How we do project management

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 trac ticket updates or git commits.

Notes: Some of this is document is aspirational as of July 2010: we aren't yet following this process throughout our whole organization. Also, this document is a draft: it represents our current best ideas on how to do this, but we are still refining those ideas. See the page for the project to set up this system for open questions, status on converting things to use this system, and so on.

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. Some projects are need a term: things we're doing, time permitting, but which we could let slide if they turn out not to be so great as we thought.. And some projects are need a term here: blue-sky: things that we're considering doing someday, without a firm decision on whether or how much we're doing them.

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 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 a trac ticket linked from 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 child tickets of the main project ticket.
• Really complex projects can also get a wiki page with a name like org/projects/ShortProductName/DescriptionOfTheProject for figuring out the work plan. Serious design should still get discussed on or-dev, though, or via the proposal system.
• Blue-sky projects and projects that aren't ready for action can be represented by a single line on the list of projects.

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?

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 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. 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 ticket 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.
• The project's status. Is it an external commitment? An internal commitment? A blue-sky project? A catch-all milestone?
• As much detail as we have about what it would mean for the project to be "finished."

Next, we create tasks and milestones, linking them from the project page. XX say more XX

(Note: There is no mention of milestones above.)

Then, we start working on the thing, checking off tasks as we go. XX say more. XX