To everyone participating: the discussion has become IMO completely impossible to follow. There is a single monster-thread discussing all issues at once, without any subject change. I think issues should be broken into distinct threads with distinct mail subjects, to make things readable again.
Thanks & regards Antoine. On Thu, 08 May 2014 14:31:35 +0000 Brett Cannon <bcan...@gmail.com> wrote: > On Thu May 08 2014 at 1:44:21 AM, Ezio Melotti <ezio.melo...@gmail.com> > wrote: > > > On Thu, May 8, 2014 at 1:58 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > > > > > > On 8 May 2014 01:59, "R. David Murray" <rdmur...@bitdance.com> wrote: > > >> > > >> On Wed, 07 May 2014 08:09:03 -0700, Carol Willing > > >> <willi...@willingconsulting.com> wrote: > > >> > I'm wondering if "decision needed" might be more accurately named > > >> > "triage needed"? > > >> > > > >> > Looking at David's well documented proposals and other mail comments, > > >> > "triage needed" more specifically describes the 'state'. > > >> > > > >> > A few thoughts: > > >> > > > >> > 1. "Triage needed" would raise the importance and visibility of the > > >> > triage contributor role. A positive for onboarding and growing > > >> > development talent. > > >> > > > >> > 2. "Triage needed" is more descriptive and clearer than "decision > > >> > needed" especially for those users that do not read documentation or > > >> > understand the development workflow. "Decision needed" implies that a > > >> > decision will be made to include or not include in a release. > > >> > Realistically, decisions are made throughout the remainder of the > > >> > development process based on time, resources, etc. > > >> > > >> I'll be interested in what others think, but to me "decision needed" is > > >> closer than "triage needed". That is, the state means that someone > > other > > >> than the person moving the issue to that state needs to make a decision. > > >> That decision can be "Is this something we consider a bug? What > > releases > > >> can we fix this in given our backward compatibility requirements? > > >> Is this an acceptable enhancement? And any other decision that needs > > >> to be made before the issue can move forward. > > >> > > > > I agree. To me "triaging" mostly means updating fields/metadata and > > it's something that is done once the issue is reported. This also > > includes adding people to the nosy list so that they can comment and > > start dealing with the issues, but I don't consider this "triaging" > > anymore. IOW "triage needed" would correspond to "- no selection -". > > OTOH, "decision needed" means that the people working on the issue > > need to reach an agreement. A good example of this is > > http://bugs.python.org/issue18967. Here no triaging is needed IMHO. > > > > This is exactly the way I thought as well: the initial default state is > "triage needed" and "decision needed" means someone higher up has to make a > call on a question. Can we simply name the "no selection" state have the > text "triage needed"? > > -Brett > > > > > > >> All of these *can* be "triage" decisions, but to my ear it is the word > > >> "triage" that is more about deciding where to allocate resources ("which > > >> release"), whereas we generally don't work that way. We just decide if > > >> it can go in or not, and if the patch is ready before the next release, > > >> it can go in. > > >> > > >> More specifically, because I removed 'committer decision needed', > > >> 'decision needed' covers the case of needing a committer decision, > > >> which is by definition not a triage decision :) > > >> > > >> Perhaps 'committer decision needed' should be kept after all? > > > > > > > I don't think the distinction is useful. Anyone can contribute to the > > discussion, as long as they don't just give their opinion and change > > the stage directly. For example in http://bugs.python.org/issue18967 > > a Mercurial dev could give his opinion, and if the others agree, the > > stage can be updated (to "needs patch" or "needs review" if a patch is > > already present). > > > > > From a work queue perspective, two separate states likely makes sense, > > since > > > "Triage needed" & "Committer decision needed" are aimed at slightly > > > different groups of people (with the latter being a subset of the > > former). > > > That way, "Committer decision needed" becomes a clear avenue for > > escalation > > > by triagers to the core developers when they need a design decision or > > risk > > > assessment on a particular approach. > > > > > > > I would rather keep the list of stages short, i.e.: > > - no selection - > > information needed > > decision needed > > patch needed > > review needed > > commit (review) needed > > resolved > > > > with the following meanings > > - no selection -: issue hasn't been triaged/looked at yet > > information needed: something needs to be confirmed/clarified before > > proceeding > > decision needed: an agreement should be reached before taking action > > patch needed: we know what to do, we need the code > > review needed: we have the code, we need someone to review it > > commit (review) needed: we have the code, we need a committer to commit > > it > > resolved: issue is now closed > > > > These would be useful to (triagers also includes committers): > > - no selection -: triagers (searching for untriaged issues) > > information needed: original poster (probably not useful in searches) > > decision needed: committers (and possibly triagers) > > patch needed: everyone (people searching for issues that need patches) > > review needed: triagers (searching for issues that need a review) > > commit (review) needed: committers (searching for issues that are > > ready to go in) > > resolved: everyone (people marveling at the outstanding work of our team) > > > > Also think how these stages would affect the dashboards (e.g. > > "information needed" should be prominent on the original poster's > > dashboard). > > > > > > To illustrate the possible evolution of an issue I made a couple of flow > > charts: > > http://imgur.com/a/UgJBJ > > > > The first is without "patch update needed" the second includes it. > > Also note that is possible to go from basically every state to > > "resolved", however I omitted those arrows, since they would just > > clutter the flow chart. I'm not sure if this should be enforced > > (probably not), but at least it should provided a clearer picture. > > > > I left "decision needed", removed "patch update needed", and possibly > > removed the "review" from "commit review needed": > > 1) "decision needed" means that the problem is clear, but we have to > > discuss about the best solution. To me, "triage needed" mostly means > > that the fields/metadata are not updated; > > 2) "patch update needed" seems redundant to me, and can be replaced > > with "patch needed" + "assigned to <previous patch author>". I'm not > > strongly opposed about removing it though; > > 3) "commit review needed" seems useful to signal to core devs that > > someone reviewed the patch and it is now ready to be committed. This > > assumes that the committer will do a further review, but if we already > > passed the "review needed" stage, there are good chances that the > > patch is ready to go in (if not we can always go back to "patch > > needed"). This can also be simply called "commit needed"; > > > > > > > That more structured mechanism should nicely complement the option of > > > punting decisions to the collective wisdom (hah!) of python-dev & > > > python-ideas. > > > > > > Cheers, > > > Nick. > > > > > >> > > >> --David > > _______________________________________________ > > core-workflow mailing list > > core-workflow@python.org > > https://mail.python.org/mailman/listinfo/core-workflow > > This list is governed by the PSF Code of Conduct: > > https://www.python.org/psf/codeofconduct > > > _______________________________________________ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
