Mission Statement
Characteristics of a good mission statement (according to the internet) 
- Succinct
- Memorable
- Distinctive
- Has Longevity
- Motivating
Possible Drafts (feel free to edit, comment, or add your own)
"Potato" empowers the global communications industry to deploy applications and infrastructure quickly, reliably, and securely.
"Potato" exists to serve the infrastructure needs of the global communications industry through architecture alignment, integration, automated testing, and conformance programs. We power the telco cloud.
"Potato" defines, integrates, deploys, and tests the infrastructure and applications necessary for next-generation communication services.
"Potato" improves the quality and agility for on-boarding network services through architecture alignment, integration and deployment, test automation, and conformance.
Input from previous brainstorming meeting
Possible Mission Statement: "We exist to enable the telecom industry to collectively deploy architectures and services that serve our customer base. This is a complicated process and we listen to everyone who is a stakeholder in this process and we design solutions based on strategy, belief, and technical knowledge and in this way we advance the communications infrastructure of the world."
~this is the point of our existence – how do we convey that?
- "We exist to enable the telecom industry to transition to cloud with respect to our infra and applications. We do this by listening to our stakeholders, creating projects that enable them and making conformance programs"
- "distinctive, addresses the unique infrastructure of telco cloud
- what does "potato" bring? What is the work output we chose to bring together?
- Predictability and efficiency are important to high-level telco execs (based on convos Bob Monkmanhas had)
(will need to be edited down a bit; this is a starting point)
Raw comments summary from early CNTT exec interviews:
Speed of Development
Containers and cloud native implementation of NFVi, VNFs and CNFs represent a significant opportunity for both operators and suppliers. As this industry is very dynamic, development of adoptable standards must move quickly. Must learn from the mistakes made on OPNFV - i.e. not try to create one single reference stack or have innumerable scenarios. It would be advisable to demonstrate RA-2/RI-2/RC-2 in labs in the May/June 2020 time frame, with certification to occur in Sept 2020.
Speed and Efficiency of Deployment
Through the alignment of the developed standards with other industry bodies, the ability to “mix and match” NVFIs and VNFs in the operator platform will be feasible. Automated installs of all vnf/cnfs that work "out of the box first time/every time" will be probable, improving speed of deployment to hours/days verses weeks/months.
Cost Savings
All operators and suppliers are concerned with the improving cost efficiencies. The wide adoption of the standards is not just a technology decision; business drivers, such as lowered operating costs and more NFVi/VNF/CNF interoperability are important considerations. This ability to reduce operational costs must do so while allowing suppliers to differentiate their products/services and thus maintain market share.
Potential Value Prop:
"OPNFV is a project and community for Communication Service Providers (CSPs) and their supply chains focused on network transformation and collaboration to continuously improve the efficiency and predictability of consuming and deploying NFV infrastructure, VNFs, and CNFs. OPNFV does this by iterating through implementation of toolsets, automation, verification, conformance, and performance, aligned with normalized architectures, and enabling the community to drive down cost and time to revenue for network services."
e need to capture the end result we hope to achieve, as well as talking about the journey and collective collaboration. The starting point expresses some key aspects but it of course needs to be much more succinct and I agree that this time we should not get into too detailed specifics (because the details may change and can be capture in the Technical charter anyways, and with no acronyms.
"We exist to enable the Telco cloud ecosystem to collaboratively design and deliver new reference architectures, tools and verification programs that will dramatically reduce the complexity and cost required to deploy and operationalize cloud infrastructure and services for the world's communications network."
We could also end the last one with "...and services for the 5G economy" , in order to a bit more evocative around the promise of 5G and cloud native. it's all about business value in the end.
Scope
Current OPNFV Scope statement; The scope of the Project includes software development under an OSI-approved open source license supporting the mission, including documentation, testing, integration and the creation of other artifacts that aid the development, deployment, operation or adoption of the open source software project.
Possible new one: The scope of the Project includes both software development under an OSI-approved open source license and reference documentation, requirements, and specifications under <creative commons> in order to support the mission. These include release documentation, architecture and requirements documents, testing, integration, and the creation of other artifacts that aid in the development, deployment, operation, or adoption of the open source project.
Possible deeper dive statements to drive the formulation of the full value prop
When we define value prop, should consider the types of work we do that isn't release artifact-based.
Note that this is taken from the OPNFV 2.0 work; need to integration anything missing from CNTT
(a) Fostering close collaboration of Communication Service Providers (CSPs) and their supply chain to integrate and build tests, tools, and components for NFV infrastructure, VNFs and CNFs which realize the stated outcomes of this mission,
(b) iterating on developing an integrated, tested, and certified open software reference infrastructure (including interfaces to hardware), with tools of its own design and from upstream testing projects,
(c) contributing changes to and influencing upstream projects leveraging the reference infrastructure,
(d) building new open source components within the reference infrastructure where needed,
(e) leveraging open implementations to drive an open standards and open-source-based ecosystem for NFV solutions,
(f) supporting and maintaining the strategic framework of the Project through the technologies made available by the organization to make the Reference Infrastructure testing, certification, and deployment a success.