9 ms·

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/1472439

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.
    - kevinforrestcon 5y ago
      Then don't "do" the delete, when the users "do" the delete. Pretend to do it, actually do it 24 hours later, and if they "undo" the delete within that time frame, just remove it from the delete queue process.
    - whym 5y ago
      I don't think any fork was deleted. 3.5k forks as of now vs 3.4k forks in January: https://web.archive.org/web/20220129022012/https://github.com/httpie/httpie https://web.archive.org/web/20220129022012/https://github.co... Many people won't notice some of their stars having disappeared, but many would be surprised to see their forks deleted without their consent, especially those that are not merely a mirror. People can have diverged forks after adding substantial changes without feeding them back to the original for a variety of reasons.
  - ncmncm 5y ago
    Just not deleting them in the first place, or not deleting them until explicitly asked to, would suffice, and would be, ultimately, less code. So, I am not buying the apologetics.
    - djur 5y ago
      It seems to me that services that pretend to delete data but don't actually do it are usually subject to criticism on Hacker News, not praise.
      - ncmncm 5y ago
        You did not read the comment you replied to. Why? And then, why reply?
      - vidarh 5y ago
        The issue tend to be services who are not upfront about it. "This is potentially really damaging, so in case it's a mistake we'll just hide it for 24 hours during which you can undo" or something to that effect would be sufficient.
- quacker 5y ago
  > 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.
  - mynameisvlad 5y ago
    > 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.
  - ncmncm 5y ago
    On one hand you have millions of users who each are obliged to walk on eggshells. On the other, you have a few Microsoft hacks who could easily do the right thing on behalf of those millions of users.
- chefandy 5y ago
  Pretty much agree— Universal human fallibility is not an avoidable moral failure, but looking down on those who've made, admitted, and taken responsibility for simple mistakes sure is. Unrealistic assumptions about people's attention, processing capability, and physical capabilities may be the greatest hurdle when trying to actually solve people's problems with software. It can even be a safety issue— consider the Therac 25 incident. That said, superlatives like "impossible" aren't realistic here. As long as an action is possible, it is also possible to fuck it up. The challenge screen does require typing in the repo name which is a pretty solid attention-getter. It would be nice to list the important side effects in big angry letters but I'll bet the list of side-effects that are important to some people would be pointlessly long. Maybe a sanity check requiring repos with extremes in certain metrics to get a sanity check from support first— but I have had some preeeeettty protracted response times from GitHub support.
  - wpietri 5y ago
    > The challenge screen does require typing in the repo name which is a pretty solid attention-getter. This is not quite correct. In requires inputting the repo name. It's attention-getting the first time. But recently with some colleagues as part of a handoff we went through 50+ repos and archived the irrelevant ones. Very quickly the person doing the actual archiving went from typing to just copy-pasting the repo names. For programmers, copy-pasting from one spot to another can become very mechanical. So I think this UI choice works well for something that is done very occasionally. But it's no better if people are in the habit. Whereas showing novel information about the cost of the choice would be helpful in breaking the routine. Then could then also make it so that they had to type something only when the operation has a high cost, and what they typed could be something not directly copy-pasteable.
    - chefandy 5y ago
      That's fine. The goals of designing a sanity check prompt to snap people out of autopilot are entirely different from goals you might have in a security system— their being defeatable isn't even a flaw. Jersey barriers vs rumble strips. If someone deliberately doing the same thing over-and-over can avoid the manual effort, that's fine. Their frustration would likely make them think about it less. You don't, and shouldn't get prompted to do the same thing using the API, either.
- klabb3 5y ago
  Yeah. A warning that can be pattern matched by a human brain, that is just a routine action, will result in autopilot behavior. Flipping early repo visibility is common, I assume. Flipping visibility of 100+ star repos is likely much less common. So having a separate warning in that case might help you snap out of autopilot due to novelty. A common knee-jerk reaction to "users aren't taking our warnings seriously" is making the warning look more scary and involving more (mechanical) steps – such as two confirmations instead of one. Well, that's pattern matchable and subject to desensitization. Like the article states, it's more efficient to instead show what you're about to remove, i.e. a summary of the content as opposed to an identifier, then you get both novelty and proportional scariness, depending on how "big" it is. https://en.m.wikipedia.org/wiki/Alarm_fatigue https://en.m.wikipedia.org/wiki/Alarm_fatigue
- deleted 5y ago
  [deleted]
- Proven 5y ago
- necovek 5y ago
  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, but they already had to type out full project path as confirmation. I do believe it would be better if Github allowed restoring data in the next few days (soft deletes ftw) once they hit this issue themselves in the past. And Github support should have recognized that this project is a special, out of ordinary project, and afforded it some engineering time to restore everything.
  - Conan_Kudo 5y ago
    > 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. 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.
xupybd 5y ago
Yeah, it's a different story when dealing with safety. With industrial machines you have to assume people will do the dumbest thing possible. Because someone will find a way to get crushed in a moving part if they can. You have safety fence after safety fence and regularly test that your lockouts work. If you don't do all of this and someone dies you can face very harsh legal penalties. We don't do this with software when the cost of failure is so much lower but we should still understand smart humans will make mistakes.
- jeffreygoesto 5y ago
  In software often the cost is paid by other people (your users) and you don't (want to) see them. How much did the Atlassian outage cost it's clients altogether? How much thereof will they need to compensate?
WalterBright 5y ago
My favorite is "let's imprison people who make mistakes". It doesn't stop mistakes, it just covers them up.
- db_admin 5y ago
  People are imprisoned when they are a danger to others or at risk of flight. Their time in prison is meant to reform them and help them back into society. The community is protected from further "mistakes" from a person, while allowing the person to learn not to make the same mistake again. At least that is the idea.
- ric2b 5y ago
  Some mistakes are accidents, some mistakes are made on purpose. The latter needs some kind of consequence in place to offset the benefits from purposefully making said mistakes.
jonahx 5y ago
There is also an audiobook version, for some reason not linked from there: https://www.amazon.com/Field-Guide-Understanding-Human-Error/dp/B07CY9SSF2/ref=sr_1_2?crid=Q7XTHD68JREF&keywords=The+Field+Guide+to+Understanding+%27Human+Error%27&qid=1649979068&sprefix=the+field+guide+to+understanding+%27human+error%27%2Caps%2C82&sr=8-2 https://www.amazon.com/Field-Guide-Understanding-Human-Error...
cmeacham98 5y ago
> 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. This is applicable to almost any activity: "Sure he was driving drunk, but the car's manufacturer should have prevented that from causing any damage!" I agree that GitHub should improve the design here - privating a '10 star / 1 week old' repo shouldn't be treated the same as privating a '50k star / 10 year old' repo. I don't mean to diminish the fact that GitHub's UI should be improved here. But the author needs to take some responsibility and realize they were ""driving distracted"", and not act like GitHub is 100% at fault here. Just because GitHub didn't act perfectly doesn't mean the author didn't make any mistakes.
- barrkel 5y ago
  Neither the author, nor anybody that I can see here, is saying that the author didn't make any mistakes. But what you are saying is that marginal effort to prevent mistakes is not worthwhile. Cars, to take your example, would not be as safe as they are today if they followed the principles you've shown in this post and the grandparent. And yes, even when driving drunk, which is illegal, is safer too - stay in lane, adaptive cruise control, automatic braking, etc. have all incrementally made even extremely ill-advised behaviours safer.
- NeutronStar 5y ago
react_burger38 5y ago
This idea - fixing systems that amplify mistakes into large, irreversible impacts-- is why I am against alcohol, marijuana and other mental-state altering drugs for recreational purposes. (I'm not talking about people who really need pain relief from cancer, amphetamines for ADHD, etc.) If no one in the world drank, smoked pot, or did drugs, how much better off would we all be? 100,000 deaths come from alcohol use every year in the United States alone[1]. That doesn't even account for countless cases of abuse, broken families, crime, and other negative effects of alcohol and drugs. So many people say "oh well it's fine if I do it, I'm responsible" but then at some point someone isn't fine and isn't as responsible as they think they are. [1] https://www.cdc.gov/alcohol/features/excessive-alcohol-deaths.html#:~:text=Excessive%20alcohol%20use%20is%20responsible%20for%20more%20than,of%202.8%20million%20years%20of%20potential%20life%20lost https://www.cdc.gov/alcohol/features/excessive-alcohol-death....
- naedish 5y ago
  An interesting thought experiment - how many of us would be here at all if not for alcohol? Ignoring butterfly effect aspects, the number of people who were only conceived due to decisions made under the influence of drugs would surely be very large even today, let alone prior to the availability of birth control.
- ufmace 5y ago
  I think that do-gooders who have a "Great New Idea" for how to make society better are 1000x more dangerous than any type of drug ever invented. People drunk on alcohol mostly fall asleep harmlessly. People drunk on power and how awesome their own ideas are launch prison-industrial complexes, dystopian enforcement schemes, wars, genocides, etc. It may be an even worse drug. People on drugs mostly have some awareness that their ideas aren't very good. But for those drunk on power, the fact that their same great idea has already been tried and led to total disaster is no cause for concern at all. You see, they're obviously smarter and better than the last batch of power-addicts who tried that, so they'll do it right this time. Heaven help us if we ever discovered a chemical intoxicant that was capable of making people that deluded.
- wpietri 5y ago
MichaelBurge 5y ago
The penalty for sin is death.
- dheera 5y ago
  What about cos?
  - pbhjpbhj 5y ago
    death + π/2
- JackFr 5y ago
  Romans 6:23 The wages of sin is death.
krick 5y ago
Is that book still worth to spend time reading if I do understand what you are saying and I hold the same views? I'm always hungry to learn something useful from books, but more often than not I find these hyped books ("The Checklist Manifesto" comes to mind) really annoying in that they make me spend a significant amount of time reading stupid "curious life stories" to bring across a point that can be expressed in a 3 word sentence, like "checklists are good". And it's even worse when these are trivial truths most sane people would agree on, which doesn't make the "advice" more actionable, because it's just much easier said than done. I mean, it would be disappointing to read it to find it summarizes exactly to what you just said.
- wpietri 5y ago
  It's an incredibly rich book. I learned a ton from it. Indeed, I avoided summarizing it here precisely because it's hard to sum up.
np_tedious 5y ago
From the product's perspective speaking in aggregate, that is entirely correct. From an individual user's perspective, you still need own your shit and avoid making these mistakes. You can't rely on everything you use having smart safeguards. There will always be dumb/careless users that a product should consider. There will always be suboptimal UI (we could've just as easily been talking about CLI database tools) that a user should watch out for
rob74 5y ago
But still, I also share the opinion that GitHub's UX for dangerous actions on a repository is currently already best in class, so blaming them for your mistakes is pretty unfair. To make your repo private, you have to: - click "change visibility" in the "Danger Zone" area of the settings. - select "make private" with an additional warning shown that you will lose all stars and watchers. Ok, maybe it should mention how many. - type the name of the repo into a box and then click "I understand, change repo visibility". And yes, sometimes it is important to expect humans to not make mistakes. For example, at railway crossings. Even if you drove over it 100 times and no train came, the 101th time you may still die if you don't check for a train before crossing.
- MrBlueIncognito 5y ago
  > And yes, sometimes it is important to expect humans to not make mistakes. For example, at railway crossings. Even if you drove over it 100 times and no train came, the 101th time you may still die if you don't check for a train before crossing. For somebody going through a railway crossing, yes, they shouldn't allow themselves to be prone any mistakes there. However, for the people involved in the construction of the railway crossing, they should certainly expect everyone to screw up and scrutinize the safety. We don't want to leave anything affecting livelihoods to chance. "On average, each year around 400 people in the European Union and over 300 in the United States are killed in level crossing accidents." https://en.wikipedia.org/wiki/Level_crossing#Safety https://en.wikipedia.org/wiki/Level_crossing#Safety
  - deleted 5y ago
    [deleted]
- dskloet 5y ago
  That's why a level crossing has a barrier that's only there when a train is approaching. Imagine the barrier was always there; that would be asking for people to ignore it.
iforgotpassword 5y ago
So, displaying an additional or more explicit warning that mentions stars and watchers makes sense. No arguing, hope they do that. But to me also, it left a little bit of a bad aftertaste that the author completely skips over the part of that process where you have to enter the repository name right where they show the two screenshots side by side. Anecdotal: You have to enter the full name for a couple destructive actions on GitHub, and every time I had to do it was so jarring to me that I stopped everything, rechecked what I'm doing twice, started wondering if I might be dreaming, am on drugs or a voice in my head is telling me to do something dumb. Like, yes we should improve nonetheless, and I usually try to put myself into other people's shoes before judging them, but this is just one of the few times where I just can't help but, you know, think it was somewhat dumb to make this mistake with the current system in place. Like, next time we have this stars and watchers warning in place and still someone will manage to proceed on autopilot, what do we do next? Have a siren sound go off in addition? Have the user enable their mic and spell out the repo name? Send a written letter to GitHub? You'll never get the error rate to 0, at which point would you rather accept people making mistakes and calling them out on it than adding more inconvenience on top that just bothers everybody else?
- bspammer 5y ago
  Most people in this thread seem to be ignoring another very major cause: the inconsistent naming for personal READMEs between users and organizations. Users have their README at username/username, but orgs have it at orgname/.github Nothing else on GitHub is like this: orgs and users are treated as the same class of entity pretty much all the time. I could easily see myself making the same mistake on autopilot.
  - _asummers 5y ago
    They have a bunch of differences under the hood, particularly when you want to give perms. It makes sense, sort of, on its face, that a user can’t have teams, but why? That decision is pretty arbitrary, to me. Then in GHE, users and orgs have all sorts of fun differences when you consider things like internal/public/private and how people can interact with them; to wit, if you’re in ANY team you can see ANY internal repo in an org, but if you’re limited to just personal repos, you can see no such things.
deleted 5y ago
[deleted]
josephjang 5y ago
It's not about whether human can make a mistake or not. It's about how much effort should be made to prevent a certain type of human mistakes. If every system we're interacting daily should be fool-proof, it will requires enormous time and effort. Naturally, we invests more time and effort when it's about life and death situation. If we only lose 2 cents by our mistake, we just don't care. Of course, I'd like to have more fool-proof design in all the destructive interactions from all websites. But, the question is, does it worth it?

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.
  - kevinforrestcon 5y ago
    Then don't "do" the delete, when the users "do" the delete. Pretend to do it, actually do it 24 hours later, and if they "undo" the delete within that time frame, just remove it from the delete queue process.
  - whym 5y ago
    I don't think any fork was deleted. 3.5k forks as of now vs 3.4k forks in January: https://web.archive.org/web/20220129022012/https://github.com/httpie/httpie https://web.archive.org/web/20220129022012/https://github.co... Many people won't notice some of their stars having disappeared, but many would be surprised to see their forks deleted without their consent, especially those that are not merely a mirror. People can have diverged forks after adding substantial changes without feeding them back to the original for a variety of reasons.
- ncmncm 5y ago
  Just not deleting them in the first place, or not deleting them until explicitly asked to, would suffice, and would be, ultimately, less code. So, I am not buying the apologetics.
  - djur 5y ago
    It seems to me that services that pretend to delete data but don't actually do it are usually subject to criticism on Hacker News, not praise.
    - ncmncm 5y ago
      You did not read the comment you replied to. Why? And then, why reply?
    - vidarh 5y ago
      The issue tend to be services who are not upfront about it. "This is potentially really damaging, so in case it's a mistake we'll just hide it for 24 hours during which you can undo" or something to that effect would be sufficient.
quacker 5y ago
> 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.
- mynameisvlad 5y ago
  > 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.
- ncmncm 5y ago
  On one hand you have millions of users who each are obliged to walk on eggshells. On the other, you have a few Microsoft hacks who could easily do the right thing on behalf of those millions of users.
chefandy 5y ago
Pretty much agree— Universal human fallibility is not an avoidable moral failure, but looking down on those who've made, admitted, and taken responsibility for simple mistakes sure is. Unrealistic assumptions about people's attention, processing capability, and physical capabilities may be the greatest hurdle when trying to actually solve people's problems with software. It can even be a safety issue— consider the Therac 25 incident. That said, superlatives like "impossible" aren't realistic here. As long as an action is possible, it is also possible to fuck it up. The challenge screen does require typing in the repo name which is a pretty solid attention-getter. It would be nice to list the important side effects in big angry letters but I'll bet the list of side-effects that are important to some people would be pointlessly long. Maybe a sanity check requiring repos with extremes in certain metrics to get a sanity check from support first— but I have had some preeeeettty protracted response times from GitHub support.
- wpietri 5y ago
  > The challenge screen does require typing in the repo name which is a pretty solid attention-getter. This is not quite correct. In requires inputting the repo name. It's attention-getting the first time. But recently with some colleagues as part of a handoff we went through 50+ repos and archived the irrelevant ones. Very quickly the person doing the actual archiving went from typing to just copy-pasting the repo names. For programmers, copy-pasting from one spot to another can become very mechanical. So I think this UI choice works well for something that is done very occasionally. But it's no better if people are in the habit. Whereas showing novel information about the cost of the choice would be helpful in breaking the routine. Then could then also make it so that they had to type something only when the operation has a high cost, and what they typed could be something not directly copy-pasteable.
  - chefandy 5y ago
    That's fine. The goals of designing a sanity check prompt to snap people out of autopilot are entirely different from goals you might have in a security system— their being defeatable isn't even a flaw. Jersey barriers vs rumble strips. If someone deliberately doing the same thing over-and-over can avoid the manual effort, that's fine. Their frustration would likely make them think about it less. You don't, and shouldn't get prompted to do the same thing using the API, either.
klabb3 5y ago
Yeah. A warning that can be pattern matched by a human brain, that is just a routine action, will result in autopilot behavior. Flipping early repo visibility is common, I assume. Flipping visibility of 100+ star repos is likely much less common. So having a separate warning in that case might help you snap out of autopilot due to novelty. A common knee-jerk reaction to "users aren't taking our warnings seriously" is making the warning look more scary and involving more (mechanical) steps – such as two confirmations instead of one. Well, that's pattern matchable and subject to desensitization. Like the article states, it's more efficient to instead show what you're about to remove, i.e. a summary of the content as opposed to an identifier, then you get both novelty and proportional scariness, depending on how "big" it is. https://en.m.wikipedia.org/wiki/Alarm_fatigue https://en.m.wikipedia.org/wiki/Alarm_fatigue
deleted 5y ago
[deleted]
Proven 5y ago
necovek 5y ago
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, but they already had to type out full project path as confirmation. I do believe it would be better if Github allowed restoring data in the next few days (soft deletes ftw) once they hit this issue themselves in the past. And Github support should have recognized that this project is a special, out of ordinary project, and afforded it some engineering time to restore everything.
- Conan_Kudo 5y ago
  > 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. 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.

xupybd 5y ago

Yeah, it's a different story when dealing with safety. With industrial machines you have to assume people will do the dumbest thing possible. Because someone will find a way to get crushed in a moving part if they can. You have safety fence after safety fence and regularly test that your lockouts work. If you don't do all of this and someone dies you can face very harsh legal penalties. We don't do this with software when the cost of failure is so much lower but we should still understand smart humans will make mistakes.

jeffreygoesto 5y ago
In software often the cost is paid by other people (your users) and you don't (want to) see them. How much did the Atlassian outage cost it's clients altogether? How much thereof will they need to compensate?

WalterBright 5y ago

My favorite is "let's imprison people who make mistakes". It doesn't stop mistakes, it just covers them up.

db_admin 5y ago
People are imprisoned when they are a danger to others or at risk of flight. Their time in prison is meant to reform them and help them back into society. The community is protected from further "mistakes" from a person, while allowing the person to learn not to make the same mistake again. At least that is the idea.
ric2b 5y ago
Some mistakes are accidents, some mistakes are made on purpose. The latter needs some kind of consequence in place to offset the benefits from purposefully making said mistakes.

jonahx 5y ago

There is also an audiobook version, for some reason not linked from there: https://www.amazon.com/Field-Guide-Understanding-Human-Error/dp/B07CY9SSF2/ref=sr_1_2?crid=Q7XTHD68JREF&keywords=The+Field+Guide+to+Understanding+%27Human+Error%27&qid=1649979068&sprefix=the+field+guide+to+understanding+%27human+error%27%2Caps%2C82&sr=8-2 https://www.amazon.com/Field-Guide-Understanding-Human-Error...

cmeacham98 5y ago

> 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. This is applicable to almost any activity: "Sure he was driving drunk, but the car's manufacturer should have prevented that from causing any damage!" I agree that GitHub should improve the design here - privating a '10 star / 1 week old' repo shouldn't be treated the same as privating a '50k star / 10 year old' repo. I don't mean to diminish the fact that GitHub's UI should be improved here. But the author needs to take some responsibility and realize they were ""driving distracted"", and not act like GitHub is 100% at fault here. Just because GitHub didn't act perfectly doesn't mean the author didn't make any mistakes.

barrkel 5y ago
Neither the author, nor anybody that I can see here, is saying that the author didn't make any mistakes. But what you are saying is that marginal effort to prevent mistakes is not worthwhile. Cars, to take your example, would not be as safe as they are today if they followed the principles you've shown in this post and the grandparent. And yes, even when driving drunk, which is illegal, is safer too - stay in lane, adaptive cruise control, automatic braking, etc. have all incrementally made even extremely ill-advised behaviours safer.
NeutronStar 5y ago

react_burger38 5y ago

This idea - fixing systems that amplify mistakes into large, irreversible impacts-- is why I am against alcohol, marijuana and other mental-state altering drugs for recreational purposes. (I'm not talking about people who really need pain relief from cancer, amphetamines for ADHD, etc.) If no one in the world drank, smoked pot, or did drugs, how much better off would we all be? 100,000 deaths come from alcohol use every year in the United States alone[1]. That doesn't even account for countless cases of abuse, broken families, crime, and other negative effects of alcohol and drugs. So many people say "oh well it's fine if I do it, I'm responsible" but then at some point someone isn't fine and isn't as responsible as they think they are. [1] https://www.cdc.gov/alcohol/features/excessive-alcohol-deaths.html#:~:text=Excessive%20alcohol%20use%20is%20responsible%20for%20more%20than,of%202.8%20million%20years%20of%20potential%20life%20lost https://www.cdc.gov/alcohol/features/excessive-alcohol-death....

naedish 5y ago
An interesting thought experiment - how many of us would be here at all if not for alcohol? Ignoring butterfly effect aspects, the number of people who were only conceived due to decisions made under the influence of drugs would surely be very large even today, let alone prior to the availability of birth control.
ufmace 5y ago
I think that do-gooders who have a "Great New Idea" for how to make society better are 1000x more dangerous than any type of drug ever invented. People drunk on alcohol mostly fall asleep harmlessly. People drunk on power and how awesome their own ideas are launch prison-industrial complexes, dystopian enforcement schemes, wars, genocides, etc. It may be an even worse drug. People on drugs mostly have some awareness that their ideas aren't very good. But for those drunk on power, the fact that their same great idea has already been tried and led to total disaster is no cause for concern at all. You see, they're obviously smarter and better than the last batch of power-addicts who tried that, so they'll do it right this time. Heaven help us if we ever discovered a chemical intoxicant that was capable of making people that deluded.
wpietri 5y ago

MichaelBurge 5y ago

The penalty for sin is death.

dheera 5y ago
What about cos?
- pbhjpbhj 5y ago
  death + π/2
JackFr 5y ago
Romans 6:23 The wages of sin is death.

krick 5y ago

Is that book still worth to spend time reading if I do understand what you are saying and I hold the same views? I'm always hungry to learn something useful from books, but more often than not I find these hyped books ("The Checklist Manifesto" comes to mind) really annoying in that they make me spend a significant amount of time reading stupid "curious life stories" to bring across a point that can be expressed in a 3 word sentence, like "checklists are good". And it's even worse when these are trivial truths most sane people would agree on, which doesn't make the "advice" more actionable, because it's just much easier said than done. I mean, it would be disappointing to read it to find it summarizes exactly to what you just said.

wpietri 5y ago
It's an incredibly rich book. I learned a ton from it. Indeed, I avoided summarizing it here precisely because it's hard to sum up.

np_tedious 5y ago

From the product's perspective speaking in aggregate, that is entirely correct. From an individual user's perspective, you still need own your shit and avoid making these mistakes. You can't rely on everything you use having smart safeguards. There will always be dumb/careless users that a product should consider. There will always be suboptimal UI (we could've just as easily been talking about CLI database tools) that a user should watch out for

rob74 5y ago

But still, I also share the opinion that GitHub's UX for dangerous actions on a repository is currently already best in class, so blaming them for your mistakes is pretty unfair. To make your repo private, you have to: - click "change visibility" in the "Danger Zone" area of the settings. - select "make private" with an additional warning shown that you will lose all stars and watchers. Ok, maybe it should mention how many. - type the name of the repo into a box and then click "I understand, change repo visibility". And yes, sometimes it is important to expect humans to not make mistakes. For example, at railway crossings. Even if you drove over it 100 times and no train came, the 101th time you may still die if you don't check for a train before crossing.

MrBlueIncognito 5y ago
> And yes, sometimes it is important to expect humans to not make mistakes. For example, at railway crossings. Even if you drove over it 100 times and no train came, the 101th time you may still die if you don't check for a train before crossing. For somebody going through a railway crossing, yes, they shouldn't allow themselves to be prone any mistakes there. However, for the people involved in the construction of the railway crossing, they should certainly expect everyone to screw up and scrutinize the safety. We don't want to leave anything affecting livelihoods to chance. "On average, each year around 400 people in the European Union and over 300 in the United States are killed in level crossing accidents." https://en.wikipedia.org/wiki/Level_crossing#Safety https://en.wikipedia.org/wiki/Level_crossing#Safety
- deleted 5y ago
  [deleted]
dskloet 5y ago
That's why a level crossing has a barrier that's only there when a train is approaching. Imagine the barrier was always there; that would be asking for people to ignore it.

iforgotpassword 5y ago

So, displaying an additional or more explicit warning that mentions stars and watchers makes sense. No arguing, hope they do that. But to me also, it left a little bit of a bad aftertaste that the author completely skips over the part of that process where you have to enter the repository name right where they show the two screenshots side by side. Anecdotal: You have to enter the full name for a couple destructive actions on GitHub, and every time I had to do it was so jarring to me that I stopped everything, rechecked what I'm doing twice, started wondering if I might be dreaming, am on drugs or a voice in my head is telling me to do something dumb. Like, yes we should improve nonetheless, and I usually try to put myself into other people's shoes before judging them, but this is just one of the few times where I just can't help but, you know, think it was somewhat dumb to make this mistake with the current system in place. Like, next time we have this stars and watchers warning in place and still someone will manage to proceed on autopilot, what do we do next? Have a siren sound go off in addition? Have the user enable their mic and spell out the repo name? Send a written letter to GitHub? You'll never get the error rate to 0, at which point would you rather accept people making mistakes and calling them out on it than adding more inconvenience on top that just bothers everybody else?

bspammer 5y ago
Most people in this thread seem to be ignoring another very major cause: the inconsistent naming for personal READMEs between users and organizations. Users have their README at username/username, but orgs have it at orgname/.github Nothing else on GitHub is like this: orgs and users are treated as the same class of entity pretty much all the time. I could easily see myself making the same mistake on autopilot.
- _asummers 5y ago
  They have a bunch of differences under the hood, particularly when you want to give perms. It makes sense, sort of, on its face, that a user can’t have teams, but why? That decision is pretty arbitrary, to me. Then in GHE, users and orgs have all sorts of fun differences when you consider things like internal/public/private and how people can interact with them; to wit, if you’re in ANY team you can see ANY internal repo in an org, but if you’re limited to just personal repos, you can see no such things.

deleted 5y ago

[deleted]

josephjang 5y ago

It's not about whether human can make a mistake or not. It's about how much effort should be made to prevent a certain type of human mistakes. If every system we're interacting daily should be fool-proof, it will requires enormous time and effort. Naturally, we invests more time and effort when it's about life and death situation. If we only lose 2 cents by our mistake, we just don't care. Of course, I'd like to have more fool-proof design in all the destructive interactions from all websites. But, the question is, does it worth it?