Let's not advertise help desk emails directly
Tor Browser 3.5 now advertises support help desk emails more prominently. While showing our users how to get help is a great idea, giving them an help desk address directly puts a severe load on the support assistants that could partially be avoided.
I think we should rather point them to a web page with the following:
- List of Tor Browser known issues.
- Frequently Asked Questions related to Tor Browser
- Frequently Asked Questions related to Tor
- The help desk emails
That list can be refined over time.
The ticket should probably be split in multiple things, as it concerns Tor Browser release management (for the list of known issues) and the website.
Activity
Seconded. https://trac.torproject.org/projects/tor/ticket/5811 seems like a reasonable solution to me.
I agree. We should be linking to some kind of FAQ document that lists common questions, links to the user manual, and then finally mentions the support address.
https://trac.torproject.org/projects/tor/wiki/doc/TorBrowserBundle3FAQ is a good start. Do we want to link to that wiki page, or should we create a more permanent, static page on the website.
Trac:
Keywords: N/A deleted, tbb-usability added
Cc: N/A to mcs, brade
Priority: normal to majorReplying to mikeperry:
https://trac.torproject.org/projects/tor/wiki/doc/TorBrowserBundle3FAQ is a good start. Do we want to link to that wiki page, or should we create a more permanent, static page on the website.
I asked arma about maybe splitting https://www.torproject.org/docs/faq.html.en into a Tor FAQ and a Tor Browser FAQ. He had reservations but was not entirely opposed either. I've put this idea into a new ticket: https://trac.torproject.org/projects/tor/ticket/10545
On second thoughts, can we point users to a web page? What if they are unable to reach the Tor network and the Tor website is censored?
Another option would be to change the Request Tracker configuration like the following: when a new ticket is created, an email with the known issues and some FAQ is automatically replied. Along with “if your question is still not answered, please reply describing your problem”. The ticket is automatically closed after this initial reply. It will be re-opened if users later reply.
We could have a script fetching some content on the website on a daily basis to update the content of the automatic reply. So the previous question about maintaining a known issues list still hold.
Yes, please! This way we can actually help more users in less time. Plus, from personal experience, many users are afraid to send an email to help desk as they're not sure if their email is secure enough to ask such questions.
Replying to mttp:
Replying to mikeperry:
https://trac.torproject.org/projects/tor/wiki/doc/TorBrowserBundle3FAQ is a good start. Do we want to link to that wiki page, or should we create a more permanent, static page on the website.
I asked arma about maybe splitting https://www.torproject.org/docs/faq.html.en into a Tor FAQ and a Tor Browser FAQ. He had reservations but was not entirely opposed either. I've put this idea into a new ticket: https://trac.torproject.org/projects/tor/ticket/10545
How about making an static page with a tiny search? and then we don't need to be worry about the number of Q&As we post. I think it'd be much less confusing if we keep all of the FAQs at one places.
Then under each Q&A we probably should add a button like "If you couldn't find your answer here and need to contact a human, send an email to help@rt.tpo"
So far I like the twitter model: https://support.twitter.com/
-
Replying to mrphs:
Yes, please! This way we can actually help more users in less time. Plus, from personal experience, many users are afraid to send an email to help desk as they're not sure if their email is secure enough to ask such questions.
Ok, but what happen when they can reach neither the Tor network nor the Tor website?
Replying to lunar:
Ok, but what happen when they can reach neither the Tor network nor the Tor website?
Fine question. I'd say mirrors, but it'd raise another question, "how would an average user find one?"
Adding "how to find a mirror" to short-user-manual could be a solution. considering we're going to re-write tsum and ship it with gettor.
so in theory, if you're an average censored user, the easiest way to get the bundles would be gettor. and once you send your request, you get all necessary information to troubleshoot, bypass the censorship and get connected.
-
Replying to mrphs:
Replying to lunar:
Ok, but what happen when they can reach neither the Tor network nor the Tor website?
Fine question. I'd say mirrors, but it'd raise another question, "how would an average user find one?"
Adding "how to find a mirror" to short-user-manual could be a solution.
Aren't mirrors listed in there likely to be censored as well? Or what would you suggest in such a document?
so in theory, if you're an average censored user, the easiest way to get the bundles would be gettor. and once you send your request, you get all necessary information to troubleshoot, bypass the censorship and get connected.
Should I use GetTor again if the ISP suddently blocks access to the Tor network and I'm unable to connect?
why don't we ship tsum in TBB zip-file/tar-ball?
That's #4983 (closed). Please try to keep the discussion focused.
Similarly to what Lunar addressed in comment 6:
Why not to delete Help Desk address:
On the first side, I think on a moment about users from places where t.p.o is blocked. These users may have downloaded from one of our many mirrors, but if they have not managed to have TBB working and their help page is in t.p.o then they will never reach any help. Not the FAQ page (they can not connect it from place, nor from Tor) nor the Help Desk (they never saw our e-mail address).
On the second side, it is more honest to users (in my HPOV) if we make something along the lines of putting up the FAQ, maintaining it properly, and advertising both the FAQ and the e-mail address in TBB. Make the FAQ URL appear higher and bigger that the email addresses (we need all the addresses per language, or at least the help address belonging to the language the user downloaded, and not only the english-general queue).
Trac:
Username: Envite-
We had a quite long IRC discussion with Mike, Georg, Roger, Colin and Sherief about how could a “known issues” list be maintained.
The TBB team can maintain a list of known issues. It would probably have around 5 entries today. The TBB team needs feedback from the support team on which issues support sees most or feel the most visible.
The support team will use IRC or Trac (preferred) to notify the TBB team of issues that should appear on the list of known issues. A tool will automatically notify the support team when the list of “known issues” is modified.
Unsolved question: where should the list be?
Trac:
Cc: mcs, brade to mcs, brade, admin@insecure-complexity.com
Replying to lunar:
Unsolved question: where should the list be?
Ideally at a place where users opening tickets at the help desk would see it. Not sure if such a place exists. I am happy to start with adding it to the release notes, like Mozilla does.
-
Replying to gk:
Replying to lunar:
Unsolved question: where should the list be?
Ideally at a place where users opening tickets at the help desk would see it. Not sure if such a place exists. I am happy to start with adding it to the release notes, like Mozilla does.
Users open ticket at the help desk by sending an email. So there's no such place. In my world, it needs to be as close as possible to the “download” button. I know this is tightly related to the website redesign. Maybe we should simply start with a wiki page for the present time?
-
The solution unraveled while discussing plans at the 2014 winter dev. meeting: we are going to put a section on how to get help in the Tor Browser User Manual (#10981 (closed)). The latter will be shipped with the Tor Browser and so we can point users at that section instead of having the email address directly available. The known issues will also be available in the manual and its latest incarnation on the Tor Project's website.
Trac:
Parent: N/A to #10974 (moved)
Keywords: N/A deleted, SponsorO added 
I am raising some more awareness of this ticket by adding a few more people to the Cc.
help@rt.torproject.orgis still displayed prominently within Tor Launcher's setup wizard and in the "Network Settings" window. Is there any change the Tor Browser team should make in the short run to help our users and our support people? Should we remove that email address for now?Trac:
Cc: mcs, brade, admin@insecure-complexity.com to mcs, brade, admin@insecure-complexity.com, isabela, alison, phoul, gkReplying to mcs:
I am raising some more awareness of this ticket by adding a few more people to the Cc.
help@rt.torproject.orgis still displayed prominently within Tor Launcher's setup wizard and in the "Network Settings" window. Is there any change the Tor Browser team should make in the short run to help our users and our support people? Should we remove that email address for now? Removing the email address from Tor Launcher would be good for the time being. The help-desk currently responds with an auto-responder pointing people at https://www.torproject.org/about/contact.html.en#supportThanks!
-
Replying to phoul:
Replying to mcs:
I am raising some more awareness of this ticket by adding a few more people to the Cc.
help@rt.torproject.orgis still displayed prominently within Tor Launcher's setup wizard and in the "Network Settings" window. Is there any change the Tor Browser team should make in the short run to help our users and our support people? Should we remove that email address for now? Removing the email address from Tor Launcher would be good for the time being. The help-desk currently responds with an auto-responder pointing people at https://www.torproject.org/about/contact.html.en#supportThanks!
Sounds like a good idea to me. mcs/brade do you think we could get the Tor Launcher issue fixed in the next release for stable and alpha?
-
Please review this patch: https://gitweb.torproject.org/user/brade/tor-launcher.git/commit/?h=bug10534-01&id=b635e8ddfb1626bf4db8d70d2c6513fde892be36
We added a website address (presented as torproject.org/about/contact.html#support) but other people may think that is a bad idea. I will also attach a screenshot to show what it looks like in the network settings wizard.
Trac:
Keywords: N/A deleted, TorBrowserTeam201604R added
Status: needs_information to needs_review -
Okay, this is merged to master (3635ee8a79bc1ef6457250082d3937d7f1633911), maint-0.2.7 (7c51ef35a36ede48dd00d2269d5a953ab150b217) and maint-0.2.9 (8d94cc4e5de9bdce74fce3a7d5e1a438b435b7d2). I think we should close this one for now and open new tickets once we know for sure how our new user support will work (and once all is set up properly).
However, we need to wait before we can start a build because we need new strings to appear. Phoul: how long does that usually take until at least the en ones are available for all locales we ship? Can one speed up that process?
Trac:
Resolution: N/A to fixed
Status: needs_review to closed -
Replying to phoul:
Strings should be picked up by Transifex every few hours. The changed en values should be present in the strings until they are properly translated at that time.
But that is not happening right now. Take 3635ee8a79bc1ef6457250082d3937d7f1633911 in tor-launcher as an example. It has a modified
torsettings.bridgeHelp1Band a newtorlauncher.forAssistance2. This commit is on master, yet updating the translations neither have the former nor the latter. This means, too, that the former is overwritten in en again. After doing some looking, it appears that the commit an hour after 3635ee8a79bc1ef6457250082d3937d7f1633911 (fffc7ee3e157198664cd5b1140773ad069dd3c5b) was done before Transifex had a chance to pick up the changes.
Currently, Transifex relies on https://gitweb.torproject.org/tor-launcher.git/plain/src/chrome/locale/en/network-settings.dtd to contain the correct source strings, and will pull whatever is at this location every hour or two. In this case, updating the strings at that location and waiting a couple hours before pulling new translations into the repo should resolve the issue.
If the source strings also exist somewhere outside of https://gitweb.torproject.org/tor-launcher.git/plain/src/chrome/locale/en/network-settings.dtd, we can also point Transifex to that different location so there isn't a race between Transifex and updated translations being pushed to the repo.
-
Replying to phoul:
If the source strings also exist somewhere outside of https://gitweb.torproject.org/tor-launcher.git/plain/src/chrome/locale/en/network-settings.dtd, we can also point Transifex to that different location so there isn't a race between Transifex and updated translations being pushed to the repo.
I don't fully understand what happened. Can you explain how a race can occur? Does the tor-launcher.git --> Transifex --> translation.git process look at timestamps to decide whether changes need to be transferred back to the translation repository? Or to decide whether to pull changes out of the tor-launcher repo?
Using network-settings.dtd as an example:
Every hour or two, Transifex will check https://gitweb.torproject.org/tor-launcher.git/plain/src/chrome/locale/en/network-settings.dtd to see if its strings match what Transifex currently has. If it does not, it will pull in the changes make them available as the source strings for that resource.
This automatic updating is not git-aware, and I do not believe does any checking of time stamps either. It will simply look at https://gitweb.torproject.org/tor-launcher.git/plain/src/chrome/locale/en/network-settings.dtd, and pull in changes if they do not match what Transifex currently has.
After the new strings make it into Transifex, it will take about 15 minutes for the system on our side to pull the new translations into their respective branches in translation.git.
The race in this case occurred when https://gitweb.torproject.org/tor-launcher.git/plain/src/chrome/locale/en/network-settings.dtd got replaced by what was in translation.git prematurely, as Transifex had not pulled in the updated version of network-settings.dtd from your repo yet, which meant the strings in translation.git were still the versions pre-update.
By the time Transifex ran this check, it had already been replaced with the version from translation.git, which indicated to Transifex that nothing had changed.
Glad to see this got addressed in tor-launcher.
Was there a corresponding ticket for the torbutton string, or is that still an issue (meaning we should open a new ticket)?
src/chrome/locale/en/aboutTor.ddt in torbutton's master branch still says
<!ENTITY aboutTor.failure.label "Something Went Wrong!"> <!ENTITY aboutTor.failure2.label "Tor is not working in this browser."> <!ENTITY aboutTor.failure3prefix.label "For assistance, please contact "> <!ENTITY aboutTor.failure3Link "help@rt.torproject.org"> <!ENTITY aboutTor.failure3suffix.label ".">-
Yes, #20318 (moved) which I just submitted a patch for review for.
mentioned in issue #18939 (moved)
mentioned in issue #18954 (moved)
mentioned in issue tpo/applications/tor-browser#18939 (closed)
