diff --git a/charts/k8s-gerrit/Documentation/roadmap.md b/charts/k8s-gerrit/Documentation/roadmap.md
new file mode 100644
index 0000000..9af175a
--- /dev/null
+++ b/charts/k8s-gerrit/Documentation/roadmap.md
@@ -0,0 +1,207 @@
+# Roadmap
+
+## General
+
+### Planned features
+
+- **Automated verification process**: Run tests automatically to verify changes. \
+  \
+  Most tests in the project require a Kubernetes cluster and some additional
+  prerequisites, e.g. istio. Currently, the Gerrit OpenSOurce community does not
+  have these resources. At SAP, we plan to run verification in our internal systems,
+  which won't be publicly viewable, but could already vote. Builds would only
+  be triggered, if a maintainer votes `+1` on the `Build-Approved`-label. \
+  \
+  Builds can be moved to a public CI at a later point in time.
+
+- **Automated publishing of container images**: Publishing container images will
+  happen automatically on ref-updated using a CI.
+
+- **Support for multiple Gerrit versions**: All currently supported Gerrit versions
+  will also be supported in k8s-gerrit. \
+  \
+  Currently, container images used by this project are only published for a single
+  Gerrit version, which is updated on an irregular schedule. Introducing stable
+  branches for each gerrit version will allow to maintain container images for
+  multiple Gerrit versions. Gerrit binaries will be updated with each official
+  release and more frequently on `master`. This will be (at least partially)
+  automated.
+
+- **Integration test suite**: A test suite that can be used to test a GerritCluster. \
+  \
+  A GerritCluster running in a Kubernetes cluster consists of multiple components.
+  Having a suite of automated tests would greatly help to verify deployments in
+  development landscapes before going productive.
+
+## Gerrit Operator
+
+### Version 1.0
+
+#### Implemented features
+
+- **High-availability**: Primary Gerrit StatefulSets will have limited support for
+  horizontal scaling. \
+  \
+  Scaling has been enabled using the [high-availability plugin](https://gerrit.googlesource.com/plugins/high-availability/).
+  Primary Gerrits will run in Active/Active configuration. Currently, two primary
+  Gerrit instances, i.e. 2 pods in a StatefulSet, are supported
+
+- **Global RefDB support**: Global RefDB is required for Active/Active configurations
+  of multiple primary Gerrits. \
+  \
+  The [Global RefDB](https://gerrit.googlesource.com/modules/global-refdb) support
+  is required for high-availability as described in the previous point. The
+  Gerrit Operator automatically sets up Gerrit to use a Global RefDB
+  implementation. The following implementations are supported:
+  - [spanner-refdb](https://gerrit.googlesource.com/plugins/spanner-refdb)
+  - [zookeeper-refdb](https://gerrit.googlesource.com/plugins/zookeeper-refdb)
+
+  \
+  The Gerrit Operator does not set up the database used for the Global RefDB. It
+  does however manage plugin/module installation and configuration in Gerrit.
+
+- **Full support for Nginx**: The integration of Ingresses managed by the Nginx
+  ingress controller now supports automated routing. \
+  \
+  Instead of requiring users to use different subdomains for the different Gerrit
+  deployments in the GerritCluster, requests are now automatically routed to the
+  respective deployments. SSH has still to be set up manually, since this requires
+  setting up the routing in the Nginx ingress controller itself.
+
+#### Planned features
+
+- **Versioning of CRDs**: Provide migration paths between API changes in CRDs. \
+  \
+  At the moment updates to the CRD are done without providing a migration path.
+  This means a complete reinstallation of CRDS, Operator, CRs and dependent resources
+  is required. This is not acceptable in a productive environment. Thus,
+  the operator will always support the last two versions of each CRD, if applicable,
+  and provide a migration path between those versions.
+
+- **Log collection**: Support addition of sidecar running a log collection agent
+  to send logs of all components to some logging stack. \
+  \
+  Planned supported log collectors:
+  - [OpenTelemetry agent](https://opentelemetry.io/docs/collector/deployment/agent/)
+  - Option to add a custom sidecar
+
+- **Support for additional Ingress controllers**: Add support for setting up routing
+  configurations for additional Ingress controllers \
+  \
+  Additional ingress controllers might include:
+  - [Ambassador](https://www.getambassador.io/products/edge-stack/api-gateway)
+
+### Version 1.x
+
+#### Potential features
+
+- **Support for additional log collection agents**: \
+  \
+  Additional log collection agents might include:
+  - fluentbit
+  - Option to add a custom sidecar
+
+- **Additional ValidationWebhooks**: Proactively avoid unsupported configurations. \
+  \
+  ValidationWebhooks are already used to avoid accepting unsupported configurations,
+  e.g. deploying more than one primary Gerrit CustomResource per GerritCluster.
+  So far not all such cases are covered. Thus, the set of validations will be
+  further expanded.
+
+- **Better test coverage**: More tests are required to find bugs earlier.
+
+- **Automated reload of plugins**: Reload plugins on configuration change. \
+  \
+  Configuration changes in plugins typically don't require a restart of Gerrit,
+  but just to reload the plugin. To avoid unnecessary downtime of pods, the
+  Gerrit Operator will only reload affected plugins and not restart all pods, if
+  only the plugin's configuration changed.
+
+- **Externalized (re-)indexing**: Alleviate load caused by online reindexing. \
+  \
+  On large Gerrit sites online reindexing due to schema migrations `a)` or initialization `b)`
+  of a new site might take up to weeks and use a lot of resources, which might
+  cause performance issues. This is not acceptable in production. The current
+  plan to solve this issue is to implement a separate Gerrit deployment (GerritIndexer)
+  that is not exposed to clients and that takes over the task of online reindexing.
+  The GerritIndexer will mount the same repositories and will share events via
+  the high-availability plugin. However, it will access repositories in read-only
+  mode. \
+  This solves the above named scenarios as follows: \
+  \
+  a) **Schema migrations**: If a Gerrit update including a schema migration for
+    an index is applied, the Gerrit instances serving clients will be configured
+    to continue to use the old schema. Online reindexing will be disabled in
+    those instances. The GerritIndexer will have online reindexing enabled and
+    will start to build the new index version. As soon as it is finished, i.e.
+    it could start to use the new index version as read index, it will make a
+    copy of the new index and publish it, e.g. using a shared filesystem. A
+    restart of the Gerrit instances serving other clients will be triggered.
+    During this restart the new index will be copied into the site. Since there
+    may have been updated index entries since the new index version was published
+    indexing of entries updated in the meantime will be triggered. \
+  \
+  b) **Initialization of a new site**: If Gerrit is horizontally scaled, it will
+    be started with an empty index, i.e. it has to build the complete index. To
+    avoid this, the GerritIndexer deployment will continuously keep a copy of the
+    indexes up-to-date. It will regularly be stopped and a copy of the index will
+    be stored in a shared volume. This can be used as a base for new instances, which
+    then only have to update index entries that were changed in the meantime.
+
+- **Autoscaling**: Automatically scale Gerrit deployments based on usage. \
+  \
+  Metrics like available workers in the thread pools could be used to decide to
+  scale the Gerrit deployment horizontally. This would allow to dynamically adapt
+  to the current load. This helps to save costs and resources.
+
+### Version 2.0
+
+#### Potential features
+
+- **Multi region support**: Support setups that are distributed over multiple regions. \
+  \
+  Supporting Gerrit installations that are distributed over multiple regions would
+  allow to serve clients all over the world without large differences in latency
+  and would also improve availability and reduce the risks of data loss. \
+  Such a setup could be achieved by using the [multi-site setup](https://gerrit.googlesource.com/plugins/multi-site/).
+
+- **Remove the dependency on shared storage**: Use completely independent sites
+  instead of sharing a filesystem for some site components. \
+  \
+  NFS and other shared filesystems potentially might cause performance issues on
+  larger Gerrit installations due to latencies. A potential solution might be
+  to use the [multi-site setup](https://gerrit.googlesource.com/plugins/multi-site/)
+  to separate the sites of all instances and to use events and replication to
+  share the state
+
+- **Shared index**: Using an external centralized index, e.g. OpenSearch instead
+  of x copies of a Lucene index. \
+  \
+  Maintaining x copies of an index, where x is the number of Gerrit instances in
+  a gerritCluster, is unnecessarily expensive, since the same write transactions
+  have to be potentially done x times. Using a single centralized index would
+  resolve this issue.
+
+- **Shared cache**: Using an external centralized cache for all Gerrit instances. \
+  \
+  Using a single cache for all Gerrit instances will reduce the number of
+  computations for each Gerrit instance, since not every instance will have to
+  keep its own copy up-to-date.
+
+- **Sharding**: Shard a site based on repositories. \
+  \
+  Repositories served by a single GerritCluster might be quite diverse, e.g. ranging
+  from a few kilobytes to several gigabytes or repositories seeing high traffic
+  and other barely being fetched. It is not trivial to configure Gerrit to work
+  optimally for all repositories. Being able to shard at least the Gerrit Replicas
+  would help to optimally serve all repositories.
+
+## Helm charts
+
+Only limited support is planned for the `gerrit` and `gerrit-replica` helm-charts
+as soon as the Gerrit Operator reaches version 1.0. The reason is that the double
+maintenance of all features would not be feasible with the current number of
+contributors. The Gerrit Operator will support all features that are provided by
+the helm charts. If community members would like to adopt maintainership of the
+helm-charts, this would be very much appreciated and the helm-charts could then
+continued to be supported.