以下は、2009年12月25日に書かれた WordPress.org 公式ブログの記事、「Setting Scope」を訳したものです。リンク先は英語ページです。
先日行ったコアコミッターのミーティングで話し合った話題の一つに、リリース要件定義（およびその変更、「スコープクリープ」）がありました。現在 WordPress は 2.9 のリリースが済んで、3.0 について考え始める時期に入っています。そこで、一気に取りかかる代わりにここで立ち止まって一息つき、事前計画を立てるのが良いのではないかと思っています。今までの場合、各リリースサイクルの間にいくつか新機能を含める選択をした後も、機能フリーズ（またはベータサイクル）の直前まで機能リクエスト、改善用パッチ、継続的なバグリポートが投稿され続けていました。これにより各リリースを計画よりも遅く公開することになり、あまりにもたくさんのことが起こっているため、新しいバグをとらえるのがどんどん難しくなってしまっていました。
このようにフリーズぎりぎりまで色々と追加していく形態は、うまく機能しているとは言えません。メイン機能以外に色々と変更を加えたり、変更をすべてテストする必要があることで、ゴミ箱や画像編集などの新機能が導入されるまでに何ヶ月も余分に待つことになってしまいました。もしリリースごとに含める機能を少なくすれば、新機能をもっとすばやく取り入られるようになるはずです（ゴールは年3回のリリースです）。また、より集中的なベータテストを行うことでリリースをさらに完全なものにできるはずです。
これは簡単なことではありません。皆さんそれぞれお気に入りの機能や修正して欲しいバグがありますし、パッチがあるなら次のリリースを待つよりも今回含めてしまえばいいのに、という考えもあるからです。しかし「パッチが数週間や数ヶ月もコミットされないままだ」という不満を聞くことはあっても、「パッチが新規のバグを引き起こすこともある」という声は耳にしません。また、同時にいくつものパッチを追加することで、様々なプラットフォームの異なるホスティング環境などでのテストを完全に行うのがより難しくなっていきます。そこで、この問題に対する私たちの提案は以下の通りです。
プロジェクトマネジメント界の先例に従い、開発サイクルをスタートする前にプロジェクト計画を立てます。皆さんに機能や改善点を提案してもらい、限定したものを 3.0 に含めます（今回は特に厳しい制限が必要になります。WordPress と WordPress MU の統合は、それだけでかなりの作業量になるからです）。その後、現実的なリリース日を設定し、それまでに必ずリリースを行います。今後2つのリリースに対して暫定的な機能セットを決定し、次回のサイクルの最初に再度評価することで、現在次バージョン以外のチケットすべてにつけている曖昧な「future release（将来のリリース）」ラベルとは異なり、コミュニティとして特定の機能にコミットしていることが皆さんに分かるようになります。
また、ごく一部のケースで発生するバグや、説明不十分だったり再現できないバグにフォーカスする前に、再現性があり多くのユーザーに影響があるバグを修正します。誰かがごねて別の方向性を示したからからといって、みんなで合意したゴールから注意をそらすようなことがないようにします。もちろん、不意に予想しない事態が発生することもあるでしょう。しかし、次回のリリースに予定していなかった変更を滑り込ませないように、私たちはもっと努力しなくてはなりません（もちろん、私自身にも罪はあります… ユーザーエクスペリエンスに関わる一人として、すべてを一度に改善できればいいのにといつも思ってしまうんです！）。
オープンソースプロジェクトとしては、みんながそれぞれ独自の方針に従うよりも、一緒に動いた方がたくさんのことを成し遂げることができます。私たちは一般的かつ合意済みのゴールにフォーカスした状態を保ち、コミュニティのメンバーがプロジェクトを関係ない方向へ誘導していくことを避けなくてはなりません。その方向が、誰もが好むすばらしいアイディアであろうと、個人的な方針に基づいた提案であろうと関係ありません。また、よく状況を知らない新米ユーザーによる意見か、説得力があって声高な貢献者やコミッターからの意見かというのも関係ないのです。問題は、ゴールへのフォーカスを保つのが簡単ではないということです。だからこそ、脱線せずに前に進んでいくことができるシステムを構築していく必要があります。例えば Trac で現在の開発サイクルで確定した機能やバグリポート以外のチケットを除外し、新機能や提案は他のマイルストーンに切り分けるといったことです。
私たちは、こういったこと試すだけの価値はあると思っています。2010年に IRC の開発チャットを再開する際、最初に話し合うのは 3.0 の要件定義です。含める内容についてだいたいの合意が得られたら、適切な Trac チケットを作成し、3.0 向けではない機能リクエスト/改善についてのチケットは将来のリリースへ回します。こうすることで、3.0 の開発に集中できます。現在のマイルストーンに対するバグリポートは引き続き投稿されるはずなので、簡単ではありません。コアに含めたいと思っていながら過去に何度も先延ばしにした機能が最低でも10数個はありますが、今回の試みのためには「プラグインで実現できる」というふうに考え、コアに含めるものは最低限に抑えるよう努力したいと思います。