信頼レベルごとに許可される合理的な投票数について、皆さんはどう思いますか？メタでは、TL0を2票から0票に、TL4を10票から8票に変更したことがわかります。私自身も、ここに管理者がいるにもかかわらず、投票数がなくなっていることに気づきました！
「いいね！」 2
私は、この数が意図的に制限されているのは、「これは本当に私にとって重要だ」という指標として機能するためだとずっと思っていました。投票権がなくなっても、すべてのリクエストに「いいね！」を付けたり、機能リクエストにユースケースを追加したりすることはできます。また、私が投票した別の機能リクエストが完了してトピックが閉じられれば、これらのトピックに投票することもできます。
「いいね！」 1
@tobiaseigen、私はそれらを制限しません… 私は投票をまったく使用しないことに気づきました。なぜなら、私にとって、単に何かを支持するか反対するかのどちらかだからです。いいねが存在するのに、何かが私にとって本当に重要かどうかを判断することは、特に実用的な時間の使い方ではありません。
「いいね！」 2
最近のこの議論をJammydodgerの元の投稿に移動しました。Contribute > Feature の投票についてここで話し続けるのが適切だと感じたからです。
制限を設けるアイデアは好きですが、同時にオープンな機能リクエストが非常に多く存在しており、制限値を非常に低く設定するのは不公平に感じます。自分自身もこの制限によって制約されていると感じています！投票はシグナルでもあり、人々が投票できないようにすることで、プロダクトチームはそのシグナルを受け取れなくなってしまいます。
以下のような方針で制限値を引き上げることに傾いています。皆様のご意見をお聞かせください。
| 信頼レベル | 現在の投票数 | 提案される投票数 |
|---|---|---|
| TL0 | 0 | 0 |
| TL1 | 4 | 10 |
| TL2 | 6 | 20 |
| TL3 | 8 | 24 |
「いいね！」 2
Imo 24はこれを事実上無制限にします。
現在の制限は気に入っています。考えさせられます。
「いいね！」 2
貴重な投票を厳しく制限することが、情報の不足を招いているのではないかと疑問に思います。ここにいるユーザー数に比べて、投票数は全体的に低く見えます。多くの機能提案は「いいね」の数の方が投票数より多いですが、おそらく注目されるのは投票だけなのでしょう。
常に投票数が不足し、新しいトピックに投票するためには常に優先順位をつけたり、他の投票を犠牲にしたりしなければならないのは、大きな障壁です。私は自分の既存の投票を確認し、どうすれば投票枠を空けられるか考えていますが…どのリクエストも「価値がない」わけではありません。単にフィードからスクロールされ、忘れ去られてしまったのです。
それらを諦めるべきなのでしょうか？
コメントでお気に入りトピックを押し上げるべきでしょうか？機能に投票した上で、「そうだね、良いアイデアだね！」とコメントするのは、余計な雑音のように感じられます。
良いアイデアは、たった1〜2票で止まったままです。人々はそれらを見つけられていないのでしょうか、関心がないのでしょうか、それとも…単に投票枠が尽きているのでしょうか？
制限を緩和すれば、大量のコーディングは不要で、効果がありそうです。しかし、渋滞を減らすために道路を拡げると、かえって交通量が増え、結局元の状態に戻ってしまうという状況も思い浮かびます。
ただの思いつきですが…ハードリミットの代わりに、多少のコーディングを伴う機能的な変更案をいくつか挙げてみます。
- TL（Trust Level）に基づいて、月ごとの投票数を割り当てる。（「投票日」には、人々が#contribute: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がアップボートを制限していないことは、単純なサポート対非サポートのインジケーターとしてそれらを持つことに価値があることを示しているかもしれません。
今日は好奇心から Contribute > Feature を覗いていたら、これらのフィルタリングされたビューを比較するのが面白かったです：
「Votes」と「Likes」の両方を含むData Explorerクエリで何が実現できるか気になります… 
また：
自動化に関する考え： 「Likes」に基づく「プライマリー」プールを作成し、リクエストを投票可能なステータスに昇格させるのはどうでしょうか。
手動によるキュレーションに関する考え： 時々、明らかな価値のあるリクエストが、投票数に関係なくスタッフによって採用されます。ある意味、すでにキュレーションが行われています。しかし、すべてのリクエストにスタッフによる迅速なレビューを受けるべきではないでしょうか？
補足例：「ユーザーが自分のトピックを閉じられるようにする」という機能リクエストを8件見つけました（2014年から2025年まで）。いくつかはクローズされましたが、ほとんどは投票数0でオープン状態のままです。同じリクエストが繰り返し行われ、古いバージョンが見逃され、投票もされないのは、何かうまくいっていない証拠です。
ユーザーが検索していない、または「あなたのトピックは類似しています…」というダイアログが表示されない場合、他にできることは限られています。初期リクエストをスタッフのチェックポイントに到達させることです：
新しい場合はトピックを投票用カテゴリに移動する、
類似するリクエストが存在する場合はリンク付きで返信する。
ただ、思いつくままに話しています。すべてリソースがかかることは承知しています…
チームが投票されたトピックのリストを作成した後に投票を公開するのであれば、制限は問題ないでしょう。四半期ごとに投票を公開することも考えられます。アップデートでは、チームがロードマップに追加することを選択した機能と、優先順位の観点から考えられるタイムラインの詳細を説明することもできます。
そうでなければ、24というのは、一部の投票が1年以上、場合によってはそれ以上拘束されているため、実際には無制限ではありません。検討されていない可能性のある、事実上行き詰まっている機能から投票を削除しようとすることも面倒です。
一度、チームが強く検討している機能のリストを作成し、人々が投票するための投票を作成し、そこから物事を更新するというアイデアはどうでしょうか。リリースサイクルがあれば、トピック投票は悪くありません。そのサイクルがどうあるべきかは、チームが議論し決定する必要があることです。
意味がわかりません。もはや重要ではないことについての投票を公開できないのですか？
それらの以前に投票された事項が既に実装されているか、もはや重要でないと仮定しています。
チームが将来追加することを検討している機能リクエストをリスト化し、それらの投票結果を再利用可能として公開することは、私見ですが理にかなっていると思います。
なぜトピック投票を使うのでしょうか？ あなたが指摘したように、Like/リアクションを制限された投票数の代わりに使用することができます。 例えば、特定のリアクション（
など）を使用することで、そのカテゴリのデータエクスプローラースクリプトを使って、特定のリアクションが最も多いトピックをOP（元の投稿）で上位表示するなどして、特定の #contribute:機能リクエストへの関心を計測することが十分可能です。
一方、投票を制限することは、私の経験ではこのカテゴリに関連する更新が全くないため、進展がないように感じられます。 時折あるかもしれませんが、私が気づいていないだけかもしれません。
ただし、新しく導入された機能のいくつかは、かつて機能リクエストだったものもあるはずです。
私見ですが、トピック投票は、特定の締め切り日を設定して、上位X件のトピックの中から発表日に上位3位を決めるコンテストの投票には適していると思います。 しかし、このカテゴリで使用すると、明確な結論がなく、自分の投票を二の次にするようなコンテストのように感じられます。
「いいね！」 1
私はこのプロセスについて多くのコメントをしましたが、公平に言えば、「#completed」タグが付けられた機能リクエストはたくさんあります - カテゴリ:feature タグ:completed のフィルタリング結果
「いいね！」 2
完了したタグは役立ちます。しかし、チームが機能リクエストへの関心をより測りたい場合、投票数を制限することは逆効果になり得ます。
サムが言及したように、いいね/リアクションのような様々なシグナルがあります。（特定のリアクションを選択）あるいは投票制限なしでも構いません。すべてのアイデアに人々が投票/リアクションするわけではないからです。なぜなら、特定のアイデアに興味がないかもしれないからです。例えば、フォーラムチームの選出に関するリクエストがあると思います。
一部のフォーラムではそれはアイデア/選択肢かもしれませんが、多くの人は、フォーラムの管理者を誰にするかを潜在的な人気投票で決めることを望まないでしょう。
したがって、設定された数に制限するよりも、より多くの投票/リアクションがある機能の方が、コミュニティ全体の関心のレベルを示すことになります。設定された数に制限すると、関心が分散し、いわばより多くの同点が生じる可能性が高くなります。
「いいね！」 1
タグを見直すと、実際に追加された量を確認するのに役立ちます。しかし、投票の関心を制限するのは厳しすぎると感じます。完了した機能の中には、投票がほとんど、あるいは全くなかったものさえあります。もちろん、簡単で単純な勝利は良いことですが。
私のここでの夢は、誰もが、フィーチャーの独自の、パーソナライズされた、ランク付けされたビューを持つことができ、それをさまざまな「レンズ」を通してさまざまな集合的なビューに集約できるようにすることです。
したがって、すべてにおいて二者択一の賛成票/反対票とするのではなく、私は自分の「トップ10」リストを作成し、好みの順序で表示できるようにします。あなたも同じことができます。そして、「過去1年間にメタに参加した人々のトップ10リストを表示」したり、「スタータープランでホストされている人々のトップ10リストを表示」したりすることができます。
当面の間、オープンなロードマップとバックログをより一般的に管理する方法と関連する、ここでの管理をもう少し容易にするための他のアイデアがいくつかあります。これらには、バグ、フィーチャー、UXのカテゴリを管理する方法の変更や、オープンなアイデア出しと、私たちが作業を計画しているもの、または貢献を歓迎するものの具体的な提案や仕様とを分離する方法が含まれます。
年末までに、これに関するRFCのようなものをまとめて議論にかけたいと思っています。
「いいね！」 4