From e39d805f00df4169e2d617cd07907127ff17c33c Mon Sep 17 00:00:00 2001 From: Paris Pittman Date: Sun, 21 Jun 2020 21:34:56 -0700 Subject: [PATCH] reducing meetingpolicy --- .../governance/sig-governance.md | 24 +++++++------------ .../governance/wg-governance.md | 10 ++++---- events/community-meeting.md | 10 ++++---- 3 files changed, 18 insertions(+), 26 deletions(-) diff --git a/committee-steering/governance/sig-governance.md b/committee-steering/governance/sig-governance.md index 43b10d8ee..424b86f11 100644 --- a/committee-steering/governance/sig-governance.md +++ b/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] -- 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 -to the kubernetes-dev mailing list as this is the list the community depends on -for SIG updates. - - Each SIG is assigned an update during the monthly community meeting - throughout the year. The meeting host will publish the notes to the +[Kubernetes Community YouTube playlist] +- Report activity with the community via the kubernetes-dev@ mailing list at +least once a year. + - Each SIG is assigned an update during the [monthly community meeting] + throughout the year from sig-contributor-experience. 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 - 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. + - This is separate from the [annual report]. - 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 -to kubernetes-dev@googlegroups.com mailing list and twice a year presenting at -the monthly community meeting +- *MUST* provide updates through 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 diff --git a/committee-steering/governance/wg-governance.md b/committee-steering/governance/wg-governance.md index 293cbc549..10d9ae65b 100644 --- a/committee-steering/governance/wg-governance.md +++ b/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 -, at minimum, to their respective sponsoring SIG Chairs. SIG Chairs are -responsible for presenting the Steering Committee with the yearly [group health -check]. +(see Creation Process) in sigs.yaml. + +Updates +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 diff --git a/events/community-meeting.md b/events/community-meeting.md index 3716ab692..9606f05be 100644 --- a/events/community-meeting.md +++ b/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 - - Three SIGs per meeting, 10 minutes per SIG, if time allows 4 SIGs may present +- 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 @@ -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]. -The SIG Update should mention: +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