维基百科讨论:過濾器助理

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

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

至少应该禁止利用过滤器实现条目保护、账户封禁、编辑禁制之类一般认为是管理员权限范围的操作。--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)