On Wed, 18 Jun 2003, Richard Earnshaw wrote:

> > That's all fine (in theory), but the only practical purpose of
> > all that is to sort them on the web page, by severity first, then
> > priority. If you browse the page of unassigned bugs for a category,
> > you'll see that non-critical/high are listed beneath critical/low.
> > Of course volunteers can work on bugs in any order they like.
>
> Looking at http://www.netbsd.org/Gnats/category/toolchain.html we see all
> the high-priority toolchain bugs first, then the medium priority ones,
> then the low-priority ones.

Yet, when you look at the bugs assigned to an individual (or
non-individual -- pkg-manager get the unassigned bugs), you'll
see them sorted by severity, first.

  http://www.netbsd.org/Gnats/responsible/pkg-manager.html

Another reason to do away with the (IMO) absurd distinction.

> That makes sense to me.  High priority bugs are the ones the project has
> deemed to be more important to address.  It doesn't matter that there may
> be a critical bug in a lower priority category.

Everything makes sense if you contemplate it long enough, and embrace
the absurdity. (I work for the gu'mmint, so I see a lot of that.)
Still, from the point of view of the action-taker, I don't think it
makes any sense to have a critical, yet low-priority, bug. Really.

> > Of course volunteers can work on bugs in any order they like.
>
> Certainly.  Opensource project management is often said to be like herding
> cats?

;-) So I've heard. (I'm not in management.)

Frederick