Priorities in the tracker

After some months of tracker operation, I'd like to discuss
one aspect
of the tracker schema: priorities.

Each issue has a severity and a priority. The severity is
assigned by
the submitter, defaults to normal, and indicates how serious
the issue
impacts him and the community.

The priority is assigned by a developer (and cannot be set
by
a "mere" user), and indicates how quickly this
issue must be processed.
The priority is initially unset, requiring a developer to
perform screening.

It appears that developers rarely set the priority, leaving
the issues
formally unscreened.

So what should we do? Leave things as-is? Drop the notion of
priority?
Change our process to make sure priorities do get set (and
honored)?

Regards,
Martin
_______________________________________________
Python-Dev mailing list
Python-Devpython.org
ht
tp://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/p
ython-dev/nessto%40sharedlog.com

Martin v. Löwis wrote:
> After some months of tracker operation, I'd like to
discuss one aspect
> of the tracker schema: priorities.
> 
> Each issue has a severity and a priority. The severity
is assigned by
> the submitter, defaults to normal, and indicates how
serious the issue
> impacts him and the community.
> 
> The priority is assigned by a developer (and cannot be
set by
> a "mere" user), and indicates how quickly
this issue must be processed.
> The priority is initially unset, requiring a developer
to perform screening.
> 
> It appears that developers rarely set the priority,
leaving the issues
> formally unscreened.
> 
> So what should we do? Leave things as-is? Drop the
notion of priority?
> Change our process to make sure priorities do get set
(and honored)?
> 
It would appear useful to define some workflow aspects of
issue 
processing, for example to ensure that priority gets set by
a 
"responsible" reviewer.

However whether such workflow should be imposed by
automation or simply 
a discipline of development I'm not in a position to say.

regards
  Steve
-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC              http://www.holdenweb.com/

_______________________________________________
Python-Dev mailing list
Python-Devpython.org
ht
tp://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/p
ython-dev/nessto%40sharedlog.com

On Jan 20, 2008 10:42 AM, "Martin v. Löwis"
<martinv.loewis.de> wrote:
> After some months of tracker operation, I'd like to
discuss one aspect
> of the tracker schema: priorities.
>
> Each issue has a severity and a priority. The severity
is assigned by
> the submitter, defaults to normal, and indicates how
serious the issue
> impacts him and the community.
>
> The priority is assigned by a developer (and cannot be
set by
> a "mere" user), and indicates how quickly
this issue must be processed.
> The priority is initially unset, requiring a developer
to perform screening.
>
> It appears that developers rarely set the priority,
leaving the issues
> formally unscreened.
>
> So what should we do? Leave things as-is? Drop the
notion of priority?
> Change our process to make sure priorities do get set
(and honored)?

In my dream schema, severity becomes difficulty (e.g., easy,
medium,
hard, expert), type goes away, and priority changes to be
release-based (e.g., RFE since those can occur whenever,
next minor
release, next micro release, immediately, etc.).

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.

-Brett
_______________________________________________
Python-Dev mailing list
Python-Devpython.org
ht
tp://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/p
ython-dev/nessto%40sharedlog.com

Martin v. Löwis schrieb:
> After some months of tracker operation, I'd like to
discuss one aspect
> of the tracker schema: priorities.
> 
> Each issue has a severity and a priority. The severity
is assigned by
> the submitter, defaults to normal, and indicates how
serious the issue
> impacts him and the community.
> 
> The priority is assigned by a developer (and cannot be
set by
> a "mere" user), and indicates how quickly
this issue must be processed.
> The priority is initially unset, requiring a developer
to perform screening.
> 
> It appears that developers rarely set the priority,
leaving the issues
> formally unscreened.
> 
> So what should we do? Leave things as-is? Drop the
notion of priority?
> Change our process to make sure priorities do get set
(and honored)?

Christian currently does a good job of assigning the correct
properties
to new bugs. In any case, I'd prefer to keep a way to mark a
bug as
"high-priority" (meaning that it should be fixed
before the next release)
even if most of the bugs don't have an assigned priority.

As to whether we need both severity and priority, I have no
opinion.

Georg


-- 
Thus spake the Lord: Thou shalt indent with four spaces. No
more, no less.
Four shall be the number of spaces thou shalt indent, and
the number of thy
indenting shall be four. Eight shalt thou not indent, nor
either indent thou
two, excepting that thou then proceed to four. Tabs are
right out.

_______________________________________________
Python-Dev mailing list
Python-Devpython.org
ht
tp://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/p
ython-dev/nessto%40sharedlog.com

Georg Brandl wrote:
> Christian currently does a good job of assigning the
correct properties
> to new bugs. In any case, I'd prefer to keep a way to
mark a bug as
> "high-priority" (meaning that it should be
fixed before the next release)
> even if most of the bugs don't have an assigned
priority.

I've defined the priorities for me:

low = nice to have feature
normal = well ... pretty normal 
high = important, investigate the bug before the next
release gets out
urgent = bug breaks development or is a show stopper
immediate = security issue or major development stopper

Christian

_______________________________________________
Python-Dev mailing list
Python-Devpython.org
ht
tp://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/p
ython-dev/nessto%40sharedlog.com

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.

_______________________________________________
Python-Dev mailing list
Python-Devpython.org
ht
tp://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/p
ython-dev/nessto%40sharedlog.com