---

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

Table of Contents Issue Life-Cycle Reporting Issues Assigning Issues Accepting Issues Evaluating Issues Fixing Issues Duplicating Issues Rejecting Issues Verifying Issues Reopening Issues Closing Issues Handling of Issues Issue States

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

Accepting Issues

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

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

Use LATER resolution for issues that we don't plan to fix in this neither next release. The bugs reported via report exception or with votes/duplicates can't be resolved as LATER also this resolution can't be used for bugs with P1,P2 priority. Quality Engineering can reject this resolution in cases when the bug was reported as Voice of Customers.

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

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

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 possible to reproduce the reported problem. Issue should be marked as INCOMPLETE first, and unless more info is received in 4 weeks, then closed as WORKSFORME
• WONTFIX - won't be fixed in this product codeline (typically used for bugs in JDK).
• LATER - no plan to fix issue in this neither next product codelines

Note: Don't use REMIND.

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

Attachments