pm.md

+- immer tailored zu gruppe, eher nicht generell
+
+## why git?
+
+- product (doc, software, blah)
+- progress on product
+  - be able to see (hi)story of changes
+  - be able to go back
+- ?
+- git is best tool for the job
+
+## markdown crash course
+
+- highlighting
+- listen
+- bilder
+- hilfe
+
+
+Project Management
+==================
+
+## Group/Project Structure
+
+- base this on organizational structure / teams!
+- **because notifications** (emails)
+  - these are your triggers to consume/act/participate!
+- e.g. HR has **watch** (all) notifications for **bo/hr**, but others only
+  **participate**, i.e. when they are explicitly called upon
+- everyone in **bo** should have at least **mention** in **bo**
+- use `/cc @user` to include someone in discussion
+- **pro tip:** use **meta** project!
+- **pro tip:** start with single project, split into sub-group tree **only** if
+  complexity increases
+
+(show tree graph to highlight)
+
+## Issue
+
+- aka task aka todo
+- kommentare
+- notifications!
+- netiquette
+- mention, assignee
+- milestone, roadmap, (epics)
+
+## labels
+
+- efficient use of labels
+- kinds of labels
+  - blocked, **discuss**, consulting, coop, strategy
+  - duplicate, triage, wontfix
+  - bug, consolidation, doc
+- will recognize them naturally
+  - just start if you see some categories
+  - ask to consult at 42 open issues (when you lose overview)
+- don't overuse overindulge yourself
+- don't label if milestone
+- don't label if subgroup or subproject
+
+## documentation
+
+- write in markdown
+- decide on either
+  - wiki
+  - plain markdown with products published in runner
+
+## use case: meeting protocols
+
+- not needed if **discuss** issues are used
+- make everything **actionable**
+- don't create issues for meetings/protocols
+- if protocol is needed for externals, use wiki and/or protocol project with
+  runner, or etherpad