mowies
commented
1 year ago Subprojects in our case are e.g. keptn v1 (keptn/keptn) and KLT (keptn/lifecycle-toolkit). I think also the docs repo is counted as its own sub project. I think it makes sense to have separate privileges for separate (groups of) repo since they have vastly different code bases that maybe require completely different background knowledge to be a responsible maintainer for example
Proposal
I'd like to propose that we drastically reduce and simplify the current community management structure. I believe that the current structure is too heavy, cumbersome and is potentially actively deterring new individuals from joining the Keptn project.
Furthermore the approval process to be accepted into each level is too cumbersome for some stages.
The current structure borrows heavily from the OpenTelemetry structure but that is neither relevant or useful as Keptn simply isn't the same size as OpenTelemetry, doesn't have the same management overhead, nor the same number of maintainers to action things.
I count 8 different possible levels:
Keptn membership mentions subprojects, but to my knowledge, we have none.
Proposed Solution
We simplify the levels and if we think about it as a funnel (from left to right) with most individuals on the left and fewer on the right:
1. Member
Self-declared. Anyone can state that they're a member of the Keptn project / community. No prior approvals are required. Members typically promote Keptn (via video, blog posts, social media etc.). Members can also help generally in the community (GitHub / Slack etc.) by answering questions. Members can choose (and are encouraged) to list themselves (via a PR they raise) on a
members.mdfile.2. Contributor
Automatic process An individual becomes a Keptn contributor when their first PR is merged. Regardless of whether that individual has contributed to documentation or core code, by nature of the PR being merged, they are now a contributor.
3. Approver
Approvals required At this level of membership, a GitHub accounts starts to gain privileges which could potentially cause harm to the project. In other words, they gain the status and mechanisms to approve documentation changes or code.
Thus, 2 sponsors (other approvers or higher) must support the application for a
It is logical that to become an approver, one must be familiar with the project or piece of the project (eg. docs) for which they're becoming an approver. Applicants to become approvers are expected to already be contributors (with a meaningful number of relevant PRs). This "sanity check" procedure would be done by the "sponsors". If the "sponsors" aren't happy that the requesting individual they can simply fail to endorse.
4. Maintainer
Approvals required Maintainers have significant responsibilities in the project. Maintainers must therefore already be approvers. Maintainer applicants must have at least 2 "maintainer level or higher" sponsors OR a significant vote of confidence from other approvers.
Other roles
Technical advisory committee members, governance boards etc. are subsets of these roles.
A simplified structure like this would, I believe, make the community clearer and drive engagement as the barriers to entry are lowered.