我们已在 Contribute > Feature 类别中启用了 主题投票！
现在，您可以对任何您特别关注的功能进行投票：
（截图可能不太直观，等我们有一些已投票的主题后，我会回来替换它 ）
投票规则投票次数有限，因此您需要慎重选择。您可以在下表中查看每个信任等级的投票配额：
| 信任等级 | 投票数 |
|---|---|
| TL0 | 0 |
| TL1 | 4 |
| TL2 | 6 |
| TL3 和 TL4 | 8 |
这是总投票数，但如果您改变主意，可以取消投票并重新投票——如果某个主题被关闭，您的投票将被返还，并可用于其他开放的 Contribute > Feature 请求。
点赞/反应通常情况下，在投票主题中不会显示点赞和反应，也无法给予点赞和反应。但由于我们有着很长的历史，直接清空并重新开始似乎有些可惜，因此我们保留了这些功能。 
如果您有任何问题或建议，请告诉我
祝您在 Contribute > Feature 投票中玩得开心！
太棒了！将此插件用于功能类别很有意义 
我要去进行一些投票。
这应该会有所帮助，因为功能请求似乎经常石沉大海。
您可以在分类中找到获得最多点赞的主题，但有了投票插件，会更容易查看。
恐怕如果你希望的是这样，我们还是无法实现所有 #contribute:功能请求。
这完全可以理解。但这将使团队更容易识别哪些请求获得了更多的社区支持，将其视为一种“想要”/潜在的“需求”。
当然，还有其他因素会影响功能请求是否/何时会被处理/实现。
我不这么认为。
我之前一直在思考如何处理一些 Contribute > Feature 主题，这些主题不一定符合“请求”的格式。目前还不确定。也许可以基于标签使用 display: none;。
我认为允许投票对实验性功能并非坏事，但有点棘手，因为功能在不断发展，没有一个可以参考投票数的快照。
这可能会让那些最终会变得很棒但一开始有些妥协并以某种方式解决了他们的问题的功能显得不那么有利。
我认为投票给正在积极开发的东西很可能是浪费选票，因为在这个阶段，具体的反馈/回复比投票数更受欢迎/更有影响力。
不过现在还为时过早，所以我还没有完全形成自己的观点。
是的，我明白你的意思。对于这些实验性功能，也许最好使用标准投票而不是主题投票来探索这些功能的某些部分，一旦某个功能获得了足够的反馈点。
我想，如果这个方案行得通，我们或许可以单独设立一个类别，用于像实验性侧边栏这样的情况——我们在此分享更新和/或就正在积极开发的内容征求反馈。这样一来，Contribute > Feature 就可以更明确地用于功能建议（在这种情况下，我挺喜欢将其重命名为 #ideas 之类的想法）。
不过，我们现在才刚刚开始尝试，所以很高兴能一步步来。
我们有一个单独的类别，用于我们 PM 正在积极构建的工作，其中 PM 描述他们正在解决的问题等，通常以“听起来耳熟吗？我们想听听您的意见，这是我们的 Calendly，如果您想讨论的话。”结尾。
我们称之为“In Discovery”会议，该类别为“In Discovery”。我们还将在不久的将来设计一个想法门户解决方案，以便我们最终可以摆脱 AHA Ideas。
我很想就使用 Discourse 作为产品组织的创意门户进行交流笔记/想法——我敢打赌我们的需求将近乎相同！
有没有办法按投票数对 Contribute > Feature 进行排序？
答案：有！
在顶部点击“投票数”筛选器：
https://meta.discourse.org/c/feature/2/l/latest?order=votes
顺便说一句，这完全是 
我一直在为功能投票，但不知道我的投票数量是有限的。我明白这是有必要的，但不是很清楚。是否可以在“投票”按钮下方添加（剩余投票数）？
是的，恕我直言，投票限制太低了，而且投票在一段时间后也不会被释放。至少据我观察是这样。
如果团队能统计这些 X 个月前的议题，并且团队可能正在考虑这些议题，那就太好了。发布一个带有候选人投票的议题。
我记得当你剩下不多的选票时，会有一条消息告诉你还剩下多少。
对我来说不是，除非你的意思是投票按钮下方的一词通知。
