feat(agile handbook): Add doc on managing GitHub boards and board col…

…umns

src/content/docs/agile-handbook/heroing/managing-the-github-boards.mdx

@@ -3,4 +3,112 @@ title: "Managing the GitHub boards"
 template: basicDoc
 topics:
   - Docs agile handbook
----
+---
+
+The [Docs pull requests and Issues](https://github.com/newrelic/docs-website/projects/3) board is our source of truth for what's going on in our project. The board is divided into a series of columns so we can see visually what the status of each issue and pull request is.
+
+## A note on Assignee vs Reviewer [#assignee_reviewer]
+
+Assignee and Reviewer have different meanings:
+
+- **Assignee** means you "own" the pull request or issue and are getting it into a merge-ready state. If you are no longer owning a given pull request or issue, take your name off as assignee.
+- **Reviewer** means you are actively reviewing a pull request. If it's a pull request from outside the docs team, the reviewer is also responsible for merging the pull request into `develop`. If you're reviewing a pull request from a fellow docs writer, add your comments and mark the pull request as **Approved**, then move it to **Waiting on TW to merge**.
+
+## Drafts [#column_drafts]
+
+These issues and pull requests are in a draft state. Do not merge until their owner moves them out of the lane. This lane should _only_ be for draft pull requests. Do not "hold" pull requests or issues here.
+
+The Hero should look at this lane multiple times per day in case a pull request has been marked ready for review. Move any ready-for-review pull requests into the correct lane.
+
+## Hero to triage [#column_hero-to-triage]
+
+New issues and pull requests flow into this column automatically. As hero, you need to triage each one:
+
+1. Determine if the pull request or issue is content-related. If it's an eng issue or pull request, you can just **Archive** it to remove it from the board.
+2. Assign mandatory labels:
+  <table>
+    <thead>
+      <tr>
+        <th style={{ width: "135px" }}>
+          Label type
+        </th>
+        <th style={{ width: "135px" }}>
+          Required on
+        </th>
+        <th>
+          Description
+        </th>
+      </tr>
+    </thead>
+    <tbody>
+      <tr>
+        <td>
+          `content`
+        </td>
+        <td>
+          Issues and pull requests
+        </td>
+        <td>
+          Use this label to indicate an issue or pull request relates to content (versus the code of the site).
+        </td>
+      </tr>
+      <tr>
+        <td>
+          `from_`
+        </td>
+        <td>
+          Issues and pull requests
+        </td>
+        <td>
+          Use this label to indicate who created the issue or pull request. Use `from_tw` when it's created by a docs writer, `from_internal` when it's created by a Relic, and `from_external` when  it's from outside the company.
+        </td>
+      </tr>
+      <tr>
+        <td>
+          `pg_`
+        </td>
+        <td>
+          Issues
+        </td>
+        <td>
+          Indicates which New Relic product group is associated with this issue. 
+        </td>
+      </tr>
+    </tbody>
+  </table>
+3. Give the ticket an assignee (most likely the Hero themselves).
+4. Move the ticket to the appropriate column.
+
+## Hero: To do [#column_hero-to-do]
+
+On the basis of the triage work, the GH Hero has determined that this is appropriate in scope and range to be dealt with while Heroing, but hasn't started work yet.
+
+Tickets in this column need to have an assignee.
+
+## In progress/being reviewed [#column_in-progress]
+
+Work is underway on this issue or pull request. This includes but is not limited to reviewing incoming pull requests from outside the team, performing a peer review/peer edit, or doing a simple pull request review for another tech writer. The person doing the work should make themselves the assignee as soon as they move the pull request or issue into this column to prevent others from duplicating work.
+
+## Writer needs PR review [#column_writer-pr-review]
+
+Exactly what it says. Typically, the writer who submitted the pull request will move it to this column.
+
+A pull request review means reviewing for basic stuff like is it looking okay on preview, are there broken links or images that don't render, and are there any obvious errors in the .mdx content shown in the diff. When a pull request review is complete, this should be marked approved in GH.
+
+## Writer needs peer edit [#column_writer-peer-edit]
+
+Also exactly what it says. As with pull request review column, the writer who submitted the pull request will drag to this column.
+
+This includes all the stuff in a pull request review plus an actual peer edit. If the person requests changes the pull request should not be marked approved. If there are some suggestions, but none that need to be acted on before merging, it's okay to mark the pull request approved and leave further updates at the discretion of the writer who will be responsible for eventually merging the pull request.
+
+## Waiting on SME/blocked [#column_waiting-on-sme-blocked]
+
+Blocked until something else happens. Usually this means it's waiting on answers/verification from SME or the person who submitted the pull request. 
+
+## Waiting on TW to merge [#column_waiting-on-tw-merge]
+
+When a docs writer creates a pull request, it's their responsibility to merge it into `develop` at the appropriate time. After a reviewer is done with their pull reuqest review or peer edit, they move it into this column so the original writer can merge when ready.
+
+## 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/content/docs/agile-handbook/sprint-mechanics/sprint-workflow-and-jira-boards.mdx

@@ -5,13 +5,14 @@ topics:
   - Docs agile handbook
 ---
 
-Our sprint workflow in Jira depends on what type of work we're dealing with: Planned work, unplanned ("surprise!") work, or self-service edits that came in through the hero process.
+All of our sprint work is tracked in Jira. The workflow depends on what type of work we're dealing with: Planned or unplanned ("surprise!") work.
 
 ## Planned work [#planned_work]
 
 Planned work includes all work that is currently in our backlog or has been added to the current sprint as a result of a Sprint Planning session. This could include writing or updating documentation, research, meeting with SMEs, information architecture, incorporating peer edits, SME review, and so on. It does not include self-service edits or urgent doc requests, which are covered in the [Unplanned work](3379_INSERT_LINK_HERE) and [Self service and hero work](3379_INSERT_LINK_HERE) sections.
+Planned work includes all work that is currently in our backlog or has been added to the current sprint as a result of a Sprint Planning session. This could include writing or updating documentation, research, meeting with SMEs, information architecture, incorporating peer edits, SME review, and so on.
 
-## Unplanned work (surprises) [#unplanned_work_surprises]
+## Unplanned work (surprises!) [#unplanned_work_surprises]
 
 Usually, we get notified of major requests far enough in advance that we can include them in liaison project plans, backlog grooming, and sprint planning. Occasionally, of course, something bigger surprises us that needs emergency support.