Updates

186 Articles Before Day One

We wrote the entire operating manual before launching. Not because we had to - because building in the open means the community sees the blueprint, not just the building.

186 Articles Before Day One

Building Before Building

Ktown Team hasn’t launched yet. There are no active programs, no running teams, no open offices. We’re in the founding stage - establishing the legal framework, designing the platform, and documenting how the organization will operate.

And yet the wiki already has 186 articles across 16 collections. A guided reading path walks through 130 of them in sequence. The rest are reference material - legal documents, individual tool pages, team descriptions.

That might seem backwards. Why write the manual before building the thing?

The Blueprint Argument

Most organizations launch first and document later - if they document at all. They start with energy and good intentions, hire people, run programs, and figure out how things work along the way. The documentation, when it comes, is an afterthought. A retrospective. A formality for funders.

The problem is that by the time you document how something works, the decisions that shaped it are already forgotten. Why did we choose this governance structure? Who decided the budget would work this way? What was the reasoning behind this policy? Those answers live in old emails and the memories of people who may have moved on.

We wrote the documentation first because the process of writing forces the process of deciding. You can’t document a budget process without designing one. You can’t describe how teams work without thinking through what a team actually is. You can’t publish bylaws without making the hard calls about governance, authority, and accountability.

The wiki isn’t a record of what happened. It’s a declaration of what we intend.

What 186 Articles Cover

The wiki spans the full scope of how a community organization operates:

Each collection connects to the others. The governance framework references the team structure. The team structure references the platform tools. The platform tools reference the initiatives they support. It’s designed to be read as a whole, not as isolated pages.

Open Development in Practice

We use the term open development to describe how we build. It means the process is transparent and documented publicly. The wiki is the most visible expression of that.

Open development isn’t the same as inviting everyone to contribute code or suggest features. It means the decisions are visible. The reasoning is documented. The trade-offs are explained. If someone wants to understand why we chose a flat hierarchy over a traditional board structure, the article exists. If they disagree, they can point to the reasoning and make a case for something different.

That’s the point. Transparency isn’t useful if it only shows you the answers. It’s useful when it shows you the thinking.

What Comes Next

The 186 articles describe what Ktown Team is designed to be. What it actually becomes depends on the people who show up, the problems that emerge, and the community’s evolving needs.

Some articles will need revision. Some processes will work differently in practice than they do on paper. Some tools will be built in a different order than planned. The wiki will change as the organization does.

But the foundation is there. Anyone who wants to understand what Ktown Team is building - or challenge how we’re building it - can start with the wiki. That’s the whole idea.