Changes to Bugzilla components for Fennec Native?

[Matt Brubeck]

The "Fennec Native" product in Bugzilla is divided into four components:

Evangelism
General
IME
Web Apps

I'd like to rename "IME" to "Keyboards and IME" to make it easier for
submitters to find and understand.

I also want to add some new ones, so contributors can deal with our
increasing bug traffic by watching more specific components. Components
are most useful for this purpose if they correspond roughly to areas of
code ownership.

Here are my suggestions. I want to cover our largest code modules, but
not make the list overwhelming for bug submitters. (We will still have
"General" for areas without their own components.)

Accessibility (disability access)
Add-on manager
Add-on compatibility
Awesomescreen
Data providers (bookmark/history/password databases)
Developer tools (we don't have these yet but we will)
Downloads
Graphics, panning and zooming
Profile migration and import
Reader mode
Start page (about:home)
Search engines
Tabbed browsing
Text selection
Theme and visual design
Touch events

Some areas are not included because they fall under other Bugzilla
products (e.g. Font inflation, Sync). We've also talked about moving
more widget-level code to /widget/android and more graphics code to
/gfx, which both fall under other products.

Areas like "performance" that don't correspond to specific code modules
can be handled with keywords or whiteboard tags.

Any suggestions for changes, removals, additions? In particular, I'm
not sure what components would be most useful for the platform team...

[Gian-Carlo Pascutto]

On 27/06/2012 17:21, Matt Brubeck wrote:
> The "Fennec Native" product in Bugzilla is divided into four components:

For starters, can we rename the product to "Firefox for Android"?

I think that might be handier especially as the amount of users will
balloon now (at least we hope so).

> Profile migration and import
+export

--
GCP

[AaronMT]

On Wednesday, June 27, 2012 11:21:24 AM UTC-4, Matt Brubeck wrote:
> Downloads

> Start page (about:home)
> Search engines

> Text selection

Some of these are very basic, especially text-selection. Can't we continue to have a General which would suitable for 'everything else', considering areas like these?

[AaronMT]

On Wednesday, June 27, 2012 11:21:24 AM UTC-4, Matt Brubeck wrote:

> Some areas are not included because they fall under other Bugzilla
> products (e.g. Font inflation, Sync). We've also talked about moving
> more widget-level code to /widget/android and more graphics code to
> /gfx, which both fall under other products.

Re: Sync, although technically not a component of the front-end product, I would love to see Sync moved over. Would an outside contributor really know that Sync lies under Mozilla Services? If there's a Sync issue they're going to file it under the product of which they are using it and that is Firefox.

[Matt Brubeck]

On 06/27/2012 08:30 AM, AaronMT wrote:
>> Downloads
>> Start page (about:home)
>> Search engines
>> Text selection
>
> Some of these are very basic, especially text-selection. Can't we continue to have a General which would suitable for 'everything else', considering areas like these?

Yes, I said in my first message that we would continue to use "General"
as the default component for everything without a component of its own.

The components above may seem "basic" to a user, but they are useful
categories to developers because they correspond to specific modules in
the Fennec Native source code. The download manager code is
self-contained, for example, and it's useful for the people developing
and testing it to be notified of bugs.

See the Firefox component list, for comparison:
https://bugzilla.mozilla.org/describecomponents.cgi?product=Firefox

I'm certainly willing to cut out components like "Start page" that have
relatively few bugs filed, to keep the list small.

> Re: Sync, although technically not a component of the front-end product, I would love to see Sync moved over. Would an outside contributor really know that Sync lies under Mozilla Services? If there's a Sync issue they're going to file it under the product of which they are using it and that is Firefox.

I totally agree, but I will leave this decision to the Services
engineering and QA teams since it affects their workflow (and any
product-specific Bugzilla settings they use).

[Chris Peterson]

On 6/27/12 8:21 AM, Matt Brubeck wrote:
> I'd like to rename "IME" to "Keyboards and IME" to make it easier for
> submitters to find and understand.

"Keyboards and IME" sounds good to me.

Also, I agree with GCP that we should consider renaming "Fennec Native"
to "Firefox for Android". The name "Fennec" doesn't mean much to
non-Mozillians and the "Fennec"/"Fennec Native" distinction may be
confusing.


chris

[Marco Zehe]

Hi Matt,

On 6/27/2012 5:21 PM, Matt Brubeck wrote:
> Accessibility (disability access)

Thank you for considering accessibility!

Marco

[Mark Finkle]

On 06/27/2012 11:21 AM, Matt Brubeck wrote:

> I'd like to rename "IME" to "Keyboards and IME" to make it easier for
> submitters to find and understand.

This makes sense to me

> I also want to add some new ones, so contributors can deal with our
> increasing bug traffic by watching more specific components. Components
> are most useful for this purpose if they correspond roughly to areas of
> code ownership.
>
> Here are my suggestions. I want to cover our largest code modules, but
> not make the list overwhelming for bug submitters. (We will still have
> "General" for areas without their own components.)
>
> Accessibility (disability access)
> Add-on manager
> Add-on compatibility
> Awesomescreen
> Data providers (bookmark/history/password databases)
> Developer tools (we don't have these yet but we will)
> Downloads
> Graphics, panning and zooming
> Profile migration and import
> Reader mode
> Start page (about:home)
> Search engines
> Tabbed browsing
> Text selection
> Theme and visual design
> Touch events

I have not been a fan of the "lots of components" model. I feel it leads
to "where do I put this bug?" problems. Profile migration uses Data
providers, as does the Start page and Awesomebar. We are likely to end
up with lots of mis-filed bugs that would need to be triaged.

Having been in heavy triage for months, I don't know if more components
will positively impact day to day development. You cite "watching more
specific components" via Bugzilla as a good reason to add more
components, and this is probably true. But I don't know if that reason
outweighs the additional mental workload adding bugs to the right
component creates.

Sorry to be the stop energy here. I'd like to hear more possible reasons
to add components.

[Mark Finkle]

On 06/27/2012 11:26 AM, Gian-Carlo Pascutto wrote:

> For starters, can we rename the product to "Firefox for Android"?

Agreed

[Gervase Markham]

On 27/06/12 17:21, Matt Brubeck wrote:
> Here are my suggestions. I want to cover our largest code modules, but
> not make the list overwhelming for bug submitters. (We will still have
> "General" for areas without their own components.)

Quick note: Bugzilla standard is to use Initial Caps for component
names. Also, I assume the stuff in brackets is not going to be part of
the name used?

> Developer tools (we don't have these yet but we will)

Best to create a new component once you do, then? :-)

> Downloads
> Graphics, panning and zooming

Good to call our panning and zooming specifically.

> Profile migration and import
> Reader mode
> Start page (about:home)
> Search engines
> Tabbed browsing
> Text selection

"Selection"? People are more likely to look under S. Although given that
it's next to T, not so big an issue.

Gerv

[Axel Hecht]

What would you expect to go into search engines?

Axel

[Dave Townsend]

I'm generally of the opinion that more components are better than less.
True, bug filers are going to get it wrong but they'll get it wrong
regardless of how many components you have. If you have broad components
all you'll end up doing is copying developers on bugs that they need to
see, this is more difficult that moving them to the right component
since you have to remember all the developers involved. Perhaps easy for
you but not for everyone that might help out with this sort of triage.
And if you create an environment where you expect developers to watch
and triage their own components (at least in terms of moving to the
right area so the right people see it) then it spreads the triage
workload amongst many rather than requiring a small number of people to
do regular passes.

Wouldn't make any difference to passes for blocking status etc. I think.

[Matt Brubeck]

On 06/28/2012 03:30 AM, Axel Hecht wrote:
> What would you expect to go into search engines?

Installing and managing search plugins; displaying and using search
suggestions in the search/awesome bar. This should probably be removed
since it overlaps either with Add-on Manager or with Awesomescreen.

[Matt Brubeck]

On 06/28/2012 01:05 AM, Gervase Markham wrote:
> Quick note: Bugzilla standard is to use Initial Caps for component
> names. Also, I assume the stuff in brackets is not going to be part of
> the name used?

Thanks for the capitalization note. The stuff in brackets was just for
clarification in this thread. A somewhat longer explanation can go in
the "Component Description" field for any components we add.

> "Selection"? People are more likely to look under S.

Hmm, I'm not sure, since "Selection" seems a bit unclear to me
(selection of what?) and other alternatives like "Selecting Text" seem
awkward. Anyway, as you say, not a big deal if we keep the list
reasonably short.

[Matt Brubeck]

On 06/27/2012 10:21 PM, Mark Finkle wrote:
> I have not been a fan of the "lots of components" model. I feel it leads
> to "where do I put this bug?" problems. Profile migration uses Data
> providers, as does the Start page and Awesomebar. We are likely to end
> up with lots of mis-filed bugs that would need to be triaged.

My goal here is actually to reduce triage effort. My suggestion was
inspired by this Twitter exchange:
https://twitter.com/tko/status/217251695976132608

I used to watch the whole "Fennec" product, and often handled bugs
(sometimes even resolved them) before the triage group ever had to deal
with them. But like other developers such as Lucas, I can no longer
keep up with the growing traffic in the "Fennec Native" product and all
its front-end and platform code.

Since there are no useful sub-components for me to watch (almost all my
bugs are in "General"), this means I don't see bugs at all until after
QA or Triage manually CCs me. This seems like wasted manual work. If
some portion of bugs were filed in specific components that I had time
to watch, then I would once again offload some work from triage.

> Having been in heavy triage for months, I don't know if more components
> will positively impact day to day development. You cite "watching more
> specific components" via Bugzilla as a good reason to add more
> components, and this is probably true. But I don't know if that reason
> outweighs the additional mental workload adding bugs to the right
> component creates.

I definitely want to keep the list from getting too big for submitters
to scan. Based on everyone's feedback, my new list of requested
components is slightly smaller:

Accessibility
Add-on Manager
Add-on Compatibility
Awesomescreen
Data Providers (includes import/export)
Download Manager
Graphics, Panning and Zooming
Reader Mode
Tabbed Browsing
Text Selection
Theme and Visual Design

Submitters who don't see an obvious candidate in the list will still
choose the default "General", which is fine and is no change from the
current situation.

[Matt Brubeck]

On 06/28/2012 10:25 AM, Matt Brubeck wrote:
> My goal here is actually to reduce triage effort. My suggestion was
> inspired by this Twitter exchange:
> https://twitter.com/tko/status/217251695976132608

I meant to link to the reply:
https://twitter.com/lucasratmundo/status/217252691519352833

[Matt Brubeck]

I filed https://bugzilla.mozilla.org/show_bug.cgi?id=769731 to change
the product name.

I'd also like to request the new components sometime next week, if there
are no further objections or suggestions. Is the revised list of 11
components simple enough that it will not be a significant burden on bug
reporters?

[Matt Brubeck]

On 06/29/2012 11:21 AM, Matt Brubeck wrote:
>>> For starters, can we rename the product to "Firefox for Android"?
>> Agreed
>
> I filed https://bugzilla.mozilla.org/show_bug.cgi?id=769731 to change
> the product name.

The product name change is complete. The "Fennec Native" product in
Bugzilla has been renamed to "Firefox for Android".

[Matt Brubeck]

Based on feedback from this thread and elsewhere, I reduced the number
of components slightly, and filed this bug to add the new components to
Bugzilla:

https://bugzilla.mozilla.org/show_bug.cgi?id=771274