Changes to review policy

Mihovil Stanić mihovil at miho.im
Thu Apr 28 09:05:43 UTC 2016


Not really sure what's all fuss around correspondents column?

I receive about 15.000 emails a year on work email, handled by TB, and 
didn't notice anything different in TB behaviour except column isn't 
named "From", it's now "Correspondents".

I'm not using inbox for received and sent email, those are two different 
folders, so maybe that's why I don't have problems with it.

Mihovil


28.04.2016 u 07:33, Jim Porter je napisao/la:
> 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/11323d70/attachment.html>


More information about the tb-planning mailing list