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

181–190 of 697 posts

Re: We lost 54k GitHub stars

#181

Post by ncmncm »

vaishnavsm wrote: post #153
ncmncm wrote: post #108

Earlier quoted context omitted.

> " that GitHub couldn't restore it " What an odd turn of phrase.

Not sure what you meant? Are you pointing out couldn't vs didn't ? If so, I didn't really think about it, although now that you point it out, I think didn't would've been a better fit. I'll edit it, thanks!

I mean "refused to". There was absolutely no value to Microsoft in refusing to restore the deleted information, and there was no practical reason to have deleted it at all. Ultimately, it just amounts to contempt.

Re: We lost 54k GitHub stars

#182

Post by cycomanic »

pharrington wrote: post #113
Brian_K_White wrote: post #97

Earlier quoted context omitted.

Reads article and somehow misses it's entire thoroughly examined point, chides author for not paying attention.

If I understood the blog post correctly, the author wants the "You will PERMANENTLY lose: All stars and watchers from the repository" to be changed to "[...] X stars and Y watchers ..." Which I agree would be a better UI.

Like so often we can easily judge this by how willing we would be to accept the same behaviour in real life and I'm pretty certain that most would not accept an UI where you could e.g. just give away your house by writing the wrong adress into some form.

Re: We lost 54k GitHub stars

#183

Post by icambron »

mynameisvlad wrote: post #163
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.

This, 1000x this. It's easy to be an armchair engineer and say "well, obviously, don't make this mistake in the future". As a species, we will always take shortcuts. If a mental pathway doesn't need to be exercised to do something, it won't be. If we see the same popup a hundred times, we're going to ignore the contents by the 100th time because we're used to it. But it shouldn't be possible to make this mistake if t…

That’s not quite it. The solution isn’t to stop them from doing it or warning them more aggressively; it’s to make it genuinely less dangerous. For example, make the stars all come back when you reverse the switch.

Of course that’s a lot harder to do, since it’s a lot more than a UX change. So I’m not really slagging GitHub here. But it’s the right way to attack this problem.

Re: We lost 54k GitHub stars

#184

Post by pwdisswordfish9 »

qbasic_forever wrote: post #49
sefrost wrote: post #3

It does strike me as unfair that GitHub themselves made the exact same mistake but were able to fix it with database backups.

I wonder how different the response from Github would be if this blog post was instead, "Oops, Github's confusing UI made me delete the entire project metadata... so since we're forced to start fresh we decided to move to Gitlab/sourcehut/etc."

There is no way in the world that the kind of person who writes a post like this and clearly places so much emphasis on gamified social media stats as a proxy for self-validation ever chooses to move to Sourcehut. No way. GitLab is most likely out of the question, too. The author of this post is exactly the kind of ideal customer for what GitHub is "selling" and that the others can't provide.

Re: We lost 54k GitHub stars

#185

Post by DryLabRebel »

caymanjim wrote: post #162

On the bright side, I had no idea this existed, and now I'm going to use it quite a bit. And evangelize it to coworkers, who probably also don't know it exists, or one of them would have used it during a pairing session. I doubt they'll get back to 54k stars (and really, who cares about stars?), but this will probably lead to a lot more new users.

Same!

Re: We lost 54k GitHub stars

#186

Post by ncmncm »

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?

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.

Re: We lost 54k GitHub stars

#187

Post by [deleted] »

JadoJodo wrote: post #124
bsuvc wrote: post #84

Sure, the author should be responsible. Yes, GitHub should have a better UX around this action. But... There is another thing to consider: Is it really necessary that a repo that is accidentally made private and then made public should lose its stars anyway? Is that really what the repo owner or the people who starred the repo even want to happen?

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.

[deleted]

Re: We lost 54k GitHub stars

#188

Post by ranman »

bsuvc wrote: post #84

Sure, the author should be responsible. Yes, GitHub should have a better UX around this action. But... There is another thing to consider: Is it really necessary that a repo that is accidentally made private and then made public should lose its stars anyway? Is that really what the repo owner or the people who starred the repo even want to happen?

1) probably not the desired experience

2) probably part of the currently required setup on their database side (triggers)

Features tend to evolve evolutionarily and certain data patterns are hard to invent around for security/privacy constraints. So err on the side of deleting rather than potential privacy/security bug.

Definitely fixable with some decent investigation, coding, etc. - but hard to prioritize.

Re: We lost 54k GitHub stars

#189

Post by mynameisvlad »

icambron wrote: post #183
mynameisvlad wrote: post #163

Earlier quoted context omitted.

This, 1000x this. It's easy to be an armchair engineer and say "well, obviously, don't make this mistake in the future". As a species, we will always take shortcuts. If a mental pathway doesn't need to be exercised to do something, it won't be. If we see the same popup a hundred times, we're going to ignore the contents by the 100th time because we're used to it. But it shouldn't be possible to make this mistake if t…

That’s not quite it. The solution isn’t to stop them from doing it or warning them more aggressively; it’s to make it genuinely less dangerous. For example, make the stars all come back when you reverse the switch. Of course that’s a lot harder to do, since it’s a lot more than a UX change. So I’m not really slagging GitHub here. But it’s the right way to attack this problem.

True "Undo" is, IMO, a pipe dream for all but brand new projects. That will pretty much require you to rearchitect a decent chunk of anything that wasn't built with it explicitly in mind.

In this case, I don't quite understand why stars and forks need to be deleted when switching visibility, since it seems like the two shouldn't be linked. I can star and fork my private repos just fine, so it seems like it was just easier to clear it out than to deal with RBAC at that level.

Re: We lost 54k GitHub stars

#190

Post by cycomanic »

paxys wrote: post #28
williamsmj wrote: post #16

https://rachelbythebay.com/w/2020/10/26/num/ makes a similar point. I don't remember us saying people only have themselves to blame when that article was posted ( https://news.ycombinator.com/item?id=24904204 ). Not sure why we're doing it on this post, which makes a number of completely reasonable and specific suggestions for improvement.

"Type a specific thing to confirm" (as suggested by the post you linked) is exactly what Github does for destructive actions. And the author still messed it up because they were on "autopilot". At that point the suggestions go beyond being reasonable.

So you never copy and pasted into dialog boxes? This is exactly the same thing as the Windows warning messages were they found that nobody reads the because they are being trained to click them away.

The main thing I really don't get is why it even needs to delete all the stars? It's not like they delete all comments/issues... by users who have been deleted. So why could they not simply make the star point to a "ghost repository"?

Post reply on HN