/!\ Attention: Starting with GNOME 3, this roadmap process was abandoned and replaced by project-wide features. See 3.1 features for instance.

This page explains the rationale for the roadmap process, and explains the process itself. You can contact the roadmap gang if you have questions.


Before this process, we used to have a roadmap that was a simple wiki page (RoadMap). This approach had some issues:

For those reasons, a small team is now working on having a good roadmap: this is the Roadmap Gang. This team is in contact with maintainers and pushes them to update the roadmap when it's necessary. The team will also ask maintainers what goals have been achieved during a release.

We expected the following benefits from this process:

Roadmap Gang

This is the team working on the roadmap. There are no strict rules about who is part of the team, but it's probably a good idea to keep the team small (5 people maximum, eg). Having one person from the release team in the gang is probably a good idea, but it's not mandatory. Coordinators in this team need to be known community members, in order to be sure that the roadmap is consistent with the community wishes. However, there is no restriction for other team members.

If a member doesn't have enough time for the work, he/she should resign and a new member will join the team. This will help to get the process running, and not blocking on busy people.

Current members of the Roadmap Gang:


Here are some more details on the roadmapping process:

  1. At the end of a release cycle (or at the beginning of a release cycle) the Roadmap Gang sends a private mail to each maintainer asking them:
    • What are their plans for...
      • ...the next 4-6 months (ie, plans for the next stable release),
      • ...the next year (ie, plans for the stable release after the next one),
      • ...the future (plans for later).
    • What is blocking them to achieve those plans: missing feature in a library, missing infrastructure, not enough time, etc. (that's an important point since this knowledge is needed to unblock maintainers).
    • If they have plans about modules they do not maintain, and GNOME in general (for example, a maintainer might want to start hacking on another module, or might have a good idea for the whole desktop).
  2. Maintainers should reply within three weeks. If they don't reply, everybody will make fun of them in public places.
  3. All the data is put in RoadMap/Modules, and only the Roadmap Gang and maintainers are allowed to edit those pages. The goal of having the data on the wiki is that it's readable by everyone, so we can keep detailed plans open to everyone. Maintainers can also update their plans if they want.

  4. The Roadmap Gang analyses the data. Most of it will probably be some detailed plans that are not relevant for a GNOME-wide roadmap (they're relevant for modules roadmap, though). The goal is to outline some GNOME-wide goals, and some important goals for some modules. The analysis is done during two or three weeks.
  5. The results are published in RoadMap by the coordinators of the Roadmap Gang.

  6. The community is welcome to discuss this roadmap, and some changes may be done.
  7. After the UI freeze, maintainers are pinged: they receive a mail recalling what their goals were for the stable release, and they can reply with what was achieved, and what had to be punted. This will help with the release notes.

Important notes:

Important pages

RoadMap/ProcessBeforeGNOME3 (last edited 2012-05-16 13:12:19 by VincentUntz)