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.
We lost 54k GitHub stars
21–30 of 697 posts
Re: We lost 54k GitHub stars
#22Why 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).
Re: We lost 54k GitHub stars
#23Earlier quoted context omitted.
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.
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.
Re: We lost 54k GitHub stars
#24"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?
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.
Re: We lost 54k GitHub stars
#25The 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.
Re: We lost 54k GitHub stars
#26"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?
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!
Re: We lost 54k GitHub stars
#27GitHub 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.
Re: We lost 54k GitHub stars
#28https://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.
Re: We lost 54k GitHub stars
#29"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?
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!
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.
Re: We lost 54k GitHub stars
#30It does strike me as unfair that GitHub themselves made the exact same mistake but were able to fix it with database backups.
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.
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).