Roadmaps & Signposts
This is a scheme I've been thinking about trying out with a few apps. The basic idea is to boost the vibrancy of our app development community by planning in a more visible way, and monitoring the health of each app. It's work in progress. It ties in with, but is not dependent on AllanDay/BugManagement
Contents
Goals
Enhance the vibrancy of our core application community:
- More developers.
- More development activity.
- More development visibility.
- More excitement and interest.
- Safeguard against modules going quiet, and so achieve consistent quality across the application set.
- Above all, make it easier for people to contribute to GNOME.
What We Can Do
1. A Contribution Map
One of the most difficult hurdles to contributing is finding out what to work on, and the first step is finding an app.
A contribution "map" could be part of the solution. This would simply be a list of apps according to the type of contribution opportunities that are available. That way we can steer contributors towards modules that will give them the best chance of contributing successfully.
The map could also play a secondary role by providing a way for the project to direct resources to areas in need.
Could be similar in form to GnomeLove/CoreApps.
2. Consistent Signposts
To contribute to an app, you need to be able to basic information about it. Now that the wiki is better organised, we are in a position to provide information about each app in a consistent location.
Now that we have these consistent pages for application information, we need to review them to ensure consistency and uptodateness.
3. Roadmaps
A roadmap can be a list of features or bugs, or it can be a simple statement about the status of the app. A roadmap is not a binding commitment that certain features will be implemented by a certain time. Rather, it is a signal of where work is welcome. (As such, if an app doesn't have contribution opportunities, the roadmap should indicate this too.)
Roadmaps help to solve one of the biggest problems faced by new contributors: what to work on.
4. Health Checks
Maintainers are needed to enable other contributors to participate, by triaging bugs, reviewing patches and setting direction. Therefore, the level of application maintainership is one of the key determinants of module health.
Sometimes, of course, maintainers disappear, or they find that they don’t have as much time for an app as they used to.
If we want to ensure that all our core apps have vibrant, active, developer communities, it is important for GNOME as a whole to periodically check on the status of maintainers. Are they still involved? Are they active? What kind of help do they need?
How it Could Work
The Basic Procedure
At the beginning of each release cycle, I am willing to:
- Check on the state of each core app - did it have any changes last release? How much of its previous roadmap was accomplished? Has the bug count gone up or down? Are there many unconfirmed bugs? etc.
- Record the results of the health check as a means for future comparison.
- Talk with maintainers to check on their status and work with them to create a roadmap for the cycle (ensuring that the required bugs are filed, and so on).
- Check that the app’s homepage is up to date, and check that it gets updated with the latest roadmap.
- Update the GNOME contribution map based on the status of the app.
- Encourage the maintainer to publicise their plans for the cycle through blogging and posting to mailing lists.
After the apps have been checked, there could be a roundtable discussion with the Release Team and/or other interested parties to review the state of the apps and figure out if any actions are needed.
The procedure should be flexible and responsive to project needs.
Q. What would the procedure be if a module is unmaintained? How does someone become a maintainer in this situation?
Making It Happen
We’ve been here before, and it didn't quite work out. How and why will it work this time?
- I’m willing to do all the work. Establishing roadmaps for user facing projects requires design input, anyway.
- It will be limited in scope - I will only do it for the core apps, and the roadmaps will only cover the next cycle.
- Having the roadmap process at the beginning of the cycle will serve as a reminder to keep doing it.
- We can run it as a pilot to begin with. This means:
- Running the initiative in a small scale to begin with.
- Having an explicit evaluation process, through which participants are consulted about its effectiveness.
- After the evaluation, decide whether it was worth it or if any changes are needed.