This site has been retired. For up to date information, see handbook.gnome.org or gitlab.gnome.org.


[Home] [TitleIndex] [WordIndex

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

1. Goals

Enhance the vibrancy of our core application community:

2. What We Can Do

2.1. 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.2. 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.

2.3. 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.

2.4. 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?

3. How it Could Work

3.1. The Basic Procedure

At the beginning of each release cycle, I am willing to:

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?

3.2. Making It Happen

We’ve been here before, and it didn't quite work out. How and why will it work this time?

4. Comments


2024-10-23 10:58