Firefox Support Knowledge Base Contributor Communication Requirements Document
Right now, knowledge base contributors have at least three major venues to discuss the content of any particular article.
- Bugzilla, for requesting articles, triaging those requests, and drafting them for the knowledge base.
- Article comments on staging copies, for discussing issues about each individual article after the article has been moved to the KB.
- The Contributors forum, for any discussion about contributing to Firefox Support.
In addition to following discussions in three different places, it also requires subscribing to each individual staging copy, and CCing one's self to individual bugs. Knowing the history of past discussions about an article can be hard to find; and most of all, requesting an article requires an account outside of SUMO.
We would like to centralize communication among KB contributors with a system that makes it easy to become aware of article requests, easy to get involved in discussions, and easy to track those discussions. This would be done by creating a forum specific to KB article discussion, with one thread per-article.
For now, this only applies to the en-US knowledge base.
- All of our article requests have been English-only; and any requests for non-English articles should go through us anyway.
How it is different
Similar to threads having an unsolved and solved status, the threads in this forum would have thread statuses that would be applied to a KB article.
- Proposed - When an article is requested, but not triaged.
- Already exists - When an article request is a duplicate of another article request.
- Needs draft - When an article request has been triaged, but not drafted.
- Ready for review - When an article has been drafted, and is waiting for review to be moved to the knowledge base.
- In the Knowledge Base - When the article has been reviewed and moved to the knowledge base.
Feeds to/from staging copies
Instead of having article comments on staging copies separate from forums, the corresponding article threads in this new forum will be fed to each staging copy. For example, the posts in the thread for the Private Browsing article would appear in the comments area of the *Private Browsing article, and vice versa.
Whenever someone edits an article, the edit summary with a link to the diff would be posted in the thread for that article. We can use the same text as email notifications:
The page *Closing the only tab closes the window was changed by Bo at Tuesday 18 of August, 2009 18:50 PST.
Comment: Ctrl and Cmd and such
- Forum Name: KB articles
- Summary: Individual article requests and discussion
- Section: sub-forum of Contributors forum
- Moderator group: Approvers
- Anonymous tiki_p_forum_read
- Approvers tiki_p_forum_post_topic
- Contributors tiki_p_forum_post_topic
- Forum Moderators tiki_p_forum_post_topic
- Locale leaders tiki_p_forum_post_topic
- Registered tiki_p_forums_report
- Registered tiki_p_forum_attach
- Registered tiki_p_forum_edit_own_posts
- Registered tiki_p_forum_post
- Registered tiki_p_forum_read
- System Admins tiki_p_forum_post_topic
- Thread titles are named after the article, and the description is text from the latest post in the thread.
- Instead of "Ask a new Question" to start a thread, label should be "Propose new Knowledge Base article"
- Take the thread reply template, and remove the text telling users to start a new thread.
- Instead of setting the reply type, that drop-down can be used to set the thread status.
- this needs more changes:
- "Post new message" should probably read "Post new article request"
- Need a top banner of the forum thread view that instructs the visitor on how to use the forum, e.g. a button to "Propose new Knowledge Base article"
- The thread list view should be able to indicate the status of each article, with clear action links for e.g. "Review article", "Create draft", and so on.
- More stuff?