iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Remove Barry's & Jeremy's email address from the Authors: header (note 

to other PEP authors -- it is okay now to omit your email address from
this header, although we will be obscuring it soon).

Also, use peps@python.org as the PEP editor contact address instead of
Barry's personal address.

Remove Guido's email address.

Other updates explaining where address obscuring takes place and where
it doesn't.

Updated the Emacs file local variable section.
This commit is contained in:
Barry Warsaw 2002-05-28 15:20:17 +00:00
parent 6544b4f3bf
commit 732c0ece30
1 changed files with 33 additions and 26 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

59
pep-0001.txt
View File

@ -2,8 +2,7 @@ PEP: 1
Title: PEP Purpose and Guidelines
Version: $Revision$
Last-Modified: $Date$
Author: barry@zope.com (Barry A. Warsaw),
jeremy@zope.com (Jeremy Hylton)
Author: Barry A. Warsaw, Jeremy Hylton
Status: Active
Type: Informational
Created: 13-Jun-2000
@ -42,7 +41,7 @@ Kinds of PEPs
PEP Work Flow
The PEP editor, Barry Warsaw <barry@zope.com>, assigns numbers
The PEP editor, Barry Warsaw <peps@python.org>, assigns numbers
for each PEP and changes its status.
The PEP process begins with a new idea for Python. It is highly
@ -61,9 +60,9 @@ PEP Work Flow
into the Python development work flow with a patch submission to
the SourceForge patch manager[2] or feature request tracker[3].
The PEP champion then emails the PEP editor with a proposed title
and a rough, but fleshed out, draft of the PEP. This draft must
be written in PEP style as described below.
The PEP champion then emails the PEP editor <peps@python.org> with
a proposed title and a rough, but fleshed out, draft of the PEP.
This draft must be written in PEP style as described below.
If the PEP editor approves, he will assign the PEP a number, label
it as standards track or informational, give it status 'draft',
@ -71,9 +70,9 @@ PEP Work Flow
editor will not unreasonably deny a PEP. Reasons for denying PEP
status include duplication of effort, being technically unsound,
or not in keeping with the Python philosophy. The BDFL
(Benevolent Dictator for Life, Guido van Rossum
<guido@python.org>) can be consulted during the approval phase,
and is the final arbitrator of the draft's PEP-ability.
(Benevolent Dictator for Life, Guido van Rossum) can be consulted
during the approval phase, and is the final arbitrator of the
draft's PEP-ability.
The author of the PEP is then responsible for posting the PEP to
the community forums, and marshaling community support for it. As
@ -93,12 +92,11 @@ PEP Work Flow
PEP before submitting it for review. A PEP that has not been
discussed on python-list@python.org and/or python-dev@python.org
will not be accepted. However, wherever possible, long open-ended
discussions on public mailing lists should be avoided. A better
strategy is to encourage public feedback be sent directly to the
PEP author during the early draft phases, who collects and
integrates the comments back into the PEP. Before code is
committed to CVS in a non-experimental way though, discussion must
be moved back to the python-dev and/or python-list mailing lists.
discussions on public mailing lists should be avoided. Strategies
to keep the discussions efficient include, setting up a separate
SIG mailing list for the topic, having the PEP author accept
private comments in the early design phases, etc. PEP authors
should use their discretion here.
Once the authors have completed a PEP, they must inform the PEP
editor that it is ready for review. PEPs are reviewed by the BDFL
@ -140,15 +138,15 @@ What belongs in a successful PEP?
1. Preamble -- RFC822 style headers containing meta-data about the
PEP, including the PEP number, a short descriptive title
(limited to a maximum of 44 characters), the names contact info
for each author, etc.
(limited to a maximum of 44 characters), the names, and
optionally the contact info for each author, etc.
2. Abstract -- a short (~200 word) description of the technical
issue being addressed.
3. Copyright/public domain -- Each PEP must either be explicitly
labelled in the public domain or the Open Publication
License[4].
labelled as placed in the public domain (see this PEP as an
example) or licensed under the Open Publication License[4].
4. Specification -- The technical specification should describe
the syntax and semantics of any new language feature. The
@ -194,7 +192,7 @@ PEP Template
Title: <pep title>
Version: <cvs version string>
Last-Modified: <cvs date string>
Author: <list of authors' email and real name>
Author: <list of authors' real names and optionally, email addrs>
* Discussions-To: <email address>
Status: <Draft | Active | Accepted | Deferred | Final | Replaced>
Type: <Informational | Standards Track>
@ -205,14 +203,20 @@ PEP Template
* Replaces: <pep number>
* Replaced-By: <pep number>
The Author: header lists the email addresses and names of all the
authors/owners of the PEP. The format of the author entry should
be
The Author: header lists the names and optionally, the email
addresses of all the authors/owners of the PEP. The format of the
author entry should be
address@dom.ain (Random J. User)
and if there are multiple authors, each should be on a separate
line following RFC 822 continuation line conventions.
if the email address is included, and just
Random J. User
if the address is not given. If there are multiple authors, each
should be on a separate line following RFC 822 continuation line
conventions. Note that personal email addresses in PEPs will be
obscured as a defense against spam harvesters.
Standards track PEPs must have a Python-Version: header which
indicates the version of Python that the feature will be released
@ -223,7 +227,8 @@ PEP Template
list or URL where the PEP is being discussed. No Discussions-To:
header is necessary if the PEP is being discussed privately with
the author, or on the python-list or python-dev email mailing
lists.
lists. Note that email addresses in the Discussions-To: header
will not be obscured.
Created: records the date that the PEP was assigned a number,
while Post-History: is used to record the dates of when new
@ -365,4 +370,6 @@ Copyright
Local Variables:
mode: indented-text
indent-tabs-mode: nil
sentence-end-double-space: t
fill-column: 70
End: