Who Does What When…
Issue Life-Cycle Diagram
Appendix: Issue State Table
Who Does What When…
The reporter (person who files the issue) is supposed to be familiar with and follow the Issue writing guidelines.
At the very minimum, the reporter should provide the version of the product the reported issue was encountered in, platform, priority, short summary and detailed description of the problem. The priority should be set according to the Bug priority guidelines. In addition, the reporter can also attach any relevant files, set keywords, put other users on the interest list, vote for the issue, etc.
A newly reported issue is automatically set into the NEW state and the target milestone field is set to TBD. The following figure shows the states of an issue and helps understand the issue life-cycle in general.
Issue Life-Cycle Diagram
Notice that not all states of an issue are shown on the figure below. The issue-status is displayed in blue and the issue-resolution in the green color.
A person responsible for dispatching newly reported issues can assign issues to developers. Typically, that person would be a module owner, another developer, or a QE person. Assigning is done by checking the Reassign issue to radio button in the issue form and filling in the a valid netbeans.org alias.
Some subcomponents in Issuezilla have default owners. When a new issue is filed against such a subcomponent, it is automatically assigned to the subcomponent’s default owner.
Developers can accept issues by selecting the Accept issue button in the issue form. An accepted issue is put into the STARTED state. The developer shouldn’t accept an issue until she’s going to actively work on it. In other words, the STARTED state also means “Don’t touch, I’m working on it.”
Both assigning and accepting of issues are optional steps that may be skipped, especially when the issue resolution is straightforward. Regular users and external reporters not familiar with product internals shouldn’t need to care about these two steps much.
All newly reported issues should be evaluated by the developer responsible for the area (component or subcomponent) the issue has been filed against. The developer should read the bug report, try to reproduce the problem, perform early analysis of possible causes and eventually propose solutions or workarounds. The results of this step should be documented in the description field. The developer should also estimate in which codeline or release the issue is likely to be addressed and indicate this by setting the target milestone. It is preferred to set TM to specific release value if the issue will be (or will be very likely) fixed for this release. Otherwise, a special target milestone value future or TBD should be used. Technically, an issue with target milestone value different from TBD is considered evaluated.
Newly reported issues should be evaluated as soon as possible to identify potentially serious problems early and avoid unnecessary duplicates. Issues with priority levels 1 or 2 should be evaluated in 1 week. All issues with P3 priority should be evaluated at least before Feature Freeze of the nearest release.
Sometimes, the original issue report may not provide enough information for successful reproduction and evaluation. In such cases, the developer can mark the issue with a keyword INCOMPLETE and request more information from the reporter. The reporter is expected to provide the requested information. As soon as the information is available, the developer should remove the INCOMPLETE keyword.
If the reporter doesn’t respond within 4 weeks, the developer is free to close the issue as RESOLVED WORKSFORME, WONTFIX, or INVALID.
Changes to the source code — either bug fixes or issue implementations — are typically done by the developer responsible for the respective area.
After applying the change to the code, the developer is expected to update the issue with information that might be useful to people potentially reviewing the fix in the future (other developers, testers, users). The information might include details on what was changed and how, what files were affected, point out potential side effects, suggest test cases, etc. It’s also a good idea to provide a snapshot of a respective commit log or even link to the diff in the online cvs browser.
In addition to that, the developer has to set the issues status to RESOLVED FIXED and update the target milestone to a value corresponding to the earliest public release the change will be effective in.
Anyone (a developer, QE person, user) who runs into an issue that is an instance of another issue should mark one of the issues as duplicate of the other one. This is done by changing the issue status to RESOLVED DUPLICATE and specifying the other issue’s id. Issuezilla will automatically link both issue reports.
It is highly recommended that issues with poor and/or less comprehensive descriptions are made duplicates of issues with better and/or more comprehensive descriptions, not vice versa.
Some issues may be rejected by the evaluator (typically the responsible developer). Rejecting means that the evaluator considers the issue irrelevant and there’s no further action to be taken on it, until anyone disagrees and reopens. Three types of resolution flags that can be used when rejecting an issue:
INVALID – Invalid issue report. Error or misunderstanding on the user’s side.
WORKSFORME – The evaluator was not able to reproduce the reported problem.
WONTFIX – Won’t/can’t be fixed in this product codeline. Typically used for bugs in JDK or 3rd party libraries. A pointer to more information should always be provided in such cases (e.g. link to the bug report in a 3rd party product bug database).
Note: Usage of other available resolution types REMIND and LATER is highly discouraged. Those types are deprecated and should not be used by anyone for any purpose.
A resolved issue should by primarily verified by the original reporter. It is assumed that the person who reported the issue has the knowledge, test cases, tools and platforms needed to reproduce the originally reported problem or requested behavior and thus is in the best position to verify that the resolution is correct. Alternatively, issues that are easy to understand and/or reproduce, or are not verified by the original reporter in a reasonable time, can be verified by the QE person responsible for the affected area.
The person who verifies the issue is expected to note important details of the verification process such as tested build number, test cases tried, observed behavior, etc. Last but not least, the person has to set the issue status to VERIFIED. She should also check the target milestone value to make sure that it refers to the right release version.
Sometimes, people tend to think that only FIXED issues need to be verified, while there’s no point in verifying duplicates and rejected issues. Although it’s true that fixed issues are the most important ones to be verified, other types of resolutions should be verified as well. By doing so, the reporter confirms that she’s fine with the resolution and finds it appropriate.
If someone — typically a person trying to verify the issue — finds out that the issue has not been successfully resolved, she can reopen the issue by putting it into the REOPENED state. A comment clarifying why the issue should not be considered resolved must be provided.
Technically, issues are considered closed when they reach the VERIFIED state. Issuezilla provides the CLOSED state, which is supposed to mean that the issue is dead and no longer applicable to any of the officially supported codelines. At netbeans.org, the CLOSED state is being used for issues that are too long time in state VERIFIED – issues filed against ancient versions of the product.
Closing is done by QE by modifying the status of multiple issues at once. Typically, when a new version of the product is released, verified issues fixed in the previous version are set to the CLOSED state.