# 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 master branch.

- Create a fresh branch off of master by using:
  - `git fetch upstream`
  - `git checkout upstream/master`
  - `git checkout -b my-patch-description`

## Testing your PR before submitting

- Validate your HTML markup as to ensure well-formed HTML5.
  - These tests will be run as part of the default build, or by calling `grunt htmllint` to run the task on your built HTML.
  - You can manually test for well-formed markup using the W3C HTML validator. 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. This validation is done by calling `grunt jshint`
- Optimize your JavaScript, CSS and HTML code
- Formatting recommendations:
  - Indenting can be enforced by installing an EditorConfig plugin for your prefered IDE
  - Indent with tabs using the K&R indenting style
  - Use double quotes for strings in JavaScript (so unescaped single 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 visitsFootnote 1 to the website;
  - Any major version of a browser that, on its own, accounts for at least 5 per cent of visitsFootnote 1 to the website; and
  - The current major version of each mobile browser that accounts for at least 5 per cent of mobile device visitsFootnote 1.
- PR testing is done by Travis-CI, but the same set of tests can be run using `grunt dist` locally before you submit

## Commit Messages

When committing changes for a pull request, your commit message should start off with the name of the affected plugin(s) or topic, followed by a colon and a short description of what's changed. A longer description can also optionally be included. If the commit resolves a pre-existing issue on GitHub, include "Fixes #issue-id." as a part of the long description.

Message example
  `Plugin name/topic: Short description of the change.
  (Optional) Long description of the change. Fixes #1715.`
Command line example
  `git commit -m "Plugin name/topic: Short description of the change." -m "(Optional) Long description of the change. Fixes #1715."`

## Footnotes

Footnote 1

  For Government of Canada websites: Visits to all public-facing Government of Canada websites and web applications, excluding visits from Government of Canada workstations.

  Return to footnote 1 referrer

Date modified:
  2014-08-08