Please do include numbers with periods embedded, like “1.4 million main wombs” in DN 2 section 6 segment 12.
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.
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.
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.
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.
Many thanks for the courtesy (very touching ), 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.
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.
Okay, so from that I’d suggest
- leaving V1.1.0 planning till we’re further along the road.
- waiting until we have some more input from stakeholders so that we have a clearer idea about what is most important to work on.
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.
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!
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.
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.
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?
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.
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.
The Buddha consented in silence. --DN33
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.
I’m learning a lot about how software development is organised!
I’ll learn this by heart and may frequently apply it!
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.
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.
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.
The possibility to have a simple means to express that I’m just guessing what I’m doing feels very reassuring to me!
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.