Feedback Dashboard/Phase 2

This document describes the Feature Requirements for Phase 2 of the Feedback Dashboard. The main goal of phase 2 is provide a method for experienced editors to respond to the Moodbar comments left by new editors.

Objective
To provide an easy way for experienced editors to respond to Moodbar comments left by new editors. This interaction will hopefully help resolve some of the frustrations of new editors. We also hypothesize that direct interaction with experienced community members will have a welcoming effect and contribute to a higher level of editor retention among new editors.

Use cases

 * Experienced editor sees a comment on the Feedback Dashboard and would like to help the new editor by responding to the comment.
 * New editor who leaves a Moodbar comment receives a response from an experienced community member.

Feature Requirements
This is a draft, subject to revision.

Experienced editors should be able to respond to a comment in the Feedback Dashboard, which leaves a message on the new editor's talk page.

Mechanism for replying to Moodbar Comment
 * Experience editor should be able to respond to a comment in-line.
 * Reply should reference original feedback comment (including permalink)
 * Reply form should offer experience editor the ability to add user's talk to watchlist (e.g., check to add to watchlist)
 * We may enable this checkbox via user preference. E.g.,
 * If preference is set, checkbox appears, but editor still has discretion to add to watchlist on case-by-case basis
 * If preference is not set, checkbox never appears
 * Upon submission, the reply is posted to the new editor's talk page.
 * Talk page message has link back to original discussion message
 * Feedback dashboard indicates that there is a reply to the Moodbar comment, with a link to the response.
 * Open issues:
 * What happens when original Moodbar comment is hidden?
 * What happens when reply is removed from the talk page?
 * Initial thought is to make sure comments are not duplicated (e.g., comment exists both on the dashboard and on the talk page). We should think through the more detailed use cases to confirm this is the appropriate behavior.

Replying to a reply
 * If a new editor wants to respond to a Moodbar comment, he may do so by editing his own talk page.
 * Alternatively, he, or any other editor, may respond again on the Feedback dashboard
 * Multiple responses will not be threaded (i.e., there will be only two levels: the original comment and the replies to the comment)

Notification
 * When a new editor receives a response, they will receive an email (if there is an email address associated with their account). This email will include:
 * Original Comment
 * The fact that a user replied, including the username and time of reply
 * Text of reply (only most recent reply in the case of multiple replies)
 * Link to the reply on the user's talk page
 * Brief explanation of what a talk page is
 * Open issue: if a user doesn't have an email address associated with their account, should we ask them to submit an email address/create an account upon submission of comment?

Increasing Visibility of Moodbar
 * Introduce bubble upon first display of Moodbar invitation (to help ensure new editors see invitation to comment on their experience). Bubble disappears automatically and never reappears.
 * Further A/B testing of invitation
 * Integration of Moodbar invitation into workflow (future)

Improvements on Phase 1 (not in order of priority)
 * Suppress blank comments Require user to leave comment
 * Turn off A/B testing (for now), focusing on the invitation with the highest conversion (Feedback about editing)
 * Stats: Include basic stats at top of page (e.g., total number of Happy, Sad, Confused in past 24 hours, total number with comments)
 * Redlinked users: Users without userpages should appear as redlinks
 * Navigation pop-ups: Hovering over a user should give their edit summary (similar to current NavPop-up)
 * Administrative hiding:
 * Should enable admin to include a reason (Andrew Garrett's original feature, but implemented in a more intuitive fashion)
 * Should indicate the admin who performed the hide action and the timestamp when it was hidden (Bugzilla 32110)
 * Usability Issues
 * Filter textbox overflow (Bugzilla 32109)
 * Interaction issues: flickering when filters are active -- First loads result-set without filters, then spinner loads and renders filtered version. Should immediately render the filtered version.
 * Error while fetching more results
 * Other items
 * More clarity in language of Moodbar dialog
 * Tracking of experienced editor behavior to determine who's most helpful, responsive, etc.

Alternative method for reply system

 * An alternative method for replies is to contain the entire discussion on the Feedback dashboard page.
 * The benefit of this is that we would have the opportunity to use a structured discussion system to manage the discussion.
 * The downsides are that:
 * We lose the opportunity to educate the new user on the Talk page.
 * Other experienced editors (other than the one leaving the comment) are likely to look at the new editor's talk page to get a sense of what their editing experience is (e.g., what areas they need help on). It is helpful to have all these discussion on the user's talk page because this is likely where experienced editors to get an understanding of the new user.