style(Style guide): Responded to peer feedback

src/content/docs/agile-handbook/heroing/what-is-a-hero.mdx

@@ -99,11 +99,13 @@ For writers in Europe:
 
 ## Customer feedback sidekick [#cf_sidekick]
 
-Feedback is a gift. Every piece of meaningful feedback represents someone taking time out of their day to express something to us. It's important that we honor that gift. The sidekick role was created so that we have a role and a process for getting a human being to read through and think about and sometimes respond to every piece of feedback that people write to us. 
+Feedback is a gift. Every piece of meaningful feedback represents someone taking time out of their day to express something to us. It's important that we honor that gift. Our team created the sidekick role so that we regularly have a human being reading through and thinking about and responding to every piece of feedback that people write to us.
+
+As valuable as this feedback is, though, **our primary goal is to keep our Jira backlog down to a manageable and reasonable size**.
 
 Customer feedback from our docs site creates tickets in Jira. It's the sidekick's responsibility to look at every ticket that comes in (usually about 5–10 per day) and make decisions about each one.
 
-We have three options for these tickets:
+There are three options for these tickets:
 
 1. Close it.
 2. Fix it.
@@ -115,17 +117,17 @@ Unlike the hero, we don't take any points out of our sprint for the sidekick wor
 
 ### Close customer feedback
 
-Many pieces of customer feedback simply aren't actionable. That's ok! Even if we can't act on a specific piece of feedback, we can use this feedback in aggregate to get an overall sense of how our docs site or a specific category of our docs site is landing with our readers.
+Many pieces of customer feedback simply aren't actionable. That's ok! Even if we can't act on a specific piece of feedback, we can use this collective feedback to get an overall sense of how our docs site or a specific category of our docs site is landing with our readers.
 
-Here are some fictional examples of feedback we might not be able to take action on specifically:
+Here are some fictional examples of feedback we might not be able to act on specifically:
 
 `These docs are bad.`
 
 or 
 
 `Help!`
 
-There's also feedback that falls into the category of nonsense or mistakes.
+There's also feedback that falls into the category of nonsense or mistakes. You'll know it when you see it. Comments like this can be closed immediately.
 
 Follow this process to close tickets that aren't actionable or don't make sense:
 
@@ -136,20 +138,20 @@ Follow this process to close tickets that aren't actionable or don't make sense:
 
 ### Fix customer feedback
 
-Sometimes, though rarely, a customer feedback ticket comes in that's highly actionable and is a quick fix, such as a broken link or an outdated image. 
+Sometimes, though rarely, a customer feedback ticket comes in that's highly actionable and is a quick fix, such as a broken link or an outdated image. If you need to reach out to a subject matter expert, the ticket is **probably not** a quick fix.
 
 Follow this process to close these:
 
 1. Create a PR to address the issue.
-1. Add a category label based on the URL, such as `doc_apm` or `doc_errors-inbox`.
+1. Add a category label based on the URL, such as `doc_apm` or `doc_errors-inbox` (These labels are based off of the first part of the URL after `/docs/. For example, `https://docs.newrelic.com/docs/errors-inbox` would have the label `docs_errors-inbox`.).
 1. Add a link to the PR.
 1. Work the PR to its merge at your leisure.
 1. Set the Jira ticket Workflow status to **Closed** 
 1. Set the Jira ticket Resolution to **Done**.
 
 ### Backlog customer feedback
 
-Too many ticket backlogs have a larger quantity of tickets than can ever be meaningfully addressed. Our goal is to get our customer feedback backlog down to a small enough number that we can meaningfully and reasonably address them in a few sprints based on our current headcount and capacity. Because of this, we need to set a pretty high bar for adding a ticket to our backlog.
+Too many ticket backlogs have a larger quantity of tickets than can ever be addressed. Our team's goal is to get our customer feedback backlog down to a small enough number that we can meaningfully and reasonably address them in a few sprints based on our current headcount and capacity. Because of this, we need to set a pretty high bar for adding a ticket to our backlog.
 
 Sometimes a piece of customer feedback is quite valid, but the scope of the work required to address it isn't something our team can't commit to right now. Sometimes a comment requires technological knowledge that we don't have. Sometimes a doc simply doesn't get enough traffic to warrant fixing a problem right away.
 
@@ -179,7 +181,7 @@ When you write an email to a customer, don't send them a boilerplate message. Be
 
 Even if a single piece of customer feedback is closed and we haven't acted on it, that doesn't mean it stop being useful. When you begin to consider improving a doc or a category of docs on our site, use Jira filters to find customer feedback related to those. For example, if 20 people are expressing confusion at the doc you're looking at, you should consider how to make it less so. 
 
-Make reviewing customer feedback in aggregate for specific docs a part of your editing process. 
+Make reviewing customer feedback for specific docs categories a part of your editing process. 
 
 <ButtonGroup>
   <ButtonLink