|
|
This page explains how we keep track of our ongoing tasks in the Tor Project.
|
|
|
|
|
|
Project management as described here serves a few different purposes:
|
|
|
|
|
|
* Paid contributors want to keep a handle on what their actual current tasks are, and what everybody else is working on.
|
|
|
* Volunteer contributors and researchers want to know about interesting tasks that we want to get done, but which we _aren't_ actually working on.
|
|
|
* Users want to know what we're working on, and what they can do to help us.
|
|
|
* Funders want to stay apprised of how well we're doing at meeting our promises to them, without having to read git commits.
|
|
|
|
|
|
## What do we track exactly?
|
|
|
|
|
|
Let's start in the middle, with a **project**. In our parlance, a project is a medium- to long-duration task that one or more people could work on. Example projects might include "Make Tor support RFC1149 transports," "Translate the website into isiXhosa," "Hire a virtual office manager for our virtual office," "Write a how-to guide for using Tor on the Banana 6000," "Release Tor 0.6.7.x-rc", or "Design and deploy a new project management system."
|
|
|
|
|
|
There are different kinds of projects. Some projects represent _external commitments_: things that we've promised to funders or partners. Some projects are _internal commitments_: things that we've decided we're definitely doing, even if we didn't promise them to anybody.
|
|
|
|
|
|
Projects involve creating or enhancing some **products**. Most of our **products** are programs, but some (like the website, or the company itself) aren't.
|
|
|
|
|
|
Projects are divided into **objectives** with **tasks.** Each **task** should represent a comprehensible unit of work that can get done in a matter of hours or days. Example tasks for "Make Tor support UDP" might be "write a specification for ".
|
|
|
|
|
|
There are a few ways we represent projects, depending on their status:
|
|
|
* Every **active** project should get represented by milestone linked from the appropiate page in [org/projects](org/projects) or one of its sub-pages listing the projects for a particular product. All significant to-do items for a project should be tickets in the project's milestone.
|
|
|
|
|
|
|
|
|
### How to tell projects from other things
|
|
|
|
|
|
* If it was promised to a funder as an external commitment, it is a project no matter what. In that case we called it 'sponsored project'.
|
|
|
* If we have contracted to somebody to do it as a deliverable, it is almost certainly a project.
|
|
|
* If it is due on a particular date, it is probably a project.
|
|
|
* If it has requirements, it's probably a project.
|
|
|
* If it is a big piece of effort that breaks down well into lots of sub-tasks, it is probably a project.
|
|
|
* If it will take a week or longer, it is almost certainly a project.
|
|
|
* If it is the name of a program, website, or other artifact, it is a product and _not_ a project---though there might be a project to create or enhance said program, website, or artifact.
|
|
|
* If it will take less than one person-day, it's probably a task.
|
|
|
* (If it will take less time to do it than enter it as a task, just do it!)
|
|
|
* If it's a piece of work with no real utility except as part of a larger whole, it's probably a task.
|
|
|
|
|
|
## What's the workflow here?
|
|
|
|
|
|
### Initiating
|
|
|
|
|
|
1. We maintain a [list of ideas](https://gitlab.torproject.org/tpo/operations/proposals/-/boards/857) for possible projects to fund. First, we add that idea to the list for when a grant is available with a call for proposals (CFP).
|
|
|
|
|
|
2. When a CFP is available we write the proposal and send it. If it gets funded then we move forward with it (unless it is a project that needs to happen regardless of funding). This may take from 6 months to a year. We consider the following items
|
|
|
* Goal: the goals of the project, why they make sense, and what the high-level features, requirements will be.
|
|
|
* Timeframe
|
|
|
* Estimation / Budget
|
|
|
* Risks and mitigations
|
|
|
* Who should be involved
|
|
|
* Who has requirements authority?
|
|
|
* Who has design authority?
|
|
|
* Who has technical authority?
|
|
|
* Who has budget authority?
|
|
|
* How often will requirements and designs be reviewed, and how will adjustments be decided?
|
|
|
|
|
|
### Planning
|
|
|
|
|
|
3. Get [project](project/ProjectLife) into Gitlab as a milestone. A project milestone should contain, at minimum:
|
|
|
* The name of the project.
|
|
|
* A description of what the project entails and why we're doing it or not doing it.
|
|
|
* Objectives and tasks involved.
|
|
|
* Start and ending date.
|
|
|
|
|
|
4. Hold a [kickoff meeting](process/KickoffMeetingTemplate) with all stakeholders from the project.
|
|
|
* define scope - have presentation from the "objective owners" about what they were thinking about when they wrote that specific objective and activity
|
|
|
* show timeline of the project and who is going to work on it
|
|
|
* agree on how coordination and communication will happen.
|
|
|
|
|
|
5. Next, we create tickets, adding them to the milestone, tagging them with the sponsor label. Add the objectives, activities and indicators to the public milestone in gitlab.
|
|
|
|
|
|
6. The [roadmap](process/HowToBuildRoadmap) will be define by a [kanban board](https://gitlab.torproject.org/groups/tpo/-/boards) filtered by the sponsors's milestone.
|
|
|
|
|
|
### Communication
|
|
|
|
|
|
Through the life of a project we hold [bi-weekly meetings](process/project-meetings-template) to coordinate work between project's members and adjust the roadmap.
|
|
|
|
|
|
### Monitoring
|
|
|
|
|
|
* Key performance indicators
|
|
|
* time spent on tasks
|
|
|
* money spent on tasks
|
|
|
* % of project completed
|
|
|
* Analyze data from Gitlab using milestones and tickets closed.
|
|
|
* Keep track of timeline for the project and indicate % of project completed. The timeline changes through the project if there is any delay.
|
|
|
|
|
|
### Reporting
|
|
|
|
|
|
How frequently we report to the funders will depend on the requirements from the funder.
|
|
|
|
|
|
### Closing
|
|
|
|
|
|
* Review original documents and plans
|
|
|
* Retrospective |