Voting for launchpad

[Brad Bollenbach]

On Sat, 2006-16-09 at 20:16 -0700, Corey Burger wrote:
> On 9/14/06, Jason Taylor <killerkiwi2005 at gmail.com> wrote:
> > Is there any plans for some kind of voting on launchpad specs/bugs ?
> >
> > The voting wouldn't have to be binding any way but would give some
> > indication of what general Ubuntu users would like to see implemented.
> >
> > Then maybe for each release the top 10 most voted specs should be considered
> > / with reasons given to community for not attempting
> >
> > Or maybe it would just end up in a massive popularity contest.....
> 
> Voting is a really bad idea, because then you end up with the insanity
> of large crowds. Basic voting is already sort of enabled on specs
> anyway, just look at the list of subscribers.
> 
> Cross=posting this to launchpad users, replies should go to that list.

The current approach we're implementing allows individual users to
"propose" that a bug be fixed for a previous or upcoming release. There
is no voting or aggregation. This carries the risk of everybody doing it
because they can, or nobody doing it, because they can't be bothered.
The only way we'll know for sure if this approach is good or bad is by
rolling it out.

There's also another approach that we've talked about, in developer
discussions, that I'll repeat here for the people who weren't in those
discussions.

There's a certain poetry to release management that, from what I've
learned over the last little while, is best expressed, not through
democracy (like voting), but through collective wisdom.

The question is, from the Malone perspective:

  What bugs should I care about for the next release?

Voting makes this process look democratic, but it's not. And, like
nominations, voting requires users to actually do this metawork.

The collective wisdom approach is to gather "observational metadata"
from bugs and come up with a score that tells you, the release manager,
how much you should care about this bug. Here's an example list of
attributes that can be examined about a bug, with an example 1-10
weighting of how each criteria could be weighted in the calculation of
the bug's "heat":

  * How many people care about it, i.e., subscribers (8)
  * How many times the bug's been reported, i.e., dupes (8)
  * How much the bug is being talked about, i.e., the comments (5)
  * Has somebody already got a fix for the bug?, i.e., a patch (6)
  * Does a developer say it's really important?, i.e., Importance (10)
  * Is the bug currently being worked on? i.e. In Progress (7)
  * Has this bug been around for a long time? (2)

and so forth. All other things being equal, a bug with five dupes and 12
subscribers is more interesting than a bug with no dupes and three
subscribers. What makes this interesting, IMHO, is:

  * We're tapping into collective intelligence to assess what matters
most. it takes the indirect input of multiple users (by subscribing to a
bug, inadvertently reporting a dupe, etc.) to draw attention to a bug,
rather than just one angry user.
  * It takes no extra effort from users
  * It's a system that's not easy to "game"

"Bug heat" is just an observation, of course. The final decisions about
what gets fixed remain with the decision makers. This score can also be
used as a sort order, just like Flickr allows you to sort photos by
"Most interesting".

Brad