6 ms·

> The problem is that the box looks exactly the same for repos with no commits and stars and for repos with a decade-long history and 55k stargazers and watcher

> The problem is that the box looks exactly the same for repos with no commits and stars and for repos with a decade-long history and 55k stargazers and watchers. And it says “Warning: this is a potentially destructive action.” It seems a bit much to expect the website to show you a warning of different levels of severity depending on the stars a repos has, particularly when the standard message is pretty severe and explicit. It even makes you type the name of the repo you want to make private before proceeding - I don't see how that wouldn't make anyone snap out of autopilot. I sympathise with the author's misfortune but it is pretty hard to look at that warning dialog and conclude that he was not sufficiently warned of the consequences or given a chance to reflect. I find it disappointing that all of the lessons supposedly learned from this ordeal are lessons for other people, not the author. Surely lesson #1 should have been "check what repo you're in before taking destructive actions".

yreg 5y ago
I found this article interesting, exactly because "typing the name of the repo you want to make private before proceeding" seemed like a good solution to me as well. (Until now.) However, I can absolutely imagine doing the author's mistake and I think their UI improvement suggestion is great. To me the interface design lesson here is valuable. A recommendation to "check what repo you're in before taking destructive actions" has zero value, since everyone knows that already. --- Completely agreed on the second point though, it's weird to blame this mainly on GitHub.
- kolanos 5y ago
  It occurs to me that if your users are mindlessly doing repetitive things, no amount of "Are you sure?" or other hoop jumping is guaranteed to snap them out of it. Humans are pattern recognition machines. GitHub may be better off preventing a repo with this size of a following from being made private without a support request or something requiring a second party to confirm.
  - kif 5y ago
    At my company, we had like 3-4 steps, each with clear wording to cancel a subscription, and they had to type something in the end to confirm. Guess what? We still had tickets asking to restore their subscriptions :)
    - yreg 5y ago
      I was mesmerised how the Japanese train operators (and perhaps other similar workers) have to follow checklists where they physically point[0] at everything they are doing even when they are alone. Now I'm wondering whether this approach actually works. [0] - https://youtu.be/9LmdUz3rOQU?t=66 https://youtu.be/9LmdUz3rOQU?t=66
      - bmacho 5y ago
        I think that's a different matter. Using checklists to automate a task, and make sure you don't skip any is working. Random obstacles before dangerous acts IMO make little to no use. Before destroying a house a checklist can ensure that they checked if there are anyone in the building (i seriously have no idea how they do that), but requiring them to stand on one leg with pinched nose, I don't think that'd have any use.
  - yreg 5y ago
    Yes. Someone elsewhere in this thread suggested that it could be improved to make it impossible to make the repo private before you delete all the stars somewhere else in the UI, therefore breaking out of the pattern. Surely there are multiple solutions, but I think you distilled the essence well: make the truly dangerous action different to the learned repetition.
jjoonathan 5y ago
> It even makes you type the name More and more IT systems are starting to do this for more and more tasks. I understand why: it's a hell of a lot easier than implementing a trashcan, timed undo, joining in helpful data, etc, but man, one good session with a couple hundred resources that need to be deleted this way is enough to burn you out pretty hard on these. Also, systems that go for these lazy solutions tend also to go for the lazy solution of "just delete and recreate the resource" instead of implementing proper modify functionality. This compounds the problem. As if administrative tasks didn't already come with enough drudgery, now you have to constantly do the old timey school punishment of writing lines just to do your job. "Just add friction" is evil. Easy, but evil.
- BrandoElFollito 5y ago
  When doing such massive changes it may be worthwhile to consider using the API (requires some coding, but still faster then typing in the repo names)
  - jjoonathan 5y ago
    It wasn't github. There was no API, and if there had been, I would have been ill advised to trust it.
- wussboy 5y ago
  I have worked with an extremely complex system in the past (Genesys Engage telephony) and their configuration was so complex that changing even the most innocuous attribute in the most seemingly unrelated object could bring the system to its knees. As time went by they slowly started to “improve” the situation by constantly forcing you to click through a “changing this setting may have knock on effects to your system” banner…that they showed every time you changed anything. Making it completely useless for actually preventing you from harming your system and really just giving the impression they were trying to cover their butts legally. I hated working with that platform.
- behnamoh 5y ago
  > It even makes you type the name of the repo you want to make private before proceeding - I don't see how that wouldn't make anyone snap out of autopilot. If you're using Github's CLI tool, you can autoconfirm repo deletion so that you won't have to type the name ever again. It seems like if Github were to change their UI, they would need to somehow change their API as well.
dmitshur 5y ago
I’m wondering if you got a chance to see this part of the post: > […] I obviously had no intention to make httpie/httpie private. So, why then? > > The proximate cause was that I thought I was inside a different repo; […] What I actually intended to do was to hide the HTTPie organization’s profile README, […] > > 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. […] since I just wanted to repeat the same benign action on our organization’s profile, […] > > 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. For me, this part of the post really helps understand the context in which the mistake was made. The post is long so it is possible some people read other parts but missed this one.
- parkingrift 5y ago
  I did read that part. He or she had to exactly type out "httpie/httpie" to confirm the action. I don't know what else GitHub could do to prevent this. How much handholding does GitHub need to offer? People need to accept the consequences of their own actions. The amount of manual steps necessary to take httpie private is fairly substantial. This person was careless and learned a lesson on being careless.
  - scrollaway 5y ago
    Where do you see that they didn't accept the consequences of their own actions? They just wish it were different/better. There's no harm in that, and Github being used by millions of developers is a strong reason to make it just a little bit safer for even the rarer cases like these.
  - sunir 5y ago
    I don’t see the need for moralizing. They took responsibility, and offered GitHub money to help. They aren’t leaning in heavily to blame Github here. It’s fine to express the gulf of evaluation and execution that led to the error. It happened. There may not be any better known solutions at the moment to lower the risk any further. Calling them careless is also unjustified. They made a mental error processing the information. Whenever humans are involved there is a risk of illogical and bizarre mental errors in decision making because we are degenerating meat robots granted full agency. Shit happens. How we emotionally deal with it is the test of life as a human being.
Retric 5y ago
Warnings are vastly less useful than making such activities less dangerous. If you feel something needs get giant flashing warning messages perhaps make it reversible for a week.
- pc86 5y ago
  I don't know for sure but I think in some jurisdictions "hang on to this data you told me to delete for another week" would be a non-starter.
  - ratww 5y ago
    Which ones? Even in Europe there is ample time for replying and complying to GDPR requests. Way more than would be needed for this specific case.
  - playpause 5y ago
    They could simply offer a “move to trash” approach to get around any legal restrictions of the kind you are imagining. This would also be much nicer UX. Just click a button to delete something, and it says something like “This has has been moved to Trash, and will be permanently deleted in 30 days”. No big scary warnings needed. And you can still delete it immediately if you want (by emptying your trash afterwards) so it’s not in breach of any laws.
stonemetal12 5y ago
>he was not sufficiently warned of the consequences Like most computer warnings it was overly generic, it warned there are potential consequences, but never warned of the actual consequences. If the warning had said hey this is going to effect 55K stars and watchers, he would have known he was in the wrong spot. The problem is if you expect a generic warning then a generic warning doesn't actually warn. A specific warning is more likely to, but not guarantied to catch attention.
jasonlotito 5y ago
> It seems a bit much to expect the website to show you a warning of different levels of severity I've done this for personal projects. I don't see why GitHub can't do something similar. > It even makes you type the name of the repo you want to make private before proceeding No, it literally does not. Nor does this mean you fully understand the implications of what you are doing as explained in the article. > check what repo you're in before taking destructive actions The amount of checking and automation of things for non-destructive actions, you'll forgive someone for expecting a bit of extra automation that, in this case, literally costs less.
bocytron 5y ago
A developer at GH made the same mistake. It clearly means the UI is not working the way intended. On one hand, there's a UI change GitHub could implement that would greatly prevent this situation from happening again. On the other hand, one could try warn every github users that this situation can happen and to be carefull... Well I have my opinion on which would be most effective.
bmacho 5y ago
It seems a bit few to expect a website to show us which repository are we going to delete on the delete page, instead of hiding it (or not showing). Datas, charts, content, every info that it could gather, and it may matter. Name is not enough. Also I believe that asking us every day the ridiculously braindead act, to copy a text from here to there is more harmful than it helps, it just sets people to autopilot mode. Although I don't have any measures.
Thorentis 5y ago
The issue wasn't that the warning was different, it's that the user level README repo is named "username/username", but the organisation README is named "org/.githib". The person typed "org/org" on autopilot, thinking that orgs worked the same as users. This is a product inconsistency that is not immediately obvious and since there are product differences, the dialog for orgs vs users should definitely be different.

yreg 5y ago

I found this article interesting, exactly because "typing the name of the repo you want to make private before proceeding" seemed like a good solution to me as well. (Until now.) However, I can absolutely imagine doing the author's mistake and I think their UI improvement suggestion is great. To me the interface design lesson here is valuable. A recommendation to "check what repo you're in before taking destructive actions" has zero value, since everyone knows that already. --- Completely agreed on the second point though, it's weird to blame this mainly on GitHub.

kolanos 5y ago
It occurs to me that if your users are mindlessly doing repetitive things, no amount of "Are you sure?" or other hoop jumping is guaranteed to snap them out of it. Humans are pattern recognition machines. GitHub may be better off preventing a repo with this size of a following from being made private without a support request or something requiring a second party to confirm.
- kif 5y ago
  At my company, we had like 3-4 steps, each with clear wording to cancel a subscription, and they had to type something in the end to confirm. Guess what? We still had tickets asking to restore their subscriptions :)
  - yreg 5y ago
    I was mesmerised how the Japanese train operators (and perhaps other similar workers) have to follow checklists where they physically point[0] at everything they are doing even when they are alone. Now I'm wondering whether this approach actually works. [0] - https://youtu.be/9LmdUz3rOQU?t=66 https://youtu.be/9LmdUz3rOQU?t=66
    - bmacho 5y ago
      I think that's a different matter. Using checklists to automate a task, and make sure you don't skip any is working. Random obstacles before dangerous acts IMO make little to no use. Before destroying a house a checklist can ensure that they checked if there are anyone in the building (i seriously have no idea how they do that), but requiring them to stand on one leg with pinched nose, I don't think that'd have any use.
- yreg 5y ago
  Yes. Someone elsewhere in this thread suggested that it could be improved to make it impossible to make the repo private before you delete all the stars somewhere else in the UI, therefore breaking out of the pattern. Surely there are multiple solutions, but I think you distilled the essence well: make the truly dangerous action different to the learned repetition.

jjoonathan 5y ago

> It even makes you type the name More and more IT systems are starting to do this for more and more tasks. I understand why: it's a hell of a lot easier than implementing a trashcan, timed undo, joining in helpful data, etc, but man, one good session with a couple hundred resources that need to be deleted this way is enough to burn you out pretty hard on these. Also, systems that go for these lazy solutions tend also to go for the lazy solution of "just delete and recreate the resource" instead of implementing proper modify functionality. This compounds the problem. As if administrative tasks didn't already come with enough drudgery, now you have to constantly do the old timey school punishment of writing lines just to do your job. "Just add friction" is evil. Easy, but evil.

BrandoElFollito 5y ago
When doing such massive changes it may be worthwhile to consider using the API (requires some coding, but still faster then typing in the repo names)
- jjoonathan 5y ago
  It wasn't github. There was no API, and if there had been, I would have been ill advised to trust it.
wussboy 5y ago
I have worked with an extremely complex system in the past (Genesys Engage telephony) and their configuration was so complex that changing even the most innocuous attribute in the most seemingly unrelated object could bring the system to its knees. As time went by they slowly started to “improve” the situation by constantly forcing you to click through a “changing this setting may have knock on effects to your system” banner…that they showed every time you changed anything. Making it completely useless for actually preventing you from harming your system and really just giving the impression they were trying to cover their butts legally. I hated working with that platform.
behnamoh 5y ago
> It even makes you type the name of the repo you want to make private before proceeding - I don't see how that wouldn't make anyone snap out of autopilot. If you're using Github's CLI tool, you can autoconfirm repo deletion so that you won't have to type the name ever again. It seems like if Github were to change their UI, they would need to somehow change their API as well.

dmitshur 5y ago

I’m wondering if you got a chance to see this part of the post: > […] I obviously had no intention to make httpie/httpie private. So, why then? > > The proximate cause was that I thought I was inside a different repo; […] What I actually intended to do was to hide the HTTPie organization’s profile README, […] > > 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. […] since I just wanted to repeat the same benign action on our organization’s profile, […] > > 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. For me, this part of the post really helps understand the context in which the mistake was made. The post is long so it is possible some people read other parts but missed this one.

parkingrift 5y ago
I did read that part. He or she had to exactly type out "httpie/httpie" to confirm the action. I don't know what else GitHub could do to prevent this. How much handholding does GitHub need to offer? People need to accept the consequences of their own actions. The amount of manual steps necessary to take httpie private is fairly substantial. This person was careless and learned a lesson on being careless.
- scrollaway 5y ago
  Where do you see that they didn't accept the consequences of their own actions? They just wish it were different/better. There's no harm in that, and Github being used by millions of developers is a strong reason to make it just a little bit safer for even the rarer cases like these.
- sunir 5y ago
  I don’t see the need for moralizing. They took responsibility, and offered GitHub money to help. They aren’t leaning in heavily to blame Github here. It’s fine to express the gulf of evaluation and execution that led to the error. It happened. There may not be any better known solutions at the moment to lower the risk any further. Calling them careless is also unjustified. They made a mental error processing the information. Whenever humans are involved there is a risk of illogical and bizarre mental errors in decision making because we are degenerating meat robots granted full agency. Shit happens. How we emotionally deal with it is the test of life as a human being.

Retric 5y ago

Warnings are vastly less useful than making such activities less dangerous. If you feel something needs get giant flashing warning messages perhaps make it reversible for a week.

pc86 5y ago
I don't know for sure but I think in some jurisdictions "hang on to this data you told me to delete for another week" would be a non-starter.
- ratww 5y ago
  Which ones? Even in Europe there is ample time for replying and complying to GDPR requests. Way more than would be needed for this specific case.
- playpause 5y ago
  They could simply offer a “move to trash” approach to get around any legal restrictions of the kind you are imagining. This would also be much nicer UX. Just click a button to delete something, and it says something like “This has has been moved to Trash, and will be permanently deleted in 30 days”. No big scary warnings needed. And you can still delete it immediately if you want (by emptying your trash afterwards) so it’s not in breach of any laws.

stonemetal12 5y ago

>he was not sufficiently warned of the consequences Like most computer warnings it was overly generic, it warned there are potential consequences, but never warned of the actual consequences. If the warning had said hey this is going to effect 55K stars and watchers, he would have known he was in the wrong spot. The problem is if you expect a generic warning then a generic warning doesn't actually warn. A specific warning is more likely to, but not guarantied to catch attention.

jasonlotito 5y ago

> It seems a bit much to expect the website to show you a warning of different levels of severity I've done this for personal projects. I don't see why GitHub can't do something similar. > It even makes you type the name of the repo you want to make private before proceeding No, it literally does not. Nor does this mean you fully understand the implications of what you are doing as explained in the article. > check what repo you're in before taking destructive actions The amount of checking and automation of things for non-destructive actions, you'll forgive someone for expecting a bit of extra automation that, in this case, literally costs less.

bocytron 5y ago

A developer at GH made the same mistake. It clearly means the UI is not working the way intended. On one hand, there's a UI change GitHub could implement that would greatly prevent this situation from happening again. On the other hand, one could try warn every github users that this situation can happen and to be carefull... Well I have my opinion on which would be most effective.

bmacho 5y ago

It seems a bit few to expect a website to show us which repository are we going to delete on the delete page, instead of hiding it (or not showing). Datas, charts, content, every info that it could gather, and it may matter. Name is not enough. Also I believe that asking us every day the ridiculously braindead act, to copy a text from here to there is more harmful than it helps, it just sets people to autopilot mode. Although I don't have any measures.

Thorentis 5y ago

The issue wasn't that the warning was different, it's that the user level README repo is named "username/username", but the organisation README is named "org/.githib". The person typed "org/org" on autopilot, thinking that orgs worked the same as users. This is a product inconsistency that is not immediately obvious and since there are product differences, the dialog for orgs vs users should definitely be different.