Re: [admin] Recommended way to mark bugs as `next level`? [Was: Re: [custom-elements] Seeking pre-LC comments for Custom Elements; deadline Oct 13
I marked all custom element next level bugs as RESOLVED+LATER. They are here: http://bit.ly/GIZamj
Re: [admin] Recommended way to mark bugs as `next level`? [Was: Re: [custom-elements] Seeking pre-LC comments for Custom Elements; deadline Oct 13
Hi Art, Arthur Barstow art.bars...@nokia.com, 2013-10-05 08:00 -0400: On 10/4/13 8:12 PM, ext Dimitri Glazkov wrote: A better view of bugs is here: https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=14968hide_resolved=1 The only remaining bug is to coordinate with Math and SVG working groups to make sure that they don't step on our dashes: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23256 Everything else is in the Level 2 pile. If there's a better way to mark these up, let me know. That's a good question. I don't recall WebApps agreeing on a specific mechanism for tagging bugs for the next level/version. One option is to set Severity to Enhancement and/or the Priority to one of the lower levels. Another option is to use the Whiteboard field. The Whiteboard field is the easiest and lightest-weight way. That lets individual editors use whatever values they want that are appropriate to their particular specs. So Dimitri could just put Level 2 in the Whiteboard field and optionally maybe also change the status to resolved=later. (I kinda' like using Severity/Enhancement because it is visible in a component's default list view but I don't have a strong preference.) Mike, All - do you have a recommendation for Dimitri (and the rest of WebApps)? Another option that's not as lightweight as using the Whiteboard field is, we could create a set of Target Milestone values for the WebApps bugzilla product, and those would be available to all WebApps components. We'd need to first decide on what the set of values should be. --Mike -- Michael[tm] Smith http://people.w3.org/mike
Re: [admin] Recommended way to mark bugs as `next level`? [Was: Re: [custom-elements] Seeking pre-LC comments for Custom Elements; deadline Oct 13
On Sat, Oct 5, 2013 at 5:22 AM, Michael[tm] Smith m...@w3.org wrote: Hi Art, Arthur Barstow art.bars...@nokia.com, 2013-10-05 08:00 -0400: On 10/4/13 8:12 PM, ext Dimitri Glazkov wrote: A better view of bugs is here: https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=14968hide_resolved=1 The only remaining bug is to coordinate with Math and SVG working groups to make sure that they don't step on our dashes: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23256 Everything else is in the Level 2 pile. If there's a better way to mark these up, let me know. That's a good question. I don't recall WebApps agreeing on a specific mechanism for tagging bugs for the next level/version. One option is to set Severity to Enhancement and/or the Priority to one of the lower levels. Another option is to use the Whiteboard field. The Whiteboard field is the easiest and lightest-weight way. That lets individual editors use whatever values they want that are appropriate to their particular specs. So Dimitri could just put Level 2 in the Whiteboard field and optionally maybe also change the status to resolved=later. I am totally okay with that. (I kinda' like using Severity/Enhancement because it is visible in a component's default list view but I don't have a strong preference.) Mike, All - do you have a recommendation for Dimitri (and the rest of WebApps)? Another option that's not as lightweight as using the Whiteboard field is, we could create a set of Target Milestone values for the WebApps bugzilla product, and those would be available to all WebApps components. We'd need to first decide on what the set of values should be. If I set resolved=later, the target milestone doesn't seem as useful. :DG
Re: [admin] Recommended way to mark bugs as `next level`? [Was: Re: [custom-elements] Seeking pre-LC comments for Custom Elements; deadline Oct 13
Hi Dimitri, Dimitri Glazkov dglaz...@chromium.org, 2013-10-05 09:01 -0700: If I set resolved=later, the target milestone doesn't seem as useful. It does it you plan to reopen a bug at some later date and work on it then --Mike -- Michael[tm] Smith http://people.w3.org/mike
