Fix typos in roadmap

content/blog/2024-05-23-roadmap-may-2024.md

@@ -7,7 +7,7 @@ On May 7 and 8, 2024, folks from the Linebender team went to [the RustNL confere
 
 By that point, we all felt fairly exhausted, but ~~because Raph is a cruel taskmaster~~ since we wanted to use the opportunity we had, we came together in our hotel's conference room to discuss the Linebender project, and what we wanted from it.
 
-We'd initially thought of that this day would be an informal day of unstructured chatting about the ecosystem, but it fairly quickly turned into a semi-formal planning exercise, where we tried to figure out a roadmap for the next few months.
+We'd initially thought that this day would be an informal day of unstructured chatting about the ecosystem, but it fairly quickly turned into a semi-formal planning exercise, where we tried to figure out a roadmap for the next few months.
 
 What follows is a comprehensive summary of what exactly we're planning to do.
 We've tried to focus on blockers, where a missing feature in one project is stalling progress on other projects, because those are the hardest barriers to coordination, and we wanted to take advantage of being in the same room together to knock them down.
@@ -88,7 +88,7 @@ It includes some work we already finished since RustNL, but will not be updated
 
 - **Priority:** High.
 - **Assigned:** Olivier Faure.
-- **Description:** Right now widgets can use context methods in their different passes to request that other passes be ran. What passes can run what other passes isn't clearly documented, especially around edge cases. We should write an RFC to nail down the passes, how they can communicate, and the rationale around them.
+- **Description:** Right now widgets can use context methods in their different passes to request that other passes be run. What passes can run what other passes isn't clearly documented, especially around edge cases. We should write an RFC to nail down the passes, how they can communicate, and the rationale around them.
 - **PR:** TBD.
 
 ### Rewrite documentation
@@ -126,15 +126,15 @@ It includes some work we already finished since RustNL, but will not be updated
 
 - **Priority:** High.
 - **Assigned:** Chad Brokaw.
-- **Description:** Parley should support laying out inline content the way web browsers do, where blocks are splices into your text and should be laid out according to available inline space the same way words are.
+- **Description:** Parley should support laying out inline content the way web browsers do, where blocks are spliced into your text and will be laid out according to available inline space the same way words are.
 - **Issue:** [parley#25](https://github.com/linebender/parley/issues/25)
 - **PRs:** [parley#67](https://github.com/linebender/parley/pull/67), [parley#76](https://github.com/linebender/parley/pull/76)
 
 ### Write adequate documentation
 
 - **Priority:** High.
 - **Assigned:** Nico Burns.
-- **Description:** Parley currently has virtually no documentation. If we want it to become a fundational crate, we need to explain to people how to use it.
+- **Description:** Parley currently has virtually no documentation. If we want it to become a foundational crate, we need to tell people how to use it.
 - **PR:** [parley#26](https://github.com/linebender/parley/pull/26)
 
 ### Software renderer
@@ -179,7 +179,7 @@ It includes some work we already finished since RustNL, but will not be updated
 
 - **Priority:** Medium.
 - **Assigned:** Daniel McNab.
-- **Description:** One of Xilem's selling point is the ability to handle virtual lists and async sources of data. That ability was temporarily removed for the Masonry port, but we'd like to add it back it. We don't want Masonry to be aware of async stuff, but the AppDriver trait should at least provide a method which lets Xilem access Masonry internals on its own initiative.
+- **Description:** One of Xilem's selling points is the ability to handle virtual lists and async sources of data. That ability was temporarily removed for the Masonry port, but we'd like to add it back. We don't want Masonry to be aware of async stuff, but the AppDriver trait should at least provide a method which lets Xilem access Masonry internals on its own.
 - **Issue:** [xilem#340](https://github.com/linebender/xilem/issues/340)
 
 ### Add unit tests
@@ -194,14 +194,14 @@ It includes some work we already finished since RustNL, but will not be updated
 - **Priority:** Low.
 - **Assigned:** Olivier Faure.
 - **Description:** Right now we're mostly working off vibes to know whether or not any of our work improved performance or introduced regressions.
-We should write at least *one* benchmark that would test a basic Xilem use-case, so we get a general idea how our performance is progressing.
+We should write at least *one* benchmark that would test a basic Xilem use-case, so we get a general idea of how our performance is progressing.
 - **Issue:** [xilem#362](https://github.com/linebender/xilem/issues/362)
 
 
 ## AccessKit
 
 Matt Campbell's contract with Google hasn't started yet.
-When it does, top priority will likely be the Android backend.
+When it does, the top priority will likely be the Android backend.
 
 The plan is to study existing Android accessibility implementations for non-Java toolkits, including Flutter, Chromium, and Gio, to get a better understanding of what's required to implement Android accessibility from scratch.
 
@@ -225,13 +225,13 @@ Some notable sub-goals:
 
 - **Priority:** Highest.
 - **Assigned:** Aaron Muir Hamilton, Raph Levien.
-- **Description:** We need to extend Winit to be compatible with Android IME interfaces. An Android application without support for virtual keyboard and other input methods is a non-starter. Our design choices here will have influence on accessibility as well.
+- **Description:** We need to extend Winit to be compatible with Android IME interfaces. An Android application without support for the virtual keyboard and other input methods is a non-starter. Our design choices here will have some influence on accessibility as well.
 
 ### Gesture recognition
 
 - **Priority:** Low.
 - **Assigned:** Aaron Muir Hamilton.
-- **Description:** When the user swipes on the screen, we want to send some kind of scrolling events instead of a normal pointer event. Ideally there should be first-class support for that event to handle momentum scrolling, but a dumber solution would just emulate mouse wheel ticks.
+- **Description:** When the user swipes on the screen, we want to send some kind of scrolling event instead of a normal pointer event. Ideally there should be first-class support for that event to handle momentum scrolling, but a dumber solution would just emulate mouse wheel ticks.
 
 
 ## Conclusion