Skip to content

Latest commit

 

History

History
216 lines (150 loc) · 7.58 KB

CHARTER.md

File metadata and controls

216 lines (150 loc) · 7.58 KB
Raw

SHIELD Project Charter

This charter is effective June 1st, 2019.

A. Mission

The mission of the SHIELD Project is to:

  1. produce a scalable, reliable, cloud-native data protection solution for providing backup and restore capabilities to cloud platforms like Kubernetes and Cloud Foundry;

  2. establish an implementation-agnostic ecosystem for the creation and deployment of pluggable data- and storage-system integrations for said data protection solution; and

  3. Advocate and evangelize the use and implementation of said data protection solution.

B. Governance Board

  1. The Governance Board shall be responsible for overall oversight of the Project and coordination of the efforts of any Technical Committees and Working Groups.

  2. The initial governance board will be appointed by the current project maintainer, James Hunt, at the time of the adoption of this charter. Following this, the Governance Board will implement procedures and methodologies for the selection of Governance Board voting members from the contributing community.

  3. The Governance Board will encourage transparency (e.g. publish public minutes). Committee and Working Group meetings will be open to the public, and can be conducted electronically, via teleconference, or in person.

  4. The Governance Board has the authority to create Committees that may focus on code or non-code efforts to advance the Mission (such as standards, specifications, and/or architecture).

  5. Working Groups are established and maintained by Project contributors to advance Project work. Working Groups focus on specific metric, methodological, ethical, and technical issues associated with open source project health.

  6. Roles: Committees and Working Groups involve Contributors and Maintainers:

    • Contributors: anyone in the community that contributes code, documentation, use cases, standardized metrics, or other community activities related to the Project;

    • Maintainers: Contributors who have the ability to commit directly to a Project’s repository and are responsive to contributions or changes from Contributors. Maintainers are listed in the README of each repository.

  7. Participation in the Project, including contributions to any Committee or Working Group, is open to all under the terms of this Charter.

  8. The Governance Board may (1) establish work flow procedures for the submission, approval, and closure/archiving of Committees and projects of Committees, (2) set requirements for the promotion to or removal from Committee roles, as applicable, and (3) amend, adjust, refine and/or eliminate the roles as it sees fit.

  9. Responsibilities: The Governance Board shall also be responsible for:

    1. coordinating the direction of the Project;

    2. stablishing any project policies, including for the addition and removal of Maintainers and documenting any requirements for official project releases;

    3. approving project or system proposals (including, but not limited to, incubation, deprecation, and changes to a project’s charter or scope);

    4. establish policies related to intellectual property;

    5. creating Committees to focus on cross-project issues and requirements;

    6. facilitating communication and collaboration among Technical Committees and Working Groups;

    7. communicating with external and industry organizations concerning Project matters;

    8. appointing representatives to work with other open source or open standards communities;

    9. establishing community norms, workflows, or policies including processes for contributing (to be published on the Project web site), issuing releases, and security issue reporting policies; and

    10. discussing, seeking consensus, and where necessary, voting on matters relating to the code base that affect multiple projects.

C. Voting

  1. While it is the goal of the Project to operate as a consensus based community, if any Governance Board or Committee decision requires a vote to move forward, the respective voting members shall vote on a one vote per voting member basis.

  2. Quorum for Governance Board and Committee meetings requires two-thirds of all voting members of the Governance Board or a Committee, as applicable. The Governance Board or any Committee may continue to meet if quorum is not met, but are prevented from making any decisions at the meeting. If quorum is not met, a second meeting with the same agenda can be called after two weeks to which quorum will become 1/2 of all voting members.

  3. Except as provided in Section (E)(2)(iii) and (F)(1), decisions by vote at a meeting shall require a simple majority vote of those in attendance, provided quorum is met. Decisions made by electronic vote without a meeting shall require a simple majority of all voting members of the Governance Board or a Committee, as applicable.

  4. In the event a vote cannot be resolved within a Committee, the Governance Board may decide the matter.

D. Openness & Inclusivity

  1. All participants should encourage open participation from any organization able to meet the participation requirements, regardless of competitive interests. Put another way, the community may not seek to exclude any participant based on any criteria, requirements, or reasons other than those that are reasonable and applied on a non-discriminatory basis to all participants.

  2. The Governance Board may adopt a fair, reasonable, and non-discriminatory Project code-of-conduct.

  3. The Project will operate in a transparent, open, collaborative, and ethical manner at all times.

  4. The output of all Project discussions, proposals, timelines, decisions, and status will be made open and easily visible to all.

E. Intellectual Property

  1. The Project seeks to integrate and contribute back to other open source projects within the mission set forth in Section (A) above. The Project also seeks to assure that relevant patentable innovations are made available without the need for any patent licenses. Based on this goal for the Project, the development community will:

    1. conform to all license requirements of the open source projects leveraged by the Project (such projects, collectively, "Upstream Projects"); and

    2. maximize opportunities for compatibility with other projects that might be leveraged by the Project.

  2. Except as described in Section (E)(3), all code contributions to the Project are subject to the following:

    1. All new inbound code contributions must be accompanied by a Developer Certificate of Origin sign-off (http://developercertificate.org).

    2. All contributions of code will be received and made available under the MIT License.

    3. The Governance Board may approve the use of an alternative license for inbound or outbound contributions on an exception basis. Exceptions require a two-thirds approval of the entire Governance Board.

  3. Upstream Project code contributions not stored within the Project’s main code repository must comply with the contribution process and license terms for the applicable Upstream Project.

F. Amendments

  1. This charter may be amended by a two-thirds vote of the entire Governance Board.

CHANGELOG

  • June 11th, 2019 - Adopted SHIELD Project Charter.