Skip to content
This repository was archived by the owner on Apr 21, 2022. It is now read-only.

Minor Charter Corrections #44

Merged
merged 1 commit into from
Sep 17, 2019
Merged

Minor Charter Corrections #44

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
45 changes: 23 additions & 22 deletions CHARTER.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,25 +1,26 @@
# OKD Working Group Charter

v1
v1.1

2019-09-13
2019-09-21

https://github.com/openshift/community/pull/3
https://github.com/openshift/community/pull/44

## Introduction
The charter describes the operations of the OKD Working Group (OKD WG).

OKD is the Origin Community Distribution of Kubernetes that is upstream to Red Hat’s OpenShift Container Platform and is built around a core of OCI containers, and Kubernetes container cluster management. OKD is augmented by application lifecycle management functionality and DevOps tooling.
OKD is the Origin Community Distribution of Kubernetes that is upstream to Red Hat’s OpenShift Container Platform. It is built around a core of OCI containers and Kubernetes container cluster management. OKD is augmented by application lifecycle management functionality and DevOps tooling.

The OKD Working Group's purpose is to discuss, give guidance to, and enable collaboration on current development efforts for OKD4, Kubernetes and related CNCF projects. The OKD Working Group will also include the discussion of shared community goals for OKD4 and beyond. Additionally, the Working Group will produce supporting materials and best practices for end-users and will provide guidance and coordination for CNCF projects working within the SIG's scope.
The OKD Working Group's purpose is to discuss, give guidance to, and enable collaboration on current development efforts for OKD, Kubernetes, and related CNCF projects. The OKD Working Group will also include the discussion of shared community goals for OKD 4 and beyond. Additionally, the Working Group will produce supporting materials and best practices for end-users and will provide guidance and coordination for CNCF projects working within the SIG's scope.

The OKD Working Group is independent of both Fedora and the Cloud Native Container Foundation (CNCF). The OKD Working Group is a community sponsored by Red Hat.
The OKD Working Group is independent of both Fedora and the Cloud Native Computing Foundation (CNCF). The OKD Working Group is a community sponsored by Red Hat.

## Mission
The mission of the OKD Working Group is:
* To collaborate on areas related to developing, deploying, managing, and operating OKD.
* To develop informational resources like guides, tutorials, and white papers to give the community an understanding of best practices, trade-offs, and value adds as it relates to developing, deploying, and managing applications in cloud native environments.
* To identify suitable projects and gaps in the ecosystem for future collaboration and coordination with those projects.
* To identify suitable projects and gaps in the ecosystem for future collaboration and coordination with those projects.

### Areas considered in Scope
The OKD Working Group focuses on the following end-user related topics of the lifecycle of cloud-native applications:
Expand All @@ -28,7 +29,7 @@ The OKD Working Group focuses on the following end-user related topics of the li
* OKD delivery and release management
* OKD management and operations

The Working Group will work on developing best practices, fostering collaboration between related projects, and working on improving tool interoperability. Additionally, the Working Group will propose new initiatives and projects when capability gaps in the current ecosystem are defined.
The Working Group will work on developing best practices, fostering collaboration between related projects, and working on improving tool interoperability. Additionally, the Working Group will propose new initiatives and projects when capability gaps in the current ecosystem are defined.

The following, non-exhaustive, sample list of activities and deliverables are in-scope for the Working Group:
* Operator Centric Installer
Expand All @@ -53,9 +54,9 @@ Anything not explicitly considered in the scope above. Example include:
The OKD Working Group is run and managed by the following chairs:
* Red Hat Community Development Liaison (CDL Chair) - Diane Mueller
* External to Red Hat (Community Chair) - Dani Comnea
* Red Hat Engineering Liaison (Engineering Chair) - Christian Glombek
* Red Hat Engineering Liaison (Engineering Chair) - Christian Glombek

Note: The referenced names and chair positions will be edited in-place as chairs are added, removed or replaced. See the roles of chairs section for more information.
Note: The referenced names and chair positions will be edited in-place as chairs are added, removed, or replaced. See the roles of chairs section for more information.

A dedicated git repository will be the authoritative archive for membership list, code, documentation, and decisions made. The repository, along with this charter, will be hosted at github.com/openshift/community.

Expand All @@ -69,32 +70,32 @@ New members can apply for membership by creating an Issue or Pull Request on the
Membership can be surrendered by creating an Issue stating this desire, or by creating a Pull Request to remove the own name from the members list.

### Decision Process
This group will seek consensus decisions. After public discussion and consideration of different opinions, the Chair and/or Co-Chair will record a decision and summarize any objections.
This group will seek consensus decisions. After public discussion and consideration of different opinions, the Chair and/or Co-Chair will record a decision and summarize any objections.

All WG members who have joined the GitHub group at least 21 days prior to the vote are eligible to vote. This is to prevent people from rallying outside supporters for their desired outcome.
All WG members who have joined the GitHub group at least 21 days prior to the vote are eligible to vote. This is to prevent people from rallying outside supporters for their desired outcome.

When the group comes to a decision in a meeting, the decision is tentative. Any group participant may object to a decision reached at a meeting within 7 days of publication of the decision on the GitHub Issue and/or mailing list. That decision must then be confirmed on the GitHub Issue via a Call for Agreement.

The Call for Agreement, when a decision is required, will be posted as a GitHub Issue or Pull Request and must be announced on the mailing list. It is an instrument to reach a time-bounded lazy consensus approval and requires a voting period of no less than 7 days to be defined (including a specific date and time in UTC).

Each Call for Agreement will be considered independently, except for elections of Chairs.

The Chairs will submit all Calls for Agreement unless vague, unprofessional, off-topic or lacking sufficient detail to determine what is being agreed.
The Chairs will submit all Calls for Agreement that are not vague, unprofessional, off-topic, or lacking sufficient detail to determine what is being agreed.

In the event that a Call for Agreement falls under the delegated authority or within a chartered Sub-Working Group, the Call for Agreement must be passed through the Sub-Working Group before receiving Working Group consideration.
In the event that a Call for Agreement falls under the delegated authority or within a chartered Sub-Working Group, the Call for Agreement must be passed through the Sub-Working Group before receiving Working Group consideration.

A Call for Agreement may require quorum of Chairs under the circumstances outlined in the Charter and Governing Documents section.

A Call for Agreement is mandatory when:
* A Chair determines that the topic requires a Call for Agreement.
* When petitioned by members of the Working Group and submitted to the Chairs to call a vote unless rejected for cause.
* When petitioned by members of the Working Group and submitted to the Chairs to call a vote unless rejected for cause.
* Technical decisions that add, remove, or change dependencies and requirements.
* Revoke a previous decision made by the Call for Agreement process.
* Approval of a Sub-Working Group when such SWG has any delegated authority.

Once the Call for Agreement voting period has elapsed, all votes are counted, with at least a 51% majority needed for consensus. A Chair will then declare the agreement “accepted” or “declined”, ending the Call for Agreement.
Once the Call for Agreement voting period has elapsed, all votes are counted, with at least a 51% majority of votes needed for consensus. A Chair will then declare the agreement “accepted” or “declined”, ending the Call for Agreement.

Once rejected, a Call for Agreement must be revised before re-submission for a subsequent vote. All rejected Calls for Agreement will reported to the Working Group as rejected.
Once rejected, a Call for Agreement must be revised before re-submission for a subsequent vote. All rejected Calls for Agreement will be reported to the Working Group as rejected.

### Charter and Governing Documents

Expand All @@ -115,14 +116,14 @@ The primary role of Chairs is to run operations and the governance of the group.
* Extending discussion via asynchronous communication to be inclusive of members who cannot attend a specific meeting time.
* Scheduling discussing of proposals that have been submitted.
* Asking for new proposals to be made to address an identified need.
* Oversee disciplinary action for members. The Chairs have the authority to declare a member inactive and expel members for cause.
* Chairs will serve for one-year revolving terms and will be approved using the [Condorcet Method](https://en.wikipedia.org/wiki/Condorcet_method). Upon the expiration of a Chair’s term, it will continue for another year, unless challenged.
* Oversee disciplinary action for members. The Chairs have the authority to declare a member inactive and expel members for cause.
* Chairs will serve for one-year revolving terms and will be approved using the [Condorcet Method](https://en.wikipedia.org/wiki/Condorcet_method). Upon the expiration of a Chair’s term, it will continue for another year, unless challenged.

The terms for founding Chairs start on the approval of this charter.
The terms for founding Chairs start on the approval of this charter.

When no candidate has submitted their name for consideration, the current Chairs may appoint an acting Chair until a candidate comes forward.

Chairs must be active members. Any inactivity, disability or ineligibility results in immediate removal.
Chairs must be active members. Any inactivity, disability, or ineligibility results in immediate removal.

Chairs may be removed by petition to the Working Group through the Call for Agreement process outlined above.

Expand All @@ -131,8 +132,8 @@ Additional Chairs may be added so long as the existing number of Chairs is odd.
In the event that an even number of Chairs exist and vote situation arises, the Chairs will randomly select one chair to abstain.

### Role of Sub-Working Groups
Each Sub-Working Group (SWG) must have a Chair working as an active sponsor. Under the mandate of the Working Group, each SWG will have the autonomy to establish their own charter, membership rules, meeting times, make in-scope decisions as delegated, and management processes.
Each Sub-Working Group (SWG) must have a Chair working as an active sponsor. Under the mandate of the Working Group, each SWG will have the autonomy to establish their own charter, membership rules, meeting times, and management processes. Each SWG will also have the authority to make in-scope decisions as delegated by the Working Group.

SWG are required to submit their agreed Charter to the Working Group for information and archival. The Chairs can petition for dissolution of an inactive or hostile SWG by Call for Agreement. Once dissolved the SWG’s delegated Charter and outstanding authority to make decisions is immediately revoked. The Chairs may then take any required action to restrict access to Working Group Resources.
SWGs are required to submit their agreed Charter to the Working Group for information and archival. The Chairs can petition for dissolution of an inactive or hostile SWG by Call for Agreement. Once dissolved the SWG’s delegated Charter and outstanding authority to make decisions is immediately revoked. The Chairs may then take any required action to restrict access to Working Group Resources.

No SWG will have authority with regards to this Charter or other OKD Working Group Governing Documents.