[Python-checkins] python/nondist/peps pep-0001.txt,1.33,1.34

bwarsaw@users.sourceforge.net bwarsaw@users.sourceforge.net
Tue, 28 May 2002 08:20:20 -0700


Update of /cvsroot/python/python/nondist/peps
In directory usw-pr-cvs1:/tmp/cvs-serv4265

Modified Files:
	pep-0001.txt 
Log Message:
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.


Index: pep-0001.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0001.txt,v
retrieving revision 1.33
retrieving revision 1.34
diff -C2 -d -r1.33 -r1.34
*** pep-0001.txt	18 Apr 2002 19:19:35 -0000	1.33
--- pep-0001.txt	28 May 2002 15:20:17 -0000	1.34
***************
*** 3,8 ****
  Version: $Revision$
  Last-Modified: $Date$
! Author: barry@zope.com (Barry A. Warsaw),
!     jeremy@zope.com (Jeremy Hylton)
  Status: Active
  Type: Informational
--- 3,7 ----
  Version: $Revision$
  Last-Modified: $Date$
! Author: Barry A. Warsaw, Jeremy Hylton
  Status: Active
  Type: Informational
***************
*** 43,47 ****
  PEP Work Flow
  
!     The PEP editor, Barry Warsaw <barry@zope.com>, assigns numbers
      for each PEP and changes its status.
  
--- 42,46 ----
  PEP Work Flow
  
!     The PEP editor, Barry Warsaw <peps@python.org>, assigns numbers
      for each PEP and changes its status.
  
***************
*** 62,68 ****
      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.
  
      If the PEP editor approves, he will assign the PEP a number, label
--- 61,67 ----
      the SourceForge patch manager[2] or feature request tracker[3].
  
!     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
***************
*** 72,78 ****
      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.
  
      The author of the PEP is then responsible for posting the PEP to
--- 71,77 ----
      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) 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
***************
*** 94,103 ****
      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.
  
      Once the authors have completed a PEP, they must inform the PEP
--- 93,101 ----
      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.  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
***************
*** 141,146 ****
      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.
  
      2. Abstract -- a short (~200 word) description of the technical
--- 139,144 ----
      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, and
!        optionally the contact info for each author, etc.
  
      2. Abstract -- a short (~200 word) description of the technical
***************
*** 148,153 ****
  
      3. Copyright/public domain -- Each PEP must either be explicitly
!        labelled in the public domain or the Open Publication
!        License[4].
  
      4. Specification -- The technical specification should describe
--- 146,151 ----
  
      3. Copyright/public domain -- Each PEP must either be explicitly
!        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
***************
*** 195,199 ****
          Version: <cvs version string>
          Last-Modified: <cvs date string>
!         Author: <list of authors' email and real name>
        * Discussions-To: <email address>
          Status: <Draft | Active | Accepted | Deferred | Final | Replaced>
--- 193,197 ----
          Version: <cvs version string>
          Last-Modified: <cvs date string>
!         Author: <list of authors' real names and optionally, email addrs>
        * Discussions-To: <email address>
          Status: <Draft | Active | Accepted | Deferred | Final | Replaced>
***************
*** 206,217 ****
        * 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
  
          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.
  
      Standards track PEPs must have a Python-Version: header which
--- 204,221 ----
        * Replaced-By: <pep number>
  
!     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)
  
!     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
***************
*** 224,228 ****
      header is necessary if the PEP is being discussed privately with
      the author, or on the python-list or python-dev email mailing
!     lists.
  
      Created: records the date that the PEP was assigned a number,
--- 228,233 ----
      header is necessary if the PEP is being discussed privately with
      the author, or on the python-list or python-dev email mailing
!     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,
***************
*** 366,368 ****
--- 371,375 ----
  mode: indented-text
  indent-tabs-mode: nil
+ sentence-end-double-space: t
+ fill-column: 70
  End: