維基百科:機械人/申請/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)[回覆]