Revise `GOVERNANCE.md`, introducting Committers and Project Managers by tombentley · Pull Request #23 · kroxylicious/.github

tombentley · 2026-02-04T23:23:15Z

These changes to the project's GOVERNANCE.md (and associated files) replace the existing single Code Owner role with two roles, Committer and Project Manager. The motivation for this proposed change is to be able to scale the number of people with commit privileges without putting additional duties on those people in terms of the project's longer term governance and sustainability. The division of responsibilities is broadly similar to, and based upon, the model used by the Apache Software Foundation, but it's not precisely the same. To be clear, this change does not change anyone's eligibility for these roles.

The change from Code Owner to Committer includes a move away from using CODE_OWNERS to limit people's scope of approval to particular parts of the repository. This has several motivations:

Necessity: Other projects, such as Apache Kafka, seem to manager just fine with a high trust model when a Committer is trusted to involve the relevant SMEs about part of a PR where they lack expertise.
Unreliability: I think it's relatively easy for directories to get renamed without updating the CODE_OWNERS, breaking the apparent security that CODE_OWNERS offers.
Simplicity: Maintaining CODE_OWNERS imposes a burden in keeping everything up to date. After all, in terms of governance, a change is a code owner's scope should also be voted on, just like making them a code owner in the first place.

All existing Code Owners would become the initial Committers and Project Managers.

There are some other changes, in terms of github team names and communications, made to align with the proposed new terminology. Those changes will be made if this PR is accepted.

Signed-off-by: Tom Bentley <tbentley@redhat.com>

GOVERNANCE.md

robobario · 2026-02-05T03:44:56Z

GOVERNANCE.md

+
+## Becoming a Committer or Project Manager
+
+New Project Managers can be elected by a majority vote of the Project Managers following the [Decision Making](#decision-making) process.


Can we clarify if this is a majority of all Project Managers, or just those participating in the vote.

GOVERNANCE.md

robobario · 2026-02-05T03:45:53Z

GOVERNANCE.md

+The Project Managers should endevour to match the number of active committers to the reported review burden, by inviting Contributors to become Committers.

-### Code Owner Criteria
+New Committers are elected by a majority vote of the Project Managers following the [Decision Making](#decision-making) process.


Can we clarify if this is a majority of all Project Managers, or just those participating in the vote.

GOVERNANCE.md

robobario · 2026-02-05T04:36:26Z

Thanks Tom, generally agree with the split into Committer + Project Manager, with the technical/governance split. Agree that a single committer role is sufficient for the scope of our project, rather than managing per-component privileges. Just some quibbles around details.

Signed-off-by: Tom Bentley <tbentley@redhat.com>

tombentley · 2026-02-05T05:28:05Z

Thanks @robobario, I've addressed your comments, and tried to make it clearer how the decision making around committers and pms works. Please take another look when you have a chance.

tombentley · 2026-02-05T05:32:47Z

GOVERNANCE.md

+This project uses the following decision making process for PRs in the repository containing this `GOVERNANCE.md`, [COMMITTERS.md][committers] and [PMs.md][PMs] files:

-## Trademark Policy
+1. **Voting:** Decisions may be made through a simple majority vote among the committers who participate in a vote, as tallied 7 days after the start of the voting process.


The intent with starting with a vote is simply that it makes clear that there is a consensus.

For code PRs it's not a huge deal if someone after the fact disagrees that something was merged: Fixing it is only a git revert away. But goverance and role changes aren't quite like that. We need it to be clear and transparent that those decisions really did meet the threshold right from the start.

I added the 7 day limit simply to avoid a kind of live lock which becomes more likely to happen once PMs move on to other things and don't participate in votes at all.

Signed-off-by: Tom Bentley <tbentley@redhat.com>

GOVERNANCE.md

PMs.md

k-wall · 2026-02-10T12:08:51Z

Couple of comments and questions, but otherwise LGTM

Signed-off-by: Tom Bentley <tbentley@redhat.com>

SamBarker

Thanks @tombentley I'm largely +1 but would like to see a mechanism for removal before hitting approve.

SamBarker · 2026-02-12T03:22:14Z

COMMITTERS.md

+* Tom Bentley, IBM (@tombentley)
+* Robert Young, IBM (@robobario)
+* Sam Barker, IBM (@SamBarker)
+* Grace Grimwood, IBM (@gracegrimwood)


nit: I'm assuming @gracegrimwood should be marked as unaffiliated

SamBarker · 2026-02-12T03:29:53Z

GOVERNANCE.md

+Other aspects of this representation are left to the discretion of the Project Managers using the [Decision Making](#decision-making) process.
+
+
+## Ceasing participation


While I'd hope it would be irrelevant I think we probably need a documented mechanism for removing committers and project managers. I don't think we need to get over overly prescriptive about the criteria for doing so but we should have a mechanism.

One of the obvious reasons for doing so would be Code Of Conduct violations, though I'm sure there are other possible rerasons.

There is already a mechanism for removing people from these roles: A change to the Committers or Project Managers is a change to the PMs.md and COMMITTERS.md in this repo, which is handled by the decision making process. (I added this section simply to make it unambiguous that people can just unilaterally resign without needing to have a vote about it, which seems like pointless ceremony to me).

So are you suggesting:

being more explicit about this mechanism, but not changing how it would work?

or some other mechanism that's not equivalent to what's already implicitly defined? If so, can you elaborate what you're looking for?

Without wanting to suggest that the COC is not important (it is), I don't think a COC violation should necessarily result in removing a role. Certainly it should be a sanction that's available. But tying the PMs' hands and disallowing them any discretion based on the specific circumstances seems like it might not be in the best interests of the project. For example, what if the complainant specifically asked that the accused only apologise, and not be removed from their role? If it's in the governance rules the other PMs would then be in a difficult position. And the reality is that we can always involve the CF to make a decision for us.

I'm not advocating all CoC violations are grounds for removal just that it is a possible sanction.

I guess I read the pr process as additive but you're right that is a bidirectional process.

So no I'm not advocating for a new process or mechanism. Maybe worth saying it's at the pms discretion so it's clear without being overly prescriptive.

SamBarker · 2026-02-12T03:31:33Z

COMMITTERS.md

+* Francisco Vila, IBM (@franvila)
+* Paul Mellor, IBM (@PaulRMellor)
+
+The committers can be addressed collectively in GitHub using the `@kroxylicious/committers` team.


We say @kroxylicious/committers here and @kroxylicious/code-reviewers in CONTRIBUTING.md do we need both?

SamBarker · 2026-02-12T03:32:21Z

CONTRIBUTING.md

-If the change is being authored by someone who is a Code Owner, that change must be reviewed by at least one other Code Owner before being merged.
+All changes which are to be committed in project source control must be reviewed by at least one [Committer](COMMITTERS.md) before being merged.
+If the change is being authored by someone who is a Committer, that change must be reviewed by at least one other Committer before being merged.
+The GitHub teams `@kroxylicious/code-reviewers` and `@kroxylicious/doc-reviewers` can be used to request a PR review from contributors.


Should the governance doc outline how people get membership of either group?

k-wall

Good step forward, thanks for putting the time in to this.

tombentley added 7 commits February 5, 2026 12:00

Remove TOC, order sections "chronologically"

aed8098

Signed-off-by: Tom Bentley <tbentley@redhat.com>

Add Users as a participant; add Contributor duties

0147087

Signed-off-by: Tom Bentley <tbentley@redhat.com>

Factor a Project Manager role out of Committer

aa0381d

Signed-off-by: Tom Bentley <tbentley@redhat.com>

Tidy up; reference files enumerating those in a role

435fe3d

Signed-off-by: Tom Bentley <tbentley@redhat.com>

Teams, COMMITTERS.md and PMs.md

a5d0c55

Signed-off-by: Tom Bentley <tbentley@redhat.com>

Remove TODO

06d2a40

Signed-off-by: Tom Bentley <tbentley@redhat.com>

Fixup

c73b9b6

Signed-off-by: Tom Bentley <tbentley@redhat.com>

robobario reviewed Feb 5, 2026

View reviewed changes

Rob's comments + more clarity wrt voting

3b64b3a

Signed-off-by: Tom Bentley <tbentley@redhat.com>

tombentley commented Feb 5, 2026

View reviewed changes

tombentley added 2 commits February 5, 2026 18:33

doh

b7bd0f3

Signed-off-by: Tom Bentley <tbentley@redhat.com>

Tweak words

3b36a6c

Signed-off-by: Tom Bentley <tbentley@redhat.com>

tombentley marked this pull request as ready for review February 8, 2026 21:08

tombentley requested a review from a team as a code owner February 8, 2026 21:08

tombentley mentioned this pull request Feb 8, 2026

Document the 'admin' role #13

Open

k-wall reviewed Feb 10, 2026

View reviewed changes

GOVERNANCE.md Show resolved Hide resolved

k-wall reviewed Feb 10, 2026

View reviewed changes

GOVERNANCE.md Show resolved Hide resolved

k-wall reviewed Feb 10, 2026

View reviewed changes

PMs.md Show resolved Hide resolved

EGC and shared secrets

a8aabff

Signed-off-by: Tom Bentley <tbentley@redhat.com>

SamBarker reviewed Feb 12, 2026

View reviewed changes

SamBarker approved these changes Feb 12, 2026

View reviewed changes

k-wall approved these changes Feb 12, 2026

View reviewed changes


		## Becoming a Committer or Project Manager

		New Project Managers can be elected by a majority vote of the Project Managers following the [Decision Making](#decision-making) process.

		Other aspects of this representation are left to the discretion of the Project Managers using the [Decision Making](#decision-making) process.


		## Ceasing participation

Conversation

tombentley commented Feb 4, 2026

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

robobario commented Feb 5, 2026

Uh oh!

tombentley commented Feb 5, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

k-wall commented Feb 10, 2026

Uh oh!

SamBarker left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

k-wall left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants