[core-workflow] Tracker workflow proposal

[R. David Murray]

On Mon, 21 Apr 2014 14:35:48 -0400, Barry Warsaw <barry at python.org> wrote:
> On Apr 21, 2014, at 12:04 PM, R. David Murray wrote:
> 
> >Priority
> >~~~~~~~~
> >
> >    low
> >    normal
> >    high
> >    deferred blocker
> >    release blocker
> >
> >I'd like to see us strive keep those queues clear, so that promoting a
> >bug to high or release blocker means it *will* get acted on reasonably
> >promptly.  (This raises the issue of what to do about bugs we currently
> >mark as "release blocker" as a *reminder* to the release manager.  I don't
> >have a proposal for that at the current time, as release management is
> >out of scope for this document, but we'll need an answer if we are going
> >to implement this.)
> 
> This is definitely an area of friction that I think needs addressing.  The
> problem is that a release blocker for one version may not be a release blocker
> for another.  Worse, it's the responsibility of the release managers - which
> may be different per release - to manage these.
> 
> Generalizing, it may be in fact that different active versions of Python might
> assign different priorities to the same bug.  I'd like to at least keep on the
> table the option to assign a priority per active Python version.

Well, one way to approach this might be via the 'fixed in version'
field, which is more-or-less how we handle it now.  To make this work,
we need another role, the release manager, who gets a new work queue
for each release for which they are responsible, and it only shows bugs
that are priority 'release blocker' or 'deferred blocker' and have *not*
been fixed in the version the queue is for.

Another possibility would be to remove the blocker priorities, and make
them version-specific tags (release-blocker-3.4, deferred-blocker-3.4,
etc).  This approach would also allow those tags to be used for the
'reminder' function.  It makes for a lot of tags, though.  Which
wouldn't be bad if we had a full tag system such as Barry mentions
in a later message.

I have a feeling that per-release priorities only apply to release
management.  Would blocker/deferred be enough priority distinction
to serve?

--David