diff --git a/docs/finn/developers.rst b/docs/finn/developers.rst
new file mode 100644
index 0000000000000000000000000000000000000000..6e7fa0d920a943e468fd70464b050ab74cf8ec7d
--- /dev/null
+++ b/docs/finn/developers.rst
@@ -0,0 +1,195 @@
+***********************
+Developer documentation
+***********************
+
+.. note:: **This page is under construction.**
+
+This page is intended to serve as a starting point for new FINN developers.
+Power users may also find this information useful.
+
+Getting started
+================
+
+Before starting to do development on FINN it's a good idea to start
+with understanding the basics as a user. Going through all of the
+:ref:`tutorials` is strongly recommended if you haven' already done so.
+Additionally, please review the documentation available on :ref:`internals`.
+
+Repository structure
+=====================
+
+.. image:: img/repo-structure.png
+   :scale: 70%
+   :align: center
+
+The figure above gives a description of the repositories used by the
+FINN project, and how they are interrelated.
+
+Branching model
+===============
+
+All of the FINN repositories mentioned above use a variant of the
+GitHub flow from https://guides.github.com/introduction/flow as
+further detailed below:
+
+* The `master` or `main` branch contains the latest released
+  version, with a version tag.
+
+* The `dev` branch is where new feature branches get merged after
+  testing. `dev` is "almost ready to release" at any time, and is
+  tested with nightly Jenkins builds -- including all unit tests
+  and end-to-end tests.
+
+* New features or fixes are developed in branches that split from
+  `dev` and are named similar to `feature/name_of_feature`.
+  Single-commit fixes may be made without feature branches.
+
+* New features must come with unit tests and docstrings. If
+  applicable, it must also be tested as part of an end-to-end flow,
+  preferably with a new standalone test. Make sure the existing
+  test suite (including end-to-end tests) still pass.
+  When in doubt, consult with the FINN maintainers.
+
+* When a new feature is ready, a pull request (PR) can be opened
+  targeting the `dev` branch, with a brief description of what the
+  PR changes or introduces.
+
+* Larger features must be broken down into several, smaller PRs. If
+  your PRs have dependencies on each other please state in which order
+  they should be reviewed and merged.
+
+Docker images
+===============
+
+If you want to add new dependencies (packages, repos) to FINN it's
+important to understand how we handle this in Docker.
+There are currently two Docker images used in FINN:
+
+* The finn.dev image, used for deploying and developing the FINN compiler. Details described below.
+* The finn.ci image, which is used for continuous integration testing. Almost identical to finn.dev image, key differences are no user setup and fewer packages installed (e.g. no Jupyter).
+
+The finn.dev image is built and launched as follows:
+
+1. run-docker.sh launches the build of the Docker image with `docker build`
+
+2. Docker image is built from docker/Dockerfile.finn_dev using the following steps:
+
+  * Base: PyTorch dev image
+  * Set up apt dependencies: apt-get install a few packages for verilator and
+  * Set up pip dependencies: Python packages FINN depends on are listed in requirements.txt, which is copied into the container and pip-installed. Some additional packages (such as Jupyter and Netron) are also installed.
+  * Do user setup: Switch to the same user running the container to avoid running as root.
+  * Clone dependency repos: These include Brevitas, finn-hlslib, finn-base, pyverilator and oh-my-xilinx. The correct commit version will be checked out by the entrypoint script.
+  * Install XRT deps, if needed: For Vitis builds we need to install the extra dependencies for XRT. This is only triggered if the image is built with the INSTALL_XRT_DEPS=1 argument.
+
+3. Docker image is ready, run-docker.sh can now launch a container from this image with `docker run`. It sets up certain environment variables and volume mounts:
+
+  * Vivado/Vitis is mounted from the host into the container (on the same path).
+  * The finn root folder is mounted under /workspace/finn. This allows modifying the source code on the host and testing inside the container.
+  * The build folder is mounted under /tmp/finn_dev_username (can be overridden by defining FINN_HOST_BUILD_DIR). This will be used for generated files. Mounting on the host allows easy examination of the generated files, and keeping the generated files after the container exits.
+  * Various environment variables are set up for use inside the container. See the run-docker.sh script for a complete list.
+
+4. Entrypoint script (docker/finn_entrypoint.sh) upon launching container performs the following:
+
+  * Update and checkout the dependency repos at specified commits.
+  * Source Vivado settings64.sh from specified path to make vivado and vivado_hls available.
+  * Download PYNQ board files into the finn root directory, unless they already exist.
+  * Source Vitits settings64.sh if Vitis is mounted.
+
+5. Depending on the arguments to run-docker.sh a different application is launched. run-docker.sh notebook launches a Jupyter server for the tutorials, whereas run-docker.sh build_custom and run-docker.sh build_dataflow trigger a dataflow build (see documentation). Running without arguments yields an interactive shell. See run-docker.sh for other options.
+
+Linting
+=======
+
+We use a pre-commit hook to auto-format Python code and check for issues.
+See https://pre-commit.com/ for installation. Once you have pre-commit, you can install
+the hooks into your local clone of the FINN repo.
+It's recommended to do this **on the host** and not inside the Docker container:
+
+::
+
+  pre-commit install
+
+
+Every time you commit some code, the pre-commit hooks will first run, performing various
+checks and fixes. In some cases pre-commit won't be able to fix the issues and
+you may have to fix it manually, then run `git commit` once again.
+The checks are configured in .pre-commit-config.yaml under the repo root.
+
+Testing
+=======
+
+Tests are vital to keep FINN running.  All the FINN tests can be found at https://github.com/Xilinx/finn/tree/master/tests.
+These tests can be roughly grouped into three categories:
+
+ * Unit tests: targeting unit functionality, e.g. a single transformation. Example: https://github.com/Xilinx/finn/blob/master/tests/transformation/streamline/test_sign_to_thres.py tests the expected behavior of the `ConvertSignToThres` transformation pass.
+
+ * Small-scale integration tests: targeting a group of related classes or functions that to test how they behave together. Example: https://github.com/Xilinx/finn/blob/master/tests/fpgadataflow/test_convert_to_hls_conv_layer.py sets up variants of ONNX Conv nodes that are first lowered and then converted to FINN HLS layers.
+
+ * End-to-end tests: testing a typical 'end-to-end' compilation flow in FINN, where one end is a trained QNN and the other end is a hardware implementation. These tests can be quite large and are typically broken into several steps that depend on prior ones. Examples: https://github.com/Xilinx/finn/tree/master/tests/end2end
+
+Additionally, finn-base, brevitas and finn-hlslib also include their own test suites.
+The full FINN compiler test suite
+(which will take several hours to run and require a PYNQ board) can be executed
+by:
+
+::
+
+  bash ./run-docker.sh test
+
+There is a quicker variant of the test suite that skips the tests marked as
+requiring Vivado or as slow-running tests:
+
+::
+
+  bash ./run-docker.sh quicktest
+
+When developing a new feature it's useful to be able to run just a single test,
+or a group of tests that e.g. share the same prefix.
+You can do this inside the Docker container
+from the FINN root directory as follows:
+
+::
+
+  python setup.py test --addopts "-k test_brevitas_debug --pdb"
+
+
+If you want to run tests in parallel (e.g. to take advantage of a multi-core CPU)
+you can use:
+
+* pytest-parallel for any rtlsim tests, e.g. `python setup.py test --addopts "-k rtlsim --workers auto"`
+* pytest-xdist for anything else, make sure to add `--dist=loadfile` if you have tests in the same file that have dependencies on each other e.g. `python setup.py test --addopts "-k mytest -n auto --dist=loadfile"`
+
+Finally, the full test suite with appropriate parallelization can be run inside the container by:
+
+::
+
+  quicktest.sh full
+
+See more options on pytest at https://docs.pytest.org/en/stable/usage.html.
+
+Documentation
+==============
+
+FINN provides two types of documentation:
+
+* manually written documentation, like this page
+* autogenerated API docs from Sphinx
+
+Everything is built using Sphinx, which is installed into the finn.dev
+Docker image. You can build the documentation locally by running the following
+inside the container:
+
+::
+
+  python setup.py docs
+
+You can view the generated documentation on build/html/index.html.
+The documentation is also built online by readthedocs:
+
+  * finn.readthedocs.io contains the docs from the master branch
+  * finn-dev.readthedocs.io contains the docs from the dev branch
+
+When adding new features, please add docstrings to new functions and classes
+(at least the top-level ones intended to be called by power users or other devs).
+We recommend reading the Google Python guide on docstrings here for contributors:
+https://google.github.io/styleguide/pyguide.html#38-comments-and-docstrings
diff --git a/docs/finn/getting_started.rst b/docs/finn/getting_started.rst
index 017138075ba8c19c01b11e8ebb721e3089b69fd8..3b475303d7dde91e8b6a21856eb4d66417f164d7 100644
--- a/docs/finn/getting_started.rst
+++ b/docs/finn/getting_started.rst
@@ -111,43 +111,6 @@ http://127.0.0.1:8888/?token=f5c6bd32ae93ec103a88152214baedff4ce1850d81065bfc
 
 The ``run-docker.sh`` script forwards ports 8888 for Jupyter and 8081 for Netron, and launches the notebook server with appropriate arguments.
 
-Running the test suite directly
-*******************************
-FINN comes with a set of tests to check for regressions. The full test suite
-(which will take several hours to run and require a PYNQ board) can be executed
-by:
-
-::
-
-  bash ./run-docker.sh test
-
-There is a quicker variant of the test suite that skips the tests marked as
-requiring Vivado or as slow-running tests:
-
-::
-
-  bash ./run-docker.sh quicktest
-
-If you want to run individual tests, you can do this *inside the Docker container
-from the FINN root directory* as follows:
-
-::
-
-  python setup.py test --addopts "-k test_brevitas_debug"
-
-If you want to run tests in parallel (e.g. to take advantage of a multi-core CPU)
-you can use:
-
-* pytest-parallel for any rtlsim tests, e.g. `python setup.py test --addopts "-k rtlsim --workers auto"`
-* pytest-xdist for anything else, make sure to add `--dist=loadfile` if you have tests in the same file that have dependencies on each other e.g. `python setup.py test --addopts "-k mytest -n auto --dist=loadfile"`
-
-Please see the pytest documentation for more about picking tests by marks or by name.
-
-Finally, the full test suite with appropriate parallelization can be run inside the container by:
-
-::
-
-  quicktest.sh full
 
 Environment variables
 **********************
@@ -169,7 +132,7 @@ These are summarized below:
 
 Supported Hardware
 ===================
-**End-to-end support including driver:** For quick deployment, FINN targets boards supported by  `PYNQ <https://pynq.io/>`_ . For these platforms, we can build a full bitfile including DMAs to move data into and out of the FINN-generated accelerator, as well as a Python driver to launch the accelerator. We support the Pynq-Z1, Pynq-Z2, Ultra96, ZCU102 and ZCU104 boards.
+**Shell-integrated accelerator + driver:** For quick deployment, we target boards supported by  `PYNQ <https://pynq.io/>`_ . For these platforms, we can build a full bitfile including DMAs to move data into and out of the FINN-generated accelerator, as well as a Python driver to launch the accelerator. We support the Pynq-Z1, Pynq-Z2, Ultra96, ZCU102 and ZCU104 boards.
 As of FINN v0.4b we also have preliminary support for `Xilinx Alveo boards <https://www.xilinx.com/products/boards-and-kits/alveo.html>`_ using PYNQ and Vitis, see instructions below for Alveo setup.
 
 **Vivado IPI support for any Xilinx FPGA:** FINN generates a Vivado IP Integrator (IPI) design from the neural network with AXI stream (FIFO) in-out interfaces, which can be integrated onto any Xilinx FPGA as part of a larger system. It's up to you to take the FINN-generated accelerator (what we call "stitched IP" in the tutorials), wire it up to your FPGA design and send/receive neural network data to/from the accelerator.
diff --git a/docs/finn/img/repo-structure.png b/docs/finn/img/repo-structure.png
new file mode 100644
index 0000000000000000000000000000000000000000..05031ff9a5500c3302a36ea88309b3707bc5d108
Binary files /dev/null and b/docs/finn/img/repo-structure.png differ
diff --git a/docs/finn/index.rst b/docs/finn/index.rst
index 782aa53edcca5420f0540461d21bdfcbcd362c7d..fa7ed30205da5b9c63c469ca600211e7865a9730 100644
--- a/docs/finn/index.rst
+++ b/docs/finn/index.rst
@@ -47,5 +47,6 @@ More FINN Resources
    command_line
    example_networks
    internals
+   developers
    source_code/finn
    genindex
diff --git a/docs/finn/internals.rst b/docs/finn/internals.rst
index 602fef6cf84075059938b5c2d7b7e017aabec70a..0fbc3cf72795005591994ddca0fa0d58b72622a8 100644
--- a/docs/finn/internals.rst
+++ b/docs/finn/internals.rst
@@ -1,9 +1,9 @@
+.. _internals:
+
 *********
 Internals
 *********
 
-.. note:: **More developer-oriented documentation will be coming in future releases.**
-
 Intermediate Representation: FINN-ONNX
 ======================================