On Tue, Apr 29, 2014 at 7:27 PM, francis wrote:

On 04/29/2014 01:33 PM, anatoly techtonik wrote:

...

Agile models [...]

adopt it, because it makes projects personalized, requires them to be open.While being open harms profits, the biggest problem is loss of control.

Could you please elaborate on why projects (A) get personalized, (B) need to be open and (C) there is a loss of control?

(A) project get personalized, because the driving force behind achievements is personal and even emotional, highly dependent on people involved in the process, how these people feel outside and inside of their working space, and if they are able to effectively communicate (B) openness is required to earn trust, in human systems trust is the main asset for healthy environment. you can not demand trust (or empathy), and being closed needs a very good arguments to be trusted. openness is important, because people want to act independently, and if people are not aware of the processes that happen in other parts of the company, they won't have confidence in what are they doing and won't be able to optimize and seek advice when their competence is not sufficient. closed systems often lead to situation where people need to receive permissions too often, and will lose the gumption soon (C) loss of control means that stakeholders become dependent on people. patents, NDAs, contract obligation and CLAs - these things exist to protect business from conflicts and human factor. they create environment that is independent of humans. this is the opposite of trusting people. loss of control means that there is no central authority (person or a committee) who is giving green light - the decision and responsibility is taken by people who make the solution. these makes it much more easier to do things. it is only important to keep team to be cross-disciplinary and practicing (no pure theorists).

PS: I'm just asking because from my experience cannot extrapolate that points (it may be that my experience here is too small :-))

This is my experience of working with cross-disciplinary teams. There is a high probability that it is highly dependent on age, social status, region and mentality, but this is why agile workflows were born.

Hi Nick, On Tue, Apr 29, 2014 at 9:39 PM, Nick Coghlan wrote:

Anatoly, if you try to be part of this project, I will leave it. Your complete lack of empathy for the point of view of others is not acceptable in environments I am attempting to work in.

I don't know how to react to that considering that it is a public email. em·pa·thy: the ability to understand and share the feelings of another. I don't think that you can understand and share feelings of people who are living in a world without perspective. Note I am not saying that I am such person, but empathy might be the last thing that these people need. If you're not ready to contact with such people - that's ok, but requiring to erase them from the open space that is also interesting to them is a little bit too much. I need tools that speed up development of technology, and started with user experience of collaborative Python support process since the day I landed my first related edit to the Python wiki. I believe it was several years ago. Since then I changed few jobs, but still couldn't find one that allowed me to dedicate more time and energy to the cause. My braincells are not loaded with knowledge how to earn a lot of money, but details of various core Python tools, Roundup tracker architecture, and observations on the processes that are enough to construct a vision. The only problem that to become a useful approach it needs more data, experiments and a little bit different environment. I am trying to send a signal to the subscribers of this list - don't try to solve the problem yourself - create an environment where people will be happy to solve that problem for you. You need more feedback from outside than you probably imagine.

Anatoly, if you try to be part of this project, I will leave it.

There is no need for you to leave. I am already banned or moderated from the most of Python things that were kind of important to me, and passive aggressive style of my writing won't hold me there for long. And I also don't want to be an annoyance if anything good is going to happen. If you need my expertise or feedback - I am open for collaboration, or ask Ezio - he is a good communicator and has a unique ability to filter emotions from rationale.

Hi Anatoly, This is getting long and very "meta", but I feel I must reply and explain further so that there is a chance that useful discussion can later happen in this forum. One important member has already said that he is considering leaving in light of your post, so obviously some action is required to save this forum, and I choose to do so openly and in the relevant context. I do ask that if you have any specific points you'd like to clear up on this subject, please let's discuss them privately before bringing them to everyone's attention. To everyone else, this here so that you can read it if you like, and for future reference. On Thu, May 15, 2014 at 12:09 PM, anatoly techtonik wrote:

On Thu, May 1, 2014 at 11:21 AM, Tal Einat 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.

Are general discussions about OOP are relevant on python-list? Despite Python being a programming language, they *are not relevant* unless they are somehow *directly* related to Python. A discussion about whether "agile" or "rigid" workflows would be better suited *for core Python* could be relevant on this list. In such a context, giving references to relevant sources of background info could be useful. However, starting a *general* discussion about types of workflows is not *directly* relevant. I am not saying that it could not possibly be useful to discuss here, but there was no previous discussion in whose context it became useful and relevant *now*. To phrase the above differently, the discussion here should assume that common concepts are understood by the participants. If someone doesn't know a concept, they can ask or do their own research. If, during a *directly relevant* discussion, there is a reason to make sure that the concepts are understood to mean the same thing by everyone, that would be a different matter. Even in such a case, though, a few pointers to good reading sources should be the start, and discussion should only arise if there is disagreement with those sources. That is usually quite rare.

...

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.

I am not angry at all. From previous experience from posts with such subjects, I have learned that they tend to cause tension and anger. A remark can be inflammatory even if it does not succeed in making anyone angry. For example, "vim rules, Emacs sucks" is a subject which may cause heated debate -- it is inflammatory because that it what it tries to achieve. This can be true even if the author didn't mean for it to be inflammatory.

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

Uninformative does not mean I need more information. It means that you wrote something which does not convey much information. Your subject is like "virtue: good (north) vs. evil (south)" -- not much information in there, and also confusing and mixing up unrelated concepts. I do insist that "gameplay" and "process" are confusing and out of place in your subject. I've done "classic" work planning with "games" and I've done "agile" without them. And both "agile" and "rigid" are different kinds of processes, so calling one of them "process" is a mistake.

...

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.).

And here is the source of the problem -- "agile" is not a very well defined term, and different people understand it differently. From my understanding, "agile" is not about combining several patterns from a pool of well-known ones such as Kanban or "planning poker". And even if that is your understanding of the term, that has nothing to do with the personalities of the people involved.

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.

"Corporate workflow" can be just as adjustable as "agile". I've seen teams do "agile" without changing their process over time. On the other hand, I've seem teams do "classic" development but adjust their positions, responsibilities and processes very often. Whether the workflow is adjusted over time, and how often this happens, is unrelated to whether this workflow is considered "agile". "Agile" usually means that the work plan is flexible -- not the process itself! The plan is changed often to meet changing requirements, customers or other needs and limitations. Even in "agile", the process by which the work plan is created and changed can stay the same or be changed over time, but that is a different matter.

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).

No, that means that the process is rigid. I can write a formal paper describing the different roles and interactions for SCRUMM (an "agile" methodology), enforce those in an organization, and have as a result an "agile" workflow with a rigid, highly-specified process.

...

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.

I read that several times but can't quite understand what your point is. If the available personnel and their competencies are limited, that is just one factor that should be taken into account when planning work or defining processes. If you need to be careful not to drive away potential contributors, that is another such factor. This last is something you've been mentioning often so I'm guessing it is at least part of what you're trying to say. And still I don't see how "agile" or "rigid" has anything to do with this. For anyone still reading: The following part is about Anatoly's personal feelings about and experience with the PSF. There is nothing remotely related to workflow issues.

...

...

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.

What you personally don't like about the PSF really isn't relevant here.

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.

The PSF's effect on the workflow is very indirect, especially as you describe it. To claim that such indirect influence is reason to voice your opinions of the PSF here is just an excuse. As is obvious, the PSF is not dictating any process or workflow, and is hardly taking part in the discussion as far as I can tell. This is all being left to us, the community of developers. So leave the PSF out of this discussion -- it isn't relevant.

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.

Come on, really? "a short hacker's guide" ... "what every word means"?! Your requests are not being granted simply because they are not reasonable.

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.

Several such people have contacted you and tried to help you understand these things. It is very annoying that you say that they have not! They have invested more time and effort with you than they should have and you ignore that completely. Your lack of respect towards them is outrageous.

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

How can anyone ever know that she is doing something "right"?. There usually isn't any "right" way to do things. Your argument has no merit.

...

...

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)

Regardless of how you came to it, the subject you chose is terrible. I've already gone into detail about this above.

...

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.

Perhaps some processes do this, but not all. As I've explained above, "agile" is usually taken to mean that the work plan is flexible, not the process itself. It is natural that people who choose a flexible work plan as a solution to quickly changing requirements and needs will sometimes also be flexible with their process as well. Still, you should not confuse the flexibility of process by which work is done with the flexibility of what is done using that process.

...

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?

Absolutely. As I mentioned in the beginning, please take up any additional related points with me privately. This discussion must not continue here. - Tal