In my time of contribution to IIO, I had some fun and learning situations. These things probably happen frequently to newcomers, but as common as they are, you are many times unprepared for them.
“HTML mail is not permitted on the Linux Kernel Mailing List”
I always send patches using neomutt (again, Siqueira has well-made setup files for neomutt here: https://github.com/rodrigosiqueira/myConfigFiles/tree/master/roles/neomutt/files/mutt). I find the neomutt a cleaner and more efficient mail client to format patches with all the necessary information. Moreover, it provides a second chance to revise the code and messages before sending it. It also helps the developer to comply with email sending etiquette standards. Yes, it exists and is briefly explained here: https://kernelnewbies.org/PatchCulture.
Some colleagues have allerted me about the mistake of sending an HTML e-mail to the mailing list. However, I’m a beginner and I fell into the trap of incorporating HTML when replying to an email on the list. This happened was because I decided to reply to a patch comment using the Gmail website (without checking the plain text option). Does checking this option really solve the problem? I don’t know. I was so embarrassed that I preferred not to take any chances and, since then, I only send emails to the list using neomutt. Honestly, I was afraid to receive some rude answers about this mistake.
Finally, I resend the email by apologizing. Life goes on :)
Who is this guy?
In the beginning, I had an idea that Jonathan (maintainer), the author of the driver and those in cc of my patch-email, are the only ones who could make an opinion about my patch. So, the first time that an unknown developer criticized my patch’s style, I was wondering: who is this guy and why is he criticizing my patch?
One of the things I learned in life is to wait. You don’t have to be the first to respond when you’re in a group activity, and, some times, you don’t need to answer anything. I also understand that developing for Linux is always a group activity. The team is not fixed, you don’t know all the participants, but you need to know that good group activity practices usually work on the Linux community. Also, remember that you are in public and the audience does not also know you (and may never know you); so what you write is free of interpretation as well.
Therefore, I waited a while for most experienced developers and any possible involved in that code to give their opinion too. Finally, I asked my colleagues at FLUSP, who was that guy and found out that he was a very experienced developer at one of the main companies that develop devices, in addition to being very active in the community. So this guy was much more experienced and capable than I was and he knew exactly what he was doing. Furthermore, he stopped his time to carefully review my patch (a so simple and not very relevant patch), from an inexperienced developer. So who am I to find anything? hahaha
Finally, I believe that not knowing who is the person that is commenting on your code is (or should be) the standard of developing for an open and geographically distributed community.