RFC: Governance

Community
1

As promised, I wrote a more formal proposal for the new technical governance model for GNOME that I presented at GUADEC 2025.

WARNING: this is a long document. Please read it all before forming an opinion. Governance is not a computer program, and you are not compilers; there’s no point in stopping at the first thing you disagree with.

While comments are welcome, I’d like to stress two things:

  • if you are not contributing to GNOME, you are not really the target audience of this document and proposal; this means that, while you may have a point of view, it does not necessarily mean your point of view is relevant. Please, think long and hard whether you want to leave a comment.
  • the moderation mallet is going to be out and on high alert; moderators will be on the lookout for bad behaviour, and discussions that spin out of control are going to be spun out to separate threads—or deleted, if they go off topic or off the code of conduct

This is an RFC, which means nothing is final until the stakeholders reach some rough consensus.

I have tried to fill out some of the rules for the steering committee, mainly based on the Debian Technical committee and the Rust Leadership Council; there’s a lot more to be written on the decision making process of the steering committee, but I didn’t want to commit to that before iteratively figuring out the role of the committee itself.

Summary

This change proposes to formalize the GNOME technical governance structure, by creating various teams representing shared areas of interest to take over the existing informal technical leadership represented by individual project maintainers, and allow future expansion when new shared areas of interest arise.

Motivation

The GNOME technical governance model has barely changed from the “rag tag band of misfits” of the halcyon days of the project’s youth: we are still structured around informal power dynamics, with people appearing and disappearing, driven by somebody’s vision and chance, until all its spent. Decision-making is an exercise of sisyphean patience, where people must push the boulder of the community uphill only to watch it roll back down with every cycle.

The GNOME Handbook describes the decision making process as:

Most decisions in GNOME are made informally, by individuals working in collaboration with one another. This informal way of making decisions applies to who works on what, which features are supported, and which technical and user experience designs are implemented.

The motivation for this proposal is to remove the “informal” and “individual” parts, and instead create formal, shared structures to increase accountability while diffusing personal responsibility.

Background: no formal structure

There is a power vacuum at the center of GNOME, as there is nobody nominally “in charge” that decides:

  • the overall direction and vision for the project
  • the priorities for a particular release

The release team and design team are, both within and without the project, seen as final arbiters but they have neither the resources nor the mandate to actually make or implement any such decision. We leave any decision to each individual, overworked, overstretched project maintainer, and we assume that they will care about the design, the implementation, the QA, and the integration of each and every feature, while simultaneously dealing with the day to day maintenance in the form of issue triaging, code reviews, and general housekeeping of their project. None of these decisions are shared, documented, or even properly planned; they may exist in the form of individual bug reports, but the overall process is opaque to other maintainers or contributors.

Background: existing teams

GNOME has various teams already, but none of them apply to components and applications, and they exist either as emanations of the Foundation’s board (like the release team), or they have been grandfathered in from informal structures, and they exist (or not exist, like in the case of the current Documentation team) de facto, without a scope, mission, or official membership.

It is impossible to know if somebody is, for instance, member of a team: you have to join a Matrix room, ask questions, present work, and hope that the people replying to you are actually GNOME contributors, as opposed to bystanders.

Background: project fiefdoms

GNOME works as a collection of projects, each maintained by a few people, or as its most common, a single person. There are no rules that prevent a single person from maintaining multiple projects. There is no formal venue for discussing changes across multiple projects. There is no formal process to propose changes across multiple projects. Each project is its own special, unique snowflake when it comes to interaction with other projects, both as dependencies and reverse dependency. While some projects have multiple contributors that could be described as “maintainers”, they are an overall minority.

Each project maintainer (be it expressed as an individual or a team) is responsible for vetting every change, act as a mentor, provide institutional knowledge, and general gatekeeper. Various individuals operate as the sole maintainer for multiple projects. This ensure that any decision or change that affects multiple projects under GNOME is delegated to one or few individuals.

What needs improvement

While we need a formal process for making and documenting technical decisions, we are currently lacking a structure to even implement that process. In order to have a way to create proposals that are evaluated by the community of contributors to the GNOME project, shepherded into completion, and formally approved by a steering committee, we need a way to structure the community of contributors to actually make that happen.

Governance structure

The basic idea is to dissolve the “projects rule” structure, and instead create new teams representing various areas of shared interest that include multiple projects; the existing contributors operate within the boundaries of these teams, and any decision making happens at the team level, as opposed of the project level.

Teams

Primary roles

Each team should:

  • shepherd changes related to the team area.
    • This means: ensuring all stakeholders are aware of a change; working on identifying design details, trade offs, and alternatives; build consensus
  • accept or reject changes in the team area
  • set policies on what changes can be reviewed and merged directly, and what changes require a larger discussion
  • have regular meetings, each with public minutes
  • have discussions on public forums as much as possible
  • decide its own membership
  • decide its own lead and representative

Decision making

Consensus

GNOME is based on rough consensus: decisions are achieved by listening to all stakeholders, addressing the blocking issues discovered during the discussion, and deciding when a certain acceptance threshold is achieved.

While a successful outcome is one where all sides of a debate have been heard and addressed in some way, it is important to note that consensus does not mean “design by committee”, nor it means indefinite blocking by one or few individuals.

Lack of consensus

In some cases consensus, rough or otherwise, cannot be reached. Some times it is caused by “trivial” concerns, like naming, even if there is consensus on the substance; in other cases, there can be some strongly held beliefs in either side of a debate. Teams are empowered to decide which one of their members should be in the “lead” position, to resolve the impasse, and make an executive decision.

The teams

The initial set of teams proposed is:

Team Area of interest
Platform The OS and application development layer
OS System components and OS integration
Core apps Core applications
Tooling Development tools and applications

It is important to note that this list is just the initial set, and is predicated on having an already well-defined list of contributors in the area. New teams can be added after the governance model is adopted.

Each team can have additional sub-teams for focused topics.

Each team will have a dedicated area for discussion in Discourse, as well as a room on Matrix.

Each team is empowered to add or remove team members whenever needed, taking into consideration that team membership is not a precondition for contributing to projects within the team’s remit.

Platform team

Focuses on the libraries at the core of our software development platform.

The following sub-teams are part of the Platform team:

  • Introspection: describing and consuming the software development platform (bindings, documentation, tests)
  • Services: system and user session services that are provided by GNOME

OS team

Oversees the system components, like the compositor, system settings, networking, and the integration with the lower layers of the OS.

Core apps

Focuses on the applications that are part of the core GNOME user experience. The team is responsible for proposing the addition and removal of core applications to the Release team.

Tooling

Oversees the various applications and tools used for the development of GNOME components, as well as applications targeting GNOME.

The steering committee

The steering committee serves as the technical leadership of the GNOME project as a whole. In particular, it:

  • Sets the overall direction and vision for the project. That means setting the core values that are used when making decisions about technical trade offs.
  • Sets the priorities of the project. Design bandwidth and development resources are scarce commodities, and the steering committee makes decisions on what to priorities for each cycle.
  • Focuses on broad concerns. The steering committee takes a global view of the GNOME project, to ensure that all its components fit together in a coherent way.
  • Manages the teams. Over time, new teams may be needed, or existing teams may need to be split up or stood down; for specific concerns, new “strike teams” may be created to address limited tasks.

Duties and expectations

At a high level, the steering committee is only in charge of:

  • identifying and prioritizing work that has no clear ownership
  • delegating this work, potentially by creating new teams to own it
  • making decisions on urgent matters that have no clear ownership
  • coordinating project-wide changes to teams, structures, or processes
  • ensuring teams are accountable to their area of interest, to other teams, and to the GNOME project as a whole
  • ensuring where possible that teams have resources necessary to accomplish their work
  • establishing the official position, opinion, or will of the GNOME project on technical matters

In addition to these duties, the steering committee has the additional expectations and constraints:

  • delegate work; the committee should not take work beyond its duties
  • ensure the long term operations of the project; the committee should ensure that project management work happens regularly, and does not accumulate organizational debt
  • be accountable; the steering committee has broad powers, which means every member of the committee must be accountable for their actions
  • be representational; the steering committee represents various aspects of the GNOME project, but it should also strive to represent the diversity of the GNOME community
  • share burden; all members of the steering committee must share the burdens of the committee’s duties
  • respect others’ purview; the steering committee must respect the purviews of each team. The committee should consult with and work together with teams on solutions, and should almost never make decisions that go against the wishes of any given team
  • act in good faith; committee members should make decisions in the best interest of the GNOME project as a whole even if those decisions come into conflict with their individual teams, their employers, or other outside interests
  • be transparent; while not all decisions (or aspects of a decision) can be made public, the steering committee should be as open and transparent about their decision-making as possible. The steering committee should also ensure the organizational structure of the GNOME project is clear and transparent
  • respect privacy; the steering committee must never compromise personal or confidential information for the sake of transparency, including adjacent information that could unintentionally disclose privileged information
  • foster a healthy working environment; the steering committee representatives should all feel satisfied with the amount and nature of their contribution. They should not feel that their presence on the committee is merely out of obligation but rather because they are actively participating in a meaningful way
  • evolve; the steering committee is expected to evolve over time to meet the needs of teams, the GNOME project, and the community

Steering committee representatives and other team members serve as examples for those around them and the broader community. All of these roles represent positions of responsibility and leadership; their actions carry weight and can exert great force within the community, and should be wielded with due care. People choosing to serve in these roles should thus recognize that those around them will hold them to a correspondingly high standard.

Structure of the steering committee

The steering committee includes exactly one representative of each team, determined by the team members at their own choice.

Each representative represents at most one team, even if they are also a member of other teams. The primary responsibility of representing any GNOME team falls to the representative of the team they fall under.

List of teams

The steering committee is composed by a representative from the following teams:

  • Platform
  • OS
  • Core apps
  • Tooling
  • Design
  • Release
  • Translation
  • Infrastructure

Term limits

Each member of the steering committee has a term limit of 24 months (two years) in length. After the term expires, their respective team will propose a new member for the steering committee. There are no hard limits on the amount of non-consecutive terms that a member can serve on the steering committee, or the number of terms served for other teams.

Half the appointments will happen after the March release of GNOME, and the other half after the September release, to avoid the case of changing all representatives at the same time.

Limits on representatives from a single company/entity

Just like the board of directors of the GNOME Foundation, members of the steering committee must not disproportionately represent a single company, legal entity, or closely related set of legal entities. No organization, corporation or similar entity, or any affiliate thereof shall hold, directly or indirectly, more than 40% of the membership of the steering committee.

With an initial number of 8 members from the existing teams, this means no more than 3 members can belong to the same organization.

Relationship to the GNOME Foundation

The board of directors of the GNOME Foundation shall appoint a non-voting liaison to the steering committee, to ensure that the Foundation continues to not be responsible for the technical direction of the project.

Drawbacks

The main drawback of this proposal is that we may not have enough people to fill out these teams; ideally, the whole impetus of a team-based governance model is to bring in new contributors that have so far resisted the role of “maintainer”, but that may come at the cost of losing existing maintainers that feel that the GNOME project is better served with them acting as gatekeepers to ensure a consistent and coherent experience. While this proposal may seem radical, it is designed to take what is already partially implemented; this should mitigate the risk of alienating a large part of the contributors base.

9 Likes
2

I think, as a whole, this direction is reasonable. Thank you, Emmanuele, for putting so much time and care into this.

I’ll start with my tiny nitpick: let’s call the OS team the “System” team instead, with the expectation that there will be a dedicated “GNOME OS” team in the future representing the interests of the GNOME OS project. Otherwise there will just be confusion when that day comes.

Overall, my concern is that we don’t have enough people for this bureaucratic process to shift us away from the status quo. It seems to me like we’ll still have de-facto “maintainers” who have the institutional knowledge over their corner of the stack. Not even necessarily because folks want to hoard institutional knowledge, but simply because we don’t have enough people interested in involving themselves. Someone needs to keep triaging issues/reviewing MRs/fixing bugs/etc, and it’s going to be the people who know most about a specific codebase. I fear the end result will be teams that have members working on unrelated projects, or grouped into subteams that consist essentially of individuals.

I’ll use myself as an example: I maintain gnome-session and co-maintain GDM, and only because RedHat had me replace Ray (otherwise I wouldn’t have been interested enough in the problems there to overcome the opportunity cost of getting into it). It’s not that these were particularly difficult codebases for me to wrap my head around, and Ray was very happy to get me up to speed in their details. It took some time and effort, but I was able to take over. The difficult part isn’t the official role of a maintainer: tagging releases. It’s the unofficial role of “person who understands this code enough to meaningfully review MRs and think of solutions to issue reports”.

If GDM gets grouped with Mutter under the “System Team”, I wouldn’t feel any more comfortable reviewing and hitting the merge button on a Mutter MR than I do today (that is: not at all). Nor do I expect that I’d suddenly become a lot more interested in the internals of Mutter, to the point where I’d spend the time and energy to learn enough that it would become appropriate for me to review MRs there. The same applies vice versa too: I don’t expect Mutter developers to suddenly become interested enough in GDM to gain enough of an understanding of all of the complexity (i.e. PAM :grimacing:) for it to be appropriate to start reviewing and landing MRs.

So in terms of this proposal, I can’t yet wrap my head around how all of this is supposed to fit together to solve the fiefdom problem. I suppose a valid course of action is just to accept that this is what it is, and that the people with de-facto power today (by being a maintainer of a project) will have formal power when we put these structures into place (by being the sole interested party for a project on the relevant team). But I’m not certain that this is all you intend to achieve

My other concern is projects that GNOME deeply involves itself with, but aren’t technically part of GNOME. There’s lots of these: many different freedesktop services, Flatpak, Flathub, portals, Wayland, systemd, etc. I’ll pick on Flatpak for the purposes of demonstrating my point.

Flatpak isn’t a GNOME project. But GNOME developers go work on things in Flatpak because we want these features in GNOME. It’s unclear to me how that interacts with this whole structure: GNOME is interested in certain Flatpak functionality, Flatpak is interested in representing itself in GNOME’s technical decision making process because it’s legitimately quite an important part of GNOME, and yet there’s no mechanism for that.

So the question is: how do we integrate these important non-GNOME projects that GNOME really involves itself with, and potentially GNOME people are involved in maintaining them? The governance structure would have no formal power over these projects, but might still have power over the GNOME contributors contributing to these projects on behalf of GNOME.

Something to consider: projects like systemd have their own governance structures. I wonder if we need some kind of formal mechanism for cross-project communication channels that can exist as members of teams. For instance, the System team might include someone who’s involved in systemd and not necessarily a GNOME developer - just the systemd project gets to elect a liaison into GNOME’s technical leadership structure (and vice versa). In practice, there would probably be a single person representing GNOME’s interests to systemd and systemd’s interests to GNOME

3 Likes
3

Yes, which is why the same concern is listed in the “drawbacks” section at the end. As I also wrote there, the whole idea is to add more people that currently fall short, for one reason or another, of the role of “maintainer”, so we don’t get gatekeepers.

Also, this is really the least “bureaucratic” process possible, unless by “bureaucratic” you mean “something that doesn’t rest on the narrow shoulders of a single person”, in which case we are just winding up the ticking clock until GNOME is maintained by three people in a trenchcoat. Don’t know if you noticed, by the amount of “maintainers” hasn’t been skyrocketing, as of late.

Then why don’t have more people share this load, without necessarily having Red Hat pay for them?

Also, this whole section is puzzling, to me, to a degree that I barely can fathom:

Do you think I review all the merge requests in GLib, GTK, Pango, GdkPixbuf, gobject-introspection, or any other library I am even tangentially involved in? Because I don’t. There are people that know more than me about aspects of a lot of code bases for which I am nominally a maintainer.

If you are knowledgeable in the GDM bits, I assume you’re going to feel confident in reviewing code that touches GNOME Shell’s use of GDM.

This proposal is not meant to create teams of people that know the whole code base that falls under their area of interest—though it would be great if more people knew more parts of GNOME, which is why more people should be involved in this. What this proposal does is:

  1. create teams of people with shared interests, responsible for projects that fall under those areas, and have them talk to each other in a reasonably public setting whenever they want to change something in GNOME
  2. create a steering committee from representatives of those teams that work on global vision, and act as a referee when teams propose changes

The fiefdom problem is solved not when we don’t have people that know a project very well: it’s solved when those people are not in the position of blocking things from happening, or dumping a whole change as a fait accompli without telling anybody else.

On a longer scale, this proposal create a culture of sharing the load, with the ability of including more people to propose and discuss changes.

2 Likes
4

I re-read the proposal and I have one question.

Where should be place for proposing RFCs (is this correct way to form this sentence?)? Should it be Discourse or specific repo on gitlab?

Thank you for proposing this!

5

The RFC part is still a work in progress; unfortunately, we have this bootstrapping problem where we need teams to propose/accept/reject RFCs, and we need RFCs to define the governance structure in more detail. We can get an initial steering committee going with a rough definition, and then go through a proper RFC mechanism to define a more comprehensive process, likely after a few iterations.

From a merely procedural standpoint, we will create a repository with an RFC template, and then any RFC gets added to that repository via merge requests; you can check the Rust RFC process which is a very lightweight version of the PEP process:

  1. fork the “RFC” repository
  2. create a new RFC from the template
    • add all the details: team, summary, explanation, technical details, drawbacks, alternatives, prior art, unresolved issues, future changes
    • for user-facing changes: UI/UX design details, QA plan, documentation
    • most importantly: who is responsible for the work
  3. open a merge request
    • ideally, we’d have an editorial team that checks the conformance of each RFC, keeps track of the open merge requests, labels them appropriately in GitLab, keeps the discussion going; as we’re starting out, this role can be filled in by each team
  4. discuss the RFC within the team, and with all the involved stakeholders
    • this can be problematic to do on GitLab, given its lack of moderation tools; we might need to have the discussion on Discourse
    • we could have a discussion between team members on GitLab, and use Discourse to open the discussion to the larger community
  5. once the discussion is over, the team calls for a Final Comment Period of N days
    • the team also decides whether the proposal should be merged, closed, or postponed at the end of the FCP
    • this is where we want to reach out to all possible stakeholders that haven’t weighed in for a final chance to present objections
  6. the RFC is merged or closed (or, if postponed, it goes back into development); if it is merged, then it’s “active” and people can work on implementing its final form
    • minor changes to an active RFC can be submitted as the result of the implementation; major changes will need a new RFC; each team decides what’s “minor” and what’s “major”

All of this happens within the remit of each team; the steering committee gets involved only to resolve issues with RFCs that cover more multiple teams, or if a team is unable to come to a decision, or if a team does not have the resources to implement an RFC.

Again, this is fairly rough.

2 Likes
6

Some of your comments indicate you’re still hoping to get rid of project maintainers, which is unrealistic. GNOME is a big collection of small projects, and teams with a large scope and perspective are just not a better way of working on small projects. I see only two possible ways that ends: (a) we’ll continue to have de facto maintainers and everything operates same as before, except without any way to formally indicate who the maintainer is, which is not an improvement; or (b) we take “no maintainers” seriously until chaos ensues and eventually we change our minds and bring back maintainers.

But I see your proposal does not directly call for replacing maintainers. Forming some higher-level teams seems fine. I don’t know how well they’ll work, but why not give it a try? Even if only some of the teams are successful, that’s a win. Giving those teams formal power, including power to overrule maintainers, also seems fine. (Our fiefdoms should be “softer.” Collaborating well together is more important than exerting absolute authority over particular components.) Creating a steering committee to relieve release team and design team from serving that role also seems like a clear improvement. I suppose my suggestion is: try everything you’re saying, but layer it all one level above maintainers rather than eliminating maintainers entirely.

Exception: I think it’s perfectly fine for the maintainer of a particular project to be a team rather than a list of individuals. But this will probably only work well for a few GNOME projects, not for most of them. And the teams would likely have to be of narrower scope than you propose here. E.g. a Platform team is probably not a good fit maintaining the entire development platform, because the development platform is huge; you might be interested in GTK and Pango, but maybe not in libsoup or libgdata. An OS team is probably not a good fit for maintaining the entire OS. (Higher-level teams could certainly oversee lower-level teams and maintainers, but now things are starting to feel pretty complicated. Then again, that might be OK since we can evolve as we go; no need to get everything perfect from the beginning.)

2 Likes
7

We’ll need to tighten up these rules to more precisely specify when terms end. With 1/4 of the terms expiring every 6 months, and 2 year terms, we would probably want to have A, B, C, and D terms so it’s clear when exactly each person’s term ends. Or perhaps we don’t need terms at all, because each position is appointed by a particular team; each team could decide on its own who should represent the team and for how long.

I’m also not sure whether this particular format for steering committee will actually work well. Maybe infrastructure team is too busy for somebody to serve on steering committee. Or maybe translation team just wants to focus on translations rather than governance. Or maybe accessibility team does want somebody to sit on the committee, but they’re not on your initial list of teams, so how do we decide to add them? I don’t know. Maybe it’s good enough to say that the steering committee itself should figure this out and define its own rules.

Another option would be for GNOME Foundation to just directly elect the members of the steering committee.

The teams are too high-level to effectively replace maintainers.

To use Adrian’s example, we could have a lower-level team for maintaining gdm, gnome-settings-daemon, and gnome-session. Call it “core services team” or something like that. Another lower-level team could maintain gnome-shell, gnome-shell-extensions, and mutter. I’d say it’s also perfectly fine to have a higher-level “OS team” with oversight responsibility over all of the above, but expecting a high level team to actually maintain all of these components is expecting too much, because they are too loosely-related to each other to reflect real shared interest. Platform team and Core Apps team will both have the same problem. The scope is way too big for the teams to operate effectively at a low level.

I agree that it’s time to do something about these problems, and creating teams seems like a good solution.

We should probably discuss this separately, since whether RFCs work well or not will be independent of whether governance teams work out well. Writing RFCs won’t be enjoyable, but we probably really do need a more formal way of handling changes that affect many components.

2 Likes
8

Bureaucracy isn’t a bad thing, and I’m not using it to mean a bad thing. Establishing formal bodies of governance with authority, regular meetings, etc is bureaucracy. The obvious end goal after this proposal, which is establishing a formal RFC process, is also very much bureaucracy. No more “maintainers do what they want”, and instead now people have to go through the “paperwork” of talking to others, (eventually) filing formal RFCs, and so on. These are not bad things, these are things we need. But that doesn’t make them not bureaucracy.

Bureaucracy, when not in excess, is a good thing. And this isn’t too much. Nor do I think an RFC process would be too much either.

If there are people interested in sharing this load I am happy to have them around and helping. I certainly could spend more of my time on other things. But I don’t know if such people exist and where to find them. Especially if we’re talking about folks that aren’t being paid to be doing this.

Well it is the responsibility of the maintainer(s) to ensure that MRs get reviewed and issues get addressed, even if they themselves aren’t doing the work (which in my experience working on GNOME is a rare exception). But many of the libraries you mention here have multiple maintainers, and even though you’re not personally reviewing all of the MRs yourself the maintainer team as a whole is doing all of the reviewing. At least in my experience interacting with many GNOME projects.

To try and quantify this, I looked at GLib’s 10 most recently updated merged MRs. You left some kind of review comment or approval on 4 of them. You, Marco Trevistan, Philip Withnall, and Michael Catanzaro (the list of maintainers Philip identifies as the “most active recent maintainers”) left review comments/approvals on all 10 of the MRs. Just Marco and Philip alone left comments/approvals on 8/10 MRs, and the 2 remaining MRs were authored by Philip.

I did the same experiment with GTK. Of the last 10 merged MRs (ignoring one that made a release), Matthias Clasen authored 8 of them and reviewed the 9th. You reviewed the remaining MR. Of the last 10 merged MRs that Matthias didn’t author, Matthias reviewed 9/10 and you reviewed the remaining one.

Are there situations where all the people who are nominally maintainers of a module aren’t very familiar with the code? Sure. But I’m not really so sure that this is the case for the majority of GNOME projects. Also, I wouldn’t expect that such projects are the projects where maintainers make use of their fiefdom powers

Not really, no. At least I wouldn’t be comfortable to hit the merge button on the MR. I could review those changes from a GDM perspective and see if the GDM bits are being done correctly, but I’m unsure how changes to the low level GDM parts will break the rest of gnome-shell (after all, there’s a whole frontend there, and also much of that code is reused between GDM and the lock screen, etc).

Maybe over time I can become familiar enough with GNOME Shell’s codebase to understand the implications changes I accept would have on the rest of the code. But that’s an exercise in getting familiar with gnome-shell’s inner workings, not GDM’s.

It’s much easier for me to just interact with the GNOME Shell developers, during development and during review.

I think Michael’s suggestions helped this click for me: what this proposal gives on top of the status quo is the formal authority of a group of people to override an individual maintainer’s decision.

For instance: if this passes I might be the “de-facto maintainer” of gnome-session (i.e. I review all the MRs and make the day-to-day changes to the project, even if we remove the formal position of maintainer). But the System Team my module would belong to will have the ability to overrule my decisions if they’re out of line from the team’s greater direction (and, via the steering committee, potentially the project’s greater direction). This makes lots of sense to me as something we need to have.

And at that point, we might as well leave the role of “maintainer” defined. That way we know who’s still responsible for ensuring MRs get reviewed and issues get addressed. But the overall Team a project is under has overrule authority over the formal maintainer’s decisions.

I also agree with Michael that it makes sense to allow projects to have their “maintainer” be the team they belong to. In fact, this should probably just happen by default for projects that don’t have maintainers defined.

9

A collection of unrelated points on this proposal:

The scope of the steering committee sounds very good, and is something that I’ve wanted GNOME to have for a long time (largely because of the power vacuum issue, but also as a way to diversify and open up project leadership roles). I’m wholeheartedly in favour of that aspect of the proposal.

Committee appointment is a tricky problem. We need to ensure that the committee is composed of people who can engage in high-quality decision making. We also need individuals who have the time and energy to fulfil their duties. And we want the committee to be representative of the wider project and to be open to emerging project leaders. A more diverse appointment system might help with that. I’d be in favour of having additional seats that have an alternative appointment mechanism (committee self-appointment or election being the obvious ones).

I’d probably drop the term limits for the initial proposal. It’s a good thing to consider, but I’d probably wait to see how things work out before setting those details.

My main concern about the proposal is that it is too big. Formalised teams plus steering committee plus RFC process is a lot. Out of those three elements the development teams is the most high-risk and complex. I can’t help but wonder whether that part of the plan should be decoupled and given more time/space to evolve. (Speaking of which, the teams which represent groups of modules are awfully big and include a large variety of project types. A proposal for constituent sub-teams would be good to have, in my view.)

For the new governance structure to have legitimacy I think that it will be important to have some form of community ratification, possibly a referendum amongst foundation members. That could happen after a trial period. Let’s also set out a timeline for review and adjustment, like an annual retrospective for the first couple of years.

5 Likes
10

I honestly don’t understand this hyperfixation both you and @mcatanzaro have with the existence of a “maintainer”. I assume it’s because you both started projects and feel like you are owed some sort of recognition for that, and you want to have final say on everything, which: fair play, but it’s really not an important part of any proposal.

Does the idea of removing the role of a maintainer personally offends you? Is that a sort of personal hang up in how you see free software development working?

Once again: “overruling” is not the goal of this proposal, just a side-effect. It’s telling that both you and Michael go straight to that.

The goal of this proposal is to turn a self-isolating, individualistic model of governance into a collaborative one. There should be no reason to override the decision of somebody working inside the “System” team, because you get to talk to other people in that team and get feedback.

You are focusing on a contingency for conflict that arises from somebody taking a decision without talking to anybody else. This is a grim view of free software development.

11

Looking at similar committee (Debian, Python, Rust) there’s a spectrum for the appointment of members: you go from elected positions (Python), to appointment by the committee (Debian), to an automatic membership defined by the structure of the governance (Rust).

The Rust approach requires restructuring the GNOME contributors community into teams, so that all members of the steering committee belong to a team—thus making the steering committee a reflection of the contributors community; this is a bit too much, in my opinion. That’s why the proposal adds a bunch of reps from different teams.

To be honest, I am not super-fond of the co-optation of Debian and, closer to home, the Release team; it’s good and fine for a specific set of tasks, like building and releasing GNOME, but a more “aspirational” team like the steering committee would suffer from groupthink pretty quickly.

Maybe, as you hinted, a more “mixed” approach might work: reps from teams, and additional co-opted members to balance them out.

Again: I want to avoid groupthink; plus, I want to avoid the case where people are afraid of commitment or of messing up, because they don’t have any off-ramp. We can quibble on the duration of a term, but introducing term limits ex post is always more complicated than just starting with them.

Yep, which is why I didn’t include the RFC process at all. :wink:

This proposal is strictly for creating teams to populate the core of the steering committee.

I added two sub-teams for the Platform team, and at GUADEC I’ve heard ideas for other teams related to that area.

Ideally, instead of people hyperfocusing on whether or not I’m trying to remove the role of maintainers like I’m proposing the installation of guillotines in the middle of Place de la Revolution, we’d see people proposing additional teams and sub-teams.

2 Likes
12

The only project I’ve started is libgnome-games-support, and frankly I don’t care too much about that one.

The fact that maintainers have final say on everything is a defect in our current development model, and I appreciate that you’re trying to fix that.

What I’m mainly concerned about is responsibility. Reading issue reports and reviewing merge requests is critical work. Currently maintainership is formal way to indicate that somebody has volunteered to do that work. This system currently works moderately well. If we have a problem, then we talk to the project maintainers; if no project maintainers are available, then we can mark the project as unmaintained and put out a call for new maintainers. (We need a better way to indicate that projects are in need of new maintainers.)

So my question is: how will high level teams decide who will read the issue tracker, respond to merge requests, flag security issues for GNOME Security, etc? Components cannot be overlooked. If you join the Platform team, then will you dutifully help with triaging libxslt issue reports? I rather doubt it, but the team will need to ensure that somebody does so. Maintainership seems like the best way to define this responsibility, but as long as each high level team truly has a plan to take responsibility for each of the dozens of components within its extremely broad purview, I suppose that’s sufficient.

Ideally, each project has a team of maintainers. Of course, that’s not always possible simply because not enough people are interested in contributing to a project. The GNOME community has grown much larger, but the maintainer community has not. I suspect we could do a better job of recruiting maintainers.

2 Likes
13

One question I have in regards to deciding direction on each of these teams. Hopefully this is not out of scope in this thread. If not, I’ll restate this at a future date.

Ideally, the RFC could account for external stakeholders like 3rd party developers or extensions developers. This gives the ability for community to weigh in on the priorities in GNOME’s roadmap.

The discussing in public forums feels like it would generate more noise than anything else. Leaving teams to have to decipher needs, wants, and nice to have from that noise. I would suggest a more formal approach with finding specific stakeholders within the 3rd party/extension community. Like having a public review of a team’s roadmap with those stakeholders. An example is that GNOME shell developers frequently query major shell extension developers about changes being made. It’s not formal, but it does help inform their decisions.

I just want to make sure that we incorporate voices from those who develop using our platform, use our design patterns, and provide GNOME to users and building a robust feedback loop.

3 Likes
14

I absolutely love this proposal. Sorry for taking so long to comment on it — I didn’t notice it had been posted.

Even if one takes the pessimistic view that this proposal won’t encourage anyone else to contribute to GNOME or eventually become involved in decision making and maintenance, it will at least encourage the existing maintainers to un-silo and shuffle around a little bit more.

In particular, the requirement for teams to “have regular meetings” will, I hope, go a long way to getting people to collaborate a bit more and spread institutional knowledge around. This is something which was perhaps previously done through blogging, but less of that has happened in recent years.

As Michael says, discussing the RFC process would make sense, otherwise discussion of this is going to get head-of-line blocked on RFCs too. It seems that we could implement teams/steering first, and then RFCs shortly afterwards.

I agree with all of what Allan said about phasing, legitimacy, etc.

As I read the proposal, the new way of working would be for any member of the team to triage issue reports and review MRs. That will likely end up being the same few people as before (the old maintainers) at least to begin with, but it allows for people to broaden their areas of interest over time.

If MRs and issues are building up in a project without being triaged/reviewed, that will get noticed in the regular team meetings and then the team can collaborate on addressing it. (If it doesn’t, the team meetings aren’t working.) MRs and issues regularly build up in some projects under our current system — having someone named as a maintainer is no guarantee they will actually do what you are expecting them to do.

As I’m reading it, in the proposal, responsibility moves from maintainers to the team. This would rely on each project being labelled as the responsibility of a specific team (rather than overlapping with multiple teams).

The current system works well at burning specific people out to the point they disappear. It does not work at all well at encouraging new people to become maintainers. I really think we need to move away from the current system.

Replying to some specific points in the proposal:

Perhaps team membership should be a precondition for contributing to planning within the team. I feel like you probably meant that already, but perhaps it would be clearer to mention it explicitly here, to contrast with the “taking into consideration” clause here.

Suggest calling these “working groups” or “task groups” as “strike teams” is a bit violent. But I won’t bikeshed on this!

Ignore me if I’m going too much into the weeds here. This is starting to sound quite a lot like a constitution (which is fine) — would it be useful to add things normally in a constitution, like quorum thresholds for decision making, minimum frequency of meetings, and a grievance mechanism for forcing membership change if things break down?

3 Likes
15

Thanks for your feedback, Philip; it’s much appreciated.

I think this is a good clarification; my main point was: “you don’t need to be part of the team to contribute (code or otherwise) to a project”. If you want to contribute to planning, though, you definitely need to be part of the team.

I wanted to be a bit more lightweight on the consensus mechanisms, also because as pointed out, we might not have a full coverage right out of the box. The governance structure (and possibly the RFC mechanism) allow for improvements down the line, after we had a few iterations; this is also why I don’t want to try and get everything perfect on the first try.

As I said in my presentation at GUADEC: it would be incredibly narcissistic to think GNOME’s governance requirements are completely unique. Nevertheless, we are our own project, with our own community, and I want to give us plenty of runway to get to a comfortable process.

As for “a grievance mechanism for forcing membership change if things break down”: the steering committee is the team management. They are the ones that handle the team membership if there are issues. If the steering committee itself is involved, I think it’s perfectly fine to have the Foundation’s board of directors—as the ultimate political expression of the larger GNOME community—be on hand to solve issues there.

2 Likes
16

That seems reasonable. I think it would be worthwhile explicitly mentioning that in the proposed document though, so it’s more obvious that certain mechanisms within the document were deliberately left loose for future refinement, rather than left loose and not meant for future refinement.

:+1:

Also sounds good to me. Again, I think this would be worthwhile briefly mentioning in the document.

3 Likes
17

Would it be worthwhile getting together a small working group of people to hash this out, incorporate the feedback so far, and polish it to the stage where it’s ready for putting to the project membership for approval/implementation?

Worried that (with the best will in the world) having it all rest on one person’s shoulders risks the proposal not reaching escape velocity.

I’m happy to be involved, although the working group membership would have to be more diverse than the people in this thread so far — it would need representation from at least all the proposed new teams.

5 Likes
18

I really like the proposal, it gives us hope to fight the burning out problem, the tribal knowledge problem, and RFCs are proven to work as we can see in other projects that have them. Thank you Emmanuele for putting the time into this important initiative.

I want to highlight a point I like from the discussion that has already happened:

As I understand it, much won’t change at first - same people, focusing on their areas of expertise, and that’s completely fine, nobody will be asked to review anything they don’t have knowledge of. But I think the process is definitely worth it in the long run, as I think will make people talk to each other more, and nothing prevents the team for deciding on “maintainers” of any project, that’s up to any team to figure how they collaborate, and actually I think that would be great idea for a start.

My main question from this thread is, what would be the process of joining a team for a newcomer person? If I understand correctly, that would be a responsibility of the team itself, so each team could have their own process. Or maybe there could be some common process.

I’d like to help with this initiative, and out of the proposed teams, my interest and knowledge areas covert the OS (System components and OS integration) team the most.

I think this is the actionable thing right now - we should ask people that we think would be interested in being representatives of each of the teams, and connect them to this thread if they’re interested.

1 Like
19

Now that GNOME 49 is mostly out of the door, we can work on this more in earnest.

I’m less concerned about getting the wording right, and instead getting the infrastructure off the ground. Having the document approved without having the structure to sustain it will only result in lack of interest.

I would start by creating the new teams, instead. Gathering members, establishing collaborative spaces, and holding regular meeting.

I’m happy to start organising the Platform meeting, so we can decide the kind of scope we want to cover, and what kind of sub-teams need to be created. I’d start contacting the maintainers of the core SDK libraries and services.

I am also happy to help people in the system, core and circle app development communities, though I am clearly not going to be as relevant to their mission and scope.

Once we have these teams, the project membership will either automatically align to this structure, or won’t, and we’ll have to figure out some other approach.

It would be hilariously on point if a change in governance model towards a more collaborative style of maintenance were to be thwarted by a lack of collaboration.

1 Like