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

Compare with Current View Page History

« Previous Version 2 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: docs
  • Proposed name for the repository: docs

Project description:.

  • Create and maintain documentation for ONAP for user audiences the tasks they perform.   For example: a developer pulling code, building, running, hacking and pushing; administrator installing, configuring, and monitoring.
  • Establish and maintain the the tool chain that supports the integration of sources to build ONAP release documentation
  • Establish a process recognized in the release plan whereby some sources of documentation are maintained by other projects.  For example, an API document for a software component or guidelines document for VNF developer.
  • Determine how to align content with training, marketing, etc
  • Determine how to validate documentation
  • Benefit end users quickly understand how to do something, documentation is always in sync with the software in release.

Scope:

  • Describe the functionality to be provided by the project. 
    • Complete Content Catalog
    • CI/CD Document 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 good practices and basic documentation.
    • Subsequent release will be required for all projects to comply with practices, complete content, understand / meet multi-language requirements, etc.
  • Identity a list of features and functionality will be developed.
    • Documentation uses a similar pattern including gerrit, jenkins, artifacts published in nexus or readthedocs.org
  • Identify what is in or out of scope. During the development phase, it helps reduce discussion.

Architecture Alignment:

  • How does this project fit into the rest of the ONAP Architecture?
    • Linkages with source project providers insure alignment.
    • Target users and use cases drive the content
  • How does this align with external standards/specifications?
    • Identify best practices for documentation tool chain talking with other open source projects (eg. open daylight, opnfv)
  • Are there dependencies with other open source projects?
    • May use readthedocs.org as way of publishing documents.

Resources:

  • Primary Contact Person
  • Names, gerrit IDs, and company affiliations of the committers
  • Names and affiliations of any other contributors
  • Project Roles (include RACI chart, if applicable)

Other Information:

  • Seed Code - Developer Wiki with User Guide, Tutorials, A Demo Platform
  • Vendor Neutral  Yes
  • Meets Board policy (including IPR)  Yes


Key Project Facts

Project Name:

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

Repo name:
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