I'll just toss in a "What sometimes happens" story for the good of the order.

One day a few years ago I got an IM from someone asking a question that a Group Owner would be able to answer. My response was "Beats me, I'm just a Member." They replied, "No, you're the Owner!" I checked the group Profile and, sho'nuff, there's my name. The Profile doesn’t show the previous owner, only the Creator, so there was no way to ask "Why me?" Only guess is that the Owner wanted to jump ship, saw that my first name is the same as the original Creator, and handed it to me. I found a friend to co-own with me and we've had it ever since

I don't know if this helps, but maybe emphasizes the need for a better way to do group transfers?

I believe the Lab can help with such issues if they can verify the situation and that the intention to take over is benevolent. I've seen examples of this, at least things that looked like this.

I'm not sure how your idea would work if not like that. Should the current group owner be able to choose names of group members as "successors" if the owner goes absent? Like a will? But when should that kick in? What if the chosen successor had left the group before they would inherit the group, or if they are inactive as well? How many successors could you choose? If you select several, how would be the order of succession established? Should this be all automated?

This brings up quite a few questions.

I think the general idea of this is important and it is an issue I think needs to be sorted. However the implementation can't just be to automatically promote any member retroactively. The reason for this is that store owners could loose access to their store groups if this would happen.

My suggestion would be to make it a toggle option in the group itself if management succession should be active or not, as well as adding options for setting a time limit on how long the group owner should be inactive before succession is activated and a priority list for who can take over, which could be either a list of names of specific people or anyone from a specific role.

This would sadly leave all old inactive groups in an inactive state, but it would prevent most currently active and new groups from turning inactive.

Thanks for writing this up — the need for a clear “leadership succession” path for long-inactive/legacy groups (where the owner/officers are gone and remaining members are stuck without the ability to manage or revive the group) has come up before.

We found your report is a duplicate of from (the Jira archive):

Because it matches the same underlying issue (how to handle groups whose leadership has effectively disappeared), we’re going to set this item to and associate your feedback with that existing request. We don’t have an ETA to share, but adding your specific use case—preserving a long-running group’s identity/lineage and enabling a safe, reversible takeover process when leadership is inactive—helps illustrate why this matters.

Thanks again for taking the time to document the scenario, especially with the long-term “inter-generational” angle for older groups.