diff --git a/modules/sysadmin_guide/nav.adoc b/modules/sysadmin_guide/nav.adoc
index a5dc5b9..1aefd62 100644
--- a/modules/sysadmin_guide/nav.adoc
+++ b/modules/sysadmin_guide/nav.adoc
@@ -29,7 +29,7 @@
 ** xref:fedmsg-gateway.adoc[fedmsg-gateway - SOP]
 ** xref:fedmsg-introduction.adoc[fedmsg introduction and basics - SOP]
 ** xref:fedmsg-irc.adoc[fedmsg-irc - SOP]
-** xref:fedmsg-new-message-type.adoc[fedmsg-new-message-type - SOP in review ]
+** xref:fedmsg-new-message-type.adoc[Adding a new fedmsg message type - SOP]
 ** xref:fedmsg-relay.adoc[fedmsg-relay - SOP in review ]
 ** xref:fedmsg-websocket.adoc[fedmsg-websocket - SOP in review ]
 ** xref:fedocal.adoc[fedocal - SOP in review ]
diff --git a/modules/sysadmin_guide/pages/fedmsg-new-message-type.adoc b/modules/sysadmin_guide/pages/fedmsg-new-message-type.adoc
index f1732dd..1cd98bd 100644
--- a/modules/sysadmin_guide/pages/fedmsg-new-message-type.adoc
+++ b/modules/sysadmin_guide/pages/fedmsg-new-message-type.adoc
@@ -6,8 +6,8 @@ First, figure out how you're going to publish the message? Is it from a
 shell script or from a long running process?
 
 If its from shell script, you need to just add a
-[.title-ref]#fedmsg-logger# statement to the script. Remember to set the
-[.title-ref]#--modname# and [.title-ref]#--topic# for your new message's
+_fedmsg-logger_ statement to the script. Remember to set the
+_--modname_ and _--topic_ for your new message's
 fully-qualified topic.
 
 If its from a python process, you need to just add a
@@ -15,13 +15,13 @@ If its from a python process, you need to just add a
 apply here.
 
 If this is a short-lived python process, you'll want to add
-[.title-ref]#active=True# to the call to `fedmsg.publish(..)`. This will
-make the fedmsg lib "actively" reach out to our fedmsg-relay running on
-busgateway01.
+_active=True_ to the call to `fedmsg.publish(..)`. This will
+make the _fedmsg_ lib "actively" reach out to our _fedmsg-relay_ running on
+_busgateway01_.
 
 If it is a long-running python process (like a WSGI thread), then you
 don't need to pass any extra arguments. You don't want it to reach out
-to the fedmsg-relay if possible. Your process will require that some
+to the _fedmsg-relay_ if possible. Your process will require that some
 "endpoints" are created for it in `/etc/fedmsg.d/`. More on that below.
 
 == Supporting infrastructure
@@ -31,18 +31,18 @@ key that can be read by the program to sign its message. If you don't
 have a cert already, then you need to create it in the private repo. Ask
 a sysadmin-main member.
 
-Then you need to declare those certs in the [.title-ref]#fedmsg_certs#
+Then you need to declare those certs in the _fedmsg_certs
 data structure stored typically in our ansible `group_vars/` for this
 service. Declare both the name of the cert, what group and user it
 should be owned by, and in the `can_send:` section, declare the list of
 topics that this cert should be allowed to publish.
 
 If this is a long-running python process that is _not_ passing
-[.title-ref]#active=True# to the call to
-[.title-ref]#fedmsg.publish(..)#, then you have to also declare
+_active=True_ to the call to
+`fedmsg.publish(..)`, then you have to also declare
 endpoints for it. You do that by specifying the `fedmsg_wsgi_procs` and
 `fedmsg_wsgi_vars` in the `group_vars` for your service. The iptables
-rules and fedmsg endpoints should be automatically created for you on
+rules and _fedmsg_ endpoints should be automatically created for you on
 the next playbook run.
 
 == Supporting code
@@ -50,9 +50,9 @@ the next playbook run.
 At this point, you can push the change out to production and be
 publishing messages "okay". Everything should be fine.
 
-However, your message will show up blank in datagrepper, in IRC, and in
-FMN, and everywhere else we try to render it. You _must_ then follow up
-and write a new [.title-ref]#Processor# for it in the fedmsg_meta
+However, your message will show up blank in _datagrepper_, in IRC, and in
+_FMN_, and everywhere else we try to render it. You _must_ then follow up
+and write a new _Processor_ for it in the _fedmsg_meta_
 library we maintain:
 https://github.com/fedora-infra/fedmsg_meta_fedora_infrastructure
 
@@ -60,14 +60,14 @@ You also _must_ write a test case for it there. The docs listing all
 topics we publish at http://fedora-fedmsg.rtfd.org/ is automatically
 generated from the test suite. Please don't forget this.
 
-Lastly, you should cut a release of fedmsg_meta and deploy it using the
-[.title-ref]#playbooks/manual/upgrade/fedmsg.yml# playbook, which should
+Lastly, you should cut a release of _fedmsg_meta_ and deploy it using the
+`playbooks/manual/upgrade/fedmsg.yml` playbook, which should
 update all the relevant hosts.
 
 == Corner cases
 
 If the process publishing the new message lives _outside_ our main
-network, you have to jump through more hoops. Look at abrt, koschei, and
-copr for examples of how to configure this (you need a special firewall
+network, you have to jump through more hoops. Look at _abrt_, _koschei_, and
+_copr_ for examples of how to configure this (you need a special firewall
 rule, and they need to be configured to talk to our "inbound gateway"
 running on the proxies.