5 ms·

When the repo goes private, people who can’t see it any more can’t have it in their list of starred repos.

by akerl_ 5y ago

tester756 5y ago
why not just do not display it and keep stars?
munk-a 5y ago
So mark the repo as private without their permission to view and have queries for starred repositories ignore repositories you can't view - that's an extremely frequent approach to take with complex permission and social functions. I completely understand that not everyone has time to build everything and software is an evolving process - but soft deletion for social links is my default state of mind (then you overlay it with indexing or caching or whatever your performance flavor is to make sure those soft deleted rows don't exist in the active query space).
- akerl_ 5y ago
  I mean, they totally could have built it that way. But they didn’t. I was answering why stars were removed. From a data complexity standpoint, it sounds like they decided they didn’t want to have to make calls to the authorization layer when parsing a user’s stars. The downside is the behavior seen when a repo goes private, but my bet is that repositories being made private is far less frequent than calls to get a list of starred repos.
  - munk-a 5y ago
    I totally get that - it's not an insane design decision it's just different from what my default suggestion would be. And to be honest - your source of truth database, on a system of this scale, is likely going to be detached from your pool of active data (possibly with some data shadowing, caching - what have you). The thing that throws me off is that they shot themselves with this footgun - whenever we (munk-a's employer) footgun ourselves we remove the footgun to prevent future footgunnery. They made the original design decision one way, and when they were burned by it they didn't re-examine it.
    - akerl_ 5y ago
      FWIW, if the blog post had centered around “GitHub, it’s strange to me that you made this mistake and didn’t reevaluate the root causes, and now I’ve made the mistake and it sucks”, I’d not be griping all over the comments here. It’s the framing that GitHub has inflicted a deep, irreparable wound to the author that I can’t reconcile with the facts.
  - Dylan16807 5y ago
    > From a data complexity standpoint, it sounds like they decided they didn’t want to have to make calls to the authorization layer when parsing a user’s stars. You can also solve that by adding a flag column, or putting privated stars in a different table. That tiny bit of denormalization shouldn't be more expensive than the current process, or the other costs of privating/unprivating a repo.
Dylan16807 5y ago
Why not? I think the respectful solution is to show it as "you starred X, it's private now, you can unstar if you like" (make sure if the name changes privately then the new name isn't shown). Such a solution is not only good in the case of mistakes like this, it also doesn't gaslight the person that starred a repo only for it to disappear from their list.
- munk-a 5y ago
  Or even make it so that those starrings that no longer have permissions to view the starred item just effectively don't exist because of data rules.
  - Dylan16807 5y ago
    That's bad because it lies to users and you can't remove the star when it's in that state.
    - munk-a 5y ago
      But if your star doesn't effectively exist why does that matter?
      - Dylan16807 5y ago
        Because if the star is merely hidden then the repo can come back later. If you don't want any association with that repo any more, it's bad that it can put itself back into your starred list.
- akerl_ 5y ago
  This may be the most hilarious misuse of “gaslight” that I’ve ever seen. If I publish something and you save the link and then I decide “nah, I don’t want that to be published”, I haven’t gaslit you.
  - Dylan16807 5y ago
mekster 5y ago
It's just bad design never getting fixed despite several prior incidents except for GitHub's own project which they reverted. Why do they not just give a public/private flag on star data than somehow modifying the data irreversibly? For users, just remove the repo from their starred project list if it's not visible.

When the repo goes private, people who can’t see it any more can’t have it in their list of starred repos.

by akerl_ 5y ago

When the repo goes private, people who can’t see it any more can’t have it in their list of starred repos.

tester756 5y ago

why not just do not display it and keep stars?

munk-a 5y ago

So mark the repo as private without their permission to view and have queries for starred repositories ignore repositories you can't view - that's an extremely frequent approach to take with complex permission and social functions. I completely understand that not everyone has time to build everything and software is an evolving process - but soft deletion for social links is my default state of mind (then you overlay it with indexing or caching or whatever your performance flavor is to make sure those soft deleted rows don't exist in the active query space).

akerl_ 5y ago
I mean, they totally could have built it that way. But they didn’t. I was answering why stars were removed. From a data complexity standpoint, it sounds like they decided they didn’t want to have to make calls to the authorization layer when parsing a user’s stars. The downside is the behavior seen when a repo goes private, but my bet is that repositories being made private is far less frequent than calls to get a list of starred repos.
- munk-a 5y ago
  I totally get that - it's not an insane design decision it's just different from what my default suggestion would be. And to be honest - your source of truth database, on a system of this scale, is likely going to be detached from your pool of active data (possibly with some data shadowing, caching - what have you). The thing that throws me off is that they shot themselves with this footgun - whenever we (munk-a's employer) footgun ourselves we remove the footgun to prevent future footgunnery. They made the original design decision one way, and when they were burned by it they didn't re-examine it.
  - akerl_ 5y ago
    FWIW, if the blog post had centered around “GitHub, it’s strange to me that you made this mistake and didn’t reevaluate the root causes, and now I’ve made the mistake and it sucks”, I’d not be griping all over the comments here. It’s the framing that GitHub has inflicted a deep, irreparable wound to the author that I can’t reconcile with the facts.
- Dylan16807 5y ago
  > From a data complexity standpoint, it sounds like they decided they didn’t want to have to make calls to the authorization layer when parsing a user’s stars. You can also solve that by adding a flag column, or putting privated stars in a different table. That tiny bit of denormalization shouldn't be more expensive than the current process, or the other costs of privating/unprivating a repo.

Dylan16807 5y ago

Why not? I think the respectful solution is to show it as "you starred X, it's private now, you can unstar if you like" (make sure if the name changes privately then the new name isn't shown). Such a solution is not only good in the case of mistakes like this, it also doesn't gaslight the person that starred a repo only for it to disappear from their list.

munk-a 5y ago
Or even make it so that those starrings that no longer have permissions to view the starred item just effectively don't exist because of data rules.
- Dylan16807 5y ago
  That's bad because it lies to users and you can't remove the star when it's in that state.
  - munk-a 5y ago
    But if your star doesn't effectively exist why does that matter?
    - Dylan16807 5y ago
      Because if the star is merely hidden then the repo can come back later. If you don't want any association with that repo any more, it's bad that it can put itself back into your starred list.
akerl_ 5y ago
This may be the most hilarious misuse of “gaslight” that I’ve ever seen. If I publish something and you save the link and then I decide “nah, I don’t want that to be published”, I haven’t gaslit you.
- Dylan16807 5y ago

mekster 5y ago

It's just bad design never getting fixed despite several prior incidents except for GitHub's own project which they reverted. Why do they not just give a public/private flag on star data than somehow modifying the data irreversibly? For users, just remove the repo from their starred project list if it's not visible.