exactly this. If we adopt PEP, things that we could have fixed between a 0.1 will have to at least wait three 0.1v, and things we could have fixed between 1.5 and 1.7 will end up in 2.0
Julia is too young for PEP for sure, and I can’t imagine if we require a 1000-word essay, many quality of life improvements would have been implemented. (many of them started with relatively new developers (or just power users) asking on here or github issue)
Instead of trying to introduce a full, formal system like PEPs, what can be done to help the community keep abreast of progress in language development? A couple thoughts that come to mind:
Have a Github board for any issues or PRs that could be considered “proposals”. Since label hygiene is pretty good in the Julia repo, certain labels could be used to drive the automation between different states. For bikeshedding purposes, let’s say the columns are “WIP”, “ready for triage”, “triaged” and “done”.
Document this somewhere on julialang.org. I saw a couple days ago that nobody knew triage wasn’t mentioned at all on any official resources, so even a page with a couple sentences and links could help there. Bonus if there’s a way to auto-generate a (less detailed) table like GitHub - tc39/proposals: Tracking ECMAScript Proposals, but even linking to a project board or filtered list of issues would work (as well as instructions to access the triage call so people don’t have to stumble upon the slack channel themselves)
Changes that are externally visible should touch the NEWS.md file so if someone were to set up a bot to announce such changes, or just look at it and make posts on discourse summarizing recent changes, that’s a pretty good concise summary of what has changed that affects end users.
Maybe I’m off in my impression of PEPs in python (disclaimer: I’ve written maybe five lines of python total in my life), but the only PEPs I hear my contemporaries discussing or engaging with are ones that have to do with new syntax or features that to some degree change what constitutes idiomatic python. Considering that the goal in this thread seems to be creating a system in which people who aren’t Julia devs can keep better track of the direction of the language (since the devs are obviously plugged in already without them), I think it would also be informative to consider how many big sweeping changes that non-hardcore end-users would really care about are planned. Like, I see why python had one for introducing pattern matching and stuff, for example, as it might completely change the way some people write python code. But if the Julia core team isn’t planning to continue to introduce new core features and syntaxes that change idiomatic use, I think that might point towards not introducing a more formal method for tracking changes and development.
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.
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,
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.
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.
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.
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.
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.
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.
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.
A digest of what changes have landed would be great! I believe the ask in the topic is more about keeping track of changes before they are merged, so having a (lightweight, so as not to burden contributors) mechanism for that would still be valuable.
Currently, one has to manually dig through issues and PRs to separate quick bug/doc fixes from the non-trivial design discussions and feature proposals. Since PRs with as much traffic as, say, RFC: bring back v0.6 scope rules in the REPL by JeffBezanson · Pull Request #33864 · JuliaLang/julia · GitHub are quite rare in the grand scheme of things, would it not be feasible to assign them a label or add them to a Github project so that community members who want to provide feedback are more aware of what’s out there? I can think of a few examples where it would’ve been nice to have a semi-comprehensive source of “big” feature proposals to point people to from this forum. Another added benefit would be that it helps narrow down what doesn’t have a proposal in flight already, while providing a list of prior art for anyone who wants to submit their own to fill perceived gaps.
Ok, let’s do this thing. Someone from this thread should kick it off by doing this for #4600.
I wish this became the common mindset when responding to suggestions for changes to the language. When someone says “Julia should have X”, they should be gently encouraged to make a package that does as much as possible to provide X without a change to the language as a prerequisite for further discussion.
Maybe it won’t have the last step if that’s impossible in a package, such as dedicated syntactic sugar, but they have a viable implementation hammered out that works, and can be tried out and tested in the wild. And maybe eventually merged into the language, like the examples you mention.
But that’s not how it works at the moment. Merits of various features are debated in the abstract, leading to endless discussions.
Done, please consider editing the original issue these are addressed.
I like @akb’s writeup so much that I think it would be useful as a Github issue template for proposals, what do you think?
@akb, @paulmelis: any progress on writing up a PEP-like report for #4600? I’d like to make progress on that issue and if we’re instituting a PEP-like process then we can’t make any additional progress until someone has written this. It would be great to get an estimate of when we can expect this. It would probably also be good to know which of you are working on it so that we don’t duplicate work unnecessarily.
Hey @StefanKarpinski I’m pleased to hear the process/proposal idea is being received well. I realize now that I had left some components unspecified, such as who is going to write each proposal.
I don’t have a good understanding of the consequences of #4600, and I can’t afford to learn all about it in order to write it up. In general, I won’t have the resources to write proposals for complex issues that I’m not involved with.
Two proposals I could write would be (1) a proposal for my pet issue “Distinguish string functions for data values vs programmer information” or (2) a proposal for proposals (a “Julep Julep”).
If each issue owner writes their own proposals, that may place an unmanageable burden on the most prolific contributors of significant proposals unless they can offload work to someone else interested in advancing a particular idea. For #4600, I see 33 participants in that conversation, so maybe one or two of them are interested in writing a proposal.
Ah, I was hopeful that someone was offering to do some work but I had a nagging suspicion I was actually being volunteered to do more work. If someone happens to do this process, great. Otherwise I’m just going to continue on as I would have done.
I see nobody stepped up in that issue and I understand how that could make you feel like this is just more weight on your shoulders.
I want the proposal idea to work for all the reasons I listed, so maybe as a gesture and demonstration I can try to synthesize a first draft for the fromfile proposal. Hopefully someone involved in that issue can correct my errors.
Part of the idea of the proposal suggestion is that your job may be made easier because you won’t have to do the work of synthesizing all the comments into an implementation or trying to figure out what’s actually being proposed – it lets you just say “no proposal/package, no (significant) change”.
It is true that writing a proposal and package is real work. Maybe I’m naive and nobody will be willing to actually write any proposals. Python has a concept of a “BDFL delegate” for an issue, in which Guido would name some specific person to take charge of managing a proposal. That could help with the diffusion of responsibility that we see in the fromfile instance.
who’s paying for assistants/secretaries wage? isn’t this precisely why at the moment we probably don’t want a full blown PEP-like process because we’re moving pretty rapidly with many active but may other wise pretty busy contributors?
What I think we can do is add “what makes a good PR” in CONTRIBUTING.md. There is a lot of stuff in there already, but looking it over something does seem to be missing. Basically we should detail what our standards are for a quality PR, e.g. stating explicitly that we like to see:
Then if a change is proposed that we’re not sure about, we can ask that those points be addressed.
Having a BDFL declare that a certain process must be used, or is rejected and shall not be used, is not really our style. If somebody puts up a good PR, I’m going to accept it whether they wrote a formal document or not. Or, if somebody writes up a proposal (in whatever format) I’m happy to look at that as well. A good example is the recent atomics feature: Julia Atomics Manifesto - HackMD
There Jameson found it useful to write up a design document first, and there was some discussion and iteration on it before and during implementation. If there hadn’t been such a document, it would have been reasonable for somebody to comment “this is a complex change, I think this could use a formal proposal”. Proposals, of course, can also come in the form of issues and not necessarily PRs.
I can see that it’s kind of useful to have a standard suggested proposal format for those cases where a proposal is warranted, but it’s not really a big deal to me. I’ll read a proposal in any format, and if I think it’s lacking something I’ll say so 
Detailing quality standards for changes sounds like a great move. 🖒
Given the impact of checklists on quality, I think it would be helpful to have a place where proposers check some boxes to confirm they actually dealt with each of the quality standards. Even without enforcing anything, having a reminder “oh yeah I’m supposed to consider alternative designs” (etc) may help out.
It would be good if such a checklist weren’t hidden in a giant CONTRIBUTING.md. I think @Tamas_Papp had an idea about a proposal template; maybe the standards list could be in the PR template too.
As an alternative to the PEP comparison, I’d like to point to the Rust RFC process [1]. I think it walks the line well between ‘overly formal’ and ‘hasty and ill-considered’, as well as the one between ‘overly technical and opaque’ and ‘political and shallow’. I think it’s an improvement on the Python system, and something Julia could do well to emulate.
I think the issue (heh) is more about issues than PRs. A PR is already very concrete code and can be discussed and experimented with.
In contrast, there are a lot of issues proposing some change to Julia without sufficient discussion of motivation, alternative implementations, how it is done in other languages. This leads to long discussions going in circles.
Julia is mature enough at this point that it would be reasonable to ask that people making proposals without PRs about changing the core language in some way invest a bit of work into at least writing it up in detail.