community, wg, template: create wg templates (#301)

* community, wg, README: add documentation around SIGs and WGs

Signed-off-by: Daniel Hiller <[email protected]>

* community, wg, template: create wg templates

Create a template for working group definitions, aligned to how SIG
templates currently look.

Signed-off-by: Daniel Hiller <[email protected]>

* community, wg, template: update GOVERNANCE.md

Fix whitespace, link to membership policy instead.

Co-authored-by: aburdenthehand <[email protected]>
Signed-off-by: Daniel Hiller <[email protected]>

* Apply suggestions from code review

Co-authored-by: aburdenthehand <[email protected]>
Signed-off-by: Daniel Hiller <[email protected]>

* wg, template: remove leads section

Also add two example GitHub handles under chairs to make clear that two
are the minimum.

Signed-off-by: Daniel Hiller <[email protected]>

---------

Signed-off-by: Daniel Hiller <[email protected]>
Signed-off-by: Daniel Hiller <[email protected]>
Co-authored-by: aburdenthehand <[email protected]>

Author: dhiller

GOVERNANCE.md

@@ -1,11 +1,14 @@
 # Project Governance
 
 - [Maintainers](#maintainers)
-- [Becoming a Maintainer](#becoming-a-maintainer)
-- [Meetings](#meetings)
-- [CNCF Resources](#cncf-resources)
-- [Code of Conduct Enforcement](#code-of-conduct)
-- [Voting](#voting)
+  - [Becoming a Maintainer](#becoming-a-maintainer)
+  - [Meetings](#meetings)
+  - [CNCF Resources](#cncf-resources)
+  - [Code of Conduct Enforcement](#code-of-conduct)
+  - [Voting](#voting)
+- [SIGs (Special Interest Groups)](#sigs)
+  - [SIG Subprojects](#subprojects)
+- [WGs (Working Groups)](#working-groups)
 
 ## Maintainers
 
@@ -27,7 +30,7 @@ follow through to fix issues.
 A maintainer is a contributor to the project's success and a citizen helping
 the project succeed.
 
-## Selecting Maintainers
+### Selecting Maintainers
 
 The current project maintainers will periodically review contributor activities
 to see if additional project members may be promoted to maintainers. 
@@ -50,7 +53,7 @@ A candidate must be proposed by an existing maintainer by filing an PR in the
 A simple majority vote of +1s from existing Maintainers approves the application. 
 Approved maintainers will be added to the [private maintainer mailing list](mailto:[email protected]).
 
-## Meetings
+### Meetings
 
 Time zones permitting, Maintainers are expected to participate in the weekly public
 community meeting. More details can be found [here](commnuity_meeting.md).
@@ -61,7 +64,7 @@ Maintainer on receipt of a security issue or CoC report.  All current Maintainer
 must be invited to such closed meetings, except for any Maintainer who is
 accused of a CoC violation.
 
-## CNCF Resources
+### CNCF Resources
 
 Any Maintainer may suggest a request for CNCF resources, in the
 [developer mailing list](https://groups.google.com/forum/#!forum/kubevirt-dev), 
@@ -70,15 +73,15 @@ or during a community meeting.  A simple majority of Maintainers approves the
 request.  The Maintainers may also choose to delegate working with the CNCF to 
 non-Maintainer community members.
 
-## Code of Conduct
+### Code of Conduct
 
 [Code of Conduct](./code-of-conduct.md)
 violations by community members will be discussed and resolved
 on the [private Maintainer mailing list](mailto:[email protected]).  If the reported CoC violator
 is a Maintainer, the Maintainers will instead designate two Maintainers to work
 with CNCF staff in resolving the report.
 
-## Removing Maintainers
+### Removing Maintainers
 
 Maintainers may voluntarily retire at any time.  Should a maintainer retire, 
 it requires a majority vote of the current maintainers to reinstate them.
@@ -93,7 +96,7 @@ Maintainers may also be demoted at any time for one of the following reasons:
 
 Removing a maintainer requires a 2/3 majority vote of the other maintainers.
 
-## Voting
+### Voting
 
 While most business in KubeVirt is conducted by "lazy consensus", periodically
 the Maintainers may need to vote on specific actions or changes.
@@ -105,3 +108,60 @@ request a vote be taken.
 Most votes require a simple majority of all Maintainers to succeed. Maintainers
 can be removed by a 2/3 majority vote of all Maintainers, and changes to this
 Governance require a 2/3 vote of all Maintainers.
+
+## SIGs
+
+The KubeVirt project is organized primarily into Special Interest Groups, or SIGs.
+Each SIG is comprised of members from multiple companies and organizations, with a
+common purpose of advancing the project with respect to a specific topic, such as
+Networking or Storage. Our goal is to enable a distributed decision structure
+and code ownership, as well as providing focused forums for getting work done,
+making decisions, and onboarding new contributors. Every identifiable subpart of
+the project (e.g., github org, repository, subdirectory, API, test, issue, PR)
+is intended to be owned by some SIG.
+
+Our SIGs define mission and scope via their charters, ownership of code via
+[OWNERS](https://www.kubernetes.dev/docs/guide/owners/), and members and roles in
+[sigs.yaml].
+
+For more details see also the [Kubernetes SIGs] model.
+
+Examples:
+* [sig-network - charter](./sig-network/charter.md)
+* [sig-network - kubevirt/kubevirt OWNERS_ALIASES](https://github.com/kubevirt/kubevirt/blob/a7e0311d8704663351abd4bc9bbc8511753d2838/OWNERS_ALIASES#L60)
+* [sig-ci - sigs.yaml](https://github.com/kubevirt/community/blob/4f63a79c0ed810aa332cd6716d4986001d28bcd7/sigs.yaml#L119)
+
+### Subprojects
+
+Specific work efforts within SIGs are divided into subprojects. Every part of the
+KubeVirt code and documentation must be owned by some subproject. Some [SIGs](#sigs)
+may have a single subproject, but many SIGs have multiple significant subprojects
+with distinct (though sometimes overlapping) sets of contributors and owners, who
+act as subproject’s technical leaders: responsible for vision and direction and
+overall design, choose/approve design proposals approvers, field technical
+escalations, etc.
+
+For more details see also the [Kubernetes Subprojects] model.
+
+## Working Groups
+
+We need community rallying points to facilitate discussions/work regarding topics
+that are short-lived or that span multiple SIGs.
+
+Working groups are primarily used to facilitate topics of discussion that are in
+scope for KubeVirt but that cross SIG lines.
+
+Our WGs define mission and scope via their charter, and members and roles in
+ [sigs.yaml].
+
+For more details see also the [Kubernetes WGs] model.
+
+## Roles and Organization Management
+
+All our SIGs and WGs follow the Roles and Organization Management outlined in our [membership policy].
+
+[Kubernetes SIGs]: https://github.com/kubernetes/community/blob/master/governance.md#sigs
+[Kubernetes Subprojects]: https://github.com/kubernetes/community/blob/master/governance.md#subprojects
+[Kubernetes WGs]: https://github.com/kubernetes/community/blob/master/governance.md#working-groups
+[membership policy]: ./membership_policy.md
+[sigs.yaml]: ./sigs.yaml

README.md

@@ -1,7 +1,7 @@
 # Community
 
 Welcome to the KubeVirt Community repo!
-Here you will find all things community, including our [membership policy](membership_policy.md), [project governance](GOVERNANCE.md), charters for our SIGs (Special Interest Groups), [upcoming events](https://github.com/kubevirt/community/wiki/Events), and more.
+Here you will find all things community, including our [membership policy](membership_policy.md), [project governance](GOVERNANCE.md), charters for our [Special Interest Groups](./GOVERNANCE.md#sigs) and [Working Groups](./GOVERNANCE.md#working-groups), [upcoming events](https://github.com/kubevirt/community/wiki/Events), and more.
 
 If you're looking for the main code base, you can find it at [kubevirt/kubevirt](https://github.com/kubevirt/kubevirt).
 

wg-TEMPLATE/README.md

@@ -0,0 +1,37 @@
+# Working Group Responsibilities
+
+All KubeVirt Working Groups (WGs) must define a charter.
+
+- The scope must define:
+  - what problem the WG is solving
+  - what deliverable(s) will be produced, and to whom
+  - when the problem is expected to be resolved
+- The governance must outline:
+  - the responsibilities within the WG
+  - the roles owning those responsibilities
+  - which SIGs are stakeholders
+
+## Steps to create a WG charter
+
+1. Copy [the template][WG Template] into a new file under community/wg-*YOURWG*/charter.md
+2. Fill out the template for your WG
+3. Update [sigs.yaml] with the individuals holding the roles as defined in the template.
+4. Create a pull request with a draft of your `charter.md` and `sigs.yaml` changes. Communicate it within your WG and the stakeholder SIGs and get feedback as needed.
+5. Send the WG Charter out for review to [email protected]. Include the subject "WG Charter Proposal: YOURWG"
+   and a link to the PR in the body.
+6. Typically expect feedback within a week of sending your draft. Expect longer time if it falls over an
+   event such as KubeCon/CloudNativeCon or holidays. Make any necessary changes.
+7. Once accepted, the maintainers will ratify the PR by merging it.
+
+## How to use the templates
+
+WGs should use [the template][WG Template] as a starting point.
+
+
+## Goals
+
+The primary goal of the charters is to define the scope of the WG within KubeVirt and how the WG can determine whether it has achieved their solution. A majority of the effort should be spent on these concerns.
+
+[WG Template]: wg-charter-template.md
+[sigs.yaml]: ../sigs.yaml
+

wg-TEMPLATE/wg-charter-template.md

@@ -0,0 +1,22 @@
+# WG YOURWG Charter
+
+## Scope
+
+Include a 2-3 sentence summary of the problem this group is trying to solve.
+Imagine trying to explain your work to a colleague who is familiar with KubeVirt
+but not necessarily all of the internals.
+
+## Governance
+
+### Stakeholder SIGs
+
+A list of SIGs that are relevant to the WG.
+The template may also mention:
+* which SIGs are more relevant than others, and
+* which subprojects are related to the WG
+
+### Roles and responsibilities
+
+#### Chairs
+- @your-github-handle-1
+- @your-github-handle-2