Governance should show who can make a decision

A governance document becomes difficult to trust when it describes a process that participants no longer use. A newcomer can follow the published rules and still miss the place where decisions happen. Simplification can close that gap, provided it makes authority and accountability easier to see. Removing procedure without explaining who can decide merely moves the uncertainty elsewhere.

Django’s April 16, 2026 proposal sought to align written governance with operating practice after the Steering Council had suspended its formal voting process the previous year. It gave July 1 as an intended adoption target. The September 22 approval announcement later confirmed approval of DEP 19 by the Council and DSF Board. That later confirmation must remain separate from the April proposal and its target date.

A process needs an address

A contributor with a technical proposal needs to know where to take it. They also need to know who may close the discussion, what kind of agreement is sufficient and where to raise an unresolved objection. A document can answer those questions in a few clear paragraphs or obscure them across several pages. Length is a poor proxy for whether the process is usable.

The practical test is to follow a decision through the written rules. Begin with a plausible disagreement about a change to a project. Identify the person or body responsible for receiving it and the action which turns discussion into a decision. Then look for the record which allows someone absent from the conversation to understand the outcome. Any missing step deserves attention before shortening the text.

This exercise does not require a project to expose every informal conversation. People need room to explore ideas before making proposals. It does require a visible point at which informal discussion acquires authority. Otherwise familiarity with existing participants becomes an unofficial qualification for effective participation. A simpler document should lower that dependence on personal access.

Distinguish permission from responsibility

Being allowed to decide is different from being responsible for explaining the decision. A council may have the authority to settle an issue, while a named participant maintains the record and communicates what happens next. Combining those duties can work in a small group. Leaving them implicit makes it harder to tell whether an unresolved issue is awaiting a decision or merely an announcement.

For a technical leader, this distinction helps diagnose stalled work. More meetings will not necessarily fix an unclear decision right. Nor will a new voting rule guarantee that anyone explains the result to contributors. Ask which obligation is missing and write that obligation down. A useful rule connects an action to a responsible role and a place where the outcome can be found.

The historical dates illustrate another responsibility: reporting the state of the process accurately. A proposed timetable tells participants what the authors hope to achieve. Approval establishes a different fact. The gap between the two does not, by itself, prove why the schedule changed or how well the process worked. Avoid filling that gap with an invented account of disagreement, delay or internal politics.

Formal votes have a protective purpose

The strongest objection to simplification is that formal procedures can protect people who are uncomfortable challenging a confident group. A vote can force an explicit position, preserve an objection and make the decision threshold visible. Informal consensus can leave a minority wondering whether silence was taken as agreement. That is a real design concern, even when the participants act in good faith.

The response should be proportionate to the consequences. A reversible editorial decision may need little procedure. A decision which changes participation rights deserves a clearer route for objections and review. The point is to match the protection to what is at stake, rather than to celebrate the absence of votes as an achievement. Consensus still needs an account of how unresolved disagreement is handled.

A project can also distinguish between recording dissent and allowing every objection to stop work indefinitely. Those are separate choices. A readable process can explain what happens to an objection without promising unanimity. The safeguard is strongest when participants understand it before the disagreement begins, including people who cannot attend the meeting or follow the discussion continuously.

Check the process through ordinary use

A governance rewrite should be tested with people who lack the authors’ background knowledge. Ask them to locate the route for proposing a change and the person who can resolve a disagreement. If their answers depend on someone explaining unwritten customs, the document still has work to do. This is a proposed usability check, rather than a claim about testing performed by Django.

The same check belongs in a custom software engagement when several people can request changes. The team needs to know who agrees the scope and who accepts the consequences of a trade-off. A short decision record can be enough. Borrowing a foundation’s full governance structure would usually add obligations which the project has no reason to carry.

The useful deliverable is a process that someone can follow without guessing where authority lives. Keep the procedures which make participation and dissent legible, and simplify the ones which obscure ordinary decisions. Then keep the written process aligned with what participants actually do. That continuing responsibility matters more than presenting the rewrite itself as the end of the work.