That doesn't really solve the problem. I've gotten PRs that do do an adequate job of explaining why why something should be implemented. Then I look at the code and it doesn't fully solve the problem, or it does so in a way that will obviously break something else.

In that case, isn't a sufficiently reasoned "why" a contribution in itself?

Not trying to downplay the time wasted to reject the PR, though.

A colleague once setup a PR description template that asked for short sections like:

- Why is this change needed (big picture)

- Why are you doing it this way (small picture)

- What are the trade-offs you made for this approach

- How do you know this is correct, that it works the way you think it does?

- What other changes or approaches does committing to this way block in the future?

etc. If you had actually thought through what you were doing, it was a few min to fill it all out. People were just on auto-pilot really struggled.

> If you had actually thought through what you were doing, it was a few min to fill it all out.

... for people who are native speakers of English.

Software engineering is a highly collaborative process. To be successful you need to be pretty good at reading and writing whatever language the team is using. I've worked with plenty of non-native speakers who were well above the average I see for natives. In the last 10 years I found the level of just basic writing for new Jr engineers has really fallen.

If you can't write, you can't think

you know EXACTLY what would happen in such a system.

I don't, please enlighten me.

My prediction is that many new contributors would complain loudly. Some existing contributors would sympathize.

It’s I think a normal evolution of a social norm. There will be a period of competing values.

people would use LLMS for those summaries, defeating the purpose. You can already see it in PRs in companies where LLM code is pushed.

I wonder if some of these projects with ayatollah maintainers are looking at forks sooner rather than later?