Handling of Issues in Issuezilla

Mission Statement

Define the rules and guidelines to be followed when dealing with information stored in Issuezilla (issue tracking system for the NetBeans project).

Involved Parties

There are a number of parties interested in the issue tracking processes.

• Internal Developers - developers working on the core of the platform and the basic modules that are part of the standard distributions. They are mostly focused on the latest version of the product and are interested in their unresolved issues.
• External Developers - developers working on modules based on the NetBeans platform. They are usually developing against the latest stable version of the product and thus may not be familiar with the changes in the new version being developed.
• Users - they are our customers. They are interested in the open issues in the version they're working with. If they are experiencing any problem, they may also want to know, when and in what version it will be fixed.
• QA engineers - they live and die with the issue tracking system. They need to be aware of all opened issues in the version under development as well as they need to track issues surviving from previous releases.

Other categories may exist and one person may be a member of multiple groups at the same time. As seen in the list, the information required by different groups of stakeholders may differ.

Versions

It is impossible to see the information stored in the IssueZilla from the cvs view. There is nothing like the "main trunk" nor "branches". The issue is found in some version of the product and it exists until resolved in the same or any subsequent version.

Process:
• default Version is Dev
• this version is used until the specific branch is created
• Dev version is renamed to X.X version
• a new Dev version is created

Issues are reported against versions from which has been the build created. It means there could be a time, when issues are reported against more than one version.

Target Milestones

Issuezilla provides a field that suggests at which point the issue will (or should) be addressed. We are using Target Milestone also for evaluating issues.

Process:
• define new (next) Target Milestone when last stable version is released
• all resolved issues should have TM!=TBD
• issues with TM==VersionX have to be reevaluated if they are opened after Feature Freeze of VersionX and they won't be fixed in the targeted release

Verifying Issues

This is defined in Issue Life-Cycle document. Reporter are not used to verify issues.

Process:
• reporters are expected to verify their issues
• high priority issues (P1,P2) have to be verified before release date to approve the fix of the problem
• QE will verify automatically issues of last but one version