Re: Sorry State

Hi !

I really don't have a strong experience in the Open source community
(been here only a few months), but I must agree with Evandro.

> Ubuntu has also done some changes in the panel, like the 'Add to Panel'
> dialog. From what I remember this was first done in Ubuntu and after a
> release using that configuration discussion started on the usability
> list. Another example is the log out dialog on the right top corner of
> the screen in Dapper, which wasn't proposed for discussion on
>, it was just implemented there when GNOME uses the window
> selector for the top right corner.

Thanks for those two examples, I happen to be the one who made both :)

I remember asking myself this question before I made some changes in
Ubuntu : since I was a beginner, I wanted to get some advice from
upstream, write real specs with the help of other experienced desktop
designers, in order to have a strong background before actually begin my
coding. In order to get a new feature written in a spec (for example), I
wrote dozens of emails defending my point of view, trying to get this
feature in. I really tried this way very seriously, but it just took too
much time, and eventually I had to code stuff on my own, while still
asking the community's advice regularly.

Discussing possible new features always lead to rising very deep
problems, everybody tells his opinion (that's great), nobody agrees, and
in the end nothing is done (I have actually experienced that and got
frustrated). So I dropped it and did it my way : yes, it is the lazy
way, I agree, but if I have only two months, I prefer spending them
coding than discussing and not doing anything eventually [1]. The best
way to do this would be, of course, to take the time to discuss and
reach something most people agree with. But time is often a scarce

I'm not saying taking our time to discuss changes is wrong (of course
not). But sometimes I just need to try something out. If there's a new
feature proposal, and some developers find it is a bad idea, but it
basically looks like a nice thing to try, then just let the guy code it,
make it better, and then let everyone actually try it.

When I first made the "add to panel" dialog, most people were against it
(finding the current one was better), so I just worked on my own, while
still keeping in touch, to tell people what I was doing (and commenting
on blogs saying that my dialog sucked to give my point of view and tell
what I was doing next). I hope this was the right way to do things. And
when my stuff was actually released, people started to discuss about it.
That's my point : the best way *would* be to discuss together *before*
coding, but most of the time this cannot be done, and the best take is
to let people do according to what they think is right, and then
thinking about including the result in the mainstream, or not.

Again, I really don't have much experience here and I'm certainly not
the one who could tell that Novell's way is good or bad (and my little
dialogs are nothing compared to their changes), but I just thought I'd
share what I felt back then.


[1] My time was precious back then because I was part of Google's
"Summer of Code" program, and I had to get results in two months of
time, including learning everything I needed about GNOME and GTK+. I
believe this time constraint exists in lots of other cases, too.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]