EEP: 2
Title: Sample Plaintext PEP Template
Version: $Revision$
Last-Modified: $Date$
Author: Per Gustafsson <pergu(at)it(dot)uu(dot)se>
Status: Final/R-33 Replaced by EEP 33
Type: Process
Content-Type: text/plain
Created: 14-Aug-2001
Post-History:
Replaced-By: 33
Abstract
This EEP provides a boilerplate or sample template for creating
your own plaintext EEPs. In conjunction
with the content guidelines in EEP 1 [1], this should make it easy
for you to conform your own EEPs to the format outlined below.
Note: if you are reading this EEP via the web, you should first
grab the plaintext source of this EEP in order to complete the
steps below. DO NOT USE THE HTML FILE AS YOUR TEMPLATE!
If you would prefer to use lightweight markup in your EEP, please
see EEP 3, "Sample reStructuredText EEP Template" [2].
This document is based on PEP 9 [3].
Rationale
EEP submissions come in a wide variety of forms, not all adhering
to the format guidelines set forth below. Use this template, in
conjunction with the content guidelines in EEP 1, to ensure that
your EEP submission won't get automatically rejected because of
form.
How to Use This Template
To use this template you must first decide whether your EEP is
going to be an Informational or Standards Track EEP. Most EEPs
are Standards Track because they propose a new feature for the
Erlang language or standard library. When in doubt, read EEP 1
for details or contact the EEP editors <eeps@erlang.org>.
Once you've decided which type of EEP yours is going to be, follow
the directions below.
- Make a copy of this file (.txt file, not HTML!) and perform the
following edits.
- Replace the "EEP: 2" header with "EEP: XXX" since you don't yet
have an EEP number assignment.
- Change the Title header to the title of your EEP.
- Leave the Version and Last-Modified headers alone; we'll take
care of those when we check your EEP into the Subversion
repository. These headers consist of keywords ("Revision" and
"Date" enclosed in "$"-signs) which are automatically expanded
by the repository. Please do not edit the expanded date or
revision text.
- Change the Author header to include your name, and optionally
your email address. Be sure to follow the format carefully:
your name must appear first, and it must not be contained in
parentheses. Your email address may appear second (or it can be
omitted) and if it appears, it must appear in angle brackets.
It is okay to obfuscate your email address.
- If there is a mailing list for discussion of your new feature,
add a Discussions-To header right after the Author header. You
should not add a Discussions-To header if the mailing list to be
used is erlang-questions@erlang.org, or if discussions should be
sent to you directly. Most Informational EEPs don't have a
Discussions-To header.
- Change the Status header to "Draft".
- For Standards Track EEPs, change the Type header to "Standards
Track".
- For Informational EEPs, change the Type header to
"Informational".
- For Standards Track EEPs, if your feature depends on the
acceptance of some other currently in-development EEP, add a
Requires header right after the Type header. The value should
be the EEP number of the EEP yours depends on. Don't add this
header if your dependent feature is described in a Final EEP.
- Change the Created header to today's date. Be sure to follow
the format carefully: it must be in dd-mmm-yyyy format, where
the mmm is the 3 English letter month abbreviation, e.g. one of
Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec.
- For Standards Track EEPs, after the Created header, add a
Erlang-Version header and set the value to the next planned
version of Erlang, i.e. the one your new feature will hopefully
make its first appearance in. Thus, if the last version of
Erlang/OTP was R11B-3 and you're hoping to get your new feature
into R11B-4 set the version header to:
Erlang-Version: R11B-4
- Leave Post-History alone for now; you'll add dates to this
header each time you post your EEP to
erlang-questions@erlang.org. E.g. if you posted your EEP to the
list on August 14, 2006 and September 3, 2006, the Post-History
header would look like:
Post-History: 14-Aug-2006, 03-Sept-2006
You must manually add new dates and check them in. If you don't
have check-in privileges, send your changes to the EEP editor.
- Add a Replaces header if your EEP obsoletes an earlier EEP. The
value of this header is the number of the EEP that your new EEP
is replacing. Only add this header if the older EEP is in
"final" form, i.e. is either Accepted, Final, or Rejected. You
aren't replacing an older open EEP if you're submitting a
competing idea.
- Now write your Abstract, Rationale, and other content for your
EEP, replacing all this gobbledygook with your own text. Be sure
to adhere to the format guidelines below, specifically on the
prohibition of tab characters and the indentation requirements.
- Update your References and Copyright section. Usually you'll
place your EEP into the public domain, in which case just leave
the "Copyright" section alone. Alternatively, you can use the
Open Publication License[4], but public domain is still strongly
preferred.
- Leave the little Emacs turd at the end of this file alone,
including the formfeed character ("^L", or \f).
- Send your EEP submission to the EEP editors (eeps@erlang.org),
(Funny Joke removed :)
Plaintext EEP Formatting Requirements
EEP headings must begin in column zero and the initial letter of
each word must be capitalized as in book titles. Acronyms should
be in all capitals. The body of each section must be indented 4
spaces. Code samples inside body sections should be indented a
further 4 spaces, and other indentation can be used as required to
make the text readable. You must use two blank lines between the
last line of a section's body and the next section heading.
You must adhere to the Emacs convention of adding two spaces at
the end of every sentence. You should fill your paragraphs to
column 70, but under no circumstances should your lines extend
past column 79. If your code samples spill over column 79, you
should rewrite them.
Tab characters must never appear in the document at all. An EEP
should include the standard Emacs stanza included by example at
the bottom of this EEP.
When referencing an external web page in the body of an EEP, you
should include the title of the page in the text, with a
footnote reference to the URL. Do not include the URL in the body
text of the EEP. E.g.
Refer to the Erlang Language web site [1] for more details.
...
[1] http://www.erlang.org
When referring to another EEP, include the EEP number in the body
text, such as "EEP 1". The title may optionally appear. Add a
footnote reference, a number in square brackets. The footnote
body should include the EEP's title and author. It may optionally
include the explicit URL on a separate line, but only in the
References section. Note that the eep2html.py script will
calculate URLs automatically. For example:
...
Refer to EEP 1 [7] for more information about EEP style
...
References
[7] EEP 1, EEP Purpose and Guidelines, Gustafsson
http://www.erlang.org/eeps/eep-0001.html
If you decide to provide an explicit URL for an EEP, please use
this as the URL template:
http://www.erlang.org/eeps/eep-xxxx.html
EEP numbers in URLs must be padded with zeros from the left, so as
to be exactly 4 characters wide, however EEP numbers in the text
are never padded.
References
[1] EEP 1, EEP Purpose and Guidelines, Gustafsson
http://www.erlang.org/eeps/eep-0001.html
[2] EEP 3, Sample reStructuredText EEP Template, Gustafsson
http://www.erlang.org/eeps/eep-0003.html
[3] PEP 9, Sample Plaintext PEP Template, Warsaw
http://www.python.org/dev/peps/pep-0009/
[4] http://www.opencontent.org/openpub/
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:
