Move Roster and Launcher to different repositories

[enrico-ghidoni]

As we discussed in private @milivojm, I think it would be best for each project to have its own repository.

This is for multiple reasons:

• issues don't need to be labelled according to what project they are linked to
• guidelines on how to run a project are too specific, for example Launcher has a different deployment than Roster and yet they share the same docker-compose.yaml
• branch management becomes a thing again, whereas with both project in the LevelUp repo it's unclear what master and develop are for and what every feature branch is about

[milivojm]

Here is how we will proceed:

1. I will branch release/0.1.0 from feature/roster-application.
2. You (Henrik) continue on application forms in the feature/roster-application. Do the essential features for Application Form aggregate. Don't use issue trackers yet. You can branch out from "your" branch into smaller branches (because smaller pull focused pull requests are easier to test and review), just name them feature/roster-application-something and when you think it is ready, create a PR to release/0.1.0. I will review it.
3. I (Highway) will create a feature/roster-member branch. Same as you, I do essential features for Member aggregate.
4. On 30.09.2021. I will take the role of Release Owner and merge what is finished into release/0.1.0 and skip what is not. We will deploy it on Tools server for the 1st time.
5. On 01.10.2021. I will remove CNTO Launcher into different repository without porting any history and label it 1.0.0. Same day I will create Roster release/0.2.0 from 0.1.0.
6. Issues now can be used for 0.1.0. Bugs need to be fixed and 0.1.0 stabilized (0.1.1, 0.1.2 etc). Same bug fixes need to be merged into 0.2.0.
7. On 31.10.2021. we release 0.2.0 again with same mindset, good finished PRs go in, unfinished wait for next month. 0.1.0 is archived and we go again.

We cannot plan feature based releases (I can't stress that enough) because that requires being in a company and payed for it. Instead we will do time based releases.

Using issues works for reporting problems and ideas but planning releases does not.

[enrico-ghidoni]

Sounds jolly good to me