Opt in

[1egoman]

More detail here: backstrokeapp/server#84 (comment)

[evandrocoan]

Does this seem reasonable? Might be able to work on this this weekend if I get some time.

Yes. For me you can either disable the upstream -> forks feature, or just do this. I favor this because I would never use this feature as it is, as I already stated:

But most users should not be so patience and started flagging the bot account. Probably they have to ideia how to disable, or whether there is a documentation about, even if they know about a documentation, they will not have the patience to read it and find out what to do to stop this unknown bot. Then they will probably have not ideia why this unknown bot is annoying them so much, then they flag this bot for annoyance.

I only would favor using this feature if the implementation was like:

This feature of setup all forks to receive updates from the upstream should not automatically spread pull request through all forks. It should just also be opt-in by the fork users'. But as the fork owner has setup it, the fork users' could accept it. This could be done only by the fork users which already have a backstroke account. Then when they fork a repository which has backstroke setup, this backstroke link is added to the https://app.backstroke.co/#/links page as a disabled link. Then, they can enable it if they want to.

Currently as you planned, I ask, how would a user know whether the upstream has setup a backstroke link?

To help them, the users which already have a backstroke account, they could receive a email from backstroke with a link which they can use to enable the link if they want to. Users which do not have a backstroke account, should not receive any email. But when they create a backstroke account, they will already have these links available to be enabled, if they want to.

These quotes are from: backstrokeapp/server#84 (comment)

[1egoman]

Currently as you planned, I ask, how would a user know whether the upstream has setup a backstroke link?

I haven't gotten that far yet, but a potential solution could be to create readme badge that upstream project maintainers could add to their readme that could add the label to a fork?

I like what you've suggested (as I mentioned before) but it's not a solution that will solve the problem right now (so that backstroke-bot can be un-flagged by Github ASAP). One of the nice things about using labels is that if later someone (either me or someone with more time) is able to put together an alternative method, it should be pretty easy to migrate to another solution.

After I can get this fix deployed, let's circle back, because what you've suggested sounds like a better longer term solution.