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

391–400 of 697 posts

Re: We lost 54k GitHub stars

#391

Post by steve_adams_86 »

apostacy wrote: post #380
steve_adams_86 wrote: post #301

Apart from it being clear that the UI and the user using it could have been better, I don’t agree with criticism like “GitHub should obviously do x” or “this would be easily resolved if the action didn’t caused cascading deletes” and so on. GitHub is a large and complex set of applications, and making changes like that is probably not trivial. It’s probably not a high priority either. This is the first time I’ve hear…

Should customers who have had a bad experience just not give any feedback then? Github should be grateful for this feedback. I know that it takes effort to make your product or service better, but that doesn't mean that customers shouldn't ever say anything. Customers are telling Github how it can improve its service. Github can choose to listen to them, or not. With some simple frontend changes, they can probably re…

I completely agree that the feedback is valuable and I don’t think no one should say anything. In fact I think it’s essential to say something.

I’m only commenting on how so many comments trivialize the work required to resolve this. I have a feeling nothing is trivial at GitHub.

Re: We lost 54k GitHub stars

#392

Post by zach_garwood »

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?

I'm not at a terminal, so I can't check it out, but could you make a compound foreign key with the soft delete column and use the on update cascade? Something like `alter table stars add foreign key (repo_id, is_deleted) references repos (id, is_deleted) on update cascade;`

Re: We lost 54k GitHub stars

#393

Post by 14u2c »

lalopalota wrote: post #303
jakelazaroff wrote: post #267

Earlier quoted context omitted.

Just don't show them. Filter out private repos before showing a user's stars, notifying them of issues, etc.

Right, just more work. More tests. More edge cases. More time.

Well, they put in the time to test a massive cascading delete operation. Surly a flag would have offered far less possibility of catastrophic outcomes and therefore would been significantly easier to confidently develop and test.

Re: We lost 54k GitHub stars

#394

Post by steve_adams_86 »

njsubedi wrote: post #312
steve_adams_86 wrote: post #301

Apart from it being clear that the UI and the user using it could have been better, I don’t agree with criticism like “GitHub should obviously do x” or “this would be easily resolved if the action didn’t caused cascading deletes” and so on. GitHub is a large and complex set of applications, and making changes like that is probably not trivial. It’s probably not a high priority either. This is the first time I’ve hear…

But.. one of their developers also made the same mistake as the OP. The OP learned a lesson but seemingly anyone at GitHub didn’t think, “we should fix this confirmation dialog so this doesn’t happen again”.

It’s also possible that they did consider it, but upon investigation it entailed more work than they could justify.

I do think including more context about what will be destroyed by the action would be great, and probably pragmatic, but… If typing out the name of the repository isn’t enough, providing context might not be either.

The more I think about it, the more it seems like one of those “Whatever, we’ve got a million other things to do” situations. It might get a handful of inquiries about it per year while a dozen other features get hammered with attention and requests from paying customers.

Again, not saying they can’t improve it. Just giving them the benefit of the doubt here and proposing that it’s possible that it isn’t better for legitimate reasons.

Re: We lost 54k GitHub stars

#395

Post by gpvos »

saila wrote: post #253
vaishnavsm wrote: post #133

Earlier quoted context omitted.

Sure, I understand that. But I think, as a designer, I can't really control the actions of my users. I can only try to design such that I can get them closer to the action they want to take. From that perspective, I think adding the additional information to the warning UI would, if not solve the problem, at least get us one step closer to helping the user make the right decision. Tbh, when I've deleted repo's, I've…

In addition to typing the repo name, maybe they should make you check a box for each type of item that will be deleted: [ ] Delete 54,000 stars? [ ] Delete 8,000 watchers? [ ] etc

And, importantly, don't show an item if it has zero items in it.

Re: We lost 54k GitHub stars

#396

Post by ozim »

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?

Totally agree - cascade delete is such a nice thing - until it is not.

Technically you want to delete dependent stuff, but in this case this seems like overstepping on development side.

Re: We lost 54k GitHub stars

#397

Post by kgeist »

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 manage to delete projects by accident. When we asked them how that happened (we've set up so many hurdles!), the user says, just like in the article, that they thought they were deleting a different (test) project.

3rd iteration: I suggested showing the number of objects in the project (just like suggested in the article) so that the user knew they aren't deleting a test project.

I moved on to a different project since, but the saga probably continues.

Re: We lost 54k GitHub stars

#398

Post by HeavyStorm »

Did I just read a pages-long whining, blaming the tool for the mistake?

Sure, github could help Httpie, but that would be unexpected. More than killing your repo because you're not paying attention.

Re: We lost 54k GitHub stars

#399

Post by langsoul-com »

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…

Damn, would be interesting to know what the effects of the third iteration is.

Would validate/invalidate the authors ui suggestions.

Re: We lost 54k GitHub stars

#400

Post by langsoul-com »

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…

Perhaps 1-2 weeks of warning before a full delete of stars would be desirable for any repo with over 1k stars.

Sorta like most social media apps when you want to delete your account. It doesn't delete it fully until a month later

Post reply on HN