diff --git a/modules/sysadmin_guide/nav.adoc b/modules/sysadmin_guide/nav.adoc
index 30f3b31..ad361a7 100644
--- a/modules/sysadmin_guide/nav.adoc
+++ b/modules/sysadmin_guide/nav.adoc
@@ -86,7 +86,7 @@
 ** xref:outage.adoc[Outage Infrastructure - SOP]
 ** xref:packagereview.adoc[Package Review - SOP]
 ** xref:pagure.adoc[Pagure Infrastructure - SOP]
-** xref:pdc.adoc[pdc - SOP in review ]
+** xref:pdc.adoc[PDC - SOP]
 ** xref:pesign-upgrade.adoc[pesign-upgrade - SOP in review ]
 ** xref:planetsubgroup.adoc[planetsubgroup - SOP in review ]
 ** xref:publictest-dev-stg-production.adoc[publictest-dev-stg-production - SOP in review ]
diff --git a/modules/sysadmin_guide/pages/pdc.adoc b/modules/sysadmin_guide/pages/pdc.adoc
index 4534048..130f1c7 100644
--- a/modules/sysadmin_guide/pages/pdc.adoc
+++ b/modules/sysadmin_guide/pages/pdc.adoc
@@ -2,8 +2,10 @@
 
 Store metadata about composes we produce and "component groups".
 
-App: https://pdc.fedoraproject.org/ Source for frontend:
-https://github.com/product-definition-center/product-definition-center
+App: https://pdc.fedoraproject.org/
+
+Source for frontend: https://github.com/product-definition-center/product-definition-center
+
 Source for backend: https://github.com/fedora-infra/pdc-updater
 
 == Contact Information
@@ -27,12 +29,12 @@ tooling down the road for future releases.
 
 The webapp is a django app running on pdc-web0\{1,2}. Unlike most of our
 other apps, it does not use OpenID for authentication, but it instead
-uses SAML2. It uses [.title-ref]#mod_auth_mellon# to achieve this (in
+uses SAML2. It uses _mod_auth_mellon_ to achieve this (in
 cooperation with ipsilon). The webapp allows new data to be POST'd to it
 by admin users.
 
-The backend is a [.title-ref]#fedmsg-hub# process running on
-pdc-backend01. It listens for new composes over fedmsg and then POSTs
+The backend is a _fedmsg-hub_ process running on
+_pdc-backend01_. It listens for new composes over fedmsg and then POSTs
 data about those composes to PDC. It also listens for changes to the
 fedora atomic host git repo in pagure and updates "component groups" in
 PDC to reflect what rpm components constitute fedora atomic host.
@@ -40,7 +42,10 @@ PDC to reflect what rpm components constitute fedora atomic host.
 For long-winded history and explanation, see the original Change
 document: https://fedoraproject.org/wiki/Changes/ProductDefinitionCenter
 
-NOTE: pdc is being replaced by fpdc (Fedora Product Definition Center)
+[NOTE]
+====
+PDC is being replaced by fpdc (Fedora Product Definition Center)
+====
 
 == Upgrading the Software
 
@@ -51,32 +56,32 @@ a run of that playbook.
 
 == Logs
 
-Logs for the frontend are in [.title-ref]#/var/log/httpd/error_log# on
+Logs for the frontend are in `/var/log/httpd/error_log` on
 pdc-web0\{1,2}.
 
-Logs for the backend can be accessed with [.title-ref]#journalctl -u
-fedmsg-hub -f# on pdc-backend01.
+Logs for the backend can be accessed with
+`journalctl -u fedmsg-hub -f` on _pdc-backend01_.
 
 == Restarting Services
 
-The frontend runs under apache. So either [.title-ref]#apachectl
-graceful# or [.title-ref]#systemctl restart httpd# should do it.
+The frontend runs under apache. So either `apachectl graceful`
+or `systemctl restart httpd` should do it.
 
-The backend runs as a fedmsg-hub, so [.title-ref]#systemctl restart
-fedmsg-hub# should restart it.
+The backend runs as a _fedmsg-hub_, so
+`systemctl restart fedmsg-hub` should restart it.
 
 == Scripts
 
-The pdc-updater package (installed on pdc-backend01) provides three
+The _pdc-updater_ package (installed on _pdc-backend01_) provides three
 scripts:
 
-* pdc-updater-audit
-* pdc-updater-retry
-* pdc-updater-initialize
+* `pdc-updater-audit`
+* `pdc-updater-retry`
+* `pdc-updater-initialize`
 
 A possible failure scenario is that we will lose a fedmsg message and
 the backend will not update the frontend with info about that compose.
-To detect this, we provide the [.title-ref]#pdc-updater-audit# command
+To detect this, we provide the `pdc-updater-audit` command
 (which gets run once daily by cron with emails sent to the releng-cron
 list). It compare all of the entries in PDC with all of the entries in
 kojipkgs and then raises an alert if there is a discrepancy.
@@ -84,9 +89,9 @@ kojipkgs and then raises an alert if there is a discrepancy.
 Another possible failure scenario is that the fedmsg message is
 published and received correctly, but there is some processing error
 while handling it. The event occurred, but the import to the PDC db
-failed. The [.title-ref]#pdc-updater-audit# script should detect this
+failed. The `pdc-updater-audit` script should detect this
 discrepancy, and then an admin will need to manually repair the problem
-and retry the event with the [.title-ref]#pdc-updater-retry# command.
+and retry the event with the `pdc-updater-retry` command.
 
 If doomsday occurs and the whole thing is totally hosed, you can delete
 the db and re-ingest all information available from releng with the
@@ -95,14 +100,14 @@ happen on pdc-web01 with the standard django settings.py commands.)
 
 == Manually Updating Information
 
-In general, you shouldn't have to do these things. pdc-updater will
+In general, you shouldn't have to do these things. `pdc-updater` will
 automatically create new releases and update information, but if you
-ever need to manipulate PDC data, you can do it with the pdc-client
-tool. A copy is installed on pdc-backend01 and there are some
+ever need to manipulate PDC data, you can do it with the _pdc-client_
+tool. A copy is installed on _pdc-backend01_ and there are some
 credentials there you'll need, so ssh there first.
 
 Make sure that you are root so that you can read
-[.title-ref]#/etc/pdc.d/fedora.json#.
+`/etc/pdc.d/fedora.json`.
 
 Try listing all of the releases:
 
@@ -117,11 +122,10 @@ $ pdc -s fedora release update fedora-21-updates --deactivate
 ....
 
 [NOTE]
-.Note
 ====
 There are lots more attribute you can manipulate on a release (you can
-change the type, and rename them, etc..) See [.title-ref]#pdc --help#
-and [.title-ref]#pdc release --help# for more information.
+change the type, and rename them, etc..) See `pdc --help`
+and `pdc release --help` for more information.
 ====
 
 Listing all composes:
@@ -139,9 +143,11 @@ https://github.com/product-definition-center/product-definition-center/issues/42
 Some small group of release engineers need to be superuser to set eol
 dates and add/remove components. You can grant them permissions to do
 this via some direct database calls. First find out their email address
-listed in fas, then login to db01.phx2.fedoraproject.org:
+listed in fas, then login to _db01.iad2.fedoraproject.org_:
 
-sudo -u postgresql psql pdc pdc-# update kerb_auth_user set is_superuser
-= 'true' where email = 'usersemailfromfas';
+....
+sudo -u postgresql psql pdc pdc-
+# update kerb_auth_user set is_superuser = 'true' where email = 'usersemailfromfas';
+....
 
-the user will now have privs with their normal tokens.
+The user will now have privs with their normal tokens.