Give a bug a hug

[Richard Gaskin]

Terry Judd wrote:

 > I'd totally forgotten about the Bugzilla voting system. I liked that
 > approach as well and agree that bringing it back could help both us
 > and LC to prioritise fixes.

Voting is one of those things that has a certain ring of rightness about 
it (who doesn't love democracy?), and it's technically easy to do - so 
why not?

It turns out that people are much more complicated than the systems we 
create. :)

I had extensive discussion about the Bugzilla voting system with Kevin, 
Mark Waddingham, and others there at LiveCode Ltd., in response to the 
reactions many members of our community (including yours truly) 
expressed when the voting was removed from the bug DB.

What I learned was that although it seems like a good idea, in practice 
it winds up being a less useful indicator of the "importance" of a bug 
than one might intuitively think.

In dry terms, one of the issues with it is that it conflates two very 
different signals: one for the severity of a bug to the individual 
experiencing it, and another for the number of people affected by the bug.

In practice, these are some of how it played out:

If I happen to feel a bug is super important, but five others think it's 
merely worth reporting but isn't shutting down their work, my single 
five-vote click doubles the number of votes.  What does that mean?

We know it doesn't mean ten people find it unimportant.  And it doesn't 
mean that two people find it extremely important.

To fully understand exactly what a given tally score means requires 
looking at the vote distribution, and also at the individual voters and 
the details of their comments in the report.

So if I feel like casting five votes against it there's no way to know 
whether I'm actually having an urgent need, or just having a mood to 
make a point about the age of the report, or any number of things. I 
might have also contributed a comment or example which could explain my 
intention, or no further information at all.

And from time to time we may have a bug that's really critical, but so 
far seen by fewer people.  Such a report may have far fewer votes than 
one that has little harmful effect but has been seen more frequently.

And then there are the times one of us will get particularly incensed 
about a pet issue (some of you may recall times I've done this myself), 
and we rant about it here and encourage votes for the pet issue.  I'm 
sure some of those votes were people who actually experienced the issue, 
but I'm equally sure some of those were just friendly people being 
supportive, and not votes that would have arrived there organically 
without the politicking.

Give it some time and each of us can imagine other scenarios that muddy 
the clarity of that vote signal.

By the time a developer working on the bug looks at the various aspects 
relevant to understanding what the vote tally really means, there's 
enough familiarity with the details that an assessment of priority can 
be made just as easily without it.


There remains at least one element which could loosely be seen as a sort 
of voting: a bug's CC list.

Usually an address will wind up there after that person has experienced 
the bug, searched the DB for it, and found that it had been reported. 
When that happens organically, the number of people subscribing to a bug 
can be a useful addition that, with the other details of the report, 
help the team evaluate priority.

And being a single value per user, it's a single signal rather than a 
conflation of two different signals as the old form with multiple votes 
did, so it's more immediately clear what it's signifying.

-- 
  Richard Gaskin
  LiveCode Community Liaison