feat: Expand migration requirements in template.

At Matt Powers' recommendation, this amends the "Compatibility and
Migration" section of the RFD template to describe expectations for
analyzing and planning migrations more clearly, including specific
questions which ought to be answered, and clarifying the limits of
SchemaVer in expressing the adoption burden of new features.

Signed-off-by: Andrew Lilley Brinker <abrinker@mitre.org>

Author: alilleybrinker

rfds/_TEMPLATE.md

@@ -87,6 +87,27 @@ Also describe any migration paths required of CVE stakeholders, including any
 requirement to transition from a prior structure in the schema to a new
 structure, or to comply with stricter data quality constraints.
 
+Some of the following questions may be important to answer, depending on the
+scale of the changes proposed in an RFD:
+
+- How long should the proposed change be communicated to CVE stakeholders in
+  advance of being rolled out in CVE Services?
+- What types of testing are necessary before the change is rolled out into
+  production? (This testing may also be part of the Success Metrics and
+  rollback criteria.)
+
+While SchemaVer's compatibility rules only consider the impact of a change on
+the ability of users of a schema to interact with _historic_ data, any change
+to the schema which adds new capabilities places a demand on CVE stakeholders
+to adapt. For CNAs and ADPs this may mean updating their integrations with
+CVE Services to provide data in new fields, while for CVE consumers it may
+require amending their CVE record parsing to make use of new data or be able to
+parse new records.
+
+This fact, that `ADDITION`-level changes still create work for CVE stakeholders,
+should never be used as a sole reason to reject a proposed RFD, but it should
+strongly inform any roll out plan for changes.
+
 ## Success Metrics
 [success-metrics]: #success-metrics