Discussions have occurred on the Clojure Google group periodically about the Clojure contribution process, and why it is the way it is. This page attempts to give brief answers to some of the questions raised in those discussions.
Brief description of Clojure contribution process
Clojure, its contrib libraries, and ClojureScript, are distributed under the Eclipse Public License. Anyone can submit bug reports or enhancement requests by creating a ticket on JIRA (a list of tickets categorized by project is here), and attach a patch implementing the change if they desire. Only patches written by someone who has signed a Clojure Contributor Agreement (CA) will be considered for inclusion. Instructions for submitting a CA, and a list of the contributors are given here (over 500 contributors as of January 2013).
If you do not wish to submit a CA, you can also participate in discussions in the Clojure Google group or the #clojure IRC channel, and someone else may become interested in implementing your ideas.
For the contrib libraries, the Project Lead decides what to do with all tickets and submitted patches. The Project Leads are listed on the project page above, given again here. For ClojureScript, David Nolen tends to be the de facto project lead, even though Rich Hickey is listed on that page.
For Clojure, there are about 5 to 10 contributors with the authorization to be Clojure screeners. They examine Clojure tickets and patches, deciding what to do with them. If they approve of a ticket with a patch, then Rich Hickey also examines the patch. If he approves, then the patch is committed.
The project leads, Clojure screeners, and Rich Hickey all work on Clojure as volunteers, in their spare time, many of them since 2007 when Clojure was first released.
More details on how to create a patch, and about the screening process, are available on the JIRA workflow page here.
Other articles that may be of interest:
- Stuart Sierra's "Clojure Governance and How It Got That Way", February 2012
The articles below are not directly related to Clojure development, but were written by developers of other open source projects. They express some of the same sentiments on what the Clojure screeners and Rich Hickey go through when considering patches:
- Kevin Bourrillion's "The story with #guava and your patches", October 2011
- Ilya Grigorik's "Don't 'push' your pull requests", December 2011
FAQs about the Clojure contribution process
Why does Clojure require that contributors first sign a contributor agreement (CA)?
It boils down to two reasons:
- To protect Clojure from future legal challenges that might discourage businesses from adopting it.
- To enable Clojure to be relicensed under a different open-source license if that would be advantageous.
Signing the Contributor Agreement grants Rich Hickey joint ownership of your contributions. In exchange, Rich Hickey guarantees that Clojure will always be available under an open-source license approved by either the Free Software Foundation or the Open Source Initiative.
Why does Clojure require that contributors submit a contributor agreement on paper?
The requirement to mail a signed CA on paper was set up in 2007 (TBD: verify if that is the correct year), before there were as many choices for electronic methods as exist today. It is the most easy to defend if there were ever a legal challenge to the copyright of any of the Clojure code. There has been some discussion in October 2012 on the Clojure Dev Google group about allowing electronic submission of CAs, too, but there is no process in place for that yet.
Link to Clojure Dev discussion thread
Other projects hosted on GitHub accept pull requests. Why not Clojure?
Rich Hickey prefers to evaluate patches attached to JIRA tickets. This is not to make it more difficult for contributors, or for legal reasons, but because of his work flow preferences. It is easier for him.
Link to Oct 2012 Clojure Google group message from Rich Hickey on this topic
But what about all of the people who won't contribute if you don't change your process to suit them?
If some people choose not to go through the steps for the current process, that is unfortunate. The process of creating JIRA tickets and patches is documented and not terribly difficult. We understand that submitting a physical signed CA is slow and/or expensive from many parts of the world, and hopefully there will be an electronic method in place in the future.