[jcgrillo]

The whole "anyone can submit a PR" thing has been a UX issue from day one. That probably needs to go away, and I doubt anyone would really miss it. Where Github could help is by providing a means to build trust that doesn't involve random unknown people slinging code at projects.

[jedberg]

Any sort of trust requirement would break the entire model and cause some serious inequality.

How would a random kid in a 3rd world country ever get noticed enough to enter a trust circle, for example?

[jcgrillo]

That's a hard problem! I don't know. But when we select colleagues we build trust before we let them in the building by interviewing them, looking at their work, checking their references. So maybe there's some sort of analogous process that isn't just "here's a big PR, look at it" that would be useful? If there was such a process, maybe that kid could go through it and become trusted.

EDIT: from Github's selfish perspective, this would gatekeep their CI load. I assume (I have no idea, it's just a guess) that mostly serving source code and handling commits is not primarily the scale problem. Instead (again just guessing) probably the vast majority of the compute load due to PRs is running all the CI checks. Nontrivial projects can spawn a hell of a lot of compute per PR, and on every subsequent commit pushed while the PR is open.

[roadbuster]

> would break the entire model

The "model" - GH effectively allowing an overload of their infra - is already broken

> How would a random kid in a 3rd world country ever get noticed enough to enter a trust circle

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

[jedberg]

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

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]

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

[RoddaWallPro]

Mitchel Hashimoto started a tool for this, https://github.com/mitchellh/vouch.

[jcgrillo]

This looks awesome thanks for the link.