Re: "Bug of the month", or how to get people fixing bugs
Andrew Suffield <asuffield@debian.org> writes:
> > Please consider http://c2.com/cgi/wiki?BehavioralEffectOfMetrics.
> >
> > Especially following section:
> >
> > | As JimCoplien has been saying for years (repeating an old adage),
> > | "What gets measured gets done." Measure the Severity A bug reports?
> > | Nothing that doesn't actually kill a user will be higher than Severity
> > | B. How long are bug reports in the "open" state? They never will be;
> > | they'll skip directly from "created" to "closed" (or will be
> > | transitioned as soon as the system allows). Track how many lines of
> > | code a programmer writes? You'll see a lot of comments. Measure lines
> > | of non-commentary code? There are tricks to bloat that one, too; you
> > | may even encourage copy-and-paste.-( Measure how many bug reports a
> > | programmer does real work on? You'll see heavy concentration on
> > | trivial fixes, and an avoidance of doing anything complicated.
>
> That's kinda the whole point. The usual abuses of doing only the easy
> tasks are not possible, because the only thing you get scored for are
> the randomly-selected tasks that you were assigned. The only bias is
> to close the assigned bugs in a manner that does not get them reopened
> (or otherwise flagged as improperly closed) - and that's the desired
> goal.
I also made the proposition that you could steal somebodys points by
supplying a shorter/better/cleaner patch to the same problem. The
judge there should probably be the maintainer (but he won't get points
for doing so himself) because he has to life with the patch.
> > | I've always mistrusted software metrics. All too often, all they
> > | measure is how well people can manipulate them. (I hate having this
> > | attitude! Improving software quality or software development without
> > | metrics is like loosing weight without ever getting on a scale. Not
> > | that getting on a broken scale will help a dieter any....)
> > | --PaulChisholm
>
> The trick is to ensure that manipulating the metric results in the
> desired goal. This is not usually easy, but in this case it seems to
> be.
>
> Normally the big problem is that people concentrate only on the
> metrics - but you won't get assigned bugs on packages that you
> maintain, so each package still has its normal maintainer taking care
> of it.
The metric should be simple and should not fluctuate too much with
small changes, like adding spaces or newlines.
Also some interaction with the maintainer could be added. He clould
give extra points for clean fixes or deduce points for stuff he has to
still cleanup.
> > I can only support Andres Salomon, that very much care has to be
> > taken, to _not_ bias this game against current goals (quality and
> > users). Iff this can be archived, it could be quite fun ...
>
> The specific objective is to stir up the morass of bugs that are
> sitting there and not getting dealt with. I suspect that it is not
> actually necessary to be very detailed in avoiding abuses - simply
> getting attention will cause a great many of those bugs to be fixed,
> or closed, as appropriate.
>
> Even if the net result is only that all the non-bugs get closed (but I
> doubt that would happen), that's still a good thing ;)
Think about a Bug Squashing Party but with rules, statistics and points.
> ==
>
> On Fri, Aug 30, 2002 at 08:32:30PM -0400, Vikki Roemer wrote:
> > Sounds cool! Not that I've done any *serious* programming (yet ;) ; or
> > at least, nothing that I think is worth packaging up and submitting--
> > although my alarm clock has possibilities, I think... Anyway, I would
> > consider joining the 'Bug of the Month Club' once my classes settle down
> > a mite and once I get a mite more programming experience-- say, in a few
> > monthes. One quick question, though-- can the players choose which
> > languages they would prefer to work with, or don't they have a
> > choice?
>
> I can't think of any way to filter assignment by language, especially
> since that would open a few abuse paths (there really aren't very many
> things written in tcl, ruby, or objective C, to pick three at random,
> and the system's fundamental security layer is based on random
> selection from a vast pool of bugs).
If you have such an odd selection you might not get any bugs by lack
of bugs and thus no points. Does that sound fair?
> (It is possible that the bug could get closed through random chance
> while it was assigned to somebody - but the odds are low, so it's not
> really a problem).
Thats when you draw a joker.
Same with "merge". You might merge it with a bug someone closes. Easy
point.
MfG
Goswin
Reply to: