Projects transcend modules and components, as a Collection of work undertaken to deliver a well-defined goal. The goal can be anything ranging from feature induction, integration activity or support activity defining overall scope of the project.

Induction of new project needs to be brought as a proposal to the TSC.

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.

Committers

All committers from participating modules are listed as project committers.

• Committer rights are per module; being a Committer on one module does not give an individual committer rights on any other module.
• The Committers will work with TSC and PTLs to implement and enforce decisions of these bodies and ensure that project design and code complies with the architecture and release and code guidelines.
• Committers are responsible for delivering new code to the project as well as helping Contributors through review and other guidance, and must actively participate in the project to maintain their status.
• Committers are responsible for the quality of the code that they commit, they must ensure sufficient test coverage for any piece of code they commit to the project.
• All project committers information such as name, company, and Contact information should be documented in the wiki under the project.

Each project/module should strive for diversity of Committers representing different organizations as well as individuals. However Committer promotions are based on meritocracy and prioritize project/module contributions above other considerations.

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.

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.

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.

Initial PTL for a project will be specified at project creation

PTL Election Mechanics

PTL Candidates

Candidates for the project’s Project Technical Leader will be derived from the Committers of the Project.  Candidates must self nominate.

Voter Eligibility

Only Committers for a project are eligible to vote for a project’s Project Technical Lead. TSC will formally induct the PTL to the Project

PTL Election

An election for Project Technical Leader occurs when any of the following are true:

• The project is initially created
• The Project Technical Leader resigns their 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.

Induction of New Project

Proposal for new projects needs to be submitted for TSC review and approval as per Proposing a new Project (template subjected to approval)

Project Operations

Project Decisions Making Process

TSC is responsible for setting technical TF goals, identifying use cases, setting release guidelines and milestones. It will work with PTLs to develop and maintain project high level and detailed architecture. Project Committers will work within this technical and release guidance to deliver individual projects.

Within the project, Committers should operate by general consensus. If consensus cannot be reached within a reasonable timeframe, decisions are taken by 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, and traceable decision making process.

Spec/Blueprint Submission

A blueprint is an initial version of a proposal for the new feature or problem solution proposed in a scope of a Project.

Blueprint proposal can be submitted in scope of a project with following:

• A registered JIRA EPIC ticket reflecting requested blueprint/feature in the backlog of the TF Jira Feature project with following data
  • Meaning full name and description
  • Target release
  • Assignee will be Blueprint/Feature Lead - person responsible for delivering all needed documentation, explanations, and also responsible for proper reflecting of achieved milestones of requested change in the TF Jira Feature project
• Detailed information as per Blueprint template to be submitted for review at tf-specs with TF Jira ID
• A suppliment optional detailed document, that talks about the design or other aspects enabling community members and reviewer to obtain better understand the proposal
• Feature Lead can mark the blueprint ready for review by moving Jira ticket to Selected for TSC discussion column in the Kanban board of the TF Jira Feature project.

Spec/Blueprint Review

All Blueprints needs be discussed/presented over community call. PTL associated with the project is responsible to review and approve the submitted blueprints.

Code Review Submission

Any Contributor submitting a code for review needs to ensure following in the commit message:

• Associated JIRA ID from Feature or Bugs
• DCO (Developer Certificate of Origin) - committer sign-off
• Detailed information on solution (problem addressed in commits for bugs)

Code Review

Code changes submitted will be subjected to review and approval from committers/PTLs of the Project 

• Code changes scoped within a single module can be committed by an approval from either a PTL or module Committer
• Code changes spanning across multiple modules can be committed by an approval from a PTL of the associated Project or approved by atleast two committers from different modules

* For faster turn arround time, Contributors can choose to split/organise the Code changes in a way to submit separate reviews for individual modules

Release Management

Checkpoints Submitted On-Time

Release manager and PTLs will coordinate to ensure work submissions in projects meets the milestones set as per TSC approved release plans.

Projects must submit the information required for release checkpoints on-time corresponding to associated milestones. Submissions must be correct and adequate, as judged by the release manager and TSC. Inadequate or missing submissions will result in grievance.

PTLs will coordinate with Release Manager to track delays with respect to achieving certain milestones of a project, and propose a plan for any of the following action:

• Dropping of a blueprint out of a release in event of unacceptable delays or due to bad quality of work delivered
• Propose a work plan to cover on the missed milestone dates
• Propose to accomodate delay needed to:
  • Achieve important feature deliver
  • Achieve reasonable release stability

Documentation

Projects are required to produce a user guide, developer guide and release notes for each release.