Helm Triage Maintainers
The existing Helm Project Maintainers have identified the need for a new "triage" role. This document lists out the responsibilities of this new role.
Helm Project Maintainers are responsible for activities surrounding the development and release of code, the operation of any services they own (e.g. https://get.helm.sh), or the tasks needed to execute their project (e.g., community management, setting up an event booth). Introducing a new "Helm Triage Maintainer" role allows new project maintainers to join the project without the responsibilities of release management, service operation, or event management.
This new role provides three benefits:
- New Triage Maintainers can help maintain the project's day-to-day, such as responding to new tickets and review pull requests
- Helm project maintainers' burden is reduced, allowing them to carry out higher-level tasks like coordinating software releases, organizing events, and maintaining production services.
- Provides an easier on-ramp from community members, to Triage Maintainers, to project maintainers, to org maintainers.
Project maintainers are looking for new members to join the project. However, community members have expressed in the past that they cannot commit more than a few hours per month to the project. Additionally, some project maintainers are concerned providing newer members the "keys to the castle" prior to a formal vetting process may introduce significant risk to the project's users. A new maintainer may be available to help maintain the project, but it may take several months before trust is established.
The new Triage Maintainer role is allowed to perform certain day-to-day tasks as a maintainer of the project, including:
- attach labels to issues
- assign issues to milestones
- review and approve pull requests
- nominate new Triage Maintainers
- nominate new Core Maintainers
The following roles and responsibilities are NOT allowed to be performed under this role:
- merge pull requests
- release new revisions of the Helm Client
- operate any public-facing services, such as
- Mailing lists
- Slack channels
- The helm/helm GitHub project
- organize official LF events (Helm Summit)
- vote on governance-related topics (including membership votes)
- become a member of the security team
- receive access to the helm_project Keybase team
- receive access to the cncf-helm-core-maintainers mailing list
These restrictions can be waived if these responsibilities are performed under direct supervision of a Helm Project Maintainer. For example, if a Helm Triage Maintainer would like to learn the release process, they may "shadow" the Helm Project Maintainer that is assigned as the release engineer. Triage Maintainers may also join the Helm Summit Program Committee to help review CFPs, but cannot be assigned the role of Program Chair.
The same rules about active maintainers applies to Triage Maintainers. Triage maintainers MUST remain active on the project. If they are unresponsive for > 3 months they will lose maintainer status unless a super-majority of the other project maintainers agrees to extend the period to be greater than 3 months.
The same voting process as Core Maintainers apply to Triage Maintainers. Nominations are sent to the public helm mailing list. Users must declare who they wish to nominate as Triage Maintainer. Self-nominations are accepted.
Afterwards, the Core Maintainers call for a vote on the internal Core Maintainer mailing list. If a two-thirds majority agree to the vote, the nomination passes.
Community members may still request for a vote to join as a full project maintainer. This new role provides an additional option to join the project at a lower commitment level.
The role helps protect the Helm Client and its users from new maintainers with malicious intent to de-rail or otherwise "pwn" the project. As Helm is one of the CNCF's most popular projects, a certain level of care and caution should be taken when providing new members access to production services. This new role helps keep the list of maintainers with production system access to a minimum.
How to teach this
The contents of this HIP will be discussed in the public Helm Dev meeting, which is recorded.
The author considered whether a Triage Maintainer could perform the duties of a release engineer, but rejected as a release engineer needs detailed information about the project's design, intents, and implementation. These tenets are not necessarily required to be a Triage Maintainer.
All of the Helm project's secret credentials are stored in the helm_project Keybase team, which we currently use for cross-communication between other project maintainer groups. This is a shared team - every project maintainer (helm, helm-www, chartmuseum, etc.) has access to the credentials in that account.
Should those credentials be moved elsewhere so we can invite Triage Maintainers to the channel, or should Triage Maintainers be restricted to the mailing list/slack channels?
A: It's probably best to use the mailing list/slack channels for this role; the Triage Maintainer is (hopefully) a stepping stone to project maintainer, which requires access to Keybase.