diff --git a/development-workflow.md b/development-workflow.md
index 6fb5c78..829d41d 100644
--- a/development-workflow.md
+++ b/development-workflow.md
@@ -2,7 +2,7 @@
 
 ### Ticket lifecycle
 
-* Some tickets get assigned to milestones
+* When we decide to work on a ticket, it should be assigned to a milestone
 * Some tickets in the current milestone are given high priority
 * High-priority tickets are eligible to be worked on
 * When you start working on a ticket, assign it to yourself and label it `In progress`
@@ -15,13 +15,6 @@
 * Mention the parent ticket in the child tickets
 * Close the parent ticket and label it `Fixed` when all the child tickets have been fixed
 
-### Priorities
-
-* No priority label: we haven't decided whether to work on this ticket
-* `Low priority`: the ticket will be worked on eventually but doesn't have a milestone
-* `Medium priority`: the ticket has a milestone
-* `High priority`: the ticket belongs to the current milestone and can be worked on immediately
-
 ### Categories
 
 * Every ticket should be labelled `Bug`, `Feature`, `Feature request`, `Task`, `Document` or `UX design`
@@ -32,13 +25,14 @@
   * `Document`: work that produces a document
   * `UX design`: work that produces a design mockup
 * Before assigning the `UX design` label, ask yourself whether the ticket can be closed when a mockup is produced. If the answer is yes, assign the label. If the answer is no, create a child ticket for the mockup and assign the label to the child.
+* Tickets like `Usability` and `Security` can be assigned to any ticket regardless of whether it's a bug, feature, etc.
 
 ### Resolutions
 
 * Every closed ticket should be labelled `Fixed`, `Duplicate` or `Rejected`
   * `Fixed`: the issue described by the ticket was addressed
   * `Duplicate`: another ticket describes the same issue -- add a comment mentioning which ticket
-  * `Rejected`: the issue described by the ticket will not be addressed -- add a comment explaining why not
+  * `Rejected`: the issue described by the ticket is obsolete, or we're not planning to address it -- add a comment explaining why not
 
 ## Branches
 
@@ -66,18 +60,13 @@
 
 * Check out and run the code as well as reading it
 * Make sure you understand what the code is doing and why
-* Ask plenty of questions -- the goal is to ensure that you and the developer have a shared understanding of the code
+* Ask plenty of questions
+* The goal is to ensure that you and the developer have a shared understanding of the code
 
 ## Tests
 
 * To run the tests in Android Studio:
-  * Select `Run > Edit Configurations` from the menu
-  * Click `+` and select `JUnit`
-  * Set `Test kind` to `All in package`
-  * Set `Search for tests` to `Across module dependencies`
-  * Set `VM options` to `-Djava.library.path=../briar-desktop/libs`
-  * Set `Use classpath of module` to `briar-android`
-  * Click `OK` to create the run configuration
+  * Select `All tests` from the run configuration dropdown
 * To run the tests from the command line:
   * `./gradlew test --continue`
 
@@ -89,11 +78,13 @@
   * What you'll be working on today/tomorrow
   * Any blockers
 * If you're awake and online at 10am UTC, please post your update at that time so we can have a standup meeting
+* We have a planning meeting in the town square channel each Monday at 2pm UTC
 
 ## Dependencies
 
 * If the ticket you're working on depends on an earlier ticket that's in code review, base your new branch on the branch that's awaiting review
 * When the first branch is merged, rebase the second branch onto master
 * You can put the second branch up for review by selecting the first branch as the target, instead of master
+* The second merge request should be marked WIP until the first one is merged
 * Mention the dependency in the second merge request
 * Remember to update the target branch of the second merge request when the first branch is merged