Live data from Hacker News

Vouch

github.com

71–80 of 507 posts

Re: Vouch

#71
post #67

Not sure about this one. I understand the need and the idea behind it is well-intentioned, but I can easily see denouncelists turn into a weapon against wrongthinkers. Said something double-plus-ungood on Twitter? Denounced. Accepted contribution from someone on a prominent denouncelist? Denouced. Not that it was not possible to create such lists before, but it was all informal. The real problem are reputation-farmer…

GitHub needs to implement eBay-like feedback for contributors. With not only reputation scores, but explanatory comments like "AAAAAAAAAAAAAA++++++++++++ VERY GOOD CONTRIBUTIONS AND EASY TO WORK WITH. WOULD DEFINITELY MERGE THEIR WORK AGAIN!"

Re: Vouch

#73
post #60

Initially I liked the idea, but the more I think about it the more this feels like it just boils down to: only allow contributions from a list of trusted people.

This makes a lot more sense for large scale and high profile projects, and it eliminates low quality slop PRs by default with the contributors having to earn the trust of the core maintainers to contribute directly to the project.

Re: Vouch

#74

"Open source has always worked on a system of trust and verify" 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/o…

[flagged]

Re: Vouch

#76
I think denouncing is an incredibly bad idea especially as the foundation of VOUCH seems to be web of trust.

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.

Re: Vouch

#77
post #52
post #42

Isn't it extremely difficult problem? It's very easy to game, vouch 1 entity that will invite lots of bad actors

The usual way of solving this is to make the voucher responsible as well if any bad actor is banned. That adds a layer of stake in the game.

That's putting weight on the other end of the scale. Why would you want to stake your reputation on an internet stranger based on a few PRs?

Re: Vouch

#78
post #52

Earlier quoted context omitted.

The usual way of solving this is to make the voucher responsible as well if any bad actor is banned. That adds a layer of stake in the game.

A practical example of this can be seen in lobsters invite system, where if too many of the invitee accounts post spam, the inviter is also banned.

I think this is the inevitable reality for future FOSS. Github will be degraded, but any real development will be moved behind closed doors and invite only walls.

Re: Vouch

#79
This makes sense for large-scale and widely used projects such as Ghostty.

It also addresses the issue in tolerating unchecked or seemingly plausible slop PRs from outside contributors from ever getting merged in easily. By default, they are all untrusted.

Now this social issue has been made worse by vibe-coded PRs; and untrusted outside contributors should instead earn their access to be 'vouched' by the core maintainers rather than them allowing a wild west of slop PRs.

A great deal.

Re: Vouch

#80
post #74

"Open source has always worked on a system of trust and verify" 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/o…

[flagged]

What kind of things would you like to hear? The default is you hear nothing. Most black boxes work this way. And you similarly have no say in the matter.
Post reply on HN