维基百科

维基百科讨论:机器人方针/存档一

< Wikipedia talk:機械人方針
Jimmy-bot在话题“对维基百科:用户页、维基百科:机器人方针及相联页面的合并更新”中的最新留言：4年前

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

最新留言：在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)
      • 我认为需要多严格的CODE REVIEW应由BAG需决定。但BAG应保留权力，在必要时审阅adminbot的代码。只有adminbot才有这项额外规定，可算是为防万一的措施。--Temp3600（留言） 2017年2月8日 (三) 09:38 (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)

修订机器人方针，增加使用https的建议

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

本主题或以下段落文字，移动自Wikipedia:互助客栈/方针。执行者：Jimmy-bot（留言） 2017年3月3日 (五) 08:42 (UTC)。


维基百科的机器人账号可能用于持续、大量编辑，理应比普通账号获得更多安全保证，在登录凭据被盗时做出的封禁处理也应加速执行。HTTPS是广泛使用的传输层加密手段，WMF于2015年6月中旬开始强制执行HTTPS，对于普通HTTP网页访问执行跳转。然而现时一些用户（好吧，User:Antigng）使用的机器人程序仍然全局使用未经加密的HTTP，甚至通过X-Forwarded-Proto:https绕过跳转，这几乎是在玩火。（好在Antigng似乎是在wmflab上运行这东西，暂时没有什么有人搞鬼的担忧。）

基于以上考虑，我提议在2.1“机器人账号”一章加入以下段落：

机器人操作者有责任通过各种手段保证机器人账号的安全。操作者应及时报告疑似被盗情况，并使用HTTPS加密API登录、操作。

——Artoria2e5编 保持讨论完整，直接ping我回复。 2017年2月21日 (二) 02:38 (UTC)

去年6月wmf把我利用的这个漏洞补上了，所以我早就不在wmflabs上使用明文HTTP工作了。现在我的bot在本地，通过正向代理将HTTP请求转为HTTPS以后发送给wmf的服务器。--Antigng（留言） 2017年2月21日 (二) 04:42 (UTC)
考虑到可能有人想得出跨着大老远用 HTTP 代理，先继续留着HTTP这条吧……（我下一个想玩的是 malformed html/template，或者 buffer overrun）——Artoria2e5编 保持讨论完整，直接ping我回复。 2017年2月21日 (二) 07:45 (UTC)

机器人与自动驾驶

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

本主题或以下段落文字，移动自Wikipedia:互助客栈/方针。执行者：Jimmy-bot（留言） 2017年6月29日 (四) 08:42 (UTC)。

最近维基百科上出现多次维基人操作的机器人出问题而无回应的情况，提报多日，均未解决。事故机器人的两位操作者皆为不活跃的维基人。有些问题（例如误将WP:关注度/提报当作编辑站提报的）可以手动回退，有些问题（例如出错大量合理使用图片）被用过滤器解决，还有些问题（Adminbot 未经机器人授权封禁代理 IP）普通用户则无法动手修复；需要人力去回退和写过滤器为机器人擦屁股本末倒置，失去一开始使用机器人的理由。

上述问题有部分已经被发现好一段时间。若普通用户长时间进行非建设性贡献，多半早已被封禁。目前因为机器人有其他贡献无法对其进行封禁，但私以为因为用户有重大贡献而采用双重标准，是不合适的行为。

机器人方针不要求操作者开放与授权源代码，所以无法直接请懂技术的人接替不活跃操作者的机器人。既然现在已有依赖机器人又联系不上操作者的情况，是否应该修改机器人方针，以避免日后有更多架机长休克仍在驾驶的飞机？Dargaseat ‧ c ‧ s 2017年6月17日 (六) 08:31 (UTC)

说起来倒是有一个方法可以缓解这个问题，就是不同任务分成不同账号编辑，方便封禁和回退。如果是一个账号，最好能提供每个任务单独的开关。 --砜中嘌呤的白磷萃取 打谱 2017年6月17日 (六) 13:23 (UTC)
可以用滥用日志作出控制，无需用到封禁的程度，封禁不是为了惩罚，除非用了滥用日志，而错误的编辑还是一直出错，则予以暂时封禁以作处理。--小跃（捞出记录） 2017年6月17日 (六) 14:22 (UTC)
Jimmy-abot和Liangent-bot虽然看起来出错多，但依总贡献比例来算很低，绝大多数的编辑还是有利的，支持编辑不同开分操作，甚至编辑长期不再时授权源代码。--Zest 2017年6月17日 (六) 14:29 (UTC)
@小躍：我倒是想说冲刷滥用过滤器日志的问题。--A2093064#Talk 2017年6月17日 (六) 15:35 (UTC)
@蘭斯特：否定贡献比例说法，应依照每个任务各自计算错误率，做个夸张的比喻，假设我有1000个任务，其中一个任务错误率100%，这样能被接受吗？--A2093064#Talk 2017年6月17日 (六) 15:35 (UTC)
我的意见是指像Liangent-bot的重定向，少数会出错，大致上没问题，至于其中一个任务错误率100%，就有问题，所以支持编辑不同开分操作，以便管理。--Zest 2017年6月17日 (六) 16:06 (UTC)
如果你的意思是"A-bot必须开源"，我倒是十分赞成，不过估计通不过就是了...--Temp3600（留言） 2017年6月17日 (六) 18:09 (UTC)
如果编辑过于频繁，AF是会宕掉的--百無一用是書生 (☎) 2017年6月19日 (一) 02:04 (UTC)

修改机器人方针

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

本主题或以下段落文字，移动自Wikipedia:互助客栈/方针。执行者：Jimmy-bot（留言） 2017年8月28日 (一) 08:42 (UTC)。

此增修内容原为逆袭的天邪鬼于2017年2月22日（43316532、43316612、43316635、43316697、43316814、43319208）及2017年4月25日（44122868、45318362、44123011）径自追加，嗣后经编辑者本人主动于2017年7月22日撤回“破坏”（45318362、45318349）；然查该修正内容确符中文维基百科习惯且技术上较为可行，故提案修改本（机器人）方针。

现行方针请参照本方针页，而修改草稿请参照本草稿页。由于修改篇幅较大，相关变更内容请参照本比较页，欢迎提出意见。--小火车（留言） 2017年7月28日 (五) 22:03 (UTC)

有种故意习惯成自然的问题，利用没人注意到的可能修改方针，然后过足够长时间被发现的话，可以按照以长久实行无不妥为默许而通过修订。——路过围观的Sakamotosan 2017年7月30日 (日) 01:08 (UTC)
如果真有这种事我又干嘛提出这个修正案？--小火车（留言） 2017年7月31日 (一) 12:19 (UTC)
你说的没错，User:Temp3600不懂装懂，我篡改方针，反正结果都是损毁性的。如果说有什么区别，我的修改用一个撤销按钮就恢复了，而他的修改却不能一个撤销搞定。没关系，反正你们的修订都是通过讨论得出的共识，对就是对，错也是对，敢和社群对着干的都是损毁性编辑。我知道你们最擅长打仗，你们随便，我不跟你们玩，只要我不参与你们能拿我怎么样。--逆袭的天邪鬼（留言） 2017年7月30日 (日) 11:46 (UTC)
所以偷偷改方针是非常麻烦危险的事，天邪鬼别整天搞这种贪得意的无聊行为，既然发现了并取消了，就算了。——路过围观的Sakamotosan 2017年7月31日 (一) 01:27 (UTC)
就修改内容而言，我(＋)赞成本修改，并感谢天邪鬼致力完善方针细节。然而，希望他也明白社群有一定的决策程序，如可能的话，应尽量在程序容许范围内进行修改。--Temp3600（留言） 2017年7月31日 (一) 08:37 (UTC)

由于多日无新回应，公示七日。--小火车（留言） 2017年8月10日 (四) 06:51 (UTC)

由于多日无新回应，本提案视为通过，公告七日后存档。--小火车（留言） 2017年8月18日 (五) 05:55 (UTC)

修改机器人方针

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

本主题或以下段落文字，移动自Wikipedia:互助客栈/方针。执行者：Jimmy-bot（留言） 2017年11月2日 (四) 08:42 (UTC)。

现行条文

===机器人账号===
...略...
此外，机器人账户用户名应包含“Bot”或“机器人”等标记，以资分辨用户及机器人所作编辑。机器人账户用户页上可加上{{bot}}注明。

提议条文

===机器人账号===
...略...
此外，机器人账户用户名应包含“Bot”或“机器人”等标记，否则必须在每个编缉摘要中均加入Bot或机器人等字眼，以资分辨用户及机器人所作编辑。机器人账户用户页上可加上{{bot}}注明。

要每个机器人的用户都必须有Bot的字眼并不合理，其实最终目的也只是分办编缉。怎么就不善用编缉摘要，而必须有用户名要求呢？--Шәτіт🐷0 2017年10月10日 (二) 08:50 (UTC)

(！)意见这可能造成我们必须要解析summary的困难。例如一笔编辑summary为“避免bot重复编辑这个页面”、“机器人出错了 改回来”，那这些编辑可能会被当作机器人的编辑。另外我们也得要考虑到有些时候我们可能仅仅从页面获得使用者名称，之后就要判别使用者的身份、执行某些操作，这样的操作并没有经过检核某个页面编辑纪录的过程，因此也就没有summary可取。这情况下若是没有限制使用者的名称，就比较容易出错误。另外还应考虑机器人没有加上bot flag、还没得到bot flag之申请者的编辑情况，可能连人类都容易误判。 --Kanashimi（留言） 2017年10月10日 (二) 11:41 (UTC)
(！)意见一个用户是否是机器人用户，最终应该还是看是否有 Bot flag （量多，最近更改能过滤）或者是否有机器人申请通过的记录（量少，或许也就不需要单独过滤了）。编辑摘要的话，感觉还是管得太细了一点点 .... Dargaseat ‧ c ‧ s 2017年10月10日 (二) 15:23 (UTC)
“要每个机器人的用户都必须有Bot的字眼并不合理”可否论述不合理的原因？——Aotfs2013 留于 2017年10月10日 (二) 16:05 (UTC)
只是"应"而已，大原则还是bot name能否让人清楚明白。--Temp3600（留言） 2017年10月10日 (二) 17:20 (UTC)
编缉摘要含有bot字眼，有时候也会与人类编辑混淆，例如编缉摘要中为“bot坏了”，不好分辨。--PatrollerAAAA（讨论|留名） 2017年10月11日 (三) 05:16 (UTC)
如有1个未持有机器人权限的人类编辑者提出删除1个由User:Liangent-bot创建的重定向的删除讨论，在该页面加上{{Vfd|这是User:Liangent-bot所创建的重定向，但{{link-en}}的参数出现错误|r|date=2017/11/02}}，但编缉摘要却是“User:Liangent-bot根据{{link-en}}的参数错误创建”，则该人类编辑者不应视为机器人--林勇智 2017年10月15日 (日) 12:27 (UTC)
我觉得要求以机器人为目的的账号含bot字眼确实会有容易分辨的好处。如果这样做法有其他不方便的话，或许可以衡量利弊消除这个规定，但是需要先说明情况——为什么这个要求不合理，造成了什么不方便。否则我想这个要求还是保存着好。Bluedeck 2017年10月23日 (一) 05:12 (UTC)

意见征询︰机器人活跃度门槛

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

本主题或以下段落文字，移动自WP:VPP。执行者：--J.Wong 2018年4月17日 (二) 04:29 (UTC)。

本讨论已经结束。请不要对这个存档做任何编辑。

目前而言，《机器人方针》规定机器人活跃门槛为“如机器人账号及其操作者最近两年没有编辑，其机器人权限可被移除。”翻查纪录，在此除权条件下，有机器人最后编辑时间是零九年，距今几近十年。姑勿论会否引起系统安全问题，机器人长期没动作，而编辑环境其实恒年常变，而机器人审核小组无法定期审核各个机器人操作许可，如此一来该等操作许可会否已经与方针指引或者编辑惯例有所矛盾呢？是故，现请诸位就以下问题发表意见。--J.Wong 2018年3月21日 (三) 06:36 (UTC)

甲、机器人不活跃门槛是否应该继续与操作者挂勾？

如题。而如果操作者活跃，而机器人久未活动，要否重新经过机器人审核小组审核方可重新继续操作呢？--J.Wong 2018年3月21日 (三) 06:36 (UTC)

建议脱勾，重新申请时或许豁免审核比较好。—AT 2018年3月21日 (三) 15:09 (UTC)
应脱勾，但不必豁免审核，反正BAG成员可自行提出无须测试。JC1 2018年3月21日 (三) 16:40 (UTC)
应脱勾，需重新申请，但建议审核小组视情况予以快速批准（若再次运行无任何问题）。--Xiplus#Talk 2018年3月22日 (四) 13:25 (UTC)
应脱勾，需重新申请。--Temp3600（留言） 2018年3月24日 (六) 07:40 (UTC)

乙、机器人不活跃门槛是否继续维持于两年？

如果不建议维持于两年，那多少为之合适？--J.Wong 2018年3月21日 (三) 06:36 (UTC)

与其他权限看齐，建议改为半年。—AT 2018年3月21日 (三) 15:10 (UTC)
存档、维护等机器人于首轮运作后可能要一段长时间才须再次运作，建议至少一年。JC1 2018年3月21日 (三) 16:40 (UTC)

其他

就目前机器人方针活跃度要求，两年不活跃是权限及运行许可一并取消，然而是机器人所有的任务合并计算，再加上操作者是否活跃，若是机器人只执行某一项任务，而另一项任务已有数年没执行，这并不合理。再者，更重要的事情是编辑环境并非永远不变，BAG批准一项机器人任务势必要考量目前的环境能否运行机器人，例如一个长久未执行的存档机器人一天突然执行，但页面的版面架构早已改变，于是将存档搞得乱七八糟，反之，若是一个有持续在运行的机器人，要变更版面架构时，自然会想到有这个存档机器人，便会通知操作者配合做出修改（这只是一个小举例，严重可能是机器人做出大量不恰当编辑后才被发现）。

因此，我认为应该针对每一项任务单独设定一个不活跃自动撤销许可的期限，机器人超过一定期限没有执行这项任务，许可即被自动撤销，然而BAG势必无法定期审视一个任务有没有过久无执行，因此若要有这项规定，应该是操作者在重新执行这项任务时必须自行确认，或者是当任何人发现许可已被自动撤销时，向操作者告知，且操作者应当立即停止运作机器人。要重新运行这项任务时必须重新申请，BAG确认在前次批准的条件下重新运行机器人并无问题时，可给予快速批准。--Xiplus#Talk 2018年3月22日 (四) 13:25 (UTC)

立意虽好，但除非能设立中央数据库集中统整各项permit，否则暂不支持。--Temp3600（留言） 2018年3月24日 (六) 07:43 (UTC)
@Temp3600：这个？--Xiplus#Talk 2018年3月24日 (六) 16:38 (UTC)
可以再写得清楚些。确保及时更新外，对于只有1个permit的机器人，可列出预定过期时间，长远而言则要求在编辑摘要写明在执行那一个任务。--Temp3600（留言） 2018年3月25日 (日) 13:52 (UTC)
@Temp3600：但我上面的说法并非是要BAG或其他人主动定期来审视现有的许可。--Xiplus#Talk 2018年3月31日 (六) 12:41 (UTC)
在我而言这是一个方便性的问题。比如说现实生活中，会有学费单/电费单等提醒你需要到期续约的配套措施。如果要求operator自行记忆每个任务的最后操作时间，我认为过于苛刻。--Temp3600（留言） 2018年3月31日 (六) 16:04 (UTC)
是最后操作时间还是批准时间？批准时间可以列表纪录，但最后操作时间就很困难了，而我想最清楚最后操作时间的应该是操作者本身。--Xiplus#Talk 2018年4月2日 (一) 09:09 (UTC)
倒回来，我想一个合适的机器人操作者对操作环境的改变会有适当的反应，合适则继续操作，不合则重新讨论。当机器人一直运作（其他任务），并于操作者控制之下，由其自行确认，有疑问提出就好。题外话，以前我曾经把已完成的任务划线，结果[1]。JC1 2018年3月26日 (一) 20:43 (UTC)
这个，个人觉得在该操作许可留言，并通知机器人审核小组成员，会是比较好的做法。--J.Wong 2018年3月27日 (二) 03:03 (UTC)
  • 稍为归纳一下︰一、机器人及操作者不活跃门槛应该脱勾；二、机器人门槛则建议由两年降为半年至一年；三、如果机器人久未活跃，需重新申请。机器人审核小组如认为可以，则可快速批准。--J.Wong 2018年4月9日 (一) 14:23 (UTC)

机器人方针修订

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

本主题或以下段落文字，移动自WP:VPP。执行者：--J.Wong 2018年5月1日 (二) 05:24 (UTC)。

本讨论已经结束。请不要对这个存档做任何编辑。

基于上列意见征询结果，建议对《机器人方针》作出以下修订。

现行条文

活跃度要求 如机器人账号及其操作者最近两年没有编辑，其机器人权限可被移除。移除前，应先到操作者的用户讨论页留言，并给予一星期的通知期。如操作者日后回到维基，并希望再次运作机器人，必须重新申请。

提议条文

活跃度要求 如机器人账号最近一年没有编辑，其机器人权限可被移除。移除前，应先到操作者的用户讨论页留言，并给予一星期的通知期。无论操作者是否活跃，如果所持机器人久未活跃，以致权限已经撤销，则必须重新申请操作许可。机器人审核小组成员如认为妥当，则可以快速批准操作。另外，亦建议操作者就机器人各项已批准任务最后操作日期留有纪录，以及如某项任务已经久未进行，就算该项任务已经获得批准，再次运行时仍应留意机器人设定是否与现行编辑环境相配合。操作者如认为某项许可已经再无需要使用，则可于该操作许可留言，并通知任何机器人审核小组成员处理。其他用户如果发现某机器人某项任务已经没有执行超过一年，则可按上列程序要求复核。

  • 一年而非半年，虽然意见征询结果之中，有不少用户认为应该与其他权限看齐，将门槛降至半年。唯当中，有用户指出可能某些任务间隔是会比较长。此可能的确不能轻易排除，是故将期限定为一年。至于意见征询其他一节之中，意见指应该按已批准任务最后操作日期计算，此方向其实可取，惜未能议出具体执行之策，掣肘之处仍然不鲜。今尝折衷而为，鼓励操作者自行保留纪录，并于停搁后，再次执行前，检查是否仍与编辑环境相配合。亦指出操作者可如何申请注销已无用操作许可。及提示其他用户如发现则可以按相关程序申请复核。谨此。--J.Wong 2018年4月9日 (一) 15:53 (UTC)
(＋)支持--Temp3600（留言） 2018年4月12日 (四) 05:46 (UTC)
(＋)支持，较兼顾现实的做法。--Xiplus#Talk 2018年4月13日 (五) 13:25 (UTC)

再三强烈要求规范WP:MASSCREATION

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

本主题或以下段落文字，移动自WP:VPP。执行者：--J.Wong 2018年6月9日 (六) 05:20 (UTC)。

本讨论已经结束。请不要对这个存档做任何编辑。

WP:MASSCREATION要求用户以自动或半自动方式批次创建条目或页面分类前，必须先提出申请。“批次”指50项编辑或以上。你应先到互助客栈及相关专题寻求共识。操作者必须确保所创建的条目符合社群的要求。但在下发现不少用户未能符合以上要求，甚至拒绝沟通，故以在下建议修改MASSCREATION，建立一些基本的要求，并开始严格拆行WP:BOTPOL，请注意：这不是收紧关注度或要求删除旧有条目，而是要求用户及后使用机器人时更为谨慎。

绝大部分情况下，以机器人建立的条目皆没有人维护，故此创建时应订立更高标准。在下建议要求使用机器人创建条目时须符合下列条件，否则停止创建：

我认为必须要有一项参考资料、一导航模板合理，但资讯框并非必需。--【和平至上】💬📝 2018年4月28日 (六) 06:13 (UTC)
没有人说是完整的资讯框，以最近的弗尔克谢什蒂乡为例，单以现有的名称、原名、上级行政区、面积、人口去建立资讯框，完全足够，也无须另外找资料。JC1 2018年4月28日 (六) 06:38 (UTC)
@Yangfl、Justincheng12345： 曾在IRC上多次请求他人对TMBW是否使用了机器人进行评论，但是因为技术限制没有任何依据证实，所以我只能选择AGF。此外，据我所看到的情况，TMBW翻译的来源语种（例如德语、爱沙尼亚语等）早已采用使用直接引用wikidata作为infobox数据显示来源的做法，所以，即使使用翻译工具也不能在源代码里找到资讯框资料来。--云间守望淡出中，有事请发邮件 2018年4月28日 (六) 10:05 (UTC)
“弗尔克谢什蒂乡是罗马尼亚的乡份，位于该国西南部，由戈尔日县负责管辖，面积84平方公里，海拔高度188米，2007年人口3,597，人口密度每平方公里43人。”不论如何，他就是已经取出那些资料了吧？别说创建条目之时有raw data，就算是现在用regex也能提出再放入infobox内吧？另外就是BOTPOL从来没有说一定要某种程式才算机器人，WP:MEATBOT：“在处理争议时，那些编辑是由机器人、使用半自动工具的编者、或是全手动所做并不重要；”JC1 2018年4月28日 (六) 10:35 (UTC)
@Justincheng12345：其取出的系旧的资料，我说明的情况是在于较新的资料其不可能直接由Wikidata摘取出来（技术要求挺高的）。不过讲道理，他这样做确实严重扰乱站务秩序了，而且如果用regex确实能放进infobox去，我承认。（在下曾为该用户擦过屁股，表示深受其害。）--云间守望淡出中，有事请发邮件
话说其实从wikidata取资料很简单了，就以罗马尼亚乡份为例，来这里，然后下载csv就可以了。另外依照wikidata自动更新未必可取，很容易做成内文与infobox不对应。JC1 2018年4月29日 (日) 06:06 (UTC)
(＋)支持：我曾有使用机器人创建条目的计划。但是我也支持以下要求：创建条目时应尽可能确保数据库为最新版本；建立页面填入已创建的条目，方便他人检查及更新；不应当是孤立、未归类、断链页面。--云间守望淡出中，有事请发邮件 2018年4月28日 (六) 11:42 (UTC)

@WQL：，我想了数天强制使用资讯框或许并非完全适合，例如应该使用文中的资料还是最新的资料之类。但想问一下有什么原因让你不支持强制参考资料和导航模板？我相信这两项很简单吧？使用的数据库本身就是一个参考资料，导航模板简单而言也可以把同一省份的某级行政区条目放在一起就好，更何况从英语版抄过来使用翻译连结小工具也是非常容易。JC1 2018年5月3日 (四) 13:40 (UTC)

MASSCREATION第一版

现行条文

以自动或半自动方式批量创建条目或页面分类前，必须先提出申请。“批量”指50项编辑或以上。你应先到互助客栈及相关专题寻求共识。操作者必须确保所创建的条目符合社群的要求。

更简单的方法是减少创建的条目数量，或先在各属专题的子页面创建条目，由其他编辑检查后，再移动到条目空间。这些方法不用申请机器人，也更容易得到社群的支持。

提议条文

以自动或半自动方式批量创建条目或页面分类前，必须先提出申请。“批量”指50项编辑或以上。你应先到互助客栈及相关专题寻求共识。操作者必须确保所创建的条目符合社群的要求。

更简单的方法是减少创建的条目数量，或先在各属专题的子页面创建条目，由其他编辑检查后，再移动到条目空间。这些方法不用申请机器人，也更容易得到社群的支持。

一般而言，除非社群或机器人审核小组提出豁免，由机器人创建的条目须达致以下标准：

  1. 创建条目时应尽可能确保数据库为最新版本
  2. 建立页面列出已创建的条目，方便他人检查及更新
  3. 页面应包含最少一项参考资料及一导航模板
  4. 页面不能为孤立页面、未归类页面、断链页面
(＋)赞成：合理的要求。--【和平至上】💬📝 2018年5月9日 (三) 14:26 (UTC)
完全(＋)赞成：方便巡查（反正我也不会用MASSCREATION）。ŚÆŊMØŠĀ 2018年5月13日 (日) 01:17 (UTC)
(＋)赞成：第三项深得我心。--Temp3600（留言） 2018年5月14日 (一) 16:43 (UTC)
  • 仅反对导航模板。本人的意见是：
    • 第3项：条目应被维基化，应有至少一项参考资料。
    • 第4项：条目不能为孤立页面。
  • 维基化包含添加分类、链接（即避免断链页面）。导航模板不是所有批量建立都有，可能也不是都合适（再举个例子吧，无编号的道路或街巷、立交桥），不应强制要求。反而是考虑到批量建立的条目都依赖于格式化信息，有条件强制要求信息框。 --达师 - 370 - 608 2018年5月14日 (一) 17:55 (UTC)
  • 如果以持有机器人权限的账户建立条目，因为机器人自带巡查豁免（autopatrol），那么建立条目的品质应该跟能获得巡查豁免权的情况看齐？--Xiplus#Talk 2018年5月14日 (一) 23:22 (UTC)
说远一点，遇到这种情况，应要求创建者先弄几个条目出来，大家自然心里有数。问题是:如果有人一来就手动大建特建呢?--Temp3600（留言） 2018年5月15日 (二) 11:56 (UTC)
这几个月还多了IP用户不论条目质量就把孟加拉的条目随意地开，劝止都不听呢。--owennson（聊天室、奖座柜） 2018年5月15日 (二) 16:27 (UTC)
(＋)赞成--Hello903hello 留言·贡献 回复用{{ping}} 2018年5月16日 (三) 08:56 (UTC)

我暂时总结一下，社群主要有以下数项疑虑：

  1. 导航模板是否必须。参考达师和快龙的意见，改为某些条目才须导航模板如何？我认为最起码可以为行政区。
  2. 资讯框是否必须，这个要社群先回答WQL的问题。例如，机器人所使用的数据库与wikidata的有所不同（或者资料陈旧），而某些原因未能全面采用wikidata的资料，那么资讯框的内容应该使用本来的数据库还是wikidata？
    1. 这个问题于其他条目也是同理，若日后有模板可直接从wikidata取得资料，那么可以容许资讯框与内文不对应吗？
  3. autopatrol本来就没有品质要求，只是创建条目数够了就有了
  4. 最后，一直以来未经批准下运行的机器人会立刻封禁，我相信MEATBOT也是同理，当然作为主账号可先作通知或警告。

可以先讨论一下上述数项。JC1 2018年5月16日 (三) 13:05 (UTC)

  • JC1君︰首先，阁下要明白此乃方针，无可能列出所有条目范畴应该如何办，所以可以做的是，改为“建议”。又或者提醒操作者，如所创范畴有导航模板或资讯框就应该加上，而非“必须”。巡查豁免审批是应该也要看质素，看条目质素是否可免于巡查。--J.Wong 2018年5月20日 (日) 03:41 (UTC)
    • WP:VD也是方针，其亦于没有穷举的情况下列出非常多的破坏类型，同理，列出部分应受较多限制的条目范畴为何又有所分别？巡查豁免当然应该要看使用者一向所创条目的质素，但其实每个管理员标准不一，而方针亦只是指“熟知维基方针及指引（特别是生者传记和关注度）的可信赖用户”，根本没有清楚准则。JC1 2018年5月20日 (日) 08:39 (UTC)
    • 两者并不可比。《破坏方针》没能穷列所有情况，与此提案是否应该按实况给予足够豁免，根本完全无关。阁下只要再修改草案，给予足够豁免，其实问题就迎刃而解。--J.Wong 2018年5月21日 (一) 12:46 (UTC)
      • 当然有关，重点就是方针可以在无需穷举之下列出部分应当处理的情况，故此其“无可能列出所有条目范畴”，正如“无可能列出所有破坏行为”。我的提案比给予豁免更为宽松，只是要求部分已列出的条目范畴受较多限制，例如只有行政区划条目需要符合导航模板的额外要求之类，其他按原本维基化/孤立页面的要求处理。JC1 2018年5月22日 (二) 06:51 (UTC)
      • 更何况“除非社群或机器人审核小组提出豁免”一句已符合给予足够豁免，hell，可以说已经给予全面豁免了。JC1 2018年5月22日 (二) 06:57 (UTC)
      • 之所以言之不可比是因为《破坏方针》有给予明确定义，然后不穷尽例子只为说明此项定义。亦因如此，《破坏方针》可以不穷举例子，正如《收录准则》一样。但此处，阁下草案是定出标准，而此等标准并非用以说明某个定义。而且现在就是提示阁下草案有值得斟酌之处，提供豁免固然是好，但并没有根本解决缺漏。所以才叫阁下修改字眼。就第三项，无论是上列达师君所提议，抑或修改成“页面应包含最少一项参考资料，以及如果条目范畴有相应导航模板，则亦应该包含其中。”，个人都能够接受。请君考虑，在下无意刁难，只希望草案不会有已知缺憾。--J.Wong 2018年5月23日 (三) 02:41 (UTC)

MASSCREATION第二版

现行条文

以自动或半自动方式批量创建条目或页面分类前，必须先提出申请。“批量”指50项编辑或以上。你应先到互助客栈及相关专题寻求共识。操作者必须确保所创建的条目符合社群的要求。

更简单的方法是减少创建的条目数量，或先在各属专题的子页面创建条目，由其他编辑检查后，再移动到条目空间。这些方法不用申请机器人，也更容易得到社群的支持。

提议条文

以自动或半自动方式批量创建条目或页面分类前，必须先提出申请。“批量”指50项编辑或以上。你应先到互助客栈及相关专题寻求共识。操作者必须确保所创建的条目符合社群的要求。

更简单的方法是减少创建的条目数量，或先在各属专题的子页面创建条目，由其他编辑检查后，再移动到条目空间。这些方法不用申请机器人，也更容易得到社群的支持。

一般而言，除非社群或机器人审核小组提出豁免，由机器人创建的条目须达致以下标准：

  1. 创建条目时应尽可能确保数据库为最新版本
  2. 建立页面列出已创建的条目，方便他人检查及更新
  3. 条目应已维基化，并有至少一项参考资料。
  4. 页面不能为孤立页面。
  5. 如条目范畴有相应导航模板，亦应包含其中。
  6. 可行情况下，条目应附有讯息框。

建议适度扩大机器人的使用范围

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

本主题或以下段落文字，移动自WP:VPP。执行者：--J.Wong 2018年6月28日 (四) 09:41 (UTC)。

嘛，也不是第一次提了，只是最近这三天的经历，感受更深了不少。

我希望，机器人不仅仅限于现在的补个标点、标记/补充替换个死链接、发个通知什么的这种工作，应该进一步投入到人力资源补充、反破坏日常维护的工作中去。

165.84.176.62提出“为什么黄智雯、李佳芯、蔡思贝、甚至张可颐等等等等大部分演员可以有性质?”，这是个好问题。角色性质，早就有共识原则上禁止使用了（我个人一直是有条件接受），那为什么这么多条目变成了漏网之鱼？显然，是执行力度的问题，根本性问题是缺乏人力，而wiki太大了（指望我一个人管了所有TVB条目这事显然也不现实，于是只能尽可能多管几个，到最后，几个有人日常维护的，反倒成了异类，大部分其他条目在野蛮生长。）

而今天下午，本来国籍的问题，北极企鹅团路过看见，已经帮忙弄好了，下午我上来，当时Jasonloi1997已经在那里了，结果陈奕迅等三个条目，我前后大概顶了20分钟多一点（基本到极限啦，很久没这么干过了。最后没彻底顶住不说，我倒收到了3RR通知...  囧rz…… 刚才我查了一下记录，管理员处理完已经是晚上很晚了）。

我想说，无论是角色性质，还是国籍破坏。它们都有固定的编辑模式/内容，既然这样，是否可以投入机器人进行维护工作，代替纯人工？（特别是下午那20分钟，真是够呛）

--我是火星の石榴（留言） 2018年6月13日 (三) 17:32 (UTC)

ORES--百無一用是書生 (☎) 2018年6月14日 (四) 02:06 (UTC)
  • 其实这话题与机器人方针没太大关系……请善用已有科技。--J.Wong 2018年6月14日 (四) 05:07 (UTC)
  • 这有点像是在说enwiki的User:ClueBot NG，会自动识别并回退可能的破坏编辑。不过zhwiki编辑量还没那么大，AF应该够用。--Suaveness（对话．贡献） 2018年6月14日 (四) 14:30 (UTC)
  • (？)疑问：@Red16：什么叫做角色“性质”？ 他们又不是化学物质，有什么性质？如果是讯息框，未见禁止加入讯息框的共识。--　宇帆（维基贡献十周年！留言·欢迎签到[试用小工具]） 2018年6月15日 (五) 04:53 (UTC)
    • (：)回应：就是男/女1/2/3/4号...然后其他人的粉丝会过来说，我们才是1号，你们根本是配角，于是就这么开始轮上了...那wiki不就是变成了儿童游乐园了嘛。当年kellymok被封禁的理由不就是这个？长期出没解除了？我查了一下并没有啊。--我是火星の石榴（留言） 2018年6月15日 (五) 05:07 (UTC)
  • “角色性质，早就有共识原则上禁止使用了”不了解，可设定方针、设定防滥用过滤器，用不上机器人吧。机器人对有表格内容的清理并不有效，机器人回退还可能造成编辑战、漏网/绕过，如Liangent-bot的反简繁破坏。如果共识确定并且内容规律，可以请求机器作业来纠正。--YFdyh000（留言） 2018年6月15日 (五) 14:40 (UTC)
    • 我自己也想不明白，为什么编辑共识的讨论记录会找不到？但是相关封禁记录肯定全部都在，但是最早的依据存档找不到，这我们是不是要把那一堆持续出没的给放出来？  囧rz…… 只能麻烦管理员去找了，如果十几年的记录就找不到的话(等于数据会自动永久性丢失) 这没什么好说的了。
过滤器难道不是需要管理员来设置的么？我自己费码农出身，精密模板这种东西肯定算了。
另，现在另一个大问题是，既有内容的大规模清理，不使用机器人的话，不具可行性吧？你要都丢给我一个人，我肯定不干了。--我是火星の石榴（留言） 2018年6月15日 (五) 18:39 (UTC)
(※)注意：禁止加入讯息框的共识不存在。--　宇帆（维基贡献十周年！留言·欢迎签到[试用小工具]） 2018年6月16日 (六) 01:40 (UTC)
(※)注意：禁止加入讯息框的共识不存在，化学性质信息框、算法性质信息框、多面体性质信息框......等等并非未经筛选的资料，且禁止加入讯息框的共识不存在，乃至角色性质讯息框，无明显共识，参与讨论人数过少，想说你们正在WP:POINT。--　宇帆（维基贡献十周年！留言·欢迎签到[试用小工具]） 2018年6月16日 (六) 09:42 (UTC)
  • 事实上WP:BOTPOL并未直接对这类任务作出特定的限制。但是从机器人的三大原则（有用、无害、有效）来看，显然这类机器人不如过滤器有用和有效，因此获批的可能性不大。--Antigng（留言） 2018年6月20日 (三) 14:57 (UTC)

方针小修

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

见Special:Diff/50250102。-- Junjie Yuan（留言） 2018年7月4日 (三) 11:26 (UTC)

我觉得这个方针要改的地方还有很多，不过最近没什么时间，先不管了。--Junjie Yuan（留言） 2018年7月4日 (三) 11:28 (UTC)

Techadmin 能拥有adminbot吗？

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

本主题或以下段落文字，移动自Wikipedia:互助客栈/方针。执行者：Jimmy-bot（留言） 2019年4月19日 (五) 08:14 (UTC)。

最近liangent bot 停运，大家都吃了不少苦头。但可惜目前的管理员暂时未有时间研究如何维修它。能不能将adminbot的拥有人放宽到techadmin呢，让多点人参与研究呢？

  • 界面管理员权限的确在 Liangent-bot 的功能上没什么可做的，除非把 DYK 模板放进 MediaWiki 名字空间（囧），这样自带全保护且 IA 也可以编辑。--Tiger（留言） 2019年4月10日 (三) 01:14 (UTC)
  • 代码确实需要多次调试并且更改，不太可能每次调试、甚至紧急的更改都要耗费宝贵管理员的时间与精力来部署软件。若是以参与处理技术性站务为主来申请管理员，不晓得各位觉得如何？ --Kanashimi（留言） 2019年4月10日 (三) 08:54 (UTC)
  • 其实是有擅长技术站务而且也活跃的管理员在，如果给他们的话，他们可自行调试、更改。如果他们都无法完成这个工作，而且正好有一个值得信任的非管理员愿意做这件事，那么此次作为例外，给他们一个含有管理员权限的机器人账户我觉得可以考虑。--Tiger（留言） 2019年4月10日 (三) 09:16 (UTC)
  • （值得信任的水准恐怕要很高，就是和管理员一致，只是不去考察那位用户其他方面的站务能力）--Tiger（留言） 2019年4月10日 (三) 09:21 (UTC)
可以考虑允许界面管理员或者面向技术维护的类似管理群组的申请带管理员权限的机器人，不过需要遵守更严格的规定，例如代码要公开review；只限于任务内的操作（除了一些合理的调试行为）；一经发现违规、超范围操作、或者涉及公器私用的，立即除权，无合理解释的话永久不得再申请。——路过围观的Sakamotosan | 避免做作，免敬 2019年4月11日 (四) 00:28 (UTC)

对维基百科:用户页、维基百科:机器人方针及相联页面的合并更新

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

本主题或以下段落文字，移动自Wikipedia:互助客栈/方针。执行者：Jimmy-bot（留言） 2020年3月9日 (一) 00:14 (UTC)。

已解决
下列讨论已经关闭，请勿修改。如有任何意见，请至合适的讨论页进行，并不要再次编辑本讨论。

目前的用户页方针对机器人账号等合规附属账号的用户页没有明确的规范。此外，部分机器人的用户子页设有技术开关，如User:Liangent-bot/message，一旦遭到错误的更改，可能影响到众多用户。现拟对此作出明文规定：

Wikipedia:用户页

于目前“从我的用户页上有哪些其他信息可以被别人看到？”下，新增一章：

现行条文

无。

提议条文

机器人及其他合规多重账号的用户页 一般来说，机器人及其他合规多重账号用户页的所有权归这些账户的操作者所有；如果机器人由多人一起操作，则一般而言，所有操作者都具有所有权。操作者对这些用户页进行创建、修改、申请进行管理操作时，等同于对自己的用户页空间进行操作。

Wikipedia:机器人方针

于“机器人的使用”下添加三级标题，为：

现行条文

无。

提议条文

机器人的用户页 机器人可按实际需求设立用户页及用户子页面。这些页面的管理权属于机器人操作者。由于此类页面有一定系统管理功能，管理员可对它们实施预防性保护。

Wikipedia:保护方针

修改Wikipedia:保护方针#不同的保护期限，增加：

现行条文
  • 保护一些“系统管理”页面，包括许多编辑用的模版，例如删除告示、小作品模版等。
  • 保护MediaWiki的名字空间，以及嵌入包含的页面，这些页面会影响所有用户的系统界面。
提议条文
  • 保护一些“系统管理”页面，包括许多编辑用的模版，例如删除告示、小作品模版等。
  • 保护有“系统管理”性质的机器人子页面。
  • 保护MediaWiki的名字空间，以及嵌入包含的页面，这些页面会影响所有用户的系统界面。

Wikipedia:傀儡

修改公开备用账号一节：

现行条文

== 公開備用帳號 ==

使用多重帐号的用户应当明示帐号间的关系，除非这样做会违背合理使用多重帐号的目的。明示的方式是在备用帐号用户页上使用模板{{User Alternate Acct|主帐号名}}。在主帐号页上亦可加上{{User Alt Acct Master}}标记。

提议条文

== {{新增條文|公開多重帳號間的關係}} ==

使用多重帐号的用户应当明示帐号间的关系，除非这样做会违背合理使用多重帐号的目的。明示的方式之一是在子帐号的用户页上使用诸如{{User Alternate Acct|主帐号名}}、{{Bot|主帐号名}}等模板。在主帐号页上亦可加上{{User Alt Acct Master}}标记。经标记后，主账户对这些用户页进行创建、修改、申请进行管理操作时，等同于对自己的用户页空间进行操作。

个人有两只账号，目前这只比较活耀比较新，另一只贡献次数比较多。到时你们讨论完成后请题醒或指导我如何标记Heartingvia（留言） 2020年2月22日 (六) 03:55 (UTC)
不同意必须要用模板作出合理使用多重账号声明，我认为只要用户页具有适切的说明文字即可。ꓢꓯꓠꓟꓳꓢꓮ COVID-19 2020年2月23日 (日) 06:13 (UTC)
"使用多重帐号的用户应当明示帐号间的关系"是旧有的方针条文。我不太清楚当初为什么会译做"应"。--Temp3600（留言） 2020年2月23日 (日) 13:54 (UTC)
条文是“使用多重帐号的用户应当明示帐号间的关系”没错，其实没了“应”这个字更好，不过这要另外提案。我说的是我认为只要用户页具有适切的说明文字说明帐号间的关系（例如A用户和B用户是同一个人操作的）就行，不一定要用模板显示。ꓢꓯꓠꓟꓳꓢꓮ 漆黑漫长夜 2020年2月23日 (日) 14:26 (UTC)
"明示的方式之一是"就行了吧。--Temp3600（留言） 2020年2月23日 (日) 15:38 (UTC)
接受，其实只要不是唯一就可以。ꓢꓯꓠꓟꓳꓢꓮ 漆黑漫长夜 2020年2月24日 (一) 02:16 (UTC)
好，已改。--Temp3600（留言） 2020年2月24日 (一) 11:41 (UTC)
初步不反对。ꓢꓯꓠꓟꓳꓢꓮ 漆黑漫长夜 2020年2月24日 (一) 11:43 (UTC)
本讨论已经关闭，请勿修改。如有任何意见，请至合适的讨论页进行，并不要再次编辑本讨论。
检索自“https://zh.wikipedia.org/w/index.php?title=Wikipedia_talk:機械人方針/存檔一&oldid=68173039”
返回到项目页面“機械人方針/存檔一”。