Contributor Guidelines

From FirebugWiki

Revision as of 08:08, 8 May 2013 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
  • Add a comment above your localization(s) of the following form:
   # LOCALIZATION NOTE (<localization key>):
   # Description
  • Format localizations consistantly.
    • Use sentence fragments without ending punctuation for tooltips, infotips, buttons and other UI.
    • Use full sentences for longer descriptions in infotips, infobars, notification boxes and console messages.

Issues

  • Follow the status order.

Issue-lifecycle.png

  • Use labels to categorize the issues.
Label Description
console, net, stack, inspect, activation, etc. The panel or module an issue is related to; generally required when triaging an issue
Test-case-in-suite, Test-case-available, Test-case-needed Issue needs/has a reproducible manual test case; generally required when triaging an issue
<Firebug version> Version of Firebug the issue is seen on (e.g. 1.11-b3); generally required when triaging an issue
extension-issue An issue related to a Firebug extension; The extension name needs to be provided as another label (e.g. netexport-0.9-b2).
contribution A non-Firebug-member provides a patch for an issue and we apply it
platform Issue needing platform support or a fix on platform side
refactoring Issue related to code refactoring (no bug fix or UI changes); requires the type of the issue to be set to Type-Enhancement
doc-needed, doc-available Fix requires/has documentation in the wiki and/or on the feature description pages
release-note-wanted Feature/bug fix should be mentioned in a release note
FBTest-wanted, FBTest-available Fix requires/has an automated test case
OpSys-* Bug affects only a specific operating system; requires the type of the issue to be set to Type-Defect
priority-* Issue has a specific priority to be fixed; issues with high priority should be considered to be put on the roadmap
complexity-* Issue has a specific complexity; issues with low complexity are a good starting point for new contributors
ux-* Issue affects/covers a specific piece of user experience; labels are copied from Bugzilla, where a detailed description of each label can be found
Personal tools