Edit workflow.md

Edit file, mostly for consistent person and tense.

Author: Amanda Butler

docs/reference/contributing/guidelines/workflow.md

@@ -231,17 +231,17 @@ The following labels summarize the scope of the pull request.
 
 #### Rollup pull requests
 
-When Mbed OS has many small, orthogonal pull requests waiting for CI testing to start, maintainers have the option of bundling multiple pull requests into a single pull request referred to as a rollup pull request. Once this rollup pull request passes CI testing and is merged, the bundled pull requests used to build the rollup pull request are also automatically merged.
+When Mbed OS has many small, orthogonal pull requests waiting for CI testing to start, maintainers can bundle multiple pull requests into a single pull request referred to as a rollup pull request. Once this rollup pull request passes CI testing and merges, the bundled pull requests used to build the rollup pull request also automatically merge.
 
-By the time a pull request is selected to be integrated into a rollup pull requests, it already has a release label and is patiently waiting to start CI testing. Each bundled pull request gains a *rollup PR* label and once the rollup pull request is generated, a comment is also be added to the bundled pull request, informing the bundled pull request's author.
+By the time the maintainers select a pull request to be integrated into a rollup pull request, it already has a release label and is waiting to start CI testing. Each bundled pull request gains a *rollup PR* label. Once the rollup pull request is generated, a comment is added to the bundled pull request, informing the bundled pull request's author.
 
-In the event that the rollup pull request fails CI testing, maintainers will identify the problem bundled pull requests, update their statuses, and will provide additional guidance on what went wrong. Critically, if a bundled pull request is updated *while* it is already in a rollup pull request, and the rollup pull request passes CI and is merged, the updated bundled pull request *will not* be automatically merged.
+If a rollup pull request fails CI testing, maintainers identify the problem bundled pull requests, update their statuses and provide additional guidance on what went wrong. Critically, if a bundled pull request is updated *while* it is already in a rollup pull request, and the rollup pull request passes CI and merges, the updated bundled pull request *does not* automatically merge.
 
 ##### How it works
 
-Rollup pull requests take advantage of the exact same process that is used to merge a pull request into master, except that pull requests are mergedin into a freshly rebased temporary branch. All pull requests with the *rollup PR* label are cloned and merged into the temporary branch, and assuming no merge conflicts arise, a pull request is opened with the temporary branch. Once the rollup pull request is merged, all other pull requests that went into building the rollup pull request are also _marked_ as merged because their contents are now a part of master.
+Rollup pull requests use the same process as pull requests merging into master, except that pull requests are merged into a rebased temporary branch. All pull requests with the *rollup PR* label are cloned and merged into the temporary branch. If no merge conflicts arise, a pull request is opened with the temporary branch. Once the rollup pull request merges, all other pull requests that went into building the rollup pull request are also _marked_ as merged because their contents are now part of master.
 
-Rollup pull requests are a solution to two types of problem: CI testing duration, and semantic conflict problem. The most obvious use of a rollup pull request is to drastically lower the time needed to test many pull requests at once. Best case, maintainers go from needing to put N pull requests through CI, down to only one, drastically lowering the load on CI infrastructure, and helps close pull requests much sooner. The second, more suble, problem that rollup pull requests solve is the case where two pull requests pass testing on their own, but as soon as they join together, the way they interact with each other causes tests to fail. A simple example can be found [here](https://bors.tech/essay/2017/02/02/pitch).
+Rollup pull requests are a solution to two types of problem: CI testing duration and semantic conflict problem. Rollup pull requests drastically lower the time to test many pull requests at once. Instead of putting many pull requests through CI, only one goes through testing. This lowers the load on the CI infrastructure and helps close pull requests sooner. The second, more subtle, problem that rollup pull requests solve is the case in which two pull requests pass testing on their own, but as soon as they join together, the way they interact with each other causes tests to fail. For more details, please see [this example](https://bors.tech/essay/2017/02/02/pitch).
 
-A special case occurs when a bundled pull request is updated while its rollup pull requests is undergoing testing. When a pull request is bundled into a rollup pull request, it's commits become a part of the rollup pull request, at the time that the rollup pull request source branch is created. If the bundled pull requests is updated, its commit history is no longer exactly mirrored in the rollup pull request. If this situation arises, the bundled pull request that was updated _will not_ be automatically marked as merged, since all changes of the updated bundled pull request were not present in the merged rollup pull request. Maintainers will treat the updated, previously-bundled pull requests as if it were on its own all along.
+A special case occurs when a bundled pull request is updated while its rollup pull request undergoes testing. When a pull request is bundled into a rollup pull request, its commits become a part of the rollup pull request at the time that the rollup pull request source branch is created. If you update the bundled pull requests, its commit history is no longer exactly mirrored in the rollup pull request. If this situation arises, the bundled pull request that was updated _is not_ automatically marked as merged because all changes of the updated bundled pull request were not present in the merged rollup pull request. Maintainers treat the updated, previously bundled pull request as if it were on its own all along.