Reading the defect, I find people being unnecessarily obstructive. Closing the ticket, twice, is a rude, and unnecessary action. How about acknowledging that these waters are dark and murky and help making things better? Surely, documenting processes can only be an improvement? A lot has changed in open source development in the last 10 years. The processes we have are starting to have the air of cathedral around them. K From: Python-Dev [mailto:python-dev-bounces+kristjan=ccpgames.com@python.org] On Behalf Of Guido van Rossum Sent: 28. nóvember 2013 18:40 To: anatoly techtonik Cc: python-dev Subject: Re: [Python-Dev] PEP process entry point and ill fated initiatives Anatoly, the Python community is a lot more diverse than you think. "Pull requests" (whatever that means) are not the way to start a PEP. You should start by focusing on the contents, and the mechanics of editing it and getting it formatted properly are secondary. The process is explained in PEP one. Your bug report would have gotten a much better response if you had simply asked "what is the process, I can't figure it out from the repo's README" rather that (again) complaining that the core developers don't care. Offending people is not the way to get them to help you.

-----Original Message----- From: Python-Dev [mailto:python-dev- bounces+kristjan=ccpgames.com@python.org] On Behalf Of Antoine Pitrou Sent: 29. nóvember 2013 14:58 To: python-dev@python.org Subject: Re: [Python-Dev] PEP process entry point and ill fated initiatives

On Fri, 29 Nov 2013 09:16:38 +0000 Kristján Valur Jónsson <kristjan@ccpgames.com> wrote:

...

Closing the ticket, twice, is a rude, and unnecessary action.

Closing the ticket means "we don't believe there is an issue, or we don't think it would be reasonable to fix it". If that's our judgement on the issue, how is it rude to close it? Also, this attitude. Who are the "we" in this case? And why send messages to people by shutting doors?

...

How about acknowledging that these waters are dark and murky and help making things better?

Well, how about? If Anatoly has a concrete proposal, surely he can propose a patch to make things better. Which is what he did. And instead of helpful ideas on how to improve his patch,

the issue is closed. The acolytes have spoken. I know that Anatoly himself is a subject of long history here, but I myself have felt lessening affinity to the dev community in recent years. It feels like it is increasingly shutting itself in. Cheers, K

On 29/11/2013 15:25, Kristján Valur Jónsson wrote:

I know that Anatoly himself is a subject of long history here, but I myself have felt lessening affinity to the dev community in recent years. It feels like it is increasingly shutting itself in.

I entirely agree, the development community is getting to the stage where it stinks. Consider Issue 19755. It was a low priority admittedly, but it took them 17 minutes and 47 seconds to action it, what is the world coming to? :) -- Python is the second best programming language in the world. But the best has yet to be invented. Christian Tismer Mark Lawrence

On 29.11.2013 16:25, Kristján Valur Jónsson wrote:

...

...

How about acknowledging that these waters are dark and murky and help making things better?

Well, how about? If Anatoly has a concrete proposal, surely he can propose a patch to make things better.

Which is what he did. And instead of helpful ideas on how to improve his patch, the issue is closed. The acolytes have spoken.

I'm not sure we're talking about the same issue item. Anatoly did not present a patch which could have been improved: http://bugs.python.org/issue19822 Anatoly refuses to sign the Python CLA, so it's not surprising that he didn't provide a patch. His only contribution was a step-by-step process he put in the ticket description which doesn't represent the PEP process. Christian pointed him to the correct process, but he unfortunately just ignored this. I'm afraid there's nothing much we can do to make ends meet. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 29 2013)

...

...

Python Projects, Consulting and Support ... http://www.egenix.com/ mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/

::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/

On 30 November 2013 01:25, Kristján Valur Jónsson <kristjan@ccpgames.com> wrote:

I know that Anatoly himself is a subject of long history here, but I myself have felt lessening affinity to the dev community in recent years. It feels like it is increasingly shutting itself in.

Are you sure it isn't just that the focus of development has shifted to matters that aren't of interest or relevance to you? Many (perhaps even most) problems in Python don't require changes at the language or standard library level. We have cycle times measured in months, and impact times measured in years (especially since core development switched to Python 3 only mode for feature development). That's not typically something that is useful in day-to-day development tasks - it's only ever relevant in strategic terms. One thing that has changed for me personally, is that I've become far more blunt about refusing to respect those that explicitly (and vocally) refuse to respect us, yet seem to want to participate in core development anyway, and that's directly caused by Anatoly. He's still the only person who has been proposed for a permanent ban from all python.org controlled communication channels. That was averted after he voluntarily stopped annoying people for a while, but now he's back and I think the matter needs to be reconsidered. He refuses to sign the CLA that would allow him to contribute directly, yet still wants people to fix things for him. He refuses to read design documentation, yet still wants people to listen to his ideas. He refuses to care about other people's use cases, yet still wants people to care about his. As a case in point, Anatoly recently suggested that more diagrams in the documentation would be a good thing (http://bugs.python.org/issue19608). That's not an objectively bad idea, but producing and maintaining good diagrams is a high overhead activity, so we generally don't bother. When I suggested drawing some and sending a patch (I had forgotten about the CLA problem), Anatoly's response was that he's not a designer. So I countered with a suggestion that he explore what would be involved in adding the seqdiag and blockdiag sphinx extensions to our docs build process, since having those available would drastically lower the barrier to including and maintaining reasonable diagrams in the documentation, increasing the chance of such diagrams being included in the future. Silence. "Hey some diagrams would be helpful!" is not a useful contribution, it's stating the bleeding obvious. Even nominating some *specific* parts of the guide where a diagram would have helped Anatoly personally would have been useful. The technical change I suggested about figuring out what we'd need to change to enable those extensions would *definitely* have been useful. Another couple of incidents recently occurred on distutils-sig, where Anatoly started second guessing the decision to work on PyPI 2 as a test-driven-development-from-day-one incrementally developed and released system, rather than trying to update the existing fragile PyPI code base directly, as well as complaining about the not-accessible-to-end-users design docs for the proposed end-to-end security model for PyPI. It would be one thing if he was voicing those concerns on his own blog (it's a free internet, he can do what he likes anywhere else). It's a problem when he's doing it on distutils-sig and the project issue trackers. This isn't a matter of a naive newcomer that doesn't know any better. This is someone who has had PSF board members sit down with them at PyCon US to explain the CLA and why it is the way it is, who has had core developers offer them direct advice on how to propose suggestions in a way that is more likely to get people to listen, and when major issues have occurred in the past, we've even gone hunting for people to talk to him in his native language to make sure it wasn't a language barrier that was the root cause of the problem. *None* of it has resulted in any signficant improvement in his behaviour. Contributor time and emotional energy are the most precious resources an open source project has, and Anatoly is recklessly wasteful of both. We've spent years trying to coach him on being an effective collaborator and contributor, and it hasn't worked. This isn't a democracy, and neither is it a place for arbitrary people to get therapy on their inability to have any empathy for another person's point of view - in the end, passion for the language isn't enough, people have to demonstrate an ability to learn and be respectful of other people's time and energy, and Anatoly has well and truly proven he doesn't have either of those. Anatoly has the entire rest of the internet to play in, we shouldn't have to put up with his disruptions when we're actually trying to get stuff done. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

Thanks for this long explanation, Nick. For someone that is not a compulsive reader of python-dev it certainly helps by putting things in perspective. I think the problem you describe is a singular one that needs to be dealt with using singular methods. My own personal complaints, have other causes, I hope, and I see now that bringing the two up as being somehow related is both incorrect and unwise. I'm sorry for stirring things up, I'll try to show more restraint in the future :) Cheers, Kristján -----Original Message----- From: Nick Coghlan [mailto:ncoghlan@gmail.com] Sent: 30. nóvember 2013 03:39 To: Kristján Valur Jónsson Cc: Antoine Pitrou; python-dev@python.org Subject: Re: [Python-Dev] PEP process entry point and ill fated initiatives On 30 November 2013 01:25, Kristján Valur Jónsson <kristjan@ccpgames.com> wrote:

I know that Anatoly himself is a subject of long history here, but I myself have felt lessening affinity to the dev community in recent years. It feels like it is increasingly shutting itself in.

Are you sure it isn't just that the focus of development has shifted to matters that aren't of interest or relevance to you? Many (perhaps even most) problems in Python don't require changes at the language or standard library level. We have cycle times measured in months, and impact times measured in years (especially since core development switched to Python 3 only mode for feature development). That's not typically something that is useful in day-to-day development tasks - it's only ever relevant in strategic terms. One thing that has changed for me personally, is that I've become far more blunt about refusing to respect those that explicitly (and vocally) refuse to respect us, yet seem to want to participate in core development anyway, and that's directly caused by Anatoly. He's still the only person who has been proposed for a permanent ban from all python.org controlled communication channels. That was averted after he voluntarily stopped annoying people for a while, but now he's back and I think the matter needs to be reconsidered. He refuses to sign the CLA that would allow him to contribute directly, yet still wants people to fix things for him. He refuses to read design documentation, yet still wants people to listen to his ideas. He refuses to care about other people's use cases, yet still wants people to care about his. As a case in point, Anatoly recently suggested that more diagrams in the documentation would be a good thing (http://bugs.python.org/issue19608). That's not an objectively bad idea, but producing and maintaining good diagrams is a high overhead activity, so we generally don't bother. When I suggested drawing some and sending a patch (I had forgotten about the CLA problem), Anatoly's response was that he's not a designer. So I countered with a suggestion that he explore what would be involved in adding the seqdiag and blockdiag sphinx extensions to our docs build process, since having those available would drastically lower the barrier to including and maintaining reasonable diagrams in the documentation, increasing the chance of such diagrams being included in the future. Silence. "Hey some diagrams would be helpful!" is not a useful contribution, it's stating the bleeding obvious. Even nominating some *specific* parts of the guide where a diagram would have helped Anatoly personally would have been useful. The technical change I suggested about figuring out what we'd need to change to enable those extensions would *definitely* have been useful. Another couple of incidents recently occurred on distutils-sig, where Anatoly started second guessing the decision to work on PyPI 2 as a test-driven-development-from-day-one incrementally developed and released system, rather than trying to update the existing fragile PyPI code base directly, as well as complaining about the not-accessible-to-end-users design docs for the proposed end-to-end security model for PyPI. It would be one thing if he was voicing those concerns on his own blog (it's a free internet, he can do what he likes anywhere else). It's a problem when he's doing it on distutils-sig and the project issue trackers. This isn't a matter of a naive newcomer that doesn't know any better. This is someone who has had PSF board members sit down with them at PyCon US to explain the CLA and why it is the way it is, who has had core developers offer them direct advice on how to propose suggestions in a way that is more likely to get people to listen, and when major issues have occurred in the past, we've even gone hunting for people to talk to him in his native language to make sure it wasn't a language barrier that was the root cause of the problem. *None* of it has resulted in any signficant improvement in his behaviour. Contributor time and emotional energy are the most precious resources an open source project has, and Anatoly is recklessly wasteful of both. We've spent years trying to coach him on being an effective collaborator and contributor, and it hasn't worked. This isn't a democracy, and neither is it a place for arbitrary people to get therapy on their inability to have any empathy for another person's point of view - in the end, passion for the language isn't enough, people have to demonstrate an ability to learn and be respectful of other people's time and energy, and Anatoly has well and truly proven he doesn't have either of those. Anatoly has the entire rest of the internet to play in, we shouldn't have to put up with his disruptions when we're actually trying to get stuff done. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On Thu, Nov 28, 2013 at 9:39 PM, Guido van Rossum <guido@python.org> wrote:

Anatoly, the Python community is a lot more diverse than you think. "Pull requests" (whatever that means) are not the way to start a PEP. You should start by focusing on the contents, and the mechanics of editing it and getting it formatted properly are secondary. The process is explained in PEP one. Your bug report would have gotten a much better response if you had simply asked "what is the process, I can't figure it out from the repo's README" rather that (again) complaining that the core developers don't care. Offending people is not the way to get them to help you.

Sorry, I didn't mean to offend anyone. It never was my goal. Everybody knows that I personally can easily find information about how to start new PEP - like this one - http://www.python.org/dev/peps/pep-0001/ I am not sure it is _the entry point_ I am looking for, because it may happen that there is a more up-to-date chapter about this in devguide. That's why I didn't paste any links - PEP list subscribers know a lot better about the process than I am. But the issue is - if my point of entry is PEP repo, and the first thing I do is reading the README, I expect it to contain the link to the PEP process, and this link is missing. It is not that I can't figure out something, it is that people need more time than necessary to find required info, and the time is the most valuable resource. Now there is a huge part about "community process vision", complains, analysis, request to resume CLArification work, and generic stuff about experience. It is not obligatory to read. About ill fated initiatives. I don't like when people prematurely close tickets without waiting for the mutual agreement that the problem is solved. Perhaps trackers should have personal "agree/disagree/meh" flags to help other people state their opinions, but until then the lack of time will always lead to the same communication problems. I value contributions people made for Python, even if I am not expressive about it, I do realize that without all these people it won't be possible. I can only regret that people can't self-sustain the feeling that they are important and that they take offence instead. Perhaps this offence is that makes them closing tickets without waiting for reply. Reply is not be required to close ticket for valid reason, but the point of conflict is that I don't like when tickets are prematurely closed under the reason of "you. do it right" instead of "let's make it better". Both "right" and "better" are subjective, but there is a big difference. "better" can be discussed, and "right" is not. I don't think it's ok. I understand that people don't have time to waste in chit chatting, but so do I, and everybody else out there. I am disrespectful to policies, that's right. I believe that policies need to be revised every couple of years, but nobody do this. Rules that work for folks that were present at the time the consensus is reached need to be explained to those who came later, and still you can't expect them to comply. Just because they don't have choice, they may choose to ignore, and community loses another contributor. I again complain, because I see many things that don't move and it doesn't make me happy. I can not be polite if I am not happy. From one side it's my own problem and I know about. Another aspect is that I won't have motivation to write if I am unhappy and polite - it is depressive. From the other side there is also a point of conflict that can not be ignored. People who signed CLA do not understand my position that CLA is harmful. They think that if I didn't sign it then I am just trolling and exclude me. I won't send patches until CLA is clear for every contributor and not like "common, just sign it, I am not a lawyer, but they know it is good". This probably make people upset, and they try to "help" you, so you have to maintain a sane amount of "dignity" to resist the pressure. People afraid to accept patches even when I *explicitly* give my permission to use them. I tired of writing patches that can not be accepted even with my explicit permission - permission in which I understand what I am giving out. But apparently there is something wrong with my permission - it is not incomplete, because if something was missing - people would tell me about it. But people don't understand what is missing. They say "you, do it right", "CLA is the right" way. I ask why, and there is silence. No, I've been given a lot of complicated books about lawyership, stuff that was written before I was born. I don't get it. That's my ill fated initiative to clarify the CLA and make Python contribution process free from FUD. People "do it right" and force other people to "do it right" as I see it. That's a natural process, but it can be constructive if the meaning of what is "right" is discussed and changed if necessary. Otherwise Python development becomes an exclusive privilege for those who comply or doesn't care about anything else. I am not using Python because of Python. I am using it, because it solves a whole heck of usability problems and ux issues with programming languages in this world, and I want Python development process to reflect on that matter. It may be that we are all missing something much bigger than we thought. I won't be surprised to know that Python 3 with all its internal beauty will never be successful, because of "artificial engineering" approach instead of "ux research" https://caremad.io/blog/a-look-at-pypi-downloads/ People are unreliable beings. While many praise Kenneth Rietz for inventing requests, I value him for fallibilism - is the word I learnt from his web site. I can throw in a simple idea that the "print() function changed the perception of the language" and now Python 3 is not the same simple universal tool I used to hack in my free time, and it might be true. But only in combination with other issues and features like opening text files not in UTF-8, constant headache about putting data in and out of Python with unnatural encode/decode paradigm, more complicated argparse, bigger docs. Everything may matter. My friend, biologist, who started from zero, said he finds Python 3 more understandable than Python 2. I can't share this feeling, but I accept it. Many Python folks can not accept that Python 3 may not be better. It just "don't right". I started to avoid using the word "wart", but I really want to see all these "gotchas" compiled in one place to iterate over them in community process. The process that can show that we can not rely on that somebody of us is "right". PyPy and IPython are more "right" is you ask me, but I still want mainstream Python to be better, and I want people who can make it better, to be able to do so. I am not the one who can meddle with internals, so I don't even try, but I can polish things on the outside, and this is what I try to do. I don't need Python as the best language in the world, I need it as universally understood one. Simple and generic, and perhaps bad and harmful for certain things. Python 3 is not simple, but it may be an intermediate step in forging a common vision of what is wrong with all that. This can become possible if developer expectations could be openly matched against user expectations and user experience of both. "git is complicated, because you don't do it right" - this kind of argument is very common and when majority of people start to think this way - you get "The Emperor's New Clothes" effect - mice prickle and cry, but eat cactus without saying a word. git could be better, but that attitude doesn't allow community to concentrate. That's was a weak attempt to define a vision for community process. I am not sure it is appropriate for this kind of mail, but there is no other place for it as I can see. Some points may be useful anyway. Community process may sound to abstract, so let's get back to the conflict. I am not sending patches, because most of the time I can not create them (that's irrelevant to the CLA). So I am trying to solve different problem - why people who can fix things, don't do this? And this thing is directly connected to their (user) experience of interacting with community. Here comes the CLA with different reasons why it is required. People say CLA is required, because of historical heritage and license stack. It is said that CRNI, BeOpen and other guys refuse to give up their "rights" on Python. Which "rights"? 1. Do they really want to control Python? 2. Or they just want to earn some points in Public Relations? 3. Or do they want to be respected as a vital part of Python history? These three are conflicting. I doubt that either CRNI or BeOpen choose (1). When why do they insist on license? They want PR points (2). But if stubborn and unclear license makes people less likely to contribute, it only makes reputation worse, not better. If they want (3) then we need to give them that. They don't need to enforce it with license terms. Enforcing doesn't earn respect either. This can be solved. People say CLA is required to protect PSF and Python, and you don't need to understand the text to sign it. I disagree and we won't reach any agreement here. I am radical in that I believe that "security by obscurity" is a bad approach to earn trust and respect between people. I demand human like CLArification. If Google and other parties managed to reduce lawyerish clutter, PSF can try better too. Sorry for being disrespectful to the community of lawyers that granted us all this "fun". People say CLA is required to contribute to Python documentation, and that's something that was discussed with no result. This is a lowest point and the most simple problem that can be addressed for now if somebody feel we should take an action and make something constructive out of this "otherwise likely to become ill fated" thread. https://mail.python.org/pipermail/python-legal-sig/2013-August/thread.html -- anatoly t.