Support/Firefox Features/Clean up user profile/v2
Status
| Feature Name | |
| Stage | Stage II |
| Version | TBD |
| Health | [ON TRACK] {{{1}}} |
| Status note | A quick note about current status/stage or next steps required to progress. |
{{#set: |feature name = Feature Name |stage = Stage II |version = TBD |health = [ON TRACK] {{{1}}} |status = A quick note about current status/stage or next steps required to progress. }}
Team
| Product Manager | |
| Feature Manager | |
| Lead Developer | |
| Security | |
| Privacy | |
| Localization | |
| Accessibility | |
| Quality assurance | |
| User experience |
{{#set: | product manager = | feature manager = | lead developer = | security = | privacy = | localization = | accessibility = | qa = | ux = }}
- Feel free to list other team members below the table here.
Open issues/risks
List
Stage I: Definition
1. Feature overview
Required Overview description of the feature, motivation for the feature, goals, why it's important.
2. Users & use cases
Required A clear definition of the target users/audience and the use cases that we want to support, for either end-users or developers.
3. Dependencies
Defining giver dependencies and taker dependencies so you know who owes to whom what and when.
4. Requirements
A list of things that the feature should do (must-haves and nice-to-haves) for users and/or developers. This should not include implementation decisions or options, but should include performance/latency/SLA/responsiveness requirements.
Non-goals
Optional - things we're specifically not trying to do with this particular iteration of a feature.
Stage II: Design
5. Functional specification
What the feature will do to satisfy the requirements, in written form.
6. User experience design
Designs, interactions, etc., mainly in visual form, if relevant.
Stage III: Planning
7. Implementation plan
Summary of the high-level approach to be taken
8. Security
Are there security risks; has the design been reviewed; what needs to be changed before we proceed?
9. Privacy
Are there privacy risks; has the design been reviewed; what needs to be changed before we proceed?
Stage IV: Development
10. Implementation
Links to bugs -- we don't try to track the detailed progress here, that should happen in bugzilla.
Stage V: Release
11. Landing criteria
Final checklist for everything the feature team feels should happen before a feature can land -- could be a scalability model, security code review, etc. Will eventually develop a standard table for this.
Feature details
| Priority | "unprioritized", "P1", "P2", "P3" |
| Roadmap | whichever Roadmap this Feature is from, or set by Prod Mgr |
| Secondary Roadmap | {{{secondary roadmap}}} |
| Feature List | "Desktop", "Mobile", "Platform", "Services", or "Other" |
| Engineering Team | Engineering team who will be doing primary development. |
{{#set: |priority = "unprioritized", "P1", "P2", "P3" |roadmap = whichever Roadmap this Feature is from, or set by Prod Mgr |secondary roadmap = {{{secondary roadmap}}} |feature list = "Desktop", "Mobile", "Platform", "Services", or "Other" |team = Engineering team who will be doing primary development. }}
Team status notes
Teams are welcome to use these fields however they see fit. Both fields can be used in queries to generate lists on other wiki pages. If you would like help or have questions, please contact Deb.
| status | notes | |
| Products | ||
| Engineering | ||
| Security | ||
| Privacy | ||
| Localization | ||
| Accessibility | ||
| Quality assurance | ||
| User experience |
{{#set: | product-status = | product-note = | security-status = | security-note = | privacy-status = | privacy-note = | localization-status = | localization-note = | accessibility-status = | accessibility-note = | qa-status = | qa-note = | ux-status = | ux-note = }}
Revision history
| date | author | change |
| YYYY/MM/DD | Your Name Here | Initial feature proposal. |