besu/MAINTAINERS.md

Maintainers

Active Maintainers

Name	Github	LFID
Abdel Bakhta	abdelhamidbakhta	abdelhamidbakhta
Adrian Sutton	ajsutton	ajsutton
Antoine Toulme	atoulme	atoulme
Byron Gravenorst	bgravenorst	bgravenorst
David Mechler	davemec	davemec
Edward Mack	edwardmack	mackcom
Gary Schulte	garyschulte	GarySchulte
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
Karim Taam	matkt	matkt
Meredith Baxter	mbaxter	mbaxter
Nicolas Massart	NicolasMassart	NicolasMassart
Stefan Pingel	pinges	pinges
Trent Mohay	rain-on	trent.mohay
Rai Sur	RatanRSur	ratanraisur
Danno Ferrin	shemnon	shemnon
Usman Saleem	usmansaleem	usmansaleem

Emeritus Maintainers

Name	Github	LFID
Chris Hare	CjHare	cjhare
Edward Evans	EdJoJob	EdJoJob
Ivaylo Kirilov	iikirilov	iikirilov
Rob Dawson	rojotek	RobDawson
Tim Beiko	timbeiko	timbeiko

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.