Talk:Article feedback/Version 5/Testing

Welcome to our testing discussion page for the Article Feedback v5 project!

If you have any general questions or suggestions about this release of Article Feedback, you are welcome to post a comment on this discussion page. We will respond as soon as we can.

To report a bug, please post it here on Bugzilla.

Pressing enter still does not work
--TMg 17:40, 15 February 2013 (UTC)
 * When I enter a comment ("add note") and I press enter the page reloads and my comment is not saved. I'm pretty sure this way mentioned before. My current browser is Opera.
 * The question mark in the "Activity Log" does nothing. Please remove it.
 * Why can I click "no reason given"? I can not provide a reason there. It is just another link to the activity log. Why do we need multiple links for that?
 * The link in "Marked as resolved by 31.212.178.10" in the right column leads to the non-existing user page. In most cases such links lead to the contributions page for that unregistered user.
 * "no reason given": If you can add a note there should be a link "Add note" next to it. If theres a note "Read note" will be displayed.--Se4598 (talk) 22:32, 15 February 2013 (UTC)
 * Good point. We plan to remove "no reason given" altogether, as you suggest. Fabrice Florin (WMF) (talk) 22:58, 20 February 2013 (UTC)
 * "Marked as resolved by 31.212.178.10": Only registered users can resolve/mark useful/... feedback. But because feedback was imported from enwiki and the users didn't exist in this installation, Mediawiki displays the associated IP-adress. So normally IPs will never be appear in the messages, only registered Users--Se4598 (talk) 22:32, 15 February 2013 (UTC)
 * Se4595 is right, this is a temporary artifact caused by the import of comments from En-wiki, for testing purposes. Fabrice Florin (WMF) (talk) 22:58, 20 February 2013 (UTC)


 * Thanks, TMg, for testing the tool and posting your comments here -- and many thanks to Se4598 for answering some of TMG's questions! I have responded to some of these comments, both above and below.
 * • Pressing 'Enter' doesn't work when I add a note: Good point, which I have reported to our developer. Thanks!
 * • Question mark in "Activity Log" doesn't work: Duly noted. We'll remove it as you suggest.
 * Much appreciated! Fabrice Florin (WMF) (talk) 22:58, 20 February 2013 (UTC)

Hiding feedback without oversight?
Previously hidden feedback was hidden for editors. Now there only the inappropriate-option and the post will be still visible to editors. How administrators should deal with feedback that should be hidden for most users but is not serious enough to be normally oversighted? for example en:WP:Article Feedback/Feedback response guidelines H1, H4, H5--se4598 (talk) 22:43, 15 February 2013 (UTC)


 * Thanks for bringing this up, Se4598!
 * To broaden the pool of moderators, the new 'Inappropriate' tool is now available to all editors, and we do not think there is a need for a separate 'hidden' category, besides this 'inappropriate' category. The rationale is that there is such a large amount of 'inappropriate' feedback that it would overwhelm monitors if they were the sole gatekeeper for this tool. We'd like to keep it that way, but are asking other colleagues and community members for their thoughts on this point.


 * We would also like to remove the gray mask that used to be shown over 'hidden' posts -- now called 'inappropriate' posts. It's unnecessary in our view, because a) readers can't see inappropriate posts and b) there is little risk of editors being exposed to this content inadvertently, since they have to click on 'More filters', then select 'Inappropriate' to see it; moreover, if an editor explicitly asks for inappropriate feedback to be displayed (by selecting the "Inappropriate" filter), then they would reasonably expect to see the inappropriate comments without any masks. Forcing you to click on every single post to see its contents is a bad user interface in our view, because it breaks the workflow for editors who want to check if "inappropriate" feedback was improperly classified (which can be done by skimming the list if the content is visible). This gray mask had initially been requested to be more consistent with the 'rev/del' practice used on English Wikipedia. But we don't think it's as relevant for the new tools in the context of reducing the editor workload, and may not matter so much to the international wikis that are actually planning to use the tool. From a user experience standpoint, fewer clicks will significantly reduce the editor workload, which is our main priority at this point.


 * With all this in mind, we have updated this access and permission matrix of user rights for Article Feedback, to reflect our latest developments. Is this updated access table accurate, as far as you are concerned? Do you have any questions about it?


 * All things considered, do you think that your community would be comfortable with this proposal? We are asking others as well, so we can all compare notes on this issue.


 * Thanks again for all your invaluable help in getting this tool ready for wider deployment. It's very much appreciated! Fabrice Florin (WMF) (talk) 00:51, 21 February 2013 (UTC)
 * I agree, overall it's a good decision but you haven't answered my question: How administrators should deal with feedback that should be hidden for most users but is not serious enough to be normally oversighted? In my opinion It can't be oversighted because it would be in conflict with the Oversight policy but also it shouldn't be visible to editors. So admins are missing their Revision deletion-tool. It's a conflict with the OS-policy if they hide feedback that matches the actual 'hidden'-criteria (see en:WP:OS point #4 and #5 and note: These cases shouldn't be used any longer because of rev/del). The previous behavior of 'hidden' was rev/del but thats no longer the case. Thats the point. Maybe you should contact the enwiki-oversighter first to discuss it with them or implement the previous behavior for hide. Overall I think it is right to give users a option to handle vandalism but not by removing admin tools (for en:WP:Article Feedback/Feedback response guidelines H1, H4, H5).--se4598 (talk) 16:01, 21 February 2013 (UTC)


 * The Germans are using a different OS-policy (the one on Meta - which has a narrower scope than the one on the English Wikipedia - but I agree that the area between oversight-able material and "transparent to all (editors)" is an issue that has to be addressed.
 * In a broader context: WMF legal is on record insisting (in short) that matured communities can't simply co-opt Administrators without proper process, because broadening the number of users - able to access legally sensitive material - carelessly could potentially increase liability risks. It strikes me that the planned (de.wp-)design of the tool
 * a) might qualify in several respects as doing just that indirectly (and unintentionally) by creating a novel administrative field without the tools necessary to take care of it
 * b) can't be fixed through "reasonable expectation" to being exposed to such material on the side of the non-administrative community-member, because it is not an sufficient argument (and it would surely also apply to co-opted administrators). The argument applying to co-opted administrators, in turn, strikes me pretty much as also applying to non-administrative community members supposed to review and mark the same material, regards --Jan eissfeldt (talk) 10:34, 22 February 2013 (UTC)


 * Hello se4598 and Jan eissfeldt, thanks for your thoughtful recommendations, which we have discussed with our team. You make some very logical points that the current tools would deprive administrators from a function which they need. On that basis, we propose to restore 'Hide this post' as a separate function from 'Mark as inappropriate', as described in this new feature requirement.


 * This 'Hide this post' text link would appear in the second moderation panel that is shown after a post has been marked as inappropriate, and would only be visible to monitors (administrators, rollbackers or reviewers) and oversighters. Clicking on 'Hide this post' would display a gray mask over that post, which would make it impossible for anyone but a monitor or oversighter to see the contents of that post. Monitors or oversighters would be able to click on that gray mask to reveal its contents -- as well as an 'Un-hide this post' text link, which would revert the previous action and reveal the post again.


 * This would provide administrators with the equivalent of a Revision deletion-tool, to remove from public view feedback that should be hidden for most users but that is not serious enough to be oversighted, as you requested. If the German Wikipedia wishes to restrict this feature to only administrators (leaving out rollbackers or reviewers), this could be easily done with a local configuration setting for monitor rights.


 * Would this work for you? In the interest of time, we would like to implement that feature right away, so we could have it in time for next week's deployment. Please keep in mind that new feature development has ended for this project, so we're squeezing this in at the last minute, but will not be able to do more than bug fixes and small tweaks going forward.


 * Thanks again for your good insights and understanding! Fabrice Florin (WMF) (talk) 02:55, 7 March 2013 (UTC)


 * Correct me if I'm wrong, but isn't this feature working exactly like you describe it above in the current version on dewiki? At least I have been hiding quite a few comments already. There hasn't been a big discussion about a hiding policy yet, but I handle it currently similarly to the revdel feature for articles. There are quite some cases where we hide revisions on dewiki that are not within the OS policy but are deleted for other reasons anyway, such as copyvios or illegal statements accoring to german law (i.e racistic comments)--PaterMcFly (talk) 16:49, 7 March 2013 (UTC)


 * Hello PaterMcFly, you are absolutely correct that the 'Hide this post' feature currently works as described on both English and German Wikipedia. However, we plan to deploy new moderation tools next week, and we had considered removing that feature at that time, because it is so similar to the 'Mark as inappropriate' tool. Thanks to this discussion, we now plan to keep it after all. While this introduces a bit more complexity in the user interface, it is limited only to posts marked as inappropriate and only to monitors, while filling an important gap, so I think this is the right decision. Thanks again to se4598 and Jan eissfeldt for pointing out the issues that this would have created! All the best. Fabrice Florin (WMF) (talk) 17:31, 7 March 2013 (UTC)

Still a lot broken in the current labs build
I'm not sure if all the previously reported bugs are fixed in the current labs build. However, here are some oddities I found while testing at labs today: Don't get me wrong, it's not all bad. I'm simply focusing on the oddities. For example I like the new "View more actions...". I'm not sure but I think the previous version used a popup. The new version is much better. --TMg 14:11, 8 March 2013 (UTC)
 * 1) I was not logged in and wrote a comment. I can see my comment at http://ee-prototype.wmflabs.org/wiki/Special:ArticleFeedbackv5/Main_Page. But the numbers are odd.
 * 2) "0 featured comments (of 13)". Why 13? There is only 1 comment.
 * 3) "77% found what they were looking for". This does not make any sense no matter what numbers you use. 0 of 13? 1 of 13?
 * 4) Now I login as "test-editor". The numbers do not change and are therefor still confusing. But at least I got a filter dropdown with a little more to do.
 * 5) It tells me I "cannot review your own posts". I know it uses a cookie. However this feels strange. Like my IP adress is stored in the database besides my username. I know it is not. Warning: Some users consider this a tracking cookie. They will refuse the tool because of that. Also it's way to easy to fake votes. All I have to do is to delete the cookie. Even if I'm logged in.
 * 6) The possibility to "Sort by" should completely disapear if there is only a single comment. At least disabled. But I prefer to make things invisible if there is nothing I can do with it.
 * 7) I choose the filter "Helpful (1)" and yes, it displays 1 comment. But it is not marked as helpful. It is marked as non-actionable. Bug?
 * 8) All empty feedback is blocked because of a filter "Extremely short post". This is extremely confusing because there is a button to "Post without a comment". Because of the filter the button is not only useless, it is frustrating. I'm not sure if this can be ignored because it is an odd test in the labs or if it is a bug that needs to be solved (solution: hide the button if such a filter exists).
 * Wow, this is strange. I tried to unarchive this post: http://ee-prototype.wmflabs.org/wiki/Special:ArticleFeedbackv5/Main_Page/697676f02877de9ad6f59958389022f3. It worked but one minute later a user called "Article Feedback V5" (which is neither a user nor a bot) undid my action and archived the post again. The bug is: Why is there a button to "Undo archive" if this action is blocked by the tool a few seconds later? I guess this happens because the post is marked as "inappropriate". If this is true then there needs to be a button "Undo mark as inappropriate" or "Undo archive and remove all markings". Not "Undo archive".
 * 1) This auto-archive stuff also disturbs some user actions. For example I clicked "Unmark as useful" on a random post at the central feedback page. I waited a little bit. It got auto-archived in the background. I could not see this but now I know this is what happens. 30 seconds later I tried to mark it as "Useful". My click got ignored. Nothing happened. I tried to click "Resolved" or anything else. Nothing works. This is very easy to reproduce. There should be at least an "out of sync" error message.
 * 2) There is still to much garbage at the detail page. Sorry. It's not bad but it's possible to make it better by removing more unneeded stuff.
 * 3) "(#697676f02877de9ad6f59958389022f3)". This is like displaying the page ID number in the Wikipedia projects. Remove it. It's in the adress bar of the browser. Thats enough.
 * 4) "using feedback form 6X". I guess this is intended because there are multiple versions of the tool used side by side. Please remove this in the final version. It does not add anything to the comment.


 * Thank you, TMg, for taking the time to test the Article Feedback tool so thoroughly! We will go through the issues you reported and address the most important ones first, such as the number discrepancies noted at the top. As far as the auto-archive issue is concerned, it's due to the fact that on this test site we are archiving comments much faster than we will on production. Note that even if these issues are not solved in the first release, we will aim to address all critical bugs in coming weeks. Please be patient with us, as we have a lot on our plate getting this first test release out the door. :) Fabrice Florin (talk) 20:18, 12 March 2013 (UTC)
 * OK, thanks. I know archiving is much faster in the test wiki than it will be in production. But the issues remain the same. Why does it act like a bot? It's not a registered user. I can not see it's contributions log, for example. Why is it even necessary to mark archived posts in the database? Why is it necessary to distinguish between "resolved" and "archived" posts? What's the point if I can't even undo this? Why not simply make this a rule in the filters? (Like "show unreviewed posts that aren't older than 3 months".) I was so happy that you finally dropped some of the confusing duplicate flags. Why do you introduce a new duplicate flag the same time you drop others?


 * What if an article is edited very seldom, let's say once in two years. On the other hand you have articles that are edited every day. What auto-archive rule do you use? For the first article it will be bad to archive possible useful posts to early. But you need to archive different in very popular articles. How do you achieve this? Why not let the users decide by clicking "useful", "resolved", "no action needed", "inappropriate" or simply filter by "I don't care about old posts"? --TMg 13:57, 13 March 2013 (UTC)


 * It's indeed an account used by a bot/script, see de:Benutzer:Article Feedback V5. See Article feedback/Version 5/Testing at "Auto-archive comments" and Article feedback/Version 5/Feature Requirements at "Timining". I think that should answer most of your questions.--se4598 (talk) 14:14, 13 March 2013 (UTC)
 * This answers a few question, thanks. When I wrote my initial post it told me the "User account is not registered." I thought this was intended but it seems it was a bug. My main question remains: Why is an "archived" flag needed in the database? Why not simply split the "unreviewed" filter into an "unreviewed new posts" and "unreviewed old posts"? This would do exactly the same ("reduce the moderation workload") without introducing an other confusing duplicate flag. Even worse: The flag increases the overall workload. We can "undo" the flag and we have to undo the flag for certain posts. Why should we check every single post if it needs to be unarchived or not? The intended feature is to split the "stream" into two parts: fresh and old. This belongs to the filters. Not to every single post. Twitter is used as an example. Twitter does not store an "archived" flag for every single tweet. This doesn't make sense because it depends on the user if a certain post is to old to be useful for the user. Same problem here: If I watch the central feedback page I want to review only posts written in the last few hours. If I watch the feedback by category (still not possible, I really don't understand why) I need the posts from a few days or weeks. If I watch a single article I may need the feedback from the last 5 years. In short: This clearly needs to be a filter. Not a flag stored with the post.


 * What's the problem? Users complaining about the workload? The solution is insanely simple: Remove most of the numbers. Especially remove the giant numbers from the top of the pages. Move the numbers to the bottom and make them light gray and very small. Compare with Google. Yes, it tells you the total number of results. But the number is very small and almost not visible. Nobody thinks "o my god I have to review gazillions of web pages". It doesn't matter. It's more like a fun fact. Do the same and help the users focus on whats important: the top few posts according to the filter. The total number doesn't matter. Don't increase the amount of numbers by introducing an other flag. Reduce the amount of numbers. --TMg 20:15, 13 March 2013 (UTC)


 * Hey TMg, thanks for all your thoughtful ideas for simplifying the user experience in future releases. You made some interesting suggestions, but we have now ended feature development and the work you propose goes beyond the scope of this long-awaited release. At this point, we are mostly looking for bugs for the current feature set, as described on these help pages. We'll then want to test that feature set with the community for a couple months before considering any final feature changes. For now, I encourage you to test the current version of the tool, here on WMFLabs. Some of the technical bugs your reported may already be solved in that new version. And the auto-archive settings can be tweaked locally by each wiki, based on feedback from the community after testing it thoroughly with different timings. We'll get back to you about your longer-term recommendations once this week's deployment is behind us (we expect to have the new version Friday on a limited sample of articles on en-wiki and de-wiki. Thanks again for your helpful feedback! Fabrice Florin (WMF) (talk) 09:07, 14 March 2013 (UTC)