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 <[email protected]> wrote: > On Thu, May 1, 2014 at 11:21 AM, Tal Einat <[email protected]> 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 _______________________________________________ core-workflow mailing list [email protected] https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
