Contribution Guidelines

This project is open source and provides multiple ways to make meaningful contributions. This application couldn’t exist without the help of many contributors, and we want you to feel like you can help out and make a difference.

Ways to Contribute

There are many ways to contribute:

  • Filing an Issue - if you find a bug or want to request an enhancement, file an issue.
  • Working on Issues - feel free to pick up any open issue that you feel you’re capable of addressing.
  • Documentation - if you enjoy writing and want to contribute to the project, try improving our documentation.

Filing an Issue

Issues should be filed directly inside of the GitHub repository. File an issue if:

  • You’ve identified a bug in the application. This means that you believe something is working incorreclty and should be fixed.
  • You want to request a new feature for the application. This means that you believe something is missing and should be included.

For bug reports, please include:

  • A description of the actions taken when the error or bug was found.
  • What you expected the behavior to be when taking this action.
  • What actually happened when this action was taken.
  • If you have any interest in addressing the issue yourself.

For feature requests, please include:

  • A description of the problem you want to solve.
  • Your opinion on the best solution for this problem.
  • If you have any interest in addressing the issue yourself.

Please include as much detail as possible to help the team address your issue.

Working on Issues

Please feel free to begin working on any open issue in the issue list of the GitHub repository. If the issue is still open, that means that the team plans on eventually addressing it, and any help is appreciated. Please consider:

  • Beginner issues - If you’ve never contributed to the project, you may want to try one of the issues tagged with beginner. These issues are small and self-contained and provide good experience for new contributors.
  • Accepted issues - Issues tagged with accepted will eventually be addressed by the team. Please only submit requests for accepted issues.

If you’re going to work on an issue, please add a comment to that issue saying so and indicating when you think you’ll be able to complete it. This helps to avoid any duplicate effort.


  • “I’ll take a look at this issue over the weekend.”
  • “I’m going to work on this. Give me two weeks to complete it.”
  • “I’m looking into this and should have something in a couple days.”

If someone has already committed to work on an issue, please do not work on it. If you’re unable to finish work on an issue, please add a comment letting people know. Don’t worry if this is the case, we appreciate all contributions.

If the issue significantly changes an existing feature / function of the application, it’s required that documentation is also updated.


There are several ways to help with documentation, including:

  • Fixing typos
  • Improving the existing documentation (i.e. making it more clear or concise)
  • Add new documentation for features that were missed or overlooked.

Pull Requests

If you would like to contribute to the repo, please use a GitHub pull request. Any contributions made in any other way (i.e. code snippets in issues) will not be considered. This is the quickest way to allow us to evaluate the code.

Please follow these guidelines when submitting your pull request:

  • Make sure there is an open issue for the request
    • Not applicable for documentation about existing functionality.
  • The pull request must have a description. This should include what was done and how you addressed the issue.
  • Please make your pull request on the development branch.
  • The commit message should say “(fixes #1234)” at the end of the description if it takes care of an existing issue (1234 should be replaced with the issue number)
  • Be sure to make small, purposeful pull requests. Large pull requests with multiple changes may be closed without merging.
  • All changes must have accompanying tests.
  • All changes must have any impacted documentation updated.
  • Follow the code conventions.