That'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.
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'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.
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 / 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”
So all those people got notifications and then some of them looked further at the notifications and then engaged. Now those people won't get those notifications and won't engage. Most of these people won't notice they don't get these notifications. They won't resubscribe. They're lost forever. This is kind of like losing your email list.
Your comment reads like you don't understand how a community works.
If the measure of community is “people who get my emails, and wouldn’t notice if they stopped getting my emails”, then yea, I guess we just disagree about what a community is.
I’m on an email list for marketing message for a hotel I stayed at last year. TIL that I’m part of their community.
If you focus solely on the getting notifications part. But the core part of any community is the ability to broadcast news to them. If you remove the ability to broadcast news and falicate communication between members then the community fades. Especially, if it's remove.
Not all members of a community are extremely active, some aren't that active at all if you remove the ability to let the less active people know stuff that may be of interest to them then obivously it'll damage a community.
You don't get notifications after starring a repo, they're only a measure of how popular the repo is. The repo did legitimately lose its Watchers, but the author seems a lot more concerned about losing (and getting back) the stars.
There's a repo-user join table that is gone. That's literal data loss. If I delete your contacts, is that data loss? I mean, you still have your phone and all your ex-contacts still have phone numbers.
Have you been living under a rock? Everyone judges repos by their amount of stars. Why do you think every social media network has the concept of likes?
They didn't burn a diary. They burnt the list of people who subscribed to updates to a diary. If those people still care about the diary, they can resubscribe to those updates.
It's crazy to me how quickly this conversation has devolved. If Pewdiepie had all his Youtube subscribers deleted should he just say "oh well, the ones that like me will come back". No. Because that's an absurd attitude. Obviously that would forever hurt his viewership. Github is no different with stars. They matter. Period. Maybe not to you. But they matter.
Pewdiepie's compensation is intrinsically related to his subscriber count, no? That gives him a reason to care. Is your compensation similarly related to your github star count? I sure hope not..
If I unstar your repo, I have not taken anything from you because you never owned my star in the first place. Github presents this number to you as though it were important, to give you a dopamine hit when the number goes up. Their motivation for doing this is obvious. If you fall for this trick, that's on you. You have the choice to stop caring.
And even if the premise of these metrics being important were accepted, the fact remains that the removal of people from the watchers list is not irreversible. No irreplaceable documents were destroyed. No diaries were burned. If the repository had been deleted, commit history erased, that would be comparable to a diary burning. But that's not what happened (and would probably still be reversible.)
For which to happen you've to do the same thing: type out its name. So I wonder if people ask for privatize to be presented with number of stars, should when deleting a repo GitHub present you with number of commits, issues, releases, etc as well?
It'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.
This is explicitly addressed in the article, and a compelling case is made for why that safety measure was ineffective in this case, I encourage you to read the article
> There was an explicit suggestion right there in the article what else they could do, so you don't even have to guess.
I read it, but I disagree.
Honestly I don't think it would have prevented this. If you're muscle memorying past warning signs the text on the warning sign isn't going to matter much.
My point was purely about UX, obviously there are technical solutions to this problem.
Well it's exactly what happened in this case. The user got a sort of warning fatigue with the UX and familiarity with it made it easy to do without much internal debate.
But I think some other UI flaws contribute to that in this case.
Comfort with a UI means eventually you want it to get out of your way and your brain will do what it needs to streamline the process. At which point those elements intended to break the flow of the app no longer do.
The best thing to do is provide undo. Then you can reduce the hoops people have to jump through because the consequences are less severe.
Simplify the modal so the text about what will happen stands independently enough to be parsec on first glance.
Show quantified data on what could happen. Instead of "you will lose all followers" which is true for any app, display "you will lose all 54,318 followers"
Having read through the article I'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.
With that mindset, planes would still fall out of the sky every month. Because basically 90% of plane crashes used to be "pilot error". If you then say, well, it was pilot error, bad pilot, can't do anything about it, that's the way it is, pilot should've not made an error... well, then we wouldn't have reached the amazing aviation safety we have now.
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 "oxygen" knob on the anesthetist's gas panel not go to zero. But it appears lots of people here can't imagine why that change was made.
Pilots and doctors are two great examples of customer pools where UI/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 "correctness" of dark patterns.
UI/UX often gets overlooked as being unimportant, and, as a backend person I can definitely sympathize, but when you're building a product that people use for important things it is important to give UI/UX the attention it deserves.
> The case against Vaught hinges on her use of an electronic medication cabinet, a computerized device that dispenses drugs and is widely used in hospitals
>
> ...
>
> Vaught triggered an override that unlocked a much larger swath of medications
>
> ...
>
> Some experts have said cabinet overrides are a daily event at many hospitals.
>
> Vaught insisted in her testimony before the nursing board last year that overrides were common at Vanderbilt, and that a 2017 upgrade to the hospital’s electronic health records system was causing rampant delays at medication cabinets. Vaught said Vanderbilt instructed nurses to use overrides to circumvent delays and get medicine as needed.
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 "autopilot".
That's a completely different situation and defending learned stupidity of just clicking ok to everything.
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's fault for creating a system where an operator error is likely. OTOH stars are such a vanity metric that i can't be bothered to feel too sympathetic because who cares about stars?
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”?
Drop passive aggressive comments like the one about how they'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 "future pain" is pretty crazy. "We lost 54k GitHub stars"? They're imaginary internet points! Cope.
> Due to an unfortunate sequence of events, I accidentally made the project’s repository private for a moment. And GitHub cascade-deleted our community that took 10 years to build.
This reads the same, to me, in terms of cause and effect.
I’m sincerely struggling to understand - what is changed by referring to Github as the subject of the second sentence, as opposed to leaving out Github in the version you proposed?
People frequently use the passive voice when referring to how software works. Like, “I entered my PIN and the phone unlocked”. “I entered my PIN and the phone unlocked itself” is maybe common too, but less common is “I entered my PIN and iOS unlocked my phone” or “I enter my pin and Apple unlocked my phone”[0].
Using the active voice shifts responsibility and autonomy for the action away from the author and onto GitHub. (Which, I mean, is exactly what the author was trying to do I think. But we were talking about ways the post could be changed to do that less.)
[0]: This is confounded a bit by GitHub being both the name of the software and the company. In context though I believe they meant the company?
Thank you for a patient explanation. I see that using passive voice leaves out all other decisions, choices, influences, etc. And I agree that active voice is a shift to bring those into the mix.
I think the point I’m hung up on is I just don’t see blame in my version. I sincerely read it as a factual retelling, including GitHub (the software) as an agent that responds to commands and performs them. It makes me wonder where the borderline (if there is one?) would be between statements that convey neutrality versus seeming to be accusations (perhaps unintentionally and undetectably).
I am curious what you do see as GitHub the company’s contributing actions to the overall situation. And where the accusation line might be.
Clearly someone or some group of someones at Github built the functionality. And, in so doing, made it possible for an accidental deletion situation to exist, even if at the time they did it completely in good intention and with included warnings.
At some point though, Github themselves deleted data on their own repo by taking it private. They followed up by restoring their data, and not changing the dialog to be more clear.
Are any of these statements blaming, to your eyes/ears?
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.
