Steward Governance

The project is under steward governance, in which a small group of core stewards look after the overall direction and coherence of the spec family, while a broader set of editors are responsible for individual specs.

The rules for changing a spec depend on its maturity. Early on, editors change specs freely. As a spec stabilizes and implementations come to rely on it, changes require more care and wider agreement.

This approach distributes power more than a BDFL would, without taking on the full complexity of a more polycentric, representative approach. Delegating specs to their editors keeps work moving, reduces bottlenecks, and makes the best use of specialized expertise. We believe this is appropriate for the DASL Project's current maturity and complexity, but we invite you to challenge this if you disagree. As the project matures, we expect it to develop more complex governance with stronger democratic properties. Should that not happen, at the very least the people involved in core governance need to be rotated out so as to avoid the evolution of an oligarchy.

DASL Core Stewards

The DASL Core Stewards are tasked with overall stewardship of the project. This includes:

• Agreeing that new work should be undertaken.
• Resolving disputes that can't be resolved by the community and editors.
• Appointing and, if necessary, removing spec editors.
• Maintaining governance documents.
• Supporting the community and modelling the welcoming, creative, and effective culture that makes people want to use DASL.

Core aims for 3–5 members, small enough to stay coherent. New stewards are invited by existing members, based on sustained contribution and a track record of constructive collaboration. A steward may step down at any time. Core decisions, including removing a steward, require a two-thirds majority.

Our accountability is to one another and to the community. In practice, that means working in the open, explaining our decisions, and staying open to feedback.

Current members of DASL Core (alphabetically by last name):

• Robin Berjon
• Juan "Bumblefudge" Caballero
• Michelle Lee

Editors

Editors are responsible for the specs that carry their name. They are the primary contact to discuss the spec and to whom issues ought to be addressed.

A spec may have one or more editors, who share responsibility and are expected to reach decisions among themselves.

An editor's authority over a spec follows its maturity level (see Maturity Levels).

Editors are chosen by Core (often simply for being whoever proposed the work) and can be removed by Core. If an editor steps down or becomes inactive, responsibility for the spec returns to Core.

Note for Editors: When you bring a spec into the world, other people will disagree with your choices. Sometimes, those people will be right. Or maybe they'll be wrong but the community will nevertheless agree with them. Editors are expected to keep a healthy distance from their specs, so as not to become emotionally invested in any particular aspect.

Maturity Levels

Specs move through 4 maturity levels, which signal both how reliable the spec is and what kind of change process it lives under. Core stewards, in consultation with the editor, decide when a spec changes levels.

Proposed

Just a proposal, in a PR or an issue. It will get dropped unless Core agrees to take it on.

Hot New Stuff

Promising but unstable. Expect the editor(s) to change it freely. Experiment with it, but don't have anything critical relying on it.

Stabilising

Specs are likely to spend a fair amount of time here. Editors can make editorial changes and minor tweaks. Breaking changes need community review: a PR left open for two weeks or until it gets two approvals, whichever comes first.

Stable

Tested, deployed, and not expected to change. Breaking changes are only made for overwhelming reasons. Any changes beyond typos require Core approval and a PR left open for community review for at least two weeks.

There are 2 additional levels:

Abandoned

Specs that reached any level of maturity, but are no longer maintained.

Informative

This is reserved for documents that don't expect to be implemented in code.

New Work

The DASL project focuses on small, orthogonal specs that compose into larger wholes. Because each spec is comparatively cheap to produce, we can accept new work more readily than projects built around large, monolithic specs. It does not, however, mean that we should accept anything.

When new work is proposed, Core weighs these criteria together. They guide assessment rather than serving as a checklist, and Core's decision is final.

Implementation

Is the proposer implementing? Is there interest from other implementers? Are we likely to see more than one implementation?

Useful

Is there a clear use case for the spec? Is there more than one person stating that they'll want to use this in a credible scenario? Is it encoding existing practice or at least addressing pain that is widely felt?

Integration

Does the proposed spec integrate well with the other primitives? Does it make use of them or enrich them? Are there clear use cases in which other specs get used with the proposed one?

Do The Work

Will the proposer do the work of producing and maintaining the spec, and ideally contribute to testing and advocacy? Are they good at cooperating with others? Might they drive interest from others such that someone will step up to replace them if needed?

Community Support

Do the people affected (implementers, likely users, related editors) support or at least accept the proposal? Can objections be resolved through discussions or changes? We can't always reach full consensus, but we want to avoid work that proceeds over sustained, reasonable objection.