Features/Jetpack/Land Parts of Add-on SDK In Core
Status
Land Parts of Add-on SDK In Core | |
Stage | Planning |
Status | In progress |
Release target | ` |
Health | OK |
Status note | ` |
{{#set:Feature name=Land Parts of Add-on SDK In Core
|Feature stage=Planning |Feature status=In progress |Feature version=` |Feature health=OK |Feature status note=` }}
Team
Product manager | David Mason |
Directly Responsible Individual | Dietrich Ayala |
Lead engineer | Irakli Gozalishvili |
Security lead | ` |
Privacy lead | ` |
Localization lead | ` |
Accessibility lead | ` |
QA lead | ` |
UX lead | ` |
Product marketing lead | ` |
Operations lead | ` |
Additional members | ` |
{{#set:Feature product manager=David Mason
|Feature feature manager=Dietrich Ayala |Feature lead engineer=Irakli Gozalishvili |Feature security lead=` |Feature privacy lead=` |Feature localization lead=` |Feature accessibility lead=` |Feature qa lead=` |Feature ux lead=` |Feature product marketing lead=` |Feature operations lead=` |Feature additional members=` }}
Open issues/risks
`
Stage 1: Definition
1. Feature overview
The Add-on SDK is a product for building Firefox addons. You download it separately from Firefox, and it builds addons that load in Firefox using Firefox's existing support for loading addons.
There are a variety of advantages to this approach, but there are also downsides. In particular, because the SDK packages API implementations, the addon bootstrapper, and the module loader with each individual addon (à la static linking in compiled software), addon packages are relatively large.
To reduce addon package size to the absolute minimum, we should land stable parts of the SDK's functionality into the core of Firefox. This includes API implementations, and it may also include the module loader and the bootstrapper.
However, we might decide to land API implementations in core as JavaScript Harmony modules rather than landing a CommonJS module loader in core alongside them.
Also, we should wait for the API implementations to stabilize (f.e. as a result of OOP addons) before we land them in core, since we can iterate faster on them in the SDK's code repository than in core's.
2. Users & use cases
The target audience is addon developers. The use case is an add-on developer using the Add-on SDK (either directly or via the Add-on Builder) to build an addon.
3. Dependencies
`
4. Requirements
`
Non-goals
`
Stage 2: Design
5. Functional specification
`
6. User experience design
`
Stage 3: Planning
7. Implementation plan
`
8. Reviews
Security review
`
Privacy review
`
Localization review
`
Accessibility
`
Quality Assurance review
`
Operations review
`
Stage 4: Development
9. Implementation
`
Stage 5: Release
10. Landing criteria
` {{#set:Feature open issues and risks=` |Feature overview=The Add-on SDK is a product for building Firefox addons. You download it separately from Firefox, and it builds addons that load in Firefox using Firefox's existing support for loading addons.
There are a variety of advantages to this approach, but there are also downsides. In particular, because the SDK packages API implementations, the addon bootstrapper, and the module loader with each individual addon (à la static linking in compiled software), addon packages are relatively large.
To reduce addon package size to the absolute minimum, we should land stable parts of the SDK's functionality into the core of Firefox. This includes API implementations, and it may also include the module loader and the bootstrapper.
However, we might decide to land API implementations in core as JavaScript Harmony modules rather than landing a CommonJS module loader in core alongside them.
Also, we should wait for the API implementations to stabilize (f.e. as a result of OOP addons) before we land them in core, since we can iterate faster on them in the SDK's code repository than in core's. |Feature users and use cases=The target audience is addon developers. The use case is an add-on developer using the Add-on SDK (either directly or via the Add-on Builder) to build an addon. |Feature dependencies=` |Feature requirements=` |Feature non-goals=` |Feature functional spec=` |Feature ux design=` |Feature implementation plan=` |Feature security review=` |Feature privacy review=` |Feature localization review=` |Feature accessibility review=` |Feature qa review=` |Feature operations review=` |Feature implementation notes=` |Feature landing criteria=` }}
Feature details
Priority | P1 |
Rank | 999 |
Theme / Goal | ` |
Roadmap | Jetpack |
Secondary roadmap | ` |
Feature list | Jetpack |
Project | ` |
Engineering team | Jetpack |
{{#set:Feature priority=P1
|Feature rank=999 |Feature theme=` |Feature roadmap=Jetpack |Feature secondary roadmap=` |Feature list=Jetpack |Feature project=` |Feature engineering team=Jetpack }}
Team status notes
status | notes | |
Products | ` | ` |
Engineering | ` | ` |
Security | ` | ` |
Privacy | ` | ` |
Localization | ` | ` |
Accessibility | ` | ` |
Quality assurance | ` | ` |
User experience | ` | ` |
Product marketing | ` | ` |
Operations | ` | ` |
{{#set:Feature products status=`
|Feature products notes=` |Feature engineering status=` |Feature engineering notes=` |Feature security status=` |Feature security health=` |Feature security notes=` |Feature privacy status=` |Feature privacy notes=` |Feature localization status=` |Feature localization notes=` |Feature accessibility status=` |Feature accessibility notes=` |Feature qa status=` |Feature qa notes=` |Feature ux status=` |Feature ux notes=` |Feature product marketing status=` |Feature product marketing notes=` |Feature operations status=` |Feature operations notes=` }}