Community

In May 2013, active development of the Maqetta open source project stopped, and in February 2014, the free web hosting service for the Maqetta application at Maqetta.org became unavailable.

User community

Users can help the Maqetta project by:

• Participating in the Maqetta user community at Google Groups
• Reporting bugs and requesting features using the Maqetta Issue Tracker at GitHub

More active participation

Users and programmers who would like to actively participate in the project can help by:

• Participating in the Maqetta developer community at Google Groups
• Filing good bugs (and test cases) or adding comments to existing bugs to help developers solve issues quickly and fully understand feature requests (see Maqetta Issue Tracker at GitHub)
• Writing documentation and tutorials
• Writing patches to fix bugs
• Submitting code for new features

Issue and Feature Tracking (aka Bugs)

Most project development revolves around “bugs” or “tickets”. All bugs that are found are logged in Maqetta Issue Tracker at GitHub 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 should include the following information:

• Browser type (IE, Firefox, Opera, …)
• Browser version
• OS and OS Version
• All steps necessary to reproduce the issue
• (Preferred, but optional) email address of the person filing the bug or a way to communicate with him/her in case it is necessary to ask follow-up questions.

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:

1. Search the bug database to find similar issues that might have already been reported.
2. 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. (You will need to have a login at GitHubto log add comments to an existing bug.)
3. If no existing bug is found, create a new one that includes all of the information listed above. (You will need to have a login at GitHubto log a new bug.)
4. 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.
5. 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.

Contributing Fixes

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.

The Road To Becoming A Committer

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 Dojo 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 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.

If you are interested in becoming a contributor, please review the Contributors License Agreement.