diff --git a/PatchReviewProcess.md b/PatchReviewProcess.md
index e6438e7..c37b49e 100644
--- a/PatchReviewProcess.md
+++ b/PatchReviewProcess.md
@@ -30,10 +30,6 @@ Here is the overall process for patch review.  For technical tips, see below.
   4. If you understand the patch and find no errors or omissions then write a comment on the ticket saying that you reviewed it, remove the keyword "review-needed", add the keyword "reviewed" and assign it to someone with repository write access (currently 'zooko', 'warner' and 'davidsarah'). We'll commit it to trunk.
   5. Feel good about yourself.  Thank you for helping with our little project attempting to improve the world!
 
-# Design reviews
-
-To request a design review, explain your design (with or without a patch) and then add the [design-review-needed]query:keywords~=design-review-needed&status=!closed&group=milestone tag. Completion of a design review will normally not directly result in a patch being committed. The main goal of a design review is to give the person working on the ticket confidence that there are no show-stopping issues with the approach they are taking, and to get feedback on smaller issues that are useful to take into account before doing further work on a patch.
-
 # Advanced
 
 Once you decide that you like reviewing tickets and you get into the habit of doing it frequently, then read this essay by Jonathan Lange on how to do it well: [Your Code Sucks and I Hate You: The Social Dynamics of Code Reviews](http://mumak.net/stuff/your-code-sucks.html).
@@ -48,7 +44,7 @@ Please suggest improvements here if you run into technical snags while reviewing
 
 ## Ticket attachment links
 
-Attachments in a ticket have two links, a name, which points to an html page with prettification, and a raw download link.  You can save the download link (such as by `wget`) and use `darcs apply` to configure your repository to test a particular patch.
+Attachments in a ticket have two links, a name, which points to an html page with prettification, and a raw download link.  You can save the download link (such as by `wget`) and use `darcs apply` to configure your repository to test a particular patch. Note that you do not *have* to apply a patch to your local repository or test it in order to review it—often just reading the prettified version on the web is sufficient.
 
 For the #1149 ticket, for example, there are two links for the attachment named "test-for-webopen.darcs.patch":