维基百科

维基百科讨论:管理员/存档5

< Wikipedia talk:管理员
132.234.228.109在话题“编辑请求 2023-09-24”中的最新留言：1年前

讨论应该如何理解和判定 Wikipedia:管理员#避嫌

最新留言：在3年前发布21条留言8人参与讨论

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

本主题或以下段落文字，移动自Wikipedia:互助客栈/其他#讨论应该如何理解和判定_Wikipedia:管理员#避嫌。执行人：U:Gluo88。

  • （见Wikipedia:管理员#避嫌）“管理员不应该在一项事宜中使用普通用户和管理员的双重身份”, 网上了解了一下各种例子， 我觉得:本次“封禁”是视乎是由于同一“争持”引发（紧接地管理员对该事件的警告应该看做 “同一事宜”）。 由于任何个人的见解都会带有主观性， 很需要听一听其它维基人“同一事宜”的看法， 类似于某些法院评判靠陪审团的成员，政治论题评判靠民意的多数。我也刚看到这件事， 感有关对方针的理解，权衡利弊， 多讨论一些时间可能更好些， 能让更多人参与使得讨论更充分一些。“同一事宜”的 “争持”中，管理员对该事件的警告带有主观性，甚至是报复性的警告，可能性极大，所以需要避嫌“同一事宜”的处理。--Gluo88（留言） 2021年1月21日 (四) 14:46 (UTC)
    三个月的时间足够长了，却没有得出任何结论。“对封禁或封禁期限不满请去挂T:Unblock，然后等待其他管理员介入”，这是最行之有效的解决方案。--安忆Talk 2021年1月21日 (四) 14:23 (UTC)
    看来我与您在这个问题下的“时间是否足够长”有不同见解。我也刚看到这件事后， 网上做了调研，提出上面的看法。 很想和大家心平气和的理性地讨论。 由于任何个人的见解都会带有主观性， 这也需要听一听其它维基人的观点。--Gluo88（留言） 2021年1月21日 (四) 14:32 (UTC)
    1. 我觉得讨论三个月已经够久了。2.建议不要在其他人留言之后，再重新在留言中加入新的标题，改变其他人留言所在的段落（例如这个）,这有可能影响读者对留言的解读。--Wolfch (留言) 2021年1月21日 (四) 16:04 (UTC)
    事件内，此管理员以管理员身份做出警告，却未被回应并被无视，才加以封禁处理；如提封禁申诉，此申诉是由其他的、事件之外的管理员处理的，并非由当事管理员处理。故无嫌可避。--安忆Talk 2021年1月22日 (五) 04:27 (UTC)
    封禁不是由争执引起，而是作为管理员对于违规行为，经警告无效后的处理措施。--安忆Talk 2021年1月22日 (五) 04:30 (UTC)
    接#Mys 721tx滥权，任意封禁用户。考虑到此话题为中途插入，与原有讨论的诉求无关联，且“分割章节”的做法或影响他人对原有留言的理解，现将此话题独立出来。--安忆Talk 2021年1月21日 (四) 16:57 (UTC)
  1. 本条目被从： Wikipedia:互助客栈/其他#Mys_721tx滥权，任意封禁用户 分出来， 专门讨论按Mys_721tx滥权中（Wikipedia:管理员#避嫌）方针 - “管理员不应该在一项事宜中使用普通用户和管理员的双重身份”，对于“同一事宜”的各种不同看法。侧重对方针的理解的讨论。 比如上面讨论中，在这里只是想抽象出一个例子来讨论。
  2. 由于任何个人的见解都会带有主观性， 很需要多听一听维基人“同一事宜”的各种不同看法。本论题很难像形式逻辑的命题，可以靠纯粹的逻辑推理解决。而更像政治论题评判，主要靠充分的讨论， 理解双方论点和理由， 然后靠民意的多数。 比如，充分的讨论后的投票等 （也许可以考虑按维基的 “共识” 和“公示”程序。 ）。
  3. 也可考虑将本事件抽象出对以后的判别有参考价值的案例，补充到 Wikipedia:管理员#避嫌一节中。

--Gluo88（留言） 2021年1月21日 (四) 18:07 (UTC)

@Mys 721tx： @Uranus1781： @AnYiLin： @Catowen： @Catowen： @Ericliu1912： @YFdyh000： @Mewaqua： @Sanmosa： @周雁棠： @Hjh474：（见Wikipedia:管理员#避嫌）“管理员不应该在一项事宜中使用普通用户和管理员的双重身份”, 网上了解了一下各种例子， 我觉得管理员和用户“争持”引发出该管理员的“警告”和“封号”这三个步骤是应该看做同“一项事宜”。“同一事宜”的 “争持”中，管理员对该事件的警告带有主观性，甚至是报复性的警告，可能性极大，所以需要避嫌“同一事宜”的处理。 是否按 Wikipedia:管理员#避嫌 要求，管理员不应该自已“封号”和自己正在进行争持的用户？
--Gluo88（留言） 2021年1月23日 (六) 03:43 (UTC)

  • 此管理员在执行封禁前并没有和用户争执，故您的论据不存在，且搞错了发生顺序。此管理员为应对违规行为以管理员身份施以多次警告，均未被回应且被无视，才加以封禁。争执的内容，即“争执该不该永封”是在封禁后产生的。--安忆Talk 2021年1月23日 (六) 03:56 (UTC)
  1. 谢谢分享看法。这里讨论的是： 管理员和用户“争持”引发出该管理员的“警告”和“封号”这三个步骤的情况。关于你说的案例，不在这个提案讨论范围。
  2. 关于你说的案例是否属于这种情况的个例（尽管我的观点与你不同）， 应该在Wikipedia:互助客栈/其他#Mys_721tx滥权，任意封禁用户的讨论范围。
  3. 很想和大家心平气和的理性地讨论。 由于任何个人的见解都会带有主观性， 这也需要听一听其它维基人的观点。
--Gluo88（留言） 2021年1月23日 (六) 04:28 (UTC)
如果真的有某管理员和某用户的争执在此管理员对此用户实施封禁前发生，可以警告，因为警告是所有人可以做的。但不可以自行封禁，应求助于其他管理员，这是现行方针的规定。所以您想改善什么呢？--安忆Talk 2021年1月23日 (六) 04:34 (UTC)
谢谢分享看法。是否下面的解释对应了你上面的说法：
  1. 如果真的发生争执，按“避嫌”原则，只能用其普通用户身份， 所以不可以自行封禁，应求助于其他管理员。
  2. 关于“如果真的发生争执，可以警告，因为警告是所有人可以做的”。 但这时，发警告的身份应该看做是普通用户， 而不是管理员。 可以发多次警告， 但不能以发了多次警告为理由，来实行封禁。
  3. 与其说改善我宁愿说是澄清。
--Gluo88（留言） 2021年1月23日 (六) 05:05 (UTC)
2有补充，“但不能以发了多次警告为理由，来实行封禁”改为“但此管理员不能以发了多次警告为理由，来实行封禁。应请求其他管理员介入并由其他管理员进行定夺。”--安忆Talk 2021年1月23日 (六) 05:14 (UTC)
User:爱学习的饭桶/免死金牌。-Mys_721tx（留言） 2021年1月23日 (六) 05:28 (UTC)
  1. 我认同 U:AnYiLin的进一步补充， 多谢了。
  2. 请问Mys_721tx君是否同意经U:AnYiLin 进一步补充的观点，谢谢。 也谢谢Mys_721tx君分享， User:爱学习的饭桶/免死金牌 开始就说："本用户页因幽默而保留，请不要当真。"
--Gluo88（留言） 2021年1月23日 (六) 12:52 (UTC)
  • (！)抗议Mys 721tx把到处批评他的User:醍醐的花见永久封禁，也是没有避嫌。--124.217.188.96（留言） 2021年1月23日 (六) 12:32 (UTC)
    建议去看封禁日志和理由。此用户持续添加侵犯版权内容、散发原创研究及使用傀儡，封禁由短及长，直至永封；后于八月申诉中承诺“再也不做”，结果又犯，再次被永封；在其他管理员实施单页编辑限制后其又去其他页面继续进行违规行为，屡教不改再次招致永封。管理员的做法合规得不得了，有何嫌需避。--安忆Talk 2021年1月24日 (日) 04:04 (UTC)
    路过，留个言就走，不要期望我作进一步回应。个人认为上述案例某程度上存在问题。从当时站内外的讨论，我觉得该用户只是未能掌握防止侵犯版权以及不发布原创内容之间的平衡，未见其编辑行为存在破坏性质，最佳做法应该是AGF、劝导并协助用户改写内容。封禁乃用作防止破坏而非惩罚用户，这一点还是有些管理员会偶然越线（案例：Sanmosa君的对上一次封禁），而相反对于某些用户却存在过大的包容度，某程度上看见双重标准的情况。以上只是我对于上述案例及某些管理员行径的个人意见。--LuciferianThomas．留言 2021年1月25日 (一) 08:26 (UTC)
    (▲)同上。-- 2021年1月31日 (日) 04:33 (UTC)

改进自我解封（unblockself）权限描述

最新留言：在3年前发布19条留言4人参与讨论

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

现行条文

解除自我封锁。[1]

提议条文

解除自我封锁。 [2]

参考资料

  1. ^ 自我封锁为自己对自己的封锁，此功能由软体直接实现。自2018年12月起，管理员已被取消“自我解封（unblockself）”的权限（T150826），但为了阻止被盗窃的管理员帐号，仍可在封锁状态下封锁对自己执行封锁的管理员。
  2. ^ 自我解封是解除对自己的封禁，此功能由MediaWiki软体实现。因2018年11月曾发生多起管理员被盗号且在自我解封后继续破坏的事件，2018年12月起，维基媒体基金会所属计划上的管理员已无“自我解封（unblockself）”权限（T150826），为预防被盗管理员账号封禁其他管理员以持续破坏，被封禁的管理员能封禁对自己执行封禁的管理员。管理员一直能解除由自己对自己执行的封禁。

位于Wikipedia:管理员#封禁与解封用户。主要是脚注。注：所用MediaWiki转换组现有'zh-cn:封禁; zh-tw:封鎖; zh-hk:封鎖;'，源码中的“封锁”变化请忽略。

另外，同段现有的“查封”用词是否该统一为“封禁”，不必要的动词形式？（无地区词转换）。--YFdyh000（留言） 2021年2月10日 (三) 18:49 (UTC)

抱歉先暂停讨论，{{inuse}}，提案的叙述仍有问题。--YFdyh000（留言） 2021年2月10日 (三) 19:03 (UTC)

修订完成。考虑过“自我解封、解除自我封锁。”这样划线以区分，但或许不易理解。--YFdyh000（留言） 2021年2月10日 (三) 19:22 (UTC)

“但为了防止被窃的管理员账户封禁其他管理员后继续破坏”是否更明确一点？--Lt2818（留言） 2021年2月11日 (四) 07:02 (UTC)
@Lt2818：指换掉“但为了允许反封禁被窃的管理员账户”这句吗。感觉不明确啊，除非“其他”换成“其他所有管理员”/“其他活跃管理员”。--YFdyh000（留言） 2021年2月11日 (四) 07:15 (UTC)
没必要加这些定语吧，我封禁【所有-1】或者【活跃+1】的管理员就不符合。另外下一句过长，可以保持原先【在封禁状态下】的表述。--Lt2818（留言） 2021年2月11日 (四) 07:25 (UTC)
活跃+1仍包括“其他活跃”。感觉看不懂“封禁其他管理员后继续破坏”，因为此时没明说被封禁时能否正常行使封禁权。想等待更多意见。--YFdyh000（留言） 2021年2月11日 (四) 07:58 (UTC)
我先说明一下提议条文中的问题：“反封禁（此三字若无下文则不知所云）被窃的管理员账户”是手段而非目的，放在“为了”后不大合适。原文有些翻译腔但可以理解。不妨再找找合适的行文。--Lt2818（留言） 2021年2月11日 (四) 09:23 (UTC)
原本的描述是我原创的，居然被说翻译腔，哈哈哈哈哈...。--Xiplus#Talk 2021年2月11日 (四) 13:02 (UTC)
我们中出了一个老外--YFdyh000（留言） 2021年2月11日 (四) 16:15 (UTC)
“翻译腔”是对文字风格的（负面）描述，并非指文字由翻译得来。--Lt2818（留言） 2021年2月12日 (五) 14:45 (UTC)
“为了允许”，允许后面放行为而非目的没毛病吧，这样设计的目的就是允许这样的行为。--YFdyh000（留言） 2021年2月11日 (四) 16:17 (UTC)
这条无所谓，问题不大。但是“反封禁”的确难以理解。--Lt2818（留言） 2021年2月12日 (五) 14:49 (UTC)
我想说“反过来封禁”的意思，需要表达那么清楚吗（我不反对），会有人理解为unblock吗……--YFdyh000（留言） 2021年2月12日 (五) 14:51 (UTC)
我知道是这个意思（不是说unblock），展开了同样难以理解。你这里缺少一个“封禁其他管理员”的假设，否则“反过来封禁”难以成立。--Lt2818（留言） 2021年2月12日 (五) 15:08 (UTC)
我的理解是“反封禁”隐含了自己被封禁的前提，才能反过来。总之，语句改了，再看一下。--YFdyh000（留言） 2021年2月12日 (五) 15:25 (UTC)
没问题，现在感觉好多了。--Lt2818（留言） 2021年2月12日 (五) 16:08 (UTC)
“但为了防止被窃的管理员账户封禁其他管理员后无法被制止的情况出现”，这样可能清晰一点，但行文比较长。--Lt2818（留言） 2021年2月11日 (四) 09:50 (UTC)

新的质疑

最新留言：在3年前发布1条留言1人参与讨论

管理员并没有特权，这句话及以下整段话现在仍挂在条目正文中，这完全和现状相悖，为何迟迟不进行修改？──以上未签名的留言由子非鱼何不食肉糜（讨论｜贡献）于2021年7月21日 (三) 11:38 (UTC)加入。

关于管理员方针中“避嫌”一节的探讨

最新留言：在3年前发布4条留言3人参与讨论

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

据我所知，“避嫌”一节常在争议中被引用，而大家对于此处的规定的理解各不相同，所以想要拿出来探讨一下。以下是方针原文：

管理员不应该在一项事宜中使用普通用户和管理员的双重身份，而应该要么使用普通用户的身份，要么使用管理员的身份，尽管用户是同一个人。在以下场合的具体限制有：

  • 保护：管理员不应该保护/解除保护他们牵扯进去的页面，而应该像普通用户一样求助于其他管理员，这些页面不包括诸如主页等的常见保护页面；
  • 封禁：管理员不得仅因某用户反对自己而封禁这个用户；
  • 删除：管理员不得删除自己提议删除或者投票删除的页面；

在以上情况下，管理员应该以普通用户的身份要求其他管理员协助。

以上规定似乎仅仅是关于某个用户与管理员的二元关系，并没有涉及到编辑团体或者地域的描述。当今中文维基社群内部较为复杂，很多情况下，事情会延伸到持不同观点的编辑群体，抑或是来自不同地域的编辑群体。于是，我希望社群能够明确以下情形中，“避嫌”是否适用，以及如何适用。

  1. 某一地区分会或用户组的用户（如台湾分会、大陆的WMC、香港的WMHK用户组），成为争议、扰乱、破坏等的主体的时候，该地区分会或用户组内的管理员是否有避嫌的义务？
  2. 某一政治立场的用户（如统派、独派），成为争议、扰乱、破坏等的主体的时候，与其持相同（政治）立场的管理员，是否有避嫌的义务？
  3. 站外行为是否能够影响站内“避嫌”的适用？如果站外人身攻击或者歧视呢？如果适用，相关的分会或用户组的管理员又是否会连带受限？
  4. 封禁明确的破坏（违反方针）的用户，保护明显受到破坏的页面，是否应当不受“避嫌”的限制？
  5. (PLUS) 如果其他管理员有连带的避嫌义务（无论是因为分会、用户组还是立场），那么是否会造成其他无组织、未表明立场的管理员在权力上超出有组织、有立场的管理员？

近期的一些问题以及以往遇到过的事实让我想要看看大家对于这些怎么看待。--1=0，欢迎加入WP:维基百科维护专题 2021年7月16日 (五) 04:04 (UTC)

简答：
  1. 视情况，因为分会或用户组是实在而紧密的组织，确有组织集体行动／决策的可行性，但组织集体行动／决策并非必然。故此同属同一分会或用户组且有明显迹象表明为集体行动／决策（的结果）的情况下才可构成适用避嫌的情形。
  2. 不适用，因为“某一政治立场的用户”是概念性而松散的群体，并且其成员的实际具体理念可能也有一定的差异，因此组织集体行动的可行性低，集体决策的可行性则为零。故此同属同一政治立场本身不构成适用避嫌的情形。
  3. 站外行为如果和站内行为有明确联系或关系，则适用。相关行为的“人身攻击”或“歧视”的属性本身需要社群共识确定，如果社群共识确定有相关属性的话，可以不适用。分会或用户组成员是否连带受限取决于站外行为是否和站内行为有明确联系或关系且有明显迹象表明该站外行为为集体行动／决策（的结果）。
  4. 要视乎共识是否认可相关情形是否真的是“破坏”。如果真的是“破坏”，自然可以不适用。
  5. 技术上不存在权力“超出”的情况，因为没有管理员因任何管理员有连带避嫌义务而获得永久额外权限，有永久额外权限的管理员只有行政员（和监督员）。连带避嫌义务的生效仅为对具连带避嫌义务的管理员在行使权力时暂时性的限制。
以上。SANMOSA Σουέζ 2021年7月16日 (五) 13:22 (UTC)
补充：1和2的分别在于前者的成员身分是确切、非有即无的，而后者的成员身分是模糊、可被诠释的（有时候可以视为有，有时候可以视为无）。SANMOSA Σουέζ 2021年7月16日 (五) 13:27 (UTC)

尝试重提管理员复任制度

最新留言：在3年前发布49条留言11人参与讨论

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

下列讨论已经关闭，请勿修改。如有任何意见，请至合适的讨论页进行，并不要再次编辑本讨论。

在下一向认为，解任一段时间不活跃之管理员是考虑到帐号安全问题，而不是能力问题（如果是的话就应该走罢免路线），何况各种因为现实生活充实啊、暂时想休息啊之类因素而自行辞职的情况。只要其恢复活跃，一般而言，没有不重新赋予其管理员权限，尽速恢复投入站务工作的理由。此外，目前所有管理员复任都要经过重新选举，而选举不仅费时费力（近年来问题愈加泛滥，数目更是直线上升到了候选人可能难以负荷的地步），且还曾经出现AT辞了又选选了又辞，选了6次这种例子（当然，这是极端情形）。故参考英文维基百科早先修订之相关规定，提议设立管理员复任制度，概要如下：

  • 在自愿辞职或因不活跃而离任的情况下，前管理员可提出管理员复任申请，由行政员审核。
    • 由于行政员布告板尚未开设，可考虑一并启用之，或另设申请提出地点。
  • 若有以下情况，不应予以直接复任：
    • 当事人过往是在牵涉争议之情况下自行辞职。
      • 此时，当事人应循一般申请管理人员程序重新上任，或至少先经社群广泛讨论，直至达成共识为止。
    • 长期不活跃，满足其中一项条件：
      • 当事人自愿辞职后二年以上没有编辑，或因不活跃而离任后一年以上没有编辑；
      • 当事人申请复任前已至少五年未进行管理操作。
      此时，当事人应循一般申请管理人员程序重新上任。
    • 无法保障当事人帐号之安全性。
  • 授权前，行政员应确信当事人已恢复活跃或将恢复活跃，并至少待申请提出达24小时。若过程中他人有所疑虑，行政员应推迟授权，并进行充分讨论，直至达成共识为止。

考虑到本地显然不能直接套用其他维基的制度，且过往社群对相关话题意见繁多，希望社群此次能再提出修订意见，放松或加严规定，以期符合本地对于管理员行使职能之期望。此外，若对过往情形有所疑虑，社群亦可考虑不溯及既往。

注：因应近期之基金会行动，若有必要，可延后实施此制度，以防混乱。—— Eric Liu 创造は生命（留言．留名．学生会） 2021年9月25日 (六) 18:27 (UTC)

“牵涉争议之情况下自行辞职”应如何定义，英维是否曾有相关案例因而受到行政员拒绝复权？--NHC、才不是NPC呢哼！｡:.ﾟヽ(*´∀`)ﾉﾟ.:｡ 2021年9月25日 (六) 18:54 (UTC)
举个抽象的例子，假如某管理员被提起罢免，讨论正激烈或已经进入连署阶段，他意图先辞职“避风头”，待风头过后再申请复任，这样的情况就不应该被允许。具体案例可能要花一点时间寻找；此条文似乎近年来在英维不常被引用，长期不活跃才是当地历来复任失败的主因。关于因此进入深入讨论，惟最后成功复任的案例可见此，在该案中同时对此条文进行了一些分析。—— Eric Liu 创造は生命（留言．留名．学生会） 2021年9月25日 (六) 19:40 (UTC)
那PhiLiP是自愿辞职，但原因是抗议爱孟解封，这种情况下适合直接复任吗？--中文维基百科20021024（留言） 2021年9月25日 (六) 22:04 (UTC)
他有直接牵涉进去守望者爱孟事件吗？（比如：有在辞任前的相近时间在相关讨论中表示反对解除封锁守望者爱孟吗？）Sanmosa Outdia 2021年9月26日 (日) 01:06 (UTC)
根据他的辞职理由，我感觉很可能有。--中文维基百科20021024（留言） 2021年9月26日 (日) 01:50 (UTC)
那就可能不适合。不过讨论这个也没甚么意义，因为他没有表明自己希望恢复管理员权限。如果他根本不打算恢复管理员权限的话，那他能不能依照管理员复任制度恢复管理员权限就完全不重要了。Sanmosa Outdia 2021年9月26日 (日) 02:17 (UTC)
我不会尝试不经投票就恢复权限的。可见的未来里也没打算恢复权限（无论投票与否，但界面管理员可能除外，我还没想好）。--菲菇＠维基食用菌协会 2021年9月26日 (日) 05:24 (UTC)
我认为管理员复任制度要注明一点：管理员复任制度仅适用于恢复管理员权限，自愿辞职或因不活跃而离任前同时兼具的其他权限（如行政员、监督员）不因管理员权限的恢复而同时恢复，而仍须循一般申请管理人员程序重新上任。另：介面管理员或可同时适用管理员复任制度。Sanmosa Outdia 2021年9月26日 (日) 01:12 (UTC)
@Ericliu1912：根据上面的东西写了Wikipedia:管理员的复任（参考了User:Aotfs2013/草稿列表/管理员的休任），有需要的话自行调整即可。有鉴于行政员布告板尚未开设，而且我也不预期有大量管理员会提出复任，我觉得直接在“管理员的复任”页面申请即可。Sanmosa Outdia 2021年9月26日 (日) 02:51 (UTC)
理论上不用另立页面，写入《管理员方针》、《行政员方针》即可；亦可直接开设行政员布告板，可预期该处除了处理管理员复任申请，还能处理机器人作业申请批准等行政员积压工作。另外，英维那边是允许同时取回行政员权限的，但考虑到本地可能对此产生争议，可改为不允许直接复任。—— Eric Liu 创造は生命（留言．留名．学生会） 2021年9月26日 (日) 04:59 (UTC)
@Ericliu1912：如果要开设行政员布告板的话，我预期会导致页面的大量移动，这需要另外寻求社群许可。此外，zhwiki也单设了WP:管理员的离任页面，我认为单设WP:管理员的复任会是较适合的安排。同意改为前管理员不允许直接恢复行政员权限。另：希望就介面管理员应否适用作回应。Sanmosa Outdia 2021年9月26日 (日) 05:33 (UTC)
应规定仅适用于管理员权限。另外不清楚开设行政员布告板会如何“导致页面的大量移动”。我稍微修正一下我早前的说法，行政员布告板实际上以处理管理员请辞和不活跃解任为主要业务，若开设可将该二项业务并入行政员布告板。—— Eric Liu 创造は生命（留言．留名．学生会） 2021年9月26日 (日) 05:41 (UTC)
我个人对于介面管理员应否适用没大意见。就修正说法后的情况，那我就不预期会导致页面的大量移动了，但由于还是需要整合页面，这需要另外寻求社群许可（可能还需要改方针）。Sanmosa Outdia 2021年9月26日 (日) 14:28 (UTC)
Sanmosa话说，其实我是有考虑重新将一些离任相关内容整并回管理员方针的（但要分阶段处理，不适合在此处包裹提案），所以才觉得复任相关内容一开始就写在管理员方针更加好。—— Eric Liu 创造は生命（留言．留名．学生会） 2021年10月25日 (一) 03:09 (UTC)
假设某用户于2010年自愿辞任管理员后，在30年间一直有编辑，然后于2040年申请直接复任管理员，可以接受否？--Mewaqua（留言） 2021年9月27日 (一) 15:48 (UTC)
要看当事人这三十年间做的主要是什么类型的编辑。此外，对于这种极端情况，我想绝对会适用“他人有所疑虑”那一段，没那么容易直接复任。—— Eric Liu 创造は生命（留言．留名．学生会） 2021年9月27日 (一) 17:35 (UTC)
考虑到原草案确实有点太宽松，修正了一下，这样应该可以避免此情况发生了。—— Eric Liu 创造は生命（留言．留名．学生会） 2021年9月27日 (一) 17:45 (UTC)

征询一下@Antigng、Aotfs2013之意见。—— Eric Liu 创造は生命（留言．留名．学生会） 2021年10月5日 (二) 06:21 (UTC)

@Ericliu1912：你还打不打算推行？WP:7DAYS的说明是讨论持续了30日就可以公示，所以最早10月25日就可以公示了。需要做甚么调整的话请明示。Sanmosa WÖRK 2021年10月20日 (三) 02:45 (UTC)
当然有打算，但就现在这参与程度来看，强行公示也不见得能服众，只能待更多人来参与。上面我ping的那二人都对复任制度有想法，只是可能他们最近忙吧，都没有回应。—— Eric Liu 创造は生命（留言．留名．学生会） 2021年10月20日 (三) 08:49 (UTC)
@Ericliu1912：或许你再另外ping几个人来也可以，Bulletin单列一栏吸引关注也可以。Sanmosa WÖRK 2021年10月25日 (一) 03:13 (UTC)
Antigng和Aotfs2013再ping一次好了。—— Eric Liu 创造は生命（留言．留名．学生会） 2021年10月22日 (五) 06:39 (UTC)

方针修订草案

预定修订管理员方针、行政员方针，修订内容暂定如下：

（管理员方针）（顺便简单整理一下相关段落）

现行条文

管理员的权限取得与丧失 如果你觉得自己或他人有资格成为管理员，请见Wikipedia:申请成为管理员的申请标准及程序。

管理员离任的具体办法，或提请取消某位管理员的权限，请见Wikipedia:管理员的离任。

提议条文

管理员的权限取得与丧失 申请 如果你觉得自己或他人有资格成为管理员，请见Wikipedia:申请成为管理员的申请标准及程序。

离任 管理员离任的具体办法，或提请取消某位管理员的权限，请见Wikipedia:管理员的离任。

复任 无论管理员为何离任，皆可以上方提及之一般程序重新申请成为管理人员。

而在自愿辞职或因不活跃而离任的情况下，当事人可提出管理员复任申请，由行政员审核。基本上，复任申请除有以下情事外应可获通过：

  • 牵涉争议而辞职：若当事人过往是在牵涉重大争议（例如被提起解任投票）之情况下自行辞职，则应循一般管理人员申请程序重新上任，或至少先经社群广泛讨论，直至对于当事人之地位达成共识为止。
  • 长期不活跃而满足以下其中一项条件，此时行政员应当否决复任申请，而当事人应循一般管理人员申请程序重新上任：
    • 自愿辞职后2年、不活跃离任后1年未有编辑：当事人在自愿辞职后已至少2年没有编辑，或因不活跃而离任后至少1年没有编辑；
    • 申请复任前5年未有管理操作：在因不活跃而离任之情况下，当事人申请复任前已至少5年未进行管理操作。
  • 无法保障当事人帐号之安全性：有合理根据，可认为当事人帐号之安全性不受保障，以至于不适合直接取回重大权限。相关证据应当向行政员提出，并附详细说明。

管理员复任申请应在行政员布告板提出，由行政员依据权限恢复程序操作。授权前，行政员应确信当事人已恢复活跃或将恢复活跃，并至少待申请提出达七日。若过程中他人有所疑虑，行政员应推迟授权，并进行充分讨论，直至达成共识为止。

本制度不适用于介面管理员、行政员、使用者查核员与监督员。从这些职务上离任者应循一般管理人员申请程序重新上任。

（行政员方针）

现行条文

权限 （略）

提议条文

权限 （略）

恢复权限 若有复任申请在行政员布告板提出，行政员应当遵循以下程序操作：

  1. 确认当事人是否曾是管理员；
  2. 确认当事人离任原因为自愿辞职或不活跃；
  3. 检查当事人之使用者讨论页、相关布告板、互助客栈和其他讨论，确认当事人是否因牵涉争议而辞职；
  4. 为充分确认申请之合理性，行政员在授权前应至少待申请提出达7日，以让其他行政员和编者发表意见。若有足以影响情况之新资讯出现，行政员可适当推迟授权时间；
  5. 若当事人在自愿辞职后已至少2年没有编辑，或因不活跃而离任后已至少1年没有编辑，行政员应当否决申请，或转介一般管理人员申请程序；
  6. 若当事人申请复任前已至少5年未进行管理操作，行政员应当否决申请，或转介一般管理人员申请程序；
  7. 在恢复管理员权限前，行政员应确信当事人已恢复活跃或将恢复活跃；
  8. 若在复任申请之审核过程中他人有所疑虑，行政员应推迟授权，并进行充分讨论，直至达成共识为止。

以上。请诸位为草案修订提供更多意见。—— Eric Liu 创造は生命（留言．留名．学生会） 2021年10月25日 (一) 04:36 (UTC)

24小时也太短了。可能长一点但不要至少的字眼。--ghren🐦吱吱吱...🔊 2021年10月25日 (一) 04:43 (UTC)
那延长至三日应该足够了吧。—— Eric Liu 创造は生命（留言．留名．学生会） 2021年10月25日 (一) 13:39 (UTC)
我觉得够，但是你维是连公示废话都要14天的，看看其他人意见。此外我颇担心这制度会成了受争议人物的捷径，就像和奋球，（节删）而且本身也就试过高票落选，假如他去申请，新制下会如何处理呢？--ghren🐦吱吱吱...🔊 2021年10月25日 (一) 13:57 (UTC)
他辞职后二年以上没有编辑，不得申请。假设他可以申请的话，他不是因为牵涉争议而辞职的，或可适用“他人有所疑虑”这一段之叙述，由诸位行政员来斟酌。不过您确定您说的真的是他吗？好像不太符合实际情形？—— Eric Liu 创造は生命（留言．留名．学生会） 2021年10月25日 (一) 14:20 (UTC)
认错人了，当他合乎辞职后二年有编辑算了。行政员会怎样处理呢？不太喜欢有过于空洞的条文。特许一定是会推迟的。就怕一些牵涉重大争议的人物过了投票后两三年后辞职，然后用这机制上任时大家又要互撕，当然我是在WP:水晶球。--ghren🐦吱吱吱...🔊 2021年10月25日 (一) 15:09 (UTC)
如果会互撕的话，我觉得在这三天的时间内应该就会有其他编者来发表异议了，毕竟某种程度上来说管理员申请比方针修订案之类的还要多人关注（从参与相关投票的人数比较可知一二）。加上行政员应有充分判断能力，个人觉得问题应该不太大。---Peacearth（留言） 2021年10月25日 (一) 15:50 (UTC)
不信任我维行政员的人不在少数，条文能写清就最好了。--ghren🐦吱吱吱...🔊 2021年10月25日 (一) 17:56 (UTC)
@Ericliu1912没人互煮就准备公示吧。--ghren🐦吱吱吱...🔊 2021年11月2日 (二) 02:14 (UTC)
(：)回应@Ghrenghren：本人并未参与RSN讨论，何来在该处得罪其他主编之说？我更没有上过ANB，您大概是认错人了。-Peacearth（留言） 2021年10月25日 (一) 14:31 (UTC)
尬了，记反了。不好意思啊，真的不好意思。ghren🐦吱吱吱...🔊 2021年10月25日 (一) 14:37 (UTC)
了解，没关系的：）-Peacearth（留言） 2021年10月25日 (一) 15:52 (UTC)

再收集讨论一会。ghren🐦吱吱吱...🔊 2021年11月6日 (六) 18:36 (UTC)

参考7DAYS，72小时建议改成7天吧。桐生君★[讨论] 2021年11月14日 (日) 09:06 (UTC)

7DAYS只规范互助客栈，这理由说不通吧。Sanmosa Ázijský Mesiac/Asiatischer Monat 2021年11月14日 (日) 10:49 (UTC)
单纯只是从7DAYS取了一个数，不是要遵循7DAYS方针，像是自确也是7天。桐生君★[讨论] 2021年11月14日 (日) 11:08 (UTC)
@Sanmosa这个从宽不从紧吧，就7天吧，三天可能真的未必够时间表达反对意见，也不应该为这小问题而再拖复任方案了。--ghren🐦吱吱吱...🔊 2021年11月14日 (日) 12:34 (UTC)
我是没大意见。@Ericliu1912。--Sanmosa Ázijský Mesiac/Asiatischer Monat 2021年11月14日 (日) 13:35 (UTC)
行吧。—— Eric Liu 创造は生命（留言．留名．学生会．STE） 2021年11月14日 (日) 13:45 (UTC)
依WP:7DAYS，此案自2021年9月25日 (六) 18:27 (UTC)起已讨论逾30日，故送公示。Sanmosa Hrom a peklo, márne vaše proti nám sú vzteky! 2021年11月16日 (二) 08:12 (UTC)
假如申请人在辞任或因不活跃而离任管理员后在行为上有重大违反、或近期的非轻微违反、或长期持续的非轻微违反中文维基百科或其它维基媒体计划网站的方针或指引、维基媒体基金会决议或使用条款，是否可以用“在复任申请之审核过程中他人有所疑虑”反对复任申请？如果因此不予简易复任，又是否与“基本上，复任申请除有以下情事外应可获通过”有矛盾？--Mewaqua（留言） 2021年11月16日 (二) 17:02 (UTC)
“基本上”与“一般情况下”等义，如果出现了特殊情况，那就算不是该部分所列出的情事也可以成为拒绝理由。你提到的那些情况属于我刚才提到的“特殊情况”，因此如果行政员确实认为相关情节严重至不可复权，他可以以“在复任申请之审核过程中他人有所疑虑”为由拒绝，而如此为之并不会与“基本上，复任申请除有以下情事外应可获通过”有矛盾，原因是“基本上”限定词的存在。--Sanmosa Hrom a peklo, márne vaše proti nám sú vzteky! 2021年11月17日 (三) 02:04 (UTC)
@Mewaqua。Sanmosa Hrom a peklo, márne vaše proti nám sú vzteky! 2021年11月17日 (三) 03:02 (UTC)
@Ericliu1912提案已通过。--Sanmosa WAM 2021年11月25日 (四) 05:45 (UTC)
本讨论已经关闭，请勿修改。如有任何意见，请至合适的讨论页进行，并不要再次编辑本讨论。

“管理员”是否应该更名为“系统操作员”

最新留言：在3年前发布28条留言11人参与讨论

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

目前看到当前方针板“增加管理员站务要求”的讨论，管理员向一些用户解释管理员并不是一般人认知中的管理员，而是一名受到社区信任，被解除一些限制的用户。 但是管理员这个词，其实是具有刻板印象的一个词，因此才造成一些人的误解，是否应该将“管理员”改名为“系统操作员”？ 系统操作员正好也是“sysop”的中文译名，这样用户就能理解系统操作员跟模板编辑员之类的概念是一样的，减少误解。 --桐生君★[讨论] 2021年11月13日 (六) 17:03 (UTC)

WP:没坏别修--Billytanghh 讨论 欢迎参与亚洲月 2021年11月13日 (六) 18:16 (UTC)
那只是个论述，而WP:BOLD这还是指引，本人认为，如果更名为系统操作员，让系统操作员有所谓的操作次数要求是不合理的，能有一个直观上的感觉。桐生君★[讨论] 2021年11月14日 (日) 01:38 (UTC)
“管理员”是坏了？还是“修复”后就好了？既然不是坏了，要修？——Sakamotosan路过围观杯弓蛇影 | 避免做作，免敬 2021年11月14日 (日) 03:20 (UTC)
这个词“修复”后就好了，因为社会大众认知中的“管理员”是“站长”，而不是一名具有权限的用户，“修复”后，所有人都能直观的明白，“系统操作员”和“模板编辑员”是一样的，因此要求“系统操作员”这一权限有站务要求可能不合理，因为“模板编辑员”也没有站务要求。桐生君★[讨论] 2021年11月14日 (日) 03:42 (UTC)
感觉这是一种词义正义的问题，而不是实务性的问题。在这里管理员的职责，就有类似“站长”的性质，包括大部分前台性调控工作（可以编辑界面信息、脚本、CSS等）、日常维护（从功能性的，如删除、保护等，到业务性的，例如从执行删除的来源是速删、讨论删除等）、社群管理（封锁的执行本身就是根据社群已有的规则或共识等），虽然这个前台性的“站长”不拥有站点（站点是属于基金会的）这一点与正式的站长有所差异。但不足以认为是问题。更严格来说“系统操作员”我认为更像是后台性的基金会硬件或系统的维护人员。——Sakamotosan路过围观杯弓蛇影 | 避免做作，免敬 2021年11月14日 (日) 08:21 (UTC)
其实也可以叫“管理操作员”，不过没有共识的话，就结案吧。桐生君★[讨论] 2021年11月14日 (日) 08:48 (UTC)
“事务员”如何？Sanmosa Ázijský Mesiac/Asiatischer Monat 2021年11月14日 (日) 13:46 (UTC)
Wikipedia:管理员中提及的英文名称有“Admin（或en的Administrator）”和“SysOp”，从早期翻译来看已经选定了前者的翻译。这已经是惯例性的用词，不是实务性的损坏（例如：例如导致系统异常、或业务问题），无法认为这是“坏了”的问题。——Sakamotosan路过围观杯弓蛇影 | 避免做作，免敬 2021年11月15日 (一) 01:03 (UTC)
要问，我会说否；不问，一样说否。 2021年11月18日 (四) 16:42 (UTC)
  • (＋)支持更名。早就想提这个了。在本人看来某些人自认选上来便可“管理”他人，其职务名称所引起他们莫名的自傲感是其中原因，进而忘了自己的本质与其他用户仅是能处理站务与否的问题。建议更名为“系统操作员”或PerSanmosa更名为事务员，其“管理权限”更为“站务处理权限”。——WMLO（留言） 2021年11月25日 (四) 21:46 (UTC)

题外话：关于巡查员

( π )题外话：甚至本人认为“巡查员”一词也是需要“修复”的，站外人士，或新来的人很可能以为巡查员是某种“维基百科官员”，应改名“巡视员”。桐生君★[讨论] 2021年11月14日 (日) 03:48 (UTC)
我觉得两个问题一点关系都没有。--ghren🐦吱吱吱...🔊 2021年11月14日 (日) 05:33 (UTC)
“巡查”的“查”包括发现问题后的行动，而“巡视”的“视”只有看，一般认为不包括行动。——Sakamotosan路过围观杯弓蛇影 | 避免做作，免敬 2021年11月14日 (日) 08:25 (UTC)
巡查给人一种“是维基媒体基金会的官方人员，来到中文维基百科视察监督”的感觉。桐生君★[讨论] 2021年11月14日 (日) 08:46 (UTC)
管理员等也不是官方人员啊。或者只是你想多罢了。——Sakamotosan路过围观杯弓蛇影 | 避免做作，免敬 2021年11月14日 (日) 08:52 (UTC)
管理员的作用是管理网站，作为一般市民，当然会认为管理员是官方的人（或有官方支持 / 代表官方意见）。包括巡查员作为与新用户的第一交手对象，也会被认为近似于管理员。事实是你不可能让所有人都明白维基百科的运作方式，不是谁想多，而是你想太少。->>Vocal&Guitar->>留言 2021年11月14日 (日) 13:05 (UTC)
解释清楚，而不是迁就蠢货。——Sakamotosan路过围观杯弓蛇影 | 避免做作，免敬 2021年11月16日 (二) 00:41 (UTC)
要考虑巡查豁免者的名称应该如何更改。Sanmosa Ázijský Mesiac/Asiatischer Monat 2021年11月14日 (日) 13:46 (UTC)
“免审阅者”、“免校阅者”如何。桐生君★[讨论] 2021年11月14日 (日) 15:36 (UTC)
随着巡查员的更名而更名，例如如果巡查员更名为“巡视员”，那么巡查豁免者就可以更名为“巡视豁免者”。--落花有意12138 论 回复请ping我 2021年11月22日 (一) 13:34 (UTC)
本站点从来没有“官方”的组织，除了涉及后台硬件管理、软件维护，还有涉及业务上的特殊情况是存在属于正式的“官方”——基金会，这也是一直对所有不明站点人员结构的人们都这样解释。所以只是个别的语文理解问题，我不认为这是问题，或者是那些有问题的理解才是问题。——Sakamotosan路过围观杯弓蛇影 | 避免做作，免敬 2021年11月15日 (一) 01:07 (UTC)

巡查员改“校阅者”、“检阅者”、“审阅者”、“审稿人”如何？意思是reviewer而不是patrol。桐生君★[讨论] 2021年11月14日 (日) 15:36 (UTC)

Wikipedia:管理员

最新留言：在2年前发布8条留言7人参与讨论

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

当中提及： 

管理員不應該在一項事宜中使用普通用戶和管理員的雙重身份，而應該要麼使用普通用戶的身份，要麼使用管理員的身份，儘管用戶是同一個人。在以下場合的具體限制有：

保護：管理員不應該保護/解除保護他們牽扯進去的頁面，而應該像普通用戶一樣求助於其他管理員，這些頁面不包括諸如主頁等的常見保護頁面；

封禁：管理員不得僅因某用戶反對自己而封禁這個用戶；

刪除：管理員不得刪除自己提議刪除或者投票刪除的頁面；

在以上情況下，管理員應該以普通用戶的身份要求其他管理員協助。

但我觉得管理员应该可以删除自己提议的O1、G10快速删除，因为这样通常不会对维基百科造成太大影响，也公平。
请各位在下面讨论一下。Choi Chin Long 2022年2月22日 (二) 10:04 (UTC)

请允许我直接引用两条五大支柱：在不引起争议时，任何改善（或保护）维基百科的行为都没有太大问题--Kegns（留言） 2022年2月22日 (二) 13:42 (UTC)
与文明方针有何联系？ Stang★ 2022年2月22日 (二) 13:48 (UTC)
正常流程是用户先提删，后管理员进行删除，而第一步为普通用户操作，第二步为管理操作，所以一位管理员不能单独完成这两个步骤。--东风（留言） 2022年2月23日 (三) 03:39 (UTC)
其实O1目前管理都是自己删掉的，用bot删还是人手删有什么分别？--Ghren🐦🕛 2022年2月23日 (三) 04:19 (UTC)

我们要如何看到维基百科的各级管理员啊？

最新留言：在2年前发布4条留言3人参与讨论

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

应该有一个列表把各级管理员啥的罗列出来吧？ --AndyPKU（留言） 2022年5月28日 (六) 02:22 (UTC)

管理员名单、行政员名单、回退员名单、巡查员名单。另外可以在特殊:参数设置的小工具开启“看哪个管理人员在线”及“在编辑记录中标示用户权限”功能。桐生ここ★[讨论] 2022年5月28日 (六) 02:34 (UTC)
非常感谢！--AndyPKU（留言） 2022年5月28日 (六) 13:49 (UTC)

提议新设wikipedia-zh-admin@lists.wikimedia.org

最新留言：在2年前发布25条留言12人参与讨论

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

已经有人建立，可以关闭讨论串了。--Z7504非常建议必要时多关注评选（留言） 2022年6月16日 (四) 06:05 (UTC)
下列讨论已经关闭，请勿修改。如有任何意见，请至合适的讨论页进行，并不要再次编辑本讨论。
于Phabricator查看
编号T310465的任务
已解决
借近期讨论过滤器问题的契机，讨论一下是否寻求管理员新设一电邮列表。探讨此问题的动因是：
  1. 一方面，滥用过滤器匹配规则“事前泄密”的情况确实存在，缩小匹配规则查阅权限的持有范围，在此情况下会成为一个很可能的选项；
  2. 另一方面，资深用户在过滤器有关站务（比如，过滤器错误报告）上的确发挥了很大作用，尽管权限持有范围可能出现限缩，但是对于公开匹配规则而无碍的过滤器，原则上也应尽可能公开；
  3. 同时，在编写防滥用过滤器规则(ADM2)的过程中，感觉一小部分过滤器的公开性是可以检讨的；
  4. 但是相关讨论可能会涉及匹配规则细节，所以私有的讨论或许更为适宜。
新设一电邮列表的主要理由有下：
  1. 包括上述过滤器问题讨论在内的很多站务问题，需要一个能包纳所有管理员的平台开展讨论。
  2. 现行的unblock-zh lists.wikimedia.org尽管包纳所有管理员，但每天都会接收海量申请IP豁免的邮件，实际上已经不适合管理员用于讨论站务。
以上。--Kirk # 2022年6月1日 (三) 05:56 (UTC)
归纳了一下本地或常与本地有关的邮件列表：
  • 公共列表
  • 私有列表
    • wikipedia-zh-afc-reviewer lists.wikimedia.org（似可停用）
    • unblock-zh lists.wikimedia.org：中文维基百科封禁申诉
    • otrs-zh lists.wikimedia.org：中文志愿回复团队
    • wikizh-bureaucrats lists.wikimedia.org：中文维基百科行政员
    • oversight-zh-wp wikipedia.org：中文维基百科监督员
以及Wikipedia:邮件列表或可更新。--Kirk # 2022年6月1日 (三) 06:25 (UTC)
  • (＋)支持设立管理员邮件列表。另外上面那几个邮件位址格式实在参差不齐，还有一些名称过时了，日后有没有办法处理一下（ —— Eric Liu 創造は生命（留言・留名・学生会） 2022年6月1日 (三) 08:09 (UTC)
    （参差问题虽然是题外话）同表示不舒服，但估计会维持现状。目前新设地址的基本上按照“<计划全称>-<语言代号>-<功能名称> lists.wikimedia.org”的格式。监督员邮箱地址命名应该是从英文维基百科oversight-en类比迁移，行政员邮箱地址命名则迁移自公共主列表wikizh-l，估计是当时没有制定统一的规则所致。--Kirk # 2022年6月1日 (三) 11:14 (UTC)
    意思说其实日后可以考虑 unblock-zh -> wikipedia-zh-unblock, wikizh-bureaucrats -> wikipedia-zh-bureaucrats, oversight-zh-wp -> wikipedia-zh-oversight ？--SunAfterRain 2022年6月8日 (三) 01:41 (UTC)
    “wikipedia-zh-oversight”wikipedia-zh-suppress* —— Eric Liu 創造は生命（留言・留名・学生会） 2022年6月8日 (三) 09:09 (UTC)
不反对设立，但是对它能起多少作用不乐观，很可能没几个人用甚至没几个人订阅。--Tiger（留言） 2022年6月1日 (三) 15:35 (UTC)
wikizh-l都没人用....--百無一用是書生 (☎) 2022年6月2日 (四) 03:57 (UTC)
如果是可以公开讨论的内容，也就寻求充分利用一下wikizh-l了。--Kirk # 2022年6月2日 (四) 08:50 (UTC)
多一个正式管道总是好的。此外，给管理员开一个专用Telegram群组的效益或许会高一些？根据统计，至少约有四分之一的管理员持有Telegram帐号。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年6月2日 (四) 05:11 (UTC)
能提高效率，但TG的多个方面对历史留档不太友好（销号/删除历史消息/账号关联性）。--YFdyh000（留言） 2022年6月2日 (四) 06:07 (UTC)
从普遍的工作环境来看，我觉得使用邮件的存档性、用户关联性比面向即时通信的tg更好。——Sakamotosan路过围观 | 避免做作，免敬 2022年6月2日 (四) 08:05 (UTC)
我想Telegram主要应该是作为管理员之间即时沟通的管道，至于任何正式决策都要在站内解决，或者有日志存档等。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年6月2日 (四) 09:58 (UTC)
TG作为即时便捷的辅助手段尚可。邮箱既是讨论渠道，更是公示和存档的渠道。--Kirk # 2022年6月2日 (四) 08:49 (UTC)
若无进一步意见，建议今日起开始公示。--Kirk # 2022年6月9日 (四) 04:26 (UTC)
这个要创建应该也不难，但是真正想使用的人有多少？公不公示估计也没差，没意见的话可能都可以直接创建就好了。--Z7504非常建议必要时多关注评选（留言） 2022年6月9日 (四) 10:32 (UTC)
@KirkLU、Ericliu1912、和平奮鬥救地球：讲那么多看起来没有实质意义的讨论，所以你们有没有人要建立了？反正没有人反对嘛。管理员，阿不是管理员的当然无感阿，不是管理员的讨论这个意义在哪？--Z7504非常建议必要时多关注评选（留言） 2022年6月13日 (一) 07:15 (UTC)

根据phab:T310465，目前私有列表wikipedia-zh-admin lists.wikimedia.org 已被建立。虽然目前存档功能暂时被关闭，但有需要的话可随时重新启用。-Peacearth（留言） 2022年6月13日 (一) 13:28 (UTC)

本讨论已经关闭，请勿修改。如有任何意见，请至合适的讨论页进行，并不要再次编辑本讨论。

提议：是否应该提高管理员和行政员任内的要求？

最新留言：在2年前发布34条留言16人参与讨论

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

除了提案人和HK5201314外未见其他支持者，雪球关闭--SunAfterRain 2022年10月11日 (二) 03:13 (UTC)
下列讨论已经关闭，请勿修改。如有任何意见，请至合适的讨论页进行，并不要再次编辑本讨论。

绝大多数管理员和行政员凭借撰写优秀的条目内容登上高位，但是这些人的大多数在上任后鲜少有优秀的条目问世，只是沉迷于管理，难免会形成“官僚阶层”，使普通用户产生管理员和行政员是维基百科“站长”的错觉。

不做过多赘述，我认为管理员应该每个月为维基百科贡献一个优良条目，行政员应该每个月为维基百科贡献一个典范条目。如果既是管理员又是行政员，每个月应该为维基百科贡献一个典范条目和一个优良条目。如果行政员或者管理员达不到要求，第二个月降为临时，第三个月除权。

我认为这是消除管理员制度现有弊端的最好方法。Assifbus（留言） 2022年10月9日 (日) 13:39 (UTC)

您确定“凭借撰写优秀的条目内容登上高位”？管理人员本就非内容创作为先。创作方面接近的是WP:维基荣誉。WP:CHOICE。--YFdyh000（留言） 2022年10月9日 (日) 13:47 (UTC)
管理人员每日待处理的工作还不够多吗、增加这样的制度检视管理人员似有不妥、每日待处理事务有多少，光是封禁和保护就有得忙了，就算想写什么也要挤得出时间，每个人都是志愿者，管理人员更是志愿担更多的维护责任的人，用“沉迷管理”来描述这个真的不太好吧。--Mafalda4144（留言） 2022年10月9日 (日) 14:01 (UTC)
什么破提议。管理员是拿扫帚的清洁工。而编辑条目的是工作人员。清洁工的权利就是能进入很多工作人员进不去的地方。w:WP:NOBIGDEAL--0xDeadbeef（留言） 2022年10月9日 (日) 14:05 (UTC)
++ —— Eric Liu 創造は生命（留言・留名・学生会） 2022年10月11日 (二) 00:53 (UTC)
相比之下，萌娘百科的管理员要求还真是德政啊。现在贵站有谁可以一个月写一条GA啊。--Ghren🐦🕚 2022年10月10日 (一) 03:34 (UTC)
(＋)强烈支持：
作为一个编辑者，当然是希望以管理员级数为目标，如果管理员不提供参考予所谓破坏者，又对破坏者施加punishment，如何服众？
(＆)建议管理员、行政员、回退员、巡查员每一季挑选部分劣质条目并加以编辑。然后提交编辑比例至少达40%的5个GA或通过1个共议制FA，否则很难称得上这个职位。--唔好阻住我爱国（留言） 2022年10月10日 (一) 10:51 (UTC)
登上首页的条目都是可供参考的范例，可每天新增的条目有多少以此为目标，占数据空间的有多少？就算真的这么要求管理群好了，这样能减少我行我素的使用者无视规则建立条目吗？有多少使用者知道什么是典范或优良？一个占数据空间的条目爽快建立，要存还废要看是不是侵权还要想办法帮他改善，觉得该要求管理群的各位平常有自愿帮忙协助改善条目？这是所有维基人都可以做的事，为什么只要求管理群要立标竿？破坏者比如LTA:KORTV根本才没有管什么目标，想破坏就破坏。--Mafalda4144（留言） 2022年10月10日 (一) 11:07 (UTC)
管理员应该做更多，如果他没有能力做更多的事情，理应辞职并当回普通编辑这一个。--唔好阻住我爱国（留言） 2022年10月10日 (一) 11:15 (UTC)
这个所谓的“破提案”如果通过，动的是所有管理阶层的蛋糕，但是能让管理员和行政员的定位更明显。管理员和行政员理应是所有用户写条目的“标杆”。
(：)回应如果是这样的话，那管理员选举也得改改。应该看候选人创作多少优良条目和典范条目，而不是看有多少WP:维基荣誉。
WP:维基荣誉能“刷”出来，而优良条目和典范条目需要经过普通编辑者的筛选。Assifbus（留言） 2022年10月9日 (日) 13:53 (UTC)
为什么您认为管理员、行政员要“条目写的好”，也有技术型管理员啊。只要对条目撰写等规则的理解到位，不写任何条目也行的。巡查员、回退员等同上，编写条目只是证明能力的途径，并不是强加在这些身份上的必然任务。--YFdyh000（留言） 2022年10月9日 (日) 13:59 (UTC)
所以我说的是绝大多数。技术型管理员除外。Assifbus（留言） 2022年10月9日 (日) 23:02 (UTC)
如果混合型怎么办？而且本来如果按照分工的话，就只有技术型和行政型的，一个臭写条目的，做管理员就是边写条目边封人吗？ 从立论就是有问题的，管理员等的当选与编写条目数质并没有直接的关联。——Sakamotosan路过围观 | 避免做作，免敬 2022年10月10日 (一) 02:55 (UTC)
冒昧再说个，打算用这样的标准检视管理群之前，是否自己达到了这样的标准呢？您建立的每个条目方方面面都符合优良以及典范吗？或是退一步来说有符合到维基百科最基本的标准呢？—Mafalda4144（留言） 2022年10月9日 (日) 14:13 (UTC)
对管理人员的要求理应要比其他用户高。我承认自己有很多不足，所以也一直没申请管理员。如果管理员申请时和在任时不撰写优秀的条目内容，那么我这种写条目的“菜鸟”也可以当管理员，在处理站务方面会比一些人处理的更好。（玩笑话）@Mafalda4144Assifbus（留言） 2022年10月9日 (日) 22:53 (UTC)
真的当管理员们申请头衔摆放著好看的啊，写个条目要花多少心力，处理站务差不多就死那么多脑细胞了可能还更多，近期变更随便看都会遇见破坏，您有没有去逛过呢？用掉自己比金钱还珍贵的时间、自愿出来担这些比毛还毛的毛躁事、都不用管才可以专心写条目好不好是不是？顺带一提若您想申请管理员也是可以的就跟著程序走，不过大家比较想要知道的，应该会是您在站务上打算协助哪方面的事哟，您可以现在开始去看“管理员忙什么”。--Mafalda4144（留言） 2022年10月10日 (一) 01:09 (UTC)
(－)反对。 ——魔琴 [ 留言 贡献 ] 2022年10月10日 (一) 02:09 (UTC)
根本思想就已经不正确了。管理员与行政员不是什么“高位”，因为他们担负的义务远高于享有的权利。另外，WP:维基荣誉能“刷”出来......吗？阁下不妨著手先替自己“刷”看看，看刷不刷得出来，如果刷得出来，建议阁下可以更上一层楼，争取“争上高位”，享受种种“特权”，在下绝不会羡慕或忌妒您的。-游蛇脱壳/克劳棣 2022年10月10日 (一) 06:26 (UTC)
反驳一下。明明是享有的权利高于担负的义务。如果管理员人人尽职尽责的话，我今天也不会提出这个议案了。很明显一些人只充分的享受权利却没有尽多少义务。Assifbus（留言） 2022年10月10日 (一) 09:52 (UTC)
我的提议值得通过，这会让维基百科焕然一新。Assifbus（留言） 2022年10月10日 (一) 23:52 (UTC)
本站之管理员权限，是任何获社群信任者都有资格获得，而不是要以什么天大地大的苦劳来换取的，与所谓“法官”之流更是无从相比；不管会不会写条目，能够获得社群信任，那么就有资格能获得管理员权限。强迫管理员“作业绩”这种事——无论是写条目还是处理站务——纯属不理解其制度宗旨的无稽之谈。换个角度说，如果今天本站有足够的管理员，还有必要硬是去压榨剩馀之有限人力么？终归是社群“信任”不够多人的缘故。请不要舍本逐末，把那些愿意接下社群信任“扫帚”的“清洁工”都赶跑了。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年10月11日 (二) 00:53 (UTC)
另外说一句，写条目越多，越容易卷入或引发编辑冲突，也就越难成为管理员（毕竟要经过社群投票），所以近年能“凭借撰写优秀的条目内容登上高位”者实已屈指可数矣。还有一个矛盾是，越常参与社群讨论（例如现在这则话题），与他人意见相左、乃至于争吵之频率就越高，这同样也会在管理员申请时成为明显的阻碍。例如现在这则话题，我讲了上面那一席话，岂不是会惹到不少人？这样我即使想为、而且能够为社群做事，也难成功了。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年10月11日 (二) 01:02 (UTC)
同意Eric阁下的看法，认为相应自治体代权机制之改进并不能以单一衡常编辑参与度等机械化数据为考虑依据，综合来说相应问题在理想情况下适宜采用分权和复合设计而分摊相应站务之自治，但如Eric阁下所言之矛盾所反映之侧面、相应事务亦可能于局限内。--约克客（留言） 2022年10月11日 (二) 02:55 (UTC)
要这么搞可以啊咱不反对，那谁给管理员行政员付钱，一个月10万USD，年终奖金3个月，写出一条FA1万奖金GA5千奖金，付的下去再来提这些。--~~Sid~~ 2022年10月11日 (二) 02:43 (UTC)
(－)倾向反对。管理员的本质也仅是普通的编者，只是拥有更多的权限以便维护耳。要求提高显然很荒谬。--  （☎|♼） 2022年10月11日 (二) 03:00 (UTC)
本讨论已经关闭，请勿修改。如有任何意见，请至合适的讨论页进行，并不要再次编辑本讨论。

Jimmy200001 骚扰多篇文章

最新留言：在2年前发布1条留言1人参与讨论

Jimmy200001 

騷擾多篇文章--TVB(HONGKONG01)（留言） 2022年12月25日 (日) 15:41 (UTC)

整理管理员用户组权限

最新留言：在1年前发布76条留言9人参与讨论

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

下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。结论综叙如下：
关闭特定方案，以下方小节聚焦问题核心为先。--路西法人 2023年7月20日 (四) 07:02 (UTC)

为厘清管理员用户组的权限的作用，我主张自管理员用户组移除以下没有管理作用、纯粹重复其他用户组的基础编辑权限。移除这些权限不会影响管理员的任何操作，因他们属于其他用户组而仍然保留了这些权限：

一、所有自动确认用户或更低权限者均持此权，而这些权限无法移除，管理员用户组持此权实属冗馀重复：
  • 上传文件 (upload)
  • 不受基于IP的速率限制 (autoconfirmed)
  • 执行触发验证码的操作时无需验证 (skipcaptcha)
  • 新建用户账户 (createaccount)
  • 创建短链接 (urlshortener-create-url)
  • 将结构式讨论话题标记为已解决 (flow-lock)
  • 查看当前转码活动的信息 (transcode-status)
  • 查看详细过滤器日志 (abusefilter-log-detail)
  • 移动分类页面 (move-categorypages)
  • 移动根用户页面 (move-rootuserpages)
  • 移动页面 (move)
  • 编辑保护级别为“仅允许自动确认用户”的页面 (editsemiprotected)
  • 编辑其他使用者的结构式讨论话题的标题 (flow-edit-title)
  • 编辑其它用户的结构式讨论帖子 (flow-edit-post)
  • 覆盖现存文件 (reupload)
  • 重置已失败或已转码的视频将其再次加入到作业队列中 (transcode-reset)
二、修正设立XCON前的管理员不能自动提升为延伸确认用户的问题（即令所有管理员都是XCON），后可直接继承自延伸确认用户组而非管理员用户组的权限：
  • 编辑受延伸确认保护的页面 (extendedconfirmed)
  • 移动文件 (movefile)
三、如可，将自动巡查从管理员分拆，因其不涉及主动的管理行为，而管理员又没有“会写条目”的要求（2023年7月20日 (四) 11:23 (UTC)增订）
  • 使自己的编辑自动标记为已巡查 (autopatrol)

目标为使管理员用户组与其他进阶权限看齐，不持有与其他基础用户组重复的权限，便于往后判定何为“使用管理权限”；例如与如何判定其他用户组（如巡查员）是否有“使用权限”（WP:RFDR惯常的讨论重点）看齐。简单来说，就是剩下的权限如回退、保护、封锁等，用了就视为“作为管理员身份的行动”，依管理行动的相关程序申诉，而非视作“作为一般用户身份的编辑”处理。上面要移除的都不是用作管理的，不需要由管理员额外重复持有。--路西法人 2023年7月18日 (二) 17:16 (UTC)

我(－)反对这提案，滥用上述权限应当同样视为滥用管理权限，否则管理人员滥用权限的情况无法得到正视，因为管理人员不当使用上述权限所进行的操作相对于一般用户更难处理（比如移动页面）。Sanmosa In vain 2023年7月19日 (三) 00:22 (UTC)
管理员滥用权限包括但不等于也不限于滥用管理权限，也包括滥用一般编辑权限。管理员滥用管理权限毫无疑问是立即紧急除权，而滥用一般编辑权限则可与一般用户一样以封锁处理，（然后再除权），完全不冲突。依照阁下的论述，管理员不当使用“编辑页面 (edit)”权限（并不附于管理员用户组上）就跟“移动页面 (move)”有分别了？两者同样是“暴走的管理员可能会滥用的权限”，有何不同？
以最近一次Ws227的除权作为例子，最终先以不限期封锁阻止滥用移动权（及移动不带重定向权）再除权，与我的观点完全一致。
这里所分辨“管理权限”跟“一般编辑权限”的差异在于影响应作为管理行动申诉还是作为一般不当行为提报。若管理员滥用以上摘除的基础权限，与庶民同罪一般用户的处理方式应当相同，应当封锁、禁制处理，以此预防进一步扰乱行为；上面没有摘除的“管理权限”（如回退、保护、封锁等）则应在管理员布告板（主页）申诉，有滥用则是在客栈讨论除权。--路西法人 2023年7月19日 (三) 01:20 (UTC) ／ 修订于2023年7月19日 (三) 10:51 (UTC)
您目前的观点是把“管理员滥用权限”和“滥用管理权限”混为一谈。我这里的目的是分辨清楚哪些是“用作管理的权限”和“一般编辑权限”，然后您的回应立马就展现了把“管理权限”跟“编辑权限”混乱了的情况，更加佐证我分拆权限的需要。分拆了不会使管理员滥用一般编辑权限没有后果，只是将后果与其他用户同化（提报AIV、AN3、ANM）并被封锁或禁制。
最佳的类比例子应如此：回退员滥用“编辑页面 (edit)”权限，您也不能直接提报至WP:RFDR，而是该报AIV、AN3，然后再讨论用户是否适合继续持有该权；只有滥用“快速回退最后一位用户对某一页面的编辑 (rollback)”或“移动页面时不在原页面创建重定向 (suppressredirect)”时才会提报WP:RFDR。
补充上面：提报一般的不当编辑行为是AIV、AN3、ANM等，AN的子版面是“提报给（不涉事）管理员处理的案子”；AN本身则是“讨论管理员操作的地方”，作用不同。--路西法人 2023年7月19日 (三) 01:34 (UTC)
@LuciferianThomas：“管理员滥用管理权限毫无疑问是立即紧急除权”现在的情况并非如此，紧急除权的要求是滥用管理权限且对维基百科造成巨大损害，其他情况就算真滥用了管理人员专有权限也是走解任投票，另参上方讨论（该讨论串中，有个别管理员甚至认为就算管理人员滥用管理权限且对维基百科造成巨大损害，也有不需要立即紧急除权的情况，虽然我自己肯定不认同就是了）。我个人的看法是既然管理员用户组持有相关权限，那相关权限就是管理权限。Sanmosa In vain 2023年7月19日 (三) 10:19 (UTC)
所以紧急除权跟一般除权结论都是除权，不影响我论述啊。“个人的看法是既然管理员用户组持有相关权限，那相关权限就是管理权限”，然而现在社群有成员（昨天TG讨论）连回退都不承认是管理权限，您这过度延伸更不可能被他们接受。“管理员用户组持有相关权限”但“该权限并非先由管理员用户组赋予”，那么该权限就不是管理权限，而是一般编辑权限。--路西法人 2023年7月19日 (三) 10:28 (UTC)
“紧急除权跟一般除权结论都是除权”，但从过往经验来看能真正除权的比率很小，论述不能流于理论。Telegram的讨论不能当成社群共识，管理员用户组持有的权限列表则是固定的，用管理员用户组持有的权限列表来判定管理权限是甚么显然合理得多。Sanmosa In vain 2023年7月19日 (三) 10:40 (UTC)
您要不要看看您的意见与下方Cwek的意见有多冲突，您们二人的论述已经完全反驳对方的论述，是方便我把您们两个自相矛盾的异议当成您们互相驳斥了吗（）。Telegram的讨论不能当成社群共识，这是理所当然，问题是连那边都未曾达成共识啊，不然我拔上来讨论干嘛。管理员用户组持有的权限列表则是固定的：否，提案可以修改，那么就不是固定的；且社群未曾认定那些是管理权限，已经过社群共识认定为管理权限的只有管理员方针所列之权限。我认同用管理员用户组持有的权限列表来判定管理权限是甚么显然合理得多，但现今持有权限列表与方针所列“管理权限”相悖，所以才提案将不属于社群认定的管理权限自管理员用户组移除。--路西法人 2023年7月19日 (三) 10:48 (UTC)
我有看过，但我为甚么必须要看，反正我跟他都是来反对提案的，具体反对理由的差异不是我需要关心的事情。我说“Telegram的讨论不能当成社群共识”这话的意思是Telegram群组里的东西并不是这里客栈讨论应该关心的范畴，任何Telegram群组里的讨论都不能纳入客栈讨论共识的考量之内。既然你说到“管理员用户组持有的权限列表”是“可以修改”的，那容我先问一个问题：谁在技术上有具体权限修改？Sanmosa In vain 2023年7月19日 (三) 10:59 (UTC)
“管理员用户组持有的权限列表”是“可以在取得社群共识后提报phab:修改”啊。不存在社群无法修改管理员权限的部分，phab（正常来说）除了技术原因外也不能以技术问题以外的原因拒绝社群共识所得，自然是“可以修改”的。我有看过，但我为甚么必须要看，反正我跟他都是来反对提案的。很简单，既然两位的异议是互相矛盾的，那我可以拿他的论述来反驳你的异议，再拿你的论述反驳他的异议，自然两个都是WP:共识方针所视为已经反驳的异议啊。两个完全矛盾的异议就代表两个都是有问题的异议论述。--路西法人 2023年7月19日 (三) 11:06 (UTC)
我问的是“谁在技术上有具体权限修改”，不过你既然都已经说了是phab那边的人，那我也不执著于此太多了，但我们此前应该有一段很长的时间没有报过phab那边修改管理员用户组持有的权限了，那权限列表相对而言比起管理员方针页面稳定得多，因此权限列表的可参考性更大。“phab（正常来说）除了技术原因外也不能以技术问题以外的原因拒绝社群共识所得”（这句是不是有语病？），那这里牵涉到两个问题：（1）现在管理员用户组持有的权限的设定有没有背后的技术原因？这点我们完全不知道，假设是真有先前我们并不知道的技术原因的话，那就算这里的用户100%同意修改，这不也是徒劳吗？（2）你提到“正常来说”，但你是否能够确定你理解上的“正常来说”跟phab那边理解的“正常来说”一致？phab会不会认为现在的情况不属于“正常来说”的情形？不管如何，我觉得你应该先确认一下phab一般会不会处理这种移除“重复权限”的操作。Sanmosa In vain 2023年7月19日 (三) 11:22 (UTC)
但我们此前应该有一段很长的时间没有报过phab那边修改管理员用户组持有的权限了：否，设立WP:XCON的时候就（被动）新增过管理员用户组的“编辑延伸确认保护页面”权限。我稍后会去问问技术上是否允许。--路西法人 2023年7月19日 (三) 12:01 (UTC)
不理解归类“管理权限”的意义。管理员被指创建质量不佳页面，受到巡查豁免，也是滥用“管理权限”、可直接提报解任讨论吗。拒绝沟通和共识才是滥用，否则只是编辑争议，涉及权限而便利但一般用户也可做到同等效果的事情，应该归类为一般操作。用到权限可能是无意识或者节省时间，而节省时间是因为社群对该用户组有更高的信任度而授予，仅凭争议涉便利权限来讨论剥夺用户组的实质权限是很奇怪的——仿佛用TW做了不妥回退，于是列入TW工具黑名单（假设存在）。--YFdyh000（留言） 2023年7月19日 (三) 11:56 (UTC)
管理员持有巡查豁免这一问题跟巡查员是否应该持有巡查豁免一样，如果社群在#提议重组现有的用户权限组的讨论中认定巡查员不应该巡查自己条目的话，那同样应该剥夺管理员的巡查豁免权限，成为管理员的要求中也不存在获得巡查豁免的要求，没写过几个条目的也是可以成为管理员的（尤为站务、反破坏专长者），所以我不会拿巡查豁免来说。此案是回应阁下在TG群认为“回退不应视作管理行动”的观点，我不否认存在管理员使用回退功能（带编辑摘要）参与编辑争议的可能，但“对回退操作有异议”是否如阁下所认为“必然归类一般操作视作编辑争议”并不认同。若管理员已判定对方不是对内容争议而是明显的破坏、侵权或扰乱回退，并以封锁、保护、禁制等管理行动接续，那回退操作跟封锁保护禁制等分开申诉显然不合理，这是我的论点。--路西法人 2023年7月19日 (三) 12:13 (UTC)
不看好剥夺管理员的巡查豁免。至少目前，巡查豁免是管理员用户组的权限吧，所以按上文所说，创建页面也变成了动用管理权限。我的观点，附理由的回退功能应视作非管理行为，尤其是摘要认真对应回退内容时。无理由的回退，除非明显的滥用或争议或不回应，否则也可能出现对“明显破坏”理解不同产生的无理由反破坏，而使用回退与使用撤销、TW回退通常并无本质区别，操作更快是权限所给但绝非权限主体。除非摘要附上或另发警告，否则不认为回退是任何管理行动的前奏。--YFdyh000（留言） 2023年7月19日 (三) 12:36 (UTC)
有点矫枉过正？例如其他项目区有没将高阶用户组中清理在低阶用户组中已经包含的重复权限？——Sakamotosan路过围观 | 避免做作，免敬 2023年7月19日 (三) 01:04 (UTC)
别人没做不代表我们不能做。既然是重复的，为何不摘除？既然有助分辨哪些是进阶的管理权限（回退、巡查、封锁、保护、过滤器编辑权）和一般用户都有的普通权限（编辑、移动、上传），为何就是矫枉过正？如何修到“超过了适切程度”？--路西法人 2023年7月19日 (三) 01:23 (UTC)
Wikipedia:管理员指定了哪些是管理员的权责，不认为用户组的权限配置与管理员的角色权责直接关联来定论。用户组配置权限的重复不影响功能的使用，我不认为坏。——Sakamotosan路过围观 | 避免做作，免敬 2023年7月19日 (三) 03:10 (UTC)
既然方针指明管理员只有哪些额外权责，那为何用户组需要重复管理员已经有的权限？编辑延伸确认保护页面不是管理员权责，为何该权限附于管理员用户组而不是附于延伸确认用户然后管理员能如一般用户自动获得延伸确认用户组？移动权在“用户”组，该权限为何需要重复附于管理员用户组？那回退员持有移动不带重定向权，又是否需要重复提供move权限确保他能移动条目？不是嘛。整个逻辑上既然不合理，技术上没坏，意义上坏了。--路西法人 2023年7月19日 (三) 04:39 (UTC)
可能技术原因，因为管理员用户组最早并肯定存在，而其他用户组和自动用户组可能不曾存在，体验权限首先给管理员而非新增用户组，以及极特殊情况下可能（临时）管理员用户不具自动确认等用户组。建议您先咨询技术人员，看“清理权限”是否可行和被接受，至少英文维基没这么做。如果技术人员不愿执行此操作，讨论共识决定哪个页面/哪些权限为“管理权限”就好，别用这个系统信息。--YFdyh000（留言） 2023年7月19日 (三) 11:44 (UTC)
大致意见如此，建议去其他地方（例如mw的讨论区、en的技术版）问一问技术上移除管理员组里面这些权限有没技术上的影响。如果不影响的话，再讨论用户组的权限与职务角色的权力是否关联。——Sakamotosan路过围观 | 避免做作，免敬 2023年7月20日 (四) 00:15 (UTC)
再者，Wikipedia:管理员#权限完全只是基于用户组的权限配置然后选择了特定权限表达是管理权限，更加反映社群本来就有分辨哪些才是管理员额外于一般用户拥有哪些权限。该列表更是不知道多久没人更新了。既然该列表是基于用户组的权限配置，那用户组的权限配置就应该反映这些权限属于管理权限的事实，然后直接引导用户去看用户组权限配置，而不是放一个static的表在那里不更新。--路西法人 2023年7月19日 (三) 04:52 (UTC)
纯属玩笑，也可能是mw初始化设置下的一个后备：一个用户（user）授予了管理员（sysop），因为需要移动页面权限（move）。——Sakamotosan路过围观 | 避免做作，免敬 2023年7月19日 (三) 03:14 (UTC)
很可能是初始遗留，那既不需要则应移除。--路西法人 2023年7月19日 (三) 04:41 (UTC)
如果举Ws227做例子的话，我认为，Ws227的移动操作实际上普通用户也能弄（好像对应页面是属于“目标页只有一个版本且是来源页的重定向是可以覆盖移动的”的情况），应该这个问题扔去AM3、ANM等处理的，但因为其“管理员”的身份，加上装死般不回应，才提升到“是否适格作为管理员”的层面，但注意的是，他这个案例中并没有用到“管理员”用户组或者角色特有的管理性质权限，包括保护页面、封禁用户等，只是其行动的性质不符合作为“管理员”的期望（或者社群认为他这样做根本不符合作为一名管理员），而且相关页面以前他也这样处理过，并且碰上“枪口”了。据上，实质上“管理员”用户组所拥有的权限（无论是面向管理性质或者非管理性质）与作为“管理员”身份的权力并不直接关联，而社群看管理员是否适格是看其行为而不是其使用权限，或者说使用到的权限（无论是来自于管理员用户组还是其他附带的用户组）只是行为的表现，和是否需要清除用户组所谓重复权限这个意见上，我认为是风马牛不相干的，所以我认为这不是坏。——Sakamotosan路过围观 | 避免做作，免敬 2023年7月20日 (四) 00:39 (UTC)
否，Special:Log/delete/Ws227显示存在覆写删除多于一个版本的重定向（需delete权限），且动用了多次undelete权限，显然是滥用管理权限。--路西法人 2023年7月20日 (四) 02:14 (UTC)
Special:Log/delete/Cwek那我呢？覆盖移动是会触发G8删除。至于undelete的话，我再看看。——Sakamotosan路过围观 | 避免做作，免敬 2023年7月20日 (四) 05:52 (UTC)
嗯？那我大概记错覆写重定向的部分了；不过有几则（13276440、13276638）都似乎是一般的删除动作。--路西法人 2023年7月20日 (四) 06:12 (UTC)
历史有点乱，有多笔新春移动后新建重定向页的记录，可能正在尝试修正阴历新年和新春由于移动导致的内容异常关系，之后新春也经过其他管理员还原恢复过。如果从这里看，可能是管理员用户组特定（可能因为有delete权限）导致允许覆盖移动时删除掉多版本重定向页，但并不是因为有delete权限或者有其他不相关的权限而认为是否适格管理员，而是从整个行为——包括这样无意间利用权限的便利来处理页面，而且并没有讨论共识等支持；及之后的不回应（即使上线后做过其他编辑）——认为这不是再适合作为管理员，与用户组是否有那些权限无关，或者盲目地认为将管理员的权责与用户组的权限简单地关联看待。——Sakamotosan路过围观 | 避免做作，免敬 2023年7月20日 (四) 06:30 (UTC)
部分缺失记录（简单来说，我不是管理员，看不到或看不出），但也不一定全是是坏的管理行为，例如纳征、过大礼这一对，纳征其中有相邻记录是2022-02-10~2023-06-22，前面的有大量侵权内容处理，2023-05-25由Wing按照侵权删除过，而Ws227在2023-05-27（纳征应该是还原到2022-02-07 InternetArchiveBot那笔）、2023-06-01（过大礼）做过相关的还原，可能是侵权删除的原始内容修复处理。同上述的，部分相关的行为和用户组存在那些可能重复于其他用户组的权限需要处理有关系，而且我认为是以角色所做行为作为评判标准有关，而不单纯依靠用户组的权限设定。——Sakamotosan路过围观 | 避免做作，免敬 2023年7月20日 (四) 06:09 (UTC)
（元宵节、元宵節 (華人)、元宵节 (华人)）：丢失了太多和由于这次事件可能没完全还原版本，我推测可能是元宵节移动元宵節 (華人)并且删除了元宵节 (华人)（认为可以繁简转换而没必要保留），可能利用了delete权限来处理他认为没必要的页面。——Sakamotosan路过围观 | 避免做作，免敬 2023年7月20日 (四) 06:48 (UTC)
Wikipedia_talk:管理员解任投票/Ws227/第3次：涉无故回退存废讨论的合并结论，同样属于管理操作。--路西法人 2023年7月20日 (四) 06:51 (UTC)
2022-02-25T11:37:40由Wing按照侵权删除（这时页面位置为空？），2023-05-17T06:52:15有人创建了一页新的页面，2023-05-25由Wing按照侵权删除，而Ws227在2023-05-27还原49个版本，大致数了一下，可能是去到“2022-02-07T21:37:09‎ InternetArchiveBot”的版本，之后Wong128hk再还原了3个版本，可能是2022-02-10的三笔版本，然后以侵权内容再隐藏了49+1版本。我猜测Ws227可能没留意到更早的版本有侵权问题，或者到“2022-02-07T21:37:09‎ InternetArchiveBot”的版本并没有问题，之后加了或者重新整页为侵权内容按整页删除，然后Ws227恢复后，在这次混乱中将更早的版本当成侵权内容一并隐藏了。（由于更早的版本是隐藏的，无法比对现在内容， 只能推测如此）——Sakamotosan路过围观 | 避免做作，免敬 2023年7月20日 (四) 07:16 (UTC)
(＋)支持--Firedoge2023（留言） 2023年7月20日 (四) 05:20 (UTC)
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

管理行动与管理员的角色的判定

@Cwek、Sanmosa、YFdyh000：被三位搞到完全乱了。给三位整理一下上面完全矛盾、互相驳斥的论点：

  • 我主张尽量将不涉及“管理”社群的权限自管理员用户组移除，并将由明显属于管理员专有权限（如保护、禁制、封锁）接续的一系列的动作（包括管理及非管理操作，如回退、还原至某个版本、移动等）都视为管理行动的一部分
  • Cwek主张以管理员方针 § 权限一节及以角色所做行为作为[是否视作管理操作(?)]评判标准；
  • YFdyh主张回退无论怎样只要有异议都能视为编辑争议，按我对其留言的理解，其立场是“只要操作是普通人能做（不论什么方式），就当成是普通人”；
  • Sanmosa的主张是现在Special:UserGroupRights#sysop所列所有权限都是管理权限。

我的方案是站在三位的正中央，三位是在三角形的三个角上，您们现在是在不断反驳对方的论点，要不要先理顺您们的异议论点。--路西法人 2023年7月20日 (四) 06:28 (UTC) ／ 2023年7月20日 (四) 07:36 (UTC)修订

但有一点我和另外两位是一致的：必须先确认你提议的操作是否一般上可被phab接受。Sanmosa In vain 2023年7月20日 (四) 06:43 (UTC)
那是另一回事。提案的最终目的是判定什么属于管理员的角色、什么属于管理行动的一部分、什么应该以申诉而非争议形式处理。直接动用户权限只是其中一个直接处理的办法。--路西法人 2023年7月20日 (四) 06:48 (UTC)
但如果不这样做的话，讨论很容易会失焦。现在的情况就是这样。Sanmosa In vain 2023年7月20日 (四) 06:55 (UTC)
看来我不关讨论您是看不懂我的意思。现在重点转移了，重点是“什么应判定为管理行动”，后续如何执行待此讨论有什么结论再说。--路西法人 2023年7月20日 (四) 07:04 (UTC)
我觉得技术上有什么权限根本不重要，重点在于是否有意或无意地以“管理员”的身份操作，否则就应视为与普通编者无异。当然，如果利用只有管理员有的权限，那自然算是管理操作，这也毫无疑问。—— Eric Liu 創造は生命（留言・留名・学生会） 2023年7月20日 (四) 07:13 (UTC)
阁下所提出的判断标准似乎非常主观（有意和无意由谁定夺？似无客观标准），难以作出有效评判；甚至管理员可以按照自己利益更改说法。就以站外讨论时辩论的例子（虽然我没明讲是此例）：管理员Mys_721tx在印度等条目注意到用户IAVZR（无视后续查核发现是傀儡一事，对事不对人）的侵权编辑（使用回退功能并在第一次回退附有“-rc（回退侵权）”的摘要；后续无再重复提供理由），并予以回退及封锁。在此例中，没有客观标准判断是否有意以管理员身份操作。争议点是“是否管理操作影响后续处理如申诉／提报争议等的合理性”：我主张回退本是管理操作，后续更接续明显为管理的封锁操作，回退一事应作为管理行为的一部分申诉；YFdyh认为回退只是加速版的编辑撤销不属于管理操作，应作为一般编辑争议提报处理。--路西法人 2023年7月20日 (四) 07:31 (UTC)
除了按管理员等方针规范，就是社群共识以及常识。只要有完整前后文脉络，以常理即可判断上述回退属于管理操作的一部分，不应当分开来看。你确定YFdyh000君真的认为这种回退也算是单纯编辑争议？—— Eric Liu 創造は生命（留言・留名・学生会） 2023年7月20日 (四) 08:01 (UTC)
我对其2023年7月19日 (三) 12:36 (UTC)的留言的理解正是如此。--路西法人 2023年7月20日 (四) 08:26 (UTC)
“身份说”有用但会有主观判断的成分。回退属于“管理行为”，但非管理员也能做所以不是“管理操作”。如果是处理侵权、存废讨论等提报中的操作之一，可能视作以管理员身份在结案的操作，但编辑条目本身可能仍不是“管理操作”，结案、保护、删除等才是。如果是日常巡查中直接回退，只是在反破坏，其他人难以看出这是“管理员结论”，也没必要看出这点；哪怕是“再加就封禁”编辑摘要或对话页警告，普通人也能做，只是管理员的身份强化了执行力。一般编辑何时算“管理操作”的一环，具体走哪个申诉流程，我真的觉得影响不大，看操作结果是否符合共识和沟通就好了。投诉时将一般编辑归入“该管理员的操作”我没意见，但能投诉“滥用管理权限”我觉得很怪。--YFdyh000（留言） 2023年7月20日 (四) 16:37 (UTC)
提案者是认为“管理员”的权责应该与“管理员”用户组的权限直接关联来规范定义“管理操作”；但我（或者包括其他用户）认为应该以“行为”来判断，权限只是行为下的使用表现（可能是有意无意的，例如覆盖移动多版本重定向可能是delete权限的体现，但他可能认为只是在正常的编辑操作，这是可能是无意的；对于其他用户的话，只能覆盖移动单版本重定向，如果有用户组也有delete权限，他也可能无意间做到类似“管理员”那样的操作），我不认为以为了建立这种强关联为由来清理所谓的与其他用户组重复的权限。——Sakamotosan路过围观 | 避免做作，免敬 2023年7月20日 (四) 07:26 (UTC)
现在已先不讨论是否技术上移除管理员用户组的重复权限；我的立场亦有说明我认同应该以行为判断，然而大家这一部分的标准完全不一致，这才是这个小节的讨论之处。--路西法人 2023年7月20日 (四) 07:33 (UTC)
这样说，我对于管理员权限的认定分为“实权限”与“虚权限”，其中：
  • “实权限”是管理员用户组技术上可以行使的所有权限，其中再细分为：
    • “非专有实权限”，即一般延伸确认用户可以行使的权限，因为所有管理员都理论上是延伸确认用户，以及
    • “专有实权限”，即一般延伸确认用户不能行使的权限，也就是技术上相对于延伸确认用户而言仅容许被列入管理员用户组的用户行使的权限（例如页面的删除权与恢复权），而
  • “虚权限”则是技术上任何延伸确认或以下用户都能操作，但实务上只认定管理员的操作有效或不可直接推翻的权限（例如页面存废讨论的保留决定，非管理员作出的决定可以直接重开，但管理员作出的决定不可以，只能经DRV决定推翻与否）。
我的意见是：
  • 从定义上而言，所有“虚权限”都依赖“实权限”操作，但并不一定依赖“专有实权限”操作，而“虚权限”可以是多个“实权限”的集合；
  • 从定义上而言，“专有实权限”与“虚权限”必然为“管理权限”，而“非专有实权限”则需视乎情况而定；
  • “实权限”是技术上的东西，需要由技术站点特别授予，因此社群单设立本地规则而不做任何其他事情无法让管理员获得“实权限”；
  • “虚权限”由于并不一定经常依赖“专有实权限”操作，因此并不是技术上的东西，继而可以通过设立本地规则让管理员获得“虚权限”；
  • 滥用管理权限的情形包括：
    1. 滥用“专有实权限”、
    2. 滥用“非专有实权限”且该使用“非专有实权限”的情形被认定为属于使用“管理权限”，以及
    3. 滥用“虚权限”。
因此，管理员故意在AFD将显然不适合保留的页面以“保留”结案虽然没有滥用任何“专有实权限”，但仍然是滥用管理权限，不能因为该管理员没有滥用任何“专有实权限”而认为他没有滥用管理权限；
  • 管理员使用“非专有实权限”的情形是否属于使用“管理权限”的判定权，以及是否使用了“虚权限”的判定权，均在于社群，而非管理员本身。管理员可以自由心证，但如其自由心证不合理，社群有权不予接纳。社群应以管理员的行为判定管理员使用“非专有实权限”的情形是否属于使用“管理权限”或是否使用了“虚权限”。
以上。Sanmosa In vain 2023年7月20日 (四) 11:05 (UTC)
修改于2023年7月21日 (五) 00:44 (UTC)。Sanmosa In vain 2023年7月21日 (五) 00:44 (UTC)
您对于“实权限”的观点已被YFdyh反驳：至少目前，巡查豁免是管理员用户组的权限吧，所以按上文所说，建立页面也变成了动用管理权限。（2023年7月19日 (三) 12:36 (UTC)）。以阁下的论点，管理员拥有editsemiprotected、autopatrol、extendedconfirmed等权限，编辑受延伸确认保护页面（注意大部分管理员没有延伸确认用户组，即其延伸确认保护编辑权是管理员组授予）、创建新页面也实际动用了Special:ListGroupRights#sysop所列sysop用户组的权限，这显然是不合理的。--路西法人 2023年7月20日 (四) 11:12 (UTC)
我现在重新想了一下，我的意见是管理人员动用Special:群组权限中所示的“（全部）群组”所有的权限可以不视为动用管理权限。但是如果到了（自动）确认用户专有的权限的层阶的话我不支持，因为（自动）确认用户专有的权限已经是相对于一般人（要考虑到整个网络世界的范围）而言较高阶的权限，但动用管理权限的操作所针对的对象不一定全部都是（自动）确认用户，所以管理员使用editsemiprotected、autopatrol、extendedconfirmed等管理员组所有的权限应该要视为动用了管理权限。Sanmosa In vain 2023年7月20日 (四) 13:24 (UTC)
阁下对“管理”二字有非常严重的误解。editsemiprotected和extendedconfirmed等权限是无法主动摘除的，即使失去管理员状态仍然存在，表示摘帽子仍然不会阻止其继续享有该等权限者，显然非“管理员特有的进阶权限”更非“主动用作管理维基百科的权限”，不可能符合“管理权限”的意思。需要跟一般用户一样以封锁处理，而不能单靠移除管理权限永久阻截该等行为的，就证明了“管理权限”跟“一般权限”的差异。--路西法人 2023年7月20日 (四) 13:41 (UTC)
我觉得我没有误解，这应该就只是我跟你将拿来跟管理员组对比的用户权限组别有分别而已。那我还有另一种认定方法，就是要视乎管理人员行使权限时主要影响的对象有甚么人，如果上至延伸确认用户的话，那行使与延伸确认用户重复的权限不视为动用管理权限，但如果上至自动确认用户（而非延伸确认用户）的话，那行使与延伸确认用户重复的权限就会视为动用管理权限，因为这个行驶重复权限的操作对自动确认用户产生了实际的制约效果。这种认定方法的前设是假定用户权限级别较低的用户（比如非管理员、非延伸确认用户的自动确认用户）不完全熟悉用户权限级别较高的用户所有的权限。Sanmosa In vain 2023年7月20日 (四) 13:50 (UTC)
恕我吐槽，除非你维莫名空降管理员，否则管理员就算被解除管理员也依然会有editsemiprotected和extendedconfirmed此两权限。既然都空降了，那自然是基金会行动了，根本不会受这个提案影响。--SunAfterRain 2023年7月20日 (四) 13:54 (UTC)
“注意大部分管理员没有延伸确认用户组，即其延伸确认保护编辑权是管理员组授予”，这是LuciferianThomas上边的原话。Sanmosa In vain 2023年7月20日 (四) 14:03 (UTC)
这是WP:XCON当初配置的遗留问题，本来就是bug／错误配置（新的管理员如Ericliu1912和Peacearth都会在成为管理员前获得延确）。显然不是合理反驳太阳君所述的论点。--路西法人 2023年7月20日 (四) 14:08 (UTC)
我想我可能看错了一点东西，请容许我先冷静一下以后再重看。Sanmosa In vain 2023年7月20日 (四) 14:13 (UTC)
延伸确认通过之时，预期所有符合500/90要求的用户都应该成为延伸确认用户，管理员也不应排除在外。该flag本来不能手动授予或移除，自然管理员应同样自动获得该权，但实际配置之时并无这样做。延确是应该要像自确一样如常附于管理员上。--路西法人 2023年7月20日 (四) 14:17 (UTC)
延伸一下YFdyh的论点：担任管理员的要求并不包含“会写条目”，而管理员的autopatrol权限是管理员用户组授予的（管理员不会同时持有巡查豁免、巡、退等用户组），那么是否管理员创建不合格条目（动用了autopatrolled权），就变成滥用管理员权限了？莫名其妙啊。--路西法人 2023年7月20日 (四) 11:21 (UTC)
既然阁下会提议摘巡查员的巡查豁免，为何会提出同样没有写条目要求的管理员应保留巡查豁免权，并将建立不当条目视作“滥用管理权限”呢？虽然我当初提案确实没有指出巡查豁免权（因为不在原先两个组别内），但上方我也曾提出过如果可以就连autopatrol都摘掉。为何阁下就一概而论全部（包括巡查豁免）都是管理权限，不能摘呢？何来之“可靠效力”呢？不是社群共识所得的东西，何来“效力”？--路西法人 2023年7月20日 (四) 11:32 (UTC)
@LuciferianThomas：你这里这样把这个权限单独摘出来讲不合理，因为你当初的提议是把一篮子的权限都给移除掉，我反对的是把一篮子的权限都给移除掉的做法。如果你真要单独拿出来讲的话，那我建议你就此单独新开提案，而不是在关了那个一篮子提案后单独将这点抽出来批判我。你这里既然说要先“判定什么属于管理员的角色、什么属于管理行动的一部分、什么应该以申诉而非争议形式处理”，那你就不要在这里在牵扯到移除权限的事情，不然讨论离题了大家也控制不住。Sanmosa In vain 2023年7月20日 (四) 13:12 (UTC)
阁下的立场是Special:ListGroupRights#sysop全部都视为管理权限，把巡查豁免作为一个例子论证阁下观点有问题，又不行了？对我的立场而言，“摘权限”是跟“不视作管理操作”是同价的，别给我抓字眼。我表达的是阁下认为管理员现在持有的权限全部都应该视为管理权限的观点错误，为何阁下就一概而论全部（包括巡查豁免）都是管理权限，不能摘呢？问的是为何阁下就不能从阁下的观念中摘掉“巡查豁免”以至其他没有管理作用的权限视作“管理权限”的观点。--路西法人 2023年7月20日 (四) 13:27 (UTC)
那你当初的提议是不是把一篮子的权限都给移除掉？我觉得你应该合理预期其他人会从宏观的角度来看整件事情。你把这个权限单独摘出来讲的做法属于从微观角度来看，我从不同的微观角度来看的答案跟从宏观的角度来看的答案是有可能有不同的，所以如果你要知道我就这个微观角度来看的答案的话，请明示。Sanmosa In vain 2023年7月20日 (四) 13:31 (UTC)
我对于我早前想要摘以及现在不认同认定为管理权限的每一个权限的立场都非常一致：全部都未曾也不该视作管理权限，不会像阁下一个一样。如果阁下是大一回事小一回事的观点，那请阁下先审视您自己的观点为何会不一致和自相矛盾。再者，前面反对我摘权的，一个是觉得只要一般人能做到（以任何方式）的动作就都不是管理操作（管理权限的范围比我还紧），一个是觉得纯粹没必要动，只有阁下是觉得全部都是管理操作，不应该动。四人中与自己、其他人立场最不一致的仍是阁下。--路西法人 2023年7月20日 (四) 14:03 (UTC)
我之所以说我从不同的微观角度来看的答案跟从宏观的角度来看的答案是有可能有不同的，是因为有些时候某几件事情分开来看各自是某种属性，但集合在一起来看属性会变化，我的答案的不一致是性质的变化所导致的，你在性质有变化的情况下仍保持完全一致的观点会导致你的观点在部分情况下有效、部分情况下无效。所以我还是这个问题：你到底要不要知道我就这个微观角度来看的答案？Sanmosa In vain 2023年7月20日 (四) 14:08 (UTC)
我对于自相矛盾的观点没有兴趣。--路西法人 2023年7月20日 (四) 14:24 (UTC)
就算你根本完全不打算知道我的具体立场意见是甚么，那请你至少也不要随意将我的具体立场断章取义。我相信我已经把我的话说得足够明确了：这里的情况分开看与一起看是不同的，不能一概而论。Sanmosa In vain 2023年7月20日 (四) 14:29 (UTC)
(－)反对：为了防止本讨论在格式上偏向修订方，专门设了这个子段。既未能证明造成严重的站务处理困扰，我也不明白此举意义何在。留着无妨，改了也没有显著的益处。——WMLO※议程表 2023年7月20日 (四) 22:21 (UTC)
现在没有提案，纯属讨论，没有可以“反对”的事情。摘权的讨论早已关闭。--路西法人 2023年7月21日 (五) 00:07 (UTC)
我想了一下，其实为了让所有管理员正常自动提升为延伸确认用户而移除仅与延伸确认用户重复的权限或许是可取的，但其他的我认为需要谨慎地个别考虑。Sanmosa In vain 2023年7月20日 (四) 23:59 (UTC)
管理员拥有延伸确认权并非无法自动提升延伸确认用户的技术原因，最大可能是管理员用户组停用了一切自动提升，这是不应该发生的事。再者，如果与延伸确认用户重复的权限可以“不视作管理权限”（或移除），没道理自确用户拥有的权限autoconfirmed、editsemiprotected等权不能同样办理。--路西法人 2023年7月21日 (五) 00:11 (UTC)
（1）如果“最大可能是管理员用户组停用了一切自动提升”的话，那停用自动提升的技术原因（或称bug）又是甚么？移除与延伸确认用户重复的权限能解决停用自动提升的技术问题吗？如果不能的话，那解决的方法又是甚么？（2）我相信你还记得我有说过“我想我可能看错了一点东西，请容许我先冷静一下以后再重看”这句话，我之后想了一下，好像确实是这样的道理。这样的话，请容许我调整我对“实权限”与“虚权限”的具体定义。Sanmosa In vain 2023年7月21日 (五) 00:24 (UTC)
XCON的解决方法最简单粗暴就是共识后交phab工单。gerrit:712754的修订（InitialiseSettings.php#L-14979）设定了[ '!', [ APCOND_INGROUPS, 'sysop' ] ]，似乎是当初讨论时直搬过来的问题（WP:XCON：机械人以及管理员都自动拥有此权限，因此不会另外授予该群组权限，但在部署以后获得管理员权限的用户可能早已拥有此权限。）。现在导致{{If extendedconfirmed}}和MediaWiki:Group-extendedconfirmed.css等不适用于符合500/90条件的旧管理员的不合理情况。--路西法人 2023年7月21日 (五) 01:18 (UTC)
既然移除仅与延伸确认用户重复的权限不能解决停用自动提升的技术问题，我建议停用自动提升的技术问题应该另开讨论。Sanmosa In vain 2023年7月21日 (五) 01:37 (UTC)
不过既然阁下已经修订了对“实权”的观点，不再一刀切将所有“管理员组拥有的权限”都视作“管理用的权限”已经跟其他用户的观点更为靠近了，那问题就大概解决了。技术问题本来是想跟摘权一并处理，那就稍后再分案处理。--路西法人 2023年7月21日 (五) 02:03 (UTC)

编辑请求 2023-09-24

最新留言：在1年前发布3条留言3人参与讨论

  请求已处理——暁月凛奈 (留言) 2023年9月24日 (日) 02:58 (UTC)

Antigng-bot2已被解除管理员机械人，请把目前管理员人数改为{{#expr:{{NUMBEROFADMINS}} - 3}}（不含2个[[Wikipedia:ADMINBOT|管理员机器人]]及1个[[Wikipedia:管理员名单#系統帳戶|系統帳戶]]）。--132.234.229.169（留言） 2023年9月24日 (日) 02:45 (UTC)

@暁月凛奈：目前管理员人数仍然为{{#expr:{{NUMBEROFADMINS}} - 4}}，请改为{{#expr:{{NUMBEROFADMINS}} - 3}}。--132.234.228.109（留言） 2023年9月24日 (日) 04:43 (UTC)
检索自“https://zh.wikipedia.org/w/index.php?title=Wikipedia_talk:管理员/存档5&oldid=79534821”
返回到项目页面“管理员/存档5”。