diff --git a/Doc/whatsnew/whatsnew20.tex b/Doc/whatsnew/whatsnew20.tex
index 7043b58..40d7c62 100644
--- a/Doc/whatsnew/whatsnew20.tex
+++ b/Doc/whatsnew/whatsnew20.tex
@@ -18,7 +18,7 @@
 }
 
 A new release of Python, version 2.0, will be released some time this
-summer.  Beta versions are already available from
+autumn.  Beta versions are already available from
 \url{http://www.pythonlabs.com/products/python2.0/}.  This article
 covers the exciting new features in 2.0, highlights some other useful
 changes, and points out a few incompatible changes that may require
@@ -55,6 +55,92 @@
 done between May and September.  
 
 % ======================================================================
+\section{New Development Process}
+
+The most important change in Python 2.0 may not be to the code at all,
+but to how Python is developed.  
+
+In May of 2000, the Python CVS tree was moved to SourceForge.
+Previously, there were roughly 7 or so people who had write access to
+the CVS tree, and all patches had to be inspected and checked in by
+one of the people on this short list.  Obviously, this wasn't very
+scalable.  By moving the CVS tree to SourceForge, it became possible
+to grant write access to more people; as of September 2000 there were
+27 people able to check in changes, a fourfold increase.  This makes
+possible large-scale changes that wouldn't be attempted if they'd have
+to be filtered through the small group of core developers.  For
+example, one day Peter Schneider-Kamp took it into his head to drop
+K\&R C compatibility and convert the C source for Python to ANSI
+C. After getting approval on the python-dev mailing list, he launched
+into a flurry of checkins that lasted about a week, other developers
+joined in to help, and the job was done.  If there were only 5 people
+with write access, probably that task would have been viewed as
+``nice, but not worth the time and effort needed'' and it wouldn't
+never have been done.
+
+SourceForge also provides tools for tracking bug and patch
+submissions, and in combination with the public CVS tree, they've
+resulted in a remarkable increase in the speed of development.
+Patches now get submitted, commented on, revised by people other than
+the original submitter, and bounced back and forth between people
+until the patch is deemed worth checking in.  This didn't come without
+a cost: developers now have more e-mail to deal with, more mailing
+lists to follow, and special tools had to be written for the new
+environment.  For example, SourceForge sends default patch and bug
+notification e-mail messages that are completely unhelpful, so Ka-Ping
+Yee wrote an HTML screen-scraper that sends more useful messages.
+
+The ease of adding code caused a few initial growing pains, such as
+code was checked in before it was ready or without getting clear
+agreement from the developer group.  The approval process that has
+emerged is somewhat similar to that used by the Apache group.
+Developers can vote +1, +0, -0, or -1 on a patch; +1 and -1 denote
+acceptance or rejection, while +0 and -0 mean the developer is mostly
+indifferent to the change, though with a slight positive or negative
+slant.  The most significant change from the Apache model is that
+Guido van Rossum, who has Benevolent Dictator For Life status, can
+ignore the votes of the other developers and approve or reject a
+change, effectively giving him a +Infinity / -Infinity vote.
+
+Producing an actual patch is the last step in adding a new feature,
+and is usually easy compared to the earlier task of coming up with a
+good design.  Discussions of new features can often explode into
+lengthy mailing list threads, making the discussion hard to follow,
+and no one can read every posting to python-dev.  Therefore, a
+relatively formal process has been set up to write Python Enhancement
+Proposals (PEPs), modelled on the Internet RFC process.  PEPs are
+draft documents that describe a proposed new feature, and are
+continually revised until the community reaches a consensus, either
+accepting or rejecting the proposal.  Quoting from the introduction to
+PEP 1, ``PEP Purpose and Guidelines'':
+
+\begin{quotation}
+    PEP stands for Python Enhancement Proposal.  A PEP is a design
+    document providing information to the Python community, or
+    describing a new feature for Python.  The PEP should provide a
+    concise technical specification of the feature and a rationale for
+    the feature.
+
+    We intend PEPs to be the primary mechanisms for proposing new
+    features, for collecting community input on an issue, and for
+    documenting the design decisions that have gone into Python.  The
+    PEP author is responsible for building consensus within the
+    community and documenting dissenting opinions.
+\end{quotation}
+
+Read the rest of PEP 1 for the details of the PEP editorial process,
+style, and format.  PEPs are kept in the Python CVS tree on
+SourceForge, though they're not part of the Python 2.0 distribution,
+and are also available in HTML form from
+\url{http://python.sourceforge.net/peps/}.  As of September 2000,
+there are 25 PEPS, ranging from PEP 201, ``Lockstep Iteration'', to
+PEP 225, ``Elementwise/Objectwise Operators''.
+
+To report bugs or submit patches for Python 2.0, use the bug tracking
+and patch manager tools available from the SourceForge project page,
+at \url{http://sourceforge.net/projects/python/}.
+
+% ======================================================================
 \section{Unicode}
 
 The largest new feature in Python 2.0 is a new fundamental data type: