[Python-Dev] PEP process entry point and ill fated initiatives (original) (raw)

anatoly techtonik techtonik at gmail.com
Fri Nov 29 12:08:31 CET 2013

On Thu, Nov 28, 2013 at 9:39 PM, Guido van Rossum <guido at 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.

anatoly t.

More information about the Python-Dev mailing list