Hi Katherine, On Thu, 07 Sep 2023 at 14:39, Katherine Cox-Buday <cox.katherin...@gmail.com> wrote:
>> Maybe it's time to take a step back and instead of asking “How can >> we >> decrease the cognitive overhead for contributors?”, we should >> perhaps >> ask “For which contributors do we want to/can we decrease the >> cognitive >> overhead?” > > That's interesting, because I view this as the antithesis of what Rich > was trying to convey. > > That quote is at the end of a dismissive ad hominem response which has > grossly misinterpreted this discussion, even attributes it to malice, > seems to draw the conclusion that contributing to Guix should be left to > those for whom the current situation is fine, and even intimates that > those who would like to improve the situation are incompetent. About the dismissive ad hominem response, sorry. I should have clearly mentioned that I was fully rejecting the rest but only keeping the argument I was quoting. > Here's the quote from Rich's talk: > > The fact that we throw these things around sort of casually > saying, "Oh I > like to use that technology because it's simple. And when I say > simple I > mean easy. *And when I'm saying easy, I mean, because I already know > something that looks very much like that*" is how this whole thing > degrades, and we can never have objective discussion about the > qualities > that matter to us in our software. > > Rich is saying that there are intrinsic properties to approaches that > make them simple, but possibly not easy, and that we shouldn't rest our > arguments on claiming something is "easy", because that term is > relative, and often related to familiarity. Familiarity is a hard bias > to overcome. Yeah. I think I had already gotten it. ;-) For someone who already plays guitar, then ukulele is “easy”. For someone who does not know any instrument or nothing about music, ukulele is “hard”. Although, the complexity of the ukulele is the same in both cases. « For which contributors do we want to/can we decrease the cognitive overhead? », so I read it as: do we discuss about someone who is already playing guitar or someone who is knowing nothing about music. We already have the answer: we are speaking about someone who already plays guitar (a skilled programmer). As you said elsewhere in the thread, we are all different, we all have different backgrounds, etc. and the idea behind “easy is relative” implies that we have to bound for whom it needs to be easy. “How can we decrease the cognitive overhead for contributors?” Here, contributor is not explicitly defined. In all the thread, the term ’contributor’ is interpreted very differently. Well, I repeat my very first message: Well, from my point of view, we are using here the term “contribution” as it was one homogeneous thing. [...] For example, a two-line patch trivially updating one package is not the same contribution as several-to-many two-line patches more some package additions for updating all the R ecosystem. And that’s not the same as rewriting the Python build system or as packaging the last version TensorFlow. The cognitive overhead for these 3 contributions is not the same. Therefore, the way to reduce the friction will not be the same, IMHO. A task is not “easy“ by itself. It depends on 1. the complexity of the task and 2. on the person who does it. We are saying the same thing, no? Now, this discussion has identified various frictions that are useless and bring no value for the project. It is clear that we need to improve by smoothing or even maybe removing some of them. Somehow, now we have to discuss about specific task, task by task, and propose how to improve. Survey is one next action for collecting data. The other action for more automation is not clear yet. We need to open discussions about QA, scripts, etc. For what my opinion is worth. > Read charitably, this quote suggests that there is a singular, best, way > to do things, and that if it doesn't work for some, the problem is not > the process, but that "those people" are incompetent. Saying it plainly and stretching a bit, yes “easy is relative” means some people do not have the background to complete some process. Reading the word “incompetent” as “not possessing the necessary ability, skill, etc to do or carry out a task; incapable” I am incompetent for playing guitar for example. And playing music is really not easy for me. And so? :-) It is related to the question: for whom it has to be easy. A good example is the switch to some web interface for the translation. Some translators does not have programming skills, so they are incompetent for programming, and it was not easy for them to configure the tools for contributing to translation. The improvement had been the removal of the friction by switching to some web interface. Now, the process is probably not easy for people like me that are not used to web interface, although interacting with web interface is a simpler task than configuring some tools for editing translation files. Somehow, the new web interface makes me “incompetent” for translating. It is about finding the right balance. Hum, we are far from the initial discussion. ;-) Again, I think we are expressing the same thing and we are on the same wavelength, I guess. :-) > This is classic gatekeeping. Sorry, I do not see any gatekeeping. Because all seems open and many people are doing their best for helping. Maybe that does not work, maybe that’s not enough, yeah maybe but I do not see “the practice of controlling access to information, advanced levels of study, elite sections of society, etc“. Well, are you French? ;-) Because I feel we are discussing unrelated points emerging although we are agree on the core and we just detail tiny variations of the same thing. :-) >>> - Differentiating the types of complexity (importantly defining >>> incidental complexity): https://youtu.be/SxdOUGdseq4?t=1173 >> >> It appears to me that it is also what I have tried to say in my very >> first message [2]. :-) >> >> Well, from my point of view, we are using here the term >> “contribution” >> as it was one homogeneous thing. Instead, I think the term refers >> to a >> range with a gradual complexity. And the improvements or tools >> maybe >> also need to be gradual depending on this range. > > This is crucial, so please forgive me if I belabor this point. > > You are correct that there are a range of ways to contribute, and some > of them are intrinsically more difficult. But irrespective of that range > of difficulty, *improving the accessibility and experience helps everyone*. Are we on a wrong road? Because we speak about the same thing, I guess: a skilled programmer (you!) who wants to contribute to some packages and does not find it “easy” by pointing several apparent frictions. So it means we have a problem! Period. :-) The question is how to improve? Now, after discussing it – thank you for opening this can of worms, it was necessary and this discussion is very helpful! – we have some items to act on, no? Just to point, the root of the discussion about the commit message format is about complexity, not about easiness. Is the current format too complex than no one finds it easy? The various steps for checking and submitting patches are simple but they are not easy. Therefore, we must remove that because making hard as not value. About the commit message format, we could make it simpler, which would lead to probably have something easier, but would we keep the value we have with the current complexity? > On the contrary, throughout this thread, I've thought that you > understood the larger picture. I'm just responding to points where I > thought I could contribute something, or where the points I've made have > been challenged or questions have been asked. Thank you very much for all the efforts and time you are putting in this topic. They are worth and very fruitful. I totally agree with your words: If Guix is for everyone, then we should do our best to ensure everyone can contribute with the things they're skilled at. And my point of view is that is a very big task so we need to start somewhere and incrementally improve in order to reach this goal. Cheers, simon