Changes to review policy

Axel Grude axel.grude at
Thu Apr 28 08:52:10 UTC 2016

PS: If somebody can provide a condensed version of the Pros & Cons of the 
correspondence column I could make a YouTube video on Thunderbird Daily 
<> on it.

> I think implementing this new feature which people wanted for 15 years (!!) is great.
> On the other hand I don't think it's a good idea to "force" it upon people who've been working without it for 15 years.
I would like to know why people were wanting this feature for such a long time, and 
lay out the argument for it in my video.

I would also try to create & showcase a userChrome hack to replace the right arrow 
with a more obvious icon in order to make it more acceptable.


> *Subject:*Re: Changes to review policy
> *From:*Axel Grude
> *To:*Tb-planning
> *Sent: *Thursday, 28/04/2016 09:45:12 09:45 GMT ST +0100 [Week 17]
> Dear Jim,
> I think the general move to a correspondent column may be a good one, the problem is 
> that it is not very obvious which of the emails are by me (having the mere direction 
> of a light gray arrow pointing one way or another is actually very hard to parse at 
> a glance). I would therefore have liked a more obvious metaphor for "my personal 
> emails", which may have been easier to adopt; even if it was something simple like a 
> special hue for the arrow or a different icon. An extended UAT phase for fundamental 
> changes like this would be great; that would have to be separate from "finding" the 
> change in a bug.
> Would it be possible to recruit some people for voluntary UAT - this means a more 
> focused effort than just relying on beta users to report. It would mean working with 
> the new features for a period of time (e.g. 2 weeks) within test cases created by 
> the patch author and then gathering the results and reporting them back to the patch 
> owner; either directly or via Bugzilla comment. Also a link to a compiled UAT build 
> would have to be available.
> I would volunteer for being a UAT tester, if it wouldn't include code review or 
> having to compile my own version.
> thanks
>   Axel
> -- 
> *Axel Grude <mailto:axel.grude at>*
> Software Developer
> Thunderbird Add-ons Developer (QuickFolders, quickFilters, QuickPasswords, Zombie 
> Keys, SmartTemplate4)
> AMO Editor Get Thunderbird!
>> *Subject:*Changes to review policy
>> *From:*Jim Porter
>> *To:*Tb-planning
>> *Sent: *Thursday, 28/04/2016 06:33:52 06:33 GMT ST +0100 [Week 17]
>> 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
>> importance:
>> 1) No data/program state should be lost.
>> 2) Before changing a default, we should be sure the new default is
>>     fully-operational.
>> 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.
>> Thoughts?
>> - Jim
>> [1] Full disclosure: this is based solely on inspection, not actually
>> running the code.
>> _______________________________________________
>> tb-planning mailing list
>> tb-planning at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 846 bytes
Desc: not available
URL: <>

More information about the tb-planning mailing list