Hi all,

surely most of you will have read Ryan's post "Update from Thunderbird Product Manager" on tb-planning. Allow me some comments.

In the first section Ryan describes a drive to improve product quality, hear hear! Until recently Thunderbird with 25 million users and about 15 developers had no formal QA team whatsoever. Developers did their own testing and there were a few volunteers doing release testing. Needless to say, that many regressions slipped through, for example in 91.3.2 calendar printing was broken. Now one poor guy has been "repurposed" as a (quote) "QA person". I wish him all the luck of the world. In comparable development, there is a ratio of 3:1 or 4:1 of developers vs. QA.

I've personally suggested to Ryan back at the end of 2019 to create a team dedicated to QA, bug triaging, regression tracking, fault analysis and enterprise support, but that was ignored since the drive has always been, and still seems to be, more and more and more developers. Nice to see that the project has picked up some of my suggestions after 2.5 years.

In the next section Ryan talks about usability and user interviews. Well, what users want is already known, one just has to look at the tickets/bugs in Bugzilla. For example, users want a multi-line message list, a feature they know from Outlook or Postbox. There are two bugs (213945 and 441414), the earlier from 2003(!!) with a combined almost 300 votes. Betterbird has been shipping this since September 2021. Good thing is, Ryan woke up to it, finally.

Another thing users want is a stable product without regressions, so what worked yesterday must continue to work today, maybe in a different way, unless a feature was removed on purpose (not by accident) after careful consideration. Thunderbird release strategy of sometimes not backporting available regression(!!) fixes to the current release version is detrimental to user satisfaction. Of course it would need active management of regressions (see third paragraph above) and a commitment to product quality. Most important example in recent months: Being able to permanently decrypt messages, a regression compared to TB 68 with Enigmail, much requested, will now ship in TB 102, so release users "only" had to wait two years for it.

On the other hand, Ryan has not yet recognised the major impediment that is holding Thunderbird back, and that is the Mozilla culture in its many facets. Here are just a few:

Mozilla platform code is considered the be-all and end-all, when in fact it is just an upstream project whose code Thunderbird could adapt to its own needs to its hearts content. Take the multi-line message list. The necessary changes to the Mozilla platform code weren't accepted by Mozilla, hence the feature was never implemented, despite patches which have existed for decades.

The counterproductive Mozilla contribution attitude: Say there was a regression and a contributor proposes a fix which is deemed suboptimal. In case the contributor for some reason doesn't pursue the issue further, the issue is now blocked and not fixed, sometimes for years, much to the detriment of the users. That's like the master plumber waiting for the apprentice to fix the leak while the building is flooded. There are so many bugs in the system which are blocked in this way :-( - This Mozilla contribution attitude is arrogant and doesn't constitute good teamwork. In any well working team, people who are struggling would receive help from their managers since in the end, everyone should contribute their share so the problem gets fixed for the customer.

Another Mozilla problem is "purity": For example, the issue of symbol fonts (Wingdings, Webdings) not being displayed properly in Firefox despite being displayed correctly in Chrome-based browsers went back to 2004 (bug 236854). This can be detrimental to mail composition of users don't realise that they are accidentally sending out symbols instead of text. When the issue was raised again in 2022 (bug 1756720), that bug was closed immediately referring back to the previous "purist" answer which was: An "A" should always be rendered as an "A", not as a symbol. And then, in this particular case, a miracle happened: Someone re-opened the latter bug and finally fixed it after 18 years. Well, users generally don't want to wait for miracles, they would instead prefer some decent product planning which tells them when their issue will be addressed.

In summary: I wish Ryan good luck fighting as a David against a Goliath of encrusted structures. Maybe he'll get there in ten years. More than two years have already been wasted (see third paragraph above).