Better organisation of reviews

It might change the result, or it might not - I'm not sure it's fair to generalise about that. I've participated in reviews which seem to be going one way until somebody chimes in much later on with some domain-specific expertise or use-cases.

Personally, I'm finding it difficult to keep up, and that's why I want to revisit the question of whether it is really necessary for reviews to be so short. I feel that the onus should be on justifying why reviews are so short, rather than the opposite. With such short reviews, even the smallest of things can materially impact how much time somebody has to read, consider, and express their thoughts. Take the review about property wrappers as function arguments - something like that is likely to have a very big impact on the language, and it feels rather unprofessional that circumstances like a sick child would significantly limit how much somebody can participate in that review. It is mostly a question of professionalism.

As for the delay: the part of this that matters most (IMO) is whether the review time causes tangible delays in shipping the feature to developers in official releases. But official releases don't just spring up and surprise us: they are planned and staged, so I don't think this is actually going to delay when things ship. I can only remember one very time-sensitive proposal, and of course I expect the core team to reserve the right to make those kinds of exceptions as needed.

2 Likes