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.
This reads like somebody was placing way too much personal mental value on “the repo for my project has a large number of stars”
Your comment reads like you don't understand how a community works.
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.
Those most likely lost to the wind forever are the ones that star a repo and forget about it.
I think the problem self corrects but agree there's a short term slowdown possibility in the wake.
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.
"Do you want to delete this?"
"Yes"
"Are you sure?"
"Yes."
....
"OMG it's all gone!?!?"
I've had a very different experience around stars - they're just a bit of fluff and pretty unimportant compared to watches.
If the watchers still care to watch, they can choose to watch again.
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?
Typing in the number of objects that would be deleted in addition to the name is something else.
Or, they could just keep all of them in place, but hidden, and "restore" them all automatically if you made it public again.
There are lots and lots of things they could do better, if they cared. But paraphrasing Eunice, of course they don't care, they're Microsoft.
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.
Do you have any concrete evidence for this? A lot of people keep saying this but don't provide anything factual in the way of UX studies, etc.
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.
A Firefox use case w study and their approach.
https://medium.com/firefox-ux/designing-better-security-warn...
Good discussion of the problem:
https://ux.stackexchange.com/questions/44609/how-do-i-avoid-...
My takeaways are as follows:
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"
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.
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.
Here's a recent case of a nurse going to prison for a medication error, where the UX of the medical cabinets is blamed in a big way: https://khn.org/news/article/radonda-vaught-fatal-drug-error...
> 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.
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.
People making bad UIs make them that way regardless of consequences for users.
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?
Even using words like "future pain" is pretty crazy. "We lost 54k GitHub stars"? They're imaginary internet points! Cope.
Literally stop blaming with language like “GitHub deleted…”
> 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.
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?
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?
That's a much bigger failure than clicking the wrong button.
Humans make mistakes all the time. We build systems to try to mitigate these and build them better by learning from new mistakes.