完全に理解できます。[1] 私は Discourse が本当に気に入っていますし、この投稿を書いたのは Discourse が今後も成功し続けてほしいからです。
私が学んだことは、コミュニティは変化を好まないが、自分が主体性を持っていると感じれば、変化に対してはるかにオープンになるということです。人々に主体性を与える方法は無数にあります。例えば、チュートリアルをウィキ投稿に変更すれば、私のような人々が更新できるようになります。ESR（長期サポート）計画の実装も役立ちます。なぜなら、すぐに変更を加えない選択肢を提供するからです。[2] また、私の経験をまとめて、オープンソースプロジェクトを管理する人々に見てもらうことも役立ちます。特に、私が不満を言った問題が一夜で解決されたからです。
「ユーザーの意見聴取は有害か？」[3] で Kathy Sierra はこう書きました：
多くの人が、フォーカスグループが多くの点で極めて非効率的であることを理解していますが、それでもなお、実在するユーザーからの実際のフィードバックを聴くことが、新製品やサービスの開発、および既存のものの改善にとって最善の方法だと想定しています。しかし、そこには大きな問題があります。それは、_人々は自分が思いもよらなかったものをどうやって求めるべきか、必ずしも知らない！_ということです。ほとんどの人は、既存のものを見て、それをどう改善できるかを考えるだけで、完全に_漸進的_な改善に基づいて提案を行います。しかし、それは全く新しいものに対するビジョンを持つこととは大きく異なります。
真の革新は、ユーザーが_直接的に_言うことからほとんど生まれません。
私が言ったように、私はフロントエンド開発者ではありません。なぜこれらの変更が行われたのか、それが私にどう恩恵をもたらすのか、よくわかりません。[4] それでも、最終的に Discourse をより良くするのであれば、それは問題ありません。
それでも、ビジョンをもう少し明確に理解できれば、私のような人々も納得しやすくなります。この変更について、提案内容は以下の通りです：
- より優れた開発体験
- Discourse の将来のバージョンで大幅なパフォーマンス向上が可能になる
まあ、良さそうですか？私は特に #1 を感じ取れませんでしたし、#2 は多くのことを意味する可能性があります。私にとってより効果的なのは、以下のような説明です（もちろん、これは私が勝手に作った例です）：
- 公式の Discourse プラグインを移行した際、コード行数が X%削減されました。テンプレートを JavaScript と同じファイルに配置することで、将来のコードの理解と修正が容易になります。
- Handlebars を完全に削除するテストブランチを設けたところ、ページ読み込みが X%速くなることが判明しました。それだけでなく、[ユーザーが提起したある問題] を解消できる可能性のある最適化も見つかりました。
専門家ではない人々を教育する視点で少し詳しく説明することは、信頼を維持するために非常に役立ちます。私は変更を好まないかもしれませんが、他のユーザーが直面した実際の問題を解決することに対して、どう反論できるでしょうか？
OpenSSL も同様の構造を持っています。サポート契約を販売するコーポレーション（約 15 名）と、非営利の利益を管理する財団（私を含む 10 名）があります。私たちのドキュメントも遅れがちです。元の投稿を書いている最中に、先月に削除された機能への参照がまだ残っていることに気づきました。そのための PR を作成中です。また、ダウンストリームのプロジェクトから強く批判された変更もいくつか行いました。 ↩︎
プラグイン作成者にはあまり役立たないかもしれません。彼らは最先端のバージョンを維持したいコミュニティをサポートしたいと考えているためです。しかし、私にとっては素晴らしいことです。私のプラグインを使っているのは私だけだと信じているからです。 ↩︎
大枠の視点では、私がそれほど重要ではないのかもしれません。しかし、私は Discourse に依存している他の人々の代弁者としての「私」について話しています。結局のところ、私自身を最もよく知っているのは私自身です！ ↩︎