I did not have the time to counter all those points but I was going to and 
point that Discourse has a solution for nearly all of those. I would REALLY 
prefer having the mailing-list part of the discussion on Discourse.

> On 03 Aug 2016, at 07:46, Jacob Bandes-Storch via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> I hope my replies aren't too curt — I don't want to pick a fight (any more 
> than I did by starting this topic), but to explore how Discourse can serve 
> these use cases. Feel free to re-rebut.
> 
> On Mon, Aug 1, 2016 at 3:03 PM, Brent Royal-Gordon <br...@architechies.com 
> <mailto:br...@architechies.com>> wrote:
> 
> I don't think enough has been said in favor of mailing lists. Some advantages 
> for them:
> 
> 1. Available on every platform.
> Browsers too.
>  
> 
> 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.
> 
> 
> 3. Native on every platform.
> Browsers too.
>  
> 
> 4. Based on open standards with multiple implementations.
> Browsers too. You may argue that the forum itself is too centralized, but 
> Mailman is necessarily centralized too.
> 
> 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.
>  
> 
> 5. Does not require you to proactively check swift-evolution.
> Email notification settings, or full-on mailing list mode, or RSS, can solve 
> this.
> 
> 
> 6. Supports offline reading and drafting.
> Mailing list mode or RSS / reply-by-email.
> 
> 
> 7. Supports clients with alternate feature sets.
> Discourse has RSS feeds and JSON APIs.
>  
> 
> 8. Supports bot clients for both sending (like the CI bot) and receiving 
> (like Gmane).
> Discourse has an API 
> <https://meta.discourse.org/t/discourse-api-documentation/22706> which can be 
> used for posting. It also supports bot-like plugins 
> <https://github.com/discourse/try-bot/blob/master/plugin.rb> 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.
> 
> 
> 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.
>  
> 
> 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 
> <https://meta.discourse.org/t/support-multiple-new-topic-drafts/7263/15?u=jtbandes>
>  for note-taking purposes.
>  
> 
> 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 
> <https://meta.discourse.org/t/permission-changes-moderators-have-less/12522>. 
> Of course, you can always contact someone via other means.
> 
> 
> 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.
> - Discourse is as easily backed up as any other computer system: 
> https://meta.discourse.org/t/configure-automatic-backups-for-discourse/14855 
> <https://meta.discourse.org/t/configure-automatic-backups-for-discourse/14855>
> - 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.
>  
> 
> 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? Is it because the 
> projects are so long-running that email was the best/only choice when they 
> started? I'm not sure anyone has done real academic research on the use of 
> mailing lists in open source projects. If someone can find any, I'd be 
> interested to read it.
>  
> 
> I could probably go on, but I'll stop here for now.
> 
> 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.
> 
> This seems like status quo bias to me. 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.)
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to