Re: [Python-ideas] Moving to another forum system where
Is that really an issue here? I personally haven't seen threads where Brett tried to stop an active discussion, but people ignored him and kept fighting. Not personally with Brett, but I have seen multiple people try to stop the “reword or remove beautiful is better than ugly in Zen of Python.” The discussion was going in circles and evolved into attacking each other’s use of logical fallacies.
Other than that, my biggest issues with the current mailing system are: * There’s no way to keep a updated proposal of your own- if you decide to change your proposal, you have to communicate the change. Then, if you want to find the authoritative current copy, since you might’ve forgotten or you want to join he current discussion, then you have to dig through the emails and recursively apply the proposed change. It’s just easier if people can have one proposal they can edit themselves. * I’ve seen experienced people get confused about what was the current proposal because they were replying to older emails or they didn’t see the email with the clear examples. * The mailing list is frankly obscure. Python community leaders and package maintainers often are not aware or do not participate in Python-ideas. Not many people know how to use or navigate a mailing list. * No one really promotes the mailing list, you have to go out of your way to find where new features are proposed. * Higher discoverability means more people can participate, providing their own use cases or voting (I mean using like or dislike measures, consensus should still be how things are approved) go out of their way to find so they can propose something. Instead, I envision a forum where people can read and give their 2 cents about what features they might like to see or might not want to see. * More people means instead of having to make decisions from sometimes subjective personal experience, we can make decisions with confidence in what other Python devs want. Since potential proposers will find it easier to navigate a GUI forum, they can read previous discussions to understand the reasoning, precedent behind rejected and successful features. People proposing things that have already been rejected before can be directed to open a subtopic on the older discussion.
On Sep 18, 2018, at 3:19 PM, python-ideas-request@python.org wrote:
Is that really an issue here? I personally haven't seen threads where Brett tried to stop an active discussion, but people ignored him and kept fighting.
On Wed, Sep 19, 2018 at 10:21 AM James Lu <jamtlu@gmail.com> wrote:
Not personally with Brett, but I have seen multiple people try to stop the “reword or remove beautiful is better than ugly in Zen of Python.” The discussion was going in circles and evolved into attacking each other’s use of logical fallacies.
Other than that, my biggest issues with the current mailing system are:
* There’s no way to keep a updated proposal of your own- if you decide to change your proposal, you have to communicate the change. Then, if you want to find the authoritative current copy, since you might’ve forgotten or you want to join he current discussion, then you have to dig through the emails and recursively apply the proposed change. It’s just easier if people can have one proposal they can edit themselves.
That's what the PEP system exists for. But with the "remove the word ugly from the zen" proposal, it's not serious enough for anyone to actually want to write up a PEP about it. Normally, what happens is that the "authoritative current copy" can always be found at https://www.python.org/dev/peps/pep-????/ for some well-known PEP number. That PEP generally has a single authoritative author (sometimes two or three, but always a small number). For any proposal that actually has currency, this system does work (well enough that I've wanted to introduce something like it in other contexts). ChrisA
On Tue, Sep 18, 2018 at 5:57 PM Chris Angelico <rosuav@gmail.com> wrote:
For any proposal that actually has currency, this system does work
The trouble is the ambiguity of knowing what "actually has currency" is and how to get it. PEP 1 states, "Following a discussion on python-ideas, the proposal should be submitted as a draft PEP via a GitHub pull request." However, PEP 1 does not give instruction on how to evaluate whether that discussion has been completed satisfactorily. https://www.python.org/dev/peps/pep-0001/#submitting-a-pep
Michael Selik writes:
However, PEP 1 does not give instruction on how to evaluate whether that discussion has been completed satisfactorily.
That's because completion of discussion has never been a requirement for writing a PEP. Writing a PEP is a lot more effort than writing an email. The purposes of initiating discussions are 1. Avoid duplication. Nobody has encyclopedic knowledge of the hundreds of PEPs anymore, but the lists do. 2. Gauge feasibility of the proposal. Some are non-starters for reasons of "Pythonicity", others are extremely difficult to implement given Python internals or constraints like LL(1) syntax in the parser. 3. Gauge interest in the content of the proposal. If the protagonists think it's worth it after that, they write a PEP. Typically the discussion continues on list during the drafting.
On Thu, Sep 20, 2018 at 2:13 AM Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
Michael Selik writes:
However, PEP 1 does not give instruction on how to evaluate whether that discussion has been completed satisfactorily.
That's because completion of discussion has never been a requirement for writing a PEP.
Not for drafting, but for submitting. For my own PEP submission, I received the specific feedback that it needed a "proper title" before being assigned a PEP number. My goal for submitting the draft was to receive a PEP number to avoid the awkwardness of discussing a PEP without an obvious title. Perhaps PEP 1 should be revised to clarify the expectations for PEP submission.
That's because completion of discussion has never been a requirement for writing a PEP.
Not for drafting, but for submitting.
Can you quote pep1? I think you’re wrong. In general pep1 is frustratingly vague. Terms like “community consensus” without defining community or what numbers would constitute a consensus are not fun to read as someone who doesn’t personally know anyone of the core devs. Further references to Guido are even more frustrating now that he’s bowed out. / Anders
On Thu, Sep 20, 2018 at 9:27 AM Anders Hovmöller <boxed@killingar.net> wrote:
That's because completion of discussion has never been a requirement for writing a PEP.
Not for drafting, but for submitting.
Can you quote pep1? I think you’re wrong.
I can't remember if I pulled this quote previously (that's one of the troubles with emails): "Following a discussion on python-ideas, the proposal should be submitted as a draft PEP ..." Could you clarify what you think is inaccurate in the previous statements?
Not for drafting, but for submitting.
Can you quote pep1? I think you’re wrong.
I can't remember if I pulled this quote previously (that's one of the troubles with emails): "Following a discussion on python-ideas, the proposal should be submitted as a draft PEP ..."
Could you clarify what you think is inaccurate in the previous statements?
It later states this is just to avoid submitting bad ideas. It’s not actually a requirement but a (supposed) kindness. / Anders
On Thu, Sep 20, 2018 at 10:25 AM Anders Hovmöller <boxed@killingar.net> wrote:
Not for drafting, but for submitting.
Can you quote pep1? I think you’re wrong.
I can't remember if I pulled this quote previously (that's one of the troubles with emails): "Following a discussion on python-ideas, the proposal should be submitted as a draft PEP ..."
Could you clarify what you think is inaccurate in the previous statements?
It later states this is just to avoid submitting bad ideas. It’s not actually a requirement but a (supposed) kindness.
Some regulations are de jure, others are de facto.
A point here: any proposal that is an actual proposal, rather than a idea that needs fleshing out, can benefit from being written down in a single document. It does NOT have to be an official PEP in order for that to happen. If you are advocating something, then write it down, post it gitHbu or some such, and point people to it -- that's it. Using this list alone (or any forum-like system) is not a good way to work out the details of the proposal -- if you have a written out version, then folks can debate what's actually in the proposal, and not the various already discussed and rejected idea that float around in multiple discussion threads... -CHB On Thu, Sep 20, 2018 at 7:46 PM, Michael Selik <mike@selik.org> wrote:
On Thu, Sep 20, 2018 at 10:25 AM Anders Hovmöller <boxed@killingar.net> wrote:
Not for drafting, but for submitting.
Can you quote pep1? I think you’re wrong.
I can't remember if I pulled this quote previously (that's one of the troubles with emails): "Following a discussion on python-ideas, the proposal should be submitted as a draft PEP ..."
Could you clarify what you think is inaccurate in the previous statements?
It later states this is just to avoid submitting bad ideas. It’s not actually a requirement but a (supposed) kindness.
Some regulations are de jure, others are de facto. _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
Executive summary: Writing a PEP is an inherently uncertain process. Achieving "community consensus" is the goal of the process, not a precondition. Anders Hovmöller writes:
In general pep1 is frustratingly vague. Terms like “community consensus” without defining community or what numbers would constitute a consensus are not fun to read as someone who doesn’t personally know anyone of the core devs. Further references to Guido are even more frustrating now that he’s bowed out.
These terms have little to do with what a new PEP's proponent needs to think about, though. A PEP-able proposal by definition involves uncertainty. Nobody, not even Guido, can tell you in advance whether a PEP will be accepted (for implementation). The PEP process is rigorous enough that by the time you get close to needing consensus to proceed, you'll know what it means. "Community consensus" is not a condition for *anything* in the PEP process, except final acceptance. It is the *goal* of the process. PEPs are approved (for publication) by default; the only requirement is editorial completeness. PEPs are needed for two reasons: (1) to get the input of the community, both highly competent engineers for implementation and a variety of users for requirements, to refine a complex proposal or one with far-reaching implications for the language, and/or (2) to build a consensus for implementation. Either way, by definition the outcome is unclear at the beginning. If your concern about "consensus" is that you want to know whether you're likely to get to consensus, and an accepted PEP, ask somebody who seems sympathetic and experienced enough to know about what it looks like on the list when a PEP is going to succeed. Anything PEP-able is sufficiently unclear that rules can't be given in PEP 1. It is possible only to say that Python is now very mature, and there's a strong conservative bias against change. That doesn't mean there aren't changes: Python attracts a lot of feature proposals, so the rate of change isn't slowing although the acceptance rate is declining gradually. "Consensus" is never defined by numbers in the English language, and it does not mean "unanimity". In PEP 1, it means that some people agree, most people don't disagree, and even if a senior person disagrees, they're willing to go along with the "sense of the community". As that adjective "senior" implies, some people count more to the consensus than others. Usually when I write "senior" I'm referring to core developers (committers), but here there people who are "senior" enough despite not having commit bits.[1] "The community" is not well defined, and it can't be, short of a doctoral dissertation in anthropology. The relevant channels are open-participation, some people speak for themselves, some people are "official" representatives of important constituencies such as the leaders of large independent projects or alternative implementations, and some people have acquired sufficient reputation to be considered representative of a group of people (especially when other members of the group rarely participate in the dev lists but for some reason are considered important to the community -- I'm thinking in particular of sysadmins and devops, and the problems we can cause them by messing with packaging and installation). References to the BDFL are, of course, in limbo. AFAIK we don't have one at the moment. Until we do, any PEPs will presumably be accepted either by a self-nominated BDFL-Delegate acceptable to the core devs, or by an ad hoc committee of interested core devs, and that part of PEP 1 can't be usefully updated yet. This is not a weakness of the Python project, IMO. Rather, the fact that, despite a sort of constitutional crisis, the whole process is continuing pretty much as usual shows its strength. This is possible because the BDFL is not, and has not been for many years, a "hands-on" manager. It's true that where a proposal affects his own "development *in* Python", he's likely to work closely with a proponent, off- and on-list, or even *be* the proponent. Of course such proposals are more likely to be approved, and a few community members have pushed back on that because it appears undemocratic. But the general reaction is "maybe 'Although that way may not be obvious at first unless you're Dutch' applies to me in such cases!" For most proposals, he's "just" a very senior developer whose comments are important because he's a great developer, but he is easily swayed by the sense of the community. Bottom line: except in the rare case where your proposal directly affects the BDFL's own coding, the BDFL's now-traditional role is to declare that consensus has been achieved, postpone the PEP because it's clear that consensus is not forming, or in rare cases, make a choice despite the lack of consensus. But none of this is really of importance to a PEP proponent ("champion" in the terminology of PEP 1). PEP 1 is quite specific about the required components of the document, and many points of formatting and style. Accept the uncertainty, and do what you need to do to meet those requirements, that's all there is to it. If the community wants more, or wants changes, it will tell you, either as a demand about style or missing content from an editor or as a technical comment on the list. Whether you accept those technical comments is up to you, but your star will rise far more rapidly if you are very sensitive to claims that "this change to the PEP will a big improvement for some significant consituency in the community". If you want advice on whether the chance of acceptance is high enough to be worth putting in more work, ask the BDFL-Delegate (or the BDFL if she/he has "claimed" the PEP) where the proposal has an official adjudicator, and if not, a senior core developer. If one doesn't know who the senior developers are yet, she should think twice about whether she's ready to PEP anything. That's not a litmus test; some PEPs have eventually succeeded though the proponent was new to the project development process.[2] But it's a lot less painful if you can tell who's likely to be able to sway the whole project one way or the other. And as a matter of improving your proposal, who surely does know more about what your proposal implies for the implementation than you do, so you should strongly consider whether *you* are the one who's missing something when you disagree with them. Footnotes: [1] They are familiar to some of the core developers as drivers of important projects developing *in* Python. [2] The ones I can think of involve the same kind of person as footnote 1, and a co-proponent who was a core developer.
Process suggestions that could minimize non-BDFL's BDFL legwork: * https://github.com/python/peps * https://github.com/pypa/interoperability-peps * Use GitHub reactions for voting on BDFL delegates, PEP final approval, and PEP sub issues? * Specify a voting deadline? * How to make a quorum call? * Add '@core/team' as reviewers for every PEP? * Link to the mailing list thread(s) at the top of the PR * [ ] Add unique message URLs to footers with mailman3 * What type of communications are better suited for mailing lists over PEP pull-requests and PEP code reviews? It seems like everything's fine, but I would have no idea, BTW [] https://en.wikipedia.org/wiki/Quorum_call On Saturday, September 22, 2018, Stephen J. Turnbull < turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
Executive summary: Writing a PEP is an inherently uncertain process. Achieving "community consensus" is the goal of the process, not a precondition.
Anders Hovmöller writes:
In general pep1 is frustratingly vague. Terms like “community consensus” without defining community or what numbers would constitute a consensus are not fun to read as someone who doesn’t personally know anyone of the core devs. Further references to Guido are even more frustrating now that he’s bowed out.
These terms have little to do with what a new PEP's proponent needs to think about, though. A PEP-able proposal by definition involves uncertainty. Nobody, not even Guido, can tell you in advance whether a PEP will be accepted (for implementation). The PEP process is rigorous enough that by the time you get close to needing consensus to proceed, you'll know what it means.
"Community consensus" is not a condition for *anything* in the PEP process, except final acceptance. It is the *goal* of the process. PEPs are approved (for publication) by default; the only requirement is editorial completeness. PEPs are needed for two reasons: (1) to get the input of the community, both highly competent engineers for implementation and a variety of users for requirements, to refine a complex proposal or one with far-reaching implications for the language, and/or (2) to build a consensus for implementation. Either way, by definition the outcome is unclear at the beginning.
If your concern about "consensus" is that you want to know whether you're likely to get to consensus, and an accepted PEP, ask somebody who seems sympathetic and experienced enough to know about what it looks like on the list when a PEP is going to succeed. Anything PEP-able is sufficiently unclear that rules can't be given in PEP 1. It is possible only to say that Python is now very mature, and there's a strong conservative bias against change. That doesn't mean there aren't changes: Python attracts a lot of feature proposals, so the rate of change isn't slowing although the acceptance rate is declining gradually.
"Consensus" is never defined by numbers in the English language, and it does not mean "unanimity". In PEP 1, it means that some people agree, most people don't disagree, and even if a senior person disagrees, they're willing to go along with the "sense of the community". As that adjective "senior" implies, some people count more to the consensus than others. Usually when I write "senior" I'm referring to core developers (committers), but here there people who are "senior" enough despite not having commit bits.[1]
"The community" is not well defined, and it can't be, short of a doctoral dissertation in anthropology. The relevant channels are open-participation, some people speak for themselves, some people are "official" representatives of important constituencies such as the leaders of large independent projects or alternative implementations, and some people have acquired sufficient reputation to be considered representative of a group of people (especially when other members of the group rarely participate in the dev lists but for some reason are considered important to the community -- I'm thinking in particular of sysadmins and devops, and the problems we can cause them by messing with packaging and installation).
References to the BDFL are, of course, in limbo. AFAIK we don't have one at the moment. Until we do, any PEPs will presumably be accepted either by a self-nominated BDFL-Delegate acceptable to the core devs, or by an ad hoc committee of interested core devs, and that part of PEP 1 can't be usefully updated yet. This is not a weakness of the Python project, IMO. Rather, the fact that, despite a sort of constitutional crisis, the whole process is continuing pretty much as usual shows its strength.
This is possible because the BDFL is not, and has not been for many years, a "hands-on" manager. It's true that where a proposal affects his own "development *in* Python", he's likely to work closely with a proponent, off- and on-list, or even *be* the proponent. Of course such proposals are more likely to be approved, and a few community members have pushed back on that because it appears undemocratic. But the general reaction is "maybe 'Although that way may not be obvious at first unless you're Dutch' applies to me in such cases!" For most proposals, he's "just" a very senior developer whose comments are important because he's a great developer, but he is easily swayed by the sense of the community. Bottom line: except in the rare case where your proposal directly affects the BDFL's own coding, the BDFL's now-traditional role is to declare that consensus has been achieved, postpone the PEP because it's clear that consensus is not forming, or in rare cases, make a choice despite the lack of consensus.
But none of this is really of importance to a PEP proponent ("champion" in the terminology of PEP 1). PEP 1 is quite specific about the required components of the document, and many points of formatting and style. Accept the uncertainty, and do what you need to do to meet those requirements, that's all there is to it. If the community wants more, or wants changes, it will tell you, either as a demand about style or missing content from an editor or as a technical comment on the list. Whether you accept those technical comments is up to you, but your star will rise far more rapidly if you are very sensitive to claims that "this change to the PEP will a big improvement for some significant consituency in the community". If you want advice on whether the chance of acceptance is high enough to be worth putting in more work, ask the BDFL-Delegate (or the BDFL if she/he has "claimed" the PEP) where the proposal has an official adjudicator, and if not, a senior core developer.
If one doesn't know who the senior developers are yet, she should think twice about whether she's ready to PEP anything. That's not a litmus test; some PEPs have eventually succeeded though the proponent was new to the project development process.[2] But it's a lot less painful if you can tell who's likely to be able to sway the whole project one way or the other. And as a matter of improving your proposal, who surely does know more about what your proposal implies for the implementation than you do, so you should strongly consider whether *you* are the one who's missing something when you disagree with them.
Footnotes: [1] They are familiar to some of the core developers as drivers of important projects developing *in* Python.
[2] The ones I can think of involve the same kind of person as footnote 1, and a co-proponent who was a core developer.
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
On Saturday, September 22, 2018, Wes Turner <wes.turner@gmail.com> wrote:
It seems like everything's fine, but I would have no idea, BTW
Would project boards be helpful for coordinating proposal status information, or extra process for something that's already working just fine? https://github.com/python/peps/projects https://github.com/pypa/interoperability-peps/projects TBH, I like Waffle.io boards, but core team may be more comfortable with GH projects with swimlanes?
[] https://en.wikipedia.org/wiki/Quorum_call
On Saturday, September 22, 2018, Stephen J. Turnbull < turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
Executive summary: Writing a PEP is an inherently uncertain process. Achieving "community consensus" is the goal of the process, not a precondition.
Anders Hovmöller writes:
In general pep1 is frustratingly vague. Terms like “community consensus” without defining community or what numbers would constitute a consensus are not fun to read as someone who doesn’t personally know anyone of the core devs. Further references to Guido are even more frustrating now that he’s bowed out.
These terms have little to do with what a new PEP's proponent needs to think about, though. A PEP-able proposal by definition involves uncertainty. Nobody, not even Guido, can tell you in advance whether a PEP will be accepted (for implementation). The PEP process is rigorous enough that by the time you get close to needing consensus to proceed, you'll know what it means.
"Community consensus" is not a condition for *anything* in the PEP process, except final acceptance. It is the *goal* of the process. PEPs are approved (for publication) by default; the only requirement is editorial completeness. PEPs are needed for two reasons: (1) to get the input of the community, both highly competent engineers for implementation and a variety of users for requirements, to refine a complex proposal or one with far-reaching implications for the language, and/or (2) to build a consensus for implementation. Either way, by definition the outcome is unclear at the beginning.
If your concern about "consensus" is that you want to know whether you're likely to get to consensus, and an accepted PEP, ask somebody who seems sympathetic and experienced enough to know about what it looks like on the list when a PEP is going to succeed. Anything PEP-able is sufficiently unclear that rules can't be given in PEP 1. It is possible only to say that Python is now very mature, and there's a strong conservative bias against change. That doesn't mean there aren't changes: Python attracts a lot of feature proposals, so the rate of change isn't slowing although the acceptance rate is declining gradually.
"Consensus" is never defined by numbers in the English language, and it does not mean "unanimity". In PEP 1, it means that some people agree, most people don't disagree, and even if a senior person disagrees, they're willing to go along with the "sense of the community". As that adjective "senior" implies, some people count more to the consensus than others. Usually when I write "senior" I'm referring to core developers (committers), but here there people who are "senior" enough despite not having commit bits.[1]
"The community" is not well defined, and it can't be, short of a doctoral dissertation in anthropology. The relevant channels are open-participation, some people speak for themselves, some people are "official" representatives of important constituencies such as the leaders of large independent projects or alternative implementations, and some people have acquired sufficient reputation to be considered representative of a group of people (especially when other members of the group rarely participate in the dev lists but for some reason are considered important to the community -- I'm thinking in particular of sysadmins and devops, and the problems we can cause them by messing with packaging and installation).
References to the BDFL are, of course, in limbo. AFAIK we don't have one at the moment. Until we do, any PEPs will presumably be accepted either by a self-nominated BDFL-Delegate acceptable to the core devs, or by an ad hoc committee of interested core devs, and that part of PEP 1 can't be usefully updated yet. This is not a weakness of the Python project, IMO. Rather, the fact that, despite a sort of constitutional crisis, the whole process is continuing pretty much as usual shows its strength.
This is possible because the BDFL is not, and has not been for many years, a "hands-on" manager. It's true that where a proposal affects his own "development *in* Python", he's likely to work closely with a proponent, off- and on-list, or even *be* the proponent. Of course such proposals are more likely to be approved, and a few community members have pushed back on that because it appears undemocratic. But the general reaction is "maybe 'Although that way may not be obvious at first unless you're Dutch' applies to me in such cases!" For most proposals, he's "just" a very senior developer whose comments are important because he's a great developer, but he is easily swayed by the sense of the community. Bottom line: except in the rare case where your proposal directly affects the BDFL's own coding, the BDFL's now-traditional role is to declare that consensus has been achieved, postpone the PEP because it's clear that consensus is not forming, or in rare cases, make a choice despite the lack of consensus.
But none of this is really of importance to a PEP proponent ("champion" in the terminology of PEP 1). PEP 1 is quite specific about the required components of the document, and many points of formatting and style. Accept the uncertainty, and do what you need to do to meet those requirements, that's all there is to it. If the community wants more, or wants changes, it will tell you, either as a demand about style or missing content from an editor or as a technical comment on the list. Whether you accept those technical comments is up to you, but your star will rise far more rapidly if you are very sensitive to claims that "this change to the PEP will a big improvement for some significant consituency in the community". If you want advice on whether the chance of acceptance is high enough to be worth putting in more work, ask the BDFL-Delegate (or the BDFL if she/he has "claimed" the PEP) where the proposal has an official adjudicator, and if not, a senior core developer.
If one doesn't know who the senior developers are yet, she should think twice about whether she's ready to PEP anything. That's not a litmus test; some PEPs have eventually succeeded though the proponent was new to the project development process.[2] But it's a lot less painful if you can tell who's likely to be able to sway the whole project one way or the other. And as a matter of improving your proposal, who surely does know more about what your proposal implies for the implementation than you do, so you should strongly consider whether *you* are the one who's missing something when you disagree with them.
Footnotes: [1] They are familiar to some of the core developers as drivers of important projects developing *in* Python.
[2] The ones I can think of involve the same kind of person as footnote 1, and a co-proponent who was a core developer.
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Here are links to the Apache governance docs: https://www.apache.org/foundation/governance/#technical https://www.apache.org/foundation/governance/pmcs.html Which are the PSF docs for these exact same processes for open source governance? (In re: to transitioning from BDFL is not dead, but) https://devguide.python.org/#contributing https://devguide.python.org/experts/ - is there a different BDFL-delegate org chart, or would this be the page to add to and refer to? On Saturday, September 22, 2018, Wes Turner <wes.turner@gmail.com> wrote:
On Saturday, September 22, 2018, Wes Turner <wes.turner@gmail.com> wrote:
It seems like everything's fine, but I would have no idea, BTW
Would project boards be helpful for coordinating proposal status information, or extra process for something that's already working just fine?
https://github.com/python/peps/projects
https://github.com/pypa/interoperability-peps/projects
TBH, I like Waffle.io boards, but core team may be more comfortable with GH projects with swimlanes?
[] https://en.wikipedia.org/wiki/Quorum_call
On Saturday, September 22, 2018, Stephen J. Turnbull < turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
Executive summary: Writing a PEP is an inherently uncertain process. Achieving "community consensus" is the goal of the process, not a precondition.
Anders Hovmöller writes:
In general pep1 is frustratingly vague. Terms like “community consensus” without defining community or what numbers would constitute a consensus are not fun to read as someone who doesn’t personally know anyone of the core devs. Further references to Guido are even more frustrating now that he’s bowed out.
These terms have little to do with what a new PEP's proponent needs to think about, though. A PEP-able proposal by definition involves uncertainty. Nobody, not even Guido, can tell you in advance whether a PEP will be accepted (for implementation). The PEP process is rigorous enough that by the time you get close to needing consensus to proceed, you'll know what it means.
"Community consensus" is not a condition for *anything* in the PEP process, except final acceptance. It is the *goal* of the process. PEPs are approved (for publication) by default; the only requirement is editorial completeness. PEPs are needed for two reasons: (1) to get the input of the community, both highly competent engineers for implementation and a variety of users for requirements, to refine a complex proposal or one with far-reaching implications for the language, and/or (2) to build a consensus for implementation. Either way, by definition the outcome is unclear at the beginning.
If your concern about "consensus" is that you want to know whether you're likely to get to consensus, and an accepted PEP, ask somebody who seems sympathetic and experienced enough to know about what it looks like on the list when a PEP is going to succeed. Anything PEP-able is sufficiently unclear that rules can't be given in PEP 1. It is possible only to say that Python is now very mature, and there's a strong conservative bias against change. That doesn't mean there aren't changes: Python attracts a lot of feature proposals, so the rate of change isn't slowing although the acceptance rate is declining gradually.
"Consensus" is never defined by numbers in the English language, and it does not mean "unanimity". In PEP 1, it means that some people agree, most people don't disagree, and even if a senior person disagrees, they're willing to go along with the "sense of the community". As that adjective "senior" implies, some people count more to the consensus than others. Usually when I write "senior" I'm referring to core developers (committers), but here there people who are "senior" enough despite not having commit bits.[1]
"The community" is not well defined, and it can't be, short of a doctoral dissertation in anthropology. The relevant channels are open-participation, some people speak for themselves, some people are "official" representatives of important constituencies such as the leaders of large independent projects or alternative implementations, and some people have acquired sufficient reputation to be considered representative of a group of people (especially when other members of the group rarely participate in the dev lists but for some reason are considered important to the community -- I'm thinking in particular of sysadmins and devops, and the problems we can cause them by messing with packaging and installation).
References to the BDFL are, of course, in limbo. AFAIK we don't have one at the moment. Until we do, any PEPs will presumably be accepted either by a self-nominated BDFL-Delegate acceptable to the core devs, or by an ad hoc committee of interested core devs, and that part of PEP 1 can't be usefully updated yet. This is not a weakness of the Python project, IMO. Rather, the fact that, despite a sort of constitutional crisis, the whole process is continuing pretty much as usual shows its strength.
This is possible because the BDFL is not, and has not been for many years, a "hands-on" manager. It's true that where a proposal affects his own "development *in* Python", he's likely to work closely with a proponent, off- and on-list, or even *be* the proponent. Of course such proposals are more likely to be approved, and a few community members have pushed back on that because it appears undemocratic. But the general reaction is "maybe 'Although that way may not be obvious at first unless you're Dutch' applies to me in such cases!" For most proposals, he's "just" a very senior developer whose comments are important because he's a great developer, but he is easily swayed by the sense of the community. Bottom line: except in the rare case where your proposal directly affects the BDFL's own coding, the BDFL's now-traditional role is to declare that consensus has been achieved, postpone the PEP because it's clear that consensus is not forming, or in rare cases, make a choice despite the lack of consensus.
But none of this is really of importance to a PEP proponent ("champion" in the terminology of PEP 1). PEP 1 is quite specific about the required components of the document, and many points of formatting and style. Accept the uncertainty, and do what you need to do to meet those requirements, that's all there is to it. If the community wants more, or wants changes, it will tell you, either as a demand about style or missing content from an editor or as a technical comment on the list. Whether you accept those technical comments is up to you, but your star will rise far more rapidly if you are very sensitive to claims that "this change to the PEP will a big improvement for some significant consituency in the community". If you want advice on whether the chance of acceptance is high enough to be worth putting in more work, ask the BDFL-Delegate (or the BDFL if she/he has "claimed" the PEP) where the proposal has an official adjudicator, and if not, a senior core developer.
If one doesn't know who the senior developers are yet, she should think twice about whether she's ready to PEP anything. That's not a litmus test; some PEPs have eventually succeeded though the proponent was new to the project development process.[2] But it's a lot less painful if you can tell who's likely to be able to sway the whole project one way or the other. And as a matter of improving your proposal, who surely does know more about what your proposal implies for the implementation than you do, so you should strongly consider whether *you* are the one who's missing something when you disagree with them.
Footnotes: [1] They are familiar to some of the core developers as drivers of important projects developing *in* Python.
[2] The ones I can think of involve the same kind of person as footnote 1, and a co-proponent who was a core developer.
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
On Saturday, September 22, 2018, Wes Turner <wes.turner@gmail.com> wrote:
Here are links to the Apache governance docs:
https://www.apache.org/foundation/governance/#technical
https://www.apache.org/foundation/governance/pmcs.html
Which are the PSF docs for these exact same processes for open source governance? (In re: to transitioning from BDFL is not dead, but)
https://devguide.python.org/#contributing
https://devguide.python.org/experts/ - is there a different BDFL-delegate org chart, or would this be the page to add to and refer to?
re: Documenting the BDFL-Delegate process (in PEP 1?) I'm just not good with a MUA; Markdown in a linear GH issue is far easier to unsubscribe from; so I just added triple quotes:
From "[Python-Dev] Petr Viktorin as BDFL-Delegate for PEP 580":
""' Jeroen Demeyer Hello, I would like to propose Petr Viktorin as BDFL-Delegate for PEP 580, titled "The C call protocol". He has co-authored several PEPs [...] """ """ INADA Naoki 2018年10月3日(水) 21:24 Jeroen Demeyer <J.Demeyer@ugent.be>:
Hello, Really? I don't know process to assign BDFL-delegate without BDFL. This PEP is ...
Łukasz Langa
My understand is that accepting *any* PEP by anyone is out of the question until the governance situation gets resolved. That's the only reason why... """
""" On Wednesday, October 3, 2018, INADA Naoki <songofacandy@gmail.com> wrote: 2018年10月3日(水) 21:24 Jeroen Demeyer <J.Demeyer@ugent.be>: Hello,
I am well aware of the current governance issues, but several people have mentioned that the BDFL-Delegate process can still continue for now.
Really? I don't know process to assign BDFL-delegate without BDFL. """
""" AFAIU, there is not yet a documented process for BDFL-delegate assignment. There's this in the devguide; which links to PEP1: "20.2. PEP Process¶" https://devguide.python.org/langchanges/#pep-process https://github.com/python/devguide/blob/master/langchanges.rst And PEP 1: "PEP 1 -- PEP Purpose and Guidelines" "PEP Workflow" https://www.python.org/dev/peps/pep-0001/#pep-workflow "PEP Editors" https://www.python.org/dev/peps/pep-0001/#pep-editors "PEP Editor Responsibilities & Workflow" https://www.python.org/dev/peps/pep-0001/#pep-editor-responsibilities-workfl... https://github.com/python/peps/blob/master/pep-0001.txt And the devguide has a list of experts: https://devguide.python.org/experts/ Maybe PEP1 is the place to list current BDFL-Delegates (in addition to in the PEP metadata as in the OT PR: python/peps#797 "PEP 580: Petr Viktorin as BDFL-Delegate" )? Not to bikeshed, but is BDFL-Delegate still the current term because that's what's in all the other PEPs' metadata? """ Maybe a "delegation" GH Issue label or similar (and a commit prefix) on the python/peps repo would be helpful?
On Saturday, September 22, 2018, Wes Turner <wes.turner@gmail.com> wrote:
On Saturday, September 22, 2018, Wes Turner <wes.turner@gmail.com> wrote:
It seems like everything's fine, but I would have no idea, BTW
Would project boards be helpful for coordinating proposal status information, or extra process for something that's already working just fine?
https://github.com/python/peps/projects
https://github.com/pypa/interoperability-peps/projects
TBH, I like Waffle.io boards, but core team may be more comfortable with GH projects with swimlanes?
[] https://en.wikipedia.org/wiki/Quorum_call
On Saturday, September 22, 2018, Stephen J. Turnbull < turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
Executive summary: Writing a PEP is an inherently uncertain process. Achieving "community consensus" is the goal of the process, not a precondition.
Anders Hovmöller writes:
In general pep1 is frustratingly vague. Terms like “community consensus” without defining community or what numbers would constitute a consensus are not fun to read as someone who doesn’t personally know anyone of the core devs. Further references to Guido are even more frustrating now that he’s bowed out.
These terms have little to do with what a new PEP's proponent needs to think about, though. A PEP-able proposal by definition involves uncertainty. Nobody, not even Guido, can tell you in advance whether a PEP will be accepted (for implementation). The PEP process is rigorous enough that by the time you get close to needing consensus to proceed, you'll know what it means.
"Community consensus" is not a condition for *anything* in the PEP process, except final acceptance. It is the *goal* of the process. PEPs are approved (for publication) by default; the only requirement is editorial completeness. PEPs are needed for two reasons: (1) to get the input of the community, both highly competent engineers for implementation and a variety of users for requirements, to refine a complex proposal or one with far-reaching implications for the language, and/or (2) to build a consensus for implementation. Either way, by definition the outcome is unclear at the beginning.
If your concern about "consensus" is that you want to know whether you're likely to get to consensus, and an accepted PEP, ask somebody who seems sympathetic and experienced enough to know about what it looks like on the list when a PEP is going to succeed. Anything PEP-able is sufficiently unclear that rules can't be given in PEP 1. It is possible only to say that Python is now very mature, and there's a strong conservative bias against change. That doesn't mean there aren't changes: Python attracts a lot of feature proposals, so the rate of change isn't slowing although the acceptance rate is declining gradually.
"Consensus" is never defined by numbers in the English language, and it does not mean "unanimity". In PEP 1, it means that some people agree, most people don't disagree, and even if a senior person disagrees, they're willing to go along with the "sense of the community". As that adjective "senior" implies, some people count more to the consensus than others. Usually when I write "senior" I'm referring to core developers (committers), but here there people who are "senior" enough despite not having commit bits.[1]
"The community" is not well defined, and it can't be, short of a doctoral dissertation in anthropology. The relevant channels are open-participation, some people speak for themselves, some people are "official" representatives of important constituencies such as the leaders of large independent projects or alternative implementations, and some people have acquired sufficient reputation to be considered representative of a group of people (especially when other members of the group rarely participate in the dev lists but for some reason are considered important to the community -- I'm thinking in particular of sysadmins and devops, and the problems we can cause them by messing with packaging and installation).
References to the BDFL are, of course, in limbo. AFAIK we don't have one at the moment. Until we do, any PEPs will presumably be accepted either by a self-nominated BDFL-Delegate acceptable to the core devs, or by an ad hoc committee of interested core devs, and that part of PEP 1 can't be usefully updated yet. This is not a weakness of the Python project, IMO. Rather, the fact that, despite a sort of constitutional crisis, the whole process is continuing pretty much as usual shows its strength.
This is possible because the BDFL is not, and has not been for many years, a "hands-on" manager. It's true that where a proposal affects his own "development *in* Python", he's likely to work closely with a proponent, off- and on-list, or even *be* the proponent. Of course such proposals are more likely to be approved, and a few community members have pushed back on that because it appears undemocratic. But the general reaction is "maybe 'Although that way may not be obvious at first unless you're Dutch' applies to me in such cases!" For most proposals, he's "just" a very senior developer whose comments are important because he's a great developer, but he is easily swayed by the sense of the community. Bottom line: except in the rare case where your proposal directly affects the BDFL's own coding, the BDFL's now-traditional role is to declare that consensus has been achieved, postpone the PEP because it's clear that consensus is not forming, or in rare cases, make a choice despite the lack of consensus.
But none of this is really of importance to a PEP proponent ("champion" in the terminology of PEP 1). PEP 1 is quite specific about the required components of the document, and many points of formatting and style. Accept the uncertainty, and do what you need to do to meet those requirements, that's all there is to it. If the community wants more, or wants changes, it will tell you, either as a demand about style or missing content from an editor or as a technical comment on the list. Whether you accept those technical comments is up to you, but your star will rise far more rapidly if you are very sensitive to claims that "this change to the PEP will a big improvement for some significant consituency in the community". If you want advice on whether the chance of acceptance is high enough to be worth putting in more work, ask the BDFL-Delegate (or the BDFL if she/he has "claimed" the PEP) where the proposal has an official adjudicator, and if not, a senior core developer.
If one doesn't know who the senior developers are yet, she should think twice about whether she's ready to PEP anything. That's not a litmus test; some PEPs have eventually succeeded though the proponent was new to the project development process.[2] But it's a lot less painful if you can tell who's likely to be able to sway the whole project one way or the other. And as a matter of improving your proposal, who surely does know more about what your proposal implies for the implementation than you do, so you should strongly consider whether *you* are the one who's missing something when you disagree with them.
Footnotes: [1] They are familiar to some of the core developers as drivers of important projects developing *in* Python.
[2] The ones I can think of involve the same kind of person as footnote 1, and a co-proponent who was a core developer.
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
re: Updating the BDFL-Delegate policy (in PEP 1) On Wednesday, October 3, 2018, Wes Turner <wes.turner@gmail.com> wrote:
On Saturday, September 22, 2018, Wes Turner <wes.turner@gmail.com> wrote:
[...]
https://devguide.python.org/#contributing
https://devguide.python.org/experts/ - is there a different BDFL-delegate org chart, or would this be the page to add to and refer to?
re: Documenting the BDFL-Delegate process (in PEP 1?)
I'm just not good with a MUA; Markdown in a linear GH issue is far easier to unsubscribe from; so I just added triple quotes:
From "[Python-Dev] Petr Viktorin as BDFL-Delegate for PEP 580":
""' Jeroen Demeyer Hello, I would like to propose Petr Viktorin as BDFL-Delegate for PEP 580, titled "The C call protocol". He has co-authored several PEPs [...] """
""" INADA Naoki 2018年10月3日(水) 21:24 Jeroen Demeyer <J.Demeyer@ugent.be>:
Hello, Really? I don't know process to assign BDFL-delegate without BDFL. This PEP is ...
Łukasz Langa
My understand is that accepting *any* PEP by anyone is out of the question until the governance situation gets resolved. That's the only reason why... """
""" On Wednesday, October 3, 2018, INADA Naoki <songofacandy@gmail.com> wrote:
2018年10月3日(水) 21:24 Jeroen Demeyer <J.Demeyer@ugent.be>: Hello,
I am well aware of the current governance issues, but several people have mentioned that the BDFL-Delegate process can still continue for now.
Really? I don't know process to assign BDFL-delegate without BDFL. """
""" AFAIU, there is not yet a documented process for BDFL-delegate assignment.
There's this in the devguide; which links to PEP1:
"20.2. PEP Process¶" https://devguide.python.org/langchanges/#pep-process https://github.com/python/devguide/blob/master/langchanges.rst
And PEP 1:
"PEP 1 -- PEP Purpose and Guidelines" "PEP Workflow" https://www.python.org/dev/peps/pep-0001/#pep-workflow "PEP Editors" https://www.python.org/dev/peps/pep-0001/#pep-editors "PEP Editor Responsibilities & Workflow" https://www.python.org/dev/peps/pep-0001/#pep-editor- responsibilities-workflow
https://github.com/python/peps/blob/master/pep-0001.txt
And the devguide has a list of experts: https://devguide.python.org/experts/
Maybe PEP1 is the place to list current BDFL-Delegates (in addition to in the PEP metadata as in the OT PR: python/peps#797 "PEP 580: Petr Viktorin as BDFL-Delegate" )?
Not to bikeshed, but is BDFL-Delegate still the current term because that's what's in all the other PEPs' metadata? """
Maybe a "delegation" GH Issue label or similar (and a commit prefix) on the python/peps repo would be helpful?
''' On 2018-10-03 17:12, Wes Turner wrote:
AFAIU, there is not yet a documented process for BDFL-delegate assignment.
PEP 1 says: """ However, whenever a new PEP is put forward, any core developer that believes they are suitably experienced to make the final decision on that PEP may offer to serve as the BDFL's delegate (or "PEP czar") for that PEP. If their self-nomination is accepted by the other core developers and the BDFL, then they will have the authority to approve (or reject) that PEP. """ I know that it says "core developers and the BDFL". However, if the core developers agree that Petr can become BDFL-Delegate, I don't see why that wouldn't be possible. ''' The phrase "core developers and the BDFL" is where some sort of alternate quorum/majority policy would need to be specified if this is a contentious issue in practice? (TBC, I'm +1 on the particular delegation that's not the question here)
On Saturday, September 22, 2018, Wes Turner <wes.turner@gmail.com> wrote:
On Saturday, September 22, 2018, Wes Turner <wes.turner@gmail.com> wrote:
It seems like everything's fine, but I would have no idea, BTW
Would project boards be helpful for coordinating proposal status information, or extra process for something that's already working just fine?
https://github.com/python/peps/projects
https://github.com/pypa/interoperability-peps/projects
TBH, I like Waffle.io boards, but core team may be more comfortable with GH projects with swimlanes?
[] https://en.wikipedia.org/wiki/Quorum_call
On Saturday, September 22, 2018, Stephen J. Turnbull < turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
Executive summary: Writing a PEP is an inherently uncertain process. Achieving "community consensus" is the goal of the process, not a precondition.
Anders Hovmöller writes:
In general pep1 is frustratingly vague. Terms like “community consensus” without defining community or what numbers would constitute a consensus are not fun to read as someone who doesn’t personally know anyone of the core devs. Further references to Guido are even more frustrating now that he’s bowed out.
These terms have little to do with what a new PEP's proponent needs to think about, though. A PEP-able proposal by definition involves uncertainty. Nobody, not even Guido, can tell you in advance whether a PEP will be accepted (for implementation). The PEP process is rigorous enough that by the time you get close to needing consensus to proceed, you'll know what it means.
"Community consensus" is not a condition for *anything* in the PEP process, except final acceptance. It is the *goal* of the process. PEPs are approved (for publication) by default; the only requirement is editorial completeness. PEPs are needed for two reasons: (1) to get the input of the community, both highly competent engineers for implementation and a variety of users for requirements, to refine a complex proposal or one with far-reaching implications for the language, and/or (2) to build a consensus for implementation. Either way, by definition the outcome is unclear at the beginning.
If your concern about "consensus" is that you want to know whether you're likely to get to consensus, and an accepted PEP, ask somebody who seems sympathetic and experienced enough to know about what it looks like on the list when a PEP is going to succeed. Anything PEP-able is sufficiently unclear that rules can't be given in PEP 1. It is possible only to say that Python is now very mature, and there's a strong conservative bias against change. That doesn't mean there aren't changes: Python attracts a lot of feature proposals, so the rate of change isn't slowing although the acceptance rate is declining gradually.
"Consensus" is never defined by numbers in the English language, and it does not mean "unanimity". In PEP 1, it means that some people agree, most people don't disagree, and even if a senior person disagrees, they're willing to go along with the "sense of the community". As that adjective "senior" implies, some people count more to the consensus than others. Usually when I write "senior" I'm referring to core developers (committers), but here there people who are "senior" enough despite not having commit bits.[1]
"The community" is not well defined, and it can't be, short of a doctoral dissertation in anthropology. The relevant channels are open-participation, some people speak for themselves, some people are "official" representatives of important constituencies such as the leaders of large independent projects or alternative implementations, and some people have acquired sufficient reputation to be considered representative of a group of people (especially when other members of the group rarely participate in the dev lists but for some reason are considered important to the community -- I'm thinking in particular of sysadmins and devops, and the problems we can cause them by messing with packaging and installation).
References to the BDFL are, of course, in limbo. AFAIK we don't have one at the moment. Until we do, any PEPs will presumably be accepted either by a self-nominated BDFL-Delegate acceptable to the core devs, or by an ad hoc committee of interested core devs, and that part of PEP 1 can't be usefully updated yet. This is not a weakness of the Python project, IMO. Rather, the fact that, despite a sort of constitutional crisis, the whole process is continuing pretty much as usual shows its strength.
This is possible because the BDFL is not, and has not been for many years, a "hands-on" manager. It's true that where a proposal affects his own "development *in* Python", he's likely to work closely with a proponent, off- and on-list, or even *be* the proponent. Of course such proposals are more likely to be approved, and a few community members have pushed back on that because it appears undemocratic. But the general reaction is "maybe 'Although that way may not be obvious at first unless you're Dutch' applies to me in such cases!" For most proposals, he's "just" a very senior developer whose comments are important because he's a great developer, but he is easily swayed by the sense of the community. Bottom line: except in the rare case where your proposal directly affects the BDFL's own coding, the BDFL's now-traditional role is to declare that consensus has been achieved, postpone the PEP because it's clear that consensus is not forming, or in rare cases, make a choice despite the lack of consensus.
But none of this is really of importance to a PEP proponent ("champion" in the terminology of PEP 1). PEP 1 is quite specific about the required components of the document, and many points of formatting and style. Accept the uncertainty, and do what you need to do to meet those requirements, that's all there is to it. If the community wants more, or wants changes, it will tell you, either as a demand about style or missing content from an editor or as a technical comment on the list. Whether you accept those technical comments is up to you, but your star will rise far more rapidly if you are very sensitive to claims that "this change to the PEP will a big improvement for some significant consituency in the community". If you want advice on whether the chance of acceptance is high enough to be worth putting in more work, ask the BDFL-Delegate (or the BDFL if she/he has "claimed" the PEP) where the proposal has an official adjudicator, and if not, a senior core developer.
If one doesn't know who the senior developers are yet, she should think twice about whether she's ready to PEP anything. That's not a litmus test; some PEPs have eventually succeeded though the proponent was new to the project development process.[2] But it's a lot less painful if you can tell who's likely to be able to sway the whole project one way or the other. And as a matter of improving your proposal, who surely does know more about what your proposal implies for the implementation than you do, so you should strongly consider whether *you* are the one who's missing something when you disagree with them.
Footnotes: [1] They are familiar to some of the core developers as drivers of important projects developing *in* Python.
[2] The ones I can think of involve the same kind of person as footnote 1, and a co-proponent who was a core developer.
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
If one doesn't know who the senior developers are yet, she should think twice about whether she's ready to PEP anything. That's not a litmus test; some PEPs have eventually succeeded though the proponent was new to the project development process.[2] But it's a lot less painful if you can tell who's likely to be able to sway the whole project one way or the other.
I think that entire paragraph made it sound even worse than what I wrote originally. It reads to an outsider as “if you don’t know what’s wrong I’m not going to tell you”.
And as a matter of improving your proposal, who surely does know more about what your proposal implies for the implementation than you do, so you should strongly consider whether *you* are the one who's missing something when you disagree with them.
Is this me specifically or “you” in the abstract? English isn’t great here. I personally supplied a complete implementation so don’t see how this applies to me? / Anders
On Sat, 22 Sep 2018 at 10:56, Anders Hovmöller <boxed@killingar.net> wrote:
If one doesn't know who the senior developers are yet, she should think twice about whether she's ready to PEP anything. That's not a litmus test; some PEPs have eventually succeeded though the proponent was new to the project development process.[2] But it's a lot less painful if you can tell who's likely to be able to sway the whole project one way or the other.
I think that entire paragraph made it sound even worse than what I wrote originally. It reads to an outsider as “if you don’t know what’s wrong I’m not going to tell you”.
And as a matter of improving your proposal, who surely does know more about what your proposal implies for the implementation than you do, so you should strongly consider whether *you* are the one who's missing something when you disagree with them.
Is this me specifically or “you” in the abstract? English isn’t great here.
I personally supplied a complete implementation so don’t see how this applies to me?
/ Anders _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Sorry, hit send too soon... On Sat, 22 Sep 2018 at 13:24, Paul Moore <p.f.moore@gmail.com> wrote:
On Sat, 22 Sep 2018 at 10:56, Anders Hovmöller <boxed@killingar.net> wrote:
If one doesn't know who the senior developers are yet, she should think twice about whether she's ready to PEP anything. That's not a litmus test; some PEPs have eventually succeeded though the proponent was new to the project development process.[2] But it's a lot less painful if you can tell who's likely to be able to sway the whole project one way or the other.
I think that entire paragraph made it sound even worse than what I wrote originally. It reads to an outsider as “if you don’t know what’s wrong I’m not going to tell you”.
More like, if you're not sufficiently familiar with the community or the language, you have some research to do to get to a point where your proposals are likely to be sufficiently well informed. People could simply tell you the facts, but that wouldn't help with the process of becoming familiar with the community/language. Yes, that's a barrier to people making proposals. But not all barriers to entry are bad - this one says, do your research in advance, which IMO is a bare minimum people should expect to need to do... Paul
I think that entire paragraph made it sound even worse than what I wrote originally. It reads to an outsider as “if you don’t know what’s wrong I’m not going to tell you”.
More like, if you're not sufficiently familiar with the community or the language,
And now you made it sound even worse by insinuating that I don’t know the language and maybe I’m not a part of the community. / Anders
On Sat, Sep 22, 2018 at 5:53 AM Anders Hovmöller <boxed@killingar.net> wrote:
I think that entire paragraph made it sound even worse than what I
wrote originally. It reads to an outsider as “if you don’t know what’s wrong I’m not going to tell you”.
More like, if you're not sufficiently familiar with the community or the language,
And now you made it sound even worse by insinuating that I don’t know the language and maybe I’m not a part of the community.
Anders, I'm sorry you feel that everyone is piling onto you. I don't think they intend to pick specifically on you at all. What Stephen and Paul are describing applies to everyone who wants to write a PEP. I think collectively we haven't spent enough time writing up guidelines for new PEP authors to make it possible for someone to start writing a PEP without asking questions about how to write a PEP. I think part of the problem is that every author has a different background -- some folks come with great technical and writing skills but without much experience with how debate works in the Python (core dev) community; others have experience using the language and interacting with the community and have good ideas but lack writing skills or understanding of the technicalities of parsers and interpreters. So instead of writing a complete guide to writing a PEP (and getting it approved), we have to answer questions and help prospective authors based on the text they show us. I have to admit that I've not followed the full context, but I recommend that you try to see that other posters in this thread are trying to help with kindness, not judging you or your skills. Good luck with your PEP, whatever it is about! -- --Guido van Rossum (python.org/~guido)
And now you made it sound even worse by insinuating that I don’t know the language and maybe I’m not a part of the community.
Anders, I'm sorry you feel that everyone is piling onto you.
Well a bit, but mostly I was just pointing out that the text I replied to wasn’t thought out and made it sound worse than it is (I think!).
I don't think they intend to pick specifically on you at all.
Agreed. It’s also maybe a consequence of using English where “thou”, “you” and “one” has been merged into one word, creating ambiguity.
What Stephen and Paul are describing applies to everyone who wants to write a PEP.
Sure, but that there isn’t a list of people who form the deciding committee makes it very strange. That it applies to everyone doesn’t make it better, it makes it worse.
we have to answer questions and help prospective authors based on the text they show us.
Also agreed. The fastest responses on this list tend to be the most hostile and least constructive also, so if you read it after the fact and don’t pay close attention to the chronology it looks nicer than how it feels posting here.
I have to admit that I've not followed the full context, but I recommend that you try to see that other posters in this thread are trying to help with kindness, not judging you or your skills. Good luck with your PEP, whatever it is about!
Sure. But I’m also pointing out that they are being (accidentally?) brusque. I know I am all the time! I keep apologizing and trying to backpedal when I realize I wasn’t understood in the way I was attempting. / Anders
On Sat, Sep 22, 2018 at 8:52 AM Anders Hovmöller <boxed@killingar.net> wrote:
I think that entire paragraph made it sound even worse than what I wrote originally. It reads to an outsider as “if you don’t know what’s wrong I’m not going to tell you”.
More like, if you're not sufficiently familiar with the community or the language,
And now you made it sound even worse by insinuating that I don’t know the language and maybe I’m not a part of the community.
Anders, I think you're reading too much into what Paul and Stephen are writing. To me it seems they are just explaining the landscape of how the PEP process typically plays out. I don't think their comments are insinuating anything.
On 09/22/2018 05:52 AM, Anders Hovmöller wrote:
And now you made it sound even worse [...]
Their use of the word "you" is "everybody who wants to write a PEP", not you "Anders Hovmöller" specifically. (Isn't English a wonderful language? *sigh* ) -- ~Ethan~
Anders Hovmöller writes:
If one doesn't know who the senior developers are yet, she should think twice about whether she's ready to PEP anything. That's not a litmus test; some PEPs have eventually succeeded though the proponent was new to the project development process.[2] But it's a lot less painful if you can tell who's likely to be able to sway the whole project one way or the other.
I think that entire paragraph made it sound even worse than what I wrote originally. It reads to an outsider as “if you don’t know what’s wrong I’m not going to tell you”.
"What's wrong" *with what*? Nothing in that paragraph implies that anything is wrong with anything. I wrote that post for your benefit *among others* but it's not about you. It's about how Python development makes decisions about whether to implement a proposal (specifically, PEPs) or not. Understanding how things work currently will help new contributors get their proposals implemented, or at least understand why those proposals weren't accepted. Unfortunately, there seems to be a lot of misunderstanding about these very basic processes, among a half-dozen or more newcomers who are posting about governance. I want to clear that up. Personally, I think Python governance is fine, but for those who don't, they should at least understand what it *is* before they start proposing modifications.
And as a matter of improving your proposal, who surely does know more about what your proposal implies for the implementation than you do, so you should strongly consider whether *you* are the one who's missing something when you disagree with them.
Is this me specifically or “you” in the abstract? English isn’t great here.
Nothing in that post is about you, it's just that your post triggered mine, and a quote from your post was a convenient lead-in to a discussion of several aspects of the PEP process (and more generally the decision to implement a feature or not) that are pretty opaque to most newcomers. Regards,
If one doesn't know who the senior developers are yet, she should think twice about whether she's ready to PEP anything. That's not a litmus test; some PEPs have eventually succeeded though the proponent was new to the project development process.[2] But it's a lot less painful if you can tell who's likely to be able to sway the whole project one way or the other.
I think that entire paragraph made it sound even worse than what I wrote originally. It reads to an outsider as “if you don’t know what’s wrong I’m not going to tell you”.
"What's wrong" *with what*? Nothing in that paragraph implies that anything is wrong with anything.
Sorry. I was vague. Let me try to explain what I meant. It’s a common trope that people who are bad at relationships expect their partners to be mind readers. This is exemplified by the expression I quoted: “if you don’t know what’s wrong, I’m not going to tell you”. This is funny/sad because it is precisely when someone doesn’t know something that it is important to tell them instead of clamming up and refuse further information. Me and others have pointed out that we can’t figure out and the docs don’t say how the change process happens. The response to this was
If one doesn't know who the senior developers are yet, she should think twice about whether she's ready to PEP anything
I can’t see how this is different from the trope. Is there a committee? Then why not just name it? How does one figure this out? Should I just do some statistics on the git repo and surmise that the top committers are the committee? Do I have to read the commit log and all mails in this mailing list and Python-dev the last 10 years? Do I need a time machine so I can attend sprints and pycons and core developer meetings that have already happened? Is there a secret handshake? I am being a bit silly with these suggestions but it’s to point out that I see no way to exclude any of those possibilities from PEP1 or your mails. In fact they seem to me less like silly examples now than before your mails.
Is this me specifically or “you” in the abstract? English isn’t great here.
Nothing in that post is about you, it's just that your post triggered mine, and a quote from your post was a convenient lead-in to a discussion of several aspects of the PEP process (and more generally the decision to implement a feature or not) that are pretty opaque to most newcomers.
Good. Thanks for the clarification. / Anders
On Sat, Sep 22, 2018 at 2:00 PM Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
If one doesn't know who the senior developers are yet, she should think twice about whether she's ready to PEP anything.
On Sat, Sep 22, 2018 at 4:03 PM Anders Hovmöller <boxed@killingar.net> wrote:
Is there a committee? Then why not just name it? How does one figure this out?
I sympathise, because I think the documentation could be more clear. There is a list of people with "push" privileges and a little bit of why they gained that privilege, or at least from whom. There's also a list of their interests, which corresponds somewhat to which modules they're "in charge of". https://devguide.python.org/developers/ https://devguide.python.org/experts/ Note that there isn't a listing for syntax or builtins. Perhaps that should be remedied, but it'd require a volunteer. Further, now that Guido has abdicated, the process for PEP approval is uncertain.
Michael Selik writes:
On Thu, Sep 20, 2018 at 2:13 AM Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
That's because completion of discussion has never been a requirement for writing a PEP.
Not for drafting, but for submitting. For my own PEP submission, I received the specific feedback that it needed a "proper title" before being assigned a PEP number.
What does that have to do with "completion of discussion"? I don't know what the editor told you, but in the PEP "proper title" is well- defined and not very stringent: "accurately describes the content".
My goal for submitting the draft was to receive a PEP number to avoid the awkwardness of discussing a PEP without an obvious title. Perhaps PEP 1 should be revised to clarify the expectations for PEP submission.
Good point. That's definitely grounds for refusing to approve the PEP, but the approval criteria are in the section "PEP Editor Responsibilities & Workflow". I'm submitting a pull request (python/peps #789 on GitHub) to also put it in the section "Submitting a PEP", under the bullet "The PEP editors review your PR for structure, formatting, and other errors." Steve
On Tue, Sep 18, 2018 at 8:21 PM James Lu <jamtlu@gmail.com> wrote:
Is that really an issue here? I personally haven't seen threads where Brett tried to stop an active discussion, but people ignored him and kept fighting. Not personally with Brett, but I have seen multiple people try to stop the “reword or remove beautiful is better than ugly in Zen of Python.” The discussion was going in circles and evolved into attacking each other’s use of logical fallacies.
I disagree with your description, of course, but that's not important right now. Multiple people *without any authority in that forum* tried to stop a discussion, and failed. Why would it be any different if it happened in a forum? Those same people still wouldn't have the power to lock the discussion. They could only try to convince others to stop. If the ones with authority wanted to completely shut down the discussion, they can do so now. The only thing that a forum adds is, when they say stop, no one can decide to ignore them. If no one is ignoring them now, then locking powers don't add anything.
Other than that, my biggest issues with the current mailing system are:
* There’s no way to keep a updated proposal of your own- if you decide to change your proposal, you have to communicate the change. Then, if you want to find the authoritative current copy, since you might’ve forgotten or you want to join he current discussion, then you have to dig through the emails and recursively apply the proposed change. It’s just easier if people can have one proposal they can edit themselves. * I’ve seen experienced people get confused about what was the current proposal because they were replying to older emails or they didn’t see the email with the clear examples.
I agree that editing is a very useful feature. In a large discussion, newcomers can comment after reading only the first few posts, and if the first post has an easily-misunderstood line, you'll get people talking about it. For proposals, I'm concerned that many forums don't have version history in their editing tools (Reddit being one such discussion site). Version history can be useful in understanding old comments. Instead, you'd have to put it up on a repo and link to it. Editing will help when you realize you should move your proposal to a public repo.
* The mailing list is frankly obscure. Python community leaders and package maintainers often are not aware or do not participate in Python-ideas. Not many people know how to use or navigate a mailing list. * No one really promotes the mailing list, you have to go out of your way to find where new features are proposed. * Higher discoverability means more people can participate, providing their own use cases or voting (I mean using like or dislike measures, consensus should still be how things are approved) go out of their way to find so they can propose something. Instead, I envision a forum where people can read and give their 2 cents about what features they might like to see or might not want to see.
Some of these problems are not about mailing lists. Whether a forum is more accessible can go either way. A mailing list is more accessible because everyone has access to email, and it doesn't require making another account. It is less accessible because people might get intimidated by such old interfaces or culture (like proper quoting etiquette, or when to switch to private replies). Setting up an email interface to a forum can be a compromise.
* More people means instead of having to make decisions from sometimes subjective personal experience, we can make decisions with confidence in what other Python devs want.
I don't agree. You don't get more objective by getting a larger self-selected sample, not without carefully designing who will self-select. But getting more people means getting MORE subjective personal experiences, which is good. Some proposals need more voices, like any proposal that is meant to help new programmers. You want to hear from people who still vividly remember their experiences learning Python. On the other hand, getting more people necessarily means more noise (no matter what system you use), and less time for new people to acclimate.
Since potential proposers will find it easier to navigate a GUI forum, they can read previous discussions to understand the reasoning, precedent behind rejected and successful features. People proposing things that have already been rejected before can be directed to open a subtopic on the older discussion.
A kind of GUI version already exists, precisely because this is a public mailing list. Google Groups provides a mirror of the archives. https://groups.google.com/forum/#!forum/python-ideas It's searchable, and possibly replyable. You can even star conversations (but not hide them). If it isn't listed on some python.org page, maybe it should be. Personally, when I want to find past discussions, I use Google with the keyword `site:https://mail.python.org/pipermail/python-ideas/`. I know a lot of people don't know about that, though. Maybe it can be listed on one of the python.org pages. As for subtopics, I haven't seen such things. I've seen reply subtrees, but either they don't bump the topic (giving them little visibility), or they do bump the topic (annoying anyone as much as a new topic). I don't know if there is a good compromise there.
Oh wow, Google Groups is actually a much better interface. Any better forum software needs a system where people can voluntarily leave comments or feedback that is lower-priority. I'm not sure if Discourse has this, actually. Reddit comments are extremely compact as are Stack Overflow comments. I was going to propose that the PSF twitter account post a link to https://groups.google.com/forum/#!topic/python-ideas/, but I was worried that getting more subjective personal experiences might undesirably decrease the signal-to-noise ratio. On Wed, Sep 19, 2018 at 12:48 AM Franklin? Lee < leewangzhong+python@gmail.com> wrote:
On Tue, Sep 18, 2018 at 8:21 PM James Lu <jamtlu@gmail.com> wrote:
Is that really an issue here? I personally haven't seen threads where Brett tried to stop an active discussion, but people ignored him and kept fighting. Not personally with Brett, but I have seen multiple people try to stop
the “reword or remove beautiful is better than ugly in Zen of Python.” The discussion was going in circles and evolved into attacking each other’s use of logical fallacies.
I disagree with your description, of course, but that's not important right now.
Multiple people *without any authority in that forum* tried to stop a discussion, and failed. Why would it be any different if it happened in a forum? Those same people still wouldn't have the power to lock the discussion. They could only try to convince others to stop.
If the ones with authority wanted to completely shut down the discussion, they can do so now. The only thing that a forum adds is, when they say stop, no one can decide to ignore them. If no one is ignoring them now, then locking powers don't add anything.
Other than that, my biggest issues with the current mailing system are:
* There’s no way to keep a updated proposal of your own- if you decide to change your proposal, you have to communicate the change. Then, if you want to find the authoritative current copy, since you might’ve forgotten or you want to join he current discussion, then you have to dig through the emails and recursively apply the proposed change. It’s just easier if people can have one proposal they can edit themselves. * I’ve seen experienced people get confused about what was the current proposal because they were replying to older emails or they didn’t see the email with the clear examples.
I agree that editing is a very useful feature. In a large discussion, newcomers can comment after reading only the first few posts, and if the first post has an easily-misunderstood line, you'll get people talking about it.
For proposals, I'm concerned that many forums don't have version history in their editing tools (Reddit being one such discussion site). Version history can be useful in understanding old comments. Instead, you'd have to put it up on a repo and link to it. Editing will help when you realize you should move your proposal to a public repo.
* The mailing list is frankly obscure. Python community leaders and package maintainers often are not aware or do not participate in Python-ideas. Not many people know how to use or navigate a mailing list. * No one really promotes the mailing list, you have to go out of your way to find where new features are proposed. * Higher discoverability means more people can participate, providing their own use cases or voting (I mean using like or dislike measures, consensus should still be how things are approved) go out of their way to find so they can propose something. Instead, I envision a forum where people can read and give their 2 cents about what features they might like to see or might not want to see.
Some of these problems are not about mailing lists.
Whether a forum is more accessible can go either way. A mailing list is more accessible because everyone has access to email, and it doesn't require making another account. It is less accessible because people might get intimidated by such old interfaces or culture (like proper quoting etiquette, or when to switch to private replies). Setting up an email interface to a forum can be a compromise.
* More people means instead of having to make decisions from sometimes subjective personal experience, we can make decisions with confidence in what other Python devs want.
I don't agree. You don't get more objective by getting a larger self-selected sample, not without carefully designing who will self-select.
But getting more people means getting MORE subjective personal experiences, which is good. Some proposals need more voices, like any proposal that is meant to help new programmers. You want to hear from people who still vividly remember their experiences learning Python.
On the other hand, getting more people necessarily means more noise (no matter what system you use), and less time for new people to acclimate.
Since potential proposers will find it easier to navigate a GUI forum, they can read previous discussions to understand the reasoning, precedent behind rejected and successful features. People proposing things that have already been rejected before can be directed to open a subtopic on the older discussion.
A kind of GUI version already exists, precisely because this is a public mailing list. Google Groups provides a mirror of the archives. https://groups.google.com/forum/#!forum/python-ideas It's searchable, and possibly replyable. You can even star conversations (but not hide them). If it isn't listed on some python.org page, maybe it should be.
Personally, when I want to find past discussions, I use Google with the keyword `site:https://mail.python.org/pipermail/python-ideas/` <https://mail.python.org/pipermail/python-ideas/>. I know a lot of people don't know about that, though. Maybe it can be listed on one of the python.org pages.
As for subtopics, I haven't seen such things. I've seen reply subtrees, but either they don't bump the topic (giving them little visibility), or they do bump the topic (annoying anyone as much as a new topic). I don't know if there is a good compromise there.
On Wed, 19 Sep 2018 11:54:20 -0400 James Lu <jamtlu@gmail.com> wrote:
Oh wow, Google Groups is actually a much better interface.
Depends who you talk to. For me, having to use the Google Groups UI would be a strong impediment to my continued contribution. Regards Antoine.
Any better forum software needs a system where people can voluntarily leave comments or feedback that is lower-priority. I'm not sure if Discourse has this, actually. Reddit comments are extremely compact as are Stack Overflow comments.
I was going to propose that the PSF twitter account post a link to https://groups.google.com/forum/#!topic/python-ideas/, but I was worried that getting more subjective personal experiences might undesirably decrease the signal-to-noise ratio.
On Wed, Sep 19, 2018 at 12:48 AM Franklin? Lee < leewangzhong+python@gmail.com> wrote:
On Tue, Sep 18, 2018 at 8:21 PM James Lu <jamtlu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Is that really an issue here? I personally haven't seen threads where Brett tried to stop an active discussion, but people ignored him and kept fighting. Not personally with Brett, but I have seen multiple people try to stop
the “reword or remove beautiful is better than ugly in Zen of Python.” The discussion was going in circles and evolved into attacking each other’s use of logical fallacies.
I disagree with your description, of course, but that's not important right now.
Multiple people *without any authority in that forum* tried to stop a discussion, and failed. Why would it be any different if it happened in a forum? Those same people still wouldn't have the power to lock the discussion. They could only try to convince others to stop.
If the ones with authority wanted to completely shut down the discussion, they can do so now. The only thing that a forum adds is, when they say stop, no one can decide to ignore them. If no one is ignoring them now, then locking powers don't add anything.
Other than that, my biggest issues with the current mailing system are:
* There’s no way to keep a updated proposal of your own- if you decide to change your proposal, you have to communicate the change. Then, if you want to find the authoritative current copy, since you might’ve forgotten or you want to join he current discussion, then you have to dig through the emails and recursively apply the proposed change. It’s just easier if people can have one proposal they can edit themselves. * I’ve seen experienced people get confused about what was the current proposal because they were replying to older emails or they didn’t see the email with the clear examples.
I agree that editing is a very useful feature. In a large discussion, newcomers can comment after reading only the first few posts, and if the first post has an easily-misunderstood line, you'll get people talking about it.
For proposals, I'm concerned that many forums don't have version history in their editing tools (Reddit being one such discussion site). Version history can be useful in understanding old comments. Instead, you'd have to put it up on a repo and link to it. Editing will help when you realize you should move your proposal to a public repo.
* The mailing list is frankly obscure. Python community leaders and package maintainers often are not aware or do not participate in Python-ideas. Not many people know how to use or navigate a mailing list. * No one really promotes the mailing list, you have to go out of your way to find where new features are proposed. * Higher discoverability means more people can participate, providing their own use cases or voting (I mean using like or dislike measures, consensus should still be how things are approved) go out of their way to find so they can propose something. Instead, I envision a forum where people can read and give their 2 cents about what features they might like to see or might not want to see.
Some of these problems are not about mailing lists.
Whether a forum is more accessible can go either way. A mailing list is more accessible because everyone has access to email, and it doesn't require making another account. It is less accessible because people might get intimidated by such old interfaces or culture (like proper quoting etiquette, or when to switch to private replies). Setting up an email interface to a forum can be a compromise.
* More people means instead of having to make decisions from sometimes subjective personal experience, we can make decisions with confidence in what other Python devs want.
I don't agree. You don't get more objective by getting a larger self-selected sample, not without carefully designing who will self-select.
But getting more people means getting MORE subjective personal experiences, which is good. Some proposals need more voices, like any proposal that is meant to help new programmers. You want to hear from people who still vividly remember their experiences learning Python.
On the other hand, getting more people necessarily means more noise (no matter what system you use), and less time for new people to acclimate.
Since potential proposers will find it easier to navigate a GUI forum, they can read previous discussions to understand the reasoning, precedent behind rejected and successful features. People proposing things that have already been rejected before can be directed to open a subtopic on the older discussion.
A kind of GUI version already exists, precisely because this is a public mailing list. Google Groups provides a mirror of the archives. https://groups.google.com/forum/#!forum/python-ideas It's searchable, and possibly replyable. You can even star conversations (but not hide them). If it isn't listed on some python.org page, maybe it should be.
Personally, when I want to find past discussions, I use Google with the keyword `site:https://mail.python.org/pipermail/python-ideas/` <https://mail.python.org/pipermail/python-ideas/>. I know a lot of people don't know about that, though. Maybe it can be listed on one of the python.org pages.
As for subtopics, I haven't seen such things. I've seen reply subtrees, but either they don't bump the topic (giving them little visibility), or they do bump the topic (annoying anyone as much as a new topic). I don't know if there is a good compromise there.
On Wed, Sep 19, 2018 at 7:49 AM Franklin? Lee <leewangzhong+python@gmail.com> wrote:
On Tue, Sep 18, 2018 at 8:21 PM James Lu <jamtlu@gmail.com> wrote:
Is that really an issue here? I personally haven't seen threads where Brett tried to stop an active discussion, but people ignored him and kept fighting. Not personally with Brett, but I have seen multiple people try to stop the “reword or remove beautiful is better than ugly in Zen of Python.” The discussion was going in circles and evolved into attacking each other’s use of logical fallacies.
Multiple people *without any authority in that forum* tried to stop a discussion, and failed. Why would it be any different if it happened in a forum? Those same people still wouldn't have the power to lock the discussion. They could only try to convince others to stop.
It would be different because some people use private mail addresses, and might not be very happy to start the day by seeing political/personal/meta/uninteresting/etc. discussions in mailbox. This aspect alone would make _any_ forum-like approach far better than mailing list. Mikhail
On Tue, 18 Sep 2018 18:37:09 -0400 James Lu <jamtlu@gmail.com> wrote:
* The mailing list is frankly obscure. Python community leaders and package maintainers often are not aware or do not participate in Python-ideas. Not many people know how to use or navigate a mailing list. * No one really promotes the mailing list, you have to go out of your way to find where new features are proposed. * Higher discoverability means more people can participate, providing their own use cases or voting (I mean using like or dislike measures, consensus should still be how things are approved) go out of their way to find so they can propose something. Instead, I envision a forum where people can read and give their 2 cents about what features they might like to see or might not want to see.
I'm not sure that's a popular opinion, but I don't think I want more people around on python-ideas. There's enough quantity here. The problem is quality. Regards Antoine.
Le 19/09/2018 à 00:37, James Lu a écrit :
Is that really an issue here? I personally haven't seen threads where Brett tried to stop an active discussion, but people ignored him and kept fighting. Not personally with Brett, but I have seen multiple people try to stop the “reword or remove beautiful is better than ugly in Zen of Python.” The discussion was going in circles and evolved into attacking each other’s use of logical fallacies.
Other than that, my biggest issues with the current mailing system are:
* There’s no way to keep a updated proposal of your own- if you decide to change your proposal, you have to communicate the change. Then, if you want to find the authoritative current copy, since you might’ve forgotten or you want to join he current discussion, then you have to dig through the emails and recursively apply the proposed change. It’s just easier if people can have one proposal they can edit themselves. * I’ve seen experienced people get confused about what was the current proposal because they were replying to older emails or they didn’t see the email with the clear examples. * The mailing list is frankly obscure. Python community leaders and package maintainers often are not aware or do not participate in Python-ideas. Not many people know how to use or navigate a mailing list. * No one really promotes the mailing list, you have to go out of your way to find where new features are proposed. * Higher discoverability means more people can participate, providing their own use cases or voting (I mean using like or dislike measures, consensus should still be how things are approved) go out of their way to find so they can propose something. Instead, I envision a forum where people can read and give their 2 cents about what features they might like to see or might not want to see. * More people means instead of having to make decisions from sometimes subjective personal experience, we can make decisions with confidence in what other Python devs want.
Since potential proposers will find it easier to navigate a GUI forum, they can read previous discussions to understand the reasoning, precedent behind rejected and successful features. People proposing things that have already been rejected before can be directed to open a subtopic on the older discussion.
+1 except for visibility I have been on this list for years and those issues have been a big problem ever since. But I agree with Antoine, quantity is not the problem. Quality is. However having no way to moderate efficiently means nobody does it, which means quality goes down. Since you have no way to identify who is who anyway, you can't know if the person telling you that you are out of line is an experienced member of the community or a newcomer with a lot of energy. Another things is that we keep having the same debates over and over. If you had the same duplication in code, it would never pass code reviews. The problem is looking up something, or making a reference to something is really hard on the list. A few scenario that seem important to me that are badly handled by this tool: - Person A is making a long constructive argument, and person B arrives, doesn't read anything, and make arguments against things that have been answered. It should be easy for somebody to link to the answers to this. - Somebody is making a proposal that has been already discussed and rejected several times. It should be easy to link to the discussions and conclusions about this. Even if the goal is to start the debate over again, at least we start ahead. - A is telling B this is a bad idea. It should be easy to tell if the person is experienced or not. You probably don't want to interact the same way with Victor and Yury, that have done numerous contributions to the Python core, and me, that is just a regular Python dev and don't know how the implementation work. - somebody wants to make a proposal. It should be easy to search if similar proposals already have been made, and read __ a summary __ of what happened. The bar to write a PEP is to high to serve that purpose: most proposal don't ever leave the list.
On Wed, Sep 19, 2018 at 11:23 PM Michel Desmoulin <desmoulinmichel@gmail.com> wrote:
- A is telling B this is a bad idea. It should be easy to tell if the person is experienced or not. You probably don't want to interact the same way with Victor and Yury, that have done numerous contributions to the Python core, and me, that is just a regular Python dev and don't know how the implementation work.
Hmm, I'm not sure about this. Shouldn't a person's arguments be assessed on their own merit, rather than "oh, so-and-so said it so it must be right"? But if you want to research the people who are posting, you're welcome to do that. The list of core dev experts is on the devguide: https://devguide.python.org/experts/ Translating those usernames back into real names would be done via BPO, I think. ChrisA
Le 19/09/2018 à 15:28, Chris Angelico a écrit :
On Wed, Sep 19, 2018 at 11:23 PM Michel Desmoulin <desmoulinmichel@gmail.com> wrote:
- A is telling B this is a bad idea. It should be easy to tell if the person is experienced or not. You probably don't want to interact the same way with Victor and Yury, that have done numerous contributions to the Python core, and me, that is just a regular Python dev and don't know how the implementation work.
Hmm, I'm not sure about this. Shouldn't a person's arguments be assessed on their own merit, rather than "oh, so-and-so said it so it must be right"?
"Merit" is something hard to evaluate, having context help. If somebody comes and says "this is hard to implement so I doubt it will pass", Tim Peters does know better than the average Joe. If somebody says, "I advise you to do things the other way around, it works better on this mailing list". You will consider the advice more strongly if the author has been on the list 10 years or 10 days. Above all, if 2 people have opposite views, and that they both make sense, having the context of who they are helping. It's the same has if somebody gives you health advice. You do want to listen to everybody, but it's nice to know who is a doctor, and who is a somebody who repeats Facebook posts. It helps to decide.
But if you want to research the people who are posting, you're welcome to do that. The list of core dev experts is on the devguide:
https://devguide.python.org/experts/
Translating those usernames back into real names would be done via BPO, I think.
This is a good summary of the problem with the list: you can do anything you want, but it cost you time and effort. And since you have many things to do, cumulatively, it's a lot of time and effort. I read all the posts and answered 2 mails on the list today. It took me 40 minutes. And I have been on the list for a long time so I know how the whole thing works so I'm pretty fast at doing this. Who can spend a lot of time every day, and yet feels to be just barely part of the discussion ? Who will take the time to do things right ? And among those few people, couldn't they do more good things if we'd save them time and energy ? Let's make the tool work for the community, and not against it. I agree that the mailing list is a great format for things like Python-dev. However, it's not a good fit for Python-idea: we have reached the limit of it for a long time. Most of the real decisions are actually taken outside of it, with more direct channels in the small groups of contributors. It slows down the decision process and it waste a lot of good will.
ChrisA _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Most of the real decisions are actually taken outside of it, with more direct channels in the small groups of contributors.
It would be very nice if there was more transparency in this process. The language is better if more subjective personal experience heard- but to make that happen, the forum experience must be better for both On Tuesday, September 18, 2018 at 8:21:46 PM UTC-4, James Lu wrote:
Is that really an issue here? I personally haven't seen threads where Brett tried to stop an active discussion, but people ignored him and kept fighting. Not personally with Brett, but I have seen multiple people try to stop the “reword or remove beautiful is better than ugly in Zen of Python.” The discussion was going in circles and evolved into attacking each other’s use of logical fallacies.
Other than that, my biggest issues with the current mailing system are:
* There’s no way to keep a updated proposal of your own- if you decide to change your proposal, you have to communicate the change. Then, if you want to find the authoritative current copy, since you might’ve forgotten or you want to join he current discussion, then you have to dig through the emails and recursively apply the proposed change. It’s just easier if people can have one proposal they can edit themselves. * I’ve seen experienced people get confused about what was the current proposal because they were replying to older emails or they didn’t see the email with the clear examples. * The mailing list is frankly obscure. Python community leaders and package maintainers often are not aware or do not participate in Python-ideas. Not many people know how to use or navigate a mailing list. * No one really promotes the mailing list, you have to go out of your way to find where new features are proposed. * Higher discoverability means more people can participate, providing their own use cases or voting (I mean using like or dislike measures, consensus should still be how things are approved) go out of their way to find so they can propose something. Instead, I envision a forum where people can read and give their 2 cents about what features they might like to see or might not want to see. * More people means instead of having to make decisions from sometimes subjective personal experience, we can make decisions with confidence in what other Python devs want.
Since potential proposers will find it easier to navigate a GUI forum, they can read previous discussions to understand the reasoning, precedent behind rejected and successful features. People proposing things that have already been rejected before can be directed to open a subtopic on the older discussion.
On Sep 18, 2018, at 3:19 PM, python-ideas-request@python.org wrote:
Is that really an issue here? I personally haven't seen threads where Brett tried to stop an active discussion, but people ignored him and kept fighting.
Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Just an observation. I've been a member of this mailing list since (literally) five days ago and I am receiving a busload of emails. I'm a member of Stackoverflow and I visit the Q&A site daily... and I hardly ever receive emails. I suspect Discourse would be a good match for these discussions (although I have no experience whatsoever with it). TL;DR; I would appreciate receiving less mail. Cheers, Hans
-----Original Message----- From: Python-ideas <python-ideas-bounces+tritium- list=sdamon.com@python.org> On Behalf Of Hans Polak Sent: Wednesday, September 19, 2018 12:36 PM To: python-ideas@python.org Subject: Re: [Python-ideas] Moving to another forum system where
Just an observation. I've been a member of this mailing list since (literally) five days ago and I am receiving a busload of emails.
I'm a member of Stackoverflow and I visit the Q&A site daily... and I hardly ever receive emails.
I suspect Discourse would be a good match for these discussions (although I have no experience whatsoever with it).
TL;DR; I would appreciate receiving less mail.
I don’t think its unreasonable to point out that it’s a *mailing list*. A firehose of email is generally a sign of good health of a mailing list. Even so, there are mitigations to the firehose effect, including, but not limited to digests and setting up your client to move mailing list posts directly to a folder (including the trash for threads you don’t want to follow). I don't understand how one can sign up for a mass email discussion forum, and be surprised that it increased the amount of email they receive. It's kind of the point of the medium.
Cheers, Hans
Even so, there are mitigations to the firehose effect, including, but not limited to digests
I accidentally signed up with divest turned on for this list first. I got five digests in so many hours and I couldn’t figure out how to respond to individual threads. It’s a terrible choice and I personally would recommend removing the option because it seems broken or at least unusable. / Anders
I don’t think its unreasonable to point out that it’s a *mailing list*. A firehose of email is generally a sign of good health of a mailing list. Even so, there are mitigations to the firehose effect, including, but not limited to digests and setting up your client to move mailing list posts directly to a folder (including the trash for threads you don’t want to follow). I don't understand how one can sign up for a mass email discussion forum, and be surprised that it increased the amount of email they receive. It's kind of the point of the medium.
Right you are, Alex. I don’t think its unreasonable to point out that the title of this thread is "Moving to another forum". If you want to contribute Python Ideas you *have to* subscribe to the mailing list. Let me just say that I second the idea of moving to another forum. I already move most mail automatically to the trash folder and read it there before eliminating it. My inbox contains exactly four emails at the moment, FYI. Cheers, Hans
-----Original Message----- From: Hans Polak <hpolak@polak.es> Sent: Thursday, September 20, 2018 3:38 AM To: Alex Walters <tritium-list@sdamon.com>; python-ideas@python.org Subject: Re: [Python-ideas] Moving to another forum system where
I don’t think its unreasonable to point out that it’s a *mailing list*. A firehose of email is generally a sign of good health of a mailing list. Even so, there are mitigations to the firehose effect, including, but not limited to digests and setting up your client to move mailing list posts directly to a folder (including the trash for threads you don’t want to follow). I don't understand how one can sign up for a mass email discussion forum, and be surprised that it increased the amount of email they receive. It's kind of the point of the medium.
Right you are, Alex.
I don’t think its unreasonable to point out that the title of this thread is "Moving to another forum". If you want to contribute Python Ideas you have to subscribe to the mailing list.
I have zero sympathy for this position. First, you only need to join the list to propose major changes - everything other type of contribution can be done off list. Fixing bugs never touches a list at all unless you need to discuss backwards incompatible changes, at which point it goes to the lower volume python-dev list. Documentation changes are done on the tracker, and trivial changes are done in pull requests. The firehose of python-ideas is a barrier to entry to suggesting major changes to the language. This is a GOOD thing. Major changes need dedicated advocates - if they are unwilling to endure the flood of mail, they are not dedicated enough to the change, and that is an indication of how much they will contribute to actually bring that fruition. They need a thick skin, since the idea will be folded, spindled and mutilated, usually reducing the change proposed to a single actionable item. This is what makes python a good language - the road to changing it is incredibly tough. We should not want to make it easier. The firehose is a virtue for this list.
Let me just say that I second the idea of moving to another forum.
I already move most mail automatically to the trash folder and read it there before eliminating it. My inbox contains exactly four emails at the moment, FYI.
Cheers, Hans
The firehose of python-ideas is a barrier to entry to suggesting major changes to the language. This is a GOOD thing. Major changes need dedicated advocates - if they are unwilling to endure the flood of mail, they are not dedicated enough to the change, and that is an indication of how much they will contribute to actually bring that fruition. They need a thick skin, since the idea will be folded, spindled and mutilated, usually reducing the change proposed to a single actionable item. This is what makes python a good language - the road to changing it is incredibly tough. We should not want to make it easier.
The firehose is a virtue for this list.
You’re conflating two things here: 1. Volume of mails (which is irrelevant for people who have a more advanced mail workflow anyway as has been pointed out as an argument against the very idea that is a firehouse at all) 2. People being... let’s be nice and say.. brutally honest and change averse. Point 2 has no connection to the technology afaik. And point 1 is weak at best. / Anders
On 9/20/2018 3:38 AM, Hans Polak wrote:
I don’t think its unreasonable to point out that the title of this thread is "Moving to another forum". If you want to contribute Python Ideas you *have to* subscribe to the mailing list.
Or you can point your mail/news reader to news.gmane.org and 'subscribe' to gmane.comp.python.ideas, which keeps everything in this list in a separate folder and only downloads messages one wants to read. -- Terry Jan Reedy
On 18/09/18 23:37, James Lu wrote:
Other than that, my biggest issues with the current mailing system are:
* There’s no way to keep a updated proposal of your own- if you decide to change your proposal, you have to communicate the change. Then, if you want to find the authoritative current copy, since you might’ve forgotten or you want to join he current discussion, then you have to dig through the emails and recursively apply the proposed change. It’s just easier if people can have one proposal they can edit themselves.
Believe it or not, I like the fact that you can't just edit posts. I've lost count of the number of forum threads I've been on where comments to the initial post make *no sense* because that initial post is nothing like it was to start with. (Also it makes it easier to quote people back at themselves :-)
* I’ve seen experienced people get confused about what was the current proposal because they were replying to older emails or they didn’t see the email with the clear examples.
As you said yourself, "you have to communicate the change." Even in a forum or similar. Just editing your post and expecting people to notice is not going to cut it. And yes, there is a danger that even experienced people will get confused about what is being proposed right now, but I've seen that happen on forums too. The lack of threading tends to help with that, but on the other hand it stifles breadth of debate.
* The mailing list is frankly obscure. Python community leaders and package maintainers often are not aware or do not participate in Python-ideas. Not many people know how to use or navigate a mailing list. * No one really promotes the mailing list, you have to go out of your way to find where new features are proposed. * Higher discoverability means more people can participate, providing their own use cases or voting (I mean using like or dislike measures, consensus should still be how things are approved) go out of their way to find so they can propose something. Instead, I envision a forum where people can read and give their 2 cents about what features they might like to see or might not want to see.
-1. (I'm British, I'm allowed to be ironic.) Approximately none of this has anything to do with the medium. If the mailing list is obscure (and personally I don't think it is), it just needs better advertising. A poorly advertised forum is equally undiscoverable.
* More people means instead of having to make decisions from sometimes subjective personal experience, we can make decisions with confidence in what other Python devs want.
Um. Have you read this list? Mostly we can make decisions with confidence that people disagree vigorously about what they as Python devs want. Besides, I've never met a mailing list, forum or any group of more than about twelve people that could make decisions in a timely manner (or at all in some cases), and I've been a member of a few that were supposed to. Eventually some*one* has to decide to do or allow something, traditionally the BDFL.
Since potential proposers will find it easier to navigate a GUI forum, they can read previous discussions to understand the reasoning, precedent behind rejected and successful features. People proposing things that have already been rejected before can be directed to open a subtopic on the older discussion.
Your faith in graphical interfaces is touching, but I've seen some stinkers. It is no easier to go through the average forum's thousands of prior discussions looking for the topic you are interested in than it is to go through the mailing list archive (and frankly googling is your best bet for both). People don't always do it here, but they don't always do it on any of the forums I'm on either, and resurrecting a moribund thread is no different to resurrecting a moribund topic. -- Rhodri James *-* Kynesim Ltd
participants (19)
-
Alex Walters -
Anders Hovmöller -
Antoine Pitrou -
Chris Angelico -
Chris Barker -
Ethan Furman -
Franklin? Lee -
Guido van Rossum -
Hans Polak -
James Lu -
Michael Selik -
Michel Desmoulin -
Mikhail V -
Nicholas Chammas -
Paul Moore -
Rhodri James -
Stephen J. Turnbull -
Terry Reedy -
Wes Turner