Where should Julia feature requests go?

[Tamas_Papp]

@gdalle

I thought it was very surprising, and a rather major unspoken policy (if true)

I think that implicitly, the problem is that making a useful (nontrivial) feature request that has a chance of resulting in a PR that is actually merged may require a lot of exploratory work at this stage in Julia’s development, and issues are not the ideal place to do this.

Discussion on this forum usually serves the purpose of clarifying this. Also, they help new users who believe they are missing a feature, while they are just not familiar enough with Julia to find an idiomatic solution.

In order to understand this better, it is useful to understand what people mean when they use “Julia” in this context:

1. The semantics of the language proper. These are the basic building blocks for the language: the parametric type system, control flow, namespaces, scopes, metaprogramming, dispatch, etc. The implicit intention is to keep these building blocks as orthogonal and small as possible, because changes are costly and have ramifications to the compiler etc. The bar for adding a new feature here is very high, and usually only those who are actively involved with working on Julia intervals have the experience to design a useful addition.

2. The syntax of the language. This is a favorite for brainstorming about new features, mostly because people miss syntax from another language they are used to. Usually, the problem is that it may not integrate well into Julia, either at the parser level or conceptually. Most of these feature requests just peter out, the exception is adding an operator and similar trivial changes.

3. The functions and types defined in Base. Because Julia has been in development for a long time, most of the low-hanging fruits have been addressed, and it is encouraged that new functionality should go into packages. (In retrospect, arguably a lot of this functionality should have been in packages already, but this cannot be addressed now without breaking.) A feature request has the best chance of succeeding when it addresses some very basic functionality or a something that cannot be don in a package.

4. The standard libraries. They are well onto their way of becoming packages and decoupled from the language proper. Features should be implemented in new or existing packages.

[apieum]

@ToucheSir

For the record, I just had no strong opinion on the whole naming discussion beyond not wanting it to spiral out of control like some past discourse topics have.

I don’t mean it’s intentional, if you don’t have “strong opinion” maybe you need time and feedbacks to gain perspective on it. Early noise doesn’t help.

ScopedValue is a good example of a feature request merged into trunk. I’ve been using it for 6 months and saw you trying differents solutions (from logger to task local storage…) before it was mature enough for merge.
This is a concrete and natural way to do:
Create a package, experiment things in a safe env. and when it’s mature enough to comply with the main project needs and requirements (code style, tests, traction, compatibility…), the feature request is just details but maybe you can enlight us on these details ?

@ToucheSir

While there’s certainly no hurt in trying to look at the question of “where should Julia feature requests go?” from a philosophical or systems of governance perspective, I suspect most people following this thread are here for concrete ideas about how to improve the status quo.

From my perspective status quo is an illusion, formalizing tends to prevent people to think by themselve which restrict possibilities and worst if they try something interesting outside status quo, there’s always someone to tell them to follow the established rules. In FOSS world there’s plenty kinds of people each one may have differents approaches, imo it’s more valuable to tell them they’re safe to be themselves, they’ve the right to experiment, there’s no failure just a learning process and we’ve all been there.

But if people are looking for something more concrete, a solution may be to extract data from github, discourse and all possible places where people communicate about feature requests to provide usefull insights on how to make feature requests.