Turn a shared problem into work people can deliver.
DFM is the method proposed for organising work as connected functions and modules. DFMP is the public path for developing that method and examining how it works.
A function states a purpose, the context it needs and the result others can evaluate. Related functions form modules that remain connected to the larger objective.
Well-defined work makes participation more accessible and helps collaborators retain responsibility for the quality and direction of what they build.
A practical example
A contributor could take one documented modelling task, publish the result and show how it changes the module that depends on it. This is an illustration of the proposed design.
Why this exists
DFM is the method half: how a problem becomes functions that people who have never met can each finish a piece of.
The argument in full is on the manifesto. The economy page states plainly what contributing here earns and what it does not.
The method
- Model. The issue is modelled and modularized, with the initial strategy expressed as a Bayesian model. Before any code, what is known, what is assumed, and what would change the strategy are written down.
- Fragment. The problem is partitioned into small functions.
- Distribute. Functions are distributed among collaborators through decentralized peer review. Nobody is assigned work. Contributors claim what matches their skill.
- Review. Ideas are discussed with communities and councils and turned into a comprehensive, widely revised paper. Validation runs alongside development, not after it.
- Integrate. A contribution is proposed in an issue, developed on its own branch and submitted as a pull request to
master. Automated checks and public discussion preserve traceability. During the founding phase,Hyadhuadmay also integrate directly under the organization governance policy.
The protocol adapts to different kinds of project, but the logic does not change.
Principles
- Simplicity and cleanliness
- Automation
- Relation and documentation
- Agile development is evolutionary
- Worldwide collaboration
- International community, local emergence
Science inside DFM
DFM can be used with different methodologies. Combined with the scientific method, it helps build a paper and works as a validator and optimizer of hypotheses.
The path starts with a question to be answered. Then come hypotheses about the question and its solutions. The hypotheses are elaborated, evaluated and revised, and the weight of their claims is measured: how well supported and validated they are. From them an adaptive, Bayesian theory is built that integrates the hypotheses and keeps being improved and revised as evidence accumulates and whenever it is falsified.
In DFM, hypotheses are functions and theories are modules. Modular sets of theories let the system be validated and evolved in layers. A theory that no longer describes new data and situations is replaced without compromising the whole system, in an evolutionary scheme similar to the biological one, but continuous and directed toward optimizing purposes and extrapolating to the new.
The D, distributed, stands for data systems and claims based on proof: a reliable environment where these theories, that is, modules, run in a distributed way and feed back into each other. Each module and function plays a part in validating and testing the strength of the others.
What a resolution paper contains
Before a project is developed, it needs a paper, reviewed and approved by peers. The paper contains all the logic involved and its mathematical demonstration. The functions are well specified within its scope, and implementation and architecture are kept as simple and redundant as possible.
Each function needs a precise description and, above all, an account of error and attack: proposed attacks and a real mathematical proof that it works. A paper may reuse functions from other papers. The modules that integrate the functions keep the simplest possible architecture and are reviewed and catalogued extensively in the documentation, with a structure that stays evolutionarily compatible.
DFMP · the proposal process
DFMP is the path a proposal takes from an idea to a legitimated paper. The protocol has to ensure that papers created from it are self-assessed, validated and re-evaluated. Before entering the approval process, a paper must have been presented to the community through the issues and widely discussed. All goals and purposes must be in line with Drayker.
dfmpp/ holds the proposals themselves.
How it fits the whole
The method is the first layer of the ecosystem, and every other layer runs on it.
Drayker is designed so that thousands of strangers can work on one thing without a manager in the middle: any issue is broken into functions small enough for one person or one agent to finish, and Dk can help match them to context and capacity. The same vocabulary of functions and modules is the language the BSDK base structure is proposed in. Operational symmetry stops there: members remain responsible for consent, review and constitutional decisions, through the constitutional procedure, built with Dk Global and within the kernel. Meta DFM formalizes the method itself; councils are designed for validation; the Academy connects formation to functions; Dknowledge keeps the papers traceable; and DAF is a transitional governance scaffold the same proposals can feed into. The method is the one part genuinely in use today — which is the whole point of starting there.
State of this documentation
The method and the proposal path are written down. DFMP-000, the paper that should specify the proposal process itself, is currently a title and nothing more. Writing it is the most useful thing anyone could contribute here, and it does not require permission. Open an issue with the draft.
Contributing
Open an issue in this repository. Issues small enough for one person to finish carry the open-function label and appear on the board at drayker.org.
Related: dfmpproject (proposing a project through DFM) · metadfmp (modeling the method itself) · dknowledge (papers and roadmap).
English is the canonical language of this documentation; read other languages through automatic translation. Native translation and localization are planned for the Drayker sites.
DFMP and DAF describe proposed collaboration and governance architecture. Drayker’s current founding-phase governance is documented in draykerdk/.github, and the work is primarily voluntary. Content licensed CC BY 4.0.