[icambron]

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.

[mynameisvlad]

True "Undo" is, IMO, a pipe dream for all but brand new projects. That will pretty much require you to rearchitect a decent chunk of anything that wasn't built with it explicitly in mind.

In this case, I don't quite understand why stars and forks need to be deleted when switching visibility, since it seems like the two shouldn't be linked. I can star and fork my private repos just fine, so it seems like it was just easier to clear it out than to deal with RBAC at that level.

[whym]

I don't think any fork was deleted. 3.5k forks as of now vs 3.4k forks in January: https://web.archive.org/web/20220129022012/https://github.co...

Many people won't notice some of their stars having disappeared, but many would be surprised to see their forks deleted without their consent, especially those that are not merely a mirror. People can have diverged forks after adding substantial changes without feeding them back to the original for a variety of reasons.

[kevinforrestcon]

Then don't "do" the delete, when the users "do" the delete.

Pretend to do it, actually do it 24 hours later, and if they "undo" the delete within that time frame, just remove it from the delete queue process.

[ncmncm]

Just not deleting them in the first place, or not deleting them until explicitly asked to, would suffice, and would be, ultimately, less code. So, I am not buying the apologetics.

[djur]

It seems to me that services that pretend to delete data but don't actually do it are usually subject to criticism on Hacker News, not praise.

[vidarh]

The issue tend to be services who are not upfront about it. "This is potentially really damaging, so in case it's a mistake we'll just hide it for 24 hours during which you can undo" or something to that effect would be sufficient.

[ncmncm]

You did not read the comment you replied to. Why? And then, why reply?

[everforward]

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.