{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 Condor 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 Condor's file transfer capabilities, see section~\ref{sec:file-transfer}".
+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:
