Reconsidering the "buddy system"

These days, the dev@ list is a very busy place. It takes a truly
dedicated person to attempt to read everything that goes on there. I
regularly find myself discarding some threads, in order to reserve
enough time to participate effectively in others. In particular, I am
concerned about people posting patches which slip past our collective
radar and are lost in oblivion. For this reason, I wonder if we have
done wrong in trying to direct patches to email and never issue-tracking.

I've recently gone and tried to read our issue tracker policy from an
outside perspective. The result of that is that I am now afraid that we
are making unreasonable demands on what people must do before they
report bugs to us. I've come to the conclusion that if I was to
encounter Subversion's policy for the first time in a project that I was
not strongly involved in, I would be fairly indignant at the hoops I was
being asked to jump through.

For the two reasons above, I would like to propose that the buddy policy
be abolished forthwith.

Naturally, this will require that we developers interact more with the
issue tracker. However, I think this is something we MUST do anyway -
there are currently 72 issues in the "---" milestone, which is supposed
to be a marker of "this issue has not yet received initial triage". I
think we have fallen into the trap of marginalizing the issue tracker to
the point that even the developers aren't using it effectively, for the
most part.

So, in brief, here's what I think we should do about it:

1. Modify the IZ front page to:

a) politely request that people carefully consider whether they have a
true bug, or a case of user error, or a reasonably complete code
contribution, or a simple draft patch for discussion.

b) guide people to use the issue tracker for bugs or significant code
contribution, or the mailing list otherwise.

c) strongly recommend that when filing an issue, they also post a link
and a brief summary to dev@, explaining that this will greatly help in
getting prompt responses. Emphasize that the list is the place for
discussion, and the issue tracker works best for checkpointing summaries
of the progress of discussions, not holding them itself.

2. Set up a simple list of boilerplate responses for closing misguided
issue filings, so that we can deal with them with an extreme minimum of
effort.

3. Have a policy of regularly reviewing "---"-milestoned issues, perhaps
with an automated periodic mailing of open "---" issues to dev.

4. Try to use IZ to maintain a central database of things that need to
be done, rather than keeping a great deal of that information on
individual brains and inboxes.

I am hopeful that the end result of this will be to take some of the
pressure off dev@ as the sole mechanism for reporting *and tracking*
inbound bug reports, and allow us to make better use of our issue tracker.

Max.