---
title: "The CentOS SIGs"
title_lead: |
  The Special Interest Groups (SIGs), are the teams responsible for their
  specific CentOS Project variants. Variants are specialized and focused rebuilds
  of CentOS to meet the needs and requirements of their corresponding communities
  and the technology associated with those communities.
layout: aside
---

SIGs are usually self-forming around a technology by a small community of
enthusiasts and interested parties. In addition to the existing CentOS SIGs, it
is expected that additional SIGs, as approved by the CentOS Board, will be
created.

Each group will be responsible for its own variant in CentOS that is
specifically targeted towards its community (e.g., The CentOS FooBar SIG
creates a CentOS variant targeted to FooBar users and developers, the CentOS
Hosting SIG builds a variant for web hosters, included in the CentOS
distribution). The SIG is the deciding authority on what is required in their
variant to satisfy the needs of their community, with the understanding that
the Board has ultimate oversight as explained elsewhere. If required, the
CentOS Board will help the individual SIGs to reach consensus on any issues or
problems.

SIGs are the only way for an entity to use and associate the CentOS brand with
a variant. You can always use Git and the repo to fork and try-out ideas, but
only those packages in git.centos.org and released and signed by CentOS can be
called 'CentOS'.

Another type of SIG is functional, focused on maintaining parts of the Project
itself, such as infrastructure, documentation, and design. A unique SIG is the
Core SIG that builds and maintains the core CentOS derivative of Red Hat
Enterprise Linux. It is unique because it is the central, orchestrating
platform that all other variants are built from.

## CentOS Core SIG Responsibilities

* Build the CentOS release.
* _Sign_ the CentOS release.
* Push official CentOS releases to the initial mirror.
* Coordinate with upstream as required.
* Accept changes into Git.
  * Manage Git licensing and contribution policies.

## Variant SIG Responsibilities

* Create and maintain one or more variations with technology in CentOS on top of or modifications to the core base.
* Foster a user community as a primary purpose of the variant.
  * Keep the Project artifacts (the variant) relevant and useful to the user community.
* Ensure the software brought in to support the variant is licensed and prepared properly for packaging and distribution as part of the CentOS Project.
* Oversee inclusions of code related to the variant in to git.centos.org.
* Conduct the business of the SIG following accepted open source practices around meritocracy and consensus decision making.

## Functional SIG Responsibilities
* Accountable for designing, building, and maintaining key Project component(s).
* Make the functional area open for participation, with barriers to contribution as low as feasible and reasonable.
* Foster a community of users and doers around the functional aspect, to share the responsibility, workload, and innovation.
* Work within given legal constraints and requirements.

## SIG Governance

<figure class="figure">
  <img class="figure-img img-fluid" src="/about/governance/sig-maturity-crossover.png" alt="SIG Governance">
</figure>

The SIGs themselves also have a merit path toward autonomy and accountability
for Project aspects. The determination of merit level is reflected in the
amount of oversight required by the Board and the SIGs ability to self-sign and
release software builds. As merit increases, Board oversight goes down, with a
transition spot in the middle where the SIG naturally obtains more autonomy,
usually toward the end of the "Early" phase.

__Sandboxes__ are the entry point for all proposed SIGs. To enter, there must
be a Champion from or approved by the Board and a proposal (which indicates the
reason for the SIG, the expected audience, initial team, risks, etc.) For a SIG
to be created, there must be at least 3 +1 votes from the Board (NOT including
the Champion) and zero (nil) -1 votes. When approved, the Champion becomes the
formal Mentor of the Sandbox SIG.

Sandboxes cannot make formal releases, but can create releases that allow
people, developers, etc. to use, test, and play with the build. Sandboxes are
also closely monitored by the Board to ensure that they are attracting interest
and developers and users are learning the ropes regarding SIG operation. All
new committers, developers, SIG core team members, etc. must be approved by the
Board.

SIGs that have expressed a level of merit, as determined by the Board, will
move to the __Early__ SIG stage (Sandboxes can request graduation to Early, if
they like). These SIGs are allowed to create formal releases, but the release
must be approved by the Board and signed by the Mentor. In all other matters,
however, they are self-sufficient and no longer require Board approval, such as
as in adding committers and so forth. Movement from Sandbox to Early is via 3
+1 vote of the Board (Mentor not included) and zero (nil) -1 votes.

The final stage is the __Mature__ SIG. Again, this graduation is based on the
judgment and determination of the Board, but this movement must be a unanimous
decision of the Board. The Mature SIG has full control over the SIG, pulling in
its own sources to git.centos.org, its releases, its internal governance, and
has the ability to self-sign releases. The Board members may vote in, or
participate in any SIG decision at any time.

In both the Sandbox and Early SIGs, the role of the Board is primarily to
facilitate the movement of those SIGs towards the Mature level; it serves as an
initial gateway with the goal of getting out of the way of the SIGs.

Note that in all cases, maturity is a measure of the community itself, and not
the codebase or the actual SIG variant release. A mature SIG could create a
non-mature (e.g., Alpha or Beta release) distribution and, conversely, a
Sandbox SIG could produce a very mature (robust and reliable) distro.

## Community and SIGs

SIGs represent the true power and value of the CentOS Project. As seen in the
current CentOS Dojos, and in the CentOS community itself, the builds provide a
safe, neutral, and communal central meeting place for major technology areas.
This is the reason why SIGs should not be program/project specific (e.g., a
MariaDB rebuild), but rather technology-area focused (e.g., the "Hoster's"
rebuild). By creating a central point where all projects and communities can
interact, using the OS as the common foundation, upstream projects will be able
to reach and interface with a much larger audience.

It is expected that SIGs may propose significant forking of the base CentOS
core, such as introducing a new Python version or Linux kernel. It is the job
of the Board and CentOS Core SIG to oversee and approve any forks that are
pulled back into Git, including to ensure that these forks are supportable.
This support is best done by an active and engaged variant SIG. The Board or
CentOS Core SIG can pull a variant from release if they reasonably believe the
variant SIG is unable to support the variant. Another option is reassigning an
active variant from a dead SIG to a willing living SIG. The Board is
specifically not limited in what it can do to protect the quality of the CentOS
mark where it comes to the content and quality of a variant.

## Creating a new SIG

The process of creating a new SIG involves two major components:
community building and the administrative side.

Bring your SIG proposal first to the centos-devel mailing list to find
other like-minded people who wish to start the SIG with you. Also look
around outside of the CentOS project for people who may want to
distribute projects on CentOS

Once you have a core group that wants to make this happen, open a ticket
on the [board issue tracker](https://git.centos.org/centos/board/issues)
with your proposed SIG, and someone there will walk you through the
process.

For the current list of active SIGs, refer to
[http://wiki.centos.org/SpecialInterestGroup](http://wiki.centos.org/SpecialInterestGroup)

## Retiring a SIG

If a SIG misses two of their quarterly reports in a row: then the community manager should contact the members listed in the account system. More than a single attempt at contact should be made. If the SIG responds they can be correctly categorized. If they do not respond within 45 days, they can be considered inactive.

If the SIG (a) fails to respond, (b) responds that the SIG completed the work it intended and no further work is required, or (c) responds that they’ve decided to abandon the effort - the following actions should be performed.

(1) An announcement should be sent to CentOS Devel indicating the SIG is reaching end of life. If members believe they can re-energize the SIG, this would be the time to stop the retirement.
(2) A board ticket should be opened for notification purposes only so the board can track if suddenly a bunch of SIGs drop off.
(3) A ticket should be opened with Infra to archive the SIG materials. Steps should be taken to account for both the desire to credit past members with their work and those members who wish to be de-listed from the archive.