diff --git a/VERSION b/VERSION
index b52282a..1a285c3 100755
--- a/VERSION
+++ b/VERSION
@@ -1 +1 @@
-2.10.4
+2.10.5
diff --git a/overview/architecture_overview.rst b/overview/architecture_overview.rst
index acb49e0..49e2729 100644
--- a/overview/architecture_overview.rst
+++ b/overview/architecture_overview.rst
@@ -76,7 +76,7 @@
       of the system. An opensource implementation exists in the form of the `open-olt-adapter <https://github.com/opencord/voltha-openolt-adapter>`_) which uses
       gRPC and the `openolt.proto <https://github.com/opencord/voltha-protos/blob/master/protos/voltha_protos/openolt.proto>`_
       API as its means of communication to the ``open-olt-agent``. Closed source adapter
-      that use different SB protocols to the device, such as NETCONF, have been have been proven to work with VOLTHA
+      that use different SB protocols to the device, such as NETCONF, have been proven to work with VOLTHA
       with no changes required to the system.
     - ``ONU Adapter``. The ONU adapter is responsible for all the interactions and commands towards the ONU via OMCI,
       such as discovery, MIB upload, ME configuration, T-CONT and GEM port configuration and so on.
diff --git a/overview/lab_setup.rst b/overview/lab_setup.rst
index fd24d1a..47e8921 100644
--- a/overview/lab_setup.rst
+++ b/overview/lab_setup.rst
@@ -303,10 +303,10 @@
 Configuration for in-band OLT control
 -------------------------------------
 
-If OLT is being used in in-band connectivity mode, the
+If OLT is being used in in-band connectivity mode, this
 `document <https://docs.google.com/document/d/1OKDJCPEFVTEythAFUS_I7Piew4jHmhk25llK6UF04Wg>`_
 details the configuration aspects in ONOS and the aggregation switch to
-trunk/switch in-band packets from the OLT to BNG or Voltha.
+trunk/switch in-band packets from the OLT to BNG or VOLTHA.
 
 In-band OLT software upgrade
 -------------------------------------
diff --git a/release_notes/release_process.rst b/release_notes/release_process.rst
index 90ccc97..63be3af 100644
--- a/release_notes/release_process.rst
+++ b/release_notes/release_process.rst
@@ -12,12 +12,13 @@
 ``voltha-2.3``, etc.  The rest of this section will use the ``voltha-2.3``
 release as an example:
 
-A branch named ``voltha-2.3`` is created on the voltha-helm-charts repo.  Release
-candidates will be created of each chart for the ``2.3`` release. The action that
-indicates the creation of the ``2.3`` release is to changing the `voltha
+A branch named ``voltha-2.3`` is created on the voltha-helm-charts repo.
+Release candidates will be created of each chart for the ``2.3`` release.
+The action that indicates the creation of the ``2.3`` release is to changing
+the `voltha
 <https://gerrit.opencord.org/gitweb?p=voltha-helm-charts.git;a=tree;f=voltha>`_
-helm chart, and adapter charts with version: ``2.3.0`` specified in ``Chart.yaml``
-within the `voltha-helm-charts
+helm chart, and adapter charts with version: ``2.3.0`` specified in
+``Chart.yaml`` within the `voltha-helm-charts
 <https://gerrit.opencord.org/gitweb?p=voltha-helm-charts.git;a=summary>`_ repo.
 
 Accompanying tests for 2.3 are created by creating a branch created named
@@ -25,7 +26,7 @@
 <https://gerrit.opencord.org/gitweb?p=voltha-system-tests.git;a=summary>`_
 repo. At release we create a tag ``2.3.0`` on that branch.
 
-These two repos are the only ones that receive a ``2.3.0`` tag. Other repos that
+These two repos are the only ones receiving a ``2.3.0`` tag. Other repos that
 contain individual components have their own versioning/release cadence, driven
 by SemVer.
 
@@ -87,7 +88,8 @@
 
 Process to create a change on a stable branch
 
-- Add a Jira item, with the ``Affects Version: ``VOLTHA vX.X`` set
+- Create a jira ticket for the problem and document the ``Affects Version/s:``
+  - field with affected version(s) ``VOLTHA vX.X``.
 - Discuss and get consensus on the issue via the Voltha mailing list, in the
   all-Voltha meeting, or on Slack about whether this fix should be brought to a
   stable branch
@@ -112,11 +114,10 @@
 
 API Deprecation policy
 ----------------------
-
-VOLTHA has in place a 2 release deprecation policy. Starting from ``voltha-2.9`` the APIs that are marked as deprecated
-are automatically removed after 2 releases.
-As an example an API marked as deprecated in ``voltha-2.9`` will be removed after the ``voltha-2.10`` release
-and will not be present anymore in ``voltha-2.11``.
+VOLTHA supports 2 release deprecation policy. Starting from ``voltha-2.9``
+the APIs that are marked as deprecated are automatically removed.
+For example an API marked as deprecated in ``voltha-2.9`` will be removed after
+the ``voltha-2.10`` release and will not be present anymore in ``voltha-2.11``.
 
 The removal process is intended to happen automatically, meaning no further notice of removal needs to be sent out.
 The deprecated objects and APIs are marked in the `voltha-protos <https://github.com/opencord/voltha-protos>`_ using the