Introduce new SIG governance and tooling

GOVERNANCE.md

@@ -50,6 +50,26 @@ 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:cncf-kubevirt-maintainers@lists.cncf.io).
 
+## SIGs
+
+The following is largely copied from the [Kubernetes project implementation of SIGs](https://github.com/kubernetes/community/blob/master/governance.md#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 Documentation. 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. Most identifiable subpart of the project (e.g., github org, repository, subdirectory, API, test, issue, PR) are intended to be owned by some SIG.
+
+Areas covered by SIGs may be vertically focused on particular components or functions, cross-cutting/horizontal, spanning many/all functional areas of the project, or in support of the project itself. Examples:
+
+* Vertical: Compute, Network, Storage
+* Horizontal: Scalability, Architecture
+* Project: Testing, Release, Docs
+
+SIGs must have at least one and ideally two SIG chairs at any given time. SIG chairs are intended to be organizers and facilitators, responsible for the operation of the SIG and for communication and coordination with the other SIGs, the Steering Committee, and the broader community.
+
+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 (e.g., the PR approval and release process) and assets (e.g., the KubeVirt repo).
+
+A primary reason that SIGs exist is as forums for collaboration. Most of the work in a SIG should stay local within that SIG. However, SIGs must communicate in the open; ensure other SIGs and community members can find notes of meetings, discussions, designs, and decisions; and periodically communicate a high-level summary of the SIG's work to the community.
+
+SIGs may also need to collaborate on PRs that make changes to areas owned by multiple SIGs. Where possible each SIG should provide approval before the overall PR is merged in this situation with approval by a single maintainer avoided if possible.
+
 ## Meetings
 
 Time zones permitting, Maintainers are expected to participate in the weekly public

Makefile

@@ -0,0 +1,7 @@
+IMAGE_NAME=golang:1.18
+
+generate:
+ go run ./tools/sigs/generator/app.go
+
+generate-dockerized:
+ docker run --rm -e WHAT -e GOPROXY -v $(shell pwd):/go/src/app:Z $(IMAGE_NAME) make -C /go/src/app generate

OWNERS_ALIASES

@@ -0,0 +1,13 @@
+aliases:
+ sig-compute-leads:
+ sig-documentation-leads:
+ sig-network-leads:
+ sig-release-leads:
+ sig-scale-leads:
+ - rthallisey
+ sig-storage-leads:
+ sig-testing-leads:
+ ug-kubevirt-community-leads:
+## BEGIN CUSTOM CONTENT
+
+## END CUSTOM CONTENT

go.mod

@@ -2,4 +2,12 @@ module kubevirt.io/community
 
 go 1.16
 
-require gopkg.in/yaml.v3 v3.0.0-20210107192922-496545a6307b
+require (
+ github.com/go-git/go-git/v5 v5.8.1 // indirect
+ github.com/google/go-github/v32 v32.1.0 // indirect
+ golang.org/x/mod v0.12.0 // indirect
+ gopkg.in/yaml.v3 v3.0.1
+ k8s.io/enhancements v0.0.0-20230814195121-6f435a9d5438 // indirect
+)
+
+replace k8s.io/test-infra => k8s.io/test-infra v0.0.0-20230814175321-ca2ce39cca6f