281–290 of 697 posts
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.
Earlier quoted context omitted.
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 y…
> 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.
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.
Earlier quoted context omitted.
> 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.
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.
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 / in a input box triggering in us a lot consciousness or extra care. Typing something more unusual could actually be more impacting I think.
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.
Earlier quoted context omitted.
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 Th…
> 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 impor…
> "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.
Earlier quoted context omitted.
> 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.
> 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.
I really like this post. 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 ar…
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 - t…
Mistakes happen. It's better to have a really good Undo than a lot of confirmation dialogs.
I really like this post. 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 ar…
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 - t…
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 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.
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.
"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.