[SYCL][DOC] Describe process of prototyping KHR extensions

sycl/doc/developer/KHRExtensions.md

@@ -0,0 +1,48 @@
+# Considerations for working on KHR extensions
+
+SYCL specification evolves through embedding extensions developed by various
+vendors, including Khronos Group itself (`khr` extensions).
+
+In order for a KHR extension to be accepted, there must be CTS tests for it and
+at least one implementation which passes them.
+
+Considering that KHR extensions are being developed in public, we can start
+prototyping them as soon as corresponding PR for an extension is published at
+KhronosGroup/SYCL-Docs.
+
+However, we shouldn't be exposing those extensions to end users until the
+extension if finalised, ratified and published by Khronos - due to risk of an
+extension changing during that process and lack of the officially published
+version of it.
+
+So, we can have a PR but can't merge it. Keeping PRs opened for a long time is a
+bad practice, because they tend to get stale: there are merge conflicts,
+potential functional issues due to the codebase changes, etc.
+
+In order for us to avoid stale PRs, all functionality which is a public
+interface of an "in-progress" KHR extension, must be hidden under
+`__DPCPP_ENABLE_UNFINISHED_KHR_EXTENSIONS` macro. That way we can merge a PR to
+avoid constantly maintaining it in a good shape, start automatically testing it
+but at the same time avoid exposing incomplete and/or undocumented feature to
+end users just yet.
+
+"in-progress" KHR extension term used above is defined as:
+- PR proposing a KHR extension has not been merged/cherry-picked to `sycl-2020`
+  branch of KhronosGroup/SYCL-Docs.
+
+  That only happens after all formal processes on Khronos Group side are
+  completed so an extension can be considered good and stable to be released by
+  us.
+
+  Note: merge of an extension proposal PR into `main` branch of
+  KhronosGroup/SYCL-Docs repo is **not** enough.
+- Published (i.e. the above bullet complete) KHR extension, which hasn't been
+  fully implemented by us
+
+The macro is **not** intended to be used by end users and its purpose is to
+simplify our development process by allowing us to merge implementation (full
+or partial) of the aforementioned extensions earlier to simplify maintenance and
+enable automated testing.
+
+Due to this reason, we are not providing a separate macro for each "in-progress"
+KHR extension we may (partially) support, but just a single guard.

sycl/doc/index.rst

@@ -66,3 +66,4 @@ Developer Documentation
    developer/DockerBKMs
    developer/ABIPolicyGuide
    developer/ContributeToDPCPP
+   developer/KHRExtensions