Hacker News Reader

Comment by briandoll | Hacker News Reader

I'm quoted in the article and I wanted to clear one thing up that was missing from it.

When bots get reported to us by people using GitHub our support folks reach out to the bot account owner and encourage them to build a GitHub service[1] instead. As a service, the same functionality would still be available to everyone using GitHub, but it would be opt-in instead.

A few months ago we heard from some developers of service integrations that beyond the existing API features, it would be handy to be able to provide a form of "status" for commits. We added the commit status API [2] in September to accommodate that. We're always open to feedback on how the API and service integrations can improve.

The point is, GitHub services are a much better way to build integrations on GitHub.

[1] https://github.com/github/github-services [2] https://github.com/blog/1227-commit-status-api

View on HN

Well, devs are always going to create bots. They're a fact of life.

Why not establish an opt-out convention similar to robots.txt? The idea is that people who want to opt-out would create a ".robots" file in their repo, with "none" in it. Any bot that doesn't respect the .robots file is hellbanned.

The problem with opt-in is that people won't use it unless they (a) know it's available, (b) know how to get it, and (c) actually go get it. So people don't really do that. But establishing an opt-out convention like this solves the problem entirely, and it's simple.

Why hellban? What's wrong with a normal ban?

Because then they'll know they need to use a different proxy and change the bot behavior to avoid detection.

What if you accidentally added a bug in your bot? What if the policy-guard has a bug? What if there's changed robots-policies you didn't have time to keep up with? What if there's an admin with a personal vendetta against some bot? (the three first bullets also show why opt-out is a bad idea, over opt-in)

You don't think it would be appropriate to warn the bot-owner about this first? Hellbanning must always be a last resort, not something you throw around as standard procedure for even the smallest misdemeanours.

The recent spread of hellbanning on internet forums really is a plague. I've been hellbanned on several sites for no obvious reason at all. On reddit for example it was because their spam-bot detected that i posted two posts containing the same link within too short time -.-

Banning them and establishing services solves the problem for everyone but the bot developer as far as I can tell...

Opt-out sucks because you are forced to deal with it. Opt-in makes the most sense because there are no hurdles to jump in order to not be bothered.

If no one finds or wants to use your service without it being forced on them, it can not be that great of a service.

you could have a single opt-in to bots-as-a-whole (as a github account setting rather than per-repo), and then blacklist individual bots if they end up being spammy. that seems like a nice balance between "do nothing by default" and frictionless adoption of the feature.

While this is a fine idea, why can't that be "opt-out to bots -as-a-whole (as a github account setting rather than per-repo), and then whitelist individual bots if you want to find out if they provide some utility"? That seems like the proper balance between "do nothing by default" and the lest friction required to use bots without requiring those who don't want to be involved at all needing to do anything?

If it's about discovery of bots, then come up with some meaningful way to make them discoverable (presumably better than the Apple App Store zing) without people needing to be exposed to them by default.

white listing individual bots is not low-friction. ideally i want the bots to discover me, not vice versa.

You do, but no one else does.

How about a header in email that the sender can include that forces the email to the top of your inbox and makes it undeleteable? You can opt-out by having an email address of user+optout@example.com all the time.

You do, but no one else does.

How small-minded. There are many of us who want to be discovered by bots. We just keep quiet because people like you have such strong opinions and aren't afraid to be mean about them.

Wouldn't it be ironic if your opinion was in the minority?

Yes, I want bots too.

The people who want opt-in are not the bad guys here, and neither are the people who want opt-out. The bad guys are those who poisoned the well, tragedy of the commons, by abusing the system. Unfortunately, there is a greater chance of abuse than there is utility, and it's more difficult for everyone to manage opt-out on an individual occurrence basis than it is to manage opt-in centrally by trying to ban bots across the board. And neither are that actually that successful, despite there having been individual successes in some communities.

Reddit's user made bots are an awesome addition and I'm very glad they are not opt-in.

I think there is room in every community for automated users, if the tools for managing misbehaving users is strong enough. Github however has been known to not have strong moderation tools, so perhaps a temporary opt-in policy could be used until those tools improve?

I'd prefer opt-in, and a nice directory of robots you could essentially subscribe to. I did a little thinking about this a while ago when the Gunio robot was annoying some people about whitespace:

https://github.com/hartez/vcs-robots

I don't want to create yet another file in my repo. I'm already plenty happy with a .gitignore and a Makefile/SConstruct file for my C projects, and a setup.py + associated files for my Python projects.

This "add a file to your repo" is starting to get annoying, there is even a project for it, called Filefile[1].

[1]: https://github.com/cobyism/Filefile

Someone should wrote a bot to submit pull requests with these metafiles.

I'm with thwarted on this one. I don't want to put my repo on a service where I have to opt-out of things based on extraneous files in my repo. That's extra clutter in my repo for something that could easily be handled in other ways (not to mention the fact that repos would be opted-in by default).

I don't like this, because then it means I have to change my repo to make a Github feature work, when Github has whole configuration UIs on their site for both my account and my repos.

Also I don't see the problem with opt-in. If your bot/plugin/service is worth its salt you'll be putting some effort into marketing it (which includes explaining how to use it).

The alternative is Github marketing the opt-out, which seems a bit strange if they're launching a feature and advising users how to not use it so they don't get spammed.

One could regard it as the first implementation of a robots.txt-like standard for public code: the existence/contents of .robots in a repo/directory implies that the owner wants control over the type of mechanical contributions received, no matter where the code is hosted.

It could be opt-in (initially at least), i.e. a .robots with contents "all", "typo" or "whitespace" etc would allow bots of the given type (an empty or missing file would imply "none").

> The problem with opt-in is that people won't use it unless they (a) know it's available, (b) know how to get it, and (c) actually go get it. So people don't really do that. But establishing an opt-out convention like this solves the problem entirely, and it's simple.

I don't see any of those things as "problems". IMO, it should be opt-in, on a per-project basis. There could be another checkbox in each project's "Settings" tab. The default should be that people are left alone.

Reply on news.ycombinator.com