Organization Structure Exercise
In the comments section please discuss your thoughts in the context of the follow questions:
- Is this function needed in the new organization?
- How do you see the function fitting in the organization? (example: Is Oversight a role in a Business Coordination or is it a separate function unto itself?
- What dependencies exist between the functions?
- What other discussion points can you offer regarding the Function?
on the FUNCTIONS (not groups) listed below
- Business Coordination
- Release Mgmt
- Work intake (Al Morton what is this called in OPNFV? Answer: The Requirements Working Group, which is part of our JERMA Release Process)
What do we produce?
Based on Trevor's comments below and some of last week's conversation, this can be a space to talk about what we produce and why. The How is really up to the TechOps TF, but I do think we need to wrestle with the what. And to repeat what was discussed last week, "We need to improve the ability to on-board infrastructure and network services" or some version of that is what we're trying to accomplish at the highest level.
Reference Conformance Documentation
Specific Test Cases (Do we need to divide btwn benchmarking and functional?)
Conformance Programs – Links to CVC Need to be Considered
Proof of Concepts
Other Development Projects
Tooling Activities and Projects
Additional Activities – Doing the Journey Together
A place to brainstorm next level-down considerations based on outcomes from the above section. This is not meant to dictate specifics of elections policies and procedures but what rather we expect of any governing or oversight body.
TSC Composition – Short-Term – Interim/Startup TSC
When new projects starts or in the immediate aftermath of a merger, most projects elect to have a "start-up" or "interim" TSC, where the TSC has different election procedures for a constrained period of time. An example with which we are all familiar is when new stand-alone projects start, their TSCs usually consist of the founding platinum members of the organization (ONAP, OPNFV, FD.io, ODL, and TF(?) all followed this model). Over time the TSC migrates to a fully democratic model, elected by the community according to its agreed election procedures. Since OPNFV and CNTT are both established, a modified and accelerated version of this model can likely be used.
Rationale: Although the meld process is helping the communities get to know one another, many of the individual contributors and PTLs/workstream leads don't know very many people in the other group, which makes general voting across both groups for a single TSC challenging in the short term. In addition, both groups are likely to want to feel that they have representation as the group gets off the ground and forms a cohesive whole. A TSC that is overly weighted in one direction may cause hard feelings in the less represented community. Finally, this TSC will be unique in that one of its primary job will be to see the Meld fully realized – i.e., that what put down on paper really happens in practice and that we create a successful, unified group that operates as one project. This TSC will need to lead us to build a strong culture together across all the contributors of all the work.
- Choose "Meld" TSC size (15?) - Decision? 15 members?
- Allocate 8 seats to one group and 7 to the other
- As close to half and half as possible
- Flip a coin to determine which one is slightly larger?
- Election timeline?
- Quorum Requirement
- Change the voting criteria - a 2/3 majority?
- Determine a process to fill those allocated seats. I see two options:
- Each TSC votes amongst its existing members to determine who serves on the "Meld" TSC
- Each community runs a vote according to its existing procedures to fill its seats from the existing TSC members
- Note that one community could go one path the other could go the other
- Also note that it's possible that not every existing TSC member may want to serve on the "Meld" TSC as its responsibilities may be different than steady state – one first step could be to assess interest and volunteers
- Decision?: Each Existing TSC Plus CNTT Gov will vote among themselves for the MELD interim TSC membership?
- It may be possible to shorten the election cycle compared to the full annual election
- Decide the term of the "Meld" TSC
- Long enough to effect the full merge
- Ideally aligned with steady state annual election cycle
- Suggestion: When Steady state annual election (Aug-Sept.)but no later than
Consensus as of week of Oct 19
- 15 member TSC
- Each existing TSC will select from its own members those that will join the interim TSC (CNTT may also involve the governance committee)
- Term to end when 2021 elections are held but to last no longer than through dec 31 2021
- How many seats from which org?
- Election timeline
TSC Composition – Long-term/Steady State
- Roles, responsibilities, desired skillsets
- Eligibility (Fair, quantifiable, transparent) – may be that this is a topic for the Tech Ops group?
- Composition (Are all seats generally elected seats?)
- Officers (currently a chair and vice chair for OPNFV, single chair for CNTT) Scott Steinbrueck and Walter Kozlowski are CNTT TSC co-chairs, are they not?
External Relationships (LFN Projects and External)
A place to brainstorm next level-down considerations based on outcomes from the above section. What are the types of relationships we need to build with external organizations? How do we want to build them? What metrics do we use to measure success? What are out 2021 priorities ?
Conformance Program (OVP) Considerations
Fundamentally, this is the end goal of much of the merged group's activities, so a very strong relationship and understanding of requirements with CVC is extremely important.
The Marketing function is definitely needed, especially in the beginning when we have a great deal of evangelism and positioning to do. LFN projects have an LFN MAC Liaison rep to report up to that body and maintain marketing efforts for individuals.
Business Coordination: Not sure what this function would do inside of “Melded”
Oversight: Wholistic oversight of project activities and how they fit together. Define and manage processes and flows to define and document standards activities the lead to RI and RC development.
Lead development of RI and RCs. Track, promote upstream development activities.
Release Mgmt: Things to be released:
1) RM – new versions
2) RAs – New versions for existing RAs, and sometimes new RAs
3) Upstream Development Plans – When gaps are identified in upstream projects, how do we plan that engagement, track it, incorporate it, test it, etc
4) RIs that conform to new versions of RAs.
5) RC test plans – validated to ensure they are complete regarding compliance of implementations and VNF/CNFs
6) Test suites that conform to the test plans
7) OVP – certification(s) – tied to successful completion of compliance test suite for given RA/RI
Work Intake: Work planning. Do we “intake” work, or do we define the execute work? The RM will evolve causing changes to the RAs. RAs will evolve and new ones created causing new work in RIs and RC Testing. (see oversight for defining and manging these flows).
RMs, RAs. We need them to be created similar to the way they’ve been done in the past, but input/feedback from RI/RC communities must be included to properly scope activity.
We need lots of development/developers – which is currently the group’s largest shortcoming.
Arbitrage: (see oversight)
I have evolved the functions / activities from above a bit and organized them under three categories. Something like infrastructure may not seem like a function but I think there are activities/functions around that which are needed. For each I have added some notes below based on our discussions and some additional thoughts.
Ongoing work activities (process + community resources)
Support functions and community resources
Interim TSC (needs to be in place by end of year)
- join existing TSCs?
- community vote?
TSC (long term)
Specifications / Dev
Based on action item I took from last meeting to articulate and expand on my "expectations" question:
There is a question around expectations of releases, especially across the entire flow from the RM to a conformance badge. What are the expectations around when and how a specific requirement in RM or RA gets expressed in a set of specific tests? I'm not sure it's reasonable to ever expect 100% test coverage for any RA, so as we get more and more specific how do we know we've succeeded and met the bar and how does that evolve over time? More importantly, how do we communicate that to our core stakeholders (i.e., for someone at an operator, what do they know they can trust in any given release of RA document, reference implementation, conformance test suite, or badging initiative? Assuming that this will be agile and change over time how do we enable the entire ecosystem to have the data to make decisions without an overwhelming amount of information? How do we communicate the evolving interrelationships between implementation and requirement?