Emmanuele Bassi

4 weeks ago

Emmanuele Bassi
4 weeks ago

Embloggeration happened: bassi.io/articles/2025/08/03/g…

For those who were unable to attend, or see the recording, these are the notes for my GUADEC 2025 presentation about introducing a formal technical governance in GNOME, starting from a "change proposal" process, through the addition of a steering committee to evaluate those changes, and all the way down to the removal of the role of the "maintainer" for projects that exist under the GNOME umbrella.

#gnome

Governance in GNOME

For those who were unable to attend or see the recording, these are the notes for my GUADEC 2025 presentation about introducing a formal technical governance in GNOME, starting from a

^{halting problem}

#gnome

in reply to Emmanuele Bassi

Emmanuele Bassi

in reply to Emmanuele Bassi 4 weeks ago

Since for some unknown reason I have had to mention it multiple times: by "removing maintainers" I do not mean "I'll assemble a detail of six men, take the existing maintainers behind the chemicals shed and shoot them". I'm referring to the role of a project maintainer, which I want to replace with teams of people working in the same area of interest

in reply to Emmanuele Bassi

✧✦Catherine✦✧

in reply to Emmanuele Bassi 4 weeks ago

reading this made me realize that people think a maintainer's namesake job involves doing the releases

i've always used the word synonymous to a "leader"

in reply to ✧✦Catherine✦✧

Emmanuele Bassi

in reply to ✧✦Catherine✦✧ 4 weeks ago

@whitequark the role and its duties vary from project to project; a maintainer in GNOME has, historically, been the person rolling the releases and uploading the artefacts because they had access to the FTP server; but it also meant the person responsible for doing all the reviews, going through all the issues, and providing some institutional knowledge. It's basically a mix between a senior engineer and a release manager.

@✧✦Catherine✦✧

in reply to Emmanuele Bassi

✧✦Catherine✦✧

in reply to Emmanuele Bassi 4 weeks ago

yeah, the latter part makes sense to me

in reply to ✧✦Catherine✦✧

Emmanuele Bassi

in reply to ✧✦Catherine✦✧ 4 weeks ago

@whitequark it is what it ought to be: a role that uplifts new contributors, and plans for its own obsolescence. Unfortunately, it mutated into a sort of "medieval lord controlling their fiefdom" kind of role, which may even work for singular projects, but it's a disaster for communal projects

@✧✦Catherine✦✧

in reply to Emmanuele Bassi

✧✦Catherine✦✧

in reply to Emmanuele Bassi 4 weeks ago

yeah, I can see that

This entry was edited (4 weeks ago)

in reply to Emmanuele Bassi

kramo

in reply to Emmanuele Bassi 3 weeks ago

So if I want any of this to happen, what can I actually do other than wait for other people to do something (as if my MR was blocked by a maintainer on vacation)? :)

in reply to kramo

Emmanuele Bassi

in reply to kramo 3 weeks ago

@kramo since you're a core app maintainer, I'd start gathering other core app people and seed a "core app team": exchange code reviews, document change proposals, triage issues, have regular meetings between core app contributors for discussing features and issues, and keep notes. Basically: core applications should be a shared area of interest. Once we have a process for creating groups, we can make the core apps team official, and then select somebody to be in the steering committee.

@kramo

in reply to Emmanuele Bassi

darkdragon

in reply to Emmanuele Bassi 2 weeks ago

My understanding of "maintainer" is the person maintaining a project in a sense to keep it healthy and sustainable. This includes reviewing designs and code changes in a timely manner. Who is going to do this? Can we start paying maintainers to review code in a timely manner? Both corporate sponsors and private contributors have very little intrinsic motivation to review other people's changes instead of working on the ones they care about themselves.

in reply to darkdragon

Emmanuele Bassi

in reply to darkdragon 2 weeks ago

@darkdragon “who is going to do this”: the same people that do it today, and more in the future. There’s no need to have a singular maintainer or a single person responsible for everything: the Great Man Theory belongs to the trash heap

@darkdragon

in reply to Emmanuele Bassi

darkdragon

in reply to Emmanuele Bassi 2 weeks ago

Was the previous maintainer role limited to a single person?

in reply to darkdragon

Emmanuele Bassi

in reply to darkdragon 2 weeks ago

@darkdragon it's not limited to a single person, but it's tied to individuals. Before the release service, maintainers had SSH access to upload release artefacts; now individuals with the maintainer bit have access to repository settings and can push protected tags.

@darkdragon

in reply to Emmanuele Bassi

darkdragon

in reply to Emmanuele Bassi 2 weeks ago

what about merging to the default branch (like merging MRs)? Is this part of the maintainer role or something else?

in reply to Emmanuele Bassi

darkdragon

in reply to Emmanuele Bassi 2 weeks ago

How do you make sure such change proposals don't get stalled? Did you get inspiration from other projects' processes like the Wayland change process (which I can highly recommend): gitlab.freedesktop.org/wayland…

governance: introduce workflow improvements (!342) · Merge requests · wayland / wayland-protocols · GitLab

Proposal: Improving Development Workflows Problem Statement Development discussions in wayland-protocols often get 'stuck', which...

^GitLab

This entry was edited (2 weeks ago)

in reply to darkdragon

Emmanuele Bassi

in reply to darkdragon 2 weeks ago

@darkdragon you assume I haven’t looked at various governance mechanisms already, which leads me to conclude you did not read the blog post you are replying to

@darkdragon

in reply to Emmanuele Bassi

Emmanuele Bassi

in reply to Emmanuele Bassi 2 weeks ago

@darkdragon the Wayland governance is not the only model in existence; it teaches us something, just like every other model—though it’s still too early to call it a success, compared to the models of communities like Python, Rust, Fedora, or Debian

@darkdragon

in reply to Emmanuele Bassi

darkdragon

in reply to Emmanuele Bassi 2 weeks ago

I read it at full length but only remembered the comparison with Python which already inspired the previous failed attempt (although after reading again it also lists Rust and Fedora which are very similar and don't seem to provide additional aspects). So it makes sense to do a more elaborate comparison. Especially the aspect of many of them getting stalled is quite common in these ecosystems. The golang approach is also very inspiring. Or the original RFCs for internet standards.

This entry was edited (2 weeks ago)

⇧

Emmanuele Bassi 4 weeks ago • •

Emmanuele Bassi
4 weeks ago