Adding tags and voting on bug reports

Second.

I dreamed of this for a long time. In my opinion, one should take an ubuntu laptop and a laptop with a different OS/environment (e.g. suse, windows, osx), and take note of all embarassing bugs (e.g. no ability to work with cabled networks without dhcp, if one has no admin rights, printers setup not working, user switching not working in the first desktop OS having multi-user etc.). Then a voting system would prioritize the bug list and we all will know that, fixing the bugs reported there, we will have an OS that reacts as expected to usual tasks. There will always be tons of specific bugs, but you won't have a "strange" desktop where some every-day operations such as connecting to pay-per-time dsl require the Scary MS-DOS-alike Terminal Window to be executed.

You can already tag bugs, we just need the voting system. We need a voting system which normalizes among all voters, so that if one just wants a cosmetic fix and gives a high vote to that, it won't work.

A note for whatever developer reads this: the number of bug reporters which are not ubuntu developers nor members of the QA-team suggests that ubuntu unconsciously carried out a revolution: tons of users who really want to help the developers by reporting errors. Let them vote for the bugs, give them decision power. In a couple of years I bet you'll think how did you work without such an help.

A voting system can be implemented outside launchpad, even tough we need a way to authenticate within launchpad itself, but I can think of a couple of ways. Once we have at least a certain number of votes to avoid false alarms, we can just start sending a monthly reminder to the development mailing list, containing the top 10 voted bugs, and the top 10 bugs tagged with embarrassing.

First proposal, not perfect but better than nothing:

To implement a voting system, you just need a bug open on LP, where any comment containing just, say, "please fix bug #NNNNN" will count as a vote. This way you'll get LP authentication on votes. You just need to fetch this page monthly with a script, count votes, remove duplicates and votes for closed bugs, and gather stats, weighting votes as you please (e.g. assigning a maximum overall weight to each user), then send an e-mail to ubuntu devel with a link to the stats gathering procedure, and the list of bugs.

To comment on the page, you can provide an automated script and, say, a firefox plugin which alters LP to show a "vote for this bug" link.

Only problem is that the page would grow until unusable. To solve this, each month, you'd have to open a new bug, close the old one, providing a link to next in a comment. Title of the bug would be the key to find current bug voting place (e.g. "Bug votes for month 09/2007") and, again, automation could be obtained by client-side support.

Sorry if this idea annoys anyone, just comment here and explain why not then.

Second proposal: just add a voting system to LP. This needs LP developers.

The "embarassing" tag now in use is great, I think the second bug with it deserves its tag well, too (language pack problem). We just need to take care that if someone adds the tag just to get attention, tags are removed sometimes too.

The other ideas are also nice, currently the only "vote" thing is the number of duplicate bugs...

Does anybody have any data/research that would suggest that voting like this would help much? It sounds nice and all but I'm not sure that we'd gain much from it.
I'm fairly certain that the bottleneck is mostly in finding people to actually fix the bug than deciding if we should fix it in the first place. It also seems like it might frustrate users more when there is a bug that has a lot of votes but doesn't get fixed right away (for whatever reason).
The only real benifit I see is a psychological one where letting users "vent" in a constructive way helps them feel like they are contributing and it might lower the "me too" noise on the actual bug report.

IMO, I don't think squeaky wheel is a good way of prioritizing bugs. Votes are just another (highly biased) statistic and are used both by users to add weight to 'this is important' and by developers to add weight to 'but not as important as this' arguments, but not actually used in decision making because everyone is aware how biased it is. I think they create friction and would hinder correct prioritization of bugs based on actual needs of the Ubuntu user base and interests of the volunteers spending time on fixing things, instead of the opinions of the minority and highly skewed demographic who would would vote.

I do think some sort of 'me too' counter would be useful to allow developers to gage roughly how many users a bug is annoying.

(I am not an Ubuntu developer, so weight this opinion accordingly :-) )

I see a benefit as an advice to developers. If tons of people are requesting a fix for a bug that has been judged minor, maybe this bug is affecting usability. However, I don't see why a minority of people would vote. Just add a parallel "importance" tag, which is weighted so that it becomes relative to other bugs, instead of absolute as the current importance mark.

I agree to the current state of things where users can't set priority, since a bug marked as high will be "as high as" every other important bug in ubuntu, even if an unexperienced user just thought it to be so. But if you weight votes, you shift decision power to whoever can set importance now (and notice it's not who is going to fix the bug) to everybody. If importance could be set only by the assignee of a bug, I would agree with you, we cannot dictate on developers work. But priority is set by the qa team. Why not make everybody the qa team? It works in many applications. Why do you expect the majority of users to be so ignorant not to understand the difference between a showstopper, and a cosmetic fix?

I personally reported tons of bugs, there are 4-5 that I consider embarrasing, and that urge to be fixed. Not all of mine, just 4-5. Because I want to be able to advice ubuntu to people (to solve bug #1) and want to be sure it will work for them, better than their current OS. If their OS can connect to pay-per-time DSL, and ubuntu needs me to remember to teach them the correct commands, there's no competition.

So, a way for users to signal common problems they encounter when adopting ubuntu, or offering ubuntu to somebody else, would shift the perspective from a mainly developer-focused point of view, to a wider, intrinsical definition of usability problem.

On Sat, 2007-10-06 at 14:53 +0000, Timo Jyrinki wrote:
> The "embarassing" tag now in use is great, I think the second bug with
> it deserves its tag well, too (language pack problem). We just need to
> take care that if someone adds the tag just to get attention, tags are
> removed sometimes too.
>
> The other ideas are also nice, currently the only "vote" thing is the
> number of duplicate bugs...
>

The tags are fine, but as you pointed out, the tags might be misused.
Tagging will only be immune to misuse, if it is combined with a
voting/weighting system. The feature MUST NOT require any moderation by
a SUPERUSER as this process should be solely user driven.

Also as mentioned earlier, opening an extra bug report just for voting
defeats the purpose of the idea. The idea is to make it dead-simple for
users to express how embarrassing they find a bug.

HOW is the keyword here. I propose to implement this just like you rate
a video on youtube, just that you don't set how good you find the thing,
but how embarrassing.

Such a voting system could also be used for other attributes, I just
can't think of any that would make sense from the top of my head. Maybe
it could be used in other parts of LP. I could imagine voting on
blueprints or bugs that are actually feature requests like this one!

I totally agree with elias. A simple voting system like Youtube would be easy to implement and launchpad would benefit A LOT of this new functionality. Developpers would easily know which bugs affects a lot of people and could consider this important criterion when assigning bug priorities.

If someone want to work on this, I made a blueprint for launchpad :

https://blueprints.edge.launchpad.net/malone/+spec/vote-system

I have seen voting in other bug tracking systems and experience says it does not work. This issue actually popped up on the mailing lists a while back - https://lists.ubuntu.com/archives/ubuntu-devel/2006-April/017425.html .

I agree to that too.

We must not mix up vote system and priority in a bug tracking system, the vote must be independent from the priority of the bug. The vote is a clue which will help people to gather around priorities but the vote isn't the priority itself. I continue to think that if this idea is correctly implemented in launchpad, it will gives great benefit for the community.

Vote system can help tracking which blueprint are in demand, which bugs affects a lot of users. It can also help by reducing noise in launchpad.

But maybe I'm wrong, it's my actual opinion :)

On Sat, 2007-10-13 at 12:39 +0000, Saïvann Carignan wrote:
> I agree to that too.
>
> We must not mix up vote system and priority in a bug tracking system,
> the vote must be independent from the priority of the bug. The vote is a
> clue which will help people to gather around priorities but the vote
> isn't the priority itself. I continue to think that if this idea is
> correctly implemented in launchpad, it will gives great benefit for the
> community.
>
> Vote system can help tracking which blueprint are in demand, which bugs
> affects a lot of users. It can also help by reducing noise in launchpad.
>
> But maybe I'm wrong, it's my actual opinion :)
>

Exactly, the voting/rating does not need to have any effect on
prioritization. The priority would still be set by whoever does it now.
It is just an additional source of information for the guys who maintain
the queue of open bugs. It will be easier for them to decide which bug
is of public interest and which is not.

The same applies to blueprints. If in case Canonical or other party
wants to fund some development it would be more easy for them to decide
which one will have great community resonance.

As Jordan said, if only in the hopes of
> lower the "me too" noise on the actual bug report.
this bug is worth fixing.

Bugzilla does have votes and even if the vote is all I can contribute at a given skill level it feels nice that I can give input in the problem.

If one happens to subscribe to a popular bug, that as far as I know is the way to "vote" as of now, it gets "spammy" real soon with all the "me toos" and it is a bit of an annoyance.

To curtail "abuses" the number of votes could be limited to say 50 or 100 vote points that they could move around between a number of bugs; that way any given user would be also able to prioritize on the bugs that impact them.

I think this one should be confirmed.

I ended up here via this Brainstorm idea http://brainstorm.ubuntu.com/idea/8338

Whenever you have voting people will assume that the outcome must have influence. People will think that so long as a bug is voted on enough its priority will rise until it must be fixed which need not be the case (popular bugs can remain open for a long time). This just creates angst and people go on and say "How come this bug with 500 votes hasn't been fixed? Bug XYZ has less votes so you should be fixing this one." If a low priority bug has a high number of votes people will become extremely angry. Trying to shame people into doing things (especially if they are not being paid) is a dicey business.

Il giorno dom, 11/05/2008 alle 09.48 +0000, Sitsofe Wheeler ha scritto:
> People will think that so long as a bug is voted on enough
> its priority will rise until it must be fixed which need not be the
> case
> (popular bugs can remain open for a long time). This just creates
> angst [...]

Also seeing that a bug has been marked low priority by a too quick
analysis, and this bug blocks the everyday workflow of a lot of people,
and that is taking users away from your favourite distribution that you
took ages to convince them to test (and see bug #1) creates angst :) Not
that I have a solution. There are even worse things, such as
functionality being removed without discussion because "nobody needs
that" and then a bug opened to request the feature back being pushed
down the queue.. and many other cases where it usually is impossible to
draw developers attention to a case - "if it's been already triaged I
don't need to look at it...". Voting would be needed for these cases,
that should not exist at all in principle but are there in front of us.

Vincenzo

I filed a duplicate (didn't find this bug then) and here is the same comment copy-pasted

The users cannot give feedback which are the bugs most critical for them. Advocacy comments doesn't seem to do any good.

Example case 1: https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/59695

Example case 2: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/221673

This leads to the user frustration when the developers are seen as elitistic bastards who are motivated by sole technology interest and not human concerns.

Ubuntu should follow its philosophy "Linux for human beings" and at least create an illusion that the users can express their concern and the developers and the users are part of the same community. The easiest way for this would be bug voting.

I file this as an bug since what we have here is an failure to communicate between the users and the core community. Please let's up end up like Mozilla Bugzilla which has bugs open > 5 years with hundreds of frustrated comments.

Java has done it ~10 years now:

http://bugs.sun.com/top25_bugs.do

See brainstorm idea:

http://brainstorm.ubuntu.com/idea/8338/

We are not trying to embrass anything here. We just want to have a channel (one besides the frustrated comment) for people to give feedback. In the dream scenario if the bug has 500 votes it won't be any more low priority, because the community now perceives this as a problem.

As Jordan Mantha mentions the problem is actually find a developer. This would be an excellent way to have a map where a little fix can make very many people happy and the community could direct the scarce developer resource better. There are lots of students etc. hobbyist who are ready to tackle problems and ofter ask on the mailing list "what could I do?"

@Sitsofe Wheeler: In your alternative world the developers don't need to hear from the users and they live in their own happy bubble. The truth is that 90% feedback is negative and people just must accept this fact - you learn to live with it when you get a lot of feedback. That's why scandal and accident news sell well. Since we already have seen that popular bugs to lead a comment flood (and a lot of extra subscriptions and more comments "why I am getting all this shit") the voting system would be actually a better solution for this problem.

Mikko:
Youch. I don't think I was advising the "happy bubble". I think my point is far more nuanced (if you do this you'll create a placebo)...

Regrading bugs not getting enough attention - I'm afraid that's what happens when there aren't the resources to fix them all and believe me my bugs will always seem important to me. Subscriptions are interesting because it requires real determination to stay on in bugs that get huge numbers of comments and in fact leads one to only comment when necessary (but this only happens if you have seen the process before). A subscription requires a certain level of commitment.

What is really needed are more good advocates who really know the system and highlight only a few issues that are important and are being overlooked. I don't believe voting is that advocate as it doesn't learn and is guided only by popularity but this is an opinion.

I think that the first thing a new contributor want to do is to show is opinion. There's actually no way to do this without making pollution in launchpad, so a lot of potential contributors are probably afraid because launchpad looks complicate and they don't know where to start.

1. It will give the opportunity to new contributors to start contributing, and invite them to learn more but at least they will be able to start somewhere. Since they will feel at a first glance that ubuntu is democratic, they will not be shy to start working with the community.
2. It will avoid a lot of pollution in launchpad.
3. It will helps developers knowing which bugs are a problem for a lot of users.

launchpad beta release 2.1.9 (r7102) now include a pre-functionnality named "Does this bug affect you?", which is exactly what this bug report stands for so this bug might be closed in a short time. Outside of this, feature request like this one should now be posted to brainstorm.ubuntu.com rather than launchpad so developers can review and discuss good ideas. Since this is a feature request more than a bug report, I set the status to invalid. Thanks for the constructive discussion.

> launchpad beta release 2.1.9 (r7102) now include a pre-functionnality named "Does this bug affect you?"

This is great news, however, I just clicked this field on a bug and
kind of felt like sending my heart to /dev/null:
Is that data collected, evaluated, vizualized any where?

> Is that data collected, evaluated, vizualized any where?

Yes, for example:
  http://qa.ubuntu.com/reports/launchpad-database/bugs-with-most-users-affected.html

Bryce: the numbers clearly show two things in my opinion:

1) the bugs on top of the list are effectively important bugs, people is not "voting" randomly. Bug count seems better than vote, even is technically it is the same thing. So it may be worth to try to start fixing bugs based on that chart, if point 2 below is addressed;

2) too few people is stating which bugs do they have. We need to encourage "me too" clicking a lot, e.g. by putting an invitation _not to post_ "me too" comments but rather click on the me too link, above the "Add comment/attachment" box, and making the "me too" link big and visible.

One could also try to gather specifically this "me too" counts by periodically proposing, *only* in the testing distribution, (e.g. changing the firefox start page in some special bug days) a short list of bugs, taken from the packages the user is using, randomly sampled among the open bugs, with a distribution that makes the choice more likely, the more "noise" is on the bug (some value computed from comments, duplicates, subscribers).