diff --git a/CodeReview.md b/CodeReview.md
new file mode 100644
index 0000000..3b9cae1
--- /dev/null
+++ b/CodeReview.md
@@ -0,0 +1,39 @@
+# Requirements
+
+All commits and must be reviewed by at least one Melange engineer other than the author before migration to the master branch.
+
+# Author Process
+
+When you feel that your current line of development is ready for review:
+  1. If master has advanced beyond where it was when you started your development, pull the current head of master and merge master's changes with yours.
+  1. Push your line of development to a branch in the origin repository.
+  1. Ask another Melange engineer to review every unreviewed commit in your branch.
+  1. Make changes and re-push to your branch, and secure re-review as necessary.
+  1. When every commit on your branch has been reviewed (positively), push the (reviewed) head commit of your development branch to master, taking care to make no additional changes.
+  1. Prune your development branch if it will see no further use.
+
+# Sample Author Commands
+
+## Pulling from origin
+`git pull --no-rebase --no-commit`
+
+Without the --no-commit flag, a pull operation that requires a commit will get an auto-created commit with an auto-generated log message like "Merge branch page-fix". Because our branch names are ephemeral we suppress the auto-created commit so that we may give any merge commit a message that describes the substance of what is being merged.
+
+## Pushing commits to a branch for review
+`git push origin <hex string of commit to be reviewed>:<review branch name>`
+
+## Pushing reviewed commits to master
+`git push origin <latest reviewed commit hex string, not branch name or other alias>:master`
+
+This will either push your specific reviewed commits to master or fail as non-fast-forward (in which case you'll have to merge and undergo further review).
+
+# Rebase
+
+**Do not rebase.** Rebases cause us to lose review history and chronological ordering of our work. A falsely linear history just isn't worth it.
+
+# Reviewer Process
+If a change looks good and needs no comment, just mark it positive and hit the "submit" button. This suppresses the per-commit email thread and cuts down on mailing list noise.
+
+# Exceptions
+
+Commits made as part of the release process ("Set new Melange version number...") are exempt and may be made on master. They should still be reviewed when convenient, though.
\ No newline at end of file
diff --git a/CodeReview.wiki b/CodeReview.wiki
deleted file mode 100644
index 28bd0fb..0000000
--- a/CodeReview.wiki
+++ /dev/null
@@ -1,42 +0,0 @@
-#summary Procedure for Melange Code Review.
-#labels Contents-Draft
-
-= Requirements =
-
-All commits and must be reviewed by at least one Melange engineer other than the author before migration to the master branch.
-
-= Author Process =
-
-When you feel that your current line of development is ready for review:
-  # If master has advanced beyond where it was when you started your development, pull the current head of master and merge master's changes with yours.
-  # Push your line of development to a branch in the origin repository.
-  # Ask another Melange engineer to review every unreviewed commit in your branch.
-  # Make changes and re-push to your branch, and secure re-review as necessary.
-  # When every commit on your branch has been reviewed (positively), push the (reviewed) head commit of your development branch to master, taking care to make no additional changes.
-  # Prune your development branch if it will see no further use.
-
-= Sample Author Commands =
-
-== Pulling from origin ==
-{{{git pull --no-rebase --no-commit}}}
-
-Without the --no-commit flag, a pull operation that requires a commit will get an auto-created commit with an auto-generated log message like "Merge branch page-fix". Because our branch names are ephemeral we suppress the auto-created commit so that we may give any merge commit a message that describes the substance of what is being merged.
-
-== Pushing commits to a branch for review ==
-{{{git push origin <hex string of commit to be reviewed>:<review branch name>}}}
-
-== Pushing reviewed commits to master ==
-{{{git push origin <latest reviewed commit hex string, not branch name or other alias>:master}}}
-
-This will either push your specific reviewed commits to master or fail as non-fast-forward (in which case you'll have to merge and undergo further review).
-
-= Rebase =
-
-*Do not rebase.* Rebases cause us to lose review history and chronological ordering of our work. A falsely linear history just isn't worth it.
-
-= Reviewer Process =
-If a change looks good and needs no comment, just mark it positive and hit the "submit" button. This suppresses the per-commit email thread and cuts down on mailing list noise.
-
-= Exceptions =
-
-Commits made as part of the release process ("Set new Melange version number...") are exempt and may be made on master. They should still be reviewed when convenient, though.
\ No newline at end of file