This policy clearly has not served us well in the past, if, as you say right after:
In many cases there is a lack of maintainers that are willing to show up
The main problem is that you can’t have your cake and eat it, too: either maintainers can disappear with no transition planned, and then return at their leisure; or somebody needs to step up, and figure out how to replace them with whatever resources we have at our disposal. I understand we’re all volunteers, here, but at the end of the day somebody needs to release GNOME, and that means the train never really stops.
We already had a discussion over this here, on Discourse: A reflection on maintainership: what to do when the bus factor dwindles?
Sadly, no policy came out of that—or out of any other case in which we had maintainers of core modules doing light release work, or simply disappearing for a while.
As I said on the release team channel, I’m entirely in favour of having a policy that defines when the release team should step up and take over an unmaintained module—leaving leeway for maintainers that wish to step back for a bit. This means having a clear process for maintainers to announce they wish to step back for a bit, so that the release team can cope with it.
First of all:
- maintainers should always feel welcome to come into the release team channel and announce they are taking time off
- maintainers should be proactive, and nominate their replacements—the sooner they do, the better; but they can also decide at the very last moment
The important thing to remember is that the release team is not a collection of people just running around taking tarballs or kicking the CI pipelines: they act as the “maintainer of last resort” for core components. This role is not something that was dreamed up by the current release team members: it’s an emergent behaviour in the community, that was necessary to ensure a timely and consistent release process of the whole of GNOME. It’s all well and good to consider yourself a maintainer of your own project, but you’re not maintaining in a vacuum, and you’re not responsible only for your little piece of the puzzle. It’s the fundamental reason why having access to the GNOME group gives you access to the whole of the GNOME projects; we encourage people to take ownership of the platform, and we always did. Yes, some maintainers are really specific in how they maintain their projects; and yes, some maintainers don’t have the resources to keep up and yet they still maintain an iron grip on the projects they created. It has been a cause of friction in the past.
This is why maintainers of core GNOME modules should really be proactive:
- find other people to work on your module in your absence before leaving/taking a break
- update the DOAP file to ensure that there is always at least a person that can be reached for issues
- communicate large scale changes to the release team so that they can plan ahead
We’re all working on this thing together, and the hard part of this work is talking to other people, not writing code.