Document contents, purpose, plans and history of all repositories in the os2forms organisation

[janhalen]

To make it transparent and clear what purposes the different repositories serve in the os2forms organization, could the description in the README ⬇️ be improved to be more welcoming to collaborators and to make it more appealing to get involved for newcomers?

Solution main repositories:

Drupal core incl. installatioj profile: https://github.com/OS2Forms/os2forms8

OS2Forms forløb profile: https://github.com/OS2Forms/os2forms_forloeb_profile

OS2Forms main Drupal module https://github.com/OS2Forms/os2forms

Lets discuss how the purpose, history and plans for each repository in the os2forms organisation can be documented in the best possible way, in the os2forms_docs.

[janhalen]

Additionally, if the os2forms core product depends on custom code from other repos than the ones contained in the os2forms organisation (e.g. from os2web or a development partner repo) it should be documented to help the process of scoping an os2forms core.

[janhalen]

@lilosti @skifter @ds-bellcom

To get this conversation started, I can come up with some suggestions with example,s and then you can chip in below with comments about the feasibility and implementation issues.

Here goes:

The source code for the "core" version of os2forms with the modules accepted into core is located in the os2forms organization in the os2forms repo. The repo structure COULD look like this following Drupal best practice.

os2forms/os2forms ├── web/ # Drupal root │ ├── core/ # Drupal core (managed by Composer) │ ├── modules/ │ │ └── module_a/ # Custom modules specific to this project │ │ └── module_b/

My experience with the os2forms development history means that i might be mising somthing.. Lets discuss deviations here then. The structure should be configurable in the composer.json even with some changed paths when building.

Another repo with modules that only a few members are using and are NOT included in the core-maintenance contract could be structured in a seperate repo:

os2forms/contributed-modules ├── modules/ │ ├── module_x/ │ │ ├── src/ │ │ ├── tests/ │ │ ├── module_x.info.yml │ │ ├── module_x.module │ │ └── composer.json │ ├── module_y/ │ │ ├── src/ │ │ ├── tests/ │ │ ├── module_y.info.yml │ │ ├── module_y.module │ │ └── composer.json

The last category of modules that are only in use by one single member, should be placed outside the os2forms organization and only if a larger group of memebers want to invest in the development and/or maintenance of the it could be proposed to be included in the "contributed-modules" repo in the os2forms org.

What do you all think? Lets talk about it!

[ds-bellcom]

Hi @janhalen (and @Tgjerulff, @lilosti and @skifter).

It sounds like a really good plan and something we at Bellcom would really like to take part in looking into.

The release we have coming up here in Q4/24 is primarily a cleanup release, so it will be something we would really like to look into once we have done the cleanup. Then it will also be more clear to see what is included in the central maintenance agreement and what is not.

Unfortunately, I do not know if it requires major changes in our setup if we are to move our customers' solutions from using "/OS2Forms/os2forms8" to "/OS2Forms/os2forms" or if it is an easy change. But we must have looked into it for sure.

I would like to know what happens if a module goes from being a "contributed module" to becoming a "core module". Should the code then be moved from one repository to the other? And how does it affect the solutions? I think that there will be changes every six months when there is a new release, so it should preferably not be something where we make it more difficult for ourselves.

Is this something we should meet about in December or January so that we can get started on this and everyone agrees on how to do it?

[janhalen]

Unfortunately, I do not know if it requires major changes in our setup if we are to move our customers' solutions from using "/OS2Forms/os2forms8" to "/OS2Forms/os2forms" or if it is an easy change. But we must have looked into it for sure.

@ds-bellcom: It should be possible to build both a "core" release package/container and several other "custom" releases for customers that deviate from "core" - The "core" build should live in the Os2 repo as a github action, like in other os2 products and how to run that build with a customer configuration should be documented, preferably with at deployment template present in the os2 org in a "deployment-templates" repo.

Custom builds and other more tightly coupled ways of delivering Drupal can live in the operations partners repo/CI-CD pipeline together with custom configs for the customers.

Most of the module loading could be configured with a composer.json with the right paths setup, but the builds would need some design work, to reach the goal of a more universal way of deploying os2forms.

[janhalen]

I would like to know what happens if a module goes from being a "contributed module" to becoming a "core module". Should the code then be moved from one repository to the other? And how does it affect the solutions? I think that there will be changes every six months when there is a new release, so it should preferably not be something where we make it more difficult for ourselves.

@ds-bellcom: First of all, enabling transparency, reviews and accountability on a codebase IS "more difficult", no doubt about that. As the coordinating comitee has descided that they wish a product that is reduced in functionality and a more transparent way of defining what is an official part of a "os2forms core" distribution, this is what could be done to support those descissions.

I recommend that the code is contributed via a PR, so the acceptance and the technical review is fully transparent and can be monitored in public and by all stakeholders. If the code is accepted into core both for its functionality, its strategic fit and its technical qualities, it could be deleted (or archived if preferred) from the "contributions" repo and continue its life in the os2forms repos modules folder.