Add new membership procedure doc
This commit is contained in:
parent
633c4c1923
commit
841f54aa36
|
@ -0,0 +1,103 @@
|
|||
# Adding a new member to a Kubernetes GitHub Org
|
||||
|
||||
This procedure outlines the steps to add someone to a Kubernetes GitHub
|
||||
organization. These directions are based off of the [community membership]
|
||||
guidelines. If there is a discrepancy as to the exact membership requirements,
|
||||
the [community membership] guidelines take precedence.
|
||||
|
||||
## Membership Requirements
|
||||
|
||||
All members of the Kubernetes GitHub org are required to do the following:
|
||||
|
||||
- Have 2FA enabled on their GitHub account
|
||||
|
||||
This is enforced by GitHub. The contributor will not be able to accept the org
|
||||
invitation without it, and they will be removed from the org automatically in
|
||||
the event they disable it.
|
||||
|
||||
- Join the [k-dev] mailing list
|
||||
|
||||
We don't explicitly check this, but we require the contributor to check the
|
||||
box saying that they have joined.
|
||||
|
||||
- List their active contributions
|
||||
|
||||
This is left purposefully vague. We want to record what those contributions
|
||||
are, but we leave it up to the sponsors to determine if they are at a bar that
|
||||
warrants membership. We want to make it easy for those who are actively
|
||||
contributing to join, but this bar should be higher than, for example, a few
|
||||
spelling corrections.
|
||||
|
||||
- List the active subprojects they are involved in
|
||||
|
||||
In the same vein as the above, we leave this vague, and as guidance for the
|
||||
sponsors. The sponsors should also be active in these same subprojects.
|
||||
|
||||
## Sponsor Requirements
|
||||
|
||||
One of the most critical pieces in the process is validating the sponsors meet
|
||||
the requirements to sponsor a new member. With the size of the Kubernetes
|
||||
project, those involved with processing new memberships do not have the
|
||||
visibility to determine if each prospective member's contributions meet the
|
||||
standard needed to become a member. We rely on sponsors to vouch for the work of
|
||||
the prospective new member, and to validate the work they are doing.
|
||||
|
||||
We do however, have to validate that the sponsor's credentials meet the standard
|
||||
required to be eligible to sponsor a new member. These requirements are:
|
||||
|
||||
- Sponsors must be a member of the org they are attempting to sponsor for.
|
||||
|
||||
For example, if the membership being requested is for kubernetes-incubator,
|
||||
then the sponsor should be a member of either that org, or main Kubernetes
|
||||
org (as members of the main org have implicit membership in other orgs).
|
||||
|
||||
- Sponsors must be a reviewer or approver in at least one OWNERS file in any
|
||||
Kubernetes GitHub org.
|
||||
|
||||
- Sponsors must be from multiple member companies to demonstrate integration
|
||||
across community
|
||||
|
||||
A single sponsor may be from the same company as the prospective member, but
|
||||
no more than one sponsor can be from the same company. If both sponsors on an
|
||||
application are from the same company, please request that the applicant
|
||||
solicit an additional sponsor from a different company.
|
||||
|
||||
- Sponsors must have close interactions with the prospective member
|
||||
|
||||
Sponsors need to be familiar enough with the prospective member's
|
||||
contributions to be able to properly vouch for them. This is to ensure
|
||||
integrity in the membership process, and a "web of trust" for the privileges
|
||||
we afford members.
|
||||
|
||||
If there are questions with regard to a sponsor's qualifications, please attempt
|
||||
to seek clarification or a second opinion before moving forward with processing
|
||||
the membership.
|
||||
|
||||
## Processing the request
|
||||
|
||||
Once all the requirements have been validated, we can move forward with
|
||||
processing the membership.
|
||||
|
||||
1. Open a PR against the [kubernetes/org] config, adding the potential member's
|
||||
GitHub username to the members list. Note, that the list is alpha sorted, but
|
||||
case insensitive.
|
||||
|
||||
1. For clarity, please use one commit per username added (although you may add
|
||||
that user to multiple orgs in the same commit).
|
||||
|
||||
1. In the PR body (and not the commit message), add `fixes #1234, fixes #1234`
|
||||
with the issue numbers of the membership request issues that this PR is
|
||||
resolving. One PR can be used to resolve multiple membership requests.
|
||||
|
||||
1. Add a note to the original membership request stating that a membership
|
||||
invite will be sent out once the PR has merged.
|
||||
|
||||
1. Wait for a member of the GitHub administration team to approve the PR for
|
||||
merge.
|
||||
|
||||
|
||||
|
||||
|
||||
[community membership]: /community-membership.md
|
||||
[k-dev]: https://groups.google.com/forum/#!forum/kubernetes-dev
|
||||
[kubernetes/org]: https://git.k8s.io/org/
|
Loading…
Reference in New Issue