Wikipedia:Requests for comment/Article feedback

This is a requests for comment about article feedback.

Background

What is being discussed here.

For over a year, the Wikimedia Foundation has placed a comments box on selected articles that allows readers and other page viewers to add feedback (comments) to articles. This is colloquially known as article feedback. A feed of these comments is available at Special:ArticleFeedbackv5.

The Wikimedia Foundation plans to expand this feedback box to all articles on the English Wikipedia by the end of March 2013.

The purpose of this request for comment is to determine the answer to a few questions:

1. What should the scope of the article feedback tool be (cover all articles, opt-in per article, etc.)?
2. Are there sufficient resources to moderate and respond to all of the feedback?
3. How will abuse filters handle articles in which the subject's title contains a disallowed word (e.g., Blue-footed Booby + "boob")?
4. Will the tool continue to only be a(n expanded) box or will it go more minimal? Will it go "above the fold" (e.g., File:Article-link-to-feedback.png)?

Users are encouraged to sign below supporting a particular view or to add their own view.

View by MZMcBride

There are currently insufficient resources to moderate and respond to article feedback for all articles. Consequently, the article feedback tool should be available as an opt-in feature on a per-article basis, allowing individual interested editors to receive feedback on articles that they are willing to monitor and respond to.

The design of the article feedback tool should be as minimally intrusive as possible, recognizing that the content area of articles is sacrosanct. Comments should never appear below an article and the tool itself should be positioned in an inconspicuous place to avoid disruption to readers.

Users who endorse this view

1. MZMcBride (talk) 01:33, 21 January 2013 (UTC)
2. Support - I'd add that article feedback as a concept seems to have started as a trick to get people involved in editing Wikipedia, that this experiment has not produced demonstrably positive results, that the comments generated are essentially garbage, that the feedback boxes are disruptively large, and that the whole exercise is a waste of time at this point. "Opt-in" and "Make smaller" are probably the closest principles to this view that have a chance of gaining sufficient support, however, so I will endorse those. Carrite (talk) 01:52, 21 January 2013 (UTC)
3. Weak support - The article feedback tool is a hive of vandalism and crap. At least this is a step towards deleting it. Reaper Eternal (talk) 03:27, 21 January 2013 (UTC)
4. Support. The feedback tool should only be implemented on an article if there is at least one editor who is willing to monitor the feedback. I have other concerns, but will express them in another section.--Srleffler (talk) 04:00, 21 January 2013 (UTC)
5. Agreed I clicked the "Feedback from my watched pages" link once on a whim and not only found not a single useful comment, but the majority of what was there was people wanting the lyrics to a particular song (which would of course have been a copyvio). Not just unhelpful but actively discouraging. Andrew Lenahan - Starblind 05:33, 21 January 2013 (UTC)

Comments

• What happens if two editors of an article disagree over whether they want the feedback box to be included? Also, it seems to be a question of will rather than resources. Finally, I find that allowing editors to decide whether they want feedback in "their" article undesirably promotes WP:OWNership.AgnosticAphid talk 01:12, 18 January 2013 (UTC)
  • If two editors are in disagreement, they do what you do in the case of any other article-related disagreement: take it to the talk page. :-)

    I understand the distinction you're trying to make between will and resources, I think. You're saying that Wikipedia does have the resources (enough man-power), but the resources just won't be allocated in this way (there's not enough will or determination from editors to actively monitor the feedback)? I can't say I disagree, but I think that still qualifies as having insufficient resources, if the resources are unavailable, as I wrote. I'm more than open to better phrasing, though. What do you have in mind?

    Regarding article ownership, I think many editors take pride in their work. We see this more clearly in featured articles, but it's still true through the entire project. WP:OWN is about controlling the content of the article in an unfair way, it's not about taking pride in your work or protecting it. --MZMcBride (talk) 01:20, 18 January 2013 (UTC)

    • I guess I feel like saying we have insufficient "resources" implies it's not possible to monitor the feedback whereas I think the issue you're referencing is that people don't seem to want to monitor the feedback. The former would be an inherent problem with feedback; the latter could be because the tool is new or unfamiliar and might not always remain the case. To be honest, though, in my limited time spent reviewing feedback I haven't even noticed that there is a lack of will.

      My issue with a disagreement over inclusion of the tool is that there seems to be no real basis to resolve a disagreement over whether the tool should be used. Wouldn't the arguments always be "I don't like it" vs "it seems useful to me!"? And then it seems like the default would have to be, just don't include it if editors disagree.

      W/r/t ownership, it came to my mind because I saw that on the main article feedback talk page that some people were requesting to add "their" articles to the feedback blacklist. I don't wish to see an undesirable tool shoved down anyone's throat, which would probably cause a loss of editors, but if the project as a whole thinks that it is valuable to allow anonymous editors to more easily comment upon article quality, why should a single editor be able to decide that for aesthetic or other reasons that "their" article doesn't get feedback and keeps the pretty useless "rate this page!" box instead? It kind of seems like this is allowing a sort of "local consensus" on the feedback tool for each article. I don't think I'm expressing myself very well on this latter point, to be honest. AgnosticAphid talk 09:08, 18 January 2013 (UTC).

      P.S. I apologize if I'm not supposed to comment on the views before the RFC actually starts. I'm not ver experienced and i found myself not quite agreeing with either view presented; yet I don't feel confident writing a view of my own. But it seems I've spilled a lot of "ink" already; I hope it's not off-putting. AgnosticAphid talk 09:15, 18 January 2013 (UTC)

      • Regarding responding to feedback, as I read the stats, only 11% of feedback is moderated within a month. (I'm not a stats guy, so if I'm wrong about the conclusion I'm drawing, please let me know.)

        I don't think arguments would (or should, I suppose) include "I don't like it" or similar. The feedback from the tool itself should be able to stand on its own, I think. Editors are able to look at the feedback being received and evaluate whether it's serving its purpose to create a better encyclopedia. I doubt there would be (m)any disputes, though perhaps I'm being overly optimistic. :-)

        I agree that the ratings box (a.k.a. ArticleFeedback, as opposed to ArticleFeedbackv5) is pretty useless. I believe it will be disabled shortly, as it's no longer supported and the data it's collecting is not even being monitored or used, I'm told. I can say that "local consensus" (or an "article-by-article" approach) has been strongly advocated for in the past for certain issues as it's often an effective means to prevent a more top-down, forceful approach to articles.

        Absolutely no worries regarding "spilled ink." As I said below, I think having comments prior to beginning of endorsing/supporting individual views is a really good thing. I don't find it off-putting at all. Thank you for taking the time to post your thoughts; they've been helpful for me to read. --MZMcBride (talk) 16:48, 18 January 2013 (UTC)

• I don't see why editors A and B should be able to decide that editor C can't receive feedback on article X simply because A and B don't want to deal with it. Perhaps A and B should be able to enable a user preference that hides the feedback box and links for them only? --Aurochs (Talk | Block) 19:36, 18 January 2013 (UTC)
  • I agree. I don't see why editors A and B would have an issue with receiving feedback if it's useful, helps in building a free encyclopedia, and there's a willing editor (editor C) who has volunteered to respond to the feedback. My concern is not this scenario. My concern is a very plausible scenario in which there are mounting piles of feedback on millions of articles that will receive no attention from anyone. Even during this extended trial period, we've seen thousands of articles with feedback that goes un-responded to. I think this is unfair to the people leaving feedback and I think it creates a lot more potential harm (from bad feedback [vandalism, libel, etc.] that lingers) than potential good. --MZMcBride (talk) 22:08, 18 January 2013 (UTC)
    • It is likely that the current backlog of feedback exists mostly because most of our editors are not familiar with AFT5 or how to use it. The WMF has done practically no publicity work for this tool during the beta period. I expect a lot more editors will be scrutinizing the feedback once it launches to 100% of en.wiki. Further, there will be a couple of software releases soon that address concerns with usability and the moderating tools we have available right now, which might also help engage editors with moderating feedback. Finally, an at-will opt-out just doesn't seem to be a very good way to address this concern. It would probably exacerbate the issue on those articles that continue to carry AFT5. Editors would probably become less interested in working with feedback, since it wouldn't consistently be there to work with.

Wrt editors A and B, your proposal will almost certainly create the exact situation that I described. Editors steamroll each other all the time, for the stupidest of reasons. And what if A and B are unanimous, and then they decide to leave the project 8 months later? Editor C will land on article X and find that there's been no feedback for the past 8 months that he could use to improve it. --Aurochs (Talk | Block) 01:58, 19 January 2013 (UTC)

I'm going to take exception to your comment that the WMF has done nothing to advertise AFT5; it's actually been better advertised than almost all "new" extensions or UI changes I've seen in the past 5 years. Risker (talk) 02:02, 19 January 2013 (UTC)

The only reason I ever heard of AFT5 is because I clicked the little link at the top of my watchlist. Otherwise, the only publicity I've seen on this wiki has been on pages dedicated to the tool itself. If I missed something, please let me know, but me missing things doesn't speak volumes about the quality of the publicity. --Aurochs (Talk | Block) 15:08, 19 January 2013 (UTC)

In a vacuum, I'd say that putting a prominent link on the watchlist of the English Wikipedia is a pretty high level of publicity. But I understand various mitigating factors here. --MZMcBride (talk) 17:44, 20 January 2013 (UTC)

View by Nyttend

We don't have enough resources to moderate and respond to article feedback for all articles in a rapid manner. However, widening this tool's use to all articles will be in the spirit of "given enough eyes, all bugs are shallow"; better to make a late fix than to make no fix at all. Do what we can to increase editing, there are always going to be people who won't want to edit a page but who will be happy to leave comments. We should encourage them to help, even when we can't address their concerns immediately. The design of the article feedback tool should be as minimally intrusive as possible etc.; no disagreement with MZMcBride's second paragraph.

Users who endorse this view

1. ...

Comments

You're not concerned about Wikipedia hosting publicly visible libel or vandalism for months or years? You make a very reasonable point regarding feedback and the lack of a deadline, but in some ways—and I say this with all due respect—your view makes me think you're operating with a romanticized view of the feedback that's actually being collected. --MZMcBride (talk) 04:05, 18 January 2013 (UTC)

Not particularly romanticised; I just don't see a big difference between this and vandalism to or libel in the article itself. Vandalism to the article itself is visible to everyone easily, unlike feedback, which you can't find as easily if you don't know where to look. I don't particularly see why we should trust Internet canines to edit our articles but not to leave comments on them. Nyttend (talk) 04:52, 18 January 2013 (UTC) Are we really supposed to start commenting before the start of the RFC? If so, what's the difference between an opened and a not-yet-opened RFC? Not objecting to having this discussion; I just wonder if we should move it to the talk page.

No idea. The only difference is that there is a little "comment period" before endorsing actually begins, which I think is a good thing™. Legoktm (talk) 09:29, 18 January 2013 (UTC)

The idea behind a drafting period was to prevent the possibility of first-mover advantage. It helps to have a few views for people to compare and digest before endorsing/supporting/voting gets started. I think comments during this time are more than fine: they allow feedback on the views so that the views can be adjusted prior to endorsing. This is much better than attempting to rewrite views after people have signed on to them, I think. --MZMcBride (talk) 15:01, 18 January 2013 (UTC)

The feedback tool's current design makes it less likely that feedback will be read and responded to. Feedback is less visible to editors than an edit to the article or its talk page (feedback on an article does not show up in editors' watch pages, and is visible only if they go looking for feedback). It is thus more likely to accumulate inappropriate material. --Srleffler (talk) 04:04, 21 January 2013 (UTC)

View by Aurochs

No, we do not have enough resources to moderate and respond to all the feedback. We don't have enough resources to edit articles either. Wikipedia is a volunteer project, and no initiative we roll out will ever see 100% utilization. However, AFT5 can be seen as an attempt to deal with the resources we have more effectively, because it will help us focus our editing resources where they actually matter for readers.

In addition to the possibility of disputes between individual editors that AgnosticAphid pointed out above, I'm also concerned that allowing at-will opt-out for AFT5 will provide yet another place for WikiProjects to bicker with each other and individual editors, and it will confuse the user experience for the people who leave feedback. ("This article doesn't have a feedback box but all the other articles I've read today do. WTF is going on here?" That seems like a crummy thing to do to our readers based on one editor's personal preference.) It also sounds like an easy way for people to vandalize articles. If the feedback tool is implemented as a patchwork only on certain articles, I fear that editors will become less driven to read and moderate it, because it's not always there for them to moderate, and they may have to get into fights with other editors just to receive it. Finally, we cannot use AFT5 to improve an article that has been blacklisted.

For these reasons, I believe that AFT5 should be rolled out 100% to all mainspace articles. There is already a protection mechanism built into the tool (see Okeyes' view below), so if necessary, it could be disabled on an exceptional basis, but this should be used only when a clear set of objective criteria have been met.

I agree that feedback comments should never appear on the article page, and the feedback box probably doesn't need to be made any more conspicuous than it already is.

Users who endorse this view

1. Aurochs (Talk | Block) 03:30, 21 January 2013 (UTC)

Comments

How will it allow us to focus our editing resources ? In order to do that, you need to process the data, and for that you need resources. So at some point you need to divert human resources, for which benefit ? It would have to be analyzed. From what I see, not one in fifteen comments are potentially helpful with respect to the stated objective of readers to contribute productively to building the encyclopedia (even though it's already filtered). Does the benefit of having this information outweigh the cost of processing it ? Considering that most of the suggestions provided would be evident to any minimally experienced editor ('not enough information'), or unfeasible for policy or practical reasons, I have doubts. Of the rest that can be helpful, I'm afraid there is a way too small probability that the request can get to someone who would be able to fulfill it. Of course some bots could make some basic processing, for example when 'image' or 'picture' is in a feedback (as often), it could somehow notify requested pictures because it's very likely that the reader wants one in the article. So it would allow a little focusing of resources in this instance, but I don't see much other examples. And then it would be easier to just have a 'request picture' function. Cenarium (talk) 06:03, 20 January 2013 (UTC)

First, it doesn't take very much time or effort to read the feedback and come to a conclusion about how the readers feel about an article. These aren't PhD dissertations, they're short comments. So no, I don't think the cost of processing it is very high. Second, the suggestions provided by feedbackers are not always "self-evident" - it's not always obvious to us as editors that a particular article needs more images or that it's not detailed enough. I feel like you're really dramatically underestimating the proportion of helpful feedback. I have personally made a number of article edits and even proposed a move based on information posted to feedback. The feedback tool also gives us a better idea of who our readers are, which is something we haven't ever really known (and which is very useful for writing great prose). Finally, editors can browse the list of all feedback and find something they can fix themselves, much the same way people currently monitor recent changes to spot vandalism. --Aurochs (Talk | Block) 16:43, 20 January 2013 (UTC)

The "crummy" user experience you describe is just the status quo: The feedback box only appears on selected articles at present. If feedback were opt-in, implemented only when there is an editor willing to monitor it, the user experience would not be any worse than it is now. The user experience would be improved, since any feedback they leave would be read and responded to if approriate, compared to the present really crummy user experience, which is that in most cases feedback receives no response at all, and may well not be read by anyone. --Srleffler (talk) 04:11, 21 January 2013 (UTC)

I will comment on this in your own view below, in order to keep the conversation together. --Aurochs (Talk | Block) 04:41, 21 January 2013 (UTC)

Actually, you didn't mention this in your view, so I'll respond to it here. Here's the problem I see with the opt-in proposal: Suppose that a reader leaves feedback on an article. Nobody with that article on their watchlist pays attention to feedback, so it languishes for a few months. Then an outside editor comes across the article, thinks they may be interested in editing it, and checks the feedback listing. S/he finds the feedback left months before, and uses it to improve the article. This is not possible under the opt-in system - that feedback will simply not be left, and the editor will have nothing to go by but the seat of his pants. Further, AFT5 can be an avenue for article discovery, but not if an opt-in system is used. --Aurochs (Talk | Block) 04:49, 21 January 2013 (UTC)

View by Mike Cline

I talked at length last year at Wikimania with the lead of this project and came away feeling there was a tremendous upside potential for this tool. Eventually it will become a tremendous source of data on how the reader community (10,000X larger than the editor community) views wikipedia. So the benefit will accrue long-term to not only article improvement, but to improvements in policies and guidelines based on emphirical data from the reader community. Asthetics and resource issues aside, in no way should there be an opt-out for any article, except under extreme and compelling circumstances. The data this tool generates in the future should be based on the holistic locus of WP articles. --Mike Cline (talk) 16:49, 18 January 2013 (UTC)

Users who endorse this view

1. Considering what has occurred with adding revision reviews, I believe that adding this to all article would be an overall benefit to Wikipedia. --Super Goku V (talk) 01:58, 21 January 2013 (UTC)
2. This is another side of my own view posted above, so I, of course, endorse it. --Aurochs (Talk | Block) 03:09, 21 January 2013 (UTC)

Comments

View By Beeblebrox

This RFC came up in some comments on the functionaries mailing list. i cannot claim to speak for the entire oversight team in this matter, but I am concerned that there will be a flood of unactionable requests for oversight if this tool is brought into wider service. The reason I have this concern is that we regularly get such requests now with just the limited deployment. The only fix I have seen floated for this is a whole new user right just for suppressing feedback I personally think that is a solution that completely ignores the nature of the problem. The suppression policy applies equally to feedback and actual content, so those entrusted with this new right would still need to be vetted as oversighters. I would like the policy for requesting suppression of feedback to be very, very clear that suppression is warranted only for a very small minority of edits, and that most kinds of vandalism, including BLP violations, do not qualify. Education is the only way to resolve this issue. I have been on a bit of a campaign already to personally speak to users who make invallid requests to suppress feedback and feel it has put a dent in the number of bad requests we get, but I'm only one person and cannot hope to keep up with personally notifying every last person who makes an invalid request if the use of feedback tool is expanded.

TLDR version Feedback reviewers need to have it made very clear to them that suppression is not for "normal" vandalism. Beeblebrox (talk) 21:52, 20 January 2013 (UTC)

Users who endorse this view

1. Beeblebrox (talk) 03:27, 21 January 2013 (UTC)
2. Agreed. Any usage of revdel, suppression, etc should be exactly the same as if they had edited a talk page. Legoktm (talk) 03:31, 21 January 2013 (UTC)

Discussion

Why do we need an RfC for this? Whereas this is a clear and valid statement, is not it best done by bot posting on talk pages for instance? Or do you intend to change smth in the policy?--Ymblanter (talk) 22:32, 20 January 2013 (UTC)

I intend to see if there is a consensus that education on this issue is an imperative part of expanding use of the tool. As far as I can tell this is a general RFC on the use of AFT, I am not aware of any restriction that says all views must propose a change in policy. Beeblebrox (talk) 03:27, 21 January 2013 (UTC)

Given that there has never been any formal policy on AFT, I think this fits in with the scope of the RFC. Legoktm (talk) 03:32, 21 January 2013 (UTC)

Commenting briefly; I think Max intends for this to be an RfC covering the scope of the deployment of AFT5. I'm always happy to receive feedback (you'd note that last time the functionaries brought this problem up with us, we invested developer resources in educating editors about what 'oversight' was for) but splitting the RfC off 15 ways may lead to a no-overall-consensus thing, or, a 15-different-consensuses thing :P. Okeyes (WMF) (talk) 03:34, 21 January 2013 (UTC)

I do not mind discussing it here, it just seems to me that the issue is already covered by existing policies (suppression policy), and should just be enforced.--Ymblanter (talk) 08:01, 21 January 2013 (UTC)

• A quick comment here. (I do think this is somewhat relevant to the RFC as it is another manner in which volunteer resources are being used by the AFT5 project.) I took a look at the last 45 days of suppression requests that came in via email to the Oversight OTRS queue; I also did a sample of 45 days prior to when the software was set up for our oversighters to handle suppression requests from AFT5, which automatically sends an email to the OTRS queue. There was no statistically significant increase in requests submitted via OTRS (bearing in mind that there is a +/- 15% variation in requests month over month); in the last 45 days, approximately 28% of requests originated from AFT5. Statistical data including frequency of suppressions is available here with prior months available in the page history, and does not show any statistically significant change in the frequency of suppressions over the past two years. Based on this limited sample, it does not appear that including AFT5 on 10% of the articles has had a significant effect on the number of *emailed* suppression requests, or the frequency of suppressions.

  It is important to note that an unquantifiable percentage of suppression requests are made outside of the OTRS system, and that the average number of suppressions has not significantly changed. It's very difficult to give a full picture of the workload of oversighters, because a significant portion of emailed requests in particular result in multiple suppressions, while an equally significant percentage of requests (from all sources) result in no suppressions. It is also very difficult to predict whether or not we will see an increase in suppression requests from AFT5, because those requests are entirely dependent on the moderation of individual comments, and it's not obvious that the number of comments that get moderated will change. Risker (talk) 08:11, 21 January 2013 (UTC)

View By GregJackP

The tool is useless. Most of the comments are not even actionable. Additionally, wading through the inane comments to get to one to work on wastes time, and we don't have enough resources to handle it as it, much less by expanding it. We should eliminate the feature.

Users who endorse this view

1. GregJackP Boomer! 02:16, 21 January 2013 (UTC), as proposer.
2. Strongly support getting rid of AFT in any and all forms. I would propose this myself if you hadn't. Reaper Eternal (talk) 03:29, 21 January 2013 (UTC)
3. "Useless" is a little strong. I would've recommended this as a view, but I felt it wasn't tenable (politically, I suppose). That said, I can support this option. --MZMcBride (talk) 03:42, 21 January 2013 (UTC)
4. Strong support - OK, "next to useless" instead of "useless, perhaps, but whatever description is used, it's an unnecessary burden on our resources. Beyond My Ken (talk) 04:49, 21 January 2013 (UTC)
5. Strong Support it should be eliminated or, at the very most, used on rare occasion to invite public comment on contentious articles. It certainly hasn't been shown to be helpful so far, and if it does 'take off' so to speak who's going to volunteer to sift through the litterbox to get rid of all the spam, BLP violations, etc? Andrew Lenahan - Starblind 05:28, 21 January 2013 (UTC)

Comments

• @ MZM - I think you know I'm not always known for my tact. :D GregJackP Boomer! 03:46, 21 January 2013 (UTC)
• While very few feedback comments provide specific, directly actionable feedback, almost all of them reveal something about the article they're attached to that is helpful for us as editors to know. It is also extremely unlikely that the WMF is going to abandon this after over a year of development. --Aurochs (Talk | Block) 03:55, 21 January 2013 (UTC)

• I don't disagree that it won't go away, but if they don't want to know our opinion, they (WMF or whomever) shouldn't ask. This is just my 2 cents. Regards, GregJackP Boomer! 04:05, 21 January 2013 (UTC)

View by Okeyes (WMF)

This RfC raises a lot of interesting questions: I'll do my best to answer them, bit by bit, but I'd like to start with a "how do I see AFT5?" schpiel. Obviously, I'm supportive of it ;p.

We started working on this tool over a year ago, with a couple of objectives: to provide feedback that editors could use to improve articles, and to offer readers a way of contributing to the encyclopaedia and maybe becoming editors. I'd argue that we've succeeded in these goals. The latest research can be found on meta; it shows that on feedback quality, based on evaluation by around 20 long-time editors, between 30 and 60 percent of feedback submitted can be used to improve an article. Of those users who try to sign up and contribute, 66 percent of their edits are helpful (or, at least, not reverted - it's hard to gauge edit helpfulness). We started trying to make a tool that would provide useful feedback and let readers contribute; the tool provides, however you look at it, a lot of useful feedback, and acts as an avenue for readers or first-time editors to make quality contributions.

Along the way we've integrated the spam blacklist, worked in abuse filters so that people can cut out blatantly improper feedback without ever having to bother a feedback patroller with it (in the same way we do edits), and built software so that, on high-volume articles, the feedback tool can be turned off if there are serious problems with contributions people are making. To come, we've got an improved interface that makes getting rid of bad feedback (and highlighting good feedback) easier. We're doing a lot of work to up quality above where it is even now, and make it easier to deal with things that slip through the cracks. I appreciate things aren't perfect right now - as with editing, they never will be.

So, on to the questions.

1. What should the scope of the article feedback tool be (cover all articles, opt-in per article, etc.)?

   As said, we're aiming at 100 percent deployment (with some caveats: as said above, if you've got a high-volume protected page where people are misbehaving, you can turn the tool off). I'm pretty comfortable with this decision, because the alternative (opt-in, rather than opt-out) creates a lot of problems. As AgnosticAphid says above, you're going to encounter quite a few unnecessary disputes - and even if sticking the feedback tool on an article is clearcut, with over 4 million articles (and that's not to mention help pages, which we've enabled the tool for so that editors can tweak help documentation to meet what new editors need need) it's going to take a heck of a long time to manually go through them.

   I appreciate that there are going to be submitted pieces of feedback that are unhelpful or even inappropriate; I think this is inevitable in any open system, just like it's inevitable that we get vandalism. The important thing is having ways to deal with it, be it the tools we've built in, third-party scripts (in the same way we have Huggle or Twinkle) or human intervention. And actually, I think the quality of feedback is going to be higher by volume on the pages we haven't applied the tool to, and the volume itself lower: the way we randomly selected the 10 percent that currently have the tool means that high-traffic pages are overrepresented.

2. Are there sufficient resources to moderate and respond to all of the feedback?

   The honest answer is "probably not", although that's at least in part down to how many people want to use the tool :). But, again, I don't see this as a problem: we're a wiki. Always have been, always will be. Edits will need oversighting or deleting, bad edits will slip through the cracks, and we accept that because it's necessary to produce the good things that an open system gives us. I see no reason not to take the same attitude with feedback.

3. How will abuse filters handle articles in which the subject's title contains a disallowed word (e.g., Blue-footed Booby + "boob")?

   This one I don't know the answer to - I'm not regex-literate (although I'm pretty good with R these days). But my first question would be "how do we handle edits?" Presumably new people try to edit the Blue-footed Booby page; what's our solution there? Either we have a solution, in which we can probably apply it to feedback (feedback falls under abuse filters in the same manner that edits do), or we don't have a solution but the community considers that acceptable, in which case it's not an article feedback-specific problem or a blocker. If it was a blocker, we wouldn't allow non-autoconfirmed editing.

4. Will the tool continue only be a(n expanded) box or will it go more minimal? Will it go "above the fold" (e.g., File:Article-link-to-feedback.png)?

   On the first point - at the moment, the plan is to continue using an expanded box. I'd caution against using a more minimal design: when we tested one we found it actually reduced the quality of submitted feedback. I don't think that's something anyone participating in this RfC wants. In regards to the "above the fold" link; that link is something we're working on, but there are some caveats :). The actual intention of the link isn't to solicit feedback comments - it's simply a link to the feedback page for this article. It would only be visible to editors, and is an attempt to target a possible problem mentioned above of not enough people monitoring feedback. Again, I think supporting better monitoring is something we can all agree is A Good Thing.

With all of these things taken into account, I'm in favour of deploying the tool, although as mentioned that's hardly a surprising statement ;p. I hope others are as well.

I hope I've answered the primary questions. To avoid piling-on or badgering, I'm going to be lurking largely on the talkpage from now on. If you have individual questions about our data/upcoming plans/whatever or seek some clarification, just drop a note there and I'll respond as soon as I can. Thanks :). Okeyes (WMF) (talk) 03:14, 21 January 2013 (UTC)

Users who endorse this view

Comments

The AbuseFilter answer seems like it needs further thought. The issue is that you've currently implemented fairly heavy-handed abuse filters, which are fine for a limited test, but how will people comment on the article cunt or faggot or bitch? Standard editing is not subject to abuse filters like these. Article feedback, however, is subject to very stringent filters. And article feedback will invariably include currently disallowed words. The Blue-footed Booby example was kind of convoluted... the current feedback filters would hit thousands of legitimate article titles and consequently a lot of legitimate feedback. Is there a solution to this? --MZMcBride (talk) 03:52, 21 January 2013 (UTC)

No, although I think perfection is probably beyond any software we write :/. Thousands of articles, possibly - but when we're talking a wiki with 4 million articles that's, what, a 99 percent success rate :). I'm slightly confused by statements that the current abuse filters do not include abuse filters like these: we've got one that hits personal attacks, one that renders Everyone Poops difficult for newcomers to edit, and one that hits two of the three examples you brought up (forgive me if I've read these wrong; as said, regex is not exactly something I'd stick in my C.V. skills section). Okeyes (WMF) (talk) 03:56, 21 January 2013 (UTC)

Additionally, cunt, bitch and faggot are all semi-protected. Apparently, the amount of vandalism they got was greater than the edit filters could handle; perhaps articles like those will also wind up blacklisted from AFT5. --Aurochs (Talk | Block) 04:09, 21 January 2013 (UTC)

I deliberately (and explicitly) had a method of blocking AFT5 built, interlocked with protect options - so it'd be trivial for any admin to turn the tool off in those circumstances, yep. Okeyes (WMF) (talk) 04:14, 21 January 2013 (UTC)

View by Srleffler

While I see the potential for a feedback tool to be useful, I believe that the current implementation fails to achieve this, and may do more harm than good. The feedback tool channels readers who want to comment on an article to leave their comment in a place where it is less likely to be read than the article talk page, and where it is impossible for anyone to respond, either to provide information to the reader or to get more information on the changes they would like to see made to the article. Readers get frustrated because they are being asked to give feedback, but they see quickly that their feedback gets no response.

This problem severely limits the utility of the tool. I do not feel that the tool should be widely deployed until these implementation problems are fixed, and have been beta tested on a small number of articles. This tool is simply not ready for wide deployment, and will do more harm than good to the project.--Srleffler (talk) 04:26, 21 January 2013 (UTC)

Users who endorse this view

Comments

• This argument is undermined by a couple of key facts. First, the strong response to AFT5 relative to talk page comments tells me that readers prefer it greatly over the talk page system. We are not channeling readers away from the talk pages, because chances are pretty damn good that those readers would not have posted on the talk page anyway. Second, the talk page comments that are left by unregistered users are rarely responded to, at least in my experience. I have seen talk page comments willfully ignored by editors who think they're reverting vandalism. --Aurochs (Talk | Block) 05:03, 21 January 2013 (UTC)
  • I agree with your first point, but feel that a different feedback mechanism would better address the clear need for an easy way for readers to leave comments and post questions. For example, the feedback form could automatically create a talk page entry and give the person leaving a comment a link to the correct talk page section. Alternatively, a better feedback system could be devised, which actually meets Wikipedia's needs. I'm not opposed to feedback in general—I'm merely arguing that the current implementation fails to achieve its goals, and may do more harm than good overall.

I think your second point is mistaken, or at least disagrees with my experience. On the articles I edit, useful comments are much more likely to get an appropriate response on the talk page than in the feedback system. The inability to reply is a key problem: I have seen many feedback messages where the reader clearly had an idea in mind for how the article could be improved, but didn't express it clearly enough that I could make out what they wanted. If I could ask them what they meant, it's possible I could have done something with the suggestion. In other cases, the reader is looking for information that I know exists elsewhere. I could point them there, if only there were a way to reply to their comment. I've seen comments from readers expressing frustration that their previous comments received no response, but in many cases there is no way to respond, nor even any way to tell the reader why they are not getting a response. All of these readers have been ill-served by being channeled into the feedback mechanism. Some of them would have perhaps found the talk page if the feedback mechanism didn't exist. The ones who did not find the talk page would still be mostly better off for not having left feedback that will not do any good.--Srleffler (talk) 06:08, 21 January 2013 (UTC)

To comment briefly; on the first point, the problem with talkpage entries is that it would swiftly overwhelm the talkpage system and the editing format is not suited well to removing vandalism where subsequent contributions have been made. On the second, a reply mechanism is on our to-do list. Okeyes (WMF) (talk) 06:33, 21 January 2013 (UTC)