|
|
# Tor Browser Team Triaging Process
|
|
|
|
|
|
|
|
|
Here we document the processes we use for triaging problem reports and feature requests. This is a (roughly) daily process. Triaging currently covers three different channels. Tickets (new tickets and recently updated tickets), Blog comments, and IRC channels.
|
|
|
|
|
|
## Tickets
|
|
|
### Assigning Keywords and Priority
|
|
|
|
|
|
Review all tickets in the `Applications/Tor Browser` component that do not contain a `TorBrowserTeam` keyword (eventually, [[doc/TorBrowser#TorBrowserTicketsNeedingTriage:|this query]] will provide those tickets).
|
|
|
with
|
|
|
Tickets are triaged into three categories, as well as subcategories depending on priority.
|
|
|
1) If this an an issue or feature we should solve/implement within the next two months?
|
|
|
- If it should be solved within the next month, then add the `TorBrowserTeamYYYYMM` keyword, where `YYYYMM` are the current year and month.
|
|
|
- If this is a bug that violates either the privacy or security requirements in the [https://2019.www.torproject.org/projects/torbrowser/design/ Tor Browser Design], then set the ticket's priority as `High`.
|
|
|
- Otherwise set the priority as `Medium`.
|
|
|
- If it should be solved "soon", but not necessarily this month, then set the `TorBrowserTeamYYYYMM` keyword for next month's and set the priority as `Medium`.
|
|
|
- If it should be solved at some time in the future, but not "soon", then set the `TorBrowserTeamTriaged` keyword. This includes tickets we should work on within the next 6-8 months as well as "wishful-thinking/pony" tickets, which we likely won't consider anytime soon unless we receive funding for it.
|
|
|
|
|
|
These are general guidelines. Two exceptions for this process are:
|
|
|
1. If we are near the end of the month, then we should be smart about whether we actually use the current month or simply put the ticket in next month's queue.
|
|
|
- This is a little tricky because at the beginning of each month, we move tickets with last month's keyword into the new month. We should be careful that tickets are not accidentally de-prioritized as a result of this process.
|
|
|
1. If we know a ticket won't be worked on within the next two months, but we know it will like be worked on during a specific month in the future (for example, we know it should be on the roadmap in four months), then we should assign the correct `TorBrowserTeamYYYYMM` keyword now, and not using `TorBrowserTeamTriaged`.
|
|
|
|
|
|
If you do not know the severity/priority of a ticket, then simply add the `tbb-triage-level2-needed` keyword.
|
|
|
|
|
|
### Comment Followup
|
|
|
When a ticket is opened or updated , but more information is needed, then add a comment asking for more information and set the status as `needs_information`.
|
|
|
|
|
|
When a ticket is in `needs_information` and more information is provided, then either reply and request even more information if it is needed or thank the user and set the status as `new`. Ask another member of the team if you don't know if a ticket contains enough information, or add the `tbb-triage-level2-needed` keyword.
|
|
|
|
|
|
## Blog Comments
|
|
|
Review all comments on Tor Browser-related blog posts. Approve non-spam comments, delete spam comments. See (policy) for more details.
|
|
|
|
|
|
We create tickets for any comments which report a new issues, and reply to the comment with a link to the ticket.
|
|
|
We reply to comments if there is a question to which we know the answer, otherwise we ask another team member to answer the question.
|
|
|
|
|
|
## IRC
|
|
|
We should monitor `#tor` and `#tor-project` for people reporting problems/bugs, as well as feature requests. |