Now that you're on the HN's frontpage, hopefully somebody from Github upper management will see this and all will be good soon thanks to gold old HN (especially when they did the same thing themselves and restored it).
Wish you the best.
Now that you're on the HN's frontpage, hopefully somebody from Github upper management will see this and all will be good soon thanks to gold old HN (especially when they did the same thing themselves and restored it).
Wish you the best.
That's not the only difference. The other difference is that you also have to type the full repository name, including the organization name.
If they wanted to delete the correct repository, they would have to type httpie/.github, but instead they typed httpie/httpie.
It's unfortunate what happened, but without GitHub removing the possibility at all to delete repositories/change the visibility, I don't know what else they could have done to try to prevent it. It's really hard as a user to affect the wrong repository, as you are gonna have to mentally and literally pause to write out the organization name + repository (httpie/httpie in this case) and if that doesn't stop you, I don't think anything would.
As the author of the post suggests: Prominently spell out "This will remove 54,000 stars." vs. "This won't remove any stars (there are none yet)."
It almost certainly would help. When you attempt to delete a world of warcraft character you are prompted with the character's level, among other info. This is the biggest difference you'll see between the delete procedure for a level 1 alt with < 1 hr played and a level 80 (or w/e) character with >10,000 hr played if you've named them similarly.
Because of the relatively low character limit and the popularity of alts, this feature (delete character) gets a lot of use and misuse so it's reasonable to expect the developers to have put some thought in to it.
Right? As in, "this will affect 0 stars" vs "this will affect 54,000 stars" is an informational difference. Calling out "this will affect all stars" (without specifying a number) doesn't break a user out of doing it to the wrong repo, since that message is the same in both cases.
This is not true.
We had an internal tool at a previous job that required you to type the name of a service's cluster into a field before deleting it. Automated deployments sometimes got left behind - and users would go in periodically and clean them up.
If you watched folks, they would type the name of the cluster being deleted into that box UNTIL they had to do this many times in a row. As soon as it was a "batch" job, folks would go through the motion of:
1. click delete
2. double click service name
3. ctrl+c
4. click text input
5. ctrl+v
6. press "Confirm"
It was remarkable, after someone did this once, I don't think I ever observed them going back to typing in the cluster name. That algorithm of "copy and paste" carried over into every prompt they saw of that form moving forward.
I'm guilty of this too - I no longer type the prompted name for this form of confirmation dialogue, it's a copy-and-paste.
Humans will always take the easiest route. We just have to accept that and come up with better solutions that aid humans or fit to our very weird nature.
You and most of the rest of us, I suspect. Like I want to type that out every time...
The community was valuable to GitHub as well.
I could see a spec on “sizable community thresholds” where if an interaction might blow away something of that size GH affords you an exchange with a “concierge” forcing a minor exchange with a real person.
Most of the time that's true, or we'd be hearing about this happening all of the time. But 'most of the time' is not 'every time'. 'Almost always' is also not 'every time'. This is a distinction that Human Factors people make that victim-blaming nerds do not.
You've seen the video on Youtube (or Reddit) of the guy holding the fish throwing his phone into the lake? He didn't do that because he was stupid, he did it because he made an executive decision to, "hold fish, take picture with phone, throw it in the water" and then his motor cortex swapped 'it' to the wrong hand and went on autopilot.
If you don't like that example, I know of a highly secure data center in Seattle that had the emergency power cutoff button pushed not once but twice by different tenants. The first time was a pure accident of bumping it while doing maintenance. The second time someone opened an acrylic case and pushed the button because they thought "buttons open doors, I see a button. Sure is weird that it is covered with a box... hey why did the lights go out?" You have problem, you observe action or object that solves problems (maybe not this problem), monkey brain attempts action to see if problem is solved.
Typing in the repository name narrows the gap between intent and action, but it doesn't close it. Technically making someone type, "Make hippie/hippie private" would at least make them spell out the intent, narrowing it again. But it doesn't make them state the intent. Strictly speaking, they are being told to transcribe text. Whether they parse the text they're typing or not is a separate step, in two different parts of the brain. Any of those fails to connect and you have a catastrophic destruction. From a Precautionary Principle standpoint, the consequences are exactly the same with all three options, and only the likelihood has changed.
If you want to make a big dent in outcomes you have to also reduce the consequences, not just the opportunity. Making all actions reversible is the most conceptually simple and the most technically difficult option. Parceling out consequences over time is usually less difficult, and if you pick an order that makes the feedback immediate, then the person realizes quickly that what they meant and what they said didn't line up, before the real damage kicks in.
Github is built around git. The two biggest ways to permanently lose data from git, one of them is protected by permissions and may be off by default. The other one is automatic but takes 30 days. That's two very different precedents that have been set, and they picked the wrong one to emulate.
No, you don't have to type it, and I doubt anyone types it. You copy that line and paste it. Often it's done on autopilot, especially when in a rush.
In famous words of Mr. Larry wall, 3 great virtues of every programmer: laziness, impatience, and hubris.
It’s typically short short, and it’s a very destructive action. It’s also very apparent to me why I would want to type it out.
That said, someone is going to make a mistake at some point. I’d expect better from github support here.
A lot of us navigate by typing, be it CLI, in our IDE, URLs etc. And we must have got used to type hundreds of times our company or project names every day, in many places.
I can't imagine typing <project name>/<project name> in a input box triggering in us a lot consciousness or extra care. Typing something more unusual could actually be more impacting I think.
"We were in the top Xth percentile" makes the author sound like a complete tool and I have little sympathy for them, especially given they're already back to 3k stars.
Expecting the dialog to say "now, you've got 50,000 stars, are you REALLY REALLY SURE?" is just infantile, but really matches the overall tone the author has.
That's not in itself a huge problem, but in this case it was compounded with the fact that the generic repo he was acting on is named inconsistently for users vs organizations, and he had just done it on his user account. If I'm reading correctly, a user's profile readme repo is `<user>/<user>`, while for organizations it is `<org>/.github`, and, crucially, `<org>/<org>` is almost always going to be the core project for that org.
So yes, the warning says you will lose all stars on the project, but in the moment it would have seemed (to a fallible human brain who was in a user-space context) that this was the right repo, whereas a "you will lose 54k stars" message would have broken the user out of that space.