The Clojure contribution process is designed to allow for open collaboration while also insuring that each change to the code base is well planned and executed. 


After a ticket has been vetted, it moves into the development phase. At this point, patches will be created and attached to the ticket. This code can be written by anyone who has submitted a CA. Due to copyright restrictions any patches submitted by someone without a CA will not be accepted, and feature/fix will need to be recoded from scratch. 

The core contributors to Clojure try to code patches for bugs first, and then move on to feature requests. Therefore if you have an accepted CA, there is a major feature that interests you, and it is missing a patch, feel free to code the patch yourself. As with most open source projects, if you find a missing feature bothersome, you are most likely the right person to code the implementation.


After the patch has been coded and attached to the ticket, the ticket will be “ready to screen”. The goal of screeners is to provide code-review and implementation oversight to new features and bugs. Where vetters review the high-level aspects of a ticket (is this feature needed?), screeners provide low-level oversight of the process (is this feature coded correctly?). If the screeners are uncomfortable with the patch, it will be marked as “incomplete” and sent back to the “vetted” phase to be refactored and screened again.


Once a patch has been screened, it is sent to Rich Hickey for final approval. Rich can perform one of three actions on the ticket. He can outright reject it (perhaps asking that it be put into a contrib library), he can approve it for the current release, or he can approve it for the next release.
If a ticket is marked for the current release, one of the Clojure committers will take the patches attached to the ticket and commit them to the github repository. At this point the ticket is marked as done, and the ticket number is placed into the changelog for the next release of Clojure.
Once beta testing starts for a given version of Clojure, all new features will be placed in the backlog for the next release and only bug fixes will be accepted for the current release. Once the current version of Clojure has been released, the next release backlog will be committed to the source repository.