Activity
Trac:
Parent Ticket: legacy/trac#32519 (moved)
First and foremost, I think we need to communicate a policy to people when they get their @tpo email forward. That is, they should know the expected way that we will handle their email address when they move on from Tor.
Part of the problem we have now is that we haven't been clear to people in the past, so I imagine people have a variety of expectations. We're going to keep surprising people until we have a policy and we've communicated it.
One of the culture clashes here is between a free software community project, where email addresses are tied to a person who is contributing, and a company, where email addresses are 'owned' by the company and of course you shouldn't expect any email privacy or even to control who gets your email now and in the future. And some people are on both sides of the line: for example, I became arma@tpo back when it was a free software community project, and now I'm an employee and officer.
One reason this matters is because people will quite reasonably use their email addresses in different ways depending on the expected persistence. If I knew that we planned to possibly redirect my tpo mail to somebody else, or if I knew that our policy is that my tpo email address will be unreliable at getting email to me in the future, I would switch to using a domain that I know I'll continue to control.
Ok, with all this in mind, let me try to talk through some concrete options.
Option one, we decide our policy is that soon after you stop being an employee or stop being a core contributor, by default your email address goes away. I think this would be a poor choice. It would mean that folks who take a break from working on Tor will see a disruption in their contact address -- the email address they used, and likely also the one they used in their git commits -- and they will feel less wanted when considering whether to return. If this is our policy, I would get new business cards with some other domain, and probably change my git commit addresses. People would ask why my Tor card has a freehaven.net email address, and it would be embarrassing, both to me and to Tor, when I explain why.
Option two, when we are adding a new email forward, we decide whether it's in the "company" or "hacker" category, and we make it clear to the person getting it. If it's in the company category, then they know that it will go away after they leave, possibly get redirected, and all the things that company people expect to happen to their email addresses. If it's the hacker category, we'll plan by default to leave it in place unless special circumstances make us need to do something else. I think this approach would be a fine choice. There are some details still to be worked out, like how to handle the existing addresses (I think we could go through and categorize them), and how to recognize when a person has shifted category, but I think they're solvable.
Option three is like option two except the division is "are they a core contributor or not". That is, in this policy, if you have been voted in as a core contributor, you are like the "hacker" category above. Whereas if you have an email address but you didn't get it by being voted in as a core contributor, then you're like the "company" category above. I'd be fine with this approach too. In many ways it's cleaner than option two.
I also don't have any need to force a permanent email address on people who didn't expect it. I'd be fine with an approach for the hacker side where, when they become less active, we ask them if they plan to make use of the address in the future, and then they can say yes or no.
And there will definitely be exceptions where we choose to disassociate ourselves from a person, e.g. after we fire them or after the community council kicks them out of the community. I am talking here about our default policy, and exceptional circumstances can and should produce rare exceptions.
Yet another complexity comes from the conflict in how to handle company vs hacker for folks who fit into both categories. But if, when people switch from the hacker category to the company category, they give up the expectation of having a reliable email address for the future, we should make that clear to them as a tradeoff they are choosing.
Replying to arma:
[snip]
Option one, we decide our policy is that soon after you stop being an employee or stop being a core contributor, by default your email address goes away. I think this would be a poor choice. It would mean that folks who take a break from working on Tor will see a disruption in their contact address -- the email address they used, and likely also the one they used in their git commits -- and they will feel less wanted when considering whether to return.
Yes, We really should avoid that scenario if possible. From a project's perspective it's important to realize that contributors that come to us and want to work with us up to the point that they get a tpo address are a very scarce resource (if you don't believe me just look at, say, the last couple of years and count how many new people we got during that time). Thus, I would not want to alienate any of them with that option.
Option two, when we are adding a new email forward, we decide whether it's in the "company" or "hacker" category, and we make it clear to the person getting it. If it's in the company category, then they know that it will go away after they leave, possibly get redirected, and all the things that company people expect to happen to their email addresses. If it's the hacker category, we'll plan by default to leave it in place unless special circumstances make us need to do something else. I think this approach would be a fine choice. There are some details still to be worked out, like how to handle the existing addresses (I think we could go through and categorize them), and how to recognize when a person has shifted category, but I think they're solvable.
Option three is like option two except the division is "are they a core contributor or not". That is, in this policy, if you have been voted in as a core contributor, you are like the "hacker" category above. Whereas if you have an email address but you didn't get it by being voted in as a core contributor, then you're like the "company" category above. I'd be fine with this approach too. In many ways it's cleaner than option two.
I think option three is a good idea to explore, in particular as it incorporates the core contributor idea, which we worked hard to establish, as the central category for our community part.
Trac:
Cc: N/A to gk
wow that's a lot of text. :) if i may, here's a summary of the three options arma proposed:
-
deactivation delay. when a person leaves (either stops contributing to TPO or is not part of TPI), email stops working after a delay
-
two systems, with grand-father clause. like the two systems case below, but with a "grand-father" clause that give a "TPO" (or "hacker") access (ie. it doesn't get closed) to the email if they were already core before joining TPI
-
two systems: hacker and corporate. the hacker group is: if you are part of "core", your email keeps working when you leave, and never gets redirected. the corporate group includes people who did not get the email by being admitted in the "core" group, those emails are disabled or redirected when they leave.
I hope that's a good summary, please correct any misconceptions I might have carried.
That said, I'm not sure I see the distinction between option 2 and 3 above, nor what that distinction would bring in the first place. Maybe it tries to fix the "some details still to be worked out" problem, but I find those two confusing.
Furthermore, I think it misses a key idea that should be formally proposed:
- email is private, forwards for function. ie. with exceptions, emails keep working when we grant people access to @torproject.org. this includes "corporate" people that were not admitted to "core". emails are not forwarded ever, except in rare cases where accounts legitimitaly belonging to TPI/TPO should be reset and are associated with a personal email address. all "function-level" communications should happen through official channels ("fundraisigin@", "accounting@", "torproject-admin@", etc)
I understand there are strong feelings, especially in TPI, that we need to be able to forward people's emails when they leave. I would argue that is a sign of a problem in our communications more than a policy that we should adopt formally.
If people contact anarcat@ instead of torproject-admin@, that's a problem which we need to fix, for example. If only because it's possible that I eventually leave the organisation, or more likely go on a long vacation, during which time it's absolutely irrelevant to write me directly for help about TPA. I constantly remind people of this, and it generally works. If we do not institute that policy correctly, we will have a lot of trouble keeping track of those roles in the first place - using forwards is not really going to help us anyways.
Besides, it seems to me we are trying two different and somewhat unrelated problems:
- A. what happens when someone leaves: do they keep their forward?
- B. can we read other people's mail: specifically, when A happens, do we, can we, should we forward their emails to some one else?
The four proposals on the table can be formatted in this matrix, from what I understand:
Proposal A. Expiry B. Forward Notes 1. deactivation delay yes maybe? policy on forwards not clarified 2. two systems with grand-father if TPI if TPI depends on how the user got the account originally 3. two systems if TPI if TPI emails can expire and redirect if not core 4. private no no emails don't expire at all and do not forward, with exceptions I will end by mentioning that proposal 1 is the current status quo. The retire-a-user procedure I have now does deactivate users accounts and emails after a delay, and has been applied to people already. I have only recently made a note in that procude that people might need to keep their email, but that's definitely unclear.
So we definitely need more clarity on this procedure, otherwise mistakes like the one I did last week will keep on happening.
-
Replying to anarcat:
Furthermore, I think it misses a key idea that should be formally proposed:
- email is private, forwards for function. ie. with exceptions, emails keep working when we grant people access to @torproject.org. this includes "corporate" people that were not admitted to "core". emails are not forwarded ever, except in rare cases where accounts legitimitaly belonging to TPI/TPO should be reset and are associated with a personal email address. all "function-level" communications should happen through official channels ("fundraisigin@", "accounting@", "torproject-admin@", etc)
I understand there are strong feelings, especially in TPI, that we need to be able to forward people's emails when they leave. I would argue that is a sign of a problem in our communications more than a policy that we should adopt formally.
If people contact anarcat@ instead of torproject-admin@, that's a problem which we need to fix, for example. If only because it's possible that I eventually leave the organisation, or more likely go on a long vacation, during which time it's absolutely irrelevant to write me directly for help about TPA. I constantly remind people of this, and it generally works. If we do not institute that policy correctly, we will have a lot of trouble keeping track of those roles in the first place - using forwards is not really going to help us anyways.
Sending email to a person also makes it very difficult for us to distribute workload. Some people have a huge email workload. And they could do with some help handling it.
Using role-based addresses is one solution to this issue. Multiple people can get access to a role-based account. And people can redirect all their role-based mail when they are busy with other tasks, or when they go on leave.
Besides, it seems to me we are trying two different and somewhat unrelated problems:
- A. what happens when someone leaves: do they keep their forward?
- B. can we read other people's mail: specifically, when A happens, do we, can we, should we forward their emails to some one else?
I also think we should be very careful of the ethical and legal implications of reading other people's mail. We talk a lot about human rights, and the right to privacy. We should recognise and respect the privacy rights of Tor staff and volunteers.
We also work with people in Europe, and other jurisdictions with strong privacy laws. I'm not a lawyer, but we should talk to lawyers before creating policies where we read other people's mail.
okay, this ticket is old, and long, and stuck in the icebox and will not go anywhere unless we do something about it, so let's.
we actually talked about this with gaba at an adhoc meeting about onboarding&offboarding and we concluded we "just" need to make a proposal and see if it sticks... right now the idea is this:
when someone is laid off, resigns, or is fired, we setup an auto-reply with a bounce announcing the replacement email (if any), to give agency to the sender. the auto-reply expires 12 months later. we also remove existing forwards older than 12 months that we already have.
i'm happy to discuss this here further, but i think the next step here is to draft a TPA-RFC with this proposal. i just figured i'd give a heads up before doing that work, just in case someone had a better brilliant idea (which is, i guess, the whole purpose of TPA-RFCs, so i'll probably just make the rfc anyways)...