|This page is under development, there will be more content added soon. See the WEBSITE-662 EPIC for tasks related to this page, contributions are welcome!|
Developers don’t use the various issue states consistently. The following description just gives a broad overview. See here for a description of states in JIRA.
Issues start out as Open.
When work has begun but not finished, the Assignee will often mark the issue In progress.
When finished and a solution is checked in, the Assignee (or a bot responding to commit messages) will mark the issue Resolved
Some users also mark issues Closed after a fix is confirmed by others.
When an issue was resolved or closed before, but users still experience the same problem, they may set the issue to Reopened.
If an issue is considered to be a Duplicate, it will be marked as resolved, and the original issue will be linked. It’s not always the newer issue that gets closed as duplicate, sometimes it’s the older one, e.g. when the description in the new one is better, or the new one has more watchers. This depends on the developer resolving as duplicate. Duplicate issues should only be reopened when you have determined that they are not actually a duplicate of the linked issue, and for no other reason.
Issues may be found to be Won’t Fix or Not a Defect for various reasons, e.g. when a developer determines that the issue isn’t actually a problem with Jenkins.
Issues may be resolved as Cannot Reproduce when the developer is unable to reproduce the issue as described, e.g. because it may have been resolved since it was reported, or it is believed the issue is not with Jenkins.
Issues resolved as Incomplete do not provide a sufficient description of the problem.
When a developer decides to work on such an issue, the Assignee field is changed to that developer. It may be set to In progress while it’s being worked on.
When a fix has been integrated, the issue is usually marked Resolved (using the resolution Fixed), and sometimes marked Closed after the fix has been verified.