development-workflow.md

@@ -2,13 +2,13 @@
 
 ### Ticket lifecycle
 
-* Every ticket starts off in the backlog
-* Some tickets get added to the roadmap, a subset of the backlog that's organised into milestones
+* Any ticket that doesn't have a milestone belongs to the backlog
+* Some tickets get assigned to milestones
 * 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`
 * When you create a merge request, label the ticket `In code review`
-* When your branch is merged, close the ticket if necessary and label it `Fixed`
+* When your branch is merged, close the ticket if necessary, and label it `Fixed`
 
 ### Parent and child tickets
 
@@ -19,9 +19,9 @@
 ### Priorities
 
 * No priority label: we haven't decided whether to work on this ticket
-* `Low priority`: the ticket will be worked on eventually but isn't on the roadmap
-* `Medium priority`: the ticket is on the roadmap
-* `High priority`: the ticket is on the roadmap and should be worked on immediately
+* `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 should be worked on immediately
 
 ### Categories
 
@@ -30,9 +30,8 @@
   * `Feature`: a user-visible improvement
   * `Feature request`: a feature someone has asked for -- we might or might not implement it, but either way the request should be recorded
   * `Task`: work that isn't visible to the user, e.g. refactoring or research
-  * `Document`: work that produces a document rather than code
-  * `UX design`: work that produces a design rather than code
-* Every major feature involves UX design and coding -- create child tickets for the design and coding tasks, don't add the `UX design` label to every feature
+  * `Document`: work that produces a document
+  * `UX design`: work that produces a design mockup
 
 ### Resolutions
 
@@ -51,14 +50,14 @@
 
 * Make sure **all** tests are passing
 * Check the [pre-review checklist](pre-review-checklist)
-* Rebase your branch if necessary to fix any merge conflicts, e.g. `git rebase -i master`
+* Rebase your branch if necessary to fix any merge conflicts: `git rebase -i master`
 * After rebasing, use `git push -f` to overwrite the remote branch
 * [Open a merge request](https://code.briarproject.org/akwizgran/briar/merge_requests/new)
 
 ## Code review
 
 * At least one other person must review your code before it's merged to master
-* You should address all the reviewer's comments before merging
+* You should respond to all the reviewer's comments before merging
   * If an issue needs to be fixed before merging, push the fix to your branch and notify the reviewer
   * If an issue is better dealt with after merging, create a ticket and reply with the ticket number
 * Once your branch has been merged you can delete the remote branch
@@ -67,7 +66,7 @@
 
 * 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 not just to find bugs but 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
 
@@ -93,7 +92,7 @@
 
 ## Dependencies
 
-* If you're working on a ticket that depends on an earlier ticket that's awaiting code review, base your new branch on the branch that's awaiting review
+* 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
 * Mention the dependency in the second merge request