+ + + + + + + + + + + + + About CentOS + + + + + + + + + + + + + + + + +

+ +

+ + +

Meritocracy
Consensus decision making

#CentOS Governance - Appendix: Glossary

CentOS Governance - Appendix: Glossary

Meritocracy

@@ -12,8 +147,8 @@

As the above shows, a meritocracy is not, therefore, a democracy proper but a pseudo-republic. The wants and desires of the community are weighed in the atmosphere of merit that enables access and control.

##Consensus decision making -One practice of meritocracy is the consensus-based decision model. From http://en.wikipedia.org/wiki/Consensus_decision-making, “Consensus decision-making is a group decision making process that seeks the consent of all participants.” In practice, it is different from a majority-vote-wins approach. In the CentOS Project a discussion toward a decision follows this process:

Consensus decision making

One practice of meritocracy is the consensus-based decision model. From http://en.wikipedia.org/wiki/Consensus_decision-making, “Consensus decision-making is a group decision making process that seeks the consent of all participants.” In practice, it is different from a majority-vote-wins approach. In the CentOS Project a discussion toward a decision follows this process:

A proposal is put forth and a check for consensus is made. @@ -47,3 +182,13 @@ One practice of meritocracy is the consensus-based decision model. From http://e
Block (-1) votes used as a veto are typically used only when consensus cannot otherwise be met, and are effectively a veto that any sitting Board member can utilize with sufficient substantiation.

« Back to Governance
+ +

+ +

+ + diff --git a/_site/about/governance/board-responsibilities.html b/_site/about/governance/board-responsibilities.html index 74ed69c..40518f6 100644 --- a/_site/about/governance/board-responsibilities.html +++ b/_site/about/governance/board-responsibilities.html @@ -1,11 +1,145 @@ -

About CentOS

+ +

+ + +

CentOS Governing Board Responsibilities
Individual Governing Board Member Responsibilities
Chair Responsibilities
Red Hat Liaison Responsibilities

#CentOS Governing Responsibilities

CentOS Governing Responsibilities

« Back to Governance

CentOS Governing Board Responsibilities

@@ -75,3 +209,13 @@

The Board will operate under the principles of meritocracy, having the Board be driven by a consensus-based decision model. This model fosters an active healthy debate that furthers the Project while recognising its relationship to Red Hat’s product source, the new formal relationship with Red Hat, and preserving the viability of the key upstream that feeds it.

« Back to Governance

+ +

About CentOS

+ +

+ + +

Variant or Functional SIGs
CentOS Core SIG
Board Members

#CentOS Governance - Joining the Project

« Back to Governance

There are 3 primary paths within the CentOS Project for individuals to obtain and grow merit. The main path is by proving yourself within a SIG or between SIGs (if the SIGs are related in such a way that merit would be transferred.) A second path is to get involved in the primary technical SIG, CentOS Core. A third path is to be part of the Governing Board.

##Variant or Functional SIGs -Individuals wishing to participate in the CentOS Project typically start as users then contributors and eventually committers to a SIG. A contributor is anyone who contributes something to the Project, such as documentation, code, forum help, wiki edits, IRC moderating, and so forth. A committer is a contributor who has gained the right through merit to commit their own contributions directly to Project source repositories, such as git.centos.org (code) and wiki.centos.org (documentation.)

Variant or Functional SIGs

Individuals wishing to participate in the CentOS Project typically start as users then contributors and eventually committers to a SIG. A contributor is anyone who contributes something to the Project, such as documentation, code, forum help, wiki edits, IRC moderating, and so forth. A committer is a contributor who has gained the right through merit to commit their own contributions directly to Project source repositories, such as git.centos.org (code) and wiki.centos.org (documentation.)

The initial level of effort required is quite low, and generally consists of those who use CentOS and submit bug reports and patches to the build, or other contributions as per a SIG’s needs. By creating a steady reputation in helping out a SIG, the SIG team may decide to provide that person with commit access (to any stream of contributions required to show and gain merit, such as code, wiki articles, design artifacts, etc.) under the watchful eye of an assigned mentor. The individual is expected to grow in merit enough that the mentor is no longer required, and at the request of the mentor, the individual becomes a peer within the SIG committer group. The structure in a SIG is flat and a peer with 1 month of experience has as much of a voice about project direction as one with 1 or more years.

##CentOS Core SIG -A SIG with a higher barrier to entry is the CentOS Core SIG, which has the ultimate say in technical and directional decisions related to the build and components in the core. The CentOS Core SIG team is selected for membership from the CentOS Core SIG committer group, as voted on by the current team. Obtaining core team membership requires current members to give at least 3 +1 votes and no -1 votes. A -1 vote on core team membership must be based on a substantive reason, such as technical, Project merit, community behavior, etc.

CentOS Core SIG

A SIG with a higher barrier to entry is the CentOS Core SIG, which has the ultimate say in technical and directional decisions related to the build and components in the core. The CentOS Core SIG team is selected for membership from the CentOS Core SIG committer group, as voted on by the current team. Obtaining core team membership requires current members to give at least 3 +1 votes and no -1 votes. A -1 vote on core team membership must be based on a substantive reason, such as technical, Project merit, community behavior, etc.

A SIG that consistently has a significant number of -1 votes, especially from a single person, indicates an issue that should be brought to the attention of the Board , as it may be an indicator of a dis-functional SIG and may adversely impact the meritocracy.

##Board Members -Each Board member appointed or reconfirmed by the Board will be selected based on merit. Merit criteria have been defined to recognize, among other things, active participation in the CentOS Project, an understanding of the Project, and an understanding and ability to balance the objectives derived from the relationship with it’s Red Hat-based upstream. In this regard, Candidate Board members must:

Board Members

Each Board member appointed or reconfirmed by the Board will be selected based on merit. Merit criteria have been defined to recognize, among other things, active participation in the CentOS Project, an understanding of the Project, and an understanding and ability to balance the objectives derived from the relationship with it’s Red Hat-based upstream. In this regard, Candidate Board members must:

Have demonstrated, including through active participation and contribution to the broader aspects of running the CentOS Project for an extended period of time, a solid understanding of and motivation to foster a healthy relationship to it’s upstream, the factors that influence and guide that ecosystem, and the need to maintain the health and vitality of that ecosystem.

« Back to Governance

+ +

About CentOS

+ +

+ + +

CentOS Core SIG Responsibilities
Variant SIG Responsibilities
Functional SIG Responsibilities
SIG Governance

#The CentOS SIGs

« Back to Governance

@@ -12,7 +152,7 @@

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

CentOS Core SIG Responsibilities

Build the CentOS release.
Sign the CentOS release.

##Variant SIG Responsibilities

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. @@ -38,7 +178,7 @@
Conduct the business of the SIG following accepted open source practices around meritocracy and consensus decision making.

##Functional SIG Responsibilities

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.
Work within given legal constraints and requirements.

##SIG Governance

SIG Governance

@@ -79,3 +219,13 @@ SIGs represent the true power and value of the CentOS Project. As seen in the cu

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

« Back to Governance

+ +

+ + diff --git a/_site/about/governance/voting.html b/_site/about/governance/voting.html index 44c846b..09cb0df 100644 --- a/_site/about/governance/voting.html +++ b/_site/about/governance/voting.html @@ -1,5 +1,143 @@ + + + + + + + + + + + + + About CentOS + + + + + + + + + + + + + + + + +

+ +

+ + +

When do votes need to be called?
Role of the Liaison

#CentOS Governance - Voting

CentOS Governance - Voting

« Back to Governance

The voting system used by all SIGs and the Governing Board uses a consensus-based decision model except where noted.

@@ -8,13 +146,13 @@

All -1s votes require reason/ explanation, -1’s with no substantiation may be overturned.

##When do votes need to be called? -Votes need to be called for all substantial business. Votes need to be left open for a reasonable period (not less than 72 hours) if members of the Board are not available to participate in the vote; provided that for votes/matters that have been deemed time or business critical by Red Hat, as noted below, voting must be held open until the Liaison has voted.

When do votes need to be called?

Votes need to be called for all substantial business. Votes need to be left open for a reasonable period (not less than 72 hours) if members of the Board are not available to participate in the vote; provided that for votes/matters that have been deemed time or business critical by Red Hat, as noted below, voting must be held open until the Liaison has voted.

Lazy consensus may be used for non-substantial business. Lazy consensus is defined as asking for objections as opposed to calling for a vote. Any objection on lazy consensus is considered the same as a -1 on a vote. There is no minimum +1 vote requirement.

##Role of the Liaison -The Liaison also has the role of dealing with issues such as security, export, or items that have a direct legal or other Red Hat business connection for the Project, and on issues of such business may have an additional role as defined by the following:

Role of the Liaison

The Liaison also has the role of dealing with issues such as security, export, or items that have a direct legal or other Red Hat business connection for the Project, and on issues of such business may have an additional role as defined by the following:

A. If a decision/solution cannot be found on an issue that is deemed time and/or business critical by Red Hat then, after a reasonable time, the Liaison may be requested by the Chair to seek assistance from Red Hat in making the decision, obtaining additional input from Red Hat executives, engineers, and stakeholders.

@@ -23,3 +161,13 @@ The Liaison also has the role of dealing with issues such as security, export, o

Unless the Liaison specifically indicates on a specific issue that he/she is acting in his/her official capacity as Liaison, either prior to a vote or later (e.g., after an issue has been deemed time or business critical), the Liaison’s voice and vote is treated the same as any other member of the Board. Decisions indicated as Liaison decisions made on behalf of the Board by the Liaison may not be overturned.

« Back to Governance

+ +

+ + diff --git a/_site/feed.xml b/_site/feed.xml index 9f14c6a..3bfd8a9 100644 --- a/_site/feed.xml +++ b/_site/feed.xml @@ -1 +1 @@ -Jekyll2018-11-29T16:02:25-06:00http://0.0.0.0:4000/feed.xmlcentos-jekyll \ No newline at end of file +Jekyll2018-11-29T22:12:39-06:00http://0.0.0.0:4000/feed.xmlcentos-jekyll \ No newline at end of file diff --git a/about/governance/appendix-glossary.md b/about/governance/appendix-glossary.md index de4aba8..eb731b6 100644 --- a/about/governance/appendix-glossary.md +++ b/about/governance/appendix-glossary.md @@ -2,12 +2,13 @@ title: "CentOS Governance - Appendix: Glossary" markdown: basic is_dynamic: true +layout: default --- * Table of contents will replace this text. {:toc} -#CentOS Governance - Appendix: Glossary +# CentOS Governance - Appendix: Glossary {:.no_toc} [« Back to Governance](/about/governance) @@ -18,7 +19,7 @@ First and foremost, the basic tenet behind meritocracy is that people gain merit As the above shows, a meritocracy is not, therefore, a democracy proper but a pseudo-republic. The wants and desires of the community are weighed in the atmosphere of merit that enables access and control. -##Consensus decision making +## Consensus decision making One practice of meritocracy is the consensus-based decision model. From http://en.wikipedia.org/wiki/Consensus_decision-making, "Consensus decision-making is a group decision making process that seeks the consent of all participants." In practice, it is different from a majority-vote-wins approach. In the CentOS Project a discussion toward a decision follows this process: 1. A proposal is put forth and a check for consensus is made. diff --git a/about/governance/board-responsibilities.md b/about/governance/board-responsibilities.md index e8775e3..7dde0af 100644 --- a/about/governance/board-responsibilities.md +++ b/about/governance/board-responsibilities.md @@ -2,12 +2,13 @@ title: "CentOS Governance - Board Structure" markdown: basic is_dynamic: true +layout: default --- * Table of contents will replace this text. {:toc} -#CentOS Governing Responsibilities +# CentOS Governing Responsibilities {:.no_toc} [« Back to Governance](/about/governance) diff --git a/about/governance/joining-the-project.md b/about/governance/joining-the-project.md index 8d7ac55..81016d4 100644 --- a/about/governance/joining-the-project.md +++ b/about/governance/joining-the-project.md @@ -2,6 +2,7 @@ title: "CentOS Governance - Joining the Project" markdown: basic is_dynamic: true +layout: default --- * Table of contents will replace this text. @@ -13,17 +14,17 @@ is_dynamic: true There are 3 primary paths within the CentOS Project for individuals to obtain and grow merit. The main path is by proving yourself within a SIG or between SIGs (if the SIGs are related in such a way that merit would be transferred.) A second path is to get involved in the primary technical SIG, CentOS Core. A third path is to be part of the Governing Board. -##Variant or Functional SIGs +## Variant or Functional SIGs Individuals wishing to participate in the CentOS Project typically start as users then contributors and eventually committers to a SIG. A contributor is anyone who contributes something to the Project, such as documentation, code, forum help, wiki edits, IRC moderating, and so forth. A committer is a contributor who has gained the right through merit to commit their own contributions directly to Project source repositories, such as git.centos.org (code) and wiki.centos.org (documentation.) The initial level of effort required is quite low, and generally consists of those who use CentOS and submit bug reports and patches to the build, or other contributions as per a SIG's needs. By creating a steady reputation in helping out a SIG, the SIG team may decide to provide that person with commit access (to any stream of contributions required to show and gain merit, such as code, wiki articles, design artifacts, etc.) under the watchful eye of an assigned mentor. The individual is expected to grow in merit enough that the mentor is no longer required, and at the request of the mentor, the individual becomes a peer within the SIG committer group. The structure in a SIG is flat and a peer with 1 month of experience has as much of a voice about project direction as one with 1 or more years. -##CentOS Core SIG +## CentOS Core SIG A SIG with a higher barrier to entry is the CentOS Core SIG, which has the ultimate say in technical and directional decisions related to the build and components in the core. The CentOS Core SIG team is selected for membership from the CentOS Core SIG committer group, as voted on by the current team. Obtaining core team membership requires current members to give at least 3 +1 votes and no -1 votes. A -1 vote on core team membership must be based on a substantive reason, such as technical, Project merit, community behavior, etc. A SIG that consistently has a significant number of -1 votes, especially from a single person, indicates an issue that should be brought to the attention of the Board , as it may be an indicator of a dis-functional SIG and may adversely impact the meritocracy. -##Board Members +## Board Members Each Board member appointed or reconfirmed by the Board will be selected based on merit. Merit criteria have been defined to recognize, among other things, active participation in the CentOS Project, an understanding of the Project, and an understanding and ability to balance the objectives derived from the relationship with it's Red Hat-based upstream. In this regard, Candidate Board members must: * Have demonstrated, including through active participation and contribution to the broader aspects of running the CentOS Project for an extended period of time, a solid understanding of and motivation to foster a healthy relationship to it's upstream, the factors that influence and guide that ecosystem, and the need to maintain the health and vitality of that ecosystem. diff --git a/about/governance/sigs.md b/about/governance/sigs.md index c44c649..3f69d7e 100644 --- a/about/governance/sigs.md +++ b/about/governance/sigs.md @@ -2,6 +2,7 @@ title: "CentOS Governance - SIGs" markdown: basic is_dynamic: true +layout: default --- * Table of contents will replace this text. @@ -21,7 +22,7 @@ SIGs are the only way for an entity to use and associate the CentOS brand with a 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 +## CentOS Core SIG Responsibilities * Build the CentOS release. * _Sign_ the CentOS release. * Push official CentOS releases to the initial mirror. @@ -29,7 +30,7 @@ Another type of SIG is functional, focused on maintaining parts of the Project i * Accept changes into Git. * Manage Git licensing and contribution policies. -##Variant SIG Responsibilities +## 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. @@ -37,13 +38,13 @@ Another type of SIG is functional, focused on maintaining parts of the Project i * 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 +## 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 +## SIG Governance

diff --git a/about/governance/voting.md b/about/governance/voting.md index c7bb128..26ca18e 100644 --- a/about/governance/voting.md +++ b/about/governance/voting.md @@ -2,12 +2,13 @@ title: "CentOS Governance - Voting" markdown: basic is_dynamic: true +layout: default --- * Table of contents will replace this text. {:toc} -#CentOS Governance - Voting +# CentOS Governance - Voting {:.no_toc} [« Back to Governance](/about/governance) @@ -17,12 +18,12 @@ Except where noted, decisions require 3 yes votes (+1) and no objections (-1's) All -1s votes require reason/ explanation, -1's with no substantiation may be overturned. -##When do votes need to be called? +## When do votes need to be called? Votes need to be called for all substantial business. Votes need to be left open for a reasonable period (not less than 72 hours) if members of the Board are not available to participate in the vote; provided that for votes/matters that have been deemed time or business critical by Red Hat, as noted below, voting must be held open until the Liaison has voted. _Lazy consensus_ may be used for non-substantial business. Lazy consensus is defined as asking for objections as opposed to calling for a vote. Any objection on lazy consensus is considered the same as a -1 on a vote. There is no minimum +1 vote requirement. -##Role of the Liaison +## Role of the Liaison The Liaison also has the role of dealing with issues such as security, export, or items that have a direct legal or other Red Hat business connection for the Project, and on issues of such business may have an additional role as defined by the following: A. If a decision/solution cannot be found on an issue that is deemed time and/or business critical by Red Hat then, after a reasonable time, the Liaison may be requested by the Chair to seek assistance from Red Hat in making the decision, obtaining additional input from Red Hat executives, engineers, and stakeholders.