Welcome and thank you for wanting to contribute! Following these guidelines helps us communicate to one another more effectively so we can resolve any issues and improve the program quicker. And remember help is always welcome, if you have an idea or want to help out let us know.

Table of contents

Code of conduct

Besides the guidelines set out in this document we expect our community reads and follows to the code of conduct as well.


The organizations philosophy is to provide a simple yet expansive toolkit done through a modular approach preferably using minimal libraries. We hope the achieve a simple to use and easy to maintain solution.


Before opening an issue choose the right repository. If your issue deals with a specific module go its repository.

When opening an issue via the issue tracker please use one of the templates listed below.

Creating pull requests

Before you start work on a pull request check any open pull request first then open an issue and inform us about what you want to do. Whether this is about a bug fix or new feature we would hate to see you effort go to waist. Perhaps someone is already working on fixing that bug or you wish to build a feature that is out of the scope. However do not let this discourage you from creating your own fork! We support most use-cases, but can not realistically support all, so feel free to modify the project.

To create a pull request first fork the repository, change to the develop branch, make, and commit your changes. Then create a pull request in the original repository, select the changes, fill in a short form, and submit the request. Afterwards simply wait for us to get back to you with any feedback.

If the repository does not have a develop branch, then use the default branch.

When making changes make sure you do everything listed below.

Follow styling

There is no specific styling guide to use. There are however two which can automatically be enforced by EditorConfig and ESLint using the .editorconfig and .eslintrc.json files respectively. Therefore you are recommend to install a plugin to automate this process.

See EditorConfig's download section for a list of editor extensions.

Run tests

Clone the repository, install dependencies with $ npm i --save, and run tests with $ npm test.

Write documentation

The projects documentation include four elements the instruction manual, change log, code comments, and commit messages. The first two are meant for users, and the latter two for contributors.

Write tests

Sometimes tests need to be added, improved, or updated to reflect recent changes, be sure to run the current tests and make changes if necessary. Tests are written using the npm package Ava in the repositories test directory and run using $ npm test. Travis-ci bot will automatically run the tests on different versions of node when submit a pull request. If any tests fail your pull request will never be accepted.

Sign off commits

Ensure your commits are signed off on at the end of your commit message, like so Signed-off-by: Jean Smith <>. Your signature certifies that you comply with the project's Developer Certificate of Origin. The goal of the DCO is to make sure contributors have to legal right to submit their changes. Therefore make sure to use your real name and not a pseudonym.

If you set your and git configs, you can sign your commit automatically with git commit -s command or in Visual Studio Code use the Commit All (Signed Off) or Commit Stages (Signed Off) option.

Reviewing pull requests

Before a pull request is allowed to be merged into the development branch at least one other contributor has to review and approve the changes made.

Travis-ci automatically runs test and DCO bot automatically checks commits for sign offs.