[ColinWright]

Thanks for the reply, but if your CI[0] server does passes reasonably often, why would one of them not happening then prevent you from continuing to work? It runs in passes, so it's not really continuous, and I'd expect it to survive running slightly less often, or slightly more irregularly.

Do you stop work when it runs? I don't understand your workflow that implies you have to stop while a process that runs often fails to run on one occasion.

I remain confused.

[0] I assume this is "Continuous Integration"

[scott_s]

I think the idea is that they just so happened to at a point in their workflow when they needed GitHub to be up. For some reason, wakeless needed to know the results of the CI server. There aren't many such points for people, but if you have a large enough sample of people, some of them will be at such points at any given moment of time.

[ColinWright]

Thanks for your reply - it's a useful data point for me. However ...

What I think I'm repeatedly asking, and what I think I'm not being told, is what there is in their workflow that requires github to be up at a given moment.

Here I am, working on some code, or working on some documentation. I'm using my local repo, and I decide that it would be a good idea to push to the shared repo on github.

Oh, it's down.

Never mind, I'll carry on with the next bug-to-fix/feature-to-add.

What is it that people are doing that requires github to be up, otherwise at that moment they can't work and have to wait?

I feel like I'm asking a question that makes sense to me, and yet people are staring back blankly, unable to comprehend the question. Perhaps my understanding of people's use of github is so radically wrong that my question is based on total misconceptions of everything.

I don't know. I'm trying to find out. I'm getting downvoted.

Pretty soon I'll go away without having learned something from the people who clearly have the knowledge, but can't understand my ignorance.

I wonder if this is born of the fact that I always arrange my workflow so as not to require any external services at any specific time. In part, this is a result of getting into computing at a time when remote services were inherently unstable. Perhaps times have changed enough that people assume remote services will always be up, and then when they aren't, everything has to stop, because their workflow is predicated on availability.

This is like programming an API querying system that just assumes the remote server won't hang. Enough of the time it's true to make it not worth worrying about. I wonder if I'm just from a culture that's so foreign, no one knows where to being in explaining the modern world to me.

[derefr]

How do you carry on to the next bug-to-fix/feature-to-add when you're using Github Issues as your bug tracker? Or what if all you've got on your plate for the day is "review and merge everyone's pull requests to create our next release candidate build?" Or, even ignoring Github's extra features, what if you need to integrate a new prototype-stage third-party library, which is hosted on Github?

Or, to be less charitable, and to assume some incompetence on someone's part (though not necessarily the developer doing the work)--what if you're trying to use bundle/npm install to set up a working environment for one of your codebases, but one of the dependencies is listed as a git ref of a repo hosted on Github?

And honestly, this is all assuming you would "just move on to the next [whatever]." Most people will take any excuse to procrastinate. :)