Skip to content

Latest commit

 

History

History
90 lines (77 loc) · 4.17 KB

MAINTAINERS.md

File metadata and controls

90 lines (77 loc) · 4.17 KB
Raw

Maintainers

Active Maintainers

Name Github LFID
Abdel Bakhta abdelhamidbakhta abdelhamidbakhta
Adrian Sutton ajsutton ajsutton
Byron Gravenorst bgravenorst bgravenorst
Chris Hare CjHare cjhare
Edward Evans EdJoJob EdJoJob
Ivaylo Kirilov iikirilov iikirilov
Jason Frame jframe jframe
Joshua Fernandes joshuafernandes joshuafernandes
Lucas Saldanha lucassaldanha lucassaldanha
Sally MacFarlane macfarla macfarla
Madeline Murray MadelineMurray madelinemurray
Mark Terry mark-terry m.terry
Meredith Baxter mbaxter mbaxter
Nicolas Massart NicolasMassart NicolasMassart
Trent Mohay rain-on trent.mohay
Rai Sur RatanRSur ratanraisur
Rob Dawson rojotek RobDawson
Danno Ferrin shemnon shemnon
Tim Beiko timbeiko timbeiko
Usman Saleem usmansaleem usmansaleem

Emeritus Maintainers

None.

Becoming a Maintainer

Besu welcomes community contribution. Community members may progress to become a maintainer. To become a maintainer the following steps occur, roughly in order.

  • 5 significant changes have been authored by the proposed maintainer and accepted.
  • The proposed maintainer has the sponsorship of at least one other maintainer.
    • This sponsoring maintainer will create a PR modifying the list of maintainers.
    • The proposed maintainer accepts the nomination and expresses a willingness to be a long-term (more than 6 month) committer.
    • This would be a comment in the above PR.
    • This PR will be communicated in all appropriate communication channels. It should be mentioned in any maintainer/community call. It should also be posted to the appropriate mailing list or chat channels if they exist.
  • Approval by at least 3 current maintainers within two weeks of the proposal or an absolute majority of current maintainers.
    • These votes will be recorded in the PR modifying the list of maintainers.
  • No veto by another maintainer within two weeks of proposal are recorded.
    • All vetoes must be accompanied by a public explanation as a comment in the PR for adding this maintainer
    • The explanation of the veto must be reasonable.
    • A veto can be retracted, in that case the approval/veto timeframe is reset.
    • It is bad form to veto, retract, and veto again.
  • The proposed maintainer becomes a maintainer
    • Either two weeks have passed since the third approval,
    • Or an absolute majority of maintainers approve.
    • In either case, no maintainer presents a veto.

Removing Maintainers

Being a maintainer is not a status symbol or a title to be maintained indefinitely. It will occasionally be necessary and appropriate to move a maintainer to emeritus status. This 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, although this 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 unspecified circumstances.

Like adding a maintainer the record and governance process for moving a maintainer to emeritus status is recorded in the github PR making that change.

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.