Contributor guidelines

Filing a bug or an issue

  • What version of WET is the affected experienced in (v3.0.0, v3.0.1, etc)? If it is not the latest stable version, does to the latest version resolve the issue?
  • What browser was the bug found in? (IE8, FireFox 18, Chrome 24, or a combination of browsers)
  • A link to a page that can be used to reproduce the issue (demo or public URL). If a public page cannot be provided, a picture should be attached showing the issue (use GitHub's issue attachment feature)
  • Post in the issue space for the WET variant in which the bug was found. If it applies to the project itself, post an issue in the WET-BOEW repository.
  • Review the issues to see if someone's already filed it by filtering the categories listed on the left or using the search box.
  • Post your issue.

Creating a pull request

Pull requests are welcome. Please make sure your changes are to the latest code and limit the commit range to just the files you intended to change (to avoid conflicts).

  • To cut down on commit pollution in the main code base consider rebasing your commits before you create a pull request to the main branch.

New components

Should be added in a feature-* branch (e.g., feature-lightbox) that is created off of the master branch.

  • Create the a fresh branch off master by using:
    • git fetch upstream
    • git checkout upstream/master
    • git checkout -b my-cool-new-feature
  • Licensing for all new components and supporting code must be compatible with the MIT license used by WET.
  • New plugins should use the same structure and formatas existing plugins.
  • Include the WET terms and conditions comment block in all text-based source files that fall under Crown Copyright.

Bug fixes and patches that apply to all versions

Should be submitted to the v3.0 branch.

  • Create a fresh branch off of v3.0 by using:
    • git fetch upstream
    • git checkout upstream/v3.0
    • git checkout -b my-patch-description

Testing your PR before submitting

  • Validate your HTML markup. Markup should be well-formed HTML5.
    • To test for well-formed markup, validate with an XHTML5 preset and a checkmark next to "Be lax about HTTP Content-Type".
  • Validate your CSS with the following changes to the default settings:
    • Profile: CSS level 3
    • Vendor extensions: Warnings
  • Validate your JavaScript code
  • Optimize your JavaScript, CSS and HTML code
  • Formatting recommendations:
    • Indent with tabs using the K&R indenting style
    • Use single quotes for strings in JavaScript (so unescaped double quotes can be used for attributes in HTML output)
  • Test Web pages against the following browser test baseline:
    • The current and previous major version of each browser that accounts for at least 5 per cent of visits to the website;
    • Any major version of a browser that, on its own, accounts for at least 5 per cent of visits to the website; and
    • The current and previous versions of the default browsers of each mobile operating systems that accounts for at least 5 per cent of the global or Canadian mobile operating system market share.
  • PR testing is done by Travis-CI, but the same set of tests can be run using "ant test" locally before you submit