（この記事は長いので前半と後半に分けました）
Drupal 8 フィーチャー フリーズ後の段階に入った今、僕たちは Drupal 7 フィーチャー フリーズのあとと同じような状態にある。つまり、次のようなものだ。
- いくつかのイニシアチブは（タスクを）ほとんど完了し、現在はクリーンアップに取りかかるところ。
- 他のイニシアチブはアーキテクチャー的にはほとんど出来上がってきているが、まだ大きく欠けているところがいくつもある。
- さらに他のイニシアチブはアーキテクチャー的にまだ完成していない。あるいは「統合/変換（書き換え）の作業が大量に残っている」、「際立った重大/重要なバグがたくさんある」のどちらか、または両方だ。
ここから先、僕たちは、どのパッチを Drupal コアに直接入れるかという点について、もっと戦略的になる必要がある。つまり、ハードな決断を下さなくてはならないということだ。コミットするパッチのどれひとつとして Drupal 8 を「出荷可能な状態」から遠ざけてはならない（リリースできる状態に近づけることはあっても遠ざけることは許されない）。
（タスクが）未完了のイニシアチブ（公式、非公式とも）には基本的に 2 つのカテゴリーがある：
- コードが既に HEAD に入っていて、（それを）元に戻す予定はなく、それ（その機能）が完成することが Drupal 8 のリリースにとって重大であるもの。この例は CMI、Entity NG、Router（といった要素）の変換（書き換え）作業だ。これらのイシューに対してパッチのコミットを重ねていくことは、Drupal をリリースに向かって進めていくことになる。
- コードが現在、HEAD に入っていない。または、ライブラリーが Drupal 内の他の部分によって実質的に使用されていない。この例としては Twig、CSS 再構成（CSS re-organization）、そして SCOTCH の一部が挙げられる。これらのイシューに対してパッチのコミットを重ねていくことは、Drupal を「未知の領域」へと連れて行き、リリースをリスクにさらす可能性がある。
というわけで、Drupal 8 が前進するためにコミットするものの是非を決める場合、コア コミッターたちは以下の戦略（決定プロセス）をとる予定でいる。
ひとつのパッチがある場合、まず「そのパッチがより大きな『メタ』イシューに属するか」という点を評価（チェック）する。Drupal 8 のキュー内にある大多数のイシューにとって、その答えは「ノー」だろう。たとえば、ルーチンのバグ フィックスや自己完結型の DX（デベロッパー エクスペリエンス）改良なら、できたところでそのままコミットできる。
あるイシューがより大きなメタ イシューの一部である場合、「このメタ イシューは Drupal 8 のリリースにとって重大か」という点が問題になる。それが「イエス」の場合、「これは僕たちをリリースに近づけることになるか」という問い（条件）が満たされる。よって、そうしたパッチはできあがり次第、コミットされることになるだろう。この例としては個別の CMI 変換が挙げられる。設定マネージメント システム内のどこでも CMI のすべての部分を利用できるようにしないかぎり、Drupal 8 は出荷できない。同様に、やり方を宣言する方法が二つあるものを出荷することもできない。