I would guess that it's just the digital version of the internet going down at work, and everyone hanging out in the office kitchen talking about how the internet is down, until it goes back up.
In other words, if you're waiting for [service] to come up in order to get something done, there's not much better to do.
> if you're waiting for [service] to come up in order
> to get something done, there's not much better to do.
I don't understand this - it's a distributed document control system. You can continue to work on your local repo - why is it that you can get nothing done? Perhaps I just don't understand your workflow, but why is github the site essential to your progress?
It would be useful to me if someone could explain how their workflow requires github to be available, because it would seem that they are using facilities or features of which I am unaware.
Today it went down, just as I needed our CI server to do a pass. Which is fine, grab a coffee, then I sat down and thought, I'll catch up on some code reviews.
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 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.
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.
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. :)
Still no one is explaining a workflow that requires github to be up.
This was a genuine question. I have no doubt that my usage is different from yours, and I appreciate the opportunity to learn. Perhaps I can do things better, and you can be the one to teach me.
I don't care about the downvote(s), but I do care about missing an opportunity to do things better, or more effectively, or more efficiently, or something. Clearly people here use github differently from me, and I'd appreciate the opportunity to learn.
Presumably, interacting with Github's hosted issue tracking, editing your project's documentation on the wiki, submitting pull requests, doing a code-review of someone else's pull request before accepting it--any "clerical" project task other than writing and committing code, really.
I was speaking more generally than just Github's case with my original comment, though; for example, it's really obvious that people talk about Reddit being down on HN because when Reddit is down, they're A. bored, and B. want to talk about Reddit being down. They'd do that on Reddit if they could ...but it's down.
Comments
I would guess that it's just the digital version of the internet going down at work, and everyone hanging out in the office kitchen talking about how the internet is down, until it goes back up.
In other words, if you're waiting for [service] to come up in order to get something done, there's not much better to do.
It would be useful to me if someone could explain how their workflow requires github to be available, because it would seem that they are using facilities or features of which I am unaware.
Today it went down, just as I needed our CI server to do a pass. Which is fine, grab a coffee, then I sat down and thought, I'll catch up on some code reviews.
Thankfully, it wasn't long till it came back up.
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"
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.
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.
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. :)
Still no one is explaining a workflow that requires github to be up.
This was a genuine question. I have no doubt that my usage is different from yours, and I appreciate the opportunity to learn. Perhaps I can do things better, and you can be the one to teach me.
I don't care about the downvote(s), but I do care about missing an opportunity to do things better, or more effectively, or more efficiently, or something. Clearly people here use github differently from me, and I'd appreciate the opportunity to learn.
Presumably, interacting with Github's hosted issue tracking, editing your project's documentation on the wiki, submitting pull requests, doing a code-review of someone else's pull request before accepting it--any "clerical" project task other than writing and committing code, really.
I was speaking more generally than just Github's case with my original comment, though; for example, it's really obvious that people talk about Reddit being down on HN because when Reddit is down, they're A. bored, and B. want to talk about Reddit being down. They'd do that on Reddit if they could ...but it's down.