> On 03 Aug 2016, at 12:01, Brent Royal-Gordon via swift-evolution > <[email protected]> wrote: > >> On Aug 2, 2016, at 10:46 PM, Jacob Bandes-Storch <[email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
