We lost 54k GitHub stars • Hacker News Board

Re: We lost 54k GitHub stars

#671

Post by Aeolun » Sat, Apr 16, 2022, 10:32 AM UTC

berkes wrote: post #475

h3mb3 wrote: post #454

Earlier quoted context omitted.

1. Why would it be particularly difficult for them to have soft deletes in Rails or at scale? 2. Like the article suggests, additional UX improvements could be made besides making it possible to restore a backup or providing an undo action. 3. I feel you are ignoring the fact that technology-wise it was probably Rails along with its MVC model that got them into their scale in the first place. 4. Had they focused on a…

> 1. Why would it be particularly difficult for them to have soft deletes in Rails or at scale? I don't know the internals of Github. But we had soft-delete dragging down our database. Indexing, for one, becomes tough. It also presumes everything lives in a single, canonical, transactional database. In real life, anything of scale, with legacy lives in multiple services. There'll be caches, search-indexes (elastic et…

> Why do software engineers insist on re-inventing wheels every few years rather than grab existing, proven and solid solutions for this?¹

For one thing, because it works very well and is much easier to wrap your head around than the command pattern (much less undoing a command, and keeping track of which commands make incompatible changes).

These things are worth the effort if you are going to build an app that will be around for ten years and serve an existing market. Much harder to justify if you are still figuring out what you actually need to do.

Like, I agree with you that most developers just don’t know about it yet, and therefore don’t use it, but that’s also a factor of MVC just being the right choice for 90% of all apps, and easier to get started with.

Re: We lost 54k GitHub stars

#672

Post by varajelle » Sat, Apr 16, 2022, 11:42 AM UTC

They already have more than 10k star now. So this mistake sure gave them some publicity.

Re: We lost 54k GitHub stars

#673

Post by hcks » Sat, Apr 16, 2022, 1:01 PM UTC

mekster wrote: post #199

This is laziness on GitHub. If your client asks you for work and you get lazy because it needs some internal modification that could take a day instead of an hour, you just respond it's impossible. Generally that's quite unacceptable especially when they already know about the situation from previous incidents and obviously human errors could happen again and the fact they did restore for their own project doesn't ma…

The author is not a client but a user. He doesn't pay GitHub, and is certainly not entitled to having a day of internal engineering workforce (costing in the tens of thousands of $) fixing his mistakes.

Re: We lost 54k GitHub stars

#674

Post by jdmichal » Sat, Apr 16, 2022, 1:06 PM UTC

david_allison wrote: post #243

jdmichal wrote: post #114

Earlier quoted context omitted.

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…

Would you consider submitting a patch?

Actually, I should. The biggest hold up will probably be translations though, unless they have that already translated.

Re: We lost 54k GitHub stars

#675

Post by mattcwilson » Sat, Apr 16, 2022, 2:43 PM UTC

alecbz wrote: post #666

mattcwilson wrote: post #634

Earlier quoted context omitted.

From the post: > Due to an unfortunate sequence of events, I accidentally made the project’s repository private for a moment. And GitHub cascade-deleted our community that took 10 years to build. This reads the same, to me, in terms of cause and effect.

In terms of cause and effect yes, in terms of attribution no.

I’m sincerely struggling to understand - what is changed by referring to Github as the subject of the second sentence, as opposed to leaving out Github in the version you proposed?

Re: We lost 54k GitHub stars

#676

Post by mattcwilson » Sat, Apr 16, 2022, 2:44 PM UTC

burnished wrote: post #670

mattcwilson wrote: post #370

Earlier quoted context omitted.

Thank you for quoting. I see where you’re coming from - the comparison to killing people is pretty hyperbolic. Do you agree that, hyperbolic metaphors aside, the UI improvement suggestion is a good one?

go back and re-read the comment you originally replied to

Indeed - thanks :)

Re: We lost 54k GitHub stars

#677

Post by sbarre » Sat, Apr 16, 2022, 4:11 PM UTC

farmerstan wrote: post #617

sbarre wrote: post #614

Earlier quoted context omitted.

I believe the world would be a better place if we all showed a bit more compassion towards each other, but let's agree to disagree.

I am very compassionate towards their loss. It must suck to have mistakenly destroyed their community. However I draw the line when they falsely blame others for their own mistake. You can be compassionate for a mistake and still insist someone take ownership over this own careless error instead of blaming others. You mistake compassion for “let them do or say whatever they want because they are a victim”.

If all you read out of that article was blaming, then you didn't read it very closely.

The main takeway that I took from that article was the seemingly low effort improvement that could be made to the UI/UX of that action, which could help other people not make the same mistake.

That's not about blaming Github vs. themselves, it's a reasonable critique of an existing system and looking for ways to make it better for everyone.

Unless you think there is no room for improvement in that system at all.

Re: We lost 54k GitHub stars

#678

Post by farmerstan » Sat, Apr 16, 2022, 5:08 PM UTC

sbarre wrote: post #677

farmerstan wrote: post #617

Earlier quoted context omitted.

I am very compassionate towards their loss. It must suck to have mistakenly destroyed their community. However I draw the line when they falsely blame others for their own mistake. You can be compassionate for a mistake and still insist someone take ownership over this own careless error instead of blaming others. You mistake compassion for “let them do or say whatever they want because they are a victim”.

If all you read out of that article was blaming, then you didn't read it very closely. The main takeway that I took from that article was the seemingly low effort improvement that could be made to the UI/UX of that action, which could help other people not make the same mistake. That's not about blaming Github vs. themselves, it's a reasonable critique of an existing system and looking for ways to make it better for…

You need to read more carefully. The author goes through great pains to ensure he doesn’t admit fault. Never once does he say “okay I admit, I should have been more careful.” He doesn’t take ownership ever over the fact that he made the mistake. He thinks this is all GitHub’s fault because of his misunderstanding and carelessness.

Re: We lost 54k GitHub stars

#679

Post by some_random » Sat, Apr 16, 2022, 6:01 PM UTC

canadaduane wrote: post #639

some_random wrote: post #599

Earlier quoted context omitted.

Honestly, they are blaming Github here. They included a whole "Lessons" section, which are complaints about Github's UI, then database design, then community support. I don't think we should be making fun of them for accidentally privating their repo, but I absolutely laughed at >The dialog should be more contextual and, paraphrasing again, it should say “You’re about to kill 55,000 people.” That would’ve certainly m…

> They aren’t leaning in heavily to blame Github here. > Honestly, they are blaming Github here. I think both of these statements can be true at the same time. They are taking much of the responsibility while also explaining how some aspects of Github's design are partly responsible for the outcome.

That's fair, there are two things that rub me the wrong way here. First being how big of a deal they're making about the github equivalent of bookmarks, stars are not a community, period. The more significant thing is that this industry runs on mv foobar foobar truncating foobar with no recourse short of forensics, github's confirmation flow is quite good. Sure it could be improved, but it's so much better than pretty much everything else we have to interact with that assigning responsibility to them for not sounding a klaxon in addition to requiring one to type in the exact name of what's being deleted is absurd.

Re: We lost 54k GitHub stars

#680

Post by vladsanchez » Sat, Apr 16, 2022, 7:03 PM UTC

I just starred HTTPIE again.

I feel their pain and while I don't claim to be perfect, this was was self-inflicted as it was clearly stated in Github dialog warning:

"You will permanently loose all stars and watchers of this repository"

Please don't blame Github for EndUser fault. People are click-happy and don't read. I'm happy they're able to restore their reputation and followers, not because of pity but because their product value and reputation.

Congrats HTTPIE!