Anyone in the world can review and build your own articles and codes, and send it to the repository, provided that follow the paper of the designer, if you want to develop an idea, a person can meet with other interested community volunteers to create a paper.
The main projects are sliced into levels and modules, with priorities and different times, each level and module can be cut into different roles, and functions can be divided between a team or other group of people or individual person.
Priority levels are defined by primary parts, where other modules are dependent on their completion, for example, Dk itself is dependent on the completion of the computing structure, intelligent and evolutionary network BSDK which is dependent on AI algorithms and metaprogramming, which is dependent on evolutionary and altoML models, which is dependent on volunteer organization and optimal resolution proposals.
These priority levels are highly dependent on each other, so completing one leads to prioritizing the next, and all updates are kept in the background and open to volunteers for correction and optimization.
So each function and module has its dependencies, the dependencies have higher priority, which does not mean that other functions cannot be worked on.
Both individuals and teams can work on the DFM model independently from anywhere in the world, delivering papers in a development process, or reviewing papers delivered based on main projects, teams or people can also submit motions for resolution through paper and even ask for funding and support.
From the paper, all functions can begin to be developed, ideally starting at the priority level.
In an open project, roles are distributed, anyone can work on specific roles, the role gives an overview of roles and can be updated over time, roles can also be broken down into smaller roles and it is recommended that each function is independent, and only modules have functional dependencies.
A module may not be independent, as it needs functions for its operation, since a function must be independent and fulfill, well, a single function, so the modules use the functions to perform other functions through them.
These issues are important from both a technical and organizational point of view, so that each person can work on as many roles and modules as they want, while dedicated times are used for priority, integration, and review.
Initially a github repository will be created for paper resolution, submission and review purposes only, another repository will be created for funding and support proposals and requests in conjunction with our temporary DAO on the aragon platform.
Ex:
The most commonly used model for DFM in main projects is metaprogramming, where volunteers design a training and testing environment where A.I algorithms create an optimal solution to a problem in the form of functions that can be used in the BSDK framework.
The entire process is documented and optimized so that anyone in the world can review and collaborate on the proposal, seeking the best solutions to the needs presented.
To participate, you can choose a method for your proposal that best fits your project or resolution.
Agile development models and scientific method.
Falsificationism
Deductive hypothetical method
Bayesian Process and the Occam's razor
A.I modeling, simulation and various techniques for building optimal solutions and metaprogramming.
Voluntary and collaborative project creation models related to Drayker and its ecosystem.
Proposals, projects and general initiatives of volunteers outside the DFM models or with their own methodology can be organized in this repository and community.
No permission is required, any volunteer can create their outreach, content, proposals and protocols as they please.
In the EI repository, volunteers can expose their projects and initiatives, get volunteers, ideas, help, crowdfunding, support, and many other resources, and can also be used as a forum for Drayker-related initiatives.
Each method has a specific repository, within which repository can be discussed the fundamentals of each method, optimizations, method-related improvement and resolution proposals, learning, design patterns, tools and everything else related to the repository-specific method.
When a motion for a resolution is applied to a project, it must use one of the methods, and pass the protocol until it is approved as a secondary project, incorporated into the main project or other projects.
Environment of falsifiability, attacking ideas and proposals from all sides and proposing solutions.
