Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce new roles/teams in kedaorg #107

Open
JorTurFer opened this issue Apr 10, 2024 · 6 comments
Open

Introduce new roles/teams in kedaorg #107

JorTurFer opened this issue Apr 10, 2024 · 6 comments
Assignees

Comments

@JorTurFer
Copy link
Member

Currently, we are only the maintainers who have the approval/merge permissions and we are the only included in codeowners. This doesn't scale, and we should introduce an intermediate level (reviewer, approver, contributor, whatever) between reviewing PRs without any permission and merging permissions.

My proposal is to include a new team with approval permissions on repositories (one group per repo on those repos where it makes sense) and include them as part of codeowners in order to notify them automatically when there are new PRs.

The permissions that I'd add to this new team are:

  • codeowners -> To be notified on PRs
  • issue triagge -> We need help triaging issues and it can be useful for the project
  • pr approval (not merge) -> Having more folks whose approval can be usable for merging can improve the project. e.g: zbynek creates a PR but Tom or me can't review it. Recurrent contributors have enough context and knowledge to review it and approve it, and zbynek could merge it once it's approved.

This could be something in the middle to not have to jump from "nothing" to maintainer. This can be also useful for us as probably new maintainers will be found on those teams (or eventually project scoped maintainers, idk)

If you also think that it's useful, I'm willing to draft a PR defining the new roles/teams, the scopes, expectations and the way to be invited to them.

@tomkerkhove @zroubalik ?

@zroubalik
Copy link
Member

Yeah, agree. We should have reviewers group - they will be notified and can review (but not merge PRs).

@JorTurFer
Copy link
Member Author

Do you think that drafting the team definition can be useful to discuss the edges over it can be useful? As this has to be reflected on this repo for transparency, I guess that I can draft the description in a PR

@tomkerkhove
Copy link
Member

Yes we should, we also need this for Credly

@JorTurFer
Copy link
Member Author

I'll try to draft something this week

@tomkerkhove
Copy link
Member

These are the CNCF roles which are also what they offer for Credly, I'd align with this given this is fairly standard in CNCF:
image

@JorTurFer
Copy link
Member Author

Okey, for the moment I think that I'll draft just "contributor" to cover the reviewer that I proposed, but we can iterate from it in the future to add the others

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants