feat(agile handbook): Build out doc on hero responsibilities

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

@@ -0,0 +1,89 @@
+---
+title: "What is a hero?"
+template: basicDoc
+topics:
+  - Docs agile handbook
+---
+
+"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 who provides overnight support for 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).
+
+## Goals for heroing [#heroing-goals]
+
+A Relic once described the New Relic culture this way: 
+
+> In the end, everyone here is working toward the same purpose [...] That person pinging you with some random request that seems unrelated to your world has the same goals as you. Help them, be kind, be patient.
+
+Your mission as hero is to personify that attitude in Docs-land. Here's what that looks like in practice:
+
+- **Create a consistent interface for the team.** Our GitHub hero and #documentation hero workflows help us make sure that connections to our team stay strong by providing stable, consistent points of contact. The heroes ensure that someone will always be available to answer pressing questions or needs relating to docs without long wait times, even if the designated liaison is out or a liaisonship has ended, or when new and unexpected needs arise.
+- **Provide a great (internal and external) customer experience.** The heroes respond quickly to questions, give timely draft reviews, and perform great customer service and problem solving. The hero roles provide continuity, regardless of who's filling the roles on a given day. The heroes will keep tabs on the #documentation Slack channel and our GitHub issues backlog.
+- **Share knowledge about the site and our products.** The heroes end up touching all kinds of obscure areas of our site and interacting with teams they may never have worked with directly. It's a great opportunity to learn more about New Relic and to build relationships across the org.
+- **Edit new content to our standards.** We depend on self-service to cover lots of products with relatively few writers. With the launch of the new Docs site, New Relic customers will now be able to submit proposed edits directly via GitHub. The GitHub hero gives us a single accountable person who can review new content against Docs team standards and turn it around quickly.
+- **Buffer the team from interrupts.** Since the heroes are our "designated interruptibles" for their shifts, the rest of the team is freed up for deeper focus time. When it is appropriate to bring in another team member, heroes can help in streamlining the handoff and providing helpful context so that their teammate can get started quickly with the lowest possible context-switching burden. 
+
+## Heroing is a full-time job [#heroing-full-time-job]
+
+As the hero, you're often pulled in a lot of directions in a given shift. Because of this, the expectation is that you do not take on sprint work during your hero shift, unless you really have nothing else to do after completing your hero duties.
+
+Similarly, you are 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]
+
+The GitHub hero monitors the GitHub board and the flow of work through GitHub.
+
+### Triage issues and PRs
+
+The GitHub hero triages every incoming pull request and issue. You'll tag the issue and pull request, route it to the correct column or team, and also help review incoming edits. For details on handling all of this, see [Managing the GitHub boards](3379_INSERT_LINK_HERE).
+
+### Review PRs
+
+The bulk of your time is generally spent reviewing and approving PRs from non-writers. To review an incoming PR:
+
+1. Label the pull request appropriately (see [Managing the GitHub boards](3379_INSERT_LINK_HERE) for details).
+2. Assign yourself to the pull request, so it's clear that you're on point to review and merge.
+3. Review the pull request, depending on what type of edit it is:
+    - **If it's a simple "cosmetic" edit**, review the pull request to ensure it's formatted correctly, technically accurate, and fits New Relic style guidelines.
+    - **If it's a deeper edit, or a completely new doc**, give it an in-depth review. The [Docs site edit checklist](/docs/style-guide/processes-procedures/docs-site-edit-checklist/) is a great resource here. If it's a really complex or large edit, consider creating a Jira ticket for an upcoming sprint to give it the review time it needs.
+    - **If it's a What's new post**, pay special attention to frontmatter, links, and image formatting. This content follows marketing style, so it doesn't need to fully match our style guidelines for things like capitalization.
+    - **If it's a release note**, focus your review on formatting and basic style, and ensuring the release note itself is helpful. Release notes don't need to follow all docs style guidelines religiously.
+4. Preview your change in Gatsby Cloud or locally.
+5. Merge the pull request into **develop**.
+
+### Merge develop into main
+
+We merge the develop branch into the main branch a few times a day. This kicks off a build, and ultimately is how draft docs become published docs. Currently we do this three times a day: Around 9 am PST, noon PST, and 3 pm PST. 
+
+To merge, just [click this magic link](https://github.com/newrelic/docs-website/compare/main...develop) and follow the prompts.
+
+### Provide peer reviews if time allows
+
+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.
+
+## #documentation hero responsibilities
+
+The #documentation hero monitors Slack and helps answer questions about docs and route people to the right resource on the team.
+
+### Update the Slack alias
+
+Update the alias to ping your name at the start of your hero shift.
+
+To update the alias, type the following into the chat box: `!hero set @YOUR_SLACK_HANDLE`. For example, if it's Austin's hero shift, the thing to type would be `!hero set @austin`.
+
+### Field questions in the #documentation channel
+
+Common questions and requests include:
+
+- **Questions about docs content**. Answer the question if you know it, or reach out to other writers if it's an area you're not familiar with. Encourage the requestor to edit the docs or submit an issue wherever possible.
+- **Triage requests for docs support**. If it's a project that already has a [liaison](3379_INSERT_LINK_HERE) attached, connect the requestor to the appropriate writer. If it's a project without exisitng writing support, connect them to a docs team manager to have a scoping conversation.
+- **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 reuqest 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 the [Miscellaneous site owners](3379_INSERT_LINK_HERE).) If you can't figure out who owns it, try asking the writing team in Slack.
+
+## Second-shift hero support
+
+Our tech writers in Barcelona 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.
+
+## For more help
+
+We welcome thoughts or questions on our handbook! The easiest way to get in touch is to [file a GitHub issue](https://github.com/newrelic/docs-website/issues/new/choose).

src/nav/docs-agile-handbook.yml

@@ -29,7 +29,8 @@ pages:
         path: /docs/agile-handbook/sprint-mechanics/liaisonships
   - title: "Heroing"
     path: /docs/agile-handbook/heroing
-      - title: "What's a hero?"
-        path: /docs/agile-handbook/heroing/whats-a-hero
+    pages:
+      - title: "What is a hero?"
+        path: /docs/agile-handbook/heroing/what-is-a-hero
       - title: "Managing the GitHub boards"
         path: /docs/agile-handbook/heroing/managing-the-github-boards