Projects & Applications

Compose projects and carry successful work into lasting applications.

Projects & Applications proposes an environment for creating, adapting and connecting collaborative projects. A project that fulfils its purpose can become a maintained application.

Projects would combine functions, templates, validation and attributable participation, preserving the knowledge needed to adapt them to another context.

PAP is where reusable methods, people and knowledge are intended to meet in continuing practice.

A practical example

A local learning project could reuse a tested structure, adapt its activities and publish the changes that another community would need to understand. This is an illustration of the proposed design.

The problem it addresses

Useful structure and learning often remain tied to the group that produced them. Another initiative may struggle to reuse the work or understand why it succeeded.

How a project would be built

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.

Where this stands

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. This repository is where the public charter and a first worked example are meant to be written. A first example could look like this: a town that distrusts the water of its wells enters PAP with the problem described in public — which wells, which contaminants, what margin of error is enough — and that project sheet is what lets strangers take functions in it.

This repository develops the proposal through public documentation and review. The capabilities described here still require specifications, worked examples and implementation.

Scope

• 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

Not in scope

• A running platform, an account system or a hosting service.
• A replacement for the proposal path described in DFMPProject.
• A claim that resources entrusted to a project become its private asset, or that DAF permanently owns allocation rules.

How it fits the whole

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 carry resources entrusted to them through accountable allocations. Those resources remain bound to the purpose for which they were entrusted and return to the common funds under the agreed closing conditions; they are not a self-contained fund the project owns.

First functions

These are concrete and unclaimed. Any of them can be opened as an issue and delivered by one person.

1. Define the threshold: what a project must satisfy to be promoted into an application.
2. Write what the platform has to guarantee a project.
3. Describe one application worth composing first.
4. Argue where DFMPProject ends and the platform begins.
5. 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.
6. Specify how a governance or coordination function can migrate from DAF into PAP without importing DAF’s federative points as general reputation.

How to contribute

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.

Sources of truth

• 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