add sig governance doc
This commit is contained in:
parent
ab32d77a39
commit
577c94feea
|
@ -35,7 +35,7 @@ The weekly community meeting provides an opportunity for the different SIGs, WGs
|
|||
|
||||
## Special Interest Groups (SIG) and Working Groups
|
||||
|
||||
Much of the community activity is organized into a community meeting, numerous SIGs and time bounded WGs. Each of those groups operates a little differently which is reflected in how they capture notes, examples, and other information. Each groups material is in its subdirectory in this project.
|
||||
Much of the community activity is organized into a community meeting, numerous SIGs and time bounded WGs. SIGs follow these [guidelines](governance.md) although each of these groups may operate a little differently depending on their needs and workflow. Each groups material is in its subdirectory in this project.
|
||||
|
||||
The community meeting calendar is available as an [iCal to subscribe to] (https://calendar.google.com/calendar/ical/cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com/public/basic.ics) (simply copy and paste the url into any calendar product that supports the iCal format) or [html to view] (https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles).
|
||||
|
||||
|
|
|
@ -0,0 +1,12 @@
|
|||
# Kubernetes SIG Governance
|
||||
|
||||
In order to standardize Special Interest Group efforts, create maximum transparency, and route contributors to the appropriate SIG, SIGs should follow the guidelines stated below:
|
||||
|
||||
* Meet regularly, at least for 30 minutes every 3 weeks, except November and December
|
||||
* Keep up-to-date meeting notes, linked from the SIG's page in the community repo
|
||||
* Announce meeting agenda and minutes after each meeting, on their SIG mailing list
|
||||
* Record SIG meeting and make it publicly available
|
||||
* Ensure the SIG's mailing list and slack channel are archived
|
||||
* Report activity in the weekly community meeting at least once every 6 weeks
|
||||
* 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 code and tests explicitly owned and supported by the SIG, including issue triage, PR reviews, test-failure response, bug fixes, etc.
|
Loading…
Reference in New Issue