在我管理的论坛中，邮件列表模式已启用数月。然而就在几小时前，该设置突然被停用。这是怎么回事？
现在的状态如下：
我查看了工作人员操作日志，但在那个时间段内没有任何相关记录。
可能是什么原因导致的？
编辑： 我现在已重新启用该功能，并已向所有受影响的用户发送了消息。
Discourse 现在默认将“禁用邮件列表模式”设置的值设为 true。如果您的站点用户曾使用邮件列表模式，将“禁用邮件列表模式”设置重新改为 false，即可再次向他们发送邮件列表邮件。
我明白了。不过，这可能会影响所有使用此功能的 Discourse 用户，涉及所有 Discourse 安装实例。我建议开发团队在类似情况下更加谨慎，并且可能不要自动在现有实例上恢复此设置。
在我们的案例中，有 20 小时的邮件丢失，而且每位受影响的用户都收到了一条消息（Discourse 并不特别方便单独向用户发送消息）。
无论如何，感谢您的解答。
做出这一决定并非轻率之举。这是基于我们观察到的极端现实问题：对于自托管用户和其他 Discourse 安装，邮件成本急剧飙升。
我们选择了一个更安全的默认设置，以帮助人们控制成本。
@sam：@deeplow 表达的惊讶（我也有同感）让我很好奇：Discourse 管理员是否可以订阅某个类别，以便在不密切跟踪 Discourse 开发的情况下，及时了解推送到社区的高层变更——尤其是破坏性变更？
对我来说，问题不在于变更本身，而在于完全 措手不及，随后不得不排查出错原因。不过，也许我只是漏掉了一个应该关注的公告类别？（浏览时我看到了 releases 类别，但查看该类别本周的话题，并没有发现任何能在该变更发生前引起我注意的内容；即便事后知道该留意什么，我也没看到相关提及。）
谢谢，
-Brad
附：它链接到 release-notes 标签。
我理解事先不知情会让人感到不安，我们一直尽力让社区同行，而且这一变更已在此处提及。
关注 release-notes 和 #feature:announcements 标签，您将能及时获知此类变更。
我在发布说明中看到了这一点，但对其未得到更突出的展示感到意外。
对于全新安装更改默认设置是合理的，但在现有论坛上切换默认设置对我们管理员来说可能有些欠妥。请问今后能否避免这样做？
嗨 @TallTrees，更改默认设置的情况极为罕见。我们深知这会影响现有站点。据我所知，在我加入团队的 3 年多时间里，我们只这样做过两次。正如 Sam 所说：
我们正在讨论，若未来不得不进行此类操作，应如何调整相关流程。同时，我强烈建议您阅读发布说明——即使未来我们不再调整流程，像这样的内容也会包含在发布说明中，而发布说明会与我们发布新版本测试版的同时公开。
作为付费客户，我不期望必须阅读每一次测试版发布说明的通告，以避免让用户感到意外。我们选择 SaaS 解决方案，是因为运营论坛并非我们的主业——我们需要的是一个沟通平台，但其维护工作是一种干扰，没有人有时间专注于此。
此外，据我所知，“测试版”（beta）版本实际上会部署到我们的生产环境中，因此这个命名可能并不恰当？
回顾并重新阅读发布说明中的陈述，我认为措辞在描述实际变更的性质方面存在歧义：
我们现已通过站点设置默认禁用邮件列表模式，以防止站点因发出大量邮件而产生意外的高额费用。
我认为，通常当人们想到默认设置变更时，并不会认为他们特定的选择会在未来被覆盖。这种情况就好比 YouTube 在我多次关闭“自动播放下一个视频”功能后，每次应用升级又将其重新开启；或者营销人员在我仅退订其主订阅列表中的某个分支后，仍持续向我发送邮件。
依我之见，这是一个很好的建议，有助于维持用户对 Discourse 的良好印象。否则，这一变更会被用户视为一种故障，而非对管理员体验的改进。
@mattdm，我不同意你的观点。请相信，这一变更已在团队内部引发了大量讨论。我们确实会尽量避免此类破坏性变更，尤其是那些影响最终用户的变更。我们在这里失策了。我们认识到其造成的影响，并对此表示歉意。
同意。我们今天早些时候已经做出了调整。在默认设置变更之前，任何在个人偏好中启用过邮件列表模式的站点，该模式将重新启用。
已收到。
太棒了，感谢您的聆听：heart: