继续关于 为 Discourse 反应添加选项 的讨论：
请提供一些支持功能来替换 Retort，允许用户对任何单个帖子发布多个反应（如果需要，可以从有限的集合中选择，但集合由管理员选择，管理员选择的数量没有限制）。
例如，
是表达同意的一个好选项，但同一个反应者可能想表达 
来表示对某件悲伤事情的同情。多种反应还有很多其他的用例。限制用户只能选择一种反应方式会令人沮丧。
此外，设置自定义反应应该是一个选项，管理员可以上传任意标题的任意图片。这样，社区就可以设置特定于其社区的反应。
该功能可以是改进版的 Discourse Reactions，也可以是一些额外的“多重反应”插件，本质上是 Retort 的维护版本。目前的 Discourse Reactions 无法充分替代 Retort。
显示反应的地方，这些反应对于传达情感毫无价值。这就是为什么我所知道的所有平台都将给出的反应限制为一个。
如果有人想从文字转为图形，它已经存在了。
所以，我不明白，原因肯定在我身上 
我不认为有人建议强制使用，这很可能只是插件中的一个可选设置。 
每个社区都不同，每个社区都会发现不同的功能是可取的。很多人一直在享受 Retort 插件，所以肯定有一些人想要这个功能。 
当然有。就像外面有很多人喜欢用标签作为话题标签，或者用表情符号代替文字一样。
这仍然是一种污染，因为数百万只苍蝇有时也会出错 
现在我们深入了纯粹的元讨论。
当然，如果可以选择允许使用多个反应，那么管理员可以决定提供什么或不提供什么。但是……我们没有多个类别，因为使用它们毫无意义。这是另一个毫无意义的选项
我很想看看一个话题或帖子在有人决定使用多个反应来讲述一个简短的故事时会是什么样子，就像很多人在 Instagram 上滥用话题标签一样。
所以，如果团队必须选择要开始构建和开发哪些功能，我会说这个功能不在列表的前列。如果所有的反应都加 1 分（因为现在多个反应的选项是减慢 TL 增加的一个原因），那会好得多。
Slack 也是如此。它在聊天/论坛领域并非小众产品。
我同意这里的其他人，这可能对某些社区有意义。有一个启用它的设置并不会强迫任何社区使用该功能。
需要记住的一点是指标。一个用户添加 17 个反应仍然应该算作一次用户一次反应。
我们的reactions插件只允许一个表情符号映射为“喜欢”（这会影响热门话题、摘要等），所以这应该不是问题。
我就是不同意。你真的在争论说标记 
和 
因为它们是两个反应，所以对于表达情感毫无价值吗？
那个 是指 /s 吗？显然，坚持类别对于分类具有结构性价值，但另一种选择是 Discourse 提供的标签。而且，帖子的标记（而不是仅限于主题）确实可能很有用。多个反应（类似 Retort 的风格）实际上允许了一种版本，因为可以添加自定义反应并标记它们，它们可以是任何上传的图片和任何名称。例如，在我使用的 Discourse 实例中，有一个 Retort 反应，标签是“changed_my_mind”，这在选项中确实非常棒。
GitHub 也是一个允许多个反应的平台，而且它确实很好用。曾经只有喜欢或赞成/反对是常见的，拥有各种反应并不是什么新鲜事。那时，拥有各种反应选择和今天一样有用，只是开发者/设计师社区还没有意识到。现在他们意识到了，共识支持提供各种反应。允许人们标记对一个帖子的多个反应是相同的模式。它足够有用，以至于任何拥有它的人都不会想让它消失，而且总有一天它会成为共识，一旦每个人都意识到它，而今天任何怀疑它的人都只是在进行同样的反对，就像当初抵制拥有各种反应的人一样。
这确实是一个事实。它们毫无价值，仅出于两个原因而需要：
如果你看看任何社交媒体平台，你会发现大多数用户都不使用它们。他们只给一个赞。
如果我给你的回答一个反应，
是意味着你感到困惑，还是你写的东西令人困惑？
是我生你的气，还是这个情境让我的脑袋炸开了？ 是我为你感到难过，还是描述的情况令人难过？
是我在嘲笑你，和你一起笑，还是情境本身很可笑？反应是为平台（类似Facebook）设计的，相对很少使用，而且确实令人困惑（并且被误解的表情符号已经引发了无数的争吵），我只是想知道谁更想要更多的表情符号：管理员还是用户？
而且，获得一大堆表情符号而不是几个，也是对用户体验的犯罪
您是否会考虑一个建议，即用更多的问号来表达您的想法？像“事实如此”（作为您陈述观点的描述）和“毫无价值”这样的绝对断言，与寻求“零假设”（寻找您可能出错的地方，这最终会支持您的原始观点或引导您学习）的态度相比，更有可能降低您自己学习的机会。
以下是 Retort 的多重反应的一个具体用例（这只是无限潜在示例中的一个）：
而且，在我们的 Discourse 实例上，我们专门地并且普遍地使用多种这些自定义标签的反应，以表明这些不同的、互补的含义，这些含义具有关于语义和重要性的共识。如果您怀疑其效用，那仅仅表明您有些愤世嫉俗。我们的设置的效用毋庸置疑。
在任何特定社区中，规范都可以通过计划或随着时间的推移而自然产生，事实上，许多表情符号在社交媒体世界中已经具有普遍的共识含义。我可以轻松想象各种社区使用具有特定内部含义的反应。我并不是在争辩说图像本身具有固有的、存在于社会中介语境之外的含义，或者说天真的人会自动理解其含义。我断言（有证据和经验支持）多种反应可以具有巨大的效用。
我提到了 GitHub，它们也使用一小部分表情符号，而不是任意选择的。用户在那里也会对帖子发表多种反应，这很有用且有意义。
在我看来，“好极了”、“哈哈”、“完全同意”、“同情”和“谢谢”这些反应都可以用“点赞”的“赞赏”反应来代替，而且不会有任何问题？你能给我一个具体的例子，说明在一个帖子中，你可以用多个这些反应来回应，并且它实际上改变了回应的含义吗？
这种观点就等同于说我们可以从英语中删除这些短语而不会有问题。显然，这些词语有不同的含义和内涵。
我们论坛上几乎百分之百的帖子都是其重要性的例证。我们明确描述过“欣赏”的意思是“感谢此帖”，就像“此帖有建设性贡献”一样，例如“我很欣赏这个帖子被发出来”。这一点也不表示我同意此帖。这极大地改变了我们的互动方式以及我们对互动的感受。如果点赞意味着同意，那么你就不能对一个表达了你不同意的观点的帖子做出反应。能够对一个表达了我不认同的观点但却经过深思熟虑的帖子，感到高兴地给出点赞“欣赏”，这真是令人耳目一新。我很欣赏他们深思熟虑地分享了他们的观点（这不是我对每个帖子都有的感觉，我不欣赏自以为是、啰嗦、离题或轻蔑的帖子）。所以，我们给出的欣赏比其他论坛要多得多，而且这样做感觉很好！能够承认已阅读并欣赏了一个帖子，而不必担心该反应会被误解为同意，这真是太自由了。所有这些数量更多的欣赏，使得简单的承认有了更公开的可见性，并形成了一个更友好、更支持性的社区。
因此，在这种情况下，万岁是用来庆祝“我们发布了！”这样的帖子，就像 GitHub 使用 
一样，它比 更强烈、更不同。而“哈哈”是分享一些幽默，当然不是所有帖子都适用。“完全同意”作为 是同意的指标（同样，与欣赏帖子不同）。同情是在人们分享令人不安的事情时表达同情。最后，“谢谢”作为 
是后来添加的，当时人们发现他们确实想要表达更强烈的感激之情（例如，对于一个说“我整个周末都在做这个，这是我取得的进展”的帖子），这与仅仅说点赞、谢谢你的帖子不同。这更多的是感谢你的工作等等。我们普遍认为 对于一直以来的通用使用来说，情感上太强烈了，并且不同意将其作为默认反应，但当我们想要表达更强烈的情感时，我们会怀念它。
而多重反应的意思是：我想表达对一个帖子的欣赏和同情，有时一个帖子同时包含幽默和悲剧，同情+哈哈实际上是有意义的。而且反应不会像回复帖子那样制造太多的噪音……我的意思是，我觉得我好像在解释为什么会有反应这回事，但这与这里的主题无关。显然，曾经有过论坛没有反应的时代，但现在每个人都更喜欢有反应，官方插件现在支持多种选择，所以对于提供不同选项已经达成了共识。唯一没有就允许人们对同一帖子做出多种反应达成共识的原因，与过去没有选择的原因相同——人们尚未认识到其效用，尽管它一直都在那里。
非常感谢您如此详细的解释。
我个人认为，这会很……累人。
“别让我费脑子”
我怀疑你觉得设计和讨论设置很累人，而不是简单地使用它。一旦有了设置和普遍共识，使用工具可以使参与更容易，并且减少思考（考虑几个简单的反应比为表达基本相同的反应而进行的思考要快而简单）。
就在这里，我希望我能 你的回复，因为我欣赏听到你的意见，但我不希望被误解为我同意你的意见。嗯，我还是标记了 ，我认为在这个特定的语境下没有误解。
但我想我还是有些同意你的看法。我自己在这里的过度思考是累人的。但如果我能只标记几个合适的反应而不必用这个单独的文本回复来过度解释，那就不会是这样了 ……我刚刚想象你和其他人在这篇帖子上标记“哈哈” 
反应，以一种和我一起笑的方式承认这有点荒谬（元和过度思考的程度）……所以，是的，我证明了你的观点。或者也许是我比反应更累人……哈哈
使用文本简洁回复也是支持的。你甚至可以用大表情装饰。
从根本上说，反应的底层设计与“每帖多个表情”相悖。当时有条岔路……Slack 风格或 Facebook 风格，我们选择了 Facebook 风格。
我们需要一种完全不同的控件来处理多个反应，这将是一个重大的工程变更。
你说得非常好。如果我参与了讨论，我会强烈主张“Slack 风格”。认识到 Discourse Reactions 是“Facebook 风格”，这种简单的 Facebook 与 Slack 风格的反应是最简洁、最清晰的方式来表达为什么停止将 Retort 描述为仅仅被取代是好的。Retort 的维护或替换确实会引发关于有限的志愿者（甚至付费）开发人员时间和优先事项的所有困境，但我认为让每个人都清楚情况是一个开始。
仅供参考，现在太晚了，Retort 的存在“Slack 风格”可以被提出来作为使 Discourse Reactions 采用这种风格的原因，因为它将为所有已经使用 Retort 的人提供平稳的过渡。目前，我们可以将此主题视为对“Slack 风格”插件的请求，即 Retort 的实际后继者。
单独的插件是选择和熟练的编码人员的问题，总有新的选择空间，但我很好奇。您认为，总的来说：更多的论坛用户会来自Facebook还是Slack背景？
这是一个合理的问题，但更重要的是 Slack 的方法更胜一筹。设计应考虑熟悉度，但也应考虑不考虑熟悉度的情况下什么才是更好的设计。
又回到了老生常谈的 beta 与 vhs 之争 或者说 markdown 是否比所见即所得的 html 前端更胜一筹。又或者是史上最强大的国王和王后：苹果与 PC。我的意思是，这只是基于某人自身偏好而做出的又一个概括。也称为品味问题
最重要、最有力的一点是，用户必须知道如何使用该环境，并且感觉熟悉。事实上，这正是你和其他一些人想获得 Slack 风格的真实原因。这本身并没有什么错。
但现实是，Slack 用户只是少数。因此，默认情况下，如果一个系统无法扩展，提供的解决方案必须遵循大多数人的需求和习惯。
但这现在是一个纯粹的元话题，因为我们又回到了这个问题：是否有人会为此编写插件。在那之后，整个根本问题“反应是否被广泛使用和需要，还是仅仅是管理员想要的另一个小玩意”或多或少是学术性的——因为这是选择的问题。
我想说，我非常希望看到此线程中请求的功能，因为我们目前在论坛上使用 Retort。这两个功能：自定义表情符号和每帖多个反应的使用频率相当高。也许每帖多个表情符号反应的使用频率较低，但经常会用到点赞帖子和对帖子做出反应的组合（据我目前所知，反应插件也不支持这种情况）。我们的社区还广泛使用 Discord，因此让论坛上的反应功能与 Discord 类似将是一种很好的用户体验一致性。
自定义表情符号已受支持。
reactions 插件在您使用已配置为映射到点赞的反应时，已经创建了一个底层的点赞。