Create MAINTAINERS.md #812
Conversation
Signed-off-by: Hendrik Ebbers <[email protected]>
hendrikebbers
requested review from
rbair23,
popowycz,
stoqnkpL and
dmueller2001
There was a problem hiding this comment.
- There is nothing here that speaks to timeliness. Is there any expectation by contributors regarding the timeliness in acting on contributions by maintainers?
- Compliance with the organization's policies - I would recommend that we include that maintainers are the primary overseers ensuring that activities in their repos are compliant with the policies of Hiero and LF-DT. Example being complying with the LF-DT security vulnerability disclosure policy.
- I would also recommend that we highlight the maintainers responsibility in fostering an environment as outlined in the Code of Conduct.
- Regarding the test and release pipeline and the publication of artifacts, from a good practices perspective, I would recommend we have a document/procedure which outlines what the expecations are (e.g. artifacts should include all variable test parameters/inputs).
- Regarding becoming a maintainer - is there a definition of what a "significant" PR is?
| | Name | GitHub ID | GitHub Scope | LFID | Discord ID | Email | | ||
| |-----------------|----------------------------------------------|--------------|-------|-------------|----------| |
There was a problem hiding this comment.
It would be nice to get this lined up (also it looks like there may be tabs in here)
| - The proposed maintainer establishes their reputation in the community, | ||
| including authoring five (5) significant merged pull requests, and expresses | ||
| an interest in becoming a maintainer for the repository. |
There was a problem hiding this comment.
I think for us, we distinguish between committers and maintainers, whereas LFDT may not in general. I think the bar to becoming a maintainer is far higher than 5 significant merged pull requests, although for a committer this may be about right. I think we need to revisit this language. Maintainers have voting rights, and that should come with a long history of active participation.
|
|
||
| ## Removing Maintainers | ||
|
|
||
| Being a maintainer is not a status symbol or a title to be carried |
There was a problem hiding this comment.
Just a formatting comment -- some lines are short, some lines are really long. I think we should reformat so we have as a rule 120 chars per line, like we do source files.
| - The PR **MAY** be communicated on appropriate communication channels, including relevant community calls, chat channels and mailing lists. | ||
| - The PR is merged and the maintainer transitions to maintainer emeritus if: | ||
| - The PR is approved by the maintainer to be transitioned, OR | ||
| - Two weeks have passed since at least three (3) Maintainer PR approvals have been recorded, OR |
There was a problem hiding this comment.
There is no mention of maintainer votes of NO. So suppose less than a majority agree with the PR, so they don't approve the PR. But then after two weeks only 3 maintainer PR approvals were needed to merge the PR. I also assume a single NO by a maintainer is not sufficient, otherwise two bad maintainers colluding together could avoid ever being removed. instead, there has to be some voting process, and I am skeptical that the PR approval process is the best way to do it (since tallying up the results is difficult).
hendrikebbers
added
the
Hiero Transfer
As defined by LFDT every repository needs a MAINTAINERS.md file (https://lf-decentralized-trust.github.io/governance/governing-documents/repository-structure.html). A template provided by LFDT can be found at https://github.com/LF-Decentralized-Trust/governance/blob/main/tac/governing-documents/SAMPLE-MAINTAINERS.md
This PR creates the first MAINTAINERS.md file for a Hiero repo. The file contains a lot of definitions and rules. Therefore it must be reviewed by the TSC before we move forward and create new repositories.
Based on the guideline of LFDT for the MAINTAINERS.md file (see https://lf-decentralized-trust.github.io/governance/governing-documents/MAINTAINERS-file.html), at least one contact method needs to be provided for each maintainer. Currently the table has not filled any contact method. I suggest to use email by default but want to discuss that before publishing mails in the file.