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

Rationale

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

• The roadmap was editable by everybody, and so some people were changing it while they really shouldn't have done so;
• There was no consistency, it was just some ideas thrown on a webpage: the roadmap is not a TODO list, it's more high-level than that;
• It was bound to always be outdated: a small team is needed to maintain it;
• Often, contributors were ignoring it: they're busy people, and we have to go ask them some questions instead of waiting that they do what we expect.

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:

• Stimulate a roadmapping culture inside the community so that we discuss more often where we want to go (based on concrete plans);
• Increase the awereness about the future steps of the project inside and outside the community;
• Help with the release notes writing.

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:

• LucasRocha

• VincentUntz

• BrianCameron

• AlbertoRuiz

Process

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:

• Since the data comes from the maintainers, we hope that it will be possible to not force a roadmap, but only create a GNOME-wide roadmap from the ideas that are already around.
• 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.

Important pages

• RoadMap - where the final result of the roadmap process is published

• RoadMap/Draft - Draft for the new roadmap

• RoadMap/Archive - Previous roadmaps

• RoadMap/Modules - Roadmap information gathered from the module maintainers

• RoadMap/BeforeNewProcess - Roadmap page before the new process took place