OVERVIEW ON THE SPR SYSTEM (JIRA)

1. General Introduction
2. Basic Workflow of the System
3. Best Practices
4. User Interface: Submitting new issues
5. User Interface: Searching issues

---

General Introduction

The SPR System is meant to be used by internal or external users of the ALMA software. Whenever an error in some code or in the documentation is found or a change to improve the behaviour of an existing software seems needed, you can submit a Software Problem Report (SPR, also known as issue in JIRA terminology) as explained below. To make easier, the software code is grouped in packages, containing related software modules. Each SPR must refer to the proper package.

For latest information on automatic SPR Board call up messages and similar info please see the SE TWiki page AlmaSoftwareBoard

The SPR system is currently based on Atlassian's JIRA Enterprise Edition, located in Chile and maintained by the Joint ALMA Office. It supports the vast majority of Browsers currently available on the market. It can be found at http://jira.alma.cl.

Basic workflow of the system

Problem submitted by a user (the Reporter)

Assigned to almasccm (Alma Software Configuration Control Manager: he/she is the responsible person for collecting all the SPRs and maintening the system. He/she can create/modify components and users)

Notification to all relevant people

Comments are added by the persons reponsible for the component mentioned in the ticket. Also, comments may be added by any user known to the system

The SPR is discussed in the SCCB (Software Configuration Control Board) meeting and a Responsible Person (Assignee) is appointed for the problem. The SCCB Meetings are called by almasccm and the responsible persons for each package are invited. During the meetings, it is decided whether to accept or not the SPR, the person to assign the SPR to and the deadline for solving the SPR.

Responsible works on the problem

Responsible can resolve the SPR ( by adding a final remark on it and putting it into one of the possible resolution states) whenever he solves the problem.

The Reporter may close the problem.

---

When a SPR is submitted, the almasccm, a list of people defined by the pakage and any names/addresses in the 'cc' field will be notified with all details of the problem. After this point, any change in 'status' will result in all the listed people above and the 'Responsible' being notified of the changes on all problem details.

Upon closing, a 'Resolution' value must be set and a remark must be added on the 'Comment' field. The system does not allow the resolution of the ticket unless a proper resolution value has been set. Legitimate values are Fixed, Won't Fix, Duplicate, Incomplete, Cannot Reproduce

1. REMARK: when a problem is submitted to JIRA, it is assigned to the almasccm. This user is the only one who can progress the 'status' of the report from 'open' to 'assigned' and therefore initiate the continuance of the workflow. After this point, the 'Assignee' user as well as the almasccm can progress the 'status' of a problem.

2. REMARK Versions are created at project level by the JIRA administrator. Project planners will have to supply a matrix of Version Names/Descriptions/numbers and these are then added to the system.
3. REMARK: (Urgent SPRs) There may be special circumstances, such as problems found while commissioning, that require immediate attention. Under these circumstances the originator is allowed to prompt the relevant person(s) to provide to fix to without waiting for a decision from the SPR board. It has to be noticed though that:
   • an SPR must be filed, nevertheless, and the originator must outline the urgency of the matter. These SPR's should be explicitly labeled as "URGENT"
   • common sense and use with restraint must be exercised.
   • urgent SPRs shall be subject to special scrutiny.
4. Disputes between the originator and the respondent of an urgent SPR shall be brought to the immediate attention of ALMA software management.

DIFFERENCES WITH REMEDY / BEST PRACTICES

1. any resolved issue must also be actively closed. Closing an issue can only be done by the Reporter or by almasccm.
2. that an issue has been assigned does not automatically mean that it is in progress. It has to be explicitly put in progress state.
3. Watchers can be removed by other people, this is not the way it should be, but for the time being people are asked to refrain from doing so.
4. It is not possible to have automated component based notification for more than one person. The only solution will be to create fake users which have a mailing list as a regular mail address.
5. The edit issue feature, which we've not disabled, should be used with care. Users are not supposed to arbitrarily change a DueDate or a Priority. But they might have to edit the "AdditionalUsers to email" field

Fields on Create Issue page:

Project	Value to be selected: ATF-Computing
Issue type	Possible values: Bug A problem which impairs or prevents the functions of the product. New feature A new feature of the product, which has yet to be developed. Task A task that needs to be done. Improvement An improvement or enhancement to an existing feature or task. Action item A directive opened by the panel during a Design Review RID Review Item Discrepancy
Summary	It is a brief description to quickly identify the issue.
Priority	It the initial assessment of the urgency of this Issue, as perceived by the originator.   Blocker Blocks development and/or testing work, production could not run. Critical Crashes, loss of data, severe memory leak. Major Major loss of function. Minor Minor loss of function, or other problem where easy workaround is present. Trivial Cosmetic problem like misspelt words or misaligned text.   Priority is liable to be changed during SCCB meetings.
Due date	Deadline
Components	This field specifies to which Package the issue is related.
Affects Version/s	Version of the project which are affected by this issue
Fix Version/s	Versions of the project which will resolve the issue
Reporter	The user who entered the issue into the system
Environment	Environment of the issue
Description	The complete statement of the problem
Original Estimate	Time estimate
Additional Users to email	This Field should be filled with all the people that need to be notified by e-mail about the Issue progress

 

Additional Fields on Query page:

Queries can be done on all above mentioned fields and on the following ones:

Text search on fields: Summary, Comments, Description, Environment.	Query Syntax
Dates and Times	On creation, update, due time
Status	Each issue has a status, which indicates the stage of the issue. In the default workflow, issues start as being Open, progressing to In Progress, Resolved and then Closed. Other workflows may have other status transitions. Open The issue is open and ready for the assignee to start work on it. In Progress This issue is being actively worked on at the moment by the assignee. Reopened This issue was once resolved, but the resolution was deemed incorrect. From here issues are either marked assigned or resolved. Resolved A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed. Closed The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.
Resolution	An issue can be resolved in many ways, only one of them being "Fixed". The defined resolutions are listed below. You can add more in the administration section. Fixed A fix for this issue is checked into the tree and tested. Won't Fix The problem described is an issue which will never be fixed. Duplicate The problem is a duplicate of an existing issue. Incomplete The problem is not completely described. Cannot Reproduce All attempts at reproducing this issue failed, or not enough information was available to reproduce the issue. Reading the code produces no clues as to why this behavior would occur. If more information appears later, please reopen the issue.

 

Please report to: < alma-sw-semgr@eso.org > any major problem you encounter using the system.