Re: Rules for design in Gnome
- From: Alberto Ruiz <aruiz gnome org>
- To: Seif Lotfy <seif lotfy com>
- Cc: Federico Mena Quintero <federico gnome org>, desktop-devel-list <desktop-devel-list gnome org>
- Subject: Re: Rules for design in Gnome
- Date: Tue, 24 Apr 2012 14:10:40 +0100
I would like to take a moment to make a reflection.
Maintainers only get to decide what's done in their modules back then when GNOME was organized in a maintainer centric fashion. However with 3.0 we have moved towards a model where yet another force is included in the decision making process, that is, the design team. So far they have done a huge amount of good quality work, GNOME 3.0 wouldn't be what it is without them and without this approach.
You don't find many open source communities where a pipeline for design driven development is implemented, in fact, very few companies implement this either. I think we should embrace this concept. I think giving ALL the decision making power to the maintainers is a bad idea, in fact I think it's harming to do so.
I can certainly understand that it may be risky to do things that way, we may alienate and harm the motivation of some people, but maintainers, as much as I respect and praise them for the work they do, should understand that they are trust are deposited onto them by the community to follow the community process, and if the community decides that they may not have the final word on everything, that's the way it should be.
I guess that all I am saying is just because we have been a maintainer/module centric development model doesn't mean we have to keep doing things that way, I want GNOME to be a design driven community, I think it's obvious what the benefits are by looking at the progress of GNOME Shell and the different applications that are being revamped by the design team. And I think that if we chose to, as a community, we can ask maintainers to trust the design team when it comes to design.
Now, that doesn't mean that a maintainer cannot challenge a design decision, but in the same way that challenging a maintainers implementation takes patches and a great deal of technical discussions, maintainers will have to learn to speak de language of the design team, and that takes time.
Of course, this design driven approach comes with a cost, and challenges may rise, but I think this should be a matter of consensus and discussion. I respect and I admire Federico, and I certainly understand why he is upset by some of the new problems that are arising. I think it would help a lot if the people involved in some of the problems he is experienced stepped up in a constructive and open manner, I think that most of the problem comes with the fact that some of the design members don't communicate much outside of certain circles. Yet, I don't think this thread had the best start in this regard :)
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]