Sep 092010
 

These days I often have a hard time to keep up with the tasks on my TODO lists, but I do manage to sneak in a spare hour here or there to look into code I authored sometime ago and that’s waiting for maintenance attention. For projects like Gtk+/GLib it’s incredibly hard to figure a good start and order for bug processing if time is sparse and the number of bugs is flooding you.

Other projects on the net use issue trackers that support user voting of individual requests, here are two examples:

Of course I do realize that we have priority and severity fields in GNOME Bugzilla, but those are for a different purpose than polling the public opinion on which bugs should be fixed best/next, or which bugs have the largest pain impact on our user base.

At least for me, a publicly open voting system for GNOME Bugs would be immensely useful to judge where it’s best to concentrate my development efforts.

Tweet about this on TwitterShare on Google+Share on LinkedInShare on FacebookFlattr the authorBuffer this pageShare on RedditDigg thisShare on VKShare on YummlyPin on PinterestShare on StumbleUponShare on TumblrPrint this pageEmail this to someone

  15 Responses to “09.09.2010 Request to support voting in GNOME Bugzilla”

  1. launchpad has “affects XX people” and you can add yourself to that =)

  2. You have the CC, counting the ammount of people on CC you have a sense of priority I would say.

    • No, CC is for people who are willing to actively participate in the bug resolution process. You cannot sort by CC counts and it cannot be used for *public* polling. Take a look at other Bug trackers on the net, interesting bugs have very high votes, but not CC lists.

  3. What about using Flattr for this? It would be great to make a plugin to integrate Bugzilla with Flattr 🙂

    Disclaimer: it seems I’m not the first one with a similar idea! ( http://identi.ca/notice/46175489 )

  4. Amount of duplicates is half of a workaroind, but I wouldn’t want to advertise it. 🙂
    https://bugzilla.gnome.org/duplicates.cgi?product=gtk%2B&openonly=1

  5. Flattr sounds like a cool idea to create some funding, but I’m afraid that as soon as money is involved, people would feel ripped off if a bug or enhancement request with many Flattr hits gets ignored. That may result in quite a lot of pressure on developers, who may have other priorities.

  6. Yeah,

    The current problem is that you can not search bugs for numbers of CC’s and GNOME Bugzilla doesn’t have votes. So the maintainers can’t know what are the bugs that affects more people.

    So I think the vote system is the less evil solution. Other posibility would be a vote system where only the maintainer can know the number of votes of each bug.

  7. Very much needed feature indeed. I like also the idea of flattr, but it should be lower-priority.

  8. “Take a look at other Bug trackers on the net, interesting bugs have very high votes, but not CC lists.” — Tim Janik

    Like at google code where “staring an issue” implies CCing it.

  9. The Flattr money should only be paid out when the bug is fixed.

  10. The reason why GNOME disabled votes is that votes are of no importance to usual development, plus it’s too easy to stuff them (by eg posting a link to lwn, slashdot or even a blog). Also, I fear this would end up being as useful as http://brainstorm.ubuntu.com/

  11. The reason why GNOME disabled votes is that votes are of no importance to usual development

    And you don’t find worrying the fact that the voice of users is actively ignored in the development?

    What I do is what I think every sensible developer should do, I take into consideration how many people have voted, then I make my own mind based on the priorities of the project. Then, I set the priority for the bug, and clearly communicate what are the plans regarding it. Sometimes it mean saying; sorry, this is too difficult to implement, it won’t be done any time soon, however it is important, therefore we’ll try to fix this by milestone X.

    Having the number of votes clearly visible at least helps to avoid important bugs gathering dust, like having no feedback from months, even though any developer could have taken 10 seconds to look at it and say; “Please attach a back-trace, see how [here]”.

    All the reasons given by GNOME people are easily debunkable, and mostly based on wrong assumptions. They should at least give it a try a few months, only *then* then can say with confidence what are the effects of having this. In the meantime it’s just speculation.

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>