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

511–520 of 697 posts

Re: We lost 54k GitHub stars

#511

Post by josephjang »

wpietri wrote: post #123
cmeacham98 wrote: post #111

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.

It's not about whether human can make a mistake or not. It's about how much effort should be made to prevent a certain type of human mistakes.

If every system we're interacting daily should be fool-proof, it will requires enormous time and effort. Naturally, we invests more time and effort when it's about life and death situation. If we only lose 2 cents by our mistake, we just don't care.

Of course, I'd like to have more fool-proof design in all the destructive interactions from all websites. But, the question is, does it worth it?

Re: We lost 54k GitHub stars

#512

Post by alpaca128 »

viscanti wrote: post #200
cmeacham98 wrote: post #111

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…

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

I'm pretty sure GDPR doesn't say everything must be wiped instantly but instead within a reasonable time period. One that's certainly enough to undo such actions.

Re: We lost 54k GitHub stars

#513

Post by forgotpwd16 »

robonerd wrote: post #345
spiderice wrote: post #340

Earlier quoted context omitted.

It's crazy to me how quickly this conversation has devolved. If Pewdiepie had all his Youtube subscribers deleted should he just say "oh well, the ones that like me will come back". No. Because that's an absurd attitude. Obviously that would forever hurt his viewership. Github is no different with stars. They matter. Period. Maybe not to you. But they matter.

Pewdiepie's compensation is intrinsically related to his subscriber count, no? That gives him a reason to care. Is your compensation similarly related to your github star count? I sure hope not.. If I unstar your repo, I have not taken anything from you because you never owned my star in the first place. Github presents this number to you as though it were important, to give you a dopamine hit when the number goes up…

>If the repository had been deleted

For which to happen you've to do the same thing: type out its name. So I wonder if people ask for privatize to be presented with number of stars, should when deleting a repo GitHub present you with number of commits, issues, releases, etc as well?

Re: We lost 54k GitHub stars

#514

Post by jeffreygoesto »

xupybd wrote: post #195
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.

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…

In software often the cost is paid by other people (your users) and you don't (want to) see them. How much did the Atlassian outage cost it's clients altogether? How much thereof will they need to compensate?

Re: We lost 54k GitHub stars

#515

Post by alpaca128 »

hk__2 wrote: post #496
ncmncm wrote: post #177

Earlier quoted context omitted.

Even better, flipping "public/private" has absolutely no need to delete any information at all. There could be separate buttons, "Delete all my stars", "Delete all my watches".

> Even better, flipping "public/private" has absolutely no need to delete any information at all. Of course it does. You can’t watch/star a private repo unless you have access, so all watchers/starrers should be removed. If you kept the data as-is watchers would still see the repo updates in their feed, which is the opposite of the 'private' feature promise.

Sure, if you don't change any part of the system it has to be that way. But there's no reason a private switch can't just suspend stars/watchers instead of permanently deleting them.

Re: We lost 54k GitHub stars

#516

Post by Gigachad »

tshaddox wrote: post #132
FabHK wrote: post #90

Earlier quoted context omitted.

> I don't know what else they could have done to try to prevent it. As the author of the post suggests: Prominently spell out "This will remove 54,000 stars." vs. "This won't remove any stars (there are none yet)."

I'm not convinced that would have really solved the problem. One could just as easily post a screenshot of two nearly identical dialogs where the only different is that one says "This will remove 54 stars" and the other says "This will remove 54,000 stars" and the same argument could be made that "the only way to notice the difference is if you happen to notice those 3 zeros."

No amount of warning popups will help. The only solution is a delayed delete with the option to undo.

Re: We lost 54k GitHub stars

#517

Post by Aeolun »

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…

Tbh, it doesn’s look like the wrong repo name if you want to make your organisation README private. I agree with the author that the discrepancy between user and organisation profiles doesn’t help here. If every user/organisation could make a .github repo instead it would be much more obvious.

Re: We lost 54k GitHub stars

#518

Post by josephjang »

pmontra wrote: post #509
cmeacham98 wrote: post #111

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…

The author explicitly admits "my brain switched to auto-pilot mode." The problem with that is that we're on auto-pilot many times and we realize we're doing it only after something bad happens. The UX should prevent auto-pilot to do harm to us (and possibly to the customer/company relationship.) "You're about to delete 55k stars" should be enough, as the author suggested. But designers can be on auto-pilot too.

> But designers can be on auto-pilot too. You're blaming some people without any basis.

Re: We lost 54k GitHub stars

#519

Post by tialaramex »

ryandrake wrote: post #321
mynameisvlad wrote: post #239

Earlier quoted context omitted.

> I'll bet the list of side-effects that are important to some people would be pointlessly long. There's many good ways to design this that wouldn't result in pointlessly long lists (which is another problem). You don't need to expose everything that will happen when you do an action, just the "most important". With unlimited budget, you could compare a bunch of metrics to a baseline to figure out what might be impor…

Warnings are good but not perfect. At the end of the day, you can’t help everyone with just warnings. You could make the UI bright flashing red, with a skull and crossbones, have it say “Never invoke this: it will delete all your data and kill your dog. Please type ‘I_WANT_CANCER’ to continue.” And users will do it. It can’t be helped. The only (admittedly hard) way is UNDO.

Undo. If it's possible, you want undo. If it's difficult, you still want undo. Only when you've satisfied yourself that it's outright impossible should you reluctantly design the UX with the "Are you sure?" prompt instead.

Also, if you must have I_WANT_CANCER type prompts, try to make them involve expressing what it is that the human is agreeing to, because sometimes it's only at that point the human realises their plan was very stupid. GitHub does that here (you have to type the name of the repo, to delete main_project you'll need to type main_project) but many things do not.

This is why I like Git's force-with-lease. When I try to forcibly overwrite the state, because I know Jim's push was wrong and must be undone, force-with-lease makes me express that, "--force-with-lease=jim-daft-change". And when in fact what I'm going to overwrite is Lisa's urgent bug fix, not Jim's erroneous change, the force-with-lease fails and to get it to apply this way I'd need to say "--force-with-lease=lisa-bug-fix" and that's one last opportunity to say "Wait, what? That's not what I want to do".

Re: We lost 54k GitHub stars

#520

Post by forgotpwd16 »

williamsmj wrote: post #58
pluc wrote: post #21

You didn't lose anything, you asked for it to be removed by setting your repository private, albeit mistakenly. Something that is public (stars) cannot coexist with something that is private (your repo), otherwise unexpected things start to happen or you need to write a bunch of pointless edge cases. It makes sense. So does this article, but it should be a "lesson learned" and not a "GitHub fucked us" angle cause it…

The article literally has a section "Lessons learned".

Lessons learned... for GitHub to take.
Post reply on HN