RFE: Establish maintainer/approver status per subproject/repository

[thschue]

Proposal

Currently, the approver/maintainer status is solely established at the organization level. As - in the meanwhile - Keptn consists of multiple projects/repositories (Keptn LTS / Keptn Lifecycle Toolkit / Docs), it would make sense to define a maintainer/approver status also on the project/repo level.

Therefore, I propose:

• Split organization and repository member/ownerships
• Organization maintainer/approvership is defined by:
  • listed as maintainer/approver/member in keptn/community/MAINTAINERS (to be established)
  • org-maintainers are elected by a majority vote of GC/TC
  • org-maintainers are also listed as maintainers in the CNCF with the respective voting rights
  • org-maintainers have their respective membership level throughout the whole organization (keptn, keptn-contrib)
  • TC and GC members automatically get org-maintainers for their election period
• Sub-Project/Repo maintainer/approvership is defined by:
  • assigned to the respective role in the OWNERS file of the repository (see https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md)
  • subproject maintainers are sponsored by 2 org/repo maintainers with a comment period of 5 days without objections
  • the scope of the membership level is on the repository level, no organization-wide or CNCF voting rights are related
  • they are member of the keptn github organization

Sponsors

• @thisthat
• @AlexsJones

Checklist

• [x] The idea is brought up for a discussion in a relevant Keptn Slack channel (use #keptn-project by default)
• [x] Each sponsor should reply to this issue with the comment "I support".

[thisthat]

I think goes hand-in-hand with our upcoming peribolos change 👍 I definitely support having a more fine-grained contributing ladder 👍

[aepfli]

also see https://github.com/keptn/community/pull/223 and the readme changes where i specially request governance committee approval :) we do have multiple initiatives running, we should at least limit the coordination to one place - and i suggest this issue here

[AlexsJones]

I support this notion

[bradmccoydev]

I like and support this. This will help grow the project by empowering people and giving them a sense of ownership of the hard work they put into those repos/work which will lead to sticky contributors. It will also help us keep up to date across repos services as we move fast.

[agardnerIT]

I support this. It makes total sense for someone to maintain docs but not core code (for example).

[mowies]

I support this as well!

[thisthat]

We introduced Peribolos with support for subproject-level permissions. What is left:

1. adjust the ladder document (see #273)
2. how to transition existing permission from a single team into multiple

For the second point, at the moment, we migrate all users into the @keptn/keptn-maintainers team

[DavidPHirsch]

@thisthat I think this done