7 ms·

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 wh

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.

Too 14y ago
Why hellban? What's wrong with a normal ban?
- sneak 14y ago
  Because then they'll know they need to use a different proxy and change the bot behavior to avoid detection.
  - Too 14y ago
    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 -.-
jamespo 14y ago
Banning them and establishing services solves the problem for everyone but the bot developer as far as I can tell...
thwarted 14y ago
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.
- zem 14y ago
  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.
  - thwarted 14y ago
    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.
    - zem 14y ago
      white listing individual bots is not low-friction. ideally i want the bots to discover me, not vice versa.
      - thwarted 14y ago
        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.
X-Istence 14y ago
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 https://github.com/cobyism/Filefile
- Evbn 14y ago
  Someone should wrote a bot to submit pull requests with these metafiles.
kreeger 14y ago
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).
FuzzyDunlop 14y ago
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.
- dbaupp 14y ago
  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").
jlarocco 14y ago
> 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.

Too 14y ago

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

sneak 14y ago
Because then they'll know they need to use a different proxy and change the bot behavior to avoid detection.
- Too 14y ago
  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 -.-

jamespo 14y ago

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

thwarted 14y ago

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.

zem 14y ago
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.
- thwarted 14y ago
  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.
  - zem 14y ago
    white listing individual bots is not low-friction. ideally i want the bots to discover me, not vice versa.
    - thwarted 14y ago
      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.

X-Istence 14y ago

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 https://github.com/cobyism/Filefile

Evbn 14y ago
Someone should wrote a bot to submit pull requests with these metafiles.

kreeger 14y ago

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

FuzzyDunlop 14y ago

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.

dbaupp 14y ago
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").

jlarocco 14y ago

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