**Note** This DD architecture diagram can be found in code respository in [editable][diagramedit] format. Like the rest of the whole code, you can suggest modifications
This methodology focuses on self-organized team dynamics, interpersonal collaboration, and individual and team learning in a way that allows integrate the *Open Source* nature of **DD** with feedback or update cycles in the schools that are part of the pilot project and the technical needs of the project.
1.**Speculation**: In this phase a plan is made taking into account limitations and needs of the project, users, etc. writing issues, feedback or failures, in order to define the cycles.
2.**Collaboration**: In this phase we organize and work together, always taking care that working people must:
3.**Learning**: Whether a desired result is reached or not, this process will help everyone involved, as it will increase the understanding of the project and its associated technologies. While working together [Merge Request][mr] and their associated reviews, as well as the communication between team working on and reporters are a crucial part.
To simplify the review work and to ensure certain quality of what is integrated in repository:
- Nobody can direct `push` to `main` branch (`main`).
Always is necessary to follow the [Merge Request][mr] review proces.
- ** TO BE REVIEWED ( branch based events?? )** There is a [buildbot][buildbot] instance (in `ci.dd-work.space`, login via GitLab) as a Continuous Integration that reacts to `push` events in `main` branch and to [Merge Request][mr] events in any other branch.
- When the event is a [Merge Request][mr], only static checks are executed, so no complete tests are launched.
This is to prevent crypto mining CI/CD abuse.
These checks are the same as:
[ShellCheck][sc] for shell scripts, [mkdocs][mkdocs] to check that the documentation is generated as it should, soon we'll add linters and standard python checks.
- When the event is a `push` to `main`,
additionally to the [Merge Request][mr] tests, it will start the installation process from the scratch in a virtual machine.
This helps in detecting problems and makes sure that DD can be correctly.
- Members of group `DD-workspace` in Gitlab have administration permissions in Buildbot instance, this allow them to start or cancel build tasks manually if it is required.
