|
| 1 | +# Maintainers |
| 2 | + |
| 3 | +The general handling of Maintainer rights and all groups in this GitHub org is done in the https://github.com/hiero-ledger/governance repository. |
| 4 | + |
| 5 | +## Maintainer Scopes, GitHub Roles and GitHub Teams |
| 6 | + |
| 7 | +Maintainers are assigned the following scopes in this repository: |
| 8 | + |
| 9 | +| Scope | Definition | GitHub Role | GitHub Team | |
| 10 | +| ---------- | ------------------------ | ----------- | ---------------------------------- | |
| 11 | +| Maintainer | The GitHub Maintain role | Maintain | `hiero-sdk-cpp-maintainers` | |
| 12 | + |
| 13 | +## Active Maintainers |
| 14 | + |
| 15 | +<!-- Please keep this sorted alphabetically by github --> |
| 16 | + |
| 17 | +| Name | GitHub ID | Scope | LFID | Discord ID | Email | Company Affiliation | |
| 18 | +|----- | --------- | ----- | ---- | ---------- | ----- | ------------------- | |
| 19 | +| | | | | | | | |
| 20 | + |
| 21 | + |
| 22 | +## Emeritus Maintainers |
| 23 | + |
| 24 | +| Name | GitHub ID | Scope | LFID | Discord ID | Email | Company Affiliation | |
| 25 | +|----- | --------- | ----- | ---- | ---------- | ----- | ------------------- | |
| 26 | +| | | | | | | | |
| 27 | + |
| 28 | +## The Duties of a Maintainer |
| 29 | + |
| 30 | +Maintainers are expected to perform the following duties for this repository. The duties are listed in more or less priority order: |
| 31 | + |
| 32 | +- Review, respond, and act on any security vulnerabilities reported against the repository. |
| 33 | +- Review, provide feedback on, and merge or reject GitHub Pull Requests from |
| 34 | + Contributors. |
| 35 | +- Review, triage, comment on, and close GitHub Issues |
| 36 | + submitted by Contributors. |
| 37 | +- When appropriate, lead/facilitate architectural discussions in the community. |
| 38 | +- When appropriate, lead/facilitate the creation of a product roadmap. |
| 39 | +- Create, clarify, and label issues to be worked on by Contributors. |
| 40 | +- Ensure that there is a well defined (and ideally automated) product test and |
| 41 | + release pipeline, including the publication of release artifacts. |
| 42 | +- When appropriate, execute the product release process. |
| 43 | +- Maintain the repository CONTRIBUTING.md file and getting started documents to |
| 44 | + give guidance and encouragement to those wanting to contribute to the product, and those wanting to become maintainers. |
| 45 | +- Contribute to the product via GitHub Pull Requests. |
| 46 | +- Monitor requests from the LF Decentralized Trust Technical Advisory Council about the |
| 47 | +contents and management of LFDT repositories, such as branch handling, |
| 48 | +required files in repositories and so on. |
| 49 | +- Contribute to the LFDT Project's Quarterly Report. |
| 50 | + |
| 51 | +## Becoming a Maintainer |
| 52 | + |
| 53 | +This community welcomes contributions. Interested contributors are encouraged to |
| 54 | +progress to become maintainers. To become a maintainer the following steps |
| 55 | +occur, roughly in order. |
| 56 | + |
| 57 | +- The proposed maintainer establishes their reputation in the community, |
| 58 | + including authoring five (5) significant merged pull requests, and expresses |
| 59 | + an interest in becoming a maintainer for the repository. |
| 60 | +- A PR is created to update this file to add the proposed maintainer to the list of active maintainers. |
| 61 | +- The PR is authored by an existing maintainer or has a comment on the PR from an existing maintainer supporting the proposal. |
| 62 | +- The PR is authored by the proposed maintainer or has a comment on the PR from the proposed maintainer confirming their interest in being a maintainer. |
| 63 | + - The PR or comment from the proposed maintainer must include their |
| 64 | + willingness to be a long-term (more than 6 month) maintainer. |
| 65 | +- Once the PR and necessary comments have been received, an approval timeframe begins. |
| 66 | +- The PR **MUST** be communicated on all appropriate communication channels, including relevant community calls, chat channels and mailing lists. Comments of support from the community are welcome. |
| 67 | +- The PR is merged and the proposed maintainer becomes a maintainer if either: |
| 68 | + - Two weeks have passed since at least three (3) Maintainer PR approvals have been recorded, OR |
| 69 | + - An absolute majority of maintainers have approved the PR. |
| 70 | +- If the PR does not get the requisite PR approvals, it may be closed. |
| 71 | +- Once the add maintainer PR has been merged, any necessary updates to the GitHub Teams are made. |
| 72 | + |
| 73 | +## Removing Maintainers |
| 74 | + |
| 75 | +Being a maintainer is not a status symbol or a title to be carried |
| 76 | +indefinitely. It will occasionally be necessary and appropriate to move a |
| 77 | +maintainer to emeritus status. This can occur in the following situations: |
| 78 | + |
| 79 | +- Resignation of a maintainer. |
| 80 | +- Violation of the Code of Conduct warranting removal. |
| 81 | +- Inactivity. |
| 82 | + - A general measure of inactivity will be no commits or code review comments |
| 83 | + for one reporting quarter. This will not be strictly enforced if |
| 84 | + the maintainer expresses a reasonable intent to continue contributing. |
| 85 | + - Reasonable exceptions to inactivity will be granted for known long term |
| 86 | + leave such as parental leave and medical leave. |
| 87 | +- Other circumstances at the discretion of the other Maintainers. |
| 88 | + |
| 89 | +The process to move a maintainer from active to emeritus status is comparable to the process for adding a maintainer, outlined above. In the case of voluntary |
| 90 | +resignation, the Pull Request can be merged following a maintainer PR approval. If the removal is for any other reason, the following steps **SHOULD** be followed: |
| 91 | + |
| 92 | +- A PR is created to update this file to move the maintainer to the list of emeritus maintainers. |
| 93 | +- The PR is authored by, or has a comment supporting the proposal from, an existing maintainer or a member of the project's Technical Steering Commitee (TSC). |
| 94 | +- Once the PR and necessary comments have been received, the approval timeframe begins. |
| 95 | +- The PR **MAY** be communicated on appropriate communication channels, including relevant community calls, chat channels and mailing lists. |
| 96 | +- The PR is merged and the maintainer transitions to maintainer emeritus if: |
| 97 | + - The PR is approved by the maintainer to be transitioned, OR |
| 98 | + - Two weeks have passed since at least three (3) Maintainer PR approvals have been recorded, OR |
| 99 | + - An absolute majority of maintainers have approved the PR. |
| 100 | +- If the PR does not get the requisite PR approvals, it may be closed. |
| 101 | + |
| 102 | +Returning to active status from emeritus status uses the same steps as adding a |
| 103 | +new maintainer. Note that the emeritus maintainer already has the 5 required |
| 104 | +significant changes as there is no contribution time horizon for those. |
0 commit comments