|
|
# How we do project management at the Tor Project - WIP (editing it)
|
|
|
|
|
|
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 developers want to keep a handle on what their actual current tasks are, and what everybody else is working on.
|
|
|
* Volunteer developers 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 gitlab ticket updates or 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.
|
|
|
* 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? WIP
|
|
|
|
|
|
First, we realize there needs to be a project. ~~This could be as formal as a funder listing a deliverable on a contract, or as informal as a developer thinking, "You know, some day BridgeDB should be able to give out bridges over SMS." At this point, you add an entry to the appropriate product's list of projects on [org/roadmaps](org/roadmaps) or one of its subpages. (If it's a tiny enhancement that can get done in a single task, you could also instead add a trac ticket to the appropriate component.)~~
|
|
|
|
|
|
~~At some time before the project becomes active, it should get a new trac ticket for it. The trac ticket should be named something like "Add Haskell support to Tor." Set the ticket type to "project," and it will be linked from the projects overview section on [org](org). This is the master ticket for the project. If it has a due date, assign it to the appropriate milestone. In its description, add the following code: "[[TicketQuery(parent=#**NUM**)]]", where **NUM** is the number of the ticket. This will insert a list of all the child tickets. If you know the steps needed to finish the project, add them as new tickets, and set their parent id to the master ticket for the project.~~
|
|
|
|
|
|
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.
|
|
|
* Start and ending date.
|
|
|
|
|
|
Next, we create tickets, adding them to the milestone, tagging them with the sponsor label.
|
|
|
|
|
|
An [initial roadmap](process/HowToBuildRoadmap) for the project will be discussed and agreed in the [kickoff meeting](process/KickoffMeetingTemplate). |