From aa1c3e9d7ef5ba056e1a1924ca7b6246fde812e4 Mon Sep 17 00:00:00 2001 From: akwizgran Date: Thu, 10 Dec 2015 15:34:28 +0000 Subject: [PATCH] akwizgran created page: RpcNotes --- development-workflow.md | 23 +++++++++++------------ 1 file changed, 11 insertions(+), 12 deletions(-) diff --git a/development-workflow.md b/development-workflow.md index e502c33..83150b4 100644 --- a/development-workflow.md +++ b/development-workflow.md @@ -2,13 +2,12 @@ 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 - * You can skip rebasing if there are no merge conflicts -* When your branch is ready to merge, open a merge request +* 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 + * Use `git push -f` to overwrite the remote branch after rebasing + * 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 * Once your branch has been merged you can delete the remote branch @@ -19,18 +18,18 @@ Issues * 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 * 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', 'task', 'feature', 'feature request' or 'document' +* Every ticket should be labelled 'bug', 'feature', 'feature request', 'task' 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 +* 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 roughly what hours you'll be working via the standup channel -* At the start or end of each day (whichever's closer to 10am UTC), post an update to the standup channel saying: +* 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 -* If you're online at 10am UTC, please post your update at that time so we can have an interactive meeting +* If you're online at 10am UTC, please post your update at that time so we can have a standup meeting