Skip to content

Filing Bugs

Jump to bottom
kennas edited this page Apr 18, 2011 · 4 revisions

Filing Bugs

“Bugs” in the context of the project refer to everything from broken aspects of the framework, to regressions, to unimplemented features. We use GitHub Issues to manage our bugs. Here are a few helpful tips for filing good bugs:

  1. Are you up to date? Make sure your current checkout is up to date. The bug may have already been fixed and there is no need to report it.
  2. Bug or Feature? Check the documentation to make sure the particular API you are having trouble with isn’t meant to behave that way. If the behavior matches the documentation but you still feel it is incorrect, file a bug and specify in the report that you believe the expected behavior is incorrect.
  3. Known Bug? Search GitHub Issues to make sure the bug isn’t already reported. If it is, feel free to add any additional comments. Additionally, we encourage you vote up the issue. The DSF team will use the vote count as a strong indication of what issues are worth fixing quickly.
  4. Congratulations If you’ve gotten this far, that means you have a real bug! Feel free to file it by clicking on "Create Issue”.
    • Provide a brief description of the bug or feature that is missing.
    • Tell us what platform you experienced this bug on. OS and Browser, such as Mac OS X 10.5.6 Safari 3.5.2 (5525.27.1)
    • Is this bug a Regression? If it is, let us know the last version that worked. Regressions are top priority to be fixed.
    • Provide clear and concise reproduction steps. The easier it is for us to reproduce the bug, the likelier it will get fixed.
    • Better yet, provide a test case as an attachment, or a URL to a place where the bug happens. If the bug includes a test case, it is very likely that it will get fixed quickly.
    • Provide appropriate tags in the bug to make it easy for us and others to search for it later. Some special “action” tags have been defined to help determine the next action needed in order to close the ticket:
      • Test Case Needed (@needtest) : A test case is needed so the bug can be reproduced and someone can begin to work on it.
      • Answer Needed (@needanswer) : An answer is needed to help determine the next step to close this ticket.
      • To Acknowledge (@to-acknowledge) : Tickets with test cases or clear explanation. A second person should acknowledge that this tickets needs some work (because sometimes, it’s a feature, not a bug).
      • Acknowledged (@acknowledged) : Tickets that are ready to be worked on.
      • Being worked on (@working-on) : Someone is already working on this ticket.
      • To Review (@to-review) : Tickets with a proposed solution. Those tickets may be solved or closed after a review
      • New features (@new-features) : New features that need to be implemented. The specifications should be made clear enough, so that someone can start working on it.

If you are currently working on a fix, let us know in the comments and tag the ticket as @working-on so others don’t waste resources fixing it or so that we can help you out.

Clone this wiki locally