diff --git a/README b/README.asc
similarity index 88%
rename from README
rename to README.asc
index 3c2b8655..28922ecb 100644
--- a/README
+++ b/README.asc
@@ -109,12 +109,6 @@ It is sensible to also heed the following guidelines:
     means no imps, cyberdemons, etc).  The new monsters will behave the
     same way as the originals, but will be totally new.
 
-=== Build process
-
-The Freedoom build process is fairly complete and should not change
-without good reason.  Write a decent explanation why your method is
-better; just enough to get your point across is good enough.
-
 === Documentation
 
 Freedoom always needs help with the documentation, so please send your
@@ -138,18 +132,14 @@ patches, but keep in mind:
 TODO: Figure out the best method of doing this.  This mainly requires
 time to see what works best.
 
-If you use git, make sure your commit messages start with a single line,
-under 72 characters, which provides an adequate summary of your changes.
-You should prefix this line with the component you are committing (for
-example, ``map17: fixed unbeatable map'').  This should be followed by a
-blank line and a paragraph or more to explain your change in detail (for
-example, explaining what part of the map was broken).  See commit
-49dc6ca861d4b85ca16b219941ecb86d3e172ac1 for an example.  Sign your
-comments with +git commit -s+, these leaves a trail of whose hands a
-commit went through and could be useful for some purposes; git alone can
-give an indication of up to two people, however the AUTHOR/COMMITTER
-fields are not quite reliable or flexible enough for the same
-information.
+If you use git, make sure your commit messages start with a single
+line, under 72 characters, which provides an adequate summary of your
+changes. You should prefix this line with the component you are commit
+(for example, ``map17: fixed unbeatable map''). This should be
+followed by a blank line and more explanation if it's needed (for
+example, explaining what part of the map was broken). The commit
+2013-12-20T16:06:55Z!rjy@users.sourceforge.net shows a good example of
+a well-structured commit message.
 
 You should commit often; each important change should get its own
 commit, but minor changes need not.  Take advantage of git's ability to