How we lost 54k GitHub stars

What happened?

Due to an unfortunate sequence of events, I accidentally made the project’s repository private for a moment. And GitHub cascade-deleted our community that took 10 years to build.

What does it mean?

If you’re a downstream maintainer or anyone previously watching httpie/cli for notifications, for example, you’ll need to re-watch the repo. Incidentally, we’ve recently published a security release.

The same goes for stars. If you’re one of those 54K people who’ve starred the repo any time in the past decade, the repo is no longer among your starred projects.

Why did you make the repo private‽

It’s a peculiarity of GitHub, to put it mildly, that making a repo private permanently deletes all watchers and stars. I was even aware of this, and I obviously had no intention to make httpie/cli private. So, why then?

The proximate cause was that I thought I was inside a different repo; one with no content and zero stars. What I actually intended to do was to hide the HTTPie organization’s profile README, which I had created the week before but had no opportunity to populate.

What put me on the wrong path was an otherwise completely unrelated action: I had just done the same (i.e., hidden an empty README) on my personal profile by making jkbrzt/jkbrzt private.

GitHub’s conceptual model treats users and organizations as very similar entities when it comes to profiles and repos. In this context, and since I just wanted to repeat the same benign action on our organization’s profile, my brain switched to auto-pilot mode.

I didn’t realize at the moment there’s an inconsistency in the naming of this special repo containing profile READMEs and that it differs for users and organizations: name/name vs. name/.github.

That’s why I proceeded to make httpie/cli private instead of httpie/.github without realizing my mistake.

But there’s a confirmation, right‽

There’s a confirmation box. It’s designed to stop users in a situation like mine from doing something stupid. It tells you that “You will permanently lose all stars and watchers of this repository.” That’s pretty scary.

The problem is that the box looks exactly the same for repos with no commits and stars and for repos with a decade-long history and 55k stargazers and watchers. And it says “Warning: this is a potentially destructive action.”

To paraphrase, the box tells you “You’re about to demolish a house. If there are any people inside, they will all die”.

But it doesn’t include anything specific to break you out of your auto-pilot mode if you’ve confused the address and think you’re looking at an empty house.

A 54k-star question: Which one of these two dialogs is safe to confirm and which one deletes a 10-year-old community?

The dialog should be more contextual and, paraphrasing again, it should say “You’re about to kill 55,000 people.” That would’ve certainly made me pause.

So you made it private, just flip the switch!

You can imagine my confusion when I went back to the organization page and not only could I still see the empty README but our most popular repo was nowhere to be found. After a moment I realized what happened. So I went back to the repo’s settings to flip the switch. But GitHub didn’t allow me to do that—for an entire half an hour.

If you’re wondering why so long, it’s because 🥁 that’s how long it took GitHub to cascade-delete our decade of stargazers and watchers. And there was no way to stop the process. All I could do was start writing to GitHub support, refresh the page and wait for the number of stars to reach zero before I could make it public again.

Why doesn’t GitHub restore it‽

GitHub obviously has backups. And it is indeed possible to undo the damage done by accidentally making a repo private. The GitHub team themselves accidentally made the GitHub Desktop app repo private once. And they restored everything for themselves within hours. Here’s the former GitHub CEO explaining the situation:

In our case, however, they refuse to do that, citing undesirable side effects and the cost of resources. We even offered GitHub financial compensation for any resources required. But, sadly, they declined. They have other priorities than resurrecting the community of one of the oldest and most popular community projects on their platform.

So the answer to the question is, unfortunately, the following: GitHub will restore a repo damaged by making it private. But only if it’s one of their own projects, not a community one. The latter gets a tweet, at best.

Lesson #1: UI/UX design

Show, don’t tell. Design confirmation dialogs in a don’t-make-me-think fashion. When the user is about to destroy something, don’t describe that as a potential scenario in abstract words that the user needs to convert to mental images and put values on. Especially when cascade-deleting as a side effect of the primary action. For example, here’s how we approach that in HTTPie for Desktop:

And, of course, the dialog should reflect the severity of the side-effect. It should be quiet when there are no side effects at all. Otherwise, we risk desensitizing the user by wasting their limited attention capital:

Lesson #2: Database design

Use soft-deletes. People are human and they make mistakes. For hard-deletes, delay the process.

Lesson #3: Relationship with GitHub

It was a human error on our side and GitHub made it clear they’re not legally obliged to help us. The tone of our decade-long mutually-beneficial relationship is set by GitHub’s Terms of Service. Thinking there was more to it was naive.

After all, GitHub has a history of taking controversial actions that go against the spirit of open source and community and then reverting them only based on public outrage. And Microsoft (which now owns GitHub), despite its newly-found affection for open source, has not always had exactly a great reputation.