Introduce a CONTRIBUTING.md file with Lead requirements

[kimwnasptd]

This is an effort on defining the expectations from Manifest WG Leads as well as criteria for someone to be promoted into a leadership position in the WG.

This should help to ensure people that are invested in the project can also have the "authority" to guide the process and development.

This is a first iteration on defining the pillars that a Manifests WG Lead is expected to be able to drive. The next goal then will be to draft an initial list of requirements, for someone to be a reviewer or approver. I'll be doing this in this PR but wanted to start this effort early and ping people for feedback while this list is being finalized.

This should help us have a process, to handle user requests that want to be promoted into leadership roles, which will be uniform across this WG.

cc @kubeflow/wg-manifests-leads @annajung @DomFleischmann @juliusvonkohout @jbottum @james-jwu @zijianjoy

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[google-oss-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: kimwnasptd

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [kimwnasptd]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[kimwnasptd]

Any feedback is more that welcome! Also if you believe my text is not clear enough please feel free to expose it and we can iterate.

/hold

[jbottum]

@kimwnasptd Nice job! We might consider adding something like these...6. Will provide timely review of issues and PRs 7. Will attend and be an active participant in the Manifest Working Group meetings.

[annajung]

Good point, I think that might be actually part of the "community and health of the project". Would it be helpful to be specific on what community and health means by saying

Investing in the community and health of the project by being active participants in open issues, pull requests, and community meetings

[annajung]

Maybe also taking @juliusvonkohout's comment, it can be edited to

Investing in the community and health of the project by being active participants in issues, pull requests, community meetings, and making meaningful technical contributions

[juliusvonkohout]

In general that is fine. but to get rid of inactive ones we need to specify hard requirements

[annajung]

That's a good point. Maybe another section in the doc is appropriate here to determine inactivity and how to demote for both approver and reviewer roles

[juliusvonkohout]

@jbottum what do you think? is this already too strict? We really need more active reviewers and get rid of inactive ones

Reviewer requirements

• Root Reviewers should have at least 5 accepted PRs. We need more active reviewers
• Root Reviewers are supposed to attend at least 30 % of the manifest-WG meetings within a calendar year. Otherwise they can be removed from the owners file
• Root reviewers are supposed to review at least 3 PRs per year. It does not matter whether these reviews have been done before or after becoming reviewer. It also does not matter whether it was an official review, what counts is a meaningful technical contribution in the PR or issue thread. Otherwise they can be removed from the owners file.

Approver requirements

• Root approvers should have reviewed at least 5 PRs . In my case that would be already a few from networkpolices, bentoml and Ray. It does not matter whether these reviews have been done before or after becoming reviewer. It does not matter whether it was an official review, what counts is a meaningful technical contribution in the PR or issue thread.
• Root approvers are supposed to attend at least 30 % of the manifest-WG meetings within a calendar year. Otherwise they can be demoted to root reviewer.
• Root approvers are supposed to review at least 3 PRs per year. It does not matter whether these reviews have been done before or after becoming reviewer. It also does not matter whether it was an official review, what counts is a meaningful technical contribution in the PR or issue thread. Otherwise they can be demoted to root reviewer.
• To become root approver you have to be owner of at least one subproject, as for example contrib/networkpolicies

[annajung]

Thanks for starting this effort! Clear processes and requirements will be helpful to all contributors!

[kimwnasptd]

Was looking around at the community docs and found out this one that specifies the subproject owner role
https://github.com/kubeflow/community/blob/master/wgs/community-membership.md#subproject-owner

It looks like the correct place for this PR is to make it against this file
https://github.com/kubeflow/community/blob/master/wg-manifests/charter.md#roles-and-organization-management

But, since there's review context here I'll continue with updating this PR and once we have consensus I'll close it and open it in the community repo

[kimwnasptd]

@jbottum @annajung @juliusvonkohout thank you very much for the feedback!

Did a pass and tried to address the input. PTAL

[juliusvonkohout]

@kimwnasptd It should be "Has attended at least 50% of Manifests WG meetings" instead of "Has attended at least 75% of Manifests WG meetings" as discussed in the last meeting. So on average we expect people to attend at least one meeting per month. That leaves enough room for vacation, sickness etc.

[annajung]

kubeflow/community#632 is merged.
Not sure if this PR still needs to be added to this repo or not.

/hold
/lgtm

feel free to unhold if you want to merge this

[kimwnasptd]

I'd propose to close this PR since the community one was merged. Once the CNCF transition is fully finalised we can then do an update to the CONTRIBUTING.md