reducing meetingpolicy

committee-steering/governance/sig-governance.md

@@ -13,20 +13,13 @@ 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 the
-[Kubernetes Community YouTube playlist]
+[Kubernetes Community YouTube playlist]  
-- Report activity with the community via the kubernetes-dev mailing list at
+- Report activity with the community via the kubernetes-dev@ mailing list at
-least once a quarter. Whichever format the SIG uses should _always_ be reported
+least once a year. 
-to the kubernetes-dev mailing list as this is the list the community depends on
+  - Each SIG is assigned an update during the [monthly community meeting]
-for SIG updates.  
+  throughout the year from sig-contributor-experience. The meeting host will publish the notes to the
-  - Each SIG is assigned an update during the monthly community meeting
-  throughout the year. The meeting host will publish the notes to the
   kubernetes-dev mailing list with the update.  
-  - Due to limited opportunities (twice a year) at the community meeting to
+  - This is separate from the [annual report]. 
-  present, your SIG will need to figure out two other options to deliver on SIG
-  updates to meet the quarterly reporting requirement:
-    a. During KubeCon + CloudNativeCon or  
-    b. A presentation or summary update sent to the kubernetes-dev
-  mailing list.
 - 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
@@ -122,9 +115,7 @@ Subproject contributors (as applicable).
  groups like SIGs and the Steering Committee but *MAY* delegate the actual
  communication and creation of content to other contributors where
  appropriate  
-- *MUST* provide quarterly updates through our community channels: twice a year
+- *MUST* provide updates through the [monthly community meeting]
-to kubernetes-dev@googlegroups.com mailing list and twice a year presenting at
-the monthly community meeting  
 - *MUST* present yearly [annual report] for the group but *SHOULD* get help with
 curation from other SIG participants
 
@@ -249,3 +240,4 @@ Issues impacting multiple subprojects in the SIG should be resolved by either:
 [#tech-lead]: #Tech-Lead
 [Google group]: https://groups.google.com/forum/#!forum/kubernetes-sig-config
 [dashboard]: https://testgrid.k8s.io/
+[monthly community meeting]: /events/community-meeting.md

committee-steering/governance/wg-governance.md

@@ -44,10 +44,10 @@ Working Groups are distinct from SIGs in that they are intend to:
 
 Working Groups will typically have stake holders whose participation is in the
 context of one or more SIGs.  These SIGs should be documented as stake holders of the Working Group
-(see Creation Process). Working Group Chairs are required to give yearly updates
+(see Creation Process) in sigs.yaml. 
-, at minimum, to their respective sponsoring SIG Chairs. SIG Chairs are
+
-responsible for presenting the Steering Committee with the yearly [group health
+Updates  
-check].
+Working Group Organizers are required to give updates to their respective sponsoring SIG Chairs. Organizers are responsible for presenting the Steering Committee with the yearly [annual report].
 
 ## Is it a Working Group? Yes, if...
 - It does not own any code
@@ -112,4 +112,4 @@ References
 [SIG / WG Lifecycle]: /sig-wg-lifecycle.md
 [repositories document]: https://github.com/kubernetes/community/blob/master/github-management/kubernetes-repositories.md
 [community members]: /community-membership.md
-[group health check]: ./annual-reports.md
+[annual report]: ./annual-reports.md

events/community-meeting.md

@@ -60,8 +60,8 @@ General speaking the meeting is structured as follows:
   - Older stable releases and point releases
 - Contributor Tip of the Week (~2 minutes, Optional)
   - These can be a variety of topics, including [devstats graphs]
-- SIG Updates
+- Community Group Updates
-  - Three SIGs per meeting, 10 minutes per SIG, if time allows 4 SIGs may present 
+  - 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
@@ -104,10 +104,10 @@ completing within the allotted time box.
   enthusiastic support, the community team will help schedule a continuation.
 
 
-## SIG Updates
+## Community Group Updates
 
-SIGs will give a community update at least once per release cycle per the [schedule].
+SIGs and other community groups like committees and WGs (Working Groups) will give an update at least once a year.
-The SIG Update should mention:
+The update should mention:
 
 - Topics where input is being sought from other SIGs
 - Topics that could affect other SIGs