维基百科

维基百科讨论:回退功能/存档2

< Wikipedia talk:回退功能
最新留言：9个月前由Jimmy-bot在话题再提重组用户权限组内发布

将Wikipedia:回退功能#移动时不留重定向合并到Wikipedia:重定向#移动时不留重定向

最新留言：3年前27条留言5人参与讨论

本主题或以下段落文字，移动自WP:VPP。执行者：SANMOSA 江南好，风景旧曾谙 2021年3月17日 (三) 06:03 (UTC)。

通过。SANMOSA 江南好，风景旧曾谙 2021年3月17日 (三) 06:00 (UTC)
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

理由如下：

  1. 此权限跟Wikipedia:回退功能没有太大的关连，个人认为纯粹是回退权里包含此权限因此写入此处
  2. 有几率导致像是Wikipedia_talk:重定向#分类重定向的情况

-- Sunny00217  2021年2月11日 (四) 16:08 (UTC)

WP:回退员重定向到回退功能页面。“如有违反前述原则，当以除权处理。”对方针有意义，需要解决。--YFdyh000（留言） 2021年2月11日 (四) 16:12 (UTC)
Suppress redirect 也与反破坏有关，不认为完全无关联。 2021年2月11日 (四) 16:14 (UTC)
因为连巡查员也有-- Sunny00217  2021年2月12日 (五) 06:36 (UTC)
与反破坏有关+1。但若欲改为留下连结，合并重复内文于一处，使未来容易维护，亦无不可。--Hjh474（留言） 2021年2月12日 (五) 02:34 (UTC)
现拟议修改WP:重定向、WP:回退功能、WP:新页面巡查如下：
WP:重定向：
现行条文

移动时不留重定向

主页面：Wikipedia:回退功能 § 移动时不留重定向
快捷方式

一般来说，移动页面时，会自动留下重定向。某些用户组（拥有suppressredirect权限的用户）可以通过取消选中标有“保留重定向”的框来阻止创建重定向，称为移动时不留重定向（suppressing redirect）。目前，这些群组包括管理员、巡查员、回退员等。在某些情况下，移动页面时自动创建的重定向是不恰当的——例如文章曾被移动破坏至不良标题。不留重定向即可节省移动后删除重定向的时间和麻烦。

一般情况下，重定向是历史纪录中一个有用的条目，所以除非有充分理由移动时不留重定向（例如故意破坏，将放错位置的内容转移到用户空间或释放标题以便另一页面占用），最好将其留下。重定向留下帮助读者找到旧文章一条线索，以防在其先前位置创建新文章，并防止连结失效。因此，我们通常既不移动时不留重定向，也不删除重定向。

提议条文

移动时不留重定向

快捷方式

一般来说，移动页面时，会自动留下重定向。某些用户组（拥有suppressredirect权限的用户）可以通过取消选中标有“保留重定向”的复选框来阻止创建重定向，称为移动时不留重定向（suppressing redirect）。目前，这些群组包括管理员、巡查员、回退员等。在某些情况下，移动页面时自动创建的重定向是不恰当的——例如文章曾被移动破坏至不良标题。不留重定向即可节省移动后删除重定向的时间和麻烦。移动而不留重定向依旧会记录在案，不过会加上“不留重新导向”的标示。

一般情况下，重定向是历史纪录中一个有用的条目，所以除非有充分理由移动时不留重定向，最好将其留下。重定向留下帮助读者找到旧文章一条线索，以防在其先前位置创建新文章，并防止连结失效。因此，我们通常既不移动时不留重定向，也不删除重定向。

何时可移动而不留重定向 当重定向符合快速删除方针，特别是G3（故意破坏）、O1（应用户要求在该用户空间下移动页面或从该用户空间下将页面移动到主名字空间），或将放错位置的内容转移到用户空间，或须释放标题（腾空页面）以便另一页面占用时候，即可移动而不留重定向。

何时不可移动而不留重定向 用户不得利用权限于命名争议中夺取优势、无视命名争议而使用权限或者将权限用于破坏。巡查员、回退员如有违反前述原则，当以除权处理。

WP:回退功能：
现行条文

移动时不留重定向 移动页面时，预设会留下重定向。然而，有时留下重定向会增加后续工作，并不理想，例如回退页面移动破坏，又或者需要腾空页面以便移动其他页面。当拥有“移动时不留重定向”权限时，移动页面时就可以于移动页面界面取消剔选“留下重新导向页面”框框。如此，就可以移动页面而不留重定向。移动而不留重定向依旧会纪录在案，不过会多一句“不留重新导向”。

何时可移动而不留重定向 当重定向符合快速删除方针，特别是G3、O1，即回退移动破坏或应用户要求在该用户空间下移动页面或从该用户空间下将页面移动到主名字空间。

何时不可移动而不留重定向 用户不得利用权限于命名争议中夺取优势、无视命名争议而使用权限或者将权限用于破坏。如有违反前述原则，当以除权处理。

提议条文

移动时不留重定向

主页面：Wikipedia:重定向 § 移动时不留重定向
WP:新页面巡查：
现行条文

移动时不留重定向

主页面：Wikipedia:回退功能 § 移动时不留重定向

移动页面时，预设会留下重定向。然而，有时留下重定向会增加后续工作，并不理想，例如回退页面移动破坏，又或者需要腾空页面以便移动其他页面。当拥有“移动时不留重定向”权限时，移动页面时就可以于移动页面界面取消勾选“留下重新导向页面”复选框。如此，就可以移动页面而不留重定向。移动而不留重定向依旧会纪录在案，不过会多一句“不留重新导向”。巡查员运用此权限时，应遵守回退功能方针相关段落规定。

提议条文

移动时不留重定向

主页面：Wikipedia:重定向 § 移动时不留重定向

以上。如通过，有关移动时不留重新导向权限的规定将统一整合至WP:重定向（包括有关除权规定），而WP:回退功能与WP:新页面巡查则只留下章节连结。SANMOSA SPQR 2021年2月18日 (四) 01:15 (UTC)

@Sunny00217、YFdyh000、Pseudo Classes、Hjh474。SANMOSA SPQR 2021年2月18日 (四) 01:17 (UTC)
没什么意见。把“纪录”更正“记录”吧。--YFdyh000（留言） 2021年2月18日 (四) 01:27 (UTC)
@YFdyh000： 完成。SANMOSA 誓山海而长在，似日月而无休 2021年2月20日 (六) 02:22 (UTC)
@YFdyh000：名词是用“纪录”没错，动词才是“记录”。我改的一处正是本是动词的地方。SANMOSA 誓山海而长在，似日月而无休 2021年2月20日 (六) 02:37 (UTC)
不是名词动词问题吧，纪录用于成绩统计层面（纪录片除外），记录才是文字层面。难道有地区词差异。--YFdyh000（留言） 2021年2月20日 (六) 02:51 (UTC)
@YFdyh000：《文书处理手册》附录2（第60页）。（意外发现地区词差异）SANMOSA 誓山海而长在，似日月而无休 2021年2月20日 (六) 03:05 (UTC)
有点搞不清，可能需另议或字词转换……在中国大陆，纪录主要是最好成绩或总结归纳，会议记录、历史记录等不会写纪录，个人健康纪录也一般是“个人健康记录”。此博客提到文书所用动词/名词分法，但评论也有不同意见。--YFdyh000（留言） 2021年2月20日 (六) 04:11 (UTC)
@YFdyh000：恐怕不能用字词转换处理，因为误转几率太高：有些地方的使用是一样的，但有些地方的使用是完全不同的。《文书处理手册》是台湾官方文件，我给予的连结也是政府网站链接，我认为没办法质疑。繁体来说是会写“会议纪录”、“历史纪录”的（至少前者我非常肯定）。SANMOSA 誓山海而长在，似日月而无休 2021年2月20日 (六) 04:18 (UTC)
指在方针指引页（如Wikipedia:R）转换。浏览器的“历史记录”我是很确定的。--YFdyh000（留言） 2021年2月20日 (六) 04:36 (UTC)
（1）问题完全一样，在任何地方转换都会出现一样的问题。（2）科技公司经常会忽略地区用词差异，不能作准。SANMOSA 誓山海而长在，似日月而无休 2021年2月20日 (六) 07:56 (UTC)
你这一“不能作准”，中国大陆所有软件和文献就都是错的了。我非常确定99%+将History称作历史记录，历史纪录是Best record。在此题中讨论可能不大合适。--YFdyh000（留言） 2021年2月20日 (六) 08:06 (UTC)
@YFdyh000：至少在繁体不能作准吧。如果是中国大陆公司开发的browser，在中国大陆简体下反而是可以作准的。如果没其他问题的话，我就不再修改提案了。SANMOSA 誓山海而长在，似日月而无休 2021年2月20日 (六) 13:57 (UTC)
代为标示{{新增条文}}，请帮确认有无错漏。--Hjh474（留言） 2021年2月18日 (四) 02:17 (UTC)
{{删除条文}}也加上了。SANMOSA SPQR 2021年2月18日 (四) 02:26 (UTC)
原来巡查权那里也有一段-- Sunny00217  2021年2月18日 (四) 03:10 (UTC)
是不是需要公示贴公告板？--Hjh474（留言） 2021年2月26日 (五) 02:46 (UTC)
@Hjh474：你是不是忘了WP:7DAYS？SANMOSA 江南好，风景旧曾谙 2021年3月1日 (一) 10:25 (UTC)
  赞。--Hjh474（留言） 2021年3月1日 (一) 10:29 (UTC)
现公示7日。SANMOSA 江南好，风景旧曾谙 2021年3月10日 (三) 10:38 (UTC)
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

下放移动主页面时一并移动子页面权限

最新留言：2年前25条留言8人参与讨论

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

我在上方#提议设立维护员权限的讨论中提到可以下放move-subpages权限予巡查员、回退员等用户，现在我会提出具体提案，内容如下：

  • 权限内容：移动主页面时一并移动最多100个子页面
  • 下放对象：巡查员、回退员、界面管理员
  • 下放原因：方便回退员更有效率地回退涉及子页面的移动争议及破坏，方便巡查员、模板编辑员、界面管理员于为存在子页面的页面更名时更有效率地完成更名操作

就以上内容，现提出新增以下方针：

Wikipedia:界面管理员
Help:页面重命名（设为章节方针）
Wikipedia:新页面巡查、Wikipedia:回退功能、Wikipedia:模板编辑员

以上。可分别讨论巡查员、回退员、模板编辑员、界面管理员是否适合拥有此权限。Sanmosa Outdia 2021年9月25日 (六) 03:31 (UTC)

(＝)中立，但建议给有suppressredirect的。--安忆Talk 2021年9月25日 (六) 05:15 (UTC)
注：有suppressredirect权限者包括管理员（本已有move-subpages权限）、巡查员、回退员。Sanmosa Outdia 2021年9月25日 (六) 08:01 (UTC)
看了看后续讨论，感觉这个权限比较适合用来批量移动Mediawiki:xxx/* User:xxx/*，而不是用在和条目有密切关系的空间。--安忆Talk 2021年9月26日 (日) 16:19 (UTC)
(＋)倾向支持：有时候移动一个页面还要检查一大堆子页面真的很痛苦。—— Eric Liu 创造は生命（留言．留名．学生会） 2021年9月25日 (六) 12:53 (UTC)
由于本功能的问题，使用本功能仍然要检查一大堆子页面，因此并没有方便许多。--Xiplus#Talk 2021年10月4日 (一) 03:31 (UTC)
先想想有什么具体情况会用到这个权限，才会知道对不同使用者群组的是否真的有帮助，找找曾经动用过本权限的具体案例对讨论应相当有帮助。例如提案中“回退涉及子页面的移动破坏”，破坏者通常没有移动子页面权限，我移动破坏还给你乖乖按著子页面结构移动？当然是给你乱移动啊，因此“回退涉及子页面的移动破坏”根本不切实际。--Xiplus#Talk 2021年9月26日 (日) 01:16 (UTC)
@Xiplus：或许我更正一下字眼：“移动争议及破坏”。我不排除有LTA真的会按著子页面结构移动，但考虑到更多情况下是编辑争议所引发的移动战，参与移动战的用户自然会按著子页面结构移动，因此为回退移动战，有必要授予此权限予回退员。Sanmosa Outdia 2021年9月26日 (日) 01:25 (UTC)
不反对您的说法啦，但无法说服我...移动子页面的功能其实限制多，所以很难用，只有简单的情况我才会去用它，不然都是一个一个移动比较稳当，所以我觉得很难用来处理移动战。退一步来说就算能够处理，回退员没有足够的权力来制止移动战，只有管理员才有（即保护），回退员使用此权限也只是参与移动战而已，而不是处理移动战。--Xiplus#Talk 2021年9月26日 (日) 12:28 (UTC)
容许我举之前的一个解除权限申请的案例：Antigng的提请理由是“在没有附上编辑摘要的情况下回退争议性编辑，有违回退方针对这种回退仅限于明显非建设性编辑的限定”，我当时给的意见是“恢复编辑战发生前的最后一个稳定版本是标准的编辑战处理程序，基本上就是等管理员来保护而已”，结案的管理员Shizhao在我的意见的基础上否决了除权申请。我认为只要回退员尽其所能恢复编辑战发生前的最后一个稳定版本，那就已经算是某程度上的“处理”了，就算不是“处理”，也肯定是协助处理。Sanmosa Outdia 2021年9月26日 (日) 14:26 (UTC)
不同意，Wikipedia:保护方针#使用和处理编辑请求：“若页面出现编辑争议需要全保护，管理员可以在执行保护之后，由保护的管理员本人将页面回退到争议发生前的较早版本”，仅有执行保护的管理员本身可以决定是否要回退，若执行保护的管理员决定不回退，其他管理员也没有权力回退，更不用说保护前回退员的回退行为，认定为处理编辑战完全不正确。--Xiplus#Talk 2021年9月26日 (日) 15:23 (UTC)
划线：“执行保护之后”。如果回退员在管理员施行保护前已经恢复编辑战发生前的最后一个稳定版本，那管理员自然在施行保护后不会进行回退，这可以算是为管理员省工夫，因此应该被认定为“协助处理”。Sanmosa Outdia 2021年9月29日 (三) 05:51 (UTC)
回退员不能保证在封禁/保护前是否会被再次回退，除非破坏内容相当严重（需要OS之类的），否则回退员不应坚持持续进行“反破坏战”，仅冲刷页面历史而无明显益处，使用该权限对大量页面进行“反破坏战”我更要反对了。--Xiplus#Talk 2021年9月29日 (三) 08:45 (UTC)
刚刚试了一下。大家应该都知道目标页面存在时是无法移动过去的，管理员在移动界面会有一个额外选项是“移动同时删除目标页面”，但在移动子页面时，就算勾了这个选项，只要某个子页面目标页面存在，该子页面的移动会在没有任何提示的情况下失败，而其他页面会移动成功，造成部分页面未移动而分隔两地，就算回退员发现该情况，也没有删除权限来修复，只会让情况变得更糟。--Xiplus#Talk 2021年9月26日 (日) 12:45 (UTC)
@Xiplus：理论上可以通过把目标页面临时移开来解决（回退员有suppressredirect权限）。不知道能不能跟PHAB提议一下在使用移动主页面时一并移动子页面权限时，如果某个子页面的目标页面存在而导致移动失败，系统能给个失败提示。Sanmosa Outdia 2021年9月26日 (日) 14:26 (UTC)
我自己是反对这样的操作，就算回退员移动开页面，仍然需要管理员来执行删除，回退员抢先操作并没有减轻管理员的工作量，反而将页面移动到不相干的名称，让删除日志保存在其他名称之下，变成一个缺点。虽然问题很小，但我仍然认为这是对suppressredirect的滥用。--Xiplus#Talk 2021年9月26日 (日) 15:31 (UTC)
这个要直接上报phab了吧？-- Sunny00217  2021年10月5日 (二) 14:56 (UTC)
另外，也考虑到回退员有suppressredirect权限，可以协助处理移动请求（巡查员同），因此授予此权限予回退员亦可令回退员在协助处理移动请求上更为便利（我预想到的情况是{{Infobox road2}}）。Sanmosa Outdia 2021年9月26日 (日) 01:28 (UTC)
至少我能确定模板编辑员不会用到这个权限，如果要移动受模板保护的模板，必须待社群有共识才能移动，那么由管理员执行就够了，反正移动的积压也不严重，更不用说同时移动子页面。就需求来说，模板编辑员应该比较需要转换内容模型的权限，毕竟光是测试CSS就要从模板移动到使用者页面（我不相信CSS沙盒），太累了。 2021年9月28日 (二) 12:33 (UTC)
那可以把模板编辑员排除掉。Sanmosa Outdia 2021年9月29日 (三) 05:51 (UTC)
已去除，不存档至Wikipedia talk:模板编辑员。 2021年9月29日 (三) 14:37 (UTC)
应该正面表列“可以使用的情况”，这才能做为支持该提案成立的理由，“为存在子页面的页面更名时更有效率地完成更名操作”是对于该功能的描述而不是下放权限的理由。--Xiplus#Talk 2021年10月4日 (一) 03:37 (UTC)

再提拆分回退员之私密过滤器源码阅读权至另一用户组

最新留言：1年前118条留言21人参与讨论

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

过往多次讨论见Wikipedia_talk:防滥用过滤器#提议修改维基百科:防滥用过滤器。简介:鉴于目前回退员中有内鬼，过往数年泄漏过滤器详情，导致反破坏工作受到不少影响。此事亦进一步影响到回退员可否兼领其他权限(如LTA private wiki的阅读权限)的质疑，导致反破坏权限改革无法推进。

为此，再次建议拆分回退员之AF源码阅读权(abusefilter-view-private)，以收紧其获得人数。该新用户组的成员应高度可信，且在反破坏工作中保持活跃。

请诸君讨论。--Temp3600（留言） 2022年10月30日 (日) 12:24 (UTC)

个人倾向(＋)支持，但应该考量到之前提出的问题（如对过滤器并没有那么了解的回退员间接造成接触到的资讯差异）。我是有想过一折衷方案（前提是技术上可行）：过滤器触发时只截取出触发的部分，而非显示过滤器完整结构。这样也能帮助看不懂AF是做什么的回退员比较能够理解触发原因。-- （☎）dt 2022年10月31日 (一) 01:50 (UTC)
哇你这想法有点天方夜谭诶，过滤器做不到这一点，或者说我就没见过哪儿有能展示这种信息的东西。GDB和LLDB我都没印象有这种工具诶（--MilkyDefer 2022年10月31日 (一) 02:09 (UTC)
如果连回退员都看不懂触发器语法的话，要这个权限有什么意义，还不如支持AF助理方法，让懂得人自己去检查或者协助修改AF。而且展示出触发的语法部分估计现在AF的实现根本没有这样的功能，还要mw开发组来实现（或者自己推修改补丁）。只能说有点异想天开。——Sakamotosan路过围观 | 避免做作，免敬 2022年10月31日 (一) 02:19 (UTC)
程序上极难实现，只能人工处理，那似乎等同条文上允许某种“查阅请求”。--YFdyh000（留言） 2022年10月31日 (一) 02:28 (UTC)
那算了（看到时全域有没有这个需求、mw开发出来再说，原本只是想有没有人写个小工具就可以解决），就把abusefilter-view-private去掉就好。“另一使用者群组”可以考虑由回退员之间选出，之后由管理授权吧。-- （☎）dt 2022年10月31日 (一) 03:49 (UTC)
(＋)强烈支持。--路西法人 2022年10月31日 (一) 03:31 (UTC)
(！)意见：上一次讨论进行了近四个月，最终也没能达成共识。“共识是可以改变的，但如果你要提出类似的提案，应该解决过去的反驳意见”（WP:常年提案）。个人想知道此次讨论较上次讨论有何变化？另外，似乎最近由过滤器详情泄露引起的破坏有所减少？--Yining Chen（留言|签名页） 2022年10月31日 (一) 05:53 (UTC)
上一次的讨论一开始没有考虑分拆，而直接将权限收回管理员，引起不满；后来又因为ip masking导致困难重重。这次只处理核心部分，即AF分家。其他问题容日后再处理。--Temp3600（留言） 2022年10月31日 (一) 10:03 (UTC)
更改一下说法，IP masking方面问题不大。 Stang★ 2022年11月11日 (五) 19:10 (UTC)
感谢补充，但仍建议下一步再处理此问题。--Temp3600（留言） 2022年11月17日 (四) 04:35 (UTC)
我记得上次诸位就是同意居多，问题似乎在技术阻碍？个人对此提议自然是(＋)支持。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年10月31日 (一) 07:27 (UTC)
上次是提到了phab:T309318。如果不考虑IP masking的话就应该没事。 ——魔琴 [ 留言 贡献 ] 2022年10月31日 (一) 08:01 (UTC)
对建立反LTA类型的用户组无异议，但希望同期建立有效、便捷渠道或规则为可信用户处理相关咨询，如回退员的合理询问和建议，以解决部分用户的偶发需求。--YFdyh000（留言） 2022年10月31日 (一) 07:37 (UTC)
这方面我有一计，但暂时想不出要怎样配合中维的情况来实施：强化维基百科:反破坏工作小组的职能，将建立为“反破坏专家”的公会。--Temp3600（留言） 2022年10月31日 (一) 14:42 (UTC)
能不能提出什么具体议案或者说服力的理据，“仿佛剧团每隔一段时间重复演出同样的戏码”，我是比较无奈的。上次不是说要将IPInfo和IP masking合并到这个新的用户组，然后就没下文了。--Ghren🐦🕓 2022年10月31日 (一) 09:09 (UTC)
这次希望先解决目前的问题，IP masking目前还没有起色，合并进来的话就搞不下去了。--Temp3600（留言） 2022年10月31日 (一) 10:03 (UTC)
之前的讨论参考了YF君提供的意见，我提出的意见的确有舍本逐末之嫌。既然回退员主要工作是快速回退破坏，那么侧重点应当是对回退相关方针的理解程度至少可以让社群信服做与反破坏相关的工作。而不是技术（例如私密滥用过滤器）能力，因为其侧重点无法保证回退员具备此种能力或与其相对应的操守。所以(＋)支持拆分权限。--绍💓煦集思广益 2022年11月5日 (六) 07:44 (UTC)
(＋)支持拆出Wikipedia:过滤器助理。--冥王欧西里斯（留言） 2022年11月5日 (六) 12:37 (UTC)
感谢X43现身说法证明拆分的需要。--Ghren🐦🕙 2022年11月26日 (六) 14:48 (UTC)

名字与细则

过往的方案见Wikipedia:过滤器助理。欢迎各位讨论。--Temp3600（留言） 2022年11月5日 (六) 17:25 (UTC)

(＋)支持以上提案。--冥王欧西里斯（留言） 2022年11月7日 (一) 03:05 (UTC)

题外话

( π )题外话 如果有查看已删除页面的权限（browsearchive、deletedtext，deletedhistory不确定）或用户组，可能更方便某些任务（侵权、G5、破坏等历史页面的核查）。--YFdyh000（留言） 2022年11月8日 (二) 13:38 (UTC)
您是不是要找：WP:删除员，WP:维护员。[开玩笑的]--Yining Chen（留言|签名页） 2022年11月8日 (二) 14:11 (UTC)
准确说，去掉删除/恢复权限的“删除员”。不知道社群是否有兴趣加在新用户组上。目前是通过WP:AR，但时效性不好。--YFdyh000（留言） 2022年11月8日 (二) 14:59 (UTC)
？？去掉删除/恢复权限还算是什么删除员。--Ghren🐦🕓 2022年11月11日 (五) 08:45 (UTC)
你的逻辑是不是有点混乱？这也没说这是要启用删除员，这只是探讨一个与删除员类似，在具体权限上有所限制的<未知>而已。--MilkyDefer 2022年11月11日 (五) 12:42 (UTC)
所以我说的不是删除员，而是能查阅私有（非公开）记录的另一组权限，是否能合进去，参考蓝桌图书馆、已删百科等需求。已知新权限开放给高度可信用户，唯低于管理员。大多数已删除页面，只是出于维护，可能没有保密需求，需要保密的要监督。权限组可以命名如“非公开记录查看员”（Non-public record viewer）。--YFdyh000（留言） 2022年11月11日 (五) 13:31 (UTC)
你这个“非公开记录”很容易让人联想到真的要签字且具有法律效力而且大陆人不能签的NDA欸，你要不改个名字吧。--MilkyDefer 2022年11月11日 (五) 15:35 (UTC)
这是考虑到私有对应的private与“隐私”相同，担心误解。要不然，“私有记录查看者（Non-public record viewer）”，中英非一致译法。或者，进阶记录查看者，但表意很模糊。--YFdyh000（留言） 2022年11月11日 (五) 16:12 (UTC)
查阅员这个名字如何？可以查看AR，也可以查看过滤器。桐生ここ★[讨论] 2022年11月12日 (六) 04:19 (UTC)
很难，或者你需要让这个组拥有类RfA的授予标准（社群页面公布请求、不少于7天的投票云云）。 Stang★ 2022年11月11日 (五) 19:10 (UTC)
建议先完成分柝，再进一步调整，避免再次流产。--Temp3600（留言） 2022年11月14日 (一) 02:37 (UTC)
最近不授予回退权是不是和这有关？Evesiesta 2022年11月27日 (日) 17:07 (UTC)
不清楚，但应该没有关系。--Temp3600（留言） 2022年11月27日 (日) 18:53 (UTC)

初步方案

按旧稿修改了一份草稿:过滤器助理，请诸君讨论。--Temp3600（留言） 2022年11月15日 (二) 16:35 (UTC)

题外话#2：全域的m:Abuse filter helpers就是“过滤器助理”，不知道为什么要翻译成“防滥用编辑器帮助者”，是时候正名一下了（叫全域过滤器助理？会不会误以为是“全域过滤器”的助理？） ——魔琴 [ 留言 贡献 ] 2022年11月15日 (二) 16:46 (UTC)
@Liuxinyu970226：还在吗--Temp3600（留言） 2022年11月15日 (二) 17:14 (UTC)
赞成更名，“全域过滤器助理”挺好的。“帮助者”应只是粗译遗留。--YFdyh000（留言） 2022年11月16日 (三) 11:03 (UTC)
问题一：对比中维和英维的两个过滤器助理页面，英维是只有admin以上的用户有abusefilter-view-private权限，那在中维，abusefilter-view-private的权限应该是像现在一样，回退员也有，还是管理员以上的才有这个权限？
问题二：查看垃圾链接阻止列表日志这个权限在英维得是过滤器助理以上的用户才有，但是中维只要是个User就有了，要不要调整之类的。一直不理解为什么为什么过滤器39、92是不公开的，但是黑名单的阅读权限就放得这样低。（这算是个无关问题，只是刚好看到而已）
问题三：启用双重身份验证有这个需要嘛？在我的眼中这不是一个很重要的权限，不一定要双因素验证。--Ghren🐦🕘 2022年11月16日 (三) 01:53 (UTC)
1. 英维的管理员数量多很多。讨论的不就是该权限从回退员移到低于管理员的新用户组吗。2. 不了解这个权限。3. 有一定必要，已知需求源自“潜伏”风险，而查看过滤器不留日志，可能难以感知账号被盗用？--YFdyh000（留言） 2022年11月16日 (三) 11:07 (UTC)
啊，抱歉，我看错了。问题一应该是这样：对比中维和英维的两个过滤器助理页面，英维是只有admin以上的用户有abusefilter-log-private权限（查看标记为私密的过滤器的过滤日志），那在中维，abusefilter-log-private的权限应该是像现在一样，回退员也有，还是管理员以上的才有这个权限？我复制的时候没看清楚。不好意思。我想知道“查看标记为私密的过滤器的过滤日志”这个权限是也是收回，还是继续保留在回退员上比较好。--Ghren🐦🕘 2022年11月16日 (三) 13:04 (UTC)
一起移入新用户组。--YFdyh000（留言） 2022年11月16日 (三) 22:05 (UTC)
现在完全没有讨论要取消回退员abusefilter-log-private权限。也看出不出这个方案打算这样办。过去共识看来也不打算这样办。那是否要重复给这新用户组这个权限就是个问题。要从回退员手中收回这个权限，要更深的讨论。--Ghren🐦🕚 2022年11月17日 (四) 03:36 (UTC)
本提案讨论的是解除回退员的abusefilter-view-private权限；英维也是User持有，为什么放的这么低请参阅gerrit:405670；“须有良好账户保安操守，例如开启双重认证（2FA）、设立高强度密码、电脑不受恶意程序感染等”。 Stang★ 2022年11月16日 (三) 12:37 (UTC)
  • 感谢各位的回应。“拆分回退员之私密过滤器源码阅读权至另一用户组”指的是移除回退员的abusefilter-view-private权限，并邀请社群中仍希望保留该权限的用户申请加入新用户组。回退员的abusefilter-log-private权限不在本讨论范围，但由于新用户组的成员可获得log-private权限，该权限获得人数将可能上升。--Temp3600（留言） 2022年11月17日 (四) 04:45 (UTC)
    方案草稿中“资格要求”的第六点，在实际实行中似乎很难做到。缺乏有效的方式证明某用户是否可信。--Yining Chen（留言|签名页） 2022年11月17日 (四) 11:12 (UTC)
    我看英维这一条也是自由心证而已，总之没有人对这一点提出质疑就算是过关。--Temp3600（留言） 2022年11月17日 (四) 14:54 (UTC)
    显然是基于共识，消除合理质疑。可能需要如一周或两周的公示期。--YFdyh000（留言） 2022年11月17日 (四) 15:25 (UTC)
    确实缺乏有效的方式，共识制要求社群成员的绝大多数对于何为可信任有良好的认知，并有良好的说理能力。但我不认为我们的社群能达到这个要求。英文维基百科以我有限的观察也只能说是勉强达到。实际做起来，做还是能做的，但多少会把问题积累起来到以后产生比较大的麻烦。--Tiger（留言） 2022年11月22日 (二) 17:03 (UTC)
    坦率说，在中维上高度可信要求可能无法严格地执行。但考虑到目前回退员持有view权是"没有要求"，本项至少能收紧一些限制，并为解除不适合者的权限提供法规上的支持。--Temp3600（留言） 2022年11月27日 (日) 16:55 (UTC)
    尚且不谈中维潜在的地区（组织）割裂（不信任）问题，假若将标准放得如此低，那么是否反面说明不可信用户（潜在的破坏者）也可顺利担任回退员？换言之，假若该方案能够实施，那么就根本没有必要另设权限，只要找到“社群成员”对当前回退员列表逐一审查，把所有“不可信用户”都移权+封禁，即可解决问题。又若模拟权限设立后的“公示”，那么只要现在开放一个讨论，所有用户都可在其中指认自己认为“不可信”的回退员，最后统一公示一段时间以后直接移权即可，完全没必要设立新权限嘛。如果在措施不完善的情况下贸然设立一个新权限，恐怕无益于反破坏问题的解决，反而不如不设立AFH权限，而由管理员代为处理源码阅读请求。--Yining Chen（留言|签名页） 2022年11月28日 (一) 11:12 (UTC)
    首先，目前已经有破坏者现正担任回退员，这在上次的讨论已经有不少用户和管理员表达过。您所指的“排查回退员”方案，上次也有人提议过，但执行十分困难——部分回退员并不活跃，或已经退出一线反破坏工作多年，现行方针并无任何规则可用于解任他们，而且单凭猜疑，解任用权恰当但没有参与反破坏工作的回退员在实务上也不可行。现行机制的弱点，正是破坏者可以先混到回退员，然后保持低活跃状态，以此逃避反破坏小组的监视，而使用abusefilter-view-private权限亦无任何纪录可查，导致无任何方法可以找出此等内奸。其次，直接由管理员查阅的方案上一次也有讨论过（应该先上一次最先就是讨论此方案），并已经被社群驳回。--Temp3600（留言） 2022年11月29日 (二) 14:39 (UTC)
    您所说的“单凭猜疑”解任回退员，与“单凭猜疑”拒绝AFH申请有什么区别呢？--Yining Chen（留言|签名页） 2022年11月30日 (三) 01:55 (UTC)
    拒绝AFH申请的主要原因应是“用户不符合资格要求”，即身为回退员但未有在反破坏工作中活跃；自称将维护AF但没有兑现承诺等。这些都是客观的理由。至于分别，则在于AFH与回退员所需的信用等级不同。回退员如无法取阅敏感资料，则其权限可造成的破坏十分有限，要求先有违规行为后再解任依然合适；但AFH可以取得敏感资料，且缺乏监察途径，即使没有过违规行为，仍有可能不适合获权。--Temp3600（留言） 2022年11月30日 (三) 03:25 (UTC)
    那么该如何处理地域问题呢？作为例子，2022年9月管理员选举中有两名候选人被质疑“与WMC关系千丝万缕”“前与WMC的关系紧密”“WMC仍潜伏于社群中”，可见某些人至今仍不能做到对WMC成员在处理隐私信息（广义）方面的基本信任。该如何才能确保此类偏见在AFH的申请过程中不会出现，并且不会对申请过程造成干扰呢？或是说AFH权限不接受WMC成员（即大陆用户）的申请？--Yining Chen（留言|签名页） 2022年11月30日 (三) 05:22 (UTC)
    另设用户组仅是遵循最小权限原则。对于双面人问题，目前权限机制（无日志）不能解决，要依靠其他方法。--YFdyh000（留言） 2022年11月30日 (三) 07:05 (UTC)
    我承认这个问题很难回答。维基百科的底层逻辑是信任社群共识，而您的说法意指社群共识本身就存在偏见，要求以另一种权力来源来平衡共识，这涉及复杂的权力平衡设计，恐怕不是我几天内就能想像出来的。但或许我以下的观点可稍为安慰：大体而言，社群的权限投票还是讲证据的，在RFA的明票年代更是如此。计划中AFH的申请不是投票，也不会使用securepoll，申请人无须担心被流言暗箭攻击而无从反驳。--Temp3600（留言） 2022年12月3日 (六) 15:23 (UTC)

Kriz Ju的建议：提高对AFH的技术要求

  • (！)意见：个人支持方案草稿，综观上方站友讨论，个人对相关条文微调意见如下：
  • “申请程序”：“如果您有意申请过滤器助理的权限，请亲自到Wikipedia:权限申请/申请过滤器助理权限申请。申请时，经由至少一名已拥有此项权限的回退员，或者具备过滤器相关站务经验的管理员具名支持后，由具备过滤器相关站务经验的管理员综合评估授权；进行授权的管理员不可和前述的具名支持者为同一人。申请者若由于合理因素而无法完成申请条件，可考虑提出具体事由，在客栈寻求协助或发起讨论，而拥有相关站务经验的管理员应对于获得客栈讨论认可的申请者直接完成授权。”
  • “资格要求”：
  • 6.“经社群讨论，认可为高度可信之使用者”
  • 7.“申请者应对正则表达式有基本认识，并且须由拥有相关站务经验的管理员授权。”个人意见，供参。--Kriz Ju（留言） 2022年12月9日 (五) 19:33 (UTC) --Kriz Ju（留言） 2022年12月13日 (二) 11:12 (UTC)--Kriz Ju（留言） 2022年12月19日 (一) 17:38 (UTC)
( π )题外话 &   吐槽：您所编写的草案条文似乎使用了太多文言表述，导致其理解时有一定难度  囧rz……--Yining Chen（留言|签名页） 2022年12月11日 (日) 01:53 (UTC)
(！)意见：OK，已尝试直接依站友意见对上方条文进行异动。--Kriz Ju（留言） 2022年12月13日 (二) 11:12 (UTC)
(！)意见：个人的想法是，无论是否考评，只有同时具备专业能力和社群信任度的用户能获权，因此亦仅能由具备该领域能力的管理员授权，才具备某种程度之公信力，否则管理员自己本身一无所知又何以评估是否授权呢？至于具体考评，是比照其他权限可能出现的审核考评，其实也是考给社群看，以获公信，个人无甚意见，已依站友意见对上方条文意见调整文字，供参。--Kriz Ju（留言） 2022年12月19日 (一) 17:38 (UTC)
个人感觉这一要求略显严格，唯亦不失为确立其地位的策略。看看社群诸君还有没有什么意见了。--Temp3600（留言） 2022年12月27日 (二) 16:27 (UTC)
  • (！)意见：1.整个授权过程中涉及到两名以上管理员的参与，在实际实行过程中可能存在相当大的困难；2.“具备过滤器相关站务经验”在判断标准上可能存在问题。仅对过滤器进行小范围的修改并不能证明这名管理员就具备操作过滤器的能力。3.假若该提案通过，想要判断某名管理员是否进行过与过滤器相关的站务处理将变得比较困难。某些管理员可能主要编辑private过滤器，这样普通用户就无法对相关问题进行查证。另一方面来说，想要找到某名用户编辑过滤器的所有记录也相当困难，除非由社群仿照Wikipedia:监督/统计维护一个“管理员参与过滤器编辑的记录列表”。--Yining Chen（留言|签名页） 2022年12月31日 (六) 04:00 (UTC)
  • 既然社群没有进一步意见，暂时不提高要求。--Temp3600（留言） 2023年1月8日 (日) 14:27 (UTC)

第一阶段公示：确认分拆

现按上方的共识，进行第一阶段公示，确认将AF源码阅读权(abusefilter-view-private)从回退员权限中移除。本项的实施则预计在整套方案通过后一次过执行。现就此  公示7日。

新用户组的细则则仍属讨论阶段，诚邀各位就获权细则，除权条件等细节作深入讨论。--Temp3600（留言） 2022年11月27日 (日) 17:01 (UTC)

看来公示期结束了。那就等上边了。--Ghren🐦🕕 2022年12月6日 (二) 10:29 (UTC)
卡。--Temp3600（留言） 2022年12月19日 (一) 03:01 (UTC)

第二阶段公示：成立过滤器助理用户组

现按上方的共识，进行第二阶段公示，将草稿:过滤器助理确立为方针。通过后将成立相关的用户组。现就此  公示7日。先再讨论一下。--Temp3600（留言） 2023年1月9日 (一) 14:20 (UTC)

回退员的除权安排将在新用户组开放申请后再决定细节。--Temp3600（留言） 2023年1月8日 (日) 14:57 (UTC)

(－)反对：上方讨论显然不够充分，未能达到形成共识的程度。仅有三人参与的讨论，且其中还有未能解决的反对性意见，是否能称作“形成共识”？没人参与是否等于全部支持？如果反复在未能形成充分共识的情况下强行推进讨论，虽有WP:AGF，但恐怕仍有游戏共识形成程序的嫌疑。--Yining Chen（留言|签名页） 2023年1月9日 (一) 01:34 (UTC)
继续讨论当然很好，但得有人前来。看看下星期如何了。--Temp3600（留言） 2023年1月9日 (一) 14:34 (UTC)
(－)反对：根本就没明白过滤器助理究竟只是用来查看不公开过滤器的，还是用来修改过滤器的。申请所需要求远高于该组所具备的权限。--广雅 范★ 2023年1月9日 (一) 09:04 (UTC)
很明显没有修改过滤器的能力啊？--Ghren🐦🕓 2023年1月9日 (一) 09:06 (UTC)
补充了一下我的回复。想表明的是只是查看过滤器日志根本就没必要对正则表达式有基本认识、计划协助维护中文维基百科的过滤器等。--广雅 范★ 2023年1月9日 (一) 09:10 (UTC)
如希望查看日志（即abusefilter-log-private），按现行程式申请回退员权限即可。申请abusefilter-view-private才需要申请这一新权限。此外，回退员如果积极参与反破坏工作，及符合其他基本要求，即可获批。--Temp3600（留言） 2023年1月9日 (一) 14:34 (UTC)
还是那个问题吧，单纯的查看是否需要这么高的要求。--广雅 范★ 2023年1月10日 (二) 02:34 (UTC)
至少必须高于回退员，以排除目前向破坏者提供资料的回退员内鬼。--Temp3600（留言） 2023年1月11日 (三) 14:52 (UTC)
但是只是单纯查看没必要硬性要求会正则吧，以及不能编辑的话对过滤器有认识计划维护过滤器是有什么意义？--广雅 范★ 2023年1月12日 (四) 02:53 (UTC)
呃，要看的权限但看不懂正则，那怎么看懂过滤器的条件？要来干嘛？--路西法人 2023年1月12日 (四) 03:36 (UTC)
能改过滤器的管理员都没这个要求，只能看的助理却有这个要求吗？--广雅 范★ 2023年1月13日 (五) 06:45 (UTC)
管理员未必会去看和接触过滤器，但助理则一定要能理解过滤器。如果助理需要其他人帮助来解读，不还是“泄密”了。“基本认识”要求似乎不高。--YFdyh000（留言） 2023年1月13日 (五) 06:50 (UTC)
问题在于，“基本认识AF”的要求比“基本认识Regex”要高。比如第51号过滤器，第27号过滤器等，即使某名用户“基本认识”regex，如果没有相应基础，也很难理解其工作原理。--Yining Chen（留言|签名页） 2023年1月13日 (五) 11:21 (UTC)
我说的“基本认识”指过滤器功能方面，能判读多数过滤器就符合查看过滤器的基础条件（之一），不考虑复杂语法或编辑特征等检测。不太明白广雅范的“单纯查看没必要硬性要求会正则”，是适用哪些人群。--YFdyh000（留言） 2023年1月13日 (五) 12:21 (UTC)
建议对正则表达式有基本认识。如果没有认识但有必要看到源码（例如是其他维基的管理员希望抄一份中维过滤器的源码），自然符合申请原因。--Temp3600（留言） 2023年1月12日 (四) 09:56 (UTC)
这是在基本资格下列出来的欸，而且是要怎样维护过滤器呢？--广雅 范★ 2023年1月13日 (五) 06:45 (UTC)
按我所知，目前部分回退员会在站外联络管理员，向对方提出修改建议。基本资格方面，的确是希望申请者先了解regex，确认权限对自己有帮助才来申请。然而，如果是抄对码到其他维基等作业，未必需要懂得regex也可进行，故这不是强制要求。没有写成“基本认识AF”应是希望将条件写得具体些，毕竟有些人看得懂AF的界面也会说自己“基本”懂得AF。--Temp3600（留言） 2023年1月14日 (六) 14:21 (UTC)
@Temp3600、Yining Chen：我觉得倒不如直接问现任的回退员他们之中哪些人是真的用得上AF源码阅读权的（至少我在卸任之前完全用不上），然后我们对所有自称用得上AF源码阅读权的回退员逐一详细审查，确定哪些用户是可以获得AF源码阅读权的，最后直接分拆权限，把所有获确认可获授权的用户全部批量授权就可以了。我之所以这样说，不只是因为自己在卸任之前完全用不上AF源码阅读权，也是因为在使用“如果不通过就不给人吃饭”的方式后也没啥回退员前来讨论的缘故，这个情况让我怀疑是不是真的有那么多人需要AF源码阅读权。Sanmosa Συ γάρ μοι και μοίρα εί και τύχη 2023年1月12日 (四) 14:16 (UTC)
我个人预期只有几十位回退员最终需要这个权限。待过滤器用户组建立后，我支持在除权先发出通知，让回退员前来报名，批准后再对回退员组除权。--Temp3600（留言） 2023年1月14日 (六) 14:21 (UTC)
假若讨论能够通过，或许可以提前开放申请，仿照IA和查核助理的方式，列出一个“由社群共识委任的第一批AFH”名单。----Yining Chen（留言|签名页） 2023年1月14日 (六) 14:42 (UTC)
我也支持这样做。--Temp3600（留言） 2023年1月15日 (日) 03:22 (UTC)
在权限设立后初期，恐怕很少有两名以上管理员能站出来为一名申请人“担保”。即使到了后期，AFH人数逐渐增加，恐怕也很难找到愿意为自己投票支持的用户。毕竟这种“担保制”申请权限的方式应该是第一次在中文维基百科应用，谁也不知道会变成怎样。--Yining Chen（留言|签名页） 2023年1月14日 (六) 14:46 (UTC)
未见“担保”条文，也未理解为何不会有担保。--YFdyh000（留言） 2023年1月14日 (六) 17:28 (UTC)
草案要求“一名管理员具名支持，一名管理员授权”，这不是在变相要求申请该权限要一名管理员“担保”？--Yining Chen（留言|签名页） 2023年1月15日 (日) 00:14 (UTC)
Draft:过滤器助理和Wikipedia:过滤器助理草案页面中，我没看到这种要求，烦请指明原文？--YFdyh000（留言） 2023年1月15日 (日) 03:00 (UTC)
Yining Chen所指的任命条件经讨论后，最终没有纳入方针中。--Temp3600（留言） 2023年1月15日 (日) 03:20 (UTC)
敝人在此对个人构想稍作澄清。首先，请站友切勿曲解并诠释为“担保”，敢问怎么担？怎么保？要拿什么担保呢？若这样讲，所有的“提名”或“推荐”、“支持”通通都算是担保了吗？其次，最初的设想，之所以会存在可先由一名管理员提名或支持，是为了解决若将该权限直接拆分，第一位获权者如何产生的问题；换言之，往后的申请者不须非得由管理员支持或提名才可申请，因此自不存在所谓一定要“两位管理员”才能申请一说。再次，即便真需要两位管理员，也不过是执行层面的问题而已，如果社群中不存在足够的具备相关经验和技术之管理员（真没有吗？）或门槛过高，自可再议，否则动辄以不具实质证明之“恐怕如何如何”之预想或预设立场（逻辑上和“恐怕不会如何如何”是差不多的意义，众人都用“恐怕这样那样”，其他人也可以说“其实不会”，各说各话），个人认为于讨论上难有裨益。最后，若社群认为此类门槛过高，自可调整降低，个人无甚意见。真正重要的地方在于，获权者彼此间若都会协同经手维护过滤器的话，能看到内部设计的人就是那一群而已，理想上多少自当相互信任，而不是互相怀疑，这样的门槛就是为了确保能获权的用户是具备相当信任度和技术能力的，而且人数是否真的需要那么多，仍部分取决于实务需求和社群之信任，讲白了以后若有其他问题导致相互怀疑，也是持权用户间的争议了。--Kriz Ju（留言） 2023年1月15日 (日) 14:10 (UTC)
还希望您能保持冷静。首先，本人只是将个人经过思考，预想可能会发生的事情用某种方式写出来，供大家来参考，并没有以此为理由故意阻碍社群通过讨论。如果有人认为我在胡言乱语，杞人忧天，可以选择忽视。毕竟前人说“实践是检验真理的唯一标准”，如果大家都同意，完全可以现在就把这个方针草案立刻付诸实践。这样就彻底消除了别人说“恐怕”的所有机会（但这样是否是WP:POINT还有待商榷）。其次，有了第一名AFH，那选第二名时会不会变成“与第一名AFH关系好坏的评选”？如果第一名AFH直接站出反对候选人该怎么办？如果您的提案被社群初步认可，这些问题或许都要更深入的思考和讨论。( π )题外话：本人在语句中掺入大量的“恐怕”“或许”等词汇这种行为，是早期在某种特定环境下写作的产物，希望您能谅解。--Yining Chen（留言|签名页） 2023年1月15日 (日) 14:53 (UTC)
(！)意见：无妨的，您不用担忧，我相当冷静，亦无任何强求。个人只是期待，众人对他人未指明之概念，或未明言之事，请尽可能避免替他人注记或视为他人所言，甚而持续延伸，何况所谓“担保”与这里的实务实在相差甚远，试问这里的谁愿意为谁拿出什么条件真正担保过什么呢？至于个人对任何提案或构想，一向抱持可参考、可讨论之态度，若（已）无兴致或共识，随意看看即可，有兴趣参考、没兴趣拉倒，无伤大雅的。敝人并非认为是所谓杞人忧天之类，只是不喜欢太多所谓诉诸恐惧的诉求（当然您也有合理的考量），此类诉求和手法显然泛滥使用于社会中，任何构想适合或适当与否，讨论即可，当然这种说法也只是我个人偏好罢了（笑）。
至于您提到“与第一名AFH关系好坏的评选”之担忧，确实有道理，不过第二名申请者（或之后的任何用户）仍可透过两位管理员（或之后的其他获权回退员）支持，或是如敝人提及的，自认能力和信任度皆具备的用户，若认为受到不公待遇，导致无法获得任何适当支持，亦可考虑于客栈请社群品评，做为可能的救济途径；而这也是为何个人认为理想上应该直接于申请时进行公开考评之故，当然必然也会存在有人作弊或找代打之类的疑虑，然而哪项申请又可以完全杜绝所有疑虑呢？回过头来，若要仅仅提及“关系好坏”，个人倾向以两个层面观之，表面而言，与任何特定用户之关系深浅，的确影响是否具备信任度，然而这部分还是得回归管理员之专业判断和操守，若管理员不吃这套，试问关系好又如何呢（自然这点除了挑战人性，也必然永远有争议）？另一方面，信任度的基础其实有相当部分来自于社群对特定用户的“熟悉度”，而熟悉度又来自于用户平日于平台的公共领域（如社群活动、竞赛、站务、荣誉表扬，或公开讨论等领域）之实质贡献、投入和活跃与否（自然包含曝光度之类），换个角度看，或许较有机会获得社群信任的用户，在公领域常具备至少部分用户对其拥有之熟悉度，这是可以透过人为努力达成的。无论如何，正因总有争议，个人才倾向或许可以考虑设定申请考评，如此而已。其实说实话，不论是这里，抑或现实社会，所谓“靠关系”，实为常态，即便这里的管理人员选举和信任度亦无法避免此种争议（讲白了就是只要我看你不顺眼你再厉害我也不会投给你或支持你什么的），但吾人是否应该放弃其他可能性呢？
退一步而言，不论制度如何设定或规划，皆难以排除各种或所有疑虑，又或是总有各种“不公”（不论是否真实存在或真是如此），于社群中始终存在难以有效消除、缓解之隔阂或争议，那么个人认为此即可视为当下社群风貌和需求的“现实表现”了（现实世界中此类情事亦然）。--Kriz Ju（留言） 2023年1月15日 (日) 19:59 (UTC)
AFH需由管理员授权，这与目前其他权限的授权方式相同。这只代表管理员确认了社群达成的共识，难言是管理员对此的担保。“管理员具名支持”方面，考虑到目前管理员团队有不少活跃成员，几可肯定会有管理员维基人参与AFH申请的讨论，如担心AFH讨论过于寛松，可先实行一两个月后再检讨。--Temp3600（留言） 2023年1月24日 (二) 17:26 (UTC)

再议回退员的角色（是否可以与巡查员进行简并？）

最新留言：9个月前37条留言16人参与讨论

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

最近我在授权时再次想到一个以前想过的问题，那就是回退员实际上现在处于一个有些尴尬的位置。设置某种职权而不是把权限下放给所有的确认用户，其初衷自然是防止权限遭到滥用。然而，就事实上而言，标记新页面为已巡查确实是巡查员才能做的一件事，但在Twinkle工具早已普及的今天，事实上的版本回退却不是回退员的专利，大部分情况下回退员的回退功能比起Twinkle也没有很大便利性。回退员事实上高于确认用户的权限几乎只剩下查看防滥用过滤器这一项。因此，个人认为，是不是有必要稍微改革一下回退员的申请方式呢？以下提出了两种想法，想请教一下大家的意见：

  1. （较缓和）申请巡查员时，鼓励符合回退员授权条件的用户在申请成为巡查员栏目申请巡查权时一并申请获得回退权，管理员在任命权限时可一并进行考察，能很大程度上减少授权的行政工作。
  2. （较激进）把回退员的防滥用过滤器查阅权限和回退权都授予巡查员。毕竟防滥用过滤器在新条目巡查时可能也用得上。之后原则上回退员只授予少部分同时进行反破坏的巡查豁免者。--クオン·千の海を越えて·愛おしき欠片 2023年6月29日 (四) 23:05 (UTC)
我倾向剥夺回退员的防滥用过滤器查阅权限（包括现任的）后采较激进提案（甚至乎完全废除回退员，把回退权也打包送给巡查豁免者也可），原因是防滥用过滤器查阅权限有隐私安全风险。较缓和提案我认为也可行，但成效不会太大。Sanmosa Акум орь ничодатэ, кроеште-ць алтэ соарте 2023年6月29日 (四) 23:09 (UTC)
巡退合并，但申请资格使用回退员的条件如何？--冥王欧西里斯（留言） 2023年6月29日 (四) 23:58 (UTC)
可以考虑。——Sakamotosan路过围观 | 避免做作，免敬 2023年6月30日 (五) 00:14 (UTC)
个人感觉回退员比巡查员好当。回退员有能力判断明显破坏就行，而判断这点并没有很大难度。但新页面巡查员就要知道哪些条目该删、哪些条目可留，对于可留的条目，还应该清楚当前条目的最大问题是什么（然后正确地标记维护模板）。抛开故意滥用权力造成危害的事情不谈，我觉得巡查员的应该不低于回退员的门槛。两权合一用较高的门槛我认为也可以。--洛普利宁 2023年6月30日 (五) 07:28 (UTC)
提高门槛个人无异议，毕竟大部分申请人实际获得巡查权时编辑数量已大于1000。--クオン·千の海を越えて·愛おしき欠片 2023年6月30日 (五) 07:53 (UTC)
(＊)提醒一下，社群已经达成了剥夺回退员防滥用过滤器查阅权限的共识。见Wikipedia:维基百科政策简报/存档/2022-12“方针与指引重要变动”第三条。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年6月30日 (五) 02:00 (UTC)
但后续的新建用户组好像没有下文。——Sakamotosan路过围观 | 避免做作，免敬 2023年6月30日 (五) 02:20 (UTC)
而且“abusefilter-log-private”（看隐藏过滤器触发的日志）还是保留的。——Sakamotosan路过围观 | 避免做作，免敬 2023年6月30日 (五) 02:22 (UTC)
系统回退是可以绕过过滤器（可能是没配置对应action？）、黑名单的，而且更快（不像Twinkle那样是编辑盖版本）。除了隐藏过滤器的查看外，回退员的功能已经有点鸡肋了。不反对，但隐藏过滤器的查看的确需要一个安放的用户组。——Sakamotosan路过围观 | 避免做作，免敬 2023年6月30日 (五) 00:14 (UTC)
那么综合这些意见，可否单独把回退权下放给巡查员然后二权合一，技术上把回退员这个权限改为防滥用过滤器查阅员（旧回退员不直接转换为过滤器查阅员），原则上只开放给极少数有需要的用户申请（类似于大量讯息发送员）？或者索性完全废弃回退员这个职权，查阅防滥用过滤器的权限授予给模板编辑员（因为两者很大程度上都是技术方面的问题）--クオン·千の海を越えて·愛おしき欠片 2023年6月30日 (五) 07:53 (UTC)
过滤器问题并不能简单总结为“技术问题”，而应是“反破坏”。您已经担任了管理员职务很久，相信您比大家要更熟悉过滤器的相关工作流程。而模板编辑员显然与反破坏工作关系不大。--Yining Chen（留言|贡献） 2023年6月30日 (五) 14:04 (UTC)
只是一个简单的设想，具体方案还要再讨论。走前面一种方案把回退员变成原则上只授予少部分编者的过滤器查阅员个人认为也是可取的。--クオン·千の海を越えて·愛おしき欠片 2023年6月30日 (五) 17:01 (UTC)
我赞同这个方向。我的想法是将“回退员”的中文名称改为“过滤器查阅员”，并只留下防滥用过滤器查阅权（没回退权），回退权授予所有巡查员（与巡查豁免者）。Sanmosa Акум орь ничодатэ, кроеште-ць алтэ соарте 2023年7月2日 (日) 04:46 (UTC)
建议仅授予巡查员，巡查豁免者拿这个似乎有点没办法解释为什么要这个权限。--冥王欧西里斯（留言） 2023年7月2日 (日) 12:54 (UTC)
我觉得或许可以假定巡查豁免者通晓回退权的使用时机，所以我才提议可以让巡查豁免者有回退权，但这也只是我的其中一个设想，我也不是说我就一定要主张这个。Sanmosa Акум орь ничодатэ, кроеште-ць алтэ соарте 2023年7月4日 (二) 15:13 (UTC)
我感觉回退员权限中就一个suppressredirect对写条目有帮助，并且这也是我一贯的要求。像是unwatchedpages、rollback显然属于维护需要。----Cat on Mars 2023年7月5日 (三) 17:58 (UTC)
如果如Kuon所言使用TW回退相比回退功能已无多差异，那么应当做的是直接搁置或废弃回退功能，而不是简单就把这东西丢给巡查员。->>Vocal&Guitar->>留言 2023年7月2日 (日) 12:37 (UTC)
回退员的回退可以绕过滥用过滤器与黑名单，还是有差。--冥王欧西里斯（留言） 2023年7月2日 (日) 12:52 (UTC) +1
所以，立题的根本如果有问题，那也无从讨论废除回退员这一可能。->>Vocal&Guitar->>留言 2023年7月3日 (一) 03:37 (UTC)
某日我在SWV上回退中文版的破坏，结果我没有本地回退被过滤器阻挡操作失败……所以差别还是相当大的……--And ALLAH said, “Together we unite!” And there’s power. 2023年7月7日 (五) 02:09 (UTC)
回退权限始终包含“复原”以外的特性，不可整个废除；并入巡查员也并不合理（我过往曾提过类似巡退合并的提案，但现在想到相反的论点）：各人有不同专长，回退员是反破坏，巡查员是检查内容品质，完全是两个不同范畴的权限。合并两个权限总会出现有人只用其中一半的问题，不如维持分拆更好。--路西法人 2023年7月3日 (一) 05:20 (UTC)
问题在于这个“有人”具体有多少，我当回退员时根本未曾用过隐藏防滥用过滤器查阅权，这理论上也是“有人只用其中一半”的问题，因此我认为以“有人只用其中一半”来反对合并不能服众。我认为有必要知道同时是巡查员与回退员的用户的具体人数。Sanmosa Акум орь ничодатэ, кроеште-ць алтэ соарте 2023年7月3日 (一) 23:41 (UTC)
不全然认同“未曾用过隐藏防滥用过滤器查阅权”算是用一半。“回退员”顾名思义主要权限是系统回退，防滥用过滤器查阅权只是因为同属反破坏权限才勉强附于回退员组别权限中吧，只能称得上“附边”的权限。巡查权跟回退权就是两个非常常用且主要的权限，回退并入巡查，想申请权限做反破坏的用户就真的只用一般了。经查，现时192名回退员、172名巡查员，其中有130名用户同时持有二权。合并权限后，假设所有用户过渡至新权限，会有234名巡退员，即每九个巡退员就有四个只用一半。--路西法人 2023年7月4日 (二) 13:38 (UTC)
就算是现在的巡查员的各种权限，理论上也是“有人只用其中一半”的。巡查员表面上的权限是巡查权，但实际上还有巡查豁免权，此外还有不留重新导向移动权，而（包括我在内）好一部分的巡查员巡查页面的频率很低，可能每三个里只有一个是真的会经常巡查页面，而剩下两个就是为了那个附设的不留重新导向移动权，但为此特地把不留重新导向移动权分成一个独立的权限也不合理（当然，我个人更倾向把这个权限下放），所以我仍然认为以“有人只用其中一半”来反对合并不能服众。Sanmosa Акум орь ничодатэ, кроеште-ць алтэ соарте 2023年7月4日 (二) 15:09 (UTC)
我倒是觉得巡查员是否要附带巡查豁免权存疑，现在巡查员的条件似乎比巡查豁免员低，而且感觉部分巡查员（或者巡查+回退）不一定能保证自己所写是否无需巡查。--在下荷花，请多指教（欢迎签到） 2023年7月6日 (四) 11:23 (UTC)
这是老问题，好像是技术原因。也因为理念上可能认为能自我控制才有能力巡查别人，但复审其实很有价值。不过复审未必要关联到新页面巡查。--YFdyh000（留言） 2023年7月6日 (四) 11:29 (UTC)
有技术问题？导游就是巡退一体然后豁免分开。--在下荷花，请多指教（欢迎签到） 2023年7月6日 (四) 16:15 (UTC)
不过导游的巡查员只有rollback、patrol跟suppressredirect三种权限就是了，如果真的合并，改成这样也不是不行。--冥王欧西里斯（留言） 2023年7月6日 (四) 23:41 (UTC)
葡萄牙语版上的回退者同时持有封锁权限（详见此处）。不过实际使用上似乎也有所限制，好像原则上只允许不超过24小时短期封锁……我不了解葡萄牙语，其他细节可能没有察觉到。--And ALLAH said, “Together we unite!” And there’s power. 2023年7月7日 (五) 02:01 (UTC)
但这个同时要修封锁方针，以中文维基百科目前的封锁方针来说大概不能直接这样给权限。--冥王欧西里斯（留言） 2023年7月7日 (五) 02:28 (UTC)
这个感觉在中维不太可能实现就是了。--在下荷花，请多指教（欢迎签到） 2023年7月7日 (五) 11:19 (UTC)
我认为就现阶段而言，鼓励巡查员同时申请回退员是可行的。—— Eric Liu 創造は生命（留言・留名・学生会） 2023年7月10日 (一) 09:37 (UTC)
  总结：结合以上的讨论，那么是否可以在这里提出两个提案呢？一是设立过滤器查阅员并剥夺回退员过滤器查阅权，二是鼓励巡查员同时申请回退权。--クオン·千の海を越えて·愛おしき欠片 2023年7月11日 (二) 21:37 (UTC)
前者已在下方讨论。后者没意见，但考虑到隐私问题，我不建议在剥夺回退员私有过滤器查阅权前鼓励巡查员同时申请回退权。Sanmosa In vain 2023年7月11日 (二) 22:34 (UTC)

再提重组用户权限组

最新留言：9个月前29条留言10人参与讨论

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

以下列出中文维百常年不通过，但非常需要的更改权限提议：

  • 降低自动确认用户的门槛
  • 巡查员与回退员合并为巡退员
  • 设立高级巡退员以查看私密过滤器
  • 给界面管理员授予编辑被保护页面的权限
  • 与基金会协商重新引入用户查核员--Firedoge2023（留言） 2023年7月13日 (四) 14:24 (UTC)
请勿在讨论版直接引用个人沙盒，这会使您此后的更改直接反馈到该页面，使讨论内容无法确定。此外关于用户组权限的调整，还请您不要自顾自地不给出任何理由直接提出自己的一系列想法，这无助于发现问题和解决问题，只是在创造问题。——暁月凛奈 (留言) 2023年7月13日 (四) 14:41 (UTC)
回复@暁月凛奈：这些想法也不是我提的呀，之前都有讨论--Firedoge2023（留言） 2023年7月13日 (四) 14:50 (UTC)
以上提议我觉得会因安全原因而不会通过，例如反对降低自动确认用户的门槛的原因是有长期破坏者喜欢通过刷编辑数来破坏被半保护的页面。--Lanwi1Talk 2023年7月13日 (四) 15:56 (UTC)
可以限制为条目命名空间编辑--Firedoge2023（留言） 2023年7月14日 (五) 02:02 (UTC)
可能和mw技术实现有关，至少在P站申请得到mw开发人员支持改进出这个功能才能讨论。不过如果看自动确认和延伸确认两种类似机制下的授权方式有明显差异，感觉这个授权部分是屎山，没人想动。 ——Sakamotosan路过围观 | 避免做作，免敬 2023年7月14日 (五) 03:05 (UTC)
“再议回退员的角色（是否可以与巡查员进行简并？）”、“提议重组现有的用户权限组”不是已经在讨论有关部分问题（包括合并巡查和回退，将回退看私密AF的权限正式转给另一个用户组）。至于其他（如“降低自动确认用户的门槛”、“界面管理员编辑被保护页面”），只是举出常年理由并不足够说服吧，至少说明现在为什么要这么做。——Sakamotosan路过围观 | 避免做作，免敬 2023年7月14日 (五) 01:11 (UTC)
“界面管理员”本来就是防止管理员被盗后修改界面空间（例如Mediawiki空间的js脚本、css等）而将相应编辑权限拆出来提高安全性，“编辑被保护页面”如果指全保护的话应该是管理员就可以吧？——Sakamotosan路过围观 | 避免做作，免敬 2023年7月14日 (五) 01:15 (UTC)
PS，虽然现在来看，除了AnYiLin外，剩下的也是管理员（乐），有点脱裤子放屁的感觉，而且申请难度也和管理员接近。如果说好处的话， 就是收窄修改界面空间用户的范围，一些专注页面管理、用户管理的管理员通常不需要这个编辑能力。——Sakamotosan路过围观 | 避免做作，免敬 2023年7月14日 (五) 01:20 (UTC)
那就剥夺几个界面管理员的管理员身份[开玩笑的]--Firedoge2023（留言） 2023年7月14日 (五) 02:07 (UTC)
这不是开玩笑，毕竟这几位的确是偏向技术维护的管理员。虽然从所谓安全性而已，是提出了拆分组别的要求，而基于其角色，他们看上去又好像没有丢失了这些权力。——Sakamotosan路过围观 | 避免做作，免敬 2023年7月14日 (五) 03:24 (UTC)
看了一下，应该给界管授予以下权限
editprotected
editcontentmodel
delete（仅限Mediawiki命名空间或CSSJS页面）
undelete（仅限Mediawiki命名空间或CSSJS页面）
suppressredirect（仅限Mediawiki命名空间或CSSJS页面）--Firedoge2023（留言） 2023年7月14日 (五) 02:24 (UTC)
反对，界面管理员不应该有更改界面以外的任何权限，以上五个权限全部没有技术上的命名空间限制，全部不应授予界面管理员。--路西法人 2023年7月14日 (五) 02:39 (UTC)
「界面管理员的可信程度不应亚于管理员，甚至应该更高。」可信程度更高，权限也应更高。--Firedoge2023（留言） 2023年7月14日 (五) 02:51 (UTC)
所以我曾经认为这句话说得不好，产生界面管理员组别的意义是为了隔离界面空间编辑功能而产生（或者说是拆分出来），实际上它的权限少于管理员，没有什么“可信程度不应亚于管理员，甚至应该更高”的意义。除了可以加些js脚本（可能引入隐私泄漏的破坏脚本），或者恶作剧性质的css外，远不如管理员能删除页面、保护页面、或者封锁用户更麻烦，前者直接用API也能绕开页面修复。——Sakamotosan路过围观 | 避免做作，免敬 2023年7月14日 (五) 03:10 (UTC)
我把这句话删了--Firedoge2023（留言） 2023年7月14日 (五) 03:24 (UTC)
从技术上，有类似控制特定用户组对特定页面空间的动作控制插件：mw:Extension:Lockdown，不过可能需要确定基金会会不会允许使用这个插件。“editprotected”（编辑全保护页面）感觉没必要给，因为这本来是管理员主要权限之一、“editcontentmodel”可能可以考虑。至于其他要看插件功能来确定。——Sakamotosan路过围观 | 避免做作，免敬 2023年7月14日 (五) 03:20 (UTC)
须证明日常工作中常用、必需，否则放在管理员权限组、双人完成就好（活跃者少是另一问题）。可信程度高不代表要授予非必要的权限。--YFdyh000（留言） 2023年7月18日 (二) 13:20 (UTC)
请深思熟虑以后再提案，不要一股脑提出来。这些提案“常年不通过”是有原因的。从使用者查核员问题就可以看出，显然提案人没有对本站权限体系发展事先做过研究。—— Eric Liu 創造は生命（留言・留名・学生会） 2023年7月14日 (五) 13:13 (UTC)
我研究过--Firedoge2023（留言） 2023年7月14日 (五) 13:39 (UTC)
@Ericliu1912：虽然我个人也同样不认可这次Firedoge2023的做法，但你用“这些提案‘常年不通过’是有原因的”来批判他我也不认可。这样说吧，我一开始在2018年重提设立编辑禁制方针（现称“禁制方针”）的时候也没有怎么“深思熟虑”过，而且编辑禁制方针当时也是常年提案，但那时最终我的提案通过了。Sanmosa In vain 2023年7月14日 (五) 13:52 (UTC)
我自已也不认可我的观点。--Firedoge2023（留言） 2023年7月14日 (五) 14:03 (UTC)
提案人应对提案脉络及意义有充分掌握，这是基本道理。操之过急而缺乏准备的提案不值得社群多花精力去“帮”提案人额外考虑。—— Eric Liu 創造は生命（留言・留名・学生会） 2023年7月14日 (五) 14:12 (UTC)
我的意思是说你先不要一来就假设对方完全没有“对提案脉络及意义有充分掌握”，这某程度上可以算是冒犯。Sanmosa In vain 2023年7月14日 (五) 14:28 (UTC)
我只是就事论事。提案人如果明确知道为什么要提案、怎么解决过往讨论未能解决的问题并合理说服社群，就不会出现“自顾自地不给出任何理由”等情况以及上方某些不明就里的意见；如果认真、严肃地对待讨论，就更不应该出现“那就剥夺几个界面管理员的管理员身份[开玩笑的]”这种发言。—— Eric Liu 創造は生命（留言・留名・学生会） 2023年7月14日 (五) 15:40 (UTC)
😅--Firedoge2023（留言） 2023年7月16日 (日) 02:52 (UTC)
取自“https://zh.wikipedia.org/w/index.php?title=Wikipedia_talk:回退功能/存檔2&oldid=80314420”
返回到项目页面“回退功能/存檔2”。