*More than ten years ago, a video game known as "Minecraft" was in its beta testing-phase.**End-users had many suggestions for Minecraft.* *The Mojang team (developers of Minecraft ) used a web platform for suggested changes to the videogame. **The website was known as "Get Satisfaction" **The GetSatisfaction page for Minecraft as so easy to use that sometimes children posted bug reports for Minecraft. Also, several less tenable thoughts fielded by people of the same mental maturity were quickly filtered out and shot down.* *More than ten years ago, there was a system for a major software project which did a good job of floating good ideas to the top and sinking bad ideas to the bottom.* *GetSatisfaction used a voting system, and the most popular suggestions were often implemented by Mojang's development team. When the Microsoft corporation bought Minecraft, the Minecraft GetSatisfaction page died, so it is difficult to look at now.* *Get Satisfaction allowed beta-testers to prioritize and sort well-written bug-reports, and I personally thought it worked better than git or other alternatives * *The python-ideas mailing list is a very cumbersome way to vet changes to the Python interpreter or other aspects of the python language. If the power-that-be would work with GetSatisfaction people to make a copy-cat of the GetSatisfaction page for Minecraft, I think that the python community could then better drive PEPs (Python Enhancement Proposals)* *Samuel Muldoon* *muldoonsamuel@gmail.com <muldoonsamuel@gmail.com>*
On Sat, 19 Feb 2022 at 05:56, Samuel Muldoon <muldoonsamuel@gmail.com> wrote:
The python-ideas mailing list is a very cumbersome way to vet changes to the Python interpreter or other aspects of the python language. If the power-that-be would work with GetSatisfaction people to make a copy-cat of the GetSatisfaction page for Minecraft, I think that the python community could then better drive PEPs (Python Enhancement Proposals)
Popularity is a *terrible* way to judge ideas. I'm currently fighting with another platform on that same topic. All you can see from a system like that is how many of the popular ideas get implemented. It says nothing about how many good ideas end up languishing with a small number of votes, simply because they never reach critical mass and not enough people see them. Does GetSatisfaction allow downvotes? If yes: how do you stop a vocal few from shooting down any idea they don't like? If no: how do you guard against those who have louder voices being the only ones heard (in the case of Minecraft, if a major Youtuber were to link to a report, it would undoubtedly get a lot more votes than one from someone without such a platform)? There is no way to make a popular vote fair. ChrisA
On Sat, Feb 19, 2022 at 06:04:28AM +1100, Chris Angelico wrote:
Popularity is a *terrible* way to judge ideas. I'm currently fighting with another platform on that same topic.
Can we ask which platform?
All you can see from a system like that is how many of the popular ideas get implemented. It says nothing about how many good ideas end up languishing with a small number of votes, simply because they never reach critical mass and not enough people see them.
Rather like the way we tell people to publish on PyPI and see if it becomes popular.
Does GetSatisfaction allow downvotes? If yes: how do you stop a vocal few from shooting down any idea they don't like?
Nothing like Python-Ideas then :-) Typically voting systems only allow logged-in users to vote, and you can only vote once. You can change your vote at any time, but a vocal few is limited to only downvoting once each, they can't vote a thousand times each and overwhelm the popular voice. Same applies to up-voting.
There is no way to make a popular vote fair.
That's an odd take. A better take is that, fair or not, popularity is not necessarily a good judge of what works well in a language. Language design requires skill and taste, and it is not obvious that the wisdom of the crowd extends that far. -- Steve
On Sun, 20 Feb 2022 at 18:05, Steven D'Aprano <steve@pearwood.info> wrote:
On Sat, Feb 19, 2022 at 06:04:28AM +1100, Chris Angelico wrote:
Popularity is a *terrible* way to judge ideas. I'm currently fighting with another platform on that same topic.
Can we ask which platform?
Not on-list, out of courtesy. It's unrelated.
All you can see from a system like that is how many of the popular ideas get implemented. It says nothing about how many good ideas end up languishing with a small number of votes, simply because they never reach critical mass and not enough people see them.
Rather like the way we tell people to publish on PyPI and see if it becomes popular.
Yes and no. Python doesn't use PyPI download counts to decide what gets added to the standard library, for instance. A package is not judged solely on the basis of some form of upvote. We tell people to publish and see, but even if it isn't popular, it's still on PyPI and has whatever value it has.
Does GetSatisfaction allow downvotes? If yes: how do you stop a vocal few from shooting down any idea they don't like?
Nothing like Python-Ideas then :-)
Typically voting systems only allow logged-in users to vote, and you can only vote once. You can change your vote at any time, but a vocal few is limited to only downvoting once each, they can't vote a thousand times each and overwhelm the popular voice.
Same applies to up-voting.
Question: Do votes from newly-created accounts have as much weight as those from well-established accounts? I can assure you, from experience, that there is no correct answer to this question, and that the vocal few can always shoot down ideas they don't like, if downvoting is a possibility.
There is no way to make a popular vote fair.
That's an odd take.
"Fair" is such an ill-defined concept that the statement is almost vacuously true. But here's one simple example: Politics in the United Kingdom can be seen to be somewhat England-dominated, due to the population density. This can lead to Scotland being underrepresented. Or does it? Maybe Scotland is represented precisely as much as it deserves to be. Or maybe not. What is fair? (It's quite amusing playing a grand strategy game and having Scotland conquer all of England by forming military alliances with Austria as well as France. Yeah, who's underrepresented now, huh?)
A better take is that, fair or not, popularity is not necessarily a good judge of what works well in a language. Language design requires skill and taste, and it is not obvious that the wisdom of the crowd extends that far.
Yes, this is also true. And on the rare occasions when a poll is conducted, it is purely for information, and is never binding. Citation: PEP 308. https://www.python.org/dev/peps/pep-0308/#detailed-results-of-voting The C-like question/colon syntax and a parenthesized form of if statement were both significantly more popular than the syntax that ended up implemented. If the matter had been "put to a vote", we'd have had a quite different result. And honestly, I'm glad of it. ChrisA
Hey Christ, We can always think in terms of weighted vote, the more your account is "well-established" (either by being ancient or by contributing) the more it's vote has weight. Anyway, just a suggestion. Regards, -- SENHAJI RHAZI Hamza Le dim. 20 févr. 2022 à 09:43, Chris Angelico <rosuav@gmail.com> a écrit :
On Sun, 20 Feb 2022 at 18:05, Steven D'Aprano <steve@pearwood.info> wrote:
On Sat, Feb 19, 2022 at 06:04:28AM +1100, Chris Angelico wrote:
Popularity is a *terrible* way to judge ideas. I'm currently fighting with another platform on that same topic.
Can we ask which platform?
Not on-list, out of courtesy. It's unrelated.
All you can see from a system like that is how many of the popular ideas get implemented. It says nothing about how many good ideas end up languishing with a small number of votes, simply because they never reach critical mass and not enough people see them.
Rather like the way we tell people to publish on PyPI and see if it becomes popular.
Yes and no. Python doesn't use PyPI download counts to decide what gets added to the standard library, for instance. A package is not judged solely on the basis of some form of upvote. We tell people to publish and see, but even if it isn't popular, it's still on PyPI and has whatever value it has.
Does GetSatisfaction allow downvotes? If yes: how do you stop a vocal few from shooting down any idea they don't like?
Nothing like Python-Ideas then :-)
Typically voting systems only allow logged-in users to vote, and you can only vote once. You can change your vote at any time, but a vocal few is limited to only downvoting once each, they can't vote a thousand times each and overwhelm the popular voice.
Same applies to up-voting.
Question: Do votes from newly-created accounts have as much weight as those from well-established accounts? I can assure you, from experience, that there is no correct answer to this question, and that the vocal few can always shoot down ideas they don't like, if downvoting is a possibility.
There is no way to make a popular vote fair.
That's an odd take.
"Fair" is such an ill-defined concept that the statement is almost vacuously true. But here's one simple example: Politics in the United Kingdom can be seen to be somewhat England-dominated, due to the population density. This can lead to Scotland being underrepresented. Or does it? Maybe Scotland is represented precisely as much as it deserves to be. Or maybe not. What is fair?
(It's quite amusing playing a grand strategy game and having Scotland conquer all of England by forming military alliances with Austria as well as France. Yeah, who's underrepresented now, huh?)
A better take is that, fair or not, popularity is not necessarily a good judge of what works well in a language. Language design requires skill and taste, and it is not obvious that the wisdom of the crowd extends that far.
Yes, this is also true. And on the rare occasions when a poll is conducted, it is purely for information, and is never binding. Citation: PEP 308.
https://www.python.org/dev/peps/pep-0308/#detailed-results-of-voting
The C-like question/colon syntax and a parenthesized form of if statement were both significantly more popular than the syntax that ended up implemented. If the matter had been "put to a vote", we'd have had a quite different result. And honestly, I'm glad of it.
ChrisA _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/LCJJ7M... Code of Conduct: http://python.org/psf/codeofconduct/
On Sun, 20 Feb 2022 at 08:05, Steven D'Aprano <steve@pearwood.info> wrote:
There is no way to make a popular vote fair.
That's an odd take.
A better take is that, fair or not, popularity is not necessarily a good judge of what works well in a language. Language design requires skill and taste, and it is not obvious that the wisdom of the crowd extends that far.
A problem with most online votes is that participation is self-selected. There is no way to measure turnout, and therefore, it is impossible to tell how representative the voters are for the community at large. If voting is limited to a select group (which could be as small as Python core developers, or as large as anyone who has ever had a pull request merged into cpython, or something in-between), then a vote could be a way to measure opinions after a lengthy discussion fails to reach a consensus. Gerrit.
On Sun, Feb 20, 2022 at 04:38:37PM +0100, Gerrit Holl wrote:
A problem with most online votes is that participation is self-selected. There is no way to measure turnout, and therefore, it is impossible to tell how representative the voters are for the community at large.
I'm sure that Minecraft knows precisely how many subscribers they have. If they have a million subscribers and 999,999 votes for a feature and 1 against, I think they could probably guess that the Yes votes were representative of the community at large. Democracies deal with this all the time. Some, like Australia, have compulsory voting, and something like 95% turnout. Other democracies struggle to reach 50% turnout, with figures closer to 30% being more typical. Some democracies discourage voting, or have unequal votes. In a situation like Minecraft, where the software runs on their servers, they could (hypothetically) even weight the votes according to how many hours of game play the account has done. Or look at whether certain features were more popular among hard core gamers or casual gamers, whether votes were associated with how much money they spend, etc. Python cannot do anything like that, not even in principle. Unlike Minecraft, who can tell you precisely how many accounts there are (and make a reasonable estimate of how many unique human users are associated with each account), we can't even guess how many Python developers there are with any degree of certainty. What even counts as a Python developer? Some disinterested teen forced to learn it at school? Professional programmers? Sys admins who edit the occassional .py script? Web developers who use Python frameworks?
If voting is limited to a select group (which could be as small as Python core developers, or as large as anyone who has ever had a pull request merged into cpython, or something in-between), then a vote could be a way to measure opinions after a lengthy discussion fails to reach a consensus.
Sure. But another argument is that if a lengthy discussion fails to reach a consensus, the status quo should win. https://www.curiousefficiency.org/posts/2011/02/status-quo-wins-stalemate.ht... -- Steve
Gerrit Holl writes:
If voting is limited to a select group (which could be as small as Python core developers, or as large as anyone who has ever had a pull request merged into cpython, or something in-between), then a vote could be a way to measure opinions after a lengthy discussion fails to reach a consensus.
I'm not sure what the benefit of "measuring opinions" is supposed to be, when those opinions don't bring real resources with them, and few of them are informed beyond "sounds cool" and "YAGNI". If a discussion fails to reach consensus, human brains do OK at holding a fairly detailed summary of it, including who held what opinion when discussion ended -- far more informative than the result of a vote. What a vote can do for you is make an up or down decision, or choose among alternatives. But from the project's point of view, these decisions are rarely pressing (except maybe security fixes, and those are not going to be discussed publicly, let alone put to a general vote!) If an issue is still controversial after a long discussion, it's usually because there are competing interests in play, and somebody has to lose something they want. In those cases, it's almost always best to table it, and see if any technical progress is made on reconciling differences about the issue over the next release cycle. Sure, tabling issues frustrates non-committer proponents (who are also usually the proponents of voting schemes, what a coincidence!), but that's normally better than frustrating committers who are against it.
On 2022-02-20 17:56, Stephen J. Turnbull wrote:
Gerrit Holl writes:
If voting is limited to a select group (which could be as small as Python core developers, or as large as anyone who has ever had a pull request merged into cpython, or something in-between), then a vote could be a way to measure opinions after a lengthy discussion fails to reach a consensus.
I'm not sure what the benefit of "measuring opinions" is supposed to be, when those opinions don't bring real resources with them, and few of them are informed beyond "sounds cool" and "YAGNI". If a discussion fails to reach consensus, human brains do OK at holding a fairly detailed summary of it, including who held what opinion when discussion ended -- far more informative than the result of a vote.
What a vote can do for you is make an up or down decision, or choose among alternatives. But from the project's point of view, these decisions are rarely pressing (except maybe security fixes, and those are not going to be discussed publicly, let alone put to a general vote!) If an issue is still controversial after a long discussion, it's usually because there are competing interests in play, and somebody has to lose something they want. In those cases, it's almost always best to table it, and see if any technical progress is made on reconciling differences about the issue over the next release cycle.
Sure, tabling issues frustrates non-committer proponents (who are also usually the proponents of voting schemes, what a coincidence!), but that's normally better than frustrating committers who are against it.
FYI, the verb "to table" has different meanings in US and UK English. In US English it means to remove from discussion, whereas in UK English it means to propose for discussion, which is the opposite. On a list that has an international reach, it's probably best to avoid the verb altogether.
"To table" is a contranym in both the US and the UK. On Tue, Feb 22, 2022 at 9:53 AM MRAB <python@mrabarnett.plus.com> wrote:
On 2022-02-20 17:56, Stephen J. Turnbull wrote:
Gerrit Holl writes:
If voting is limited to a select group (which could be as small as Python core developers, or as large as anyone who has ever had a pull request merged into cpython, or something in-between), then a vote could be a way to measure opinions after a lengthy discussion fails to reach a consensus.
I'm not sure what the benefit of "measuring opinions" is supposed to be, when those opinions don't bring real resources with them, and few of them are informed beyond "sounds cool" and "YAGNI". If a discussion fails to reach consensus, human brains do OK at holding a fairly detailed summary of it, including who held what opinion when discussion ended -- far more informative than the result of a vote.
What a vote can do for you is make an up or down decision, or choose among alternatives. But from the project's point of view, these decisions are rarely pressing (except maybe security fixes, and those are not going to be discussed publicly, let alone put to a general vote!) If an issue is still controversial after a long discussion, it's usually because there are competing interests in play, and somebody has to lose something they want. In those cases, it's almost always best to table it, and see if any technical progress is made on reconciling differences about the issue over the next release cycle.
Sure, tabling issues frustrates non-committer proponents (who are also usually the proponents of voting schemes, what a coincidence!), but that's normally better than frustrating committers who are against it.
FYI, the verb "to table" has different meanings in US and UK English. In US English it means to remove from discussion, whereas in UK English it means to propose for discussion, which is the opposite. On a list that has an international reach, it's probably best to avoid the verb altogether. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/4XBBEQ... Code of Conduct: http://python.org/psf/codeofconduct/
-- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th.
Democracy has its pros and cons. ...RM On Fri, Feb 18, 2022 at 10:57 AM Samuel Muldoon <muldoonsamuel@gmail.com> wrote:
*The python-ideas mailing list is a very cumbersome way to vet changes to the Python interpreter or other aspects of the python language. If the power-that-be would work with GetSatisfaction people to make a copy-cat of the GetSatisfaction page for Minecraft, I think that the python community could then better drive PEPs (Python Enhancement Proposals)*
-- Richard Mateosian <xrm@pacbell.net> Berkeley, California
participants (9)
-
Chris Angelico -
David Mertz, Ph.D. -
Gerrit Holl -
MRAB -
Richard Mateosian -
Samuel Muldoon -
Senhaji Rhazi hamza -
Stephen J. Turnbull -
Steven D'Aprano