Re: [draft] Planning for GNOME 3.0

[Lucas Rocha <lucasr gnome org>]

Hi Vincent,

Looks great! Here goes another batch of comments (prefixed with COMMENT):

Let's first diverge a bit and discuss the lack of vision. If you look
closely at our community, it'd be wrong to say that people are

COMMENT: This sentence ("discuss the lack of vision") looks a bit
weird. Maybe something like "discuss the general impression that GNOME
lacks vision".

 lacking a vision; but the project as a whole does indeed have this
issue. What we are missing is people blessing one specific vision and
making it official, giving goals to the community so we can all work
together in the same direction. This is part of what the release team
should do, and although many of us weren't there, we believe this is
something that the release team did in the 2.0 days. The reason of why
the release team stopped doing this is simple: it just happened that
with our six months

COMMENT: maybe a comma after "happened that"?

development cycle, the big plans became less and less important
because everything (community, development process, etc.) was just
working very well. But we've now reached a point where our next steps
should be moving to another level, and those next steps require
important decisions. That's the job of the release team. Please note
that release team members don't have to be the ones who have the
vision; they "just" have to be the voice of the community.

COMMENT: maybe use "Release Team" instead "release team" all over the text?

(As a sidenote, the roadmap process that we tried to establish two
years ago was a first attempt to fix this. Unfortunately, it

COMMENT: link to http://live.gnome.org/RoadMap/Process

So let's go to the core topic and discuss what the GNOME 3.0 effort
should be. We propose the following list of areas to focus our efforts
on:

Note about how long-term goals are how we handle things now

COMMENT: leftover?

 - Evolution of the User Experience
 - Streamlining of the Platform
 - Promotion of GNOME

*Evolution of the User Experience*

COMMENT: the "Evolution" here makes me think of "Evolution" the
application :-P Maybe "User Experience Evolution"?

It seems pretty clear now that there are two important ideas that can
have a real positive impact on the user experience:

 - GNOME Shell: the shell idea is not just about changing the panel
and the window manager. It's about changing the way you start an
activity and how you switch between two different activities. Or more
generally, how you manage your different activities on the desktop.

 - Changing the way we access documents (via a journal): having to
deal with a filesystem in their daily work is not what makes users
happy -- on the contrary, they generally just want to access their
documents and not to browse their hard disk. Providing new solutions
to this problem (using timelines, tags, bookmarks, etc.) is something
that has been of interest in our community for a long time, but we
never completely jumped in. We simple should.

COMMENT: I think it would be good to remark here that those "ideas"
are already being implemented by some contributors (gnome-shell and
zeitgeist?).

There's one obvious question related to those potential changes: what
will happen to the old way of doing things? For example, will we still
make the GNOME Panel available if, for some reason, people are not
immediately happy with GNOME Shell? There's no obvious answer to this,
and this will have to be discussed. Some of us believe that it would
be a good thing to keep providing the old elements for a limited time,
to ease the migration. That being said, doing that would obviously
take some development resources and slow down work on what should be
the future. Not an easy choice, of course.

*Streamlining of the Platform*

Since GNOME 2.0 was released in 2002, there have been quite some
changes in our developer platform: new APIs have landed and some other
APIs have been deprecated. There are even some platform libraries that
are now nearly unused. This just creates some confusion and does not
make the life of developers easy. Since we want applications to be
developed for GNOME, this is an issue that we should fix.

Hence, it makes perfect sense to rework our platform and try to
clarify it for newcomers. Here are some steps that should be
considered:

 - move all of the deprecated libraries out of the platform, so people
stop using them in new code;
 - create a staging area in the platform for libraries that aim to be
in our platform but do not offer enough guarantees at the moment (like
GStreamer): this will send a clear message on what should be used;
 - rework the way we present the platform to also integrate some of
the external dependencies: while, say, D-Bus or Avahi are external
dependencies, they are definitely what we want developers to use. And
it's easy to be more explicit about this.
 - move the bindings closer to the platform when we talk about
bindings, to make them even more visible and attract developers from
all languages.

COMMENT: As noted by Luis, I think we should add a more exciting note
here: "welcome platform additions that allows GNOME to improve its
user experience and easily integrate with online services such as
location-awareness, 3d animations, web services integration, etc.".

One common issue that often came up when discussing how to promote
GNOME was that promoting the desktop as a whole is difficult. But
there's no need to do that. We can instead focus our messaging around
the GNOME experience: the basic GNOME experience simply is the GNOME
Shell; but users actually do not use just the basic desktop, and they
launch applications.

COMMENT: maybe "they use applications"? "launch" is a bit weird...

*Other Potential Areas*

The areas presented above are actually not a big surprise to anybody
following the GNOME development and are fairly obvious choices.
However there are other candidates that would help make GNOME 3.0 a
success. Those potential focus areas simply need people to step up so
we can be sure expectations can be met.

 - Desktop Testing: with the recent creation of the Desktop Testing
Team, this topic becomes more and more visible. We can innovate there,
and we actually should: we helped show the way in the free software
world when it comes to usability and accessibility, and there is no
reason for us not aiming at a similar experience for desktop testing.

 - Art: with the recent GTK+ Theming API hackfest, some good consensus
was reached on how theming should be done in the future. This gives us
a new opportunity for an updated look and feel. This can happen with
the help from artists: if we have artists and coders working together,
with the coders knowing the needs from artists, then there is no doubt
that the result will simply rock.

 - Mobile: the mobile team could do something if they want. Make the
mobile platform more attractive. Simplify the communication around it.

COMMENT: I'd add here "Online Services and Location awareness" as
potential areas.