doc: fix typos in contributing docs

doc/contributing/first-contributions.md

@@ -21,7 +21,7 @@ If your first contribution is motivated by an issue you already encounter, but y
 is complex, introduces a new feature, breaks backward compatibility, or needs a significant refactor,
 it can be useful to open an issue to discuss whether the change or its design is acceptable before
 working out the implementation details. The issue can be opened before you send the pull request,
-or along side your pull request (in which case, it's better to keep the pull request in draft mode).
+or alongside your pull request (in which case, it's better to keep the pull request in draft mode).
 
 Straightforward or non-controversial changes, such as an obvious bug fix or a small refactor, don't
 usually benefit from discussions in a separate issue, and can be sent directly as a pull request.

doc/contributing/pull-requests.md

@@ -459,7 +459,7 @@ commit.
 
 If a pull request has been inactive for more than six months, add the `stalled` label
 to it. That will trigger an automation that adds a comment explaining the pull request
-may be close for inactivity, giving a heads-up to the contributor before actually
+may be closed for inactivity, giving a heads-up to the contributor before actually
 closing it if it remains inactive.
 
 ### Approving a change

doc/contributing/writing-tests.md

@@ -345,7 +345,7 @@ when troubleshooting tests that timeout in CI. With no log statements, we have
 no idea where the test got hung up.
 
 There have been cases where tests fail without `console.log()`, and then pass
-when its added, so be cautious about its use, particularly in tests of the I/O
+when it's added, so be cautious about its use, particularly in tests of the I/O
 and streaming APIs.
 
 Excessive use of console output is discouraged as it can overwhelm the display,