- From: Jörg Knobloch <firstname.lastname@example.org>
- To: email@example.com
- Cc: Ryan Sipes <firstname.lastname@example.org>
- Subject: [tb-project-discuss] Some comments on Ryan's post "Update from Thunderbird Product Manager"
- Date: Wed, 4 May 2022 10:33:18 +0200
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
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
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).