Live data from Hacker News

We lost 54k GitHub stars

httpie.io

301–310 of 697 posts

Re: We lost 54k GitHub stars

#301
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.

Re: We lost 54k GitHub stars

#302

Earlier quoted context omitted.

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

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.

Re: We lost 54k GitHub stars

#303

Earlier quoted context omitted.

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.

Right, just more work. More tests. More edge cases. More time.

Re: We lost 54k GitHub stars

#304

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

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

Re: We lost 54k GitHub stars

#305

Earlier quoted context omitted.

> 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 u…

> 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,…

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.

Re: We lost 54k GitHub stars

#306

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

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.

Re: We lost 54k GitHub stars

#307
post #8

Earlier quoted context omitted.

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…

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

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

Re: We lost 54k GitHub stars

#308
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.

Re: We lost 54k GitHub stars

#309
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.

Re: We lost 54k GitHub stars

#310
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.

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

Acknowledge their own agency and responsibility.

Literally stop blaming with language like “GitHub deleted…”

Post reply on HN