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. >> 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
