Shorten the introduction

README.md

@@ -4,27 +4,15 @@
 [![Coverage Status](https://coveralls.io/repos/github/zalando-incubator/postgres-operator/badge.svg)](https://coveralls.io/github/zalando-incubator/postgres-operator)
 [![Go Report Card](https://goreportcard.com/badge/github.com/zalando-incubator/postgres-operator)](https://goreportcard.com/report/github.com/zalando-incubator/postgres-operator)
 
-The Postgres operator manages PostgreSQL clusters on Kubernetes using the [operator pattern](https://coreos.com/blog/introducing-operators.html).
+## Introduction 
-During the initial run it registers the [Custom Resource Definition (CRD)](https://kubernetes.io/docs/concepts/api-extension/custom-resources/#customresourcedefinitions) for Postgres.
-The `postgresql` CRD is essentially the schema that describes the contents of the manifests for deploying individual
-Postgres clusters using StatefulSets and [Patroni](https://github.com/zalando/patroni).
 
-Once the operator is running, it performs the following actions:
+The Postgres [operator](https://coreos.com/blog/introducing-operators.html) manages PostgreSQL clusters on Kubernetes:
 
-* watches for new `postgresql` manifests and deploys new clusters
+1. The operator watches additions, updates and deletions of Postgresql manifests (cluster descriptions) and changes the running clusters accordingly. For example, when a user submits a new manifest, the operator fetches that object and spawns a new Postgres cluster, including all necessary  entities such as Kubernetes StatefulSets and Postgres roles. The [`postgresql` Custom Resource Definition](https://kubernetes.io/docs/concepts/api-extension/custom-resources/#customresourcedefinitions) defines settings that a cluster manifest may contain (see example).
-* watches for updates to existing manifests and changes corresponding properties of the running clusters
-* watches for deletes of the existing manifests and deletes corresponding clusters
-* acts on an update to the operator configuration itself and changes the running clusters when necessary
-  (i.e. the Docker image changes for a minor release update)
-* periodically checks running clusters against the manifests and syncs changes
 
-Example: When a user creates a new custom object of type ``postgresql`` by submitting a new manifest with
+2. The operator also watches updates to its own configuration and alters running Postgres clusters if necessary. For instance, if a pods' Docker image is changed, the operator carries out the rolling update. That is, it re-spawns one-by-one pods from each StatefulSet it manages with the new Docker image. 
-``kubectl``, the operator fetches that object and creates the required Kubernetes entities to spawn a new Postgres cluster
-(StatefulSets, Services, Secrets).
 
-Update example: After changing the Docker image inside the operator's configuration, the operator first goes to all StatefulSets
+3. Finally, the operator periodically synchronizes the actual state of each Postgres cluster with the desired state defined in the cluster's manifest. 
-it manages and updates them with the new Docker image; afterwards, all pods from each StatefulSet are killed one by one
-and the replacements are spawned automatically by each StatefulSet with the new Docker image. This is called the Rolling update.
 
 
 ## Quickstart 
@@ -55,6 +43,7 @@ We have automated these steps for you:
 ```bash
 cd postgres-operator
 ./run_operator_locally.sh
+minikube delete
 ```
 
 ## Scope