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.
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.
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
developbranch, then use the default branch.
When making changes make sure you do everything listed below.
There is no specific styling guide to use. There are however two which can automatically be enforced by EditorConfig and ESLint using the
.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.
Clone the repository, install dependencies with
$ npm i --save, and run tests with
$ npm test.
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.
README.mdintroduces the project and provides instructions on how to use the package.
CHANGELOG.mdlists what has changed in which version. Add your changes under the
UNRELEASEDheader, if not already there feel free to add it. Then create sub-headers with the type of changes either
Removedwhere you will list the changes.
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.
Ensure your commits are signed off on at the end of your commit message, like so
Signed-off-by: Jean Smith <firstname.lastname@example.org>. 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
user.emailgit configs, you can sign your commit automatically with
git commit -scommand or in Visual Studio Code use the
Commit All (Signed Off)or
Commit Stages (Signed Off)option.
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.