Contributor Guidelines

From FirebugWiki

Revision as of 09:49, 14 September 2012 by Sebastianz (Talk | contribs)
Jump to: navigation, search

The Firebug project defines some guidelines contributors should keep in mind when working on the project.

Contents

Coding

  • Keep to the Firebug Coding Style.
  • Changes, which should be included in a bug fix release first need to be tested in an alpha release.
    E.g. fixes, which should be included in 1.10.4 need to be released in an alpha version of 1.11 first.

Preferences

  • Avoid introducing new preferences when they are unnecessary, i.e. try to reuse existing preferences or to find a better UI instead.
    E.g. Instead of adding a preference for string cropping reuse firebug.extensions.stringCropLength
  • Give your preference a good name.
    • Give it a panel and usage independent name if it's a preference that could be reused somewhere else
      E.g. extensions.firebug.showUserAgentCSS
    • Reuse the naming convention of similar preferences.
      E.g. if you want to specify the max. number of displayed elements, you should append "Limit" to the name as it's done for extensions.firebug.multiHighlightLimit, extensions.firebug.net.logLimit.
    • Prefix panel/module specific preferences with the panel/module name
      E.g. like extensions.firebug.net.hiddenColumns extensions.firebug.cache.mimeTypes

Localizations

  • Make sure you allow localization of all string labels you add to the UI.
  • Give your localization keys a good name.
    • Give it a panel and usage independent name if it's a localization that could be reused at different places
    • Reuse the naming convention of similar preferences.
    • Prefix panel/module specific preferences with the panel/module name
      E.g. net.label.Resend
    • Prefix element specific preferences by the element type
      E.g. console.cmd.help_title and console.msg.nothing_to_output

Issues

  • Follow the status order.

Issue-lifecycle.png

  • Use labels to categorize the issues.
Personal tools