Maintainership-related decisions must be taken with respect to the rules established in our governance. This document provides guidelines for the implementation of these decisions.
Reviewers have no maintainers power, but behave similarly and therefore this document includes also guidelines for reviewers.
Both Maintainers and Reviewers are defined by OWNERS files. Most of the processes described below involve making pull requests (PRs) to correctly make changes to those files.
Table of Contents
- Organization membership
- Onboarding a Reviewer
- Onboarding a Maintainer
- Offboarding a Reviewer
- Offboarding a Maintainer
- Review maintainers activity
- Mentoring programs
Resources
- Governance
- Code Of Conduct
- Maintainers Guidelines
- Maintainers List
- Repositories Guidelines
- Repositories List
- Adopters List
- Contributing
- Security policy
- Join the Community
Maintainers and Reviewers are also organization members.
If they are not yet organization members, they should open a PR to add them to the members entry of org.yaml.
Maintainers are usually not removed from organization members because they become Emeritus Maintainers, unless they request so.
Former Reviewers are removed from the organization members if they are no longer listed in any OWNERS file.
If Community Members believe they match the criteria to become Reviewers of a repository (or a subdirectory) they can propose themselves by opening a PR to add themselves to the reviewers entry of the OWNERS of the repository (or the subdirectory). The person in question must publicly express their interest and should discuss it with the other persons listed in the OWNERS file and the community before proposing themself.
New reviewers can also be proposed and sponsored by existing Maintainers and Reviewers.
Maintainers will review the PR and decide.
If the decision is to grant the reviewer status, then the person in question must become a member of the falcosecurity Github organization (see the Organization membership section).
If Community Members believe they match the criteria to become Maintainers of a repository (or a subdirectory) they can propose themselves by opening a PR to add themselves to the approvers entry of the OWNERS of the repository (or the subdirectory). The person in question must publicly express their interest and should discuss it with the other persons listed in the OWNERS file and the community before proposing themself.
New maintainers can also be proposed and sponsored by existing Maintainers.
Maintainers will review the PR and decide. Before taking the decision, existing maintainers may ask the person in question to shadow them or apply for a reviewer position for a period.
If the decision is to grant the maintainer status, then the person in question must:
- Update the
people/affiliations.jsonfile by opening a PR to add their information. - If they aren't already, become a member of the falcosecurity Github organization (see the Organization membership section).
- Join with
*-maintainersGitHub team relative to the repository they became maintainer of (i.e. thefalco-maintainersteam for falcosecurity/falco); One can do so by opening a PR to change the org.yaml file. - Only for first-time core maintainers:
- also join with
core-maintainersteam; - go to https://maintainers.cncf.io/ and open a PR to be listed as a Falco maintainer;
- ask the CNCF to be added to the
cncf-falco-maintainers@lists.cncf.iomailing list.
- also join with
Reviewers of a repository (or a directory) can lose their status by voluntarily stepping down for personal reasons, an extended period of inactivity, a period of failing to meet the requirements for the role, a violation of the Code Of Conduct and/or at the maintainers' discretion.
In such a case, a PR is required to remove the person in question from the reviewers entry of the respective OWNERS file. Maintainers will review the PR and decide.
Furthermore, former Reviewers are removed from the organization members if they are no longer listed in any OWNERS file.
Maintainers of a repository (or a directory) can lose their status by voluntarily stepping down for personal reasons, or due to inactivity.
In such a case:
- A PR is required to move the person in question from the
approversentry to theemeritus_approversentry of the respective OWNERS file. The person in question must be mentioned in the body of the PR. This acts as a final contact attempt so that they can provide their feedback. - Another PR is required to remove them from GitHub team defined by the org.yaml file.
- Only for core maintainers who are losing their status:
- remove them from the
core-maintainersteam; - go to https://maintainers.cncf.io/ and open a PR to remove them under Falco;
- ask the CNCF to remove them from the
cncf-falco-maintainers@lists.cncf.iomailing list.
- remove them from the
The Maintainers' activity is periodically reviewed. Any Maintainer that does not show significant activity on the repository (or the subdirectory) they maintain can be removed from the approvers entry of the respective OWNERS of the repository (or the subdirectory), as described in the Offboarding a Maintainer section.
Maintanership decisions must be made on a per-OWNERS-file basis. So, a maintainer can be inactive in a project area but still involved elsewhere.
Inactive maintainers are proposed for review by any other Maintainer or, whenever possible, by the automation. The review is performed by opening a PR where other maintainers of the repository (or the subdirectory) can discuss and decide. If the persons under consideration voluntarily step down, the PR can be merged by lazy consensus; otherwise, a majority vote is needed.
Maintainers contributions can be measured by using the CNCF DevStats project (see also API reference).
An inactive person is defined as someone with less than 10 recorded contributions within the past six months.
Exceptions are allowed for vacation, sick leave, maternity and paternity leave, or planned absences. Moreover, since this method does not consider special situations and does not track all Maintainers duties, other exceptions can be made at the discretion of existing maintainers. In particular, the criteria can be loose and tightened as needed for Special repositories and those with very little activity.
The community promotes initiatives to seek new maintainers to ensure that the project grows healthy and increases the maintainers' diversity.
Existing maintainers regularly open mentoring programs for aspirant maintainers. Mentorship is the most practical way to share knowledge. The goal is to help aspirants understand the maintainer's activities and duties.
Mentoring programs may be tailored to the needs of a particular repository or area of the project. However, they must at least include:
- a mentoring period where one or more maintainers with enough experience guide the participants, who will learn the dynamics of being a maintainer by performing concrete activities;
- an evaluation process that must consider the technical merit, the participation in the community, as well as the other requirements to become a maintainer.
Whenever a new program starts, it must be announced to the community via the official communication channels.
Core Maintainers as a team are responsible for maintaining the falcosecurity GitHub organization; thus, they can intervene in any situation concerning their responsibility. If needed, they can ask to become maintainers of a repository.
Core Maintainers who volunteer to intervene must act with the spirit of serving the entire falcosecurity organization.