Hi all, we are a diverse community with a diverse set of needs, that is
evident in the responses. There may be a more general discussion to be
had about formalizing a process for adding/removing services to KDE's
infrastructure. In fact, there is currently a Phabricator task about
this, which I will link to shortly in a separate email to keep responses
to this email specifically about Telegram bridging.
Regarding the current discussion, I think it is important to reiterate
that Telegram bridging is causing problems, this is not new (see below),
and whatever our community needs must address that. Indeed the reason I
got involved now is due to the bridge being down a few weeks ago and
Paul suggesting I reach out to sysadmins to clarify the situation for
the community. From what I understand: the Telergam bridging situation
as it is now is not manageable long-term, and may not even be manageable
short-term for those dealing with it (see the end of this email).
Since it has been a big part of the discussion the past two days, I feel
it may help to establish what was recently discussed publicly re
shutting down the Telegram bridges. I have included an overview at the
end of this email for those who want it. I hope it is helpful, at the
very least in establishing common ground. In short: from what I can
tell, the problems re Telegram bridging were publicly discussed (see
below), but not in a way that was obvious from the subject line or
conducive to further discussion, and it does not seem there was any
discussion directed at the Telegram userbase specifically. I have also
gone over the kde-community mailing list going back to 2017 to get some
history about instant messaging at KDE. I figured this may help
understand why we are in the place we are currently at. There was a lot
of lively debate, to put it kindly :) And issues about Telegram bridging
have been brought up going back at least 5 years (see, for example, [1],
[2]; also some positive changes [3]).
[1] "Telegram-IRC bridge not working" thread (2018):
https://mail.kde.org/pipermail/kde-community/2018q1/004346.html
[2] Reply to "The chat situation" thread (2020):
https://mail.kde.org/pipermail/kde-community/2020q2/006330.html
[3] "Telegram Bridge Migration" thread (2021):
https://mail.kde.org/pipermail/kde-community/2021q2/006884.html
Underlying many of the discussion points the past couple of days seems
to be a distinction between incoming vs. outgoing vs. internal
communication (this is the three-way distinction I used in the Akademy
presentation, there are likely other relevant distinctions, maybe even
just a simple inreach vs. outreach).
* /Incoming/: How KDE receives information from the world
* /Outgoing/: How KDE shares information with the world
* /Internal/: How KDE exchanges information among contributors
Using this paradigm, it may help to consider which communication
channels are used for which purposes (i.e., mapping the three types of
communication to KDE's communciation channels). For example, would you
agree with the following?
* Mailing list (long-form discussion): primarly internal communication
* Matrix/IRC/Telegram (real-time chat): in some cases used for
internal communication (developer teams), in other cases for
incoming/outgoing communication (outreach teams)
* Discourse (forum): primarily incoming/outgoing communication, only
limited internal communication
- ....
So, if we need to find a structured way to decide how to allocate
resources, it seems reasonable to me to suggest those teams with a heavy
outgoing/incoming focus have good reason to need access to widely-used
proprietary platforms and corresponding technical support (the
"exceptions" in the initial announcement). As has been pointed out many
times, much of the world is on those platforms, as unfortunate as that
may be.
There may be other teams that have particular needs requiring
exceptions, and those should also be considered, but maybe there can be
agreement on the above at least.
Then the questions is: how do we use the resources we have to support
those teams? I cannot speak to that, unfortunately.
Maybe this helps?!
Whatever we do, please recall that most involved are volunteering their
time and energy for the love of KDE. We have a diverse set of needs,
from those of the sysadmins to the developers, from the visual design
group to the promo team. Let's make sure we try to see the situation
from all point of views and reply to each other gently with that in mind.
Cheers,
Joseph
== Recent Public Discussion Overview re Telegram Bridging
Nicco is correct that the June thread "Telegram <-> Matrix bridges will
be removed in September" did not result in a discussion about closing
the Telegram bridge, despite the subject line. As Nicco pointed out,
Nate wrote: "If the discussion has not yet started, then it seems a bit
premature to be making any decisions now based on potential future
outcomes of said discussion." Although there were some further points
made about Telegram bridging in response, the thread did not result in a
community decision-making re shutting down Telegram bridges.
Telegram bridge problems were also part of the May discussion
"Retirement of IRC Services and KDETalk.net (Jabber)". The subject line
did not mention Telegram. Email thread starts here:
https://mail.kde.org/pipermail/kde-community/2023q2/007607.html
The points about Telegram embedded in the discussion from various
contributors are as follows. (I did not cherry-pick some responses,
these are all that I can see specifically related to Telegram -- I hope
I didn't miss any.)
> Given that we are now fairly well migrated to Matrix, the need to
maintain our Telegram bridging is much reduced, and i'd therefore like
to retire that without replacement.
> Either way, those channels should migrate to the Matrix provided
bridge if they still need bridging (ideally the Telegram channels would
be shutdown as they're a significant source of abuse)
> As [...] pointed out it isn't Mattermost that we use for Telegram
bridging. Telegram is currently mainly using a mautrix-telegram bridge
run for us by EMS, this was only ever planned as a short term service to
aid in getting the users in the unofficial Telegram rooms to migrate
over to Matrix. Some rooms are still using the legacy Telegram <> IRC <>
Matrix bridging due to issues with the number of users in some rooms and
broken permissions on the Telegram side
>
> The current situation with Community members using Telegram is that
the majority also have Matrix accounts that they use to take part in
other chats. This results in a duplication in users in lots of our rooms
that has negative impacts on Matrix and IRC having to handle all these
extra users/connections. The Telegram bridge is also a major source of
spam coming into us and onto IRC. There isn't anything we can do to
properly manage this as we have no control over how Telegram is operated.
>
> The current plan is for the Telegram bridge to be decommissioned
later this year. We may consider alternative options for some outreach
related channels, but within KDE it is redundant
As also noted, there was a (hybrid format?) discussion in an Akademy
BoF, which many contributors were not aware of. The notes are here:
https://community.kde.org/Akademy/2023/IM_Infrastructure_BoF
Regarding Telegram:
> Telegram Bridge
> * needs to go away as we lost access to some of this due to it
being reported as spam
> * runs on infrastructure which we could only use for a short period
of time
> * set up new Telegram bridge, but only for external facing rooms
> - causes high load
> - big spam source, as banning isn't propagated
--
Joseph P. De Veaugh-Geiss
KDE Internal Communications & KDE Eco Community Manager
OpenPGP: 8FC5 4178 DC44 AD55 08E7 DF57 453E 5746 59A6 C06F
Matrix: @joseph:kde.org
Generally available Monday-Thursday from 10-16h CET/CEST. Outside of
these times it may take a little longer for me to respond.
KDE Eco: Building Energy-Efficient Free Software!
Website: https://eco.kde.org
Mastodon: @[email protected]
