Merge branch 'adbridge-development' into development

Author: adbridge

docs/reference/contributing/guidelines/workflow.md

@@ -63,9 +63,7 @@ If commits do not follow the above guidelines, we may request that you modify th
 
 ## Pull request template
 
-The following template is automatically provided on the raising of a pull request against mbed-os.
-The details required will depend on the type of pull request being raised. See below for a more detailed
-explanation of the requirements.
+The following template is automatically provided when you raise a pull request against `mbed-os`. The details required depend on the type of pull request you create:
 
     ### Description (*required*)
 
@@ -107,14 +105,14 @@ explanation of the requirements.
 
 ### Description field
 
-There are two parts to the description, both of which are required.
-The first is a summary of the pull request. This should clearly state the reason for the PR and what 
-the changes entail. The second part requires the author to state what, if any, documentation changes 
-also need to be made to accompany the changes.
+There are two parts to the description, both of which are required:
+
+- The summary of the pull request clearly states the reason for the PR and what the changes involve.
+- The documentation section requires you to state what, if any, documentation changes need to accompany the code changes.
 
 ### Pull request type
 
-There are three pull request types and these correspond to the 3 main categories specified in semantic versionning, Patch, Feature (Minor) and Major.
+There are three pull request types, and these correspond to the three main categories specified in semantic versioning: patch, feature (minor) and major.
 
 #### Patch update
 
@@ -160,43 +158,34 @@ Each feature has a Mbed OS technical lead. This person is responsible for:
 
 This is for breaking changes and should be rare. A breaking change is any change that results in breaking user space. It should have strong justification for us to consider it. Often, such changes can be backward compatible, for example, deprecating the old functionality and introducing the new replacement.
 
-A contribution containing a breaking change is the most difficult PR to get merged. Any breaking changes in a codebase can have a large negative impact on any users of the codebase. Breaking changes are always limited to a major version release.
+A contribution containing a breaking change is the most difficult PR to get merged. Any breaking changes in a codebase can have a large negative effect on any users of the codebase. Breaking changes are always limited to a major version release.
 
 A project technical lead and the Mbed OS technical lead must approve breaking change pull requests.
 
-
 ### Test results
 
-This section is to indicate what test results if any are required for the PR.
-The three options are :
-* No Tests required for this change (E.g docs only update)
-* Changes will be tested by existing mbed-os tests (Greentea or Unittest)
-* Tests / results will supplied as part of this PR. For this option the test results and/or tests
-  should be posted in this section below the tick boxes.
+This section is to indicate what test results, if any, are required for the PR. The three options are:
+
+- No tests required for this change (for example, a documentation-only update).
+- Changes will be tested by existing `mbed-os` tests (Greentea or Unittest).
+- Tests and results will be supplied as part of this PR. For this option, post the tests and test results
+  below the tick boxes.
 
 ### Reviewers
 
-Reviewers are automatically added by a bot based on the files that are actually changed, however this section
-gives the author the option to specify additional, specific reviewers. Required reviewers should be tagged here. E.g. @adbridge, @0xc0170
-
+A bot automatically adds reviewers based on the files that are actually changed. However, this section gives you the option to specify additional, specific reviewers. Tag required reviewers here, such as @adbridge, @0xc0170.
 
 ### Release Notes
 
-Every pull request changing or adding functionality must fill in the "Release notes" section. Consequently
-this applies to feature and major PRs. For both these types the 'Summary of changes' section must be 
-completed. This should provide a brief description of changes introduced, including justification.
+Every pull request changing or adding functionality must fill in the "Release notes" section. This applies to feature and major PRs. For both these types, you must complete the "Summary of changes" section. Provide a brief description of changes introduced, including justification.
 
-For major PRs is is also compulsory to complete the 'Impact of changes' and 'Migration actions required'.
+For major PRs, it is also compulsory to complete the "Impact of changes" and "Migration actions required".
 
 The impact of changes must contain an analysis of effects: components affected and potential consequences for users.
 
-The migration actions required should describe how to migrate from a previous version of the code being
-changed to the new version. Please include code snippets to illustrate before and after the addition or 
-change.
-
-The release notes section is automatically pulled into the overall release notes for a feature or major 
-release and this should be considered when writing the entries.
+The migration actions required should describe how to migrate from a previous version of the code being changed to the new version. Please include code snippets to illustrate before and after the addition or change.
 
+The release notes section is automatically pulled into the overall release notes for a feature or major release. This should be considered when you write the entries.
 
 ## GitHub pull requests workflow
 
@@ -218,41 +207,43 @@ All pull requests must be reviewed. The Arm Mbed CI bot determines the most suit
 
 GitHub dismisses a reviewer's status after any change to the pull request commit history (such as adding a new commit or rebasing). Smaller changes, such as documentation edits or rebases on top of latest master, only require additional review by maintainers. Their approval is sufficient because a team assigned as a reviewer already approved the pull request.
 
-Label: `needs: review`
-Time: Three days for reviewers to leave feedback after the maintainers add the label.
+- Label: `needs: review`.
+- Time: Three days for reviewers to leave feedback after the maintainers add the label.
 
 ### The Continuous Integration (CI) testing
 
 There are many [CI systems available](../contributing/ci.html) for testing Mbed OS pull requests and braches. Which CI tests we run against a particular pull request depends on the effect that it has on the code base. Irrespective of which CI tests run, Mbed OS has an all-green policy, meaning that all triggered CI jobs must pass before we merge the pull request.
 
-- Label: `needs: CI`
+- Label: `needs: CI`.
 - Time: One day for CI to complete and report back results.
 
 ### Work needed
 
 A pull request in the "work needed" state requires additional work due to failed tests, or rework as a result of the review. If a pull request is in this state, our maintainers request changes from the pull request author.
 
-- Label: `needs: work`
+- Label: `needs: work`.
 - Time: Three days for the pull request author to action the review comments.
 
 ### Ready for integration
 
 Maintainers merge pull requests during the internal gatekeeping meetings that occur three times a week. They can merge straightforward pull requests immediately.
 
-- Label: `Ready for merge`
-- Time: Two days
+- Label: `Ready for merge`.
+- Time: Two days.
 
 ### Releases
 
 When we merge a pull request that we will publish in a patch release, we tag it with the 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 are only published in feature releases.
 
-The release tag has the following format:
+The release tag has the format:
+
+*release-version: m.f.p*
 
-*release-version: m.f.p*  Where:
+Where:
 
-* `m` is the major release 
-* `f` is the feature release 
-* `p` is the patch release.
+- `m` is the major release.
+- `f` is the feature release.
+- `p` is the patch release.
 
 From time to time there may be additional suffixes added which could represent a release candidate or 
 alpha/beta release etc