I have edited your post to make it readable. Do not start a line with a space, it suppresses line wrapping and forces the paragraph to be rendered in a fixed width font.. If you would like to discuss the processes I suggest you use the same feedback forum I referred you to the last time you chose to use a support forum for something it was not. https://support.mozilla.org/en-US/questions/1388966 Lets look at documentation however. I wasted years trying to even keep the basic documentation for Thunderbird up to date. A complete waste of my time is all I felt is was, not updating it certainly did not increase the number of support requests, nor did it change the basic quality of the questions. This forum has always been full of questions that were fully answered in the documentation however everyone is focused on getting someone to answer their question for them. I have given up on documentation. No one appears to read it and most that do somehow manage to fail to understand what they read based on their interpretations I see in forums. However I came to the conclusion that most of those seeking answers are not interested in actually reading to learn, only to have their personal question answered by someone that did the research for them. As for your quote, I don't think it would be me, because I am not proud. But there is no nicely-written and bound manual. There was one initiated about 15 years ago, it was written and never updated. I think the keys to the flossmanuals site used to develop it were lost when Mozilla Messaging closed as that was around the same time. It is still online here https://archive.flossmanuals.net/_booki/thunderbird/thunderbird.pdf However manuals are largely a thing of the past. People just do not read them, just as people no longer buy books from bookshops. There was flurry of "idiots guides" some 15 years ago to cover the lack of understandable documentation for many products from vendors. Thunderbird however never got one. As far a your software documentation. I am guessing you works on big iron. We had book cases full of documentation and user manuals for everything from MVS to IBM skeletons. We even had software specification documents that outlined the inputs, process and expected outputs from each process. That is not how software is developed these days. This is the only documentation https://searchfox.org/comm-central/source/mailnews beyond the discussion in the relevant bug reports that can be linked from the last source change in each file. This means that if you are trying to document anything you are in rather an interesting situation where even if you know doing such will cause such an action, you never really know if you are documenting a bug or a planned behavior. It is like this supernova thing. It is here and has been delivered. What is clear is it is not complete. But what proportion of the original scope of the development on that project is complete is unknown. I think to anyone. It certainly has not been made public. Add to that that anyone outside the development cycle get around 6 weeks to identify the new bits and document it before release and you are actually talking about an effort requiring more hours than the initial development. Mozilla has never been about documenting their software, either at the source level (code comments can be misleading and are at times left overs from the last century at Netscape) or the user level. Now if you would like to take over writing the support documentation, I am sure you are welcome to the job. I am certainly not doing it any more. Each time I hand it off, the person just disappears after a relatively short time because it is a thankless job with lots of folk demanding a high level of documentation from a maintainer generally of one person.