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
+- maybe sketch this live, ask everyone to log in and join the project
+
+## Why git?
+
+(only explain this if there is actual git usage)
+
+- 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
+
+(cheat sheet)
+(put this at the place where we do the issue comment interactive thingy)
+
+- highlighting
+- lists
+- pictures (depp n drop)
+- **help** button
+- 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 in meeting (because agenda is known before and everyone can
+  prepare)
+- structured communication
+  - (cross)referencing
+  - threading
+  - (re)searchable
+  - dedup
+  - team addressing (like mailing list)
+
+## Showcase
+
+- show some examples of how this could work
+  - https://git.ufz.de/it/eve
+  - https://git.idiv.de/sc
+  - anything public from gitlab.com team internal shit
+- 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**
+  - 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!
+  - (strategy) for entire namespace / group
+  - inter-project relations or whatnot
+  - overarching / overlapping / across all projects
+- **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?
+  - permissions can be upgraded but not downgraded
+- **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?
+    - guest darf issues sehen außer bei priv.
+    - ansonsten reporter, steckt ja schon im namen
+- 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**)
+
+(TODO: Beispielkonzepte durchdesignen)
+
+## 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
+  - (TODO: 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)
+
+- schreit euch nicht an
+- best practices zu
+  - vermeidung überflüssiger kommentare
+    - stay on topic
+    - thumbs up/down
+
+## Milestones / Roadmap
+
+- 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**
+- u will recognize them naturally
+  - just start if you recognize something repeating
+  - ask us to consult at 42 open issues (or 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
+
+(paar demo projekte zeigen)
+
+## use case: 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, `/unlabel ~discuss`
+- end meeting when no more discuss issues
+- 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
+- **learning:**
+  - start with normal protocol and add to issues later
+  - ideally done on the fly, but needs bit of practice
+
+## Issue Boards
+
+- based on action and status label kinds
+- strukturfindung, nur wenn nötig anwenden!
+
+(das ist eigentlich consulting, nur erwähnen, dass sie wissen das es gibt, aber
+definitiv noch nicht nutzen sollten, erst nach consulting bei $42 issues)
+
+## 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
+
+## best practices: what to put where
+
+- I have list of X, what do I do?
+  - group vs project
+  - issue vs project
+  - issue vs meilenstein
+  - meilenstein vs issue with task list
+
+## Summary / Conclusion / Fazit / Comparison to $world
+
+- better than email
+  - no information lost
+  - referencing!
+- it's waaay better than the most misused software ever (which is Excel BTW)
+
+Additional Slides
+=================
+
+## use case: meeting protocols in Wiki
+
+- 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