| Name | Github | LFID |
|---|---|---|
| Abdel Bakhta | abdelhamidbakhta | abdelhamidbakhta |
| Adrian Sutton | ajsutton | ajsutton |
| Antony Denyer | antonydenyer | antonydenyer |
| Antoine Toulme | atoulme | atoulme |
| Byron Gravenorst | bgravenorst | bgravenorst |
| Daniel Lehrner | daniellehrner | daniellehrner |
| Diego López León | diega | diega |
| Fabio Di Fabio | fab-10 | fab-10 |
| Frank Li | frankisawesome | frankliawesome |
| Gary Schulte | garyschulte | GarySchulte |
| Jiri Peinlich | gezero | JiriPeinlich |
| Justin Florentine | jflo | RoboCopsGoneMad |
| 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 |
| Rai Sur | RatanRSur | ratanraisur |
| Sajida Zouarhi | sajz | SajidaZ |
| Danno Ferrin | shemnon | shemnon |
| Simon Dudley | siladu | siladu |
| Taccat Isid | taccatisid | taccatisid |
| Usman Saleem | usmansaleem | usmansaleem |
| Name | Github | LFID |
|---|---|---|
| Chris Hare | CjHare | cjhare |
| David Mechler | davemec | davemec |
| Edward Evans | EdJoJob | EdJoJob |
| Edward Mack | edwardmack | mackcom |
| Ivaylo Kirilov | iikirilov | iikirilov |
| Trent Mohay | rain-on | trent.mohay |
| Rob Dawson | rojotek | RobDawson |
| Tim Beiko | timbeiko | timbeiko |
| Vijay Michalik | vmichalik | VijayMichalik |
Besu welcomes community contribution. Each community member may progress to become a maintainer.
There are two ways to become a maintainer:
- Contribute significantly to the code in this repository.
- Contribute significantly to the doc or being recognized as great help by other contributors.
The requirement to be able to be proposed as a code maintainer is:
- 5 significant changes on code have been authored in this repos by the proposed maintainer and accepted (merged PRs).
The requirements to be able to be proposed as a non-code maintainer are:
- 5 significant changes on documentation have been authored in this repos by the proposed maintainer and accepted (merged pull-requests (PR), excluding hyperledger/besu-doc repos contribution).
- or 5 significant support answers on official public channels that solved the user issue.
- or being recognised as a fully involved and significant help for issue triage and assignment or roadmap planning effort and code review by other maintainers. There is no number defined for these criteria as the vote will decide if the criteria are valid.
For both types of maintainers, the following steps must occur for a contributor to be "upgraded" as a maintainer:
- The proposed maintainer meets the expectations for the targeted maintainership type (see code and non code types.)
- The proposed maintainer has the sponsorship of at least one other maintainer.
- This sponsoring maintainer will create a proposal PR modifying the list of maintainers. (see proposal PR template.)
- The proposed maintainer accepts the nomination and expresses a willingness to be a long-term (more than 6 month) committer by adding a comment in the proposal PR.
- The PR will be communicated in all appropriate communication channels including at least besu-contributors channel on Hyperledger Discord, the mailing list and any maintainer/community call.
- Approval by at least 3 current maintainers within two weeks of the proposal or
an absolute majority (half the total + 1) of current maintainers.
- Maintainers will vote by approving the proposal PR.
- No veto raised by another maintainer within the voting timeframe.
- All vetoes must be accompanied by a public explanation as a comment in the proposal PR.
- The explanation of the veto must be reasonable and follow the Besu code of conduct.
- A veto can be retracted, in that case the voting timeframe is reset and all approvals are removed.
- It is bad form to veto, retract, and veto again.
The proposed maintainer becomes a maintainer either:
- when two weeks have passed without veto since the third approval of the proposal PR,
- or an absolute majority of maintainers approved the proposal PR.
In either case, no maintainer raised and stood by a veto.
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 two reporting quarters, 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.
As for adding a maintainer, the record and governance process for moving a maintainer to emeritus status is recorded using review approval in the 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 always already has the required significant contributions. There is no contribution prescription delay.
I propose to add [maintainer github handle] as a Besu project maintainer.
<!-- for code contributors -->
[maintainer github handle] contributed with many high quality commits:
- [list significant achievements]
Here are [their past contributions on Besu project](https://github.com/hyperledger/besu/commits?author=[user github handle]).
<!-- for non-code contributors -->
[maintainer github handle] contributed with many high quality actions:
- [list significant actions]
Voting ends two weeks from today.
For more information on this process see the Becoming a Maintainer section in the MAINTAINERS.md file.