e.g. Jonathan Beltran - (comment, questions)

@fuqiao We probably need further explanation about the relationship between sub teams of dev/ops/compliance under RM/RA/RI, e.g. what is the relationship between RA dev and RI dev?

Gergely Csatari , Jonne Soininen : We are a little bit worried that this many groups may fragment the community too much (number of meetings, etc). One way could be to combine RA1 Core and RA1 Ops, RA2 Core and RA2 Ops, RI1 Core and RI1 Dev. Shouldn't RI and RC groups be represented in OPNFV directly, using the already existing structures there instead of in CNTT?

Gergely Csatari , Jonne Soininen : We agree, that the boxes at the bottom include the tasks for a governance structure. We are wondering if rather than  splitting the responsibilities it wouldn't be better to have a Governance Steering team with joint responsibility of the tasks. 

Qiao Fu how do we select Lead/co-Lead. If there is only one candidate, that should be fine. But what will happen when we have multiple candidates? What will happen in open-source community is we will have a vote. Then we have to define who has the right to vote? And how long will the lead/co-lead serve for one term? I can think of the complicated process in OPNFV TSC charters which define the voting procedures...

Phil Robb +1

Gergely Csatari , Jonne Soininen : Just out of interrest, what is the term limit for the different WSL positions.

Qiao Fu When we split the governance work into 6 pieces, we need to define how do we make decisions within the governance. Does that mean we will have the WS make decisions on the certain work listed, or we will have a larger "governance' team where people can 'vote'? We also need to define at what level should each different thing be reviewed and make decision. e.g., for a technical choice of a certain version of software, should we make the decision at the certain team in RA/RM/RI? or should we go to TS, or should we go to board? With the structure here, we only know how many characters we have in the governance, however we still lack of certain decision process.

Qiao Fu After read through the slides, I realize there is a decision process, which ends only at the TS level. Then how do we expect the TS to work with Governance? Probably the decision process between TS and Gov should also be defined?

Qiao Fu For the RI team, I see logo for OPNFV there, and there are also logo for OpenStack and CNCF in the RA team. Then how should we define our relationship with these opensource projects? How should we work with there TSC? e.g., OPNFV is now having a different release cycle from CNTT, how should RI team follow this? 

Jim Baker I think the logos were intended to show a OpenStack AND Kubernetes based RA. OPNFV will need to drive fixes upstream when required and should develop relationships with the TSCs of the key upstream projects when appropriate. OPNFV release cycle timing can be tuned at a later time, I do not think this is an immediate issue.

Qiao Fu From my understanding, TS will be almost the same as TSC in OPNFV. If I understand this right, I would further think lots of future decision making effort will happen in TS level. If this is true, we need to be careful with the TS member. Who can be one of the member, who has the right to vote(or give +1 for git review)? OPNFV begin with one representative one company, then turn into community selected TS members after we have enough active contributors and also people are well aware of each one's contribution to the community. 

Jim Baker I Fu Qiao is right - creating parallel/overlapping technical steering bodies is a recipe for disaster. OPNFV and OVP (RI and RC respectively) have existing technical steering. CNTT technical steering should focus on the RM/RA ONLY - and then drive the LFN efforts through the existing structures.

Trevor Cooper I understand that CNTT RI work-streams are a "mirror" for OPNFV CNTT-RI project but this may be confusing for new contributors and any overlap is likely to cause problems. It would be simpler to create clean distinction to say all RI work happens in OPNFV including RI technical oversight. RI requirements and priorities come from CNTT RAs and governance body. I think this in line with above comments.

Jim Baker Providing roadmap inputs to OPNFV and OVP is great - it's a contribution to the existing planning and commitment delivery process.

Cédric Ollivier:

I would have strongly considered an opensource model (see OPNFV) based on meritocraty instead of nominating people regarding the nature of their companies by laws. All contribution statistics (pull requests, bugs, comments on pull/requests) are available from the beginning which eases selecting the best committers.

I disagree with the current 2 operators + 2 vendors requirements to merge changes even if I understand we can improve the process sometimes wrong during Botrange. It seems falsy to ask for 4 committers to merge a pull regarding regarding the number of current active committers (ratio 1:1?). Then I consider once again that selecting the nature of company is not right from a meritocracy.

I would proposed 2 committers only from 2 different companies excluding the author's one. (1 committer could be considered depending on the number of contributors).

Qiao Fu How many TSLs do we expect? If there is only one (or two, counting the co-lead), I would expect huge workload for TSL. I am worried it would be impossible for the TSL to go through all the details of each submission of PR in each different streams, which eventually will make the approval just a process...

Qiao Fu Such decision process is different from the other open-source projects, such as OPNFV. So for CNTT-RI project, should we follow OPNFV's rule when developing codes in OPNFV, and follow CNTT rule when developing documents in CNTT? Same problem may occur in other communities as well.