[Maildev] Engineering Council or Engineering Steering Committee (ESC) - where art thou?

Mark Rousell mark.rousell at signal100.com
Fri Aug 31 12:45:19 EDT 2018

On 31/08/2018 16:21, Jörg Knobloch wrote:
> On 31/08/2018 16:30, Mark Rousell wrote:
>> A question to everyone here: Is there a strategic roadmap anywhere?
>> I'm very sorry if I haven't noticed one! Please do tell me where it
>> is. Or are things that contribute to or reflect what should be
>> strategy still being decided on an ad hoc issue by issue basis by
>> those who are in de facto control of implementation?
> I'm not aware of one. For the hotly contested add-ons issue for example,
> this is all we've come up with so far:
> https://wiki.mozilla.org/Thunderbird/Add-ons_Guide_63

Ah yes. Well, that's much better information than nothing of course and
it's a good thing that the current knowledge is documented somewhere.

But of course I think it also highlights the lack of a firm overall
roadmap. So much is dependent on what the Firefox project does that it
makes it difficult for Thunderbird to develop a firm, consistent
roadmap, not just on extensions but on anything. (But this is a
different problem again to the ones under discussion here).

> But we hired Magnus as a technical manager
> (https://mail.mozilla.org/pipermail/tb-planning/2018-August/006127.html),
> so we can look forward to some planning now.

Oh yes, indeed. Well in that case it could be argued that Magnus is
fulfilling his role by taking the position that he is on this issue...
except that the lack of agreed and documented strategic direction means
that his decisions could be seen as simply reflecting his preferences
rather than the preferences of the project as a whole.

> As for the colour issue, the current suggestion looks like this:
> https://bug690644.bmoattachments.org/attachment.cgi?id=9003086
> I think adding tooltips explaining the dangers is a good idea.

I like the screenshot in the context of the main program preferences
area. It makes sense.

I just have two caveats:
(1) Use of the phrase "non-default" always causes me to ask: "Hang on,
what are the defaults? It doesn't say. But I don't want to lose my
current settings by clicking Restore Defaults just to find out." And so
rather than using "non-default", might I suggest that the warning text
is something like this: "Warning: Removing the tick from 'Use reader's
default colors' may cause incorrect message display when viewed by the

(2) The use of "recipient" and "reader" to refer to essentially the same
entity is I think inconsistent. Furthermore, the word "reader" is often
used to refer to particular software or parts of software and so I don't
think it is necessarily clear that "reader" refers to the recipient's
mail client in this context. For this reason I suggest changing "Use
reader's default colors" to "Use the recipient's default colors" or even
"Do not set colors (allow recipient to view using their own color scheme)".

And two comments about context:
(1) If this is the look for the main program preferences area then it
does of course need to be matched by the UI in the compose window. I.e.
When 'Use reader's default colours' option is selected, the per-message
colour picker in the compose window needs to be disabled (not removed!)
and the user needs to be told why this is (as per items (i) and (j) in
my previous message).

(2) Ideally in my opinion there would be a per-message option in the
compose window to enable/disable setting text and background colours
(using similar language to whatever is decided for the program
preferences area under discussion here) but as I mentioned in item (h)
before I think it can be on a menu or in a dialog by default rather than
being immediately exposed on a toolbar.

( I'll add a comment on Bugzilla with these comments. )

> The UI
> for the "per message" setting is rather poor (compose window, Format >
> Page Colors and Background)

It is a bit unobvious, isn't it, but making it more obvious is perhaps
part of a wider issue with discoverability and editing workflow in the
compose window (especially in HTML mode). I don't think I'm saying
anything radical when I say that the compose window could do with some
serious updating, especially the HTML editor.

And wouldn't a Markdown editor be nice. I rather suspect that Markdown
is going to become popular as a native email format (maybe).

But, again, these particular issues are probably out of scope for the
particular issue at hand here.

> and there isn't an option to make the
> individual setting global, which is also a good idea.

I agree.

I just want to add that I realise that I am sticking my oar in as a user
whilst not offering direct coding contributions. I feel guilty about
that but, for the time being, I'm not in a position to offer more.
Nevertheless, I hope that what I can contribute has some value.

Mark Rousell

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thunderbird.net/pipermail/maildev_lists.thunderbird.net/attachments/20180831/a2035c20/attachment.html>

More information about the Maildev mailing list