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

311–320 of 697 posts

Re: We lost 54k GitHub stars

#311

Post by bawolff »

polote wrote: post #2

That's crazy that a manual error by someone, for whatever reason, end up being an article blaming Github for all sort of reasons. And never accepting that the thing that really failed here is the user who performed the action.

To borrow something from safety engineering - there is no such thing as an operator error, only bad user interfaces.

I definitely think this is github's fault for creating a system where an operator error is likely. OTOH stars are such a vanity metric that i can't be bothered to feel too sympathetic because who cares about stars?

Re: We lost 54k GitHub stars

#312

Post by njsubedi »

steve_adams_86 wrote: post #301

Apart from it being clear that the UI and the user using it could have been better, I don’t agree with criticism like “GitHub should obviously do x” or “this would be easily resolved if the action didn’t caused cascading deletes” and so on. GitHub is a large and complex set of applications, and making changes like that is probably not trivial. It’s probably not a high priority either. This is the first time I’ve hear…

But.. one of their developers also made the same mistake as the OP. The OP learned a lesson but seemingly anyone at GitHub didn’t think, “we should fix this confirmation dialog so this doesn’t happen again”.

Re: We lost 54k GitHub stars

#313

Post by alecbz »

WhyNotHugo wrote: post #238

This sounds like a great opportunity to move onto an open source platform to host this very popular open source tool. Their current hosts have even just proved that they don't care about them much -- only first party projects get special treatment.

Open source doesn’t mean direct access to the underlying data/databases. Self-hosted could work, but creates new problems like “are you sure your backups are working?”

Re: We lost 54k GitHub stars

#314

Post by lalopalota »

ncmncm wrote: post #208
layer8 wrote: post #203

Earlier quoted context omitted.

> silently I’d argue that GitHub should send them a notification that the repo they starred has been made private.

And another that it was made public again. Or neither, and just not delete shit that there was no need to delete.

The user said "delete this stuff". GitHub asked, "Are your sure?" User: "Yes".

Seems like a good reason to delete it.

Re: We lost 54k GitHub stars

#315

Post by mypalmike »

ncmncm wrote: post #186
metaltyphoon wrote: post #91

Earlier quoted context omitted.

> 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?

There is no need to delete anything at all. Set the "private" flag when the user asks for to make it private. Unset the "private" flag when they make it public again. If it is needful to be able to delete stars, make a separate button for that. But it is hard to imagine such a need.

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 if you engineer solutions to all the edge cases. Perhaps after this incident they will consider doing so. But it's certainly not as trivial as you imply.

Re: We lost 54k GitHub stars

#316

Post by judge2020 »

jedberg wrote: post #286
judge2020 wrote: post #282

Earlier quoted context omitted.

> the only difference is that you don't know if the repository still exists or not. If an admin were to private->delete, then all the stars referencing the report would stay and thus the reference to the repo would still be there, on GitHub's servers. There's a difference between GitHub storing things forever and third parties on the internet being a forever archive of visible pages.

But that's an easy fix. If they delete the repo, delete the stars. If they make it private, indicate it is now private in some way.

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

Re: We lost 54k GitHub stars

#318

Post by alecbz »

calcifer wrote: post #150
jacobolus wrote: post #138

Earlier quoted context omitted.

The origin of “gaslight” is a movie where a husband surreptitiously removes objects from the room, dims and brightens the lights, etc. and pretends the changes were just the wife’s imagination. https://en.wikipedia.org/wiki/Gaslight_(1944_film)#Plot Removing bookmarks from someone’s list without notification seems at least broadly comparable (in both cases, the victim is confused and might question their own memory,…

> albeit the action of an emotionless machine with a programming bug rather than a malicious human Yes, if you remove a major part of the definition (intent) then it can fit whatever you want it to fit. Like Gino D'Acampo most famously said [1], if my grandmother had wheels, she would have been a bike . [1] https://www.youtube.com/watch?v=A-RfHC91Ewc

I think it’s a fair use of the term. I’d maybe feel differently if there was a better term to use for “non-intentional gaslighting”, but afaik there isn’t really.

Re: We lost 54k GitHub stars

#319

Post by xyst »

Seems a bit too extra for me. You are literally typing in the fully qualified repo name you want to make private:

Please type httpie/.github to confirm.

vs

Please type httpie/httpie to confirm.

At some point, we are going to have to stop coddling the users.

Re: We lost 54k GitHub stars

#320

Post by mgdlbp »

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.

Making a private repo public could also be delayed.
Post reply on HN