News for hackers. Stuff that matters.
Re:We lost 54k GitHub stars by icambron on Thursday April 14, 2022 @07:20PM (#31034737)
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.

Re:We lost 54k GitHub stars by mynameisvlad on Thursday April 14, 2022 @07:24PM (#31034771)
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.

Re:We lost 54k GitHub stars by whym on Thursday April 14, 2022 @10:16PM (#31036014)
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.

Re:We lost 54k GitHub stars by kevinforrestcon on Friday April 15, 2022 @01:49AM (#31036951)
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.

Re:We lost 54k GitHub stars by ncmncm on Thursday April 14, 2022 @08:39PM (#31035356)
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.
Re:We lost 54k GitHub stars by djur on Friday April 15, 2022 @01:21AM (#31036818)
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.
Re:We lost 54k GitHub stars by vidarh on Friday April 15, 2022 @04:38AM (#31037849)
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.
Re:We lost 54k GitHub stars by ncmncm on Friday April 15, 2022 @01:52AM (#31036965)
You did not read the comment you replied to. Why? And then, why reply?
Re:We lost 54k GitHub stars by everforward on Saturday April 16, 2022 @08:23PM (#31057304)
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.