diff --git a/pm.md b/pm.md new file mode 100644 index 0000000000000000000000000000000000000000..035d1fa75a6698917d1855230ee01da3c5b59e81 --- /dev/null +++ b/pm.md @@ -0,0 +1,230 @@ +## 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