信頼レベルごとに許可される合理的な投票数について、皆さんはどう思いますか？メタでは、TL0を2票から0票に、TL4を10票から8票に変更したことがわかります。私自身も、ここに管理者がいるにもかかわらず、投票数がなくなっていることに気づきました！
「いいね！」 2
私は、この数が意図的に制限されているのは、「これは本当に私にとって重要だ」という指標として機能するためだとずっと思っていました。投票権がなくなっても、すべてのリクエストに「いいね！」を付けたり、機能リクエストにユースケースを追加したりすることはできます。また、私が投票した別の機能リクエストが完了してトピックが閉じられれば、これらのトピックに投票することもできます。
「いいね！」 1
@tobiaseigen、私はそれらを制限しません… 私は投票をまったく使用しないことに気づきました。なぜなら、私にとって、単に何かを支持するか反対するかのどちらかだからです。いいねが存在するのに、何かが私にとって本当に重要かどうかを判断することは、特に実用的な時間の使い方ではありません。
「いいね！」 2
この最近のディスカッションを Jammydodger の元の投稿に移動しました。投票についてここで話し続けるのが適切だと感じたからです。
制限のアイデアは好きですが、非常に多くの未解決の機能リクエストがあるため、非常に低い制限を設定するのは不公平だと感じます。私自身もこれで制約を感じています！投票はシグナルでもあり、人々が投票できないようにすることで、製品チームからそのシグナルを奪うことになります。
以下のような方向で制限を引き上げることを検討しています。皆さんはどう思いますか？
| 信頼レベル | 現在の投票数 | 提案された投票数 |
|---|---|---|
| TL0 | 0 | 0 |
| TL1 | 4 | 10 |
| TL2 | 6 | 20 |
| TL3 | 8 | 24 |
「いいね！」 2
Imo 24はこれを事実上無制限にします。
現在の制限は気に入っています。考えさせられます。
「いいね！」 2
貴重な投票の厳格な配分が、限られた情報につながるのではないかと疑問に思っています。ここのユーザー数に対して、投票数は一般的に少ないように思えます。多くの機能提案は、投票よりも「いいね！」の方が多いですが、注目されるのは投票だけだと想像しています。
常に投票がなく、新しいものに投票するためにトリアージと犠牲を払わなければならないのは、大きな障壁です。私は既存の投票を確認して、どのように投票を解放できるかを見ていますが、リクエストのどれも「価値がない」わけではありません。単にフィードからスクロールして忘れられただけです。
それらを諦めるべきでしょうか？
お気に入りにコメントして「いいね！」を増やすべきでしょうか？機能に投票した後、「はい、良いアイデアです！」とコメントするのは、無駄なノイズのように感じます。
良いアイデアが1つか2つの投票で放置されています。人々はそれらを発見していないのでしょうか、興味がないのでしょうか、それとも…単に投票がないのでしょうか？ 
制限を増やすには多くのコーディングは必要なく、役立つように思えますが、道路を広げて交通量を減らすと、さらに交通量が増え、元に戻ってしまうという考えも浮かびます。
ただの思いつきですが…ハードリミットの代替として、多くのコーディングが必要な機能変更をいくつか提案します。
- TLに基づいて毎月一定数の投票を割り当てる。（「投票の日」には、人々が#featureを訪れて未解決の項目を評価するため、活動が活発になります…）
…または、heliosurgeが言及したように、最終的に投票を解放する。
- 一定時間経過後に使用済みの投票を解放する、または
- スタッフが定期的に古い機能リクエストをレビューし、a) もう一度チャンスを与えるためにトピックを更新するか、または b) 「対処する計画はない」とコメントして投票を解放する。
…いずれの場合も、投票はそのまま残り、ユーザーはこれらのトピックの投票を解除することで投票割り当てを超えることはできません。
（私には簡単に言えますが、おそらくかなりのコーディングが必要でしょう 
）
「いいね！」 2
@sam、私にはそうではありません。なぜなら、私は単に「いいね」を使用するだけだからです。現在の実装は、GitHub Discussions の「アップボート」と「サムズアップ」が両方存在するのと同様に、少し冗長に感じられます。
「いいね！」 2
重複したシグナルがあるのは紛らわしいという意見に同意します。
「機能リクエストの書き方が気に入りました。私には良いと思います」
対して
「これは間違いなく私のトップ8に入ります。ディスコースが構築すべきだと思います」
トピック投票が有効な場合にopの「いいね」を無効にするのは興味深い実験かもしれません。
「いいね！」 1
「申し訳ありませんが、これは行いません」とコメントして一部のリクエストを閉じることについて
2年間完了した機能や、もはや意味をなさない機能リクエストを古いものとして閉じることには、確かに非常に説得力のあるものがあります。
「いいね！」 2
最終的にはそれほど変わらないと思います。私の投票のほとんどは1年前に追加されました。はい、もっと多くのトピックに投票できたでしょうが、一度すべての投票を使い切ると、また同じになります。1つが完了して閉じられるのを待つか、別のトピックから投票を削除する必要があります。Metaには20件以上の優れた機能リクエストがあることも確かです 
前述したように、私にとって投票は「いいね」よりも強力なものです。しかし、興味を捉えるためには、最初の投稿への「いいね」も非常に役立つと今でも思っています。投票が有効になる前の10年以上、それらは指標でした。したがって、それらを無視すること、特に長期間のリクエストで無視することは、当時ユーザーがサポートを示す唯一の方法を無視することを意味します。
また、誰も機能リクエストをそれほど必要としているとは思わず、投票を費やすことはないかもしれませんが、多くのユーザーはそれが役立つと考えて「いいね」をしています。1つの投票（通常はリクエストの作成者による）は、複数の「いいね」よりも、さまざまなDiscourseサイトにとってその機能がどれほど役立つかについて、より多くを語るでしょうか？
「本当にこれに興味がある」という投票数を増やす代わりに、それらを分散できるトピックの数を制限する方が良いのではないでしょうか。
したがって、今年の約100件のトピックに378件の[
]トピックに投票する代わりに、それらを事前選択することが理にかなっているかもしれません。
たとえば、複数のユーザーからの関心を示す特定の量のリアクションがあるリクエストのみが投票可能であるか、または時間で制限して、特定の期間のトピックに投票を制限して、それらの機能グループ内でお気に入りを検索できるようにすることができます。
「レビューキューを改訂しています。どのようなリクエストが思い浮かびますか？」と言うこともできます。その後、それらはサブカテゴリに移動され、投票されます。
約100件のトピックに4票を投じることができるのは、すべてのオープンな機能トピックに10票を投じることができるよりも比例して多くなります。
「いいね！」 3
@sam、私は逆を期待していました。投票は、いいねにはない何かを技術的に提供しますか？サポートしないFRを誰もいいねしないと思います。
いいねが無効になった場合、それは「インテリジェンスを低下させる」ことになると思います。比較として、ForgejoとGitLabがアップボートを制限していないことは、単純なサポート対非サポートのインジケーターとしてそれらを持つことに価値があることを示しているかもしれません。
好奇心から今日の Feature を調べてみたところ、これらのフィルタリングされたビューを比較するのが興味深かったです。
投票数と「いいね！」の両方を含む Data Explorer クエリで何ができるか気になります… 
また：
自動化の考え: 「いいね！」に基づいて「プライマリ」プールを作成し、投票可能なステータスにリクエストをエスカレートさせるかもしれません。
手動キュレーションの考え: 明白なメリットのあるリクエストは、投票数に関係なくスタッフが時々取り上げることがあるため、ある意味、すでに何らかのキュレーションは行われています。しかし、すべてを迅速なスタッフレビューにかけるべきでしょうか？
サポートする例として、「ユーザーに自分のトピックを閉じさせる」に関する機能リクエストが 8 件見つかりました — 2014年から2025年のものまで — 数件はクローズされていますが、ほとんどが投票数 0 のままオープンになっています。同じリクエストが繰り返し行われているのに、古いバージョンが無視され、投票されていない場合、何かがうまく機能していません。
ユーザーが検索していない、または「あなたのトピックは類似しています…」というダイアログが表示されていない場合、初期のリクエストをスタッフのチェックポイントに到達させる以外に何ができるか分かりません。
新しい場合は、トピックを投票カテゴリに移動する。
類似のリクエストが存在する場合は、リンクを付けて返信する。
独り言です。すべてにリソースが必要なことは分かっています…
チームが投票されたトピックのリストを作成した後に投票を公開するのであれば、制限は問題ないでしょう。四半期ごとに投票を公開することも考えられます。アップデートでは、チームがロードマップに追加することを選択した機能と、優先順位の観点から考えられるタイムラインの詳細を説明することもできます。
そうでなければ、24というのは、一部の投票が1年以上、場合によってはそれ以上拘束されているため、実際には無制限ではありません。検討されていない可能性のある、事実上行き詰まっている機能から投票を削除しようとすることも面倒です。
一度、チームが強く検討している機能のリストを作成し、人々が投票するための投票を作成し、そこから物事を更新するというアイデアはどうでしょうか。リリースサイクルがあれば、トピック投票は悪くありません。そのサイクルがどうあるべきかは、チームが議論し決定する必要があることです。
意味がわかりません。もはや重要ではないことについての投票を公開できないのですか？
それは、以前投票されたものが実装されたか、もはや重要でなくなったと仮定しています。
チームが将来追加することを検討しているもののリストに機能リクエストをまとめ、その投票を再利用できるようにすることは、私の意見では理にかなっています。
トピック投票をそもそも何のために使うのでしょうか？あなたが言及したように、いいね/リアクションを、設定された投票数に限定される代わりに使うことができます。例えば、特定のリアクションである:discourse: を使うことは、その特定の#featureリクエストへの関心を測るのに十分かもしれません。なぜなら、データエクスプローラースクリプトを使って、このカテゴリ内のトップトピックを、この特定のリアクションが最も多いOP投稿で返すことができるからです。
投票を制限することと比べると、このカテゴリに直接関連する更新が私の経験上全くないため、あまり進展していないように感じられます。時々あるかもしれませんが、私が気づいていないだけかもしれません。
新しく展開されたもののいくつかは、かつて機能リクエストだったのだろうと確信しています。
私の意見では、トピック投票は、コンテストで、設定された締め切りでトップXトピックに投票し、発表日にトップ3の勝者を発表するのに適しているかもしれません。しかし、このカテゴリで使用すると、自分の投票を推測する必要がある、明確な結論のないコンテストのように感じられます。
「いいね！」 1
私はこのプロセスについて多くのコメントをしましたが、公平に言えば、「#completed」タグが付けられた機能リクエストはたくさんあります - カテゴリ:feature タグ:completed のフィルタリング結果
「いいね！」 2
完了したタグは役立ちます。しかし、チームが機能リクエストへの関心をより測りたい場合、投票数を制限することは逆効果になり得ます。
サムが言及したように、いいね/リアクションのような様々なシグナルがあります。（特定のリアクションを選択）あるいは投票制限なしでも構いません。すべてのアイデアに人々が投票/リアクションするわけではないからです。なぜなら、特定のアイデアに興味がないかもしれないからです。例えば、フォーラムチームの選出に関するリクエストがあると思います。
一部のフォーラムではそれはアイデア/選択肢かもしれませんが、多くの人は、フォーラムの管理者を誰にするかを潜在的な人気投票で決めることを望まないでしょう。
したがって、設定された数に制限するよりも、より多くの投票/リアクションがある機能の方が、コミュニティ全体の関心のレベルを示すことになります。設定された数に制限すると、関心が分散し、いわばより多くの同点が生じる可能性が高くなります。
「いいね！」 1
タグを見直すと、実際に追加された量を確認するのに役立ちます。しかし、投票の関心を制限するのは厳しすぎると感じます。完了した機能の中には、投票がほとんど、あるいは全くなかったものさえあります。もちろん、簡単で単純な勝利は良いことですが。
私のここでの夢は、誰もが、フィーチャーの独自の、パーソナライズされた、ランク付けされたビューを持つことができ、それをさまざまな「レンズ」を通してさまざまな集合的なビューに集約できるようにすることです。
したがって、すべてにおいて二者択一の賛成票/反対票とするのではなく、私は自分の「トップ10」リストを作成し、好みの順序で表示できるようにします。あなたも同じことができます。そして、「過去1年間にメタに参加した人々のトップ10リストを表示」したり、「スタータープランでホストされている人々のトップ10リストを表示」したりすることができます。
当面の間、オープンなロードマップとバックログをより一般的に管理する方法と関連する、ここでの管理をもう少し容易にするための他のアイデアがいくつかあります。これらには、バグ、フィーチャー、UXのカテゴリを管理する方法の変更や、オープンなアイデア出しと、私たちが作業を計画しているもの、または貢献を歓迎するものの具体的な提案や仕様とを分離する方法が含まれます。
年末までに、これに関するRFCのようなものをまとめて議論にかけたいと思っています。
「いいね！」 4