Drayker pap.drayker.org
Platform

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 & Applications

Compose projects and carry successful work into lasting applications.

Projects & Applications is a system in which intentions become projects composed of functions and modules, and projects evolve and can become durable applications. It is also the environment in which organization, knowledge, participants and resources can be distributed among units. PAP organizes the passage from intention to project: it makes it possible to describe a purpose, break it down into functions, link it to available capacities and follow what happens. This repository 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.

Project and application

A project is liquid and highly experimental. An application is more solid: its terms are defined, its organization has settled, and it changes less often because it has reached a form that works. Every application passes through being a project, and when it becomes one it loses none of its project functions; it gains new ones. The project stops reinventing every process in every cycle. This stability frees work for new problems, and the possibility of revision makes it possible to correct the form that has stabilized.

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.

A society also distributes the power to begin. Some can gather capital, hire a team and turn an intention into reality; others spend their lives finding problems they know how to formulate but never have the means to work on. In PAP, a question a member presents reaches accumulated knowledge, other experiences of the same problem and capacities that can be mobilized. The path to realization no longer depends on wealth, position, social class, appearance or the story of where one comes from. It depends only on present reality and on what each person does.

How a project would be built

Five ways, combinable rather than exclusive:

Projects are generic. A project can be an organization of members, a research effort, an application, an improvement to the system or a person’s own plan of life and study. Projects can be created inside other projects and applications, communicate, share resources, merge, and join with others to form new projects.

Any open project can be reused as the base of another and adapted, and an improvement validated there can return to the original. Versions are tested in parallel by projects with different proposals; the network integrates validated improvements. 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.

As a project shows progress, the network relates it to more knowledge, computation, infrastructure, funding and people. If another project is already heading in the same direction, the intelligence suggests integration instead of duplication. If a problem demands very different capacities, it brings together specialities that would never meet through current institutional channels.

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.

How a project would flow

A project would move through these stages:

  1. Intention.
  2. Project.
  3. Functions.
  4. People, agents, knowledge and resources.
  5. Execution.
  6. Result.
  7. Dknowledge.
  8. Review or integration.
  9. Application, or a new attempt.

The DFM method covers the middle of this flow.

Functional decomposition makes it possible to gather specialities around problems that exceed any isolated team. Scientific research, software development, instrumentation, manufacturing and validation can advance on different fronts, linked by dependencies and integration criteria, and each front keeps those responsible for it, its results and knowledge usable by the others. What forms in this way is a collective intentionality: intentions, knowledge, needs and capacities distributed among the participants relate to one another and become common action, without requiring unanimity or a majority. Showing each person what their function does in the whole gives the participants back a view of the shared work.

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 project receives collaboration when it has a public form: the problem, the expected result, the functions needed, the resources available and the way what was done will be examined. With that clarity, the ambition can be large and the commitments the size of present capacity. 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

Not in scope

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, the first phase in the distribution of the Drayker Embassy’s power and a basic, primitive form of PAP, implemented now to test its dynamics in the construction itself. 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. As PAP matures, each project increasingly carries its participants, its Dknowledge, specialized Dks, modules, rules and resources. DAF serves to build the independent infrastructure that will make it unnecessary, and so it prepares its own dissolution: it stops being a separate layer and comes to live inside PAP. 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. A partnership around a project has to widen the capacity to realize the common purpose; its reach, its counterparts and the rights over what it produces are known, so that support for the construction stays distinct from a dependence that hands its direction to another interest. Ongoing functions inside a project require recognition of cost, responsibility and the conditions to stay.

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, starting from the qualitative criterion above: defined terms, a settled organization and a form that works.
  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 a project can run today, before any allocation of common capacity: 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 draykerdk/.github. 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

Part of Drayker · content under CC BY 4.0