Live data from Hacker News

We lost 54k GitHub stars

httpie.io

241–250 of 697 posts

Re: We lost 54k GitHub stars

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

Let's assume that the stars don't go away when the repo is made private. There are a couple of options:

- The users can still see all their stars and find the private repo, which makes it not private.

- The users can't see all their stars, they can only see their stars for the public repos. There's no way to find or unstar a private repo that you starred while it was public. This would lead to the situation that if you unstar everything and make sure you have zero stars, you could wake up the next week with 1 starred repos, and then with 3 starred repos, because some repos went public again.

- The users can see all their stars, but the private ones lead to a 404, which would be perplexing for a greater number of people than the current behavior.

- All private repos that have been public at least once lead to a "this repo is now private" message, that would in practice allow anyone to make an index of all the private repos that were public at least once. And it would also allow anyone to know when a private repo that was private at least once is deleted.

I think the current behaviour is better than all of these options.

Re: We lost 54k GitHub stars

#242

Earlier quoted context omitted.

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…

> It's easy to be an armchair engineer and say "well, obviously, don't make this mistake in the future". It's sort of equally easy to say Github should do X or Y to improve the UX in this (rare?) case without actually knowing the effort or opportunity cost. Like maybe I'd rather Github figure out how to not have outages so frequently and how to not accidentally give people million+ dollar bills and such.

> Like maybe I'd rather Github figure out how to not have outages so frequently and how to not accidentally give people million+ dollar bills and such.

I doubt the engineers working on the stability issues or billing have anything to do with UX and vice versa. It's not like there's a singular focus that everyone at the company must prioritize above all else. Multiple people can work on multiple projects and not impact one another at all.

Re: We lost 54k GitHub stars

#243

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 ran into this in pgAdmin recently. When right-clicking on a server, the options to disconnect the server and remove the server are right next to each other. Clicking disconnect presents you with the following dialog box: "Are you sure you want to disconnect the server? No / Yes" Click remove presents you with the following dialog box: "Are you sure you want to remove the server? No / Yes" Good luck! I mean, it's no…

Would you consider submitting a patch?

Re: We lost 54k GitHub stars

#244
post #9

"It's their fault, they only showed 5 warning banners. A 6th one would have totally stopped me from doing this." If a "type your repository name to confirm" box still doesn't make you double check that you picked the right repository, what else can they even do?

Also seems a bit suspect that they had a "perfect UI/UX example" to show how they would have handled these dialogs. Is this whole thing an advertisement for HTTPie?

As much as I dislike the general tone of the blogpost (as well as specifics like expecting special treatment (ie restoring a backup) in exchange for money when 1) Github doesn't offer that as a standalone service and 2) that wasn't already in their contract), I don't see how the example UI is anything but a straight improvement.

Re: We lost 54k GitHub stars

#245
eh, github kinda sucks.

they should fix this, or at least pull username lists for stars/follows and give them to the user for followup.

if the user self hosted, they'd pull from their own backups. instead they trusted a third party and helped contribute to that third party's success. now it's that very success that the user contributed to that stands in the way of help resolving the user's problem.

shrugging and saying sorry is kinda pathetic.

Re: We lost 54k GitHub stars

#246

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

Interesting idea but what PII is stored with stars?

Re: We lost 54k GitHub stars

#247

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…

Having to also type out the number of stars you're deleting when it's above some threshold would probably eliminate the error. I think people who use git a lot are used to having the same or similar repository names in multiple contexts and locations (it's decentralised), so typing out the repository name, even though it includes the user/organisation, is not as severe-seeming as the designers thought. Confirming the consequences seems better than confirming the command.

Re: We lost 54k GitHub stars

#248
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 wonder how different the response from Github would be if this blog post was instead, "Oops, Github's confusing UI made me delete the entire project metadata... so since we're forced to start fresh we decided to move to Gitlab/sourcehut/etc."

httpie would never do this. Deleting their stars is already a blow for their community, but changing to another provider would kill it.

Re: We lost 54k GitHub stars

#249
post #198
post #89

Earlier quoted context omitted.

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.

How would stars and watchers work on a private repo, though?

Re: We lost 54k GitHub stars

#250
post #29

Earlier quoted context omitted.

I came in to say precisely this. It’s easy to point fingers after the fact but probably the person wouldn’t have checked regardless of the message in the dialog box. “They warned me but because I didn’t read the dialog box because it was too boring!

if you RTFA he did actually read the dialog box (which is where he found out that it would delete the stars) he just didn't notice the 1 line in a 30+ line generic modal. He accepts responsibility for what he did, but points out the very real opportunity to improve the UI/UX of a very destructive operation with real contextual data about what is about to be destroyed.

I did RTFA. I do not accept the excuse that he didn’t read it properly. He skimmed it because he thought it was the same box but it wasn’t. He even admits that it contained the exact information that he was looking for. I don’t see any way he can complain.
Post reply on HN