As a part of our Free Dojo Support initiative, we received the following question from Rob about contributing back to the Dojo Toolkit:

The Question

I have some questions around contributing back to the Dojo Toolkit project. We have used dojo heavily in the past 6 months, but haven’t yet really needed to join the community forums or discussions, instead finding all the answers we need online or by delving into the code. Now our project is nearing a release, we have some enhancements and Dijits we would like to contribute back to the project. A search online only reveals information regarding becoming a committer, so until this becomes a reality, how do we submit patches?

We have different things we’d like to commit:

  • Enhancements to existing Dijits (e.g. support for skipping over hidden tabs in the TabController, supporting true/false values in select, etc.), which we assume must go through an existing committer.
  • Brand new Dijits (Dojo version of the jQuery asmSelect widget, editable widget mixin, etc.) which we assume should go into the new Dojo Foundation Package repository.

Any guidance for submitting these from both a personal and corporate perspective would be appreciated.

The Answer

Thanks Rob, we’re happy that you’re having solid success with Dojo and are excited to contribute! The Dojo Toolkit generally follows the approach outlined for contributing to the Dojo Foundation.

  1. File a Contributor License Agreement (CLA). There are versions for individuals and corporations. The Dojo Foundation protects the interests of all contributors and users by accepting all code and documentation contributions only from people who have signed a CLA, significantly reducing future legal risk for everyone involved.
  2. Create a Dojo Foundation account. This provides you with access to login to the issue tracking system and more.
  3. Submit patches for enhancements or bug fixes. Create diffs and attach them to new tickets. Providing test cases for accuracy as well as performance, and including source code documentation and comments are a plus. Be sure to test your work against the latest subversion checkout, submit patches using the “unified diff” format, and follow the Dojo style guidelines, etc. All new modules should follow the Asynchronous Module Definition (AMD).
  4. Review and merge. New patches are typically accepted early in the release cycle, unless they fix critical bugs. So it is best to get your patches reviewed and accepted right after a release happens. Committers and module owners are rather busy, so please be patient and persistent in tracking down the right person to get your patch reviewed, updated, and merged into trunk.
  5. Create packages for new widgets and extensions. The Dojo Foundation Package Repository is indeed the right place to contribute. We recommend following the same guidelines as contributing to official Dojo code, so that it may later be included in official Dojo releases if relevant to the wider community, and well coded, tested, and documented. Your code may be hosted in a github repo, or through any relevant URL as defined in the package template.

As you mentioned, becoming a project committer happens later, in recognition of significant contributions to the project, and for those individuals that would like to make a more significant long-term commitment to making Dojo even better.

Next Question Please!

Have a Dojo question you’re just dying to ask? Get your free Dojo support now! Or sign-up for the Best JavaScript and Dojo Support available to get all of your questions answered all the time!