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

61–70 of 697 posts

Re: We lost 54k GitHub stars

#61

Post by akerl_ »

that_guy_iain wrote: post #44
akerl_ wrote: 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…

So all those people got notifications and then some of them looked further at the notifications and then engaged. Now those people won't get those notifications and won't engage. Most of these people won't notice they don't get these notifications. They won't resubscribe. They're lost forever. This is kind of like losing your email list. Your comment reads like you don't understand how a community works.

If the measure of community is “people who get my emails, and wouldn’t notice if they stopped getting my emails”, then yea, I guess we just disagree about what a community is.

I’m on an email list for marketing message for a hotel I stayed at last year. TIL that I’m part of their community.

Re: We lost 54k GitHub stars

#62

Post by robonerd »

BHSPitMonkey wrote: post #56
munk-a wrote: post #47

Earlier quoted context omitted.

Can you just clarify if that statement was sarcastic or not? I've had a very different experience around stars - they're just a bit of fluff and pretty unimportant compared to watches.

HTTPie's watches were irreversibly deleted, too.

> Irreversible

If the watchers still care to watch, they can choose to watch again.

Re: We lost 54k GitHub stars

#63

Post by nkozyra »

that_guy_iain wrote: post #44
akerl_ wrote: 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…

So all those people got notifications and then some of them looked further at the notifications and then engaged. Now those people won't get those notifications and won't engage. Most of these people won't notice they don't get these notifications. They won't resubscribe. They're lost forever. This is kind of like losing your email list. Your comment reads like you don't understand how a community works.

To be fair, people very active in a project will probably realize relatively quickly.

Those most likely lost to the wind forever are the ones that star a repo and forget about it.

I think the problem self corrects but agree there's a short term slowdown possibility in the wake.

Re: We lost 54k GitHub stars

#65

Post by munk-a »

akerl_ wrote: post #42
munk-a wrote: post #19

Earlier quoted context omitted.

So mark the repo as private without their permission to view and have queries for starred repositories ignore repositories you can't view - that's an extremely frequent approach to take with complex permission and social functions. I completely understand that not everyone has time to build everything and software is an evolving process - but soft deletion for social links is my default state of mind (then you overla…

I mean, they totally could have built it that way. But they didn’t. I was answering why stars were removed. From a data complexity standpoint, it sounds like they decided they didn’t want to have to make calls to the authorization layer when parsing a user’s stars. The downside is the behavior seen when a repo goes private, but my bet is that repositories being made private is far less frequent than calls to get a li…

I totally get that - it's not an insane design decision it's just different from what my default suggestion would be. And to be honest - your source of truth database, on a system of this scale, is likely going to be detached from your pool of active data (possibly with some data shadowing, caching - what have you).

The thing that throws me off is that they shot themselves with this footgun - whenever we (munk-a's employer) footgun ourselves we remove the footgun to prevent future footgunnery. They made the original design decision one way, and when they were burned by it they didn't re-examine it.

Re: We lost 54k GitHub stars

#67

Post by nessguy »

sefrost wrote: post #3

It does strike me as unfair that GitHub themselves made the exact same mistake but were able to fix it with database backups.

Just as AceJohnny said, the scope of this is entirely different. Restoring a backup for an internal project costs time/resources that the company can easily handle. If it became a problem it would be easy for github to tell their internal projects "No, we're no longer restoring from backups"

Opening up the ability to do that externally would potentially require multiple people working full-time to handle the requests.

"We even offered GitHub financial compensation for any resources required." Considering the tone of the article I think there's a very high risk if github accepted agreed to that we'd see an article titled "Github charges popular open source project $5000 to fix a minor accident"

Re: We lost 54k GitHub stars

#68

Post by RangerScience »

Heavily reminds me of this RubyConf talk: https://rc-temp000-videos.s3.us-west-1.amazonaws.com/Laura-M...

One of the core bits of the talk is about the sort of messages our automated systems give us, and whether they're sufficient, or woefully lacking - which is what the linked article is also talking about, when it talks about how the "warning: about to burn down a house" doesn't tell if anyone's in that house.

Re: We lost 54k GitHub stars

#69

Post by HL33tibCe7 »

pizza234 wrote: post #43
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.

It's not so easy to make this accident - one needs to type the full name of the repository. AWS does the same, for example, when deleting RDS instances, and I find it effective.

This is explicitly addressed in the article, and a compelling case is made for why that safety measure was ineffective in this case, I encourage you to read the article

Re: We lost 54k GitHub stars

#70

Post by vaishnavsm »

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 are enough to get people to think about what they're doing, but this example clearly demonstrates that what's important is to use design not to scare (alone?), but to convey the information which makes a dangerous action dangerous as well. I also really like the fact that when the action isn't dangerous, the distractions ("Type this repo's name", etc) just go away. It's super intuitive, and (for a newbie designer like me) really helps build an intuition for various design principles put in action.

Lesson 2, which was to use soft deletes, is something I have more thoughts about. I assume that the cascading done on GitHub would be done on a FK constraint, but I'm not really sure how you'd do a "cascading soft delete" without making some kind of manual cascading logic? If anyone's aware of a standard way to accomplish this, please do let me know. Of course, the best way may just be to simplify the model so they aren't needed at all haha.

As designers and developers we've been given a chance to sharpen our toolkit. Thanks, HTTPie! You've gained a new star :)

Edit: Changed GitHub couldn't restore to GitHub didn't restore, as pointed out by @ncmncm (https://news.ycombinator.com/item?id=31033758#31034195)

Post reply on HN