# 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.