|
|
|
**Purpose of this document:** This is a _living_ document mean to be a clear, easy-to-use guide for TPI contributors who work together in projects. This page explains how we keep track of our ongoing tasks in the Tor Project.
|
|
|
|
|
|
|
|
**Questions or feedback?** Contact Project Manager (@gaba)
|
|
|
|
|
|
|
|
Project management as described here serves a few different purposes:
|
|
|
|
|
|
|
|
* Tor Project's staff want to keep a handle on what their actual current tasks are, and what everybody else is working on.
|
|
|
|
* Project managers want to understand the status of each project and if there are any blockers.
|
|
|
|
* 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 a kanban board linked from the appropriate page in [our sponsored projects](home#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 milestones. Projects may have more than one milestone to help complete its deliverables but will have only ONE label with the sponsor number to mark all the tickets for the project.
|
|
|
|
|
|
|
|
|
|
|
|
### 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 lifetime of a project?
|
|
|
|
|
|
|
|
### Initiating
|
|
|
|
|
|
|
|
“Ideas” on what we are looking funding for comes from different sources from Tor’s staff and community.
|
|
|
|
|
|
|
|
1. The organization’s goals for the year we are in. For example, for 2023 they are:
|
|
|
|
* A Mature Tor Project (organization)
|
|
|
|
* Stable income flows from a diverse funding base
|
|
|
|
* Diverse and robust organization that meets our needs
|
|
|
|
* Strong organizational culture focuses on employees and volunteers happiness
|
|
|
|
* Global brand recognition - Tor means strong privacy
|
|
|
|
* Full Access (product/projects)
|
|
|
|
* Any person on the planet can access the Tor network
|
|
|
|
* Any person on the planet can use the Tor network to access any websites or services online
|
|
|
|
* Ensure the Tor network is diverse, healthy, stable, and scalable
|
|
|
|
2. Ideas submitted to the [proposals tracker](https://gitlab.torproject.org/tpo/operations/proposals/-/issues) we maintain.
|
|
|
|
3. Mails sent to the grants@torproject.org about possible projects to fund.
|
|
|
|
|
|
|
|
Determining what project to apply for depends on capacity, funding opportunities and organizational priorities.
|
|
|
|
|
|
|
|
When a call for proposals (CFP) for a grant is available we [write the proposal](/Process/Project-Design-and-Grant-Writing) 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
|
|
|
|
* Including admin overhead (PM, leads, accounting,etc)
|
|
|
|
* 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?
|
|
|
|
|
|
|
|
At this stage, the project is put into the [GrantHub platform](https://www.granthubonline.com), and assigned a number. The GrantHub platform is managed by the Grants team, and is used to track funding opportunities over the entire lifecycle.
|
|
|
|
|
|
|
|
Once the proposal is submitted to the potential funder, the process of getting it approved may take several iterations to adjust budgets, timelines, expectations, deliverables, etc. depending on the funders’ specific criteria, until the project is awarded or rejected.
|
|
|
|
|
|
|
|
All grant writing happens in ephemeral Google docs, or in the Fundraising Team/Grants folder in Nextcloud. The final version of the submitted documents are stored in the Nextcloud Fundraising Team/Grants folder.
|
|
|
|
|
|
|
|
### Planning
|
|
|
|
|
|
|
|
Once the project gets approved, the project manager gets the submitted documents that were approved and stores the approved, final version in Nextcloud in the folder Sponsors/Sponsor NN/Documents Submitted. They will also add the sponsor information to the [active Sponsors's page](home#projects).
|
|
|
|
|
|
|
|
Next the project manager will:
|
|
|
|
* Send a poll to all people involved in the project to find a day to do a kickoff meeting.
|
|
|
|
* Converts the approved time-line into a ‘status and timeline’ spreadsheet to track and change across the duration of the project.
|
|
|
|
* Creates a label ‘Sponsor NN’ in Gitlab
|
|
|
|
* Creates a [coordination meeting pad with information about the project](Process/Templates/KickoffProjectMeetingPadTemplate):
|
|
|
|
* Start and end dates
|
|
|
|
* Goals
|
|
|
|
* Who is involved in the project
|
|
|
|
* Frequency and where meetings will be held
|
|
|
|
* Links to timeline, Gitlab kanban board, sponsor folder in Nextcloud
|
|
|
|
* Deliverables that will be accomplished across the duration of the project
|
|
|
|
* Indicators used in the project, if any
|
|
|
|
|
|
|
|
The [kickoff meeting](Process/Templates/KickoffMeetingTemplate) agenda includes:
|
|
|
|
* Going over Deliverables and desired outcomes, clarifying anything that is not clear
|
|
|
|
* Reviewing what we are tracking during the project
|
|
|
|
* Define Scope (who is creating tickets for what) at this time. If possible have a presentation from "objective owners" about what they were thinking about when they wrote that specific objective and activity.
|
|
|
|
* Remind people that they need to [estimate](Process/HowToEstimate) all tickets included in this project.
|
|
|
|
* If one or more milestones will be created to track deliverables for the project then the milestone needs to 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.
|
|
|
|
* Tasks involved in the deliverable.
|
|
|
|
* Start and ending date.
|
|
|
|
* Review Timelines and Estimations as well as who is going to work on it.
|
|
|
|
* How we are going to work:
|
|
|
|
* when do we meet
|
|
|
|
* how frequently
|
|
|
|
* what to expect from these meetings (agenda, status)
|
|
|
|
* agree on how coordination and communication will happen..
|
|
|
|
|
|
|
|
Next, we create tickets, adding them to the appropiate milestone, tagging them with the sponsor label.
|
|
|
|
|
|
|
|
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 monthly or bi-weekly [meetings](Process/Templates/ProjectMeetingsTemplate) to coordinate work between project's members and adjust the timeline.
|
|
|
|
|
|
|
|
### Executing
|
|
|
|
|
|
|
|
* Tracking system
|
|
|
|
* project costs: done by CEO (Sue)
|
|
|
|
* costs: done by CEO (Sue)
|
|
|
|
* regular risks assessments (not done on a regular basis at the moment but it should be done by PM)
|
|
|
|
* how likely to miss deadline
|
|
|
|
* how much impact
|
|
|
|
* progress on activities in Gitlab as well as who is working on what.
|
|
|
|
|
|
|
|
At a pre-determined regular frequency there are voice meetings in BBB to coordinate work from the project. Each meeting will have:
|
|
|
|
* Agenda created by participants
|
|
|
|
* Status for each person in the project’s team with what they worked on in the last period, what they are planning to work next and if they need help.
|
|
|
|
* Check timeline/deliverables/outcomes if needed.
|
|
|
|
* Project-specific discussion topics
|
|
|
|
|
|
|
|
### Tracking and Monitoring
|
|
|
|
|
|
|
|
Right now to track the work done in the project we use:
|
|
|
|
|
|
|
|
* Gitlab
|
|
|
|
* with labels utilizing the Gitlab Boards (kanban) to plan what needs to be done next as well as visualize what people are working on.
|
|
|
|
* milestones for what makes sense
|
|
|
|
* A spreadsheet in Nextcloud that has the timeline and status of each activity in the project. This is kept up-to-date manually by the project manager based on information from Gitlab’s tickets, project meetings and discussions with team leads.
|
|
|
|
|
|
|
|
Key performance indicators on a project:
|
|
|
|
* time spent on tasks: we do not do this but it would be desirable to keep track of time spent on tasks. For this we need people to write down estimations for their tasks as well as how much time was spent on each issue. Gitlab tickets can track this information.
|
|
|
|
* % of project completed
|
|
|
|
|
|
|
|
|
|
|
|
### Reporting
|
|
|
|
|
|
|
|
How frequently we report to the funders will depend on the requirements from the funder when we sign the agreement with them.
|
|
|
|
|
|
|
|
### Closing
|
|
|
|
|
|
|
|
* Review original documents and plans
|
|
|
|
* Retrospective once the project is completed. |
|
|
|
**Purpose of this document:** This is a _living_ document mean to be a clear, easy-to-use guide for TPI contributors who work together in projects. This page explains how we keep track of our ongoing tasks in the Tor Project.
|
|
|
|
|
|
|
|
**Questions or feedback?** Contact Project Manager (@gaba)
|
|
|
|
|
|
|
|
Project management as described here serves a few different purposes:
|
|
|
|
|
|
|
|
* Tor Project's staff want to keep a handle on what their actual current tasks are, and what everybody else is working on.
|
|
|
|
* Project managers want to understand the status of each project and if there are any blockers.
|
|
|
|
* 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 a kanban board linked from the appropriate page in [our sponsored projects](home#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 milestones. Projects may have more than one milestone to help complete its deliverables but will have only ONE label with the sponsor number to mark all the tickets for the project.
|
|
|
|
|
|
|
|
|
|
|
|
### 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 life cycle of a project?
|
|
|
|
|
|
|
|
The following steps are the different phases that a project goes through at Tor, from the moment that we start dreaming it until it is completed.
|
|
|
|
|
|
|
|
### Initiating/Ideation
|
|
|
|
|
|
|
|
“Ideas” on what we are looking funding for comes from different sources from Tor’s staff and community. We gather them from the strategy goals for the organization, ideas from the team about what work is needed for the tools they maintain that are submitted via gitlab issues or mails to grants at torproject dot org:
|
|
|
|
|
|
|
|
1. The organization’s goals for the year we are in. The strategy goals for 2023 are [a mature organization and full access to Tor](https://gitlab.torproject.org/tpo/team/-/wikis/home#organization). For 2025-2030 we [discussed the strategy](https://gitlab.torproject.org/tpo/team/-/wikis/Meetings/2024/Lisbon/5-years-strategy) during the last in-person Tor meeting.
|
|
|
|
2.Ideas submitted to the [proposals tracker](https://gitlab.torproject.org/tpo/operations/proposals/-/issues) we maintain.
|
|
|
|
3. Mails sent to the grants@torproject.org about possible projects to fund.
|
|
|
|
|
|
|
|
Determining what project to apply for depends on capacity, funding opportunities and organizational priorities.
|
|
|
|
|
|
|
|
When a call for proposals (CFP) for a grant is available we [write the proposal](/Process/Project-Design-and-Grant-Writing) 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
|
|
|
|
* Including admin overhead (PM, leads, accounting,etc)
|
|
|
|
* 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?
|
|
|
|
|
|
|
|
At this stage, the project is put into the [GrantHub platform](https://www.granthubonline.com), and assigned a number. The GrantHub platform is managed by the Grants team, and is used to track funding opportunities over the entire lifecycle.
|
|
|
|
|
|
|
|
Once the proposal is submitted to the potential funder, the process of getting it approved may take several iterations to adjust budgets, timelines, expectations, deliverables, etc. depending on the funders’ specific criteria, until the project is awarded or rejected.
|
|
|
|
|
|
|
|
All grant writing happens in ephemeral Google docs, or in the Fundraising Team/Grants folder in Nextcloud. The final version of the submitted documents are stored in the Nextcloud Fundraising Team/Grants folder.
|
|
|
|
|
|
|
|
### Planning
|
|
|
|
|
|
|
|
Once the project gets approved, the project manager gets the submitted documents that were approved and stores the approved, final version in Nextcloud in the folder Sponsors/Sponsor NN/Documents Submitted. They will also add the sponsor information to the [active Sponsors's page](home#projects).
|
|
|
|
|
|
|
|
Next the project manager will:
|
|
|
|
* Send a poll to all people involved in the project to find a day to do a kickoff meeting.
|
|
|
|
* Converts the approved time-line into a ‘status and timeline’ spreadsheet to track and change across the duration of the project.
|
|
|
|
* Creates a label ‘Sponsor NN’ in Gitlab
|
|
|
|
* Creates a [coordination meeting pad with information about the project](Process/Templates/KickoffProjectMeetingPadTemplate):
|
|
|
|
* Start and end dates
|
|
|
|
* Goals
|
|
|
|
* Who is involved in the project
|
|
|
|
* Frequency and where meetings will be held
|
|
|
|
* Links to timeline, Gitlab kanban board, sponsor folder in Nextcloud
|
|
|
|
* Deliverables that will be accomplished across the duration of the project
|
|
|
|
* Indicators used in the project, if any
|
|
|
|
|
|
|
|
The [kickoff meeting](Process/Templates/KickoffMeetingTemplate) agenda includes:
|
|
|
|
* Going over Deliverables and desired outcomes, clarifying anything that is not clear
|
|
|
|
* Reviewing what we are tracking during the project
|
|
|
|
* Define Scope (who is creating tickets for what) at this time. If possible have a presentation from "objective owners" about what they were thinking about when they wrote that specific objective and activity.
|
|
|
|
* Remind people that they need to [estimate](Process/HowToEstimate) all tickets included in this project.
|
|
|
|
* If one or more milestones will be created to track deliverables for the project then the milestone needs to 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.
|
|
|
|
* Tasks involved in the deliverable.
|
|
|
|
* Start and ending date.
|
|
|
|
* Review Timelines and Estimations as well as who is going to work on it.
|
|
|
|
* How we are going to work:
|
|
|
|
* when do we meet
|
|
|
|
* how frequently
|
|
|
|
* what to expect from these meetings (agenda, status)
|
|
|
|
* agree on how coordination and communication will happen..
|
|
|
|
|
|
|
|
Next, we create tickets, adding them to the appropiate milestone, tagging them with the sponsor label.
|
|
|
|
|
|
|
|
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 monthly or bi-weekly [meetings](Process/Templates/ProjectMeetingsTemplate) to coordinate work between project's members and adjust the timeline.
|
|
|
|
|
|
|
|
### Executing
|
|
|
|
|
|
|
|
* Tracking system
|
|
|
|
* project costs: done by CEO (Sue)
|
|
|
|
* costs: done by CEO (Sue)
|
|
|
|
* regular risks assessments (not done on a regular basis at the moment but it should be done by PM)
|
|
|
|
* how likely to miss deadline
|
|
|
|
* how much impact
|
|
|
|
* progress on activities in Gitlab as well as who is working on what.
|
|
|
|
|
|
|
|
At a pre-determined regular frequency there are voice meetings in BBB to coordinate work from the project. Each meeting will have:
|
|
|
|
* Agenda created by participants
|
|
|
|
* Status for each person in the project’s team with what they worked on in the last period, what they are planning to work next and if they need help.
|
|
|
|
* Check timeline/deliverables/outcomes if needed.
|
|
|
|
* Project-specific discussion topics
|
|
|
|
|
|
|
|
### Tracking and Monitoring
|
|
|
|
|
|
|
|
Right now to track the work done in the project we use:
|
|
|
|
|
|
|
|
* Gitlab
|
|
|
|
* with labels utilizing the Gitlab Boards (kanban) to plan what needs to be done next as well as visualize what people are working on.
|
|
|
|
* milestones for what makes sense
|
|
|
|
* A spreadsheet in Nextcloud that has the timeline and status of each activity in the project. This is kept up-to-date manually by the project manager based on information from Gitlab’s tickets, project meetings and discussions with team leads.
|
|
|
|
|
|
|
|
Key performance indicators on a project:
|
|
|
|
* time spent on tasks: we do not do this but it would be desirable to keep track of time spent on tasks. For this we need people to write down estimations for their tasks as well as how much time was spent on each issue. Gitlab tickets can track this information.
|
|
|
|
* % of project completed
|
|
|
|
|
|
|
|
|
|
|
|
### Reporting
|
|
|
|
|
|
|
|
How frequently we report to the funders will depend on the requirements from the funder when we sign the agreement with them.
|
|
|
|
|
|
|
|
### Closing
|
|
|
|
|
|
|
|
* Review original documents and plans
|
|
|
|
* Retrospective once the project is completed. |
