维基百科:机器人/申请/存档/2022年/獲批的申請

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

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)
@XiplusSPI已正式啟用,複查無問題(除了昨天私訊提及一筆在更新機械人期間因手誤而造成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)

@XiplusAntigng根据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)
@ATping一下在线的行政员。 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
  • 編輯時段及頻率:每日一次
  • 受影響頁面:
  • 遵守機器人規範
  • 已有機器人權限:

範例操作,目標頁面名稱首先會嘗試相同名稱的子頁面,如果頁面已存在,則依序嘗試使用「结构式讨论 存档 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-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)

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君和其他調查助理1233ATannedBurgerItcfangyeSCP-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)
@Ericliu1912Stang新版本的原始碼改成「機械人」(不帶手動轉換),該詞會自動轉換成zh-tw的「機器人」和zh-cn的「机器人」。(zh-hk的「機械」不會自動轉換成「機器」,但機械人有)--西 2022年7月13日 (三) 09:06 (UTC)
測試已完成,順便十四天唯一一次CU請求有即將過期的帳號觸發自動提示的編輯差異。--西 2022年7月17日 (日) 15:07 (UTC)
通知@XiplusEricliu1912Stang--西 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-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)
啊,是有的[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)