NRAO Home  >  Green Bank  |  Wiki Topic:    GB > Software > BugFixing

Changes | Index | Contents | Search | Statistics | Go

Bug Fixing Guidelines and Procedures

• Entering a Bug into JIRA
  • JIRA Administration
• Should I work on the bug right away?
• Ok, I need to work on this bug. What now?
• Ok, I can't (or don't need to) work on the bug right now. What happens to it?

There are at least 3 ways you might find out about a bug or task to be completed.

1. The bug is on one of our lists, e.g. AstridReports, CurrentReports, or JIRA.
2. You were specifically told about a bug or found it by responding to an operational support item.
3. You were reading the Operators Logs and you noticed something that should be fixed.

Entering a Bug into JIRA

The bug should be entered into JIRA. This can be done by visiting http://bugs.aoc.nrao.edu

JIRA Administration

• View your profile: http://bugs.aoc.nrao.edu/secure/ViewProfile.jspa
• Contact an administrator: http://bugs.aoc.nrao.edu/secure/Administrators.jspa
• For more information on JIRA, see: http://www.atlassian.com/software/jira

Should I work on the bug right away?

Once the item is logged into JIRA, you must decide whether or not to work on it.

1. Does the issue require an emergency fix to be patched into a software product? The answer is YES if:
   • No workaround is available for the critical issue at hand, AND
   • A scheduled astronomical observation has failed and changes must be made for the observation to continue, OR
   • Routine operations (including commissioning) are at a standstill until the fix is made, OR
   • A solution has been found to a critical problem that has been deferred from a previous release, OR
   • A change is low risk, low impact, and on the critical path for high site wide priority work being done in other divisions.
2. If the issue requires an emergency fix, work on the bug.
3. Does the outstanding issue block someone from progressing in their work, or supporting routine operations? If so, work on the bug.
4. Is the Level of Effort (LOE) small compared to the value that will be delivered by solving the problem? If so, work on the bug.
5. Are you on track to complete your commitments for the current development cycle? If so, work on the bug.
6. Have you helped out with other SDD commitments for the current development cycle wherever possible, and there is nothing left for you to do? If so, work on the bug.
7. If you answered NO to all of the above, don't work on the bug.

Ok, I need to work on this bug. What now?

Work the problem, being sure to inform your Division Head that you are changing gears, and why you have chosen to do this.

Ok, I can't (or don't need to) work on the bug right now. What happens to it?

But what happens to it, you ask? Obviously, the issue will remain a problem (and potentially a bug) until it is fixed.

• Each development cycle, the list of bugs are considered during the cycle planning meeting. If it is deemed to be a priority, the bug will get scheduled via this forum. Just make sure that AmyShelton is aware of it, so that it can be considered.
  • Unless system reliability and improvements are higher priority than project work, usually only one or two items will be selected for completion.
• You can feel free to pick up any bug item and work it at any time, being sure to remember that it becomes your responsibility to filter out the requirements that are not shared by more than one astronomer. Often, a request will be made that is at odds with the needs of other groups, or with observing in general. A good rule of thumb is that if at least three people agree with the change, it is a viable change. We must ensure that we prevent investing time in work items that are not congruent with the overall goals of the site.
  • If you decide to work on a bug, you might consider writing an MR. An MR is a good idea if the bug fix requires more than minimal effort and/or affects more than a single system component. Just as with any MR, make sure that it goes through the CCC (e-mail gb-ccc) and has a sponsor.