[Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047)

[Stephen J. Turnbull]

anatoly techtonik writes:

 > I'll abandon my efforts when you prove me that current "documented
 > process" is a top-notch way for all interested parties to do a quality
 > contributions to make Python better.

I think the product of the process speaks very well for the process.

 > The most valuable contributions are coming from professionals, and
 > these people often don't have enough time to follow "documented
 > process".

I think you have that exactly backward.  It is precisely the seasoned
professionals who value process most.  Professionals are good at
managing their own time and can handle process if they can make it
routine; but they get annoyed and go away if you break their routine.
It's non-professional newcomers who are most attracted by minimal
process.

 > the biggest problem with current "documented process" is that
 > nobody even thinks about it.

Look harder.  People thinking about the "Python process" are all over
this list, not to mention featured PEP authors.  (It's this kind of
gratuitous exaggeration that Nick speaks of.)

In general, you remind me of the "let's import Japanese practices"
management consultancies of the '80s.  They failed dismally, because
none of the famous Japanese process innovations are standalone.  They
depend on each other and on a common culture, both lacking in the
U.S. and Europe.  That doesn't mean that quality circles, JIT, and the
like haven't been successfully applied outside of Japan, but they work
differently and organizations had to adapt both the Japanese practices
and their existing processes to get any advantage from the
innovations.  I think the analogy to software process, including in
open, open source projects like Python, is quite strong.

If you want to change the process, I believe that the most effective
way is kaizen, ie, gradually improving by sanding down some rough
spots, not by whacking off whole subprocesses that you believe are
wasteful.  Truly wasteful subprocesses generally don't survive in this
environment.  You should look harder to figure out what they're good
for, and then gradually wean the project from them by providing
alternative ways to accomplish those goals that are less wasteful, but
compatible with other aspects of the existing process.