[Python-ideas] Iterative development

[anatoly techtonik]

On Thu, Jan 30, 2014 at 7:17 PM, Zachary Ware
<zachary.ware+pyideas at gmail.com> wrote:
> I haven't been following this thread very closely, but I have to
> disagree with you here, Anatoly.

That's ok. Kenneth Rietz converted me to fallibilism, and I hope to spread
the virus further.

> On Thu, Jan 30, 2014 at 5:24 AM, anatoly techtonik <techtonik at gmail.com> wrote:
>> It is quite obvious from outside that Python has some kind of process,
>
> Which is well documented in several places.  It can be tricky to
> always find all of those places, but anyone who is interested can ask,
> and will be quickly shown where to look.

MIT Technology Review had an article about decreasing participation
of Wikipedia. Here is the quote:

"The main source of those problems is not mysterious. The loose
collective running the site today, estimated to be 90 percent male,
operates a crushing bureaucracy with an often abrasive atmosphere that
deters newcomers who might increase participation in Wikipedia and
broaden its coverage.

In response, the Wikimedia Foundation, the 187-person nonprofit that
pays for the legal and technical infrastructure supporting Wikipedia,
is staging a kind of rescue mission. The foundation can’t order the
volunteer community to change the way it operates. But by tweaking
Wikipedia’s website and software, it hopes to steer the encyclopedia
onto a more sustainable path."

http://www.technologyreview.com/featuredstory/520446/the-decline-of-wikipedia/

Bureaucracy deters newcomers, and knowing that most people don't
read, but scan, I believe that Python should also think about ways
to tweak software and process for new generations instead of placing
bureaucratic filters to allow only those who comfortable with old ways
of doing things to pass by. Most people are lurkers and won't even
dare to ask a question especially as (silly) as the one about the
process seems.

>> but it is quite hard to sync to it for people from outside,
>
> I'm not sure what you mean here.  Every contributor starts from
> "outside" of Python.  I found no difficulty in getting started when I
> did, and I've seen several people start contributing successfully
> since then.  It would be very hard to go from nothing to suddenly
> contributing huge patches to the innermost details of Python at a
> rapid pace, but that's not really what people (especially people new
> to open source development, like I was) should be doing anyway.  Start
> slow and small, build from there, and it's an easy and painless
> process.

And if you just don't have a time for that? If you have a cancer and
going to die in the next couple of years if technology won't be advance
enough to save you?

People have different goals in mind and you're trying to impose your
own way on them, which won't suit them. That's why, again, I am not
proposing to replace current development practice. I just want to see
that people can see benefits in following a parallel route and try to
think about those benefits, and not about intrusiveness about some
idea in comfort zone of their established workflow.

Which leads me the the interesting observation that if people used to
things, they are less likely to discuss specific arguments,
because there is no problem for them personally. Which divides the
community into contributor and non-contributors and makes the
communication between parties hard (if not impossible at all).

>> because it is not open
>
> Here I must disagree emphatically.  My entire Python experience shows
> me that everything about Python is as open as possible.  If you want
> to know something, look for it.  If you can't find it, ask for it.  If
> you can't be shown where it is, somebody (even yourself) will write it
> down somewhere so the next person looking can find it.

I agree that Python strives to be as open as possible, but there are
projects that do it better. The notion of open is subjective, but the criteria
that I use is if information is buried under piles of other information and is
tricky to find - it is not truly open.

In strictly technical terms of information theory - if information didn't
reach the recipient - the information is unreachable.

But.. it is my general point of view that Huxley wins over Orwell. In
original mail there was the specific notion of open that you generalized.
I stated reasons why the process is not open, one of which you've
left below:

>> - is not completely clear how the planning is made,
>
> I'm not sure what you mean here, what planning?  Anything that could
> be construed as "planning" is done via the PEP process, which is well
> documented in PEP 1.

I believe that question constitutes the answer. There is not planning, so
it is not clear what's going on, so it is not possible to jump in and help.
Yes, you can ask, but really - who'd do this? Internet has many other
things to do than messing with all this mailing list communication stuff
that people find "easy".

>> which tasks are available for current sprint, what you can help with and how to track
>> the progress.
>
> This is the very definition of a bug tracker, and Python's is quite
> good for all of this.

Ok. I opened the tracker. Who's doing what currently, what is being done
for the next release and what can I help with? I don't see the answer
there. I am pretty sure it is a documented somewhere on the internet,
but I already look into internet I don't see it.

>  There could stand to be some upkeep done on
> some of the older issues: it would be good for an impartial person to
> pick through and see whether an issue is still a problem, update any
> patches to apply to current branches, manage the 'easy' tag, add the
> proper people to the nosy list, etc.  This kind of thing would be a
> great place for someone to contribute.  Honestly, just bringing all
> tracker issues up to date would be a worthwhile sprint task in my
> opinion.

The only problem that if you're not a committer, you don't have any
of the privileges to do the stuff what you've mentioned above.

But that's not the reason why the whole useful stuff is not done right
now. The reason is that current process doesn't support it or make the
whole process not fun.

I am glad that we have a first *recurring* task that can be solved with the
idea of iterative development process. It is "bug triaging" task which can
be decomposed into more fun "cave hunting" task that addresses the
most ancient issues to refactor, reclassify and deobfuscate them,
e.g. push the progress in incremental way.

For this to work, the progress should be measurable for two weeks
period:

[ ] entomology works for open species in range 1034-2000 (xx total)

Which when completed is accompanied with analysis on the problems
encountered and recommendation (consensus) what do to with each.

specimen no.1034 - thread started from a patch, which was discussed
and agreed in ML, LGTM required author to do nitpicks with user
comments and more tests, which never happened. specimen filled in
2007-08-27 for Python ???, after 1 year 5 months reworked by core
contributor for Python ???, missed the 2.7 deadline, planned for 3.2
and seems like missing it too.


I don't know about you, but I see here a few very interesting problems
in the process of dissecting this specimen that will be visible after
the first iteration and what could and will be addressed in the next
iterations by people who choose to work not on Python, but on bug
tracker instead. That is the flexibility I am talking about.