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 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:
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’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.
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.