chore: fix typos (#477)

charter/README.md

@@ -112,7 +112,7 @@ Chairs also have the following regular duties within their Working Groups:
 * Check into persistent issues present on a given Working Group's repositories of responsibility (ex. bot failures)
 * Ensure that the WG roster list is an accurate reflection of current member activity.
 
-In addition to these reponsibilities, a Chair may have additional responsibilities specific to their Working Group.
+In addition to these responsibilities, a Chair may have additional responsibilities specific to their Working Group.
 
 ### Reaching Agreement
 
@@ -156,8 +156,8 @@ The AWG in turn delegates its authority to all other working groups.
 To prevent the AWG from becoming the sole political power of the project,
 it is expected that the AWG abstains from casting individual technical decisions that are the responsibility of other working groups.
 The AWG should principally serve as a _circuit breaker_.
-If a delegate working group is failing to meet its responsibilities, the AWG may intervent up to and including alterning group members, or altering the groups authority, responsibilities, or existence.
+If a delegate working group is failing to meet its responsibilities, the AWG may intervene up to and including altering group members, or altering the groups authority, responsibilities, or existence.
 
 **Authors note:**
 
-> The current Electorate/AWG mix places almost all the power in the hands of a few large corporatations at the outset. While not ideal to many, this was chosen because it represents today's status-quo. The choice to delay defining an Electorate was made to _ensure_ it was not rushed, and that we have time to balance project stakeholders large and small.
+> The current Electorate/AWG mix places almost all the power in the hands of a few large corporations at the outset. While not ideal to many, this was chosen because it represents today's status-quo. The choice to delay defining an Electorate was made to _ensure_ it was not rushed, and that we have time to balance project stakeholders large and small.

policy/leaving-governance.md

@@ -13,4 +13,4 @@ This documents the process of leaving Electron Governance. A contributor is no l
 
 * Request an admin of Electron's Slack to change the contributor to a guest account. Message in #wg-community-safety for this. Any member of Community & Safety WG is a Slack admin.
 
-* Message in #access-request that the contributor has left Electron Governance. The Google suite account needs to be mannually disabled, and 30 days later the account will be deleted. See [details on GSuite permissions](./permissions.md#gsuite).
+* Message in #access-request that the contributor has left Electron Governance. The Google suite account needs to be manually disabled, and 30 days later the account will be deleted. See [details on GSuite permissions](./permissions.md#gsuite).

wg-administrative/README.md

@@ -19,7 +19,7 @@ It is important that other working groups have autonomy and agency to fulfill th
 
 | Avatar | Name | Role | Time Zone |
 | -------------------------------------------|----------------------|----------------------------| -------- |
-| <img src="https://github.com/PlaineKevin.png" width=100 alt="@PlaineKevin">  | Kevin Nguyen [@PlaineKevin.](https://github.com/PlaineKevin) | Chair | PT (Los Angeles) |
+| <img src="https://github.com/PlaineKevin.png" width=100 alt="@PlaineKevin">  | Kevin Nguyen [@PlaineKevin](https://github.com/PlaineKevin) | Chair | PT (Los Angeles) |
 | <img src="https://github.com/groundwater.png" width=100 alt="@groundwater">  | Jacob Groundwater [@groundwater](https://github.com/groundwater) | Member | PT (San Francisco) |
 
 ### Open Roles

wg-api/spec-documents/message-ports.md

@@ -70,7 +70,7 @@ When this message is received in the main process, any `MessagePort` objects tra
 * `options` Object (optional)
   * `transfer` any[] - a list of transferable objects to be sent with the message.
 
-Similar to `WebContents.send`, but allows transfering transferable objects.
+Similar to `WebContents.send`, but allows transferring transferable objects.
 
 > [name=Samuel Attard]
 > I'm trying to figure out if there's a way for this to be non-breaking integrated into `.send` to avoid the confusion around two different ways to send IPC.  Can't see an easy way out there though.
@@ -202,6 +202,6 @@ There have been several discussions (going [as far back as 2013](https://lists.w
 
 As written, this API would provide a way to establish direct renderer-to-renderer communication, as well as a new way to divide the namespace of IPC messages, and a way to provide an [object-capability model](https://html.spec.whatwg.org/multipage/web-messaging.html#ports-as-the-basis-of-an-object-capability-model-on-the-web). It would also be possible to bind a MessagePort to a Node worker thread in the main process, allowing direct communication from a renderer to a background thread in the main process.
 
-The addition of the option to specify transferables along with messages sent between processes could in future be extended to allow transfering new kinds of objects. For instance, we could allow transferring file handles, or [Streams](https://streams.spec.whatwg.org/).
+The addition of the option to specify transferables along with messages sent between processes could in future be extended to allow transferring new kinds of objects. For instance, we could allow transferring file handles, or [Streams](https://streams.spec.whatwg.org/).
 
 [channel-messaging-api]: https://developer.mozilla.org/en-US/docs/Web/API/Channel_Messaging_API

wg-api/spec-documents/wc-print-sync.md

@@ -39,7 +39,7 @@ will become
 `pageRanges` => `pageRange`
 `printSelectionOnly` => `shouldPrintSelectionOnly`
 
-`webContents.print()` will no longer take a callback, and instead return a `Promise<void | string>`, where the Promise resolves if printing successfully occured, and rejects with the failure cause if it did not occur.
+`webContents.print()` will no longer take a callback, and instead return a `Promise<void | string>`, where the Promise resolves if printing successfully occurred, and rejects with the failure cause if it did not occur.
 
 ## Rollout Plan
 

wg-releases/major-version-release-schedule.md

@@ -88,7 +88,7 @@
 | Week 13 | 2020-01-24 | 8.0.0-beta.x | Action: Release final beta |
 | Week 14 | 2020-01-27 | Quiet Period Starts | Stable Prep Week |
 | Week 14 | 2020-01-31 | Stable Prep Items Due | Stable Prep Week |
-| Week 15 | 2020-02-03 | Kick off 8.0.0 releaese | Action Item |
+| Week 15 | 2020-02-03 | Kick off 8.0.0 release | Action Item |
 | Week 15 | 2020-02-04 | 8.0.0 | Stable Deadline ✨ |
 
 ## 9.0.0

wg-releases/sudowoodo.md

@@ -8,7 +8,7 @@ Only authorized releasers have the ability to trigger Sudowoodo, and they can be
 
 In order to trigger a new release:
 
-1. Invoke `/sudowoodo` as a backslack command in the `#bot-releases` Slack channel.
+1. Invoke `/sudowoodo` as a backslash command in the `#bot-releases` Slack channel.
 2. Choose the correct release branch (`main`, `5-0-x`, etc.) and release type (`stable`, `beta`, `nightly`) from the dropdown in the resulting dialog.
 3. Monitor the resulting release until builds are finished and Sudowoodo is preparing to publish the new release to npm
 4. Enter the OTP needed to publish the builds to npm (similarly gated to `sudowoodo-trainers`)