**DRAFT DRAFT DRAFT**

*This document is a work in progress, and has not been reviewed by anyone.*

# Special Interest Groups

Special Interest Groups (SIGs) are smaller groups within the CentOS community that focus on a small set of issues, in order to either create awareness or to focus on development along a specific topic.

## Purpose and Value of SIGs

The definition of SIGs is broad enough to encompass a wide variety of possible efforts, and we look to the community to define what they want to work on. Some of the more common focuses of SIGs include:

* CI/CD of an upstream effort, for use on CentOS variants
* Curation of a set of tools for use on CentOS in a particular field of use
* Creation of a "spin" of CentOS for a particular purpose
* Working group around a particular task or topic (eg. promotion, infrastructure, documentation) benefiting the CentOS project as a whole

Many existing SIGs are focused on making sure a particular tool or package works well on CentOS Linux or CentOS Stream, and so much of their effort might be on packaging and testing. This may be particularly useful to project or product teams who wish to target CentOS, RHEL, and RHEL rebuilds for production deployment.

## Creation

SIGs are created upon approval by the Board of Directors.

### Requirements

A proposed SIG must meet certain requirements:

* The topic must be related to a use scenarion on CentOS Linux and/or CentOS Stream, or of benefit to the CentOS community as a whole.
* A SIG must default to public communication on all topics, with private deliberation/discussion happening only when there is reasonable justification. Such private communication must be accessible to the Board of Directors for oversight purposes.
* All code produced within the SIG must be compatible with a [FOSS license presently used by CentOS](https://www.centos.org/legal/licensing-policy/)
* All documentation produced within the SIG must be under a license which complies with [CentOS content licensing policy](https://www.centos.org/legal/licensing-policy/#other-contributions)
* A proposed SIG shall be sponsored by a past or present member of the Board of Directors, or the current Chair of another existing SIG.

### The Proposal Process

Before you write a SIG proposal, you should address the following considerations:

#### Existing SIGs in the same space.

Check to see if the topic of collaboration is already covered by an [existing SIG](https://wiki.centos.org/SpecialInterestGroup).

While a certain amount of overlap between SIGs may be acceptable in some cases, strive to collaborate with an existing SIG wherever possible, to avoid splitting a volunteer pool or otherwise duplicating effort.

SIGs should ordinarily be organized around a particular topic (eg. Cloud, or Virtualization) rather than a specific implementation (eg. OpenStack, or Xen)

#### Request comment on centos-devel

Post an introductory 'RFC' (Request For Comments) email to the [centos-devel mailing list](https://lists.centos.org/mailman/listinfo/centos-devel) before investing a lot of time in writing a propsal. This serves several purposes, including identifying potential collaborators, determining whether there is already any existing effort on your area of interest.

#### Find a sponsor

Find a CentOS Governing board member, or the chair of another existing SIG, to join the effort as a sponsor. If you are not able to find someone, you should ask the Community Manager to assist in your search.

The SIG sponsor need not be an active member of the SIG itself, but, rather, serves as a mentor through the creation process.

In particular, the SIG sponsor will
* Help you craft your proposal, based on what they believe the Board will be looking for
* Assist in scheduling the agenda item in which the Board of Directors will consider your request
* Upon creation of the SIG, they will work with you and the Infrastructure SIG to request any initial resources be created
* List the SIG on the SpecialInterestGroup page in the wiki, and ensure that your SIG wiki page contains all of the recommended information.

#### Write your proposal

See [SpecialInterestGroup/ProposalTemplate](https://wiki.centos.org/SpecialInterestGroup/ProposalTemplate) for a template of things to include on the SIG's wiki page. Your initial SIG wiki page will serve as the proposal which will be presented to the Board of Directors for approval.

Once your proposal has been written, you should send it to the centos-devel mailing list for comments and suggestions. This also notifies the Board that they should expect the proposal to appear in a Board meeting agenda in the near future.

### Acceptance

The sponsoring member of the Governing board will put the proposal at a regularly scheduled board meeting. The Board will, if the proposal is accepted, give its charter to the SIG to begin its work.

SIG founders should stay in close contact with their sponsor through this process to work out any questions arising from the proposal.

Once a SIG proposal is approved, you should update the SIG wiki page to reflect that the SIG is now active, and proceed with starting up the work of the SIG.

## Resources

Each SIG should have a wiki page, as mentioned above, which describes the goals and progress of the SIG. See ["Contribute to the Wiki"](https://wiki.centos.org/Contribute#Contribute_to_the_Wiki) for details on how to request access to create this content.

A SIG may request a dedicated mailing list. However, we recommend that, at least initially, all discussion happen on `centos-devel`, using a SIG subject line tag (For example, preface your subject line with "[Cloud]" to indicate that the topic is in regards to the Cloud SIG) in order to keep your work in front of the entire community. A SIG's conversations may be split off into a separate list at such a time that they reach a volume which overwhelms other discussion.

Subject to available resources and Infrastructure SIG time, other resources (eg. a SCM system, web hosting space, admin services, etc.) may be requested.

## Governance

SIGs are expected to operate in a collaborative, transparent, consensus-based manner.

SIGs are encouraged, whenever possible, to strive for vendor neutrality. That is, they should actively seek membership that represents more than a single employer or organization.

Each SIG shall designate a SIG Chair. This is not necessarily a leader, but, rather, is the individual tasked with reporting to the Board of Directors (See below) and ensuring that the SIG records (ie, the wiki page) accurately reflect the status of the SIG. The method of selecting this Chair is left to each SIG.

SIGs are expected to operate according to the terms of the [CentOS Code of Conduct](https://www.centos.org/code-of-conduct/).

Beyond that, the governance requirements are minimal, and each SIG is encouraged to govern themselves in the way that best works for them. In SIGs which are related to an upstream community, this usually means reflecting the governance of that upstream community.

## Communication and Documentation

Discussions should occur in public, whenever possible. That is, they should happen on a public mailing list, or, if discussion happens elsewhere, it should be reported back to the mailing list for broader visibility.

Important decisions should be made in such a way that SIG membership across multiple languages and/or timezones is given time to weigh in, rather than rushing things during a time when others may be sleeping or observing local/regional holidays.

Decisions should be documented publicly (ie, in the wiki), so that they may be accessed easily by those coming to the project later on.

## Reporting and Oversight

SIGs are expected to report to the Board of Directors quarterly, on [a schedule which will be listed](https://wiki.centos.org/SpecialInterestGroup#SIG_Reporting).

Reports should include:

* Membership update (members added, removed, Chair changes)
* Releases or other artifacts produced since the last report
* Health report and general activity report
* Issues to bring to the attention of the Board

Although your report is addressed to the Board, and is used to ensure that SIGs are operating in a healthy and sustainable manner, your secondary audience is the larger community, to keep them informed of your work, and let them know areas where they can get involved.

## Retirement

When a SIG is no longer active, the wiki should be updated to reflect this. Specifically, the SIG's wiki page should indicate that the SIG is retired, and the [main SIG listing](https://wiki.centos.org/SpecialInterestGroup) should be updated to move the SIG to the Retired/Inactive list.

Any artifacts that were produced by the SIG may be moved to the [CentOS Vault](https://vault.centos.org/) at this time, to indicate to users that they are no longer updated or supported in any way.