WIP: project management

see #4

pm.md

+## Urist McTaylor
+
+- match the needs of the group, with general part
+- ask about their structure
+- ask about their needs
+- ask about their projects
+- sketch this live, ask everyone to log in and join the project
+
+## Why git?
+
+- product (doc, software, blah)
+- progress on product
+  - be able to see (hi)story of changes
+  - be able to go back in history (emotet)
+- git is best tool for the job
+
+## Markdown Crash Course
+
+- highlighting
+- lists
+- pictures
+- help
+- only tell about advanced stuff like tables and flowcharts
+- **pro tip:** use preview
+
+## Communication
+
+(how *can* you benefit from GitLab workflows)
+
+- less meetings
+- better focus
+- no information lost
+- it's waaay better than the most misused software ever (which is Excel BTW)
+
+## Showcase
+
+- show some examples of how this could work
+  - https://git.ufz.de/it/eve
+  - https://git.idiv.de/sc
+- TODO others would be nice, but it's hard to get to esp. because non-software,
+  organizational groups are likely to be private
+- TODO collect success stories
+- TODO interview Stefan / PR
+- TODO rust nursery, RFC stuff, SIGs
+
+## Building Blocks aka Bob the Builder
+
+(dumb down conceptual elements)
+
+- **projects** in **namespaces**
+- **issues**
+  - organized in **milestones** (and **epics**)
+  - categorized by **labels**
+
+(yes it's only 5! that simple!)
+
+(TODO: can we mind map or graph this? maybe using the builder/lego
+visualization)
+
+Project Management
+==================
+
+## Group/Project Structure
+
+- base this on teams! (functional/organizational structure)
+  - (for non-software 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 or `/cc @bo/hr`
+- **pro tip:** use **meta** project!
+- **pro tip:** start with sub-group and a single project per team, split
+  further **only** if complexity increases, this enables `/cc @bo/hr`
+  - **TODO:** geht das? dann dürfte ja wirklich nur **hr** member der Gruppe
+    sein?
+- **pro tip:** everything can easily be moved
+
+(show tree graph to highlight)
+(show demo notification settings)
+
+## Group/Project Access
+
+- visibility: **public**, **internal**, **private**, (invite)
+- decide about general openness, models include
+  - everything **public**
+  - everything **private**
+  - mostly **private**, with some **internal** / **public** parts to talk to
+    company / world
+- roles: guest, reporter, developer, maintainer, owner
+  - **TODO:** relevant how to non-software projects?
+    - wiki edits?
+    - issue visibility, commenting, creation?
+- decide about sharing responsibility, models include
+  - shared everything, esp. for **private** and small teams
+  - small team of *invested* **maintainers** / shareholders / stakeholders
+    - quorum has to sign off on **all** changes
+    - **maintainers** coach **developers** / **contributors**
+  - (everyone else with access is **guest** or **reporter**)
+
+## Issue
+
+- aka task aka todo
+  - focus, i.e. ideally one issue per actionable task
+  - i.e. stay on topic, no drive-by comments
+- stand-alone comment vs thread
+  - follow discussion threads
+  - (demo this, prepare good example)
+- use mention, assignee, due
+- **pro tip:** want outside opinion? use **discuss** label!
+- **pro tip:** decide on language and stick to it!
+  - if project is relevant to outsiders, may wanna use English
+
+## Netiquette
+
+(copy from basics seminar)
+
+## Milestones/Roadmap(/Epics)
+
+- use to communicate **strategic** goals
+  - define your win conditions
+  - assign someone responsible
+    - responsible doesn't mean do all the work, but delegate and trigger others
+    - best case: someone who intrinsically cares about the goals
+- assign issues to milestones
+- decide on roadmap with team, assign start/end dates
+
+## Labels
+
+(efficient use of labels)
+
+- kinds of labels
+  - action: blocked, **discuss**, consulting, coop, strategy
+  - status: duplicate, in progress, triage, wontfix
+  - category: bug, consolidation, doc, `$your_domain_category`
+    - useful for overview and priority
+    - specialization within team vs spreading knowledge with **coop**
+- will recognize them naturally
+  - just start if you recognize something repeating
+  - ask to consult at 42 open issues (when you lose overview)
+- don't overuse and overindulge yourself
+- don't label if milestone, it's already categorized and filterable
+- don't label if subgroup or subproject, e.g. don't label **hr** if there is
+  **hr** group or project
+- label **if** you need a filter that can't otherwise be expressed
+
+## How to get rid of Meetings
+
+(the mother of all GitLab pro tips)
+
+- use **discuss** label for meetings
+- only talk about those issues
+- write decision in comment
+- go back to work when you're done
+- if there's nothing to **discuss**, cancel meeting
+- if you can get everyone to actively discuss in issue comments, you can get
+  rid of meetings all together
+- if so, use **discuss** to drive consensus/quorum and use voting emotes
+
+## Issue Boards
+
+- based on action and status label kinds
+
+## Documentation
+
+- write in markdown
+- depending on audience, decide on either
+  - wiki for fellow GitLab'ers
+  - plain markdown with products (PDF, Nextcloud, Web) 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