Thank you to everyone who was able to drop by the Slack channel on Wednesday. The threads there are still ongoing,
From those discussions and my experience I put together a quite-drafty document, a sort of strawpond for you to throw various pebbles at—ideas, corrections, additions, questions, etc.
Please use the "Files changed" tab to add comments via the "+" next to a sentence and its line number. When in the comment, you can use the vertical "+-" button to make a suggested edit or change. This is a useful feature, making it easier to commit your suggestions to the PR.
I am pasting the contents below so we can discuss in this email thread as well:
# SIG Community
This SIG cares about all aspects of what is helpful and harmful to this open source software community.
We understand that this project is a human endeavor, and it is our job to put people before practice, process, and even principle.
**What does it mean to support a community?**
It means understanding and putting resources into whatever is important to people in this community.
We put our own time and energy into this support, and we help coordinate and direct project resources.
**What is an open source project compared to a community?**
A _project_ is a general term referring to an effort by people to accomplish something that requires time and multiple steps. Pruning a rose bush is a task, where a multi-year effort to plant a new rose garden is a project.
An open source software community is a type of _community of practice_, and the software project is the place where the community practices.
You can have a community without a project, which is really a social club.
But you cannot have an open source project without a community.
However, not all open source software is maintained by a project.
It may rather be maintained by an individual, or a single organization by fiat.
### In scope
* Creating and maintaining an open source governance for the project
- In particular establishing democratically elected overarching leadership or focus committees (Steering, Security, et al)
* Establishing further SIGs to take over specific purviews from SIG Community
* Being widely inclusive and holding a vision for diversity and equity in the project
* Supporting diversity, equity, and inclusion with actions and resources
* Maintaining project Code of Conduct and related reporting and response processes
* Care about and improve the user and contributor experience
* Create and maintain user personas for the project
* Establish a project-wide documentation approach
* Establish project-wide communication norms
* User and contributor onboarding, i.e., the process for bringing new people into the project
* Creating and maintaining project role definitions and responsibility/authority matrix
* Keeping track of project and community health, including the use of metrics
* Work with SIG Operations to scope and define the infrastructure of participation for contributors
* Ownership and financing (domain names, other project assets)
* Ensure project-wide transparency
* Set project technical direction and maintain a development roadmap
### Out of scope
* Directing project infrastructure
* Handling embargoed security discussions and responses
* Being the body that leads the project beyond the ratification of Governance 1.1, which will establish one or more leadership committees.
* Contributors, and by extension contributors' organizations
* OpenInfra Foundation, via OpenInfra Labs relationship
* Open Source Developers (user persona)
### Subproject Creation
Creation of subprojects happens through SIG consensus, coordinated by SIG Chairs.
All subprojects and their memberships are tracked in [sigs.yaml](../sigs.yaml).