Revise GOVERNANCE.md, introducting Committers and Project Managers
#23
Conversation
Signed-off-by: Tom Bentley <tbentley@redhat.com>
Signed-off-by: Tom Bentley <tbentley@redhat.com>
Signed-off-by: Tom Bentley <tbentley@redhat.com>
Signed-off-by: Tom Bentley <tbentley@redhat.com>
Signed-off-by: Tom Bentley <tbentley@redhat.com>
Signed-off-by: Tom Bentley <tbentley@redhat.com>
GOVERNANCE.md
Outdated
|
|
||
| ## 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. |
There was a problem hiding this comment.
Can we clarify if this is a majority of all Project Managers, or just those participating in the vote.
GOVERNANCE.md
Outdated
| 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. |
There was a problem hiding this comment.
Can we clarify if this is a majority of all Project Managers, or just those participating in the vote.
|
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>
|
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. |
GOVERNANCE.md
Outdated
| 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. |
There was a problem hiding this comment.
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>
| Those people with code ownership responsibilities will be identified in each repository (`.github/CODEOWNERS`). | ||
| For the sake of transparency, the membership of github teams will be made public in [TEAMS.md](TEAMS.md). | ||
| - **Contributors:** Anyone who contributes to the project in any form. | ||
| - **Contributors:** Anyone who contributes to the project, in any form, is a Contributor. |
There was a problem hiding this comment.
Is someone who participates in a Github discussion, Git issue, or Slack discussion also a Contributor?
There was a problem hiding this comment.
According to this definition, yes. But the way the rest of the document is written, including such people as Contributors shouldn't affect the decision making processes. i.e. contributions which don't require approval are made by such Contributions, but because they don't require approval there's nothing more to be said.
|
|
||
| ## Becoming a Code Owner | ||
| * inform the Project Managers about the review burden they're experiencing. | ||
| * suggest to the Project Managers other individuals who they consider meet the Committer criteria below. |
There was a problem hiding this comment.
Should we suggest the channel to be used to start this process? Maybe a Github discussion in an appropriate category would be a good approach.
There was a problem hiding this comment.
I don't think we need to be prescriptive (and let's remember this document is intended to be prescriptive) about where the communication happens. The point is that it does happen, and that the PMs should be taking review burden into account, because that's an important factor for sustaining the project.
We're all technical people, so we're drawn to nice hard and fast rules which we can reason about, but too many rules can make it hard to act, and limit the reasons for doing so, which can be problematic in itself. In this example, if we name a channel then what are we supposed to do if people use the wrong channel? Discount the input? What if a Committer doesn't want to use a public channel to give their feedback? Personally I'm very cautious about making value judgements about individuals at all, and especially in public.
|
Couple of comments and questions, but otherwise LGTM |
Signed-off-by: Tom Bentley <tbentley@redhat.com>
SamBarker
left a comment
SamBarker
left a comment
There was a problem hiding this comment.
Thanks @tombentley I'm largely +1 but would like to see a mechanism for removal before hitting approve.
| * Tom Bentley, IBM (@tombentley) | ||
| * Robert Young, IBM (@robobario) | ||
| * Sam Barker, IBM (@SamBarker) | ||
| * Grace Grimwood, IBM (@gracegrimwood) |
There was a problem hiding this comment.
nit: I'm assuming @gracegrimwood should be marked as unaffiliated
| Other aspects of this representation are left to the discretion of the Project Managers using the [Decision Making](#decision-making) process. | ||
|
|
||
|
|
||
| ## Ceasing participation |
There was a problem hiding this comment.
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 was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
| * Francisco Vila, IBM (@franvila) | ||
| * Paul Mellor, IBM (@PaulRMellor) | ||
|
|
||
| The committers can be addressed collectively in GitHub using the `@kroxylicious/committers` team. |
There was a problem hiding this comment.
We say @kroxylicious/committers here and @kroxylicious/code-reviewers in CONTRIBUTING.md do we need both?
| 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. |
There was a problem hiding this comment.
Should the governance doc outline how people get membership of either group?
4 participants
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:
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.