SC Voice – the road to v1

Please do include numbers with periods embedded, like “1.4 million main wombs” in DN 2 section 6 segment 12.

1 Like

You can now edit examples-en.txt

The Buddha and Bhante Sujato have done quite a remarkably consistent job of choosing phrases carefully to match spiritual needs. I see Examples as a way to teach folks Bhante’s vocabulary for the Buddha. This is why I set my maxResults to 25 when refining a search term. Usually a smaller set of results exactly matches what Bhante had in mind during translation. A search term like “suffering” is therefore too broad to be useful, but “root of suffering” homes in quite exactly to 7 suttas.

1 Like

I have added this to V1.0 as a bug. However it is tricky. I currently use the periods to distinguish sutta references such as SN12.3. :thinking:

2 Likes

Yes, and I think this is general usage. Maybe you’ve to address numbers like 1.4 million individually—and I think there might not be too many of them.

2 Likes

Oh. By the way, @sabbamitta technically has now the ability to update the Release Plan. If @Aminah allows, you would be able to add your entry to the desired release and cc Aminah for approval. We are currently conflating bug-tracking with release-planning for convenience, but we are also self-organizing so let’s work efficiently within our roles.

1 Like

Many thanks for the courtesy (very touching :anjal:), but of course, my approval isn’t needed.

Yes, it’s a really good point and it’s very helpful for everyone to be on the same page. As per previous discussion, I had taken it (perhaps mistakenly) that the Backlog (subdivided into features, bugs & research) was the place to register everything not in the immediate release plans (ie v0.9.2 & v1) and that everything would be re-assessed at v1.

Beyond that, to my mind it makes sense to order/prioritize whatever’s being added to what ever list (v0.9.2, v1 or backlog) it terms of value it adds to the app, but if you’d (plural) prefer to do it a different way, it’s all good by me.

1 Like

Yes. In a standard scrum team, the QA Lead will assign release priority for bugs and would put features on the Backlog for the PO to prioritize. Features are fuzzy and require careful thought from one person (the PO) to elicit a continuity of purpose.

1 Like

Okay, so from that I’d suggest

  1. leaving V1.1.0 planning till we’re further along the road.
  2. waiting until we have some more input from stakeholders so that we have a clearer idea about what is most important to work on.
2 Likes

Thanks a lot for the trust!

I’m a little bit afraid that my technical knowledge might be not quite enough to assess whether fixing a bug requires much or little work, or would even involve costs, or if it is at all feasible. I don’t feel too confident to just put you things on your plate without knowing how edible they are…

Maybe I’d restrict myself to adding propositions to the Backlog for the time being.

1 Like

Don’t worry, I had (and have) exactly the same issue, then I started to discover this incredible technical skill I didn’t realise I had: asking! :smiley:

Actually, you raise a very good point because I realised that I never actually mentioned my work around when initially adding/amending things; I just added it according initial rough assessment and left a “(TBD)” (to be discussed) note for anything I wasn’t sure about (primarily in terms of work involved).

I think as per the above we all seemed happy with the idea that so as to be able to draw a line somewhere we’d leave v0.9.2 as it is, except for anything that strikes you as very important.

1 Like

The Technical Lead also has the ability to amend the Project Plan with information such as cost/consequences so that the QA Lead and PO can together make rational decisions.

2 Likes

Oh master of Scrum, I know that you will know it has to be a negotiation between all parties, the QA and PO have to have input from the devs to have even the remotest possible chance of knowing what is achievable.

Speaking of which, Karl, in terms of how v0.9.2 looks right now, how does it seem to you in terms of load/manageability?

1 Like

Actually, the Buddhist model of silent assent works quite well and efficiently. Dev need speak only in order to provide reasons for re-consideration. PO/QA should not be burdened by technical limitations.

2 Likes

As far as I’m aware, the Buddha’s model organising a community is by unanimous consent.

I don’t think of it quite so much as a burden, as we need input from a (read ‘the’) key party. More importantly than that, my preference is for everyone to happily negotiate what works for them and keeps them happy in their work.

1 Like

The Buddha consented in silence. --DN33 :speak_no_evil:

I haven’t said anything because (? 2018/9) is still within reach, with 99% probability of 12/31/2018.

Understood. But for Scrum to work brilliantly, the PO must stay true to vision and chivvy and harass and provoke engineers to step up to that vision. Sometimes that vision requires engineers to reach beyond what they know. And in those cases absolutely wonderful things happen. Engineers, in turn, are responsible for educating the team about how a given architecture can implement a vision. Architecture informs possibility. Vision drives architecture. Suffering is a vital condition for faith, joy, rapture, tranquility, bliss, immersion, and truly knowing and seeing (i.e., vision per SN12.23). The PO turns suffering into vision.

1 Like

I’m learning a lot about how software development is organised!

I’ll learn this by heart and may frequently apply it! :sweat_smile:


Coming back to the search phrases:

This may be a personal preference of mine for similes; but on the other hand I think it does happen that people want to find a specific simile in the suttas, maybe because they remember having been inspired by a sutta with this simile, and wish to study the teaching connected to it—which may address a particular kind of suffering they experience. :thinking:

I feel this is really a good point, and I absolutely see the value in giving preference to phrases with a limited number of results.

1 Like

Just as I would encourage you to not take any English tips from me, I’d likewise encourage you to not take any software dev tips from me. It is a dark art I’m negotiating mostly by ignoring expectations and finding idiosyncratic solutions where I see fit.

2 Likes

The possibility to have a simple means to express that I’m just guessing what I’m doing feels very reassuring to me! :smiling_face_with_three_hearts:

1 Like

Oh hey, I just remembered a wiki page was set up aaaages ago specifically for mispronunciation (before I think there was even any Pali voice). Would it perhaps make sense to commandeer that page for these purposes?

Maybe it will help avoid things getting too cluttered and we can pull in pronunciation fixes into each release plan as we go.

2 Likes

Almost all of Sabbamitta’s finds are fixable without excessive effort. The Mispronunciations wiki page has documented those sad exiles that will probably never be fixed. By all means do feel free to update MIspronunciations with more homographs or other oddities.

2 Likes