You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

This is a potential draft of a project proposal template.  It is not final or to be used until the TSC approves it.

Project Name:

  • Proposed name for the project: Documentation
  • Proposed name for the repository: org.onap.docs

Project description:.

  • Create and maintain documentation targeted to ONAP user audiences and the tasks they perform.   For example:
    • a platform developer pulling, building, running, hacking and pushing source code ;
    • an administrator installing, configuring, and monitoring an ONAP instance;
    • a designer or tester creating, validating, and delivering service models;
    • a VNF developer designing, testing, and certifying a VNF for use on ONAP
    • ... others as required for release plans or ONAP committees
  • Establish and maintain a tool chain that supports the integration of documentation source material from all ONAP projects and builds documentation artifacts for each release.
  • Establish a process to recognize source and final documentation dependencies in the release plan, end to end tests, and/or CI/CD to insure these deliverables are created early in a release cycle and remain current with changes made in other projects.
  • Benefits include users quickly understand how to do required tasks, documentation is efficiently created and is in sync with the software in a release.

Scope:

  • Describe the functionality to be provided by the project. 
    • Documentation artifacts for ONAP integrating dependencies on source material from all projects
    • CI/CD Documentation Tool Chain

  • Please provide the full intended scope of the project; not just what is intended for the project's first release.
    • First release establishes best practices and basic documentation.
    • Subsequent releases will be required for all projects to comply with practices, complete content for all audiences, address how documents might be tailored or translated for use in different ONAP instances, etc.
  • Identity a list of features and functionality will be developed.
    • Documentation managed with the same pattern as source code including gerrit, jenkins, artifacts published in nexus or readthedocs.org, etc.
  • Identify what is in or out of scope. During the development phase, it helps reduce discussion.
    • TBD

Architecture Alignment:

  • How does this project fit into the rest of the ONAP Architecture?
    • Dependencies with all projects providing source material for documentation.
    • Target use cases drive the user audience and task requirements.
  • How does this align with external standards/specifications?
    • Project will identify best practices for a documentation tool chain by looking at other open source projects (eg. open daylight, opnfv)
  • Are there dependencies with other open source projects?
    • Evaluate use of readthedocs.org as way of publishing documents.

Resources:

  • Primary Contact Person
  • Names, gerrit IDs, and company affiliations of the committers
    • Rich Bennett, rb2745@att.com, AT&T
    • Timo Perala, timo.perala@nokia.com, Nokia
    • Greg Glover, gg2147@att.com, AT&T
    • Kevin Scaggs, ks0567@att.com, AT&T
  • Names and affiliations of any other contributors
  • Project Roles (include RACI chart, if applicable)

Other Information:


Key Project Facts

Project Name:

  • JIRA project name: Documentation
  • JIRA project prefix: DOC

Repo names:


Lifecycle State: proposal
Primary Contact:
Project Lead:
mailing list tag [docs]
Committers:
rb2745@att.com
timo.perala@nokia.com
gg2147@att.com
ks0567@att.com






*Link to TSC approval: 
Link to approval of additional submitters: 

  • No labels