Please begin by checking Bugzilla to see whether your problem has already been logged.
Please note in your bug report the version of Chandler Desktop you are using to help guide us. You can do this by simply copying the name of the application as it appears on your computer. For more information: StepByStepBugReporting
Instructions for Dogfooders
|
First, check to see if your problem has already been logged: Open Bugs | Search Bugzilla
Please note in your bug report the OS, browser and version of the browser to help guide us. For example: Intel Mac | Firefox | 2.0.
If you downloaded the OSAF bundle, then please list the database and version you are running. For example: MySQL 5.0.27 . The version number is located in the 'About Cosmo'. We are currently looking into updating bugzilla to support adding these fields.
|
Advice for Reporting Bugs
A a well-written bug report will help get your bug fixed more quickly than a mediocre bug report. The Mozilla bug-filing guidelines don't apply perfectly to Chandler, but they have good advice as to what will make your bug report most effective.
Please attach your patch to the bug. If this is your first time submitting a bug fix, you should read the PatchLifeCycle document, which tells you how to attach your patch and what to expect after you've submitted your patch.
Note: There are a couple of Bugzilla fields that the bug owners and possibly their managers use to schedule and prioritise work, so it would be appreciated if you didn't change them. They are:
- target milestone
- priority
Note that you can set priority when you file a bug, and that is fine. The development managers will set the target milestone for the bug so the submitter would know by what timeline or milestone they expect the bug to be fixed.
What happens once my bug is reported?
When you report your bug, it will be assigned to an owner, who will determine its priority relative to all the other Chandler bugs. This priority will determine when someone will look at the bug.
How bug priority is decided
While Chandler is still in active development phase, these kind of bugs take a priority:
- Bugs that block forward progress
- any bug that makes the build go red or prevents chandler from launching is of course of the highest priority
- any bug that causes chandler to crash upon invoking an action
- any bug that breaks agreed upon smoke test
- any bug necessary for upcoming development work
- any bug that prevents testing other features
- Bugs that result from unfinished features, features that were to be finished in previous milestones
- we want to encourage features to get finished, so its important to address these bugs before moving on to new features
- Bugs that represent "broken windows"
- the phrase "broken windows" is from Malcom Gladwell's The Tipping Point: the example is that streets with broken windows experience more crime and vandalism, the broken windows create an environment that suggests the wrong behavior. In our circumstance, we want to create an environment of high quality. This guideline is of course subjective.
- code that needs to be refactored is an example of a broken window
- performance problems, ui glitches, and other signs of low robustness, low quality can also be broken windows
Of course, some exceptions are made in the following cases:
- Bugs that can be more efficiently resolved at a later date
- by development work scheduled for a future milestone
- by development work best done in another project, e.g. wxWidgets
Lower priority bugs
The following type of bugs take a lower priority:
- Visual imperfections in the user interface.
- Unimplemented functionality. We don't view each piece of unimplemented
functionality as a bug, as least not yet. If you have ideas about what
the product ought to do eventually, please turn to the mailing lists
and wiki for information and discussion. We expect that discussions
of functionality will occur in the mailing lists (as they have been),
perhaps move to the wiki, and end up as bugs only after there's a reasonably
clear understanding of the nature and priority of the functionality.
|