Skip to content
Permalink
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
144 lines (72 sloc) 10.8 KB

The Linux Foundation

CHAOSS – Community Health Analytics Open Source Software

Project Charter (the “Charter”)

Effective: Sept 1, 2017

Last Updated: March 15, 2019

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 and Working Groups.

  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). Committee and Working Group 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 Committees that may focus on code or non-code efforts to advance the Mission (such as standards, specifications, and/or architecture). The 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 collection 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.

  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:

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

    2. 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 GB 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. 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 to focus on cross-project issues and requirements;

    6. facilitating communication and collaboration among 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 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 Committee meetings requires two-thirds of all voting members of the GB or a Committee, as applicable. The GB 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 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 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.

  4. The current Project code of conduct can be found at (https://chaoss.community/about/code-of-conduct/).

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.
You can’t perform that action at this time.