CLDR-18227 Add definitions for Tech Preview and Final Candidate

CLDR-18227

Add definitions for Tech Preview and Final Candidate

See #4281

Author: AEApple

docs/site/index/process.md

@@ -8,7 +8,7 @@ title: CLDR Process
 
 This document describes the Unicode CLDR Technical Committee's process for data collection, resolution, public feedback and release.
 
-- The process is designed to be light-weight; in particular, the meetings are frequent, short, and informal. Most of the work is by email or phone, with a database recording requested changes (See [Requesting Changes](/requesting_changes)).
+- The process is designed to be light-weight; in particular, the meetings are frequent, short, and informal. Most of the work is by email or virtual meeting, with a database recording requested changes (See [Requesting Changes](/requesting_changes)).
 - When gathering data for a region and language, it is important to have multiple sources for that data to produce the most commonly used data. The initial versions of the data were based on best available sources, and updates with new and improvements are released twice a year with work by contributors inside and outside of the Unicode Consortium.
 - It is important to note that CLDR is a Repository, not a Registration. That is, contributors should NOT expect that their suggestions will simply be adopted into the repository; instead, it will be vetted by other contributors.
 - The [CLDR Survey Tool](https://st.unicode.org) is the main channel for collecting data, and bug/feature requests are tracked in a database ([file a ticket](/requesting_changes#how-to-file-a-ticket)).
@@ -24,7 +24,12 @@ The [UTS #35: Locale Data Markup Language (LDML)](https://www.unicode.org/report
 
 - Requests for changes are entered in the bug/feature request database ([file a ticket](/requesting_changes#how-to-file-a-ticket)).
 - Structural changes are always backwards-compatible. That is, previous files will continue to work. Deprecated elements remain, although their usage is strongly discouraged.
-- There is a standing policy for structural changes that require non-trivial code for proper implementation, such as time zone fallback or alias mechanisms. These require design discussions in the Technical Committee that demonstrates correct function according to the proposed specification.
+- There is a standing policy for structural changes that require non-trivial code for proper implementation, such as time zone fallback or alias mechanisms. These require design discussions in the [CLDR Design Working Group](https://cldr.unicode.org/cldr-tc/design-wg) and approval by the [CLDR Technical Committee](https://cldr.unicode.org/cldr-tc) that demonstrates correct function according to the proposed specification.
+- New sections may be added to the specification in Technical Preview, Final Candidate depending on how finalized the new section is, what type of feedback the Technical Committee requires, and whether the feedback period needs to extend across one or more releases.
+    - **Technical Preview** - Specification section have been approved by the CLDR Technical Committee and open for feedback. New features may be modified or removed similar to elements marked with [@TECHPREVIEW in the DTD as described in the LDML](https://www.unicode.org/reports/tr35/#dtd-annotations).
+    - **Final Candidate** - A Final Candidate is a version of a new section of the specification that is considered ready for release, and is expected to become stable in the next release. An optional Final Candidate stage follows a period of feedback in Technical Preview stage for one or more releases where additional feedback is still desired. Changes will only be made if serious issues are discovered during this feedback period.
+
+
 
 ## Data- Submission and Vetting