Do people use GitHub stars for something? Sometimes I star things but I have no idea what it does or why I do it.
It’s basically just a bookmark for yourself. And GitHub shows how many users have “bookmarked” a particular repository.
We lost 54k GitHub stars
211–220 of 697 posts
Re: We lost 54k GitHub stars
#212That'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.
I suppose you never take a backup because everything should be in ideal conditions.
If you consider manual errors as non existent, you need to rethink your design.
Re: We lost 54k GitHub stars
#213That'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.
What could the author have done with this post that would take it from being “blaming” into “giving feedback in an earnest intent to save others future pain”?
Drop passive aggressive comments like the one about how they're going to stop wearing their GitHub T-Shirt because of how GitHub subjected them to the same treatment that lesser and more unworthy projects would have received.
Even using words like "future pain" is pretty crazy. "We lost 54k GitHub stars"? They're imaginary internet points! Cope.
Re: We lost 54k GitHub stars
#214Earlier 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…
> It's easy to be an armchair engineer and say "well, obviously, don't make this mistake in the future".
It's sort of equally easy to say Github should do X or Y to improve the UX in this (rare?) case without actually knowing the effort or opportunity cost.
Like maybe I'd rather Github figure out how to not have outages so frequently and how to not accidentally give people million+ dollar bills and such.
Re: We lost 54k GitHub stars
#215Earlier 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…
Pretty much agree— Universal human fallibility is not an avoidable moral failure, but looking down on those who've made, admitted, and taken responsibility for simple mistakes sure is. Unrealistic assumptions about people's attention, processing capability, and physical capabilities may be the greatest hurdle when trying to actually solve people's problems with software. It can even be a safety issue— consider the Therac 25 incident.
That said, superlatives like "impossible" aren't realistic here. As long as an action is possible, it is also possible to fuck it up. The challenge screen does require typing in the repo name which is a pretty solid attention-getter. It would be nice to list the important side effects in big angry letters but I'll bet the list of side-effects that are important to some people would be pointlessly long. Maybe a sanity check requiring repos with extremes in certain metrics to get a sanity check from support first— but I have had some preeeeettty protracted response times from GitHub support.
Re: We lost 54k GitHub stars
#216What can you purchase with GitHub stars? More seriously, why do they matter? Is it a prestige thing only or are there practical consequences to losing the stars?
I sometimes decide what to use based on number of stars. It's a trust in the quality of the software.
Now httpie is on 2.5k stars and if I only knew about it today, I'd consider using an alternative with 10k stars if there's any.
Re: We lost 54k GitHub stars
#217Earlier 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…
Yeah. A warning that can be pattern matched by a human brain, that is just a routine action, will result in autopilot behavior. Flipping early repo visibility is common, I assume. Flipping visibility of 100+ star repos is likely much less common. So having a separate warning in that case might help you snap out of autopilot due to novelty.
A common knee-jerk reaction to "users aren't taking our warnings seriously" is making the warning look more scary and involving more (mechanical) steps – such as two confirmations instead of one. Well, that's pattern matchable and subject to desensitization.
Like the article states, it's more efficient to instead show what you're about to remove, i.e. a summary of the content as opposed to an identifier, then you get both novelty and proportional scariness, depending on how "big" it is.
Re: We lost 54k GitHub stars
#218Earlier 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.
My point is that IF they delete everything, they should send a notification to the affected users. When the repository is made public again, then since they deleted the star relation it’s not possible to send another notification.
Re: We lost 54k GitHub stars
#219Meta: why is the word "how" omitted from the title? I've seen this a couple of times recently and I don't understand why people are omitting words like "how" and "why." The only thing I see in the guidelines is about omitting "gratuitous" numbers and adjectives, neither of which "how" and "why" are.
The server automatically removes "how" and "why" at the start of a title. Numbers or at least 10 are also autoremoved.
Re: We lost 54k GitHub stars
#220That'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.
With that mindset, planes would still fall out of the sky every month. Because basically 90% of plane crashes used to be "pilot error". If you then say, well, it was pilot error, bad pilot, can't do anything about it, that's the way it is, pilot should've not made an error... well, then we wouldn't have reached the amazing aviation safety we have now.
I think there might be a difference between losing a plane and losing your “GitHub stars”.