Explainers should be written for a general audience

[alice]

Just as an example of a widespread issue, the WebXR Anchors Module explainer has several obscure terms of art in the opening summary. This is not approachable for an audience unfamiliar with XR, and means the reader has to do more work to understand.

Also, Explainers should not be written with just the TAG in mind as an audience, but be assumed to be eventually used by developers to understand the API in context.

How can we improve this situation from our end?

[alice]

Our "touch points" are the design review issue template and, by extension, the Explainer Explainer (in particular the preamble before the template).

Both of these need to be kept as brief as possible, so that there is a chance people will actually read them.

Are there any other opportunities for influencing Explainer authoring?