We've recently been tracking lots of bugs in add-ons, e.g. bug 700547. There is no suitable product or component for these, so they often end up in Core/General or Core/JS Engine, which is confusing. We should add a new product and/or component for these. https://wiki.mozilla.org/BMO/Requesting_Changes gives guidelines for the info needed before adding a new product and/or component. One tricky thing is that we don't want every single bug/feature request for every add-on to end up with us, we only want this for certain interesting things (e.g. zombie compartments). So we should choose the name with some care. (BTW, the QA Contact for this component is "firstname.lastname@example.org", which is missing an 'r'.)
There is a a "addons.mozilla.org" Product. Creating a new component inside that might be a better option, if the existing ones don't fit already.  https://bugzilla.mozilla.org/describecomponents.cgi?product=addons.mozilla.org
The addons.mozilla.org product is about the AMO website itself, not the add-ons hosted within it. Also, AMO add-ons are only a fraction of all add-ons.
i think classifying the product or component as "technical evangelism" would avoid the issue of people using it as a location for reporting bugs in addons. i propose creating a new component under the current "Technical Evangelism" product called "Addons" for tracking these issues. cc'ing stormy to get her feedback on this. (note: we'll probably need signoff from jorge or fligtar before proceeding)
Sounds good to me.
Jorge, Fligtar: any objections to "Technical Evangelism" / "Add-ons" as the product / component names?
I'm OK with it.
I can take this. Do we need to wait for sign-off from the other stake holders or is this good to go forward then? dkl
(In reply to David Lawrence [:dkl] from comment #7) > I can take this. Do we need to wait for sign-off from the other stake > holders or is this good to go forward then? we need sign-off from stormy, or someone else who owns tech-evang.
I've read this thread and the referenced thread a couple of times and I'm not really sure what we are trying to solve. Can someone give me a couple of example bugs that would end up in the new category?
Pretty much all of the bugs blocking bug 700547.
(In reply to Stormy Peters from comment #9) > I've read this thread and the referenced thread a couple of times and I'm > not really sure what we are trying to solve. Can someone give me a couple of > example bugs that would end up in the new category? It's for tracking certain classes of bugs that are common in add-ons and that we can detect and that we wish to track. Bug 700547 is (I think) the only example at the moment -- though I can imagine there might be other examples in the future -- and currently all the bugs tracked by it have a bogus product/component like core/general. It nicely matches the existing meaning of "tech evangelism", as I understand it, in that it's a case where a non-Mozilla entity is writing bad code that interacts with Firefox and hurts users' experiences with and perceptions of Firefox. Also, by putting it under "tech evangelism" it reduces the chance that people will report vanilla bugs in add-ons within it -- and that's good, because should be reported to the individual add-on's bug trackers, wherever they are.
I'm going to try to push this along. The info that https://wiki.mozilla.org/BMO/Requesting_Changes says is needed for a new component: - The name of the component: "Add-ons". (Under the "Tech evangelism" product). - The product it should go in: Tech Evangelism. - A longer description: "Evangelism bugs for add-ons that exhibit common problems that make Firefox run sub-optimally. Note that ordinary add-on bugs should not be filed here, but should be filed with the add-on's own bug tracker." - Any flags (bug and/or attachment) that will need to be visible for bugs against the new component: I'm not sure about that. The description for the Tech Evangelism product at https://bugzilla.mozilla.org/enter_bug.cgi?full=1 is currently "For reporting web pages that need to be upgraded to support web standards and Gecko-based browsers". That should be have something like this appended: "And for reporting add-ons that exhibit common problems that make Firefox run sub-optimally." Stormy, does all that sound ok to you?
+1, this sounds like a good idea as long as we have resources assigned to take track bugs.
This seems sort of similar to the existing Firefox::Extension Compatibility component. Certainly that's where I've moved bugs like this in the past. I wonder if the scope of that component should just be expanded?
(In reply to Nicholas Nethercote [:njn] from comment #12) > Stormy, does all that sound ok to you? Once I get approval I can get this setup. dkl
I'm good with it!