diff --git a/committee-steering/governance/sig-governance.md b/committee-steering/governance/sig-governance.md index b01256661da..f48b3a5dcf3 100644 --- a/committee-steering/governance/sig-governance.md +++ b/committee-steering/governance/sig-governance.md @@ -1,16 +1,25 @@ # SIG Roles and Organizational Governance -This charter adheres to the conventions described in the [Kubernetes Charter README]. +This charter adheres to the conventions described in the [Kubernetes Charter README]. It will be updated as needed to meet the current needs of the Kubernetes project. -This document will be updated as needed to meet the current needs of the Kubernetes project. +In order to standardize Special Interest Group efforts, create maximum transparency, and route contributors to the appropriate SIG, SIGs should follow these guidelines: +- Create a charter and have it approved according to the [SIG charter process] +- 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 +- Record meetings and make them publicly available on a YouTube playlist +- Report activity in the weekly community meeting at least once every quarter +- 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 [forums provided] as the primary means of working, communicating, and collaborating, as opposed to private emails and meetings + +The process for setting up a SIG or Working Group (WG) is listed in the [sig-wg-lifecycle] document. ## Roles ### Notes on Roles -Unless otherwise stated, individuals are expected to be responsive and active within -their roles. Within this section "member" refers to a member of a Chair, Tech Lead or -Subproject Owner Role. (this different from a SIG or Organization Member). +Within this section "member" refers to a member of a Chair, Tech Lead or +Subproject Owner Role. (this different from a SIG or Organization Member). - Initial members are defined at the founding of the SIG or Subproject as part of the acceptance of that SIG or Subproject. @@ -20,7 +29,7 @@ Subproject Owner Role. (this different from a SIG or Organization Member). role is adequately staffed during the leave. - Members going on leave for 1-3 months *MAY* work with other members to identify a temporary replacement. -- Members of a role *SHOULD* remove any other members that have not communicated a +- Members of a role *SHOULD* remove any other members that have not communicated a leave of absence and either cannot be reached for more than 1 month or are not fulfilling their documented responsibilities for more than 1 month. This may be done through a [super-majority] vote of members, or if there are not @@ -49,7 +58,7 @@ Subproject Owner Role. (this different from a SIG or Organization Member). - Resolve X-Subproject technical issues and decisions - Number: 2-3 - Membership tracked in [sigs.yaml] - + ### Subproject Owner - Subproject Owners @@ -91,6 +100,11 @@ Subproject Owner Role. (this different from a SIG or Organization Member). - Contributing instructions defined in the SIG CONTRIBUTING.md ### Project Management +In addition, SIGs have the following responsibilities to SIG PM: +- identify SIG annual roadmap +- identify all SIG features in the current release +- actively track / maintain SIG features within [k/enhancements] +- attend [SIG PM] meetings, as needed / requested #### Subproject Creation @@ -113,7 +127,7 @@ Option 2: by Federation of Subprojects - [sigs.yaml] *MUST* be updated to include subproject information and [OWNERS] files with subproject owners - Where subprojects processes differ from the SIG governance, they must document how - e.g. if subprojects release separately - they must document how release and planning is performed - + Subprojects may create repos under *github.com/kubernetes-sigs* through [lazy-consensus] of subproject owners. --- @@ -155,11 +169,17 @@ Issues impacting multiple subprojects in the SIG should be resolved by either: - after 3 or more months it *SHOULD* be retired - after 6 or more months it *MUST* be retired +[SIG PM]: https://github.com/kubernetes/community/tree/master/sig-pm +[k/enhancements]: https://github.com/kubernetes/enhancements +[forums provided]: + [lazy-consensus]: http://en.osswiki.info/concepts/lazy_consensus [super-majority]: https://en.wikipedia.org/wiki/Supermajority#Two-thirds_vote [KEP]: https://git.k8s.io/enhancements/keps/YYYYMMDD-kep-template.md [sigs.yaml]: https://github.com/kubernetes/community/blob/master/sigs.yaml#L1454 [OWNERS]: contributors/devel/owners.md +[SIG Charter process]: https://github.com/kubernetes/community/blob/master/committee-steering/governance/README.md [Kubernetes Charter README]: https://github.com/kubernetes/community/blob/master/committee-steering/governance/README.md [Embargo Policy]: https://git.k8s.io/security/private-distributors-list.md#embargo-policy [SECURITY_CONTACTS]: https://github.com/kubernetes/kubernetes-template-project/blob/master/SECURITY_CONTACTS +[sig-wg-lifecycle]: /sig-wg-lifecycle.md diff --git a/committee-steering/governance/wg-governance.md b/committee-steering/governance/wg-governance.md index 875774dcd98..16f9a88ff46 100644 --- a/committee-steering/governance/wg-governance.md +++ b/committee-steering/governance/wg-governance.md @@ -4,14 +4,14 @@ Working Groups provide a formal avenue for disparate groups to collaborate around a common problem, craft a balanced position, and disband. Because they represent the interests of multiple groups, they are a vehicle for consensus building. If code is developed as part of collaboration within the Working Group, that code will be housed in an -appropriate repository as described in the [repositories document][repodoc]. The merging of this code into the repository +appropriate repository as described in the [repositories document]. The merging of this code into the repository will be governed by the standard policies regarding submitting code to that repository (e.g. developed within one or more Subprojects owned by SIGs). Because a working group is an official part of the Kubernetes project it is subject to steering committee oversight over its formation and disbanding. -[repodoc]: https://github.com/kubernetes/community/blob/master/github-management/kubernetes-repositories.md +The tactical checklist to creation and/or retirement is found in the [SIG / WG lifeycle] document. ## Goals of the process @@ -26,7 +26,7 @@ over its formation and disbanding. - Changing the status of existing Working Groups/SIGs/Sub-projects ## Working Group Relationship To SIGs -Assets owned by the Kubernetes project (e.g. code, docs, blogs, processes, etc) are owned and +Assets owned by the Kubernetes project (e.g. code, docs, blogs, processes, etc) are owned and managed by [SIGs](sig-governance.md). The exception to this is specific assets that may be owned by Working Groups, as outlined below. @@ -38,7 +38,7 @@ own the following types of assets: - Discussion Forum Groups Working Groups are distinct from SIGs in that they are intend to: - + - facilitate collaboration across SIGs - facilitate an exploration of a problem / solution through a group with minimal governmental overhead @@ -73,23 +73,7 @@ should eventually be reflected in a pull request on sigs.yaml: 1. Who will chair the group, and ensure it continues to meet these requirements? 1. Is diversity well-represented in the Working Group? -Once the above questions have been answered, the pull request against sigs.yaml can be created. Once the generator -is run, this will in turn create the OWNERS_ALIASES file, readme files, and the main SIGs list. The minimum -requirements for that are: - -- name -- directory -- mission statement -- chair information -- meeting information -- contact methods -- any [sig](sig-governance.md) stakeholders - -The pull request should be labeled with any SIG stakeholders and committee/steering. And since GitHub notifications -are not a reliable means to contact people, an email should be sent to the mailing lists for the stakeholder SIGs, -and the steering committee with a link to the PR. A member of the community admin team will place a /hold on it -until it has an LGTM from at least one chair from each of the stakeholder SIGs, and a simple majority of the steering -committee. +Once the above questions have been answered, complete the rest of the checklist in the [SIG / WG Lifecycle] document Once merged, the Working Group is officially chartered until it either completes its stated goal, or disbands voluntarily (e.g. due to new facts, member attrition, change in direction, etc). Working groups should strive to @@ -117,7 +101,8 @@ within the Working Group, and [sigs.yaml](/sigs.yaml) should be updated. References - [1] https://github.com/kubernetes/community/pull/1994 -- [2] https://groups.google.com/a/kubernetes.io/d/msg/steering/zEY93Swa_Ss/C0ziwjkGCQAJ +- [2] https://groups.google.com/a/kubernetes.io/d/msg/steering/zEY93Swa_Ss/C0ziwjkGCQAJ -[repository document]: https://github.com/kubernetes/community/blob/master/github-management/kubernetes-repositories.md +[SIG / WG Lifecycle]: /sig-wg-lifecycle.md +[repositories document]: https://github.com/kubernetes/community/blob/master/github-management/kubernetes-repositories.md diff --git a/governance.md b/governance.md index 8dfc32cc41f..243d7a014e7 100644 --- a/governance.md +++ b/governance.md @@ -6,18 +6,22 @@ The Kubernetes community adheres to the following principles: * Open: Kubernetes is open source. See repository guidelines and CLA, below. * Welcoming and respectful: See Code of Conduct, below. * Transparent and accessible: Work and collaboration should be done in public. See SIG governance, below. -* Merit: Ideas and contributions are accepted according to their technical merit and alignment with project objectives, [scope](https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/), and [design principles](contributors/design-proposals/architecture/principles.md). +* Merit: Ideas and contributions are accepted according to their technical merit and alignment with project objectives, [scope], and [design principles]. # Code of Conduct -The Kubernetes community abides by the [Kubernetes code of conduct](/code-of-conduct.md). Here is an excerpt: +The Kubernetes community abides by the [Kubernetes code of conduct]. Here is an excerpt: _As contributors and maintainers of this project, and in the interest of fostering an open and welcoming community, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities._ As a member of the Kubernetes project, you represent the project and your fellow contributors. We value our community tremendously and we'd like to keep cultivating a friendly and collaborative 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). +[positive experiences]. + +# Values + +[We have them!] # Community membership @@ -83,6 +87,10 @@ community. See [sig governance] for more details about current SIG operating mechanics, such as mailing lists, meeting times, etc. +More information: +[SIG Governance Requirements] +[SIG Lifecycle] - for a tactical checklist on creation and retirement + ### Subprojects Specific work efforts within SIGs are divided into **subprojects**. @@ -97,10 +105,9 @@ field technical escalations, etc. Example subprojects for a few SIGs: * SIG Network: pod networking (CNI, etc.), Service (incl. kube-proxy), Ingress, DNS, and Network policy -* SIG Apps: workload APIs, Helm, Kompose, ... * SIG Cluster Lifecycle: kubeadm, kops, kubespray, minikube, ... -Subprojects for each SIG are documented in [sigs.yaml](sigs.yaml). +Subprojects for each SIG are documented in [sigs.yaml]. ## Working Groups @@ -115,7 +122,7 @@ forming a Working Group. See [working group governance] for more details about forming and disbanding Working Groups. -Working groups are documented in [sigs.yaml](sigs.yaml). +Working groups are documented in [sigs.yaml]. ## Committees @@ -134,7 +141,7 @@ charter. Some topics have long term relevance to large groups of Kubernetes users, but do not have clear deliverables or ownership of parts of the Kubernetes code base. As such they are neither good fits for SIGs or Working Groups. -An example of such a topic might be continuous delivery to Kubernetes. +An example of such a topic might be continuous delivery to Kubernetes. Though their central goal is not a a deliverable piece of work, as contributing members of the community user groups are expected to work with SIGs @@ -142,7 +149,7 @@ to either identify friction or usability issues that need to be addressed, or to provide or improve documentation in their area of expertise. However these activities are covered under general code contributions to the relevant SIGs (e.g. SIG Docs) rather than as part of the user group. These contributions -are expected to be more incremental and ad-hoc versus the more targeted +are expected to be more incremental and ad-hoc versus the more targeted output of a user group. User groups function as a centralized resource to facilitate communication @@ -152,8 +159,8 @@ form working groups under the auspices of some SIG for such work. Likewise they shouldn't take ownership of anything in the Kubernetes process, as that is a role for SIGs. -To facilitate discoverability and engagement, -user groups are documented in [sigs.yaml](sigs.yaml) +To facilitate discoverability and engagement, +user groups are documented in [sigs.yaml] ## Cross-project Communication and Coordination @@ -192,12 +199,19 @@ Note that "Kubernetes incubator" process has been deprecated in favor of the new All contributors must sign the CNCF CLA, as described [here](CLA.md). +[positive experiences]: https://www.cncf.io/blog/2016/12/14/diversity-scholarship-series-one-software-engineers-unexpected-cloudnativecon-kubecon-experience +[sigs.yaml]: /sigs.yaml +[SIG Lifecycle]: /sig-wg-lifecycle +[We have them!]: /values.md +[Kubernetes code of conduct]: /code-of-conduct.md +[design principles]: /contributors/design-proposals/architecture/principles.md +[scope]: https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/ [community membership]: /community-membership.md -[sig governance]: /sig-governance.md +[sig governance]: /committee-steering/sig-governance.md [owners]: /community-membership.md#subproject-owner [sig charter process]: /committee-steering/governance/README.md [short template]: /committee-steering/governance/sig-governance-template-short.md [kubernetes repository guidelines]: /github-management/kubernetes-repositories.md [working group governance]: /committee-steering/governance/wg-governance.md - +[SIG Governance Requirements]: /committee-steering/governance/sig-governance-requirements.md [![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/governance.md?pixel)]() diff --git a/sig-governance.md b/sig-governance.md index 3551a1026fb..8d6f3cc2dc0 100644 --- a/sig-governance.md +++ b/sig-governance.md @@ -1,114 +1,3 @@ -# SIG Governance +This document was spread into various sections of documents in the [committee-steering] folder. This tombstone should be deleted before the 1.15 release and verified there are no dependencies. -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: - -* Create a charter and have it approved according to the [SIG charter process] -* 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 - -In addition, SIGs have the following responsibilities to SIG PM: -* identify SIG annual roadmap -* identify all SIG features in the current release -* actively track / maintain SIG features within [k/features](https://github.com/kubernetes/features) -* attend [SIG PM](/sig-pm/README.md) meetings, as needed / requested - -[SIG charter process]: /committee-steering/governance/README.md - -## SIG Roles - -Defining SIG Roles is a function of the SIG Charter. -Guidelines for drafting a SIG Charter can be found [here](/committee-steering/governance/README.md). - -## SIG creation and maintenance procedure - -### Prerequisites - -* Work with the Steering Committee to scope the SIG and get provisional approval. - Follow the [SIG charter process] to propose and obtain approval for a charter. -* 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 [@parispittman](https://github.com/parispittman) or [@castrojo](https://github.com/castrojo). New users can join at [slack.kubernetes.io](http://slack.kubernetes.io). -* 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 by emailing Paris Pittman(`parispittman@google.com`) and Jorge Castro(`jorgec@vmware.com`). You must set up a google group (see below) for the SIG leads so that all the SIG leads have the ability to reset the password if necessary. - * Read [how to use YouTube](/communication/K8sYoutubeCollaboration.md) for publishing your videos to the Kubernetes channel. - * Calendars - 1. Create a calendar on your own account. Make it public. - 2. Share it with all SIG leads with full ownership of the calendar - they can edit, rename, or even delete it. - 3. Share it with `sc1@kubernetes.io`, `sc2@kubernetes.io`, `sc3@kubernetes.io`, with full ownership. This is just in case SIG leads ever disappear. - 4. Share it with the SIG mailing list, lowest privileges. - 5. Share individual events with `cgnt364vd8s86hr2phapfjc6uk@group.calendar.google.com` to publish on the universal calendar. -* Use existing proposal and PR process (to be documented) -* Announce new SIG on kubernetes-dev@googlegroups.com -* Leads should [subscribe to the kubernetes-sig-leads mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-leads) -* 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. - -### Discussion Platforms - -Your SIG needs a place to discuss topics asynchronously. You have two options, a traditional mailing list via Google Groups, or a category on [discuss.kubernetes.io](discuss.kubernetes.io). The main difference is Groups is primarily email-based with a web UI tacked on, and Discuss is primarily a Web UI with email tacked-on. The other difference is that your SIG/WG is responsible for moderating your Google Group; with discuss you just depend on the usual community moderation. - -- Working Groups, due to their temporary nature, are strongly encouraged to consider using an existing SIG mailing list if appropriate, otherwise use a discuss category for less management overhead. -- SIGs, due to their usage of calendars, and Zoom accounts, are strongly encouraged to use a traditional mailing list. - -Choose one: - -#### Create a Category - -Post a message asking for a category in the [Site Feedback and Help](https://discuss.kubernetes.io/c/site-feedback) section and a moderator will create your category for you and provide you with a URL and mail address to post to. - -#### Creating a Google Group - -Create a Google Group at [https://groups.google.com/forum/#!creategroup](https://groups.google.com/forum/#!creategroup), following the procedure: - -Each SIG must have two discussion groups with the following settings. - -- kubernetes-sig-foo (the discussion group): - - Anyone can view content - - Anyone can join - - Anyone can post - - Only members can view the list of members -- kubernetes-sig-foo-leads (list for the leads, to be used with Zoom and Calendars) - - Only members can view group content - - Anyone can apply to join - - Anyone can post - - Only members can view the list of members -- Groups should be created as e-mail lists with at least three owners (including parispittman 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 Paris and Ihor via email address (with a suitable welcome message); in Members/All Members select Ihor and Paris and assign to an "owner role" -- Set "View topics", "Post", "Join the Group" permissions to be "Public" - -## SIG/WG Retirement - -Sometimes it might be necessary to sunset a SIG or Working Group. -SIGs/WGs may also merge with an existing SIG/WG if deemed appropriate, and would save project overhead in the long run. -Working Groups in particular are more ephemeral than SIGs, so this process should be followed when the Working Group has accomplished it's mission. - -- Retiring a SIG for is covered in the [SIG Governance](https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-governance.md) -- Retiring a Working Group is covered in [WG Governance](https://github.com/kubernetes/community/blob/master/committee-steering/governance/wg-governance.md) - -The process for closing a SIG/WG is as follows: - -- SIG Chairs agree to disband. This decision should follow the decision making process of the SIG's Charter. -- Send a email to kubernetes-dev to let people know the SIG has either closed or merged with another SIG. This will let SIG Contributor Experience know that they need to help you archive/deactivate project resources. - - Consider sending a [closing summary](https://docs.google.com/document/d/1qZcAvuWBznR_oEaPWtwm7U4JNT91m8r9YOUvInU-src/edit#heading=h.jsw0l2t0ra8) to the list. -- Work with SIG Contributor Experience to: - - Archive the mailing list/group - - Archive the leads mailing list/group - - Archive the slack channel - - Deactivate the group's Zoom license - - Move all appropriate github repositories to an appropriate archive or a repo outside of the Kubernetes org - - Each subproject a SIG owns must transfer ownership to a new SIG, outside the project, or be retired - - File an issue with kubernetes/org if multiple repos that need to be retired - - Coordinate with SIG Testing on the following topics (if necessary) - - Retire or transfer any test-infra jobs owned by the SIG - - Retire or transfer any testgrid dashboards owned by the SIG - - Clean up and remove all GitHub teams that refer to that SIG/WG - - Migrate/Remove/Deprecate any SIG/WG labels in [labels.yaml](https://git.k8s.io/test-infra/label_sync/labels.yaml) - - Ensure that the YouTube Collaboration links are removed -- Remove SIG Calendar and events from the community calendar -- Update `sigs.yaml` to reflect the removal of the SIG/WG - - Move the existing SIG directory into the [archive](/archive) in kubernetes/community \ No newline at end of file +[committee-steering]: /committee-steering diff --git a/sig-wg-lifecycle.md b/sig-wg-lifecycle.md new file mode 100644 index 00000000000..a57adaddc55 --- /dev/null +++ b/sig-wg-lifecycle.md @@ -0,0 +1,117 @@ +# SUMMARY: + +This document covers everything you need to know about the creation and retirement (“lifecycle”) of a special interest or working group within the Kubernetes project. General project governance information can be found in the [steering committee repo]. +Out of scope for this document: [subproject] creation. + +[Creation] +[Retirement] + +# [Creation] +## Prerequisites for a SIG +- [ ] Read [sig-governance.md] +- [ ] Send an email to the Steering Committee to scope the SIG and get provisional approval. +- [ ] Look at the checklist below for processes and tips that you will need to do while this is going on. It's best to collect this information upfront so you have a smoother process to launch +- [ ] Follow the [SIG charter process] to propose and obtain approval for a charter +- [ ] Announce new SIG on kubernetes-dev@googlegroups.com + +## Prerequisites for a WG +- [ ] Read [wg-governance.md] +- [ ] Send email to [kubernetes-dev@googlegroups.com] titled "WG-Creation-Request: WG Foo" with some of the questions answered from wg-goverance.md and wait for community discourse; ask for SIG sponsorship +- [ ] Do the first checklist item in the #GitHub section below and add a row to the WG section: + - [ ] Label with committee/steering and wait for a simple majority + - [ ] Also add sponsoring SIG Chair/Tech Leads as approvers; you'll get this from the community email above + - [ ] Place a `/hold` on it until the members that need to review have; a contributor experience member will do this for you if they don't see one already +- [ ] Send an email to the stakeholder SIG mailing lists and steering committee with the sigs.yaml pull request + +## GitHub: +- [ ] Submit a PR that will add rows to [sigs.yaml] using the [generator doc]; this will create README files and OWNERS_ALIASES files for your new directory in `kubernetes/community` +- You’ll need: + - SIG Name + - Directory URL + - Mission Statement + - Chair Information + - Meeting Information + - Contact Methods + - Any SIG Stakeholders + - Any Subproject Stakeholders +- [ ] Add SIG-related docs like charter.md, schedules, roadmaps, etc. to your new kubernetes/community/SIG-foo directory once the above PR is merged. +- [ ] File a [Kubernetes/Org] Issue for a label; read about our [GitHub management] services + +## Communicate: +Each one of these has a linked canonical source guideline from set up to moderation and your role and responsibilities for each. We are all responsible for enforcing our [code of conduct]. +- [ ] Read [moderation.md] and understand your role in keeping our community safe +- [ ] Create your mailing lists - One for your members and another for your chairs/leads +- Either [GoogleGroups] OR [discuss.kubernetes.io] +- Example: kubernetes-[sig/wg]-foo@googlegroups.com and kubernetes-[sig/wg]-foo-leads@googlegroups.com +- The chairs/leads email will be used for activation of certain platforms (eg zoom) +- [ ] Request a slack channel. [slack-guidelines.md] +- [ ] Request a YouTube playlist link [k8syoutubecollaboration.md] +- [ ] Request a zoom account [zoom-guidelines.md] + +## Engage: +...as a chair/tech lead with other chairs/tech leads +- [ ] Subscribe to the kubernetes-sig-leads@googlegroups.com group +- [ ] Join the #chairs-and-techleads slack channel + +...with the community as part of [sig-governance.md] +- [ ] Get on the schedule for [Thursday community updates]; info at the top of the agenda +- [ ] Schedule your weekly/biweekly/at least every 3 weeks update meetings [TODO - THIS MAY CHANGE ONCE WE EXPLORE GSUITE] +- Use a poll service like doodle.com that will help you get a good pulse on your community and when they can meet +- This calendar creation process will allow all of your leads to edit SIG/WG Meetings. This is important as we all change jobs, email addresses, and take breaks from the project. Shared calendars will also provide consistenacy with contributors looking for your subproject meetings, office hours, and anything else that the SIG/WGs contributors should know about. +- Create a shared calendar on your own account. [example with google calendars: https://support.google.com/calendar/answer/37095?hl=en] Note: If you are creating from a corporate account like Google, it will not be public. Do a test first and ask a friend that doesn't work at your company. + - Name it “SIG/WG Foo [Time Cadence] Meetings” + - Sharing / access settings: Make it public + - Share it with full rights ("make changes and manage sharing”) with: cgnt364vd8s86hr2phapfjc6uk@group.calendar.google.com (Why this weird address? This is a public calendar that will be used to populate calendars on various sites) + - Your SIG/WG lead email distro (see second bullet in Communicate) + - Share it with lowest level of shown details (“see all event details”): + - SIG/WG membership distro (example: kubernetes-sig-foo@) + +# [Retirement] (merging or disbandment) +Sometimes it might be necessary to sunset a SIG or Working Group. SIGs/WGs may also merge with an existing SIG/WG if deemed appropriate, and would save project overhead in the long run. Working Groups in particular are more ephemeral than SIGs, so this process should be followed when the Working Group has accomplished it's mission. + +## Prerequisites for SIG Retirement +- [ ] SIG’s retirement decision follows the decision making and communication processes as outlined in their charter + +## Prerequisites for WG Retirement +- [ ] Have completed the mission of the WG or have another reason as outlined in [wg-governance.md] + +## Steps: +- [ ] Send an email to kubernetes-dev@googlegroups.com and community@kubernetes.io alerting the community of your intentions to disband or merge. [example] +- This kicks off the process for Contributor Experience’s community managers who will reach out and set an issue against `kubernetes/community` with exact next steps covered below. We can help walk through this when you get there. Most of this is covered in the same creation communication docs as above. +- [ ] Archive the member and lead/chair mailing lists/[GoogleGroups] +- [ ] Check the [slack-guidelines.md] for latest process on archiving the slack channel +- [ ] Deactivate the zoom license +- [ ] Delete your shared SIG/WG calendar +- [ ] Ensure that the [k8syoutubecollaboration.md] links are removed and you've uploaded all SIG/WG meetings to date +- [ ] Move the existing SIG directory into the archive in `kubernetes/community` +- [ ] GitHub archiving/removing/other transactions: + - [ ] Move all appropriate github repositories to an appropriate archive or a repo outside of the Kubernetes org + - [ ] Each subproject a SIG owns must transfer ownership to a new SIG, outside the project, or be retired + - [ ] File an issue with kubernetes/org if there are multiple repos + - [ ] Retire or transfer any test-infra jobs or testgrid dashboards, if applicable, owned by the SIG. Work with SIG-Testing on this. + - [ ] Migrate/Remove/Deprecate any SIG/WG labels in labels.yaml + - [ ] Remove or rename any GitHub teams that refer to the SIG + - [ ] Update sigs.yaml to remove or rename + + +[steering committee repo]: https://github.com/kubernetes/steering +[discuss.kubernetes.io]: https://discuss.kubernetes.io +[subproject]: /governance.md#subprojects +[Creation]: (#Creation) +[Retirement]: (#Retirement) +[sig-governance.md]: /committee-steering/governance/sig-governance.md +[SIG charter process]: /committee-steering/governance +[wg-governance.md]: /committee-steering/governance/wg-governance.md +[sigs.yaml]: /sigs.yaml +[generator doc]: /generator +[Kubernetes/Org]: https://github.com/kubernetes/org/issues/new/choose +[GitHub management]: /github-management +[code of conduct]: /code-of-conduct.md +[moderation.md]: /communication/moderation.md +[GoogleGroups]: /communication/mailing-list-guidelines.md +[slack-guidelines.md]: /communication/slack-guidelines.md +[k8syoutubecollaboration.md]: /communication/K8sYoutubeCollaboration.md +[zoom-guidelines.md]: /communication/zoom-guidelines.md +[discuss-guidelines.md]: /communication/discuss-guidelines.md +[Thursday community updates]: /events/community-meeting.md +[example]: https://docs.google.com/document/d/1qZcAvuWBznR_oEaPWtwm7U4JNT91m8r9YOUvInU-src/edit#heading=h.jsw0l2t0ra8