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