[core-workflow] workflow types: agile (gameplay) vs rigid (process)

[anatoly techtonik]

On Thu, May 1, 2014 at 11:21 AM, Tal Einat <taleinat at gmail.com> wrote:
>
> First of all, your post is off-topic for this list. We are here to
> discuss the workflow of core Python development and related tools, not
> to have general discussions about workflow.

It is the same as saying "We are here to discuss the structure of objects
of our program, not to have general discussions about classes".

Don't you think that discussing structure of objects without touching
classes is a little bit weird? You do realize that everybody should know
at least what kind of possibilities are available.

> Next, using a title such as "agile (gameplay) vs rigid (process)" is
> inflammatory (= will make people angry) but uninformative and
> unhelpful.

We are speaking about some imaginary angry people or it made you
angry? If it is so - say it to me. I don't understand why it makes you
angry and I won't if you don't tell me. You can use private email.

About being uninformative - I am waiting for questions. And note - it's
not me who is starting offtopic.

> Furthermore, to the extent of my understanding of the relevant terms,
> you show a complete misunderstanding of them. Here are some specific
> examples:
>
>> Agile workflows often take into account
>> personalities, habits and environment of people
>> involved in a process.
>
> I have never encountered a workflow which specifically takes into
> account personalities and habits. In my opinion it is silly to say
> that agile workflows take personalities and habits into account while
> other workflows do not.

It is said that agile workflows often take personalities and habits into
account. Not that all agile workflows do this. If you take personalities
and habits into account and adjust your workflow accordingly, then it
is flexible. If this workflow can also adapt to other factors dynamically
- it can be named agile (usually "agile" means that your workflow is a
combination of well-known patterns that are combined - kanban,
iterations, backlog, othergameplayhere, etc.).

It will help to understand it better if you compare it to usual corporate
workflow, where you have a "position" and a set strict actions that this
position can do and what responsibilities it has. This is not adjustable,
so it is a rigid workflow.

Workflows also have an indicators that they are rigid. If there is a
formal paper that regulates interactions, then there workflow is most
 likely rigid (hard to change).

> On the other hand, regardless of workflow, any specific development
> group should take into account many considerations, including the
> environment and its members' personalities and habits. This has
> nothing to do with workflow, so I simply cannot make any sense of your
> above statement.

Yes, it seems obvious that every development group naturally tries to
take into account many considerations, including environment, but in
parts of the world where most outsourcing takes place you often
can not adapt environment - the environment filters and forges people.
Many just leave. In remote teams you need to be extra careful about
people and bus factor. Many competencies are unique and you don't
have a community of developers on your project to filter from.

>> Just think about why different people don't feel fun
>> contributing to Python overall, who are those people,
>> why Python community needs them, and how you
>> can help them by removing obstacles.
>
> This is precisely what the Python developers and the PSF have always
> done. Specifically, in recent years they have been spending more and
> more time and effort on this. Despite this you have repeatedly (now
> and in the past) accused them all of not doing so, and you are simply
> completely *wrong*. This just shows how distorted your view of the
> Python developers is.

I never said that PSF doesn't do anything at all. My main criticism is that
what it does is insufficient, lacks visibility, does not have a feedback loop,
and as a result - not effective. FWIW, I don't like that PSF protects
legalese instead of defending open source values, it doesn't invest in
researching and solving conflicts, can't set focus for community, organize
collaboration and open environment for hacking, learning and
cross-disciplinary exchange.

I am saying it here, because PSF is major factor that affects people
minds and as a result, evolution of workflow tools. Some people don't
participate, because there is an organization that exists to solve problems.
The hope that if somebody is active in doing something, this organization
works with them in reaching their goals, help them, not limit them, ignore
or ban. If there is an opinion, this organization counts that opinion, makes
stats, provides something that this person can not provide.

PSF is made for legalese. I asked many times to provide a short hacker's
guide on CLA - why it exists, why the wording is like this, what every word
means, why these specific words are there, what countries are affected,
why some clauses don't work by default and what needs to be changed to
make open source a better place like it was before. Legalese if the primary
function of PSF as I see it. Does anybody who can help to answer these
questions tried to contact me? No.

What is the PSF workflow? How does it know that it does anything right?

>> workflow types: agile (gameplay) vs rigid (process)
>
> This is ridiculous. Every agile methodology I have heard of includes
> some specific process for development. From all of the development
> groups I have been in or worked with, those which used "agile" methods
> had much clearer processes which they actually stuck to and which were
> usually more effective. "Agile" does not mean not taking work
> seriously and it is not an excuse for lack of process.

There is nothing contradictory with what you say. I completely support
this. It is confusing use of parentheses on my side. Title undergo an
evolution to become more clear, but final mutation changed meaning:
-> agile vs rigid workflows
(there are people who don't know about agile or who think that agile
 is another buzzword)
-> workflows: agile vs rigid
(still there is no definition what is "agile" and what is "rigid", and I am
the one to educate or coin one)
-> workflows: agile gameplay vs rigid process
(it is not about gameplay vs process, so accent should be on being
 flexible and not try to make PEP that will filter people)
-> workflows: agile (gameplay) vs rigid (process)


> Perhaps you have met some developers who used "agile" as an excuse for
> not defining processes, but you would be wrong to think this is true
> of all other groups who use "agile" methods.

Now it is crystal clear that "agile process" is also process, and the
main difference from "rigid process" is that "agile" process includes
a mechanism for changing itself as soon as it is necessary.

> To summarize, this post is off-topic, inflammatory and contains
> several grossly incorrect statements. In my opinion this discussion
> should not continue here.

Do you still think so?
-- 
anatoly t.