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.
