https://bitbucket.org/rirror/peps

PEP repository readme lacks information about how to send Python Enhancement Proposal step-by-step.

1. hg clone https://bitbucket.org/rirror/peps
2. cd peps
3. # choose number
4. cp ??? pep-{{number}}.txt
5. # commit
6. # send pull request
7. # discuss

The process is well explained in the PEP templates right at the top of the PEP list:

http://www.python.org/dev/peps/pep-0009/
http://www.python.org/dev/peps/pep-0012/

New PEP authors should get in touch with experienced core developers or mentors in order to get assistance.

> PEP process entrypoint

Do you work with developers of the distutils-* objects? It looks like Daniel Holth works on such PEP for example:
https://mail.python.org/pipermail/distutils-sig/2013-July/021854.html

You may join this mailing list:
https://mail.python.org/mailman/listinfo/distutils-sig

The "entrypoint" here means the point of entry for new Python Enhancement Proposals. Christian, what you propose is a 4th order link for someone who knows what PEPs are, and clones PEP repository to submit own proposal.

What I propose it to make PEP repository self-sufficient, so that person who cloned it, can immediately get to work. You can argue that people who don't have time to read on all previous stuff, should not write PEPs, but I'd object that it is good to be inclusive.

Anatoly, please read http://www.python.org/dev/peps/pep-0012/

The process you are describing is not correct. In particular, the discussion happens before sending in a pull request.

As for discussion of the PEP process: that should happen on python-dev, not in some ticket in the tracker.

Closing the ticket again.

> The process you are describing is not correct. In particular, the discussion happens before sending in a pull request.

Post the link to correct process into README.rst and then this issue can be closed.

As for python-dev, I thought it is too obvious and minor issue (still issue) to raise there, so it is just a matter of somebody with knowledge, time and commit privileges to commit the patch. It may worth to raise the question there anyway as I see that communicating usability concerns is a big problem.

The ticket has been closed by two people. Why do you keep re-opening the ticket?

On 28.11.2013 15:45, anatoly techtonik wrote:
> 
> anatoly techtonik added the comment:
> 
>> The process you are describing is not correct. In particular, the discussion happens before sending in a pull request.
> 
> Post the link to correct process into README.rst and then this issue can be closed.

The repo readme is not the right place for this. Christian already mentioned
the PEPs and anything should go into the dev guide.

If you have something to contribute, please open a ticket, add a patch
and request review.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

> The ticket has been closed by two people. Why do you keep re-opening the ticket?

Because you're not providing any arguments. If it is not important for you, just ignore. If something is not clear - ask. What you do is just closing the stuff, because you _feel_ that is not an issue. Provide rationale, address my points and then I'll close it myself. The particular stuff that is not clarified:

>> Post the link to correct process into README.rst and then this
>> issue can be closed.
> The repo readme is not the right place for this. Christian already
> mentioned the PEPs and anything should go into the dev guide.

I want to know why PEPs repository README is not the place to direct users to starting point for submitting enhancement proposals?

> If you have something to contribute, please open a ticket, add a patch
and request review.

I am already keep opening it, damn. I want to contribute an improvement for the PEP process and not forget about it. That's why I fill in into tracker, and not into email.

Anatoly, please stop reopening the issue, it's *really* annoying. Not
only you failed to understand correctly your problem (it looks like
nor Christian nor Marc-Andre nor me understood your request), but it
looks like you don't care of our answers.

> PEP repository readme lacks information about how to send Python Enhancement Proposal step-by-step.

Did you at least read the *first* PEP, the PEP which describes the PEP process?
http://www.python.org/dev/peps/pep-0001/

Did you also read the developer guide? The PEP process is also explained there:
http://docs.python.org/devguide/langchanges.html#pep-process

> What I propose it to make PEP repository self-sufficient,

The PEP 1, 9 and 12 are already included in the PEP repository.

I don't understand why you are focused on the README.rst file. PEPs
are more convinient because automatically exported online at:
http://www.python.org/dev/peps/

For example, you must read:
http://www.python.org/dev/peps/pep-0001/

> I am already keep opening it, damn. I want to contribute an improvement for the PEP process and not forget about it. That's why I fill in into tracker, and not into email.

The PEP process is already well described, so your issue is invalid.

You don't propose anything concrete. Example of concrete thing: a
patch on the pep-0001.rst or on README.rst. Or contribute to the
devguide.

Did you sign the contributor agreement?
http://docs.python.org/devguide/coredev.html#sign-a-contributor-agreement

I know that you don't want to sign it, even if I don't understand why
(please don't start discuss it here, the legal mailing list is the
right place), but it's required to contribute to CPython.

--

The PEP process is not so formal. Just start discussing an idea on
python-idea, don't worry of the exact structure of a PEP document. It
can be written later. It is a waste of time to write a full PEP if an
idea is quickly rejected.

Closing for the hopefully final time.  Anatoly, if you keep reopening this ticket you have to expect removal of tracker privileges.

New changeset 34cb64cdbf7b by Guido van Rossum in branch 'default':
Add brief explanation and web pointers to README.txt. Fixes issue 19822.
http://hg.python.org/peps/rev/34cb64cdbf7b