GITBOOK-280: No subject

docs/SUMMARY.md

@@ -34,7 +34,7 @@
 * [Project Delivery Workflow](product-ops/product-delivery-workflow.md)
 * [Index Issue Specifications](product-ops/index-issue-specifications.md)
 * [DTS Website Management](product-ops/dts-website.md)
-* [Release Process](product-ops/release-management-process.md)
+* [Release Process](product-ops/release-process.md)
 * [Product Manager Assignments](https://docs.google.com/spreadsheets/d/1BsOklJsJiIIqdlmtNtr9peL3URS7Hdu9RVj4D97701k/edit#gid=1907210355)
 
 ## Developer

docs/product-ops/product-delivery-workflow.md

@@ -104,7 +104,7 @@ When you click the "New Issue" button in the upper righthand corner of most page
 * Work with the team lead—via Github comments or in a planning/refinement/sync meeting—to assign an [estimate](https://atd-dts.gitbook.io/wiki/product-ops/github-project-management#estimates) to each issue. Zenhub's [Planning Poker](https://www.zenhub.com/planning-poker) is also a fun way to estimate asynchronously.  
 * Bring complex issues to Backlog Refinement ([Apps](https://docs.google.com/document/d/1NENOLq5v9n77N\_sNbV\_iu2dzi9cU5dTfAex9ay7Q7N0/edit#heading=h.mlv4bpg8du2a) | [Dev](https://docs.google.com/document/d/1k6L33xi1zDWEtW3n3oh212DmDug2F8yHLaZ-XW20Dsg/edit#heading=h.7h18hmh8ypw)) to discuss with builders. Break them up into smaller issues as necessary, document the agreed-upon approach, and align on an [estimate](https://atd-dts.gitbook.io/wiki/product-ops/github-project-management#estimates). 
 * Prioritize work with stakeholders during Sprint Reviews. 
-* If practical, [release](release-management-process.md) versions of an application on a regular basis. 
+* If practical, [release](release-process.md) versions of an application on a regular basis. 
 * Perform usability testing to surface improvements to the user experience. Since we don't have dedicated user researchers at DTS, we love [think-aloud usability testing](https://www.nngroup.com/articles/thinking-aloud-the-1-usability-tool/) for its simplicity and depth of insight. [Here are some think-aloud test plans](https://drive.google.com/drive/u/0/folders/1eQai0Hzsz7EVI9RUmPWdPq3rNX0FPc7T) we've done. It's handy to record sessions on Teams so that you can expand on your notes, embed screenshots/clips in issues, etc. 
 
 ## Completion 

docs/product-ops/release-process.md

@@ -0,0 +1,22 @@
+# Release Process
+
+This is the general process we use to release new code to one of our custom applications. The Apps team has defined a separate, specialized [process for deploying custom code in Knack](https://atd-dts.gitbook.io/atd-knack-operations/). 
+
+* The Product Manager & Dev Lead collaboratively plan what issues will be included in the release
+* The Dev Lead ensures that all issues are assigned, completed, and tested before the release
+* After a pull request is reviewed by several devs, the PM reviews and adds any new functionality to the QA test script  
+* The Dev Lead creates a single pull request that includes the scope of the release\
+  _Example:_ [_https://github.com/cityofaustin/atd-vz-data/pull/496_](https://github.com/cityofaustin/atd-vz-data/pull/496)
+* The Dev Lead cleans up release notes\
+  _Example:_ [_https://github.com/cityofaustin/atd-vz-data/releases_](https://github.com/cityofaustin/atd-vz-data/releases/)
+* The release branch is deployed to Staging and the PM performs QA testing 
+* The PM notifies users of scheduled downtime
+* Release party 🎉
+  * PM merges pull request
+  * Dev Lead notifies #atd-dev that the pull request has been tested, approved, and merged 
+  * PM sends release notes to stakeholders and users 
+  * Team debriefs on the process and updates the steps as needed 
+  * Dev Lead creates an issue for the next release
+
+Application-specific versions of this process are written as issues so they can be tracked collaboratively for each release. \
+_Example:_ [_https://github.com/cityofaustin/atd-data-tech/issues/16094_](https://github.com/cityofaustin/atd-data-tech/issues/16094)