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
