Proposal to improve our roadmap process

[Vincent Untz <vuntz gnome org>]

Hi,

Lucas and I have both been thinking about how we can improve the GNOME
roadmap, and since we had some ideas about this, we took some time to
discuss them today. Here are some kind of minutes. This is more or less
a proposal (Lucas, please fix any error I'll put in there). We'd love to
know if you think it's a good idea or not. We can of course discuss
about this in the meeting of Saturday. We'd like to start spamming
maintainers next week.

=====================

We think that there's currently an issue with the GNOME roadmap, and
more generally, a lack of direction. We hope that improving the roadmap
will help having better direction.

Right now, we have a kind of roadmap located on the wiki at
http://live.gnome.org/RoadMap
Here are some problems we see with this document:
 + it's editable by everybody, and so some people are changing it while
   they really shouldn't (users, eg)
 + there's absolutely no consistency
 + it's just some ideas thrown on a webpage
 + it's bound to always be outdated
 + I guess most contributors are ignoring it

Lucas has stepped up to ask maintainers their plains for 2.20, which is
good. He also asked people to update the roadmap wiki page. There were
not a lot of results, though. This is probably because maintainers
usually are busy people.

Here's what we're intending to do (assuming the release team feedback is
positive):

 + send a mail to devel-announce-list to explain what we'll do, and more
   generally explain the new roadmap process
 + send a private mail to each maintainer asking them what are their
   plans for the next 4 months (ie, features for 2.20), for the next
   year (ie, for 2.22), and for the future (later than 2.22). Also, we
   want to know what is blocking them to achieve those goals (that's
   an important point since we'll want to unblock maintainers as much as
   possible)
   We also ask people what are their plans wrt to other modules and
   GNOME in general. For example, a maintainer might want to start
   hacking on another module.
 + we ask them to reply within two weeks (or three?). If they don't
   reply, we'll make fun of them in public places.
 + we gather all the data and we put it on the wiki, asking people to
   not edit those pages. The goal of having the data on the wiki is that
   it's readable by everyone. And maintainers can update them if they
   want.
 + we start an analysis of all this data. Most of it will probably be
   some details we don't really care about. But we hope that we'll be
   able to outline some GNOME-wide goals, and some important goals for
   some modules.
 + we publish those goals as a roadmap.

Some important points here:
 + all this work is done by a small team (could be release team, but we
   can delegate this to a group of volunteers). Right now, Lucas and I
   are interested to work on this.
 + this means that the roadmap can not be edited by everybody. Just a
   small group of people can edit it.
 + since the data comes from the maintainers, we hope that we'll be able
   to not force a roadmap, but only create a GNOME-wide roadmap from the
   ideas that are already around

We also plan to integrate this process into the schedule. This means
that at the beginning of a new development cycle (or maybe, at the end
of a development cycle...), we send private mails to maintainers and
update the roadmap following the process outlined above. Also, after the
UI freeze, we ping maintainers with what they wanted to do for this
release, so we can know what was done and what wasn't done. This will
probably make it easier to write the release notes. So three new things
to add to the schedule:
 + ping maintainers about roadmap for next cycle and future (at the end
   of a cycle or at the beginning of a cycle)
 + update the roadmap (one month later)
 + check what was achieved after ui freeze

Another point is that we'll want to know when a maintainer has some good
ideas for a module, but doesn't have time to work on them. Because this
would be a good way to know where help is welcome. And maybe we can get
some new maintainers thanks to this information.

This needs to be bootstrapped, and we want to do this soon. This means
that we'll get some results for 2.20, but we expect to have "real"
results for 2.22.

Vincent

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