Hi Alison,

Here's the mail from last summer, with the "new" (as of then) organization and coordination plan. Hopefully this will be useful to you in figuring out the past, present, and future for the community team.

I am also cc'ing tor-project here, since there's nothing sekrit in the below mail, and we should get into the habit of publishing stuff that used to maybe be sensitive but now probably isn't.

--Roger

----- Forwarded message from Roger Dingledine arma@mit.edu -----

Date: Mon, 25 May 2015 09:02:22 -0400 From: Roger Dingledine arma@mit.edu To: tor-internal@lists.torproject.org Subject: Team-based structure (Vegas Plan, mark 2)

Hi folks!

In my last mail I mentioned the topic of org structure. In my mind the main goals we're trying to solve with a better-understood structure are:

1) Better communication and coordination, both inside the team and between teams.

2) Give everybody a home. That is, have a named person who can help you when you need help with something (there's a conflict between you and somebody, you need some specific resource to accomplish your tasks, you don't know what you should work on next, ...).

With that in mind, here is one way we could divide up into teams:

---------------------------------------------------------------------

Community team Kate Jake Harmony Leiah Nima Sebastian

Network team Nick Yawning George Dgoulet Andrea Isis Aaron Gibson

Applications team Mike Geko Pearl Crescent Arthur Nicolas Arlo Sukhbir Support team

Measurement team Karsten Arturo Philipp Winter Virgil

Operations team Tom Steve Sue Abt

---------------------------------------------------------------------

Some observations to help you understand why I made these choices:

- I called the community team that name rather than outreach or advocacy or communications because its focus is on our people, inside and out: communicating to them, learning from them, getting them involved in making more Tor. So it includes Tor Weekly News, making the website accessible, handling press, doing trainings and conferences and materials to go with that, and all forms of outreach.

- The "network" team is what I would have called the "tor" team, but Nick used the word 'network' once so I'm using it here. This is the backend: the program called Tor, the pluggable transports, the bridge distribution, the network simulators, the scripts that support directory authorities, etc.

- The applications team works on the programs that end users think of as Tor: Tor Browser, other apps that bundle Tor, the equivalents on Android/iOS, and builds and QA for these applications. This team also works on enabling users to actually use these applications: that includes phrases like UX design, documentation, making sure that users can find answers to common questions, and making sure that developers know which questions are common so they can prioritize them.

- The measurement team mashes together metrics, OONI, badexit detection, onionoo and the community websites that draw from onionoo, and the research groups who care about our data.

- And lastly, I put an explicit operations team on the list, even though it is small and probably doesn't have enough people on it to do everything it will want to do. But I realized that if I didn't list it, I would be reinforcing the assumption that "operations team" and "execdir" are synonyms.

- There are other tiny and lonely teams that I didn't list. For example, we might imagine an "infrastructure team" with weasel and qbi on it. But I'm wary of loading our kind volunteer sysadmins down with the communication responsibilities of being their own team. I guess the other conclusion there is that we should sketch out which teams are missing now compared to the future well-functioning and better-balanced Tor, and figure out a plan and timeline for getting from here to there.

- Some of the choices could easily have gone another way. For example, why is the badexit detection work in the measurement team, and not in the network team? Is Tails part of applications, or part of community? We'll need to adapt based on what's working and what isn't working.

- There are many people and groups that I didn't list in the above. That doesn't mean we don't like you, or that you're less valuable than the people I did list. I mostly focused on the people who get paid in some way for this work. Many of our volunteers fit into multiple categories (e.g. Matt Finkel could be community, could be network, probably could be a third as well). I'll leave it to them which team they want to be their 'home', also keeping in mind that these don't need to be permanent decisions. So think of this as an opportunity to choose your own destiny. :)

- You'll notice that Isabela and Roger aren't in the list. That's because I've signed us up to be facilitators of the whole process. Maybe that means you can think of us like being on every team? We should be careful of accidentally thinking of these two people as k+1 people each though.

- You'll also notice that these teams are broken up by functionality and purpose, not by funders. So for example we don't have a SponsorR team, even though that project ties together many teams. So we're going to need to cooperate and coordinate between the teams to keep various funders happy.

---------------------------------------------------------------------

How do the teams work? You'll notice I didn't call out 'team leaders' or 'managers' or the like.

The goal, original Vegas plan style, is for each team to self-organize so it can fulfill its responsibilities. Some teams will pick a person to be their primary person. Other teams will divide up responsibilities, or trade off, or whatever works for them.

That said, I did list a person at the top of each team who I'm hoping will be instrumental in leading the self-organizing.

---------------------------------------------------------------------

What are the responsibilities of each team? That's something we should work through together. Here are some we might choose:

- Keep everybody inside the team coordinated on what needs to be done, who's doing it, how it's going, etc.

- Summarize for the other teams what your team is up to -- what you've done and what you want to do.

- Summarize for your own team what the other teams are up to. That is, here is one way to solve the n-to-n communication scaling problem.

- Solve problems inside your team when you can, and when you can't, escalate them to get help from the other teams. That is, part of the team responsibility is to help the other teams when they have problems they can't solve internally. As opposed to turning me into the central manager for everybody -- one day we might have a dedicated operations director who magically fills that role, but we're not there right now, and we're probably going to be happier if we're better at handling issues as a team of teams.

- Maintain the roadmaps for your team, including brainstorming things you should do that funders would pay for, and helping to frame these for funders so it's clear why they should. Some teams will do their own grantwriting, whereas other teams aren't set up right now for being good at it themselves. I'd like to resist having a separate 'fundraising team', since that's a great way for teams to pretend that it's somebody else's problem. This topic also ties into our general "how we want to get funded" discussions -- in the future it can't all be writing grants.

In the past we've gone to new funders with peripheral (experimental) projects, which has been risky because we don't always put the organizational resources behind them to ensure their success. I think our better strategy in the future is to do more fundraising by the core projects, and use this funding to do the peripheral experimental projects. For example, raise money for Tor Browser to generalize Tor Launcher to make it easier to build things like Tor Messenger. More on this topic later.

- One thing that's missing in this plan is the more traditional "manager" roles: doing intra-team performance reviews, identifying when people aren't pulling their weight, working to resolve issues like this. I worry that doubling up the roles will, in Karsten's words, "change the character of the team idea from a supporting structure to a power structure." Is our best plan there to continue stalling until we get the operations team more up to speed? Input here would be great. (A supporting structure is still helpful here, because it gives more chances to answer the question "What is so-and-so doing?")

Next week (June 4-6) some of us are getting together in Boston to discuss structure among other topics. Somebody from each team will be there. So please discuss amongst your team if there's some outcome or direction you want us to be sure to include.

--Roger

----- End forwarded message -----