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.
Bridging the Gap: Precision for Non-Native Speakers
Writing a WebAssembly proposal to the W3C’s WebAssembly Community Group (W3C Wasm CG) demands not just technical expertise, but also a very specific kind of written communication. The goal is clarity, conciseness, and a formal tone that reflects the collaborative nature of standards development. For developers whose first language isn’t English, navigating this landscape can be particularly challenging. It’s easy to fall into phrasing that feels overly conversational or lacks the precision expected within a technical proposal. Let’s consider some common pitfalls and how to proactively address them.
One frequent issue is using vague terms like “it should” or “we need.” In a formal document, these phrases lack impact and don’t convey the why behind a suggestion. Instead of saying “It should be more efficient,” which leaves room for interpretation, try something like, “The proposed implementation introduces an O(n^2) complexity in the core algorithm; we suggest exploring alternative approaches leveraging a hash table to achieve an expected time complexity of O(n).” Notice the explicit articulation of the problem (O(n^2)) and the solution (hash table). Similarly, avoid “we think” – replace it with “Based on our analysis…” or “We propose…”. Another key area is active versus passive voice. While passive voice isn’t inherently bad, over-reliance can create convoluted sentences. Aim for a balance; actively stating who’s responsible when appropriate (“The team will investigate…” ) adds clarity and accountability.
Let’s look at how this might play out in a practical scenario. Imagine you’re submitting a pull request (PR) to the W3C Wasm TC repository, describing a change related to memory management. A colleague might send you a comment on Slack: “This looks good, but maybe add some more detail?” That’s a perfectly understandable sentiment, but it doesn’t offer constructive feedback. A better response would be something like, “Thank you for the review. I’ve added a detailed explanation of the rationale behind this change, specifically addressing potential memory fragmentation issues outlined in section 3.2 of the specification.” This demonstrates attentiveness and immediately directs attention to relevant documentation. Remember, every sentence should contribute directly to conveying information and persuading your audience – be deliberate with your word choice.
Finally, pay close attention to phrasing when discussing existing proposals or specifications. Instead of saying “This is similar to…” it’s more effective to state “This builds upon the concepts outlined in RFC 9186 regarding memory model synchronization.” This demonstrates you’ve done your homework and understand the broader context. Using precise language, focusing on impact rather than simply stating what you want, and referencing existing documentation are all critical components of successful communication within a standards development environment.