Skip to content

Latest commit

 

History

History
139 lines (70 loc) · 10.9 KB

project-charter.md

File metadata and controls

139 lines (70 loc) · 10.9 KB
Raw

The Linux Foundation

CHAOSS – Community Health Analytics Open Source Software

Project Charter (the “Charter”)

Effective: Sept 1, 2017

This Charter sets forth the responsibilities and procedures for technical contribution to, and oversight of, the CHAOSS – Community Health Analytics Open Source Software Project (the “Project”) within The Linux Foundation. Contributors to the Project must comply with the terms of the Charter as well as any applicable policies of The Linux Foundation.

1. The Project Mission

The mission of the Project is to:

  1. produce integrated, open source software for analyzing software development, and definition of standards and models used in that software in specific use cases;

  2. establish implementation-agnostic metrics for measuring community activity, contributions, and health; and

  3. optionally produce standardized metric exchange formats, detailed use cases, models, or recommendations to analyze specific issues in the industry/OSS world.

2. Governance Board

  1. The Governance Board (the “GB”) shall be responsible for overall oversight of the Project and coordination of the efforts of any Technical Committees.

  2. At inception of the Project, the GB voting members consists of those individuals identified on the Project website (https://chaoss.community). Following inception of the Project, the GB will implement procedures and methodologies for the selection of GB voting members from the contributing community.

  3. The GB will encourage transparency (e.g. publish public minutes). Technical Committees meetings will be open to the public, and can be conducted electronically, via teleconference, or in person.

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

  5. At the launch of the project, the initial Technical Committees of the project are the “Software Committee,” responsible for technical oversight of inbound and outbound coding projects, and the “Metrics Committee,” responsible for the determination of technology-agnostic metrics and standards to be developed  by the Project, and  the GB shall provide coordination of the interrelationship between the Software and Metrics Committees. At inception of the Project, the voting members of the each Technical Committee consist of those individuals identified on the Project website (http://[domain name]). Following the inception of the Project, each Technical Committee is expected to implement procedures and methodologies for the selection of voting members of the Technical Committees.

  6. Roles: Technical Committee projects will generally involve Contributors and Maintainers:

    1. Contributors: anyone in the community that contributes code, documentation, use cases, standardized metrics, or other technical artifacts to the Project;

    2. Maintainers: Contributors who have the ability to commit directly to a Project’s main branch, repository, or wiki page and are responsive to contributions or changes from Contributors.

  7. Technical participation in the Project, including technical contributions to any Technical Committee, is open to all under the terms of this Charter. The initial Maintainers will be the list of Maintainers identified in the Project’s code repository or wiki site.

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

  9. The GB shall annually elect a GB Chair and GB Co-Chair from representatives involved in either or both the Software or Metrics Committees, such that both the Software and Metrics Committees will be represented by the Co-Chairs. The Chair and Co-Chair will set the agenda and preside over meetings of the GB.

  10. Responsibilities: The GB shall also be responsible for:

    1. coordinating the direction of the Project;

    2. establishing any project policies, including for the addition and removal of Maintainers and documenting any requirements for official project releases (Software or Metrics);

    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 or working groups to focus on cross-project issues and requirements;

    6. facilitating communication and collaboration among all Technical Committees;

    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;

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

    11. coordinate any marketing, events, or communications with The Linux Foundation.

3. GB Voting

  1. While it is the goal of the Project to operate as a consensus based community, if any GB or Technical 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 GB and Technical Committee meetings requires two-thirds of all voting members of the GB or a Technical Committee, as applicable. The GB or any Technical Committee may continue to meet if quorum is not met, but are prevented from making any decisions at the meeting.

  3. Except as provided in Section 8.b(iv) and 9.a, decisions by vote at a meeting shall require a majority vote of those in attendance, provided quorum is met. Decisions made by electronic vote without a meeting shall require a majority of all voting members of the GB or a Committee, as applicable.

  4. In the event a vote cannot be resolved within a Technical Committee, the GB may decide the matter. In the event that any vote cannot be resolved by the GB, any voting member on the GB is entitled to refer the matter to The Linux Foundation for assistance in reaching a decision.

4. Antitrust Guidelines

  1. All participants in the Project must abide by The Linux Foundation Antitrust Policy available at http://www.linuxfoundation.org/antitrust-policy.

  2. 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.

5. Code of Conduct

  1. The GB may adopt a fair, reasonable, and non-discriminatory Project code-of-conduct, with approval from The Linux Foundation as outlined below.

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

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

6. Budget and Funding

  1. The GB will coordinate any budget or funding needs with The Linux Foundation. Organizations participating may be solicited to sponsor Project activities and infrastructure needs on a voluntary basis.

  2. The Project will not raise any funds and will be supported on a volunteer basis by the Project participants.

  3. Under no circumstances will The Linux Foundation be expected or required to undertake any action on behalf of the Project that is inconsistent with the tax-exempt purpose of The Linux Foundation.

7. General Rules and Operations

The Project should:

  1. engage in the work of the project in a professional manner consistent with maintaining a cohesive community, while also maintaining the goodwill and esteem of The Linux Foundation in the open source software community;

  2. respect the rights of all trademark owners, including any branding and usage guidelines;

  3. engage The Linux Foundation for all Project press and analyst relations activities;

  4. upon request, provide information regarding Project participation, including information regarding attendance at Project-sponsored events, to The Linux Foundation; and

  5. coordinate with The Linux Foundation in relation to any websites created directly for the Project.

8. Intellectual Property Policy

  1. The Project seeks to integrate and contribute back to other open source projects within the mission set forth in Section 1 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 8.c, 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 GNU General Public License, Version 2 or later, or Version 3 or later.

    3. All contributions to implementation-agnostic metrics and standards, including associated scripts, SQL statements, and documentation, will be received and made available under the MIT License (https://opensource.org/licenses/MIT).

    4. The GB 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 GB.

  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

  4. The Project may engage The Linux Foundation to determine the availability of, and register, trademarks, service marks, which shall be owned by The Linux Foundation. Any Project-related domain names and trademarks will be owned by The Linux Foundation and any pre-existing Project-related domain names or trademarks shall be transferred to The Linux Foundation for use by the Project.

9. Amendments

  1. This charter may be amended by a two-thirds vote of the entire GB, subject to approval by The Linux Foundation to ensure the amendment is in-line with non-profit requirements and open source principles.