Mission: Add-ons enable Firefox users to personalize their web experience.
This is the home page for Add-ons at Mozilla.
Including but not limited to:
Note: This is a list of people employed by Mozilla. But we are way more than that, please add yourselves in if you want.
Emanuela Damiani, UX Designer (internal)
- Rachel Tublitz, Add-ons Lead (internal)
- Jorge Villalobos, Product Manager (internal, mozillians profile)
- Scott DeVaney, Sr. Editorial Manager (internal, mozillians profile)
- Caitlin Neiman, Community Manager (internal, mozillians profile)
- Andreas Wagner, Product Operations Manager (internal, mozillians profile)
- Philipp Kewisch, Operations Manager (internal, mozillians profile)
Get in touch
If you discover an add-on security vulnerability, even if the add-on is not hosted on a Mozilla site, please notify us. We will work with the developer to correct the issue. Please report security vulnerabilities confidentially
in Bugzilla or by emailing firstname.lastname@example.org.
Bugs on addons.mozilla.org
If you find a problem with the site, we'd love to fix it. Please file a bug report and include as much detail as possible.
Please see the add-ons calendar:
Click into the calendar event to find links to publicly available meeting minutes.
Contribute to Add-ons
Support user freedom by helping to keep Firefox the most customizable browser available.
Status & Roadmap
Bugs are stored in one of two places depending upon the project. Roadmaps are all stored in Trello.
Anything that has to land in Firefox or Firefox for Android must have a Bugzilla bug. So most of the bugs are tracked in there.
Everything else is tracked on Github. The main repositories are:
We use Trello for planning out roadmaps. A Trello card normally relates to multiple bugs, or a larger feature.
For information on the roll out of multi-process Firefox and add-ons, please see the schedule
Planning to communicate changes or coming features. One example is blogs, audiences, channels, and who will be writing/reviewing.
- Improve work prioritization, so the team is always working on the most important features.
- Simplify continual planning, so the plan matches reality.
- Improve visibility so that the stakeholders make the best decisions about the direction of the product (call out risks early, relative priorities, trade-offs)
Priorities follow this Standard:
- Priority 1 - Blocker, must-fix before shipping or a priority feature we are including in this release.
- Priority 2 - Major impact, considering severity × probability. Not a blocker for shipping. For Features we'd really like it, but wouldn't hold shipping for it.
- Priority 3 - Average Bug. definitely a problem, but doesn't stop someone from using the product.
- Priority 4 - Not used.
- Priority 5 - Low-impact. Something we won't fix, but would accept patches for.
Importance will be left at "normal" unless a bug is on the line of being one Priority higher and lower - and then will be marked "Major" or "Minor" accordingly. If a bug has been marked "critical" or "blocker," that bug should be made a P1.
- Optional Whiteboard tag
Adding a short descriptive area tag in the whiteboard when possible, to visually group bugs quickly in a list. ex: "[tabs] triaged"
- Triaged bug mark-up
Adding triaged tag to the end of the Whiteboard for bugs that have been assigned a priority, so we know what has been triaged. No  needed
Common Bug Queries
WebExtensions Triage process
The goal of this is to allow the developers to triage the bugs and spot major regressions, but when we get to a triage meeting it shouldn't be the first time people have looked at the bug and so can have a good conversation about the bug.
Handles installing, running and updating add-ons within Firefox. Also has pages like about:addons. In bugzilla - product: Toolkit, component
This page was last modified on 31 May 2021, at 08:45.