[Python-Dev] PEP process entry point and ill fated initiatives

[anatoly techtonik]

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.

https://mail.python.org/pipermail/python-legal-sig/2013-August/thread.html
--
anatoly t.