r12 - 11 Mar 2010 - 21:20:47 - HeikkiToivonenYou are here: OSAF >  Projects Web  >  OSAFCommunity > GetInvolved > ReportABug

Report a bug

What is a bug? A problem with the software. Something that confuses you. Inconsistent or unexpected behavior. If you are unsure how to report your problem, please post a message to the Chandler Users list.

Chandler Project uses Bugzilla to track bugs. To report a bug, you will first need to sign up for a bugzilla account.

Please observe the glossary. Use of appropriate terms will increase the likelihood of Bugzilla finding what you seek.


Report a Chandler Desktop Bug

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

Report a Chandler Hub or Chandler Server Bug

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.

-- MimiYin - 15 Jun 2007

Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r12 < r11 < r10 < r9 < r8 | More topic actions
 
Open Source Applications Foundation
Except where otherwise noted, this site and its content are licensed by OSAF under an Creative Commons License, Attribution Only 3.0.
See list of page contributors for attributions.