Skip to content

GitLab

Last edited by Gaba
Page history

How we do project management at The Tor Project

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 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 (in our private nextcloud instance) 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
  • Timeframe
  • Estimation / Budget
  • Risks and mitigations
  • Who should be involved

Planning

  1. Get project 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.
  1. Hold a kickoff meeting with all stakeholders from the project.
  • define scope
  • show timeline of the project and who is going to work on it
  • agree on how coordination and communication will happen.

  1. Next, we create tickets, adding them to the milestone, tagging them with the sponsor label.

  2. The roadmap will be define by a kanban board filtered by the sponsors's milestone.

Communication

Through the life of a project we hold bi-weekly meetings 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