Quick JIRA Manual to create an issue. M.F. Gómez de la Cruz

Size: px

Start display at page:

Download "Quick JIRA Manual to create an issue. M.F. Gómez de la Cruz"

Adam McKenzie
5 years ago
Views:

1 Quick JIRA Manual to create an issue M.F. Gómez de la Cruz

2 Create new JIRA case

3 Select Project from the pulldown list

4 Select Issue Type from the pull-down list

5 Type a title that summarizes the issue

6 Select Priority from the pulldown list Blocker: Reserved for catastrophic failures exceptions, crashes, corrupt data... They must be fixed immediately. Critical - These may refer to unhandled exceptions or to other "serious" bugs that only happen under certain specific conditions. No hard limit for resolution time, but should be fixed within the week (hotfix) and must be fixed by next release. Major - Usually reserved for perf issues. Anything that seriously hampers productivity but doesn't actually prevent work from being done. Fix by next release. Minor - These are "nuisance" bugs. Fix for this release if there are no higher-priority issues, otherwise the following release. Trivial - Cosmetic issues. They'll get fixed if the fix only takes a few minutes.

7 Optionally,select as many Components as needed from the pull-down list Components are sub-sections of a project. They are used to group issues within a project into smaller parts. This should contain the different application names for that project.

8 Optionally, you can schedule an issue

9 Type the name or select from the pull-down list the person(s)

10 Type your name

11 Insert the environment

12 Describe the issue

13 Optionally add attachments (screenshots, files )

14 Optionally, enter a time estimation

15 Enters the reporter if you are not the original reporter

16 Enter tags for helping filtering

17 Create issue

18 Components description (Tags) Change Request: Design Errors - As in, we misunderstood the spec and the feature doesn't do what it's supposed to do at all, or does it so poorly that it's unusable. This is the highest priority for a change request, but it is still a priority 2 - a change request can never take precedence over a blocker bug. These must be fixed by next release Important - Significant cost savings (or profit potential, depending on the kind of software), major performance enhancements, anything that will make the app more awesome. Or anything escalated to this level by management - this is the highest escalation level for a feature. Expected to go into next release but may be cut in the event of a time or cash crunch Normal - Basically something that a lot of people want (or one VIP wants), and the rationale for it is clear and reasonable, but there's nothing special about it that would warrant it taking precedence over any other run-of-the-mill request. Minor performance tweaks, add this field or this button or this report, make this sort as a number instead of alphabetically, that kind of thing. These get assigned to the next release, but are the first to get cut if any delays come up Low-Impact - Layout changes, wording changes, changes that might conflict with the baseline requirements, pie-in-the-sky features that could take months to implement, etc. These automatically get assigned to a future release unless we're not working on anything more important (which is... never). Often when the next release does go out, these will get deferred to an even further release as more important requests pile up Optional - We don't actually call it optional (I think officially it's "Time Permitting"), but that's pretty much what this is. Generally reserved for two classes of change: (a) dumb requests that we know will just annoy most people ("show a confirmation dialog every time the user tries to click this button"), and (b) internally-conceived features that we can't cost-justify above official requests. Not assigned to any release Application Type: DAQ Analysis Test Reporter Type: Operator Developer Tester Where: Bloc4 Control Room Kind of Issue: Programming Documentation GUI Internal Priority: Very High - Concerns the first issue to be solved if exists one more important between the High ones High - Concerns the selected issues that has to be solved during the week Medium - Concerns the issues that may be solved during the week after finishing the High ones. Normally, these issues will be converted into High the week after. Low - Concerns the not important issues, issues that can be solved in very short periods of time or with low impact. May be solved when there s time. Very Low

Max Score / Max # Possible - New ABI Gradebook Feature

Max Score / Max # Possible - New ABI Gradebook Feature OPTIONAL MAX SCORE TOOL (*EGP users: This was the Max Score / Points feature in EGP.) This feature is for teachers who want to enter Raw Scores for