User talk:Staeiou/Archives/2010/March

research

As the author of Huggle this made for interesting reading; gives an overview of the process from an academic perspective that I don't think I've seen before. Given your grasp of the field (I don't think terms like "delegated cognition" were in my original spec!) do you have any criticism of the process as a whole or suggestions for how it could be improved? There's not much I can do from a social perspective, of course, but I can try my best on the technical side. Gurch (talk) 23:29, 26 January 2010 (UTC)

So sorry for the late reply, I've been taking far too long of a wikibreak. I'm so glad that you read my article and liked it! So here are my thoughts: From the technical side of things, I think that Huggle isn't being used for blocking, though since I'm not an admin, I have no first hand experience. One thing I see are admins who vandal fight (like J.delanoy) using Huggle to revert and warn, then switching over to Twinkle to block and leave talk page notices. I think this is because Huggle doesn't do the templated block notices, right? Integration with AIV would be cool too - I know AIV console exists, but it is standalone and doesn't look like it is being actively maintained. If AIV reports were a specialized kind of queue, admins could review block requests as they are made, check the diffs, then issue a ban or one of the standard replies. Finally, I'm not sure what is going on with flagged revisions and if there is an in-browser tool to review revisions, but I see Huggle taking the lead on automating that process as well.

Speaking more on the process side, it would be great if there was some sort of coordination or division of labor between Huggle installations, but I understand the technical problems with, say, assigning edits to each user. Still, the biggest problem is getting preempted, and people don't want to have their time wasted. It becomes a race, which is good for efficiency but means that people don't always review as thoroughly. This especially becomes a problem with non-obvious vandalism, most of which just requires a minimal amount of Googling to detect.

It would be great if users could checkout or hold an edit, indicating to others that it is under review. Huggle could send out a message to a specialized IRC channel that all installations monitor, so there would be practically no overhead (or at least I assume - you know the tech details way better than I do). What also might be beneficial using this system is a way for users to signal suspicion for a given edit without reverting. The coordination benefits are obvious, and I also suspect that just giving people these options might make them use the software in different (hopefully more thoughtful) ways. For example, even if the 'hold this edit' button literally doesn't do anything, people might feel more comfortable taking their time after they press it. I might be wrong, but would be a great experiment. Stu ^(aeiou)_{I'm Researching Wikipedia} 16:51, 2 March 2010 (UTC)

Thanks for your reply. Yes, these are valid suggestions; pretty much all things that have at least crossed my mind at some point, but useful to hear from another angle.

The problems with dividing changes amongst several people are partly technical and partly social. Not everyone has IRC access, we can only really rely on them having HTTP access, so any sort of inter-client communication would require an external HTTP server that I would have to maintain, which I don't really have the resources for. What's more, there really aren't enough changes being made, or people online, to make such distribution worth the extra effort -- with ignored changes discounted, really one person can comfortably keep up with the pace of changes, and it's rare for more than two or three people to be using the software simultaneously. Finally, the big problem with having each change only reviewed by one person is that that person will make mistakes. With the current system if one person fails to deal with a problem change there is at least a chance someone else will see the same change and deal with it. Sharing changes around would lose this, and it would only take one malicious user marking all the bad changes they recieved as harmless (something that is not actionable on the wiki as no actual edits would be made) to seriously screw things up. And if each change was given to two or more people to try to mitigate this, there would be no benefit over the current system.

"Checking out" an edit has similar problems -- if someone "checks out" vandalism, and then fails to do anything with it (perhaps they're just occupied by something else), Huggle users won't see it, and if they do find it manually, will have to deal with it manually. Sure, the checkout can expire after a certain time, but that leaves the vandalism around much longer than it should be. This system is, of course, also open to abuse. This is more a social problem -- people need to realise that there is no prize for reverting the most revisions, that they should be careful regardless and if someone fixes a change before them that is a good thing. Unfortunately such social problems are not easily solved by technical means. Having a "hold" button that actually didn't do anything wouldn't be very helpful, as people would quickly figure out, when they "held" a revision and it was still reverted, that it wasn't actually doing anything. Finally, and again most importantly, such a function would be powerless to prevent changes made manually, or with any other tool, thus it wouldn't really solve anything.

There are several significant obstacles to implementing support for change patrolling or flagged revisions or any such thing in Huggle, due mostly to bad design on the MediaWiki end. I've filed issue reports and tried to fix some of the problems myself, but with little success. Even something as simple as having change tags accessible to Huggle has been completely ignored by the developers and I've had to implement the MediaWiki side of it myself (and it still has yet to go live on Wikimedia sites over a year after I requested it). I also have serious issues with the implemenation and to some extent the concept of both patrolling and the flagged revisions extension, not to mention the attitude of the vocal segment of this project's community towards it. Patrolling in a way is worse because it is a core part of MediaWiki, thus there is somewhat less of an excuse for shoddy implementation than there is for an extension such as flagged revisions, though with both used on Wikimedia projects the distinction becomes somewhat moot. And this is without even getting into the huge amount of extra "reviewing" work for no real benefit that volunteers will have to be concocted out of thin air to do (remember *every* revision except auto-patrolled revisions will have to be reviewed, so say goodbye to Huggle's whitelist, because none of those users are trusted enough in the eyes of administrators, and none of their revisions will even show up to readers unless reviewed, and hello to a much bigger queue of revisions 99% of which are good yet all of which need reviewing. Also say hello to disciplinary consequences for falsely reviewing a bad revision as good, something that is not a problem at the moment because for good revisions you simply do nothing and everything works fine). All so a few vocal users, who (coincidentally of course) are administrators and wouldn't themselves have to wait around for days and even weeks for their revisions to be reviewed, can have their way. If you're wondering what my technical objections are, here is one of the bigger deal-breakers: when a user who is shown 'stable' revisions rather than the latest revision (which would be all anonymous users) views a page and is sent to an older, 'flagged', revision, rather than the current revision, not only is the revision shown as it was then but all templates and images included in the page are shown as they were then. On the one hand this means subsequent changes to templates don't affect the 'stable' version. On the other hand, it means that if a template just happens to be vandalised when the revision comes to be flagged, flagging it will freeze the vandalised version of the template in place on that page. Now anonymous users will be directed to this old revision with a vandalised template on it -- and since normal users wouldn't be able to review their own revisions, there is nothing the author can do to get rid of this vandalism. They would have to find an administrator (who as usual, have all the power and can review whatever they like) to fix it. This is bad enough, but now consider how recent changes monitoring works, particularly in Huggle. You view a diff, and accept or reject a change based on that. If an included template is vandalised you have absolutely no indication of this from a diff, which just shows the changed wikitext of the page. To be certain there were no vandalised images or templates in an article you would have to view the article and read it from top to bottom and see that there is nothing broken about it. Now compare the effort involved to review a one-word change to a large article with a diff (read the one red word) versus reading 20 paragraphs of text. This is a fundamental design flaw in my opinion.

Huggle has the capability to block users (and post the appropriate messages); this was disabled when breaking changes to the MediaWiki software made without consideration for external tools caused Huggle's blocks to be made incorrectly. Given the problems that caused and the apparent tendency on the part of MediaWiki to change in ways that break Huggle I am somewhat reluctant to allow access to features like blocking that people create a lot of drama about. For now I've decided to intentionally not support either blocking or any sort of interface to the reported users list, in order to guarantee that no matter what the Huggle user does, there is always some point along the path from being warned to being blocked that is not handled by Huggle and must be done manually. This partly serves as a guard against users being blocked by overenthusiastic Huggle users that revert without thinking, and partly limits the damage that software problems can cause. Gurch (talk) 18:18, 2 March 2010 (UTC)

WP:Research last call for cleanup before an RFC

PiperNigrum and myself are about to start the (poorly documented) process of submitting WP:Research for review by the community and I'm making one last call for cleanup and input. Please give the article a careful read if you have a chance. Unless major flaws are discovered, we'll be adding the {{rfc}} template to the talk page to start the process on March 2nd. That's one week from this posting. --EpochFail^(talk|work) 22:29, 23 February 2010 (UTC)

The RFC has been started, but I'm worried that we are lacking participation in the discussion. We have made posts in WP:VPP, posted on wiki-research-l and invited everyone from Wikipedia:WikiProject_Research. Any ideas? --EpochFail^(talk|work) 16:43, 10 March 2010 (UTC)