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…
Vouch
151–160 of 507 posts
Re: Vouch
#152It 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.
You can also integrate it in clients by adding payment/reward claim headers.
Re: Vouch
#153It 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.
Re: Vouch
#154Earlier 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.
Re: Vouch
#155Earlier 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.
Re: Vouch
#156How 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.
Re: Vouch
#157Re: Vouch
#158Earlier 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.
Re: Vouch
#159Earlier 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
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
#160This 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.)