Splitting up "Mail Window Front End" bugzilla component
Dan Mosedale
that we keep components small enough that they don't require more than
one person to keep on top of them.
As it stands, the Mail Window Front End component of Thunderbird is far
too large for that, so we're losing the benefit of having individual
pieces localized to a single driver's brain.
So we need to split it up. One possible taxonomy would be:
Folder List
Message List
Message Reader Pane
Mail Windows
Ideally, each of these buckets would be small enough to be manageable by
one person, but large enough that it actually is worth having a separate
component for. It's not really clear to me whether the list above meets
that criterion, so I'd like more input from folks (eg Wayne, Gary, Phil)
who spend more time triaging than I do. What say you guys? Is that a
good split? If not, what do you think is likely to work better?
Dan
Ben Bucksch
> As it stands, the Mail Window Front End component of Thunderbird is
> far too large for that
Agreed. It's too large in general - the contains most of the Thunderbird UI.
> So we need to split it up. One possible taxonomy would be:
> Folder List
> Message List
> Message Reader Pane
> Mail Windows
Message Reader Pane: should include standalone msg viewer. If you call
it just "Message Reader", it runs the risk of catching libmime bugs.
Maybe "Message Reader UI"?
What is "Mail Windows"? Did you mean that to be the standalone msg
viewer? I think it should be combined with the msg reader pane in 3pane,
because it's partially the same code, no?
We need a "other main window" component which catches all bugs which fit
in neither of the above. Or did you mean to keep the current component?
Ron K.
> Dan Mosedale wrote:
>
>> Since we're now driving Thunderbird 3 bugs by components, it's important
>> that we keep components small enough that they don't require more than
>> one person to keep on top of them.
>>
>> As it stands, the Mail Window Front End component of Thunderbird is far
>> too large for that, so we're losing the benefit of having individual
>> pieces localized to a single driver's brain.
>>
>> So we need to split it up. One possible taxonomy would be:
>>
>> Folder List
>> Message List
>> Message Reader Pane
>> Mail Windows
>
>
> Menus
> Tabbed Mail
> Toolbar
>
> thereby mimicking the structure of the Firefox product in some aspects.
>
> Simon Paquet
Adding the Tab UI seems reasionable. The menues and the Tool bar are both
elements of an XUL Tool box and sensible are collectively "Control Tools".
--
Ron K.
Who is General Failure, and why is he searching my HDD?
Kernel Restore reported Major Error used BSOD to msg the enemy!
Wayne Mery
MWFE is definitely too big (obscene?) - definitely in terms bugs, I
don't know code-wise. Thinking in terms of functionality I come up with
almost the same list.
Message reader/Message view is a no-brainer pull out, and should include
standalone window as others have said. (guesstimate 1/15 of MWFE bugs,
maybe less)
Tabs is a logical unit, but exceedingly small - unless we see tabs
coming up in a big way in places other than 3-pane I don't see it
becoming standalone unit. Tabs and Toolbar might be a good mix. Don't
have a great name for the combo - UI Tools? Do we own much toolbar code?
Folder and message list feel like they should be together, but maybe
that's just because I'm a heavy drag and drop guy. Since Folder and
message pane are diverging in terms of presentation model, and bearing
in mind the needs of extensions, folder pane might be good on its own.
But from a triage POV, no matter what you do, this entire area will
still be challenging - though strong(er) definitions of each component
may help some.
To give you a sense of scale, open bugs counts (of which 1/3 are ENH)
for largest components:
1,800 MWFE (many of these are backend issues*)
1,300 General (many of these are MWFE issues)
1,200 Composition (TB+backend combined)
600 Backend
400 Address book
nothing else breaks 300
* ~1/7 are search and view bugs, which should probably be in search
Notes:
- Search is 64 bugs, seems ridiculously low
- Help, at 10, is a blip
Gary Kwong
that MWFE is another dumping ground besides General. After reading
others' thoughts,
Folder/message list
Menus
Toolbar and Tabs
Message reader UI
is what I'm probably siding with. Again, the exact wording to be agreed
on should probably be what users think they would be, which is why I
grouped Toolbar and Tabs together. I'm fine with the namings being
changed either way so long as these parts are covered. Tabs might
overlap with message reader UI but I can't think of any better phrase now.
Also, are these 4 new components an addition to MWFE, or a replacement
for it?
-nth10sd
Gary
Gary Kwong
> - Search is 64 bugs, seems ridiculously low
> - Help, at 10, is a blip
Search -- merge with gloda or something?
Help -- anything to do with SUMO for TB?
-nth10sd
Dan Mosedale
> On 30.01.2009 22:20, Dan Mosedale wrote:
>> On 1/30/09 11:44 AM, Wayne Mery wrote:
>>>> Message Reader UI
>>>
>>> will this include display of message body?
>>
>> Yes.
>
> Actually, message body is libmime, which has its own component: Mailnews
> Core / MIME.
While the emitting code does happen to live in libmime, and perhaps some
of the Message Reader UI bugs that get filed will end up over in
Mailnews Core / MIME, I think this is really conceptually part of the
UI, and it makes as much or more sense to triage it with the rest of the
UI bugs.
Dan
Dan Mosedale
> Dan Mosedale on 1/30/2009 4:20 PM, keyboarded a reply:
>> On 1/30/09 11:44 AM, Wayne Mery wrote:
>>>> Message Reader UI
>>>
>>> will this include display of message body?
>>
>> Yes.
>>
>
>
> My only nit is toolbar should be plural as there are bars in several
> components
Address book window toolbar bugs seem likely to be filed under Address
Book, and compose window toolbar bugs will end up in Message Compose
Window. Are there other toolbars (besides 3-pane and message-window)
that I'm forgetting?
> and with an extension custom bars can be added the way that
> Fx does them.
Right, but the number of bugs that generically effect custom toolbars
but not of the three bundled ones is likely to be vanishingly small.
My thinking is that we really do want this just to be about the message
window & 3 pane window toolbars, which are almost (but not entirely)
identical. Bryan, any thoughts here?
Dan
Phil Ringnalda
> Folder and Message Lists
> Toolbar and Tabs
> Message Reader UI
> Miscellaneous UI/MWFE
The one that seems most-missing from that list, and most likely to be
generally useful as a component, is Theme: the whole of Moz has always
sucked at prioritizing theme bugs when they are mixed in with *real*
bugs, and far more than any of those others, someone interested in
watching th...@thunderbird.bugs is likely to be uninterested in watching
the others, which in cases where you aren't just trying to split one big
bucket into four is my primary measure of "does this make sense as a
component?"
Bryan Clark
> My thinking is that we really do want this just to be about the message
> window & 3 pane window toolbars, which are almost (but not entirely)
> identical. Bryan, any thoughts here?
Agreed.
Just some general thoughts about this process... Bugzilla, because of
the way it works forces us to need to strike the balance between what
users would understand and what components are actually under the hood.
This also means we can't have too many components. The extremely fine
breakdown provides developers better categories to understand bugs but
makes it much harder for people reporting to know what component is
correct. And since a component is required to file a bug it's better
that we have a limited number with some large, obvious ones to choose.
Having somewhat general components like Mail Front End and Mail
Sending/Receiving be the "catch all" for people reporting as well as
components for smallish technical items seems like a good balance.
All that said, I think we have a good list so far for the breakdown
already. I talked myself into and out of a themes component several
times. On one hand it seems like bugs filed under themes will almost
always be filed wrong. On the other hand we're working on themes much
more now than ever before so it would at least help to have that
component for us to track our work separately. Plus we increased the
number of themes from 2 to 3, a large statistical increase. Likely the
themes component would be a good addition.
Cheers,
~ Bryan
Ron K.
> On 02/02/2009 04:29 PM, Dan Mosedale wrote:
>> My thinking is that we really do want this just to be about the message
>> window & 3 pane window toolbars, which are almost (but not entirely)
>> identical. Bryan, any thoughts here?
>
> Agreed.
>
> Just some general thoughts about this process... Bugzilla, because of
> the way it works forces us to need to strike the balance between what
> users would understand and what components are actually under the hood.
>
> This also means we can't have too many components. The extremely fine
> breakdown provides developers better categories to understand bugs but
> makes it much harder for people reporting to know what component is
> correct. And since a component is required to file a bug it's better
> that we have a limited number with some large, obvious ones to choose.
>
> Having somewhat general components like Mail Front End and Mail
> Sending/Receiving be the "catch all" for people reporting as well as
> components for smallish technical items seems like a good balance.
>
Since Bugs have a default CC list, is Wayne Mery in that list? The
advantage is QA can white board/keyword a new bug to fine grain a component
when the Bugzilla classification is too general.
Dan Mosedale
> On 02/02/2009 04:29 PM, Dan Mosedale wrote:
>> My thinking is that we really do want this just to be about the message
>> window & 3 pane window toolbars, which are almost (but not entirely)
>> identical. Bryan, any thoughts here?
>
> already.
OK, I just filed bug 476980 on creating these three new components:
Folder and Message Lists
Toolbar and Tabs
Message Reader UI
> I talked myself into and out of a themes component several
> times. On one hand it seems like bugs filed under themes will almost
> always be filed wrong. On the other hand we're working on themes much
> more now than ever before so it would at least help to have that
> component for us to track our work separately. Plus we increased the
> number of themes from 2 to 3, a large statistical increase. Likely the
> themes component would be a good addition.
There didn't seem to be much consensus among the (small number of) folks
I talked to that Themes would really attract that many bugs. For that
reason, and because:
* it's harder to get rid of components than to create them
* unlike the other three components, it's not addressing an immediate
problem
* having less choice is generally better UI
I've held off on the Themes component. If you or Phil or someone else
decide that you feel strongly about it (either now or in the future),
feel free to drive that forward.
Dan
Dan Mosedale
>
> Since Bugs have a default CC list, is Wayne Mery in that list? The
> advantage is QA can white board/keyword a new bug to fine grain a
> component when the Bugzilla classification is too general.
The way that we've done this traditionally is to have people who are
interested watch the default QA contact which is a bogus email address
(eg message...@thunderbird.bugs). I've filed the component creation
bug to use that strategy. If Wayne or other QA folks decide in the
future that they want to change how they do that, great, but for now I
think the existing way is good enough that we shouldn't block on making
the perfect decision here.
Dan
Bryan Clark
> a thought about pane vs. list ... is "pane" more common than list, in
> bugs and documentation (wiki, kb, etc)? My sense is "list" is more
> common around those who deal with the code, but pane is more well known
> to users.
Meant to chime in on this part as well... with nothing of true
substance, of course. If I were to guess, the greatest majority of
users wouldn't have one or the other in mind. I think you were aiming
toward that point as well.
If I were creating a bugzilla interface of my own I would allow
developers to take screenshots of the app and then let users click the
area where the problem was. Anyway... that's about the level of
understanding of the application components that I'd want to assume the
user has. If we were diagnosing a car we shouldn't need the driver to
tell us the noise is coming from the manifold, just the kind of sound it
makes and when it makes the sound. Every answer can only be expected in
terms the person understands or not at all.
So my recommendation would be that list is probably fine and pane is
probably ok as well. The thing that has folders or messages is more
likely what people will key in on. Good to see these filed!
Cheers,
~ Bryan
David Ascher
> On 02/02/2009 04:29 PM, Dan Mosedale wrote:
>> My thinking is that we really do want this just to be about the message
>> window & 3 pane window toolbars, which are almost (but not entirely)
>> identical. Bryan, any thoughts here?
>
> Agreed.
>
> Just some general thoughts about this process... Bugzilla, because of
> the way it works forces us to need to strike the balance between what
> users would understand and what components are actually under the hood.
In some alternate reality where bugzilla were more agile, we could have
user-facing buckets and developer-facing buckets. Bugs would get filed
in one, and then assigned to the other (while retaining the user-facing
classification). Given that we triage bugs anyway, it doesn't seem like
having two different taxonomies would be that problematic. I'm sure
there are reasons, but...
--david
Wayne Mery
> On 01/30/2009 11:44 AM, Wayne Mery wrote:
>> a thought about pane vs. list ... is "pane" more common than list, in
>> bugs and documentation (wiki, kb, etc)? My sense is "list" is more
>> common around those who deal with the code, but pane is more well known
>> to users.
>
> Meant to chime in on this part as well... with nothing of true
> substance, of course. If I were to guess, the greatest majority of users
> wouldn't have one or the other in mind. I think you were aiming toward
> that point as well.
>
> If I were creating a bugzilla interface of my own I would allow
> developers to take screenshots of the app and then let users click the
> area where the problem was.
BINGO!
A UI screenshot with mouseover information would also help users file
bugs with more correct and more precise terminology. This is what
guided bug entry should have for Thunderbird (among other things).
David Ascher
Note that it shouldn't be too hard to make a webapp that provided this
front-end, and resulted in bug submission via the regular bugzilla web
page.
--david
David Ascher
This (as a webapp frontend to bugzilla) feels like a great summer of
code project, actually. Anyone care to write it up?
-david
Tony Mechelynck
Of course it wouldn't help the users (and from what I've seen, I believe
there are a huge lot of them) who file bugs into Thunderbird => General
because they don't realize they belong in MailNews Core -- but, also of
course, this is not what this thread is about.
Best regards,
Tony.
--
Laetrile is the pits