Organizations can now block abusive users | Hacker News Reader

Organizations can now block abusive users

github.com

75 pointsmparlane47 comments

"Organization owners now have the ability to block abusive users from public repositories. This feature allows project owners to block users, and prevents blocked users from opening or commenting on issues or pull requests, forking repositories, and adding or editing wiki pages."

I get blocking users from opening/commenting/sending PRs/editing the wiki, but why block them from forking a public project?

That seems very, very dangerous to me. I think GitHub needs to preserve the ability for anyone to fork a project.

That bothers me, too. This could be used to prevent forking.

They're not blocked from logging out and cloning the project, just from hosting it on GitHub as a "fork" linked back to the original project.

Yes, but why?

So people can pretend the "abusive" user (e.g. ones posting "harmful emojis") doesn't exist.

It's a mindset, I think. See, for instance, this woman complaining about News Genius[1], discussed here [2]. At one point, she's upset that a blocked Twitter user can see her public tweets.

People should be able to moderate and exclude people. It's just funny how powerful they think that capability should be.

1: https://ellacydawson.wordpress.com/2016/03/25/how-news-geniu... 2: https://news.ycombinator.com/item?id=11404640

Probably because the only technical advantage to the "fork" button is that it tells all sorts of GitHub social-coding backend things (pull requests, the network graph, etc.) that the two repositories are related, and it is exactly those things that you'd want to block. If I were in their shoes as an engineer, I'd probably decide that it's more reliable to just disable the fork feature entirely, than to go through everything that fork does and disable it. (I'd consider implementing a second "fork" codepath that just does the equivalent of git clone && git push, and silently replacing the regular fork button with the fake-fork button instead of disabling it, but chances are I'd probably find this lower-priority than other work.)

Blocks from users to other users (which have been around just about forever) work the same way.

Because you don't want a MikeeUSA dragging your project's name through the muck and mire.

If you don't want people to be able to use your work how they wish, don't license it as free software. Or trademark the name if the naming is an issue. Blocking someone from being able to use your code is anti-software-freedom and goes against the spirit of the licenses most likely used by 99% of github repositories.

The post isn't totally clear, so I can understand how people are misreading this. But "prevents blocked users from ... forking repositories" refers to the GitHub "fork" button, not to the ability to e.g. run `git clone` from the command line.

This isn't about blocking people from being able to use software (which both goes against the letter and the spirit of free software licenses); it's about blocking people from being able to interact with the maintainers. We've had that since the days of Usenet killfiles and IRC klines.

They're not blocked from using it, they're just blocked from associating their use with you.

Would be great to have some transparency, perhaps a "# of users banned in this repo". That'd be one way to see where the balance of "abuse" lies, with the repo/org or the contributors. In other words, another indicator for health of the community, just like # of stars, forks, contributors, and watchers.

Giving a number of banned users is something that, counterintuitively, is very abuseable. Someone with an axe to grind could pretty easily create a bunch of sockpuppet accounts with the sheer purpose of getting accounts banned and that number inflated, thus giving an appearance of a community being unwelcome.

It seems like more of an indicator of whether the project was involved in some sort of controversy. I don't think you can say anything about a "balance of abuse" just based on the number of users banned.

> This feature allows project owners to block users, and prevents blocked users from(...) forking repositories ...

People here don't get that some organisations and individuals will use it to push block lists, unrelated to any Github activity, and depending on your actions on Twitter, Facebook G+ or whatever you'll be blocked in advance from forking, contributing, interacting with a large range or repositories ... same as Twitter Block lists ...

I get it that you may want to block certain people from bringing negativity to the community (via comments, issues, etc.), but how does preventing them from forking repositories help? It sounds anti-opensource.

Probably to prevent them from doing bad things to the fork graph (eg. Abusive or inflammatory commit messages would come to mind).

Then just hide their part of the graph?

That's what it does.

Why not just make the feature NOT remove the button, but simply hide their fork from the graph? Seems rather simple to implement, and a lot more in the 'spirit' of open source.

You can always run `git clone`, make a new repo, and run `git push`.

Also, this feature already existed for individual accounts, for years, and worked that way. I haven't heard of blocklists for GitHub ever existing. Why do you think this is different for organizations?

If a project on Github blocks you for something you said on Twitter, why do you want to contribute to that project anyway?

Good projects can be infiltrated by overzealous politickers. The @freebsdgirl debacle is a particularly good example of this, as she was also responsible for a certain block bot.

And why not? A project is a project, and some twat who happens to have the keys to the Twitter account of that project should not define how you should feel about a community.

I could see this being both a blessing and a curse.

On the one hand, it's easy to see how this is a powerful tool respectful developers can use to moderate their community positively.

But from the other, I've heard a few too many stories along the lines of "passionate contributor breaks into argument with passionate repo owner" and chaos ensues. I could see feature a way for people to step on toes and divide rather than encourage positive community.

I think a better long-term solution for the problem you describe is community norms around shared maintenance, where a passionate repo owner can step back and ask other repo owners to moderate and cool down the discussion, or a passionate contributor can ask other people with authority in the project to step in and intervene, either just with words or with semi-binding decisions.

This has a fairly long history in the F/OSS community, partly out of necessity before tools like GitHub existed. If your project is owned by some organization like Apache instead of by you personally, you still get to be a maintainer, but there are well-defined procedures for you not being the only maintainer. And one of the primary benefits of Linux distros is that it essentially forces a moderator (the distro packager) between users and the upstream maintainer, who can step in and choose to side with the user or the maintainer (or neither!) if there's a contentious discussion. Again, taking Linux distros as an example, all the major distros have some form of appellate group of developers -- Debian's technical committee, Fedora's steering committee, etc. -- who are encouraged to moderate important and difficult discussions, and empowered to overrule package maintainers if it ever becomes necessary.

Preventing the repo owner from having the block tool wouldn't force them to come to an agreement with the contributor. They'd either keep yelling, use the (existing) close-and-lock-conversation button, ignore the contributor, or give up and get frustrated and burn out. I think it would be better to encourage social norms that allow handling these disagreements productively (and expecting that acrimonious disagreements will probably happen at some point,) than to expect to solve this by limiting technical tools.

By the way, note that blocking users is a feature that already exists for individual accounts. Extending it to organizations makes it ever-so-slightly easier for those norms to grow, by removing essentially the only disadvantage of maintaining your project in an organization instead of in your personal account.

GitHub is severely lacking in moderation tools, this is a good move.

I assume existing forks will still remain in the blocked users account but will no longer appear in the fork graph.

Censorship now moves to source code revision control. Regardless of the good intentions, this make me queasy.

This is not at all censorship. Daily reminder: https://xkcd.com/1357/

This comment seems to be a misconception regarding a misconception: the cited xkcd addresses Freedom of Speech, not censorship. Censorship can be applied by any medium owner. E.g. if Y Combinator deletes comments or articles on Hacker News regarding a certain topic or from a specific user, without being or acquiescing to a government organization, it may still be reasonably said that they are censoring that topic or user.

https://en.wikipedia.org/wiki/Censorship

The cited xkcd also does not do a good job of addressing freedom of speech. Many writers have used "free of speech" to refer to a broad social and cultural principle, not merely a legal doctrine, and defended it on grounds that apply just as much against private censorship and social ostracism as much as against government censorship. The idea that free speech is a concept that is applicable only to government restrictions is of fairly recent vintage, and historically was most used by libertarians rather than the progressives who more often promote it now. In summary, John Stuart Mill had much clearer and sounder ideas about free speech than Randall Munroe.

The comic doesn't actually address freedom of speech, it addresses the First Amendment of the United States Constitution (and conflates it with free speech). The first is an amendment to a contract between the people of the United States and the government of the United States and the second is a philosophical principle. The concept of Free Speech did not start with the United States constitution and any reference to the First Amendment when referencing Free Speech kind of misses the point.

Cryptofascism: so hot right now.

Does it also make you queasy that the person in charge of a project has the ability to approve or deny pull requests? Is that also a form of censorship? I don't see this being much more than the typical administrative control someone would have over a collaborative project or account.

How is denying a pull request the same as banning someone from forking your project? Don't you see undue power bestowed on some people here?

It's OK for admins to deny pull requests, but not OK for them to deny the right to fork the said open source project. Kind of takes the open out of the open source by doing so.

They can fork it, they just have been disinvited from using github's fork button to do so. There's nothing blocking them from downloading the source, etc.

No, because that only applies to forking a project within the Github UI. Nothing is stopping anyone from cloning a project and pushing it to their repository.

It's an administrative detail. Just use the HTTPS end point. That requires no auth for read-only access to public repos.

Read another way, abusive organizations and project maintainers can now block users.

That seems like a good thing. If an organization or project maintainer is going to be abusive towards me, I'd rather know that at the outset, than spend time writing a good pull request or issue and then deal with the hostility. I'd certainly rather know that at the outset than put the project in production, become tied to it, and then realize that I'm unable to contribute to it productively.

If they block me preemptively, I can decide to investigate alternative projects to invest time into, or perhaps I can decide to fork the project (any free software or Open Source license requires non-discrimination in licensees), git push it to my own account, and attempt to run a non-abusive community around it. Or perhaps I can decide to reimplement it myself.

That seems like a self-correcting problem.

It's a marketplace of ideas, no? Talent will generally avoid abuse...

I wonder where that rug ever ended up.

I think a better counterargument is that open source allows forking - if there's a problem with a community you can just make a community around an existing codebase.

YAY!!! CENSORSHIP MADE EASY!!!

It's a bit ironic that I've been 'down voted' for a sarcastic comment about censorship...

Reply on news.ycombinator.com