- tor-project - lists.torproject.org

(FWD) Team-based structure (Vegas Plan, mark 2)
by Roger Dingledine 21 Mar '16

21 Mar '16

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(a)mit.edu> ----- Date: Mon, 25 May 2015 09:02:22 -0400 From: Roger Dingledine <arma(a)mit.edu> To: tor-internal(a)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 -----

1 0

(FWD) Submit to FOCI '16?
by Roger Dingledine 21 Mar '16

21 Mar '16

If you have been doing something exciting lately (I know many of you have!), consider writing it up as a FOCI submission. If you need help figuring out what to write, or what would be a good submission, etc, let me or others know and we'll try to help. Also if you've done a cool thing but don't have time to write it all up, you might be able to team up with some academics here who would help with the writing-up. See recent FOCI programs here: https://www.usenix.org/conference/foci15/workshop-program https://www.usenix.org/conference/foci14/workshop-program https://www.usenix.org/conference/foci13/workshop-program --Roger ----- Forwarded message from Prateek Mittal <pmittal(a)princeton.edu> ----- Date: Mon, 21 Mar 2016 17:03:16 -0400 From: Prateek Mittal <pmittal(a)princeton.edu> To: Roger Dingledine <arma(a)mit.edu>, Nick Mathewson <nickm(a)freehaven.net>, Mike Perry <mikeperry(a)fscked.org>, karsten(a)torproject.org Cc: Amir Houmansadr <amir(a)cs.umass.edu>, FOCI '16 Program Co-Chairs <foci16chairs(a)usenix.org>, Sandy Ordonez <sandra(a)opentechfund.org> Subject: Submit to FOCI '16? Hi Roger, Nick, Mike, Karsten, Hope things are well. Given exciting recent developments across the Tor ecosystem, we are writing to encourage you (and your colleagues) to submit your work to this year???s Workshop on Free and Open Communications on the Internet (FOCI '16). FOCI 2016 will be co-located with USENIX Security in Austin, TX on August 8 2016. This year, we're looking for six-page papers on any aspect of freedom of communications on the Internet, ranging from technical research on circumventing or measuring censorship, to research at the intersection of policy, regulation, social science and law. (For example, new Tor mechanisms -- both planned and deployed, new threats facing Tor, and experience + roadmap papers could all be a great fit.) https://www.usenix.org/conference/foci16 <https://www.usenix.org/conference/foci16>The submission deadline is May 2. Also, if you know anybody else who should know about it, please help us spread the word. Thanks! Amir and Prateek (Co-Chairs) -- Prateek Mittal Assistant Professor Princeton University http://www.princeton.edu/~pmittal/ ----- End forwarded message -----

1 0

A Statement from The Tor Project on Software Integrity and Apple
by Kate Krauss 21 Mar '16

21 Mar '16

A Statement from The Tor Project on Software Integrity and Apple The Tor Project exists to provide privacy and anonymity for millions of people, including human rights defenders across the globe whose lives depend on it. The strong encryption built into our software is essential for their safety. In an age when people have so little control over the information recorded about their lives, we believe that privacy is worth fighting for. We therefore stand with Apple to defend strong encryption and to oppose government pressure to weaken it. We will never backdoor our software. Our users face very serious threats. These users include bloggers reporting on drug violence in Latin America; dissidents in China, Russia, and the Middle East; police and military officers who use our software to keep themselves safe on the job; and LGBTI individuals who face persecution nearly everywhere. Even in Western societies, studies demonstrate that intelligence agencies such as the NSA are chilling dissent and silencing political discourse <http://m.jmq.sagepub.com/content/early/2016/02/25/1077699016630255.full.pdf…> merely through the threat of pervasive surveillance. For all of our users, their privacy is their security. And for all of them, that privacy depends upon the integrity of our software, and on strong cryptography. Any weakness introduced to help a particular government would inevitably be discovered and could be used against all of our users. The Tor Project employs several mechanisms to ensure the security and integrity of our software. Our primary product, the Tor Browser, is fully open source. Moreover, anyone can obtain our source code and produce bit-for-bit identical copies of the programs we distribute using Reproducible Builds <https://blog.torproject.org/blog/deterministic-builds-part-one-cyberwar-and…>, eliminating the possibility of single points of compromise or coercion in our software build process. The Tor Browser downloads its software updates anonymously using the Tor network, and update requests contain no identifying information that could be used to deliver targeted malicious updates <http://arstechnica.com/security/2016/02/most-software-already-has-a-golden-…> to specific users. These requests also use HTTPS encryption <https://www.eff.org/pages/tor-and-https> and pinned HTTPS certificates (a security mechanism that allows HTTPS websites to resist being impersonated by an attacker by specifying exact cryptographic keys for sites). Finally, the updates themselves are also protected by strong cryptography, in the form of package-level cryptographic signatures (the Tor Project signs the update files themselves). This use of multiple independent cryptographic mechanisms and independent keys reduces the risk of single points of failure. The Tor Project has never received a legal demand to place a backdoor in its programs or source code, nor have we received any requests to hand over cryptographic signing material. This isn't surprising: we've been public about our "no backdoors, ever <https://www.torproject.org/docs/faq#Backdoor>" stance, we've had clear public support from our friends at EFF and ACLU, and it's well-known that our open source engineering processes and distributed architecture make it hard to add a backdoor quietly. From an engineering perspective, our code review and open source development processes make it likely that such a backdoor would be quickly discovered. We are also currently accelerating the development of a vulnerability-reporting reward program to encourage external software developers to look for and report any vulnerabilities that affect our primary software products. The threats that Apple faces to hand over its cryptographic signing keys <http://fortune.com/2016/03/11/apple-fbi-source-code-signature/> to the US government (or to sign alternate versions of its software for the US government) are no different than threats of force or compromise that any of our developers or our volunteer network operators may face from any actor, governmental or not. For this reason, regardless of the outcome of the Apple decision, we are exploring further ways to eliminate single points of failure, so that even if a government or a criminal obtains our cryptographic keys, our distributed network and its users would be able to detect this fact and report it to us as a security issue. Like those at Apple <http://www.nytimes.com/2016/03/18/technology/apple-encryption-engineers-if-…>, several of our developers have already stated that they would rather resign than honor any request to introduce a backdoor or vulnerability into our software that could be used to harm our users. We look forward to making an official public statement on this commitment as the situation unfolds. However, since requests for backdoors or cryptographic key material so closely resemble many other forms of security failure, we remain committed to researching and developing engineering solutions to further mitigate these risks, regardless of their origin. We congratulate Apple on their commitment to the privacy and security of their users, and we admire their efforts to advance the debate over the right to privacy and security for all. -- Kate Krauss Director of Communications and Public Policy kate(a)torproject.org @TorProject 1-718-864-6647 (works for Signal also) PGP: CC0D 9B42 DE89 D4D0 619B A606 DDEB 3937 7D18 973B

2 1

Tor Lecture at ANU
by Tim Wilson-Brown - teor 18 Mar '16

18 Mar '16

Hi, I've been invited to give a lecture about Tor to a Computer Networks class at The Australian National University (ANU). It's a class I took more than a decade ago, and I've kept in touch with the lecturer. This is the first time I've given a lecture on Tor. I've been asked to speak about Tor in general, browser fingerprinting, and single onion services. I was thinking of using some of the images from: https://www.torproject.org/about/overview.html.en#thesolution <https://www.torproject.org/about/overview.html.en#thesolution> https://www.torproject.org/docs/hidden-services.html.en <https://www.torproject.org/docs/hidden-services.html.en> I'm scheduled for next Thursday Australian time (which is Wednesday UTC / US time). Does anyone have any tips for giving a talk on Tor, or any other diagrams that would be useful for slides? Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F

5 4

GSoC idea - Feedback/Report extension for TB
by Nima Fatemi 16 Mar '16

16 Mar '16

Hey there, As I've mentioned on IRC, I've this idea to create an extension for Tor Browser. Such a thing could really improve our relationship with end-users while helping us to collect the metrics we need for UX on an opt-in basis. Initially I was thinking of this as a mechanism for users to give us feedback and report problems they might encounter while using the browser. But after some thoughts and specially after seeing dcf's notes from UX session at dev meeting[1], I realized we could even take this further. This could be even used by users who have problem connecting to Tor network to troubleshoot their connectivity issues or it could give us a hint on how and when a network starts blocking Tor connections. To write a simple list of the things I think this extension could do: - Have a message box to submit feedback + we could let them to attach img as well + or we could include a checkbox that would automatically take an screenshot of the Tor Browser window. I think chrome used to have such feature. - Have an option to opt in for network tests. Test different protocols and see if vanilla tor or any of the Pluggable Transports are being blocked. - Collect some information about their network and computers: such as operating system, version of tor browser, country code, maybe AS Number, etc. There are some open questions to answer. eg how to safely submit collected data? I was thinking maybe over onion but that's only if user has gotten past tor-launcher and tor is running properly. All of this obviously should be opt-in only and is a very good thing for the review-board to approve before going live. What do you think? Is it worth to give it a shot at GSoC? sukhe and willscott have showed interest in mentoring. Can we have three mentors for GSoC? [1] https://trac.torproject.org/projects/tor/wiki/org/meetings/2016WinterDevMee… -- Nima 0XC009DB191C92A77B | @mrphs "I disapprove of what you say, but I will defend to the death your right to say it" --Evelyn Beatrice Hall

5 6

Support plan proposal
by Colin Childs 16 Mar '16

16 Mar '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi everyone, Below is the support plan proposal that has been mentioned in the "State of the helpdesk?" thread. Feedback is very much welcomed, as there may be things I have not considered, or have missed. Documentation updating: 1. Update Tor Browser user manual [1] 2. Update HS guide [2] 3. Update relay guides [3] Note: When users contact the help-desk, the majority of questions would fit into these three topics. The majority of the majority would fall into the user manual, however there are still tickets about running / maintaining relays and HSs. Support portal creation and/or FAQ updating: 1. Convert RequestTracker articles[4] into user-usable resources 2. Determine if these resources should be added to FAQ, or to their own page. My opinion, is that we could create something like Twitter's "Help Center"[5] using a combination of these articles, and expanded FAQ entri es. 3. If the help portal option is favored, researching which free platforms we could use for this would be my next step. I'm also confident that creating something with basic functionality would not be a large time sink, however this seems like a problem that is likely solv ed. Providing direct user support: I believe with the documentation updates, and making the support articles more easily available will decrease the number of users who require our assistance; but it will never result in no users requiring assistance. The best solution I can think of, is the following: 1. Finish "Documentation updating" and "Support portal creation and/or FAQ updating" tasks 2. Announce the new resources on the Tor blog, and other platforms 3. Watch for and incorporate feedback on the new resources 4. Put out another call for volunteers, as well as reach out to previous help-desk staff 5. Re-open the help-desk, to a (hopefully) more manageable number of tickets. [1]: https://lists.torproject.org/pipermail/tor-project/2016-March/000151.htm l [2]: https://www.torproject.org/docs/tor-hidden-service.html.en [3]: https://www.torproject.org/docs/tor-relay-debian.html.en [4]: https://people.torproject.org/~colin/rt-articles.git [5]: https://support.twitter.com/ - -- Colin Childs Tor Project https://www.torproject.org Twitter: @Phoul -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJW4PqVAAoJEJWQHABkmqq5F50P/1Tq5fvzc07bUiQea4goq3no OdwD8NUFdFLK4EZe165Cedqoaddz3uWkOUmJmYtUBILLvjHp6E/AWhrIHBU1hCXv WenOKat6kQPhgH8FKCGt2r9UtVRQ1y78JwthFN/m9uUBMIYmAxhMfe/tf20/2G9c l2jph9SHU1q1NQrBhQ65ch+ZkZXZtPtEaM55eK/jyuYY6U8oHFYo0U1o1dq0tv/C +St9OWgTUMLto0lghhSfuU/1cmjW4vB8OeF+Sy3F8Hqs35ZgDP/0yccG1QbSsxIv Jytz6s6k/0+7PeE22s4EIcUDC1AY9+W14KcR/TCEjDFB+EqdyRYnS45nyHZ8Vhm9 tzig2To87pE8m/uUU1CT9uUkuSdJiunYWQYoiicJ00c3E/pxU/8d5Sea+Ic7C6jO vejR64jHW4/DShCOq0UspZnMIPUfcElMIEvsyQ4SmcDfZfEaimFoksaPVGGnihLb AfQRue2v5FQx36ulwNRoypZcqtYvQA3b8l+mGaP49C1qLeg2t8jESYjv4L9fAIdf HLVvj/kWS51dYkcrUaUBE++vVBjXlpctjfRvT3Qav3fT0gSiOs3nQkaOwJeG71rV 1CvdxP0bPfMAtHk9shovvNiqwPi9tREu9edWUhIsgKY5Quf9ZzS/5+skElpVt5yK xnUKSRSjDr8vriZfoMOa =Hksr -----END PGP SIGNATURE-----

2 1

First report from UN Special Rapporteur on Privacy
by Virgil Griffith 11 Mar '16

11 Mar '16

Of interest to Tor people---first report by the UN Special Rapporteur on the Right to Privacy: * http://dl.dropbox.com/u/3308162/A-HRC-31-64.pdf "As the Special Rapporteur mentioned in presenting his report at the Human Rights Council today, his focus is currently on defining “what" to protect (defining privacy) and “why" (privacy as an enabling right rather than as an end in itself), whereas the “how” is envisioned for a much later stage in his mandate." If someone on the list wants to get into this I'll make the appropriate connections. -V ---------- Forwarded message ---------- From: Nicolas Seidler <seidler(a)isoc.org> Date: Wed, Mar 9, 2016 at 7:06 AM Subject: [Internet Policy] Heads-up: new report by UN Special Rapporteur on Privacy To: "internetpolicy(a)elists.isoc.org" <internetpolicy(a)elists.isoc.org> Dear all, I would like to bring your attention to the release of the first report by the UN Special Rapporteur on the Right to Privacy, Joseph A. Cannataci. http://www.ohchr.org/EN/HRBodies/HRC/RegularSessions/Session31/Documents/A-… As we mentioned when this mandate was created, this is a brand new position in the UN Human Rights Council that was created as part of reactions to disclosures on pervasive communication surveillance (including at the UN General Assembly level in December 2014). We are still going through the report and will share more thoughts later on. We can however already note that this first report focuses on defining a roadmap for the Special Rapporteur, and highlighting what he considers as key issues for his mandate going forward. As the Special Rapporteur mentioned in presenting his report at the Human Rights Council today, his focus is currently on defining “what" to protect (defining privacy) and “why" (privacy as an enabling right rather than as an end in itself), whereas the “how” is envisioned for a much later stage in his mandate. ISOC will continue to follow closely this process and to offer a bridge for our community’s input in the Special Rapporteur’s mandate, who is keen to consult a wide range of stakeholders. Be on the lookout for more analysis next week, and in the meantime do not hesitate to share your thoughts. Best regards, Nicolas Seidler Senior Policy Advisor The Internet Society _______________________________________________ To manage your ISOC subscriptions or unsubscribe, please log into the ISOC Member Portal: https://portal.isoc.org/ Then choose Interests & Subscriptions from the My Account menu.

1 0

Moderation for new tor-users@ mailing list
by Moritz Bartl 11 Mar '16

11 Mar '16

Hi everyone, At the Valencia dev meeting, in the "take back community channels"[1] session, we discussed how to deal with the somewhat degenerated tor-talk mailing list. The initial idea was to come up with some excellent, nice and reasonable guidelines and explanations of what should be on tor-talk (and, subsequently, what should be posted someplace else, and where), switch tor-talk to be moderated, and then moderate users for a while until they have shown to agree to the guidelines. Also, step up moderation a bit in the sense that if a user starts to post off-topic things again to warn them, or put them back into moderation. A less aggressive approach was discussed, which involves the creation of a new list called "tor-users". This new list will not ahve all the thousands(?) of subscribers of tor-talk, which is a shame, but it might be easier to apply a new moderation concept to a new list and sort-of give up the old one, than trying to change the climate on the old list. Also, the idea for the new list was to explicitly have a more narrow focus than the broad "tor-talk" list, namely "(community) user support". weasel suggested a set of scripts that they used at Debian for some list moderation. It sure sounds great to use IMAP and mail move actions for moderation instead of the mailman interface. It does not necessarily require TPI to officially run an IMAP server; we could use an account someplace else, and even run the scripts outside of TPI if we wanted to. We did succeed in that we now have a number of volunteers who want to help moderate. (Not enough, please let me know if you want to help, too). I am the unfortunate volunteer that even agreed to "lead" this effort! :-) What we still don't have is a nice and friendly mail that explains the concept and the underlying guidelines, and points to other potential venues (like cpunks maybe) if people want to discuss other things. Does anyone want to come up with a draft for discussion? I guess ideally we even have a couple of templates to use in mailman for rejection messages, but we can come up with those while we go along. I don't think I should be the one writing it, we have native speakers with better writing skills amongst ourselves :) Weasel, what's the status of those moderation scripts, and what kind of suggestions do you have on moving that forward? Sorry that I didn't want to talk about it back in Valencia when you wanted to, but I really wasn't in the right mood... Can you dig them up so I can have a look? Do you want to run them on TPI infrastructure? Do you wnt me to run them on mine? [1] https://trac.torproject.org/projects/tor/wiki/org/meetings/2016WinterDevMee… -- Moritz

2 1

NH Tor bill overwhelmingly passes the house!!!
by Alison Macrina 10 Mar '16

10 Mar '16

Great news! The pro-Tor bill [1] from NH State Rep Keith Ammon just passed the NH House by a HUGE margin -- 268-62!!! This is a really big deal, not just because it shows how much support there is from NH congresspeople, but because it was expected not to pass (they were anticipating a floor fight [2]). This bill is not yet a law -- it still needs to go before the NH Senate and pass there. But this makes me hopeful! The ACLU of NH is working with Rep Ammon on a senate strategy, and I may provide additional testimony if needed. I'll keep everyone posted on this. Alison [1] http://www.dailydot.com/politics/new-hampshire-tor-library-legislation/ [2] http://www.dailydot.com/politics/tor-bill-new-hampshire-floor-fight/

2 1

State of helpdesk?
by Roger Dingledine 09 Mar '16

09 Mar '16

Hi Colin, I had a good chat last week with one of the volunteers that you recruited some months ago to help with the helpdesk. He told me that he wasn't answering tickets anymore, since it is just a deluge of tickets, mostly the same over and over, and without any feedback mechanisms from the helpdesk to the other support pieces (faq, stackexchange, etc) and dev teams, there isn't really an end in sight. I suspect I agree with him -- taking a step back, it seems wise for us to enumerate our support mechanisms, and try to prioritize and triage so we do what is most scalable and most sustainable. That said, I don't think many of us have a good handle on where the helpdesk is right now. So it's hard for us to know where it should fit in this triaging. Can you summarize for us how many tickets it's getting, how many (and which) people are active, whether most tickets are getting answered (and after how long), what languages they're in, and whatever other questions I ought to be asking? Then we will be in a better position to try to help you. Thanks! --Roger

3 7