Now that compose grew up to be such a multi-headed...

# meta

[Big Chungus]

Now that compose grew up to be such a multi-headed hydra, I propose renaming #compose channel to #compose-android to match #compose-wear, #compose-web and #compose-desktop.

Then it would be great to have a new #compose (or maybe #compose-meta) channel created to be focussed on general compose questions (state management, code sharing between platforms, integrating with external stuff, etc...).

[Zach Klippenstein (he/him) [MOD]]

I'm sure this naming was intentional and there's a good reason behind it. @Adam Powell do you know what it is?

[Adam Powell]

#compose is the general channel you're mentioning already. It has a population of over 6,200 people, many of which lurk and many of those who participate do so by asking very general questions about the composition model or the compose-ui stack independent of platform. Occasionally some questions about interactions with platform-specific APIs come up, such as android arch components ViewModel or navigation. I think this is okay, and I would welcome similar questions from other platform-specific libraries because nearly all of them involve a component of the composition model and effective data flow designs that are applicable outside of those libraries that can be informative for the other lurkers in the channel.

[Adam Powell]

I do not think it would be appropriate to ask an existing community of 6,200+ people to rejoin another channel to return to a status quo that they are already a part of.

[Big Chungus]

Hmm, that's not the impression I was left with 😄 To me it seems that #compose is mainly used as #compose-android as opposed to general compose.

As for asking people to switch channels, that was never my suggestion. That's why I emphasized that current #compose should be renamed to #compose-android first (to preserve members) and only after that new general #compose channel would get created.

But if current #compose is already meant to be generic, maybe a better way to go would be to simply reflect that in the channel's description and just create a new #compose-android for platform-specific discussions?

[Adam Powell]

it is already intended to be generic, and I do not believe that generic nature needs to extend to channel policing. If folks also want to talk about what they're building for desktop in there, I think they should. If something is deeply android-specific and has no elements that apply to others, I think it's fine to nudge those questions to the already-existing #android; it'll give people something that isn't immediately branded with 😶 anyway 🙂

[Adam Powell]

if we wanted to encourage change in the various compose channels I'd move to discourage stackoverflow-like questions across the board; any time there's a surge of, "here's my code, why isn't it working?" questions, the conceptual or design discussions drop sharply for a few days

[Big Chungus]

Fair enough. I guess I'm just chasing concise and focussed channels (#android for using kotlin in android vs #compose-android for using compose in android) too much. Must be just me 😅

[Big Chungus]

Yeah, seeing all that SO-like knowledge lost on this slack is always painful, but that and entirely different beast...

[Big Chungus]

But I digress...

[Adam Powell]

I read it more as you're looking to improve signal to noise ratio in general 🙂 I don't think hyper-focused channels are an effective way to do that in online communities since it leads to a lot of low-traffic, little-known channels, and a lot of the traffic in the bigger channels becomes redirects to other places. Communities languish that way, especially when it causes the people who are doing a lot of the helping to stop coming back because they just have a bunch of tedious no-op unread indicators to clear.

[Adam Powell]

I think the strong push towards thread-for-everything around here is a net negative for similar reasons. It repels free-flowing conversation in an attempt to replicate web forums, and in doing so it invites stackoverflow questions because that kind of request/response exchange benefits from aggressive threading