Rules for the issue tracker

From FirebugWiki
Revision as of 04:40, 14 October 2011 by Sebastianz (Talk | contribs) (People should also be friendly to user users)

Jump to: navigation, search

We really appreciate every bug report and enhancement request you give us. Though there are some golden rules you should follow when creating issues or commenting on them.

General rules

Be polite

Don't shout at us or other users. We're a small team of volunteer developers, which spend their spare time to make Firebug better. We like everybody, who wants to give constructive contributions to the Firebug project. Also other users might not have enough experience with Firebug yet. So don't angry, if they don't understand immediately what you tell them.

If you're completely frustrated about Firebug, then we advise you to scream into a pillow and drink some tea before you disclose us your grief.

Be available for requests

If you posted on an issue, you should be available for further questions from our side. If we don't get feedback from you for long and can't reproduce your issue, we will close it!

Use a common language

Try to explain yourself in English. We're an inhomogenous team living in different places all around the world. And other users may also want to participate in an issue's discussion. Also to make it easier for others to understand what you mean, you should use the Firebug Terminology for elements inside Firebug.

Rules for creating issues

Read how to create issue reports

First read what to do when you found a bug or have a suggestion for improvement. Reading through that and following the steps described there already solves most of the issues you experience.

Create a test case

When your issue is not reproducible for us, we can't fix it! If you can't provide a test case, please ask in the Firebug discussion group or in the Firebug IRC channel instead.

When creating the issue

Add a meaningful summary

The issue summary should reflect the contents of your report, i. e. by reading it somebody should be able to understand what the issue covers.

Bad example:

Firebug is not working as expected

Good example:

"Break On Next" is not working when being clicked while script execution is stopped

Describe it well, but keep it brief

Describe your issue as detailed as possible. You should always keep in mind, that somebody else reading your issue should easily understand what you're talking about.

This also means, that you shouldn't write a whole story around your issue. Keep it short. It makes it much easier for people to follow your descriptions.

Put code blocks into attachments

Instead of posting parts of code into your issue description, you should put them into a file and attach that instead. This keeps the issues readable.

Rules for commenting on issues

Just post constructive input

Avoid comments, that are not helping us to solve an issue. This is just flooding the mail boxes of people subscribed to an issue. Instead you should try to help us solving the issue, i. e. provide more information about an issue.

E. g. constructive input can be:

  • Creating a test case to an issue, that doesn't have one yet
  • Trying a test case on another system
  • Describing a different view on an issue
  • Giving a hint how to solve an issue
  • Providing a patch for an issue

Bad examples:

me, too
I also see this issue.

Good examples:

Instead of creating an entry in the context menu, the option should be in the panel toolbar. That makes it more visible.
Tried the test case on Win7 + FF 7.0.1 + FB 1.8.3 and it fails for me.
I can't reproduce that issue running on Mac OS X + FF 10.0a1 (Nightly) + FF 1.9.0a3 (SVN)
If I set the missing variable "xyz" via the Command Line, the problem disappears.

Note, instead of "+1" posts you should use the star button to vote for an issue.