docs: fix 17 typos across README and proposals

APPLICATION-GUIDE.md

@@ -55,9 +55,9 @@ focus has been front-end web development or mobile applications.
 
 Finally, do you have any other commitments during the GSoC period, and how will
 they affect your work? These aren't normally deal-breakers; in the past
-we've accomodated people who've needed to care for elderly relatives on
+we've accommodated people who've needed to care for elderly relatives on
 a certain schedule, and in one case a student needed to be away from their
-work for a week in order to get married. We can be reasonably accomodating
+work for a week in order to get married. We can be reasonably accommodating
 on this front, we simply prefer not to be surprised.
 
 # Errors to avoid
@@ -103,5 +103,5 @@ that you can find us on Matrix.
 * Participants in any Mozilla project are expected to respect
 and uphold the Mozilla Community Participation Guidelines
 [https://www.mozilla.org/en-US/about/governance/policies/participation/]
-* The GSOC FAQ is here available here:
+* The GSOC FAQ is available here:
 [https://developers.google.com/open-source/gsoc/faq]

README.md

@@ -53,5 +53,5 @@ That said, there are a lot of moving parts to the Mozilla project, and figuring
     * The receipt showing you paid for this semester
     * The letter showing your scholarship/financial aid etc covers this semester in early 2020
 
-    And it is fine to markout the grades or the funding or other personal details (we just need to see your name, your school name and the recent date on there).
+    And it is fine to mark out the grades or the funding or other personal details (we just need to see your name, your school name and the recent date on there).
     Our team does not review proof of enrollment documents via email. Your documents will be reviewed after March 31 and the team will let you know at that time if your submission was not accepted. You will be able to submit a new proof of enrollment if the first one is not accepted by our team. 

proposals/common-voice-kiosk.md

@@ -37,7 +37,7 @@ Here is a rough expected timeline for 12 weeks of work:
 
 * ~1 week: project setup, learning the codebase, meeting the team
 * ~2 weeks: scoping out project, researching and determining best approach
-* ~2 weeks: working with UX leads to finalize desings
+* ~2 weeks: working with UX leads to finalize designs
 * ~4 weeks: active development based on finalized designs
 * ~2 weeks: QA and refinement
 * ~1 week: documentation, product demo, retrospective

proposals/devtools-overflow-debugging.md

@@ -14,7 +14,7 @@ It is very common for unwanted scrollbars to appear in webpages when working on
 
 - Ability to navigate large code bases and communicate with relevant teams remotely.
 
-- Experience using browser developer tool
+- Experience using browser developer tools
 
 ## Project Details
 
@@ -38,7 +38,7 @@ The steps to complete the project are roughly outlined below:
 
 - **Phase 1 (May 18 - June 15)**: Implement the new Gecko API that lists element nodes that cause a given element to overflow.
 
-- **Phase 2 (June 15 - August 1)**: Implement the basic UI in DevTools for displaying this list of elementsd.
+- **Phase 2 (June 15 - August 1)**: Implement the basic UI in DevTools for displaying this list of elements.
 
 - **Phase 3 (August 1 - ~August 17)**: Stabilize and refine the feature. Polish the UI, and perhaps add telemetry to track usage of the feature.
 

proposals/devtools-server-sent-events.md

@@ -13,7 +13,7 @@ This project is about building an inspector intercepting and visualizing server-
 
 ## Skills Required
 
-* Experience with Javascript/HTML/CSS required
+* Experience with JavaScript/HTML/CSS required
 * Experience with React/Redux is advantage
 * Clear English communication
 * Enjoy open source environment
@@ -36,7 +36,7 @@ The feature should be part of the Network panel and it should allow the user to:
 
 * Explore JSON formatted data using an expandable tree widget
 
-A stretch goal is building binary data inspector and use it for previewing binary packets sent through server-sent events and also WebSocket channels.
+A stretch goal is building a binary data inspector and use it for previewing binary packets sent through server-sent events and also WebSocket channels.
 
 
 ## Additional Information

proposals/extension-activity-monitor.md

@@ -29,7 +29,7 @@ Knowledge of browser extension APIs is a bonus.
 An `activityLog` API is available (in Firefox >= 70) to privileged extensions, the applicant's goal is leveraging this API to
 create a privileged extension which would explore various ways to present this information to the users.
 
-In particular, this project's goal is to expore the following areas:
+In particular, this project's goal is to explore the following areas:
 
 - An extension page that shows the active extensions and their effect on the browser, such as altered browser settings or network requests,
   and the messages exchanged between the different parts of the extension.

proposals/servo-webgpu.md

@@ -5,22 +5,22 @@
 
 ## Project Description 
 
-There is a an initial implementation of WebGPU in Servo.
-This GSoC proposal is for improving this to a point where basic examples can be ran, and a fair portion of the conformance test suit is covered.
+There is an initial implementation of WebGPU in Servo.
+This GSoC proposal is for improving this to a point where basic examples can be run, and a fair portion of the conformance test suite is covered.
 
 ## Skills Required
 
 An applicant needs:
 
-* good understanding of at least one of the graphics APIs, and will to learn more (WebGPU)
-* will to learn or experience working with Rust language
+* good understanding of at least one of the graphics APIs, and willingness to learn more (WebGPU)
+* willingness to learn or experience working with Rust language
 * ability to navigate large code bases and communicate with relevant teams remotely
 
 Prior experience working with Servo or wgpu-rs is a plus.
 
 ## Project Details
 
-[WebGPU](https://gpuweb.github.io/gpuweb/) is an emerging API or the Web that efficiently exposes graphics and compute capabilities. It's not based on an existing native API but is inspired by, and targeting Vulkan, D3D12, and Vulkan.
+[WebGPU](https://gpuweb.github.io/gpuweb/) is an emerging API or the Web that efficiently exposes graphics and compute capabilities. It's not based on an existing native API but is inspired by, and targeting Vulkan, D3D12, and Metal.
 
 [Servo](https://github.com/servo/servo/) is an experimental browser engine written in [Rust](https://www.rust-lang.org/) language. It was an early home for [Stylo](https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-engine-quantum-css-aka-stylo/) and [WebRender](https://hacks.mozilla.org/2017/10/the-whole-web-at-maximum-fps-how-webrender-gets-rid-of-jank/), which are now parts of Firefox. Servo is currently used to experiment with VR/AR applications, where latency, power consumption, and performance requirements are extremely tight. Therefore, implementing WebGPU in Servo opens the doors for more immersive experience in VR and AR.
 

proposals/webrender-gfx-opengl.md

@@ -12,7 +12,7 @@ Make the experimental WebRender fork by Szeged (that uses gfx-rs for rendering)
 An applicant needs:
 
 * good understanding of OpenGL and general principles behind Vulkan
-* will to learn or experience working with Rust language
+* willingness to learn or experience working with Rust language
 * ability to discover, investigate and fix graphics issues independently, while constantly communicating the progress and requesting feedback
 
 Prior experience working with gfx-rs and/or WebRender is a plus.