wip: docs: march resolutions

See coop-cloud/organising#583

docs/abra/cheat-sheet.md

@@ -27,11 +27,6 @@ flags: `-f/--force`, `-C/--chaos`
 - `abra app rm --volumes $APPNAME`
 flags: `-f/--force`, `-V/--volumes`
 
-### add/remove server
-- `abra server add $SERVER`
-- `abra server remove $SERVER`
-flags: `-s/--server`
-
 ### upgrade abra
 - `abra upgrade`
 flags: `--rc`
@@ -74,6 +69,3 @@ As you can see we, we're selecting all recipes where category is "Utilities".
 `abra app ls -m -S |jq '[.[].apps[] | select(.status == "deployed") | del(.upgrade)]' |tv`
 
 The `del(.upgrade)` filter filters out available versions for the recipe in question for that row. It could be useful to leave in if you want a list of deployed apps that need an upgrade.
-
-
-

docs/abra/design.md

@@ -0,0 +1,9 @@
+---
+title: Design
+---
+
+## Design Prime Directives
+
+* De-coupling: it should be possible to use the recipes without relying on
+  `abra`. The commons of recipes should live and function independently of
+  `abra`.

docs/abra/hack.md

@@ -2,6 +2,19 @@
 title: Hack
 ---
 
+## Contributing
+
+Welcome to Hacking the Planet with `abra`! We're looking forward to see what
+you come up. If you have any questions, don't hesitate to ask 💖 If any of your
+changes seems a bit controversial, it's probably to come have a chat first to
+avoid heartache.
+
+In general, we're into the idea of "Optimistic Merging" (instead of
+"Pessimistic Merging" based on our understanding of
+[C4](https://hintjens.gitbooks.io/social-architecture/content/chapter4.html)
+(described further down under "Development Process" and also [in this blog
+post](http://hintjens.com/blog:106)).
+
 ## Quick start
 
 Get a fresh copy of the `abra` source code from [here](https://git.coopcloud.tech/coop-cloud/abra).

docs/federation/code-of-coop.md

@@ -0,0 +1,160 @@
+---
+title: Code of Co-operation
+---
+
+> Huge thanks to the folks at [Varia](https://varia.zone/) &
+> [LURK](https://lurk.org) who carefully prepared wonderful Code of Conduct
+> documents which we have adapted for our needs (with permission). See the
+> original documents [here](https://varia.zone/en/pages/code-of-conduct.html)
+> and [there](https://lurk.org/TOS.txt).
+
+Co-op Cloud is used by several communities coming from a variety of cultural,
+ethnic and professional backgrounds. We strive for to be welcoming to people of
+these various backgrounds and provide a non-toxic and harassment-free
+environment. 
+
+The Code of Conduct is a set of guidelines that help establish shared values
+and ensure that behaviour that may harm participants is avoided. 
+
+We acknowledge that we come from different backgrounds and all have certain
+biases and privileges. Therefore, this Code of Conduct cannot account for all
+the ways that people might feel excluded, unsafe or uncomfortable. We commit to
+open dialogues, and as such this Code of Conduct is never finished and should
+change whenever needed. We amend this document over time so it reflects the
+priorities and sensitivities of the community as it changes.
+
+It is a collective responsibility for all of us to enact the behaviour
+described in this document.
+
+## Expected behaviour
+
+We expect each other to:
+
+### Be considerate...
+
+...of each other, the space we enter, the Co-op Cloud community and the
+practices that it houses.
+
+### Be open and generous...
+
+...while trying not to make assumptions about others. This can include
+assumptions about identity, knowledge, experiences or preferred pronouns. Be
+generous with our time and our abilities, when we are able to. Help others, but
+ask first. There are many ways to contribute to a collective practice, which
+may differ from our individual ways.
+
+### Be respectful...
+
+...of different viewpoints and experiences. Respect physical and emotional
+boundaries. Be respectful of each others' limited time and energy. Take each
+other and each other's practices seriously. Acknowledge that this might lead to
+disagreement. However, disagreement is no excuse for poor manners.
+
+### Be responsible....
+
+...for the promises we make, meaning that we follow up on our commitments. We
+take responsibility for the good things we do, but also for the bad ones. We
+listen to and act upon respectful feedback. We correct ourselves when
+necessary, keeping in mind that the impact of our words and actions on other
+people doesn't always match our intent.
+
+### Be dedicated...
+
+...which means not letting the group happen to us, but making the group
+together. We participate in the group with self-respect and don't exhaust
+ourselves. This might mean saying how we feel, setting boundaries, being clear
+about our expectations. Nobody is expected to be perfect in this community.
+Asking questions early avoids problems later. Those who are asked should be
+responsive and helpful.
+
+### Be empathetic...
+
+..by actively listening to others and not dominating discussions. We give each
+other the chance to improve and let each other step up into positions of
+responsibility. We make room for others. We are aware of each other's feelings,
+provide support where necessary, and know when to step back. One's idea of
+caring may differ from how others want to be cared for. We ask to make sure
+that our actions are wanted.
+
+### Foster an inclusive environment...
+
+...by trying to create opportunities for others to express views, share skills
+and make other contributions. Being together is something we actively work on
+and requires negotiation. We recognize that not everyone has the same
+opportunities, therefore we must be sensitive to the context we operate in.
+There are implicit hierarchies that we can challenge, and we should strive to
+do so. When we organize something (projects, events, etc.), we think about how
+we can consider degrees of privilege, account for the needs of others, promote
+an activist stance and support other voices.
+
+## Unacceptable behaviour
+
+### No structural or personal discrimination
+
+Attitudes or comments promoting or reinforcing the oppression of any groups or
+people based on gender, gender identity and expression, race, ethnicity,
+nationality, sexuality, sexual orientation, religion, disability, mental
+illness, neurodiversity, personal appearance, physical appearance, body size,
+age, or class. Do not claim “reverse-isms”, for example “reverse racism”.
+
+### No harrassment
+
+Neither public nor private. Also no deliberate intimidation, stalking,
+following, harassing photography or recording, disruption of events,
+aggressive, slanderous, derogatory, or threatening comments online or in person
+and unwanted physical or electronic contact or sexual attention. No posting or
+disseminating libel, slander, or other disinformation.
+
+### No violation of privacy
+
+Namely publishing others’ private information, such as a physical or electronic
+address, without explicit permission. Do not take or publish photos or
+recordings of others after their request to not do so. Delete recordings if
+asked.
+
+### No unwelcome sexual conduct
+
+Including unwanted sexual language, imagery, actions, attention or advances.
+
+### No destructive behaviour
+
+Or any other conduct which could reasonably be considered inappropriate. This
+includes (but is not exclusive to) depictions of violence without content
+warnings, consistently and purposely derailing or disrupting conversations, or
+other behaviour that persistently disrupts the ability of others to engage in
+the group or space.
+
+## Intervention procedure
+
+**Immediate intervention (help is needed now!)**
+
+If you are feeling unsafe, you can immediately contact the Co-op Cloud members
+who are tasked with making sure the code of co-operation is respected.
+
+These contact people are members of Co-op Cloud who will do their best to help,
+or to find the correct assistance if relevant/necessary. Here is the list so
+far. If you would like to help in this task, please also feel free to volunteer
+to be a support member.
+
+> handle: `sordidwhiskey` contact:
+> [helo@coopcloud.tech](mailto:helo@coopcloud.tech) handle: `3wc` contact:
+> [helo@coopcloud.tech](mailto:helo@coopcloud.tech)
+
+For example, something happened during a still-ongoing online event and needs
+to be acted upon right away. Action is taken immediately when this violation of
+the code of co-operation is reported. This could involve removing an attendee
+from said event.
+
+## Non-immediate intervention (a situation that requires more time)
+
+Other violations need to be considered and consulted upon with more people or
+in a more measured way. For example: If you experience an ongoing pattern of
+harrassment; if you witness structurally unacceptable behaviour; if somebody
+keeps "accidentally" using discriminatory language, after being asked to stop.
+
+If you feel comfortable or able, discuss the issues with the involved parties
+before consulting a mediator. We prefer to constructively resolve disagreements
+together and work to right the wrong, when it is possible and safe to do so.
+However, if the problems still persist, those who are responsible for enforcing
+the code of co-operation can help you deal with these kinds of problems.
+Contact the members listed above. Information will be handled with sensitivity.

docs/federation/index.md

@@ -38,4 +38,10 @@ This is the public facing page where we publish all things federation in the ope
 
     [Tools We Use](/federation/tools){ .md-button .md-button--primary }
 
+- __Code of Co-operation__
+
+    Be excellent to each other 💝
+
+    [Read More](/federation/code-of-coop){ .md-button .md-button--primary }
+
 </div>

docs/federation/minutes/2024-29-03.md

@@ -0,0 +1,125 @@
+---
+title: 2024-29-03
+---
+
+## Meta
+
+* Time: 29-03-2024
+* Present: d1, p4u1, mo
+* Call: https://vc.autistici.org/CoopCloudFederationMeeting
+
+## Agenda
+
+- checking in
+- abra release planning https://git.coopcloud.tech/coop-cloud/organising/issues/583
+- reforms to fedi process
+  - symptoms  
+    - eotl vote delayed weeks
+    - many members not paying dues, no waiver agreed
+    - vera / Flancia left all chats?
+  - proposals
+    - [define fedi member reponsibilities](https://git.coopcloud.tech/coop-cloud/organising/issues/579)
+    - exit criteria for fedi members
+    - delay x quorom decision making
+    - rolling "credit system" for doing work
+    
+## Notes
+
+### Checking in
+
+d1: last release was gnarly, was tired but now looking forward to coordinating new release
+
+mo: travelling, pretty busy, alakazam presentation/docs/feedback energies
+
+p4: release hell, good progress, happy to see automation for new release. backupbot spec is underway, to discuss soon...
+
+### Release planning
+
+Note about previous release: goreleaser refused to to release on a branch previously, so we reverted the backup changes and reverted the revert after the release
+
+#### Catalogue
+
+why catalogue?
+- advantage: git repository
+- disadvantage: overhead, CI/CD system, people don't understand it, several bugs
+
+proposal: rely on tags in the repository. clone everything to .abra/recipes/... pull tags locally on-the-fly.
+
+if i create a new version of a recipe, the catalogue is not even at all. it just looks locally. the update happens afterwards
+
+precomputing means saving resources later on
+
+With the operator collaboration topic, it will be possible to specificy an app recipe with a git location, it is then possible to skip the catalogue.
+https://git.coopcloud.tech/coop-cloud/organising/issues/533#issuecomment-19038
+
+recipes.coopcloud.tech (the Elm app) is reading the JSON
+
+in an ideal post-catalogue abra, you could just ref a git org where `RECIPE=<recipe>` would find `https://git.example.com/<org>/<recipe>` and even `RECIPE=<org>/<recipe>`
+
+Backwards compatiblibility will be key. For next next release 🎉
+
+#### Automation test suite
+
+Computing power from somewhere? Local-IT doing migration atm so not ideal timing. Maybe again after a month or so, can check-in again then.
+
+Can also ask Autonomic and/or whoever else feels like they can help.
+
+#### Cli Argument Handling
+
+https://git.coopcloud.tech/coop-cloud/organising/issues/581
+
+Upgrade to `urfave/cli` version 2 will enforce `abra app command command [command options] <domain> [<service>] <command> [-- <args>]`
+
+Maybe we need a poll to see how people are using it? `@mo` using the strict format anyway, `@d1` not minding, `@p4` in favour...
+
+adding a good/clear warning/error that if using e.g. `--chaos` on the end, it's not possible anymore...
+
+> How do you use flag options (e.g. `--chaos`) with Abra?
+> At the beginning: abra app deploy --chaos app.example.com
+> At the end: abra app deploy app.example.com --chaos
+
+> How annoyed will you be if, we enforce it at the beginning?
+> Not annoyed
+> Slighty annoyed
+> Very annoyed
+> If you are *annoyed, what can we do to help this process? e.g. docs, warning, etc.
+
+Decision vs. poll? It's not really a choice. the lib is broken / enforces this. its ambigous now and just causes issues / questions / confusion.
+
+Hack to re-order options transparently? Some pre-processor which would special case the `[-- ARGS]` for `abra app cmd`.
+
+Doing it one way is just clear for everyone.
+
+Plan: make proposal, get votes. if voted against, try to make new with adaptions / more work/money etc. but compromises with needs. (TODO: `@d1`)
+
+Btw emoji polls are actually broken for some clients 😱
+
+### Fedi process reforms
+
+https://git.coopcloud.tech/coop-cloud/organising/issues/579
+
+- pay yearly dues or get waiver (don't pay)
+- actively participate in voting
+- actively participate in monthly federation meetings. if you can't make it, please send your updates by text
+- agree to code of conduct
+
+exit criteria?
+
+- no yearly dues arragement
+- no/less voting/participation in meetings
+
+TODO: proposal, pass, check in with people in the "exit criteria" area, are they OK?
+
+### Goals of Federation?
+
+- what is the purpose of the fedi?
+- in relation to theory, ideology, strategy
+- Co-op Cloud Conf !!!
+- let's think about this and check back in
+
+### Next meeting
+
+`@mo` does next poll
+
+
+

docs/federation/resolutions/drafts/020.md

@@ -0,0 +1,49 @@
+---
+title: "Resolution 020"
+---
+
+- Topic: Federation member responsibilities
+- Date: ...
+- Deadline: ...
+- Size: Large
+
+### Summary
+
+Motivated by the last Federation meeting: [minutes](https://docs.coopcloud.tech/federation/minutes/2024-29-03/).
+
+New members are joining the Federation, hurray! In the discussion about what it means to join, the question came up: what exactly are the responsibilities of the members? This was raised in [`#581`](https://git.coopcloud.tech/coop-cloud/organising/issues/581).
+
+Responsibilities were defined in the original [Federation Proposal](https://pad.autonomic.zone/s/MLafJE2jC#Responsibilities). We would like to document and extend those in this proposal.
+
+Furthermore, some existing members have not been participating, not paid dues/asked for waiver and some have even left the federation chat room. It would seem also time to define some "exit criteria" to keep a healthy balance.
+
+### Details
+
+#### Responsibilities
+
+**Already agreed upon**
+
+- Pay yearly dues or ask for waiver (if they can't afford it)
+- Actively participate in all large decisions
+- Agree to the [Code of Co-operation (CoC)](https://docs.coopcloud.tech/federation/code-of-coop/)
+
+**New**
+
+- Actively participate in monthly federation meetings. If they can't make it, updates will be sent by text.
+
+#### Exit criteria
+
+> The idea is not to eject people out the federation but to use these clear guidelines as a way to assess if participants should remain federation members. This applies to both sides as it is often unclear how to leave volunteer projects.
+
+**New**
+
+- Not paying dues / having an agreed waiver
+- Not actively participating in all large decisions
+- Not active in federation monthly meetings
+- Do not behave in accordance with the [CoC](https://docs.coopcloud.tech/federation/code-of-coop/)
+
+#### Implementation
+
+- These criteria + a link to the [Federation proposal](https://pad.autonomic.zone/s/MLafJE2jC) will be clearly linked on a new "Federation handbook" on docs.coopcloud.tech
+
+- An agenda point will be put on the next federation meeting to chase up dues/waiver agreements and to agree on a collective process for checking on participation of members.

docs/federation/resolutions/drafts/021.md

@@ -0,0 +1,74 @@
+---
+title: "Resolution 021"
+---
+
+- Topic: Budget XXX: Flag handling in Abra
+- Date: ...
+- Deadline: ...
+- Size: Medium
+
+### Summary
+
+Motivated by the collective release planning: [`#583`](https://git.coopcloud.tech/coop-cloud/organising/issues/583) under "Argument Handling".
+
+Due to a bug in the underlying library (`urfave/cli`) that Abra uses for command-line argument/flag handling, we have a bug in Abra which cannot be fixed without causing a breaking change. See [`#581`](https://git.coopcloud.tech/coop-cloud/organising/issues/581) for the ongoing discussion. This proposal is the TLDR; and proposal for the fix.
+
+### Details (Budget XXX)
+
+#### The problem
+
+The current help output of `abra app deploy` is as follows:
+
+`abra app deploy [command options] <domain> [<version>]`
+
+However, it is possible to do both of the following:
+
+```
+abra app deploy --chaos example.org  # "before" style
+abra app deploy example.org --chaos  # "after" style
+```
+
+However, `abra app cmd` is broken if you try to use the "after" style:
+
+```
+abra app cmd <domain> <function> --local -- <args>
+```
+
+This results in `FATA[0000] <recipe> doesn't have a --local function` which is a bug in the `abra` code. It tries to read the position of the arguments but `--local` is included as an argument. The bug in `abra` is due to a bug in `urfave/cli` - "after" style options appear as arguments 😱
+
+The only way to use `abra app cmd` right now is using the "before" style:
+
+```
+abra app cmd  --local <domain> <function> -- <args>
+```
+
+This means that some commands allow both "after" and "before" style and some only allow "before" style. This is a source of confusion, raised issues and frustration.
+
+#### Our solution
+
+We propose to remedy this situation by upgrading `urfave/cli` to version 2 which enforces the "before" style. This was the solution from `urfave/cli` developers to fix their bug. You can then only do e.g.
+
+```
+abra app deploy --chaos <domain>
+```
+
+This is the "simplest" option in terms of development capacity and is the most cost effective option. The upgrade effort is more or less a known quantity, see [`#404`](https://git.coopcloud.tech/coop-cloud/abra/pulls/404) for more.
+
+We have previously reverted from version 2 to version to 1 to maintain this flexibility. However, this leaves us with an unresolved bug which we want to close off.
+
+#### Alternatives
+
+If this restriction is seen as too burdensome, we see some alternatives.
+
+If you choose to vote against this proposal, please include your preference for an alternative (below or with your own). This allows us to mount another proposal with minimal effort.
+
+There is no guarantee we can get these right and it will incur an ongoing maintenance cost.
+
+1. we make a special case hack in the case of the `--local` handling and proceed as usual
+1. we upgrade to v2 and include a patch which automatically re-orders "after" style options into the "before" style transparently
+
+#### Budget
+
+Compensate `@p4u1` for XXX hrs work to get this done. This includes XXX hrs
+backpay for the initial spike in
+[`#404`](https://git.coopcloud.tech/coop-cloud/abra/pulls/404).

docs/federation/resolutions/drafts/023.md

@@ -0,0 +1,48 @@
+---
+title: "Resolution 023"
+---
+
+- Topic: Budget XXX: Improved project organisation
+- Date: ...
+- Deadline: ...
+- Size: Large
+
+### Summary
+
+Motivated by the collective release planning: [`#583`](https://git.coopcloud.tech/coop-cloud/organising/issues/583) under "Improved Project Organisation".
+
+Several issues, both social & technical in nature are cominmg up based on our chocies for how to organise our project management in Co-op Cloud. This proposal will present the problems and proposals for solutions.
+
+### Details (Budget XXX)
+
+#### The problems
+
+1. Because recipes and "other" repositories are gathered under a single Gitea organisation, [co-op cloud](https://git.coopcloud.tech/coop-cloud), `abra` has to do some serious acrobatics to understand what is a recipe and what is not a recipe. More details in [`#377`](https://git.coopcloud.tech/coop-cloud/organising/issues/377). See also [`#569`](https://git.coopcloud.tech/coop-cloud/organising/issues/569).
+1. Several participants have complained that there is too much indirection & noise involved in having a single issue tracker, [organising](https://git.coopcloud.tech/coop-cloud/organising/issues). By noise, we mean that, e.g. there are several conventions (labels, writing "Abra: " / "Docs: ") in marking issues related to different repositories. By indirection, we mean that it is not always clear where the issue relates to.
+1. There is an old Federation related organisation and related repository, [Federation](https://git.coopcloud.tech/Federation) which has raised questions from new members. It is not used now but it is still there.
+
+#### The solutions
+
+For the recipes issue:
+
+1. Rename [co-op cloud](https://git.coopcloud.tech/coop-cloud) to "Co-op Cloud Configuration Commons (CCCC)".
+1. Create a new Gitea organisation called "Co-op Cloud Federation (CCF)".
+1. Migrate all "non recipe" repositories away from [co-op cloud](https://git.coopcloud.tech/coop-cloud) ("CCCC") and under the CCF organisation.
+
+This creates a clear separation between the configuration commons AKA "the recipes" and "other stuff". This means that `abra` logic can be greatly simplified and become performant once again. Furthermore, we don't break any URLs by keeping the recipes where they always were. The renaming aspect is purely cosmetic, the recipe organisation URL will remain "co-op cloud".
+
+Then, for the issue management issue:
+
+1. Re-open all repository issue trackers instead of pointing to [organising](https://git.coopcloud.tech/coop-cloud/organising/issues).
+1. Migrate all issues by hand from `organising` to their relevant issue trackers. E.g. all issues in organising with the `abra` label will go to the `abra` issue tracker.
+1. Create a new repository called "Co-op Cloud Federation Coordination" where we have an issue tracker for specific federation discussions (E.g. "tracking every member paying dues").
+1. Create a single Gitea Project under the CCF organisation called "Federation FTW".
+
+"Federation FTW" will be the project we collectively refer to in our federation meetings as the "main list of priorities". Issues from every part of the project can be referenced there in a single place. Discussions can happen decentrally in their own issue trackers. It is the central source of truth for our current priorities and a way to stay up to date with what we want to do in the short to medium term.
+
+#### Budget
+
+* 5 hrs for migrating labours of the issues to their related issue trackers.
+* Additional 3 hrs for unseen migration / busy work gotchas.
+* 4 hrs for `abra` changes to only parse the new recipes repository
+* Total: 12 hrs

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

@@ -4,7 +4,7 @@ title: "Resolution 019"
 
 - Topic: Karrot joins the Co-op Cloud Federation
 - Date: 25-03-24
-- Deadline: 25-04-2024
+- Deadline: 08-04-2024
 - Size: Large
 
 ### Summary
@@ -12,10 +12,11 @@ title: "Resolution 019"
 > [Karrot](https://karrot.world) / [Docs](https://docs.karrot.world)
 
 [@nicksellen](https://git.coopcloud.tech/nicksellen) is a Karrot Team member and has:
-- used Co-op Cloud for https://bath.social
-- supported Foodsharing Luxembourg to self-host Karrot using Co-op Cloud
-- participated in https://matrix.to/#/#coopcloud-tech:autonomic.zone chat
-- some small contributions/fixes/bug reports for some Co-op Cloud stuff
+
+- Used Co-op Cloud for [bath.social](https://bath.social)
+- Supported Foodsharing Luxembourg to self-host Karrot using Co-op Cloud
+- Participated in [`#coopcloud-tech:autonomic.zone`](https://matrix.to/#/#coopcloud-tech:autonomic.zone) chat
+- Some small contributions/fixes/bug reports for some Co-op Cloud stuff
 
 ### Details
 

docs/intro/inspirations.md

@@ -0,0 +1,6 @@
+---
+title: Inspirations
+---
+
+* [Dmytri Kleiner: "You can't code away their wealth"](https://yewtu.be/watch?v=FEU632_Em3g). Also, [The Telekommunist Manifesto](https://www.networkcultures.org/_uploads/%233notebook_telekommunist.pdf). Reading / checking out Kleiners work is a must IMHO -- `@decentral1se`.
+* [CoopCycle](https://coopcycle.org/en/) - heavily inspired the Federation model and how we shaped the first decisions on how to do it. -- `@decentral1se`

docs/maintainers/handbook.md

@@ -391,13 +391,17 @@ If you don't have time or are not an operator, reach out on our communication ch
 In the root of your recipe repository, run the following (if the folder doesn't already exist):
 
 ```
-mkdir -p releases
+mkdir -p release
 ```
 
 And then create a text file which corresponds to the version release, e.g. `1.1.0+5.9.0` and write some notes. `abra` will show these when another operator runs `abra app deploy` / `abra app upgrade`.
 
 You can also add release notes for the next release into a special file `releases/next`. This file will be used when running `abra recipe release`.
 
+!!! warning "Not available previous versions of Abra"
+
+    Using `releases/next` is only available in > 0.9.x series of `abra`.
+
 ## How do I generate the recipe catalogue
 
 To generate an entire new copy of the catalogue:

docs/operators/handbook.md

@@ -205,18 +205,6 @@ At time of writing (Jan 2022), we think there is a limitation in our design whic
 
 This may be possible to overcome if someone really needs it, we encourage people to investigate. We've found that often there are limitations in the actual software which don't support this anyway and several of the current operators simply use a new domain per app.
 
-## Creating a new server
-
-`abra server new` can create servers if you have an account with a supported 3rd party integration. We currently support [Servers.coop](https://servers.coop) & [Hetzner](https://hetzner.com). The process of creating a new server usually goes like this:
-
-1. Create an account with a server hosting provider
-2. Generate an API client key which you'll give to `abra`
-3. Run `abra server new` & fill in the values
-
-`abra` supports creating, listing and removing servers if the 3rd party integration supports it.
-
-If you want to teach `abra` how to support your favourite server hosting provider, we'd glady accept patches.
-
 ## How do I bootstrap a server for running Co-op Cloud apps?
 
 The requirements are:
@@ -226,6 +214,12 @@ The requirements are:
 1. Swarm mode initialised
 1. Proxy network created
 
+!!! warning "You may need to log in/out"
+
+    When running `usermod ...`, you may need to (depending on your system) log
+    in and out again of your shell session to get the required permissions for
+    Docker.
+
 ```
 # docker install convenience script
 wget -O- https://get.docker.com | bash
@@ -242,18 +236,6 @@ apt install apparmor
 systemctl restart docker containerd
 ```
 
-## Managing DNS entries
-
-`abra record ...` can help you manage your DNS entries if you have an account with a supported 3rd party provider. We currently support [Gandi](https://gandi.net). The process of managing DNS with `abra` usually goes like this:
-
-1. Create an account with a DNS service provider
-2. Generate an API client key which you'll give to `abra`
-3. Run `abra record ls` to check everything works
-
-`abra` supports creating, listing and removing DNS entries if the 3rd party integration supports it.
-
-If you want to teach `abra` how to support your favourite DNS service provider, we'd glady accept patches.
-
 ## How do I persist container logs after they go away?
 
 This is a big topic but in general, if you're looking for something quick & easy, you can use the [journald logging driver](https://docs.docker.com/config/containers/logging/journald/). This will hook the container logs into systemd which can handle persistent log collection & managing log file size.
@@ -462,3 +444,8 @@ route requests after. You're free to make as many `$whatever.yml` files in your
 
  Please note that we have to hardcode `production` and `web-secure` which are
  typically configurable when not using `FILE_PROVIDER_DIRECTORY_ENABLED`.
+
+## Can I use Caddy instead of Traefik?
+
+Yes, it's possible although currently Quite Experimental! See
+[`#388`](https://git.coopcloud.tech/coop-cloud/organising/issues/388) for more.

docs/operators/tutorial.md

@@ -32,6 +32,12 @@ You need to keep port `:80` and `:443` free on your server for web proxying to y
 
 `abra` has support for creating servers (`abra server new`) but that is a more advanced automation feature which is covered in the [handbook](/operators/handbook). For this tutorial, we'll focus on the basics. Assuming you've managed to create a testing VPS with some `$hosting_provider`, you'll need to install Docker, add your user to the Docker group & setup swarm mode:
 
+!!! warning "You may need to log in/out"
+
+    When running `usermod ...`, you may need to (depending on your system) log
+    in and out again of your shell session to get the required permissions for
+    Docker.
+
 ```
 # docker install convenience script
 wget -O- https://get.docker.com | bash

mkdocs.yml

@@ -61,6 +61,7 @@ nav:
       - "Frequently Asked Questions": intro/faq.md
       - "Project Strategy": intro/strategy.md
       - "Comparisons": intro/comparisons.md
+      - "Inspirations": intro/inspirations.md
       - "Project Status": intro/bikemap.md
       - "Managed Hosting": intro/managed.md
       - "Get In Touch": intro/contact.md
@@ -91,6 +92,7 @@ nav:
       - "Install": abra/install.md
       - "Quick Start": abra/quickstart.md
       - "Upgrade": abra/upgrade.md
+      - "Design": abra/design.md
       - "Recipes": abra/recipes.md
       - "Hack": abra/hack.md
       - "Troubleshoot": abra/trouble.md
@@ -103,6 +105,7 @@ nav:
       - "Bylaws": federation/bylaws.md
       - "Finance": federation/finance.md
       - "Membership": federation/membership.md
+      - "Code of Co-operation": federation/code-of-coop.md
       - "Resolutions":
         - federation/resolutions/index.md
         - "Passed":
@@ -125,9 +128,11 @@ nav:
         - "In Progress":
           - federation/resolutions/in-progress/013.md
           - federation/resolutions/in-progress/018.md
+          - federation/resolutions/in-progress/019.md
       - "Minutes":
         - federation/minutes/index.md
         - "Recently":
+          - federation/minutes/2024-29-03.md
           - federation/minutes/2024-02-01.md
         - "Archive":
           - federation/minutes/2022-03-03.md