Hey all. I don't think I'm going to be able to join this morning's meeting due to technical difficulties, so I'm adding a couple of comments below.
On Jun 26, 2017, at 12:08 AM, Roger Dingledine arma@mit.edu wrote:
On Fri, Jun 23, 2017 at 04:41:57PM -0400, Tommy Collison wrote:
+Georg +Pastly +Catalyst +Steph
Also -- this grant is now due the 7th, so we have a whole extra week!
Thanks Tommy.
Georg, Pastly, Taylor, it will be really useful to get your insights and preferences here.
Here are some thoughts to get us going:
Step zero, where do we provide support now? In Valencia I made a list:
"What are our current places for user interaction / users to get their questions answered?" https://trac.torproject.org/projects/tor/wiki/org/meetings/2016WinterDevMeet...
Another interesting paragraph from those notes:
"Suggestion: get one person funded who will prioritize and tend the community channels. A person that wants to help. We as the community must help this person. They don't have to answer all the questions themselves, so long as they create an atmosphere where people get answers. We'd pay them to get up to speed in Tor. We need to figure out what characteristics this person must have (technical, non-technical etc)."
A support person whose job is to "tend the community channels" is quite a bit different than a support person whose job is to "assist in getting the support portal up and running". Where on the spectrum do we want to be?
This position is NOT for tending the community channels. At least not at first, and it shouldn't be in the job description. I think this is a full-time job without that.
We thought of this position as an extension of the communications team. The comm team gets lots of questions on social media and from the press that require an ability to explain technical concepts to non-technical people. That's what this position is supposed to be. This person will also help with the support portal.
I think there are two priorities we should keep in mind, and they appear to contradict each other but I argue they actually don't:
A) User support that scales is way better than user support that doesn't scale. So, we should put high value on the websites, social media, and stackexchange -- activities that reach a lot of people, and activities that teach other people how to help people. And aim less for private helpdesk responses, irc responses, mailing list responses, and other transient non-scalable approaches.
B) Our support person is going to need to learn many things, especially what problems people are experiencing *today*, and getting up to speed and staying there will involve interacting with users in many different contexts. One of the most important ways we find new bugs and usability issues we should address is by interacting with people in the blog comments, or talking to people on irc, or working with confused people on trac. We need our support person to be engaged and active in these interactive venues, with the #1 goal of learning how to help people better, and the #2 goal of (as a nice side effect) helping people.
That is, while the focus should be on support that scales, the way to get there is to participate in the more interactive, more transient places, in order to know what to write in the places that reach more users.
Corollary #1: we need a person who never regards any pieces of the Tor world as "set in stone" or "out of scope". If the person is hunting for a workaround for a Tor Browser bug, but not involving the Tor Browser people in the discussion "because they're busy developing", that's never going to be best. All website text is waiting to be improved, all user support requests should be examined to find software/documentation bugs that can be fixed so the next user doesn't have the problem, all workflows and support channels have inefficiencies that we can examine and discuss and resolve. Everything can be made better.
Corollary #2: we need a support person who has enough of a technical clue to know what's likely to be easy or hard to change, and understand how to ask the right questions to developers, and understand their answers and work toward a solution.
Corollary #3: we need a support person who can stay on track with the support mission, rather than e.g. thinking the developer side is really cool and getting bogged down trying to be a developer in all of our projects at once.
+1! We really need someone who wants to stay doing support work! Shari
--Roger
tor-community-team mailing list tor-community-team@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-community-team