Accept or Decline
Successor has a set timeframe to accept. If declined, it moves to the next in line
Role Transfer
Upon acceptance, maintainer rights and SLAs are automatically transferred
Testament Shared
Your private instructions and documentation are shared with the new maintainer
Community Notified
Repository badge updates and community is informed of the transition from the badge
FEATURES
What exactly does "inactivity" mean, and what activity counts to prevent the trigger?
Inactivity is entirely defined by the Maintainer during setup (e.g., "6 weeks with no code commits on the main branch"). The system continuously monitors the linked repository metrics (commits, pull requests, issue responses, etc.) based on your chosen criteria. When the threshold is nearing, you'll get a reminder with a specific link that lets you confirm activity with a single click, resetting the timer without needing a code push. Number of reminders are set by you.
What if the Maintainer receives a reminder but is unable to respond (e.g., medical emergency)?
As the system is designed to send out multiple reminders before progressing to succession, it is meant to handle these kind of scenarios. If the Maintainer still misses all specified reminders over the set period, the system will however proceed to the next step: attempting succession. A succession is only finalized after the Maintainer has had opportunity to respond to the reminders.
Does Auto-Successor transfer the legal ownership or copyright of my code?
No. Auto-Successor only transfers the Maintainer role (administrative privileges, such as merge rights and GitHub organization control) and the Testament (your instructions). It operates strictly within the terms of your project's existing Open Source License (e.g., MIT, GPL). The copyright and code ownership remain governed by your original license and contributor agreements (CLAs).
What happens if the first Successor declines the role?
If the first Successor declines the role or fails to accept within the specified window (e.g., 2 weeks), the request is automatically transferred to the second person in the defined Succession Order. This escalation continues down your list of up to five candidates until one accepts or the list is exhausted.
Can I set up Auto-Successor to transfer maintenance to a GitHub Organization instead of an individual?
Yes. We recommend setting up a small GitHub Organization to be the primary Successor. This prevents future single-point-of-failure issues, as the Organization's access can be managed by a team, ensuring greater project longevity and stability.
Will the public display of Successors' profiles put them at risk or pressure?
The Auto-Successor badge only displays the candidate's GitHub ID and a link to their profile. This is a necessary transparency measure to build community trust. By confirming their role, Successors agree to this limited visibility. It acts as a positive signal that they have been vetted and are prepared for the responsibility.
How does the system handle transferring SLAs or commercial agreements?
The Service acts as a notification facilitator. When Auto-Succession is triggered, the Testament can contain explicit instructions regarding the transfer of any associated Support Level Agreements (SLAs) or contracts. It is the responsibility of the new Maintainer and the external party to legally finalize that transfer, but our system ensures the instructions and handover process are executed. We plan however to look further into an integrated transfer of SLAs in the near future.
What happens if all my listed Successors are also inactive or decline?
If all five designated Successors decline or do not respond, the system will notify the original Maintainer (if possible) and archive the Auto-Successor configuration. The project remains unmaintained, but the public badge will indicate that the succession plan has been exhausted, providing transparency to the user community before any further action (like a community fork) is required.