A project is how people organize around anything they want to do. An application is what a project becomes once it works.
Where an intention becomes a project, and a project becomes something that lasts.
The environment where projects are created, composed, validated, cloned and evolved, and where a project that reaches its objective is formalized into an application. A project is liquid and experimental. An application is the solid form of one that arrived. Every application was a project first. Bound to UID so participation is attributable, and to the method so a project is built from parts rather than from scratch.
This is not only for developers. A project can be a study plan, a research programme, a local group, a DAO, an organization, a piece of software. Anything that needs a goal, people and steps.
Organizing around a shared objective is rebuilt from nothing every time. The work of coordinating, the structure, the roles, the sequence, does not transfer between initiatives, and a project that succeeds has no way to become a durable thing without being rebuilt as something else.
How it works today. Every initiative invents its own coordination, and nothing that one group learns is available to the next. What worked stays a project. What failed is attempted again elsewhere.
What would change. Projects are composed from modules in a shared format, so starting one is assembling rather than beginning, and a project that reaches its objective is promoted into an application without losing what it was.
Why the rest depends on it. Without it, the method has nowhere to be practised at scale and every project stays the size of its founders.
Four ways, combinable rather than exclusive:
- With Dk. Describe what you want. A working structure is proposed and evolves with the project.
- From a template. Standard models for known purposes, copied and adapted.
- By assembly. Pre-built functions and modules connected into a structure. The method applied to the project itself.
- From scratch. Your own functions and modules, when nothing that exists fits.
Any open project can be copied and modified. The fundamentals resemble a code forge, applied to far more than code. Dk is meant to work against duplicated effort: pointing to modules that already exist, to what has been tried and failed, and to people working towards the same thing.
Projects would also carry validation and testing, predictions, modelling and simulation, so an idea can be examined before resources are spent on it, and evolved or discarded on evidence.
Drayker has internal material on the platform that is not published yet. The closest public relative is DFMPProject, which describes how a project gets proposed but not where it then lives. A repository comes only after a public charter and one worked example.
Nothing described here is implemented. This repository exists so that the first document about it has somewhere to live and someone can argue with it in public.
- Projects and applications as composable modules
- The lifecycle from project to application, and what promotion requires
- Reuse, cloning and templates across projects
- Validation, modelling and simulation before resources are committed
- Participation attributed through UID
- Relation to DFMPProject and the project queues
- A running platform, an account system or a hosting service.
- A replacement for the proposal path described in DFMPProject.
- A claim that projects carry their own money or that DAF permanently owns allocation rules.
Where projects are composed and where they become applications — the middle of the loop that turns a problem into value.
A problem enters through DFMP and is modelled as a project through DFMPProject; PAP is where that project lives, is composed, copied and evolved — one shared language of functions and modules, so a project can reuse what another already solved. Participation inside it is attributed through UID. It runs on Dk and progressively receives durable coordination functions tested in DAF. Every project and organization carries its own Dknowledge, in connection with a specialized Dk — the project's knowledge grows with the project, and reusable learning can cross scales with provenance and authorization. It closes the loop with the Academy, where a function can become a learning path, and relates needs and resources to the capacity economy. Projects may have resource relationships and accountable allocations; they do not inherently carry a self-contained fund.
These are concrete and unclaimed. Any of them can be opened as an issue and delivered by one person.
- Define the threshold: what a project must satisfy to be promoted into an application.
- Write what the platform has to guarantee a project.
- Describe one application worth composing first.
- Argue where DFMPProject ends and the platform begins.
- Describe the minimum lifecycle without any economy of its own: create, set an objective, invite a participant, review a proposal, record a contribution, and close or reuse a project.
- Specify how a governance or coordination function can migrate from DAF into PAP without importing DAF's federative points as general reputation.
Read CONTRIBUTING.md
and GOVERNANCE.md in
the organization. In short: open or find an issue, say in the thread that you are taking
it, branch as fn/<issue-number>-<short-name>, and open a pull request against
master. There is no separate review branch.
Participation is voluntary and implies no compensation, employment or future claim.
- This repository, for what Projects & Applications is and is not.
.drayker/component.yml. The machine-readable contract, validated on every pull request.- drayker.org/project/pap/. The same record inside the portal, with the live board.
- drayker.com/project/pap/. The case for it, in plain terms.
Part of Drayker · content under CC BY 4.0