Changes to review policy
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.
> 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
> *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.
> *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
>> *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, 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
>>  Full disclosure: this is based solely on inspection, not actually
>> running the code.
>> tb-planning mailing list
>> tb-planning at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 846 bytes
Desc: not available
More information about the tb-planning