I don’t really agree with your assessment. Some points about bikeshedding:
- It is easier to just give opinions than do a full review; if you feel that a PR discussion is full of discussions, sometimes the issue is the lack of people available/motivated to do a full review. (But the opinions are already useful; for example #11882 got many opinions and no full review and this sufficed to make good progress on the design for a new iteration of the PR.)
- I don’t agree with your “no-brainer” assessment on either of the two PRs you cite.
- #11993: Changing the tools we install by default could have unforeseen effects on our users (who knows how those tools are used?), so we need a broad discussion with the community to make sure that a change is safe/acceptable. If we merge this as a “no-brainer” and then, at the next release, users end up complaining that their workflow broke, and we have to revert, this is a fair amount of time wasted for everyone. Of course, there is a risk of this happening no matter how long we discuss the PR, but I think it is important to take the time to hear people on this.
- #2170: I fail to see how you think of a fundamental change to many modules of the stdlib API as a no-brainer change. We don’t have operators in the stdlib for now (except in the initially-opened namespace), so figuring how to do this right is tricky. Binding operators are also a new feature and people don’t agree on the right way to design them yet (there is another PR open that could change our syntactic choices quite a bit).
The standard library is held to very strong backward-compatibility expectations, which make mistake costly. This is a reason why there is a lot of hesitation to large stdlib changes. (For a while it was even completely frozen. The situation has improved a lot in the last few years, thanks to a few brave souls notably @nojb, @c-cube and @dbuenzli.) We could relax this backward-compatibility requirement, but this would also have costs in the ecosystem.
The OCaml development process is very much not a “move fast and break things” sort of thing. People tend to be averse to change by default. This has costs – it can certainly be frustrating to contributors – but it also brings a lot of value for users of the language, who rarely need to be worried about moving to a new language version. I think that some of what you call a bike-shedding culture is part of what preserves this value for users.
Of course, there is also superfluous bike-shedding, and I am sure that there are various aspects of our change process that could be changed – including various aspects that I cannot see/recognize myself as I am too used to the current ways of doing things. But I remain of the impression that the first source of frustration for contributors are the delays in getting a decision on their PR, and that this is not caused by the discussions but by the lack of workforce to take those decisions – at the level of quality we have come to expect of these decisions. We could, certainly, decide to worry less about changes and be more trigger-happy with the merge button, but do you really believe that we would get a better language in the end?
In the OCaml review process I see a culture of bikeshedding on basic design and alternatives after the implementation is already up for review in someone’s PR.
What would you propose as a different way of doing things?