[swift-evolution] [Swift4] Mailing list vs. Forum

[David Hart]

> On 03 Aug 2016, at 12:01, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> On Aug 2, 2016, at 10:46 PM, Jacob Bandes-Storch <jtbandes at gmail.com> wrote:
>> 
>>> 1. Available on every platform.
>> Browsers too.
> 
> True.
> 
>>> 2. Performant on every platform. (Discourse, for instance, struggles on Android.)
>> Browsers are heavily tuned for performance, and Discourse is a relatively lightweight site. If you prefer the performance of your email client, there's mailing list mode.
> 
> Discourse is *very* Javascript-heavy and has long had severe performance issues in some browsers, particularly Chrome on Android. It appears they've recently taken some steps to mitigate this issue in their most common view or two, but it's still not nearly where it ought to be.
> 
>>> 3. Native on every platform.
>> Browsers too.
> 
> Safari is native, but Discourse in Safari is not by any means native. Any attempt to define things otherwise would produce a vacuous definition of the term "native".
> 
>>> 4. Based on open standards with multiple implementations.
>> Browsers too.
> 
> Again, treating the browser as though it is the important piece here renders the statements meaningless.
> 
>> You may argue that the forum itself is too centralized, but Mailman is necessarily centralized too.
> 
> But Mailman is merely a conveyance. It can be swapped out for an equivalent email-based conveyance with relatively little effort or inconvenience to users. Imagine the amount of effort needed to move from Discourse to (say) phpBB and you'll see the difference.
> 
>> And this isn't always a positive: formatting of styled, quoted, and even plain text is quite varied among email clients, so popular threads often end up looking like huge messes.
> 
> This is true. (There was a minor quoting issue with this reply, probably because you used HTML email.) However, in my experience it *usually* works out okay. The bigger issue is not really the software, but the wetware: many people don't really pay attention to the quoting their mail client does.

It’s not only quoting. Code formatting is a mess and really hinders readability. I try to do my best to use some formatting when I can, but when I’m on the go, with only my iPhone, using Mail, its a pain to write code in posts and replies.

>>> 5. Does not require you to proactively check swift-evolution.
>> Email notification settings, or full-on mailing list mode, or RSS, can solve this.
> 
> I haven't used mailing list mode. How good is the fidelity of the posts? How about the replies? If features don't come across in one direction or another, email users will be second-class citizens.
> 
>>> 6. Supports offline reading and drafting.
>> Mailing list mode or RSS / reply-by-email.
> 
> It seems like an awful lot of your solutions are "use Discourse like a mailing list". To me, that suggests we ought to just have a mailing list.

He’s not saying "use Discourse like a mailing list”. He’s saying: if you *really* want to use an email client, the option is there. I would only use Discourse if we were using it.

>>> 7. Supports clients with alternate feature sets.
>> Discourse has RSS feeds and JSON APIs.
> 
> So you can invoke the features Discourse already supports from alternate clients. If you want to, say, search messages in a way that Discourse's API doesn't permit, you'll have to download and index all the messages. Which you would have already done if it were a mailing list.

This example is a bit extreme. I can already find information more easily with Discourse’s search than my mail client search.

>>> 8. Supports bot clients for both sending (like the CI bot) and receiving (like Gmane).
>> Discourse has an API which can be used for posting. It also supports bot-like plugins which can respond to various events, although I imagine that requires self-hosting. External bots interested in receiving would probably need to poll RSS, or just make use of mailing list mode as a receive hook.
> 
> Polling isn't great (and polling RSS could easily miss posts, depending on how the RSS feeds are designed). 
> 
>>> 9. Supports user-specific automatic filtering.
>> Topics and categories in Discourse each support a range of notification options from "watching" to "muted". My understanding is that these settings are respected by mailing list mode.
> 
> But there's no means to say "I don't care about messages from the CI bot" or "delete this specific type of message someone keeps spamming us with", is there?
> 
>>> 10. Users can privately annotate messages.
>> Discourse has "bookmarks", basically a way of saving individual posts/replies for yourself. Users can also send themselves private messages for note-taking purposes.
> 
> To keep stuff I don't care about out of the way, I use Mail.app's color flags to mark threads—yellow for threads I'm following, gray for threads I'm ignoring, red for threads on my own proposals, etc.—and then sort the folder by flag color. Does Discourse offer anything like that? It seems like it only offers a binary "bookmark" option.
> 
>>> 11. Drafts and private messages are not visible to any central administrator.
>> I'm not sure whether Discourse drafts are saved on the server. Moderators are restricted from viewing private messages.
> 
> Private messages are in the database, aren't they? There's no end-to-end encryption, is there?
> 
>> Of course, you can always contact someone via other means.
> 
> By *what* means? Discourse doesn't tell you a person's email address or any of their other contact info.
> 
>>> 12. History is stored in a distributed fashion; there is no single point of failure that could wipe out swift-evolution's history.
>> This is a fair point. But: 
>> - The Git repository of proposals is distributed.
> 
> There is an *awful* lot of useful content in swift-evolution that is worth archiving. The proposals capture only a tiny fraction of it.
> 
>> - Discourse is as easily backed up as any other computer system: https://meta.discourse.org/t/configure-automatic-backups-for-discourse/14855
> 
> One administrator creating a private database dump is no substitute for collectively having hundreds or thousands of redundant copies of everything.
> 
>> - Users who would like a low-fidelity local copy for themselves can enable mailing list mode.
>> - Anyone is free to access/archive publicly accessible content using the APIs. 
> 
> But it doesn't just *exist*; you have to proactively create it.
> 
> (The same is true of other things, like offline reading and drafting. The fact that, if you think of it, you *can* get these things is not nearly as good as it just always being there.)
> 
>>> 13. Usually the medium of choice for large-scale, long-running open source projects.
>> 
>> Is that just because people already know how to use email?
> 
> Maybe, but that's still true here.
> 
>> Is it because the projects are so long-running that email was the best/only choice when they started?
> 
> Maybe in some cases, like Linux and Perl. But (for example) LLVM is an open source organization built in this century, long after web forums became a thing. I would not assume that, because some mail-based projects are older than the web, all mail-based projects are mindlessly cargo-culting.
> 
>>> I would love to have a great web archive for swift-evolution—something with a really solid search function, good threading, and most of the other niceties of forums. It'd even be nice to have an upvote feature. But these are all things that you could do without taking swift-evolution off of email.
>> 
>> It's just as valid to *start* with a great forum system, and build any desirable additional features on top, as it is to start with a mailing list and build additional features on top. (Discourse being open-source is a pretty big advantage in terms of the ability to add features.)
> 
> If someone's going to do it, sure. But who's that gonna be? Discourse is a monolithic app under the exclusive control of an administrator; outsiders can't really take advantage of its open-source-ness.
> 
> Unless Swift.org is going to be very proactive about managing and enhancing its Discourse installation, that won't be a real benefit. The way the Mailman instance has been managed suggests to me that they really want something as close as possible to "set it and forget it". That's not a criticism—we're probably all better off with them focusing on the language, not the communications channels—but it suggests we shouldn't count on a lot of effort being put into customizing and improving those channels.
> 
> A mailing list is a good "naked robotic core" for project communication: it handles the central function of distributing information to all interested parties without requiring much maintenance. Third parties (that means you and me) can then build whatever tools we need based on that core.

It’s a “naked robotic core”, but it’s not a *good* one IMHO. The Atom open source project uses Discourse and are quite happy with it.

> -- 
> Brent Royal-Gordon
> Architechies
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution