> By submitting a quality change with a clear description, preferably with unit tests? Is that no longer considered an acceptable hurdle?

But the proposal is to specifically disallow that unless the person is already known.

That is the model today, the one that people want to get rid of.

▲

roadbuster a day ago | parent [-]

I think you are taking an excessive interpretation of what was suggested.

Let's level-set on the issue: Of late, GH has suffered a continuous stream of noteworthy outages. It is hypothesized the underlying cause of the instability has been the dramatic rise in submissions from coding agents ("AI"). The open question is how (or whether) GH can get load at a manageable level, with the proposal being, 'don't immediately allocate build/compute resources against any and all submissions.'

I don't see why that is equivalent to rampant disenfranchisement in the open source community. I believe what people have in mind is closer to, "don't immediately trigger an expensive build process as soon as someone submits a pull request."

	▲	jcgrillo 19 hours ago \| parent [-]
		> "don't immediately trigger an expensive build process as soon as someone submits a pull request." Yes, and I'd add to that "don't immediately trigger an expensive review process". There's no good reason maintainers should have to be on the hook for screening submissions from the entire general public (including all the various OpenClaws or whatever)... It's an absolutely unreasonable thing to ask of anyone. So Github has the opportunity to both protect their own uptime and do a decent thing for the community by solving this problem.