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.

▲

moring a day ago | parent | next [-]

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.

▲

lokar a day ago | parent | prev [-]

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.

▲

aleph_minus_one a day ago | parent [-]

> 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.

	▲	lokar a day ago \| parent [-]
		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