I let this letter sit a while, partly because I was busy with other things,
and partly because current-users has been consumed with other discussions;
this one got lost in the noise.

At 14:14 -0700 9/25/98, in his message entitled "bug message", Guenther
Grau wrote:

>Bill Studenmund wrote:
>> If the bug has a responsable party assigned, I think Erik's reminder
>> scripts will remind that party about the bug.

>That's great! I didn't know about the existance of this script.
>However, this still leaves the other task I mentioned:
>
>Who reassings a bug if the fix takes to long?

No one in particular.

>And you brought up another aspect to consider:
>
>Who takes care that all bugs are assigned to someone?

No one in particular. There are automatic assignments to generic mailing
lists, but that's about it.

>IMHO, we need some people who just take care of fixing bugs.
>We have lot's of extremly talented developers, who
>make excellent designs and implementations, but it
>would be great if we had a couple of people who
>just fixed some bugs and thus freed our talented
>developers from this (mostly) busywork, so they
>have more time to spend on designs.
>
>  Guenther

The NetBSD Project has given its GNATS database relatively benign neglect
for some time. I've been gently trying to nudge things in what I think is
the right direction for a while now with some success, and with that
background, I'd like to suggest some changes to how problem reports get
handled:

1. We need a database administrator; someone who will be responsible for
the care and feeding of the GNATS database itself.

2. I believe that new problem reports (PRs) in the port-specific categories
should be automatically be assigned to PR-person for that port, by default,
the portmaster. Note that being the responsible party for a PR does not
mean that you have to be the one to do the work, it means that you should
see that the work gets done, and the PR answered. Really, we need a new
type of job title, perhaps "port-foo QA person" with an appropriate E-mail
alias (e.g. port-foo-whipping-boy), which would be the postmaster by
default, but easily reassigned to someone else when a volunteer steps up to
the plate.

(just as an aside, I think that having a per-port "build" person would be a
pretty good thing, too).

3. for the generic categories we need at least a "responsible person per";
I have no problem with committees per se, provided that there is a clear
delineation of responsibilities so that nothing gets dropped on the floor
("I thought you were supposed to handle that!" "Well, I thought *you* were
supposed to handle that!"). Certainly we have people who specialize in
things like standards conformance (e.g POSIX, XPG), security, and kernel
hacking...

The whole goal of this is to improve the response time we give to problem
reports, both in time and quality. We tell people when a problem shows up
"please file a PR to make sure this issue isn't dropped on the floor" but
we're not as good at followup on those PRs as I believe we should be.

I recognize that this is a volunteer project, and that any given person has
limits on what he or she can contribute. This is why I am suggesting
additional people be recruited, rather than trying to heap new work on the
existing base of support that we have.

And to put, so to speak, my money where my mouth is, I volunteer to be DB
administrator.

For those of you who might unaware, we have a pretty nice web browsing
interface to the GNATS PR DB system at http://www.netbsd.org/Gnats/ even if
I do say so myself. Please feel free to fix as many PRs as you are able; it
is much easier to respond to and close a PR when there is already a fix
attached, and nothing stops any of you from corresponding with the person
who had the problem and trying to help them make it work (just be sure to
CC "gnats-bugs@gnats.netbsd.org" with the PR category/number in the subject
so that the database will append that correspondence to the PR in the
database). NetBSD works best when we *all* (users, developers, core) work
together.

	Erik <fair@clock.org>