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.

Or simply automate the restoration! They know how to do it! Make it easy!

True. On the other hand - Atlassian did automate their backup restoration. Look where it brought them ;-)

Obviously you need to automate the restoration of the restoration!

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"

Or, knowing that it's the only way they have to recover from this situation, they could make the process easier to do and price it out as a service.

Or, just leave everything in place, always, and have the other code ignore the annotations for exactly as long as the repo is private.

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.

Ok, then have a separate button: "Delete all 54,000 stars on this repo", completely independent of public/private.

Internal vs External support.

Internal support is inherently limited: the single organization is of limited size.

External support has no limit in scope, you have to setup SOPs (Standard Operating Procedures), communicate expectations, likely hire support staff...

Look at it this way: internal support is helping your friends, but external support requires setting up contracts.

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.

httpie would never do this. Deleting their stars is already a blow for their community, but changing to another provider would kill it.

And yet they specifically call out Microsoft. And then the only consequence is "I will probably take a break from wearing Octocat-decorated t-shirts."

Which makes them come out as hypocrites. You don't get to blame Microsoft for EEE, and then continue to help them with it !!

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.)

[1] - https://web.archive.org/web/20201116172809/https://github.co...

It would strike me even more unfair if GitHub fixed this mistake only for customers they like.

What is possibly unfair about that?