Changes to review policy

Jim Porter squibblyflabbetydoo at
Thu Apr 28 05:33:52 UTC 2016

Given the user outcry around the upgrade from the From/Recipients column
to the Correspondents column (see
<> for example), I'd
like to propose some new guidelines to our review policy to prevent this
from happening again. To be rather blunt, I don't think we're upholding
the minimum standards of quality that people should be able to expect
from us.

It's an especially stark contrast when you compare the Correspondents
column issue to another change in 45.0: the new default in composition
to create new <p> elements every time you hit enter. A number of people
have also been dissatisfied with the latter, but the fix for that is to
uncheck a single checkbox.

Undoing the Correspondents column upgrade, on the other hand, involves
setting a hidden pref and then fixing all the folders that were
"upgraded". Worse, we can't automatically roll the column state back
because we've actually destroyed data! If a user had *both* the From and
Recipient columns shown, the upgrade code hides them[1], and there's no
way I know of to look at the current state to determine this.

Therefore, I'd like to propose the following: any change to
Thunderbird's defaults should have a super-review before landing.
Super-reviewers would be especially focused on making sure that changes
meet most or all the following conditions, in descending order of

1) No data/program state should be lost.

2) Before changing a default, we should be sure the new default is

3) Users should have an easy path to roll back to the previous UI/UX if
   they don't like the new version. If possible, ask the user *before*
   upgrading them.

4) It should be easy for users to find out what's changed, along with
   instructions for how to adjust the new behavior to their liking.

Of course, I understand the desire to ship new features, especially if
we think they're better than the old ones, but we need to be very
careful. Email is mission-critical for many people, and as such, we have
a responsibility not to break things. Hopefully with a few more eyes on
changes like this, we can come up with ways to satisfy existing users'
needs while still working to modernize Thunderbird.


- Jim

[1] Full disclosure: this is based solely on inspection, not actually
running the code.

More information about the tb-planning mailing list