[core-workflow] Tracker workflow proposal

[R. David Murray]

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).

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'.

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