Contributors:

Contributors may create all types of JIRA issues to add new User Stories, Tasks, etc.  The general flow is to have EPICs and User stories in place first that create  basic deliverable structure  with any seed material inserted. Additional tasks can be created to generate material for missing sections. Once a document section has text, then Bug reports against that text would be more appropriate. The majority of the progress  is thus expected to be  via bug reports triggering fixes in the deliverables.

To Convert existing documentation to .rst

For the Project's seed documentation it is useful to convert from other document formats into .rst.

A video of the conversion process using Pandocs is  available here .

To Build from .rst to .html 

After making changes in your local clone of the repo, it is recommended to validate the appearance of the changes in .html.

A video demonstrating a local build of the .html is available here 

To Report a Bug

ONAP requires all bug fixes to be associated with a JIRA issue,  so create the JIRA bug report first. 

Issue Type:

Bug

Component Field:

This is the VNFRQTS Project deliverable impacted: VNF Guidelines, VNF Requirements etc. 

Description field:

Please be as specific as you can  in raising a bug report against the VNFRQTS deliverables. If there is a requirement number or document section number, please use that.  

It helps to have a brief example use case illustrating the problem.  If this bug impacts the Release A use cases, please indicate how that is impacted as well. 

Linked Issues:

One Bug should cover one topic. If there are multiple issues raised, please use separate bug report and link them using the Linked Issues section.  

JIRA task/bug report handling

The weekly project team meetings review the status of the current JIRA backlog including bug reports.  Proposed tasks & bug reports are assigned to Sprints for resolution. 

To propose a Fix to a Bug 

ONAP requires all bug fixes to be associated with a JIRA issue. Don't  just make a change until the bug has been discussed on one of the weekly project calls, and teh bug assigned to the Sprint.

You will need to check in/out  your changes to the requirements documentation using git/gerrit. To use Git & Gerrit, ( assuming you do not already have them) will require you to set up your environment.  You will need to clone the ONAP repos from http://gerrit.onap.org to your local machine to make your changes as a contributor. The ONAP community is tracking progress using the JIRA system. So please remember to  close the jira tickets for the tasks you are completing so that the progress we make is visible. The workflow of the ONAP development process and policies are summarized in this figure.

When you push the change up for review with gerrit, it helps the committers find it if the commit message title includes the project name  ie. [VNRFRQTS]

A video example of the process is available here .

Committers

ONAP uses the Gerrit review system for committing changes to the code - including our documentation source files.   Please recall the ONAP policy is that committers cannot merge their own changes. For community transparency, please try to get reviews from diverse community members. The documentation project has a review checklist for general documentation.

VNFRQTS Project Sprints and Backlogs

The weekly VNFRQTS conference calls are used for scrum style grooming of the Product and Sprint backlogs. This is where prioritization of Bugs and other issues for resolution is discussed. 


  • No labels

1 Comment

  1. Great! All these videos are useful, thanks for the job!