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

171–180 of 697 posts

Re: We lost 54k GitHub stars

#171

Post by vaishnavsm »

metaltyphoon wrote: post #91
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'm not really sure how you'd do a "cascading soft delete" without making some kind of manual cascading logic? Perhaps the delete action is not accomplished right away and a column is checked. Then after a X amount of months a worker process goes around actually deleting things?

I meant to focus on the cascade part of the equation here. For example, lets say `stars` are foreign keyed (FKed henceforth) to repos, and (say) `X` are FKed to `stars`, and `Y` is FKed to `X`. Then if you do a "hard" delete of the repo status (or the stars), then we can set that to cascade to `X` and `Y` as well. Otoh, I don't think you can apply a cascade like that automatically when you're just changing a value (which is how a soft delete would be implemented, ig). Can you? Is there some really cool hook that allows this?

Re: We lost 54k GitHub stars

#172

Post by makeitdouble »

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…

On typing out the name of the resource, it is of course a way better check than just displaying it. I think it also was very efficient when there was only a few places using it, and the novelty made it attention focusing.

Thing is, we type all day, and can type pretty much any string at a decent speed without putting much thought into it.

Any of us must have mistakenly typed a full file path or API URL, just to realize it’s not the right machine or project after having typed it all. It just take 2 or 3s max after all.

I think it becomes an arms race to get attention on important things, we can do better by focusing more on every single destructive operation. We can also avoid having too similar interfaces for completely different contexts.

Re: We lost 54k GitHub stars

#173

Post by freedomben »

sam0x17 wrote: post #142
JadoJodo wrote: post #124

Earlier quoted context omitted.

I don’t know for certain but I feel like this could allow something like 1. Takeover/inherit public repo with lots of stars 2. Take repo private (retaining stars) 3. Replace repo code with some malicious/offensive code. 4. Take repo public again 5. Inherit the trust/prestige of the old repo.

Yeah but it's not like stars are seen as some amazing endorsement on the part of the individual starring. It's more like a favorites list if anything

stars absolutely are seen as an endorsement. I'm guilty of that for sure, and I've been in a ton of conversations about adopting some thing and the "number of stars" is often a consideration unless it's a project like React or Vue, etc.

Would you really not look at two repos that do the same thing, with similar ages and recent commits but one has zero stars and the other has hundreds, and not at least initially trust the latter more?

Re: We lost 54k GitHub stars

#174

Post by freedomben »

tshaddox wrote: post #132
FabHK wrote: post #90

Earlier quoted context omitted.

> I don't know what else they could have done to try to prevent it. As the author of the post suggests: Prominently spell out "This will remove 54,000 stars." vs. "This won't remove any stars (there are none yet)."

I'm not convinced that would have really solved the problem. One could just as easily post a screenshot of two nearly identical dialogs where the only different is that one says "This will remove 54 stars" and the other says "This will remove 54,000 stars" and the same argument could be made that "the only way to notice the difference is if you happen to notice those 3 zeros."

It seems like a pretty easy feature to build. No database changes required, and I wouldn't be surprised if the API already returns the star count for the repo so it's client-side only. I'd guess somebody could do it in a couple of hours (famous last words lol). I'd guess adding that feature would be less time/effort than restoring httpie's stars. A/B testing might be a little harder since conditions like OP's don't happen often, but you could at least do some testing.

Re: We lost 54k GitHub stars

#175

Post by [deleted] »

paxys wrote: post #9

"It's their fault, they only showed 5 warning banners. A 6th one would have totally stopped me from doing this." If a "type your repository name to confirm" box still doesn't make you double check that you picked the right repository, what else can they even do?

[deleted]

Re: We lost 54k GitHub stars

#176

Post by nosefrog »

Additional context: a GitHub employee addresses why they didn't do a backup restore in this tweet:

> Yup, all watchers go when you go private and a bunch of notification settings etc. We've tried re-staring projects in the past etc but that ends up breaking lots of peoples notification settings. It's something we should make more reversible but hard for reasons

> It's the reason we display this when you try to do it. But a better fix would be for us to make it more easily reversible in the future.

https://twitter.com/martinwoodward/status/149333649025189478...

Re: We lost 54k GitHub stars

#177

Post by ncmncm »

benjaminjackman wrote: post #110
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…

For Lesson 1: I think the general pattern that ought to be followed is to "prefer undo to warnings." Undo is often harder to implement, however it's usually a superior experience.

Even better, flipping "public/private" has absolutely no need to delete any information at all.

There could be separate buttons, "Delete all my stars", "Delete all my watches".

Re: We lost 54k GitHub stars

#178

Post by kortilla »

capableweb wrote: post #59
jakelazaroff wrote: post #27

GitHub made a cardinal UX design sin here: never use a warning when you mean undo [1]. If they had given even a five minute grace period before starting the irreversible process of removing all the watchers, this wouldn’t have happened. https://alistapart.com/article/neveruseawarning/

Which comes with its own problems. What if I just published something I wanted to be secret? Then I need to be able to switch it back to private, and it has to be quick, not after five minutes. Distributed systems with eventual consistency already make fixes like that hard, not to mention caches and whatever.

There is no undo there. 5 mins seems like a long time to you but to the bots that scrape GitHub repos for secret things, the time it took you to notice and reverse something yourself was already the time they needed.

If you made something public on GitHub that shouldn’t have been, it was immediately compromised, you just might not notice.

Re: We lost 54k GitHub stars

#179

Post by ccheney »

paxys wrote: post #9

"It's their fault, they only showed 5 warning banners. A 6th one would have totally stopped me from doing this." If a "type your repository name to confirm" box still doesn't make you double check that you picked the right repository, what else can they even do?

Also seems a bit suspect that they had a "perfect UI/UX example" to show how they would have handled these dialogs. Is this whole thing an advertisement for HTTPie?

Re: We lost 54k GitHub stars

#180

Post by freedomben »

mynameisvlad wrote: post #168
freedomben wrote: post #155

Earlier quoted context omitted.

that would break billions of scripts and confuse the hell out of hundreds of thousands or millions of users. Especially seems unnecessary since most distros ship an alias that makes the default `rm` command run with the `-I` or `-i` command.

> Especially seems unnecessary since most distros ship an alias that makes the default `rm` command run with the `-I` or `-i` command. I would say that makes things even worse . Because it's just training you to rely on -i/I as a sensible default. One day, you'll encounter that one distro that doesn't have that, and it'll be the time where you really wish it were.

Hmm, interesting point. I removed that alias early personally in favor of giving due respect to rm (especially with a `-r`!), which is probably an indicator in your favor.
Post reply on HN