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.
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.