Re: GNOME 3.2 ideas and plans

Frederic Peters wrote:
> Allan Day wrote:
> > Matthias Clasen wrote: 
> > > With GNOME 3.0 going into code freeze any day now, it is high time
> > > that we start looking beyond 3.0 and start collecting ideas and making
> > > plans for what comes next. To that end, I have collected a list of
> > > things that have fallen off the 3.0 train at one point or another, as
> > > well as some other things that might be nice to put on the roadmap.
> > > Some of these have designs and/or working implementations, others or
> > > just ideas.
> > > 
> > > I'd like to encourage everybody to chime in with their own ideas and
> > > plans for GNOME 3.2.
> > 
> > Thanks for starting this thread, Matthias. I totally agree with the
> > priorities you've set out.
> Thanks Alan too.
> > I'd also like to see us concentrate on the design quality of our core
> > applications. There are already designs in the repository [1] for some
> > of these, including EoG, the calculator and Empathy. There are others
> > that still need some design love.
> > 
> > Nautilus was a success story this last cycle. The UI roadmap [2] process
> > that we used there seemed to work really well: perhaps designers and
> > developers could sit down at the beginning of the cycle and draw up UI
> > roadmaps for other applications?
> It would be excellent; "if you don't blog about it, it didn't happen",
> and it has been so true with the gnome-design repository, we need to
> publicize the designs and this will get new contributors on board, I
> am really fond of the GNOME Voice Recorder design by Hylke, he blogged
> about it[1], and two weeks later someone had started implementing it
> and posted on the gnome-multimedia.

Blogging is definitely part of the solution. So are conversations
between designers and developers. That was what moved us forward with
Nautilus: we hashed out the details, made compromises, came up with a
plan. A lot of the credit for that should go to Cosimo.

> During the 3.0 cycle the marketing and design teams were fantastic,
> but they are only now appearing in our schedule and processes
> (defining the "featured apps", for example)
> Just like we integrated older teams (e.g. the string freezes for the
> translators, or consulting the documentation team about new modules),
> there are certainly things to do here; you wrote it above, here it
> is again:
> > perhaps designers and developers could sit down at the beginning of
> > the cycle and draw up UI roadmaps for other applications?
> Not just because we are in the mood for 3.0, but for future versions
> too, having that part written down in a schedule makes it important.
> This is definitely something I find important, I'd like to take time
> to hear ideas from all teams, and shake it out.
> A direction is that Fedora has "features", Ubuntu has "blueprints",
> and we could do as well, thinking things up for the whole GNOME, not
> delimited by modules.
> A good example is our Sharing story, in the words of Matthias:
>   > - Sharing: We have rygel, and gnome-user-share, and vino but no
>   > finished design for how this is going to appear in a control-center
>   > panel
> So there's Bastien from gnome-user-share, Zeeshan from Rygel, Juan
> from Grilo... some initial design by Hylke (iirc), we should find a
> way to assemble persons and ideas, and get that created for 3.2.

The idea of blueprints makes a lot of sense to me. There are several
wiki pages that I have written that are close to that form. The Eye of
GNOME design page [1] is a good example.

Whatever process we come up with, designs need to be able to evolve and
then be agreed upon. The blueprint has to be the focus of discussion
between designers and developers (particularly maintainers) and,
crucially, someone has to say "yes, we're happy to do this", or "the
only way that UI will happen is over my dead body".

A key part of the Nautilus process was that we had an IRC meeting and
agreed on the UI bugs we wanted fixing. They became the roadmap [3].
Then Cosimo did something smart: he put a link to the roadmap page in
the #nautilus topic. Everyone could see what the plan was.

Having an 'official' plan also (I think) helped new contributors. We had
GNOME Love bugs in there that they knew we definitely wanted fixing.

In conclusion:
 * Designers and developers need to talk more
 * Blueprints are good if they are a tool for reaching consensus
 * Roadmaps are a good way to implement plans (and include contributors)
 * Everyone needs to know what the roadmap is


IRC: aday on

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]