On Sat, 2006-16-09 at 20:16 -0700, Corey Burger wrote: > On 9/14/06, Jason Taylor <[EMAIL PROTECTED]> 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 -- launchpad-users mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/launchpad-users
