Re: Triage Plan for Firefox Components

Hi Emma, Sorry to bother you again. I built a tool Issue Workflow Explorer (IWE) to help better understand and investigate issue policies in history. The demo is available online at http://yuekeplus.cn/iwe/demo/mozilla. The document is at http://yuekeplus.cn/iwe/tutorial. Now as I'm wonderin

Re: Triage Plan for Firefox Components

On Friday, 14 October 2016 04:10:18 UTC+8, Emma Humphries wrote: > > > ​Hi John, > > Thanks for your patience while I got back to you. > > The triage plan we're using is > https://wiki.mozilla.org/Bugmasters/Process/Triage. > > The Platform team is also using ​ > https://wiki.mozilla.org/Plat

Re: Triage Plan for Firefox Components

On Fri, Oct 7, 2016 at 2:29 AM, wrote: > Hi I'm someone who is studying the triage process and workflow among OSS, > Can anyone tell me does the new triage plan discussed here get adopted and > what is the final version? I would also love to know where and could I > follow your discussions on pol

Re: Triage Plan for Firefox Components

On Wednesday, 30 March 2016 04:08:45 UTC+8, Emma Humphries wrote: > tl;dr > > In Quarter Two I'm implementing the work we’ve been doing to improve > triage, make actionable decisions on new bugs, and prevent us from shipping > regressions in Firefox. > > Today I’m asking for feedback on the plan

Re: Triage Plan for Firefox Components

On 2016-04-13 9:34 AM, Gervase Markham wrote: > On 12/04/16 21:01, Mark Côté wrote: >> Meant to reply to this earlier... BMO has a User Story field that sounds >> like it does exactly what you want. It's an editable field that keeps >> history (admittedly not in an easy-to-read way, but that could

Re: Triage Plan for Firefox Components

On 12/04/16 21:01, Mark Côté wrote: > Meant to reply to this earlier... BMO has a User Story field that sounds > like it does exactly what you want. It's an editable field that keeps > history (admittedly not in an easy-to-read way, but that could be > improved). Despite the name of the field, I'

Re: Triage Plan for Firefox Components

I've long thought that Bugzilla should be more like Wikipedia: the "front page" of the bug is editable and always up-to-date (i.e. not incorrect or outdated STRs), but the history and meta discussion is still available on a "back page". On 4/12/16 2:19 PM, David Lawrence wrote: I used to thi

Re: Triage Plan for Firefox Components

I used to think it should be called "Abstract". Sort of a summarization of the bug itself. dkl On 04/12/2016 05:02 PM, Emma Humphries wrote: > This is probably a field that could stand to be re-labled, as I was > blithely thinking (and I would guess others are) that it was for features, > only. >

Re: Triage Plan for Firefox Components

This is probably a field that could stand to be re-labled, as I was blithely thinking (and I would guess others are) that it was for features, only. -- Emma On Tue, Apr 12, 2016 at 1:01 PM, Mark Côté wrote: > On 2016-04-07 2:50 AM, L. David Baron wrote: > > (I'd much rather a bug report be edit

Re: Triage Plan for Firefox Components

On 2016-04-07 2:50 AM, L. David Baron wrote: > (I'd much rather a bug report be editable text, with history > available, for answers to these or similar questions -- rather than > a stream of permanent comments. But we seem stuck with the horrid > stream-of-comments Bugzilla format, which means I

Re: Triage Plan for Firefox Components

This also has the effect of being somewhat confusing for the docs team, since we may use your priority labels when planning the order in which to work. Having a standardized system would make our lives easier and improve the quantity and quality of the material we produce to document y'all's work.

Re: Triage Plan for Firefox Components

My personal gmail is : anna.j.hite On Friday, April 8, 2016 11:53 PM, Douglas Turner wrote: Emma, Thanks for doing this. I'm not sure whether something like this would work for platform engineering, but we'll keep an eye how things develop with Firefox and might consider it once we h

Re: Triage Plan for Firefox Components

On Wed, Apr 6, 2016 at 6:47 PM, Emma Humphries wrote: > > I'd like to finish up feedback on by the end of the working day Thursday > the 6th (PST.) > > Then we'll get to work on a solid specification for the work so we can > start implementation sometime in Q2. > ​Okay, closing off discussion f

Re: Triage Plan for Firefox Components

Hmm.. Well, whether platform adopts this universally or not seems like a question for Doug and Johnny. Though, I'm sure they'll take your input seriously. Doug, do you have any thoughts on how long an evaluation period you think is appropriate here? -Ekr On Fri, Apr 8, 2016 at 3:25 PM, Emma Hu

Re: Triage Plan for Firefox Components

And yes, that's what I mean by Platform. Thanks. On Fri, Apr 8, 2016 at 11:24 AM, Andrew McCreight wrote: > Emma can correct me if I'm wrong, but I think she is using "Firefox" in > the non-jargony sense of the entire thing we're shipping in Firefox, > including Gecko. We've been using this sys

Re: Triage Plan for Firefox Components

Emma can correct me if I'm wrong, but I think she is using "Firefox" in the non-jargony sense of the entire thing we're shipping in Firefox, including Gecko. We've been using this system for a month or so in DOM. I think it has been going well. Anybody who is interested can ask Andrew Overholt or I

Re: Triage Plan for Firefox Components

Emma, Thanks for doing this. I'm not sure whether something like this would work for platform engineering, but we'll keep an eye how things develop with Firefox and might consider it once we have some experience there. I encourage you to report back here when Firefox starts using this system

Re: Triage Plan for Firefox Components

On Fri, Apr 8, 2016 at 10:54 AM, Benjamin Smedberg wrote: > On Thu, Apr 7, 2016 at 2:50 AM, L. David Baron wrote: >> Why it's important >> What makes this problem important or urgent to fix? >> > > Yes! If this isn't clear, who owns this? Either the module owner/peer, or a > product m

Re: Triage Plan for Firefox Components

On Thu, Apr 7, 2016 at 2:50 AM, L. David Baron wrote: > > > I don't think the idea that a bug belongs in the triage queue if it > is untriaged and without a needinfo? is the right process. I think, > instead, that there should be less emphasis on needinfo? to a > specific person, and more emphas

Re: Triage Plan for Firefox Components

You might be able to create views into these triage queue's with combinations of existing keywords and maybe a few added ones. For example: Can reproduce Can others reproduce the problem described? has the inverse represented by needs-testcase for example. In the case of the bug

Re: Triage Plan for Firefox Components

First: there's that Bugzilla Anthropology project ( https://wiki.mozilla.org/Bugzilla_Anthropology) thanks. I'd heard mention of it and asked around. What we found during the pilot, and the Platform Team has found in their triage, is that list of bugs with needinfo? is I'm worried that multiple q

Re: Triage Plan for Firefox Components

re: Determining answers to any or all of the above might require multiple rounds of dialog, and some of them need to be understood in sequence rather than in parallel. They also require very different sets of expertise to determine. Yes! We should set up systems and process and sk

Re: Triage Plan for Firefox Components

On Wednesday 2016-04-06 18:47 -0700, Emma Humphries wrote: > Following up on yesterday's email: I put together a draft second proposal > and shopped it around some, and now I want to bring that back into the main > discussion. > > The bullet point version of this is: > > * Add a binary field that

Re: Triage Plan for Firefox Components

Sorry to be dense, but if I understand correctly, you'd like to: 1. Have a policy that all of Gecko needs to triage bugs in a certain way. 2. Redefine how everyone defines priorities? And you think that 24 hours is enough time to get consensus on that. Do I have that right? -Ekr On Wed, Apr 6

Re: Triage Plan for Firefox Components

Following up on yesterday's email: I put together a draft second proposal and shopped it around some, and now I want to bring that back into the main discussion. The bullet point version of this is: * Add a binary field that components can use, TRIAGED (Y/N, T/F, +,-) * In the case of Firefox rel

Re: Triage Plan for Firefox Components

On Fri, Apr 1, 2016 at 9:45 AM, James Graham wrote: > But once we have picked something, can we at least try to remove any UI > that is more-or-less vestigial given that decision and, at least briefly, > fight entropy by making things simpler and more consistent, rather than the > reverse. ​Ye

Re: Triage Plan for Firefox Components

On Tue, Apr 5, 2016 at 9:27 PM, Emma Humphries wrote: > It's been a week since I asked for your comments on the plan for triage, > thank you. > > I'm going reply to some general comments on the plan, and outline next > steps. > > Ekt and others said that up to now, individual teams have owned how

Re: Triage Plan for Firefox Components

Emma, On Tue, Apr 5, 2016 at 5:27 PM, Emma Humphries wrote: > It's been a week since I asked for your comments on the plan for triage, > thank you. > > I'm going reply to some general comments on the plan, and outline next > steps. > I just want to say that I have been following this thread, an

Re: Triage Plan for Firefox Components

It's been a week since I asked for your comments on the plan for triage, thank you. I'm going reply to some general comments on the plan, and outline next steps. Ekt and others said that up to now, individual teams have owned how they triage and prioritized bugs. Mozilla has made commitments to h

Re: Triage Plan for Firefox Components

A few comments, although I think others have touched on some of this already. I think my biggest concern is that this is conflating triage and prioritization, which complicates things and introduces ambiguity. For example, what would it even mean to have a "triage: fix-now" bug that's also a P5? I

Re: Triage Plan for Firefox Components

On 01/04/16 15:51, Mike Hommey wrote: > Bug status is currently, IMHO, completely misused and thus useless: > - people with editbug capability file as NEW by default. Why should a bug > I file in a component I'm not working on (because I noticed a bug > in Firefox) be NEW? > - there is a long t

Re: Triage Plan for Firefox Components

Gervase Markham wrote: On 01/04/16 15:51, Mike Hommey wrote: Bug status is currently, IMHO, completely misused and thus useless: - people with editbug capability file as NEW by default. Why should a bug I file in a component I'm not working on (because I noticed a bug in Firefox) be NEW? -

Re: Triage Plan for Firefox Components

On 4/1/16 10:57 AM, Emma Humphries wrote: Could you add how your team maps the the priority flag, or link to a page describing it? https://wiki.mozilla.org/index.php?title=Bugmasters/Projects/Folk_Knowledge/Priority_Field&action=edit&redlink=1 This is interesting information! Do you have other

Re: Triage Plan for Firefox Components

On Thu, Mar 31, 2016 at 06:47:32PM -0700, Emma Humphries wrote: > What to call these has been a long thread in the document comments, but I'm > starting to lean towards: > > FIX-FOR-RELEASE > FIX-SOON > and > BACKLOG > > as well as adding (see the proposed edit) a FEATURE resolution for bugs > wh

Re: Triage Plan for Firefox Components

On 04/01/2016 08:32 AM, Gijs Kruitbosch wrote: On 01/04/2016 16:16, Andrew McCreight wrote: On Thu, Mar 31, 2016 at 4:01 PM, Chris Peterson wrote: Anthony's Media Playback team has been using a simple and effective triage system without special tags. All open bugs in the Audio/Video Playba

Re: Triage Plan for Firefox Components

While we're on the topic of how teams use the Priority Flag, could I ask y'all do to something for me? Could you add how your team maps the the priority flag, or link to a page describing it? https://wiki.mozilla.org/index.php?title=Bugmasters/Projects/Folk_Knowledge/Priority_Field&action=edit&re

Re: Triage Plan for Firefox Components

On 04/01/2016 10:35, Marco Bonardo wrote: Fwiw, we (Awesome Search Team) also use Priority for the backlog, and we consider P1, P2 and P5 the same as Media Playback team. So there is some convergence about the meaning of those. Though we also use P3 for "we care about this and will fix it, provid

Re: Triage Plan for Firefox Components

On 01/04/16 01:02, Emma Humphries wrote: I've responded to a similar comment in the google doc, but I'll repeat it here. Priority sounds like a great choice, but given that everyone's using the Priority field their own way, there's enough heterogeneity in how it's used to make it difficult. I

Re: Triage Plan for Firefox Components

On 2016-04-01 11:32 AM, Gijs Kruitbosch wrote: On 01/04/2016 16:16, Andrew McCreight wrote: The drawback of indicating priorities in this way is that it is totally opaque to anybody who is not on that particular subteam, let alone somebody who is using Bugzilla for the first time to report b

Re: Triage Plan for Firefox Components

On Fri, Apr 1, 2016 at 8:33 AM, Milan Sreckovic wrote: > Valid point. > > Being able to tell the status of “other team’s bugs” is critical for some > number of people that look at bugs across all teams. A number of > directors, release management, I’m sure a sizeable number. I would still > gue

Re: Triage Plan for Firefox Components

On 01/04/2016 16:16, Andrew McCreight wrote: On Thu, Mar 31, 2016 at 4:01 PM, Chris Peterson wrote: Anthony's Media Playback team has been using a simple and effective triage system without special tags. All open bugs in the Audio/Video Playback component are in one of four states at all tim

Re: Triage Plan for Firefox Components

Valid point. Being able to tell the status of “other team’s bugs” is critical for some number of people that look at bugs across all teams. A number of directors, release management, I’m sure a sizeable number. I would still guess a minor though; I know I am completely unaffected by the P’s a

Re: Triage Plan for Firefox Components

On Thu, Mar 31, 2016 at 4:01 PM, Chris Peterson wrote: > Anthony's Media Playback team has been using a simple and effective triage > system without special tags. All open bugs in the Audio/Video Playback > component are in one of four states at all times: > > * Priority P1 bugs should be fixed A

Re: Triage Plan for Firefox Components

> On Mar 31, 2016, at 18:22 , Daniel Veditz wrote: > > On Thu, Mar 31, 2016 at 12:28 PM, Milan Sreckovic > wrote: > I’m going to start and keep arguing that we do not want to have an explicit > name for that largest bucket of “wishlist” bugs, and should instead h

Re: Triage Plan for Firefox Components

On Fri, Apr 1, 2016 at 8:17 AM, Kartikaya Gupta wrote: > It seems to me that when this bug program was started, it had these > two goals (quoted from Emma's previous email): > > "First, we want > to make better assertions about the quality of our releases by making clear > decisions about which b

Re: Triage Plan for Firefox Components

On Fri, Apr 1, 2016 at 9:30 AM, Lawrence Mandel wrote: > On Fri, Apr 1, 2016 at 8:17 AM, Kartikaya Gupta > wrote: > >> It seems to me that when this bug program was started, it had these >> two goals (quoted from Emma's previous email): >> >> "First, we want >> to make better assertions about th

Re: Triage Plan for Firefox Components

It seems to me that when this bug program was started, it had these two goals (quoted from Emma's previous email): "First, we want to make better assertions about the quality of our releases by making clear decisions about which bugs must be fixed for each release (urgent) and actively tracking th

Re: Triage Plan for Firefox Components

On Fri, Apr 1, 2016 at 2:02 AM, Emma Humphries wrote: > Priority sounds like a great choice, but given that everyone's using the > Priority field their own way, there's enough heterogeneity in how it's used > to make it difficult. > Fwiw, we (Awesome Search Team) also use Priority for the backlo

Re: Triage Plan for Firefox Components

What to call these has been a long thread in the document comments, but I'm starting to lean towards: FIX-FOR-RELEASE FIX-SOON and BACKLOG as well as adding (see the proposed edit) a FEATURE resolution for bugs which are feature tracking and individual features. I'd consider adding a consistency

Re: Triage Plan for Firefox Components

On Thu, Mar 31, 2016 at 12:28 PM, Milan Sreckovic wrote: > Or, I could start arguing in the bug, that this should be higher priority, > and fill up the comments with non-technical information. ​This reminds me, we have filtering tools to mute abusive and unproductive comments in bugs. https:/

Re: Triage Plan for Firefox Components

I've responded to a similar comment in the google doc, but I'll repeat it here. Priority sounds like a great choice, but given that everyone's using the Priority field their own way, there's enough heterogeneity in how it's used to make it difficult. If I was to take that approach, I'm concerned

Re: Triage Plan for Firefox Components

On 3/31/16 3:22 PM, Daniel Veditz wrote: ​We get that now, with no marker at all. The only real difference I see with a marker is that people will catch on sooner whereas now it takes a while until they realize they are being ignored. They eventually get discouraged​ or upset either way. Might ev

Re: Triage Plan for Firefox Components

On Thu, Mar 31, 2016 at 12:28 PM, Milan Sreckovic wrote: > I’m going to start and keep arguing that we do not want to have an > explicit name for that largest bucket of “wishlist” bugs, and should > instead have it marked by the absence of a tag. ​What distinguishes a bug that has not been tria

Re: Triage Plan for Firefox Components

This may be somewhat long winded. I will make it in the context of Gecko graphics, because that’s where I have the most data and experience. It may or may not apply to other components. Reviewing all the incoming bugs, in a timely matter, is very important to us. Over the past few years, the

Re: Triage Plan for Firefox Components

Softvision also makes use of the feature keyword as one way to identify new feature work to test in upcoming releases. Lawrence On Thu, Mar 31, 2016 at 10:49 AM, Milan Sreckovic wrote: > We do have a feature keyword today. While it may be most used for the > documentation purposes, the feedbac

Re: Triage Plan for Firefox Components

We do have a feature keyword today. While it may be most used for the documentation purposes, the feedback graphics team got when we started using it to tag feature requests was positive. As in, it’s OK to use for that. — - Milan > On Mar 29, 2016, at 22:32 , Emma Humphries wrote: > > On

Re: Triage Plan for Firefox Components

Hi Emma, for those of us that are addicted to data: You have about a 1000 bugs of data, and I'd love to hear some of the good parts, and maybe also some of the bad parts. Also, you tested on three teams, and you report a success story from one. Could you frame that a bit? Is that within the

Re: Triage Plan for Firefox Components

On 2016-03-29 8:09 PM, Eric Rescorla wrote: On a more substantive, less procedural note, this seems to be designed for a particular workflow in which there is an assumption that bugs are for immediate processing. However, in may cases we use bugs as placeholders or assemble big dependency tre

Re: Triage Plan for Firefox Components

On Tue, Mar 29, 2016 at 5:09 PM, Eric Rescorla wrote: > On a more substantive, less procedural note, this seems to be designed for > a particular workflow in which there is an assumption that bugs are for > immediate processing. However, in may cases we use bugs as placeholders or > assemble big

Re: Triage Plan for Firefox Components

Hmmm... Who do you believe is the decider here and what do you believe is the decision procedure for these components? Generally, the way things work isn't that Firefox promulgates policy for how other components handle their bugs. On a more substantive, less procedural note, this seems to be desi

Re: Triage Plan for Firefox Components

Components that feed into FFx, so that's Core, Toolbox, Firefox, Fennec and the pieces of platform we're using to ship. While there's not a 'Gecko' component in bugzilla, it does cover the components there which are Gecko. -- Emma On Tue, Mar 29, 2016 at 3:16 PM, Eric Rescorla wrote: > I'm try

Re: Triage Plan for Firefox Components

I'm trying to figure out the scope of this proposal. Are you expecting it to apply merely to Firefox or to Gecko as well? -Ekr On Tue, Mar 29, 2016 at 1:07 PM, Emma Humphries wrote: > tl;dr > > In Quarter Two I'm implementing the work we’ve been doing to improve > triage, make actionable decis