Merge pull request #2859 from newrelic/DOC-7014-style-guide-review

[DOC-7014] Style guide - Added Bradley's feedback.

src/content/docs/style-guide/writer-workflow/github-intro.mdx

@@ -7,7 +7,7 @@ topics:
 As tech doc writers (TW) we [edit docs](/docs/style-guide/writer-workflow/tech-writer-workflow/), do [peer edits](/docs/style-guide/writer-workflow/peer-editor-workflow/), or use the [Docs Team GitHub board](https://github.com/newrelic/docs-website) to track the status of issues and pull requests (PR).  
 
 ## Who is who in an issue/PR? [#who-is-who]
-GitHub keeps track of all activity concerning an issue or PR, including, of course, the people involved. When a new issue or PR is filed, check on the filer’s username and see if they're listed as a member of our organization. If you're not sure, treat someone as external until you know otherwise. 
+GitHub keeps track of all activity concerning an issue or PR, including, of course, the people involved. When a new issue or PR is filed, check on the filer’s username and see if they're listed as a member of the New Relic organization. If they aren't, try to find them on Slack based on their username. If you're not sure about someone's affiliation, treat them as external until you know otherwise. 
 
 People in an issue/PR include:
 
@@ -36,9 +36,9 @@ The docs board has the following columns:
         **Needs triage**
       </td>
       <td>
-        The Hero or Sidekick review issues and PRs in this column, then drag them to the appropriate column.
+        The Hero or Sidekick **review and [label](#labels)** issues and PRs in this column, then drag them to the appropriate column.
 
-        If the issue/PR is labeled `eng`, go ahead and click its ellipses icon to archive it. For other issues and PRs, add the [correct labels](#labels). 
+        If a PR or issue is labeled `eng`, the Hero/Sidekick can go ahead and click its ellipses icon to archive it. 
       </td>
     </tr>
     <tr>
@@ -144,15 +144,15 @@ Every issue needs these labels:
   - `from_internal`: A Relic created it.
   - `from_external`: A user opened it in the repo OR it came in through #customer-feedback process.
   - `from_tw`: One of us created it (unless we were passing along #customer-feedback).
-- `Optional`: Jira’d: Issues that have a corresponding Jira ticket. 
+- `Optional`: Jira’d: Issues that have a corresponding Jira ticket. Make sure you leave the Jira number in the comments of the issue (for example, DOC-1234).
 
 Every pull request needs these labels:
 - Always add `content`
 - Add one of:
   - `from_internal`: A Relic created it.
   - `from_external`: A user opened it in the repo OR it came in through #customer-feedback process.
   - `from_tw`: One of us created it (unless we were passing along #customer-feedback). If the PR fixes an external issue, label it as `from_tw` since the work was done by a tech writer.
-- Optional: `Jira’d`: Issues that have a corresponding Jira ticket. 
+- Optional: `Jira’d`: Issues that have a corresponding Jira ticket. Make sure you leave the Jira number in the comments of the PR (for example, DOC-1234).
 
 ## Check the edit history of a doc or file [#doc-history]
 There are two options two check the history of a file:

src/content/docs/style-guide/writer-workflow/github-troubleshooting.mdx

@@ -35,7 +35,7 @@ If you're running with issues with your local build, try these options:
     id="restart-yarn"
     title="Stop and restart yarn"
   >
-    1. In the terminal, ensure you're in the docs-website directory.
+    1. In the terminal, ensure you're in the `/docs-website` directory.
     2. Hit CONTROL+C to interrupt the yarn process, if necessary.
     3. Run `yarn && yarn start`.
   </Collapser>
@@ -48,7 +48,7 @@ If you're running with issues with your local build, try these options:
     1. In the terminal, ensure you're in the docs-website directory.
     2. Hit CONTROL+C to stop yarn, if necessary.
     3. In GitHub Desktop, commit any changes needed on your branch, and then switch to the Develop branch.
-    4 Back in the terminal, run `yarn && yarn start`.
+    4. Back in the terminal, run `yarn && yarn start`.
 
     If the site now builds correctly, the issue is with the changes in your branch. Stop Yarn again, go back to your branch, and troubleshoot.
   </Collapser>
@@ -71,7 +71,7 @@ If you're running with issues with your local build, try these options:
   >
   There may be times when your .cache directory has been corrupted. This directory is ignored by Git, which means that it travels with you from branch to branch. This might be the problem if your local builds are failing regardless of which branch you’re on.
 
-  To solve this, run `rm -rf .cache`.
+  To solve this from your `/docs-website` directory, run `rm -rf .cache`.
   </Collapser>
 
   <Collapser
@@ -83,7 +83,7 @@ If you're running with issues with your local build, try these options:
 
   1. In the terminal, ensure you're in the docs-website directory.
   2. Hit CONTROL+C to stop yarn, if necessary.
-  3. Blow away modules and cache and start from scratch running `rm -rf node_modules && rm -rf .cache && yarn && yarn clean`.
+  3. Blow away modules and cache and start from scratch by running the `kknuke` Keyboard Maestro command, or run `rm -rf node_modules && rm -rf .cache && yarn && yarn clean` in your terminal. 
   4. When everything completes, start the site `yarn start`.
 
   You may need to add sudo at the start of the rm commands.
@@ -101,6 +101,8 @@ If you're running with issues with your local build, try these options:
 ## My redirect throws a 404 error when testing it locally [#redirect-404]
 Redirects are a bit strange on local builds. To test them, navigate to the page that is being redirected, wait until it throws a 404, and then wait ~1-2 minutes. It should redirect you after a while. If it doesn’t, ensure you set up the redirect correctly. 
 
+You can also test the redirects out in the Gatsby build.
+
 ## A check fails in the PR [#check-fail]
 <Callout variant='important'>
 The only checks needed to merge a PR are the checks marked as `required` on the PR. These are `run linter`, `run tests`, `license/cla`, and `unpaired translations removed` for merges to develop, and `build the docs site` for merges to main. If a required check fails, the failure must be addressed in order for the PR to be merged. If an optional check fails, reach out in the help channel so that the hero can look into the failure, but feel free to merge the PR since optional checks don't block releases.
@@ -143,3 +145,6 @@ Merge conflicts pop up pretty often with what’s new posts because the `whats-n
 
 If you see changes to this file show up in GitHub Desktop, make sure to discard them, rather than push them up to your branch. This will make it less likely that other people will have to deal with merge conflicts related to this file.
 
+<Callout variant="caution">
+  Never merge a PR that changes `whats-new-ids.json`.
+</Callout>