Feature tracking via bug keyword

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Feature tracking via bug keyword

lsblakk
Hello all,

This wiki page: https://wiki.mozilla.org/Features/Release_Tracking now picks up on the keyword 'feature' in your meta/tracking bugs.

Please add this to your feature work to make sure it gets early QA, Stability, PR, User Advocacy, and Release Management awareness in preparation (and in support) of their initial launch.

Thank you,
Lukas
*-*-*-*-*-*
Release Manager, Mozillian
mozillians.org/lsblakk





_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Feature tracking via bug keyword

Chris Peterson-12
On 10/16/13 1:02 PM, Lukas Blakk wrote:
> This wiki page:https://wiki.mozilla.org/Features/Release_Tracking  now picks up on the keyword 'feature' in your meta/tracking bugs.
>
> Please add this to your feature work to make sure it gets early QA, Stability, PR, User Advocacy, and Release Management awareness in preparation (and in support) of their initial launch.

Lukas, can you please clarify what would be considered a "feature" for
this tracking page and when we should use this keywrod?

For example, the SpiderMonkey team is working on Generational GC, which
is a big internal change to improve JS performance, but it is not a
user-facing feature.


thanks,
chris
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Feature tracking via bug keyword

Cameron McCormack-4
In reply to this post by lsblakk
Lukas Blakk wrote:
> This wiki page: https://wiki.mozilla.org/Features/Release_Tracking
> now picks up on the keyword 'feature' in your meta/tracking bugs.
>
> Please add this to your feature work to make sure it gets early QA,
> Stability, PR, User Advocacy, and Release Management awareness in
> preparation (and in support) of their initial launch.

What counts as a feature?
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Feature tracking via bug keyword

Juan Becerra
Anything you think would benefit from people in QA spending quality time doing manual testing qualifies as a feature, for example.

There will be times when this is not clear, but if there's a chance an end-user could see the effect, it would be great to see it flagged.

juanb
 

----- Original Message -----
From: "Cameron McCormack" <[hidden email]>
To: "Lukas Blakk" <[hidden email]>
Cc: "[hidden email] ()" <[hidden email]>, [hidden email], [hidden email], [hidden email]
Sent: Wednesday, October 16, 2013 3:48:30 PM
Subject: Re: Feature tracking via bug keyword

Lukas Blakk wrote:
> This wiki page: https://wiki.mozilla.org/Features/Release_Tracking
> now picks up on the keyword 'feature' in your meta/tracking bugs.
>
> Please add this to your feature work to make sure it gets early QA,
> Stability, PR, User Advocacy, and Release Management awareness in
> preparation (and in support) of their initial launch.

What counts as a feature?
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Feature tracking via bug keyword

Lawrence Mandel-2
In reply to this post by Cameron McCormack-4
----- Original Message -----
> Lukas Blakk wrote:
> > This wiki page: https://wiki.mozilla.org/Features/Release_Tracking
> > now picks up on the keyword 'feature' in your meta/tracking bugs.
> >
> > Please add this to your feature work to make sure it gets early QA,
> > Stability, PR, User Advocacy, and Release Management awareness in
> > preparation (and in support) of their initial launch.
>
> What counts as a feature?
 
At this point I would consider any major change to the browser as a 'feature'. This is definitely a judgement call. As Juan pointed out with QA, I would consider flagging any work that requires cross team collaboration (QA, releng, IT, etc.), that makes a significant, user or dev visible change (i.e. changes to the UI and changes to DOM/JS APIs), or that you think should be relnoted or announced on the Mozilla blog (alerting comms). I'm sure there are other suitable criteria and just because one or more of these criteria are met doesn't mean you necessarily have to flag a bug as a feature.

We should learn as we go. I think over flagging is welcome at this point.

Lawrence
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Feature tracking via bug keyword

Marc Schifer
I would include any major rewrites of significant portions of the back end as well.

Marc S.

----- Original Message -----
From: "Lawrence Mandel" <[hidden email]>
To: "Cameron McCormack" <[hidden email]>
Cc: "Lukas Blakk" <[hidden email]>, [hidden email], "[hidden email] ()" <[hidden email]>, [hidden email], [hidden email]
Sent: Thursday, October 17, 2013 7:54:52 AM
Subject: Re: Feature tracking via bug keyword

----- Original Message -----
> Lukas Blakk wrote:
> > This wiki page: https://wiki.mozilla.org/Features/Release_Tracking
> > now picks up on the keyword 'feature' in your meta/tracking bugs.
> >
> > Please add this to your feature work to make sure it gets early QA,
> > Stability, PR, User Advocacy, and Release Management awareness in
> > preparation (and in support) of their initial launch.
>
> What counts as a feature?
 
At this point I would consider any major change to the browser as a 'feature'. This is definitely a judgement call. As Juan pointed out with QA, I would consider flagging any work that requires cross team collaboration (QA, releng, IT, etc.), that makes a significant, user or dev visible change (i.e. changes to the UI and changes to DOM/JS APIs), or that you think should be relnoted or announced on the Mozilla blog (alerting comms). I'm sure there are other suitable criteria and just because one or more of these criteria are met doesn't mean you necessarily have to flag a bug as a feature.

We should learn as we go. I think over flagging is welcome at this point.

Lawrence
_______________________________________________
dev-platform mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Feature tracking via bug keyword

Paolo Amadini
In reply to this post by lsblakk
On 16/10/2013 22.02, Lukas Blakk wrote:
> This wiki page: https://wiki.mozilla.org/Features/Release_Tracking now picks up on the keyword 'feature' in your meta/tracking bugs.

I've set the keyword and milestone on bug 907082 but don't see it in:

https://wiki.mozilla.org/Features/Release_Tracking#Platform_2

I've marked it as FIXED because it seems that the queries require that,
but I'm not familiar with the JSON query language enough to understand
why the bug does not appear in the results after doing that.

By the way, can the queries be less restrictive and just select by
product, milestone and "feature" keyword? We generally defer setting
the FIXED status on meta-bugs until all the major dependencies are
handled, that may happen during the Aurora cycle as well, and having
the feature show up in release tracking before everything is fixed can
be useful.

Paolo
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Feature tracking via bug keyword

Lawrence Mandel-2
----- Original Message -----

> On 16/10/2013 22.02, Lukas Blakk wrote:
> > This wiki page: https://wiki.mozilla.org/Features/Release_Tracking now
> > picks up on the keyword 'feature' in your meta/tracking bugs.
>
> I've set the keyword and milestone on bug 907082 but don't see it in:
>
> https://wiki.mozilla.org/Features/Release_Tracking#Platform_2
>
> I've marked it as FIXED because it seems that the queries require that,
> but I'm not familiar with the JSON query language enough to understand
> why the bug does not appear in the results after doing that.

The issue is that the platform queries were only set to match product=Core. I have updated the platform queries to include the Toolkit product and your bug is now listed in the table.

> By the way, can the queries be less restrictive and just select by
> product, milestone and "feature" keyword? We generally defer setting
> the FIXED status on meta-bugs until all the major dependencies are
> handled, that may happen during the Aurora cycle as well, and having
> the feature show up in release tracking before everything is fixed can
> be useful.

Lukas - Can you comment on why the queries require the FIXED status?

Lawrence
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Feature tracking via bug keyword

lsblakk
They do not require the FIXED status
On Oct 18, 2013, at 11:03 AM, Lawrence Mandel <[hidden email]> wrote:

> ----- Original Message -----
>> On 16/10/2013 22.02, Lukas Blakk wrote:
>>> This wiki page: https://wiki.mozilla.org/Features/Release_Tracking now
>>> picks up on the keyword 'feature' in your meta/tracking bugs.
>>
>> I've set the keyword and milestone on bug 907082 but don't see it in:
>>
>> https://wiki.mozilla.org/Features/Release_Tracking#Platform_2
>>
>> I've marked it as FIXED because it seems that the queries require that,
>> but I'm not familiar with the JSON query language enough to understand
>> why the bug does not appear in the results after doing that.
>
> The issue is that the platform queries were only set to match product=Core. I have updated the platform queries to include the Toolkit product and your bug is now listed in the table.
>

Thanks Lawrence!

>> By the way, can the queries be less restrictive and just select by
>> product, milestone and "feature" keyword? We generally defer setting
>> the FIXED status on meta-bugs until all the major dependencies are
>> handled, that may happen during the Aurora cycle as well, and having
>> the feature show up in release tracking before everything is fixed can
>> be useful.
>
> Lukas - Can you comment on why the queries require the FIXED status?
>

They don't, and I've removed those values - typically bugs don't get their target milestone set until after they've landed on that version anyway, and even if it's not fixed yet but *targeted* we should make sure it's visible early and known to our support teams.

Cheers,
Lukas


_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning