Discourseチームが、私を含め、他の多くの人々の提案に対してオープンであることに感謝しています。
長年にわたりMetaでこの問題が頻繁に発生しているのを見てきましたが、今回、一般的な私の考えを述べるきっかけとなりました。私もそれを見てフラストレーションを感じていましたが、どのように提起すればよいか分かりませんでした。そこで、今、それについて書いてみようと思います。
背景
時折、MetaでDiscourseの機能や変更に関する新しい提案に対して、人々が群がって批判する傾向が見られます。ソフトウェアに新しいユーザーの経験に耳を傾け、理解するのではなく、コミュニティのメンバーがアイデアを先回りして否定してしまうことがあります。これは、アイデアが過去にDiscourseチームによって却下された場合や、Discourseチームによって他の設定よりも特定のデフォルト設定が選択された場合などに起こります。
たとえそうであっても、過去に議論されたことがある場合でも、なぜアイデアやソフトウェアに関する苦情を先回りして却下すべきではないのか、私の考えを述べたいと思います。
Discourseチームが最終決定権を持つ。多くのことが変化した。当時のことは現在当てはまらないかもしれない。
まず、私たちコミュニティメンバーはDiscourseのプロダクトマネージャーではありません。誰かのアイデアが過去に却下されたことやその理由を伝えると、それは必ずしもDiscourseのプロダクトチームの現在の決定を反映しているとは限りません。
時には、Discourseチーム自身が、過去に却下された機能を開発することに決定することもあります。チャットはそのような機能の1つでした。
したがって、過去の決定が現在の決定と同じであるという100％の保証はありません。
Discourseチームのメンバーでさえ、Discourseの優先事項について互いに異なる見解を持っていることがあります。
例えば、私はよく@erlend_shのブログを読んでおり、彼がチャットをDiscourseにどのように組み込むかについてチームの他のメンバーとは異なる見解を持っていたことを議論しています。強調は私によるものです。
ほとんどのオープンソースプロジェクトには専用のフォーラムはありませんが、それらを持つプロジェクトはほぼ間違いなくグループチャットも備えています。私の最後のDiscourseでの仕事は、Discourse Chatの導入によって、これら2つのモードを統合しようとする試みでした。
私はそのMVP（その後コアに昇格しました）を非常に誇りに思っていますが、そこから私が進みたかった方向は、従来のフォーラムとしてのDiscourseプロジェクトのDNAとは理解可能なほど互換性がありませんでした。私はチャットを私たちのコミュニティ体験のリードにすることを提案しました。コミュニティはチャットルームから始まると私は思いました。Discourseはそうは思わなかったので、私たちは友好的に別れました。
数年後、私の立場は変わりません。「グループチャット」と「フォーラム」はほぼ同じ意味であるべきです。実際、Discord、私たちのコミュニティの支配者、は現在、フォーラムパラダイムにうまく収まるさまざまなスレッドとボード機能もサポートしているため、私たちはその方向に向かっているようです。
したがって、何がDiscourseに含まれるべきではないかを私たち自身が時期尚早に決定することはできません。なぜなら、それも時間とともに変化する可能性があるからです。
Discourseの初期からいる私たちにとっては、CDCKが10人未満で、プロダクトマネジメントがDiscourseの共同創設者によって非常に多く推進されていたことを覚えているでしょう。しかし、現在、CDCKは100人の強力なチームであり、CDCKにはプロダクトチーム全体があります！
Discourse自体ははるかに多くのユーザーベースを持っており、ソフトウェアのニーズと使用法は、Discourseの初期の採用者を超えて成長しました。より広範には、ソーシャルプラットフォームの状況は変化し（FacebookからDiscordなどに勢いが移り）、人々の一般的な期待も変化しました。
チームはDiscourseの初期よりもはるかに大きくなったため、過去のプロダクト開発の初期には優先度がはるかに低かった他の機能に取り組むための能力が増えました。
したがって、現在機能リクエストをどのようにレビューするかは、初期の頃とはかなり異なるでしょう。プロダクトチームは、何が最終的に開発され、いつ開発されるかを決定するための独自のプロセスを持っています。
より多くのデータポイントが望ましい
第二に、Discourseチームがより少ないデータポイントよりも多くのデータポイントを聞くことは、通常役立ちます。
Metaで「3の法則」として緩やかに普及したものがありました（機能リクエストが検討される前に、少なくとも3人が何かについて苦情を言う必要があります）。それであっても、人々が経験を共有し、苦情を言うことを許可しなければ、3人の異なる人が何か問題を見つけることを聞くことができます。
それとは別に、もう1つの普及したアイデアは苦情駆動開発でした。そして、これでは、人々の意見を聞く必要があります。
私が機能したと見た唯一のことは、ユーザーと深く関わり、彼らとコミュニケーションを取り、関係を育むことです。
それを再読した後、私は「3の法則」の元の前提は、実際には、他の誰もそれに不満を言っていない場合、あなたの意見は重要ではないということではないと強く主張します。
その核心は、（特にリソースが限られているチームの場合）人々が最も不満に思っていることを見つけることは、ユーザーを最も悩ませている問題を見つける効率的な方法であるということです。そうすれば、それらを最初に修正できます。
Steve KrugがDon’t Make Me Thinkで述べているように：
修正するためのリソースよりも多くの問題を見つけることになるので、最も深刻な問題から修正することに集中することが非常に重要です。そして、3人のユーザーは、テストしているタスクに関連する最も重要な問題の多くに遭遇する可能性が非常に高いです。
したがって、他の多くの人が同じことについて不満を言っていないからといって、それが重要ではないということにはなりません。Discourseチームが現在のユーザーの主要な/マイナーなペインポイントを検討する際に、より多くのデータポイントは依然として役立ちます。
実装しなくても、人々のフィードバックに感謝することは可能
第三に、すべての提案を実装できない場合や、実装しないと決定した場合でも、人々のフィードバックに感謝することは可能です。
ゲームデザインを学んだ後、このようにフィードバックを処理することに慣れました。そこでは、フィードバックの提供と受信がプロセスの大部分を占めていました。各ゲームレベル、デザインドキュメントなどのイテレーションで、少なくとも3人の他の人の作品にフィードバックを提供し、少なくとも3人からフィードバックを受け取りました。私はしばしば、他の人が欠席したり、課題の提出が遅れたりした場合に備えて、4人または5人の人々にフィードバックを提供しようとしました。
しばしば、人々のフィードバックは非常に洞察力があり役立ちますが、10以上の重要なポイントがあり、現在、実装する時間があるのは1〜3個だけです。
これは、私がプロのソフトウェアエンジニアとして、小規模なスタートアップでコミュニティと頻繁にやり取りしていたときにも同様でした。10以上の重要なバグレポートがあるかもしれませんが、次のアップデートでは、それらのうち1〜3個を修正する時間があります。
いずれにせよ、私は人々の観察に感謝し、彼らの考えを共有してくれたことに感謝し、バグの再現手順を記述する時間を作ってくれたことに感謝し、ご迷惑をおかけしたことをお詫びする義務を非常に強く感じています。
ほとんどの場合、ユーザー/プレイヤーは、本当に迷惑でない限り何も言いません。したがって、書かれたフィードバック/機能リクエスト/バグレポートのほとんどは、何かについて自分の考えを共有するために時間を割いた人からのものです。他の多くの人が考えたかもしれないが、まだ特定したり言及したりしなかったこと、おそらくあなたが見逃したものなどです。
したがって、誰もが言うことをすべて実装できない場合（これは90％の時間かもしれません）でも、そのすべてのフィードバックに飛びついてそれを押し下げる必要はありません。フィードバックは、たとえ現時点でそれに対応するリソースがなくても、またはそれに対応しないと決定した場合でも、依然として重要です。
とにかく、だからこそ、私たちコミュニティメンバーは、他の新しい人々が自分の考えを共有できるようにし、すぐに彼らの提案を却下しないことが価値があると思います。これは、Discourseチームの機能に関する立場が時間とともに変化する可能性があり、フィードバックはDiscourseチームにとって依然としてデータポイントとして役立つからです。たとえ現時点で実装されないとしても。