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

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 ​ >

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 >

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

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

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,

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

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

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

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,

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

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.

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

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?

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

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

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

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

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

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

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

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

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

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?

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

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=edit=1 This is interesting information! Do you have other "folk

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 >

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

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=edit=1 Thank

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,

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

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

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

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

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

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

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

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

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

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

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,

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 >

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

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

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

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

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,