Current state

Here are membership-like features that we currently have:

How does this currently work, are we happy with the criteria we have for tor-internal?

  • Too liberal.
  • It's no longer a safe space. It's also a question of size.
  • Some people on the list are not fond of Tor.

The boat has kinda sailed though. It's not just Nick, Roger, Paul, weasel, and friends. The Tor Project is not going to get any smaller

In general, there's too much traffic that should not be on tor-internal@. It's just that it's general Tor Project coordination. This should happen on a public mailing list. We do need to better refine what should go on tor-internal@.

Where do we go?

Mozilla has a clear division betwen: community members, contributors, employees. We basically can replicate that structure.

  • The Tor community: anyone who self-identify and wants to help Tor.
  • Tor Project members: people working on the project who went through a membership process.
  • Company folks: employees, contractors, board members… Anyone to which there is a legal relationship.

What you do get when you become a member?

  • You are called a member of the Tor Project.
  • You get an email address (and an XMPP account).
  • You get a shell and a personal homepage on
  • You get access to private communication channels: mailing list, chat, and the internal document repository.
  • You get the Tor Project to support requests for resources like hardware, or publicity material.
  • You get some kind of transitive trust.

Membership process

What do I need to become a member?

  • 6 months of doing stuff.
  • OpenPGP key signed by someone already in the project.
  • An advocate that is already in the project.
  • You know enough about how to use the Tor Project resources that you are going to get, like not act like a press contact if you haven't been properly prepared for it.
  • Agree with the mission statement.
  • Agree with the code of conduct.
  • Agree about keeping private things private (or should this be in the code of conduct?).
  • No vetos. That also means there's an email to the current members that present the candidate, their past contributions, and some advocacy.

There might be exceptions. But this would be the documented process that is visible to external people.


How do I become a member?


  • The applicant has been doing stuff in the project for the past six months.
  • The applicant has an OpenPGP key publicly signed by someone already in the project.
  • The applicant has one or more people in the project who are willing to support their applications (hereafter referred to as “advocates”).

Actual process:

  • The applicant send a OpenPGP-signed email to the public tor-project@ mailing list with examples of significant contributions they have done to the project.
  • One or more advocate reply to this email to support the application. These emails have to be signed with OpenPGP as well.
  • The account manager review the contributions and if they are fond to be sufficient, process to write an email to the internal mailing list with a summary of the application and ask for any vetos.
  • After two weeks, if no current project member vetoed the application, the account manager opens an OpenPGP Trac ticket to ask TSA to create the account.

Further discussions


Who is going to ensure the process runs? Do we want application managers? Who is going to review the submissions?

EDIT: Let's start with one person who is authoritative on who is a member or not. So for applications they would send summaries and seek vetos, and finally create the ticket to get the account added if everything is right.

The “Tor Project Account Manager” (like the one in Debian) would have authority to decide who is accepted or removed from the project.

It might be better if the account manager is not contracting or employed by the company.

Meanwhile, Roger has so far acted as such gatekeeper. But we don't want Roger to be running the process has he has too many things to do already.

(Damian declined has he doesn't want to be the one making the decisions.)

Loosing membership

We need a process on how people lose membership.

We also need to document or refine the suspension/reject process. And not conflate the Tor Project company and community. Who can make such decision need to be documented. It's probably bad to have someone in the company being able to kick someone from the community, just because they are an employee.

Currently, Damian pings people who are on tor-internal haven't been active for a year and ask them if they want to stay subscribed.

We could elaborate on that, e.g. if you don't do stuff for 1 year, then you are declared as “emeritus” until you can do things again.


  • Missing In Action case: Monthly or quaterly review of current members and see if anyone has been inactive for a while (like a year). Let's ping them by email and ask if they plan to get back contributing soon. In case not, or they are unresponsive then, they are moved to the “emeritus” status. The idea is that they can be fast tracked if they start contributing again regarding the whole joining process.
  • Suspension case and expulsion case: Complaints will be received by the moderation team (see Code of Conducts discussions). Actions will be decided there.

Conflicts or concerns amongst members

How can one raise concerns about another member?

EDIT: They should be addressed to the moderation team. If the complaints are about any members of the moderation team, then they should go to one of the board member.

What kind of contributions do we recognize?

Code is obvious. What about advocacy, translation, UX, etc.?

How about relay operators? Is running a relay enough to apply? How about dir. auth. operators?

EDIT: We make a distinction between the Tor Project and the Tor network. Helping with the network is not the same as helping building the software or advocating for the tools. People who are just relay operators or just dir. auth. operators can't apply for membership.

Employees and contractors

We should not require employees or contractors to be members. How do we make that work?

EDIT: If there's a internal mailing list dedicated to company matters, then we don't need to add all employees and contractors to the tor-internal@ list. If employees or contractors need to work on project-wide stuff, they can also use the newly created tor-project@ mailing list. Does people in the company think otherwise?

In any cases, we are likely to get different subscriber list between tor-assistants@ and tor-internal@ as company people might need to be on tor-assistants@ and they would not necessarily be members. Or can we move tor-assistants@ to Request Tracker or something less crazy than the current situation?


How do we move from the current unspecified situation to having actual members?

EDIT: Currently we have people not actively contributing to the project except by sending a message to the internal mailing list from time to time. What do we do? Maybe we can consider than participating in the private mailing list is a valuable contribution. Although most discussions related to the project should be moved to a tor-project@ mailing list. In any cases, we should remove people who say the want to read tor-internal@ but never participate in any ways.

The Account Manager should work with Roger (?) to review everyone currently subscribed to tor-internal@ and if they have been contributing lately, then have them formally agree on the mission statement and the code of conduct. If so, create missing LDAP accounts or switch a flag for the currently existing account.



Is “Tor Project Member” the right name?

Nick raised that “member” might have legal implications.

Mozilla uses “contributors” but we want anyone to feel like they can contribute to the project without having to go through a formal process.

Debian uses “developers” but this might be off-putting to people who don't identify as such like people doing advocacy or designers.

ArchLinux uses “Trusted Users”.

“Volunteers” would not be good as some people “in the project” are going to be employees or contractors.

Concrete things to be done to make this happen

  • Create a tor-project@ public mailing list. DONE: 2015-10-17
  • Create more or one of tor-employees@ / tor-company@ mailing list.
  • Define a policy of what should go on tor-internal@.
  • Migrate what's relevant to the internal SVN and corporate SVN into Git/Sparkleshare repositories. We different repositories for different user groups. Company stuff should go in a different directory than press which can be used by some members and some employees, than stuff that is for members (like the key to the internal IRC channel).
  • Review and refine what it means to be a member.
  • Review and refine the membership process.
  • Review the idea of the “Tor Project Account Manager”. Decide on who that could be.

Other random things

We probably want to make the distinction between community/members/employee more visible (e.g. to journalists).

In Ubuntu some people have emails and some have not. Case study on how the Ubuntu community and the GNOME community are not friendly to one another anymore. Because of what Canonical as the company did.

At Mozilla, you have to be an employee to get an email address. You lose your email address when you leave.

Last modified 4 years ago Last modified on Oct 18, 2015, 8:56:08 AM