[core-workflow] Tracker workflow proposal

[Brett Cannon]

On Mon May 05 2014 at 11:54:18 AM, R. David Murray <rdmurray at bitdance.com>
wrote:

> I'm a week later than I expected, but I've added my notes to the
> discussion summary started by Ezio at:
>
>     https://wiki.python.org/moin/TrackerDevelopmentPlanning
>
> Based on the feedback, I propose two major changes compared to my
> initial proposal.
>
> The first is to combine 'keywords' and 'component' into a single
> tags field, which will include all the labels from the experts index.
> Types is reduced to *just* documentation/bug/enhancement, everything
> else is a tag.  Likewise priority is reduced to just high/normal/low,
> and release-blocker and deferred-blocker become per-release tags.
>
> I think the tags should at least initially be a fixed set (that is,
> normal users can't add tags).
>

SGTM. I know Ezio pointed out the list will be long, but since triagers
will be the ones typically setting the field it shouldn't be an issue.


>
> The second major change is that I think we should defer the decision about
> how to manage patches until we can experiment with some possibilities.
> In particular, Ezio has some preliminary code to do content analysis
> on patches, and I think we should experiment with incorporating that,
> and try out a couple of different ways of managing patches once we have
> that automated analysis working.  Ezio made some notes about this on
> the document.
>
> Although this wasn't discussed directly, I also removed 'committer
> decision needed' from the list of states, leaving just 'decision needed'.
> The various 'closed/xxx' items can at least for now (and probably forever)
> continue to be a 'closed' state plus the (simplified) 'resolution'.
> Given this, it would be quite practical to simply change 'stage' list
> from its current value to what I propose for the new state.  That means
> it would look like this:
>
>         - no selection -        (that is: new)
>         information needed
>         decision needed
>         patch needed
>         review needed
>         patch update needed
>         commit review needed
>         resolved
>
> We can then add reactors (and javascript) such that changing an issue
> stage to 'resolved' also closes it, and that changing an issue status to
> 'closed' resolves it, and vice versa (re-opening an issue goes to, say,
> 'patch needed' if no specific stage is set; changing the stage reopens
> the issue).  This will make it easy to implement the new state scheme
> and build the UI for the queues &c, and when we are ready to cut over
> to the new UI, we can retire 'status'.
>

Also SGTM.

-Brett


>
> If this is deemed acceptable, then I would propose that we (a) go
> ahead and make that change, (b) make the change to the 'assigned to'
> field, (which we are currently not using much at all), (c) add code
> to the existing UI to allow regular users to make the state (stage)
> transitions as outlined in my proposal, and (d) add the dashboard UI
> for getting optimal access to the resulting queues.  These changes are
> really the heart of my proposal, and would get us a lot of the benefit,
> even before we optimize the UI.
>
> --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/20140507/bce5ec50/attachment.html>