221–230 of 697 posts
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.
Earlier quoted context omitted.
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.
Why do they even delete those stars?
When the repo goes private, people who can’t see it any more can’t have it in their list of starred repos.
Why do they not just give a public/private flag on star data than somehow modifying the data irreversibly?
For users, just remove the repo from their starred project list if it's not visible.
Why care? Stars don't mean anything, save for the few people who organise the software they use by starring it. Certainly it's not a community owned by the maintainers. I don't own a connection with the people that upvoted this post, and stars mean exactly the same (effectively nothing).
But GitHub, by design, seeks to be as much of a social network as a repository hosting service and people take the stars very seriously. I’ve seen many CVs that brag about the candidate’s star counts.
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 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 is applicable to almost any activity: "Sure he was driving drunk, but the car's manufacturer should have prevented that from causing any damage!" I agree that GitHub should improve the design here - privating a '10 star / 1 week old' repo shouldn't be treated the same as privating a '50k star / 10 year old' repo. I don't mean to diminish the fact that GitHub's UI should be improved here.
But the author needs to take some responsibility and realize they were ""driving distracted"", and not act like GitHub is 100% at fault here. Just because GitHub didn't act perfectly doesn't mean the author didn't make any mistakes.
Earlier quoted context omitted.
Yeah, I also found that tone sort of jarring, but they do bring up a good point; the warning banner and inputs should be contextual and having to input the number of things affected would be a UI improvement. And I can understand why they would write this in anger/frustration.
I’m curious which statements from the article carried that tone?
>>"To paraphrase, the box tells you “You’re about to demolish a house. If there are any people inside, they will all die”. But it doesn’t include anything specific to break you out of your auto-pilot mode if you’ve confused the address and think you’re looking at an empty house."
>>"The dialog should be more contextual and, paraphrasing again, it should say “You’re about to kill 55,000 people.” That would’ve certainly made me pause."
Theres something about the juxtaposition that makes it feel like it should have been obvious. I think its because in those examples you would blame whoever didn't put whatever guard rail was necessary to prevent those outcomes. My suspicion is that it wasn't the authors intent and they were probably just upset, but thats an opinion I formed after reading the rest.
This happened to me as well. It's sad that GitHub doesn't retain that data.
My faith in their tech department is falling when they can't fix such a small issue.
Earlier quoted context omitted.
> That comparison spot the difference pic is really scary. I had to check it 2 times myself before I could spot that the last line is different. That's not the only difference. The other difference is that you also have to type the full repository name, including the organization name. If they wanted to delete the correct repository, they would have to type httpie/.github, but instead they typed httpie/httpie. It's u…
> That's not the only difference. The other difference is that you also have to type the full repository name, including the organization name. This is not true. We had an internal tool at a previous job that required you to type the name of a service's cluster into a field before deleting it. Automated deployments sometimes got left behind - and users would go in periodically and clean them up. If you watched folks,…
You and most of the rest of us, I suspect. Like I want to type that out every time...
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". I don't know. Github employees themselves have made this mistake as outlined in the post, and they were easily able to recover from it, which probably lowered the priority on chang…
Obviously it would be nice to see A similar response from GitHub regardless of whether the issue at hand is affecting themselves versus a member of their community. But, as long as humans are making the decisions, that’s probably a pipe dream. And honestly, policing could very well be the standard example of this.
It does strike me as unfair that GitHub themselves made the exact same mistake but were able to fix it with database backups.
I'm just surprised that after going through that pain themselves they didn't decide to revise how that social linking data is handled. A lot of github content is softly deleted by necessity, you couldn't nuke tickets written by a now non-existent user or unmerge PRs so this isn't really a new concept to the team. I don't think it's surprising they'd do such a thing for themselves and not a customer - I'm more surpris…