[ncmncm]

There is no need to delete anything at all. Set the "private" flag when the user asks for to make it private. Unset the "private" flag when they make it public again.

If it is needful to be able to delete stars, make a separate button for that. But it is hard to imagine such a need.

[mypalmike]

Stop. You've said the same thing a dozen times in this thread. Besides being repetitive, you're overlooking the obvious fact that having associations from non members of private repos to those repos is problematic. At the very least at the UI level, maintaining known dead internal links is bad form. So you'd be creating edge cases for the UI and probably numerous places deeper in the tech stack as well. Which is fine if you engineer solutions to all the edge cases. Perhaps after this incident they will consider doing so. But it's certainly not as trivial as you imply.

[fer]

Mmh? Maybe it's because I've never touched frontend professionally in my life, but I think that if you're doing it in the UI you're doing it VERY wrong.

This logic should be purely in the DB model or very close to it. In any case the internal API should never ever list private repos of an organization a user isn't a member of, period. Stars or no stars. Follows or no follows. Why should it? There's no corner case here, if stars pose a problem, the problem isn't the stars, it's a defective model behind. Hiding things that aren't meant to be seen in the UI means putting business logic in the UI. Just don't.

[mypalmike]

Fair point. My intent was to point out the UX would be broken. But you're right, the data model that backs that UX is what would have to change.