Discourse Post Voting からの議論の続きです。
Q&Aトピックの最初の投稿は質問そのものであるため、アップボートオプションは無効にすべきです。
「いいね！」 2
これはトピック間の優先順位付けのための機能ではありませんか？
現在、誰かがトピックに投票する理由が不明確で分かりにくいことに同意します。
「いいね！」 2
投稿をこちらに移動しました @volanar。以前にも言及がありましたので。
意図的なものだと返信があったと思ったのですが、見つかりません。探してみて、何か分かりましたらお伝えします。
「いいね！」 5
「いいね！」 6
これはサイトの設定に大きく依存します。質問の質に投票することは、Stack Overflowのようなサイトでは確立されたものです。
投票コントロールは意図的に保持しており、CSSで削除しても問題ありません。サイトの設定で追加することも検討します。
「いいね！」 5
しかし、質問自体は回答の投票に参加できません。さらに、回答と一緒にフィルタリングすることもできません。常に一番上に表示されるべきです。
「いいね！」 1
OPのスタイルを別のものにすると、返信のものとは意味が違うことを示すのに役立つのではないでしょうか？
「いいね！」 1
質問への投票は、Discourse の文脈において本当に議論に値する事項だと私は考えています。私は SO 風のサイトに少しの経験がありますし、post-voting 型のトピックにおいて、投票が質問に対して果たす有用性について少し考えてみたいと思います（便宜上、以降はこれらを単に「質問」と呼びます）。
あなたは、Stack Overflow などの純粋な Q&A プラットフォームでは、質問への投票（賛成・反対）が特定の目的に使われていると指摘しています。具体的には以下の通りです。
- 質問の質を示す、または「同じ質問を持っている」「そのような質問の必要性が理解できる」ことを示す
- 質問をスコアで検索・ソート・フィルタリングする
- 質問がサイトの範囲内か外かを示す
- 特に質の低いコンテンツを隠す
- 非モデレーターユーザーによる削除を可能にする
- 良質な/悪質な質問を投稿したユーザーに評判（レピュテーション）やカルマで報いる/罰する。
私の知る限り、これらは現在、プラグインを使用しているかどうかに関わらず、Discourse には当てはまりません。この機能は比較的新しいものですが、これらの Q&A 機能のうち、Discourse で実際に活用したいと思うものがどれくらいあるのか興味があります。表面的には、現在の信頼レベルシステムや他のモデレーション慣行からの大きなパラダイムシフトのように見えます。
もし これらの質問タイプの追加の主な目的が、コミュニティが容易に SE スタイルのサイトを構築・ホストできるようにし、その主目的を議論よりも構造化された Q&A にすることにあるのであれば、それは非常に興味深いことです。詳しく聞かせていただきたいのですが… 私は SO で多くのことを学び、その核心的な機能の一部を疑問視するに至り、ゼロから構築するならば SO の多くの側面をそのまま模倣することはむしろ勧めないだろうと考えるようになりました。
Discourse コミュニティが投稿投票プラグインを実行するといったハイブリッドシステムについて考える際、正直なところ、質問 への投票がそもそも意味をなすかどうか分かりません。この機能やその実装について詳しくは知らないことを認めますが、少し触れてみたり、ここにある投稿を読み漁って学んだりした結果、この結論に至りました。
Discourse において質問投票がもたらす価値とは？
このプラグインが公式になってから 1 年未満であり、まだ流動的であることは理解しています。Discourse のモデレーション、機能、または範囲について専門家であると主張するつもりはありません（間違いがあれば指摘してください）が、現状では異なる（そしておそらくより良い）解決策が用いられており、質問スコアの多くの必要性を不要にしているように思えます。
TL;DR - 太字 の部分をお読みください。
| # | 機能 | SO での利用 | Discourse での利用 | 有用か？ |
|---|---|---|---|---|
| 1 | 投票による通知 | 賛成票は投稿者に評判の変化を通知します。SO には「いいね」機能はありません。 | 投票は質問者に通知を送りませんが、「いいね」は送ります。 | 投票通知を Discourse に追加するのは容易だと思われますが、なぜ両方必要なのでしょうか？「いいね」こそが、ここで質問投票が不要に見える主な理由の一つです。 [1] |
| 2 | 質問者への投票の影響（評判） | 評判は SO における権限付与の基準であり、ユーザーの評判は彼らのステータスの主要な側面です。評価の高い質問から評判を得ることは、質問のみを投稿するユーザーが権限を得られる数少ない方法の一つです。 | 評判に相当するものはありません。権限は信頼レベルシステムを通じて付与され、TL 1 では単にコンテンツを読むことを重視・報酬としています。Q&A 形式の投稿への投票は「いいね」としてカウントされるようですが、質問にも回答にも「いいね」は存在しません。 | 投稿作成、評判、権限の直接的な結びつきは、私が SO で最も変更したい側面です。ユーザーはコンテンツ作成を必要としない複数の経路で権限を得られるべきです。ユーザーが TL を獲得するために質問投票を必要としないのであれば、それは不要に思えます。 |
| 3 | 質問者への投票の影響（非評判） | 非公開で自動的な SO の再犯防止システム（モデターによって上書きできない）の一部は、質問スコアに基づいて、一貫して低評価の質問を投稿するユーザーの将来の質問をブロックすることに依存しています。SO には、コンテンツがサイト上で公開される前にプレビューを要求する手段はありません。 | モデレーターは、自動化ではなく、ツールを使用してユーザーを黙らせ、停止させるか、ユーザーの TL を上書きします。新規投稿のモデレーター審査を要求する設定は一部のケースで利用可能ですが、投稿の受容度に基づくものではありません。 | SO の規模と「誰でも質問できるようにする」という優先度を考慮すると、ユーザーに対する自動的な質問禁止の使用は理解できます（ただし、システムの見直しが必要です [2])。既存の TL ベースの投稿制限とフラグの使用に依存すれば、ユーザーモデレーションのために質問スコアは不要です。 |
| 4 | ポストへのスコアの影響 | 低スコアの質問はフロントページから隠され、信頼されたユーザーや自動化によってより簡単に削除されます。特定のフラグタイプは、十分な数を受け取ると質問を削除できます。同じタイプのフラグは、誰が投じたかに関わらず、すべて同じ重み付けされます。 | フラグに基づいて投稿を自動的にクローズ、非表示、削除する堅牢な既存システムがあり、これによりフラグが付けられた投稿にモデターの注意を引くことができます。優れたフラグ履歴を持つユーザーからのフラグは、持たないユーザーからのものよりも重み付けされます。 | 既存のシステムは非常にバランスが取れているように思えます。過去のフラグを使って新しいフラグに重みをつけることで、ユーザーは正確なフラグ付けをするよう動機付けられます。対照的に、重み付けされていない投票を使ってコンテンツを隠したり削除したりするのは誤用されやすく、過去の投票を考慮していません。既存のフラグシステムと併せて、投票に頼って投稿をモデレーションする必要はありません。 |
| 5 | 質問のソート/フィルタリング | 質問スコア、回答数、解決ステータスは、すべての質問リストビューで明確に示されます。検索はユーザーのリクエストに応じて、質問スコアを使って結果をフィルタリングおよびソートできます。すべてのトピックが Q&A であるため、Q&A のみを検索するための構文は不要です。検索には質問のみを返す構文が含まれています。 | 質問スコアはトピックリストに表示されませんが、解決ステータスと回答数は表示されます。結果は「いいね」（投票を含む）でソートできます。Q&A トピックのみを返す方法はありません。in:first 構文は質問のみを返すように思えます。 |
投稿タイプ（Q&A 対議論、質問対回答/レスポンス）の検索構文の追加は価値があるように思えますが、脇道にそれています。(トピックリストに OP の投票を表示する機能リクエスト) は有用かもしれませんが、トピックリストにおける質問スコアの代わりとして「いいね」を採用するか、あるいは FR を却下して UI を現状のまま維持することもできます。 |
| 6 | 賛成票の意味 | 質問の賛成票のホバーテキストには「この質問は研究努力を示しています。有用で明確です」と表示されます。前半は議論の余地があり、後半は主観的で曖昧です。ユーザーは「私も同じ質問をしました！」など、多くの理由で質問に投票する可能性がありますが、これは「有用」に含まれると主張できますが、専門家は単純で一般的な質問は（自分にとって）有用ではないと判断して反対票を投じるかもしれません。 [3] [4] | 未定義。いつ投票すべきかについての UI 上の指示はありません。これは新しい機能であり、コミュニティによって投票を推奨する理由が異なる可能性があるため、理解できます。馴染みのある「いいね」機能はこのトピック形式では欠落しています。「いいね」はハートに限定される可能性がありますが、コミュニティは追加のリアクションを設定できます。 | 投票のタイミングについて合意形成に成功したコミュニティであっても、質問投票の理由は、回答投票の理由（ほぼ常に「これは正しい」または「これに同意する」）よりも頻繁に主観的で広範です。コミュニティが多様なリアクションオプションを追加した場合、「いいね」こそが、純粋な賛成/反対投票よりも「なぜ」誰かが質問に投票したのかをよりよく説明できます。 |
| 7 | 反対票の意味 | SO で質問に反対票を投じるタイミングを 10 人に聞いても、おそらく 10 通りの答えが返り、その半分は「誤り」であり、多くの場合は編集、フラグ付け、クローズ、またはコメントで対処すべきものです。これらの機能の未使用は、質問者が自分の質問が説明なしに反対票を付けられたことに混乱と苛立ちを感じ、メタで投稿し、そのような投票を禁止するよう求める原因となります。 [5] | 同様に、当然ながら未定義です。質問の多くの問題は、コメントで実行可能な変更や推奨事項を指摘したり、質問のフラグオプションを使って質問者に DM を送ったり、モデレーター向けにフラグを立てたりすることで、より効果的に対処できるでしょう。デフォルトのハートは、反対票の否定的な含意とは相容れません。 | 人々は反対票を嫌います。プラットフォームがユーザーに反対票を付けられたことを知らせないように多大な努力を払っていてもです。これは、助けを求めており、行き詰まりやフラストレーションを共有することで脆弱になっている質問者にとって、より苦痛であることが多いです。質問への反対票は簡単な対応かもしれませんが、質問者の改善には役立ちません。他のツールに頼ることで、疎外感ではなくコミュニケーションを促すことができます。 |
コミュニティの拠点に合わせた図書館機能の適応
既存のプラットフォーム、特にあなたが構築に関わったプラットフォームのパターンに従いたいという衝動は理解できます。しかし、SE/SO 上のコミュニティについて私が得た最大の教訓は、大多数の（新しい）ユーザーが SE をフォーラムに近いものだと誤解しており、特にクローズや投票の面で最初の質問の受け入れ方に苦労しているということです。SO で質問することは多くの人にとってストレスを誘発します… インターネットには、SO に関する参照が溢れており、そこでは質問が 完全に無視されるか、プログラミング質問として何が資格を満たすかについての難解で気まぐな期待を持つ、自任したプラットフォームおよび主題の専門家によって厳しく判断されると伝えられています… そして、多くの人はそれを望んでいません。
彼らが頻繁に述べている望みは、人を知り、つながりを作り、馬鹿にしたような気分にならずに助けを求められる、小さく親密なコミュニティです。多くの点で、Discourse はまさにそれだと私は思います。オープンエンドで主観的なトピックを奨励しつつ、より古典的な Q&A 形式もサポートする広範な形式を持つことで、コミュニティが望む方法で互いを支援できるようにしています。
仮に SO が知識図書館を作成・キュレーションする最善の方法だったとしても（実際にはそうではありません）、Discourse は（そしてそうであってはならない）そのようなリソースになろうとするものではありません。Discourse のホームページは、Discourse を「コミュニティのオンラインホーム」として売り出しています。私が子供たちに居心地の良い家を感じてほしいと思うとき、私は彼らの質問を奨励し育成し、会話に参加するためのスペースを作ります。彼らを図書館に連れて行くとき、私は頻繁に彼らに静かにするように言い、本棚をジャングルジムのように扱うのを防がなければなりません。
私の考えでは、質問投票は図書館には必要かもしれませんが、おそらく家には必要ないでしょう。そして、それは人々がその家をどれだけ楽しめているかに悪影響を及ぼす可能性があります。
座学での PM 的考察
このセクションは、上記の巨大なテーブルよりもはるかに重要ではありません。まだ読んでいない場合は、まずそちらをお読みください。このテーブルは、私がこの要約に至った経緯を説明するものですが、私の情報の不備による問題も明らかにするでしょう。念のため、私は Discourse の専門家ではありません。「Discord」と書いてしまわないように常に確認しています。
- 質問投票の削除 - もし人々が SO のような純粋な Q&A を本当に望むのであれば、それは設定にできますが、デフォルトはオフにするべきです。
- 質問への「いいね」の復活 - 人々が質問に友好的に反応・支援できる手段を提供します。質問に適したデフォルトのリアクション（肯定的なものも否定的なものも）を提供することを検討してください。
- 同じトピックで「いいね」か投票かのどちらかに統一したいという意図は理解できますが、両方を混ぜる価値はあると思います。Discourse ユーザーはすでに「いいね」に慣れています… 実際には…
- 回答への「いいね」の価値の調査 - 投票やコメントに加えて検討します。リアクションは投票よりも友好的に感じられ、コメントを書かずに賛成/反対の二元論以上のことを示したい人もいます。投票と「いいね」がすでに検索結果のソートに使われているなら、回答の順序決定時に両方を使う方法があるかもしれません。レビューキューでのフラグスコアに似たアプローチです。
- 回答への投票を維持 - 回答投票は、単一の質問に対するソリューションをランク付けするという主要な目的を果たしており、ストレスを引き起こす可能性があっても、賛成票も反対票も不可欠です。
同じトピックで「いいね」と投票を混在させたくないという意図は理解できます。 ↩︎
anecdotal ですが、質問者を早期に q-ban（質問禁止）させることを目的として、一部のユーザーが質問に対して反対票を過剰に使う傾向があり、これが解除をより困難にしているケースもあります。そのようなシステムでは、意図せぬ結果を考慮し、それを最小化する方法を見つけることが不可欠です。 ↩︎
SO における質問投票について TED トークができるほどですが、多くの SO ユーザーが「情報の図書館」という概念を忘れ、その「研究努力を示す」というホバーテキストがそれを助長してしまったと言わざるを得ません。優れた図書館にはすべての情報が揃っています。図書館の向こうの町に同じ情報があるからといって、追加を拒否するのはばかげています。 ↩︎
また、「メタでは投票が異なる」という話には触れないでおきますが、私の解決策は Discourse と Q&A を統合することなので、少なくともトピックに合致するかもしれません。 ↩︎
SO で何と言おうと、反対票は個人的に感じられます。たとえそう意図されていないとしても。 ↩︎
「いいね！」 2
この比喩は大好きです。私の家が（子供たちが宿題をしているとき）図書館のように扱われることもあれば、図書館が（コミュニティイベントを開催するとき）遊び場になることもあることに注意してください。しかし、デフォルトが重要です。Discourseは、良くも悪くも、よりリラックスした議論フォーラムというデフォルトを持っています。それは敵対的ではなく協調的です。Q&Aは、ほとんどのDiscourseコミュニティでは例外となるでしょう。
私には複雑な思いがあります。ダウン投票は、代替手段よりも意見の不一致を表現するより親切な方法であると私は思います。ダウン投票に関する多くの苦情に対応してきた中で、人々が抱える最大の懸念は、匿名でのダウン投票は、接続された評判システムという文脈では不公平に感じられることです。人々は、なぜダウン投票されたのかを知りたいと思っています。表面的には、問題を修正するために知りたいと思っています。実際には、ほとんどの人はダウン投票した人と議論したいと思っており、議論の根拠となるものが何もないのだと推測します。それらの議論はめったに生産的ではないので、それは通常良いことです。
特に質問に対するダウン投票は、ほとんどのフォーラムの協調的な性質を考えると、Discourseでは扱いにくいです。Stack Overflowの例なしで開発された場合、人々が質問の投票を望むかどうかはわかりません。理想的な世界では、投票は質問の質を反映するでしょう：
- 問題が明確に説明されていますか？
- 他の人が問題を調査するための十分なコンテキストが提供されていますか？
- 要点に絞られており、不必要な背景情報が避けられていますか？
- コミュニティの専門分野に該当しますか？
厳しい現実は、質問の投票はコミュニティが質問に対して抱く感情を反映する傾向があるということです。Stack OverflowでNullPointerExceptionエラーについて質問している場合、どれだけうまく質問しても、悪い経験をするでしょう。それは百万回も聞かれており、人々は別のバージョンの質問に答えることに興味がありません。
おそらくそれは質問投票の機能であり、バグではありません。もしそうなら、コミュニティが追いつけないほど質問が多い場合に意味をなす機能です。新しく形成されたコミュニティや、Q&Aに時折陥る協調的なフォーラムであるコミュニティを助ける機能ではありません。つまり、質問投票は非常に多くのDiscourseコミュニティを助けるとは思えません。したがって、それは「無効」をデフォルトとする設定であるべきだと思います。
最近、ビデオAMAのために質問を収集していたクライアントにPost Votingを提案しました。古いシステムは、いいねの数に応じて上位X個の質問を収集することでした。質問をしている人は、質問のリクエストへの返信を並べ替える簡単な方法がありませんでした。Post Votingは、返信が自動的に並べ替えられるため、この目的に最適です。しかし、含まれている質問投票は無意味で混乱を招きます。多くの人々はAMAのために質問を送信するためにコミュニティを訪れています。いいねは有用なシグナルになります。ダウン投票？おそらく誤クリックか、新機能の実験でしょう。今晩、CSSで削除する予定です。[1]
テーマに合わせて調整する必要がある他の調整がいくつかあるため、この煩わしさを修正するのに良い機会です。 ↩︎
「いいね！」 1
質問自体に投票機能を提供したい場合、トピック投票プラグインを使用するのは理にかなっていますか？それとも、私の理解が間違っていますか？