1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
|
# Kubernetes GitHub Organization Guide
The Kubernetes project leverages multiple GitHub organizations to store and
organize code. This guide contains the details on how to run those organizations
for CNCF compliance and for the guidelines of the community.
## SLOs
The [GitHub Administration Team] will aim to handle requests in the following
time frames:
- Organization invites should be handled within 72 hours of all requirements for
membership being met (all +1s obtained).
- Repository creation or migration requests should be responded to within 72
hours of the issue being opened. There may be information required or specific
requirements that take additional time, but once all requirements are met, the
repo should be created within 72 hours.
- Security or moderation requests should be handled ASAP, and coverage should be
provided in multiple time zones and countries.
- All other requests should be responded to within 72 hours of the issue being
opened. The time to resolve these requests will vary depending on the
specifics of the request.
If a request is taking longer than the above time frames, or there is a need to
escalate an urgent request, please mention **[@kubernetes/owners]** on the
associated issue for assistance.
## Organization Naming
Kubernetes managed organizations should be in the form of `kubernetes-[thing]`.
For example, [kubernetes-client](https://github.com/kubernetes-client) where the
API clients are housed.
Prior to creating an organization please contact the steering committee for
direction and approval.
Note: The CNCF, as part of the Linux Foundation, holds the trademark on the
Kubernetes name. All GitHub organizations with Kubernetes in the name should be
managed by the Kubernetes project or use a different name.
## Transferring Outside Code Into A Kubernetes Organization
Due to licensing and CLA issues, prior to transferring software into a
Kubernetes managed organization there is some due diligence that needs to occur.
Please contact the steering committee and CNCF prior to moving any code in.
It is easier to start new code in a Kubernetes organization than it is to
transfer in existing code.
## Team Guidance
Each organization should have the following teams:
- teams for each repo `foo`
- `foo-admins`: granted admin access to the `foo` repo
- `foo-maintainers`: granted write access to the `foo` repo
- `foo-reviewers`: granted read access to the `foo` repo; intended to be used
as a notification mechanism for interested/active contributors for the `foo`
repo
- a `bots` team
- should contain bots such as @k8s-ci-robot and @thelinuxfoundation that are
necessary for org and repo automation
- an `owners` team
- should be populated by everyone who has `owner` privileges to the org
- gives users the opportunity to ping owners as a group rather than having to
search for individuals
**NB**: Not all organizations in use today currently follow this team guidance.
We are looking to coalesce existing teams towards this model, and use this model
for all orgs going forward. Notable discrepancies at the moment:
- `foo-reviewers` teams are considered a historical subset of
`kubernetes-sig-foo-pr-reviews` teams and are intended mostly as a fallback
notification mechanism when requested reviewers are being unresponsive.
Ideally OWNERS files can be used in lieu of these teams.
- `admins-foo` and `maintainers-foo` teams as used by the kubernetes-incubator
org. This was a mistake that swapped the usual convention, and we would like
to rename the team
## Project Board Guidance
Guidelines for project boards in the Kubernetes GitHub orgs are described below:
- All project boards should be organization-level project boards instead of
repository-level even if the project board is intended to be scoped to a single
repository. It is easier to distribute permissions via org-level project boards
since write access to a repo-level project board requires full write access
to the repo.
- Project Boards *must* have `Public` visibility.
- The default _Organization Member Permission_ is suggested to be `Write` so
that contributors can move cards themselves as they take on work items.
However if the project board needs to be only scoped to a set of people,
the access *must* be granted through a GitHub team, instead of direct
collaborator access.
**NB**: Not all project boards in use today currently follow this guidance.
We are looking to coalesce existing project boards towards this model, and use
this model for all orgs going forward.
## Repository Guidance
Repositories have additional guidelines and requirements, such as the use of CLA
checking on all contributions. For more details on those please see the
[Kubernetes Template
Project](https://github.com/kubernetes/kubernetes-template-project), and the
[Repository Guidelines](kubernetes-repositories.md)
[GitHub Administration Team]:
/github-management/README.md#github-administration-team
[@kubernetes/owners]: https://github.com/orgs/kubernetes/teams/owners
|
