Contributing doesn’t always mean having code repository commit access. In fact, some of the best open source contributors never have commit access. In order for Quartz to be successful, we rely on help in many areas other than writing software. These include:
- Submitting bug reports (with patches!)
- Writing documentation (esp. based on common issues in the forums)
- Helping out in the forums
We recognize people who help out in any way by adding their name as a contributor to the development team. Every person listed there has helped in some way, big or small, to make Quartz what it is today. Without them, the project certainly would not be the same. With that said, we know that some people are especially interested in writing software…
Authorship record of code modules and/or documentation is also maintained to give credit where credit is due.
Have you built a great new feature or documentation improvement? Drop us a note in the forums or file a feature enhancement request in our issue tracker and let us know about it. We gladly, and regularly accept contributions, and there are a few ways you can participate.
Contributors are given credit for their work, though they must be willing (for licensing purposes) to license and/or assign a copyright of the work. Once you have submitted your contribution we will contact you about providing us with a license or submitting a signed Contributor Agreement. If we request that you assign your copyright of the work to a Terracotta project, you can find the Contributor Agreement document and directions for submission to Terracotta through the link. This document only needs to be filled out once per contributor - not once for each contribution.
Contributions which do not require full Contributor’s License Agreement (CLA)
A contribution which is an obvious or “drive-by” fix would not require you to sign a CLA rather you will grant us a license to use your contribution. Changes are obvious fixes if they do not introduce any new functionality or creative thinking.
The submissions such as the following would not require you to sign a CLA
- Bug fixes that have an obvious simple fix and do not change intended feature functionality;
- Adding logging messages or debugging output;
- Changes to build files;
- Additions and changes to test files;
- Minor doc additions or improvements;
- Spelling/grammar fixes; Correcting typos;
- Cleaning up comments in the code; or
- Changes to white space or formatting;
The following are examples that would still require a signed CLA before your submission would be incorporated into the project:
- Any code that results in a change in functionality;
- A new feature;
- Feature Enhancement, or anything that alters product behavior;
- A translation; or
- Extensive or creative documentation or comments.
If you’re not sure if your fix is obvious you can ask us by sending an email to: email@example.com.
For those contributions that do not require a CLA: upon submission of Your Contribution you hereby grant Software AG and to recipients of the software distributed by Software AG a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to install, use, reproduce, prepare derivative works of, publicly display, publicly perform, offer to sell, sell, import, sublicense, transfer, and distribute Your Contribution and any such derivative works.
Contributions which do require a full Contributor’s License Agreement (CLA)
Substantial contributions require a CLA, in this case, a “Contributor Agreement” document must be filled-out and sent to Terracotta (firstname.lastname@example.org) – indicating that you assign the copyright of the work to the Quartz project. This document only needs to be filled out once per contributor - not once for each contribution.
Becoming a Quartz Developer
Becoming a core developer for Quartz is on an invite-only basis. The project leaders look for people who have submitted bug reports (with patches), helped out with writing documentation, stay active in the community forums, or make code contributions. In addition to all these, developers must demonstrate a strong desire to see the project be successful. This is typically done by staying in touch with the project leaders, following up on reported bugs, and generally offering assistance.