5 files changed, 40 insertions, 40 deletions
diff --git a/docs/integration-CICD.rst b/docs/integration-CICD.rst
index 298b292f4..f7d9f0790 100644
--- a/docs/integration-CICD.rst
+++ b/docs/integration-CICD.rst
@@ -19,7 +19,7 @@ Continuous Integration
 The CI part provides the following features:
 
 - Repository Verification (format of the INFO.yaml)
-- Patchset verification thank to json/yaml/python/go/rst/md linters. These jenkins
+- Patchset verification thank to json/yaml/python/go/rst/md linters. These Jenkins
   verification jobs are hosted in the ci-management repository. They can vote
   +1/-1 on patchset submission. Integration team systematically enables linters
   on any new repository
@@ -45,24 +45,24 @@ There are 2 Continuous Deployment architectures.
 Jenkins CD on Windriver/Intel lab
 ..................................
 
-The CD part on windriver/Intel is based on jenkins.
+The CD part on Windriver/Intel is based on Jenkins.
 
-It is based on a standalone VM hosting a jenkins server.
-The credentials of this VM as well as the jenkins server have been provided to
+It is based on a standalone VM hosting a Jenkins server.
+The credentials of this VM as well as the Jenkins server have been provided to
 integration committers.
 
-Several jobs can be triggered from this jenkins interface.
+Several jobs can be triggered from this Jenkins interface.
 Historically several chains were run daily (staging/release) but due to
 performance issues, they have all been stopped.
 Only SB-00 has been kept for use case support.
-The jenkins interface was however used to launch the installation of SB-00.
+The Jenkins interface was however used to launch the installation of SB-00.
 
-This jenkins script is leveraging resources available in OOM and integration
+This Jenkins script is leveraging resources available in OOM and integration
 repositories.
 
-It was planned to replaced this CD by a gitlab runner based CD to unify the CD
-management. But due to performance issue in the DC it was not possible to
-finalize the operation in Guilin.
+The replacement of this CD by a gitlab runner based CD to unify the CD
+management was planned, but finalizing the operation in Guilin was not possible
+due to performance issues.
 
 Gitlab CD
 .........
diff --git a/docs/integration-labs.rst b/docs/integration-labs.rst
index f00a5324c..2ac8ffb14 100644
--- a/docs/integration-labs.rst
+++ b/docs/integration-labs.rst
@@ -15,7 +15,7 @@ ONAP Integration Labs
    - The Continuous Deployment (CD) Labs
    - The Orange openlab
 
-Additionnaly integration contributors may deal with their own lab pushing results
+Additionally integration contributors may deal with their own lab pushing results
 in the integration portal (See DT http://testresults.opnfv.org/onap-integration/dt/dt.html)
 
 Windriver/Intel lab
@@ -38,8 +38,8 @@ resources (April 2020).
 In order to avoid disturbing the projects, the reinstallation has been postponed
 after Guilin.
 A huge cleanup has been done in order to save the resources.
-The historical CI/CD chains based on a stand alone jenkins VM hosted in Windriver
-have been stopped.For guilin only SB-00 has been kept and re-installed for the
+The historical CI/CD chains based on a stand-alone Jenkins VM hosted in Windriver
+have been stopped. For Guilin only SB-00 has been kept and re-installed for the
 use case support.
 
 If you want to use this lab, you need a VPN access. The procedure is described in
@@ -48,10 +48,10 @@ the `wiki <https://wiki.onap.org/pages/viewpage.action?pageId=29787070>`__.
 Environment Installation Scripts
 ................................
 
-In addition of the official OOM scripts, Integration used to provide some
-exwtra scripts/guidelines to install your OpenStack infrastructure thanks to a
+In addition to the official OOM scripts, Integration used to provide some
+extra scripts/guidelines to install your OpenStack infrastructure thanks to a
 heat template. See :ref:`Integration heat guideline <integration-installation>`
-for details. This scripts were used mainly in windriver labs but are not actively
+for details. These scripts were used mainly in Windriver labs but are not actively
 maintained.
 
 .. caution:
@@ -67,8 +67,8 @@ Contact the Integration team to get an access.
 Orange Openlab
 --------------
 
-This lab is a community use lab. It is always provided the last stable version,
-so the frankfurt release during Guilin release time.
+This lab is for community use. It is always provided with the last stable version,
+i.e. Frankfurt release during Guilin development time.
 Please note that such labs do not provide admin rights and is shared with all
 the users. It can be used to discover ONAP.
 
diff --git a/docs/integration-repositories.rst b/docs/integration-repositories.rst
index 17b59710b..211f2d39e 100644
--- a/docs/integration-repositories.rst
+++ b/docs/integration-repositories.rst
@@ -49,7 +49,7 @@ Integration
 -----------
 
 The integration repository is the historical repository.
-As a consequence it includes several elements in the same reppository:
+As a consequence it includes several elements in the same repository:
 
 - Deployment scripts (deployment directory)
 - Tests: the first non robot tests (security, vCPE,..)
@@ -79,10 +79,10 @@ rather than systematically re-inventing the wheel.
 Testsuite
 ---------
 
-The testsuite repository and it sub repositories deal excelusively with tests.
+The testsuite repository and its sub repositories deal exclusively with tests.
 
 The testsuite repository includes all the robotframework scripts.
-The robot pod that can be installed as part of the ONAP cluster is build from
+The robot pod that can be installed as part of the ONAP cluster is built from
 this repository.
 
 Several tooling repositories are associated with the robot tests (heatbridge,
@@ -126,7 +126,7 @@ Oparent
 External repositories
 ---------------------
 
-Additionnaly, the Integration team also deals with external gitlab.com
+Additionally, the Integration team also deals with external gitlab.com
 repositories.
 
 .. csv-table:: Integration external repositories table
@@ -135,8 +135,8 @@ repositories.
     :delim: ;
     :header-rows: 1
 
-The python-onapsdk has been developped out of ONAP as gitlab provided more
-enhanced built-in features for this kind of developments.
+The python-onapsdk has been developed outside of ONAP as gitlab provided more
+enhanced built-in features for this kind of development.
 
 The xtesting-onap repository is also hosted in gitlab.com as the CD part of
 Integration work is based on public gitlab-ci chains.
diff --git a/docs/integration-resources.rst b/docs/integration-resources.rst
index 0ae3e7013..403ea9d71 100644
--- a/docs/integration-resources.rst
+++ b/docs/integration-resources.rst
@@ -33,7 +33,7 @@ Integration Test database
 -------------------------
 
 The integration team shares a Test Result Database with the OPNFV project. All
-the test results of the CD are automatically pushed in this database.
+the test results of the CD are automatically pushed to this database.
 It is possible to retrieve the results through the Test API associated with this
 test Database.
 
@@ -51,14 +51,14 @@ lab, period, last, CI id,..)
 See the `OPNFV test API documentation <https://wiki.opnfv.org/pages/viewpage.action?pageId=2926452>`__.
 
 Any company running ONAP Integration tests can be referenced to push their results
-in this database.
+to this database.
 This Database is hosted on a LF OPNFV server. Results are backuped daily.
 Integration committers can have access to this server.
 
 VNF demo Artifacts
 ------------------
 
-They are hosted in the demo repositories and published in
+VNF demo artifacts are hosted in the demo repositories and published in
 https://nexus.onap.org/content/repositories/releases/org/onap/demo/vnf/.
 
 Simulators
diff --git a/docs/integration-tests.rst b/docs/integration-tests.rst
index be3a04c7b..045a44063 100644
--- a/docs/integration-tests.rst
+++ b/docs/integration-tests.rst
@@ -6,21 +6,21 @@ Tests
 =====
 
 .. important::
-   Integration is in charged of several types of tests:
+   Integration is in charge of several types of tests:
 
-   - Use Cases: developped by use case teams, usually complex, demonstrating high value capabilities ofr ONAP. They may be partially automated and even
+   - Use Cases: developed by use case teams, usually complex, demonstrating high value capabilities of ONAP. They may be partially automated and even
      integrated in CD.
    - CSIT Tests: functional tests created by the projects, partially hosted in CSIT repository
-   - Automatic Test Cases: these use cases are usually more simple and aims to validate that ONAP is working properly.
+   - Automatic Test Cases: these use cases are usually more simple and aim to validate that ONAP is working properly.
      These tests have been developed to validate ONAP as a software solution.
-     In theory all the main function shall be covered by such tests in order to have more robust CI/CD and then avoid regressions.
+     In theory all the main functions shall be covered by such tests in order to have more robust CI/CD and then avoid regressions.
      These tests are usually developed and maintained by the integration team.
 
-We may also indicate that when the development of the test framework python-onapsk
-follows standard developement quality rules and imposes the creation of
+We may also indicate that when the development of the test framework python-onapsdk
+follows standard development quality rules and imposes the creation of
 unit/functional/integration tests.
 As an example python-onapsdk requires a unit test coverage of 98% before merging
-a new feature, which is far above the project criteria in SonarCLoud today.
+a new feature, which is far above the project criteria in SonarCloud today.
 
 Use Cases
 ---------
@@ -31,16 +31,16 @@ CSIT Tests
 ----------
 
 The CSIT tests are functional tests executed by the projects on mocked
-environement to validate their components.
+environment to validate their components.
 Historically it was hosted in a CSIT repository.
 
-Integration team invited the projects to bring back such tests bacdk to home
+Integration team invited the projects to bring back such tests back to home
 repository for 2 main reasons:
 
 - integration cannot be a bottleneck: +2/merge from integration needed for each
   project
-- most of the tests are abandonned and not maintained when hosted in a third party
-  repository leading to  CI/CD time waste and misleading test reporting
+- most of the tests are abandoned and not maintained when hosted in a third party
+  repository leading to CI/CD resource waste and misleading test reporting
 
 In Guilin a PoC to help the project to re-insource their functional tests have
 been initiated.
@@ -58,7 +58,7 @@ They are all embedded in `xtesting <https://pypi.org/project/xtesting/>`__ docke
 .. hint::
    Automatic tests are currently divided in 4 different categories:
 
-   - infrastructure-healthcheck: tests from OOM checking the ONAP namespace, certificates,..
+   - infrastructure-healthcheck: tests from OOM checking the ONAP namespace, certificates...
    - healthcheck: basic tests on components
    - smoke tests: end to end tests
    - security tests
@@ -94,7 +94,7 @@ in order to collect the logs of the different components during the test executi
 
 .. figure:: files/tests/test-onap-k8s.png
 
-Healhcheck Tests
+Healthcheck Tests
 ................
 
 .. csv-table:: Healthcheck Tests