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.
We lost 54k GitHub stars
261–270 of 697 posts
Re: We lost 54k GitHub stars
#262Earlier quoted context omitted.
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 t…
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.
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.
Re: We lost 54k GitHub stars
#263Earlier quoted context omitted.
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.
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] t…
> 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.
Re: We lost 54k GitHub stars
#264In 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
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.
Re: We lost 54k GitHub stars
#265Earlier quoted context omitted.
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 t…
> 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.
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.
Re: We lost 54k GitHub stars
#266Sure, 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?
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…
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.
Re: We lost 54k GitHub stars
#267Earlier quoted context omitted.
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?
Just don't show them. Filter out private repos before showing a user's stars, notifying them of issues, etc.
Re: We lost 54k GitHub stars
#268I 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 :)
Re: We lost 54k GitHub stars
#269Sure, 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?
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 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.
Re: We lost 54k GitHub stars
#270Earlier quoted context omitted.
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…
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? [ ] etc
Or just, you know, not delete anything until otherwise asked to. None of tha has anything essential to do with making the thing private.