Stephan Lo
f797af114b
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).
1.8 KiB
Review
- 09h35 Marco business plan issue: value of software, depreciation FTE: around 100 overall, 3 full teams of developers tax discussion
10h04 Discussions
-
10h10 Julius
-
10h27 Sebastiano - DevDay bis 10h40
schriften bei votes größer - fragen sollten lesbar sein!
devops is dead .... claim
-
Stephan bis 10h55
-
christopher 10h58
-
robert 11:11
- app
- devops-pipelines
- edp in osc deployed
-
michal has nothing to show
-
evgenii wants to finish -- 11:30
-
patrick 11:32
====
projekt management meeting
workshops, externe teams
customer episodes
wem was wo prinzipien | Rollen, Personas
weiter die perspektive des nutzers bekommen, inneres verlangen eines developers, mein anspruch an das EDP (bekommen wir das hin, möchte ic damit arbeiten)
level 2 erklimmen
workshops halten
senioren bekommen
level1: source code structure, artefakte builden, revision control, branching model, e.g. pull requesting, tests der software, local debugging level2: automatisierung des artefakte-builds, versionsmgmt, milestones, tickets, issues, compliances an security level3: deployment auf stages, feedback pipeline verhalten level4: feedback app-verhalten (logs, metrics, alerts) + development loop level5: 3rd level support in production
level1: coding source code structure, artefakte builden, revision control, branching model, e.g. pull requesting, tests der software, local debugging
level2: reaching the outdside world with output automatisierung des artefakte-builds, versionsmgmt, milestones, tickets, issues, compliances an security
level3: run the app anywhere deployment auf stages, feedback pipeline verhalten
level4: monitoring the app feedback app-verhalten (logs, metrics, alerts) + development loop
level5: support 3rd level support in production (or any outer stage)
sprint 4 leveraging säule eigene app säule chore säule