From e7d4bc27472d1a250ed749f842d527d57ff1ba80 Mon Sep 17 00:00:00 2001 From: akwizgran Date: Wed, 13 Apr 2016 10:39:27 +0000 Subject: [PATCH] --- development-workflow.md | 23 +++++++++++++++++------ 1 file changed, 17 insertions(+), 6 deletions(-) diff --git a/development-workflow.md b/development-workflow.md index 07bb060..e08c212 100644 --- a/development-workflow.md +++ b/development-workflow.md @@ -5,16 +5,25 @@ * 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, e.g. `git pull origin master --rebase` + * Rebase your branch if necessary to fix any merge conflicts, e.g. `git rebase -i master` * Use `git push -f` to overwrite the remote branch after rebasing * [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 -* Don't push directly to master unless it's an emergency and the change is very simple +* You should address all the reviewer's comments before merging + * If a comment is better dealt with as a separate ticket after merging, create a ticket and reply with the ticket number + * Let the reviewer know when all the comments have been addressed * Once your branch has been merged you can delete the remote branch +* When reviewing a branch: + * Check out and run the code as well as reading it + * Make sure you understand what the code is doing and why + * Don't be afraid to ask questions # Tests -* Before merging a branch, make sure the tests still pass +* Before opening a merge request, make sure the tests still pass * To run the tests in Android Studio: * Select 'Run > Edit Configurations' from the menu * Click '+' and select 'JUnit' @@ -33,12 +42,13 @@ * When your branch is merged, label the ticket 'fixed' and close it, or include 'Closes #55' in your commit message to close the ticket automatically (you still need to update the label) * 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' +* Every ticket should be labelled 'bug', 'feature', 'feature request', 'task', 'document' or 'ux design' * 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 either way 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 + * Document tasks produce text rather than code + * UX design tasks produce designs rather than code # Meetings @@ -54,4 +64,5 @@ * If you have a task that depends on an earlier task that's awaiting 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 -* Add a note about the dependency to the merge request and change the target branch when the first branch is merged +* Mention the dependency in the second merge request +* Remember to update the target branch when the first branch is merged