Changes to review policy

Jim squibblyflabbetydoo at
Sat Apr 30 21:32:31 UTC 2016

Before I reply point-by-point, I'd like to underscore something that I
might not have made clearly enough in my original message: I'm *not*
proposing that we keep old code around just to satisfy
especially-conservative users. I'm only proposing that we improve our
process for changing *defaults*; that is, cases where we've already decided
we'll keep both ways around. While I think we should also think carefully
about removing features/behavior just because we don't see a use for them,
that's a separate issue, and one I don't have a good answer for at the

Per this thread, my current plan is to work on a set of guidelines for UX
reviewers in these cases so that we ask the appropriate questions before
release. Even if we don't satisfy all of the conditions in my original
message, I think we should be checking them and ensuring we have a good
reason if we violate one of them.

On Sat, Apr 30, 2016 at 2:34 PM, Jonathan Protzenko <
jonathan.protzenko at> wrote:

> 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.
I ran a poll among people who contribute to Thunderbird (or at least follow
closely enough to know about tb-planning) because I wanted to get a sense
for what people liked in terms of icon shape. The main reason I did this is
because opinion was split about 50/50 in the bug. That doesn't imply that
we'd do this for every change (or even 10% of changes). The only time I'd
see merit in a poll is when - like this case - several core TB developers
disagree on a minor issue (icon shape) and we're just going in circles.
Heck, we could probably have just flipped a coin.

> 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.
To be honest, if I really wanted to create a modern MUA, I'd just go work
on asuth's "glodastrophe" client. Having worked on its internals when it
was the Gaia Email client, it's miles ahead of Thunderbird in terms of

While it's hard to say anything about Thunderbird's userbase with certainty
(we don't have much data), I think it's safe to say that Thunderbird's
continued relevance is deeply tied to its legacy. We should recognize that
and work to preserve a continuity of user experience (within reason). We
might be able to improve on it in some ways, but I think attempting to
modernize Thunderbird is a distraction from more important tasks[1]. We
don't have a lot of resources, and I would much rather see us using the
resources we have to polish *existing* parts of Thunderbird. There are tons
of half-finished bits sitting around, and I think we overprioritize new
features compared to finishing the ones we already started. Gloda is a
great example of this: overall, I think Gloda is pretty great, but there
are still - almost 6 1/2 years after its initial release - significant gaps
in it.

> - 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.
As already mentioned in this thread, the number of people complaining isn't
especially important to me, since it's practically impossible to figure out
how many people are happy or not. I care a lot more about the *content* of
users' complaints, and in this case, those complaints made it clear to me
that we failed to understand all the implications of our upgrade code. This
is what I'm trying to solve.

> - 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.
No, I'm not. We never even *proposed* removing the From/Recipients column
when we added the Correspondents column. If anything increased the
complexity of Thunderbird, it was the automatic upgrade code. As mentioned
above, I'm not proposing that we keep around literally every old feature in
Thunderbird; you may recall that I argue harder than most to *remove*
obsolete parts of Thunderbird. But if we're already keeping around the old
feature and only changing the default, as we did in this case, we owe it to
users to ensure that we change their defaults with care.

While you might argue that we needed the upgrade code in order to make it
worth landing Correspondents, that's making an assumption that we know
enough about our userbase to say that the majority would prefer
Correspondents to From/Recipients. To be rather blunt, we don't know a damn
thing about how the average user uses Thunderbird. To my knowledge, we've
never actually studied that. Years ago, I ported Test Pilot to Thunderbird
so that we *could* learn what our users like. I think we made one study
that was never actually completed before the project petered out.

> - 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.
I don't agree. There are a great many things that contributors can work on
that aren't particularly controversial, and even in cases where a change
might be controversial, it's the job of the core Thunderbird team
(submodule owners, UX peers, etc) to manage the politics and make
(hopefully!) intelligent decisions about how to change Thunderbird. A new
contributor should feel that the core

- Jim

[1] "Modernize" is vague enough that almost anything we do could be called
"modernizing", but here I specifically mean working on new UX features (as
opposed to architectural cleanup, finishing existing features, etc).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the tb-planning mailing list