diff --git a/.github/contributing.md b/.github/contributing.md
index fefc136d..01b09d67 100644
--- a/.github/contributing.md
+++ b/.github/contributing.md
@@ -7,36 +7,13 @@ for its software development lifecycle. Github workflow is a simple workflow
 that works well for a small project with multiple developers needing to work 
 on the code and review each other's code before merging into the main branch.
 
-### Process
-
-1. **Developer A** wants to make a change to the code
-2. On their local machine, developer A checkouts a branch to make that change
-3. **Developer B** wants to make a change to a different part of the code
-4. On their local machine, developer B checkouts a branch to make their change
-5. **Developer A** makes the change and pushes the code to the remote repo on Github
-6. **Developer A** opens a Pull Request (PR) so that others can review the change
-7. Other developers approve the Pull Request 
-8. **Developer A** squashes their branch's commits and merges the Pull Request into the main branch
-9. **Developer B** updates their local main branch with the changes that were just merged 
-10. **Developer B** squashes their branch's commits and merges the Pull Request into the main branch
-11. **Developer B** opens a Pull Request (PR) so that others can review the change
-12. Other developers approve the Pull Request 
-13. **Developer C** wants to make a release
-14. **Developer C** uses the [D3b Release Maker](https://github.com/d3b-center/d3b-release-maker) to 
-create a release PR on Github
-15. Other developers approve the Pull Request 
-16. **Developer C** merges the release PR which activates a Github workflow that tags the main branch with 
-the next version and creates the release on Github 
-
-
-Let's solidify this with an example.
 
 ## 👨🏻‍💻 Develop
 
 This assumes you've already setup your development environment. If not, 
 follow the steps in [Setup Dev Environment](#setup-dev-environment)
 
-### Create a branch
+### 1. 🌴 Create a branch
 ```shell
 # Checkout your local main branch
 git checkout main
@@ -49,7 +26,7 @@ git pull
 git checkout -b add-patient-birth-sex 
 ```
 
-### Commit the change 
+### 2. ✏️  Commit the change 
 
 After you've made the change you want on your local machine its time 
 to commit that change to the project repo. 
@@ -72,7 +49,7 @@ $ git add <file path to the file you want to commit>
 $ git commit -m ":sparkles: Add new birthSex extension to Patient" 
 ```
 
-### ⚠️  Important! - Rebase
+### ⚠️  3. Important! - Rebase
 If another developer has merged their code (Pull Request) while you're working
 on your change, you will need to update your branch with those changes before
 you continue developing. 
@@ -98,7 +75,7 @@ git push -f
 If you do this often you will rarely have conflicts.
 
 
-## 📝 Pull Request
+## 📝 4. Pull Request
 
 Once you're happy with your changes, its time to [open a Pull Request](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request?tool=webui)
 so that others can review your code and upon their approval you can merge your branch
@@ -117,7 +94,7 @@ with a **"Motivation"** and **"Approach"** section. Please be sure to fill these
 so that reviewers can quickly and easily understand the purpose of the PR and 
 the changes.
 
-## Squash and Merge
+## 5. 🔀 Squash and Merge
 Once your PR has been approved you're ready to merge it. Before you merge it,
 you'll want to "squash" all of your commits into 1 commit. This cleans up your 
 branch's commit history and makes the main branch much cleaner as feature 
@@ -172,7 +149,7 @@ versions of the IG and tie those versions to snapshots of the project.
 In this project we use [Semantic Versioning](https://semver.org/) to mint 
 version numbers for various types of changes. Please read more at semvar.org. 
 
-## 📦 Release
+## 📦 6. Release
 Releases on Github are snapshots of the project at a particular point in time,
 stamped with a versionn number of some kind, in our case, semantic version number.
 A release can be made at any time, although, it is typical to make a release after
@@ -197,4 +174,30 @@ repo, create the Github release and attach the snapsot to the release.
 
 The Github workflow will also publish the IG to its domain.
 
+## 👩‍💻 Example of Workflow
+
+Let's solidify everything above with an example.
+
+1. **Developer A** wants to make a change to the code
+2. On their local machine, developer A checkouts a branch to make that change
+3. **Developer B** wants to make a change to a different part of the code
+4. On their local machine, developer B checkouts a branch to make their change
+5. **Developer A** makes the change and pushes the code to the remote repo on Github
+6. **Developer A** opens a Pull Request (PR) so that others can review the change
+7. Other developers approve the Pull Request 
+8. **Developer A** squashes their branch's commits and merges the Pull Request into the main branch
+9. **Developer B** updates their local main branch with the changes that were just merged 
+10. **Developer B** squashes their branch's commits and merges the Pull Request into the main branch
+11. **Developer B** opens a Pull Request (PR) so that others can review the change
+12. Other developers approve the Pull Request 
+13. **Developer C** wants to make a release
+14. **Developer C** uses the [D3b Release Maker](https://github.com/d3b-center/d3b-release-maker) to 
+create a release PR on Github
+15. Other developers approve the Pull Request 
+16. **Developer C** merges the release PR which activates a Github workflow that tags the main branch with 
+the next version and creates the release on Github 
+
+
+
+