Commit 8ea18f39 authored by French, Robert's avatar French, Robert
Browse files

Add Project Management content

parent bac1e2ad
<!-- $theme: gaia -->
<!-- *template: gaia -->
<!-- $size: 16:9 -->
# Gitlab Project Management
### Git It Together
##### Oak Ridge National Laboratory
<!-- page_number: true -->
## Why Project management?
* Help keep a large group on task
* Organize complaints, feedback, bugs from users
* Organize suggestions, desires, (and complaints!) from developers
### Solo Project Management
* Keep track of what is in your head
* Prioritize what to do next
* Keep yourself from getting lost in rabbit holes!
### What's involved?
* Open an Issue
* Submit a Merge Request to fix that issue
* Merge
* *Hey Presto* your bug is fixed!
### Some Caveats
* Some of these recommendations are biased towards operational projects, and may not make as much sense for research work
* I would love for someone to present on how they do (or don't!) use similar methods when the milestones are papers and talks instead of releases
<!-- *template: invert -->
## All About Issues
### Issues should be as precise as possible
* Bad collaborators will say "Newest commit doesn't build"
* Good collaborators will say
*"Could not compile commit `1234abc` under GCC 7.1.0 using HDF5 1.10.0 with parallel-netcdf FORTRAN extensions enabled. This last worked in commit `47ab45f`. Attached is a reproducer."*
* Make it a point to be a good collaborator
* Even if it is only you on the project!
### Labelling an Issue
* Over time, successful projects will accrue **tons** of issues
* Tons of systems for managing labels:
* Mostly, just pick something and **document it!**
### Using Issue Boards
* Gitlab has a very lightweight [KanBan]( issue board
* Columns are tied to labels
* Moving items between columns changes labels
* Good for seeing everything in one place
* Can be very noisy
### Using Milestones
* Much less flexibile that Issue Boards
* Three columns: ToDo, Active, Done
* Automatic burndown charts (Gitlab 9.1+)
* Great for showing management that yes, you are actually getting work done
* Can be too coarse-grained at times
### Tracking Dependencies
* Issues can (informally) depend on other issues
* Gitlab provides a **Checklist** feature that can be composed of other issues
* Allows anyone to come back and check off an item
* Easy to see dependencies, can be tricky to see dependents.
<!-- *template: invert -->
## Assignment and Approval
### Assigning Issues
* Assigning an Issue makes it "Active" within any applicable milestones
* Be biased towards Assignment == Actively Being Worked
* Eagerly assigning (or signing up for) work can be overwhelming
* Unassigned tasks should be ready for anyone to take
* Helps keep folks from getting idle or off target
### Merge Request Approvals
* In addition to CI (you are doing CI, right?)
* Gitlab allows you to specify a pool of "Approvers" for each project
* Senior Developers
* Customers (technical ones, anyway)
* Managers (see above)
* Fellow Developers
* Can also set threshhold for number of required approvals
<!-- *template: invert -->
## Getting work Done
### The Easy part
* All the organization pays off when it comes time to commit
* `git commit -m "Fixes #63"` will (once merged into master):
* Close issue #63
* Mark it off any open checklists
* Remove it from any boards
* Move it to the "Done" column on any Milestones
### Summary
* Do the boring work of categorizing issues
* Do it regularly, and involve all of your teammates
* Take the time to give definitions for each label
<!-- *template: invert -->
# Questions?
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment