Changes to review policy

Jim Porter squibblyflabbetydoo at gmail.com
Thu Apr 28 17:52:16 UTC 2016


On 04/28/2016 05:36 AM, Florian Quèze wrote:
> Always keeping the previous behavior around when implementing something
> new increases significantly code complexity, and results in maintenance
> hell.

In this case, however, we kept the old implementation around anyway, so
there's no extra maintenance burden. To be clear, I'm *not* suggesting
that we can only make changes if the user can opt out. I'm only
suggesting (in this point) that a super-reviewer validate whether we've
done the best we can at allowing opt-out if it's feasible.

> Also, asking users for each single thing is rarely a sign of good UX, it
> rather shows that the UX wasn't thought through and users need to take
> care of figuring it out on their own instead of trusting the designer.

I still stand by my original argument that this UI should have defaulted
to enabled, but I think we can do a better job of providing users with
an easy way of opting out. In the old days, we had a migration wizard
that let us ask users what they want us to do on their behalf, e.g.
whether to set all IMAP folders to download messages for offline
reading. It might be a good idea to resurrect the migration wizard.

> Remember that people are way more vocal when they are frustrated than
> when they are happy. Given the size of the Thunderbird user base, any UI
> change is guaranteed to frustrate at least some users. This isn't a good
> reason to stop making changes.

That's why I contrasted this case with another controversial change in
TB 45: the change to creating a new <p> element when hitting enter in
the HTML composer. A fair number of people are annoyed at this too, but
the process for opting out is very simple (uncheck a single box), and
there's no loss of information. I think we handled that change
correctly, and I have no problem accepting that some people are grumpy
about that change.

The Correspondents upgrade, however, is hard to opt out of and can lose
information in some cases. If we had designed things so that there was
an easy way to say "no thanks", I'd stand by it too.

> To be honest, given the current state of the tree, I don't think we need
> more processes, but rather more people taking care of blocking issues
> (eg. fixing the bustages).

I'd removed it from my initial draft, but I had originally planned on
mentioning that we should be prioritizing bugfixes and completing
unfinished features, since these tasks stand a better chance of helping
our userbase.

- Jim



More information about the tb-planning mailing list