... | ... | @@ -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 |