Page History

...

1. Ensure that the bug has test code and steps
   If a bug does not have enough information to recreate it, then the bug will be closed as incomplete.  There are some exceptions to this rule, for example, the submitter might already know that the bug cannot be recreated easily.  In general, we require sample code and numbered steps before we can fix a bug.
2. Ensure that the bug has a meaningful title
   Very often, we process huge lists of bugs.  It is very helpful if the title of the bug describes is as accurately as possible without being too long to read.  Bug titles like "XXX doesn't work" require us to click on the bug every time or remember exactly what doesn't work every time we process bug lists.
3. Ensure that the following are set correctly:
   1. IssueType - <MORE HERE>
   2. Component - <MORE HERE>
   3. Priority - <MORE HERE>
   4. FixVersion - <MORE HERE>
   5. Assignee - <MORE HERE>
   6. Key Words - <MORE HERE>
4. Perform an initial assessment
   When a bug submitter provides steps and code, the bug needs to be recreated.  If the problem does not happen, the bug may have already been fixed or the submitter may be mistaken about the issue.  If the problem does happen, then it might be a regression.  This is quite easy to prove by running the code under older release, starting with the last update release (XuYY) and moving backward.
5. Select 'Evaluation Complete'
   This should only be done by a project leads lead or technical leadslead.  It is important for project leaders to keep track which bugs are being fixed right away and which are being deferred or moved to another release.  This is especially critical during ramp down phases and milestones.

****** OLD CONTENT ***** IN PROGRESS *******

...