> […] 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 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.
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.
>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.
> 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.
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.
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.
The article describes exactly what else they could do, including example screenshots from another app that does it.
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.
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.
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.
Surely there are multiple solutions, but I think you distilled the essence well: make the truly dangerous action different to the learned repetition.
Now I'm wondering whether this approach actually works.
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.
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.
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.
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.
If you feel something needs get giant flashing warning messages perhaps make it reversible for a week.
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.
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.
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.
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".