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)