This page collects information around handling issues (Bugs, RFEs (requests for enhancements), etc.) in IssueTracker. These documents look on worklow in more detail than our overview and the guidelines for reporting issues.
|A Bug's life time||
Describes the workflow for handling normal bugs - these is what you will probably encounter most in
If your're interested in what will happen to a bug you submitted, or if you want to help by triaging bugs, you should look at this workflow.
|FEATURE: Specification Writing||Describes the workflow for specifying a feature, accompanied in IssueTracker.|
|FEATURE: Implementation||Describes the workflow for specifying a feature, accompanied in IssueTracker.|
|FEATURE: Quality Assurance (QA)||Describes the workflow for QA'ing a feature, accompanied in IssueTracker.|
|QA for RFEs||
RFEs are "Requests for Enhancements" - these are those issues where people suggest new features
to be implemented, or existing features to be enhanced. This workflow describes how RFEs are handled by QA.
Note that QA is responsible for ensuring that RFEs are in a usable form before they're passed to team which evaluates RFEs.
|Evaluating RFEs||This workflow describes how RFEs are handled by the user experience team.|
|Regressions||This document describes the policy with respect to regression issues, i.e. issues describing broken functionality.|
|Basic IssueTracker Rules||This descument describes the very basic rules one should know - and respect - when submitting issues, or adding comments to issues, in IssueTracker.|
|Handling RFEs||This document proposes a handling for RFEs, to consolidate them (towards the planning of a new release) into so-called requirements. This allows to get a better overview about requirements people have to OpenOffice.org, and to decide, on a level which is more general than individual issues, about the focus for the next release(s).|
Last modified: $Date: 2007/02/23 10:42:34 $