shaunm / centos / centos.org

Forked from centos/centos.org 2 years ago
Clone

Blame about/governance/sigs.md

401d07
---
401d07
title: "The CentOS SIGs"
401d07
title_lead: |
401d07
  The Special Interest Groups (SIGs), are the teams responsible for their
401d07
  specific CentOS Project variants. Variants are specialized and focused rebuilds
401d07
  of CentOS to meet the needs and requirements of their corresponding communities
401d07
  and the technology associated with those communities.
401d07
permalink: /:path/:basename/index.html
401d07
layout: page
401d07
toc: true
401d07
---
401d07
401d07
SIGs are usually self-forming around a technology by a small community of
401d07
enthusiasts and interested parties. In addition to the existing CentOS SIGs, it
401d07
is expected that additional SIGs, as approved by the CentOS Board, will be
401d07
created.
401d07
401d07
Each group will be responsible for its own variant in CentOS that is
401d07
specifically targeted towards its community (e.g., The CentOS FooBar SIG
401d07
creates a CentOS variant targeted to FooBar users and developers, the CentOS
401d07
Hosting SIG builds a variant for web hosters, included in the CentOS
401d07
distribution). The SIG is the deciding authority on what is required in their
401d07
variant to satisfy the needs of their community, with the understanding that
401d07
the Board has ultimate oversight as explained elsewhere. If required, the
401d07
CentOS Board will help the individual SIGs to reach consensus on any issues or
401d07
problems.
401d07
401d07
SIGs are the only way for an entity to use and associate the CentOS brand with
401d07
a variant. You can always use Git and the repo to fork and try-out ideas, but
401d07
only those packages in git.centos.org and released and signed by CentOS can be
401d07
called 'CentOS'.
401d07
401d07
Another type of SIG is functional, focused on maintaining parts of the Project
401d07
itself, such as infrastructure, documentation, and design. A unique SIG is the
401d07
Core SIG that builds and maintains the core CentOS derivative of Red Hat
401d07
Enterprise Linux. It is unique because it is the central, orchestrating
401d07
platform that all other variants are built from.
401d07
401d07
## CentOS Core SIG Responsibilities
401d07
401d07
* Build the CentOS release.
401d07
* _Sign_ the CentOS release.
401d07
* Push official CentOS releases to the initial mirror.
401d07
* Coordinate with upstream as required.
401d07
* Accept changes into Git.
401d07
  * Manage Git licensing and contribution policies.
401d07
401d07
## Variant SIG Responsibilities
401d07
401d07
* Create and maintain one or more variations with technology in CentOS on top of or modifications to the core base.
401d07
* Foster a user community as a primary purpose of the variant.
401d07
  * Keep the Project artifacts (the variant) relevant and useful to the user community.
401d07
* Ensure the software brought in to support the variant is licensed and prepared properly for packaging and distribution as part of the CentOS Project.
401d07
* Oversee inclusions of code related to the variant in to git.centos.org.
401d07
* Conduct the business of the SIG following accepted open source practices around meritocracy and consensus decision making.
401d07
401d07
## Functional SIG Responsibilities
401d07
* Accountable for designing, building, and maintaining key Project component(s).
401d07
* Make the functional area open for participation, with barriers to contribution as low as feasible and reasonable.
401d07
* Foster a community of users and doers around the functional aspect, to share the responsibility, workload, and innovation.
401d07
* Work within given legal constraints and requirements.
401d07
401d07
## SIG Governance
401d07
401d07
<figure class="figure">
401d07
  SIG Governance
401d07
</figure>
401d07
401d07
The SIGs themselves also have a merit path toward autonomy and accountability
401d07
for Project aspects. The determination of merit level is reflected in the
401d07
amount of oversight required by the Board and the SIGs ability to self-sign and
401d07
release software builds. As merit increases, Board oversight goes down, with a
401d07
transition spot in the middle where the SIG naturally obtains more autonomy,
401d07
usually toward the end of the "Early" phase.
401d07
401d07
__Sandboxes__ are the entry point for all proposed SIGs. To enter, there must
401d07
be a Champion from or approved by the Board and a proposal (which indicates the
401d07
reason for the SIG, the expected audience, initial team, risks, etc.) For a SIG
401d07
to be created, there must be at least 3 +1 votes from the Board (NOT including
401d07
the Champion) and zero (nil) -1 votes. When approved, the Champion becomes the
401d07
formal Mentor of the Sandbox SIG.
401d07
401d07
Sandboxes cannot make formal releases, but can create releases that allow
401d07
people, developers, etc. to use, test, and play with the build. Sandboxes are
401d07
also closely monitored by the Board to ensure that they are attracting interest
401d07
and developers and users are learning the ropes regarding SIG operation. All
401d07
new committers, developers, SIG core team members, etc. must be approved by the
401d07
Board.
401d07
401d07
SIGs that have expressed a level of merit, as determined by the Board, will
401d07
move to the __Early__ SIG stage (Sandboxes can request graduation to Early, if
401d07
they like). These SIGs are allowed to create formal releases, but the release
401d07
must be approved by the Board and signed by the Mentor. In all other matters,
401d07
however, they are self-sufficient and no longer require Board approval, such as
401d07
as in adding committers and so forth. Movement from Sandbox to Early is via 3
401d07
+1 vote of the Board (Mentor not included) and zero (nil) -1 votes.
401d07
401d07
The final stage is the __Mature__ SIG. Again, this graduation is based on the
401d07
judgment and determination of the Board, but this movement must be a unanimous
401d07
decision of the Board. The Mature SIG has full control over the SIG, pulling in
401d07
its own sources to git.centos.org, its releases, its internal governance, and
401d07
has the ability to self-sign releases. The Board members may vote in, or
401d07
participate in any SIG decision at any time.
401d07
401d07
In both the Sandbox and Early SIGs, the role of the Board is primarily to
401d07
facilitate the movement of those SIGs towards the Mature level; it serves as an
401d07
initial gateway with the goal of getting out of the way of the SIGs.
401d07
401d07
Note that in all cases, maturity is a measure of the community itself, and not
401d07
the codebase or the actual SIG variant release. A mature SIG could create a
401d07
non-mature (e.g., Alpha or Beta release) distribution and, conversely, a
401d07
Sandbox SIG could produce a very mature (robust and reliable) distro.
401d07
401d07
## Community and SIGs
401d07
401d07
SIGs represent the true power and value of the CentOS Project. As seen in the
401d07
current CentOS Dojos, and in the CentOS community itself, the builds provide a
401d07
safe, neutral, and communal central meeting place for major technology areas.
401d07
This is the reason why SIGs should not be program/project specific (e.g., a
401d07
MariaDB rebuild), but rather technology-area focused (e.g., the "Hoster's"
401d07
rebuild). By creating a central point where all projects and communities can
401d07
interact, using the OS as the common foundation, upstream projects will be able
401d07
to reach and interface with a much larger audience.
401d07
401d07
It is expected that SIGs may propose significant forking of the base CentOS
401d07
core, such as introducing a new Python version or Linux kernel. It is the job
401d07
of the Board and CentOS Core SIG to oversee and approve any forks that are
401d07
pulled back into Git, including to ensure that these forks are supportable.
401d07
This support is best done by an active and engaged variant SIG. The Board or
401d07
CentOS Core SIG can pull a variant from release if they reasonably believe the
401d07
variant SIG is unable to support the variant. Another option is reassigning an
401d07
active variant from a dead SIG to a willing living SIG. The Board is
401d07
specifically not limited in what it can do to protect the quality of the CentOS
401d07
mark where it comes to the content and quality of a variant.
401d07
fb9ced
## Creating a new SIG
fb9ced
fb9ced
The process of creating a new SIG involves two major components:
fb9ced
community building and the administrative side.
fb9ced
fb9ced
Bring your SIG proposal first to the centos-devel mailing list to find
fb9ced
other like-minded people who wish to start the SIG with you. Also look
fb9ced
around outside of the CentOS project for people who may want to
fb9ced
distribute projects on CentOS
fb9ced
fb9ced
Once you have a core group that wants to make this happen, open a ticket
fb9ced
on the [board issue tracker](https://git.centos.org/centos/board/issues)
fb9ced
with your proposed SIG, and someone there will walk you through the
fb9ced
process.
401d07
401d07
For the current list of active SIGs, refer to
401d07
[http://wiki.centos.org/SpecialInterestGroup](http://wiki.centos.org/SpecialInterestGroup)