Last week Georges stepped down as a maintainer of xdg-desktop-portal-gnome, a project he started a while ago with the intention to have a version locked place to put existing and new GNOME portal backends on our own development platform.
The background that led up to him stepping down has been brought up with the code of conduct committee, but with that said, it does not directly relate the topic here.
Immediately after Georges stepped down, parts of the release team took it upon themselves to designate new maintainers, without involving either Georges himself, or any of the other contributors to the project, and instead handed over maintainership to three individuals without prior direct involvement.
I believe this was in error, as it is not the job of the release team to manage how individual projects are run, and the transition was not done in the right mindset. What should have been done is to allow for things to calm down, with decisions making postponed to a later date. There were no practical reasons for rushing anything.
The best path forward, I believe, is to undo the recent maintainership changes to xdg-desktop-portal-gnome, let things cool down for some weeks, and then start over, so that we hopefully can all do so on good terms. It should hopefully make little difference in peoples willingness to contribute.
Release team responsibilities
Learning from this experience, it appears to me that we need policy for how to handle transitioning maintainership of core modules. It is in my opinion that the release team should be no more involved than they have in the past, which means being a backup solution for when the maintainers are unavailable for urgent patch reverting or release tagging, and similar activities.
In many cases there is a lack of maintainers that are willing to show up, and it’s understandable that it is beneficial to have a general “up for grabs” policy for actually abandoned projects, but that type of policy clearly doesn’t apply here, and the recent events show that the lack of policy is problematic.
Once we, as the GNOME project at large, have reached a consensus about what policy should be in place to handle transitions like these, we can with better confidence go back and apply it to xdg-desktop-portal-gnome.