diff --git a/release-notes/release_process.rst b/release-notes/release_process.rst
new file mode 100644
index 0000000..632dd7e
--- /dev/null
+++ b/release-notes/release_process.rst
@@ -0,0 +1,158 @@
+Release Process
+===============
+
+This document describes the technical steps to create a new release of VOLTHA.
+
+Creating the initial release
+----------------------------
+
+A release branch name is decided on, where all tagged releases will be created
+in each repo. Historically this has been ``voltha`` followed by the Major and
+Minor `Semver <https://semver.org/>`_ version, such as ``voltha-2.2``,
+``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
+<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
+<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
+``voltha-2.3`` on the `voltha-system-tests
+<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
+contain individual components have their own versioning/release cadence, driven
+by SemVer.
+
+For all other repos that create components that go into the release, tags will
+be created and ``voltha-2.3`` branches are created starting from the tag.
+
+To allow for future patches to go into the repo in a way that does not conflict
+with the patch version, each component repo's ``VERSION`` file should have it's
+Minor version increased. (ex: ``1.1.x`` to ``1.2.0-dev``, so future ``1.1.x+1``
+component release can easily be created).
+
+Testing CI jobs will be created that check out the voltha-2.3 branch of the
+`voltha-system-tests
+<https://gerrit.opencord.org/gitweb?p=voltha-system-tests.git;a=summary>`_
+repo, testing the charts as checked out with the ``voltha-2.3`` branch of
+``voltha-helm-charts``.  Patches on the ``voltha-2.3`` branch of components
+that build containers will need to be changed to rebuild those containers and
+test with the ``voltha-2.3`` branch of helm charts.
+
+Creating point releases on a stable branch
+------------------------------------------
+
+If a fix is only needed to the helm charts:
+
+- Make the fix on the master branch of voltha-helm-charts (assuming that it is
+  required in both places).
+
+- After the master tests pass, manually cherry-pick the fix to the voltha-2.3
+  branch (the Chart.yaml version would be different, requiring the manual
+  step).
+
+- Cherry-picked patchsets on that branch will be checked by the voltha-2.3
+  branch of tests.
+
+- When it passes, submitting the change will make a new 2.3.x release
+
+If a fix is needed to the components/containers that are included by the helm
+charts:
+
+- Develop a fix to the issue on the master branch, get it approved after
+  passing master tests.
+
+- Manually cherry-pick to the voltha-2.3 branch of the component, incrementing
+  the patch version, and test with the voltha-2.3 version of
+  voltha-system-tests and helm charts.
+
+- Update helm charts and go through the helm chart update process above.
+
+
+What changes can be brought into a stable branch?
+-------------------------------------------------
+
+For a change to be suitable for a stable branch, it has to be either a:
+
+- Bug
+- Non-code fix (documentation, build process)
+- Security or compatibility updates (problem found in a dependency, upstream
+  software EOL, etc.)
+
+Process to create a change on a stable branch
+
+- Add a Jira item, with the ``Affects Version: ``VOLTHA vX.X`` set
+- 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
+- Create a fix, and go through the integration process to create a new point
+  release.
+
+What is a bug?
+""""""""""""""
+
+- Anything that causes a functional regression test (Robot tests) to fail
+- Not a new feature!
+- Severe issue (causes data loss or crash), or frequently occurring are
+  generally more likely to be accepted.
+- Issues that are merely annoying and don't cause data loss or a crash, or
+  happen very infrequently or can't be reproduced may not be.
+
+As a best practice, please add tests when bugs are found, if tests don't
+currently cover the particular bug. Examples:
+
+- Robot tests for integration-related issues
+- Unit tests for code-level issues
+
+
+Repos branched for each release
+-------------------------------
+
+Charts
+""""""
+
+- voltha-helm-charts
+
+Testing
+"""""""
+
+- voltha-system-tests
+
+Tools
+"""""
+
+- bbsim (also creates containers)
+- voltctl
+
+ONOS Apps
+"""""""""
+
+- aaa
+- dhcpl2relay
+- igmp
+- kafka
+- mcast
+- olt
+- sadis
+
+Libraries
+"""""""""
+
+- pyvoltha
+- voltha-lib-go
+- voltha-protos
+
+Components (which build containers)
+"""""""""""""""""""""""""""""""""""
+- ofagent-go
+- voltha-go (rw_core)
+- voltha-openolt-adapter
+- voltha-openonu-adapter
+- voltha-onos (includes ONOS Apps)
+
diff --git a/release-notes/voltha-2.2.rst b/release-notes/voltha-2.2.rst
new file mode 100644
index 0000000..7d029a6
--- /dev/null
+++ b/release-notes/voltha-2.2.rst
@@ -0,0 +1,79 @@
+VOLTHA 2.2 Release Notes
+========================
+
+Highlights
+----------
+
+Started the SEBA Surge effort to get VOLTHA 2.x in production by AT&T, DT, and
+TT. VOLTHA 2.2 release is a stepping stone towards that goal. Main highlights
+of this release include the work done for stabilizing VOLTHA and creating test
+infrastructure.
+
+Core
+----
+- Simplified VOLTHA stack: https://docs.google.com/presentation/d/1pPJFG1NIDQGSla_Sn1Jx4xqDXO9uEEhwgTegZEB6JK0/edit
+
+Development process
+-------------------
+
+- kind-voltha used to bring up development/testing
+- voltctl CLI replaces CLI container
+- Supports AT&T workflow
+- Moved to BAL 3.1 (from BAL 2.6 in VOLTHA 1.7 and 2.1 releases)
+- 7 active brigades
+
+Testing
+-------
+
+- Expanded set of Test Cases: https://docs.google.com/spreadsheets/d/1TOSibGWXOAYOVeT0UwcivFRMm3oQzSdcpRG5E9_WTbQ/edit
+- Patchset sanity testing with emulated hardware (BBSim)
+- Ability to submit patchsets for test on physical hardware (hardware test keyword in gerrit)
+- Nightly regression suite on hardware growing
+- New BBSim used for functional testing and scale testing
+- BBSim Reflector (BBR) to verify BBSim itself scales
+
+Documentation
+-------------
+
+- Operator Workflows Defined: https://docs.google.com/presentation/d/1FP42UviD9Ln-Pjrho5cEOT4mxD1SjszjJUD1MA3jdKY/edit
+- Several Design docs published: https://drive.google.com/drive/u/1/folders/1sNbD1oMA1twG4Kqn2e77ExzXR81qC6LK
+
+Known Issues
+------------
+
+- | This release does not support Tech Profiles other than 1 TCONT,
+  | 1 GEM port, due to issues in BAL 3.1 (VOL-2104, VOL-2105). A move to BAL 3.4 is required.
+- A scenario in the AT&T workflow results in errors (see VOL-2395)
+
+Component Versions
+------------------
+
+- ONOS: 1.13.9, with app versions:
+    - olt: 3.0.1
+    - sadis: 3.1.0
+    - aaa: 1.9.0
+    - dhcpl2relay: 1.6.1
+    - kafka: 1.1.0
+
+- VOLTHA component versions
+    - helm charts
+        - voltha: 2.2.0
+        - adapter-openolt 2.2.0
+        - adapter-openonu 2.2.0
+        - onos: 1.1.4
+    - Containers
+        - voltha-rw-core: 2.2.3
+        - voltha-of-agent: 2.2.3
+        - voltha-openolt-adapter: 2.2.5
+        - voltha-openonu-adapter: 2.2.6
+        - voltha-onos: 2.2.0
+
+- BBSim
+    - helm charts: 3.0.7
+    - container: 0.0.9
+
+- OpenOLT Agent using BAL 3.1 (voltha-2.2)
+    - openolt_2_2_0_asfvolt16.deb (available from EdgeCore site)
+    - | Get access credentials for https://edgecore.quickconnect.to and then login and navigate to File_Station ->
+      | EdgecoreNAS, and then the folder /ASXvOLT16/OpenOLT_Agent/From_ONF_Distribution/ and pick the version above
+
diff --git a/release-notes/voltha-2.3.rst b/release-notes/voltha-2.3.rst
new file mode 100644
index 0000000..131cb05
--- /dev/null
+++ b/release-notes/voltha-2.3.rst
@@ -0,0 +1,71 @@
+VOLTHA 2.3 Release Notes
+========================
+
+Highlights
+----------
+
+
+Core
+----
+
+
+Development process
+-------------------
+
+
+Testing
+-------
+
+
+Documentation
+-------------
+
+
+Known Issues
+------------
+
+
+Component Versions
+------------------
+
+**Helm Charts**
+
+Git repo: `voltha-helm-charts <https://gerrit.opencord.org/gitweb?p=voltha-helm-charts.git;a=tree;h=refs/heads/voltha-2.3>`_
+
+voltha ``2.3.1`` with container images:
+
+- voltha-rw-core: ``2.3.6``
+- voltha-ofagent-go: ``1.1.6``
+
+voltha-adapter-openolt: ``2.3.0`` with container image voltha-openolt-adapter: ``2.3.21``
+
+voltha-adapter-openonu ``2.3.0`` with container image voltha-openonu-adapter: ``2.3.6``
+
+voltha-onos: ``3.0.1`` using container image ``4.0.2``
+
+bbsim: ``3.0.18`` using container image: ``0.1.0``
+
+**ONOS**
+
+Version: ``2.2.2``
+
+App versions:
+
+- aaa: ``2.0.2``
+- dhcpl2relay: ``2.0.2``
+- igmpproxy: ``2.0.0``
+- kafka: ``2.2.0``
+- mcast: ``2.0.0``
+- olt: ``4.0.2``
+- sadis: ``5.0.1``
+
+**BBSim**
+
+- container: ``0.1.0``
+
+**OpenOLT Agent** ``2.3.0`` using ``BAL 3.2.3.2`` SDK
+
+- ``openolt_2_3_0_asfvolt16.deb`` (available from EdgeCore site)
+- Get access credentials for https://edgecore.quickconnect.to and then login
+  and navigate to File_Station -> EdgecoreNAS, and then the folder
+  /ASXvOLT16/OpenOLT_Agent/From_ONF_Distribution/ and pick the version above