Project Decisions Making Process
Technical Committee (TC) of the 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
Release manager will propose milestones and associate a timeline to the delivery for a release. PTLs will coordinate with Release Manager to track progress of deliverables proposed and accepted corresponding to their Projects.
PTLs and Release Manager should operate on consensus for following
- Drop a blueprint out of a release in the event of unacceptable delays or due to bad quality of work delivered
- Propose a delay in the scheduled release date to TSC in event of time need to:
- Accomodate a feature delivery important for the release
- Achieve reasonably release stablity