AI: Dig up previous PTL definition; incorporate into elections proposal?
Projects Summary
Projects that are either required by most applications for dependency reasons or are mature, stable, responsive projects that are consistently able to take part in releases without jeopardizing them should be considered Managed. Managed Projects will receive additional support from the test and release teams to further their stability and make sure Tungsten Fabric releases go out on-time. To enable this extra support, Managed Projects will be given less autonomy than projects which have no dependencies.
Managed Projects for Dependency Reasons
Some projects are required by almost all other Tungsten Fabric projects. These projects must be Managed for it to support almost every Tungsten Fabric use case. Such projects will not have a choice about being in the Managed Project category, the TSC will decide they are critical to the Tungsten Fabric platform and include them. They may not always meet the requirements that would normally be imposed on projects that wish to join the Managed Projects. Since they cannot be kicked out of the release, the TSC, test and release teams will do their best to help them meet the Release Requirements. This may involve giving Linux Foundation staff temporary committer rights to merge patches on behalf of unresponsive projects, or appointing committers if projects continue to remain unresponsive. The TSC will strive to work with projects and member companies to proactively keep projects healthy and find active contributors who can become committers in the normal way without the need to appoint them in times of crisis.
Requirements for Managed Projects
Healthy Community
Managed Projects should strive to have a healthy community.
Responsiveness
Managed Projects should be responsive over email, Gerrit, JIRA and in regular meetings.
All committers should be subscribed to their project’s mailing list and the release mailing list. All PTLs should be subscribed to the TSC and Discuss mailing lists.
For the following particularly time-sensitive events, an appropriate response is expected within two business days.
- Release candidate feedback.
- Major disruptions to other projects where a Jira weather item was not present and the pending breakage was not reported to the release mailing list.
If anyone feels that a Managed Project is not responsive, a grievance process shall be implemented in JIRA to clearly handle the situation and keep a record for future consideration by the TSC.
Active Committers
Managed Projects should have sufficient active committers to review contributions in a timely manner, support potential contributors, keep CSIT healthy and generally effectively drive the project.
If a project that the TSC deems is critical to the Managed Release is shown to not have sufficient active committers the TSC may step in and appoint additional committers. Projects that can be dropped from the Managed Release will be dropped instead of having additional committers appointed.
Managed Projects should regularly prune their committer list to remove inactive committers, following the Committer Removal Process.
TSC Attendance
Managed Projects are required to send a representative to attend TSC meetings. This generally is the PTL.
To facilitate quickly acting on problems identified during TSC meetings, representatives must be a committer to the project they are representing. A single person can represent any number of projects.
Representatives will make the following entry into the meeting minutes to record their presence:
@name - Project
TSC minutes will be scraped each release to gather attendance statistics. If a project does not provide a representative for at least 80% of TSC meetings a grievance will be filed for future consideration.
Checkpoints Submitted On-Time
Managed Projects must submit the information required for release checkpoints on-time. Submissions must be correct and adequate, as judged by the release team and the TSC. Inadequate or missing submissions will result in a grievance.
Depend only on Managed Projects
Managed Projects should only depend on other Managed Projects.
Documentation
Managed Projects are required to produce a user guide, developer guide and release notes for each release.
Project Roles
Contributor
A Contributor is someone who contributes to a project. Contributions could take the form of code, code reviews, Wiki and documentation contributions, Jira activities or other artifacts. Contributors work with a project’s Committer and the project’s sub-community. A Contributor may be promoted to a Committer by the project’s Committers after demonstrating a history of contributions to that project.
Committer
For each project, there is a set of Contributors approved for the right to commit code to the source code management system (the “Committers”) for that project.
- Committer rights are per project; being a Committer on one project does not give an individual committer rights on any other project.
- The Committers will be the decision-makers on all matters for a project including design, code, patches, and releases for a project.
- Committers are the best available individuals but usually, work full-time on components in active development.
- All project committers information such as name, company, and Contact information should be documented in the wiki under the project.
In order to preserve meritocracy in the selection of Committers while ensuring diversity of Committers, each initial project is encouraged to take on at least two Committers from different companies (subject to meritocracy).
Project Technical Leader
A project is required to elect a Project Technical Leader (“PTL”). The PTL acts as the de facto spokesperson for the project (feature projects and integration projects).
Project Technical Leader Candidates
Candidates for the project’s Project Technical Leader will be derived from the Committers of the Project.
Candidates must self nominate.
Project Technical Leader Voters
Only Committers for a project are eligible to vote for a project’s Project Technical Lead.
Project Technical Leader Election Mechanics
An election for Project Technical Leader occurs when any of the following are true:
- The project is initially created
- The Project Technical Leader resigns his or her post
- The majority of committers on a project vote to call a new election
- One year has passed since the last Project Technical Leader election for that project
Project Operations
Project Decisions Making Process
Technical and release decisions for a project should be made by consensus of that project’s Committers. If consensus cannot be reached, decisions are taken by a majority vote of a project’s Committers. Committers may, by majority vote, delegate (or revoke delegation) of any portion of such decisions to an alternate open, documented (wiki), and traceable decision-making process.
Committer Lifecycle
Adding Committers
- Initial Committers for a project will be specified at project creation
- Committer rights for a project are earned via contribution and community trust. Committers for a project select and vote for new Committers for that project.
- New Committers for a project should have a demonstrable established history of meritocratic contributions.
Adding Committers to moribund projects
In the event that a project has no active committers (e.g., due to resignations, etc.), the TSC may appoint an interim Committer from a project’s active Contributors. This term shall last until the next release date, after which time the Committer must stand for election from amongst other Committers on the project to maintain his or her status. In this special case, approval requires a majority of committers who respond within two weeks. If no one responds by the deadline, then the committer status is approved. This provision allows a project to continue development following an unexpected change in personnel.
The method by which the TSC appoints an interim Committer is first by request to the TF-TSC email list indicating the request to appoint an interim Committer for a project. After the reception of such an email, the normal TSC decision process applies.
Removing Committers
A Committer may voluntarily resign from a project by making a public request to the PTL to resign (via the project email list and cc to tsc@lists.tungsten.io ).
A Committer for a project who is disruptive, or has been inactive on that project for an extended period (e.g., six or more months) may have his or her Committer status revoked by the project’s Project Technical Leader or by 2/3 supermajority vote of the project’s committers.
The Project Technical Leader is responsible for informing the Technical Steering Committee (TSC) of any committers who are removed or resigned via the email list: tsc@lists.tungsten.io.
Former committers removed for reasons other than being disruptive may be listed as ‘Emeritus Committers’. That title expresses gratitude for their service but conveys none of the privileges of being a Committer.