Talk:Article feedback/Version 5/Feature Requirements

Feedback page

This is so awesome! You probably thought of this (and it could be covered somewhere in all this thorough text that I skimmed over), but one thing that seems like it would be really cool for the Feedback Page is to have a place to mark whether or not a comment was incorporated into the article. For example, for the San Francisco article, there is a comment that says a person did not find the "List of Sister Cities." As an editor, it would be great if I added this part to the article itself, and then checked-it-off on the feedback page. Jwild 19:36, 2 February 2012 (UTC)

Comments on Abuse Filter Requirements

Thanks Fabrice for putting this together. Here are some comments. In general, I'd like to simplify things as much as possible for the first release. This area of the product is by nature complex, so I'd like for us to be diligent about managing the scope.

• Filter actions: I think the notion of being able to provide filter actions that depend on the severity of the abuse is an interesting one, but I'd recommend we keep things simple for the first iteration of the feature, using a single filter action to cover all cases as a starting point. Can you and Oliver come up with a recommendation for this action?
• Feedback guidelines: I like the idea of educating the user about what's appropriate. I'd avoid describing the filters as that will just enable vandals to get around them.

Howief (talk) 17:34, 30 March 2012 (UTC)

Manual override of spam filters

The "Disallow" action in the spam filter should never prevent the feedback to be posted; human intervention should always be ultimately required to ban user posts, we can't rely solely on automated judgement for that. The potential for false positives that forbid posting a legitimate comment is too high.

When feedback matches the disallow rules, the user should be warned but given the option to "Post the comment anyway"; it's OK in that case to flag the feedback as hidden and label it with "automated rejection" for a human to review it later. I.e. the "disallow" mode would work just as the Warn case, but comments matching it would be hidden by default. Diego Moya (talk) 16:36, 10 April 2012 (UTC)

Article Feedback Posts Log

I'm glad to see the notion of a post log being incorporated here, as I believe it will be beneficial for attracting editors to read and consider the feedback provided by readers - and (one hopes) to encourage editors to incorporate featured or helpful feedback into an article. I would suggest, however, that "featured" posts continue to be shown in the log until or unless they have been marked as "resolved". This would keep an unresolved but still featured feedback post from being dropped from the list before someone actions it. This is the kind of feedback post that will draw uninvolved but skilled editors to an article, and attracting this group of editors will be important in the success of the feedback tool. I think the "centralized log" will be a good way to help build the links between the community and the readers. Risker (talk) 02:39, 12 April 2012 (UTC)

Consolidated hide tools

I understand the desire to "simplify the interaction model by grouping moderation actions in a way that map better with user intents". While I do agree that the proposal to group several actions under "Hide" simplifies the interaction model, I'm not sure it maps better with user intents.

In the proposed model, "Hide" is the primary action, with the other actions being subsidiary. In other words:

• I want to hide this post because it has been resolved.
• I want to hide this post because it is not usable.
• I want to hide this post because it is inappropriate.

While I think this works for for "not usable" and "inappropriate", it doesn't work quite as well for "Resolved." Compare the following:

• I want to hide this post because it has been resolved.
• I want to make this post as resolved (and it will also be hidden as a result of marking as resolved).

In the first case, hiding is the primary action and in the second case, marking as resolved is the primary action. For example, take a look at this feedback on the Barack Obama feedback page. This post suggests that the article should include Obama's position on same-sex marriage and User: OwenBlacker featured the post on July 18. The article at the time actually had this information. A few days later, another editor (User: Innotata) marked this featured post as resolved. In my opinion, the intent of User: Innotata's action was closer to wanting to resolve the issue rather than to hide the post. It would be good to get some quick feedback from actual users on whether this is the case.

Secondly, we're mixing valences quite a bit. As is pointed out, the three options under hide are: 'resolved' (good), 'not usable' (neutral), 'inappropriate' (bad). The primary action, however, is "Hide" which has a negative valence, at least in terms of how it seems to be used ("harmful comments need to be hidden." IMO, it's a bit strange to have a primary action with a negative valence when the subsidiary actions range from good to bad.

These design decisions are a matter of tradeoffs, so I'm not suggesting a particular course of action. I would, however, like to make sure that these factors are considered and that we have a clear rationale for the decision. Howief (talk) 06:00, 21 November 2012 (UTC)

Thanks, Howie, you make some really good points above. I reached a similar conclusion this evening.

I think the moderator's main intent is to 'Resolve this post' -- which should be the primary action, with 'Hide' / 'Inappropriate' as a secondary action.

This maps well with the mental model which community leader Risker expresses in her post above, where she describes posts as either 'featured,' 'resolved' or 'unresolved'.

With that in mind, here's another way to present this feature to the user:

Resolve as:

* Fixed

* Unusable

* Inappropriate

This approach has several benefits, which address most issues noted above:

• it maps more closely with the user's expectation
• it extends the meaning of 'Resolve' to cover a wider range of actions
• it tracks whether or not the feedback was used ('Fixed')
• it lets use the 'Hide' action more selectively (e.g.: for 'Inappropriate', but not 'Fixed')
• it uses a more neutral term ('Resolve') to cover both positive and negative actions

Coincidentally, the 'Fixed' action was specifically requested by Jwild in her post above, as well as other editors in our AFT5 talk page archives. This action is also essential for measuring the impact of article feedback, by tracking how many fixes were made to articles thanks to this tool. (Alternative names for this action could be: 'Done', 'Improved article' or 'Used in article' -- if we think 'Fixed' is too narrow).

What do you think of this new direction?

Fabrice Florin (WMF) (talk) 09:50, 21 November 2012 (UTC)

I agree with the concerns with "hide". I initially proposed "close" but "Resolve" can work too in my opinion.

Pginer (talk) 12:36, 21 November 2012 (UTC)

"Discuss on talk page" - Moving of feedback to the talk page

I like this idea, please realize it! I used the existing script for German Wikipedia already a few times, when I thought the feedback should be discussed on the talk page. --Miss-Sophie (talk) 11:54, 17 February 2013 (UTC)

Watchlist for feedback

• I cannot find a way to keep a watch on the feedback on articles for which I have enabled feedback on en:WP other than physically checking each article. This takes a lot of time, and as there is usually no feedback since I last looked, the time is totally wasted. This is not an effective use of editing time.
• It is also pointless looking at the main feedback page, as almost all of the feedback is on subjects I do not know enough about to assess, or don't care about at all. The ones I am interested in are few and far between when they actually exist, and then only a few are actually useful. This is also an unacceptable waste of my time, even worse than the case for manually checking every article, because in that case I can actually tell when I have finished checking.
• Notifying me only of feedback that has been tagged as useful is beside the point. Firstly, I want to make that decision myself, secondly, that way I will never be notified of feedback which has not been moderated, and as there may not be anyone else who is moderating the pages I watch it would then be lost completely, which is a waste of the person who made the feedback's time.
• There is an urgent requirement for a way of keeping track of new feedback on only the articles that one is interested in. I would be happy to see them in my regular watchlist, on a separate watchlist or on echo. I would even tolerate an e-mail notification, though that could easily get a bit over the top.
• Lack of notification is crippling the feature. Pbsouthwood (talk) 09:48, 31 August 2013 (UTC)

Enable/disable feedback on a page, is MediaWiki 1.22.x required?

I've been playing around with implementing AFT on a non-Wikipedia site and the new Enable/disable feedback on a page is a great feature IMHO. From my read of repo summary, I need the R1_22 branch of the extension to use this functionality. Is it compatible with MediaWiki 1.21.3? Is this documented anywhere?

Based on my experience it is not. When used it causes the page to hang. I've checked the httpd logs and found I'm getting:

PHP Fatal error:  Call to undefined method WikiPage::insertProtectNullRevision() 
in /var/www/html/f/extensions/ArticleFeedbackv5/ArticleFeedbackv5.permissions.php on line 248

I googled and the method WikiPage::insertProtectNullRevision doesn't seem to exist in MediaWiki 1.21.3.

--Peculiar Investor (talk) 18:02, 18 November 2013 (UTC)