Skip to content

Latest commit

 

History

History
198 lines (133 loc) · 11.2 KB

PROCESS.md

File metadata and controls

198 lines (133 loc) · 11.2 KB
Raw

Flux Community Processes

This document defines community processes in the Flux project.

As foundational documents such as GOVERNANCE.md and community-roles.md grew, we decided to move definition of processes here. Consider this your "how to" with regard to interacting with the Flux community.

Joining the Flux Project

Applying for Flux Membership

Requirements:

  • Have made multiple contributions to the project or community. Contribution may include, but is not limited to:
    • Authoring or reviewing PRs on GitHub
    • Filing or commenting on issues on GitHub
    • Contributing to project or community discussions (for example meetings, Slack, email discussion forums, Stack Overflow)
  • Subscribed to the flux-dev mailing list
  • Actively contributing to 1 or more fluxcd GitHub org repos
  • Sponsored by 2 project members Note the following requirements for sponsors:
    • At least 1 of the sponsors must be a maintainer
    • Sponsors must have close interactions with the prospective member - for example code/design/proposal review, coordinating on issues, etc.
    • Sponsors must be from multiple companies to demonstrate integration across community

Process:

Open an issue against the fluxcd/community repo

If you are unsure about what to write or how much to mention, have a look at some of the previous membership applications.

  • Ensure your sponsors are @mentioned on the issue

  • Complete every item on the checklist

    ### GitHub Username
e.g. (at)example_user

### Requirements
- [ ] I have reviewed the community membership guidelines in [community-roles.md](community-roles.md)
- [ ] I have subscribed to the cncf-flux-dev e-mail list [https://lists.cncf.io/g/cncf-flux-dev/join](https://lists.cncf.io/g/cncf-flux-dev/join)
- [ ] I am actively contributing to 1 or more `fluxcd` GitHub org repos (eg. Flux, Flagger)
- [ ] I have enabled 2FA in GitHub
- [ ] I have two sponsors that meet the sponsor requirements listed in the community membership guidelines
- [ ] I have spoken to my sponsors ahead of this application, and they have agreed to sponsor my application

### Sponsors
- (at)sponsor-1
- (at)sponsor-2

### List of contributions to the Flux project
- PRs reviewed / authored
- Discussions involved in & Issues responded to
- Flux subprojects I am involved with (Flagger, Flux, Controllers)

  • Have your sponsoring members/maintainers reply confirmation of sponsorship: +1

  • Once your sponsors have responded, your request will be reviewed by a member of the core maintainers.

  • Add yourself to the list of Flux Project Members afterwards.

Any missing information will be requested.

Applying for Flux Maintainership

Process:

  • Make a PR against the MAINTAINERS file for a fluxcd GitHub org repo. Example PR
  • @mention all the other current maintainers
  • Have maintainers submit their vote by +1
  • Once all maintainers in repo have +1 the pr will be reviewed by a member of the core maintainers

Electing new Maintainers of the same repository is an Unanimity decision.

Once the above process has taken its course, make sure you

Applying as core maintainer: The same process applies for applying as a core maintainer. The PR should be against the CORE-MAINTAINERS file though and an accordingly higher level of experience and a more holistic understanding of the project is expected.

Applying as a Security Team member

Process:

  • You need to be a Maintainer to be able to apply
  • Set up your Keybase account
  • Make a PR against the SECURITY.md file in https://github.com/fluxcd/.github adding your contact information
  • @mention @fluxcd/core-maintainers
  • Have maintainers submit their vote by +1
  • Once all maintainers in repo have +1 the PR will be reviewed by a member of the core maintainers

Adding new Security Team members is an Unanimity decision.

Once the above process has taken its course, make sure you

Proposal Process

  • Code changes should go through the pull request process, where the idea and implementation details can be publicly discussed with Maintainers, other contributors, and end users. Pull requests should only be merged after receiving GitHub approval from at least one Maintainer who is not the pull request author.
  • For architectural changes to Flux, please use the RFC process. Note that Flux v2 uses GitHub discussions for (non-architectural) proposals in the fluxcd/flux2 Git repository https://github.com/fluxcd/flux2/discussions?discussions_q=category%3AProposals.
  • Non-code changes should be proposed as GitHub issues. If unclear which Git repository to create the issue in, default to the community repository https://github.com/fluxcd/community.
  • All proposals should be discussed publicly in an appropriate GitHub issue or pull request.
  • If a Maintainer of an affected Git repository feels feedback from specific people is warranted they will @mention those users or teams to request feedback.
  • Proposals may also be added to the Flux Dev weekly meetings agenda, as a good avenue for making progress on a decision https://lists.cncf.io/g/cncf-flux-dev/calendar.

Project Processes

Code of Conduct violations

As a project, it is important to us that we provide a safe and enjoyable space. Upholding our Code of Conduct is key to this.

If you wish to report a violation, please contact the private Maintainer mailing list and the Flux maintainers will work on resolving this as a matter of priority.

Inactivity

It is important for contributors to be and stay active to set an example and show commitment to the project. Inactivity is harmful to the project as it may lead to unexpected delays, contributor attrition, and a lost of trust in the project.

Inactivity is to be defined by the core maintainers team.

Consequences of being inactive include:

  • Involuntary Removal
  • Being moved to Emeritus status

Involuntary Removal

Involuntary removal of a contributor happens when responsibilities and requirements aren't being met. This may include repeated pattern of inactivity, extended period of inactivity, and/or a violation of the Code of Conduct. This process is important because it protects the community and its deliverables while also opens up opportunities for new contributors to step in.

Involuntary removal is handled by the core maintainers team. Removing a Repository Maintainer or Core Maintainer for any reason other than inactivity is a Supermajority decision.

Stepping Down/Emeritus Process

If and when contributors' commitment levels change, contributors can consider stepping down (moving down a role) vs moving to emeritus status (completely stepping away from the project).

Please reach out to the core maintainers team to discuss this process.

Stepping Back Into a Role

If and when someone is available to step back into a previous contributor role, this is something that can be arranged and considered by the core maintainers team.

Please reach out to the core maintainers team to discuss this process.

Licensing changes

Licensing and intellectual property changes is a Unanimity decision. To be made by the core maintainers.

Governance changes

core maintainers decide on material changes to the Governance document. This is a Supermajority decision.

  • Note: editorial changes to governance may be made by lazy consensus, unless challenged. These are changes which fix spelling or grammar, update work affiliation or similar, update style or reflect an outside and obvious reality. They do not change the intention or meaning of anything in this document.

Contact

For inquiries, please reach out to: @fluxcd/core-maintainers on GitHub.

Requesting new repositories / bots / GitHub applications / etc

File an issue in the fluxcd/community repository and contact the @fluxcd/org-admins team to fulfil your request.

Electing Org Admins

Org Admins are defined in the ORG-ADMINS file. An election can be done through a pull request against this file to be approved by the core maintainers.

The list of members is reviewed every year and should consist of:

  • active members (preferably spread over various timezones and organizations)
  • counterparts at the CNCF and Linux Foundation

Examples of Decisions

  • Project change: Moving Flagger under the Flux organisation was not a code or architectural change, but a big decision that impacted the Flux project and community, hence it was discussed in various Flux Dev meetings, before being put up at #34 for a comment period of one month and when there were no objections, the decision was announced here.
  • Architectural change: introducing the RFC process itself was introduced as an RFC. Here is a list of other architectural changes which fall under that category: https://github.com/fluxcd/flux2/pulls?q=label%3Aarea%2FRFC+.
  • Application to become a member of the Flux project was filed as an issue under fluxcd/community: #127 (a checklist of requirements, sponsors, list of contributions, and approval can be found in the issue - just follow this process).