- What problem are you trying to solve? Prior to any patch you should have a problem statement, and it should be included in the description of the patch.
- What is your solution approach? Please make this clear in the description, so that it does not have to be inferred from the code.
- Have you vetted your idea with the community? Please discuss on either the dev or clojure-dev list before your write your patch, and include a link to the discussion. (Not necessary for trivial patches like typos.)
- Which patch is which? As tickets grow, make sure you document clearly which patch(es) are active. Don't do this be deleting old patches, just refer to patches by name in the comments.List the tradeoffs.
- What other approaches did you consider, what are their tradeoffs, and why is the approach you selected best?
- How will you prove to others your patch works? Plan to include tests. Example-based tests are ok, but generative tests are preferred.
- Don't do too much! Submit small patches that address specific problems, don't add anything extra, even (especially!) "cleanup" of nearby code.List the tradeoffs. What other approaches did you consider, and why is the approach you selected best?
While Your Patch is Being Considered
- Keep the description up-to-date as comments come in. It is very time-consuming to reconstruct the current state of a ticket by reading the comment thread.
- Rally support. Votes are good, and precise comments from other users reviewing the ticket are even better.
- As tickets grow, make sure you document clearly which patch(es) are active. Don't do this by deleting old patches, just refer to patches by name in the comments.
Once you're ready to craft your code, the first thing you'll need is a clone of the Clojure or appropriate repository. The examples below are for the Clojure project -- for submissions to Clojure itself: