Bug tracking system policy

Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> writes:
> (btw, I've taken this on-list per Tom Lane's suggestion; the
> short summary is that the new bug tracking system is getting non-bug
> bug reports and it is short-circuiting the highly successful mailing
> list support process.)

Just to give everyone else some context (and try to get a more useful
title on the thread ;-)), this discussion concerns the Keystone bug
tracking system that was recently installed on www.postgresql.org;
see http://www.PostgreSQL.ORG/bugs/nbrowse.php3. There is some
sketchy documentation about Keystone at
http://www.stonekeep.com/ksonline/docs/docindex.html.

Now that we've got the thing, we need to figure out an effective process
for using it. The limited experience so far doesn't seem particularly
productive. Here are some comments that I sent to the core group
earlier today.

Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> writes:
> We've got a *great* network of folks on the mailing lists who help
> everyone with questions. That should be the first (and second, and
> third) line of defense for anyone with a question or a possible bug
> report, and imho we shouldn't have *anything* in the bug tracking
> system which has not gone through that process first.

> How do we accomplish this without having a completely closed bug
> reporting system (which for me is one of the options; Bruce could use
> this for his bug-related ToDo's...).

Hmm, so you are thinking it should be a *tracking* system for
acknowledged bugs, but not an initial reporting system, and we'd
continue to rely on the mail lists for initial reporting.

That might not be a bad idea. I've already noticed that people
are failing to provide full bug reports (version, platform, etc)
because the Keystone system doesn't give them a template to fill out.
Seems like we were getting more complete reports via the email process.

> Should we consider having a more limited number of folks with access
> to the bug tracking system? Perhaps this could be a perk for long-time
> contributors who go out of their way to help answer questions??

We want read-only access for everyone, I think, but limiting the number
of people who can enter and update slips might be good.

My reasons for pushing a BTS in the first place were that it would
provide better *visibility* : has a bug been fixed, who is working
on it, what is known about it, etc. Basically I was thinking of a
TODO list with more detail per item than a one-line summary. (Also
it should keep records of closed-out problems, so people could find
out what version fixes a problem.)

Cluttering the BTS database with random reports doesn't aid visibility
of the important ones. We want to allow read-only access so that status
is visible to everyone, but that doesn't mean we have to allow everyone
to alter the database.

This line of thought also suggests that we should immediately enter
all the TODO items into the BTS as slips... Bruce could then generate
the text TODO via a query from the DB ;-)

Further comments, anyone?

regards, tom lane