Revert "docs: remove 013 for now"

This reverts commit b05b577695.

docs/federation/resolutions/in-progress/013.md

@@ -0,0 +1,83 @@
+---
+title: "Resolution 013: Budget 007: Operator sync - 2023-10-14"
+---
+
+- Deadline: 2023-10-28
+- Size: Large
+
+### Summary
+
+As highlighted in several tickets (e.g. [`#434`](https://git.coopcloud.tech/coop-cloud/organising/issues/434), [`#467`](https://git.coopcloud.tech/coop-cloud/organising/issues/467)), several operators working together on the same server routinely run into deployment instability. This is due to the fact that we do not store or sync the deployment version of the apps.
+
+With this proposal, we would like to address the synchronisation of app deployment versions. This is being called "Operator sync". What follows is the design proposal which has already received feedback from operators on [this pad](https://pad.riseup.net/p/IebZQkpe3OOpYyVT8f1j-keep).
+
+### Details (Budget 007)
+
+We support a config file (`$ABRA_DIR/config.yml`) which has these defaults:
+
+```yaml
+---
+operator:
+  sync: false
+```
+
+We also add a `abra config` command which has the following shape:
+
+```
+🌻 ./abra config -h
+NAME:
+   abra config - Manage system-wide Abra configuration
+
+USAGE:
+   abra config command [command options]
+
+COMMANDS:
+   generate, g  Generate default configuration
+
+OPTIONS:
+   --help, -h  show help
+```
+
+If there is no `$ABRA_DIR/config.yml` or `sync: false`, nothing changes. When `sync: true`, *only* the `abra app deploy / upgrade / rollback` commands have new behaviour.
+
+There is also a new command `abra app sync <domain>` which triggers a synchronisation.
+
+When `abra app deploy/upgrade/rollback/sync` is run, here's what we do:
+
+* `git pull` on the sync repository
+    * if there are changes, pull them in & log them
+    * if there is a merge conflict, bail out and ask operator to resolve them
+
+`abra` will search for Git repositories under `$ABRA_DIR/servers/...`. A single Git repository at the root (`$ABRA_DIR/servers/.git`) and on the individual server level (`$ABRA_DIR/servers/example.com/.git`) are supported. Both solution work alongside each other and symlinks are resolved.
+
+The way to avoid merge conflicts will be to never move the `OPERATOR_SYNC_VERSION` env var (see below) from the line it is on in the app env config. `abra` will always insert it just under the `TYPE` env var.
+
+The initial implementation asks operators to initialise their own Git repositories.
+
+* Read the `OPERATOR_SYNC_VERSION` env var as the version to deploy / upgrade from / rollback from
+    * upgrade: if deployed version does not match `OPERATOR_SYNC_VERSION`, warn before overview
+    * rollback: same as above!
+
+* Run the deployment
+    * if successful, record a new `OPERATOR_SYNC_VERSION`, commit & push the changes
+    * if unsuccessful, do not record a `OPERATOR_SYNC_VERSION` and ask operator to resolve
+
+If `--chaos` is passed, we use the short commit hash instead of the version label.
+
+Here's an example of the `OPERATOR_SYNC_VERSION` env var:
+
+```
+# in ~/.abra/servers/example.com/matrix.example.com.env
+TYPE=matrix-synapse
+OPERATOR_SYNC_VERSION=4.0.0+v1.93.0 # managed by Abra
+```
+
+Operator documentation will also be provided.
+
+**Budget amount**: 400 EUR (20 hrs * 20 EUR/hr)
+
+**Who will implement this**: decentral1se
+
+**When will the money be spent**: Before mid November 2023.
+
+**What is the money for**: Implementing the first steps of operator sync.

mkdocs.yml

@@ -103,6 +103,7 @@ nav:
           - federation/resolutions/passed/012.md
         - "In progress":
           - federation/resolutions/in-progress/index.md
+          - federation/resolutions/in-progress/013.md
         - "Draft":
           - federation/resolutions/drafts/index.md
       - "Finance": federation/finance.md