Component maintainer role

[jjbustamante]

Readable

Signed-off-by: Juan Bustamante jbustamante@vmware.com

[buildpack-bot]

Maintainers,

As you review this RFC please queue up issues to be created using the following commands:

/queue-issue <repo> "<title>" [labels]...
/unqueue-issue <uid>

Issues

• ✅ 7354ed - buildpacks/community#196 "Document component maintainer role"

[sambhav]

Happy to champion this.

[loewenstein]

I am wondering a bit what exactly we want to solve with this and if we need the finer-grained formal structure to achieve this.

Maintainers are in charge of the day to day maintenance of the team's projects including

Do we fear that pack maintainers expect kpack maintainers to review pack PRs or be otherwise responsible for pack? Or do we fear that kpack maintainers will leverage any kind of voting power to overrule decisions regarding pack that the packmaintainers would otherwise decide for? Do we fear kpack maintainers will single-handedly merge code into pack that pack maintainers don't want to see merged?

I believe the answers will all be: "No, not really" or even "No, not at all". But then, why can't wen just add kpack to the platform team's responsibility and welcome a bunch of new maintainers to the platform team that will likely mostly concentrate on kpack as a platform. I don't see why we would need new roles for this.

[sambhav]

I am wondering a bit what exactly we want to solve with this and if we need the finer-grained formal structure to achieve this.

Maintainers are in charge of the day to day maintenance of the team's projects including

Do we fear that pack maintainers expect kpack maintainers to review pack PRs or be otherwise responsible for pack? Or do we fear that kpack maintainers will leverage any kind of voting power to overrule decisions regarding pack that the packmaintainers would otherwise decide for? Do we fear kpack maintainers will single-handedly merge code into pack that pack maintainers don't want to see merged?

I believe the answers will all be: "No, not really" or even "No, not at all". But then, why can't wen just add kpack to the platform team's responsibility and welcome a bunch of new maintainers to the platform team that will likely mostly concentrate on kpack as a platform. I don't see why we would need new roles for this.

@loewenstein I think the issue is not that of trust but of responsibility. Currently a team maintainer position also includes other responsibilities and can be fairly heavyweight including responsibilities involving the governance of the project.

There might also be numerous component level maintainers (for example kpack has more than 4 maintainers right now) that might not be ready to commit to the wider team level responsibilities and rather be interested in contributing to a specific project.

Similarly, on the other hand, some existing team maintainers might not be familiar with donated projects and might not be comfortable being the sole reviewers/approvers for PRs for certain projects. (The way project governance is currently set up, only team maintainers can merge PRs)

As an open source organization, we want to make sure that we are open to such contributors. We have been trying as much as possible to make sure our governance and contribution processes can be made conducive to more people.

Having been part of the discussions regarding this RFC in the WG, the core motivation behind this RFC was to relieve some responsibilities from both the team maintainers and project maintainers and to allow for projects to easily foster in the CNB organization. kpack is one example, but another example that motivated this RFC was the cosign integration RFC, where the existing platform maintainers did not have the expertise or bandwidth to help maintain such a component and we had volunteers who had experience with sigstore willing to help with the contributions and maintanance of the signer binary.

[jjbustamante]

Some feedback from the Working Group meeting last week (10/13)

• Add more details on how to implement the approach
• Add more examples where the new role is useful (BAT) mentioned by Sam

[jjbustamante]

@samj1912

I wanted to address your comment from WG meeting last week about adding a little more detail on the implementation of this RFC, what exactly do you have in mind?

[sambhav]

@jjbustamante a couple of details on how permissions and ownership should work.

I believe that a component or a group of components (in kpack's case, the controller, cli and other related repos) should be represented by a github team.

The team members should have maintainer permissions on the group of repos related to the component and should be codeowners on the repos. The branch protection should require codeowners to approve to merge a PR.

[jjbustamante]

@samj1912

Thanks for the feedback, I updated the how it works section trying to reflect your comments, let me know how it looks :)

[sambhav]

I think the RFC is in a good state and feels like it's ready to be undrafted. I'm going to do that.

@jjbustamante can you please bring it up in the #buildpacks slack channel and if there are no strong comments, let's put the rfc in FCP.

[sambhav]

Putting this RFC in FCP with the FCP ending on 4th November.

[sambhav]

/queue-issue buildpacks/community "Document component maintainer role"