大家认为每个信任级别允许的合理投票数是多少？我看到在 Meta 上，我们将 TL0 的投票数从 2 降至零，TL4 的投票数从 10 降至 8。我注意到我自己也用完了投票数，尽管我在这里是管理员！
2 个赞
我一直认为这个数量是故意限制的，这样它就可以作为一种“这对我来说真的很重要”的指标。即使我用完了投票权，我仍然可以喜欢所有请求并将我的用例添加到功能请求中。而且，一旦我投票的另一个功能请求完成并且该主题关闭，我仍然可以对这些主题进行投票。
1 个赞
@tobiaseigen，我不会限制他们……我发现自己从不使用投票，因为对我来说，我只是支持或反对某件事；当点赞存在时，试图确定某件事是否对我来说真的重要并不是一个特别实用的利用我时间的方式。
2 个赞
我将最近的讨论移至 Jammydodger 的原始帖子，因为我觉得在这里继续讨论投票是合适的。
我喜欢限制的想法，但我也认为有太多未解决的功能请求，所以设置一个非常低的限制似乎不公平。我自己也觉得受到限制！投票也是一种信号，如果我们不让人们投票，我们就剥夺了产品团队的信号。
我倾向于在以下方面提高限制。大家觉得怎么样？
| 信任等级 | 当前投票数 | 建议投票数 |
|---|---|---|
| TL0 | 0 | 0 |
| TL1 | 4 | 10 |
| TL2 | 6 | 20 |
| TL3 | 8 | 24 |
2 个赞
Imo 24 turns this into practically unlimited
I like the current limits, makes you think
2 个赞
我确实想知道，宝贵的投票是否受到严格限制，这是否会导致信息有限。考虑到这里用户数量众多，投票数通常似乎偏低。许多功能建议的点赞数比投票数还多，但我猜只有投票才会被注意到。
总是没有投票，并且总是不得不进行分类和牺牲才能对任何新事物进行投票，这是一个巨大的障碍。我查看我现有的投票以了解如何释放投票……但没有一个请求是不值得的。它们只是从信息流中滚动而过，被遗忘了。
我应该放弃它们吗？
我应该在我的收藏夹中添加评论吗？投票了一个功能后，评论“是的，好主意！”感觉像是多余的混乱。
好主意只有一两个投票。人们没有发现它们，不感兴趣，还是……他们只是没有投票了？
增加限制不需要大量的编码，而且感觉会有帮助——但我也想到拓宽道路以减少交通流量只会吸引更多交通，然后你又回到了原点。
只是随便说说……一些大量的编码功能性更改作为硬性限制的替代方案：
- 根据 TL 分配每月的投票数。（在“投票日”，人们会访问 Feature 并评估开放项目……）
……或者，正如 heliosurge 提到的，最终释放投票：
- 在设定的时间后释放已使用的投票，或者
- 工作人员定期审查过时的功能请求，然后 a) 提升主题以获得另一个机会，或者 b) 评论“无计划解决”并释放投票。
……无论哪种情况，已投的票都将保留，并且用户不能通过进一步取消对这些主题的投票来超过他们的投票分配。
（我说的轻松。这可能需要大量的编码 
）
2 个赞
@sam，对我来说不是这样，因为我只使用点赞。它目前的实现感觉有点多余——就像 GitHub Discussions 同时存在点赞和竖起大拇指一样。
2 个赞
同意重复点赞会造成混淆
“我喜欢你写功能请求的方式，对我来说听起来不错”
和
“我认为 Discourse 应该构建这个功能，这绝对是我心中的前八名”
当启用主题投票时，禁用发帖人点赞可能是一个有趣的实验。
1 个赞
有一些关于关闭一些请求的说法，例如“抱歉我们不这样做”。
关闭已完成 2 年的功能，并将不再有任何意义的功能请求标记为过时，这确实非常有说服力。
2 个赞
我认为最终不会有太大变化。我的大部分投票都是在一年前添加的。是的，我本来可以投票给更多的话题，但一旦我用完了所有的投票，结果还是一样：我必须等一个投票完成并关闭，或者我需要从另一个话题中移除我的投票。我相当确定，在 Meta 上也有超过 20 个好的功能请求 
正如我之前所说，对我来说，投票比“喜欢”更强大。但我仍然认为对第一个帖子的“喜欢”对于吸引兴趣也非常有帮助。在启用投票功能十多年来，它们一直是指标。因此，忽略它们，尤其是在长期存在的请求上，就意味着忽略了用户过去能够表达支持的唯一方式。
另外，也许没有人认为这个功能请求是他们非常需要以至于要花一票去投票，但很多用户喜欢它，因为他们认为它会有帮助。一票（通常由请求的作者投出）是否比多个“喜欢”更能说明这个功能对一系列不同的 Discourse 网站有多大帮助？
我想知道，与其增加“我真的很感兴趣”的投票数量，不如限制他们可以分配话题的数量。
所以，与其今年有 378 个主题可以投票（
），不如考虑预先选择它们。
例如，只有那些获得一定数量反应表明多个用户感兴趣的请求才能投票，或者你可以按时间限制，说投票仅限于某个时间段的主题，以便在该功能组中找到最受欢迎的。
你也可以说，“我们正在审查队列。您会想到哪些请求？”然后将它们移到一个子类别中进行投票。
能够将 4 票投给约 100 个话题，其比例将比能够将 10 票投给所有开放的功能话题要高。
3 个赞
@sam，我希望的是相反的情况。投票在技术上是否提供了点赞所没有的东西？我怀疑没有人会点赞一个他们不支持的“功能请求”。
如果禁用点赞，启用投票，我认为那才会“减少信息量”。作为比较，Forgejo 和 GitLab 不限制点赞可能表明，将点赞作为简单的支持或不支持指标是有价值的。
出于好奇，我今天在 Feature 标签下浏览了一下，比较这些过滤视图很有趣：
我想知道使用包含“投票数”和“点赞数”的数据探索器查询可以实现什么…… 
另外：
[quote=“Moin, post:30, topic:308402”]与其让用户对今年的 378 个主题进行投票，不如预先选择它们可能更有意义
[/quote]
自动化思考： 也许可以根据点赞数建立一个“主要”池，将请求升级到可投票状态。
人工策划思考： 偶尔，一些明显有价值的请求会得到工作人员的关注，无论投票数如何，所以某种程度上，已经有一些策划工作在进行了。但也许所有内容都应该经过工作人员的快速审查？
支持性示例：我发现了 8 个关于“让用户关闭自己的主题”的功能请求——从 2014 年到 2025 年——其中一些已关闭，但大多数仍处于开放状态且没有投票。如果同一个请求被反复提出，而较早的请求却无人问津且未被投票，那说明有些地方没能很好地运作。
如果用户没有搜索——或者没有看到“您的主题相似……”的对话框——我不确定还能做些什么，除非初始请求能到达工作人员的检查点：
如果是新请求，则将主题移至投票类别；
如果存在相似请求，则回复一个链接。
只是在自言自语。我知道一切都需要资源……
如果团队在拟定投票主题列表后公布投票结果，那么限制是可以接受的。也许可以每季度公布一次投票结果。这次更新甚至可以详细说明团队选择添加到路线图中的功能，并提供一个按优先级的潜在时间表。
否则，24 次确实不是无限的，因为有些投票被占用了超过一年甚至更久。试图去删除那些可能根本没有被考虑的、看似沉寂的功能的投票也是一件麻烦事。
也许一个想法是时不时地创建一个团队正在认真考虑的功能列表，并创建一个民意调查供人们投票，然后根据投票结果进行更新。如果存在发布周期，主题投票也未尝不可。周期应该是多少，这是团队需要讨论和决定的事情。
不明白，你们不能公布那些对你们来说已不再重要的事项的投票结果吗？
这只是假设先前投票通过的事情已经实施或不再重要。
在我看来，将功能请求整理成一个列表，列出团队考虑在未来添加的功能，并释放这些选票供再次使用，是合理的。
为什么要使用主题投票？正如您所提到的，可以使用“赞”/反应而不是限制在一定数量的选票。使用特定的反应，比如 :discourse:，可能足以衡量特定 #功能请求 的兴趣，因为您可以使用数据浏览器脚本在这个类别中返回带有最多此特定反应的帖子中的热门主题。
与限制投票相比，这真的感觉没有进展，因为根据我的经验，没有与此类别直接相关的更新。可能偶尔会有，但我可能没有注意到。
我敢肯定，一些新推出的功能以前也曾是功能请求。
依我看，主题投票可能更适合用于竞赛，对“X个热门主题”进行投票，并设定一个截止日期来宣布前三名获胜者。但在该类别中使用它，感觉更像是一场没有明确结论的竞赛，需要对自己的选票进行猜测。
1 个赞
我在这里对这个过程发表了很多评论，但老实说，有很多功能请求被标记为 completed – 针对类别:feature 标签:completed 的过滤结果
2 个赞
完成的标签确实有帮助。但我发现，如果团队想衡量对功能请求的更多兴趣，限制投票数量可能会适得其反。
正如 Sam 提到的，有各种信号，比如“赞/反应”（选择一个特定的反应），甚至没有投票限制。因为并非所有“想法”都会有人投票/点赞，因为他们可能对某个特定的想法不感兴趣。例如，我记得有一个关于选举论坛团队的请求。
虽然在某些论坛中这可能是一个想法/选项，但许多人可能不希望通过潜在的“人气竞赛”来决定谁来管理论坛。
因此，您仍然会根据投票/点赞的数量来衡量社区的整体兴趣水平，而不是限制在一个固定的数字，后者更有可能分散兴趣并导致更多的“平局”，可以说。
1 个赞
查看标签确实有助于了解添加了多少内容。但这感觉对投票兴趣的限制太大了。即使一些已完成的功能投票很少或没有投票。当然，简单易行的胜利是件好事。
我在这里的愿景是让每个人都有自己个性化的、按优先级排序的功能视图，然后我们可以通过不同的“视角”将这些视图汇总成不同的集体视图。
因此，我不需要在所有事情上进行二元投票/不投票，而是可以整理出我的“前十名”列表，并按偏好顺序显示它们。你也可以做同样的事情。然后我可以做一些事情，比如“向我展示过去一年加入 Meta 的人的前十名列表”或“向我展示使用我们入门计划的人的前十名列表”，等等。
与此同时，我还有一些其他想法，可以使这里的事情更容易管理，这些想法与我们如何更普遍地管理开放路线图和待办事项列表的想法相关联。这些想法涉及我们如何管理 Bug、功能和用户体验 (UX) 类别的变化，以及我们如何将更开放的构思与我们计划处理或乐于看到贡献的具体提案和/或规范区分开来。
我希望在今年年底之前整理出一份类似 RFC 的文件供大家讨论。
4 个赞