A Change is considered _code complete_ when the bug state is moved to ON_QA and when there are no blocking bugs open.
A contigency plan should include:
A good "how to test" should answer these four questions:
Alignment with Objectives: Does your proposal align with the https://docs.fedoraproject.org/en-US/project/objectives/[current Fedora Objectives]? This will not apply to many Changes, but it's important to consider when proposing a Change. Being out of alignment isn't an automatic rejection, it's just one more aspect to consider.
A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. Note that motivation for the change should be in the Motivation section below, and this part should answer the question "What?" rather than "Why?".
Assume that not everyone who sees this will know what you're talking about. Give a brief description of packages or services where it makes sense.
Benefit to Fedora
Be sure to include the following areas if relevant:
Change Proposal Name
Change submission guidance
Changes which cannot be completed for the release are automatically deferred to the next release. You do not need to re-propose the Change unless you are making substantional revisions to it. If you need to defer a change, let the Program Manager know and they will update the wiki page and the Bugzilla tracker appropriately.
Contingency deadline: When is the last time the contingency mechanism can be put in place?
Contingency mechanism: (What to do? Who will do it?)
Contingency Plan
Current status
Describe what Users will see or notice, for example:
Detailed Description
Does this improve some specific package or set of packages? For example: This change modifies a package to use a different language stack that reduces install size by removing dependencies.