Introduction
Tor has all-hands meetings roughly twice a year. These meetings are typically broken into three parts: team meetings (staff and invited volunteers only), community meetings (staff and invited community members), and public days (open to everyone).
This page serves to provide meeting templates primarily for the team meetings, with some overlap for community meetings. It is intended to describe the types of meetings all teams should have, as well as additional meetings that individual teams tend to have.
Every meeting has at least three components: Goals, Outputs, and Stakeholders. Meetings can also have additional explicit non-goals, and may also list Bottlenecks -- people who need to be there, but tend to be in high demand for other concurrent meetings.
When creating a schedule using these templates, be sure to write down specifics for these fields for your meeting in the schedule. In particular, the Duration, Stakeholders, and Bottleneck fields are essential to ensure proper scheduling. The Stakeholders field will help determine if this is a team meeting, or if it should be held on one of the community days.
Meeting Templates
Here is a template template that you can copy+paste to create a new meeting type:
| Duration | 20 minutes, 60 minutes, 90 minutes |
|---|---|
| Description | What is this meeting about? How does it usually run? |
| Goal | Describe the meeting's goal. Goals should be substantive and ideally also measurable, so we can ensure meeting time is well spent. |
| Non-Goals | Describe ways this meeting type can get derailed or distracted by off-topic material (optional) |
| Outputs | What notes/diagrams/documents/tickets should the meeting produce? |
| Stakeholders | Who has to attend the meeting in order for it to reach its goals? |
| Bottlenecks | Who do we need to attend for a decision to be made, but is at risk of having a conflict? (optional) |
Meetings that every team has (almost) every 6 months
Team Roadmap
| Duration | 60 minutes |
|---|---|
| Description | Plan and document what the team wants to accomplish in the next 6 months. For development-oriented teams, this is the creation of milestones and a schedule. For non-development teams (and Agile teams), this is a story or narrative (or set of narratives) of what Tor should look like in 6 months as a result of your work. |
| Goal | Produce a plan for the next 6 months, with specific people committing to roles and/or specific action items. |
| Outputs | For development teams, this is usually a schedule of post-it notes that gets transferred to the wiki and trac tags, usually with difficulty estimates and people+sponsor tags. For non-development or agile teams, this can be a written narrative of a plan, with specific action items and/or roles needed to achieve that plan. |
| Stakeholders | Team members |
| Bottlenecks | Isabela |
Team Retrospective
| Duration | 60 minutes |
|---|---|
| Description | Review the roadmap from the last 6 months, with an eye towards process improvements. What did you achieve? What didn't you achieve? Why? Are any sponsor deliverables or contracts at risk? Are there any processes, estimating, or scheduling improvements that you can make to improve your ability to execute? For non-development teams (and Agile teams), how does your narrative match reality today. Is there anything that you should try to do differently this time around? See this list of retrospective meeting formats for ideas. |
| Goal | Evaluate and improve workflow and planning processes. |
| Outputs | For development teams, this is usually changes to development process, meetings, trac usage, etc. For non-development or agile teams, the outputs will depend on your workflow, etc. |
| Stakeholders | Team members |
| Bottlenecks | Isabela? |
Funding Proposal Discussion
| Duration | 60 minutes |
|---|---|
| Description | Discussion of potential future funding proposals |
| Goal | To come up with and discuss things that either specific teams (or the org) wants to pitch to funders. |
| Outputs | Notes on the funding proposal -- what will it involve, who will do the work, how much will it cost, etc. |
| Stakeholders | Team Lead(s) of teams involved, Tommy |
| Bottlenecks | Team Leads, Tommy, Isabela? |
Tor Network Team Meetings
The Tor network team tends to follow a waterfall model. Development progresses in phases, with new features typically going from idea/trac ticket, to a draft proposal, to an accepted proposal, to a prototype, and finally to an implementation. Thus the team will tend to have meetings on specific upcoming proposals that may not require the entire team, but will often require key people to be present at critical points to make decisions. Thus it is a good idea to review the set of open/draft proposals when coming up with meeting ideas, since many of them will need attention.
Proposal Discussion
| Description | Discussion of a specific design proposal, or to-be-written proposal. |
|---|---|
| Goal | To move a proposal forward -- get enough agreement to move a proposal into the next stage of development |
| Outputs | Notes on proposal updates; action items for next steps; ownership assignment for said updates/action items |
| Stakeholders | People who are interested in working on the proposal |
| Bottlenecks | Often Nick and Roger, especially for accepted/about-to-be-implemented proposals |
Cross-Team Coordination Meeting
| Description | Coordination between tor-core and things that use it. Other teams, tools, products, and components often need features from Tor. Coordination meetings are usually about a specific feature, but if you notice that the schedule has no coordination meetings proposed, it probably is a good idea to add a generic general one for people to show up to. |
|---|---|
| Goals | Determine what new features are needed by others, and discuss how they should work. |
| Outputs | Design sketches; proposal notes; trac tickets. |
| Stakeholders | Nick, Isabela, members from other teams |
| Bottlenecks | Nick, Isabela |
Tor Browser Team Meetings
The Tor Browser team tends to follow an Agile/Scrum development model. Tickets are grouped into categories depending on type of issue (tracking, fingerprinting, usability, hardening, etc), and the team pulls tickets off of the backlog to work on them.