On the communication channels we use

I have concerns regarding the communication channels we use for working on LibreOffice. First, it seems we are sliding into a situation where the closed-source chat platform Telegram becomes an official channel for team coordination. This is frustrating because there has been no discussion about the topic. The move is apparently due to some people wanting to use their privately preferred communication method (with friends & family) with their work topics. All of the ones pushing Telegram into contributor coordination are TDF employees (QA, design, marketing). In Finland we have a saying for this sort of process: climbing a tree butt-first.

Closed-source tools have been used for coordination in the past, but accompanying them has been the intent to move to FOSS equivalents as soon as possible. The Engineering Steering Committee uses Google Hangouts, because no other tested platform could handle the amount of participants and the geographical diversity (yet the limitations of Hangouts are a constant source of annoyance). A clear contender in this arena is https://hubl.in/ from Linagora, a company that contributes to LibreOffice development. The LibreOffice design team used Google Docs, but now LibreOffice Online is the obvious choice for design proposals, no less from the perspective of dogfooding.

With the slide to Telegram, there is no expressed rationale and no actual need to go proprietary. These days we have an array of modern FOSS chat tools geared towards various different audiences: Mattermost, Zulip, Rocket.chat, Gitter, Let's Chat, Riot. Moving to Telegram now is as absurd as if we started using Slack or Skype.

The cheerleaders of Telegram have an allergy to IRC. It's a legacy system with some clunky bits, there is no use denying it. Wait a sec, did I just describe LibreOffice as well?? So why are we being lunatics pimping a tool built on a swamp of legacy code, but at the same time wrinkling our noses at a legacy chat system? Well, it turns out the old dog has learned new tricks while we were busy making fun of it. Modern web IRC clients offer most of the features of the chat platforms mentioned above.

When we direct new contributors to IRC, we should point them to an instance of The Lounge, the new Kiwi IRC or Convos. Fortunately, it very much looks like Freenode will replace its tired old webchat with one of them, Kiwi IRC, because Freenode's owner PrivateInternetAccess is sponsoring its development. As you may know, Freenode webchat links are all over the LibreOffice website and TDF wiki.

Second, I'd like to bring up a more difficult subject: proprietary social networks, taking Twitter and Facebook as specific examples. I used to believe they were a necessary evil to get marketing done. Recently it has become evident that they are rather a "Nazgûl flying out of Mordor" -grade evil. The walled garden effect is really kicking in. If you are not logged in to the services:

- you cannot read FB event comments
- you cannot read "Tweets & replies"
- FB often asks you to solve a CAPTCHA just to view a page
- FB hovers a giant banner in your face trying to pressure you to sign up

These superficial, but very disgusting patterns arise naturally from the business plan of trying to capture the web as a platform. Do the world a favour and refrain from publishing content exclusively on these dark platforms. Take inspiration from the legendary Calc hacker Eike and start tooting: https://joinmastodon.org/

Rouse yourself from the sweet lull of inertia and explore the systems that were created to empower you: https://github.com/Kickball/awesome-selfhosted/#social-networks-and-forums

People already on Telegram are far more than people willing to move to a
different platform like RocketChat (which I have installed, to discover
that nobody was using it).

Telegram groups are used for discussions, and it looks like there is a
majority of people more familiar with Telegram than with other tools
(and this has nothing to do with TDF team, but with the habits of people).

IMHO, we have to reach out to people, and not force them upfront to
switch to what we consider a better option. Once they have started to
contribute, we can ask them to move to our preferred platform, which is
a mailing list (for marketing). This is what happens today.

Marketing coordination happens on the private marketing mailing list,
where people are invited once they show some willingness to help (but
then the reality is that these people are more active on Telegram than
on the mailing list).

I use IRC to communicate with other team members, although I do not like
at all the system (independently from the client, as I have tested them
all, to discover that they are developed by developers for developers,
and not for people with a different background and mindset).

The fact that we respect people willing to use IRC instead of Telegram
is confirmed by bridges which have been created between the two. Bridges
are available for general discussions, QA and design, so for every group
where they are needed.

By the way, if I had to use what my family and friends are using, I
would switch to POTS and text messages, as this is what old people in
industries such as communications and marketing are using (nobody is on
Telegram or Slack, a few are using FB Messenger and even less WhatsApp
and Skype).

Source code is at https://github.com/telegramdesktop/tdesktop

Where it states «The source code is published under GPLv3 with OpenSSL
exception, the license is available here.»
The "here" links to
https://github.com/telegramdesktop/tdesktop/blob/dev/LICENSE, which
contains the text of the GNU GPL 3.0

As such, I don't understand how it can be accused of being "closed source".

jonathon

Hi Jonathon, Ilmari, all,

the closed-source chat platform Telegram becomes an official channel for team coordination.

Source code is at https://github.com/telegramdesktop/tdesktop

Where it states «The source code is published under GPLv3 with OpenSSL
exception, the license is available here.»
The "here" links to
https://github.com/telegramdesktop/tdesktop/blob/dev/LICENSE, which
contains the text of the GNU GPL 3.0

As such, I don't understand how it can be accused of being "closed source".

Yes, you're right. However, the most important thing Ilmari is pointing
is about the decision process that shouldn't be on IRC or Telegram or
any other media but on mailing lists.
I like that the community is able to use the tool it prefers to
communicate, that opens the possibilities and makes our projects more
reachable. ESC is not only using hangout, but also phones on Talkyoo,
one language is leading its translation on Facebook, etc... whatever
they are at ease with and brings people together.
What we should be very careful with is to report on the lists, make the
decision process available on the lists and keep an archive of the
activities on the lists. That way each new comer has access to the
information at the same level others have and there is a memory of what
has been done.

Cheers
Sophie

https://en.wikipedia.org/wiki/Telegram_(messaging_service)

"Its client-side code is open-source software but contains binary blobs, and the source code for recent versions is not always immediately published, whereas its server-side code is closed-source and proprietary."

Hello,

I just want to make clear that the decision of creating the Telegram
group for QA was discussed in the QA meeting on 2017-04-25 [1]

Besides, both channels are bridged now, which IMHO, allow everyone to
choose what fits her/him better.

Regards

[1]
http://nabble.documentfoundation.org/Libreoffice-qa-QA-Meeting-Minutes-2017-04-25-tc4213251.html

El 01/08/17 a les 10:46, Sophie ha escrit:

Hello,

I have concerns regarding the communication channels we use for working on LibreOffice. First, it seems we are sliding into a situation where

thanks for sharing your concerns. I indeed do take these very seriously, and that topic was considered quite a lot before going that route.

My personal take on the situation is that the primary and official channels are those on TDF premises, i.e. primarily our mailing lists, wiki, pad and other resources to create and upload content. We have full control over these. My personal order of preference is e-mail (it's an asynchronous medium that everyone can use at the time and frequency they like), sometimes chat or phone, as the latter ones can help resolving topics easier than with lots of mails back and forth.

During the previous LibreOffice Conference, the organizers have setup a Telegram group for the attendees. It was considered mostly an experiment and planned to be shut down after the conference - the strong participation rate and acceptance of it made us rethink and keep it running. It was not a decision upfront, but turned out to be a good idea (IMHO) over time. So, it was initialized in first place by volunteer conference organizers, and has not been pushed by TDF's team, although of course they are quite visible.

I agree, though, that we can get better on communication that, indeed. There was a blog post at https://blog.documentfoundation.org/blog/2016/10/25/presenting-libreoffice-telegram-channel/ that also mentions bridging to IRC, but we could have added more details.

The main reason for using all sorts of networks is that we "want to get the people where they are". Especially for the younger generations, and also for some native language groups, messengers and social networks have turned out to be the most effective way. I recall at least one community ever since using Google Plus, and another one ever since using Facebook, considering mailing lists way too complicated and "old style". Being a free software enthusiast, and essentially living in my e-mail client, this doesn't make me totally happy; however, IMHO we would be wasting lots of opportunities if we expect people to show up on mailing lists and IRC, independent what their background is.

This is also the reason why the (few) truly free and open social tools do not help in this regard - they are only used by those already attracted by our project. If we want to reach out to new possible contributors, we need to show up where they are, if we like it or not. And looking at my contacts, very few of these use one of the truly free tools either; one contact here, another contact there, but nothing consistent sadly.

For me, the main rationale is to have as many content creation, discussions and votes on official channels as possible. I'd like to avoid a situation where decisions take place on some random network only a few subscribe to - the primary working place is the mailing list still, decision need to be properly communicated and shared and run on the official channels.

I'm all open for making access easier, have a better web IRC, and also re-investigate video conferencing systems (although I have to admit that testing with 10-20 people is quite time-consuming, so I'd prefer a real-life experience with such an amount, geographically distributed, on various bandwiths). Bridging is another option, and deciding which content to post where makes sense as well.

If you have proposals, please share them. We surely can get better, and I'm open for any proposals.

Hope that helps!
Florian

Hi,

I'm all open for making access easier, have a better web IRC

Do you think it's worth hosting our own web IRC front-ends? Currently we
point people to Freenode's webchat, eg

https://webchat.freenode.net/?channels=#tdf-infra

But if we host ourselves, we could add TDF/LO themeing, extra help, and
make the interface more welcoming for newbies to IRC.

Just a thought...

Mike

Kiwi IRC rewrite will go stable in a couple of weeks. I intend to change our links to point to it. It is much nicer than the dated qwebirc interface.
For now, you can try the new version like so (add and remove channels at will):
https://kiwiirc.com/nextclient/#irc://irc.freenode.net/libreoffice-qa,libreoffice-design,libreoffice-dev,libreoffice-doc,tdf-infra

Hosting our own, we could set up persistent history. A history solution for Kiwi IRC is currently in development. Kiwi IRC also has a theme builder functionality for CSS-only changes: https://kiwiirc.com/nextclient-themebuilder

Incidentally, KDE is having a similar discussion: https://mail.kde.org/pipermail/kde-community/2017q3/003664.html (warning: massive thread, you might spend your whole day..)

Ilmari

Hi,

Kiwi IRC rewrite will go stable in a couple of weeks. I intend to change our links to point to it. It is much nicer than the dated qwebirc interface.
For now, you can try the new version like so (add and remove channels at will):
https://kiwiirc.com/nextclient/#irc://irc.freenode.net/libreoffice-qa,libreoffice-design,libreoffice-dev,libreoffice-doc,tdf-infra

doesn't look too bad to me indeed. :wink:
Do you know if it is available localized? I think if we want to extend IRC to casual users, some localization would be helpful, and for me Kiwi IRC loaded in English. No dealbreaker, but a nice to have of course.

Incidentally, KDE is having a similar discussion: https://mail.kde.org/pipermail/kde-community/2017q3/003664.html (warning: massive thread, you might spend your whole day..)

Didn't manage to read this yet though :slight_smile:

Florian

Yes, it supports localization, as evidenced by code changes such as: https://github.com/kiwiirc/kiwiirc/pull/56
I don't think anyone has translated it yet.
qwebirc never supported localization.

Ilmari

I was wrong, the translations are here: http://translations.kiwiirc.com/

Ilmari

Could the missing desktop app become a showstopper? Telegram is available as standalone app and Telepathy can also handle this protocol (not sure about Pidgin). Thomas collected a couple of requirements in the KDE chat what a messenger should be able to do. I would rate some points differently, so the avatar is a nice-to-have and stickers a contradiction, and suggested to run a Kano survey like I did for KGet in [2]. But the list is interesting anyway.

[1] https://mail.kde.org/pipermail/kde-community/2017q3/003693.html
[2] https://user-prompt.com/using-the-kano-method-to-prioritize-requirements/

I guess you mean "missing desktop app with an attractive GUI"? :slight_smile:
Regarding features in general, chat history batch is a draft in the IRC v3 spec: http://ircv3.net/specs/extensions/batch/chathistory-3.3.html
A metadata spec is being written and it would include avatars.

It is also worth mentioning here that replies are a draft: http://ircv3.net/specs/client-tags/reply.html
Editing and deleting of messages is being worked on: https://github.com/ircv3/ircv3-specifications/pull/304

Ilmari

KDE fellows found a Qt5-app for Matrix https://github.com/mujx/nheko/ (we need a cross-platform tool for average users without the hassle to compile; or rather a simple mobile app)

Hi,

Could the missing desktop app become a showstopper?

that reminds me of one question I didn't answer yet: Why Telegram. :wink:

Indeed, the possibility to use it on mobile, in browser and as dedicated desktop application was one of the main reasons, beyond the fact that it's been used by many people. There are several truly free and open solutions out there, but sadly, very few users use them - and that's in line with what I wrote earlier on about "getting people where they are".

I tried some mobile IRC clients a while ago and was not really convinced: no push notification, high battery usage - IRC simply is a different tool than a messenger...

I'm not at all against hosting our own web IRC frontend, preferably localized - I just think it won't get us the mobile crowd...

Florian

I have continued working with Kiwi IRC's lead developer. I brought up the topic of KDE and showed him their Etherpad, which listed all sorts of requirements and nice-to-haves for a messaging solution. In response, he said he is willing to work with KDE and LibreOffice to build a platform that we can be happy with.

I posted my proposal to KDE community list: https://mail.kde.org/pipermail/kde-community/2017q3/003857.html

For convenience, I will include below the text that the Kiwi dev wrote after reading KDE's requirement list:

Kiwi Next is the next generation of the Kiwi IRC client, specifically aiming to bring modern interfaces and ease of use from platforms such as Slack to IRC.

Many communities have established environments built up around IRC so any features or additions that Kiwi IRC brings will be 100% IRC compliant throughout and put to the IRCv3 working group so that other clients and servers may also make use of the functions.

The UI for Kiwi Next is getting tested on all major browsers including mobile, with translations being made available for 28 languages to make sure that anybody trying to be part of a community can do so.

Keeping people connected to IRC so that they may receive notifications on their desktop and/or mobile is a huge feature currently missing from IRC. This is currently being developed directly into Kiwi IRC so it is available out of the box with minimal fuss. Once connected and logged into your existing network services, a user can then simply resume their session with complete message history and searching. This is a feature that will be introduced on kiwiirc.com very soon but also entirely open source to be used anywhere. Works very similar to ZNC in that Kiwi acts as a normal IRC client which means any IRC client can make use of the same server.

A lot of the points mentioned are very much inline with the aims for Kiwi Next, most likely due to the same mindset: Slack + IRC merged together with some IRCv3 features thrown in.

Some quick overview points:
* 100% standards compliant
* Part of the IRCv3 working group to improve IRC itself
* Open source with an available hosted solution
* Use existing infrastructure and tools
* Multilingual and accessible
* Web based while still allowing desktop clients to be used
* Has already been tested with thousands of users in a single channel flood fest
* Built in media preview (images, videos, PDFs, anything that can be embedded)

Soon to be released:
* Team based channels that supports @everybody highlighting
* Switchable message views such as traditional IRC view and a more relaxed avatar + relaxed view
* Message reactions (Using IRCv3 standards so they work with other clients too)

In development at the moment:
* Built in BNC with desktop/mobile notifications
* Use Kiwi IRC and a desktop client on the same account at the same time (similar to ZNC)
* Message history + searching + exporting
* File sharing by uploading files through the UI, with optional file history

Not in development but can easily be added into Kiwi Next if required:
* Replying to a message with a reference/quote
* Editing messages
* Annotate images linked/shared through the client
* Stickers between Kiwi clients or between all IRC clients

Hello,

I have continued working with Kiwi IRC's lead developer. I brought up the topic of KDE and showed him their Etherpad, which listed all sorts of requirements and nice-to-haves for a messaging solution. In response, he said he is willing to work with KDE and LibreOffice to build a platform that we can be happy with.

this is an important topic and I have not forgotten about it - just the time upfront LibOCon keeps us quite busy. :wink:

That being said, are you at LibOCon, so we could talk there in person maybe?

Florian

Sure.

Some weeks ago there was this nice bit of news about Konversation: https://blogs.kde.org/2017/09/05/konversation-2x-2018-new-user-interface-matrix-support-mobile-version

I just discussed with the Kiwi IRC dev and I decided I will replace the qwebirc links in our wiki and site with the /nextclient/ link tomorrow. Full roll out of the next gen version to the /client/ URL is pending some translations and /nextclient/ will never stop working in any case. It is possible for us to the get a custom landing page and background image for the webchat. We can discuss this at the conf.

Best,
Ilmari