维基百科

维基百科讨论:机器人/申请

< Wikipedia talk:机器人
Aotfs2013在话题“容许长期没有讨论的WP:BRFA进行测试”中的最新留言：6年前
了解更多有关此页面的信息

Wikipedia:机器人/申请

最新留言：在14年前发布5条留言3人参与讨论

这个页面要统一一下，新的申请放在最上面还是最下面，现在放在上面下面的都有……--Liangent (留言) 2009年12月13日 (日) 05:50 (UTC)回复

哦，貌似是说我？--达师—信访—工作报告 2009年12月13日 (日) 10:04 (UTC)回复
你和灰菇,一下一上--Liangent (留言) 2009年12月13日 (日) 11:18 (UTC)回复

我认为这是小事情，因此我很bold地自己决定把新的申请放到最底了，也重新排序了所有申请。如果没有异议就这样吧。—Altt311 (留言) 2009年12月13日 (日) 16:16 (UTC)回复

另外请留意trustmebot的申请，根据账户纪录我肯定该用户虚报资料（其实是复制自其他申请），请协助处理。—Altt311 (留言) 2009年12月13日 (日) 16:16 (UTC)回复

Flagging on meta

最新留言：在11年前发布3条留言3人参与讨论

Hello, I'm rather curious as to why a wiki with 8 local bureaucrats is redirecting bots seeking automatic approval to meta to be flagged by stewards. It seems rather odd to say the least, as it also means that the logs for bot flagging are on meta and not here. Snowolf How can I help? 2012年3月5日 (一) 15:21 (UTC)回复

有人想回答这个问题吗？Bennylin（留言） 2012年12月21日 (五) 08:34 (UTC)回复
Thanks Benny, IIRC I have replied to Snowolf over this matter on IRC or meta. In case my memory failed me, basically we are not redirecting automatically approval requests to meta. It was a comment by a user that 'requesting at meta may get you faster response'. At that time our crats were not really active. --Ben.mq 2012年12月21日 (五) 09:10 (UTC)回复

机器人的审批

最新留言：在9年前发布11条留言4人参与讨论

本主题或以下段落文字，移动自Wikipedia:互助客栈/其他。执行者：Jimmy-bot（留言） 2015年9月30日 (三) 08:42 (UTC)。回复

请教一下，现在大概有哪些管理员们在做机器人的审批呢？--Kanashimi（留言） 2015年9月20日 (日) 03:46 (UTC)回复

书生、Jimmy Xu、Kegns吧--贾大师讲大道 2015年9月20日 (日) 03:49 (UTC)回复
只有行政员才能审批。--Antigng（留言） 2015年9月20日 (日) 03:54 (UTC)回复
有可能加速审批吗？--Kanashimi（留言） 2015年9月20日 (日) 04:06 (UTC)回复
这么快就等不及了？我还比你早两天呢。--Antigng（留言） 2015年9月20日 (日) 04:16 (UTC)回复
之前曾经等了段时间，想了解一下审批的瓶颈在哪。--Kanashimi（留言） 2015年9月20日 (日) 04:26 (UTC)回复
@Kanashimi：存废讨论天天都有，管理员每天都会去看；封禁申诉很重要，管理员每天也都会去看。机器人申请既不重要又不紧急，不可能有人每天关注，还要行政员批准，自然就慢了。--Antigng（留言） 2015年9月20日 (日) 05:17 (UTC)回复
我们有可能提供些援助吗？--Kanashimi（留言） 2015年9月20日 (日) 05:19 (UTC)回复
想要凑齐en:WP:BAG那么多人是不可能的。--Antigng（留言） 2015年9月20日 (日) 05:47 (UTC)回复
或者我们可以把标准放低一些？--Kanashimi（留言） 2015年9月20日 (日) 05:59 (UTC)回复

提议于本地设置机器人审核员专门权限

最新留言：在7年前发布194条留言22人参与讨论

本主题或以下段落文字，移动自Wikipedia:互助客栈/方针。执行者：-和平、奋斗、救地球！（留言）欢迎加入维基Telegram群 2017年2月21日 (二) 11:21 (UTC)。回复

前期讨论

如题。希望本地能设置相关权限（现今中文维基百科负责批核机器人权限与功能者为WP:行政员，英文维基百科则有Bot Approvals Group）。详述如下：

为什么要这么做？
  1. 当今Wikipedia:机器人/申请有许多积压（而且还不包含因为太多积压而导致失去/降低意愿的潜在申请），现有活跃之行政员数量过少，无暇应付。
  2. 行政员不一定了解相关技术，这只是行政员事务的一部分。根据WP:行政员：“行政员须具备的能力：在出现复杂情况的时候，决定投票共识及结论，并能有效地对这些决定做出全面解释”，对于机器人相关领域的理解则非其所要求的。
  3. 由于机器人申请的特殊性，需要有专精相关领域的成员协助判断。如果不熟相关领域的行政员仅依共识而造成误判，可能会造成大量的错误发生。
  4. 反之，如果交由熟悉相关领域之受信任用户判断授权，较为适当。
  5. 方便熟悉相关领域之受信任用户协助处理积压，而不需要等到自己成为行政员之后才能处理。“只是为了走过场而完成程序并不是维基百科的方针”。
可行吗？会不会产生什么问题？
  1. 当今中文维基百科有很多活跃且熟悉相关领域的非行政员（包含管理员）受信任用户，应能解决当前处理人力不足之问题。
  2. 虽然不一定能如同en:WP:BAG那么多人[1]，但是本地的事务量也相对没那么多，而且程序上应尚不至于需要搞得那么复杂（维持现有程序应该够，顶多微调一下），所以应不成问题。

以上，不知大家觉得如何？-和平、奋斗、救地球！（留言） 2017年1月26日 (四) 11:58 (UTC)回复

实行问题

原则上不反对，唯有以下数点:

1. 选拔方式。行政员有民意支持，故可一人独断。审核员应否以选举产生?
2. 权力运用。审核员应以小组方式投票通过一项目，或可一人决定?如机器人运作出现问题，审核员应否负连带责任?
3. 不活跃/解职规定。在何种情况下可对审核员免职?
4. 管理员会否自动成为此小组成员?

以上，望解答。--Temp3600（留言） 2017年1月26日 (四) 15:11 (UTC)回复

对于BAG组的选拔，我建议有持有现役机器人的用户可以优先。——路过围观的Sakamotosan 2017年1月27日 (五) 01:16 (UTC)回复
“优先”指的是参选的资格?投票的资格?--Temp3600（留言） 2017年1月27日 (五) 04:36 (UTC)回复
参加BAG的。——路过围观的Sakamotosan 2017年1月27日 (五) 05:08 (UTC)回复
对于BAG组的选拔，我建议有持有现役机器人的用户可以优先。——路过围观的Sakamotosan 2017年1月27日 (五) 01:16 (UTC)回复
个人意见：
  1. 首先申请者需要有一定的技术背景和经验。因此我认为申请者首先需要是持有现役机器人的用户或管理员。由于机器人的操作可能会在短时间内影响大量条目，所以审核员应该是需要被社群成员所信任的，故应可采用社群推选的模式。
  2. 这点可以考虑。不过这也需要考虑到审核员人数多寡，如果太少人的话我认为只要没有其他审核员反对，一位审核员通过即可（不过当然要给其他人有审视的时间）。至于连带责任，则视情形交由社群决定。若严重程度上确有必要则可将其免职。
  3. 不活跃规定同巡查回退管理行政员。其余部分免职的话如果是社群推选，则可罢免，若否则WP:申请解除权限。
  4. 行政员可自动成为此小组成员（毕竟现在的情况就是这样），至于管理员的话可进一步讨论。
以上。-和平、奋斗、救地球！（留言） 2017年1月27日 (五) 05:09 (UTC)回复
应注意本案并非微调程序就能解决。BAG本质为一咨询团体，虽无实质权力，但将对目前体制的权力安排构成重大影响。光是BAG applications 应否放进RFA就是个大问题了。本人倾向不放。--Temp3600（留言） 2017年1月29日 (日) 13:42 (UTC)回复

我觉得方针里其实有一个阻碍审批的问题：“在经过一段时间的讨论后，行政员将根据社区共识批准或拒绝申请”。这里以及具体的规则上都没有明确定义时间的长短。这样导致的一个后果就是在审批时往往认为讨论不充分，因此长期放置。此外，这里的共识倒不是要走投票，因为还得有技术上的考虑。因此，我想提议参考Wikipedia:共识#过程中的“没有异议或不被其他编者回退的编辑，均可假定其具备共识”的说法，为机器人的审批设定一个终止时间：在这个时间点之前，如果其他用户提出的所有问题都得到了正面的回答，且提出问题者或表示对回答满意，或没有继续追问，就认为共识存在且通过：唯一例外是审批者具有否决权，以确保专业角度上机器人不会引发问题。—菲菇＠维基食用菌协会 2017年1月27日 (五) 05:27 (UTC)回复

(！)意见：如果有最后几[天时分秒]追问的话，会来不及回答从而影响审批。要不回答时间比终止时间延长一些，像动员令那样。 --白磷变成了红磷并祝您春节快乐~萃取 打谱 2017年1月30日 (一) 15:25 (UTC)回复
我不打算制订硬性的结束时间。--Temp3600（留言） 2017年1月30日 (一) 16:43 (UTC)回复
的确有卡在最后几[天时分秒]的情况。因此，可否考虑可以将结束时间设置在最后一次有效讨论之后的XX天（类似但不等同于互助客栈的存档规则）？这样既能保证充分讨论，也能避免卡时间的情况出现。此外，此处的“有效讨论”不包括插科打诨和纯粹的支持、反对及其单调附加语（如“好”、“不错”，“赞成”，“就应该怎么做”，“这样不对”，“1024”等）。--菲菇＠维基食用菌协会 2017年1月31日 (二) 07:10 (UTC)回复

可参考英文版

英文版目前BAG制度如下:

申请者不一定是持有现役机器人的用户或管理员。当然，这种情况下提名极难通过。事实上组里大半人都是管理员。
需社群投票通过，但不设最低通过票数。获通过者一般有十票。
提名期为时一周。
解任方式为reconfirmation vote，此制度类似优特重审，即要求重新进行授权投票。

英文版目前bot applications制度如下:

bot applications 设trial period 制度。一般为50 edits。BOT从申请到正式批准需三次批核。(50 trial / 100 extended trial / approved)
通过约需一周至一个月。
只需一名BAG审议即可。

--Temp3600（留言） 2017年1月28日 (六) 09:57 (UTC)回复

我想先看看大家有没有什么想法。如果没有的话，我可能数天后提出本地方案初稿。如果需要设立投票，希望@和平奮鬥救地球：协助处理。
请注意本案颇为复杂，涉及两大部分:创设BAG制度，及修订目前机器人申请方针。提出意见时，请考虑不同部分之间的互动。

--Temp3600（留言） 2017年1月28日 (六) 10:12 (UTC)回复

即使是在英文版BAG active members也只有7人。尽力而为吧。--Temp3600（留言） 2017年1月30日 (一) 09:36 (UTC)回复

分拆机器人方针

和奋球坑我啊...我要先拆出bot policy 为一独立页面。--Temp3600（留言） 2017年1月30日 (一) 09:47 (UTC)回复
弄好了第一部分-直接分拆。见草稿:Wikipedia:机器人方针。由于日后要补上机器人审核小组的有关章节，我想先看看有没有人想借机修改机器人方针。由于本案不涉任何实质修订，如没有反对意见，将直接通过。

@和平奮鬥救地球、Clear Sky C、小躍、PhiLiP：--Temp3600（留言） 2017年1月30日 (一) 10:17 (UTC)回复
@Temp3600： 谢谢您，那么原本的“指引”、“参见”、“资源”要改移动到何处呢？-和平、奋斗、救地球！（留言） 2017年1月31日 (二) 03:15 (UTC)回复
@和平奮鬥救地球：那些可移可不移，因为BAG group设立的规定要写进方针里面，所以要先独立出来。本身的机器人页面则可按英文版再改。--Temp3600（留言） 2017年1月31日 (二) 03:50 (UTC)回复
OK。既然并未涉及任何实质修订，我想如果一天内没有任何反对意见就通过吧。-和平、奋斗、救地球！（留言） 2017年1月31日 (二) 04:01 (UTC)回复
离提出已有一天，拆分完成。顺带一提，如参考英文版，“指引”部分也会移入方针区。--Temp3600（留言） 2017年1月31日 (二) 16:15 (UTC)回复

机器人申请页面

日后的机器人申请页面:草稿:维基百科:机器人/申请。有意见请提出。--Temp3600（留言） 2017年1月30日 (一) 17:07 (UTC)回复

草稿:Wikipedia:机器人审核小组初稿完成。请注意本文甚短，因主要内容将仿效英文版放到方针里。--Temp3600（留言） 2017年1月30日 (一) 17:52 (UTC)回复
  赞-和平、奋斗、救地球！（留言） 2017年1月31日 (二) 03:16 (UTC)回复
这算是遗留问题，可一并改之。--Temp3600（留言） 2017年2月1日 (三) 17:41 (UTC)回复

BAG产生办法提案

既然方针拆分完成，终于可以在方针上进一步修改了。我的初步提案如下:

申请加入BAG组规则如下:
所有行政员自动加入。
投票权限于有本地机器人的用户。AWB使用者应否有权投票则未定。
参选权属于所有用户。这主要是方便一些以前有机器人，或是在外站有丰富经验的用户。
当选最低要求为+5票。正反票一一扺消。
投票期约一星期。社群可在期间提出问题考察申请人的能力。
提问期一星期。行政员在社群结束讨论后，可关闭投票，作出决定。
半年不参与机器人事务，则标记为不活跃用户。是否移稌出组可议。我建议暂时涷结资格，用户回归时只要无人反对就可开始工作。
罢免方法为信任投票，等于重选。(即目前优特重审。)冷静期三个月。只有拥有投票权的用户有资格提出信任投票。


日后机器人授权流程如下:

分四阶段，每阶段约一星期
申请测试许可(1-3 天)-第一阶段测试(50edits/7-10days)-第二阶段测试(100edits/7-10days)-正式通过
一名BAG就可通过，行政员可直接授权，不必再审查。所以一但批出正式许可就无法收回，只能要管理员把BOT封掉。如其他BAG对该机器人有疑虑，应及早提出。


注意: BAG组虽无正式权力，但其作为维基机器人事务的正式咨询组织，拥有机器人事务上最大的发言权。

--Temp3600（留言） 2017年1月31日 (二) 17:02 (UTC)回复
(？)疑问：
  1. “投票期”与“提问期”之差异？
  2. “第一阶段测试”与“第二阶段测试”之差异？
以上。-和平、奋斗、救地球！（留言） 2017年2月1日 (三) 04:29 (UTC)回复
1.这是为应对菲菇和白磷提出的“可否考虑可以将结束时间设置在最后一次有效讨论之后的XX天（类似但不等同于互助客栈的存档规则）”而设，希望给予申请人足够的时间回答问题。
2.这个可举例:
小明在X月1日向BAG提出申请。社群觉得其计划不错。7日，BAG批准第一阶段测试。小明在8日开始测试，发现不少细节问题，并一一修正，在13日表示一切问题都已解决。BAG于是在14日批准第二阶段测试。小明在15-18日测试，再没有问题出现，同时社群也没有反对意见。BAG最终在21日正式批准申请。
在“第一阶段测试”发现问题是正常的，而“第二阶段测试”则预期BOT已能够正常运作，只是给予社群足够的时间检查是否有遗漏的错误。--Temp3600（留言） 2017年2月1日 (三) 10:35 (UTC)回复
  赞-和平、奋斗、救地球！（留言） 2017年2月1日 (三) 11:26 (UTC)回复
当然，如果在第二阶段发现新问题，测试阶段自然需要延长，甚至重新进行第二阶段测试。--Temp3600（留言） 2017年2月2日 (四) 09:11 (UTC)回复
没有大的意见。只是这一条“半年不参与机器人事务，则标记为不活跃用户”。私觉得在没有专用日志可以过滤的情况下，要人为判定这点似乎得付出很大工作量（得逐条检查用户的发言记录）；和回收的那一点权力（实际上只是咨询权而非执行权）相比，判定花费的人力可能不太划算。--菲菇＠维基食用菌协会 2017年2月2日 (四) 05:07 (UTC)回复
这一点可以再改松一点。不活跃标记主要是用来提示申请人可以找那些活跃用户帮忙。我觉得"感觉"他有一段时间不活跃，对用户页提醒一下，如无回应就可以标成不活跃了。--Temp3600（留言） 2017年2月2日 (四) 09:11 (UTC)回复
诚邀@Antigng、Kanashimi、Black9869184、WilliamSkyWalk、A2093064：前来参与讨论。--Temp3600（留言） 2017年2月2日 (四) 18:39 (UTC)回复
诚邀@Shizhao、Stang、Liangent、小躍：前来参与讨论。(以上各位为本年度的BOT申请者。)--Temp3600（留言） 2017年2月2日 (四) 18:45 (UTC)回复
@Temp3600：要算几天才无回应？--水中捞跃 2017年2月3日 (五) 05:46 (UTC)回复
@小躍：唔...两个星期?@PhiLiP：觉得两星期够吗?--Temp3600（留言） 2017年2月3日 (五) 07:45 (UTC)回复
足够了。--菲菇＠维基食用菌协会 2017年2月4日 (六) 08:42 (UTC)回复
@Temp3600：究竟是要“涷结”？还是要“冻结”？--水中捞跃 2017年2月4日 (六) 08:58 (UTC)回复
这只是打错字吧...私以为是"冻结"。--Temp3600（留言） 2017年2月4日 (六) 09:02 (UTC)回复
  1. “投票期约一星期”和“提问期一星期”不妨合并。
  2. “申请测试许可”期不需要这么长，个人认为3天就行。
  3. 这个投票建议参考监管员的选举，即提问期在投票器以前开始，如果提案人“希望给予申请人足够的时间回答问题”的话。以上。-- Stang 124 2017年2月5日 (日) 01:19 (UTC)回复
  1. 投票期和问答期是同时开始的，只是问答期比投票期更早完结。如果想改成问答期比投票期早一点开始也可以。
  2. 翻查英文版，“申请测试许可”期常只有一天，故同意缩短。--Temp3600（留言） 2017年2月5日 (日) 10:13 (UTC)回复
四个阶段只是建议/常规流程吧？从目前申请的bot案例看，大多数都不必第二阶段测试--百無一用是書生 (☎) 2017年2月17日 (五) 03:53 (UTC)回复
如果机器人在第一阶段测试时没有任何出错，自然可跳过第二阶段测试。--Temp3600（留言） 2017年2月17日 (五) 06:22 (UTC)回复

投票权认定

对AWB用户(在checkpage有名字的用户)，可以让他们投半票。投票通过票数维持五票。大家意下如何?--Temp3600（留言） 2017年2月2日 (四) 09:13 (UTC)回复

“管理员如要使用AWB，可将自己的用户名列入”。这是否意味着管理员都可以投半票？-- Stang 127 2017年2月2日 (四) 10:12 (UTC)回复
技术上而言，是。我只能希望管理员能自律，只在确实熟悉AWB的情况下才投票。--Temp3600（留言） 2017年2月2日 (四) 13:52 (UTC)回复
个人觉得不是AWB问题，而是bag的人选是否对信息技术和编程有一定的了解。所以我的粗浅看法是满足两条即可：1.对信息技术和编程有一定的了解；2. 对方针指引比较了解。--百無一用是書生 (☎) 2017年2月3日 (五) 03:10 (UTC)回复
@Shizhao：社群中任何编者都可以参选bag，然而，我希望获选的BAG得到本地机器人社群的认可，所以在投票权加上了限制。--Temp3600（留言） 2017年2月3日 (五) 07:40 (UTC)回复
BAG由行政员审核如何？投票只用于表达意见而不用于计算票数。 --达师 - 345 - 574 2017年2月5日 (日) 10:04 (UTC)回复
这样会大幅降低BAG的认受性啊...我相信获得本地机器人社群的认可是BAG的条件之一。--Temp3600（留言） 2017年2月5日 (日) 15:57 (UTC)回复
我是指类似于存废讨论的安排。不拘泥于票数而只考虑共识的达成。 --达师 - 345 - 574 2017年2月6日 (一) 17:49 (UTC)回复
类似于现在GR，GS产生方式。-- Stang 122 2017年2月7日 (二) 01:18 (UTC)回复
那将最低支持票改为最低讨论参与人数如何?--Temp3600（留言） 2017年2月7日 (二) 05:14 (UTC)回复
也可以。--William is Wikipedia! 2017年2月7日 (二) 08:44 (UTC)回复

正式提案

草稿:Wikipedia:机器人方针已经翻译完毕。中文现行方针已合并到相应的章节，而过时的部分则顺便取消。上面讨论的审核小组产生办法尚未加进去－我在想应放到那儿。本版本主要供各位检查有否重大错误之处。--Temp3600（留言） 2017年2月7日 (二) 20:49 (UTC)回复

放了到WP:BAG--Temp3600（留言） 2017年2月14日 (二) 06:46 (UTC)回复
本更新除设立BAG外，亦包括以下修改:
新增部分:

1.明确定义机器人、半自动编辑、脚本
2.要求机器人以assertion功能防止未登入时编辑

solved
这个为何是必须的？--百無一用是書生 (☎) 2017年2月8日 (三) 06:52 (UTC)回复
防止未登入时编辑。我留意到assertion extension已加入mediawiki中，如果中文版没有此问题可取消本条。 --Temp3600（留言） 2017年2月8日 (三) 07:19 (UTC)回复
(－)反对，我有无数种方法防止未登录编辑，比如当token="+\"的时候立即终止进程，根本没有强制assertion的必要。--Antigng（留言） 2017年2月8日 (三) 14:33 (UTC)回复
虽然我现在也在用assertion，但还是(－)反对这条，没必要限制具体的实现方法。(＆)建议改成推荐。 --砜中嘌呤的白磷萃取 打谱 2017年2月8日 (三) 14:46 (UTC)回复
再举个例子，封禁User:10.68.0.0/16（目前已经被封禁）即可阻止Tool Labs的机器人未登入编辑，用不着这么啰嗦。--逆袭的天邪鬼（留言） 2017年2月8日 (三) 14:50 (UTC)回复

3.要求机器人输出的讯息(如编辑摘要)能被普通用户明白，及要以礼貌语气书写
4.要求机器人在用户页列出工作项目、自动化程度、频率
5.不容许制作以大量下载维基为目的的机器人

(－)反对，这要求有道理但是没有意义，因为只要帐户不往维基百科里写东西，就算他大量下载内容也没有人能发现，管理。就算把这个账户封禁了他也照样能大量下载内容。--Antigng（留言） 2017年2月8日 (三) 14:49 (UTC)回复
不需要提——如果我不希望让你们知道我在通过Bot下载东西的话，我甚至根本不需要注册账号。--逆袭的天邪鬼（留言） 2017年2月8日 (三) 14:50 (UTC)回复
原文为"Bots that download substantial portions of Wikipedia's content by requesting many individual pages are not permitted. "我可能译错了，重点是在取得内容的方法，让我想想怎改... --Temp3600（留言） 2017年2月8日 (三) 16:40 (UTC)回复
见2009年的方针：“bot不能用于与获得批准的bot任务无关的，大量资料的传送。这包括从其他网站动态载入内容，这将导致网站被列入黑名单，并且bot帐号被永久查封。如果你想大量下载内容或镜像这个站点，请从我们的数据库下载。”经过2013年的讨论，这些内容被删掉了。--Antigng（留言） 2017年2月8日 (三) 16:58 (UTC)回复
可是13年的讨论也没有明确反对这一条啊，而且留着也没有坏处。--Temp3600（留言） 2017年2月9日 (四) 11:17 (UTC)回复

6.在用户讨论页发放讯息的机器人应设有拒绝讯息机制

solved
这个在中文版是否已经有完善机制？是否强制？--百無一用是書生 (☎) 2017年2月8日 (三) 06:52 (UTC)回复
至少要设有黑名单。如果有人直接找操作者要求停止发讯，我觉得应予尊重。--Temp3600（留言） 2017年2月8日 (三) 07:19 (UTC)回复
顺便加一个：可以给机器人加入紧急停止功能，但不是必须要加。--逆袭的天邪鬼（留言） 2017年2月8日 (三) 15:01 (UTC)回复
这是强制要求。--Temp3600（留言） 2017年2月8日 (三) 16:40 (UTC)原文是may...--Temp3600（留言） 2017年2月9日 (四) 10:59 (UTC)回复
(？)疑问：我没看到现在的draft里哪有强制要求加入紧急停止功能……管理员紧急封禁这个算吗？ --砜中嘌呤的白磷萃取 打谱 2017年2月8日 (三) 17:28 (UTC)回复
这次提案有数份文件。Draft:维基百科:机器人/申请see here --Temp3600（留言） 2017年2月8日 (三) 17:33 (UTC)回复
嗯嗯了解，那就是要加入{{Emergency-bot-shutoff}}吧，现在的机器人好像都有。 --砜中嘌呤的白磷萃取 打谱 2017年2月8日 (三) 19:49 (UTC)回复
(－)反对强制，不管怎样，都可以直接封禁掉。封禁本身就是紧急停止功能。没必要非得加入一个模板。模板只是更显眼而已，可以推荐使用，但没必要强制--百無一用是書生 (☎) 2017年2月9日 (四) 06:47 (UTC)回复
译错，会改。--Temp3600（留言） 2017年2月9日 (四) 10:59 (UTC)回复

7.机器人应留意{{inuse}}模版机器人应避免编辑冲突

solved
如果目的是防止编辑冲突，单单是{{inuse}}没有大多意义--百無一用是書生 (☎) 2017年2月8日 (三) 06:52 (UTC)回复
可否解释? --Temp3600（留言） 2017年2月8日 (三) 07:19 (UTC)回复
就是说防止编辑冲突不是单单靠{{inuse}}来解决的。只要bot具有防止编辑冲突的机制就可以了--百無一用是書生 (☎) 2017年2月8日 (三) 09:40 (UTC)回复
(－)反对，同上，防止编辑冲突检查timestamp即可实现。--Antigng（留言） 2017年2月8日 (三) 14:39 (UTC)回复
(－)反对，有些条目的inuse挂了几个月都没人理。--逆袭的天邪鬼（留言） 2017年2月8日 (三) 14:51 (UTC)回复

8.规定以自动或半自动方式批量创建条目前必须申请

seems solved
现在中文维基百科似乎是根本不允许批量创建条目，请仔细检查相应的讨论与共识，在完成确认之前(－)反对。--Antigng（留言） 2017年2月8日 (三) 14:39 (UTC)回复
见Wikipedia:互助客栈/其他/存档/2013年2月#模板容量上限现况疑问、Wikipedia:页面存废讨论/记录/2013/02/18#天河公园站--Temp3600（留言） 2017年2月8日 (三) 16:50 (UTC)回复

9.正规化申请上诉/除权程序
10.收紧对adminbot的规定，BAG及管理员有权要求adminbot交出源代码。adminbot必须得到社群的广泛认可才可执行。(i.e. 乏人问津的adminbot申请会失败)

seems solved
必须交出源码有点过分？但是应该强烈建议对所有的bot使用的工具代码开源（尤其运行在labs上的bot，见wikitech:Nova Resource:Tools/Rules）。此外，强制交出源代码在务实上也可能存在困难，比如只是处理任务当中的临时性脚本，随手写的，用完一次就不再用了；比如过程中用到的shell脚本，公开有可能涉及服务器安全；比如使用的第三方现成的闭源工具--百無一用是書生 (☎) 2017年2月8日 (三) 06:52 (UTC)回复
这条只限制adminbot。如果adminbot出错影响很大。而且本条是指BAG有权要求交出源代码，如果BAG认为不需要这样检查，自然可以不交。--Temp3600（留言） 2017年2月8日 (三) 07:19 (UTC)回复
(－)反对，例如寻找开放代理等执行有风险任务的bot不应该（任何人要求都不可以）让任何人知道源代码。--Antigng（留言） 2017年2月8日 (三) 14:29 (UTC)回复
我无法明白。BAG在为受社群信任的维基人，有权知道一切 - 当然，如果BAG接受你的解释的话，可以不查。如果你那么不愿意信任他人的话，为什么你要去写维基呢?--Temp3600（留言） 2017年2月8日 (三) 16:53 (UTC)回复
如果公布源代码，我这个喜欢破坏维基百科的用户就可以简单地改改源码，做到既能用开放代理实施破坏，又不会被发现而招致封禁了。所以不是不信任的问题，而是现在有人在互助客栈方针版威胁你们。（正经话：制造者应该有权不公开源代码，或者仅限于内部传阅，甚至不对任何人公开。adminbot的制造者应该清楚滥用信任的后果。）--逆袭的天邪鬼（留言） 2017年2月9日 (四) 15:43 (UTC)回复
adminbot出错的危害太大，本条的code review权力对此十分重要。连反破坏王牌cluebot都有公开原代码，我想不到中文维基有什么黑科技，一公开就见光死。另外，BAG是得到社群信任的用户。如果adminbot申请人不信任BAG，他就不应该申请机器人了。--Temp3600（留言） 2017年2月9日 (四) 19:46 (UTC)回复
记得en有个封禁开放代理的adminbot由于安全问题不予开源。-- Stang 121 2017年2月8日 (三) 07:24 (UTC)回复
同样，如果bag同意不需交出源代码，自然可以不交。交源代码给bag不等于开源 - bag只可以内部传阅源代码。--Temp3600（留言） 2017年2月8日 (三) 07:39 (UTC)回复
认可。不过希望“有权要求交出源代码”改的口气较为柔和。-- Stang 121 2017年2月8日 (三) 07:43 (UTC)回复
"It is recommended that the source code for adminbots be open, but should the operator elect not to do so, they must present it for review upon request from any BAG member or administrator."原文用了must，我在想应怎样翻译较好。--Temp3600（留言） 2017年2月8日 (三) 10:42 (UTC)回复
直译成“若小组成员要求，必须……”呢？或者试试 RFC 6919 的 "MUST (BUT WE KNOW YOU WON'T)" 吧。[开玩笑的]——Artoria2e5编 保持讨论完整，直接ping我回复。 2017年2月8日 (三) 13:06 (UTC)回复
改了一点，请看看。 --Temp3600（留言） 2017年2月8日 (三) 14:30 (UTC)回复
可以更柔化一些，“有权要求审阅源代码”。这里的重点是用code review来确保代码安全，不是确保代码可分享。--菲菇＠维基食用菌协会 2017年2月9日 (四) 16:06 (UTC)回复
谢谢菲菇，已改。--Temp3600（留言） 2017年2月9日 (四) 19:37 (UTC)回复

11.容许自愿辞职的管理员在社群请求下保留adminbot权限离任管理员可将adminbot转交给其他管理员，让其他管珼员保持该机器人的运作

solved
结合上一条，这种要求表现出来的样子，似乎让人感到我们过于依赖bot了。这样可能会有很大的隐患。人的工作被bot限制住了，没了bot难道就做不了事情了？--百無一用是書生 (☎) 2017年2月8日 (三) 06:52 (UTC)回复
这条发动的机会同样十分低。但如果一名受信任用户因私人理由辞职而要求adminbot退役，是社群的损失。--Temp3600（留言） 2017年2月8日 (三) 07:19 (UTC)回复
(－)反对，安全隐患。不过完全可以由另外一个有资格运行adminbot的人运行（即所有权转交）。-- Stang 121 2017年2月8日 (三) 07:46 (UTC)回复
好吧，如果再有其他人反对这项，我就把它取消掉。--Temp3600（留言） 2017年2月8日 (三) 10:32 (UTC)回复
同意转交的方案。 --达师 - 345 - 574 2017年2月12日 (日) 10:26 (UTC)回复
OK，已改。--Temp3600（留言） 2017年2月14日 (二) 06:35 (UTC)回复

12.对多人共用的机器人作出规定
13.新增活跃度要求:如机器人及操作者两年没有编辑，机器人会被除权。设有一星期的通知期。

seems solved
Wikipedia_talk:机器人#.E8.AE.BE.E7.AB.8B.E6.9C.BA.E5.99.A8.E4.BA.BA.E9.99.A4.E6.9D.83.E6.9C.BA.E5.88.B6。-- Stang 121 2017年2月8日 (三) 07:26 (UTC)回复
@Stang：看了讨论，但仍不明白情况如何麻烦。请指教。 --Temp3600（留言） 2017年2月8日 (三) 07:31 (UTC)回复
“一大堆iwbot的操作者都不在本地，应该不需要扩展到全域编辑数吧？--Jimmy Xu 论 2016年5月13日 (五) 16:08 (UTC)”。另未收到提及。-- Stang 121 2017年2月8日 (三) 07:39 (UTC)回复
另，应opt-out掉系统帐户。-- Stang 121 2017年2月8日 (三) 07:42 (UTC)回复
取消部分:
  1. 容许就所有任务申请adminbot，但须有广泛共识
  2. 取消向监管员要求授权的安排。除global bot外都需经bag审批

--Temp3600（留言） 2017年2月8日 (三) 04:20 (UTC)回复

讨论

(为方便讨论，我可能移动你的留言。如果你反对的话，请告诉我。)--Temp3600（留言） 2017年2月8日 (三) 10:23 (UTC)回复

inuse, adminbot code review
seems solved
  • (？)疑问：
    • “机器人应留意{{inuse}}模版”，怎么“留意”呢，永远不编辑带inuse的页面吗？另外现在的API有两个参数是开始编辑的时间戳和编辑时上一版本的时间戳，这两个参数填对就能防止冲突，所以好像没什么必要特别留意inuse模版？如果要防编辑冲突，可以要求机器人的编辑均需加上那两个参数，讨论页新开话题除外（因为永远不会冲突）。
    • “如果机器人依赖一些不公开的规则来运行（如利用一连串正则表达式来决定行动），审核小组组员及管理员有权要求机器人操作者提供该等规则供审阅。”正则表达式为什么是不公开的规则……按我的理解是不是要把正则表达式的匹配规则用白话解释给BAG和管理员？
    • 交出源代码的问题，例如A要求后向他交出了代码，如果后来这代码经过了或大或小的修改，是否必须要向A重新发送？
  • 以上。 --砜中嘌呤的白磷萃取 打谱 2017年2月8日 (三) 04:57 (UTC)回复
    • 原文为“If the bot operates upon additional rules (such as lists of regular expressions applied in a particular decision-making process) that are not publicly visible, the bot operator should make these available to any BAG member or administrator upon request”。因此“不公开的额外规则”指的应是正则表达式等规则本身没有公开的情况。——Artoria2e5编 保持讨论完整，直接ping我回复。 2017年2月8日 (三) 05:01 (UTC)回复
(：)回应留意{{inuse}}模版指如机器人发现有2小时内挂的inuse模版，不应作任何编辑，以避免编辑冲突
Artoria2e5已解释“不公开的额外规则”。这是确保机器人运行时所有有关代码都得到审阅，不能弄黑盒。
白磷是指申请期间修改还是申请成功后再作修改?
--Temp3600（留言） 2017年2月8日 (三) 05:08 (UTC)回复
注：目前按照 sec 3.1.1 "在不经批准下合法运行的条件" 处理的话，小修改应不需要交出。我的建议是建议adminbot用户主动提交，同时允许小组成员做出明示的“每次都提交”要求。提交最好包含历史。——Artoria2e5编 保持讨论完整，直接ping我回复。 2017年2月8日 (三) 05:15 (UTC)回复
小修改可不用交出，除非BAG明文要求。至于具体个案的提交形式，我觉得可由BAG自行决定。 --Temp3600（留言） 2017年2月8日 (三) 09:13 (UTC)回复
但是是不是可以假设“使用完毕或暂时不再编辑时”，加入模版者会“删除这个标签”，所以可以直接看到inuse的页面就不管。 --砜中嘌呤的白磷萃取 打谱 2017年2月8日 (三) 05:21 (UTC)回复
嗯嗯，这依靠挂inuse的用户自律了。--Temp3600（留言） 2017年2月8日 (三) 09:15 (UTC)回复
弄个机器人去维护啊，Category:被搁置的条目。--A2093064#Talk 2017年2月8日 (三) 12:48 (UTC)回复
有些条目的inuse挂几个月都没人理，所以不能指望用户自律。--逆袭的天邪鬼（留言） 2017年2月8日 (三) 14:54 (UTC)回复
嗯嗯，总之我还是(－)反对这个，如我所述用timestamp判断就行，后者是这个的超集。 --砜中嘌呤的白磷萃取 打谱 2017年2月8日 (三) 14:58 (UTC)回复
呜，我认错。为什么有那么多人喜欢乱挂inuse啊...--Temp3600（留言） 2017年2月8日 (三) 17:01 (UTC)回复
（跑题）因为很容易忘记拿掉嘛……如果规定忘记拿掉的人会被自动永久封禁，肯定就没人用这模板了。[开玩笑的] --砜中嘌呤的白磷萃取 打谱 2017年2月8日 (三) 17:35 (UTC)回复
    • 我认为代码修改的复核，没必要每次都复核，除非代码修改导致与原来所申请的任务有很大的不同才可能有必要复核（有时候可能已经都变成了一个新任务了）。这个不应该规定太严格，可以宽松一些，如何判断交由BAG来处理。另外我认为不需要提交代码给谁，鼓励代码开源就足够了（在半自动编辑指引章节，也有说“与机器人一样，我们鼓励，但不强逼创造者公开工具的源代码。”）--百無一用是書生 (☎) 2017年2月8日 (三) 06:52 (UTC)回复
bot max speed
solved

No objection. The six per minute rule is already ignored in many cases anyway. I would suggest though that fast should not be the default bot rate, but rather than bots be allowed to push the speed limit only if there is an argument for why faster editing is useful. For example, bots that response to user actions (e.g. antivandal) might be able to do more (assuming any of them are in fact obeying a 10 second rule right now), but on the other hand things like adding dates to tags can be completed at a leisurely pace, since it doesn't really matter if the run takes 10 hours or 2. And if there should be a problem, slower is still better. So, yes higher speed seems fine, when necessary/useful. Dragons flight 19:22, 21 February 2007 (UTC)

The intent of restricting edit speed is a.) so as not to overload the servers, which isn't as much of a concern now that the maxlag parameter exists and is (I believe) used by AWB, and b.) if there might be any possible problem with the task, so it can be caught in time to stop and revert before too much damage is done. 3-4 edits a minute is a restriction, in my opinion, beyond the bot policy's remit. If you're making semi-automated edits, just make sure you're checking all of them and you're fine. That being said, AWB's restrictions may be more stringent than those of the bot policy so if your question is specific to them you should ask at WT:AWB or the like. Cheers, — madman 04:34, 17 September 2012 (UTC)

@Antigng：可以看看英文版为何立下这条规定。 --Temp3600（留言） 2017年2月8日 (三) 17:16 (UTC)回复
第二段主要针对AWB？ --砜中嘌呤的白磷萃取 打谱 2017年2月8日 (三) 19:53 (UTC)回复
@WhitePhosphorus：你读坏了。第一个人是说必要的时候可以申请加速，但是大部分事情都没那么急。第二个人列出了当时这么做的两个理由：一是之前提到的服务器性能原因，现在已经不是问题（AWB等程序可以测量卡顿）；二是出错了来得及停下。——Artoria2e5编 保持讨论完整，直接ping我回复。 2017年2月9日 (四) 00:38 (UTC)回复
嗯嗯，熬夜熬傻了。 --砜中嘌呤的白磷萃取 打谱 2017年2月9日 (四) 02:26 (UTC)回复
@Temp3600：，这些只能证明为什么bot需要一个速率上限。然而为什么这个上限是0.2req/s则完全没有论证。以我自己的bot为例，现在在过滤器的限制下速率上限是1req/s，我也没有发觉有任何问题。而且一旦bot出故障，这个速率限制已经能够拦下绝大多数的问题编辑了，见过滤器日志。--Antigng（留言） 2017年2月9日 (四) 01:04 (UTC)回复
@Antigng：这多少是原则问题了。你认同英文方针中“The urgency of a task should always be considered; tasks that do not need to be completed quickly (for example, renaming categories) can and should be accomplished at a slower rate than those that do (for example, reverting vandalism).”一句吗?--Temp3600（留言） 2017年2月9日 (四) 03:54 (UTC)回复
这是很显然的，根据常识也可以知道。比如Cluebot的速率上限是9000req/min。--Antigng（留言） 2017年2月9日 (四) 04:01 (UTC)回复
见Wikipedia_talk:机器人#.E6.93.8D.E4.BD.9C.E9.A2.91.E7.8E.87：“现有的WP:机器人#节约资源一段已经严重过时，那些限制显然太高了，对于机器人的编辑频率，应当不作出强制限制。如果的确影响到了服务器的性能，我相信系统管理员会联系相关用户，或直接作出相应的处理。对于未获得权限的账户（如试运行期），大量编辑限制在1分钟5次如何（当然如果只是一小部分的编辑，比如只改十来个页面，可以不必限制）？”--Antigng（留言） 2017年2月9日 (四) 04:07 (UTC)回复
这是程度的问题。为了遵从比例原则，那些不紧急的项目应如何"慢"呢? --Temp3600（留言） 2017年2月9日 (四) 04:12 (UTC)回复
所谓慢不应该是“为慢而慢”，快也不应当是为快而快，而是要综合考虑服务器的承载能力和任务的易错程度以后再判断应当使用何种速度。容易错的任务，比如创建重定向，可能出错需要人查，缩小较大的图片，可能把长截图缩成棍子，也需要人检查。这种情况下，就算1分钟1个，24小时不间断就是1440个，人也查不过来，还是快。然而批量移除已删模板，在处理之前查一下链入页面就可以保证没有错，就算1分钟跑完100个页面也不嫌快。一刀切地上限0.2req/s没有道理。--Antigng（留言） 2017年2月9日 (四) 04:20 (UTC)回复
要是如此，只好将决定权交给BAG逐案判断了。--Temp3600（留言） 2017年2月9日 (四) 11:02 (UTC)回复
@Antigng：但是我总得写个一般参考值... --Temp3600（留言） 2017年2月9日 (四) 11:07 (UTC)回复
如果没有从技术角度来论述为什么是“应该是xx req/s”，那么最好不要写具体数值，只留一些模糊的语句（例如“编辑频率要综合考虑服务器的承载能力和任务的易错程度”），以免留下“外行指挥内行”的印象。--逆袭的天邪鬼（留言） 2017年2月9日 (四) 16:02 (UTC)回复
好吧，改了。BAG判断吧。--Temp3600（留言） 2017年2月9日 (四) 19:54 (UTC)回复
文辞修正
solved

“在过往，批核过程和获得机器人权限是分开的；并不是所有获批的机器人都有权限。这是由于有些机器人的编辑不应从最近更改中隐藏。现在由于用户可选择在最近更改显示机器人编辑，这情况已不再出现。”一直没太明白说这个的原因是什么？无论en，还是c区，直到现在仍然有很多未获bot权限的bot。尤其是C区，大部分用来上传的bot都没有bot权限。有时不仅仅是“有些机器人的编辑不应从最近更改中隐藏”，而是希望有更多的人看到bot的编辑（例如大部分上传bot，希望能有人类编辑来给它上传的文件进行进一步整理；例如User:CommonsDelinker，希望人类能发现到被错误删除或替换的图像；例如User:RonaldB，希望能有更多用户看到OPD的更新）--百無一用是書生 (☎) 2017年2月8日 (三) 07:12 (UTC)回复

现在本地还存在没有bot flag的机器人吗? --Temp3600（留言） 2017年2月8日 (三) 09:54 (UTC)回复
上面列的两个都是啊。-百無一用是書生 (☎) 2017年2月8日 (三) 15:30 (UTC)回复
这个有点麻烦，让我想想--Temp3600（留言） 2017年2月8日 (三) 17:49 (UTC)回复
"现在由于用户能在最近更改显示机器人编辑，一般获准的机器人都会获得权限，除非申请者主动表示不要权限。”如何? --Temp3600（留言） 2017年2月9日 (四) 05:14 (UT
这点当然如此。BAG只是有权内部传阅adminbot的代码作审核之用，而非对外发布。可能弄个private repositories吧--Temp3600（留言） 2017年2月9日 (四) 11:11 (UTC)回复
用户在机器人申请书中，可标明自己不需要机器人权限。--Temp3600（留言） 2017年2月9日 (四) 11:13 (UTC)回复
bag应该可以根据情况，灵活判断需不需要给bot权限，即使用户标明自己不需要机器人权限，bag也应该有权要求用户必须有blog权限--百無一用是書生 (☎) 2017年2月9日 (四) 12:07 (UTC)回复
同意，已改--Temp3600（留言） 2017年2月9日 (四) 19:59 (UTC)回复
不服重审
solved

@Temp3600：原方针中说：“在经过一段时间的讨论后，行政员将根据社群共识批准或拒绝申请。对于已拒绝的申请，申请者仍然可以陈述自己的观点，要求作出决定的行政员或其他行政员重新考虑授权，或重新提出新的申请。但在社群共识明显的情况下，申请者应该避免扰乱性的申诉。”请问在实行BAG后，如申请者不服，如何请求重审？-- Stang 119 2017年2月10日 (五) 04:10 (UTC)回复

用户可于Wikipedia:机器人/申请#申请复核提出，由另一位BAG成员复检。如果情况特殊，可能需要社群全体的参与。--Temp3600（留言） 2017年2月10日 (五) 04:44 (UTC)回复
几个小问题
  1. “然而，如果操作者能证明机器人不会出错（如将所有要修改的项目先试运行一次）”，何谓“所有要修改的项目先试运行一次”？所有要修改的项目都跑完一遍了也不用申请了，因为都改好了:P
  2. “跨语言链接机器人应停止运行”，是否需要明确定义何谓“跨语言链接机器人”以避免争议？
  3. “更简单的方法是逐少创建条目，或先在各属专题的子页面创建条目，由其他编辑检查后，再移动到条目空间。这些方法不用申请机器人，也更容易得到社群的支持”，如果是条目“先在各属专题的子页面创建”的批量创建，还是会造成最近更改的洗版吧？那Draft呢？
  4. “如机器人账号及其操作者最近两年没有编辑”，是“且”的意思嘛？
  5. “所有行政员都自动成为小组的一员”，那么有无需要名列成员名单中？或者给个连结就好？

以上。希望能厘清一下规则以避免日后可能的争议。-和平、奋斗、救地球！（留言）欢迎加入维基Telegram群 2017年2月16日 (四) 09:01 (UTC)回复

“试运行”指在自己的用户子页模拟运行所有修改一次。社群不容许机器人未获得许可时直接在条目页面运行，所以“所有要修改的项目都跑完一遍了也不用申请了，因为都改好了”并不会出现-根本连测试许可都不会批出，这类工作直接拒绝之。
可略改为目前方针中“维护跨语言链接的机器人”，并加上到Help:跨语言链接的连接。
“先在各属专题的子页面创建”页面的确会洗版，正如在用户子页批量创建一样。但批量创建无可避免会洗RC，在专题洗已是较容易管控的方法。Draft不方便条目的集中管理。而且本条希望批量创建者能得到专题的同意和帮助，尽力保证该批条目的质量。
“如机器人账号及其操作者最近两年没有编辑”is both bot account and its operators.
我没有所谓。为方便管理，可不列入，仅给连结。
--Temp3600（留言） 2017年2月16日 (四) 09:34 (UTC)回复
  1. 跨语言链接部分，应否排除“出现在正文中的连结”部分，因为那应和本条立意无涉。
  2. “本条希望批量创建者能得到专题的同意和帮助”，如何定义“得到专题的同意”？毕竟本地目前很多专题都只有1,2个人在维护、甚至没有活跃者。很多也无法明确定义“专题成员”。-和平、奋斗、救地球！（留言）欢迎加入维基Telegram群 2017年2月16日 (四) 10:01 (UTC)回复
第一项位置不明，请给出上下文。第二项采半强制性质-如果您觉得专题无用，也可以在自己的用户子页进行，但我相信有关的专题编辑已经是最可能有意愿协助检查条目的人了。“得到专题的同意”指部分该类条目的编者可能反对批量创建，如果无法取得他们的同意，应停止批量创建。--Temp3600（留言） 2017年2月16日 (四) 10:09 (UTC)回复
第一项位于Help:跨语言链接。第二项的部分，技术上BAG成员如何确认有关的专题编辑同意与否？-和平、奋斗、救地球！（留言）欢迎加入维基Telegram群 2017年2月16日 (四) 10:13 (UTC)回复
跨语言链接机器人指的是interwikibot，至少在wiki的英文语境下没有歧义。个人认为批量创建至少应该申请bot任务批准后才运行（至于是否要bot flag则视情况而定）。“如将所有要修改的项目先试运行一次”这只是举例吧？并不是所有的任务都能全都先试跑一遍的，甚至有的任务并无跑一遍这种概念。而且基于软件工程自身的基本特点，谁也无法保证机器人不会出错--百無一用是書生 (☎) 2017年2月17日 (五) 04:13 (UTC)回复
第一项，我并不可能为了机器人而修改Help:跨语言链接-那页面为非为机器人事务而设。第二项，证明自己的机器人任务得到社群支持的责任在于申请者。提案者可附上专题的讨论页面连结，方便审核小组判断。如将所有要修改的项目先试运行一次”是针对上下文修改很可能出错，而增设的特殊规则。--Temp3600（留言） 2017年2月17日 (五) 06:17 (UTC)回复
并非修改Help:跨语言链接，而是在机器人方针说明清楚。例如说可以将“除非该工作无法在维基数据上进行（如连结到某一分段）”这句写清楚成“除非该工作无法在维基数据上进行（如连结到某一分段、以及出现在正文中的连结）”-和平、奋斗、救地球！（留言）欢迎加入维基Telegram群 2017年2月17日 (五) 06:41 (UTC)回复
唔...有机器人是在处理正文中的跨语言链接吗?--Temp3600（留言） 2017年2月17日 (五) 10:54 (UTC)回复
有。例如User:Cewbot。-和平、奋斗、救地球！（留言）欢迎加入维基Telegram群 2017年2月18日 (六) 10:47 (UTC)回复
OK，已改。--Temp3600（留言） 2017年2月19日 (日) 05:14 (UTC)回复
  赞-和平、奋斗、救地球！（留言）欢迎加入维基Telegram群 2017年2月19日 (日) 05:27 (UTC)回复

提案通过

最近数天已无讨论。如果社群没有新意见，我在此提出:

统一通过草稿:维基百科:机器人/申请、草稿:Wikipedia:机器人审核小组、草稿:Wikipedia:机器人方针及其附带文件。

七天之内如无反对意见，视作正式通过。 --Temp3600（留言） 2017年2月14日 (二) 10:36 (UTC)回复

我实在不懂地区转换，如有需要，望请其他用户协助。--Temp3600（留言） 2017年2月15日 (三) 06:42 (UTC)回复
就我这里的观察来看，应该已经有全局转换了，不需要额外增加转换。倒是挂上G1=IT可能有点用。 --达师 - 345 - 574 2017年2月16日 (四) 10:19 (UTC)回复
哈哈，加了过后“当机”被转成“死机”于是zh-cn下傲娇地显示成了“死机械人”……（已修复）—菲菇＠维基食用菌协会 2017年2月19日 (日) 01:31 (UTC)回复
thx for your help.--Temp3600（留言） 2017年2月19日 (日) 13:04 (UTC)回复

容许长期没有讨论的WP:BRFA进行测试

最新留言：在6年前发布3条留言3人参与讨论

本主题或以下段落文字，存档自Wikipedia:VPP。执行人：——Aotfs2013 留于 2017年12月28日 (四) 18:42 (UTC)。回复

目前有部分WP:BRFA申请案长期(>28天)没有其他用户参与讨论。这对审核小组的判断构成了一定困难。

为此，建议增加到期条款，如果某项申请一个月后仍没有任何回应，加上早前已提案到互助客栈上邀请社群发表意见，而没有任何反对，则审核小组可以直接批出测试期，由测试的结果决定社群是否需要该bot。

添加话题
检索自“https://zh.wikipedia.org/w/index.php?title=Wikipedia_talk:机器人/申请&oldid=60980424”
返回到项目页面“机器人/申请”。