Wikipedia:Article Feedback/Feedback response guidelines

No formally adopted guidelines exist to guide those editors interacting with the Article Feedback pages on how to respond to different types of potentially problematic feedback. The following is a draft version of a guideline.

For information on how the tools on the Feedback pages work, please see Wikipedia:Article Feedback/Help/Monitors.

This is a draft of the current guidelines. Non-minor changes should have consensus on the talk page.

Featuring and resolving feedback

Featuring

Any feedback which is reasonably actionable, may be useful to the community, is likely to improve the article and at some point is likely to be marked resolved either as done or as rejected (as opposed to unuseful), should be featured. The format of the feedback (such as whether it is all in capitals or not) should not be considered when deciding whether to feature or not.

If a user continually features unhelpful feedback, the community may come to a consensus to ban the user from participating in Article Feedback. Discussions of this nature should take place at the Administrators' noticeboard/Incidents.

Resolving

Users are encouraged to look through featured feedback and see if they can make the suggested changes (etc.) to the article. When the suggested change is completed, the feedback should be marked as resolved (please include the diff)

Feedback should be marked as resolved if it has already been fulfilled (that is, it is already in the article). Feedback should also be marked as resolved if it includes a reasonable suggestion (which would normally meet the conditions for featuring) but is clearly not going to be fulfilled on policy grounds (please also state the policy as a comment when you mark it as resolved).

Marking feedback as un/helpful

Marking feedback as helpful or unhelpful does not affect its appearance, only the percentage shown below the feedback.

Mark feedback as unhelpful if it does not contribute to the development of the article (such as "Justin Bieber is great" or "ksnknck"), if the feedback submission should hidden according to the criteria do that instead.

Mark feedback as helpful if it is generally helpful, but not likely to be marked as resolved in the future.

Hiding and unhiding feedback

Hiding is different from simply reverting, it is more akin to a revision deletion. Only monitors (editors in the adminstrator, reviewer and rollbacker user groups) are able to hide feedback and see feedback once hidden. Generally, only the following should be hidden:

H1 Copyright violations.

H2 Insulting, degrading, or offensive material, allegations, harassment, threats or attacks including personal attacks directed at specific editors or Wikipedia editors in general (this criterion should be interpreted liberally).

H3 Purely disruptive material that is of little or no relevance or merit to the project. This includes nonsensical text (such as aksnksckdjdvfpqsk), browser-crashing or malicious HTML or CSS, shock or phishing submissions, and spam links (which are not related to the article).

H4 Personal information not serious enough to be oversighted (such as email address, which do not include real names or other identifiable material).

H5 BLP violations which are not serious enough to be oversighted.

H6 Duplicate feedback submissions by the same user on the same article may be hidden if they provide the same or similar information provided in their duplicates. Monitors should determine whether the most detailed or the most recent feedback submission will be left unhidden. This criterion should be used only when another criterion would not justify the feedback submission being hidden. That is, if H2 applies to one or some of the submissions, use it first, then use this critera if there are still duplicates.

H7 Non-contentious housekeeping including correction of clear and obvious unintended mistakes in previous hides, changes to hides based upon communal discussion and clear consensus, adding information to the notes, hiding blank feedback.

H8 Ignore all rules. Monitors are encouraged to use their own judgement and discretion when assessing whether a submission should be hidden or not. If you are unsure, mark it as abuse, as this filter will usually be viewed by other monitors, or hide it and leave an explanatory reason.

Monitors are strongly advised to make reference to the above reasons by adding a note when prompted. They are anchored as H#, for example WP:AFT5G#H2.

The ability to hide feedback is inherited from other user permissions. If an editor is hiding feedback inappropriately, and the issue cannot be resolved through discussion, the ability to hide feedback may be removed using the normal process for removing the parent right that is granting the ability to hide.

Feedback submitters, if you believe your feedback has been hidden incorrectly, please leave a message at the AFT5 noticeboard.

Requesting oversight

According to the usual oversight policy, Oversight should be requested on feedback which contains non-public personal information, such as phone numbers, home addresses, workplaces, schools or identities of pseudonymous or anonymous individuals who have not made their identity public. This includes hiding the IP data of editors who accidentally logged out and thus inadvertently revealed their own IP addresses. Suppression is a tool of first resort in removing this information

Email addresses should be hidden, but Oversight should not generally be requested unless the email address contains identifiable information.

If in doubt it is better to request Oversight and leave the decision up to the Oversighter, rather than not request it and have potentially problematic information stay live.

Once a feedback submission has its initial Oversight request declined, Oversight should not be re-requested. If a monitor feels that it should have been Oversighted they may re-request Oversight using the tool leaving a detailed reason.

Feedback protection

Note: this section does not have any consensus yet.
The feedback form on any article can be disabled by users in the admin user group. Admins may protect an article against feedback (called feedback protection) when the vast majority of feedback submissions on that article are hidden according to the above criteria. The time frame used to judge this is up to the admin, but should be no less than one week. For articles (particularly BLPs) which have had a number of submissions hidden under critera H1, H2, and/or H5, the "vast majority" requirement may be relaxed, to a level decided on by the admin. Any article may be feedback protected after a consensus amongst monitors is achieved on the Monitor's Noticeboard.

Conflict of interest

In general, an editor should not use any auto/confirmed (for example, featuring feedback) or monitor (for example, unhiding feedback) tools on feedback they submit, with the exception of hiding feedback that they submitted with their own account.

Wheel warring

The requirements listed at WP:Adminstrators#Reinstating a reverted action ("Wheel warring") are applied to all actions by monitors (that is the word "administrator" is replaced by "monitor").

In general, if a monitor has already reversed a monitor action (for example, hiding feedback), there is very rarely any valid reason for the original or another monitor to reinstate the same or similar action again without clear discussion leading to a consensus decision. Discussion of this sort should take place on the AFT5 noticeboard.

Sanctions will vary depending on whether the users involved are admins or reviewers/rollbackers. Admins are subject to the conditions at WP:WHEEL, so usually in an immediate Request for Arbitration. Reviewers and rollbackers may have these rights removed by an uninvolved admin; whether removal comes before or after discussion at Administrators' noticeboard/Incidents would depend on the extent of the wheel-warring.