Changes to review policy

Axel Grude axel.grude at gmail.com
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 
<https://www.youtube.com/c/thunderbirddaily> on it.

https://bugzilla.mozilla.org/show_bug.cgi?id=1152706#c5

> 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.

regards,
   Axel


> *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 gmail.com>*
> 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
>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1152706>  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 mozilla.org
>> https://mail.mozilla.org/listinfo/tb-planning
>>
>
>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20160428/016854aa/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 846 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20160428/016854aa/attachment.png>


More information about the tb-planning mailing list