Skip to end of metadata
Go to start of metadata

COPRHD Governance

Bylaws

Article I- Overview

This document (“Bylaws”) defines the governance structure under which the CoprHD Project (“Project”) operates. It defines the roles and responsibilities of the Project participants, who may vote, how voting works, and how conflicts are resolved.

 

The CoprHD Project provides an open and extensible implementation of a Software-Defined Storage (“SDS”) controller.  An SDS controller provides a uniform management interface for the provisioning and lifecycle management of heterogeneous storage infrastructures ranging from traditional enterprise Storage Area Network (SAN) arrays to software-defined storage stacks running on commodity hardware.

 

Anyone can use CoprHD, and anyone can contribute to the code base.  The intention is to foster an active community of users, Contributors, and Committers across the storage industry to drive innovative and standardized capabilities in storage management.

 

Article II- Roles and Responsibilities

The Bylaws define a set of roles with associated rights and responsibilities.  These roles govern what tasks an individual may perform within the Project.  The roles are defined as follows:

A.              Technical Steering Committee (“TSC”)

 

1.              Overview.  The TSC is responsible for setting the future direction of the Project.  Therefore it is TSC’s responsibility to review all Project development requests and to approve Subprojects that meet the vision and spirit of the Project. 

 

2.              Responsibilities. Example responsibilities of the TSC include: 

a.      Setting the technical direction of the Project including determining what new features are to be included, and what technical problems are to be addressed by each product release;

b.              Approving the content of the product releases;

c.              Prioritizing developments in the Project and any Subproject(s) therein;

d.              Selection of a Project Maintainer(s);

e.              Reporting to the Project community on a regular basis regarding developments within the Project; and

f.               Adoption of rules and regulations governing the Project.

 

3.              Structure of the TSC.  On the Initial Creation Date, the TSC shall be composed of five (5) members.  EMC shall appoint three (3) (the “EMC Voting Block”) of the five (5) TSC members on the Initial Creation Date.  After the Initial Creation Date, the TSC shall have at least five (5) members and no more than ten (10) members.  Each TSC member shall serve a one (1) year term.  For avoidance of doubt, the EMC Voting Block shall expire on the one (1) year anniversary of the Initial Creation Date.  There shall be no prohibition on re-election or re-designation of any TSC member following the completion of that member’s term in office.  Each TSC member shall serve the term specified herein and until his or her successor is appointed, or until his or her earlier death, resignation, or removal, unless an elected TSC member is replacing an existing member, where the newly elected member shall serve out the remaining term of the member being replaced.  TSC membership shall be allocated as follows:

a.              Membership on the TSC.  Any person may be nominated to fill a seat on the TSC. These seats shall be voted on as follows. Each Committer may vote for a number of candidates equal to the number of open seats on the TSC. Those Persons receiving the largest number of Committer votes shall be elected to the TSC.  For example, if there are five (5) TSC seats available, each committer may vote for up to 5 people. If the distribution of votes across seven candidates is- 22%, 20%, 18%, 16%, 10%, 8%, and 6% , those candidates receiving 22%, 20%, 18%, 16%, and 10% of the vote shall be elected as members of the TSC.

b.              [Reserved]

 

4.              [Reserved]

 

5.              Election of a TSC Chair.  Within twenty (20) days of the Initial Creation Date, the TSC members shall elect a chairperson (“TSC Chair”) for a one (1) year term to represent the views of the TSC, the chairperson voted into their position by a simple majority (more than fifty percent (50%)) of TSC members.  Subsequent TSC Chairs shall be elected for a one (1) year term by a simple majority (more than fifty percent (50%)) of TSC members on the one (1) year anniversary of the TSC Chair’s election.  There shall be no prohibition on re-election of a TSC Chair following the completion of that Chair’s term in office.  Each TSC Chair shall serve the term specified herein and until his or her successor is elected or until his or her earlier death, resignation, or removal, unless an elected TSC Chair is replacing an existing Chair, where the newly elected TSC Chair shall serve out the remaining term of the Chair being replaced.

 

6.              TSC Meetings and Voting Generally.  At least once a year and, where so desired, on a more frequent cadence (e.g., monthly, quarterly) as determined by a simple majority (more than fifty percent (50%)) of TSC members, the TSC shall meet to discuss and vote on TSC business (e.g., technical direction of the Project, and election of the TSC Chair).  In the case of a tie vote between TSC members, the TSC Chair shall be the tie breaking vote. 

 

7.              Matters Requiring a Simple TSC Majority.  The following matters require a simple majority (more than fifty percent (50%)) of TSC members to approve:

 

a.     Product Releases.  When a release of one of the Project's products is ready, a vote in favor is required to accept the release as an official release of the Project.

b.     Product Release Theme.  When a new Project Theme is proposed, a vote is required.

c.     Appointment of Maintainer(s).  When voting for a candidate Maintainer, a vote in favor of the candidate becoming a Maintainer is required. 

d.     Setting of Cadence to Elect New Committers.  When new Committers to a Subproject are sought, a vote in favor of an election cadence is required.

e.     Setting of an Approval Type(s).  When the TSC seeks to identify the type of Approval sought (see Article III.B) from Committers for a decision, a vote in favor of the type of approval sought is required. 

f.      Expansion of the TSC Size.  When the TSC desires to expand its membership beyond five (5) members, a vote is required.

g.     Meeting Cadence.  When the TSC desires to set a regular meeting cadence (e.g., meeting on a monthly, quarterly basis), a vote is required. 

h.     Creation of a New Incubated or Active Project. When the TSC seeks to create a new Incubated or Active Project, a vote is required.

i.      Changing the Status of a Subproject.  When the TSC desires to change the status of a Subproject, a vote is required.

j.      Inclusion of a Subproject in Project Official Release.  When the TSC desires to incorporate a Subproject into an official release of the Project, a vote is required.

k.     Ceasing Operations.  When the TSC desires to cease operations during the two (2) year period from the Initial Creation Date, a vote is required.

 

8.              Matters Requiring a Super TSC Majority.  The following matters require a super majority (more than seventy percent (70%)) of TSC members to approve:

a.     Approving or Changing the Name of the Project.  When the TSC seeking to approve changing the name of the Project, a vote is required.

b.     Selecting a Standards Organization.  When the TSC seeks to select a standards organizations through which to standardize the Project, a vote in favor is required.

c.     Amending these Bylaws.  Where the TSC seeks to amend these Bylaws, a vote is required.

d.     Entering into Any Formal Affiliation with Another Organization.  Where the TSC seeks to enter into any formal affiliation with another organization (e.g., the Eclipse Foundation, the Linux Foundation), a vote is required.

e.     Changes to Article V- Licensing & Intellectual Property.  When the TSC seeks to approve changes (e.g., selection of a new Project license) to Article V- Licensing & Intellectual Property, a vote is required.

f.      TSC Member Removal.  When removal of a TSC member is sought, a vote of TSC members (excluding the member in question) is required.

g.     Committer Removal.  When removal of commit privileges is sought, a vote of TSC members (excluding the Committer in question if a member of the TSC) is required.

 

9.              Notice Requirements for Meetings.  The TSC Chair will schedule regular TSC meetings at an agreed to cadence.  No regular TSC meeting will be deemed to have been validly held unless written notice is provided to each of the TSC members at least fourteen (14) calendar days prior to such meeting, the notice will identify the time and place of the meeting and all potential actions to be undertaken by the TSC at the meeting so that each member can reasonably prepare for and attend such TSC meeting.  The written notice may be provided personally, by mail, by fax, or by electronic message with return confirmation.  Each member has a right to attend and shall make a reasonable effort to attend each TSC meeting, including by telephone.

 

10.           Special Meetings.  Special TSC meetings for any purpose or purposes outside of the published agenda for regular meetings may be called at any time by the TSC Chair or by simple majority (more than fifty percent (50%)) of the members.  Written notice of the time and place of such special meeting shall be given to each member at least five (5) days prior to the special meeting.

 

11.          Action by the TSC.  No action may be taken or approved by the TSC that is outside the Project’s stated purpose as set forth in Article I.

 

12.           Action Without Meeting.  Any action required or permitted to be taken by the TSC at a meeting may be taken without a meeting if all of the members consent in writing to such action, by electronic ballot or otherwise.  The action shall be evidenced by one or more written consents describing the action taken, signed by each member, and included in any minutes reflecting the action taken.  Any action taken hereunder shall be effective upon the receipt of the written consent of all of the members for approval of the action under consideration.

 

13.           Quorum.  A “Quorum” as used herein requires that a simple majority (more than fifty percent (50%)) of the TSC members must be present (including via telephone or video conference, or other lawful means not prohibited by these Bylaws) for the transaction of business by the TSC.  If this Quorum is not established at any TSC meeting, the members present in person or otherwise as provided above, and entitled to vote at such meeting, can recess the TSC meeting from time to time, without notice other than announcement at the meeting, until such Quorum is established.  A majority of the voting power of the members present, whether or not a Quorum is present, may recess or adjourn any meeting to another time and place.

 

14.           Reserved

 

B.              Contributors

All of the volunteers who are contributing code, documentation, or resources to the Project are deemed contributors to the Project.  A Contributor that makes sustained, welcome contributions to the Project may be invited to become a Committer, depending on the ability of the Contributor to meet the definition of a Committer.

 

C.              Committers

1.              Overview.  The Project's Committers are responsible for the ongoing development, documentation, and test (engineering) functions for the Project.  Committers may cast binding votes on any technical discussion regarding any Subproject. 

 

2.              Access to Project Infrastructure.  A Committer’s permission levels on the project infrastructure (e.g., source control, wiki, etc.) will be elevated once they are voted to be a Committer. These expanded permissions will include the ability to commit code to the Project's main branches.

 

3.              Initial Appointment of Committers.  On the Initial Creation Date, EMC shall appoint at least three (3) Committers.

 

4.              Election of Committers Generally.  At least once a month (or some other more frequent cadence as determined by the TSC), a Contributor(s) who meets the definition of a Committer shall be voted on to become a Project Committer, if the contributor is nominated by an existing committer or nominates themself.  To be a Committer, a Contributor must meet the definition of Committer and receive a Consensus Approval (see Article III.B.1) vote by the then existing Project Committers, with a minimum of three (3) affirmative votes. Written notice for a meeting to elect Committers shall be provided at least seven (7) calendar days prior to such meeting, and will identify the time and place of the meeting and Candidate Committers seeking election.  The written notice may be provided to each Project Committer personally, by mail, by fax, or by electronic message with return confirmation.  Each Project Committer has a right to attend and shall make a reasonable effort to attend each election meeting, including by telephone.

 

5.           [Reserved]

 

6.            Lapse of Committer Status. A committer who becomes inactive and makes no contributions to the Project for over six (6) months will be considered to have allowed his or her committer status to lapse and will lose all Committer privileges on the Project. If such an individual becomes active again, they may once again be nominated as a Committer through the normal process.

 

D.             Release Manager

A Release Manager (“RM”) is responsible for managing the lifecycle of stable releases of Project software.  The RM works with the Technical Steering Committee (“TSC”) to build consensus around the release plan, tracks features commits, bug fixes, and testing in order to achieve a successful Product Release Vote.  The RM shall be a person appointed by a simple majority vote (more than fifty percent (50%)) of the TSC members, and shall serve for a one (1) year term.  A vote shall be held on the one (1) year anniversary of the RM’s election to determine a new RM.  Each RM shall serve the term specified herein and until his or her successor is elected or until his or her earlier death, resignation, or removal, unless an elected RM is replacing an existing RM, where the newly elected RM shall serve out the remaining term of the RM being replaced.


Article III- Decision Making by Committers

A.              Voting Generally by Committers.  Decisions regarding the Project are made by votes on the primary Project mailing list of Committers.  For technical decisions, only the votes of Committers are binding.  Votes are clearly indicated by a subject line (i.e., the subject line of some type of electronic correspondence) starting with [VOTE]. Votes may contain multiple items for approval and these should be clearly separated.  A vote is cast by replying to the vote mail.  Voting may take the following flavors:

1.              +1 "Yes," "Agree," or "the action should be performed": In general, this vote indicates a willingness on the behalf of the voter to make it happen;

2.              +0: This vote indicates a willingness for the action under consideration to go ahead. The voter, however, will not be able to help;

3.              -0: This vote indicates that the voter does not, in general, agree with the proposed action but is not concerned enough to prevent the action going ahead; and

4.              -1: “No/Disagree”: This is a negative vote.  On issues where consensus is required, this vote counts as a veto. All vetoes must contain an explanation of why the veto is appropriate.  Vetoes with no explanation are void.  It may also be appropriate for a -1 vote to include an alternate course of action.  All participants in the Project are encouraged to show their agreement with or against a particular action by voting.

 

B.              Approvals by Committers

These are the types of approvals that can be sought by TSC. Different actions require different types of approvals:

 

1.              Consensus Approval: Consensus approval requires binding “Yes” votes and no binding vetoes;

 

2.              Lazy Consensus:  Lazy consensus requires no “No/Disagree” votes (“silence gives assent”);

 

3.              Majority:  A lazy majority vote requires more binding “Yes” votes than “No/Disagree” votes. Silence gives assent; and

 

4.              Super Majority:  Lazy super majority (more than seventy percent (70%)) votes requires twice as many “Yes” votes as “No/Disagree” votes. Silence gives assent.

 

Article IV- Types of Voting by Committers

A.              This section describes the various actions undertaken within the Project, the corresponding approval required for that action, and those who have binding votes over the action.  Types of voting includes:

 

1.     Code Change.  A change made to the Project codebase and committed by a Committer.  This includes source code, documentation, etc.

a.              Approval Required: Lazy Consensus approval of Committers, with a minimum of two approvals (see Article III.A.1).

 

2.     Modifying Bylaws.  Suggested modifications to the Bylaws may be proposed by the Committers and sent to the TSC for consideration.

a.              Approval Required: a super majority (more than seventy percent (70%)) of TSC members (see Article III.A.1). 

 

B.              Voting Timeframes

Votes are open for a period of seven (7) days to allow all active voters time to consider the vote.  Votes relating to code changes are not subject to a strict timetable but should be made as timely as possible.

 

Article V- Licensing & Intellectual Property

A.              Licensing- Code

The Apache License, Version 2.0 (ALv2) (http://www.apache.org/licenses/LICENSE-2.0) shall be the default license used by the Project to license code, and the TSC must approve any exception. 

B.              Contributions- Code

Contributions of code to the project shall be received under the Developer Certificate of Origin (”DCO”) (http://elinux.org/Developer_Certificate_Of_Origin) in combination with an appropriate open source license.

C.              Contributions-Documentation

The Creative Commons License version 4 (the “BY CC License”) (https://creativecommons.org/licenses/by/4.0/legalcode) shall be the default license used by the Project to receive and license contributions of documentation to the Project.

 

D.             Trademarks

The Project shall maintain and publish Trademark Guidelines or Trademark Licenses.  The Trademark Guidelines shall provide guidance for anyone who desires to display or otherwise use the Marks.  Specifically, the Project may from time to time select one or more names, logos, trademarks, certification marks, or service marks (collectively, “Marks”), to be used to promote the Project.  In such case, the Project will promulgate policies for use of such Marks (which may include certification requirements) under a separate policy (collectively, “Trademark Guidelines”).  In certain cases, the TSC may adopt a trademark licensing regime to license Marks.

 

E. Confidentiality and Trade Secrets.

Participants in the Project acknowledge that the Project’s mission is to make the Project code base freely available, and, accordingly, participants shall ensure that any contributions or other materials or information provided by participant, participant’s employees, or agents to the Project are not subject to any requirement of confidentiality, unless and to the extent expressly agreed upon in advance in writing by the TSC and the participant.

 

Article VI- Project Types and Approvals

A.              Overview. 

From time to time the TSC may approve a new Subproject and or change the status of a Subproject.  The voting requirement for approving a new Subproject or changing the status of a Subproject is outlined in Article II.A.7.i. 

 

B.              Creation of a New Active Project of Incubated Project. 

The TSC Chair may propose to the TSC a new Active Project or Incubated Project during any TSC meeting.  The proposal shall identify at least one Committer or TSC member who will manage the Active or Incubated Project, and provide enough technical detail to enable the TSC members to vote on the proposal.  Additionally, the proposal shall outline the necessary infrastructure requirements necessary to maintain the new Active Project or Incubated Project.

 

C.              Changing the Status of a Subproject. 

During a TSC meeting, the TSC Chair may propose to the TSC that a then Active Project or Incubated Project become an Archived Project or vice-versa.  The proposal shall identify the reasons for the proposed change in status so as to enable the TSC members to vote on the proposal.  Additionally, the proposal shall outline the necessary infrastructure requirements necessary to facilitate and maintain the change in status.

 

Article VII- Definitions

 

A.              “Active Project” means a Subproject that is undergoing active development and is included in the release train process.

 

B.              “Affiliate” means any legal entity that directly or indirectly controls another entity via beneficial ownership of more than fifty percent (50%) of voting power or equity (“Control”), or is under the Control of another entity, for so long as such Control exists.

 

C.              “Archived Projects” means a Subproject that reaches the end of its useful life, is retained for posterity, but is no longer actively developed or eligible for release train inclusion.

 

D.             “Candidate Committer(s)” means a Contributor who meets the definition of Committer, but who has not received a simple majority (more than fifty percent (50%)) approval vote of the then existing Project Committers.

 

E.              “Committer” means a Contributor who has received a simple majority (more than fifty percent (50%)) approval vote of the then existing Project Committers.

 

F.              “Contribution” means any information or materials, including software source code, documentation, or related materials, provided to the Project by a Committer or Contributor and which is, or is proposed to be, included in a Project.

 

G.             “Contributor” means a developer who has made at least one (1) contribution (e.g., source code or documentation) to Project code base.

 

H.             “EMC” shall mean the EMC Corporation, a corporation formed under the laws of the Commonwealth of Massachusetts.

 

I.               “Incubation Project” means a project that is proposed for inclusion in the Project, undergoing active development, but is not included in the release train process.

 

J.               “Initial Creation Date” means the earlier of the date on which contributions are initially accepted pursuant to these Bylaws, or December 8th, 2015.

 

K.              [Reserved]

 

L.              “Majority Vote” or “Majority” means an affirmative vote of more than fifty percent (50%) of the total number of all votes of those who are entitled to vote on a particular matter (telephonically, electronically, or physically, as permitted by applicable law).

 

M.            “Maintainer” means a Person who manages the infrastructure for the Project (incl. the version controls system, and project website) and otherwise organizes the source code in the repository.

 

N.             “Person” or “Persons” means Committer, Contributor, or natural person.

 

O.             “Product Release Vote” means a vote by the TSC to make available Project software in binary or source code form.

 

P.              “Project” means the Project and associated Subproject created under these Bylaws.

 

Q.             “Project Theme” means a technical blueprint or software architecture describing the functionality of the Project or Subproject.

 

R.              “Subproject” means one or more of the Projects’ open source projects that have been duly approved by the TSC, including- Active Projects, Incubation Projects, and Archived Projects.

 

S.              “TSC” means a Technical Steering Committee composed of any Person.





 


  • No labels