Backstroke-bot has been flagged.

[1egoman]

Unfortunately, Github flagged the backstroke-bot user today, most likely for creating pull requests. This means that, until Github unflags the user, any pull requests backstroke creates will be invisible (I did test though, and they are created, though they aren't visible on the pull requests page of a repository)

I sent Github support a message, and hopefully they'll be able to unflag the user account.

Hello,

I am the owner of the `backstroke-bot` account. It has recently been flagged, most likely because it is a machine account. The backstroke-bot machine account helps run the service [Backstroke](https://backstroke.co), a service for keeping changes in sync between forks of popular open source projects. It's primarily maintained by me, Ryan Gaus (and my primary Github account is [here](https://github.com/1egoman) ). According to Github's terms of service, the `backstroke-bot` user follows all the guidelines for machine accounts, to the best of my knowledge ([here's the section of the terms of service that particularly mention machine accounts](https://help.github.com/articles/github-terms-of-service/#2-account-requirements).

How would I go about unflagging the my machine user?

Thanks,
Ryan

[evandrocoan]

Perhaps it was annoying too much people when repository owners setup it to sync all its forks. Then the backstroke bot app received too much flags.

These flags are a real pain in the ass when they start coming. When I want to receive updates, I just create a link from my fork to the upstream, I do not expect to the updates coming from the upstream to my forks automatically without I asking it to. I know I can disable, and when I found it, I disable.

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.

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.

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.

[1egoman]

Yep, I figured that might be the case. I ran into this issue way back when I started backstroke, and I added a link to the project's readme to a document detailing how to disable backstroke on a fork: https://github.com/backstrokeapp/server/blob/master/disable-on-a-fork.md

Maybe it's worth putting that link in the pull requests that Backstroke generates?

What you've layed out sounds like a good plan, but is going to require a lot of work to get to that point. Also - and I don't know if this is a valid point - but I suspect (and the analytics back this up) many people that hear about backstroke learn about it through pull requests being made on their repositories. Not to say that marketing should be prioritized over user experience at all, but it's something to consider.

I'm interested to hear how the github folks respond. I'll add a link to the pull request that the backstroke-bot user creates to make it easy to opt out in the future.

[TonyBenedetti]

I'm new to Backstroke and was very pleased by how well it worked. Today when it apparently didn't generate any PRs from the upstream Fabrik/fabrik repo, I figured the server was down an would be back soon. So I tried to pick up the latest commits "manually" through GitHub. But GitHub presented me with this nastygram: "Pull request creation failed. Validation failed: A pull request already exists for Fabrik:master".

So it seems(?) that in addition to being "invisible", the Backstroke generated PRs are clogging the pipes. Let's hope your request to the GitHub folks to take down the flags will get the flow working again.

 Tony Benedetti

[1egoman]

As I probably should have expected, it sounds like someone reported the backstroke-bot user as creating spam. As a response to this, Github wants me to make Backstroke opt-in before they'll reenable the backstroke-bot user.

I'm thinking the easiest way to do this might be to invert how opting out works right now: maybe have an opt-in tag you add to a repository if it's the fork of a project that has backstroke enabled? I think the issue here (from my understanding) is when syncing occurs from upstream => all forks, so syncing from upstream => single fork probably shouldn't be an issue, because the person creating the Backstroke link needs to have permissions to write to the fork repo in order to create the link.

So, the new flow for syncing to all forks of an upstream becomes:

• Get all forks of a repository
• Loop through each, looking for some sort of identifier that makes it known that this repository should receive PRs.
• Create pull requests on only those repositories.

Syncing from an upstream to a single fork stays the same, since adding the link acts as a form of opting in (you need to own the fork).

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

[TonyBenedetti]

In the mean time, does anyone have any advice about how I can clear out the "invisible" PRs that are (apparently?) "clogging the pipes" and preventing me from getting commits from the upstream public repo?

[evandrocoan]

1. You can clone your fork on your computer
2. Run git add remote upstream https://github.com/user/repo
3. Run git fetch upstream
4. Run git merge upstream/master

[1egoman]

@TonyBenedetti You also might be able to close those PRs via the github api - I was able to still retrieve details about some backstroke pull requests vis the api even though the backstroke-bot user was flagged.

I'm sorry for the inconvenience - working on a solution that will hopefully go live at some point over the weekend, and if not, this upcoming week. Once this is live Github support should be able to unflag the backstroke-bot user.

[TonyBenedetti]

Thanks, @evandrocoan & @1egoman. I had other issues (not connected to Backstroke in any way) with the way I had set up my repo and with my workflow. I took the opportunity presented by this Backstroke hiatus to blow away and then rewicker my repo. The "invisible" PRs naturally completely disappeared and the new pipes were thus totally clear.

Be assured that I will return to Backstroke as soon as I hear the "all clear" siren.

[1egoman]

@TonyBenedetti backstroke-bot has been unflagged by github support, and is posting pull requests to users again. You should be all clear! Thanks for being patient.

@evandrocoan Can you open an issue detailing the idea you had for implementing a better solution to this issue (the plan is for the fix that's in place to only be temporary)? It seems like a good idea but I want to discuss it / let others take a look at it if they so wish before working on it.