@Kangz This PR makes the change we discussed last Tuesday.

Several of the proposal files have out-of-date headers, but that's a pre-existing problem; if it's all right, I would like to keep this PR limited to just moving files around.

Previews, as seen when thisbuild job started (d5e0bbd):
WebGPU_{webgpu.idl |Explainer |Correspondence Reference}
WGSL_{grammar.js |wgsl.lalr.txt}

One potential point of discussion: we have several proposals that have been accepted, but are waiting for CTS and implementation revisions and thus have not yet been merged into the main spec. This PR moves those intoproposals/accepted. One might argue that proposals should be moved intoaccepted only when the main spec text is updated.

I made the change here because the committee has agreed to accept the proposals, so the file's location reflects the plain meaning of the term.

Moving proposals to accepted / inactive sounds good! However for proposals that accepted but yet to be merged in the spec IMHO it would be better to keep them active. For example as we're implementing immediates, we keep finding tiny points of discussion (the latest one is#5473) and moving them toaccepted would make them seem like they are done and won't change, which isn't the case. (maybeaccepted should bemerged-in-spec? I couldn't come up with a better name just now)

I'd be in favor of not moving proposals in dedicated folders as it means links shared during implementation will become dead. Seehttps://groups.google.com/a/chromium.org/g/blink-dev/search?q=main%2Fproposals%20webgpu for instance.

A "simple" status/roadmap update in each proposal would be better in my opinion.

I think we should try to use permalinks to proposals in those situations in the future, but there is still value in having semi-permanent links to the latest version too.

#5385 tracks updating the roadmaps - I think now that we have a lot of proposal docs, I want to have a list of standard statuses and have them link to a status.

Itis annoying to have a folder full of proposals with no filtering. Once we have standard statuses, we could generate an index (either aproposals/README.md in the repo that is checked to be up to date, or a page athttps://gpuweb.github.io/gpuweb/proposals/ with a generated index). What do folks think of that?

It is annoying to have a folder full of proposals with no filtering.

This is my concern. I'm not at all wedded to the approach taken by this PR.

Instead of generating indices, could we just do a combination of both? Keep the approach here which moves proposals intoaccepted/,inactive/ (and should we have arejected/?) but also create stub files in this folder which just contain something like:

This proposal has been {accepted, rejected, deferred} and the original proposal moved to [new path](new path).

Then, folks can quickly see what's accepted, inactive, rejected but also links don't all get broken?

@dj2's proposal would still break fragment identifier links BUT it would be a good compromise.