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

621–630 of 697 posts

Re: We lost 54k GitHub stars

#621

Post by jasonlotito »

NoboruWataya wrote: post #569

> The problem is that the box looks exactly the same for repos with no commits and stars and for repos with a decade-long history and 55k stargazers and watchers. And it says “Warning: this is a potentially destructive action.” It seems a bit much to expect the website to show you a warning of different levels of severity depending on the stars a repos has, particularly when the standard message is pretty severe and…

> It seems a bit much to expect the website to show you a warning of different levels of severity

I've done this for personal projects. I don't see why GitHub can't do something similar.

> It even makes you type the name of the repo you want to make private before proceeding

No, it literally does not. Nor does this mean you fully understand the implications of what you are doing as explained in the article.

> check what repo you're in before taking destructive actions

The amount of checking and automation of things for non-destructive actions, you'll forgive someone for expecting a bit of extra automation that, in this case, literally costs less.

Re: We lost 54k GitHub stars

#622

Post by senjin »

glacials wrote: post #615
parkingrift wrote: post #583

Earlier quoted context omitted.

I did read that part. He or she had to exactly type out "httpie/httpie" to confirm the action. I don't know what else GitHub could do to prevent this. How much handholding does GitHub need to offer? People need to accept the consequences of their own actions. The amount of manual steps necessary to take httpie private is fairly substantial. This person was careless and learned a lesson on being careless.

Based on your phrasing I’m still not sure if you understand parent—yes, the author had to type “httpie/httpie”, but due to GitHub’s user-level README repo feature, _that specific repo name_ conventionally would be a README repo, which is what the author was trying to delete. For example, my README repo is and must be called “glacials/glacials”; if I wanted to delete it that is what I would type, but if I were an orga…

Thank you for this explanation. I didn't know profile READMEs were a thing and have to be named the same as the user account. I can see how this could be confusing when the functionality is different between users and orgs.

Re: We lost 54k GitHub stars

#623

Post by mypalmike »

ncmncm wrote: post #423
mypalmike wrote: post #315

Earlier quoted context omitted.

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…

Quoted post unavailable.

A childish response.

Feel free to address the points that I and others have brought up.

Re: We lost 54k GitHub stars

#624

Post by user_7832 »

fourseventy wrote: post #527
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.

Couldn't agree more. The author not only messes up his own repo while blaming the GitHub UI, he proceeds to then whine that GitHub employees won't restore his data from a backup.

If it's a mistake that even a GitHub employee can make with very heavy consequences, is that entirely the fault of the author?

When Lauda Air Flight 004 crashed because the pilots accidentally deployed the reverse thrusters in air, even though it was the pilot who "made a mistake", Boeing was forced to change their design and now the original design is considered flawed.

Re: We lost 54k GitHub stars

#625

Post by kif »

kolanos wrote: post #607
yreg wrote: post #570

Earlier quoted context omitted.

I found this article interesting, exactly because "typing the name of the repo you want to make private before proceeding" seemed like a good solution to me as well. (Until now.) However, I can absolutely imagine doing the author's mistake and I think their UI improvement suggestion is great. To me the interface design lesson here is valuable. A recommendation to "check what repo you're in before taking destructive a…

It occurs to me that if your users are mindlessly doing repetitive things, no amount of "Are you sure?" or other hoop jumping is guaranteed to snap them out of it. Humans are pattern recognition machines. GitHub may be better off preventing a repo with this size of a following from being made private without a support request or something requiring a second party to confirm.

At my company, we had like 3-4 steps, each with clear wording to cancel a subscription, and they had to type something in the end to confirm. Guess what? We still had tickets asking to restore their subscriptions :)

Re: We lost 54k GitHub stars

#627

Post by behnamoh »

jjoonathan wrote: post #571
NoboruWataya wrote: post #569

> The problem is that the box looks exactly the same for repos with no commits and stars and for repos with a decade-long history and 55k stargazers and watchers. And it says “Warning: this is a potentially destructive action.” It seems a bit much to expect the website to show you a warning of different levels of severity depending on the stars a repos has, particularly when the standard message is pretty severe and…

> It even makes you type the name More and more IT systems are starting to do this for more and more tasks. I understand why: it's a hell of a lot easier than implementing a trashcan, timed undo, joining in helpful data, etc, but man, one good session with a couple hundred resources that need to be deleted this way is enough to burn you out pretty hard on these. Also, systems that go for these lazy solutions tend als…

> It even makes you type the name of the repo you want to make private before proceeding - I don't see how that wouldn't make anyone snap out of autopilot.

If you're using Github's CLI tool, you can autoconfirm repo deletion so that you won't have to type the name ever again. It seems like if Github were to change their UI, they would need to somehow change their API as well.

Re: We lost 54k GitHub stars

#628

Post by user_7832 »

throwaway0x7E6 wrote: post #406
aerovistae wrote: post #371

Earlier quoted context omitted.

They did admit they fucked up. Then they tried to make the best of it by looking for possible ways of preventing other people from repeating their mistake. What did you want? A blog post that says "I suck, I'm a failure, thanks for reading"? Why is this your response to someone trying to be contructive while post-morteming a failure?

the guy with 10+ experience of using github went to the "danger zone", pressed the red button, saw the very, very, very explicit warning about the consequences of pressing it and confirmed the action by explicitly typing the exact name of the repository. yes, that blog post would've been apt. as constructive as it gets. >Why is this your response because I don't want to send a notarized request every time I need to d…

> because I don't want to send a notarized request every time I need to delete a folder, format a disk or submit a SQL query

Aah yes, the only 2 extreme options, no/minimal warnings and extreme warnings. "Who needs rationality or subtlety on the internet anyway?"

Re: We lost 54k GitHub stars

#629

Post by judge2020 »

loa_in_ wrote: post #490
judge2020 wrote: post #316

Earlier quoted context omitted.

That's information disclosure; nothing about the repo after it's privated should be known, including name changes and deletion.

It was known and there are many sites scraping GH for metadata that will have it anyway

Not whether or not a repo exists after it's set private.

Re: We lost 54k GitHub stars

#630

Post by yreg »

kolanos wrote: post #607
yreg wrote: post #570

Earlier quoted context omitted.

I found this article interesting, exactly because "typing the name of the repo you want to make private before proceeding" seemed like a good solution to me as well. (Until now.) However, I can absolutely imagine doing the author's mistake and I think their UI improvement suggestion is great. To me the interface design lesson here is valuable. A recommendation to "check what repo you're in before taking destructive a…

It occurs to me that if your users are mindlessly doing repetitive things, no amount of "Are you sure?" or other hoop jumping is guaranteed to snap them out of it. Humans are pattern recognition machines. GitHub may be better off preventing a repo with this size of a following from being made private without a support request or something requiring a second party to confirm.

Yes. Someone elsewhere in this thread suggested that it could be improved to make it impossible to make the repo private before you delete all the stars somewhere else in the UI, therefore breaking out of the pattern.

Surely there are multiple solutions, but I think you distilled the essence well: make the truly dangerous action different to the learned repetition.

Post reply on HN