Support/Firefox Features/Clean up user profile/v2
Status
Automatically Fix User Profile | |
Stage | Stage II |
Version | TBD |
Health | Ok |
Status note | Need to set up a meeting with Alex Limi and Dave Townsend |
Team
Product Manager | |
Feature Manager | Michael Verdi |
Lead Developer | Dave Townsend |
Security | |
Privacy | |
Localization | |
Accessibility | |
Quality assurance | George Carstoiu (irc: GeorgeCarstoiu) |
User experience | Alex Limi |
- Feel free to list other team members below the table here.
Open issues/risks
- Using the installer to do this is not a good idea but the process could be triggered in the installation process
- How could this work on OS X and Linux since they don't have the same install process as Windows?
- There is a plan to remove the Profile Manager UI (Bug 214675) and add an external Profile Manager application (Bug 539524). This solution is fine from a testing point of view but for the user who is just trying to fix Firefox this will complicate an already difficult process. Our feature would make the removal of the profile manager ui irrelevant from the user's point of view.
Stage I: Definition
1. Feature overview
We should provide some way for users to automatically fix Firefox by fixing their profile while retaining their data (bookmarks, history, passwords, etc). There are a number of serious Firefox issues (not starting, crashing, unexpected behavior, lost toolbars and more) that can be solved by fixing the user's profile. The problem is, fixing a profile is an incredibly difficult task – see these two articles (1, 2) for complete steps. Many users try to reinstall Firefox to solve these issues but reinstallation doesn't do anything to the profile folder. Providing this option on installation could make it both intuitive and discoverable.
2. Users & use cases
The goal is to take a difficult and confusing repair process that most people never discover (and often need one on one help to complete when they do find it) and turn it into an easy and discoverable operation that can be done without guidance.
Example:
A user determines that "something" is wrong with Firefox, so they attempt to fix it by reinstalling. The installation process should afford some mechanism for the user to repair Firefox (by repairing/creating a new profile and retaining the user data).
3. Dependencies
Defining giver dependencies and taker dependencies so you know who owes to whom what and when.
4. Requirements
- Easy to use
- Easy to discover (Ideally the user shouldn't have to go to SUMO to figure this out)
Non-goals
- A Clean Install is another repair process that is not covered by this 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. |
- Property "Roadmap" (as page type) with input value "whichever Roadmap this Feature is from, or set by Prod Mgr" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
- Property "Secondary roadmap" (as page type) with input value "{{{secondary roadmap}}}" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
- ""Desktop", "Mobile", "Platform", "Services", or "Other"" is not in the list (`, BYOB, Desktop, Marketplace, Mobile, Platform, Plugin Directory, Services, Thunderbird, Jetpack, ...) of allowed values for the "Feature list" property.
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 |
Revision history
date | author | change |
2011/06/16 | Michael Verdi | Updating to new feature page format. |