Adding content from a mailing list discussion for the record:

My main concern is that this move is just moving the problem temporarily and that this is asking the community to move to yet another service. The big question to me is “where does the community lives ?” Is it stackoverfow, slack, discuss, youtube. There is fragmentation already.

I agree that it's weird right now with both discuss and mailing lists, which is why we've been evaluating things over the last few months. YouTube is a separate thing, I think it's for people who want to consume video meetings and there's not much overlap. I believe that StackOverflow does a great job for answering technical questions, and we do encourage people who have technical questions to go to SO. What this is trying to do is to tie it all together, let me give you some examples:

This past week Bob, Jeff Sica, and I have been working on more unifying things in discuss, like automatically publishing Kubernetes release notes in the announcement section and then tying that in to a bot to announce on both slack and twitter. The idea here is for us to have one source of truth (github), and then one source of aggregation(discuss), which can then fan announce in places users are, like twitter/slack.

Or another example, I've been publishing the meeting notes to the community meeting with a video in one thread (https://discuss.kubernetes.io/t/kubernetes-weekly-community-meeting/35) so that you can just subscribe to that and get the latest community meeting notes, similar to a newsletter. This helps tie in all the things in google docs (that are hard to find unless you know where to look.) By itself it's not that big a deal, but when you combine it with having Josh's content on the same subforum (https://discuss.kubernetes.io/t/last-week-in-kubernetes-development-july-22nd-2018/1260) it starts to become more valuable. As we find more valuable information for people we can help surface it.

However to do all this kind of aggregation, one-stop-shop for all things Kubernetes we need something more powerful than a mailing list, which is where having a Discourse API is so handy. On the outset it's easy to think about it as just a forum or list, but what we're really asking for here is to have our discussions be more API based so our automation-obsessed community can help get the signal out to users while muting the noise. We haven't even gotten to the more powerful features yet, like the ability to move off-topic discussions from github to discuss, or the ability to embed subforums on the website. We are currently talking to the CNCF web team about how best to bring the good dynamic content in a more visible place, a new skin, better integration with the website, that sort of thing. For at least the next 6 months the priority is going to be aggregating and giving people one place to go.

For all that to happen we need critical mass, which is why we're asking to sunset the list. We know it will be disruptive in the near term but ultimately better in the long term. I agree with Dan that Kubernetes as a whole should eventually consume the entire platform instead of lists, I think the user list is a good place to start so the community can get more comfortable with it. And I'd like to make it available as opt-in for SIGs and WGs who want to try it in lieu of a traditional list. I think we have a few more automation/features we'd need to think about to make it more appealing to k8s developers, we are very keen in making sure we put thought into this as we don't want to disrupt k8s development.

One more platform is going to create even more fragmentation at the cost of dependency on yet another third party tool .

While we are using the Discourse the hosted-service, the software itself is OSS and we have full access to our data. Other OSS projects have either contributed or sponsored features in the software so I think when we compare that to say StackOverflow, Slack, or Google Groups that we have more control over our destiny than before. Slack announced removing it's XMPP/IRC gateways while we were in the middle of writing this proposal, so it was important reminder for us to consider our future options!

I hope this addresses some of your concerns!

Regarding the “spam” i hope you can turn on a blocker for certain keywords no matter the trust level.

Just a follow up on this, there is a custom word block feature. I was able to find lots of curated lists of horrible words on the internet (yay internet!) and have imported them. The input form won't allow a post to go through, instead they will receive an error which tells them the exact word that has been blocked and they must remove it before it accepts a post. The user has the ability to flag a moderator if there's a false positive.

I believe it was @bgrant0607 that mentioned g docs and calendar. how does that play out if you were to archive the ml?

@wadadli - mailing lists can't own calendar items or gdocs so we are good to go there. the mailing list is also not listed as being invited to any meetings that we currently run (sigs, wg, office hours, moc, etc.).

For the record, I was referring to SIG mailing lists rather than kubernetes-users@. Mailing lists can be invited to meetings and docs can be shared with them.

Following up on a discussion in slack. It may be worth setting up localized categories and engaging with active community members from those regions to preemptively establish native-language moderation teams.

With that in mind, here are the to dos:

• Create Regional Categories
• Establish native-language moderation teams

• Move the automated posting from jeefy's personal account to something like k8s-bot, this account must be owned by contribex.
• Move the zapier account to a cncf credit card. I can expense this for now. This account must be owned by contribex.
• Move the discourse credit card to a cncf credit card.
• Establish workflow guidelines for the zapier account. (we can probably use this zapier thing for other automation across the project, we should think about smart ways to do this).
• Connect discuss to @kubernetescontributor on twitter
• Connect discuss to #announcements and #events on slack. This will need an app permission and the usual due diligence for adding a slack bot.
• Implement whatever design/theme Alex submits.
• Release team is connected to the announcements section and this is automated, we should consider migrating kubernetes-announce@ as well.
• NNTP gateway account so people can read messages via gmane.

I read the mailing list as the news group gmane.comp.containers.kubernetes.user on gmane.org. I know that others – albeit not many – do that same. I have admin access for gmane's configuration, so maybe a transition is possible. New messages must be sent to gccku-kubernetes-user at m.gmane.org.

@bronger This should be doable, we could create an account called "gmane gateway" or something and then have it subscribe to the group and then tweak it's email settings to send every mail sent to the "General Discussions" category. I'll add it as a work item.

Would it be possible to get a test newsgroup or something set up so we can play with the settings? I am hesitant to start sending mails to that address without testing how noisy it is first. (Feel free to contact me via mail listed in my github profile).

/close

@parispittman: Closing this issue.