The following figure shows the states of an issue and helps understand the issue life-cycle in general ( Issue-Status, Issue-Resolution).
For more details how to report a new issue look at the Issue Reporting Guidelines.
Assigning is done by checking the Reassign issue to radio button in the issue form and filling in the a valid netbeans.org address (for some subcomponents it's done automatically).
Developers can accept issues by selecting the Accept issue button in the issue form (status changed automatically to STARTED). Developer shouldn't accept an issue until she's going to actively work on it. In other words, the STARTED == "Don't touch, I'm working on it."
The evaluation of an issue involves the following:
- Checking that the priority is correct according to the Bug Priority Guidelines
- Checking that the bug is assigned to the right component and the right owner
- Determining whether the bug is reproducible or not (or whether it is random)
- Checking whether the issue is a duplicate of another issue
- Adding a comment to the issue that adds any applicable information - either acknowledges the problem or asks for more information, justifies the priority (if it was changed by the evaluator), describes the required fix (if known) etc.
- If applicable, changing the status accordingly to FIXED, WORKSFORME, INCOMPLETE, DUPLICATE etc.
- Setting the target milestone to a value different that TBD (see below)
Specifically, evaluation does not require the following:
- Determining the root cause of the bug in the code
- Deciding about the approach of the fix
The issue is considered evaluated if Target Milestone != TBD. The Bug Dashboard also takes this into account. The values of Target Milestone have the following meaning:
- Upcoming release number - if it is believed that the bug is fixable in the current code base for the upcoming release
- Next - if it is known that the bug is not fixable in the current code base (as it would require large or risky changes) and needs to be postponed to the next release. This target milestone will be automatically changed to upcoming release number after recent Code Freeze day.
All newly reported issues should be evaluated by responsible developer as soon as possible:
- P1,P2 in a week
- P3 before end of selected Milestone of upcoming release
Responsible developer updates the issue with information that might be useful to people reviewing the fix (what was changed and how, what files were affected, point out potential side effects, suggest test cases).
All fixed issues should have the Hg changeset revision in comment field. (You can use simple notation like #0123456789ab and it will be hyperlinked for anyone using BrowserTools.)
Responsible 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.
If the issue is an instance of another issue it should be marked as DUPLICATE. Issues with poor and less comprehensive descriptions should be closed as duplicates of issues with better and more comprehensive descriptions.
Requesting more information
The issue is not complete, we do not have enough information to resolve/fix it appropriately, so there's no further action to be taken and it's closed as INCOMPLETE. Reporter is asked to reopen issue once she provides requested data.
The issue is irrelevant and there's no further action to be taken on it. Resolution flags that can be used:
- INVALID - error or misunderstanding on the user's side or summary/description is not in English
- WORKSFORME - we are not able to reproduce the reported problem and we can't find where the problem is even on user's setup
- WONTFIX - agree this is an issue, but we do not plan to fix it in next 2 product codelines (typically used for bugs in JDK, bugs that need risky/huge architectural changes, rewrites of big portion of code).
Reporter (she has the knowledge, test cases, tools and needed platforms) or QE should verify issue by changing the status to VERIFIED. It's expected to note important details (tested build number, test cases tried, observed behavior) and check the target milestone value refers to the correct release version.
Anyone can change the status to REOPENED state, when she finds that issue has not been successfully resolved. She has to provide appropriate comment (why the issue should not be considered resolved).
The CLOSED state is being used for issues that are too long time in state VERIFIED. Closing is done by QE, when a new version of the product is released
The ...WAIVER_APPROVED keyword is being used for issues that we are not able to fix in recent release, it's usually requested by Development and follows WaiverProcess for particular release. Issue can't be waived more than 2 times, so the issue has to be FIXED or marked as WONTFIX afterwards.
Handling of Issues
The document Handling of Issues in Issuezilla specifies rules how to handle with issues.