![]() If the bug is a feature request, change the severity to enhancement.once a bug is validated, it goes to prioritization.the bug may be a user problem, or may be intended behavior - these get annotated with the reason/information and RESOLVED to INVALID or WONTFIX or WORKSFORME (generally, INVALID means the report is just bogus, WORKSFORME means the report is not a problem, and WONTFIX is used for things that are valid requests, but that the team can't do).the bug may get moved to another component/product.if there is no response within a week, close the bug (RESOLVED INVALID or WONTFIX) telling the submitter to re-open once they have more info.The bug remains in the NEW state until enough information is received to validate it. if the bug needs more information to be validated as a bug, add a request for more information/steps to reproduce, etc.verify if the bug is really a bug or if it belongs to this component.At the start of each day, each project/component team lead does bug triage.Bugzilla provides a mechanism to watch another email address and developers are expected to use this to watch the component owner's address to monitor the incoming bugs for their projects/components.Users may not change the Committer owned fields - this is enforced by social convention.The Committers "own": status, resolution, and priority.Users "own": component, version, platform, OS, severity, summary, and description.The Eclipse projects have different schemes for using Bugzilla, but a common one is as follows: The Bugzilla documentation describes the basic mechanics and outlines the bug lifecycle that is designed into Bugzilla: A common question new projects ask is "how should we use Bugzilla effectively?".
0 Comments
Leave a Reply. |