Features/Firefox/PluginCrashComments: Difference between revisions

no edit summary
No edit summary
No edit summary
 
(11 intermediate revisions by 4 users not shown)
Line 1: Line 1:
Once you have created your Feature page, please remove this paragraph and link to your page from the [[Features/Inbox|Features Inbox]], where a team will triage it and move it into the appropriate [[Features|Feature list]]. If you have any questions, please contact [[User:Dria|Deb]].
{{FeatureStatus
|Feature name=Plugin crash comments
|Feature stage=Planning
|Feature health=OK
}}
{{FeatureTeam
|Feature product manager=Asa Dotzler
|Feature feature manager=Sheila Mooney
|Feature qa lead=Vlad Ghetiu (irc: vladg)
|Feature ux lead=Jennifer Boriss
}}
{{FeaturePageBody
|Feature open issues and risks=Need to get this feature prioritized and an owner for the implementation.
|Feature overview=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 so any additional data is helpful.


{| class="fullwidth-table"
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.
|-
| style="font-weight: bold; background: #DDD;" | Feature
| style="font-weight: bold; background: #DDD;" | Status
| style="font-weight: bold; background: #DDD;" | ETA
| style="font-weight: bold; background: #DDD;" | Owner
|-
<section begin="status" />
| [[Adding Comments to Plugin Crashes]]
| {{StatusHealthy|status=One or two sentence status report.}}
| YYYY-MM-DD
| Owner Name
<section end="status" />
|-
|}


== Summary ==
Another side benefit of getting this implemented is Electrolysis. We will want to enable users to submit comments when the content process crashes.
Succinct summary of the feature.
|Feature ux design=Design details and mockups can be found in [https://bugzilla.mozilla.org/show_bug.cgi?id=648675 Bug 648675].
 
|Feature implementation notes=We are currently tracking this feature in [https://bugzilla.mozilla.org/show_bug.cgi?id=648675 Bug 648675].
== Team ==
}}
Who's working on this?
{{FeatureInfo
 
|Feature priority=P2
* '''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 roadmap=Plugin Interactions
* '''Lead Developer''':
|Feature list=Desktop
* '''Product Manager''':
|Feature engineering team=Desktop front-end
* '''QA''':
}}
* '''UX''':
{{FeatureTeamStatus}}
* '''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.
 
== 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.
 
== 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) ==
{| class="fullwidth-table"
|-
| {{StatusHealthy|status=&nbsp;}}
| Healthy: feature is progressing as expected.
|-
| {{StatusBlocked|status=&nbsp;}}
| Blocked: feature is currently blocked.
|-
| {{StatusAtRisk|status=&nbsp;}}
| 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.
|}
 
__NOTOC__
 
Please remove this line and any non-relevant categories below.  Add whatever other categories you feel are appropriate.
 
[[Category:Features]]
[[Category:Firefox]]
[[Category:Platform]]
[[Category:Services]]
[[Category:Mobile]]
[[Category:Other]]
canmove, Confirmed users, Bureaucrats and Sysops emeriti
496

edits