Copy edit workflow.md again

Copy edit file for active voice, agreement and formatting.

Author: Amanda Butler

docs/reference/contributing/guidelines/workflow.md

@@ -48,7 +48,7 @@ Pull requests on GitHub have to meet the following requirements to keep the code
 - Commits should always contain a proper description of their content. Start with a concise and sensible one-line description. Then, elaborate on reasoning of the choices made, descriptions for reviewers and other information that might otherwise be lost.
 - You should always write commits to allow publication, so they can never contain confidential information, reference private documents, links to intranet locations or rude language.
 - Each commit should be the minimum self-contained commit for a change. A commit should always result in a new state that is again in a compilable state. You should (if possible) split large changes into logical smaller commits that help reviewers follow the reasoning behind the full change.
-- Commits and pull request title should follow [Chris Beam’s seven rules of great commit messages](http://chris.beams.io/posts/git-commit#seven-rules):
+- Commits and pull request titles should follow [Chris Beam’s seven rules of great commit messages](http://chris.beams.io/posts/git-commit#seven-rules):
 	1. Separate subject from body with a blank line.
 	1. Limit the subject line to 72 characters (note that this is a deviation from Beam's standard).
 	1. Capitalize the subject line.
@@ -93,8 +93,7 @@ Each pull request goes through the following workflow:
 
 The Mbed OS maintainers add labels to a pull request that represent the pull request workflow states. The Mbed OS maintainers are responsible for moving pull requests through the workflow states.
 
-Each state is time boxed. In most cases, this is sufficient time to move to an another state. The pull request can be closed if no update
-is provided within the time frame.
+Each state is time boxed. In most cases, this is sufficient time to move to an another state. The pull request can be closed if no update is provided within the time frame.
 
 ##### Reviews
 
@@ -116,7 +115,7 @@ Time: 3 days for the pull request author to respond to the review comments.
 
 ##### Releases
 
-When we merge a pull request that will be published in a patch release, we tag the pull request with specific patch release version. This is the release in which we first publish this pull request. For patch releases, we allow only bug fixes, new targets and enhancements to existing functionality. New features only go to feature releases.
+When we merge a pull request that we will publish in a patch release, we tag the pull request with specific patch release version. This is the release in which we first publish this pull request. For patch releases, we allow only bug fixes, new targets and enhancements to existing functionality. New features only go to feature releases.
 
 The release tag has the following format: