You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Maintaining ownership continuity: Explain criteria for transfering repositories to successor's account. #40673
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
Reacted by Karl Horky
Reacted by Arjun Saluja, grzegorz.kryczka86@gmail.co and Karl Horky
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.
changed the title [-]Maintaining ownership continuity: Explain criteria for account transfer.[/-][+]Maintaining ownership continuity: Explain criteria for transfering repositories to successor's account.[/+]on Oct 4, 2025
@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.
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.
@jokicdanijel Honestly, I suspect there's no concrete policy and exceptions would be managed on a case-by-case basis by contacting support, based on the extremely equivocal answers I've received. I'm fine with someone updating links to make sure all the information we have is properly cross-referenced and possibly updating the wording, but if you have a specific situation that you're dealing with right now, I would suggest contacting the support team. They might also help you with hypotheticals, I'm not sure, but what we have documented is our policy, and anything else would have to be negotiated with support individually.
If support can solve these cases in ways not defined in policy, the supporters would probably love to have hints from the account owner about how to deal with a stranger claiming to act on behalf of the account owner. We should consider and document some kind of safe deposit box for such hints. Maybe a standardized name for a private repo? I'm not sure though whether the security level of a regular repo is appropriate.
@mk-pmb That's something else you would have to discuss with support. The docs team just isn't equipped to handle decisions like that. I think it's at the point where I need to close this issue, unless you want to update some links to make things more discoverable, because all roads seem to lead back to support.
Yeah I guess here in docs we should focus on documenting the current state, update docs with the clarifications from above, and acknowledge the aspects that aren't decided yet. I won't soon have time to do that myself though.
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.
Thanks! Now people can at least find the relevant info at the very bottom. To waste even less of their time, we should clarify the very broad and promising intro sentence "… manage … repositories if you are not able to." to a wording that already spoilers that the tutorial below will only work for the most extreme subclass of that. For me, the most helpful honest wording would be a straight "if you die iRL"), but I see how other people may prefer a fluffier version. I hope we can still align it to the facts.
Activity
welcome commentedon Oct 3, 2025
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.
Sharra-writes commentedon Oct 3, 2025
@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?
mk-pmb commentedon Oct 4, 2025
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.
[-]Maintaining ownership continuity: Explain criteria for account transfer.[/-][+]Maintaining ownership continuity: Explain criteria for transfering repositories to successor's account.[/+]Sharra-writes commentedon Oct 6, 2025
@mk-pmb Gotcha! Thanks for clarifying. I'll go ask the appropriate team about this, and see if we need to update the docs.
Sharra-writes commentedon Oct 6, 2025
@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.
mk-pmb commentedon Oct 7, 2025
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.
jokicdanijel commentedon Oct 17, 2025
github-actions commentedon Nov 18, 2025
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.
mk-pmb commentedon Nov 19, 2025
3 remaining items
user1428282826372-cmyk commentedon Nov 23, 2025
github-actions commentedon Jan 6, 2026
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.
mk-pmb commentedon Jan 7, 2026
jokicdanijel commentedon Apr 4, 2026
Hi, just checking in on this.
Is there any update on whether the documentation will be clarified regarding:
Thanks!
Sharra-writes commentedon Apr 9, 2026
@jokicdanijel Honestly, I suspect there's no concrete policy and exceptions would be managed on a case-by-case basis by contacting support, based on the extremely equivocal answers I've received. I'm fine with someone updating links to make sure all the information we have is properly cross-referenced and possibly updating the wording, but if you have a specific situation that you're dealing with right now, I would suggest contacting the support team. They might also help you with hypotheticals, I'm not sure, but what we have documented is our policy, and anything else would have to be negotiated with support individually.
mk-pmb commentedon Apr 10, 2026
If support can solve these cases in ways not defined in policy, the supporters would probably love to have hints from the account owner about how to deal with a stranger claiming to act on behalf of the account owner. We should consider and document some kind of safe deposit box for such hints. Maybe a standardized name for a private repo? I'm not sure though whether the security level of a regular repo is appropriate.
Sharra-writes commentedon Apr 14, 2026
@mk-pmb That's something else you would have to discuss with support. The docs team just isn't equipped to handle decisions like that. I think it's at the point where I need to close this issue, unless you want to update some links to make things more discoverable, because all roads seem to lead back to support.
mk-pmb commentedon Apr 14, 2026
Yeah I guess here in docs we should focus on documenting the current state, update docs with the clarifications from above, and acknowledge the aspects that aren't decided yet. I won't soon have time to do that myself though.
Sharra-writes commentedon Apr 16, 2026
@mk-pmb I'll add a help wanted tag to this, to see if someone else wants to update the articles. To sum up: a link to About successors should be added to the bottom of Maintaining ownership continuity.
iselalopez975 commentedon Nov 6, 2026
mk-pmb commentedon Nov 6, 2026
Thanks! Now people can at least find the relevant info at the very bottom. To waste even less of their time, we should clarify the very broad and promising intro sentence "… manage … repositories if you are not able to." to a wording that already spoilers that the tutorial below will only work for the most extreme subclass of that. For me, the most helpful honest wording would be a straight "if you die iRL"), but I see how other people may prefer a fluffier version. I hope we can still align it to the facts.