diff --git a/pep-3000.txt b/pep-3000.txt
new file mode 100644
index 000000000..4af84b417
--- /dev/null
+++ b/pep-3000.txt
@@ -0,0 +1,105 @@
+PEP: 3000
+Title: Python 3000
+Version: $Revision$
+Last-Modified: $Date$
+Author: Guido van Rossum <guido@python.org>
+Status: Active
+Type: Process
+Content-Type: text/x-rst
+Created: 05-Apr-2006
+Post-History: 
+
+
+Abstract
+========
+
+This PEP sets guidelines for Python 3000 development.  Ideally, we
+first agree on the process, and start discussing features only after
+the process has been decided and specified.  In practice, we'll be
+discussing features and process simultaneously; often the debate about
+a particular feature will prompt a process discussion.
+
+
+Naming
+======
+
+Python 3000, Python 3.0 and Py3K are all names for the same thing.
+The project is called Python 3000, or abbreviated to Py3K.  The actual
+Python binary, once it is released, will be named Python 3.0.
+
+
+PEP Numbering
+=============
+
+Python 3000 PEPs are numbered starting at PEP 3000.  PEPs 3000-3099
+are meta-PEPs -- these can be either process or informational PEPs.
+PPEs 3100-3999 are feature PEPs.  PEP 3000 itself (this PEP) is
+special; it is the meta-PEP for Python 3000 meta-PEPs (IOW it describe
+the process to define processes).  PEP 3100 is also special; it's a
+laundry list of features that were selected for (hopeful) inclusion in
+Python 3000 before we started the Python 3000 process for real.  PEP
+3099, finally, is a list of features that will *not* change.
+
+
+Timeline
+========
+
+We need a meta-PEP for the Python 3000 timeline.  At this moment, I
+hope to have a first alpha release out sometime in 2007; it may take
+another year after that (or more) before the first proper release,
+named Python 3.0.
+
+I expect that there will be parallel Python 2.x and 3.x releases for
+some time; the Python 2.x releases will continue for a longer time
+than the traditional 2.x.y bugfix releases.  Typically, we stop
+releasing bugfix versions for 2.x once version 2.(x+1) has been
+released.  But I expect there to be at least one or two new 2.x
+releases even after 3.0 (final) has been released, probably well into
+3.1 or 3.2.  This will to some extend depend on community demand for
+continued 2.x support, acceptance and stability of 3.0, and volunteer
+stamina.
+
+It's quite possible that Python 3.1 and 3.2 will be released much
+sooner after 3.0 than has been customary for the 2.x series.  The 3.x
+release pattern will stabilize once the community is happy with 3.x.
+
+
+Compatibility and Transition
+============================
+
+We need a meta-PEP to describe the compatibility requirements.  Python
+3000 will break backwards compatibility.  There is no requirement that
+Python 2.9 code will run unmodified on Python 3.0.  I'm not sure
+whether it is reasonable to require that Python 2.x code can be
+mechanically translated to equivalent Python 3.0 code; Python's
+dynamic typing combined with the plans to change the semantics of
+certain methods of dictionaries, for example, would make this task
+really hard.  However, it would be great if there was some tool that
+did at least an 80% job of translation, pointing out areas where it
+wasn't sure using comments or warnings.  Perhaps such a tool could be
+based on something like Pychecker.
+
+
+Meta-Contributions
+==================
+
+Suggestions for additional text for this PEP are gracefully accepted
+by the author.  Draft meta-PEPs for the topics above and additional
+topics are even more welcome!
+
+
+Copyright
+=========
+
+This document has been placed in the public domain.
+
+
+
+..
+   Local Variables:
+   mode: indented-text
+   indent-tabs-mode: nil
+   sentence-end-double-space: t
+   fill-column: 70
+   coding: utf-8
+   End: