... | ... | @@ -2,11 +2,13 @@ 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.
|
|
|
* 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."
|
... | ... | @@ -18,7 +20,7 @@ Projects involve creating or enhancing some **products**. Most of our **product |
|
|
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.
|
|
|
* 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
|
... | ... | @@ -34,17 +36,33 @@ There are a few ways we represent projects, depending on their status: |
|
|
* (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?
|
|
|
## What's the lifetime of a project?
|
|
|
|
|
|
### Initiating
|
|
|
|
|
|
1. We maintain a [list of ideas](https://gitlab.torproject.org/tpo/operations/proposals/-/boards/857) 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).
|
|
|
“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.
|
|
|
|
|
|
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
|
|
|
When a call for proposals (CFP) for a grant 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: 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?
|
... | ... | @@ -52,41 +70,88 @@ There are a few ways we represent projects, depending on their status: |
|
|
* Who has budget authority?
|
|
|
* 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.
|
|
|
|
|
|
3. Get [project](project/ProjectLife) 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.
|
|
|
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.
|
|
|
|
|
|
4. Hold a [kickoff meeting](process/KickoffMeetingTemplate) with all stakeholders from the project.
|
|
|
* define scope - have presentation from the "objective owners" about what they were thinking about when they wrote that specific objective and activity
|
|
|
* show timeline of the project and who is going to work on it
|
|
|
* agree on how coordination and communication will happen.
|
|
|
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.
|
|
|
|
|
|
5. Next, we create tickets, adding them to the milestone, tagging them with the sponsor label. Add the objectives, activities and indicators to the public milestone in gitlab.
|
|
|
### Planning
|
|
|
|
|
|
6. The [roadmap](process/HowToBuildRoadmap) will be define by a [kanban board](https://gitlab.torproject.org/groups/tpo/-/boards) filtered by the sponsors's milestone.
|
|
|
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:
|
|
|
* 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.
|
|
|
* 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 [bi-weekly meetings](process/project-meetings-template) to coordinate work between project's members and adjust the roadmap.
|
|
|
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
|
|
|
|
|
|
### Monitoring
|
|
|
* 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.
|
|
|
|
|
|
* Key performance indicators
|
|
|
* time spent on tasks
|
|
|
* money spent on tasks
|
|
|
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
|
|
|
* 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.
|
|
|
### 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 |
|
|
* Review original documents and plans
|
|
|
* Retrospective once the project is completed. |
|
|
\ No newline at end of file |