- Name: add component maintainer role
- Start Date: 2022-09-39
- Author(s): @jjbustamante
- Status: Approved
- RFC Pull Request: rfcs#234
- CNB Pull Request: (leave blank)
- CNB Issue: buildpacks/community#196
- Supersedes: #228
This RFC proposes the creation of a new role component maintainer in the project governance, responsible of executing maintainer duties on the repositories in a specific component under a CNB team.
- maintainers: individual that maintain specific code repositories.
- contributor: individual who make regular contributions to a team (documentation, code reviews, responding to issues, participation in proposal discussions, contributing code, etc.)
- teams: Group of individuals focused on narrower sets of concerns related to specific aspects of the project. Example: implementation team, platform team.
- team lead: is a maintainer who has special responsibilities for representing team concerns at the project level
- component maintainer: the proposed role in this RFC. Individual that maintain specific code repositories of a software-component inside a CNB team.
- software component: is a software unit with a well-defined interface and explicitly specified dependencies.
- github team: groups of organization members that reflects a company or group's structure with cascading access permissions.
Our current governance process defines teams and each team is responsible for maintaining some number of software components, these teams are organized internally with 3 different roles:
- Team Leads
- Maintainers
- Contributors
The process does not take into consideration the sizes of the software components that a maintainer must take accountability for or the expectations of the community contributors who made want to specialize in certain pieces of the projects, as the number and size of all the software components in a team increases we may need to distribute the responsibilities in a different way.
Compared to the model based on 3 roles, this new role should:
- re-balance responsibilities inside a team empower contributors to take ownership of key components align with their technical skills or career path expectations
- support maintainers on their role's goals one responsibility of a maintainer is
growing the team by mentoring aspiring contributors and maintainers, this new role offers a growing path for some contributors what would like to become maintainers.
It provides a mechanism to handle the increases of complexity of the source code of each component maintain by a team, when a team lead or maintainer determines a software component is big enough to be delegated to a contributor that desires to specialize and has the know-how to be responsible of a component they can nominate him/her to become component maintainer and delegates some of the day to day activities to this person.
A new role and guideline on how to nominate individuals to this role will be include it in our governance process.
CNB maintainer contributor responsibility can be describe as: is in charge of the day to day maintenance of the team's projects
As we can see in diagram above, a CNB team takes care of N number of software components and the project contributors from the community make their contributions to any of those components.
Depending on the team, these components can increase in size or complexity, or there could be someone from the community that wants to specialize their contributions on certain components without taking the responsibility of become a team maintainer.
Let's take for example the Platform Team, which right now have 2 maintainers, and let's use the LOC (lines of code) metric, for each of the components maintains by this team, to dimension the size of them.
| Component | LOC |
|---|---|
| Pack | +58000 |
| Tekton Tasks + Pipelines | +2150 |
| CircleCI Pack Orb | +400 |
Note: Tokei tool was used to calculate the LOC of the repositories.
As part of the CNB roadmap a better out-of-the box Kubernetes and Docker integration is a goal of the project and in order to do that, the Platform Team will have to include another software component that accomplish this goal.
In case of this scenario, then an hypothetical update of the component table if kpack project is donated into CNB (see RFC for more details) will be:
| Component | LOC |
|---|---|
| Pack | +58000 |
| Tekton Tasks + Pipelines | +2150 |
| CircleCI Pack Orb | +400 |
| Kpack | +57000 |
As we can see, a new implementation of the Platform Interface Specification could be as big as pack but most important:
- It requires a specific knowledge in Kubernetes
Another example of the problem presented in this RFC is: adding support to cosign RFC. In this RFC a new phase executable must be developed and maintain by the Platform team, but this implementation requires knowledge and expertise on technologies like sigstore.
The proposal is to incorporate a component maintainer role in our governance process.
The component maintainer will take under his/her responsibility a well defined software component in a CNB team and for each repository will be allow to:
- reviewing, approving, and merging pull requests.
- planning release milestones, and releasing components versions
- edit, label, assign issues
An updated version of the previous diagram shows graphically this new role.
As we can see a new orange box was drawn representing a component, or group of software components, the new component maintainer role is taking responsibilities for. When a team lead or maintainer wants to use the role in their team, they must follow these steps:
-
In case it doesn't exist, a new github team must be created. A recommended name for this new team must follows the format
[cnb-team]-[component]-maintainers, where:- cnb-team: is the CNB team responsible for the software component, for example:
Platform Team. - component: is the software component name. for example:
kpack.
Some examples are:
platform-kpack-maintainersorplatform-cosign-maintainers - cnb-team: is the CNB team responsible for the software component, for example:
-
For each repository related to the component or group of components:
- In case it doesn't exist, a new CODEOWNERS file must be added.
- Add the team
[cnb-team]-[component]-maintainerscreated into the CODEOWNERS file. - Members of the team should have maintainers permissions.
- The branch protection should require CODEOWNERS to approve or merge a pull request.
-
Add the new component maintainer's github account into the
[cnb-team]-[component]-maintainersgithub team.
Let's come back to our previous examples.
In these cases, the existence of the component maintainer role will provide the rules to the platform team lead or platform maintainers to nominate (following the guidelines describe in the next section) a component maintainer.
In case kpack is donated to CNB, kpack maintainers could become component maintainers of this component and keep doing all the activities required for maintaining the lights on in the project without having to assume the whole set of responsibilities of a Platform team maintainer. Also, platform maintainers will not be overwhelm being the sole reviewers/approvers for kpack's pull requests if they are not familiar with the project.
The existence of the component maintainer will open the door to the community, in particular, those volunteers with experience on sigstore to help on with the contributions and maintenance of the new signer binary proposed.
This case, is an example of two different areas of interest or knowledge where having the separation of responsibilities is relevant.
Follow this guideline to nominate a component maintainer for a software component inside a team
- The software component must be defined under the GOVERNANCE team section, for example: Platform Team -> kpack
- New component maintainers must already be contributors of the team
- New component maintainers must be nominate by a team lead or a maintainer of the team under the following scenarios:
- A software component developed outside CNB project was accepted under their team and they do not have the know-how or experience to handle it.
- A community contributor have explicitly manifest the desire to become a component maintainer and the team lead or maintainer consider he/she has the skills and knowledge to take the responsibility and accountability of the component.
- New component maintainers must be elected by super-majority of the team’s maintainers
None
Why should we not do this?
- Yet another role
- We decide to wait until the problem arises
If no new role is created, maintainer will continue to be accountable and responsible of all the software components inside a team.
The first attempt to addressed the problem was proposing the repository level ownership RFC but abandoned this idea because:
- A new role is more consistent with current governance structure
- A new role will provide more visibility to the community to identify individuals responsible for each repository.
Discuss prior art, both the good and bad.
None
None