This RFC is scheduled to begin on Monday, January 21. At that time, I will notify these same pages of the start of the RFC and I will add the RFC to Template:Centralized discussion. Please let me know if there are any other pages that should be notified of this discussion. Thanks! --MZMcBride (talk) 17:47, 17 January 2013 (UTC)[reply]
I disagree with your assessment and would like to write a different statement. Do I have to wait until Monday, or may I write one now? Nyttend (talk) 17:50, 17 January 2013 (UTC)[reply]
Please write one now. :-) The idea to wait for Monday was exactly this: to allow some other views to be posted before voting gets underway. --MZMcBride (talk) 18:43, 17 January 2013 (UTC)[reply]
Cool, thanks. Again to anyone else: if you know of a talk page or template where this discussion should be posted, please do so (or let me know and I'll take care of it). I think we hit the major spots (the five above and Template:Cent). I can't think of anywhere else off-hand where this should be posted. I half-considered a watchlist notice, but that seemed excessive. --MZMcBride (talk) 01:47, 21 January 2013 (UTC)[reply]
Hrmmm. I suppose that's to be expected given where the discussion was advertised, I guess, though it's a bit unfortunate. At least the discussion got some Signpost exposure/coverage prior to it ending.
Is this a WMF-approved RfC? Have the Foundation given any indication that they'll be swayed from their current position by the consensus decided here? DoctorKubla (talk) 18:08, 17 January 2013 (UTC)[reply]
Does it really matter? If there is an overwhelming consensus from the community to remove AFTv5 from all articles (or even consensus the other way), it would be rather unwise of the foundation to do something against the direct wishes of the community. Legoktm (talk) 18:42, 17 January 2013 (UTC)[reply]
I don't believe the Wikimedia Foundation ever approves requests for comment. The editors are the ones being asked to moderate and respond to this feedback. The editors are the ones who built Wikipedia. This seems pretty clearly to be an editor issue to me. --MZMcBride (talk) 18:44, 17 January 2013 (UTC)[reply]
I have no problem with reader feedback ... I understand that readers are more likely to edit after they've given feedback ... but an unintended consequence of the increased attention to feedback, particularly when it's called "reviewing", is that it causes confusion with actual article reviewing at WP:PR, FAC and WP:GAN. (Btw, although I work at FAC, I support the position that GAN and FAC don't work as well as they should for all areas of the project, and I think that's a problem that needs fixing ... but they're a vital part of what works for many wikiprojects.) If more attention is being paid in article-space to reader feedback, then more attention should also be paid to the reviewing processes. I don't have any strong preference for what form that attention should take. - Dank (push to talk) 19:02, 17 January 2013 (UTC)[reply]
I remember people being quite enthusiastic about the research on it at Wikimania, but I don't have any personal knowledge of the research. - Dank (push to talk) 19:07, 17 January 2013 (UTC)[reply]
40% of feedback blindly classified as useful by at least 2 Wikipedians (but less than 25% on popular articles)
How many readers are we engaging?
2,800 unique anon posters/day
How many unique users participate in moderation?
90 unique daily feedback moderators
How many posts are moderated?
3.5% daily posts moderated within 24h
11.5% daily posts moderated within 1 month
The obvious problems with AFT5 on en-wiki are feedback moderation and noise rate. I wish we had some stats from the AFT trial on german Wikipedia, because I think that things are quite different there: Higher moderation rate (i wildly guess 60%), feedback by native speakers (almost exclusively), less feedback volume (~1% of articles with AFT and less page views in de-wiki overall). The 4 month trial is supported by a poll in November/December with a majority (79 PRO /29 CONTRA). --Atlasowa (talk) 22:07, 20 January 2013 (UTC)[reply]
Question - if the consensus on the RfC is to eliminate the current feedback tool, what is your position, or the position of WMF? Should it then be eliminated or will it be rolled out anyway? Regards, GregJackPBoomer!23:19, 21 January 2013 (UTC)[reply]
I cannot speak for the WMF. My role here is to bring staff and the community closer together and involve the community in staff decisions (and vice versa); I'm an admin, a long-term user, have been the both of those for years, so obviously my attitude in this may differ from my colleagues. My perspective is and has always been that if the community actively and explicitly doesn't want the software, they shouldn't have to get it. From an ethical point of view I am incredibly uncomfortable with forcing positive software decisions on people, except where strictly necessary (or where I think they're so ludicrously wrong as to need involuntary commitment); from a practical point of view, it's an utter waste of my time, Engineering's time and the community's time to trample over consensus for a single extension and then spend 6-12 months arguing about it and having other conversations informed by bled-over rage. We've got more important stuff to do than bicker.
As an aside: can I ask that we stop talking in terms of 'elimination' or how 'useless' the tool is, please? I've spent fourteen months of my life working on this software, as have several other people I consider colleagues and in a few cases friends. It doesn't add anything to the conversation except offence for some people who are (as silly as it may sound to people opposed to the tool) actually trying to do good. Okeyes (WMF) (talk) 06:50, 22 January 2013 (UTC)[reply]
If the view that free-text article feedback does more harm than good prevails in this RFC, we will not deploy the tool to English Wikipedia and remove both AFT5 and AFT4 from here. We will continue to support requested trials of the tool in other languages/projects, but won't spend significant development effort in this area in the near future. (To be sure, AFT5 was always a low priority effort, with a single engineer dedicated fully to the project since July 2012, Oliver's substantial efforts on the community side notwithstanding.) --Eloquence*07:06, 22 January 2013 (UTC)[reply]
Oliver, my intent was not to cause offense. Although I'm not an IT type, I've worked around and with a number of them, and I know the efforts that go on behind the scene to develop tools to make things work better and more efficiently. The feedback project was a good idea, but as with any new system, unforeseen issues can come up. In this case, it is the type of comments that are left. The tool itself functions fine (and I'm very impressed at how it is designed), it is just that we have to deal with way too much chaff to get to something useful. Again, my apologies if I offended you. GregJackPBoomer!12:37, 22 January 2013 (UTC)[reply]
In any RfC, there is an unavoidable bias introduced by the fact that it is possible to read existing views before adding your own view. Thus if those with a particular bias or POV happen to get in early, that alone can influence the results. This bandwagon effect is why so many types of polls (incuding our own arbcom elections) do not reveal partial results.
On the other hand, seeing previous opinions can also lead to a clearer consensus, as seen in the delphi method. According to this theory, it is not the seeing of other views that is the problem, but rather that some views (the early views) are seen by more people while making up their minds and other views (the late views) are seen less. In some cases there may be an additional bias caused by the choice of where to pre-advertise the pre-RfC.
That being said, allowing views and endorsements or comments about views to be posted prior to the start of the RfC is a method that makes the unavoidable bias worse. That's why, whenever I administer an RfC, I limit any pre-activity to attempts to make sure the question is not misleading or the wrong question, and I delete everything but the question prior to the official start of the RfC. In my opinion, this deletion process should be done here and this RfC should start with just a question. Of course those who have given their opinions already can and will cut and paste them from the history, but perhaps, having read this view, will wait a day or two before doing this to minimize any perception of bias. The default duration of an RfC is 30 days, so there will be ample time. --Guy Macon (talk) 22:20, 18 January 2013 (UTC)[reply]
Users who endorse this view
...
Comments
Your comments read as though you view RFCs as scientific or social experiments. It's a little bewildering, as they're neither. This RFC isn't a thirty-day trial, it's a community discussion about a proposed software feature. --MZMcBride (talk) 03:37, 19 January 2013 (UTC)[reply]
Have you seen any examples of other RfCs where certain editors were given a three-day head start before it opened? (If you do find one, please keep a count of how many you had to check before you found it). --Guy Macon (talk) 09:47, 19 January 2013 (UTC)[reply]
I'm sorry, I'm not sure I'm following your question. Can you clarify what you mean by "certain editors"? And can you clarify what you mean by "head start"? --MZMcBride (talk) 17:29, 20 January 2013 (UTC)[reply]
"Head start" = commenting on a RfC before it opens. "certain editors" = those who found out about the pre-RfC and commented upon it. Contrast with those who don't find out about the RfC until it is posted and advertised in the usual way. "Bandwagon effect" = the natural advantage that views posted prior to the RfC opening have on influencing other editors.
Others don't seem to agree with the view you're putting forward here, but perhaps they will in the coming days. I'd be interested in what others think. It's possible that I'm really off-base and/or really bad at this RFC thing. I don't think I am, obviously, but if others agree with you, they should say so.
I think the problem with your question ("Have you seen any examples of other RfCs where certain editors were given a three-day head start before it opened?") is that it's poorly framed. I advertised this discussion in several places, as noted on the talk page. And anyone is free to comment here (and they have...). Are there other RFCs that started in a similar fashion? I'm sure. I don't have the time to conduct a research study of English Wikipedia requests for comment, but you're free to study the matter if you like. As someone who has studied English Wikipedia RFCs, I'd be interested in the results of such a study. :-)
Honestly, in all my time here, I'd never heard of the practice of clearing an RFC before it officially opens. I looked at Wikipedia:Requests for comment and didn't see it noted there. I value my time and the time of my colleagues. I think banishing my work and their work to the page history in order to serve an undocumented—and I would argue distorted—view of how RFCs should operate seems disrespectful to the people who have already chosen to get involved here. And more than that, I think the way in which this RFC has been conducted—allowing people to post a few different views and not giving a first-mover advantage to the people who notice the creation of the RFC soonest—works pretty well. --MZMcBride (talk) 01:32, 21 January 2013 (UTC)[reply]
Two things:
I would suggest that this section in particular be removed to the talk page as it is obviously a statement about the RFC itself, not the tool that is the subject of the RFC.
I have myself participated in several RFCs that had position statements drafted beforehand and I am struggling to see why Guy seems to feel it constitutes an unfair "head start" as it seems clear that anyone who wants to can add their own position right now and have in fact been invited to do so with multiple notices around WP. Beeblebrox (talk) 21:41, 20 January 2013 (UTC)[reply]
The point is moot now, but I am curious as to why multiple editors appear to think that Bandwagon effect either does not exist or in some way doesn't apply to RfCs. BTW, I just checked 20 random RfCs and they all have views starting after the RfC opened. Statistically, that means that it is probable that 10% or less started accepting views before the start. If anyone indicates that they care about what other RfCs have done, I can increase the sample size by checking More RfCs and come up with a more exact result. --Guy Macon (talk) 02:02, 21 January 2013 (UTC)[reply]
I guess my confusion is why you think the bandwagon effect is notable in the context of RFCs. Isn't it present in any open discussion? --MZMcBride (talk) 04:02, 22 January 2013 (UTC)[reply]
It's present in most community discussions, but those who design the discussions should try to minimize the bandwagon effect, and of the 20 RfCs I checked, 100% did try to minimize the bandwagon effect by having everyone start at the same time. Arguing against efforts to minimize the bandwagon effect because a lesser bandwagon effect would inevitably remain is a variation of the Nirvana fallacy. Less bias is better than more bias, even if the reduction is small and even if some bias remains no matter what you do.
This RfC has been run (I am 100% certain that this is in no way intentional) in a way that increased the bandwagon effect. Decreasing the bandwagon effect would have been better. Maybe just a little better but some is better than none. I don't see why you wouldn't want to minimize all potential sources of bias.
There is another side effect of this decision. By prematurely discussing the answers to the questions, less thought and less discussion was devoted to the question of whether the right questions are being asked and whether the wording can be improved. IMO this RfC could have been improved if we had focused first on improving the questions instead of immediately gathering answers to the questions. --Guy Macon (talk) 04:53, 22 January 2013 (UTC)[reply]
Anyone could have rewritten, rephrased, or replaced the questions during the drafting period (or even prior to the drafting period... this RFC was created on January 4). Nobody seemed interested in editing the questions, however, so we moved forward with the questions that I formulated. I didn't post my view until January 17. Maybe the discussion should have been better advertised in order to solicit more feedback about the questions to ask? But then I worry you would just be upset about a greater head start for certain editors. :-/ --MZMcBride (talk) 06:16, 22 January 2013 (UTC)[reply]
I give up. You don't seem to understand that [A]: I am not "upset" over anything. I just happen to know a somewhat better way (reduced bias because of reduced bandwagon effect) to run an RfC. And [B]: The somewhat better way is simple: Start the RfC at the start time and not several days before the start time. Your "then I worry you would just be upset..." comment makes me think that you don't even understand what it is that I am suggesting.
Clearly my suggestions, while correct (yes, bandwagon effect does exist and does cause increased bias in this situation), are not going to be accepted no matter what I say, so I am going to invoke WP:DEADHORSE and stop trying. Feel free to have the last word - I will not reply. --Guy Macon (talk) 19:26, 22 January 2013 (UTC)[reply]
Seems to be an ongoing resource issue on the WMF side. So my question is: if required could the WMF provide in total five times the resource offered to date in order to complete this project? If the answer is yes then I'm all for completing, if the answer is no then I have to feel that the WMF has put the project in doubt by under estimation of resource. Regards, Sun Creator(talk)01:58, 23 January 2013 (UTC)[reply]
We intentionally resourced AFT5 at a low level (with a single engineer fully dedicated to it), compared to some of our higher priority projects (like Visual Editor, Mobile, or the other Editor Engagement projects). We looked at it, and continue to look at it, as an exploratory, high risk / high reward project, with strong emphasis on solid research results (many of which have been linked to already). Everyone who's worked on it put their heart and soul into it, and it's a fair bit of elapsed time, but it's not, and never has been, a top priority initiative.
With that said, it's close to feature-complete. The main remaining change to the user experience is an improvement to the moderation tools to increase efficiency (a one-click "Resolve as" feature that makes sifting through comments much easier); you find the new UI here. The other remaining work, if we go 100% on en.wp, is to scale the backend architecture, which is not at all trivial and requires help from some of our most senior engineers -- something we likely won't go through with if the prevailing view here is that having a tool like this does more harm than good.--Eloquence*08:27, 23 January 2013 (UTC)[reply]
Well in my view it's no where near feature complete unless you are thinking of a solution that won't be acceptable to the community which seems to be the place we are quickly reaching. Regards, Sun Creator(talk)11:59, 23 January 2013 (UTC)[reply]
I'm saying the project is about 80% complete and as completing(making it a polished quality bit of software) the last 20% requires 80% of the resource(man hours) so the WMF will need in total five times the amount of resource already applied to the project. If the last 20% isn't planned to be done or is done in a half-hearted way then the resistance(from the community in the case of Wiki) to it's full rollout will be significant and likely derail it. Regards, Sun Creator(talk)22:31, 23 January 2013 (UTC)[reply]
Note: official interpretation of «we likely won't go through with if the prevailing view here is that having a tool like this does more harm than good» is «the foundation will respect the community's decision regarding a full deployment».[2] --Nemo23:11, 24 January 2013 (UTC)[reply]
I think you're kind of missing the point there. :-) I would hazard a guess that for folks who value this type of feedback, it's not about the informational content so much as it's about the connection with a reader who's saying "Good job, it would be more awesome with a picture". That connection can provide motivation and a sense of accomplishment ("I've done something another person will value") that a mere database report cannot, for some people.
Human beings vary wildly in motivations and emotional response. One way to categorize these biases is to distinguish between folks who value "content before connection" ("I don't care who you are, just give me the facts"), vs. people who value "connection before content" ("Let's get to know each other, then let's talk shop"). Unsurprisingly, the process of creating an encyclopedia in a radically open manner self-selects for the former -- we don't (can't) care who you are, even what you are, just as long as you get your facts and your sources right. Conversely, if you have nothing new or interesting to say, we tend to prefer you say nothing at all.
But one of the challenges with AFT is that it will precisely appeal to people who seek connection more than it will to people who seek content. If you're a connection-oriented person, it helps you empathize with readers. You might see a comment that says "Why is X not in the article", check the article, and see it's already there -- and then think, WTF? Why did this reader miss this? And you might find that the important fact they were looking for is hidden somewhere in an infobox or caption and deserves more prominent mention. If you're a content-oriented person, you might read the same comment and say to yourself "Here we go, yet another useless comment".
I think everyone, including you, acknowledges that there can be universally useful feedback coming in through a tool like this (straightforward factual corrections or notes of non-obvious omissions, etc). But some folks (as is evident in a few comments in the RFC) do find even less actionable or informational comments useful, because they can be motivating, help empathize with readers, and help re-examine assumptions. That doesn't mean one group is right and the other is wrong -- they're just differently motivated. :-)
If you can hear me at all on this, this is what I'm expressing concern about -- that we're potentially shutting down an important tool because it has more appeal to one group of people than another, even though its impact on those who prefer to ignore it is relatively benign.
Of course I see that there are legitimate arguments against having a tool like AFT in place, especially if you do view it through the lens of "this is a pile of work that needs addressing". (I don't think that's necessarily the view you have to take, but there's a sort of protective/hygienic element of not wanting crap to accumulate anywhere, even if it doesn't materially affect a significant number of people.) And the "human connection" you can get from a comment from an IP address is about the most minimal you can get, and may not be a sufficient motivation to offset any perceived negative impact. But reasoning that amounts to "I don't have a use for it, so nobody does" is inherently flawed.--Eloquence*08:03, 23 January 2013 (UTC)[reply]
I took a more moderate view. So this isn't really a reply to me as much as it is a reply to the RFC, I think. I don't disagree that a sane, useful feedback tool would be nice. I remember some brainstorming at Wikipedia:Kvetch (and possibly elsewhere...). But that's not what we have here. What we have here is a comments section at the end of the article, accumulating largely noise, with some heavy-handed abuse filters applied to it to make it vaguely palatable.
And, of course, there's a sense among many people I've talked to that it's not just the feature itself (which is pretty bad), but also the way in which the Wikimedia Foundation is pressing ahead with this feature: setting a deployment date to all articles without a clear consensus to do so (though your edit on this talk page did alleviate some of those concerns), seemingly ignoring the fact that there aren't enough engaged editors to keep up with a firehose of noise, and implementing this tool in a slick, smug way with colored smiley (and sad) faces and a big box at the bottom of the page with big blue buttons. Can you see how that looks to long-time editors? When people who are trying to write an encyclopedia look at this, is it really unreasonable for them to think "wtf? no." xkcd got it mostly right.
I do user support in #mediawiki, and every once in a while we have someone come in with a question about how to make some extension work. But it sometimes turns out that they didn't need an extension. Or they needed a different extension. Or they needed asta different approach entirely. Put simply: it's still unclear to me what you're trying to do here with this feedback tool. I see the tool you've created and I understand its mechanics, but what goal are you trying to accomplish? Take a step back and explain what you're trying to do and then we can see if the solution you've chosen is a good fit. There are other implementation options (such as directing users to the talk page, etc.), but it's impossible to evaluate these options without a better understanding of what your aims are. --MZMcBride (talk) 08:45, 23 January 2013 (UTC)[reply]
There's an important difference between "there are no images on this page" and "there are no images on this page and it's the kind of page where I'd expect to see one". Also, your report doesn't capture the need for specific types of images. Special:ArticleFeedbackv5/B_cell#836643 asks for a particular kind of image on a page that already has five images. Your report can't do that. Only a human is going to be able to evaluate the images that are in the article and decide that a type of image is lacking. WhatamIdoing (talk) 23:32, 23 January 2013 (UTC)[reply]
We can also add to this misguided requests for images for articles that cannot get images (usually caused by a failure to read the article) – for example, Astatine has already gotten 5 comments stating "The article needs an image" or something similar, despite the lead already stating that "Elemental astatine has never been viewed". Double sharp (talk) 11:56, 24 January 2013 (UTC)[reply]
It's also useless on all pages about places, because they come from those who use Wikipedia like Wikitravel (who are more than the users of Wikitravel, surely), and in contrast to those who ask "more maps!!". --Nemo07:59, 25 January 2013 (UTC)[reply]
Nice idea. Of course it also shows that a bot can post huge amounts of useful feedback with the feedback tool. It is a worthy todo list item. Could a bot also delete further requests for image(s)/picture(s)/illustration(s)? 84.106.26.81 (talk) 14:11, 20 February 2013 (UTC)[reply]
Why is the third question How will abuse filters handle articles in which the subject's title contains a disallowed word (e.g., Blue-footed Booby + "boob")? using will ? This is question for the programmer of the tool, not for the general public. Just go look up those regex used.
Shouldn't it be How should filters handle rather than How will filters handle? --11:09, 23 January 2013 (UTC), Utar (talk)
It's being asked because it's an important consideration, I think. Did you read this post? I looked up the regex used. They're currently very broad and will result in thousands of false positives if this tool is deployed to all articles. Considering how to effectively combat abuse of this tool with a wide-scale deployment of it is certainly within the scope of this RFC, in my opinion. If this technical issue can't be resolved, how will a deployment to all articles move forward?
I may not be a native English speaker but there definitely is the difference between how it will work and how it should work for me.
Will: current state in future
Should: state wikicommunity is hoping for
Do you really take those two words as synonyms? --16:57, 28 January 2013 (UTC), Utar (talk)
Oh, I guess we're reading this differently. I meant "will" to mean "I don't see a possibility of how this can function given the limitations in text parsing and processing by computers using pre-defined patterns," not "how would it function in an ideal world." That is, I didn't intend to ask how it should work, I think we all can agree on that (it should block "bad" comments and allow "good" comments). I'm asking how we can programmatically determine what is a good comment and what is a bad comment. Simply looking at word choice (e.g., "fuck" or "shit" or "tits") can't work. So what do we do instead? --MZMcBride (talk) 05:34, 29 January 2013 (UTC)[reply]
Just to note, I was approached on #wikipedia-en by "<sex@wikipedia/MZMcBride>" who, apropos of nothing, indicated surprise that I had not commented on this RfC yet. On saying, inter alia, that the issue left me feeling rather neutral and I hadn't seen a useful summary of what the RfC was about, this person then told me (and the couple of hundred other people present) "Just read Greg's view. It's like three sentences. If you agree, sign below. If not, close the tab."
The WMF is not obliged to follow community RfCs. In the past, it hasn't - on occasions dealing with technical features. Despite this, we made a conscious effort to participate fully in this discussion and abide by the outcome, part and parcel of a much larger push to "fail better" with how we involve editors in software. I can't speak for the other staffers who have commented here or been part of the decision-making process, but I, at least, recommended involvement on the premise that people would be operating in good faith: that the outcome would actually be representative of community concerns and needs, even if it fell in a direction we didn't want.
This statement suggests that isn't the case. I'm not sure what this means for our involvement: I'll be talking to other staff about it, although personally I don't want to waste the time of those editors who are participating in good faith. I'll leave it up to the community to decide if something needs to be done about this on their side of things. Okeyes (WMF) (talk) 00:11, 25 January 2013 (UTC)[reply]
Thanks. Having read it, I can confirm that it validates Demiurge's claim (although obviously I can't validate if the log matches the channel discussion). I can also confirm that there are a ton of names in #wikipedia-en I don't recognise. I feel old all of a sudden. Okeyes (WMF) (talk) 00:36, 25 January 2013 (UTC)[reply]
Oliver: If this conversation happened in #wikipedia-en and additional validation of the log is needed, I can reference my logs to check it out. MzMcbride: Oh, for heaven's sake. Why would you even do something like this, when you know IRC leaks like a sieve and that you would make your own arguments look bad when it came out that you'd canvassed? All: for what it's worth, as someone who commented many times in this RfC and uses IRC, I was not canvassed in any way to this discussion, and before this thread, I saw no evidence in any of the WMF channels I use on IRC that anyone else was either. I expect the Foundationeers are throwing their hands up now and talking about how this is why they shouldn't bother to check in with community consensus in the first place, but I urge you not to fall into that trap. You wanted an RfC on the future of AFT,(Sorry, I don't know why my brain keeps telling me this was an RfC started by a WMFer. More accurate represention of what I meant follows:) You've worked very hard, and very well, to keep the community involved in this tool's future and development, and this is another chance for you to take the community's opinions into account. Given the sheer number of people who have participated in good faith in the discussion, any conclusions from the RfC should not be written off because of the behavior of one person. Attempting to nullify things now is not going to help you when it comes to gathering enough community goodwill to make the tool useful.
Also, I and at least a few other people who I have on my watchlist and who had participated in the AFT development process over the past year or so received barnstars from Fabrice a day or two ago urging us to vote in this RfC. While two wrongs don't make a right, it seems to me that both sides are pushing their initiative on this, and will perhaps cancel each other's (hopefully small) influence out. How about we all call it quits on trying to influence the outcome with anything other than honest arguments on the RfC? A fluffernutter is a sandwich! (talk) 00:53, 25 January 2013 (UTC)[reply]
Not to comment on most of this; on the barnstars, yes, Fabrice sent out a set of barnstars to people who had participated in improving AFT5 over the last 12 months. As soon as I was alerted of this I trouted him, and he stopped doing it; I understand it to be a good-faith mistake. Okeyes (WMF) (talk) 01:04, 25 January 2013 (UTC)[reply]
Yes, I don't mean to imply that I think Fabrice was operating in bad faith, at all. All my interactions with him have led me to feel that he means absolutely well. I'm just sort of hopefully saying that maybe both actions (one apparently deliberate, one apparently not) both amounted to the same level of vote-swinging (if any), and thus the damage to either side isn't as bad as it could be. A fluffernutter is a sandwich! (talk) 01:08, 25 January 2013 (UTC)[reply]
Is there any other context to the message? What was the discussion about? Based on the above quote, it didn't seem like he took a position, based on the "if not," (i.e., don't agree) "close the tab." It was leaving the decision to the recipient and whoever else was listening. It's hard to comment or respond to this without the full context. GregJackPBoomer!00:53, 25 January 2013 (UTC)[reply]
Since you ask, Greg, the immediately preceding discussion was about Wikipedia categories and sexual preference and nationality; at which point the IRC user in question stepped in to express surprise about my not having commented on this RfC. That was literally one line and the next line. A total non-sequitur. --Demiurge1000 (talk) 01:11, 25 January 2013 (UTC)[reply]
Since there is a question on the order of comments, I would prefer to see the log. I still don't see that comment, without more, as a request for a !vote one way or another. I've worked with MZM in SCOTUS for awhile, and he's always been above board. GregJackPBoomer!02:13, 25 January 2013 (UTC)[reply]
Umm. I think Demiurge1000 is just trying to make drama. He seems to have deliberately misquoted me. I said... "Demiurge1000: Just read Greg's view. It's like three sentences. If you agree, sign below. If not, close the tab. ;-)"
The ";-)" was intended to indicate sarcasm. Demiurge1000 clearly understands this, so I'm confused why he's trying to create drama here. --MZMcBride (talk) 01:38, 25 January 2013 (UTC)[reply]
Now, wait a second here. You've surely been around on the Internet long enough to know that sarcasm isn't communicated well in text. In my estimation a smiley is less likely to successfully communicate sarcasm than an actual sarcastic sentence. This calls for an abject apology about inappropriate sarcasm use in a serious context, not a disagreeable comment about "deliberate[] misquot[ing]" and "creating drama." Canvassing is, if not prohibited, at least frowned upon, for good reason. And the obvious question is, was there more canvassing directed at people who don't care enough to publicly expose themselves to potential obloquy and the kind of inappropriate comments you just made? AgnosticAphidtalk01:57, 25 January 2013 (UTC)[reply]
Sarcasm often translates poorly on the Internet (Poe's law). I deliberately included an emoticon to indicate sarcasm. I apologize if this wasn't clear. I've been on the Internet for most of my life and I've always understood ";)" or ";-)" to indicate sarcasm (universally).
Prior to today, I considered Demiurge1000 a friend and I mentioned the RFC in #wikipedia-en (a channel dedicated to the English Wikipedia) because I genuinely thought he might have an interest in it. Demiurge1000 chose to not only misquote me, but he also apparently is misrepresenting the order of events. He says above that after he indicated he felt neutrally, I told him to vote in a particular way. Looking at the log of the conversation, this is a complete fabrication. I made the sarcastic comment (indicating it was sarcasm with an emoticon) and then he said he felt neutral several minutes later. Demiurge1000 posted here in what reads like an attempt to stir up drama. I didn't approach him privately or in a dark alley and I certainly didn't canvas for support in a serious manner. I spoke to him in a very public channel. For what it's worth, I also mentioned the RFC in #wikimedia as well to another user who I thought might be interested in it. Again, a very public channel. I've been on the up-and-up here. Demiurge1000: do you have any response? --MZMcBride (talk) 02:05, 25 January 2013 (UTC)[reply]
I find this to be a "non-apology apology." You assume that Demiurge understood that you supposedly intended to convey "Just kidding! You should spend a significant amount of time considering all of the views in the RFC even though you've said something that I felt necessitated a response of 'its only three sentences!'" with ";)". Then you say "I apologize if this wasn't clear" when it obviously wasn't clear and you should have known before you said it that (1) it wouldn't be and (2) canvassing is a serious matter that calls for the exercise of care with word choice. Adding insult to injury, you assume that demiurge is acting in bad faith. AgnosticAphidtalk02:19, 25 January 2013 (UTC)[reply]
I'd like to wait for Demiurge1000 to reply. I'm having a lot of difficulty assuming good faith right now because Demiurge1000 seems to have deliberately misquoted me and he seems to have deliberately misrepresented the order of events. We'll see what he has to say (if anything). --MZMcBride (talk) 02:21, 25 January 2013 (UTC)[reply]
Sorry, one more point to add. In the same log file (#wikipedia-en_20130124.log), Demiurge1000 said "Susan: Maybe it's not a very well written RfC, then. ;)" and "Well, I'm not one to make threats, kiddo ;)". I believe these two verbatim quotes from Demiurge1000 indicate that he is well aware of what ";)" or ";-)" mean in an online discussion. Absolutely no objection from me to post the entire log here, though, for others to review and evaluate for themselves. --MZMcBride (talk) 02:27, 25 January 2013 (UTC)[reply]
Based on the additional quotes shown by MZM, it is clear that Demiurge understands the use of the wink icon. And with the comment about not being well-written, LOL, I can certainly understand MZM's comment about 3 sentences. My view was extremely short, extremely blunt, probably without near enough tact (for which I inadvertently caused offense, and for that I am sorry), but also extremely clear as to what I thought should happen. In context, as I see it now, there doesn't appear to be any way that it was canvassing. Of course, the only way to be sure is to see the transcript, which I may add, has been already shared with some that were not parties to the conversation. GregJackPBoomer!02:58, 25 January 2013 (UTC)[reply]
Whether s/he understands that a wink typically is used to convey non-seriousness and whether s/he understood that MZM supposedly intended this particular wink to convey substantive meaning – "I actually intended this wink to signify that I really meant the exact opposite of what I said; you should carefully read through each of the views presented in the RFC, not just GregJackP's brief view, and after you've done so, please vote on whichever view you find to be the most persuasive, even though you apparently indicated you didn't have much time or interest" – are not he same thing. How can you say what someone else understood? Moreover, what about everyone else on IRC that also saw the comment? Did they also understand the complex ideas conveyed by this wink? It's easy for you to say that this wasn't canvassing, who knows if there was more canvassing, and this shouldn't affect the RFC when it's your view that appears to be prevailing at the moment. AgnosticAphidtalk03:52, 25 January 2013 (UTC)[reply]
Well, why don't we contact everyone that !voted and ask if they were canvased in any way? Of course, including the ArbCom members that support getting rid of the tool. I've looked at the comments that have been shared, and don't see it the way you do - nowhere did MZM say "don't vote" for another view. GregJackPBoomer!04:29, 25 January 2013 (UTC)[reply]
Wikipedia is a very open site. So far there's been one accusation of off-wiki canvassing by someone who seems to have intentionally misquoted and misrepresented what happened. If others step forward and accuse me of canvassing (on-wiki or off-wiki), I think there would be cause for concern. As it is, this seems like Demiurge1000 acting inappropriately in an attempt to create drama where there is none. I'm still waiting on Demiurge1000 to reply to what's been written here and I'm doing my best to reserve judgment of his actions until he can fully explain them (if he can), but as it stands, I'm very disappointed in him. Before today, I considered him a friend and an upstanding user. His actions on this talk page have left me hurt. :-/ --MZMcBride (talk) 04:20, 25 January 2013 (UTC)[reply]
I have permission from MzMcbride to post here the relevant portion of IRC log (timestamped roughly [hour]:23 through [hour]:44 on my computer), if that would be considered helpful to this conversation. I would have to strip it of joins/parts (privacy) and conversation by others (unrelated), though. Demiurge, your permission would also be required before I can release that log onwiki. Would you please let me know here or on IRC if you're ok with it being released? A fluffernutter is a sandwich! (talk) 02:28, 25 January 2013 (UTC)[reply]
I've just spoken with Fluffernutter, who assures me that in their scrollback the comment does indeed have a smiley on it. My scrollback does not stretch that far back (I went to bed at eleven minutes past one, and the first mention of this smiley here or anywhere else was twenty-something minutes after that), and my client (Chatzilla) does not capture smileys when copying and pasting from scrollback. Being aware of this, I checked for smileys on MZMcBride's comments before I emailed the log to Oliver - I didn't see any. (We've considered whether it's possible Chatzilla displays some smileys but not others, but that doesn't seem likely, and a brief search doesn't find any reports of such problems.) Since it's extremely problematic to conclude that what Fluffernutter says they see in front of them is not in fact what appeared in the channel, the only conclusion is that my visual check was flawed. (This would also mean, in my view, that the comment, although unwise, didn't rise to the level of serious canvassing and was pretty much the standard level of banter that goes on in these type of discussions.) My apologies to all concerned. --Demiurge1000 (talk) 08:10, 25 January 2013 (UTC)[reply]
Many of the respondents to this RFC do not appear to have moderated more than a few if any feedback comments. I would like to ask whomever closes this to make a script to count each respondent's number of feedback moderations and use that count to weight their opinion of the tool on views where experience with it is likely to correspond to an informed opinion. 71.208.1.51 (talk) 00:24, 25 January 2013 (UTC)[reply]
As the person who would presumably benefit from such a thing, given the current distribution of views, I'd recommend against this; taking MediaWiki-logged moderator actions is not necessarily identical to whether someone has actually looked at the feedback. Okeyes (WMF) (talk) 00:27, 25 January 2013 (UTC)[reply]
I maintain that actually moderating more than a few comments is very likely to indicate substantially more experience with and understanding of the implications of the tool than not having moderated. 71.208.1.51 (talk) 00:47, 25 January 2013 (UTC)[reply]
To reference a very specific use case (is that the right term?), an analysis of this type would misrepresent the depth of involvement of oversighters in patrolling feedback. By definition, most of the work we do in curating feedback is no longer visible to anyone other than ourselves and users with a few other types of special userrights. A fluffernutter is a sandwich! (talk) 00:55, 25 January 2013 (UTC)[reply]
This suggestion would bias the results, since users who do not like the feedback tool are more likely to choose not to moderate feedback. --Srleffler (talk) 04:14, 26 January 2013 (UTC)[reply]
Note that if you work for the WMF, we recommend that you focus on providing factual information in the comment sections or talk page -- and refrain from voting or posting personal views as a new section, so that we don't interfere with this community deliberation process. If you do participate, be sure to use your staff account and avoid getting into heated discussions, which just state the relevant facts you are aware of, and leave it at that.
WMF staff members who have already contributed to this discussion include Oliver Keyes, Erik Moeller and yours truly (posted as a comment after MZ McBride's view). Our comments are longer than we expect other WMF contributions to be, because we wanted to surface all the known facts for the record. But we are now taking more of an observer role, to let others comment on this community discussion without interference from the foundation.
While I appreciate the intent to not interfere, the staff who also happen to be community members (which is probably about half of the people working for the Wikimedia Foundation?) should feel free to participate in this and any other community discussion. Working for the Wikimedia Foundation doesn't preclude you from articulating a view in an RFC (I turned Fabrice's long comment into a view) or endorsing specific views, so long as you're giving your own, honest opinion. There's only an issue if you're giving someone else's opinion or the organization's opinion.
If you really believe that this tool is a worthwhile endeavor or that its warts can be overcome, that's a perfectly legitimate position and it's fine to say so, if you truly believe that. Similarly, if you think this tool should be killed off, that's also okay to say, if you're an active community member who also happens to be a staff member and that's your opinion. You may run into social issues at the office, but that's really of no relevance to Wikipedia and that's mostly a matter of how you frame your comments, I imagine. I personally don't have an issue (and would welcome) more participation from all sides (active editors, Wikimedia Foundation staff, et al.). --MZMcBride (talk) 06:26, 25 January 2013 (UTC)[reply]
This is a nice principle, but it causes problems; what about staffers who are not, traditionally, editors? I have no objection to people like Fabrice, User:Kaldari et al participating, but we have an issue with staffers who are not traditionally editors. Okeyes (WMF) (talk) 12:53, 25 January 2013 (UTC)[reply]
But we tend to discount or downgrade their vote. And with staffers who literally don't have an account for editing, contributing in volunteer discussions is frowned upon internally. At this point I think we're getting away from the RfC topic a bit; I'm happy to discuss this on my talkpage. Okeyes (WMF) (talk) 13:17, 25 January 2013 (UTC)[reply]
I am astounded that anyone working for WMF would not be required to have an account and some small experience at editing. Would you trust a tee-totaling brewmaster or a vegetarian bbq pitmaster? ;) Rmhermen (talk) 18:02, 25 January 2013 (UTC)[reply]
No, and (to use the analogy) if being a staffer actually required editing, I think we would always hire editors. Quite a few of our staff are community sourced; I can think of managers, programmers and, heck, the deputy director just off the top of my head. But a lot of our jobs do not directly require editing knowledge; it's sort of hard to argue as to why people should need to know the manual of style to keep our network of datacentres running. Okeyes (WMF) (talk) 18:12, 25 January 2013 (UTC)[reply]
You think it's hard to argue why someone who's in charge of making sure edits work properly should have some familiarity with editing? Just how hard? --MZMcBride (talk) 23:27, 25 January 2013 (UTC)[reply]
I think it's hard to argue why that should be a requisite rather than a nice-to-have. Don't get me wrong; show the staff two equally-qualified candidates for a job, one of whom has experience with the community, and I'm sure they'd hire the one with the experience. But it's difficult to say that if the one with community experience was simply a worse developer, or operations engineer, or whatever, as to why we should hire them. It's nice to have engineers who know their way around the community, sure. It's even nicer to have engineers who know their way around code. As said, this is rather distracting from the RfC's point, so I'd suggest anyone who wants to further discuss this with me drop me a talkpage note. Okeyes (WMF) (talk) 23:31, 25 January 2013 (UTC)[reply]
Oliver: So what you're saying is that people should acquire some competence and experience as editors before they provide feedback about the content of Wikipedia. OK, got it. --Ori.livneh (talk) 21:44, 25 January 2013 (UTC)[reply]
More "If 140 people who work for us, an unknown number of which have not participated in the community and will not be expected to triage feedback, show up and participate in an RfC, it sort of harms the legitimacy of the RfC" :P. Okeyes (WMF) (talk) 22:12, 25 January 2013 (UTC)[reply]
As though there are 140 people working for the Wikimedia Foundation who could figure out how to edit. You basically acknowledged this reality just a few lines up. --MZMcBride (talk) 23:29, 25 January 2013 (UTC)[reply]
Not knowing != 'not being able to figure'. I said we don't always hire people with editor 'status', as it were, not that we hire people where editing is beyond them ;p. Anyway, as said, this is a distraction: drop me a note elsewhere if you want to continue the conversation for whatever reason. Okeyes (WMF) (talk) 23:33, 25 January 2013 (UTC)[reply]
48 hours expired, proposal not passed. 10:38, 31 January 2013 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
So, first: thanks to everyone who's participated in this discussion so far. We really appreciate the feedback (yes, even from people who don't like the tool ;p). That said, as Fabrice mentioned in his perspective on the RfC, we do know about a lot of the problems with the feature: the difficulty of moderating things speedily, which adds to the problem of poor-quality feedback; the way things stay around, the confusing presence of feedback without comments. For the last couple of months we've been working on a complete revamp of AFT5, which is meant to be deployed in mid-to-late February. Amongst other things, it contains:
Auto-archiving for unactioned feedback that is more than N days old;
One-click moderation for most actions;
Massive simplification of the feedback page;
Replacement of 'hide' with 'mark as inappropriate' so that the junk-able feedback actually includes all the junk;
I appreciate that the tool as it stands at the moment is far from ideal. But it seems premature to judge it based on an unfinished version, whether people judge it positively or negatively. So, what I'd like to propose is this: we extend the RfC until early March. As soon as the software is finished, we deploy it to replace AFT5 as it stands now, and give it a couple of weeks to let people play around with it and see if it helps manage the bad feedback so that the good feedback is more worth having around. People can then be commenting on the tool as we'd like it deployed, rather than the half-finished version it is now. Whatever the outcome is, the Foundation agrees to abide by it; if the community doesn't want the tool on any article, it doesn't have to have the tool.
This is, I'll acknowledge, kind of an unusual thing to ask for. But I want to make sure that when we're deciding whether to deploy more widely, or less widely, we're deciding based on what would actually be deployed (or removed). I'd suggest a quick 48 hour straw poll decide if we extend as far as is suggested. Okeyes (WMF) (talk) 16:27, 28 January 2013 (UTC)[reply]
Support: (as an aside) The things I dislike about RFCs are that some editors go off the subject and into their personal agenda. Can we please not do that here? Thanks. Mugginsx (talk) 17:03, 28 January 2013 (UTC)[reply]
I'm a little confused by your support of extending this RFC, given your endorsement of Greg's view ("well-intentioned idea but has not worked out as intended"). --MZMcBride (talk) 17:06, 28 January 2013 (UTC)[reply]
Edit conflict My understanding is that the tool will be improved. It is hard to wade through all of the extraneous conversation. Am I mistaken? Mugginsx (talk) 17:19, 28 January 2013 (UTC)[reply]
Support. Thank you for staying so neutral here Oliver, I appreciate your analysis, understanding, and consideration for our concerns. I fairly patient with people, so I'm fine with giving you guys more time to adjust the tool and I'll be happy to reassess my opinion. Please make the "link at the top" at tab, something like "Talk", "Feedback", "Article". But since there are so many problems with this tool as it stands now, please reduce its popularity until it is ready to be redeployed in a better state. Good luck to you and the devs, • Jesse V.(talk)17:15, 28 January 2013 (UTC)[reply]
Yeah, I suggested doing just that a few months ago; the feeling seems to be that in design terms we're moving away from tabs, and the idea sort of got nixed :/. It will be a (fairly nondisruptive) link on the article byline. On reducing its popularity: That's something I can take back and throw around depending on how this discussion goes. At the moment, though, there's a bug with AFT5 where if you get feedback on an article that has ceased to have AFT5, it stays in the system but nobody can monitor it, which I imagine would be pretty infuriating. Okeyes (WMF) (talk) 17:20, 28 January 2013 (UTC)[reply]
Strong Support! I think this is a very important tool. I do think that it should look more like the feedback dashboard though. Maybe also a character limit would be nice to eliminate some vandalism ―Rosscoolguy17:26, 28 January 2013 (UTC).[reply]
Weak support. I don't hold out a ton of hope that v6 will magically fix everything, but if Oliver & co are willing to run v6 for a limited and set amount of time before we come back here, and they'll promise that the subsequent RfC on 6 will be the end of things (no "Oh, but you should see v7!"), I'd be willing to give them a little breathing room here. A fluffernutter is a sandwich! (talk) 17:40, 28 January 2013 (UTC)[reply]
Tepid support per Fluffernutter. While I'm not at all confident that the announced changes will do much to alleviate my concerns about the tool, I see no great harm in taking a wait-and-see approach. As long as the Foundation and the developers are willing to abide by whatever community consensus develops in a couple months, the community should be willing to give the new version a chance. There's no great urgency; Article Feedback is a minor distraction. Rivertorch (talk) 18:13, 28 January 2013 (UTC) Switching !vote to oppose[reply]
Support Let's give it a go. I'm not sure about continuing this RfC (unless I've misunderstood), I think it should be closed after 30 days with a nice "we hear you" response from involved WMF parties and a new one can then be opened after we've tried out the new tool. If this RfC had been aimed (more explicitly) at "what improvements do you want in the next release, remember it's still being developed", then all parties would probably welcome the new changes, but it unfortunately ended up being "do we want this or not", so I understand the opposition below Jebus989✰18:21, 28 January 2013 (UTC)[reply]
We should either close the RFC after 30 days and implement the consensus or extend it. Starting a new RFC is absolutely a no-go in my mind. --MZMcBride (talk) 18:34, 28 January 2013 (UTC)[reply]
I understand this position (best of three? ah, best of five?) but we don't honestly expect all the current participants to review their comments in light of the tool updates, inevitably making Greg's statement the de facto winner. I supported this statement and still do, but that's not the point if we really are going to take Oliver's word that these changes will make a big difference (I realise that's not the position being held in the oppose section) Jebus989✰18:44, 28 January 2013 (UTC)[reply]
These RFCs themselves are inherently a drain on community time and resources. I can't ask my colleagues in good faith to waste their time re-voting in a few weeks because the Wikimedia Foundation wasn't interested in what they had to say the first time. And given the history here (think "Pending Changes" and its numerous RFCs), we must learn from our past and strive to ensure that we do not repeat past mistakes. --MZMcBride (talk) 18:48, 28 January 2013 (UTC)[reply]
I accept your point about PC, I know I wasted a lot of typing before eventually realising it was going to be implemented either way, I'm (naively?) optimistic that this won't turn out the same way. Jebus989✰19:19, 28 January 2013 (UTC)[reply]
I won't say this is Oliver and the Wikimedia Foundation looking for an "out," per se, but this is unabashedly a request for more time. I guess whether it's a legitimate request for a deadline extension or not is left as an exercise for the reader. I'm not a professional teacher, but occasionally I consider how I'd treat late homework if I were. Homework is a day-to-day thing and shit happens, so it makes sense to forgive the occasional lapse in meeting a homework deadline. But this isn't really equivalent to homework, this is a fourteen-month project that has fundamental issues in its implementation, so I really can't be as forgiving. I'm a bit surprised that while there's been a lot of talk about IRC chats and soliciting community feedback, none of the issues mentioned in this RFC seem to have been adequately addressed in the past fourteen months. To me, that indicates that feedback either wasn't properly solicited or everyone was in cahoots to object at the eleventh hour. To its credit, the Wikimedia Foundation has made it crystal clear that they'll respect the community consensus found in this RFC, including a consensus to disable AFTv4 (the ratings box) and AFTv5 (the comments box). At this point, I think sending a clear message would be better than attempting to push the goal posts further apart. Just my view; I fully respect the editors who think a little extra time is warranted here, I just don't happen to be one of them. --MZMcBride (talk) 07:20, 29 January 2013 (UTC)[reply]
Support. I would like to gain experience with the updated version to form a more complete opinion of the tool. I agree with others that this RfC was opened prematurely in light of the pending improvements, but many of the most substantive objections are rendered moot by new features. We're not going to solve the problem of reader engagement by just killing the tool, we need to continue to get feedback and improve it. Dcoetzee02:04, 29 January 2013 (UTC)[reply]
Support. Seems very sensible given that the RFC was opened prematurely. I also believe that the feedback from the tool should be a net benefit, at least for some types of articles. --Avenue (talk) 02:59, 29 January 2013 (UTC)[reply]
Support I think the potential benefits to this outweigh any negatives and hopefully the next version will remove some of the poorer elements (or at least make them harder to deal with) - SchroCat (talk) 05:58, 29 January 2013 (UTC)[reply]
Support I don't see the harm in seeing what the new (and hopefully improved) version of the tool is before deciding to permanently get rid of it. Yes, it sucks that however many people spent their time reviewing the proposals and typing in their votes and asking people to look at the proposal on IRC. But really, the initiator of the RFC could have asked the WMF staff that have spent many months of their lives trying to increase reader engagment if now was an appropriate time to make a permanent decision on AFTv5 before this RFC started. OKeyes was pretty clear from the get-go that it wasn't. I don't see how people can really say, "the next version is inevitably going to suck for the same reasons I already posted" without seeing it first. AgnosticAphidtalk09:02, 29 January 2013 (UTC)[reply]
Support I have seen that the feedback tool has helped to improve Wikipedia in some ways. If other editors do not like it, then that is their rightful opinion. However, I do believe that a new version would be alright to try. At the worst, its removal will be delayed a few weeks or months. ;) --Super Goku V (talk) 10:12, 29 January 2013 (UTC)[reply]
Strong Supprt: I fail to understand why other editors want to get rid of this tool. Considering it needs a major revamp perhaps; as for me though, it has been quite helpful. Harsh (talk) 15:43, 29 January 2013 (UTC)[reply]
Support, as a work in progress. The developers have been willing to listen and respond. That gives me confidence that the tool will eventually be satisfactory for editors who want this kind of feedback. Some don't, and that's OK: there's no obligation to use it. Cynwolfe (talk) 19:47, 29 January 2013 (UTC)[reply]
Support. my previous contact with Okeys, realted to feedback about AFTv5, was *extremely* negative, so I am not his fan. Also, I do not like people changing the rules as the game goes on. Neither I like short-timed voting (48h deadline for a un-announced proposal?). I think AFTv5 is bad, and I pretty much doubt AFTv5.1 would be 'the one'. But I can not see how waiting 2 extra weeks will hurt WP that much. If there is something substantially new to show, then let them show it. If there is nothing that new, or on time, then you'll look veery bad on the picture... Any trial should not last anything longer than mid-late March (2 weeks after "early March") - Nabla (talk) 22:08, 29 January 2013 (UTC)[reply]
Support - It makes sense to wait and see whether the new version addresses some of the concerns people have before we decide to get rid of it. Also I don't see the harm in pushing consensus back a few weeks. Azaleaa (talk) 23:13, 29 January 2013 (UTC)Azaleaa[reply]
Rather strongly. This tool has been in development for well over a year. This RFC was started on January 4 and opened on January 21. In this time, nobody mentioned holding off on a discussion of this tool. It wasn't until January 24 that Fabrice proposed pushing back the date of this discussion. As it stands, this discussion is scheduled to end February 21. I don't believe there will be any substantive shift in views toward this tool in a two-week period (February 21–early March, which I'm also annoyed that you seem to have intentionally left ambiguous) following the standard closure time. --MZMcBride (talk) 16:38, 28 January 2013 (UTC)[reply]
I'll admit to having intentionally left it ambiguous, because there's some degree of fluidity in software timetables (as I'd imagine you know). Okeyes (WMF) (talk) 16:40, 28 January 2013 (UTC)[reply]
Sure. But with 56 endorsements currently, far ahead of any other view, the Wikimedia Foundation's response to the proposal to turn off the tool completely seems to be "well, we'll make it even more prominent in articles for the next month or so." 'cause that's gonna win you some supporters.... --MZMcBride (talk) 16:43, 28 January 2013 (UTC)[reply]
Not in the slightest; our response has been to say 'we get what you're saying, we're comfortable following it, but we'd like to make sure any decision that is made is made off the version that would actually be deployed'. As said, that feature is in a version to be released for a couple of weeks, not 'the next month or so', and actually I think it could be very useful. Some people are objecting because they simply don't have enough feedback respondents to triage feedback easily; if there's a feature that could improve the number of people monitoring (and if those people feel it's a worthwhile way to spend their time) it's at least worth investigating. Okeyes (WMF) (talk) 16:46, 28 January 2013 (UTC)[reply]
I just want to say, honestly and earnestly, that I've been continually impressed with the straight face you've worn when discussing this tool. I've said so previously, but I still believe that you, as a long-time Wikipedia editor, do not (and would not ever) support this tool. If the roles were reversed, your rhetoric on the matter would likely be delightful to read. You've got quite a sharp tongue, that's only enhanced by its British origins. But in these discussions, you've consistently toed the party line, something I don't imagine I personally would be able to do, and I've been taken aback by your dedication to a tool that I don't believe you truly support. (This is, of course, one of the many reasons I don't believe I could ever work for the Wikimedia Foundation, and I see your experience here as a cautionary tale.) --MZMcBride (talk) 17:04, 28 January 2013 (UTC)[reply]
That doesn't really address the topic of discussion here :). On AFT5 - whether it's good or bad, my job is to make it the most-good or least-bad. I'd like to think that's an attitude that everyone takes, not an attitude specific to me. I see these improvements as just that: improvements. Given that the decision on whether the tool is deployed or not is outside my remit (on the Foundation side, it's handled by management, not by the community liaison, and on the community side, by the community, not by An Editor) I'm just trying to improve it as best I can. I see these things as improvements, so I want them to be considered. I'm slightly worried if that makes me special or impressive. Okeyes (WMF) (talk) 17:08, 28 January 2013 (UTC)[reply]
I am a bit concerned about possible knee-jerk oppose votes before it becomes clear exactly what is being proposed here. Please keep an open mind. A new version could be anything from "fixed all the problems" to "better, but needs work" to "going in the wrong direction -- this one is worse than the old one". If you don't know what the next version is, how can you support or oppose it? --Guy Macon (talk) 17:59, 28 January 2013 (UTC)[reply]
I've learned in life to evaluate reality based on reality. The people commenting on this talk page and on the RFC are doing so based on what currently exists. If others choose to base their decisions on vaporware, I can't do anything to stop them, but I certainly won't join them. --MZMcBride (talk) 18:51, 28 January 2013 (UTC)[reply]
And please don'n annoy us by proclaiming that "yes, we have implemented a half-baked version for a year, but when we have had plenty of negative feedback and people seem to want to get rid of it, we just ignore all that and present a new and better version(TM)". Disable the current one, present the new one in a test environment or on a small sample of pages for a predefined limited amount of time, and get feedback on the new one before deploying it any further. Oh, and your item #4, please no; confine these things to the talk page of the article, that's what it is there for. Don't use the article space to give any prominence to the drivel (sorry, feedback) people leave behind. The risk that you'll be linking to e.g. BLP violations is way too big, compared to the small benefit that link will provide. Fram (talk) 16:53, 28 January 2013 (UTC)[reply]
Um, everyone that follows the link to the feedback? If people now leave BLP violatoions in the feedback, it does little harm because hardly anyone sees them anyway. The more prominent you make the feedback, the more people will see all the rubbish left there (and the few useful things as well). I don't see any reason why we would give more exposure to this when most people seem to want to get rid of it. If you keep it around, first make sure that the quality improves, and then consider putting a link in the articles. But please, not the other way around, as you seem to be proposing... Fram (talk) 17:02, 28 January 2013 (UTC)[reply]
As the explanation above makes clear, it would only really appear for logged-in users - who already have a specific source of feedback through the watchlist link. So it's not really expanding the pool of people. I note above the "small subset of articles"; yes, we're not planning on rolling out version 5.2, as it were, everywhere: it would be silly. The idea is that it would replace version 5, in terms of being deployed to the same number of pages and the same pages. AFT5.1 would die, 5.2 would replace it until/unless the community decides it isn't enough of an improvement. Okeyes (WMF) (talk) 17:05, 28 January 2013 (UTC)[reply]
The current number of articles is hardly what I would call a "small number", I was thinking about a few hundreds instead at most. And linking it from one page vs. linking it from many pages does increase the visibility significantly, many people don't use the watchlist but edit logged in anyway. Fram (talk) 17:15, 28 January 2013 (UTC)[reply]
Do we have any numbers on the watchlist issue? And the problem with 'a few hundred' is that we have four million articles; any results risk being very unrepresentative :/. I don't want the community to look at an unrepresentative sample and think 5.2 has either done nothing to the problem when it's improved on it, or that it's improved on the problem when actually it's had a minimal impact. Okeyes (WMF) (talk) 17:16, 28 January 2013 (UTC)[reply]
I Strongly oppose reducing or increasing the number of articles. That's not how testing works; if you change multiple things at one you won't know whether a change is because of the new version or because of the new number of articles. --Guy Macon (talk) 18:06, 28 January 2013 (UTC)[reply]
As I stated in the RfC, this product leads to reinforcing the idea of blogging about the encyclopedia. SOFIXIT should be the order of the day. If you want help, go to the talk page. If newbies don't understand that, let's spend our time fixing that. The goal of this project is to build an encyclopedia, not to blog about it. I like the adage: "Give a man a fish, he eats for a day, teach a man to fish, he eats for a lifetime". This tool is just about setting up a system where bloggers will be continuously asking for fish, and complaining about the fish they get. I also don't like the idea coming out in these discussions that these bloggers aren't considered editors. Do we really want to set up an arbitrary illusory boundary between readers and editors? WP:BATTLE amongst a myriad other things comes to mind. There's just a lot about this tool which seems directly contrary to "the wiki-way". I feel like I could go on and on about the problems this is (and will be) creating. - jc3717:23, 28 January 2013 (UTC)[reply]
This isn't really laid out too intuitively, but I think I'm opposing further implementation of the tool (that's what I intend to oppose). The solution to having a horrible and unwanted feature is not to tweak it, it's to get rid of it. GRAPPLEX17:25, 28 January 2013 (UTC)[reply]
Yes and no; you're opposing replacing the current version with a newly developed version which can be poked at. This isn't actually an additional development cost, since we have to develop the new version for other wikis anyway. Okeyes (WMF) (talk) 17:26, 28 January 2013 (UTC)[reply]
I didn't think it was an additional development cost, I just don't want to see a "version 2.0" hanging around when I don't particularly care for the core idea of the feature, let alone the particulars of its implementation. GRAPPLEX17:28, 28 January 2013 (UTC)[reply]
You requested a comment now and now is when you're getting it. Don't change the rules just because you don't like the outcome. If the tool wasn't even ready, why ask for comments about scope and resources now in the first place? This tool has been in development (and deployed without community authorization) for almost a year now. I sincerely doubt a few last minute tweaks will remedy its shortcomings. Not until we completely remove from the equation the tool's purpose to entice new editors can we have a serious conversation about how we design tools that help us improve article quality. That said, I'd be happy to work with both Okeyes and Fabrice on other solutions to increase the number of (and/or retain) editors. --Bensin (talk) 17:51, 28 January 2013 (UTC)[reply]
Meh. I'm still not thrilled with several situations regarding this where it seems to me that a local consensus overturned a broader consensus. But I am merely a single Wikipedian, who am I to disagree with the foundation when they want to railroad something through... - jc3718:38, 28 January 2013 (UTC)[reply]
You are correct, Okeyes. I retract the first three sentences of my statement. MZMcBride: The problem is not foundation not seeking community input. The problem in my view has been them not implementing, and complying with, the input given. Also, I don't approve of what might best be described as "project pushing". --Bensin (talk) 18:40, 28 January 2013 (UTC)[reply]
While I'm trying to assume good faith, the only reasonable conclusion I can see that the Wikimedia Foundation didn't start an RFC on its own is that it wasn't interested in hearing what the community had to say. If it had started an RFC, as I did, it would have become clear quite quickly that there is deep opposition to this tool and it would have been presented with a list of reasons why. So I continue to wonder, if all parties were acting in good faith, why the Wikimedia Foundation didn't start this conversation itself. Instead, it chose to set a deadline for a full-scale deployment. :-/ --MZMcBride (talk) 18:43, 28 January 2013 (UTC)[reply]
If we weren't interested in the community's opinion we wouldn't have spent fourteen months engaging with the community. I note you chose not to participate other than to start this RfC, which was disappointing. Okeyes (WMF) (talk) 19:56, 28 January 2013 (UTC)[reply]
Oppose. From what I see, the new tool doesn't address the issues and problems of the current tool, it just has an easier interface for moderation. We need a different solution. GregJackPBoomer!17:55, 28 January 2013 (UTC)[reply]
Oppose the proposed changes are ignoring the most fundamental problems raised so I don't see much benefit in waiting for them. In particular the fifth point basically involves trying to divert more editors from improving articles to processing AFT feedback, which doesn't really address the problem that AFT is placing an extra burden on the community rather than helping the community. I'd like to suggest that the AFT team ditches AFT and then goes through Bugzilla, the Strategy Wiki and all the other places where people have requested improvements and triages them all. Write at the top of a big sheet of paper "Since 2007 and the rise of templating the community has shifted from a SoFixIt mentality to a SoTagItForOthersToFix mentality, the community has gone off the boil and become a less productive and more snarky place. How do we fix this?" Then divide all the bright ideas into ones like AFT that steam in the wrong direction, ones that would have zero affect on the problem and ones that would mitigate the problem; Then go and implement a bunch of suggestions from that third group. ϢereSpielChequers18:24, 28 January 2013 (UTC)[reply]
Someone should start an rfc stating this, if only that I could support it (Hmm maybe in the spirit of SOFIXIT, perhaps I should, lol. Though in all fairness, I'd prefer WSC start it as it was his initial proposal : ) - jc3718:35, 28 January 2013 (UTC)[reply]
The tool is fundamentally useless and a waste of time. Spit and polish will have a chance to make it waste less time, but this would still be a waste of time. Courcelles18:39, 28 January 2013 (UTC)[reply]
Oppose mainly on procedural grounds. If consensus via this RfC is to remove the tool, remove it and be done with it. Based on comments in above sections, it looks like its going to be deployed on other wikis as well, so if it turns out AFTv16 is amazing, we can judge that based on how it works on other languages, and then have another discussion to re-enable the tool. Legoktm (talk) 19:03, 28 January 2013 (UTC)[reply]
Rather strongly oppose. As I noted previously, I have yet to receive anything through this feedback tool except useless comments from anonymous sources. If I ever do find a signed intelligent feedback comment, am I supposed to delve through edit history to find the iteration of the article to which it refers? I mean, a comment about a stub that has since been formed into a GA or FA is obviously past its pull date. A comment praising its article, which has since been stripped of most of its non-sourced but true material, would lead an editor to believe the article needed no work. Other such scenarios may occur to the inquiring mind.Georgejdorner (talk) 19:47, 28 January 2013 (UTC)[reply]
Oppose. I find it very strange that a tool that is 'known' to have so many problems should be rolled out for testing with a view to implementing it site-wide, and I am not convinced of the objectivity and quality of the evaluation of the tool's usefulness. I don't think it really makes sense to switch this RfC late in the day to be discussing a different version of the tool. Many of the objections to AFT are fairly fundamental and will not be changed by a new improved version of the same thing. If the result of this RfC is a rejection by the community, I would hope that a 'back to the drawing board' approach would be taken (to the issue, not the tool). --Michig (talk) 20:40, 28 January 2013 (UTC)[reply]
Oppose. I am unconvinced that tweaking this system is going to improve the quality of feedback in any meaningful way. We already have a functioning feedback system for readers to use: the talk pages. Axl¤[Talk]20:51, 28 January 2013 (UTC)[reply]
Partial oppose. The proposed changes sound promising, and I don't object to a trial run: run the new improved beta feedback tool on a small number of pages for six months or so, and then come back and ask the community whether it should be deployed more widely, fixed further, or scrapped. Any discussion of full deployment of the improved feedback tool is way premature until we have actually had the chance to try it out for an extended period of time. I don't see any reason to extend this RFC. We are judging the current feedback tool on its merits. My assessment is that the current feedback tool is a failure, and considering full deployment is not merited at this time. If some future feedback tool is better, I'm open to it, but it will need an extended test run for the community to evaluate it before full deployment is even considered.--Srleffler (talk) 01:40, 29 January 2013 (UTC)[reply]
PS. I'm opposed to adding a link at the top of the article pages. I would encourage instead that you make a more obvious connection from an editor's watchlist to the feedback on the watched articles.--Srleffler (talk) 01:43, 29 January 2013 (UTC)[reply]
"Sure; as the proposal explains, we're not looking to fully deploy a new version, we're looking to replace the current randomised deployment of AFT5 on a subset of wikipedia articles with 5.2, as it were. It wouldn't hit all articles, or any articles the existing tool doesn't already hit. Okeyes (WMF) (talk) 01:45, 29 January 2013 (UTC)[reply]
I understand that, but your proposal seems to assume that that trial will last a couple weeks, and then be followed by full deployment. I object to any consideration of full deployment until a version of the tool has been tested for at least a few months on a small number of articles, and has achieved community support. Slow down, take your time, get it right, and then come back and ask us if we want to deploy the thing to the whole encyclopedia. --Srleffler (talk) 03:11, 30 January 2013 (UTC)[reply]
No, my proposal seems to assume that the trial will last a couple of weeks, and the community will then decide if they want to continue the trial, ramp it up everywhere, or turn it off completely, or opt in, or...etc, etc, etc. The problem with testing on a small number of articles is that if we start messing with the pool of articles as well as the software, it becomes pretty much impossible to tell which is having a positive impact (if there is a positive impact): at the same time, the smaller number of articles, the greater the chance that any results of the experiment are unreliable. Okeyes (WMF) (talk) 03:45, 30 January 2013 (UTC)[reply]
I see. I understand your concern. I'm not sure how to respond to it. I don't think a couple of weeks is going to be sufficient. Given how badly AFT5 has failed, I think a much longer trial of 5.2 is required. The only way I could support a couple-week trial is if it were agreed in advance to have a !vote at the end on the question of killing it or continuing the trial (no option to deploy further without a longer trial).--Srleffler (talk) 05:43, 30 January 2013 (UTC)[reply]
That seems sort of unnecessary, insofar as the only way that another option ("opt in" say) could be acted on is if the community, following that trial, decided it was worthwhile. Now: I get the problem of 'they might make a problematic decision based on insufficient evidence'. But this is a conversation on trialing improvements to the software so that people are making a decision on the software as it would be deployed. I'd argue that if making a decision after a two-week trial is too great of a risk, making a decision about software that hasn't been deployed is an even greater one. Okeyes (WMF) (talk) 06:01, 30 January 2013 (UTC)[reply]
Oppose. Too little, too late. The problems with AFT are fundamental, and can only be solved by killing the thing altogether. MER-C02:24, 29 January 2013 (UTC)[reply]
Oppose I don't see how this will get us past fundamental concerns I have with the tool. This sort of feedback would work a great deal better with all Wikipedia processes if it were built to push that information into talk pages. Anti-vandalism tools would work immediately. Ditto edit-filters, watchlists, page protection, and many sorts of policy around oversight. Worse than the numerous complexity issues, by creating two distinct classes of talk page, we're creating two distinct classes of regular users, a divide which (in my view) is much harsher than the editor/sysop divide, and undercutting the ways in which we encourage new users to edit--all at a cost of greatly increased complexity. Could some of the putative good be saved? Maybe. I'm not sure, honestly. It could be that the back end of the AFT could be modified to take better advantage of the Talk page as the repository for reader feedback. How that can be reconciled with the desires to make use of the data in a more structured form is not something I have a clean answer for, and it may in fact be impossible, but I'm not yet willing to say it is impossible. While I don't say this lightly, there has been a lot of great work by a lot of people, I don't see the path above as currently converging to a net positive for Wikipedia along. --j⚛e deckertalk03:21, 29 January 2013 (UTC)[reply]
I would like to support this rational- and balanced-seeming proposal. I really have found i have to Oppose though because, as well put as all Okeyes' comments are, they end up not addressing the primary issue ~ the tool is a poor solution for a set of problems (attracting readers into the editor camp and getting feedback on articles) which have a better solution (talk pages) already. Sure, pressing that Talk button might be a bit intimidating (i was terrified i would break something the first time i did, i clearly remember), but it works; i'd be happier seeing Okeyes putting his energy into promoting talk and how to make it clearer for readers how easy talking is than promoting this tool, the primary use of which seems to be to make it easier for vandals to leave their drivel. Cheers, LindsayHello04:12, 29 January 2013 (UTC)[reply]
Switching to oppose. After thinking about it a bit more and reading what others have written, I'm finding it hard to justify my endorsement of waiting to see what good the improvements do. I'm sure they will be improvements, but the fundamental problems almost certainly will remain. Let's put the developers to work on making talk pages more user-friendly for newbies and get rid of what can only continue to be a distraction as long as it's a separate system that's parallel to the established system for commenting on articles: the talk page. I still don't think any great harm would come of waiting, but I suspect we'd end up repeating this same discussion in a few weeks and come to the same conclusions, and that would be unnecessarily tedious. Rivertorch (talk) 06:42, 29 January 2013 (UTC)[reply]
Strong Oppose the proposed changes DO sound like an improvement, in the sense that a punch in the face is an improvement over a baseball bat to the nuts. I find it kind of insulting that the WMF, faced with overwhelming consensus against the tool, is basically saying "well, whatever, we're going to keep working on this horrible piece of crap anyway". The problems with the tool are fundamental and not something that further tweaking or testing can improve upon. What the WMF should do is admit it goofed and apologise for wasting OUR donation dollars on this thing. Andrew Lenahan - Starblind19:20, 29 January 2013 (UTC)[reply]
Andrew, as I've repeatedly made clear, we've already developed the new version (we're waiting on code review and some backend features before we can deploy it) and even if the community does reject this, since we've got the tool deployed on the German and French Wikipedias (both projects having accepted it, either fully or for a trial) we'd have to develop this stuff anyway. I appreciate this is an emotional issue (for me, at least: I've spent 14 months of my life on this tool) but I would ask you to please not make this, I guess, personal: 'the tool is bad' is fine. 'the tool is bad and those who developed it should feel bad and apologise because they screwed up' communicates nothing more except for hurtful sentiments. Okeyes (WMF) (talk) 21:07, 29 January 2013 (UTC)[reply]
Oppose along with Starblind, I think most of the changes are an improvement. But this should not delay the removal of the current version , against which there is overwhelming consensus. Then let the new version be proposed, and possibly accepted for a small trial. The concept behind AF is not necessarily a bad one, but the balance between making it unobtrusive and yet clearly visible enough to be used is very difficult, as is the balance between permitting people to say what they want, and removing improper comments. We have an almost overwhelming job of removing harmful material in our regular way of editing; I think that in the last year or two we've finally managed to get somewhere, I would be very reluctant to increase the workload on what has to be reviewed. I don't particularly agree with the conspiracy theories about the WMF. I think they're trying to engage the community. It's just that they are very clumsy at it. Given their continuing lack of understanding, it is our responsibility to explain it to them more clearly, and our reaction to proposals like this is the best way. We are basically saying what we need to say, if we reject something, do not do it; don't try to evade the issue by testing additional versions instead of following the community's consensus. The first step in engaging the community is respecting its decisions. DGG ( talk ) 20:21, 29 January 2013 (UTC) .[reply]
Oppose - If there are significant changes to the tool, it should be dealt with in a separate fresh RfC to give it a fair hearing with fresh judgement. In the meantime, while I understand that people have worked hard on it, if the overwhelming opinion of the community is that the tool is not useful then it should be switched off for now. I would prefer that a new version be trailed first before deployment anyway. CT Cooper ·talk21:47, 29 January 2013 (UTC)[reply]
By trail I mean very limited deployment, on a selected number of articles, with the exact scope decided by the community. Once the trial is complete, the community can make an informed judgement if they want full implementation or if they want to ditch it completely. CT Cooper ·talk02:07, 30 January 2013 (UTC)[reply]
Oppose -- Were it absolutely the most perfect thing in the customer-relations universe, it would still be a massive timesink which takes away from the important work of building the encyclopedia. In the best of all possible worlds, the signal-to-noise ratio of the tool is going to be extremely low, something that software design can't change, because it comes with the user base. I realize that the WMF is going to roll out this new version no matter what we say here, and I certainly hope it's an improvement, but I would prefer that they spend their time and money doing something much more valuable, like converting to a registered-users-only system and eliminating the vandalism that does along with allowing IP editing, or even putting some money into a war chest for the inevitable copyright lawsuit which is bound to come, and seems to have the Foundation running scared. Beyond My Ken (talk) 03:48, 30 January 2013 (UTC)[reply]
We're not; we're asking for permission to roll out a new version, exclusively so that this new version can be evaluated as part of *this* RfC. If we didn't plan on respecting the community's opinion about a deployment of 5.2 I would not have opened this sub-vote. Okeyes (WMF) (talk) 19:34, 30 January 2013 (UTC)[reply]
Oppose This was a worthwhile experiment and was well executed by Okeyes and the rest of the WMF technical staff, but the fundamental problems with the tool are such that it should be discontinued. The new version of the tool doesn't appear likely to resolve the issues I and others have raised in the RfC, most of which aren't of a technical nature anyway. Nick-D (talk) 07:18, 30 January 2013 (UTC)[reply]
Oppose, at long last I understand that having readers leave one-time comments is considered a goal in itself. I have long misunderstood: I thought the goal was purely to use AFT as a stepping stone to engaging on the talk page or in article space. If that had been the design goal, we would have a very different tool, and probably one whose continued use I would support. But it seems to me the goal has been the wrong one from the beginning. Wikipedia's strength is as platform that supports two-way communication; while that communication is not always pretty, the general formula has gotten us to where we are today. I'm not interested in a tool that further fragments discussion and reduces oportunities to deliberate back and forth and come to agreement. I think it will steer the project in the wrong direction. I do think experimenting with this kind of feature has been a good thing though, and hope the data produced proves valuable to the next editor engagement project. -Pete (talk) 08:58, 30 January 2013 (UTC)[reply]
A caveat -- I can see the benefit of leaving AFT enabled in the "Help:" namespace. Maybe that would be a good way to roll out the new version and put it to some productive use on enwp. -Pete (talk) 10:04, 30 January 2013 (UTC)[reply]
Oppose - minor tweaks to the existing tool don't solve (what I perceive as) the fundamental problem that the tool creates two separate places which hold comments, suggestions etc to improve the article. The effort would be more productively spent on a tool that made it easier for a reader to add a new section to the existing talk page. Mitch Ames (talk) 11:41, 30 January 2013 (UTC)[reply]
Oppose per MZMcBride, DGG, others. We've seen how this plays out before, with the WMF folks not liking the community input they get and then trying to find some way to avoid having to listen. No, there's no conspiracy and yes, they do some really good things, but it's happened enough times over the past few years that it's becoming a disruptively WP:IDHT situation. To the merits, the proposed fixes would do little to nothing to solve the problems I and others see in the tool. As such, even assuming this proposal had been made in good faith, there would be no point in it. If the fix doesn't address the problem, there's no need to try it out. – PhilosopherLet us reason together.20:12, 30 January 2013 (UTC)[reply]
oppose per Mitch Ames, if the up-coming fixes dont significantly address the majority of concerns, and it does not seem to me that they will, there seems little reason to think that the communities reactions will change. 20:17, 30 January 2013 (UTC)
Proposal is unclear. By "one click moderation", do you mean the same flawed set of choices with a different activation button or do you mean that we can finally revert vandalism and spam? --Guy Macon (talk) 17:22, 28 January 2013 (UTC)[reply]
The labels and categories have been clarified a heck of a lot to essentially divide into 'useful' 'not actionable' and 'inappropriate'. If you encounter nonsense, you can hit 'inappropriate' and it gets hidden. The narrowness of "hide"'s definition was kind of a pain for handling not-offensive-but-disruptive stuff, I appreciate, and we've tried to fix that. 'not actionable' also gets it nicely out of the way so people don't have to choose between doing nothing and marking it as 'resolved', mixing it in with useful-and-implemented feedback. I just wish we'd had this four months ago :/.
At the same time, there is a one-click element: people hit 'inappropriate' once, it goes. No finnicky edit summaries. I'll clarify to note that this is included. Okeyes (WMF) (talk) 17:25, 28 January 2013 (UTC)[reply]
Thanks! I will strike out the above after the clarification is added and I know what is to be done with not-offensive-but-disruptive stuff. Also, may I make a small suggestion? in the slides I keep seeing disclaimers about some feedback being posted before abuse filters were in place. Before a new version is rolled out, please figure out how to apply those filters to the existing feedback or archive it all with a "these are all from the old version" note and start fresh. --Guy Macon (talk) 17:36, 28 January 2013 (UTC)[reply]
Yeah, we have :). There will be an auto-archive feature which will automatically archive all non-moderated feedback more than N (we're thinking 30? it can be tweaked on the fly) days old. It'll be invisible to readers, and invisible to editors unless they go a-hunting, meaning that we can scrap the pre-abusefilter stuff and also prevent a tremendous backlog of stuff to do building up. Okeyes (WMF) (talk) 17:40, 28 January 2013 (UTC)[reply]
Sounds good. When you roll out a new major version, you can have it start with the autoarchive time at one minute, and as soon as everything is archived you can set it to whatever the real autoarchive time is. --Guy Macon (talk) 17:48, 28 January 2013 (UTC)[reply]
If you could somehow differentiate between the inane "likes", vandalism and the meaningful comments then archiving inanities after thirty days would be helpful - of course some pages would need it more frequently. But Autoarchiving everything means that the occasional useful comment will also get discarded and that is a bitey think to do. My view is that we are better off not asking for such feedback than asking for it and not being able to action it. Two things that would address some of my concerns about this tool would be first to auto archive likes and similar inanities - if we can design filters to pickup vandalism we can also design a filter that picks up permutations of "Luv u Jason" and archives them after say 24 hours; Secondly to shift from collecting feedback to encouraging improvement. So anyone clicking "lacks images" could be taken to a "search our image library" window and then if they find an image they want to add auto guided through the process of adding it to the article. Equally anyone clicking "there is a typo" could be guided to a simple search and replace process - with an accompanying pop up explanation if they want to shift between English and American English spelling. ϢereSpielChequers18:04, 28 January 2013 (UTC)[reply]
We're looking into an attempt at a cluebot-esque thing for feedback, but I'm not entirely sure where we are and didn't want to promise what I couldn't commit to delivering. Okeyes (WMF) (talk) 18:36, 28 January 2013 (UTC)[reply]
I would have no serious objection to either (1) extending the current RfC or (2) letting it run its course, then opening a new request when the new-and-improved feedback tool comes on line. Notwithstanding the large number of commenters who find the current tool either unhelpful or "a disservice" to readers, I don't take the RfC as forbidding introduction of the revised tool, which could be evaluated on its own merits. Cnilep (talk) 00:13, 29 January 2013 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
For what it's worth, since you posted your proposal, two more editors have signed on to Greg's view, bringing it to 58 endorsements so far. I fear that any action that the Wikimedia Foundation takes to delay the implementation of the consensus found in this RFC will be seen—fairly or not—as a "bait and switch" and will be viewed very negatively by the editing community. --MZMcBride (talk) 18:15, 28 January 2013 (UTC)[reply]
No. The only "bait and switch" here is using an RfC that says "to determine the answer to a few questions:" in "1 Background" and pretending that the answers to an entirely separate question in "7 View By GregJackP" are somehow the result of the RfC.
Many people just read the first paragraph of an RfC and, if they don't care about the answer to the specific question asked, move on. Thus a question buried in one of the views gets an answer from a biased sample.
If you expect WMF to take a specific action based upon a Wikipedia RfC, I suggest that you create a new RfC with a title and a summary asking that specific question and seeing what the answers are.
And, I might add, I suggest that you spend the pre-RfC period discussing whether the wording is right instead of using it to give certain individuals selected by you a chance to get in their views before those who don't pay attention to Rfcs until they start get their shots in. If you had spent more effort on the issue of whether you are asking the right question, perhaps "should we shut it down?" would have been one of the questions at the top of the RfC. --Guy Macon (talk) 19:00, 28 January 2013 (UTC)[reply]
I don't mean to be rude, but nobody seems to agree with you regarding how to conduct an RFC. Question 1 of the RFC is "What should the scope of the article feedback tool be (cover all articles, opt-in per article, etc.)?" and Greg's answer was essentially that the scope of the feedback tool should be none. Regarding the Wikimedia Foundation and expectations, I'll just state again that nobody seems to agree with you. If there are others who do, I urge them to weigh in here or on my talk page or elsewhere. But as it is, over 130 editors have participated in some way in this RFC. Of those 130-plus editors, 58 have endorsed a(n extreme) view of completely disabling the feedback tool. I think that pretty much speaks for itself. --MZMcBride (talk) 19:21, 28 January 2013 (UTC)[reply]
Maybe somebody could answer this for me: why are multiple versions of the AFT still deployed? For example, AFT5 is at İsmet Hürmüzlü while an earlier version (and seemingly far more commonly in use) is at Maryland Route 279.
If we are to think of the AFT as undergoing version-numbered updates, then previous versions should be made obsolete very quickly. Instead, we've treated AFT5 as something of a fork of the earlier tool. I vaguely recall discussions where it is fairly well-agreed that AFT5 is an improvement over the star-rating versions. Why then do the star-rated versions persist? Does it have a loyal set of supporters? Who are they? Will yet a third version be introduced concurrently with this proposal? Jason Quinn (talk) 19:41, 28 January 2013 (UTC)[reply]
No, as my proposal makes clear :). 5.2, as it were, will replace 5. 4 has not been deprecated because we felt the information was still sort-of useful and it presented a less inconsistent interface for readers than 'no feedback form on most pages' and 'a feedback form on some, with no discernible explanation as to why'. Okeyes (WMF) (talk) 19:54, 28 January 2013 (UTC)[reply]
All computer programmes are an unfinished version - probably nothing in the world today is as on-going as software development, and WMF projects are no exception - like all software developers, they launch new products before they are really ready for deployment. Like many software products, they are designed from the perspective of the designers who sometimes only pay lip service to the need for use and operation by people who want tools but who don't want to know how they are made. The AfT was designed for the Foundation's constant hunger for stats, but without being of any real advantage to the overall state of our articles, and it simply creates a further drain on the time and resources of our dedicated, regular volunteers who are getting weary of cleaning up the Foundation's mistakes.
Extending a Wikipedia RfC usually has one goal: to increase support for the outcome favoured by the proposer(s). I have stated many times on Wikipedia that the flaw (per MugginsX, MZMcBride, and Guy Macon) with RfCs is that they often get bogged down and sidetracked to the extent that the overview gets lost, and people do not read the entire discussion before casting their vote. Hence many comments are based simply on 'like/don't like'.
I was never in favour of the AfT and I gave up commenting on its earlier discussions and development because I knew that the Foundation would plough on regardless, just at it does with many of its projects and fiats that the community does not approve of. I'm not sure that AfT has been a 'low priority effort' (Eloquence), and while I admire Oliver's tenacity on this and other Foundation projects that he has worked very hard to promote and keep on track, after 14 months it's time now to understand that AfT is a dead horse to be 'eliminated'. The salaried team(s) of engineers should now be redeployed to focus on some other solutions for new user reception/retention, and article improvement, recognised by the community as being of truly high priority.
On the eventual discontinuation of AfT, I would concede to a simple message at the foot of articles such as: If you would lke to comment on how this article could be improved, feel free to start or join a discussion on its [[talk page]]. Kudpung กุดผึ้ง (talk) 01:21, 29 January 2013 (UTC)[reply]
I'm curious, the consensus on the RfC appears to be to remove the tool (at 60 supporting right now), and this quick straw poll is running at about 2:1 opposing the new tool. Is this RfC & straw poll going to be final, or will we have to readdress this later? My position is that if it works well on other language wikis, we can always, as a community come back for it, but that until then, it should not be deployed here. GregJackPBoomer!05:01, 29 January 2013 (UTC)[reply]
Well, there are three weeks to go, so there's still the possibility of a miraculous comeback for those in favor of a full-scale deployment. But you're right, of course, Oliver, et al. have now learned that this tactic (attempting to extend the RFC closure date) isn't working to work, as there seemingly isn't sufficient support for it. It was worth a shot, on the Wikimedia Foundation's part, but as far as I'm concerned, this will be the last "sub-vote" we see of this kind, a "one and done" kind of thing. --MZMcBride (talk) 05:31, 29 January 2013 (UTC)[reply]
Huh, it seems to have shifted towards a more balanced 3:2 in the last five hours, granted I am supporting the suggestion. In any case, I guess that we will soon be seeing the end of the tool soon. --Super Goku V (talk) 10:19, 29 January 2013 (UTC)[reply]
Sure; my point was merely that (firstly) it is rather a low priority effort - again, a single engineer - and (secondly) that there isn't actually a question of 'will building version 6 cost resources better spent elsewhere'. The resources have been spent. Even if they hadn't, we'd have to spend them for the other projects that are trying or seeking to deploy this tool. It's not a matter of cost or redeploying to focus on higher-priority solutions. Okeyes (WMF) (talk) 01:36, 29 January 2013 (UTC)[reply]
I believe it's a single full-time engineer. That is, there's one person working full-time on this project (which is more than nearly any other project gets, by the way), while there are a number of other engineers (some of whom even happen to be full-time Wikimedia Foundation employees) involved with this project in some capacity.
For example, as I understand it, Matthias M. is the primary full-time engineer. But other engineers (such as Asher F.) have worked on other components of this, such as database backend support. "Splitting hairs" is putting it nicely. Erik was careful in crafting his comment on this talk page to be technically correct. You (Oliver) seem to have veered off that path. Kudpung, good to see you, as always. --MZMcBride (talk) 05:27, 29 January 2013 (UTC)[reply]
Again, you're missing my main point: the database sharding? Has to be done anyway for de.wiki. Code review? Has to be done anyway, de.wiki. Yes, there are some assets attached to this for a few hours a week - but they'd be attached anyway, because it's a piece of software other projects want (unless you're suggesting that, because enwiki doesn't want it, we shouldn't build it at all). Okeyes (WMF) (talk) 02:23, 30 January 2013 (UTC)[reply]
If this is your point, beware the ridicule. AFT has been built exclusively for en.wiki and all the rest are byproducts, as the team has reiterated countless times: Fabrice confirmed this a few days ago, «This could be the beginning of a wonderful trend, where our software development efforts would no longer be driven primarily from an english-centric perspective, but embrace a more global approach instead» (emphasis added).
Moreover, Bug 42881 – ArticleFeedback has hundreds of unaddressed internationalisation issues is still open; reports of i18n/l10n issues have accumulated for more than a year and were addressed for the first time only a month ago. I'd like you to remember the many hours translatewiki.net translators and staff spent over AFT headaches (21 thousands translations and hundreds of reports), like many code reviewers, database engineers, ops, debuggers etc. (548 bugs filed, making it a top 10 or so all time biggest bugzilla component and the single biggest one in its timespan, after WikidataRepo, excluding configuration requests and "general" components): it's not true that "they'd be attached anyway" to AFT, they were forced by AFT being imposed over us and they could have been spent over something else. Maybe it was a good investment, but please stop denying the investment many people made over this project. I personally find it insulting. --Nemo10:35, 30 January 2013 (UTC)[reply]
I'm not denying the investment; I'm pointing out that the investment was already necessary. And it is: you're misunderstanding Fabrice's email. He can't have meant 'we're not deploying for other projects or building for other projects' because, frankly, we have deployed to other projects. The Germans and French both have it, for example. Okeyes (WMF) (talk) 17:57, 30 January 2013 (UTC)[reply]
No, it wasn't already necessary, as I said above; and yes, you're denying the effort, with all this «one engineer», «it is rather a low priority effort - again, a single engineer -» etc. And no, I'm not misreading anything: I didn't say that the tool wasn't deployed to other wikis, only that the needs of other wikis have not been considered in developing it, which is hardly a novel concept, and that "foreign deploy" is just a byproduct. --Nemo18:51, 30 January 2013 (UTC)[reply]
Could we add a 'feedback' tab and page beside the 'talk' tab to each article. We could call it feedback, comments, input, critique, etc. We could place a warning at the top for other readers like: "Warning! This page may not be moderated in a timely manner and therefore it may contain unsourced material, opinions, and words like boobs" type thing.--Canoe1967 (talk) 17:51, 29 January 2013 (UTC)[reply]
I think some wikis actually call the "Talk" tab "Feedback." I'm trying (and failing) right now to remember which wikis. Of course "Talk" was previously "Discussion." I personally don't think another tab is the solution here, particularly given the high likelihood that it would simply create confusion for users: "do I post to the talk/discussion page or do I post to the feedback page?" "What's the difference?" Even as someone who understands the distinction we'd be creating, articulating the distinction to users would be very difficult to do, I think. --MZMcBride (talk) 19:31, 29 January 2013 (UTC)[reply]
It might be as simple as just re-naming that tab to dual purpose then. Input/Feedback, Discussion/Feedback, Corrections/Discussion, etc.--Canoe1967 (talk) 02:13, 30 January 2013 (UTC)[reply]
Was one of the reasons for creation to have edits from these devices then? That may be awkward if editors can't discuss on talk pages or access their own messages and warnings on their talk pages. Btw a friend with an iPad has access, I will have him check his iPhone as well. Many of these devices may show dynamic IP addresses which may make policing even more difficult.--Canoe1967 (talk) 16:31, 1 February 2013 (UTC)[reply]
No, that was not a rationale; the rationale was simply that the current talk interface is unwieldy and difficult to use (and does not surface things properly). Okeyes (WMF) (talk) 17:00, 1 February 2013 (UTC)[reply]
Is it technically possible to have the feedback linked to the talk page and create a date stamped header? Any response to that talk section could then show on the feedback page as well?--Canoe1967 (talk) 17:06, 1 February 2013 (UTC)[reply]
We probably could fairly easily. The problems, though, are fairly substantial; first, high-profile articles get a lot of feedback. Talk pages are designed to load as one big mass of wikitext, not as discrete elements, which means that they would swiftly become massively overburdened. If vandalism is submitted, there's no such thing as a one-click hide function, and it can be very difficult to disentangle submitted edits once succeeding edits have been made. Second, the advantage of being able to reply is lost when the only way they can comment back is through wikimarkup, which is the problem with talkpages in the first place. Okeyes (WMF) (talk) 18:00, 1 February 2013 (UTC)[reply]
Could we add an option to the feedback to leave a note on the talk page if the reader wishes? Perhaps the article as well. "Click here to correct or click here to request correction" type thing.--Canoe1967 (talk) 18:16, 1 February 2013 (UTC)[reply]
This is the sort of design/approach I had thought was at the core of the project from the beginning. I think there is a potent opportunity down this path, but I worry that a quick-fix retrofit would cause more disruption than good. The different dynamics on popular pages vs. rarely-discussed pages is one of many dimensions that should be thought through first. If there is will and resources to develop a roadmap around this, starting with an exploration of what is known and desired by WMF staff and what is known and desired by highly engaged volunteers, I would strongly support that. At this point, it seems to me that WMF is ready to move on, but if that should change I think there is room for a productive project in this direction. -Pete (talk) 18:33, 1 February 2013 (UTC)[reply]
Okeyes, it would rather help (you) if you stopped useing false arguments. I may agree talk pages are not that easy to master, but it is not true that you need any wikimarkup to use it. Insisting in false reasoning only make yoiu look bad
Nabla, my argument was that you need wikimarkup to handle the replies - which you do. If a newcomer hits a talkpage section that has already had things posted, they're going to be confronted with markup from signatures, section headers and
All I need is to hit (section) edit, write at the bottom, and hit "save". No wikimarkup at all needed. There is no need to read through the source text. If indentation is crucial, someone can, and will, help. Also you argue with talk page difficulty versus AFT5's near zero dificulty. Neither using talk page is as hard as you try to present it, nor the AFT5 is that obvious to use and, most of all, to understand it's purpose. Nabla (talk) 17:52, 2 February 2013 (UTC)[reply]
Sure; you don't need to read through the source text. But my point is that it's not accurate to suggest 'you don't need to be able to parse/use wikimarkup'; there will be wikimarkup. And I seriously doubt anyone is going to hit edit, be confronted with a load of markup they've never seen that wasn't on the page, and not get slightly weirded out. I mean sure: this does work if we assume that people will not read source text. Do we have any evidence that's true? And if it is true, why are talkpages not overrun with feedback already? Okeyes (WMF) (talk) 19:06, 2 February 2013 (UTC)[reply]
Oliver, Nabla's point here is pretty straightforward and factual, but you seem to be hearing something he or she is not saying. Nabla's point is about the "New Section" link (which is closely analogous to AFT5), not the "Edit" link. There is no wiki syntax involved. (Extending the new user's interaction to read and/or make followup comments would be desirable too, but that's a different, more complex discussion, and probably not one worth having given the lack of resources to fully explore or implement it.) -Pete (talk) 20:04, 2 February 2013 (UTC)[reply]
To be fair I must say I am referring to both cases. As you said, creating a new talk section needs no wikimarkup at all. When replying, yes it may get scary to look at that weird text, but nevertheless there is no need to learn to read nor write wikimarkup, only the need for an effort to ignore it. Okeyes, I don't know why the talk pages are not overrun with more input (but I am surprised that you apparently do not know either!?) But I woud suggest a test before blaming it on the wikimarkup: use the exact same 'bait' as used by AFTv5 (a big box at article's the bottom with a direct question with simple click-button-yes/no answer) then, instead of displaying a text box, redirect users to a new section in the talk page (example, imagine "Great. Any suggestion for improvement?" writen at the top). Would there be more, less, the same input as nowadays? That is, how much of the extra input is due to avoiding wikimarkup, and how much is due to the extra visibility plus a simple baiting question? I'd bet most is not the wikimarkup. All in all, you do have some points. Talk pages are not the simplest and most intuitive thing in the world. It is possible to improve on that. It is a pity if one and a hlaf year's work get's wasted. etc.. But ignoring simple factual information does not help you. - Nabla (talk) 23:35, 2 February 2013 (UTC)[reply]
At this point I think it's fairly clear we're not going to come to an agreement. On the 'study' point; we're in the middle of a big discussion about how a lot of users don't want the feedback users are leaving, given the good:bad ratio. I suspect 'okay, but can we perform a test to satisfy one user's curiosity?' is unlikely to be met with cheers of approval. We've conducted user tests already, on talkpages, and will be doing more in the future for Flow; they have shown that users are dissuaded from using talkpages due to the formatting and, yes, the markup. Okeyes (WMF) (talk) 00:20, 3 February 2013 (UTC)[reply]
I have not suggested a test to satisfy me, I suggested a thought experiment to you. Given your current knowledge and information what do you think would be the result? If you have done user tests, then why say «And I seriously doubt ..." (your quote, my emphasis) when you could say "according to study 'xxx' I know that ...". Could you please point us to the study, or any information on that study, so we can see it? - Nabla (talk) 17:20, 3 February 2013 (UTC)[reply]
Oliver, I'd like to request that you not so quickly jump to the "satisfy one user" point. You suggested in a different thread that I was alone in having a certain view, and two other highly engaged users jumped in (without prompting from me, by the way) to emphatically voice their agreement. Similarly here, you seem to downplay Nabla's interest as being peculiar to him/her; but this area is very much of interest to me as well, and I believe probably many other participants in this discussion. I would appreciate a discussion that remains more focused on ideas and their merits, and less on the qualifications or political strength of the people bringing them up. You may of course need to make those assessments privately, but publicly stating that people's views are outliers is damaging to the discussion (and, in these two cases at least, highly inaccurate). -Pete (talk) 19:49, 4 February 2013 (UTC)[reply]
Pete, something can be based on numbers or political strength of participants, not both. I'm not trying to downplay it as 'not of interest': I'm pointing out that it's ultimately rather purposeless given the fairly clear outcome of the discussion. Okeyes (WMF) (talk) 19:51, 4 February 2013 (UTC)[reply]
It was proposed not to satisfy anybody, but to explore a potentially useful area. If you disagree on the assessment of whether it's useful, why bring up the idea that it would "satisfy one user?" This kind of language has the effect, if not the intent, of marginalizing people. -Pete (talk) 19:57, 4 February 2013 (UTC)[reply]
Because I read it as 'I would like this data to satisfy my own train of thought, in the hope that this will be useful to evaluating the tool overall', and replied to address both points. At this point we appear to be splitting hairs, so I'm going to go back into my box. Okeyes (WMF) (talk) 19:59, 4 February 2013 (UTC)[reply]
Yes, this discussion has probably run its course for now. But I think this is a very important point, not splitting hairs at all. I would argue what's under discussion is fundamental to having productive interactions around product design and evaluation. -Pete (talk) 21:27, 4 February 2013 (UTC)[reply]
(ec) I point you, Okeyes, to a few things: I started out by agreeing that "talk pages are not that easy to master" (due to markup and 'protocol', evidentelly, I presume), I simply pointed that stricltly speaking you do not need wikimarkup. To insert a one time comment, which is all AFTv5 allows a user to do, you do not need to even be aware of the existence of wikimarkup, which is a self evident truth, as you can check for your self by leaving a comment. You say that we need wikimarkup to reply. Striclky, you don't, but yes, it surely helps, yes it sure may scare new users - I said so from the start! But if you want to compare how hard it is to reply and follow up on talk pages (which is somewhat hard, sure), then you need to compare how do you reply and follow up using AFTv5. I asked you long ago, and my question - below - is still unanswared. So using a talk page is a hard way to reply (we both agree on that) but given it is impossible to reply using AFTv5, we can not compare them (and if we do, talk pages win, because hard or not, we may reply). You asked why do we have a lot of AFT feedback, and not as many Talk page feedback. Evidently, I can't *know* that, but I gave a hypothesis. I wrote it in the form of a gedanken experiment, if you can not understand that, that is your problem, not mine. You choose to ignore that I agree on most of the issue (yes, wikimarkup is hard, yes there may be a better way to get input, yes it is worth to keep on testing this or similar tools) and instead go on and accuse me of asking for a test to satisfy one man... - Nabla (talk) 21:52, 4 February 2013 (UTC)[reply]
My apologies; I missed the "talk pages are not that easy to master" (this is, I think, good evidence as to why I should take time off when ill rather than keep working). Okeyes (WMF) (talk) 05:28, 5 February 2013 (UTC)[reply]
We could possibly add a 'add input/feedback/request section' template to the top of each talk page to make it easier for new editors as well.--Canoe1967 (talk) 18:04, 2 February 2013 (UTC)[reply]
Are there any good resources which 'show off' specific instances of AFT being useful for something other than new editor recruitment? i.e. including link a piece of feedback coupled with subsequent usage of the feedback to benefit the content. It would be good to have use cases where it works well, backed by examples of where it has happened in practise. So far I can only find statistical summaries which suggest its good for new editor recruitment, and a few comments by AFT-active users in the RFC where they say they have utilised the reader feedback, but only a few specific examples without any decent writeup about those examples. Forgive me for not reading the entire RFC and research documentation. John Vandenberg(chat)07:20, 30 January 2013 (UTC)[reply]
So, a highlight reel, as it were? I could probably put one together, but I've deliberately resisted one because I feel that subjective evidence tends to give a false impression, and I don't want to deceive people. I could easily pull out a dozen examples of feedback being actioned, but without any way of going "these are some of many " with confidence. Okeyes (WMF) (talk) 07:32, 30 January 2013 (UTC)[reply]
John, one thing that has stood out to me as an important opportunity, both in watching the feedback for my watchlist items and in discussion about the tool, is using the tool in the Help: namespace. (I've seen a ton of feedback going by for WP:CHEATSHEET, which is not in that namespace, but same idea.) -Pete (talk) 19:36, 30 January 2013 (UTC)[reply]
Thanks Pete, but I've done that a few times, and I want to scream every time I look at it. It is a colossal waste of time in my opinion based on the few times I have played a little, both in the development effort and in the community effort required to make sense of this new firehose of shit that has been unleashed on the wiki. That is why I am asking for its supporters to give me something to demonstrate it has been useful to them for content. John Vandenberg(chat)23:30, 30 January 2013 (UTC)[reply]
Yow, OK. Not sure unleashing the firehose of shit on this page is going to help matters, but do what ya gotta do. I'll let those more informed about the tool address what you say, after they clean off their glasses ;) -Pete (talk) 03:35, 31 January 2013 (UTC)[reply]
Hi Oliver, I can appreciate that, but a highlight reel is a list of highlights; its obviously one sided, but I think it would be useful to see the best story that you can put forward, and I want details about content rather than stats about new editors (the latter is good, but new editors are a means to an end - some of us are trying to build an encyclopedia). I'm sure AFT has been useful, but the signal to noise ratio makes it hard for someone like myself (with limited time) to see the good stuff. I only need to open AFT to see the bad stuff; I need someone else to find and present the good stuff. John Vandenberg(chat)23:47, 30 January 2013 (UTC)[reply]
"Think carefully and consciously about whether you really want feedback, and why. If you truly think that you could benefit from someone else’s thinking, then ask for it. But if you feel confident that what you are doing or thinking is already good enough, then it’s OK not to ask. In other words, don’t ask for input as social convention. Do it only if you mean it.
If you do ask for feedback, be prepared to seriously consider it. That doesn’t mean that you have to do everything that’s suggested, but you should at least listen and think about it. Then give the person who provided the feedback some acknowledgement or thanks for making the effort (and maybe even an explanation of what you’ve done with the input)."
This whole project appears to have been done with the "we should ask for feedback" without any consideration about whether and how we as a project can and should react to such requests.-- TRPoD aka The Red Pen of Doom17:35, 30 January 2013 (UTC)[reply]
Was there any community drive for a "we need and want feedback to improve the quality of articles?" - was there any consideration of "this is how we will be able to utilize the feedback to improve articles"? - was there consideration that the false front of "please give us feedback" as a backdoor cover for "we want new people to become editors" would likely backfire when there was no good way of acknowledging the feedback and why it was / was not implemented or the bad taste in the mouth of the user who has been duped from a request for feedback that has as a purpose a hidden agenda of "come on become an editor"? -- TRPoD aka The Red Pen of Doom17:47, 30 January 2013 (UTC)[reply]
Those would seem to be contradictory questions; we're either engaged in a conspiracy to deceive readers, or trying to promote useful feedback, not both (it's the latter, for avoidance of ambiguity). Yes, there was community drive for replacing AFT4 with actual feedback - I can provide diffs if you so wish - and yes, of course we wanted to work out ways to use the feedback to improve articles. Okeyes (WMF) (talk) 17:55, 30 January 2013 (UTC)[reply]
I didn't say there was no recruitment effort, I said it wasn't an attempt to deceive people; "give us feedback (we'll do nothing with) and start editing". The intention was always for feedback to be useful and to be used. Frankly, if we wanted to recruit people alone we'd just stick 'did you know you can edit? click here to find out how' at the top of every article. Okeyes (WMF) (talk) 19:00, 30 January 2013 (UTC)[reply]
and I didnt say there was no intent for anyone to ever act on the feedback provided. But the design and implementation of the tool has been at/for multiple cross purposes giving poor results for all of them. A tool for feedback would be designed to draw focused actionable feedback and get it to editors who want to make those improvements; a tool to collectively measure the quality that readers see in the articles would have a different features and ask and evaluate on a different scale; and a tool designed to encourage participation would have yet different features. This tool is apparently attempting to do all three and not doing any of them well/appropriately, hence my assessment that it seems that it was put out there based more on "everybody collects feedback, so we should too" rather than a thought out plan with a clearly identified specific goal to get actionable feedback to those who want and intend to use it ( and design specs to accomplish that goal). -- TRPoD aka The Red Pen of Doom20:03, 30 January 2013 (UTC)[reply]
(ec) This is related to the issue in my question on the main page. (And obviously there is no conspiracy, just unsuccessful efforts at communication.) When "feedback" meant "click some stars," nobody could possibly expect that to be the beginning of a back-and-forth editorial discussion. But when "feedback" turns into commenting, suddenly you've got people doing the kind of thing we expect them to do on talk pages -- but they're doing it in a way that is totally disconnected from talk pages, without even a clear path to talk page interaction. In hindsight, that was a really radical shift. I'm pretty sure that shift is the place where most of the community support began to erode. In my opinion, if it were messaged more clearly at the time, the resounding "NO" that seems to be resulting from this discussion would have come very quickly and clearly and with less effort expended on all sides. But, hindsight is always 20/20… -Pete (talk) 18:25, 30 January 2013 (UTC)[reply]
Pete, I appreciate this is your reason for rejecting the tool, but a brief trawl through the RfC comments shows quite clearly that a lot of people simply take issue with the quality of the feedback coming in. Okeyes (WMF) (talk) 19:00, 30 January 2013 (UTC)[reply]
Yes, fair enough -- there are objections that don't have anything to do with this. But there are also plenty of objections deriving from the kind of engagement the tool incentivizes, and how it connects to the existing collaboration model. -Pete (talk) 19:28, 30 January 2013 (UTC)[reply]
I rather strongly agree with Pete here - there was a quite dramatic change from one to the other that should have been cleared up then. Oh, well. I didn't say a lot about Pete's reason here in my comment because I thought it naturally followed from the concerns w/ quality of the feedback, etc. Perhaps that was just a mistake on my part, but I suspect other contributors felt the same way. – PhilosopherLet us reason together.20:17, 30 January 2013 (UTC)[reply]
I was happy to see Pete jump into this RFC and I've found his contributions very thoughtful and useful, particularly in extracting the Wikimedia Foundation's rationale for working on this tool. Some of this hadn't been (as) apparent to me. --MZMcBride (talk) 21:04, 30 January 2013 (UTC)[reply]
I think some people here are hammering particularly hard at this RfC because the community is operating at what feels like a power disadvantage compared to the WMF - many people remember WP:ACTRIAL and fear that - despite the many times we've been assured on this RfC that it won't happen - the WMF at any point could go "yoink!" and remove our agency in this decision. The thing is, if the WMF were to make that sort of bad-faith move (and I really don't think that they will in this case, given the explicit assurances we've gotten here not only from Okeyes but from Eloquence) they would simply go ahead and do it, no matter how utterly any anti-AFT arguments had vaporized the pro camp. There is nothing to be gained by being extra-mean, or extra-aggressive, or throwing in a bonus ad hominem with your view. The only thing that does is change this from a discussion/debate into a full-on argument, and that's not what we're here to do. So I would ask that anti-AFT commenters please remember that you're directing your words to real people who have put real man-hours into really trying to make a tool that would be great and useful; pro-AFT commenters, please remember that you're speaking to real people who have put a good-faith effort into evaluating the tool and are probably no happier than you to find that it's not working out as they'd like. No side of this debate is operating in bad faith, and it's unnecessary to the discussion to argue or imply that they are. A fluffernutter is a sandwich! (talk) 05:00, 31 January 2013 (UTC)[reply]
It would probably help if someone closed the straw poll, above. It was started 3 days ago and was supposed to run for 48 hours, and the clear consensus (60%) opposes the proposal. GregJackPBoomer!05:19, 31 January 2013 (UTC)[reply]
Procedural Objection: I challenge Nemo's claim to be "uninvolved", and I do not trust his ability to be an impartial and unbiased closer. Please note that this is not a claim that the closing itself was or was not justified. I would like someone who really is uninvolved to make that determination. --Guy Macon (talk) 19:08, 4 February 2013 (UTC)[reply]
Nemo is uninvolved to the extent that he did not participate in that specific vote. I agree that his view is not fully independent, but: it has been claimed above that the lack of closure was a contributing factor to heightening malaise. If we take GregJackP's assertion at face value, getting this closed was a high priority; and finding somebody that is truly, fully independent to take the time to absorb a complex, charged discussion and form an opinion about the consensus is a difficult task. If you would like somebody else to make a determination, how do you propose to go about recruiting somebody who is more independent? -Pete (talk) 19:39, 4 February 2013 (UTC)[reply]
I have always found that a polite request at ANI gets someone to close the RfC. My personal opinion is that closing it was obviously right, but I like having someone who is completely uninvolved and who we trust enough to be an administrator do the closing. That way whoever doesn't like the results has no valid cause to complain. Of course they complain anyway, and in those cases the admin almost always asks another admin to review the closing. --Guy Macon (talk) 22:09, 4 February 2013 (UTC)[reply]
Perhaps, but 61% to 35%, is almost 2 to 1, which is a clear consensus. See also Consensus decision-making where one of the methods talked about is by a "super majority" of 60%. Plus, the proposal was to implement additional changes in AFT, and with only 35% supporting, it clearly failed. GregJackPBoomer!22:57, 4 February 2013 (UTC)[reply]
I agree that everyone should be civil and respectful in this discussion (and in any discussion on this site). I haven't seen much that strays from this principle and if I had, I'd certainly be in line to call it out. In other words, I don't agree that the temperature is currently a problem. These RFCs are long (thirty days on the Internet is a long time) and it's already begun to dramatically wind down, as was to be expected. We'll only see another bump if a watchlist notice is employed, but I don't think that'll be necessary or warranted here.
Reading this section made me recall a comment I wrote on the RFC (paraphrased): If article feedback were as eloquent and thoughtful as the posts on this page, we wouldn't have any issue.
If you think there are particular edits or actions that are raising the temperature, please feel free to say so. As it is, I'm having difficulty seeing an issue currently. --MZMcBride (talk) 18:20, 31 January 2013 (UTC)[reply]
Sorry if I've missed something with all this "article feedback" stuff, but why can't users just use the talk page of the article(s) in question to report problems? πr2 (t • c) 20:17, 2 February 2013 (UTC)[reply]
A few reasons I have bothered to read are: Talk pages are hard for new users to edit, they can't edit talk pages without a real computer (iphones etc. don't work), and talk pages would fill with fluff like 'Nice boobs!'--Canoe1967 (talk) 20:31, 2 February 2013 (UTC)[reply]
Only a few articles have it now. I think this page is about expansion to all articles soon. It shows as an 'Editing Wikipedia' link at the top left of pages to the right of the puzzle globe.--Canoe1967 (talk) 21:10, 2 February 2013 (UTC)[reply]
Three reasons: (1) many readers wont realize that "talk" means a place to give feedback; (2) using the Talk page requires more button clicks (hence results in fewer readers giving feedback); (3) Readers that try to edit Talk page are presented with an intimidating warning "You are not logged in. Your IP address will be publicly visible if you make any edits. Please log in or sign up to have your edits associated with a user name, among other benefits.". --Noleander (talk) 04:00, 3 February 2013 (UTC)[reply]
It should be noted that your IP address is also given when you use the Article Feedback tool (unless you're logged in, obviously). Thank you for explaining it, though. Now I think I understand it a bit. πr2 (t • c) 14:32, 3 February 2013 (UTC)[reply]
the overall comment rate via this interface would be 20-70% of the total edit rate (and 2-6x the current talk-page comment rate).
roughly 10-70% of these comments are helpful, and another 10-30% have some small (perhaps redundant/universal "add photo of type X") value
most of these comments are from IPs (who might only leave one such comment); in contrast with talk pages which are mostly by logged-in editors
almost none of these commenters get personal feedback (talkpage messages or other alerts) when their feedback is acted upon
My casual analysis and summary of the analyses above:
even 20% nonsense can feel like a lot, which means less rewarding and less time-leverage for reviewers. (may be enhanced as long as the traditional curation tools only work with talkpages & this new stream of input is not made compatible with talkpages.)
there is a significant amount of useful new input within that new stream (comparable to today's useful talkpage input)
the useful input comes from a significant number of new people (readers who otherwise might not contribute).
the jury is still out on whether they come back and contribute again, particularly since the current design isn't set up to easily generate any feedback loop for them: dialogue, or a notification when their comment is acted on or responded to [or even a way to so respond]
analysis suggests these are not people whose attention is being drawn away from talk pages.
It seems to me there is a lot of low-hanging opportunities to improve on the current methods for commenting on pages, and also great potential for finding ways to target or channel interest in commenting in useful directions. This field of experimentation shouldn't be dropped, wherever the experiments happen. (I don't see a need to run experiments on huge swaths of articles at once: it's not clear to me what data one gets from 500k articles that isn't reasonably simulated by 500... other than data on the extent of community patience.)
It's good to see the depth of interest in articulating specific goals, and logging/visualizing/sharing data from trials. But an RfC, or even the talk pages of the feature description here & on mw.org, seem like poor ways to capture that energy. Requests in "talk-page debate" form tend to get lost; or responded to partially, in a thread, which is later hard to find and impossible to sort or order according to any sort of metadata. So, in the spirit of discussing good ways to capture, collate, aggregate feedback: we could use a better method for community eval/testing/feedback on features such as this. – SJ +08:36, 3 February 2013 (UTC)[reply]
Do "positive actions (helpful, featured)" include/overlap "resolved"? I don't know about the "significant amount of useful new input": it would seem that only a minuscule fraction of feedback (less than 4 %) was "resolved"/acted upon? Also, how do you compare to talk pages? I can agree on the "comparable" as in same order of magnitude, probably, but I lost the data on talk page editing you refer to.
Yes, I mean order of magnitude. Of course the format of the input interface encourages short comments more than the talk page does; so this tends towards specific requests, typo callouts, corrections, or aggregatable mini-requests (12 people ask for the following kinds of images). I don't think one should try comparing directly to the quality or impact of talk pages. As to resolution: I didn't see a clear way to note this when I acted on AFT items; wouldn't be surprised if this was rarely done.
Collating two slightly different points of yours: "dialogue, or a notification when their comment is acted on or responded to" is what talk pages are designed for, and Echo/Flow will apparently provide all with notifications for replies (I think everyone agrees this is useful); as for "hard to find and impossible to sort or order according to any sort of metadata", AFT could keep the metadata linked to a diff where the free-text is posted on the talk page, becoming a useful index of talk pages edits (including those "featured", "resolved" etc.) rather than the current obscure superstructure (or black box, even).
I like the idea of AFT providing an "easy way to add a comment" and adding new metadata, linked to talk-page additions.
Finally, on community evaluation etc. (this last paragraph got way longer than I wanted; skip it if bored.). AFT was born as a feature to monitor the improvements to Public Policy Initiative articles in a measurable, report-to-the-investor-like way; Pete and others have shown that even some attentive community members didn't understand the fundamental aims of the project, which perhaps evolved in an unclear way for those who have not yet understood the WMF mindset on this matter (mindset which makes sense to me, right or not). My small personal suggestion is always to start everything from real and concrete needs raising from the communities (note the plural, we have 800 wikis); and from the field-tested experiences and ideas they had in the past dozen years: sometimes genial, often crazy and completely broken, always very valuable. If the aim had been to collect "feedback", at least to me a few solid points would have been apparent: 1) we need a system to get reports of mistakes from people who want to "speak with the editor" and who currently either complain on newspapers (if powerful) or rant on the web (if common people); 2) we need more eyeballs on the long tail of articles nobody watches; 3) feedback works if sent to a place where it can be easily posted, refactored and acted upon, as (allegedly) proved by the feedback tool on Wiktionaries and so on. However, the aim has never been to collect feedback; perhaps renaming AFT as the ReaderEditingEngagement extension would have made conversation on the topic more productive, and questions like mine on the least disappointing aspects of the experiment would get some answers. ;-) As for the general problem, I'm not qualified to suggest anything on how "product" design discussion/decision should happen, but I hope that as Wikimedia we have, somewhere, someone who proves able to. --Nemo17:35, 3 February 2013 (UTC)[reply]
Renaming / splitting / separating distinct projects and aims is generally a good idea. You are right about things morphing over time without clear boundaries. As to your fine questions; you're inspiring me to do my own anecxperiment. – SJ +18:40, 3 February 2013 (UTC)[reply]
Lots of good stuff to read through here, unfortunately I can't get to it all today. But I want to note one detail: the history of AFT and the PPI isn't really as you say (though I understand why it might appear that way). Metrics around general engagement (as opposed to the engagement of specific groups of teachers and students) were not of particular interest to that project, nor to its primary funder. The Wikipedia Education Program – Metrics for evaluation page was developed more recently, but reflects the kinds of things we sought to measure in order to evaluate the PPI's success. You'll note that general engagement of readers is not on that list. -Pete (talk) 16:11, 4 February 2013 (UTC)[reply]
I'm not saying that AFT data was crucial in PPI project, it was just a small tile. But that small tile did have that perspective, and while not being important for PPI this has an influence on AFT. Of course my narration is a partial one (I was showing a point and didn't mean to write a complete history), but I don't think it's incorrect. Also, I'm not sure how initial a design you're referring to, but I attended the Berlin two-days education meeting in early March 2011 and my memory for such things is usually good enough, so I shouldn't be too wrong. --Nemo17:29, 4 February 2013 (UTC)[reply]
This is a topic that is complex and full of nuance, and perhaps not vital to determining the best path forward. Since we seem to be agreed that your initial summary wasn't complete (which to me is no big deal as long as it's noted here), I suggest we drop it in the interest of making way for more productive discussion. -Pete (talk) 19:42, 4 February 2013 (UTC)[reply]
I disagree with your assessment here, Nemo. This tool was intended to collect feedback, and always was; until fairly recently, tools to help improve article quality were considered to be supporting a key strategic goal of the WMF. As the strategic goals changed, suddenly it is now an editor engagement tool. Unfortunately, it's almost completely ineffective at drawing in new editors; indeed, the edit button on the top of the page, and the section edit buttons, are both significantly more effective. This tool is being repurposed for a function it was not designed to do, in order to meet a different WMF strategic objective and justify its continuing existence. Risker (talk) 16:15, 4 February 2013 (UTC)[reply]
Strategic goals have not changed in the last 3/4 years. I don't know what you mean with "was intended" and "always was", but as an autonomous project I stand my point that it never authentically was (PPI itself was meant as an "editor engagement tool" too, one could say). Means and aims are often muddled, sure. --Nemo17:29, 4 February 2013 (UTC)[reply]
Hello, everyone -- and thanks for your thoughtful comments about Article Feedback. Many of your good insights are invaluable to us and have already helped us improve this reader engagement tool.
I'm happy to say that we now have a new version of Article Feedback, which is ready for testing on our prototype site. This new version in based on recommendations from several participants to this discussion, as well as many community members on the English Wikipedia and other projects around the world.
We invite you to try out some of the new features described on this testing page, then share your thoughts on whether these improvements would make it more useful on the English Encyclopedia -- even if it's only for a limited deployment, as proposed here. We also plan to test these new tools on other sites such as the French and German Wikipedias, so your comments will benefit other communities as well.
Mockup of new moderation tools and filters under consideration.New moderation tools under review
This new version is expected to greatly reduce the editor workload by providing simpler moderation tools, as well as better filters to surface useful feedback and make the best comments more visible to editors. Here are some highlights of what's new in this version.
• Better feedback filters: surface good feedback, hide useless comments.
This feature automatically separates comments between 'Featured' and 'Unreviewed' filters, as well as other moderation queues. The 'featured' filter comments are shown by default and only list posts marked as 'useful' or 'helpful' by moderators. The 'unreviewed' tab lists all posts that have not yet been moderated. These separate filters surface the best feedback in the default view, and make it harder for a casual user to see feedback that has not yet been moderated. Editors can also access 'More filters' to view moderated comment queues such as 'resolved', 'no action needed' or 'inappropriate'.
• Simpler moderation tools for editors: moderating feedback is now a lot easier and faster for editors.
This feature helps editors moderate unreviewed comments more effectively, using four simple tools to mark comments as 'useful', 'resolved', 'no action needed' or 'inappropriate', with only one click. To make moderation faster, editors are no longer required to add a note for each moderation (but can do so by clicking on 'Add note'). Moderated feedback is then moved into the appropriate queue, which editors can view under 'More filters'. These moderation tools were developed with the active participation of community members, as described in this usability study.
• Separate reader moderation tools: encourages readers to moderate with their own tools.
This feature invites readers to participate in the moderating comments with their own tools (mark as helpful/unhelpful, flag as abuse), shown below each feedback post. These reader tools are now only shown to anonymous users (and new editors). We have removed these reader tools for editors, to simplify their choices, so they only have to focus on the more powerful editor moderation tools on the right.
• Feedback link on articles: shows up if there is useful feedback for your article.
This feature shows a small link below the article title, pointing editors to any posts featured by moderators. It aims to surface the best comments for editors, so they can use them to improve articles. (Many article editors are not even aware that there is feedback for their articles.)
Next week, we will add an auto-archive feature, which will automatically archive comments that have not been moderated after a while, to limit exposure to potentially inappropriate feedback. To learn more, check out this project update, or read the full details on new features under development.
Once these features have been fully tested and debugged on our prototype site, we expect to release them on multiple sites such as the French and German Wikipedias in March 2013. We hope that some of you will find this improved tool valuable for the English Wikipedia as well, and that Article Feedback can remain available in some form to the many editors who find it useful.
As I stated earlier in my view as product manager for this project, the Wikimedia Foundation will respect the community's decision regarding a full deployment of this tool on the English Wikipedia. But we recommend that this decision be based on the latest version of the tool, and that it take into account the broader question of how to best engage our readers to contribute to the growth of our movement.
Nowadays, most large information and journalism sites provide simple feedback tools to enable readers to easily communicate with editors; as a top 10 web site, Wikipedia also has a responsibility to provide a practical solution to the public we serve. While we appreciate suggestions that talk pages be used for reader feedback instead of this tool, they are very intimidating to new users, who rarely use them, and have very low traffic. It appears that Article Feedback addresses that need more effectively, even if it is used as an interim step towards a better solution down the line. For that reason, I recommend that the community consider a compromise solution, such as the one proposed here.
The above is definitely the direction that we should be going. I have one request: when this goes to articles for testing, could we make it so that the only feedback we see is the feedback entered after the new version is rolled out? In particular, if I run some statistics on how much is useful, I don't want to be concerned about feedback posted using previous versions or under previous abuse filters, especially on any pages that list "all feedback." Thanks! --Guy Macon (talk) 22:05, 15 February 2013 (UTC)[reply]
Guy, it's the weekend for workin'folk -- including Monday here in the states. (I agree though, if for some reason this does go live, an effort should be made to separate feedback from before and after.) However, Mzmcbride raised some substantive questions about whether the abuse filter approach even made sense, which I'm not sure have been addressed. I'm far from an expert on abuse filter, but from the discussion I saw here it seemed that there was a significant disconnect. -Pete (talk) 20:08, 17 February 2013 (UTC)[reply]
I have rather a lot of experience wrangling abuse filters. Mzmcbride identified some significant problems, but they appear to be things that have been solved before in different contexts. I am going to jump down and give this its own section, and this time I won't forget that not everyone has the care-free 80-hours-per-week lifestyle of a an engineering consultant... :( --Guy Macon (talk) 20:19, 17 February 2013 (UTC)[reply]
Hi Guy Macon and Pete, thanks for your thoughtful comments -- and sorry I couldn't respond sooner, due to the holiday here in the U.S. As Okeyes points out, we were planning to hide all unmoderated comments from last year before consulting the community about a wider deployment. It's unfortunate that this RfC took place before we could do this, as it gave everyone an inaccurate impression on the quality of the feedback. And as Guy points out above, most issues with the abuse filters can be improved with the same tools now available for article edits; this can either done by filter editors from the community, or by WMF; in either case, these issues do not appear unsurmountable, as others have suggested in this discussion. Fabrice Florin (WMF) (talk) 21:51, 19 February 2013 (UTC)[reply]
It seems like the approach this update has taken is to improve the experience for moderators of feedback. I appreciate that the tools for assessing feedback are now clearer but, respectfully, I think the focus should be on engineering the feedback form itself so that we get better feedback in the first place. Right now we have a yes or no button and exactly one field where a user can enter anything. We're not doing anything to (A) help users find answers to the most common queries or (B) help users understand that what we want is specific, actionable feedback about the article rather than about the subject of the article. There are a number of possible options for the form that might improve the quality of the feedback that we get. For instance, if the user says they aren't satisfied with the article we might have a few suggestions for action that they can take. If they think the language of the article is too complex we might refer them to simple english wikipedia. If they have a question about the subject of the article we might direct them to the reference desk. If they want to contact the subject of the author we might explain that wikipedia is not a directory. Perhaps we can use checkboxes so that users can select common requests, like pictures. In addition, the language in the free-form text box should be more specific about what we're looking for. We don't want to here "this article needs a picture" (the current suggestion). We want to here something like "there is a typo in the third sentence".GabrielF (talk) 22:15, 15 February 2013 (UTC)[reply]
Hi Gabriel, thanks for your good insights on how we might improve the feedback form. When I first joined this project in fall 2011, I mocked up this preliminary wireframe for an 'expanded feedback' form, which might address some of your suggestions. We did not pursue that approach right away, because we wanted to focus on getting the first part of the form done. But we would be open to investigating this idea again in future releases, if you think it's worth it. In the meantime, we will look into replacing "this article needs a picture" with something more specific, as you suggest. Fabrice Florin (WMF) (talk) 21:51, 19 February 2013 (UTC)[reply]
I appreciate the update and the description of what improvements are contained. The substance, though, only underscores what I've come to believe throughout this discussion: that the AFT (including the most recent update) results from a flawed analysis of what we have, what we want, and how to get there.
This stands out in particular:
"While we appreciate suggestions that talk pages be used for reader feedback instead of this tool, they are very intimidating to new users, who rarely use them, and have very low traffic."
This statement reflects an oversimplified understanding of a number of points that have been raised about talk pages and possibilities.
I don't think this tool has a useful future without a back-to-basics deliberation about its possibilities and purpose, and it's been made very clear the resources for that are not available. So I'm retracting my support for what's now referred to as the compromise solution. I'm not sure what purpose it would serve. -Pete (talk) 18:41, 17 February 2013 (UTC)[reply]
Hi Pete, I'm sorry that you found my statement about talk pages 'oversimplified.' To be fair, I was trying to keep my post short, so I only wrote one sentence on that point, which might explain why you found it lacking. The fact remains that talk pages in their current form do not seem to provide the simple solution which I believe is needed to engage Wikipedia readers. We would be happy to improve the talk pages to better address this public need, and many of the ideas suggested in this discussion could prove useful to that end; but we do not expect to do take on such a major new project this year, due to other commitments. So it's unlikely that a practical solution would be available for at least another year, which is why I recommend a temporary compromise, so we can continue to provide a usable reader feedback tool, even in limited form. With that in mind, I'm not sure if retracting your support for such a compromise will help improve the current status quo, which will continue to make it hard for readers to participate on Wikipedia. Fabrice Florin (WMF) (talk) 21:51, 19 February 2013 (UTC)[reply]
Just to be clear, hiding the old feedback will be of no use if the hidden feedback is included in the results of any tools that return a list of all feedback, all feedback for a particular article, etc. I want to run various statistics on just the feedback entered under the latest version of the tool and filtered by the latest version of the abuse filters. Ideally, someone at WMF or here an en-wikipedia would create a template that would do most of the work. Something like {{subst:AFTest|Article/All|Start date|End date|Number of Random samples|All/Hidden/Resolved/Open/AbuseFlagged}} that would generate a table with a random selection of feedbacks (clickable so you can see each one), all ready for additional analysis. (Technical question: is there a random function in our wikimarkup/template language?) --Guy Macon (talk) 22:39, 19 February 2013 (UTC)[reply]
Hi Guy, if the community decides to remove this tool from the English Wikipedia, we plan to save the feedback data collected so far into a file, so that further research could be done with it. We will aim to store it in a format like SQL, so that you could do the queries you propose above. In the meantime, you can get some useful data from this feedback moderation dashboard and this feedback volume dashboard. Note however, that we have not yet deployed the new version of the tool on the English Wikipedia, so a better place to collect data based on the new tool would be on the German or French Wikipedia, after we deploy the new features on those sites in March. Fabrice Florin (WMF) (talk) 22:22, 20 February 2013 (UTC)[reply]
Update 1: Before this discussion closes, I also wanted to point out that we are considering a couple final features for this release of Article Feedback, which can help address some of of the issues raised in this RfC: better integration with talk pages, and useful feedback notifications (through Echo):
• Discuss on talk page: share useful feedback with editors on talk page.
This Article Feedback feature would make it easy to promote a feedback post to the article talk page, so that editors can discuss it in the same place where they already have conversations about article improvements. To that end, we propose to add a 'Discuss on talk page' link in the menu editors see after a feedback post is marked as useful with the new tools, as shown in this first mockup. This feature proposal also includes a 'Contact this user' link to the user's talk page, to encourage interactions with readers, even if their feedback is not deemed useful. We are now considering implementing this feature in the first release, since it seems easy to do from a development standpoint and is a very frequent request we've heard over and over again from different communities (English, French and German Wikipedias). This would be the first step towards a talk page integration that could be continued in future releases.
• Featured feedback notification - Editors: let editors know when useful feedback is featured for their pages.
This Echo feature would automatically send a notification to page creators when feedback is found useful for pages they started. The purpose of this feature is to make creators aware that other editors found useful feedback for their pages, so they can use these reader suggestions to improve these articles.
• Featured feedback notification - Readers: let readers know when their feedback is found useful.
This Echo feature would automatically send a notification to registered users when feedback they posted is featured (e.g.: marked as useful by editors and/or marked as helpful by readers). The purpose of this feature is to give positive reinforcement to users who make productive contributions to Wikipedia, to encourage them to participate more actively.
To sum up, we expect that the combination of all these new features can significantly improve the first wide release of Article Feedback v5 -- and address many of the issues that have been raised so far. As for future releases, more features are under consideration to increase the tool's usefulness over time.
The "discuss on talk page" feature seems like a step in the right direction, and I'm very glad to see it implemented. The core functionality is great to have; I think there are still open questions to explore around how it would be implemented. IMO a reasonable way to implement or further test AFT would be to use it on an opt-in basis, with publish-to-talk-page enabled in every case. It could be turned on for low traffic articles, turned off for any article where it results in too much noise/vandalism. This would eliminate the need to moderate an extra queue (for experienced users), and eliminate the fragmentation of where comments go for new users, making it more possible for them to return later and see their own comments and any response. At any rate, thanks for developing that feature and noting it here. Hopefully there is an opportunity to discuss implementation sometime down the road. -Pete (talk) 04:53, 25 February 2013 (UTC)[reply]
Actually the "feedback2talk" feature was developed as a userscript (de:Benutzer:Se4598/js/AFT_FeedbackToTalk.js) by german user Se4598 more than 2 months ago. It's really great, but it certainly doesn't fix fundamental issues of AFT like abundant noise. And it is unclear to me, how the feedback giver will learn about the move to the talk page, where his further participation would be welcome, obviously. --Atlasowa (talk) 14:18, 25 February 2013 (UTC)[reply]
Hi Pete and Atlasowa, thanks for your comments about this proposed new feature! Pete, we would be open to the opt-in solution you recommend above, and would be glad to consult with you and other community members to tweak it, once a first version is available. Atlasowa, you are correct that this idea was first implemented as a user script from a German contributor (we couldn't use the script in its current form, but can adapt it as part of the AFT extension); You are also correct that that particular feature doesn't solve the 'abundant noise' of AFT, which the new 'auto-archive' feature just announced below solves more effectively. As far as letting users know that their feedback has been featured and/or promoted to the talk page, we propose to use our new Echo notifications project, as described in the 'Featured feedback notification for readers' specification above. Fabrice Florin (WMF) (talk) 22:08, 25 February 2013 (UTC)[reply]
Actually the new Simpler moderation tools will in part make moderation more difficult. The update concentrates on the problems of enWP, too little moderation activities, and "To speed up the moderation process, we propose to no longer display a flyout for adding a note each time you click on one of the moderation tools (e.g. 'Done'). Instead, the moderation action would take place as soon as you click on the link, with the option to add a note afterwards, if you like" and further: "To further simplify the moderation tools, we propose to remove the 'View activity' tool in the default view of the feedback page. Since this 'View activity' option is already available in the 'details' permalink page, it is not essential to show it here, as it distracts editors from the main moderation process." So basically this discourages editors to give a note about their moderation action (you would need to click an extra button to give a note, after the fact) and it makes it very difficult to read those moderation notes of other editors, if they wrote one (you would need to click the 'details' button to get to the 'details' permalink page and to click on 'View activity' there). I doubt that many people find the notes there - if any editor still cares to give notes. But these notes are very useful: If the feedback says the article contains no information on what the mammal eats and where it lives, it is good to know that another editor checked and actually found the information in the article section 2 (this happens a lot, readers don't actually read... not even the intro...). On german WP, we have a lot of moderation activity and some editors are clicking 'resolved' very fast ("i personally don't think this mammal needs a second picture, resolved") and even 'abuse' ("doesn't help me edit=abuse"). The moderation notes actually help improve moderation, by making moderation transparent and by giving examples to other moderators. And giving feedback on feedback to readers too. Moderation notes are useful (just as 'edit summaries' are) and should be encouraged. --Atlasowa (talk) 14:18, 25 February 2013 (UTC)[reply]
Atlasowa, I don't understand why you think that the new moderation tools would be more difficult. This usability study suggests that an editor can go through a queue of unreviewed feedback a lot faster if they only have to click once and don't have to write a note each time. Editors are still invited to write a note if they have the time and interest, but are no longer required to. In the previous version of the software, we observed that this requirement was slowing down the moderation process, and that few people took the time to read these notes in the activity log (which you would still be able to access in the new version). We recommend a less time-consuming moderation workflow for comments than for edits, because we do not believe that comments are as important as edits, which have more lasting value. That said, it may be possible to require notes on Wikiprojects where the community prefers to encourage notes, rather than reducing the moderation workload. Fabrice Florin (WMF) (talk) 22:08, 25 February 2013 (UTC)[reply]
Fabrice, if we want a "less time-consuming moderation workflow" then maybe editors shouldn't even look at the article that the feedback was posted on - because that is time-consuming. Or maybe we shouldn't even ask for feedback that we can't handle. Presently, we are encouraged to write 'notes', but not required: you can skip the note. To give an example, if I see a feedback "this article needs a picture" I look at the article: does it already have dozens of pictures? Would a picture of the cartoon character evidently be a copyright violation? If I click 'resolved', i 'note' the result of those questions. If i don't, then the reader sees 'resolved', but there are still no pictures, so the feedback is repeated, often in a less polite manner - is this how we value feedback, how we turn readers into editors? (On german WP, we want to enable readers/feedback givers to 'view activity'.) And my note is also for other editors: I checked the article and the feedback is wrong, or based on this feedback i added a wikilink to the article etc. You are right, writing a moderation note is not without effort. But without it, moderation becomes meaningless, random, frustrating, redundant. For comparison: If I revert talk page contributions without edit comment, that would be bad, a breach of etiquette - but feedback is less important, so it's OK? According to the 2011 editor survey, the most frustrating on Wikipedia is to have other editors look down on you, to have your edits reverted without an explanation and to have your articles deleted - how about the readers, whose feedback is ignored and "deleted" "by Wikipedia"? Aren't we burning potential new editors? Agreed, a lot of feedback is just random, meaningless noise - but is it a good strategy to react with random, unexplained feedback moderation? Maybe we just shouldn't ask for feedback that we can't handle. --Atlasowa (talk) 11:36, 26 February 2013 (UTC)[reply]
Hi Atlasowa, you make an excellent point that adding a note makes moderation actions much more meaningful. We encourage moderators to take the time to write such notes for feedback that warrants it, for all the good reasons you suggest above. However, I am not sure that it is worth it to add a note for a large number of comments where no action is needed (unclear, nonsense, praise, duplicate) or even for random swear words. Either way, it's up to the individual moderator to make that call, and the tool is available for moderators to add a note any time they want. Thanks as well for letting us know that you would like everyone on the German Wikipedia to be able to view moderation activity, including readers. Since it's just a permission change, it should be pretty easy for us to implement that request, if there is consensus that it's needed. Fabrice Florin (WMF) (talk) 03:03, 28 February 2013 (UTC)[reply]
Update 2: I am happy to say that we have developed one more important feature to address some of the issues raised in this RfC: auto-archiving of unreviewed comments, as summarized below.
• Auto-archive comments: remove comments that are not moderated after a while.
This feature aims to reduce the moderation workload by automatically archiving comments that have not been reviewed after a period of time. By removing old comments from the 'Unreviewed' list, it gives editors fewer comments to moderate at any given time. But it still offers a special 'Archived' filter for editors who want to check auto-archived comments to see if any of them could be useful. The period of time before a post is archived would vary with the page's overall volume of unreviewed comments. For example, on the controversial Barack Obama page which can quickly collect up to a hundred unreviewed comments, these comments would be automatically archived after a couple days; but for a new page with just a few comments, we would only archive posts once a year.
We invite you to try out this new feature, along with all the others on this testing page. Together, these new features address many of the concerns we have heard on this RfC. It appears that only a few of the people commenting on this RfC have tested these new features, which seems unfortunate, given that the new Article Feedback software is now significantly different from the old software which most votes are based on. Fabrice Florin (WMF) (talk) 22:08, 25 February 2013 (UTC)[reply]
So comments which had not been moderated would be removed from front-and-center viewing but would still be available for any users to see if they chose? I can see why you implemented this, but I'm coming at the feedback issue almost entirely from a position of "someone who deals with cleaning up the worst of the worst feedback" (so, YMMV) and I don't think this actually addresses the issues of throughput and (really) bad feedback that are relevant to that. "After X time, we'll take the feedback that might be bad and put it in this other basket here, where it won't get much attention but will still be around, so we're still liable for hosting it and people could still find it" doesn't seem like the best solution to either "there's too much feedback to handle" or to "the feedback has to be patrolled at some point for legal/safety issues". A fluffernutter is a sandwich! (talk) 22:19, 25 February 2013 (UTC)[reply]
Hi Fluffernutter, thanks for your good observations about the Auto-archive feature. Rest assured that all feedback which has been auto-archived is no longer accessible to the public, so any potential legal risk is greatly reduced, as only editors can see them (about 0.3% of total visitors to En-wiki). I also want to take this opportunity to thank you and all the volunteers who have taken the time to clean up the worst of the feedback during our test. I appreciate this is not a fun task, as I found out myself during my own testing. Which is why we have worked very hard to reduce that workload in a variety of ways, and I believe that we have made good progress towards that goal. In addition to the features above, we added special features for oversighters, such as this warning and checklist to throttle oversight requests -- and we also moved the Request oversight link after a post is marked as inappropriate. We estimate that the combination of these two changes alone could reduce the number of oversight requests down to a fourth of what it was last year. I would also like to note that a total of about 630 oversight-related actions took place last year, out of nearly a million posts (including 400 posts oversighted and 230 oversight requests declined). While we appreciate that moderating 600 posts is an inconvenience, it only represents a couple days of work at most for the entire year. And we expect that workload to reduce even more, now that all these new features are available. So one could make a reasonable argument that a few extra days of work per year may be a small price to pay for giving readers a voice on Wikipedia. Respectfully, Fabrice Florin (WMF) (talk) 03:03, 28 February 2013 (UTC)[reply]
Update 3: I am happy to say that we have now completed yet another important feature requested in this RfC: 'Discuss on talk page', as summarized below and on this testing page.
• Discuss on talk page: share useful feedback with editors on talk page.
This feature makes it easy to promote a useful feedback post to the article talk page, so that editors can discuss it in the same place where they already have conversations about article improvements. To test this feature on this prototype site, first log in as test-editor, then click on the 'Discuss on talk page' link for any feedback post that has been marked as useful (it's shown to editors only in the moderation tool panel on the right of the feedback page, as shown in this first mockup). Note that you may not be able to save your post to the talk page on this prototype site today, but we expect to fix that site problem shortly; for now, you can view an example here. This feature is intended as the first step towards a tighter talk page integration that could be continued in future releases (next, we plan to add a 'Contact this user' link for feedback that is not deemed useful, linking to the user page of the reader who posted the comment). Fabrice Florin (WMF) (talk) 03:03, 28 February 2013 (UTC)[reply]
Perhaps this no longer occurs in the new version of this clearly rejected tool, but one thing among many that bothers me are "helpful" feedbacks which have as action: "Marked as helpful by Article Feedback V5". Is this some automated "marked as helpful" tool? Or is this an action by a specific editor that isn't logged to his account for some reason? Or something else? Something like this or this is not "helpful", and it certainly is not for some automated process to decide this. Fram (talk) 13:33, 19 February 2013 (UTC)[reply]
If you click on "View more actions" you'll see who actually rated the comment. In these cases both were rated "helpful" by 202.142.141.146, who's also been busy elsewhere on Wikipedia this month vandalizing articles with edits like this Brilliant. Voceditenore (talk) 14:18, 19 February 2013 (UTC)[reply]
Ah, so a Aftv5 bug plus a "helpful" user, making the feedback even less useful than usual. Thanks. On this one, I don't seem to be able to view who hides behind the Article Feedback V5 monicker. Perhaps because it is too old (3 weeks)? Fram (talk) 14:33, 19 February 2013 (UTC)[reply]
I notice that post says "Written by an anonymous user using feedback form 6X", whatever that is. That might account for it, although I haven't got a clue how. Voceditenore (talk) 15:16, 19 February 2013 (UTC)[reply]
Vandal abusing article feedback? No problem! Let me just revert the vandalism... Oh. Wait.Struck out because it was based upon experience with older version. Sorry about that. --Guy Macon (talk) 22:44, 19 February 2013 (UTC)[reply]
This is a known, and corrected, bug. For reference, Vandals abusing article feedback can be reverted; there's a 'void flags' button for a reason :). I'd note that I ran an analysis of all feedback actions which featured one anonymous and one logged-in user and found they agreed the majority of the time. Okeyes (WMF) (talk) 23:17, 19 February 2013 (UTC)[reply]
Indeed. I thought it had already been corrected (in fact, I'm sure of it) but something seems to have gone wrong with that patch. Sigh; I'll give people ye old hairy eyeball. Okeyes (WMF) (talk) 12:12, 20 February 2013 (UTC)[reply]
Hi. In this edit, I filed a request for closure of this RFC. It looks like there's a bit of backlog there and this discussion is massive, so it may take a bit for someone to come along and close this. I'll add a note to the top of the subject-space page mentioning the closure request, but I suppose there's no harm in discussion continuing until someone uninvolved has time/inclination to do the deed. --MZMcBride (talk) 08:27, 21 February 2013 (UTC)[reply]
Hi. The discussion has been closed by Geni (thank you, Geni!). I've gone ahead and filed bugzilla:45538, which I believe appropriately reflects the consensus found here. If anyone disagrees, please comment on the bug or below. --MZMcBride (talk) 04:14, 28 February 2013 (UTC)[reply]
Thanks, Geni, for closing this discussion -- I am glad that a compromise was reached so that editors who wish to use the article feedback tool can continue to do so on the English Wikipedia. Thanks as well to MZMcBride for filing the Bugzilla ticket for us. :)
As requested, we plan to make these revisions today on the English Wikipedia:
disable AFT4 feedback tool
disable feedback tool on AFT5 'lottery' articles
switch AFT5 to 'opt-in' mode (using the 'Article Feedback 5' category)
This will remove Article feedback tools from most of the articles on the English Wikipedia, as requested in the RfC closure statement. If you wish to enable AFT5 on articles you watch, you can simply add this special 'Category:Article_Feedback_5' to these articles -- and the feedback form will automatically appear at the bottom of these pages. Editors who add AFT5 are encouraged to moderate feedback periodically for those articles (using the reader feedback link at the top of their article talk pages). To learn more about our next steps about Article Feedback, check this updated 2013 release plan.
I would like to take this opportunity to personally thank all editors who contributed to this discussion. We learned a lot from your recommendations, and this will help us improve not only Article Feedback, but other editor tools as well. Okeyes will post more information on that topic shortly. Sincerely, Fabrice Florin (WMF) (talk) 18:30, 5 March 2013 (UTC)[reply]
Update: As requested, we just disabled AFT4 and AFT5 'lottery' articles on the English Wikipedia today. To enable AFT5 for articles which you are working on, simply add 'Category:Article_Feedback_5' on these pages, as described above. Please let us know if you have any questions about these changes. Fabrice Florin (WMF) (talk) 19:39, 5 March 2013 (UTC)[reply]
Does the tool not work on disambiguation pages? I'd have thought they're the best place to put a feedback form so that readers can suggest new terms for disambiguation, and several editors had asked for it at the RfC. But I've placed one at Big and it doesn't show anything. Diego (talk) 22:41, 5 March 2013 (UTC)[reply]
It doesn't at the moment, although if we are moving to the categories system I'm sure it would be trivial to add them (if people are willing to maintain the feedback pages). On the two categories point: originally we were using AFT5 for scientific testing to work out what version of the feedback form worked the best, and so we needed a controlled sample that wouldn't change. People who also wanted AFT5 on their article put it in 'additional articles' instead. I imagine we will transition to just using one category when the changeover and new deployments happen. Okeyes (WMF) (talk) 23:35, 6 March 2013 (UTC)[reply]
Sorry for the delay in posting this, guys; travel and work combined has been crazy this week.
Thank you to everyone who participated in the RfC, regardless of which way you voted. We are grateful for the amount of time people spent giving us feedback on its features, advantages and disadvantages; as volunteers, giving up this much of your time to talk to us is not a trivial thing. We continue to believe that an article feedback tool is a theoretical net gain, and hope that the 'opt-in' deployment we have compromised at will give people the benefits of AFT5 without many associated costs. If you want to have AFT5 deployed on an article you watch, simply add Category:Article Feedback 5 to the page and the tool will automatically appear.
In the meantime, we are busy planning deployments for many other Wikimedia projects where the communities have reached consensus in favour of the tool, including trial runs on the German, French and Hungarian projects - you can look at our deployments plan here. If you are aware of other wikis where AFT5 might be useful or appreciated, please drop a note on my talkpage so that we can discuss it, seek local consensus and investigate deployment options.
If you are interested in the other software we are currently building, you can sign up to the engagement mailing list. Our next project on enwiki will be Echo, a new notifications system. We hope you will give us feedback on it, as well; a lot of the discussions we've had about AFT5 have informed the things we're looking at for Echo as well as Flow :). Okeyes (WMF) (talk) 19:22, 8 March 2013 (UTC)[reply]
Readers Survey 2011: Reasons for not editing
Measuring Article Quality (AFT4). Protonk, Wikimania 2012 presentation, video (30 min) (Article feedback/Research)
AFT5 2012-Q4 report. Dario Taraborelli, December 2012
