Sorry for the very late reply.

We would be more than happy to host an instance of Discourse for Ruby
talk. We already host http://parley.rubyrogues.com/ (which is private)
and nutted a lot of the mail only issues.

1. We support reply via email
2. We support creating new topics via email (if explicitly enabled)
3. We support "mailing list mode" in which you get a mail for every post made.

I completely understand the concern about the CLA, despite Discourse
being GPL it does require a CLA for contribution, we have a few topics
on the issues surrounding:
https://meta.discourse.org/t/does-discourse-s-contributor-agreement-provide-an-exit-door-from-open-source/1399
https://meta.discourse.org/t/a-question-on-gpl-licensing-and-the-current-wordpress-debacle/3355
and https://meta.discourse.org/t/discourse-the-gpl-and-per-file-notice/7208

We would be 100% extracting out reusable bits of Discourse into MIT
gems, for example we have https://github.com/discourse/onebox under
MIT and https://github.com/SamSaffron/message_bus under MIT. I would
be more than happy to pull a lot of the mail processing out into its
own gem.

Discourse has a fair amount of advantages when it comes to running a
large group, you could segment out groups that need more private
discussions, or even have "observer only" categories. Talking about
code is easier with syntax highlighting, markdown has its advantages,
search is better and so on.

We could handle a segmented community quite well, you could ignore a
bunch of categories you don't care about and watch ones you do.

On Wed, Jul 2, 2014 at 5:48 PM, Eric Wong <normalperson / yhbt.net> wrote:
> (Adding Sam to the Cc:, since he works on Discourse but I'm not sure
>  if he's subscribed to ruby-talk. (I think Sam must be subscribed to
>  respond to this post, though))
>
> full thread here:
> http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/428556
>
> "Abinoam Jr." <abinoam / gmail.com> wrote:
>> Hi all,
>>
>> Thanks Robert Klemme for raising attention to the issue.
>>
>> I'll throw my own impressions...
>>
>> ABOUT THE CHANNEL
>> 1) Mailing list interest are falling (in general) (this is old news).
>>   - New ways to comunicate are raising and taking place.
>> 2) Web foruns (like phpbb) are one of the things that took place.
>> 3) Stackoverflow more recently.
>> 4) Discourse is probably the future! And it's in rails!
>
> AFAIK, Discourse is as much JS as it is Ruby.
>
>> 5) Lots of rubyists have blogs and concentrate their online activity
>> on Twitter (I only recently have adhered to it (@abinoamjr_en))
>>
>> We could give Discourse a try and move this "community" formed around
>> the mailing list to discourse.
>
> Some of us don't like JS or bloated GUI browsers at all.
>
> However, I understand Discourse is working on email integration,
> so maybe that concern is moot...
>
> Email also has some great, non-obvious things going for it (which I hope
> Discourse supports):
>
> 1) We can easily Cc: folks who may be subject matter experts but not
>    on a particular list.  This is unfortunately uncommon on Ruby lists
>    because they tend to require subscriptions.
>
>    For example, I'm roping Sam into the discussion in hopes he can
>    chime in on Discourse ;)
>
>    Thus email addresses must remain visible and non-obfuscated.
>
> 2) Fallback to private email is important in case:
>    a) the list server goes dead
>    b) the conversation needs to become private
>
>    That means no obfuscating/redirecting emails to go through a
>    central server.
>
> Why I do not contribute to Discourse (or a lot of projects nowadays):
>
> 1) Contributor License Agreement - this is a showstopper
>    The Free Software Foundation is probably the only organization
>    I can trust with this.
>
> 2) It's unclear if contribution is possible via Free Software only
>    (that means not using proprietary web services).
>
>> Same community, new channel. Perhaps it works.
>>
>> ABOUT THE ACTORS
>> 1) Most of the old newbies are now experts and don't enjoy _anymore_
>> joining in basic threads.
>> 2) Newbies don't understand that Ruby _TALK_ is not about "Talking"
>> (relaxed, chatting) about Ruby. <sarcasm>Isn't that
>> obvious?</sarcasm>. And they are suprised when they "relaxed" ask to
>> the list (as they were at an IRC channel) "Hey everybody, anybody
>> could do this homework for me?" and doesn't get "good" answers.
>>
>> But there's freshly debuted 'experts' that are still interested in
>> helping the fresh new newbies. Why not let one help the other? (Well,
>> there's the problem of the signal to noise ratio. Would discourse help
>> with that?)
>
> I don't know if Discourse would help.  Ruby as a language isn't too
> interesting to talk about anymore.  It's mature at this point and its
> strengths and weakness are well-known (and work on removing the
> weaknesses mostly happens on the ruby-core list :)
>
>> ABOUT THE CONTENT
>> 1) The more free Ruby content available in the internet the less prone
>> to ask to list people are. So it's "natural" to the traffic to fade
>> down as Ruby solidify itself. (More true if we prohibit the newbies to
>> ask anything that is already somewhere on the internet).
>
> Right, the quality of Ruby documentation has gotten much better
> in recent years (thanks to the likes of drbrain and zzak!).
>
>> 2) If newbies ask freely:
>>   - Noise raises (but noise for some, signal for others)
>> 3) Why not segmentate the list?
>>   - Ruby-newbies for a more welcoming mailing list where people that
>> don't care to receive a lot of traffic with newbie questions could
>> join together to welcome, and take care of the new members that are
>> coming to help grow our community.
>>   - Ruby-??? for a more "rigid behavioured" mailing list with a clear
>> set of rules to ask and to answer so that it could make it a
>> high-quality content list?
>>   - Could discourse solve this kind of separation well?
>
> I want _less_ segregation/segmentation, and even merging ruby-talk with
> ruby-core would be great.  Every Ruby user is a potential Ruby core dev
> (and every Ruby core dev is already a Ruby user).
>
> Furthermore, it'd be nice to open the lists to non-subscribers and make
> it easier to rope in folks who may not be subscribed or paying
> attention.
>
> What I'm describing is common practice on the high-traffic git and Linux
> kernel mailing lists and works pretty well.  Spam isn't a big problem
> with good filtering; rejecting HTML and Bcc: seems to help greatly, too.