Issue Life-Cycle

The following figure shows the states of an issue and helps understand the issue life-cycle in general
(Issue-Status, Issue-Resolution).

Issue handling in details Reporting Assigning Accepting Evaluating Fixing Duplicating Rejecting Reopening Closing

Reporting Issues

For more details how to report a new issue look at the Issue Reporting Guidelines.

Assigning Issues

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 automaticaly).

Accepting Issues

Developers can accept issues by selecting the Accept issue button in the issue form (status changed automaticaly 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."

Evaluating Issues

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 that the issue is not 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.
• 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 if fixable in the current code base for the upcoming release.
• Future - 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.

All newly reported issues should be evaluated by responsible developer as soon as possible:

• P1,P2 in a week
• P3 before Feature Freeze of upcoming release

keyword INCOMPLETE :
If the issue report doesn't provide enough information, the issue is marked with this keyword.
Reporter is expected to provide the requested information within 4 weeks (if not issue is closed as RESOLVED WORKSFORME / WONTFIX / INVALID).

Fixing Issues

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 CVS commit log in comment field.
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.

Duplicating Issues

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.

Rejecting Issues

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.

WORKSFORME - it isn't impossible to reproduce the reported problem.

WONTFIX - won't be fixed in this product codeline (typically used for bugs in JDK).

Note: Don't use REMIND,LATER.

Verifying Issues

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.

Reopening Issues

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).

Closing Issues

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

Handling of Issues

The document Handling of Issues in Issuezilla specifies rules how to handle with issues.

---

Issue States
State	Set by			Relevant Status Change
	reporter	developer	QE
New	X			status = NEW target_milestone = TBD (set automaticaly)
Evaluated		X		target_milestone != TBD
Incomplete		X	X	keyword = INCOMPLETE
Assigned	X	X	X	assigned_to = somebody@netbeans.org
Accepted		X		status = STARTED
Rejected	X	X	X	status = RESOLVED and resolution = DUPLICATE/INVALID/WONTFIX/WORKSFORME
Fixed		X		status = RESOLVED and resolution = FIXED and target_milestone = x.y
Verified	X		X	status = VERIFIED
Reopened	X	X	X	status = REOPENED and resolution = blank (set automaticaly)
Closed			X	status = CLOSED