How to Write a WebAssembly Proposal in English: Standards Committee Language
A guide to the English language patterns, vocabulary, and document structure used in WebAssembly standards proposals — for engineers contributing to the W3C WebAssembly CG.
Writing for a Standards Committee Is a Specific Skill
Standards documents occupy a unique position in technical writing. They must be precise enough to serve as binding specifications, clear enough to be understood by implementers across multiple languages and runtimes, and persuasive enough to build consensus among people with competing interests and opinions.
The WebAssembly Community Group (CG) and Working Group (WG) follow conventions shared with other W3C and IETF standards bodies. If you are proposing a new WASM feature or amendment, understanding these conventions — and the English register they require — is as important as the technical content.
Standards Document Structure
Most WebAssembly proposals follow a common structure. Each section has its own vocabulary conventions.
1. Overview / Introduction
This section states what the proposal is and why it exists. It should be readable by someone unfamiliar with the motivation.
- Use present tense to describe the current state: “WebAssembly currently lacks a mechanism for…”
- Use future tense or conditional to describe the proposed state: “This proposal introduces… / With this change, programs would be able to…”
- Avoid marketing language. Do not write “a powerful new feature” — write “a mechanism that enables X.”
2. Motivation
The motivation section explains the problem being solved. Strong motivation sections cite real use cases and, where possible, evidence of demand.
| Useful phrases | Usage |
|---|---|
| ”The absence of X forces implementations to…” | Describing the current workaround cost |
| ”This limitation prevents…” | Explaining blocked use cases |
| ”Several implementations have independently arrived at…” | Showing community convergence |
| ”User research indicates that…” | Evidence-based motivation |
3. Proposal
This section contains the normative content — the actual specification change. Its language is highly formalised.
Normative language conventions:
| Term | Meaning |
|---|---|
| ”MUST” | A requirement — non-compliance is an error |
| ”MUST NOT” | A prohibition |
| ”SHOULD” | A recommendation — deviation requires justification |
| ”MAY” | A permitted option |
| ”is defined to be” | Introduces a formal definition |
| ”is well-formed” | Satisfies the structural validity rules |
| ”traps” | Terminates execution with a runtime error |
| ”is implementation-defined” | Behaviour the specification intentionally leaves to implementers |
4. Alternatives Considered
This section demonstrates rigorous thinking and builds committee confidence. For each alternative:
- State what it is: “An alternative approach would be to…”
- State why it was not chosen: “This was rejected because… / This approach would require… / The committee determined that…”
- Use neutral, non-dismissive language even for rejected alternatives: “While this approach has merit, it introduces complexity at the…“
5. Open Questions
Open questions signal intellectual honesty and invite community input.
- Frame each question precisely: “It is unclear whether X should be permitted when Y is also present.”
- Tag questions by who needs to resolve them: “This is a question for the security-focused members of the CG.”
- Distinguish between questions that are blocking and those that can be resolved during implementation.
Standards Committee Register
Standards writing uses a formal, impersonal register that differs from everyday technical writing.
Avoid:
- First person:
“I think this approach is better”→ “This approach is preferred because…” - Informality:
“basically”/“kind of”/“you’d think that…” - Hedging without substance:
“it might potentially be the case that…”→ “There is a risk that…”
Prefer:
- Passive voice for describing specification behaviour: “A trap is signalled when…”
- Active voice for prescribing implementer behaviour: “The runtime must validate…”
- Precise quantification: not “fast” but “linear time in the number of instructions”
Participating in Committee Discussion
In CG meetings and issue threads, certain English patterns recur.
| Situation | Phrase |
|---|---|
| Expressing concern | ”I have a concern about the interaction between this proposal and…” |
| Requesting clarification | ”Could the champion clarify the intended semantics when…” |
| Blocking a proposal | ”I would like to register a formal objection to…” |
| Expressing tentative support | ”I am broadly supportive of the direction, though I would like to see the alternatives section strengthened.” |
| Suggesting a revision | ”Would the authors consider amending the proposal to handle the case where…” |
Example Sentences
- “This proposal introduces a mechanism for structured control flow across module boundaries, addressing a limitation that currently requires unsafe workarounds in compiled language runtimes.”
- “The motivation section should include at least two concrete use cases with evidence of demand from production deployments, rather than hypothetical scenarios.”
- “An alternative using a new instruction opcode was considered but rejected on the grounds that it would require changes to all existing validators without a clear benefit over the type-system approach.”
- “It is an open question whether this feature should be gated on a capability flag or enabled unconditionally; the committee should resolve this before the proposal advances to Phase 3.”
- “When the operand stack is empty and a structured control instruction is encountered, the validator must signal a type error — this is not implementation-defined behaviour.”
Practical Advice for Non-Native Speakers
Standards documents are reviewed by native and non-native English speakers alike. Grammar errors in normative text can create genuine ambiguity — “MAY NOT” and “MUST NOT” have different meanings, and a missing negation can reverse the intended requirement.
Before submitting a proposal, ask a colleague to read the normative sections specifically looking for ambiguity in the modal verbs. This is a common source of revision requests at committee stage.
The Bytecode Alliance and W3C CG both welcome contributors from all linguistic backgrounds. The quality of your technical insight matters more than native-like fluency. Clear, precise, well-structured English is sufficient — and achievable with practice.