New category idea: Proposals

Site Feedback
, , ,
1

I’d like to see if we can fill a need that I feel is currently missing in the community.

In general, OCaml advances in spurts that come out of the productivity of very few individuals. This isn’t a bad thing per se, but the result is that there isn’t much planning or discussion in the general community, nor is there much feedback-gathering happening in public forums. Experts who know OCaml’s codebase will implement an idea and submit a PR, and then people may react to that PR, but again, this is almost entirely happening at a late stage of development. What about the non-expert who wants to raise an idea for the language and get people’s feedback? What if there’s some feature that people would find really useful, but the experts aren’t aware of demand for this feature because the community has nowhere where they’re permitted to express their desire?

What I’m thinking of is a category where people can propose ideas, either for libraries or for OCaml’s direction, and other people can show support for the idea or explain why it’s great, or not good, or just not a good fit for OCaml. A brainstorming area, if you will. Experts may look through these ideas for things to implement or just shoot down because they’re not supported by theory. An expert working on implementing a specific feature (e.g. Modular Implicits) can use this topic to think through repercussions of the feature, and to get people’s feedback before the next stage of implementation.

I know, the whole thing is experimental – but that’s kind of the point. I’m trying to encourage the kind of productive discussion that can lead to good things happening down the road. Many of these discussions take place before the PR on github comes about, but currently they only take place in limited quarters (e.g. Inria, Cambridge, Jane Street, and the emails of the lead developers), and I’d like to see if we can open up these discussions to make them more effective. Most importantly, unlike PRs, there’s minimal effort required to raise an idea here, and therefore there’s even less of a reason to feel bad if the idea is shot down.

As to why a category’s needed: I think it’ll give people the license to raise these kinds of ideas without just getting shot down right away. By creating the category, we give legitimacy to have these kinds of creative discussions, and acknowledge that we’re not wasting anyone’s time: if you don’t want to see these kinds of discussions, don’t subscribe to this category.

BTW I’m not set on the name for this category. I thought about calling it Design or Ideas, but I think these 2 things are encompassed by the term ‘Proposals’.

Worst case, if the category doesn’t work out, it can be removed later on.

5 Likes
2

Even more than legitimacy, it’ll give incentive to do so, which is great.

1 Like
3

What about the non-expert who wants to raise an idea for the language and get people’s feedback? What if there’s some feature that people would find really useful, but the experts aren’t aware of demand for this feature because the community has nowhere where they’re permitted to express their desire?

The Caml Mantis bug tracker is sometimes used for raising ideas in this way. Here are two examples:

  • PR6618 proposes octal escapes for characters and strings
  • PR7233 proposes improving GADT pattern matching to support refining abstract types

Both proposals were subsequently implemented by someone other than the proposer, and both were incorporated into the language.

I don’t want to discourage anyone from posting ideas here, of course, but people might like to know that there’s an effective channel available already.

4

I have seen this usage for Mantis in the past. Perhaps Mantis could be seen as the next stage for the more ‘actionable’ proposals to be written here, in case the author is incapable of creating a PR. The problems with Mantis are plenty, including the fact that it’s not widely seen by the community, that there is the constant noise of actual bugs that need to be addressed, and that the interface is unintuitive.

Additionally, the discussions I would ideally like to see here can reach far outside the scope of OCaml as a language/compiler, since they would involve the whole community and ecosystem.

1 Like
5

Application developers don’t have time to mingle with language developers. Don’t send them to an obscure bug tracker for them to weigh in diplomatically on some feature proposal. Not only they won’t give feedback, they simply won’t give a try to the language at all, because it’s flagrant that their needs won’t be fulfilled.

As an application developer, it’s baffling to see that GADTs were included in the language before namespaces.

As a tool developer, it’s painful to have to implement a specific feature just because only one very persistent person insisted on it and made you feel guilty to not implement it. Then you’d implement the feature only to wake up one year later and realize that nobody uses it and that it required so much work for nobody’s benefit.

Here with this new forum we could post feature requests within a Proposal category. Random users or prospective users can find them later, and hit “Like”, so that language developers will see what most people want.

1 Like
6

I find the idea interesting and some of the arguments convincing, but I’m a bit worried that a forum place could end up feeling like a wasteland of (often half-baked) ideas because of the lack of people available to evaluate them, provide feedback and turn them into effective implementations. There is a general asymmetry/imbalance where it is much easier and less effort-demanding to say than to do, to propose than to implement, and encouraging the former without an effective strategy for the later may be ineffective, and even possibly a source of frustration.
In communities with an established RFC process like C#, Rust or Haskell, one of the very real criticisms is that “RFCs end up being ignored” – and those communities have many more people working full-time on the language evolution than OCaml. @whitequark, who did some excellent work on handling RFCs in the Rust community, may have feedback on that.

The worry is not merely hypothetical, we already have the issue at the level of github Pull Requests (PRs), with many more people willing to send new PRs than to review existing PRs. And PRs already have the property that, because they require implementation work, they tend to be modest in scope and effect. The difference in cost versus work demanded for open-ended proposals can be much wider. For example, everyone has idea on how wonderful flambda could be if only it optimized X better, and almost no one is available to invest work in actually improving flambda.

We could consider having such a Proposal forum as a time-limited experiment, just like we did for Github Pull Requests initially: have it for six months, see whether it has a clear positive impact, otherwise close it and invite people to keep using Mantis / PRs.

@mjambon: I’m not sure “GADTs vs. namespaces” is a fair comparison given that it is actually easier to propose a convincing GADT design than a convincing namespace design (there was one attempt at doing GADTs and it succeeded, so far there have been at least two attempts to design namespace systems (one by myself, one by Pierrick Couderc) that did not work out).

2 Likes
7

I agree with your caution, and also agree that experimenting is the way to go. Let’s see how this goes. I don’t see this as a place to get real, full RFCs going, as that will probably involve moving to a somewhat more structured and actionable format – like a github PR or a mantis issue. But maybe I’m wrong and this is a good platform for that as well.

I think GADTs are just very esoteric, and so very few people had strong feelings about them. It’s easier to introduce a change to a communal project when few people care about said change, especially when it’s orthogonal to the rest of the language. Namespaces affect everyone in the community and everyone understands them, and so they all want to have a say. At the same time, it would be very good to have some ability to gauge community interest in particular areas and act based on those interests, rather than favoring the top-down approach we’ve had so far. This is something that’s only enabled by technology like opam and this forum.

2 Likes
8

You’re making my point. We want to give feedback - how we feel about things - without push-back and without getting into personal discussions. This is time-consuming and I’m not interested in burning my social capital over this; nobody is.

9

Just curious - why would someone want namespaces while we already have powerful module system?

10

@Alex Please start a new topic.

1 Like
11

Unfortunately, lot’s of PR are not blocked because they lack review, but simply because nobody can get in agreement over what should be done. If you want more reviews, potential reviewers should be directed to PRs that actually need review. At the moment, the “review-needed” tag is almost unused.

Triaging is not fun, but you can’t ask people to review random PRs in the bug tracker. Some of them have either no answer from the core team indicating that it will be ever merged or a 20 pages long thread with no decision whatsoever. Some other are suspended on purpose, and so on.

12

Maybe what I expect people to do is to help with both the reviews and the triaging. I am not sure that the two aspects can be separated – often you know whether or not it is easy to make a decision by just trying to make one.

13

This is overly optimistic. As someone who can review some stuff. The idea of reviewing something only to end up learning that the core team is not interested by merging the feature is the highest motivation-killer you can ever imagine. There is a triagining process for mantis issues, but it was never really extended to GPRs, except by you. A start would be to actually close PRs that are dead/rejected.

1 Like
14

A benefit of encouraging proposals is that when they are problematic in some way, the poster and others can learn from responses that explain why they’re problematic.

15

The Rust community has their RFC process for this https://github.com/rust-lang/rfcs

In short, if you would like to make a significant change to the language or platform tools you propose an RFC with a description of and rationale for the change and solicit feedback from the community.

I’m not advocating that we adopt their process whole cloth, but thought I’d mention it as an example of a community implementing something like what you describe.

[edit] Rust’s RFC process was mentioned earlier in the discussion but I’ll leave my comment up anyway, if only for the link to the process.