"The secret master plan" Boy do I wish I had a secret master plan tucked in a drawer somewhere! It would be really useful....
To the extent we have a master plan, it's in two documents that everybody has seen: http://www.gnome.org/~mccann/shell/design/GNOME_Shell-20091114.pdf http://live.gnome.org/GnomeShell/RoadmapTwoThirtyOne "The Red Hat cabal" The practical structure of the GNOME Shell project dual (benevolent) dictatorship - I'm the dictator for technical decisions, Jon is the dictator for design decisions. That's pretty much like every other GNOME module - someone has to make the decision in the end, and a lot of decisions are pretty much arbitrary. Are we going to depend on the development version of glib and GSettings for 2.31.3 or are we going to wait until 2.31.4? For more interesting decisions, influence is strictly a function of involvement. Creating patches, talking to us on IRC, coming up with solutions for problems we are having, and so forth. If you are doing work, you'll have a say. On the technical side, there are non-Red-Hatters with enormous influence because they are doing enormous amounts of work. As of yet, the number of people with that influence on the design side is small. But that's nothing fundamental - we would certainly welcome more help with open arms. (What has been a challenge is figuring out how to create the stepping stones to getting involved *productively* in design; we have tons of people coming up with ideas. But you can't implement 50 conflicting ideas.) "A corporate driven project" The defining characteristic of a corporate driven project is that what gets accepted or what doesn't is a factor of what's good for the corporation. I don't see that this is the case for GNOME Shell. The goal of Red Hat's involvement in the shell is a really great *upstream* version of GNOME. GNOME 3 with a great user interface out of the box. And we've always tried to make this a great collaboration between all the GNOME contributors including all the companies. That's the way it began at the GNOME design hackfest in 2008, and if since then certain companies have gone off and done their own thing, that's not because we haven't solicited their help. GNOME Shell is on the other hand a _driven_ project. We've always had an end-goal of GNOME 3; we haven't generally wanted to accept patches just because they exist. And it has a heavy review process. We do a *lot* of code review. I think that pays off in quality code and having a culture where the contributors are on the same page. But it does mean that sometimes patches languish waiting for review - code review is probably 30-40% of the work of the project. In other words, if you can't get a patch into GNOME Shell quickly, that doesn't mean that "the man" (or Red Hat) has it against you. (That being said, the unreviewed queue has typically been around 10-20 unreviewed patches while hundreds of patches do go in each month.) Zeitgeist Since at least last fall it's been very clear what the requirements are for Zeitgeist as part of GNOME 3. Not a framework that you can build multiple ideas on top of. Not something that's going to work on multiple desktop environments. Not an activity journal that is disconnected from the rest of the GNOME experience. For Zeitgeist to be part of the GNOME 3 experience, the GNOME 3 experience with files had to be defined. And then you can consider how a daemon like Zeitgeist might be a useful tool for building that. I feel pretty terrible that we weren't able to incorporate the work that Siegfried Gevatter did last summer as part of a the SOC. But in the end, without a UI plan, it was just extra complexity without a point for users.... we had to come up with the time to create a UI plan. That didn't happen until a few months ago, while it should have happened *before* the SOC project started. Our fault. "Technical boards" The day we have technical boards that are saying what can and can't go into individual modules is the day we lose GNOME. Technical decisions need to be made by the people that have a stake in the issue. Not by people who come in, spend an hour hearing about something for the first time, and then lay down the law. GNOME works to the extent that its members talk together; bring people over to their positions; actively work to create a consensus. If you have a valid point, you will be able to convince people of it. If we have massive disagreements going on between module maintainers (something I haven't seen for many years), there may be need for mediation - for getting people to talk. But that needs to be strictly *non-technical* mediation. And can be handled by the release team or the Foundation board as necessary. _______________________________________________ foundation-list mailing list foundation-list@gnome.org http://mail.gnome.org/mailman/listinfo/foundation-list
