Why do i need to convince a core developer for my PEP? AFAIK the steering council can include non core developers (i know it isn't that current case but for the future this is important). And if the last authority who will approve my PEP is the steering council i just need to convince them not core developers. Sponsors can stay (and they should because guidance is important) but thy shouldn't be mandatory. Let everyone to send their peps.
On 25/07/2019 13:14, Batuhan Taskaya wrote:
Why do i need to convince a core developer for my PEP? AFAIK the steering council can include non core developers (i know it isn't that current case but for the future this is important). And if the last authority who will approve my PEP is the steering council i just need to convince them not core developers.
Sponsors can stay (and they should because guidance is important) but thy shouldn't be mandatory. Let everyone to send their peps.
Consider it this way; if you can't convince a single core developer to back your idea, your chances of getting general support, never mind the steering council, are very limited. -- Rhodri James *-* Kynesim Ltd
What i see is when you post the ideas channel and it is something that doesnt change much on the frontside people dont care. And when people dont care, they forgot. PEP reviewing process is way better than posting to ideas and try to convince people. On Thu, Jul 25, 2019 at 3:21 PM Rhodri James <rhodri@kynesim.co.uk> wrote:
On 25/07/2019 13:14, Batuhan Taskaya wrote:
Why do i need to convince a core developer for my PEP? AFAIK the steering council can include non core developers (i know it isn't that current case but for the future this is important). And if the last authority who will approve my PEP is the steering council i just need to convince them not core developers.
Sponsors can stay (and they should because guidance is important) but thy shouldn't be mandatory. Let everyone to send their peps.
Consider it this way; if you can't convince a single core developer to back your idea, your chances of getting general support, never mind the steering council, are very limited.
-- Rhodri James *-* Kynesim Ltd _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/USFGXF... Code of Conduct: http://python.org/psf/codeofconduct/
On Thu, Jul 25, 2019 at 10:34 PM Batuhan Taskaya <isidentical@gmail.com> wrote:
What i see is when you post the ideas channel and it is something that doesnt change much on the frontside people dont care. And when people dont care, they forgot. PEP reviewing process is way better than posting to ideas and try to convince people.
Then convince a core dev that your proposal is important enough to write a PEP about. If you can't do that, odds are your proposal wouldn't be accepted anyway - like Rhodri said. ChrisA
On 07/25/2019 05:31 AM, Batuhan Taskaya wrote:
What i see is when you post the ideas channel and it is something that doesnt change much on the frontside people dont care. And when people dont care, they forgot. PEP reviewing process is way better than posting to ideas and try to convince people.
If someone posts a PEP to python-dev as the first step, they will be told to take it to ideas for discussion. If someone wants to post a PEP-like document to python-ideas they are welcome to do so -- possibly the only thing lacking to make it an official PEP is the PEP number, but that can be added later once you've got the support of a core-dev. However, writing a PEP-like document is a serious investment of energy and time, and most ideas can be discarded long before with minimal discussion. -- ~Ethan~
What i see is when you post the ideas channel and it is something that doesnt change much on the frontside people dont care. And when people dont care, they forgot. PEP reviewing process is way better than posting to ideas and try to convince people.
You are proposing a change to the content of PEP 1 ( https://www.python.org/dev/peps/pep-0001/). If you look at the history of
On Thu, Jul 25, 2019 at 9:32 AM Batuhan Taskaya <isidentical@gmail.com> wrote: that PEP, you will see that its content has changed over time. It used to be that non-core developers could write PEPs that were accepted: I know this very well since I've never been a core developer and have written a PEP that was accepted (https://www.python.org/dev/peps/pep-3111/) some thirteen years ago. This was then; now, I personally do see the need to have PEPs sponsored by core developers - you obviously have a different opinion. At the very least, you should go over the history of PEP 1, and find out the discussions (on python-ideas and python-dev, as well as possibly other sources) that led to the change which you wish to revert. You might want to provide a rationale as to what such a reversion is warranted, including a summary of the arguments that led to the current situation (sponsorship required) and how the entire process would be improved by not requiring this sponsorship. Following the practice for discussions that lead to PEPs, you should also include the arguments offered by others on this list who do not appear to support such a change and explain why and how the alternative you propose is better. I assume that your underlying motivation is that you have in mind some changes to the Python language or its libraries, and that you would wish to submit a PEP without requiring a sponsor. Since core developers are responsible for implementing and supporting such changes, your suggestion to change PEP 1 should include an explanation as to how core developers would benefit from the change you propose and how allowing anyone, no matter how familiar they are with the Python code and standard library, to be able to submit PEP that would require the core developers to spend valuable time considering them seriously without the ideas included in the PEP having been discussed more casually on some public forums such as this one. André Roberge
On Thu, Jul 25, 2019 at 5:21 AM Rhodri James <rhodri@kynesim.co.uk> wrote:
On 25/07/2019 13:14, Batuhan Taskaya wrote:
Why do i need to convince a core developer for my PEP? AFAIK the steering council can include non core developers (i know it isn't that current case but for the future this is important). And if the last authority who will approve my PEP is the steering council i just need to convince them not core developers.
Sponsors can stay (and they should because guidance is important) but thy shouldn't be mandatory. Let everyone to send their peps.
Consider it this way; if you can't convince a single core developer to back your idea, your chances of getting general support, never mind the steering council, are very limited.
I'll make it even more concrete: if a single core dev won't sign off on a PEP idea then the steering council won't consider it. It should be understood that I came up with the sponsorship idea as a PEP author, core dev, and steering council member (which the steering council signed off on): - As a PEP editor because there's only so many of us and so I want PEPs to be as "done" as they can be by the time they come to the peps repo so there's less copy-editing - As a core dev because I don't want a discussion on python-dev to start until a PEP is in great shape and there won't be rehashing of previous ideas or any critical points missing - As a member of the steering council because if not a single core dev likes an idea then I'm not interested in considering a PEP because the steering council may help break stalemates but we are not about to against the entire Python core team (which is what we would be asked to do if not a single core dev wanted to back a PEP) In other words the hurdle of finding a sponsor is very deliberate.
On Thu, Jul 25, 2019 at 10:16 PM Batuhan Taskaya <isidentical@gmail.com> wrote:
Why do i need to convince a core developer for my PEP? AFAIK the steering council can include non core developers (i know it isn't that current case but for the future this is important). And if the last authority who will approve my PEP is the steering council i just need to convince them not core developers.
Sponsors can stay (and they should because guidance is important) but thy shouldn't be mandatory. Let everyone to send their peps.
A PEP shouldn't be the *first* step in a proposal - it's a document designed to gather together a lot of details, possibly arguments and counter-arguments, and the justifications for decisions. Instead, start by just writing up your idea as a python-ideas post; anyone can do that, and then if you get enough support on -ideas, you can go forward with writing a PEP, if it's even necessary. ChrisA
25.07.19 15:14, Batuhan Taskaya пише:
Why do i need to convince a core developer for my PEP? AFAIK the steering council can include non core developers (i know it isn't that current case but for the future this is important). And if the last authority who will approve my PEP is the steering council i just need to convince them not core developers.
Sponsors can stay (and they should because guidance is important) but thy shouldn't be mandatory. Let everyone to send their peps.
Only core developers have permissions to merge in the Python repositories. So you need at least one core developer on your side to make an official PEP. I hope you do not want to allow everybody to merge in the Python repositories.
On Thu, Jul 25, 2019 at 8:17 AM Batuhan Taskaya <isidentical@gmail.com> wrote:
Why do i need to convince a core developer for my PEP? AFAIK the steering council can include non core developers (i know it isn't that current case but for the future this is important). And if the last authority who will approve my PEP is the steering council i just need to convince them not core developers.
To convince a majority of the steering council and 0 core developers to make a change, you'd need a hypothetical future steering council with a non-core-developer majority. Even if we stipulate that this would ever happen (which seems exceedingly unlikely), presumably that majority would change the policy to allow themselves to sponsor PEPs. (In my opinion if there's even a single steering council member who isn't a core developer, they'd probably be able to convince the rest of the council to add a special exception allowing them to sponsor PEPs; I find it hard to imagine someone being trusted enough to sit on the council without the rest of the council thinking they can be trusted to sponsor a PEP...)
On 7/26/2019 11:21 AM, Geoffrey Spear wrote:
On Thu, Jul 25, 2019 at 8:17 AM Batuhan Taskaya <isidentical@gmail.com <mailto:isidentical@gmail.com>> wrote:
Why do i need to convince a core developer for my PEP? AFAIK the steering council can include non core developers (i know it isn't that current case but for the future this is important). And if the last authority who will approve my PEP is the steering council i just need to convince them not core developers.
To convince a majority of the steering council and 0 core developers to make a change, you'd need a hypothetical future steering council with a non-core-developer majority.
Even if we stipulate that this would ever happen (which seems exceedingly unlikely), presumably that majority would change the policy to allow themselves to sponsor PEPs.
(In my opinion if there's even a single steering council member who isn't a core developer, they'd probably be able to convince the rest of the council to add a special exception allowing them to sponsor PEPs; I find it hard to imagine someone being trusted enough to sit on the council without the rest of the council thinking they can be trusted to sponsor a PEP...)
I agree with all of these points. In addition, I find it hard to believe someone couldn't find a sponsor for a well-written PEP. I'm happy to sponsor such a PEP, even if I think it will be rejected. Rejected PEPs serve a useful purpose, too, if only to point to when the same issue comes up in the future. Just be aware that writing a PEP so that it gets to the accept/reject stage can take months of work. At least it has in my case. What you won't find is someone to sponsor a PEP that says something like "remove the GIL", without any details of how to do it. And it's good that no one would sponsor that: it's just noise! This is what the "you must have a sponsor" rule is trying to prevent. It's not trying to prevent well thought out ideas that might not get accepted. Eric
Eric V. Smith wrote:
In addition, I find it hard to believe someone couldn't find a sponsor for a well-written PEP. I'm happy to sponsor such a PEP, even if I think it will be rejected. Rejected PEPs serve a useful purpose, too, if only to point to when the same issue comes up in the future.
Do most of the other core developers also share this perspective? Even though PEPs were not intended to be intimidating, they definitely can be for those who are less familiar with the process. I can imagine that many people would think that a "sponsor" would mean fully convincing someone to be completely on board with their idea. As someone who only more recently began contributing to Python, my previous perception of PEPs were these monolithic technical documents that were well approved by the entire community. I'm slowly starting to see them more as simply being well structured proposals after having seen more of them. To many outside of the development community though, such as those proposing ideas, their impression of a PEP is probably based on the massive ones such as PEP 8. Although it was purely comical, I think PEP 401 helped me quite a lot to see them as less intimidating. PEP 581 is a good example of an actual approved one that's easily digestible.
On Sat, Jul 27, 2019 at 12:50 PM Kyle Stanley <aeros167@gmail.com> wrote:
Eric V. Smith wrote:
In addition, I find it hard to believe someone couldn't find a sponsor for a well-written PEP. I'm happy to sponsor such a PEP, even if I think it will be rejected. Rejected PEPs serve a useful purpose, too, if only to point to when the same issue comes up in the future.
Do most of the other core developers also share this perspective? Even though PEPs were not intended to be intimidating, they definitely can be for those who are less familiar with the process. I can imagine that many people would think that a "sponsor" would mean fully convincing someone to be completely on board with their idea.
As someone who only more recently began contributing to Python, my previous perception of PEPs were these monolithic technical documents that were well approved by the entire community. I'm slowly starting to see them more as simply being well structured proposals after having seen more of them.
Not a core dev, but from my perspective, PEPs are far too "iconic". People make their first posts to python-ideas under the impression that they should be writing PEPs. No, that's not the case; start with discussion (which doesn't require a sponsor), and *then* start talking about a PEP. By the time you get that far along with a proposal, either your idea has enough support for a core dev to say "yeah, I'll sponsor that" (even if s/he doesn't actually agree with the proposal), or you know you're asking for something controversial (in which case your first hurdle is to convince a core dev). ChrisA
On Sat, 27 Jul 2019 at 03:51, Kyle Stanley <aeros167@gmail.com> wrote:
Eric V. Smith wrote:
In addition, I find it hard to believe someone couldn't find a sponsor for a well-written PEP. I'm happy to sponsor such a PEP, even if I think it will be rejected. Rejected PEPs serve a useful purpose, too, if only to point to when the same issue comes up in the future.
Do most of the other core developers also share this perspective? Even though PEPs were not intended to be intimidating, they definitely can be for those who are less familiar with the process. I can imagine that many people would think that a "sponsor" would mean fully convincing someone to be completely on board with their idea.
Personally, my position is a bit more nuanced. I'm happy enough to sponsor a PEP, but most people's "PEP ideas" are actually still insufficiently well thought out to be worth a PEP, and typically my first comment as a sponsor would be "you don't need a sponsor yet, you need to refine your proposal a lot first". However, from the way a lot of threads on python-ideas go, it's clear that a lot of people aren't really aware of how much work is needed to get a proposal to the point where it's ready for a PEP (and when they get feedback to that effect from the list, they get frustrated at the "negative feedback"). So while I'm happy enough to sponsor a (well-written) PEP, I'm not anywhere near as willing to mentor someone in how to develop a proposal to the point where it's ready for submission as a PEP (because I simply don't have the time). And people tend not to appreciate the difference between those two tasks. Paul
On 7/29/19 4:33 AM, Paul Moore wrote:
On Sat, 27 Jul 2019 at 03:51, Kyle Stanley <aeros167@gmail.com> wrote:
In addition, I find it hard to believe someone couldn't find a sponsor for a well-written PEP. I'm happy to sponsor such a PEP, even if I think it will be rejected. Rejected PEPs serve a useful purpose, too, if only to point to when the same issue comes up in the future. Do most of the other core developers also share this perspective? Even
Eric V. Smith wrote: though PEPs were not intended to be intimidating, they definitely can be for those who are less familiar with the process. I can imagine that many people would think that a "sponsor" would mean fully convincing someone to be completely on board with their idea. Personally, my position is a bit more nuanced. I'm happy enough to sponsor a PEP, but most people's "PEP ideas" are actually still insufficiently well thought out to be worth a PEP, and typically my first comment as a sponsor would be "you don't need a sponsor yet, you need to refine your proposal a lot first". However, from the way a lot of threads on python-ideas go, it's clear that a lot of people aren't really aware of how much work is needed to get a proposal to the point where it's ready for a PEP (and when they get feedback to that effect from the list, they get frustrated at the "negative feedback").
So while I'm happy enough to sponsor a (well-written) PEP, I'm not anywhere near as willing to mentor someone in how to develop a proposal to the point where it's ready for submission as a PEP (because I simply don't have the time). And people tend not to appreciate the difference between those two tasks.
Paul
I would say that most people don't easily understand that there is by necessity (and how much) a lot more work to change a 'Standard' that affects a lot of people vs changing the local rules for a given small group or project. With a small group, it is easy to chat with most of the users and confirm that there are no obvious problems. The small group is also much more likely homogeneous in style and application, so much easier to see what it might break. When changing something much broader, there WILL be people using it in ways you just haven't thought about, and because you likely can't talk to everyone who will be affected (they aren't all listening to the same channel) it become important to work out more of the details so people not as familiar with what you are proposing can perhaps notice issues with what you are proposing. It isn't just something about Python and PEPs, but a common problem for any large scale project. -- Richard Damon
Hi folks, one of the list admins here, my eye was caught by this ongoing discussion. I’m responding to this message out of several on this topic, because it brings up an interesting point - do we have good documents on this process that are attached to python-ideas and/or core mentoring lists? I did some googling about, and the most specific thing I found was this description of python-ideas: “”" This list is to contain discussion of speculative language ideas for Python for possible inclusion into the language. If an idea gains traction it can then be discussed and honed to the point of becoming a solid proposal to put to python-dev as appropriate. “”” which seems insufficient... Should we provide a more explicit or detailed rationale for python-ideas, based on this thread? We could make some or all of the following points — * python-ideas is for discussion of speculative ideas * the process is, (1) refine ideas here, (2) after broad acceptance of basic premise, develop an informal writeup, (3) find a core dev sponsor who will back turning this into a PEP * pointers to PEP 1, https://www.python.org/dev/peps/pep-0001/, and Python governance, https://www.python.org/dev/peps/pep-0013/ * pointers to core mentorship list, https://www.python.org/dev/core-mentorship/, and python developer documentation, https://devguide.python.org * pointers to this thread * please note that the burden for adding features to the language is high because you’re affecting so many people, increasing support burden, etc. etc. * note that everyone working on python is a volunteer, please respect their time and effort. I could try drafting something and passing it by people on this list to see what they think, but I’m wondering if I’m missing an obvious resource that I could just link to in the python-ideas description. best, —titus
On Jul 26, 2019, at 10:49 PM, Kyle Stanley <aeros167@gmail.com> wrote:
Eric V. Smith wrote:
In addition, I find it hard to believe someone couldn't find a sponsor for a well-written PEP. I'm happy to sponsor such a PEP, even if I think it will be rejected. Rejected PEPs serve a useful purpose, too, if only to point to when the same issue comes up in the future.
Do most of the other core developers also share this perspective? Even though PEPs were not intended to be intimidating, they definitely can be for those who are less familiar with the process. I can imagine that many people would think that a "sponsor" would mean fully convincing someone to be completely on board with their idea.
As someone who only more recently began contributing to Python, my previous perception of PEPs were these monolithic technical documents that were well approved by the entire community. I'm slowly starting to see them more as simply being well structured proposals after having seen more of them.
To many outside of the development community though, such as those proposing ideas, their impression of a PEP is probably based on the massive ones such as PEP 8. Although it was purely comical, I think PEP 401 helped me quite a lot to see them as less intimidating. PEP 581 is a good example of an actual approved one that's easily digestible. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/4WVJMM... Code of Conduct: http://python.org/psf/codeofconduct/
On Mon, Jul 29, 2019 at 9:51 PM C. Titus Brown <ctbrown@ucdavis.edu> wrote:
I’m responding to this message out of several on this topic, because it brings up an interesting point - do we have good documents on this process that are attached to python-ideas and/or core mentoring lists?
Documents? I don't think so.
Should we provide a more explicit or detailed rationale for python-ideas, based on this thread? We could make some or all of the following points —
That would be a great idea. Where should they be hosted? Once something along these lines exists, I would strongly recommend creating a GitHub issue template on the PEPs repo (and maybe others) that references it.
* python-ideas is for discussion of speculative ideas
* the process is, (1) refine ideas here, (2) after broad acceptance of basic premise, develop an informal writeup, (3) find a core dev sponsor who will back turning this into a PEP
* pointers to PEP 1, https://www.python.org/dev/peps/pep-0001/, and Python governance, https://www.python.org/dev/peps/pep-0013/
* pointers to core mentorship list, https://www.python.org/dev/core-mentorship/, and python developer documentation, https://devguide.python.org
* pointers to this thread
* please note that the burden for adding features to the language is high because you’re affecting so many people, increasing support burden, etc. etc.
* note that everyone working on python is a volunteer, please respect their time and effort.
I could try drafting something and passing it by people on this list to see what they think, but I’m wondering if I’m missing an obvious resource that I could just link to in the python-ideas description.
If you are missing such a resource, then so am I. Also worth including: A section of "common misconceptions" such as "there's only one way to do it" and what's meant by "refuse to guess". You mention the burden for adding features; I'd perhaps go a little broader than that and talk about the significance of backward compatibility. This seems like a great idea... and, like every other good idea that goes through this list, it's going to get a ton of bike-shedding :) ChrisA
Hosting? I suggest Python wiki Abdur-Rahmaan Janhangeer
I suggest to put this in the devguide and deep-link there from the python-ideas (and python-dev?) description. The more we have under version control the better. There shouldn't be a need for too much bikeshedding on the first iteration -- just get a simple PR (along the lines of what you wrote) up (you can ping me for review) and once it's merged you can link to it; we can then easily iterate on the contents if there seems to be a need for additional suggestions. On Mon, Jul 29, 2019 at 8:13 AM Ai mu <cryptolabour@gmail.com> wrote:
Hosting? I suggest Python wiki
Abdur-Rahmaan Janhangeer _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/NBILWW... Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him/his **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
+1 Will implement and circle back around to this list. best, --titus On Mon, Jul 29, 2019 at 08:38:22AM -0700, Guido van Rossum wrote:
I suggest to put this in the devguide and deep-link there from the python-ideas (and python-dev?) description. The more we have under version control the better. There shouldn't be a need for too much bikeshedding on the first iteration -- just get a simple PR (along the lines of what you wrote) up (you can ping me for review) and once it's merged you can link to it; we can then easily iterate on the contents if there seems to be a need for additional suggestions.
On Mon, Jul 29, 2019 at 8:13 AM Ai mu <cryptolabour@gmail.com> wrote:
Hosting? I suggest Python wiki
Abdur-Rahmaan Janhangeer _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/NBILWW... Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him/his **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/DVUIY3... Code of Conduct: http://python.org/psf/codeofconduct/
-- C. Titus Brown, ctbrown@ucdavis.edu
+1, will circle back around to this list with news. best, —titus
On Jul 29, 2019, at 11:38 AM, Guido van Rossum <guido@python.org> wrote:
I suggest to put this in the devguide and deep-link there from the python-ideas (and python-dev?) description. The more we have under version control the better. There shouldn't be a need for too much bikeshedding on the first iteration -- just get a simple PR (along the lines of what you wrote) up (you can ping me for review) and once it's merged you can link to it; we can then easily iterate on the contents if there seems to be a need for additional suggestions.
On Mon, Jul 29, 2019 at 8:13 AM Ai mu <cryptolabour@gmail.com> wrote: Hosting? I suggest Python wiki
Abdur-Rahmaan Janhangeer _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/NBILWW... Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido van Rossum (python.org/~guido) Pronouns: he/him/his (why is my pronoun here?) _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/DVUIY3... Code of Conduct: http://python.org/psf/codeofconduct/
Hi folks, sorry, took me more than a few months, but I wrote a draft of a python-ideas HOWTO here, https://hackmd.io/@-6xkuCDkTrSFptQEimAdcg/B1noEGh2H Thanks to Eric Smith and Chris Barker for their link suggestions, and Chris Angelico and Guido van Rossum for their additional thoughts in a brief off-list thread. SO. The question becomes, where do we host this? I received the strong suggestion from both Guido and Stephen Turnbull that it should be in the devguide (see quoted message from GvR below). But, when I finished this draft and went to look at the devguide repo, realized that the devguide at https://devguide.python.org/ may not be the best place to host it, because (as written) the dev guide is VERY focused on code development. I think this HOWTO is a bit more community and process oriented than the current top-level materials in the dev guide. So instead of submitting a PR, I am appealing to the list for your thoughts. The three easiest options I see are: 1. Put it on python.org, perhaps replacing the content here: https://www.python.org/dev/. I can’t figure out where that content is hosted (it’s not in https://github.com/python/pythondotorg/ !?) 2. put it in the current dev guide somewhere, just so it lands in version control. Then iterate on both it and the dev guide. My first thought would be to merge the content with this document, https://github.com/python/devguide/blob/master/langchanges.rst. 3. put it somewhere near the front of the current dev guide, and do more work to adjust the dev guide. Thoughts? Am I missing am obvious location? Should I just get on with a PR and we’ll sort it out later? :) best, —titus
On Jul 29, 2019, at 8:38 AM, Guido van Rossum <guido@python.org> wrote:
I suggest to put this in the devguide and deep-link there from the python-ideas (and python-dev?) description. The more we have under version control the better. There shouldn't be a need for too much bikeshedding on the first iteration -- just get a simple PR (along the lines of what you wrote) up (you can ping me for review) and once it's merged you can link to it; we can then easily iterate on the contents if there seems to be a need for additional suggestions.
On Mon, Jul 29, 2019 at 8:13 AM Ai mu <cryptolabour@gmail.com> wrote: Hosting? I suggest Python wiki
Abdur-Rahmaan Janhangeer _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/NBILWW... Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido van Rossum (python.org/~guido) Pronouns: he/him/his (why is my pronoun here?) _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/DVUIY3... Code of Conduct: http://python.org/psf/codeofconduct/
On 12/1/19 10:45 AM, C. Titus Brown wrote:
Hi folks,
sorry, took me more than a few months, but I wrote a draft of a python-ideas HOWTO here,
Thanks so much for writing this. I think Python-Ideas is a perfect example of something that could use an introduction, so that peoples' expectations are properly set.
Thanks to Eric Smith and Chris Barker for their link suggestions, and Chris Angelico and Guido van Rossum for their additional thoughts in a brief off-list thread.
SO. The question becomes, where do we host this?
I received the strong suggestion from both Guido and Stephen Turnbull that it should be in the devguide (see quoted message from GvR below).
But, when I finished this draft and went to look at the devguide repo, realized that the devguide at https://devguide.python.org/ may not be the best place to host it, because (as written) the dev guide is VERY focused on code development. I think this HOWTO is a bit more community and process oriented than the current top-level materials in the dev guide.
So instead of submitting a PR, I am appealing to the list for your thoughts.
The three easiest options I see are:
1. Put it on python.org, perhaps replacing the content here: https://www.python.org/dev/. I can’t figure out where that content is hosted (it’s not in https://github.com/python/pythondotorg/ !?)
To me, the audience for the Python-Ideas HOWTO is very different than for /dev/: the people suggesting ideas are not necessarily proposing to implement the ideas. They definitely are not (yet) interested in the process of developing CPython. This is doubly true for the people who really need to read the HOWTO.
2. put it in the current dev guide somewhere, just so it lands in version control. Then iterate on both it and the dev guide. My first thought would be to merge the content with this document, https://github.com/python/devguide/blob/master/langchanges.rst.
Again, the devguide will not be an obvious place for people to stumble across the HOWTO.
3. put it somewhere near the front of the current dev guide, and do more work to adjust the dev guide.
Thoughts? Am I missing am obvious location? Should I just get on with a PR and we’ll sort it out later? :)
There is a page that catalogs the mailing lists: https://www.python.org/community/lists/ . A new page linked from the Python-Ideas description (which is very brief!) sounds good to me. Thanks again for doing this! --Ned.
best, —titus
On Jul 29, 2019, at 8:38 AM, Guido van Rossum <guido@python.org> wrote:
I suggest to put this in the devguide and deep-link there from the python-ideas (and python-dev?) description. The more we have under version control the better. There shouldn't be a need for too much bikeshedding on the first iteration -- just get a simple PR (along the lines of what you wrote) up (you can ping me for review) and once it's merged you can link to it; we can then easily iterate on the contents if there seems to be a need for additional suggestions.
On Mon, Jul 29, 2019 at 8:13 AM Ai mu <cryptolabour@gmail.com> wrote: Hosting? I suggest Python wiki
Abdur-Rahmaan Janhangeer _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/NBILWW... Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido van Rossum (python.org/~guido) Pronouns: he/him/his (why is my pronoun here?) _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/DVUIY3... Code of Conduct: http://python.org/psf/codeofconduct/
Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/CO2673... Code of Conduct: http://python.org/psf/codeofconduct/
On Sun, Dec 1, 2019, 11:06 AM Ned Batchelder <ned@nedbatchelder.com> wrote:
Hi folks,
sorry, took me more than a few months, but I wrote a draft of a
On 12/1/19 10:45 AM, C. Titus Brown wrote: python-ideas HOWTO here,
Thanks so much for writing this. I think Python-Ideas is a perfect example of something that could use an introduction, so that peoples' expectations are properly set.
Thanks to Eric Smith and Chris Barker for their link suggestions, and Chris Angelico and Guido van Rossum for their additional thoughts in a brief off-list thread.
SO. The question becomes, where do we host this?
I received the strong suggestion from both Guido and Stephen Turnbull that it should be in the devguide (see quoted message from GvR below).
But, when I finished this draft and went to look at the devguide repo, realized that the devguide at https://devguide.python.org/ may not be the best place to host it, because (as written) the dev guide is VERY focused on code development. I think this HOWTO is a bit more community and process oriented than the current top-level materials in the dev guide.
So instead of submitting a PR, I am appealing to the list for your thoughts.
The three easiest options I see are:
1. Put it on python.org, perhaps replacing the content here: https://www.python.org/dev/. I can’t figure out where that content is hosted (it’s not in https://github.com/python/pythondotorg/ !?)
To me, the audience for the Python-Ideas HOWTO is very different than for /dev/: the people suggesting ideas are not necessarily proposing to implement the ideas. They definitely are not (yet) interested in the process of developing CPython. This is doubly true for the people who really need to read the HOWTO.
2. put it in the current dev guide somewhere, just so it lands in
version control. Then iterate on both it and the dev guide. My first thought would be to merge the content with this document, https://github.com/python/devguide/blob/master/langchanges.rst. Again, the devguide will not be an obvious place for people to stumble across the HOWTO.
+1, developer-oriented material is the wrong place. Most first-time posters won't see it there at all.
3. put it somewhere near the front of the current dev guide, and do more work to adjust the dev guide.
Thoughts? Am I missing am obvious location? Should I just get on with a PR and we’ll sort it out later? :)
There is a page that catalogs the mailing lists: https://www.python.org/community/lists/ . A new page linked from the Python-Ideas description (which is very brief!) sounds good to me.
Thanks again for doing this!
--Ned.
I'd suggest putting the full text on the list sign up page above the subscription form (to encourage reading before signing up) and perhaps even in the body of an automated welcome email upon subscribing. The goal is to have as many new subscribers read it as possible, and that requires making it as visible as possible. Text will be read if easily seen and not buried "below the fold". Links are much less likely to be followed.
On Dec 1, 2019, at 8:15 AM, Jonathan Goble <jcgoble3@gmail.com> wrote:
On Sun, Dec 1, 2019, 11:06 AM Ned Batchelder <ned@nedbatchelder.com> wrote: On 12/1/19 10:45 AM, C. Titus Brown wrote:
Hi folks,
sorry, took me more than a few months, but I wrote a draft of a python-ideas HOWTO here,
[ munch of good discussion ]
Thoughts? Am I missing am obvious location? Should I just get on with a PR and we’ll sort it out later? :)
There is a page that catalogs the mailing lists: https://www.python.org/community/lists/ . A new page linked from the Python-Ideas description (which is very brief!) sounds good to me.
Thanks again for doing this!
--Ned.
I'd suggest putting the full text on the list sign up page above the subscription form (to encourage reading before signing up) and perhaps even in the body of an automated welcome email upon subscribing.
The goal is to have as many new subscribers read it as possible, and that requires making it as visible as possible. Text will be read if easily seen and not buried "below the fold". Links are much less likely to be followed.
Thanks Ned & Jonathan! I forgot to include some information in the original e-mail — I changed the python-ideas list so that new subscribers are by default under moderation. This was initially in response to the increase in spam, but also provides the opportunity to serve as a gate that lets me and other moderators respond to a first-post with “hey, have you read <THIS>? You really should!” So, in addition to being linked in to the appropriate places, I’m hoping to point to this document in a response to newcomers posting to the list. That seems like another high-conversion target location in addition to having it be on the list signup page and in a welcome message. best, —titus
Thanks for writing this up! It's nicely done. C. Titus Brown writes:
On Dec 1, 2019, at 8:15 AM, Jonathan Goble <jcgoble3@gmail.com> wrote:
I'd suggest putting the full text on the list sign up page above the subscription form (to encourage reading before signing up) and perhaps even in the body of an automated welcome email upon subscribing.
In its current short form, I think this is the best place. Among other things, there is a link to it in every post:
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Your text is on the long side for a list intro page, but given what it does, it's not too long. I don't see a good reason to make it any longer, so little downside risk to making it the list intro page -- it's not going to blow up and need to be moved out of there. Steve
On Sun, Dec 1, 2019 at 7:49 AM C. Titus Brown <ctbrown@ucdavis.edu> wrote: 1. Put it on python.org, perhaps replacing the content here:
I think that's a fine idea -- that page is really pretty limited, it could use a fleshing out. However, I'm not sure it's best to replace that page with this one, but rather, to replace that page with one that then refers to this one, as well as a few others. In any case, somewhere on python.org 2. put it in the current dev guide somewhere, just so it lands in version
control.
well, getting onto gitHug sooner than later would be good --hopefully you'll learn soon where/how the whole python.org site is managed.
3. put it somewhere near the front of the current dev guide, and do more work to adjust the dev guide.
nah, as has been pointed out that really is about actually contributing code to cPython -- and I think it's good to keep it that way. Most contributors to python-ideas never get that far. Should I just get on with a PR and we’ll sort it out later? :)
well, yes. If you don't resolve this soon, at least get it somewhere we can all comment on it :-) One thought --not sure it it belongs in this same docs, but it would be good to provide some guidance to PEP authors (and may-someday-be-a-PEP authors) as to how to moderate the conversation -- it is REALY hard to do, and I'm not sure what advise we can provide, but it would be good to see if we can put together a useful document. Thanks or doing this! -CHB
best, —titus
On Jul 29, 2019, at 8:38 AM, Guido van Rossum <guido@python.org> wrote:
I suggest to put this in the devguide and deep-link there from the python-ideas (and python-dev?) description. The more we have under version control the better. There shouldn't be a need for too much bikeshedding on the first iteration -- just get a simple PR (along the lines of what you wrote) up (you can ping me for review) and once it's merged you can link to it; we can then easily iterate on the contents if there seems to be a need for additional suggestions.
On Mon, Jul 29, 2019 at 8:13 AM Ai mu <cryptolabour@gmail.com> wrote: Hosting? I suggest Python wiki
Abdur-Rahmaan Janhangeer _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/NBILWW... Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido van Rossum (python.org/~guido) Pronouns: he/him/his (why is my pronoun here?) _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/DVUIY3... Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/CO2673... Code of Conduct: http://python.org/psf/codeofconduct/
-- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
Add a link to the HOWTO into the mailman footer? Barry
On 1 Dec 2019, at 15:45, C. Titus Brown <ctbrown@UCDAVIS.EDU> wrote:
Hi folks,
sorry, took me more than a few months, but I wrote a draft of a python-ideas HOWTO here,
https://hackmd.io/@-6xkuCDkTrSFptQEimAdcg/B1noEGh2H
Thanks to Eric Smith and Chris Barker for their link suggestions, and Chris Angelico and Guido van Rossum for their additional thoughts in a brief off-list thread.
SO. The question becomes, where do we host this?
I received the strong suggestion from both Guido and Stephen Turnbull that it should be in the devguide (see quoted message from GvR below).
But, when I finished this draft and went to look at the devguide repo, realized that the devguide at https://devguide.python.org/ may not be the best place to host it, because (as written) the dev guide is VERY focused on code development. I think this HOWTO is a bit more community and process oriented than the current top-level materials in the dev guide.
So instead of submitting a PR, I am appealing to the list for your thoughts.
The three easiest options I see are:
1. Put it on python.org, perhaps replacing the content here: https://www.python.org/dev/. I can’t figure out where that content is hosted (it’s not in https://github.com/python/pythondotorg/ !?)
2. put it in the current dev guide somewhere, just so it lands in version control. Then iterate on both it and the dev guide. My first thought would be to merge the content with this document, https://github.com/python/devguide/blob/master/langchanges.rst.
3. put it somewhere near the front of the current dev guide, and do more work to adjust the dev guide.
Thoughts? Am I missing am obvious location? Should I just get on with a PR and we’ll sort it out later? :)
best, —titus
On Jul 29, 2019, at 8:38 AM, Guido van Rossum <guido@python.org> wrote:
I suggest to put this in the devguide and deep-link there from the python-ideas (and python-dev?) description. The more we have under version control the better. There shouldn't be a need for too much bikeshedding on the first iteration -- just get a simple PR (along the lines of what you wrote) up (you can ping me for review) and once it's merged you can link to it; we can then easily iterate on the contents if there seems to be a need for additional suggestions.
On Mon, Jul 29, 2019 at 8:13 AM Ai mu <cryptolabour@gmail.com> wrote: Hosting? I suggest Python wiki
Abdur-Rahmaan Janhangeer _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/NBILWW... Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido van Rossum (python.org/~guido) Pronouns: he/him/his (why is my pronoun here?) _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/DVUIY3... Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/CO2673... Code of Conduct: http://python.org/psf/codeofconduct/
C. Titus Brown wrote:
put it in the current dev guide somewhere, just so it lands in version control. Then iterate on both it and the dev guide. My first thought would be to merge the content with this document, https://github.com/python/devguide/blob/master/langchanges.rst.
This option seems like a good one to me - there are plenty of other places where the information should be referenced (e.g. from https://devguide.python.org/communication/), but the dev guide is definitely intended to cover more than just the practical aspects of implementing already approved changes, it's also meant to provide guidance on having productive discussions when deciding whether or not to make a particular change. Cheers, Nick.
I wrote a slightly longer post similar to Guido's, and I'll not bore you with that. but let me emphasize what I think are the two important points. (1) Put it in the devguide and link from the -ideas and corementorship list blurbs on mail.python.org. (2) Just go FULL NIKE. do it, one draft, take advice on that, and submit a PR to the devguide. If people have improvements, they can do the same. This doesn't need bikeshedding on the wording. Steve
participants (22)
-
Ai mu -
Andre Roberge -
Barry Scott -
Batuhan Taskaya -
Brett Cannon -
C. Titus Brown -
C. Titus Brown
-
Chris Angelico -
Christopher Barker -
Eric V. Smith -
Ethan Furman -
Geoffrey Spear -
Guido van Rossum -
Jonathan Goble -
Kyle Stanley -
Ned Batchelder -
Nick Coghlan -
Paul Moore -
Rhodri James -
Richard Damon -
Serhiy Storchaka -
Stephen J. Turnbull