Joola is open source software - we welcome contributors! Some things you might like to help out with:

  • Documentation
  • New features
  • Bugfixes
  • Security vulnerabilities

Join the conversation

Have an idea for Joola? Found a bug? We encourage you to start a conversation on the [Joola Google Group] [joola-user] or to file a [new issue on GitHub] [new-issue] before writing code. Announcing what you're working on (or even just your need or pain points) starts a collaborative process to identify general solutions and helps us all avoid duplicating effort.

Let's build Joola and grow our community, together.

Contributor License Agreement

As the project sponsor, Joola Smart Solutions Ltd. would like to ensure the long-term viability of Joola and its community. The Contributor License Agreement helps ensure everyone can enjoy Joola with confidence that Joola is here to stay.

Specifically, our Contributor License Agreements (CLAs) grant the contributor and Joola Smart Solutions Ltd. joint copyright interest in contributed code. Further, it provides assurance from the contributor that contributions are original work that does not violate any third-party license agreement. The agreement between contributors and project is explicit, so Joola users can be confident in the legal status of the source code and their right to use it.

For all contributions to Joola (be they software, bug fixes, configuration changes, documentation, or any other materials), we ask that contributors complete and sign a Contributor License Agreement. We have two different Contributor License Agreements (CLAs), depending on whether you are contributing in a personal or professional capacity. Both are based on the Apache Software Foundation's own CLAs, with modifications:

Please complete and sign the most appropriate CLA for you.

Contributing to development

Third-party patches are essential for keeping Joola great and we want to keep it as easy as possible to contribute changes that get things working in your environment. There are a few guidelines that we need contributors to follow so that we can have a chance of keeping on top of things.

Getting Started

  • Make sure you have a GitHub account.
  • Submit a ticket for your issue (, assuming one does not already exist.
    • Clearly describe the issue including steps to reproduce when it is a bug.
    • Make sure you select the relating components to the issue.
    • Make sure you fill in the earliest version that you know has the issue.
  • Fork the repository on GitHub

Making Changes

  • Create a ticket branch (name your branch #issuenumber, according to the ticket you raised) from where you want to base your work.
    • This is usually the develop branch.
    • Only target release branches if you are certain your fix must be on that branch.
    • To quickly create a ticket branch based on master; git branch feature/#issuenumber develop then checkout the new branch with git checkout feature/#issuenumber. Please avoid working directly on the master or develop branches.
  • Make commits of logical units.
  • Check for unnecessary whitespace with git diff --check before committing.
  • Make sure your commit messages are in the proper format #issuenumber message.
#123 Make the example in CONTRIBUTING imperative and concrete

Without this patch applied the example commit message in the CONTRIBUTING
document is not a concrete example.  This is a problem because the
contributor is left to imagine what the commit message should look like
based on a description rather than an example.  This patch fixes the
problem by making the example concrete and imperative.

The first line is a real life imperative statement with a ticket number
from our issue tracker.  The body describes the behavior without the patch,
why this is a problem, and how the patch fixes the problem when applied.
  • Make sure you have added the necessary tests for your changes.
  • Make sure you lint your code (run: npm run lint).
  • Run all the tests to assure nothing else was accidentally broken (run: npm run test:scenario)..
  • Make sure your tests maintain the current test coverage level (run: npm run test:scenario:coverage).


Documentation is managed under the repo's wiki. For changes of a trivial nature to comments and documentation, it is not always necessary to update the wiki. For contributions affecting documentation, please contact project admins to ensure you have been granted with an editor role.

Submitting Changes

  • Sign the Contributor License Agreement.
  • Push your changes to a ticket branch in your fork of the repository.
  • Submit a pull request to the repository in the Joola organization.
  • Update your ticket to mark that you have submitted code and are ready for it to be reviewed.
    • Include a link to the pull request in the ticket

Contributing to documentation

We welcome contributors to the Joola documentation with open arms - just as we welcome contributors to the Joola codebase!

Our main store of documentation is the project's gh-pages site.

Contributing to the documentation

To make edits to the documentation, fork the repo (git://, checkout the gh-pages branch (run: git checkout -b gh-pages) make edits and then submit a pull request. The documentation site is powered by Jekyll coupled with redcarpet markdown.

All the documentation is stored in Markdown format. Good tools for editing markdown include Markdownpad on Windows, or Mou for Mac. We also like Sublime Text.

Contributing to Code Documentation

To make edits to the code documentation (jsdoc), for the code repo (git://, make edits to the jsdoc comments in the code files located under lib and then submit a pull request.

We are using a custom-tailored version of jsdox for building our jsdoc documentation.