8 ms·
Sure, the author should be responsible. Yes, GitHub should have a better UX around this action. But... There is another thing to consider: Is it really nece
by bsuvc 5y ago
Sure, the author should be responsible.
Yes, GitHub should have a better UX around this action.
But...
There is another thing to consider:
Is it really necessary that a repo that is accidentally made private and then made public should lose its stars anyway?
Is that really what the repo owner or the people who starred the repo even want to happen?
- GnomeSaiyan 5y agoAgreed. This just screams bad UX on a corner case.
- JadoJodo 5y agoI don’t know for certain but I feel like this could allow something like 1. Takeover/inherit public repo with lots of stars 2. Take repo private (retaining stars) 3. Replace repo code with some malicious/offensive code. 4. Take repo public again 5. Inherit the trust/prestige of the old repo.
- sam0x17 5y agoYeah but it's not like stars are seen as some amazing endorsement on the part of the individual starring. It's more like a favorites list if anything
- freedomben 5y agostars absolutely are seen as an endorsement. I'm guilty of that for sure, and I've been in a ton of conversations about adopting some thing and the "number of stars" is often a consideration unless it's a project like React or Vue, etc. Would you really not look at two repos that do the same thing, with similar ages and recent commits but one has zero stars and the other has hundreds, and not at least initially trust the latter more?
- ninkendo 5y agoYou can do that without the “making it private and public again” part anyway.
- V__ 5y agoBut couldn't the same be achieved without taking it private?
- notreallyserio 5y agoYeah, that's a risk. They could mitigate it by allowing you to revert all branches/tags back to the pre-private state, but we're getting more and more complicated here.
- deleted 5y ago[deleted]
- ranman 5y ago1) probably not the desired experience 2) probably part of the currently required setup on their database side (triggers) Features tend to evolve evolutionarily and certain data patterns are hard to invent around for security/privacy constraints. So err on the side of deleting rather than potential privacy/security bug. Definitely fixable with some decent investigation, coding, etc. - but hard to prioritize.
- DryLabRebel 5y agoI think this is getting at the more robust solution. When youtube videos are taken down or made private, they are not deleted necessarily from my playlists. There's simply an indicator that they video is 'no longer available'. I don't see why something similar can't be the behaviour for GitHub stars and watches?
- wodenokoto 5y agoYou do lose the title, which is super annoying. "What did I used to have?" Super frustrating feeling. Here's a list of your favourite songs, but two are missing, have fun figuring out which two it is!
- nilleo 5y agoI recently discovered a neat trick that if you Google the url for the private video (you still have this in your list), you're likely to find the title of the video, therefore allowing you to at least figure out what it was and seek out a new video.
- diego_sandoval 5y agoLet's assume that the stars don't go away when the repo is made private. There are a couple of options: - The users can still see all their stars and find the private repo, which makes it not private. - The users can't see all their stars, they can only see their stars for the public repos. There's no way to find or unstar a private repo that you starred while it was public. This would lead to the situation that if you unstar everything and make sure you have zero stars, you could wake up the next week with 1 starred repos, and then with 3 starred repos, because some repos went public again. - The users can see all their stars, but the private ones lead to a 404, which would be perplexing for a greater number of people than the current behavior. - All private repos that have been public at least once lead to a "this repo is now private" message, that would in practice allow anyone to make an index of all the private repos that were public at least once. And it would also allow anyone to know when a private repo that was private at least once is deleted. I think the current behaviour is better than all of these options.
- XCSme 5y ago> The users can still see all their stars and find the private repo, which makes it not private. Why seeing a start you made for a previously public repository makes it not private? People remember things too, there's also the webarchive. You should be able to unstar it or keep your star, the only difference is that you don't know if the repository still exists or not.
- judge2020 5y ago> the only difference is that you don't know if the repository still exists or not. If an admin were to private->delete, then all the stars referencing the report would stay and thus the reference to the repo would still be there, on GitHub's servers. There's a difference between GitHub storing things forever and third parties on the internet being a forever archive of visible pages.
- jedberg 5y agoBut that's an easy fix. If they delete the repo, delete the stars. If they make it private, indicate it is now private in some way.
- ozim 5y agoTotally agree - cascade delete is such a nice thing - until it is not. Technically you want to delete dependent stuff, but in this case this seems like overstepping on development side.