551–560 of 697 posts
Earlier quoted context omitted.
Acknowledge their own agency and responsibility. Literally stop blaming with language like “GitHub deleted…”
How would you word that sentence and remain factual about the deletion?
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)."
Until the next post by someone else that missed that warning and suggest to make the warning blinking with a big font
Right? As in, "this will affect 0 stars" vs "this will affect 54,000 stars" is an informational difference. Calling out "this will affect all stars" (without specifying a number) doesn't break a user out of doing it to the wrong repo, since that message is the same in both cases.
Earlier quoted context omitted.
> That comparison spot the difference pic is really scary. I had to check it 2 times myself before I could spot that the last line is different. That's not the only difference. The other difference is that you also have to type the full repository name, including the organization name. If they wanted to delete the correct repository, they would have to type httpie/.github, but instead they typed httpie/httpie. It's u…
> That's not the only difference. The other difference is that you also have to type the full repository name, including the organization name. This is not true. We had an internal tool at a previous job that required you to type the name of a service's cluster into a field before deleting it. Automated deployments sometimes got left behind - and users would go in periodically and clean them up. If you watched folks,…
It does strike me as unfair that GitHub themselves made the exact same mistake but were able to fix it with database backups.
(Not weighing in on whether they still should have considered it or not, just observing that their claim that it costs an unacceptable amount may not be inconsistent with having restored a much less comparatively "hot" repo.)
[1] - https://web.archive.org/web/20201116172809/https://github.co...
That comparison spot the difference pic is really scary. I had to check it 2 times myself before I could spot that the last line is different. Now that you're on the HN's frontpage, hopefully somebody from Github upper management will see this and all will be good soon thanks to gold old HN (especially when they did the same thing themselves and restored it). Wish you the best.
In both cases the dialog clearly warns you, with bolded text, on a separate line, of the consequences of your actions. "We were in the top Xth percentile" makes the author sound like a complete tool and I have little sympathy for them, especially given they're already back to 3k stars. Expecting the dialog to say "now, you've got 50,000 stars, are you REALLY REALLY SURE?" is just infantile, but really matches the ove…
That's not in itself a huge problem, but in this case it was compounded with the fact that the generic repo he was acting on is named inconsistently for users vs organizations, and he had just done it on his user account. If I'm reading correctly, a user's profile readme repo is `/`, while for organizations it is `/.github`, and, crucially, `/` is almost always going to be the core project for that org.
So yes, the warning says you will lose all stars on the project, but in the moment it would have seemed (to a fallible human brain who was in a user-space context) that this was the right repo, whereas a "you will lose 54k stars" message would have broken the user out of that space.
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…
It sounds like you've never been part of an engineering organization (I know you have since you bring up unlimited budget ;) It is obviously possible to design a much better, contextual warning with (more) relevant details highlighted. How much time is usually set aside for those? And yet, it's never going to stop mistakes. And how many other places like these are there in a large service like GitHub? A much better w…
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…
I am surprised so many people treat losing stars as "dangerous": I can certainly emphatize with the designer coming up with this pop-up while looking at a sample project with 12 stars. Considering this project was out of ordinary in having 54k stars (article mentions being in top 80), they should not be surprised that their case is not top of mind. Sure, it would be nice to highlight the most destructive of actions,…
Lots and lots of websites and companies use the number of stargazers as a strangely important metric for success, so losing them can be really bad.
So yeah, github didn't do any extra effort to restore what's imo essentially a vanity metric. Makes sense to me ?
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…
If your whole job is to use power-tools, the fact of using power-tools by itself — scary to some — becomes benign for you. `rm -rf` isn't scary to type if you e.g. write CI scripts intended to run in sandboxes all day. Deleting a repo isn't scary if you delete a lot of pointless repos. A prompt that pops up to warn you that you're doing something potentially dangerous, when you know that what you're doing is benign,…
A well-intentioned PM then thought the fix was to alias rm and add prompts to confirm. They had a whole project to add this alias everywhere.
First it broke existing scripts all over the place. So they fixed them to auto apply the confirmation.
Cut to a few months later and someone rm-rf’d something again, ignoring the prompt (or maybe auto applying it).
So the PM wanted a better message and a second prompt.
People are well intentioned but I’ve seen this path of stupidity that doesn’t solve the problem but is an activity in response to a problem.
Contrarian opinion here. While things can always be better the Github UX is good enough here. I am reminded of an old phrase: “A bad workman always blames his tools.” At some point you just need to accept responsibility for your actions and stop blaming others.