Maintainers are assigned the following scopes in this repository:
Scope | Definition | GitHub Role | GitHub Team |
---|---|---|---|
Maintainer | The GitHub Maintain role | Maintain | open-enterprise-agent-maintainers |
Name | GitHub ID | Scope | LFID | Discord ID | Company Affiliation | |
---|---|---|---|---|---|---|
Björn Sandmann | bsandmann | Maintainer | bjoernsandmann | [email protected] | Blocktrust | |
David Poltorak | davidpoltorak-io | Maintainer | davidpoltorak_io | [email protected] | IOHK | |
Pat Losoponkul | patlo-iog | Maintainer | pat_pat | [email protected] | IOHK | |
Yurii Shynbuiev | yshyn-iohk | Maintainer | yuriishynbuiev | [email protected] | IOHK |
Name | GitHub ID | Scope | LFID | Discord ID | Company Affiliation | |
---|---|---|---|---|---|---|
Anton Baliasnikov | antonbaliasnikov | Maintainer | [email protected] |
The expectation is for maintainers to perform the following duties for this repository. The responsibilities listed are in high to low-priority order:
- Review, respond, and act on any security vulnerabilities reported against the repository.
- Review, provide feedback on, and merge or reject GitHub Pull Requests from Contributors.
- Review, triage, comment on, and close GitHub Issues submitted by Contributors.
- When appropriate, lead/facilitate architectural discussions in the community.
- When appropriate, lead/facilitate the creation of a product roadmap.
- Create, clarify, and label issues to be worked on by Contributors.
- Ensure that there is a well-defined (and ideally automated) product test and release pipeline, including the publication of release artifacts.
- When appropriate, execute the product release process.
- Maintain the repository CONTRIBUTING.md file and getting started documents to give guidance and encouragement to those wanting to contribute to the product and become maintainers.
- Contribute to the product via GitHub Pull Requests.
- Monitor requests from the Hyperledger Technical Oversight Committee about the contents and management of Hyperledger repositories, such as branch handling, required files in repositories, etc.
- Contribute to the Hyperledger Project's Quarterly Report.
This community welcomes contributions. Interested contributors are encouraged to progress to become maintainers. To become a maintainer, the following steps occur roughly in order.
- 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. A PR has been created to update this file and add the proposed maintainer to the list of active maintainers.
- An existing maintainer authors the PR or has a comment on the PR from an existing maintainer supporting the proposal.
- The proposed maintainer authors the PR or has a comment from the proposed maintainer confirming their interest in being a maintainer.
- The PR or comment from the proposed maintainer must include their willingness to be a long-term (more than 6 months) maintainer.
- An approval timeframe begins once the PR and necessary comments are received.
- The PR MUST be communicated on all appropriate channels, including relevant community calls, chat channels, and mailing lists. The community's comments of support are welcome.
- The PR gets merged, and the proposed maintainer becomes a maintainer if either:
- Two weeks have passed since the receipt of at least three (3) Maintainer PR approvals, OR
- An absolute majority of maintainers have approved the PR.
- It may be closed if the PR does not get the requisite PR approvals.
- Once the add maintainer PR merges, any updates to the GitHub Teams are made.
Being a maintainer is not a status symbol or a title or indefinite. Moving the maintainer to emeritus status will occasionally be necessary and appropriate. The status change can occur in the following situations:
- Resignation of a maintainer.
- Violation of the Code of Conduct warranting removal.
- Inactivity.
- A general measure of inactivity will be no commits or code review comments for one reporting quarter. Inactivity will not be strictly enforced if the maintainer expresses a reasonable intent to continue contributing.
- Reasonable exceptions to inactivity will be granted for known long-term leave such as parental leave and medical leave.
- Other circumstances are at the discretion of the other maintainers.
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 resignation, the Pull Request is mergeable following a maintainer PR approval. If the removal is for any other reason, the following steps SHOULD be followed:
- A PR has been created to update this file and move the maintainer to the list of emeritus maintainers.
- The PR is authored by or has a comment supporting the proposal from an existing maintainer or Hyperledger GitHub organization administrator.
- The approval timeframe begins upon receipt of the PR and necessary comments.
- The PR MAY be communicated on appropriate channels, including relevant community calls, chat channels, and mailing lists.
- The PR gets merged, and the maintainer transitions to maintainer emeritus if:
- The PR gets approval from the maintainer to transition, OR
- Two weeks have passed since receipt of at least three (3) Maintainer PR approvals, OR
- An absolute majority of maintainers have approved the PR.
- It may be closed if the PR does not get the requisite PR approvals.
Returning to active status from emeritus status uses the same steps as adding a new maintainer. Note that the emeritus maintainer already has the 5 required significant changes, as there is no contribution time horizon for those.