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 are enough to get people to think about what they're doing, but this example clearly demonstrates that what's important is to use design not to scare (alone?), but to convey the information which makes a dangerous action dangerous as well. I also really like the fact that when the action isn't dangerous, the distractions ("Type this repo's name", etc) just go away. It's super intuitive, and (for a newbie designer like me) really helps build an intuition for various design principles put in action.
Lesson 2, which was to use soft deletes, is something I have more thoughts about. I assume that the cascading done on GitHub would be done on a FK constraint, but I'm not really sure how you'd do a "cascading soft delete" without making some kind of manual cascading logic? If anyone's aware of a standard way to accomplish this, please do let me know. Of course, the best way may just be to simplify the model so they aren't needed at all haha.
As designers and developers we've been given a chance to sharpen our toolkit. Thanks, HTTPie! You've gained a new star :)
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 - the author had to _type out_ the name of the repo they wanted deleted into the warning box. At that point, it's hard to believe the author when they claim that this one addition to the warning UI would have definitely stopped them when they weren't paying enough attention to notice they had typed the entirely wrong repo into the confirmation box.
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 not a super huge deal to recreate the server entry, but still annoying when you're in the middle of something and just realized what you did.
Honestly, just replacing the "Yes" button with the action being taken would be enough to improve this. "No / Disconnect" and "No / Remove". But my personal opinion is that disconnecting is not a destructive action unless there's an open transaction or running query. So the dialog box should be contextual on that scenario, and otherwise it should just disconnect.
"Disconnecting will cancel executing queries and rollback open transactions. Continue? No / Disconnect"
> While the author clearly feels bad about the fact that they've lost his community and that GitHub couldn'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.
Also, writing a solid blog post about a customer-service corner case and getting it to the top of news.ycombinator can be a great, if somewhat last-ditch, opportunity to escalate a problem.
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'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?
He did have to type "httpie/httpie" in the box to confirm, no? I'm rather surprised that that didn't snap him out of auto-pilot mode. There ought to have been a DING in the brain seeing that the repo this is being applied to was httpie/httpie?
OTOH, I haven't been in such a mode, so I really got no right to comment on this. Best wishes to the team -- that those who saw his post will restar/rewatch the repo -- and (fwiw) thanks for writing it up and making me even more paranoid (in a positive sense) about doing such destructive operations.
> The problem is that the box looks exactly the same for repos with no commits and stars and for repos with a decade-long history and 55k stargazers and watchers. And it says “Warning: this is a potentially destructive action.”
It seems a bit much to expect the website to show you a warning of different levels of severity depending on the stars a repos has, particularly when the standard message is pretty severe and explicit. It even makes you type the name of the repo you want to make private before proceeding - I don't see how that wouldn't make anyone snap out of autopilot. I sympathise with the author's misfortune but it is pretty hard to look at that warning dialog and conclude that he was not sufficiently warned of the consequences or given a chance to reflect.
I find it disappointing that all of the lessons supposedly learned from this ordeal are lessons for other people, not the author. Surely lesson #1 should have been "check what repo you're in before taking destructive actions".
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).
GitHub made a cardinal UX design sin here: never use a warning when you mean undo [1]. If they had given even a five minute grace period before starting the irreversible process of removing all the watchers, this wouldn’t have happened.
"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.
Apart from it being clear that the UI and the user using it could have been better, I don’t agree with criticism like “GitHub should obviously do x” or “this would be easily resolved if the action didn’t caused cascading deletes” and so on.
GitHub is a large and complex set of applications, and making changes like that is probably not trivial. It’s probably not a high priority either. This is the first time I’ve heard of this in the existence of GitHub, and while that doesn’t mean it has only happened once, I suspect it’s rarely a meaningful issue.
Solving problems like this at GitHub’s scale is often hard both due to the need to do things that matter more, and due to how entrenched database schemas and application architectures tend to be. I’m sure their migrations are plenty scary to manage, and doing it to alter behaviour when toggling privacy on a repository understandably wouldn’t be high on their list of reasons to perform one.
Aside from those concerns, I bet there are a lot of lines of code which assume stars exist for specific reasons. Once they can exist for another reason, you have to rewrite logic around that, rewrite tests for that logic, etc. It could easily be way more work than it seems at a glance.
Reminds me of our own quest to stop users from deleting their entire projects by accident in our product.
1st iteration: delete button with a confirmation box (standard stuff). Users click through the box in autopilot mode and still delete their entire projects.
2nd iteration: someone came up with an idea: confirmation box + an additional checkbox (if it isn't checked, the delete button is disabled). Users still manage to delete projects by accident. When we asked them how that happened (we've set up so many hurdles!), the user says, just like in the article, that they thought they were deleting a different (test) project.
3rd iteration: I suggested showing the number of objects in the project (just like suggested in the article) so that the user knew they aren't deleting a test project.
I moved on to a different project since, but the saga probably continues.
That's crazy that a manual error by someone, for whatever reason, end up being an article blaming Github for all sort of reasons. And never accepting that the thing that really failed here is the user who performed the action.
I have no dog in the fight here, and no affiliation to HTTPie, but this definitely seems like a Github issue to me. You can't just give users ways to easily and accidentally shoot themselves in the foot, and then blame the user for shooting themselves in the foot.
Having read through the article I'm really not getting the same vibes of Github being wholly blamed for this mistake - they clearly call out their own user error directly in the article but offer suggestions to make it less of an issue in the future. I got the sense that a long time user had went through a hellish week of trying to restore data and is feeling bitter but mostly just wants the product to improve.
With that mindset, planes would still fall out of the sky every month. Because basically 90% of plane crashes used to be "pilot error". If you then say, well, it was pilot error, bad pilot, can't do anything about it, that's the way it is, pilot should've not made an error... well, then we wouldn't have reached the amazing aviation safety we have now.
To borrow something from safety engineering - there is no such thing as an operator error, only bad user interfaces.
I definitely think this is github's fault for creating a system where an operator error is likely. OTOH stars are such a vanity metric that i can't be bothered to feel too sympathetic because who cares about stars?
What could the author have done with this post that would take it from being “blaming” into “giving feedback in an earnest intent to save others future pain”?
I suppose you never take a backup because everything should be in ideal conditions.
If you consider manual errors as non existent, you need to rethink your design.
How big is "clearly big"? Whenever someone makes the same mistake with a slightly-less-big repository should the warning thresholds be revised to also show up for those?
In America, we blame individuals when systems fail. We don't have to, we can actually design systems to be better. Design isn't just about making things look pretty. Good design reduces entropy.
Thankfully there are exceptions to this, notably aviation. Having all accidents investigated by an independent board with a systems approach has proven to be an extremely successful model. It's a shame it isn't replicated elsewhere.
It is a workman, who builds a very succesful tool for others. Not a bad workman by my definition.
And his suggestions of improving the UI sound very solid. Also I am not sure, if you got the part, where he pointed out, that Github themself made the same misstake for one if their repos. Sure, sure, all bad workman.
Maybe the UX is not great, but surely having to type "httpie/httpie" would have given me a pause.
Regardless, to make mistakes is human. What I don't really like is how the author starts attacking Github and Microsoft, just because they can't afford to fix the author's mistake. A huge red flag for me.
That's a meaningless statement, though, as it can always be used against anyone complaining about something. I mean, you yourself wrote this the other day:
> I had to work with SAP Hybris a year or two ago. My IDE was not smart enough. Well actually I spent a good number of days trying to configure my IDE to be able to work properly with Hybris. I failed. What a mess
Are you a bad workman blaming your tools? Or do some tools just genuinely have faults?
Completely disagree; when it comes to programming (where all tools are infinitely malleable), it’s a poor programmer who puts up with suboptimal tools.
I don't think he's blaming HN to the point where he's shirking responsibility for what he did. I read this post as a clever way to get play on HN which will help him get some of his stars/watchers back.
Couldn't agree more. The author not only messes up his own repo while blaming the GitHub UI, he proceeds to then whine that GitHub employees won't restore his data from a backup.
Additional context: a GitHub employee addresses why they didn't do a backup restore in this tweet:
> Yup, all watchers go when you go private and a bunch of notification settings etc. We've tried re-staring projects in the past etc but that ends up breaking lots of peoples notification settings. It's something we should make more reversible but hard for reasons <waveshand>
> It's the reason we display this when you try to do it. But a better fix would be for us to make it more easily reversible in the future.
I notice there are a lot of people in this comment section who either haven’t read the article at all, or haven’t read it in full. Worth reading the full post before commenting
Why care? Stars don't mean anything, save for the few people who organise the software they use by starring it.
Certainly it's not a community owned by the maintainers. I don't own a connection with the people that upvoted this post, and stars mean exactly the same (effectively nothing).
What an astonishingly poor design decision by GitHub. The intelligent design decision to making a repository private is to have private be a flag, and to have that privacy setting propagate down to the watcher level. Then, when a repository is made public again, all the watchers etc return.
Want to give users a way to remove all watchers? Great, make that /a separate action/ -- in no world and in no other application is it an intuitive UI/UX pattern to have make something private mean it gets deleted. That's absurd. Make private means "hidden for the indefinite future, but available to be made unhidden when I as a user see fit." That is the only reasonable definition I have ever seen (Instagram for example).
Whether you want to show a user that they watched a repository which is no longer public or simply have it disappear is up to the user, but I cannot understand why anyone thought that the straightforward solution was to /simply delete the data/. Between this and the now common downtime, I'm increasingly worried that GitHub is simply asleep at the wheel.
DevRel 101. If a project had 54k stars and they obviously made a mistake why take the chance of them writing a blog post and having it hit the front page on HN?
If Nat was still CEO this wouldn't have been a thing.
[+] [-] vaishnavsm|3 years ago|reply
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 are enough to get people to think about what they're doing, but this example clearly demonstrates that what's important is to use design not to scare (alone?), but to convey the information which makes a dangerous action dangerous as well. I also really like the fact that when the action isn't dangerous, the distractions ("Type this repo's name", etc) just go away. It's super intuitive, and (for a newbie designer like me) really helps build an intuition for various design principles put in action.
Lesson 2, which was to use soft deletes, is something I have more thoughts about. I assume that the cascading done on GitHub would be done on a FK constraint, but I'm not really sure how you'd do a "cascading soft delete" without making some kind of manual cascading logic? If anyone's aware of a standard way to accomplish this, please do let me know. Of course, the best way may just be to simplify the model so they aren't needed at all haha.
As designers and developers we've been given a chance to sharpen our toolkit. Thanks, HTTPie! You've gained a new star :)
Edit: Changed GitHub couldn't restore to GitHub didn't restore, as pointed out by @ncmncm (https://news.ycombinator.com/item?id=31033758#31034195)
[+] [-] cmeacham98|3 years ago|reply
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 - the author had to _type out_ the name of the repo they wanted deleted into the warning box. At that point, it's hard to believe the author when they claim that this one addition to the warning UI would have definitely stopped them when they weren't paying enough attention to notice they had typed the entirely wrong repo into the confirmation box.
[+] [-] jdmichal|3 years ago|reply
"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 not a super huge deal to recreate the server entry, but still annoying when you're in the middle of something and just realized what you did.
Honestly, just replacing the "Yes" button with the action being taken would be enough to improve this. "No / Disconnect" and "No / Remove". But my personal opinion is that disconnecting is not a destructive action unless there's an open transaction or running query. So the dialog box should be contextual on that scenario, and otherwise it should just disconnect.
"Disconnecting will cancel executing queries and rollback open transactions. Continue? No / Disconnect"
[+] [-] mherdeg|3 years ago|reply
Also, writing a solid blog post about a customer-service corner case and getting it to the top of news.ycombinator can be a great, if somewhat last-ditch, opportunity to escalate a problem.
[+] [-] benjaminjackman|3 years ago|reply
[+] [-] metaltyphoon|3 years ago|reply
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?
[+] [-] sriku|3 years ago|reply
OTOH, I haven't been in such a mode, so I really got no right to comment on this. Best wishes to the team -- that those who saw his post will restar/rewatch the repo -- and (fwiw) thanks for writing it up and making me even more paranoid (in a positive sense) about doing such destructive operations.
[+] [-] NoboruWataya|3 years ago|reply
It seems a bit much to expect the website to show you a warning of different levels of severity depending on the stars a repos has, particularly when the standard message is pretty severe and explicit. It even makes you type the name of the repo you want to make private before proceeding - I don't see how that wouldn't make anyone snap out of autopilot. I sympathise with the author's misfortune but it is pretty hard to look at that warning dialog and conclude that he was not sufficiently warned of the consequences or given a chance to reflect.
I find it disappointing that all of the lessons supposedly learned from this ordeal are lessons for other people, not the author. Surely lesson #1 should have been "check what repo you're in before taking destructive actions".
[+] [-] bsuvc|3 years ago|reply
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?
[+] [-] ghoomketu|3 years ago|reply
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.
[+] [-] sefrost|3 years ago|reply
[+] [-] jakelazaroff|3 years ago|reply
https://alistapart.com/article/neveruseawarning/
[+] [-] williamsmj|3 years ago|reply
[+] [-] paxys|3 years ago|reply
[+] [-] steve_adams_86|3 years ago|reply
GitHub is a large and complex set of applications, and making changes like that is probably not trivial. It’s probably not a high priority either. This is the first time I’ve heard of this in the existence of GitHub, and while that doesn’t mean it has only happened once, I suspect it’s rarely a meaningful issue.
Solving problems like this at GitHub’s scale is often hard both due to the need to do things that matter more, and due to how entrenched database schemas and application architectures tend to be. I’m sure their migrations are plenty scary to manage, and doing it to alter behaviour when toggling privacy on a repository understandably wouldn’t be high on their list of reasons to perform one.
Aside from those concerns, I bet there are a lot of lines of code which assume stars exist for specific reasons. Once they can exist for another reason, you have to rewrite logic around that, rewrite tests for that logic, etc. It could easily be way more work than it seems at a glance.
[+] [-] kgeist|3 years ago|reply
1st iteration: delete button with a confirmation box (standard stuff). Users click through the box in autopilot mode and still delete their entire projects.
2nd iteration: someone came up with an idea: confirmation box + an additional checkbox (if it isn't checked, the delete button is disabled). Users still manage to delete projects by accident. When we asked them how that happened (we've set up so many hurdles!), the user says, just like in the article, that they thought they were deleting a different (test) project.
3rd iteration: I suggested showing the number of objects in the project (just like suggested in the article) so that the user knew they aren't deleting a test project.
I moved on to a different project since, but the saga probably continues.
[+] [-] polote|3 years ago|reply
[+] [-] spiderice|3 years ago|reply
[+] [-] munk-a|3 years ago|reply
[+] [-] FabHK|3 years ago|reply
[+] [-] enlyth|3 years ago|reply
[+] [-] bawolff|3 years ago|reply
I definitely think this is github's fault for creating a system where an operator error is likely. OTOH stars are such a vanity metric that i can't be bothered to feel too sympathetic because who cares about stars?
[+] [-] mattcwilson|3 years ago|reply
[+] [-] Dylan16807|3 years ago|reply
That's a much bigger failure than clicking the wrong button.
[+] [-] shrimpx|3 years ago|reply
[+] [-] mekster|3 years ago|reply
[+] [-] wly_cdgr|3 years ago|reply
[+] [-] sschueller|3 years ago|reply
Humans make mistakes all the time. We build systems to try to mitigate these and build them better by learning from new mistakes.
[+] [-] dom96|3 years ago|reply
[+] [-] barrucadu|3 years ago|reply
[+] [-] HellsMaddy|3 years ago|reply
https://www.youtube.com/watch?v=Ra_0DgnJ1uQ
https://en.wikipedia.org/wiki/Human_factors_and_ergonomics
[+] [-] _moof|3 years ago|reply
[+] [-] davedx|3 years ago|reply
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.
[+] [-] FeepingCreature|3 years ago|reply
[+] [-] hutzlibu|3 years ago|reply
It is a workman, who builds a very succesful tool for others. Not a bad workman by my definition.
And his suggestions of improving the UI sound very solid. Also I am not sure, if you got the part, where he pointed out, that Github themself made the same misstake for one if their repos. Sure, sure, all bad workman.
[+] [-] kif|3 years ago|reply
Regardless, to make mistakes is human. What I don't really like is how the author starts attacking Github and Microsoft, just because they can't afford to fix the author's mistake. A huge red flag for me.
[+] [-] matsemann|3 years ago|reply
That's a meaningless statement, though, as it can always be used against anyone complaining about something. I mean, you yourself wrote this the other day:
> I had to work with SAP Hybris a year or two ago. My IDE was not smart enough. Well actually I spent a good number of days trying to configure my IDE to be able to work properly with Hybris. I failed. What a mess
Are you a bad workman blaming your tools? Or do some tools just genuinely have faults?
[+] [-] raldi|3 years ago|reply
[+] [-] abuggia|3 years ago|reply
[+] [-] fourseventy|3 years ago|reply
[+] [-] nosefrog|3 years ago|reply
> Yup, all watchers go when you go private and a bunch of notification settings etc. We've tried re-staring projects in the past etc but that ends up breaking lots of peoples notification settings. It's something we should make more reversible but hard for reasons <waveshand>
> It's the reason we display this when you try to do it. But a better fix would be for us to make it more easily reversible in the future.
https://twitter.com/martinwoodward/status/149333649025189478...
[+] [-] HL33tibCe7|3 years ago|reply
[+] [-] bearbin|3 years ago|reply
Certainly it's not a community owned by the maintainers. I don't own a connection with the people that upvoted this post, and stars mean exactly the same (effectively nothing).
[+] [-] auggierose|3 years ago|reply
Because people cannot judge for themselves if something is great or not, they always need proxies. It would be cool if we could somehow fix THAT.
[+] [-] ranguna|3 years ago|reply
[+] [-] capdeck|3 years ago|reply
[+] [-] yowlingcat|3 years ago|reply
Want to give users a way to remove all watchers? Great, make that /a separate action/ -- in no world and in no other application is it an intuitive UI/UX pattern to have make something private mean it gets deleted. That's absurd. Make private means "hidden for the indefinite future, but available to be made unhidden when I as a user see fit." That is the only reasonable definition I have ever seen (Instagram for example).
Whether you want to show a user that they watched a repository which is no longer public or simply have it disappear is up to the user, but I cannot understand why anyone thought that the straightforward solution was to /simply delete the data/. Between this and the now common downtime, I'm increasingly worried that GitHub is simply asleep at the wheel.
[+] [-] jdorfman|3 years ago|reply
If Nat was still CEO this wouldn't have been a thing.