On jeu., 2009-07-23 at 13:40 +0200, Vincenzo Ciancia wrote: > triggers the response that I am the only one reporting the bug, then > it's not affecting all users, hence it's low priority or even not a bug. > I think some of you reading will remember such a circumstance recently > :) (Perhaps not so) clearly this is wrong. Usability bugs typically > affect ALL users, but all of us need to go on and learn how to > circumvent those.
Things are often not as clear as you think, read the list of all the bugs users suggested as hundredpapercut for some example. The way you use your computer is often different from the one the next user will use and you will have conflicting opinions (some users think that switching workspace by scrolling mouse over the applet is efficient some other that the behavior is confusing, some will want confirmation to actions some other don't get why the computer should ask confirmation rather than just respect the user action, etc) There is several issues there: - the people working on packages and softwares are often good to do technical work but not so good when it comes to take decisions on usability or design - the usability issues reported often turn to long arguments between users not agreeing on the change and those issues are in the middle of clear technical bugs, it's difficult for usability people to list the usability concern and reciprocally a high number of usability suggestion makes the list of technical bugs harder to work with since you have to find a way to filter those you have no interest in - the distribution maintainers are not written most of the software distributed and don't always feel entitled to take design decision on the software without having it discussed with the upstream authors, they also don't always want to take the suggestion upstream because they have no strong opinion on the topic and don't feel they will argue for the change in a convincing way there That said we should perhaps have a different location where those suggestions can be discussed and moved to the bug tracker once a clear design change is approved (ie rather than adding ubuntu tasks to each hundredpapercut next time only add one for things which have been set to triaged and have clear suggestions which have been reviewed) > upstream. Guess what? Nobody cared to reply. I don't know if my comment > triggered any attention but clearly this issue is not considered > interesting enough to post a reply, even if it's present in ALL the > ubuntu installation. That's 100% of the users. Did you consider that only few people are working on this software during their after work hours and they can't just managed to deal with the flood of issues and suggestions sent their way? The issue there is no that "nobody cared" or that "the issue is no considered interesting enough", it's just than there is hundred of bugs open on this component and not enough people working on it to handle those correctly. Note also that bumping settings for bugs will not make a difference in the fact that the limitation is simply due to a lack on manpower to work on those. You seem to argue in favor of welcoming higher number of suggestions and bug reports, that's good but how does it solve this workload issue? What is the use of having thousand of good suggestion if nobody is working on making those happen and the quantity is just discourage the few volunter to have a look to the list because they know they can't deal with all those? Wouldn't it make sense to have a lower number of suggestions but focused on what would really make a difference in the user experience, a list that would be manageable for people doing the changes? Sebastien Bacher -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
