Merge pull request #5845 from nimbinatus/2021-community-meeting-update

Update community meeting doc with new information

Author: k8s-ci-robot

events/community-meeting.md

@@ -18,7 +18,8 @@ See it on the web at [calendar.google.com], or paste this [iCal url] into any
 [iCal client]. Do NOT copy the meetings over to your personal calendar, you will
 miss meeting updates. Instead use your client's calendaring feature to say you
 are attending the meeting so that any changes made to meetings will be reflected
-on your personal calendar. 
+on your personal calendar. Note that we no longer are sending out meeting invites
+to the mailing list due to limitations of public Google Groups.
 
 All meetings are archived on the [YouTube Channel].
 
@@ -30,10 +31,11 @@ Quick links:
 
 ## Purpose
 
-The Kubernetes community meeting is intended to provide a holistic overview of
-community activities, critical release information, and governance updates. It
-also provides a forum for discussion of project-level concerns that might need a
-wider audience than a single special interest group (SIG).
+The Kubernetes community meeting is intended to provide a contributor-wide forum
+for discussion of various community activities, critical release information, 
+Kubernetes Enhancement Proposals (KEPs), and governance updates. The focus of
+discussion is on project-level concerns that might need a wider audience than a
+single special interest group (SIG).
 
 
 ## Notetaker(s)
@@ -48,43 +50,47 @@ the beginning of the call.
 ## Meeting Agenda
 
 If you have a topic you'd like to present or would like to see discussed,
-please propose a specific date on the [Kubernetes Community Meeting Agenda][agenda].
+please propose that topic on the [Kubernetes Community Meeting Agenda][agenda].
 
 General speaking the meeting is structured as follows:
 
 - Introduction by Host (~3 minutes)
-- Community Demo (~10 minutes, Optional)
+- Announcements
+  - Any community announcements that are not discussion topics should go here
 - Release Updates (~10 minutes, Optional, release manager's discretion)
   - Development Release
   - Stable Release and point releases
   - Older stable releases and point releases
-- Contributor Tip of the Week (~2 minutes, Optional)
-  - These can be a variety of topics, including [devstats graphs]
-- Community Group Updates
-  - Three SIGs per meeting, 10 minutes per SIG, if time allows 4 SIGs may present. This includes committees and working groups. 
-- Announcements (~5 minutes)
-  - Any other community announcements should go here
-  - Shoutouts, an aggregation of thanks from community members to other
-    contributors via the `#shoutouts` channel 
+- Topics for discussion
+- KEP Callouts
+- Shoutouts, an aggregation of thanks from community members to other
+  contributors via the `#shoutouts` channel 
 
+## Topics for Discussion
 
-## Demos
+Contributors can suggest topics for discussion to the host via the agenda doc.
+Any topic should include a person to start the conversation or provide further
+context. Examples for such topics include the following ideas:
 
-The first 10 minutes of a meeting is dedicated to demonstrations from the
-community. These demos are noted at the top of the community document. There is
-a hard stop of the demo at 10 minutes, with up to 5 more minutes for questions.
-Feel free to add your demo request to the bottom of the list, then one of the
-organizers will get back to you to schedule an exact date. Demo submissions MUST 
-follow the requirements listed below: 
+- Decisions where input is being sought from other SIGs
+- Topics that could affect other SIGs
+- Discussions around getting contributions for a particular project
+
+## KEP Callouts
 
+If a KEP has a significant impact to other SIGs or the project as a whole, or
+if the people behind a KEP would like to have more discussion with the rest of
+the contributors group about that KEP, add the KEP to the agenda so we can
+discuss it.
 
-### Requirements
+## A Word on Demos
 
-This meeting has a large number of attendees. Out of respect for their time, we
-ask that you be fully prepared for your demo. Make sure slides are clear if
-applicable, and the link to them is posted in the meeting agenda. Also, if you 
-are doing a live coding demo, please make sure it has a reasonable chance of
-completing within the allotted time box.
+If a discussion or a KEP requires demoing a specific feature or functionality
+for the group, please remember this meeting has a large number of attendees.
+Out of respect for their time, we ask that you be fully prepared for your demo.
+Make sure slides are clear if applicable, and the link to them is posted in the
+meeting agenda. Also, if you are doing a live coding demo, please make sure it
+has a reasonable chance of completing within the allotted time box.
 
 - Demos must be about a core component of Kubernetes or a related project that
   is owned by a SIG. For projects in the Kubernetes ecosystem, you can sign up
@@ -93,8 +99,6 @@ completing within the allotted time box.
   and screensharing capabilities with the hosts. If you cannot make and keep this
   commitment, you will not be allowed to proceed with your demo until such time
   you can.
-- You also required to commit to being available the week before your demo date
-  in case there is an issue with that week's demo.
 - The use of a headset or other high-quality audio equipment is strongly
   encouraged. Typing on a laptop while using the system microphone is distracting,
   so please insulate your microphone from key noises.
@@ -104,43 +108,6 @@ completing within the allotted time box.
   enthusiastic support, the community team will help schedule a continuation.
 
 
-## Community Group Updates
-
-SIGs and other community groups like committees and WGs (Working Groups) will give an update at least once a year.
-The update should mention:
-
-- Topics where input is being sought from other SIGs
-- Topics that could affect other SIGs
-- Currently active themes and goals in the SIG
-  - Broad description of future themes and goals if possible
-- Status of any notable features that are transitioning across the spectrum of
-  incubation, alpha, beta, stable/GA, or are being deprecated
-- New or deprecated subprojects
-- Leadership position changes or updates
-- Charter status and updates, if any
-- How people can contribute, areas where help is needed
-- Any pending Kubernetes Enhancement Proposals (KEPs) or general big ideas that
-  might warrant outside input
-- Prior 1.X.Y release patches in flight status
-- Current 1.X release targeted feature status
-- Rescheduling an update can happen, but is strongly discouraged as the schedule
-  is done with as much lead time as possible to allow SIGs time to plan ahead
-  - SIGs should consider asking someone who is not a chair or lead to give this
-    update as a mentorship/growth opportunity to newer members
-  - There is a [pregenerated slide template] that you can use for your status
-  - The update belongs entirely to the SIG, there will be periods when "boring"
-    work happens and the SIG might want to not give a status update, instead
-    consider a shorter update that at least lets the community know if you're in
-    a quiet period. Informing the community that you've been clearing out the
-    backlog in a 1 minute status is much better than not having a status report
-    because you're concerned about not filling out the template in full. Just
-    cut out what doesn't apply to you. 
-
-Since you only usually have ~10 minutes generally speaking if something is
-internal only to your SIG and doesn't affect others it doesn't need to be
-mentioned, people can always attend your SIG meeting for the details.
-
-
 ## Archives
 
 The document gets slow as we add notes, so it is archived regularly into the