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

431–440 of 697 posts

Re: We lost 54k GitHub stars

#431

Post by sparqlittlestar »

organsnyder wrote: post #352
CodeWriter23 wrote: post #258

Earlier quoted context omitted.

I’ve adopted a pattern of: If they click ok: Asking again to be sure you want to destroy masses of data But even that fails if there is a language barrier.

> But even that fails if there is a language barrier. Surely GitHub is localized? (and if not, why the hell not?)

I recall that GitHub used to be localised in several languages, but no more. And I can’t seem to find any references to it anymore, either. “GitHub interface translation” gives search results about code, not about GitHub’s interface

Re: We lost 54k GitHub stars

#432

Post by fer »

mypalmike wrote: post #315
ncmncm wrote: post #186

Earlier quoted context omitted.

There is no need to delete anything at all. Set the "private" flag when the user asks for to make it private. Unset the "private" flag when they make it public again. If it is needful to be able to delete stars, make a separate button for that. But it is hard to imagine such a need.

Stop. You've said the same thing a dozen times in this thread. Besides being repetitive, you're overlooking the obvious fact that having associations from non members of private repos to those repos is problematic. At the very least at the UI level, maintaining known dead internal links is bad form. So you'd be creating edge cases for the UI and probably numerous places deeper in the tech stack as well. Which is fine…

Mmh? Maybe it's because I've never touched frontend professionally in my life, but I think that if you're doing it in the UI you're doing it VERY wrong.

This logic should be purely in the DB model or very close to it. In any case the internal API should never ever list private repos of an organization a user isn't a member of, period. Stars or no stars. Follows or no follows. Why should it? There's no corner case here, if stars pose a problem, the problem isn't the stars, it's a defective model behind. Hiding things that aren't meant to be seen in the UI means putting business logic in the UI. Just don't.

Re: We lost 54k GitHub stars

#434

Post by nine_k »

411111111111111 wrote: post #410
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 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? Couldn't you just use an on delete trigger for this? I have no experience one the subject however

An ON UPDATE trigger for the is_deleted column would do.

Some databases also support INSTEAD OF triggers.

Re: We lost 54k GitHub stars

#435

Post by mlatu »

i mean, if they hadnt taken their repo private on accident, i probably wouldnt ever have heard of them.. i never really was interested in what the most watched or starred repos were, but something better than curl? yes please, may i have another?

Re: We lost 54k GitHub stars

#436

Post by roflulz »

WA wrote: post #414
kgeist wrote: post #397

Reminds me of our own quest to stop users from deleting their entire projects by accident in our product. 1st iteration: delete button with a confirmation box (standard stuff). Users click through the box in autopilot mode and still delete their entire projects. 2nd iteration: someone came up with an idea: confirmation box + an additional checkbox (if it isn't checked, the delete button is disabled). Users still mana…

Same here. I finally brought accidentally deleting stuff down to zero by having them type the number they get to lose: "You have 55,231 GitHub stars. Please type 55231 if you want to delete them all." But I guess, if you delete repos often enough, this will also become muscle memory. Edit: Just saw the other comment here suggesting the same: https://news.ycombinator.com/item?id=31033996

just do soft deletes that can be undone... seems so easy..

Re: We lost 54k GitHub stars

#437

Post by berkes »

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…

Github is built with MVC. On rails no less. Where problems like soft delete are hard, or even impossible to solve (in scale).

Yet there are many architectures beside MVC. Many of them decades old. Proven. Established. Yet unknown to devs who picked up a rails book on day 1 and never looked back (I've been guilty of that for years).

This particular problem is a textbook candidate for Command Pattern. The problem of undo is solved naturally in any event-sourced setup (git is even sourced, and moving through history a prime feature). Probably more architectures that I'm less familiar with, solve 'undo' as well.

But we are stuck with the web, backends in 2022, being built on MVC frameworks like Rails, where solving such issues is tough and complex. So we are stuck with a huge amount of warning dialogs to 'solve' this.

Point being: choose your architecture well, based on your needs and the tradeoffs. Don't just grab the next fancy framework, because that will decide for you, if, and how you solve things like 'soft delete' or 'undo'.

Re: We lost 54k GitHub stars

#438

Post by onion2k »

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…

GitHub probably should show the stars in the warning UI

In this particular case the stars would have been a useful clue, but in the majority of similar cases the wouldn't be any stars. It would be a useless and redundant signal.

Re: We lost 54k GitHub stars

#439

Post by terrymunro »

sorokod wrote: post #404

None of the "Lessons learned" are of personal nature - unbelievable.

I know, I'm seething at how many people are supporting this person.

I would be on his side too if he started with accepting his part in this and took responsibility but he clearly blames GitHub for everything and learned nothing from this. Such arrogance, let's see if HTTPie will have a nice warning every time you try to do a http delete command.

I've done something similar to this and took responsibility. I accidentally deleted an Azure Resource Group with the CLI tool. It just says "Are you sure you want to do this? Y/n" Doesn't even tell you what you're deleting. Oh whoops all the resources within that resource group are now irreversibly gone now.

My lessons learned was, when doing something potentially dangerous no matter how unimportant you think it is, slow down and take your time.

Things such as making a repo private or deleting things are relatively infrequent. It doesn't hurt to take a few minutes to carefully check all the variables before doing anything. You aren't losing much time in the grand scheme of things. Now he's definitely lost more time. Was it worth the few seconds you would have saved if you were on the right thing?

Re: We lost 54k GitHub stars

#440

Post by [deleted] »

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…

[deleted]
Post reply on HN