TSC Elected Members

Technical Representatives consist of Active Technical Contributors (ATC).  ATCs are defined as having "At least one approved/merged patch in one release is required in the preceding 12 months prior to the election." This will be determined by the union of a Gerrit query and a GitHub query. The Gerrit query will be run against both https://review.opencontrail.org and https://gerrit.tungsten.io until the former has been retired for a full 12 months. Since a Gerrit change may consist of multiple patch sets, but only the final patch set that is merged enters into the repository there may be an ambiguity as to who the contributor is. For the purposes of ATC status, the author of the final patch set will be considered to be the contributor of the merged change. The TSC will have the right to inspect the script/query which is used by the Linux Foundation to pull the list of ATCs.

Community Representatives consist of Active Community Contributors.  ACCs are approved by the TSC as having done non-technical work.  This is comprised of members that have been active on the mailing lists, confluence, and JIRA. The TSC will then vote to approve or decline the individual’s ACC status. Such a designation is good for one year and must be renewed by the TSC annually to remain current.

The TSC is responsible for:

1. Setting high level architecture goals and coordinating overall project architecture and technical direction

2. Selecting technology stack, software features and supported hardware including

3. Approving project or system proposals (including, but not limited to, incubation, deprecation, and changes to a sub-project’s scope);

4. organizing sub-projects and removing sub-projects;

5. Developing Project use cases;

6. Defining and monitoring Project technical processes and interfaces with third party code and external projects including creating sub-committees or working groups to focus on cross-project technical issues and requirements;

7. Overseeing the Infrastructure Working Group other TSC working groups;

8. Appointing representatives to work with other open source or open standards communities;

9. Establishing community norms, workflows, issuing releases, and security issue reporting policies;

10. Approving and implementing policies and processes for contributing (to be published in the CONTRIBUTING file) and coordinating with other project committees to resolve matters or concerns that may arise as set forth in Section 7 of this Charter;

11. Engaging in discussions, seeking consensus, and where necessary, voting on technical matters relating to the code base that affect multiple projects;

12. Setting target dates for software development and testing;

13. Coordinating any marketing, events, or communications regarding the Project with the Manager of LF Projects and the Marketing Advisory Council of the LF Networking Fund of The Linux Foundation (“LFN”);

14. Establishing a vetting process for maintaining security and integrity of new and/or changed code base and documentation, including vetting for malicious code and spyware; and

15. Establishing a security issue reporting policy and resolution procedure.