I'm just surprised that after going through that pain themselves they didn't decide to revise how that social linking data is handled. A lot of github content is softly deleted by necessity, you couldn't nuke tickets written by a now non-existent user or unmerge PRs so this isn't really a new concept to the team.
I don't think it's surprising they'd do such a thing for themselves and not a customer - I'm more surprised they didn't remove the footgun for future mistakes on their part.
Just as AceJohnny said, the scope of this is entirely different. Restoring a backup for an internal project costs time/resources that the company can easily handle. If it became a problem it would be easy for github to tell their internal projects "No, we're no longer restoring from backups"
Opening up the ability to do that externally would potentially require multiple people working full-time to handle the requests.
"We even offered GitHub financial compensation for any resources required." Considering the tone of the article I think there's a very high risk if github accepted agreed to that we'd see an article titled "Github charges popular open source project $5000 to fix a minor accident"
Just FYI - you can star private repositories so it's not quite that simple. You'd need to determine if the starring aligns with permissions... but I think it's still relatively reasonable.
I get that, but they probably shouldn't have publicized the remediation via a public tweet if it's an avenue that's closed to the rest of us plebs (since in cases like this, it really feels like salt in the wound).
I wonder how different the response from Github would be if this blog post was instead, "Oops, Github's confusing UI made me delete the entire project metadata... so since we're forced to start fresh we decided to move to Gitlab/sourcehut/etc."
There is no way in the world that the kind of person who writes a post like this and clearly places so much emphasis on gamified social media stats as a proxy for self-validation ever chooses to move to Sourcehut. No way. GitLab is most likely out of the question, too. The author of this post is exactly the kind of ideal customer for what GitHub is "selling" and that the others can't provide.
There was a way to say this without framing it as a personal attack. The author may care about stars because they find that increased engagement leads to higher quality contributions, for example.
When you think about it, it seems reasonable, I think about what would happen if it were me.
If I was working at GitHub, and I nuked something, then the rest of my day would be un-nuking that thing. On the other hand if I was working on something totally unrelated, and then you my PM came to me and said "can you stop what you're doing and unfuck this thing" it would obviously depend on what I was working on.
It's your customer (repo owners) asking for support and throwing it away being busy is just lazy attitude. You had prior incidents and the bugs were left as is and apparently it will happen again.
Being busy is lazy? GH has hundreds of thousands of customers. In your company, how often do you immediately drop everything to work on a single customer's issue? How often do customer issues sit in a support queue? What would be the reasonable turn around time for an issue like this?
I would observe that even today, the GH desktop repo has only 14k stars, and at the time, archive.org says only 2.6k[1] - so I would not be surprised if the costs associated with the restore were massively different.
(Not weighing in on whether they still should have considered it or not, just observing that their claim that it costs an unacceptable amount may not be inconsistent with having restored a much less comparatively "hot" repo.)
