The following is a list of all the maintainers of the Hyperledger FireFly . Each maintainer may be a Codeowner of one or more GitHub repos within the project.
Name | Email Address | GitHub ID | Discord Username | |
---|---|---|---|---|
Alexey Semenyuk | aliaksei.semianiuk@instinctools.com | @alex-semenyuk | @alexey_semenyuk | |
Dzianis Andreyenka | dzianis.andreyenka@instinctools.com | @denisandreenko | @darusolog | |
Peter Broadhurst | peter.broadhurst@kaleido.io | @peterbroadhurst | @peterbroadhurst#9261 | |
Vinode Damle | vinod.damle@fmr.com | @vdamle | @peanuts2667 | |
David Echelberger | david.echelberger@kaleido.io | @eberger727 | @dech.dev | |
Hayden Fuss | hayden.fuss@kaleido.io | @hfuss | ||
Nick Gaski | @nickgaski | @nickgaski#8739 | ||
Nicko Guyer | @nguyer | @alpha7shooter | ||
@hfus#0446 | ||||
Gabriel Indik | gabriel.indik@kaleido.io | Gabriel Indik@gabriel-indik | @Gabriel Indik#9348 | |
Andrew Richardson | andrew.richardson@kaleido.io | @awrichar | @andrew.richardson | |
Alex Shorsher | alex.shorsher@kaleido.io | @shorsher | @shorsher | |
Matthew Whitehead | matthew.whitehead@kaleido.io | @matthew1001 | @matthew.whitehead | |
Chengxuan Xing | chengxuan.xing@kaleido.io | @Chengxuan | @xingchxuan | |
Jim Zhang | jim.zhang@kaleido.io | @jimthematrix | @jimthematrix | |
Enrique Lacal | enrique.lacal@kaleido.io | @enriquel8 | @enriquel8 | |
Sam May | sam.may@kaleido.io | @sammaywork | @samuel_may |
Each maintainer may be a maintainer (code owner) of one or more GitHub repos within the project. Each repository contains a list of the maintainers for that specific repo and a CODEOWNERS
file which points to the corresponding GitHub team. For a list of maintainers by repo, please see this page in GitHub: https://github.com/orgs/hyperledger/teams/firefly-maintainers/teams
Expectations of Maintainers
Maintainers are expected to regularly:
- Make contributions to FireFly code repositories including code or documentation
- Review pull requests
- Investigate open GitHub issues
- Participate in Community Calls
Becoming a Maintainer
The FireFly Project welcomes and encourages people to become maintainers of the project if they are interested and meet the following criteria:
Criteria for becoming a member
- Expressed interest and commitment to meet the expectations of a maintainer
- A consistent track record of contributions to FireFly code repositories which could be:
- Enhancements
- Bug fixes
- Tests
- Documentation
- A consistent track record of helpful code reviews on FireFly code repositories
- Regular participation in Community Calls
- A demonstrated interest and aptitude in thought leadership within the FireFly Project
- Sponsorship from an existing maintainer
There is no specific quantity of contributions or pull requests, or a specific time period over which the candidate must prove their track record. This will be left up to the discretion of the existing maintainers.
Process for becoming a maintainer
Once the above criteria have been met, the sponsoring maintainer shall propose the addition of the new maintainer at a public Community Call. Existing maintainers shall vote at the next public Community Call whether the new maintainer should be added or not. Proxy votes may be submitted via email before the meeting. A simple majority of the existing maintainers is required for the vote to pass.
A vote to add a maintainer, is a vote to acknowledge that someone meets the criteria for becoming a maintainer, and to designate that person as someone who represents the open source Hyperledger FireFly project and community. The specific decision of which GitHub repositories a maintainer is given responsibility for does not require a vote and is left up to the discretion of the existing maintainers.
Maintainer resignation
While maintainers are expected in good faith to be committed to the project for a significant period of time, they are under no binding obligation to do so. Maintainers may resign at any time for any reason.
Maintainer inactivity
If a maintainer has remained inactive (not meeting the expectations of a maintainer) for a period of time (at least several months), an email should be sent to that maintainer noting their inactivity and asking if they still wish to be a maintainer. If they continue to be inactive after being notified via email, an existing maintainer may propose to remove the inactive maintainer at a public Community Call. Existing maintainers shall vote at the next public Community Call whether the inactive maintainer should be removed or not. Proxy votes may be submitted via email before the meeting. A simple majority of the existing maintainers is required for the vote to pass.