# Governance of the DASL Project The goal of the DASL Project is to develop content-addressing technologies and technologies that benefit from content-addressing primitives, with a view towards supporting the kind of unbundled software and protocol architectures that best align with and promote democratic governance. ## Steward Governance The project is under steward governance, in which a group of people who have proven themselves in the care and feeding of the project and are therefore respected by the wider community hold the ultimate say. This approach distributes power more than a BDFL would while not yet pulling in the full complexity of a more polycentric, representative approach. We estimate that this is appropriate for the project's current maturity and complexity, but we invite you to challenge this appreciation if you disagree with it. As the project matures, we expect it to develop more complex governance with stronger democratic properties that don't rely on, essentially, everyone knowing everyone else. 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](https://berjon.com/transmutations/). ## DASL Core The DASL Core people are tasked with 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. - Maintaining governance documents. - Generally supporting the community, modelling good behaviour, making people want to use DASL because of how cool, welcoming, and creative the community is. Our accountability is to one another and to the community. As per steward governance, DASL Core works on the principle that we wouldn't want to disappoint each other and the community. Current members of DASL Core include (alphabetically by given name): - ??? maybe B - ??? maybe E - ??? maybe E - Juan "Bumblefudge" Caballero - Michelle "Mosh" Lee - Robin Berjon ## Editors Editors are responsible for the specs that have their name on them. They are the primary contact to discuss the spec and the people to whom issues ought to be addressed. Editors are chosen by Core (often simply for being whoever proposed the work) and can be removed by Core. 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 maintain a healthy distance with their specs so as not to become emotionally invested in any particular aspect. ## Maturity Levels DASL specs can have multiple maturity levels, which are used both to convey how reliable they are and what kind of change process they exist under. Proposed This is just a proposal, in a PR or an issue. There should be no expectation from the spec whatsoever. This will get dropped unless Core agrees to take it on. Hot New Stuff This is promising but unstable. Expect the editor(s) to just change it willy-nilly. Definitely experiment with it but don't have anything critical relying on it. Stabilising Drafts are likely to spend a fair amount of time at this maturity. It's fine for editors to make editorial changes and relatively minor tweaks but anything that breaks implementations needs to be discussed with the community. Stable This is for tested and deployed specs that we expect not to change at all. Because the future is unknowable, it's possible for changes to happen if there is an overwhelming reason to, but breaking changes must be near-impossible. Changes other than typos require Core approval and ideally community review. Abandoned This is used for specs that were accepted at some point and reached any level of maturity, but were then given up on. Informative This is reserved for documents that don't expect to be implemented in code. ## New Work An important focus of the DASL project is on producing small, orthogonal specs that can be composed into larger wholes. This means that any given spec is expected to be comparatively cheap to produce (at least relative to the monster specs often produced elsewhere). In turn, this means that we may be able to accept new work more easily. It does not, however, mean that we should accept anything. These criteria will be considered by Core whenever new work is proposed: 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 Is it clear that the proposer will do the work of producing and maintaining the spec, possibly also contributing 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? No/Low Community Objections Is there no opposition from the community? If there is, is it reasonable? Can it be tempered? We can't always obtain full community consensus, but we do want to avoid work that takes place over sustained reasonable opposition. Core Is Final Ultimately, Core's decisions here are final. ### Proposing New Work If you want to propose new work, please go through the following steps: 1. Check that you meet the criteria above. If you think that you don't quite meet them yet but could with some help, that's cool! Do reach out, just with the expectation that the discussion might be longer. 2. [Open an issue in the DASL repo](https://tangled.org/dasl.ing/dasl.ing/issues/new) in which you explain what your proposal is, addressing the questions raised by the criteria. 3. It's encouraged (but not required) to [post your proposal to the Atmosphere](https://mu.social/) so as to encourage wider discussions. 4. Take the ensuing discussion in good spirit! People are busy and not always able to turn around comments very quickly. Don't take it personally, it doesn't mean that anyone hates your baby spec.