On Tue, Nov 5, 2019 at 3:17 PM Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote: <snip> > My intention was to provide some scope to the problem, because it > seemed that a lot of alternatives being floated were not seeing some > of the more subtle cases that we were trying to address. However, the > biggest problem is that nearly every email to the list has been > started with a "Begging the Question" Fallacy. People have started > from the premise that "Modularity is Bad" and all of the rest of the > conversation has continued from there. I'd like to provide an > opportunity for us as a community to *constructively* state our > grievances with Modularity. The fundamental root cause of some of the > miscommunication is, I believe, that Modularity has problems and that > people have assumed that they are fundamental and unfixable. Others have contacted me privately and indicated that my choice of words here did not convey the tone that I had intended. It makes it sound as if I am accusing people of being disingenuous. I had meant to indicate that we (as fallible humans) were falling into the "Begging the Question" Fallacy as we had pre-judged the situation and then proceeded to continue talking as if those judgements were forgone conclusions. I myself have been guilty of doing the same at times in those threads and have been actively attempting to catch myself when I do. My intention here was to help others notice the same of their own contributions. I do apologize if it came across as dismissive or accusatory. It can be difficult to convey intention over plaintext. For what it's worth, you can reasonably start reading the email from the following section and not be missing anything except my poorly-chosen lead-in. > I'd like to gather a constructive list of the actual use-cases that > you feel Modularity is causing problems for, with the following > stipulations: Any *subjective* problems will be ignored. "I think > writing YAML is harder than writing a spec file" is an example of a > subjective opinion. Similarly, "change inevitably results in some > learning curve" is a basic maxim of innovation and is not in and of > itself an argument not to change. "Modularity requires me to write > both a spec file and a YAML file, thereby increasing the total work" > is an *objective* observation (and a valid one; I'm going to include > it below in my own starter list). If you aren't sure if it's > objective, a useful question is "is it quantitatively measurable?" > (AKA "Can I assign a number to it and see that number increase or > decrease when changing something about the implementation?") <snip> _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
