[hombre_fatal]

Well, the problem you just outlined is a reputation (+ UI) problem: why are contributions from unknown contributors shown at the same level as PRs from known quality contributors, for example?

We need to rethink some UX design and processes here, not pretend low quality people are going to follow your "no low quality pls i'm serious >:(" rules. Rather, design the processes against low quality.

Also, we're in a new world where code-change PRs are trivial, and the hard part isn't writing code anymore but generating the spec. Maybe we don't even allow PRs anymore except for trusted contributors, everyone else can only create an issue and help refine a plan there which the code impl is derived?

You know, even before LLMs, it would have been pretty cool if we had a better process around deliberating and collaborating around a plan before the implementation step of any non-trivial code change. Changing code in a PR with no link to discussion around what the impl should actually look like always did feel like the cart before the horse.

[bombcar]

Because until now, unknown contributors either submitted obvious junk which could be closed by even an unskilled moderator (I've done triage work for OS projects before) or they submitted something that was workable and a good start.

The latter is where you get all known contributors from! So if you close off unknown contributors the project will eventually stagnate and die.

[SlinkyOnStairs]

In the long distant past of 4-5 years ago, it simply wasn't a problem. Few projects were overwhelmed with PRs to begin with.

And for the major projects where there was a flood of PRs, it was fairly easy to identify if someone knew what they were talking about by looking at their language; Correct use of jargon, especially domain-specific jargon.

The broader reason why "unknown contributor" PRs were held in high regard is that, outside of some specific incidents (thank you, DigitalOcean and your stupid tshirts), the odds were pretty good of a drive by PR coming from someone who identified a problem in your software by using it. Those are incredibly valuable PRs, especially as the work of diagnosing the problem generally also identifies the solution.

It's very hard to design a UX that impedes clueless fools spamming PRs but not the occasional random person finding sincere issues and having the time to identify (and fix them) but not permanent project contribution.

> and the hard part isn't writing code anymore but generating the spec

My POV: This is a bunch of crap and always has been.

Any sufficiently detailed specification is code. And the cost of writing such a specification is the cost of writing code. Every time "low code" has been tried, it doesn't work for this very reason.

e.g. The work of a ticket "Create a product category for 'Lime'" consists not of adding a database entry and typing in the word 'Lime', it consists of the human work of calling your client and asking whether it should go under Fruit or Cement.

[sheepscreek]

I don’t know why you got downvoted. Those are good points.

Contrary to popular belief, I believe open-source projects are poised for a significant windfall. If a project lacks the ability to transform a good problem into an advantage, that’s their prerogative, but it shouldn’t be the norm (I hope not).

I like to think of it as a stranger/volunteer using their tokens to give the project maintainers a choice. Imagine each issue having 3-4 PRs - it’s a brave new world that demands new solutions!

From a place of scarcity - to now picking from multiple PRs, not a bad problem to have. This is turning into a signal vs noise optimization problem. Could it be solved with agents specially fine-tuned for this use-case? Maybe. Why not?

Also many projects on GitHub do have discussions (typically in a long Issues thread) before someone opens a PR.