[rfc] bug handling priorities

[Stephen J. Turnbull]

Martin Pool writes:

 > There are a couple of sticky issues:
 > 
 > One is user support, where they may be easy to answer and timeliness
 > may help a lot if there is already an answer.  I think we do
 > reasonably well on the list and irc

I think the core developers do way too much, actually.  I think a
developer with something on his plate should let a user question wait
at least 24 hours, maybe 48, unless it looks like a real bug, or it's
a known user-killer whose fix isn't in common circulation yet, and the
answer is "upgrade; it's fixed but there's no workaround".  Users have
have been really jerked around by your product do appreciate TLC from
the perpetrators.

I'm not volunteering<wink>, but you oughtta see if you can get
bystanders like me to do user care.  Somebody like Brad Knowles on
Mailman-Users would be super excellent (but hey, that would be like if
you could get Larry McVoy to do user service for you, so don't set your
sights quite that high).

 > The other is that explicitly marking bugs as "confirmed, low priority"
 > has a low payoff, but detecting and acting on critical bugs has a high
 > payoff.

Excuse me, but to detect whether it's critical you gotta look at it.
And as long as you're looking, why not tick the "low priority" box
(whether or not you've confirmed it)?  (In fact, that sounds a lot
like what you actually do, as described elsewhere in your post.)

 > Saying "thanks for your bug", removing dupes before they
 > proliferate, or getting more reproduction data while it's still fresh
 > is somewhat useful, but on the whole I suspect users would rather get
 > 1 bug fixed than be thanked 20 times.

I agree with the "thanks" and "getting data", but linking dupes is
much more important than either of those.  So many times I've filed a
new bug because either I've not searched or completely missed the
appropriate keywords ... only to find weeks or months later when the
dupe gets triaged that it was fixed concurrently with my report (but
only in the dev branch) or that somebody had long since provided a
usable workaround in a linked thread/bug.  I've also wasted a lot of
time wading through a swampful of bugs that look like mine, and turn
out to be identical ... but have no additional/useful information.  It
also wastes my time as a developer, you know, the "I'm sure I've seen
this bug before but now I can't find it" syndrome.

 > The heuristic I have in mind is
 > 
 >  fixing critical bugs
 >  >> making releases
 >  >> reviewing or otherwise unblocking other developers
 >  >> landing approved patches (possibly with tweaks or test fixes)
 >  >> answering user questions

Again, I think that for somebody who can do all the other tasks,
answering user questions should be lower priority.  Somebody should be
a "meta-developer", looking for people who can do these tasks.  You
can often find somebody who's not in a position to make code
contributions who's more than happy to to direct user questions to the
right places.

 >  >> working on in-progress bugs or development
 >  >> triaging bugs
 >  >> starting new work