维基百科讨论:管理操作复核请求

是否应该引入Administrative action review？

如题，en:Wikipedia:Administrative action review，提请讨论。--桐生ここ★[讨论] 2023年10月19日 (四) 15:02 (UTC)

场地的话建议直接使用互助客栈或管理员布告板。现在没有再额外多开一个页面的需求。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2023年10月19日 (四) 16:36 (UTC)

在下觉得讨论是否应该引入Administrative action review是个好想法。 关于具体的页面，可以进一步商讨。 en:Wikipedia:Administrative action review认为：管理操作审查（XRV/AARV）确定管理员工具或其他高级权限的使用是否符合维基百科的政策和指南。行政复议讨论的目的是就具体行动是否适当达成共识，而不是追究责任。 --Gluo88（留言） 2023年10月19日 (四) 18:27 (UTC)

听上去不错。管理员布告板听上去更像给管理员看的，而这个是提案和讨论（相关讨论可以分开和引流，但做标注），是不同功能，应该分开。--YFdyh000（留言） 2023年10月19日 (四) 22:49 (UTC)

那在互助客栈其他区开话题也行。目前本站的实践情况是分立页面往往导致流量大幅下降，讨论难以聚焦促进共识形成。我想重点应该要放在管理员操作复议流程本身。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2023年10月20日 (五) 17:41 (UTC)

过于互煮，难以阅读和追踪进度，讨论会自动存档。专门版面和流程，或将有助讨论的清晰化，发言可以适当约束或分流，哪怕只形成提报状态和讨论索引的页面，也是有帮助的。--YFdyh000（留言） 2023年10月20日 (五) 21:07 (UTC)

一个不错的想法。Sanmosa _{Ινα κραζω σοι} 2023年10月20日 (五) 01:08 (UTC)

我认为可以。--~~Sid~~ 2023年10月25日 (三) 12:04 (UTC)

需要拥有肯执行复议结果的管理员，就目前社群的情况来看不太确定能否稳定运行。--东风（留言） 2023年10月25日 (三) 14:35 (UTC)

本站缺乏深厚的社群基础来处理这种棘手的问题。目前而言，对于管理员权限运用的严重问题，除了最终手段的解任投票以外，社群多少还是会予以究责，但并不以某种正式的程序来运作。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2023年10月25日 (三) 22:42 (UTC)

在下也认同阁下的观点。比如，Wikipedia:互助客栈/其他#关于U:Bigbullfrog1996的不限期封禁, 已经出现非涉事管理员的处理被当管理事员回退， 产生了管理操作争议。

引入Administrative action review， 可以在社群形成共识， 便于非涉事管理员按社群共识处理， 避免进一步的管理操作争议和管理战。--Gluo88（留言） 2023年10月25日 (三) 23:51 (UTC)

如果大家都认可的话，是否有人愿意翻译？我翻译的话可能就不是那么原版了。--桐生ここ★[讨论] 2023年10月25日 (三) 15:22 (UTC)

@桐生ここ：暂时翻译了一半（WP:管理操作审查），不过我发现有很多地方都本地不适用，所以可能需要考虑本地的具体适用情形。Sanmosa _{Ινα κραζω σοι} 2023年10月27日 (五) 04:08 (UTC)

不符合本地的直接移除就可以了。--桐生ここ★[讨论] 2023年10月27日 (五) 04:14 (UTC)

我觉得可能需要考量哪些适用本地替代通道，哪些直接移除，比如部分enwiki里会送去仲裁的在zhwiki可能是走管理员紧急解任流程。6和7的替代通道我有些拿不定主意。Sanmosa _{Ινα κραζω σοι} 2023年10月27日 (五) 06:20 (UTC)

@Sanmosa：，不建议翻译为“审查”，“复检”比较不会有负面联想。--路西法人 2023年10月27日 (五) 06:10 (UTC)

我也只是翻译了一半而已，这译名的事情倒也不用太担心，一时三刻也成不了定案。Sanmosa _{Ινα κραζω σοι} 2023年10月27日 (五) 06:20 (UTC)

难道不应该是“复议（复议）”么？—— Eric Liu _{創造は生命（留言・留名・学生会）} 2023年10月27日 (五) 07:40 (UTC)

@桐生ここ：除了“管理操作复核请求并不用于”的第5、6项（原第6、7项）还没想好替代通道外，大体内容已翻译完成了，见WP:管理操作复核请求，但具体运作方式我没搬运过来。Sanmosa _{Ινα κραζω σοι} 2023年10月27日 (五) 07:00 (UTC)

但是我翻译了这么一轮，我感觉这XRV跟RFDA（联署前讨论）与RFDR都有一定程度的重合，或许可以考虑顺便整合一下RFDR，并容许可经XRV发起RFDA？Sanmosa _{Ινα κραζω σοι} 2023年10月27日 (五) 07:05 (UTC)

我原本也是这样考虑的，所以才说“我翻译可能就不是那么原版了”，不过，确实如东风说“需要拥有肯执行复议结果的管理员”，如果像Eirc说“社群多少还是会予以究责”，那么可能缺少愿意推翻原决定的管理员。因此原版方针的精神是社群来讨论处理问题，而不是追究责任。--桐生ここ★[讨论] 2023年10月28日 (六) 10:55 (UTC)

建议是想解决具体问题则发起AARV，认为管理员不再适合担任则发起RFDA。--桐生ここ★[讨论] 2023年10月28日 (六) 10:57 (UTC)

在下认为“解决具体问题则发起AARV” 是很好的建议。

"缺少愿意推翻原决定的管理员", 可能管理员个人复议判断与容易引起涉事管理员争议有关。

“肯执行复议结果的管理员”应该问题不大。如果经过XRV复议，社群形成共识，非涉事管理员只是按社群共识处理，不需要花大量的时间和经历与涉事管理员就管理操作争议长篇辩论， 避免进一步的管理操作争议和管理战。

在XRV复议过程中, 如果涉事管理员，对非涉事管理员按社群形成共识的处理，仍有不当的管理操作，涉事管理员被认为不再适合担任，再考虑发起RFDA。--Gluo88（留言） 2023年10月28日 (六) 13:17 (UTC)

我说的“容许可经XRV发起RFDA”就是这个意思。Sanmosa _{Ινα κραζω σοι} 2023年10月28日 (六) 13:49 (UTC)

那我不反对。--桐生ここ★[讨论] 2023年10月28日 (六) 17:09 (UTC)

第5项可以是WP:ANM，中维也没有其他渠道；第6项的CU封禁可以重提WP:SPI或联络WP:申诉专员处理、OS封禁可以联络WP:申诉专员处理。--桐生ここ★[讨论] 2023年10月28日 (六) 17:28 (UTC)

我把复核按钮加上了，见WP:管理操作复核请求，现在需要看社群是打算在互助客栈进行复核（使用Template:XRV-VPO），还是在这个页面进行复核（使用en:Template:XRV）。--桐生ここ★[讨论] 2023年10月28日 (六) 19:27 (UTC)

如果是互助客栈，大概效果是这样：Special:PermaLink/79547547。--桐生ここ★[讨论] 2023年10月28日 (六) 19:35 (UTC)

如果没有格式需求和长度担忧，可以先放在客栈、存档到专门页，流程稳定后再直接专门页面，避免早期缺乏广泛关注？不然，可能需要放T:公告栏，但何时适宜放会有争议。--YFdyh000（留言） 2023年10月28日 (六) 19:52 (UTC)

基本上放在互助客栈，提案通过便可以正常运作，可以利用Jimmy-bot完成存档，而且参与人数会比较多。如果使用专页，可能还需要一个机器人，或者修改现有机器人，而且每个讨论可能都需要放公告栏。流程稳定之后再到专页也不错。--桐生ここ★[讨论] 2023年10月28日 (六) 20:04 (UTC)

@Sanmosa：作为译者，您怎么看？--桐生ここ★[讨论] 2023年10月29日 (日) 13:35 (UTC)

我其实比较倾向于直接专门页面并应用DRV的格式，毕竟我用的译名是“复核请求”（对应enwiki的“review”）。不过如果具体需求不太大的话，不反对在过渡期内暂时移师客栈讨论。Sanmosa _{Ινα κραζω σοι} 2023年10月29日 (日) 16:58 (UTC)

正式提案

• 提报严重、根深蒂固或持续的争端、违规情形
  • 此时应请求仲裁（本地不适用）

@Ericliu1912、Sanmosa、YFdyh000、Gluo88、LuciferianThomas、ASid 有些问题想请教参与此讨论用户的意见：

1. 关于第5项的仲裁委员会替代方案有“其他不当行为”和“互助客栈”，选择哪个？
2. 是否同意过渡期内AARV暂时移师客栈讨论。
3. 是否大致同意现在的草案，并同意提升为正式流程。

--桐生ここ★[讨论] 2023年10月31日 (二) 11:54 (UTC)

（1）较倾向于ANM；（2）同意；（3）没特别的意见，反正我本来就只是想要翻译出来而已，也仅此而已。Sanmosa _{Ινα κραζω σοι} 2023年10月31日 (二) 12:00 (UTC)

社群对此议题似乎尚缺乏足够共识。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2023年11月1日 (三) 11:26 (UTC)

在上面的讨论中，

有五位认为这个似乎不错；

一位建议使用互助客栈；

一位认为不知道能否稳定运行；

没有特别明确的反对意见。

即便不通过成为正式流程，也可以像Category:英语维基百科指引中的一些指引，社群仍然可以按照这个指引实际运作，只是这个指引没有强制约束力而已，但按照这个指引社群讨论出的共识是有约束力的。就像不要诉诸法律威胁曾经只是论述，但仍然在需要的时候会被执行。--桐生ここ★[讨论] 2023年11月1日 (三) 16:39 (UTC)

我认为实施制度的时机还不够成熟，但是同意你的说法。上面提过社群已经有一些非成文程序来检讨管理员的操作，而充实这种程序自然是没有问题的。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2023年11月2日 (四) 03:01 (UTC)

可以考虑。--Borschts ^™ 2023年11月2日 (四) 14:55 (UTC)

那么作为非正式的流程，例如动员令、亚洲月、AFC等，移除此流程在{{布告板连结}}的灰色标注，非正式的启用此布告板， 公示7日。（与DRV不同的是，DRV是方针，XRV是论述。）--桐生ここ★[讨论] 2023年11月2日 (四) 17:46 (UTC)

不好。我觉得现阶段仍应作一种程序上的辅助论述，那就不当直接启用布告板。而且在互助客栈讨论总而言之也好些。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2023年11月3日 (五) 03:19 (UTC)

正确说法不是启用布告板，而是启用此论述，目前此论述的发起按钮是导向互助客栈的，只是那个灰色标注会让人以为不能按下那个按钮。--桐生ここ★[讨论] 2023年11月3日 (五) 03:37 (UTC)

是否不反对移除灰色标注？--桐生ここ★[讨论] 2023年11月3日 (五) 09:45 (UTC)

@Ericliu1912。--桐生ここ★[讨论] 2023年11月3日 (五) 15:28 (UTC)

论述的话就还不用放在布告板连结的导航模板了。可以放在管理员方针的参见章节，供社群参考。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2023年11月3日 (五) 15:36 (UTC)

这个状态就像WP:COI和COI布告板目前也只是论述。--桐生ここ★[讨论] 2023年11月3日 (五) 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)