Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We lost 54k GitHub stars

httpie.io

Post reply on HN
Print view View original

31–40 of 697 posts

Re: We lost 54k GitHub stars

#31

Post by akerl_ »

Dylan16807 wrote: post #20
akerl_ wrote: post #11

Earlier 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.

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.

Re: We lost 54k GitHub stars

#32

Post by phphphphp »

pizza234 wrote: post #25

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.

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.

Re: We lost 54k GitHub stars

#33

Post by burnished »

paxys wrote: post #9

"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?

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.

Re: We lost 54k GitHub stars

#34

Post by sbarre »

paxys wrote: post #28
williamsmj wrote: post #16

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.

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.

Re: We lost 54k GitHub stars

#35

Post by Dylan16807 »

munk-a wrote: post #23
Dylan16807 wrote: post #20

Earlier quoted context omitted.

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.

That's bad because it lies to users and you can't remove the star when it's in that state.

Re: We lost 54k GitHub stars

#36

Post by delaaxe »

akerl_ wrote: post #8
spiderice wrote: post #5

Earlier quoted context omitted.

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…

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?

Re: We lost 54k GitHub stars

#38

Post by Dylan16807 »

akerl_ wrote: post #31
Dylan16807 wrote: post #20

Earlier quoted context omitted.

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.

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.

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.

Re: We lost 54k GitHub stars

#40

Post by munk-a »

polote wrote: post #2

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.

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.
Post reply on HN