Skip to end of metadata
Go to start of metadata

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

Compare with Current View Page History

« Previous Version 9 Next »

OpenECOMP Bugs, Epics, Stories, and Tasks are tracked in the JIRA system at https://JIRA.openecomp.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.

Get a Linux Foundation Account

If you intend to file or update information in JIRA, you will need a Linux Foundation identity to access the OpenECOMP JIRA account. Read this page for instructions.

JIRA User's Guide

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

JIRA Setup for OpenECOMP

OpenECOMP defines a number of different projects for the various subsystems and areas of OpenECOMP.

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

Viewing Issues in JIRA

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:

Reporting a Bug

To report a bug against OpenECOMP, 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.

  • Select the Project against which you want to open the Bug
  • Ensure that you select the Issue Type "Bug"
  • Provide a concise description of the error
  • Select Component if the project provides greater granularity on component breakdown
  • Provide a detailed description of the issue
  • Attach any supporting information (logs, stack trace, screen shots, etc…)
  • Assign the bug to yourself if you plan to fix the issue; otherwise, leave Assignee blank
  • Select Create at bottom of screen

Proposing a New Feature

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.

  • Provide a clear and concise Summary of the new feature
  • Provide detailed Description of the new feature
  • Select Create


JIRA Issue Type

There are 4 JIRA Issue types

Epic:

  • Captures a large body of work
  • It is essentially a large user story that can be broken down into a number of smaller stories
  • It may take several sprints to complete an epic
  • Usage: Usually Epic are created by PTLs

Story:

  • A Story or user story is a software system requirement that is expressed in a few short sentences, ideally using non-technical language
  • Non-technical language, express user needs
  • Usage: Usually Story are created by PTLS

Jira Story

Task:

  • A Task is typically one of many tasks that make up a story
  • Contains description of individual work item (detailed, technical)
  • Breaks-up stories into digestible workloads
  • Can be shared, assigned, relate to, depends/depended on by, blocks/blocks by
  • Usage: Anyone can create a task and assign to himself or someone else

Bug:

  • A defect, an error, a flaw that requires either code or documentation change
  • Usage: Anyone can create a bug and assign to himself or someone else

JIRA Statuses

There are 4 distinct JIRA Statuses

  1. TO DO: Status of Issue Creation
  2. In Progress: Issue is currently being worked out
  3. Implemented: Issue has been worked out Reporter MUST verify
  4. Done: Verification Passed. Use Resolution code

JIRA Transition

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.

FromToActorComment
TO DOIn ProgressAssignee

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 DOImplementedAssignee

Straightforward implementation. Verification is needed by the Reporter.

Assignee field is change to: Reporter.

TO DODONEAssignee

Straightforward implementation. Verification is done by the Assignee.

Usually the Reporter is the Assignee.

In ProgressTO DOAssignee

For some reasons the Assignee needs to stop working on this issue.

In ProgressDONEAssignee

Straightforward implementation. Verification is done by the Assignee.

Usually the Reporter is the Assignee

ImplementedDONEReporter

The Reporter as successfully verified the issue.

Resolution code is mandatory

JIRA Resolution Code

  • Unresolved (by default)
  • Done: Issue is fixed, closed
  • Cannot Reproduce (self explicit)
  • Duplicate: Provide duplicate issue number
  • Won’t Do: Explain reasons why the issue will never be fixed

JIRA Version

  • Affects Version/s: Project version(s) for which the issue is (or was) manifesting
  • Fix Version/s: Project version(s) for which the issue is (or was) fixed

Note: Once the Release Naming is approved, we will all use same naming convention in JIRA Release.

Recommendations for writting Proper JIRA Issue

Do and Don't

  • 1 record per Jira Issue. Do not report multiple bugs within one single JIRA Issue.

Otherwise, it makes it very difficult:

    • to have a focused discussion
    • to track progress
  • Even if you encountered several issues at once, you should open a separate JIra Issue for each and Link issues together.
  • Keep ongoing communication in JIRA. Email do not scale. Email are lost. Use JIRA to provide all necessary Logs, code sniptets, screenshots.
  • You case you need to get notified on a change: Use JIRA Watch capability.
  • Assignee: By default, while creating a JIRA Issue, the PTL is assigned. Issue can be re-assigned by anyone.
  • Even if status is Done, issue can be re-opened. Nothin is preventing to re-open a closed JIRA Issue.
  • The JIRA Issue Summary should precisely describe the problem. "X is broken" is not a helpful description. "X is doing Y instead of Z" is much better.

Description Field


  • Provide more details on the issue
  • Describe the error you see, and describe the behavior expected
  • Provide steps to reproduce the error
  • If possible, provide actual commands to run
  • Attach logs or screenshots
  • Try to reduce the problem to the smallest possible use case to make it easier to reproduce the bug and to test the solution
  • Embed code in the description and use formatting
  • Provide info on: OS, Browser, Java version,…








Embed Code


Describe environment

  • No labels