Features/Firefox/PluginCrashComments: Difference between revisions

Revision as of 22:26, 6 May 2011

Once you have created your Feature page, please remove this paragraph and link to your page from the Features Inbox, where a team will triage it and move it into the appropriate Feature list. If you have any questions, please contact Deb.

Feature	Status	ETA	Owner
PluginCrashComments	One or two sentence status report.	YYYY-MM-DD	Owner Name

Summary

Today, if a plugin crashes, the user is prompted to submit a crash report. However, they are not provided with an interface for entering a comment alongside the crash report as they can with other types of crashes. Although comments are optional and we rely on the users ability to give us informed information about what they are doing at the time of the crash, they are another piece of data that can assist us in diagnosing a problem. Plugin crashes are particularly difficult to analyze.

A recent security study showed a pretty high percentage of users liked the idea of providing comments and crash reports to help improve Firefox. In more than one case during the course of Firefox 4 development, reading the users' comments has lead to the resolution of a serious top crash in the product. For this reason we think this is a pretty important enhancement to get in.

Another side benefit of getting this implemented is Electrolysis. We will want to enable users to submit comments when the content process crashes.

Team

Feature Manager: Sheila Mooney
Lead Developer:
Product Manager:
QA:
UX: Jennifer Boriss
Accessibility:
Security:
Privacy:

Release Requirements

Next Steps & Open Issues

Related Bugs & Dependencies

We are currently tracking this feature in Bug 648675.

Risks

Use Cases

Designs

Design details and mockups can be found in Bug 648675.

Test Plans

Goals

Non-Goals

Other Stuff

Legend (remove if you like)

	Healthy: feature is progressing as expected.
	Blocked: feature is currently blocked.
	At Risk: feature is at risk of missing its targeted release.
ETA	Estimated date for completion of the current feature task. Overall ETA for the feature is the product release date.

Please remove this line and any non-relevant categories below. Add whatever other categories you feel are appropriate.

@@ Line 9: / Line 9: @@
 |-
 <section begin="status" />
-| [[Adding Comments to Plugin Crashes]]
+| [[PluginCrashComments]]
 | {{StatusHealthy|status=One or two sentence status report.}}
 | YYYY-MM-DD
@@ Line 18: / Line 18: @@
 == Summary ==
-Succinct summary of the feature.
+Today, if a plugin crashes, the user is prompted to submit a crash report. However, they are not provided with an interface for entering a comment alongside the crash report as they can with other types of crashes. Although comments are optional and we rely on the users ability to give us informed information about what they are doing at the time of the crash, they are another piece of data that can assist us in diagnosing a problem. Plugin crashes are particularly difficult to analyze.
+A recent security study showed a pretty high percentage of users liked the idea of providing comments and crash reports to help improve Firefox. In more than one case during the course of Firefox 4 development, reading the users' comments has lead to the resolution of a serious top crash in the product. For this reason we think this is a pretty important enhancement to get in.
+Another side benefit of getting this implemented is Electrolysis. We will want to enable users to submit comments when the content process crashes.
 == Team ==
-Who's working on this?
-* '''Feature Manager''': ''whoever is responsible for doing the day-to-day work of driving the feature to completion and updating the status on this page''
+* '''Feature Manager''': Sheila Mooney
 * '''Lead Developer''':
 * '''Product Manager''':
 * '''QA''':
-* '''UX''':
+* '''UX''': Jennifer Boriss
 * '''Accessibility''':
 * '''Security''':
 * '''Privacy''':
-* Etc.
-Team list should make it clear who to ask about what, and who to ping when they're needed.  If you do not need someone in a particular role (ie: Security), that's fine, just delete that line.  Contact info for each person would also be handy.
 == Release Requirements ==
-Complete checklist of items that need to be satisfied before we can call this feature "done".
 == Next Steps & Open Issues ==
-Either the next set of tasks that need to happen to move this project along, or (ideally) the full list of project tasks/action items with things crossed off as they're finished.  Including the name of who's responsible for each item, and a rough ETA can be useful.
-Open issues include unanswered questions, things that need to be explored, decisions that still need to be made, etc.  Again, including the name of who's responsible for each item can be useful.
 == Related Bugs & Dependencies ==
-Links to the feature tracking bug & other relevant bugs; links to related plans (test plan, product marketing plan, etc.); notes about things that depend on this, etc.
+We are currently tracking this feature in [https://bugzilla.mozilla.org/show_bug.cgi?id=648675 Bug 648675].
 == Risks ==
-Identify, prioritize, track and communicate any risks associated with this feature/project.
 == Use Cases ==
-Everyone loves use cases, so you should provide them if you can (and where it makes sense).  The [[ChannelSwitching/ChannelSwitchingFeature#Use_Cases|Channel Switcher]] Feature Page has some good examples.
 == Designs ==
-Any and all mockups, design specs, tech specs, etc.  Either inline or linked to.
+Design details and mockups can be found in [https://bugzilla.mozilla.org/show_bug.cgi?id=648675 Bug 648675].
 == Test Plans ==
-Any and all test plans and strategies.  Either inline or linked to.
 == Goals ==
-The high level goals for the feature (which the release requirements checklist should fulfill).  These are the guiding light and overall vision for the feature.  Refer to this if there is confusion or are disputes about direction, designs, planning, etc.
 == Non-Goals ==
-Things we are specifically not doing or building as part of this feature.
 == Other Stuff ==
-Can include things like:
-* Competitive landscape
-* Research & references
-* Whatever else is useful to the project.
 == Legend (remove if you like) ==