There is a lot of talk about how hard it is to contribute to clojure.core, and also quite a lot of reasonable arguments on why it’s hard. I don’t want this topic to dwell on the ongoing discussion, so please help me out here
My background comes from Python, Objective-C and a little bit of Elixir. All different languages with different governance models. I’ll try to highlight here how these languages differ in how they are developed, in the hopes that it might help propel the discussion a little bit forward, and actually allow people to help clojure.core in areas where they want and can take help. There is a lot of information already out there about this, and I aim to gather it in this thread.
I’ll start with examples of other languages:
The easy one first – Objective-C is (now) developed and governed by Apple, and until Swift came along it was the only game in town if you wanted to target mac/iOS platforms. No transparency, no community input, developed in the shadows and every now and then you’d get a major release, WWDC presentations, documentations, book updates etc etc.
Python used to have a BDFL but recently he stepped down after 20+ years of involvement.
There is an extensive developer guide here: https://devguide.python.org
The bug tracker is powered by Roundup and can be found here: https://bugs.python.org
To contribute, you need to sign a CLA so that the PSF can use your code. PSF is a software foundation that owns the copyright of Python (transferred to it from the BDFL).
There used to be a patch-driven workflow but these days Github PRs are used.
There is a standard process for major additions to the language, called PEPs (Python Enhancement Proposals). The main concept is that you float an idea to the python-dev list, and if it doesn’t get shot down there, you are asked to write a pretty comprehensive PEP that covers problem statement, rationale, alternatives considered, impact on existing code etc etc. Various groups of people shepherd the process (editing, requesting for more input etc etc) but the final decision to reject/accept the PEP rests with the BDFL (or his chosen assignee).
For smaller things, such as additions or fixes to the (wide) standard library there is a well-established process that involves numerous people. Examples are triagers, reviewers, “nosy people” who might be in
the issue etc.
Triagers are people who can change the status/type/etc of issues. You gain this role after demonstrating your ability to help and to collaborate with others.
Triage and Code Review is usually the bottleneck. The dev guide says that you should wait a month until a code review, and then you can ping the issue to get a reminder. No one is paid to do code reviews.
There are many gentle reminders that getting your contribution in is hard, and might still be rejected after lots of work.
There is a also a dedicated security communications line for CVEs etc.
There is a core team of 6 people, one of which is José Valim, Elixir’s creator. The development guide lives here: https://elixir-lang.org/development.html
GitHub is used extensively, both issues and PRs. Longer discussions happen on the elixir-core mailing list. Before proposing a big change to the language, you are advised to gather community feedback on forums etc, then write it up on the mailing list.
There seems to be a policy of aggressively fixing/closing issues posted on GitHub. Issue response time is also very fast. There doesn’t seem to a well-documented process. José seems to be doing a lot of triaging work on GitHub issues. It appears he is full-time employed just to work on Elixir.
It is pointed out that since Elixir has macros, you can use them to extend the language without changes to the core. The core team focuses on things you can’t do with macros, and “best-practice” features/concepts that gain leverage by being in the language itself.
To be continued. I’d love to hear how other languages deal with this. Please, let’s not use this topic to judge – just facts.