跳转到内容

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

页面内容不支持其他语言。
维基百科，自由的百科全书

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

本主题或以下段落文字，移动自WP:互助客栈/方针。执行者：亲，我签名那刻的时间是 2024年12月22日 (日) 08:36 (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)[回复]
至少应该禁止利用过滤器实现条目保护、账户封禁、编辑禁制之类一般认为是管理员权限范围的操作。--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)[回复]
plus 已添加——敬颂冬绥 ZhaoFJx(论•签) 2024年12月6日 (五) 16:49 (UTC)[回复]

修改申请标准和流程

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

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

现行条文

申请程序 如果您有意申请过滤器助理的权限，请亲自到Wikipedia:权限申请/申请过滤器助理权限申请，或接受其他用户于该页发起的提名。

以下使用者不需要去申请或是为他们增加本权限，他们本身已经获自动授予同等的权限：

  • 管理员
提议条文

申请程序 符合申请过滤器助理要求者，可循一般程序，在权限申请页申请成为过滤器助理。

提出申请后，具有管理员、回退员或过滤器助理权限的用户可以提出问题，并自行按其认知支持或反对申请，惟须附上有效理由。在申请人明显不符合条件的情况下，一名管理员或过滤器助理可以快速关闭此申请。申请以七日为限，七日后如总有效票数大于等于四票，且满足以下条件符合以下条件，则一名管理员或过滤器助理可以结案并授予过滤器助理权限：

  1. 支持率在50%以上； 社群就授予权限达成合意；
  2. 没有管理员或过滤器助理反对。

或：

  1. 有效票数大于等于四票；
  2. 支持率在80%以上；
  3. 没有管理员反对。

以上。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%尚不清楚会不会太高，就先观望一下，看实操结果如何。--（☎）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)[回复]
检索自“https://zh.wikipedia.org/w/index.php?title=Wikipedia_talk:過濾器助理&oldid=85405311”