docs: extract dev workflows from contributing docs

docs/contributor-manual/README.md

@@ -7,4 +7,5 @@ Welcome to the **LibreTime contributor manual**, you should find guides to impro
 - Learn about the [architecture of LibreTime](./design/architecture.md)
 - Learn about the [database design](./design/database.md)
 
+- Learn about the [development workflows of LibreTime](./development-workflows.md)
 - Start coding by setting up a [development environment](./development-environment.md)

docs/contributor-manual/design/database.md

@@ -2,6 +2,8 @@
 title: Database
 ---
 
+LibreTime is designed to work with a [PostgreSQL](https://www.postgresql.org/) database server and uses both the [PropelORM](https://github.com/propelorm/Propel) in the legacy app and [Django ORM](https://docs.djangoproject.com/en/4.1/topics/db/models/) in the API to interact with the database.
+
 ## Database schema creation and migrations
 
 The method to maintain the database schema, is to write both a migration file for already installed databases and to update a `schema.sql` file for fresh databases. On fresh installation, the database is filled with the `schema.sql` and `data.sql` files and LibreTime won't run any sql migration on top of it. Previously, when LibreTime was upgraded, the missing migrations were run using a custom php based migration tool, those migrations are now handled by Django. The missing migrations are tracked using both a `schema_version` field in the `cc_pref` table and a Django migration id.
@@ -53,3 +55,13 @@ stateDiagram-v2
 
     apply_django_migration --> [*]
 ```
+
+## Modifying the database schema
+
+To modify the database schema use the following steps:
+
+1. Modify `legacy/build/schema.xml`.
+2. Run `make -C legacy propel-gen` to regenerate the legacy files.
+3. Run `pre-commit run --all` and `make -C legacy format` multiple times to clean and format the previously generated files.
+4. Update the `api` models to reflect the changes made to the schema.
+5. Create a new schema migration file in the `api/legacy/migrations` directory.

docs/contributor-manual/development-environment.md

@@ -2,6 +2,10 @@
 title: Development environment
 ---
 
+This page describes the different way to run LibreTime in a development environment.
+
+The recommended development environment is the [docker-compose setup](#docker-compose).
+
 ## Docker-compose
 
 To setup a docker-compose development environment, run the following commands:
@@ -21,6 +25,18 @@ docker-compose up -d
 docker-compose logs -f
 ```
 
+:::info
+
+You may also use the following `make clean dev` shortcut:
+
+```bash
+make clean dev
+
+docker-compose logs -f
+```
+
+:::
+
 ## Vagrant
 
 To use Vagrant, you need to install a virtualization engine: [VirtualBox](https://www.virtualbox.org) or Libvirt. The [vagrant-vbguest] package on Github can help maintain guest extensions on host systems using VirtualBox.

docs/contributor-manual/development-workflows.md

@@ -0,0 +1,77 @@
+---
+title: Development workflows
+---
+
+## Git workflow
+
+LibreTime uses [Github pull requests to manage changes](https://docs.github.com/en/get-started/quickstart/contributing-to-projects). The workflow looks like this:
+
+- [Create a fork of the project](https://docs.github.com/en/get-started/quickstart/fork-a-repo).
+- Check out the `main` branch. If you're making a minor or small documentation change you can check out the `stable` branch.
+- Create a new branch based on the checked out branch.
+- Work on your changes locally. Try to keep each commit small to make reviews easier.
+- Lint and test the codebase, for example using the `make lint` or `make test` commands inside the app folder you want to check.
+- Push your branch.
+- Create a pull request in Github.
+- We'll review your request and provide feed back.
+
+## Project layout
+
+The LibreTime repository is split into multiple tools/services/apps at the root of the project. You will find `Makefile` in each of the component of the project. Those `Makefile` describe the different commands available to develop the project.
+
+Here is a small description of the different components in the repository:
+
+```bash
+.
+├── analyzer      # The LibreTime Analyzer service
+├── api           # The LibreTime API service
+├── api-client    # The API clients used internally by other services
+├── docker        # The docker related files
+├── docs          # The documentation
+├── install       # The install script
+├── installer     # The install script extra files
+├── legacy        # The LibreTime Legacy service
+├── playout       # The LibreTime Playout service
+├── shared        # A shared library using by our python based services
+├── tools         # Set of tools used to maintain the project
+├── website       # Website repository that is cloned when developing the documentation
+└── worker        # The LibreTime Worker service
+```
+
+For example, to lint and test the `analyzer` service, you can run the commands:
+
+```bash
+make -C analyzer lint test
+
+# Or by changing into the analyzer directory
+cd analyzer
+make lint test
+```
+
+## Pre-commit
+
+LibreTime uses [pre-commit](https://pre-commit.com/) to ensure that the files you commit are properly formatted, follow best practice, and don’t contain syntax or spelling errors.
+
+You can install and setup pre-commit using the [quick-start guide on the pre-commit documentation](https://pre-commit.com/#quick-start). Make sure to install pre-commit and setup the git pre-commit hook so pre-commit runs before you commit any changes to the repository.
+
+The workflow looks like this:
+
+- Install pre-commit.
+- After cloning the repository, setup the pre-commit git hooks:
+
+  ```bash
+  pre-commit install
+  ```
+
+- Make your changes and commit them.
+- If pre-commit fails to validate your changes, the commit process stops. Fix any reported errors and try again.
+
+:::info
+
+You can also run pre-commit anytime on all the files using:
+
+```bash
+pre-commit run --all-files
+```
+
+:::