[QGIS-Developer] Revolt Chat Community Server

[Greg Troxel]

Régis Haubourg via QGIS-Developer <qgis-developer at lists.osgeo.org>
writes:

> thanks for the work with Revolt. I tried it during the developer
> meeting in Firenze, but I did not persist in using it. Let me explain
> why and please excuse me in advance, this is a pretty long mail!

I found your message to be very thoughtful and helpful.

For background, my involvement in qgis development is so far maintaining
the pkgsrc entry (also gdal, postgis, proj), portability testing on
those projects, and ranting about WGS84 ensembles.

> - mailing lists are dying. Younger won't jump in. Being at ease
> suppose a good email client and filter rules. And this is a pain. What
> is really unique is that they are indexed by search engine and
> accessible via public archives. We built a knowledge base each time we
> post a mail. Osgeo also offers a central hub where one can't explore
> existing mailing lists, and this was a really nice to me.  Now that
> Nabble is dead, there is no more forum-like web access. And let's not
> forget that some people just don't want to use apps, and would like to
> stick to mail forever.  So we can't stay without decision here.

I think it's really unfortunate that people object to using email, for
reasons that to me border on fashion.

Besides archives, mailinglists have another important point, which is
that the set of subscribers to a list are a community, a group that
makes some effort to belong, and people tend to remain.   I don't see
this with other mechanisms.

In particular, community doesn't happen with github; only the very few
dedicated contributors subscribe all, and, at least in smaller projects,
a handful of people deal with and respond to issues that mostly should
not be in issues.  I suspect this is partially github's fault for
pushing all interaction to their systems while not offering
mailinglists, and partly that people expect personalized support from
others rather than joining and being mutual.

Another point I think is very important is that email allows meaningful
participation by people who are only able to pay attention once a day or
even less.  Anything chat-like (which includes many forums in my
experience) generates a culture of instant discussion and moving on.
The things that matter actually happen on slower time scales, and using
fast-only mechanisms effectively excludes slower time scale people.

This is a tools issue, but I find that with email, the conversations
arrive (and in my case are sorted into per-project folders), and I
become aware of them.  I do not have to go to N different websites to
keep up with various projects.

> - Chats aren't efficient and generate too much traffic. I personnaly
> just don't have enough bandwidth to follow 10% of the channels I
> should follow. And I am pretty involved. Furthermore, each country
> seems to have its preferences on which too to use. I ended up in
> having 6 apps on my phone only for those channels. This is far from
> ideal. Let's not forget that some people will never leave IRC too :)
> (and some have older phones not supporting so many apps).

I agree about too much traffic.  Between it being easy to type, vs an
expectation of thoughtfulness in email, and people popping into chats,
expecting help, and then leaving, I find it too much and only follow a
few.

> - we also have issues, Pull requests and potential GitHub discussions
> to not forget here :)

We do, but that's proprietary software and relying on it more raises the
cost of leaving.

> - adding a new communication channel without stating officially which
> is the main channel just breaks the single source of truth principle
> we had with mailing lists. I have seen recently two feedback from
> community users thinking that there was no debate on major topics,
> just because the discussion on the mailing list topics stalled. But
> those discussions in fact did occur, but spread across those new
> channels, and we didn't have enough bandwidth to summarize the
> decision on the mailing list (and we also forgot). This is the most
> annoying issue.

I think this should be  fixed by declaring the mailinglist to be the
communication method of record.

> Discourse is a modern forum, that can act as a chat if you are inline,
> or a mailing list, and let users tune their notifications levels
> pretty nicely.  Just have a look to the main page, stating the
> principles of this tool [0]

This is interesting and I don't have experience with it.  I suspect that
means the kinds of projects I tend to participate in are either
mailinglist culture projects or github only.

>  - Discourse as one organized and persistent place, including the
> osgeo history discussions. This would be the main communication
> channel. I will contact OSGEO to see if the system administration
> committee want to go this way for all the osgeo mailing lists.

I am open to considering this if it functions as a non-broken
mailinglist.  That's a tall order, with From: fields correct without
messing up DKIM/DMARC, but maybe there is good enough.

> - We choose on main chat tool for instant messaging. Discord or Revolt
> could be the choice. I would vote for open source first. So this would
> be Element-Matrix or Revolt. Revolt is a bit too much overlapping
> Discourse feature to me. Element Matrix is already bridged to IRC and
> exists.

I would say that open source, clients and server should be an absolute
requirement, and there should be a very strong bias to federated and
already in use.  And, I'd include "people who avoid Google push services
do not have a second-class experience".

You say Element Matrix, but I think it's really "Matrix" and people can
use whatever clients they want (and I get it that most use Element).
(Interestingly, Unified Push seems to work fine for Element and
FluffyChat.)

As a data point for what it's worth, not much:

  I had never heard of Revolt until this discussion.

  I have known about matrix for years and set up my own homeserver in
  early 2021.  (And xmpp 20 years ago, and I've been using email since

Looking at Revolt, it does seem like even the server is Free Software.
The android client is not available in the main F-Droid repository.  In
my view meeting the inclusion criteria is how you demonstrate that the
app is actually Free Software, instead of using proprietary google
libraries.

Greg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20221102/6e8d0049/attachment-0001.sig>