diff --git a/website/src/daily-emails/2022-11-30.md b/website/src/daily-emails/2022-11-30.md
new file mode 100644
index 00000000..9d7af9b8
--- /dev/null
+++ b/website/src/daily-emails/2022-11-30.md
@@ -0,0 +1,43 @@
+---
+title: >
+  Ship, Show or Ask
+pubDate: 2022-11-30
+permalink: >
+  archive/2022/11/30/ship-show-or-ask
+tags:
+  - git
+---
+
+"Ship / Show / Ask" describes itself as a self-described modern branching strategy that combines the features of pull or merge requests with the ability to keep shipping changes.
+
+Each change is either a "Ship", "Show", or "Ask".
+
+## Ship
+
+"Ship" changes are what I most commonly do with continuous integration and trunk-based development projects. Changes are committed directly to the main branch and shipped - assuming that the CI pipeline and any other automated checks pass. There is no blocking code review or pull request for "Ship" changes.
+
+## Show
+
+"Show" changes are made on a temporary branch instead of the mainline. This branch is then used to create a pull request which is closed once the CI checks pass without any code review.
+
+Once the pull request is merged, the change is deployed, but the pull request is still available as somewhere to have feedback and conversation about the change.
+
+This is something that I did today after starting to write a new feature by implementing the Decorator design pattern, and wanted others to be aware of this approach and ask any questions.
+
+Another reason for this approach is if someone wants to ensure that the CI checks will pass before merging to mainline. Some Developers worry about breaking the CI pipeline with a trunk-based approach and blocking others, so want to know that the pipeline will continue to work and they aren't disrupting other team members.
+
+## Ask
+
+This is how I've worked on most projects before, and still with some clients where they want to review changes before merging, or maybe I want to have a discussion and review a change beforehand.
+
+This is also common when new Developers join a project or need to change some code they haven't worked on before.
+
+## Conclusion
+
+I like the flexibility and balance of this approach. I prefer to work on "mostly ship" projects, and most of the show and ask conversations happen during pair or mob programming sessions.
+
+Some of my clients where I work with teams are "mostly ask" and work in a more Git Flow-type way and want to review any changes before they're merged and deployed.
+
+But if you're working on a "mostly ask" project and want to move to "mostly ship", then aiming to move to "mostly show" is a good intermediate step and a way to reduce shipping time or develop and build confidence in the CI pipeline before moving to trunk-based development and removing the manual review step.
+
+The full article with more information is at https://martinfowler.com/articles/ship-show-ask.html.