Support:PRD: Difference between revisions

1,714 bytes added ,  11 March 2008
no edit summary
No edit summary
 
(4 intermediate revisions by 3 users not shown)
Line 60: 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 66: 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 72: 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 ===


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.
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: 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.
=== 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: 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.
=== 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]  
* 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 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 188: 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 217: 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 222: 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:'''
==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 228: 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:''' 
==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
103

edits