Topic on Talk:Edit Review Improvements/Proposed Huggle improvements

Please provide responses to the new icon scheme, the standardized ORES classifications, the User Info enhancements, the enhanced filtering, etc.

This is a bit off-topic. I'm an admin on en.wikipedia and I've had a lot of experience with anti-vandal/recent changes patrol (AV/RCP) work there, over many years (up to last summer). In 2014 I became dissatisfied with Huggle's limitations and built my own prototype AV/RCP program that I called AddBad. I set out the principles behind it at https://en.wikipedia.org/wiki/User:Smalljim/AddBad , which you might like to read. I haven't done anything with the program for nearly a year now, but the principles on which I built it proved to be very effective at distinguishing vandalism from good-faith edits - as evidenced by the 30,000 or so edits (mostly reverts/warnings/blocks) that I made to en.wikipedia with its aid, with an extremely low error rate. The two main things I learned are 1. there is a lot of useful information available that isn't being made use of by any of the current generation of AV/RCP programs. 2. Extensive user customisation should be available so that each editor doing RCP doesn't end up chasing the same bad edits (as happens with Huggle now). I have to say that when I tried ORES last year I was unimpressed with its predictions, and ReviewStream appeared to be clogged up with uninteresting information, while omitting the stuff that would be really useful for AV work (I don't know if they have got better since). Hope this helps, sorry it's rather negative, happy to answer any questions, etc... Smalljim (talk) 00:34, 8 February 2017 (UTC)</nowiki></nowiki>

(Copied over from the EnWiki Huggle feedback page)

Having read through the full proposal I cannot shake the feeling this proposal was written with the absolute best of intentions, but without full working knowledge of Huggle as a tool. To explain i'd like to highlight two main characteristics of Huggle:

• Huggle is realtime only: Huggle connects each editor to the recent changes feed and generates a local list of edits that have to be checked without prioritization beyond listing edits from previously reverted editors first.
• Huggle is for high-speed editing: On an average evening EnWiki had about 170 edits a minute with spikes to 220 and more edits a minute. By default Huggle filters whitelisted editors (long term editors, bots and so on) but there is still a very sizeable portion that has to be verified every minute. Huggle pre-caches all diffs before adding them to the queue so navigation between diffs is nearly instant. When reverting Huggle will handle the work in the background (Rollback + warn) while the user can review the next edit in the meantime.

Huggle as of such excels at a single job: It allows a user to single handedly monitor a wiki that is as large and busy as the English wikipedia. It is essentially a single queue that a user can navigate at high speed in order to cull any clear cut vandalism that got trough Cluebot NG or the edit filters. It is not well suited for slow patrol as it will not load old edits, and won't list any more edits if it reaches its queue capacity of 200 edits (Which on EnWiki is reached in minutes). Comparing this to the proposal as written I would conclude that the suggestions included wouldn't truly fit Huggles methodology of vandalism patrol - though I hasten to add I am but one user and other users may use Huggle in an entirely different fashion.

To explain: The proposal as written seems to focus on extending the Huggle interface so that it provides more contextual information about editors, chiefly based on the calculated ORES score / editor account age. Due to Huggle's nature i would personally find this information irrelevant: For me using Huggle equals looking at the displayed diff while using keyboard shortcuts to navigate the edit queue. I wouldn't take note of any added queue icons or the ORES score. The queue icons wouldn't be too useful as any edit in the queue would be reached in seconds: On average I spend about 2 seconds looking at a revision before concluding it is fine or clear-cut vandalism and moving to the next one. If an edit cannot be readily be identified as clear vandalism it shouldn't be dealt with trough Huggle in the first place. Using the same methodology i am not using the ORES score either: I am manually checking each edit so a machine evaluation is redundant.

The proposal as written would make a lot of sense in another vandalism patrol tool though: Stiki. While Huggle is real-time Stiki uses a server backend to log edits. Logged edits are forwarded for evaluation to editors who use Stiki. Since Stiki will happily serve weeks old edits it is much better suited to slow patrol and thus handling edits that may not be ideal yet aren't clear cases of malicious intent. I find that both tools complement each-other well: Huggle is perfect for first-line defence against clear cut vandalism while Stiki is better suited at dealing with the edge cases or cases where good faith editors may run into trouble. Since the goal of this project is new editor engagement i would argue that a slow patrol tool that doesn't have a time limit on its queue is the better option to implement this. Excirial ^{(Contact me,Contribs)} 22:58, 7 February 2017 (UTC)