<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 30/07/2012 20:58, Kent James wrote:<br>
</div>
<blockquote cite="mid:5016E76B.8030906@caspia.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<a moz-do-not-send="true"
href="https://bugzilla.mozilla.org/show_bug.cgi?id=487386"><b>Bug 487386</b></a>
<br>
<br>
That bug has everything permitted within Bugzilla to scream for
attention:<br>
<br>
[ux-papercut], [gs], [UXprio], 25 dups, 52 votes, major
importance, wanted-thunderbird, user whine with official "do not
whine in BMO" response, etc.<br>
</blockquote>
Yes, I'd agree it is a paper-cut bug.<br>
<blockquote cite="mid:5016E76B.8030906@caspia.com" type="cite"> Yet
unfortunately the answer to your question is "there are no plans
to address this bug".<br>
</blockquote>
Not quite true. We have discussed routes to improving Thunderbird
which would also result in fixing this issue. They aren't simple and
involve a big reworking of the way the main window UI works.<br>
<br>
The SeaMonkey <a
href="https://bugzilla.mozilla.org/show_bug.cgi?id=541876#c1">"ugly
proof of concept"</a> is an interesting work around, although I'd
be concerned that it could be fragile in itself. It also wouldn't
fix some of the other related issues of feed pages/messages being
reloading, text selection and focus.<br>
<br>
Now I think about it, I don't think I've actually written down the
direction I was originally thinking of going, so I'll do that and
post it separately, as it isn't just related to fixing that specific
bug.<br>
<br>
The fundamental problem is that currently all message display tabs
are using the same "messagepane" element (as well as other elements)
- there's various assumptions all through the UI code that it
exists, or that there's just one of them. This is also why we can't
close the main 3-pane tab at the moment.<br>
<br>
To fix that is quite a lot of work, but I'll let you see that from
the route I was proposing when I post it.<br>
<br>
<blockquote cite="mid:5016E76B.8030906@caspia.com" type="cite">
Personally I think this is a travesty, and it is bugs like that
that get me motivated to improve our general qc process. Looking
at the papercuts list, I nominated it as a bug, but only got one
supporter for that, so it did not make the official first list.
What we really need is a group process <b><i>that we actually use
to choose bugs to work on</i></b> where important stakeholds
in Thunderbird have the opportunity to influence which problems
get addressed.<br>
</blockquote>
There's an important additional factor - the amount of work a
papercut requires to fix. Whilst you can say it is important, if it
will take a year of someone's work to fix, then maybe it isn't such
a good choice, unless you are getting lots of user complaints (afaik
we're generally just seeing them in bugzilla for this bug, and not
on gs, but I've not looked myself).<br>
<br>
The group process is much more interesting, and we should use the
change of release & governance discussions to work out what we
want there. Obviously we can't get everyone to work on just the bugs
we want, but exploring that group process is something I'd like to
see.<br>
<br>
<blockquote cite="mid:5016E76B.8030906@caspia.com" type="cite">
There are existing processes in both BMO and gs that attempt to do
this. I don't really understand why those processes are not used
in a more effective way to influence development. People have
followed our process, this bug is easily a top 5 bug we should be
looking at, yet we don't.<br>
</blockquote>
It is always a balance of the bugs/features/time/visibility. In this
case, I'd say that time to fix has been outweighing the others, and
whilst it is visible to the users, it doesn't seem to cause the
level of complaints that other bugs do.<br>
<br>
Mark.<br>
</body>
</html>