[Python-ideas] Iterative development

[anatoly techtonik]

On Wed, Jan 29, 2014 at 5:18 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 29 January 2014 23:57, Chris Angelico <rosuav at gmail.com> wrote:
>> On Wed, Jan 29, 2014 at 11:29 PM, anatoly techtonik <techtonik at gmail.com> wrote:
>>> If information doesn't reach the recipient who want to read it, it is "hidden".
>>> Even if you talk in public channel on IRC, the information is hidden from me
>>> if I was not connected and channel doesn't have public logs.
>>
>> Then if you care, connect. It's not hidden if you have the power to access it.
>>
>> Here's a suggestion: Fork Python (that's legal, that's what open
>> source means) and start development using the model you advocate. If
>> it's massively better than what's happening, (a) developers will flock
>> to your model, and (b) the project could be completely handed over to
>> you, as happened with GCC.
>>
>> Or alternatively, explain to us here what the real advantages are of
>> your new model. So far, what I've seen is "hey, here's an idea", and
>> not "here's what this idea will do to benefit Python"; and the idea
>> itself looks more suited to a big business than to open source. Maybe
>> someone who's actually used Agile will know what's so wonderful about
>> it, but unless every core dev *has*, a bit of explanation will help.
>
> Plenty of us have used it, and we know it's an entirely inappropriate
> model for open source development projects with broad asynchronous
> participation, as the time commitment needed to make the short cycle
> work is antithetical to loose collaboration. It works well for a
> focused team supporting a single application to meet the specific
> needs of a single business, though.

About *Agile*

I tried to avoid the word Agile, but since you saying that you've used that,
let us agree on terminology. In my world *agile* means *flexible*, which
means *able to change*. It doesn't mean *scrum* or *two weeks sprint*
or any of the hardcoded value that you put behind the phrase of "entirely
inappropriate model for open source". Not that that's clear, let's move on.

"Asynchronous participation" is called "distributed development", and it
is used both by open source and by commercial companies a lot. If
Yahoo terminated this practice and Google didn't even try - that's a
problem of management of these companies. It doesn't mean it doesn't
work for professional teams or people *interested* in interacting this way.
Agile helps to analyze and improve distributed development processes
the same way it does for rigid corporate practices.

You say - "short cycles" are bad. In agile I'd say - let's try and see why.
Maybe it's cycles what are bad, maybe it's people who can not sync
this often, maybe there is a technical problem with communication that
can be resolved by using right tools.