---

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">

</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.