Unified internal communications channel

[Albert Astals Cid]

El dilluns, 11 de desembre de 2023, a les 12:55:17 (CET), Joseph P. De Veaugh-
Geiss va escriure:
> Hi,
> 
> as others already mentioned, the issue that prompted this discussion
> seems to me not a tooling issue, but a usage one. Nonetheless, it is a
> good opportunity to talk about communication channels at KDE and to
> identify areas for improvement.
> 
> On 12/9/23 13:00, kde-devel-request at kde.org wrote:
> >> I had the idea for such a channel before. But I admit that I did not
> >> search
> >> whether such a channel already exists.
> >> 
> >> I would subscribe to a channel which is readable via email and has
> >> messages
> >> like these examples:
> >> [...]
> > 
> > I think you touched an important issue there - we should define the scope
> > of the proposed communication channel(s) and give guidelines for when and
> > how to use them.
> > 
> > There's no use in having another channel if people will end up
> > sidestepping it because they were unsure if their topic was relevant.
> 
> I like David's proposal of a community-wide channel only for
> announcements, with a clear scope, moderation to keep it on-topic, and
> links to channels for further discussion. And I agree with Johannes that
> well-defined scope can help encourage contributors to provide content!
> That said, I also see the issue of adding yet another channel to KDE's
> communications infrastructure, at least not without looking at what
> channels already exist and how they are used.
> 
> I thought about the topic over the weekend. Personally I find it helpful
> to identify the organizational structure and then map the tools onto the
> structure, not the other way around. To illustrate what I am thinking,
> here is a graph showing subset relationships between groups, starting at
> everything under the node KDE COMMUNITY. The subsets are obviously far
> from perfect, should be reconsidered, and just here as examples. (If
> anyone would like to seriously discuss graphing the KDE organization,
> please be in touch. I think it would be useful.)
> 
> 
>          KDE COMMUNITY
>           /          \
>          /            \
>   NON-TECHNICAL    TECHNICAL
>       /    \        /  |   \
>      /      \      /   |    \
>   USERS  CONTR.° VDG  PLASMA [...]
>           / \
>       [...] Int.Communities
> 
> °Contributors
> 
> Assuming this is a useful way of graphing the organizational structure
> of KDE (that is just an assumption, I am not committed to this), the
> questions for me are then:
> 
>   - What communication /within/ groups do we want?
>   - What communication /across/ groups do we want?
>      + Which tool(s) would best achieve what we want?
>      + Which tool(s) do we already use? Are they achieving what we want?
>      + Do we need to add/remove tool(s)? Which ones?
> 
> Here are ideas of how I might apply the above approach, using some
> examples from earlier in this thread:
> 
>   - planet.kde.org blogs:
>      + Used for communication from "TECHNICAL" to "KDE COMMUNITY".
>      + Which other channels (e.g., social media) are used for this
> cross-group communication? Are there areas for improvement?
> 
>   - plasma-devel ML:
>      + Used for communication within the "PLASMA" group. Which other
> tools are used for this group? Are they all needed?
>      + What advantages or disadvantages are there if we added/removed a
> tool (e.g., moved this group to Discuss, closed the mailing list, etc.)?
>      + How do groups outside PLASMA communicate with this group?
> (particularly relevant in this context)
> 
>   - kde-code-devel and kde-devel MLs:
>      + Both seem to fall within "Technical" group (as brought up by Carl)
>      + However, they have slightly different scope. Can they be merged?

They could probably be merged yes, there's been some timid attempts that 
didn't succeed but maybe it's time to try again :D

Cheers,
  Albert

> 
>   - kde-community ML:
>      + Communication within "CONTRIBUTORS" group
>      + How can we move people from the USERS node to the CONTRIBUTORS
> one? What communication is needed to achieve this?
>      + Would another tool (e.g., Discuss + ML function) be better suited
> for this communication, in that it potentially is seen by more users and
> the exposure may invite them to join in KDE's non-technical community?
> 
> If others here find this a helpful way to discuss it, I am happy to
> develop the idea further and make some concrete suggestions. This is
> just a sketch for now.
> 
> Cheers,
> Joseph