Changes to review policy

Jonathan Protzenko jonathan.protzenko at gmail.com
Sat Apr 30 19:34:53 UTC 2016


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.

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.

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

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

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

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

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.

~ jonathan

On 04/27/2016 10:33 PM, Jim Porter wrote:
> 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/20160430/a59cb849/attachment-0001.html>


More information about the tb-planning mailing list