Process/HowProjectManagementAtTheTorProject.md

+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