Re: Bug 851818 - Modernizing the Enter Bug Entry Page in Bugzilla
Hi Everyone, Taking in all of the feedback received, Byron came up with updated proposal in https://bugzilla.mozilla.org/show_bug.cgi?id=851818#c3 that I think will address the needs of the feedback provided here. If you have any additional comments, feedback, etc, please feel free to provide that information by replying to this thread. Sincerely, Jason Smith ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Bug 851818 - Modernizing the Enter Bug Entry Page in Bugzilla
On Mon, 18 Mar 2013 20:52:23 +0100, Anthony Ricaud wrote: On 18/03/13 17:39, L. David Baron wrote: On Monday 2013-03-18 09:27 -0700, Jason Smith wrote: I'd actually like to see Core higher on the list for the no-canconfirm case. I think it's common for reasonably well-informed Web developers (who would have been able to choose a reasonably correct component within Core, given the list) to file standards bugs and end up with them languishing in Firefox::General. And I think appropriate guiding for Web developers filing bugs against the rendering engine is an important case. I'd suggest renaming Core here. Web developers don't understand what Core is. They might know Gecko though. Does it make sense to rename Core to Gecko? I'm sure web developers have heard of Gecko (Webkit, Trident, etc) but do they know what Gecko actually covers? Changing Core to Gecko just changes one funny code word with another funny code word. Phil -- Philip Chee phi...@aleytys.pc.my, philip.c...@gmail.com http://flashblock.mozdev.org/ http://xsidebar.mozdev.org Guard us from the she-wolf and the wolf, and guard us from the thief, oh Night, and so be good for us to pass. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Bug 851818 - Modernizing the Enter Bug Entry Page in Bugzilla
I disagree on Calendar being on that list. Doing some Bugzilla diving shows that the number of bugs filed in Calendar over the past month was around ~30 or so bugs. That's less than the Gaia Calendar app itself (which is a Bugzilla component) and is on the low end in comparison to other Bugzilla products. I don't think there's any data to justify the Calendar component remaining on the enter bug page if the bug filing rate is too low. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Bug 851818 - Modernizing the Enter Bug Entry Page in Bugzilla
jsmith.mozi...@gmail.com wrote: I disagree on Calendar being on that list. Doing some Bugzilla diving shows that the number of bugs filed in Calendar over the past month was around ~30 or so bugs. That's less than the Gaia Calendar app itself (which is a Bugzilla component) Are these bugs filed by users with and/or without canconfirm and/or canedit? -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Bug 851818 - Modernizing the Enter Bug Entry Page in Bugzilla
Seems like a good proposal, but dev-platform doesn't really feel like the best place to get feedback from the people affected. Not sure what would be, though. (on Labs: There's a bunch of smaller projects there, but I don't mind if they're slightly harder to find) --da On Mon, Mar 18, 2013 at 9:27 AM, Jason Smith jsm...@mozilla.com wrote: Hi Everyone, In bug 851818 (https://bugzilla.mozilla.org/**show_bug.cgi?id=851818https://bugzilla.mozilla.org/show_bug.cgi?id=851818), I've filed a bug to suggest rethinking what our enter bug entry page for users who are filing bugs with canconfirm or no canconfirm access. I'd like to discuss what changes we should make to that enter bug entry page such as adding new products to the list that we think should be there, keeping certain products on the list that are important enough to remain there, and removing certain products that we don't think need to be there. I've outlined the state of enter bug entry pages under canconfirm and no canconfirm below and included my initial thoughts below. Thoughts? *existing canconfirm access* *enter bug entry page list* - Core - Firefox - Thunderbird - Calendar - Camino - SeaMonkey - Firefox for Android - Mozilla Localizations - Mozilla Labs - Mozilla Services - Other Products *existing no canconfirm access enter bug entry page list* - Firefox - Firefox for Android - Thunderbird - Mozilla Services - SeaMonkey - Mozilla Localizations - Mozilla Labs - Calendar - Core *Ideas for what products we should add* - BootToGecko (canconfirm and not canconfirm) - Firefox for Metro (canconfirm and not canconfirm) - Marketplace (canconfirm and not canconfirm) *Ideas for what products we should remove* - Thunderbird (canconfirm and not canconfirm) - Calendar (canconfirm and not canconfirm) - Camino (canconfirm and not canconfirm) - SeaMonkey (canconfirm and not canconfirm) - Mozilla Labs (canconfirm and not canconfirm) *Rationale for Additions* - BootToGecko - Big focus at Mozilla with a lot of people working on this project, so I think this could benefit greatly from being on the front page. - Firefox for Metro - Important for our Windows 8 story and could probably benefit for contributors from knowing up front where to file bugs on this while it's under development - Marketplace - Important in conjunction with BootToGecko and a common bugzilla product I don't think people realize exists. In doing bug triage for B2G, there's very high cases where bugs for Marketplace have ended up in the incorrect component, so I'm hoping putting this on the front page will increase likelihood that the bug ends up in the right spot. *Rationale for Removals* - Thunderbird - Decreased focus at Mozilla now that has moved to contribution only now, so I don't think this needs to be on the front page. - Calendar - Decreased focus at Mozilla overall in comparison to other products on the front page - Camino - Low focus at Mozilla overall in comparison to other products on the front page - SeaMonkey - Low focus at Mozilla overall in comparison to other products on the front page - Mozilla Labs - Looks like an outdated Bugzilla product that may not have high bug filing usage - probably does not need to be on the front page -- Sincerely, Jason Smith Desktop QA Engineer Mozilla Corporation https://quality.mozilla.com __**_ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/**listinfo/dev-platformhttps://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Bug 851818 - Modernizing the Enter Bug Entry Page in Bugzilla
On Monday 2013-03-18 09:27 -0700, Jason Smith wrote: *existing canconfirm access* *enter bug entry page list* - Core - Firefox - Thunderbird - Calendar - Camino - SeaMonkey - Firefox for Android - Mozilla Localizations - Mozilla Labs - Mozilla Services - Other Products *existing no canconfirm access enter bug entry page list* - Firefox - Firefox for Android - Thunderbird - Mozilla Services - SeaMonkey - Mozilla Localizations - Mozilla Labs - Calendar - Core I'd actually like to see Core higher on the list for the no-canconfirm case. I think it's common for reasonably well-informed Web developers (who would have been able to choose a reasonably correct component within Core, given the list) to file standards bugs and end up with them languishing in Firefox::General. And I think appropriate guiding for Web developers filing bugs against the rendering engine is an important case. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla http://www.mozilla.org/ 턂 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Bug 851818 - Modernizing the Enter Bug Entry Page in Bugzilla
On 18/03/2013 16:27, Jason Smith wrote: - BootToGecko - Big focus at Mozilla with a lot of people working on this project, so I think this could benefit greatly from being on the front page. This should be Firefox OS as that's what the users will know it as. *Rationale for Removals* - Thunderbird - Decreased focus at Mozilla now that has moved to contribution only now, so I don't think this needs to be on the front page. Mozilla is still committed to providing security and stability updates, as well as enabling those contributions. We need the bug reports to enable this to happen, and I think making Thunderbird harder to find would send the wrong message here. Mark. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Bug 851818 - Modernizing the Enter Bug Entry Page in Bugzilla
I have a concern that removing active community projects would increase the community/MOCO divide. Kevin On Mar 18, 2013 10:35 AM, Mark Banner mban...@mozilla.com wrote: On 18/03/2013 16:27, Jason Smith wrote: - BootToGecko - Big focus at Mozilla with a lot of people working on this project, so I think this could benefit greatly from being on the front page. This should be Firefox OS as that's what the users will know it as. *Rationale for Removals* - Thunderbird - Decreased focus at Mozilla now that has moved to contribution only now, so I don't think this needs to be on the front page. Mozilla is still committed to providing security and stability updates, as well as enabling those contributions. We need the bug reports to enable this to happen, and I think making Thunderbird harder to find would send the wrong message here. Mark. __**_ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/**listinfo/dev-platformhttps://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Bug 851818 - Modernizing the Enter Bug Entry Page in Bugzilla
On 2013-03-18 12:39 PM, L. David Baron wrote: I'd actually like to see Core higher on the list for the no-canconfirm case. I think it's common for reasonably well-informed Web developers (who would have been able to choose a reasonably correct component within Core, given the list) to file standards bugs and end up with them languishing in Firefox::General. And I think appropriate guiding for Web developers filing bugs against the rendering engine is an important case. I agree with all of this, but I think that even very well-informed Web developers might find the Core component list daunting and incomprehensible. I think it'd be a good idea to have a special bug-entry wizard just for Firefox didn't render this page correctly that knows how to map standard web development terminology (HTML, JavaScript, CSS, tables, forms, accessibility, ...) to components, and which also encourages inclusion of things like self-contained minimal test cases, screen shots, and cross-browser comparisons. zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Bug 851818 - Modernizing the Enter Bug Entry Page in Bugzilla
Jason Smith schrieb: *Ideas for what products we should remove* And how the XXX should users of those products file new bugs then? Robert Kaiser ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Bug 851818 - Modernizing the Enter Bug Entry Page in Bugzilla
Sounds good to me. Also to add in a piece of private feedback I received - SeaMonkey wants to remain on the front page as there's a strong community behind it that still works on that project. Sincerely, Jason Smith Desktop QA Engineer Mozilla Corporation https://quality.mozilla.com On 3/18/2013 9:39 AM, L. David Baron wrote: On Monday 2013-03-18 09:27 -0700, Jason Smith wrote: *existing canconfirm access* *enter bug entry page list* - Core - Firefox - Thunderbird - Calendar - Camino - SeaMonkey - Firefox for Android - Mozilla Localizations - Mozilla Labs - Mozilla Services - Other Products *existing no canconfirm access enter bug entry page list* - Firefox - Firefox for Android - Thunderbird - Mozilla Services - SeaMonkey - Mozilla Localizations - Mozilla Labs - Calendar - Core I'd actually like to see Core higher on the list for the no-canconfirm case. I think it's common for reasonably well-informed Web developers (who would have been able to choose a reasonably correct component within Core, given the list) to file standards bugs and end up with them languishing in Firefox::General. And I think appropriate guiding for Web developers filing bugs against the rendering engine is an important case. -David ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Bug 851818 - Modernizing the Enter Bug Entry Page in Bugzilla
On 3/18/13 10:14 PM, Jason Smith wrote: Sounds good to me. Also to add in a piece of private feedback I received - SeaMonkey wants to remain on the front page as there's a strong community behind it that still works on that project. For similar reasons I would like Calendar to stay on the main page. Despite it being a community project, it is still active. Users already have enough trouble with update woes and whatnot, removing Calendar from the front page would make it even harder to file Calendar bugs. I have similar feelings for any active project. Philipp ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Bug 851818 - Modernizing the Enter Bug Entry Page in Bugzilla
(2013/03/19 2:31), Mark Banner wrote: On 18/03/2013 16:27, Jason Smith wrote: - BootToGecko - Big focus at Mozilla with a lot of people working on this project, so I think this could benefit greatly from being on the front page. This should be Firefox OS as that's what the users will know it as. I feel new entries are justified. *Rationale for Removals* - Thunderbird - Decreased focus at Mozilla now that has moved to contribution only now, so I don't think this needs to be on the front page. Mozilla is still committed to providing security and stability updates, as well as enabling those contributions. We need the bug reports to enable this to happen, and I think making Thunderbird harder to find would send the wrong message here. Removing ThunderBird will give wrong signals. I am afraid that will reduce the user base even though ESR seems to be well received today. At the next release cycle, we will see large departure and thus this removal negates the idea of community-support. We will enter cycles of reduced number of users, reduced number of feedbacks, and thus eventual demise sooner than otherwise. IMHO. That removal will start me pondering what to do with my mailer (currently TB), too. Mark. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Bug 851818 - Modernizing the Enter Bug Entry Page in Bugzilla
Robert Kaiser wrote: *Ideas for what products we should remove* And how the XXX should users of those products file new bugs then? we're talking about removing products from the list of products initially shown to users, not about removing the products from bmo completely. the complete list of products will always be a single click away. Philipp Kewisch wrote: I have similar feelings for any active project. there are *many* active projects/products which are not initially shown; i don't think that alone is good enough criteria for inclusion in the list. finding the product isn't difficult, via clicking on other products or searching with the search field. if someone isn't able to find the calendar product via either of these, i would question the value of their bug report :) L. David Baron wrote: I'd actually like to see Core higher on the list for the no-canconfirm case. I think it's common for reasonably well-informed Web developers (who would have been able to choose a reasonably correct component within Core, given the list) to file standards bugs and end up with them languishing in Firefox::General. if you select 'firefox' from the guided bug form, your bug is forced into the 'firefox::untriaged' component. if their bugs are landing in firefox::general, it would be because either they are switching to the advanced form and selecting that product/component, or triage are incorrectly moving bugs from firefox::untriaged to firefox::general instead of into the core product. in either case, moving core up in the list won't address this issue. on the guided bug form there's always been a link report an issue with firefox on a site that i've developed, which takes you to the core product. instead of moving core, i'd rather draw more attention to this link. -- byron - irc:glob - bugzilla.mozilla.org team - ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
