（この記事は長いので前半と後半に分けました）
DrupalCon で Drupal 開発者たちと話していてはっきりとわかったのは、Drupal 8 のフィーチャー フリーズとコード フリーズに関する質問がいくつもあるということだ。たとえば、フィーチャー フリーズのあとは何に取り組んだらいいのか、自分の Drupal モジュールを Drupal 8 に移植するのはいつ始めたらいいのか、自分は Drupal 8 のテストをいつ始めたらいいのか、といったものだ。このブログ記事では、これらをはじめとした数々の質問に答えてみよう。
また、それに加えてのお知らせだが、僕は、これまでのアルファおよびベータ リリースの使い方をもっと業界の標準に沿ったかたちに合わせ、コード フリーズの期限を変更することにした。一貫性（全体の統一性）を向上させる作業にもっと余裕を持たせるためだ。あと、貢献（拡張）モジュールの開発者たち/作者たちに対して僕が期待していることも書き記しておきたかった（のでそれも含めてある）。それは、彼らにいつ（行動することを）期待しているのか、何をすることを奨励しているのか、といったことだ。
開発段階の期間（現在から 12 月 1 日まで）
以下は僕たちがまだ開発中である間にすることだ。ここでは新しい機能および API の主な変更のそれぞれに優先順位を付けることを目指す。
- 新しい機能および主な新しい API
- 主な新しい API への初期的な変換：これらの API をサポートするために他の機能や変更を加える必要がないことを確かめる
- 他の機能群に対する障害をなくすために必要なリファクタリング（プログラムの振る舞いを変えることなくソースコードを変更すること）
フィーチャー フリーズ期間（12 月 1 日から 4 月 1 日まで）
フィーチャー フリーズの目的は、既存の機能群の実装を改善すること、特別なケースをなくすことによってコアの統一性および首尾一貫性を改善すること、そして、新しい API などを使うようにコアを変換することによって重複していたやり方を統一することにある。
この段階では新しいサブシステムを加えることを停止する。既存サブシステムのリファクタリングおよびより細かい API 変更ならびに API 補足は次の場合に許可される：既存機能の統一性および首尾一貫性を改善するのに役立つ場合、または特定の重大なタスクまたはバグを解決するために必要である場合。
たとえば、フィーチャー フリーズの期間中であっても以下のことは引き続き歓迎するし、奨励もする。
variable_X()を CMI に変換する作業を完了し、変数システムを削除する- Symfony コンポーネントを使用するため、ページのキャッシングとセッションのハンドリングをリファクタリングすることによってブートストラップ（のプロセス）を最適化および整理する
- フィーチャー フリーズの前に追加された機能群をよりうまく統合する（例：既存のレイアウト UI を既存のコンテクスト認識型ブロックで、または EntityFieldQuery を使って Views で統合する）
アルファ リリースはフィーチャー フリーズ期間中に出し始める予定だ。貢献プロジェクトの作者のうち、コア API が自分のプロジェクトをよりうまくサポートするよう改良に協力したい人は、これらのアルファ リリースを使って自分のモジュール、テーマ、ディストリビューションの移行を始めることができる。コア開発者たちはコア API をどういう風に合理化すればいいのかという点について（この期間に）貢献プロジェクトの作者たちからのフィードバック（意見、感想）や提案を求める。