# 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:** 1\
**Showing post:** 6

<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).

---

_[View the full topic](https://discourse.julialang.org/t/requests-for-comments/103551)._