akwizgran created page: development workflow

development-workflow.md

@@ -0,0 +1,24 @@
+Branches
+
+* Always work on a branch
+* Name your branch after the ticket you're working on, e.g. `55-key-manager-refactoring`
+* Push your branch at least once a day so everyone knows what you're working on -- that will help us to spot conflicts early
+* When your branch is ready to merge, rebase it onto master
+  * Howls of outrage: you can't rebase a public branch!
+  * But nobody else is working on it, so it's actually fine
+  * You can use `git push -f` to overwrite the remote branch after rebasing
+* When your branch is rebased onto master, open a merge request
+* At least one other person must review your code before it's merged to master
+* Don't push directly to master unless it's an emergency and the change is very simple
+
+Issues
+
+* Every ticket should be labelled 'bug', 'task', 'feature', 'feature request' or 'document'
+* Bugs are mistakes that affect the user, e.g. potential crashes
+* Tasks are work items that don't directly affect the user, e.g. refactoring or research
+* Features are work items that directly affect the user
+* Feature requests are features that someone has asked for -- we might or might not implement them, but they're worth documenting
+* Documents are work items that produce writing rather than software
+* When you start working on a ticket, assign it to yourself
+* Label your ticket 'in progress' while you're working on it, then 'in code review' while it's being reviewed
+* When your branch is merged, label the ticket 'fixed' and close it