[no subject]

Revamp our User Experience
============================

When talking with some great people at GUADEC about GNOME 3.0, one
concern that came more than once was that it would be an error to do
GNOME 3.0 without any big user-visible change. While some of us didn't
necessarily agree with this concern, it was still a fairly valid one.
But it turns out that if you tell the community that there's something
after 2.x, then the community will stop vaguely thinking about future
ideas and start working on concrete plans.

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

 - GNOME Shell [2]: 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, like GNOME
   Zeitgeist [3]): 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
   simply should.

These two ideas can form the basis of an overhauled GNOME user
experience; they are not the only changes that we can and will do, but
they definitely are the most advanced projects to help us move forward
in terms of user experience. The GNOME Shell and the GNOME Zeitgeist
projects are indeed already well underway, with working code and strong
development going on for nearly six months. This means the effort is not
about starting those projects, but about first completing them so that
people can work daily with them, and then polishing them.

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. However, it's worth noting that
distributors and other community members using GNOME to build enterprise
products will most certainly help maintain the GNOME 2.x shell for quite
some time, and the project will support that to the greatest reasonable
extent.


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;

 - include new exciting technologies that we're starting to see used in
   our desktop. Some obvious examples are 3D effects (with Clutter) and
   geolocalization (with GeoClue and libchamplain).

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

The work that has been done on GObject introspection [4] will also
deeply change the way GNOME development can be done; we've already
started to see how it can be leveraged in GNOME Shell, and the fact that
it can bring new popular languages like Javascript to GNOME is a huge
benefit.

All this has of course an impact on our applications: we will have to
port the code away from all deprecated APIs, but also prepare our
applications to be ready for forthcoming changes, like GTK+ 3.0. This is
luckily a task that we can easily quantify and the progress can be
tracked on a simple web page.


Promotion of GNOME
==================

Our community has historically been strong on the development side, but
we have always struggled to promote GNOME. That's because this is
certainly no easy task. Our user base has however grown significantly
since our project started, and we failed to recruit people that could
have helped here. GNOME 3.0 is an opportunity to change this and attract
contributors that can help forge the communication around the GNOME
project. The promotion of the project is definitely part of what makes a
good release, and the Marketing Team can contribute a lot to the success
of 3.0.

Of course, an obvious goal for the promotion of GNOME in this context
would be preparing the 3.0 release and the messaging around this
release. After highlighting the changes done specifically for 3.0, one
other immediate idea is to simply show the progress the GNOME project
has made since GNOME 2.0: GNOME 2.10 could arguably have been named 3.0
when compared to 2.0, and the same goes for 2.20. This could serve as a
basis for work on explaining why our evolutionary approach in
development works well.

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 use
applications. We've never explained why the applications developed for
GNOME are good; we've never really put those applications under the
spotlight. For instance, why shouldn't we put on the front page of the
GNOME website a clearly labeled message about a good music manager? We
wouldn't have to choose between Rhythmbox or Banshee: we can promote
both, since both are good in different ways, and both are good examples
of the GNOME experience.

This leads us to a third item: relaunch our website. While our current
website is known for being broken in various different ways from a
communication point of view, we've not been able to deliver the new
version that would fix things. Fixing the website is a large task, but
we should not give up on this: the GNOME website is a core part of the
GNOME identity, and we cannot ignore the current issues. This happened
because of lack of manpower, but the good news is that there are web
developers that are fond of GNOME and just don't know they can help the
project.

And the fact that web developers can play an important role is also
valid for all of our users. As of now, we are not really empowering
users to promote GNOME: what should a user do if he wanted to do so? We
all know how some viral communication can benefit a project like ours,
so the solution is simple: let's give ourselves a chance to make this
happen!


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 [5]: 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: a GTK+ Theming API hackfest was held in February, where 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.

 - People: the telepathy framework has nicely progressed over the last
   few years and it's offering great perspectives to integrate instant
   messaging, and more generally, interaction with people in other
   applications. With some focus, it could contribute to make GNOME a
   social desktop where you do not only work on documents, but where you
   also really interact with your friends.

 - Mobile: the GNOME Mobile platform was first introduced in GNOME 2.24,
   and it helped make our presence in the mobile world visible. A lot of
   the changes that are planned around the platform are of direct
   interest to the Mobile Team.


Organizing the Development
==========================

We need to define a clear timeline for the development, with a schedule
that will let us check that the development is on the right path. The
end goal is simple: we want to deliver GNOME 3.0 by the time of 2.30
release. This makes sense for various reasons: from a technical
perspective, the timing is good for the integration of new technologies
or projects (GNOME Shell, for example); from a messaging point of view,
the evolution from 2.30 to 3.0 is logical and easy to understand. It's
worth pointing out that if you compare GNOME 2.26 with GNOME 2.0, it's
actually quite surprising to see that we have still kept a 2.x version
numbering while we could be at 3.x, or even 4.x. Making GNOME 2.30 a 3.0
version is of course still an ambitious goal, but we can achieve it
thanks to what we learnt in the past.

The development methods we have adopted during GNOME 2.x are overall
good methods and the community has become used to them. For example,
contributors understand the reasons behind the freezes we have and try
their best to respect those freezes. This is not something that should
be changed because we now have an opportunity to try something else; on
the contrary, those methods will make our path to 3.0 easier. Some
regressions were pointed out during the past few cycles: those should
not be ignored and we believe part of the reasons why they happened is
that only a subpart of our community was trying to move forward, which
created some controversy; having a community-wide focus should limit
those controversies, and hence the regressions as felt by the community.

The six months cycle is now part of our culture and has an impact on the
free software ecosystem, with distributions basing their schedule on our
schedule. Trying to change this crucial element of our release
management, which works quite well, would certainly not help us in any
way. Therefore, we will keep six months-based schedules. But having
project-wide and long-term goals require some adaptation. GNOME 2.28
will not be an independent release or a destination in itself, but it
will be a logical step towards GNOME 2.30, and therefore GNOME 3.0.

Of course, we should be prepared to consider the fact that GNOME 2.30
might not be good enough for us to call it 3.0. All of our time-based
releases are also quality-based releases: if the QA Team feels a release
should be delayed, then it will be delayed. In the context of 3.0, this
is something that we should be ready to diagnose early on during the
2.29 development cycle and we should not be afraid of keeping GNOME 2.30
as 2.30 and waiting for GNOME 2.32 for the 3.0 release, for example.
That being said, we want the community to try as hard as possible to
make "GNOME 2.30 = GNOME 3.0" a success.

On a more general note, overlaying a long-term development cycle (3
years for example) with project-wide goals, on top of our six months
development schedules is something we want to keep after GNOME 3.0.


Conclusion
==========

You can already check out the schedule for the 2.27 and 2.29 development
cycles [6]: it contains some concrete steps and deadlines that will help
keep our work focused to make GNOME 3.0 a reality.

As already mentioned, this is an ambitious plan and it will only be
realized if everybody comes out and helps. Companies can contribute a
lot -- for instance, the GNOME Shell effort is doing great thanks to Red
Hat's involvement. But GNOME wouldn't even exist without all of the
volunteers who are passionate about the project. It's because this
passion is so strong that we can build such a plan!

We're getting there. We strongly believe that all this can make a good
plan for GNOME. Sure, it's not perfect. And there will be disagreements
and issues along the road. But it is the way forward.


The GNOME Release Team,


[1] http://live.gnome.org/RoadMap/Process
[2] http://live.gnome.org/GnomeShell
[3] http://live.gnome.org/GnomeZeitgeist
[4] http://live.gnome.org/GObjectIntrospection
[5] http://live.gnome.org/DesktopTesting
[6] http://live.gnome.org/TwoPointTwentyseven

-- 
Les gens heureux ne sont pas pressés.