If someone creates a community for their XMPP project, that should obviously be allowed. But what about tangentially related technologies or XMPP-focused general discussion communities? Eg. would an IETF KITTEN Working Group community be disallowed because it’s not specific to XMPP (not that they’re likely to create a group, I was just trying to think of something tangentially related)? What about a group to discuss XMPP Security or XMPP UX that’s not specifically tied to a project or group? It may be worth us developing a policy on this early on to stop conflicts before they arise and to stop having to grandfather in to many groups if we decide later that they’re out of scope.
I don’t know if a right of first refusal is a good idea just because the project maintainers won’t be able to police ever place users want to congregate. Eg. if users create a Telegram or Signal group chat about Prosody (that would be weird, but whatever it’s just an example) it would be a bit odd if the maintainer could shut that down; it’s just people chatting, after all. Similar logic applies here, in my mind. That being said, I wouldn’t want to get in a position where if the maintainer does want some official community space they have control over they end up creating a competing one here. Maybe we should moderate this on a case-by-case basis? Eg. if a project is created, the maintainer shows up and asks to be added as a mod, hopefully they just do it and if not we sit down and talk through why and if we still can’t come to an agreement only then do we make two groups and let the community decide? I don’t think we want to be in a position of verifying that project spaces are official either, but that is an alternative that might work.
To be clear, I’m not saying the project owner can shut anything down. Giving them first refusal just means that if someone wants a Prosody community, we first notify the Prosody developers to see if they want to lead that community. If they’re not interested and they decline, we grant ownership to the community member that requested it.
Ahh, fair enough; I could go either way on that one, but it does make more sense to me. I think the same logic applies though: the prosody developers wouldn’t necessarily be better stewards than a user, and if users make some other kind of group the prosody developers wouldn’t necessarily be able to excersize control over it. That’s not to say that our position can’t favor “official” project groups, I just can’t figure out if it’s a good idea or not.