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
  • No labels

23 Comments

  1. Walter Kozlowski

    Thanks Al Morton for a comprehensive extract from OPNFV charter and surrounding documentation.  Most of this can be re-use in my view for the new organization.  In CNTT the role of the WS Leads is very important as each one of them is responsible for a separately defined deliverable (RM, RA-1, RA-2, etc).  The CNTT WS Leads are by definition members of TSC. There must be an OPNF equivalence with PTLs.  Because of the importance of   this topic, I think we need to agree how such Leads are elected and clarify that they will become automatically members of TSC.  There are the CNTT procedure regarding such elections and also refilling the position in case of resignation, etc.

     Scott Steinbrueck, are you going to fill in information in the CNTT section?

  2. Al Morton

    Good catch on 9. Responsibilities wrt OVP, Georg Kunz !  The TSC's work is never done...

  3. Georg Kunz

    Thank you Al Mortonfor the detailed input. Reading through the material and considering Walter Kozlowski's comment, we might want to go in, as a next step, and separate day-to-day operational duties of the groups (e.g., project reviews, voting, quorum) from governance aspects (e.g. roles, election procedures, etc.). While both must be considered, there is an overlap with the governance group regarding roles, composition, election procedures etc.

    Moreover, Walter Kozlowski, whether or not work stream leads automatically become members of the TSC is an interesting question as it blurs the line between PTL elections conducted within a project and TSC membership election which is a community wide process. Looking at established best practices in other open source projects, there is no automatic TSC membership for PTLs - at least I am not aware. An automatic membership also has an impact on the size of the TSC which we want to avoid: assuming a sudden sprawl in new projects, this would result in a shift of membership on the TSC. That said, it turns out in practice that the PTLs get elected for good reasons (→ leadership & contributions) which make them natural high profile candidates for the TSC membership positions.

    1. Pankaj Goyal

      Georg Kunz as you stated PTLs get elected to TSC but should that be formalized even if that is as ex officio membership –  as all of the work is performed in WSs.

      Another thing that should be considered for the "Meld" is devolution of some of the TSC powers to the WSs with teh TSC as being a purely lightweight oversight org.

      1. Georg Kunz

        Hi Pankaj Goyal. I assume you are referring to the "steady state" TSC now and its election procedure, i.e., not the interim TSC.

        There are currently those two approaches: i) make PTLs automatically members of the TSC or ii) let the community elect TSC members from all contributors. Honestly, I don't mind either, assuming PTLs get elected by the community in option i). The important aspect here - again referrring to the steady state TSC - is that they get elected based on their contributions.

        I also agree with the TSC being a lightweight oversight organization. In fact, it has been in OPNFV for most of OPNFV's existance, given that that projects elected their PTLs, committers, and did the release planing. At the end of the day, what matters is what is getting done in the projects. Honestly, I think that only recently, TSC membership and the role of the TSC has gained overly in "importance".

        1. Cedric Ollivier

          +1 for a lightweight oversight organization.

          I fully second that the role of the TSC has gained overly in "importance" especially regarding the projects.

  4. Walter Kozlowski

    Georg Kunz: why was the CNTT input section removed?  This was the place we agreed Scott Steinbrueck was supposed to add the CNTT charter/practices?

    1. Georg Kunz

      Walter Kozlowski not sure what you are referring to. I didn't remove the section and it is still there. Looking at the page history, the CNTT heading was moved below the OPNFV section in the context of Al Morton 's edit, but it is still here, ready to be filled.

      1. Walter Kozlowski

        Georg Kunz, the email showed that "CNTT" was removed by you.  I did  not know that you or someone else added it again at the bottom, where it was invisible to me.  Thanks for clarification but let us not move things around in the future.  Le ts us avoid unnecessary confusion, please!

        1. Al Morton

          Walter Kozlowski , I edited the page late yesterday (material on Proxies), and saw Scott Steinbrueck 's editing cursor next to the new location of the CNTT heading. I updated the page before leaving, so the CNTT heading movement is the likely result of my update (but not an edit I made explicitly).  At this point, it is important to determine if CNTT TSC has any responsibilities that OPNFV does not have, and list them in the CNTT section.

  5. Walter Kozlowski

    Responding to Georg Kunz : day-to-day operations of TSC depend on who is in it and what the goals/task of TSC are.  You actually touched on a very important topic.  In the tradition of CNTT, we do not consider our streams (like RA-1) as separate projects, but streams of the same project.  This is because those streams are working towards the same goal and they are very much dependent on each other.  The mission of MELD is to improve the "togetherness" and we have to make sure that as a result we do not create more silos! I am sure everybody agrees with this.  Because of this understanding, in the CNTT tradition the whole community elects the WS Lead and Co-Leads and they FORM the CNTT TSC.  This is a democratic process involving the whole community but at the same time it ensures that each stream is represented in TSC.  If we do not have it, the TSC will not be informed well about all streams and will not be able to make cross-stream technology related decisions.  This is actually very important from the day-to-day operations of TSC.

    1. Jim Baker

      To my knowledge, an election where votes were cast (1 per company) has never been done in CNTT. It was more of a "Nominate 'Jessi' for workstream lead, OK?" and verbal agreement. OPNFV has a very specific criteria of who can be nominated AND who is qualified to vote - as well as caps on per company representation. So, auto-promotion of PTLs to TSC reps may come into direct conflict with the OPNFV methodology. We'll need to think through this and find a middle ground...

      1. Pankaj Goyal

        Jim, the reason we have never had an election is because we have never had a need. It is not that the process doesn't exist. If you look at some of Rabi's emails whenever a vacancy has occurred they clearly state that an election will be held if multiple nominations are received.

  6. Anonymous

    Jim Baker: not really like this.  There was a wiki page for nominations, anybody in CNTT could nominate themselves or other people, and they did. These nominations were going through TSC and the CNTT Governance for collecting feedback.  I do not remember any formal voting, as the CNTT culture was to avoid formalities when it wasn't necessary, but in case of conflicting views, the voting mechanism was always  available (as you know).  The important thing was that the selection of WS leads and co-leads was an open process for the whole CNTT community, not only for a project as i understand Georg Kunz says is the case in OPNFV.  I strongly agree that we need to work it through, however a conflict with the OPNFV methodology (and CNTT methodology for that matter) is not really so important.  We are creating a  new organization and we need to find the way it will work best, and (as it is our main assumption in MELD) that the productivity is not hampered. 

  7. Georg Kunz

    Hi Walter Kozlowski, Anonymous (would you mind sharing your name?). Absolutely right. We all agree that we build a new community and by referring to the current ways-of-working in the respective existing communities, we hamper our ability to define a new structure. So, please consider my comment about the election process in OPNFV informational.

    I think that we need to take a step back and abstract from the existing terminology (project + PTL, work stream + work stream lead) because these terms are strongly associated with the existing structures. Instead, let's try to collect criteria for the composition of the TSC. Please note, however, that I believe this overlaps strongly with the org/governance MELD workstream.

    Criteria for the composition of the TSC

    • representation of the key technical contributors
    • representation of the key working areas of the overall project
    • representation of key stakeholders (operators, vendors, ...)
    • stability in terms of size and representation while enabling scalability of the overall project

    New projects typically do not apply a fully meritocratic process from the start, but they need a careful joggling of interests. While OPNFV and CNTT are not new, I expect we will do the same here as well.

    The last bullet in the list above is my main concern in the long run - assuming an increasing number of "areas". However, at the moment, I don't consider this a problem yet and we could agree on revisiting and potentially revising the composition process after some time (although I don't favor that the TSC is primarily concerned with itself then).

  8. Walter Kozlowski

    Georg Kunz: I am confessing to be Anonymous. I have no idea why this was labelled like this. Of course, it wasn't  my idea.  Some wiki glitch. Thanks for your comments. I think we have now enough in the "shared pool of meaningful ideas" to have an informed discussion.


    1. Georg Kunz

      Thanks, Walter.

  9. Al Morton

    Walter Kozlowski Thanks for explaining some of the operation of CNTT.  I have heard CNTT folks say (on more than one occasion) that they don't know much about OPNFV, how it operates and how it is organized.  We (OPNFV) tend to assume that most people are familiar with the basics of Open Source project operation (since we are all here together at Linux Foundation). It would be good if we can share our knowledge, about sub-project operation for example,  with CNTT folks as part of this exercise, because these operating rules will very likely continue in the new organization for development sub-projects. See item 6 above: there are different sub-project membership levels as a starting point (but no useful contribution would be rejected from someone not currently listed in the sub-project INFO page).

  10. Ulrich Kleber

    Maybe as a former OPNFV member, I feel some of the differences more easily.

    In CNTT we don't have committers. Everybody can write PRs. When there are 4 approvers, They can be merged (everybody can approve). Sometimes the merging "happens" without all comments be resolved before. We don't have Jenkins run some tests, since it is documents, thus no automatic checking beyond formatting.

    Workstream leads don't have permission to merge in their own project.....

    This leads also to some fuzziness when deciding who should have the permission to vote for the TSC.

    We didn't need a process for project creation or of committer maintenance in CNTT yet. Maybe CNTT is just too young for that (wink).


  11. Jim Baker

    Maybe we need to evolve the idea of "committer"  to include the (submission + reviews) factor - the essence is vetting through contribution metrics is a corner stone of the meritocratic process

  12. Cedric Ollivier

    Any TSC must steer technically a community and then must be defacto composed of the main contribution leaders (whatever it's about code contributions in OPNFV or doc contributions in CNTT).

    All opensource projects leverage on meritocracy to legitimize the TSCs and somehow reserving seats is quickly false.

    Then I would consider that they are a couple of issues in the different comments here.


    PTLs or work stream leaders may not be the best candidates. Yes they are elected among the contributors to run the meetings (it's rather promoted than elected in CNTT) but they may not be the technical leaders in their work streams.

    Then any reserved seat for PTLs or WSL is incorrect from a meritocratic / technical steering point of view.

    I frankly don't like the stakeholder criteria in a TSC. All key contributing stakeholders would be elected if they deserve to. I would emphasize that it's about technical steering, not governing.


    I don't understand key the point "working areas of the overall project". A few people are working in both CNTT and OPNFV, in multiple CNTT streams (RA1 members are helping merging RC2 changes)


    The OPNFV TSC charter leverages lots of opensource experiences and we won't find so much differences in the different opensource foundations (LFN, Apache, Opendev)

    As far as I know, the only issue in OPNFV is the eligible criteria which are far too low and allow mostly anyone to be eligible.

    CNTT member could be even part of the existing OPNFV TSC by voting +1 in 20 patches in Functest about RC1 and RC2 (I do check if Rabi Abdel was eligible thx to his reviews).


    I would have considered that OPNFV charter is good to welcome CNTT.

    It's simply about updating the eligible criteria to vote and to be candidate (merged github and gerrit stats).

    I hope we won't fall in the OPNFV trap where you can be elected without contributing any code (here doc is part of code as in CNTT).


    For my understanding FMO option 3 induces that we would adapt OPNFV charter.

    If we are considering something much more disruptive, could we warn the existing OPNFV projects asap? Al Morton

    1. Al Morton

      We have two detailed organization charters to consider, remove overlapping items, and craft a set of items that the new TSC can use efficiently. I certainly do not see disruption to OPNFV projects in the future; what the TSC does for OPNFV projects now seems to work for them. That's a goal for my participation, at least.

      1. Cedric Ollivier

        Efficiently would have been to leverage the OPNFV one, leveraging opensource knowledge and experiences. Yes we do adapt minor points such as eligible criteria for voters and candidates.

        Starting by comparing both in our case is not the efficient/best approach especially because CNTT has never run any TSC election.

        I could understand we start by equal elected TSC members from CNTT and OPNFV even if it's false in a long run (they are a couple of exceptions which are contributing on both side, our target).


        The key criteria for the composition of the TSC should be only the contributions (Github in CNTT / Gerrit in OPNFV) to the combined project. Here it's about representatives of the technical community.

        It's only the first bullet in Georg Kunz 's Criteria for the composition of the TSC.

        The remaining ones are falsy. What's the point of the stakeholders in a technical steering committee if they are not contributing at all? It's not a Board here where you pay membership (or SPC).

        I bet that Pankaj Goyaland Walter Kozlowskiwould be easily elected for a common TSC. It would be because of their contributions/visions in CNTT, rather they are stream leaders or working for an Operator.

        It should be the same for the top OPNFV contributors in Gerrit whatever they are working for Installers or Test Frameworks.

        This kind of rules had never been suggested in OPNFV even when one Operator led the code contribution with a few voters. I don't see why we should change it now. 


        Al Morton yes it's disruptive for the existing OPNFV projects If we decrease the fairness of the election or increase how the TSC can override the project decisions in parallel.

        We already discussed the key risks when voting the new release process. https://wiki.opnfv.org/pages/viewpage.action?pageId=56296083

        FMO selected option 3 merging CNTT in OPNFV. But I do confess that some MELD discussions gave me the feeling that it's rather option 2 where OPNFV helps for the legal basis.


        I also see comments about the number of seats.

        My feedbacks would be 15 seems currently too much when counting the number of active contributors in the joined stats. The ratio is too close to 1:1.


        NB: Contribution in my views includes code proposal owner, Co-Author-By and reviewers.