Skip to main content

Processes

Public Stack Processes

Every device, application, and protocol in the technology stack is the result of a design process — it determines whose thoughts and interests get digitalised, and has a decisive influence on how digitalisation takes form. A good one involves the people affected, names what it's trying to optimise for, and tests ideas before committing to them; what counts as good is agreed upon before it starts, in the Foundation.

We extend that beyond design alone. Every process — how we design, how we maintain, how we live inside the tools — shapes the experience of the citizens using the stack, not just the one that produces the first version. A process that excludes people produces a stack that doesn't fit them; one that's transparent and open to participation produces a stack people actually want to use. This is also why maintaining isn't purely technical: who keeps things running, how work is made visible, and who can take on more responsibility over time are design questions too.

Self-organisation is the connective tissue across all of it. Residents, makers, and stewards each engage with the stack differently — but the processes they follow should let roles emerge naturally, responsibilities get picked up voluntarily, and knowledge spread rather than concentrate. No single person or role should be a bottleneck.

Five processes

Organising — making work visible and ownership declared: what exists, what state it's in, and who to reach when something needs attention.

Designing — how services get chosen, shaped, and introduced. What problem does this solve? Who is it for? Design happens before deployment and shapes whether something gets used.

Living — the day-to-day experience of residing in the stack: using the tools, finding things, getting things done. The resident doesn't maintain the infrastructure, but their experience of it is what the whole stack is ultimately for.

Maintaining — the technical work of keeping services running: infrastructure provisioning, OS configuration, deployment, updates, and monitoring. This is the steward's domain.

Archiving — keeping a record of what was tried, what worked, what didn't, and why, so knowledge outlives whoever built something.