Document what happens to issues / PRs / comments / etc a user has made on public repo's when their account is deleted / suspended / etc
Code of Conduct
- [x] I have read and agree to the GitHub Docs project's Code of Conduct
What article on docs.github.com is affected?
N/A; I tried searching for similar content but couldn't find any, so I think this would be a new entry.
What part(s) of the article would you like to see updated?
N/A; see above, I believe this might be an entirely new article.
Additional information
I recently noticed that some issues on a public repo I contribute to (but don't have direct repo access to) seemed to disappear; getting a 404 when I tried to access them. I also noticed that when I tried to view the user that contributed them, I also got a 404 for their profile.
I reached out to GitHub support to find out if the information in those issues was lost:
- https://support.github.com/ticket/personal/0/3664339
There is a public repo that I contribute to, and there was an issue that I know was previously visible, that now returns a 404:
- https://github.com/jehna/humanify/issues/84
Looking up the user that created that issue, they also 404 now:
- https://github.com/REDACTED
Yet looking at a different issue I created, that links to/references the now missing issue:
- https://github.com/jehna/humanify/issues/406#issue-3001092363
I can still see the title of the previous issue:
![]()
Why is that issue no longer visible / accessible to me? Is this a bug, or has the user deleted their account / been blocked by GitHub / similar (and if so, would that remove any issues / comments / etc they've made on public repo's like this?)
To which support replied:
Hello Glenn,
Thank you for contacting GitHub support. The issue is hidden, not deleted and this is due to the account status of the user who opened the issue, not a technical issue on GitHub's side. For privacy reasons, I cannot share more details, but would recommend the user in question reach out to support for additional information.
Please let me know if there is anything else I can help you with.
Kind regards, REDACTED
I then asked:
Thanks REDACTED; that makes sense.
I understand that you can’t speak about that individual user; but more generally; if a user account was deleted / similar; would that result in issues on public repos like this getting hidden / removed / similar? Or would they go into some sort of ‘unowned’ state but still exist.
The main reason I ask is I want to know whether the information on issues that account opened may end up ‘lost’ in an instance like that? (And if so; whether I may need to make regular backups of data submitted on issues to avoid the potential of that happening)
Thanks.
Glenn
Support then confirmed:
Hello Glenn,
Deleting the account would not remove or hide the associated issues.
Kind regards, REDACTED
Finally I asked:
Ok, cool, thanks for confirming that; good to know.
Are there any docs describing what situations would cause issues to disappear from a public repo like this?
And in this case, I'm not an owner/maintainer of the repo; but assuming something similar happened on a repo of mine, would I still be able to see the issues? Or would I also lose access to them until whatever was resolved on the user's side of things?
Basically we've ended up losing access to valuable information related to the project (possibly temporarily) due to this; and I want to understand what the 'risk factor' is for something like this happening again in future; particularly on repo's I own.
If I as a repo owner was still able to see those issues (and they were just not visible to random non-repo-admins), that would be far less concerning to me than if it was lost entirely.
I haven't yet heard back from support about that; but given I couldn't find any docs for it when I searched, I figured I would proactively open an issue here for it.
Another example I found on StackOverflow that would have benefitted from a more explicit GitHub docs page to reference was:
- https://stackoverflow.com/questions/40427127/github-what-happens-with-the-commits-if-the-user-is-removed/79734956
Basically, as an open source contributor, I want to understand under what circumstances I might lose access to issue contents / etc that are valuable for my project (or one that I am contributing to) when the user who created it is deleted / suspended / similar.
@0xdevalias I can definitely see why you would want to know about the risks for this question. I don't know what kind of priority level documenting it would be, but I'll check in and find out.
Thankyou @Sharra-writes 🖤
@0xdevalias I've talked to my manager about this. It's not something we would ever document exhaustively, certainly not in its own article, just because there are always going to be unknown variables and unforeseen circumstances, and we don't want to give the impression that we have all the risks figured out. But it is the kind of thing where we might document common scenarios in other articles as it seems appropriate.
Has Support gotten back to you about anything else? I'll take this to the issues team and see if they have any common scenarios they think it would be useful to document (or any objections to us documenting this stuff - that's possible, too).
Fun fact: we used to have a problem with 404s in this repo, because our method of transferring issues caused links to redirect to private GitHub repos, which OS contributors obviously can't access. We had to figure out a better way to handle it (and then make a workflow to do it).
It's not something we would ever document exhaustively ... there are always going to be unknown variables and unforeseen circumstances, and we don't want to give the impression that we have all the risks figured out
@Sharra-writes Understandable. I wasn't expecting a "here are all the possible ways that you might ever lose access to data"; but more of a "here are the known cases where you might lose access to it based on well-defined processes; and the expectations you should have around that".
it is the kind of thing where we might document common scenarios in other articles as it seems appropriate
@Sharra-writes This is in-line with what I was thinking of when I opened this issue 👌🏻
Has Support gotten back to you about anything else?
@Sharra-writes This was the last bits of that support ticket; so not really anything meaningfully more useful:
Glenn 'devalias' Grant commented last week
Are there any docs describing what situations would cause issues to disappear from a public repo like this?
I wasn't able to find any docs for it when I searched, so opened the following issue to request a new docs page covering situations like this for future:
https://github.com/github/docs/issues/39847
REDACTED commented last week
Hello Glenn,
There are not any docs related to this and the issues are hidden from everyone but the user who created them in this situation.
Kind regards, REDACTED
Glenn 'devalias' Grant commented last week
Fair enough. Thanks.
It honestly felt a bit 'cagey'; likely wanting to protect some privacy or similar related to the user and whatever situation connected to them caused those issues to become unavailable on the repo; which is understandable.
But also at the same time, from a user who's now lost relevant information perspective, it's sort of a not helpful response; akin to basically "yeah you lost it, no you can't know anything about it, who knows if you will ever get access to it again as it's entirely based on that user seemingly".
I'll take this to the issues team and see if they have any common scenarios they think it would be useful to document (or any objections to us documenting this stuff - that's possible, too).
@Sharra-writes Thanks, I appreciate it :)
A stale label has been added to this issue, because it has been open for 30 days with no activity. If you think this issue should remain open, please add a new comment.
A stale label has been added to this issue, because it has been open for 30 days with no activity. If you think this issue should remain open, please add a new comment.
I believe this is still relevant and shouldn't be marked as stale / inactive.