We lost 54k GitHub stars(httpie.io)
httpie.io
We lost 54k GitHub stars
https://httpie.io/blog/stardust
696 comments
I specifically dislike the "Lessons" section, as it throws all the blame on github and doesn't mention the seemingly obvious advice: "make sure you're not on autopilot when taking potentially dangerous actions, on github or any website".
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'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't paying enough attention to notice they had typed the entirely wrong repo into the confirmation box.
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'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't paying enough attention to notice they had typed the entirely wrong repo into the confirmation box.
I suggest you read "The Field Guide to Understanding 'Human Error'". You'd learn a lot.
https://www.amazon.com/Field-Guide-Understanding-Human-Error...
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.
https://www.amazon.com/Field-Guide-Understanding-Human-Error...
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.
This, 1000x this.
It's easy to be an armchair engineer and say "well, obviously, don't make this mistake in the future".
As a species, we will always take shortcuts. If a mental pathway doesn't need to be exercised to do something, it won't be. If we see the same popup a hundred times, we're going to ignore the contents by the 100th time because we're used to it.
But it shouldn't be possible to make this mistake if this was designed properly and in a way that made it clear that what you're about to do is actually dangerous and not "dangerous" like the other dozen times you've seen the same message.
It's easy to be an armchair engineer and say "well, obviously, don't make this mistake in the future".
As a species, we will always take shortcuts. If a mental pathway doesn't need to be exercised to do something, it won't be. If we see the same popup a hundred times, we're going to ignore the contents by the 100th time because we're used to it.
But it shouldn't be possible to make this mistake if this was designed properly and in a way that made it clear that what you're about to do is actually dangerous and not "dangerous" like the other dozen times you've seen the same message.
Yeah. A warning that can be pattern matched by a human brain, that is just a routine action, will result in autopilot behavior. Flipping early repo visibility is common, I assume. Flipping visibility of 100+ star repos is likely much less common. So having a separate warning in that case might help you snap out of autopilot due to novelty.
A common knee-jerk reaction to "users aren't taking our warnings seriously" is making the warning look more scary and involving more (mechanical) steps – such as two confirmations instead of one. Well, that's pattern matchable and subject to desensitization.
Like the article states, it's more efficient to instead show what you're about to remove, i.e. a summary of the content as opposed to an identifier, then you get both novelty and proportional scariness, depending on how "big" it is.
https://en.m.wikipedia.org/wiki/Alarm_fatigue
A common knee-jerk reaction to "users aren't taking our warnings seriously" is making the warning look more scary and involving more (mechanical) steps – such as two confirmations instead of one. Well, that's pattern matchable and subject to desensitization.
Like the article states, it's more efficient to instead show what you're about to remove, i.e. a summary of the content as opposed to an identifier, then you get both novelty and proportional scariness, depending on how "big" it is.
https://en.m.wikipedia.org/wiki/Alarm_fatigue
Pretty much agree— Universal human fallibility is not an avoidable moral failure, but looking down on those who've made, admitted, and taken responsibility for simple mistakes sure is. Unrealistic assumptions about people's attention, processing capability, and physical capabilities may be the greatest hurdle when trying to actually solve people's problems with software. It can even be a safety issue— consider the Therac 25 incident.
That said, superlatives like "impossible" aren't realistic here. As long as an action is possible, it is also possible to fuck it up. The challenge screen does require typing in the repo name which is a pretty solid attention-getter. It would be nice to list the important side effects in big angry letters but I'll bet the list of side-effects that are important to some people would be pointlessly long. Maybe a sanity check requiring repos with extremes in certain metrics to get a sanity check from support first— but I have had some preeeeettty protracted response times from GitHub support.
That said, superlatives like "impossible" aren't realistic here. As long as an action is possible, it is also possible to fuck it up. The challenge screen does require typing in the repo name which is a pretty solid attention-getter. It would be nice to list the important side effects in big angry letters but I'll bet the list of side-effects that are important to some people would be pointlessly long. Maybe a sanity check requiring repos with extremes in certain metrics to get a sanity check from support first— but I have had some preeeeettty protracted response times from GitHub support.
> I'll bet the list of side-effects that are important to some people would be pointlessly long.
There's many good ways to design this that wouldn't result in pointlessly long lists (which is another problem). You don't need to expose everything that will happen when you do an action, just the "most important".
With unlimited budget, you could compare a bunch of metrics to a baseline to figure out what might be important. Have a lot of stars, way more than the average? That would be nice to highlight. Only have a normal number of forks? Probably less important to highlight that. At the end of the day, Github repos aren't extremely unique. Sure there's probably extremely rare edge cases, but for most repos, comparing against a relatively small number of metrics should get enough to paint a picture of what might get broken. Everything else can be hidden behind a "... and X more" if people are curious.
This both highlights the most important things that might happen, and also provide people with an action to do before confirming, hopefully helping to break the autopilot at the same time.
There's many good ways to design this that wouldn't result in pointlessly long lists (which is another problem). You don't need to expose everything that will happen when you do an action, just the "most important".
With unlimited budget, you could compare a bunch of metrics to a baseline to figure out what might be important. Have a lot of stars, way more than the average? That would be nice to highlight. Only have a normal number of forks? Probably less important to highlight that. At the end of the day, Github repos aren't extremely unique. Sure there's probably extremely rare edge cases, but for most repos, comparing against a relatively small number of metrics should get enough to paint a picture of what might get broken. Everything else can be hidden behind a "... and X more" if people are curious.
This both highlights the most important things that might happen, and also provide people with an action to do before confirming, hopefully helping to break the autopilot at the same time.
Warnings are good but not perfect. At the end of the day, you can’t help everyone with just warnings. You could make the UI bright flashing red, with a skull and crossbones, have it say “Never invoke this: it will delete all your data and kill your dog. Please type ‘I_WANT_CANCER’ to continue.” And users will do it. It can’t be helped. The only (admittedly hard) way is UNDO.
Undo. If it's possible, you want undo. If it's difficult, you still want undo. Only when you've satisfied yourself that it's outright impossible should you reluctantly design the UX with the "Are you sure?" prompt instead.
Also, if you must have I_WANT_CANCER type prompts, try to make them involve expressing what it is that the human is agreeing to, because sometimes it's only at that point the human realises their plan was very stupid. GitHub does that here (you have to type the name of the repo, to delete main_project you'll need to type main_project) but many things do not.
This is why I like Git's force-with-lease. When I try to forcibly overwrite the state, because I know Jim's push was wrong and must be undone, force-with-lease makes me express that, "--force-with-lease=jim-daft-change". And when in fact what I'm going to overwrite is Lisa's urgent bug fix, not Jim's erroneous change, the force-with-lease fails and to get it to apply this way I'd need to say "--force-with-lease=lisa-bug-fix" and that's one last opportunity to say "Wait, what? That's not what I want to do".
Also, if you must have I_WANT_CANCER type prompts, try to make them involve expressing what it is that the human is agreeing to, because sometimes it's only at that point the human realises their plan was very stupid. GitHub does that here (you have to type the name of the repo, to delete main_project you'll need to type main_project) but many things do not.
This is why I like Git's force-with-lease. When I try to forcibly overwrite the state, because I know Jim's push was wrong and must be undone, force-with-lease makes me express that, "--force-with-lease=jim-daft-change". And when in fact what I'm going to overwrite is Lisa's urgent bug fix, not Jim's erroneous change, the force-with-lease fails and to get it to apply this way I'd need to say "--force-with-lease=lisa-bug-fix" and that's one last opportunity to say "Wait, what? That's not what I want to do".
It's a real strength of Gmail and some other Google interfaces — undo instead of warning dialog.
I think from UX perspective it is unbelievably more convenient as well. Plain popup warnings with "press Ok if you mean it" are bad enough, but quite recently the new even worse "type delete, if you want to delete, then press Ok" popup has been spreading about... If I want to delete over a couple of things I get incredibly irked.
There are a couple of issues with UNDO too:
- (not intrinsic) many interfaces only give you a few seconds to undo your action, which wouldn't help in this case
- (intrinsic) some events can be layered on top of your change, meaning that you have to either block the undo or reverse all the subsequent events too. This wouldn't be the case for this HTTPie incident, but does prevent UNDO functionality from being a silver bullet.
- (not intrinsic) many interfaces only give you a few seconds to undo your action, which wouldn't help in this case
- (intrinsic) some events can be layered on top of your change, meaning that you have to either block the undo or reverse all the subsequent events too. This wouldn't be the case for this HTTPie incident, but does prevent UNDO functionality from being a silver bullet.
You assume the metrics you have are sufficient to determine intent and importance, that your users needs are uniform enough for those determinations apply, and discount the possibility of making things worse by communicating the wrong thing. These assumptions perennially land developers and inexperienced designers in hot water designing things like this.
> "most important"
Yes— the problem is determining the most important metrics for the human who's reading the dialog. Sorting the second part is a lot more difficult than the first.
> With unlimited budget
This framing is only useful to determine what behaviors would be great, not feasibility. We seem to both agree on the ideal behavior but not on the feasibility.
> you could compare a bunch of metrics to a baseline to figure out what might be important.
Important to whom?
> Have a lot of stars, way more than the average? That would be nice to highlight. Only have a normal number of forks? Probably less important to highlight that.
Average for what? Just average for everybody? For the deprecated SlackTextViewController which has vastly higher numbers overall than the unmeasurably more important net-snmp? What about for repos that serve as core functionality to frameworks that only care about forks? XML Schemas that people refer to but never interact with? What about for a company that doesn't care about stars because they're incredibly popular outside of that repo but it's critical for them to monitor the small number of people who've forked their repo?
> Sure there's probably extremely rare edge cases, but for most repos, comparing against a relatively small number of metrics should get enough to paint a picture of what might get broken.
The repo about which you said this mistake should not have been possible was an extremely rare edge case. The article went to great lengths to explore just how fantastically different this repo was. And if you're talking about painting pictures you're using the wrong medium. More information can make the message more pointed but only if it's brief and extremely relevant. If it's not, it's going to reduce the focus on the danger message.
> Everything else can be hidden behind a "... and X more" if people are curious.
Aaaand we come full circle. The whole point of this is to put the metrics most important to that user right in front of their face in bold type because that's going to stop autopilot mistakes. If it's hidden, it failed. Beyond that, the order in which you list things connotes importance— closer to the beginning means more important. Being hidden connotes far lesser importance. If you put the wrong things at the top and the right things behind a click then the autopilot user subconsciously assumes they'd care about the hidden things even less. You're increasing the risk of failure rather than decreasing it. If you're going to highlight anything, you better highlight the right thing.
The existing dialog is pretty clear that you should investigate what it does before you actually execute the command without giving people false clues, and that may be the best compromise. You don't convey false impressions but still convey danger.
> At the end of the day, Github repos aren't extremely unique.
From a quantitative perspective they're not incredibly diverse, even if they're probably more diverse than you imagine. What is immeasurably diverse is the roles those software packages serve, the people who interact with them, and what they need to accomplish their goals. Assuming you can boil that down to a heuristic using available data is something that needs to be concretely proven— not assumed.
> "most important"
Yes— the problem is determining the most important metrics for the human who's reading the dialog. Sorting the second part is a lot more difficult than the first.
> With unlimited budget
This framing is only useful to determine what behaviors would be great, not feasibility. We seem to both agree on the ideal behavior but not on the feasibility.
> you could compare a bunch of metrics to a baseline to figure out what might be important.
Important to whom?
> Have a lot of stars, way more than the average? That would be nice to highlight. Only have a normal number of forks? Probably less important to highlight that.
Average for what? Just average for everybody? For the deprecated SlackTextViewController which has vastly higher numbers overall than the unmeasurably more important net-snmp? What about for repos that serve as core functionality to frameworks that only care about forks? XML Schemas that people refer to but never interact with? What about for a company that doesn't care about stars because they're incredibly popular outside of that repo but it's critical for them to monitor the small number of people who've forked their repo?
> Sure there's probably extremely rare edge cases, but for most repos, comparing against a relatively small number of metrics should get enough to paint a picture of what might get broken.
The repo about which you said this mistake should not have been possible was an extremely rare edge case. The article went to great lengths to explore just how fantastically different this repo was. And if you're talking about painting pictures you're using the wrong medium. More information can make the message more pointed but only if it's brief and extremely relevant. If it's not, it's going to reduce the focus on the danger message.
> Everything else can be hidden behind a "... and X more" if people are curious.
Aaaand we come full circle. The whole point of this is to put the metrics most important to that user right in front of their face in bold type because that's going to stop autopilot mistakes. If it's hidden, it failed. Beyond that, the order in which you list things connotes importance— closer to the beginning means more important. Being hidden connotes far lesser importance. If you put the wrong things at the top and the right things behind a click then the autopilot user subconsciously assumes they'd care about the hidden things even less. You're increasing the risk of failure rather than decreasing it. If you're going to highlight anything, you better highlight the right thing.
The existing dialog is pretty clear that you should investigate what it does before you actually execute the command without giving people false clues, and that may be the best compromise. You don't convey false impressions but still convey danger.
> At the end of the day, Github repos aren't extremely unique.
From a quantitative perspective they're not incredibly diverse, even if they're probably more diverse than you imagine. What is immeasurably diverse is the roles those software packages serve, the people who interact with them, and what they need to accomplish their goals. Assuming you can boil that down to a heuristic using available data is something that needs to be concretely proven— not assumed.
Anyone wanting to dig deeper into the design side of this should check out Triadic Semiotics— it's the philosophy of signs.
It sounds like you've never been part of an engineering organization (I know you have since you bring up unlimited budget ;)
It is obviously possible to design a much better, contextual warning with (more) relevant details highlighted. How much time is usually set aside for those?
And yet, it's never going to stop mistakes.
And how many other places like these are there in a large service like GitHub?
A much better way to fix this is to expect mistakes and make it possible to revert instead. Soft deletes can make that trivial to implement for the most part too (except in GDPR like cases where you've got to really remove stuff).
It is obviously possible to design a much better, contextual warning with (more) relevant details highlighted. How much time is usually set aside for those?
And yet, it's never going to stop mistakes.
And how many other places like these are there in a large service like GitHub?
A much better way to fix this is to expect mistakes and make it possible to revert instead. Soft deletes can make that trivial to implement for the most part too (except in GDPR like cases where you've got to really remove stuff).
Even for GDPR stuff you can delay the hard delete for a day or so, which should give the user some time to notice and correct a mistake.
> The challenge screen does require typing in the repo name which is a pretty solid attention-getter.
This is not quite correct. In requires inputting the repo name. It's attention-getting the first time. But recently with some colleagues as part of a handoff we went through 50+ repos and archived the irrelevant ones. Very quickly the person doing the actual archiving went from typing to just copy-pasting the repo names. For programmers, copy-pasting from one spot to another can become very mechanical.
So I think this UI choice works well for something that is done very occasionally. But it's no better if people are in the habit. Whereas showing novel information about the cost of the choice would be helpful in breaking the routine. Then could then also make it so that they had to type something only when the operation has a high cost, and what they typed could be something not directly copy-pasteable.
This is not quite correct. In requires inputting the repo name. It's attention-getting the first time. But recently with some colleagues as part of a handoff we went through 50+ repos and archived the irrelevant ones. Very quickly the person doing the actual archiving went from typing to just copy-pasting the repo names. For programmers, copy-pasting from one spot to another can become very mechanical.
So I think this UI choice works well for something that is done very occasionally. But it's no better if people are in the habit. Whereas showing novel information about the cost of the choice would be helpful in breaking the routine. Then could then also make it so that they had to type something only when the operation has a high cost, and what they typed could be something not directly copy-pasteable.
That's fine. The goals of designing a sanity check prompt to snap people out of autopilot are entirely different from goals you might have in a security system— their being defeatable isn't even a flaw. Jersey barriers vs rumble strips.
If someone deliberately doing the same thing over-and-over can avoid the manual effort, that's fine. Their frustration would likely make them think about it less. You don't, and shouldn't get prompted to do the same thing using the API, either.
If someone deliberately doing the same thing over-and-over can avoid the manual effort, that's fine. Their frustration would likely make them think about it less. You don't, and shouldn't get prompted to do the same thing using the API, either.
That’s not quite it. The solution isn’t to stop them from doing it or warning them more aggressively; it’s to make it genuinely less dangerous. For example, make the stars all come back when you reverse the switch.
Of course that’s a lot harder to do, since it’s a lot more than a UX change. So I’m not really slagging GitHub here. But it’s the right way to attack this problem.
Of course that’s a lot harder to do, since it’s a lot more than a UX change. So I’m not really slagging GitHub here. But it’s the right way to attack this problem.
True "Undo" is, IMO, a pipe dream for all but brand new projects. That will pretty much require you to rearchitect a decent chunk of anything that wasn't built with it explicitly in mind.
In this case, I don't quite understand why stars and forks need to be deleted when switching visibility, since it seems like the two shouldn't be linked. I can star and fork my private repos just fine, so it seems like it was just easier to clear it out than to deal with RBAC at that level.
In this case, I don't quite understand why stars and forks need to be deleted when switching visibility, since it seems like the two shouldn't be linked. I can star and fork my private repos just fine, so it seems like it was just easier to clear it out than to deal with RBAC at that level.
I don't think any fork was deleted. 3.5k forks as of now vs 3.4k forks in January: https://web.archive.org/web/20220129022012/https://github.co...
Many people won't notice some of their stars having disappeared, but many would be surprised to see their forks deleted without their consent, especially those that are not merely a mirror. People can have diverged forks after adding substantial changes without feeding them back to the original for a variety of reasons.
Many people won't notice some of their stars having disappeared, but many would be surprised to see their forks deleted without their consent, especially those that are not merely a mirror. People can have diverged forks after adding substantial changes without feeding them back to the original for a variety of reasons.
Then don't "do" the delete, when the users "do" the delete.
Pretend to do it, actually do it 24 hours later, and if they "undo" the delete within that time frame, just remove it from the delete queue process.
Pretend to do it, actually do it 24 hours later, and if they "undo" the delete within that time frame, just remove it from the delete queue process.
Just not deleting them in the first place, or not deleting them until explicitly asked to, would suffice, and would be, ultimately, less code. So, I am not buying the apologetics.
It seems to me that services that pretend to delete data but don't actually do it are usually subject to criticism on Hacker News, not praise.
The issue tend to be services who are not upfront about it. "This is potentially really damaging, so in case it's a mistake we'll just hide it for 24 hours during which you can undo" or something to that effect would be sufficient.
You did not read the comment you replied to. Why? And then, why reply?
The counterpoint is that tools like that can be abused. Just as a hypothetical, if I have an open source product and do something the community doesn't like, I can make the repo private til the storm blows over so people can't un-star it. The number of people that remember to un-star it a week or two later is going to be a lot less.
I still think you're right, but it's not even as simple as UX and small backend changes. Allowing the repo owner to re-play other peoples' actions comes with complicated policy decisions. GitHub could make it so only support can restore those, but now they're in the awkward position of having to say when it's okay to restore and when it isn't. Still, it may be the best compromise.
I still think you're right, but it's not even as simple as UX and small backend changes. Allowing the repo owner to re-play other peoples' actions comes with complicated policy decisions. GitHub could make it so only support can restore those, but now they're in the awkward position of having to say when it's okay to restore and when it isn't. Still, it may be the best compromise.
> It's easy to be an armchair engineer and say "well, obviously, don't make this mistake in the future".
It's sort of equally easy to say Github should do X or Y to improve the UX in this (rare?) case without actually knowing the effort or opportunity cost.
Like maybe I'd rather Github figure out how to not have outages so frequently and how to not accidentally give people million+ dollar bills and such.
It's sort of equally easy to say Github should do X or Y to improve the UX in this (rare?) case without actually knowing the effort or opportunity cost.
Like maybe I'd rather Github figure out how to not have outages so frequently and how to not accidentally give people million+ dollar bills and such.
> Like maybe I'd rather Github figure out how to not have outages so frequently and how to not accidentally give people million+ dollar bills and such.
I doubt the engineers working on the stability issues or billing have anything to do with UX and vice versa. It's not like there's a singular focus that everyone at the company must prioritize above all else. Multiple people can work on multiple projects and not impact one another at all.
I doubt the engineers working on the stability issues or billing have anything to do with UX and vice versa. It's not like there's a singular focus that everyone at the company must prioritize above all else. Multiple people can work on multiple projects and not impact one another at all.
On one hand you have millions of users who each are obliged to walk on eggshells.
On the other, you have a few Microsoft hacks who could easily do the right thing on behalf of those millions of users.
On the other, you have a few Microsoft hacks who could easily do the right thing on behalf of those millions of users.
I am surprised so many people treat losing stars as "dangerous": I can certainly emphatize with the designer coming up with this pop-up while looking at a sample project with 12 stars.
Considering this project was out of ordinary in having 54k stars (article mentions being in top 80), they should not be surprised that their case is not top of mind.
Sure, it would be nice to highlight the most destructive of actions, but they already had to type out full project path as confirmation.
I do believe it would be better if Github allowed restoring data in the next few days (soft deletes ftw) once they hit this issue themselves in the past.
And Github support should have recognized that this project is a special, out of ordinary project, and afforded it some engineering time to restore everything.
Considering this project was out of ordinary in having 54k stars (article mentions being in top 80), they should not be surprised that their case is not top of mind.
Sure, it would be nice to highlight the most destructive of actions, but they already had to type out full project path as confirmation.
I do believe it would be better if Github allowed restoring data in the next few days (soft deletes ftw) once they hit this issue themselves in the past.
And Github support should have recognized that this project is a special, out of ordinary project, and afforded it some engineering time to restore everything.
> I am surprised so many people treat losing stars as "dangerous": I can certainly emphatize with the designer coming up with this pop-up while looking at a sample project with 12 stars.
Lots and lots of websites and companies use the number of stargazers as a strangely important metric for success, so losing them can be really bad.
Lots and lots of websites and companies use the number of stargazers as a strangely important metric for success, so losing them can be really bad.
[deleted]
But still, I also share the opinion that GitHub's UX for dangerous actions on a repository is currently already best in class, so blaming them for your mistakes is pretty unfair. To make your repo private, you have to:
- click "change visibility" in the "Danger Zone" area of the settings.
- select "make private" with an additional warning shown that you will lose all stars and watchers. Ok, maybe it should mention how many.
- type the name of the repo into a box and then click "I understand, change repo visibility".
And yes, sometimes it is important to expect humans to not make mistakes. For example, at railway crossings. Even if you drove over it 100 times and no train came, the 101th time you may still die if you don't check for a train before crossing.
- click "change visibility" in the "Danger Zone" area of the settings.
- select "make private" with an additional warning shown that you will lose all stars and watchers. Ok, maybe it should mention how many.
- type the name of the repo into a box and then click "I understand, change repo visibility".
And yes, sometimes it is important to expect humans to not make mistakes. For example, at railway crossings. Even if you drove over it 100 times and no train came, the 101th time you may still die if you don't check for a train before crossing.
> And yes, sometimes it is important to expect humans to not make mistakes. For example, at railway crossings. Even if you drove over it 100 times and no train came, the 101th time you may still die if you don't check for a train before crossing.
For somebody going through a railway crossing, yes, they shouldn't allow themselves to be prone any mistakes there. However, for the people involved in the construction of the railway crossing, they should certainly expect everyone to screw up and scrutinize the safety. We don't want to leave anything affecting livelihoods to chance.
"On average, each year around 400 people in the European Union and over 300 in the United States are killed in level crossing accidents."
https://en.wikipedia.org/wiki/Level_crossing#Safety
For somebody going through a railway crossing, yes, they shouldn't allow themselves to be prone any mistakes there. However, for the people involved in the construction of the railway crossing, they should certainly expect everyone to screw up and scrutinize the safety. We don't want to leave anything affecting livelihoods to chance.
"On average, each year around 400 people in the European Union and over 300 in the United States are killed in level crossing accidents."
https://en.wikipedia.org/wiki/Level_crossing#Safety
[deleted]
That's why a level crossing has a barrier that's only there when a train is approaching. Imagine the barrier was always there; that would be asking for people to ignore it.
This idea - fixing systems that amplify mistakes into large, irreversible impacts-- is why I am against alcohol, marijuana and other mental-state altering drugs for recreational purposes. (I'm not talking about people who really need pain relief from cancer, amphetamines for ADHD, etc.)
If no one in the world drank, smoked pot, or did drugs, how much better off would we all be? 100,000 deaths come from alcohol use every year in the United States alone[1]. That doesn't even account for countless cases of abuse, broken families, crime, and other negative effects of alcohol and drugs.
So many people say "oh well it's fine if I do it, I'm responsible" but then at some point someone isn't fine and isn't as responsible as they think they are.
[1] https://www.cdc.gov/alcohol/features/excessive-alcohol-death....
If no one in the world drank, smoked pot, or did drugs, how much better off would we all be? 100,000 deaths come from alcohol use every year in the United States alone[1]. That doesn't even account for countless cases of abuse, broken families, crime, and other negative effects of alcohol and drugs.
So many people say "oh well it's fine if I do it, I'm responsible" but then at some point someone isn't fine and isn't as responsible as they think they are.
[1] https://www.cdc.gov/alcohol/features/excessive-alcohol-death....
> If no one in the world drank, smoked pot, or did drugs, how much better off would we all be?
Perhaps that's true for your definition of "better off", which is perfectly fine, but it isn't universal. Even though I don't do drugs, I don't think it should be anyone's business to police what other people do with their minds and their bodies on their own time, as long as they don't pose a threat to anyone else.
Perhaps that's true for your definition of "better off", which is perfectly fine, but it isn't universal. Even though I don't do drugs, I don't think it should be anyone's business to police what other people do with their minds and their bodies on their own time, as long as they don't pose a threat to anyone else.
You haven't really thought this through.
One, those substances are fine for a lot of people.
Two, some of those substances are fine for most anybody. I've never even heard of a deadly marijuana overdose, and the evidence shows no increase in mortality for marijuana users.
Three, we already tried alcohol prohibition, and we are currently trying drug prohibition. It does not solve he problem you care about, while creating other large problems.
So really, you sound like somebody who has a personal hobbyhorse and uses pretty much anything (like say, losing stars on GitHub or mentioning a book on airplane safety investigations) to argue for it. And that sort of motivated reasoning around argument for societal change strikes me as way more dangerous than somebody eating a THC edible.
One, those substances are fine for a lot of people.
Two, some of those substances are fine for most anybody. I've never even heard of a deadly marijuana overdose, and the evidence shows no increase in mortality for marijuana users.
Three, we already tried alcohol prohibition, and we are currently trying drug prohibition. It does not solve he problem you care about, while creating other large problems.
So really, you sound like somebody who has a personal hobbyhorse and uses pretty much anything (like say, losing stars on GitHub or mentioning a book on airplane safety investigations) to argue for it. And that sort of motivated reasoning around argument for societal change strikes me as way more dangerous than somebody eating a THC edible.
I'm scared to see what your sanitized world would look like. Some of the most interesting art, music, and personal perspective has come from the consumption of the substances you deride as unnecessary and destructive.
How much art, science and deep, personal perspectives were lost due to abuse and death stemming from substance abuse? In case of certain substances (like alcohol) we have rather hard statistics about it's overal impact on physical and mental condition of society. Slow change from alcohol to safer alternatives (ex. cannabis) is probably one of the best trends in current times.
How many lives were saved or changed for the 'better' through the escape of, enjoyment of or numbing with drugs and alcohol? Who knows?
Perhaps if we think more like adults instead of infants we can try to understand complex issues better instead of reinforcing black and white stereotypes of the world or rehashing whatever our favourite source of ignorance tells us.
Perhaps if we think more like adults instead of infants we can try to understand complex issues better instead of reinforcing black and white stereotypes of the world or rehashing whatever our favourite source of ignorance tells us.
I think that do-gooders who have a "Great New Idea" for how to make society better are 1000x more dangerous than any type of drug ever invented. People drunk on alcohol mostly fall asleep harmlessly. People drunk on power and how awesome their own ideas are launch prison-industrial complexes, dystopian enforcement schemes, wars, genocides, etc.
It may be an even worse drug. People on drugs mostly have some awareness that their ideas aren't very good. But for those drunk on power, the fact that their same great idea has already been tried and led to total disaster is no cause for concern at all. You see, they're obviously smarter and better than the last batch of power-addicts who tried that, so they'll do it right this time. Heaven help us if we ever discovered a chemical intoxicant that was capable of making people that deluded.
It may be an even worse drug. People on drugs mostly have some awareness that their ideas aren't very good. But for those drunk on power, the fact that their same great idea has already been tried and led to total disaster is no cause for concern at all. You see, they're obviously smarter and better than the last batch of power-addicts who tried that, so they'll do it right this time. Heaven help us if we ever discovered a chemical intoxicant that was capable of making people that deluded.
An interesting thought experiment - how many of us would be here at all if not for alcohol? Ignoring butterfly effect aspects, the number of people who were only conceived due to decisions made under the influence of drugs would surely be very large even today, let alone prior to the availability of birth control.
[deleted]
So, displaying an additional or more explicit warning that mentions stars and watchers makes sense. No arguing, hope they do that. But to me also, it left a little bit of a bad aftertaste that the author completely skips over the part of that process where you have to enter the repository name right where they show the two screenshots side by side.
Anecdotal: You have to enter the full name for a couple destructive actions on GitHub, and every time I had to do it was so jarring to me that I stopped everything, rechecked what I'm doing twice, started wondering if I might be dreaming, am on drugs or a voice in my head is telling me to do something dumb. Like, yes we should improve nonetheless, and I usually try to put myself into other people's shoes before judging them, but this is just one of the few times where I just can't help but, you know, think it was somewhat dumb to make this mistake with the current system in place. Like, next time we have this stars and watchers warning in place and still someone will manage to proceed on autopilot, what do we do next? Have a siren sound go off in addition? Have the user enable their mic and spell out the repo name? Send a written letter to GitHub? You'll never get the error rate to 0, at which point would you rather accept people making mistakes and calling them out on it than adding more inconvenience on top that just bothers everybody else?
Anecdotal: You have to enter the full name for a couple destructive actions on GitHub, and every time I had to do it was so jarring to me that I stopped everything, rechecked what I'm doing twice, started wondering if I might be dreaming, am on drugs or a voice in my head is telling me to do something dumb. Like, yes we should improve nonetheless, and I usually try to put myself into other people's shoes before judging them, but this is just one of the few times where I just can't help but, you know, think it was somewhat dumb to make this mistake with the current system in place. Like, next time we have this stars and watchers warning in place and still someone will manage to proceed on autopilot, what do we do next? Have a siren sound go off in addition? Have the user enable their mic and spell out the repo name? Send a written letter to GitHub? You'll never get the error rate to 0, at which point would you rather accept people making mistakes and calling them out on it than adding more inconvenience on top that just bothers everybody else?
Most people in this thread seem to be ignoring another very major cause: the inconsistent naming for personal READMEs between users and organizations. Users have their README at username/username, but orgs have it at orgname/.github
Nothing else on GitHub is like this: orgs and users are treated as the same class of entity pretty much all the time. I could easily see myself making the same mistake on autopilot.
Nothing else on GitHub is like this: orgs and users are treated as the same class of entity pretty much all the time. I could easily see myself making the same mistake on autopilot.
They have a bunch of differences under the hood, particularly when you want to give perms. It makes sense, sort of, on its face, that a user can’t have teams, but why? That decision is pretty arbitrary, to me. Then in GHE, users and orgs have all sorts of fun differences when you consider things like internal/public/private and how people can interact with them; to wit, if you’re in ANY team you can see ANY internal repo in an org, but if you’re limited to just personal repos, you can see no such things.
> 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.
This is applicable to almost any activity: "Sure he was driving drunk, but the car's manufacturer should have prevented that from causing any damage!" I agree that GitHub should improve the design here - privating a '10 star / 1 week old' repo shouldn't be treated the same as privating a '50k star / 10 year old' repo. I don't mean to diminish the fact that GitHub's UI should be improved here.
But the author needs to take some responsibility and realize they were ""driving distracted"", and not act like GitHub is 100% at fault here. Just because GitHub didn't act perfectly doesn't mean the author didn't make any mistakes.
This is applicable to almost any activity: "Sure he was driving drunk, but the car's manufacturer should have prevented that from causing any damage!" I agree that GitHub should improve the design here - privating a '10 star / 1 week old' repo shouldn't be treated the same as privating a '50k star / 10 year old' repo. I don't mean to diminish the fact that GitHub's UI should be improved here.
But the author needs to take some responsibility and realize they were ""driving distracted"", and not act like GitHub is 100% at fault here. Just because GitHub didn't act perfectly doesn't mean the author didn't make any mistakes.
Neither the author, nor anybody that I can see here, is saying that the author didn't make any mistakes.
But what you are saying is that marginal effort to prevent mistakes is not worthwhile.
Cars, to take your example, would not be as safe as they are today if they followed the principles you've shown in this post and the grandparent. And yes, even when driving drunk, which is illegal, is safer too - stay in lane, adaptive cruise control, automatic braking, etc. have all incrementally made even extremely ill-advised behaviours safer.
But what you are saying is that marginal effort to prevent mistakes is not worthwhile.
Cars, to take your example, would not be as safe as they are today if they followed the principles you've shown in this post and the grandparent. And yes, even when driving drunk, which is illegal, is safer too - stay in lane, adaptive cruise control, automatic braking, etc. have all incrementally made even extremely ill-advised behaviours safer.
Yeah, it's a different story when dealing with safety.
With industrial machines you have to assume people will do the dumbest thing possible. Because someone will find a way to get crushed in a moving part if they can.
You have safety fence after safety fence and regularly test that your lockouts work.
If you don't do all of this and someone dies you can face very harsh legal penalties.
We don't do this with software when the cost of failure is so much lower but we should still understand smart humans will make mistakes.
With industrial machines you have to assume people will do the dumbest thing possible. Because someone will find a way to get crushed in a moving part if they can.
You have safety fence after safety fence and regularly test that your lockouts work.
If you don't do all of this and someone dies you can face very harsh legal penalties.
We don't do this with software when the cost of failure is so much lower but we should still understand smart humans will make mistakes.
In software often the cost is paid by other people (your users) and you don't (want to) see them. How much did the Atlassian outage cost it's clients altogether? How much thereof will they need to compensate?
Is that book still worth to spend time reading if I do understand what you are saying and I hold the same views? I'm always hungry to learn something useful from books, but more often than not I find these hyped books ("The Checklist Manifesto" comes to mind) really annoying in that they make me spend a significant amount of time reading stupid "curious life stories" to bring across a point that can be expressed in a 3 word sentence, like "checklists are good". And it's even worse when these are trivial truths most sane people would agree on, which doesn't make the "advice" more actionable, because it's just much easier said than done.
I mean, it would be disappointing to read it to find it summarizes exactly to what you just said.
I mean, it would be disappointing to read it to find it summarizes exactly to what you just said.
It's an incredibly rich book. I learned a ton from it. Indeed, I avoided summarizing it here precisely because it's hard to sum up.
My favorite is "let's imprison people who make mistakes". It doesn't stop mistakes, it just covers them up.
People are imprisoned when they are a danger to others or at risk of flight. Their time in prison is meant to reform them and help them back into society. The community is protected from further "mistakes" from a person, while allowing the person to learn not to make the same mistake again.
At least that is the idea.
At least that is the idea.
Some mistakes are accidents, some mistakes are made on purpose.
The latter needs some kind of consequence in place to offset the benefits from purposefully making said mistakes.
The latter needs some kind of consequence in place to offset the benefits from purposefully making said mistakes.
From the product's perspective speaking in aggregate, that is entirely correct.
From an individual user's perspective, you still need own your shit and avoid making these mistakes. You can't rely on everything you use having smart safeguards.
There will always be dumb/careless users that a product should consider. There will always be suboptimal UI (we could've just as easily been talking about CLI database tools) that a user should watch out for
From an individual user's perspective, you still need own your shit and avoid making these mistakes. You can't rely on everything you use having smart safeguards.
There will always be dumb/careless users that a product should consider. There will always be suboptimal UI (we could've just as easily been talking about CLI database tools) that a user should watch out for
It's not about whether human can make a mistake or not. It's about how much effort should be made to prevent a certain type of human mistakes.
If every system we're interacting daily should be fool-proof, it will requires enormous time and effort. Naturally, we invests more time and effort when it's about life and death situation. If we only lose 2 cents by our mistake, we just don't care.
Of course, I'd like to have more fool-proof design in all the destructive interactions from all websites. But, the question is, does it worth it?
If every system we're interacting daily should be fool-proof, it will requires enormous time and effort. Naturally, we invests more time and effort when it's about life and death situation. If we only lose 2 cents by our mistake, we just don't care.
Of course, I'd like to have more fool-proof design in all the destructive interactions from all websites. But, the question is, does it worth it?
[deleted]
There is also an audiobook version, for some reason not linked from there:
https://www.amazon.com/Field-Guide-Understanding-Human-Error...
https://www.amazon.com/Field-Guide-Understanding-Human-Error...
The penalty for sin is death.
> I specifically dislike the "Lessons" section, as it throws all the blame on github and doesn't mention the seemingly obvious advice: "make sure you're not on autopilot when taking potentially dangerous actions, on github or any website".
I don'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'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.
I don'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'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.
I found GitHub's Senior Director of DevRel on Twitter saying this:
> Sadly we can't easily do that without triggering lots of issue. We tried with a couple of projects in the past and found it caused a bunch of bad things to happen.
https://twitter.com/martinwoodward/status/149333028949351629...
> Sadly we can't easily do that without triggering lots of issue. We tried with a couple of projects in the past and found it caused a bunch of bad things to happen.
https://twitter.com/martinwoodward/status/149333028949351629...
Idk about "easily", but I'm sure they were motivated. If you've ever tried to restore parts of a database in a piecemeal fashion, it is usually fairly labor intensive. But you would hope there are a few gh engineers who would be motivated to do so without manager approval in the dead of night because httpie is great.
> But you would hope there are a few gh engineers who would be motivated to do so without manager approval in the dead of night because httpie is great
On the other hand, you should really, really, really hope that GitHub has internal guardrails to prevent their engineers making cowboy edits to the production databases without manager approval.
On the other hand, you should really, really, really hope that GitHub has internal guardrails to prevent their engineers making cowboy edits to the production databases without manager approval.
Haven't worked there, but I assume one engineer just needs one other engineer to approve their PR. I would be pretty surprised if it was more robust that that.
I haven't worked at GitHub either, but I did work at AWS, where a change to a production database required filing a detailed CM (change management form) with step-by-step details of the operations to be completed + monitoring criteria + rollback plans. That CM had to be approved by the senior eng staff of all affected teams, plus the full management chain, and in a high-profile issue like this, the PR/comms teams as well.
> Essentially, it'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.
Obviously it would be nice to see A similar response from GitHub regardless of whether the issue at hand is affecting themselves versus a member of their community. But, as long as humans are making the decisions, that’s probably a pipe dream. And honestly, policing could very well be the standard example of this.
Obviously it would be nice to see A similar response from GitHub regardless of whether the issue at hand is affecting themselves versus a member of their community. But, as long as humans are making the decisions, that’s probably a pipe dream. And honestly, policing could very well be the standard example of this.
> I specifically dislike the "Lessons" section, as it throws all the blame on github and doesn't mention the seemingly obvious advice: "make sure you're not on autopilot when taking potentially dangerous actions, on github or any website".
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.
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.
It’s not a “blame free postmortem” though. The author is blaming GitHub for not sending him a handwritten letter from the CEO inviting him not to do the stupid thing he positively affirmed he wanted to do.
The author also neglects to mention he had to type the full project name into a dialog box, which would be critical to any real postmortem. If typing the repo name into GitHub didn’t wake him up, why should we believe listing the number of stars would? The author said he thought he was in a different repo, but that makes no sense.
The real lesson, imo, is for people obsessed with stars to set up permissions, use dedicated accounts, and not toy around with settings you know are dangerous before you’ve had your coffee.
That’s a lot more reasonable than GitHub spending time to implement yet another warning box feature that the author has proved they can ignore regardless of how obvious GitHub makes it.
The author also neglects to mention he had to type the full project name into a dialog box, which would be critical to any real postmortem. If typing the repo name into GitHub didn’t wake him up, why should we believe listing the number of stars would? The author said he thought he was in a different repo, but that makes no sense.
The real lesson, imo, is for people obsessed with stars to set up permissions, use dedicated accounts, and not toy around with settings you know are dangerous before you’ve had your coffee.
That’s a lot more reasonable than GitHub spending time to implement yet another warning box feature that the author has proved they can ignore regardless of how obvious GitHub makes it.
The author is blaming GitHub for not sending him a handwritten letter from the CEO inviting him not to do the stupid thing he positively affirmed he wanted to do.
Please, quote from the article where you read this. I don't see it.
In the article I read, the author admits fault:
> I accidentally made the project’s repository private for a moment.
The author goes on to explain how they made the mistake.
> What put me on the wrong path was an otherwise completely unrelated action: I had just done the same (i.e., hidden an empty README) on my personal profile by making jakubroztocil/jakubroztocil private.
> GitHub’s conceptual model treats users and organizations as very similar entities when it comes to profiles and repos. 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.
> I didn’t realize at the moment there’s an inconsistency in the naming of this special repo containing profile READMEs and that it differs for users and organizations: name/name vs. name/.github.
> That’s why I proceeded to make httpie/httpie private instead of httpie/.github without realizing my mistake.
The author does not attempt to hide or misrepresent the GitHub UI that requires confirmation. They show it for both "httpie/httpie" and "httpie/.github".
It does not matter that you have to type the repo name, because once you are on auto-pilot, you proceed past this step. In fact, the author doesn't admit it, but if he's like me, I'll bet they copy/pasted the name. Because the name alone is not sufficient.
The author then goes on to suggest what might have kicked him out of auto-pilot. Providing more information about the repo other than just its name. The name alone is NOT sufficient. And they author shows some example UIs from their own software.
Your suggestion: "The real lesson, imo, is for people obsessed with stars to set up permissions, use dedicated accounts, and not toy around with settings you know are dangerous before you’ve had your coffee."
This simply does not scale. It would require everyone to learn the same lesson for themselves.
I've been a sys admin and developer for over 25 years. People make mistakes. They make them all the time. Putting context-free (or minimal context in the case of the GitHub UI) "Are you sure?" dialogs in front of them does nothing to prevent mistakes.
All the author is asking for is a bit more context from the GitHub UI to help the user realize the significance of their action. This would help future GitHub users to avoid the same error.
Please, quote from the article where you read this. I don't see it.
In the article I read, the author admits fault:
> I accidentally made the project’s repository private for a moment.
The author goes on to explain how they made the mistake.
> What put me on the wrong path was an otherwise completely unrelated action: I had just done the same (i.e., hidden an empty README) on my personal profile by making jakubroztocil/jakubroztocil private.
> GitHub’s conceptual model treats users and organizations as very similar entities when it comes to profiles and repos. 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.
> I didn’t realize at the moment there’s an inconsistency in the naming of this special repo containing profile READMEs and that it differs for users and organizations: name/name vs. name/.github.
> That’s why I proceeded to make httpie/httpie private instead of httpie/.github without realizing my mistake.
The author does not attempt to hide or misrepresent the GitHub UI that requires confirmation. They show it for both "httpie/httpie" and "httpie/.github".
It does not matter that you have to type the repo name, because once you are on auto-pilot, you proceed past this step. In fact, the author doesn't admit it, but if he's like me, I'll bet they copy/pasted the name. Because the name alone is not sufficient.
The author then goes on to suggest what might have kicked him out of auto-pilot. Providing more information about the repo other than just its name. The name alone is NOT sufficient. And they author shows some example UIs from their own software.
Your suggestion: "The real lesson, imo, is for people obsessed with stars to set up permissions, use dedicated accounts, and not toy around with settings you know are dangerous before you’ve had your coffee."
This simply does not scale. It would require everyone to learn the same lesson for themselves.
I've been a sys admin and developer for over 25 years. People make mistakes. They make them all the time. Putting context-free (or minimal context in the case of the GitHub UI) "Are you sure?" dialogs in front of them does nothing to prevent mistakes.
All the author is asking for is a bit more context from the GitHub UI to help the user realize the significance of their action. This would help future GitHub users to avoid the same error.
Agreed, and I'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't want to put in the effort: this is a once in a year kind of incident and the resources required wouldn'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's a possibility of data loss. I signed up for that when I typed the repository name in.
I intentionally did this very recently for a whole bunch of old repos (mainly because a Github bot decided to start emailing me weekly about vulnerabilities in stuff that has been untouched for nearly a decade) and was mildly annoyed at how inconvenient it was to make them private. I would have said the warnings are unnecessary overkill.
It's quite amusing to read this so soon after.
It's quite amusing to read this so soon after.
Same here - not too long ago I had to take a bunch of repositories private, and while I appreciated the prompt (I've dealt with destructive actions that have even less of a barrier before, and that sucks) it still was annoying to do that again and again.
The point the author makes is not that it should be more tedious to make private: they in fact suggest making it as tedious as it is only when you are on a new, non-massively-starred repository. Right now it is only tedious and not sufficiently alarming, is what people are saying.
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.
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 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'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.
I would also say that post does not come across to me as he is only blaming GitHub.
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't scary to type if you e.g. write CI scripts intended to run in sandboxes all day. Deleting a repo isn't scary if you delete a lot of pointless repos.
A prompt that pops up to warn you that you're doing something potentially dangerous, when you know that what you're doing is benign, is a prompt that's crying wolf. You'll learn to tune it out.
A prompt that pops up to warn you that you're doing something potentially dangerous, when you know that what you're doing is benign, is a prompt that's crying wolf. You'll learn to tune it out.
This is a good point and reminds me a story of many years ago when someone accidentally ran “rm -rf” on an important directory and caused a lot of work.
A well-intentioned PM then thought the fix was to alias rm and add prompts to confirm. They had a whole project to add this alias everywhere.
First it broke existing scripts all over the place. So they fixed them to auto apply the confirmation.
Cut to a few months later and someone rm-rf’d something again, ignoring the prompt (or maybe auto applying it).
So the PM wanted a better message and a second prompt.
People are well intentioned but I’ve seen this path of stupidity that doesn’t solve the problem but is an activity in response to a problem.
A well-intentioned PM then thought the fix was to alias rm and add prompts to confirm. They had a whole project to add this alias everywhere.
First it broke existing scripts all over the place. So they fixed them to auto apply the confirmation.
Cut to a few months later and someone rm-rf’d something again, ignoring the prompt (or maybe auto applying it).
So the PM wanted a better message and a second prompt.
People are well intentioned but I’ve seen this path of stupidity that doesn’t solve the problem but is an activity in response to a problem.
Yeah, aliases for "rm" to "rm -i" I find are especially counter productive in this regard, as it conditions people to type rm -f after they get spammed to approve several hundred files while trying to delete a git checkout or node modules too many times.
> make sure you're not on autopilot when taking potentially dangerous actions
When 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't happen.
Overall this is a classic UI design failure. In addition to the "people physically can't take themselves off autopilot" problem, the interface destroys the user's data without providing a way to get it back. It would take relatively little engineering effort to make this reversible.
When 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't happen.
Overall this is a classic UI design failure. In addition to the "people physically can't take themselves off autopilot" problem, the interface destroys the user's data without providing a way to get it back. It would take relatively little engineering effort to make this reversible.
I disagree because there is no UI to indicate you're in a special repo. And I blame GH for not considering this "large project maintainer" use-case.
When I administered many VAX / UNIX machines waaay back, the terminals were all configured to be 'special' 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 "shotgun severity".
When I administered many VAX / UNIX machines waaay back, the terminals were all configured to be 'special' 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 "shotgun severity".
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 "rm". For that reason alone, "rm" is a bad tool, and should be replaced with something like trash-cli.
that would break billions of scripts and confuse the hell out of hundreds of thousands or millions of users. Especially seems unnecessary since most distros ship an alias that makes the default `rm` command run with the `-I` or `-i` command.
> Especially seems unnecessary since most distros ship an alias that makes the default `rm` command run with the `-I` or `-i` command.
I would say that makes things even worse. Because it's just training you to rely on -i/I as a sensible default. One day, you'll encounter that one distro that doesn't have that, and it'll be the time where you really wish it were.
I would say that makes things even worse. Because it's just training you to rely on -i/I as a sensible default. One day, you'll encounter that one distro that doesn't have that, and it'll be the time where you really wish it were.
Hmm, interesting point. I removed that alias early personally in favor of giving due respect to rm (especially with a `-r`!), which is probably an indicator in your favor.
I alias rm to `echo ‘use trash’`, and then use /bin/rm when it’s what I really want.
Of course it is here with us to stay. The point is that if the initial design was different, there would be fewer headaches. We certainly have the power moving forward. And as discussed in the article, a prompt is not enough to deter a user doing something other than what they think they are doing.
>Especially seems unnecessary
An option that shows a y/n action. That's what GitHub does when you're about to make private/delete a repo (even more asking you to type out its entire name) and yet here we're.
An option that shows a y/n action. That's what GitHub does when you're about to make private/delete a repo (even more asking you to type out its entire name) and yet here we're.
[deleted]
Sure, I understand that. But I think, as a designer, I can'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've deleted repo's, I'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 "Stars: 54k" help? I think it'd help me, at the very least.
Tbh, when I've deleted repo's, I'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 "Stars: 54k" help? I think it'd help me, at the very least.
In addition to typing the repo name, maybe they should make you check a box for each type of item that will be deleted:
[ ] Delete 54,000 stars?
[ ] Delete 8,000 watchers?
[ ] etcOr just, you know, not delete anything until otherwise asked to. None of tha has anything essential to do with making the thing private.
Is the repo is private then it’s impossible for anyone to “follow” by starring or watching.
There’s also an issue of taking a repo private, making changes when no one gets alerted, and making it public to make it harder for people to know what’s going on.
There’s also an issue of taking a repo private, making changes when no one gets alerted, and making it public to make it harder for people to know what’s going on.
> There’s also an issue of taking a repo private, making changes when no one gets alerted, and making it public to make it harder for people to know what’s going on.
They could always notify watchers about the repo being made private.
They could always notify watchers about the repo being made private.
And, importantly, don't show an item if it has zero items in it.
Yeah, but on the other hand, "don't make mistakes" isn't a meaningful or useful lesson.
Don't make this specific mistake is a very meaningful and useful lesson.
Yes. But without the possibility to undo mistakes you'll stand in ruins before you learned enough lessons.
"Just don't make any mistakes" is the worst stance one can have in this context, it denies reality and only assures you're unprepared when (not if) something important goes wrong.
"Just don't make any mistakes" is the worst stance one can have in this context, it denies reality and only assures you're unprepared when (not if) something important goes wrong.
git clone good
> make sure you're not on autopilot when taking potentially dangerous actions
If they're in autopilot, how are they going to "make sure"?
Everyone has been in this spot several times. Those who didn't are just lucky.
There's got to be external contingencies to protect people when they're in autopilot.
If they're in autopilot, how are they going to "make sure"?
Everyone has been in this spot several times. Those who didn't are just lucky.
There's got to be external contingencies to protect people when they're in autopilot.
"The user shouldn't be stupid" - which is what you're saying sounds like to my ears - is not an approach that scales well.
Mistakes happen. It's better to have a really good Undo than a lot of confirmation dialogs.
Mistakes happen. It's better to have a really good Undo than a lot of confirmation dialogs.
Having to also type out the number of stars you're deleting when it'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's decentralised), so typing out the repository name, even though it includes the user/organisation, is not as severe-seeming as the designers thought. Confirming the consequences seems better than confirming the command.
I think of the burden on the typical use case and think the current prompts should be sufficient.
What’s the star threshold? 1000? 5?
I’d hate to now have to type in the number of watchers and stars as part of the private/delete/move/etc prompt for all the times I know what I’m doing.
It’s a balance between punishing the non-stupid users vs protecting the stupid users. And people switch between these categories. I might be non-stupid today and stupid tomorrow.
What’s the star threshold? 1000? 5?
I’d hate to now have to type in the number of watchers and stars as part of the private/delete/move/etc prompt for all the times I know what I’m doing.
It’s a balance between punishing the non-stupid users vs protecting the stupid users. And people switch between these categories. I might be non-stupid today and stupid tomorrow.
The author explicitly admits "my brain switched to auto-pilot mode." The problem with that is that we're on auto-pilot many times and we realize we're doing it only after something bad happens. The UX should prevent auto-pilot to do harm to us (and possibly to the customer/company relationship.) "You're about to delete 55k stars" should be enough, as the author suggested. But designers can be on auto-pilot too.
> But designers can be on auto-pilot too.
You're blaming some people without any basis.
> obvious advice: "make sure you're not on autopilot
That... isn't how "autopilot" (or humans in general) work(s).
That... isn't how "autopilot" (or humans in general) work(s).
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/organisation could make a .github repo instead it would be much more obvious.
My favorite example of this is that the cloudflare.com web UI has some extremely scary buttons, like a little "bypass CDN" button with a cloud on it that will rapidly increase traffic to your site 2-100x if you accidentally click.
I mean this isn't exactly how it works. But it's a bit scary.
I mean this isn't exactly how it works. But it's a bit scary.
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.
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.
It's also worth mentioning that the name of the resource here was confusing - the author mentions that this happened because he mixed up how GitHub names profile READMEs for organizations vs users.
GitHub probably should show the stars in the warning UI
In this particular case the stars would have been a useful clue, but in the majority of similar cases the wouldn't be any stars. It would be a useless and redundant signal.
In this particular case the stars would have been a useful clue, but in the majority of similar cases the wouldn't be any stars. It would be a useless and redundant signal.
Number of forks, maybe? Or pull requests? Although those wouldn't disappear of course...
[deleted]
> the author had to _type out_ the name of the repo they wanted deleted
Where does it say that they deleted any repo?
Where does it say that they deleted any repo?
> make sure you're not on autopilot when taking potentially dangerous actions
Humans will be humans, we can'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 "idiot proof".
Humans will be humans, we can'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 "idiot proof".
> the author had to _type out_ the name of the repo
I copy/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.”
I copy/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.”
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.
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.
Humans err.
I recommend reading “the design of every day things”, it talks about this exact attitude and why it’s terrible.
Also sudo mode, right? They had to authenticate to the whole website again too, before doing this!
> "make sure you're not on autopilot when taking potentially dangerous actions, on github or any website".
Have the advertisements/sign-up/GDPR pop-ups trained us to 'engage autopilot to dismiss the pop-up' as soon as possible irrespective of its importance?
Have the advertisements/sign-up/GDPR pop-ups trained us to 'engage autopilot to dismiss the pop-up' as soon as possible irrespective of its importance?
Agreed, the swipe at Microsoft (with links he saved from who knows when!) was especially gratuitous. He mad. Don't write something public when bitter should be a lesson right after don't be on autopilot.
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.”
“I take responsibility, but…” is not “I take responsibility.”
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's compliant in every region that could have a privacy law. I'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).
I'm pretty sure GDPR doesn't say everything must be wiped instantly but instead within a reasonable time period. One that's certainly enough to undo such actions.
Interesting idea but what PII is stored with stars?
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:
"Are you sure you want to disconnect the server? No / Yes"
Click remove presents you with the following dialog box:
"Are you sure you want to remove the server? No / Yes"
Good luck! I mean, it's not a super huge deal to recreate the server entry, but still annoying when you're in the middle of something and just realized what you did.
Honestly, just replacing the "Yes" button with the action being taken would be enough to improve this. "No / Disconnect" and "No / Remove". But my personal opinion is that disconnecting is not a destructive action unless there's an open transaction or running query. So the dialog box should be contextual on that scenario, and otherwise it should just disconnect.
"Disconnecting will cancel executing queries and rollback open transactions. Continue? No / Disconnect"
"Are you sure you want to disconnect the server? No / Yes"
Click remove presents you with the following dialog box:
"Are you sure you want to remove the server? No / Yes"
Good luck! I mean, it's not a super huge deal to recreate the server entry, but still annoying when you're in the middle of something and just realized what you did.
Honestly, just replacing the "Yes" button with the action being taken would be enough to improve this. "No / Disconnect" and "No / Remove". But my personal opinion is that disconnecting is not a destructive action unless there's an open transaction or running query. So the dialog box should be contextual on that scenario, and otherwise it should just disconnect.
"Disconnecting will cancel executing queries and rollback open transactions. Continue? No / Disconnect"
> just replacing the "Yes" button
Or the lazy web dialog popup with "Cancel" and "OK".
So you click on "Cancel Glorping The Frobnitz" and up pops a dialog with "Cancel" and "OK". It always takes a moments thought does the "Cancel" 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're a UI expert which I'm not. Of course the webdev part of changing the captions on the page really would be seconds for me to do.
Or the lazy web dialog popup with "Cancel" and "OK".
So you click on "Cancel Glorping The Frobnitz" and up pops a dialog with "Cancel" and "OK". It always takes a moments thought does the "Cancel" 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're a UI expert which I'm not. Of course the webdev part of changing the captions on the page really would be seconds for me to do.
> mean cancel the cancel glorping or cancel the cancel.
Typing error, it should be
> mean cancel the glorping or cancel the cancel.
Typing error, it should be
> mean cancel the glorping or cancel the cancel.
Would you consider submitting a patch?
Actually, I should. The biggest hold up will probably be translations though, unless they have that already translated.
[deleted]
> While the author clearly feels bad about the fact that they've lost his community and that GitHub couldn't restore it (which is honestly what any of us would've felt under similar circumstances), they'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.
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.
For Lesson 1: I think the general pattern that ought to be followed is to "prefer undo to warnings." Undo is often harder to implement, however it's usually a superior experience.
I agree that undos are pretty nice for when errors are possible, but I think there's a really good reason to put up warnings too. Let's say they accidentally made the repo private, but didn'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.
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.
There are definitely still cases where warnings are important, but the point of "prefer undo to warnings" is to eliminate as many warnings as possible to avoid desensitizing users. I should only see a scary pop-up if the action that I'm performing is going to be well and truly destructive.
Undo-instead-of-warning is a great pattern for lower-stakes actions that are easy to undo and cause minimal damage if left done. This allows the few warnings you do show to be recognized as truly important.
Undo-instead-of-warning is a great pattern for lower-stakes actions that are easy to undo and cause minimal damage if left done. This allows the few warnings you do show to be recognized as truly important.
Even better, flipping "public/private" has absolutely no need to delete any information at all.
There could be separate buttons, "Delete all my stars", "Delete all my watches".
There could be separate buttons, "Delete all my stars", "Delete all my watches".
> Even better, flipping "public/private" has absolutely no need to delete any information at all.
Of course it does. You can’t watch/star a private repo unless you have access, so all watchers/starrers should be removed. If you kept the data as-is watchers would still see the repo updates in their feed, which is the opposite of the 'private' feature promise.
Of course it does. You can’t watch/star a private repo unless you have access, so all watchers/starrers should be removed. If you kept the data as-is watchers would still see the repo updates in their feed, which is the opposite of the 'private' feature promise.
Sure, if you don't change any part of the system it has to be that way. But there's no reason a private switch can't just suspend stars/watchers instead of permanently deleting them.
Rollbacks even better.
> I'm not really sure how you'd do a "cascading soft delete" 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?
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?
There is no need to delete anything at all. Set the "private" flag when the user asks for to make it private. Unset the "private" 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.
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.
Stop. You've said the same thing a dozen times in this thread. Besides being repetitive, you're overlooking the obvious fact that having associations from non members of private repos to those repos is problematic. At the very least at the UI level, maintaining known dead internal links is bad form. So you'd be creating edge cases for the UI and probably numerous places deeper in the tech stack as well. Which is fine if you engineer solutions to all the edge cases. Perhaps after this incident they will consider doing so. But it's certainly not as trivial as you imply.
Mmh? Maybe it's because I've never touched frontend professionally in my life, but I think that if you're doing it in the UI you're doing it VERY wrong.
This logic should be purely in the DB model or very close to it. In any case the internal API should never ever list private repos of an organization a user isn't a member of, period. Stars or no stars. Follows or no follows. Why should it? There's no corner case here, if stars pose a problem, the problem isn't the stars, it's a defective model behind. Hiding things that aren't meant to be seen in the UI means putting business logic in the UI. Just don't.
This logic should be purely in the DB model or very close to it. In any case the internal API should never ever list private repos of an organization a user isn't a member of, period. Stars or no stars. Follows or no follows. Why should it? There's no corner case here, if stars pose a problem, the problem isn't the stars, it's a defective model behind. Hiding things that aren't meant to be seen in the UI means putting business logic in the UI. Just don't.
Fair point. My intent was to point out the UX would be broken. But you're right, the data model that backs that UX is what would have to change.
ncmncm(1)
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.
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 "hard" delete of the repo status (or the stars), then we can set that to cascade to `X` and `Y` as well. Otoh, I don't think you can apply a cascade like that automatically when you'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?
[deleted]
He did have to type "httpie/httpie" in the box to confirm, no? I'm rather surprised that that didn'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/httpie?
OTOH, I haven'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/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.
OTOH, I haven'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/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.
By now I've become so accustomed to just copy the bold text from the line above it and paste, that it doesn'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.
Aha .. perhaps the interface can be changed to prevent copy-paste into that field.
Better would be to not show the repo name directly above the dialog at all so the user actually has to think a bit about what they need to enter. Just re-typing a text shown to you can be done on autopilot as well.
[deleted]
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, https://www.youtube-nocookie.com/embed/Lp7E973zozc
> I assume that the cascading done on GitHub would be done on a FK constraint
GitHub doesn’t use foreign keys, the cascade delete must have been manually implemented.
https://news.ycombinator.com/item?id=21486494
GitHub doesn’t use foreign keys, the cascade delete must have been manually implemented.
https://news.ycombinator.com/item?id=21486494
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'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'm less familiar with, solve 'undo' 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 'solve' this.
Point being: choose your architecture well, based on your needs and the tradeoffs. Don't just grab the next fancy framework, because that will decide for you, if, and how you solve things like 'soft delete' or 'undo'.
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'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'm less familiar with, solve 'undo' 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 'solve' this.
Point being: choose your architecture well, based on your needs and the tradeoffs. Don't just grab the next fancy framework, because that will decide for you, if, and how you solve things like 'soft delete' or 'undo'.
I'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 ( https://berk.es/2022/03/08/the-waning-of-ruby-and-rails/ ):
> 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:
> I have a separate post planned on "RAD web frameworks", 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.
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 ( https://berk.es/2022/03/08/the-waning-of-ruby-and-rails/ ):
> 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:
> I have a separate post planned on "RAD web frameworks", 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.
I'd suggest going through all Uncle Bob Martin[1]s talks on clean code.
He has a great article (2014), old, on why you may not want to build that framework at all[2] too:
> Using a framework requires a significant commitment. By accepting the framework into your code, you surrender your control over the details that the framework manages. [...] > And yet despite the huge commitment you’ve made to the framework, the framework has made no reciprocal commitment to you at all. That framework is free to evolve in any direction that pleases its author.
Another great source are the books, and/or youtube channel by Dave Farley[3]
What set me on a journey is -decades ago- the pain I, as a developer felt when developing web-applications for my clients. But worse: the pain they felt for getting delivered crap. "Why am I delivering crap" was the question that set me to research frameworks, languages, design patterns and architecture. Drupal, Rails, Django, ASP: I've worked with it, and delivered crap with it.
In general, I found that a framework matters. e.g. the simple act of reading ActiveRecord Critisism on wikipedia[4] got me thingking:
> also due to the strong coupling of database interaction and application logic,
This was true for project D, G and Y! This was why we failed to iterate at any speed at all. Because I can relate it immediate to Real And Actual Problems, Failed Projects, Slipped Deadlines, Burned out colleagues, and so on, all of wich I encountered during my career. Not saying all those problems were caused by ActiveRecord or Rails! But that they were caused by the choice for the wrong framework. Or the choice for a framework at all.
It led me to DDD[5], which then is the gateway into all sorts of Enterprise Patterns. I dislike that name, because the connotation is all wrong. Especially the subtitle of the canonical book on DDD struck a note:
> Tackling Complexity in the Heart of Software
This! This is why I'm delivering crap: I fail to tackle the complexity that inherit in any domain. In e.g. Rails, I would just spread it all over the place, fighting against ActiveRecord and Rails, yet still failing to isolate, modularize and capture that domain.
So I no longer use Rails, nor any framework in my startup. I occasionally do some freelance gigs, often Rails. And the more I learned how to Tackle Complexity in the Heart of Software through choices and tradeoffs, the more I see why a project in Rails that I'm flewn in to salvage, is doomed. It's the choice for Rails. Not lacking of services, not "Fat Models", not "missing tests" nor missing of any sort of "rigorous refactoring" Its Rails! Rails is just unfit for this domain, this problem, this customer.
Yet Rails shines for others: I restate: It's brilliant for simple CRUD. But anything you expect to have any sort of "Complexity in the heart" is probably unfit.
[1] https://www.youtube.com/channel/UCCfqyGl3nq_V0bo64CjZh8g
[2] https://blog.cleancoder.com/uncle-bob/2014/05/11/FrameworkBo...
[3] https://www.youtube.com/channel/UCCfqyGl3nq_V0bo64CjZh8g (his books are promoted on this channel)
[4] https://en.wikipedia.org/wiki/Active_record_pattern#Criticis...
[5] https://martinfowler.com/bliki/DomainDrivenDesign.html
He has a great article (2014), old, on why you may not want to build that framework at all[2] too:
> Using a framework requires a significant commitment. By accepting the framework into your code, you surrender your control over the details that the framework manages. [...] > And yet despite the huge commitment you’ve made to the framework, the framework has made no reciprocal commitment to you at all. That framework is free to evolve in any direction that pleases its author.
Another great source are the books, and/or youtube channel by Dave Farley[3]
What set me on a journey is -decades ago- the pain I, as a developer felt when developing web-applications for my clients. But worse: the pain they felt for getting delivered crap. "Why am I delivering crap" was the question that set me to research frameworks, languages, design patterns and architecture. Drupal, Rails, Django, ASP: I've worked with it, and delivered crap with it.
In general, I found that a framework matters. e.g. the simple act of reading ActiveRecord Critisism on wikipedia[4] got me thingking:
> also due to the strong coupling of database interaction and application logic,
This was true for project D, G and Y! This was why we failed to iterate at any speed at all. Because I can relate it immediate to Real And Actual Problems, Failed Projects, Slipped Deadlines, Burned out colleagues, and so on, all of wich I encountered during my career. Not saying all those problems were caused by ActiveRecord or Rails! But that they were caused by the choice for the wrong framework. Or the choice for a framework at all.
It led me to DDD[5], which then is the gateway into all sorts of Enterprise Patterns. I dislike that name, because the connotation is all wrong. Especially the subtitle of the canonical book on DDD struck a note:
> Tackling Complexity in the Heart of Software
This! This is why I'm delivering crap: I fail to tackle the complexity that inherit in any domain. In e.g. Rails, I would just spread it all over the place, fighting against ActiveRecord and Rails, yet still failing to isolate, modularize and capture that domain.
So I no longer use Rails, nor any framework in my startup. I occasionally do some freelance gigs, often Rails. And the more I learned how to Tackle Complexity in the Heart of Software through choices and tradeoffs, the more I see why a project in Rails that I'm flewn in to salvage, is doomed. It's the choice for Rails. Not lacking of services, not "Fat Models", not "missing tests" nor missing of any sort of "rigorous refactoring" Its Rails! Rails is just unfit for this domain, this problem, this customer.
Yet Rails shines for others: I restate: It's brilliant for simple CRUD. But anything you expect to have any sort of "Complexity in the heart" is probably unfit.
[1] https://www.youtube.com/channel/UCCfqyGl3nq_V0bo64CjZh8g
[2] https://blog.cleancoder.com/uncle-bob/2014/05/11/FrameworkBo...
[3] https://www.youtube.com/channel/UCCfqyGl3nq_V0bo64CjZh8g (his books are promoted on this channel)
[4] https://en.wikipedia.org/wiki/Active_record_pattern#Criticis...
[5] https://martinfowler.com/bliki/DomainDrivenDesign.html
Thanks for the detailed breakdown! This is really helpful and exactly the kind of information I was hoping you would share.
I don't see why you are thinking it's hard with rails, you just create a default scope in your model "not_deleted", and that's done.
It will apply to all queries unless you specifically call " unscoped"
It will apply to all queries unless you specifically call " unscoped"
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've been significantly worse.
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've been significantly worse.
> 1. Why would it be particularly difficult for them to have soft deletes in Rails or at scale?
I don't know the internals of Github. But we had soft-delete dragging down our database. Indexing, for one, becomes tough.
It also presumes everything lives in a single, canonical, transactional database. In real life, anything of scale, with legacy lives in multiple services. There'll be caches, search-indexes (elastic etc), data-lakes, leader/follower clusters and whatnot. Propagating a "delete" command is no easier or harder in such a setup, than propagating a "flag" which has severe business and security implications.
2. Like the article suggests, additional UX improvements could be made besides making it possible to restore a backup or providing an undo action.
Yup. My point was that with e.g. Event-sourced or Command pattern, you don't even need that whole UI in the first place. There could be a 20 minute "undo" somewhere. Or an "undo" that remains active untill another non-compatible command renders undoing unavailable. This is a common pattern. Which was invented decades ago, and is still used everywhere to solve this exact problem.
Why invent dialogs, soft-deletes, etc, when the problem is solved, done and non-existent, given you make the right choices? Why do software engineers insist on re-inventing wheels every few years rather than grab existing, proven and solid solutions for this?¹
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.
Why do you feel this? Rails comes with tradeoffs. I'm not saying "rails was a bad choice" But I'm saying "the choice for Rails brings the tradeoffs that e.g. Undo is hard".
Saying that "it is easy in Rails" is both disingenuous and unfair: there are hundreds of Gems, some of which grown to enormous project almost the size of entire ActiveRecord itself, to tackle these problems: it isn't easy. Papertrail, for example is a magnificent monster. "just drop in papertrail" really is not a solution, it's a problem.
> 4. Had they focused on a more exotic architecture from day one, the UX of other features on the site could've been significantly worse.
I.e. "tradeoffs".
¹ The answer, I'm afraid, is a mix of the doubling-of-developers-every-four-years (forever september), NIH, and unwillingness to invest time in learning the foundations layed out in the past decades. The last is what bothers me most.
I don't know the internals of Github. But we had soft-delete dragging down our database. Indexing, for one, becomes tough.
It also presumes everything lives in a single, canonical, transactional database. In real life, anything of scale, with legacy lives in multiple services. There'll be caches, search-indexes (elastic etc), data-lakes, leader/follower clusters and whatnot. Propagating a "delete" command is no easier or harder in such a setup, than propagating a "flag" which has severe business and security implications.
2. Like the article suggests, additional UX improvements could be made besides making it possible to restore a backup or providing an undo action.
Yup. My point was that with e.g. Event-sourced or Command pattern, you don't even need that whole UI in the first place. There could be a 20 minute "undo" somewhere. Or an "undo" that remains active untill another non-compatible command renders undoing unavailable. This is a common pattern. Which was invented decades ago, and is still used everywhere to solve this exact problem.
Why invent dialogs, soft-deletes, etc, when the problem is solved, done and non-existent, given you make the right choices? Why do software engineers insist on re-inventing wheels every few years rather than grab existing, proven and solid solutions for this?¹
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.
Why do you feel this? Rails comes with tradeoffs. I'm not saying "rails was a bad choice" But I'm saying "the choice for Rails brings the tradeoffs that e.g. Undo is hard".
Saying that "it is easy in Rails" is both disingenuous and unfair: there are hundreds of Gems, some of which grown to enormous project almost the size of entire ActiveRecord itself, to tackle these problems: it isn't easy. Papertrail, for example is a magnificent monster. "just drop in papertrail" really is not a solution, it's a problem.
> 4. Had they focused on a more exotic architecture from day one, the UX of other features on the site could've been significantly worse.
I.e. "tradeoffs".
¹ The answer, I'm afraid, is a mix of the doubling-of-developers-every-four-years (forever september), NIH, and unwillingness to invest time in learning the foundations layed out in the past decades. The last is what bothers me most.
> Why do software engineers insist on re-inventing wheels every few years rather than grab existing, proven and solid solutions for this?¹
For one thing, because it works very well and is much easier to wrap your head around than the command pattern (much less undoing a command, and keeping track of which commands make incompatible changes).
These things are worth the effort if you are going to build an app that will be around for ten years and serve an existing market. Much harder to justify if you are still figuring out what you actually need to do.
Like, I agree with you that most developers just don’t know about it yet, and therefore don’t use it, but that’s also a factor of MVC just being the right choice for 90% of all apps, and easier to get started with.
For one thing, because it works very well and is much easier to wrap your head around than the command pattern (much less undoing a command, and keeping track of which commands make incompatible changes).
These things are worth the effort if you are going to build an app that will be around for ten years and serve an existing market. Much harder to justify if you are still figuring out what you actually need to do.
Like, I agree with you that most developers just don’t know about it yet, and therefore don’t use it, but that’s also a factor of MVC just being the right choice for 90% of all apps, and easier to get started with.
https://github.com/rubysherpas/paranoia 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't ever delete anything.
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't ever delete anything.
First: soft-delete really doesn't need a library. Paranoia is nice, but almost all of the code and complexity in that gem is to support multiple versions of rails and to let you configure that gem.
DIY in this case really is very simple. And far more flexible, performant even, and future-proof.
(I've worked on a project where two full-time devs spent days upgrading this gem; this is over 6 years ago). And a few months ago, I worked on a project where they had more code to configure, patch and work around paranoia, than any DIY ever did. My even simpler DIY version not only used 50% of the code we had to override the gem before, it allowed for some custom work that we could not do before.
And no: even DIY ain't as simple as you make it seem. Practical issue, that I encountered last year even, was where their "soft delete" was making state-machines very tough. Because in a FSM, "deleted" wants to be state, like anything else. But the "generic soft-delete" conflicts with that. So the project had both. And some fugly glue-code to sync between the FSM and the soft-delete and vice-versa. No suprise that this broke occasionally, making data re-available that people thought gone.
DIY in this case really is very simple. And far more flexible, performant even, and future-proof.
(I've worked on a project where two full-time devs spent days upgrading this gem; this is over 6 years ago). And a few months ago, I worked on a project where they had more code to configure, patch and work around paranoia, than any DIY ever did. My even simpler DIY version not only used 50% of the code we had to override the gem before, it allowed for some custom work that we could not do before.
And no: even DIY ain't as simple as you make it seem. Practical issue, that I encountered last year even, was where their "soft delete" was making state-machines very tough. Because in a FSM, "deleted" wants to be state, like anything else. But the "generic soft-delete" conflicts with that. So the project had both. And some fugly glue-code to sync between the FSM and the soft-delete and vice-versa. No suprise that this broke occasionally, making data re-available that people thought gone.
> I assume that the cascading done on GitHub would be done on a FK constraint, but I'm not really sure how you'd do a "cascading soft delete" without making some kind of manual cascading logic?
I'm not at a terminal, so I can'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;`
I'm not at a terminal, so I can'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;`
> "that GitHub couldn't restore it"
What an odd turn of phrase.
What an odd turn of phrase.
Not sure what you meant? Are you pointing out couldn't vs didn't? If so, I didn't really think about it, although now that you point it out, I think didn't would've been a better fit. I'll edit it, thanks!
I mean "refused to". There was absolutely no value to Microsoft in refusing to restore the deleted information, and there was no practical reason to have deleted it at all. Ultimately, it just amounts to contempt.
"I screwed up. By the way, it's your fault. I hope you realize how many people think more highly of your service because my project is there. Why wont you accept some money for a service you don't provide?"
What's the value in capitulating to that? Also, a user saying "delete this stuff" is a pretty practical reason to do so.
Indifference != contempt.
What's the value in capitulating to that? Also, a user saying "delete this stuff" is a pretty practical reason to do so.
Indifference != contempt.
Define the difference.
or maybe just incompetence? or just retro-1990s microsoft? what is this? slashdot in 1998?
i mean, this is the company that perfected the "throw it all away and start over" serviceability paradigm and the "we don't know what's wrong with it just reboot it every six hours" reliability paradigm for systems.
totally reliable business partner to trust for outsourcing critical business and government infrastructure for sure!
those who are serious and prudent seek assurance, for the reckless and feckless, there's azurance.
if the blog post doesn't work, i'd suggest renaming the project (specifically the cli) such that it makes reference to the hollowness of the new microsoft's apparent love for open source. that way when those thousands of developers (who happen the be of the exact variety that the dinosaur is trying to court) are invoking it every day, it can burn into their skulls to never ever work for, or choose technologies made by, microsoft.
score 5: funny, insightful
i mean, this is the company that perfected the "throw it all away and start over" serviceability paradigm and the "we don't know what's wrong with it just reboot it every six hours" reliability paradigm for systems.
totally reliable business partner to trust for outsourcing critical business and government infrastructure for sure!
those who are serious and prudent seek assurance, for the reckless and feckless, there's azurance.
if the blog post doesn't work, i'd suggest renaming the project (specifically the cli) such that it makes reference to the hollowness of the new microsoft's apparent love for open source. that way when those thousands of developers (who happen the be of the exact variety that the dinosaur is trying to court) are invoking it every day, it can burn into their skulls to never ever work for, or choose technologies made by, microsoft.
score 5: funny, insightful
> I assume that the cascading done on GitHub would be done on a FK constraint, but I'm not really sure how you'd do a "cascading soft delete" without making some kind of manual cascading logic?
Couldn't you just use an on delete trigger for this? I have no experience one the subject however
Couldn't you just use an on delete trigger for this? I have no experience one the subject however
An ON UPDATE trigger for the is_deleted column would do.
Some databases also support INSTEAD OF triggers.
Some databases also support INSTEAD OF triggers.
Doesn't ON UPDATE only work for foreign keys? As far as I know, it's used to update the foreign key itself, and not values based on relationships.
[deleted]
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.
"...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..."
"...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.."
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.
"...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..."
"...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.."
>I often think scary popup boxes are enough to get people to think about what they're doing
This would entirely depend upon how often it shows up. The more often it shows up when the scare isn't relevant, the less people will pay attention to it.
>the distractions ("Type this repo's name", etc) just go away
I think it shows that what one types needs to be relevant information. In this case, due to the similarity between when the author would'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't enough. If this also asked you to type in the number of git stars you were about to lose, that would've been enough to make author recheck exactly what they were doing.
This would entirely depend upon how often it shows up. The more often it shows up when the scare isn't relevant, the less people will pay attention to it.
>the distractions ("Type this repo's name", etc) just go away
I think it shows that what one types needs to be relevant information. In this case, due to the similarity between when the author would'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't enough. If this also asked you to type in the number of git stars you were about to lose, that would've been enough to make author recheck exactly what they were doing.
Factorio doesn't say "You'll lose unsaved changes" 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's so frustrating.
The number of games that DO ask this question, immediately after saving, is ridiculously high it's so frustrating.
[deleted]
> 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'm not really sure how you'd do a "cascading soft delete" without making some kind of manual cascading logic
Relying on database cascade deletions is very dangerous. Especially since as the application/org grows, it's easy to lose track of all the things that may get cascaded. There's a good chance you'll find yourself having cascade-deleted data that you never intended to have deleted.
Manually implementing logic for "when archiving X, also archive Y and Z" 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 "is_deleted" 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.
Relying on database cascade deletions is very dangerous. Especially since as the application/org grows, it's easy to lose track of all the things that may get cascaded. There's a good chance you'll find yourself having cascade-deleted data that you never intended to have deleted.
Manually implementing logic for "when archiving X, also archive Y and Z" 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 "is_deleted" 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.
Regarding cascading logic with soft deletes; I think the answer is that you don't cascade anything. You basically need to have `deleted_at IS NULL` conditions in your queries to exclude them.
I’ve adopted a pattern of:
<dialog-text>
If they click ok:
Asking again to be sure you want to destroy masses of data
<dialog-text>
But even that fails if there is a language barrier.
<dialog-text>
If they click ok:
Asking again to be sure you want to destroy masses of data
<dialog-text>
But even that fails if there is a language barrier.
> But even that fails if there is a language barrier.
Surely GitHub is localized? (and if not, why the hell not?)
Surely GitHub is localized? (and if not, why the hell not?)
I recall that GitHub used to be localised in several languages, but no more. And I can’t seem to find any references to it anymore, either. “GitHub interface translation” gives search results about code, not about GitHub’s interface
> The problem is that the box looks exactly the same for repos with no commits and stars and for repos with a decade-long history and 55k stargazers and watchers. And it says “Warning: this is a potentially destructive action.”
It seems a bit much to expect the website to show you a warning of different levels of severity depending on the stars a repos has, particularly when the standard message is pretty severe and explicit. It even makes you type the name of the repo you want to make private before proceeding - I don't see how that wouldn't make anyone snap out of autopilot. I sympathise with the author's misfortune but it is pretty hard to look at that warning dialog and conclude that he was not sufficiently warned of the consequences or given a chance to reflect.
I find it disappointing that all of the lessons supposedly learned from this ordeal are lessons for other people, not the author. Surely lesson #1 should have been "check what repo you're in before taking destructive actions".
It seems a bit much to expect the website to show you a warning of different levels of severity depending on the stars a repos has, particularly when the standard message is pretty severe and explicit. It even makes you type the name of the repo you want to make private before proceeding - I don't see how that wouldn't make anyone snap out of autopilot. I sympathise with the author's misfortune but it is pretty hard to look at that warning dialog and conclude that he was not sufficiently warned of the consequences or given a chance to reflect.
I find it disappointing that all of the lessons supposedly learned from this ordeal are lessons for other people, not the author. Surely lesson #1 should have been "check what repo you're in before taking destructive actions".
I’m wondering if you got a chance to see this part of the post:
> […] I obviously had no intention to make httpie/httpie private. So, why then?
>
> The proximate cause was that I thought I was inside a different repo; […] What I actually intended to do was to hide the HTTPie organization’s profile README, […]
>
> What put me on the wrong path was an otherwise completely unrelated action: I had just done the same (i.e., hidden an empty README) on my personal profile by making jakubroztocil/jakubroztocil private.
>
> GitHub’s conceptual model treats users and organizations as very similar entities when it comes to profiles and repos. […] since I just wanted to repeat the same benign action on our organization’s profile, […]
>
> I didn’t realize at the moment there’s an inconsistency in the naming of this special repo containing profile READMEs and that it differs for users and organizations: name/name vs. name/.github.
>
> That’s why I proceeded to make httpie/httpie private instead of httpie/.github without realizing my mistake.
I did read that part. He or she had to exactly type out "httpie/httpie" to confirm the action. I don't know what else GitHub could do to prevent this. How much handholding does GitHub need to offer? People need to accept the consequences of their own actions. The amount of manual steps necessary to take httpie private is fairly substantial. This person was careless and learned a lesson on being careless.
Based on your phrasing I’m still not sure if you understand parent—yes, the author had to type “httpie/httpie”, but due to GitHub’s user-level README repo feature, _that specific repo name_ conventionally would be a README repo, which is what the author was trying to delete.
For example, my README repo is and must be called “glacials/glacials”; if I wanted to delete it that is what I would type, but if I were an organization and wanted to delete it, I would type something else. This different behavior between acting as a user vs. acting as an organization is what caught the author off-guard. They typed “httpie/httpie” and consciously thought “yes, I want to delete the README repo, which I know must have name httpie/httpie, so that’s definitely what I’d like to do, I’ll go ahead and type that”.
This is not absentmindedness, it is a misleading product inconsistency. Were it not for this, I would 100% agree with you.
For example, my README repo is and must be called “glacials/glacials”; if I wanted to delete it that is what I would type, but if I were an organization and wanted to delete it, I would type something else. This different behavior between acting as a user vs. acting as an organization is what caught the author off-guard. They typed “httpie/httpie” and consciously thought “yes, I want to delete the README repo, which I know must have name httpie/httpie, so that’s definitely what I’d like to do, I’ll go ahead and type that”.
This is not absentmindedness, it is a misleading product inconsistency. Were it not for this, I would 100% agree with you.
Thank you for this explanation. I didn't know profile READMEs were a thing and have to be named the same as the user account. I can see how this could be confusing when the functionality is different between users and orgs.
I don’t see the need for moralizing. They took responsibility, and offered GitHub money to help. They aren’t leaning in heavily to blame Github here.
It’s fine to express the gulf of evaluation and execution that led to the error. It happened. There may not be any better known solutions at the moment to lower the risk any further.
Calling them careless is also unjustified. They made a mental error processing the information. Whenever humans are involved there is a risk of illogical and bizarre mental errors in decision making because we are degenerating meat robots granted full agency.
Shit happens. How we emotionally deal with it is the test of life as a human being.
It’s fine to express the gulf of evaluation and execution that led to the error. It happened. There may not be any better known solutions at the moment to lower the risk any further.
Calling them careless is also unjustified. They made a mental error processing the information. Whenever humans are involved there is a risk of illogical and bizarre mental errors in decision making because we are degenerating meat robots granted full agency.
Shit happens. How we emotionally deal with it is the test of life as a human being.
Honestly, they are blaming Github here. They included a whole "Lessons" section, which are complaints about Github's UI, then database design, then community support. I don't think we should be making fun of them for accidentally privating their repo, but I absolutely laughed at
>The dialog should be more contextual and, paraphrasing again, it should say “You’re about to kill 55,000 people.” That would’ve certainly made me pause.
>The dialog should be more contextual and, paraphrasing again, it should say “You’re about to kill 55,000 people.” That would’ve certainly made me pause.
> They aren’t leaning in heavily to blame Github here.
> Honestly, they are blaming Github here.
I think both of these statements can be true at the same time. They are taking much of the responsibility while also explaining how some aspects of Github's design are partly responsible for the outcome.
> Honestly, they are blaming Github here.
I think both of these statements can be true at the same time. They are taking much of the responsibility while also explaining how some aspects of Github's design are partly responsible for the outcome.
That's fair, there are two things that rub me the wrong way here. First being how big of a deal they're making about the github equivalent of bookmarks, stars are not a community, period. The more significant thing is that this industry runs on mv foobar foobar truncating foobar with no recourse short of forensics, github's confirmation flow is quite good. Sure it could be improved, but it's so much better than pretty much everything else we have to interact with that assigning responsibility to them for not sounding a klaxon in addition to requiring one to type in the exact name of what's being deleted is absurd.
> and offered GitHub money to help
It's not like they can just run a few SQL queries on prod and have the author PayPal them 10$.
They need to create a plan, cost estimate, risk assessment, get management/qa/security/SRE/... approvals, write the code, documentation, reviews, tests, run on prod, create invoice, etc. This means 10-20 people work for 1-2 days. I doubt that the author is willing to pay 20000-60000$ for this.
It's not like they can just run a few SQL queries on prod and have the author PayPal them 10$.
They need to create a plan, cost estimate, risk assessment, get management/qa/security/SRE/... approvals, write the code, documentation, reviews, tests, run on prod, create invoice, etc. This means 10-20 people work for 1-2 days. I doubt that the author is willing to pay 20000-60000$ for this.
https://httpie.io/ has a star display on the homepage, and the story https://httpie.io/about alludes to the star count:
> That humble tool, which we open-sourced, quickly captured developers’ hearts and rapidly became one of the top projects on GitHub.
> We’ve raised a Seed Round ...
It's not hard to believe the seed round and the entire pitch of the commercial venture was tied to the star count, and it's not hard to believe that the author would drop $1/star to restore the count.
> That humble tool, which we open-sourced, quickly captured developers’ hearts and rapidly became one of the top projects on GitHub.
> We’ve raised a Seed Round ...
It's not hard to believe the seed round and the entire pitch of the commercial venture was tied to the star count, and it's not hard to believe that the author would drop $1/star to restore the count.
Where do you see that they didn't accept the consequences of their own actions? They just wish it were different/better.
There's no harm in that, and Github being used by millions of developers is a strong reason to make it just a little bit safer for even the rarer cases like these.
There's no harm in that, and Github being used by millions of developers is a strong reason to make it just a little bit safer for even the rarer cases like these.
Just my 2c.. GitHub, instead of the statement "All stars and watchers", can improve it by showing "All 54000 stars and 32000 watchers" will be deleted.
Funny thing is that I have never typed in a repo to delete. I always just copy/paste from the message. It's probably what the repo owner did. Perhaps Github should generate an image instead of using text that can be copied. That way they could help mitigate the copy/paste problem.
> I don't know what else GitHub could do to prevent this.
The article describes exactly what else they could do, including example screenshots from another app that does it.
The article describes exactly what else they could do, including example screenshots from another app that does it.
This kind of attitude is how bad products get made.
Honestly, no. Your type of attitude is how bad products get made: products that cater to the absolute lowest tech illiterate user. Products that hide and simplify every useful tool to the point of annoyance and disfunction. Github's warnings are plenty enough. It doesn't matter what Github did; this post would still be made, and you people would still be thinking of even more absurd ways to make the user not do something. At a certain point, a tool has to do the function you asked it to do.
As a UX designer, I don’t understand this attitude. Clearly there are things GitHub could do to improve the design here. That doesn’t mean it’s GitHub’s fault, mistakes can always happen.
This screen gives you pretty poor context for your action. You can’t so easily see things that normally tell you at a glance where you are. They also don’t offer a good preview of the action, or undo, which is how you normally make potentially destructive actions less dangerous. Instead they made a scary prompt, but since they use that solution a lot, users may get desensitized to it.
This screen gives you pretty poor context for your action. You can’t so easily see things that normally tell you at a glance where you are. They also don’t offer a good preview of the action, or undo, which is how you normally make potentially destructive actions less dangerous. Instead they made a scary prompt, but since they use that solution a lot, users may get desensitized to it.
I found this article interesting, exactly because "typing the name of the repo you want to make private before proceeding" seemed like a good solution to me as well. (Until now.)
However, I can absolutely imagine doing the author's mistake and I think their UI improvement suggestion is great.
To me the interface design lesson here is valuable. A recommendation to "check what repo you're in before taking destructive actions" has zero value, since everyone knows that already.
---
Completely agreed on the second point though, it's weird to blame this mainly on GitHub.
However, I can absolutely imagine doing the author's mistake and I think their UI improvement suggestion is great.
To me the interface design lesson here is valuable. A recommendation to "check what repo you're in before taking destructive actions" has zero value, since everyone knows that already.
---
Completely agreed on the second point though, it's weird to blame this mainly on GitHub.
It occurs to me that if your users are mindlessly doing repetitive things, no amount of "Are you sure?" or other hoop jumping is guaranteed to snap them out of it. Humans are pattern recognition machines.
GitHub may be better off preventing a repo with this size of a following from being made private without a support request or something requiring a second party to confirm.
GitHub may be better off preventing a repo with this size of a following from being made private without a support request or something requiring a second party to confirm.
Yes. Someone elsewhere in this thread suggested that it could be improved to make it impossible to make the repo private before you delete all the stars somewhere else in the UI, therefore breaking out of the pattern.
Surely there are multiple solutions, but I think you distilled the essence well: make the truly dangerous action different to the learned repetition.
Surely there are multiple solutions, but I think you distilled the essence well: make the truly dangerous action different to the learned repetition.
At my company, we had like 3-4 steps, each with clear wording to cancel a subscription, and they had to type something in the end to confirm. Guess what? We still had tickets asking to restore their subscriptions :)
I was mesmerised how the Japanese train operators (and perhaps other similar workers) have to follow checklists where they physically point[0] at everything they are doing even when they are alone.
Now I'm wondering whether this approach actually works.
[0] - https://youtu.be/9LmdUz3rOQU?t=66
Now I'm wondering whether this approach actually works.
[0] - https://youtu.be/9LmdUz3rOQU?t=66
I think that's a different matter. Using checklists to automate a task, and make sure you don't skip any is working. Random obstacles before dangerous acts IMO make little to no use.
Before destroying a house a checklist can ensure that they checked if there are anyone in the building (i seriously have no idea how they do that), but requiring them to stand on one leg with pinched nose, I don't think that'd have any use.
> It even makes you type the name
More and more IT systems are starting to do this for more and more tasks. I understand why: it's a hell of a lot easier than implementing a trashcan, timed undo, joining in helpful data, etc, but man, one good session with a couple hundred resources that need to be deleted this way is enough to burn you out pretty hard on these.
Also, systems that go for these lazy solutions tend also to go for the lazy solution of "just delete and recreate the resource" instead of implementing proper modify functionality. This compounds the problem. As if administrative tasks didn't already come with enough drudgery, now you have to constantly do the old timey school punishment of writing lines just to do your job.
"Just add friction" is evil. Easy, but evil.
More and more IT systems are starting to do this for more and more tasks. I understand why: it's a hell of a lot easier than implementing a trashcan, timed undo, joining in helpful data, etc, but man, one good session with a couple hundred resources that need to be deleted this way is enough to burn you out pretty hard on these.
Also, systems that go for these lazy solutions tend also to go for the lazy solution of "just delete and recreate the resource" instead of implementing proper modify functionality. This compounds the problem. As if administrative tasks didn't already come with enough drudgery, now you have to constantly do the old timey school punishment of writing lines just to do your job.
"Just add friction" is evil. Easy, but evil.
I have worked with an extremely complex system in the past (Genesys Engage telephony) and their configuration was so complex that changing even the most innocuous attribute in the most seemingly unrelated object could bring the system to its knees.
As time went by they slowly started to “improve” the situation by constantly forcing you to click through a “changing this setting may have knock on effects to your system” banner…that they showed every time you changed anything. Making it completely useless for actually preventing you from harming your system and really just giving the impression they were trying to cover their butts legally.
I hated working with that platform.
As time went by they slowly started to “improve” the situation by constantly forcing you to click through a “changing this setting may have knock on effects to your system” banner…that they showed every time you changed anything. Making it completely useless for actually preventing you from harming your system and really just giving the impression they were trying to cover their butts legally.
I hated working with that platform.
> It even makes you type the name of the repo you want to make private before proceeding - I don't see how that wouldn't make anyone snap out of autopilot.
If you're using Github's CLI tool, you can autoconfirm repo deletion so that you won't have to type the name ever again. It seems like if Github were to change their UI, they would need to somehow change their API as well.
If you're using Github's CLI tool, you can autoconfirm repo deletion so that you won't have to type the name ever again. It seems like if Github were to change their UI, they would need to somehow change their API as well.
When doing such massive changes it may be worthwhile to consider using the API (requires some coding, but still faster then typing in the repo names)
It wasn't github. There was no API, and if there had been, I would have been ill advised to trust it.
>he was not sufficiently warned of the consequences
Like most computer warnings it was overly generic, it warned there are potential consequences, but never warned of the actual consequences. If the warning had said hey this is going to effect 55K stars and watchers, he would have known he was in the wrong spot.
The problem is if you expect a generic warning then a generic warning doesn't actually warn. A specific warning is more likely to, but not guarantied to catch attention.
Like most computer warnings it was overly generic, it warned there are potential consequences, but never warned of the actual consequences. If the warning had said hey this is going to effect 55K stars and watchers, he would have known he was in the wrong spot.
The problem is if you expect a generic warning then a generic warning doesn't actually warn. A specific warning is more likely to, but not guarantied to catch attention.
Warnings are vastly less useful than making such activities less dangerous.
If you feel something needs get giant flashing warning messages perhaps make it reversible for a week.
If you feel something needs get giant flashing warning messages perhaps make it reversible for a week.
I don't know for sure but I think in some jurisdictions "hang on to this data you told me to delete for another week" would be a non-starter.
They could simply offer a “move to trash” approach to get around any legal restrictions of the kind you are imagining.
This would also be much nicer UX. Just click a button to delete something, and it says something like “This has has been moved to Trash, and will be permanently deleted in 30 days”. No big scary warnings needed. And you can still delete it immediately if you want (by emptying your trash afterwards) so it’s not in breach of any laws.
This would also be much nicer UX. Just click a button to delete something, and it says something like “This has has been moved to Trash, and will be permanently deleted in 30 days”. No big scary warnings needed. And you can still delete it immediately if you want (by emptying your trash afterwards) so it’s not in breach of any laws.
Which ones? Even in Europe there is ample time for replying and complying to GDPR requests. Way more than would be needed for this specific case.
The issue wasn't that the warning was different, it's that the user level README repo is named "username/username", but the organisation README is named "org/.githib". The person typed "org/org" on autopilot, thinking that orgs worked the same as users. This is a product inconsistency that is not immediately obvious and since there are product differences, the dialog for orgs vs users should definitely be different.
> It seems a bit much to expect the website to show you a warning of different levels of severity
I've done this for personal projects. I don't see why GitHub can't do something similar.
> It even makes you type the name of the repo you want to make private before proceeding
No, it literally does not. Nor does this mean you fully understand the implications of what you are doing as explained in the article.
> check what repo you're in before taking destructive actions
The amount of checking and automation of things for non-destructive actions, you'll forgive someone for expecting a bit of extra automation that, in this case, literally costs less.
I've done this for personal projects. I don't see why GitHub can't do something similar.
> It even makes you type the name of the repo you want to make private before proceeding
No, it literally does not. Nor does this mean you fully understand the implications of what you are doing as explained in the article.
> check what repo you're in before taking destructive actions
The amount of checking and automation of things for non-destructive actions, you'll forgive someone for expecting a bit of extra automation that, in this case, literally costs less.
It seems a bit few to expect a website to show us which repository are we going to delete on the delete page, instead of hiding it (or not showing). Datas, charts, content, every info that it could gather, and it may matter. Name is not enough.
Also I believe that asking us every day the ridiculously braindead act, to copy a text from here to there is more harmful than it helps, it just sets people to autopilot mode. Although I don't have any measures.
Also I believe that asking us every day the ridiculously braindead act, to copy a text from here to there is more harmful than it helps, it just sets people to autopilot mode. Although I don't have any measures.
A developer at GH made the same mistake. It clearly means the UI is not working the way intended.
On one hand, there's a UI change GitHub could implement that would greatly prevent this situation from happening again. On the other hand, one could try warn every github users that this situation can happen and to be carefull... Well I have my opinion on which would be most effective.
On one hand, there's a UI change GitHub could implement that would greatly prevent this situation from happening again. On the other hand, one could try warn every github users that this situation can happen and to be carefull... Well I have my opinion on which would be most effective.
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?
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?
Let's assume that the stars don'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't see all their stars, they can only see their stars for the public repos. There'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 "this repo is now private" 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.
- The users can still see all their stars and find the private repo, which makes it not private.
- The users can't see all their stars, they can only see their stars for the public repos. There'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 "this repo is now private" 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.
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's been started, but the name isn't really what's important most of the time.
And there's always the potential to add a other toggle when privating a repo that lets you force-remove all stars.
And there's always the potential to add a other toggle when privating a repo that lets you force-remove all stars.
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't delete it fully until a month later
Sorta like most social media apps when you want to delete your account. It doesn't delete it fully until a month later
> 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's also the webarchive. You should be able to unstar it or keep your star, the only difference is that you don't know if the repository still exists or not.
Why seeing a start you made for a previously public repository makes it not private? People remember things too, there's also the webarchive. You should be able to unstar it or keep your star, the only difference is that you don't know if the repository still exists or not.
> the only difference is that you don't know if the repository still exists or not.
If an admin were to private->delete, then all the stars referencing the report would stay and thus the reference to the repo would still be there, on GitHub's servers. There's a difference between GitHub storing things forever and third parties on the internet being a forever archive of visible pages.
If an admin were to private->delete, then all the stars referencing the report would stay and thus the reference to the repo would still be there, on GitHub's servers. There's a difference between GitHub storing things forever and third parties on the internet being a forever archive of visible pages.
But that's an easy fix. If they delete the repo, delete the stars. If they make it private, indicate it is now private in some way.
That's information disclosure; nothing about the repo after it's privated should be known, including name changes and deletion.
It’s unclear to me what the attack vector is for that disclosure.
It was known and there are many sites scraping GH for metadata that will have it anyway
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.
>I think the current behaviour is better than all of these options.
Current behavior is destructive.
>- All private repos that have been public at least once lead to a "this repo is now private" 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.
Current behavior is destructive.
>- All private repos that have been public at least once lead to a "this repo is now private" 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.
Twitter has this kind of problem with likes (or maybe they fixed this since I haven't been on there in a while).
When someone deactivates their account, you can see that you have X additional likes, but you can't access them. If that user reactivates their account, those likes suddenly show back up.
This could be a privacy issue if you'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.
When someone deactivates their account, you can see that you have X additional likes, but you can't access them. If that user reactivates their account, those likes suddenly show back up.
This could be a privacy issue if you'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 users can't see all their stars, they can only see their stars for the public repos. There'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.
Sounds fine and expected to me.
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's simply an indicator that they video is 'no longer available'. I don't see why something similar can't be the behaviour for GitHub stars and watches?
When youtube videos are taken down or made private, they are not deleted necessarily from my playlists. There's simply an indicator that they video is 'no longer available'. I don't see why something similar can't be the behaviour for GitHub stars and watches?
You do lose the title, which is super annoying. "What did I used to have?" Super frustrating feeling.
Here's a list of your favourite songs, but two are missing, have fun figuring out which two it is!
Here's a list of your favourite songs, but two are missing, have fun figuring out which two it is!
I recently discovered a neat trick that if you Google the url for the private video (you still have this in your list), you're likely to find the title of the video, therefore allowing you to at least figure out what it was and seek out a new video.
Agreed. This just screams bad UX on a corner case.
1) probably not the desired experience
2) 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/privacy constraints. So err on the side of deleting rather than potential privacy/security bug.
Definitely fixable with some decent investigation, coding, etc. - but hard to prioritize.
2) 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/privacy constraints. So err on the side of deleting rather than potential privacy/security bug.
Definitely fixable with some decent investigation, coding, etc. - but hard to prioritize.
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.
Technically you want to delete dependent stuff, but in this case this seems like overstepping on development side.
I don’t know for certain but I feel like this could allow something like 1. Takeover/inherit public repo with lots of stars 2. Take repo private (retaining stars) 3. Replace repo code with some malicious/offensive code. 4. Take repo public again 5. Inherit the trust/prestige of the old repo.
But couldn't the same be achieved without taking it private?
You can do that without the “making it private and public again” part anyway.
Yeah, that's a risk. They could mitigate it by allowing you to revert all branches/tags back to the pre-private state, but we're getting more and more complicated here.
Yeah but it's not like stars are seen as some amazing endorsement on the part of the individual starring. It's more like a favorites list if anything
stars absolutely are seen as an endorsement. I'm guilty of that for sure, and I've been in a ton of conversations about adopting some thing and the "number of stars" is often a consideration unless it's a project like React or Vue, etc.
Would you really not look at two repos that do the same thing, with similar ages and recent commits but one has zero stars and the other has hundreds, and not at least initially trust the latter more?
Would you really not look at two repos that do the same thing, with similar ages and recent commits but one has zero stars and the other has hundreds, and not at least initially trust the latter more?
[deleted]
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're on the HN's frontpage, hopefully somebody from Github upper management will see this and all will be good soon thanks to gold old HN (especially when they did the same thing themselves and restored it).
Wish you the best.
Now that you're on the HN's frontpage, hopefully somebody from Github upper management will see this and all will be good soon thanks to gold old HN (especially when they did the same thing themselves and restored it).
Wish you the best.
> That 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's not the only difference. The other difference is that you also have to type the full repository name, including the organization name.
If they wanted to delete the correct repository, they would have to type httpie/.github, but instead they typed httpie/httpie.
It's unfortunate what happened, but without GitHub removing the possibility at all to delete repositories/change the visibility, I don't know what else they could have done to try to prevent it. It's really hard as a user to affect the wrong repository, as you are gonna have to mentally and literally pause to write out the organization name + repository (httpie/httpie in this case) and if that doesn't stop you, I don't think anything would.
That's not the only difference. The other difference is that you also have to type the full repository name, including the organization name.
If they wanted to delete the correct repository, they would have to type httpie/.github, but instead they typed httpie/httpie.
It's unfortunate what happened, but without GitHub removing the possibility at all to delete repositories/change the visibility, I don't know what else they could have done to try to prevent it. It's really hard as a user to affect the wrong repository, as you are gonna have to mentally and literally pause to write out the organization name + repository (httpie/httpie in this case) and if that doesn't stop you, I don't think anything would.
> I don't know what else they could have done to try to prevent it.
As the author of the post suggests: Prominently spell out "This will remove 54,000 stars." vs. "This won't remove any stars (there are none yet)."
As the author of the post suggests: Prominently spell out "This will remove 54,000 stars." vs. "This won't remove any stars (there are none yet)."
I'm not convinced that would have really solved the problem. One could just as easily post a screenshot of two nearly identical dialogs where the only different is that one says "This will remove 54 stars" and the other says "This will remove 54,000 stars" and the same argument could be made that "the only way to notice the difference is if you happen to notice those 3 zeros."
>I'm not convinced that would have really solved the problem.
It almost certainly would help. When you attempt to delete a world of warcraft character you are prompted with the character's level, among other info. This is the biggest difference you'll see between the delete procedure for a level 1 alt with < 1 hr played and a level 80 (or w/e) character with >10,000 hr played if you've named them similarly.
Because of the relatively low character limit and the popularity of alts, this feature (delete character) gets a lot of use and misuse so it's reasonable to expect the developers to have put some thought in to it.
It almost certainly would help. When you attempt to delete a world of warcraft character you are prompted with the character's level, among other info. This is the biggest difference you'll see between the delete procedure for a level 1 alt with < 1 hr played and a level 80 (or w/e) character with >10,000 hr played if you've named them similarly.
Because of the relatively low character limit and the popularity of alts, this feature (delete character) gets a lot of use and misuse so it's reasonable to expect the developers to have put some thought in to it.
It seems like a pretty easy feature to build. No database changes required, and I wouldn't be surprised if the API already returns the star count for the repo so it's client-side only. I'd guess somebody could do it in a couple of hours (famous last words lol). I'd guess adding that feature would be less time/effort than restoring httpie's stars. A/B testing might be a little harder since conditions like OP's don't happen often, but you could at least do some testing.
Another commenter suggested having to type the number of stars you’d be forfeiting instead of the repo name. Kind of a neat idea I think.
In practice, they are extremely unlikely to be zeroes.
No amount of warning popups will help. The only solution is a delayed delete with the option to undo.
I think the only people who won’t notice three trailing zeroes are people who don’t need to
Until the next post by someone else that missed that warning and suggest to make the warning blinking with a big font
There is a difference between using UI tweaks (color/size/motion) to call out information, and actually displaying that information.
Right? As in, "this will affect 0 stars" vs "this will affect 54,000 stars" is an informational difference. Calling out "this will affect all stars" (without specifying a number) doesn't break a user out of doing it to the wrong repo, since that message is the same in both cases.
Right? As in, "this will affect 0 stars" vs "this will affect 54,000 stars" is an informational difference. Calling out "this will affect all stars" (without specifying a number) doesn't break a user out of doing it to the wrong repo, since that message is the same in both cases.
> That'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's cluster into a field before deleting it. Automated deployments sometimes got left behind - and users would go in periodically and clean them up.
If you watched folks, they would type the name of the cluster being deleted into that box UNTIL they had to do this many times in a row. As soon as it was a "batch" job, folks would go through the motion of:
1. click delete
2. double click service name
3. ctrl+c
4. click text input
5. ctrl+v
6. press "Confirm"
It was remarkable, after someone did this once, I don't think I ever observed them going back to typing in the cluster name. That algorithm of "copy and paste" carried over into every prompt they saw of that form moving forward.
I'm guilty of this too - I no longer type the prompted name for this form of confirmation dialogue, it's a copy-and-paste.
This is not true.
We had an internal tool at a previous job that required you to type the name of a service's cluster into a field before deleting it. Automated deployments sometimes got left behind - and users would go in periodically and clean them up.
If you watched folks, they would type the name of the cluster being deleted into that box UNTIL they had to do this many times in a row. As soon as it was a "batch" job, folks would go through the motion of:
1. click delete
2. double click service name
3. ctrl+c
4. click text input
5. ctrl+v
6. press "Confirm"
It was remarkable, after someone did this once, I don't think I ever observed them going back to typing in the cluster name. That algorithm of "copy and paste" carried over into every prompt they saw of that form moving forward.
I'm guilty of this too - I no longer type the prompted name for this form of confirmation dialogue, it's a copy-and-paste.
Lol, I do this whenever they ask me to re-enter my email/password for verification even though I know exactly the purpose this mechanism is trying to enforce.
Humans will always take the easiest route. We just have to accept that and come up with better solutions that aid humans or fit to our very weird nature.
Humans will always take the easiest route. We just have to accept that and come up with better solutions that aid humans or fit to our very weird nature.
This is exactly what you start doing on Github too, since many repo operations require you to do it. Seeing this warning modal where you have to copy-paste some string is what you expect when clicking delete/make private/make public. I don't know if it really helps.
I think you make a good point, the retyping is not perceived as a genuine sort of 2-factor step but is perceived like an annoyance. Maybe the consequences of the action should be shown in a screenshot with a 5 second wait. Personally the only reason it works for me as a 2-factor is because I think about what Github's intent is when they prompt me to retype the repo name and therefore I take a moment to reflect that I indeed want to do what I want to do. But isn't that backwards? I have to imagine what Github's intention was instead of simply seeing a ui and understanding it for what it is.
> I'm guilty of this too
You and most of the rest of us, I suspect. Like I want to type that out every time...
You and most of the rest of us, I suspect. Like I want to type that out every time...
I mean obviously users are going to cut and paste that output. It's completely hostile design in terms of usability on their part. What did you expect to happen?
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.
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're asked to type to the repository you're intending to modify.
Most of the time that's true, or we'd be hearing about this happening all of the time. But 'most of the time' is not 'every time'. 'Almost always' is also not 'every time'. This is a distinction that Human Factors people make that victim-blaming nerds do not.
You've seen the video on Youtube (or Reddit) of the guy holding the fish throwing his phone into the lake? He didn't do that because he was stupid, he did it because he made an executive decision to, "hold fish, take picture with phone, throw it in the water" and then his motor cortex swapped 'it' to the wrong hand and went on autopilot.
If you don't like that example, I know of a highly secure data center in Seattle that had the emergency power cutoff button pushed not once but twice by different tenants. The first time was a pure accident of bumping it while doing maintenance. The second time someone opened an acrylic case and pushed the button because they thought "buttons open doors, I see a button. Sure is weird that it is covered with a box... hey why did the lights go out?" You have problem, you observe action or object that solves problems (maybe not this problem), monkey brain attempts action to see if problem is solved.
Typing in the repository name narrows the gap between intent and action, but it doesn't close it. Technically making someone type, "Make hippie/hippie private" would at least make them spell out the intent, narrowing it again. But it doesn't make them state the intent. Strictly speaking, they are being told to transcribe text. Whether they parse the text they're typing or not is a separate step, in two different parts of the brain. Any of those fails to connect and you have a catastrophic destruction. From a Precautionary Principle standpoint, the consequences are exactly the same with all three options, and only the likelihood has changed.
If you want to make a big dent in outcomes you have to also reduce the consequences, not just the opportunity. Making all actions reversible is the most conceptually simple and the most technically difficult option. Parceling out consequences over time is usually less difficult, and if you pick an order that makes the feedback immediate, then the person realizes quickly that what they meant and what they said didn't line up, before the real damage kicks in.
Github is built around git. The two biggest ways to permanently lose data from git, one of them is protected by permissions and may be off by default. The other one is automatic but takes 30 days. That's two very different precedents that have been set, and they picked the wrong one to emulate.
Most of the time that's true, or we'd be hearing about this happening all of the time. But 'most of the time' is not 'every time'. 'Almost always' is also not 'every time'. This is a distinction that Human Factors people make that victim-blaming nerds do not.
You've seen the video on Youtube (or Reddit) of the guy holding the fish throwing his phone into the lake? He didn't do that because he was stupid, he did it because he made an executive decision to, "hold fish, take picture with phone, throw it in the water" and then his motor cortex swapped 'it' to the wrong hand and went on autopilot.
If you don't like that example, I know of a highly secure data center in Seattle that had the emergency power cutoff button pushed not once but twice by different tenants. The first time was a pure accident of bumping it while doing maintenance. The second time someone opened an acrylic case and pushed the button because they thought "buttons open doors, I see a button. Sure is weird that it is covered with a box... hey why did the lights go out?" You have problem, you observe action or object that solves problems (maybe not this problem), monkey brain attempts action to see if problem is solved.
Typing in the repository name narrows the gap between intent and action, but it doesn't close it. Technically making someone type, "Make hippie/hippie private" would at least make them spell out the intent, narrowing it again. But it doesn't make them state the intent. Strictly speaking, they are being told to transcribe text. Whether they parse the text they're typing or not is a separate step, in two different parts of the brain. Any of those fails to connect and you have a catastrophic destruction. From a Precautionary Principle standpoint, the consequences are exactly the same with all three options, and only the likelihood has changed.
If you want to make a big dent in outcomes you have to also reduce the consequences, not just the opportunity. Making all actions reversible is the most conceptually simple and the most technically difficult option. Parceling out consequences over time is usually less difficult, and if you pick an order that makes the feedback immediate, then the person realizes quickly that what they meant and what they said didn't line up, before the real damage kicks in.
Github is built around git. The two biggest ways to permanently lose data from git, one of them is protected by permissions and may be off by default. The other one is automatic but takes 30 days. That's two very different precedents that have been set, and they picked the wrong one to emulate.
The other thing they could do is make user/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 `<user>/<user>`, so doing `httpie/httpie` for the organization made contextual/autopilot sense in the moment.
> The other difference is that you also have to type the full repository name, including the organization name.
No, you don't have to type it, and I doubt anyone types it. You copy that line and paste it. Often it's done on autopilot, especially when in a rush.
No, you don't have to type it, and I doubt anyone types it. You copy that line and paste it. Often it's done on autopilot, especially when in a rush.
I always just select the text and drag drop it in the text box with mouse.
In famous words of Mr. Larry wall, 3 great virtues of every programmer: laziness, impatience, and hubris.
In famous words of Mr. Larry wall, 3 great virtues of every programmer: laziness, impatience, and hubris.
I type it.
It’s typically short short, and it’s a very destructive action. It’s also very apparent to me why I would want to type it out.
That said, someone is going to make a mistake at some point. I’d expect better from github support here.
It’s typically short short, and it’s a very destructive action. It’s also very apparent to me why I would want to type it out.
That said, someone is going to make a mistake at some point. I’d expect better from github support here.
This topic really got me thinking.
A lot of us navigate by typing, be it CLI, in our IDE, URLs etc. And we must have got used to type hundreds of times our company or project names every day, in many places.
I can't imagine typing <project name>/<project name> in a input box triggering in us a lot consciousness or extra care. Typing something more unusual could actually be more impacting I think.
A lot of us navigate by typing, be it CLI, in our IDE, URLs etc. And we must have got used to type hundreds of times our company or project names every day, in many places.
I can't imagine typing <project name>/<project name> in a input box triggering in us a lot consciousness or extra care. Typing something more unusual could actually be more impacting I think.
Maybe some kind of grace period could be implemented that would allow changes like this to be undone within 24 hours or something.
Just showing the two screenshots feels a little disingenuous though. It'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'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.
In both cases the dialog clearly warns you, with bolded text, on a separate line, of the consequences of your actions.
"We were in the top Xth percentile" makes the author sound like a complete tool and I have little sympathy for them, especially given they're already back to 3k stars.
Expecting the dialog to say "now, you've got 50,000 stars, are you REALLY REALLY SURE?" is just infantile, but really matches the overall tone the author has.
"We were in the top Xth percentile" makes the author sound like a complete tool and I have little sympathy for them, especially given they're already back to 3k stars.
Expecting the dialog to say "now, you've got 50,000 stars, are you REALLY REALLY SURE?" is just infantile, but really matches the overall tone the author has.
The dialog clearly warns you that if you have something to delete, it will be deleted, but it doesn't let you know if there is anything to delete.
That's not in itself a huge problem, but in this case it was compounded with the fact that the generic repo he was acting on is named inconsistently for users vs organizations, and he had just done it on his user account. If I'm reading correctly, a user's profile readme repo is `<user>/<user>`, while for organizations it is `<org>/.github`, and, crucially, `<org>/<org>` is almost always going to be the core project for that org.
So yes, the warning says you will lose all stars on the project, but in the moment it would have seemed (to a fallible human brain who was in a user-space context) that this was the right repo, whereas a "you will lose 54k stars" message would have broken the user out of that space.
That's not in itself a huge problem, but in this case it was compounded with the fact that the generic repo he was acting on is named inconsistently for users vs organizations, and he had just done it on his user account. If I'm reading correctly, a user's profile readme repo is `<user>/<user>`, while for organizations it is `<org>/.github`, and, crucially, `<org>/<org>` is almost always going to be the core project for that org.
So yes, the warning says you will lose all stars on the project, but in the moment it would have seemed (to a fallible human brain who was in a user-space context) that this was the right repo, whereas a "you will lose 54k stars" message would have broken the user out of that space.
I'm afraid to think that these same people, having attitudes like this, are driving cars on public roads.
It does strike me as unfair that GitHub themselves made the exact same mistake but were able to fix it with database backups.
I'm just surprised that after going through that pain themselves they didn't decide to revise how that social linking data is handled. A lot of github content is softly deleted by necessity, you couldn't nuke tickets written by a now non-existent user or unmerge PRs so this isn't really a new concept to the team.
I don't think it's surprising they'd do such a thing for themselves and not a customer - I'm more surprised they didn't remove the footgun for future mistakes on their part.
I don't think it's surprising they'd do such a thing for themselves and not a customer - I'm more surprised they didn't remove the footgun for future mistakes on their part.
Just as AceJohnny said, the scope of this is entirely different. Restoring a backup for an internal project costs time/resources that the company can easily handle. If it became a problem it would be easy for github to tell their internal projects "No, we're no longer restoring from backups"
Opening up the ability to do that externally would potentially require multiple people working full-time to handle the requests.
"We even offered GitHub financial compensation for any resources required." Considering the tone of the article I think there's a very high risk if github accepted agreed to that we'd see an article titled "Github charges popular open source project $5000 to fix a minor accident"
Opening up the ability to do that externally would potentially require multiple people working full-time to handle the requests.
"We even offered GitHub financial compensation for any resources required." Considering the tone of the article I think there's a very high risk if github accepted agreed to that we'd see an article titled "Github charges popular open source project $5000 to fix a minor accident"
Or, knowing that it'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.
Or, just leave everything in place, always, and have the other code ignore the annotations for exactly as long as the repo is private.
Just FYI - you can star private repositories so it's not quite that simple. You'd need to determine if the starring aligns with permissions... but I think it's still relatively reasonable.
Ok, then have a separate button: "Delete all 54,000 stars on this repo", completely independent of public/private.
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.
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.
I get that, but they probably shouldn't have publicized the remediation via a public tweet if it's an avenue that's closed to the rest of us plebs (since in cases like this, it really feels like salt in the wound).
I wonder how different the response from Github would be if this blog post was instead, "Oops, Github's confusing UI made me delete the entire project metadata... so since we're forced to start fresh we decided to move to Gitlab/sourcehut/etc."
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 "selling" and that the others can't provide.
There was a way to say this without framing it as a personal attack. The author may care about stars because they find that increased engagement leads to higher quality contributions, for example.
[deleted]
httpie would never do this. Deleting their stars is already a blow for their community, but changing to another provider would kill it.
And yet they specifically call out Microsoft. And then the only consequence is "I will probably take a break from wearing Octocat-decorated t-shirts."
Which makes them come out as hypocrites. You don't get to blame Microsoft for EEE, and then continue to help them with it !!
Which makes them come out as hypocrites. You don't get to blame Microsoft for EEE, and then continue to help them with it !!
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 "can you stop what you're doing and unfuck this thing" it would obviously depend on what I was working on.
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 "can you stop what you're doing and unfuck this thing" it would obviously depend on what I was working on.
It'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.
Being busy is lazy? GH has hundreds of thousands of customers. In your company, how often do you immediately drop everything to work on a single customer's issue? How often do customer issues sit in a support queue? What would be the reasonable turn around time for an issue like this?
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 "hot" repo.)
[1] - https://web.archive.org/web/20201116172809/https://github.co...
(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 "hot" repo.)
[1] - https://web.archive.org/web/20201116172809/https://github.co...
It would strike me even more unfair if GitHub fixed this mistake only for customers they like.
What is possibly unfair about that?
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.
https://alistapart.com/article/neveruseawarning/
https://alistapart.com/article/neveruseawarning/
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.
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”.
Or, have there be no need to undo anything. Why should ticking the "private" flag have any effect on anything else? If you wanted an effect on something else, a separate button "Nuke all 53,675 star from this repo", with its own protections, would suffice.
How would stars and watchers work on a private repo, though?
Could just make them inactive for a while, but still registered.
Stop sending notifications to watchers, and replace the repo in the stargazer's starred list with a "The following starred repos are currently private and cannot be viewed:" and make the stars be remove-only for a while.
Stop sending notifications to watchers, and replace the repo in the stargazer's starred list with a "The following starred repos are currently private and cannot be viewed:" and make the stars be remove-only for a while.
Just don't show them. Filter out private repos before showing a user's stars, notifying them of issues, etc.
Right, just more work. More tests. More edge cases. More time.
Well, they put in the time to test a massive cascading delete operation. Surly a flag would have offered far less possibility of catastrophic outcomes and therefore would been significantly easier to confidently develop and test.
If they are using a database's built in support for cascading deletes, and if the star tables are simple m2m tables (basically just 2 fk's per row), the work to implement and test cascading deletes is trivial.
Cascade delete is a less risky operation from a security stand point. There are so many edge cases where potentially sensitive information could get leaked with regards to subscribed private repos if not handled correctly. In fact I have personally filed a bug bounty with GitHub after discovering just such a bug.
I’m not saying there isn’t a better way Github could handle this situation. Just that I do sympathise with the decision to cascade delete.
I’m not saying there isn’t a better way Github could handle this situation. Just that I do sympathise with the decision to cascade delete.
Sure. But that’s the cost of good UX.
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.
If you made something public on GitHub that shouldn’t have been, it was immediately compromised, you just might not notice.
[deleted]
Making a private repo public could also be delayed.
It'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.
Warnings can be done completely within the frontend, that probably makes them way more desirable for the company.
It’s definitely easier from the implementer’s point of view. That doesn’t make the UX any better, though.
Hi newbie developer here, where do i find and learn about ux design priciples like this? Just curious, thank you thank you.
"Design of everyday things" is a great book to start.
https://rachelbythebay.com/w/2020/10/26/num/ makes a similar point. I don't remember us saying people only have themselves to blame when that article was posted (https://news.ycombinator.com/item?id=24904204). Not sure why we're doing it on this post, which makes a number of completely reasonable and specific suggestions for improvement.
"Type a specific thing to confirm" (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 "autopilot". At that point the suggestions go beyond being reasonable.
The confusion is justifiably well explained by the article:
> What put me on the wrong path was an otherwise completely unrelated action: I had just done the same (i.e., hidden an empty README) on my personal profile by making jakubroztocil/jakubroztocil private.
> GitHub’s conceptual model treats users and organizations as very similar entities when it comes to profiles and repos. 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.
> I didn’t realize at the moment there’s an inconsistency in the naming of this special repo containing profile READMEs and that it differs for users and organizations: name/name vs. name/.github.
> That’s why I proceeded to make httpie/httpie private instead of httpie/.github without realizing my mistake.
> What put me on the wrong path was an otherwise completely unrelated action: I had just done the same (i.e., hidden an empty README) on my personal profile by making jakubroztocil/jakubroztocil private.
> GitHub’s conceptual model treats users and organizations as very similar entities when it comes to profiles and repos. 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.
> I didn’t realize at the moment there’s an inconsistency in the naming of this special repo containing profile READMEs and that it differs for users and organizations: name/name vs. name/.github.
> That’s why I proceeded to make httpie/httpie private instead of httpie/.github without realizing my mistake.
You really think that adding contextual information in a destructive modal (i.e. "You are about to erase 54,000 stars") is "beyond being reasonable" ?
It seems like a pretty reasonable suggestion that doesn't feel like a lot of work, but could potentially prevent an irreversible mistake.
It seems like a pretty reasonable suggestion that doesn't feel like a lot of work, but could potentially prevent an irreversible mistake.
It doesn't suggest that you type a any old "specific thing". It specifically suggests that you type something to demonstrate you acknowledge the scale of the destructive operation you are about to perform.
The OP's main suggestion is along exactly those lines. It's actually less extreme, in some ways (see OP's "Lesson 1").
The OP's main suggestion is along exactly those lines. It's actually less extreme, in some ways (see OP's "Lesson 1").
This isn't "exactly" 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.
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't get is why it even needs to delete all the stars? It's not like they delete all comments/issues... by users who have been deleted. So why could they not simply make the star point to a "ghost repository"?
The main thing I really don't get is why it even needs to delete all the stars? It's not like they delete all comments/issues... by users who have been deleted. So why could they not simply make the star point to a "ghost repository"?
> Of course, if you run into this a lot and you actually intend to hit that many machines, someone might start cutting and pasting the number. In that case, I would say that you're using that tool far too often, and should take a look at changing the way things are done to avoid having to rely on it this much.
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.
Apart from it being clear that the UI and the user using it could have been better, I don’t agree with criticism like “GitHub should obviously do x” or “this would be easily resolved if the action didn’t caused cascading deletes” and so on.
GitHub is a large and complex set of applications, and making changes like that is probably not trivial. It’s probably not a high priority either. This is the first time I’ve heard of this in the existence of GitHub, and while that doesn’t mean it has only happened once, I suspect it’s rarely a meaningful issue.
Solving problems like this at GitHub’s scale is often hard both due to the need to do things that matter more, and due to how entrenched database schemas and application architectures tend to be. I’m sure their migrations are plenty scary to manage, and doing it to alter behaviour when toggling privacy on a repository understandably wouldn’t be high on their list of reasons to perform one.
Aside from those concerns, I bet there are a lot of lines of code which assume stars exist for specific reasons. Once they can exist for another reason, you have to rewrite logic around that, rewrite tests for that logic, etc. It could easily be way more work than it seems at a glance.
GitHub is a large and complex set of applications, and making changes like that is probably not trivial. It’s probably not a high priority either. This is the first time I’ve heard of this in the existence of GitHub, and while that doesn’t mean it has only happened once, I suspect it’s rarely a meaningful issue.
Solving problems like this at GitHub’s scale is often hard both due to the need to do things that matter more, and due to how entrenched database schemas and application architectures tend to be. I’m sure their migrations are plenty scary to manage, and doing it to alter behaviour when toggling privacy on a repository understandably wouldn’t be high on their list of reasons to perform one.
Aside from those concerns, I bet there are a lot of lines of code which assume stars exist for specific reasons. Once they can exist for another reason, you have to rewrite logic around that, rewrite tests for that logic, etc. It could easily be way more work than it seems at a glance.
But.. one of their developers also made the same mistake as the OP. The OP learned a lesson but seemingly anyone at GitHub didn’t think, “we should fix this confirmation dialog so this doesn’t happen again”.
It’s also possible that they did consider it, but upon investigation it entailed more work than they could justify.
I do think including more context about what will be destroyed by the action would be great, and probably pragmatic, but… If typing out the name of the repository isn’t enough, providing context might not be either.
The more I think about it, the more it seems like one of those “Whatever, we’ve got a million other things to do” situations. It might get a handful of inquiries about it per year while a dozen other features get hammered with attention and requests from paying customers.
Again, not saying they can’t improve it. Just giving them the benefit of the doubt here and proposing that it’s possible that it isn’t better for legitimate reasons.
I do think including more context about what will be destroyed by the action would be great, and probably pragmatic, but… If typing out the name of the repository isn’t enough, providing context might not be either.
The more I think about it, the more it seems like one of those “Whatever, we’ve got a million other things to do” situations. It might get a handful of inquiries about it per year while a dozen other features get hammered with attention and requests from paying customers.
Again, not saying they can’t improve it. Just giving them the benefit of the doubt here and proposing that it’s possible that it isn’t better for legitimate reasons.
They're owned by Microsoft and funded/now led by by Nat Friedman. They can justify a lot.
No doubt, and I’ve never worked on a team with these kind of resources so I can’t be certain either. I’m just advocating for the people at GitHub and casting doubt that it’s trivial to avoid situations like this or resolve them.
Should customers who have had a bad experience just not give any feedback then?
Github should be grateful for this feedback. I know that it takes effort to make your product or service better, but that doesn't mean that customers shouldn't ever say anything. Customers are telling Github how it can improve its service. Github can choose to listen to them, or not.
With some simple frontend changes, they can probably reduce accidental destructive changes to customer's accounts.
I think Github cut some corners here. I would much rather that repo stars were treated similar to how resources on other platforms are. If someone makes it private, then return 403 "repos is private"
Github should be grateful for this feedback. I know that it takes effort to make your product or service better, but that doesn't mean that customers shouldn't ever say anything. Customers are telling Github how it can improve its service. Github can choose to listen to them, or not.
With some simple frontend changes, they can probably reduce accidental destructive changes to customer's accounts.
I think Github cut some corners here. I would much rather that repo stars were treated similar to how resources on other platforms are. If someone makes it private, then return 403 "repos is private"
I completely agree that the feedback is valuable and I don’t think no one should say anything. In fact I think it’s essential to say something.
I’m only commenting on how so many comments trivialize the work required to resolve this. I have a feeling nothing is trivial at GitHub.
I’m only commenting on how so many comments trivialize the work required to resolve this. I have a feeling nothing is trivial at GitHub.
Reminds me of our own quest to stop users from deleting their entire projects by accident in our product.
1st iteration: delete button with a confirmation box (standard stuff). Users click through the box in autopilot mode and still delete their entire projects.
2nd iteration: someone came up with an idea: confirmation box + an additional checkbox (if it isn't checked, the delete button is disabled). Users still manage to delete projects by accident. When we asked them how that happened (we've set up so many hurdles!), the user says, just like in the article, that they thought they were deleting a different (test) project.
3rd iteration: I suggested showing the number of objects in the project (just like suggested in the article) so that the user knew they aren't deleting a test project.
I moved on to a different project since, but the saga probably continues.
1st iteration: delete button with a confirmation box (standard stuff). Users click through the box in autopilot mode and still delete their entire projects.
2nd iteration: someone came up with an idea: confirmation box + an additional checkbox (if it isn't checked, the delete button is disabled). Users still manage to delete projects by accident. When we asked them how that happened (we've set up so many hurdles!), the user says, just like in the article, that they thought they were deleting a different (test) project.
3rd iteration: I suggested showing the number of objects in the project (just like suggested in the article) so that the user knew they aren't deleting a test project.
I moved on to a different project since, but the saga probably continues.
Same here. I finally brought accidentally deleting stuff down to zero by having them type the number they get to lose:
"You have 55,231 GitHub stars. Please type 55231 if you want to delete them all."
But I guess, if you delete repos often enough, this will also become muscle memory.
Edit: Just saw the other comment here suggesting the same: https://news.ycombinator.com/item?id=31033996
"You have 55,231 GitHub stars. Please type 55231 if you want to delete them all."
But I guess, if you delete repos often enough, this will also become muscle memory.
Edit: Just saw the other comment here suggesting the same: https://news.ycombinator.com/item?id=31033996
So, for projects with 100+ stars, add a wait period of 60 seconds until the delete button can be clicked _after_ the number is typed in. That should allow most users on autopilot to snap out of it, or make drunk users switch to a different tab and forget about it.
almost all of my projects have < 5 stars, typing "0" half the time is more dangerous than typing my_name/my_repo.
Better to flag it as archived. This way they can unarchive if need be.
just do soft deletes that can be undone... seems so easy..
GitHub also makes you type out the project name and that still did not help here.
I guess users will always be able to fuck things up.
Best solution would be to offer undos but then people will complain that deleting things does not actually delete. You are keeping data to yourself! Start citing privacy issues etc.
There is no winning here.
I guess users will always be able to fuck things up.
Best solution would be to offer undos but then people will complain that deleting things does not actually delete. You are keeping data to yourself! Start citing privacy issues etc.
There is no winning here.
Damn, would be interesting to know what the effects of the third iteration is.
Would validate/invalidate the authors ui suggestions.
Would validate/invalidate the authors ui suggestions.
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”
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.
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.
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.
Yea, over simplify it, that's always great.
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.
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.
To be fair, people very active in a project will probably realize relatively quickly.
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.
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.
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 no irreparable harm, no data loss.
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.
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.
I've never considered data I deleted to be lost.
"Do you want to delete this?"
"Yes"
"Are you sure?"
"Yes."
....
"OMG it's all gone!?!?"
"Do you want to delete this?"
"Yes"
"Are you sure?"
"Yes."
....
"OMG it's all gone!?!?"
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?
Can you just clarify if that statement was sarcastic or not?
I've had a very different experience around stars - they're just a bit of fluff and pretty unimportant compared to watches.
I've had a very different experience around stars - they're just a bit of fluff and pretty unimportant compared to watches.
HTTPie's watches were irreversibly deleted, too.
> Irreversible
If the watchers still care to watch, they can choose to watch again.
If the watchers still care to watch, they can choose to watch again.
That's not a reversal. If I burned your diary, you could write a new one, but nobody would call that a reversal.
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.)
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.)
>If the repository had been deleted
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?
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?
Assuming you're not being sarcastic: a company providing a metric and telling you to care about it does not oblige you to actually give a shit.
I feel like a parallel universe has suddenly intersected our own.
It's very much a matter of reputation. Losing the star as a user is a pretty small inconvenience, tantamount to losing a bookmark.
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
Yeah. I'm not sure what else you can do with warnings other than make the person effectively recite back the thing they're doing.
There was an explicit suggestion right there in the article what else they could do, so you don't even have to guess.
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.
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.
> 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.
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.
> If you're muscle memorying past warning signs the text on the warning sign isn't going to matter much.
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.
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.
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.
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"
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"
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.
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.
1. https://cantunsee.space/
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.
1. https://cantunsee.space/
> I imagine the FDA has zero tolerance for vendor software that is bundled with dark patterns
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.
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.
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.
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.
They do raise a good point about the UI though, explicitly showing "you're about to nuke 55k people, are you sure?" would make the user pause.
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?
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.
Even using words like "future pain" is pretty crazy. "We lost 54k GitHub stars"? They're imaginary internet points! Cope.
It sounds like you are ok with the post, except for the one sentence before the epilogue?
Acknowledge their own agency and responsibility.
Literally stop blaming with language like “GitHub deleted…”
Literally stop blaming with language like “GitHub deleted…”
How would you word that sentence and remain factual about the deletion?
“I accidentally made a repo private, which resulted in all of its stars being removed.”
From the post:
> 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.
> 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 swear there's something in the water. This entire thread has a ton of nastiness/bitterness in it.
In terms of cause and effect yes, in terms of attribution no.
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?
It’s active voice vs passive voice.
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?
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 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?
It is a big failure by github that making a repo private immediately and irrevocably destroys all the stars.
That's a much bigger failure than clicking the wrong button.
That's a much bigger failure than clicking the wrong button.
It's true that this is "PEBKAC" but it's also true that this is a UX/system design failure on GitHub's part.
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.
Github UX team has a responsibility to its customers to make this error MUCH harder to make than it is
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.
Humans make mistakes all the time. We build systems to try to mitigate these and build them better by learning from new mistakes.
Surprising amount of people blaming the user here. I agree completely with the author, the UX should be different for clearly "big" repos.
How big is "clearly big"? Whenever someone makes the same mistake with a slightly-less-big repository should the warning thresholds be revised to also show up for those?
It should just show the amount of stars / watchers for any repository. I don't think a custom strategy based on repo size is needed.
In America, we blame individuals when systems fail. We don't have to, we can actually design systems to be better. Design isn't just about making things look pretty. Good design reduces entropy.
https://www.youtube.com/watch?v=Ra_0DgnJ1uQ
https://en.wikipedia.org/wiki/Human_factors_and_ergonomics
https://www.youtube.com/watch?v=Ra_0DgnJ1uQ
https://en.wikipedia.org/wiki/Human_factors_and_ergonomics
Thankfully there are exceptions to this, notably aviation. Having all accidents investigated by an independent board with a systems approach has proven to be an extremely successful model. It's a shame it isn't replicated elsewhere.
A disgrace. It's not like it is any easier in aviation than anywhere else.
Civilian oversight of police departments could be instituted, too, investigating killings and maimings by police. It could be federally supervised, instead of relying on every state, county, and Podunk town to institute it.
Civilian oversight of police departments could be instituted, too, investigating killings and maimings by police. It could be federally supervised, instead of relying on every state, county, and Podunk town to institute it.
In aviation, a pilot who would ignore so many warning elements of UI (red button, dialog, retyping things) on "autopilot" would have their license revoked and possibly criminal charges pressed.
Contrarian opinion here.
While things can always be better the Github UX is good enough here. I am reminded of an old phrase:
“A bad workman always blames his tools.”
At some point you just need to accept responsibility for your actions and stop blaming others.
While things can always be better the Github UX is good enough here. I am reminded of an old phrase:
“A bad workman always blames his tools.”
At some point you just need to accept responsibility for your actions and stop blaming others.
Good workmen also blame their tools. Because sometimes tools are bad, and that's how they get improved.
“A bad workman always blames his tools.”
It is a workman, who builds a very succesful tool for others. Not a bad workman by my definition.
And his suggestions of improving the UI sound very solid. Also I am not sure, if you got the part, where he pointed out, that Github themself made the same misstake for one if their repos. Sure, sure, all bad workman.
It is a workman, who builds a very succesful tool for others. Not a bad workman by my definition.
And his suggestions of improving the UI sound very solid. Also I am not sure, if you got the part, where he pointed out, that Github themself made the same misstake for one if their repos. Sure, sure, all bad workman.
Maybe the UX is not great, but surely having to type "httpie/httpie" would have given me a pause.
Regardless, to make mistakes is human. What I don't really like is how the author starts attacking Github and Microsoft, just because they can't afford to fix the author's mistake. A huge red flag for me.
Regardless, to make mistakes is human. What I don't really like is how the author starts attacking Github and Microsoft, just because they can't afford to fix the author's mistake. A huge red flag for me.
Once you do it a few times, writing the repo names means nothing. You have to do it on your repo with 0 followers just making it public. It’s not very notable unless you’re new to Github.
My advice is for Github to tell you that you’re losing 53,000 stars (not just “all your stars”) to help knock you out of autopilot.
I don’t get the finger pointing though. Obviously they messed up, it’s the entire post. But it’s also a good moment to reflect on how UX can be used to prevent people from messing up.
My advice is for Github to tell you that you’re losing 53,000 stars (not just “all your stars”) to help knock you out of autopilot.
I don’t get the finger pointing though. Obviously they messed up, it’s the entire post. But it’s also a good moment to reflect on how UX can be used to prevent people from messing up.
What should the threshold be? 53,000 stars? 50,000 stars? 25,000? 100? No matter what number you pick, there will be someone with fewer stars who considers their stars important enough to merit a warning.
Unless you set the threshold to 1, in which case it's just more meaningless noise, like the repository name (apparently) is.
Unless you set the threshold to 1, in which case it's just more meaningless noise, like the repository name (apparently) is.
Always show the number if it's more than 0. It's more informative and might catch your attention better than "something bad might happen"
They didn't say so, but 100% they copy-pasted the name from the prompt. I always do. They didn't type manually it in a way that would help them catch the error. That's a big reason that "enter this thing: ______" isn't foolproof. Perhaps it should at least be made unselectable.
> “A bad workman always blames his tools.”
That's a meaningless statement, though, as it can always be used against anyone complaining about something. I mean, you yourself wrote this the other day:
> I had to work with SAP Hybris a year or two ago. My IDE was not smart enough. Well actually I spent a good number of days trying to configure my IDE to be able to work properly with Hybris. I failed. What a mess
Are you a bad workman blaming your tools? Or do some tools just genuinely have faults?
That's a meaningless statement, though, as it can always be used against anyone complaining about something. I mean, you yourself wrote this the other day:
> I had to work with SAP Hybris a year or two ago. My IDE was not smart enough. Well actually I spent a good number of days trying to configure my IDE to be able to work properly with Hybris. I failed. What a mess
Are you a bad workman blaming your tools? Or do some tools just genuinely have faults?
Completely disagree; when it comes to programming (where all tools are infinitely malleable), it’s a poor programmer who puts up with suboptimal tools.
I don't think he's blaming HN to the point where he's shirking responsibility for what he did. I read this post as a clever way to get play on HN which will help him get some of his stars/watchers back.
Couldn't agree more. The author not only messes up his own repo while blaming the GitHub UI, he proceeds to then whine that GitHub employees won't restore his data from a backup.
But the point he makes, is that Github made the same misstake - and for themself they could restore it.
If it's a mistake that even a GitHub employee can make with very heavy consequences, is that entirely the fault of the author?
When Lauda Air Flight 004 crashed because the pilots accidentally deployed the reverse thrusters in air, even though it was the pilot who "made a mistake", Boeing was forced to change their design and now the original design is considered flawed.
When Lauda Air Flight 004 crashed because the pilots accidentally deployed the reverse thrusters in air, even though it was the pilot who "made a mistake", Boeing was forced to change their design and now the original design is considered flawed.
Additional context: a GitHub employee addresses why they didn't do a backup restore in this tweet:
> Yup, all watchers go when you go private and a bunch of notification settings etc. We've tried re-staring projects in the past etc but that ends up breaking lots of peoples notification settings. It's something we should make more reversible but hard for reasons <waveshand>
> It's the reason we display this when you try to do it. But a better fix would be for us to make it more easily reversible in the future.
https://twitter.com/martinwoodward/status/149333649025189478...
> Yup, all watchers go when you go private and a bunch of notification settings etc. We've tried re-staring projects in the past etc but that ends up breaking lots of peoples notification settings. It's something we should make more reversible but hard for reasons <waveshand>
> It's the reason we display this when you try to do it. But a better fix would be for us to make it more easily reversible in the future.
https://twitter.com/martinwoodward/status/149333649025189478...
That's one of the exact phrases you don't want to hear from a tech department.
They make tech excuses which were ultimately their own design and tell that's not possible to be fixed.
They make tech excuses which were ultimately their own design and tell that's not possible to be fixed.
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
I read it.
I think there should be a follow-on discussion here about programming paradigm that empowers a "do what I mean not what I say" mentality.
Atlassian's recent fiasco https://www.atlassian.com/engineering/april-2022-outage-upda... 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 "gotcha" up through Product Management to expose controls for such a risky scenario.
I think there should be a follow-on discussion here about programming paradigm that empowers a "do what I mean not what I say" mentality.
Atlassian's recent fiasco https://www.atlassian.com/engineering/april-2022-outage-upda... 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 "gotcha" up through Product Management to expose controls for such a risky scenario.
Why care? Stars don't mean anything, save for the few people who organise the software they use by starring it.
Certainly it's not a community owned by the maintainers. I don't own a connection with the people that upvoted this post, and stars mean exactly the same (effectively nothing).
Certainly it's not a community owned by the maintainers. I don't own a connection with the people that upvoted this post, and stars mean exactly the same (effectively nothing).
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.
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.
>GitHub, by design, seeks to be as much of a social network
This is so true - not sure why it isn't getting talked about more - they even have a feed now [which is getting better every few days]
This is so true - not sure why it isn't getting talked about more - they even have a feed now [which is getting better every few days]
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.
The real problem is: Why are GitHub stars so important if httpie is so great?
Because people cannot judge for themselves if something is great or not, they always need proxies. It would be cool if we could somehow fix THAT.
Because people cannot judge for themselves if something is great or not, they always need proxies. It would be cool if we could somehow fix THAT.
Any recommendations?
Not really. Money seems to be a universal proxy. I guess we need to acknowledge that 54k GitHub stars has some sort of monetary value (Web3 anyone?), and then it would be obvious that you couldn't just delete it, because who would want to just delete money?
He said "somehow". I think he also believes there isn't an alternative.
Well, it is at the top of Hacker News. If everyone just goes to https://github.com/httpie/httpie and stars it again - we'll fix it in a jiffy!
As the article noted, that absolutely would not fix the underlying problem at all.
What an astonishingly poor design decision by GitHub. The intelligent design decision to making a repository private is to have private be a flag, and to have that privacy setting propagate down to the watcher level. Then, when a repository is made public again, all the watchers etc return.
Want to give users a way to remove all watchers? Great, make that /a separate action/ -- in no world and in no other application is it an intuitive UI/UX pattern to have make something private mean it gets deleted. That's absurd. Make private means "hidden for the indefinite future, but available to be made unhidden when I as a user see fit." That is the only reasonable definition I have ever seen (Instagram for example).
Whether you want to show a user that they watched a repository which is no longer public or simply have it disappear is up to the user, but I cannot understand why anyone thought that the straightforward solution was to /simply delete the data/. Between this and the now common downtime, I'm increasingly worried that GitHub is simply asleep at the wheel.
Want to give users a way to remove all watchers? Great, make that /a separate action/ -- in no world and in no other application is it an intuitive UI/UX pattern to have make something private mean it gets deleted. That's absurd. Make private means "hidden for the indefinite future, but available to be made unhidden when I as a user see fit." That is the only reasonable definition I have ever seen (Instagram for example).
Whether you want to show a user that they watched a repository which is no longer public or simply have it disappear is up to the user, but I cannot understand why anyone thought that the straightforward solution was to /simply delete the data/. Between this and the now common downtime, I'm increasingly worried that GitHub is simply asleep at the wheel.
DevRel 101. If a project had 54k stars and they obviously made a mistake why take the chance of them writing a blog post and having it hit the front page on HN?
If Nat was still CEO this wouldn't have been a thing.
If Nat was still CEO this wouldn't have been a thing.
Github stars are such a weird metric/thing. There are a lot of reasons i write open source code, but randoms on the internet who might not have even have used your project "liking" it, is not one of them.
That's not to say recognition isn't a motivator, it is. Github stars just seem like a really poor proxy for recognition.
That's not to say recognition isn't a motivator, it is. Github stars just seem like a really poor proxy for recognition.
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?
More seriously, why do they matter? Is it a prestige thing only or are there practical consequences to losing the stars?
(Whether it's a good idea or not,) people often use stars as a quick-and-dirty proxy for "is this repo reasonably well trusted?" and "how big is the community for this project?". All else being equal, many people would default to using a repo with 20,000 stars over a repo with 20.
As a junior developer, GitHub star was one of the most important metric when I am choosing library/software.
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's also an important indicator of community size and authenticity, important factors in the decision to use the code.
It's also an important indicator of community size and authenticity, important factors in the decision to use the code.
> silently
I’d argue that GitHub should send them a notification that the repo they starred has been made private.
I’d argue that GitHub should send them a notification that the repo they starred has been made private.
And another that it was made public again. Or neither, and just not delete shit that there was no need to delete.
My point is that IF they delete everything, they should send a notification to the affected users. When the repository is made public again, then since they deleted the star relation it’s not possible to send another notification.
Unless, of course, if they just changed the column setting from "starred" to "was starred". As they could do. If they cared.
The user said "delete this stuff". GitHub asked, "Are your sure?" User: "Yes".
Seems like a good reason to delete it.
Seems like a good reason to delete it.
No. The user said, "make it private". That has nothing to do with deleting anything.
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 stars
Does 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'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.
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 stars
Does 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'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.
I sometimes decide what to use based on number of stars. It'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'd consider using an alternative with 10k stars if there's any.
Now httpie is on 2.5k stars and if I only knew about it today, I'd consider using an alternative with 10k stars if there's any.
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.
Do people use GitHub stars for something? Sometimes I star things but I have no idea what it does or why I do it.
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?
“They’re not stars, they’re a community!” What percentage of your community actively contributes bugfixes?
It’s basically just a bookmark for yourself. And GitHub shows how many users have “bookmarked” a particular repository.
This reminds me of an app of mine that was a top 20 paid app 8+ years ago in the Apple app store. To try and gain more users, I decided I'd try a little test and make the app free for a short amount of time. What I did not realize was that changing the app from paid to free would completely remove my app from the top 20 charts and the free app ended up at the bottom of the free charts.
The app gained positions pretty fast in the free charts, but it never got close to what it was before. Biggest mistake I could have made in hindsight and there was nothing I could do about it. This was my first app in the app store, so I hand no experience with how things worked.
The app gained positions pretty fast in the free charts, but it never got close to what it was before. Biggest mistake I could have made in hindsight and there was nothing I could do about it. This was my first app in the app store, so I hand no experience with how things worked.
I’ll admit I didn’t read the whole thing but this sound like hyperbole
> And GitHub cascade-deleted our community that took 10 years to build.
How does losing stars equate to losing the community? Won’t actual fans be right back using and contributing?
If you remove a contributor of a private github repo it deletes their remote fork and all of their remote branches. To me that’s real loss.
> And GitHub cascade-deleted our community that took 10 years to build.
How does losing stars equate to losing the community? Won’t actual fans be right back using and contributing?
If you remove a contributor of a private github repo it deletes their remote fork and all of their remote branches. To me that’s real loss.
> Won’t actual fans be right back using and contributing?
Yes, but if "actual" fans are <1% of your existing user base then your reach and ranking is still far below what it used to be. I'm sure most people on GH don't even remember what repos they've starred, and httpie may be one of just thousands, of which many will disappear from their starred repos overnight without them even noticing.
Yes, but if "actual" fans are <1% of your existing user base then your reach and ranking is still far below what it used to be. I'm sure most people on GH don't even remember what repos they've starred, and httpie may be one of just thousands, of which many will disappear from their starred repos overnight without them even noticing.
If a user didn't care enough about the project to even remember that they starred it, why is that star being lost a problem? It was already the case that nobody was getting any value out of it.
Heavily reminds me of this RubyConf talk: https://rc-temp000-videos.s3.us-west-1.amazonaws.com/Laura-M...
One of the core bits of the talk is about the sort of messages our automated systems give us, and whether they're sufficient, or woefully lacking - which is what the linked article is also talking about, when it talks about how the "warning: about to burn down a house" doesn't tell if anyone's in that house.
One of the core bits of the talk is about the sort of messages our automated systems give us, and whether they're sufficient, or woefully lacking - which is what the linked article is also talking about, when it talks about how the "warning: about to burn down a house" doesn't tell if anyone's in that house.
I agree with the UI stuff and soft deletes. It was a lesson I learned about 7 years ago when I had users make some tragic mistakes in a system I made. “Are you sure?” doesn’t do anything more than a hand wave CYA. Showing the consequences does.
But then this starts sounding like a guy who went to the same bank for 30 years, knows the tellers, and doesn’t understand why they won’t give him a small business loan.
If you started a company, rely on GitHub for core infrastructure, why would you not pay for it? And if you did this, why would you expect them to do support outside of self-service? Open Source doesn’t mean charity-worthy anymore. Most “successful” projects are either spun out of or spearheaded by a business these days. And it’s not like GitHub is rolling in profit. Their enterprise offering is just starting to get traction under MS.
I think the complaints would be more valid if they were outside of the norms in this space. GitHub + MS is still 1000x less shady than Sourceforge. I don’t think you’d see different behavior from GitLab et al.
To the real politik-like view: this experience won’t make you (or many others) move elsewhere or pay for the service. So it’s ultimately a 0 consequence situation outside of a blog post and some community discussion.
I’m general, I don’t love pieces of software or companies. I’ll wear free t-shirts to mow the lawn, not with pride. I don’t love GitHub, but I dislike it less than the alternatives, partly because it’s just the easiest. I think most are in that camp. Oktocat lost his street cred long ago.
But then this starts sounding like a guy who went to the same bank for 30 years, knows the tellers, and doesn’t understand why they won’t give him a small business loan.
If you started a company, rely on GitHub for core infrastructure, why would you not pay for it? And if you did this, why would you expect them to do support outside of self-service? Open Source doesn’t mean charity-worthy anymore. Most “successful” projects are either spun out of or spearheaded by a business these days. And it’s not like GitHub is rolling in profit. Their enterprise offering is just starting to get traction under MS.
I think the complaints would be more valid if they were outside of the norms in this space. GitHub + MS is still 1000x less shady than Sourceforge. I don’t think you’d see different behavior from GitLab et al.
To the real politik-like view: this experience won’t make you (or many others) move elsewhere or pay for the service. So it’s ultimately a 0 consequence situation outside of a blog post and some community discussion.
I’m general, I don’t love pieces of software or companies. I’ll wear free t-shirts to mow the lawn, not with pride. I don’t love GitHub, but I dislike it less than the alternatives, partly because it’s just the easiest. I think most are in that camp. Oktocat lost his street cred long ago.
I find it ironic that some people are blaming the author so bad given that Github has made the same mistake in the past and had to restore it from the backup, making it clear that the UX could be better.
I get it, we should all be very cautious when doing destructive actions, but it's also specially easy to be confused by github's repository naming conventions and you're not seeing the actual repository you're making private, just it's name.
I get it, we should all be very cautious when doing destructive actions, but it's also specially easy to be confused by github's repository naming conventions and you're not seeing the actual repository you're making private, just it's name.
I find it ironic that you can't reverse a mistake on a site dedicated to a software that is all about reversing mistakes.
I would have had more sympathy for the author if they explained why they care so much about github stars. It's just internet points after all. At the very end, they say "What started as a side project has recently become a company" so if it's all about business, maybe they could have made that more prominent.
EDIT: sorry, not meant to be harsh. Hopefully you get what you want and thank you for writing open source software
There are also notifications and more. It’s about loosing the community enabled by the social features of github.
Okay. I just went in and double checked.
600+ comments bashing Github for not having prevented this action. Meanwhile, Github:
1) has this action in the "danger zone", literally the only UI element using RED COLOR; 2) has a warning banner on the dialog box that pops up when you click that button; 3) requires you to type in the name of the repository (which everyone copies and pastes anyway because they don’t get the point of this exercise)
So when you have all those things in place and still fly past all the defenses on an autopilot, you're not that bright to begin with and you should only blame yourself.
Meanwhile, there are 600 comments bashing Github for not putting in undo, or somesuch. The problem is, though, that this kind of carelessness that led to the repository losing its social stats doesn't stay with computers. It may very well carry over to other aspects of life, because an attitude is something ingrained way deeper than just using one computer program.
And then we have Youtube brimming with compilations of how cars don't stand a chance with trains. You would think that: 0) unambiguous warning road signs 1) red blinking lights 2) ringing bells 3) the train itself honking its horn for a couple miles before even approaching the crossing should be enough warning for the driver to move his/her ass off the track, and yet here we are.
So, yep, we may need to have better systems here and there, but being careful where it says "danger" should be a part of basic fucking competence at whatever it is you do. There are, shockingly, areas in life where an undo button doesn't exist. No, the fact that the other side didn't put safeguards in is not an excuse.
600+ comments bashing Github for not having prevented this action. Meanwhile, Github:
1) has this action in the "danger zone", literally the only UI element using RED COLOR; 2) has a warning banner on the dialog box that pops up when you click that button; 3) requires you to type in the name of the repository (which everyone copies and pastes anyway because they don’t get the point of this exercise)
So when you have all those things in place and still fly past all the defenses on an autopilot, you're not that bright to begin with and you should only blame yourself.
Meanwhile, there are 600 comments bashing Github for not putting in undo, or somesuch. The problem is, though, that this kind of carelessness that led to the repository losing its social stats doesn't stay with computers. It may very well carry over to other aspects of life, because an attitude is something ingrained way deeper than just using one computer program.
And then we have Youtube brimming with compilations of how cars don't stand a chance with trains. You would think that: 0) unambiguous warning road signs 1) red blinking lights 2) ringing bells 3) the train itself honking its horn for a couple miles before even approaching the crossing should be enough warning for the driver to move his/her ass off the track, and yet here we are.
So, yep, we may need to have better systems here and there, but being careful where it says "danger" should be a part of basic fucking competence at whatever it is you do. There are, shockingly, areas in life where an undo button doesn't exist. No, the fact that the other side didn't put safeguards in is not an excuse.
I'd recommend reading the actual post carefully before claiming to having double checked anything and then going on judging using harsh language. You completely missed the 54k stars question presented and the context in which it was presented to the op.
Oh for god’s sake, cry me a river. Boo freaking hoo.
You go to the danger zone, you fucking stop and think, and you read the alerts, and make sure you understand what they actually say. Then you proceed, maybe. Like an adult. Next time, what, they’re going to mistake deleting a repository with changing its visibility?
If httpie is that good, they should be able to regrow their stars in no time. What a first-world problem to have indeed.
You go to the danger zone, you fucking stop and think, and you read the alerts, and make sure you understand what they actually say. Then you proceed, maybe. Like an adult. Next time, what, they’re going to mistake deleting a repository with changing its visibility?
If httpie is that good, they should be able to regrow their stars in no time. What a first-world problem to have indeed.
Where did you find those §600+ comments bashing Github for not having prevented this action"?
Of the 600+ comments here, the vast vast majority is contemplating how github could improve it’s UI and UX so that nobody loses a star ever again.
This is laziness on GitHub.
If your client asks you for work and you get lazy because it needs some internal modification that could take a day instead of an hour, you just respond it's impossible.
Generally that's quite unacceptable especially when they already know about the situation from previous incidents and obviously human errors could happen again and the fact they did restore for their own project doesn't make it look any better.
If your client asks you for work and you get lazy because it needs some internal modification that could take a day instead of an hour, you just respond it's impossible.
Generally that's quite unacceptable especially when they already know about the situation from previous incidents and obviously human errors could happen again and the fact they did restore for their own project doesn't make it look any better.
The author is not a client but a user. He doesn't pay GitHub, and is certainly not entitled to having a day of internal engineering workforce (costing in the tens of thousands of $) fixing his mistakes.
>There’s a confirmation box. It’s designed to stop users in a situation like mine from doing something stupid. It tells you that “You will permanently lose all stars and watchers of this repository.” That’s pretty scary.
>The problem is that the box looks exactly the same for repos with no commits and stars and for repos with a decade-long history and 55k stargazers and watchers. And it says “Warning: this is a potentially destructive action.”
>To paraphrase, the box tells you “You’re about to demolish a house. If there are any people inside, they will all die”.
>But it doesn’t include anything specific to break you out of your auto-pilot mode if you’ve confused the address and think you’re looking at an empty house.
just admit that you fucked up and don't look for someone else to blame. people would respect you more for it
>The problem is that the box looks exactly the same for repos with no commits and stars and for repos with a decade-long history and 55k stargazers and watchers. And it says “Warning: this is a potentially destructive action.”
>To paraphrase, the box tells you “You’re about to demolish a house. If there are any people inside, they will all die”.
>But it doesn’t include anything specific to break you out of your auto-pilot mode if you’ve confused the address and think you’re looking at an empty house.
just admit that you fucked up and don't look for someone else to blame. people would respect you more for it
They did admit they fucked up. Then they tried to make the best of it by looking for possible ways of preventing other people from repeating their mistake.
What did you want? A blog post that says "I suck, I'm a failure, thanks for reading"? Why is this your response to someone trying to be contructive while post-morteming a failure?
What did you want? A blog post that says "I suck, I'm a failure, thanks for reading"? Why is this your response to someone trying to be contructive while post-morteming a failure?
the guy with 10+ experience of using github went to the "danger zone", pressed the red button, saw the very, very, very explicit warning about the consequences of pressing it and confirmed the action by explicitly typing the exact name of the repository.
yes, that blog post would've been apt. as constructive as it gets.
>Why is this your response
because I don't want to send a notarized request every time I need to delete a folder, format a disk or submit a SQL query
yes, that blog post would've been apt. as constructive as it gets.
>Why is this your response
because I don't want to send a notarized request every time I need to delete a folder, format a disk or submit a SQL query
> because I don't want to send a notarized request every time I need to delete a folder, format a disk or submit a SQL query
Aah yes, the only 2 extreme options, no/minimal warnings and extreme warnings. "Who needs rationality or subtlety on the internet anyway?"
Aah yes, the only 2 extreme options, no/minimal warnings and extreme warnings. "Who needs rationality or subtlety on the internet anyway?"
This response would get you laughed out of the medical software industry (but welcomed with open arms by CMIOs and hospital administration). Physicians are known to click through all kinds of red-flag warnings because the legal team insisted they all be turned on to maximize patient safety.
Admiring that you screwed up is one thing, but action items coming out of it should prevent somebody else from screwing up in a similar way.
One typical way is to add a confusing confirmation box, where saying yes leaves things as is, but "I want to demolish the house" is in a different location that the typical yes/no buttons
One typical way is to add a confusing confirmation box, where saying yes leaves things as is, but "I want to demolish the house" is in a different location that the typical yes/no buttons
They admitted exactly what they did. This experience is still really bad UX IMO.
There's so much focus on the UX here to alert you to a destructive action, but I haven't seen anyone mention this: why does Github even delete stars, and why on earth is it permanent?
It seems like a temporary UX hack put in place because some tricky implementation detail handling stars on private repos. Like they said "we'll fix that later" and then the warning message stayed.
In a well designed system, making a repo public/private would be a switch where full state is retained back and forth.
I mean, it's kinda hypothetical but stars aren't even completely useless in a private repo (for a sufficiently large set of users with access).
I'd go further and say that even the UX around the destructive act of deleting a repo shouldn't be necessary: that seems undo-able. Overwriting would still need a warning (creating a repo in a namespace that previously contained data) as would anything involving losing access (deleting an org, freeing it up to the community at large), but not needing it for repo deletion-a relatively common action-would go a long way toward reducing "autopilot".
It seems like a temporary UX hack put in place because some tricky implementation detail handling stars on private repos. Like they said "we'll fix that later" and then the warning message stayed.
In a well designed system, making a repo public/private would be a switch where full state is retained back and forth.
I mean, it's kinda hypothetical but stars aren't even completely useless in a private repo (for a sufficiently large set of users with access).
I'd go further and say that even the UX around the destructive act of deleting a repo shouldn't be necessary: that seems undo-able. Overwriting would still need a warning (creating a repo in a namespace that previously contained data) as would anything involving losing access (deleting an org, freeing it up to the community at large), but not needing it for repo deletion-a relatively common action-would go a long way toward reducing "autopilot".
> The tone of our decade-long mutually-beneficial relationship is set by GitHub’s Terms of Service. Thinking there was more to it was naive.
I really want to support that kind of sentiment. In fact, I want to support it every time I get a chance. That's just how I am. I enjoy people hating on Microsoft and such. I may even provoke it when it's not entirely justified.
But to be fair, making a twitter post about "some random project we host fucked up a bit, let's help them to get followers back" does seem to qualify as something "more to it". I'm pretty sure they weren't legally obliged to do that as well. And I'm pretty sure ads on github's official twitter aren't cheap either.
(But I do find that "not legally obliged" tone extremely insulting in any kind of relationships too. I myself also tend to get all "oh, so that's how you want to talk?" over that. I guess, I hate lawyers as much as I hate Microsoft. After all, they are essentially the same thing.)
I really want to support that kind of sentiment. In fact, I want to support it every time I get a chance. That's just how I am. I enjoy people hating on Microsoft and such. I may even provoke it when it's not entirely justified.
But to be fair, making a twitter post about "some random project we host fucked up a bit, let's help them to get followers back" does seem to qualify as something "more to it". I'm pretty sure they weren't legally obliged to do that as well. And I'm pretty sure ads on github's official twitter aren't cheap either.
(But I do find that "not legally obliged" tone extremely insulting in any kind of relationships too. I myself also tend to get all "oh, so that's how you want to talk?" over that. I guess, I hate lawyers as much as I hate Microsoft. After all, they are essentially the same thing.)
> We even offered GitHub financial compensation for any resources required
What? Can anyone explain this? Are people so desperate about github stars these days that they’re willing to pay Microsoft for them?
What? Can anyone explain this? Are people so desperate about github stars these days that they’re willing to pay Microsoft for them?
I think people here are underestimating how difficult it is to implement is_deleted in a production system. Literally EVERY query has to be rewritten to reflect the new database schema. If it's not been implemented from the start then you have a considerable re-write, and usually this type of project will not be revenue generating.
Not necessarily. In some ORMs you can have scopes that can be used to append common sub-queries or conditions, such as "WHERE is_deleted=0", and some allow you to specify default scopes that should be appended to every database query (unless explicitly switched off).
I'm just saying: It doesn't need to be a considerable rewrite, it really depends on how your ORM or data layer is implemented.
I'm just saying: It doesn't need to be a considerable rewrite, it really depends on how your ORM or data layer is implemented.
Murphy'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! =)
This is a well-written blog post describing a real issue with GitHub's privacy mechanism.
But it is also a little silly for the blog post to show graphs extrapolating the hypothetical number of GitHub stars several years into the future. Their graphs' X-axis goes up to 2028.
But it is also a little silly for the blog post to show graphs extrapolating the hypothetical number of GitHub stars several years into the future. Their graphs' X-axis goes up to 2028.
I think there are two types of destructive actions; destructive actions you do as a part of completing some other task, and destructive actions you do for compliance reasons.
I think the problem arises when product designers aren't sure which case their data deletion function is for.
If you dumped a bunch of social security numbers in your non-confidential data history and batch job system, you'd want to be able to permanently delete it as part of the incident response, to reduce the number of people that are exposed to data they shouldn't have access to.
But if you delete some lines of code from your text editor, they can just pop back into existence with the press of a key because you were probably just moving them around, or trying some buggy function without a piece of code you thought might be unnecessary to isolating the defect, etc. Editors clearly understand that you don't kill text out of an Emacs buffer to solve a compliance issue, so they keep it around even though you technically asked for it to be deleted. (Imagine how crazy it would be if deleting text in your editor deleted it from memory, the clipboard, version control, and your upstream VC server!)
In the case of this Github issue, there was clearly a fundamental misunderstanding. Github probably imagined the feature as a compliance type thing; get this stuff off the Internet as fast as possible at any cost necessary. Delete the list of people that even knew this thing existed! I could see why someone might want that. But what the user thought was that this was something they needed to do along the way to some other goal.
I have a feeling that people pick the compliance route more often than the "experimentation" route more often than not, not because they expect users to have actual compliance-type issues, but simply because it's easier. The net result is that users are trained to fear computers and fear experimentation, and that's a bad state we've put society in. This article is yet another victim of "if they said they were sure they wanted to delete it, we can just delete it". But it's actually pretty rare that people are sure.
I think the problem arises when product designers aren't sure which case their data deletion function is for.
If you dumped a bunch of social security numbers in your non-confidential data history and batch job system, you'd want to be able to permanently delete it as part of the incident response, to reduce the number of people that are exposed to data they shouldn't have access to.
But if you delete some lines of code from your text editor, they can just pop back into existence with the press of a key because you were probably just moving them around, or trying some buggy function without a piece of code you thought might be unnecessary to isolating the defect, etc. Editors clearly understand that you don't kill text out of an Emacs buffer to solve a compliance issue, so they keep it around even though you technically asked for it to be deleted. (Imagine how crazy it would be if deleting text in your editor deleted it from memory, the clipboard, version control, and your upstream VC server!)
In the case of this Github issue, there was clearly a fundamental misunderstanding. Github probably imagined the feature as a compliance type thing; get this stuff off the Internet as fast as possible at any cost necessary. Delete the list of people that even knew this thing existed! I could see why someone might want that. But what the user thought was that this was something they needed to do along the way to some other goal.
I have a feeling that people pick the compliance route more often than the "experimentation" route more often than not, not because they expect users to have actual compliance-type issues, but simply because it's easier. The net result is that users are trained to fear computers and fear experimentation, and that's a bad state we've put society in. This article is yet another victim of "if they said they were sure they wanted to delete it, we can just delete it". But it's actually pretty rare that people are sure.
GitHub became more a social platform rather than just a code repository and it let you build up a community - I can't argue with that. But it's a large commercial company that doesn't really care about you. Now, when it's microsoft, more so than ever. I'd never trust my data to a company like that. Last time I trusted Google I lost all (decade worth of) email. I worked in a company that WOULD sometimes make devs manually scrap user data from the database when it was our fault or users were somewhat important, but that's more like exception to the rule.
I sympathize with you. I think it is best policy they do not give you back the stars, because I can see a wave of potential misuse which could also open up vulnerabilities exploiting this practice. Does anyone use "stars" as some form of credibility to the project in terms of security?
Given your reputation, I find you will get back your stars again and maybe even higher than before. Or, at least, it shouldn't be that hard :).
With that said, I am glad to have come across this site. Sure seems to beat postman :)
Given your reputation, I find you will get back your stars again and maybe even higher than before. Or, at least, it shouldn't be that hard :).
With that said, I am glad to have come across this site. Sure seems to beat postman :)
30 minutes seems like a weirdly long time to delete 54,000 rows; doing something in SQLite like
It also seems weird that it would be necessary to delete those rows at all; yeah, having stars for private repos is kinda pointless, but other than taking up space it doesn't seem like it'd do much harm, either. If the space taken up is really that much of a concern, then a periodic cleanup job along the lines of
CREATE TABLE stars (id INTEGER PRIMARY KEY, user TEXT, repo TEXT);
INSERT INTO stars SELECT
value AS id,
'User ' || value AS user,
'foo' AS repo
FROM generate_series(0,53999);
SELECT * FROM stars;
DELETE FROM stars WHERE repo = 'foo';
It also seems weird that it would be necessary to delete those rows at all; yeah, having stars for private repos is kinda pointless, but other than taking up space it doesn't seem like it'd do much harm, either. If the space taken up is really that much of a concern, then a periodic cleanup job along the lines of
DELETE stars FROM stars JOIN repos ON
stars.repo_id = repos.id
WHERE
repos.visibility = 'private';
GitHub doesn't use foreign keys[1], and there's likely many tables related to all the users, notifications, permissions, etc... that would need to be cleaned up. Without foreign keys they likely have some system process that does this instead of a simple `DELETE FROM` which cascades.
1. https://github.com/github/gh-ost/issues/331#issuecomment-266...
1. https://github.com/github/gh-ost/issues/331#issuecomment-266...
Is focusing on github stars specially meaningful ? Is there any functional difference for the repo between having 6k stars (as of today) and 54k ? I don't think so honestly.
Github stars are just not something useful to monitor closely. I had a look at my starred repos on github, 95% of those I have no idea what it is anymore anyway.
So yeah, github didn't do any extra effort to restore what's imo essentially a vanity metric. Makes sense to me ?
So yeah, github didn't do any extra effort to restore what's imo essentially a vanity metric. Makes sense to me ?
I agree that it would be more clear if the visibility-change dialog included some stats about the repo so you can confirm at a glance that it's the right one, but... it asks you to type the full name of the repo before it will allow you to proceed.
If you do a copy-paste of what it tells you to type, that's on you. The entire point of that box is to get you to think about what you are doing, and explicitly type out the name of the thing you want to change.
Perhaps I've interacted with GitHub's UX enough to be familiar, but when OP put up a side-by-side screenshot and asked, "A 54k-star question: Which one of these two dialogs is safe to confirm and which one deletes a 10-year-old community?" ... I looked at the two boxes, saw the repo it was asking to modify in both cases, and immediately knew the correct answer!
I get that the ideal is that every person who takes any kind of action knows what they are doing and never makes a mistake. I don't know if it's realistic to expect that outcome, but certainly that's the ideal. But how far should UX designers bend over backwards to cater to people who perform destructive actions without paying attention to what they're doing?
If you do a copy-paste of what it tells you to type, that's on you. The entire point of that box is to get you to think about what you are doing, and explicitly type out the name of the thing you want to change.
Perhaps I've interacted with GitHub's UX enough to be familiar, but when OP put up a side-by-side screenshot and asked, "A 54k-star question: Which one of these two dialogs is safe to confirm and which one deletes a 10-year-old community?" ... I looked at the two boxes, saw the repo it was asking to modify in both cases, and immediately knew the correct answer!
I get that the ideal is that every person who takes any kind of action knows what they are doing and never makes a mistake. I don't know if it's realistic to expect that outcome, but certainly that's the ideal. But how far should UX designers bend over backwards to cater to people who perform destructive actions without paying attention to what they're doing?
I just starred HTTPIE again.
I feel their pain and while I don't claim to be perfect, this was was self-inflicted as it was clearly stated in Github dialog warning:
"You will permanently loose all stars and watchers of this repository"
Please don't blame Github for EndUser fault. People are click-happy and don't read. I'm happy they're able to restore their reputation and followers, not because of pity but because their product value and reputation.
Congrats HTTPIE!
I feel their pain and while I don't claim to be perfect, this was was self-inflicted as it was clearly stated in Github dialog warning:
"You will permanently loose all stars and watchers of this repository"
Please don't blame Github for EndUser fault. People are click-happy and don't read. I'm happy they're able to restore their reputation and followers, not because of pity but because their product value and reputation.
Congrats HTTPIE!
eh, github kinda sucks.
they should fix this, or at least pull username lists for stars/follows and give them to the user for followup.
if the user self hosted, they'd pull from their own backups. instead they trusted a third party and helped contribute to that third party's success. now it's that very success that the user contributed to that stands in the way of help resolving the user's problem.
shrugging and saying sorry is kinda pathetic.
they should fix this, or at least pull username lists for stars/follows and give them to the user for followup.
if the user self hosted, they'd pull from their own backups. instead they trusted a third party and helped contribute to that third party's success. now it's that very success that the user contributed to that stands in the way of help resolving the user's problem.
shrugging and saying sorry is kinda pathetic.
The author shows admirable restraint in characterizing Microsoft's response
I feel your pain. I have dropped from 250 to zero for exact same reason ;) The order of magnitude is for sure different, but still, hitting the ground without any warning was a surprise.
A workaround here is to:
- leave the repo public - move it somewhere else (to private repo) - reinit original repo with empty content - once ready, bring back the old repo to previous remote
This way your stars are preserved.
A workaround here is to:
- leave the repo public - move it somewhere else (to private repo) - reinit original repo with empty content - once ready, bring back the old repo to previous remote
This way your stars are preserved.
Why do they even delete those stars?
When the repo goes private, people who can’t see it any more can’t have it in their list of starred repos.
Why not?
I think the respectful solution is to show it as "you starred X, it's private now, you can unstar if you like" (make sure if the name changes privately then the new name isn't shown).
Such a solution is not only good in the case of mistakes like this, it also doesn't gaslight the person that starred a repo only for it to disappear from their list.
I think the respectful solution is to show it as "you starred X, it's private now, you can unstar if you like" (make sure if the name changes privately then the new name isn't shown).
Such a solution is not only good in the case of mistakes like this, it also doesn't gaslight the person that starred a repo only for it to disappear from their list.
> it also doesn't gaslight the person that starred a repo only for it to disappear from their list.
It's honestly hilarious how the definition of 'gaslight' has expanded so dramatically in the past few years that it now means 'anything that confuses me'.
For future reference, here's what it actually means [1]:
> Psychological manipulation of a person usually over an extended period of time that causes the victim to question the validity of their own thoughts, perception of reality, or memories and typically leads to confusion, loss of confidence and self-esteem, uncertainty of one's emotional or mental stability, and a dependency on the perpetrator
Github did none of those things to you.
[1] https://www.merriam-webster.com/dictionary/gaslighting
It's honestly hilarious how the definition of 'gaslight' has expanded so dramatically in the past few years that it now means 'anything that confuses me'.
For future reference, here's what it actually means [1]:
> Psychological manipulation of a person usually over an extended period of time that causes the victim to question the validity of their own thoughts, perception of reality, or memories and typically leads to confusion, loss of confidence and self-esteem, uncertainty of one's emotional or mental stability, and a dependency on the perpetrator
Github did none of those things to you.
[1] https://www.merriam-webster.com/dictionary/gaslighting
Removing something from my personal bookmark list, with no notification, does in fact lead me to question the validity of my own memories.
That fits just fine with simpler definitions like "To mislead someone such that they doubt their own memory, perceptions, or sanity."
It's an expansion from the original context but I don't think it's an unreasonable expansion.
That fits just fine with simpler definitions like "To mislead someone such that they doubt their own memory, perceptions, or sanity."
It's an expansion from the original context but I don't think it's an unreasonable expansion.
The origin of “gaslight” is a movie where a husband surreptitiously removes objects from the room, dims and brightens the lights, etc. and pretends the changes were just the wife’s imagination. https://en.wikipedia.org/wiki/Gaslight_(1944_film)#Plot
Removing bookmarks from someone’s list without notification seems at least broadly comparable (in both cases, the victim is confused and might question their own memory, because the state of the world changed in an incongruous way), though it is the action of an emotionless machine with a programming bug rather than a malicious human.
Removing bookmarks from someone’s list without notification seems at least broadly comparable (in both cases, the victim is confused and might question their own memory, because the state of the world changed in an incongruous way), though it is the action of an emotionless machine with a programming bug rather than a malicious human.
> albeit the action of an emotionless machine with a programming bug rather than a malicious human
Yes, if you remove a major part of the definition (intent) then it can fit whatever you want it to fit. Like Gino D'Acampo most famously said [1], if my grandmother had wheels, she would have been a bike.
[1]https://www.youtube.com/watch?v=A-RfHC91Ewc
Yes, if you remove a major part of the definition (intent) then it can fit whatever you want it to fit. Like Gino D'Acampo most famously said [1], if my grandmother had wheels, she would have been a bike.
[1]https://www.youtube.com/watch?v=A-RfHC91Ewc
I think it’s a fair use of the term. I’d maybe feel differently if there was a better term to use for “non-intentional gaslighting”, but afaik there isn’t really.
How about we coin a term today, "LEDlighting"? (Pronounced Led-Lighting).
"When a digital platform's state is altered in an opaque way without input on the user's behalf that directly commanded it to, and as a result causes them to question reality in the form of either their memory, the actual state of the system itself, or whether or not the system was intentionally made to do it by an unseen human."
Shadowbans, whether you think they're a good form of moderation or not, would be an example of LEDlighting.
In a game if the chat system stops working but the rest of the game works and everyone thinks they have been muted for some unknown infraction of the rules by an overreaching moderator, that's also LEDlighting.
"When a digital platform's state is altered in an opaque way without input on the user's behalf that directly commanded it to, and as a result causes them to question reality in the form of either their memory, the actual state of the system itself, or whether or not the system was intentionally made to do it by an unseen human."
Shadowbans, whether you think they're a good form of moderation or not, would be an example of LEDlighting.
In a game if the chat system stops working but the rest of the game works and everyone thinks they have been muted for some unknown infraction of the rules by an overreaching moderator, that's also LEDlighting.
[deleted]
This may be the most hilarious misuse of “gaslight” that I’ve ever seen.
If I publish something and you save the link and then I decide “nah, I don’t want that to be published”, I haven’t gaslit you.
If I publish something and you save the link and then I decide “nah, I don’t want that to be published”, I haven’t gaslit you.
I think you misunderstood.
If you remove the content, that's fine.
If you make the link itself disappear from where I saved it, that's gaslighting.
If you remove the content, that's fine.
If you make the link itself disappear from where I saved it, that's gaslighting.
Neither one of these is gaslighting.
Sure, to really count as "gaslighting" there has to be a deliberate attempt to make someone doubt their own sanity. I think we can rule out malicious intent in this case. However, when you save a link to something and then later come back to find the service acting like the link never even existed, as opposed to telling you that it was removed, that can feel pretty similar even if it's not intentional.
A user's list of starred repos shouldn't be silently abridged just because one of the repos was removed or made private. A placeholder should be left indicating that the repo was once starred but is currently unavailable.
This is something I always found annoying about Google Play Music also; when they removed a track from their service it would just silently disappear without a trace from your playlists, so unless you saved a copy of the list somewhere and compared them you might not even know to look for it elsewhere. You're just left vaguely wondering why that song never comes up in the shuffle any more. YT Music is a bit better about this—they generally leave a grayed-out placeholder. Sometimes the metadata is lacking but you can at least see where it was and know that a track was removed.
A user's list of starred repos shouldn't be silently abridged just because one of the repos was removed or made private. A placeholder should be left indicating that the repo was once starred but is currently unavailable.
This is something I always found annoying about Google Play Music also; when they removed a track from their service it would just silently disappear without a trace from your playlists, so unless you saved a copy of the list somewhere and compared them you might not even know to look for it elsewhere. You're just left vaguely wondering why that song never comes up in the shuffle any more. YT Music is a bit better about this—they generally leave a grayed-out placeholder. Sometimes the metadata is lacking but you can at least see where it was and know that a track was removed.
Or even make it so that those starrings that no longer have permissions to view the starred item just effectively don't exist because of data rules.
That's bad because it lies to users and you can't remove the star when it's in that state.
But if your star doesn't effectively exist why does that matter?
Because if the star is merely hidden then the repo can come back later. If you don't want any association with that repo any more, it's bad that it can put itself back into your starred list.
So mark the repo as private without their permission to view and have queries for starred repositories ignore repositories you can't view - that'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't exist in the active query space).
I mean, they totally could have built it that way. But they didn’t. I was answering why stars were removed.
From a data complexity standpoint, it sounds like they decided they didn’t want to have to make calls to the authorization layer when parsing a user’s stars. The downside is the behavior seen when a repo goes private, but my bet is that repositories being made private is far less frequent than calls to get a list of starred repos.
From a data complexity standpoint, it sounds like they decided they didn’t want to have to make calls to the authorization layer when parsing a user’s stars. The downside is the behavior seen when a repo goes private, but my bet is that repositories being made private is far less frequent than calls to get a list of starred repos.
I totally get that - it's not an insane design decision it's just different from what my default suggestion would be. And to be honest - your source of truth database, on a system of this scale, is likely going to be detached from your pool of active data (possibly with some data shadowing, caching - what have you).
The thing that throws me off is that they shot themselves with this footgun - whenever we (munk-a's employer) footgun ourselves we remove the footgun to prevent future footgunnery. They made the original design decision one way, and when they were burned by it they didn't re-examine it.
The thing that throws me off is that they shot themselves with this footgun - whenever we (munk-a's employer) footgun ourselves we remove the footgun to prevent future footgunnery. They made the original design decision one way, and when they were burned by it they didn't re-examine it.
FWIW, if the blog post had centered around “GitHub, it’s strange to me that you made this mistake and didn’t reevaluate the root causes, and now I’ve made the mistake and it sucks”, I’d not be griping all over the comments here.
It’s the framing that GitHub has inflicted a deep, irreparable wound to the author that I can’t reconcile with the facts.
It’s the framing that GitHub has inflicted a deep, irreparable wound to the author that I can’t reconcile with the facts.
> From a data complexity standpoint, it sounds like they decided they didn’t want to have to make calls to the authorization layer when parsing a user’s stars.
You can also solve that by adding a flag column, or putting privated stars in a different table. That tiny bit of denormalization shouldn't be more expensive than the current process, or the other costs of privating/unprivating a repo.
You can also solve that by adding a flag column, or putting privated stars in a different table. That tiny bit of denormalization shouldn't be more expensive than the current process, or the other costs of privating/unprivating a repo.
It's just bad design never getting fixed despite several prior incidents except for GitHub's own project which they reverted.
Why do they not just give a public/private flag on star data than somehow modifying the data irreversibly?
For users, just remove the repo from their starred project list if it's not visible.
Why do they not just give a public/private flag on star data than somehow modifying the data irreversibly?
For users, just remove the repo from their starred project list if it's not visible.
why not just do not display it and keep stars?
This kind of shit (accidentally doing something that in retrospect feels dumb and stupid but made sense if you were in a certain brain space) happens all the time and it’s nice the author wrote about it. I could easily see myself doing this.
It should be possible for GitHub to restore. If not now, then in the future.
It should be possible for GitHub to restore. If not now, then in the future.
Are y’all out here really stressing over GitHub stars?
What in the world…
Write some unit tests, put a benchmark together, show me example commands to get started, ANYTHING substantial will mean much more to potential new users than seeing how many GitHub stars you have.
Just my two cents, I think this is WAY off the mark.
What in the world…
Write some unit tests, put a benchmark together, show me example commands to get started, ANYTHING substantial will mean much more to potential new users than seeing how many GitHub stars you have.
Just my two cents, I think this is WAY off the mark.
It resets watchers also and people subscribed to issues. That negatively impacts the project
Ah, I didn’t know that.
Well! I’m the fool, it seems. That actually sounds terrible and rather substantial. You’d think there’d be an Undo for that.
Well! I’m the fool, it seems. That actually sounds terrible and rather substantial. You’d think there’d be an Undo for that.
I'm imagining this dev 'rm -rf / --no-preserve-root'ing and then blaming Linus.
I see a lot of folks talking about better warnings, etc.
Something else to consider for situations like this (or maybe for your apps) is to use the element of time to prevent mistakes.
For example, when a user wants to permanently delete an account or do any action that’s destructive, irreversible, or catastrophic… queue up a job for 10 minutes, an hour, or maybe a day, that gives the user time to cancel it if they made a mistake.
Out-of-band could be another way to prevent mistakes. “Want to delete your account? We’ll send you a link for you to continue via email”. This would also be cancelable.
There’s a lot of ways to deal with potentially irreversible actions outside of “better error messages” or checking the equiv of an “are you sure?” Checkbox.
Something else to consider for situations like this (or maybe for your apps) is to use the element of time to prevent mistakes.
For example, when a user wants to permanently delete an account or do any action that’s destructive, irreversible, or catastrophic… queue up a job for 10 minutes, an hour, or maybe a day, that gives the user time to cancel it if they made a mistake.
Out-of-band could be another way to prevent mistakes. “Want to delete your account? We’ll send you a link for you to continue via email”. This would also be cancelable.
There’s a lot of ways to deal with potentially irreversible actions outside of “better error messages” or checking the equiv of an “are you sure?” Checkbox.
Same story happened to us last December :/ https://www.qovery.com/blog/we-lost-3800-stars-on-github-in-...
This sounds like a great opportunity to move onto an open source platform to host this very popular open source tool.
Their current hosts have even just proved that they don't care about them much -- only first party projects get special treatment.
Their current hosts have even just proved that they don't care about them much -- only first party projects get special treatment.
Open source doesn’t mean direct access to the underlying data/databases. Self-hosted could work, but creates new problems like “are you sure your backups are working?”
This happened to me as well. It's sad that GitHub doesn't retain that data.
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 "good luck building up the community again".
My faith in their tech department is falling when they can't fix such a small issue.
My faith in their tech department is falling when they can't fix such a small issue.
Oof. Nice write-up, and it'll probably work. I.e. I'd wager that 'no we won't do for you (even in exchange for cash) what we previously did for ourselves' decision is going to get reversed.
On the plus side. 54k know and use this project not because they have it starred. So it will regain the stars rapidly, and it will again hit all the trending metrics, so new people will discover it also. No biggie
Seems a bit too extra for me. You are literally typing in the fully qualified repo name you want to make private:
Please type httpie/.github to confirm.
vs
Please type httpie/httpie to confirm.
At some point, we are going to have to stop coddling the users.
Please type httpie/.github to confirm.
vs
Please type httpie/httpie to confirm.
At some point, we are going to have to stop coddling the users.
The real lesson I make of it is that we shouldn't use a cloud product or SaaS if vendor do not allow customer to request recovery or prevent the customer to manage its own backups. I know git is decentralized and no code is ever lost but github is so much more than git.
Backups aren't mean to recover from outages. They are also, and I would even dare saying mostly, used to recover from human mistakes. If the vendor terms and conditions don't allow this, github is not a production ready solution.
Backups aren't mean to recover from outages. They are also, and I would even dare saying mostly, used to recover from human mistakes. If the vendor terms and conditions don't allow this, github is not a production ready solution.
Did I just read a pages-long whining, blaming the tool for the mistake?
Sure, github could help Httpie, but that would be unexpected. More than killing your repo because you're not paying attention.
Sure, github could help Httpie, but that would be unexpected. More than killing your repo because you're not paying attention.
> But it doesn’t include anything specific to break you out of your auto-pilot mode if you’ve confused the address and think you’re looking at an empty house.
Destruction is destruction. I think a huge red notice should be enough to stop you from dozing off. I understand your pain, but I don't think that any of this is GitHub's fault. They can't read your mind, and they can't tell if you're feed up with OSS or just irresponsible.
Destruction is destruction. I think a huge red notice should be enough to stop you from dozing off. I understand your pain, but I don't think that any of this is GitHub's fault. They can't read your mind, and they can't tell if you're feed up with OSS or just irresponsible.
>"The same goes for stars. If you’re one of those 54K people who’ve starred the repo any time in the past decade, the repo is no longer among your starred projects." //
This seems like bad design from a UX perspective. Projects I star are a characteristic of my account. If a project is made private, I still want to have the star in my account list; it feels almost like gaslighting to just remove a star.
This seems like bad design from a UX perspective. Projects I star are a characteristic of my account. If a project is made private, I still want to have the star in my account list; it feels almost like gaslighting to just remove a star.
> If a project is made private, I still want to have the star in my account list
You can’t star a private project, so by definition you can’t "keep" a star on a project that went from public to private. That’s not bad design, that’s a logical behavior.
You can’t star a private project, so by definition you can’t "keep" a star on a project that went from public to private. That’s not bad design, that’s a logical behavior.
>so by definition you can’t "keep" a star on a project //
That doesn't seem to follow. It's not intrinsic, it's a design choice, surely.
That doesn't seem to follow. It's not intrinsic, it's a design choice, surely.
>Projects I star are a characteristic of my account.
What about deleted repos? Should those be maintained as well?
What about deleted repos? Should those be maintained as well?
I wasn't thinking the repo would be maintained beyond the title (and short description, maybe whole readme?) being in a list of starred repos, and maybe having something like "[now private]" or "[removed]" added.
If I know I starred a repo and then go back to it and it's no longer accessible, I want to see that I'm not going mad and have some information about why the repo is no longer accessible.
If I know I starred a repo and then go back to it and it's no longer accessible, I want to see that I'm not going mad and have some information about why the repo is no longer accessible.
This isn't the only case where Github deletes more than one would hope. If you require 2fa for an organization, instead of simply locking out users that don't have 2fa enabled until they enable it, it removes them from the organization, and you have to re-invite them to add them back. Fortunately, it does seem to remember the groups and permissions they had when you add them back ... sometimes.
Something which annoys me with GitHub is that I don't have the option of setting up a mailing list which people viewing my repository page can opt into, as easily as they can star or opt-in to notifications. I often want to ask my users things, and I simply have no mechanism of doing that.
(doesn't have to be a mailing list, that's just the simplest feedback-request mechanism I can think of.)
(doesn't have to be a mailing list, that's just the simplest feedback-request mechanism I can think of.)
Meta: why is the word "how" omitted from the title? I've seen this a couple of times recently and I don't understand why people are omitting words like "how" and "why." The only thing I see in the guidelines is about omitting "gratuitous" numbers and adjectives, neither of which "how" and "why" are.
The server automatically removes "how" and "why" at the start of a title. Numbers or at least 10 are also autoremoved.
On the bright side, I had no idea this existed, and now I'm going to use it quite a bit. And evangelize it to coworkers, who probably also don't know it exists, or one of them would have used it during a pairing session. I doubt they'll get back to 54k stars (and really, who cares about stars?), but this will probably lead to a lot more new users.
Same!
We use a nice SaaS service for time-tracking and invoicing called Harvest. I'm thinking of it, as when you go to delete an existing invoice, it has a similar prompt to this GitHub prompt. But instead of having you type in the org and repo name, you have to type in "YOLO" (as in, "you only live once" :)
Goes to show how "red buttons" won't make a difference when it comes down to screwing up.
Starred and watched again, it's a great project, hopefully the whole audience comes back soon
[deleted]
Sounds like Microsoft recruits from the same pool as Atlassian for its Customer Success team :)
Yikes. Can this be turned into a multi-sig 2fa, or 1 hour waiting period before confirmation?
Came here to hopefully see GitHub came to the rescue through a friend of a friend on HN..
Unfortunately....not
Unfortunately....not
This hackernews post and other media coverage is getting the job done. Yesterday I saw they were at 3.2K stars, and right now they are 8.7 stars. I suspect this event will get them more users and will turn out better for them in the long run.
I dunno. You made a mistake, that’s on you. It’s so easy to say you want more hand-holding, and sure, maybe that’s not a bad idea in a sense, but you still made the mistake.
I do appreciate they aren’t yelling and complaining about it, however.
I do appreciate they aren’t yelling and complaining about it, however.
None of the "Lessons learned" are of personal nature - unbelievable.
I know, I'm seething at how many people are supporting this person.
I would be on his side too if he started with accepting his part in this and took responsibility but he clearly blames GitHub for everything and learned nothing from this. Such arrogance, let's see if HTTPie will have a nice warning every time you try to do a http delete command.
I've done something similar to this and took responsibility. I accidentally deleted an Azure Resource Group with the CLI tool. It just says "Are you sure you want to do this? Y/n" Doesn't even tell you what you're deleting. Oh whoops all the resources within that resource group are now irreversibly gone now.
My lessons learned was, when doing something potentially dangerous no matter how unimportant you think it is, slow down and take your time.
Things such as making a repo private or deleting things are relatively infrequent. It doesn't hurt to take a few minutes to carefully check all the variables before doing anything. You aren't losing much time in the grand scheme of things. Now he's definitely lost more time. Was it worth the few seconds you would have saved if you were on the right thing?
I would be on his side too if he started with accepting his part in this and took responsibility but he clearly blames GitHub for everything and learned nothing from this. Such arrogance, let's see if HTTPie will have a nice warning every time you try to do a http delete command.
I've done something similar to this and took responsibility. I accidentally deleted an Azure Resource Group with the CLI tool. It just says "Are you sure you want to do this? Y/n" Doesn't even tell you what you're deleting. Oh whoops all the resources within that resource group are now irreversibly gone now.
My lessons learned was, when doing something potentially dangerous no matter how unimportant you think it is, slow down and take your time.
Things such as making a repo private or deleting things are relatively infrequent. It doesn't hurt to take a few minutes to carefully check all the variables before doing anything. You aren't losing much time in the grand scheme of things. Now he's definitely lost more time. Was it worth the few seconds you would have saved if you were on the right thing?
Your comment about HTTPie DELETE (or any other verb that changes the system state) points at the exact problem: what is the right balance between giving the user the power and preventing the user from shooting themselves in the foot.
For example, should "my brain switched to auto-pilot mode" be seriously considered as a risk to be mitigated?
For example, should "my brain switched to auto-pilot mode" be seriously considered as a risk to be mitigated?
Sorry but losing stars by going from public to private is a small price to pay compared to going from private to public - what would you suggest be the guiding hand to prevent that kind of situation?
Just went and starred the repo. Looks like they are back up to around 5% of their original star count. Not good but probably not a catastrophe for the project.
It seems the loss of watchers is still an issue though.
It seems the loss of watchers is still an issue though.
I sometimes wish those developers who have a lapse in sanity (left-pad, faker.js, etc.) would just do this to their most popular repos instead of poisoning the software supply chain.
In a few years you'll be able to buy GitHub stars as NFT.
I agree with the author on most of their points, but I wonder if this is an argument for self-hosting your repository(ies) once your project reaches a critical-mass?
I liked the post. Then I got interested on their upcoming desktop tool. Then I decided to keep up with them but didn’t manage to find a rss of their blog…
Is rss dying?
Is rss dying?
GitHub should restore it and they should do it to cause themselves pain so they address the the improvement they can make to the Uc.
This is definitely a lesson for you as a customer and github service provider.
As customer if you are getting something for free you have to assume all risks. Here would be nice if public repos are also paid for open source projects so that you can pay for basic backup and recovery.
As a service provider github think about the product - "how do I design a more reliable system?" Deleting data immediately is never a best practice better alternative is to delay the destruction.
As customer if you are getting something for free you have to assume all risks. Here would be nice if public repos are also paid for open source projects so that you can pay for basic backup and recovery.
As a service provider github think about the product - "how do I design a more reliable system?" Deleting data immediately is never a best practice better alternative is to delay the destruction.
This is giving me a really great idea for a tool that saves past states and allows for clean reversals of said mistakes.
Alternate title: "How I deliberately messed up and why it's definitely everyone else's fault"
i mean, if they hadnt taken their repo private on accident, i probably wouldnt ever have heard of them.. i never really was interested in what the most watched or starred repos were, but something better than curl? yes please, may i have another?
They already have more than 10k star now. So this mistake sure gave them some publicity.
What are some of the benefits of HTTPie over classic wget and cURL?
Does HTTPie support WebSockets?
Does HTTPie support WebSockets?
I really like this post.
It shows how we gamify everything including open-source.
It shows how we gamify everything including open-source.
I've a feeling the author blames GitHub for this. It makes sense to be angry about it but don't see how it's GitHub's problem that you autopilot destructive actions. Although agree that the UI could be improved.
Imagine this in any other profession, oh I put gold in the trash but the trash bin did not inform me that I was pouring such important thing there, or why the disposal vehicle not stopped me after detecting such valuable content?
I like the tool, somehow I'd never heard of it until now
The post is omitting that the user must type the name of the repository in full; in this case, they typed `httpie/httpie`. If one is in such a deep autopilot state, no amount of warnings will work.
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]/[username]. [organization]/[organization] is the obvious corrolary.
Anyways it's embarrassing that Github made this same mistake themselves, and yet couldn't spare the time for a massive content creator contributing to their platform
Anyways it's embarrassing that Github made this same mistake themselves, and yet couldn't spare the time for a massive content creator contributing to their platform
Not just embarrassing, disgraceful.
The post addressed this.
> What put me on the wrong path was an otherwise completely unrelated action: I had just done the same (i.e., hidden an empty README) on my personal profile by making jakubroztocil/jakubroztocil private.
> GitHub’s conceptual model treats users and organizations as very similar entities when it comes to profiles and repos. 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.
> I didn’t realize at the moment there’s an inconsistency in the naming of this special repo containing profile READMEs and that it differs for users and organizations: name/name vs. name/.github.
> That’s why I proceeded to make httpie/httpie private instead of httpie/.github without realizing my mistake.
There'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't register that this was not in fact the profile README repo they were looking for.
> What put me on the wrong path was an otherwise completely unrelated action: I had just done the same (i.e., hidden an empty README) on my personal profile by making jakubroztocil/jakubroztocil private.
> GitHub’s conceptual model treats users and organizations as very similar entities when it comes to profiles and repos. 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.
> I didn’t realize at the moment there’s an inconsistency in the naming of this special repo containing profile READMEs and that it differs for users and organizations: name/name vs. name/.github.
> That’s why I proceeded to make httpie/httpie private instead of httpie/.github without realizing my mistake.
There'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't register that this was not in fact the profile README repo they were looking for.
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.
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.
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 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'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.
Github should really just do the right thing.
Restore their stars! Restore their stars!
Good lessons learned, thanks for sharing!
Ugh that sucks
I gave them a star to help them out.
Hi team,
You got my star back. Good luck.
You got my star back. Good luck.
rm -rf /
gives no such warnings, and maybe it should, or maybe people should be _very_ careful when typing rm -rf in front of anything.
gives no such warnings, and maybe it should, or maybe people should be _very_ careful when typing rm -rf in front of anything.
> GNU rm normally declines to operate on any directory that resolves to /.
https://www.gnu.org/software/coreutils/manual/html_node/Trea...
It’s both, but mostly the first one. rm’s default behavior is terrible design. Just because UNIX does something doesn’t make it good.
"the biggest accidental community loss in open source history"
This was very much drama for very little.
Sure, some might follow the project to know about updates, but if people care that much if they are using the latest version of a CLI tool then they will certainly check it out again later.
Very very few people of those who followed the project cares, and close to nobody cares what percentile the project ranks as by number of stars on github. Heck, even the author cares so little that he let himself mess around mindlessly while ignoring warnings and forgetting what the project was called.
Github warned about the action, and even required written confirmation to make sure it was the correct repo. The author also makes a point about naming being different for orgs and private, but if the github repo had any meaning then the author must have been very aware of what the name of it was.
Sure, github can add even more roadblocks and confirmations for those who are very careless despite all the warnings, but I don't want that personally. It's a tradeoff, and I think github has the right balance.
But sure, the situation is mildly annoying for those few who actually care.
But the dumbest part: The complaint about github not using time to restore backups to correct the mistakes of the author. Sure, they probably could, but how will they decide if a user should get special treatment? If they start bringing out backups for some users then there will be a lot of others expecting and asking for the same thing, and more.
Some might say that it won't be a problem, but considering that the author is already expecting github to restore their backups for him because github restored their own backups only proves the problem.
This was very much drama for very little.
Sure, some might follow the project to know about updates, but if people care that much if they are using the latest version of a CLI tool then they will certainly check it out again later.
Very very few people of those who followed the project cares, and close to nobody cares what percentile the project ranks as by number of stars on github. Heck, even the author cares so little that he let himself mess around mindlessly while ignoring warnings and forgetting what the project was called.
Github warned about the action, and even required written confirmation to make sure it was the correct repo. The author also makes a point about naming being different for orgs and private, but if the github repo had any meaning then the author must have been very aware of what the name of it was.
Sure, github can add even more roadblocks and confirmations for those who are very careless despite all the warnings, but I don't want that personally. It's a tradeoff, and I think github has the right balance.
But sure, the situation is mildly annoying for those few who actually care.
But the dumbest part: The complaint about github not using time to restore backups to correct the mistakes of the author. Sure, they probably could, but how will they decide if a user should get special treatment? If they start bringing out backups for some users then there will be a lot of others expecting and asking for the same thing, and more.
Some might say that it won't be a problem, but considering that the author is already expecting github to restore their backups for him because github restored their own backups only proves the problem.
You missed the nuance in the criticism of GitHub's UI. The issue is not the presence of a roadblock, but that the same roadblock is put up regardless of how "actually" destructive the action to be taken is. The same roadblock should not be used to guard against both benign and severe consequences, else you have no real way of telling what lies on the other side of the roadblock you're plowing through.
I didn't miss it, I just don't agree with it. With the name being different I'd say the roadblock is different, but you might not agree, and that's fine.
I really don't care about the number of stars my project has if I'm going to make something private. It's not like most important projects sticks out by a very significant amount of stars. What percentile would? And what percentile of these occurances are on this scale? (basically none according to the article)
I'd care more about the number of active contributors who will loose access, if I did care for a message like that.
I really don't care about the number of stars my project has if I'm going to make something private. It's not like most important projects sticks out by a very significant amount of stars. What percentile would? And what percentile of these occurances are on this scale? (basically none according to the article)
I'd care more about the number of active contributors who will loose access, if I did care for a message like that.
While the article focuses on lost stars, they also lost a lot of repository watchers.
This is pretty significant because lots of downstream users and distribution maintainers use the watching feature to get release and security advisory notifications. If this had happened secretly it's possible that a security release would be delayed because they didn't see the announcement early enough. (In fact, in the article they mention they had a security advisory recently -- so it's possible the above scenario has already happened.)
This is pretty significant because lots of downstream users and distribution maintainers use the watching feature to get release and security advisory notifications. If this had happened secretly it's possible that a security release would be delayed because they didn't see the announcement early enough. (In fact, in the article they mention they had a security advisory recently -- so it's possible the above scenario has already happened.)
[deleted]
I watched people use software for years. If you have the exact same Popup every day, you’ll get used to click ok. Has no meaning anymore. It’s in the muscle memory.
There's no nuance.
The UI warns you something serious is going to happen with bold text on a separate line.
It makes you type the full path of the affected object.
His explanation for what he was doing in the first place (making a README file private) doesn't make the slightest bit of sense.
It's a PR stunt for a startup company.
The UI warns you something serious is going to happen with bold text on a separate line.
It makes you type the full path of the affected object.
His explanation for what he was doing in the first place (making a README file private) doesn't make the slightest bit of sense.
It's a PR stunt for a startup company.
Stars on GitHub are huge in open source. 54,000 stars is a big deal and puts your project into a super-elite category.
What concrete benefits does a project get from having lots of stars? I'm not disagreeing with you, I'm just wondering what the stakes are, since I don't have a lot of open source background myself.
I'm not sure if there is a fixed universal set of concrete benefits. It probably varies from project to project and the people involved.
If it’s such a big deal then why is GitHub not intervening to help a “super-elite” tier of project?
Devs retconned the concept of a like onto a star. That doesn’t mean they are the same thing.
Devs retconned the concept of a like onto a star. That doesn’t mean they are the same thing.
> If it’s such a big deal then why is GitHub not intervening to help a “super-elite” tier of project?
That's why this is a #1 post.
> Devs retconned the concept of a like onto a star. That doesn’t mean they are the same thing.
Yes, the semantics are ill-defined.
That's why this is a #1 post.
> Devs retconned the concept of a like onto a star. That doesn’t mean they are the same thing.
Yes, the semantics are ill-defined.
> Github warned about the action, and even required written confirmation to make sure it was the correct repo.
Sure, but the written warning was the same one for a completely safe action.
Sure, but the written warning was the same one for a completely safe action.
You mean the one that requires you to write the full path of the affected object?
[deleted]
Wow, the tone alone leaves much to be desired. You must have a very unempathetic culture where you live. Best of luck to you dude, all the warmth and kindness and good vibes!
Wow, you must be a miserable, wretched, shell of a person to possibly write something like this. It’s really sad no one ever taught you manners. Hopefully one day you learn to be happy and a better person like me.
^ this is not much better tone-wise
^ this is not much better tone-wise
Hi stranger, good vibes to you too. Looks like you need them!
chikipowpow(2)
"It's their fault, they only showed 5 warning banners. A 6th one would have totally stopped me from doing this."
If a "type your repository name to confirm" box still doesn't make you double check that you picked the right repository, what else can they even do?
If a "type your repository name to confirm" box still doesn't make you double check that you picked the right repository, what else can they even do?
There's more nuance there:
> I didn’t realize at the moment there’s an inconsistency in the naming of this special repo containing profile READMEs and that it differs for users and organizations: name/name vs. name/.github.
It'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's main product repo name == the org's name, well, it's not as surprising I'd say.
> I didn’t realize at the moment there’s an inconsistency in the naming of this special repo containing profile READMEs and that it differs for users and organizations: name/name vs. name/.github.
It'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's main product repo name == the org's name, well, it's not as surprising I'd say.
Note the repository names here are "httpie/httpie" and "httpie/.github". I don'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't just fix the glitch and prevent this sort of behavior.
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'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/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.
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.
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/frustration.
I’m curious which statements from the article carried that tone?
I think in the "But theres a confirmation box, right?" and if I had to quote a portion I'd quote
>>"To paraphrase, the box tells you “You’re about to demolish a house. If there are any people inside, they will all die”. But it doesn’t include anything specific to break you out of your auto-pilot mode if you’ve confused the address and think you’re looking at an empty house."
>>"The dialog should be more contextual and, paraphrasing again, it should say “You’re about to kill 55,000 people.” That would’ve certainly made me pause."
Theres something about the juxtaposition that makes it feel like it should have been obvious. I think its because in those examples you would blame whoever didn't put whatever guard rail was necessary to prevent those outcomes. My suspicion is that it wasn't the authors intent and they were probably just upset, but thats an opinion I formed after reading the rest.
>>"To paraphrase, the box tells you “You’re about to demolish a house. If there are any people inside, they will all die”. But it doesn’t include anything specific to break you out of your auto-pilot mode if you’ve confused the address and think you’re looking at an empty house."
>>"The dialog should be more contextual and, paraphrasing again, it should say “You’re about to kill 55,000 people.” That would’ve certainly made me pause."
Theres something about the juxtaposition that makes it feel like it should have been obvious. I think its because in those examples you would blame whoever didn't put whatever guard rail was necessary to prevent those outcomes. My suspicion is that it wasn't the authors intent and they were probably just upset, but thats an opinion I formed after reading the rest.
Thank you for quoting. I see where you’re coming from - the comparison to killing people is pretty hyperbolic.
Do you agree that, hyperbolic metaphors aside, the UI improvement suggestion is a good one?
Do you agree that, hyperbolic metaphors aside, the UI improvement suggestion is a good one?
> If a "type your repository name to confirm" box still doesn't make you double check that you picked the right repository, what else can they even do?
It makes you type user/repo, which is different in a serious way. It's easy for the difference between ".github" and "httpie" to set off alarm bells. But the difference between "httpie/.github" and "httpie/httpie" can slip through.
> "It's their fault, they only showed 5 warning banners. A 6th one would have totally stopped me from doing this."
The request is for the warning to say how much will be deleted, not to add another step.
It makes you type user/repo, which is different in a serious way. It's easy for the difference between ".github" and "httpie" to set off alarm bells. But the difference between "httpie/.github" and "httpie/httpie" can slip through.
> "It's their fault, they only showed 5 warning banners. A 6th one would have totally stopped me from doing this."
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.
[deleted]
Also seems a bit suspect that they had a "perfect UI/UX example" to show how they would have handled these dialogs. Is this whole thing an advertisement for HTTPie?
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't offer that as a standalone service and 2) that wasn't already in their contract), I don't see how the example UI is anything but a straight improvement.
[deleted]
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!
“They warned me but because I didn’t read the dialog box because it was too boring!
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'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/UX of a very destructive operation with real contextual data about what is about to be destroyed.
He accepts responsibility for what he did, but points out the very real opportunity to improve the UI/UX of a very destructive operation with real contextual data about what is about to be destroyed.
You can only confirm the dialog box by typing in that line you're saying he didn't notice.
Reads article and somehow misses it's entire thoroughly examined point, chides author for not paying attention.
If I understood the blog post correctly, the author wants the "You will PERMANENTLY lose: All stars and watchers from the repository" to be changed to "[...] X stars and Y watchers..." Which I agree would be a better UI.
Like so often we can easily judge this by how willing we would be to accept the same behaviour in real life and I'm pretty certain that most would not accept an UI where you could e.g. just give away your house by writing the wrong adress into some form.
I did RTFA. I do not accept the excuse that he didn’t read it properly. He skimmed it because he thought it was the same box but it wasn’t. He even admits that it contained the exact information that he was looking for. I don’t see any way he can complain.
Ok then.
I hope others are less judgmental of you than you are of them next you make a mistake in life.
I hope others are less judgmental of you than you are of them next you make a mistake in life.
I take ownership over my mistakes. I don’t try to blame others. The world would be a better place if everyone did that.
I believe the world would be a better place if we all showed a bit more compassion towards each other, but let's agree to disagree.
I am very compassionate towards their loss. It must suck to have mistakenly destroyed their community. However I draw the line when they falsely blame others for their own mistake.
You can be compassionate for a mistake and still insist someone take ownership over this own careless error instead of blaming others. You mistake compassion for “let them do or say whatever they want because they are a victim”.
You can be compassionate for a mistake and still insist someone take ownership over this own careless error instead of blaming others. You mistake compassion for “let them do or say whatever they want because they are a victim”.
If all you read out of that article was blaming, then you didn't read it very closely.
The main takeway that I took from that article was the seemingly low effort improvement that could be made to the UI/UX of that action, which could help other people not make the same mistake.
That's not about blaming Github vs. themselves, it's a reasonable critique of an existing system and looking for ways to make it better for everyone.
Unless you think there is no room for improvement in that system at all.
The main takeway that I took from that article was the seemingly low effort improvement that could be made to the UI/UX of that action, which could help other people not make the same mistake.
That's not about blaming Github vs. themselves, it's a reasonable critique of an existing system and looking for ways to make it better for everyone.
Unless you think there is no room for improvement in that system at all.
You need to read more carefully. The author goes through great pains to ensure he doesn’t admit fault. Never once does he say “okay I admit, I should have been more careful.” He doesn’t take ownership ever over the fact that he made the mistake. He thinks this is all GitHub’s fault because of his misunderstanding and carelessness.
Not going to lie, this sounds like classic projection to me.
You must focus a lot on blaming in your life if that's what you mostly noticed when reading that article.
There's no way for either us to really know the author's intent or what he thinks - beyond the words on the page - but you seem convinced that "where the blame lies" was a major motivation, even thought it's all between the lines even by your own admission.
I read it differently, so as I said earlier, let's agree to disagree.
You must focus a lot on blaming in your life if that's what you mostly noticed when reading that article.
There's no way for either us to really know the author's intent or what he thinks - beyond the words on the page - but you seem convinced that "where the blame lies" was a major motivation, even thought it's all between the lines even by your own admission.
I read it differently, so as I said earlier, let's agree to disagree.
I think the more you write the less you make sense and you’re really grasping at straws here. Nothing you say at this point is more than strawmen, meanwhile everything I have said is not only internally consistent but makes perfect sense. I think you should give it a rest.
[deleted]
I would love to help rebuild the community.
[deleted]
You didn'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 "lesson learned" and not a "GitHub fucked us" angle cause it pretty clearly tells you what you're about to do.
This is a similar attitude to blaming users who close an program without saving, telling them it's their fault; the program even asked if they really wanted to close without saving!
But, it'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.
> but it should be a "lesson learned"
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's nice to have Undo actions, or some ways to revert possible mistakes. It makes software way less scary :)
But, it'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.
> but it should be a "lesson learned"
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's nice to have Undo actions, or some ways to revert possible mistakes. It makes software way less scary :)
The article literally has a section "Lessons learned".
Lessons learned... for GitHub to take.
While the author clearly feels bad about the fact that they've lost his community and that GitHub didn't restore it (which is honestly what any of us would've felt under similar circumstances), they'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're doing, but this example clearly demonstrates that what'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't dangerous, the distractions ("Type this repo's name", etc) just go away. It'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'm not really sure how you'd do a "cascading soft delete" without making some kind of manual cascading logic? If anyone'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't needed at all haha.
As designers and developers we've been given a chance to sharpen our toolkit. Thanks, HTTPie! You've gained a new star :)
Edit: Changed GitHub couldn't restore to GitHub didn't restore, as pointed out by @ncmncm (https://news.ycombinator.com/item?id=31033758#31034195)