Skip to content

Latest commit

 

History

History
59 lines (37 loc) · 2.33 KB

CONTRIBUTING.md

File metadata and controls

59 lines (37 loc) · 2.33 KB

Contribution guidelines

We really like contributions and bug reports, in fact the project wouldn't have got to this stage without them. We do have a few guidelines to bear in mind.

Contributing

If you’ve got an idea or suggestion you can:

Raising bugs

When raising bugs please explain the issue in good detail and provide a guide to how to replicate it. When describing the bug it's useful to follow the format:

  • what you did
  • what you expected to happen
  • what happened

Suggesting features

Please raise feature requests as issues before contributing any code.

This ensures they are discussed properly before any time is spent on them.

Contributing code

Indentation and whitespace

Your JavaScript code should pass linting.

For anything else, maintain 2-space, soft-tabs only indentation. No trailing whitespace.

Versioning

Follow the guidelines on semver.org for assigning version numbers.

Versions should only be changed in a commit of their own, in a pull request of their own. This alerts team members to the new version and allows for last-minute scrutiny before the new version is released. Also, by raising a separate pull request, we avoid version number conflicts between feature branches.

Commit hygiene

Please see our Git style guide in the 'How to store source code' page of the GDS Way, which describes how we prefer Git history and commit messages to read.

Review apps

When a pull request is opened, Heroku may create a review app that will allow you and your reviewers to preview how your changes will appear for users. If a review app is not created automatically, you can ask someone from the Prototype Kit team to create one.

Review apps are password protected with the username govuk and the password govuk.