Article feedback/Version 5/Feature Requirements

From MediaWiki.org
Jump to: navigation, search
View the Article Feedback slides
Watch this quick video tour of Article Feedback
Option 1: Feedback - An early design for Version 5 of the Article Feedback Tool

This page describes new features under development for the Article Feedback Tool Version 5 (AFT V5), from Oct. 2011 to August 2012. (See sample feedback forms on the right)

See also: project overview page, useful links, as well as technical design page, data and metrics plan and our live metrics dashboard.

Contents

Overview[edit | edit source]

Article Feedback Map
Article Feedback Touchpoints

Key features for AFT V5 include:

  • feedback forms
  • calls to action
  • feedback page
  • monitoring tools

For an overview of how these features work together, check the article feedback map (see thumbnail to the right). In phase 1.0 of this project (Dec.-Feb. 2011), we created and tested three different types of feedback forms, described below. Test results showed a slight overall preference for Option 1 (even though the other two options were also found useful). For that reason, we plan to optimize our overall design for Option 1 in the next phase of development. To learn more, read our report on the Wikimedia blog.

In the next phases of this project, we developed and tested these additional features:

Other features under consideration for later development are outlined below.

For a preview of what these forms and pages look like, read below, or check our project slides.

Feedback forms[edit | edit source]

Final Feedback Form (Option 6)[edit | edit source]

Final Feedback Form

We have developed a final version of the article feedback form (based on Option 1, as described below), to be more intuitive for the user and take less real estate on the page, while still supporting the basic functions which it now provides (see workflow diagram to the right). To that end, this new feedback form progressively reveals the current feedback form content in these 3 incremental steps:

  • Step 1: Simple Question
  • Step 2: Add a comment
  • Step 3: Thanks + Call to Action

We aim to increase both the visibility of the form and the continuity of its experience, on the assumption that it may only appear at the bottom of the page in most cases. See wireframe prototype.

Collapsed Form (step 1)

Final Feedback Form - Option 6, Step 1 - Mockup

We are developing a simple 'expandable form' -- roughly the same Option 1 form described below, but only showing the top half by default (collapsed state), as outlined below:

Help improve this page < What's this? >

Did you find what you were looking for? [ Yes ] [ No ]

When you click on the Yes or No buttons, we will simply expand the rest of the form to reveal its contents:

  • text box (3 lines) with current prompts
  • links to guidelines and legal terms
  • 'Post your feedback button

Expanded Form (Step 2)

Final Feedback Form - Option 6, Step 2 - Mockup

The expanded form would look something like this:

Help improve this page < What's this? >

Great. Would you like to add anything else? [if the user answered 'Yes']

OR:

Sorry about that. How can we make it better for you? [if the user answered 'No']

[ Text box (3 lines) with current prompts:

• Yes: "What was most useful to you? How could this article be improved?" OR

• No: 'What's missing? Any suggestions for improvement?' ]

Please post <helpful feedback>. By posting, you agree to transparency under these <terms>.

[ Post your feedback ]

This form also includes a 'go back' icon next to the title to take you back to step 1, as well as displays the number of remaining characters above the text box.

Thank you CTA (Step 3)

Final Feedback Form - Option 6, Step 4 - Mockup

We will display different calls to action (CTA), which are outlined in the next section. It is likely that we will rotate between 3 different CTAs, such as CTA1 (Edit this page), CTA2 (Learn more - if the page is protected), CTA3 (Take a survey), CTA4 (Sign up or Log in) and CTA5 (View feedback).

For example, here is updated text copy for CTA 1:

Thanks! Your feedback has been <posted here>. < What's this? >

Did you know that you can edit this page? Wikipedia works because anyone can edit its articles. Go ahead, give it a try. Be bold!

[ Edit this page ]

This approach makes the form more visible from the start, with a bold 'Improve this page' title that grabs your eye and gives more purpose to the question on the second line below. It also provides continuity by keeping the same title throughout the experience, from the initial feedback link to the question screen 1 and comment screen 2. It also seems to be a practical solution from a development standpoint, as it doesn't force us to rebuild the form from scratch.

Help Tool Tip[edit | edit source]

Help Tool Tip

When you click on the question mark icon on any of the forms, you get a small tooltip that will link to the upcoming AFTv5 help page.

Here is the updated text copy for this tool tip:

"What's this?

Wikipedia would like to hear what you think of this article. Share your feedback with the editors -- and help improve this page.

Learn more >>"

'Learn more' should link to the help page URL that matches your appropriate user group, as so:

  • Article Feedback Help for Readers

http://en.wikipedia.org/wiki/Wikipedia:Article_Feedback/Help/

  • Article Feedback Help for Editors

http://en.wikipedia.org/wiki/Wikipedia:Article_Feedback/Help/Editors

  • Article Feedback Help for Monitors

http://en.wikipedia.org/wiki/Wikipedia:Article_Feedback/Help/Monitors

  • Article Feedback Help for Oversighters

http://en.wikipedia.org/wiki/Wikipedia:Article_Feedback/Help/Oversighters

The same context-sensitive help URLs will be used behind every other help link, from the question mark icon to the help link at the top of the feedback page.

Earlier feedback forms (Options 1-3)[edit | edit source]

In phase 1.0 of this project (Dec.-Feb. 2011), we created and tested three different types of feedback forms, described below:

We tested these options against each other, to find out which is most effective for engaging readers, supporting editors and improving article quality (see data and metrics page). The feedback form interface appeared on every article selected for our phase 1 test, as the current AFT4 does now on the rest of the English Wikipedia (unless disabled in user preferences).

After comparing the results of our various research studies, we observed a slight overall preference for Option 1 (even though the other two options were also found useful). For that reason, we plan to optimize our overall design for Option 1 in the next phase of development. We will keep all other options in mind as we refine that design for the next version of this tool, and will consult with members of our community at each step of the way. To learn more, read our report on the Wikimedia blog.

Option 1[edit | edit source]

Article Feedback Form Option 1 - Mockup

To see this version of the feedback form in action on Wikipedia, click here. (The picture above is a mockup - see also earlier prototype screenshot and wireframe for this feedback tool.)

This feedback form includes these design elements, from top to bottom, left to right:

  • Title: 'Help improve this article' (instead of earlier titles: 'What do you think?' or 'Share your feedback')
  • Help button (link to static page or FAQ with tips on how to give feedback)
  • Question: 'Did you find what you were looking for?'
  • Yes/No Buttons:
    • The yes/no buttons shall have a button appearance, but function as radio buttons.
    • Clicking a yes/no button shall toggle the yes/no switch state, but not submit the form.
    • The yes/no answers shall be stored in a separate field, as well as mapped to 4 and 2 overall ratings
    • Clicking on yes/no buttons will cause a context-sensitive text prompt to appear in the comment box (see below)
  • A comment box (multiline text area)
  • A gray text prompt inside the comment box (after user clicks yes or no, e.g.: 'What's missing? Any suggestions for improvement?' - see below)
  • Small disclaimer text with links:

'Your comment will be shared on this [feedback page]. (phase 1.5)

By posting, you agree to transparency under these [terms]' (phase 1.0)

  • Post button: '[ Post your feedback ]'

Context-sensitive text prompts:

The prompts in the text area are context-sensitive, so you get a different message if you click on Yes, rather than No.

  • Yes: "What did you like most? Share your praise with the editors."
  • No: 'What's missing? Any suggestions for improvement?' (as shown in this wireframe)
  • If neither Yes/No button is selected, do not show text prompt.


  • To give users maximum freedom in option 1, we will allow a user to enter a comment in that form, even if they don't want to click on the Yes or No button. So the 'Post your feedback' button should become blue as soon as the user types in the comments box (instead of forcing them to use the Yes/No buttons).
  • Similarly, a user should have the option to click 'Yes' or 'No' and post without any comments.
  • As soon as a 'Yes' or 'No' button is clicked or a comment is typed, the 'Post your feedback' button will become blue (instead of the default gray).
  • The small legal text at the bottom of all forms will link to this privacy statement (on all forms):

"By posting, you agree to transparency under these <terms>".

foundation‏‎:Feedback_privacy_statement


Option 2[edit | edit source]

Article Feedback Form Option 2 - Dec. 11, 2011

To see this version of the feedback form in action on Wikipedia, click here. (The picture above is a mockup with new face icons from Brandon - see also earlier mockups with color icons, with only one tab selected and with all color hilites.)

This second variation of the feedback form focuses on the text comment and its label (tag).

  • The title of the form shall be "Help improve this article" (used to be context-sensitive)
  • Label selection (default selected is 'suggestion')
  • Comments box (multiline, with different prompt depending on selected label)
  • Post button (caption shall reflect the selected label).
  • Links to the feedback page (1.5) and privacy policy (1.0)

Interface functional details:

  • The labels selection shall function as tags selection, only one can be selected at any time.
  • Selecting a label shall change the default placeholder text for the comments box, only if no text had been entered yet
  • If text had been entered in the comment box, it shall persist through label changes.
  • To further clarify, there is only one text input box.

Context-sensitive text prompts:

The prompts in the text area are context-sensitive, so you get a different message if you click on Suggestion, Praise, Problem or Question.

  • Suggestion: "Make a suggestion! How can this article be improved?"
  • Question: 'Ask a question about this article. '
  • Problem: 'Report a problem. How can this article be improved?'
  • Praise: "What's most useful to you? Share your praise with the editors."

Context-sensitive button labels:

Ideally, we would have different button labels for each type of feedback, if easy to do:

  • "Post your suggestion"
  • "Post your question"
  • "Post your problem"
  • "Post your praise"

If this is hard to do, we will just have the button say: "Post your feedback"

Note: This form design is inspired in part by GetSatisfaction.com.


Option 3[edit | edit source]

Article Feedback Form Option 3

To see this version of the feedback form in action on Wikipedia, click here. This version of the feedback form provides the users with the ability to give an overall rating to the article (see rating functionality above), and a comment. Labels/tags input are not provided on this form. The visual appearance shall be the same as option 1, but have 5-star rating widget instead of the yes/no buttons.

Updated text:

  • Title: 'Help improve this article'
  • Subtitle: 'How would you rate it, overall?'
  • Comments prompt: 'Add a comment. How can this article be improved?'
  • Small text: 'By posting, you agree to transparency under these [terms]'


Option 4[edit | edit source]

Article Feedback Form Option 4

(streamlined mockup for this call to edit.)

This variation will be tested in phase 1.4 and does not provide feedback options. Instead it is a direct call for the readers to edit the article.

  • The "Edit" button takes the reader to the article's edit page.
  • The "learn how to edit" link takes the reader to this New Wikipedia Tutorial].
  • Both registered and anonymous users shall be able to edit the page, as per current Mediawiki functionality.
  • If the article is not editable by the user (according to its protection level), another interface option is to be displayed instead (options 1-3 or 5)
  • If the user has been blocked from editing by Wikipedia, another interface option will be displayed as well.
  • Wikimedia's standard CTA button with arrow is used in this mockup.

Here is the text copy for this option:

"Help improve this article

Did you know that you can edit this page?

Wikipedia works because anyone can edit its articles. Go ahead, give it a try. Be bold!

Learn how to edit >>

Edit this page => "

Option 0[edit | edit source]

The last option we will give to users during our metrics test 3 will be no feedback form at all. (option 0)

Overall Features[edit | edit source]

Overall Functionality

  • During the first testing phase, new feedback forms will only be shown on a subset of articles in the english encyclopedia (e.g.: Obama). They will not be shown for articles that are newly created, or which do not include any significant content, or which include geo-tags.
  • Feedback forms and feedback links will not be shown either if the user has selected to hide the AFT (checked 'Don't show the Article feedback widget' in Preferences > Appearance >)
  • The feedback form option to display shall be selected randomly, as per the current AFT mechanism. See this bucketing flowchart.
  • The "bucketing" mechanism will work as described in this flowchart and the technical design page. It will not be configurable, but should be easily changeable in code.
  • For testing purposes, an override parameter shall be supported in the bucketing mechanism (e.g.: a URL tag specifying which form to show).
  • All feedback forms will be displayed at the bottom of the article pages by default.
  • We are also planning to test three different 'Feedback' text links higher up in the browser window, as described in the #Placement Placement section below. If a user clicks on one of the feedback links described in the Placements section below, the feedback form will be shown as a modal overlay next to the feedback link (or at the very least provide a jump link to the form at the bottom, if overlays cannot be implemented on certain browsers). Overlay forms will include a close 'X' button and the page background will be grayed out.
  • Comments can be as long as 5,000 characters (no countdown will be shown for now, but we will simply not allow the user to type any more text beyond that limit)
  • For returning users (registered & logged in, already provided feedback for this article): the form will be blank, even if you provided feedback earlier. But this text link will be shown: 'See your last post >>' with a link to your last post(s) on the feedback page, sorted by user. Unlike with the AFT v4 form, users will not be able to edit previous feedback.
  • when calculating overall ratings (or yes/no answers), only count the last post rating, not an average of all ratings by that user for that article
  • Feedback forms may not be shown either if a user (or IP address) has been permanently blocked from editing on Wikipedia (exact policy TBD)
  • Anyone can post as many feedback items as they want for a given article (TBD: to prevent spam, do we want to set a limit of 10 posts per user per day?).
  • In phase 2.0, we may also give the users 30 minutes or so to go back and edit their feedback, in case they make a mistake they want to correct. This may be done by adding an edit link next to your posts on the feedback page.

Overall Visual Design

  • For a quick demo of the various options considered for this experiment, see this interactive prototype.
  • The feedback form interface shall follow the Mediawiki style guide, as well as the look and feel of WMF's latest Call to Action assets and buttons.\
  • The 'Post your feedback' buttons will be shown on the left of the form (where it is most likely to be clicked on than on the right).
  • All text prompts in comments to be gray, not black, as commonly done on other sites. The user comments themselves should be black, not gray.
  • A close 'X' button will be shown at the top right corner of all overlay versions of the feedback forms. This close button would not be shown on the bottom versions of the forms, where only the help icon would appear. Both the help and close buttons should be consistent in shape and size, with the '?' and 'X' as the primary differentiators.
  • When a feedback form is shown as a modal overlay, let's gray out the background, as done in the WikiLove feature (but perhaps using a lighter shade of gray).
  • The forms should survive and degrade gracefully in a visual manner within three design styles: Normal web page (580 px minimum, grow horizontally with grace); Tabletized web page (580px); Mobile (max 320 px, give 5 on each side, for 310)
  • All links will be underlined on hover (as per the style guide). External links and links that open in another window shall have an appropriate icon next to them.
  • Feedback forms should also display summary statistics. For Option 1, this could be "% found what they were looking for" and # of total comments.
    • To discuss: Should these statistics should ideally be hidden behind a click so as not to influence the reader (e.g., reader needs to click a "view stats" button)? Or does having the statistics in plain view suggest activity on the site?

Font Sizes:

We will aim to use the following font sizes, with this proposed hierarchy across all forms:

  • Title: 1.4 em / 16 pt (e.g.: 'Help improve this article')
  • Subtitle: 1.2 em / 14 pt (e.g.: 'Did you find what you were looking for?')
  • Button Labels: 1.2 em / 14 pt (e.g.: 'Yes / No', or 'Post your feedback')
  • Comments: 1.0 em / 12 pt (for both gray text prompts -- and for actual user comments)
  • Small text: 0.8 em / 10 pt ('By posting, you agree to transparency under these [terms]')

Note: For final text copy, please refer to the text descriptions above, rather than the graphic wireframes and mockups, which could be out of date.

Throttling[edit | edit source]

To prevent spam, we will throttle all feedback posts to only allow 20 posts per user per hour. If a user exceeds that limit, their post will be disallowed and a message will be shown, saying: "Your post has been rejected because you have recently posted more feedback than recommended in Wikipedia's feedback guidelines. Please do not post feedback repeatedly or excessively."

This feature may be implemented using a cookie, to keep track of when users posts feedback. For example, we may look at the timestamps of the last 20 posts from that user, and reject the post if the first timestamp is less than an hour ago.

(Developer note: due to browser limitations on number and size of cookies, it isn't feasible to track per-article activity using only cookies. So, we changed requirements to be based on site-wide feedback activity and the threshold was increased to 20 posts per hour - that setting configurable via usual method for configuration variables within AFT.)


Calls to Action (CTAs)[edit | edit source]

After readers post their feedback, they will see one of these calls to action (CTAs):

  • CTA 1: edit this article (for unprotected pages only - anyone can edit, even if they are not logged in)
  • CTA 2: learn more (shown to non-editors only, either if the page is protected, or at random)
  • CTA 4: create an account or login (only shown if the user is logged out)
  • CTA 5: see what others are saying (most editors see this this CTA by default, but some readers also occasionally see it at random)
  • CTA 6: Need help editing Wikipedia? (only shown to confirmed editors or higher, this links to Teahouse)

Calls to action that have been discontinued or postponed:

  • CTA 3: take a survey (link to survey page) - this call to action has been discontinued for now, but may be used again
  • CTA 7: get email notifications (if my post is used) - this call to action has been postponed for now

See proposed bucketing plan below.

CTA 1: Edit this page[edit | edit source]

Call to action 1: Edit this page

This 'thank you' confirmation is shown after a user posts feedback, and includes a call to action (CTA). This CTA invites the user to try editing the article they just gave feedback (see earlier mockup for 1.3). We will start the test in December with only this call to edit for phase 1.0, but plan to add more CTAs in phase 1.3.

This a direct call for the readers to edit the article.

  • The "Edit" button takes the reader to the article's edit page.
  • The "learn how to edit" link takes the reader to this New Wikipedia Tutorial].
  • Both registered and anonymous users shall be able to edit the page, as per current Mediawiki functionality.
  • If the article is not editable by the user (according to its protection level), another call to action is to be displayed instead
  • If the user has been blocked from editing by Wikipedia, another interface option will be displayed as well.

Here is the text copy for this CTA:

{checkmark} Thanks! Your feedback has been <saved>.

Did you know that you can edit this page?

Wikipedia works because anyone can edit its articles. Go ahead, give it a try. Be bold!

Edit this page =>

View Feedback Page >>

Learn how to edit >>

  • The "learn how to edit" link takes the reader to the Wikipedia Tutorial:
  • Wikimedia's standard CTA button with arrow is used in the above mockup, which uses small versions of the button and arrow graphics.

CTA 2: Learn more[edit | edit source]

Call to action: Learn more

This a call to action for readers who can't edit this article -- to learn how they can contribute to Wikipedia.

This 'thank you' confirmation is shown after a user posts feedback on a page that is protected or semi-protected. It includes a call to action (CTA) that invites the user to learn more about improving Wikipedia. In phase 1.0, this CTA will be shown when a user cannot edit the page they gave feedback on, because it is protected (instead of showing the call to edit this article). More CTAs will be added in phase 1.5.

Here is the text copy for this CTA:

{checkmark} Thanks! Your feedback has been <saved>.

Help improve Wikipedia

This encyclopedia is created by people like you. Can you give us a hand?

Learn more =>

  • Wikimedia's standard CTA button with arrow is used in the above mockup, which uses small versions of the button and arrow graphics.

CTA 3: Take a survey[edit | edit source]

Call to action: Take a survey

The purpose of this Survey Call to Action (CTA3) is to learn what readers think about this article feedback tool, overall. We also want to find out which feedback form is most helpful to participants. This short survey will include three elements:

  • A. a call to action asking them to take the survey (CTA3)
  • B. a quick survey form
  • C. a thank you message

The last two items are specified in a separate section below, called 'Surveys'

The survey CTA3 will be shown for a limited time, after filling the feedback form, and will be implemented using the same visual and experience style as other AFT5 calls to action. The quick survey form will be shown after they click 'Start the Survey', and will be implemented by Wikimedia using Survey Monkey, using a neutral style (see latest version on Survey Monkey). The thank you message will also be implemented with Survey Monkey, using the same neutral style, linking to the tutorial on how to edit Wikipedia.

Here is our proposed copy and functional elements for each touch point below:

A. Survey Call to Action (CTA3):[edit | edit source]

√ Thanks! Your feedback has been saved.

Please take a quick survey

It only takes a minute and will help improve Wikipedia.

[ START THE SURVEY ]

[this big blue button will link to one of the Survey Monkey forms -- one for each feedback option]

CTA 4: Create an account or login[edit | edit source]

CTA4: Sign up call to action

The purpose of this CTA4 is to encourage logged-out users to to create an account or login.

This call to action is only shown to logged-out users, and is now displayed randomly 100% of the time to these anonymous users. It works much like other CTAs -- except that it has one big blue button ("Create an account", linking to the account creation page), and a smaller text link ("log in", linking to the log-in page). As with other CTAs, the first line includes a link that shows the last post from that user on the feedback page.

Here is the text copy for this CTA 4:

Thanks! Your post can be viewed on this <feedback page>. [go to my last post on feedback page]

Join our community Sign up or log in, so others can respond to your feedback. Your free account makes it easier to share what you know on Wikipedia.

[ Create an Account ] or < Log in > [links to account creation or log-in pages]

Note that we are discussing alternate wordings for this CTA, as proposed by this feature under consideration: 'Sign up to track your comment'. This CTA was originally adapted from an earlier version used in AFT v4, with some changes to the wording, as well as the look and feel.

CTA 5: View feedback[edit | edit source]

Call to action 5: View feedback

The purpose of this CTA5 is to encourage editors to visit the article feedback page. This CTA5 is the primary call to action shown to editors (along with CTA6 Teahouse). It may also be shown to readers, in rotation with CTA1, CTA2 and/or CTA4.

This new call to action works much like CTA 1 or CTA 2 -- except that the big blue button links to the feedback page for this article. Also, the first line includes a link that shows the last post from that user on the feedback page.

Here is the text copy for this new CTA 5:

"Thanks! Your feedback has been <posted here>. [go to my last post on feedback page]

See what others are saying about this article.

View suggestions from other readers like you.

Can you help pick the best ideas?

[ See all comments ]" [link to feedback page for this article]

CTA 6: Visit Teahouse[edit | edit source]

AFT5-CTA6-Teahouse-Screenshot

This CTA6 invites auto-confirmed editors to visit the Teahouse in order to learn more about editing.

Here's the current copy:

'Need help editing Wikipedia?

To discuss editing on Wikipedia, come to the Teahouse, where new and

experienced editors gather to exchange helpful tips.

[Visit Teahouse]'

This will link to the Teahouse, with an ATT ref tag, as so: http://en.wikipedia.org/wiki/Wikipedia:Teahouse?ref=aft

From a bucketing standpoint, this CTA6 would only be shown to 10% of users who are auto-confirmed editors. It would not be shown to readers. (This was enabled it at 10% by lowering the odds of CTA1 from 50% to 40%).

CTA Bucketing[edit | edit source]

Our proposed bucketing plan for CTAs is as follows:

We propose to show different CTAs each time you post feedback, as appropriate for your user group, and based on your context.

So if you are a reader, we would show these CTAs:

  • CTA4 - Create an account or log in - 100% of the time (if they are logged out)

But if you are a registered user or editor, we would alternate between these CTAs:

  • CTA5 - View feedback page - 90% of the time
  • CTA6 - Visit Teahouse - 10% of the time (if they are auto-confirmed)

Survey 1: Feedback form[edit | edit source]

Here are some of the features we developed for our feedback form survey.

A. CTA 3 - Take a survey:[edit | edit source]

See CTA3 spec above for more details on this first step in getting visitors to take this survey.

B. Survey Monkey - Quick Survey Form:[edit | edit source]

<a href="http://wikimediafoundation.org/" target="_blank">Wikimedia Foundation</a> is developing a new <a href="http://www.mediawiki.org/wiki/Article_feedback/Version_5/Feature_Requirements#Feedback_forms" target="_blank">feedback form</a> and would like to know what you think.

Please take this short survey, powered by Survey Monkey.</a>

1. What do you think of that feedback form you just filled in?

( ) I like it.

( ) I do not like it.

( ) I am not sure

2. Why? How can we improve that feedback form?

_________________________________

__________________________________

__________________________________

3. How often do you edit articles on Wikipedia?

( ) never

( ) rarely

once a year

( ) once a month

( ) once a week

( ) once a day

( ) throughout the day]

You agree your responses may be used in accordance with these <a href="http://wikimediafoundation.org/wiki/Feedback_privacy_statement" target="_blank">Terms</a>.

[ SUBMIT ]

C. Survey Monkey - Thank you Message[edit | edit source]

√ Thank you!

Help improve Wikipedia This encyclopedia is created by people like you. Can you give us a hand?

Learn more =>

link to the tutorial on how to edit Wikipedia

Survey 2: Feedback page[edit | edit source]

Here are some of the features we developed for our feedback page survey.

A. Button: What do you think of this page?'

The feedback page will include a button labeled "What do you think of this page?", at the top right of the page.

B. Survey Monkey - Survey Form:'

Survey: New Feedback Page

Wikimedia Foundation is developing a new feedback page and would like to know what you think.

Please take this short survey, powered by Survey Monkey.

1. What do you think of the feedback page?

( ) I like it.

( ) I do not like it.

( ) I am not sure.

2. Why? How can we improve that feedback page?

_________________________________

__________________________________

__________________________________

3. How often do you edit articles on Wikipedia?

( ) never

( ) rarely

( ) once a year

( ) once a month

( ) once a week

( ) once a day

( ) throughout the day

( ) Other (please specify)

__________________________________

By submitting, you agree to transparency under these <terms.>

[ SUBMIT ]

C. Survey Monkey - Thank you Message

√ Thanks! Your survey response has been saved.

Help improve Wikipedia This encyclopedia is created by people like you. Can you give us a hand?

Learn more =>

[link to the tutorial on how to edit Wikipedia]

Feedback links[edit | edit source]

Feedback links on article pages[edit | edit source]

We are now testing a couple prominent feedback links that would appear 'above the fold' on article pages.

The purpose of these feedback links is to:

  • let readers know they can provide feedback to improve articles
  • enable them to quickly add feedback (without having to scroll to the bottom of the page)
  • increase the overall number of feedback posts (particularly for low-traffic articles)

At this point, we are only testing these feedback links for research purposes, to measure feedback volume and quality for different link placements. We want to learn where we can add the most value with the least amount of friction, towards our goal to get more readers to participate productively on Wikipedia. Note that we're only testing these different feedback links for a few weeks, on less than 1% of the encyclopedia. We'll share the data we collect with the community, so we can engage in a consensus-oriented discussion about whether any potential increase in quantity and quality of submitted feedback is worth the increased visibility.

Current tests[edit | edit source]

We are now testing two prominent versions of the feedback link: Option A and Option E. Option A is a small text link below the article title: 'Improve this page.' Option E, a more prominent button docked at the lower right corner of the feedback page. with a larger font and a dark blue color background, as shown below. We are comparing data from Option A and Option E, versus no links at all. The goal is to see which of these options generates the most responses with the least disruption, then implement the best of these solutions in the final version, based on test results. (Note: a possible outcome is that we would not implement any of these feedback links at all.) But we think it's useful to have a data-informed conversation about these options, and that's why we're testing these links.

AFT5 Feedback Link Option E with Flyover Mockup

Feedback link history[edit | edit source]

During the first phase of this investigation, we explored 8 different placement options on article pages, as shown in this preliminary mockup. Here are some of the options we have mocked up individually and discussed for this feedback link:

  • Option A: add feedback link below the article title (after Wikipedia slogan)
  • Option B: add feedback link below the article title bar (top right corner of page)
  • Option C: add vertical button in the right margin of the browser window
  • Option D: add horizontal button in the lower right corner of the browser window
  • Option E: add prominent horizontal button (see below) in the lower right corner of the browser window

We started by testing Option D first, because it was the easiest to develop and could give us an immediate boost to collect more data so we can measure the effectiveness of the forms. However, it generated fewer posts than the feedback form at the bottom of the page (possible reasons are that it was in small font type and with a light-blue background that was hard to notice). Other options were dismissed earlier: Option B has serious collision issues with geo-tags, Option C either overlaps with content or requires adding an extra margin. We had issues with all the options on the left side of the page (F and G), because they don't relate to the article and obscure these links and Option H introduces a lot of visual clutter by repeating the same long link for each section (for consistency, we want to use the same 'Improve this page' label as the form itself). Based on our evaluation, only a couple of these ideas appeared practical to test in the second stage of this project: Option A and Option E.

Feedback Button 'X' Close box[edit | edit source]

The Feedback button 'X' close box is a little [x] link or icon that will appear for logged in users only, when they mouse over the feedback button, as shown in this mockup.

The purpose of this feature it to enable users to remove this button (as well as the article feedback forms), by changing their AFT user preference.

For logged-in users, this will display a flyover panel inviting users to change their user preference to disable the Article Feedback Tool (this disables both AFT4 and AFT 5). In the first version of this feature, logged-out users would not see the 'X' close box at all.

Feedback Close Box

The feedback button at the lower right of the screen will include an 'X' close box when the mouse rolls over the button, as so:
" Improve this page X "

Flyover Panel

When the user clicks on 'X' in the feedback button, this flyover panel will appear, as specified below.

"Remove this tool? X

To remove this Article feedback, go to

"My Preferences > Appearances,"

then check,

"Don't show the Article feedback widget"

[ Go to my preferences ] "

Flyover Links

These links will be used when the user click inside the flyover panel:

- Go to my preferences / My Preferences > Appearances:

http://en.wikipedia.org/wiki/Special:Preferences#mw-prefsection-rendering

- X:

Close this flyover panel.

Overlay form[edit | edit source]

By default, the the feedback form would appear at the bottom of all article pages. Once a user clicks on a feedback link, the feedback form would appear as an overlay, moving from the bottom of the page to a location near the link, while the background is grayed out. If this proves difficult on some platforms, a fall-back option is to simply include a jump link to the feedback form at the bottom of the page.

Feedback links on talk pages[edit | edit source]

We now show a new feedback link on article Talk pages, so people can access the feedback page. This feedback link says "See reader feedback >>" and appears next to the article title on the Talk page, linking to the feedback page where all reader posts are listed.


Feedback page[edit | edit source]

Feedback Page Release Slides

The feedback page will show feedback posts for a given article. Its contents will vary for different user groups, as outlined below:

  • Reader's view (basic feedback page)
  • Editor's view (intermediate page for auto-confirmed editors)
  • Monitor's view (advanced page for rollbackers, reviewers or admins)
  • Oversighter's view (special feedback page for oversighters and staff)

Readers will get fewer tools than editors, monitors or oversighters. Different views for different user groups are shown below. To learn more about proposed access and permissions to feedback features by user group, read the Access section below.


New Feedback Page Design[edit | edit source]

NEW: We are now developing a new design of the feedback page for release in May 2012. This new design will streamline the overall look and feel of that page, to make it simpler and easier to use. New thumbnails of mockups will be posted in this section in coming days, with a summary of key changes. For a quick overview of this new design, check out the mockup below. It shows how visual hierarchy has been modified so that conceptually related elements are presented closer to each other.

New design for the feedback page. Visual hierarchy has been modified so that conceptually related elements are presented closer to each other.


Feedback Page for Readers[edit | edit source]

Basic Feedback Page - Reader's view

About this page[edit | edit source]

The feedback page will display a list of the feedback posts for an article, as shown in the updated mockup above (see also last mockup, earlier mockup, earlier Balsamiq wireframe, as well as earlier mockups and wireframes). Note that this reader view of the feedback page doesn't show editor tools - see separate wireframe in next section.

Who can use this page[edit | edit source]

Anyone will be able to view this feedback page, as well as filter or sort its posts. Most users will also be able to indicate if the posts are helpful or not, as well as flag posts they find abusive or inappropriate. But only trusted editors with special access (e.g. admin, rollbackers, oversight) would be able to use special tools enabling them to hide or permanently delete (oversight) some of the posts on this feedback page (see Access section).

Page Location[edit | edit source]

The feedback page will be a stand-alone page, much like the Moodbar Dashboard. For the duration of our tests, this special page will not be connected to any of the standard tabs from the article page (Article | Discussion ... Read | Edit | History). However, we will provide text links to the article and talk pages at the top of that special page. (read more below).

How to get to this page[edit | edit source]

This feedback page can be accessed in two primary ways: by clicking on text links to be added on the feedback forms and their calls to action, or clicking on a link to be added on the talk page. During the initial testing phases, these links will not be available to the public.

Overview panel[edit | edit source]

The feedback page will include an overview panel at the top of the page, to provide overall info about the feedback posts for this article:

  • Page label ('Special page' for now)
  • Page title (e.g.: 'Feedback: Golden-crowned Sparrow')
  • Number of posts (excluding any hidden or deleted posts)
  • Feedback icon (e.g.: happy, sad or confused face based on rating average)
  • Feedback summary (e.g.: '75% found what they were looking for' for option 1)
  • Tools label (for editors only)
  • Links to other related pages:
    • View article
    • Talk
    • Help

Icons[edit | edit source]

We will use updated the happy/sad face icons from the Moodbar Dashboard, for consistency. They will have a flat background color, instead of the earlier version, which was more shaded.

Toolbar[edit | edit source]

The feedback page will provide a toolbar allowing users to filter or sort the list of feedback posts. This toolbar will have a flat background color, with no gradients.

Filters[edit | edit source]

This feature (labeled 'Showing') will filter the feedback page to only show posts that match certain pre-defined tags. This will be a predefined set of options, to be determined after we analyze the feedback stream. (Note that we are now proposing to display 'Showing' before 'Sorting', see updated mockups). Here is a preliminary list under review:

  • Basic filters (available to all readers)
    • Relevant (new feature, see below -- this would be checked by default at launch)
    • Featured (only show posts that have been featured by an editor, see below)
    • Helpful (only show posts which users found helpful -- by clicking on the 'Yes' button)
    • Comments only (only show posts that have a comment -- this would be checked by default at launch)
    • All visible (show all posts which have not been hidden or deleted)
  • Editor filters (only available to 'editors' -- editors with (auto)confirmed account)
    • Unhelpful feedback (only show posts which users found unhelpful -- by clicking on the 'No' button)
    • Flagged for abuse (only show posts flagged by readers as abusive)
    • Resolved (only show posts that have been resolved)
  • Monitor filters (only available to 'monitors' -- editors with rollbacker, reviewer, admin and/or oversight access)
    • Hidden (only show posts hidden by editors)
    • Oversight declined (only show posts for which oversight has been declined by oversighters)
    • All (show all posts, including hidden, but not oversighted)
  • Oversight Filters (only available to users in 'oversight' group)
    • Oversight requested (only show posts for which oversight has been requested by editors)
    • Oversighted (only show posts permanently deleted by oversight)
    • All (show all posts, including hidden and deleted)

Each filter option above will include a counter showing the number of posts tagged with that filter -- e.g: 'Hidden (6)'.

Sorting[edit | edit source]

The 'Sort by' function will provide a predefined set of sorting options. These will be simple text links with up/down arrows next to links, which would only be shown after the user has selected one of these options. The currently selected sort item will be bolded for clarity.

  • Relevance: (default - see relevance filter section below)
    • Highest - show the most relevant posts first (default)
    • Lowest - show the least relevant posts first
  • Date:
    • Newest - show the most recent posts first
    • Oldest - show the earliest posts first
  • Helpfulness
    • Helpful - show the posts with the highest helpfulness score first (based on a score equal to the number of 'Yes' answers minus the number of 'Nos')
    • Unhelpful - show the posts with the lowest helpfulness score first (based on the same score from 'Yes/No' responses)
  • Rating:
    • Highest - show the posts with the highest article ratings first
    • Lowest - show the posts with the lowest article ratings first (e.g.: average of 'Yes/No' responses for feedback form option 1)

Feedback contents[edit | edit source]

Each feedback post listed on this page will display these content items:

  • Article rating icon (happy/sad face next to user name, based on user's article feedback)
  • Logged user name (or IP address), with link to user page
  • Article rating label (e.g.: 'found what they were looking for', based on user's 'Yes/No' answer for option 1 - or 'added a comment' if 'Yes/No' not selected)
  • Comment (truncated comment -- show first 500 letters, then click 'More' to see the rest -- current average is 113 letters or 23 words per post)
  • 'More' button (if comment is over 500 letters) showing expandable sub-section with full comment (collapsed by default)
  • Timestamp (show 'x days, hours, or minutes ago' -- also acts as perma-link to that particular post)
  • See old article (previously called 'View original version' or '152 edits since this post', linked to an earlier revision of the article at the time the feedback was posted.)
  • Status labels: 'Featured' and/or 'Resolved' (see next section for editor's view)

Helpfulness[edit | edit source]

At the bottom of each feedback post, readers will be invited to evaluate its helpfulness with a few simple pre-defined tagging functions:

  • Helpfulness Flags ('Is this feedback helpful?' with 'Yes/No' buttons mapped to 'helpful' and 'unhelpful' tags -- as well as thumbs up/thumbs down icons)
  • Response counter (e.g.: '4 yes / 2 no', shows number of responses to helpfulness question)

Flag as abuse[edit | edit source]

At the bottom of each feedback post, readers will have the option to flag abusive feedback. We are now showing it on the same line as the 'Is this helpful?' buttons, right-aligned, in smaller font, but with blue highlight, so people know it's clickable. This is a toggle button, so on your first click, the label changes to 'Flagged as abuse' and on your second click, it changes back to 'Flag as abuse.' A counter is shown as soon as one person has flagged a post. Once 3 people have flagged a post, the link color becomes red; once 5 people have flagged the post, it is automatically hidden. This function includes these elements:

  • Flag as abuse (a text link for flagging inappropriate posts -- works as a toggle, tagging the post on the first click, untagging it on the second click)
  • Flag counter (number of flags from users, shown in parenthesis)

Tools[edit | edit source]

Editor tools would be shown in the right margin -- and would only be visible to authorized editors. (see next section)

Show more posts[edit | edit source]

At the bottom of the page, a wide button would let you load more feedback posts. The feedback page would display up to 50 feedback posts by default (this number could be changed based on user feedback, but no need to give user control of number of posts right now.) Initially the "Show more" button at the end of the list would load additional posts, same amount, and, again, display the "show more" button at the end of the list. In a later stage, better pagination may be provided, as needed. (see below)


Feedback Page for Editors[edit | edit source]

Intermediate Feedback Page - Editor's view

About this page[edit | edit source]

NEW: This intermediate version of the feedback page includes special tools which would only be visible to 'auto-confirmed editors', as shown in the mockup above (see also earlier mockup. Note that the basic version in the previous section doesn't show these editor tools. Auto-confirmed editors would have access to the 'Feature this post', 'Mark as resolved' and 'View Activity' tools below (but would NOT have access to 'Hide' and 'Request oversight' tools, which would be reserved for monitors -- or the 'Oversight' tools, which would be reserved for oversighters -- see sections below).

To learn more about proposed access and permissions for these editor tools by user group, read the Access section below.

Tools[edit | edit source]

If you are an 'auto-confirmed editor', a 'Tools' panel will be shown on the right of each post. Each panel will be set against a light blue color background, as shown in the current mockup.

These editor tools will include these features for each post:

  • Feature this post - promote useful feedback to editors
  • Mark as resolved - check off featured items that have been completed
  • - - - - - - - - - (divider)
  • View activity - track actions taken by other editors or community members for this post

These tools are described one at a time below. This Tools panel will only be visible to auto-confirmed editors, monitors and oversighters. And this Tools panel will show more tools if you have a higher access level, so the oversighters will see a different view (see next section). Note that the height of the posts will vary based on the user role, to make room for these additional tools.

Feature this post

Feature this post[edit | edit source]

The 'Feature this post' function's purpose is to enable 'auto-confirmed editors' to promote useful posts to community members, as well as add a note about why they are featuring these actionable posts. This note will be listed in the activity panel, so other editors can track the status of this post as a group. This feature will have a small blue 'star' icon as a visual anchor, to make it more appealing.

When people click on the 'Feature this post' link, a small flyover sub-panel opens up , with a text box and 'feature' button, to let you add a note at the same time as you feature this post. A grayed out prompt inside the text area reminds you of the purpose of this note (e.g.: Why are you featuring this post?).

See mockup showing this feature's visual design

Here are the contents of this 'Feature this post' panel:

Feature this post X

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Add a note:

[ Why are you featuring this post? . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ] (text field)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

[ Feature this post ] Learn more (button)

Here's what happens when a user clicks on 'Feature this post' in the flyover panel:

  • the feature flyover panel closes.
  • the 'Feature this post' link is replaced with 'Un-feature this post' link, which acts as a toggle.
  • a new text link appears: 'Marked as resolved (below the 'Un-feature this post' link), only available for featured posts.
  • a green line of text is shown at the top of the post: 'This post was featured by <username> on <action date>. <View activity>'.
  • a gray 'Featured' label appears after the date (or link to old article) for each post that has been featured, to make readers aware of its status.
  • this post is tagged as 'Featured' (so it is added in the 'Featured' drop down filter).
  • this featured activity is recorded in this post's activity log, as well as on other site logs (new requirement, see below).
  • featured posts are shown more prominently in the default view of the home page.

If you click on 'Learn more', a new tab or window opens with the matching help page for editors, moderators or oversighters, depending on your user status.

If you click on 'X' (or click anywhere outside the feature panel), the flyover panel closes.

To un-feature a post, click on the 'Un-feature this post' link, which will revert to the previous state and settings.

Mark as resolved[edit | edit source]

The 'Mark as resolved' function's main purpose is to enable 'auto-confirmed editors' to identify feedback that has been resolved, as well as add a note about why they are marking a post as resolved. This note will be listed in the activity panel, so other editors can track the status of this post as a group. This feature will have a small blue 'checkmark' icon as a visual anchor, to make it more appealing.

When people click on the 'Mark as resolved' link, a small flyover sub-panel opens up , with a text box and a 'Mark as resolved' button, to let you add a note at the same time as you mark this post.

See mockup showing this feature's visual design

Here are the contents of this 'Mark as resolved' panel:

Mark as resolved X

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Add a note:

[ Why are you marking this post as resolved? . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ] (text field)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

[ Mark as resolved ] Learn more (button)

Here's what happens when a user clicks on 'Mark as resolved' in the flyover panel:

  • the 'Mark as resolved' flyover panel closes.
  • the 'Mark as resolved' link is replaced with 'Un-mark as resolved' link, which acts as a toggle.
  • a green line of text is shown at the top of the post: 'This post was marked as resolved by <username> on <action date>. <View activity>'.
  • a gray 'Resolved' label appears after the date (or link to old article) for each post that has been marked as resolved, to make readers aware of its status.
  • this post is tagged as 'Resolved' (so it is added in the 'Resolved' drop down filter).
  • this 'Marked as resolved' activity is recorded in this post's activity log, as well as on other site logs (new requirement, see below).
  • Mark as resolved posts are shown less prominently in the default view of the home page.
  • Note that 'Mark as resolved' does NOT remove the post from the 'Featured' list (only 'Un-feature this post', 'Hide' or 'Oversight' can remove it), but it moves it to the bottom of that 'Featured' list.

If you click on 'Learn more', a new tab or window opens with the matching help page for editors, moderators or oversighters, depending on your user status.

If you click on 'X' (or click anywhere outside the feature panel), the flyover panel closes.

To un-mark a post as resolved, click on the 'Un-mark as resolved' link, which will revert to the previous state and settings.


View activity

View activity[edit | edit source]

The purpose of the 'View activity log is to enable trusted editors to track article feedback moderation and coordinate their activities as a group. This feature will have a small blue 'bar graph' icon as a visual anchor, to make it more appealing.

A 'View activity' link in the Tools panel opens up a special overlay panel, which lists the activity for that post, in reverse chronological order, like History. This panel shows who did what to this post, listing each action with a user name/ID, as well as when they did it and why (if they left a note).

See mockup showing this feature's visual design

The Activity panel includes these elements:

Activity (?) (X)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Feedback post <postID> by <username>

Posted on <date> [permalink]

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

10 actions for this post

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

<username> oversighted this post on <date> [red]

<username> requested oversight on <date>

<username> hid this post on <date> [red]

<username> un-hid this post on <date>

<AFT extension> auto-hid this post on <date> [red]

<username> flagged this post on <date>

<username> flagged this post on <date>

<username> flagged this post on <date>

<username> flagged this post on <date>

<username> flagged this post on <date>

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Show more actions >>

By default, we would list the last 25 actions on this activity panel, to be viewed using the scrollbar. When a user gets to the bottom of the scroll, they can click "show more actions", we simply show another 25 actions.

Here are some of the data requirements for this activity log:

a. Actions to be tracked:

flag as abuse, unflag, hide, unhide, request oversight, unrequest oversight, oversight, un-oversight, decline oversight

b. Data needs to be tracked for each action:

User name, Post ID, article ID, action date, action taken, action note (if any)

c. Retention time for activity:

Forever -- or whatever policy Wikipedia now has for tracking edits on its articles (there may be some archiving going on after a few years).


Feedback Page for Monitors[edit | edit source]

Advanced Feedback Page - Monitor's view

About this page[edit | edit source]

This advanced version of the feedback page includes special tools which would only be visible to 'monitors' (rollbackers, reviewers, administrators and/or oversighters and staff), as shown in the updated mockup above. (See also last mockup, earlier mockup, as well as previous Balsamiq wireframe, [[commons:File:Article-Feedback-Page-Mockup-AdminTools-11-18.png|earlier mockup] and earlier wireframe). Note that the basic version in the previous section doesn't show these monitor tools. Here are two additional mockups showing the monitor's view after a post has been featured and after a post has been marked as resolved.

NEW: Monitors would have access to two new tools: 'Hide' and 'Request oversight' (reserved for monitors), but would not have access to the 'Oversight' or 'Decline oversight' tools (reserved for oversighters).

To learn more about proposed access and permissions for these monitor tools by user group, read the Access section below.

Tools[edit | edit source]

If you are a 'monitor', a 'Tools' panel will be shown on the right of each post. Each panel will be set against color background, such as the light blue in the current mockup.

These monitor tools will include these features for each post:

  • Feature this post - promote useful feedback to editors (see above section)
  • Mark as resolved - check off completed tasks in the featured list (see above section)
  • - - - - - - - - - (divider)
  • Hide this post - remove the post from view and mark it as hidden
  • Request oversight - ask that this post be 'oversighted' (permanently deleted), if it is illegal or highly inappropriate
  • - - - - - - - - - (divider)
  • View activity - track actions taken by other editors or community members for this post

These tools are described one at a time below (except for Feature this post' and 'Mark as resolved', already described in the previous section). This Tools panel will show more tools if you have a higher access level, so the oversighters will see a different view (see next section).

Feature this post[edit | edit source]

See previous section for feature description.

Mark as resolved[edit | edit source]

See previous section for feature description.

Hide this post

Hide this post[edit | edit source]

The hide function's purpose is to enable 'monitors' to hide a post, as well as add a note about why they are hiding that post. This note will be listed in the activity panel, so other editors can track the status of this post as a group. This feature will have a small blue 'X' icon as a visual anchor, to make it more appealing.

When people click on the 'Hide this post' link, a small flyover sub-panel opens up , with a text box and 'hide' button, to let you add a note at the same time as you hide.

See mockup showing this feature's visual design

Here are the contents of this 'Hide this post' panel:

Hide this post X

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Add a note:

[ Why are you hiding this post? . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ] (text field)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

[ Hide this post ] Learn more (button)

Here's what happens when a user clicks on 'Hide this post' in the flyover panel:

  • the hide panel closes
  • the hide link is replaced with 'Un-hide this post' link, which acts as a toggle
  • A red line is shown at the top of the post: 'This post was hidden by <username> on <action date>. <View activity>'.
  • a gray mask covers the 'Hidden' post, as described in the next section below
  • this post is tagged as 'Hidden' (so it is added in the 'Hidden' drop down filter)
  • this hiding activity is recorded in this post's activity log, as well as on other site logs (new requirement, see below)
  • hidden posts are no longer visible to anyone but hiders or oversighters

If you click on 'Learn more', a new tab or window opens with the Revision/Delete policy page (WP:RVDL). In a later stage, we plan to provide an interstitial page to explain to users what the 'Hide' function does and how it relates to Wikipedia's Revision/Delete policy, so they do not get confused with a page that is largely about deleting pages on Wikipedia.

If you click on 'X' (or click anywhere outside the hide panel), the flyover panel closes.

To un-hide a post, click on the 'Un-hide this post' link, which will revert to the previous state and settings.

Hidden post

Hidden Post[edit | edit source]

Once a post is hidden, it is covered by a light gray opaque panel, so that its contents are not visible by default.

See mockup showing this feature's visual design

A red line is shown at the top of the post: 'This post was hidden by <username> on <action date>. <View activity>'.

A large label says: 'Feedback hidden by an experienced editor. <View contents >> Post #24,862'

To see the hidden post, click on 'View contents' or click anywhere.

This removes the gray panel, revealing the post as it was before it was hidden, except that it is still grayed out with a translucent mask.

A post ID number is provided, so that a user can search for it or refer to it. It links to the permalink for that post.

Note: When a hidden post is shown by itself on the permalink page for that post, it will include a prominent text link below the gray mask: 'Go to feedback page'. Clicking on that link will cause the feedback page to appear, with all the posts that match your previously selected filter (or the default filter).

Request oversight

Request oversight[edit | edit source]

The 'request oversight' feature's main purpose is to enable hiders to request oversight from a small group of oversighters, asking them to permanently delete illegal or inappropriate content (what Wikipedians call 'oversight'). This feature will have a small blue 'shield' icon as a visual anchor, to make it more appealing.

See mockup showing this feature's visual design

Only hiders can see or use this 'Request oversight' feature. When they click on the 'Request oversight' link, it makes a small flyover overlay appear:

Request oversight X

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Add a note:

[ Why are you requesting oversight? . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ] (text field)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

[ Request oversight and hide ] Learn more (button)

The 'Request oversight' feature works pretty much the same as 'Flag for abuse', with these specific requirements:

  • We will now use the word 'oversight' throughout the extension (instead of 'delete' or 'delete/oversight'), to avoid confusion with the word 'delete', which is used in a different context on Wikipedia.
  • Any 'hider' (admin/rollbacker/reviewer) will have the right to 'request oversight' (readers can use 'flag for abuse' to report inappropriate feedback, or just email the permalink to an oversighter).
  • We will not show the number of requests in the counter (based on Philippe's observation that it might encourage oversighters to only oversight posts based on how many people have requested it, when they should be oversighting them all).
  • This link will be a toggle, so you can 'un-request oversight' if you think the problem has been solved. This only cancels your own request, not other requests for oversight, though.
  • Clicking on 'Request oversight' also has the effect of 'hiding' the feedback post, pending further review.
  • Note: WMF's legal department would like 'oversight-requested' posts to only be visible to oversighters (and to the persons who requested oversight), but not to hiders. We are investigating this request, and trying to determine the most effective way to implement it.

Here's what happens when a user clicks on 'Request oversight' in the flyover panel:

  • the 'Request oversight' panel closes
  • NEW: the 'Request oversight' link is replaced with 'Un-request oversight' link, which acts as a personal toggle switch for the user(s) who requested the oversight.
  • NEW: for all other monitors, the 'Request oversight' link is replaced with 'Oversight requested'
  • For oversighters only: the 'Request oversight' link is replaced with 'Decline oversight' link, to enable oversighters to decline requests for this post.
  • the 'Hide this post' link is replaced with 'Un-hide this post' link, which acts as a toggle (requesting oversight also hides the post)
  • A red line is shown at the top of the post: 'Oversight was requested and this post was hidden by <username> on <action date>. <View activity>'.
  • a gray mask covers the 'Hidden' post, as described in the section above
  • this post is tagged as 'Oversight requested' (so it is added in the 'Oversight requested' drop down filter)
  • this post is also tagged as 'Hidden' (so it is added in the 'Hidden' drop down filter, if not already hidden)
  • this oversight request and hide activities are recorded in this post's activity log, as well as on other site logs (new requirement, see below)
  • an email is sent to the oversight list, with a link to this post's permalink (new requirement, see below)

If you click on 'Learn more', a new tab or window opens with the Revision/Delete policy page (WP:RVDL).

If you click on 'X' (or click anywhere outside the hide panel), the flyover panel closes.

To undo a request for oversight, click on the 'Oversight requested' link, which will revert to the previous state and settings.

Feedback Page for Oversighters[edit | edit source]

Advanced Feedback Page - Oversighter's view

Oversight workflow

About this page[edit | edit source]

This advanced version of the feedback page includes special tools, which would only be visible to a small group of 'oversighters' (and 'staff'), as shown in the updated mockup above (see also last mockup, and earlier mockup). Note that the other views of this tool in the previous sections don't show these oversighter tools. To learn more about proposed access and permissions for these editor tools by user group, read the Access section below.

The proposed workflow for oversight practice for the Article Tool Feedback is described in this diagram (see thumbnail to the right) and detailed in this report (Option 4 is the recommended solution supported by the requirements below).

Tools[edit | edit source]

If you are part of the Oversighter or Staff user groups, you will see these tools, which are described in more depth below:

  • Feature this post - promote useful feedback to editors (see above section)
  • Mark as resolved - check off completed tasks in the featured list (see above section)
  • - - - - - - - - - (divider)
  • Hide this post - remove the post from view and mark it as hidden (or 'Unhide this post' if it has already been hidden)
  • Decline oversight - refuse to oversight this post, if it is not considered to be highly inappropriate
  • Oversight this post - permanently delete this post, so not even monitors can see it, if it is illegal or highly inappropriate
  • - - - - - - - - - (divider)
  • View activity - track actions taken by other editors or community members for this post

Decline oversight[edit | edit source]

The 'decline oversight' feature's main purpose is to enable an oversighter to refuse to 'oversight' a post they don't think is inappropriate. This feature will have a small blue round 'no' icon (like a road sign) as a visual anchor, to make it more appealing.

Only oversighters can see or use this 'decline oversights feature. When they click on the 'Decline oversight' link, it opens a small flyover panel:

Decline oversight for this post X

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Add a note:

[ Why are you declining to oversight this post? . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ] (text field)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

[ Decline oversight ] Learn more (button)

Oversighters are requested to add a note about why they are declining to oversight a post. These notes are listed in the activity panel, so other editors can track the status of these posts as a group.

Here's what happens when a user clicks on 'Decline oversight' in the flyover panel:

  • the 'Decline oversight' flyover panel closes
  • the 'Decline oversight' link is replaced with 'Oversight declined' link
  • A green line is shown at the top of the post: 'Oversight was declined by <username> on <action date>. <View activity>'.
  • this post is tagged as 'Oversight declined' (so it is added in the 'Oversight declined' drop down filter)
  • this post is also un-tagged as 'Oversight requested' (so it is removed from the 'Oversight requested' drop down filter)
  • this 'decline oversight' activity is recorded in this post's activity log, as well as on other site logs (see below)
  • the post remains visible to monitors

At that point, any monitor can choose to request oversight again -- and any oversighter can still choose to oversight, as needed.

If you click on 'Learn more', a new tab or window opens with the Oversight policy page (WP:Oversight).

If you click on 'X' (or click anywhere outside the hide panel), the flyover panel closes.

To undo an oversight, click on the 'Oversighted' link, which will revert to the previous state and settings.

Oversight this post

Oversight this post[edit | edit source]

The 'oversight this post' feature's main purpose is to enable a small group of oversighters to permanently delete illegal or inappropriate content (what Wikipedians call 'oversight'). This feature will have a small blue 'shield' icon as a visual anchor, to make it more appealing.

Only oversighters can see or use this oversight feature. When they click on the 'Oversight' link, it opens a small flyover panel:

Oversight this post X

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Add a note:

[ Why are you oversighting this post? . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ] (text field)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

[ Oversight this post ] Learn more (button)

See mockup showing this feature's visual design

Oversighters are requested to add a note about why they are oversighting (permanently deleting) a post. These notes are listed in the activity panel, so other editors can track the status of these posts as a group.

Here's what happens when a user clicks on 'Oversight this post' in the flyover panel:

  • the 'Oversight this post' panel closes
  • the 'Oversight this post' link is replaced with 'Oversighted' link (which acts as a shared toggle switch, just like 'Hide/show this post')
  • the 'Hide this post' link is replaced with the 'Un-hide this post' link (oversighting also hides the post, if not already hidden)
  • A red line is shown at the top of the post: 'This post was oversighted and hidden by <username> on <action date>. <View activity>'.
  • a gray mask covers the 'Hidden' post, as described in the next section above - only visible to oversighters
  • this post is tagged as 'Oversighted' (so it is added in the 'Oversighted' drop down filter)
  • this post is also tagged as 'Hidden' (so it is added in the 'Hidden' drop down filter, if not already hidden)
  • this oversight and hide activities are recorded in this post's activity log, as well as on other site logs (see below)
  • oversighted posts are no longer visible to anyone but oversighters

If you click on 'Learn more', a new tab or window opens with the Oversight policy page (WP:Oversight).

If you click on 'X' (or click anywhere outside the hide panel), the flyover panel closes.

To undo an oversight, click on the 'Oversighted' link, which will revert to the previous state and settings.

Even when a post is oversighted, its permalink still works, taking you to a page with only that post, covered by a gray mask (note that you need to be an oversighter to open it).

Oversight states:[edit | edit source]

The 'oversight' feature has these four main states:

  • original state (blank)
  • oversight requested (and hidden)
  • oversighted (and hidden)
  • oversight declined => original

If oversight is declined, the state goes back to original state, and wipes out all oversight requests, if any.

Oversight behavior:[edit | edit source]

  • Multiple people can request oversight
  • Requesting oversight sends an email to OTRS (Open-source Ticket Request System), which emails oversighters
  • The email to oversighters will be plain text, and include a link to the post (but doesn't need to have the user's email address in the "from" field).
  • It's okay to have multiple oversight email notifications, each time an oversight request is made
  • Requesting oversight automatically hides --> only monitors can request oversight
  • Oversighting simply means making the post invisible to anyone without oversight privileges -- they will not see oversighted posts at all
  • Oversighters will see "hidden by an experienced editor" and need to click through to view, where they can oversight
  • The 'Staff user' group (and a special 'aft5test' group, during a limited testing period) will enable WMF team members to oversight posts

Advanced Filtering[edit | edit source]

Oversighters will have access to more filtering options than regular users in the 'Showing' drop-down menu on the toolbar.

So the drop-down menus should read, for each user group:

Readers/Anonymous/Autoconfirmed:

- Relevant (default)

- Featured

- Helpful

- Comments only

- All visible

Editors (auto-confirmed):

- Relevant (default)

- Featured

- Helpful

- Comments only

- All visible

- - - - - - - - - - - - -

- Un-helpful

- Flagged as abuse

- Un-featured

- Marked as resolved

Monitors (Rollbackers, reviewers, admins):

- Relevant (default)

- Featured

- Helpful

- Comments only

- All visible

- - - - - - - - - - - - -

- Un-helpful

- Flagged as abuse

- Un-featured

- Marked as resolved

- Hidden

- Un-hidden

- Oversight requested

- Oversight declined

Oversighters (and 'afttest' group):

- Relevant (default)

- Featured

- Helpful

- Comments only

- All visible

- - - - - - - - - - - - -
- Un-helpful

- Flagged as abuse

- Un-featured

- Marked as resolved

- Hidden

- Un-hidden

- Oversight requested

- Oversighted

- Un-oversighted

- Oversight declined

- All (with oversighted)

Relevance filter[edit | edit source]

We plan to use a relevance filter to show a sanitized 'default view' of the feedback page to visitors.

Filter purpose[edit | edit source]

The purpose of this feature is to:

  • Surface good feedback
  • Reduce the noise on the feedback page

This will benefit two different user groups on Wikipedia:

  • readers (who will see more interesting feedback by default)
  • editors (who will be able to feature and act on quality feedback)

Filter contents[edit | edit source]

The relevance filter will give readers a filtered list of feedback posts, which will only include posts that meet one of these criteria:

  • Featured posts (selected by editors)

or:

  • Helpful posts (flagged by other readers)

or:

  • Comments-only

The relevance filter will remove from this featured list any posts that are:

  • Hidden
  • Oversighted

Filter access[edit | edit source]

To accomplish this, we plan to create a new filter called "Relevant", which will be shown by default and listed first in the filter drop-down menu next to the "Showing" label, in the toolbar at the top of the feedback page. Users will continue to have access to other filters in that drop-down menu (e.g. 'Helpful' or 'Featured'), based on their user rights (editors will have more filter options than readers). Also note that a new 'Sort by Relevance' function is being added next to the 'Sort by' label in the feedback page toolbar, as described in other sections of this document.

Filter ranking[edit | edit source]

We plan to use a relevance score to automatically rank posts based on the factors listed above. Each feedback post will receive a score as proposed below:

  • Featured post: +50 points (if any editor has featured it)
  • Helpful posts: +1 point for each user who found it helpful
  • Marked as resolved: -45 points
  • Unfeatured: -50 points
  • Unhelpful: -1 point for each user who found it unhelpful
  • Flagged as abuse: -5 points for each user that flagged it as abuse
  • Hide: -100 points
  • Request Oversight: -150 points
  • Oversight: -750 points
  • Unhide: +100 points
  • Decline Oversight: +150 points
  • Unoversight: +750 points

Each time a post is featured, marked as helpful/unhelpful, flagged as abuse, or otherwise moderated, its relevance score will be updated, by adding the points for that action to the current value in the relevance field. The relevance field may be stored as a separate field in the article feedback data-base, much like the helpfulness score we already use.

This spreadsheet includes examples of relevance scores and how they are sorted. The proposed values above (points for helpful, unhelpful, flagged, featured and resolved posts) will be stored in an easily-accessible configuration file, rather than in the PHP code itself. Note that a special script will need to be run for recalculating relevance scores if we ever decide to change these values in the future.

Filter sorting[edit | edit source]

By default, items in the relevance filter will be sorted in this order:

  • by relevance (using the relevance score described above, with the highest score showing first)
  • by date (showing the most recent post first, then the previous posts, in case there are several posts with the same score)

Users will also be able to sort the "Relevant" filter list by clicking on one of four labels in the top toolbar, right after 'Sort by'). Sort options will include: by Relevance, by Date, by Helfpulness and by Rating, both in ascending and descending order (see above). We are planning to use this "Relevant" filter as the default filter, and "by Relevance" as the default sort option. (To save space on the toolbar, that new "Relevance" option could eventually be merged the Helpfulness option for future releases.)

Optional: Cut-off and Declining Relevance[edit | edit source]

We are considering two possible feature improvement, which are presented here for discussion purposes, and may not be implemented until future releases.

Cut-off: We would like to add a "cut-off" to the relevance filter, so that any feedback posts whose relevance score is below a certain negative value would be excluded from the relevance filter list before it is shown to users. (For the sake of example, we might use -10 as the cut-off value, as a starting point.)

Declining Relevance: To insure that the same featured posts do not remain forever at the top of the page, we are considering gradually reducing all relevance scores by ~1% each time a new edit is made to an article. So after 100 or more edits, the relevance of a featured post would have been zeroed out, unless new people found it helpful.

Filter release[edit | edit source]

We plan to release this filter at the same time as we release the 'Feature this post' and 'Mark as resolved' tools, with a target date of mid-April. This will enable us to display feedback posts that are more likely to satisfy the needs of our users, by providing an integrated solution that will:

  • Promote high-quality suggestions
  • Create list of actionable tasks
  • Filter out low-quality feedback

Access and permissions[edit | edit source]

Different user groups will have access to different tools (as shown in this comparative wireframe). This preliminary matrix lists key user groups and AFT features under consideration, with proposed access levels shown in green for each item (see earlier version of that matrix).

Here is a list of the proposed permissions:

User Group / Tool Blocked Unregistered Registered Autoconfirmed Rollbacker / Reviewer Administrator Oversighter
View feedback page yes yes yes yes yes yes yes
Post feedback no yes yes yes yes yes yes
Mark as helpful / unhelpful no yes yes no no no no
Flag as abuse no yes yes no no no no
Mark as 'useful' no no no yes yes yes yes
Mark as 'resolved' no no no yes yes yes yes
Mark as 'no action needed' no no no yes yes yes yes
Mark as 'inappropriate' no no no yes yes yes yes
Undo no no no yes yes yes yes
Hide this post no no no no yes yes yes
View hidden feedback no no no no yes yes yes
Unhide this post no no no no yes yes yes
Request oversight no no no no yes yes yes
Un-request oversight no no no no yes yes yes
View oversight request no no no no yes yes yes
Protect articles to limit feedback no no no no no yes yes
Decline oversight no no no no no no yes
Oversight feedback no no no no no no yes
View oversighted feedback no no no no no no yes
Un-oversight feedback no no no no no no yes

This chart is based in part on this page for Wikipedia-EN User Access Levels.

Our overall goal is to tie-in with existing Wikipedia user groups and processes, rather than create new processes from scratch. For example, the current 'rollbacker' group (users with rollback permissions) would be enabled to request oversight, as well as view oversight requests. And the current 'oversight' group would have the right to permanently oversight (or un-oversight) posts containing illegal material (e.g. posts with links to child pornography).

Here are some of the highlights, to sum up the matrix above:

  • Any user can post feedback about an article, whether they are logged in or not (except for blocked users who cannot post feedback).
  • Users can post multiple comments per article, if they have several suggestions, but we will throttle comments to prevent spam (no more than 10 posts per hour).
  • For logged in users, feedback is posted under their user account (the IP address shall still be recorded, but available only to users with CheckUser permissions).
  • For anonymous or logged out users, feedback is posted under their IP address.
  • Anyone can view the feedback page, including blocked users.
  • Only readers and members can mark a post as helpful/unhelpful on the feedback page ('Was this feedback helpful? Yes / No').
  • Only readers and members can flag a post for abuse (if 5 users flag a post, it is auto-hidden as 'inappropriate')
  • Only editors can moderate a post on the feedback page (e.g. mark it as 'useful', 'resolved', 'no action needed' or 'inappropriate') or view these filters.
  • Only monitors (rollbackers, reviewers, admins or oversighters) can request oversight.
  • Only administrators (or oversighters) can protect a page to limit feedback.
  • Only oversighters can permanently oversight posts (and/or view oversighted posts).
  • A few selected WMF staff members can access the monitor, administrator or oversighter features for testing purposes only.


Abuse/Spam Filters[edit | edit source]

Abuse Filter on Feedback Form

The overall purpose of this feature is to reduce the noise on the feedback page -- and make it easier for editors to surface and use good feedback. Our first test results suggest that while a good portion of the feedback posts is likely to be helpful, a number of posts will include abuse, spam and junk. To filter some of this unhelpful feedback, we plan to include automated abuse and spam filters that can help identify questionable comments as they are posted, based on their contents, sources and/or destination.

These new filters will be based on the AbuseFilter extension by Andrew "Werdna" Garrett (now in wide use on the English Wikipedia under the name 'Edit filter'), as well as adapt the custom Edit Filters written by the community to apply this technology for a variety of uses. In our first releases, we will access the existing Abuse Filter implementation on the English Wikipedia. We also plan to use the SpamBlacklist extension for filtering content from known spammers.

Filter Editors[edit | edit source]

The Wikipedia community will be primarily responsible for creating and maintaining new filters for this feature, which can be simply added on this page, then assigned to Article Feedback as outlined below. To that end, we have reached out to experienced filter editors for the current Abuse filter, to invite them to contribute to this project. We have received helpful technical advice from Werdna already, and experienced editors like Reaper Eternal have helped improve some of the first feedback filters. We also hope to involve other experienced filter editors, such as King of Hearts, NawlinWiki, Prodego, Shirik and/or Sole Soul.

To get the ball rolling, the Wikimedia Foundation created a few initial filters, but we hope that the editor community will take charge of creating additional feedback filters, as needed. Note that we recommend that special filters be used for this project, rather than trying to get existing filters to serve dual purposes. However, existing filters used for article edits on Wikipedia can be adapted to create new filters. And all filters we write will be added to the Edit filter page, following the edit filter instructions and Abuse filter documentation.

Recommended filters[edit | edit source]

New abuse filters created for the Article Feedback Tool will automatically accept, reject/disallow, warn and/or flag inappropriate posts from the feedback page. The abuse filter extension will scan the text of each comment that is posted, to see if it matches any of the words or patterns selected by community editors as possible indicators of abuse.

We recommend filtering a wide range of abuses, including:

  • Irrelevant, repetitive, or "nonsense" comments;
  • Obscenities, swear words, or offensive content;
  • Phone numbers, email or street addresses;
  • Advertisements, promotional material, spam, or commercial solicitations;
  • Links to websites from known spammers or sites that host illegal content;
  • Programming code other than links (such as CSS, HTML or Javascript);
  • Gibberish (e.g.: the same character repeated more than 10 times)
  • Posts that are all-caps, with no punctuation, repetitive (or other telltale signs of questionable content)

Here is a preliminary list of abuse filters now under consideration, sorted by sprint number, in order of proposed deployment.

Filter groups[edit | edit source]

To insure that abuse filter actions for feedback posts do not interfere with edit filter actions, Andrew Garrett (User:Werdna) was kind enough to create a special 'feedback' group which processes 'feedback filters' separately from 'edit filters'. When creating a new abuse filter for feedback posts, editors are encouraged to select 'feedback' in the drop-down menu next to 'Filter group:' at the top of the filter edit form. This will make sure that actions from this new 'feedback filter' will not impact the performance of 'edit filters' -- and vice-versa.

Filter actions[edit | edit source]

Abuse Filter Actions

Abuse Filter Flow Diagram

The AFT5 extension will be programmed to take different actions when it finds a match, depending on the severity of the abuse:

  • Disallow: reject the post (for major offenses like obscenities - with a message explaining that it may violate feedback guidelines)
  • Warn: on the first attempt to post, show the user a warning message (for minor offenses like all-caps), then accept the second attempt
  • Auto-Flag: accept, but auto-flag the post as abuse (for minor offenses like all-caps)

All actions triggering a filter will also be logged in the Edit filter history by default. For example, here is the [abuse log for one of the first filters we deployed on Wikipedia to test this new feature.

The technical workflow diagram shown to the right outlines in greater detail the actual sequence of events from the time the user posts feedback to its possible match with an abuse filter and the resulting actions taken by the software. For more technical information, check our technical design page.

To give editors maximum flexibility for this feature, we also added special actions for feedback posts beyond auto-flag (e.g.: auto-hide and auto-oversight), but do not expect to need these actions in the near term (because we don't think machines can trusted to take such radical actions). However, these features are available in the software, should an urgent need arise for them to be used in the future.

Selecting filter actions[edit | edit source]

In most cases, we recommend choosing between Disallow or Warn, based on abuse severity. If the abuse is serious, Disallow should be selected, and should not be combined with any other action. If the abuse is minor, Warn should be selected, and we recommend that it be combined with Auto-Flag, so that monitors can be made aware of this possible abuse, even if it is accepted on the second try.

To select which of the above actions to take if a match is found, authorized community editors can use checkboxes from the section called "Actions taken when matched" in the current 'Edit filter management' tool, as proposed below:

  • Disallow: Check the box that says: "Prevent the user from performing the action in question"
  • Warn: Check the box that says: "Trigger these actions after giving the user a warning"
  • Auto-Flag: Check the special box that says: " (Article Feedback) Auto-flag as abuse"

Note that the auto-flag function is a custom action inserted by AFT, which appears as an extra checkbox at the bottom of the Edit filter management tool, as specified in the our technical design page.

Filter Messages[edit | edit source]

Two types of abuse filter messages will be supported by the Article Feedback Tool: Disallow and Warn, as outlined below.

  • The Disallow action will automatically display this message, based on pre-determined text stored in the Article Feedback extension:

"Your post has been rejected by a software filter that suggests it may have violated Wikipedia's feedback guidelines. Please revise your post and try again."

  • The Warn action can support customized messages by authorized users, displaying whatever warning message is selected within the filter rule. Filter editors are able to edit this message and/or add others depending on what's appropriate for the filter in question. However, we strongly recommend that editors refrain from using 'edit warnings', which are confusing to users because they refer to editing a page rather than posting feedback. Instead, we propose that editors use this special 'feedback warning', labeled 'abusefilter-warning-feedback':

"Your post has been rejected by a software filter that suggests it may have violated Wikipedia's feedback guidelines. Please revise your post and try again. ($1)"

($1) = shows the name of the filter that triggered that action.

This is the same warning message that is used for the Disallow function above, which is more appropriate for people posting feedback and was approved by WMF's legal team. Filter editors are welcome to create variations of this message, as long as they refer to posting feedback (not making edits on a page) and link to the feedback guidelines. If no custom message is specified by filter editors, AFT should show this special feedback warning message by default.

Feedback Guidelines[edit | edit source]

To give users do's and don'ts about posting feedback on Wikipedia, we provide concise Feedback Guidelines, outlining how to post feedback with this tool. This single page will give general examples of the type of feedback that is encouraged, as well as discouraged, and may be further edited by the Wikipedia community.

Adding a filter to Article Feedback[edit | edit source]

To make a filter work with Article Feedback, editors will need to set the variable "action" to "feedback" as part of the filter regex code, as shown in this first example of a 'shouting' filter, now posted on WIkipedia:

action == 'feedback' & new_wikitext rlike "^[A-Z0-9\s\pP]*?[A-Z]{5}[A-Z0-9\s\pP]*$"

We've been using a convention of prefixing feedback rules with "Feedback: ", but it's up to the community whether they want to use that convention or do something else entirely.

Multiple matches[edit | edit source]

In cases when multiple filters catch different types of abuse with different actions in the same post, AFT relies on the abuse filter to determine which action to take. We expect the abuse filter to work much like it does for edits: for example, on the first attempt to post feedback, if any of the rules request a warning, that warning will be displayed. If it's the second attempt (of if there was no warning), and any of the rules indicates a disallow action, the post will be rejected and the disallow message will be shown. In all other cases, all of the actions are performed -- so if a comment matches two rules with auto-flag set, it will be flagged as abuse twice.

Filter Releases[edit | edit source]

In the first release of this feature, we are only implementing two filters (#460 Feedback: Common Vandalism and #463 Feedback: Adding email addresses). The first filter (#460) is supposed to disallow posts that contain obscenities and vandalism (but doesn't do that very well), while the second filter (#463) now displays a warning for posts that contain email addresses, as well as auto-flag them. Both filters display the Disallow or Warning messages specified above, as well as a link to feedback guidelines. All other filters used during testing have been disabled. Future releases may include more filters and more actions, at the community's discretion.

Spam filters[edit | edit source]

We also plan to use the popular SpamBlacklist extension by Tim Starling to filter any post that contains a link to a known spam site. That extension will be tested in upcoming releases of this feature.


Feedback Logs and Emails[edit | edit source]

Here are requirements for central feedback logs and a couple related features, which take place in other parts of the site.

Article Feedback Activity Log[edit | edit source]

The purpose of the central Article Feedback Activity Log is to provide a sitewide listing of all editor actions taken on feedback pages, from across the site. It will enable editors, monitor, oversighters and WMF staff to track all this activity on a single page, which we hope will make their lives easier and the tool more useful. (Note that this central activity log is different from the proposed posts log of all feedback posts that have not yet been monitored - see next section.)

A special Article Feedback Activity Log item is now available on Wikipedia's central log page, where it is visible to all users, using a drop-down menu to filter only log events related to AFT5. This feedback activity log will be based on the exact same technology used by Wikimedia for its other log pages, such as this one for the Moodbar Feedback filter.

This Article Feedback Activity Log will track the following actions: 'feature', 'unfeature', 'mark as resolved', 'unmark as resolved', 'hide', 'unhide', 'request oversight' and 'unrequest oversight'. This public log will NOT display oversight-related actions, and will display them instead in the Suppression log, which is only visible to oversighters and selected WMF staff. They will now see these events in that Suppression log: 'oversight', 'un-oversight', as well as 'decline oversight'.

For each such action, it will provide these data: action date, user name of person who took the action, action taken, user name of person who posted the feedback, article name, post ID, action note (if any).

Here is the proposed new format for this centralized AFT5 activity log:

19:12, 6 April 2012 Fabrice Florin (talk | contribs) hid feedback post #4654 on Mitt Romney: "I am hiding this post because the user is SHOUTING opinions and not making any sense. Though this quote is particularly humorous: WHAT EVER HAPPENED TO THE HIPPOCRATIC OAT?"

The pseudo-code for this request would look like this:

<date> <user name> (<talk> | <contribs>) <action taken> <feedback post #[post ID]> on <article name>: "<note>"

INSTEAD OF:

<date> <user name> (talk) hid the feedback <permalink>: <note>

The exact messages to display for each action are shown on this Feedback Actions Spreadsheet.

Article Feedback Posts Log[edit | edit source]

The purpose of this proposed Article Feedback Posts Log is to provide a central listing of all feedback posts that have not been oversighted, from across the site. It will enable editors, monitors, oversighters and WMF staff to track an estimated 40,000 posts per day on a single page, which we hope will make it easier to monitor the feedback. (Note that this proposed log is for all 'non-oversighted' posts, making it different from the central activity log above.)

Here is the proposed format for this Article Feedback Posts Log:

<user name> (<talk> | <contribs>) posted <feedback> on <article title>: "<comment>"


































Article Feedback Version 5 Specs: HubFeature RequirementsTechnical DesignTestingExtension Page
Metrics: Data and Metrics PlanClicktrackingVolume AnalysisQuality Assessment
Tools:Wikipedia AFTv5 CategoryWikipedia Data StreamOpen BugsRecent Code ChangesPDF Prototype
Community: MW talk pageIdeas LogWikipedia talk page