Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We lost 54k GitHub stars

httpie.io

Post reply on HN
Print view View original

401–410 of 697 posts

Re: We lost 54k GitHub stars

#401

Post by Proven »

mynameisvlad wrote: post #163
wpietri wrote: post #123

Earlier quoted context omitted.

I suggest you read "The Field Guide to Understanding 'Human Error'". You'd learn a lot. https://www.amazon.com/Field-Guide-Understanding-Human-Error... My view is that expecting humans to stop making mistakes is much less effective than fixing the systems that amplify those mistakes into large, irreversible impacts.

This, 1000x this. It's easy to be an armchair engineer and say "well, obviously, don't make this mistake in the future". As a species, we will always take shortcuts. If a mental pathway doesn't need to be exercised to do something, it won't be. If we see the same popup a hundred times, we're going to ignore the contents by the 100th time because we're used to it. But it shouldn't be possible to make this mistake if t…

No post body was provided.

Re: We lost 54k GitHub stars

#402

Post by KennyBlanken »

bobbylarrybobby wrote: post #306
NorwegianDude wrote: post #289

"the biggest accidental community loss in open source history" This was very much drama for very little. Sure, some might follow the project to know about updates, but if people care that much if they are using the latest version of a CLI tool then they will certainly check it out again later. Very very few people of those who followed the project cares, and close to nobody cares what percentile the project ranks as…

You missed the nuance in the criticism of GitHub's UI. The issue is not the presence of a roadblock, but that the same roadblock is put up regardless of how "actually" destructive the action to be taken is. The same roadblock should not be used to guard against both benign and severe consequences, else you have no real way of telling what lies on the other side of the roadblock you're plowing through.

There's no nuance.

The UI warns you something serious is going to happen with bold text on a separate line.

It makes you type the full path of the affected object.

His explanation for what he was doing in the first place (making a README file private) doesn't make the slightest bit of sense.

It's a PR stunt for a startup company.

Re: We lost 54k GitHub stars

#403

Post by KennyBlanken »

alasdair_ wrote: post #342
NorwegianDude wrote: post #289

"the biggest accidental community loss in open source history" This was very much drama for very little. Sure, some might follow the project to know about updates, but if people care that much if they are using the latest version of a CLI tool then they will certainly check it out again later. Very very few people of those who followed the project cares, and close to nobody cares what percentile the project ranks as…

> Github warned about the action, and even required written confirmation to make sure it was the correct repo. Sure, but the written warning was the same one for a completely safe action.

You mean the one that requires you to write the full path of the affected object?

Re: We lost 54k GitHub stars

#405

Post by bradgessler »

I see a lot of folks talking about better warnings, etc.

Something else to consider for situations like this (or maybe for your apps) is to use the element of time to prevent mistakes.

For example, when a user wants to permanently delete an account or do any action that’s destructive, irreversible, or catastrophic… queue up a job for 10 minutes, an hour, or maybe a day, that gives the user time to cancel it if they made a mistake.

Out-of-band could be another way to prevent mistakes. “Want to delete your account? We’ll send you a link for you to continue via email”. This would also be cancelable.

There’s a lot of ways to deal with potentially irreversible actions outside of “better error messages” or checking the equiv of an “are you sure?” Checkbox.

Re: We lost 54k GitHub stars

#406

Post by throwaway0x7E6 »

aerovistae wrote: post #371
throwaway0x7E6 wrote: post #354

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

They did admit they fucked up. Then they tried to make the best of it by looking for possible ways of preventing other people from repeating their mistake. What did you want? A blog post that says "I suck, I'm a failure, thanks for reading"? Why is this your response to someone trying to be contructive while post-morteming a failure?

the guy with 10+ experience of using github went to the "danger zone", pressed the red button, saw the very, very, very explicit warning about the consequences of pressing it and confirmed the action by explicitly typing the exact name of the repository.

yes, that blog post would've been apt. as constructive as it gets.

>Why is this your response

because I don't want to send a notarized request every time I need to delete a folder, format a disk or submit a SQL query

Re: We lost 54k GitHub stars

#407

Post by d3nj4l »

cmeacham98 wrote: post #111
vaishnavsm wrote: post #70

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…

I specifically dislike the "Lessons" section, as it throws all the blame on github and doesn't mention the seemingly obvious advice: "make sure you're not on autopilot when taking potentially dangerous actions, on github or any website". Yes, GitHub probably should show the stars in the warning UI, and hopefully that will prevent some of these mistakes. But GitHub makes it pretty hard to make this mistake already - t…

Agreed, and I'm genuinely surprised that so many on HN are angry at GitHub when they already made it so hard to do this. The author explicitly mentions they were on autopilot - it would take a significantly more challenging barrier for them to not do the exact same thing no matter how many prompts GitHub put there. It does make sense for it to be more reversible, but I can also understand why GitHub doesn't want to put in the effort: this is a once in a year kind of incident and the resources required wouldn't be worth it compared to signal boosting, like they did on twitter. I, for one, would be extremely pissed if GitHub made it harder for me to do routine actions because there's a possibility of data loss. I signed up for that when I typed the repository name in.

Re: We lost 54k GitHub stars

#408

Post by anonfunction »

yellowapple wrote: post #338

30 minutes seems like a weirdly long time to delete 54,000 rows; doing something in SQLite like CREATE TABLE stars (id INTEGER PRIMARY KEY, user TEXT, repo TEXT); INSERT INTO stars SELECT value AS id, 'User ' || value AS user, 'foo' AS repo FROM generate_series(0,53999); SELECT * FROM stars; DELETE FROM stars WHERE repo = 'foo'; is just about instantaneous. I'm sure GitHub's schema is more complicated than that, but…

GitHub doesn't use foreign keys[1], and there's likely many tables related to all the users, notifications, permissions, etc... that would need to be cleaned up. Without foreign keys they likely have some system process that does this instead of a simple `DELETE FROM` which cascades.

1. https://github.com/github/gh-ost/issues/331#issuecomment-266...

Re: We lost 54k GitHub stars

#409

Post by djur »

ncmncm wrote: post #262
icambron wrote: post #183

Earlier quoted context omitted.

That’s not quite it. The solution isn’t to stop them from doing it or warning them more aggressively; it’s to make it genuinely less dangerous. For example, make the stars all come back when you reverse the switch. Of course that’s a lot harder to do, since it’s a lot more than a UX change. So I’m not really slagging GitHub here. But it’s the right way to attack this problem.

Just not deleting them in the first place, or not deleting them until explicitly asked to, would suffice, and would be, ultimately, less code. So, I am not buying the apologetics.

It seems to me that services that pretend to delete data but don't actually do it are usually subject to criticism on Hacker News, not praise.

Re: We lost 54k GitHub stars

#410

Post by 411111111111111 »

vaishnavsm wrote: post #70

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…

> I assume that the cascading done on GitHub would be done on a FK constraint, but I'm not really sure how you'd do a "cascading soft delete" without making some kind of manual cascading logic?

Couldn't you just use an on delete trigger for this? I have no experience one the subject however

Post reply on HN