Live data from Hacker News

Vouch

github.com

161–170 of 507 posts

Re: Vouch

#161
post #113

"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…

When there's time, you review, when there isn't you trust...

What's the rush? Building good things takes time.

Re: Vouch

#162
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…

> 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.

GitHub customers really are willing to do anything besides coming to terms with the reality confronting them: that it might be GitHub (and the GitHub community/userbase) that's the problem.

To the point that they'll wax openly about the whole reason to stay with GitHub over modern alternatives is because of the community, and then turn around and implement and/or ally themselves with stuff like Vouch: A Contributor Management System explicitly designed to keep the unwashed masses away.

Just set up a Bugzilla instance and a cgit frontend to a push-over-ssh server already, geez.

Re: Vouch

#163
post #142

Illegal in europe. You are bot allowed to keep a black list of people with the exception of some criminal situations or addiction.

Can you cite the law that says you may not do this? There are obvious cases in Europe (well, were if you mean the EU) where there need not be criminal behaviour to maintain a list of people that no landlord in a town will allow into their pubs, for example.

Under the EU’s GDPR, any processing of personal data (name, contact, identifiers, etc.) generally requires a legal basis (e.g., consent, legitimate interest, contractual necessity), clear purpose, minimal data, and appropriate protection. Doing so without a lawful basis is unlawful.

It is not a cookie banner law. The american seems to keep forgetting that it's about personal data, consent, and the ability to take it down. The sharing of said data is particularly restricted.

And of course, this applies to black list, including for fraud.

Regulators have enforced this in practice. For example in the Netherlands, the tax authority was fined for operating a “fraud blacklist” without a statutory basis, i.e., illegal processing under GDPR: https://www.autoriteitpersoonsgegevens.nl/en/current/tax-adm...

The fact is many such lists exist without being punished. Your landlord list for example. That doesn't make it legal, just no shutdown yet.

Because there is no legal basis for it, unless people have committed, again, an illegal act (such as destroying the pub property). Also it's quite difficult to have people accept to be on a black list. And once they are, they can ask for their data to be taken down, which you cannot refuse.

Re: Vouch

#164

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.

This adds friction, disincentivizes legitimate and high quality code commits and uses humans even more.

Re: Vouch

#165
post #146

Earlier quoted context omitted.

> Then again, if this is the case, why would you risk your own reputation to vouch for anyone anyway. Good reason to be careful. Maybe there's a bit of an upside to: if you vouch for someone who does good work, then you get a little boost too. It's how personal relationships work anyway. ---------- I'm pretty skeptical of all things cryptocurrency, but I've wondered if something like this would be an actually good us…

Sounds like a black mirror episode.

isnt that like literally the plot in one of the episodes? where they get a x out of 5 rating that is always visble.

Re: Vouch

#166

"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…

Cool to see you here on HN! I just discovered the openpilot repository a few days ago and am having a great time digging through the codebase to learn how it all works. Msgq/cereal, Params, visionipc, the whole log message system in general. Some very interesting stuff in there.

Re: Vouch

#167
post #113

Earlier quoted context omitted.

When there's time, you review, when there isn't you trust...

That's the issue here. Even if I trust you, I still need to review your work before merging it. Good people still make mistakes.

What is the definition of trust if you still have to verify? How does "trust" differ from "untrust" in that scenario?

Re: Vouch

#168

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

I'm not sure there are many ways to interpret "I know whether I want to merge a PR within a few seconds".

Re: Vouch

#169
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…

> 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. GitHub customers really are willing to do anything besides coming to terms with the reality…

I mean, "everyone already has an account" is already a very good reason. That doesn't mean "I automatically accept contributions from everyone", it might be "I want to make the process of contribution as easy as possible for the people I want as contributors".

Re: Vouch

#170
Ah, we have converted a technical problem into a social problem. Historically those are vastly easier to solve, right?

Spam filters exist. Why do we need to bring politics into it? Reminds me of the whole CoC mess a few years back.

Every time somebody talks about a new AI thing the lament here goes:

> BUT THINK OF THE JUNIORS!

How do you expect this system to treat juniors? How do your juniors ever gain experience committing to open source? who vouches for them?

This is a permanent social structure for a transient technical problem.

Post reply on HN