Skip to content

Contribution guidelines

Danni Larsen edited this page Nov 12, 2018 · 9 revisions

Issue tracker

Use the issue tracker to submit bug reports, features requests and submitting pull requests.

Issues and labels

Our bug tracker utilizes several labels to help organize and identify issues. Here's what they represent and how we use them:

  • css - Issues stemming from our compiled CSS or source Less files.
  • docs - Issues for improving or updating our documentation.
  • feature - New features should be added as suggestion. When discussed and assigned to a contributor, the label should be changed from suggestion to feature, and can then begin development.
  • gulp - Issues with our Gulp setup, which is used to concatenate and compile source files, and more.
  • help wanted - Issues we need help from the community to resolve.
  • js - Issues stemming from our compiled or source JavaScript files.
  • suggestion - Suggestions for a new feature to be added, or an existing one to be extended or modified. Issues with this label should not be started.
  • wontfix - As the title says, issues that will not be fixed.
  • duplicate - As the title says, issue is a duplicate of another issue. Please make sure to write a comment linking to the original issue.

For a complete look at our labels, see the our labels page.

Bug reports

If you find a bug you can submit it in the issue tracker or you can submit a pull request with the issue id as part of the name, like Fixing issue #44 or Feature #44. We will review it as quickly as possible, and merge it when approved.

Feature requests

Suggestions for new features should be added in the issue tracker and be discussed before being assigned to a contributer and deveolopment can begin. When you get an feature request assigned, the label should be changed from suggestionto ´feature`. Submit a new pull request when you

Pull requests

Please do only edit source files, and follow the general coding patterns already existing in the code. Commit your changes in logical chunks, one feature or bug fix at a time.

If you haven't done a pull request before here's a guide to get you started:

  1. Clone the project.

  2. Create a new feature branch (off the master branch) to contain your feature, change, or fix. Please name your branch like this example: issues/make-cool-error-pages#246 for the issue #246

  3. Commit your changes with logical commit messages, and push your feature branch to your fork.

  4. Open a Pull Request and include the special keyword syntax (eg. "fixes #5") in the body of your Pull Request.

IMPORTANT: By submitting a patch, you agree to allow the project owners to license your work under the terms of the MIT License (if it includes code changes) and under the terms of the Creative Commons Attribution 3.0 Unported License (if it includes documentation changes).

Rewiewing

If you review a pull-request, you dont need to check that the code is working. It's more a code-review in terms of typos, guidelines etc.