维基百科讨论:过滤器助理

有关修改滥用过滤器权限的提案

现拟增设修改滥用过滤器的权限，具体增设的方式未定。Sanmosa _{热烈庆贺“关注度”正名“收录标准”} 2025年1月19日 (日) 08:46 (UTC)

赋予过滤器助理修改滥用过滤器权限

注意到防滥用过滤器错误报告和防滥用过滤器请求积压，管理员及行政员负担较重，导致部分请求无法及时处理，这降低了过滤器阻止破坏的能力，亦增加了社群维护其的难度。因此，谨提议授予过滤器助理修改权限，协助管理滥用过滤器，尚祈社群商议为荷。Iming 彼女の爱は、甘くて痛い。 2024年12月28日 (六) 03:12 (UTC)

---

注意到防滥用过滤器错误报告和防滥用过滤器请求积压，管理员及行政员负担较重，导致部分请求无法及时处理，这降低了过滤器阻止破坏的能力，亦增加了社群维护其的难度。因此，谨提议授予过滤器助理修改权限，协助管理滥用过滤器，尚祈社群商议为荷。

现行条文 权限总览 对比起一般使用者，过滤器助理可以： 查看标记为非公开的滥用过滤器的过滤日志（abusefilter-log-private） 查看被标记为非公开的滥用过滤器（abusefilter-view-private） 启用双重身份验证（oathauth-enable） 允许移除自己账号的用户组

提议条文 权限总览 对比起一般使用者，过滤器助理可以： 查看标记为非公开的滥用过滤器的过滤日志（abusefilter-log-private） 查看被标记为非公开的滥用过滤器（abusefilter-view-private） 启用双重身份验证（oathauth-enable） 创建或修改滥用过滤器（abusefilter-modify） 修改包含受限动作的滥用过滤器（abusefilter-modify-restricted） 允许移除自己账号的用户组

此外，亦请参见二年前之增设过滤器编辑员讨论。——敬颂冬绥 ZhaoFJx_(论•签) 2024年12月5日 (四) 16:00 (UTC)

已知获权者皆熟悉过滤器和正则表达式，并考虑到目前的积压，(＋)支持本提案。不过，可能不应当授予abusefilter-modify-restricted权限，该权限实质上允许过滤器助理进行封禁这一管理动作。--Iming 彼女の爱は、甘くて痛い。 2024年12月5日 (四) 16:27 (UTC)

另可以增加限制：“仅在社群有明确共识时，过滤器助理才可以新建过滤器。”--Iming 彼女の爱は、甘くて痛い。 2024年12月5日 (四) 16:34 (UTC)

关于这个限制，需规定在 WP:AFR/可靠来源布告版 达成的共识才算数，实行没有共识的动作有机会遭除权。

BTW, 现在已经有GPT，有没有wiki人愿意付那20美金/690台币一个月，建立GPT BOT,喂他关于wiki独有的正则表达式技术文件及实行内容，建立或修改防滥用过滤器应该没什么难度^{[开玩笑的]}。--唔好阻住我爱国（留言） 2024年12月5日 (四) 16:47 (UTC)

赞成您的观点，我补充一下：“仅在社群有明确共识时，过滤器助理才可以新建过滤器。如过滤器助理未经社群讨论并取得明确共识便自行设置过滤器，则不论过滤器性质为何，皆属违规，管理员可自行决定是否除权或给予警告，社群成员如有发现也可至布告板举报。”--Iming 彼女の爱は、甘くて痛い。 2024年12月5日 (四) 16:54 (UTC)

布—>布--唔好阻住我爱国（留言） 2024年12月5日 (四) 17:23 (UTC)

@HK5201314 布—>佈，考虑使用-{}-避免自动转换——敬颂冬绥 ZhaoFJx_(论•签) 2024年12月5日 (四) 21:23 (UTC)

虽然但是，请不要这么做，除非你只是懒但有办法自行检验GPT写的到底合不合理--SunAfterRain 2024年12月13日 (五) 19:56 (UTC)

这个限制可能比较鸡肋，先是过滤器规则里面加个或条件就能在不创建新过滤器的情况下几乎达到新过滤器的功能，再是如果A过滤器本身是阻止，没有对应的警告过滤器，如果过滤器助理认为有必要拆分出仅警告的过滤器，还得走流程，也会变相积压。不如要求“依据常识判断，不合理的过滤器更动应被警告或除权”。𝐻.𝑁𝑎𝑡𝑠𝑢𝑚𝑖 ™ 2024年12月6日 (五) 01:59 (UTC)

我觉得可以，您书的对。--Iming 彼女の爱は、甘くて痛い。 2024年12月6日 (五) 02:36 (UTC)

(－)反对：设立过滤器助理的原意是为了查看过滤器的详细资讯，而非编辑过滤器。尽管资格要求中“建议”申请人对正规表达式以及应对过滤器有基本认识，但此项并非必须。个人认为应另设新权限组，而非沿有过滤器助理此原有权限。谢谢。--SCP-0000（留言） 2024年12月22日 (日) 03:24 (UTC)

@ZhaoFJx、Iming。@SCP-2000：我个人会关注现时实际上有多少个不具备对正规表达式与过滤器本身的基本认识的过滤器助理，如果没有的话，那你说的这点可以通过把资格要求中的“建议”改为硬性要求来处理。亲，我签名那刻的时间是 2024年12月22日 (日) 03:57 (UTC)

可以改为强制性要求，本来看不懂过滤器要AFH就没什么作用，日志rollbacker还是可以看（rollbacker有abusefilter-log-private权）。出于缓解积压的考虑，现行方案我认为是最优解，还请您再考虑改“申请人对正规表达式以及应对过滤器有基本认识”为强制性要求后授予AFH修改滥用过滤器权限的可行性。多谢。--Iming 彼女の爱は、甘くて痛い。 2024年12月22日 (日) 06:49 (UTC)

@Sanmosa、Iming： 抱歉忘了这讨论。简单而言，个人认同对于编辑过滤器之权限，“对正规表达式以及应对过滤器有基本认识”应为强制性要求，然而此举只会对现时持有者及反破坏工作带来干扰。为了避免带来不必要的影响，应考虑另外建立新权限组，而非沿用现有权限组。

具体而言，其一，现时有部分过滤器助理主要因反破坏或其他需要（如维护机器人）而申请此权限（参见2023、2024年存档），以便查看过滤器日志等，如果未来此权限的申请要求改为“对正规表达式以及应对过滤器有基本认识”，部分人可能因缺乏对正规表达式等技术的理解，不能申请此权限，某程度上影响了反破坏以及其他工作。

其二，正如上述所言，设立过滤器助理的原意是为了查看过滤器的详细资讯，而非编辑过滤器。当时的申请只判断申请者的能力及受信任程度，是否合适持有“查看”过滤器详细资讯，而非“编辑”过滤器。现实上，现在不可能每个过滤器助理有足够能力及信任程度拥有“编辑”过滤器权限，我们也不可能就凭表面印象而知晓谁有否能力，那唯有每位过滤器助理需重新申请此权限，无疑是扰民之举。

当然，社群可以选择不调整要求，但编辑过滤器之权限为相当“敏感”，稍有错误便会影响众多用户，且事实上跟管理员权限无异（皆可保护及封禁），故不调整要求并非明智之举。无论是英维有两个不同权限组（分别为查看及编辑过滤器），以至本站过去亦有相关讨论，本身本站权限组也不少及不差多一个权限组，个人不太理解为何沿用现有权限组，而非另外建立新权限组。谢谢。--SCP-0000（留言） 2025年1月5日 (日) 16:27 (UTC)

WP:帽子收集狂。Sanmosa _兰絮 2025年1月5日 (日) 23:59 (UTC)

至少应该禁止利用过滤器实现条目保护、账户封禁、编辑禁制之类一般认为是管理员权限范围的操作。--Tiger（留言） 2024年12月22日 (日) 06:40 (UTC)

前面那个可以写进修正案里，后面两个AFH技术上就做不到（没有abusefilter-modify-restricted权）--Iming 彼女の爱は、甘くて痛い。 2024年12月22日 (日) 06:43 (UTC)

“disallow”在 $wgAbuseFilterActionRestrictions 里吗？不在的话，写一个 user_name == 某人 然后设置阻止就和封禁没差别了吧。当然我的意思是广义上的不可以做这种事情，而不只是列出几种。或者说，这个讨论缺失了这个部分，讨论的时候至少要意识到这种问题。--Tiger（留言） 2024年12月22日 (日) 07:54 (UTC)

见草案一，AFH有权修改过滤器的情况仅包含“按照社群共识创建过滤器或根据相关讨论分拆过滤器”和“可以按照错误报告修复过滤器”，前者如果有禁止某用户编辑这类的讨论我想应该无法达成共识，后者修复过滤器不太可能涉及到这类操作（至少现在的过滤器还没有）。如果确认到AFH滥用权限做到类似封禁用户的操作，管理员可以直接撤销权限。所以虽然技术上不能直接阻止这类编辑，但是在AFH高度可信的前提下，我觉得应该还是在可控范围的，无需对这类操作过度担忧。--Iming 彼女の爱は、甘くて痛い。 2024年12月22日 (日) 08:02 (UTC)

草案

草案 #1

提议条文 权限总览 对比起一般使用者，过滤器助理可以： 查看标记为非公开的滥用过滤器的过滤日志（abusefilter-log-private） 查看被标记为非公开的滥用过滤器（abusefilter-view-private） 启用双重身份验证（oathauth-enable） 创建或修改滥用过滤器（abusefilter-modify） 允许移除自己账号的用户组

Iming指出，过滤器助理不应包含“修改包含受限动作的滥用过滤器”一权。根据滥用过滤器文档和之前讨论，过滤器助理将……

1. 可以按照社群共识创建过滤器；
   1. 可以按照社群共识创建过滤器或根据相关讨论分拆过滤器；
2. 可以按照错误报告修复过滤器；
3. 不能创建或修改包含“撤销用户的自动确认状态”、“封禁进行编辑的用户和/或IP地址”两类操作的过滤编辑器。

——敬颂冬绥 ZhaoFJx_(论•签) 2024年12月5日 (四) 22:02 (UTC)

参考上方Hotaru Natsumi君，第一条或可以改为“可以按照社群共识创建过滤器或根据相关讨论分拆过滤器；”--Iming 彼女の爱は、甘くて痛い。 2024年12月6日 (五) 16:25 (UTC)

已添加——敬颂冬绥 ZhaoFJx_(论•签) 2024年12月6日 (五) 16:49 (UTC)

修改申请标准和流程

撤回：

提案人 撤回提案。Sanmosa _蚌埠 2024年12月17日 (二) 08:50 (UTC)

下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

---

在站外收到了一些意见，有些意见指出由于赋予编辑权，应当适当拔高AFH的申请标准。因而，本人参考WP:IPBEG、WP:BAG和WP:SPI/C，草拟了一份提案，尚祈社群商议为荷。

现行条文 申请程序 如果您有意申请过滤器助理的权限，请亲自到Wikipedia:权限申请/申请过滤器助理权限申请，或接受其他用户于该页发起的提名。 以下使用者不需要去申请或是为他们增加本权限，他们本身已经获自动授予同等的权限： 管理员

提议条文 申请程序 符合申请过滤器助理要求者，可循一般程序，在权限申请页申请成为过滤器助理。 提出申请后，具有管理员、回退员或过滤器助理权限的用户可以提出问题，并自行按其认知支持或反对申请，惟须附上有效理由。在申请人明显不符合条件的情况下，一名管理员或过滤器助理可以快速关闭此申请。申请以七日为限，七日后如总有效票数大于等于四票，且满足以下条件符合以下条件，则一名管理员或过滤器助理可以结案并授予过滤器助理权限： 支持率在50%以上； 社群就授予权限达成合意； 没有管理员或过滤器助理反对。 或： 有效票数大于等于四票； 支持率在80%以上； 没有管理员反对。

以上。Iming 彼女の爱は、甘くて痛い。 2024年12月6日 (五) 12:45 (UTC)

基于程序公义，烦请阁下透露相关意见是在哪个外站及哪个人发表，谢谢！--唔好阻住我爱国（留言） 2024年12月6日 (五) 12:50 (UTC)

似乎这不涉及程序正义？另相关建议在我的私人群组中提出，当事人信息属隐私，恕不能公开。如果您一定需要的话，请理解成是我的想法。如有带来困扰，还请谅解，感谢。--Iming 彼女の爱は、甘くて痛い。 2024年12月6日 (五) 12:55 (UTC)

这可能有些打破RFR逻辑？当前RFR的逻辑应该类似于申请人提出申请，其他人有疑问则提出，管理员依据疑问及其处理完成授权与否的判断，不是简单投票。这种要求支持率的是RFA而非RFR。而且RFR很少能出现“有效票数”≥4的情况。𝐻.𝑁𝑎𝑡𝑠𝑢𝑚𝑖 ™ 2024年12月9日 (一) 10:44 (UTC)

因为有些意见指出由于赋予编辑权，应当适当拔高AFH的申请标准，因而我参考IPBEG和BAG的申请流程，写了这么个东西，本身最主要的作用是让有能力判断是否适合担任AFH的人参与最终决定。如果您真的觉得这样不合适的话，那么取消无过滤器助理反对情况下的有效票数和支持率限制如何？而且我相信管理员在赋权时也会参考社群意见，对于明显无法达成合意的讨论会直接忽视。--Iming 彼女の爱は、甘くて痛い。 2024年12月10日 (二) 02:07 (UTC)

个人感觉还是使用原来的RFR程序即可，高标准应该是高准入，而不是复杂化和量化的申请流程。但是现行AFH的准入标准已经足够高，申请人不是回退员、他站可信用户、基金会成员的情况下，本身就需要社群讨论是否准入，而即便是门槛相对低的回退员也要求活跃于反破坏；此外通用的全域1000编辑数限制也不见得低。𝐻.𝑁𝑎𝑡𝑠𝑢𝑚𝑖 ™ 2024年12月16日 (一) 09:13 (UTC)

现在申请IPBEG已经明文要求大于四票了 囧rz……，不过80%尚不清楚会不会太高，就先观望一下，看实操结果如何。--$\int$（☎）dt 2024年12月14日 (六) 04:10 (UTC)

IPBEG的权限实际上是在让IP封禁对特定用户广泛失效，进而让用户查核失效，权限可以算敏感，毕竟这样会查不出傀儡，影响反破坏和站务，但是仅是AF的编辑权很难说敏感，AF的编辑历史只要能看AF就能看到，这样AFH加了个比如禁止所有编辑的规则，管理员马上可以以滥权撤权并封禁，这种明面上的权限至少不能和IPBEG相提并论。𝐻.𝑁𝑎𝑡𝑠𝑢𝑚𝑖 ™ 2024年12月16日 (一) 09:13 (UTC)

---

根据先前讨论，考虑到部分社群成员对AFH是否适合拥有此权限不信任，本人动议试行草案一和“修改申请标准和流程”两案一年，以观后效。考虑到草案一和“修改申请标准和流程”两案无有效反对，拟三日后公示，还请各位提出意见。Iming 彼女の爱は、甘くて痛い。 2024年12月15日 (日) 13:45 (UTC)

见上方回复。𝐻.𝑁𝑎𝑡𝑠𝑢𝑚𝑖 ™ 2024年12月16日 (一) 09:13 (UTC)

按H.Natsumi君意见撤回“修改申请标准和流程”案。--Iming 彼女の爱は、甘くて痛い。 2024年12月16日 (一) 10:00 (UTC)

---

本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

草案 #2

不通过：

尚无必要赋予过滤器助理授权权限。——敬颂冬绥 ZhaoFJx_(论•签) 2024年12月16日 (一) 00:35 (UTC)

下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

---

提议条文 权限总览 对比起一般使用者，过滤器助理可以： 查看标记为非公开的滥用过滤器的过滤日志（abusefilter-log-private） 查看被标记为非公开的滥用过滤器（abusefilter-view-private） 启用双重身份验证（oathauth-enable） 创建或修改滥用过滤器（abusefilter-modify） 添加用户组：过滤器助理 允许移除自己账号的用户组

有成员主张，根据上方的授权流程草稿，草案#2应明确，在#1的基础上，允许过滤器助理赋予其他受信任用户过滤器助理一组。相信此改革可显著减轻管理人员在过滤器相关方面的任务压力。——敬颂冬绥 ZhaoFJx_(论•签) 2024年12月7日 (六) 04:03 (UTC)

(＋)赞成，在管理员工作积压严重的当下，我相信这样可以显著减轻管理人员在过滤器助理相关方面的任务压力。--Iming 彼女の爱は、甘くて痛い。 2024年12月7日 (六) 05:22 (UTC)

不同意过滤器助理授予他人此一权限。现行权限申请制度未至积压，请维持依照正常程序申请，俾便于社群检视。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年12月7日 (六) 22:35 (UTC)

同Eric君，以目前的申请积压情况无必要授予过滤器助理授予他人权限的权限--人间百态,独尊变态(讨论)(签名) 2024年12月8日 (日) 14:30 (UTC)

RFR现在没有积压，没有必要由现任AFH给申请人上权限，并且2024年AFH申请的频率极低，明显不会造成RFR积压，故反对这一部分。𝐻.𝑁𝑎𝑡𝑠𝑢𝑚𝑖 ™ 2024年12月9日 (一) 10:32 (UTC)

个人认为过滤器编辑员应该是另一种权限，这个权限远远比查看过滤器敏感（例如有过滤器编辑权限者可以建立过滤器封禁所有试图编辑的用户）。反对赋予过滤器助理修改滥用过滤器权限。--GZWDer（留言） 2024年12月10日 (二) 11:25 (UTC)

@GZWDer：草案一定义了权限中将不再存在abusefilter-modify-restricted一权，故“封禁所有试图编辑的用户”这一行动技术上即不可行。——敬颂冬绥 ZhaoFJx_(论•签) 2024年12月11日 (三) 01:21 (UTC)

但是仍然可以创建一个过滤器阻止任何用户编辑。--GZWDer（留言） 2024年12月11日 (三) 11:34 (UTC)

没必要因噎废食。现在错误报告的积压呢是放在那里的，喊管理员呢是没有人管的。按过往讨论，单开编辑者权限估计过不了，在考虑到积压问题、过往讨论和现有AFH均具备技术能力的情况下，给予AFH除受限过滤器外过滤器的编辑权是最优解，我上方提出的“修改申请标准和流程”案就是为了解决您这个问题设计的。而且事实上，我写个机器人实时回退匹配的编辑也不是不能实现这个功能，所以我是觉得把需要管理员权限的扔出去就差不多了，您意下如何？--Iming 彼女の爱は、甘くて痛い。 2024年12月11日 (三) 15:23 (UTC)

(－)反对，如果是IPBE那种就算了，但很显然授权过滤器助理没有那种积压问题（更何况还是高危权限）--SunAfterRain 2024年12月13日 (五) 19:51 (UTC)

根据上方讨论，草案二不通过。由于主要反对意见均关于草案二中新增的授予权限权限，因而草案一维持开放，请移步草案一处进行讨论，感谢。--Iming 彼女の爱は、甘くて痛い。 2024年12月14日 (六) 02:55 (UTC)

---

本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

在受限过滤器多次匹配正常编辑时的处理措施

已关闭：

提案人 撤回提案。——敬颂冬绥 ZhaoFJx_(论•签) 2024年12月10日 (二) 02:16 (UTC)

下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

---

按前文讨论，考虑到对包含受限动作的过滤器的编辑权限实际上等同于封禁权限，因而没有授予过滤器助理创建或编辑含受限动作的过滤器的权限。然而参考近期AF/FP，可预见的在未来会存在含受限动作过滤器错误匹配甚至封禁正常编辑者的情况。又考虑到WP:AF等页面不存在事实上的过滤器方针，宜同本案一并讨论。是故，本人有以下想法，尚祈社群商议为荷。

现行条文 不存在

提议条文 编辑受限过滤器 当确认到一个包含受限动作的过滤器存在不符合预期的行为或已严重影响到正常编者编辑时，过滤器助理可以请求管理员临时关闭相关过滤器或取消相关过滤器内的受限动作，直至问题解决为止。当管理员处理此类操作时，除非有其他原因，否则通常应当在关闭过滤器后取消相关过滤器内的受限动作以便其他管理员或过滤器助理修复。当一名管理员或过滤器助理确认问题得到解决后，就可以恢复过滤器至原先状态。

以上Iming 彼女の爱は、甘くて痛い。 2024年12月8日 (日) 16:14 (UTC)

反对这种处理，比如过滤器275这类自动化封禁破坏的过滤器显然不能简单取消受限，只能过滤器助理调查哪一个正则导致了错误触发并请管理员处理，取消受限造成的反破坏影响太大了。𝐻.𝑁𝑎𝑡𝑠𝑢𝑚𝑖 ™ 2024年12月9日 (一) 10:39 (UTC)

您说的确实很有道理，那可能我们需要进一步讨论在受限过滤器多次匹配正常编辑时的处理措施。至少，我认为应当将封禁一类操作改为阻止+标记以供人工审查，您觉得如何？如此应当可以有效减轻对反破坏工作的影响。--Iming 彼女の爱は、甘くて痛い。 2024年12月9日 (一) 10:44 (UTC)

275这种泛用过滤器出现这类同规则多次触发的情况下直接把封禁过滤器里面多次误报的那一个规则移动到阻止或者警告（这里可以是201和289），这个操作管理员很容易完成，过滤器助理只需要调查出受限过滤器哪一个特定规则造成了错误触发，通知管理员即可。而像是322这种针对某一特定LTA（或者类似的单一用途过滤器），多次假阳性可以改为不受限。简单说就是需要具体情况具体分析，不建议写成条文，而是出问题了再和管理员依据常识解决。𝐻.𝑁𝑎𝑡𝑠𝑢𝑚𝑖 ™ 2024年12月9日 (一) 10:55 (UTC)

可以，我很赞成您的观点。撤回提案。--Iming 彼女の爱は、甘くて痛い。 2024年12月9日 (一) 11:02 (UTC)

有需要自行IAR就好，不要订一条规则合理化IAR结果还时常发生必须IAR该规则的规则。--SunAfterRain 2024年12月13日 (五) 19:53 (UTC)

---

本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

公示

由于除草案1外的所有分案均不通过或被撤回，而有关原案或草案1的最后留言在11日前作出。依WP:共识#提案讨论及公示时间的规定，互助客栈中的提案在7日内无新留言时或可在已取得共识的前提下公示，故现以草案1为定稿，并公示定稿7日。Sanmosa _蚌埠 2024年12月17日 (二) 08:56 (UTC)

见上，提案的新发展使维持公示不再适合，现撤下公示。亲，我签名那刻的时间是 2024年12月22日 (日) 08:32 (UTC)

改走RFC机制。亲，我签名那刻的时间是 2024年12月22日 (日) 08:36 (UTC)

距上个问题及解答之日已逾7天，现恢复13天前中断的已公示5天的公示。 公示7日，2025年1月7日 (二) 01:54 (UTC)结束。——敬颂冬绥 ZhaoFJx_(论•签) 2024年12月31日 (二) 01:54 (UTC) 暂停公示：公示期间有争议，故暂停公示并进行讨论。——敬颂冬绥 ZhaoFJx_(论•签) 2025年1月5日 (日) 00:03 (UTC)

(！)意见：论其利弊，以为利大于弊；论其可靠，以为配套未足。私以为往后申请权限应要求回答至少三个问题，加强其可信度。--骇客呼吸焉—☎️— 2025年1月2日 (四) 10:29 (UTC)

(－)反对，过滤器事关全站，与管理员相比，过滤器组显然不可信。->>Vocal&Guitar->>_留言 2025年1月1日 (三) 13:27 (UTC)

(：)回应 首先，目前所有助理的申请都是在本草案通过前完成的，也就是说，基本不会存在为了破坏而申请该权限的可能；其次，这些申请都由专门的管理员检查后再授权——你可能也注意到了，并不是每个申请者都被赋权；最后，草案通过后，管理员会在处理申请时更加审慎，以确保不会让破坏者成为过滤器助理。话又说回来，草案#1中所定义的技术权限确保了助理们不能通过过滤器执行恶意操作——或在同等条件下更难执行恶意操作。——敬颂冬绥 ZhaoFJx_(论•签) 2025年1月1日 (三) 18:59 (UTC)

完全是空话，只要过滤器可以阻挡正常编辑，那就完全可能被恶意利用，而且是全站范围影响将会巨大。当初这个组分拆自回退权，回退员申请默认都给过，现在权限发生巨大变化，之前的申请当然不能作数。--。->>Vocal&Guitar->>_留言 2025年1月4日 (六) 00:16 (UTC)

你这意见多少有些Opky式的夸张了。Sanmosa _兰絮 2025年1月4日 (六) 01:55 (UTC)

提议增设过滤器编辑者权限

注意到防滥用过滤器错误报告和防滥用过滤器请求积压，管理员及行政员负担较重，导致部分请求无法及时处理，这降低了过滤器阻止破坏的能力，亦增加了社群维护其的难度。因此，谨提议增设过滤器编辑者权限组，协助管理滥用过滤器。

现在拟定的草案请见维基百科:过滤器编辑者。考虑到过往讨论，该用户组仅允许编辑非受限过滤器，这意味着过滤器编辑者在技术上不能够封禁用户或取消一名用户的自动确认用户权限。

同时参考过往讨论，提供一个FAQ以解答可能存在的问题。

• Q: 过滤器编辑相当复杂，容易搞坏

  A: 过滤器编辑者是应当具有充分经验的用户，另可以建议过滤器编辑者在新建/修改过滤器前先在测试维基进行测试。

• Q: 过滤器的影响范围可达全站，且编辑者变相拥有页面保护和使用者封锁的权利

  A: 在本草案中，编辑者无权增修含受限动作的过滤器，因而技术上即不能封禁用户。对于页面保护问题，现在的所有过滤器均没有相关设置，编辑者如未经社群讨论增补相关内容，即属违规，管理员可以即时移除其权限，同时考虑到编辑者应是高度可信用户，故该问题仍在可控范围，无需太过担心。

以上，尚祈社群商议为荷。Iming 彼女の爱は、甘くて痛い。 2025年1月6日 (一) 18:57 (UTC)

cc @ZhaoFJx：、@SunAfterRain：、@Hotaru Natsumi：、@SCP-2000：、@Tigerzeng：、@Sanmosa：、@Hycaefsiam：、@Ohtashinichiro：。 --Iming 彼女の爱は、甘くて痛い。 2025年1月6日 (一) 18:57 (UTC)

有道理。——敬颂冬绥 ZhaoFJx_(论•签) 2025年1月6日 (一) 19:02 (UTC)

除非Wikipedia talk:过滤器助理#赋予过滤器助理修改滥用过滤器权限没通过，不然无条件(－)反对，理由是会变成两个权限一样的组。--SunAfterRain 2025年1月6日 (一) 19:21 (UTC)

啊，那个可以按不通过计了。--Iming 彼女の爱は、甘くて痛い。 2025年1月6日 (一) 19:47 (UTC)

那我先观望一下，反正直到那个讨论被正式关闭前我不会撤回反对就是了--SunAfterRain 2025年1月7日 (二) 02:59 (UTC)

如同我在那边的讨论所说的一样，另设权限组有WP:帽子收集狂的疑虑。在此，我也要求SCP-2000给出另设权限组为何不属于“帽子收集狂”的合理解释，否则我没有任何合理理由能认为SCP-2000在那边的讨论的反对意见为合理反对意见。Sanmosa _兰絮 2025年1月7日 (二) 04:04 (UTC)

@Sanmosa：您不妨先详细说明为何有帽子收集狂的疑虑，以便个人回应您的疑虑。谢谢。--SCP-0000（留言） 2025年1月7日 (二) 04:27 (UTC)

两个权限组的具体权限高度相近，而且差别仅在于是否具备过滤器编辑权。假如过滤器编辑者成为独立的权限组，这会导致现有的过滤器助理权限组成为无用的权限组，而此后单独申请过滤器助理权限者显然不可能是WP:过滤器助理所建议应申请该权限的人，而只可能是收集了名衔然后不实际行使权限的帽子收集狂。Sanmosa _兰絮 2025年1月7日 (二) 04:36 (UTC)

你需要解释为什么这会导致现有的过滤器助理权限组成为无用的权限组，或者换句话说，是否存在用户只需要具备阅读私有过滤器的能力，而不需要修改过滤器的能力。目前过滤器助理方针页面所列举的要求之中，我个人只认为经社群讨论，确认对过滤器设计有相关认识，并计划协助维护中文维基百科的过滤器是有必要具备修改过滤器能力的，其他情况下只读即可 Stang^★ 2025年1月7日 (二) 09:18 (UTC)

可以说，凡是能完全看懂mw:Extension:AbuseFilter/Rules format的人都同时具备阅读与修改过滤器的能力，而不能完全看懂的都同时不具备这两种能力，这两种能力本质上就是不可分的。这情况类似转换组的代码，能看懂转换组的代码的自然都懂如何修改转换组的代码。Sanmosa _兰絮 2025年1月7日 (二) 10:43 (UTC)

我说的是“需要”，而不是“具备”，请注意这两者的区别。 Stang^★ 2025年1月7日 (二) 12:15 (UTC)

@Stang：我的意思是你说的这两个能力其实是同一个能力，因此是不可分的，“用户只需要具备阅读私有过滤器的能力，而不需要修改过滤器的能力”在逻辑上不能成立。Sanmosa _兰絮 2025年1月8日 (三) 00:29 (UTC)

我觉得你还是没看懂我的意思，或者可能我的用词存在一些不妥，你可以把“能力”理解成“权力/权限”。拥有某种权限的前提是具备某种能力，但这不意味着我只要拥有了这种能力，我就一定需要拿到这个权限。举个例子，中文维基学院上的一位管理员想参考本站的一个私有过滤器，来编写一个过滤器用于当地。这个用户很显然既具备了阅读也具备了修改的能力（水平，知识），但她只需要可以在本站查看私有过滤器（的权限），而不需要可以修改本站的过滤器（的权限）@Sanmosa：。 Stang^★ 2025年1月8日 (三) 02:25 (UTC)

我不认为会有人真的是这种想法，人总是贪心的。Sanmosa _兰絮 2025年1月8日 (三) 02:29 (UTC)

给出一个具体的，符合你的论点的案例。 Stang^★ 2025年1月8日 (三) 02:31 (UTC)

如果不需担心权限安全，可以授权查看与修改，但条文上不允许日常做修改维护（除去紧急情况？）。Sanmosa可能是说帽子收集狂，而您说抗拒帽子。--YFdyh000（留言） 2025年1月8日 (三) 02:58 (UTC)

但这样的话赋予修改权就没有意义了。--Iming 彼女の爱は、甘くて痛い。 2025年1月9日 (四) 09:02 (UTC)

意见同上，申请过滤器助理本就应既有能力理解、处理过滤器问题又保证可靠可信（之所以从回退员分离）。--骇客呼吸焉—☎️— 2025年1月7日 (二) 11:02 (UTC)

这似乎和“巡查员”和“巡查豁免者”有点像？只要类似巡查员不得再申请巡查豁免者那样，规定取得过滤器编辑权就不得再申请过滤器助理，就解决了吧？（从技术上来说，过滤器编辑员好像也拥有过滤器助理的全部权限，这么做也是符合常理的。）--自由雨日🌧️❄️ 2025年1月9日 (四) 16:26 (UTC)

首先应确定社群有此需求，避免落为档案移动员第二。若有之，则纯以所谓“收集权限帽”斥之尚难构成反对依据。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年1月9日 (四) 13:05 (UTC)

社群确有此需求，惟是否应当单立权限组有所争论。反方主要认为无需单设，授予afh编辑权限即可，单设有hatc之虞。正方主要认为原有afh授权时并未考虑到未来会有权编辑过滤器，故不应当直接授予afh此权限。--Iming 彼女の爱は、甘くて痛い。 2025年1月9日 (四) 13:24 (UTC)

我提这案单纯是因为原先的过滤器助理增加编辑权一案难以通过，故取折衷方案以求尽快解决积压问题。--Iming 彼女の爱は、甘くて痛い。 2025年1月9日 (四) 13:26 (UTC)

整合讨论

(＆)建议将本案与前案方案一两案合并为三方案讨论，即：

1. 维持现状
2. 增加AFH权限
3. 增设新群组

以利意见整合。骇客呼吸焉—☎️— 2025年1月10日 (五) 10:29 (UTC)

已整合讨论串。Sanmosa _{热烈庆贺“关注度”正名“收录标准”} 2025年1月12日 (日) 11:24 (UTC)

@Iming、ZhaoFJx、Hycaefsiam、YFdyh000、Stang、Ericliu1912、SCP-2000、Tigerzeng。Sanmosa _{热烈庆贺“关注度”正名“收录标准”} 2025年1月12日 (日) 11:27 (UTC)

个人不觉得2和3有太多本质上的区别。不过是权限授予方面的灵活度（3更好）和权限结构复杂度（2更好）的取舍，但不影响解决本案原始问题。--Tiger（留言） 2025年1月12日 (日) 15:28 (UTC)

本案旨在解决的是加快对过滤器错误报告中“需要修改过滤器的部分”、“过滤器请求”的处理速度。为什么处理速度不尽人意？1)相关请求页面看的人少，2)有权限处理的人不知道怎么处理。这个和本站引入模板编辑员很相似，但区别也比较明显：模板编辑员旨在根据编辑请求修改高风险模板，绝大部分被处理的编辑请求都需要产生明确的共识后方可由具有权限的人执行修改；而方针中对于过滤器的设立和编辑并没有共识方面的要求，实践中一向是管理员认为有需要就会进行创建和修改，且非公开的修改不在少数。由于过滤器编辑对共识的要求较弱，个人认为让更多有意愿且有能力处理需要涉及到修改过滤器的站务，有助于改善本案希望解决的问题。

其他的意见方面个人与SCP同志的意见相同，“个人认为应另设新权限组，而非沿有过滤器助理此原有权限”。 Stang^★ 2025年1月14日 (二) 06:30 (UTC)

如果没有人能够给出证据证明新增此与既有权限组的权限高度相近的权限组不会导致帽子收集狂的产生，我无法支持新设权限组的提案。Sanmosa _{热烈庆贺“关注度”正名“收录标准”} 2025年1月15日 (三) 04:51 (UTC)

@Sanmosa：我前面好像有提出解决这个问题的办法（类比巡查和巡免权限的处理方式）？--自由雨日🌧️❄️ 2025年1月15日 (三) 06:15 (UTC)

现在中文维基百科的巡查员有170个，而过滤器助理仅有26个，两个权限之间的高度重复性问题还是没有被解决。再者，检视非公开过滤器属于较高级别的权限，这与巡查权、巡查豁免权有着本质上的不同。Sanmosa _{热烈庆贺“关注度”正名“收录标准”} 2025年1月15日 (三) 07:23 (UTC)

这和数量有什么关系？思考...巡查和巡免也是有高度重复性，解决方式是“有巡免不一定有巡查，但有巡查包含了巡免权限、故就不会再有巡免”；类比过滤器助理就是“有查看权不一定有编辑权，但有编辑权必然包含了查看权、故就不会再有查看权”。至于权限高低，这好像和“帽子收集狂”问题无关？--自由雨日🌧️❄️ 2025年1月15日 (三) 07:45 (UTC)

有关，较高级别的权限会更能引起“帽子收集狂”的征服欲。Sanmosa _{热烈庆贺“关注度”正名“收录标准”} 2025年1月16日 (四) 08:10 (UTC)

编辑组统计操作或者布告板活跃度？不理解帽子收集狂有什么严重问题，除了安全风险。--YFdyh000（留言） 2025年1月15日 (三) 06:29 (UTC)

你需要为“xxx会导致帽子收集狂的产生”的主张举证。 Stang^★ 2025年1月15日 (三) 12:11 (UTC)

我不认为新设一个需要高可信程度的过滤器权限会导致收集帽子的问题。 ——魔琴［身份声明 留言 贡献 PJ:NEW23］ 2025年1月15日 (三) 12:25 (UTC)

如果大家坚持无视两个权限组的权限高度重复的问题的话，那我会认为中文维基百科现阶段可能不适合拥有单独具备过滤器编辑权的用户。Sanmosa _{热烈庆贺“关注度”正名“收录标准”} 2025年1月17日 (五) 01:29 (UTC)

可以参照patroller和autopatrolled，前者含后者。如果有HATC疑虑就AFE包含AFH的所有权限，现任AFH被授予AFE时顺带移除AFH组。AFE的门槛应当显著高于AFH，甚至可以要求AFE的获权者持有AFH一段时间并在AF/FP利用AFH做一定的工作。𝐻.𝑁𝑎𝑡𝑠𝑢𝑚𝑖 ™ 2025年1月17日 (五) 03:50 (UTC)

我也一开始是就这么说的…… ——自由雨日🌧️❄️ 2025年1月17日 (五) 04:01 (UTC)

我是更觉得HATC应该是用来限制申请人申请组而不是限制组本身，AFH和AFE这两个组的门槛够高了，单纯的HATC其实都不太容易够门槛。𝐻.𝑁𝑎𝑡𝑠𝑢𝑚𝑖 ™ 2025年1月17日 (五) 04:08 (UTC)

( ✓ )同意，HATC是用来形容一类人的虚荣的不当行为（类似于我前几天提报的一例使用IP来为自己发星章的傀儡行为），不是很理解为什么可以成为用来限制新设组的理由…… ——自由雨日🌧️❄️ 2025年1月17日 (五) 04:13 (UTC)

这样说吧：这最终会导致AFH沦为用户成为AFE的跳板，而这不该是AFH的下场，单设AFE这种架床叠屋的权限组过于官僚化了（此外，我自己是patroller与autopatrolled完全分开的支持者，两者现时的配置在我看来本就是不合理的）。再者，不论AFH与AFE的具体门槛如何，两者的高门槛都是相似的，如果这不会导致“帽子收集狂”的问题的话，那考虑到现时AFH人数的稀少，我高度怀疑单设AFE权限是否真的能起到社群预期它能起的效用。Sanmosa _{热烈庆贺“关注度”正名“收录标准”} 2025年1月17日 (五) 04:53 (UTC)

稍偏题，(！)意见：从减轻防滥用过滤器错误报告和防滥用过滤器请求积压、减轻sysop的工作负担的目的出发，在社群不够信任过滤器用户组的情况下，能否允许过滤器助理用户组修改测试用过滤器（如en:Special:AbuseFilter/1，仅可被触发而无动作）测试一定时间可行后由管理员加入有动作的过滤器？也就是将过滤器的编辑权限范围分为测试前和测试后（不清楚技术上拆分权限是否可行，但相互监督可能已经足够了），测试前的编辑权限应该是低危的。也不用分设用户组。--HeihaHeihaHa-戒慎恐惧……（留言） 2025年1月17日 (五) 05:13 (UTC)

这听起来很复杂，而且我也不知道社群是否有能力正确地完整执行整个流程，毕竟一旦管理员对规则产生了别样的理解，那整个规则也就废了。另一方面，如果“社群不够信任过滤器用户组”这种情况真的存在的话，那理论上所有AFH都该被除权。Sanmosa _{热烈庆贺“关注度”正名“收录标准”} 2025年1月17日 (五) 05:19 (UTC)

“社群不够信任过滤器用户组”是指不够信任现有过滤器助理组编辑过滤器--HeihaHeihaHa-戒慎恐惧……（留言） 2025年1月17日 (五) 06:00 (UTC)

见上，如果连这也不能信任的话，那所有的AFH实际上都是不适任的。Sanmosa _{热烈庆贺“关注度”正名“收录标准”} 2025年1月17日 (五) 06:10 (UTC)

复杂度方面就是允许过滤器助理发起测试（在无动作过滤器中进行），实际更改仍由管理员执行。这样说是否更清楚一些？--HeihaHeihaHa-戒慎恐惧……（留言） 2025年1月17日 (五) 06:05 (UTC)

确实清楚些了，感谢。Sanmosa _{热烈庆贺“关注度”正名“收录标准”} 2025年1月17日 (五) 06:11 (UTC)

如果没有积压，为什么AFH（原AFE为笔误）会想成为AFE？或者，对AFE提出更高工作要求就好，例如每月有效修改大于5笔。--YFdyh000（留言） 2025年1月17日 (五) 08:54 (UTC)

不赞同这种KPI式的要求，我很担忧这相当于逼迫AFE为此而处理不恰当的请求。Sanmosa _{热烈庆贺“关注度”正名“收录标准”} 2025年1月17日 (五) 09:47 (UTC)

如果无意愿经常编辑，请现有AFE协助就好。这避免所谓帽子问题，以及安全问题。--YFdyh000（留言） 2025年1月17日 (五) 10:05 (UTC)

我的意思是，申请AFE的人一开始是有意愿经常编辑的，但可能到头来真的能接的请求不一定有5个，这与AFE的主观意愿无关。Sanmosa _{热烈庆贺“关注度”正名“收录标准”} 2025年1月17日 (五) 10:07 (UTC)

既有高度信任，过滤器编辑者应该能直接但慎重地维护过滤器，而非只受理用户提报？且某些反破坏请求难以公开提报和讨论。如果过滤器编辑者不能保持在此领域的活跃，谨慎上任、积极解任是适当的。--YFdyh000（留言） 2025年1月17日 (五) 10:42 (UTC)

我就只回应后半句：然而管理员也同样有AFE的权限，因此就算AFE有在此领域活跃的主观意愿，在管理员（不为意地）抢AFE的KPI的情况下，这会导致AFE无法达到这个“拍脑袋”定出来的KPI，继而导致中文维基百科最后根本没有人出任AFE。Sanmosa _{热烈庆贺“关注度”正名“收录标准”} 2025年1月17日 (五) 10:47 (UTC)

不会，如果AFE没有事可做，说明不需要他担任AFE来协助管理员工作。如果一个月太短，按3个月、平均每个月5次，也是可以的。--YFdyh000（留言） 2025年1月17日 (五) 10:52 (UTC)

原始讨论串里最上面就有提到“防滥用过滤器错误报告和防滥用过滤器请求积压”是提议AFH扩权/设立AFE的原因，由此可见编辑非公开过滤器的需求是存在的，但一旦某位管理员突然一下子清了所有的防滥用过滤器错误报告和防滥用过滤器请求积压，AFE就无法满足KPI。你在这种情况下认定这代表该等用户不需要担任AFE，然而“某位管理员突然一下子清了所有的防滥用过滤器错误报告和防滥用过滤器请求积压”本质上只是偶发事件。Sanmosa _{热烈庆贺“关注度”正名“收录标准”} 2025年1月17日 (五) 11:18 (UTC)

如果现有管理员能使AFE在三个月里基本无事可做（包括主动维护过滤器来反破坏），AFE卸任、以后有需求再重新申请上任，即可。--YFdyh000（留言） 2025年1月17日 (五) 11:28 (UTC)

这会打击AFE的积极性。zhwiki是个志愿社群，积极性很重要。Sanmosa _{热烈庆贺“关注度”正名“收录标准”} 2025年1月18日 (六) 00:41 (UTC)

不可能所有好处都得到。如果群组目的是弥补管理员积压，为什么需要尸位素餐者的积极性，闲置退位为何会打击，除非上位/在位成本过高而变成帽子和工作。IPBE等权限会因闲置半年被移除，也打击了用户回归的积极性。从安全及了解近期动态来说，离任过久会不熟悉状况。这难道不是解决了您所担心的帽子问题，偶尔编辑者请其他人代办。--YFdyh000（留言） 2025年1月18日 (六) 16:40 (UTC)

我的意思是既然已经有半年不活跃除权的基本门槛，那就不要额外设置与能力无直接关系的门槛。Sanmosa _{热烈庆贺“关注度”正名“收录标准”} 2025年1月19日 (日) 02:28 (UTC)

指半年不编辑？那太容易达到，无法解决您担心的持有帽子问题、其他人担心的影响全站安全问题。--YFdyh000（留言） 2025年1月19日 (日) 12:08 (UTC)

我担忧的“帽子”是权限组分立，只要权限组不分立，那我担忧的“帽子”就不存在。至于所谓的“全站安全问题”，我倾向于是个别用户的极端看法而已，中文维基百科的社群不能被极端看法骑劫。Sanmosa _{热烈庆贺“关注度”正名“收录标准”} 2025年1月19日 (日) 12:49 (UTC)

权限数权限组不当饭吃，只要当成临时性的通行便利、及时清除低使用率，没必要担心帽子问题。安全隐患确实存在，分立权限有助减少攻击面。--YFdyh000（留言） 2025年1月19日 (日) 13:06 (UTC)

如我之前意见，该权限事关重大可影响全站，即便真的要设，也应采与界面管理员同等规格的选举方式以落实可信度。（这也是解决帽子王问题的更好方法。关于帽子问题我再多说一点，现在的过滤器组才是真正的帽子王，复制前一个人的理由就可以申请极其容易，可能有一半的人确实做出了贡献，但另一半人完全看不出除了收集帽子以外的其他目的。）。->>Vocal&Guitar->>_留言 2025年1月19日 (日) 00:05 (UTC)

我不确定Phabricator那边是否能答应这种请求，Phabricator那边已经对于我们为每个候选人分置投票页面的做法表示不满了。Sanmosa _{热烈庆贺“关注度”正名“收录标准”} 2025年1月19日 (日) 02:27 (UTC)

单选界面管理员目前无需安全投票。->>Vocal&Guitar->>_留言 2025年1月19日 (日) 23:44 (UTC)

不正确，现时参选界面管理员者也同样需要走安全投票程序，只是恰好没有人单独参选界面管理员而已。Sanmosa _{热烈庆贺“关注度”正名“收录标准”} 2025年1月21日 (二) 06:18 (UTC)

从Wikipedia:过滤器助理的描述来看，社群并未要求过滤器助理一定要维护防滥用过滤器，亦有“有意利用不公开过滤器及过滤器日志项目进行反破坏工作，但不拥有管理员权限的用户”、“在其他维基媒体项目站点上负责维护防滥用过滤器，有意借鉴中文维基百科经验的用户。”另一半人完全看不出除了收集帽子以外的其他目的 这一说法可能不完全恰当。--HeihaHeihaHa-戒慎恐惧……（留言） 2025年1月19日 (日) 03:13 (UTC)

AFH的工作不一定是为维护过滤器服务的，这或许也是设立AFE组的一个理由--HeihaHeihaHa-戒慎恐惧……（留言） 2025年1月19日 (日) 03:17 (UTC)

希望你说的是真的，但实务中我仍然倾向我的观点。->>Vocal&Guitar->>_留言 2025年1月19日 (日) 23:44 (UTC)

所以该要求“过滤器助理”定期提供（准备好）“工作报告”吗，已用于哪些事项。--YFdyh000（留言） 2025年1月19日 (日) 12:11 (UTC)

倾向没有必要，至多是全站只读化？界面管理员是真正影响全站访客的可用性和安全。对于异常过滤，如果管理员及过滤器编辑者活跃，及时改回来？如果再有自动化机制（过滤器匹配率，或者机器人什么的）来进一步复检敏感操作，就更没问题。--YFdyh000（留言） 2025年1月19日 (日) 12:14 (UTC)

全站只读不够严重？如果管理员足够活跃，那其他所有权限都不必存在了。->>Vocal&Guitar->>_留言 2025年1月19日 (日) 23:44 (UTC)

不严重。争议事件难找，与紧急事件找不来任何管理员、过滤器编辑员及监管员是两个层面，以及我说了可以做自动化预防。过滤器编辑 < 管理员 < 服务器故障下的网站不可用 < 界面管理员。--YFdyh000（留言） 2025年1月20日 (一) 01:12 (UTC)

全站只读即使找不来任何管理员和其他AFE，过滤器也会因为高触发率而很快被自动关闭，技术上的预防措施是比较完善的。--HeihaHeihaHa-戒慎恐惧……（留言） 2025年1月20日 (一) 10:05 (UTC)

我看过文档，但不确定"阻止"编辑在本站是否被配置为不考量触发率的"safe" actions。--YFdyh000（留言） 2025年1月20日 (一) 15:13 (UTC)

从only "safe" actions are allowed (the ones that can warn or prevent the ongoing action)看来阻止编辑属于"safe" actions了，被Emergency throttling限制的过滤器仍可以采取prevent the ongoing action，全站只读确实是可能的。( π )题外话，触发率的考量好像和过滤器的采取的行动无关？--HeihaHeihaHa-戒慎恐惧……（留言） 2025年1月21日 (二) 04:47 (UTC)

本地配置没有这项，应该是用的缺省配置，全站只读不在此列。𝐻.𝑁𝑎𝑡𝑠𝑢𝑚𝑖 ™ 2025年1月22日 (三) 10:38 (UTC)

有鉴于VPP过长，改走RFC。Sanmosa _{热烈庆贺“关注度”正名“收录标准”} 2025年1月19日 (日) 08:46 (UTC)