[Python-ideas] Iterative development

[Nick Coghlan]

On 8 Feb 2014 07:44, "Stephen J. Turnbull" <stephen at xemacs.org> wrote:
>
> anatoly techtonik writes:
>
>  > Yes. A lot of if you read "agile methodology" as "flexible set of
>  > practices to organize a team work".
>
> You're missing the point.  Agile methodology is about *reducing*
> flexibility in interaction and *increasing* organization, by imposing
> practices that increase productive contacts among developers without
> (hopefully) imposing much "bureaucracy."  That works extremely well if
> the community needs more structured workflows, not least because the
> lack of hierarchical bureacracy appeals to programmers used to working
> in chaotic environments.
>
> However, Python long ago developed structured cooperation that seems
> to me to be working very well for the existing developer community.
> What you are suggesting is not just introducing an "option" to use
> agile methodologies, but a proposal to *change* the workflow.  This
> will almost certainly be inconvenient and reduce participation by
> existing contributors.  In other words, increasing bureaucracy.
>
> I really don't see any benefit to Python in adopting your proposals.
> The "bureaucracy" involved in Python processes is both minimal and
> useful -- it directly contributes to the extremely high quality of
> successive Python releases.

It's also deliberately structured to create *less* work for the core
developers (and PEP 462 is a proposal to introduce even more automation to
eliminate some of the current more tedious parts).

The thing about the various Agile models are that they are a tool to
improve communications flow between a development team and the rest of the
company they work for. It's pretty good at that task, but it requires a
highly cohesive team, working on short time frames to meet the needs of a
particular business.

This is the complete opposite of the way a relatively loose collaborative
project like CPython works - each of the core developers is contributing
for our own reasons, and while we do self-impose deadlines in order to
actually get things shipped, that's largely voluntary - if a feature isn't
ready, it isn't ready, and slips to the next release.

The contributor documentation we provide is there not only for our own
reference, but also to help people get involved if they want to, both
because there's a natural attrition rate to open source development (so
current developers move on and need to be replaced by new contributors),
and also because the standard library is large and we can always use more
help (and PEP 462 is largely about making more effective use of the help we
*already* receive).

The conflict between the core development team & Anatoly has always been
that he wants *us* to change *our* practices to accommodate *him*. He first
wanted us to move all development discussions to Google Wave because *he*
preferred it to email. Then he wanted the PSF to drop the CLA relicensing
terms, even though we need them to account for the CNRI licensing history,
and even after a PSF director sat down with him at the PyCon US sprints to
explain the terms and the need for them. Most people that refuse to sign
the CLA are polite and either walk away entirely, or recognise that
refusing to sign it will greatly restrict their ability to contribute
constructively. Anatoly, by contrast, continues to try to interact with the
core development team as if he was our direct manager, and then acts
surprised when people react badly to his completely unjustified sense of
being entitled to tell us what to do (as well as his making proud
declarations of the fact that he has deliberately chosen not to read the
existing contributor documentation, because he finds doing such a thing
boring).

Cheers,
Nick.

>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140208/e2d92ff0/attachment-0001.html>