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>
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).
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.
