Azure · lmazuel · Jun 4, 2020 · Jun 1, 2020
diff --git a/common/smoketest/README.md b/common/smoketest/README.md
@@ -74,7 +74,7 @@ pip install -r requiriments.txt
 pip install -r requiriments_async.txt
 ```
 
-If a python version below 3.5 is being used, it is still possible to run the samples. When it gets to the async tests a message `'Async not suported'` will be displayed.
+If a python version below 3.5 is being used, it is still possible to run the samples. When it gets to the async tests a message `'Async not supported'` will be displayed.
 
 ## Key concepts
 

diff --git a/doc/dev/mgmt/generating-integration-test.md b/doc/dev/mgmt/generating-integration-test.md
@@ -127,7 +127,7 @@ now you can run live integration test:
 
 ## Fixing Test
 
-It's obvious that when running test for the first time someting is not going to work.
+It's obvious that when running test for the first time something is not going to work.
 
 The best approach is to:
 - fix the test manually

diff --git a/doc/dev/mgmt/generation.md b/doc/dev/mgmt/generation.md
@@ -8,7 +8,7 @@ IMPORTANT NOTE: All the commands prefixed by `python` in this page assumes you h
 
 ### Autorest versioning
 
-A few notes on [Autorest for Python versionning](https://github.com/Azure/autorest.python/blob/master/ChangeLog.md):
+A few notes on [Autorest for Python versioning](https://github.com/Azure/autorest.python/blob/master/ChangeLog.md):
 - Autorest for Python v2.x is deprecated, and should not be used anymore for any generation under any circumstances.
 - Autorest for Python v3.x is the most currently used one. Should not be used, but still ok if service team are still in v3.x and they want to avoid breaking changes for a given version (rare).
 - Autorest for Python v4.x is the current recommendation. This generator can generates async code, but this should be disabled with --no-async. No package should be shipped with async based on v4

diff --git a/doc/dev/mgmt/multiapi.md b/doc/dev/mgmt/multiapi.md
@@ -14,7 +14,7 @@ Because there is different flavors of Azure that are not necessarly provided wit
 
 ### Why a multi-api package?
 
-Indeed, a simple solution would be to write down explictly what version of SDK supports what API version. Example: 1.0 supports 2015-06-01, 2.0 supports 2017-07-01, etc. The story for customers then would be to pin the specific SDK version for the specific API version they need. However, this was considered unacceptable in an end-to-end scenario:
+Indeed, a simple solution would be to write down explicitly what version of SDK supports what API version. Example: 1.0 supports 2015-06-01, 2.0 supports 2017-07-01, etc. The story for customers then would be to pin the specific SDK version for the specific API version they need. However, this was considered unacceptable in an end-to-end scenario:
 - It means you cannot install in the same Python environment packages that would target different cloud (Python doesn't allow installation of different versions of the same package together). Azure CLI or Ansible supports for different clouds would then be extremely complicated.
 - This forces customers to use old SDK, that might have been fixed on different axis than API version (security fixes, new SDK features like async, etc.)
 - Customers rarely needs only one package, but a set of them (storage, compute, network, etc.) and having to keep track of the correct list of packages is challenging.
@@ -44,7 +44,7 @@ Network interfaces operations are defines in a [network interface file](https://
 
 **Python multi-api packaging is based on the assumptions that it's true.** If it's not, it's usually ok but requires a little more subtle packaging (see final section here)
 
-Being that a given Swagger defines only *one* fixed API version, doing multi-api version in one package implies shipping several Swagger files into one package. This is achived by the `batch` directive of Autorest. More details on how to write Readme for Swagger in the specific page for it [swagger_conf.md](./swagger_conf.md).
+Being that a given Swagger defines only *one* fixed API version, doing multi-api version in one package implies shipping several Swagger files into one package. This is archived by the `batch` directive of Autorest. More details on how to write Readme for Swagger in the specific page for it [swagger_conf.md](./swagger_conf.md).
 
 Python SDK team is responsible to design the correct set of tags to set for the `batch` node. Each line of the batch directive should contains only *one* api version to match the folder name used. this might require adding new tags in the readme.md that are specific to only one API version. These tags are usually suffixed by "-only" ([example with compute](https://github.com/Azure/azure-rest-api-specs/tree/master/specification/compute/resource-manager#tag-package-2019-03-01-only))
 

diff --git a/doc/dev/mgmt/swagger_conf.md b/doc/dev/mgmt/swagger_conf.md
@@ -14,7 +14,7 @@ In practical terms, we want to control the version of Autorest used, the output
 
 ## Writing the readme
 
-Writing the readme is the responsability of the Python SDK team. There is currently two types of templates for Python readmes:
+Writing the readme is the responsibility of the Python SDK team. There is currently two types of templates for Python readmes:
 - Readme that handles only one API version, and generates packages that handle one API version only
 - Readme that handles several API versions, and generates packages with multiples API and profile supports