|
|
|
# Roadmaps at the Tor Project
|
|
|
|
|
|
|
|
Roadmaps should:
|
|
|
|
|
|
|
|
* reflect:
|
|
|
|
* sponsor deliverables.
|
|
|
|
* team's priorities.
|
|
|
|
* dependencies.
|
|
|
|
* things we want to do to make Tor better.
|
|
|
|
* objectives that the area lead had defined with the help of their team.
|
|
|
|
* be constantly updated with honest status and estimations
|
|
|
|
|
|
|
|
This is done in Gitlab, using milestones, labels and boards. Projects documentations and other more in depth stuff will be done via wiki. By organizing this with Gitlab issues we will be able to create specific queries to answer specific questions. Example of use case questions:
|
|
|
|
|
|
|
|
* What was done on March for a specific sponsor ?
|
|
|
|
* What work on release x.x.x is related to a sponsor, and who are these sponsor?
|
|
|
|
* How much work is on person X plate?
|
|
|
|
|
|
|
|
## Roadmap Exercise
|
|
|
|
|
|
|
|
We used to use a [template for the pad](./Process/RoadmapNotesTemplate) to guide us on what needs to be considered and what to take notes of. Now we review the same questions in a spreadsheet that has information for all sponsored projects and for each team. At the beginning of each quarter each team lead meets with the project manager and engineering director. They go over everything that needs to be accomplished in the following 3 months.
|
|
|
|
|
|
|
|
### Steps during the meeting with the project manager
|
|
|
|
|
|
|
|
0. Review what was done last quarter. What worked? What needs to be improved?
|
|
|
|
1. Go over the priorities for the team. Do people need to add or change any of those priorities?
|
|
|
|
2. Go over the projects that the team is working on and discuss priorities.
|
|
|
|
3. Sort by priority items in must-have and nice-to-have sections.
|
|
|
|
4. Look at allocations for each of the tasks that the team needs to work on.
|
|
|
|
|
|
|
|
### After the meeting
|
|
|
|
|
|
|
|
The team lead discuss the roadmap with their team.
|
|
|
|
|
|
|
|
1. Use previous knowledge to move tickets around in the working board and create new tickets when needed.
|
|
|
|
2. Save notes from the meeting into the team's wiki in Gitlab.
|
|
|
|
|
|
|
|
## Working with Kanban Boards
|
|
|
|
|
|
|
|
[Kanban board](https://en.wikipedia.org/wiki/Kanban_board) is a project management tool to visually different stages of the work that needs to be done. At Tor we use it as boards in Gitlab projects and groups. It is organized in columns and cards, where each column has its cards sort out by priority.
|
|
|
|
|
|
|
|
For the organization we use the board: https://gitlab.torproject.org/groups/tpo/-/boards
|
|
|
|
|
|
|
|
Your board:
|
|
|
|
https://gitlab.torproject.org/groups/tpo/-/boards?scope=all&assignee_username=USERNAME where *USERNAME* is the user you have in Gitlab.
|
|
|
|
|
|
|
|
### Columns
|
|
|
|
|
|
|
|
* DOING: what we are working on right now.
|
|
|
|
* NEXT: what we will work in the next two weeks.
|
|
|
|
* BACKLOG: the roadmap for this quarter
|
|
|
|
* ROADMAP::FUTURE: issues that we plan to work on this year
|
|
|
|
* ICEBOX: we will do it at some point (can not be closed) but not any time soon. A parking space.
|
|
|
|
|
|
|
|
###### Other columns some teams are using
|
|
|
|
|
|
|
|
* Ongoing (we want to limit the use of this label or not have it as it is important to have tickets that we can finish and close).
|
|
|
|
* Needs review: It needs a review. It may have a MR associated or not.
|
|
|
|
* Needs information: It needs information to be worked on. We wait 1 year for an answer before closing it.
|
|
|
|
|
|
|
|
###### Labels to help sort out the roadmap
|
|
|
|
|
|
|
|
Q1, Q2, Q3, Q4: this labels will be assigned at the issues that we are planning to work on a specific quarter. It help us organize the year a little better. Not all teams are using this labels.
|
|
|
|
|
