<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p>I'm extremely confused by this proposal. What other piece of
      software runs a poll when there is a proposed change? Does Gmail
      run a survey everytime they change their UI? No. Is Gmail
      "mission-critical" for many people? Oh, yes.<br>
    </p>
    <p>If you're trying to modernize Thunderbird, then this is not going
      to help. What you're proposing is basically that everything be set
      in stone, and that we cater to an audience of users who want their
      email client to remain exactly the way it was in 1994.<br>
    </p>
    <p>- People who are upset are people most likely to navigate the
      communication channels of Thunderbird, find out about this mailing
      list and figure out how to make their voice heard on every single
      possible bug in Bugzilla. I claim that the feedback you're hearing
      about the Correspondents change is not representative of the
      general userbase.<br>
    </p>
    <p>- Who's going to test the 2ⁿ combinations of options? Options
      have a cost. You're increasing the technical debt and complexity
      of the software because a handful of people have been very vocal
      on Bugzilla.</p>
    <p>- You're deterring potential contributors, because in addition to
      the technical burden of making things opt-out, now contributors
      will have to manage politics and make sure they don't end up
      starting a flame war because they changed some people's habits.<br>
    </p>
    <p>- It's debatable whether design by committee is good or not; but
      "design by democracy" is even worse. Please, don't send out a poll
      every time we need to change the user interface. You're sampling
      hardcore, opinionated users who lurk on this mailing-list.<br>
    </p>
    <p>It's easy to get emotional, but a few heated discussions on
      Bugzilla are not a good indicator of what the general direction of
      Thunderbird should be.<br>
    </p>
    <pre class="moz-signature" cols="72">~ jonathan</pre>
    <div class="moz-cite-prefix">On 04/27/2016 10:33 PM, Jim Porter
      wrote:<br>
    </div>
    <blockquote
      cite="mid:d56a7633-10d9-6151-1ba0-19c39a9886de@gmail.com"
      type="cite">
      <pre wrap="">Given the user outcry around the upgrade from the From/Recipients column
to the Correspondents column (see
<a class="moz-txt-link-rfc2396E" href="https://bugzilla.mozilla.org/show_bug.cgi?id=1152706"><https://bugzilla.mozilla.org/show_bug.cgi?id=1152706></a> 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
<a class="moz-txt-link-abbreviated" href="mailto:tb-planning@mozilla.org">tb-planning@mozilla.org</a>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/tb-planning">https://mail.mozilla.org/listinfo/tb-planning</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>