Maintaining ownership continuity: Explain criteria for transfering repositories to successor's account.
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?
Maintaining ownership continuity of your personal account's repositories
What part(s) of the article would you like to see updated?
The page says
You can invite someone to manage your user owned repositories if you are not able to.
…, but doesn't list or link to the exact criteria which would unlock the account repository transfer.
The GitHub Deceased User Policy may be relevant but it's not clear.
Also it should be explained whether this mechanism is the right one for having a friendly takeover in the case you're still alive but unable to react to your email for a defined minimum duration.
Additional information
No response
Thanks for opening this issue. A GitHub docs team member should be by to give feedback soon. In the meantime, please check out the contributing guidelines.
@mk-pmb Thanks for opening an issue! So, I think it would help if we separate out terms a little here, because I'm not actually sure what you're asking. An account is the overall user login and password that someone signs in with. The repositories they own are created under the account, and can be transferred to another account. Now, the article conflates managing repositories with owning them/transferring them to a new owner, which I don't think is the clearest language, but we'll use that as a definition, that managing is the same as owning.
All that said, the page you linked is about transferring repositories between accounts, not transferring accounts from one person to another. Does that help or did you find something on the page unclear?
Oh, I see. In that case the criteria that I was looking for were when exactly the repository transfers would be unlocked, i.e. under which conditions and circumstances my successor can request to have my repositories transfered to their (the successor's) account. I'll edit my opening post so later readers of this thread won't have that confusion.
@mk-pmb Gotcha! Thanks for clarifying. I'll go ask the appropriate team about this, and see if we need to update the docs.
@mk-pmb Digging in more, does any of this help you? According to this article, successors can claim a repository after presenting a death certificate for the original owner. If you're simply looking to transfer a repository, that doesn't require a successor.
Yes, thank you, the "About successors" section was informative. It would be nice to have that linked in the "Maintaining ownership continuity" article.
The "About successors" section could clarify whether presenting the listed legal documents are the only methods for a successor to legitimize their requests.
If so, the wording "if you are not able to" in "Maintaining ownership continuity" should be clarified to "if they can provide evidence of your passing" or similar.
My original interpretation of "if you are not able to", and what got my hopes up, was that it would be way more flexible, a time lock where a good friend can claim I were unable to access my account, GitHub challenges me, reminds me a few times, and if I'm unable to contradict within the set time (maybe I'm too ill in hospital), the friend would gain access.
Even if the "Maintaining ownership continuity" article is clarified that it's about death, the time lock idea is conceptually close enough that it might be a reader's next question. To save them the time of investigating, the article should therefor also include a note that (I assume) GitHub does not currently provide such a time-lock mechanism.
The "Transferring a repository" article describes a procedure that needs active confirmation on my side, and a short schedule (recipient must accept within a day), and in the wait time, decision authority is on the recipient. So while the effect is the same, all details of the approval process are opposite.
schirm teilen Führe das Installationsprogramm über die Statusleiste oder den Ordner "DownloadDISPLAY= /opt/google/chrome-remote-desktop/start-host --code="4/0AVGzR1Dn3967nTwuR-GbCM_u8yY9Rvhg4fcAYlul5WSQimVQDan9cgSu4U6niRoBxsbjdg" --redirect-url="https://remotedesktop.google.com/_/oauthredirect" --name=$(hostname)
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'm still interested in improving this.
@mk-pmb Sorry it took a while to remove that tag, I've been a bit sick this week and it's got me behind in my notifications.
No problem! No excuse was needed, an no reason to disclose health information (unless you want of course). I had expected that exchange to be a bot interaction anyway. The amount of readers in any given notification queue is a platform organization issue, so I'd never have held that against you as a person anyway.
Way
On Sat, Nov 22, 2025, 10:24 PM M.K. @.***> wrote:
mk-pmb left a comment (github/docs#40673) https://github.com/github/docs/issues/40673#issuecomment-3566905987
No problem! No excuse was needed, an no reason to disclose health information (unless you want of course). I had expected that exchange to be a bot interaction anyway. The amount of readers in any given notification queue is a platform organization issue, so I'd never have held that against you as a person anyway.
— Reply to this email directly, view it on GitHub https://github.com/github/docs/issues/40673#issuecomment-3566905987, or unsubscribe https://github.com/notifications/unsubscribe-auth/BYQXUVJRJUZN2YPORDEBNP336CL3ZAVCNFSM6AAAAACIGWW7N6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKNRWHEYDKOJYG4 . You are receiving this because you are subscribed to this thread.Message ID: @.***>