They do raise a good point about the UI though, explicitly showing &quot;you&#x27;re about to nuke 55k people, are you sure?&quot; would make the user pause.

Who got shot in the foot here? The article keeps talking about killing 55 thousand people. I’m trying to grok why “unstarring the repo” is such an earthshattering thing. It’s annoying if you wanted it starred &#x2F; wanted notifications, because you have to notice and redo it… but there’s no irreparable harm, no data loss.This reads like somebody was placing way too much personal mental value on “the repo for my project has a large number of stars”

It&#x27;s not so easy to make this accident - one needs to type the full name of the repository. AWS does the same, for example, when deleting RDS instances, and I find it effective.

I have no dog in the fight here, and no affiliation to HTTPie, but this definitely seems like a Github issue to me.  You can&#x27;t just give users ways to easily and accidentally shoot themselves in the foot, and then blame the user for shooting themselves in the foot.

It is a big failure by github that making a repo private immediately and irrevocably destroys all the stars.That&#x27;s a much bigger failure than clicking the wrong button.

Having read through the article I&#x27;m really not getting the same vibes of Github being wholly blamed for this mistake - they clearly call out their own user error directly in the article but offer suggestions to make it less of an issue in the future.  I got the sense that a long time user had went through a hellish week of trying to restore data and is feeling bitter but mostly just wants the product to improve.

Likewise, surgical deaths. The number of people dying on the operating table is in sharp decline because hospitals have lately begun to institute procedures that make mistakes non-fatal.An early one was making the &quot;oxygen&quot; knob on the anesthetist&#x27;s gas panel not go to zero. But it appears lots of people here can&#x27;t imagine why that change was made.

Pilots and doctors are two great examples of customer pools where UI&#x2F;UX actually gets a significant amount of attention because we all realize how high the stakes are. I imagine the FDA has zero tolerance for vendor software that is bundled with dark patterns that encourages doctors to promote the prescription of certain drugs over others... at the same time we have quizzes that have made it to HN multiple times[1] that reinforce the &quot;correctness&quot; of dark patterns.UI&#x2F;UX often gets overlooked as being unimportant, and, as a backend person I can definitely sympathize, but when you&#x27;re building a product that people use for important things it is important to give UI&#x2F;UX the attention it deserves.1. <a href="https:&#x2F;&#x2F;cantunsee.space&#x2F;" rel="nofollow">https:&#x2F;&#x2F;cantunsee.space&#x2F;</a>

I think there might be a difference between losing a plane and losing your “GitHub stars”.

Planes have plenty of ways you can deliberately turn off systems and kill everyone on board. And they require less work that having to retype a whole text into a confirmation box.You missed that besides fixing UX, we also train pilots to think about their actions, talk to copilots about their actions, take responsibility for their actions and most importantly, not to press buttons on &quot;autopilot&quot;.That&#x27;s a completely different situation and defending learned stupidity of just clicking ok to everything.

With that mindset, planes would still fall out of the sky every month. Because basically 90% of plane crashes used to be &quot;pilot error&quot;. If you then say, well, it was pilot error, bad pilot, can&#x27;t do anything about it, that&#x27;s the way it is, pilot should&#x27;ve not made an error... well, then we wouldn&#x27;t have reached the amazing aviation safety we have now.

Drop passive aggressive comments like the one about how they&#x27;re going to stop wearing their GitHub T-Shirt because of how GitHub subjected them to the same treatment that lesser and more unworthy projects would have received.Even using words like &quot;future pain&quot; is pretty crazy. &quot;We lost 54k GitHub stars&quot;? They&#x27;re imaginary internet points! Cope.

Acknowledge their own agency and responsibility.Literally stop blaming with language like “GitHub deleted…”

What could the author have done with this post that would take it from being “blaming” into “giving feedback in an earnest intent to save others future pain”?

Github UX team has a responsibility to its customers to make this error MUCH harder to make than it is

I suppose you never take a backup because everything should be in ideal conditions.
If you consider manual errors as non existent, you need to rethink your design.

It&#x27;s true that this is &quot;PEBKAC&quot; but it&#x27;s also true that this is a UX&#x2F;system design failure on GitHub&#x27;s part.

To borrow something from safety engineering - there is no such thing as an operator error, only bad user interfaces.I definitely think this is github&#x27;s fault for creating a system where an operator error is likely. OTOH stars are such a vanity metric that i can&#x27;t be bothered to feel too sympathetic because who cares about stars?

In a normal organization where stuff like this happens one has backups since one runs these things internally.Humans make mistakes all the time. We build systems to try to mitigate these and build them better by learning from new mistakes.

That&#x27;s crazy that a manual error by someone, for whatever reason, end up being an article blaming Github for all sort of reasons. And never accepting that the thing that really failed here is the user who performed the action.

Or simply automate the restoration! They know how to do it! Make it easy!

I&#x27;m just surprised that after going through that pain themselves they didn&#x27;t decide to revise how that social linking data is handled. A lot of github content is softly deleted by necessity, you couldn&#x27;t nuke tickets written by a now non-existent user or unmerge PRs so this isn&#x27;t really a new concept to the team.I don&#x27;t think it&#x27;s surprising they&#x27;d do such a thing for themselves and not a customer - I&#x27;m more surprised they didn&#x27;t remove the footgun for future mistakes on their part.

I get that, but they probably shouldn&#x27;t have publicized the remediation via a public tweet if it&#x27;s an avenue that&#x27;s closed to the rest of us plebs (since in cases like this, it really feels like salt in the wound).

Internal vs External support.Internal support is inherently limited: the single organization is of limited size.External support has no limit in scope, you have to setup SOPs (Standard Operating Procedures), communicate expectations, likely hire support staff...Look at it this way: internal support is helping your friends, but external support requires setting up contracts.

There is no way in the world that the kind of person who writes a post like this and clearly places so much emphasis on gamified social media stats as a proxy for self-validation ever chooses to move to Sourcehut.  No way.  GitLab is most likely out of the question, too.  The author of this post is exactly the kind of ideal customer for what GitHub is &quot;selling&quot; and that the others can&#x27;t provide.

httpie would never do this. Deleting their stars is already a blow for their community, but changing to another provider would kill it.

I wonder how different the response from Github would be if this blog post was instead, &quot;Oops, Github&#x27;s confusing UI made me delete the entire project metadata... so since we&#x27;re forced to start fresh we decided to move to Gitlab&#x2F;sourcehut&#x2F;etc.&quot;

Or, knowing that it&#x27;s the only way they have to recover from this situation, they could make the process easier to do and price it out as a service.

Just as AceJohnny said, the scope of this is entirely different. Restoring a backup for an internal project costs time&#x2F;resources that the company can easily handle. If it became a problem it would be easy for github to tell their internal projects &quot;No, we&#x27;re no longer restoring from backups&quot;Opening up the ability to do that externally would potentially require multiple people working full-time to handle the requests.&quot;We even offered GitHub financial compensation for any resources required.&quot; Considering the tone of the article I think there&#x27;s a very high risk if github accepted agreed to that we&#x27;d see an article titled &quot;Github charges popular open source project $5000 to fix a minor accident&quot;

It&#x27;s your customer (repo owners) asking for support and throwing it away being busy is just lazy attitude. You had prior incidents and the bugs were left as is and apparently it will happen again.

When you think about it, it seems reasonable, I think about what would happen if it were me.If I was working at GitHub, and I nuked something, then the rest of my day would be un-nuking that thing. On the other hand if I was working on something totally unrelated, and then you my PM came to me and said &quot;can you stop what you&#x27;re doing and unfuck this thing&quot; it would obviously depend on what I was working on.

It would strike me even more unfair if GitHub fixed this mistake only for customers they like.

I would observe that even today, the GH desktop repo has only 14k stars, and at the time, archive.org says only 2.6k[1] - so I would not be surprised if the costs associated with the restore were massively different.(Not weighing in on whether they still should have considered it or not, just observing that their claim that it costs an unacceptable amount may not be inconsistent with having restored a much less comparatively &quot;hot&quot; repo.)[1] - <a href="https:&#x2F;&#x2F;web.archive.org&#x2F;web&#x2F;20201116172809&#x2F;https:&#x2F;&#x2F;github.com&#x2F;desktop&#x2F;desktop" rel="nofollow">https:&#x2F;&#x2F;web.archive.org&#x2F;web&#x2F;20201116172809&#x2F;https:&#x2F;&#x2F;github.co...</a>

It does strike me as unfair that GitHub themselves made the exact same mistake but were able to fix it with database backups.

why not just do not display it and keep stars?

So mark the repo as private without their permission to view and have queries for starred repositories ignore repositories you can&#x27;t view - that&#x27;s an extremely frequent approach to take with complex permission and social functions.  I completely understand that not everyone has time to build everything and software is an evolving process - but soft deletion for social links is my default state of mind (then you overlay it with indexing or caching or whatever your performance flavor is to make sure those soft deleted rows don&#x27;t exist in the active query space).

Why not?I think the respectful solution is to show it as &quot;you starred X, it&#x27;s private now, you can unstar if you like&quot; (make sure if the name changes privately then the new name isn&#x27;t shown).Such a solution is not only good in the case of mistakes like this, it also doesn&#x27;t gaslight the person that starred a repo only for it to disappear from their list.

It&#x27;s just bad design never getting fixed despite several prior incidents except for GitHub&#x27;s own project which they reverted.Why do they not just give a public&#x2F;private flag on star data than somehow modifying the data irreversibly?For users, just remove the repo from their starred project list if it&#x27;s not visible.

When the repo goes private, people who can’t see it any more can’t have it in their list of starred repos.

There&#x27;s more nuance there:&gt; 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&#x2F;name vs. name&#x2F;.github.It&#x27;s not unreasonable for the author to have taken the action they did given what they were trying to do. The inconsistent UX for User vs Organization READMEs is a major factor in how the error happened.And given the number of single-repo orgs where the org&#x27;s main product repo name == the org&#x27;s name, well, it&#x27;s not as surprising I&#x27;d say.

if you RTFA he did actually read the dialog box (which is where he found out that it would delete the stars) he just didn&#x27;t notice the 1 line in a 30+ line generic modal.He accepts responsibility for what he did, but points out the very real opportunity to improve the UI&#x2F;UX of a very destructive operation with real contextual data about what is about to be destroyed.

I came in to say precisely this. It’s easy to point fingers after the fact but probably the person wouldn’t have checked regardless of the message in the dialog box.“They warned me but because I didn’t read the dialog box because it was too boring!

I’m curious which statements from the article carried that tone?

Yeah, I also found that tone sort of jarring, but they do bring up a good point; the warning banner and inputs should be contextual and having to input the number of things affected would be a UI improvement. And I can understand why they would write this in anger&#x2F;frustration.

Note the repository names here are &quot;httpie&#x2F;httpie&quot; and &quot;httpie&#x2F;.github&quot;. I don&#x27;t use github(but I do use git), but the difference between the two is not exactly clear to me.They could show you the number of stars, follows, commits, creation date, the number of files, all sorts of things.Also, note that github themselves accidentally set one of their repos to private, but restored it to a previous state through backups. If the move is so boneheaded, why did github make it themselves?A better question might be why, after making the mistake(which was big enough for the CEO to tweet about), and restoring from backups, they didn&#x27;t just fix the glitch and prevent this sort of behavior.

I’ve never liked those “type this string to confirm” dialogs. It doesn’t actually tell me what I’m confirming aside from the name of it (and names are easy to get muddled up if you’re tired or rushing through something). What’s more, dialogs like that encourage people to copy&#x2F;paste those often long strings, which completely sidesteps the diligence they’re trying to encourage.Whether you agree with the tone of that article or not, the UI suggestions made are sensible. Showing the contents of the repo you’re about to change is a lot more useful than asking someone to type the name of it.

&gt; If a &quot;type your repository name to confirm&quot; box still doesn&#x27;t make you double check that you picked the right repository, what else can they even do?It makes you type user&#x2F;repo, which is different in a serious way. It&#x27;s easy for the difference between &quot;.github&quot; and &quot;httpie&quot; to set off alarm bells. But the difference between &quot;httpie&#x2F;.github&quot; and &quot;httpie&#x2F;httpie&quot; can slip through.&gt; &quot;It&#x27;s their fault, they only showed 5 warning banners. A 6th one would have totally stopped me from doing this.&quot;The request is for the warning to say how much will be deleted, not to add another step.

The article spent significant space describing exactly what, and why.

As much as I dislike the general tone of the blogpost (as well as specifics like expecting special treatment (ie restoring a backup) in exchange for money when 1) Github doesn&#x27;t offer that as a standalone service and 2) that wasn&#x27;t already in their contract), I don&#x27;t see how the example UI is anything but a straight improvement.

Also seems a bit suspect that they had a &quot;perfect UI&#x2F;UX example&quot; to show how they would have handled these dialogs. Is this whole thing an advertisement for HTTPie?

&quot;It&#x27;s their fault, they only showed 5 warning banners. A 6th one would have totally stopped me from doing this.&quot;If a &quot;type your repository name to confirm&quot; box still doesn&#x27;t make you double check that you picked the right repository, what else can they even do?

Starred and watched again, it&#x27;s a great project, hopefully the whole audience comes back soon

You really think that adding contextual information in a destructive modal (i.e. &quot;You are about to erase 54,000 stars&quot;) is &quot;beyond being reasonable&quot; ?It seems like a pretty reasonable suggestion that doesn&#x27;t feel like a lot of work, but could potentially prevent an irreversible mistake.

It doesn&#x27;t suggest that you type a any old &quot;specific thing&quot;. It specifically suggests that you type something to demonstrate you acknowledge the scale of the destructive operation you are about to perform.The OP&#x27;s main suggestion is along exactly those lines. It&#x27;s actually less extreme, in some ways (see OP&#x27;s &quot;Lesson 1&quot;).

The confusion is justifiably well explained by the article:&gt; 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&#x2F;jakubroztocil private.&gt; GitHub’s conceptual model treats users and organizations as very similar entities when it comes to profiles and repos. In this context, and since I just wanted to repeat the same benign action on our organization’s profile, my brain switched to auto-pilot mode.&gt; 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&#x2F;name vs. name&#x2F;.github.&gt; That’s why I proceeded to make httpie&#x2F;httpie private instead of httpie&#x2F;.github without realizing my mistake.

This isn&#x27;t &quot;exactly&quot; what Github does. The author suggests the number of machines to destroy in their example- a Github equivalent would be to use a number that represents the amount of resources to be destroyed. This is close to what the OP recommended.

They could very easily list the number of stars that will be deleted, as a sanity test. That in my opinion is even more reasonable than having to type the repo name, and should be implemented.

So you never copy and pasted into dialog boxes? This is exactly the same thing as the Windows warning messages were they found that nobody reads the because they are being trained to click them away.The main thing I really don&#x27;t get is why it even needs to delete all the stars? It&#x27;s not like they delete all comments&#x2F;issues... by users who have been deleted. So why could they not simply make the star point to a &quot;ghost repository&quot;?

&quot;Type a specific thing to confirm&quot; (as suggested by the post you linked) is exactly what Github does for destructive actions. And the author still messed it up because they were on &quot;autopilot&quot;. At that point the suggestions go beyond being reasonable.

<a href="https:&#x2F;&#x2F;rachelbythebay.com&#x2F;w&#x2F;2020&#x2F;10&#x2F;26&#x2F;num&#x2F;" rel="nofollow">https:&#x2F;&#x2F;rachelbythebay.com&#x2F;w&#x2F;2020&#x2F;10&#x2F;26&#x2F;num&#x2F;</a> makes a similar point. I don&#x27;t remember us saying people only have themselves to blame when that article was posted (<a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=24904204" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=24904204</a>). Not sure why we&#x27;re doing it on this post, which makes a number of completely reasonable and specific suggestions for improvement.

&gt; The other difference is that you also have to type the full repository name, including the organization name.No, you don&#x27;t have to type it, and I doubt anyone types it. You copy that line and paste it. Often it&#x27;s done on autopilot, especially when in a rush.

&gt; I don&#x27;t know what else they could have done to try to prevent it.As the author of the post suggests: Prominently spell out &quot;This will remove 54,000 stars.&quot; vs. &quot;This won&#x27;t remove any stars (there are none yet).&quot;

There are certain repository actions that require an interaction and assistance from GitHub customer support.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.

This UI is predicated on the notion that the user will connect the word you&#x27;re asked to type to the repository you&#x27;re intending to modify.Most of the time that&#x27;s true, or we&#x27;d be hearing about this happening all of the time. But &#x27;most of the time&#x27; is not &#x27;every time&#x27;. &#x27;Almost always&#x27; is also not &#x27;every time&#x27;. This is a distinction that Human Factors people make that victim-blaming nerds do not.You&#x27;ve seen the video on Youtube (or Reddit) of the guy holding the fish throwing his phone into the lake? He didn&#x27;t do that because he was stupid, he did it because he made an executive decision to, &quot;hold fish, take picture with phone, throw it in the water&quot; and then his motor cortex swapped &#x27;it&#x27; to the wrong hand and went on autopilot.If you don&#x27;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 &quot;buttons open doors, I see a button. Sure is weird that it is covered with a box... hey why did the lights go out?&quot; 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&#x27;t close it. Technically making someone type, &quot;Make hippie&#x2F;hippie private&quot; would at least make them spell out the intent, narrowing it again. But it doesn&#x27;t make them state the intent. Strictly speaking, they are being told to transcribe text. Whether they parse the text they&#x27;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&#x27;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&#x27;s two very different precedents that have been set, and they picked the wrong one to emulate.

&gt; That&#x27;s not the only difference. The other difference is that you also have to type the full repository name, including the organization name.This is not true.We had an internal tool at a previous job that required you to type the name of a service&#x27;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 &quot;batch&quot; job, folks would go through the motion of:1. click delete2. double click service name3. ctrl+c4. click text input5. ctrl+v6. press &quot;Confirm&quot;It was remarkable, after someone did this once, I don&#x27;t think I ever observed them going back to typing in the cluster name. That algorithm of &quot;copy and paste&quot; carried over into every prompt they saw of that form moving forward.I&#x27;m guilty of this too - I no longer type the prompted name for this form of confirmation dialogue, it&#x27;s a copy-and-paste.

Maybe some kind of grace period could be implemented that would allow changes like this to be undone within 24 hours or something.

The other thing they could do is make user&#x2F;organization structure for that profile readme the same - as he mentioned, he had just done it on his personal account, which is of the form `&lt;user&gt;&#x2F;&lt;user&gt;`, so doing `httpie&#x2F;httpie` for the organization made contextual&#x2F;autopilot sense in the moment.

&gt; That comparison spot the difference pic is really scary. I had to check it 2 times myself before I could spot that the last line is different.That&#x27;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&#x2F;.github, but instead they typed httpie&#x2F;httpie.It&#x27;s unfortunate what happened, but without GitHub removing the possibility at all to delete repositories&#x2F;change the visibility, I don&#x27;t know what else they could have done to try to prevent it. It&#x27;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&#x2F;httpie in this case) and if that doesn&#x27;t stop you, I don&#x27;t think anything would.

Just showing the two screenshots feels a little disingenuous though. It&#x27;s not like that dialog just pops up randomly and asks if you want to delete a random repo, and the only way for you to know which repo it&#x27;s talking about is to read that line near the bottom. In each case the path to summon that dialog had to go through direct interactions with the repo in question.

I&#x27;m afraid to think that these same people, having attitudes like this, are driving cars on public roads.

The dialog clearly warns you that if you have something to delete, it will be deleted, but it doesn&#x27;t let you know if there is anything to delete.That&#x27;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&#x27;m reading correctly, a user&#x27;s profile readme repo is `&lt;user&gt;&#x2F;&lt;user&gt;`, while for organizations it is `&lt;org&gt;&#x2F;.github`, and, crucially, `&lt;org&gt;&#x2F;&lt;org&gt;` 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 &quot;you will lose 54k stars&quot; message would have broken the user out of that space.

In both cases the dialog clearly warns you, with bolded text, on a separate line, of the consequences of your actions.&quot;We were in the top Xth percentile&quot; makes the author sound like a complete tool and I have little sympathy for them, especially given they&#x27;re already back to 3k stars.Expecting the dialog to say &quot;now, you&#x27;ve got 50,000 stars, are you REALLY REALLY SURE?&quot; is just infantile, but really matches the overall tone the author has.

That comparison spot the difference pic is really scary. I had to check it 2 times myself before I could spot that the last line is different.Now that you&#x27;re on the HN&#x27;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.

The article literally has a section &quot;Lessons learned&quot;.

This is a similar attitude to blaming users who close an program without saving, telling them it&#x27;s their fault; the program even asked if they really wanted to close without saving!But, it&#x27;s also totally possible for a program to store a backup, and let the user restore that the next time they open the program in desperation for not having saved their document in a moment of distraction.&gt; but it should be a &quot;lesson learned&quot;Yes. And as the article notes, the lesson can be that software and UX can be make to accommodate better for possible user mistakes. I personally think it&#x27;s nice to have Undo actions, or some ways to revert possible mistakes. It makes software way less scary :)

You didn&#x27;t lose anything, you asked for it to be removed by setting your repository private, albeit mistakenly. Something that is public (stars) cannot coexist with something that is private (your repo), otherwise unexpected things start to happen or you need to write a bunch of pointless edge cases. It makes sense. So does this article, but it should be a &quot;lesson learned&quot; and not a &quot;GitHub fucked us&quot; angle cause it pretty clearly tells you what you&#x27;re about to do.

&gt;GitHub, by design, seeks to be as much of a social networkThis is so true - not sure why it isn&#x27;t getting talked about more - they even have a feed now [which is getting better every few days]

Of course if GitHub were only a service for cloud hosting of Git repositories, it would be totally irrelevant whether or not the repository was marked private for 30 minutes.But GitHub, by design, seeks to be as much of a social network as a repository hosting service and people take the stars very seriously. I’ve seen many CVs that brag about the candidate’s star counts.

This change also clears out watchers. I was watching the repo to be notified of new releases (and security updates) and that was wiped out as part of this mistake.

Why care? Stars don&#x27;t mean anything, save for the few people who organise the software they use by starring it.Certainly it&#x27;s not a community owned by the maintainers. I don&#x27;t own a connection with the people that upvoted this post, and stars mean exactly the same (effectively nothing).

I came across such a prompt maybe three times total in my life, all of them making GitHub repos public or private, or deleting them. Made me stop completely in my track. So it seems to be very much dependent on what you do day to day.

Does anybody actually type those? They were a neat solution 10 years ago but they’re so common now for even inconsequential actions that I always copy and paste, on complete autopilot.

The post addressed this.&gt; 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&#x2F;jakubroztocil private.&gt; GitHub’s conceptual model treats users and organizations as very similar entities when it comes to profiles and repos. In this context, and since I just wanted to repeat the same benign action on our organization’s profile, my brain switched to auto-pilot mode.&gt; 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&#x2F;name vs. name&#x2F;.github.&gt; That’s why I proceeded to make httpie&#x2F;httpie private instead of httpie&#x2F;.github without realizing my mistake.There&#x27;s a subtle naming difference between profile README repos for users and orgs that was the root cause of this. The user typed the repo name in however because it matched the same format for the previous profile README repo, it didn&#x27;t register that this was not in fact the profile README repo they were looking for.

The post did not omit that, it included the very similar thing they typed as context for how they auto-piloted it.
In that autopilot state having to type out 54000 would probably have snapped them out of it.
I get why you&#x27;d think the author is being unreasonable, they seem to imply that this should already have been done, but I think that is mostly them feeling upset about the situation. The actual observations would be thoughtful improvements to the UI.

Your comment is omitting that the post covered this exact point in detail: they had just done the same operating on their personal profile where you have to type [username]&#x2F;[username]. [organization]&#x2F;[organization] is the obvious corrolary.Anyways it&#x27;s embarrassing that Github made this same mistake themselves, and yet couldn&#x27;t spare the time for a massive content creator contributing to their platform

They address that in the post.  Github treats organization accounts differently from personal accounts, and what would have worked perfectly fine and expected for a personal user account actually impacted a different and unexpected repo for an organization account.  I would wager 99% of Github users would make a similar mistake in the same situation since they rarely deal with organization accounts directly.

The post is omitting that the user must type the name of the repository in full; in this case, they typed `httpie&#x2F;httpie`. If one is in such a deep autopilot state, no amount of warnings will work.

The GP didn’t mean “wait 5 minutes before making any action”, they meant “stage the change so the user can see the result of their action but they still has a grace period to undo it”.

There is no undo there. 5 mins seems like a long time to you but to the bots that scrape GitHub repos for secret things, the time it took you to notice and reverse something yourself was already the time they needed.If you made something public on GitHub that shouldn’t have been, it was immediately compromised, you just might not notice.

Making a private repo public could also be delayed.

Which comes with its own problems. What if I just published something I wanted to be secret? Then I need to be able to switch it back to private, and it has to be quick, not after five minutes. Distributed systems with eventual consistency already make fixes like that hard, not to mention caches and whatever.

It’s definitely easier from the implementer’s point of view. That doesn’t make the UX any better, though.

Warnings can be done completely within the frontend, that probably makes them way more desirable for the company.

It&#x27;s understandable why warnings are used instead of undos though. Warnings are dirt simple to implement - probably a single line of code in most languages. Undo is very complex by comparison. You have to flag something for deletion and put it into some sort of deletion queue that somehow gets deleted at some future date, etc.

&quot;Design of everyday things&quot; is a great book to start.

Hi newbie developer here, where do i find and learn about ux design priciples like this? Just curious, thank you thank you.

GitHub made a cardinal UX design sin here: never use a warning when you mean undo [1]. If they had given even a five minute grace period before starting the irreversible process of removing all the watchers, this wouldn’t have happened.<a href="https:&#x2F;&#x2F;alistapart.com&#x2F;article&#x2F;neveruseawarning&#x2F;" rel="nofollow">https:&#x2F;&#x2F;alistapart.com&#x2F;article&#x2F;neveruseawarning&#x2F;</a>

It should just show the amount of stars &#x2F; watchers for any repository. I don&#x27;t think a custom strategy based on repo size is needed.

How big is &quot;clearly big&quot;?  Whenever someone makes the same mistake with a slightly-less-big repository should the warning thresholds be revised to also show up for those?

Surprising amount of people blaming the user here. I agree completely with the author, the UX should be different for clearly &quot;big&quot; repos.

Murphy&#x27;s law strikes again. Really appreciate the writeup. Making the best of the situation is a valuable lesson in itself. Hope you can get the stars back one way or another! =)

As a junior developer, GitHub star was one of the most important metric when I am choosing library&#x2F;software.

(Whether it&#x27;s a good idea or not,) people often use stars as a quick-and-dirty proxy for &quot;is this repo reasonably well trusted?&quot; and &quot;how big is the community for this project?&quot;. All else being equal, many people would default to using a repo with 20,000 stars over a repo with 20.

A practical consequence (not necessarily the only consequence) would be for the people who starred it who use stars as a bookmark feature: they have now lost their bookmark.

&gt; silentlyI’d argue that GitHub should send them a notification that the repo they starred has been made private.

Starring a repo is a way of tracking it. So now there are 55k people who were trying to keep an eye on the project who have silently lost that.It&#x27;s also an important indicator of community size and authenticity, important factors in the decision to use the code.

I sometimes decide what to use based on number of stars. It&#x27;s a trust in the quality of the software.Now httpie is on 2.5k stars and if I only knew about it today, I&#x27;d consider using an alternative with 10k stars if there&#x27;s any.

From personal experience and from reading the other comments, some people see open source as a popularity contest and more stars will get you more users (which in turn gets you more stars).Choosing one library over another just because it has more stars is bad decision making.Consider choosing a command line tool for making http requests. If you consider GitHub stars:
- curl has 24.7k stars
- httpie has 4.3k stars as of writing this
- wget only has a mirror on GitHub with 264 starsDoes this mean wget is a bad tool? Does it mean httpie used to be vastly superior to curl with over 2x the amount of stars? I don&#x27;t think you can really say anything meaningful about these projects based on the amount of stars, especially relatively to each other. Except for how many people clicked on the star button.

What can you purchase with GitHub stars?More seriously, why do they matter? Is it a prestige thing only or are there practical consequences to losing the stars?

They apparently do. Even if they did hard delete they still should have backups. They just got lazy fixing it after several similar incidents and this one was expected and yet all they do is a tweet saying &quot;good luck building up the community again&quot;.My faith in their tech department is falling when they can&#x27;t fix such a small issue.

This happened to me as well. It&#x27;s sad that GitHub doesn&#x27;t retain that data.

Heavily reminds me of this RubyConf talk: <a href="https:&#x2F;&#x2F;rc-temp000-videos.s3.us-west-1.amazonaws.com&#x2F;Laura-Maguire.mp4" rel="nofollow">https:&#x2F;&#x2F;rc-temp000-videos.s3.us-west-1.amazonaws.com&#x2F;Laura-M...</a>One of the core bits of the talk is about the sort of messages our automated systems give us, and whether they&#x27;re sufficient, or woefully lacking - which is what the linked article is also talking about, when it talks about how the &quot;warning: about to burn down a house&quot; doesn&#x27;t tell if anyone&#x27;s in that house.

The complicated thing is that every query has to look for the column.Ideally, moving the entire serialized record to an archive table keeps things as clean as possible.

I meant to focus on the cascade part of the equation here. For example, lets say `stars` are foreign keyed (FKed henceforth) to repos, and (say) `X` are FKed to `stars`, and `Y` is FKed to `X`. Then if you do a &quot;hard&quot; delete of the repo status (or the stars), then we can set that to cascade to `X` and `Y` as well. Otoh, I don&#x27;t think you can apply a cascade like that automatically when you&#x27;re just changing a value (which is how a soft delete would be implemented, ig). Can you? Is there some really cool hook that allows this?

There is no need to delete anything at all. Set the &quot;private&quot; flag when the user asks for to make it private. Unset the &quot;private&quot; flag when they make it public again.If it is needful to be able to delete stars, make a separate button for that. But it is hard to imagine such a need.

&gt; I&#x27;m not really sure how you&#x27;d do a &quot;cascading soft delete&quot; without making some kind of manual cascading logic?Perhaps the delete action is not accomplished right away and a column is checked. Then after a X amount of months a worker process goes around actually deleting things?

Not sure what you meant? Are you pointing out couldn&#x27;t vs didn&#x27;t? If so, I didn&#x27;t really think about it, although now that you point it out, I think didn&#x27;t would&#x27;ve been a better fit. I&#x27;ll edit it, thanks!

&gt; &quot;that GitHub couldn&#x27;t restore it&quot;What an odd turn of phrase.

I agree that undos are pretty nice for when errors are possible, but I think there&#x27;s a really good reason to put up warnings too. Let&#x27;s say they accidentally made the repo private, but didn&#x27;t notice it (unlike what happened here). Although you would be able to undo the change, it may have only kicked in once the news spread around (followed by reputation damage, etc). A well worded warning would prevent that.In a way, I think warnings and undo serve two different functions-warnings are meant to inform the user of their action, and undos are meant to roll back actions taken.

Even better, flipping &quot;public&#x2F;private&quot; has absolutely no need to delete any information at all.There could be separate buttons, &quot;Delete all my stars&quot;, &quot;Delete all my watches&quot;.

For Lesson 1: I think the general pattern that ought to be followed is to &quot;prefer undo to warnings.&quot; Undo is often harder to implement, however it&#x27;s usually a superior experience.

My favorite example of this is that the cloudflare.com web UI has some extremely scary buttons, like a little &quot;bypass CDN&quot; button with a cloud on it that will rapidly increase traffic to your site 2-100x if you accidentally click.I mean this isn&#x27;t exactly how it works. But it&#x27;s a bit scary.

I suggest you read &quot;The Field Guide to Understanding &#x27;Human Error&#x27;&quot;. You&#x27;d learn a lot.<a href="https:&#x2F;&#x2F;www.amazon.com&#x2F;Field-Guide-Understanding-Human-Error&#x2F;dp&#x2F;1472439058" rel="nofollow">https:&#x2F;&#x2F;www.amazon.com&#x2F;Field-Guide-Understanding-Human-Error...</a>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.

&gt; I specifically dislike the &quot;Lessons&quot; section, as it throws all the blame on github and doesn&#x27;t mention the seemingly obvious advice: &quot;make sure you&#x27;re not on autopilot when taking potentially dangerous actions, on github or any website&quot;.I don&#x27;t know. Github employees themselves have made this mistake as outlined in the post, and they were easily able to recover from it, which probably lowered the priority on changing any UX.Essentially, it&#x27;s a complete non-issue depending on whether Github cares about you.Would you like the police in your area to behave in this manner? I think not.

Sure, I understand that. But I think, as a designer, I can&#x27;t really control the actions of my users. I can only try to design such that I can get them closer to the action they want to take. From that perspective, I think adding the additional information to the warning UI would, if not solve the problem, at least get us one step closer to helping the user make the right decision.Tbh, when I&#x27;ve deleted repo&#x27;s, I&#x27;ve mostly just copied the repo name and pasted it in the box. Careless of me? Definitely. Can GitHub change that carelessness? Probably not. Will a box that says &quot;Stars: 54k&quot; help? I think it&#x27;d help me, at the very least.

How many years have we had to learn from people using programs to know that people make mistakes. Goodness knows how many people burned themselves using &quot;rm&quot;. For that reason alone, &quot;rm&quot; is a bad tool, and should be replaced with something like trash-cli.

Yeah, but on the other hand, &quot;don&#x27;t make mistakes&quot; isn&#x27;t a meaningful or useful lesson.

I would argue that the fact that GitHub themselves made the same error really tells us that yes the UI makes it way to easy to do this. Considering the number of repos on GitHub I wouldn&#x27;t be surprised if someone made the same error every a couple of weeks (but typically not with such high stakes).I would also say that post does not come across to me as he is only blaming GitHub.

On typing out the name of the resource, it is of course a way better check than just displaying it. I think it also was very efficient when there was only a few places using it, and the novelty made it attention focusing.Thing is, we type all day, and can type pretty much any string at a decent speed without putting much thought into it.Any of us must have mistakenly typed a full file path or API URL, just to realize it’s not the right machine or project after having typed it all. It just take 2 or 3s max after all.I think it becomes an arms race to get attention on important things, we can do better by focusing more on every single destructive operation. We can also avoid having too similar interfaces for completely different contexts.

Data privacy laws like GDPR probably require them to fully hard delete when a user asks for something to be deleted. So any undo functionality would need to make sure it&#x27;s compliant in every region that could have a privacy law. I&#x27;m not sure how realistic it would be to ask companies like Github to jump through all those hoops because people refused to read (and then blindly typed stuff out).

&gt; I specifically dislike the &quot;Lessons&quot; section, as it throws all the blame on github and doesn&#x27;t mention the seemingly obvious advice: &quot;make sure you&#x27;re not on autopilot when taking potentially dangerous actions, on github or any website&quot;.First of all, this is self-evident. But second of all and more importantly: it doesn’t scale.The reason we have blame-free postmortems is because people will always make mistakes, so we find ways to change process or design to minimize those mistakes.If you think you’ll never do something on autopilot, you’re fooling yourself.

Having to also type out the number of stars you&#x27;re deleting when it&#x27;s above some threshold would probably eliminate the error.  I think people who use git a lot are used to having the same or similar repository names in multiple contexts and locations (it&#x27;s decentralised), so typing out the repository name, even though it includes the user&#x2F;organisation, is not as severe-seeming as the designers thought.  Confirming the consequences seems better than confirming the command.

&gt; make sure you&#x27;re not on autopilot when taking potentially dangerous actionsWhen it comes to repetitive or familiar actions, this is physically impossible. If a repeated action is dangerous you cannot use a human interrupting themselves as your only control. It just won&#x27;t happen.Overall this is a classic UI design failure. In addition to the &quot;people physically can&#x27;t take themselves off autopilot&quot; problem, the interface destroys the user&#x27;s data without providing a way to get it back. It would take relatively little engineering effort to make this reversible.

&quot;The user shouldn&#x27;t be stupid&quot; - which is what you&#x27;re saying sounds like to my ears - is not an approach that scales well.Mistakes happen. It&#x27;s better to have a really good Undo than a lot of confirmation dialogs.

If your whole job is to use power-tools, the fact of using power-tools by itself — scary to some — becomes benign for you. `rm -rf` isn&#x27;t scary to type if you e.g. write CI scripts intended to run in sandboxes all day. Deleting a repo isn&#x27;t scary if you delete a lot of pointless repos.A prompt that pops up to warn you that you&#x27;re doing something potentially dangerous, when you know that what you&#x27;re doing is benign, is a prompt that&#x27;s crying wolf. You&#x27;ll learn to tune it out.

&gt; make sure you&#x27;re not on autopilot when taking potentially dangerous actionsIf they&#x27;re in autopilot, how are they going to &quot;make sure&quot;?Everyone has been in this spot several times. Those who didn&#x27;t are just lucky.There&#x27;s got to be external contingencies to protect people when they&#x27;re in autopilot.

I disagree because there is no UI to indicate you&#x27;re in a special repo. And I blame GH for not considering this &quot;large project maintainer&quot; use-case.When I administered many VAX &#x2F; UNIX machines waaay back, the terminals were all configured to be &#x27;special&#x27; for the super user. It would have been HORRIFICALLY BAD if any command were executed unknowingly.GH does -not- distinguish for project sizes, so there is NO SUPPORT for its users in this way. Every feature is to be considered with the same &quot;shotgun severity&quot;.

The problem is that this “seemingly obvious advice” is completely useless because it’s not actionable. It’s similar to saying “to avoid the mistake, just don’t make the mistake”To make a better system for every human, you can either try changing all the humans, or you can change the system that is supposed to serve them. One is easier than the other.

I recommend reading “the design of every day things”, it talks about this exact attitude and why it’s terrible.

Agreed, and I&#x27;m genuinely surprised that so many on HN are angry at GitHub when they already made it so hard to do this. The author explicitly mentions they were on autopilot - it would take a significantly more challenging barrier for them to not do the exact same thing no matter how many prompts GitHub put there. It does make sense for it to be more reversible, but I can also understand why GitHub doesn&#x27;t want to put in the effort: this is a once in a year kind of incident and the resources required wouldn&#x27;t be worth it compared to signal boosting, like they did on twitter. I, for one, would be extremely pissed if GitHub made it harder for me to do routine actions because there&#x27;s a possibility of data loss. I signed up for that when I typed the repository name in.

Also sudo mode, right? They had to authenticate to the whole website again too, before doing this!

Agreed, the swipe at Microsoft (with links he saved from who knows when!) was especially gratuitous. He mad. Don&#x27;t write something public when bitter should be a lesson right after don&#x27;t be on autopilot.

GitHub probably should show the stars in the warning UIIn this particular case the stars would have been a useful clue, but in the majority of similar cases the wouldn&#x27;t be any stars. It would be a useless and redundant signal.

It would be very rare to have lived through an IT career and not make one or two fatal autopilot mistakes. In the 90s and early 00s it was very easy to lose a production system because you did something wrong that you did 1000x times right before. And this is a modern version of it; for me, this should not happen; if I designed GitHub, these people giving stars and watch would get selected based on the visibility of the profile. That hardly costs anything and then the user can just switch between visible and invisible at will and not lose anything. But I have made many similar mistakes in the past which is why I don’t delete stuff usually anymore; I just flag it deleted and gdpr material I encrypt. I simply don’t want either software bugs, hacks or human error to cause any damage. With the cost of storage and the fact that I work only in b2b, this comes at virtually no cost but with a lot of happiness for both our users and myself.

I feel for the guy and what he says about user interfaces is all true, but the tone of the piece grates on me a little.“I take responsibility, but…” is not “I take responsibility.”

&gt; the author had to _type out_ the name of the repo they wanted deletedWhere does it say that they deleted any repo?

&gt; obvious advice: &quot;make sure you&#x27;re not on autopilotThat... isn&#x27;t how &quot;autopilot&quot; (or humans in general) work(s).

The author explicitly admits &quot;my brain switched to auto-pilot mode.&quot; The problem with that is that we&#x27;re on auto-pilot many times and we realize we&#x27;re doing it only after something bad happens. The UX should prevent auto-pilot to do harm to us (and possibly to the customer&#x2F;company relationship.) &quot;You&#x27;re about to delete 55k stars&quot; should be enough, as the author suggested. But designers can be on auto-pilot too.

Tbh, it doesn’s look like the wrong repo name if you want to make your organisation README private. I agree with the author that the discrepancy between user and organisation profiles doesn’t help here. If every user&#x2F;organisation could make a .github repo instead it would be much more obvious.

Yes, and as Don Norman puts it, Design is mostly on how to make errors non-catastrophic. No design nor training ever will abolish them.Humans err.

&gt; the author had to _type out_ the name of the repoI copy&#x2F;paste the repo name every time I delete a repo on GitHub. Yeah, it’s still a minor impediment, but it’s definitely not “TYPE the account and repo name.”

&gt; make sure you&#x27;re not on autopilot when taking potentially dangerous actionsHumans will be humans, we can&#x27;t help it.Structures or systems that handle large amounts of user interactions should predict such use cases and design accordingly. a.k.a make them &quot;idiot proof&quot;.

&gt; &quot;make sure you&#x27;re not on autopilot when taking potentially dangerous actions, on github or any website&quot;.Have the advertisements&#x2F;sign-up&#x2F;GDPR pop-ups trained us to &#x27;engage autopilot to dismiss the pop-up&#x27; as soon as possible irrespective of its importance?

I specifically dislike the &quot;Lessons&quot; section, as it throws all the blame on github and doesn&#x27;t mention the seemingly obvious advice: &quot;make sure you&#x27;re not on autopilot when taking potentially dangerous actions, on github or any website&quot;.Yes, GitHub probably should show the stars in the warning UI, and hopefully that will prevent some of these mistakes. But GitHub makes it pretty hard to make this mistake already - the author had to _type out_ the name of the repo they wanted deleted into the warning box. At that point, it&#x27;s hard to believe the author when they claim that this one addition to the warning UI would have definitely stopped them when they weren&#x27;t paying enough attention to notice they had typed the entirely wrong repo into the confirmation box.

&gt; just replacing the &quot;Yes&quot; buttonOr the lazy web dialog popup with &quot;Cancel&quot; and &quot;OK&quot;.So you click on &quot;Cancel Glorping The Frobnitz&quot; and up pops a dialog with &quot;Cancel&quot; and &quot;OK&quot;. It always takes a moments thought does the &quot;Cancel&quot; on the popup mean cancel the cancel glorping or cancel the cancel.Since it takes literally seconds to change the button captions it might be nice to think of something clearer. Seconds if you&#x27;re a UI expert which I&#x27;m not. Of course the webdev part of changing the captions on the page really would be seconds for me to do.

I ran into this in pgAdmin recently. When right-clicking on a server, the options to disconnect the server and remove the server are right next to each other. Clicking disconnect presents you with the following dialog box:&quot;Are you sure you want to disconnect the server? No &#x2F; Yes&quot;Click remove presents you with the following dialog box:&quot;Are you sure you want to remove the server? No &#x2F; Yes&quot;Good luck! I mean, it&#x27;s not a super huge deal to recreate the server entry, but still annoying when you&#x27;re in the middle of something and just realized what you did.Honestly, just replacing the &quot;Yes&quot; button with the action being taken would be enough to improve this. &quot;No &#x2F; Disconnect&quot; and &quot;No &#x2F; Remove&quot;. But my personal opinion is that disconnecting is not a destructive action unless there&#x27;s an open transaction or running query. So the dialog box should be contextual on that scenario, and otherwise it should just disconnect.&quot;Disconnecting will cancel executing queries and rollback open transactions. Continue? No &#x2F; Disconnect&quot;

&gt; While the author clearly feels bad about the fact that they&#x27;ve lost his community and that GitHub couldn&#x27;t restore it (which is honestly what any of us would&#x27;ve felt under similar circumstances), they&#x27;re also focusing towards the future and using their personal experience as a parable all of us can learn from.Also, writing a solid blog post about a customer-service corner case and getting it to the top of news.ycombinator can be a great, if somewhat last-ditch, opportunity to escalate a problem.

That it took a half hour to do all the pointless activity says something.

They use Rails, right? It&#x27;s probably a cascade delete but done on the application, Rails makes that very easy.

&gt; I assume that the cascading done on GitHub would be done on a FK constraintGitHub doesn’t use foreign keys, the cascade delete must have been manually implemented.<a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=21486494" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=21486494</a>

&gt; But even that fails if there is a language barrier.Surely GitHub is localized? (and if not, why the hell not?)

I’ve adopted a pattern of:&lt;dialog-text&gt;If they click ok:Asking again to be sure you want to destroy masses of data&lt;dialog-text&gt;But even that fails if there is a language barrier.

&gt; Lesson 2, which was to use soft deletes, is something I have more thoughts about. I assume that the cascading done on GitHub would be done on a FK constraint, but I&#x27;m not really sure how you&#x27;d do a &quot;cascading soft delete&quot; without making some kind of manual cascading logicRelying on database cascade deletions is very dangerous. Especially since as the application&#x2F;org grows, it&#x27;s easy to lose track of all the things that may get cascaded. There&#x27;s a good chance you&#x27;ll find yourself having cascade-deleted data that you never intended to have deleted.Manually implementing logic for &quot;when archiving X, also archive Y and Z&quot; takes more effort, but is a lot safer. When it comes to data.What surprised me most is that github performs irreversible deletions when someone making a repository private. I would have expected them to just create a &quot;is_deleted&quot; column and set that flag to true. I wonder how much of this behavior is motivated by GDPR. Ie, complying with it requires completely deleting data when requested by the user, and they decided the most straight forward way to comply with that requirement is to delete the data immediately when requested.

&gt; I assume that the cascading done on GitHub would be done on a FK constraint, but I&#x27;m not really sure how you&#x27;d do a &quot;cascading soft delete&quot; without making some kind of manual cascading logic?I&#x27;m not at a terminal, so I can&#x27;t check it out, but could you make a compound foreign key with the soft delete column and use the on update cascade? Something like `alter table stars add foreign key (repo_id, is_deleted) references repos (id, is_deleted) on update cascade;`

An ON UPDATE trigger for the is_deleted column would do.Some databases also support INSTEAD OF triggers.

&gt; I assume that the cascading done on GitHub would be done on a FK constraint, but I&#x27;m not really sure how you&#x27;d do a &quot;cascading soft delete&quot; without making some kind of manual cascading logic?Couldn&#x27;t you just use an on delete trigger for this? I have no experience one the subject however

I don&#x27;t see why you are thinking it&#x27;s hard with rails, you just create a default scope in your model &quot;not_deleted&quot;, and that&#x27;s done.It will apply to all queries unless you specifically call &quot; unscoped&quot;

1. Why would it be particularly difficult for them to have soft deletes in Rails or at scale?2. Like the article suggests, additional UX improvements could be made besides making it possible to restore a backup or providing an undo action.3. I feel you are ignoring the fact that technology-wise it was probably Rails along with its MVC model that got them into their scale in the first place.4. Had they focused on a more exotic architecture from day one, the UX of other features on the site could&#x27;ve been significantly worse.

I&#x27;m in the process of creating an MVC framework and was curious about the other architectures you mentioned.This comment seems to be down on MVC and Rails so I was curious about the alternatives you mentioned and came across your post that ended with praise of Rails ( <a href="https:&#x2F;&#x2F;berk.es&#x2F;2022&#x2F;03&#x2F;08&#x2F;the-waning-of-ruby-and-rails&#x2F;" rel="nofollow">https:&#x2F;&#x2F;berk.es&#x2F;2022&#x2F;03&#x2F;08&#x2F;the-waning-of-ruby-and-rails&#x2F;</a> ):&gt; Rails still is a great way to get a prototype demo, or minimum viable product online in days with least surprises.Your comment seems to indicate that you started discovering new architectures like the Command Pattern but it sounds like you are also still a proponent of Rails and MVC based on your blog post. Do you have any links to resources that helped you discover other patterns or could you share what took you on your journey?In the Rails blog post, you said:&gt; I have a separate post planned on &quot;RAD web frameworks&quot;, MVC and ActiveRecord, but it is safe to say that such frameworks, amongst which Rails, have found their niche, yet are by no means a silver bullet.Is that post you are planning to write going to delve into some of the architectures you mentioned here? That would definitely be something I would be interested in reading.

<a href="https:&#x2F;&#x2F;github.com&#x2F;rubysherpas&#x2F;paranoia" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;rubysherpas&#x2F;paranoia</a> is enough to solve problems at very large scales.There is nothing about Rails or MVC preventing someone from doing this. This is a very common design principle for all kind of ERP and BPM systems: don&#x27;t ever delete anything.

Github is built with MVC. On rails no less. Where problems like soft delete are hard, or even impossible to solve (in scale).Yet there are many architectures beside MVC. Many of them decades old. Proven. Established. Yet unknown to devs who picked up a rails book on day 1 and never looked back (I&#x27;ve been guilty of that for years).This particular problem is a textbook candidate for Command Pattern. The problem of undo is solved naturally in any event-sourced setup (git is even sourced, and moving through history a prime feature). Probably more architectures that I&#x27;m less familiar with, solve &#x27;undo&#x27; as well.But we are stuck with the web, backends in 2022, being built on MVC frameworks like Rails, where solving such issues is tough and complex. So we are stuck with a huge amount of warning dialogs to &#x27;solve&#x27; this.Point being: choose your architecture well, based on your needs and the tradeoffs. Don&#x27;t just grab the next fancy framework, because that will decide for you, if, and how you solve things like &#x27;soft delete&#x27; or &#x27;undo&#x27;.

All the talk about auto-pilot mode reminds me of this excellent talk on activation energy, waking up yourself from slumber, or flip-flopping between auto-pilot and emergency modes: Mel Robbins, How to stop screwing yourself over, <a href="https:&#x2F;&#x2F;www.youtube-nocookie.com&#x2F;embed&#x2F;Lp7E973zozc" rel="nofollow">https:&#x2F;&#x2F;www.youtube-nocookie.com&#x2F;embed&#x2F;Lp7E973zozc</a>

By now I&#x27;ve become so accustomed to just copy the bold text from the line above it and paste, that it doesn&#x27;t break me out anymore. I know I should concentrate and type it out, but in my head it has just become visual noise and a boring exercise.

He did have to type &quot;httpie&#x2F;httpie&quot; in the box to confirm, no? I&#x27;m rather surprised that that didn&#x27;t snap him out of auto-pilot mode. There ought to have been a DING in the brain seeing that the repo this is being applied to was httpie&#x2F;httpie?OTOH, I haven&#x27;t been in such a mode, so I really got no right to comment on this. Best wishes to the team -- that those who saw his post will restar&#x2F;rewatch the repo -- and (fwiw) thanks for writing it up and making me even more paranoid (in a positive sense) about doing such destructive operations.

Regarding cascading logic with soft deletes; I think the answer is that you don&#x27;t cascade anything. You basically need to have `deleted_at IS NULL` conditions in your queries to exclude them.

&gt;I often think scary popup boxes are enough to get people to think about what they&#x27;re doingThis would entirely depend upon how often it shows up. The more often it shows up when the scare isn&#x27;t relevant, the less people will pay attention to it.&gt;the distractions (&quot;Type this repo&#x27;s name&quot;, etc) just go awayI think it shows that what one types needs to be relevant information. In this case, due to the similarity between when the author would&#x27;ve been asked if they did what they were intending to do and what they typed to do what they actually did, we can judge the prompt isn&#x27;t enough. If this also asked you to type in the number of git stars you were about to lose, that would&#x27;ve been enough to make author recheck exactly what they were doing.

Factorio doesn&#x27;t say &quot;You&#x27;ll lose unsaved changes&quot; if you close the game immediately after saving, which is super nice.The number of games that DO ask this question, immediately after saving, is ridiculously high it&#x27;s so frustrating.

Your comment missed the main lesson of the post.GitHub (Microsoft) had a non intuitive UI feature, they themselves were victim of. They restored for their own repo but not for the customer repo...Zero customer focus is the lesson here.&quot;...In our case, however, they refuse to do that, citing undesirable side effects and the cost of resources. We even offered GitHub financial compensation for any resources required. But, sadly, they declined. They have other priorities than resurrecting the community of one of the oldest and most popular community projects on their platform...&quot;&quot;...So the answer to the question is, unfortunately, the following: GitHub will restore a repo damaged by making it private. But only if it’s one of their own projects, not a community one..&quot;

I really like this post.While the author clearly feels bad about the fact that they&#x27;ve lost his community and that GitHub didn&#x27;t restore it (which is honestly what any of us would&#x27;ve felt under similar circumstances), they&#x27;re also focusing towards the future and using their personal experience as a parable all of us can learn from.Lesson 1 on UI design I think is really important. I often think scary popup boxes are enough to get people to think about what they&#x27;re doing, but this example clearly demonstrates that what&#x27;s important is to use design not to scare (alone?), but to convey the information which makes a dangerous action dangerous as well. I also really like the fact that when the action isn&#x27;t dangerous, the distractions (&quot;Type this repo&#x27;s name&quot;, etc) just go away. It&#x27;s super intuitive, and (for a newbie designer like me) really helps build an intuition for various design principles put in action.Lesson 2, which was to use soft deletes, is something I have more thoughts about. I assume that the cascading done on GitHub would be done on a FK constraint, but I&#x27;m not really sure how you&#x27;d do a &quot;cascading soft delete&quot; without making some kind of manual cascading logic? If anyone&#x27;s aware of a standard way to accomplish this, please do let me know. Of course, the best way may just be to simplify the model so they aren&#x27;t needed at all haha.As designers and developers we&#x27;ve been given a chance to sharpen our toolkit. Thanks, HTTPie! You&#x27;ve gained a new star :)Edit: Changed GitHub couldn&#x27;t restore to GitHub didn&#x27;t restore, as pointed out by @ncmncm (<a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=31033758#31034195" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=31033758#31034195</a>)

I read it.I think there should be a follow-on discussion here about programming paradigm that empowers a &quot;do what I mean not what I say&quot; mentality.Atlassian&#x27;s recent fiasco <a href="https:&#x2F;&#x2F;www.atlassian.com&#x2F;engineering&#x2F;april-2022-outage-update" rel="nofollow">https:&#x2F;&#x2F;www.atlassian.com&#x2F;engineering&#x2F;april-2022-outage-upda...</a> is another motivating example for such a paradigm.The author of the blog touches on this paradigm as a UI element. Software engineers should have pushed that as a &quot;gotcha&quot; up through Product Management to expose controls for such a risky scenario.

I notice there are a lot of people in this comment section who either haven’t read the article at all, or haven’t read it in full. Worth reading the full post before commenting

Agreed. This just screams bad UX on a corner case.

You can do that without the “making it private and public again” part anyway.

But couldn&#x27;t the same be achieved without taking it private?

Yeah, that&#x27;s a risk. They could mitigate it by allowing you to revert all branches&#x2F;tags back to the pre-private state, but we&#x27;re getting more and more complicated here.

Yeah but it&#x27;s not like stars are seen as some amazing endorsement on the part of the individual starring. It&#x27;s more like a favorites list if anything

I don’t know for certain but I feel like this could allow something like 1. Takeover&#x2F;inherit public repo with lots of stars 2. Take repo private (retaining stars) 3. Replace repo code with some malicious&#x2F;offensive code. 4. Take repo public again 5. Inherit the trust&#x2F;prestige of the old repo.

1) probably not the desired experience2) probably part of the currently required setup on their database side (triggers)Features tend to evolve evolutionarily and certain data patterns are hard to invent around for security&#x2F;privacy constraints. So err on the side of deleting rather than potential privacy&#x2F;security bug.Definitely fixable with some decent investigation, coding, etc. - but hard to prioritize.

You do lose the title, which is super annoying. &quot;What did I used to have?&quot; Super frustrating feeling.Here&#x27;s a list of your favourite songs, but two are missing, have fun figuring out which two it is!

I think this is getting at the more robust solution.When youtube videos are taken down or made private, they are not deleted necessarily from my playlists. There&#x27;s simply an indicator that they video is &#x27;no longer available&#x27;. I don&#x27;t see why something similar can&#x27;t be the behaviour for GitHub stars and watches?

&gt; The users can still see all their stars and find the private repo, which makes it not private.Why seeing a start you made for a previously public repository makes it not private? People remember things too, there&#x27;s also the webarchive. You should be able to unstar it or keep your star, the only difference is that you don&#x27;t know if the repository still exists or not.

Your last option sounds appealing to me here. Yes it does mean that you can never really make the name of your repo fully private after it&#x27;s been started, but the name isn&#x27;t really what&#x27;s important most of the time.And there&#x27;s always the potential to add a other toggle when privating a repo that lets you force-remove all stars.

Twitter has this kind of problem with likes (or maybe they fixed this since I haven&#x27;t been on there in a while).When someone deactivates their account, you can see that you have X additional likes, but you can&#x27;t access them. If that user reactivates their account, those likes suddenly show back up.This could be a privacy issue if you&#x27;ve decided to remove likes for a certain categories of posts for whatever reason.For GitHub, a couple other options I can think of would be to 1. show stars for private repos but only for the purpose of unstarring or 2. hide stars when a repo goes private and then give users an option to re-enable their star if a repo goes back to public. But these options are relatively complex, and I can see why GitHub would go with deletion.

The repo could lead to 404 to everyone, but if someone had starred it they would get a 403. They would be able to see all their stars but not access certain repos because they were made private. Probably less surprising then some of their stars disappearing. They would at least know what happened and it’s not like wouldn’t know the repo was public at some point anyway. Additionally, there could be another button to clear stars and watchers, if the owner of the repo really wants to.

&gt; The users can&#x27;t see all their stars, they can only see their stars for the public repos. There&#x27;s no way to find or unstar a private repo that you starred while it was public. This would lead to the situation that if you unstar everything and make sure you have zero stars, you could wake up the next week with 1 starred repos, and then with 3 starred repos, because some repos went public again.Sounds fine and expected to me.

&gt;I think the current behaviour is better than all of these options.Current behavior is destructive.&gt;- All private repos that have been public at least once lead to a &quot;this repo is now private&quot; message, that would in practice allow anyone to make an index of all the private repos that were public at least once. And it would also allow anyone to know when a private repo that was private at least once is deleted.This is a much better option.

Perhaps 1-2 weeks of warning before a full delete of stars would be desirable for any repo with over 1k stars.Sorta like most social media apps when you want to delete your account. It doesn&#x27;t delete it fully until a month later

Let&#x27;s assume that the stars don&#x27;t go away when the repo is made private. There are a couple of options:- The users can still see all their stars and find the private repo, which makes it not private.- The users can&#x27;t see all their stars, they can only see their stars for the public repos. There&#x27;s no way to find or unstar a private repo that you starred while it was public. This would lead to the situation that if you unstar everything and make sure you have zero stars, you could wake up the next week with 1 starred repos, and then with 3 starred repos, because some repos went public again.- The users can see all their stars, but the private ones lead to a 404, which would be perplexing for a greater number of people than the current behavior.- All private repos that have been public at least once lead to a &quot;this repo is now private&quot; message, that would in practice allow anyone to make an index of all the private repos that were public at least once. And it would also allow anyone to know when a private repo that was private at least once is deleted.I think the current behaviour is better than all of these options.

Totally agree - cascade delete is such a nice thing - until it is not.Technically you want to delete dependent stuff, but in this case this seems like overstepping on development side.

Sure, the author should be responsible.Yes, GitHub should have a better UX around this action.But...There is another thing to consider:Is it really necessary that a repo that is accidentally made private and then made public should lose its stars anyway?Is that really what the repo owner or the people who starred the repo even want to happen?

In the absence of metrics to use for ranking, it is hilarious how people co-opt whatever weak metrics they find and then retcon a deeper meaning into them.“They’re not stars, they’re a community!” What percentage of your community actively contributes bugfixes?

Do people use GitHub stars for something? Sometimes I star things but I have no idea what it does or why I do it.