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

541–550 of 697 posts

Re: We lost 54k GitHub stars

#541

Post by harg »

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…

Regarding cascading logic with soft deletes; I think the answer is that you don't cascade anything. You basically need to have `deleted_at IS NULL` conditions in your queries to exclude them.

Re: We lost 54k GitHub stars

#542

Post by nkozyra »

tentacleuno wrote: post #384
nkozyra wrote: post #170

Earlier quoted context omitted.

> There was an explicit suggestion right there in the article what else they could do, so you don't even have to guess. I read it, but I disagree. Honestly I don't think it would have prevented this. If you're muscle memorying past warning signs the text on the warning sign isn't going to matter much. My point was purely about UX, obviously there are technical solutions to this problem.

> If you're muscle memorying past warning signs the text on the warning sign isn't going to matter much. Do you have any concrete evidence for this? A lot of people keep saying this but don't provide anything factual in the way of UX studies, etc.

Well it's exactly what happened in this case. The user got a sort of warning fatigue with the UX and familiarity with it made it easy to do without much internal debate.

But I think some other UI flaws contribute to that in this case.

Comfort with a UI means eventually you want it to get out of your way and your brain will do what it needs to streamline the process. At which point those elements intended to break the flow of the app no longer do.

A Firefox use case w study and their approach.

https://medium.com/firefox-ux/designing-better-security-warn...

Good discussion of the problem:

https://ux.stackexchange.com/questions/44609/how-do-i-avoid-...

My takeaways are as follows:

The best thing to do is provide undo. Then you can reduce the hoops people have to jump through because the consequences are less severe.

Simplify the modal so the text about what will happen stands independently enough to be parsec on first glance.

Show quantified data on what could happen. Instead of "you will lose all followers" which is true for any app, display "you will lose all 54,318 followers"

Re: We lost 54k GitHub stars

#543

Post by mattgreenrocks »

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.

If it’s such a big deal then why is GitHub not intervening to help a “super-elite” tier of project?

Devs retconned the concept of a like onto a star. That doesn’t mean they are the same thing.

Re: We lost 54k GitHub stars

#544

Post by bspammer »

iforgotpassword wrote: post #502
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.

So, displaying an additional or more explicit warning that mentions stars and watchers makes sense. No arguing, hope they do that. But to me also, it left a little bit of a bad aftertaste that the author completely skips over the part of that process where you have to enter the repository name right where they show the two screenshots side by side. Anecdotal: You have to enter the full name for a couple destructive a…

Most people in this thread seem to be ignoring another very major cause: the inconsistent naming for personal READMEs between users and organizations. Users have their README at username/username, but orgs have it at orgname/.github

Nothing else on GitHub is like this: orgs and users are treated as the same class of entity pretty much all the time. I could easily see myself making the same mistake on autopilot.

Re: We lost 54k GitHub stars

#545

Post by op00to »

hrpnk wrote: post #458
op00to wrote: post #230

Earlier quoted context omitted.

Or simply automate the restoration! They know how to do it! Make it easy!

True. On the other hand - Atlassian did automate their backup restoration. Look where it brought them ;-)

Obviously you need to automate the restoration of the restoration!

Re: We lost 54k GitHub stars

#546

Post by johnywalks »

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…

> make sure you're not on autopilot when taking potentially dangerous actions

Humans will be humans, we can't help it.

Structures or systems that handle large amounts of user interactions should predict such use cases and design accordingly. a.k.a make them "idiot proof".

Re: We lost 54k GitHub stars

#547

Post by hombre_fatal »

kif wrote: post #534
davedx wrote: post #508

Contrarian opinion here. While things can always be better the Github UX is good enough here. I am reminded of an old phrase: “A bad workman always blames his tools.” At some point you just need to accept responsibility for your actions and stop blaming others.

Maybe the UX is not great, but surely having to type "httpie/httpie" would have given me a pause. Regardless, to make mistakes is human. What I don't really like is how the author starts attacking Github and Microsoft, just because they can't afford to fix the author's mistake. A huge red flag for me.

Once you do it a few times, writing the repo names means nothing. You have to do it on your repo with 0 followers just making it public. It’s not very notable unless you’re new to Github.

My advice is for Github to tell you that you’re losing 53,000 stars (not just “all your stars”) to help knock you out of autopilot.

I don’t get the finger pointing though. Obviously they messed up, it’s the entire post. But it’s also a good moment to reflect on how UX can be used to prevent people from messing up.

Re: We lost 54k GitHub stars

#548

Post by spixy »

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

almost all of my projects have < 5 stars, typing "0" half the time is more dangerous than typing my_name/my_repo.

Re: We lost 54k GitHub stars

#549

Post by vollmond »

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…

The other thing they could do is make user/organization structure for that profile readme the same - as he mentioned, he had just done it on his personal account, which is of the form `/`, so doing `httpie/httpie` for the organization made contextual/autopilot sense in the moment.

Re: We lost 54k GitHub stars

#550

Post by salmo »

I agree with the UI stuff and soft deletes. It was a lesson I learned about 7 years ago when I had users make some tragic mistakes in a system I made. “Are you sure?” doesn’t do anything more than a hand wave CYA. Showing the consequences does.

But then this starts sounding like a guy who went to the same bank for 30 years, knows the tellers, and doesn’t understand why they won’t give him a small business loan.

If you started a company, rely on GitHub for core infrastructure, why would you not pay for it? And if you did this, why would you expect them to do support outside of self-service? Open Source doesn’t mean charity-worthy anymore. Most “successful” projects are either spun out of or spearheaded by a business these days. And it’s not like GitHub is rolling in profit. Their enterprise offering is just starting to get traction under MS.

I think the complaints would be more valid if they were outside of the norms in this space. GitHub + MS is still 1000x less shady than Sourceforge. I don’t think you’d see different behavior from GitLab et al.

To the real politik-like view: this experience won’t make you (or many others) move elsewhere or pay for the service. So it’s ultimately a 0 consequence situation outside of a blog post and some community discussion.

I’m general, I don’t love pieces of software or companies. I’ll wear free t-shirts to mow the lawn, not with pride. I don’t love GitHub, but I dislike it less than the alternatives, partly because it’s just the easiest. I think most are in that camp. Oktocat lost his street cred long ago.

Post reply on HN