103
edits
Support:PRD: Difference between revisions
no edit summary
(Taking out no longer relevant content from chat section) |
No edit summary |
||
| (7 intermediate revisions by 3 users not shown) | |||
| Line 39: | Line 39: | ||
The Knowledge base is the back bone of the Firefox support platform. All known issues should be addressed, as best possible, in a user friendly knowledge base article that is easily and quickly accessible to an end-user. | The Knowledge base is the back bone of the Firefox support platform. All known issues should be addressed, as best possible, in a user friendly knowledge base article that is easily and quickly accessible to an end-user. | ||
== | == Content Types == | ||
The content of the knowledge base are split up in the following two major categories: | |||
=== Help === | |||
Help translates to "articles about things you can do with just Firefox", like adding a bookmark, using a keyboard shortcut, or similar. Articles under the Help category should be searchable from the Firefox built-in help window, as well as the SUMO web site. See '''Support''' below for what Help is ''not'' about. | |||
* '''Reference charts:''' Reference charts are points of reference, that list all possible user-oriented options, like keyboard shortcuts, menu reference, command-line options, etc. | |||
* '''Tutorials:''' Tutorials will take a feature of Firefox, and explain the very basics on how to get started using it. More advanced elements of a feature should not be included in a feature tutorial. | |||
* '''How To's:''' How To's answer specific questions, regarding the use of Firefox, which could involve a part of a feature, or several features. | |||
=== Support === | |||
Support translates to "articles about fixing problems in Firefox that require more than just Firefox, or highly technical stuff that should not be exposed to users of the built-in help". For example, how to move a profile folder, or how to configure Norton firewall to not block Firefox. | |||
* '''Troubleshooting:''' This is the content that is more generally associated with “support” that helps users solve problems they have with Firefox. The troubleshooting section will initially be populated with MozillaZine Knowledge Base content that will be organized in a tagging structure that incorporated most frequently accessed questions data. KB style guides will allow for most user friendly help content and will evolve to include visuals. | |||
== Content Creation == | == Content Creation == | ||
| Line 51: | Line 60: | ||
New documents | === New documents === | ||
Volunteer writes documents and assigns priority for editor review | Volunteer writes documents and assigns priority for editor review | ||
| Line 57: | Line 66: | ||
Articles are required to be reviewed, before going live. As our community grows, and we have more reviewers, we will have two separate editorial approval processes: content and style (content can be published initially if correct, even if not style guide needs to be implemented) | Articles are required to be reviewed, before going live. As our community grows, and we have more reviewers, we will have two separate editorial approval processes: content and style (content can be published initially if correct, even if not style guide needs to be implemented) | ||
Existing documents / edits | New articles will initially existing in a staging area, where it can be reviewed and edited, before being visible to people not logged in. Once approved for visibility to the general public, the reviewer will move the article from the staging area to the public knowledge base. | ||
=== Existing documents / edits === | |||
Minor (spelling, grammar, etc): Push live | Minor (spelling, grammar, etc): Push live | ||
| Line 63: | Line 74: | ||
Major: Same review as new documents | Major: Same review as new documents | ||
All edits need to be made on a staging copy of the article. Once an edit is made, the edit is tagged for review. Contiguous edits by the same contributor will be treated as one edit. Anyone with given permission, can either approve or reject the edit. Once approved, the edit is applied to the KB version of the article. If the editor has reviewer permission, their own edit is automatically approved. Approvals and rejections are done on an edit-by-edit basis; so if there has been more than one edit to a staging copy, each edit has to be approved or rejected. | |||
=== Style Guide === | |||
All Firefox support documents should be written for an audience of a slightly below average internet user (doesn’t read blogs—or at least wouldn’t know one if he saw one) and take the tone of a friendly, helpful community volunteer. | |||
*Develop style guide for How To’s and for Troubleshooting docs | *Develop style guide for How To’s and for Troubleshooting docs | ||
** include requirements for any visuals (screenshots, flash/video, etc) | ** include requirements for any visuals (screenshots, flash/video, etc) | ||
Feedback system | === Feedback system === | ||
All articles will have a poll system to determine if the article is useful to users. Users are strongly encouraged to add comments on why something was not helpful, or what information would help them answer the question. | |||
Recognition of volunteers | === Recognition of volunteers === | ||
If user writes highly-rated article, we want to recognize their success by giving them more power to edit articles without review, and automatically approve articles they have reviewed. | |||
==Technical requirements== | ==Technical requirements== | ||
This summarizes our technical requirements for the knowledge base: | This summarizes our technical requirements for the knowledge base: | ||
* Permission to make live edits to live articles should be restricted to those who have already earned our trust. There should never be incorrect information in Firefox Support KB articles. | |||
** Registered users should still be able to submit edits, either to bugs, or by editing a trunk version of the article, which is going to be tricky to make contributor-friendly. [https://bugzilla.mozilla.org/show_bug.cgi?id=392513] | |||
* Need way of knowing which staging copies are not same as live copy. [https://bugzilla.mozilla.org/show_bug.cgi?id=401916] | |||
* Approve and Reject buttons for reviewing article edits. [https://bugzilla.mozilla.org/show_bug.cgi?id=402884] | |||
** If the editor has reviewer permission, their own edit is automatically approved. [https://bugzilla.mozilla.org/show_bug.cgi?id=403869] | |||
** Approving edits should add the contributor credit to the live article. [https://bugzilla.mozilla.org/show_bug.cgi?id=401917] | |||
* If a page doesn't exist for the requested locale, TikiWiki should fallback according to the http accept-language header if not logged in, or according to the user preferences if logged in. [https://bugzilla.mozilla.org/show_bug.cgi?id=398353] | * If a page doesn't exist for the requested locale, TikiWiki should fallback according to the http accept-language header if not logged in, or according to the user preferences if logged in. [https://bugzilla.mozilla.org/show_bug.cgi?id=398353] | ||
** If a page doesn't exist for the requested locale, a box should appear at the beginning of the article explaining that the page is not yet translated to the requested language. [https://bugzilla.mozilla.org/show_bug.cgi?id=398354] | ** If a page doesn't exist for the requested locale, a box should appear at the beginning of the article explaining that the page is not yet translated to the requested language. [https://bugzilla.mozilla.org/show_bug.cgi?id=398354] | ||
* Need a way of tracking article requests/status without using Bugzilla. [https://bugzilla.mozilla.org/show_bug.cgi?id=398760] | * Need a way of tracking article requests/status without using Bugzilla. [https://bugzilla.mozilla.org/show_bug.cgi?id=398760] | ||
| Line 179: | Line 204: | ||
* Threads they've posted in. | * Threads they've posted in. | ||
* Threads via arbitrary criteria (advanced search). | * Threads via arbitrary criteria (advanced search). | ||
* Threads where the user is still looking for help. Allow end users to mark their question as answered and provide a filter for contributors based on this info. This could be extended to say which post answered the question, which could tie into a contributor rating feedback mechanism. | * Threads where the user is still looking for help. | ||
** Allow end users to mark their question as answered and provide a filter for contributors based on this info. This could be extended to say which post answered the question, which could tie into a contributor rating feedback mechanism. | |||
** Threads with no replies | |||
** Threads where the last poster is (not) a contributor | |||
==Helping contributors help users== | ==Helping contributors help users== | ||
| Line 208: | Line 236: | ||
* Wiki syntax [https://bugzilla.mozilla.org/show_bug.cgi?id=396578] (FIXED) | * Wiki syntax [https://bugzilla.mozilla.org/show_bug.cgi?id=396578] (FIXED) | ||
* Create a contributors' forum (FIXED) | * Create a contributors' forum (FIXED) | ||
* Threads with no replies [https://bugzilla.mozilla.org/show_bug.cgi?id=416477] | |||
* Threads with last contributor response [https://bugzilla.mozilla.org/show_bug.cgi?id=422000] | |||
* Feed for a thread [https://bugzilla.mozilla.org/show_bug.cgi?id=422001] | |||
= Chat requirements = | = Chat requirements = | ||
| Line 213: | Line 244: | ||
Live chat will be an easy to use real time communication channel for users who can’t find answers to their questions in the knowledge base and forums. Through a web interface (no download required), users will chat with community volunteers who will be using the OpenFire application. | Live chat will be an easy to use real time communication channel for users who can’t find answers to their questions in the knowledge base and forums. Through a web interface (no download required), users will chat with community volunteers who will be using the OpenFire application. | ||
==End-User Interface== | |||
*Users should be able to access the live chat from the browser, with no download initially. | *Users should be able to access the live chat from the browser, with no download initially. | ||
*Users should be prompted to ask a question or tell their problem before initiating the live chat (possibly some segmentation from a drop down menu). | *Users should be prompted to ask a question or tell their problem before initiating the live chat (possibly some segmentation from a drop down menu). | ||
| Line 219: | Line 250: | ||
*Interface should also include statements e.g.: “Don't give out personal info” (credit cards, usernames, passwords, etc). | *Interface should also include statements e.g.: “Don't give out personal info” (credit cards, usernames, passwords, etc). | ||
==Functionality:== | |||
* Ability to push screenshots to users during chat session | * Ability to push screenshots to users during chat session | ||
** Way to get screenshots from users | ** Way to get screenshots from users | ||