wip: docs: moar resolutions

See coop-cloud/organising#583

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/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/021.md

@@ -1,57 +0,0 @@
----
-title: "Resolution 021"
----
-
-- Topic: Budget 011: Migrate to Cobra
-- Date: 22-07-2024
-- Deadline: 31-07-2024
-- Size: Large
-
-### Summary
-
-Migrate away from our current command-line dependency so `abra` usage is more predictable. The goal is to maintain feature parity with no breaking changes. The main advantage that we will get is robust and flexible handling of flags/arguments which don't depend on forcing a specific order (see [`#581`](https://git.coopcloud.tech/coop-cloud/organising/issues/581)). There are other bonuses such as built-in support for auto-completion, better handling of example usage, improved support for global flags (`--debug`) and manpage support.
-
-### Details (Budget 011)
-
-#### 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 `<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.
-
-#### The solution
-
-[Several](https://git.coopcloud.tech/coop-cloud/abra/pulls/404) [attempts](https://git.coopcloud.tech/coop-cloud/abra/pulls/435) have been made to upgrade `urfave/cli` to fix this behaviour. However, as it turns out, it is **highly unlikely** that they will fix this upstream: [`urfave/cli#1950`](https://github.com/urfave/cli/issues/1950) [`urfave/cli#1928`](https://github.com/urfave/cli/pull/1928) (and even this proposal does not really include the desired robust flexible handling we need).
-
-`@decentral1se` has done a spike to confirm that [`cobra`](https://cobra.dev) handles flexible handling of arguments/flags. Those reading this proposal and wishing to try it out for themselves can take [Hugo](https://gohugo.io/) for a spin (it uses `cobra` as the underlying command-line library).
-
-This tool is well maintained and used by several large projects such as Hugo and Kubernetes. The library matches all functionality we require.
-
-#### Budget
-
-`@decentral1se` can carry out this work.
-
-Proposed budget of 15 hrs: `15 hrs * 20 = 300 EUR`

docs/maintainers/tutorial.md

@@ -52,17 +52,6 @@ Open the `compose.yml` in your favourite editor and have a gander 🦢. The
 
 The resulting `compose.yml` is available [here](https://git.autonomic.zone/coop-cloud/matomo/src/branch/main/compose.yml).
 
-### Updating the `.env.sample`
-
-Open the `.env.sample` file and add the following
-
-```
-DB_PASSWORD_VERSION=v1
-DB_ROOT_PASSWORD_VERSION=v1
-```
-
-The resulting `.env.sample` is available [here](https://git.coopcloud.tech/coop-cloud/matomo/src/branch/main/.env.sample)
-
 ### Test deployment
 
 !!! note "Running Co-op Cloud server required!"

docs/organisers/proposals/federation.md

@@ -61,7 +61,7 @@ As a member of Co-op Cloud, you'll be able to:
 
 - Receive announcements about opportunities for funded work on Co-op Cloud early, before they're sent out to the wider community.
 
-- Use shared Co-op Cloud services, including code hosting ([git.coopcloud.tech](https://git.coopcloud.tech)), continuous deployment ([build.coopcloud.tech](https://build.coopcloud.tech)) and any future digital infrastructure we all decide to set up.
+- Use shared Co-op Cloud services, including code hosting ([git.coopcloud.tech](https://git.coopcloud.tech)), continuous deployment ([builds.coopcloud.tech](https://builds.coopcloud.tech)) and any future digital infrastructure we all decide to set up.
 
 ### Responsibilities
 

mkdocs.yml

@@ -130,7 +130,6 @@ nav:
           - federation/resolutions/passed/020.md
         - "In Progress":
           - federation/resolutions/in-progress/013.md
-          - federation/resolutions/in-progress/021.md
       - "Minutes":
         - federation/minutes/index.md
         - "Recently":