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

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

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

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?

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 :not-kotlin: anyway 🙂

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 😅

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.