维基百科:机器人/申请/存档/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)