https://kotlinlang.org logo
Title
b

Big Chungus

02/15/2022, 9:59 AM
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...).
12
3
z

Zach Klippenstein (he/him) [MOD]

02/23/2022, 12:40 AM
I'm sure this naming was intentional and there's a good reason behind it. @Adam Powell do you know what it is?
👍 1
a

Adam Powell

02/23/2022, 4:00 PM
#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.
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.
b

Big Chungus

02/23/2022, 4:03 PM
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?
a

Adam Powell

02/23/2022, 4:06 PM
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 🙂
☝️ 1
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
b

Big Chungus

02/23/2022, 4:11 PM
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 😅
Yeah, seeing all that SO-like knowledge lost on this slack is always painful, but that and entirely different beast...
But I digress...
a

Adam Powell

02/23/2022, 4:14 PM
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.
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