14 ms·

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 au

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.

johnywalks 5y ago
> make sure you're not on autopilot when taking potentially dangerous actions Humans will be humans, we can't help it. Structures or systems that handle large amounts of user interactions should predict such use cases and design accordingly. a.k.a make them "idiot proof".
Abishek_Muthian 5y ago
> "make sure you're not on autopilot when taking potentially dangerous actions, on github or any website". Have the advertisements/sign-up/GDPR pop-ups trained us to 'engage autopilot to dismiss the pop-up' as soon as possible irrespective of its importance?
mherdeg 5y ago
My favorite example of this is that the cloudflare.com web UI has some extremely scary buttons, like a little "bypass CDN" button with a cloud on it that will rapidly increase traffic to your site 2-100x if you accidentally click. I mean this isn't exactly how it works. But it's a bit scary.
wpietri 5y ago
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/dp/1472439058 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.
- mynameisvlad 5y ago
  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 this was designed properly and in a way that made it clear that what you're about to do is actually dangerous and not "dangerous" like the other dozen times you've seen the same message.
  - icambron 5y ago
    That’s not quite it. The solution isn’t to stop them from doing it or warning them more aggressively; it’s to make it genuinely less dangerous. For example, make the stars all come back when you reverse the switch. Of course that’s a lot harder to do, since it’s a lot more than a UX change. So I’m not really slagging GitHub here. But it’s the right way to attack this problem.
    - everforward 5y ago
      The counterpoint is that tools like that can be abused. Just as a hypothetical, if I have an open source product and do something the community doesn't like, I can make the repo private til the storm blows over so people can't un-star it. The number of people that remember to un-star it a week or two later is going to be a lot less. I still think you're right, but it's not even as simple as UX and small backend changes. Allowing the repo owner to re-play other peoples' actions comes with complicated policy decisions. GitHub could make it so only support can restore those, but now they're in the awkward position of having to say when it's okay to restore and when it isn't. Still, it may be the best compromise.
    - mynameisvlad 5y ago
      True "Undo" is, IMO, a pipe dream for all but brand new projects. That will pretty much require you to rearchitect a decent chunk of anything that wasn't built with it explicitly in mind. In this case, I don't quite understand why stars and forks need to be deleted when switching visibility, since it seems like the two shouldn't be linked. I can star and fork my private repos just fine, so it seems like it was just easier to clear it out than to deal with RBAC at that level.
rhtgrg 5y ago
> 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 changing any UX. Essentially, it's a complete non-issue depending on whether Github cares about you. Would you like the police in your area to behave in this manner? I think not.
- jacobsenscott 5y ago
  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.
  - swiftcoder 5y ago
    > 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 On the other hand, you should really, really, really hope that GitHub has internal guardrails to prevent their engineers making cowboy edits to the production databases without manager approval.
    - jacobsenscott 5y ago
      Haven't worked there, but I assume one engineer just needs one other engineer to approve their PR. I would be pretty surprised if it was more robust that that.
      - swiftcoder 5y ago
        I haven't worked at GitHub either, but I did work at AWS, where a change to a production database required filing a detailed CM (change management form) with step-by-step details of the operations to be completed + monitoring criteria + rollback plans. That CM had to be approved by the senior eng staff of all affected teams, plus the full management chain, and in a high-profile issue like this, the PR/comms teams as well.
vaishnavsm 5y ago
Sure, I understand that. But I think, as a designer, I can't really control the actions of my users. I can only try to design such that I can get them closer to the action they want to take. From that perspective, I think adding the additional information to the warning UI would, if not solve the problem, at least get us one step closer to helping the user make the right decision. Tbh, when I've deleted repo's, I've mostly just copied the repo name and pasted it in the box. Careless of me? Definitely. Can GitHub change that carelessness? Probably not. Will a box that says "Stars: 54k" help? I think it'd help me, at the very least.
- saila 5y ago
  In addition to typing the repo name, maybe they should make you check a box for each type of item that will be deleted: [ ] Delete 54,000 stars? [ ] Delete 8,000 watchers? [ ] etc
  - ncmncm 5y ago
    Or just, you know, not delete anything until otherwise asked to. None of tha has anything essential to do with making the thing private.
    - prepend 5y ago
      Is the repo is private then it’s impossible for anyone to “follow” by starring or watching. There’s also an issue of taking a repo private, making changes when no one gets alerted, and making it public to make it harder for people to know what’s going on.
      - account42 5y ago
        > There’s also an issue of taking a repo private, making changes when no one gets alerted, and making it public to make it harder for people to know what’s going on. They could always notify watchers about the repo being made private.
  - 5y ago
oriki 5y ago
Yeah, but on the other hand, "don't make mistakes" isn't a meaningful or useful lesson.
- pishpash 5y ago
  Don't make this specific mistake is a very meaningful and useful lesson.
  - alpaca128 5y ago
    Yes. But without the possibility to undo mistakes you'll stand in ruins before you learned enough lessons. "Just don't make any mistakes" is the worst stance one can have in this context, it denies reality and only assures you're unprepared when (not if) something important goes wrong.
- wardedVibe 5y ago
  git clone good
abnry 5y ago
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.
- freedomben 5y ago
  that would break billions of scripts and confuse the hell out of hundreds of thousands or millions of users. Especially seems unnecessary since most distros ship an alias that makes the default `rm` command run with the `-I` or `-i` command.
  - abnry 5y ago
    Of course it is here with us to stay. The point is that if the initial design was different, there would be fewer headaches. We certainly have the power moving forward. And as discussed in the article, a prompt is not enough to deter a user doing something other than what they think they are doing.
  - mynameisvlad 5y ago
    > Especially seems unnecessary since most distros ship an alias that makes the default `rm` command run with the `-I` or `-i` command. I would say that makes things even worse. Because it's just training you to rely on -i/I as a sensible default. One day, you'll encounter that one distro that doesn't have that, and it'll be the time where you really wish it were.
    - freedomben 5y ago
      Hmm, interesting point. I removed that alias early personally in favor of giving due respect to rm (especially with a `-r`!), which is probably an indicator in your favor.
      - alecbz 5y ago
        I alias rm to `echo ‘use trash’`, and then use /bin/rm when it’s what I really want.
cycomanic 5y ago
I would argue that the fact that GitHub themselves made the same error really tells us that yes the UI makes it way to easy to do this. Considering the number of repos on GitHub I wouldn't be surprised if someone made the same error every a couple of weeks (but typically not with such high stakes). I would also say that post does not come across to me as he is only blaming GitHub.
makeitdouble 5y ago
On typing out the name of the resource, it is of course a way better check than just displaying it. I think it also was very efficient when there was only a few places using it, and the novelty made it attention focusing. Thing is, we type all day, and can type pretty much any string at a decent speed without putting much thought into it. Any of us must have mistakenly typed a full file path or API URL, just to realize it’s not the right machine or project after having typed it all. It just take 2 or 3s max after all. I think it becomes an arms race to get attention on important things, we can do better by focusing more on every single destructive operation. We can also avoid having too similar interfaces for completely different contexts.
- oriki 5y ago
  It's also worth mentioning that the name of the resource here was confusing - the author mentions that this happened because he mixed up how GitHub names profile READMEs for organizations vs users.
viscanti 5y ago
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).
- justinator 5y ago
  Interesting idea but what PII is stored with stars?
- alpaca128 5y ago
  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.
js2 5y ago
> 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". First of all, this is self-evident. But second of all and more importantly: it doesn’t scale. The reason we have blame-free postmortems is because people will always make mistakes, so we find ways to change process or design to minimize those mistakes. If you think you’ll never do something on autopilot, you’re fooling yourself.
- ahepp 5y ago
  It’s not a “blame free postmortem” though. The author is blaming GitHub for not sending him a handwritten letter from the CEO inviting him not to do the stupid thing he positively affirmed he wanted to do. The author also neglects to mention he had to type the full project name into a dialog box, which would be critical to any real postmortem. If typing the repo name into GitHub didn’t wake him up, why should we believe listing the number of stars would? The author said he thought he was in a different repo, but that makes no sense. The real lesson, imo, is for people obsessed with stars to set up permissions, use dedicated accounts, and not toy around with settings you know are dangerous before you’ve had your coffee. That’s a lot more reasonable than GitHub spending time to implement yet another warning box feature that the author has proved they can ignore regardless of how obvious GitHub makes it.
  - js2 5y ago
    The author is blaming GitHub for not sending him a handwritten letter from the CEO inviting him not to do the stupid thing he positively affirmed he wanted to do. Please, quote from the article where you read this. I don't see it. In the article I read, the author admits fault: > I accidentally made the project’s repository private for a moment. The author goes on to explain how they made the mistake. > What put me on the wrong path was an otherwise completely unrelated action: I had just done the same (i.e., hidden an empty README) on my personal profile by making jakubroztocil/jakubroztocil private. > GitHub’s conceptual model treats users and organizations as very similar entities when it comes to profiles and repos. In this context, and since I just wanted to repeat the same benign action on our organization’s profile, my brain switched to auto-pilot mode. > I didn’t realize at the moment there’s an inconsistency in the naming of this special repo containing profile READMEs and that it differs for users and organizations: name/name vs. name/.github. > That’s why I proceeded to make httpie/httpie private instead of httpie/.github without realizing my mistake. The author does not attempt to hide or misrepresent the GitHub UI that requires confirmation. They show it for both "httpie/httpie" and "httpie/.github". It does not matter that you have to type the repo name, because once you are on auto-pilot, you proceed past this step. In fact, the author doesn't admit it, but if he's like me, I'll bet they copy/pasted the name. Because the name alone is not sufficient. The author then goes on to suggest what might have kicked him out of auto-pilot. Providing more information about the repo other than just its name. The name alone is NOT sufficient. And they author shows some example UIs from their own software. Your suggestion: "The real lesson, imo, is for people obsessed with stars to set up permissions, use dedicated accounts, and not toy around with settings you know are dangerous before you’ve had your coffee." This simply does not scale. It would require everyone to learn the same lesson for themselves. I've been a sys admin and developer for over 25 years. People make mistakes. They make them all the time. Putting context-free (or minimal context in the case of the GitHub UI) "Are you sure?" dialogs in front of them does nothing to prevent mistakes. All the author is asking for is a bit more context from the GitHub UI to help the user realize the significance of their action. This would help future GitHub users to avoid the same error.
mkl 5y ago
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.
- prepend 5y ago
  I think of the burden on the typical use case and think the current prompts should be sufficient. What’s the star threshold? 1000? 5? I’d hate to now have to type in the number of watchers and stars as part of the private/delete/move/etc prompt for all the times I know what I’m doing. It’s a balance between punishing the non-stupid users vs protecting the stupid users. And people switch between these categories. I might be non-stupid today and stupid tomorrow.
_moof 5y ago
> make sure you're not on autopilot when taking potentially dangerous actions When it comes to repetitive or familiar actions, this is physically impossible. If a repeated action is dangerous you cannot use a human interrupting themselves as your only control. It just won't happen. Overall this is a classic UI design failure. In addition to the "people physically can't take themselves off autopilot" problem, the interface destroys the user's data without providing a way to get it back. It would take relatively little engineering effort to make this reversible.
barrkel 5y ago
"The user shouldn't be stupid" - which is what you're saying sounds like to my ears - is not an approach that scales well. Mistakes happen. It's better to have a really good Undo than a lot of confirmation dialogs.
derefr 5y ago
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, is a prompt that's crying wolf. You'll learn to tune it out.
- prepend 5y ago
  This is a good point and reminds me a story of many years ago when someone accidentally ran “rm -rf” on an important directory and caused a lot of work. 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.
  - Macha 5y ago
    Yeah, aliases for "rm" to "rm -i" I find are especially counter productive in this regard, as it conditions people to type rm -f after they get spammed to approve several hundred files while trying to delete a git checkout or node modules too many times.
rmbyrro 5y ago
> make sure you're not on autopilot when taking potentially dangerous actions If they're in autopilot, how are they going to "make sure"? Everyone has been in this spot several times. Those who didn't are just lucky. There's got to be external contingencies to protect people when they're in autopilot.
deleted 5y ago
[deleted]
ncr100 5y ago
I disagree because there is no UI to indicate you're in a special repo. And I blame GH for not considering this "large project maintainer" use-case. When I administered many VAX / UNIX machines waaay back, the terminals were all configured to be 'special' for the super user. It would have been HORRIFICALLY BAD if any command were executed unknowingly. GH does -not- distinguish for project sizes, so there is NO SUPPORT for its users in this way. Every feature is to be considered with the same "shotgun severity".
alasdair_ 5y ago
The problem is that this “seemingly obvious advice” is completely useless because it’s not actionable. It’s similar to saying “to avoid the mistake, just don’t make the mistake” To make a better system for every human, you can either try changing all the humans, or you can change the system that is supposed to serve them. One is easier than the other.
katbyte 5y ago
I recommend reading “the design of every day things”, it talks about this exact attitude and why it’s terrible.
d3nj4l 5y ago
Agreed, and I'm genuinely surprised that so many on HN are angry at GitHub when they already made it so hard to do this. The author explicitly mentions they were on autopilot - it would take a significantly more challenging barrier for them to not do the exact same thing no matter how many prompts GitHub put there. It does make sense for it to be more reversible, but I can also understand why GitHub doesn't want to put in the effort: this is a once in a year kind of incident and the resources required wouldn't be worth it compared to signal boosting, like they did on twitter. I, for one, would be extremely pissed if GitHub made it harder for me to do routine actions because there's a possibility of data loss. I signed up for that when I typed the repository name in.
- tyrfing 5y ago
  I intentionally did this very recently for a whole bunch of old repos (mainly because a Github bot decided to start emailing me weekly about vulnerabilities in stuff that has been untouched for nearly a decade) and was mildly annoyed at how inconvenient it was to make them private. I would have said the warnings are unnecessary overkill. It's quite amusing to read this so soon after.
  - d3nj4l 5y ago
    Same here - not too long ago I had to take a bunch of repositories private, and while I appreciated the prompt (I've dealt with destructive actions that have even less of a barrier before, and that sucks) it still was annoying to do that again and again.
- taink 5y ago
  The point the author makes is not that it should be more tedious to make private: they in fact suggest making it as tedious as it is only when you are on a new, non-massively-starred repository. Right now it is only tedious and not sufficiently alarming, is what people are saying.
remexre 5y ago
Also sudo mode, right? They had to authenticate to the whole website again too, before doing this!
pishpash 5y ago
Agreed, the swipe at Microsoft (with links he saved from who knows when!) was especially gratuitous. He mad. Don't write something public when bitter should be a lesson right after don't be on autopilot.
onion2k 5y ago
GitHub probably should show the stars in the warning UI In this particular case the stars would have been a useful clue, but in the majority of similar cases the wouldn't be any stars. It would be a useless and redundant signal.
- sjamaan 5y ago
  Number of forks, maybe? Or pull requests? Although those wouldn't disappear of course...
tluyben2 5y ago
It would be very rare to have lived through an IT career and not make one or two fatal autopilot mistakes. In the 90s and early 00s it was very easy to lose a production system because you did something wrong that you did 1000x times right before. And this is a modern version of it; for me, this should not happen; if I designed GitHub, these people giving stars and watch would get selected based on the visibility of the profile. That hardly costs anything and then the user can just switch between visible and invisible at will and not lose anything. But I have made many similar mistakes in the past which is why I don’t delete stuff usually anymore; I just flag it deleted and gdpr material I encrypt. I simply don’t want either software bugs, hacks or human error to cause any damage. With the cost of storage and the fact that I work only in b2b, this comes at virtually no cost but with a lot of happiness for both our users and myself.
JackFr 5y ago
I feel for the guy and what he says about user interfaces is all true, but the tone of the piece grates on me a little. “I take responsibility, but…” is not “I take responsibility.”
aasasd 5y ago
> the author had to _type out_ the name of the repo they wanted deleted Where does it say that they deleted any repo?
lucideer 5y ago
> obvious advice: "make sure you're not on autopilot That... isn't how "autopilot" (or humans in general) work(s).
pmontra 5y ago
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.
- josephjang 5y ago
  > But designers can be on auto-pilot too. You're blaming some people without any basis.
Aeolun 5y ago
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.
mro_name 5y ago
Yes, and as Don Norman puts it, Design is mostly on how to make errors non-catastrophic. No design nor training ever will abolish them. Humans err.
jagged-chisel 5y ago
> the author had to _type out_ the name of the repo I copy/paste the repo name every time I delete a repo on GitHub. Yeah, it’s still a minor impediment, but it’s definitely not “TYPE the account and repo name.”

johnywalks 5y ago

> make sure you're not on autopilot when taking potentially dangerous actions Humans will be humans, we can't help it. Structures or systems that handle large amounts of user interactions should predict such use cases and design accordingly. a.k.a make them "idiot proof".

Abishek_Muthian 5y ago

> "make sure you're not on autopilot when taking potentially dangerous actions, on github or any website". Have the advertisements/sign-up/GDPR pop-ups trained us to 'engage autopilot to dismiss the pop-up' as soon as possible irrespective of its importance?

mherdeg 5y ago

My favorite example of this is that the cloudflare.com web UI has some extremely scary buttons, like a little "bypass CDN" button with a cloud on it that will rapidly increase traffic to your site 2-100x if you accidentally click. I mean this isn't exactly how it works. But it's a bit scary.

wpietri 5y ago

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/dp/1472439058 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.

mynameisvlad 5y ago
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 this was designed properly and in a way that made it clear that what you're about to do is actually dangerous and not "dangerous" like the other dozen times you've seen the same message.
- icambron 5y ago
  That’s not quite it. The solution isn’t to stop them from doing it or warning them more aggressively; it’s to make it genuinely less dangerous. For example, make the stars all come back when you reverse the switch. Of course that’s a lot harder to do, since it’s a lot more than a UX change. So I’m not really slagging GitHub here. But it’s the right way to attack this problem.
  - everforward 5y ago
    The counterpoint is that tools like that can be abused. Just as a hypothetical, if I have an open source product and do something the community doesn't like, I can make the repo private til the storm blows over so people can't un-star it. The number of people that remember to un-star it a week or two later is going to be a lot less. I still think you're right, but it's not even as simple as UX and small backend changes. Allowing the repo owner to re-play other peoples' actions comes with complicated policy decisions. GitHub could make it so only support can restore those, but now they're in the awkward position of having to say when it's okay to restore and when it isn't. Still, it may be the best compromise.
  - mynameisvlad 5y ago
    True "Undo" is, IMO, a pipe dream for all but brand new projects. That will pretty much require you to rearchitect a decent chunk of anything that wasn't built with it explicitly in mind. In this case, I don't quite understand why stars and forks need to be deleted when switching visibility, since it seems like the two shouldn't be linked. I can star and fork my private repos just fine, so it seems like it was just easier to clear it out than to deal with RBAC at that level.

rhtgrg 5y ago

> 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 changing any UX. Essentially, it's a complete non-issue depending on whether Github cares about you. Would you like the police in your area to behave in this manner? I think not.

jacobsenscott 5y ago
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.
- swiftcoder 5y ago
  > 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 On the other hand, you should really, really, really hope that GitHub has internal guardrails to prevent their engineers making cowboy edits to the production databases without manager approval.
  - jacobsenscott 5y ago
    Haven't worked there, but I assume one engineer just needs one other engineer to approve their PR. I would be pretty surprised if it was more robust that that.
    - swiftcoder 5y ago
      I haven't worked at GitHub either, but I did work at AWS, where a change to a production database required filing a detailed CM (change management form) with step-by-step details of the operations to be completed + monitoring criteria + rollback plans. That CM had to be approved by the senior eng staff of all affected teams, plus the full management chain, and in a high-profile issue like this, the PR/comms teams as well.

vaishnavsm 5y ago

Sure, I understand that. But I think, as a designer, I can't really control the actions of my users. I can only try to design such that I can get them closer to the action they want to take. From that perspective, I think adding the additional information to the warning UI would, if not solve the problem, at least get us one step closer to helping the user make the right decision. Tbh, when I've deleted repo's, I've mostly just copied the repo name and pasted it in the box. Careless of me? Definitely. Can GitHub change that carelessness? Probably not. Will a box that says "Stars: 54k" help? I think it'd help me, at the very least.

saila 5y ago
In addition to typing the repo name, maybe they should make you check a box for each type of item that will be deleted: [ ] Delete 54,000 stars? [ ] Delete 8,000 watchers? [ ] etc
- ncmncm 5y ago
  Or just, you know, not delete anything until otherwise asked to. None of tha has anything essential to do with making the thing private.
  - prepend 5y ago
    Is the repo is private then it’s impossible for anyone to “follow” by starring or watching. There’s also an issue of taking a repo private, making changes when no one gets alerted, and making it public to make it harder for people to know what’s going on.
    - account42 5y ago
      > There’s also an issue of taking a repo private, making changes when no one gets alerted, and making it public to make it harder for people to know what’s going on. They could always notify watchers about the repo being made private.
- 5y ago

oriki 5y ago

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

pishpash 5y ago
Don't make this specific mistake is a very meaningful and useful lesson.
- alpaca128 5y ago
  Yes. But without the possibility to undo mistakes you'll stand in ruins before you learned enough lessons. "Just don't make any mistakes" is the worst stance one can have in this context, it denies reality and only assures you're unprepared when (not if) something important goes wrong.
wardedVibe 5y ago
git clone good

abnry 5y ago

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.

freedomben 5y ago
that would break billions of scripts and confuse the hell out of hundreds of thousands or millions of users. Especially seems unnecessary since most distros ship an alias that makes the default `rm` command run with the `-I` or `-i` command.
- abnry 5y ago
  Of course it is here with us to stay. The point is that if the initial design was different, there would be fewer headaches. We certainly have the power moving forward. And as discussed in the article, a prompt is not enough to deter a user doing something other than what they think they are doing.
- mynameisvlad 5y ago
  > Especially seems unnecessary since most distros ship an alias that makes the default `rm` command run with the `-I` or `-i` command. I would say that makes things even worse. Because it's just training you to rely on -i/I as a sensible default. One day, you'll encounter that one distro that doesn't have that, and it'll be the time where you really wish it were.
  - freedomben 5y ago
    Hmm, interesting point. I removed that alias early personally in favor of giving due respect to rm (especially with a `-r`!), which is probably an indicator in your favor.
    - alecbz 5y ago
      I alias rm to `echo ‘use trash’`, and then use /bin/rm when it’s what I really want.

cycomanic 5y ago

I would argue that the fact that GitHub themselves made the same error really tells us that yes the UI makes it way to easy to do this. Considering the number of repos on GitHub I wouldn't be surprised if someone made the same error every a couple of weeks (but typically not with such high stakes). I would also say that post does not come across to me as he is only blaming GitHub.

makeitdouble 5y ago

On typing out the name of the resource, it is of course a way better check than just displaying it. I think it also was very efficient when there was only a few places using it, and the novelty made it attention focusing. Thing is, we type all day, and can type pretty much any string at a decent speed without putting much thought into it. Any of us must have mistakenly typed a full file path or API URL, just to realize it’s not the right machine or project after having typed it all. It just take 2 or 3s max after all. I think it becomes an arms race to get attention on important things, we can do better by focusing more on every single destructive operation. We can also avoid having too similar interfaces for completely different contexts.

oriki 5y ago
It's also worth mentioning that the name of the resource here was confusing - the author mentions that this happened because he mixed up how GitHub names profile READMEs for organizations vs users.

viscanti 5y ago

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

justinator 5y ago
Interesting idea but what PII is stored with stars?
alpaca128 5y ago
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.

js2 5y ago

> 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". First of all, this is self-evident. But second of all and more importantly: it doesn’t scale. The reason we have blame-free postmortems is because people will always make mistakes, so we find ways to change process or design to minimize those mistakes. If you think you’ll never do something on autopilot, you’re fooling yourself.

ahepp 5y ago
It’s not a “blame free postmortem” though. The author is blaming GitHub for not sending him a handwritten letter from the CEO inviting him not to do the stupid thing he positively affirmed he wanted to do. The author also neglects to mention he had to type the full project name into a dialog box, which would be critical to any real postmortem. If typing the repo name into GitHub didn’t wake him up, why should we believe listing the number of stars would? The author said he thought he was in a different repo, but that makes no sense. The real lesson, imo, is for people obsessed with stars to set up permissions, use dedicated accounts, and not toy around with settings you know are dangerous before you’ve had your coffee. That’s a lot more reasonable than GitHub spending time to implement yet another warning box feature that the author has proved they can ignore regardless of how obvious GitHub makes it.
- js2 5y ago
  The author is blaming GitHub for not sending him a handwritten letter from the CEO inviting him not to do the stupid thing he positively affirmed he wanted to do. Please, quote from the article where you read this. I don't see it. In the article I read, the author admits fault: > I accidentally made the project’s repository private for a moment. The author goes on to explain how they made the mistake. > What put me on the wrong path was an otherwise completely unrelated action: I had just done the same (i.e., hidden an empty README) on my personal profile by making jakubroztocil/jakubroztocil private. > GitHub’s conceptual model treats users and organizations as very similar entities when it comes to profiles and repos. In this context, and since I just wanted to repeat the same benign action on our organization’s profile, my brain switched to auto-pilot mode. > I didn’t realize at the moment there’s an inconsistency in the naming of this special repo containing profile READMEs and that it differs for users and organizations: name/name vs. name/.github. > That’s why I proceeded to make httpie/httpie private instead of httpie/.github without realizing my mistake. The author does not attempt to hide or misrepresent the GitHub UI that requires confirmation. They show it for both "httpie/httpie" and "httpie/.github". It does not matter that you have to type the repo name, because once you are on auto-pilot, you proceed past this step. In fact, the author doesn't admit it, but if he's like me, I'll bet they copy/pasted the name. Because the name alone is not sufficient. The author then goes on to suggest what might have kicked him out of auto-pilot. Providing more information about the repo other than just its name. The name alone is NOT sufficient. And they author shows some example UIs from their own software. Your suggestion: "The real lesson, imo, is for people obsessed with stars to set up permissions, use dedicated accounts, and not toy around with settings you know are dangerous before you’ve had your coffee." This simply does not scale. It would require everyone to learn the same lesson for themselves. I've been a sys admin and developer for over 25 years. People make mistakes. They make them all the time. Putting context-free (or minimal context in the case of the GitHub UI) "Are you sure?" dialogs in front of them does nothing to prevent mistakes. All the author is asking for is a bit more context from the GitHub UI to help the user realize the significance of their action. This would help future GitHub users to avoid the same error.

mkl 5y ago

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.

prepend 5y ago
I think of the burden on the typical use case and think the current prompts should be sufficient. What’s the star threshold? 1000? 5? I’d hate to now have to type in the number of watchers and stars as part of the private/delete/move/etc prompt for all the times I know what I’m doing. It’s a balance between punishing the non-stupid users vs protecting the stupid users. And people switch between these categories. I might be non-stupid today and stupid tomorrow.

_moof 5y ago

> make sure you're not on autopilot when taking potentially dangerous actions When it comes to repetitive or familiar actions, this is physically impossible. If a repeated action is dangerous you cannot use a human interrupting themselves as your only control. It just won't happen. Overall this is a classic UI design failure. In addition to the "people physically can't take themselves off autopilot" problem, the interface destroys the user's data without providing a way to get it back. It would take relatively little engineering effort to make this reversible.

barrkel 5y ago

"The user shouldn't be stupid" - which is what you're saying sounds like to my ears - is not an approach that scales well. Mistakes happen. It's better to have a really good Undo than a lot of confirmation dialogs.

derefr 5y ago

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, is a prompt that's crying wolf. You'll learn to tune it out.

prepend 5y ago
This is a good point and reminds me a story of many years ago when someone accidentally ran “rm -rf” on an important directory and caused a lot of work. 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.
- Macha 5y ago
  Yeah, aliases for "rm" to "rm -i" I find are especially counter productive in this regard, as it conditions people to type rm -f after they get spammed to approve several hundred files while trying to delete a git checkout or node modules too many times.

rmbyrro 5y ago

> make sure you're not on autopilot when taking potentially dangerous actions If they're in autopilot, how are they going to "make sure"? Everyone has been in this spot several times. Those who didn't are just lucky. There's got to be external contingencies to protect people when they're in autopilot.

deleted 5y ago

[deleted]

ncr100 5y ago

I disagree because there is no UI to indicate you're in a special repo. And I blame GH for not considering this "large project maintainer" use-case. When I administered many VAX / UNIX machines waaay back, the terminals were all configured to be 'special' for the super user. It would have been HORRIFICALLY BAD if any command were executed unknowingly. GH does -not- distinguish for project sizes, so there is NO SUPPORT for its users in this way. Every feature is to be considered with the same "shotgun severity".

alasdair_ 5y ago

The problem is that this “seemingly obvious advice” is completely useless because it’s not actionable. It’s similar to saying “to avoid the mistake, just don’t make the mistake” To make a better system for every human, you can either try changing all the humans, or you can change the system that is supposed to serve them. One is easier than the other.

katbyte 5y ago

I recommend reading “the design of every day things”, it talks about this exact attitude and why it’s terrible.

d3nj4l 5y ago

Agreed, and I'm genuinely surprised that so many on HN are angry at GitHub when they already made it so hard to do this. The author explicitly mentions they were on autopilot - it would take a significantly more challenging barrier for them to not do the exact same thing no matter how many prompts GitHub put there. It does make sense for it to be more reversible, but I can also understand why GitHub doesn't want to put in the effort: this is a once in a year kind of incident and the resources required wouldn't be worth it compared to signal boosting, like they did on twitter. I, for one, would be extremely pissed if GitHub made it harder for me to do routine actions because there's a possibility of data loss. I signed up for that when I typed the repository name in.

tyrfing 5y ago
I intentionally did this very recently for a whole bunch of old repos (mainly because a Github bot decided to start emailing me weekly about vulnerabilities in stuff that has been untouched for nearly a decade) and was mildly annoyed at how inconvenient it was to make them private. I would have said the warnings are unnecessary overkill. It's quite amusing to read this so soon after.
- d3nj4l 5y ago
  Same here - not too long ago I had to take a bunch of repositories private, and while I appreciated the prompt (I've dealt with destructive actions that have even less of a barrier before, and that sucks) it still was annoying to do that again and again.
taink 5y ago
The point the author makes is not that it should be more tedious to make private: they in fact suggest making it as tedious as it is only when you are on a new, non-massively-starred repository. Right now it is only tedious and not sufficiently alarming, is what people are saying.

remexre 5y ago

Also sudo mode, right? They had to authenticate to the whole website again too, before doing this!

pishpash 5y ago

Agreed, the swipe at Microsoft (with links he saved from who knows when!) was especially gratuitous. He mad. Don't write something public when bitter should be a lesson right after don't be on autopilot.

onion2k 5y ago

GitHub probably should show the stars in the warning UI In this particular case the stars would have been a useful clue, but in the majority of similar cases the wouldn't be any stars. It would be a useless and redundant signal.

sjamaan 5y ago
Number of forks, maybe? Or pull requests? Although those wouldn't disappear of course...

tluyben2 5y ago

It would be very rare to have lived through an IT career and not make one or two fatal autopilot mistakes. In the 90s and early 00s it was very easy to lose a production system because you did something wrong that you did 1000x times right before. And this is a modern version of it; for me, this should not happen; if I designed GitHub, these people giving stars and watch would get selected based on the visibility of the profile. That hardly costs anything and then the user can just switch between visible and invisible at will and not lose anything. But I have made many similar mistakes in the past which is why I don’t delete stuff usually anymore; I just flag it deleted and gdpr material I encrypt. I simply don’t want either software bugs, hacks or human error to cause any damage. With the cost of storage and the fact that I work only in b2b, this comes at virtually no cost but with a lot of happiness for both our users and myself.

JackFr 5y ago

I feel for the guy and what he says about user interfaces is all true, but the tone of the piece grates on me a little. “I take responsibility, but…” is not “I take responsibility.”

aasasd 5y ago

> the author had to _type out_ the name of the repo they wanted deleted Where does it say that they deleted any repo?

lucideer 5y ago

> obvious advice: "make sure you're not on autopilot That... isn't how "autopilot" (or humans in general) work(s).

pmontra 5y ago

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.

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

Aeolun 5y ago

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.

mro_name 5y ago

Yes, and as Don Norman puts it, Design is mostly on how to make errors non-catastrophic. No design nor training ever will abolish them. Humans err.

jagged-chisel 5y ago

> the author had to _type out_ the name of the repo I copy/paste the repo name every time I delete a repo on GitHub. Yeah, it’s still a minor impediment, but it’s definitely not “TYPE the account and repo name.”