Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closes #38 #116

Merged
merged 5 commits into from
Oct 15, 2016
Merged

Closes #38 #116

Changes from 2 commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
352ac9e
Closes #38
warsaw Oct 13, 2016
aa71e3e
Updated workflow.
warsaw Oct 13, 2016
23fe9d7
Respond to review.
warsaw Oct 13, 2016
a270f71
Merge branch 'master' into issue38.
warsaw Oct 14, 2016
92ee2d0
s/clone/fork/
warsaw Oct 14, 2016
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
119 changes: 68 additions & 51 deletions pep-0001.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -92,15 +92,14 @@ details. The current editors are:
* Guido van Rossum
* Barry Warsaw

PEP editorship is by invitation of the current editors. The address
<[email protected]> is a mailing list for contacting the PEP editors. All
email related to PEP administration (such as requesting a PEP number
or providing an updated version of a PEP for posting) should be sent to
this address (no cross-posting please).
PEP editorship is by invitation of the current editors, and they can be
contacted via the address <[email protected]>, but you may only need to use this
to contact the editors semi-privately. All of the PEP workflow can be
conducted via the GitHub `PEP repository`_ issues and pull requests.


Submitting a PEP
----------------
Start with an idea for Python
-----------------------------

The PEP process begins with a new idea for Python. It is highly
recommended that a single PEP contain a single key proposal or new
Expand All @@ -111,13 +110,13 @@ PEP, the more successful it tends to be. The PEP editors reserve the
right to reject PEP proposals if they appear too unfocused or too
broad. If in doubt, split your PEP into several well-focused ones.

Each PEP must have a champion -- someone who writes the PEP using the
style and format described below, shepherds the discussions in the
appropriate forums, and attempts to build community consensus around
the idea. The PEP champion (a.k.a. Author) should first attempt to
ascertain whether the idea is PEP-able. Posting to the
comp.lang.python newsgroup (a.k.a. [email protected] mailing
list) or the python-ideas mailing list is the best way to go about this.
Each PEP must have a champion -- someone who writes the PEP using the style
and format described below, shepherds the discussions in the appropriate
forums, and attempts to build community consensus around the idea. The PEP
champion (a.k.a. Author) should first attempt to ascertain whether the idea is
PEP-able. Posting to the comp.lang.python newsgroup
(a.k.a. [email protected] mailing list) or the [email protected]
mailing list is the best way to go about this.

Vetting an idea publicly before going as far as writing a PEP is meant
to save the potential author time. Many ideas have been brought
Expand All @@ -136,35 +135,46 @@ python-ideas. This gives the author a chance to flesh out the draft
PEP to make properly formatted, of high quality, and to address
initial concerns about the proposal.

Following a discussion on python-ideas, the proposal should be sent as a
draft PEP to the PEP editors <[email protected]>. The draft must be written
in PEP style as described below, else it will be sent back without further
regard until proper formatting rules are followed (although minor errors
will be corrected by the editors).

If the PEP editors approve, they will assign the PEP a number, label it
as Standards Track, Informational, or Process, give it status "Draft",
and create and check-in the initial draft of the PEP. The PEP editors
will not unreasonably deny a PEP. Reasons for denying PEP status
include duplication of effort, being technically unsound, not
providing proper motivation or addressing backwards compatibility, or
not in keeping with the Python philosophy. The BDFL can be consulted
during the approval phase, and is the final arbiter of the draft's
PEP-ability.

Developers with git push privileges for the `PEP repository`_ may claim
PEP numbers directly by creating and committing a new PEP. When doing so,
the developer must handle the tasks that would normally be taken care of by
the PEP editors (see `PEP Editor Responsibilities & Workflow`_). This
includes ensuring the initial version meets the expected standards for
submitting a PEP. Alternately, even developers may choose to submit PEPs
through the PEP editors. When doing so, let the PEP editors know you have
git push privileges and they can guide you through the process of updating
the PEP repository directly.

Submitting a PEP
----------------

Following a discussion on python-ideas, the proposal should be submitted as a
draft PEP via a `GitHub pull request`_. The draft must be written in PEP
style as described below, else it will fail review immediately (although minor
errors may be corrected by the editors).

The standard PEP workflow is:

* You, the PEP author, clones the `PEP repository`_, and create a file named
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typical GitHub terminology here would be to "fork the PEP repository on GitHub"

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ncoghlan I was sticking with git terminology, but I'm okay with using GitHub terminology. Just don't even get me started between "pull requests" and "merge requests"!

`pep-xxxx.rst` that contains your new PEP. Use "XXX" as your draft PEP
Copy link
Member

@berkerpeksag berkerpeksag Oct 13, 2016 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pep-xxxx.rst or pep-0xxx.rst

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By the way, python.org's PEP importer doesn't notice the .rst extension at the moment. I'm planning to fix it this weekend.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the markup fix. I'll apply that and push it.

As for .rst - should I change it to .txt or keep it know that you're going to make it all better? :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We'd like the .rst extension to work so that PEPs render nicely in the GitHub UI: #1

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't want to block this because of python.org. I'd say keep it as-is. I've already wrote the code so I just need a couple of hours to write a unit test and cleanup the code :)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool, we'll keep .rst then.

number.
* Push this to your GitHub clone and submit a pull request.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/clone/fork

* The PEP editors review your PR for structure, formatting, and other errors.
* Once approved, they will assign your PEP a number, and label it as Standards
Track, Informational, or Process, and give it the status "Draft"

Once the review process is complete, and the PEP editors approve it (note that
this is *not* the same as accepting your PEP!), they will squash commit your
pull request onto master.

The PEP editors will not unreasonably deny a PEP. Reasons for denying PEP
status include duplication of effort, being technically unsound, not providing
proper motivation or addressing backwards compatibility, or not in keeping
with the Python philosophy. The BDFL can be consulted during the approval
phase, and is the final arbiter of the draft's PEP-ability.

Developers with git push privileges for the `PEP repository`_ may claim PEP
numbers directly by creating and committing a new PEP. When doing so, the
developer must handle the tasks that would normally be taken care of by the
PEP editors (see `PEP Editor Responsibilities & Workflow`_). This includes
ensuring the initial version meets the expected standards for submitting a
PEP. Alternately, even developers may choose to submit PEPs via pull request.
When doing so, let the PEP editors know you have git push privileges and they
can guide you through the process of updating the PEP repository directly.

As updates are necessary, the PEP author can check in new versions if they
(or a collaborating developer) have git push privileges, or else they can
email new PEP versions to the PEP editors for publication.
(or a collaborating developer) have git push privileges.

After a PEP number has been assigned, a draft PEP may be discussed further on
python-ideas (getting a PEP number assigned early can be useful for ease of
Expand Down Expand Up @@ -490,19 +500,22 @@ direction of the PEP. One aim of the PEP process is to try to build
consensus around a PEP, but if that's not possible, an author can always
submit a competing PEP.

If you are interested in assuming ownership of a PEP, send a message
asking to take over, addressed to both the original author and the PEP
editors <[email protected]>. If the original author doesn't respond to
email in a timely manner, the PEP editors will make a unilateral
decision (it's not like such decisions can't be reversed :).
If you are interested in assuming ownership of a PEP, you can also do this via
pull request. Clone the git repository, make your ownership modification, and
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/clone/fork/

submit a pull request. You should also send a message asking to take over,
addressed to both the original author and the PEP editors <[email protected]>.
If the original author doesn't respond to email in a timely manner, the PEP
editors will make a unilateral decision (it's not like such decisions can't be
reversed :).


PEP Editor Responsibilities & Workflow
======================================

A PEP editor must subscribe to the <[email protected]> list. All
correspondence related to PEP administration should be sent (or forwarded) to
<[email protected]> (but please do not cross-post!).
A PEP editor must subscribe to the <[email protected]> list and must watch the
`PEP repository`_. Most correspondence regarding PEP administration can be
handled through GitHub issues and pull requests, but you may also use
<[email protected]> for semi-private discussions. Please do not cross-post!

For each new PEP that comes in an editor does the following:

Expand Down Expand Up @@ -549,8 +562,9 @@ Once the PEP is ready for the repository, a PEP editor will:
* Send email back to the PEP author with next steps (post to
python-list & -dev).

Updates to existing PEPs also come in to [email protected]. Many PEP
authors are not Python committers yet, so PEP editors do the commits for them.
Updates to existing PEPs should be submitted as a `GitHub pull request`_.
Questions may of course still be sent to <[email protected]>. Many PEP authors
are not Python committers yet, so PEP editors do the commits for them.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can remove the last sentence since we don't commit their updates for them anymore.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1


Many PEPs are written and maintained by developers with write access
to the Python codebase. The PEP editors monitor the python-checkins
Expand All @@ -572,6 +586,7 @@ Resources:
* `Frequently Asked Questions for Developers
<http://docs.python.org/devguide/faq.html>`_


References and Footnotes
========================

Expand Down Expand Up @@ -605,6 +620,8 @@ References and Footnotes

.. _PEP repository: https://github.com/python/peps

.. _`GitHub pull request`: https://github.com/python/peps/pulls


Copyright
=========
Expand Down