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.
 * 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)