Establish clear guidelines for who is authorized to join the organisation

[luxas]

Hi,

As a Kubernetes maintainer, I've got a few people talking to me on Slack, asking what they should do in order to join the Kubernetes organisation.

I haven't had a super-clear answer to them, and that's not great from an open community perspective.
We have to establish some clear guidelines that describes what a contributor should do in order to become a member.

(Known issues from before is also that we have no clear process for a member to become a maintainer, but with all the new OWNERS stuff that can turn a member in an OWNERS file to a approver of a PR, I think that's a lower priority item)

Definitions:

• Reviewer: Anyone that have done at least one review of a PR (voluntarily)
• Contibutor: Someone who has filed at least one issue and got at least one PR merged
• Member: Member of the kubernetes organisation. Must be a contributor and a reviewer.
• Approver: A maintainer or a member that is listed in at least one OWNERS file and have the power to /lgtm a PR so the Submit Queue merges it.
• Maintainer: A person that works for the project's best at all times and consequently gives time to answer issues, review PRs, file issues, write PRs and organize issues/PRs by labeling and closing duplicates. Is often especially good at something, but is not working only with one small thing, instead he/she is focused on the overall health of the project. Gets flakes assigned to himself/herself.

Open question: Should a member have to at least be member of one SIG?

Why would someone want to be in the organisation (in no specific order)?

• Retrigger tests on his PR
  • Actually, this should be fixed by the @kubernetes/sig-testing team. If a contributor of a PR has got the @k8s-bot ok to test message from someone in the org once, he/she should be able to retrigger tests in case they flake.
• Status (have the k8s badge on his/her profile)
• The possibility to be an assignee
• The possibility to be an approver of a PR
• To feel that he/she belongs to the community
• To be able to join a sig team on Github and get sig-notifications automatically
• etc...

We already have something here, but it doesn't explicitely address these concerns, but I think it's a good starting point.

We could define some tasks a contributor should have done before he/she can join, for example:

• Sent more than ten pull requests (PRs) in the previous three months, or more than 40 PRs in the previous year.
• Filed more than twelve issues in the previous three months, or more than 50 issues in the previous year.
• Reviewed (with the review feature of Github) more than 15 pull requests in the previous three months, or more than 60 pull requests in the previous year.
• Anything else?

I guess here we want an OR between the tasks above (that the contributor should have done at least one of those), and the more involved the contributor are, the higher the contributor will be on the list for possible new members in the org.

We could easily program a dashboard for this in order to identify the people that are possible new members, but it could be easy to abuse that system as well (by opening nearly empty issues x times just to show up on the list), so there must always be one or more persons that then approves a person to join. The persons who allow new contributors to the organisation could be some from the Community Elders (#28) team.

Then we might also want some system to remove a member from the organisation after he/she has been inactive for a specific period of time, otherwise we'll end up with an unmanageable amount of members. But that's a secondary priority, we have to define the rules how to get in first.

The really hard problem with this proposal is that it's hard to draw the line, in the end of the day it's a subjective (not always objective) decision that has to be taken. But we should try to define some requirements that everyone are aware of. We don't want them to be too easy to get (we will end up with all contributors being members => unmanagable) but at the same time not too hard to get either (few members, assignees, etc. reduces the velocity of the project).

At least it would be really helpful to have a link to a document that states something about this.
If someone want me to tell my story about how I became a maintainer while still attending upper secondary school in Finland and get the "outside" perspective from that story, feel free to ask.

P.S. I know nothing about the current process. Correct me if I'm wrong, but it's an inside-Google-thing right now, right?

cc-ing some people: @sarahnovotny @bgrant0607 @vishh @philips @jessfraz @thockin @kubernetes/contributor-experience

[kad]

one more item in the list, why it might be useful: grabbing attention of sig groups to reviewed PRs. Otherwise mentioning @kubernetes/sig-xyz magic in comments doesn't work.

[bgrant0607]

See also #112

[bgrant0607]

In particular: #112 (comment)

[k82cn]

Regarding PR, it should be not only the doc but also some functional ones.

[bgrant0607]

@kad Notifications are discussed elsewhere: https://groups.google.com/forum/#!topic/kubernetes-dev/LEtIxeG0i84

[kad]

@bgrant0607 with notifications in this proposal: it's open to account forging. Whatever naming convention is used, even if all accounts created at some point for all existing SIGs, it will be problem for new SIGs: nobody can prevent somebody to create accounts with names following naming conventions... But well, it will solve issue for a while.

[thockin]

I think there's something between reviewer and contributor, or some fork in the tree. casual reviewer: is not a member of the org, is not in OWNERS, does code review (the hero we need!). prosumer reviewer: is a member of the org, is in OWNERS as a reviewer.

…

On Sun, Dec 4, 2016 at 7:13 AM, Lucas Käldström ***@***.***> wrote: Hi, As a Kubernetes maintainer, I've got a few people talking to me on Slack, asking what they should do in order to join the Kubernetes organisation <https://github.com/kubernetes>. I haven't had a super-clear answer to them, and that's not great from an open community perspective. We have to establish some clear guidelines that describes what a *contributor* should do in order to become a *member*. (Known issues from before is also that we have no clear process for a *member* to become a *maintainer*, but with all the new OWNERS stuff that can turn a *member* in an OWNERS file to a *approver* of a PR, I think that's a lower priority item) Definitions: - *Reviewer*: Anyone that have done at least one review of a PR (voluntarily) - *Contibutor*: Someone who has filed at least one issue and got at least one PR merged - *Member*: Member of the kubernetes organisation. Must be a *contributor* and a *reviewer*. - *Approver*: A *maintainer* or a *member* that is listed in at least one OWNERS file and have the power to /lgtm a PR so the Submit Queue merges it. - *Maintainer*: A person that works for the project's best at all times and consequently gives time to answer issues, review PRs, file issues, write PRs and organize issues/PRs by labeling and closing duplicates. Is often especially good at something, but is not working only with one small thing, instead he/she is focused on the overall health of the project. Gets flakes assigned to himself/herself. Open question: Should a *member* have to at least be member of one SIG? Why would someone want to be in the organisation (in no specific order)? - Retrigger tests on his PR - Actually, this should be fixed by the @kubernetes/sig-testing <https://github.com/orgs/kubernetes/teams/sig-testing> team. If a contributor of a PR has got the @k8s-bot ok to test message from someone in the org once, he/she should be able to retrigger tests in case they flake. - Status (have the k8s badge on his/her profile) - The possibility to be an assignee - The possibility to be an approver of a PR - To feel that he/she belongs to the community - To be able to join a sig team on Github and get sig-notifications automatically - etc... We already have something here, but it doesn't explicitely address these concerns, but I think it's a good starting point. We could define some tasks a contributor should have done before he/she can join, for example: - Sent more than ten pull requests (PRs) in the previous three months, or more than 40 PRs in the previous year. - Filed more than twelve issues in the previous three months, or more than 50 issues in the previous year. - Reviewed (with the review feature of Github) more than 15 pull requests in the previous three months, or more than 60 pull requests in the previous year. - Anything else? I guess here we want an *OR* between the tasks above (that the contributor should have done *at least* one of those), and the more involved the contributor are, the higher the contributor will be on the list for possible new members in the org. We could easily program a dashboard for this in order to identify the people that are possible new members, but it could be easy to abuse that system as well (by opening nearly empty issues x times just to show up on the list), so there must always be one or more persons that then approves a person to join. The persons who allow new contributors to the organisation could be some from the *Community Elders* (#28 <#28>) team. Then we might also want some system to remove a *member* from the organisation after he/she has been inactive for a specific period of time, otherwise we'll end up with an unmanageable amount of *members*. But that's a secondary priority, we have to define the rules how to get in first. The really hard problem with this proposal is that it's hard to draw the line, in the end of the day it's a subjective (not always objective) decision that has to be taken. But we should try to define some requirements that everyone are aware of. We don't want them to be too easy to get (we will end up with all contributors being members => unmanagable) but at the same time not too hard to get either (few members, assignees, etc. reduces the velocity of the project). At least it would be really helpful to have a link to a document that states *something* about this. If someone want me to tell my story about how I became a maintainer while still attending upper secondary school in Finland and get the "outside" perspective from that story, feel free to ask. P.S. I know *nothing* about the current process. Correct me if I'm wrong, but it's an inside-Google-thing right now, right? cc-ing some people: @sarahnovotny <https://github.com/sarahnovotny> @bgrant0607 <https://github.com/bgrant0607> @vishh <https://github.com/vishh> @philips <https://github.com/philips> @jessfraz <https://github.com/jessfraz> @thockin <https://github.com/thockin> @kubernetes/contributor-experience <https://github.com/orgs/kubernetes/teams/contributor-experience> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#142>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFVgVPzyI-XXZdqmT4jFBTRe4w3T4607ks5rEtiCgaJpZM4LDm3_> .

[bgrant0607]

There is a start at documenting existing roles here:
https://github.com/kubernetes/community/blob/master/governance.md

[thockin]

That's a very exhaustive breakdown!

…

On Thu, Dec 15, 2016 at 9:40 AM, Brian Grant ***@***.***> wrote: There is a start at documenting existing roles here: https://github.com/kubernetes/community/blob/master/governance.md — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#142 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFVgVELkhhLKzjgc9CegBL1PIO43UYn_ks5rIXuZgaJpZM4LDm3_> .

[bgrant0607]

I have pushed another batch of updates to governance.md for any who wishes to take a look.

[tmrts]

Other than automating the removal of inactive members, the governance.md now contains details about the current roles in the organization and the requirements for those roles (reviewer, approver, maintainer, etc.), we can close this issue.