@litherum Any feedback on "process", e.g. whether this is an appropriate place for documents like this to live?

Previews, as seen when this build job started (039cbd8):
WebGPU | IDL
WGSL
Explainer

I'm not sure, but I believe in order to publish new documents on the W3C's recommendation track, we'd have to amend our charter. Because of that, I'd recommend, instead, marking everything in this directory as non-normative proposals, as a kind of staging ground for extensions on their way to the main spec.

Updated with something along the lines I was proposing in the last meeting: an explicit explanation of the expected future of the extension.

Updated the README to reflect the fact that this could be used for larger standards-track features.

WDYT? @jdashg @litherum

Previews, as seen when this build job started (44378ce):
WebGPU | IDL
WGSL
Explainer

@jdashg brought up some (completely reasonable) concerns during the last call about intentionality. If everyone agrees a particular proposal will never end up in the main spec, what business does it have being in this repository?

Our team generally dislikes it when legitimate proposals are made in random personal repos, so, for legitimate proposals, we'd prefer they exist here, in this repo.

So, given both of these thoughts, I think there's a path forward: this new directory is for proposals on their way to the main spec. If a proposal is rejected, it would be deleted from this folder.

Under this criteria criterion, I believe pipeline statistics queries would belong in this folder, but fine-grained timestamp queries (as they do/will exist in Chrome behind a flag) would not belong in this folder. Chrome would host their chrome-specific extension spec themselves.

We have explainers folder here, which also is never expected to become a part of the spec.
I.e. not everything in the repo is a part of the spec. We can agree to store things here that all parties wish to collaborate on, and which are highly related to the spec, can we?

Our team generally dislikes it when legitimate proposals are made in random personal repos, so, for legitimate proposals, we'd prefer they exist here, in this repo.

I agree with this, but would apply it to a broader set of documents like Dzmitry proposed. (I think design/ is the most similar folder.)

Under this criteria criterion, I believe pipeline statistics queries would belong in this folder

The "roadmap" I wrote for pipeline statistics indicates it is not on its way to the main spec:

"Roadmap: This draft extension is not on the standards track. It is currently intended to be used only in non-Web-compliant contexts, such as by Web developers who enable a command line flag or other non-default option in order to profile the performance of their application."

I would prefer to put the in-pass timestamp extension document here too, with a similar roadmap.

@litherum @jdashg Possible to get feedback on this latest PR to have a very explicit "Roadmap" for each extension document?

@litherum @kdashg post-holiday bump (and also because this topic came up in yesterday's meeting) :)

We are a standards body. I don't think we should be hosting documents that are not on the standards track. They are not a part of WebGPU.

See: https://github.com/webgpu-native/webgpu-headers

For info, some groups actually do that, especially for extensions that could perhaps get folded into the main spec later on. One example is the WebRTC Working Group, which maintains the WebRTC Extensions and Media Capture and Streams Extensions, neither of which are published on the standards track, but both of which may end up being integrated in the revelant underlying specs. From a process perspective

@litherum, @Kangz, and @toji as editor, please review. Hopefully this is the language we can finally agree on!

I've tweaked the language a bit more as I think this matches better what we agreed upon in discussions. @litherum PTAL in particular.

Previews, as seen when this build job started (16af797):
WebGPU _{webgpu.idl | Explainer | Correspondence Reference}
WGSL _{grammar.js | wgsl.lalr.txt}

was only waiting for approval from Apple, and got explicit approval so landing now.