[core-workflow] Tracker workflow proposal

Fri May 9 00:05:37 CEST 2014

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 <bcannon at gmail.com> wrote:
> On Thu May 08 2014 at 1:44:21 AM, Ezio Melotti <ezio.melotti at gmail.com>
> wrote:
> 
> > On Thu, May 8, 2014 at 1:58 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> > >
> > > On 8 May 2014 01:59, "R. David Murray" <rdmurray at bitdance.com> wrote:
> > >>
> > >> On Wed, 07 May 2014 08:09:03 -0700, Carol Willing
> > >> <willingc at 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 at 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
> >
> 