Skip to content
Snippets Groups Projects

WIP: project management

Open ck85nori requested to merge wip/project-management into main
2 unresolved threads
1 file
+ 129
0
Compare changes
  • Side-by-side
  • Inline
+ 129
0
## GitLab Building Blocks
- **projects** in **namespaces** (aka groups)
- **issues**
- organized in **milestones**
- categorized by **labels**
(yes it's only 5! that simple!)
## 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!)
- **pro tip:** use **meta** project!
- (strategy) for entire namespace / group
- inter-project relations or whatnot
- overarching / overlapping / across all projects
- **pro tip:** everything can easily be moved
- projects between namespaces
- issues between projects
- GitLab automatically creates redirects!
## GitLab Issues
- aka task aka todo
- focus, i.e. ideally one issue per **actionable** task
- i.e. stay on topic, no drive-by comments
- use mention, assignee, due
- **description:** describe what the problem/feature is; no solutions
- **comments:** describe/discuss possible solutions; use meeting or votes
(thumbs up/down) to decide on solution
- cross-referencing via `#issue-id` and `!merge-request-id`
- notification levels: who has what on which project / group;
- in general: start with **watch**, reduce if you realize it doesn't fit what
you're working on **at the moment**
- stakeholder: **watch**
- interest: **participate**
- boss: **on mention**
- **avoid disabling** notifications or you won't be kept in the loop
- **pro tip:** want opinion / discuss in meeting? use **discuss** label!
- **pro tip:** don't bother with issue boards in the beginning, especially with
few issues investing time in issue boards is wasted effort
## 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
- **pro tip:** use **strategy** label, have **strategy** meetings, i.e.
separate from **discuss** meetings, to discuss mid-term and long-term goals
## Group/Project Access
- visibility: **public**, **internal**, **private**, (invite)
- decide about general openness, models include
- everything **public**
- everything **private**
- mostly **private**, with some **internal** (like **meta** project) /
**public** parts to talk to company / world
- roles: guest, reporter, developer, maintainer, owner; check GitLab Help for
details
## (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**
- you 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 **blah** if there is
**blah** group or project
- label **if** you need a filter that can't otherwise be expressed
## 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`
- no need for separate meeting protocols!
- 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 most meetings**
- if so, use **discuss** and `@group` to drive consensus/quorum and use voting
emotes (thumbs up/down)
## Decide in your Group
- want to use **discuss** label for meeting agenda?
- better preparation by looking through **discuss** issues
- no meeting if no **discuss** issues
- better focus in meeting; less off-topic
- sharing responsibility, models include
- shared everything, esp. for **private** and small teams
- small team of *invested* **maintainers** / stakeholders
- quorum has to sign off on **all** changes
- **maintainers** coach **developers** / **contributors**
- (everyone else with access is **guest** or **reporter**)
- merge/resolve strategies; decide on **each** project
- consensus/quorum (should be default)
- benevolent dictator (especially if single maintainer)
## Summary
- better than email
- no information lost
- cross-referencing!
- it's waaay better than the most misused software ever (which is Excel BTW)
## Follow-up Meeting TOPs
- we only discuss advanced stuff **when** you need it
- schedule when:
- you lose overview: labels, issue boards, milestones
- you want to automate things: CI/CD, publish to Nextcloud, issue templates
Loading