Adding CSP to bugzilla.mozilla.org

We're about to enable a Content Security Policy (CSP)(1) on bugzilla.mozilla.org. CSP will mitigate several types of attack on our users and our site, including Cross-Site Request Forgery (XSRF)(2) and Cross-Site Scripting (XSS)(3). The first place we're deploying this is in the bug detail page in

Re: Please don't abuse "No bug" in commit messages

Thanks for checking the developer guidelines and making sure they are consistent. I'd like to hear a little more about: branch merges - … I personally wish that especially significant merges *did* have bugs to make it a little easier to track problems back to a branch landing and have a place for

Pulsebot has been given a major game misconduct penalty

Pulsebot has been suspended when we found it was spamming 5-digit bmo bugs about GitHub issues. There's a ticket to clean up bmo https://bugzilla.mozilla.org/show_bug.cgi?id=1336563 and I'll work with that team to get it cleaned up. Please reach out to bmo-ad...@mozilla.org so we can work with ev

Re: Pulsebot has been given a major game misconduct penalty

Also, thanks to :jld for alerting me to the situation. -- Emma On Fri, Feb 3, 2017 at 12:52 PM, Emma Humphries wrote: > Pulsebot has been suspended when we found it was spamming 5-digit bmo bugs > about GitHub issues. > > There's a ticket to clean up bmo https://bug

Re: Is there somewhere to get a report of new test failures from a web-platform-tests sync?

I'm glad to know that people are using Triage Center! Pull requests would be gratefully accepted, and if you don't have time, if you want to point me at relevant APIs and give me a spec for what you need, I can see what I can do, or recruit helpers. -- Emma On Fri, Feb 10, 2017 at 7:40 PM, Brian

Re: unowned module: Firefox::New Tab Page, help me find an owner

FYI, this was resolved yesterday. Peter DeHann's volunteered to triage the component. Replies to FFx list please. -- Emma On Wed, Mar 22, 2017 at 6:22 AM, wrote: > I have not been able to find an owner for the Firefox::New Tab Page > bugzilla component (bug 1346908). There are 35 tests in the

Re: QF bug whiteboard tags

This is Jean and Harold's work documented here: https://docs.google.com/document/d/1Ka8eNAISQodT1mS_OXapFG-_kk94GoXyo4eKH1j7EV4/edit -- Emma On Wed, May 10, 2017 at 8:05 PM, Jim Mathies wrote: > Hey all, > > The quantum flow project has been filing a lot of bugs lately. I'm curious > about two

Bulk Closing Intermittents

As discussed earlier, Joel and I have kicked off a process to close intermittent test failures in Bugzilla. If a test associated with a bug does not fail in 21 days, we'll close the bug as RESOLVED:INCOMPLETE. The first batch of intermittent bugs to close has 5,130 tickets. I have a script to clo

Re: Bulk Closing Intermittents

Dylan, Thank you for clarifying that difference. That was sloppy of me to describe that as a DBA operation. -- Emma On Mon, Jul 10, 2017 at 7:25 AM, Dylan Hardison wrote: > > > > > On Jul 7, 2017, at 19:35, Emma Humphries wrote: > > > > The first batch of intermitt

Re: Bulk Closing Intermittents

ke what happened on bug > 1328486 (it was bulk-closed, and then a couple of hours later the OF > robot reported that there were two failures this week - but the bug > remained closed). > > Cheers, > kats > > On Fri, Jul 7, 2017 at 10:35 PM, Emma Humphries wrote: > > As d

Re: Bulk Closing Intermittents

Yes, my query for bugs to close filters for "leave-open". Thanks! -- Emma On Wed, Jul 12, 2017 at 6:18 AM, wrote: > On Wednesday, 12 July 2017 04:09:52 UTC+1, Karl Tomlinson wrote: > > I assume this was integrated with OrangeFactor? > > > > That is the only way I know to determine whether an

Status of Closing Intermittents

Two Sundays ago I went through and closed the first batch of intermittent bugs with no new OrangeFactor (or other) comments. That was 5,000 bugs and cause an bugmail storm. I'm holding off on closing the next batch, because we need to run a script to do this. https://bugzilla.mozilla.org/show_bug

Triage Summary 2017-08-07

It's the weekly report on the state of triage in Firefox-related components. I’m writing this from a cafe in Helsink where the sun just came out. Hotspots The components with the most untriaged bugs remain the JavaScript Engine and Build Config. It is great to see the number of untriaged bugs in

Triage Summary 2017-08-21

It's the weekly report on the state of triage in Firefox-related components. I apologize for missing last week’s report. I was travelling and did not have a chance to sit down and focus on this. Hotspots The components with the most untriaged bugs remain the JavaScript Engine and Build Config. I

Re: Triage Summary 2017-08-21

, which have an assignee, but have not been modified in the past two weeks. https://mzl.la/2u2poMJ Recommendation: review assignments, determine if the priority should be changed to P2, P3, P5 or RESOLVE. On Mon, Aug 21, 2017 at 4:01 PM, Emma Humphries wrote: > It's the weekly report on t

Triage Report 2017-08-28

It's the weekly report on the state of triage in Firefox-related components. Poll Would you like a logged in BMO home page like: https://fitzgen.github.io/bugzilla-todos/? https://twitter.com/triagegirl/status/902327322178609153 Hotspots The components with the most untriaged bugs remain the J

[no subject]

It's the weekly report on the state of triage in Firefox-related components. Marking Bugs for the Firefox 57 Release The bug that will overshadow all the hard work we put into the Firefox 57 release has probably already been filed. We need to find it and fix it. If you think a bug might affect us

Re: Intermittent oranges and when to disable the related test case - a simplified policy

Andy To start: https://bugzilla.mozilla.org/buglist.cgi?product=Core&product=Firefox&product=Firefox%20for%20Android&product=Firefox%20for%20iOS&product=Toolkit&query_format=advanced&resolution=---&status_whiteboard=test%20disabled%2Ctest-disabled%2Ctestdisabled&status_whiteboard_type=anywordssub

Re: Intermittent oranges and when to disable the related test case - a simplified policy

In order to be more consistent, marking a failing test as disabled should be done with a keyword instead of a whiteboard tag. Proposed keyword: test-disabled Description: Used by test automation team to indicate the failing test associated with this bug has a failure rate above a threshold level a

Re: Intermittent oranges and when to disable the related test case - a simplified policy

that whiteboard tag being used that way? On Wed, Sep 6, 2017 at 4:32 PM, Emma Humphries wrote: > Andy > > To start: > > https://bugzilla.mozilla.org/buglist.cgi?product=Core&; > product=Firefox&product=Firefox%20for%20Android& > product=Firefox%20for%20iOS&am

Re: Quantum Flow Engineering Newsletter #25

> So, instead of using the [qf] status whiteboard tag, we will use the existing perf keyword in Bugzilla, and when triaging, teams will use the normal Bugzilla Priority fields to assign priority to the performance bugs. The existing set of o

[Policy] Tracking Regressions in Firefox Components Managed in GitHub Projects

his policy. -- Emma Humphries, Bugmaster, Firefox ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: [Policy] Tracking Regressions in Firefox Components Managed in GitHub Projects

And I misspelled Glob's name. That's Byron Jones. Sorry about that. -- Emma On Tue, Apr 10, 2018 at 4:18 PM, Emma Humphries wrote: > Release Management and the weekly regression triage must be aware of the > status of all reported regressions in order to assure we are not

Re: Is super-review still a thing?

I’m away from my computer until the morning, but I think we disabled the super-review flag. If Kris and David want to draft an architectural review policy that would be useful, and we could set up the flags at the right level > On Apr 20, 2018, at 23:51, L. David Baron wrote: > >> On Friday

New Policy: Marking Bugzilla bugs for features riding behind a pref

s and feedback on this. Thank you! -- Emma Humphries ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: New Policy: Marking Bugzilla bugs for features riding behind a pref

ship high quality code. — Emma On Wed, May 2, 2018 at 4:57 PM Emma Humphries wrote: > Hello, > > We control enabling many features and changes to Firefox using preferences. > > Program and Release management as well as PI need a better view of this. > > We've written

Intent to disable 'backlog' tracking flag in Bugzilla

The 'backlog' (originally known as 'blocking-loop') tracking flag, is available for bugs in Core::Audio/Video* and Core::WebRTC*. The flag is no longer used by the groups triaging and working on bugs in those components, and per a discussion with :drno (Nils Ohlmeier) I intend to disable setting t

Re: Intent to disable 'backlog' tracking flag in Bugzilla

As I've not heard objections to this, I'm disabling the flag. Thanks, -- Emma On Thu, Jun 28, 2018 at 12:19 AM Emma Humphries wrote: > The 'backlog' (originally known as 'blocking-loop') tracking flag, is > available for bugs in Core::Audio/Video* and Core

Intent to Disable Metadata:

There are two related requests to disable the use two tracking flag fields in Bugzilla. * https://bugzilla.mozilla.org/show_bug.cgi?id=1473002 Disable the verified-{aurora, beta, production} flag We now use the status-firefoxNN flags for this. * https://bugzilla.mozilla.org/show_bug.cgi?id=1473

Re: Using browser stored credentials for http://mywebsi.de also on https://mywebsi.de

I've been reviewing Password Manager bugs the past few days, and the https/http issue has been bugged: https://bugzilla.mozilla.org/show_bug.cgi?id=667233 and has recent activity. It has an owner, and a priority. On Wed, Nov 25, 2015 at 10:06 AM, Thomas Schäfer wrote: > Am Mittwoch, 25. November

[Responses Needed by Jan 27] Identifying Owners of Bugzilla Components in Firefox, Toolkit, and Core

The short version: we believe that the number of outstanding bugs in a component is the best metric we have of the overall health and quality of that component. We will test this belief by dramatically improving the efficiency of ingest and processing of new bugs, and would like two to four compone

Re: [Responses Needed by Jan 27] Identifying Owners of Bugzilla Components in Firefox, Toolkit, and Core

I understand, and if non-mozilla.com community members need access, email me or request access from inside the sheet. Thanks, -- Emma On Thu, Jan 21, 2016 at 2:31 PM, Josh Matthews wrote: > I'll point out that the downside of using a google doc like this is that > it's only accessible to Mozill

Re: [Responses Needed by Jan 27] Identifying Owners of Bugzilla Components in Firefox, Toolkit, and Core

Good point. I'll make the link accessible to all. -- Emma On Thu, Jan 21, 2016 at 2:44 PM, Dave Townsend wrote: > Is there any reason not to make the link publicly accessible? Then > no-one needs to request access. > > On Thu, Jan 21, 2016 at 2:37 PM, Emma Humphries wrote: >

Status of the Component Owners for Bug Decisions Sheet. Friday 1/26

summaries Firefox:Reading List Cheers, --- Emma Humphries irc: emceeaich bugmail: ehumphr...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Status of the Component Owners for Bug Decisions Sheet. Monday 1/25

ternoon after I sent out the update. And yes, that was a typo in the subject of Friday's email. It didn't come from the alternate universe where the 26th is on a Tuesday. %Complete Core 67.13% Toolkit 59.46% Firefox 70.00% Fennec iOS 45.45% Fennec Android 100.00% Overall 69.31% Cheer

Status of the Component Owners for Bug Decisions List Thursday 1/28

*Status of The Component Owners Sheet* https://docs.google.com/spreadsheets/d/10i30CFUPJM7snz0xX3czFJeBh2tNwjwjtI409DQw3x0/ If you have questions, @emceeaich on irc.mozilla.org If you think someone is a component owner enter 'name?' in owner column If you think a component is defunct (no longer

Bug Program Next Steps

Bug Program Next Steps Over the last week, I’ve asked you to step up and identify developers who will be responsible for bugs triaged into their component (in Firefox, Core, Toolkit, Fennec iOS, and Fennec Android.) Why This Matters Bugs are a unit of quality we can use to see how we’re doing. W

Re: Bug Program Next Steps

;t want to waste engineering's time, so we're piloting this with a small number of groups so we can see if we're going in the right direction, and stated what we expect to see happen with this work so we can decide if we'll continue with it. -- Emma Humphries On Fri, Jan 29, 2016

Re: Bug Program Next Steps

On Tue, Feb 2, 2016 at 9:04 AM, Richard Newman wrote: > Here's my very lightweight counter-proposal: > > Once or twice a week, automatically mail out two lists (in one email) to > the set of people Emma collected. The first are is UNCONFIRMED bugs. The > second is NEW bugs, not filed by one of th

Re: Making it easier to file performance bugs?

On Sat, Feb 13, 2016 at 4:50 AM, David Rajchenbach-Teller < dtel...@mozilla.com> wrote: > > > One possible solution would be to: > - add a component Firefox > Performance (and also Thunderbird > > Performance, etc.) to Bugzilla, which would cover all untriaged > performance issues (including web c

Status Notifications for New Bugs in DOM, DevTools, and Hello

Recently, Benjamin Smedberg gave an airmozilla talk in Mountain View [1] about improving how we handle bugs filed against Firefox, and how we hope it will make our product, the Web, and our lives better. Today, we’re ready to show you the next steps of that project. With the help of dedicated tr

Re: Status Notifications for New Bugs in DOM, DevTools, and Hello

On Mon, Feb 29, 2016 at 12:02 PM, Josh Matthews wrote: > Am I right in assuming that this is a comment that's added to the bug when > a triage decision is made, rather than as a direct response to filing the > bug? ​Yes, for now it's a comment (so we can trigger bugmail) and later it will be a

Re: Status Notifications for New Bugs in DOM, DevTools, and Hello

- Emma On Mon, Feb 29, 2016 at 12:16 PM, Emma Humphries wrote: > > On Mon, Feb 29, 2016 at 12:02 PM, Josh Matthews > wrote: > >> Am I right in assuming that this is a comment that's added to the bug >> when a triage decision is made, rather than as a direct response

Re: Setting property on the element is no longer working on Firefox 45

ty, have a look at this and update it!) The things that would be most helpful are * reproduction steps * isolated example Thanks, -- Emma Humphries, Bugmaster On Thu, Mar 10, 2016 at 10:23 AM, Devan Shah wrote: > hello > > When I set a custom property such as element.listofSome

Triage Plan for Firefox Components

following the new process -- Emma Humphries, Bugmaster ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: Triage Plan for Firefox Components

c Rescorla wrote: > 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 T

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

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

gt; telling you things you don’t care about. Or, I could start arguing in the > bug, that this should be higher priority, and fill up the comments with > non-technical information. > > Getting close to a full page, I’ll stop now. I’m available for live > conversations on the topic :)

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

and consideration as we make Bugzilla and Firefox better for everyone. -- Emma Humphries 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 decisions on new bugs, and

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

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. Thanks. -- Emma On Tue, Apr 5, 2016 at 5:27 PM, Emma Humphries wrote: > It's been a week since I ask

Re: Triage Plan for Firefox Components

ugzilla. Would you be up for helping me run a short pilot of the multi-queue system you're describing? -- Emma On Wed, Apr 6, 2016 at 11:50 PM, L. David Baron wrote: > On Wednesday 2016-04-06 18:47 -0700, Emma Humphries wrote: > > Following up on yesterday's email: I put toge

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

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

Re: [Bug 1224726] High memory consumption when opening and searching a large Javascript file in debugger.

Here's the open bugs they have touched http://mzl.la/1Q3w24o I realized this morning at the Project Meeting that we still have Monday's listed as bug triage days and I think there's some supporting structure around it that we need to give it. Let me think about that, so we can keep y'all from get

Re: [Bug 1224726] High memory consumption when opening and searching a large Javascript file in debugger.

Ah, I was looking at open bugs. Okay, he's either got a script running or something similar. On Mon, Apr 11, 2016 at 3:04 PM, Mats Palmgren wrote: > On 2016-04-11 23:32, Emma Humphries wrote: > >> Here's the open bugs they have touched http://mzl.la/1Q3w24o >> &g

Re: [Bug 1224726] High memory consumption when opening and searching a large Javascript file in debugger.

Sent them an email. On Mon, Apr 11, 2016 at 3:26 PM, Emma Humphries wrote: > Ah, I was looking at open bugs. > > Okay, he's either got a script running or something similar. > > On Mon, Apr 11, 2016 at 3:04 PM, Mats Palmgren wrote: > >> On 2016-04-11 23:32, Emma H

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: Changes to bugzilla "plugins" product

Let me take a look at those. On Mon, May 2, 2016 at 1:01 PM, Justin Dolske wrote: > Will Firefox :: Extension Compatibility also be rolled into this new :: > Other component? > > (There are ~700 open bugs there still, most of which look pretty stale.) > > Justin > > On Mon, May 2, 2016 at 11:53

Re: Changes to bugzilla "plugins" product

since the first of the year I'd like to get those into the right component, and make a decision ​ on disposing ​ ​of ​ the rest? -- ​ Emma​ On Mon, May 2, 2016 at 1:37 PM, Emma Humphries wrote: > Let me take a look at those. > > On Mon, May 2, 2016 at 1:01 PM, Justin Dolske wr

Re: Changes to bugzilla "plugins" product

to the add-on developer themselves (which > often means closing them). > > On Mon, May 2, 2016 at 2:01 PM, Emma Humphries wrote: > > Pasting what I mentioned in #fx-team > > > > > > Regarding FFx::Extension Compatibility componen > > t. > > 702 bugs total, 282

Re: Changes to bugzilla "plugins" product

its seems like its a holding pen for bugs that need to be passed > on to other areas or back to the add-on developer themselves (which > often means closing them). > > On Mon, May 2, 2016 at 2:01 PM, Emma Humphries wrote: > > Pasting what I mentioned in #fx-team > > &

Re: Ignoring viewpoints of non-Mozilla-employees can't be the way to go for a OSS project!

I want to point out that the bug in question had 48 Mozillians CC'ed on it, so any comments on the bug which are extraneous to the subject of the bug add noise to the signal. Comments are a place to make a case for a fix, but not indulging in a jeremiad if a decision is made not to fix. -- Emma

Re: Intent to unship: HTML microdata API

> On May 19, 2016, at 10:55 AM, Boris Zbarsky wrote: > > Tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=909633 > > Target release: 49 > > I believe I've removed all our in-browser dependencies on this stuff. I > haven't really checked addons because unfortunately the property na

Readable Bug Statuses in Bugzilla

Last week the bugzilla.mozilla.org team had a work week in the San Francisco office. They were finishing the work on the modal edit view in Bugzilla, and joined them to land another new feature: Readable Statuses. Bugs in bugzilla.mozilla.org have a lot of metadata, and it's often not immediately

Re: Readable Bug Statuses in Bugzilla

Yes, the plan is that the 'Modal' view will become the default, and the bmo team is working on that. Meanwhile, you can beat the rush and switch over to the view in preferences. -- Emma On Tue, May 24, 2016 at 9:55 AM, J. Ryan Stinnett wrote: > On Tue, May 24, 2016 at 11:47 AM, Gijs Kruitbosch

Re: Readable Bug Statuses in Bugzilla

ue, May 24, 2016 at 8:45 AM, Emma Humphries wrote: > Last week the bugzilla.mozilla.org team had a work week in the San > Francisco office. They were finishing the work on the modal edit view in > Bugzilla, and joined them to land another new feature: Readable Statuses. > > Bugs in bu

Re: Readable Bug Statuses in Bugzilla

Ted Mielczarek wrote: > >> On Tue, May 24, 2016, at 11:45 AM, Emma Humphries wrote: >> >>> Last week the bugzilla.mozilla.org team had a work week in the San >>> Francisco office. They were finishing the work on the modal edit view in >>> Bugzilla, and join

Re: Intent to remove: Error Console

There's 77 open bugs in the component, http://mzl.la/1YbBKto, how would you like to handle those? -- Emma On Mon, Jun 6, 2016 at 1:04 PM, Brian Grinstead wrote: > There is an Error Console feature in toolkit that's been replaced by the > Browser Console. We'd like to remove associated code in

Re: Intent to remove: Error Console

6, 2016, at 1:20 PM, Emma Humphries wrote: > > > > There's 77 open bugs in the component, http://mzl.la/1YbBKto, how would > you like to handle those? > > The majority of these look like frontend-related bugs and feature requests > which could be closed once the cod

The Whiteboard Tag Amnesty

ps://bugzilla.mozilla.org/show_bug.cgi?id=1279022, depend on your new bug. 5. CC Emma Humphries on the bug We will turn your whiteboard tag into a keyword and remove your old tag from the whiteboard tags, so make sure your dashboards and other tools that consume Bugzilla's API are updated to account

Re: The Whiteboard Tag Amnesty

a resolution such as both teams using the new keyword, or specific keywords as long as they don't semantically copy other existing fields. >> On Wed, Jun 8, 2016 at 4:32 PM, Emma Humphries wrote: >> tl;dr -- nominate whiteboard tags you want converted to keywords. Do it by >

Re: The Whiteboard Tag Amnesty

t; what it sounds like is you're just offering (for a limited time) to do > conversions on an opt-in basis? That's great. > > -P > > > On Wed, Jun 8, 2016 at 3:11 PM, Emma Humphries wrote: > >> >> >> > On Jun 8, 2016, at 1:43 PM, Kartikaya Gupta

Re: The Whiteboard Tag Amnesty

utting an administrator in the middle to add and drop keywords and > indicies would have just slowed stuff down. Permissionless to me is a > requirement. > > > On Wed, Jun 8, 2016 at 2:43 PM, Kartikaya Gupta > wrote: > >> What happens after June 24? Is the whiteboard field

Re: The Whiteboard Tag Amnesty

uot; means > concretely here. > > thanks! > > Jason > > On Wed, Jun 8, 2016 at 3:29 PM, Emma Humphries wrote: > >> There is a ticket for a "proper" tag system, >> https://bugzilla.mozilla.org/show_bug.cgi?id=1266609 which given time, >> I'd

Triage for Component Leads

This afternoon I introduced the new triage process we've developed for bugs in Firefox-related components. My presentation is at https://docs.google.com/presentation/d/1qlXlDsMnvcpA5ppJVJWIBaBDPEyw5hbjU-Q7wjjrZQM/edit?usp=sharing The guide to the process is on the Mozilla wiki: https://wiki.mozil

Re: Visualizing Crash Data in Bugzilla

I love this, and it's encouraging me to try an experiment with web extensions to help with triaging bugs. -- Emma On Tue, Aug 16, 2016 at 3:29 PM, Bob Clary wrote: > This is *way* cool! The historical feedback for the signatures is very > compelling. I recommend everyone try it out and that we

Re: Reorganization of Firefox-UI tests in mozilla-central

Henrik, It's not clear to me if this is just moving the location of existing tests, or if you're bringing in new tests. If it's the later, I'm concerned that we're going to get more intermittents filed in Bugzilla, which adds noise to the triage process. If you are adding more tests, then would

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

How To Tags Comments in Bugzilla So We Can Respond Appropriately

You might recall that if you have "editbugs" privileges, you can tag comments in Bugzilla to mark abuse, off-topic discussion, and spam. https://wiki.mozilla.org/BMO/comment_tagging Please use the right tags when reporting comments that violate our etiquette policies so that site admins can take

Emoji and Bugzilla

As the BMO team announced earlier, we're going to be allowing emoji in user inputs in Bugzilla. https://bugzilla.mozilla.org/show_bug.cgi?id=1253535 We have not committed to a date to release this feature as it requires a production database change which we haven't been able schedule yet. Meanwh

Stalled keyword in BMO

At Randell Jesup's suggestion, I've created a `stalled` keyword in bugzilla. This keyword is intended for bugs for which we want to keep open, but have currently exhausted all our attempts to solve. The keyword is documented on BMO and in our policy repo ( https://github.com/mozilla/bug-handling/bl

Writing JS preference observers? Help us test feature gate.

in trying it, please talk with Mythmon, Benson Wong, or Emma Humphries. Thank you! ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

[Bugzilla Change] "Mac OS X" deprecated, "macOS" added

Per https://bugzilla.mozilla.org/show_bug.cgi?id=1520927, we've disabled Mac OS X as an OS choice. This doesn't affect existing bugs marked with Mac OS X. New bugs on Mac desktop should select "macOS". Please update your saved searches accordingly. -- Emma __

Update to "Are We Triaged Yet" for Bug Types

I've made a change to https://are-we-triaged-yet.herokuapp.com/ to support the Bug Type changes we released today. The change is to the pending untriaged report. That will only include bugs of type Defect. The other reports will still have all types of bugs. We are working on reporting for untri

Disabling the UINEEDED keyword

Previously teams and other contributors have used the uineeded keyword in Bugzilla to indicate if the UX team’s expertise was needed. However, that keyword, with a couple of exceptions, is not currently monitored by that team. In order to prevent misunderstandings, I will be disabling the uineede

Re: Disabling the UINEEDED keyword

Typo: s/uineeded/uiwanted/gi On Thu, Apr 25, 2019 at 4:50 PM Emma Humphries wrote: > Previously teams and other contributors have used the uineeded keyword in > Bugzilla to indicate if the UX team’s expertise was needed. > > However, that keyword, with a couple of exceptions, is n

Changes to how we track regressions in Bugzilla

We are making more changes to how we report and track regressions in Bugzilla. There are multiple fields and keywords we use to track regressions in Bugzilla. It’s confusing and the fields are used inconsistently across teams. We are consolidating these fields to reduce confusion and provide a

Re: Changes to how we track regressions in Bugzilla

w the evolution of the process. -- Emma On Mon, Apr 29, 2019 at 3:15 PM Emma Humphries wrote: > We are making more changes to how we report and track regressions in > Bugzilla. > > > There are multiple fields and keywords we use to track regressions in > Bugzilla. It’s confu

Re: Changes to how we track regressions in Bugzilla

6 (migrate existing metadata). I will follow up when we are ready to enable the field in production Bugzilla. -- Emma On Mon, Apr 29, 2019 at 3:15 PM Emma Humphries wrote: > We are making more changes to how we report and track regressions in > Bugzilla. > > > There are multiple fiel

Re: Disabling the UINEEDED keyword

ing a particular UX person because the bug has a low priority. It's >> valuable meta data even if nobody monitors all uiwanted bugs. How do you >> suggest we support that use case going forward? There's the whiteboard but >> that seems like a step backwards. >&

Intent to Change: Reducing the number of severity values in Bugzilla

Hello, and apologies if you receive duplicates of this email. Bugzilla has multiple values for bug severity which are displayed alongside priority. The differences between minor or trivial are small and do not help with describing a bug’s effect. We have keywords to indicate bugs which are crash

Intent to Change: Marking Up Regressions in Bugzilla

We are making more changes to how we report and track regressions in Bugzilla. There are multiple fields and keywords we use to track regressions in Bugzilla. It’s confusing and the fields are used inconsistently across teams. We are consolidating these fields to reduce confusion and provide a co

All-Hands: How to Bugzilla Workshop on Tuesday

If you are new to, intimidated-by, hate, or want a refresher on how to work with Bugzilla, come to my How to Bugzilla workshop. Tuesday, June 18th 13:30 (1:30 PM) Fairmont Macdonald Ballroom C This is a workshop. Bring your laptops or tablets and log into Bugzilla. I will cover: * Finding the b

Inbound change to Are We Triaged Yet?

Hello, With today's merge for Firefox 70, I'm pushing a small, but hopefully useful change to our triage dashboards at https://are-we-triaged-yet.herokuapp.com/. I'm breaking out untriaged bugs into two groups: * Untriaged bugs with needinfos pending * Untriaged bugs without needinfos I'm doing

Re: Inbound change to Are We Triaged Yet?

To clarify, these reports are defects only: * Untriaged defects with needinfos pending * Untriaged defects without needinfos Remember it's a triage power-move to look at bug descriptions and move them to enhancements or tasks if they aren't bugs. -- Emma On Mon, Jul 8, 2019 at 2:

Re: Intent to Change: Reducing the number of severity values in Bugzilla

can search for the disabled values in Advanced Search, view values of severity which were changed using the History view of a bug, or request `history` as one of the returned fields in the Bugzilla API. Thank you, Emma On Wed, Jun 12, 2019 at 12:40 PM Emma Humphries wrote: > Hello,

  1   2   >