Re: Reconsidering the "buddy system"

I can't speak for the majority of the committers, but certainly the
CollabNet folks know what it's like to have our daily lives dictated by the
demands of the almight Issue Tracker. That's just the way things are done
at CollabNet. You *might* get a quick email or IRC fly-by asking if a
particular observed behavior was really a bug, but generally speaking, it's
straight to the tracker with any findings.

Now, things aren't as bad internally as they could be though. Because there
are a fixed number of folks adding stuff to our internal tracker, and
because those folks have mostly been interacting with that tracker for
years, we don't see terribly many duplicate issues. I suspect that
Subversion's tracker will be a whooole different ball of wax from that
perspective, but I could be wrong.

I say all that to say that if we decide to change our policy in the way you
suggest, that's fine with me, and I can attest to the fact that being
tracker-driven is actually a very productive way to be.

But that doesn't address the question of whether or not the Subversion
dev-folk *should* make that change. I don't have a clear opinion of that,
really.

We can avoid the patches-getting-dropped problem by simply having a single
person (perhaps on a rotating basis) watching the list for patches and
posting them to the tracker. In fact, I thought we had already this --
Michael Thelen, where are you?

The triage problem is a larger one, but here I have some questions, too.
So, a large part of my job is to do exactly this -- triage issues, decide
what's to be fixed and when, interact with the reporter to get more
information, estimated the effort and effects of the change, etc. I can
only do this really well, though, when I have in my head the "big picture"
of where the product is going, and what milestones it aims to hit along the
way. I'm not sure I could do such a thing for Subversion because, generally
speaking, our releases have very little definition. It feels kinda like,
"Hey, it's been six months so we should release something." That's not a
particularly inspired way to run a project, and certainly doesn't lend
itself to a clear picture of when particular defects or enhancements get
fielded. Remember the final push to 1.0? The definition of that release
was much more solid than really anything since, and I think triaging issues
(which we did quite a bit of back then) was easier to do.

Max Bowsher wrote:
> 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.
>
>
>
>
>

-- 
C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand