Somebody gave my mail system an atomic wedgie, I'm just going to batch
these up...
On Fri, Aug 30, 2002 at 12:29:22AM -0400, Andres Salomon wrote:
> fixing bugs, to simply closing them in the BTS. Sometimes, it's good to
> keep bugs open in the BTS
> (tagged w/ wontfix,
These will be eliminated from the candidate set anyway
> documenting a problem that other people may bring up
That's an abuse of the BTS; put it in README.Debian.
> or tagged w/ unreproducable, as another person may stumble across
> the bug, and find the original bug report useful in finding a way to
> reproduce
I've got a few ideas about how to deal with that, it's just a question
of suitable bias. More on that later...
> or w/ a severity of wishlist, that perhaps the current maintainer
> may not want to deal w/, but the next maintainer may
Getting somebody else to look at it and deal with it seems reasonable
here. If the maintainer actively doesn't want it fixed, they should
tag it wontfix.
> etc). Closing bugs does not necessarily mean fixing them.
>
> Will only certain types of bugs count? What happens when a NMU closes 1
> bug, but adds 10 others? If this doesn't improve the overall quality of
> debian, there's not much point..
==
On Fri, Aug 30, 2002 at 03:24:41PM +0200, Peter Makholm wrote:
> Of course this shouldn't change the way we use the BTS. If people
> misuse the BTS and close bugs which isn't really fixed or really
> proved as non-bugs they shouldn't get credited for the close. We might
> even let it have a negative impact on their status.
First and foremost, don't forget: this is the real world and the real
BTS. If you fuck with it, you'll get a punch in the nose. If you're a
developer, we know where you live. This, obviously, does not grant
people any special privileges whatsoever - the usual responsibilities
("get it right, all else can be forgiven"), rules ("arbitrary and
ill-defined") and punishments (@gFuckheads) relating to the BTS still
apply.
Other than that, I think it's sufficient to catch re-opens of bugs and
apply a suitable penalty.
==
On Sat, Aug 31, 2002 at 02:35:04PM -0500, Adam Heath wrote:
> Follow slashdot's ideas. Random people get to approve/disprove/verify other
> people's work. Slashdot calls it meta-moderating.
Will have to ponder that, /. has the advantage of being able to pester
you with a link at the top of the page every day, and verifying bug
fixes is much harder than reading posts.... maybe award points for
doing it.
==
On Fri, Aug 30, 2002 at 08:15:17AM -0500, Colin Watson wrote:
> I would say that wishlist and wontfix ought to be discarded when it
> comes to selecting bugs to be examined.
wontfix will be ignored when building the list of candidate bugs.
wishlist is a little trickier, as I don't want to build in unfairness
for those cases where a bug should be downgraded to wishlist, and that
can't be scored as it would open a mechanism for abuse. So the current
plan is to make it optional (default: no wishlist), so that you will
never be assigned them, and no score is given for downgraded bugs.
> Also, I'd say that there ought
> to be more than one way to score your point beyond just closing the bug.
Getting a pending tag from _the maintainer only_ gets a similarly
pending score, to be awarded when the bug is really closed (so uploads
can be delayed beyond the deadline).
> They probably ought to be verified by a human referee to make sure the
> result hasn't been harmful.
I'm inclined to ignore that possibility unless a) the bug is reopened,
or b) some other assertion that the bug was improperly handled is made
(some sort of mechanism will be provided).
==
On Fri, Aug 30, 2002 at 08:17:05AM +0200, David Schmitt wrote:
> [Please Cc: me since I am not subscribed, I hope mutt figures this
> out]
It didn't. Add debian-project@lists.debian.org (or just debian-, it'll
get the lot) to your "lists" line in .muttrc, but not the "subscribe"
line, and it'll DTRT.
> On Fri, Aug 30, 2002 at 03:45:18AM +0100, Andrew Suffield wrote:
> > Here's the basic idea: turn bug-fixing into a game (a counterbalance
> > to the huge quantities of time which moon-buggy and frozen-bubble have
> > taken away from Debian development).
>
>
> 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'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.
> 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 ;)
==
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).
> Or, if you don't know the language well, is that what the upstream
> developers are for? :)
Indeed. Note that the system does not care who closed the bug, only
that it gets closed - harassing the maintainer until they deal with
it, or persuading somebody else to deal with it, are both perfectly
valid approaches.
(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).
==
On Thu, Aug 29, 2002 at 09:04:05PM -0700, Sean 'Shaleh' Perry wrote:
> Does the player score if they post a patch or if the maintainer actually
> accepts it?
Currently the plan is to only pay attention to the bug being closed -
a patch sitting in the BTS, unapplied, does not fix anything, so it
woulnd't really be appropriate to score for it.
> Also once you have this more fully fleshed out perhaps announcing this on some
> place like DebianPlanet would be a good idea. We have plenty of users who
> have time to fix a bug or two but not become full time devels. Or is this
> meant as a Debian devels only game?
I see no reason to restrict it beyond people who have access to the
BTS. Even signatures won't be necessary to _play_, although some other
aspects may require them - the player doesn't really need to
communicate with the system in any manner more complicated than a
mailing list subscription (sort of).
--
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://www.debian.org/ | Dept. of Computing,
`. `' | Imperial College,
`- -><- | London, UK
Attachment:
pgpyrgNJylL7n.pgp
Description: PGP signature