Some notes on GNOME Shell

[Owen Taylor <otaylor redhat com>]

"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.