[theredbeard]

OSS was already brutal for new contributors before AI. You'd spend hours on a good-faith PR and get ignored for months, or get torn apart in review because you didn't know the unwritten conventions. The signal-to-noise ratio sucked but at least maintainers would eventually look at your stuff.

Now with AI-generated spam everywhere, maintainers have even more reason to be suspicious of unknown names. Vouch solves their problem, but think about what it means for someone trying to break in. You need someone to vouch for you before you can contribute, but how do you get someone to vouch for you if you can't contribute?

I get why maintainers need this. But we're formalizing a system that makes OSS even more of an insider's club. The cold start problem doesn't really get any warmer like this.

[OkayPhysicist]

Good filters make good communities. Back in the good ol' days of the internet, access to the internet in of itself was a decent filter: you had to want to be online, you needed to be somewhat technical, or at least willing to grapple with technical problems, and you needed to actively seek out communities online which aligned with your interests, and there was little financial motivation to do so in bad faith. As the barrier to entry to the internet writ large dropped to near zero, communities that were built around the bygone era's natural filtering suffered. Communities must now establish filters proactively.

Ultimately, you need to choose: does your community prioritize its short-term health, or ease of access? If a community never lets anyone in, then it withers and dies eventually, but in the meantime the community can be extremely high-trust. That's what happened to fraternal orders like the Oddfellows and the Free Masons post-Vietnam. If the community has zero barrier to entry, you end up with Twitter: a teeming mass of low-trust members screaming into the void.

The happy medium is allowing in new members just as fast as you can build trust and community cohesion. University clubs are a good example of this: at a massive turnover rate of 25% per year, they need to form processes to not just recruit that many people, but integrate that big of a chunk of their community without destroying the high-trust environment. That's how you end up with the ritualized "rushing" process.

[mrguyorama]

>Back in the good ol' days of the internet, access to the internet in of itself was a decent filter: you had to want to be online, you needed to be somewhat technical, or at least willing to grapple with technical problems, and you needed to actively seek out communities online which aligned with your interests, and there was little financial motivation to do so in bad faith

And it was horrifically expensive to be online until the mid 90s, or late 90s depending on where you were.

[MattGrommes]

The comment I read about this that I liked was that they want to push the idea of starting with an Issue and a discussion before going straight to a PR. That way you can build reputation by contributing to a discussion first. Maybe you could "earn" a temporary Vouch like this that lets you start submitting. Still open to attack but the attack is at least more difficult.

[judahmeek]

Agreed. The obvious solution is to lower the barrier of entry for demonstrating good intent, but also lowering the ceiling of effort required to analyze that demonstration for good intent.

Mandating participation in discussion prior to creating any PR sounds like a perfectly reasonable requirement.

[bootsmann]

Maybe it is because I mostly contribute to projects that have corporate backers but this has not been my experience at all. Usually opening an issue with “I would be willing to fix this” gets good and quick responses from maintainers. Maybe linux kernel devs are different but I doubt many of us have to interact with that as part of our day-to-day business.

[iamrobertismo]

Building projects, especially larger ones, has not been solely about writing code. I don't see how anything you are saying is a bad thing at all. Drive-by PRs and similar practices are bad. A high barrier is a feature, not a bug.

[everforward]

This makes sense to me. Part of me wonders if this system wouldn't work better in reverse, a blocklist instead of a banlist. Blocklists can spread via URL, in the same way that DNS or email blocklists work. Subscribe to the blocklists of people you trust.

I _think_ this removes the motivation for low-quality PRs. Get on a major blocklist and the GitHub account is basically dead. People could make new GitHub accounts, but then you never get an "impressive" GitHub account.

[monegator]

let's make it even better: why not set up a donation mechanism to get in the list?

[nananana9]

Because I want people to get paid for writing code, not to pay to write code.

[monegator]

my bad, forgot to /s

[theredbeard]

No worries, the italics did heavy lifting.

[theredbeard]

What could go wrong?!