# Requests for comments

**URL:** <https://discourse.julialang.org/t/requests-for-comments/103551>\
**Category:** Internals & Design\
**Created:** [September 5, 2023, 7:15pm UTC](https://discourse.julialang.org/t/requests-for-comments/103551 "2023-09-05T19:15:34Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![ShalokShalom](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/shalokshalom/32/52462_2.png) [@ShalokShalom](https://discourse.julialang.org/u/ShalokShalom)\
**Post date:** [September 5, 2023, 7:15pm UTC](https://discourse.julialang.org/t/requests-for-comments/103551/1 "2023-09-05T19:15:34Z")

</div>

So far as I can tell, has Julia no system to develop the language, akin to RFC’s in other languages.

This has worked superb for [Rust](https://github.com/rust-lang/rfcs), [F#](https://github.com/fsharp/fslang-design), [Kotlin](https://github.com/Kotlin/KEEP), and [Python.](https://peps.python.org/pep-0001/)

Is this intentional, and do you see sense in them, potentially?

---

<div class="post-metadata">

**Author:** ![mbauman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mbauman/32/31082_2.png) [@mbauman](https://discourse.julialang.org/u/mbauman)\
**Post date:** [September 5, 2023, 7:20pm UTC](https://discourse.julialang.org/t/requests-for-comments/103551/2 "2023-09-05T19:20:18Z")

</div>

See the [CONTRIBUTING.md](https://github.com/JuliaLang/julia/blob/master/CONTRIBUTING.md#contributing-to-core-functionality-or-base-libraries) on how this works:

> The Julia community uses [GitHub issues](https://github.com/JuliaLang/julia/issues) to track and discuss problems, feature requests, and pull requests (PR).
> 
> Issues and pull requests should have self explanatory titles such that they can be understood from the list of PRs and Issues. i.e. `Add {feature}` and `Fix {bug}` are good, `Fix #12345. Corrects the bug.` is bad.
> 
> You can make pull requests for incomplete features to get code review. The convention is to open these a draft PRs and prefix the pull request title with “WIP:” for Work In Progress, or “RFC:” for Request for Comments when work is completed and ready for merging. This will prevent accidental merging of work that is in progress.
> 
> Note: These instructions are for adding to or improving functionality in the base library. Before getting started, it can be helpful to discuss the proposed changes or additions on the [Julia Discourse forum](https://discourse.julialang.org/) or in a GitHub issue—it’s possible your proposed change belongs in a package rather than the core language. Also, keep in mind that changing stuff in the base can potentially break a lot of things. Finally, because of the time required to build Julia, note that it’s usually faster to develop your code in stand-alone files, get it working, and then migrate it into the base libraries.

---

<div class="post-metadata">

**Author:** ![Sukera](https://avatars.discourse-cdn.com/v4/letter/s/ce7236/32.png) [@Sukera](https://discourse.julialang.org/u/Sukera)\
**Post date:** [September 5, 2023, 8:26pm UTC](https://discourse.julialang.org/t/requests-for-comments/103551/3 "2023-09-05T20:26:16Z")

</div>

I’ve recently heard an interesting take on why these projects have this kind of RFC or PEP process - it’s an easy “soft no”. “We’re happy to discuss this, provided you make a convincing case and specify what you want to achieve/fix/have” is such a “soft no”, at least for most big feature requests. If someone can’t even be bothered to spec out exactly what they want, why should they get the attention & mindspace from others to disseminate their idea?

Apologies for the long video, but I think it was somewhere in this discussion:

[![](https://global.discourse-cdn.com/julialang/original/3X/4/c/4c89e83aa05d67217c0cae15ca92311e640a3f04.jpeg "Oxide and Friends 8/28/2023 -- Open Source Anti-Patterns with Kelsey Hightower") ](https://www.youtube.com/watch?v=13ctYOu8TsA)

---

<div class="post-metadata">

**Author:** ![ShalokShalom](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/shalokshalom/32/52462_2.png) [@ShalokShalom](https://discourse.julialang.org/u/ShalokShalom)\
**Post date:** [September 6, 2023, 12:09pm UTC](https://discourse.julialang.org/t/requests-for-comments/103551/4 "2023-09-06T12:09:45Z")

</div>

I think this is true to the extent, that software development generally is full of soft no’s.  
And this kind of process simply helps to organize and communicate that.  
I like it.

---

<div class="post-metadata">

**Author:** ![moble](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/moble/32/23535_2.png) [@moble](https://discourse.julialang.org/u/moble)\
**Post date:** [September 6, 2023, 7:46pm UTC](https://discourse.julialang.org/t/requests-for-comments/103551/5 "2023-09-06T19:46:41Z")

</div>

> [@Sukera](#):
>
> I’ve recently heard an interesting take on why these projects have this kind of RFC or PEP process - it’s an easy “soft no”.

I’m mostly familiar with PEPs, and can confidently say that — while it might be true for some — they are absolutely not all for "soft no"s or to [“say ‘no’ by saying ‘yes’”](https://www.youtube.com/watch?v=13ctYOu8TsA&t=5177s); _many_ of them become the de facto standards and documentation for a lot of things in the ecosystem. They are for working out the kinks in complicated issues that affect a lot of users, and those whose issues do get worked out fundamentally shape the language in important ways. Of course, IETF RFCs are the literal standards on which much of the internet is built.

On a related note, I’ll point out [julep](https://github.com/JuliaLang/Juleps)s, which filled that niche, but haven’t really taken off — I guess because the other options seem to work for the community. To take a current example, the `main` fiasco is being worked out here on discourse and on the original github PR. Maybe a julep would have worked better, but in its current state, not many users are paying attention to that repo. I think discourse and github make it easier for real users to get involved, and that increased churn allows faster iteration towards better ideas, but also more noise 🤷.

---

<div class="post-metadata">

**Author:** ![Sukera](https://avatars.discourse-cdn.com/v4/letter/s/ce7236/32.png) [@Sukera](https://discourse.julialang.org/u/Sukera)\
**Post date:** [September 6, 2023, 8:18pm UTC](https://discourse.julialang.org/t/requests-for-comments/103551/6 "2023-09-06T20:18:33Z")

</div>

> [@moble](#):
>
> I’m mostly familiar with PEPs, and can confidently say that — while it might be true for some — they are absolutely not all for "soft no"s or to [“say ‘no’ by saying ‘yes’”](https://www.youtube.com/watch?v=13ctYOu8TsA&t=5177s); _many_ of them become the de facto standards and documentation for a lot of things in the ecosystem.

Of course, an actual PEP or RFC, once written, is a very good starting point for that kind of standardization. That wasn’t my point though - it’s the action of _requiring_ that which is the “soft no”, not the PEP or RFC itself. The argument is that if a feature merits larger discussion, it ought to merit a larger proposal (and how that would fit into the existing language) as well, not just a “I would like X please”, because those kinds of requests very quickly run afoul of hidden assumptions various people participating in the discussion end up making (through no fault of their own - that’s just how communication happens). Clarifying that up front in a PEP or larger RFC or JulEP can make that easier.

> [@moble](#):
>
> Maybe a julep would have worked better, but in its current state, not many users are paying attention to that repo. I think discourse and github make it easier for real users to get involved, and that increased churn allows faster iteration towards better ideas, but also more noise 🤷.

I attribute much of that to the general lack of direction in how feature requests would like to be handled, see e.g. [here](https://discourse.julialang.org/t/improving-the-julia-issue-tracker/83365), [here](https://discourse.julialang.org/t/where-should-julia-feature-requests-go/102835) or [here](https://github.com/JuliaLang/julia/pull/50881). There just isn’t any form of consistency or overlook by anyone, and hence getting a higher maintenance (but presumably much lower signal-to-noise ratio) proposal in the form of a JulEP off the ground is very challenging. We thus arrive at the current situation - feature requests or RFCs or similar go “wherever” and are picked up/commented on by “whomever”, implemented by “anyone willing to spend the time” (only to be then told once a PR is opened that, as implemented, “triage doesn’t like it”. Much of the time spent implementing something larger could be avoided by just talking about the thing ahead of time, and actually planning for where things should go).