Why report it at all? Seriously. If I'm affected, I'll find out. If I'm not affected, why should you tell me?
It seems that every time a well-known service goes down, for however long, for whatever reason, instantly there's a flurry of posts here making sure everyone knows something that they either already know, or won't care about.
I'd really like that to stop, although perhaps I'm just a curmudgeonly old grey-beard.
It has become quite (unsuprisingly) prevalent on HN. Wonder if pg has any plans on fighting this and if the high-karma enabled functionalities take into account karma whoring in their formula.
You can easily spot the trend if you read HN through RSS. And it sucks :\
I would guess it's easier to spot the amount of noise when you skim through all the submissions as opposed to peeking at the highest voted stories on the front page every once in a while.
The the posts that end up in the front page have been filtered, an unfiltered RSS feed has even the failed attempts to get easy points.
Yes, I too hope pg decides to fight the good fight against others gaining precious Internet Points via methods I find unsavory, even if their accumulation doesn't affect me in the least.
Sock puppets = Proliferation of guns.
With karma = Availability of bullets.
What doesn't affect you individually, affects all of us collectively. I.E. It diminishes the legitimacy of this forum as a whole when those very same mechanisms that are meant to cultivate genuine discussion are abused for petty reasons easily.
Heres an idea: remove karma total - its just an epenis and nothing else. Keep points for posts so you can see if your post was good and for burying trolls but dont show the total in profile or news page. Done.
I disagree. When Twilio went down a few weeks ago, the second place I headed to was HN, and found that it wasn't just for me. And since this is a meeting place for the kind of people I want to hear from (like Twilio's developers), reading the thread helped me a lot.
So I agree with the "if it's less than 5 minutes, don't report it" sentiment, but I do like it when larger outages are reported.
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.
Usually there is a technical discussion on why this service went down, on the other hand sometimes someone comes back with an explanation of what happened and how to deal/prevent it, which is kind of helpful.
Comments
Why report it at all? Seriously. If I'm affected, I'll find out. If I'm not affected, why should you tell me?
It seems that every time a well-known service goes down, for however long, for whatever reason, instantly there's a flurry of posts here making sure everyone knows something that they either already know, or won't care about.
I'd really like that to stop, although perhaps I'm just a curmudgeonly old grey-beard.
-People notice that downtime posts end up on the front page.
-Those who care about fake internet points see downtime messages as "easy karma." No thought required.
-The mad rush to submit the "news" for easy karma results in votes for the first submission.
-The cycle repeats.
Downtime messages aren't the only thing. Sometimes things make it to the front page based on their perceived likelihood to make it to the front page.
aka karma whoring.
It has become quite (unsuprisingly) prevalent on HN. Wonder if pg has any plans on fighting this and if the high-karma enabled functionalities take into account karma whoring in their formula.
You can easily spot the trend if you read HN through RSS. And it sucks :\
Why is it more easy to spot through RSS? (genuine question)
I would guess it's easier to spot the amount of noise when you skim through all the submissions as opposed to peeking at the highest voted stories on the front page every once in a while.
The the posts that end up in the front page have been filtered, an unfiltered RSS feed has even the failed attempts to get easy points.
It appears to be easier to get into the RSS feed than the front page, so if you follow RSS you see many truly terrible submissions.
Yes, I too hope pg decides to fight the good fight against others gaining precious Internet Points via methods I find unsavory, even if their accumulation doesn't affect me in the least.
Sock puppets = Proliferation of guns. With karma = Availability of bullets.
What doesn't affect you individually, affects all of us collectively. I.E. It diminishes the legitimacy of this forum as a whole when those very same mechanisms that are meant to cultivate genuine discussion are abused for petty reasons easily.
Heres an idea: remove karma total - its just an epenis and nothing else. Keep points for posts so you can see if your post was good and for burying trolls but dont show the total in profile or news page. Done.
I disagree. When Twilio went down a few weeks ago, the second place I headed to was HN, and found that it wasn't just for me. And since this is a meeting place for the kind of people I want to hear from (like Twilio's developers), reading the thread helped me a lot.
So I agree with the "if it's less than 5 minutes, don't report it" sentiment, but I do like it when larger outages are reported.
Also, when the down time starts you don't know how much time it will last. Having the problem reported is helpful.
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.
Usually there is a technical discussion on why this service went down, on the other hand sometimes someone comes back with an explanation of what happened and how to deal/prevent it, which is kind of helpful.
I don't think age or beard colour affect curmudgeonness. The grumpiest guy at my office has a beige beard and he's not old.