Skip to content

Latest commit

 

History

History
128 lines (107 loc) · 8.21 KB

MAINTAINERS.md

File metadata and controls

128 lines (107 loc) · 8.21 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 identus-maintainers

Active Maintainers

Name GitHub ID Scope LFID Discord ID Email Company Affiliation
Allain Magyar amagyar-iohk Maintainer _ [email protected] IOG
Javier Labrador elribonazo Maintainer elribonazo [email protected] IOG
Yurii Shynbuiev yshyn-iohk Maintainer yuriishynbuiev [email protected] IOG
Fabio Pinheiro FabioPinheiro Maintainer fmgp [email protected] IOG
Benjamin Voiturier bvoiturier Maintainer bvoiturier [email protected] IOG
Curtis Harding curtis-h Maintainer _ [email protected] IOG
Goncalo Frade goncalo-frade-iohk Maintainer goncalofrade_20576 [email protected] IOG
Shailesh Patil mineme0110 Maintainer mineme110 [email protected] IOG
Björn Sandmann bsandmann Maintainer bjoernsandmann [email protected] Blocktrust
Mix Irvin mixmix Maintainer mixmix Ahau

Emeritus Maintainers

Name GitHub ID Scope LFID Discord ID Email Company Affiliation
Anton Baliasnikov antonbaliasnikov Maintainer
Ahmed Moussa hamada147 Maintainer
Timothy Wells blockchaintimothy Maintainer timw_01400
Cristian Gonzalez cristianIOHK Maintainer chet_to
Dale Peek Dale-iohk Maintainer dale.doe
Bassam Riman CryptoKnightIOG Maintainer _
David Poltorak davepoltorak Maintainer davidpoltorak_io
Esteban Garcia essbante-io Maintainer essbante
Ezequiel Postan EzequielPostan Maintainer _
Fayyaadh Adams FayyaadhAdams Maintainer .fayyaadh
Lohan Spies lohanspies Maintainer _
Milos Backonja milosbackonja Maintainer _
Miloš Džepina milosh86 Maintainer milosdz_60141
Michael Breuninger mkbreuningIOHK Maintainer mkbreuning_45483
Pat Losoponkul patlo-iog Maintainer _pat_pat
Peter Vielhaber petevielhaber Maintainer petev_iog
Shota Jolbordi shotexa Maintainer xesus1337
Kranium Mendoza womfoo Maintainer kraniumau

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.