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

231–240 of 697 posts

Re: We lost 54k GitHub stars

#231

Post by mekster »

nosefrog wrote: post #176

Additional context: a GitHub employee addresses why they didn't do a backup restore in this tweet: > Yup, all watchers go when you go private and a bunch of notification settings etc. We've tried re-staring projects in the past etc but that ends up breaking lots of peoples notification settings. It's something we should make more reversible but hard for reasons > It's the reason we display this when you try to do it.…

That's one of the exact phrases you don't want to hear from a tech department.

They make tech excuses which were ultimately their own design and tell that's not possible to be fixed.

Re: We lost 54k GitHub stars

#232

Post by js2 »

cmeacham98 wrote: post #111
vaishnavsm wrote: post #70

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

I specifically dislike the "Lessons" section, as it throws all the blame on github and doesn't mention the seemingly obvious advice: "make sure you're not on autopilot when taking potentially dangerous actions, on github or any website". Yes, GitHub probably should show the stars in the warning UI, and hopefully that will prevent some of these mistakes. But GitHub makes it pretty hard to make this mistake already - t…

> I specifically dislike the "Lessons" section, as it throws all the blame on github and doesn't mention the seemingly obvious advice: "make sure you're not on autopilot when taking potentially dangerous actions, on github or any website".

First of all, this is self-evident. But second of all and more importantly: it doesn’t scale.

The reason we have blame-free postmortems is because people will always make mistakes, so we find ways to change process or design to minimize those mistakes.

If you think you’ll never do something on autopilot, you’re fooling yourself.

Re: We lost 54k GitHub stars

#233

Post by nemothekid »

mekster wrote: post #207
nemothekid wrote: post #143

Earlier quoted context omitted.

When you think about it, it seems reasonable, I think about what would happen if it were me. If I was working at GitHub, and I nuked something, then the rest of my day would be un-nuking that thing. On the other hand if I was working on something totally unrelated, and then you my PM came to me and said "can you stop what you're doing and unfuck this thing" it would obviously depend on what I was working on.

It's your customer (repo owners) asking for support and throwing it away being busy is just lazy attitude. You had prior incidents and the bugs were left as is and apparently it will happen again.

Being busy is lazy? GH has hundreds of thousands of customers. In your company, how often do you immediately drop everything to work on a single customer's issue? How often do customer issues sit in a support queue? What would be the reasonable turn around time for an issue like this?

Re: We lost 54k GitHub stars

#234

Post by terinjokes »

bearbin wrote: post #22

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

This change also clears out watchers. I was watching the repo to be notified of new releases (and security updates) and that was wiped out as part of this mistake.

Re: We lost 54k GitHub stars

#236

Post by oriki »

makeitdouble wrote: post #172
cmeacham98 wrote: post #111

Earlier quoted context omitted.

I specifically dislike the "Lessons" section, as it throws all the blame on github and doesn't mention the seemingly obvious advice: "make sure you're not on autopilot when taking potentially dangerous actions, on github or any website". Yes, GitHub probably should show the stars in the warning UI, and hopefully that will prevent some of these mistakes. But GitHub makes it pretty hard to make this mistake already - t…

On typing out the name of the resource, it is of course a way better check than just displaying it. I think it also was very efficient when there was only a few places using it, and the novelty made it attention focusing. Thing is, we type all day, and can type pretty much any string at a decent speed without putting much thought into it. Any of us must have mistakenly typed a full file path or API URL, just to reali…

It's also worth mentioning that the name of the resource here was confusing - the author mentions that this happened because he mixed up how GitHub names profile READMEs for organizations vs users.

Re: We lost 54k GitHub stars

#238

Post by WhyNotHugo »

This sounds like a great opportunity to move onto an open source platform to host this very popular open source tool.

Their current hosts have even just proved that they don't care about them much -- only first party projects get special treatment.

Re: We lost 54k GitHub stars

#239

Post by mynameisvlad »

chefandy wrote: post #215
mynameisvlad wrote: post #163

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

Pretty much agree— Universal human fallibility is not an avoidable moral failure, but looking down on those who've made, admitted, and taken responsibility for simple mistakes sure is. Unrealistic assumptions about people's attention, processing capability, and physical capabilities may be the greatest hurdle when trying to actually solve people's problems with software. It can even be a safety issue— consider the Th…

> I'll bet the list of side-effects that are important to some people would be pointlessly long.

There's many good ways to design this that wouldn't result in pointlessly long lists (which is another problem). You don't need to expose everything that will happen when you do an action, just the "most important".

With unlimited budget, you could compare a bunch of metrics to a baseline to figure out what might be important. Have a lot of stars, way more than the average? That would be nice to highlight. Only have a normal number of forks? Probably less important to highlight that. At the end of the day, Github repos aren't extremely unique. Sure there's probably extremely rare edge cases, but for most repos, comparing against a relatively small number of metrics should get enough to paint a picture of what might get broken. Everything else can be hidden behind a "... and X more" if people are curious.

This both highlights the most important things that might happen, and also provide people with an action to do before confirming, hopefully helping to break the autopilot at the same time.

Re: We lost 54k GitHub stars

#240

Post by asadawadia »

evouga wrote: post #224
bearbin wrote: post #22

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

Of course if GitHub were only a service for cloud hosting of Git repositories, it would be totally irrelevant whether or not the repository was marked private for 30 minutes. But GitHub, by design, seeks to be as much of a social network as a repository hosting service and people take the stars very seriously. I’ve seen many CVs that brag about the candidate’s star counts.

>GitHub, by design, seeks to be as much of a social network

This is so true - not sure why it isn't getting talked about more - they even have a feed now [which is getting better every few days]

Post reply on HN