Proposed process for experimental extensions

Change-Id: Ica904510a1dc3a5b8ebe180817aa44538cf1b012
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/49303
Reviewed-by: Ben Clayton <bclayton@google.com>
Commit-Queue: Ben Clayton <bclayton@google.com>
Auto-Submit: David Neto <dneto@google.com>

README.md

diff --git a/README.md b/README.md
index 047a87c..c632356 100644
--- a/README.md
+++ b/README.md
@@ -102,3 +102,5 @@
 ## Contributing
 Please see the CONTRIBUTING and CODE_OF_CONDUCT files on how to contribute to
 Tint.
+
+Tint has a process for supporting [experimental extensions](docs/experimental_extensions.md).

docs/experimental_extensions.md

diff --git a/docs/experimental_extensions.md b/docs/experimental_extensions.md
new file mode 100644
index 0000000..8fccd13
--- /dev/null
+++ b/docs/experimental_extensions.md
@@ -0,0 +1,44 @@
+# Experimental extensions
+
+Sometimes a language feature proposed for WGSL requires experiementation
+to prove its worth.  Tint needs to support these, in general to enable
+that experimentation.
+
+The steps for doing so are:
+
+1. Choose a name for the feature, to be used in an `enable` directive.
+   An experimental extension should use prefix of `google_experimental_`
+   Example:
+
+      enable google_experimental_f16;
+
+2. Write down what the feature is supposed to mean.
+   This informs the Tint implementation, and tells shader authors what
+   has changed.
+   Ideally, this will take the form of one of the following:
+
+   - A PR against the WGSL spec.
+
+   - A description of what the contents of that PR would be, committed
+     as a document in this Tint repository.
+
+3. File a tracking bug for adding the feature.
+   Note: Should the Tint repo have a label for experimental features?
+
+4. File a tracking bug for removing the feature or converting it to
+   non-experimental.
+
+5. Write a plan for removal of the experiment.
+   - Ideally, this plan is committed to this repository, especially the
+     description of public activities and commitments. However, we recognize
+     that some internal goals or metrics may be sensitive, and can be hidden.
+   - The plan is about process, not technical details.  It should include:
+       - Who is the point of contact for this feature? The point of contact
+         is responsible when the feature causes an issue or gets in the way.
+       - What is your target date for declaring the experiment a success or
+         failure. In Chrome an experiment must be shipped or removed, in
+         finite time.
+       - What experience are you hoping to gain?  Do you have target metrics?
+       - What approvals, if any, do you need from W3C? What is your plan to
+         present your case to W3C?
+       - The bug tracking removal of the experiment.