mirror of https://github.com/aya-rs/aya
Add project governance documentation
Explains how Maintainers are selected and their responsibilities. Explains the Pull Request review workflow. Adds config for Mergify to enforce this workflow. Signed-off-by: Dave Tucker <dave@dtucker.co.uk>reviewable/pr679/r5
Dave Tucker
2 years ago
parent
73a34e1571
commit
082a5f111b
@ -0,0 +1,51 @@
|
|||||||
|
<!--
|
||||||
|
Thank you for your contribution to Aya! 🎉
|
||||||
|
|
||||||
|
For Work In Progress Pull Requests, please use the Draft PR feature.
|
||||||
|
|
||||||
|
Before submitting a Pull Request, please ensure you've done the following:
|
||||||
|
- 📖 Read the Aya Contributing Guide: https://github.com/aya-rs/aya/blob/main/CONTRIBUTING.md
|
||||||
|
- 📖 Read the Aya Code of Conduct: https://github.com/aya-rs/aya/blob/main/CODE_OF_CONDUCT.md
|
||||||
|
- 👷♀️ Create small PRs. In most cases this will be possible.
|
||||||
|
- ✅ Provide tests for your changes.
|
||||||
|
- 📝 Use descriptive commit messages: https://cbea.ms/git-commit/
|
||||||
|
- 📗 Update any related documentation.
|
||||||
|
|
||||||
|
-->
|
||||||
|
|
||||||
|
# Summary
|
||||||
|
<!---
|
||||||
|
Summarize the changes you're making here.
|
||||||
|
Detailed information belongs in the Git Commit messages.
|
||||||
|
Feel free to flag anything you thing needs a reviewer's attention.
|
||||||
|
-->
|
||||||
|
|
||||||
|
# Related Issues
|
||||||
|
<!--
|
||||||
|
For example:
|
||||||
|
|
||||||
|
- Closes: #1234
|
||||||
|
- Relates To: #1234
|
||||||
|
-->
|
||||||
|
|
||||||
|
# Added/updated tests?
|
||||||
|
|
||||||
|
_We strongly encourage you to add a test for your changes._
|
||||||
|
|
||||||
|
- [ ] Yes
|
||||||
|
- [ ] No, and this is why: _please replace this line with details on why tests
|
||||||
|
have not been included_
|
||||||
|
- [ ] I need help with writing tests
|
||||||
|
|
||||||
|
# Checklist
|
||||||
|
|
||||||
|
- [ ] Rust code has been formatted with `cargo +nightly fmt`.
|
||||||
|
- [ ] All clippy lints have been fixed.
|
||||||
|
You can find failing lints with `./clippy.sh`.
|
||||||
|
- [ ] Unit tests are passing locally with `cargo test`.
|
||||||
|
- [ ] The [Integration tests] are passing locally.
|
||||||
|
- [ ] I have blessed any API changes with `cargo xtask public-api --bless`.
|
||||||
|
|
||||||
|
[Integration tests]: https://github.com/aya-rs/aya/blob/main/test/README.md
|
||||||
|
|
||||||
|
# (Optional) What GIF best describes this PR or how it makes you feel?
|
||||||
@ -0,0 +1 @@
|
|||||||
|
* @aya-rs/aya-maintainers
|
||||||
@ -0,0 +1,163 @@
|
|||||||
|
# Aya Project Governance
|
||||||
|
|
||||||
|
The Aya project is dedicated to creating the best user experience when using
|
||||||
|
eBPF from Rust, whether that's in user-land or kernel-land. This governance
|
||||||
|
explains how the project is run.
|
||||||
|
|
||||||
|
- [Values](#values)
|
||||||
|
- [Maintainers](#maintainers)
|
||||||
|
- [Becoming a Maintainer](#becoming-a-maintainer)
|
||||||
|
- [Meetings](#meetings)
|
||||||
|
- [Code of Conduct Enforcement](#code-of-conduct)
|
||||||
|
- [Security Response Team](#security-response-team)
|
||||||
|
- [Voting](#voting)
|
||||||
|
- [Modifications](#modifying-this-charter)
|
||||||
|
|
||||||
|
## Values
|
||||||
|
|
||||||
|
The Aya project and its leadership embrace the following values:
|
||||||
|
|
||||||
|
- Openness: Communication and decision-making happens in the open and is
|
||||||
|
discoverable for future reference. As much as possible, all discussions and
|
||||||
|
work take place in public forums and open repositories.
|
||||||
|
|
||||||
|
- Fairness: All stakeholders have the opportunity to provide feedback and submit
|
||||||
|
contributions, which will be considered on their merits.
|
||||||
|
|
||||||
|
- Community over Product or Company: Sustaining and growing our community takes
|
||||||
|
priority over shipping code or sponsors' organizational goals. Each
|
||||||
|
contributor participates in the project as an individual.
|
||||||
|
|
||||||
|
- Inclusivity: We innovate through different perspectives and skill sets, which
|
||||||
|
can only be accomplished in a welcoming and respectful environment.
|
||||||
|
|
||||||
|
- Participation: Responsibilities within the project are earned through
|
||||||
|
participation, and there is a clear path up the contributor ladder into
|
||||||
|
leadership positions.
|
||||||
|
|
||||||
|
## Maintainers
|
||||||
|
|
||||||
|
Aya Maintainers have write access to the all projects in the
|
||||||
|
[GitHub organization]. They can merge their patches or patches from others.
|
||||||
|
The list of current maintainers can be found at [MAINTAINERS.md].
|
||||||
|
Maintainers collectively manage the project's resources and contributors.
|
||||||
|
|
||||||
|
This privilege is granted with some expectation of responsibility: maintainers
|
||||||
|
are people who care about the Aya project and want to help it grow and
|
||||||
|
improve. A maintainer is not just someone who can make changes, but someone who
|
||||||
|
has demonstrated their ability to collaborate with the team, get the most
|
||||||
|
knowledgeable people to review code and docs, contribute high-quality code, and
|
||||||
|
follow through to fix issues (in code or tests).
|
||||||
|
|
||||||
|
A maintainer is a contributor to the project's success and a citizen helping
|
||||||
|
the project succeed.
|
||||||
|
|
||||||
|
The collective team of all Maintainers is known as the Maintainer Council, which
|
||||||
|
is the governing body for the project.
|
||||||
|
|
||||||
|
### Becoming a Maintainer
|
||||||
|
|
||||||
|
To become a Maintainer, you need to demonstrate a commitment to the project, an
|
||||||
|
ability to write quality code and/or documentation, and an ability to
|
||||||
|
collaborate with the team. The following list is an example of the
|
||||||
|
the kind of contributions that would be expected to be promoted to Maintainer
|
||||||
|
status however there is no strict requirement for all points to be met:
|
||||||
|
|
||||||
|
- Commitment to the project, as evidenced by:
|
||||||
|
- Participate in discussions, contributions, code and documentation reviews,
|
||||||
|
for 6 months or more.
|
||||||
|
- Perform reviews for 10 non-trivial pull requests.
|
||||||
|
- Contribute 10 non-trivial pull requests and have them merged.
|
||||||
|
- Ability to write quality code and/or documentation.
|
||||||
|
- Ability to collaborate with the team.
|
||||||
|
- Understanding of how the team works (policies, processes for testing
|
||||||
|
and code review, etc).
|
||||||
|
- Understanding of the project's code base and coding and documentation style.
|
||||||
|
|
||||||
|
A new Maintainer must be proposed by an existing maintainer by opening a
|
||||||
|
Pull Request on GitHub to update the MAINTAINERS.md file. A simple majority vote
|
||||||
|
of existing Maintainers approves the application. Maintainer nominations will be
|
||||||
|
evaluated without prejudice to employers or demographics.
|
||||||
|
|
||||||
|
Maintainers who are selected will be granted the necessary GitHub rights.
|
||||||
|
|
||||||
|
### Removing a Maintainer
|
||||||
|
|
||||||
|
Maintainers may resign at any time if they feel that they will not be able to
|
||||||
|
continue fulfilling their project duties. Resignations should be communicated
|
||||||
|
via GitHub Pull Request to update the [MAINTAINERS.md] file. Approving
|
||||||
|
resignations does not require a vote.
|
||||||
|
|
||||||
|
Maintainers may also be removed after being inactive, failing to fulfill their
|
||||||
|
Maintainer responsibilities, violating the Code of Conduct, or for other reasons.
|
||||||
|
Inactivity is defined as a period of very low or no activity in the project
|
||||||
|
for a year or more, with no definite schedule to return to full Maintainer
|
||||||
|
activity.
|
||||||
|
|
||||||
|
The process for removing a maintainer is for an existing maintainer to open
|
||||||
|
a Pull Request on GitHub to update the [MAINTAINERS.md] file. The commit
|
||||||
|
message should explain the reason for removal. The Pull Request will be
|
||||||
|
voted on by the remaining maintainers. A 2/3 majority vote is required to
|
||||||
|
remove a maintainer.
|
||||||
|
|
||||||
|
Depending on the reason for removal, a Maintainer may be converted to Emeritus
|
||||||
|
status. Emeritus Maintainers will still be consulted on some project matters
|
||||||
|
and can be rapidly returned to Maintainer status if their availability changes.
|
||||||
|
However, Emeritus Maintainers will not have write access to the project's
|
||||||
|
repositories.
|
||||||
|
|
||||||
|
The process for making an Emeritus Maintainer is the same as for removing a
|
||||||
|
Maintainer, except that the [MAINTAINERS.md] file should be updated to reflect
|
||||||
|
the Emeritus status rather than removing the Maintainer entirely.
|
||||||
|
|
||||||
|
The process for returning an Emeritus Maintainer is via Pull Request
|
||||||
|
to update the [MAINTAINERS.md] file. A simple majority vote of existing
|
||||||
|
Maintainers approves the return.
|
||||||
|
|
||||||
|
## Meetings
|
||||||
|
|
||||||
|
There are no standing meetings for Maintainers.
|
||||||
|
|
||||||
|
Maintainers may have closed meetings to discuss security reports
|
||||||
|
or Code of Conduct violations. Such meetings should be scheduled by any
|
||||||
|
Maintainer on receipt of a security issue or CoC report. All current Maintainers
|
||||||
|
must be invited to such closed meetings, except for any Maintainer who is
|
||||||
|
accused of a CoC violation.
|
||||||
|
|
||||||
|
## Code of Conduct
|
||||||
|
|
||||||
|
[Code of Conduct] violations by community members will be
|
||||||
|
discussed and resolved on the private maintainer Discord channel.
|
||||||
|
|
||||||
|
## Security Response Team
|
||||||
|
|
||||||
|
The Maintainers will appoint a Security Response Team to handle security
|
||||||
|
reports. This committee may simply consist of the Maintainer Council themselves.
|
||||||
|
If this responsibility is delegated, the Maintainers will appoint a team of at
|
||||||
|
least two contributors to handle it. The Maintainers will review who is assigned
|
||||||
|
to this at least once a year.
|
||||||
|
|
||||||
|
The Security Response Team is responsible for handling all reports of security
|
||||||
|
holes and breaches according to the [security policy].
|
||||||
|
|
||||||
|
## Voting
|
||||||
|
|
||||||
|
While most business in Aya is conducted by [lazy consensus], periodically the
|
||||||
|
Maintainers may need to vote on specific actions or changes.
|
||||||
|
A vote can be taken on the private developer Discord channel for security or
|
||||||
|
conduct matters. Any Maintainer may demand a vote be taken.
|
||||||
|
|
||||||
|
Most votes require a simple majority of all Maintainers to succeed, except where
|
||||||
|
otherwise noted. Two-thirds majority votes mean at least two-thirds of all
|
||||||
|
existing maintainers.
|
||||||
|
|
||||||
|
## Modifying this Charter
|
||||||
|
|
||||||
|
Changes to this Governance and its supporting documents may be approved by
|
||||||
|
a 2/3 vote of the Maintainers.
|
||||||
|
|
||||||
|
[GitHub organization]: https://github.com/aya-rs
|
||||||
|
[Code of Conduct]: ./CODE_OF_CONDUCT.md
|
||||||
|
[MAINTAINERS.md]: ./MAINTAINERS.md
|
||||||
|
[security policy]: ./SECURITY.md
|
||||||
|
[lazy consensus]: https://community.apache.org/committers/lazyConsensus.html
|
||||||
@ -0,0 +1,27 @@
|
|||||||
|
# Maintainers
|
||||||
|
|
||||||
|
See [CONTRIBUTING.md](./CONTRIBUTING.md) for general contribution guidelines.
|
||||||
|
See [GOVERNANCE.md](./GOVERNANCE.md) for governance guidelines and maintainer
|
||||||
|
responsibilities.
|
||||||
|
See [CODEOWNERS](./CODEOWNERS) for a detailed list of owners for the various
|
||||||
|
source directories.
|
||||||
|
|
||||||
|
We use MAINTAINERS.md to track active maintainers and emeritus maintainers
|
||||||
|
rather than relying solely on GitHub teams. This codifies the process for
|
||||||
|
adding and removing maintainers as well, provides transparency, and leaves
|
||||||
|
an audit trail in the git history.
|
||||||
|
|
||||||
|
## Active Maintainers
|
||||||
|
|
||||||
|
- @ajwerner
|
||||||
|
- @alessandrod
|
||||||
|
- @astoycos
|
||||||
|
- @dave-tucker
|
||||||
|
- @davibe
|
||||||
|
- @marysaka
|
||||||
|
- @tamird
|
||||||
|
- @vadorovsky
|
||||||
|
|
||||||
|
## Emeritus Maintainers
|
||||||
|
|
||||||
|
None
|
||||||
@ -0,0 +1,23 @@
|
|||||||
|
# Security Policy
|
||||||
|
|
||||||
|
## Supported Versions
|
||||||
|
|
||||||
|
No released versions of aya or its subprojects will receive regular security
|
||||||
|
updates until a mainline release has been performed.
|
||||||
|
A reported and fixed vulnerability will be included in the next minor release,
|
||||||
|
which depending on the severity of the vulnerability may be immediate.
|
||||||
|
|
||||||
|
## Reporting a Vulnerability
|
||||||
|
|
||||||
|
To report a vulnerability, please use the
|
||||||
|
[Private Vulnerability Reporting Feature] on GitHub. We will endevour to respond
|
||||||
|
within 48hrs of reporting.
|
||||||
|
|
||||||
|
If a vulnerability is reported but considered low priority it may be converted
|
||||||
|
into an issue and handled on the public issue tracker.
|
||||||
|
|
||||||
|
Should a vulnerability be considered severe we will endeavour to patch it within
|
||||||
|
48hrs of acceptance, and may ask for you to collaborate with us on a temporary
|
||||||
|
private fork of the repository.
|
||||||
|
|
||||||
|
[Private Vulnerability Reporting Feature]: https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing/privately-reporting-a-security-vulnerability
|
||||||
Loading…
Reference in New Issue