reducing meetingpolicy

This commit is contained in:
Paris Pittman 2020-06-21 21:34:56 -07:00
parent fd5df0deed
commit e39d805f00
3 changed files with 18 additions and 26 deletions

View File

@ -13,20 +13,13 @@ December
- Keep up-to-date meeting notes, linked from the SIG's page in the community - Keep up-to-date meeting notes, linked from the SIG's page in the community
repo repo
- Record meetings and make them publicly available on the - 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. 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 - Participate in release planning meetings and retrospectives, and burndown
meetings, as needed meetings, as needed
- Ensure related work happens in a project-owned github org and repository, with - 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 groups like SIGs and the Steering Committee but *MAY* delegate the actual
communication and creation of content to other contributors where communication and creation of content to other contributors where
appropriate 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 - *MUST* present yearly [annual report] for the group but *SHOULD* get help with
curation from other SIG participants 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 [#tech-lead]: #Tech-Lead
[Google group]: https://groups.google.com/forum/#!forum/kubernetes-sig-config [Google group]: https://groups.google.com/forum/#!forum/kubernetes-sig-config
[dashboard]: https://testgrid.k8s.io/ [dashboard]: https://testgrid.k8s.io/
[monthly community meeting]: /events/community-meeting.md

View File

@ -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 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 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... ## Is it a Working Group? Yes, if...
- It does not own any code - It does not own any code
@ -112,4 +112,4 @@ References
[SIG / WG Lifecycle]: /sig-wg-lifecycle.md [SIG / WG Lifecycle]: /sig-wg-lifecycle.md
[repositories document]: https://github.com/kubernetes/community/blob/master/github-management/kubernetes-repositories.md [repositories document]: https://github.com/kubernetes/community/blob/master/github-management/kubernetes-repositories.md
[community members]: /community-membership.md [community members]: /community-membership.md
[group health check]: ./annual-reports.md [annual report]: ./annual-reports.md

View File

@ -60,8 +60,8 @@ General speaking the meeting is structured as follows:
- Older stable releases and point releases - Older stable releases and point releases
- Contributor Tip of the Week (~2 minutes, Optional) - Contributor Tip of the Week (~2 minutes, Optional)
- These can be a variety of topics, including [devstats graphs] - 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) - Announcements (~5 minutes)
- Any other community announcements should go here - Any other community announcements should go here
- Shoutouts, an aggregation of thanks from community members to other - 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. 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 where input is being sought from other SIGs
- Topics that could affect other SIGs - Topics that could affect other SIGs