メンテナーを解放しよう

重要：この情報は現在古くなっています。最新の詳細については、新しいブログ記事を確認してください。

---

TL;DR; ここ数か月かけて、ボランティアの仕組みを再設計し、主要なボランティアの方々をコミュニティからのコントリビューションをレビューする作業から少し休ませることにしました。 Exercismを純粋に学習やメンタリングのために使っている方には、ここに知っておく必要のあることは何もありません（ただ、興味があればぜひ読んでください！）。 トラックのメンテナーである方、Exercismに貢献したい方、バグや問題を報告したい方は、これを必読だと考えてください 🙂

---

この6か月間、Exercismの未来について多くの時間をかけて考え、すべての言語トラックが最高のかたちになるとはどういうことかを思い描いてきました。 これまでに築いてきたことを、とても誇りに思っています。 寄せられた85,000件の体験談は、言語トラックを築き、それを通じて多くの学習者をメンタリングしてきたコミュニティの素晴らしい仕事ぶりを物語っています。 何よりも、まだ可能性の表面をなぞり始めたにすぎないと信じています。 Exercismがどんなものになり得るかについて、大きなアイデアと希望、そしてわくわくする気持ちを持っています。 しかしそれを実現するには、まず表面下に残っているいくつかの根本的な問題を解決する必要があります。

その中でも最も重要なのは、ボランティアコミュニティを健全で持続可能なかたちで拡大していくという課題を解決することです。 Exercismは何百人もの献身的なボランティアの肩の上に築かれてきましたが、その多くが今、燃え尽きを感じており、結果として多くの人が離れていきました。 理由は数え切れないほどあります。Exercismに直接関係するものもあれば、生活の時間的なプレッシャーによるものもあり、今の世界情勢という背景によるものもあります。 しかし、プラットフォームをともによりよく築いていく方法を設計・開発する必要があることは、はっきりとわかっています。

これまでExercismは、広くコミュニティからのコントリビューションをレビューするメンテナーを置くという、オープンソースソフトウェア（OSS）のモデルで築こうとしてきました。 これは多くの問題を引き起こし、メンテナーとコントリビューターの双方にフラストレーションをもたらしました。 詳しく知りたい方は、このあとさらに掘り下げますが、要するに、主要なボランティアが今や、革新的な作り手ではなく、受け身の門番として時間を使うようになっています。 それは彼らにとってずっと楽しくないことであり、これまでそうした人たちがプラットフォームにもたらしてきた魔法をExercismが失うことを意味します。

これを解決するために、やるべきことが2つあります:

1. 従来のOSSモデルよりもExercismに適した、新しいボランティアの仕組みを設計する必要があります。 これまでもかなりのエネルギーをかけて取り組んできましたが、うまくいきませんでした。 そこで、これから数か月かけて、ボランティアとともにこれをきちんと設計するための時間を取ります。
2. これから数か月、広くコミュニティからのコントリビューションをほぼ停止し、主要なボランティアが自分たちの望むやり方でトラックの構築と開発に集中できるようにします（あるいは、ただ一息つきたいだけなら休暇を取ることもできます！）。

私の願いは、一歩引いてこれをしっかり設計し、教育チームを広げるための資金調達とあわせて進めることで、Exercismをボランティアにとって素晴らしい場所にし、その未来を確かなものにすることです。 それまでの間、これらの変更によって、トラックはこの1年でできた以上に改善・成長でき、メンテナーは燃え尽きるのをやめ、むしろExercismで作業することから、より幸せで、より活力にあふれ、よりつながりを感じられるようになるはずです。

具体的な変更

具体的に実施する変更は3つあります。

GitHub Issuesではなく、フォーラムを使いましょう

GitHubは、メンテナーが取り組みたいIssueに取り組めるよう、全面的に空けることにします。 これまでコミュニティに取り組んでもらうために作った数多くのIssueをクローズします（将来必要になれば簡単に再オープンできるよう、タグも付けます）。同時に、ほとんどのリポジトリでは、新たな、こちらが求めていないIssueやPRの作成を許可しません。 何かを話し合いたい、あるいは報告したい場合は、代わりにフォーラムを使ってください。 求められていないIssueやPRを開いた場合、自動的にクローズされ、フォーラムを案内されます。

広くコミュニティからのコントリビューションを停止する

トラックは3つのカテゴリーに分かれます:

• アクティブなメンテナーがいる大多数のトラックでは、メンテナーが自律的に動けるように、あるいは休みを取れるように、コミュニティからのコントリビューションを停止します。 （これらのトラックのメンテナーは、必須の1回レビュー要件の撤廃を申請できます。 これについてはSlackでErikに話してください）
• アクティブなメンテナーがいて、積極的にコミュニティからのコントリビューションを受け入れ続けたいと考えている一部のトラックは、開いたままにします（メンテナーで、(1)よりもこのモードを選びたい場合は、SlackでJonathan Middletonに連絡して相談してください）。
• アクティブなメンテナーがいないトラックでは、この期間、トラックの開発は実質的に停止します。

いずれの場合も、Erikと私は、ToolingリポジトリへのPRをマージ前に引き続き内容を確認します。

唯一の例外は、ApproachesとArticlesへのPRは引き続き受け入れ、組織全体で楽観的マージの方針を導入するということです。これはExercism全体にApproachesのベースラインを整え、段階的な改善を可能にすることを目的とし、次のルールに従います:

1. そのコードが演習を解けていて、構文面でも意味面でも慣用的（つまり、$LANGのコードらしく見える）であれば、マージします。 そうでなければ、PRの作者が修正します。
2. メンテナーがコンテンツに変更を加えたい場合（たとえば、アドバイスを改善する、細部を調整する、より良い・別の・より慣用的なアプローチを強調するなど）は、後続のPRで行います。

新しいボランティアの仕組みを設計する

これから先に向けて、Exercismの可能性を解き放つ、持続可能で健全なボランティアの枠組みを一緒に設計するため、コミュニティボードを立ち上げます。 Exercismの未来に本気で取り組み、このプロセスに参加したい方は、Jonathanに連絡してください。

これらの取り組みを、これから数か月間進めます。 その間ずっとすべてを検討し、2023年6月までにいくつかの新しい決定を下す予定です。 意見があれば、フォーラムでトピックを立ててください！

追記：なぜ私たちのOSSモデルは壊れているのか

これまでのモデルは、OSSモデルを中心に築かれてきました。 これは、Exercismに参加してトラックの構築で素晴らしい仕事をし、その後メンテナーの権限を与えられて、より広いユーザー基盤からのコントリビューションを受け入れてトラックを改善できるようになる、というボランティアに依拠してきました。

これは紙の上では素晴らしく見えますが、いくつかの重大な問題があります。 その最も大きな問題は、Exercismに最も多くの魔法を加える人たちが、コミュニティからのコントリビューションへの対応に時間を取られ、Exercismのコードを書いたり何かを生み出したりする時間がまったくなくなる、ということです。 これは、メンテナーがそもそもExercismに関わるようになった理由とはほとんど無関係であり、彼らが楽しめる仕事でもありません。 これは、開発が好きな人が、コードを書く代わりに人を管理するチームリーダーに「昇進」させられるようなものです。 そのときは良い昇進に見えるかもしれませんが、多くの場合、人はマネージャーであることをコーディングと同じようには楽しめないとわかります。

またこれは、広くコミュニティからのコントリビューションの総和が、あるメンテナーがそれとは別に単独で行えたであろう貢献よりも大きい、という前提にも依拠しています。 しかしExercismでは、それはほとんど当てはまりません。 Exercismは複雑で、教育は難しく、両者が合わさることで、Exercismへの貢献は複雑で難しいものになります。 Exercismが技術的にどう動くか、また教育にどうアプローチしているかについて、学び理解すべきことが山ほどあります。そのため、最初のコントリビューションのほとんどは、人が手探りで進んでいるものです。 つまり、最初の貢献は比較的小さいものですが、同時に、レビューや微調整にほとんどの場合たくさんの手間がかかるということでもあります。 これはメンテナーにとって時間のかかる作業です。 実際、レビューに費やす総時間（および必要なコンテキストの切り替え）を考えると、メンテナーは自分でそのPRを作った場合よりも、レビューにより多くの労力を注ぐことになります。 もちろん例外もありますが、99%のケースでは当てはまります。 しかも多くの場合、PRが解決する問題はメンテナーの優先順位の上位にはありません。そのため、本当に重要だとわかっていることが結果としてなされないことになり、メンテナーにとってはさらに苦しいものになります。

最後に、OSSモデルは、コントリビューターが小さく始めて、やがて知識を身につけ、十分に継続的に関わるようになってメンテナーになれる、という前提に依拠しています。 ソフトウェアライブラリのようなOSSプロジェクトでは、これは比較的うまく機能します（たとえば、ある人が本番環境でライブラリを使い、改良を加え続けて、やがて元の作者と同じくらいの知識を持つようになる、といった具合です）。 しかしExercismでは、それは起こりませんでした。 過去12か月で何千人ものコントリビューターからのPRをマージしてきましたが、その後定期的なコントリビューターになったのはほんの一握りで、メンテナーになった人はさらにわずかです。 これも主にExercismの複雑さによるものですが、このモデルが伝統的に機能してきた、まとまりのあるソフトウェアではないからでもあります。

こうしたことすべては、メンテナーの士気をひどく下げ、Exercismにとって有害です。

トラックは停滞し、構築に情熱を持っていた中核のボランティアは、仕事が他人の成果をレビューし、競合する優先順位を調整し、予期しない依頼に対応することになったことで、その情熱を大きく失いました。 v3の構築中、メンテナーはその作業が主に舞台裏だったため、比較的自律的に働くことができ、それが非常に高い生産性につながり、大半の人が貢献を本当に楽しんでいました。 v3のローンチ以降は、多くのボランティアが同じくらいの時間をExercismに費やしているにもかかわらず、ずっと楽しくなく生産性も低い時期になっています。これは主に、他者のコントリビューションやIssueへの対応にどれだけのエネルギーが注がれてきたかによるものです。 現在のボランティアは、革新的な作り手ではなく受け身の門番として時間を過ごしており、それはずっと楽しくありません。

これらは解決すべき課題であり、どれも難しいものです。 Exercismの言語トラックの構築に何百時間も費やしたい人たちが、それを実行でき、しかも楽しめるようにする方法を見つける必要があります。 バグ修正や小さな貢献が、主要なボランティアの注意を引かずにコードベースに入る方法を見つける必要があります。 また、新しいボランティアをExercismに惹きつけ、継続的な貢献を選んだ場合にはそれを支える方法を見つける必要があります。 一般に門番の役割を減らしつつ、トラックにこれほど尽力してきた人たちが強い、そして非常によく考え抜かれた意見を持っていることも尊重する必要があります。 ボランティアの仕組み全体を管理・運営することを楽しいものにする必要があります。 そして、ほかにも多くのことを解決する必要があります。 時間はかかりますし、難しい挑戦ですが、やり遂げられれば素晴らしいものになります。