关于谁可以被提及以及何时可以被提及的政策因论坛而异。在这里，我们时不时会看到这类评论：
抱歉之前@了你，我不知道这是不礼貌的行为。
我们是否可以在某个地方设置一个选项——也许是一个专门的群组——来限制谁不能被提及？但这可能会过于限制，并且应该有额外的设置来规定谁以及何时可以使用提及功能——以允许工作人员和其他后台群组的工作。
此外，错误消息应该比“您不允许提及该人”这种笼统的提示信息更具信息量。
我有一种不好的预感，这又是一次草稿，意味着在技术上很难实现，但同样——我对开发方面的知识为零。如果它很容易实现，我们早就有了，对吧？
但是，用户使用了一个本不应使用的工具，这种情况相当奇怪。
（AI建议的标题何时@是禁忌：管理论坛提及政策 
）
我相信这是最近一次#marketplace 的主题：
很高兴知道，因为我不关注 Marketplace — 但我仍然不明白为什么它不是核心部分。
Discourse 的核心功能之所以不会通过传真向您发送社区心跳，原因也是一样的。正如我们所见，这方面的需求并不大，尤其是在 CDCK 团队为其客户所做的工作范围内。幸运的是，它是开源的，理论上，一旦有人承担这项任务，无论其条件如何，都可以实现此功能。因此，您可以加入我们的这个市场请求，我们可以增加预算，以便更快地找到潜在的开发人员。到目前为止，该市场请求还没有收到任何回复。
这是最糟糕的理由之一，你也知道 
不是因为像固定电话或支票（我甚至无法写出这个词，一张充当现金的纸）这样古老的工具的例子，而是因为 Discourse 只是一段代码。我们在这里讨论的是限制操作的工具。就像我们可以限制 Discourse 何时何地弹出屏幕或在我手腕上发出哔哔声一样。
我完全理解需要限制信息流。但这应该通过设置和自动化来实现，使用一种比在用户使用广泛使用的工具时进行唠叨更文明的方式。
不。我没有兴趣讨论 Meta 的政策。我曾用这个论坛作为例子，说明为什么需要并存在此类选项的需求。
你的解决方案是付费才能获得限制内置操作的选项。我希望看到软件本身提供一个选项来调整其自身行为。就像我们可以处理其他所有事情一样。
如果由于 Discourse 的技术结构，包括工作量，而导致这项任务不可能完成，那么人为的唠叨是更便宜的选择，那么我很高兴——但我希望听到这个。或者……如果在这个人工智能时代，没有人认为我们应该拥有比人类审核和更长的规则手册更可靠的工具，那么这个功能请求将永远无法满足“三个规则”的要求，甚至无法满足企业客户的需求，那也没关系。
关于礼仪，在某种程度上都取决于上下文。
要求某人参与某个支持话题是不合适的，但在其他场合提及他们，例如引用他们 elsewhere 的参与或表示感谢，则是完全合适的。即使你能找出在代码中实现这种行为的逻辑，用户也不一定会理解。
正是如此。这就是为什么我们需要/他们/每个人需要一个额外的设置。
当然，如果不能限制提及的真正原因是它会轻易破坏后台作业（再次以…为例），比如团队的消息传递或其他任何在那里运行的东西，那是可以理解的。
我曾在现场支持和销售部门工作过。我没有做太多全球市场的工作，但做过斯堪的纳维亚市场。但英国人有一种非常强烈的倾向，如果他们的要求没有得到满足，就会立即联系主管。这就是为什么客户根本无法获得电子邮件地址和电话号码。我们不依赖于要求客户不要打扰他们，因为他们也有其他工作要做。
限制提及也是同样的道理。环境不同，但原则完全相同。
我们面临同样的问题，但由于在 Discourse 结构中提及高层人士不礼貌（而且我不确定该标记谁来提请他们注意此请求），我们只能希望他们偶然发现一个有趣的功能请求，或者它能被 Meta-Discourse 的爱好者通过他们可能共享的任何内部渠道来解决。
同时，我们作为一个使用这款出色产品的社区，可以通过资助外包开发来帮助改进其关键功能。市场请求甚至可以有一个很棒的众筹功能——这给了我们另一个可行的想法来实施。 
此主题与此主题基本相同：
我不确定那个插件对@提及是否会有那么大的帮助？我认为它只适用于私信。
似乎是双重目的：
编辑：这仅在帖子顶部的信息块中提到，其他地方均未提及，我不确定这是否确实是该插件的一部分。
我的借口是我从5公里跑步回家，外面是-10摄氏度/14华氏度，我满身大汗，焦急地等待桑拿。
现在我要去读我最初链接的内容了……
抱歉误导了您的总结，我弄错了。我们赞助的插件仅限制私信，不影响提及。