我所在的 Discourse 社区相对较新，但已迅速变得异常活跃——部分原因是从旧解决方案迁移到了新平台。Discourse 确实更胜一筹。
我们有一些关键成员认为 Discourse 的默认邮件通知不够充分（或不够全面），且他们不愿或无法利用自己的邮件系统作为解决方案的一部分；我们正在努力满足他们的需求。
在搜索过程中，我们发现可以通过 恢复邮件列表模式每日摘要 插件重新启用旧版的“邮件列表模式每日摘要”功能。
然而，我们也注意到这可能会引发问题——既包括潜在的 SMTP 流量压力（我们是自托管部署），也包括潜在的冲突和未来 bug（Discourse 更新有时会破坏该插件，届时我们需要等待插件修复）。
我们发现最近的 Discourse Priority Action Mailer 插件 可能有助于解决 SMTP 流量问题，但另一插件未来出现问题的风险依然存在。
因此，我们的问题是：
目前实现邮件列表模式（MLM）每日摘要的最佳方式是什么，以最大程度降低该方案在未来某时点失效的风险？
我们的具体使用场景如下：
该群体的“董事会”通过一系列长期运行的在线会议开展业务，相关讨论线程必须对所有成员开放，无论其是否参与 Discourse 论坛。这些线程将作为专为该目的创建的受限分类中的主题。我们暂且称其为“董事会会议”分类。
我们希望为用户提供开启邮件列表模式的选项，使其能够收到“董事会会议”分类内所有主题的完整邮件（包含所有回复），并将所有消息合并为每日发送的一封邮件（类似传统邮件列表的每日摘要）。每个活跃主题每天发送一封邮件或许可以接受，但每收到一条回复就发送一封邮件则完全不可接受。
这是他们在使用 Discourse 之前的解决方案中已具备的功能，无需对其邮件客户端进行任何额外操作。除非我们能满足这一需求，否则他们对迁移到 Discourse 感到不满。
提前感谢任何建议或指向其他解决方案/主题的链接。
neounix
(Dark Matter)
2
在你上面的帖子中，你基本上是在说（至少从我读到的内容来看），你认为插件是不可接受的，因为（就你上面提到的两个插件而言），你暗示它们未来可能会失效。
这似乎再次表明，你总体上反对“非官方”插件；但你又希望获得尚未“正式”提供的自定义功能。
在我看来，基于你读了两遍你的帖子，@MentalNomad，你应该聘请一位专业的 Discourse 插件开发者来为你特定的使用场景设计和维护一个插件。这将实现你网站的目标，并且你可以确保你的自定义插件在未来 Discourse 核心发生变化时（这可能会影响插件）仍能正常运行。
听起来合理吗？
所有“非官方”的 Discourse 插件在 Discourse 升级核心时都有失效的风险。有些插件开发者会维护他们的代码，而有些则可能不会。当你需要自定义功能并担心这种风险时，从你的帖子来看，一个不错的选择是在 Marketplace 发布你的需求，让专业人士为你开发一个符合你要求的插件。
一般来说（但并非总是如此），修改 Discourse 核心功能的插件需要打开并修改 Ruby 类。修改任何核心 Ruby 类都存在因核心变更而失效的风险。通常来说，当你希望扩展功能时，情况总是如此：如果你希望确保“非官方”Discourse 插件代码随时间得到维护，你就需要自己维护这些代码。
希望这能有所帮助。
恐怕我给您留下了错误的印象，@neounix。
并非如此。不过，我们的 IT 团队在查阅了相关插件的讨论帖后感到担忧，因为这些插件确实在过去的核心更新后出现过故障。这与其说是“某事可能会出问题”，不如说是“这事已经出过问题了”。
不，完全不是！我只是希望能得到一些反馈：是否有其他可用的插件（无论是官方的还是非官方的）可能更合适或更可靠；或者是否有消息表明影响这些插件的特定问题属于异常情况，不太可能频繁发生。换句话说，我正在为我们的团队寻求建议。
这也并不完全准确……我们很乐意听到：我们部分用户所要求的功能可以通过某种更官方或侵入性更小的方式实现；或者甚至只是了解到存在某个我们尚未发现的现有功能，能够解决用户们提出的问题。
事实上，我正是在询问解决当前需求的最佳途径。希望这听起来合情合理。
虽然感谢您的时间和关注，但我不明白，既然已有插件符合使用场景，为何还要花钱请人再开发一个插件。开发（以及调试和维护）另一个新插件，似乎是一种可靠性更低的做法。
neounix
(Dark Matter)
4
@MentalNomad，这完全不是事实。
我是你提到的其中一个插件的作者（我几天前才发布该插件），该插件从未出现故障，也没有任何讨论帖提到过相关问题。事实上，它运行完美，毫无错误。
我并非鼓吹你使用我的插件，但你对它的说法完全错误，因此我在此纠正你。
关于该插件的陈述在事实上是不准确的，很抱歉告诉你这一点，@MentalNomad 
你将它们合称为“它们”，而“它们”确实出现了问题，因为该组内一直存在故障。
当我提及它们时，我是这样表述的：
不过，让我们停止在措辞上争辩吧。我很感激你的插件的存在以及你为开发它所做的努力，也感谢所有为你插件提供代码贡献的人，感谢所有参与 MLM Daily Summary 插件开发的人员，以及创建初始 MLM Daily Summary 功能并辛勤维护 Discourse 的 Discourse 开发者们。
但我在此是为了寻求建议，了解如何利用现有工具最佳且最可靠地满足用户需求；谢谢。
neounix
(Dark Matter)
6
嘿 @MentalNomad
祝愿你和你的 IT 团队能满足你们的需求。Marketplace
保重，很高兴你澄清了你的帖子！
michaeld
(Michael - Communiteq)
7
插件出问题的频率并不重要，重要的是修复的速度有多快。只要插件得到积极维护，在大多数用户甚至察觉到它出问题时，问题就已经被修复了。
我甚至认为，插件越庞大，它出问题的频率就越高（但也会被更快地修复）。
asirota
(Alex Sirota)
9
我建议你们与这些关键成员沟通，向他们说明满足他们要求需要投入多少精力。有时，少数意见强烈的人并不能代表实际的需求。
另一方面，如果他们对电子邮件如此依赖，也许你们认为 Discourse 适合这个群体的看法有所偏差？或许他们真正需要且值得拥有的只是一个邮件列表。
您善意的评论我们已收到。
不过，为提醒各位注意这里的语境，需要说明的是，我们讨论的是一个名为“理事会”（Board）的小型子群体，其分类名称为“理事会会议”（Board Meetings），这并非偶然。
Discourse 对于绝大多数更广泛群体的讨论来说，绝对是极其合适的选择。只有这一小部分领域存在问题，而在此情况下要界定何为“应得”并不简单，既因为涉及的人员因素，也因为背后有着悠久的传统。
我完全同意！但如果我遗漏了某个维护更好且能满足此需求的插件，非常欢迎提供相关反馈。
michaeld
(Michael - Communiteq)
11
上次该插件出现问题时，一天内就得到了修复。如果这还无法满足您的要求，那么您确实应该尝试在没有插件的情况下生活。
是否可以考虑让他们使用邮件列表（例如 Mailman），并将该列表以只读方式镜像到“董事会会议”Discourse 类别，供其他人查看？
搜索“邮件列表镜像”时，这里会出现几个相关主题。
asirota
(Alex Sirota)
13
这主意真妙。这下可让他们见识了。只要让他们待在仅限电子邮件的环境里就行。
这个建议很有趣。我会提出并着手研究，但我怀疑大多数人可能更倾向于直接使用 Discourse。如果我们能将两者结合起来，或许行得通。
我其实也这么想过……但随后意识到，这样做只会让少数人满意，大多数人并不会。
riking
(Kane York)
15
我认为这其中不寻常的一点是，你只需要针对单一分类的每日摘要，而不是整个论坛。据我所知，目前还没有现成的工具可以实现这一功能。
是的，这确实有些“奇怪”。一个能够生成每日摘要并允许用户指定包含哪些类别的工具也能满足需求。
我们刚刚安装并让人测试了“恢复邮件列表模式每日摘要”功能……单封邮件的体积对于一天来说相当大，达到了 341KB，但真正的问题在于，当用户打开邮件时，图片下载导致他的手机运行吃力。
我们正考虑根据我们的需求对其进行修改，将其硬编码为仅针对目标类别。该类别的活跃度远低于整个站点，且图片极少甚至没有。这样既能满足那些坚持需要此功能的“关键”人员（针对“董事会会议”类别），又能让普通……呃，典型用户按照 Discourse 的设计初衷进行交互。
rogerco
(Roger CO)
17
这是一个有趣且有益的讨论。我一直在研究类似的内容，但并非完全相同。我希望能够生成一个每日新话题列表，并可选择性地列出指定子类别中新回复的数量。这些内容将通过 API 跨平台发布到聊天服务中，同时也为“老派”用户生成邮件。
实际上，我们会为不同类别的子集生成多种不同的摘要，并将其发送至不同的目的地。
这样做一方面是为了提升用户参与度，引导人们避免在聊天中进行深入讨论；另一方面也是为了吸引那些非数字化的爱好者——他们仍觉得像邮递员派送清单这样的形式既酷又先进（表情：翻白眼）（当然，这份清单只能是只读的！），或者更倾向于纯文本交流，而非花哨炫目的网站（这类用户确实存在！表情：独角兽）。
我很期待看到你们会提出怎样的解决方案……
rogerco
(Roger CO)
18
如果这应该是摘要而非完整复制，何不直接排除图片？让用户去网站获取完整内容。