维基百科讨论:封禁方针

编辑请求 2024-01-28

请求已拒绝

解除临时性质的封禁一章中“临时性质的封禁应当在确认情况已解决的时候解除，此包括：

......

获得审核批准或已修复故障的机器人；及”

其中“获得审核批准或已修复故障的机器人；及”一行语意不明，应该删去“；及”。--阿米娅激推（留言） 2024年1月28日 (日) 09:16 (UTC)

未完成：

不再用作开放代理伺服器的IP位址及区段；↲ 获得审核批准或已修复故障的机器人；及↲ 已撤回的法律威胁。

--Cookai饼块🍪_{（💬留言）} 2024年1月28日 (日) 10:42 (UTC)

依然没见到改动，我看到的仍然是“获得审核批准或已修复故障的机器人；及”而非上者。--阿米娅激推（留言） 2024年1月28日 (日) 11:20 (UTC)

请看下去。--Cookai饼块🍪_{（💬留言）} 2024年1月28日 (日) 11:22 (UTC)

那么改动应该是“不再用作开放代理服务器的IP地址及区段；↲ 获得审核批准或已修复故障的机器人；↲ 及已撤回的法律威胁。”除此之外在“不应解除封禁的情况”一节中也是这个问题。已查看源代码。--阿米娅激推（留言） 2024年1月28日 (日) 11:24 (UTC)

您若认为不适，可至WP:互助客栈发起讨论。这并非个例，此用法在这页就用了5次。个人认为把“及”放在后面的原因可简单解释为“那不重要”。

• A项；
• B项；
• C项；及
• D项；

和

• A项；
• B项；
• C项；
• 及D项；

显然是前者能较明确展示各项。--Cookai饼块🍪_{（💬留言）} 2024年1月28日 (日) 11:38 (UTC)

进一步增修封禁方针以及建立封禁申诉的本地共识

通过：

公示期间无异议。Sanmosa _{Szégyen a futás, de hasznos} 2024年4月20日 (六) 02:06 (UTC)

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

---

User:LuciferianThomas（路西法人，或称路君）于2023年3月提出了封禁方针的重大修订，尽管方针大部分内容引自英文版方针。

在2024年2月我因不当行为被不限期封禁之后（不到两天被解封），有用户在我讨论页评论的时候仍把“不限期封禁”称为“永久封锁”，这明显违背了“不限期封禁”方针所制定的目标“不代表该封禁永恒不可变”。而我被封的时候也看到了路君的回复，也是自此时开始即对封禁方针进行了重新翻阅，又看了英维里的方针，发现有部分方针内容是需要改进的，尤其是“不限期封禁”方针需要进一步修订，毕竟“永久封锁”的说法在英维里早就被“否定”了。

结合当前情况考虑，我提议对封禁方针的部分内容作出增修，重点修订“不限期封禁”方针，同时新增“请求封禁”方针以及修订“解除封禁”方针（小修改）。另外我提议建立封禁申诉的本地共识。以上工作的目的是，填补过去中维在封禁方针指引上的漏洞，让相关方针指引如同英维一样健全，将封禁方针指引更加程序化、系统化。提议共四条（章节），请大家分章节讨论，谢谢。

还有必要称呼“永久封锁”吗？

现行条文 不限期封锁（或称永久封锁）是指无失效时限的封禁，通常用于防止严重扰乱维基百科正常运作的行为或严重违反维基百科方针指引的行为。不限期封锁或适合用以阻止持续的不当行为，但仍需注意同样不是作惩罚之用。不限期封锁并不代表永恒不可变，而仅代表未有订立封锁时长，封锁不会自动过期解除。被不限期封锁的用户在合适的情况下可获解除封锁，并在让其被观察的情况下继续编辑，以确保该用户未来不再违反维基百科的不同规范。

提议条文 不限期封锁是指无失效时限的封禁，通常用于防止严重扰乱维基百科正常运作的行为或严重违反维基百科方针指引的行为。不限期封锁或适合用以阻止持续的不当行为，但仍需注意同样不是作惩罚之用。 另需注意“不限期”不应理解为“永久”，即不代表该封禁永恒不可变，而仅代表未有订立封锁时长，封锁不会自动过期解除。被不限期封锁的用户在合适的情况下可获解除封锁，并在让其被观察的情况下继续编辑，以确保该用户未来不再违反维基百科的不同规范。但在特别严重的情况下，如无管理员愿意解除封禁，该用户实际上已被社群禁止编辑。 参考资料

在路君修订“不限期封禁”方针之前，封禁方针关于“永久封禁”的方针内容如下：

永久封禁是一个永不失效的封禁。永久封禁通常用于防止严重干扰或威胁维基百科正常运作的行为，或严重侵犯维基百科政策的行为。这能避免该用户的行为产生更多的问题。 对于社群来说，永久封禁一个用户可被理解为完全禁止该用户进行编辑（如无管理员解封的话）。但在一般情况下，我们建议给该用户一个最后机会——在某段时间暂时解封该用户，并在被观察的情况下继续编辑，以确保该用户未来不再违反维基百科的政策。

虽然修订后已将其更名为“不限期封禁”，但条文中仍提到“或称永久封锁”。2024年2月我被无限期封的时候，也一直以为就是永久封锁，永远不给解封了。按照方针所述“不限期封锁并不代表永恒不可变，而仅代表未有订立封锁时长，封锁不会自动过期解除”，另外用户确有反省不再违规的话是可以解封的。因此，严格来说“永久封锁”这个说法不妥当，这会对用户造成误解，而且这是前后矛盾，模棱两可。而且“永久”和“不限期”本身意思和真实语景应用中有很大区别（大家可以上网搜索）。在英文版方针中有一句话直接“否定”其为“永久封禁”：

Indefinite does not mean "infinite" or "permanent"

意思就是，“不限期”不应理解为“无限”或“永久”。但基于中文语境情况，我提议修订的条文改为“不应理解为‘永久’或‘终身’”。

同样，我在英文版的封禁申诉指引也找到了这一句话：

"Indefinite" does not necessarily mean "forever" or "infinite". It means "however long is needed for the user to address the issue". This can be minutes, hours – or indeed the user may never do so.

意思是，“不限期”不一定是“永久”或“无限”。其意思是“用户需要多长时间来解决问题”。这可能是几分钟、几小时——或者实际上用户可能永远不会这样做。

为了避免对其他用户造成进一步的误解，我提出修订建议，参照英维的方针作进一步修订，具体提议内容见上。--Shwangtianyuan 不忘初心 牢记使命 2024年4月2日 (二) 16:08 (UTC)

支持修订。不赞成“终身”，非“无限”就足够了。--YFdyh000（留言） 2024年4月2日 (二) 16:34 (UTC)

不反对如此修订。Sanmosa _{Szégyen a futás, de hasznos} 2024年4月3日 (三) 07:48 (UTC)

我在文内保留括号（或称永久封锁）是基于让后来的人能再查看前人所说“永久封锁”是什么意思，如果连括号都容易造成误会，那么也请改成注释，写例如无失效时限的封锁曾称为“永久封锁”；因与实际意义不相符而在2023年3月[[Special:Diff/XXXXXX|修订方针]]后改为现称。过往称“永久封锁”的意思应视同“不限期封锁”之意，同样非“永久不可变”；详见§ 不限期封锁一节的第二段。这样。

另外我记得当初我决定写“不限期”而不是“无限期”是因为后者中的“无限”容易误导他人以为是“infinite”的意思。我不清楚YF的意思是怎样，但提案人所列出“不应理解为终身”我认为是相当合理的。--路西法人 2024年4月3日 (三) 09:36 (UTC)

个人不反对注释化处理，@Shwangtianyuan、YFdyh000。Sanmosa _{Szégyen a futás, de hasznos} 2024年4月3日 (三) 10:25 (UTC)

可以。只是不赞成引入“终身”用词，封禁是针对账号而非诉诸人身的，虽然禁止绕过封禁。--YFdyh000（留言） 2024年4月3日 (三) 11:10 (UTC)

文内正是说“不应理解为终身”，本来就是说“不是”，不知道你是在反对什么……？--路西法人 2024年4月3日 (三) 15:03 (UTC)

有时封禁的是账号（对于用户名违规），身更接近实体，不想将此概念混入。如“不应理解为终身”可能理解为有期限的封禁身。--YFdyh000（留言） 2024年4月3日 (三) 16:06 (UTC)

“不应理解”ABC不等于“可以理解为”DEF。“不应理解为终身”本来就只有“不应理解为终身”的意思，任何其他理解都是超译，不需考虑。--路西法人 2024年4月4日 (四) 12:40 (UTC)

标注注释的话应该没什么问题，虽然它并不一定是永久性的。--Shwangtianyuan 不忘初心 牢记使命 2024年4月3日 (三) 14:58 (UTC)

根据上述意见于2024年4月4日 (四) 05:43 (UTC)代为调整提案。Sanmosa _{Szégyen a futás, de hasznos} 2024年4月4日 (四) 05:43 (UTC)

基本上认可修订后的提案。--Shwangtianyuan 不忘初心 牢记使命 2024年4月4日 (四) 14:04 (UTC)

新增“请求封禁”方针

参照其他项目及其他语言版本的封禁方针，提议新增“请求封禁”方针，内容在“不适用封锁的情况”之后，“封禁指导”之前，以此将封禁方针更为程序化。具体如下：

用户可以在当前的破坏页面或者在管理员布告板/其他不当行为页面请求封禁，请求的同时亦应提供充分的证据，但管理员有权拒绝执行被请求的封禁，并可以进行独立的调查。在实施封禁之前，管理员应当充分熟悉具体情况。参见解释封锁原因。

待方针通过后，建立快捷方式WP:BLOCKREQUESTS和WP:BLOCKREQ。--Shwangtianyuan 不忘初心 牢记使命 2024年4月2日 (二) 16:08 (UTC)

原则上支持。提供充分的依据是否更好，证据不能覆盖方针，理据不能覆盖证据。“被请求的封禁”称“封禁请求”就好。未理解“并可以进行独立的调查”的强调原因，何为独立的调查，是独自调查还是能发起单独调查、询问或征询，有无具体要求。--YFdyh000（留言） 2024年4月2日 (二) 16:34 (UTC)

同YFdyh000。除此以外，我觉得AN3是否属于潜在可请求封锁的场所也值得探讨。Sanmosa _{Szégyen a futás, de hasznos} 2024年4月3日 (三) 07:53 (UTC)

赞同，但应避免直接列出对应页面，始终理论上什么地方都可以用来请求封锁：例如社群在客栈达成封锁某名用户的共识，也是一个非常边缘但完全合理合规的请求封锁模式。提案人可考虑将拟新增条文中列出页面的位置改成“用户可于适当的布告板上提出封锁请求”。

YF所指也是应当参考，可以考虑改成“须附上清晰理据，例如用户违反了什么方针指引、如何构成不当行为等。”（后面不需要“但”管理员了，这个转折似乎没太大必要。）

我建议可以改成这样：

用户可于适当的布告板提报不当行为，并必须附上清晰理据，例如用户违反了什么方针指引、如何构成不当行为等。管理员在接获提报时应自行复检提报所列理据是否有效，并在符合本（封锁）方针规定下执行封锁。若管理员认为提报有问题（如不符合实际情况、不符合方针赋予管理员封锁的情况），则有权拒绝提报。--路西法人 2024年4月3日 (三) 09:46 (UTC)

基本接受阁下的方案，没什么问题。反正，报告请求就是需要提供有效、足以证明的证据，证据不足或者不符合的都应予拒绝。--Shwangtianyuan 不忘初心 牢记使命 2024年4月3日 (三) 15:00 (UTC)

修订“解除封禁”方针

模板第二次机会是重新赢得社群信任的一种手段，主要针对过往有破坏、扰乱性编辑的用户。但中维因为方针没有提及，导致此模板一次都没用上。我在这里也是提议引入英维的方针，将“第二次机会”成为本地方针。具体内容如下：

如果用户声称希望做出建设性贡献，但管理员对其承诺存在疑问，则可以使用{{第二次机会}}模板作为解除封禁的条件，来展示用户将如何为百科全书做出贡献，以此相信用户提出的修改能够帮助维基百科。

拟引入的方针待通过后，提议加入于“封禁申诉”一节，在“任何用户均可参与……”之前。--Shwangtianyuan 不忘初心 牢记使命 2024年4月2日 (二) 16:08 (UTC)

这个想法很好。虽然我对被封禁者重新写的条目的质量很不乐观，但至少让他们审视一下自己写的条目也是好的。--ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年4月3日 (三) 03:52 (UTC)

不反对如此修订，我不清楚PoisonHK算不算一个例子。另外，建议将“声称”改为“声明”，中文里“声称”通常伴随著负面的用法，在中性的行文里用可能不太合适。Sanmosa _{Szégyen a futás, de hasznos} 2024年4月3日 (三) 07:49 (UTC)

这不错啊。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年4月4日 (四) 15:45 (UTC)

(＋)支持。--冥王欧西里斯（留言） 2024年4月11日 (四) 09:58 (UTC)

公示

依照WP:共识#提案讨论及公示时间，互助客栈中的提案仅在7日内无新留言时或已讨论达30日后，方可在已取得共识的前提下公示，其中“新留言”不包含不对提案进行实则性点评的意见。有鉴于此讨论串中最近一个对提案进行实则性点评的意见在2024年4月4日 (四) 14:04 (UTC)发表，此处已满足公示的条件，故现公示上述3个提案7日。Sanmosa _{Szégyen a futás, de hasznos} 2024年4月11日 (四) 15:58 (UTC)

---

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

管理操作复核的议题

原标题为：提议设立请求封禁机制以及扩大AARV的使用

提议设立请求封禁机制以及扩大AARV的使用

我建议社群考虑设置类似“请求封禁”的机制，即对于非纯破坏行为，有共识后再执行封禁，而非管理员独自判断引起争议。

对于解封请求，我建议扩大WP:AARV的使用，申请人可以选择请求任何一名用户协助提出AARV，由社群进行判断封禁是否适当。

提请各位讨论，有关方针条文也请踊跃发表。--桐生ここ★[讨论] 2024年6月14日 (五) 07:53 (UTC)

Ping有对提案发表意见的人@日期20220626、ChiuHsiao1221、Shwangtianyuan、HYHJKJYUJYTTY。--桐生ここ★[讨论] 2024年6月14日 (五) 07:55 (UTC)

本人是(＋)支持，社群考虑设定类似“请求封锁”的机制，确实能解决很多不必要争议，非纯破坏行为，至于解封请求，建议扩大WP:AARV的使用，我也支持，--HYHJKJYUJYTTY（留言） 2024年6月14日 (五) 08:10 (UTC)

本人亦是倾向(＋)支持。针对某位编辑账号的封禁无异于是在维基百科范围类对某人“执行死刑”。既然现实里文明国家的死刑都有复核和救济制度，那我认为维基社群也应该考虑。除了机器人账号或纯粹破坏行为外，针对其他行为的封锁账号行为要给于“拟被封所账号者”一个申诉和申请复核的渠道。--Chiu Hsiao (✉️Message) 2024年6月14日 (五) 08:20 (UTC)

原则上同意扩大AARV，但实际执行上对社群整体正确解读及执行方针有极大疑虑。在社群本身已经存在失能、有不少用户连最基本的方针指引都愿意无视的情况下，我不认为当前的社群整体而言有足够能力作出完全合乎方针指引及背后原则理解，以此判读管理人员的管理行为是否恰当。光是社群中仍对于“不限期”错误理解为“永久”或“比其他更重”的观点（WP:不限期不等于永久才是正确理解）已经反映社群缺乏判读封锁是否恰当的能力。在多个解封案例中，多名用户未有真的分析封锁理据、没有考量方针指引要求、未有从执行人的视角去看事件，甚至只是因为跟管理人员的个人恩怨就直接提出反对，反映社群缺乏作此判断的能力。原则上AARV是一件好事，但实际需要达到的效果目标及需要的技巧跟担任仲裁员无异；而仲裁委员会都尚会是社群经选举选上去的一群人，AARV的参与社群却是未经社群检视资质的用户技能参与，粗暴点说就是平民版仲裁，跟仲裁委员会的公信力还要差个天差地别。

请求封锁有极度严重社群程序官僚化及暴民政治的风险，如同上方所述，社群整体而言本身缺乏正确判读什么情况适合或不适合封锁的能力，也往往主张采取不足以阻截扰乱编辑的措施。请求封锁涉及管理员权限，又是由谁来判读共识又是一大问题：社群本身缺乏判读共识的能力（永远只会点人头而不看论据强弱），管理员自己判读共识又产生一个会起疑的点，简单来说就是没解决任何问题，还产生了更多的问题的提案。--路西法人 2024年6月14日 (五) 09:57 (UTC)

反对引入仲裁制度的人，却提案引入一个目标近似仲裁的机制，但这机制极度取决于社群能力（惟社群已经展现其失能），却也完全没有仲裁要求的严谨。在社群缺乏有关判断能力、扭曲理解方针、无视方针原则的行为获得控制前，AARV就只是一个跟当前RFDA没分别，只会制造更多争议的体制。--路西法人 2024年6月14日 (五) 10:27 (UTC)

那这么说吧，蓝桌的调查报告很好，如果封禁非纯破坏用户前，要求管理员写一份调查报告呢？--桐生ここ★[讨论] 2024年6月14日 (五) 11:11 (UTC)

包括所有差异链接，逐条说明为什么违反方针，决定量刑多久，决定量刑的理由。如果当事人怎样做可以获得原谅和解封。或者遭不限期封禁者，多久之后提出申诉可以考虑解封。--桐生ここ★[讨论] 2024年6月14日 (五) 11:17 (UTC)

管理员在封锁理据中已经提供理由和对应的diff即可视作已提供封锁报告。如果处理每一个非破坏用户都需要这样写的话，用意是好但极度官僚，手续过多可能导致愿意处理此类封锁的管理员越来越少，反而变成放任了这些扰乱者继续搞事。不过，我是同意可以要求管理员在执行不限期封锁时在封锁讯息下写出不限期封锁的考量，并在有可预见的改善可能（即不属VOA、SPA或再次封锁的用户）情况下提供WP:不限期不等于永久的说明，并写说需要对方了解什么方针指引即可获得解封（第二次机会）。

至于详细的封锁报告，则应是在AARV或仲裁的情形下提供。惟发起AARV的门槛过低，除了担忧AARV参与者素质外，还担忧会被滥用以针对特定管理员，制造毫不必要的工作量。--路西法人 2024年6月15日 (六) 00:24 (UTC)

你维管理员封禁此类人士已经圣母到极致，若是再加调查报告这种减速带我看你维是不想请捣乱的人离开了？--0xDeadbeef (留言) 2024年7月6日 (六) 16:16 (UTC)

Wikipedia:管理员布告板/编辑争议和Wikipedia:管理员布告板/其他不当行为已经复杂到我不愿意碰了，再弄这个的话更不会没事去看了....--百無一用是書生 (☎) 2024年6月17日 (一) 02:14 (UTC)

社群针对此议题是不是讨论过不少次了？为什么我感觉几个月以前才有一次。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年6月14日 (五) 12:50 (UTC)

基本上这种制度是聊胜于无，比起现在的情况肯定是利大于弊。但也要指出，管理员执行封锁操作时，理论上已经要确定当事人违反本站政策，“独自判断引起争议”可以是对管理员裁量权的事后合理质疑，但不是限制管理员行使封锁权限的前提。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年6月14日 (五) 12:52 (UTC)

支持，帮助明确共识。但裁量权目前还是得有。--YFdyh000（留言） 2024年6月14日 (五) 14:24 (UTC)

理解提案的用意，乐见其成。但在实践上可能会如路西法人君所说产生更多问题，或许会造成另一个管理员布告板。明白提案及用户对管理权运用的忧虑。－千村狐兔（留言） 2024年6月14日 (五) 15:53 (UTC)

注：此留言已被原作者（User:月都）移除。

我觉得也应该探讨一下为什么管理员们不愿意碰WP:ANMWP:AN3，如果ANM、AN3都不愿意碰，再开一个AARV事实上只会让管理员的事情变更多，我想这某种程度上并没有解决问题，反而多了另一个问题，再提醒一下管理员也是"志愿者"。

社群愿意的话亦可探讨为什么管理员越来越不活跃，还有什么方法吸引管理员回来帮忙扫地，或是另外寻求一条出路解决这个问题。--~~Sid~~ 2024年6月17日 (一) 13:04 (UTC)

额外补充我并不是要反对提案，只是不希望社群设立之后却没有达到预想的效果。--~~Sid~~ 2024年6月17日 (一) 13:05 (UTC)

以“有共识后再执行封锁”来处理“管理员独自判断”的潜在弊端可能不符比例原则，我更倾向于引入类似助言的机制，要求管理员在执行不限期封锁前应先取得至少一位未涉事的第三方用户的同意，以确保所有不限期封锁的执行都不违反比例原则。Sanmosa _{Snipe–Clam Grapple} 2024年6月18日 (二) 13:35 (UTC)

我认为这个方法可行。--~~Sid~~ 2024年6月18日 (二) 14:59 (UTC)

少打字，修正留言。~~Sid~~ 2024年6月18日 (二) 15:00 (UTC)

不合适。破坏者还要助言？说这是明显例外吧，但又有什么应该是例外呢？到头来还是要争吵。如此官僚主义弊病过重，我想事后复查比事前在那边极其复杂地商榷认定界线要容易得多。另外我还是要指出，理论上若管理员是依据社群讨论通过的方针与指引执行封锁，就是在确保社群共识得到实践；故除理据不清之外，通常不能说管理员“未依共识”执行封锁，至多是对方针与指引认知有争议。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年6月18日 (二) 17:46 (UTC)

啊，我忘了提及“非纯破坏行为”的前设。Sanmosa _蚌埠 2024年6月19日 (三) 05:47 (UTC)

支持@Sanmosa的助言机制，这个方法应该可行。--桐生ここ★[讨论] 2024年6月20日 (四) 19:20 (UTC)

有点怀疑“未涉事的第三方用户”的评判可能出现争议，并可能使部分用户有意避嫌、延后表态（私下抱团沟通）。--YFdyh000（留言） 2024年6月21日 (五) 11:57 (UTC)

关于“私下抱团沟通”，根据WP:共识，仅建议不应私下讨论维基百科相关的事项，个人建议需更改这段的用词至严禁私下讨论维基百科相关的事项，并配合利益申报 （如该名编辑者曾在外站讨论，则应当“涉事用户”处理并应主动向社群申报），否则的话也没有意思。关于最近私下讨论的例子，就是路西法人的共识议案，完全将跳过了共识形成过程便产生共识，此不合程序公义。如果之后AARV容许私下抱团沟通，那只好反对。

.

“维基外的讨论。我们不鼓励编者在其他网站、论坛、聊天工具、电子邮件或其他本专案外的地方讨论。这些讨论在“维基内”决定共识时是不予考虑的，并在它们被揭发后会引发猜疑和不信任情绪。尽管我们需要在维基外讨论少数问题以顾及隐私，但绝大多数维基百科相关的事项都应在维基百科上讨论，这样它们将对所有参与者可见。”--唔好阻住我爱国（留言） 2024年6月21日 (五) 12:40 (UTC)

我觉得与其在客栈提案（现行写法），不如改置管理员布告板的子布告板（可命名为“管理操作复核”），集中处理涉及高阶权限的使用行为。既有之“其他不当行为”子布告板，则继续留作解决普通使用者争议之处。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年6月24日 (一) 01:09 (UTC)

(＋)支持。--桐生ここ★[讨论] 2024年6月29日 (六) 21:17 (UTC)

诚如书生君所言，本站处理相关问题之场所一向不缺——Wikipedia:管理员布告板/编辑争议和Wikipedia:管理员布告板/其他不当行为。所以这个与前列两者分别何在？固然多一人一起讨论如何行使权限，未尝不可。但本站有足够人手么？在下甚是疑惑。本提案立意良善，但欠缺具体系统设计。坦白说，就是怕管理员滥权，但又没有给管理员足够配套。然后，调查事情不一定要管理员权限，所以又有多少人有能力且愿意担起此责？--J.Wong 2024年7月1日 (一) 13:46 (UTC)

我只是特别羡慕ja有这个；对于解封，en有这个，看起来都是和气的达成了共识，不知道为什么在zh，最后都是客栈吵得不可开交，甚至上RFDA解决。--桐生ここ★[讨论] 2024年7月1日 (一) 14:12 (UTC)

立意就是希望大家多用AARV，最后不用走到RFDA这一步。--桐生ここ★[讨论] 2024年7月1日 (一) 14:28 (UTC)

所以这次有提出过使用吗？有空间容许第三方审核及说话的馀地吗？--J.Wong 2024年7月2日 (二) 05:46 (UTC)

其实这次事件当中是见到Bluedeck有意愿作出独立调查，但本站社群之中，竟然未见有人愿意伸出援手。

然后就去羡慕这个，羡慕那个……

纵观整个讨论，在下见到大家更关心程序，数够票就下一步，甚少理会双方所言是否在理，能否经得起第三方审核。如果这点不变，开再多讨论空间，阁下都只能继续羡慕。--J.Wong 2024年7月2日 (二) 05:57 (UTC)

将管理操作复核设置为管理员布告板的子布告板

如题，见上方讨论，将管理操作复核设置为管理员布告板的子布告板，将作为集中处理涉及高阶权限的使用行为。桐生ここ★[讨论] 2024年6月29日 (六) 21:23 (UTC)

或者是直接指定管理员布告板本身也行吧？要评估一下流量。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年6月30日 (日) 04:13 (UTC)

应该不行，管理员布告板本身没法提供那些AARV的规则。再说管理员布告板本身也没有人会去用，目前貌似只是一个为存在而存在的东西。--桐生ここ★[讨论] 2024年6月30日 (日) 07:32 (UTC)

其实也可说是“制造”用途⋯⋯ —— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年7月1日 (一) 19:21 (UTC)

关于被无限期封禁者的用户页清空问题

我有一个问题，就是根据观察，被无限期封禁者（及被全域锁定者、被WMF封禁者）的用户页基本上都会被清空，然后再挂上各类无限期封禁模板。请问清空用户页这点在中维有无相关规定指引？反正在英维，无限期封禁者的用户页不会被清空，只是会额外挂上无限期封禁模板而已。--BigBullfrog（𓆏） 2024年7月8日 (一) 03:32 (UTC)

请参阅这里。Python6345（留言） 2024年7月8日 (一) 05:50 (UTC)

这条文仅限indef封锁。全域锁定虽然实务上比照indef封锁的方式办理，但并无本地成文规定。全域禁制一般不是本地处理的。Sanmosa _蚌埠 2024年7月8日 (一) 05:58 (UTC)

由于 维基百科:不限期不等于永久 不是方针，故管理员可以清空使用者页面。--唔好阻住我爱国（留言） 2024年7月8日 (一) 14:54 (UTC)

有关临时帐号正式使用后的傀儡方针及IP封锁方针

现时的傀儡方针中的在非登入状态下进行编辑以误导他人一节的描述为：

如使用多重IP位址进行编辑，以迷惑他人或违反上述原则，亦可视作是使用多重帐号的行为。

在临时帐号正式使用后，将会改以cookie的方法分辨用户。用户在更换IP后仍为该临时帐号，但不能使用第二个装置登入该临时帐号。考虑到有人会使用两个或以上的装置编辑以及cookie可以移除，请问是否需要规范临时帐号与另一临时帐号的关系（例如要求在其用户页表明关系）？此外，临时帐号启用后，只有部分用户能查看其IP，由于IP地址是用户私隐，故此是否需要规范何时才可以使用IP封锁？--132.234.229.111（留言） 2024年8月5日 (一) 08:34 (UTC)

傀儡部分，应该是仅限于已注册并“正式”的用户（相对于这次IP Masking机制下的“临时”用户），可能需要适当的描述调整，或者补充一个关于用户类型的定义说明mw:User_account_type（正式用户、临时用户、IP用户）。

IP部分，暂时只有管理员等拥有相应权限的用户可以查看，还是交由管理员去自行裁量某一组临时用户与IP的关系而判断是否连带IP（段）封锁，如果考虑IP隐私问题，或者单独IP（段）封锁并且涉及特定临时用户时是否声明这些关联。还有一个功能是“自动封禁该账号使用的IP地址”，暂时来看（Special:封禁列表），封锁一个用户并连带自动封锁对应IP段地址是不是不会显示相应地址段，应该已经技术上处理过这个问题（？）。——Sakamotosan路过围观 | 避免做作，免敬 2024年8月5日 (一) 09:15 (UTC)

可待技术措施正式出台，再研议如何调整相关方针。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2024年8月14日 (三) 18:13 (UTC)