PEP feedback loop (with tracker account)
It is not that hard to implement an approval function for the PEP site (to improve the visibility and the process). For example, on the page http://legacy.python.org/dev/peps/pep-0231/ the field "Status: Rejected" can be linkified to bring up a popup window with short info about quantity of people who approved the PEP (content details can be extended later). It is not that hard to add a disqus-style JS form to set status of your position towards PEP using tracker account. Will that be useful for Python community? -- anatoly t.
On Tue, Mar 25, 2014 at 5:29 PM, anatoly techtonik
For example, on the page http://legacy.python.org/dev/peps/pep-0231/ the field "Status: Rejected" can be linkified to bring up a popup window with short info about quantity of people who approved the PEP (content details can be extended later).
By "approved" do you mean those who wish it hadn't been rejected? I don't think that's terribly useful, and it implies a democratic approach to Python's development, which doesn't exist. More useful might be for the "Status: Rejected" to link to a python-dev post formally rejecting it, but that's about all. Can you elaborate on both what this would show, and how it would be useful? ChrisA
On Tue, Mar 25, 2014 at 12:07 PM, Chris Angelico
On Tue, Mar 25, 2014 at 5:29 PM, anatoly techtonik
wrote: For example, on the page http://legacy.python.org/dev/peps/pep-0231/ the field "Status: Rejected" can be linkified to bring up a popup window with short info about quantity of people who approved the PEP (content details can be extended later).
By "approved" do you mean those who wish it hadn't been rejected? I don't think that's terribly useful, and it implies a democratic approach to Python's development, which doesn't exist. More useful might be for the "Status: Rejected" to link to a python-dev post formally rejecting it, but that's about all. Can you elaborate on both what this would show, and how it would be useful?
By "approved" I mean that people sign the specific PEP version as "fully read and agree with all the clauses". For example, I don't have time to read PEPs thoroughly and I wonder how many people have. There might be a problem that PEPs don't receive enough exposure and timely feedback. I don't know - it is uncertain. Also having some kind of recorded "achievement" will help to get some motivation to do thorough reviews. Also many people don't imagine how many heads are working on a single PEP and think that there are a lot of people already. It may be that knowing the stats they will be more interested to contribute. The fourth reason is that this basic feedback system can be extended to include specific facts to be addressed, but that out of scope for now. -- anatoly t.
anatoly techtonik writes:
It is not that hard to implement an approval function for the PEP site (to improve the visibility and the process).
I gather you mean "thumbs up/down" buttons.
Will that be useful for Python community?
No. As Chris points out, the PEP process is not a voting process. (I think that's what he meant. I would say that it is "democratic" in the sense that as much as possible we try to come to consensus on a "best" proposal.) And people do switch as PEPs evolve, but I doubt they'd be likely to change their "vote" on the PEP site. Links to the discussion (or perhaps even blog posts of folks who strongly dissent) are far more relevant.
On Wed, Mar 26, 2014 at 6:16 AM, Stephen J. Turnbull
No. As Chris points out, the PEP process is not a voting process. (I think that's what he meant. I would say that it is "democratic" in the sense that as much as possible we try to come to consensus on a "best" proposal.) And people do switch as PEPs evolve, but I doubt they'd be likely to change their "vote" on the PEP site.
Yes, that's what I meant. Python is built, as most open source projects are, on a model of "a king with his ministers and citizens". The king, of course, is normally Guido [1]; core devs are Guido's ministers and close advisers; everyone else who uses Python is a citizen. (Drawing the line between ministers and citizens is a tad harder than in a parliamentary structure, so I'm going to horrendously cheat and say that ministers can be appointed and/or can step down very easily and quickly.) A PEP is basically a petition, raised and discussed. It has a champion (at least by the time it becomes a PEP), and the Champion will seek to demonstrate how the proposal will be of great benefit. This doesn't strictly equate to "number of signatures", which is how these sorts of petitions are often treated in modern politics; it's more about strength of argument. So not only is this system not democratic in the obvious sense of "majority rules" (if you get more + votes than -, the PEP is approved), it's also almost never even about gathering numerical support (which is what this *would* be able to show). There have been a few times when popular support is canvassed (PEP 308, for instance), but even then, it's certainly not "most popular option wins" (it wasn't then, although the chosen syntax was clearly in the popular group rather than the less-popular group). Recording who has fully read the PEP and agrees with every little part of it would be nearly impossible as the PEP evolves, so by the latest definition, it's impossible to calculate, as well as being almost-never-useful. Searching the python-ideas archive for the PEP number and reading through the discussion is probably the only way to find out after the event, so I sympathize with the desire to simply eyeball a figure and see; but I can't imagine it being truly useful in all that many cases. ChrisA [1] Some subprojects (like IDLE?) function identically with a different king.
From PEP 1: What is a PEP? PEP stands for Python Enhancement Proposal. A PEP is a design document providing information to the Python community, or describing a new feature for Python or its processes or environment. The PEP should provide a concise technical specification of the feature and a rationale for the feature. We intend PEPs to be the primary mechanisms for proposing major new features, for collecting community input on an issue, and for documenting the design decisions that have gone into Python. The PEP author is responsible for building consensus within the community and documenting dissenting opinions. Because the PEPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal [1]. -Barry
On Tue, Mar 25, 2014 at 10:16 PM, Stephen J. Turnbull
anatoly techtonik writes:
It is not that hard to implement an approval function for the PEP site (to improve the visibility and the process).
I gather you mean "thumbs up/down" buttons.
It is not primitive "thumbs up/down" button and not voting. The feedback loop goal to get information about community awareness - not for making decision to accept or reject a proposal. Therefore it is not democracy. The approval is not a simple boolean - it is the status object, which contains fields to make feedback loop actually useful, and may provide information, such as: 1. LGTM 2. Have questions 3. Have comments 4. Will watch later 5. tl;dr 6. meh 7. .... <link> to discussion 8. ... The status sums up opinion for a given person at a given moment. Benefits: - see who is interested - see who was able to review - see who was able to read it - see which version has questions I don't want to get into much featurecreeping, which is incrementally possible. Will that idea be useful for Python community?
Links to the discussion (or perhaps even blog posts of folks who strongly dissent) are far more relevant.
This can be added, so that folks can tie their posts to PEP feedback loop. 9. Dissent <link> (new word for me, sounds strange) -- anatoly t.
Am 25.03.2014 07:29, schrieb anatoly techtonik:
It is not that hard to implement an approval function for the PEP site (to improve the visibility and the process).
For example, on the page http://legacy.python.org/dev/peps/pep-0231/ the field "Status: Rejected" can be linkified to bring up a popup window with short info about quantity of people who approved the PEP (content details can be extended later).
It is not that hard to add a disqus-style JS form to set status of your position towards PEP using tracker account.
Will that be useful for Python community?
No. What is useful is to keep the "Post-History" header up to date, which refers people to the python-dev threads where all the discussion and "voting" takes place. I could also imagine adding direct links to the archive; however many PEPs already add references in the text where appropriate. Georg
On 03/25/2014 03:46 PM, Georg Brandl wrote:
No. What is useful is to keep the "Post-History" header up to date, which refers people to the python-dev threads where all the discussion and "voting" takes place.
So should that header just include the dates when new threads were spawned, or if significant time had passed since the last posting in the "current" thread? -- ~Ethan~
Am 26.03.2014 03:21, schrieb Ethan Furman:
On 03/25/2014 03:46 PM, Georg Brandl wrote:
No. What is useful is to keep the "Post-History" header up to date, which refers people to the python-dev threads where all the discussion and "voting" takes place.
So should that header just include the dates when new threads were spawned, or if significant time had passed since the last posting in the "current" thread?
PEP 1 says: """ The Created header records the date that the PEP was assigned a number, while Post-History is used to record the dates of when new versions of the PEP are posted to python-list and/or python-dev. Both headers should be in dd-mmm-yyyy format, e.g. 14-Aug-2001. """ And new threads are usually accompanied by a posting of a revision of the PEP. Georg
On Mar 25, 2014, at 15:46, Georg Brandl
Am 25.03.2014 07:29, schrieb anatoly techtonik:
It is not that hard to implement an approval function for the PEP site (to improve the visibility and the process).
For example, on the page http://legacy.python.org/dev/peps/pep-0231/ the field "Status: Rejected" can be linkified to bring up a popup window with short info about quantity of people who approved the PEP (content details can be extended later).
It is not that hard to add a disqus-style JS form to set status of your position towards PEP using tracker account.
Will that be useful for Python community?
No. What is useful is to keep the "Post-History" header up to date, which refers people to the python-dev threads where all the discussion and "voting" takes place.
I could also imagine adding direct links to the archive; however many PEPs already add references in the text where appropriate.
Having someone dedicate themselves to linking in all significant -ideas and -dev discussions (and relevant blog posts, etc.) would be incredibly useful. I can't think of anything else that would really be interesting at all. A +/- vote is meaningless, and expecting people to summarize their mailing-list discussions in a single post on the PEP site doesn't seem likely to capture sufficient interest on any but the most contentious PEPs.
On Wed, Mar 26, 2014 at 8:22 AM, Andrew Barnert
On Mar 25, 2014, at 15:46, Georg Brandl
wrote: No. What is useful is to keep the "Post-History" header up to date, which refers people to the python-dev threads where all the discussion and "voting" takes place.
I could also imagine adding direct links to the archive; however many PEPs already add references in the text where appropriate.
Having someone dedicate themselves to linking in all significant -ideas and -dev discussions (and relevant blog posts, etc.) would be incredibly useful.
The goal to link threads and PEP versions is reachable at the next iteration once status per person is implemented. The benefit from the system is that you don't need to dedicate a person to do this.
A +/- vote is meaningless, and expecting people to summarize their mailing-list discussions in a single post on the PEP site doesn't seem likely to capture sufficient interest on any but the most contentious PEPs.
It is not a post. It is status per revision. The difference between post and status is that status gives immediate overview (diffstat) while post needs English skills + time to bring an up-to-date image in you head. So, status is declarative and can be processed by machines. Post is procedural and requires manual human labor. Status can serve as intermediate entrypoint to join current problem field (as opposed to rereading posts from the start). -- anatoly t.
On Mar 26, 2014, at 1:07, anatoly techtonik
On Wed, Mar 26, 2014 at 8:22 AM, Andrew Barnert
wrote: On Mar 25, 2014, at 15:46, Georg Brandl
wrote: No. What is useful is to keep the "Post-History" header up to date, which refers people to the python-dev threads where all the discussion and "voting" takes place.
I could also imagine adding direct links to the archive; however many PEPs already add references in the text where appropriate.
Having someone dedicate themselves to linking in all significant -ideas and -dev discussions (and relevant blog posts, etc.) would be incredibly useful.
The goal to link threads and PEP versions is reachable at the next iteration once status per person is implemented. The benefit from the system is that you don't need to dedicate a person to do this.
A +/- vote is meaningless, and expecting people to summarize their mailing-list discussions in a single post on the PEP site doesn't seem likely to capture sufficient interest on any but the most contentious PEPs.
It is not a post. It is status per revision. The difference between post and status is that status gives immediate overview (diffstat) while post needs English skills + time to bring an up-to-date image in you head. So, status is declarative and can be processed by machines. Post is procedural and requires manual human labor.
The other difference is that nobody cares about a count of +/- status, so it doesn't really matter how easy it is to collect. If someone is trying to decide whether or not the PEP discussion is missing his point of view, a vote isn't going to tell him that. If Guido is trying to decide whether to approve or reject the PEP, he's not going to go by the vote. So what's the point of it?
participants (7)
-
anatoly techtonik
-
Andrew Barnert
-
Barry Warsaw
-
Chris Angelico
-
Ethan Furman
-
Georg Brandl
-
Stephen J. Turnbull