Guidelines for managing features in Issue Tracker. Use the following guidelines when creating issues to track enhancements and features using Issue Tracker. Issue Granularity Each team should decide at what level of granularity "feature" issues should be created and managed. Our goal is to track feature development into the specific [GlassFish milestones|^GlassFishV3Schedule#section-GlassF%20ishV3Schedule-GlassFishServerOpenSourceEdition3.1] so consider a granularity that allows us to achieve this. Issues do not need to be filed for every task - but could do so if the project wished to track work by developer and milestone. Consider a granularity defined by the "Feature ID" as identified in the Scope section of the project wiki as a good starting point for feature issues that need to be created. If the feature is large with major components of the feature being delivered into multiple milestones the work for each milestone should be represented as seperate issues. An umbrella issue can be created to group the related issues together. For example:
111 Cluster support
222 Cluster lifecycle support
333 Cluster configuration
444 Dev Tests for Cluster Support
In the above example issues 222, 333, 444 can be targeted to different milestones. Issue 111 can be closed when its dependencies have been resolved. Type Issue should use one of these three types:
Type |
Descripton |
Enhancement |
An improvement to an existing feature. |
Feature |
An addition to the software to add a piece of functionality that does not yet exist. |
Task |
An activity to be done on behalf or in support of a feature or enhancement. Tasks do not typically require direct changes to the code base. |
Priority Use the priority assigned to the feature ID from the project wiki page. Generally P1, P2 or P3. Found in Version For features targetted for 3.1 use 3.1. Assign To Assign the issue to the primary developer who will do the implementation. Summary Provide a useful summary. This can by copied from the project's wiki. For example: INFRA-005: Support create/delete/list-cluster Description At a minimum provide a link to the project's wiki. For example:
For details of this feature see:
3.1XYZ
A better description would be to provide details of the feature in the issue's description field with a link to the wiki for additional details. Post-submittal After the issue has been submitted the following fields should be updated. Target Milestone Update the Target Milestone. Choose one of the 3.1 milestones provided in the drop-down list (e.g. 3.1_ms02, 3.1_ms03, etc). Dependencies Is the issue depends on other work being completed. Update the "Issue NNNNN depends on:" field with the id's of the issues this issue depends on. Update Project Wiki Page As the "feature" issues are created update the project's wiki page with the pointers to the issues. This information can be maintain in the Milestone Schedule table. Value Add Features We are currently investigating the best tool to use to track these items. Other java.net projects (e.g. MQ) The above guidelines can be utilized for tracking features for other non-GlassFish projects as well. Separate reports will be generated for these projects. Projects in this category are: MQ, UpdateCenter |