{subsection: Where's the version history?}
 
-It lives in the source code in /doc/version-history. Inside version-history, there are separate files for each release series (e.g. "6-7.history.tex").  In each file, there's a separate subsection for each version, with the most recent versions at the top of the file. Try to keep the individual version sections sorted by relevance.
+It lives in the source code in /doc/version-history. Inside version-history, there are separate files for each release series (e.g. =6-7.history.tex=).  In each file, there's a separate subsection for each version, with the most recent versions at the top of the file. Try to keep the individual version sections sorted by relevance.
 
 {subsection:What should a version history entry be like?}
 
 It should be concise, clear, self-contained English prose.  It should be just enough info for a user or admin to have an idea of the kind of change, so they can decide if they care enough about it to upgrade their pool.  It should not include any developer jargon, or refer to internals of the HTCondor source because people shouldn't have to know anything about our source.  It should be short - if it is more than a couple sentences, or includes tables/lists, you should place this new information elsewhere in the manual. The version history entry can then (and often should) include pointers into other parts of the manual where you document the new config knob, explain the new feature, etc.  So for instance, if you fix a bug in the file transfer code, it doesn't hurt to include the line: "For more information about HTCondor's file transfer capabilities, see section~\ref{sec:file-transfer}".
 
-Immediately at the end of the entry, include the gittrac ticket number associated with this change by using the =\Ticket= macro as in the example below - note there is no trailing period after invoking this macro.  Optionally it is nice to include a commit ID as a comment above the entry. If you don't have a gittrac ticket number, 1) why not create a ticket and use it? but 2) the commit ID becomes mandatory.  Here is an example:
+Immediately at the end of the entry, include the gittrac ticket number associated with this change by using the =\Ticket= macro as in the example below - note there is no trailing period after invoking this macro. And, this macro goes on its own line in the LaTeX source. Optionally it is nice to include a commit ID as a comment above the entry. If you don't have a gittrac ticket number, 1) why not create a ticket and use it? or2) the commit ID becomes mandatory.  Here is an example:
 
 {code}
 % commit c4f4d911a808e1bdb18552e1cdeb0407b6344969
@@ -24,6 +24,8 @@
 
 Like any text added into the Manual, you should always spell check! Note that "aspell check filename.tex" is an effective spellchecker on CSL supported machines and will automatically ignore TeX commands. If you use Vim or Emacs, {link: http://toddshobbies.blogspot.com/2008/01/easy-spell-checking-with-latex.html Todd's Geek Blog shows how to spell check on the fly} just like MS Word.
 
+Like any commmit, your changes should not break the build.  In this case, we're talking about a build of the manual.  Check your prose, your formatting, and that you have not broken the build by making the manual.  Two convenient targets are in =/doc/Makefile=:  1) =ref.pdf= will make a pdf called =ref.pdf=, and 2) =local.html= will place html files in a directory named =ref-v<version>=.
+
 {subsection:What is the right branch of the manual for my change?}
 
 See SourceCodeBranches - typically it should go in the same branch as the corresponding code.