Another update. We’ve restored the redis backend, and so godoc.org should be operating okay now. I’ll watch it some more to make sure it continues to be stable.
Edit: The godoc.org server has been serving successfully without any 500s since this comment was originally posted, so I’ll update this issue to be resolved.
Let’s please everybody take a break from this discussion and see what @dmitshur has to say. Please try to be polite and respectful at all times on this issue tracker. Thanks.
It’s a little disappointing to me that a simple request for a post-mortem for an outage on a system many people rely on is being met with this level of aggression. There’s really no need to accuse people of being entitled or having ulterior motives for asking for one.
Moreover, the ball on this request is pretty much in the go team’s court, and speculating on their answer and talking down to community members for requesting one is not helpful. It’s more constructive to see what the go team says.
To my knowledge, nobody has ever committed to an availability goal for godoc.org. It is operated as a best-effort service, and it is slated to be replaced by pkg.go.dev. @dmitshur took time out of his weekend to fix it, which as far as I’m concerned was beyond the call of duty. I think it would have been nice to at least thank him. I don’t think it’s fair to assume that a post mortem is owed.
This is quite different from other services, notably proxy/index/sum.golang.org, which are critical dependencies for many Go users. We don’t have a published policy for post mortems, but I think if those experienced an outage anything like this scale it would be appropriate to publish one.
If anyone would like to discuss the level of support that these services receive, I think a thread on golang-dev or golang-nuts would be a better forum. Or, if there’s a concrete proposal, (e.g. publicize a post mortem for any significant outage) perhaps file an issue. But I don’t think this discussion is shaping up to be productive.
@cup Not looking for a post mortem since I’m pretty confident this didn’t kill anybody. 😉My desire for such a retrospective is around this one line:
If these issues can be acknowledged and made public sooner, it makes providing user support in the community much easier (and it looks better on us too).
If we do a retrospective and discover it’s not clear who to communicate these issues to and how, that’s an extremely valuable learning. If we’re able to make changes from that, it would help those of us who are fielding user questions, and pointing them to different Go-related resources. I think a good analogy might be businesses with Customer Support organizations. If there is something going on, most try to provide that sort of context to their support agents so they can better communicate with the people contacting them.
I raised the issue [1] because people were in the Gophers Slack trying to
figure out what was goin on with getting their package documentation.
fair enough, but those people are looking for Go package documentation, not a post mortem. You are looking for that.
So even if you were acting in good faith to help those people, getting a post mortem is only going to help you and others looking for that, not for people who just want the documentation.
@theckman yeah, I get that, you think its important, I do too.
But why do you feel entitled to demand one? For example, compare what you said:
@dmitshur when can we expect a post-incident analysis to be completed with a
publicly available write-up?
with another option:
Will a post-incident analysis with a publicly available write-up be made
available? If so, it would be much appreciated!
one is a demand, one is a (polite) ask.
There is an obligation to
no, theres not. Are you paying Google or Alphabet? This is open source software friend. The Golang team, and the larger Go community dont have any obligation to you in this regard.
Another update. We’ve restored the redis backend, and so godoc.org should be operating okay now. I’ll watch it some more to make sure it continues to be stable.
Edit: The godoc.org server has been serving successfully without any 500s since this comment was originally posted, so I’ll update this issue to be resolved.
Let’s please everybody take a break from this discussion and see what @dmitshur has to say. Please try to be polite and respectful at all times on this issue tracker. Thanks.
It’s a little disappointing to me that a simple request for a post-mortem for an outage on a system many people rely on is being met with this level of aggression. There’s really no need to accuse people of being entitled or having ulterior motives for asking for one.
Moreover, the ball on this request is pretty much in the go team’s court, and speculating on their answer and talking down to community members for requesting one is not helpful. It’s more constructive to see what the go team says.
Isn’t this why we have a CoC?
To my knowledge, nobody has ever committed to an availability goal for godoc.org. It is operated as a best-effort service, and it is slated to be replaced by pkg.go.dev. @dmitshur took time out of his weekend to fix it, which as far as I’m concerned was beyond the call of duty. I think it would have been nice to at least thank him. I don’t think it’s fair to assume that a post mortem is owed.
This is quite different from other services, notably proxy/index/sum.golang.org, which are critical dependencies for many Go users. We don’t have a published policy for post mortems, but I think if those experienced an outage anything like this scale it would be appropriate to publish one.
If anyone would like to discuss the level of support that these services receive, I think a thread on golang-dev or golang-nuts would be a better forum. Or, if there’s a concrete proposal, (e.g. publicize a post mortem for any significant outage) perhaps file an issue. But I don’t think this discussion is shaping up to be productive.
@cup Not looking for a post mortem since I’m pretty confident this didn’t kill anybody. 😉My desire for such a retrospective is around this one line:
If we do a retrospective and discover it’s not clear who to communicate these issues to and how, that’s an extremely valuable learning. If we’re able to make changes from that, it would help those of us who are fielding user questions, and pointing them to different Go-related resources. I think a good analogy might be businesses with Customer Support organizations. If there is something going on, most try to provide that sort of context to their support agents so they can better communicate with the people contacting them.
Being able to do this would be super nice.
fair enough, but those people are looking for Go package documentation, not a post mortem. You are looking for that.
So even if you were acting in good faith to help those people, getting a post mortem is only going to help you and others looking for that, not for people who just want the documentation.
@theckman yeah, I get that, you think its important, I do too.
But why do you feel entitled to demand one? For example, compare what you said:
with another option:
one is a demand, one is a (polite) ask.
no, theres not. Are you paying Google or Alphabet? This is open source software friend. The Golang team, and the larger Go community dont have any obligation to you in this regard.
@dmitshur suggestion worked for me. For example changing:
https://godoc.org/golang.org/x/text/cases
To:
https://pkg.go.dev/golang.org/x/text/cases
but to confirm, no, its still not working: