wikimedia / mediawiki-gadgets-RTRC

Mirror of https://gerrit.wikimedia.org/g/mediawiki/gadgets/RTRC.
https://meta.wikimedia.org/wiki/RTRC
MIT License
26 stars 11 forks source link

increase limitation from 500 to 1000 #73

Closed reza1615 closed 5 months ago

reza1615 commented 6 years ago

Please increase top limitation from 500 too 1000 image

Krinkle commented 6 years ago

@reza1615 Thank you for using RTRC!

About your request, the maximum is not decided by RTRC. It is actually decided by the wiki software (MediaWiki). And for most queries, the limit is 500 results.

https://www.mediawiki.org/wiki/API:Lists#Limits https://en.wikipedia.org/w/api.php?action=help&modules=query%2Brecentchanges (see rclimit)

This is the same as for when you viewing a query page on the wiki, such as https://en.wikipedia.org/w/index.php?title=Wikipedia:Sandbox&action=history.

For bot accounts, the limit is 5000.

reza1615 commented 6 years ago

@Krinkle I know about API limitation but MediaWiki's limitation for users is 5000 like https://en.wikipedia.org/w/index.php?title=Wikipedia:Sandbox&offset=&limit=5000&action=history it can use a loop to achieve more than 500 results.

reza1615 commented 6 years ago

also at https://www.mediawiki.org/wiki/API:Lists#Limits mentioned "5000 for users with the apihighlimits right (typically bots and sysops)" at least we can have up to 5000 for sysops. I checked at local wiki. as I am sysop it shows up to 5000 results.

Krinkle commented 6 years ago

@reza1615 Okay, I suppose we could make it conditional on a particular user right. RTRC already does this for control fields that depend on the patrol user right, for example.

However, can you tell me a little bit about how you use RTRC and why would want to show 5,000 revisions within the RTRC tool?

Given the automatic refresh feature, and the need to collaborate with other users to avoid patrolling the same edits multiple times, I would generally recommend users to have a very low limit (e.g. 10 or 20). Basically, showing just enough edits to keep the user busy between automatic refreshes (which should take about 3-5 seconds at most).

reza1615 commented 6 years ago

I use it in fa.wikipedia. fa.wiki is a medium size wiki and it's RC not like en.wiki which is highly active. so sometimes of the day, we don't have many edits and it takes about 1 minute to have 1 new edit! on the other hand at the rush hours average of our patrollers is less than 2 or 3 person. so it will be very useful for small size wikis also for en.wiki and other large size wikis at some hours of the middle night (Europian Time) which are not so crowded. If I have 1000 or 5000 limitations I will open it and try to find high priority edits at the first and try to patrol them. It is a request from other users and me and it will help us to patroling much better and exciting than now.

Krinkle commented 6 years ago

@reza1615 Thank you for explaining, this helps me understand how you use it.

Can you tell me how you determine what is a high priority edit? Do you know ORES information?

I have a plan to integrate ORES scores in RTRC as part of the filter. That way, if you enable ORES and select "damaging", it will can show you 50 edits that are damaging (instead of all 50 edits, with maybe 3 edits highlighted as damaging).

See also https://www.mediawiki.org/wiki/Edit_Review_Improvements/New_filters_for_edit_review. This filter was recently added to https://fa.wikipedia.org/wiki/Special:Recentchanges.

I do not have much time for RTRC, but the original Recent Changes page is getting better. Might even replace RTRC one day!

Would it help you and others on fa.wikipedia to feature this way in RTRC?

reza1615 commented 6 years ago

I know about New_filters_for_edit_review it has two problems 1- it is so heavy and loading the page takes some seconds 2-It is not live. live is the best feature of RTRC. about "high priority edit": I check the size of changes and the username (for example when an IP remove more than 1KB I will check it at the first. If RTRC can apply ORES It will help users to patrol efficiently.

Krinkle commented 5 months ago

Exported to https://phabricator.wikimedia.org/T361283.