How to Report a Bug in Cosmo

---

---

What should I do if I find a bug in Cosmo?

Has it already been reported?

If you find a problems with Cosmo, the first thing that you should do is see if someone else has already found the same problem. To do this, you should check our bug tracking system, Bugzilla, to see if there is a bug report that covers your problem..

Report it

If no one else has reported the bug, then help us out by reporting it.

Please note in your bug report the OS, browser and version of the browser to help guide us. For example: Mac PPC | 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.

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 Cosmo, but they have good advice as to what will make your bug report most effective.

If you have a proposed fix for the bug, that's even better. 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.

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 Cosmo bugs. This priority will determine when someone will look at the bug.

How bug priority is decided

While Cosmo 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 Cosmo from launching is of course of the highest priority
  • any bug that causes Cosmo 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:

• UI imperfections.
• 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.

Bugzilla fields you should not change

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.

-- TedLeung - 17 Nov 2005