We've had an increasing rate of non-issues entered into the issues
database lately. This isn't really anyone's fault, and I don't mean
to point fingers -- any project that has users will have a high rate
of both issue duplication, and of spurious issues.
The question is, how to handle it better?
Right now, only a few people regularly read and prune the issues
database. Ben Collins-Sussman, Mike Pilato, Greg Stein, and I do; I
also get the feeling that Philip Martin does it a lot, and Brane does
some. Apologies if I left anyone out. My point isn't to give a
complete list here, but to show how few people do it, compared to,
say, the number of people who read and respond to the dev list :-).
Jon Trowbridge, who has experience with large bug databases, says that
it's *very* effective for volunteers to get involved in issue
management. He mentioned these strategies specifically:
- When newcomers ask "How can I get involved?", we can recommend
that they go through open issues, seeing which ones still
reproduce, and checking for duplicates. This answer is
especially good for people who want to help but are not
developers, or for whatever reason are not prepared/qualified to
dive into the code itself.
- Jon also recommends "bug days". Participants join a special
`svn-bugs' channel on irc, and we devote the day to cleaning the
issues database (sounds like fun, I'll bring the beer!). Having
everyone there allows people to ask real-time questions about
whether X is expected behavior, or whether issues Y and Z are
duplicates, etc.
So please, if you're looking for a way to help, dive into that issue
tracker! If you come out holding the mangled and bloody corpses of
invalid/redundant issues, we'll hold a cookout on this list.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 11 19:32:03 2002