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 :) Disclosure: I've worked closely with most of the design team during the Font Dialog development and the Planet GNOME redesign, they were open, friendly, and VERY helpful at all stages, but at the end they allowed me to make my own decisions. 2012/4/24 Seif Lotfy <s...@lotfy.com> > OK first let us all please calm down (This does not apply to Emmanuele, > since he seems always calm :P) > > We all have the best intentions at heart. I think Federico knows exactly > that the design team has best intentions. And I hope the design team knows > that Federico has the same intentions. > > This thread sums up and shows the communication flaws between the design > team and some of us in the community. There must be a reason why this > E-mail was sent and it is not to flame or anger people. We are discussing a > problem here. We all agree that: > > - *No one is in charge. GNOME designers know they don't decide on > behalf of GNOME.* > - *We are trying to build a product here. * > > Yet how can we build a product if *some* developers don't feel attached to > what they are contributing to. Should those leave the community just > because they don't share the vision of the design team. > > If a designer designs a feature for an application, but the maintainer of > the app does not like it, who will implement it? And the other way round we > can not develop applications without designing them else no one will use > them and we will lose a developer base. > > There is a perception that GNOME design team are the ones decided the > direction. This perception did not come out of thin air and is not a > conspiracy. It is a communication problem. > > From my observation I think the design team cares more about building the > product and sometimes forgets about the community and the social capital of > GNOME. This might be based on the fact that *most* of the designers are > hired by companies. So if a maintainer doesn't want to implement their > designs they can rely on the financial capital to make it happen. > > This leads to some *developers feeling helpless about how to influence > the direction of GNOME* > * > * > Also some designs of applications are not done, and mostly are a revamp of > currently existing applications. Suggesting adding a feature to one of the > applications is the considered invalid because they don't fit the future > plans of the design (that might not be done). Can a developer add such a > feature without the design team getting upset? > > As someone who held a grudge for around 2 years against the design team, I > managed to somehow communicate with them in the last 6 months. And they are > awesome. Once the communication bridge opened I now understand them and > enjoy working with them ==> I trust their ideas. > > But I still see the how hard it is to get to them. It was not easy. So > communication efforts have to be done from both sides. > If designers expect developers to implement their ideas then they should > also tolerate and work around the fact that developers want to implement > their own ideas. > > Cheers > Seif > > On Tue, Apr 24, 2012 at 12:08 PM, Emmanuele Bassi <eba...@gmail.com>wrote: > >> hi Federico; >> >> I think this email is not at all warranted - and it generates more >> fuel for flames. >> >> On 24 April 2012 02:58, Federico Mena Quintero <feder...@gnome.org> >> wrote: >> > The design team IS welcome to: >> >> > The design team IS NOT welcome to: >> >> these elements contradict what you write below >> >> > * Second-guess maintainers or well-intentioned contributors. >> > >> > * Block development based on existing designs. >> > >> > * Block development based on incomplete or planned designs. >> > >> > * Veto development except in modules with branches that the design >> > team maintains. >> > >> > * Be dismissive of other people's own approaches to design. >> > >> > * Dismiss or handwave requests for clarification about decisions taken. >> >> here: >> >> > * Every decision is up for review. The state of the world changes, >> > not everyone shares your assumptions, and matters which seem settled >> > may need revision. >> >> so, if every decision is up for review, why shouldn't the people doing >> design second-guess or block? >> >> finally, and particularly, this is wrong: >> >> > * Assume that no one but them does design that is good for Gnome. >> >> if you're designing for Gnome, then *by definition* you are on the >> Gnome design team. >> >> if your designs are in conflict with what other people doing design >> are trying to achieve, then you should talk to them, and revise them >> and/or achieve a rough consensus on what is the direction to take. >> >> by the way, since we're dropping rules by fiat, and given that at >> least I'm empowered by the fact of having been elected on the >> Foundation's board, I think people on this list are welcome to assume >> that people mean well, and are NOT welcome to assume conspiracies or >> assume that people do stuff just because. >> >> ciao, >> Emmanuele. >> >> -- >> W: http://www.emmanuelebassi.name >> B: http://blogs.gnome.org/ebassi/ >> _______________________________________________ >> desktop-devel-list mailing list >> desktop-devel-list@gnome.org >> http://mail.gnome.org/mailman/listinfo/desktop-devel-list >> > > > _______________________________________________ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > -- Cheers, Alberto Ruiz
_______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
