-
Notifications
You must be signed in to change notification settings - Fork 29
Intro: Contributor's Guide
It's easy to get involved in the Cooperative Web Framework Development Community, also referred to as the OpenCoweb development community, and there are lots of ways you can make a difference:
Helping other users on IRC and the mailing lists Writing documentation and tutorials Filing good bugs (and test cases) to help developers solve issues quickly Writing patches to fix bugs Submitting code for new features Bug Tracking
Most project development revolves around "bugs" or "tickets". All bugs that are found are logged in GitHub Issue Tracker and subsequently assigned to developers and milestones in which they'll be fixed. This process helps us ensure that the right things are getting fixed, and the quality of the bug report often 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:
- Browser type (IE, Firefox, Opera, ...)
- Browser version
- OS and OS Version
- All steps necessary to reproduce the issue
- An email address of the person filing the bug or a way to get a hold of him/her.
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 procedure:
Search the bug database to find similar issues that might have already been reported.
- If you find an existing bug that covers the issue you're experiencing, ensure that it's reported against the right version and has all of the information listed above. Also, adding comments to the ticket noting your support for getting a particular issue resolved helps the committers prioritize, so don't hesitate to shout out if you're encountering something that is already filed.
- If no existing bug is found, create a new one that includes all of the information listed above. Log in with using your dojotoolkit.org username and password(this is NO longer guest/guest, as reported elsewhere) in order to gain access to create a new ticket.
- Add your email in the CC field so that you will receive any updates that are contributed to the ticket. This also provides a way for the developers to contact you if there is a need to get more information regarding the bug. This is particularly important for patches where a couple of iterations are sometimes needed to get the patch right before it's accepted.
- If you can provide a patch, please follow the guidelines below and make sure to sign a CLA and provide your full name in the comment field when attaching the patch to the ticket. 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.
Many project developers and users can be found in the #coweb channel in irc.freenode.net. Discussions here range from user support to design of new toolkit features. Most topics are fair game for discussion, but we only ask that everyone in the channel keep it clean and civil.
As with email, you should google for an answer to your question before asking it in IRC and civility is expected of everyone.
Logistics for weekly developers meetings are communicated in the Developer's Forum (Google Group: opencoweb-dev) and may also be communicated over IRC.
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. So 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.
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:
- your patch must conform to the project's JavaScript Style Guidelines
- your patch should be created against the latest version of the toolkit, which you can get from a Subversion checkout of the toolkit
- All changes should be submitted in "unified diff" format. The output of subversion's diff command is usually sufficient.
- A test case should accompany any patches in order to verify that the change actually fixes the issue in question
Inside the Dojo community, there are two groups of people who contribute. The word "contributors" refers to anyone who submits documentation, bug fixes, or even bug reports and test cases. You can become a contributor by sending in a CLA and jumping into the fray! Demos, patches, docs, and tests are all warmly welcomed.
"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. 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 critical release issues. Becoming a Dojo committer is considered an honor as it means you've impressed a discerning group with the quality of your contributions and the team 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, then...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, contribute significant amounts of documentation or demos, or in some other way show the team that you "get" how we work and that you respect others in the community. Committers make recommendations to the Foundation Board regarding people they think should be considered for committer 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.