继续讨论 Discourse 帖子投票：
由于问答帖子的首个帖子就是问题本身，因此不应有“点赞”选项。
2 个赞
这难道不是一个对主题进行优先排序的功能吗？
我同意，目前还不清楚为什么有人应该对某个主题进行投票。
2 个赞
我已将您的帖子移至此处 @volanar，因为它之前已被提及。 
我以为有回复说这是故意的，但我好像找不到。我会深入挖掘一下，看看能找到什么。 
5 个赞
这在很大程度上是网站偏好。对问题质量进行投票是像 Stack Overflow 这样的网站上相当成熟的功能。
我们特意保留了投票控件，通过 CSS 删除它也可以，也可以考虑添加一个网站设置。
5 个赞
但是问题本身不能参与答案的投票。而且，它也不能和答案一起被过滤。它应该总是在最上面
1 个赞
我想知道是否将 OP 中的样式与回复中的样式不同地设置样式会有助于表明它具有不同的含义？
1 个赞
我认为在 Discourse 的语境下，对问题进行投票是非常值得讨论的。我对类似 Stack Overflow 的网站有些经验 ;)，我想稍微思考一下，在 post-voting 这类话题中，投票对问题（为简洁起见，下文统称为“问题”）是否真的有用。
您说得对，在纯粹问答（Q&A）平台（如 Stack Overflow）上，问题投票（赞成和反对）有特定的用途。具体包括：
- 表明问题质量，或表示您也有同样的问题/理解提出此类问题的必要性
- 按分数搜索/排序/筛选问题
- 表明问题是否属于该站点的范围
- 隐藏质量特别低的内容
- 允许非版主用户删除内容
- 通过声望/积分奖励或惩罚发布好/坏问题的用户。
据我所知，这些功能目前并不适用于 Discourse，无论是否使用此插件。我知道该功能相对较新，但我很好奇，在这些 Q&A 功能中，有多少是您在 Discourse 中希望使用的。表面上看，这似乎是对当前信任等级系统和其他管理实践的巨大范式转变。
如果 您添加这些问答类型的主要目的是为了让社区能够轻松创建/托管自己的类似 Stack Exchange 风格的站点，其主要目的是更结构化的问答而非讨论，那确实很有趣，我很想听听更多关于这方面的内容……但我在 Stack Overflow 的这段时间学到了很多，这让我开始质疑其核心功能，以至于如果我要从头构建它，我会直接劝阻复制 Stack Overflow 的许多方面。
在思考像运行了帖子投票插件的 Discourse 社区这样的混合系统时，我老实说不知道对问题进行投票是否有任何意义。我承认我对该功能及其实现方式了解不多，但我稍微摸索了一下，并阅读了这里能找到的相关帖子以了解它，这得出了我的结论。
问题投票在 Discourse 中有什么价值？
我了解到该插件作为官方功能还不到一年，可能仍处于变动中。我绝不妄称是 Discourse 管理、功能或范围的专家（欢迎纠正我的任何错误），但似乎现状使用了不同（且可能更好）的解决方案，这使得许多问题分数的理由变得不必要。
TL;DR - 阅读粗体部分。
| # | 功能 | 在 SO 上的用途 | 在 Discourse 上的用途 | 有用吗？ |
|---|---|---|---|---|
| 1 | 投票通知 | 赞成票会通知发帖人声望变化。SO 上没有“点赞”功能。 | 投票不会为提问者创建通知，但点赞会。 | 虽然很可能很容易在 Discourse 中添加赞成票通知，但为什么要两者兼有？点赞是问题投票在此显得不必要的核心原因之一。 [1] |
| 2 | 投票对提问者的影响（声望） | 声望是 SO 授予权限的方式，用户的声望是其地位的主要方面。从广受好评的问题中获得声望是仅提问的用户获取权限的少数途径之一。 | 没有类似声望的机制。权限通过信任等级系统授予，该系统强调并奖励阅读内容（TL 1）。Q&A 风格帖子的投票似乎算作点赞，而点赞在问题和答案中均不存在。 | 帖子创建、声望和权限之间的直接联系是我最希望改变的 SO 方面。用户应该有多种无需创建内容即可获取权限的途径。如果用户不需要问题投票来获取信任等级，那么它们似乎是不必要的。 |
| 3 | 投票对提问者的影响（非声望） | SO 非公开的自动累犯系统（版主无法覆盖）的一个方面部分依赖于问题分数，以阻止持续发布低质量问题的用户未来提问。SO 没有要求在内容上线前预览的方式。 | 版主使用工具手动屏蔽、暂停或覆盖用户的信任等级，而不是依赖任何自动化。虽然有设置可以在某些情况下要求版主审查新帖子，但这并非基于帖子的反响。 | 考虑到 SO 的规模和允许任何人提问的优先级，对用户实施自动问题封禁是可以理解的（尽管该系统需要 overhaul [2])。依赖现有的基于信任等级的帖子限制和使用举报功能，使得问题分数对用户管理变得不必要。 |
| 4 | 分数对帖子的影响 | 低分问题会被隐藏在前页之外，且更容易被受信任用户或自动化删除。某些类型的举报如果数量足够多，也可以删除问题。所有同类举报的权重相等，无论谁发起的。 | 有一个完善的现有系统，可以根据举报自动关闭、隐藏和删除帖子，这也将版主注意力引向被举报的帖子。来自举报历史良好的用户的举报权重高于来自举报历史不佳的用户。 | 现有系统似乎非常平衡。通过使用过去的举报来加权新的举报，用户被激励在举报时保持准确。相比之下，使用未加权的投票来隐藏/删除内容可能被滥用，且未考虑过去的投票记录。结合现有的举报系统，依赖投票来管理帖子是不必要的。 |
| 5 | 问题排序/筛选 | 问题分数、回答数量、采纳状态在所有问题列表视图中都清晰显示。搜索可以使用问题分数根据用户请求过滤和排序结果。所有话题都是 Q&A，因此不需要语法来仅查找 Q&A。搜索包含仅返回问题的语法。 | 问题分数未显示在话题列表中，但已解决状态和回复数量会显示。结果可以按点赞（包括投票）排序。没有方法仅返回 Q&A 话题。in:first 语法似乎可以仅返回问题。 |
为帖子类型（Q&A 与讨论，问题与答案/回复）添加搜索语法似乎很有价值，尽管有些边缘化。(这个要求在话题列表中显示 OP 投票的功能请求帖子) 可能有用，但点赞可以替代话题列表中的问题分数，或者您可以拒绝该功能请求并保持 UI 原样。 |
| 6 | 赞成票含义 | 问题赞成票的悬停文本显示“此问题显示了研究努力；它有用且清晰”。前半部分存在争议，后半部分主观且模糊。用户可能出于多种原因对问题投票，包括“我也有同样的问题！”，这可以说属于“有用”范畴，但主题专家可能会认为简单但常见的问题对他们来说没用而投反对票。[3][4] | 未定义。没有关于何时投票的 UI 指引，这是可以理解的，因为这是一个新功能，每个社区可能希望鼓励投票的原因各不相同。熟悉的“点赞”功能在此话题格式中缺失。虽然点赞可能默认为爱心，但社区可以配置额外的反应。 | 即使在那些就何时投票达成共识的社区中，问题投票的理由通常也比答案投票的理由更主观、更宽泛，后者几乎总是意味着“这是正确的”或“我同意”。点赞，特别是当社区添加各种反应选项时，比单纯的赞成/反对投票更能解释为什么有人对问题投票。 |
| 7 | 反对票含义 | 问 10 个人何时应该在 SO 上对问题投反对票，你可能会得到 10 个不同的答案，其中一半是“错误”的，许多应该通过编辑、举报、关闭或评论来解决。这些功能的不足使用导致提问者在 Meta 上发帖，表达对问题被无故反对投票的困惑和沮丧，并要求禁止此类投票。[5] | 同样可以理解为未定义。大多数问题可以通过使用评论指出可操作的更改或建议、使用问题上的举报选项向提问者发送私信，或向版主举报来更有效地解决。默认的爱心与反对票的负面含义不符。 | 人们讨厌被投反对票，即使平台极力避免让用户知道他们被投了反对票。这对提问者来说往往更痛苦，他们正在寻求帮助，并因分享自己陷入困境和对被他们视为不帮忙或阻碍的人感到沮丧而感到脆弱。问题反对票可能是简单的回应，但无助于提问者改进。通过依赖其他工具，您可以鼓励沟通而不是疏远。 |
将图书馆功能适应您社区的家园
我理解遵循现有平台（特别是您参与构建的平台）所建立模式的冲动——但我从 SE/SO 社区得出的最大教训是，大多数（新）用户认为 SE 更像论坛，并且经常难以接受他们第一个问题的反响，特别是在关闭和投票方面。在 SO 上提问对许多人来说压力很大……互联网上充满了关于 SO 的引用，告诉他们的问题要么会被完全忽视，要么会被自封的平台和主题专家严厉评判，这些专家对什么构成编程问题有着神秘且反复无常的期望……许多人并不想要这样。
他们经常表示想要的是更小、更紧密的社区，在那里他们认识人，可以建立联系并寻求帮助，而不会觉得自己像个傻瓜。在很多方面，我认为 Discourse 就是这样的。通过拥有更广泛的格式，既鼓励开放式和主观性话题，又支持更经典的 Q&A 格式，您可以让社区以他们希望的方式互相支持。
即使 SO 是创建和策划知识库的最佳方式（其实不是），Discourse 也不应（且不应）试图成为那种资源。您的主页将 Discourse 宣传为“您社区的在线家园”。当我希望我的孩子感到宾至如归时，我会鼓励并培养他们的问题，为他们腾出空间加入对话。当我带他们去图书馆时，我经常不得不提醒他们保持安静，并防止他们把书架当成丛林健身房。
在我看来，问题投票对于图书馆可能是必要的，但对于家园可能不是——它可能会负面影响人们享受家园的程度。
客座产品经理时间
这部分比上面的巨型表格重要得多，所以如果您还没读，请先去读那个。表格解释了我是如何得出这个总结的，也会揭示我因信息错误而产生的任何问题——再次提醒，我不是 Discourse 专家——我一直在检查确保我没有写成“Discord”。
- 移除问题投票 - 如果人们真的想要更像 SO 的纯 Q&A，可以将其设为一个设置，但我默认会将其关闭。
- 恢复问题的点赞 - 给人们一种友好地回应/支持问题的方式。考虑提供一些适合问题的默认反应，包括正面和负面。
- 我理解希望同一话题上要么全是点赞要么全是投票的一致性，但我认为混合使用是值得的，而且 Discourse 用户已经习惯了点赞……事实上……
- 调查在答案上使用点赞的价值，作为投票和评论的补充。反应可能比投票更友好，有些人可能想表达比二元赞成/反对更多的内容，而无需写评论。如果投票和点赞已经用于排序搜索结果，也许有一种方法可以在确定答案顺序时同时使用两者——类似于审查队列中的举报分数。
- 保留答案投票 - 答案投票的主要目的是对单个问题的解决方案进行排名，赞成和反对投票都至关重要，即使它们可能会引起一些压力。
我理解希望避免在同一话题上混合点赞和投票。 ↩︎
据 anecdotal，一些用户可能会过度对问题进行反对投票，目的是让提问者更快被封禁问题，这也使得解封变得更难。在这样的系统中，必须考虑意外后果并找到最小化它们的方法。 ↩︎
我可以就 SO 上的问题投票发表一场 TED 演讲，但我要说的是，许多 SO 用户似乎忘记了“信息库”的概念，而“显示研究努力”的悬停文本加剧了这一点。一个伟大的图书馆包含所有信息。仅仅因为某样东西在隔壁城镇的图书馆里就拒绝将其加入您的图书馆是很愚蠢的。 ↩︎
另外，别跟我提“元站点的投票不同”——不过，既然我的解决方案是合并 Discourse 和 Q&A，也许这至少是题内话。 ↩︎
无论人们在 SO 上说什么，反对票感觉是个人化的，即使它们本意并非如此。 ↩︎
2 个赞
我喜欢这个比喻。我应该指出，我的家有时被当作图书馆（孩子们做家庭作业时），而图书馆有时更像游乐区（当他们举办社区活动时）。但默认设置很重要。无论好坏，Discourse 的默认设置是一个更轻松的讨论论坛。它是协作而非对抗。对于大多数 Discourse 社区来说，问答将是例外。
我喜忧参半。我确实认为踩是一种比其他方式更温和的表达异议的方式。在收到许多关于踩的抱怨后，人们最关心的是匿名的踩在连接的声誉系统中感觉不公平。人们想知道他们为什么被踩。表面上，他们想知道是为了解决问题。实际上，我怀疑大多数人想和踩的人争论，但他们没有什么可以依据的。这通常是件好事，因为这些争论很少有成效。
在 Discourse 中，踩，尤其是在问题上，与大多数论坛的协作性质不太匹配。我不确定如果不是以 Stack Overflow 为例开发，人们是否会想要问题投票。在一个理想的世界里，投票应该反映问题的质量：
- 它是否清楚地解释了问题？
- 它是否提供了足够多的上下文供他人探索问题？
- 它是否直奔主题，避免了不必要的背景信息？
- 它是否属于社区的专业领域？
严酷的现实是，问题投票往往反映了社区对问题的感受。如果你在 Stack Overflow 上询问 NullPointerException 错误，无论你问得多么好，你都会处境艰难。这个问题已经被问过一百万次了，人们没有兴趣回答另一个版本的问题。
也许这是问题投票的一个特性而不是一个 bug。如果是这样，那么当有太多问题导致社区无法跟上时，这是一个有意义的特性。它不是一个对新形成的社区或通常是协作论坛但偶尔会涉及问答的社区有帮助的特性。换句话说，我不确定问题投票对数量非常庞大的 Discourse 社区是否有帮助。所以我认为它应该是一个默认设置为“禁用”的选项。
我最近向一个正在为视频 AMA 收集问题的客户推荐了帖子投票。旧系统是根据点赞数选取排名前 X 的问题。提问者没有简单的方法来对回复提问请求的内容进行排序。帖子投票对此非常有效，因为回复是自动排序的。然而，包含的问题投票是毫无意义且令人困惑的。许多人访问社区是为了提交他们的 AMA 问题。点赞会是一个有用的信号。踩？可能是误触或对新功能的实验。我今天下午将通过 CSS 移除它。[1]
我还需要做一些其他的调整，以便它能与他们的主题配合，所以现在是修复这个烦恼的好时机。 ↩︎
1 个赞
如果我想对问题本身进行投票，使用“主题投票插件”是否合适？还是我理解错了？