diff --git a/.github/workflows/publish-docs.yml b/.github/workflows/publish-docs.yml
index 03af1009..a7165fef 100644
--- a/.github/workflows/publish-docs.yml
+++ b/.github/workflows/publish-docs.yml
@@ -9,6 +9,7 @@ on:
       - 'docs/**'
     paths:
       - 'docs/**'
+      - '.github/workflows/publish-docs.yml'
 
 jobs:
   publish:
@@ -17,6 +18,7 @@ jobs:
       matrix:
         python-version: [3.7]
         package: [docs]
+        repository: ['delphix/virtualization-sdk']
 
     steps:
       - uses: actions/checkout@v2
@@ -69,7 +71,18 @@ jobs:
         working-directory: ${{ matrix.package }}
         run: |
           pipenv run mkdocs build --clean
-      - name: Deploy the contents of docs/site to gh-pages 🚀
+      - name: Deploy the contents of docs/site to gh-pages (developer.delphix.com) 🚀
+        if: ${{ github.repository == matrix.repository }}
+        uses: peaceiris/actions-gh-pages@v3
+        with:
+          github_token: ${{ secrets.GITHUB_TOKEN }}
+          publish_dir: docs/site
+          commit_message: Deploy to gh-pages 🚀
+          user_name: "github-actions[bot]"
+          user_email: "github-actions[bot]@users.noreply.github.com"
+          cname: developer.delphix.com
+      - name: Deploy the contents of docs/site to personal gh-pages 🚀
+        if: ${{ github.repository != matrix.repository }}
         uses: peaceiris/actions-gh-pages@v3
         with:
           github_token: ${{ secrets.GITHUB_TOKEN }}
diff --git a/docs/docs/Building_Your_First_Plugin/Data_Ingestion.md b/docs/docs/Building_Your_First_Plugin/Data_Ingestion.md
index a3aaf6d3..67dcd0cb 100644
--- a/docs/docs/Building_Your_First_Plugin/Data_Ingestion.md
+++ b/docs/docs/Building_Your_First_Plugin/Data_Ingestion.md
@@ -21,7 +21,7 @@ quite limiting.
 
 For our first plugin, we will be using the more flexible [staging](/References/Glossary.md#staged-linkingsyncing) strategy. With this strategy, the Delphix Engine uses NFS for Unix environments (or iSCSI on Windows environments) to mount storage onto a [staging environment](/References/Glossary.md#staging-environment). Our plugin will then be in full control of how to get data from the source environment onto this storage mount.
 
-With the staging strategy, there are two types of syncs: sync and resync. A `sync` is used to ingest incremental changes while a `resync` is used to re-ingest all the data for the dSource. For databases, this could mean re-ingesting from a full database backup to reset the dSource. A `sync` and a `resync` will execute the same plugin operations. To differentiate a `sync` from a `resync`, simply add a boolean property (i.e. `resync`) in the plugin's [snapshot parameters definition](References/Schemas_and_Autogenerated_Classes.md#snapshotparametersdefinition-schema). Once `sync` or `resync` is selected, the property will be passed into [linked.pre_snapshot](/References/Plugin_Operations.md#staged-linked-source-pre-snapshot) and [linked.post_snapshot](/References/Plugin_Operations.md#staged-linked-source-post-snapshot) as a [snapshot parameter](/References/Glossary.md#snapshot-parameters).
+With the staging strategy, there are two types of syncs: sync and resync. A `sync` is used to ingest incremental changes while a `resync` is used to re-ingest all the data for the dSource. For databases, this could mean re-ingesting from a full database backup to reset the dSource. A `sync` and a `resync` will execute the same plugin operations. To differentiate a `sync` from a `resync`, simply add a boolean property (i.e. `resync`) in the plugin's [snapshot parameters definition](/References/Schemas_and_Autogenerated_Classes.md#snapshotparametersdefinition-schema). Once `sync` or `resync` is selected, the property will be passed into [linked.pre_snapshot](/References/Plugin_Operations.md#staged-linked-source-pre-snapshot) and [linked.post_snapshot](/References/Plugin_Operations.md#staged-linked-source-post-snapshot) as a [snapshot parameter](/References/Glossary.md#snapshot-parameters).
 
 A regular `sync` is the default and is executed as part of policy driven syncs. A `resync` is only executed during initial ingestion or if the Delphix user manually starts one. The customer can manually trigger a `resync` via the UI by selecting the dSource, going to more options and selecting **Resynchronize dSource**. ![Screenshot](images/Resync.png)
 
diff --git a/docs/docs/Release_Notes/3.0.0/3.0.0.md b/docs/docs/Release_Notes/3.0.0/3.0.0.md
index e8c41e89..c86f0998 100644
--- a/docs/docs/Release_Notes/3.0.0/3.0.0.md
+++ b/docs/docs/Release_Notes/3.0.0/3.0.0.md
@@ -7,9 +7,14 @@ To install or upgrade the SDK, refer to instructions [here](/Getting_Started.md#
 	* Provide end-users with configurable options prior to taking a snapshot.
 	* The options selected are provided as input to pre/post-snapshot functions.
 
+* Added support to initialize an [empty VDB](/References/Glossary#empty-vdb).
+	* Create an empty virtual dataset within Delphix, instead of creating it externally and ingesting it.
+	* Utilize this functionality by implementing the [initialize](/References/Plugin_Operations#virtual-source-initialize) operation.
+
 * Added a `scratch_path` property on the [RemoteHost](/References/Classes/#remotehost) object which can be used as:
 	* A location to store small amounts of persistent data.
 	* A location to mount VDB data.
+
 More details about `scratch_path` can be found [here](/Best_Practices/Scratch_Paths.md)
 
 ## Breaking Changes