|
Description
As we probably all agree, Brainstorm is great. It is a direct connection between users and developers to show what the majority of users thinks about the need of features in Ubuntu.
However, Brainstorm is only intended for broader, abstract feature requests and not for little details or bugs.
My suggestion is to add a feature to Launchpad that allows everybody with an account to click on a link or button on a bug report that reads "I am affected by this bug".
Then there could be some "Hall of shame" showing which bugs annoy the most people (maybe multiplied by the severity of the bug).
The rationale behind this is that I believe that users and developers often have different relations to bugs, for example technically more advanced people will adapt to certain bugs or do a quick workaround and forget about it while the average user won't know what to do about it.
A bug "hall of shame" would provide a quick overview which bugs affect the most people and should be fixed to ensure the happiness of the most Ubuntu users.
Tags:
(none)
Attachments
Duplicates
Comments
|
vexorian wrote on the 10 May 08 at 18:52
|
I really disagree.
Users are already terrible at determining what a priority feature addition is, which is evident in brainstorm.
Passing this method outside of feature requests is something I wouldn't want to see, specially not in something as important as bug reports.
|
|
jhoger wrote on the 10 May 08 at 19:09
|
+1,Innovative
vexorian, on the contrary, users are great at knowing how much a given bug impacts them. Severity and Priority are available in most bug trackers. Severity is typically defined by SQA. But I think Severity would be better defined by users.
Users of course don't determine Priority, that's for the developers. I don't think that's the idea here. Priority takes two inputs: Severity and available resources (budget,developers,etc.).
|
|
alex_mayorga wrote on the 10 May 08 at 21:03
|
Voted up, I've also linked the Launchpad bug.
I think this one is worth it if only to reduce the "me too" noise when you subscribe to a bug.
|
|
mlapaglia wrote on the 10 May 08 at 22:18
|
This is already done in part when developers look at the "subscribed list." I agree with alex_mayorga, the "me too" affect, while sincere from most users, doesn't help the process at all.
Maybe having a short survey for a paticular bug like "does this bug affect you everyday?", "On a scale from 1 to 10, how badly does this make your usage of the system/program/device?", and so on.
If we tied this in with jhoger's idea of making the priority dependent on two separate factors, each could keep the other in check.
To make this idea as effective as possible, a limit could be set on how many times a user could add "this effects me too" to a bug, persuading the user to select the biggest problems they are having, which would allow tim's idea of a "hall of shame" to hold bugs of the highest severity to every day usage.
If this was implemented correctly it could turn launchpad into a more efficient machine, and would allow Ubuntu (and any other project under launchpad) to knock out the biggest bugs affecting the most people.
|
|
Auzy wrote on the 11 May 08 at 05:43
|
I agree with vex on this one. How many of you guys haven't spammed friends with your brainstorm idea and told them to vote? Same thing will happen here. You'll be getting unimportant bugs getting fixed.
And some bugs are pretty much perfectly documented, and may be very easy to fix because you have enough details to kinda jump directly to the bug in the code, ie. "if []] crashes default SH interpretor in Ubuntu 8.04".
Users will be more likely to vote for shite broad bugs like "Azureus does not start" or "Firefox crashes alot".
Yet, the top bug, whilst it wont be voted by many people (because its wrong syntax anyway), would be a lot easier to fix.
And even worse, you need a good developer foundation to make a good OS (this is one reason why OSX is going on so strong, because Apple is SERIOUS about their development platform). But users all reckon "well, all developers can fix their own bugs, and there are more users then developers, so users ideas will take presidence, so bug reports which help developers dramatically, will never get voted as high, even if in the long run, they reduce bugs.
So -1. This is one of those great in theory ideas, that shouldn't happen. I would not object to it if it was automated for AUTOMATED crash reports though which send through the state of the app, and relevent details. The moment you get people involved and allow them to manually vote though, things really do fall apart.
And people will start complaining when the top voted bugs dont get fixed, but low voted ones do.
|
|
jhoger wrote on the 11 May 08 at 06:38
|
Auzy, there's a difference between getting your buddies to vote for an idea on brainstorm and trying to trick devs by screwing with the bug tracker. I don't think that would be a problem.
Now I don't think a BS style voting system would be perfect for bugs. But voting/moderation of some type would be very useful in setting Severity. Developers would still set Priority.
|
|
tim wrote on the 11 May 08 at 12:26
|
"Users are already terrible at determining what a priority feature addition is, which is evident in brainstorm."
Saying this somehow invalidates you own argument, don't you think?
"Users will be more likely to vote for shite broad bugs like "Azureus does not start" or "Firefox crashes alot"."
That's probably true, but where's the problem? How can you say that bug reports about an application not starting or an essential app crashing are "shite bugs". Sure, when there is no common denominator for a bug report like that it should be marked as "needs info", as it is now. But maybe there is really a bug that prevents Azureus to start for many people, and a bug that crashes Firefox for many users that teh devs don't know about.
Why shouldn't these bugs not get fixed? I really don't see your point.
If there are really nonsensical, incomplete or broad bug reports the they will be handled like they are now.
I realize that the idea is not perfect, but it provide additional value by showing the users interests in bugs and has no drawbacks because the devs aren't forced to do anything, it's just an additional indicator for them.
|
|
Auzy wrote on the 11 May 08 at 12:56
|
"Saying this somehow invalidates you own argument, don't you think?"
I somewhat agree with Vex.. The reality is, I've seen many ideas which were voted in totally opposite directions, over the way they are written.
Like if you had a bug report "Libflash.so 2.0 causes crashing on flash enabled pages", people are less likely to vote for it then "firefox intermittantly crashes", because the second means random crashes, the first means only certain pages. Yet, they could both be the same bug actually.
And furthermore, we have a better system in place. If you have the same problem, you could always attach the requested details to the same bug problem, so developers have more info to work off. Bugs with a lot more chatter, can be escalated. Votes don't help developers.. All it does is stress them to work on complicated bugs which take more work then 5 quick ones.
If you really want your bugs to be fixed sooner, help developers by nailing down the problem and trying different things. And anyone can learn C (I did it in grade 10 outside of school). And everyone has free time available, they just like to say they don't.
But votes, like I said, aren't always indicative of how important something is. After all, why should a system slowdown issue with a bluetooth joystick game pad for instance, that affects a thousand people, be fixed sooner then a kernel panic issue with a driver which only affects 100, but prevents them booting.
|
|
Auzy wrote on the 11 May 08 at 12:58
| |
so, btw, I do maintain a -1.. Everything in my brain really does suggest that the votes wont affect anything, but just aggravate users when bugs with 1000 votes don't get looked at quickly.
|
|
Auzy wrote on the 11 May 08 at 14:32
| |
Actually, do we have any actual Ubuntu developers here? They'd have a better idea what impact this will have.
|
|
miohtama wrote on the 11 May 08 at 16:29
|
Sun has done this with Java for a long time:
http://bugs.sun.com/top25_bugs.do;jsessionid=d8ce81c1c010ffd297db81bf8f1e
AFAIK it has actually affected to the development of Java and gets the message through when developers are being a bit elistic (sorry vexorian - are we making software for engineers or for users). Ubuntu is Linux for human beings. Should human beings be able to decide which is human for them?
|
|
jhoger wrote on the 11 May 08 at 16:31
|
Actually, Auzy this isn't an Ubuntu specific idea at all. This would work for any arbitrary tracker and project.
So any experienced developer will do (like me). But the more the merrier.
I'm a developer, and information from joe user about product issues are VERY WELCOME. I've been in this industry for a while, and I've seen the kind of junk users have to put up with. They are usually right to complain. Even when they cannot figure something out, it usually points up a usability issue.
Giving users a way to provide whatever level of feedback they are capable of would be helpful.
Also, think of this as a "safety valve" against users putting "me too" in the bug report comments. That actually does cause us devs a problem.
|
|
mlapaglia wrote on the 11 May 08 at 17:15
|
Auzy -
How about making a limit on how many bugs you could report, maybe a certain amount for every Ubuntu release, or every month, or year. This would limit each user from spamming everything their friends ask, because they know they have a set amount to work with?
Like I said before, this could be put into a mixture of things elevating a bug, such as a developer listing the importance (maybe having more sway in the equation as well.)
|
|
jhoger wrote on the 14 May 08 at 07:32
|
Devs always set priority. Even if there were no field in the bug tracker for priority they would still assume a priority mentally. When you have work to do you ALWAYS have to prioritize based on the various situations at hand.
No user comment or vote can force a dev to do anything.
The fact that it is nearly impossible to make paid engineers do something they don't want to do(i.e., something they believe doesn't make sense) pretty much sums it up. Sure they'll salute and say "Yes, Sir" but suddenly other priorities will come up or they'll find the design docs need to be rewritten or some dang thing... it essentially amounts to foot dragging. Well, it's more like they are training their manager to not be an idiot.
What makes the world go 'round is that good developers actually want to write useful software. That implies a user using it. Users, and only users can tell you whether a program is useful solution to a problem. We need more ideas, like this one, to give them ways to communicate Severity of bugs they must deal with.
Exactly the kind of thing we need.
|
Post your comment
|
Bug #149775