some proposal fixes, mostly cosmetic

svn:r9551

1 files changed, 9 insertions, 9 deletions

diff --git a/proposals/001-process.txt b/proposals/001-process.txt
index 418a5b8..2ece64f 100644
--- a/proposals/001-process.txt
+++ b/proposals/001-process.txt
@@ -25,7 +25,7 @@ Motivation:
 
    First, even at its most efficient, the old process would often have the
    spec out of sync with the code.  The worst cases were those where
-   implementation was deferred: the spec and could stay out of sync for
+   implementation was deferred: the spec and code could stay out of sync for
    versions at a time.
 
    Second, it was hard to participate in discussion, since you had to know
@@ -55,12 +55,12 @@ How to change the specs now:
    remain the canonical documentation for the Tor protocol: no proposal is
    ever the canonical documentation for an implemented feature.
 
-   {It's still okay to make mall changes to the spec if the code can be
+   {It's still okay to make small changes to the spec if the code can be
    written more or less immediately, or cosmetic changes if no code change is
    required.  This document reflects the current developers' _intent_, not
    a permanent promise to always use this process in the future: we reserve
    the right to get really excited and run off and implement something in a
-   caffeine-and-m&m-fueled all-night hacking session.}
+   caffeine-or-m&m-fueled all-night hacking session.}
 
 Proposal status:
 
@@ -105,11 +105,11 @@ What should go in a proposal:
    The body of the proposal should start with an Overview section explaining
    what the proposal's about, what it does, and about what state it's in.
 
-   After the Overview, the proposal becomes more free-form.  Depending its
+   After the Overview, the proposal becomes more free-form.  Depending on its
    the length and complexity, the proposal can break into sections as
    appropriate, or follow a short discursive format.  Every proposal should
    contain at least the following information before it can be "ACCEPTED",
-   thought the information does not need to be in sections with these names.
+   though the information does not need to be in sections with these names.
 
       Motivation: What problem is the proposal trying to solve?  Why does
         this problem matter?  If several approaches are possible, why take this
@@ -122,7 +122,7 @@ What should go in a proposal:
         Motivation and a Design, and wait for a specification until the
         Design seems approximately right.
 
-      Security implications: What effects might the proposed changes have on
+      Security implications: What effects the proposed changes might have on
         anonymity, how well understood these effects are, and so on.
 
       Specification: A detailed description of what needs to be added to the
@@ -134,9 +134,9 @@ What should go in a proposal:
 
       Compatibility: Will versions of Tor that follow the proposal be
         compatible with versions that do not?  If so, how will compatibility
-        me achieved?  Generally, we try to not to drop compatibility if at
-        all possible; we haven't made a "flag day" change since 2003 or
-        earlier, and we don't want to do another one.  [XXX is this true?]
+        be achieved?  Generally, we try to not drop compatibility if at
+        all possible; we haven't made a "flag day" change since May 2004,
+        and we don't want to do another one.
 
       Implementation: If the proposal will be tricky to implement in Tor's
         current architecture, the document can contain some discussion of how