kubernetes
/
community
mirror of https://github.com/kubernetes/community.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #619 from pwittrock/governance 

Refactor governance docs
This commit is contained in:
Phillip Wittrock 2017-05-18 08:48:25 -07:00 committed by GitHub
parent 90b7e3d999 dcd3a84473
commit 8109345036
5 changed files with 222 additions and 268 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

77
community-membership.md Normal file
View File

@ -0,0 +1,77 @@
# Community membership
New community members:
- [**New Contributor**](https://github.com/kubernetes/contrib/issues/1090): a
couple of PRs; should be welcomed to the community, helped with PR workflow, and
directed to relevant documentation
- **Active Contributor**: at least 3 merged and/or assigned PRs (which could include documentation
contributions as well as code), including one in the past month; we have
[expectations](contributors/devel/community-expectations.md)
that frequent contributors will assist in our code-review process and with project
maintenance
Established community members:
Established community members are expected to demonstrate their adherence to the principles in this
document, familiarity with project organization, roles, policies, procedures, conventions, etc.,
and technical and/or writing ability. Role-specific expectations, responsibilities, and requirements
are enumerated below.
- **Member**: an active contributor for at least 3 months; at least 10 merged and/or assigned PRs; active enough to be useful
to assign issues to them and add them to a github team (e.g., for a SIG) for notification
purposes; trusted enough to run tests on their PRs automatically; can issue "@k8s-bot ok to test"
for other contributors; if they choose public membership, they get a badge on their github profile;
should subscribe to kubernetes-dev@googlegroups.com; expected to be familiar with
project organization, roles, policies, procedures, etc.; should read the [developer
guide](contributors/devel/README.md); must enable
[two-factor authentication](https://help.github.com/articles/about-two-factor-authentication/)
- **Reviewer**: org member for at least 3 months; at least 20 merged and/or assigned PRs, including
at least 3 as the primary reviewer; familiar enough with some part of the codebase to be in some
[OWNERS](contributors/devel/owners.md) file as a reviewer (in repos using the bot),
assigned related PRs, assigned relevant test bugs; responsible for project quality control via
[code reviews](contributors/devel/collab.md); expected to be responsive to
review requests as per [community expectations](contributors/devel/community-expectations.md);
can champion incubator repos; must be nominated by an approver for that part of the codebase,
with no objections from other approvers; should be added to
[`kubernetes-reviewers`](https://github.com/orgs/kubernetes/teams/kubernetes-reviewers);
"read access" to kubernetes repo; get a badge on PR and issue comments; may be asked to
become a reviewer as a precondition for accepting a large code contribution
- **Approver**: in some [OWNERS](contributors/devel/owners.md) file as an approver, which
will be needed to get code merged; previously a reviewer for that part of the
codebase for at least 3 months; at least 30 merged and/or assigned PRs, including at least 10 as
the primary reviewer; expected to be responsive to review requests as per
[community expectations](contributors/devel/community-expectations.md); expected to
mentor contributors and reviewers; demonstrated sound technical judgement; nominated
by an area/component owner, with no objections from other owners; may be asked to
become an approver as a precondition for accepting a large code contribution
- **Area/Component Owner**: in top-level [OWNERS](contributors/devel/owners.md) file for
some area/component as an approver; design/proposal approval authority for some area
of the project, though escalation is still possible; expected to mentor and guide approvers,
reviewers, and other contributors; may be asked to become an area/component owner as a precondition
for accepting the contribution of a new component or other major function
- [**kubernetes-maintainers**](https://github.com/orgs/kubernetes/teams/kubernetes-maintainers):
approver for some part of the codebase for at least 3 months; on project for at least 1 year;
at least 50 merged and/or assigned PRs, including at least 20 as the primary reviewer;
write access to repo (assign issues/PRs, add/remove labels and milestones, edit issues and PRs, edit wiki,
create/delete labels and milestones); technically can lgtm any PR and cause it
to be merged by the submit queue, but expected to respect OWNERS files; expected to review PRs, fix bugs, maintain and
improve health and quality of the project, provide user support, mentor and guide approvers,
reviewers, and other contributors; must apply to `kubernetes-maintainers@googlegroups.com`, with a
[Champion](https://github.com/kubernetes/community/blob/master/incubator.md#faq) from the existing
kubernetes-maintainers members and a Sponsor from Project Approvers, with a summary
of contributions to the project, current project responsibilities, and links to merged and assigned PRs;
at least 3 of the maintainers must approve the application, with no objections; the application
expires after 2 weeks if not enough approvals are granted
- **Project Approvers**: approver in [top-level OWNERS file in kubernetes repo](https://github.com/kubernetes/kubernetes/blob/master/OWNERS);
de-facto project decision makers; technically can
approve virtually any PRs; can sponsor incubator repos; can sponsor maintainers;
maintainer in good standing for at least 1 year; strong technical vision;
committed to project's mission and culture; nomination/application process TBD
- [**API Approver**](https://github.com/orgs/kubernetes/teams/api-approvers):
lead designers of the project, who are familiar with the
design, requirements, mechanics, conventions, style, scope, gotchas, etc.
of the API; most beta/GA API changes are vetted by the API approvers
- [**API Reviewer**](https://github.com/orgs/kubernetes/teams/api-reviewers):
contributors familiar with design, requirements, mechanics, conventions, style,
scope, gotchas, etc. of the API; have written and/or reviewed Kubernetes APIs

174
governance.md
View File

@ -19,6 +19,14 @@ We value our community tremendously and we'd like to keep cultivating a friendly
environment for our contributors and users. We want everyone in the community to have
[positive experiences](https://www.cncf.io/blog/2016/12/14/diversity-scholarship-series-one-software-engineers-unexpected-cloudnativecon-kubecon-experience).
# Community membership
See [community membership]
# SIG Governance
See [sig governance]
# Repository guidelines
All repositories under Kubernetes github orgs, such as kubernetes and kubernetes-incubator,
@ -26,170 +34,16 @@ should follow the procedures outlined in the [incubator document](incubator.md).
use the [Apache Licence version 2.0](LICENSE). Documentation repositories should use the
[Creative Commons License version 4.0](https://github.com/kubernetes/kubernetes.github.io/blob/master/LICENSE).
# Project Roles
# Incubator process
Kubernetes is a large project. It is necessarily a group effort.
There are many ways to participate and contribute.
We value all forms of constructive contribution, no matter how small, even if not
explicitly described below.
It is intended that contributors have the opportunity to grow in responsibilities,
privileges, and authority corresponding to the scope, quality, quantity, and duration
of their contributions. Definition of criteria and process is in progress, with preliminary
requirements below.
Why would someone want to perform and be accepted into a particular role?
- To work more efficiently; more permissions reduce development friction
- Status (have the Kubernetes badge on his/her profile and/or contributions)
- Ownership
- etc...
Roles that are currently assumed by project participants are described below,
with a focus on the `kubernetes/kubernetes` repo.
## Code and documentation contributors
New community members:
- [**New Contributor**](https://github.com/kubernetes/contrib/issues/1090): a
couple of PRs; should be welcomed to the community, helped with PR workflow, and
directed to relevant documentation
- **Active Contributor**: at least 3 merged and/or assigned PRs (which could include documentation
contributions as well as code), including one in the past month; we have
[expectations](contributors/devel/community-expectations.md)
that frequent contributors will assist in our code-review process and with project
maintenance
Established community members:
Established community members are expected to demonstrate their adherence to the principles in this
document, familiarity with project organization, roles, policies, procedures, conventions, etc.,
and technical and/or writing ability. Role-specific expectations, responsibilities, and requirements
are enumerated below.
- **Member**: an active contributor for at least 3 months; at least 10 merged and/or assigned PRs; active enough to be useful
to assign issues to them and add them to a github team (e.g., for a SIG) for notification
purposes; trusted enough to run tests on their PRs automatically; can issue "@k8s-bot ok to test"
for other contributors; if they choose public membership, they get a badge on their github profile;
should subscribe to kubernetes-dev@googlegroups.com; expected to be familiar with
project organization, roles, policies, procedures, etc.; should read the [developer
guide](contributors/devel/README.md); must enable
[two-factor authentication](https://help.github.com/articles/about-two-factor-authentication/)
- **Reviewer**: org member for at least 3 months; at least 20 merged and/or assigned PRs, including
at least 3 as the primary reviewer; familiar enough with some part of the codebase to be in some
[OWNERS](contributors/devel/owners.md) file as a reviewer (in repos using the bot),
assigned related PRs, assigned relevant test bugs; responsible for project quality control via
[code reviews](contributors/devel/collab.md); expected to be responsive to
review requests as per [community expectations](contributors/devel/community-expectations.md);
can champion incubator repos; must be nominated by an approver for that part of the codebase,
with no objections from other approvers; should be added to
[`kubernetes-reviewers`](https://github.com/orgs/kubernetes/teams/kubernetes-reviewers);
"read access" to kubernetes repo; get a badge on PR and issue comments; may be asked to
become a reviewer as a precondition for accepting a large code contribution
- **Approver**: in some [OWNERS](contributors/devel/owners.md) file as an approver, which
will be needed to get code merged; previously a reviewer for that part of the
codebase for at least 3 months; at least 30 merged and/or assigned PRs, including at least 10 as
the primary reviewer; expected to be responsive to review requests as per
[community expectations](contributors/devel/community-expectations.md); expected to
mentor contributors and reviewers; demonstrated sound technical judgement; nominated
by an area/component owner, with no objections from other owners; may be asked to
become an approver as a precondition for accepting a large code contribution
- **Area/Component Owner**: in top-level [OWNERS](contributors/devel/owners.md) file for
some area/component as an approver; design/proposal approval authority for some area
of the project, though escalation is still possible; expected to mentor and guide approvers,
reviewers, and other contributors; may be asked to become an area/component owner as a precondition
for accepting the contribution of a new component or other major function
- [**kubernetes-maintainers**](https://github.com/orgs/kubernetes/teams/kubernetes-maintainers):
approver for some part of the codebase for at least 3 months; on project for at least 1 year;
at least 50 merged and/or assigned PRs, including at least 20 as the primary reviewer;
write access to repo (assign issues/PRs, add/remove labels and milestones, edit issues and PRs, edit wiki,
create/delete labels and milestones); technically can lgtm any PR and cause it
to be merged by the submit queue, but expected to respect OWNERS files; expected to review PRs, fix bugs, maintain and
improve health and quality of the project, provide user support, mentor and guide approvers,
reviewers, and other contributors; must apply to `kubernetes-maintainers@googlegroups.com`, with a
[Champion](https://github.com/kubernetes/community/blob/master/incubator.md#faq) from the existing
kubernetes-maintainers members and a Sponsor from Project Approvers, with a summary
of contributions to the project, current project responsibilities, and links to merged and assigned PRs;
at least 3 of the maintainers must approve the application, with no objections; the application
expires after 2 weeks if not enough approvals are granted
- **Project Approvers**: approver in [top-level OWNERS file in kubernetes repo](https://github.com/kubernetes/kubernetes/blob/master/OWNERS);
de-facto project decision makers; technically can
approve virtually any PRs; can sponsor incubator repos; can sponsor maintainers;
maintainer in good standing for at least 1 year; strong technical vision;
committed to project's mission and culture; nomination/application process TBD
- [**API Approver**](https://github.com/orgs/kubernetes/teams/api-approvers):
lead designers of the project, who are familiar with the
design, requirements, mechanics, conventions, style, scope, gotchas, etc.
of the API; most beta/GA API changes are vetted by the API approvers
- [**API Reviewer**](https://github.com/orgs/kubernetes/teams/api-reviewers):
contributors familiar with design, requirements, mechanics, conventions, style,
scope, gotchas, etc. of the API; have written and/or reviewed Kubernetes APIs
## SIG roles
- **SIG Participant**: active in one or more areas of the project; wide
variety of roles are represented
- **SIG Lead**: SIG organizer
## Management roles
- **Team Lead**: tech lead or manager of some team at some company working on
K8s; can influence priorities of their team members; pragmatically,
probably want label/assignment powers
- [**kubernetes-pm**](https://github.com/orgs/kubernetes/teams/kubernetes-pm): help to [manage and maintain the project](project-managers/README.md) in
ways other than just writing code (e.g. managing issues); should subscribe to kubernetes-pm@googlegroups.com
## Rotations
- [**Build Cop**](contributors/devel/on-call-build-cop.md): ensure tests pass, submit queue is working, rollback PRs,
manually merge as necessary to fix build; should be members of appropriate repo's build-cops github team
(e.g., [kubernetes-build-cops](https://github.com/orgs/kubernetes/teams/kubernetes-build-cops))
- [**User-Support Rotation**](contributors/devel/on-call-user-support.md): answer questions on stackoverflow, googlegroups,
slack, twitter, etc. full time while on duty
## Release roles
- The roles of the individuals/team responsible for major, minor, and patch releases is documented
[here](https://github.com/kubernetes/community/tree/master/contributors/devel/release). Should be
members of the appropriate release-managers github team (e.g.,
[kubernetes-release-managers](https://github.com/orgs/kubernetes/teams/kubernetes-release-managers)).
## Other duty-specific github roles:
- [**Github Org Owner**](https://github.com/orgs/kubernetes/people?utf8=%E2%9C%93&query=%20role%3Aowner):
can create repos, do ~any github action; the number of
owners shouldn't scale with the organization's growth, O(1), and optimally it
should be less than 20 people who are very familiar with project workings and
distributed across a few time zones and organizations The other repos will
have distinct sets of people filling some of the above roles, also.
## Other repositories
Guidelines for roles in other repositories are TBD. New subprojects/repositories need to be
able to add reviewers, approvers, and maintainers more rapidly than more mature subprojects.
Subprojects less than 1 year old will have relaxed time and PR requirements.
## Removal from roles
Most of the above roles require continuous, significant involvement in the project. If someone
becomes unable or unwilling to continue in their roles, they may retire. If someone doesn't fulfill
their role for 90 days or violates the code of conduct, they may be removed from the role (escalation/vote
process TBD). If they wish to resume their role in the future, they may request to return to it by asking
the current members filling that role.
# SIG Governance
In order to standardize Special Interest Group efforts, create maximum transparency, and route contributors to the appropriate SIG, SIGs should follow the guidelines stated below:
* Meet regularly, at least for 30 minutes every 3 weeks, except November and December
* Keep up-to-date meeting notes, linked from the SIG's page in the community repo
* Announce meeting agenda and minutes after each meeting, on their SIG mailing list
* Record SIG meeting and make it publicly available
* Ensure the SIG's mailing list and slack channel are archived
* Report activity in the weekly community meeting at least once every 6 weeks
* Participate in release planning meetings and retrospectives, and burndown meetings, as needed
* Ensure related work happens in a project-owned github org and repository, with code and tests explicitly owned and supported by the SIG, including issue triage, PR reviews, test-failure response, bug fixes, etc.
* Use the above forums as the primary means of working, communicating, and collaborating, as opposed to private emails and meetings
* Represent the SIG for the PM group - see [PM SIG representatives](https://github.com/kubernetes/community/blob/master/sig-pm/SIG%20PM%20representatives.md).
See [incubator process]
# CLA
All contributors must sign the CNCF CLA, as described [here](CLA.md).
[community membership]: /community-membership.md
[sig governance]: /sig-governance.md
[incubator process]: /incubator.md
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/governance.md?pixel)]()

108
sig-creation-procedure.md
View File

@ -1,109 +1,3 @@
## SIG creation procedure
### Prerequisites
* Propose the new SIG publicly, including a brief mission statement, by emailing kubernetes-dev@googlegroups.com and kubernetes-users@googlegroups.com, then wait a couple of days for feedback
* Ask a repo maintainer to create a github label, if one doesn't already exist: sig/foo
* Request a new [kubernetes.slack.com](http://kubernetes.slack.com) channel (#sig-foo) from **@sarahnovotny**. New users can join at [slack.kubernetes.io](http://slack.kubernetes.io).
* Slack activity is archived at [kubernetes.slackarchive.io](http://kubernetes.slackarchive.io). To start archiving a new channel invite the slackarchive bot to the channel via `/invite @slackarchive`
* Organize video meetings as needed. No need to wait for the [Weekly Community Video Conference](community/README.md) to discuss. Please report summary of SIG activities there.
* Request a Zoom account from @sarahnovotny if you expect more than 30 attendees or attendees from China.
* Add the meeting to the community meeting calendar by inviting cgnt364vd8s86hr2phapfjc6uk@group.calendar.google.com.
* Use existing proposal and PR process (to be documented)
* Announce new SIG on kubernetes-dev@googlegroups.com
* Submit a PR to add a row for the SIG to the table in the kubernetes/community README.md file, to create a kubernetes/community directory, and to add any SIG-related docs, schedules, roadmaps, etc. to your new kubernetes/community/SIG-foo directory.
### **Creating service accounts for the SIG**
With a purpose to distribute the channels of notification and discussion of the variuos topics, every SIG has to use multiple accounts to GitHub mentioning and notifications. Below the procedure is explained step-by-step.
NOTE: This procedure is managed and maintained by **[@idvoretskyi](https://github.com/idvoretskyi)**; please, reach him directly in case of any questions/suggestions.
#### **Google Groups creation**
Create Google Groups at [https://groups.google.com/forum/#!creategroup](https://groups.google.com/forum/#!creategroup), following the procedure:
* Each SIG should have one discussion groups, and a number of groups for mirroring relevant github notifications;
* Create groups using the name conventions below;
* Groups should be created as e-mail lists with at least three owners (including sarahnovotny at google.com and ihor.dvoretskyi at gmail.com);
* To add the owners, visit the Group Settings (drop-down menu on the right side), select Direct Add Members on the left side and add Sarah and Ihor via email address (with a suitable welcome message); in Members/All Members select Ihor and Sarah and assign to an "owner role";
* Set "View topics", "Post", "Join the Group" permissions to be "Public"
Name convention:
* kubernetes-sig-foo (the discussion group)
* kubernetes-sig-foo-misc
* kubernetes-sig-foo-test-failures
* kubernetes-sig-foo-bugs
* kubernetes-sig-foo-feature-requests
* kubernetes-sig-foo-proposals
* kubernetes-sig-foo-pr-reviews
* kubernetes-sig-foo-api-reviews
Example:
* kubernetes-sig-onprem
* kubernetes-sig-onprem-misc
* kubernetes-sig-onprem-test-failures
* kubernetes-sig-onprem-bugs
* kubernetes-sig-onprem-feature-requests
* kubernetes-sig-onprem-proposals
* kubernetes-sig-onprem-pr-reviews
* kubernetes-sig-onprem-api-reviews
#### **GitHub users creation**
Create the GitHub users at [https://github.com/join](https://github.com/join), using the name convention below.
As an e-mail address, please, use the Google Group e-mail address of the respective Google Group, created before (i.e. - for user ‘k8s-mirror-foo-misc’ use ‘[kubernetes-sig-foo-misc@googlegroups.com](mailto:kubernetes-sig-foo-misc@googlegroups.com)’). After creating the GitHub users, please, add these users to the Kubernetes organization. If you don't have enought permissions to do that (by default, you don't), please request **@idvoretskyi** (backup person - **@sarahnovotny**) to help you with this. If GitHub contacts you about having too many robot accounts, please let us know.
Name convention:
* k8s-mirror-foo-misc
* k8s-mirror-foo-test-failures
* k8s-mirror-foo-bugs
* k8s-mirror-foo-feature-requests
* k8s-mirror-foo-proposals
* k8s-mirror-foo-pr-reviews
* k8s-mirror-foo-api-reviews
There is no need for a k8s-mirro-foo user.
Example:
* k8s-mirror-onprem-misc
* k8s-mirror-onprem-test-failures
* k8s-mirror-onprem-bugs
* k8s-mirror-onprem-feature-requests
* k8s-mirror-onprem-proposals
* k8s-mirror-onprem-pr-reviews
* k8s-mirror-onprem-api-reviews
NOTE: We have found that Github's notification autocompletion finds the users before the corresponding teams. This is the reason we recommend naming the users `k8s-mirror-foo-*` instead of `k8s-sig-foo-*`. If you previously created users named `k8s-sig-foo-*`, we recommend you rename them.
#### **Create the GitHub teams**
Create the GitHub teams at [https://github.com/orgs/kubernetes/new-team](https://github.com/orgs/kubernetes/new-team), using the name convention below. Please, add the GitHub users (created before) to the GitHub teams respectively.
Name convention:
* sig-foo-misc
* sig-foo-test-failures
* sig-foo-bugs
* sig-foo-feature-requests
* sig-foo-proposals
* sig-foo-pr-reviews
* sig-foo-api-reviews
Note that there should not be a sig-foo team. We want to encourage contributors to select the most appropriate team to notify.
Example:
* sig-onprem-misc
* sig-onprem-test-failures
* sig-onprem-bugs
* sig-onprem-feature-requests
* sig-onprem-proposals
* sig-onprem-pr-reviews
* sig-onprem-api-reviews
Moved to [sig governance](/sig-governance.md#sig-creation-procecure)

129
sig-governance.md Normal file
View File

@ -0,0 +1,129 @@
# SIG Governance
In order to standardize Special Interest Group efforts, create maximum transparency, and route contributors to the appropriate SIG, SIGs should follow the guidelines stated below:
* Meet regularly, at least for 30 minutes every 3 weeks, except November and December
* Keep up-to-date meeting notes, linked from the SIG's page in the community repo
* Announce meeting agenda and minutes after each meeting, on their SIG mailing list
* Record SIG meeting and make it publicly available
* Ensure the SIG's mailing list and slack channel are archived
* Report activity in the weekly community meeting at least once every 6 weeks
* Participate in release planning meetings and retrospectives, and burndown meetings, as needed
* Ensure related work happens in a project-owned github org and repository, with code and tests explicitly owned and supported by the SIG, including issue triage, PR reviews, test-failure response, bug fixes, etc.
* Use the above forums as the primary means of working, communicating, and collaborating, as opposed to private emails and meetings
* Represent the SIG for the PM group - see [PM SIG representatives](https://github.com/kubernetes/community/blob/master/sig-pm/SIG%20PM%20representatives.md).
## SIG roles
- **SIG Participant**: active in one or more areas of the project; wide
variety of roles are represented
- **SIG Lead**: SIG organizer
## SIG creation procedure
### Prerequisites
* Propose the new SIG publicly, including a brief mission statement, by emailing kubernetes-dev@googlegroups.com and kubernetes-users@googlegroups.com, then wait a couple of days for feedback
* Ask a repo maintainer to create a github label, if one doesn't already exist: sig/foo
* Request a new [kubernetes.slack.com](http://kubernetes.slack.com) channel (#sig-foo) from **@sarahnovotny**. New users can join at [slack.kubernetes.io](http://slack.kubernetes.io).
* Slack activity is archived at [kubernetes.slackarchive.io](http://kubernetes.slackarchive.io). To start archiving a new channel invite the slackarchive bot to the channel via `/invite @slackarchive`
* Organize video meetings as needed. No need to wait for the [Weekly Community Video Conference](community/README.md) to discuss. Please report summary of SIG activities there.
* Request a Zoom account from @sarahnovotny if you expect more than 30 attendees or attendees from China.
* Add the meeting to the community meeting calendar by inviting cgnt364vd8s86hr2phapfjc6uk@group.calendar.google.com.
* Use existing proposal and PR process (to be documented)
* Announce new SIG on kubernetes-dev@googlegroups.com
* Submit a PR to add a row for the SIG to the table in the kubernetes/community README.md file, to create a kubernetes/community directory, and to add any SIG-related docs, schedules, roadmaps, etc. to your new kubernetes/community/SIG-foo directory.
### **Creating service accounts for the SIG**
With a purpose to distribute the channels of notification and discussion of the variuos topics, every SIG has to use multiple accounts to GitHub mentioning and notifications. Below the procedure is explained step-by-step.
NOTE: This procedure is managed and maintained by **[@idvoretskyi](https://github.com/idvoretskyi)**; please, reach him directly in case of any questions/suggestions.
#### **Google Groups creation**
Create Google Groups at [https://groups.google.com/forum/#!creategroup](https://groups.google.com/forum/#!creategroup), following the procedure:
* Each SIG should have one discussion groups, and a number of groups for mirroring relevant github notifications;
* Create groups using the name conventions below;
* Groups should be created as e-mail lists with at least three owners (including sarahnovotny at google.com and ihor.dvoretskyi at gmail.com);
* To add the owners, visit the Group Settings (drop-down menu on the right side), select Direct Add Members on the left side and add Sarah and Ihor via email address (with a suitable welcome message); in Members/All Members select Ihor and Sarah and assign to an "owner role";
* Set "View topics", "Post", "Join the Group" permissions to be "Public"
Name convention:
* kubernetes-sig-foo (the discussion group)
* kubernetes-sig-foo-misc
* kubernetes-sig-foo-test-failures
* kubernetes-sig-foo-bugs
* kubernetes-sig-foo-feature-requests
* kubernetes-sig-foo-proposals
* kubernetes-sig-foo-pr-reviews
* kubernetes-sig-foo-api-reviews
Example:
* kubernetes-sig-onprem
* kubernetes-sig-onprem-misc
* kubernetes-sig-onprem-test-failures
* kubernetes-sig-onprem-bugs
* kubernetes-sig-onprem-feature-requests
* kubernetes-sig-onprem-proposals
* kubernetes-sig-onprem-pr-reviews
* kubernetes-sig-onprem-api-reviews
#### **GitHub users creation**
Create the GitHub users at [https://github.com/join](https://github.com/join), using the name convention below.
As an e-mail address, please, use the Google Group e-mail address of the respective Google Group, created before (i.e. - for user ‘k8s-mirror-foo-misc’ use ‘[kubernetes-sig-foo-misc@googlegroups.com](mailto:kubernetes-sig-foo-misc@googlegroups.com)’). After creating the GitHub users, please, add these users to the Kubernetes organization. If you don't have enought permissions to do that (by default, you don't), please request **@idvoretskyi** (backup person - **@sarahnovotny**) to help you with this. If GitHub contacts you about having too many robot accounts, please let us know.
Name convention:
* k8s-mirror-foo-misc
* k8s-mirror-foo-test-failures
* k8s-mirror-foo-bugs
* k8s-mirror-foo-feature-requests
* k8s-mirror-foo-proposals
* k8s-mirror-foo-pr-reviews
* k8s-mirror-foo-api-reviews
There is no need for a k8s-mirro-foo user.
Example:
* k8s-mirror-onprem-misc
* k8s-mirror-onprem-test-failures
* k8s-mirror-onprem-bugs
* k8s-mirror-onprem-feature-requests
* k8s-mirror-onprem-proposals
* k8s-mirror-onprem-pr-reviews
* k8s-mirror-onprem-api-reviews
NOTE: We have found that Github's notification autocompletion finds the users before the corresponding teams. This is the reason we recommend naming the users `k8s-mirror-foo-*` instead of `k8s-sig-foo-*`. If you previously created users named `k8s-sig-foo-*`, we recommend you rename them.
#### **Create the GitHub teams**
Create the GitHub teams at [https://github.com/orgs/kubernetes/new-team](https://github.com/orgs/kubernetes/new-team), using the name convention below. Please, add the GitHub users (created before) to the GitHub teams respectively.
Name convention:
* sig-foo-misc
* sig-foo-test-failures
* sig-foo-bugs
* sig-foo-feature-requests
* sig-foo-proposals
* sig-foo-pr-reviews
* sig-foo-api-reviews
Note that there should not be a sig-foo team. We want to encourage contributors to select the most appropriate team to notify.
Example:
* sig-onprem-misc
* sig-onprem-test-failures
* sig-onprem-bugs
* sig-onprem-feature-requests
* sig-onprem-proposals
* sig-onprem-pr-reviews
* sig-onprem-api-reviews

2
sig-list.md
View File

@ -8,7 +8,7 @@ depending on their needs and workflow.
Each group's material is in its subdirectory in this project.
When the need arises, a [new SIG can be created](sig-creation-procedure.md)
When the need arises, a [new SIG can be created](sig-governance.md#sig-creation-procedure)
### Master SIG List