website-and-documentation/content/en/docs/v1/project/plan-in-2024/streams/_index.md

---
title: Workstreams
weight: 2
---

This page is WiP (23.8.2024).

> Continued discussion on 29th Aug 24
>
> * idea: Top down mit SAFe, Value Streams
> * paralell dazu bottom up (die zB aus den technisch/operativen Tätigkeietn entstehen)
> * Scrum Master?
> * Claim: Self Service im Onboarding (BTW, genau das Versprechen vom Developer Framework)
> * Org-Struktur: Scrum of Scrum (?), max. 8,9 Menschen

Stefan and Stephan try to solve the mission 'wir wollen losmachen'.

**Solution Idea**:

1. First we define a **rough overall structure (see 'streams')** and propose some initial **activities** (like user stories) within them.
1. Next we work in **iterative steps** and produce iteratively progress and knowledge and outcomes in these activities.
1. Next the **whole team** decides which are the next valuable steps

## Overall Structure: Streams

We discovered three **streams** in the first project steps (see also [blog](../../../blog/news/240823-archsession/_index.md)):

1. Research, Fundamentals, Architecture
1. POCs (Applications, Platform-variants, ...)
1. Deployment, production-lifecycle

```markmap
# 
## Stream 'Fundamentals'
### [Platform-Definition](./fundamentals/platform-definition/)
### [CI/CD Definition](./fundamentals/cicd-definition/)
## Stream 'POC'
### [CNOE](./pocs/cnoe/)
### [Kratix](./pocs/kratix/)
### [SIA Asset](./pocs/sia-asset/)
### Backstage
### Telemetry
## Stream 'Deployment'
### [Forgejo](./deployment/forgejo/)
```

## DoR - Definition of Ready

Bevor eine Aufgabe umgesetzt wird, muss ein Design vorhanden sein.

Bezüglich der 'Bebauung' von Plaztform-Komponenten gilt für das Design:

1) Die Zielstellung der Komponenet muss erfasst sein
doc(project): WiP - initially set up project activities 2024-08-23 14:29:09 +02:00			`---`
refactor(project): folders for streams and activities 2024-08-23 14:53:11 +00:00			`title: Workstreams`
doc(project): WiP added new section 'Onboarding' 2024-08-29 15:05:46 +00:00			`weight: 2`
doc(project): WiP - initially set up project activities 2024-08-23 14:29:09 +02:00			`---`

test: configure comprehensive markdown linting with Docsy best practices Configure markdownlint with rules aligned to technical documentation standards and Docsy theme conventions. Design Decisions: - Enable core quality rules (heading hierarchy, consistent list styles) - Allow inline HTML for Docsy shortcodes and components - Permit bare URLs (common in technical documentation) - Make code block language hints optional (pragmatic for existing content) - Set maximum 2 consecutive blank lines (balanced readability) - Enforce single trailing newline (POSIX standard) - Use asterisk for unordered lists (consistency) - Allow 2-space list indentation (Markdown standard) Auto-fixed Issues: - Converted dash lists to asterisk lists (568 fixes) - Removed trailing spaces (211 fixes) - Added missing trailing newlines (74 fixes) - Added blank lines around lists and headings (100+ fixes) Remaining Style Warnings (intentionally accepted): - MD029: List numbering variations in meeting notes (75 instances) - MD036: Bold text for section headers in ADRs (13 instances) - MD025: Multiple H1 in notes/brainstorming docs (10 instances) - MD032/MD022: Minor spacing variations (15 instances) Test Results: ✅ Hugo build: 227 pages generated successfully ✅ HTML validation: No errors ✅ Link checking: All links valid (except dev-only livereload) ✅ Markdown linting: Only non-critical style warnings remain The configuration balances strict quality checks with pragmatic flexibility for diverse content types (documentation, ADRs, meeting notes, tutorials). 2025-10-23 14:25:46 +02:00			`This page is WiP (23.8.2024).`
doc(project): WiP - initially set up project activities 2024-08-23 14:29:09 +02:00
doc(project): added memos of weekly meeting ... content which also resides in Teams OneNote 2024-08-29 13:42:11 +02:00			`> Continued discussion on 29th Aug 24`
test: configure comprehensive markdown linting with Docsy best practices Configure markdownlint with rules aligned to technical documentation standards and Docsy theme conventions. Design Decisions: - Enable core quality rules (heading hierarchy, consistent list styles) - Allow inline HTML for Docsy shortcodes and components - Permit bare URLs (common in technical documentation) - Make code block language hints optional (pragmatic for existing content) - Set maximum 2 consecutive blank lines (balanced readability) - Enforce single trailing newline (POSIX standard) - Use asterisk for unordered lists (consistency) - Allow 2-space list indentation (Markdown standard) Auto-fixed Issues: - Converted dash lists to asterisk lists (568 fixes) - Removed trailing spaces (211 fixes) - Added missing trailing newlines (74 fixes) - Added blank lines around lists and headings (100+ fixes) Remaining Style Warnings (intentionally accepted): - MD029: List numbering variations in meeting notes (75 instances) - MD036: Bold text for section headers in ADRs (13 instances) - MD025: Multiple H1 in notes/brainstorming docs (10 instances) - MD032/MD022: Minor spacing variations (15 instances) Test Results: ✅ Hugo build: 227 pages generated successfully ✅ HTML validation: No errors ✅ Link checking: All links valid (except dev-only livereload) ✅ Markdown linting: Only non-critical style warnings remain The configuration balances strict quality checks with pragmatic flexibility for diverse content types (documentation, ADRs, meeting notes, tutorials). 2025-10-23 14:25:46 +02:00			`>`
doc(project): added memos of weekly meeting ... content which also resides in Teams OneNote 2024-08-29 13:42:11 +02:00			`> * idea: Top down mit SAFe, Value Streams`
			`> * paralell dazu bottom up (die zB aus den technisch/operativen Tätigkeietn entstehen)`
			`> * Scrum Master?`
			`> * Claim: Self Service im Onboarding (BTW, genau das Versprechen vom Developer Framework)`
			`> * Org-Struktur: Scrum of Scrum (?), max. 8,9 Menschen`

refactor(project): folders for streams and activities 2024-08-23 14:53:11 +00:00			`Stefan and Stephan try to solve the mission 'wir wollen losmachen'.`
doc(project): WiP - initially set up project activities 2024-08-23 14:29:09 +02:00
test: configure comprehensive markdown linting with Docsy best practices Configure markdownlint with rules aligned to technical documentation standards and Docsy theme conventions. Design Decisions: - Enable core quality rules (heading hierarchy, consistent list styles) - Allow inline HTML for Docsy shortcodes and components - Permit bare URLs (common in technical documentation) - Make code block language hints optional (pragmatic for existing content) - Set maximum 2 consecutive blank lines (balanced readability) - Enforce single trailing newline (POSIX standard) - Use asterisk for unordered lists (consistency) - Allow 2-space list indentation (Markdown standard) Auto-fixed Issues: - Converted dash lists to asterisk lists (568 fixes) - Removed trailing spaces (211 fixes) - Added missing trailing newlines (74 fixes) - Added blank lines around lists and headings (100+ fixes) Remaining Style Warnings (intentionally accepted): - MD029: List numbering variations in meeting notes (75 instances) - MD036: Bold text for section headers in ADRs (13 instances) - MD025: Multiple H1 in notes/brainstorming docs (10 instances) - MD032/MD022: Minor spacing variations (15 instances) Test Results: ✅ Hugo build: 227 pages generated successfully ✅ HTML validation: No errors ✅ Link checking: All links valid (except dev-only livereload) ✅ Markdown linting: Only non-critical style warnings remain The configuration balances strict quality checks with pragmatic flexibility for diverse content types (documentation, ADRs, meeting notes, tutorials). 2025-10-23 14:25:46 +02:00			`Solution Idea:`
refactor(project): folders for streams and activities 2024-08-23 14:53:11 +00:00
			`1. First we define a rough overall structure (see 'streams') and propose some initial activities (like user stories) within them.`
			`1. Next we work in iterative steps and produce iteratively progress and knowledge and outcomes in these activities.`
			`1. Next the whole team decides which are the next valuable steps`
doc(project): WiP - initially set up project activities 2024-08-23 14:29:09 +02:00
			`## Overall Structure: Streams`

			`We discovered three streams in the first project steps (see also [blog](../../../blog/news/240823-archsession/_index.md)):`

			`1. Research, Fundamentals, Architecture`
			`1. POCs (Applications, Platform-variants, ...)`
			`1. Deployment, production-lifecycle`

refactor(project): folders for streams and activities 2024-08-23 14:53:11 +00:00			```markmap
			`#`
			`## Stream 'Fundamentals'`
doc(project): links in mindmap included 2024-08-23 15:11:18 +00:00			`### [Platform-Definition](./fundamentals/platform-definition/)`
			`### [CI/CD Definition](./fundamentals/cicd-definition/)`
refactor(project): folders for streams and activities 2024-08-23 14:53:11 +00:00			`## Stream 'POC'`
doc(project): links in mindmap included 2024-08-23 15:11:18 +00:00			`### [CNOE](./pocs/cnoe/)`
doc(project): addedkratix as activity 2024-08-28 17:03:02 +02:00			`### [Kratix](./pocs/kratix/)`
			`### [SIA Asset](./pocs/sia-asset/)`
doc(project): added more activities 2024-09-04 11:47:08 +00:00			`### Backstage`
			`### Telemetry`
refactor(project): folders for streams and activities 2024-08-23 14:53:11 +00:00			`## Stream 'Deployment'`
doc(project): links in mindmap included 2024-08-23 15:11:18 +00:00			`### [Forgejo](./deployment/forgejo/)`
doc(project): added more activities 2024-09-04 11:47:08 +00:00			```

			`## DoR - Definition of Ready`

			`Bevor eine Aufgabe umgesetzt wird, muss ein Design vorhanden sein.`

			`Bezüglich der 'Bebauung' von Plaztform-Komponenten gilt für das Design:`

			`1) Die Zielstellung der Komponenet muss erfasst sein`