Improved markup and added section on testing

development-workflow.md

@@ -1,35 +1,45 @@
-Branches
+# 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 avoid conflicts
 * When your branch is ready to merge:
-  * Make sure all tests are passing
-  * Rebase your branch if necessary to fix any merge conflicts
+  * Make sure **all** tests are passing
+  * Rebase your branch if necessary to fix any merge conflicts, e.g. `git pull origin master --rebase`
   * Use `git push -f` to overwrite the remote branch after rebasing
-  * Open a merge request
+  * [Open a merge request](https://code.briarproject.org/akwizgran/briar/merge_requests/new)
 * 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
 * Once your branch has been merged you can delete the remote branch
 
-Issues
+# Tests
+
+* before pushing any code, make sure the tests still complete sucessfully
+* to run them in Android Studio
+  * right-click on the briar-tests folder and select 'run all tests' to create a run configuration
+  * go to run > edit configurations to change the vm options for the 'all in briar-tests' configuration
+  * add `-Djava.library.path=../briar-desktop/libs` to the run configuration's vm options
+* to run tests on the command line, do `gradle test`
+
+# Issues
 
 * 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
+* Label your ticket '[in progress](https://code.briarproject.org/akwizgran/briar/issues?state=opened&label_name=In+progress)' while you're working on it, then '[in code review](https://code.briarproject.org/akwizgran/briar/issues?state=opened&label_name=In+code+review)' while it's being reviewed
+* When your branch is merged, label the ticket 'fixed' and close it or alternatively include 'Closes #55' in your commit message to close the ticket automatically.
 * As a rule of thumb, if a ticket takes longer than a day, break it into smaller tickets (mention the parent in the description)
-* Every ticket should be labelled 'bug', 'feature', 'feature request', 'task' or 'document'
-* Bugs are mistakes that affect the user, e.g. potential crashes
-* 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
-* Tasks are work items that don't directly affect the user, e.g. refactoring or research
-* Documents are work items that produce text rather than software
 
-Meetings
+* Every ticket should be labelled 'bug', 'feature', 'feature request', 'task' or 'document'
+  * Bugs are mistakes that affect the user, e.g. potential crashes
+  * 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
+  * Tasks are work items that don't directly affect the user, e.g. refactoring or research
+  * Documents are work items that produce text rather than software
+
+# Meetings
 
 * At the start of each week, let the team know what days you'll be working via the standup channel
 * Post a daily update to the standup channel saying:
-  * What you worked on yesterday/today
-  * What you'll be working on today/tomorrow
-  * Any blockers
+  * What you worked on yesterday/today?
+  * What you'll be working on today/tomorrow?
+  * Any blockers?
 * If you're online at 10am UTC, please post your update at that time so we can have a standup meeting