Daily release/feb 13 2024 9 40

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

@@ -1,14 +1,19 @@
 ---
-title: "What is a hero?"
+title: "What is a hero? What is a sidekick?"
 template: basicDoc
 topics:
   - Docs agile handbook
-freshnessValidatedDate: never
+freshnessValidatedDate: 2024-02-06
 ---
 
 "Hero" is a common term across New Relic for a dedicated, interruptible person who acts as an interface for a team. When you're a docs hero, you're the face of the team.
 
-We have two heroes at any given time: the GitHub hero (for issues and pull requests) and the Slack hero (for questions through Slack). We also have a second-shift hero to support EMEA Relics. Every hero's job is to keep things moving for Relics and users. We change GitHub and  heroes once a day (we used to do weekly shifts, but we've found daily shifts reduce hero burnout).
+We have two rotating roles at any given time: 
+
+* The Hero handles Slack questions, reviews pull requests, and triages GitHub issues
+* The CSAT Sidekick handles customer feedback coming in through Jira. 
+
+Both roles are here to keep docs requests moving for Relics and users, and to give the team a buffer from interruptions. We change hero and a sidekick once a week (we used to do daily shifts, but we've found the daily cadence to be too disruptive and lead to work that bleeds over to the next day).
 
 ## Goals for heroing [#heroing-goals]
 
@@ -30,7 +35,7 @@ As the hero, you're often pulled in a lot of directions in a given shift. Becaus
 
 You're also not expected to know everything as a hero! If something comes up for which you have no easy answer, let the requestor know you're on it and then ping your fellow writers or other SMEs and helpers from across New Relic for help.
 
-## GitHub hero responsibilities [#gh_hero_responsibilities]
+## Hero GitHub responsibilities [#gh_hero_responsibilities]
 
 The GitHub hero monitors the GitHub board and the flow of work through GitHub.
 
@@ -62,9 +67,9 @@ To merge, just [click this magic link](https://github.com/newrelic/docs-website/
 
 During super busy shifts, you likely won't have time for many of these, but if you're having a slow shift please take some time to periodically check the **Writer Needs Peer Edit** swim lane for fresh peer edit asks from your teammates before you switch over to doing sprint work.
 
-## Slack hero responsibilities
+## Hero Slack responsibilities [#slack_hero_responsibilities]
 
-The Slack hero monitors Slack and helps answer questions about docs and route people to the right resource on the team.
+We use Slack to help answer questions about docs and route people to the right resource on the team.
 
 ### Update the Slack alias
 
@@ -81,39 +86,103 @@ Common questions and requests include:
 * **Questions about status of a pull request or issue**. Check in and see if you can figure out, or pull in the assignee for that pull request if the status isn't clear.
 * **Questions about things we don't own (blog, API Explorer, newrelic.com, etc)**. Help them out by directing them to the appropriate Slack channel. (For a list of properties and their owner, see _Who owns the other wesbites?_ in Google Docs.) If you can't figure out who owns it, try asking the writing team in Slack.
 
-## Second-shift hero support
+## Second-shift hero support [#emea_support]
 
 Our Europe writers cover the 2nd shift heroing during their regular working hours. Unlike the US-based heroes, our Barcelona writers hero for an entire two-week sprint. Second-shift heroes cover both GitHub and Slack, but we don't expect that second-shift heroes will field every single request that comes in during their working hours since they're also carrying standard sprint duties during their hero shift.
 
-## Route and triage user feedback
-
-The hero is responsible for routing user feedback to liasions. This sections covers the entire lifecycle of a user feedback ticket:
-
-1. The hero is responsible for routing incoming tickets to the proper liaison each day
-    - The Hero leaves a comment saying the ticket is being triaged
-2. Each writer should spend 10-15 minutes/day triaging their assigned tickets 
-    - Writer either rewrites or closes the ticket
-      - If the writer closes the ticket, they must leave a comment explaining why.
-    - Writer needs to add: 
-      - Acceptance criteria
-      - User story
-      - Action items
-      - Resources 
-    - While rewriting, focus on making the ticket as swarmable as possible
-    - Assign a priority [See priority info in our team's `DOC Jira and Github fields - Project 401 - 2022` doc]
-    - Add the following label: `doc_groomed`
-3. Triaged tickets enter sprints in one of two ways:
-    - **Scrum leaders**: Bring in tickets based on marked priority
-    - **Liaisons**: Bring in high value issues
-    - **Squads**: During backlog grooming the team can chat about bringing in tickets to fill out a sprint
-
 <Callout variant="important">
 For writers in Europe:
 
 - Route incoming issues to the liaison as you have time. As writers in Europe are "eternal heroes" it isn’t fair to have you do this every day.
 - You should still triage issues routed to you from your liaisonships once per day.
  </Callout>
 
+## 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. 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.
+
+There are three options for these tickets:
+
+1. Close it.
+2. Fix it.
+3. Backlog it.
+
+<Callout variant="important">
+Unlike the hero, we don't take any points out of our sprint for the sidekick work. If you're spending more than 60 minutes per day on customer feedback tickets, that's too much time! Please let your manager know.
+ </Callout>
+
+### 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 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 act on specifically:
+
+`These docs are bad.`
+
+or 
+
+`Help!`
+
+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:
+
+1. Add a category label based on the URL, such as `doc_apm` or `doc_errors-inbox`.
+2. Set the Workflow status to **Closed** 
+3. Set the Resolution to **Cannot Reproduce**, **Filed by Mistake**, or **Won't Do** depending on what feels most appropriate.
+4. Add a brief note about why you closed it. Usually, "Not actionable" is plenty.
+
+### 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. 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` (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 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.
+
+If you're not sure whether a ticket belongs in our backlog, ask your manager or put it into the On Deck sprint to ensure it doesn't fall through the cracks.
+
+Use this process to put a ticket in the backlog:
+
+1. Write a user story.
+2. Write acceptance criteria.
+3. Write loose action items.
+4. Add any other detail about what you've learned.
+5. **Move** the ticket from the Customer Feedback to Story ticket type.
+6. Add the ticket to our Docs On Deck sprint.
+
+### Customer email
+
+There's no expectation that you email customers back regarding their feedback. However, when you respond to customers in a timely way, you can:
+
+* Build goodwill 
+* Learn more about what works and doesn't work in our docs
+* Clarify what's going on with the feedback
+* Give more useful product feedback to our PMs
+
+When you write an email to a customer, don't send them a boilerplate message. Be sure to write a genuine, thoughtful response to their feedback that either answers their question or asks meaningful questions. You may not get a response and that's OK. In most cases, people are delighted to hear back from a real human being and there's a good chance that you'll learn a little something about our docs and our platform, too!
+
+### Customer feedback in aggregate
+
+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 for specific docs categories a part of your editing process. 
+
 <ButtonGroup>
   <ButtonLink
     role="button"

src/content/docs/serverless-function-monitoring/aws-lambda-monitoring/get-started/compatibility-requirements-aws-lambda-monitoring.mdx

@@ -34,6 +34,7 @@ older than 3.9.0.
 
 To minimize performance impact, we've taken a different approach with Java and .NET Core. New Relic provides
 [OpenTracing](https://opentracing.io/) SDKs for these runtimes. This approach requires a bit more code to integrate.
+For newer runtimes, such as .NET 6, [Trace your .NET Lambda functions with New Relic and OpenTelemetry](/docs/serverless-function-monitoring/aws-lambda-monitoring/opentelemetry/lambda-opentelemetry-dotnet/) is available.
 
 For complete Lambda instrumentation, some of our agents included in our Lambda layers depend on a language-specific [AWS SDK](https://aws.amazon.com/tools/#sdk). If an AWS SDK is not used, Lambda data will appear as external service calls in the UI, with minimal detail. In other words, we rely on the AWS SDK to facilitate instrumentation of your function.