Papercuts remixed - the bug list
axel.grude at googlemail.com
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...
More information about the tb-planning