+1 for Discourse. It is much more accessible. When I subscribed to swift-evolution I was curious how bigger discussions would work since I used mailing-lists only for small teams yet. After some replies to a thread it started to get really ugly to quote relevant parts of several old posts and to keep track of all the information (not only for me which leads to unnecessary misunderstandings). Further on, it is very time-consuming to filter the information that you want to have. Features like „watch“ a thread help to customize for which threads I would like to retrieve emails or not.
Github itself uses this for issues, too. If you create an issue, you will get mail. You can unsubscribe to the issue. You can subscribe to issues you are interested in. You can click on a link in the mail leading directly to the corresponding comment in the issue. All the best Johannes > Am 04.08.2016 um 05:34 schrieb Brandon Knope via swift-evolution > <swift-evolution@swift.org>: > > Using Apple Developer Forums would cause people to leave swift-evolution (a > prediction). I don’t think they offer a good enough experience for quick > discussions like mailing lists or Discourse do. > > My question is: would we gain more people than we would lose in moving over > to something like Discourse? > > I don’t think a lot of people on here are grasping the high burden mailing > lists place on people not familiar with them > > Brandon > >> On Aug 3, 2016, at 10:02 PM, Paulo Faria via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> 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> 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> 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 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. >>>> >>>> >>>> 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 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. 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 >>>> - 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 >> >> _______________________________________________ >> 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 -- Dr. Johannes Neubauer E-Mail: neuba...@kingsware.de WWW : http://www.kingsware.de
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
