Looking at the release notes, I think that most changes are incremental “quality-of-life” improvements, and adding overhead to those would only slow things down without helping.
However, some changes either (1) are significant or (2) do not have consensus. These would benefit from added process.
I consider three dimensions along which adding process affects development.
Fewer changes
Thinking of changing the language as a classifier, we want to approve good changes and reject bad changes. Under this model, there are two effects of adding process. Because there is more overhead in making changes,
- Fewer good proposals are approved.
- Fewer bad proposals are approved.
Julia becomes more stable over time, so fewer changes are expected with increasing maturity. This is especially important after 1.0 since changes can’t easily be rolled back.
Better changes
But this first model misses something: the positive effect of structured discussion on the proposals themselves, before a decision is made.
There are several sources of information that Julia’s decision-making process could use to improve its proposals, which are sometimes used today and sometimes not.
Packaged changes
Multiple dispatch and macros allow changes to be implemented and evaluated before changing the language. However, under current practice, some significant changes are added to Julia or Base without anybody making the changes in a package first.
Other languages
Julia is innovative in several important respects, but also shares many commonalities with other languages. Currently, there is no process for reviewing other languages to see how they handle issues. Julia’s developers are experts in certain languages so they implicitly incorporate information about those languages into their decision making. But there are other important languages that don’t have much representation among Julia developers.
A more systematic review of other languages’ implementations of a feature could be very informative and beneficial. If languages X,Y,Z all do this feature a certain way, it would be good to know that and discuss if we want to diverge from that for particular reasons.
Alternative designs
One of the good things about Python’s PEPs is that they often have an “alternatives” section that explicitly enumerates and discusses the benefits and drawbacks of other ways of achieving the goal of the proposal. It’s easy to forget to do this when focused on a particular implementation, which means possibly-better designs don’t always get considered.
Better change documentation
Julia is going to have a long life, and it’s possible that most contributors haven’t made their first contribution yet. Knowing why Julia is the way it is will help future contributors make decisions.
Having a structured change documentation means later readers can understand why the language made a certain choice, without relying on someone to remember.
A proposal
- If a change is minor (as determined by the proposer) AND has no objection, no process is needed.
- If a change is not minor (as determined by the proposer) OR has ANY objection, several additional pieces of information are needed:
- What is the objective of the change?
- If the change can be made in a package, the change MUST be made in a package first. Link to the package.
- How do other languages handle this feature? List several. If deviating from a common practice, explain why.
- What are some alternative designs for achieving this goal? What are their benefits and drawbacks? Why choose this one over the others?
- What are the objections to the change? Respond to the objections.
This document doesn’t have to be long, but I think it will improve decision making. If it’s not helpful, it can be reevaluated or stopped. I would be happy to write up an example for my own pet proposal if it would be helpful to see one.