Il 23/07/2009 15:28, Sebastien Bacher ha scritto: > On jeu., 2009-07-23 at 13:40 +0200, Vincenzo Ciancia wrote:
I agree with the issues you raise. Let me see if I can even be propositive. > 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) > Fact 1: need for an authority, and maybe a democratic one ========================================================= From the above, I'd say that we need an authority to decide that we will not scroll on the destko^H ahem, to put an end to endless discussion. What I would like to see is turning endless discussion into creative and constructive force. I would consider the ubuntu usability team(s) but in my dreams of democracy I would also love some sort of a "popular jury" that can influence in some way the authority. Also because I am not going to become an ubuntu developer for lack of time :) But most important, because democracy will mean less "dictatorship feeling" hence less endless discussions. What importance to give to the democratic part (from 0 to 100% of the decision power) and how to select people (perhaps from the team of proposal 1 below) does not belong to me. But there is an obvious problem: how can one be sure that decisions will be accepted? Example: I myself endlessly discussed the pop-up of update notifier. I still hate the idea but in the end I had to accept the authority princple like everyone else. Here comes a proposal Proposal 1: a new code of conduct for develpers and bug reporters, and a new team ========== Let us design all together a new code of conduct, and create a new team. The team will have a set of bugs (assigned? separate bug tracker? just a tag? too early to say this) on which they discuss and work. The team will not have decision powers by itself (that's the authority which is a separate concern) and the condition to enter the team will be only to sign the code of conduct. The code of conduct shall be oriented to principles such as - no endless discussions, but try to accept a reached agreement even if you are not pleased by that (I am one of the biggest culprits here :)). - no underestimation of the person reporting the bug or discussing. Members of the team are supposed to know what usability is, so if at a first glance it seems they are saying something stupid, perhaps a second look is needed. Acting like the person is a newbie who needs technical explanations about why the behaviour is that way will only create endless discussions. - trying to identify common guidelines, as if all bugs reported were also in the whole ubuntu. E.g. it *should* not make sense to decide, in the same team, that rhythmbox will quit when one window is closed and banshee will not (sorry if the example is related to bad memories <g>), even if the argument "we will not go against upstream developers" may in the end be adopted in corner cases. Consistency of the desktop will be a good argument to avoid endless discussions. - whatever you like > 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 Therefore the decisions may be taken by somebody else as I suppose it is already happening in ubuntu > - 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 Therefore it is worth to create a separate place for discussion among those interested in usability, as you note below > - 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 is out of scope IMHO; I don't have a clear vision on who should talk to upstream and on when it's just better to leave things as they are. > 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) > That would be lovely. >> 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. Agreed and also: > 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. agreed and also: > > 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? > agreed, so Fact 2: lack of manpower ======================== we need manpower to fix bugs Proposal 2: mentoring as a driving force ======================================== Suppose I had good coding skills, and wanted to try to fix simple usability bugs. Then I apt-get source the package, start hacking, and get lost. That's because I don't know e.g. the huge gnome architecture. Therefore, I try to delegate to the gnome developers. But they have something better to do. But I can't do anything, since I can't find my way in the code. In the past, I tried sometimes (you were on both the bugs I can remember of) to ask for suggestions about the code *on* the bug report, in the hope that expert gnome developers were reading and could give advice. But it just did not happen. Instead of trying to guess the reason, I would suggest that we give a much more prominent role to mentoring! So let us consider the eventual discussion forum about usability that I mention above, where all the member sign the relevant code of counduct. I would expect many developers to be part of the forum for the sole purpose of doing some quick mentoring. Part of the code of conduct should then say - no impatience w.r.t. mentoring: you may get a very rough suggestion, put your hands in the code, find that you need more help, ask for it and receive it after 6 months. This is unavoidable. But if we all put our manpower under the direction of skilled, but busy, developers, we will gain skills ourselves. For me, the complexity of gnome is really a barrier. With a little bit of advice I could try to fix problems myself and then would learn more about gnome, and then one day start advicing and so on. But not in the next month, because today I received news that will stick me to my chair to do my "real" job on something not so easy :( Vincenzo -- 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
