Max Bowsher <maxb1@ukf.net> writes:
> 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.
This is exactly why we have a Patch Manager. If that person isn't
keeping up -- I'm not saying he is or isn't, I've not been in touch
enough recently to know -- our community is easily large enough to
find another qualified volunteer.
The Patch Manager system works very well as long as the manager stays
on top of things. Is that not happening here?
> 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.
I'm not sure I agree with this analysis.
The Buddy System does not require dev@ list interaction. IRC is fine
too. And private (non-list) email is fine. All the Buddy System
should really require is that you get someone else to agree with you
that this is a bug. The wording on the issues page should be changed
to make this clear -- right now it points to users@ and dev@
specifically; we should have it state explicitly that we just want at
least two heads agreeing on each bug report.
I'll be happy to make this change, if needed, once this conversation
has resolved.
(To emphasize, the Buddy System is only about bug reports, not
patches. I'm not sure the two should even be considered in the same
thread, they're quite different -- the main similarity is that we use
the issue tracker for tracking the lifecycles of both).
> 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.
Why would changing the Buddy System requirement result in developers
spending more time triaging issues? If they're not doing it now, when
the issues have already been through one level of filtering and are
presumably of high quality, then what is it about a higher number of
lower-quality issues that would cause developers to spend *more* time
in the tracker, exactly? :-)
> 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.
A lot of interface clunkiness is disguised behind that "set up a
simple list". The fact is, dealing with any issue is always going to
take a certain constant level of effort. I already have boilerplate
responses, sitting unused in files; maybe if my browser were more
easily scriptable I'd use them :-).
> 3. Have a policy of regularly reviewing "---"-milestoned issues,
> perhaps with an automated periodic mailing of open "---" issues to
> dev.
Policies that are "negative action" are successful here because they
specify requirements that must be met before something is done, e.g.,
a certain number of signatures on a release tarball.
But "positive action" policies are totally different. Okay, so we
have this policy; but who actually is going to do this reviewing?
Whoever those people are, why are they more likely to do it when we
have a policy then when we don't? Are we giving them raises or
something?
> 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 thought we already do this. Do we not?
> 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.
dev@ is not the sole mechanism for tracking inbound bug reports.
dev@ has been the sole mechanism for receiving (but not tracking)
inbound *patches*, and a patch manager has been responsible for seeing
to it that they make it into issues when not processed immediately
on-list. If that system has lapsed, let's find out why. It's a good
system when it works; I'm pretty sure of that because I've seen it
working before.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 8 19:13:17 2006