Let's de-bridge generic support/social/community channels

Project Discussion
, , ,
1

(Not sure if I chose right tags, please adjust if needed)

I suggest we stop bridging channels which are designed for support and social conversations.

Consolidating channels makes sense when we want everyone to have shared context. For example is we choose Fedora Meeting channel to run a meeting for a certain working group, we obviously would like all people to participate in the same meeting, no matter which messaging service we use.

For support or social channels though, the discussion is often split into disconnected pieces. So there is no technical requirement to keep all the conversations in one room.

At the same time there is a psychological benefit of having several different rooms:

By creating dedicated channels with smaller groups we give them the opportunity to grow as individual communities with slightly different atmosphere, to create their own set of local memes and connect better on a person-to-person basis.

Some of those rooms can be “mature” (not in terms of language, but in terms of knowledge, history and traditions of that group), some of them can be young and explore new stuff, create new own traditions.

We often see this happening around language communities: conversations in a non-english languages are usually less formal. But I think that it is not the language barrier which causes it, but rather the split out from the crowd into a smaller group creates different dynamics.

By keeping it all in one room we reduce the diversity of our community and create it as a more uniformal, normalized crowd.

Now, it is hard to come to an existing channel of 1000 people and tell them to split into two groups, and it probably doesn’t make sense, but the diversity of messaging applications already creates some natural splits in the community.

So, how about we:

  • accept that bringing as many people as possible in one room may be not a good thing
  • stop overconnecting chat groups and go for more chats with reasonable amount of members where that makes sense(*)

What do you think?

(*) - It doesn’t make sense to have two different chats dedicated to a specific working group.

2 Likes
2

(I added the matrix tag).

I’m torn on this. One the one hand, you make some valid points. I think the user experience for bridged channels is generally worse than unbridged. Either people miss some of the message (e.g. IRC users don’t see Matrix reactions) or everyone is forced to the lowest common denominator.

Part of the benefit of a bridge, though, is that it provides a bridge for people to move from the “old” platform to the “new” at their own pace. Some people will never want to leave IRC, and that’s their right. I don’t want to force them to switch, but I also don’t want to exclude them from conversations.

My personal sense is that, in the last 2.5 years without in-person meetups, Fedora contributors have become more siloed. I’ve heard similar sentiments from others. I’m in favor of de-bridging over time, but I’m not sure the time is yet right. At least not as a general policy.

3 Likes
3

I think I get your point. When a certain channel is on its path to deprecation, bridging makes sense, but then I would add a specific recommendation for new comers for which channel is considered deprecated

I also think that I can not create formal rules when we should bridge and not bridge things. Because every case seem to be slightly special.

What is important for me is that

  1. we understand that there could be valid cases for keeping certain channels apart. And include that thought in our evaluation.

  2. we de-bridge main #fedora channel

I’ve just spend a day there yesterday and couldn’t help but see that there is a tension between IRC and Matrix folks there which have to deal with bridge limitations.

But also just that there is a strong established IRC community, many names are familiar to me from 10 years ago. And while I love them all, I think that it would be nice to give a chance to other people to build a maybe slightly different support channel. And I don’t think that we should choose one or the other, I think that the generic support of the linux distribution is a big enough topic that having several overlapping but different rooms of those can be a good thing.

3 Likes
4

Maybe it makes sense to not make a general decision but treat each case individually. Unfortunately, not everyone looks regularly to discussion.fp (I know it should be that way, but I would not rely that affected people check discourse.fp regularly). So I would like to avoid creating further tensions here by some members getting the feeling in the end that we impose a decision on them. We could paste something in the respective channels and involve the respective groups to ensure that we capture their perspectives, too (maybe put something in the channel topic for some time?).

If bridging tensions cannot be overcome by existing means, it makes sense to split. I also agree to the cultural aspects; de-bridging might help a bit to not impose the “IRC legacy” on new folks. But I would decentralize these decisions to the affected groups (and to wherever the respective groups come primarily together) rather than making them here (at least if they can find a consensus), so that it reaches out to those who are affected by it. I have to admit that I feel not eligible to vote for the main #fedora channel because I am very seldomly there (the same for the Flock/Nest telegram channel).

When it comes to the Docs, I would be +1 to focus on Matrix and get rid of IRC. I think there is risk of a loss of information in each meeting and conversation (especially in the longer and more detailed conversations that we had in the recent weeks, with different conversations in parallel with many “reply to”, and smileys that represent +1 or such), and I think the few people we have at Docs might survive to focus on one medium. But also for docs, I would put the decision to the affected group and see what the others think about it. Hope that makes sense :slight_smile:

2 Likes
5

Agreed!

6

To be clear, that’s what this thread is. It’s about specific channels, not as a general policy proposal.

1 Like