Live data from Hacker News

We lost 54k GitHub stars

httpie.io

101–110 of 697 posts

Re: We lost 54k GitHub stars

#101

That comparison spot the difference pic is really scary. I had to check it 2 times myself before I could spot that the last line is different. Now that you're on the HN's frontpage, hopefully somebody from Github upper management will see this and all will be good soon thanks to gold old HN (especially when they did the same thing themselves and restored it). Wish you the best.

> That comparison spot the difference pic is really scary. I had to check it 2 times myself before I could spot that the last line is different. That's not the only difference. The other difference is that you also have to type the full repository name, including the organization name. If they wanted to delete the correct repository, they would have to type httpie/.github, but instead they typed httpie/httpie. It's u…

There are certain repository actions that require an interaction and assistance from GitHub customer support.

The community was valuable to GitHub as well.

I could see a spec on “sizable community thresholds” where if an interaction might blow away something of that size GH affords you an exchange with a “concierge” forcing a minor exchange with a real person.

Re: We lost 54k GitHub stars

#102
post #10
post #3

It does strike me as unfair that GitHub themselves made the exact same mistake but were able to fix it with database backups.

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 surpris…

[deleted]

Re: We lost 54k GitHub stars

#103
post #50

Earlier quoted context omitted.

That's bad because it lies to users and you can't remove the star when it's in that state.

But if your star doesn't effectively exist why does that matter?

Because if the star is merely hidden then the repo can come back later. If you don't want any association with that repo any more, it's bad that it can put itself back into your starred list.

Re: We lost 54k GitHub stars

#104

Earlier quoted context omitted.

> That comparison spot the difference pic is really scary. I had to check it 2 times myself before I could spot that the last line is different. That's not the only difference. The other difference is that you also have to type the full repository name, including the organization name. If they wanted to delete the correct repository, they would have to type httpie/.github, but instead they typed httpie/httpie. It's u…

> The other difference is that you also have to type the full repository name, including the organization name. No, you don't have to type it, and I doubt anyone types it. You copy that line and paste it. Often it's done on autopilot, especially when in a rush.

I type it.

It’s typically short short, and it’s a very destructive action. It’s also very apparent to me why I would want to type it out.

That said, someone is going to make a mistake at some point. I’d expect better from github support here.

Re: We lost 54k GitHub stars

#105
I think there are two types of destructive actions; destructive actions you do as a part of completing some other task, and destructive actions you do for compliance reasons.

I think the problem arises when product designers aren't sure which case their data deletion function is for.

If you dumped a bunch of social security numbers in your non-confidential data history and batch job system, you'd want to be able to permanently delete it as part of the incident response, to reduce the number of people that are exposed to data they shouldn't have access to.

But if you delete some lines of code from your text editor, they can just pop back into existence with the press of a key because you were probably just moving them around, or trying some buggy function without a piece of code you thought might be unnecessary to isolating the defect, etc. Editors clearly understand that you don't kill text out of an Emacs buffer to solve a compliance issue, so they keep it around even though you technically asked for it to be deleted. (Imagine how crazy it would be if deleting text in your editor deleted it from memory, the clipboard, version control, and your upstream VC server!)

In the case of this Github issue, there was clearly a fundamental misunderstanding. Github probably imagined the feature as a compliance type thing; get this stuff off the Internet as fast as possible at any cost necessary. Delete the list of people that even knew this thing existed! I could see why someone might want that. But what the user thought was that this was something they needed to do along the way to some other goal.

I have a feeling that people pick the compliance route more often than the "experimentation" route more often than not, not because they expect users to have actual compliance-type issues, but simply because it's easier. The net result is that users are trained to fear computers and fear experimentation, and that's a bad state we've put society in. This article is yet another victim of "if they said they were sure they wanted to delete it, we can just delete it". But it's actually pretty rare that people are sure.

Re: We lost 54k GitHub stars

#106
post #67
post #3

It does strike me as unfair that GitHub themselves made the exact same mistake but were able to fix it with database backups.

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…

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.

Re: We lost 54k GitHub stars

#107
post #84

Sure, the author should be responsible. Yes, GitHub should have a better UX around this action. But... There is another thing to consider: Is it really necessary that a repo that is accidentally made private and then made public should lose its stars anyway? Is that really what the repo owner or the people who starred the repo even want to happen?

Agreed. This just screams bad UX on a corner case.

Re: We lost 54k GitHub stars

#108

I really like this post. While the author clearly feels bad about the fact that they've lost his community and that GitHub didn't restore it (which is honestly what any of us would've felt under similar circumstances), they're also focusing towards the future and using their personal experience as a parable all of us can learn from. Lesson 1 on UI design I think is really important. I often think scary popup boxes ar…

> "that GitHub couldn't restore it"

What an odd turn of phrase.

Re: We lost 54k GitHub stars

#110

I really like this post. While the author clearly feels bad about the fact that they've lost his community and that GitHub didn't restore it (which is honestly what any of us would've felt under similar circumstances), they're also focusing towards the future and using their personal experience as a parable all of us can learn from. Lesson 1 on UI design I think is really important. I often think scary popup boxes ar…

For Lesson 1: I think the general pattern that ought to be followed is to "prefer undo to warnings." Undo is often harder to implement, however it's usually a superior experience.
Post reply on HN