Problem
Building on the discussion that was had in FluxDiscover, in the event that an owner of a community dissapeers (predominantly in larger ones that may be partnered/registered for discovery) then the community and it's staff currently can be left in the lurch with limited powers to maintain and govern itself. Initially Fluxer staff got involved to find a new owner amongst the available staff, but this was controversial and poses possible abuse concerns for the future.
Proposed solution
I posted this to allow the discussion to continue as Hampus suggested, but the idea of allowing the owner to define a succession plan in the event of their extended absence might be a good move. That way it doesn't necessarily need Fluxer/Instance staff to intervene and work out the best option.
Example of this might be that a server owner can opt in to have one or multiple users be elected as the new owner, falling back to the second, third, etc options depending on if they happen to be active at the time of the plan triggering. I realise this does come with some caveats for the owner too as the list would need maintenance to ensure it doesn't give the ownership to someone who is no longer trustworthy since the plan was set up. So perhaps users and roles could be used interchangeably to avoid it needing to be updated as much. That one is open to debate but thought I would share the idea.
Additionally other succession plan options might include instructions to set the community to read only after a set number of days, with notice being given to staff members via a system message in a moderator channel, or some other notification system. That way staff can plan ahead and consider if they need to "fork" the community. The owner may wish to keep invites turned on still to allow people to come and view the server, or turn them off completely perhaps.
Then alternatively instead of setting it to read only, they may with to have it deleted after a set number of days instead.
I do want to add that for private communities as well as smaller public communities, this would seem excessive which is why making it an opt in system would make sense. However for larger communities, it would also make sense to consider making this required to ensure there is a clear path forward. Alternatively this could be made a requirement for registration discovery instead.
I do think this solution still has flaws but hopefully theres enough ideas here to help build a working solution that suits what we all would need :)
2 comments
Comment by tempest:squll.fartcore.ai
Comment by @Pentagrade