This is what the different attributes mean and how they are used in the ArgoUML project. This is to be read as an addendum to the Tigris documentation of issues and for that reason it is not a complete list.
Issue Types
The issue types are categorized as follows in ArgoUML:
- FEATURE an addition to the software to add a piece of functionality that does not yet exist.
- DEFECT - a problem with an existing feature that is not developed to spec or does not work as designed. These are often referred to as "bugs."
- ENHANCEMENT - an improvement to an existing feature.
- TASK - A change that is of no obvious benefit from the users perspective. E.g. refactoring to improve code structure, creating JUnit tests etc.
- PATCH - This type is usually used under agreement between an ArgoUML developer with commit rights and some other party such as a student or other contributor. When the contributor completes their work they attach their patch to the issue, change its type and assign it to the developer who has agreed to review. That developer should commit or reject and change the type back to its original state.
Priorities
The priorities of DEFECTS are used in the following manner in ArgoUML:
- P1 - Fatal error
- These issues are blockers for all releases.
- Examples: ArgoUML cannot start; Crashes program, JVM or computer; and Significant loss of user data.
- P2 - Serious error
- These issues are blockers for stable releases.
- Examples: Information lost.
- P3 - Not so serious error
- Examples: Functions not working; Strange behavior; and Exceptions logged.
- P4 - Confusing behavior
- Examples: Incorrect help texts and documentation; Inconsistent behavior; UI not updated; Incorrect javadoc and most things affecting the development environment.
- P5 - Small problems
- Examples: Spelling errors. Ugly icons. Excessive logging. Missing javadoc.
Resolutions
- LATER
- Used to denote that a certain issue cannot be resolved until some special upcoming and planned-for event has happened. The event in question is noted in the target milestone.
- Events can be things like, dropping support for a JDK version, changing the version of UML that we support, or replacing some central mechanism within ArgoUML. Once they have a target milestone registered, they are considered events.
- REMIND
- Not used.
- Rationale: Each issue have basically three states:
- NEW/STARTED/REOPENED - To be resolved
- RESOLVED/VERIFIED - To be closed
- CLOSED - Finished.
- The statistics is based on this and persons looking for issues to resolve look among the "To be resolved"-group (the web pages to help in this are set up in this way). This is also in sync with our release process.
- Looking at it from a single persons perspective an issue is either a "I could work with this issue but I currently don't", "I am currently working on this issue", or "I am now done with my work on this issue". For a resolver this is corresponds to NEW/REOPEN for the first group, STARTED for the second and RESOLVED/VERIFIED/CLOSED for the third.
- The RESOLVED/REMIND does not fit this. They risk to be hanging in the RESOLVED/VERIFIED state because nobody understands where they should go from there. It is not clear who is responsible to move them forward. The person that "resolved" them or someone else. Someone risk to think that there is nothing left to do since it is resolved and if so his options of doing work are reduced which could lead to that he actually does less with ArgoUML than he else would.
- To amend this we have made two things:
- Decided that we don't use the RESOLVED/REMIND states.
At every release, as part of the release process, clean up issues that for some mysterious reason ended up in these states (See Making a release, 6, f)
- If you plan to solve an issue now, assign it to you, start it, and set the target milestone to the release you plan to have it solved. This will signal to everyone that you have the responsibility, will pursue it, and your time plan.
- If you don't plan to solve this now, leave it in the "up for grabs"-pile (as not resolved). Somebody else might want to work with it.
- If you know that an issue cannot be resolved now because it requires that another issue is solved before, register the other issue as "depends on" and leave the issue in the "up for grabs"-pile (as not resolved).
- If you know that an issue cannot be resolved now because it requires some big event to take place, put the milestone for that event in the target milestone and resolve the issue as RESOLVED/LATER.
- WORKSFORME
- This means that it works in a released version of ArgoUML. State the version in the comment.
- If the version stated by the reporter in the issue is not the same as the version in the comment then this probably means that problem was fixed in some release without anyone noticing that this problem was fixed.