Apply suggestions from code review

Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Signed-off-by: Teo Stocco <[email protected]>

website/blog/2023-11-27-node-compatibility/index.mdx

@@ -6,7 +6,7 @@ We are happy to announce that we have redesigned our SDKs to support Node/Deno a
 
 In the realm of WebAssembly, the [wit-bindgen](https://github.com/bytecodealliance/wit-bindgen) project emerges as the most mature tool to create and maintain the language bindings for WebAssembly modules. This tool introduces WIT (WebAssembly Interface Types) as an Interface Definition Language (IDL) to describe the imports, exports, and capabilities of WebAssembly components seamlessly.
 
-For example, Metatype implements the reactor pattern to handle requests as they come and delegate part of their execution in correct WASM runtime. The wit-bindgen helps there to define the interfaces between the guest (the Metatype runtime) and the host (the typegate) to ensure the correct serialization of the payloads. The `wit` defintion could look like this:
+For example, Metatype implements the reactor pattern to handle requests as they come and delegate part of their execution in correct WASM runtime. The wit-bindgen helps there to define the interfaces between the guest (the Metatype runtime) and the host (the typegate) to ensure the correct serialization of the payloads. The `wit` definition could look like this:
 
 ```
 package metatype:wit-wire;

website/docs/concepts/RFCs/M0-template.mdx

@@ -16,13 +16,13 @@ Why are we doing this? What use cases does it support? What is the expected outc
 
 ## Guide-level explanation
 
-Explain the proposal as if it was already included in the language, and you were teaching it to another peer programmer. That generally means:
+Explain the proposal as if it were already included in the language, and you were teaching it to another peer programmer. That generally means:
 
 - Introducing new named concepts.
 - Explaining the feature largely in terms of examples.
 - Explaining how Metatype programmers should _think_ about the feature, and how it should impact the way they use the platform. It should explain the impact as concretely as possible.
 - If applicable, provide sample error messages, deprecation warnings, or migration guidance.
-- If applicable, describe the differences between teaching this to existing Metatype programmers and new Metatype programmers.
+- If applicable, describe the differences between teaching this to existing Metatype programmers and to new Metatype programmers.
 - Discuss how this impacts the ability to read, understand, and maintain Metatype code. Code is read and modified far more often than written; will the proposed feature make code easier to maintain?
 
 For implementation-oriented RFCs (e.g. for compiler internals), this section should focus on how compiler contributors should think about the change, and give examples of its concrete impact. For policy RFCs, this section should provide an example-driven introduction to the policy, and explain its impact in concrete terms.
@@ -44,6 +44,7 @@ Why should we _not_ do this?
 ## Rationale and alternatives
 
 - Why is this design the best in the space of possible designs?
++ Why is this design the best among possible designs?
 - What other designs have been considered, and what is the rationale for not choosing them?
 - What is the impact of not doing this?