Kaladaran/briar
0
0
Fork 0
mirror of https://code.briarproject.org/briar/briar.git synced 2026-02-13 03:09:04 +01:00
Code Issues Projects Releases Wiki Activity

akwizgran created page: RpcNotes

akwizgran
2015-12-10 15:34:28 +00:00
parent 54877811a5
commit aa1c3e9d7e
1 changed files with 11 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

23
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