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

681–690 of 697 posts

Re: We lost 54k GitHub stars

#681

Post by everforward »

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.

The counterpoint is that tools like that can be abused. Just as a hypothetical, if I have an open source product and do something the community doesn't like, I can make the repo private til the storm blows over so people can't un-star it. The number of people that remember to un-star it a week or two later is going to be a lot less.

I still think you're right, but it's not even as simple as UX and small backend changes. Allowing the repo owner to re-play other peoples' actions comes with complicated policy decisions. GitHub could make it so only support can restore those, but now they're in the awkward position of having to say when it's okay to restore and when it isn't. Still, it may be the best compromise.

Re: We lost 54k GitHub stars

#682

Post by alecbz »

mattcwilson wrote: post #675
alecbz wrote: post #666

Earlier quoted context omitted.

In terms of cause and effect yes, in terms of attribution no.

I’m sincerely struggling to understand - what is changed by referring to Github as the subject of the second sentence, as opposed to leaving out Github in the version you proposed?

It’s active voice vs passive voice.

People frequently use the passive voice when referring to how software works. Like, “I entered my PIN and the phone unlocked”. “I entered my PIN and the phone unlocked itself” is maybe common too, but less common is “I entered my PIN and iOS unlocked my phone” or “I enter my pin and Apple unlocked my phone”[0].

Using the active voice shifts responsibility and autonomy for the action away from the author and onto GitHub. (Which, I mean, is exactly what the author was trying to do I think. But we were talking about ways the post could be changed to do that less.)

[0]: This is confounded a bit by GitHub being both the name of the software and the company. In context though I believe they meant the company?

Re: We lost 54k GitHub stars

#683

Post by ahepp »

js2 wrote: post #232
cmeacham98 wrote: post #111

Earlier quoted context omitted.

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…

> 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". First of all, this is self-evident. But second of all and more importantly: it doesn’t scale. The reason we have blame-free postmortems is because people will always make mistakes,…

It’s not a “blame free postmortem” though. The author is blaming GitHub for not sending him a handwritten letter from the CEO inviting him not to do the stupid thing he positively affirmed he wanted to do.

The author also neglects to mention he had to type the full project name into a dialog box, which would be critical to any real postmortem. If typing the repo name into GitHub didn’t wake him up, why should we believe listing the number of stars would? The author said he thought he was in a different repo, but that makes no sense.

The real lesson, imo, is for people obsessed with stars to set up permissions, use dedicated accounts, and not toy around with settings you know are dangerous before you’ve had your coffee.

That’s a lot more reasonable than GitHub spending time to implement yet another warning box feature that the author has proved they can ignore regardless of how obvious GitHub makes it.

Re: We lost 54k GitHub stars

#684

Post by ric2b »

WalterBright wrote: post #196
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.

My favorite is "let's imprison people who make mistakes". It doesn't stop mistakes, it just covers them up.

Some mistakes are accidents, some mistakes are made on purpose.

The latter needs some kind of consequence in place to offset the benefits from purposefully making said mistakes.

Re: We lost 54k GitHub stars

#685

Post by ric2b »

bokwoon wrote: post #256
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 assume that the cascading done on GitHub would be done on a FK constraint GitHub doesn’t use foreign keys, the cascade delete must have been manually implemented. https://news.ycombinator.com/item?id=21486494

They use Rails, right? It's probably a cascade delete but done on the application, Rails makes that very easy.

Re: We lost 54k GitHub stars

#686

Post by sbarre »

farmerstan wrote: post #678
sbarre wrote: post #677

Earlier quoted context omitted.

If all you read out of that article was blaming, then you didn't read it very closely. The main takeway that I took from that article was the seemingly low effort improvement that could be made to the UI/UX of that action, which could help other people not make the same mistake. That's not about blaming Github vs. themselves, it's a reasonable critique of an existing system and looking for ways to make it better for…

You need to read more carefully. The author goes through great pains to ensure he doesn’t admit fault. Never once does he say “okay I admit, I should have been more careful.” He doesn’t take ownership ever over the fact that he made the mistake. He thinks this is all GitHub’s fault because of his misunderstanding and carelessness.

Not going to lie, this sounds like classic projection to me.

You must focus a lot on blaming in your life if that's what you mostly noticed when reading that article.

There's no way for either us to really know the author's intent or what he thinks - beyond the words on the page - but you seem convinced that "where the blame lies" was a major motivation, even thought it's all between the lines even by your own admission.

I read it differently, so as I said earlier, let's agree to disagree.

Re: We lost 54k GitHub stars

#687

Post by ric2b »

umvi wrote: post #274
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/

It's understandable why warnings are used instead of undos though. Warnings are dirt simple to implement - probably a single line of code in most languages. Undo is very complex by comparison. You have to flag something for deletion and put it into some sort of deletion queue that somehow gets deleted at some future date, etc.

Warnings can be done completely within the frontend, that probably makes them way more desirable for the company.

Re: We lost 54k GitHub stars

#688

Post by ric2b »

barrucadu wrote: post #576
hombre_fatal wrote: post #547

Earlier quoted context omitted.

Once you do it a few times, writing the repo names means nothing. You have to do it on your repo with 0 followers just making it public. It’s not very notable unless you’re new to Github. My advice is for Github to tell you that you’re losing 53,000 stars (not just “all your stars”) to help knock you out of autopilot. I don’t get the finger pointing though. Obviously they messed up, it’s the entire post. But it’s als…

What should the threshold be? 53,000 stars? 50,000 stars? 25,000? 100? No matter what number you pick, there will be someone with fewer stars who considers their stars important enough to merit a warning. Unless you set the threshold to 1, in which case it's just more meaningless noise, like the repository name (apparently) is.

Always show the number if it's more than 0. It's more informative and might catch your attention better than "something bad might happen"

Re: We lost 54k GitHub stars

#689

Post by js2 »

ahepp wrote: post #683
js2 wrote: post #232

Earlier quoted context omitted.

> 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". First of all, this is self-evident. But second of all and more importantly: it doesn’t scale. The reason we have blame-free postmortems is because people will always make mistakes,…

It’s not a “blame free postmortem” though. The author is blaming GitHub for not sending him a handwritten letter from the CEO inviting him not to do the stupid thing he positively affirmed he wanted to do. The author also neglects to mention he had to type the full project name into a dialog box, which would be critical to any real postmortem. If typing the repo name into GitHub didn’t wake him up, why should we beli…

The author is blaming GitHub for not sending him a handwritten letter from the CEO inviting him not to do the stupid thing he positively affirmed he wanted to do.

Please, quote from the article where you read this. I don't see it.

In the article I read, the author admits fault:

> I accidentally made the project’s repository private for a moment.

The author goes on to explain how they made the mistake.

> What put me on the wrong path was an otherwise completely unrelated action: I had just done the same (i.e., hidden an empty README) on my personal profile by making jakubroztocil/jakubroztocil private.

> GitHub’s conceptual model treats users and organizations as very similar entities when it comes to profiles and repos. In this context, and since I just wanted to repeat the same benign action on our organization’s profile, my brain switched to auto-pilot mode.

> I didn’t realize at the moment there’s an inconsistency in the naming of this special repo containing profile READMEs and that it differs for users and organizations: name/name vs. name/.github.

> That’s why I proceeded to make httpie/httpie private instead of httpie/.github without realizing my mistake.

The author does not attempt to hide or misrepresent the GitHub UI that requires confirmation. They show it for both "httpie/httpie" and "httpie/.github".

It does not matter that you have to type the repo name, because once you are on auto-pilot, you proceed past this step. In fact, the author doesn't admit it, but if he's like me, I'll bet they copy/pasted the name. Because the name alone is not sufficient.

The author then goes on to suggest what might have kicked him out of auto-pilot. Providing more information about the repo other than just its name. The name alone is NOT sufficient. And they author shows some example UIs from their own software.

Your suggestion: "The real lesson, imo, is for people obsessed with stars to set up permissions, use dedicated accounts, and not toy around with settings you know are dangerous before you’ve had your coffee."

This simply does not scale. It would require everyone to learn the same lesson for themselves.

I've been a sys admin and developer for over 25 years. People make mistakes. They make them all the time. Putting context-free (or minimal context in the case of the GitHub UI) "Are you sure?" dialogs in front of them does nothing to prevent mistakes.

All the author is asking for is a bit more context from the GitHub UI to help the user realize the significance of their action. This would help future GitHub users to avoid the same error.

Re: We lost 54k GitHub stars

#690

Post by vaishnavsm »

nine_k wrote: post #434
411111111111111 wrote: post #410

Earlier quoted context omitted.

> I assume that the cascading done on GitHub would be done on a FK constraint, but I'm not really sure how you'd do a "cascading soft delete" without making some kind of manual cascading logic? Couldn't you just use an on delete trigger for this? I have no experience one the subject however

An ON UPDATE trigger for the is_deleted column would do. Some databases also support INSTEAD OF triggers.

Doesn't ON UPDATE only work for foreign keys? As far as I know, it's used to update the foreign key itself, and not values based on relationships.
Post reply on HN