[core-workflow] Tracker workflow proposal

Thu May 8 16:31:35 CEST 2014

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20140508/759e1cea/attachment.html>