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

651–660 of 697 posts

Re: We lost 54k GitHub stars

#651

Post by tobr »

parkingrift wrote: post #583
dmitshur wrote: post #572

Earlier quoted context omitted.

I’m wondering if you got a chance to see this part of the post: > […] I obviously had no intention to make httpie/httpie private. So, why then? > > The proximate cause was that I thought I was inside a different repo; […] What I actually intended to do was to hide the HTTPie organization’s profile README, […] > > What put me on the wrong path was an otherwise completely unrelated action: I had just done the same (i.e…

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.

As a UX designer, I don’t understand this attitude. Clearly there are things GitHub could do to improve the design here. That doesn’t mean it’s GitHub’s fault, mistakes can always happen.

This screen gives you pretty poor context for your action. You can’t so easily see things that normally tell you at a glance where you are. They also don’t offer a good preview of the action, or undo, which is how you normally make potentially destructive actions less dangerous. Instead they made a scary prompt, but since they use that solution a lot, users may get desensitized to it.

Re: We lost 54k GitHub stars

#652

Post by bocytron »

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…

A developer at GH made the same mistake. It clearly means the UI is not working the way intended.

On one hand, there's a UI change GitHub could implement that would greatly prevent this situation from happening again. On the other hand, one could try warn every github users that this situation can happen and to be carefull... Well I have my opinion on which would be most effective.

Re: We lost 54k GitHub stars

#653

Post by pbhjpbhj »

hk__2 wrote: post #500
pbhjpbhj wrote: post #491

>"The same goes for stars. If you’re one of those 54K people who’ve starred the repo any time in the past decade, the repo is no longer among your starred projects." // This seems like bad design from a UX perspective. Projects I star are a characteristic of my account. If a project is made private, I still want to have the star in my account list; it feels almost like gaslighting to just remove a star.

> If a project is made private, I still want to have the star in my account list You can’t star a private project, so by definition you can’t "keep" a star on a project that went from public to private. That’s not bad design, that’s a logical behavior.

>so by definition you can’t "keep" a star on a project //

That doesn't seem to follow. It's not intrinsic, it's a design choice, surely.

Re: We lost 54k GitHub stars

#654

Post by SkyBelow »

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 often think scary popup boxes are enough to get people to think about what they're doing

This would entirely depend upon how often it shows up. The more often it shows up when the scare isn't relevant, the less people will pay attention to it.

>the distractions ("Type this repo's name", etc) just go away

I think it shows that what one types needs to be relevant information. In this case, due to the similarity between when the author would've been asked if they did what they were intending to do and what they typed to do what they actually did, we can judge the prompt isn't enough. If this also asked you to type in the number of git stars you were about to lose, that would've been enough to make author recheck exactly what they were doing.

Re: We lost 54k GitHub stars

#655

Post by prmoustache »

The real lesson I make of it is that we shouldn't use a cloud product or SaaS if vendor do not allow customer to request recovery or prevent the customer to manage its own backups. I know git is decentralized and no code is ever lost but github is so much more than git.

Backups aren't mean to recover from outages. They are also, and I would even dare saying mostly, used to recover from human mistakes. If the vendor terms and conditions don't allow this, github is not a production ready solution.

Re: We lost 54k GitHub stars

#656

Post by _asummers »

bspammer wrote: post #544
iforgotpassword wrote: post #502

Earlier quoted context omitted.

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.

They have a bunch of differences under the hood, particularly when you want to give perms. It makes sense, sort of, on its face, that a user can’t have teams, but why? That decision is pretty arbitrary, to me. Then in GHE, users and orgs have all sorts of fun differences when you consider things like internal/public/private and how people can interact with them; to wit, if you’re in ANY team you can see ANY internal repo in an org, but if you’re limited to just personal repos, you can see no such things.

Re: We lost 54k GitHub stars

#657

Post by ezfe »

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…

Factorio doesn't say "You'll lose unsaved changes" if you close the game immediately after saving, which is super nice.

The number of games that DO ask this question, immediately after saving, is ridiculously high it's so frustrating.

Re: We lost 54k GitHub stars

#658

Post by jacobsenscott »

swiftcoder wrote: post #489
jacobsenscott wrote: post #147

Earlier quoted context omitted.

Idk about "easily", but I'm sure they were motivated. If you've ever tried to restore parts of a database in a piecemeal fashion, it is usually fairly labor intensive. But you would hope there are a few gh engineers who would be motivated to do so without manager approval in the dead of night because httpie is great.

> But you would hope there are a few gh engineers who would be motivated to do so without manager approval in the dead of night because httpie is great On the other hand, you should really, really, really hope that GitHub has internal guardrails to prevent their engineers making cowboy edits to the production databases without manager approval.

Haven't worked there, but I assume one engineer just needs one other engineer to approve their PR. I would be pretty surprised if it was more robust that that.

Re: We lost 54k GitHub stars

#659

Post by metadat »

nilleo wrote: post #466
wodenokoto wrote: post #428

Earlier quoted context omitted.

You do lose the title, which is super annoying. "What did I used to have?" Super frustrating feeling. Here's a list of your favourite songs, but two are missing, have fun figuring out which two it is!

I recently discovered a neat trick that if you Google the url for the private video (you still have this in your list), you're likely to find the title of the video, therefore allowing you to at least figure out what it was and seek out a new video.

This works about half the time. It's better than nothing, but not great.

Re: We lost 54k GitHub stars

#660

Post by bmacho »

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 few to expect a website to show us which repository are we going to delete on the delete page, instead of hiding it (or not showing). Datas, charts, content, every info that it could gather, and it may matter. Name is not enough.

Also I believe that asking us every day the ridiculously braindead act, to copy a text from here to there is more harmful than it helps, it just sets people to autopilot mode. Although I don't have any measures.

Post reply on HN