Dojo is a community effort, and we need your help!
It's easy to get involved and there are lots of ways you can make a difference:
Inside the Dojo community, there are two "levels" of participants. The word "contributors" refers to anyone who submits documentation, bug fixes, or even bug reports and test cases. This large group of designers and developers who are using the Toolkit to improve user experience are the lifeblood of the project. You can become a contributor by sending in a Contributors License Agreement and starting to pitch in in any of the ways noted above.
"Committers" are a subset of the contributor community who have been granted the ability to make changes directly to Dojo. Committers can also vote in Toolkit and Foundation matters. With that power comes significant responsibility. Committers are required to act as the front line of defense against IP pollution, follow community development standards, merge or reject patches sent in by contributors, vote, participate in weekly IRC meetings, and work on criticial release issues. Becoming a Dojo committer is considered to be an honor as it means you've impressed a discerning group of hackers with the quality of your contributions and feels that they can get along with you.
So how do you go from "contributor" to "committer"?
The first step is to file a Contributors License Agreement (outlined below). Once it's been received, start contributing! There's no hard-and-fast rule for how many contributions it takes before you are considered for committer status, but in general you'll need to close important bugs, demonstrate that you are willing to participate in the community (mailing lists, IRC, etc.), and show that you respect community norms and standards. Committers make recommendations to the Foundation Board regarding people they think should be considered for commiter status, so working with a committer to assist him/her with issues that are important for an upcoming release is a great way to ensure that your contributions are integrated and that you will be considered for committer status in a timely fashion.
Most forms of contribution aside from providing support to other users requires that you sign and submit a Contributors License Agreement (or "CLA" for short) with the Dojo Foundation. All additions to this manual, for instance, require signed CLAs.
There are two versions of the agreement:
Summarized, the CLA asserts that when you donate fixes or documentation, you both own the code that you're submitting and that the Dojo Foundation can in turn license that code to other people. While the text on the agreement suggests that you fax it in, you can submit a valid CLA by:
Sending in a CLA is a one-time thing, and once it's done, you're in the clear to start contributing to all Dojo Foundation projects! To be effective, though, you need to know a little bit about how contributors coordinate their work.
Most decisions, support, and coordination happens on the project's mailing lists. The dojo-interest mailing list is our most active list, with over a hundred messages sent to subscribers on some days. Everything from how best to theme widgets to complex debugging of applications happens here. There are several web interfaces onto this list, including the searchable gmane archive and the Nabble interface which allows for participation via the web UI.
Project mailing lists are broken up more-or-less by function. The full list:
General mailing list ettiquete holds on these lists, but here's the short list of do's and dont's in case your youth wasn't mispent reading mailing list archives like our was:
Many project developers and users can be found in the #dojo channel in irc.freenode.net. Discussions here range from user support to design of new toolkit features. The IRC channel functions kind of like a "real-time dojo-interest list".
As with email, you should google for an answer to your question before asking it in IRC and civility is expected of everyone.
Every Wed at 3pm PST, contributors of every stripe gather in the #dojo-meeting room (also on irc.freenode.net) for the weekly development meeting. Agendas for these meetings are kept in the main project wiki and the log of each week's discussions are uploaded there once the meeting for the folks who couldn't participate in real time.
Most project development revolves around "bugs" or "tickets". All bugs that are found are logged in Trac and subsequently assigned to developers and milestones in which they'll be fixed. This process takes a lot of time and work, and generally speaking the quality of the bug report determines how quickly the issue will get corrected. The best bug reports include detailed instructions on how to reproduce the bug, an attachment that shows the code for reproducing the issue, or a link to a URL that demonstrates the problem.
All bug reports need to include the following information:
If you think you've found a new bug in the system, we encourage you to file a bug report on it using the following proceedure:
The better the bug reports, the faster we can fix things, and improving existing bug reports for issues scheduled to be addressed in the next major release is a great way to get involved and speed improvement in the toolkit. And writing good test cases is just a small step away from writing patches to fix the issues.
In many cases, the hard work of fixing bugs is understanding them well enough to determine what the system is doing and what it should be doing. If you've reached this point in the process of filing a bug report, you may find it just as easy to fix the bug as to report it. What then, though? How do you get your fix merged back into the toolkit?
The easiest way to submit patches to the toolkit is to create diffs and attach them to existing bug tickets. This is a straightforward process, but we'll need a "Contributor's License Agreement" (CLA) on file from you. The process for this is outlined above.
Once your CLA has been received, project committers can review and (potentially) merge your changes to fix the bug. To increase the odds that your patch will be merged, remember the following:
Many companies send inquiries about how to "join the Foundation". While The Dojo Foundation does not have a concept of corporate membership the way some other OSS foundations do, it is still possible for companies to get their needs met inside the community processes outlined above. Most companies who are deeply involved in Founation projects attempt either to hire existing committers or encourage one of their existing employees to become committers. For corporate contributors, the steps to getting involved at a level appropriate for moderate to heavy investement in Toolkit technology (e.g., shipping a product with a Dojo-based UI) are:
Employers should note that committers are individuals, and committer status is not tied to an individuals employment situation in any way. Sponsoring a developer's time on Dojo has historically been the largest factor in reducing the time required for that person to be considered for committer status.
Lastly, if your business needs assistance with Dojo but does not want to sponsor an employee to become directly involved with the project, companies like SitePen, the TurboAjax Group, or even individual committers can provide development and support services that may shortcut the time and effort required to both develop high-quality Dojo code and speed its inclusion in the toolkit mainline.