[Swift4] Mailing list vs. Forum

Whatever keeps a mailing list as bottom implementation gets my +1.
Forums and other browser-based things may be more convenient _if_ you're
in a place with 24/7 connectivity, which is not true for many.

FWIW I'm using Thunderbird off the gmane group because threading doesn't
work well with other email clients.

···

On 8/2/16 12:21, Erica Sadun via swift-evolution wrote:

It is an instructive example of why remaining with a mailing list, flaws and all, is probably the best answer for Swift Evolution.

--
Rainer Brockerhoff <rainer@brockerhoff.net>
Belo Horizonte, Brazil
"In the affairs of others even fools are wise
In their own business even sages err."

I think this thread should focus on the mailing list vs forum, Slack is
not a forum. It could be nice to have it as an extra if we need it.

It looks to me that all benefits of a mailing list can be achieved by a
forum system with excellent support to read and reply using emails. But
the opposite is not true, one single simple example: we can't even link
related thread using email (as Tino mentioned on the Gmane thread).

The reason I don’t like mailing lists is because nobody has a good web UI for them. Gmane is clunky, the thing we have on lists.swift.org <http://lists.swift.org/&gt; is awful — it’s incredibly hard to follow conversations, things are separated by week/month for some reason, making searching difficult (and making it harder to follow the conversation). None of them allow messaging from the UI, or PM-ing a particular person if you discover their post some months later and want to ask a follow-up. It’s so far behind where group collaboration is today it’s not even funny. Then, of course, you’re exposing your email address on a public forum. So you either need a good spam filter or a second email address. Every other kind of forum abstracts your identity and puts a couple of spam-limiting barriers between strangers on the internet and your inbox.

The “advantage” of a mailing list - that you use your email client often, is pretty weak. For almost everybody, the browser can beat their mail client for usage hands-down. Everybody is used to the idea of having particular tabs which you always go back to - Apple even introduced “pinned tabs” in Safari for exactly that. If having it separate from the browser is also a bigger concern over all of email’s disadvantages, many forums have native applications available (e.g. Slack) or JSON interfaces, with apps already compatible with them and the ability to read offline.

Ditching email is obvious. It’s like if you discovered Elon Musk rode to work on a Penny-farthing.

···

On 2 Aug 2016, at 11:07, Tino Heth via swift-evolution <swift-evolution@swift.org> wrote:

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.

afair, the option of keeping a mail interface was mentioned in one of the first posts, so none of the positive aspects of email would be lost (it just wouldn't be possible to use the "bonus-features" that aren't available in the medium)
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

It is an instructive example of why remaining with a mailing list, flaws and all, is probably the best answer for Swift Evolution.

I don't get this:
If Swift Evolution had been using something more versatile than mailing lists, there wouldn't have been the need to use Gmane, which just helped to work around limitations of the original medium.
For me, it's just an argument to not switch to something that is controlled by a third party.

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.

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.

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.

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: Configure automatic backups for Discourse - admins - Discourse Meta

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.

···

On Aug 2, 2016, at 10:46 PM, Jacob Bandes-Storch <jtbandes@gmail.com> wrote:

--
Brent Royal-Gordon
Architechies

We need an official poll with all the mentioned options. I believe that would make things here a little bit faster.

+1 for something like discourse.

···

--
Adrian Zubarev
Sent with Airmail

Am 3. August 2016 um 09:48:03, Ben Rimmington via swift-evolution (swift-evolution@swift.org) schrieb:

On 1 Aug 2016, at 23:03, Brent Royal-Gordon wrote:

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.

Mailman 3 with the HyperKitty archiver has those features. For example:

<https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/&gt;

Swift-evolution is currently using Mailman 2.1.12 with Pipermail.

See also:

* <https://lwn.net/Articles/638090/&gt; (March 2015: Mailman 3 review)
* <https://lwn.net/Articles/596049/&gt; (April 2014: HyperKitty preview)

-- Ben

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

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 <brent@architechies.com <mailto:brent@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&gt; which can be used for posting. It also supports bot-like plugins <https://github.com/discourse/try-bot/blob/master/plugin.rb&gt; 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&gt; 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&gt;\. 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: Configure automatic backups for Discourse - admins - Discourse Meta
- 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

But I like sending out my messages then regretting the many typos and mistakes I only seem able to notice immediately after it's too late to do anything about it!

(so yeah, +1)

···

On 30 Jul 2016, at 12:39, Johannes Neubauer via swift-evolution <swift-evolution@swift.org> wrote:

+1 to move away from mail ;).

Another player might be [Slack][0] or [teamwire][1] . Kotlin uses Slack extensively.

[0]: https://slack.com/
[1]: http://www.teamwire.eu/

Von meinem iPhone gesendet

Am 30.07.2016 um 06:43 schrieb Muse M via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:

I'm open to ZenHub that can be integrate as part of GitHub for discussion, pull changes and it makes it easier to reference to the patches within ZenHub than from Discourse or other forums. Swiftly right?

https://www.zenhub.com <https://www.zenhub.com/&gt;

On Sat, Jul 30, 2016 at 10:10 AM, Tim Vermeulen via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
+1. Hirundo makes this format bearable, but it is still far from ideal. I see many advantages for using Discourse:

- It has actual syntax highlighting.
- It’s easier to moderate.
- It supports real-time updates.
- It’s easier to follow the flow of a conversation.
- It has better search.

I don’t doubt more people will take part in the Swift evolution process if we switch to Discourse.

> Branching...
>
> On Fri, Jul 29, 2016 at 5:22 PM, Chris Lattner via swift-evolution<swift-evolution@swift.org <mailto:swift-evolution@swift.org>(mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>)>wrote:
> > On Jul 29, 2016, at 5:14 PM, Brandon Knope<bknope@me.com <mailto:bknope@me.com>(mailto:bknope@me.com <mailto:bknope@me.com>)>wrote:
> > >
> > >Chris, has the core team discussed opening up a forum for discussing proposal implementations.
> > >
> > >Some of us aren't as skilled as the core team or other contributors but would like to learn. A forum is a much easier place for us to post for code help and to help others with their questions. I think this could help get more involved as it would be a more comfortable format for them. Think of how there are Apple Developer forums and not mailing lists for iOS betas etc.
> > >
> > >I am not saying moving swift-evo to forums *yet* but I believe a lot of the newer programmers are more comfortable with a forum format, especially when it comes to help and discussing code.
> > >
> > >Forums for contributors would:
> > >- be more familiar for a lot of the newer and not as experienced developers
> > >- be easier to search
> > >- be easier to moderate (not really a problem yet)
> >
> > Hi Brandon,
> >
> > Moving from email to a forum system has come up before, but they have some disadvantages.One of major wins of email is that it is pervasive and can be adapted into other forms.For example, if you haven’t seen it yet, check out:
> > https://stylemac.com/hirundo/
> >
> > -Chris
> >
> We've discussed forums on swift-evolution before. Maybe it's time for another go, with Swift 3 winding down.
>
> For context, prior discussions are on this thread:[swift-evolution] Mailman?
>
> (-1 for mailman: it's hard for me to even properly find&link to all the prior discussion about mailing lists, because of how mailman's archive works...)
>
>
> News in the last few days is that Gmane is at least temporarily disappearing:The End of Gmane? – Random Thoughts
>
>
> I'd just like to vote once again forDiscourse(What is Discourse? | Discourse - Civilized Discussion):-Excellent <What is Discourse? | Discourse - Civilized Discussion):-Excellent> web interface(https://meta.discourse.org/\), from the people who brought you Stack Overflow(built-in search, etc.)
> - Read via email if that's your thing: it has "mailing list mode" which includes 1-email-per-post, if that's your cup of tea
> -Reply via email(https://meta.discourse.org/t/replacing-mailing-lists-email-in/13099\)if <https://meta.discourse.org/t/replacing-mailing-lists-email-in/13099\)if> that's your thing
> - It'sopen source(https://github.com/discourse/discourse\)itself <https://github.com/discourse/discourse\)itself>
> - I believe it has ways of getting content as JSON and/or RSS, so I'd hardly say "can be adapted into other forms" is an exclusive feature of email.
>
> And, Discourse providesfree hosting for community-friendly open-source projects(http://blog.discourse.org/2016/03/free-discourse-forum-hosting-for-community-friendly-github-projects/\). Istrongly suspect(https://twitter.com/jtbandes/status/705886542309363712\)Swift <https://twitter.com/jtbandes/status/705886542309363712\)Swift> would qualify for this.
>
>
> There have been several people on this list arguing in favor of mailing lists — I encourage folks to go read the old thread for themselves.
>
> It's worth noting there are also plenty of voices that don't get heard on this list, because people just don't like using mailing lists. One example:https://twitter.com/pilky/status/755105431555608580_______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto: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

+1 for moving all from email because of all that has been said, any
decent forum would be better really but I also love Discourse and would
love to have Swift discussions officially through it.

Hirundo looks really really nice but to me it is an example of how email
is not enough, not the opposite.

···

On Sat, Jul 30, 2016, at 11:42, Tim Vermeulen via swift-evolution wrote:

Does ZenHub have something that even remotely looks like a
forum? I can’t
find anything like that on their website. Or is your suggestion that
we
move all of swift-evo directly to GitHub?

I'm open to ZenHub that can be integrate as part of GitHub for
discussion, pull changes and it makes it easier to reference to
the patches within ZenHub than from Discourse or other forums.
Swiftly right?

https://www.zenhub.com

On Sat, Jul 30, 2016 at 10:10 AM, Tim Vermeulen via swift-evolution<swift-evolution@swift.org(mailto:swift- >> evolution@swift.org)>wrote:

+1. Hirundo makes this format bearable, but it is still far from
ideal. I see many advantages for using Discourse:

- It has actual syntax highlighting.
- It’s easier to moderate.
- It supports real-time updates.
- It’s easier to follow the flow of a conversation.
- It has better search.

I don’t doubt more people will take part in the Swift evolution
process if we switch to Discourse.

Branching...

On Fri, Jul 29, 2016 at 5:22 PM, Chris Lattner via swift-evolution<swift-evolution@swift.org(mailto:swift- >>>> evolution@swift.org)(mailto:swift-evolution@swift.org)>wrote:

On Jul 29, 2016, at 5:14 PM, Brandon Knope<bknope@me.com(mailto:b- >>>>> knope@me.com)(mailto:bknope@me.com)>wrote:

Chris, has the core team discussed opening up a forum for
discussing proposal implementations.

Some of us aren't as skilled as the core team or other
contributors but would like to learn. A forum is a much easier
place for us to post for code help and to help others with their
questions. I think this could help get more involved as it would
be a more comfortable format for them. Think of how there are
Apple Developer forums and not mailing lists for iOS betas etc.

I am not saying moving swift-evo to forums **yet** but I believe
a lot of the newer programmers are more comfortable with a forum
format, especially when it comes to help and discussing code.

Forums for contributors would:
- be more familiar for a lot of the newer and not as experienced
  developers
- be easier to search
- be easier to moderate (not really a problem yet)

Hi Brandon,

Moving from email to a forum system has come up before, but they
have some disadvantages.One of major wins of email is that it is
pervasive and can be adapted into other forms.For example, if you
haven’t seen it yet, check out:
https://stylemac.com/hirundo/

-Chris

We've discussed forums on swift-evolution before. Maybe it's time
for another go, with Swift 3 winding down.

For context, prior discussions are on this thread:
[swift-evolution] Mailman?

(-1 for mailman: it's hard for me to even properly find&link to all
the prior discussion about mailing lists, because of how mailman's
archive works...)

News in the last few days is that Gmane is at least temporarily disappearing:
The End of Gmane? – Random Thoughts

I'd just like to vote once again forDiscourse
(What is Discourse? | Discourse - Civilized Discussion):-Excellentweb interface
(https://meta.discourse.org/\), from the people who brought you
Stack Overflow(built-in search, etc.)
- Read via email if that's your thing: it has "mailing list mode"
  which includes 1-email-per-post, if that's your cup of tea
-Reply via email
(https://meta.discourse.org/t/replacing-mailing-lists-email-in/13099\)
ifthat's[1] your thing
- It'sopen source(https://github.com/discourse/discourse\)itself
- I believe it has ways of getting content as JSON and/or RSS, so
  I'd hardly say "can be adapted into other forms" is an exclusive
  feature of email.

And, Discourse providesfree hosting for community-friendly open-
source projects
(http://blog.discourse.org/2016/03/free-discourse-forum-hosting-for-community-friendly-github-projects/\)
. Istrongly suspect
(https://twitter.com/jtbandes/status/705886542309363712\)Swiftwould
qualify for this.

There have been several people on this list arguing in favor of
mailing lists — I encourage folks to go read the old thread for
themselves.

It's worth noting there are also plenty of voices that don't get
heard on this list, because people just don't like using mailing
lists. One example:
https://twitter.com/pilky/status/755105431555608580_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org(mailto:swift-evolution@swift.org)
https://lists.swift.org/mailman/listinfo/swift-evolution

_________________________________________________
swift-evolution mailing list
swift-evolution@swift.org(mailto: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

Links:

  1. https://meta.discourse.org/t/replacing-mailing-lists-email-in/13099\)ifthat%27s

There's no guarantee we would have to give it up entirely - many forum platforms have apps with caching for offline viewing.

Besides, im not sure these discussions are always so important that you really need to download the entire list and save it all offline.

Karl

···

Sent from my new Email (‎Email - Edison Mail on the App Store)

On Aug 2, 2016 at 6:05 pm, <Rainer Brockerhoff via swift-evolution (mailto:swift-evolution@swift.org)> wrote:

On 8/2/16 12:21, Erica Sadun via swift-evolution wrote:
> It is an instructive example of why remaining with a mailing list, flaws and all, is probably the best answer for Swift Evolution.

Whatever keeps a mailing list as bottom implementation gets my +1.
Forums and other browser-based things may be more convenient _if_ you're
in a place with 24/7 connectivity, which is not true for many.

FWIW I'm using Thunderbird off the gmane group because threading doesn't
work well with other email clients.

--
Rainer Brockerhoff <rainer@brockerhoff.net (mailto:rainer@brockerhoff.net)>
Belo Horizonte, Brazil
"In the affairs of others even fools are wise
In their own business even sages err."
http://brockerhoff.net/blog/ (http://brockerhoff.net/blog/_______________________________________________swift-evolution\)

_______________________________________________ (http://brockerhoff.net/blog/_______________________________________________swift-evolution\)
swift-evolution (http://brockerhoff.net/blog/_______________________________________________swift-evolution\) mailing list (mailto:listswift-evolution@swift.orghttps)
swift-evolution@swift.org (mailto:listswift-evolution@swift.orghttps)
https (mailto:listswift-evolution@swift.orghttps)://lists.swift.org/mailman/listinfo/swift-evolution

The same can be said about an email client and what it renders.

···

On Wed, Aug 3, 2016, at 03:01, Brent Royal-Gordon via swift-evolution wrote:

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".

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: Configure automatic backups for Discourse - admins - Discourse Meta

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.

···

On 03 Aug 2016, at 12:01, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

On Aug 2, 2016, at 10:46 PM, Jacob Bandes-Storch <jtbandes@gmail.com> wrote:

--
Brent Royal-Gordon
Architechies

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

Exactly what I was going to say. Why not use Apple’s forum?
It’s there already. It’s just a matter of using it. Some are saying things like, the core team should be focused on working on the language, etc. That’s so obvious that it shouldn’t even be said. This is a fact, but a fact that has nothing to do with having a good communication medium. It’s just a matter of decision. The core team could decide we use apple’s forum instead of the mailing list, boom, done. If we need any extra features from the forum, it’s not gonna be the core team to deal with. It will be the people that are already responsible for the apple forum.

···

On Aug 3, 2016, at 6:47 AM, David Hart via swift-evolution <swift-evolution@swift.org> wrote:

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 <mailto: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 <brent@architechies.com <mailto:brent@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&gt; which can be used for posting. It also supports bot-like plugins <https://github.com/discourse/try-bot/blob/master/plugin.rb&gt; 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&gt; 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&gt;\. 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: Configure automatic backups for Discourse - admins - Discourse Meta
- 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 <mailto: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

+1

I think this is a great idea! The use of a mailing list is manageable for a small (2-10) groups but doesn’t scale to the size and frequency of comments/replies that the Swift Open Source project has seen thus far. Not to mention, it reeks of 1996.

I’m not sure if we should authenticate users via AppleID, because we want the Swift community to remain cross-platform going forward.

A Slack would be a great idea, for banter but may get crazy. We would want the slack channels to remain subject pure (i.e., no shenanigans). Email is good in this regard in that a reply is expensive and therefore on-topic, whereas slack replies are cheap and therefore easily off topic. Anyone have any idea to combat that? Code of Conduct?

I think in making this decision we should separate the determination that the mailing lists are posing too great a burden at our scale from the selection of what we should use in its stead.

- Sean

···

I think this thread should focus on the mailing list vs forum, Slack is
not a forum. It could be nice to have it as an extra if we need it.

It looks to me that all benefits of a mailing list can be achieved by a
forum system with excellent support to read and reply using emails. But
the opposite is not true, one single simple example: we can't even link
related thread using email (as Tino mentioned on the Gmane thread).

+1 from me as well to anything that allows editing typos after posting.

Charles

···

On Jul 30, 2016, at 8:22 AM, Haravikk via swift-evolution <swift-evolution@swift.org> wrote:

But I like sending out my messages then regretting the many typos and mistakes I only seem able to notice immediately after it's too late to do anything about it!

(so yeah, +1)

On 30 Jul 2016, at 12:39, Johannes Neubauer via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

+1 to move away from mail ;).

Another player might be [Slack][0] or [teamwire][1] . Kotlin uses Slack extensively.

[0]: https://slack.com/
[1]: http://www.teamwire.eu/

Von meinem iPhone gesendet

Am 30.07.2016 um 06:43 schrieb Muse M via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:

I'm open to ZenHub that can be integrate as part of GitHub for discussion, pull changes and it makes it easier to reference to the patches within ZenHub than from Discourse or other forums. Swiftly right?

https://www.zenhub.com <https://www.zenhub.com/&gt;

On Sat, Jul 30, 2016 at 10:10 AM, Tim Vermeulen via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
+1. Hirundo makes this format bearable, but it is still far from ideal. I see many advantages for using Discourse:

- It has actual syntax highlighting.
- It’s easier to moderate.
- It supports real-time updates.
- It’s easier to follow the flow of a conversation.
- It has better search.

I don’t doubt more people will take part in the Swift evolution process if we switch to Discourse.

> Branching...
>
> On Fri, Jul 29, 2016 at 5:22 PM, Chris Lattner via swift-evolution<swift-evolution@swift.org <mailto:swift-evolution@swift.org>(mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>)>wrote:
> > On Jul 29, 2016, at 5:14 PM, Brandon Knope<bknope@me.com <mailto:bknope@me.com>(mailto:bknope@me.com <mailto:bknope@me.com>)>wrote:
> > >
> > >Chris, has the core team discussed opening up a forum for discussing proposal implementations.
> > >
> > >Some of us aren't as skilled as the core team or other contributors but would like to learn. A forum is a much easier place for us to post for code help and to help others with their questions. I think this could help get more involved as it would be a more comfortable format for them. Think of how there are Apple Developer forums and not mailing lists for iOS betas etc.
> > >
> > >I am not saying moving swift-evo to forums *yet* but I believe a lot of the newer programmers are more comfortable with a forum format, especially when it comes to help and discussing code.
> > >
> > >Forums for contributors would:
> > >- be more familiar for a lot of the newer and not as experienced developers
> > >- be easier to search
> > >- be easier to moderate (not really a problem yet)
> >
> > Hi Brandon,
> >
> > Moving from email to a forum system has come up before, but they have some disadvantages.One of major wins of email is that it is pervasive and can be adapted into other forms.For example, if you haven’t seen it yet, check out:
> > https://stylemac.com/hirundo/
> >
> > -Chris
> >
> We've discussed forums on swift-evolution before. Maybe it's time for another go, with Swift 3 winding down.
>
> For context, prior discussions are on this thread:[swift-evolution] Mailman?
>
> (-1 for mailman: it's hard for me to even properly find&link to all the prior discussion about mailing lists, because of how mailman's archive works...)
>
>
> News in the last few days is that Gmane is at least temporarily disappearing:The End of Gmane? – Random Thoughts
>
>
> I'd just like to vote once again forDiscourse(What is Discourse? | Discourse - Civilized Discussion):-Excellent <What is Discourse? | Discourse - Civilized Discussion):-Excellent> web interface(https://meta.discourse.org/\), from the people who brought you Stack Overflow(built-in search, etc.)
> - Read via email if that's your thing: it has "mailing list mode" which includes 1-email-per-post, if that's your cup of tea
> -Reply via email(https://meta.discourse.org/t/replacing-mailing-lists-email-in/13099\)if <https://meta.discourse.org/t/replacing-mailing-lists-email-in/13099\)if> that's your thing
> - It'sopen source(https://github.com/discourse/discourse\)itself <https://github.com/discourse/discourse\)itself>
> - I believe it has ways of getting content as JSON and/or RSS, so I'd hardly say "can be adapted into other forms" is an exclusive feature of email.
>
> And, Discourse providesfree hosting for community-friendly open-source projects(http://blog.discourse.org/2016/03/free-discourse-forum-hosting-for-community-friendly-github-projects/\). Istrongly suspect(https://twitter.com/jtbandes/status/705886542309363712\)Swift <https://twitter.com/jtbandes/status/705886542309363712\)Swift> would qualify for this.
>
>
> There have been several people on this list arguing in favor of mailing lists — I encourage folks to go read the old thread for themselves.
>
> It's worth noting there are also plenty of voices that don't get heard on this list, because people just don't like using mailing lists. One example:https://twitter.com/pilky/status/755105431555608580_______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto: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

+1 for a forum or other editable medium.

···

On Sat, Jul 30, 2016 at 4:55 PM Charles Srstka via swift-evolution < swift-evolution@swift.org> wrote:

+1 from me as well to anything that allows editing typos after posting.

Charles

On Jul 30, 2016, at 8:22 AM, Haravikk via swift-evolution < > swift-evolution@swift.org> wrote:

But I like sending out my messages then regretting the many typos and
mistakes I only seem able to notice immediately after it's too late to do
anything about it!

(so yeah, +1)

On 30 Jul 2016, at 12:39, Johannes Neubauer via swift-evolution < > swift-evolution@swift.org> wrote:

+1 to move away from mail ;).

Another player might be [Slack][0] or [teamwire][1] . Kotlin uses Slack
extensively.

[0]: https://slack.com/
[1]: http://www.teamwire.eu/

Von meinem iPhone gesendet

Am 30.07.2016 um 06:43 schrieb Muse M via swift-evolution < > swift-evolution@swift.org>:

I'm open to ZenHub that can be integrate as part of GitHub for discussion,
pull changes and it makes it easier to reference to the patches within
ZenHub than from Discourse or other forums. Swiftly right?

https://www.zenhub.com

On Sat, Jul 30, 2016 at 10:10 AM, Tim Vermeulen via swift-evolution < > swift-evolution@swift.org> wrote:

+1. Hirundo makes this format bearable, but it is still far from ideal. I
see many advantages for using Discourse:

- It has actual syntax highlighting.
- It’s easier to moderate.
- It supports real-time updates.
- It’s easier to follow the flow of a conversation.
- It has better search.

I don’t doubt more people will take part in the Swift evolution process
if we switch to Discourse.

> Branching...
>
> On Fri, Jul 29, 2016 at 5:22 PM, Chris Lattner via swift-evolution< >> swift-evolution@swift.org(mailto:swift-evolution@swift.org)>wrote:
> > On Jul 29, 2016, at 5:14 PM, Brandon Knope<bknope@me.com(mailto: >> bknope@me.com)>wrote:
> > >
> > >Chris, has the core team discussed opening up a forum for discussing
proposal implementations.
> > >
> > >Some of us aren't as skilled as the core team or other contributors
but would like to learn. A forum is a much easier place for us to post for
code help and to help others with their questions. I think this could help
get more involved as it would be a more comfortable format for them. Think
of how there are Apple Developer forums and not mailing lists for iOS betas
etc.
> > >
> > >I am not saying moving swift-evo to forums *yet* but I believe a lot
of the newer programmers are more comfortable with a forum format,
especially when it comes to help and discussing code.
> > >
> > >Forums for contributors would:
> > >- be more familiar for a lot of the newer and not as experienced
developers
> > >- be easier to search
> > >- be easier to moderate (not really a problem yet)
> >
> > Hi Brandon,
> >
> > Moving from email to a forum system has come up before, but they have
some disadvantages.One of major wins of email is that it is pervasive and
can be adapted into other forms.For example, if you haven’t seen it yet,
check out:
> > https://stylemac.com/hirundo/
> >
> > -Chris
> >
> We've discussed forums on swift-evolution before. Maybe it's time for
another go, with Swift 3 winding down.
>
> For context, prior discussions are on this thread:
[swift-evolution] Mailman?
>
> (-1 for mailman: it's hard for me to even properly find&link to all the
prior discussion about mailing lists, because of how mailman's archive
works...)
>
>
> News in the last few days is that Gmane is at least temporarily
disappearing:
The End of Gmane? – Random Thoughts
>
>
> I'd just like to vote once again forDiscourse(
What is Discourse? | Discourse - Civilized Discussion):-Excellent web interface(
https://meta.discourse.org/\), from the people who brought you Stack
Overflow(built-in search, etc.)
> - Read via email if that's your thing: it has "mailing list mode" which
includes 1-email-per-post, if that's your cup of tea
> -Reply via email(
https://meta.discourse.org/t/replacing-mailing-lists-email-in/13099\)if
that's your thing
> - It'sopen source(https://github.com/discourse/discourse\)itself
> - I believe it has ways of getting content as JSON and/or RSS, so I'd
hardly say "can be adapted into other forms" is an exclusive feature of
email.
>
> And, Discourse providesfree hosting for community-friendly open-source
projects(
http://blog.discourse.org/2016/03/free-discourse-forum-hosting-for-community-friendly-github-projects/\).
Istrongly suspect(
https://twitter.com/jtbandes/status/705886542309363712\)Swift would
qualify for this.
>
>
> There have been several people on this list arguing in favor of mailing
lists — I encourage folks to go read the old thread for themselves.
>
> It's worth noting there are also plenty of voices that don't get heard
on this list, because people just don't like using mailing lists. One
example:
https://twitter.com/pilky/status/755105431555608580_______________________________________________
> 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

_______________________________________________
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

_______________________________________________
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

A scenario I often have to follow, both at home and on trips, is
connect, download everything new, disconnect, read entire threads later
offline.

···

On 8/2/16 13:15, Karl Wagner via swift-evolution wrote:

There's no guarantee we would have to give it up entirely - many forum
platforms have apps with caching for offline viewing.

Besides, im not sure these discussions are always so important that you
really need to download the entire list and save it all offline.

Karl

On Aug 2, 2016 at 6:05 pm, <Rainer Brockerhoff via swift-evolution >> <mailto:swift-evolution@swift.org>> wrote:

On 8/2/16 12:21, Erica Sadun via swift-evolution wrote:
> It is an instructive example of why remaining with a mailing list, flaws and all, is probably the best answer for Swift Evolution.

Whatever keeps a mailing list as bottom implementation gets my +1.
Forums and other browser-based things may be more convenient _if_ you're
in a place with 24/7 connectivity, which is not true for many.

FWIW I'm using Thunderbird off the gmane group because threading doesn't
work well with other email clients.

--
Rainer Brockerhoff <rainer@brockerhoff.net>
Belo Horizonte, Brazil
"In the affairs of others even fools are wise
In their own business even sages err."

I still think it is worth doing a test to see how everyone likes it:

Move swift-users (users who should see a quick benefit from because it would be more familiar) to discourse and see how that plays out. Let people test out all of the features and performance before moving the most popular lists.

Brandon

···

Sent from my iPad

On Aug 3, 2016, at 7:42 AM, David Hart via swift-evolution <swift-evolution@swift.org> wrote:

On 03 Aug 2016, at 12:01, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

On Aug 2, 2016, at 10:46 PM, Jacob Bandes-Storch <jtbandes@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: Configure automatic backups for Discourse - admins - Discourse Meta

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@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

No it can't. An email client renders text (possibly with HTML styling
applied, but most mailing list traffic is just text). The issue of it
being native or not pertains to everything *except for* the text. All of
the chrome, all of the controls for manipulating the client, navigating
between messages, writing replies, etc. All of that stuff is native in
an email client, and non-native in forums software like Discourse.

-Kevin

···

On Wed, Aug 3, 2016, at 11:06 AM, Felipe Cypriano via swift-evolution wrote:

On Wed, Aug 3, 2016, at 03:01, Brent Royal-Gordon via swift- > evolution wrote:

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".

The same can be said about an email client and what it renders.

Even if it is better, someone if going to have to either maintain the server and install of discourse _or_ pay discourse to host it. Until someone on the core team agrees to those terms, what’s the point really?

Has anyone looked into the possibility of extending discourse’ mail support to feed into discourse instead? Then discourse would be the view layer instead of trying to the the truth of the data.

-David

···

On Aug 3, 2016, at 5:21 AM, Brandon Knope via swift-evolution <swift-evolution@swift.org> wrote:

I still think it is worth doing a test to see how everyone likes it: