維基百科

維基百科:機械人/申請/存檔/2022年/獲批的申請

< Wikipedia:机器人‎ | 申请‎ | 存档

This is an archive page. For new bot request, please to go Wikipedia:機械人/申請 and follow the instructions there.

Xiplus-abot 9

包含將不存在的條目移除（通常是從英文維基百科複製規則是產生），及修復重新導向以免移動條目後導致圖片無法顯示，範例編輯。--Xiplus#Talk 2022年1月2日 (日) 14:37 (UTC)

是否可搭配連結翻譯器確認？因為我檢查了一下，不少條目其實有本地版本。—— Eric Liu 創造は生命（留言．留名．學生會） 2022年1月2日 (日) 21:43 (UTC)
增加新的限制時，會自動豁免已經有使用的條目（這不是連結翻譯器）：Special:Diff/69456351。--Xiplus#Talk 2022年1月3日 (一) 16:24 (UTC)
增加移除不存在的檔案：Special:Diff/69455828。--Xiplus#Talk 2022年1月3日 (一) 16:23 (UTC)
  快速批准運作。--Jimmy Xu 論 2022年1月10日 (一) 15:05 (UTC)

申請變更：增加維護{{受限制文件}}的功能，移除：1 2、標記：1 2。--Xiplus#Talk 2023年3月21日 (二) 12:30 (UTC)

  快速批准運作 --百無一用是書生 (☎) 2023年3月23日 (四) 08:17 (UTC)

Jimmy-abot 3

已批准--Kegns（留言） 2014年5月2日 (五) 13:11 (UTC)
鑑於目前本站在中國大陸無法直接訪問，對開放代理採取過於激進的主動封禁帶來了較大的負面影響，暫時撤回批准待修正--Kegns（留言） 2016年2月8日 (一) 08:23 (UTC)
依Wikipedia:互助客棧/其他#重啟「機械人自動封禁機房IP段的任務」的提議重提申請，排除列表在User:Jimmy-abot/NOP.json。--Jimmy Xu 論 2021年9月20日 (一) 13:32 (UTC)
我近期有遇到公共WiFi熱點的出口IP位址被（全域）封鎖的情況，封鎖原因是機房地址，雖然我在這邊的編輯不受影響，是在編輯metawiki/enwiki的時候發現的，在utrs@enwiki嘗試申訴無果（被拒絕）。我並沒有認真調查為什麼那個WiFi會使用Akamai的機房地址作為出口IP，以及這樣的現象有多廣泛，也並沒有想過應該怎麼辦。就在這裏說一下吧，看有沒有人了解是什麼情況，以及應該怎麼應對。Liangent（留言） 2021年9月25日 (六) 03:21 (UTC)
是不是出口直接有透明代理。--Jimmy Xu 論 2021年9月25日 (六) 16:10 (UTC)
有重複封鎖/解封的問題 https://w.wiki/4dR8 。--Xiplus#Talk 2022年1月2日 (日) 14:42 (UTC)
另外能否好好使用action=unblock，不管在紀錄上不會標成解除封鎖，或是與其他工具整合都會造成麻煩，例如被CVN認為是第二次封鎖而加入黑名單。--Xiplus#Talk 2022年1月2日 (日) 14:49 (UTC)
重複封鎖的問題來自數據源，我之前已經修掉了一些，如果再運行的話會盯着這例看看。
action=unblock已修改。--Jimmy Xu 論 2022年1月10日 (一) 15:00 (UTC)
看起來仍然在使用0秒在解封而非action=unblock。--Xiplus#Talk 2022年1月20日 (四) 11:03 (UTC)
最後一次日誌操作在2021-12-20T10:52:16。--Jimmy Xu 論 2022年1月20日 (四) 18:11 (UTC)
抱歉漏看時間了，所以現在是測試完先停止了嗎？看來只缺一個批准？--Xiplus#Talk 2022年1月23日 (日) 11:37 (UTC)
之前3個月測試完成之後就先停止了。應該是的。--Jimmy Xu 論 2022年1月23日 (日) 13:51 (UTC)
看起來上面提的問題都解決了，  正式批准運作。--Xiplus#Talk 2022年1月24日 (一) 05:47 (UTC)

LuciferianBot 3

匯入自en:Wikipedia:Bots/Requests for approval/Mz7 (bot)並本地化。--路西法人☆ 2022年1月24日 (一) 09:22 (UTC)

  批准測試運作（直到正式啟用），配合現在在準備各個頁面同時來測試，正式啟用前再重新檢視一次有沒有問題。--Xiplus#Talk 2022年1月26日 (三) 05:54 (UTC)
@Xiplus：SPI已正式啟用，複查無問題（除了昨天私訊提及一筆在更新機械人期間因手誤而造成error的編輯，已迅速修正）。--路西法人☆ 2022年2月14日 (一) 03:30 (UTC)
每分鐘檢查好像不必要地增加太多編輯，建議跟enwiki一樣10分鐘檢查1次就好。--Xiplus#Talk 2022年2月14日 (一) 03:36 (UTC)
已改。--路西法人☆ 2022年2月14日 (一) 04:05 (UTC)
  批准延長測試運作（30日），再觀察其他狀態有無問題。--Xiplus#Talk 2022年2月15日 (二) 02:50 (UTC)
  測試已完成：延長測試運作已達30日，不見有任何新問題導致運作異常。--路西法人𖤐 2022年3月17日 (四) 03:29 (UTC)
  正式批准運作。--Xiplus#Talk 2022年3月17日 (四) 04:53 (UTC)

Air7538-bot 4

目前是空分類。似乎沒有多到需要bot維護的地步？--百無一用是書生 (☎) 2021年8月4日 (三) 07:08 (UTC)
能夠自動化作業總是好的吧。—— Eric Liu 創造は生命（留言．留名．學生會） 2021年8月4日 (三) 07:30 (UTC)
某天我一共移除了28個，可以看我貢獻記錄，在今年的7月26日。這個有積壓的可能。--Air7538（留言） 2021年8月5日 (四) 00:04 (UTC)
ok，可否詳細說明一下整個任務的工作流？--百無一用是書生 (☎) 2021年8月6日 (五) 03:26 (UTC)
  批准測試運作（30次編輯）。--Jimmy Xu 論 2021年8月29日 (日) 18:12 (UTC)
這個怎麼樣了？--百無一用是書生 (☎) 2021年10月22日 (五) 07:12 (UTC)
因為這個分類（Category:已逝世超過一個月的人物）經常是空的，所以還沒有進行測試。。。--Air7538（留言） 2021年10月23日 (六) 10:08 (UTC)
過去1個月有35筆人工移除，但機械人仍然沒有任何測試？--Xiplus#Talk 2022年1月20日 (四) 10:57 (UTC)
我儘快。--Air7538（留言） 2022年2月1日 (二) 10:28 (UTC)
您應該讓您的程式定期自動執行，您申請的自動化程度是全自動。--Xiplus#Talk 2022年2月2日 (三) 13:36 (UTC)
現在可以全自動執行，每天執行3次，時間在0:10（UTC）6:10（UTC）12:10（UTC）。我會在自動執行後，複查一下自動編輯。--Air7538（留言） 2022年2月13日 (日) 06:12 (UTC)
  測試已完成，剛才一下子多了10幾筆編輯，測試期間沒什麼問題，我的正則表達式寫的太爛了。--Air7538（留言） 2022年2月28日 (一) 13:05 (UTC)
Special:Diff/71395017，請不要留下空白行。 regex 後面應該加上 \n? 。修正後  批准延長測試運作（5次編輯），完成後ping我。--Xiplus#Talk 2022年5月1日 (日) 06:44 (UTC)
@Xiplus已完成。--Air7538（留言） 2022年5月8日 (日) 00:12 (UTC)
用 \n? 比 \n 好吧？--Xiplus#Talk 2022年5月8日 (日) 06:01 (UTC)
有道理，已改。--Air7538（留言） 2022年5月8日 (日) 07:00 (UTC)
  正式批准運作。--Xiplus#Talk 2022年5月8日 (日) 14:24 (UTC)

MilkyDeferBot

  • 狀態：   已批准
  • 操作者：Milky·Defer
  • 提請時間：2022年2月2日 (三) 12:55 (UTC)
  • 自動化程度：全自動
  • 程式語言：Rust
  • 用途：根據分類、模版嵌入、頁面鏈入鏈出、頁面前綴等條件篩選並創建頁面列表
  • 原始碼連結：GitHub
  • 編輯時段及頻率：可調節（見下方「工作機制」）
  • 受影響頁面：不定（見下方「工作機制」）
  • 遵守機械人規範：無關
  • 已有機械人權限：否

用戶故事：長期以來，電子遊戲維基專題使用一個「最近更改」頁面來追蹤電子遊戲相關條目的最近更改，有助於巡查破壞等。這個頁面的背後依賴於一個記錄了所有電子遊戲條目的專題頁面：WikiProject:電子遊戲/條目列表。這個列表的更新長期以來一直由User:Lopullinen負責，他的工作流程是前往Quarry進行查詢，然後使用Excel篩選出位於條目名字空間的頁面，再手動將內容粘貼上去[來源]。去年下半年，Lopullinen的大部分時間忙於現實生活，無力及時更新列表，大致一個月才有時間更新一次，導致一個月內創建的新條目（以及被移動的既有條目）無法得到及時跟蹤。此外，專題的優良、典範、特表清單也是由他負責進行手動更新。最近他終於用上了PAWS進行半自動的更新，但是他仍然希望有機械人可以做到全自動更新。

因此我考慮寫了這個功能比較簡單的機械人，可以依照不同的條件按照不同的輸出格式生成頁面列表。頁面列表對最近更改巡查、各個專題的更新、維基百科本身的維護有益。最近更改巡查的兩個頁面列表都有大半年沒更新了，估計也沒有幾個人知道。

類似技術與分析：目前存在一些功能相近的解決方案。其中之一是DynamicPageList擴展，這個擴展只能以分類作為生成依據，但是它是置於MediaWiki內運行的擴展，而非外部工具。DPL的更新是即時的，也在俄語維基新聞大批量導入頁面的時候，搞垮了整個伺服器集群造成網站大面積下線。DPL不適合在中文維基百科使用，實際上中文維基百科沒有安裝這個擴展，phab也不允許安裝這個擴展。另一個功能相近的方案是Quarry，也就是Lopullinen曾經在用的方案，這是一個外部工具，直接對數據庫執行SQL查詢，因此具有很強的靈活性（比我寫的這個機械人要強），但是要求使用者有SQL基礎，且非自動任務，生成的結果需要人工的後續處理才能放入站內頁面中。PetScan也是一樣，其功能也很強大（甚至包括了圖片使用、維基數據），但同樣也不是自動任務，也需要後續的人工處理。英文維基百科有JL-Bot為各個專題列出當專題的優秀條目列表，可以佐證類似需求和技術實現是現實的。

工作機制：機械人所執行的工作按照「任務」（Task）來組織。Task定義了一項查詢的表達式、查詢超時、查詢限額、查詢頻率、輸出頁面與格式。因此機械人會影響到的頁面僅僅由Task數量以及每個Task定義的輸出頁面數量決定。機械人工作並非即時也並非連續，工作頻率由Task決定。每個Task處於JSON頁面內受到MediaWiki界面保護，可防止破壞與濫用（我不登入機械人賬號我自己都沒法用我主號控制機械人運作）。此外，機械人僅根據頁面的上述元數據屬性進行查詢，不過問頁面內的實際內容，因此也不存在大量下載頁面內容的疑慮。

安全性：考慮到DPL的前車之鑑，待申請的機械人的運作十分保守。所有的作業都規定了最大超時時間（默認120秒，可對單個Task覆蓋默認值），以及最大查詢限額（默認單次API查詢限額50000條，可對單個任務以及單個查詢覆蓋默認值）。這也是PetScan存在的安全限制（PetScan網頁默認限制一萬條結果）。超出查詢時間會導致查詢即時終止，超出查詢限額則會導致查詢結果不全。為了防止濫用，機械人還有特殊的限制：如果被指定的輸出頁面位於機械人配置中的「禁止命名空間」中，則機械人不會向目標頁面寫入內容（當前包括條目空間，可配置加入使用者討論空間）、如果被指定的頁面不存在，則機械人不會創建目標頁面、如果被指定的頁面是重定向頁面，則機械人不會寫入內容。上述機制儘可能保障機械人不會讓伺服器過載，以及儘可能防止他人利用機械人進行騷擾和破壞。

小規模測試：機械人方針容許在使用者個人頁面中進行測試，因此我提前利用它進行了三個不同的查詢。User:MilkyDefer/plbot test/vglist執行了用戶故事中Lopullinen想要做的事情；User:MilkyDefer/plbot test/vgexpand列出了電子遊戲條目中掛有空章節或需要擴充模版的頁面；User:MilkyDefer/plbot test/vgimportant則列出了當前優良條目、典範條目、特色列表中被掛上維護模版以至於被列入「拒絕當選新條目首頁展示」分類的條目，這幾個條目應該要被拉出來重審。其他的一次性工作例子則包括列出WP:GA、WP:FA、WP:FL頁面中的重定向頁面供User:Ericliu1912修正等。

請求機械人運作許可：限於機械人方針限制，沒有獲批的機械人只能在測試頁面和自己的用戶頁內進行測試，因此無法在其他頁面內運作。此外，申請機械人權限可以獲得API高請求限額，因此一次查詢可以返回更多結果，減少API訪問次數降低伺服器負載，也可以減少由於等待數據傳輸而導致的可能超時問題。我已經熟讀API使用禮儀，尊重Maxlag參數，頁面寫入由互斥鎖控制，不存在同時寫入大量頁面問題。此外，申請機械人運作可以讓我有機會在Toolforge上運作該機械人，屆時會考慮接入SQL查詢以獲得更好的體驗，不過我看不懂Toolforge的申請流程。

以上，希望各位不吝賜教。 --Milky·Defer 2022年2月2日 (三) 12:55 (UTC)

根據專題品質評級標準，本機械人申請已評為典範級。--Xiplus#Talk 2022年2月2日 (三) 13:33 (UTC)
所以想要建立新的列表，是直接向您申請嗎？管理員也有權力直接建立新的列表？--Xiplus#Talk 2022年2月2日 (三) 13:35 (UTC)
是這樣的，管理員是受信任的使用者，而普通用戶提出申請也能有一層人工審核，感覺比較安全。 --Milky·Defer 2022年2月2日 (三) 14:43 (UTC)
(＋)支持。—— Eric Liu 創造は生命（留言．留名．學生會） 2022年2月20日 (日) 09:03 (UTC)
  批准測試運作（30日）。--Xiplus#Talk 2022年2月26日 (六) 15:00 (UTC)
了解，稍後我去申請Wikitech和ToolForge，等申請通過後開始測試。--Milky·Defer 2022年2月27日 (日) 05:40 (UTC)

現在30日測試已經接近結束，這裏報告一下情況。機械人所進行的所有工作都列在了User:MilkyDeferBot/pagelistbot/tasks當中。其中大部分都跟分類集合的交並補相關，但是也有利用其它機械人所列出的列表進行進一步處理的例子，這個例子展示了該機械人潛在的與其他機械人配合工作的能力。

在機械人運作的期間它沒有發癲，也沒有因編碼不良而發生運行時錯誤的情況。接下來的重點改進放在 完成將機械人定時運作機制從指定間隔時間改為指定cron上，以及 完成多使用一些惰性加載的模式來稍微改善點性能。我希望能夠趁着清明假期完成。 --MilkyDefer 2022年4月1日 (五) 13:11 (UTC)

Special:Diff/71396510，失敗的話不更新頁面會比較好？--Xiplus#Talk 2022年5月2日 (一) 14:08 (UTC)
@Xiplus：我設計這個機制的本意是如果有人不小心寫錯了表達式的話能得到反饋知道自己做錯了。不然的話遲遲不更新頁面也不知道發生什麼事了，就真的除了我跑去toolforge後台查看日誌之外別無他法了。--MilkyDefer 2022年5月2日 (一) 14:11 (UTC)
可以顯示錯誤訊息，但不移除下面的列表？--Xiplus#Talk 2022年5月2日 (一) 14:16 (UTC)
聽上去可行，這幾天實現試試。P.S. 我發現因為密鑰的問題我上不去Toolforge了（囧）--MilkyDefer 2022年5月2日 (一) 14:23 (UTC)
從後台導出檢閱了一下日誌，是網絡連接突然中斷的事故（Broken pipe os error 32）。--MilkyDefer 2022年5月2日 (一) 14:50 (UTC)
@Xiplus：：給機械人添加了一個「eager mode」機制——只有當任務被指定為「eager mode: true」時，不論結果如何都會更新全部內容（與之前行為一致）；默認為false，此時若查詢不成功則只會更新狀態模板，不會碰頁面的其他部分。這裏展示一次運作實例：我在做出這筆更新後，機械人僅更新了模板部分（該任務每個整點啟動，下次更新會在東八區晚上九點，此時應會恢復正常運作）。另外，我終於搞清楚為什麼我用tmux在Toolforge那邊掛着機械人每三四天就會自動被殺死了，原來是我搞錯了用法——已經改為提交至Grid Engine運作。 --MilkyDefer 2022年5月4日 (三) 12:08 (UTC)
  正式批准運作。--Xiplus#Talk 2022年5月8日 (日) 14:25 (UTC)
@Xiplus：請問接下來，機械人的botflag是……會怎麼樣呢？--MilkyDefer 2022年5月8日 (日) 14:56 (UTC)
找個行政員來授權吧。--Xiplus#Talk 2022年5月8日 (日) 15:26 (UTC)
 完成。—AT 2022年5月8日 (日) 16:12 (UTC)

Willy1018-bot 5

寂伏經年，據《機械人方針》，撤銷許可。--J.Wong 2023年12月29日 (五) 13:32 (UTC)

Crystal-bot 4

您確定只有semimajor這個參數而已嗎？--Xiplus#Talk 2022年6月4日 (六) 12:26 (UTC)

@Xiplus、Antigng：根據Antigng在irc的發言修改了代碼。對於小行星只有semimajor這個參數，對於挪威市鎮只有demonym這個參數。 Stang★ 2022年6月4日 (六) 13:53 (UTC)
  批准測試運作（50次編輯）。--Xiplus#Talk 2022年6月4日 (六) 14:02 (UTC)
  測試已完成，一開始正則寫的稍微有點問題（前4筆編輯），後來修正了。後續測試未發現問題。 Stang★ 2022年6月4日 (六) 14:16 (UTC)
  批准測試運作（50次編輯），要求：小行星和挪威市鎮條目各25條。--Antigng（留言） 2022年6月4日 (六) 14:21 (UTC)
  測試已完成，挪威市鎮條目共21條已全部完成，小行星條目25條，兩者均未發現問題。 Stang★ 2022年6月4日 (六) 14:34 (UTC)
該任務影響條目總量不足600，已測試近1/6且未發現新問題。予以  快速批准運作，請行政員核實後授予權限。--Antigng（留言） 2022年6月4日 (六) 14:46 (UTC)
@AT：ping一下在線的行政員。 Stang★ 2022年6月4日 (六) 22:18 (UTC)
 完成。—AT 2022年6月4日 (六) 22:24 (UTC)
  已完成。 Stang★ 2022年6月4日 (六) 23:17 (UTC)

TolBot 5

這個機械人已經在 5 個其他語言的 wiki 操作。Stang 要求我在這裏操作我的機械人。Tol（留言） 2022年6月7日 (二) 17:47 (UTC)

  快速批准運作 --百無一用是書生 (☎) 2022年6月8日 (三) 03:21 (UTC)

Xiplus-abot 10

  • 狀態：   已批准
  • 操作者：Xiplus#Talk
  • 提請時間：2022年5月29日 (日) 10:43 (UTC)
  • 自動化程度：全自動
  • 程式語言：Pywikibot
  • 用途：跟隨使用者更名移動Flow頁面
  • 原始碼連結：Github
  • 編輯時段及頻率：每日一次
  • 受影響頁面：
  • 遵守機械人規範：否
  • 已有機械人權限：是
於Phabricator查看
編號T126229的工單
於Phabricator查看
編號T150572的工單

範例操作，目標頁面名稱首先會嘗試相同名稱的子頁面，如果頁面已存在，則依序嘗試使用「结构式讨论 存档 X」，此子頁面名稱跟Flow系統相同。--Xiplus#Talk 2022年5月29日 (日) 10:43 (UTC)

如果一個人至少更名兩次（或以上）會發生什麼事？分別假設兩次（或以上）更名前都有結構式討論頁存檔跟只有其中一（幾）次有的情況。—— Eric Liu 創造は生命（留言・留名・學生會） 2022年5月29日 (日) 10:58 (UTC)
會移動兩次。多個結構式討論跟多次重命名無關，反正機械人會按照編號依序找到合適的目標名稱。--Xiplus#Talk 2022年5月29日 (日) 11:18 (UTC)
  批准測試運作（50次編輯）-Peacearth（留言） 2022年6月5日 (日) 04:52 (UTC)
  測試已完成：結果。--Xiplus#Talk 2022年6月5日 (日) 05:25 (UTC)
使用者討論:CapitainAfrika/結構式討論 存檔 2（原未在新名稱下）比使用者討論:CapitainAfrika/結構式討論 存檔 1（原已在新名稱下）早建立，但順序卻反了。機械人或應該要先判斷二頁面建立時間前後，將原存檔一移動至存檔二，再將未更名的存檔移動至存檔一。—— Eric Liu 創造は生命（留言・留名・學生會） 2022年6月5日 (日) 05:41 (UTC)
這樣還需要額外的資料查詢，改成優先處理page_id比較小的頁面，有高度類似的效果。--Xiplus#Talk 2022年6月5日 (日) 05:55 (UTC)
該任務不打算去更動不需要移動的頁面，故該意見不被考慮。--Xiplus#Talk 2022年6月5日 (日) 05:57 (UTC)
這本質上是系統bug所造成的結果，雖然此機械人任務貌似沒有打算處理，但往後仍應該通盤檢討是否修正。—— Eric Liu 創造は生命（留言・留名・學生會） 2022年6月15日 (三) 09:09 (UTC)
如果有即時移動，那就不會有出現兩個Flow的問題，那有該任務後，就再也不會出現兩個Flow的問題了。--Xiplus#Talk 2022年6月15日 (三) 11:28 (UTC)
  正式批准運作-Peacearth（留言） 2022年6月8日 (三) 13:24 (UTC)

Crystal-bot 3

原申請

每15分鐘獲取最近更改，篩選帶有mw-undo或mw-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)

Dušan Kreheľ (bot)

  • 狀態：   已批准
  • 操作者：Dušan Kreheľ（留言）
  • 提請時間：2022年6月8日 (三) 03:05 (UTC)
  • 自動化程度：Automatically or semi-automatically
  • 程式語言：PHP, Wikimate and my custom code.
  • 用途：Merging simple identical references by bot (Only the wiki syntax type changes).
  • 原始碼連結：Private.
  • 編輯時段及頻率：Maximal 2 times per month.
  • 受影響頁面：Standard no more pages.
  • 遵守機械人規範：No.
  • 已有機械人權限：No.

✍️ Dušan Kreheľ（留言） 2022年6月8日 (三) 03:05 (UTC)

"User account "Dušan Kreheľ (bot)" is not registered." Please use the bot account to log in to zhwiki first--百無一用是書生 (☎) 2022年6月8日 (三) 06:36 (UTC)
@Shizhao: Fixed.--Dušan Kreheľ（留言） 2022年6月8日 (三) 08:30 (UTC)
Which wikis are this bot task already running on?--百無一用是書生 (☎) 2022年6月8日 (三) 08:45 (UTC)
en:Wikipedia:Bots/Requests_for_approval/Dušan_Kreheľ_(bot)_III--Antigng（留言） 2022年6月8日 (三) 10:37 (UTC)
@Antigng: My idea is: The bot merging the references and then the someone change the name of references later. The user select the name of the reference based on the title, the url, the publisher or the tematic subject. I wanna the my bot changes the small and good. My change will definitely improve the readability of pages for readers. It's my offer.--Dušan Kreheľ（留言） 2022年6月8日 (三) 12:56 (UTC)
@Shizhao: Actual: cswiki, jawiki, slwiki, euwiki and eswiki. Maybe soon on ptwiki.--Dušan Kreheľ（留言） 2022年6月8日 (三) 12:39 (UTC)

  批准測試運作（50次編輯） --百無一用是書生 (☎) 2022年6月9日 (四) 01:49 (UTC)

@Shizhao: The 50 testing changes is done.--Dušan Kreheľ（留言） 2022年6月9日 (四) 08:06 (UTC)
Just a note that the bot falsely triggered several abuse filters a lot of times and I have fixed those AFs. --碸中嘌呤的白磷萃取 打譜 2022年6月9日 (四) 08:19 (UTC)
@WhitePhosphorus: I don't think it's completely fake. I think that AFs is more strictly configured and also plays a big role when the account was created (My bot account have approximate only 24 hours). Although the bot is in the "confirmed" group, him changes are strict blocked (none warning) to removing more text from the page.--Dušan Kreheľ（留言） 2022年6月9日 (四) 08:46 (UTC)
@WhitePhosphorus: AF does not know my bot account is the bot, so he considers him as a user. It's probably better to have fake warnings now than to overlook malicious activity in another case.--Dušan Kreheľ（留言） 2022年6月9日 (四) 08:55 (UTC)
Can the edit summary be in Chinese?--百無一用是書生 (☎) 2022年6月9日 (四) 09:30 (UTC)
To be more specific, could you make the bot's interface texts locally configurable? --Antigng（留言） 2022年6月9日 (四) 10:17 (UTC)
@Shizhao, @Antigng: None problem. But, You must write the text (or translate), how have I use in the page change description with my bot. My bot use standard this comment style messages (Notice: singular/plural):
Sorry, I might have not been clear. By "locally configurable" I meant, to let your bot take the text of local configuration page(s) as the input for bot interface(s), rather than hard code it in your program. For instance, Xiplus-abot is an approved bot, and it is configurable via pages like User:Xiplus-abot/task/10/config.json.--Antigng（留言） 2022年6月10日 (五) 02:29 (UTC)
其實這個要看個案，不是都有這種必要--百無一用是書生 (☎) 2022年6月10日 (五) 03:32 (UTC)
@Shizhao, @Antigng: Not the bad way. You can set: User:Dušan Kreheľ/Merging simple identical references by bot/Edit summary/zh.--Dušan Kreheľ（留言） 2022年6月10日 (五) 08:39 (UTC)
Edit summary has been translated,   批准延長測試運作（50次編輯）--百無一用是書生 (☎) 2022年6月13日 (一) 02:27 (UTC)
@Shizhao: Next 50 adjustments were made.--Dušan Kreheľ（留言） 2022年6月19日 (日) 09:50 (UTC)

  正式批准運作 --百無一用是書生 (☎) 2022年6月20日 (一) 08:38 (UTC)

Dušan Kreheľ (bot) 2

cite模板內archive-url參數（或者類似的）應保證不被變更。 Stang★ 2022年6月29日 (三) 17:27 (UTC)
@Stang: Thx Your message. The better way is, if the URL is "archive.org", so the URL is skeeped.--Dušan Kreheľ（留言） 2022年6月29日 (三) 21:20 (UTC)
@Stang: It is implement to ignore the domain archive.org now.--Dušan Kreheľ（留言） 2022年6月30日 (四) 17:01 (UTC)
  批准測試運作（50次編輯） --百無一用是書生 (☎) 2022年7月8日 (五) 11:49 (UTC)
@Shizhao: The 50 changes is done.--Dušan Kreheľ（留言） 2022年7月8日 (五) 19:07 (UTC)
find a bug: [2]. Don't fix content in <syntaxhighlight>, <pre>, <nowiki>--百無一用是書生 (☎) 2022年7月9日 (六) 12:28 (UTC)
@Shizhao: Yes, fixed. There was no condition for testing the tag names with the broken tag names.--Dušan Kreheľ（留言） 2022年7月9日 (六) 12:57 (UTC)
@Dušan Kreheľ：I like the idea, but also have multiple questions:
  1. The reason why the source code is not available. The rules is configurable? Or just because it's still an alpha.
  2. How many pages will check and modify, all pages per 15 days? and why it doesn't comply the {{bot}}, or the future will comply.
  3. diff, just removing the trailing "&" is not worth committing I think.
  4. It does not adequately remove all useless parameters. null parameters, ?hp&?hp (may need to be customized), oref&oref=slogin, chksm= (maybe).--YFdyh000（留言） 2022年7月12日 (二) 02:48 (UTC)
It is difficult to remove all useless parameters--百無一用是書生 (☎) 2022年7月12日 (二) 03:20 (UTC)
@Shizhao:
  1. The source code is public.
  2. Standart no more pages. The list of pages for change is generated from a dump of the local wikipedia (new wiki dump are 2 times per month).
  3. Even one insignificant character can be used for tracking.
  4. Thanks for the tips for the next revision of the tracking parameters.--Dušan Kreheľ（留言） 2022年7月12日 (二) 15:43 (UTC)
  批准延長測試運作（50 edits） --百無一用是書生 (☎) 2022年7月13日 (三) 02:15 (UTC)
@Shizhao: Ups, 60 changes is done.--Dušan Kreheľ（留言） 2022年7月13日 (三) 07:23 (UTC)
  正式批准運作 --百無一用是書生 (☎) 2022年8月1日 (一) 05:59 (UTC)

LuciferianBot 4

  • 機械人將自動運行兩項任務：
    1. 檢查查核請求問題：在傀儡調查中請求查核的案件自動產生報表檢查被提報查核的帳號的問題，會在報表中提供的問題包括無效用戶名（IP帳號）、沒有本地帳號、在本地沒有可見編輯或日誌記錄、在本地超過90天前最後可見編輯或日誌記錄（可能  數據過期）、在本地超過83天前最後可見編輯或日誌記錄（可能即將  數據過期）。此任務隨產生「Wikipedia:傀儡調查/案件」報表的任務執行，每十分鐘更新報表的同時找出新的查核請求提供報表，如無新查核請求則沒有額外動作。
    2. 提示監管員留言：此系根據絲糖君於Wikipedia:機械人/作業請求#同步SPI中監管員的查核結果提出的工作。監聽m:SRCU監管員作出的編輯，如監管員有新留言則於本地作出提示，提示僅會在本地案件狀態為「endorse」或「condefer」時提供。現階段暫時僅作出提示有新留言，但由於現在SPI（以及過往HAM）的習慣還是轉回來的時候也要翻譯成中文給本地，如果以絲糖君所提出的做法直接轉回來似乎有所牴觸，故此部分暫緩執行。
--路西法人 2022年6月10日 (五) 04:57 (UTC)
通知上次審閱SPI報表任務的Xiplus君和其他調查助理1233、ATannedBurger、Itcfangye、SCP-2000諸君。--路西法人 2022年6月10日 (五) 05:01 (UTC)
建議頻率改為5分鐘。--1233 （T / C） 2022年6月10日 (五) 11:24 (UTC)
子任務1中已根據Antigng君在站外的提醒修改成「在本地沒有可見編輯或日誌記錄」和「在本地超過90/83天前最後可見編輯或日誌記錄」。--路西法人 2022年6月12日 (日) 01:51 (UTC)
1. 簽名應該放在留言最後面。 2. 非查核的SPI還是可以確認IP，而且本質上是不會公佈帳號與IP間關係，查核時提供IP是沒有問題的。--Xiplus#Talk 2022年6月19日 (日) 01:33 (UTC)
已修正訊息留言置於留言最後方，而IP的訊息已經撤除。--路西法人 2022年6月22日 (三) 01:27 (UTC)
  批准測試運作（14日）先測試一段時間再看有什麼問題需要改善。--Xiplus#Talk 2022年6月22日 (三) 01:45 (UTC)
e04我開了半天才發現早前測試用的filter沒關掉，完全沒在運行（（（14天從第一筆編輯啟計吧。--路西法人 2022年6月24日 (五) 15:13 (UTC)
機械人應簽名。 Stang★ 2022年6月30日 (四) 16:00 (UTC)
有留意到，那個只是測試編輯（強行搬回過去的留言作測試），並非實際運作環境。--路西法人 2022年7月1日 (五) 00:16 (UTC)
測試運作以第一筆有效編輯（2022年7月3日 (日) 10:20 (UTC)）起計。--路西法人 2022年7月4日 (一) 00:14 (UTC)
請轉換機械助理一詞，可以考慮-{zh-hans:机器人助理;zh-hant:機械助理}-；指向監管員用戶名的連結建議使用metawiki的；如果可行的話，請不要更新{{doing}}的回應。 Stang★ 2022年7月6日 (三) 15:57 (UTC)
已更新，已加入地區詞轉換和監管員用戶名連結；新版本會讀取監管員的狀態更新，監管員的{{doing}}會將狀態變更為checking（版本差異），而完成查核就會留言完成查核並將狀態變更為checked（版本差異）。--路西法人 2022年7月9日 (六) 01:12 (UTC) 編輯：補個連結。--路西法人編輯於2022年7月12日 (二) 08:54 (UTC)
考慮到只有香港翻譯為「機械人」，建議臺灣正體地區詞改為「機械人助理」。—— Eric Liu 創造は生命（留言・留名・學生會） 2022年7月13日 (三) 08:30 (UTC)
@Ericliu1912、Stang：新版本的原始碼改成「機械人」（不帶手動轉換），該詞會自動轉換成zh-tw的「機器人」和zh-cn的「机器人」。（zh-hk的「機械」不會自動轉換成「機器」，但機械人有）--路西法人 2022年7月13日 (三) 09:06 (UTC)
  測試已完成，順便十四天唯一一次CU請求有即將過期的帳號觸發自動提示的編輯差異。--路西法人 2022年7月17日 (日) 15:07 (UTC)
通知@Xiplus、Ericliu1912、Stang。--路西法人 2022年7月17日 (日) 15:08 (UTC)
LGTM，不過為什麼機械人的簽名中的兩個連結是一樣的。@LuciferianThomas： Stang★ 2022年7月18日 (一) 00:53 (UTC)
User:LuciferianBot/SPIsign我寫錯了（（（（--路西法人 2022年7月18日 (一) 01:18 (UTC)
Special:Diff/72911871，建議收集常見的status參數，顯示為完成而不是d。--Xiplus#Talk 2022年7月27日 (三) 02:19 (UTC)
 完成。--路西法人 2022年7月27日 (三) 02:51 (UTC)
  批准延長測試運作（30日）--Xiplus#Talk 2022年7月27日 (三) 02:53 (UTC)
Special:Diff/73336386 案件狀態設為undefined--Xiplus#Talk 2022年8月25日 (四) 02:21 (UTC)
前兩天注意到的時候修復了，處理狀態時未有處理掉註釋（假設了監管員更改狀態會移除註釋），且switch漏了個default。[3]--路西法人 2022年8月25日 (四) 02:24 (UTC)
  測試已完成@Xiplus：。--路西法人 2022年9月1日 (四) 06:15 (UTC)
  正式批准運作。--Xiplus#Talk 2022年9月1日 (四) 06:21 (UTC)

Crystal-bot 3

原申請

每15分鐘獲取最近更改，篩選帶有mw-undo或mw-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)
啊，是有的[4]--百無一用是書生 (☎) 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)

Koalabot 4

A2093064-bot 29

根據簽名指引自動提醒以下問題： 1. 簽名過長 2. 簽名包含模板或模板樣式 3. 簽名包含外部連結，目前僅自動提醒這些類別，可參見User:A2093064-bot/task/42/問題簽名列表（過時的標籤等Lint error不在簽名指引規範內，不會進行提醒），將提醒3次，兩次之間間隔至少7天且至少使用1次該簽名（這表示長期沒有使用簽名的人不會被提醒），3次警告無效自動提報至Wikipedia:管理員佈告板/其他不當行為。--Xiplus#Talk 2022年8月26日 (五) 15:16 (UTC)

  批准測試運作,建議只測試代碼中匹配簽名的功能，並把匹配到的簽名在用戶空間的頁面上展示，便於向審核人員展示匹配到的簽名大概是什麼樣的。代碼中其他部分我認為暫時沒有測試的必要--百無一用是書生 (☎) 2022年10月11日 (二) 07:24 (UTC)
另，bot檢查簽名問題是採用signatures.toolforge.org的結果麼？--百無一用是書生 (☎) 2022年10月11日 (二) 07:28 (UTC)
我不知道signatures.toolforge用的是不是transform/wikitext/to/lint，Lint errors我是用這個，不過Lint errors暫不在提醒範圍內，其他的判斷是自己寫的，可參考程式碼。--Xiplus#Talk 2022年10月11日 (二) 08:57 (UTC)
匹配簽名及展示檢測到的錯誤已經長期運作於User:A2093064-bot/task/42/問題簽名列表，可看歷史，另外請問測試內容包含通知使用者嗎？--Xiplus#Talk 2022年10月11日 (二) 09:03 (UTC)
  快速批准運作，檢查User:A2093064-bot/task/42/問題簽名列表看起來邏輯沒什麼問題--百無一用是書生 (☎) 2022年10月11日 (二) 09:40 (UTC)

DeadbeefBot

英維上已有權限，現在請求在中文維基上作業。0xDeadbeef（留言） 2022年10月1日 (六) 14:22 (UTC)
請先在本wiki或metawiki的用戶頁上說明該bot的任務（即，讓中文社群其他人很容易的就知道這個bot是幹什麼的）。--百無一用是書生 (☎) 2022年10月11日 (二) 07:38 (UTC)
@Shizhao:  完成--0xDeadbeef（留言） 2022年10月12日 (三) 05:56 (UTC)
根據en:Wikipedia:Bots/Requests for approval/ScannerBot，  快速批准運作 --百無一用是書生 (☎) 2022年10月12日 (三) 06:54 (UTC)

Willy1018-bot 6

  快速批准運作 --百無一用是書生 (☎) 2022年10月12日 (三) 13:29 (UTC)
寂伏經年，據《機械人方針》，撤銷許可。--J.Wong 2023年12月29日 (五) 13:33 (UTC)

Bluedeck-b-bot

  • 狀態：   已批准
  • 操作者：Bluedeck
  • 提請時間：2022年10月10日 (一) 20:46 (UTC)
  • 自動化程度：全自動
  • 程式語言：Typescript / Nodejs 18
  • 用途：給用戶發送郵件。有時會不頻繁的記錄一些日誌在子頁面。如果編輯，只編輯自己的子頁面。
  • 原始碼連結：無
  • 編輯時段及頻率：基本不編輯，主要是發郵件
  • 受影響頁面：僅用戶子頁面，數量不確定
  • 遵守機械人規範：不編輯他人的用戶頁和用戶討論頁
  • 已有機械人權限：否
細節：發送郵件的用途：這是 unblock-zh.org 準備工作的一環。bluedeck-b-bot 會根據 unblock-zh.org 的指令來驗證用戶身份。比如，通過點擊郵件中的連結驗證自己在wiki上的賬號。郵件的頻率會由伺服器上的一些heuristics控制，比如，同一個用戶一天發送郵件數量不超過兩件。同一個IP一天發送郵件總數量不超過兩件，兩件以上會對IP和IP段進行CAPTCHA/POW處理。為了記載日誌而做出的編輯數應該不超過1小時一次。Bluedeck 2022年10月10日 (一) 21:13 (UTC)
如果需要驗證身份的話，為什麼不使用oauth呢？ Stang★ 2022年10月10日 (一) 21:23 (UTC)
oauth只能是host在labs上的app用，我這個不host在labs上 Bluedeck 2022年10月10日 (一) 21:37 (UTC)
也不是吧，你比較trusted然後這個工具只是驗證信息，感覺問題應該不大 Stang★ 2022年10月10日 (一) 21:39 (UTC)
你是對的，現在這個限制好像沒有了，我會去寫oauth。不過同時我仍然想提供一個走email驗證的方式供用戶選擇（不用輸密碼、2FA）。Bluedeck 2022年10月11日 (二) 06:58 (UTC)
如上所言的話，email驗證只是用做額外途徑，那麼還有必要非要用這個賬號發郵件麼？而且走這個賬號發驗證郵件，郵件域名是wikipedia.org，而用來驗證的域名是unblock-zh.org，這會否存在安全問題或其他隱患？最後，如果不host在labs上，長期來看是否會存在持續性問題？--百無一用是書生 (☎) 2022年10月11日 (二) 07:47 (UTC)
為什麼必須用wiki上的電郵功能：有一個69.42.0.1造訪，聲稱自己是zhwiki上的「James Wales」用戶，選擇郵件驗證。那我一定是給user:James Wales發一枚確認郵件，而不是要求69.42.0.1提供自己的任意郵箱，因為目的是驗證wiki用戶所屬，而不是驗證郵箱所屬。那麼user:James Wales的在wiki註冊的郵箱是不公開的，所以唯一的途徑就是用special:emailuser發給user:James Wales，因此必須用電郵用戶。Bluedeck 2022年10月11日 (二) 08:18 (UTC)
ok。明白了。但還有一個顧慮，首先oauth已經能解決「驗證wiki用戶所屬」的問題，其次用戶郵箱本身不公開，但通過這種方式進行郵箱驗證，是否存在過度收集用戶郵箱的私隱問題？（特別還是在WMF伺服器以外的地方）--百無一用是書生 (☎) 2022年10月11日 (二) 09:46 (UTC)
不存在。special:emailuser發送完郵件後，發件人看不到user:James Wales的郵箱地址（當然除非他回覆郵件）。驗證方式是點擊郵件中連結，這個操作也是無法讓伺服器了解到你的郵箱地址。Bluedeck 2022年10月11日 (二) 10:08 (UTC)
我目前基本上沒什麼意見了。但出于謹慎，希望有其他人能夠給出意見。 --百無一用是書生 (☎) 2022年10月12日 (三) 07:00 (UTC)
在個人測試範圍內  正式批准運作。--Xiplus#Talk 2022年10月28日 (五) 02:51 (UTC)

Ning-Bot 2

首先依照某些條件，將User:維基小霸王/沙盒4中的條目大致分為三類，其中A與B類使用AWB通過替換章節標題的方法新增章節或在相關章節內新增內容；C類條目不作處理。已使用主賬號通過AWB進行了少量（20筆）測試性編輯。見此，均由本人檢查，未發現明顯問題。--Yining Chen（留言|簽名頁） 2022年10月25日 (二) 05:56 (UTC)

(＋)支持--維基小霸王（留言） 2022年10月26日 (三) 02:19 (UTC)
能否提供AWB該任務的設定檔案？--Xiplus#Talk 2022年10月28日 (五) 02:48 (UTC)
User:Ning-Bot/Task/settings.xml. --Yining Chen（留言|簽名頁） 2022年10月28日 (五) 03:14 (UTC)
為什麼要將參考XX換成參考資料，根據Wikipedia:格式手冊/版面佈局#附錄元素指引，那是不同的東西。--Xiplus#Talk 2022年10月29日 (六) 13:10 (UTC)
改為使用其他方法進行替換。已將相關原始碼放置於上方。示例。--Yining Chen（留言|簽名頁） 2022年10月30日 (日) 05:48 (UTC)
我覺得re5的正規表達式有點問題。--Xiplus#Talk 2022年11月4日 (五) 02:28 (UTC)
似乎確實有問題，只匹配了一半的標題。但或許不影響使用，因為沒有使用其進行替換。而且如果改成和re4相同的形式就沒問題了。--Yining Chen（留言|簽名頁） 2022年11月4日 (五) 14:22 (UTC)
  批准測試運作（100次編輯）。--Xiplus#Talk 2022年11月6日 (日) 12:38 (UTC)
  測試已完成。在某一個條目中，機械人進行了兩次替換；另外在前10個條目編輯時引入了一個多餘的空行，均已修正。--Yining Chen（留言|簽名頁） 2022年11月6日 (日) 13:48 (UTC)
參考文獻後面被額外加入一個空格（變成兩個空格）。--Xiplus#Talk 2022年11月6日 (日) 13:54 (UTC)
已完成。--Yining Chen（留言|簽名頁） 2022年11月6日 (日) 14:11 (UTC)
這筆編輯表示一個頁面會被加入多個章節？這不對吧。--Xiplus#Talk 2022年11月8日 (二) 15:38 (UTC)
這是為測試相關代碼而有意進行的修改。實際代碼只會添加一個標題。--Yining Chen（留言|簽名頁） 2022年11月9日 (三) 10:50 (UTC)
  批准延長測試運作（50次編輯）。--Xiplus#Talk 2022年11月9日 (三) 15:45 (UTC)
  測試已完成。--Yining Chen（留言|簽名頁） 2022年11月10日 (四) 09:53 (UTC)
參考資料後面的換行是不必要加入的（或者說不符格式自動修正的規則）。--Xiplus#Talk 2022年11月10日 (四) 13:34 (UTC)
另外編輯摘要意義不明，建議修改一下（例如 加入{{[[T:Wikisource further reading|Wikisource further reading]]}}相當直白），連同這個修正後請做一筆編輯。--Xiplus#Talk 2022年11月10日 (四) 13:37 (UTC)
完成。--Yining Chen（留言|簽名頁） 2022年11月11日 (五) 10:47 (UTC)
  正式批准運作，請找行政員授權。--Xiplus#Talk 2022年11月11日 (五) 12:56 (UTC)
已授權。—AT 2022年11月13日 (日) 10:14 (UTC)
  撤銷許可 任務已完成，per Special:PermaLink/75484780。--Xiplus#Talk 2023年1月12日 (四) 14:16 (UTC)
取自 "https://zh.wikipedia.org/w/index.php?title=Wikipedia:机器人/申请/存档/2022年/獲批的申請&oldid=75241289"