Copy Page

You are not logged in. Any changes you make will be marked as anonymous. You may want to Log In if you already have an account. You can also Sign Up for a new account.

<p>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.</p><h1>Brief description of Clojure contribution process</h1><p>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 <a href="http://dev.clojure.org/jira/secure/BrowseProjects.jspa#all">here</a>), 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 <a href="http://clojure.org/contributing">here</a> (over 500 contributors as of January 2013).</p><p>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.</p><p>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 <a href="http://dev.clojure.org/jira/secure/BrowseProjects.jspa#all">here</a>.  For ClojureScript, David Nolen tends to be the de facto project lead, even though Rich Hickey is listed on that page.</p><p>For Clojure, there are several contributors with the authorization to be Clojure screeners (there are 9 screeners as of Feb 2013 – the list is <a href="http://dev.clojure.org/display/doc/Screeners">here</a>).  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.</p><p>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.</p><p>More details on how to create a patch, and about the screening process, are available on the JIRA workflow page <a href="http://dev.clojure.org/display/design/JIRA+workflow">here</a>.</p><p>Other articles that may be of interest:</p><ul><li>Stuart Sierra's &quot;<a href="http://clojure.com/blog/2012/02/17/clojure-governance.html">Clojure Governance and How It Got That Way</a>&quot;, February 2012</li></ul><p>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:</p><ul><li>Kevin Bourrillion's &quot;<a href="https://plus.google.com/113026104107031516488/posts/ZRdtjTL1MpM">The story with #guava and your patches</a>&quot;, October 2011</li><li>Ilya Grigorik's &quot;<a href="http://www.igvita.com/2011/12/19/dont-push-your-pull-requests/">Don't 'push' your pull requests</a>&quot;, December 2011</li></ul><h1>FAQs about the Clojure contribution process</h1><h2>Why does Clojure require that contributors first sign a contributor agreement (CA)?</h2><p>See <a href="http://clojure.org/contributing">http://clojure.org/contributing</a></p><p>It boils down to two reasons:</p><ol><li>To protect Clojure from future legal challenges that might discourage businesses from adopting it.</li><li>To enable Clojure to be relicensed under a different open-source license if that would be advantageous.</li></ol><p>Signing the Contributor Agreement grants Rich Hickey joint ownership of your contributions. I<span style="font-size: 10.0pt;line-height: 13.0pt;">n exchange, Rich Hickey guarantees that Clojure will always be available under an open-source license approved by either the </span><a href="http://www.fsf.org/" style="font-size: 10.0pt;line-height: 13.0pt;">Free Software Foundation</a><span style="font-size: 10.0pt;line-height: 13.0pt;"> or the </span><a href="http://opensource.org/" style="font-size: 10.0pt;line-height: 13.0pt;">Open Source Initiative</a><span style="font-size: 10.0pt;line-height: 13.0pt;">.</span></p><h2>Why does Clojure require that contributors submit a contributor agreement on paper?</h2><p>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.</p><p><a href="https://groups.google.com/forum/?fromgroups=#!topic/clojure-dev/6BSE8OqnYnc">Link</a> to Clojure Dev discussion thread</p><h2>Other projects hosted on GitHub accept pull requests.  Why not Clojure?</h2><p>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.</p><p><a href="https://groups.google.com/forum/#!msg/clojure/jWMaop_eVaQ/3M4gddaXDZoJ">Link</a> to Oct 2012 Clojure Google group message from Rich Hickey on this topic</p><h2>But what about all of the people who won't contribute if you don't change your process to suit them?</h2><p>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 <a href="http://dev.clojure.org/display/design/JIRA+workflow">documented</a> 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.</p>