Live data from Hacker News

We lost 54k GitHub stars

httpie.io

191–200 of 697 posts

Re: We lost 54k GitHub stars

#191
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?

I think this is getting at the more robust solution.

When youtube videos are taken down or made private, they are not deleted necessarily from my playlists. There's simply an indicator that they video is 'no longer available'. I don't see why something similar can't be the behaviour for GitHub stars and watches?

Re: We lost 54k GitHub stars

#193

Earlier quoted context omitted.

> I'm not really sure how you'd do a "cascading soft delete" without making some kind of manual cascading logic? Perhaps the delete action is not accomplished right away and a column is checked. Then after a X amount of months a worker process goes around actually deleting things?

I meant to focus on the cascade part of the equation here. For example, lets say `stars` are foreign keyed (FKed henceforth) to repos, and (say) `X` are FKed to `stars`, and `Y` is FKed to `X`. Then if you do a "hard" delete of the repo status (or the stars), then we can set that to cascade to `X` and `Y` as well. Otoh, I don't think you can apply a cascade like that automatically when you're just changing a value (w…

[deleted]

Re: We lost 54k GitHub stars

#194
post #134
post #115

Earlier quoted context omitted.

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.

Re: We lost 54k GitHub stars

#195

Earlier quoted context omitted.

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…

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.

Yeah, it's a different story when dealing with safety.

With industrial machines you have to assume people will do the dumbest thing possible. Because someone will find a way to get crushed in a moving part if they can.

You have safety fence after safety fence and regularly test that your lockouts work.

If you don't do all of this and someone dies you can face very harsh legal penalties.

We don't do this with software when the cost of failure is so much lower but we should still understand smart humans will make mistakes.

Re: We lost 54k GitHub stars

#196

Earlier quoted context omitted.

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…

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.

My favorite is "let's imprison people who make mistakes". It doesn't stop mistakes, it just covers them up.

Re: We lost 54k GitHub stars

#197
post #141

Earlier quoted context omitted.

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…

How many years have we had to learn from people using programs to know that people make mistakes. Goodness knows how many people burned themselves using "rm". For that reason alone, "rm" is a bad tool, and should be replaced with something like trash-cli.

[deleted]

Re: We lost 54k GitHub stars

#198
post #89

Earlier quoted context omitted.

Which comes with its own problems. What if I just published something I wanted to be secret? Then I need to be able to switch it back to private, and it has to be quick, not after five minutes. Distributed systems with eventual consistency already make fixes like that hard, not to mention caches and whatever.

The GP didn’t mean “wait 5 minutes before making any action”, they meant “stage the change so the user can see the result of their action but they still has a grace period to undo it”.

Or, have there be no need to undo anything. Why should ticking the "private" flag have any effect on anything else? If you wanted an effect on something else, a separate button "Nuke all 53,675 star from this repo", with its own protections, would suffice.

Re: We lost 54k GitHub stars

#199
This is laziness on GitHub.

If your client asks you for work and you get lazy because it needs some internal modification that could take a day instead of an hour, you just respond it's impossible.

Generally that's quite unacceptable especially when they already know about the situation from previous incidents and obviously human errors could happen again and the fact they did restore for their own project doesn't make it look any better.

Re: We lost 54k GitHub stars

#200

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…

Data privacy laws like GDPR probably require them to fully hard delete when a user asks for something to be deleted. So any undo functionality would need to make sure it's compliant in every region that could have a privacy law. I'm not sure how realistic it would be to ask companies like Github to jump through all those hoops because people refused to read (and then blindly typed stuff out).
Post reply on HN