Clojure

Contributing to Clojure

Ways to Contribute

There are many ways to make a meaningful contribution to the Clojure community:

  • Advocate for the use of Clojure in your organization

  • Use Clojure and share your experience via talks, blogs, etc

  • Start or join a local meetup

  • Help new Clojure users in Slack or other forums

  • Create or provide patches to open source libraries

  • Create or improve Clojure tools

  • Write guides or reference documentation for libraries

  • Write intros or getting started guides for tools

  • Create Clojure podcasts, screencasts, or videos

  • Give a talk at a conference

  • Write an article or book

  • Start a Clojure podcast

  • Start a Clojure conference or join the organization team for an existing one

  • Test new alpha or beta releases of Clojure on your code base and provide feedback

If you are writing a guide, making an event, or creating a resource, please consider contributing to this web site, clojure.org. All of the content is stored in GitHub and pull requests and issues are accepted. For more information on how to contribute, see the page on contributing to the site. Every page has a link to the corresponding source file in the bottom right corner. If you have an idea for a new guide or updated documentation, please file an issue for discussion.

Clojure Development

Clojure was created by Rich Hickey and is developed by a core team of developers at Cognitect, which supports this work. The Clojure development team values a measured and thoughtful approach to language evolution with a strong emphasis on maintaining backward compatibility.

The Clojure core team values those that engage with the current stream of ongoing work, doing the difficult work of triage, patch development, screening, etc. The workflow page highlights places to tap into those queues of work as jira reports. The core team tends to focus on tickets primarily in the late alpha / early beta period for a release cycle. During other parts of the release cycle, activity may seem dormant, but that is the perfect time to improve tickets so they are ready to evaluate. Tickets that are well-written with good patches can move quickly through the cycle at the appropriate time.

Important development resources:

Issues

If you have found an issue with Clojure, please consider filing a ticket in the issue tracker. You might want to check what you are seeing with others on a Clojure discussion forum before filing. Please review the guide to creating useful tickets.

Clojure accepts contributions as patches on issues. Before submitting a patch, please sign the contributor agreement, and review these guidelines on developing patches. Please note that tickets may be assessed over a long period of time, following the workflow.

Enhancements and Features

Clojure’s direction is determined by Rich Hickey and the core team. This process is open to input and visible in issues and commits, but not explicitly driven by the community. The core team pays attention to the needs of the community by monitoring and participating in many Clojure discussion forums, and by reviewing issues and votes in the issue tracker.

If you have an idea for an enhancement or new feature for Clojure, it may be helpful to search the issue tracker for prior issues and/or raise this idea for discussion in one of the Clojure forums. In particular, the mailing lists or #clojure-dev room on Clojurian slack are good places to discuss.

Please follow the guidelines in Creating Tickets and Developing Patches - enhancement/feature tickets should start with a compelling problem to solve and compare alternatives and their tradeoffs, rather than leap straight to a solution and a patch. Clojure is a small language and endeavors to remain so. In many cases, proposed features can instead be provided in functions or libraries outside the core.

Roadmap

Clojure is an open-ended project with no fixed release schedule. Major releases typically occur about once per year. While there are usually a few focused areas of work in a major release, it is common for those to change during the development of the release in response to either feedback or changing external needs. Because of this, a roadmap is typically not declared at the beginning of a release. Ongoing development is visible during alpha releases, often phased over multiple dev releases. The Dev Changelog chronicles these changes during the release cycle.

Additionally, the core team may be doing work in dependent projects or tools, rather than the language itself, such as spec, core.specs, tools.deps, clj, etc. This is still considered part of the broader "release" train.