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 think it needs “unofficial” in the name, it’s not like that on reddit and other social media as well, right? Also what @poVoq@lemmy.ml says
That’s a fair point; it’s for discussion whether it’s an official venue or not and in general there’s no reason it should have better discussions just because a core contributor created it. I’m convinced. I’ll be curious to see if anyone else has counter arguments.
Although if the official project author shows up later I can see it being weird that they’re not a mod; no reason why they should be, I suppose, but some people would expect to be an mods over a place a community they’re a leader of is gathering. I suspect that the original creators would make them mods, but I could see it being a source of conflict too.
Someone created a couple of subs on Reddit for some XMPP projects I develop. I’m now in a situation where I don’t have full control over those, and therefore don’t want to promote them as official venues for the project. That leads to me not posting to or participating in them.
This kind of situation would be prevented by an “official-only” rule, or at least to give the project developers first refusal if someone wants to create a community for a specific project.
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.
I am curious if you reached out and asked to be made a mod on the subreddits and what the result was? Did they have a reason for denying you?