Apart from it being clear that the UI and the user using it could have been better, I don’t agree with criticism like “GitHub should obviously do x” or “this would be easily resolved if the action didn’t caused cascading deletes” and so on.
GitHub is a large and complex set of applications, and making changes like that is probably not trivial. It’s probably not a high priority either. This is the first time I’ve heard of this in the existence of GitHub, and while that doesn’t mean it has only happened once, I suspect it’s rarely a meaningful issue.
Solving problems like this at GitHub’s scale is often hard both due to the need to do things that matter more, and due to how entrenched database schemas and application architectures tend to be. I’m sure their migrations are plenty scary to manage, and doing it to alter behaviour when toggling privacy on a repository understandably wouldn’t be high on their list of reasons to perform one.
Aside from those concerns, I bet there are a lot of lines of code which assume stars exist for specific reasons. Once they can exist for another reason, you have to rewrite logic around that, rewrite tests for that logic, etc. It could easily be way more work than it seems at a glance.
But.. one of their developers also made the same mistake as the OP. The OP learned a lesson but seemingly anyone at GitHub didn’t think, “we should fix this confirmation dialog so this doesn’t happen again”.
It’s also possible that they did consider it, but upon investigation it entailed more work than they could justify.
I do think including more context about what will be destroyed by the action would be great, and probably pragmatic, but… If typing out the name of the repository isn’t enough, providing context might not be either.
The more I think about it, the more it seems like one of those “Whatever, we’ve got a million other things to do” situations. It might get a handful of inquiries about it per year while a dozen other features get hammered with attention and requests from paying customers.
Again, not saying they can’t improve it. Just giving them the benefit of the doubt here and proposing that it’s possible that it isn’t better for legitimate reasons.
No doubt, and I’ve never worked on a team with these kind of resources so I can’t be certain either. I’m just advocating for the people at GitHub and casting doubt that it’s trivial to avoid situations like this or resolve them.
Should customers who have had a bad experience just not give any feedback then?
Github should be grateful for this feedback. I know that it takes effort to make your product or service better, but that doesn't mean that customers shouldn't ever say anything. Customers are telling Github how it can improve its service. Github can choose to listen to them, or not.
With some simple frontend changes, they can probably reduce accidental destructive changes to customer's accounts.
I think Github cut some corners here. I would much rather that repo stars were treated similar to how resources on other platforms are. If someone makes it private, then return 403 "repos is private"
GitHub is a large and complex set of applications, and making changes like that is probably not trivial. It’s probably not a high priority either. This is the first time I’ve heard of this in the existence of GitHub, and while that doesn’t mean it has only happened once, I suspect it’s rarely a meaningful issue.
Solving problems like this at GitHub’s scale is often hard both due to the need to do things that matter more, and due to how entrenched database schemas and application architectures tend to be. I’m sure their migrations are plenty scary to manage, and doing it to alter behaviour when toggling privacy on a repository understandably wouldn’t be high on their list of reasons to perform one.
Aside from those concerns, I bet there are a lot of lines of code which assume stars exist for specific reasons. Once they can exist for another reason, you have to rewrite logic around that, rewrite tests for that logic, etc. It could easily be way more work than it seems at a glance.