Papercuts remixed - the bug list

Axel axel.grude at
Fri Jul 13 16:07:04 UTC 2012

(CC'ing JBP + Kent here as my Emails go through moderation, no idea why)

Kent James*wrote on *Friday, 13/07/12 14:19:03 14:19 GMT Daylight Time +0100
> On 7/13/2012 3:57 AM, Wayne Mery (d531) wrote:
>> I admire everyone's enthusiasm but I think we are blazing ahead too quickly, 
>> announcing a process and potentially blogging already only a couple days after 
>> discussion started.
> Right now, we are partly battling time. The Thunderbird brand was enormously damaged 
> by the announcement of last Friday (dare I say botched announcement?) that has been 
> interpreted much more negatively than I think was intended. Now we have a small 
> window of time where people are watching Thunderbird a little more closely than 
> usual. It is really critical that a positive statement is given in that window of 
> time, and that statement needs to show hope that there actually is a community 
> effort that will back up Thunderbird.

as regards instead of announcing decisions, why not just publicise the fact that there 
is a group of people actively working on the innovation road map, and (maybe) 
encourage participation. Of course I wouldn't know whether publicising Tb-Planning 
toeverybody would be a good move, but some form of publicising has to be done so the 
public at least knows this isn't stagnant.
> With Andreas and atuljangra also signing up, we now have 8 developers who have 
> committed to investing in the Thunderbird project over the next year. It would be 
> good to get that message out, and my target is Sunday night.
> I agree that the rest of the process is not well defined at the moment, and perhaps 
> you are correct that I should be cautious about talking about the specifics of a 
> process that is still in development.
there are some enhancements that are long overdue, so restriction to just [["minor"]] 
fixes would definitely be a mistake. I would be happier if we could land one or two 
power features aimed at power or corporate users, that directly compete with features 
from other mail clients (such as a filter wizard, or an improved HTML composer).
> But there is a second part of this that I'd also like to talk about about, and it is 
> a little more delicate. Part of what is going on with the TB changes is that Mozilla 
> is emphasizing stability over innovation with Thunderbird. That is actually good 
> news for a large part of the Thunderbird user base. The last thing many users want 
> is constant, unnecessary churn in the user interface. (My own pet peeve: removing 
> the folder class selection from the folder pane, forcing someone to write an 
> extension to put it back which is now very popular).
<pet peeve alarm> It is "One of those" changes falling under the umbrella of 
"simplification" that can be discussed for a long time (and I was opposed to this as 
well). Simplification of something that might be inherently "not simple" or 
"simplification for simplicity's sake" is something that I hope will fall by the 
wayside with the new innovation model - or at least critically discussed. There are 
quite a few people in design teams that mistake simple with ergonomic, which is not 
always the same. I feel this definitely needs further discussion before any major UI 
decisions (e.g. calendar in window / Compose in Tab) are made.

Without going into detail, I just want to remind everybody of Firefox's controversial 
"Tabs on Top" decision (which actually makes more sense in Tb) ..., imho it was a 
hastily implemented feature and not very well researched; let's avoid this trap with 
Thunderbird and focus on the burning issues.

</pet peeves end>

> I would like to find some positive ways to engage those people. And emphasizing that 
> we are going to be taking more concrete steps than in the past to try to listen to 
> their needs, and respond to them, is a Good News story.
It also depends on your target audience - is it mainly developers who read your blog, 
or your Add-On users? A link would be nice.
> But this is delicate because it is partly critical of what Mozilla has done in the 
> past - or could easily be interpreted that way. It is also extolling the glories of 
> slower release cycles at a time when Mozilla is already working to respond to recent 
> criticism of rapid release (the "Firefox Update Discussion" email). I'm aware of 
> these sensitivities and want to be careful - but I think that subtle criticism is 
> acceptable and even desirable.
I think the "rapid release cycle topic" is not something to be emphasized so much, 
after all before that we did have irregular security updates; so this is really just 
an internal process, and ultimately discussing it diverts attention from innovation 
and productivity, which I find much more important from the users point of view. How 
often one releases isn't something that should be even portrayed as internally 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the tb-planning mailing list