382544 - Initial "Component" choices for new Mozilla bug are impoverished

Status: RESOLVED INVALID

(bugzilla.mozilla.org :: Administration, task)

Description

[Kent Paul Dolan]

[This is a bug against bugzilla _as instantiated for
Mozilla_, not against "bugzilla in general", so I'm
not sure this is the correct place to report the
bug. Triage types please repost this if it is misplaced.]

The "Component" dropdown table for Mozilla bug
initial reports has very few entries, as seen at the
subject URL, and most of those not recognizable to
end users, so that "General" is probably the
overwhelmingly most used component, not a helpful
beginning for developers or the bug triage process.

Compare the "Component" dropdown table choices once
the bug is "in the system", say here:

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

and see instead a rich set of Component choices, most
of them much more recognizable to end users, from
which a better initial choice of component could be
made.

Granted, that doing so also gives naive bug
reporters more ways to get in trouble, please
consider replacing the initial sparse "Component"
table with the same larger set of choices as the
subsequent rich "Component" table, to help improve
the triage process speed and the possibility for
precision of initial component identification.

Thanks.

xanthian.

Comment 1

[Dave Miller [:justdave]]

Adding Gerv, since the complaint seems to be about the guided form and he owns that.

Comment 2

[Gervase Markham [:gerv]]

The list of components depends on the Product selected. The URL you quoted above:
https://bugzilla.mozilla.org/enter_bug.cgi?product=Mozilla%20Application%20Suite&format=guided
has chosen the "Mozilla Application Suite" product, which is obsolete (end-of-lifed). It retains the list of components that it always had.

The bug you quote, on the other hand:
https://bugzilla.mozilla.org/show_bug.cgi?id=382463
is in the currently-active "Core" component, which represents all the core parts of the Mozilla platform - of which, as you note, there are a lot.

The solution to your problem is to pick the right Product when filing bugs :-)

Gerv

Comment 3

[Kent Paul Dolan]

(In reply to comment #2)
> The list of components depends on the Product
> selected. The URL you quoted above:

> https://bugzilla.mozilla.org/enter_bug.cgi?product=Mozilla%20Application%20Suite&format=guided

> has chosen the "Mozilla Application Suite"
> product, which is obsolete (end-of-lifed). It
> retains the list of components that it always had.
 
> The bug you quote, on the other hand:
> https://bugzilla.mozilla.org/show_bug.cgi?id=382463
> is in the currently-active "Core" component, which
> represents all the core parts of the Mozilla
> platform - of which, as you note, there are a lot.
 
> The solution to your problem is to pick the right
> Product when filing bugs :-)
 
> Gerv
 

Gerv,

That makes no sense at all.

The bug isn't "invalid" merely because the product
against which it has been placed is end-of-lifed.

I'm reporting bugs against SeaMonkey, which is part
of the Mozilla Application Suite.

SeaMonkey is still under active maintenance
(granted, slow as molasses), and new nightly builds
are produced regularly as clockwork.

SeaMonkey is still far superior to the putative
replacement for it, Firefox, which latter is pretty
much unusably feature bereft, a total bug farm, and
incredibly ugly to anyone used to using SeaMonkey.

To any of my acquaintances who complain about
Firefox, and there are many, I refer them to
SeaMonkey as the better option.

Moreover, the Mozilla Application Suite is shown,
without demurrers, _by_ mozilla.org, on page:

https://bugzilla.mozilla.org/enter_bug.cgi

as the CORRECT PRODUCT against which to report
SeaMonkey bugs.

Certainly it cannot be so difficult to replace one
table with another as to justify arguing over
whether the change is needed with someone who has
just encountered that the change would be HELPFUL TO
DEVELOPERS?

This is even more out of line than it taking three
entire years to get your one line change for Bug
250604 to put a link in the text suggesting
furnishing a Talkback Crash ID with bug reports, to
the page that tells _how_ to _GET_ a Talkback Crash
ID, despite that having that information readily
available to beta testers could only HELP
DEVELOPERS, and would have helped developers
immensely(*) for that ENTIRE THREE YEAR INTERVAL?

Developers need, by policy, to give boosted priority
to bug fixes that make developers more effective at
their tasks.

Receiving more talkback crash IDs was just such a
fix, yet making instructions for how to do it
easily located received incredibly inappropriately
low priority.

Starting bug triage with a more precise component
identification is just such a fix.

I shouldn't have to be doing a sales job like this
even to keep the fix on the active bugs list. The
task should be easily recognized to be in the best
interest OF DEVELOPERS, those very same developers
whose work product includes the SeaMonkey nightly
builds, and accomplished expeditiously, rather than
dismissed.

xanthian.

(*) As soon as I became able to supply talkback
crash IDs, bug fixes for the crashes I reported
became much quicker, days or weeks instead of
formerly years to get a fix. For example:
https://bugzilla.mozilla.org/show_bug.cgi?id=380734

Comment 4

[Gervase Markham [:gerv]]

My apologies; I thought that SeaMonkey had its own Bugzilla product. Having checked, it turns out that this is not the case. Let me give you a better response:

The list of components you saw in the enter_bug.cgi form is the list available for the selected product - the Mozilla Application Suite. If you had selected Firefox, then you would have seen the Firefox list, which is not much bigger (35 vs 27). Unless you click the "advanced" link and pick Core from the long list, then you will never get the Core list which is presented on the bug you link to.

In splitting Core from the front ends, we realised that this would mean that some Core bugs would be filed in a Firefox or Thunderbird or Suite component and need to be moved to Core. We anticipated that this would be done as part of the triage process, and it's actually better because it means that bugs which make it to components in Core are generally good and valid.

So:

- If you want the Guided bug entry form to display a list of Components other than those associated with the chosen Product, I can tell you that's pretty unlikely to ever happen;

- If you want more Components created in the Mozilla Application Suite product, then you need to contact the SeaMonkey team.

Gerv