维基百科:机器人/申请/Crystal-bot/3

维基百科,自由的百科全书

Crystal-bot 3

原申请

每15分钟获取最近更改,筛选带有mw-undomw-rollback的编辑,如果做出上述编辑的用户是延伸确认用户,标记被其回退的编辑为已巡查。

脚本会从带有mw-undo的编辑向前搜索,如果发现与前述修订版本相同的版本,则存储搜索过程中找到的所有版本;如果超过50个编辑后仍未找到,放弃搜索。对于回退操作,则会从mw-rollback的编辑向前搜索,直到做出编辑的用户的用户名发生变化为止。最后,将上述搜索过程中找到的所有版本标记为已巡查。 Stang 2022年6月2日 (四) 00:20 (UTC)[回复]

简单测试了一下 Stang 2022年6月2日 (四) 00:22 (UTC)[回复]
我覺得只需要標記最新(或進行回退的)版本為已巡查就好,不需要每筆都標記。--Xiplus#Talk 2022年6月2日 (四) 01:11 (UTC)[回复]
一定程度上借鉴了这边的指南。进行回退的版本目前没管,看共识吧。 Stang 2022年6月2日 (四) 01:25 (UTC)[回复]
我覺得應該是回退到另一個已巡查版本才視為自動巡查吧?--Xiplus#Talk 2022年6月2日 (四) 03:48 (UTC)[回复]
我的想法是“一个相对资深的用户对某个页面执行了回退,那么可以认为被退回的页面已经被检查过了”;你这种思路有点像flaggedrev那种处理方法(autoreviewrestore),我感觉问题主要在于那个“被退回到的版本”可能并没有人标记(尽管它很可能是没问题的),另外“查某个修订版本是不是被巡查过了”有些过于麻烦了。 Stang 2022年6月3日 (五) 14:37 (UTC)[回复]
批准測試運作(100次編輯) --百無一用是書生 () 2022年6月6日 (一) 13:23 (UTC)[回复]
@Shizhao请授予patroller权限。另外本任务不涉及编辑。 Stang 2022年6月6日 (一) 15:26 (UTC)[回复]
套用的模板而已,就是100次巡查操作--百無一用是書生 () 2022年6月7日 (二) 01:50 (UTC)[回复]
測試已完成。在2022-06-06T16:19Z至2022-06-07T06:49Z(共14.5个小时)期间,执行了100次标记巡查。标记巡查在某些情况下会失败,例如被标记的版本:由持有autopatrol权限的用户做出、距今超过了30天、已被修订版本删除(内容)、是被回退(mw-rollback)的。本任务不会检查标记巡查是否成功。 Stang 2022年6月7日 (二) 06:52 (UTC)[回复]
回退由MW系統自動將被回退的編輯標為已巡查,只需要巡查回退本身(如同我前面建議)。--Xiplus#Talk 2022年6月7日 (二) 15:10 (UTC)[回复]
已进行修改(目前会对附带mw-rollback标签的编辑进行巡查),如有需要可延长测试。 Stang 2022年6月7日 (二) 16:06 (UTC)[回复]
我不太清楚,API不提供某个版本是否已巡查的标记么?--百無一用是書生 () 2022年6月8日 (三) 03:27 (UTC)[回复]
啊,是有的[1]--百無一用是書生 () 2022年6月8日 (三) 03:47 (UTC)[回复]
你是指标记巡查前先判断这个版本是否已被标记过了?感觉没这个必要,这又不是edit还要考虑冲突问题;还是说用这个当generator,那么不是这么一回事吧,我应该查的是mw-undo撤销掉的编辑(而不是带mw-undo这个tag的编辑)是否是已被标记过的。 Stang 2022年6月8日 (三) 04:06 (UTC)[回复]
啊,之前的搞错意思了,那为何不直接查标记为mw-reverted的编辑呢?--百無一用是書生 () 2022年6月8日 (三) 06:28 (UTC)[回复]
一方面,mw-reverted的添加(跑一个RevertedTagUpdateJob)在时间上具有一定的滞后性,具体会延迟多少不清楚,但这会对判断产生一定的误差;另一方面,The mw-reverted change tag is applied shortly after the revert is made if the edit is considered auto-approved...If patrolling is enabled on your wiki, auto-approval is equivalent to the edit being autopatrolled. Thus, only users with the autopatrol user right will have their reverted tag applied right away.@Shizhao Stang 2022年6月8日 (三) 07:29 (UTC)[回复]
顺便本来是想用EventStreams的,可惜那边给不出来tag Stang 2022年6月8日 (三) 07:44 (UTC)[回复]
原来这样。这个task竟然有11年历史了.....。说回正题,这个任务只要把需要标记为已巡查的修订根据条件判断正确就行了,至于你说的标记失败的例子,我认为没啥大问题,顶多就是后台日志输出可能多了点(只要不标错,标漏了没关系)--百無一用是書生 () 2022年6月8日 (三) 08:55 (UTC)[回复]
另外,能不能社群讨论一下,符合什么条件的用户的编辑可以视为免巡查,那么只要某用户达到该条件,就可以用bot把他之前的编辑全部标记为已巡查。甚至可以考虑结合OERS打分的情况,只要评分好的编辑,不管是谁编辑的,全都用bot自动标记为已巡查。我说这个的目的就是,尽量把未巡查的数量减少,以便更加凸显版本巡查的意义--百無一用是書生 () 2022年6月8日 (三) 09:02 (UTC)[回复]
来点数据以我运行这个机器人之前的7天为例,7天内共发生编辑221445次,最近更改中有26%的编辑(57163笔)出于未巡查状态,而进行了最近更改巡查的修订版本只占全部编辑的0.04%(85笔)。以上面测试的数据估计,这个任务可以将待巡查的编辑的2%(约1160笔)进行标记(感觉比例很小啊)。我支持设置一个条件使“达成就可以使用机器人将其的编辑全部标记巡查”(当然,最理想的情况是Xiplus贡献的patch得到合并)。 Stang 2022年6月8日 (三) 11:05 (UTC)[回复]
SQL有錯,應該使用rc_type = 0而非rc_new = 0。--Xiplus#Talk 2022年6月8日 (三) 12:42 (UTC)[回复]
感谢指出。更正:7天内产生的104243笔对已存在的页面的编辑中,有55%的编辑(56893笔)未被最近巡查,最近更改巡查共83笔,占全部编辑的0.07%。ORES相关的事项稍后发到客栈其他版。 Stang 2022年6月8日 (三) 13:50 (UTC)[回复]
批准延長測試運作 100次巡查操作--百無一用是書生 () 2022年6月8日 (三) 09:03 (UTC)[回复]
进行中……日志参见此处 Stang 2022年6月8日 (三) 11:05 (UTC)[回复]
測試已完成。在2022-06-08T10:34:00Z至2022-06-09T01:49:00Z(共15.25个小时)期间,执行了112次标记巡查 Stang 2022年6月9日 (四) 02:20 (UTC)[回复]
看到客栈开讨论了。如果客栈讨论有结果并做了bot,那本任务是不是意义就不大了?--百無一用是書生 () 2022年6月9日 (四) 03:08 (UTC)[回复]
不怎么相关,被回退的编辑一般都不怎么goodfaith。如果有结果那扩充一下本任务的范围好了,bot也比较好写。 Stang 2022年6月9日 (四) 03:24 (UTC)[回复]

 正式批准運作 --百無一用是書生 () 2022年6月9日 (四) 03:38 (UTC)[回复]

@Stang:我仍強烈建議如果您要巡查被回退編輯的話,也請同時巡查該回退本身,我現在常常在巡查時,檢查最近一次巡查的版本與最新版本的差異(檢查所有未巡查修訂差異的意思),然後發現這是一筆回退的編輯,但這個破壞已經被其他人檢查過了,我不應該要再次檢查。--Xiplus#Talk 2022年6月10日 (五) 07:01 (UTC)[回复]
參見食物巡查日誌或透過Wikipedia:最近更改巡查小工具查看歷史。--Xiplus#Talk 2022年6月10日 (五) 07:03 (UTC)[回复]
我主要担心出现编辑战的问题。另外如果客栈里的提案通过的话,应该可以解决大部分您说到的情况。 Stang 2022年6月10日 (五) 07:56 (UTC)[回复]
編輯戰的問題?--Xiplus#Talk 2022年6月10日 (五) 11:44 (UTC)[回复]
重新一想问题不大,即使那种问题也不是修订巡查应该负责的范围,已修改。 Stang 2022年6月10日 (五) 13:24 (UTC)[回复]

变更1

接上6月被存档了的客栈讨论。本脚本监听ORES的EventStreams,当“damaging为false且goodfaith为true”时标记编辑为已巡查。因为任务很相关所以就写到一个页面上了。 Stang 2022年7月13日 (三) 04:32 (UTC)[回复]

是不是这个任务通过,就可以不用屏蔽未巡查标记了?--百無一用是書生 () 2022年7月13日 (三) 08:26 (UTC)[回复]
為什麼不用0.027這個門檻?--Xiplus#Talk 2022年7月13日 (三) 09:20 (UTC)[回复]
我的理解是,采用真假的方式好处是简单、不用维护、保持与ORES的判断标准在逻辑上一致、且能巡查掉大半的(可能)无问题编辑;0.027则是自定的标准,可能需要时不常调整数值,很多(可能)无问题编辑不会被巡查?--百無一用是書生 () 2022年7月13日 (三) 09:51 (UTC)[回复]
尝试dry run了一下发现用EventStreams传回的true/false用很大的问题……
标上“★”的是一些damaging是true的probability接近50%的编辑,看起来ORES认为这个值不到50%就没问题……?新版的代码已修改成读0.027这种值来判断的方式。 Stang 2022年7月13日 (三) 11:48 (UTC)[回复]
在機器學習應用面上,這個數值本來就是由人工選定,您所認為的「真假」,也只是選定門檻值為0.5而已,並無差異,反而是選定0.5無邏輯,「保持與ORES的判斷標準在邏輯上一致」實際上ORES就是選定0.027作為門檻。--Xiplus#Talk 2022年7月13日 (三) 12:33 (UTC)[回复]
不实际进行巡查的跑了几天,发现大概可以巡查掉30%的(可以被巡查的)编辑。 Stang 2022年7月16日 (六) 19:22 (UTC)[回复]
 正式批准運作 --百無一用是書生 () 2022年7月28日 (四) 02:56 (UTC)[回复]

变更2

灵感来自元维基的一个task Stang 2022年7月13日 (三) 14:15 (UTC)[回复]

批准測試運作(30日) --百無一用是書生 () 2022年7月28日 (四) 02:56 (UTC)[回复]
測試已完成具体参见日志,未发现明显问题。@Shizhao Stang 2022年9月5日 (一) 05:54 (UTC)[回复]
 正式批准運作 --百無一用是書生 () 2022年9月5日 (一) 06:38 (UTC)[回复]