|
|
= Ticket Triage =
|
|
|
This page documents our ticket triaging process for a milestone.
|
|
|
|
|
|
We often end up with a lot of tickets in a milestone and unfortunately not enough capacity to address them all. Furthermore, we have a roadmap to respect so in order for a ticket **to get into a milestone**, it must match those criteria:
|
|
|
|
|
|
* Must-fix bugs, to include:
|
|
|
* Security issues (keyword: `security`)
|
|
|
* Regressions (keyword: `regression`)
|
|
|
* Crash bugs (keyword: `crash`)
|
|
|
* Issues which are very very fast to fix, usually under an hour (keyword: `fast-fix`)
|
|
|
* Roadmap item (see below for the process).
|
|
|
|
|
|
If you are unsure if a ticket should go in the `Unspecified` milestone, mark it **<VERSION>-proposed** so we can decide during the network team weekly meeting if it should.
|
|
|
|
|
|
== Triage Algorithm ==
|
|
|
For all tickets in a specific milestone (ex: 0.3.4.x), here are the 4 phases. The **<VERSION>** would be "034" for the context of the 0.3.4.x milestone.
|
|
|
|
|
|
=== PHASE ONE: Marking the root issues ===
|
|
|
1) Make sure that all must-fix issues are tagged (Keywords) with **<VERSION>-must** and one or more of the following:
|
|
|
|
|
|
* security
|
|
|
* crash
|
|
|
* regression
|
|
|
|
|
|
2) For every issue that is very very fast to fix, if you believe that you will fix it and need less than 1 hour to do so, mark it **fast-fix** and **assign it to yourself**. (If it is worth fixing, and it will take less than an hour, and you will _not_ do it yourself, convince somebody else to take it on.)
|
|
|
|
|
|
3) For every roadmapped master issue, tag the issue with **<VERSION>-roadmap-master**. Make sure that every subticket of that roadmapped master issue has that ticket as its parent, grand-parent, great-grandparent, etc.
|
|
|
|
|
|
4) If there are high-impact issues that are not yet marked, which you believe should be fixed in <VERSION>, you need to get them on the roadmap. Mark them as **<VERSION>-roadmap-proposed**. We should discuss this list regularly at the network team weekly meeting.
|
|
|
|
|
|
=== PHASE TWO: Transitive closure ===
|
|
|
|
|
|
1) Iteratively identify every issue whose parent has **<VERSION>-roadmap-master** and mark that issue with **<VERSION>-roadmap-subtask**.
|
|
|
|
|
|
=== PHASE THREE: Getting ready to sweep ===
|
|
|
|
|
|
1) Mark every issue in the 0.3.4 milestone with **<VERSION>-triage-<YYYYMMDD>**.
|
|
|
|
|
|
2) For every kind of ticket that was marked in phase one or phase two above, mark it with **<VERSION>-included-<YYYYMMDD>**.
|
|
|
|
|
|
3) Find those tickets in 0.3.4 that are **not marked** with **<VERSION>-included-<YYYYMMDD>**. Mark them with **<VERSION>-removed-<YYYYMMDD>**.
|
|
|
|
|
|
4) Solicit comment on the removed tickets. Should any of them go into the roadmap after all?
|
|
|
|
|
|
=== PHASE FOUR: Sweeping the tickets ===
|
|
|
1) Move every ticket in **<VERSION>-removed-*** into `Tor: unspecified`. |
|
|
\ No newline at end of file |