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>pull/679/head
Dave Tucker
1 year ago
parent
8778c4ca29
commit
bf4722d67a
@ -0,0 +1,2 @@
|
||||
* @aya-rs/aya-maintainers
|
||||
aya/src/public-api.txt @alessandrod
|
||||
@ -0,0 +1,131 @@
|
||||
# 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](https://github.com/aya-rs).
|
||||
They can merge their patches or patches from others. The list of current maintainers
|
||||
can be found at [MAINTAINERS.md](./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 the following:
|
||||
|
||||
- commitment to the project:
|
||||
- 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.
|
||||
|
||||
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.
|
||||
|
||||
A Maintainer may be removed at any time by a 2/3 vote of the remaining maintainers.
|
||||
|
||||
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.
|
||||
|
||||
## Meetings
|
||||
|
||||
There are no standing meetings for Maintainers.
|
||||
|
||||
Maintainers will also 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](./CODE_OF_CONDUCT.md) 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](./SECURITY.md).
|
||||
|
||||
## Voting
|
||||
|
||||
While most business in Aya is conducted by "[lazy consensus](https://community.apache.org/committers/lazyConsensus.html)",
|
||||
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.
|
||||
@ -0,0 +1,16 @@
|
||||
# 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.
|
||||
|
||||
| Name | Employer | Areas of Expertise |
|
||||
| ---- | -------- | ------------------ |
|
||||
| [Alessandro Decina](https://github.com/alessandrod) | Contractor | Everything! |
|
||||
| [Michal Rostecki](https://github.com/vadorovsky) | Light Protocol | Aya Log, LSM |
|
||||
| [Dave Tucker](https://github.com/dave-tucker) | Red Hat | sys_bpf(), BTF, Networking and Tracing Programs, bppfs |
|
||||
| [Davide Bertola](https://github.com/davibe) | ? | bpf-linker, LLVM |
|
||||
| [Mary](https://github.com/marysaka) | ? | Compatibility with older kernels |
|
||||
| [](https://github.com/ajwerner) | ? | ? |
|
||||
| [Tamir Duberstein](https://github.com/tamird) | ? | ? |
|
||||
| [Andrew Stoycos](https://github.com/astoycos) | Red Hat | ? |
|
||||
@ -0,0 +1,13 @@
|
||||
# Security Policy
|
||||
|
||||
## Supported Versions
|
||||
|
||||
No released versions of aya or it's 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](https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing/privately-reporting-a-security-vulnerability)
|
||||
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.
|
||||
Loading…
Reference in New Issue