CNTT and OPNFV TSC Responsibilities

Owned by Jim Baker
Last updated: Oct 08, 2020 by Scott Steinbrueck
7 min read

OPNFV

OPNFV's Board-Approved Charter is in a 2018 PDF-doc.  This doc begins with a Mission and Scope (updated in 2020, Approved, and available elsewhere) and then provides the TSC Responsibilities and other details. OPNFV has a TSC Procedures Doc, which has some overlap with the OPNFV Charter. A Community Election Procedure doc also has some overlapping requirements and more details.

  1. "The Technical Steering Committee (the “TSC”) will be responsible for all technical oversight of the open source Project."  (the charter goes on to describe specific responsibilities and procedures)

  2. The TSC conducts community elections, according to Community Election Procedure including

    1. determining TSC composition,

    2. determining eligibility criteria for TSC membership,

    3. approving the election calendar, and

    4. revising the election procedure from time to time.

    5. the Election method (from TSC Procedures Doc):

      1. For election of persons (TSC chairs, Project Leads, etc.) a multiple-candidate method should be used, e.g.:

        1. Condorcet: Election method that elects the candidate that would win by majority rule in all pairings against the other candidates or

        2. Single Transferable Vote: A voting system designed to achieve proportional representation through ranked voting in multi-seat constituencies

        3. Multiple-candidate methods reduce to simple majority voting when there is only one position to be filled.

  3. The TSC elects a TSC Chair, who will preside over meetings of the TSC and will serve until their resignation or replacement by the TSC. The TSC Chair

    1. will serve as the Project’s representative to the Technical Advisory Committee (“TAC”) of the LF Networking Fund of The Linux Foundation (“LFN”),

    2. will be the primary communication contact between the Project and the LFN

    3. will have responsibility for providing input on Project resource requirements to the TAC.

    4. also, will provide project health reports to the TAC, as requested.

  4. NOTE: At present, the OPNFV TSC has established the additional roles of TSC Vice-Chair and Strategic Planning Committee (SPC) Representative. Both roles are elected from the TSC membership using the same procedure as TSC Chair election.

  5. TSC Voting and Quorum at meetings

    1. While the Project aims to operate as a consensus based community, if any TSC decision requires a vote to move the Project forward, the voting members of the TSC will vote on a one vote per voting member basis.

    2. Quorum for TSC meetings requires at least a majority of all voting members of the TSC to be present. The TSC may continue to meet if quorum is not met, but will be prevented from making any decisions at the meeting.

      1. Quorum requirements are also based on TSC member attendance, See the 2020 Quorum reduction vote page

      2. The TSC Procedures Doc allows Proxies for TSC members who know in advance that they cannot attend a meeting. The current TSC Proxy Policy was updated by TSC agreement in January 2020.

    3. Decisions at meetings require a majority of TSC members present in the Quorum.  Decisions made electronically ("wiki-vote") require a majority of all TSC members.

  6. Sub-Project Oversight: The TSC may

    1. establish work flow procedures for the submission, approval, and closure/archiving of projects, 

    2. set requirements for the promotion of Contributors to Committer status, as applicable (see the TSC Procedures Doc doc, section 4, for more project governance details), and 

    3. amend, adjust, refine and/or eliminate the roles of Contributors, and Committers, and create new roles, and publicly document any TSC roles, as it sees fit.

  7. Additional TSC Responsibilities:

    1. .coordinating the technical direction of the Project;

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

      1. The development process will provide for projects to follow the life-cycle process as described in the TSC’s project lifecycle document. The development process will include a process for the TSC to oversee and approve changes in the lifecycle of a project,which will include consideration of the following criteria: (from the TSC Procedures Doc )

        1. Cleanliness of code base.

        2. Ample and diverse Contributors and Committers to assure vitality of the project.

        3. Stability (e.g. presence of test suites and use of an appropriate source-code control system).

        4. Predictability of releases.

        5. Alignment with OPNFV’s goals and priorities

    3. organizing sub-projects and removing projects;

    4. creating sub-committees or working groups to focus on cross-project technical issues and requirements;

    5. appointing representatives to work with other open source or open standards communities;

    6. establishing community norms (including code of conduct), workflows, issuing releases, and security issue reporting policies;

    7. approving and implementing policies and processes for contributing (to be published on wiki.opnfv.org) and coordinating with the Series Manager to resolve matters or concerns that may arise as set forth in Section 7 of this Charter;

    8. amending the TSC Procedures Document and other policies and documents of the TSC;

    9. approving license exceptions under Section 7 of the Charter;

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

    11. coordinating any marketing, events, or communications regarding the Project with the LF Projects Manager or their designee.

  8. Charter Amendments: The charter may be amended by a two-thirds vote of the entire TSC and is subject to approval by LF Projects.

  9. Responsibilities wrt OVP

    1. approval of the scope of the OVP infrastructure badging program

    2. review and approval of exemption requests

CNTT 

Formal Definitions

  • "Charter" links

  • Technical Steering Committee

    • The Technical Steering Committee (the “TSC”) is responsible for general oversight of the CNTT Projects (aka Workstreams).

    • The TSC is responsible to meeting one of CNTT's core principals is to stay current with new and emerging trends in the industry, including how to integrate new technologies and processes. In pursuit of this Goal the TSC approves:

      • the creation of a new CNTT Release and Milestones

      • new Workstreams (WS),

      • termination of a WS, and

      • the creation of any short-term teams focused on an emerging technology or field of interest to CNTT

    • The TSC is led of a Lead and up to 2 (two) Co-Leads and are elected as per CNTT election policies. The Nomination and Selection document defines the process for selecting the TSC Leads and Co-Leads. The document also specifies the Length of Term which is 12 calendar months and will start typically in February each year and end around the same time the year after. The exact dates and timing might vary to accommodate CNTT releases and workshops.

    • The TSC is composed of Workstream Leads/Co-Leads (Nomination and Selection specifies the process for selecting the WS Leads and Co-Leads).

    • The TSC Lead/Co-Leads are responsible for arranging and leading regular TSC meetings with a formal agenda and published minutes.

    • The TSC is open to all but formally participants belong only to CNTT member companies.

    • The TSC and constituent WSs follow Concensus-based Decision Making

    • The TSC Lead is responsible for monitoring progress of the projects and their activities (Github Issues and Pull Requests (PR) for inactivity. Any inactivity is pointed to the WS Leads and if not addressed are brought for discussion at the regular TSC Meetings.

    • The TSC Lead is the Code Owner in Github of all Technical Workstreams and hence is authorized for final approval and merger of completed PRs. Since the WS Leads are Code Owners of the activities for their WS, the TSC Lead will normally only act on a PR whose author is the WS Lead (and hence cannot approve and merge) or where exceptional circumstance require the TSC Lead to approve the activities.

    • The TSC resolves any inter-WS issues following a consensus-based approach.

    • The TSC defines policies or changes to existing policies that affect multiple WSs.

  • Technical Workstream

    • Workstreams (WS) are responsible for all technical activities related to their approved nature of work.

    • Workstreams are responsible to define the work to be performed for a particular CNTT release, and the management and tracking of progress of the work.

    • Workstream Leads (WSLs) have responsibilities and perform functions similar to the TSC Lead for their Workstreams including holding WS Meetings, approval and merge of technical content changes for their WS.

General activities

  • Weekly TSC Meeting where WSLs, contributors discuss ongoing community activities.  Types of topics may vary, here are some examples:

    • Current release centered around current and upcoming milestones (see below for more detail)

    • Any "issues" that cannot be resolved within the workstream can be raised at TSC for more general cross-workstream discussion and potentially resolved

    • Upcoming conference / schedule

    • Meld activities, information sharing

    • Technical interactions with non-CNTT entities

    • Various announcements

    • Decisions - current release "Elbrus" was decided via wiki poll

  • Release Details

  • Workstreams

    • Reference Model

    • Edge

    • 1-stream (RA-1, RI-1, RC-1) - Openstack based, virtual machines

    • 2-stream (RA-2, RI-2, RC-2) - Kubernetes-based, containers

    • Weekly meetings - each workstream has their own meeting to review open working items, discuss various related topics

    • Topics are often discussed offline during the week via Github issues.  Typically these topics are geared towards a documentation update via Github Pull Request, and as such are "linked" (so that when the PR is merged, the corresponding issue is automatically closed - this is typical workflow in Github)

TSC Lead(s) - activities

  • Current Lead / Co-Leads:  @Scott Steinbrueck @Walter.kozlowski @Ulrich Kleber

  • TSC Meeting - Weekly

    • Create agenda

    • Moderate TSC Meeting - keep to the time schedule, enable fair/open dialog, track notes, pull attendance from Zoom reports

  • Governance meeting - Weekly

    • Prepare summary

    • Represent the summary at meeting - with current status and activities

    • Ensure activities and action items properly flow back and forth between TSC and GOV

  • Github activities - ongoing, periodically

    • Github project "Technical Steering " - manage and groom issues/pulls

    • Review/Approve/Merge PRs as "codeowner" - When the WSL is the author of a PR, the label "merge-ready" is applied as a signal for TSC Lead review/approve/merge.

    • General grooming of all issues and PRs, when needed (look for old / stale items)

  • Release planning

    • (Milestone 1) Establish the release page / name / schedule / scope draft

    • (Milestone 2) Ask WSLs to fill in high level scope list (create a Github issue, @mention WSLs as a task)

    • Then track each release milestone, grooming towards milestone completion, nudging WSL to complete issues/pulls

  • General

    • Represent CNTT TSC as needed

    • Attend other meetings, explain as needed

    • Prepare materials as needed

    • Interviews, blogs, email exchanges, etc