信頼レベルごとに許可される合理的な投票数について、皆さんはどう思いますか？メタでは、TL0を2票から0票に、TL4を10票から8票に変更したことがわかります。私自身も、ここに管理者がいるにもかかわらず、投票数がなくなっていることに気づきました！
「いいね！」 1
私は、この数が意図的に制限されているのは、「これは本当に私にとって重要だ」という指標として機能するためだとずっと思っていました。投票権がなくなっても、すべてのリクエストに「いいね！」を付けたり、機能リクエストにユースケースを追加したりすることはできます。また、私が投票した別の機能リクエストが完了してトピックが閉じられれば、これらのトピックに投票することもできます。
「いいね！」 1
@tobiaseigen、私はそれらを制限しません… 私は投票をまったく使用しないことに気づきました。なぜなら、私にとって、単に何かを支持するか反対するかのどちらかだからです。いいねが存在するのに、何かが私にとって本当に重要かどうかを判断することは、特に実用的な時間の使い方ではありません。
「いいね！」 1
この最近のディスカッションを Jammydodger の元の投稿に移動しました。投票についてここで話し続けるのが適切だと感じたからです。
制限のアイデアは好きですが、非常に多くの未解決の機能リクエストがあるため、非常に低い制限を設定するのは不公平だと感じます。私自身もこれで制約を感じています！投票はシグナルでもあり、人々が投票できないようにすることで、製品チームからそのシグナルを奪うことになります。
以下のような方向で制限を引き上げることを検討しています。皆さんはどう思いますか？
| 信頼レベル | 現在の投票数 | 提案された投票数 |
|---|---|---|
| TL0 | 0 | 0 |
| TL1 | 4 | 10 |
| TL2 | 6 | 20 |
| TL3 | 8 | 24 |
「いいね！」 1
Imo 24はこれを事実上無制限にします。
現在の制限は気に入っています。考えさせられます。
「いいね！」 2
貴重な投票の厳格な配分が、限られた情報につながるのではないかと疑問に思っています。ここのユーザー数に対して、投票数は一般的に少ないように思えます。多くの機能提案は、投票よりも「いいね！」の方が多いですが、注目されるのは投票だけだと想像しています。
常に投票がなく、新しいものに投票するためにトリアージと犠牲を払わなければならないのは、大きな障壁です。私は既存の投票を確認して、どのように投票を解放できるかを見ていますが、リクエストのどれも「価値がない」わけではありません。単にフィードからスクロールして忘れられただけです。
それらを諦めるべきでしょうか？
お気に入りにコメントして「いいね！」を増やすべきでしょうか？機能に投票した後、「はい、良いアイデアです！」とコメントするのは、無駄なノイズのように感じます。
良いアイデアが1つか2つの投票で放置されています。人々はそれらを発見していないのでしょうか、興味がないのでしょうか、それとも…単に投票がないのでしょうか？ 
制限を増やすには多くのコーディングは必要なく、役立つように思えますが、道路を広げて交通量を減らすと、さらに交通量が増え、元に戻ってしまうという考えも浮かびます。
ただの思いつきですが…ハードリミットの代替として、多くのコーディングが必要な機能変更をいくつか提案します。
- TLに基づいて毎月一定数の投票を割り当てる。（「投票の日」には、人々が#featureを訪れて未解決の項目を評価するため、活動が活発になります…）
…または、heliosurgeが言及したように、最終的に投票を解放する。
- 一定時間経過後に使用済みの投票を解放する、または
- スタッフが定期的に古い機能リクエストをレビューし、a) もう一度チャンスを与えるためにトピックを更新するか、または b) 「対処する計画はない」とコメントして投票を解放する。
…いずれの場合も、投票はそのまま残り、ユーザーはこれらのトピックの投票を解除することで投票割り当てを超えることはできません。
（私には簡単に言えますが、おそらくかなりのコーディングが必要でしょう 
）
「いいね！」 1
@sam、私にはそうではありません。なぜなら、私は単に「いいね」を使用するだけだからです。現在の実装は、GitHub Discussions の「アップボート」と「サムズアップ」が両方存在するのと同様に、少し冗長に感じられます。
「いいね！」 1
重複したシグナルがあるのは紛らわしいという意見に同意します。
「機能リクエストの書き方が気に入りました。私には良いと思います」
対して
「これは間違いなく私のトップ8に入ります。ディスコースが構築すべきだと思います」
トピック投票が有効な場合にopの「いいね」を無効にするのは興味深い実験かもしれません。
「いいね！」 1
「申し訳ありませんが、これは行いません」とコメントして一部のリクエストを閉じることについて
2年間完了した機能や、もはや意味をなさない機能リクエストを古いものとして閉じることには、確かに非常に説得力のあるものがあります。
「いいね！」 2
最終的にはそれほど変わらないと思います。私の投票のほとんどは1年前に追加されました。はい、もっと多くのトピックに投票できたでしょうが、一度すべての投票を使い切ると、また同じになります。1つが完了して閉じられるのを待つか、別のトピックから投票を削除する必要があります。Metaには20件以上の優れた機能リクエストがあることも確かです 
前述したように、私にとって投票は「いいね」よりも強力なものです。しかし、興味を捉えるためには、最初の投稿への「いいね」も非常に役立つと今でも思っています。投票が有効になる前の10年以上、それらは指標でした。したがって、それらを無視すること、特に長期間のリクエストで無視することは、当時ユーザーがサポートを示す唯一の方法を無視することを意味します。
また、誰も機能リクエストをそれほど必要としているとは思わず、投票を費やすことはないかもしれませんが、多くのユーザーはそれが役立つと考えて「いいね」をしています。1つの投票（通常はリクエストの作成者による）は、複数の「いいね」よりも、さまざまなDiscourseサイトにとってその機能がどれほど役立つかについて、より多くを語るでしょうか？
「本当にこれに興味がある」という投票数を増やす代わりに、それらを分散できるトピックの数を制限する方が良いのではないでしょうか。
したがって、今年の約100件のトピックに378件の[
]トピックに投票する代わりに、それらを事前選択することが理にかなっているかもしれません。
たとえば、複数のユーザーからの関心を示す特定の量のリアクションがあるリクエストのみが投票可能であるか、または時間で制限して、特定の期間のトピックに投票を制限して、それらの機能グループ内でお気に入りを検索できるようにすることができます。
「レビューキューを改訂しています。どのようなリクエストが思い浮かびますか？」と言うこともできます。その後、それらはサブカテゴリに移動され、投票されます。
約100件のトピックに4票を投じることができるのは、すべてのオープンな機能トピックに10票を投じることができるよりも比例して多くなります。
「いいね！」 2
@sam、私は逆を期待していました。投票は、いいねにはない何かを技術的に提供しますか？サポートしないFRを誰もいいねしないと思います。
いいねが無効になった場合、それは「インテリジェンスを低下させる」ことになると思います。比較として、ForgejoとGitLabがアップボートを制限していないことは、単純なサポート対非サポートのインジケーターとしてそれらを持つことに価値があることを示しているかもしれません。