[Python-Dev] Priorities in the tracker

[Stephen J. Turnbull]

Brett Cannon writes:

 > In my dream schema, severity becomes 

Then how does the user indicate how important it is to him?  My
severities (in an experimental roundup tracker I'm implementing) are
'inelegant', 'inconvenient', 'some work obstructed', 'much work
obstructed', 'security', 'data loss', 'sudden death'.

 > difficulty (e.g., easy, medium, hard, expert),

This is hard to classify with confidence, IMO.  It also means
different things: You could associate it with the set of developers
qualified to handle it, or with the amount of time it would take an
experienced developer to deal with it.  These points of view are
correlated, but I wouldn't be surprised if they have different effects
on the workflow.

 > type goes away,

I'm leaning to this myself, except that I think it is useful to inform
non-developers that some things are organizationally hard.  Eg, a "big
RFE" will require a PEP, while a "big bug" just gets fixed ASAP.

 > and priority changes to be release-based (e.g., RFE since those can
 > occur whenever, next minor release, next micro release,
 > immediately, etc.).

What you're talking about here is what a lot of projects call
milestones.  However, priority is a separate notion, especially for
features.  It indicates which features scheduled for the next
milestone are most likely to get delayed to a later one.

 > I think priority should more be tied to our release cycles than this
 > generic notion of importance. If it is important, we should try to get
 > it done by a certain release. Let's have that fact directly reflected
 > by the tracker.

Sure.

Note that if you take everything I said literally and implement it,
you get an unwieldy mess.  Something's gotta go, I expect.  But I
think there are aspects to the "dream schema" you present that are not
going to work as well as you would hope.