ONAP Bugs, Epics, Stories, and Tasks are tracked in the JIRA system at https://jira.onap.org/.
Note that you do not need to log into JIRA to view issues; however, your view will be read-only and not all fields described below will be visible.
If you intend to file or update information in JIRA, you will need a Linux Foundation identity to access the ONAP JIRA account. Read this page for instructions.
If you are not familiar with JIRA, you can refer to JIRA User's Guide provided by Atlassian: https://confluence.atlassian.com/JIRA064/JIRA-user-s-guide-720416011.html
ONAP defines a number of different projects for the various subsystems.
To view the current set of JIRA projects, go to the Projects menu, select View All Projects from the pull down menu to see what is currently defined.
Below is the current set of Projects; however, note that additional JIRA projects may be added as needs dictate, so this list is not static
There are many ways to view issues in JIRA. The description here is one way.
Go to Issues menu, select Search for issues
This will bring up the following screen. You will be able to select which Project(s) you want to search, what issue Types (Bug, Epic, Story, Task), what Status and so on. The "More" menu allows you to select additional fields to search on to further narrow down your search.
An alternative to searching, you can use predefined filters provided by JIRA as shown below:
To report a bug against ONAP, select Create (please note that screen display may vary slightly depending from where in JIRA you create the bug)
The following Create Issue screen will be displayed.
New feature or enhancement proposals are submitted via JIRA using the Story issue type.
Before you submit your idea, first check to see if something similar already exists in the backlog. If not, go ahead and create a Story.
Searching for a Story in the backlog works the same way as searching for a Bug (Viewing Issues in JIRA), just select Issue Type Story instead of Bug along with the Project(s) of interest in the Search menu. Alternative, you can go to the Backlog board for a particular project, such as shown below for MSO.
To submit your feature or enhancement proposal, go to the Backlog board of the applicable Project and select Create Issue. In our example, we are using MSO.
This will present the following menu, go to the far right and click on the three dots.
This will bring up the Create Issue screen as show below.
There are 4 JIRA Issue types
There are 4 distinct JIRA Statuses
Use this guideline to setup the mandatory "JIRA Priority" field. Note that the PTL has jurisdiction over this criteria and may thus requalifies the priority.
Highest: Catastrophic defect that causes total failure of the software or unrecoverable data loss with no available workaround. Complete shut-down of the process, nothing can proceed further. Blocks testing of the product / feature.
Must be fixed in the next build.
High: Severely impaired functionality. Erratic performance and reduced system availability. It may cause major components or features of the system to be unavailable although certain parts of the system remain functional. A workaround may exist but its use is unsatisfactory or at a high time cost (manual intervention required).
Must be fixed in any of the upcoming builds and should be included in the current release.
Medium: Failure of non-critical aspects of the system but results in an inconvenient situation. It causes some undesirable behavior, but the system is still functional. There is a reasonably satisfactory workaround. It is still a valid defect that should be corrected.
May be fixed after the release or in the next release.
Low: It won't cause any major break-down of the system. It does not result in the termination of services, does not impact usability of the system and the desired results can be easily obtained by a workaround.
Fix can be deferred until after more serious defect have been fixed.
Lowest: No impact to the functionality. More related to the enhancement of the system.
May or may not be fixed at all.
This table is intented to describe the main Status transition that may occuer. The "Actor" represents the person who is in charge to change the "Status" field.
From | To | Actor | Comment |
---|---|---|---|
TO DO | In Progress | Assignee | Assignee has started working on this Issue. Usually, this is not a trivial Issue that may takes hours. It gives visibility to the community that someone is taking of the issue. |
TO DO | Implemented | Assignee | Straightforward implementation. Verification is needed by the Reporter. Assignee field is change to: Reporter. |
TO DO | DONE | Assignee | Straightforward implementation. Verification is done by the Assignee. Usually the Reporter is the Assignee. |
In Progress | TO DO | Assignee | For some reasons the Assignee needs to stop working on this issue. |
In Progress | DONE | Assignee | Straightforward implementation. Verification is done by the Assignee. Usually the Reporter is the Assignee |
Implemented | DONE | Reporter | The Reporter as successfully verified the issue. Resolution code is mandatory |
Note: Once the Release Naming is approved, we will all use same naming convention in JIRA Release.
Otherwise, it makes it very difficult: