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

141–150 of 697 posts

Re: We lost 54k GitHub stars

#141

Post by abnry »

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…

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.

Re: We lost 54k GitHub stars

#142

Post by sam0x17 »

JadoJodo wrote: post #124
bsuvc wrote: 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 don’t know for certain but I feel like this could allow something like 1. Takeover/inherit public repo with lots of stars 2. Take repo private (retaining stars) 3. Replace repo code with some malicious/offensive code. 4. Take repo public again 5. Inherit the trust/prestige of the old repo.

Yeah but it's not like stars are seen as some amazing endorsement on the part of the individual starring. It's more like a favorites list if anything

Re: We lost 54k GitHub stars

#143

Post by nemothekid »

sefrost wrote: 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.

When you think about it, it seems reasonable, I think about what would happen if it were me.

If I was working at GitHub, and I nuked something, then the rest of my day would be un-nuking that thing. On the other hand if I was working on something totally unrelated, and then you my PM came to me and said "can you stop what you're doing and unfuck this thing" it would obviously depend on what I was working on.

Re: We lost 54k GitHub stars

#144

Post by sam0x17 »

paxys wrote: post #28
williamsmj wrote: post #16

https://rachelbythebay.com/w/2020/10/26/num/ makes a similar point. I don't remember us saying people only have themselves to blame when that article was posted ( https://news.ycombinator.com/item?id=24904204 ). Not sure why we're doing it on this post, which makes a number of completely reasonable and specific suggestions for improvement.

"Type a specific thing to confirm" (as suggested by the post you linked) is exactly what Github does for destructive actions. And the author still messed it up because they were on "autopilot". At that point the suggestions go beyond being reasonable.

They could very easily list the number of stars that will be deleted, as a sanity test. That in my opinion is even more reasonable than having to type the repo name, and should be implemented.

Re: We lost 54k GitHub stars

#145

Post by [deleted] »

calcifer wrote: post #81
Dylan16807 wrote: post #20

Earlier quoted context omitted.

Why not? I think the respectful solution is to show it as "you starred X, it's private now, you can unstar if you like" (make sure if the name changes privately then the new name isn't shown). Such a solution is not only good in the case of mistakes like this, it also doesn't gaslight the person that starred a repo only for it to disappear from their list.

> it also doesn't gaslight the person that starred a repo only for it to disappear from their list. It's honestly hilarious how the definition of 'gaslight' has expanded so dramatically in the past few years that it now means 'anything that confuses me'. For future reference, here's what it actually means [1]: > Psychological manipulation of a person usually over an extended period of time that causes the victim to q…

[deleted]

Re: We lost 54k GitHub stars

#146

Post by oriki »

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…

Yeah, but on the other hand, "don't make mistakes" isn't a meaningful or useful lesson.

Re: We lost 54k GitHub stars

#147

Post by jacobsenscott »

rhtgrg wrote: post #128
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 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". I don't know. Github employees themselves have made this mistake as outlined in the post, and they were easily able to recover from it, which probably lowered the priority on chang…

Idk about "easily", but I'm sure they were motivated. If you've ever tried to restore parts of a database in a piecemeal fashion, it is usually fairly labor intensive. But you would hope there are a few gh engineers who would be motivated to do so without manager approval in the dead of night because httpie is great.

Re: We lost 54k GitHub stars

#148

Post by vaishnavsm »

benjaminjackman wrote: post #110
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…

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.

I agree that undos are pretty nice for when errors are possible, but I think there's a really good reason to put up warnings too. Let's say they accidentally made the repo private, but didn't notice it (unlike what happened here). Although you would be able to undo the change, it may have only kicked in once the news spread around (followed by reputation damage, etc). A well worded warning would prevent that.

In a way, I think warnings and undo serve two different functions-warnings are meant to inform the user of their action, and undos are meant to roll back actions taken.

Re: We lost 54k GitHub stars

#150

Post by calcifer »

jacobolus wrote: post #138
calcifer wrote: post #81

Earlier quoted context omitted.

> it also doesn't gaslight the person that starred a repo only for it to disappear from their list. It's honestly hilarious how the definition of 'gaslight' has expanded so dramatically in the past few years that it now means 'anything that confuses me'. For future reference, here's what it actually means [1]: > Psychological manipulation of a person usually over an extended period of time that causes the victim to q…

The origin of “gaslight” is a movie where a husband surreptitiously removes objects from the room, dims and brightens the lights, etc. and pretends the changes were just the wife’s imagination. https://en.wikipedia.org/wiki/Gaslight_(1944_film)#Plot Removing bookmarks from someone’s list without notification seems at least broadly comparable (in both cases, the victim is confused and might question their own memory,…

> albeit the action of an emotionless machine with a programming bug rather than a malicious human

Yes, if you remove a major part of the definition (intent) then it can fit whatever you want it to fit. Like Gino D'Acampo most famously said [1], if my grandmother had wheels, she would have been a bike.

[1]https://www.youtube.com/watch?v=A-RfHC91Ewc

Post reply on HN