> 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".
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.
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.
Based on your phrasing I’m still not sure if you understand parent—yes, the author had to type “httpie/httpie”, but due to GitHub’s user-level README repo feature, _that specific repo name_ conventionally would be a README repo, which is what the author was trying to delete.
For example, my README repo is and must be called “glacials/glacials”; if I wanted to delete it that is what I would type, but if I were an organization and wanted to delete it, I would type something else. This different behavior between acting as a user vs. acting as an organization is what caught the author off-guard. They typed “httpie/httpie” and consciously thought “yes, I want to delete the README repo, which I know must have name httpie/httpie, so that’s definitely what I’d like to do, I’ll go ahead and type that”.
This is not absentmindedness, it is a misleading product inconsistency. Were it not for this, I would 100% agree with you.
Thank you for this explanation. I didn't know profile READMEs were a thing and have to be named the same as the user account. I can see how this could be confusing when the functionality is different between users and orgs.
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.
Honestly, they are blaming Github here. They included a whole "Lessons" section, which are complaints about Github's UI, then database design, then community support. I don't think we should be making fun of them for accidentally privating their repo, but I absolutely laughed at
>The dialog should be more contextual and, paraphrasing again, it should say “You’re about to kill 55,000 people.” That would’ve certainly made me pause.
> They aren’t leaning in heavily to blame Github here.
> Honestly, they are blaming Github here.
I think both of these statements can be true at the same time. They are taking much of the responsibility while also explaining how some aspects of Github's design are partly responsible for the outcome.
That's fair, there are two things that rub me the wrong way here. First being how big of a deal they're making about the github equivalent of bookmarks, stars are not a community, period. The more significant thing is that this industry runs on mv foobar foobar truncating foobar with no recourse short of forensics, github's confirmation flow is quite good. Sure it could be improved, but it's so much better than pretty much everything else we have to interact with that assigning responsibility to them for not sounding a klaxon in addition to requiring one to type in the exact name of what's being deleted is absurd.
It's not like they can just run a few SQL queries on prod and have the author PayPal them 10$.
They need to create a plan, cost estimate, risk assessment, get management/qa/security/SRE/... approvals, write the code, documentation, reviews, tests, run on prod, create invoice, etc. This means 10-20 people work for 1-2 days. I doubt that the author is willing to pay 20000-60000$ for this.
> That humble tool, which we open-sourced, quickly captured developers’ hearts and rapidly became one of the top projects on GitHub.
> We’ve raised a Seed Round ...
It's not hard to believe the seed round and the entire pitch of the commercial venture was tied to the star count, and it's not hard to believe that the author would drop $1/star to restore the count.
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.
Just my 2c.. GitHub, instead of the statement "All stars and watchers", can improve it by showing "All 54000 stars and 32000 watchers" will be deleted.
Funny thing is that I have never typed in a repo to delete. I always just copy/paste from the message. It's probably what the repo owner did. Perhaps Github should generate an image instead of using text that can be copied. That way they could help mitigate the copy/paste problem.
Honestly, no. Your type of attitude is how bad products get made: products that cater to the absolute lowest tech illiterate user. Products that hide and simplify every useful tool to the point of annoyance and disfunction. Github's warnings are plenty enough. It doesn't matter what Github did; this post would still be made, and you people would still be thinking of even more absurd ways to make the user not do something. At a certain point, a tool has to do the function you asked it to do.
As a UX designer, I don’t understand this attitude. Clearly there are things GitHub could do to improve the design here. That doesn’t mean it’s GitHub’s fault, mistakes can always happen.
This screen gives you pretty poor context for your action. You can’t so easily see things that normally tell you at a glance where you are. They also don’t offer a good preview of the action, or undo, which is how you normally make potentially destructive actions less dangerous. Instead they made a scary prompt, but since they use that solution a lot, users may get desensitized to it.
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.
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.
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.
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 :)
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.
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.
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.
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.
> 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.
>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.
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.
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.
> 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.
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.
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.
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".