Skip to content

Contributor Ladder

Within the Kubernetes community, the concept of a contributor ladder has been developed to define how individuals can earn formal roles within the project. The Ingate contributor ladder largely follows the roles defined by the broader Kubernetes community, though some aspects are unique to this community.

Goals

This doc will provide an initial step towards the following goals:

  • Ensure the long-term health of the Ingate project and community
  • Encourage new contributors to work towards formal roles and responsibilities
  • Clearly define the path towards leadership roles
  • Develop a strong leadership pipeline, so we have great candidates to fill project leadership roles

Scope

This doc covers the following repositories:

There are opportunities to become an approver or reviewer for either the entire project or a subset of that project. For example, you could become a reviewer or approver focused on just docs or Helm.

Contributor Ladder Steps

The Ingate contributor ladder has the following steps:

  1. Member
  2. Reviewer
  3. Approver
  4. Maintainer

Within Ingate, there are a variety of areas in which one can become a reviewer or approver, including:

  • Documentation
  • Helm

General Guidelines

Everyone is welcome

We appreciate all contributions, especially non-code contributors such as docs updates and real-world examples. You don’t need a formal role in the project to make or review pull requests and help with issues or discussions. It is entirely optional to accept a formal role within the project. You must adhere to the Code of Conduct while contributing to the Ingate project.

These roles require continued contributions

Applying for one of the roles defined above should only be done if you intend to continue to contribute at a level that would merit that role. If for any reason If you cannot continue in one of the roles above, please resign. Members with an extended period away from the project with no activity will be removed from the Kubernetes GitHub Organizations and will be required to go through the org membership process again after familiarizing themselves with the current state of the project.

Don’t merge without consensus

If you have reason to believe that a change may be contentious, please wait for additional perspectives from others before merging any PRs. Even if you have access to merge a PR, it doesn’t mean you should. Although we can’t have PRs blocked indefinitely, we need to ensure everyone has had a chance to present their perspective. One of the best ways to resolve issues is to attend the community meeting and discuss it with maintainers.

Start a discussion

If you’re interested in working towards one of these roles, please reach out to an Ingate maintainer on Slack in the ingate-dev channel.

Member, Reviewer, and Approver

The first steps on the contributor ladder are already clearly defined in the upstream Kubernetes Community. Ingate follows those guidelines along with the rest of the Kubernetes community.

Maintainers

The final steps on the contributor ladder represent significant overall leadership roles within the project. The spaces available for these roles are limited (generally, 3-4 people in each role is ideal). We ensure that different companies are represented in these roles wherever possible.

Ingate Maintainers are known as Subproject Owners within the Kubernetes community. To become an Ingate Maintainer, the most important things we expect are:

  • Long-term, sustained contributions to Ingate for at least 6 months
  • Deep understanding of technical goals and direction of the project
  • Successfully authored and led significant enhancement proposals
  • Approver for at least 3 months
  • Ability to lead community meetings

In addition to all the expectations described above, we expect maintainers to set the technical direction and goals for the project. This role is critical to the project's health; maintainers should mentor new approvers and reviewers and ensure healthy processes are in place for discussion and decision-making. Finally, maintainers are ultimately responsible for releasing new versions of the controller.