Opened 6 years ago

Closed 3 years ago

Last modified 3 years ago

#10534 closed defect (fixed)

Let's not advertise help desk emails directly

Reported by: lunar Owned by: mikeperry
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-usability, tbb-easy, SponsorO, TorBrowserTeam201604R
Cc: mcs, brade, admin@…, isabela, alison, phoul, gk Actual Points:
Parent ID: #10974 Points:
Reviewer: Sponsor:

Description

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.

Child Tickets

Attachments (1)

wizard.png (134.9 KB) - added by mcs 3 years ago.
Mac OS X wizard screenshot

Download all attachments as: .zip

Change History (33)

comment:1 Changed 6 years ago by mttp

Seconded. https://trac.torproject.org/projects/tor/ticket/5811 seems like a reasonable solution to me.

comment:2 Changed 6 years ago by mikeperry

Cc: mcs brade added
Keywords: tbb-usability added
Priority: normalmajor

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.

comment:3 in reply to:  2 ; Changed 6 years ago by 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

comment:4 Changed 6 years ago by lunar

Mike, could you state your feelings about maintaining a known issues list on such a landing page?

For example, having to answer over and over again abut the ibus issue feels quite ridiculous. It would be a good if updating such a list becomes part of TBB Q&A and release processes.

comment:5 Changed 5 years ago by mikeperry

Keywords: tbb-easy added

comment:6 Changed 5 years ago by lunar

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.

comment:7 in reply to:  3 ; Changed 5 years ago by 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.

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@…"

So far I like the twitter model: https://support.twitter.com/

comment:8 in reply to:  7 ; Changed 5 years ago by lunar

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?

comment:9 in reply to:  8 ; Changed 5 years ago by 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. 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.

comment:10 Changed 5 years ago by mrphs

why don't we ship tsum in TBB zip-file/tar-ball?

comment:11 in reply to:  9 Changed 5 years ago by lunar

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. Please try to keep the discussion focused.

comment:12 Changed 5 years ago by Envite

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).

Last edited 5 years ago by Envite (previous) (diff)

comment:13 Changed 5 years ago by lunar

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?

comment:14 Changed 5 years ago by phoul

Cc: admin@… added

comment:15 in reply to:  13 ; Changed 5 years ago by 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.

comment:16 in reply to:  15 Changed 5 years ago by lunar

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?

comment:17 Changed 5 years ago by lunar

Keywords: SponsorO added
Parent ID: #10974

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). 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.

comment:18 Changed 5 years ago by lunar

Status: newneeds_information

comment:19 Changed 3 years ago by ikurua22

Severity: Normal

tor.stackexchange.com

comment:20 Changed 3 years ago by mcs

Cc: isabela alison phoul gk added

I am raising some more awareness of this ticket by adding a few more people to the Cc.

help@rt.torproject.org is 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?

comment:21 Changed 3 years ago by bugzilla

Component: TorBrowserButtonTor Browser

Ticket is so tbb-easy that it cannot be fixed for 2 years...

comment:22 in reply to:  20 ; Changed 3 years ago by 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.org is 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#support

Thanks!

comment:23 in reply to:  22 Changed 3 years ago by gk

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.org is 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#support

Thanks!

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?

comment:24 Changed 3 years ago by mcs

Keywords: TorBrowserTeam201604R added
Status: needs_informationneeds_review

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.

Changed 3 years ago by mcs

Attachment: wizard.png added

Mac OS X wizard screenshot

comment:25 Changed 3 years ago by gk

Resolution: fixed
Status: needs_reviewclosed

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?

Last edited 3 years ago by gk (previous) (diff)

comment:26 Changed 3 years ago by 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.

comment:27 in reply to:  26 Changed 3 years ago by gk

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.bridgeHelp1B and a new torlauncher.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.

comment:28 Changed 3 years ago by phoul

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.

comment:29 in reply to:  28 Changed 3 years ago by mcs

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?

comment:30 Changed 3 years ago by phoul

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.

comment:31 Changed 3 years ago by arma

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 ".">

comment:32 Changed 3 years ago by gk

Yes, #20318 which I just submitted a patch for review for.

Note: See TracTickets for help on using tickets.