We lost 54k GitHub stars • Hacker News Board

Re: We lost 54k GitHub stars

#71

Post by epidemian » Thu, Apr 14, 2022, 10:29 PM UTC

pluc wrote: post #21

You didn't lose anything, you asked for it to be removed by setting your repository private, albeit mistakenly. Something that is public (stars) cannot coexist with something that is private (your repo), otherwise unexpected things start to happen or you need to write a bunch of pointless edge cases. It makes sense. So does this article, but it should be a "lesson learned" and not a "GitHub fucked us" angle cause it…

This is a similar attitude to blaming users who close an program without saving, telling them it's their fault; the program even asked if they really wanted to close without saving!

But, it's also totally possible for a program to store a backup, and let the user restore that the next time they open the program in desperation for not having saved their document in a moment of distraction.

> but it should be a "lesson learned"

Yes. And as the article notes, the lesson can be that software and UX can be make to accommodate better for possible user mistakes. I personally think it's nice to have Undo actions, or some ways to revert possible mistakes. It makes software way less scary :)

Re: We lost 54k GitHub stars

#72

Post by Dylan16807 » Thu, Apr 14, 2022, 10:29 PM UTC

akerl_ wrote: post #42

munk-a wrote: post #19

Earlier quoted context omitted.

So mark the repo as private without their permission to view and have queries for starred repositories ignore repositories you can't view - that's an extremely frequent approach to take with complex permission and social functions. I completely understand that not everyone has time to build everything and software is an evolving process - but soft deletion for social links is my default state of mind (then you overla…

I mean, they totally could have built it that way. But they didn’t. I was answering why stars were removed. From a data complexity standpoint, it sounds like they decided they didn’t want to have to make calls to the authorization layer when parsing a user’s stars. The downside is the behavior seen when a repo goes private, but my bet is that repositories being made private is far less frequent than calls to get a li…

> From a data complexity standpoint, it sounds like they decided they didn’t want to have to make calls to the authorization layer when parsing a user’s stars.

You can also solve that by adding a flag column, or putting privated stars in a different table. That tiny bit of denormalization shouldn't be more expensive than the current process, or the other costs of privating/unprivating a repo.

Re: We lost 54k GitHub stars

#73

Post by nkozyra » Thu, Apr 14, 2022, 10:29 PM UTC

pizza234 wrote: post #43

spiderice wrote: post #5

Earlier quoted context omitted.

I have no dog in the fight here, and no affiliation to HTTPie, but this definitely seems like a Github issue to me. You can't just give users ways to easily and accidentally shoot themselves in the foot, and then blame the user for shooting themselves in the foot.

It's not so easy to make this accident - one needs to type the full name of the repository. AWS does the same, for example, when deleting RDS instances, and I find it effective.

Yeah. I'm not sure what else you can do with warnings other than make the person effectively recite back the thing they're doing.

Re: We lost 54k GitHub stars

#74

Post by googlryas » Thu, Apr 14, 2022, 10:30 PM UTC

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?

Note the repository names here are "httpie/httpie" and "httpie/.github". I don't use github(but I do use git), but the difference between the two is not exactly clear to me.

They could show you the number of stars, follows, commits, creation date, the number of files, all sorts of things.

Also, note that github themselves accidentally set one of their repos to private, but restored it to a previous state through backups. If the move is so boneheaded, why did github make it themselves?

A better question might be why, after making the mistake(which was big enough for the CEO to tweet about), and restoring from backups, they didn't just fix the glitch and prevent this sort of behavior.

Re: We lost 54k GitHub stars

#75

Post by w-m » Thu, Apr 14, 2022, 10:30 PM UTC

phphphphp wrote: post #32

pizza234 wrote: post #25

The post is omitting that the user must type the name of the repository in full; in this case, they typed `httpie/httpie`. If one is in such a deep autopilot state, no amount of warnings will work.

Does anybody actually type those? They were a neat solution 10 years ago but they’re so common now for even inconsequential actions that I always copy and paste, on complete autopilot.

I came across such a prompt maybe three times total in my life, all of them making GitHub repos public or private, or deleting them. Made me stop completely in my track. So it seems to be very much dependent on what you do day to day.

Re: We lost 54k GitHub stars

#76

Post by qbasic_forever » Thu, Apr 14, 2022, 10:31 PM UTC

pizza234 wrote: post #25

The post is omitting that the user must type the name of the repository in full; in this case, they typed `httpie/httpie`. If one is in such a deep autopilot state, no amount of warnings will work.

They address that in the post. Github treats organization accounts differently from personal accounts, and what would have worked perfectly fine and expected for a personal user account actually impacted a different and unexpected repo for an organization account. I would wager 99% of Github users would make a similar mistake in the same situation since they rarely deal with organization accounts directly.

Re: We lost 54k GitHub stars

#77

Post by hnlmorg » Thu, Apr 14, 2022, 10:31 PM UTC

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?

I’ve never liked those “type this string to confirm” dialogs. It doesn’t actually tell me what I’m confirming aside from the name of it (and names are easy to get muddled up if you’re tired or rushing through something). What’s more, dialogs like that encourage people to copy/paste those often long strings, which completely sidesteps the diligence they’re trying to encourage.

Whether you agree with the tone of that article or not, the UI suggestions made are sensible. Showing the contents of the repo you’re about to change is a lot more useful than asking someone to type the name of it.

Re: We lost 54k GitHub stars

#78

Post by akerl_ » Thu, Apr 14, 2022, 10:31 PM UTC

munk-a wrote: post #65

akerl_ wrote: post #42

Earlier quoted context omitted.

I mean, they totally could have built it that way. But they didn’t. I was answering why stars were removed. From a data complexity standpoint, it sounds like they decided they didn’t want to have to make calls to the authorization layer when parsing a user’s stars. The downside is the behavior seen when a repo goes private, but my bet is that repositories being made private is far less frequent than calls to get a li…

I totally get that - it's not an insane design decision it's just different from what my default suggestion would be. And to be honest - your source of truth database, on a system of this scale, is likely going to be detached from your pool of active data (possibly with some data shadowing, caching - what have you). The thing that throws me off is that they shot themselves with this footgun - whenever we (munk-a's em…

FWIW, if the blog post had centered around “GitHub, it’s strange to me that you made this mistake and didn’t reevaluate the root causes, and now I’ve made the mistake and it sucks”, I’d not be griping all over the comments here.

It’s the framing that GitHub has inflicted a deep, irreparable wound to the author that I can’t reconcile with the facts.

Re: We lost 54k GitHub stars

#79

Post by pharrington » Thu, Apr 14, 2022, 10:31 PM UTC

sbarre wrote: post #29

farmerstan wrote: post #26

Earlier quoted context omitted.

I came in to say precisely this. It’s easy to point fingers after the fact but probably the person wouldn’t have checked regardless of the message in the dialog box. “They warned me but because I didn’t read the dialog box because it was too boring!

if you RTFA he did actually read the dialog box (which is where he found out that it would delete the stars) he just didn't notice the 1 line in a 30+ line generic modal. He accepts responsibility for what he did, but points out the very real opportunity to improve the UI/UX of a very destructive operation with real contextual data about what is about to be destroyed.

You can only confirm the dialog box by typing in that line you're saying he didn't notice.

Re: We lost 54k GitHub stars

#80

Post by pessimizer » Thu, Apr 14, 2022, 10:31 PM UTC

akerl_ wrote: post #8

spiderice wrote: post #5

Earlier quoted context omitted.

I have no dog in the fight here, and no affiliation to HTTPie, but this definitely seems like a Github issue to me. You can't just give users ways to easily and accidentally shoot themselves in the foot, and then blame the user for shooting themselves in the foot.

Who got shot in the foot here? The article keeps talking about killing 55 thousand people. I’m trying to grok why “unstarring the repo” is such an earthshattering thing. It’s annoying if you wanted it starred / wanted notifications, because you have to notice and redo it… but there’s no irreparable harm, no data loss. This reads like somebody was placing way too much personal mental value on “the repo for my project…

> there’s no irreparable harm, no data loss.

There's a repo-user join table that is gone. That's literal data loss. If I delete your contacts, is that data loss? I mean, you still have your phone and all your ex-contacts still have phone numbers.