Live data from Hacker News

Vouch

github.com

151–160 of 507 posts

Re: Vouch

#151

Users already proven to be trustworthy in one project can automatically be assumed trustworthy in another project, and so on. 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 helpfu…

It's just an example of what you can do, not a global feature that will be mandatory. If I trust someone on one of my projects, why wouldn't I want to trust them on others?

Re: Vouch

#152
post #139

It should just be $1 to submit PR. 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.

If you want me to read your comment, please pay me $1 first... if I find your comment interesting I might refund.

I had this idea / pet project once where I did exactly this for email. Emails would immediately bounce with payment link and explanation. If you paid you get credit on a ledger per email address. Only then the mail goes through.

You can also integrate it in clients by adding payment/reward claim headers.

Re: Vouch

#153
post #139

It should just be $1 to submit PR. 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.

If you want me to read your comment, please pay me $1 first... if I find your comment interesting I might refund.

The market currently values your reading of HN comments at $0.

Re: Vouch

#154
post #131

Earlier quoted context omitted.

I didn't mean the "fuck off" part to be quite verbatim... this ghostty PR[0] is a good example of how this stuff should be handled. Notably: there's no attempt to review or provide feedback--it's instantly recognized as a slop PR--and it's an instant ban from repo. This is the level of response these PRs deserve. What people shouldn't be doing is treating these as good-faith requests and trying to provide feedback or…

Sure, but that pull request is blatantly unreviewable because of how it bundles dozens of entirely unrelated commits together. Just say that and move on: it only takes a one-line comment and it informs potential contributors about what to avoid if any of them is lurking the repo.

Sounds like we're largely saying the same thing. Open source maintainers should feel empowered to say "nope, this is slop, not reading, bye" and ban you from the repo, without worrying if that seems unprofessional.

Re: Vouch

#155

Earlier quoted context omitted.

Sure, but that pull request is blatantly unreviewable because of how it bundles dozens of entirely unrelated commits together. Just say that and move on: it only takes a one-line comment and it informs potential contributors about what to avoid if any of them is lurking the repo.

One problem with giving any feedback is that it can automatically be used by an agent to make another PR.

If they immediately make another low-quality PR that's when you ban them because they're clearly behaving like a bad actor. But providing even trivial, boilerplate feedback like that is an easy way of drawing a bright line for contributors: you're not going to review contributions that are blatantly low-quality, and that's why they must refrain from trying to post raw AI slop.

Re: Vouch

#156
post #86

How does a potential positive contributor pierce through? If they are not contributing to something already and are not in the network with other contributors? They might be a SME on the subject and legit have something to bring to the table but only operated on private source. I get that AI is creating a ton of toil to maintainers but this is not the solution.

One solution is to have a screensharing call with the contributor and have them explain their patch. We have already caught a couple of scammers who were applying for a FOSS internship this way. If they have not yet submitted anything non-trivial, they could showcase personal projects in the same way. FOSS has turned into an exercise in scammer hunting.

I'm not sure if I follow, are the PRs legitimate and they are just being made to buff their resume, or are PRs malicious?

Re: Vouch

#157
I believe interviewing devs before allowing them to contribute is a good strategy for the upcoming years. Let’s treat future OS contributors the same way companies/startups do when they want to hire new devs.

Re: Vouch

#158
post #154

Earlier quoted context omitted.

Sure, but that pull request is blatantly unreviewable because of how it bundles dozens of entirely unrelated commits together. Just say that and move on: it only takes a one-line comment and it informs potential contributors about what to avoid if any of them is lurking the repo.

Sounds like we're largely saying the same thing. Open source maintainers should feel empowered to say "nope, this is slop, not reading, bye" and ban you from the repo, without worrying if that seems unprofessional.

If you explicitly say "this is unreviewable junk, kthxbye" there's nothing unprofessional about it. But just blaming "AI slop" runs into the obvious issue that most people may be quite unaware that AI will generate unreviewable junk by default, unless it's being very carefully directed by an expert user.

Re: Vouch

#159

Earlier quoted context omitted.

I'm not the parent but if you know you want to merge a PR "within a few seconds" then you're likely to be merging in bad changes. If you had left it at know you want to reject a PR within a few seconds, that'd be fine. Although with safety critical systems I'd probably want each contributor to have some experience in the field too.

Sounds like you misunderstood. They didn't say they are merging PRs after a few seconds. Just that the difference between a good one and a bad is often obvious after a few seconds. Edit: typos

Exactly, every PR starts with:

1. What’s the goal of this PR and how does it further our project’s goals?

2. Is this vaguely the correct implementation?

Evaluating those two takes a few seconds. Beyond that, yes it takes a while to review and merge even a few line diff.

Re: Vouch

#160
> The idea is based on the already successful system used by @badlogicgames in Pi. Thank you Mario.

This is from the twitter post referenced above, and he says the same thing in the ghostty issue. Can anyone link to discussion on that or elaborate?

(I briefly looked at the pi repo, and have looked around in the past but don't see any references to this vouching system.)

Post reply on HN