diff options
| author | parispittman <parispittman@google.com> | 2019-03-20 02:29:14 -0700 |
|---|---|---|
| committer | parispittman <parispittman@google.com> | 2019-03-20 02:36:36 -0700 |
| commit | d7ca367ed1ba14442e107eb82df1960064399c49 (patch) | |
| tree | aa822bd64e3f7eb979d8da099a16054e4c1327b6 | |
| parent | 32b54fb1b7d0dfd4eccd83dc9f7b2f2aecf9e20e (diff) | |
calendar clean up
| -rw-r--r-- | communication/calendar-guidelines.md | 1 | ||||
| -rw-r--r-- | sig-creation-procedure.md | 2 | ||||
| -rw-r--r-- | sig-wg-lifecycle.md | 14 |
3 files changed, 9 insertions, 8 deletions
diff --git a/communication/calendar-guidelines.md b/communication/calendar-guidelines.md index 67721396..45fa80db 100644 --- a/communication/calendar-guidelines.md +++ b/communication/calendar-guidelines.md @@ -35,7 +35,6 @@ Best advice here is to recreate one. It won't hurt to recreate a meeting invite Make sure your work account doesn't have restrictions for public viewing of calendar invites you create. Test this with other contributors before sending it to mailing lists if you are unsure. This would be for both the calendar entry itself and the shared calendar if you are the chair creating it. If this is the case, use a personal account (ex: gmail). - #### If you are viewing calendar events: TODO diff --git a/sig-creation-procedure.md b/sig-creation-procedure.md index a9c04bb6..e2ee859b 100644 --- a/sig-creation-procedure.md +++ b/sig-creation-procedure.md @@ -1,3 +1,3 @@ -## SIG creation procedure +## Special Interest and Working Group creation procedure Moved to [sig-wg-lifecycle](/sig-wg-lifecycle.md) diff --git a/sig-wg-lifecycle.md b/sig-wg-lifecycle.md index 0681fb56..58dca09c 100644 --- a/sig-wg-lifecycle.md +++ b/sig-wg-lifecycle.md @@ -1,14 +1,15 @@ -# SUMMARY: +## 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] +## [Creation] ### Prerequisites for a SIG - [ ] Read [sig-governance.md] -- [ ] Send an email to the Steering Committee(<steering@kubernetes.io>) to scope -the SIG and get provisional approval. +- [ ] Send an email to the Steering Committee <steering@kubernetes.io> 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 @@ -54,9 +55,10 @@ Each one of these has a linked canonical source guideline from set up to moderat ...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/triweekly [update meetings] and create your SIG/WG shared calendar. +- [ ] Create a shared calendar and schedule your weekly/biweekly/triweekly weeks [update meetings] +- 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 consistency with contributors looking for your subproject meetings, office hours, and anything else that the SIG/WGs contributors should know about. -## [Retirement] +## [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. |