2:16 p.m.
Hi all:
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.
https://github.com/operate-first/community/pull/124/
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
## Scope
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.
## Stakeholders
* Contributors, and by extension contributors' organizations
* OpenInfra Foundation, via OpenInfra Labs relationship
* MOC?
* 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).
--
Karsten Wade [he/him/his] | Senior Community Architect | @quaid
Red Hat Open Source Program Office (OSPO) : @redhatopen
The Open Source Way : https://theopensourceway.org
Operate First : https://operate-first.cloud