Skip to content

Latest commit

 

History

History
106 lines (84 loc) · 6.19 KB

MAINTAINERS.md

File metadata and controls

106 lines (84 loc) · 6.19 KB
Raw

Maintainers

Maintainer Scopes, GitHub Roles and GitHub Teams

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

Active Maintainers

Name GitHub ID Scope LFID Discord ID Email Company Affiliation
Björn Sandmann bsandmann Maintainer bjoernsandmann sandmann@codedata.solutions Blocktrust
David Poltorak davidpoltorak-io Maintainer davidpoltorak_io david.poltorak@iohk.io IOHK
Pat Losoponkul patlo-iog Maintainer pat_pat pat.losoponkul@iohk.io IOHK
Yurii Shynbuiev yshyn-iohk Maintainer yuriishynbuiev yurii.shynbuiev@iohk.io IOHK

Emeritus Maintainers

Name GitHub ID Scope LFID Discord ID Email Company Affiliation
Anton Baliasnikov antonbaliasnikov Maintainer antonbaliasnikov@gmail.com

The Duties of a Maintainer

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.

Becoming a Maintainer

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.

Removing Maintainers

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.