Updating the wording in qa-sign-off.mdx file

* Update qa-sign-off.mdx

Changing some of the wording and working in a link to QA's "How to file a QA ticket" document

* Update qa-sign-off.mdx

Added specificity of ticket type

* Added custom link for QA ticket creation

* updating the QA ticket link ...

... to point to a custom issue creation page in JIRA

docs/getting-started/for-product.md

@@ -15,7 +15,7 @@ Responsibilities include:
 - Align on the design of the experiment by attending a [desktop](https://www.google.com/url?q=https://docs.google.com/document/d/1dH-aG8IsYtq6881_Q_cyEtmxli0bK7nuVcUD-5D7q-s/edit%23&sa=D&source=calendar&ust=1646684514330583&usg=AOvVaw0O5Sbz3fHVx2rFDcl3DpNg) or [mobile](https://docs.google.com/document/d/1XJ3o5zjVETtZi7u1r3XvsJHmrmxxpmuFs42PDzWVhXw/edit#heading=h.sh37wxowgx5) office hour and filing a [data org Jira ticket](https://mozilla-hub.atlassian.net/jira/software/c/projects/DO/boards/269).
 - Creating the [Data Org Jira ticket](https://mozilla-hub.atlassian.net/jira/software/c/projects/DO/boards/269) (linked in experiment brief)
 - Implementing the experiment in [Nimbus console AKA Experimenter](https://experimenter.services.mozilla.com)
-- Creating the [QA Jira ticket](https://mozilla-hub.atlassian.net/jira/software/c/projects/QA/boards/261) (linked in experiment brief)
+- Creating the [QA "Nimbus/Remote delivery" Jira ticket](https://mozilla-hub.atlassian.net/secure/CreateIssueDetails!init.jspa?pid=10212&issuetype=11290) (linked in experiment brief)
 - Launching the experiment, ending enrollment, ending experiment (the [experimentation workflow](/workflow/overview))
 - Working with the experiment team (in slack at #ask-experimenter) to identify a set of reviewers trained and authorized to review experiments in your feature area. The experiment team will train them on how to review.
 

docs/workflow/implementing/risk-mitigation/qa-sign-off/qa-sign-off.mdx

@@ -4,12 +4,11 @@ slug: /qa-sign-off
 sidebar_position: 1
 ---
 
-Feature testing alone is not enough for experiments or rollouts.  There is testing specific to see that the turning on and off of your feature works through Nimbus.  There is also testing if you are changing configurations (does it work in different locals? platforms?), if there is new advanced targeting that needs testing, and if there is new telemetry.  
+Feature testing alone is not enough for experiments or rollouts. A QA passthrough will also ensure that the feature is successfully turned on/off through Nimbus, that it works on all desired platforms and most important locales, that the targeting expression works as expected (only users that meet the criteria will be enrolled in the experiment/rollout), and that the telemetry that we’re basing the analysis on is successfully gathered while enrolled.
 
-Unless you are 100% certain you don’t need QA - [file a QA ticket here](https://mozilla-hub.atlassian.net/jira/software/c/projects/QA/boards/261?quickFilter=1447).  Issue type will be either Experiment or Rollout.   QA often finds critical edge cases that were missed.  
+Unless you are 100% certain you don’t need QA - [file a QA "Nimbus/Remote delivery" ticket here](https://mozilla-hub.atlassian.net/secure/CreateIssueDetails!init.jspa?pid=10212&issuetype=11290). You can use [this document](https://docs.google.com/document/d/1oz1YyaaBI-oHUDsktWA-dLtX7WzhYqs7C121yOPKo2w/edit#heading=h.s50iqavbblol) as a guide when filing the ticket to ensure that you pass all the relevant information that you can to QA. Going through QA is recommended, as they often find critical edge cases that were missed.
 
 The only possible exceptions where you may not need official QA are below; **if you choose to skip QA, you must self-test**, [learn more](https://experimenter.info/previewing-experiments).  Self-testing is recommended even before sending to QA, as it can avoid days of delay if QA discovers an easily corrected recipe error when they start testing.
 1.  You are launching on Nightly or early Beta and the feature itself was tested.  
 2.  You are repeating an experiment with minimal changes that don’t involve new code.  Ex: QA tested the original experiment - and now you are rolling out one of the winning configurations.  You launched the original but there was a small error in targeting (be sure to consider localization with every country/language change, if there is user facing copy in your experiment!)
-3.  You are doing a message experiment with no new code changes or new targeting, so only changing the copy / well tested fields.  Note: Skipping testing for this is when we see easy-to-make human errors lead to sending the wrong language places.  We also see more image resolution issues that you’d think (cropped, color issues, scaling issues).  Swapping images can cause unexpected display issues.
-
+3.  You are doing a simple message experiment/rollout (Infobar or Heartbeat) with no new code changes or new targeting, so only changing the copy / well tested fields. Note: Skipping testing for this is when we see easy-to-make human errors lead to sending the wrong language places. We also see more image resolution issues that you’d think (cropped, color issues, scaling issues).  Swapping images can cause unexpected display issues.