Feature Creep
Status
| Feature Creep | |
| Stage | Draft |
| Status | ` |
| Release target | ` |
| Health | OK |
| Status note | ` |
{{#set:Feature name=Feature Creep
|Feature stage=Draft |Feature status=` |Feature version=` |Feature health=OK |Feature status note=` }}
Team
| Product manager | Jeff Griffiths |
| Directly Responsible Individual | ` |
| Lead engineer | Shane Caraveo |
| Security lead | ` |
| Privacy lead | ` |
| Localization lead | ` |
| Accessibility lead | ` |
| QA lead | ` |
| UX lead | Brian Clark |
| Product marketing lead | ` |
| Operations lead | ` |
| Additional members | ` |
{{#set:Feature product manager=Jeff Griffiths
|Feature feature manager=` |Feature lead engineer=Shane Caraveo |Feature security lead=` |Feature privacy lead=` |Feature localization lead=` |Feature accessibility lead=` |Feature qa lead=` |Feature ux lead=Brian Clark |Feature product marketing lead=` |Feature operations lead=` |Feature additional members=` }}
Open issues/risks
`
Stage 1: Definition
1. Feature overview
Feature Creep is a new way to de-couple feature experimentation from the train model and illicit feedback from Firefox Release or Beta users about experimental features or feature prototypes in a fun way via add-ons.
2. Users & use cases
Mozilla Developers: teams that are working on new features that involve changes to UX need an efficient way to access a broad spectrum of users for feedback.
End Users: enthusiasts may be interested in accessing and providing feedback on upcoming Firefox features or experiments that are meant to improve the appearance or usefulness of Firefox, without the need to install nightly builds.
3. Dependencies
- AMO api for accessing add-ons in a collection.
- Telemetry and/or other analytics systems that we can use to collect usage data from opted-in users.
4. Requirements
`
Non-goals
This hsould not be a distribution channel for bugfix back-ports.
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=Feature Creep is a new way to de-couple feature experimentation from the train model and illicit feedback from Firefox Release or Beta users about experimental features or feature prototypes in a fun way via add-ons. |Feature users and use cases=Mozilla Developers: teams that are working on new features that involve changes to UX need an efficient way to access a broad spectrum of users for feedback.
End Users: enthusiasts may be interested in accessing and providing feedback on upcoming Firefox features or experiments that are meant to improve the appearance or usefulness of Firefox, without the need to install nightly builds. |Feature dependencies=* AMO api for accessing add-ons in a collection.
- Telemetry and/or other analytics systems that we can use to collect usage data from opted-in users.
|Feature requirements=` |Feature non-goals=This hsould not be a distribution channel for bugfix back-ports. |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 | Unprioritized |
| Rank | 999 |
| Theme / Goal | ` |
| Roadmap | ` |
| Secondary roadmap | ` |
| Feature list | ` |
| Project | ` |
| Engineering team | ` |
{{#set:Feature priority=Unprioritized
|Feature rank=999 |Feature theme=` |Feature roadmap=` |Feature secondary roadmap=` |Feature list=` |Feature project=` |Feature engineering team=` }}
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=` }}
Problem: people working on Firefox features have difficulty getting user feedback if they ride the train model. The Nightly and Aurora channels don't get the right set of users exposure.
Solution: create a channel through which people can opt in to and try out new features that have been implemented as add-ons. Some examples:
- add-ons that implement proposed UX changes
* socialAPI prototypes
* Panorama 2
The most sensible comparison I can think of would be Google's 'labs' capability for adding advanced or obscure capabilities to their websites.
The particularly important distinctions between this concept and pointing people to Firefox Nightly are:
- audience / exposure. Feature Creep would install into the current release of Firefox.
* features, not bug fixes.
Some sketchy implementation details:
The feature would be implemented as an add-on that provides an about:addons-style listing of feature prototypes to try out.
The add-ons presented to the user would be a collection on AMO ( eg we would use existing infrastructure with few tweaks ) curated by Mozilla.
The 'Feature Creep' add-on could also be instrumented to provide additional metrics about user behaviour when using new / prototyped features.