From b801fe8f2c54001b776c54a91787326eae783194 Mon Sep 17 00:00:00 2001 From: parispittman Date: Mon, 6 Apr 2020 10:51:42 -0700 Subject: [PATCH] adding community group health check --- .../governance/annual-reports.md | 134 ++++++++++++++++++ .../governance/sig-governance.md | 3 + .../governance/ug-governance.md | 5 + .../governance/wg-governance.md | 9 +- governance.md | 17 ++- 5 files changed, 163 insertions(+), 5 deletions(-) create mode 100644 committee-steering/governance/annual-reports.md diff --git a/committee-steering/governance/annual-reports.md b/committee-steering/governance/annual-reports.md new file mode 100644 index 00000000000..a7f43e78d1e --- /dev/null +++ b/committee-steering/governance/annual-reports.md @@ -0,0 +1,134 @@ +# Kubernetes Community Group Annual Reports + +This document outlines the bootstrap process for an annual reporting and +communication structure for Special Interest Groups (SIGs), Working Groups (WGs) +, User Groups (UGs), and Committees +All policy updates will be in their respective [SIG], [WG], and [UG] + governance docs as well as the general [governance] guidance. + +## Goals +- Paint a complete project health picture for all of our community groups +- Create a feedback loop between Chairs, Tech Leads, Subproject Owners, WG and +UG Organizers, the community groups at large, and the Steering +Committee to move the project forward +- Encourage dialogue about the wellbeing of the projects contributors and offer +suggested guidance and coaching +- Promote healthy, active, engaged community groups +- Understand and have context before issues arise and celebrate wins where they +should be highlighted +- Help reshape project priorities at a high level + +## Reporting Process + +Chairs and Organizers are responsible for compiling a yearly public report but +may be completed with the help of members of that group. Chairs and Organizers +ensure that reports are complete, accurate, and submitted to the Steering +Committee. + +### 2020: +Due to playing catch up with 40 community groups, we will have a slightly +modified timeline bootstrap process this year and then will follow the process +outlined in 2021. This means that Chairs will be reporting twice in n months and +not a year. A yearly cadence will be followed post 2021. + +TODO outline time line for 2020 + +### 2021 and on: +1. Chairs create one report and send it to steering-private@kubernetes.io for +review; reports are due at the end of February and will use a template with the +questions listed below TODO: to be created +2. Steering Committee will assign one member as a liaison to each community group before the +reports are submitted so there is an established point of contact for any help or +guidance needed +3. The March SIG Chairs and Tech Leads meetings will be used as follow up for +the community groups that have questions from/to Steering and report +retrospectives +4. Steering will schedule private meetings to follow up on anything denoted as +a private matter on the report; reports are not made public until all private +comments have been addressed +5. Once reviewed and follow ups are completed, Steering will ask the chair(s) +of the group to submit a pull request to that groups documentation in the +community repo. +6. The Steering Committee liaison will work directly with groups that have follow +up items and update Steering during regular monthly meetings + +### Tips for Chairs and Working Group Organizers: +- Work together with your groups roles and community members to complete; +suggestion: schedule a dedicated meeting to go over project health with the +goal of compiling this report +- All questions are require a response. If something isn't applicable, n/a is +fine. +- This report will be considered private until Steering reviews and follows up +with next steps of a pull request; however, please include any and all explicit +private matters between [private] tags [/private]. We will absolutely not +release information between private tags. If Chairs and/or Organizers would like + to do the *Your Role* section individually and privately, please send to us at + steering-private@kubernetes.io +- [insert a google doc template here for the questions] //TODO + +## Questions for report: + +//A copy of these questions will be provided in a template + +#### You and your role: +When did you become a chair and do you enjoy the role? +What do you find challenging? +Do you have goals for the group? +Do you want to continue or find a replacement? If you feel that you aren’t ready + to pass the baton, what would you like to accomplish before you do? +Is there something we can provide that would better support you? +Do you have feedback for Steering? Suggestions for what we should work on? + +#### Special Interest Groups: +- How are you doing with operational tasks in [yourgroup]-governance.md? +- Is your README accurate? have a CONTRIBUTING.md file? +- All subprojects correctly mapped and listed in sigs.yaml? +- How does the group get updates, reports, or feedback from subprojects? Are +there any that are being retired? +- Are OWNERs files up to date? +- Tell us about your meetings: large/small, active/quiet? learnings? up to date +on the Kubernetes community YouTube under a community group playlist? Meeting +notes up to date? +- When was your last public community update? (provide link) + +##### Membership +- Are all listed SIG leaders (chairs, tech leads, and subproject owners) active? +- How do you measure membership? By mailing list members, OWNERs, or something +else? +- How does the group measure reviewer and approver bandwidth? Do you need help +in any area now? What are you doing about it? +- Is there a healthy onboarding and growth path for contributors in your SIG? +What are some activities that the group does to encourage this? What programs +are you participating in to grow contributors throughout the contributor ladder? +- What programs do you participate in for new contributors? +- Does the group have contributors from multiple companies/affiliations? + +##### Current initiatives and project health +- What are initiatives that should be highlighted, lauded, shout outs, that +your group is proud of? Currently underway? What are some of the longer tail +projects that your group is working on? +- What areas does the group need the most help with? +- Whats the average open days of a PR and Issue in your group? / what metrics does + your group care about and/or measure? + +### Working Groups: +Working Group Organizers are responsible for submitting this report but may +delegate to members to curate +- What was the initial mission of the group and if it's changed, how? +- What’s the current roadmap until completion? +- Have you produced any artifacts, reports, white papers to date? +- Is the group active? healthy? contributors from multiple companies and/or end +user companies? +- Is everything in your readme accurate? posting meetings on youtube? +- Do you have regular check-ins with your sponsoring SIGs? + + +### Thanks +Thanks to the Apache Software Foundation for their open guidance on PMC reporting +https://www.apache.org/foundation/board/reporting + + +[SIG]: https://git.k8s.io/community/committee-steering/governance/sig-governance.md +[WG]: https://git.k8s.io/community/committee-steering/governance/wg-governance.md +[UG]: https://git.k8s.io/community/committee-steering/governance/ug-governance.md +[governance]: https://git.k8s.io/community/governance.md diff --git a/committee-steering/governance/sig-governance.md b/committee-steering/governance/sig-governance.md index 0f599979d38..5fd89041520 100644 --- a/committee-steering/governance/sig-governance.md +++ b/committee-steering/governance/sig-governance.md @@ -131,6 +131,8 @@ Run operations and processes governing the SIG: - *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* present yearly [annual report] for the group but *SHOULD* get help with +curation from other SIG participants ### Tech Lead @@ -250,6 +252,7 @@ Issues impacting multiple subprojects in the SIG should be resolved by either: [sig-wg-lifecycle]: /sig-wg-lifecycle.md ["member" on our contributor ladder]: /community-membership.md [Kubernetes Community YouTube playlist]: https://www.youtube.com/channel/UCZ2bu0qutTOM0tHYa_jkIwg +[annual report]: ./annual-reports.md [contributor guide]: /contributors/guide/README.md [devel]: /contributors/devel/README.md [#tech-lead]: #Tech-Lead diff --git a/committee-steering/governance/ug-governance.md b/committee-steering/governance/ug-governance.md index 400179b2498..38aaf03e92f 100644 --- a/committee-steering/governance/ug-governance.md +++ b/committee-steering/governance/ug-governance.md @@ -19,6 +19,10 @@ Example User Groups: - Creating Kubernetes project roles. - Claiming ownership of any specific topic. +## UG Activities +- Present yearly [group health check] to Steering Committee + + ## UG Example Activities - Facilitating collaboration between user group members - which may result in the production of - blogs, docs, guides, demos, presentations, prototypes, external contributions, etc. (UG is itself not responsible to create any such content, it merely facilitate members creating them). - Anything produced within the context of the user group can be ultimately owned by a SIG as a subproject or is owned by individuals in the user group. @@ -37,3 +41,4 @@ Example User Groups: The process for setting up a User Group (UG) is listed in the [sig-wg-lifecycle] document. [sig-wg-lifecycle]: /sig-wg-lifecycle.md +[group health check]: ./annual-reports.md diff --git a/committee-steering/governance/wg-governance.md b/committee-steering/governance/wg-governance.md index 83f568c1792..293cbc54978 100644 --- a/committee-steering/governance/wg-governance.md +++ b/committee-steering/governance/wg-governance.md @@ -44,7 +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). +(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]. ## Is it a Working Group? Yes, if... - It does not own any code @@ -72,7 +75,8 @@ should eventually be reflected in a pull request on sigs.yaml: 1. Who will chair the group, and ensure it continues to meet these requirements? 1. Is diversity well-represented in the Working Group? -Please note that all working group organizers and holders of other leadership roles must be [community members]. +Please note that all working group organizers and holders of other leadership +roles must be [community members]. Once the above questions have been answered, complete the rest of the checklist in the [SIG / WG Lifecycle] document @@ -108,3 +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 diff --git a/governance.md b/governance.md index 47668546d81..c08368c28ac 100644 --- a/governance.md +++ b/governance.md @@ -69,9 +69,9 @@ Each SIG must have a charter that specifies its scope (topics, subsystems, code repos and directories), responsibilities, areas of authority, how members and roles of authority/leadership are selected/granted, how decisions are made, and how conflicts are -resolved. See the [SIG charter process] for details on how charters are managed. -SIGs should be relatively free to customize or change how they operate, -within some broad guidelines and constraints imposed by cross-SIG processes +resolved. See the [SIG charter process] for details on how charters are managed. +SIGs should be relatively free to customize or change how they operate, +within some broad guidelines and constraints imposed by cross-SIG processes (e.g., the release process) and assets (e.g., the kubernetes repo). A primary reason that SIGs exist is as forums for collaboration. @@ -162,6 +162,15 @@ User Groups. To facilitate discoverability and engagement, user groups are documented in [sigs.yaml] +## Community Group Annual Reports +As you can see in the descriptions above, the project is robust with diverse +groups of contributors and their varying degrees of expected communications. + +The annual community group health check will establish an opportunity for deeper + dialogue and broader communication across the chairs of each group and the + Steering Committee. By including this reporting with the existing community + meeting structure, we can focus on the goals outlined in the [Annual Report] doc. + ## Cross-project Communication and Coordination While most work shouldn’t require expensive coordination with other @@ -214,4 +223,6 @@ All contributors must sign the CNCF CLA, as described [here](CLA.md). [working group governance]: /committee-steering/governance/wg-governance.md [user group governance]: /committee-steering/governance/ug-governance.md [SIG Governance Requirements]: /committee-steering/governance/sig-governance-requirements.md +[Annual Report]: /committee-steering/governance/annual-reports.md +[monthly community meeting]: /events/community-meeting.md [![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/governance.md?pixel)]()