Page tree
Skip to end of metadata
Go to start of metadata


When OPNFV launched, the TSC was populated with representatives of the Platinum members. The consensus was that the TSC composition would be revisited after OPNFV is established.  In Q4'2016, we added 5 "committers-at-large" TSC members to Platinum TSC representatives.  This purpose of this page is to capture community discussions on the TSC composition.  

Discussion/Consensus during the Euphrates Plugfest

  • Term: 1 year term.   If someone stands down, the TSC can (but does not have to, TSC decides) backfill for the remainder of the term via an election.
  • Size: 15 members.
  • Cap per company: Each organization can have a maximum of 2 TSC reps.
  • Eligibility (for nomination/voting): Need to move away from committers and define an "active contributor"
    • Active contributors are determined based on annual metrics TBD (e.g. x patches merged, x number of reviews, x JIRA tickets closed, x wiki contributions, etc.)
    • PTLs have an input on the "active contributor list" compiled

Questions as we move towards LF Networking (or Projects Harmonization, umbrella organization, etc.)

  • Target size of the TSC (same as today/smaller/larger?): How do we determine the right number?
    • DN: I recommend smaller - with a lower limit of 15. I think 19 or 21 is a good size. OPNFV is a diverse ecosystem, and that diversity will not be represented by a group which is too small.
  • The new Technical Charter states that the current TSC stay as is during the "startup period" (up to 12 months) before moving to merit-based TSC.  So the following are discussions are not applicable.  
    • Evolutionary approach (step by step evolve from platinum member representatives to elected members) or step function (elect an entirely meritocratic TSC in a single go)?
    • In case an evolutionary approach is considered - potential options:
      • (a) (in case the target TSC is smaller than the current one): we define a target number of TSC members and whenever s TSC member steps down, we won't pick a new member until we reach the target number
      • (b) (in case we stay with the current size) whenever a TSC member steps down, s/he'll pick a community member to replace him/her
      • (c) (in case we stay with the current size) we stay at the current number, and whenever a TSC member steps down, we'll trigger an election to choose a new TSC member
    • DN: Since we will no longer have Platinum members, I do not think that any move after the merger should include a special status post-merger. I expect that in a wholesale election that many of the current TSC members would be returned, as senior and visible members of the community, and that rules governing representation caps will suffice to ensure diversity of representation. I think it could be a good idea to reserve a small number of seats (2-3) for Board appointed TSC members, with the explicit guidance that these seats are intended to ensure representation of under-represented constituencies (operators, labs, universities, ...)
  • Constituents who are eligible to run & vote in TSC elections (right now it's just committers)
    • DN: I do not think committer aligns well with active participation in OPNFV - some people became committers at the creation of a project and have done nothing, others are very active in the community but are not committers on any project. In addition, there are many positive contributions to OPNFV which are not included in the Committer activities (JIRA tickets, Gerrit reviews, event co-ordination, infrastructure management, to name just a few). I think we need to broaden the definition to Active Technical Contributors, to include anyone who meets a minimum bar of contribution in the previous release cycle or 2. A large constituency is better to get representative TSC members.
    • DN: Another question: Will there be different criteria for being a candidate and voting in the election?
  • Do we need to limit the number of elected TSC members from each organization (e.g. Max of 2)?
    • DN: Yes, I think that's a good idea. Particularly if we reduce the size to 15-20.
  • ...




Topics during the 2017 OPNFV Summit


  • Are committers the right people to elect the TSC?
  • Can we go to 100 per cent merit based TSC today?
    • Responsibilities of the TSC (see section 5 of the TSC Charter)


"Subject to such policies as may be set by the Board, the TSC is responsible for simultaneous release dates, release quality standards, technical best practices (including the establishment and maintenance of a Development Process), monitoring technical progress, mediating technical conflicts between Committers and Project Leads, and organizing inter-project collaboration. The TSC will define OPNFV’s release vehicles and serve as OPNFV’s primary technical liaison body with other consortiums and groups."




Topics during the OPNFV-Danube Plugfest (April'2017)

For background information about the OPNFV bylaws, OPNFV TSC charter and what other organizations are doing, see this presentation: TSC composition background and notes from OPNFV Danube Hackfest 

What should the TSC do?

Before deciding who should be in the TSC, it is worth discussing what the TSC should do.  The following tasks have been mentioned (please also read Section 5 of the TSC Charter).


  • Review existing projects, check if all projects are relevant, what projects are missing

  • Give technical feedback on different topics

  • Give feedback on the technical direction of the OPNFV

  • Have like-minded people for technical discussions and fixing technical problems

  • Be a technical decision body

  • Serve as a technical interface for the End User Advisory Group

Points for purely elected TSC

  • Can get a smaller and more active TSC which would help reach quorum in meetings
  • This would be a move towards a merit (or contribution) based TSC
  • Example: Limit the size of the TSC to 12 members with 50% of the TSC members elected from PTLs and the other 50% elected from committers (there would be a maximum of 2 TSC members from each company)

Point for keeping current TSC

  • Difficult to define who should vote for the TSC, since the projects are so different (e.g. are committers the right constituents?)
  • OPNFV is end-user focused rather than developer oriented, so if project committers elect the TSC, the voice of the end users could be lost
  • Platinum members may feel that they are losing one of the benefits of being a Platinum member.  

Other alternatives

  • A hybrid of two approaches above where Platinum members would have a certain number of TSC seats
  • Example: Limit the size of the TSC to 15 members with 10 members elected from Platinum members and the remaining 5 elected from committers (there would be a maximum of 2 TSC members from each company).  



  • No labels


  1. Limiting the size of the TSC would be beneficial in my opinion. 22 is a big number, it's impossible that all members actively engage in the conversation. 15 would make more sense.

    I like the hybrid approach, it's a way to involve different roles in the TSC (developers, end users, etc. ). There's still the open question: who's allowed to vote?

    Another point is how to ensure diversity inside the TSC. We could do that by making sure that we have diversity in the candidates for the TSC seats. If candidates are not so diverse then we should approach people directly to include genders, roles, geographies, etc that are missing.

  2. I lean towards a hybrid approach as well as a smooth migration path between the current situation and a purely PTLs/committers TSC.

    Platinum members having a certain number of TSC seats and the remaining elected from PTLs/committers with a limited total number of TSC members from each company.  

  3. Notes from the discussion:

    • TSC members nominate themselves, must prove to be "active contributor"
    • Committers vote 
    • Two year terms
    • 15 members?
    • Staggered system

    Still, no more than two members from the same company can be elected (more than two can be nominated)

    Same in presentation format: