Exploring new communication channels

#102

and in addition, if you are wanting to totally ignore a particular channel which has been brought back through a @mention (or at any other point), you can right-click on a channel, a group, or a server and “mark as read” to clear/hide it again

#103

As someone who hangs out in the Redox zones I’m pretty sure jackpot51, our BDFL, self hosts most of our things, yes. Additionally, jackpot51 appears to add the accounts manually, too. I’m quite certain we have no OAuth or real burning desire for it at the current time.

#104

Have you considered trying an XMPP MUC? This is a pretty common choice among XMPP projects and works pretty well once MUC-MAM has become a de-facto standard for providing paged history.

An XMPP server could be self-hosted by Mozilla itself, still allowing users from different servers to join.

I heard that Matrix had some problems with performance, so that they had to disable presence in rooms altogether.

#105

[Disclaimer: I’m not a “core” Rust developer, just a “normal” Rust developer, working on a Scheme interpreter. Please don’t take this reply the wrong way; it’s just my opinion, which I’m not imposing on anyone, I’m only expressing it.]

After ~100 replies, and almost 10 days, I am astonished that searching for the word “mail” appears only four times, and when it does is about the integration between GitHub / Discourse and emails.

So why do I care about mail: over the years I was interested in many open-source projects, and from their community discussions I learnt quite a lot; and for most (i.e. almost 99%) of these projects all this “peering into the community discussions” happened by subscribing to their mailing lists, creating some labels in GMail, and using the “mute” and “star” features. This way I was able to handle more that 150 projects at one time (with an daily intake of about 100 new threads per day, and more than 1k emails per day.)

Now it seems that “lately” some projects moved to “fancier” community discussion channels:

  • the majority to Discourse-based deployments;
  • some other to various PHPforum clones;
  • a few other use GitHub issues;

So what is wrong with these “fancier” discussion channels:

  • they lack “proper” integration with email (take 1); yes, they can send you emails, but good luck trying to create any useful filters (especially in GMail), mainly because they lack a core fundamental functionality of email community discussions – correctly setting the List-Id header;

  • they lack “proper” integration with email (take 2): yes, they can send you emails, yes they’ll clog your inbox, and no they don’t look like “proper” emails… they look more like HTML-based advertisments from your local grocery store;

  • following more than one project makes you have to “hunt” discussions in multiple places – i.e. one tab per “community”;

  • following more than one project will make you feel disoriented due to the various “layouts”, “color schemes”, and other “eye-candy”; take for example internals.rust-lang.org and users.rust-lang.org – although they belong to the same project, run the same software, and possibly are administered by the same people, they have slightly different “layouts” and “color schemes” – on the main one uses “red” for selected tabs while the other uses “blue”;

  • they are “ephemerous” – when the VM goes down, so does all the “community history”… (“that ain’t right” would say the sys-admin because he has “backups”…)

  • they don’t work offline; (neither does GMail, but one always has the option of offline IMAP backups, Thunderbird, etc.)

  • etc.

So in conclusion one would ask what’s the point of my post: raising awareness of the fact that “newer” and “fancier” isn’t especially “better” for everyone or in all circumstances.

(There is a reason why even in 2018 the IETF still issues RFC documents as plain-text, with 80 columns wide…)

I do see the advantages of alternative discussion channels – and Discourse seems to be the least “unpleasing” one – however I would have loved a little bit more attention to the “grumpy-stuck-in-the-past” generation that prefers mail-oriented workflow…

#106

A genuine question since i never was part of a community that was managed by mailing lists: how would moderation work?

#107

And this is the “nice” part about mail-based workflow:

  • you have the option (as an mailing list administrator) to “unsubscribe” a particular fellow form your mailing list – probably just like you can do something similar in Discourse;
  • but you have also the option as an “individual” to “block” a particular fellow by creating a GMail (or alternative) rule that either “mark as spam” or “delete” any email coming from that person;

But then again, having a mail-based workflow also comes with the added benefit of all the research and effort that went into SPAM filtering.

Therefore in all these years I never had a real issue with this. GMail did its best to “moderate” the “community” for me. :slight_smile:

#108

Thanks, I may try that. Somehow the 110% font size resets after a browser restart, even though other appearance settings persist. I have some data set to be cleared on browser restarts, so it is possible they use some form of local storage here – but not for other settings? Quite strange.

#109

Funnily enough, I have the opposite experience: I consider high-volume discussion as something which e-mail handles badly, and heavily dislike being forced into using e-mail for this purpose. In my opinion, there is a clear divide between “e-mail” and “chat” communication patterns, which call for using one or the other depending on circumstances:

  • The former is most suitable for low-frequency important content which I am expected to read carefully. Any skimming through my mailbox is my own responsibility, and missing an important message while doing so is a failure from my part, not that of the sender.
  • The latter is most suitable for high-frequency disposable content, where the expected reaction to a large amount of missed messages is shameless skimming or even skipping. Having an archive of old messages is appreciated, but I don’t mind the service dropping them after a reasonable delay.

Here are some reasons why I think our experience of e-mail differs:

  • As a result of being around the web for a while, I have 4 active mailboxes from 4 different providers (plus some aliases). Constantly switching between 4 webmails with completely different ergonomics is a non-starter, so I need to use “unified” local e-mail clients like Thunderbird.
  • Because of this, and because I also use my cellphone as part of my strategy for handling the absurd amount of e-mail which ill-managed professional mailing lists send me, fancy e-mail client features which requires constant synchronization across devices to be useful, such as automatic filtering and deletion, are a non-starter.
  • So I need to handle my e-mail traffic ~manually, which is very painful whenever some stupid service decides that sending me one e-mail anytime something minor happens is a good idea (shame on you, Gitlab!).

Here is where I think other services outperform e-mail on this “frequent notification” scenario:

  • Gitter sends you one e-mail when there is new traffic which you haven’t been checking for a while, then stops until you visit the website. This is the way all e-mail notifications from high-traffic web services should work, in my opinion.
  • RSS clients (and dubious contenders like Twitter) allow me to easily separate “newspaper-style” notifications, which I can safely afford to skip when I’m overloaded, from personal messaging which I must read and potentially answer. This is an invaluable feature when e.g. going on a long holiday.
#111
  1. Redox OS self-hosts everything, from the website to GitLab
  2. It is merely a preference to require invitation for the chatroom
  3. Jeremy and I work at System76, and we also use it for Pop!_OS
  4. Pop!_OS is open: https://chat.pop-os.org/
#112

This entire discussion has been about finding an appropriate chat platform, not about the desired platform for long-form posts. One bikeshed at a time, please. :slight_smile: If you want to discuss making Discourse integrate better with email, please start another topic.

As far as I can tell, Discourse sets a List-Id header that you can filter on:

List-ID: Rust Internals <internals.rust-lang.org>

Discourse emails have a proper plain-text component, if you view them in a plain-text email reader. I’d never looked at the HTML version until just now, but it doesn’t seem all that unreasonable either. If you have specific concerns about the HTML styling, you could report them upstream to Discourse.

As far as I can tell, you can arrange to treat Discourse like a mailing list, and receive mails for everything.

#113

[First of all please take into account that my points against these “forum” systems don’t apply to all, some get somethings right, meanwhile other they miss…]

However it also sets the To header, which makes GMail and other mail clients think this is a “personal” email. (The “advised” way is to not set To unless the user actually set it, and rely only on List-Id. At the moment I know of no mailing-list system that doesn’t obey this.

#114

That seems like a peculiarity of gmail. There’s a huge difference between “set email headers to allow for normal list filtering” and “set email headers to make gmail happy”. Most list filtering uses exclusively List-Id.

Nonetheless, if this is an issue for you, you could report it upstream to Discourse.

#115

For services such as discourse, slack, zulip, gitter etc, i prefer to disable all email notifications because I’m mostly likely to check either the web or the mobile app version during the day. This helps reduce the email clutter.

#116

Incidentally the Ember.js team is having the exact same discussion:

#117

I wouldn’t call it “the exact same” discussion. They’re switching from one proprietary chat app (Slack) to another. This seems like a substantially smaller change with fewer downsides, compared to dropping IRC.

#118

Is anyone else having the problem that Discord often loads chats (DMs and channels) somewhere in the middle so one has to scroll down a couple screens first – even if all messages in the chat have been read already? Rather irritating.

#119

I encounter that occasionally. If you scroll to the bottom, switch to another channel, and switch back, it seems to go away for a while. Definitely worth reporting.

#120

One disadvantage of many email lists is that it is hard to join a conversation if you are a new or occasional contributor. If you weren’t subscribed to the list when a message is sent, there’s no simple way to post a proper reply to it. (There are ways to do it in some email clients, but they are generally not very convenient or discoverable.)

A mailing list integrated with a newsgroup or forum interface (like gmane.org or Google Groups) can mitigate this problem somewhat.

#121

Well, if we’re seriously going to talk about mailing lists, then this needs to be said:

I’ve never figured out how to properly navigate a mailing list. And I mean really, really basic stuff no one even considers a skill or a feature, like finding the start of a thread, going to the next or previous post in a thread, figuring out if there even is a next or previous post at all, etc. I’m still not clear on whether there are ways to do these things or mailing lists are just that primitive.

IRC has enough usability issues that it eventually drove me away from the Rust channels, but mailing lists I probably would have never tried in the first place.

#122

For all intents and purposes, Discourse is a mailing list as you can interact with it purely through email after signup:

We’ve migrated many large mailing list communities to Discourse, such as Chef and Swift. For 99% of mailing list users we appear to have achieved satisfactory feature parity.