Maintainership transitions

[jadahl (Jonas Ådahl)]

xdg-desktop-portal-gnome

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.

[mcatanzaro (Michael Catanzaro)]

I don’t think release team has any written rules regarding special powers to add or remove project maintainers, so my vote would be that no such powers exist at all. At least, I’m pretty confident we do not want to claim special power to remove maintainers, so I don’t see why we’d have special power to add maintainers either. Instead, I’d say any GNOME developers should feel empowered to help newer contributors with taking maintainership of abandoned projects.

This incident happened in #release-team:gnome.org rather than a more neutral location like #gnome-hackers:gnome.org because Georges entered that room, said he needed help to remove himself from the doap file, and left so that we could not continue the conversation with him. Discussion naturally proceeded in the room where that occurred. The fact that he immediately left the room to avoid participating in any follow-up discussion, and had not already selected a replacement maintainer before quitting, seemed like an indication that he didn’t want to be involved with selecting a new maintainer. So honestly I really don’t understand the problem here. xdg-desktop-portal-gnome was abandoned with zero remaining maintainers. It’s important and cannot be left abandoned. Volunteers emerged (much to my surprise). Are we supposed to say no?

@jadahl

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.

With regards to the current situation with xdg-desktop-portal-gnome: I don’t understand why removing the new maintainers of xdg-desktop-portal-gnome would possibly make sense. Two of the three new maintainers are experienced GNOME developers who successfully maintain several other projects. I trust they will ensure that development proceeds in a conservative manner that fits with Georges’s original vision for the project. And if other developers also want to maintain xdg-desktop-portal-gnome, I highly doubt they would object to having more maintainers. So, with regards to this particular incident, what is your desired end goal here? As far as I know, we don’t currently have any other volunteers willing to maintain xdg-desktop-portal-gnome, and if we did, presumably they would likely be able to work something out with the current maintainers? i.e. does there exist some actual real dispute that needs to be resolved? I don’t think there does? So I don’t think there’s any need to revisit this unless (a) there are multiple people who wish to maintain the project, and also (b) there exists some actual dispute between them that would need to be mediated. Unless that’s actually the case, what would be the value of going backwards and removing the new maintainers?

With regards to future cases: I don’t see any problem with spelling out some new policy to handle transitions in maintainer status. Certainly couldn’t hurt things. But someone would have to write it.

[mcatanzaro (Michael Catanzaro)]

@jadahl

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.

One more thing. I had no clue that you would have wanted to be included in this discussion because you were not in the doap file, and I didn’t look beyond the very top of the git history to see who was contributing, and even if I had, you have six merged merge requests and I wouldn’t have taken that to indicate that you’d be interested in being part of a maintenance discussion. If you had been in the doap then we’d hopefully have roped you in, but you weren’t so there was really no way to know. There is a <helper> tag that you can use to add yourself to a project’s doap without becoming a maintainer if desired.

[matthiasc (Matthias Clasen)]

My take on this is that yes, this was too rushed of a decision.

We have plenty of weakly maintained modules, and a week or two with and empty doap file would not be a problem, and give some time to evaluate the circumstances, look for volunteers and organize a handover.

That being said, I was not involved in the decision, because I was not paying attention to the release-team channel, and I should have. I apologize for that.

[ebassi (Emmanuele Bassi)]

@jadahl

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.

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.

[mcatanzaro (Michael Catanzaro)]

BTW I do agree that having some more formal process for what to do when the last maintainer steps down would be beneficial. Maybe a more formal call for volunteers on Discourse would help things feel less rushed.

[garnacho (Carlos Garnacho)]

@ebassi

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.

Starting with the premise that making releases is not necessarily a maintainer’s task, and that these “last resort maintainer” tasks don’t include the things that really characterize the role of a maintainer, we could argue whether the release team is doing that.

And conversely, making tarballs, creating tags, or even creating branches do not require any doap changes, and could perhaps even be compatible with active maintainers.

@ebassi

it’s an emergent behaviour in the community, that was necessary to ensure a timely and consistent release process of the whole of GNOME.

Appointing new maintainers has never happened, and it was never necessary to ensure a timely release. Also, the bulk of the new appointed maintainers is not part of the release team.

@ebassi

We’re all working on this thing together, and the hard part of this work is talking to other people, not writing code.

And we are here because this is failing badly. Georges did not disappear and can be talked to, yet we are talking as if this case was an unavoidable contingency that cannot be undone. Neither of that is true, and it would be good to revisit, because we are not a meat grinder, and a drop out note from one of the most active contributors should at least have raised a two-sided conversation.

And I do agree we need rules, this has shown we do.

[ebassi (Emmanuele Bassi)]

@garnacho

And we are here because this is failing badly. Georges did not disappear and can be talked to, yet we are talking as if this case was an unavoidable contingency that cannot be undone.

But Georges did disappear: he has been dropping out of every single GNOME channel (except the gnome-shell one) for days; as Michael said, he joined the release-team channel, announced that he was removing himself from the DOAP file and that he could not commit the change because there was no valid maintainer left, and then left immediately.

Of course, the obvious thing to do is to message him in a private channel and ask—but private channels are not transparent, and not a good way to have a public transfer of ownership of a core component.

Honestly, I love Georges, and I understand stress and burn out—I have been there myself, and had to cut myself out of a lot of stuff; but we’re dancing around the fact that he did not behave in the most gracious of ways in this particular circumstance. It’s all the more relevant because just a couple of days before this particular incident, he gave Jonas and me access to the xdg-desktop-portal project on GitHub, in a perfectly transparent manner, which is precisely how things should work.

@garnacho

Appointing new maintainers has never happened, and it was never necessary to ensure a timely release. Also, the bulk of the new appointed maintainers is not part of the release team.

And here we go around the point, once again.

The release team did not appoint new maintainers at all: with Georges out of the picture by his own hand, somebody showed up and offered to take ownership at the tail end of a development cycle, with a release coming up. Sure, you can make a tarball even if you’re not in the DOAP file, but what’s the point if the DOAP file does not have any maintainer?

All the release team did was acknowledging the offer, and since one of the two people offering did not have a GNOME account—while still being a well-known member of the community and a foundation member—gave a reference to the account team for that. That’s all that happened, and all the release team can do.

The release team cannot nominate maintainers, and cannot remove maintainers. Maintainers can only remove themselves, and they can either ask other people to become new maintainers, or people with the GNOME account can show up and take up unmaintained projects. This is how it has always been—even before DOAP files were introduced—and nobody is asking to change that. This whole fiction of an absurdly powerful release team going around assigning maintainers to projects is a fundamental misunderstanding of what happened, and this is the third time the record has to be corrected. I sincerely hope it is the last.

[garnacho (Carlos Garnacho)]

@ebassi

This whole fiction of an absurdly powerful release team going around assigning maintainers to projects is a fundamental misunderstanding of what happened, and this is the third time the record has to be corrected. I sincerely hope it is the last.

I do not need to be talked down like that, thanks. Also, I was in the room and saw it develop, even if we could argue it started tongue-in-cheek.

Since you are troubled by my use of the word “appoint”, let me rephrase my quoted comment:

Maintainer changes never materialized in a total timespan of 34 min since the prior maintainer leaving without his involvement. They rarely happen with a total 2 prior contributions from 3 new maintainers, and are never necessary to ensure a timely release.

[jadahl (Jonas Ådahl)]

We seem to agree that the release team should have no power to remove maintainers from projects. We also seem to agree that the release team also should have no power to add maintainers to projects, but what happened is just that, no matter how you look at it.

@mcatanzaro

Are we supposed to say no?

It was not your place to spot volunteers, say yes or no, and appoint them as maintainers within a bit more than half an hour after the previous maintainer felt he had to remove himself.

@mcatanzaro

because you were not in the doap file, and I didn’t look beyond the very top of the git history

It was also not your responsibility to look at doap files, git history etc, to gather information whether it was appropriate to immediately commit to these changes with such short notice. I would appreciate if you avoid trying to make this personal about who you failed to ask. In this case, it was not your responsibility or job to ask to begin with.

GNOME is a collection of projects that share a common goal. These projects are largely self governed by the people contributing to the projects. By side stepping this by implementing these rushed changes, even if the intentions were good, was in my opinion wrong, and the way to make it right, is to undo them.

@ebassi

This whole fiction of an absurdly powerful release team going around assigning maintainers to projects is a fundamental misunderstanding of what happened, and this is the third time the record has to be corrected. I sincerely hope it is the last.

Not only did maintainership change hands on a very short notice, without anyone in the project involved, concerns about how things were done were raised by both the previous maintainer and myself after he referred to me, when asked to vouch for new account permissions explicitly for this new role a day after. These concerns were then hand waved away and overruled by the release team within a couple of hours. If the nature of the previous maintainers departure wasn’t enough, shouldn’t this also have raised some flags that things were changing a bit too fast? What word other than appoint or delegate should be used to describe what happened?

I hope you understand there issues raised here are with the GNOME community at large’s best interest in mind. I believe that transparency, accountability, rules and due process is necessary to ensure people feel their projects are in good hands when they are part of GNOME.

[gbsneto (Georges Basile Stavracas Neto)]

After pondering about this for a few days, I have come to the conclusion that the appropriate way to fix this situation is GNOME/xdg-desktop-portal-gnome!81. The rationale is in the merge request.

This should, at the very least, withdraw the situation in xdg-desktop-portal-gnome from this conversation, and let the focus be shifted towards discussing better policies to handle transitions like this.

[mcatanzaro (Michael Catanzaro)]

@jadahl

GNOME is a collection of projects that share a common goal. These projects are largely self governed by the people contributing to the projects. By side stepping this by implementing these rushed changes, even if the intentions were good, was in my opinion wrong, and the way to make it right, is to undo them.

I guess this is the part that I’m failing to understand. In normal situations, yes, I would absolutely agree. But in this situation, with nobody left to talk to – presumably Georges did not want to be involved in selecting his replacement, or he would not have left so suddenly – the only practical way to handle the situation is for anybody who wants to take over to do so. Otherwise, nobody can ever take over and the project is effectively locked forever. Right? So I’m still failing to understand how exactly you would have liked to see this play out. What do you want the process for dealing with unmaintained modules to look like?

@jadahl

Not only did maintainership change hands on a very short notice, without anyone in the project involved, concerns about how things were done were raised by both the previous maintainer and myself after he referred to me, when asked to vouch for new account permissions explicitly for this new role a day after. These concerns were then hand waved away and overruled by the release team within a couple of hours. If the nature of the previous maintainers departure wasn’t enough, shouldn’t this also have raised some flags that things were changing a bit too fast? What word other than appoint or delegate should be used to describe what happened?

So although this situation prompted her new account request, Jamie was ready for a GNOME account regardless due to her contributions to other projects. I think we just had a misunderstanding with the new account process. You didn’t do anything wrong there; you were not familiar with her contributions, so you declined to ack her, which is fine.

@jadahl

I hope you understand there issues raised here are with the GNOME community at large’s best interest in mind. I believe that transparency, accountability, rules and due process is necessary to ensure people feel their projects are in good hands when they are part of GNOME.

[jadahl (Jonas Ådahl)]

@mcatanzaro

But in this situation, with nobody left to talk to – presumably Georges did not want to be involved in selecting his replacement, or he would not have left so suddenly – the only practical way to handle the situation is for anybody who wants to take over to do so. Otherwise, nobody can ever take over and the project is effectively locked forever. Right?

I had no problem reaching out to Georges, despite neither of us being in the release team room. Of course it would not be effectively locked forever. If it was truly abandoned, that would have been discovered within a reasonable amount of time.