Merge pull request #3476 from parispittman/calendarupdates

calendar doc updates

communication/calendar-guidelines.md

@@ -0,0 +1,47 @@
+Project meetings are a life line of the Kubernetes project but calendaring is hard. Use this guide to help you navigate though the trickiness of calendars and learn from our fails.
+PR in your favorite tip that can help others or if you have an example other than gmail.
+
+### "I'm a chair for a SIG or WG and need to set up a meeting":
+//This may change with the addition of a gsuite but this is the current best state   
+*This calendar creation process will allow all of your leads to edit SIG/WG Meetings.*   
+
+1- Use a poll service like doodle.com that will help you get a good pulse on your community and when they can meet  
+2- Create a new shared calendar in the meantime as 'SIG Foo Shared Calendar'   
+  This is important as we all change jobs, email addresses, and take breaks from the project. It will allow you to transfer the ownership to the shared calendar and then the rest of your team can edit it at anytime. [example of a shared calendar with google calendars: https://support.google.com/calendar/answer/37095?hl=en]   
+3- Access permissions and sharing:
+* Make all event details publicly accessible. Do this from an account that won't have problems with sharing and posting information publicly. This is important and you should test this first if you are not using a personal account like gmail. //TODO add a pic
+* Share it with full rights ("make changes and manage sharing” on gmail) to: your SIG/WG lead mailing list and community@kubernetes.io. With great power comes great responsibility, let your other chairs know they can accidentally delete a calendar if they are trying to delete it from theirs.
+* Lastly, share with view permissions only (“see all event details”) to: your SIG/WG mailing list   
+
+4- Once you have a time cadence settled from your members, create a calendar invite with the shared calendar as the owner. //TODO add a pic  
+5- Name it “SIG/WG Foo [Time Cadence ex: Biweekly] Meetings”  
+6- Sharing: Public (note: most gmail will have a 'default visibility' setting that automatically is turned on. Default visibility is usually not public and will need to manually scroll to public)  
+7- Include your meeting notes, zoom information, and any other pertinent information that you want your SIG/WG to know.   
+8- Invite your SIG/WG mailing list and cgnt364vd8s86hr2phapfjc6uk@group.calendar.google.com (Why this weird address? This is a public calendar that will be used to populate calendars on various sites)  
+/end
+
+### "I'm a chair and the person that created the meeting is either no longer with the project or no longer at employer that holds the invite"
+If you have a shared calendar with edit rights to other chairs, leads, etc., they can edit the invite and migate the situation. Also check with folks on the community@kubernetes.io team.  
+
+If there is no shared calendar and still one owner, ask the person to transfer it to a shared calendar or you'll need to recreate one.
+Best advice here is to recreate one. It won't hurt to recreate a meeting invite every few months anyway to refresh the group.
+
+### "I'm a contributor and want to see one of/all of the SIG calendar(s)."
+* All of the SIGs and WGs have meeting agendas with detailed information at the top. You can get this information from the SIG/WG list. Join their mailing list for the most up to date calendar invites. Chairs will always invite the entire mailing list to events.
+* To see all of the meetings on one calendar: https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America%2FLos_Angeles
+
+## Permissions Tips
+#### If you are creating calendar events:
+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
+
+## Misc Tips
+Don't copy calendars if you can help it. Copying the calendar onto your calendar will prevent you from getting updates like a canceled meeting.  
+Always join a SIG/WG mailing list thats of interest and our main contributor list - kubernetes-dev@googlegroups.com. Accept the invite from the sender and you'll have the updates.   
+
+If a chair is offboarding, ask them to transfer the ownership so there isn't a ghost calendar invite on your members calendar.   
+
+//TODO - tip about timezones

sig-creation-procedure.md

@@ -1,3 +1,3 @@
-## SIG creation procedure
+## Special Interest and Working Group creation procedure
 
-Moved to [sig governance](/sig-governance.md#sig-creation-procedure)
+Moved to [sig-wg-lifecycle](/sig-wg-lifecycle.md)

sig-wg-lifecycle.md

@@ -1,4 +1,4 @@
-# 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.
@@ -6,15 +6,15 @@ Out of scope for this document: [subproject] creation.
 [Creation]
 [Retirement]
 
-# [Creation]
-## Prerequisites for a SIG
+## [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.
 - [ ] 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
+### 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:
@@ -23,7 +23,7 @@ Out of scope for this document: [subproject] creation.
   - [ ] 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:
+### 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
@@ -37,7 +37,7 @@ Out of scope for this document: [subproject] creation.
 - [ ] 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:
+### 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
@@ -48,34 +48,27 @@ Each one of these has a linked canonical source guideline from set up to moderat
 - [ ] Request a YouTube playlist link [youtube-guidelines.md]
 - [ ] Request a zoom account [zoom-guidelines.md]
 
-## Engage:
+### 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@)
+- [ ] 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] (merging or disbandment)
+## [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
+### Prerequisites for SIG Retirement
 - [ ] SIG’s retirement decision follows the decision making and communication processes as outlined in their charter
 
-## Prerequisites for WG Retirement
+### Prerequisites for WG Retirement
 - [ ] Have completed the mission of the WG or have another reason as outlined in [wg-governance.md]
 
-## Steps:
+### 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]
@@ -115,3 +108,4 @@ Sometimes it might be necessary to sunset a SIG or Working Group. SIGs/WGs may a
 [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
+[update meetings]: /communication/calendar-guidelines.md