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

411–420 of 697 posts

Re: We lost 54k GitHub stars

#411

Post by remexre »

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…

Also sudo mode, right? They had to authenticate to the whole website again too, before doing this!

Re: We lost 54k GitHub stars

#412

Post by tyrfing »

d3nj4l wrote: post #407
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…

Agreed, and I'm genuinely surprised that so many on HN are angry at GitHub when they already made it so hard to do this. The author explicitly mentions they were on autopilot - it would take a significantly more challenging barrier for them to not do the exact same thing no matter how many prompts GitHub put there. It does make sense for it to be more reversible, but I can also understand why GitHub doesn't want to p…

I intentionally did this very recently for a whole bunch of old repos (mainly because a Github bot decided to start emailing me weekly about vulnerabilities in stuff that has been untouched for nearly a decade) and was mildly annoyed at how inconvenient it was to make them private. I would have said the warnings are unnecessary overkill.

It's quite amusing to read this so soon after.

Re: We lost 54k GitHub stars

#413

Post by cyphar »

NorwegianDude wrote: post #326
bobbylarrybobby wrote: post #306

Earlier quoted context omitted.

You missed the nuance in the criticism of GitHub's UI. The issue is not the presence of a roadblock, but that the same roadblock is put up regardless of how "actually" destructive the action to be taken is. The same roadblock should not be used to guard against both benign and severe consequences, else you have no real way of telling what lies on the other side of the roadblock you're plowing through.

I didn't miss it, I just don't agree with it. With the name being different I'd say the roadblock is different, but you might not agree, and that's fine. I really don't care about the number of stars my project has if I'm going to make something private. It's not like most important projects sticks out by a very significant amount of stars. What percentile would? And what percentile of these occurances are on this sc…

While the article focuses on lost stars, they also lost a lot of repository watchers.

This is pretty significant because lots of downstream users and distribution maintainers use the watching feature to get release and security advisory notifications. If this had happened secretly it's possible that a security release would be delayed because they didn't see the announcement early enough. (In fact, in the article they mention they had a security advisory recently -- so it's possible the above scenario has already happened.)

Re: We lost 54k GitHub stars

#414

Post by WA »

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

Re: We lost 54k GitHub stars

#416

Post by d3nj4l »

tyrfing wrote: post #412
d3nj4l wrote: post #407

Earlier quoted context omitted.

Agreed, and I'm genuinely surprised that so many on HN are angry at GitHub when they already made it so hard to do this. The author explicitly mentions they were on autopilot - it would take a significantly more challenging barrier for them to not do the exact same thing no matter how many prompts GitHub put there. It does make sense for it to be more reversible, but I can also understand why GitHub doesn't want to p…

I intentionally did this very recently for a whole bunch of old repos (mainly because a Github bot decided to start emailing me weekly about vulnerabilities in stuff that has been untouched for nearly a decade) and was mildly annoyed at how inconvenient it was to make them private. I would have said the warnings are unnecessary overkill. It's quite amusing to read this so soon after.

Same here - not too long ago I had to take a bunch of repositories private, and while I appreciated the prompt (I've dealt with destructive actions that have even less of a barrier before, and that sucks) it still was annoying to do that again and again.

Re: We lost 54k GitHub stars

#417

Post by munchler »

dmitryminkovsky wrote: post #300
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.

What concrete benefits does a project get from having lots of stars? I'm not disagreeing with you, I'm just wondering what the stakes are, since I don't have a lot of open source background myself.

Re: We lost 54k GitHub stars

#418

Post by Agentlien »

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…

I've seen some software, can't remember which, that forces you to type the name of the project you're deleting to confirm. That's made me think twice.

Re: We lost 54k GitHub stars

#419

Post by snurk »

ryandrake wrote: post #321
mynameisvlad wrote: post #239

Earlier quoted context omitted.

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

Warnings are good but not perfect. At the end of the day, you can’t help everyone with just warnings. You could make the UI bright flashing red, with a skull and crossbones, have it say “Never invoke this: it will delete all your data and kill your dog. Please type ‘I_WANT_CANCER’ to continue.” And users will do it. It can’t be helped. The only (admittedly hard) way is UNDO.

It's a real strength of Gmail and some other Google interfaces — undo instead of warning dialog.

Re: We lost 54k GitHub stars

#420

Post by manmal »

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

So, for projects with 100+ stars, add a wait period of 60 seconds until the delete button can be clicked _after_ the number is typed in. That should allow most users on autopilot to snap out of it, or make drunk users switch to a different tab and forget about it.
Post reply on HN