Earlier quoted context omitted.
When there's time, you review, when there isn't you trust...
What's the rush? Building good things takes time.
deadlines, money, attention. The usual things in industry.
Vouch
391–400 of 507 posts
Re: Vouch
#392Earlier quoted context omitted.
Per the readme: > Unfortunately, the landscape has changed particularly with the advent of AI tools that allow people to trivially create plausible-looking but extremely low-quality contributions with little to no true understanding. Contributors can no longer be trusted based on the minimal barrier to entry to simply submit a change... So, let's move to an explicit trust model where trusted individuals can vouch for…
I suspect a good start might be engaging with the project and discussing the planned contribution before sending a 100kLOC AI pull request. Essentially some signal that the contributor intends to be a responsible AI driver not just a proxy for unverified garbage code.
That's the most difficult part oftentimes. People are busy and trying to join these conversations as someone green is hard unless you already have specifically domain knowledge to seek (which requires either a job doing that specific stuff or other FOSS contributions to point to).
Re: Vouch
#393Unfortunately, the mob mentality, and gate keeping from the Reddit mod era, proves that these types of systems simply don’t work.
Yeah, these solutions are always made to try and disract from the fact that you need real, admin-level moderation and enfoecement to build trustworthy users and communities. a rogue actor should be afraid of losing their account if they submit slop. But instead all this is outsourced on the community to try and circumnavigate.
Community level enforcement is unfortunately a game of cat and mouse. except the mouse commands an army and you can only catch one mouse per repo. The most effective solution is obviously to ban the commander, but you'll never reach it as a user.
Re: Vouch
#394What's the plan to avoid a Bluesky-like bubble from forming around Vouch projects? Say what you want about wanting to avoid politically disagreeable people, but Bluesky has been shrinking gradually since the 2024 election, as people interested in political effectiveness or even avoiding a hugbox have drifted away. Or think about how new projects are generally not started as GPL anymore (except if they want to charge…
>What's the plan to avoid a Bluesky-like bubble from forming around Vouch projects? I don't really see the issue, 'bubble', is a buzzword for what we used to call a community. You want to shrink viral online platforms to health, which is to say to a sustainable size of trusted and high quality contributors. Unqualified growth is the logic of both cancer and for-profit social media platforms, not of a functioning comm…
I've been on Mastodon, in leftist spaces theoretically ideologically aligned with me (I've since drifted more...)
It was horrible. Being on Mastodon was one of the most corrosive, humorless, joyless, anxiety and guilt inducing experiences I've ever had.
Re: Vouch
#395It 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.
> It should just be $1 to submit PR.
This, but for an escrow so people can show their actual interest in GitHub Issues, instead of just demanding new features or fixes. So if it gets implemented, the devs get the bounty, if not then they're refunded. I sometimes think about how this could help fund open source at least a little bit.
No comment on making PRs paid, not everyone would react well to that, and some people might be in countries and circumstances where any amount would be problematic.
Re: Vouch
#396Prior art? https://en.wikipedia.org/wiki/Advogato
> the purpose of the trust metric is to certify that a given user account on Advogato is known by the Advogato community to actually belong to the individual who claims it and is known to be a member of the free software and open source community. The user may be an crank, annoying, or of a political persuasion that you don't agree with. What the trust metric attempts to guarantee is that they really are who they say they are
Sounds like a slightly different goal but certainly an interesting system to look at
Re: Vouch
#397Why stop at restricting pull requests? I wouldn't want spam issues either. New issues and contributors should be gated at the "discussion" stage.
Re: Vouch
#398Earlier quoted context omitted.
I am still not going to merge random code from a supposed trusted invdividual. As it is now, everyone is supposedly trusted enough to be able to contribute code. This vouching system will make me want to spend more time, not less, when contributing.
I think something people are missing here is, this is a response to the groundswell in vibecoded slop PRs. The point of the vouch system is not to blindly merge code from trusted individuals; it's to completely ignore code from untrusted individuals, permitting you to spend more time reviewing the MRs which remain.
Would it not be better to report accounts then?
Re: Vouch
#399I've thought about making such a system before, but never considered making it a single flat file¹. How are you going to identify who keeps inviting these bad actors?
Assuming the list is under source control, the commit history can answer this question but it's manual work whereas a tree/graph system shows you directly who is making the bad judgement calls (may be intentional or not, so this person can keep contributing so long as those contribs are good, but not invite further people). I don't understand the added value of a bunch of software around what is essentially an allowlist where the commit history already shows why someone was added or removed
¹ https://github.com/mitchellh/vouch?tab=readme-ov-file#vouche...
Re: Vouch
#400It 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.
> It should just be $1 to submit PR. This, but for an escrow so people can show their actual interest in GitHub Issues, instead of just demanding new features or fixes. So if it gets implemented, the devs get the bounty, if not then they're refunded. I sometimes think about how this could help fund open source at least a little bit. No comment on making PRs paid, not everyone would react well to that, and some people…
pay-to-commit has been discussed in the article linked here
https://news.ycombinator.com/item?id=46938811
escrow is a more complex system, and there are multiple possible implementations, but the nice thing is you can skip it and get the same results.
let's assume for a second that the repo owner spends time on PR review, and that time needs to be reimbursed. let's also assume that the person pushing a PR expects some sort of bounty. then as long as the review price is less than bounty price, there's no need for escrow. the pushing party goes out on a limb paying the reviewer to merge their PR, but also expects (rightly or not) to be remunerated for solving the bounty. whether they really did solve it is in the remit of the bounty originator, who might or might not be part of the group controlling the repository. if there's escrow, then the bounty giver probably has to be part of that group. not having escrow allows for crowd funding by interests outside of the repo controlling party.
escrow is only usefully different in a situation when there is no bounty, you want to push code, and then you want to say "ok, here's some money, and here's a PR, either accept the PR and give me money or don't accept it and take my money" as a means of skipping the line or getting a shot at pushing in the first place. however, at that point two things are apparent: 1. you expect the reviewer to do work required to implement your desired changes for free and 2. this might start getting abused, with PRs getting rejected (to gain money) but then modified / refactored versions of this code being pushed via commits or from another user who is the repo owner's puppet (refactoring code is becoming super cheap due to AI). so that degenerates escrow-to-push into a scam.
there are more considerations like that in the article I linked to. I agree that an economy around FOSS pushing would be desirable. it also doesn't preclude free-as-in-money contributions - there are at least two mechanisms that would allow it: 1. you get sponsored by someone who sees your talent (either gives you money to push, or they have push access to that repo and can hand it out free) 2. you create a fork that becomes so good and valuable that upstream pulls from you for free
ultimately becoming a respected developer with free push access to contended repositories should be something that you can monetize to some extent that's purely within your remit, and it would greatly reduce unserious bullshit coming from third parties (especially all those weird hardware developers) and make it easier to be a FOSS dev.