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

291–300 of 697 posts

Re: We lost 54k GitHub stars

#291

Post by barrkel »

cmeacham98 wrote: post #225
wpietri wrote: post #123

Earlier quoted context omitted.

I suggest you read "The Field Guide to Understanding 'Human Error'". You'd learn a lot. https://www.amazon.com/Field-Guide-Understanding-Human-Error... My view is that expecting humans to stop making mistakes is much less effective than fixing the systems that amplify those mistakes into large, irreversible impacts.

> My view is that expecting humans to stop making mistakes is much less effective than fixing the systems that amplify those mistakes into large, irreversible impacts. This is applicable to almost any activity: "Sure he was driving drunk, but the car's manufacturer should have prevented that from causing any damage!" I agree that GitHub should improve the design here - privating a '10 star / 1 week old' repo shouldn'…

Neither the author, nor anybody that I can see here, is saying that the author didn't make any mistakes.

But what you are saying is that marginal effort to prevent mistakes is not worthwhile.

Cars, to take your example, would not be as safe as they are today if they followed the principles you've shown in this post and the grandparent. And yes, even when driving drunk, which is illegal, is safer too - stay in lane, adaptive cruise control, automatic braking, etc. have all incrementally made even extremely ill-advised behaviours safer.

Re: We lost 54k GitHub stars

#292

Post by dzmien »

capableweb wrote: post #53
ghoomketu wrote: post #17

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. Now that you're on the HN's frontpage, hopefully somebody from Github upper management will see this and all will be good soon thanks to gold old HN (especially when they did the same thing themselves and restored it). Wish you the best.

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

Maybe some kind of grace period could be implemented that would allow changes like this to be undone within 24 hours or something.

Re: We lost 54k GitHub stars

#293

Post by whack »

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…

> 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

Relying on database cascade deletions is very dangerous. Especially since as the application/org grows, it's easy to lose track of all the things that may get cascaded. There's a good chance you'll find yourself having cascade-deleted data that you never intended to have deleted.

Manually implementing logic for "when archiving X, also archive Y and Z" takes more effort, but is a lot safer. When it comes to data.

What surprised me most is that github performs irreversible deletions when someone making a repository private. I would have expected them to just create a "is_deleted" column and set that flag to true. I wonder how much of this behavior is motivated by GDPR. Ie, complying with it requires completely deleting data when requested by the user, and they decided the most straight forward way to comply with that requirement is to delete the data immediately when requested.

Re: We lost 54k GitHub stars

#295

Post by chikipowpow »

NorwegianDude wrote: post #289

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

Re: We lost 54k GitHub stars

#296

Post by JJMcJ »

jdmichal wrote: post #114
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 ran into this in pgAdmin recently. When right-clicking on a server, the options to disconnect the server and remove the server are right next to each other. Clicking disconnect presents you with the following dialog box: "Are you sure you want to disconnect the server? No / Yes" Click remove presents you with the following dialog box: "Are you sure you want to remove the server? No / Yes" Good luck! I mean, it's no…

> just replacing the "Yes" button

Or the lazy web dialog popup with "Cancel" and "OK".

So you click on "Cancel Glorping The Frobnitz" and up pops a dialog with "Cancel" and "OK". It always takes a moments thought does the "Cancel" on the popup mean cancel the cancel glorping or cancel the cancel.

Since it takes literally seconds to change the button captions it might be nice to think of something clearer. Seconds if you're a UI expert which I'm not. Of course the webdev part of changing the captions on the page really would be seconds for me to do.

Re: We lost 54k GitHub stars

#297

Post by neoromantique »

diego_sandoval wrote: post #241
bsuvc wrote: post #84

Sure, the author should be responsible. Yes, GitHub should have a better UX around this action. But... There is another thing to consider: Is it really necessary that a repo that is accidentally made private and then made public should lose its stars anyway? Is that really what the repo owner or the people who starred the repo even want to happen?

Let's assume that the stars don't go away when the repo is made private. There are a couple of options: - The users can still see all their stars and find the private repo, which makes it not private. - The users can't see all their stars, they can only see their stars for the public repos. There's no way to find or unstar a private repo that you starred while it was public. This would lead to the situation that if y…

>I think the current behaviour is better than all of these options.

Current behavior is destructive.

>- All private repos that have been public at least once lead to a "this repo is now private" message, that would in practice allow anyone to make an index of all the private repos that were public at least once. And it would also allow anyone to know when a private repo that was private at least once is deleted.

This is a much better option.

Re: We lost 54k GitHub stars

#298

Post by lalopalota »

ncmncm wrote: post #181
vaishnavsm wrote: post #153

Earlier quoted context omitted.

Not sure what you meant? Are you pointing out couldn't vs didn't ? If so, I didn't really think about it, although now that you point it out, I think didn't would've been a better fit. I'll edit it, thanks!

I mean "refused to". There was absolutely no value to Microsoft in refusing to restore the deleted information, and there was no practical reason to have deleted it at all. Ultimately, it just amounts to contempt.

"I screwed up. By the way, it's your fault. I hope you realize how many people think more highly of your service because my project is there. Why wont you accept some money for a service you don't provide?"

What's the value in capitulating to that? Also, a user saying "delete this stuff" is a pretty practical reason to do so.

Indifference != contempt.

Re: We lost 54k GitHub stars

#299

Post by thayne »

This isn't the only case where Github deletes more than one would hope. If you require 2fa for an organization, instead of simply locking out users that don't have 2fa enabled until they enable it, it removes them from the organization, and you have to re-invite them to add them back. Fortunately, it does seem to remember the groups and permissions they had when you add them back ... sometimes.

Re: We lost 54k GitHub stars

#300

Post by dmitryminkovsky »

NorwegianDude wrote: post #289

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

Stars on GitHub are huge in open source. 54,000 stars is a big deal and puts your project into a super-elite category.
Post reply on HN