chore(na): how to become maintainer #1940
Conversation
Co-authored-by: Binod Adhikary <adhikary@medicmobile.org>
Co-authored-by: Apoorva Pendse <apoorvavpendse@gmail.com>
| title: "Core Maintainer" | ||
| linkTitle: "Core Maintainer" |
There was a problem hiding this comment.
What do you think about using the term "Committer" instead of "Maintainer"? The idea is that lots of people (both technical and non-technical) are involved in "maintaining" the CHT. However, these requirements here are focused specifically on people who would have commit privileges in the medic org. That is a very specific type of maintenance that, for security and feasibility reasons, should be delegated to a limited group of technical people.
Closely related to this (and with consideration of @dianabarsan's earlier comment) it seems like even from the beginning we might need at least four levels of involvement in CHT development:
- "Contributor" - basically anyone engaging with the CHT development community (commenting on the forum, submitting GitHub issues, submitting PRs)
- There are no requirements to this role. It is just the default state of anyone who contributes.
- "Reviewer" - someone with moderate CHT experience who is able to review PRs, but does not have commit privileges.
- This is a mid-tier between no access and full access. The goal is to recognize regular contributors and provide them the opportunity to further engage with the code base by reviewing PRs, etc.
- A PR that has been approved by a "Reviewer" can be merged by a "Committer" (without the "Committer" necessarily being expected to do a full review of the PR). It will be up to the discretion of the Committer (who holds ultimate responsibility for the code they are committing) whether or not the PR needs further review.
- The requirements for this level should be similar to the Committer, but less in scope.
- There should be no limit on how many users we have at the Reviewer level.
- "Committer" - has commit privileges to the public
medicrepositories (but only as-needed access to the private repos).- Committers can approve/merge PRs (that they did not create)
- This constitutes a considerable level of responsibility and requirements should be comparatively high to reach this level.
- We should probably only have a limited number of Committers (as discussed more in a comment below). Committers should have explicit responsibilities and base expectations that they need to accomplish to maintain their status as a Committer.
- "Admin" - has admin privileges in the
medicorg.- Obviously only granted to a select group of people, though it is probably still worth communicating in these docs how someone gets to be an admin.
There was a problem hiding this comment.
I love that you broke the roles down, however I disagree with the point about the reviewer being a lower tier than committer, or that PR does not need to be reviewed by a committer.
I think the roles should be switched, not necessarily by name but by level of trust (maybe not the best word) and PRs should require be reviewed and merged by committers. Of course, someone else can do a review - train their reviewer brain, and a committer should over-review.
I'm not sure about the terminology to use.
|
|
||
| _\* Features and bug fixes are measured by a PR that was successfully merged to `main`_ | ||
|
|
||
| ## How to add a core maintainer |
There was a problem hiding this comment.
There is a real security concern for having too many users with commit access and/or having stale users (who are no longer involved in the CHT community) with commit access. I think we may need to consider accepting nominations on an as-needed basis. Consider something like a target of 15 users with commit access. We periodically (or automatically?) audit that list according to our requirements from the "When to remove..." section below. When we have open slots we can post a "Call for nominations" on the forum or something...
|
Wonderful discussion here! I'll look to update the document early next week based on feedback above. Keep the comments coming!! |
* chore: mark 3.x guides as archive * chore(na): remove CHT 3.x hosting pages * tidy up hextra cards on landing pages * remove a bunch of '4.x' instances * add missing aliases for 4.x, not that upgrades can take up to 5x, not 3x :( * remove 4.x mention per feedback * remove 4.x mention per feedback x2 --------- Co-authored-by: Andra Blaj <andra@medic.org>
* chore(na): squad closeout steps * Update squads.md * Update squads.md --------- Co-authored-by: Phil Mwago <41321750+Phil-Mwago@users.noreply.github.com>
Description
This PR adds steps and processes on how to become core maintainer for any of the CHT repositories. The PR not only will be a way to publish the information, but will be used as a public discussion to gather input on what the community thinks.
License
The software is provided under AGPL-3.0. Contributions to this project are accepted under the same license.