I'm not convinced it blows up. It might also end up placing a larger burden on contributors, and especially first-time contributors, to provide concise, high-quality documentation that justifies their contribution.

I'm thinking of something like: Explain, in at most 300 characters, why we should merge your change, or at least why we should invest the time to read a longer explanation (somethings things ARE complex). If you don't do that, or those 300 characters aren't convincing, or have nothing to do with your change or the longer explanation, then you get a canned response so the maintainers waste minimal time.

▲

thayne a day ago | parent | next [-]

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

▲

Keyframe a day ago | parent | prev [-]

you know EXACTLY what would happen in such a system.

▲

moring a day ago | parent [-]

I don't, please enlighten me.

▲

lokar a day ago | parent | next [-]

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.

▲

Keyframe a day ago | parent | prev | next [-]

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

▲

CamperBob2 a day ago | parent | prev [-]

Explain, in at most 300 characters, why we should merge your change, or at least why we should invest the time to read a longer explanation (somethings things ARE complex) would simply become a prompt.

The solution, of course, is to use the best available LLMs as the first line of defense against slop contributions. But if the project maintainers have issued a sweeping fatwa prohibiting an entire class of useful tools, that option along with many others is off the table.

	▲	tiahura a day ago \| parent [-]
		I wonder if some of these projects with ayatollah maintainers are looking at forks sooner rather than later?