Skip to content

Latest commit

 

History

History
91 lines (62 loc) · 6.75 KB

Project Governance Model.md

File metadata and controls

91 lines (62 loc) · 6.75 KB
Raw

中文版

TARS Foundation Open Source Project Governance Model

Code

  • The project produces Open Source software, for distribution to the public at no charge.
  • The project's code is easily discoverable and publicly accessible.
  • The code can be built in a reproducible way using widely available standard tools.
  • The full history of the project's code is available via a source code control system, in a way that allows any released version to be recreated.
  • The provenance of each line of code is established via the source code control system, in a reliable way based on strong authentication of the committer. When third-party contributions are committed, commit messages provide reliable information about the code provenance.

Licenses and Copyright

  • All new inbound code contributions to the Project must be made using an OSI-approved open source license specified for the Project within the “LICENSE” file within the Project’s code repository (the “Project License”).
  • All the Project dependencies mentioned above cannot exceed the license used by the Project.
  • The Project dependencies must be available as Open Source
  • Contributors of Project must sign individual CLA (Contributor License Agreement)
  • All copyrights created by the Project belong to the TARS Foundation

Releases

  • Releases consist of source code and are distributed using standard and open archive formats that are expected to stay readable in the long term.
  • Releases are approved by the Project's PMC (Project Management Committee), in order to make them an act of the Foundation.
  • Releases are signed and/or distributed along with digests that can be reliably used to validate the downloaded archives.
  • The release process is documented and repeatable to the extent that someone new to the project is able to independently generate the complete set of artifacts required for a release.

Quality

  • The project is open and honest about the quality of its code. Various quality and maturity levels for different modules are natural and acceptable as long as they are clearly communicated.
  • The project puts a very high priority on producing secure software.
  • The project provides a well-documented, secure and private channel to report security issues, along with a documented way of responding to them.
  • The project puts a high priority on backwards compatibility and aims to document any incompatible changes and provide tools and documentation to help users transition to new features.
  • The project strives to respond to documented security reports in a timely manner.

Community

  • The community welcomes contributions from anyone who acts in good faith and in a respectful manner and adds value to the project. Contributions include source code and documentation, constructive bug reports, constructive discussions, marketing, and generally anything that adds value to the project.
  • The way in which contributors can be granted more rights such as commit access or decision power is documented in public and archived places, and is the same for all contributors.
  • The project strives to answer user questions in a timely manner.
  • Contributors come from multiple organizations.
  • The project has a well-known homepage that points to all the information required to operate according to this project governance plan.

Consensus Building

  • The project maintains a public list of its contributors who have decision power -- the project's PMC (Project Management Committee) consists of those contributors.
  • Decisions are made by consensus among PMC members and are documented on the project's main communications channel. Community opinions are taken into account but the PMC has the final word if needed.
  • All "important" discussions happen asynchronously in written form on the project's main communications channel. Offline, face-to-face or private discussions that affect the project are also documented on that channel.

Independence

  • The project is independent from any corporate or organizational influence.
  • Contributors act as themselves as opposed to representatives of a corporation or organization.

Note: the TARS Community is unique and requires a different set of metrics that are tailored to its members. Hence, we've made adjustments to this section to reflect our community's characteristics。

TARS Foundation project governance plan setup

One very important aspect of open source software foundation is technology, and it comes from projects. Hence, the TARS Foundation values technical projects and follows the project growth stages: Incubation => Graduation.

  • The Incubation level is for the project that is ready to enter the production environment, but there may be some specifications in the project that are not consistent with the Foundation’s terms. The project usually needs to improve its documentation in terms of translation, document quality, project CLA, project license, etc.

  • The Graduation level is for the project that reaches maturity and fulfills the Foundation charter.

Specific requirements are as follow:

Incubation Stage

To be accepted in the Incubation stage, a project must:

  • Have multiple TOC members to step forward as sponsors to enter incubation
  • Follow the TARS Foundation Code of Conduct
  • Adhere to TARS Foundation IP Policy (including trademark transferred)
  • List their incubation status prominently on website/readme
  • A clear versioning scheme.
  • Meet at least the first point of each category in the project criteria above.

Graduation Stage

In addition to fulfilling the Incubation requirements, the project must meet all the requirements in the project criteria in order to become a graduated project.

Project Donation Process

  • Submit project proposal through a form.
  • TOC reviews the proposal during a regular meeting and schedules a time for presentation in the next meeting.
  • The PMC or important committer(s) of the proposed project is/are invited to attend and present the proposal to the TOC members.
  • The TOC members may engage with the project to ask further questions along with the PMC or important committer(s).
  • TOC will vote to pass the submitted project proposal into incubation with a simple majority rule.

Project Incubation Process

  • When the incubating project meets all the requirements, it can apply to be a graduated project. It needs to demonstrate whether the project realizes all the criteria and the degree of realization in an Assessment file on the project page. The TOC will review and vote to decide if the project reaches graduation.