diff --git a/CONTRIBUTING.rst b/CONTRIBUTING.rst
new file mode 100644
index 0000000000..2c4d6c5022
--- /dev/null
+++ b/CONTRIBUTING.rst
@@ -0,0 +1,19 @@
+The source repository for this project can be found at:
+
+ https://opendev.org/openstack/kolla
+
+Pull requests submitted through GitHub are **not** monitored.
+
+To start contributing to OpenStack, follow the steps in the contribution guide
+to set up and use Gerrit:
+
+ https://docs.openstack.org/contributors/code-and-documentation/quick-start.html
+
+Bugs should be filed on Launchpad:
+
+ https://bugs.launchpad.net/kolla
+
+For more specific information about contributing to this repository, see the
+Kolla contributor guide:
+
+ https://docs.openstack.org/kolla/latest/contributor/contributing.html
diff --git a/doc/source/contributor/CONTRIBUTING.rst b/doc/source/contributor/CONTRIBUTING.rst
deleted file mode 100644
index b598178bc8..0000000000
--- a/doc/source/contributor/CONTRIBUTING.rst
+++ /dev/null
@@ -1,136 +0,0 @@
-=================
-How To Contribute
-=================
-
-Basics
-======
-
-#. Our source code is hosted on `OpenDev Kolla Git
- `_. Bugs should be filed on
- `launchpad `_.
-
-#. Please follow OpenStack `Gerrit Workflow
- `__
- to contribute to Kolla.
-
-#. Note the branch you're proposing changes to. ``master`` is the current focus
- of development. Kolla project has a strict policy of only allowing backports
- in ``stable/branch``, unless when not applicable. A bug in a
- ``stable/branch`` will first have to be fixed in ``master``.
-
-#. Please file a `blueprint of kolla `__
- for any significant code change and a bug
- for any significant bug fix. See how to reference a bug or a blueprint in
- the `commit message `_.
- For simple changes, contributors may optionally add the text "TrivialFix" to
- the commit message footer to indicate to reviewers a bug is not required.
-
-#. We use a `whiteboard `__
- to keep track of CI gate status, release status, stable backports, planning
- and feature development status.
-
-Please use the existing sandbox repository, available at `sandbox
-`_,
-for learning, understanding and testing the `Gerrit Workflow
-`_.
-
-Adding a release note
-=====================
-
-Kolla uses the following release notes sections:
-
-- ``features`` --- for new features or functionality; these should ideally
- refer to the blueprint being implemented;
-- ``fixes`` --- for fixes closing bugs; these must refer to the bug being
- closed;
-- ``upgrade`` --- for notes relevant when upgrading from previous version;
- these should ideally be added only between major versions; required when
- the proposed change affects behaviour in a non-backwards compatible way or
- generally changes something impactful;
-- ``deprecations`` --- to track deprecated features; relevant changes may
- consist of only the commit message and the release note;
-- ``prelude`` --- filled in by the PTL before each release or RC.
-
-Other release note types may be applied per common sense.
-Each change should include a release note unless being a ``TrivialFix``
-change or affecting only docs or CI. Such changes should `not` include
-a release note to avoid confusion.
-Remember release notes are mostly for end users which, in case of Kolla,
-are OpenStack administrators/operators.
-In case of doubt, the core team will let you know what is required.
-
-To add a release note, run the following command:
-
-.. code-block:: console
-
- tox -e venv -- reno new
-
-All release notes can be inspected by browsing ``releasenotes/notes``
-directory.
-
-To generate release notes in HTML format in ``releasenotes/build``, run:
-
-.. code-block:: console
-
- tox -e releasenotes
-
-Note this requires the release note to be tracked by ``git`` so you
-have to at least add it to the ``git``'s staging area.
-
-Adding a new service
-====================
-
-Kolla aims to both containerise and deploy all services within the OpenStack
-ecosystem. This is a constantly moving target as the ecosystem grows, so these
-guidelines aim to help make adding a new service to Kolla a smooth experience.
-
-The image
----------
-
-Kolla follows `Best practices for writing Dockerfiles
-`__
-when designing and implementing services where at all possible.
-
-We use ``jinja2`` templating syntax to help manage the volume and complexity
-that comes with maintaining multiple Dockerfiles for multiple different base
-operating systems.
-
-Images should be created under the ``docker`` directory. OpenStack services
-should inherit from the provided ``openstack-base`` image, while supporting and
-infrastructure services (for example, mongodb) should inherit from ``base``.
-
-Services consisting of only one service should be placed in an image named the
-same as that service, for example, ``horizon``. Services that consist of
-multiple processes generally use a base image and child images, for example,
-``glance-base``, ``glance-api``, and ``glance-registry``.
-
-Jinja2 'blocks' are employed throughout the Dockerfile's to help operators
-customise various stages of the build (refer to :ref:`Dockerfile Customisation
-`)
-
-Some of these blocks are free form however, there are a subset that should be
-common to every Dockerfile. The overall structure for a multi container service
-is as follows:
-
-.. code-block:: console
-
- FROM {{ namespace }}/{{ image_prefix }}openstack-base:{{ tag }}
- LABEL maintainer="{{ maintainer }}" name="{{ image_name }}" build-date="{{ build_date }}"
-
- {% block << service >>_header %}{% endblock %}
-
- {% import "macros.j2" as macros with context %}
-
- << binary specific steps >>
-
- << source specific steps >>
-
- << common steps >>
-
- {% block << service >>_footer %}{% endblock %}
- {% block footer %}{% endblock %}
-
-.. note::
-
- The generic footer block ``{% block footer %}{% endblock %}`` should not be
- included in base images (for example, glance-base).
diff --git a/doc/source/contributor/adding-a-new-image.rst b/doc/source/contributor/adding-a-new-image.rst
new file mode 100644
index 0000000000..db3f19b503
--- /dev/null
+++ b/doc/source/contributor/adding-a-new-image.rst
@@ -0,0 +1,52 @@
+==================
+Adding a new image
+==================
+
+Kolla follows `Best practices for writing Dockerfiles
+`__
+where at all possible.
+
+We use ``jinja2`` templating syntax to help manage the volume and complexity
+that comes with maintaining multiple Dockerfiles for multiple different base
+operating systems.
+
+Images should be created under the ``docker`` directory. OpenStack services
+should inherit from the provided ``openstack-base`` image, and
+infrastructure services (for example: ``fluentd``) should inherit from
+``base``.
+
+Projects consisting of only one service should be placed in an image named the
+same as that service, for example: ``horizon``. Services that consist of
+multiple processes generally use a base image and child images, for example:
+``cinder-base``, ``cinder-api``, ``cinder-scheduler``, ``cinder-volume``,
+``cinder-backup``.
+
+Jinja2 `blocks` are employed throughout the Dockerfiles to help operators
+customise various stages of the build (refer to :ref:`Dockerfile Customisation
+`)
+
+Some of these blocks are free form. However, there is a subset that should be
+common to every Dockerfile. The overall structure is as follows:
+
+.. code-block:: console
+
+ FROM {{ namespace }}/{{ image_prefix }}openstack-base:{{ tag }}
+ LABEL maintainer="{{ maintainer }}" name="{{ image_name }}" build-date="{{ build_date }}"
+
+ {% block << service >>_header %}{% endblock %}
+
+ {% import "macros.j2" as macros with context %}
+
+ << binary specific steps >>
+
+ << source specific steps >>
+
+ << common steps >>
+
+ {% block << service >>_footer %}{% endblock %}
+ {% block footer %}{% endblock %}
+
+.. note::
+
+ The generic footer block ``{% block footer %}{% endblock %}`` should **not** be
+ included in base images (for example: ``cinder-base``).
diff --git a/doc/source/contributor/contributing.rst b/doc/source/contributor/contributing.rst
new file mode 100644
index 0000000000..264e1b86e1
--- /dev/null
+++ b/doc/source/contributor/contributing.rst
@@ -0,0 +1,125 @@
+============================
+So You Want to Contribute...
+============================
+
+For general information on contributing to OpenStack, please check out the
+`contributor guide `_ to get started.
+It covers all the basics that are common to all OpenStack projects: the
+accounts you need, the basics of interacting with our Gerrit review system,
+how we communicate as a community, etc.
+
+Below will cover the more project specific information you need to get started
+with Kolla.
+
+Basics
+~~~~~~
+
+The source repository for this project can be found at:
+
+ https://opendev.org/openstack/kolla
+
+Communication
+~~~~~~~~~~~~~
+
+IRC Channel
+ ``#openstack-kolla`` (`channel logs`_) on Freenode
+
+Weekly Meetings
+ On Wednesdays at 15:00 UTC in the IRC channel (`meetings logs`_)
+
+Mailing list (prefix subjects with ``[kolla]``)
+ http://lists.openstack.org/pipermail/openstack-discuss/
+
+Meeting Agenda
+ https://wiki.openstack.org/wiki/Meetings/Kolla
+
+Whiteboard (etherpad)
+ Keeping track of CI gate status, release status, stable backports,
+ planning and feature development status.
+ https://etherpad.openstack.org/p/KollaWhiteBoard
+
+.. _channel logs: http://eavesdrop.openstack.org/irclogs/%23openstack-kolla/
+.. _meetings logs: http://eavesdrop.openstack.org/meetings/kolla/
+
+Contacting the Core Team
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+The list in alphabetical order (on first name):
+
++-----------------------+---------------+------------------------------------+
+| Name | IRC nick | Email address |
++=======================+===============+====================================+
+| `Christian Berendt`_ | berendt | berendt@betacloud-solutions.de |
++-----------------------+---------------+------------------------------------+
+| `Dincer Celik`_ | osmanlicilegi | hello@dincercelik.com |
++-----------------------+---------------+------------------------------------+
+| `Eduardo Gonzalez`_ | egonzalez | dabarren@gmail.com |
++-----------------------+---------------+------------------------------------+
+| `Jeffrey Zhang`_ | Jeffrey4l | jeffrey.zhang@99cloud.net |
++-----------------------+---------------+------------------------------------+
+| `Marcin Juszkiewicz`_ | hrw | marcin.juszkiewicz@linaro.org |
++-----------------------+---------------+------------------------------------+
+| `Mark Goddard`_ | mgoddard | mark@stackhpc.com |
++-----------------------+---------------+------------------------------------+
+| `Michał Nasiadka`_ | mnasiadka | mnasiadka@gmail.com |
++-----------------------+---------------+------------------------------------+
+| `Radosław Piliszek`_ | yoctozepto | radoslaw.piliszek@gmail.com |
++-----------------------+---------------+------------------------------------+
+| `Surya Prakash`_ | spsurya | singh.surya64mnnit@gmail.com |
++-----------------------+---------------+------------------------------------+
+| `Cao Yuan`_ | caoyuan | cao.yuan@99cloud.net |
++-----------------------+---------------+------------------------------------+
+
+.. _Christian Berendt: https://launchpad.net/~berendt
+.. _Dincer Celik: https://launchpad.net/~osmanlicilegi
+.. _Eduardo Gonzalez: https://launchpad.net/~egonzalez90
+.. _Jeffrey Zhang: https://launchpad.net/~jeffrey4l
+.. _Marcin Juszkiewicz: https://launchpad.net/~hrw
+.. _Mark Goddard: https://launchpad.net/~mgoddard
+.. _Michał Nasiadka: https://launchpad.net/~mnasiadka
+.. _Radosław Piliszek: https://launchpad.net/~yoctozepto
+.. _Surya Prakash: https://launchpad.net/~confisurya
+.. _Cao Yuan: https://launchpad.net/~caoi-yuan
+
+The current effective list is also available from Gerrit:
+https://review.opendev.org/#/admin/groups/460,members
+
+New Feature Planning
+~~~~~~~~~~~~~~~~~~~~
+
+New features are discussed via IRC or mailing list (with [kolla] prefix).
+Kolla project keeps blueprints in `Launchpad `__.
+Specs are welcome but not strictly required.
+
+Task Tracking
+~~~~~~~~~~~~~
+
+Kolla project tracks tasks in `Launchpad `__.
+Note this is the same place as for bugs.
+
+If you're looking for some smaller, easier work item to pick up and get started
+on, search for the 'low-hanging-fruit' tag.
+
+A more lightweight task tracking is done via etherpad - `Whiteboard `__.
+
+Reporting a Bug
+~~~~~~~~~~~~~~~
+
+You found an issue and want to make sure we are aware of it? You can do so
+on `Launchpad `__.
+Note this is the same place as for tasks.
+
+Getting Your Patch Merged
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Most changes proposed to Kolla require two +2 votes from core reviewers before
++W. A release note is required on most changes as well. Release notes policy
+is described in :ref:`its own section `.
+
+Significant changes should have documentation and testing provided with them.
+
+Project Team Lead Duties
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+All common PTL duties are enumerated in the `PTL guide `_.
+Kolla-specific PTL duties are listed in `Kolla PTL guide `_.
diff --git a/doc/source/contributor/index.rst b/doc/source/contributor/index.rst
index 40c5b0d190..6e49472375 100644
--- a/doc/source/contributor/index.rst
+++ b/doc/source/contributor/index.rst
@@ -12,7 +12,9 @@ We welcome everyone to join our project!
.. toctree::
:maxdepth: 2
- CONTRIBUTING
+ contributing
+ adding-a-new-image
+ release-notes
running-tests
bug-triage
ptl-guide
diff --git a/doc/source/contributor/release-notes.rst b/doc/source/contributor/release-notes.rst
new file mode 100644
index 0000000000..854fc88fc1
--- /dev/null
+++ b/doc/source/contributor/release-notes.rst
@@ -0,0 +1,45 @@
+.. _release-notes:
+
+=============
+Release notes
+=============
+
+Kolla uses the following release notes sections:
+
+- ``features`` --- for new features or functionality; these should ideally
+ refer to the blueprint being implemented;
+- ``fixes`` --- for fixes closing bugs; these must refer to the bug being
+ closed;
+- ``upgrade`` --- for notes relevant when upgrading from previous version;
+ these should ideally be added only between major versions; required when
+ the proposed change affects behaviour in a non-backwards compatible way or
+ generally changes something impactful;
+- ``deprecations`` --- to track deprecated features; relevant changes may
+ consist of only the commit message and the release note;
+- ``prelude`` --- filled in by the PTL before each release or RC.
+
+Other release note types may be applied per common sense.
+Each change should include a release note unless being a ``TrivialFix``
+change or affecting only docs or CI. Such changes should `not` include
+a release note to avoid confusion.
+Remember release notes are mostly for end users which, in case of Kolla,
+are OpenStack administrators/operators.
+In case of doubt, the core team will let you know what is required.
+
+To add a release note, run the following command:
+
+.. code-block:: console
+
+ tox -e venv -- reno new
+
+All release notes can be inspected by browsing ``releasenotes/notes``
+directory.
+
+To generate release notes in HTML format in ``releasenotes/build``, run:
+
+.. code-block:: console
+
+ tox -e releasenotes
+
+Note this requires the release note to be tracked by ``git`` so you
+have to at least add it to the ``git``'s staging area.