|
|
**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.
|
|
**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)
|
|
**Questions or feedback?** Contact Project Manager (@gaba)
|
|
|
|
|
|
|
|
Project management as described here serves a few different purposes:
|
|
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.
|
|
* 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.
|
|
* 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.
|
|
* 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.
|
|
* 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.
|
|
* 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?
|
|
## 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."
|
|
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.
|
|
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 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 ".
|
|
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:
|
|
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.
|
|
* 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
|
|
### 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 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 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 is due on a particular date, it is probably a project.
|
|
|
* If it has requirements, it's 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 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 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 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 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 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.
|
|
* 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?
|
|
## What's the life cycle of a project?
|
|
|
|
|
|
|
|
### Initiating
|
|
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.
|
|
|
|
|
|
|
|
“Ideas” on what we are looking funding for comes from different sources from Tor’s staff and community.
|
|
### Initiating/Ideation
|
|
|
|
|
|
|
|
1. The organization’s goals for the year we are in. For example, for 2023 they are:
|
|
“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:
|
|
|
* A Mature Tor Project (organization)
|
|
|
|
|
* Stable income flows from a diverse funding base
|
|
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.
|
|
|
* Diverse and robust organization that meets our needs
|
|
2.Ideas submitted to the [proposals tracker](https://gitlab.torproject.org/tpo/operations/proposals/-/issues) we maintain.
|
|
|
* Strong organizational culture focuses on employees and volunteers happiness
|
|
3. Mails sent to the grants@torproject.org about possible projects to fund.
|
|
|
* Global brand recognition - Tor means strong privacy
|
|
|
|
|
* Full Access (product/projects)
|
|
Determining what project to apply for depends on capacity, funding opportunities and organizational priorities.
|
|
|
* 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
|
|
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
|
|
|
* Ensure the Tor network is diverse, healthy, stable, and scalable
|
|
* Goal: the goals of the project, why they make sense, and what the high-level features, requirements will be.
|
|
|
2. Ideas submitted to the [proposals tracker](https://gitlab.torproject.org/tpo/operations/proposals/-/issues) we maintain.
|
|
* Timeframe
|
|
|
3. Mails sent to the grants@torproject.org about possible projects to fund.
|
|
* Estimation / Budget
|
|
|
|
|
* Risks and mitigations
|
|
|
Determining what project to apply for depends on capacity, funding opportunities and organizational priorities.
|
|
* Including admin overhead (PM, leads, accounting,etc)
|
|
|
|
|
* Who should be involved
|
|
|
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
|
|
* Who has requirements authority?
|
|
|
* Goal: the goals of the project, why they make sense, and what the high-level features, requirements will be.
|
|
* Who has design authority?
|
|
|
* Timeframe
|
|
* Who has technical authority?
|
|
|
* Estimation / Budget
|
|
* Who has budget authority?
|
|
|
* Risks and mitigations
|
|
* How often will requirements and designs be reviewed, and how will adjustments be decided?
|
|
|
* Including admin overhead (PM, leads, accounting,etc)
|
|
|
|
|
* Who should be involved
|
|
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.
|
|
|
* Who has requirements authority?
|
|
|
|
|
* Who has design authority?
|
|
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.
|
|
|
* Who has technical authority?
|
|
|
|
|
* Who has budget authority?
|
|
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.
|
|
|
* How often will requirements and designs be reviewed, and how will adjustments be decided?
|
|
|
|
|
|
|
### Planning
|
|
|
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 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).
|
|
|
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.
|
|
|
|
|
|
|
Next the project manager will:
|
|
|
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.
|
|
* 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.
|
|
|
### Planning
|
|
* Creates a label ‘Sponsor NN’ in Gitlab
|
|
|
|
|
* Creates a [coordination meeting pad with information about the project](Process/Templates/KickoffProjectMeetingPadTemplate):
|
|
|
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).
|
|
* Start and end dates
|
|
|
|
|
* Goals
|
|
|
Next the project manager will:
|
|
* Who is involved in the project
|
|
|
* Send a poll to all people involved in the project to find a day to do a kickoff meeting.
|
|
* Frequency and where meetings will be held
|
|
|
* Converts the approved time-line into a ‘status and timeline’ spreadsheet to track and change across the duration of the project.
|
|
* Links to timeline, Gitlab kanban board, sponsor folder in Nextcloud
|
|
|
* Creates a label ‘Sponsor NN’ in Gitlab
|
|
* Deliverables that will be accomplished across the duration of the project
|
|
|
* Creates a [coordination meeting pad with information about the project](Process/Templates/KickoffProjectMeetingPadTemplate):
|
|
* Indicators used in the project, if any
|
|
|
* Start and end dates
|
|
|
|
|
* Goals
|
|
The [kickoff meeting](Process/Templates/KickoffMeetingTemplate) agenda includes:
|
|
|
* Who is involved in the project
|
|
* Going over Deliverables and desired outcomes, clarifying anything that is not clear
|
|
|
* Frequency and where meetings will be held
|
|
* Reviewing what we are tracking during the project
|
|
|
* Links to timeline, Gitlab kanban board, sponsor folder in Nextcloud
|
|
* 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.
|
|
|
* Deliverables that will be accomplished across the duration of the project
|
|
* Remind people that they need to [estimate](Process/HowToEstimate) all tickets included in this project.
|
|
|
* Indicators used in the project, if any
|
|
* 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.
|
|
|
The [kickoff meeting](Process/Templates/KickoffMeetingTemplate) agenda includes:
|
|
* A description of what the project entails and why we're doing it or not doing it.
|
|
|
* Going over Deliverables and desired outcomes, clarifying anything that is not clear
|
|
* Tasks involved in the deliverable.
|
|
|
* Reviewing what we are tracking during the project
|
|
* Start and ending date.
|
|
|
* 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.
|
|
* Review Timelines and Estimations as well as who is going to work on it.
|
|
|
* Remind people that they need to [estimate](Process/HowToEstimate) all tickets included in this project.
|
|
* How we are going to work:
|
|
|
* If one or more milestones will be created to track deliverables for the project then the milestone needs to contain, at minimum:
|
|
* when do we meet
|
|
|
* The name of the project.
|
|
* how frequently
|
|
|
* A description of what the project entails and why we're doing it or not doing it.
|
|
* what to expect from these meetings (agenda, status)
|
|
|
* Tasks involved in the deliverable.
|
|
* agree on how coordination and communication will happen..
|
|
|
* Start and ending date.
|
|
|
|
|
* Review Timelines and Estimations as well as who is going to work on it.
|
|
Next, we create tickets, adding them to the appropiate milestone, tagging them with the sponsor label.
|
|
|
* How we are going to work:
|
|
|
|
|
* when do we meet
|
|
The [roadmap](process/HowToBuildRoadmap) will be define by a [kanban board](https://gitlab.torproject.org/groups/tpo/-/boards) filtered by the sponsors's milestone.
|
|
|
* how frequently
|
|
|
|
|
* what to expect from these meetings (agenda, status)
|
|
### Communication
|
|
|
* agree on how coordination and communication will happen..
|
|
|
|
|
|
|
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.
|
|
|
Next, we create tickets, adding them to the appropiate milestone, tagging them with the sponsor label.
|
|
|
|
|
|
|
### Executing
|
|
|
The [roadmap](process/HowToBuildRoadmap) will be define by a [kanban board](https://gitlab.torproject.org/groups/tpo/-/boards) filtered by the sponsors's milestone.
|
|
|
|
|
|
|
* Tracking system
|
|
|
### Communication
|
|
* project costs: done by CEO (Sue)
|
|
|
|
|
* costs: done by CEO (Sue)
|
|
|
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.
|
|
* regular risks assessments (not done on a regular basis at the moment but it should be done by PM)
|
|
|
|
|
* how likely to miss deadline
|
|
|
### Executing
|
|
* how much impact
|
|
|
|
|
* progress on activities in Gitlab as well as who is working on what.
|
|
|
* Tracking system
|
|
|
|
|
* project costs: done by CEO (Sue)
|
|
At a pre-determined regular frequency there are voice meetings in BBB to coordinate work from the project. Each meeting will have:
|
|
|
* costs: done by CEO (Sue)
|
|
* Agenda created by participants
|
|
|
* regular risks assessments (not done on a regular basis at the moment but it should be done by PM)
|
|
* 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.
|
|
|
* how likely to miss deadline
|
|
* Check timeline/deliverables/outcomes if needed.
|
|
|
* how much impact
|
|
* Project-specific discussion topics
|
|
|
* progress on activities in Gitlab as well as who is working on what.
|
|
|
|
|
|
|
### Tracking and Monitoring
|
|
|
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
|
|
Right now to track the work done in the project we use:
|
|
|
* 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.
|
|
* Gitlab
|
|
|
* Project-specific discussion topics
|
|
* 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
|
|
|
### Tracking and Monitoring
|
|
* 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.
|
|
|
|
|
|
|
|
Right now to track the work done in the project we use:
|
|
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.
|
|
|
* Gitlab
|
|
* % of project completed
|
|
|
* 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.
|
|
### Reporting
|
|
|
|
|
|
|
|
Key performance indicators on a project:
|
|
How frequently we report to the funders will depend on the requirements from the funder when we sign the agreement with them.
|
|
|
* 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
|
|
### Closing
|
|
|
|
|
|
|
|
|
|
* Review original documents and plans
|
|
|
### Reporting
|
|
* Retrospective once the project is completed. |
|
|
|
|
|
|
|
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. |
|
|
