Google Drive
Gist
Clipboard
DRAFT DRAFT DRAFT
This document is a work in progress, and has not been reviewed by anyone.
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.
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:
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.
SIGs are created upon approval by the Board of Directors.
A proposed SIG must meet certain requirements:
Before you write a SIG proposal, you should address the following considerations:
Check to see if the topic of collaboration is already covered by an existing SIG.
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)
Post an introductory 'RFC' (Request For Comments) email to the centos-devel mailing list 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 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
See 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.
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.
Each SIG should have a wiki page, as mentioned above, which describes the goals and progress of the SIG. See "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.
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.
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.
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.
SIGs are expected to report to the Board of Directors quarterly, on a schedule which will be listed.
Reports should include:
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.
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 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 at this time, to indicate to users that they are no longer updated or supported in any way.
-
Any changes
Be notified of any changes
-
Mention me
Be notified of mention me
-
Unsubscribe
Subscribe