I get the spirit of this project is to increase safety, but if the above social contract actually becomes prevalent this seems like a net loss. It establishes an exploitable path for supply-chain attacks: attacker "proves" themselves trustworthy on any project by behaving in an entirely helpful and innocuous manner, then leverages that to gain trust in target project (possibly through multiple intermediary projects). If this sort of cross project trust ever becomes automated then any account that was ever trusted anywhere suddenly becomes an attractive target for account takeover attacks. I think a pure distrust list would be a much safer place to start.

If PR is good, maintainer refunds you ;)

I noticed the same thing in communication. Communication is now so frictionless, that almost all the communication I receive is low quality. If it cost more to communicate, the quality would increase.

But the value of low quality communication is not zero: it is actively harmful, because it eats your time.

I get that AI is creating a ton of toil to maintainers but this is not the solution.

Not sure about the trust part. Ideally, you can evaluate the change on its own.

In my experience, I immediately know whether I want to close or merge a PR within a few seconds, and the hard part is writing the response to close it such that they don't come back again with the same stuff.

(I review a lot of PRs for openpilot - https://github.com/commaai/openpilot)

This is similar to real life: if you vouch for someone (in business for example), and they scam them, your own reputation suffers. So vouching carries risk. Similarly, if you going around someone is unreliable, but people find out they actually aren't, your reputation also suffers. If vouching or denouncing become free, it will become too easy to weaponize.

Then again, if this is the case, why would you risk your own reputation to vouch for anyone anyway.

The real problem are reputation-farmers. They open hundreds of low-effort PRs on GitHub in the hope that some of them get merged. This will increase the reputation of their accounts, which they hope will help them stand out when applying for a job. So the solution would be for GitHub to implement a system to punish bad PRs. Here is my idea:

- The owner of a repo can close a PR either neutrally (e.g. an earnest but misguided effort was made), positively (a valuable contribution was made) or negatively (worthless slop)

- Depending on how the PR was closed the reputation rises or drops

- Reputation can only be raised or lowered when interacting with another repo

The last point should prevent brigading, I have to make contact with someone before he can judge me, and he can only judge me once per interaction. People could still farm reputation by making lots of quality PRs, but that's actually a good thing. The only bad way I can see this being gamed is if a bunch of buddies get together and merge each other's garbage PRs, but people can already do that sort of thing. Maybe the reputation should not be a total sum, but per project? Anyway, the idea is for there to be some negative consequences for people opening junk PRs.

If you get denounced on a popular repo and everyone "inherits" that repo as a source of trust (e.g. think email providers - Google decides you are bad, good luck).

Couple with the fact that usually new contributors take some time to find their feet.

I've only been at this game (SWE) for ~10 years so not a long time. But I can tell you my first few contributions were clumsy and perhaps would have earned my a denouncement.

I'm not sure if I would have contributed to the AWS SDK, Sendgrid, Nunit, New Relic (easily my best experience) and my attempted contribution to Npgsql (easily my worst experience) would have definitely earned me a denouncement.

Concept is good, but I would omit the concept of denouncement entirely.

For a single organisation, a list of vouched users sounds great. GitHub permissions already support this.

My concern is with the "web" part. Once you have orgs trusting the vouch lists of other orgs, you end up with the classic problems of decentralised trust:

1. The level of trust is only as high as the lax-est person in your network 2. Nobody is particularly interested in vetting new users 3. Updating trust rarely happens

There _is_ a problem with AI Slop overrunning public repositories. But WoT has failed once, we don't need to try it again.

“After we left Samble I began trying to obtain access to certain reticules,” Sammann explained. “Normally these would have been closed to me, but I thought I might be able to get in if I explained what I was doing. It took a little while for my request to be considered. The people who control these were probably searching the Reticulum to obtain corroboration for my story.”

“How would that work?” I asked.

Sammann was not happy that I’d inquired. Maybe he was tired of explaining such things to me; or maybe he still wished to preserve a little bit of respect for the Discipline that we had so flagrantly been violating. “Let’s suppose there’s a speelycaptor at the mess hall in that hellhole town where we bought snow tires.”

“Norslof,” I said.

“Whatever. This speelycaptor is there as a security measure. It sees us walking to the till to pay for our terrible food. That information goes on some reticule or other. Someone who studies the images can see that I was there on such-and-such a date with three other people. Then they can use other such techniques to figure out who those people are. One turns out to be Fraa Erasmas from Saunt Edhar. Thus the story I’m telling is corroborated.”

“Okay, but how—”

“Never mind.” Then, as if he’d grown weary of using that phrase, he caught himself short, closed his eyes for a moment, and tried again. “If you must know, they probably ran an asamocra on me.”

“Asamocra?”

“Asynchronous, symmetrically anonymized, moderated open-cry repute auction. Don’t even bother trying to parse that. The acronym is pre-Reconstitution. There hasn’t been a true asamocra for 3600 years. Instead we do other things that serve the same purpose and we call them by the old name. In most cases, it takes a few days for a provably irreversible phase transition to occur in the reputon glass—never mind—and another day after that to make sure you aren’t just being spoofed by ephemeral stochastic nucleation. The point being, I was not granted the access I wanted until recently.” He smiled and a hunk of ice fell off his whiskers and landed on the control panel of his jeejah. “I was going to say ‘until today’ but this damned day never ends.”

“Fine. I don’t really understand anything you said but maybe we can save that for later.”

“That would be good. The point is that I was trying to get information about that rocket launch you glimpsed on the speely.”*

But I like the idea and principle. OSS need this and it's traded very lightly.

Feels like making a messaging app but "how messages are delivered and to whom is left to the user to implement".

I think "who and how someone is vouched" is like 99.99% of the problem and they haven't tried to solve it so it's hard to see how much value there is here. (And tbh I doubt you really can solve this problem in a way that doesn't suck.)

Would people recommend it? I feel like I have such huge inertia for changing shells at this point that I've rarely seriously considered it.