维基百科讨论:用户权限级别

成为自动确认用户后,长时间不登陆账号,账号会怎么样?

问题已解决：

落花有意12138 _{论 回复请ping我} 2021年7月31日 (六) 05:26 (UTC)

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

---

各位前辈大家好,我现在已经是自动确认用户了,但是因为工作的原因,可能没法每天都登陆维基百科,我想请教一下,如果我长时间(如一周/一月)不登陆维基百科,也不再有新的编辑,我现在的账号会怎么样?等我之后再次登的时候还会是自动确认用户么?还是说会变成用户界面不存在呢?希望可以得到各位前辈的解答,十分感谢!--Zsllong（留言） 2021年7月26日 (一) 05:59 (UTC)

是；什么都不会变。--安忆^Talk 2021年7月26日 (一) 06:12 (UTC)

没有权限职务的话，没有变化。——Sakamotosan路过围观杯弓蛇影 | 避免做作，免敬 2021年7月26日 (一) 06:44 (UTC)

可能会由于长期不编辑跳掉ipbe？但自动确认用户是不是就有ipbe了--祝编安--pavlov2（留言） 2021年7月26日 (一) 09:02 (UTC)

没有。您对这些东西还真的是一点都不熟悉啊。--Lightyears _GBAW 2021年7月26日 (一) 09:04 (UTC)

不是由于某人说疑似我不是新手嘛，怀疑我是wp:SPA,我得跟您说我确实是新手。我不熟悉。--祝编安--pavlov2（留言） 2021年7月27日 (二) 14:02 (UTC)

都可以建立两岸四地什么会了还......-- Sunny00217  2021年7月30日 (五) 01:11 (UTC)

自动确认用户权限除了滥用过滤器，其他人吊销不掉。 --Milky·Defer 2021年7月26日 (一) 13:12 (UTC)

好的,我晓得了,非常感谢各位前辈的解答!我确实对这些都不是很熟悉,之前没有接触过呢,正在一点点的积累经验。感恩!--Zsllong（留言） 2021年7月27日 (二) 01:48 (UTC)

啊抱歉，之前我说的那句话不是对您说的。--Lightyears _GBAW 2021年7月27日 (二) 02:01 (UTC)

没关系的。--Zsllong（留言） 2021年7月27日 (二) 08:24 (UTC)

---

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

设置新的保护类型

无共识：

注册用户保护无共识。--虫虫飞♡♡→♡℃※留言 2021年7月24日 (六) 10:18 (UTC)

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

---

维基百科部分条目被IP破坏者亦有，如直接半保护，可能影响到非自动确认用户进行正常编辑（如果它们不会提起编辑请求），遂提议设置此保护类别。

图标	命名	简介
	注册用户保护	受到此保护的页面只有注册用户（不论是非新用户，确认用户或自动确认用户）可以编辑。

--CreeperDigital1903 2021年6月7日 (一) 12:07 (UTC)

(－)倾向反对蛤，才50就自确了啦。--路西法人 • 留言 2021年6月7日 (一) 12:34 (UTC)

我觉得不一定，我从新用户变成自动确认花了快一个月。50说少也不算少了，又不是英维只要10次。问题是这在技术上能否实现，以及是否真的有“IP用户进行破坏但新用户不会”的情况。--Milky·Defer 2021年6月7日 (一) 13:19 (UTC)

• (－)反对。->>Vocal&Guitar->>_留言 2021年6月7日 (一) 13:22 (UTC)

  反对也得给原因，WP:!VOTE。--路西法人 • 留言 2021年6月7日 (一) 14:25 (UTC)

• 我唯一想到可能有用的地方是WP:VP/help.--Temp3600（留言） 2021年6月7日 (一) 16:10 (UTC)

如果要这样做的话，那必须将自动确认用户的要求进一步提高（可以把要求提升到与对Tor用户的要求一样，都是注册达90天并编辑达100次）。SANMOSA _Σουέζ 2021年6月8日 (二) 03:11 (UTC)

这个级别绝不应用于取代目前的半保护。七日确认机制是阻止即兴破坏者的利器。--Temp3600（留言） 2021年6月8日 (二) 08:00 (UTC)

@Temp3600：或许把注册用户保护、原一般半保护（注册满一周用户保护）和原Tor半保护（新半保护）当成3个并行的层级也可。我只是感觉现时zhwiki的自动确认用户的要求真的有点低而已。SANMOSA _Σουέζ 2021年6月8日 (二) 14:09 (UTC)

如果真得需要那么多保护级别，或许用AF即可。--银河市长—☎️— 2021年6月9日 (三) 08:15 (UTC)

话说我真的无法理解为什么wp:right申请“确认使用者”需要有“自动确认使用者”--木瓜不是食物#留言 2021年6月8日 (二) 05:33 (UTC)

用来给老用户开合规的分身账户，例如进行涉及确定用户权限的技术测试。——Sakamotosan路过围观杯弓蛇影 | 避免做作，免敬 2021年6月8日 (二) 12:05 (UTC)

不是自确亦可申请。--Hamish with w. 2021年6月8日 (二) 14:15 (UTC)

又被半保护了--木瓜不是食物#留言 2021年6月10日 (四) 03:38 (UTC)

@Jonathan5566：其他版请-- Sunny00217  2021年6月12日 (六) 04:35 (UTC)

(－)倾向反对功效不大-- Sunny00217  2021年6月9日 (三) 09:08 (UTC)

(－)反对。—MintCandy♫ _{欢迎参加浙江专题 台州专题} 2021年6月10日 (四) 05:04 (UTC)

(－)反对，没有太大作用。--Lanwi1(留言) 2021年6月21日 (一) 15:39 (UTC)

(－)反对，破坏者随便注册账号就能乱改。天蓬大元帅-会客 阅读机器翻译放松一下 2021年7月17日 (六) 07:55 (UTC)

---

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

引入延伸确认保护

已通过：

已公示七天，有关人事任免条件的条文修订，公示期间没有反对意见，这个修订已通过；但延伸确认保护有少数反对意见，暂时未通过。--虫虫飞♡♡→♡℃※留言 2021年7月17日 (六) 10:08 (UTC)

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

---

延伸确认保护还比较值得讨论。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2021年6月10日 (四) 09:47 (UTC)

上面说的有道理。--安忆^Talk 2021年6月10日 (四) 13:33 (UTC)

(▲)同上，XC权更值得讨论。--路西法人 • 留言 2021年6月10日 (四) 14:13 (UTC)

(▲)同上--虫虫飞♡♡→♡℃※留言 2021年6月18日 (五) 13:40 (UTC)

(＋)支持。空气小猫（留言） 2021年6月19日 (六) 23:31 (UTC)

初步提案如下：

现行条文	提议条文 延伸确认权限条件 账号已注册3个月。 已经编辑条目空间500次。(不含用户页及用户讨论页) 符合条件后，系统自动授权。 延伸确认权保护 只能由延伸确认用户编辑。

现行条文 解任投票联署提出或上任投票开始1个月前，编辑100次或以上；并在联署提出或上任投票开始前3个月内至少有一次编辑（不包括任何使用者页面及使用者对话页）； 编辑3000次或以上，或编辑1500次条目或以上。

提议条文 解任投票联署提出或上任投票开始1个月前，拥有延伸确认权限；并在联署提出或上任投票开始前3个月内至少有一次编辑； 编辑3000次或以上，或编辑1500次条目或以上。

以上。--虫虫飞♡♡→♡℃※留言 2021年6月20日 (日) 04:14 (UTC)

(－)倾向反对，Wikipedia:常年提案#扩展确认用户：没有充分理由证明延伸确认使用者比自动确认使用者更适合进阶编辑-- Sunny00217  2021年6月20日 (日) 07:07 (UTC)

鉴于刚才有人抗议其实是覆盖编辑表示不满，我就画掉反对了（（（^{[开玩笑的]}-- Sunny00217  2021年6月20日 (日) 07:24 (UTC)

(＋)支持，不过可以参考目前的自动确认使用者设立权限申请及除权，还有保护方针可以同时跟进条文“当出现自动确认使用者编辑战或半保护时仍无法有效的保护条目管理员即可提高至延伸确认保护”。~~Sid~~ 2021年6月20日 (日) 07:16 (UTC)

(▲)同上，但固然前提是参与编辑战的用户并非延确用户 草--路西法人 • 留言 2021年6月20日 (日) 07:46 (UTC)

就Wikipedia:常年提案#扩充确认用户的“未通过原因”的回应：不应将设立延确用户视为进行“进阶编辑”或“解决争议”的手段。设立延确应是减少高风险页面的破坏，而非如该页所述“编辑全保护页面”等操作（这个不是延确的工作）。延确应配合设置蓝锁作为破坏行为的防范手段而非争议编辑的处理手段。编辑争议／编辑战的行为依然应该以金锁处理（尤其为政治议题）。现行确实有银锁的编辑战保护，以蓝锁作为防止争议的保护手段的考量应与银锁编辑战保护相似。--路西法人 • 留言 2021年6月20日 (日) 07:38 (UTC)

为什么要用一堆xx锁的非正式用语！ 草-- Sunny00217  2021年6月21日 (一) 00:00 (UTC)

随便啦wwwwww--路西法人 • 留言 2021年6月21日 (一) 02:27 (UTC)

感觉只不过是将自动确认用户的难度延后到ex确认用户的难度吧，并不能根本破坏防范的问题。——Sakamotosan路过围观杯弓蛇影 | 避免做作，免敬 2021年6月21日 (一) 03:21 (UTC)

刷500比刷50难啊，还要90天。--路西法人 • 留言 2021年6月21日 (一) 05:51 (UTC)

(－)反对，延伸确认保护主要针对被破坏的半保护页面，在解决编辑战方面没有太大作用。目前中文维基百科没有足够条件引入延伸确认保护。--Lanwi1(留言) 2021年6月21日 (一) 15:33 (UTC)

阁下哪里来“延确保护必定需要协助解决编辑战”的说法？延确用来保护高风险页面或模板正合适，高编辑战风险也不会拿延确来保护而是全保护了啊。--路西法人 • 留言 2021年6月22日 (二) 02:21 (UTC)

中文维基百科有半保护和模板保护就足够了，我看了一下外文版方针，延伸确认保护仅用来保护被破坏的半保护页面。--Lanwi1(留言) 2021年6月22日 (二) 16:42 (UTC)

这样的话确实和模板保护有点重复。我有个反建议：延伸确认保护可以拿来处理人事任免投票资格。@Lanwi1。SANMOSA _Σουέζ 2021年6月27日 (日) 01:18 (UTC)

(？)疑问 人事任免投票资格？是要把延伸确认资格从500次编辑拉伸到1500或3000次编辑吗？—- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鲜果茶☕]（☎️·☘️） 2021年6月27日 (日) 01:56 (UTC)

可以把人事任免投票资格第一条的“编辑100次或以上”改为“延伸确认资格”，其他维持不变。--虫虫飞♡♡→♡℃※留言 2021年6月27日 (日) 02:19 (UTC)

(＋)支持User:虫虫飞案。 -- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鲜果茶☕]（☎️·☘️） 2021年6月27日 (日) 02:26 (UTC)

把延伸确认资格从500次编辑拉伸到1500次或3000次编辑是可行的，甚至如果技术允许的话，可以让系统自动判别用户是否符合人事任免投票资格，然后为符合资格者自动授权延伸确认用户，授权后不符合资格者自动除权。SANMOSA _Σουέζ 2021年6月27日 (日) 02:34 (UTC)

太高了，这最终会过度妨碍想编辑的人。有些职业维基人^{[开玩笑的]}一周不到就可以三千，但非职业维基人^{[开玩笑的]}想要达到千次以上都会花费相当长的时间，可能半年，可能一年，总之太长了。--安忆^Talk 2021年6月27日 (日) 03:41 (UTC)

不然一样维持500次，然后把人事任免投票资格第ー条的“编辑100次或以上”改为“延伸确认资格”，其他维持不变，则是变成将人事任免投票资格第ㄧ条改成500次。-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鲜果茶☕]（☎️·☘️） 2021年6月27日 (日) 03:48 (UTC)

人事任免投票资格完全可以计票时审核（就是目前的方式），不需要依赖任何技术上的使用者群组啊（不用为了这个资格建立使用者群组的意思）？--Xiplus#Talk 2021年6月27日 (日) 04:35 (UTC)

这样做可以直接省去计票审核的程序，因为不符合资格者自己也投不了票。SANMOSA _Σουέζ 2021年6月28日 (一) 00:23 (UTC)

现在计票审核也没多难，都有工具帮助了；前面提的延伸确认资格根本无法完全涵盖人事任免投票资格（技术上根本无法计算“在联署提出或上任投票开始前3个月内至少有一次编辑”），无法省去计票审核的程序；没有资格者应该还是能发表意见，不可能用保护功能。--Xiplus#Talk 2021年6月28日 (一) 02:04 (UTC)

@Sanmosa延伸确认保护也不能处理人事任免投票资格，只能处理被破坏的半保护页面。--Lanwi1(留言) 2021年6月27日 (日) 16:02 (UTC)

@Lanwi1：抱歉，我完全不同意你的看法。中文维基百科不是英文维基百科的中文版，如果中文维基百科的社群共识决议对延伸确认保护有另类的用法的话，那这种另类的用法仍然是可行的。SANMOSA _Σουέζ 2021年6月28日 (一) 00:23 (UTC)

@Sanmosa：除了英文版，法文版和日文版也实施延伸确认保护，都是防破坏，若有另类的用法会脱离本来的目的。目前中文维基百科没有如问题编辑频繁发生之类的足够背景支持引入延伸确认保护。--Lanwi1(留言) 2021年6月28日 (一) 19:22 (UTC)

@Lanwi1：我有一个疑问：您认为共产主义现在能否永久半保护（近半年约被破坏了10次以上）？如果说这个是意识形态，那么性交（现在被半保护了约10年）和同性恋呢？从目前中维鼓励一切用户进行编辑的角度来说这些条目确实都不应该半保护，但是过去几个月的经验/历史记录很明显显示出如果不半保护还会继续有破坏，但如果引入了扩展保护，很明显这几个条目就适合进行长期半保护了。当然，对应的原本很有争议的条目自然可以上升至扩展保护，但是如果只有半保护和全保护的话，至少我认为情况是比较尴尬的。--ときさき くるみ 2021年6月29日 (二) 11:28 (UTC)

条目共产主义现在不需要永久半保护的原因是未受到频繁破坏。扩展保护仅用于被破坏的半保护页面，我还认为需要永久扩展保护的基本上都是被LTA破坏的半保护页面，若以针对LTA突破半保护为由引入扩展保护，我表示支持。另外日文版引入扩展保护的背景就是有些LTA喜欢突破半保护，本地只有影武者喜欢突破半保护……--Lanwi1(留言) 2021年6月29日 (二) 20:45 (UTC)

@Lanwi1：您能否大致给出您心目中频繁的标准？在我看来在一个大部分科学类条目两三年没人写的地方，某个条目半年被破坏了接近10次绝对达到频繁的标准了。另，看了一下英维，的确您说的有道理，不过英维同样对波兰种族主义、阿以冲突这类高争议但应该没有LTA的条目进行了扩展保护。--ときさき くるみ 2021年6月30日 (三) 07:16 (UTC)

基本上是短期内密集破坏，因此长期又零星的破坏就处于临界情况，我无法直接说一律保护或不保护，要按个案判断，但若是冷清的条目导致看起来编辑全是破坏，那或许会被保护。--Xiplus#Talk 2021年6月30日 (三) 08:01 (UTC)

不同意引入扩展保护会让“这几个条目就适合进行长期半保护”，引入比半保护层级还高的扩展保护不应该变相让半保护的标准放松，如果您认为半保护的标准应该放松，您应该提议社群变更半保护标准，而不是透过引入扩展保护来解决。--Xiplus#Talk 2021年6月30日 (三) 01:23 (UTC)

@Xiplus：我知道，但这更多不是标准的问题：我个人认为（欢迎指出错误），排除掉全保护外只有半保护和不保护，管理员在遇到已被轻至中度破坏的争议条目由于只有这两个选项，自然会更倾向于不保护，让其他编者去自行回退掉破坏的编辑（海纳百川有容乃大，这可是中维的标语），而非进行半保护（但是从实用主义角度来说，我个人认为这并非好事，这样反而浪费了人力去维护本可以不存在的破坏，如果进行了半保护，原本要贡献的编者可以在讨论页请求编辑保护条目，而原本的破坏者的破坏也就自然留在了讨论页，而非条目页）。但如果有了扩展保护，管理员就更自然地会考虑短时进行半保护。--ときさき くるみ 2021年6月30日 (三) 07:16 (UTC)

全面全保护就再也不会有破坏了，但这是不可能的，所以保护跟开放只能取得一个合适的平衡。“扩展保护，管理员就更自然地会考虑短时进行半保护”，我不会，所以我才无法理解引入扩展保护的目的，要达成你的目的只能引入一个比半保护层级还低的保护。--Xiplus#Talk 2021年6月30日 (三) 07:52 (UTC)

@Xiplus：我懂all or nothing的问题，但说实话单从结果来看确实是很多英维半保护且中维（我认为）也应该半保护的条目没有半保护，比如上面那几个例子，如果您认为这不是扩展自确的原因，欢迎您说说您认为是什么原因导致中维更不倾向于半保护。--ときさき くるみ 2021年6月30日 (三) 08:25 (UTC)

英维破坏量更多，自动确认门槛较低。这是一般性原因，不是针对前面您提的条目。--Xiplus#Talk 2021年6月30日 (三) 13:05 (UTC)

英维破坏量多没问题，但其实中维破坏比例可能高一些，我没实际做过数据统计，但是单从个人经验来看感觉如此。我知道，我强调这几个例子只是为了突出现在的问题。不过现在我想问一句：设立一个（全保护之下的）更低门槛和设一个更高门槛真的本质上不等价吗？最后，我希望我是错的，但是每次点开这些常用条目一翻历史就能看到一批扰乱性编辑实在让人恼火，所以我才大力支持，哪怕能稍稍激励一部分管理员更勤的上半保护我个人目前认为也是值得的。--ときさき くるみ 2021年6月30日 (三) 17:22 (UTC)

查阅您提出的几个条目，都没有近期请求保护被拒绝的案例，所以您说这些条目管理员不会保护这点实在有待商榷。--Xiplus#Talk 2021年7月1日 (四) 02:02 (UTC)

好吧，我可妥协，但我还是对上文所述的现状不满。--ときさき くるみ 2021年7月1日 (四) 17:31 (UTC)

(＋)支持设立甚至拔高门槛，wikiscan上的数据显示每月活跃自确至少约占每月活跃用户数的6%~7%，今年上半年至少应有超过2700名自确用户进行过编辑，最近更改的筛选栏中也有对初学者和有经验的编者的区分。是，某些条目生来就是有争议的，这些条目的编辑战可能确实没法避免，但至少设立更高门槛的自确可以让想要参与这些条目的人进一步学习中维的规则和过去的案例，而且引入扩展自确之后也可以对一些有相对较少争议（但总体上仍有较大争议）的条目上半保护。--ときさき くるみ 2021年6月27日 (日) 16:27 (UTC)

编辑数与学习规则毫无关联。->>Vocal&Guitar->>_留言 2021年6月30日 (三) 04:59 (UTC)

@Ohtashinichiro：Yes, but actually NO. 是，这两者是没有直接关系。但大多数编者的条目编辑水平和辨别来源的水平最终还是在编辑的过程中提升的，您不能指望一个不懂维基语法的新手在中维这种左侧栏里没有“学习如何编辑”的地方一开始就懂如何将他主观想写的东西写出来并引出来源，更别提去辨别来源是否可靠，是否是主流观点了。这么说可能有点太泛泛而谈了，您不妨回想一下您刚开始写维基百科的时候写的条目是什么水平而现在又是什么水平（如果您不介意的话我可以帮您找找您早期的编辑）。--ときさき くるみ 2021年6月30日 (三) 07:16 (UTC)

我和你讲规则，你和我讲技术。对于想闯红灯的人，需要过问他的车技？。->>Vocal&Guitar->>_留言 2021年7月3日 (六) 01:27 (UTC)

我是觉得高引用数转换组（CGroup）如果要保护的话，Extended confirmed users这种水准正好比较合适。一般高风险模板可能有各种各样的技术考量，模板编辑员也是技术优秀的用户。但转换组基本就是纯内容向模板，熟悉相关领域、掌握简单语法的编辑都可以胜任修改。50次编辑可能经验不足，500次编辑大概就比较合适了。--洛普利宁 2021年7月3日 (六) 09:54 (UTC)

根据WP:7DAYS，现就延伸确认保护及人事任免的修订提案公示七天。--虫虫飞♡♡→♡℃※留言 2021年7月10日 (六) 10:02 (UTC)

对于这一没有经过仔细思考和周全考虑的提案，我是不会支持的。况且提案的疏漏没有得到解决。--Bookwith（留言） 2021年7月13日 (二) 18:33 (UTC)

@Bookwith：请说说有什么疏漏。--虫虫飞♡♡→♡℃※留言 2021年7月14日 (三) 00:13 (UTC)

应该能看出，连实施细节都没想好就来提案了。--Bookwith（留言） 2021年7月14日 (三) 05:43 (UTC)

放心吧，这个很简单，而且之前本站有过模板保护及模板编辑员的引入的经验。--虫虫飞♡♡→♡℃※留言 2021年7月14日 (三) 05:51 (UTC)

为什么是条目空间500次？这类要求向来没有指定名字空间的。即使有充足经验，依然应该列出各项实施细节。--Bookwith（留言） 2021年7月14日 (三) 06:46 (UTC)

英维日维都是500次条目空间，而且避免用户在用户页刷够500次。至于具体细节，就像英维那边，系统会自动授权；还是您希望像日维那边一样可以通过申请获得？即管理员可以授予可信用户权限，也可移除用户的权限？--虫虫飞♡♡→♡℃※留言 2021年7月14日 (三) 06:52 (UTC)

英维日维的要求都不是500次条目空间，请别撒谎。--Bookwith（留言） 2021年7月14日 (三) 08:49 (UTC)

英维方针没有写明，但我就亲身试过了，而且取得了英维的延伸确认用户权(500次条目空间后才获得)，500次非条目空间，英维是不会授予延伸确认权，您可以去试一下。--虫虫飞♡♡→♡℃※留言 2021年7月14日 (三) 09:07 (UTC)

根本不是，那里500次是不限命名空间的，不要再误导他人了。--Bookwith（留言） 2021年7月14日 (三) 11:45 (UTC)

我不太了解原因，总之我在英维600次编辑数时，确实没有获得“延伸确认”，要在“条目空间500”才能获得权限。--虫虫飞♡♡→♡℃※留言 2021年7月14日 (三) 12:06 (UTC)

既然您担心门槛太高，我把门槛降低至不只限于条目空间。--虫虫飞♡♡→♡℃※留言 2021年7月14日 (三) 10:00 (UTC)

到底排除用户/用户讨论页，意义何在。--Bookwith（留言） 2021年7月14日 (三) 11:49 (UTC)

意义在于避免用户GAME，刷编辑数。您看VIP存档，经常有人举报有用户刷编辑数以求“自动确认”。--虫虫飞♡♡→♡℃※留言 2021年7月14日 (三) 12:00 (UTC)

我反对这一要求，因为实在太没意义了。一些编者们愿意刷到自动确认，不代表他们愿意刷到延伸确认，尤其是500次编辑对于他们来说是个难以达到的目标；甚或有一些只求移动权限、只求上传图片的编者，难道他们会对这一延伸确认权有兴趣？我们必须面对现实，看看各大站点的权限摘要。看，古今中外，有哪个站点的权限要求会像这样排除某些命名空间？无论是需要申请的权限，还是自动授予的权限，没有一个站点会设下这样的限制。为什么？因为稍有智慧的人都不难看出，这样设限对于恶意刷权限的编者来说，几乎没有任何作用。提案前请三思。--Bookwith（留言） 2021年7月14日 (三) 17:51 (UTC)

刷???编辑数是用刷的?= =这我有理解错误吗?如果没有那这反对简直胡闹。~~Sid~~ 2021年7月14日 (三) 18:15 (UTC)

就是有这种人啊，-- Sunny00217  2021年7月15日 (四) 03:19 (UTC)

那把门槛降低至不只限于条目空间不就解决了？是在乱吵什么鬼？-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鲜果茶☕]（☎️·☘️） 2021年7月15日 (四) 04:17 (UTC)

要故意排除用户/用户讨论空间，难道不会显得很可笑吗？--Bookwith（留言） 2021年7月15日 (四) 04:56 (UTC)

(－)强烈反对该提案, 如果不加限制地滥用保护, 把所有争议条目都加以保护, 不是彻底违背了WP:SOP和WP:BB的原则? 那样的话,当时允许IP用户编辑就是一个错误的决定. 最后让维基百科变得与百度百科没有任何区别. --Yining Chen（留言|签名） 2021年7月17日 (六) 07:42 (UTC)

@Yining Chen：延伸确认保护不能乱用的，只有半保护无法保护的情况下，才能用，而且可以减少用“全保护”，所以不违反WP:SOP和WP:BB，此外也与ip编辑无关，因为半保护下，ip也不能编辑，但您不因此反对半保护，防止破坏也很重要。--虫虫飞♡♡→♡℃※留言 2021年7月17日 (六) 08:07 (UTC)

• 已公示七天，有关人事任免条件的条文修订，公示期间没有反对意见，这个修订已通过；但延伸确认保护有少数反对意见，暂时未通过。--虫虫飞♡♡→♡℃※留言 2021年7月17日 (六) 10:08 (UTC)

---

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

引入延伸确认保护(第二稿)

已通过：

已公示七天，有关延伸确认用户权及延伸保护的条文修订已通过。--虫虫飞♡♡→♡℃※留言 2021年7月24日 (六) 10:13 (UTC)

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

---

于Phabricator查看
编号 T287322的任务

现根据第一稿的少数反对意见修订如下，重新公示七天：

现行条文	提议条文 延伸确认权限条件 账号已注册3个月。 已经编辑500次。 符合条件后，系统自动授权。 延伸确认权保护 只能由延伸确认用户编辑。 在半保护无法阻止破坏时才能用。 在半保护无法阻止的编辑战时才能用。

以上。--虫虫飞♡♡→♡℃※留言 2021年7月17日 (六) 10:13 (UTC)

• 已公示七天，有关延伸确认用户权及延伸保护的条文修订已通过。--虫虫飞♡♡→♡℃※留言 2021年7月24日 (六) 10:13 (UTC)

---

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

延伸确认权限后续讨论 part1

反正你们都同意我也不管了，结-- Sunny00217  2021年7月28日 (三) 01:02 (UTC)

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

---

• 这个通过方式有严重瑕疵吧，只有虫虫飞一个人说通过？（因为太奇怪了，所以这边来请一下上面讨论过的人@Sidishandsome、LuciferianThomas、Cwek、Lanwi1、Sanmosa、A2569875、Xiplus、Tokisaki Kurumi、Ohtashinichiro、Lopullinen、Bookwith）-- Sunny00217  2021年7月26日 (一) 04:19 (UTC)

• (※)注意:讨论已超过一个月，最后一个修订版公示七天期间，完全没有人反对，共识很明显。--虫虫飞♡♡→♡℃※留言 2021年7月26日 (一) 04:27 (UTC)

  虫虫飞：我不同意这是个合符程序的公示──通过方式是有严重瑕疵。有个简单的问题──一个存在反对意见的提案，在经过修订后能立即视为已取得共识吗？显然不能。提出修订案后立即进行公示，是不当的。还有关键的一点──对原提案进行改良后，应当邀请原提案的反对者参与讨论，让他们知悉有关改动。而这点，虫虫飞是做不到的，以致于有反对者未知悉本提案。--Bookwith（留言） 2021年7月26日 (一) 09:03 (UTC)

• 请了解wp:共识方针!--虫虫飞♡♡→♡℃※留言 2021年7月26日 (一) 09:10 (UTC)

  虫虫飞毋须为此而担心。还请解答上方疑问。--Bookwith（留言） 2021年7月26日 (一) 10:23 (UTC)

• 您上面的意见很好，但您的意见不符合方针规定，请阅读相关方针。--虫虫飞♡♡→♡℃※留言 2021年7月26日 (一) 10:40 (UTC)

  请虫虫飞解释我的意见如何违反共识方针，以致于不能被采纳和执行。--Bookwith（留言） 2021年7月27日 (二) 04:48 (UTC)

• 您上面的意见是不符合方针规定，如果您认为符合，请引用方针论证，维基是不能把自己的意见当规则，详见Wikipedia:不要为阐释观点而扰乱维基百科。--虫虫飞♡♡→♡℃※留言 2021年7月27日 (二) 05:12 (UTC)

  虫虫飞仍然避答我的意见在哪一方面不符合方针，也就是我的意见抵触了哪一条方针。对此我不感乐观。--Bookwith（留言） 2021年7月27日 (二) 10:24 (UTC)

• 我上面是说您提出的建议不符合方针要求，您提出“应当邀请原提案的反对者参与讨论”等要求，方针在哪里规定?而且您在公示期放弃讨论，通过后才出来闹，是属于为展述个人观点而扰乱维基百科。--虫虫飞♡♡→♡℃※留言 2021年7月27日 (二) 11:00 (UTC)

  那句不是要求。而是说明虫虫飞没有邀请其他维基人参与讨论的情况。--Bookwith（留言） 2021年7月27日 (二) 16:15 (UTC)

• 发出公示公告就已经是“邀请其他维基人参与讨论”，提案是面对整个社群，而不是面对您一个人，而且有些用户会觉得ｐｉｎｇ是很骚扰。而且哪个方针规定一定要ｐｉｎｇ人来讨论？--虫虫飞♡♡→♡℃※留言 2021年7月27日 (二) 16:30 (UTC)

• @蟲蟲飛：我先重启讨论，本案结案具有瑕疵，依据WP:7DAYS：“该提案只要取得共识便可公示，为期至少7日”，未见本案有其他留言，仅有阁下之提案，一人提案的无新留言不足以成立新共识，再者上方Sunny00217君已按WP:7DAYS：“如果有新意见，请通过协商解决问题”提出程序异议，故重启讨论。--🍫巧克力～✿ 2021年7月26日 (一) 04:29 (UTC)
• @卡達：您误解了方针，WP:7DAYS是指公示期间，不是说公示通过后，如果想推翻已通过的提案应在下面重新提案，而且不是直接重启已通过而且关闭几天的讨论。--虫虫飞♡♡→♡℃※留言 2021年7月26日 (一) 04:34 (UTC)
  • @蟲蟲飛：应该是说，共识的形成来自于前期的讨论，有鉴于程序正义的实践，还是请阁下确认上述参与提案的讨论者是否对修正案有无疑义，否则在“取得共识”的前提下，会缺乏足够的提案通过正当性，也就会变成Sunny君所质疑“通过”无新留言的一人提案情形。--🍫巧克力～✿ 2021年7月26日 (一) 04:38 (UTC)
• @卡達：提案无异议就通过，一向都是这样，如果事后有异议，也应该按照既定规则去重新提案。这正如RFA期间您忘了投反对票，等到候选人上任了，您不能事后才出来反对。--虫虫飞♡♡→♡℃※留言 2021年7月26日 (一) 04:42 (UTC)
  • @蟲蟲飛：确实是如此，但按照这样来看的话，保险起见还是请阁下利用WP:SNOW来缩短等待期进入公示，不然难保之后不会有同样的事情发生，辛苦阁下了。--🍫巧克力～✿ 2021年7月26日 (一) 04:57 (UTC)
  • 我对提案通过的共识没异议，而且提案在过去一个月获得了大量用户支持，而且最后的修订版，在完全没有反对下通过，共识已经非常明显。其他人有需要请自行去提案，而且重大的提案不应WP:SNOW。--虫虫飞♡♡→♡℃※留言 2021年7月26日 (一) 05:04 (UTC)
• @蟲蟲飛：我基本上没有意见，延伸确认保护对LTA有效。--Lanwi1(留言) 2021年7月26日 (一) 05:57 (UTC)
• 认为程序并没什么大问题，可以视为通过。(＋)强烈支持提案。-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鲜果茶☕]（☎️·☘️） 2021年7月26日 (一) 06:43 (UTC)
• 我支持引入延伸确认保护，举个例子这个保护就可以应用在LTA:KAGE上，延伸确认的宗旨在于当半保护无法有效防止条目遭受破坏时，保护才会提高到这个层级。引入延伸确认保护后模板上也能够降低部分模板的保护，而尽为可能的接近维基百科人人皆可编辑这个宗旨又可以做到一定的保护。~~Sid~~ 2021年7月26日 (一) 07:28 (UTC)
• +1。--MCC214（Sign | Contributions） 2021年7月26日 (一) 13:35 (UTC)
• 之前改稿了之后我一直没再发言就是因为我没太看懂这一稿在哪一点上会有问题，这不是已经把用户空间纳入了吗……？--ときさき くるみ 2021年7月27日 (二) 23:49 (UTC)

• 对呀，bookwith一直最介意的这点已经根据他的意见改了，不明白他还在闹什么?--虫虫飞♡♡→♡℃※留言 2021年7月28日 (三) 00:16 (UTC)

公示公告的后续讨论

• 公示期过后才出来反对，实属扰乱，而且，有一些用户会把站务公告（客栈顶部的）贴在自己的用户页上，再者，反对者不会没有和前述人士进行交流，所以没有任何理由不知道。--MCC214（Sign | Contributions） 2021年7月26日 (一) 10:02 (UTC)。
  • 想吐槽的是这种公示方法，贴出来就要公示且没贴在布告板，结果没半个人留言，并非反对提案，谢谢-- Sunny00217  2021年7月26日 (一) 11:33 (UTC)
    • Sunny00217显然就是没看公告，提案于7月10日已经发出公示公告。--虫虫飞♡♡→♡℃※留言 2021年7月26日 (一) 11:46 (UTC)
      • 虫虫飞胡来，怎么可以用旧的公示项目（7月10日）来公示新的东西（7月17日）？！还怪我没看公告？！-- Sunny00217  2021年7月27日 (二) 01:09 (UTC)
      • 7月10日号开始公示，7月24日才结束，新提案只有简单修饰，没有重大修改，而且已经重新公示了七天，前后共公示十四天；提案已经比其他人的提案多公示七天。--虫虫飞♡♡→♡℃※留言 2021年7月27日 (二) 02:51 (UTC)

        可惜没法假设修订版已经取得共识。--Bookwith（留言） 2021年7月27日 (二) 04:52 (UTC)

        公示期间没有反对意见，就是通过，几乎所有维基都是这样。--虫虫飞♡♡→♡℃※留言 2021年7月27日 (二) 05:09 (UTC)

        你把上面那个关了然后重开一个不认为可以直接沿用旧的公示项目-- Sunny00217  2021年7月27日 (二) 10:42 (UTC)

• 中间的提案关不关与修订后的提案的公示无关，而且提案已经公示十四天，已经比方针要求七天更高，您自己在公示期间放弃讨论，而且不看公示公告，这是您自己的问题。--虫虫飞♡♡→♡℃※留言 2021年7月27日 (二) 10:54 (UTC)

  沿用原有的公告已经有问题了。--Bookwith（留言） 2021年7月27日 (二) 16:03 (UTC)

• 公示公告已经发出十四天，但您十四天都不出来讨论，这也是您自己的问题。--虫虫飞♡♡→♡℃※留言 2021年7月27日 (二) 16:35 (UTC)

• 议案得不到大家的关注，还能视作通过吗？究竟是各位放弃讨论，抑或是没人知悉修订后的提案？答案你心中有数。--Bookwith（留言） 2021年7月27日 (二) 16:21 (UTC)

• 大家都在关注，只是您一个人没关注公告内容和客栈的讨论，而且提案已经按照方针规定完成公示１４天，但是您在公示期间放弃讨论，这是您自己的问题；这就像假设ＲＦＡ期间您忘记投票，然后投票期结束了，您才出来闹，这也是您自已的问题。--虫虫飞♡♡→♡℃※留言 2021年7月27日 (二) 16:25 (UTC)

  虫虫飞声称大家都在关注，却出现7天公示期内无人讨论的局面，请问这合理吗？难道没人提出意见还能视作通过？--Bookwith（留言） 2021年7月27日 (二) 17:26 (UTC)

• 提案没异议，就是通过了，一向都是这样呀!--虫虫飞♡♡→♡℃※留言 2021年7月28日 (三) 00:19 (UTC)

@Sunny00217：公告栏同类通知应当合并。-- ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年7月27日 (二) 16:12 (UTC)

• (！)强烈抗议有心人士企图翻案！ 完全不认为目前的通过有任何问题，无疑是在恶意找碴。-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鲜果茶☕]（☎️·☘️） 2021年7月26日 (一) 15:17 (UTC)

---

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

关于权限的疑问

检视防滥用过滤器非公开详细资料存取日志 (abusefilter-privatedetails-log)这个权限具体的作用是什么？除了详细资料存取日志，还有什么样的资料存取会被记录？存取“检视防滥用过滤器非公开详细资料存取日志”是会被记录的吗？什么样的权限可以看到“存取‘检视防滥用过滤器非公开详细资料存取日志’日志”？--Papayatrash｛留言｝ 2021年8月1日 (日) 13:04 (UTC)

找mw看啊（mw:Extension:AbuseFilter），再不行去en或mw问啊。有可能AF还有一些类似CU的隐藏数据日志，所以和CU数据一样对等。——Sakamotosan路过围观杯弓蛇影 | 避免做作，免敬 2021年8月1日 (日) 13:24 (UTC)

英文不好啊--Papayatrash｛留言｝ 2021年8月1日 (日) 13:34 (UTC)

没有隐藏数据日志，管理员看到的和回退员看到的是一样，管理员只是可以修改。--虫虫飞♡♡→♡℃※留言 2021年8月1日 (日) 13:41 (UTC)

@蟲蟲飛：这权限只有cu有--Papayatrash｛留言｝ 2021年8月1日 (日) 13:46 (UTC)

[1]-- Sunny00217  2021年8月1日 (日) 13:42 (UTC)

有看没有懂--Papayatrash｛留言｝ 2021年8月1日 (日) 13:50 (UTC)

延伸确认权限后续讨论 part2

已解决：

优化案已公示七天通过。

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

---

于Phabricator查看
编号T287322的任务

回退相关方针编辑：

• 就人事任免投票资格调整部分，有关公告并未对“人事任免投票资格调整”这类重大事件有任何提及。
• 就扩展用户级别部分，个人认为上述讨论并未达成非常显著共识。--DreamerBlue（留言） 2021年7月29日 (四) 01:56 (UTC)

@Xiplus、Lanwi1：这情况需要处理一下。SANMOSA _Σουέζ 2021年7月29日 (四) 02:50 (UTC)

(！)意见:程序上没问题，公示期没有反对意见，已经通过了；而且提案由始至终都有大量支持。--虫虫飞♡♡→♡℃※留言 2021年7月29日 (四) 03:27 (UTC)

(！)强烈抗议有心人士企图翻案！ 完全不认为目前的通过有任何问题，无疑是在恶意找碴。--(！)强烈抗议有心人士企图翻案！ 完全不认为目前的通过有任何问题，无疑是在恶意找碴。-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鲜果茶☕]（☎️·☘️） 2021年7月29日 (四) 03:53 (UTC)

本人主要是注意到，就人事任免投票资格调整部分，有关公告并未对“人事任免投票资格调整”这类重大事件有任何提及，这意味着整个公示存在一个瑕疵。本人的想法也是(＋)支持该案，希望能让该案重新公示通过。--DreamerBlue（留言） 2021年7月29日 (四) 03:56 (UTC)

(！)强烈抗议有心人士企图阻止翻案！ 完全认为目前的通过有严重问题，无疑是在恶意隐瞒问题。 --(！)强烈抗议有心人士企图阻止翻案！ 完全认为目前的通过有严重问题，无疑是在恶意隐瞒问题。 --Yining Chen（留言|签名） 2021年8月5日 (四) 11:37 (UTC)

@蟲蟲飛、A2569875：不好意思，但我希望两位能留意上方确实有多个对提案本身的强烈反对意见，我不认为相关反对意见小到可以被忽略。SANMOSA _Σουέζ 2021年7月29日 (四) 03:58 (UTC)

另外，容许我在这里表达我对整个提案（包括对“人事任免投票资格”的调整）的反对意见，我认为上方的反对意见的理由合理。SANMOSA _Σουέζ 2021年7月29日 (四) 03:58 (UTC)

你根本就不明白我被LTA:X43与LTA:114.27联手打到快要死掉的痛苦。长期各种乱搞，我都快精神崩溃了，现在连这个曙光都要封掉，烂死了！ 烂死了！ 烂死了！ 烂死了！ 烂死了！-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鲜果茶☕]（☎️·☘️） 2021年7月29日 (四) 04:00 (UTC)

我认为提升自动确认用户的门槛比较实际可行。我不相信他们能熬30日或90日。SANMOSA _Σουέζ 2021年7月29日 (四) 05:45 (UTC)

不要小看X43，他用账号会刻意观察反破坏动向微调编辑行为，导致社群无法辨认出他是X43（已有多次这样的例子，每次都让我焦虑到死掉）；而若只用50次（就算提高到100次也没用）的自动确认用户门槛，他很容易就能继续破坏，且只有50-100次编辑若用X43式的奸诈狡猾心机之“刻意观察反破坏动向微调编辑行为”阻碍社群判断他是傀儡（见Ahri6279这只傀儡就是这类行为）根本不会露出马脚，而若用500次延伸确认保护，一来，在他逐渐接近500次编辑纪录的过程中会比只有50-100次的编辑纪录有更多样本能分析是否露马脚，进而在达到500次编辑前成功封禁他的傀儡，而达到相关条目（500次进阶确认保护）保护的效果。—- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鲜果茶☕]（☎️·☘️） 2021年7月29日 (四) 06:23 (UTC)

@A2569875：容许我recall用户权限的取得门槛：自动确认用户的门槛是注册满7日并同时编辑满50次，延伸确认用户的门槛是注册满90日并同时编辑满500次，也就是说就算一个用户满足了编辑次数的要求，他还是需要等到注册后的一段固定的时间才能取得相关门槛。我这里说的“提升自动确认用户的门槛”不只是提升编辑次数的要求，也包括提升注册满N日的日数要求。SANMOSA _Σουέζ 2021年7月29日 (四) 06:42 (UTC)

你太小看X43了；你根本不了解X43，你也根本不了解我被X43搞到快要死掉的心情，被他搞到精神科都不知道去挂号多少次了；他躲/假装正常编辑半年以上的号多的是；建议你回避。—- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鲜果茶☕]（☎️·☘️） 2021年7月29日 (四) 06:45 (UTC)

那我只能说用延伸确认保护应付X43也不是长久之计，因为他终有一天也会适应新的编辑模式。当然，如果你说注册满90日并同时编辑满500次的用户不会被自动授予权限，而是还是需要先去权限申请页面申请权限的话，那用延伸确认保护应付X43则是合理的。你需要考虑这点。SANMOSA _Σουέζ 2021年7月29日 (四) 06:53 (UTC)

@A2569875。SANMOSA _Σουέζ 2021年7月29日 (四) 05:52 (UTC)

本人认为Tokisaki Kurumi的支持意见有说服力，另外希望各位能注意Lopullinen的意见。--DreamerBlue（留言） 2021年7月29日 (四) 04:02 (UTC)

@DreamerBlue：那原本的提议修改也是不恰当的，因为如果条文只在Lopullinen的情境实施，相关条文需要限制延伸确认保护的适用对象为模板空间和模组空间的页面。如果能限制延伸确认保护的适用对象为模板空间和模组空间的页面，并将CGroup与其他适合实施延伸确认保护的受模板保护页面改用延伸确认保护，那我会支持如此提案。SANMOSA _Σουέζ 2021年7月29日 (四) 05:52 (UTC)

能否说下您为何坚持仅让扩展保护适用于模板和模组？--ときさき くるみ 2021年7月29日 (四) 06:32 (UTC)

因为这是Lopullinen的提案，如果连带其他东西也适用的话，那个就不是他的提案，而需要当成另一个提案分开考虑。我现在之所以反对整个提案是因为虫虫飞声称现在的提案（什么也能用的提案）是我的提案，但我一开始的提案就只打算将延伸确认用户权限用于判别人事任免投票资格。SANMOSA _Σουέζ 2021年7月29日 (四) 06:42 (UTC)

好的，知道了。--ときさき くるみ 2021年7月29日 (四) 07:42 (UTC)

（编辑冲突 × 4） 吐槽@Sanmosa：我在三天就已经问过了，见上方（另外删除已经存档的讨论内容）。-- Sunny00217  2021年7月29日 (四) 04:02 (UTC)

(※)注意:两次的提案后续讨论都是提到有用户没注意到提案，但并非反对提案，因此提案的共识是明显，可以以“后续讨论”的形式让社群注意一下通过的提案内容也好。--虫虫飞♡♡→♡℃※留言 2021年7月29日 (四) 04:15 (UTC)

@蟲蟲飛：你有认真阅读吗？Sanmosa很明显是反对的。-- Sunny00217  2021年7月29日 (四) 04:18 (UTC)

延伸确认权附带投票权是Sanmosa提出的，您为什么会认为Sanmosa会反对自己提出的提案呢？DreamerBlue上面也说他支持提案，您之前那个后续讨论也说您“不反对”--虫虫飞♡♡→♡℃※留言 2021年7月29日 (四) 04:22 (UTC)

我说Sanmosa很明显是反对的，为什么会有您之前那个后续讨论也说您“不反对”？！-- Sunny00217  2021年7月29日 (四) 04:25 (UTC)

想吐槽的是这种公示方法，贴出来就要公示且没贴在布告板，结果没半个人留言，并非反对提案，谢谢-- Sunny00217 2021年7月26日 (一) 11:33 (UTC)

那句话如果是在说我的话，我完全没说过我“不反对”提案，甚至我在2021年6月28日 (一) 00:23 (UTC)以后就没有在那个讨论串留过言。SANMOSA _Σουέζ 2021年7月29日 (四) 05:45 (UTC)

• (※)注意:延伸确认权附带投票权是Sanmosa提出的,然后其他人支持，而且在公示期没有反对意见下通过的。--虫虫飞♡♡→♡℃※留言 2021年7月29日 (四) 05:57 (UTC)

  这样的话确实和模板保护有点重复。我有个反建议：延伸确认保护可以拿来处理人事任免投票资格。@Lanwi1。SANMOSA Σουέζ 2021年6月27日 (日) 01:18 (UTC)

  我认为当时其他人反对我那个提议，或至少并无对我那个提议表示支持。整个讨论除了我自己和明确不赞同我的提议的人以外，所有人都只在讨论编辑战或LTA的问题。SANMOSA _Σουέζ 2021年7月29日 (四) 06:01 (UTC)

  • 当时很多人支持您的提议，如我和宇帆都大力支持，然后在公示14天期间完全没有反对下通过。--虫虫飞♡♡→♡℃※留言 2021年7月29日 (四) 06:05 (UTC)

    看漏了，我能确定你和他当时是支持我的提议的，但要注意的一点是我的提议是仅将延伸确认用户权限用于判别人事任免投票资格（而且还是要把延伸确认用户权限的获取资格设定为人事任免投票资格）。而且，就算是仅将延伸确认用户权限用于判别人事任免投票资格的提议，除了你们两个外，就只有Lanwi1和Xiplus就此表达过意见，而他们两个都是反对我的提议的，而且反对理由充分，因此也看不到有将延伸确认用户权限用于判别人事任免投票资格的共识。把你们四个和我自己排除后，就真的没人对我那个提议表示任何意见（包括支持意见）了，我认为应该理解成他们对我的提议不屑一顾。A2569875现在所希望做到的东西（处理LTA）并不是我一开始提议的东西。SANMOSA _Σουέζ 2021年7月29日 (四) 06:13 (UTC)

• • Lanwi1和Xiplus是觉得单纯以您的建议作为理据去引入这个权限是不好，然后大家都围绕这个话题去讨论，包括防lta等理据，然后公示期，Lanwi1和Xiplus都没再反对，而且在sunny 上面的“后续讨论”中，Lanwi1还明确表示(＋)支持。--虫虫飞♡♡→♡℃※留言 2021年7月29日 (四) 06:19 (UTC)

    Xiplus的情况应该理解为他对原提案本身并没有任何的意见，那自然也不包含支持意见。Lanwi1方面我同意你的解读。但就算如此，原讨论串里确实存在明显的反对意见，我确实看不出来你有进行妥善处理。SANMOSA _Σουέζ 2021年7月29日 (四) 06:30 (UTC)

    “原讨论串里确实存在明显的反对意见”，除了提案通过几天后出来闹的，哪个用户是反对的？只有Yining Chen是提出反对，但在第二稿已经根据他的意见优化提案，而且他在第二稿公示期没再反对。此外，我看到您已经过去phab那边反对，我建议在下面优化提案，以形成更明确的共识，而且不建议过去那边争论，否则洋人觉得中维很乱，影响将来其他提案的申请。--虫虫飞♡♡→♡℃※留言 2021年7月29日 (四) 07:05 (UTC)

虫虫飞修改此讨论的名称，由“延伸确认权限争议 part2”改为“延伸确认权限后续讨论 part2”[2]，我不太赞成这样的修改，标题是反映原来开始此一讨论者的看法，不太确定目前的修改是反映了谁的看法？若只是修改者的看法，我是否也可以修改此一标题，再改为我的看法？--Wolfch (留言) 2021年7月29日 (四) 04:24 (UTC)

其实讨论最早的标题是“设置新的保护类型”（原始标题），并复制已存档的部分，在下删掉了存档部分并改成“延伸确认权限争议 part2”-- Sunny00217  2021年7月29日 (四) 04:27 (UTC)

DreamerBlue本来的标题是“后续讨论”，是sunny改为“争议”的，我觉得提案人原先的标题较佳。--虫虫飞♡♡→♡℃※留言 2021年7月29日 (四) 04:29 (UTC)

那我没有意见--Wolfch (留言) 2021年7月29日 (四) 04:48 (UTC)

---

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

优化提案

已通过：

提案已讨论两个月，优化提案已再次公示七天，获得绝大多数使用者支持，包括：A2569875、DreamerBlue、Lanwi1、Tokisaki Kurumi、Jonathan5566 、Sidishandsome、MCC214、LuciferianThomas、Eric liu、Newbamboo、30000lightyears、Sammypan、A1Cafel、CreeperDigital1903 等。

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

---

提案虽然已经通过，但有用户有疑虑，我建议可以把已经过的提案再优化，以形成更明确的共识，欢迎大家提出优化建议，已经通过的提案如下：

Wikipedia:用户权限级别#延伸确认使用者（非方针指引）［分案A］

现行条文	提议条文 一个已注册的用户会在注册达90天并编辑达500次后自动获得此权限。该用户权限允许用户编辑受到进阶确认保护的页面。机器人以及管理员都自动拥有此权限。

Wikipedia:保护方针#延伸确认保护［分案B］

现行条文	提议条文 延伸确认保护 延伸确认保护仅允许延伸确认使用者编辑，该使用者群组会在注册达90天并编辑达500次时自动授予给注册使用者。 管理员仅能在页面已被半保护，且证实半保护仍无法阻止破坏或编辑战的页面上使用延伸确认保护。与半保护相同，不得对尚未发生的破坏或编辑战进行预见性保护。亦不得将延伸确认保护使用于破坏或编辑战以外的页面上，应直接使用全保护（对于模板或模组可用模板保护）。

Wikipedia:人事任免投票资格［分案C］

现行条文 解任投票联署提出或上任投票开始1个月前，编辑100次或以上；并在联署提出或上任投票开始前3个月内至少有1次编辑（不包括任何用户页及用户对话页）； 编辑3000次或以上，或编辑1500次条目或以上。

提议条文 解任投票联署提出或上任投票开始120天前，编辑至少500次；并在联署提出或上任投票开始前90天内至少有1次编辑（不包括任何用户页及用户对话页）； 编辑至少3000次，或编辑条目至少1500次。

以上。--虫虫飞♡♡→♡℃※留言 2021年7月29日 (四) 06:58 (UTC)

• 如果延伸确认引入后，可以参考英维降低自动确认的门槛，这部分可以一并讨论。~~Sid~~ 2021年7月29日 (四) 07:12 (UTC)

  反对降低自确门槛。目前自确门槛已经非常低了。--Lightyears _GBAW 2021年7月29日 (四) 09:19 (UTC)

需要添加延伸确认用户组吗？（指确认使用者这种）--Papayatrash｛留言｝ 2021年7月29日 (四) 07:26 (UTC)

@Jonathan5566：日维那边是可以由管理员授权，也可以移除，您希望像日维那边的做法吗？--虫虫飞♡♡→♡℃※留言 2021年7月29日 (四) 07:31 (UTC)

可以提出几点意见：

1. 反对系统自动特许的设置，应该要求用户自行请求授权（这应该是你理解的“像日维那边的做法”）；
2. “账号已注册1个月”过短，真的要实施的话应该维持原提案的90日；
3. 延伸确认权保护应容许用于高风险页面保护（描述可以参考enwiki和Lopullinen的意见，不过我不会当成是Lopullinen的提案）；
4. 基于1，反对连锁修改人事任免投票资格；

以上。SANMOSA _Σουέζ 2021年7月29日 (四) 08:09 (UTC)

(：)回应

1. 日维那边的做法是系统自动授权，但可以按实际需要申请，但这个是有问题，因为延伸确认应是经过长时间贡献而获得的，而不是申请的，而且会加重管理员负担。
2. 这个可以再讨论。
3. 原提案没反对用在模板。
4. 已经通过的提案不宜推翻，但可以讨论优化，而且延伸确认权附带投票权不是您自己提出的吗？

以上。--虫虫飞♡♡→♡℃※留言 2021年7月29日 (四) 08:42 (UTC)

（1）如果打算要用延伸确认权限防治LTA，那系统自动授权就会使延伸确认权的保护力受严重削弱，因为LTA可以掌握新的权限的取得模式（这点我是就A2569875描述的LTA特征而提出的），而且并不是所有用户都热衷于高级权限。如果真的会加重管理员的负担，那就只能让更多适任的人担任管理员。（4）zhwiki有（局部）推翻已通过提案的先例，而且我也可以选择收回提案（这也不是我第一次收回自己的提案），反正相关条文已经被回退掉了，我觉得没分别。SANMOSA _Σουέζ 2021年7月29日 (四) 08:59 (UTC)

您提出那个案例是一个非常坏的先例，不建议动辄推翻已通过的提案；此外延伸确认权通过后，能获得权限的人一定很多，不应搞得太复杂。--虫虫飞♡♡→♡℃※留言 2021年7月29日 (四) 09:50 (UTC)

一般的申请权限的程序应该不复杂。能获得权限的人（有权者）多不代表申请并使用权限的人（行权者）也多。SANMOSA _Σουέζ 2021年7月29日 (四) 13:38 (UTC)

这个权限有别于其他权限，简单来说就是编辑权，就如“自动确认权”，如果管理员也可以取消，就很可怕了。--虫虫飞♡♡→♡℃※留言 2021年7月29日 (四) 13:59 (UTC)

在我的理解中，模板编辑员的权限也是一种编辑权，但管理员依现行方针也是可以取消的。SANMOSA _Σουέζ 2021年7月29日 (四) 14:21 (UTC)

模板编辑员是一种管理员全保护权限下放给有限使用者的替代方案，必须非常可信，所以自从模板编辑员引入后，大量高危页面就由全保护改为模板保护。但延伸确认是一个资历性质的权限，有点像自动确认的延伸。英维也不会由管理员授权，也不会由管理员除权，也没必要。--虫虫飞♡♡→♡℃※留言 2021年7月29日 (四) 14:35 (UTC)

了解。但我的想法与你的想法的不同之处在于：我认为延伸确认权限也是一种权限下放，一来既然要把这权限用于防治LTA，就应该要排除任何授权予LTA的机会，因此应该只有可信用户才能获得权限（但不需要如模板编辑员的权限般非常可信），不然就会有让LTA取得权限并在脆弱的“保护”中持续破坏的机会；二来部分现在施行模板保护的高危页面会因启用延伸确认权限而再改为延伸确认保护，我认为情况某程度上与模板编辑员类近。如果真的担忧取消编辑权的问题，可以规定延伸确认权限只有在用户为破坏者的情况下方可移除，其他情况（包括可导致封锁的情况）都不能，并规定违反该规定移除用户的延伸确认权限的管理员可以被任何用户提出紧急除权，而不需要经过除权投票（但如果这样的方针通过了，需要知会meta一声，因为他们也要看zhwiki本地的规则处理）。SANMOSA _Σουέζ 2021年7月29日 (四) 14:54 (UTC)

延伸确认权不是一个由管理员主观判断，然后授权的权限，而是经过积累经验，系统自动授权的。而LTA如果真要三个月去获取这个权限，一旦被发现就是永封。此外，用户滥用此权限是封锁，而不是除权，正如现在假如一个用户破坏，是封锁，而不是移除自动确认权。维基的编辑权的意义是非常大的，当此权限的相应保护引入后，意味可能有为数不少的条目被延伸保护，因此应该让没破坏该条目的权限拥有者，仍然有编辑权。--虫虫飞♡♡→♡℃※留言 2021年7月29日 (四) 15:15 (UTC)

你之所以说“延伸确认权不是一个由管理员主观判断，然后特许的权限，而是经过积累经验，系统自动特许的”是因为你自己的提案如此设定而已，可见权限是自动授权还是人手授权完全是看实际规范的方针的规定。既然现在大家就在讨制定有关新权限的方针，那新权限是自动授权还是人手授权自然是可以讨论的。因此，我不会说你的主张完全不能提出来，但我不会把你的主张直接当成“事实”来看待。SANMOSA _Σουέζ 2021年7月30日 (五) 08:31 (UTC)

此外，要注意的是这个权限是要配合“延伸保护”，而“延伸保护”只有在半保护无法阻止的破坏或编辑战时才能施行，那么用户可以有什么充份理据去申请此权限去绕过“延伸保护”？如果“延伸保护”可以被轻易绕过，这个保护的作用就大大减低了。--虫虫飞♡♡→♡℃※留言 2021年7月30日 (五) 08:42 (UTC)

正是因为希望保证“延伸保护”不被LTA轻易绕过，所以我才主张应该人手授权。基本上在权限申请页面，很多人在那边很容易表露自己申请权限的真正目的，我们可以从中判别哪些是LTA为了进行（秘密的）破坏而申请权限的。而且，也有鉴于管理员在处理授权时有一定的灵活性，我们也很容易从中判别哪些是用户为了维持自己所主张的页面版本而申请权限的。SANMOSA _Σουέζ 2021年7月30日 (五) 08:47 (UTC)

根据Sanmosa的意见修改了提案。至于完全由管理员授权的建议，由于管理员人手不足，要等到中维管理员数达到像英维那样超过1000,才有足够人手处理。--虫虫飞♡♡→♡℃※留言 2021年7月30日 (五) 09:56 (UTC)

临时权限有用吗？设立目的为何？--Bookwith（留言） 2021年7月30日 (五) 18:11 (UTC)

原则上管理员不应授权，考虑到用户如果有非常充分的理据下，才可以临时授予，而且延伸保护通常不会永久。--虫虫飞♡♡→♡℃※留言 2021年7月31日 (六) 00:24 (UTC)

所谓的“非常充分的理据”到底是什么？我想不到有任何合理的情形需要人手授权。--Bookwith（留言） 2021年8月1日 (日) 07:45 (UTC)

例如您已经有相关权限，但您想用小号编辑受保护的条目，或者客栈被保护了，您是新手，想到求助区求助等都是合理理由。--虫虫飞♡♡→♡℃※留言 2021年8月1日 (日) 08:25 (UTC)

虫虫飞：我不相信互助客栈会应用到延伸保护。至于前面的情况，根本就不该申请。--Bookwith（留言） 2021年8月2日 (一) 19:08 (UTC)

第一个情况较少，但确实有LTA突破自动确认门槛继续破坏，见第一次讨论内容。第二个情况与现时用户为小号申请确认用户的情况相似，这不是该不该的问题，而是用户的选择权。--虫虫飞♡♡→♡℃※留言 2021年8月3日 (二) 00:19 (UTC)

(＋)支持90日注册条件，对人事任免投票资格的修改表示(＝)中立。--Lightyears _GBAW 2021年7月29日 (四) 09:23 (UTC)

如果是要管理员可以自由移除的话可以写一只机器人自动授权（但host的人的服务器压力会非常大）？-- Sunny00217  2021年7月29日 (四) 11:50 (UTC)

• 英维那边是系统自动授权，这个权限其实是自动确认的延伸版，而且如果管理员滥权，无理移除用户权限，也有问题。--虫虫飞♡♡→♡℃※留言 2021年7月29日 (四) 12:12 (UTC)

虫虫飞认为已通过的提案不适宜推翻，我倒是反对。这个提案即使优化，也不会带来显著的改变──我依然对提案没有好感。--Bookwith（留言） 2021年7月29日 (四) 14:49 (UTC)

如果您有什么意见，也可提出，让提案更加优化。--虫虫飞♡♡→♡℃※留言 2021年7月29日 (四) 15:19 (UTC)

根据30000lightyears和Sanmosa意见改为“3个月”--虫虫飞♡♡→♡℃※留言 2021年7月29日 (四) 09:38 (UTC)

“3个月”的长度是不固定的，建议写成“90日”，但对此条的大意无意见。SANMOSA _Σουέζ 2021年7月29日 (四) 09:40 (UTC)

根据Sanmosa意见修改为“90日”。--虫虫飞♡♡→♡℃※留言 2021年7月29日 (四) 09:44 (UTC)

• (！)意见人事任免方面，由于管理员审批受主观因素影响，建议还是通过硬性的编辑数注册时间来确定。 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年7月29日 (四) 12:54 (UTC)

(✓)同意:英维那边也是系统自动授权。--虫虫飞♡♡→♡℃※留言 2021年7月29日 (四) 13:07 (UTC)

• (！)意见：还是觉得把这两件绑一起是错误的决定。--Papayatrash｛留言｝ 2021年7月30日 (五) 04:01 (UTC)

• 您的理据是什么?没记错，英维的投票权就是延伸确认用户，中维没cu，RFA等傀儡投票过去也是有的，现时刷傀儡投票账号太容易了，而且某个lta整天在教人改ua，刷投票傀儡，已经让全站的人都懂得改ua规避cu去刷傀儡投票了，这个问题您觉得可以怎样解决?--虫虫飞♡♡→♡℃※留言 2021年7月30日 (五) 04:14 (UTC)

  假设由管理员授权，道德太有弹性了。且管理员可以控制投票者，这事本身就有问题。“人事任免由于管理员审批受主观因素影响，建议还是通过硬性的编辑数注册时间来确定。”但反破坏的角度来说，应该由管理员授权，这样可以某种程度防范LTA。所以这两件事情不应缠在一起。--Papayatrash｛留言｝ 2021年7月30日 (五) 06:15 (UTC)

• 已经根据您的意见，修改了提案。--虫虫飞♡♡→♡℃※留言 2021年7月30日 (五) 10:03 (UTC)

  括号请改全形，提案本身(＋)赞成。--Papayatrash｛留言｝ 2021年7月30日 (五) 11:52 (UTC)

  建议改为“……1个月前，已被系统自动赋予延伸确认权限” ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年7月30日 (五) 12:32 (UTC)

  根据羊羊32521意见，修改了提案。--虫虫飞♡♡→♡℃※留言 2021年7月30日 (五) 13:08 (UTC)

整体上(＋)支持此提案，但如果将“解任投票联署提出或上任投票开始1个月前，已被系统自动赋予延伸确认权限”改成“解任投票联署提出或上任投票开始30天前，已被系统自动赋予延伸确认权限”；“联署提出或上任投票开始前3个月内至少有一次编辑”改成“联署提出或上任投票开始前30天内至少有一次编辑”就更好了，因为一个月可以有28/29/30/31天的，清楚说明天数可以减少争拗，另“联署提出或上任投票开始前3个月内至少有一次编辑”好像不能有效提升维基人的积极性（三个月就才来一次，之后又不上来）。--MCC214（Sign | Contributions） 2021年7月30日 (五) 15:57 (UTC)

现在还来谈收紧资格限制。--Bookwith（留言） 2021年7月30日 (五) 18:05 (UTC)

我也认为可以暂时不再进一步收紧，延伸确认权限已经是合理要求。--虫虫飞♡♡→♡℃※留言 2021年7月31日 (六) 00:24 (UTC)

根据mcc214意见，把“一个月”改为“30天”。--虫虫飞♡♡→♡℃※留言 2021年7月31日 (六) 00:30 (UTC)

干脆顺便把其他方针指引的半年、六个月也一起以同样理由改成180天算了-- Sunny00217  2021年7月31日 (六) 04:52 (UTC)

您自己可以另行提出嘛。--MCC214（Sign | Contributions） 2021年7月31日 (六) 13:43 (UTC)

虽然先前有人同意人事任免投票资格可以采用延伸确认，但没有人说明为何要（实质）提高人事任免投票资格的门槛？--Xiplus#Talk 2021年7月31日 (六) 13:45 (UTC)

那是因为过去RFA都有傀儡，而且现在的门槛确实太低，容易刷投票权。最近某个LTA也在整天教人如何改ua和刷投票权傀儡，这个问题也得解决。--虫虫飞♡♡→♡℃※留言 2021年7月31日 (六) 13:51 (UTC)

似乎确实没有人说明为何要提高人事任免投票资格。个人调查了过去5次RFA，考虑到近期的某些RFA支持票数显然不属于正常范围（基本属于可以列入维基百科之最的范畴），且也受到了傀儡的干扰（例如CRHK128、South Africa No.1曾干扰管理员投票），我不反对提升人事任免投票资格。--DreamerBlue（留言） 2021年7月31日 (六) 13:52 (UTC)

你们想要提高人事任免投票资格应分案提出，而不是绑定延伸确认权限一案，虽然某项资格要求某一权限这件事没有问题，但前提是那个权限的资格已被确实设立，因此像7月17日通过人事投票资格参考一尚未正式确定门槛的权限这一严重的程序瑕疵，通过提案之人未能察觉，也未有人指出问题。我感到相当惊讶。--Xiplus#Talk 2021年7月31日 (六) 14:27 (UTC)

给你们两个选择， 1. 先确立延伸确认后，再开始讨论人事任免投票资格。 2. 现在另案人事任免投票资格，其资格不援引延伸确认。--Xiplus#Talk 2021年7月31日 (六) 14:29 (UTC)

首次讨论我就已经提出过，反对以人事任免投票资格为理由设立该权限，现在的投票资格就没有援引任何权限，你们改成另一个没有援引权限的门槛没有问题。至于延伸确认用于反破坏我没意见，我没有同意设立，但以这点设立没有问题，另外请把正式提议条文拿出来，而不是现在上方那个口语化的东西。--Xiplus#Talk 2021年7月31日 (六) 14:34 (UTC)

提案之前虽然已经通过，但您看我还没改方针，因为我本来想等到延伸确认权限通过才改方针；之前模板编辑员的申请也是一样，先通过权限申请，然后相关通过的方针才生效,但两者都是同步进行。此外，提案显示的就是正式条文，英文这个权限也是几行字。--虫虫飞♡♡→♡℃※留言 2021年7月31日 (六) 14:49 (UTC)

英文的哪个页面交出来，我看看是不是只有这几个字。--Xiplus#Talk 2021年7月31日 (六) 15:05 (UTC)

这一小段就是英维的延伸确认权限的描述，如果有其他意见想补上去，也可以提出来讨论。--虫虫飞♡♡→♡℃※留言 2021年7月31日 (六) 15:12 (UTC)

那么延伸确认保护的部分呢？--Xiplus#Talk 2021年8月1日 (日) 02:15 (UTC)

延伸确认保护也是头一小段有关，重点也已经写在提案上了，如果有其他意见想补上去，也可以提出来讨论。--虫虫飞♡♡→♡℃※留言 2021年8月1日 (日) 02:22 (UTC)

算了你听不懂的话，我直接改了，多说无益。--Xiplus#Talk 2021年8月1日 (日) 02:57 (UTC)

同样地，“并在联署提出或上任投票开始前3个月内至少有一次编辑”也要改成“并在联署提出或上任投票开始前90天内至少有一次编辑”，另联署的门槛也要考虑作出相应调整。--MCC214（Sign | Contributions） 2021年7月31日 (六) 14:01 (UTC)

这个雪球就好了吧（-- Sunny00217  2021年8月1日 (日) 01:53 (UTC)

根据MCC214意见，修改了提案；联署门槛可以适当时机再讨论，暂时先优化了这个提案。--虫虫飞♡♡→♡℃※留言 2021年7月31日 (六) 14:06 (UTC)

我把上方三部分分成分案A、B、C，大家可以就个别分案分别表达意见。我先说明：反对分案C，支持分案B，观望分案A。SANMOSA _Σουέζ 2021年8月1日 (日) 03:07 (UTC)

(？)疑问：C方案的“解任投票联署提出或上任投票开始……前，编辑500次或以上”的……不是90天么？何时变成4个月（120天）了？--MCC214（Sign | Contributions） 2021年8月5日 (四) 13:07 (UTC)

延伸确认权(3个月取得权限)+1个月=4个月。--虫虫飞♡♡→♡℃※留言 2021年8月6日 (五) 04:19 (UTC)

建议可把所有人事任免投票页（分开讨论和投票）进行延伸确认保护，减低误投的机会。--Wiki emoji | 😷🅔🅜🅞🅙🅘🅦🅘🅚🅘😷 _{祝百毒不侵～} 2021年8月5日 (四) 23:43 (UTC)

不同意保护。假如真的保护的话，实在是太荒谬了。--Bookwith（留言） 2021年8月7日 (六) 17:45 (UTC)

(✓)同意:英维的投票页是延伸确认保护的。--虫虫飞♡♡→♡℃※留言 2021年8月6日 (五) 04:15 (UTC)

那四个月也应该改为120天。--MCC214（Sign | Contributions） 2021年8月6日 (五) 10:46 (UTC)

完成--虫虫飞♡♡→♡℃※留言 2021年8月6日 (五) 11:07 (UTC)

Sanmosa之前的建议

这样的话确实和模板保护有点重复。我有个反建议：延伸确认保护可以拿来处理人事任免投票资格。@Lanwi1。SANMOSA Σουέζ 2021年6月27日 (日) 01:18 (UTC)

把延伸确认资格从500次编辑拉伸到1500次或3000次编辑是可行的，甚至如果技术允许的话，可以让系统自动判别用户是否符合人事任免投票资格，然后为符合资格者自动授权延伸确认用户，授权后不符合资格者自动除权。SANMOSA Σουέζ 2021年6月27日 (日) 02:34 (UTC)

这样做可以直接省去计票审核的程序，因为不符合资格者自己也投不了票。SANMOSA Σουέζ 2021年6月28日 (一) 00:23 (UTC)

@Sanmosa：

(※)注意:分案C“延伸确认权附带投票权”是sanmosa自己提出的，然后虫虫飞和宇帆等人支持，现在他在通过后才说反对自己原先的提案提议，请sanmosa说明理据﹗请注意在共识形成过程中应提出有效理据，而非单纯表态。--虫虫飞♡♡→♡℃※留言 2021年8月1日 (日) 03:31 (UTC)

请你搞清楚，我的用意是把延伸确认用户权限的取得资格设定为原本的人事任免投票资格，而不是把后者提升到前者。我恳请虫虫飞立即停止其歪曲事实的表述。SANMOSA _Σουέζ 2021年8月1日 (日) 03:48 (UTC)

重看留言，似乎是您自己忘了自己的话。您原意是要“1500次或3000次编辑”才获得权限，然后我建议改第一条，然后宇帆等人支持。--虫虫飞♡♡→♡℃※留言 2021年8月1日 (日) 04:06 (UTC)

完全没有这回事。你从一开始提案就曲解了我的意思。宇帆等人支持的是你的提案，但你的提案和我的想法并不相同。SANMOSA _Σουέζ 2021年8月1日 (日) 04:34 (UTC)

应该是说您是最先提出延伸确认权附带投票权，但大家觉得您提出的门槛太高(1500次或3000次编辑才获得权限)，然后我根据您的方案作出修订，然后大家支持。--虫虫飞♡♡→♡℃※留言 2021年8月1日 (日) 04:46 (UTC)

我完全没有这个想法。如果大家以为我有，那就是大家集体误解。SANMOSA _Σουέζ 2021年8月1日 (日) 04:57 (UTC)

无论如何，留言存档大家都能看到。最重要的是，您是最先提出延伸确认权附带投票权，如果您觉得具体的条件太高或太低，大家可以再讨论，以形成共识，而且维基的共识过程不应只作单纯的表态，最重要是说出理据；而且此提案其实已经通过了，考虑到有人说没看公告，或公示公告不清晰，才再讨论再优化方案。--虫虫飞♡♡→♡℃※留言 2021年8月1日 (日) 05:03 (UTC)

Sanmosa没有提出分案C。那不是Sanmosa的提案，请虫虫飞停止曲解。分案C是对门槛的实质提升，我保留反对意见。--Bookwith（留言） 2021年8月1日 (日) 07:40 (UTC)

您误解了上面留言，请重看。而且请不要为反对而反对，请说明您理据!--虫虫飞♡♡→♡℃※留言 2021年8月1日 (日) 07:49 (UTC)

现时的门槛一直没出大问题，也对投票者的经验作出了相当的肯定。没有需要修改。--Bookwith（留言） 2021年8月1日 (日) 07:57 (UTC)

• 可能您没注意，最近的rfa都出现傀儡投票，而且vip也多了刷编辑数的举报，某lta还整天教人改ua刷投票傀儡，这个问题您觉得可以怎样解决?--虫虫飞♡♡→♡℃※留言 2021年8月1日 (日) 08:18 (UTC)

@蟲蟲飛：我的建议是把人事任免投票资格的提升的讨论与这里的讨论分开处理，其实我有一个更大胆的提案。SANMOSA _Σουέζ 2021年8月2日 (一) 06:54 (UTC)

提案已经进行了一个多月，个别用户说没看公告，或者公告不清晰，就要把已经通过的提案推翻；现在延伸确认用户附带投票权的提议也是Sanmosa提出的，通过后走去phab闹的也是samosa您，搞到洋人以为中维很乱。我不认为要这样浪费社群时间和资源。通过的提案其实就不应任意推翻，或者您有什么改善建议，您可以提出来，大家一起讨论，把提案优化，而不是动辄推翻已通过的提案。或者您有什么优化建议，先提出来，大家讨论一下。--虫虫飞♡♡→♡℃※留言 2021年8月2日 (一) 07:05 (UTC)

我和Xiplus的态度一样：“我不承认那是我的方案”，而且这好像也不是我第一次表明我这个态度了。SANMOSA _Σουέζ 2021年8月2日 (一) 07:26 (UTC)

@Sanmosa：您的方案和我的方案是有些不同，但延伸确认权限附带投票权是您最先提出的，您可能连自己说过的话也忘记，我把您说过话的重点贴出来给您看看，您最先的方案是：“有个反建议：延伸确认保护可以拿来处理人事任免投票资格。”“把延伸确认资格从500次编辑拉伸到1500次或3000次编辑是可行的”，但您现在不同意“500编辑”，那您希望怎样优化？还有不同意“500次编辑”的理据是什么？--虫虫飞♡♡→♡℃※留言 2021年8月2日 (一) 07:48 (UTC)

“把延伸确认资格从500次编辑拉伸到1500次或3000次编辑是可行的”的前提是社群真的同时有将进阶确认用户资格与人事任免投票资格绑定和提升人事任免投票资格的共识，那时候由于延伸确认资格=人事任免投票资格，因此“把延伸确认资格从500次编辑拉伸到1500次或3000次编辑”可以做到提升人事任免投票资格的效果。然而我看不到这样的共识，因此我反对绑定。SANMOSA _Σουέζ 2021年8月2日 (一) 13:59 (UTC)

@Sanmosa：简单来说您自己就是没有反对理据，而且一再反悔自己原先的提议(延伸确认权附带投票权)，其实我不明白您在反对什么，而且现在就是除了您和Bookwith在反对，没有人反对，而bookwith没有提出反对理由，而且一直拒绝回应；提案已经获得绝大多数人支持，如果您没有提出有效反对理据，而是单纯表态，而且如果您也不打算提出改善建议，根据WP:共识：“共识不强求一致同意”，那提案就可以视为已经形成共识，稍后公示；但如果您有改善建议，欢迎您提出来，大家再讨论，我也会尽量妥协。--虫虫飞♡♡→♡℃※留言 2021年8月2日 (一) 14:20 (UTC)

我重申一次：我和Xiplus的态度一样：“我不承认那是我的方案”，而且我质疑“提案已经获得绝大多数人支持”的声称的真实性。我现在的底线是不将进阶确认用户资格与人事任免投票资格绑定，以及将人事任免投票资格的调整分开处理，其他我都可以不反对。SANMOSA _Σουέζ 2021年8月2日 (一) 15:08 (UTC)

请您重读上面留言，我上面那句哪里说了“方案”二字，如果您喜欢咬文嚼字，那么“方案≠提议”，至于明确支持提案的人有：A2569875、DreamerBlue、Lanwi1、Tokisaki Kurumi、Jonathan5566 、Sidishandsome、MCC214等，之前支持的有：LuciferianThomas、Eric liu等，这不叫获得绝大多数人支持”，叫什么？此外，“将进阶确认使用者资格与人事任免投票资格绑定”是您最先提出的，您现在反对，理据是什么？上面大家已经讨论过之所以这个权限与投票权绑定，是为了解决RFA的傀儡票问题，这也是您自己在第一次讨论首先提出的，如果反对这个方案，您有什么解决傀儡投票的问题？另一方案是不绑定权限，就是条件和权限的条件是一样的，您看这样有没有问题？--虫虫飞♡♡→♡℃※留言 2021年8月2日 (一) 15:34 (UTC)

我同意分开处理。--Bookwith（留言） 2021年8月2日 (一) 19:29 (UTC)

@Sanmosa：我根据您意见改了，请审阅﹗--虫虫飞♡♡→♡℃※留言 2021年8月2日 (一) 15:54 (UTC)

@Sanmosa：请回应﹗--虫虫飞♡♡→♡℃※留言 2021年8月1日 (日) 04:16 (UTC)

@Lanwi1、Tokisaki Kurumi、A2569875、Sidishandsome、MCC214：邀请上面参与了讨论的人也发表一下意见。--虫虫飞♡♡→♡℃※留言 2021年8月1日 (日) 03:44 (UTC)

这是只邀请一个立场的用户来参与讨论吗？这恰当吗？--Bookwith（留言） 2021年8月1日 (日) 07:33 (UTC)

• ping的上限人数是五个人，而且前期讨论主要是这些人。而且ping不是必须的，用户应该自觉留意客栈的讨论，而且客栈讨论也不是面对几个人，而是面对整个社群。您对xiplus的方案有优化建议吗？--虫虫飞♡♡→♡℃※留言 2021年8月1日 (日) 07:41 (UTC)

  以现在的分案B来说，对有需要用户人手授权是不难的。受影响页面和用户实际上很少。--Bookwith（留言） 2021年8月1日 (日) 07:50 (UTC)

  我不承认那是我的方案。--Xiplus#Talk 2021年8月1日 (日) 10:42 (UTC)

  ping的上限是5个人，但不代表你不能用多次模板-- Sunny00217  2021年8月2日 (一) 01:01 (UTC)

  • ping的上限早就变成10个人了，而且mw:Extension:Echo允许一笔编辑提及50个人。 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年8月2日 (一) 15:32 (UTC)

    草，还是ccf改的-- Sunny00217  2021年8月3日 (二) 12:27 (UTC)

好吧，提案大家都给了意见，说是谁的不重要，这是xiplus修订差异:

Special:Diff/66876450--虫虫飞♡♡→♡℃※留言 2021年8月1日 (日) 10:55 (UTC)

@Bookwith：如果把非编辑战的授权条件放宽，您能否接受提案?--虫虫飞♡♡→♡℃※留言 2021年8月1日 (日) 09:10 (UTC)

对于人事任免投票门槛的调整，我认为仍有讨论空间，或者需要评估各种门槛的优劣后再作决定。--Bookwith（留言） 2021年8月2日 (一) 19:24 (UTC)

• 中维没cu，rfa傀儡票和lta整天教人改ua避cu的问题也极为严重，用户举报傀儡刷编辑数的vip举报也越来越多。现在只有您不同意，如果没有更好的建议，就用现在的方案。--虫虫飞♡♡→♡℃※留言 2021年8月3日 (二) 00:27 (UTC)

支持上述三个提案，但现在有一个可能性存在的问题：如果遇上有未符提案一要求的人申请权限，且申请获批之后，及后才被发现进行鬼崇破坏（User:太鲁阁号），那如何应对？--MCC214（Sign | Contributions） 2021年8月1日 (日) 09:51 (UTC)

• 如果是lta，就直接永封，及移除权限;如果是非lta的，就是移除权限，按破坏情节决定封锁期限。--虫虫飞♡♡→♡℃※留言 2021年8月1日 (日) 10:09 (UTC)

  重点是当初的申请是如何获批的。我目前还是想不到有哪些情况需要自行申请权限，虫虫飞在上面回复的“新手想到客栈求助”也不合情理。我较为担心容许人手特许后会出现一些非必要的申请，对提案构成一个漏洞。--Bookwith（留言） 2021年8月2日 (一) 19:18 (UTC)

@Bookwith：我上面的回应是“第一个情况较少，但确实有LTA突破自动确认门槛继续破坏，见第一次讨论内容。第二个情况与现时使用者为小号申请确认使用者的情况相似，这不是该不该的问题，而是使用者的选择权。”如果取消授权，您是否接受方案?--虫虫飞♡♡→♡℃※留言 2021年8月3日 (二) 00:37 (UTC)

如果客栈最终会应用到延伸保护，那么我会反对。至于第二点的部分，我会把它视为“没有真正需要的申请”，不该批准及授权。--Bookwith（留言） 2021年8月3日 (二) 07:09 (UTC)

所以这边会有选择的空间。可以选择全数由系统自动授权，或者是需要权限的全数提交申请。--Bookwith（留言） 2021年8月3日 (二) 07:11 (UTC)

@Bookwith：已经根据您的意见修改了提案，请审阅﹗--虫虫飞♡♡→♡℃※留言 2021年8月3日 (二) 08:06 (UTC)

如果客栈不会应用到延伸保护，那么暂时没有大问题。--Bookwith（留言） 2021年8月3日 (二) 08:14 (UTC)

@Bookwith、Sanmosa：请两位回应我上面的问题﹗--虫虫飞♡♡→♡℃※留言 2021年8月2日 (一) 13:02 (UTC)

我的意思是将分案C完全自本案剥离，并另开新讨论串。SANMOSA _Σουέζ 2021年8月3日 (二) 03:58 (UTC)

• 您的理据是什么？延伸确认权附带投票权是您最先提出，但您一再咬文嚼字，反对您自己提出来的建议，不停纠缠于“方案”的定义，昨天也已经根据您的建议改了提案，但您还是不满意。上面早就回应了您这个意见，提案已经讨论了两个月，已经获得绝大多数人支持，不应该为了个别用户，而浪费社群的时间及资源，而且提案已经根据您的意见优化，如果sanmosa 没有实质理据，请不要为反对而反对，而且这是WP:ONEHANDGIVES:“故意拖延或冗长辩论”。--虫虫飞♡♡→♡℃※留言 2021年8月3日 (二) 04:10 (UTC)

  我同意将分案C完全剥离。分案C与分案A、B属性质完全不同的提案，没有必要捆绑式一并通过。因上方讨论较少涵盖到有关分案C的内容，假如另外一节讨论修订人事任免投票门槛，应可激发更为深入的讨论。--Bookwith（留言） 2021年8月3日 (二) 08:20 (UTC)

• 不认为没关，延伸确认在英维就是投票权，而且分案C早就通过了，没有合理理据不应贸然推翻已通过的提案，而且这是浪费社群时间和资源。如果要推翻，您应另行根据规定规则去提案推翻，而不是自己不喜欢就直接“否定”。中维没有cu，rfa傀儡票和lta整天教人改ua避cu的问题也极为严重，使用者举报傀儡刷编辑数的vip举报也越来越多，这个问题必须要解决。--虫虫飞♡♡→♡℃※留言 2021年8月3日 (二) 09:16 (UTC)

  既然提案性质不同，我希望分开通过。--Bookwith（留言） 2021年8月3日 (二) 12:05 (UTC)

• 请您按既定规则去另行重新提案！此案已经过两个月讨论，早已经通过，现在是讨论怎样优化，而不是个人喜好，而任意否定已经通过的提案，浪费社群资源和时间。如果对提案有什么优化建议，请您提出来讨论。--虫虫飞♡♡→♡℃※留言 2021年8月3日 (二) 12:21 (UTC)
• 反对将C方案剥离重新讨论，已经通过的方案可以优化，但没有必要重新开启新的讨论，少数服从多数是最基本的社区规则。Sammypan（留言） 2021年8月4日 (三) 04:38 (UTC)

三个提案本身就有相辅相承的作用，少了一个都会使到本身所期望的作用大打折扣。--MCC214（Sign | Contributions） 2021年8月4日 (三) 11:45 (UTC)

(＋)支持目前的提案。--Newbamboo（留言） 2021年8月4日 (三) 14:56 (UTC)

(＋)强烈支持本提案。--爬行数码1903 2021年8月8日 (日) 07:39 (UTC)

(＋)支持上述提案。--A1Cafel（留言） 2021年8月8日 (日) 08:32 (UTC)

+1。--MCC214（Sign | Contributions） 2021年8月10日 (二) 10:39 (UTC)

• 修改“人事任免投票资格”请比照2011年Wikipedia:人事任免投票资格/首轮表决及后续投票的先例，“各项表决的有效投票人数必须不少于25票，其结果方为有效。”--Mewaqua（留言） 2021年8月8日 (日) 13:48 (UTC)

• 十年前的做法现在不适用，而且当时没有WP:7DAYS。--虫虫飞♡♡→♡℃※留言 2021年8月12日 (四) 07:08 (UTC)

分案C以中文易读性的角度来看，不觉得有点冗吗？--小过儿（留言） 2021年8月8日 (日) 17:26 (UTC)

@Subscriptshoe9：关于“中文易读性”，有没有改善建议？--虫虫飞♡♡→♡℃※留言 2021年8月9日 (一) 03:38 (UTC)

xiplus已经改善语句。--虫虫飞♡♡→♡℃※留言 2021年8月9日 (一) 03:58 (UTC)

@蟲蟲飛：赞，没意见了。--小过儿（留言） 2021年8月9日 (一) 04:25 (UTC)

重新公示延确三案

此副标题由路西法人 • 留言在2021年8月6日 (五) 03:01 (UTC)补上，以与上方段落分别。

• 提案已讨论两个月，获得绝大多数用户支持，包括：A2569875、DreamerBlue、Lanwi1、Tokisaki Kurumi、Jonathan5566 、Sidishandsome、MCC214、LuciferianThomas、Eric liu、Newbamboo、30000lightyears、Sammypan 等，考虑到有个别用户有疑虑，因此为提案进行了优化讨论，已经处理了极少数的反对意见，而且已根据反对者的建议，进行了适度“妥协”及修订，现在公示七天，如有意见，请尽快提出。--虫虫飞♡♡→♡℃※留言 2021年8月5日 (四) 07:07 (UTC)

• (－)反对。虽然以目前这种情况，无法阻挡历史的车轮前进^{[开玩笑的]}，但仍希望在此阐明本人观点。首先：目前所有有关"延伸保护"的内容都可以使用过滤器实现。可以使用更简单的方法实现，为什么要大费周折，再设立一个用户级别和保护等级？第二，如同本人此前所表明的，新设立用户权限和保护等级无法对现有情况做出任何改善，一些LTA甚至能够绕过CU，一个新用户等级恐怕无法起到任何效果，只能使编辑维基百科的门槛变高，阻挡那些真正想要为维基百科做出贡献的新用户。最后对于该提案本身，首先，若最终确定设立“延展保护”用户等级，希望能够为该权限的持有设置限制，即必须保持一定的活跃度才能够持续保持该权限。其次，如果按照现行方针，很有可能会出现巡查员甚至回退员无法编辑那些被延伸保护的页面，本末倒置，使其很难进行维基百科的维护工作。以上，感谢。--Yining Chen（留言|签名） 2021年8月5日 (四) 10:23 (UTC)

• @Yining Chen：过滤器是不能完全阻挡LTA，例子如LTA千村狐免对客栈的破坏，过滤器的效果都不好。提案其实早于7月24日通过了，现在只是优化提案。上面我只看到您的反对理由，没看到改善建议，您是坚持无论如何都要反对，还是提案根据阁下意见修订后，您愿意接纳提案？如果是后者，希望您能提出改善建议。--虫虫飞♡♡→♡℃※留言 2021年8月5日 (四) 11:24 (UTC)

  @蟲蟲飛：“延展保护”是不是可以由设立一个“阻挡不满足指定条件（编辑次数和时间）的用户编辑指定页面”过滤器来实现？如果可以，为什么要单设用户组？--Yining Chen（留言|签名） 2021年8月5日 (四) 11:29 (UTC)

• @Yining Chen：您上面的建议只有极少数的管理员懂得去操作，我虽然也会用过滤器，但也不懂得用过滤器去代替保护操作，AT也说他不会用过滤器，而且遇到严重破坏时，保护操作比过滤器快很多。--虫虫飞♡♡→♡℃※留言 2021年8月5日 (四) 11:34 (UTC)

  您注意到我所说的内容中“第二“往后的部分了吗？如果没有还希望您能够浏览下。--Yining Chen（留言|签名） 2021年8月5日 (四) 11:41 (UTC)

• @Yining Chen：“第二“往后的部分的问题，早就有人在第一次讨论时讨论过了，半保护门槛太低，有 lta绕个半保护去破坏条目，如果您认为延伸确认权限门槛太低，可以提出来，我会尽量“妥协”，您觉得怎样？此外，“阻挡那些真正想要为维基百科做出贡献的新使用者”的疑虑在上次提案第二公示时已经根据您的意见修订，这个保护只适用于半保护无法阻止的“破坏”和“编辑战”，而且可以减少用“全保护”。--虫虫飞♡♡→♡℃※留言 2021年8月5日 (四) 11:46 (UTC)

  我很诧异您将我的言论理解为“认为权限门槛过低”；并且我稍作寻找，也未能找到此前有价值的讨论（讨论过长，导致看的时候会眼花^{[开玩笑的]}）。--Yining Chen（留言|签名） 2021年8月5日 (四) 11:52 (UTC)

• @Yining Chen：您看漏了我那句前面有“如果”二字，想问一下，您上面说“新设立使用者权限和保护等级无法对现有情况做出任何改善，一些LTA甚至能够绕过CU”，您认为这个权限无法解决破坏等问题，是觉得权限门槛太低，还是什么？此外，如果把权限限定为“半年”，您是否接纳提案？--虫虫飞♡♡→♡℃※留言 2021年8月5日 (四) 12:00 (UTC)
• @Yining Chen：此外，中维回退员的编辑数要1000，比延伸确认权高，英维的回退权反而比延伸确认的门槛低，但没什么问题；至于巡查权，在英维是必须达到延伸确认权，才能申请巡查，我也觉得中维的巡查权申请门槛太低，您可以自行提案提高巡查权限的申请门槛。我上面的问题，您可以回应一下吗？--虫虫飞♡♡→♡℃※留言 2021年8月5日 (四) 12:28 (UTC)

  好，该权限可以有效解决问题，(＋)强烈支持。--Yining Chen（留言|签名） 2021年8月5日 (四) 13:01 (UTC)

不要以为过滤器是万能工具，LTA有一些关键字很常用（部分可以用于模版、模组等），我们不可能全部挡死（除非用一句/一段当一个关键字去挡，但LTA改一两个字就避过了），否则，新手的编辑就会受到很大的阻碍，而LTA将中文改成拼音、英文、注音、同音字、近似字、同义字、近义字、反义字、异体字就避过了，再者，LTA的新花样太多，所以YC，您认为过滤器有用么？--MCC214（Sign | Contributions） 2021年8月5日 (四) 12:56 (UTC)

本人看法同MCC214。过滤器绕开太容易，封锁太死的话假阳性太多。--DreamerBlue（留言） 2021年8月5日 (四) 12:59 (UTC)

我指的是过滤器可以实现和页面保护类似的效果，您可能理解错了。--Yining Chen（留言|签名） 2021年8月5日 (四) 13:06 (UTC)

关注度提报又说可以用过滤器取代半保护，当年我也以为可以，但结果呢？--MCC214（Sign | Contributions） 2021年8月5日 (四) 13:10 (UTC)

当前异议已排除（并改为强烈支持），继续公示至2021年8月12日 (四) 07:07 (UTC)（虫虫飞宣布公示起计七天）。--路西法人 • 留言 2021年8月6日 (五) 03:01 (UTC)

Special:Diff/66955743。--Xiplus#Talk 2021年8月6日 (五) 04:06 (UTC)

延伸确认权(3个月取得权限)+1个月=4个月。--虫虫飞♡♡→♡℃※留言 2021年8月6日 (五) 04:11 (UTC)

@蟲蟲飛：原来是“1个月前，已获得权限”，就是说“1个月前，已经达到延伸确认的标准（注册3个月且500笔）”。现在的方案是“4个月前500笔”，相当于“4个月前，已经达到延伸确认的编辑数标准（500笔）”。这两个不一样，在下认为不能把1月和3月相加。（当然如果社群有意将任免资格提高到这个标准，也是没问题的。）副知@MCC214、Xiplus. ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年8月6日 (五) 23:40 (UTC)

• 其实比原来方案没有提高，3+1或4，其实就是取得权限加一个月就有投票权，英维那边是延确前两月才有投票权。--虫虫飞♡♡→♡℃※留言 2021年8月7日 (六) 00:19 (UTC)
  • 我上面的问题只是为了释除疑虑，本身支持该方案的立场不变。--MCC214（Sign | Contributions） 2021年8月7日 (六) 11:24 (UTC)

  @蟲蟲飛：我觉得不一样。我再解释一下，大家看看我有没有理解错误的地方。假设投票5月1日开始（我就不考虑大小月了）。原方案要求我4月1日的时候注册3个月+500笔，也就是说1月1日已经注册（但不管我当时有多少编辑），4月1日达到500笔。现方案要求我4个月前达到500笔，就是说1月1日已经注册（显然），1月1日达到500笔。所以“达到500笔”的时间从4月1日提前到了1月1日。对方案的支持立场同MCC214。 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年8月7日 (六) 11:40 (UTC)

投票权没要求注册时间，延确才有注册时间要求，所以两种情况的投票权获得的时间是一样的。是有些分别，但改为90天，和原先提案的差异就更大。参考英维的做法，他们投票权也是这样写，但他们要求更高，要500条目空间。--虫虫飞♡♡→♡℃※留言 2021年8月7日 (六) 11:49 (UTC)

抱歉，我不同意120天的要求。这变相是提升了所需要的门槛。另一方面，“500次条目空间”的说法早在7月讨论时已被否定，请停止再度提出。--Bookwith（留言） 2021年8月7日 (六) 17:41 (UTC)

@Bookwith：那么改为90天，即比原先提案“延确1个月前”的要求降低了，您同意吗?请注意：投票权的意义在于用户在一段时间对候选人和社群的观察，而且有足够的活跃度和编辑经验，才能作出客观的评鉴。--虫虫飞♡♡→♡℃※留言 2021年8月8日 (日) 00:16 (UTC)

@MCC214、羊羊32521：两位怎样看？--虫虫飞♡♡→♡℃※留言 2021年8月8日 (日) 02:13 (UTC)

不支持不反对，但希望Bookwith君能提出合理理由。-- ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年8月8日 (日) 13:57 (UTC)

虫虫飞知道“1个月前拥有延伸确认权限”和“120天前编辑500次”之间的分别吗？目前这样已经将门槛大幅度提升了，至少在日数方面可以有所调整。--Bookwith（留言） 2021年8月9日 (一) 14:22 (UTC)

@Bookwith：其实120天已经很低要求，因为才注册几个月，对候选人和维基社群都不认识，无法评鉴候选人是否适任。如果降低到90天呢？您同意吗？--虫虫飞♡♡→♡℃※留言 2021年8月9日 (一) 14:39 (UTC)

到底会不会排版。--Xiplus#Talk 2021年8月9日 (一) 15:12 (UTC)

现在要求120天前编辑至少500次，不是120天前注册。这个应该要考虑清楚。--Bookwith（留言） 2021年8月9日 (一) 18:26 (UTC)

已根据bookwith意见降低门槛为90天。--虫虫飞♡♡→♡℃※留言 2021年8月9日 (一) 23:43 (UTC)

建议Bookwith君提出合理理由。120天已经提出这么久了没有反对意见，降低至90天是不是应该重新通知社群？ ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年8月10日 (二) 00:08 (UTC)

(✓)同意洋洋意见，请bookwith回应他的问题。--虫虫飞♡♡→♡℃※留言 2021年8月10日 (二) 00:58 (UTC)

我还是希望虫虫飞解释当初把“30天前拥有延伸确认”提升为“4个月前编辑500次”背后的原因，或者是谁提议这个修改的。如果我能够得悉这个更改背后的原因，或许能够消除疑虑。--Bookwith（留言） 2021年8月10日 (二) 07:59 (UTC)

那是Sanmosa提出的，原因是我为了形成更明确的共识，对极少数的重要反对意见的一种“妥协”。--虫虫飞♡♡→♡℃※留言 2021年8月10日 (二) 08:09 (UTC)

我没有看见，能引用原话吗？还有请处理好排版。--Bookwith（留言） 2021年8月10日 (二) 11:49 (UTC)

上面一大段“sanmosa原先提议”那章节，您可以看一下，我为了避免重贴太多留言在提案，我把您要的留言贴在您讨论页。此外，请您回应洋洋的问题，不要岔开话题。--虫虫飞♡♡→♡℃※留言 2021年8月10日 (二) 12:06 (UTC)

到底会不会排版，要讲几次。--Xiplus#Talk 2021年8月11日 (三) 01:17 (UTC)

那么我觉得他的发言被曲解了。他没有要求提升投票资格，只是希望将新增新权限的提案与调整投票资格的提案分开处理。我到现在还是不理解设置在120天有什么理由，你设到120天也要有个原因啊。--Bookwith（留言） 2021年8月11日 (三) 17:20 (UTC)

上面早就解释了，这是延确3个月+1的计法。而且请您看看洋洋和其他人的意见。--虫虫飞♡♡→♡℃※留言 2021年8月12日 (四) 00:12 (UTC)

能这样相加的吗？就上方羊羊也有质疑过。--Bookwith（留言） 2021年8月12日 (四) 04:33 (UTC)

他最后澄清了他是支持，而且我之前曾提出根据您的意见修订，但没有人支持您的意见，而且您现在还没有回应羊羊的问题(他已经提出多天了)，而且请您看看其他人的意见，请注意您现在的行为是WP:ONEHANDGIVES:“故意拖延或冗长辩论”。--虫虫飞♡♡→♡℃※留言 2021年8月12日 (四) 04:44 (UTC)

我认为提高门槛势在必行，120天是合理的（另外我主张将延伸确认门槛扩展至移动重要命名空间）--Newbamboo（留言） 2021年8月10日 (二) 07:13 (UTC)

+1。--MCC214（Sign | Contributions） 2021年8月10日 (二) 10:38 (UTC)

移动权是自动确认权的，这个要另外提案讨论。--虫虫飞♡♡→♡℃※留言 2021年8月10日 (二) 07:21 (UTC)

• 已公示七天，提案通过。--虫虫飞♡♡→♡℃※留言 2021年8月12日 (四) 07:10 (UTC)

---

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

大量讯息发送者不在本文之列吗

如题。还是已经列出但我没找到？--洛普利宁 2021年8月28日 (六) 16:39 (UTC)

@Lopullinen：目前没有列出，应当补充。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2021年9月6日 (一) 08:03 (UTC)

延伸确认权限后续讨论 part3

译名

话说，社群究竟打算采用延伸确认、扩展确认，还是进阶确认作为译名啊？这三种我都有见过。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2021年8月2日 (一) 04:06 (UTC)

进阶确认吧，听起来自然一点。--Lt2818（留言） 2021年8月2日 (一) 05:02 (UTC)

之前的情况好像是简体用“高级确认”、繁体用“进阶确认”，建议沿用。SANMOSA _Σουέζ 2021年8月2日 (一) 06:51 (UTC)

• 反对繁简不统一的译名。 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年8月2日 (一) 13:02 (UTC)

  但这东西繁简不同的译名是以前早就有的，你引用的页面可能不适合。不过如果大家的意思是“进阶确认”可以用的话，至少繁体的译名可以定下来了。SANMOSA _Σουέζ 2021年8月2日 (一) 13:55 (UTC)

  繁简译名不统一除了加入公共转换组，写模板的时候还要一个个手动转换，在别人的讨论页留言可能还要看看别人用什么变体，然后flow又不支持/支援字词转换……反正就是麻烦，还不如取名的时候统一。 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年8月2日 (一) 14:11 (UTC)

  那我也推荐“进阶确认”。SANMOSA _Σουέζ 2021年8月2日 (一) 15:05 (UTC)

“进阶”具有浓厚阶级意味，个人认为“延伸”或“扩展”都比“进阶”对新手友善。简称而言，“延确”“进确”“扩确”好像也就“延确”最顺口。--路西法人 • 留言 2021年8月3日 (二) 01:58 (UTC)

支持延伸确认。--Bookwith（留言） 2021年8月3日 (二) 06:42 (UTC)

同-- Sunny00217  2021年8月3日 (二) 12:31 (UTC)

(✓)同意“延伸确认”最顺口。--虫虫飞♡♡→♡℃※留言 2021年8月3日 (二) 03:17 (UTC)

(＋)支持支持使用延伸确认，这个译名。~~Sid~~ 2021年8月4日 (三) 13:30 (UTC)

(✓)同意，延伸确认比进阶好一点，也比较善意。--阿伦（留言） 2021年8月14日 (六) 15:54 (UTC)

注：为了不造成混乱而界面讯息已暂时统一为方针通过时采用之名称，唯此决定不应影响此讨论，若最终决定名称不同将全面替换名称，以上。--Xiplus#Talk 2021年8月18日 (三) 05:58 (UTC)

---

公示7日：就译名定为“延伸确认”进行公示，参7DAYS，公示柒天--papayatrash〈留言〉 2021年8月30日 (一) 04:41 (UTC)

• 公示期已过。应进行全面之盘点，确保未有遗珠未获修改。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2021年9月8日 (三) 09:12 (UTC)

图标

请移动到Wikipedia:投票/决定延伸确认图示讨论。--Xiplus#Talk 2021年10月4日 (一) 09:47 (UTC)

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

---

当前图标是蓝色的锁里头一个人，与半保护的图标只有配色上的差别，其意义恐难以与半保护做出区分。顺便套用C区讨论的一个论点，对于色盲/色弱人士他们难以区别这两个保护。因此我提议修改图标。个人初步想法是在人的旁边放个加号之类的东西。 --Milky·Defer 2021年8月4日 (三) 02:15 (UTC)

(＋)支持:可以把图标贴出来给大家看一下吗？--虫虫飞♡♡→♡℃※留言 2021年8月4日 (三) 02:40 (UTC)

干脆大家在这些选项当中选一个吧，或者有其他设计者也可提出： --Milky·Defer 2021年8月4日 (三) 06:22 (UTC)

• 
  1
• 
  2
• 
  3

---

2号的加号太小了，根本看不见。我做了一个加大的版本：

• 
  4
• 
  5

 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年8月4日 (三) 12:53 (UTC)

好像出了点问题 囧rz……我的Ai一打开文件它就是那么细……不知道有没有人帮我修一下…… ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年8月4日 (三) 12:56 (UTC)

人好像也变形了……-- ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年8月4日 (三) 13:01 (UTC)

我知道问题出在哪了。 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年8月4日 (三) 13:06 (UTC)

不，我不知道。 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年8月4日 (三) 13:09 (UTC)

其实我是知道的。我改完了。副知@Sidishandsome、AnYiLin ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年8月4日 (三) 13:55 (UTC)

我投羊羊君修改过的2号一票，其实就是4号。~~Sid~~ 2021年8月4日 (三) 13:23 (UTC)

(✓)同意2号或4号都好。--虫虫飞♡♡→♡℃※留言 2021年8月4日 (三) 14:22 (UTC)

我将gallery设定成右上角图示大小，因为必须在此大小下能够辨识图示内容。--Xiplus#Talk 2021年8月4日 (三) 13:28 (UTC)

如果没有其他方案，建议从3和4之中选择。4中图案多了些，不过也还可以。--安忆^Talk 2021年8月4日 (三) 13:32 (UTC)

• (＋)支持:4。--虫虫飞♡♡→♡℃※留言 2021年8月4日 (三) 15:29 (UTC)

希望4的加号能再粗一点 --Milky·Defer 2021年8月4日 (三) 16:39 (UTC)

@MilkyDefer：稍微加粗了那么一点点（描边减少了0.3px），再大整个图就都是白的了 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年8月5日 (四) 00:02 (UTC)

@MilkyDefer、羊羊32521：我有个意见，就是不同版本的锁的蓝色的色调好像有差异，建议用File:Extended-protection-wikimedia1-blue.svg.png的蓝色色调作准（也当成我提议用File:Extended-protection-wikimedia1-blue.svg.png作icon）。SANMOSA _Σουέζ 2021年8月5日 (四) 07:08 (UTC)

@Sanmosa：色调比较柔和，但更像c:Category:Page Protection Padlock Redesign - All中的“Create”（白纸保护）？个人认为File:Extended-protection-wikimedia1-blue.svg.png 的图案更适合“扩展”的译名，还要看上面命名的结果。 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年8月5日 (四) 08:22 (UTC)

• 而且比较像连锁保护。 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年8月5日 (四) 10:42 (UTC)

• 补充了5号。 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年8月5日 (四) 10:42 (UTC)
• 本人更加支持三号，对于视力障碍人士更加友好。--DreamerBlue（留言） 2021年8月5日 (四) 13:05 (UTC)

  三号似乎更适合（已经没机会见到的）稳定版本保护就是了……--Milky·Defer 2021年8月5日 (四) 13:14 (UTC)

• 我追加提议一种往锁里面放只笔的方案，图我明天做。 --Milky·Defer 2021年8月5日 (四) 13:12 (UTC)
  • 我希望图标能与新用户组的名字联系，比如 的“+”， 的扩张感和 的箭头，我不清楚笔和extended确认有什么关系…… ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年8月5日 (四) 23:48 (UTC)

  笔和加号咯。--路西法人 • 留言 2021年8月6日 (五) 03:25 (UTC)

个人觉得此应视乎最后通过使用的译名，延伸用2或4，扩展用5。个人认为2的加号太小，4号的太大锁头要忍一下^{[开玩笑的]}。用户加个tick号怎样？--路西法人 • 留言 2021年8月6日 (五) 00:23 (UTC)

可以用个2~4中间吧-- Sunny00217  2021年8月6日 (五) 07:42 (UTC)

我倒觉得4的+改成√不错。--Lightyears _GBAW 2021年8月7日 (六) 11:10 (UTC)

(！)意见：个人认为英语维基百科的File:Extended-protection-shackle.svg更好些。--爬行数码1903 2021年8月16日 (一) 06:51 (UTC)

(＊)提醒E字锁头可能会造成判读上的困难。-- 不沈舰、抜锚ォッ✨_{🦈🍤#どうも💙さめです！} 2021年8月18日 (三) 08:57 (UTC)

@Oldmanson：(＊)提醒：您的留言有未闭合的标签<s>（因为html5弃用直接改成<del>，若有错误敬请见谅）-- Sunny00217  2021年8月18日 (三) 09:20 (UTC)

• 根据Wikipedia:投票/更新Wikipedia:保护方针的图示，现行保护图示如下：

保护级别	图标
全保护	全保护
模板保护	模板保护
半保护	半保护
创建保护	创建保护
移动保护	移动保护
文件保护	文件保护
基金会保护	基金会保护
连锁保护	连锁保护

 ——魔琴 [ 喀布尔陷落 ] 2021年8月18日 (三) 14:34 (UTC)

@蟲蟲飛、Sanmosa、羊羊32521、MilkyDefer、CreeperDigital1903、Sunny00217、DreamerBlue、Xiplus、AnYiLin、Oldmanson：为确保各模板能有共识修改正确显示为延伸确认保护而不会fallback至其他与保护状态不符的锁图案，先提出提案，在达成共识采用新锁头之前暂时采用英维E字锁，防止新手被误导或搞乱。--路西法人 • 留言 2021年8月22日 (日) 13:28 (UTC)

(✓)同意--虫虫飞♡♡→♡℃※留言 2021年8月22日 (日) 13:34 (UTC)

• (＋)支持。--爬行数码1903 2021年8月22日 (日) 22:59 (UTC)
• 可也，建议IAR直接通过。LuciferianThomas ——魔琴 [ 喀布尔陷落 ] 2021年8月23日 (一) 06:50 (UTC)

@Sanmosa：WP:SNOW了这个吧。麻烦帮忙改。--路西法人 • 留言 2021年8月30日 (一) 01:32 (UTC)

• 
  Icon with clock

半保护之所以有个人头，可能是在象征‘自动确认用户’的一大特点 - 已经有了一个账户，一个身份，对维有了基本认识。所以我觉得延伸保护有个时钟，可以象征‘延伸确认用户’的一大特点 - 已经经过更长时间的认可。有点丑随便吧，如果有谁觉得这想法还可以的话弄一个好点的吧。 Iridium(IX) 2021年8月24日 (二) 13:39 (UTC)

不知道您有没有听说过一个说法，展示时钟通常喜欢将时间放在10点10分左右的位置。实际上您会发现时针和分针顺便组成了对勾的样子。在这个基础上再进行一点微调吧。 --Milky·Defer 2021年9月8日 (三) 06:41 (UTC)

噢好的--Iridium(IX) 2021年9月9日 (四) 11:17 (UTC)

• 
  Icon with clock

还行吗？ Iridium(IX) 2021年9月11日 (六) 13:51 (UTC)

@SIridiuM28：不是你这锁怎么跟其他摆出来的相比这么小啊？ --Milky·Defer 2021年9月16日 (四) 04:39 (UTC)

svg应该是能调大小的吧不确定--Iridium(IX) 2021年9月16日 (四) 06:54 (UTC)

请把档案调成正方形。--Xiplus#Talk 2021年9月16日 (四) 14:32 (UTC)

已调整--Iridium(IX) 2021年9月21日 (二) 08:29 (UTC)

• 
  Modified
• 
  Pencil

以上是我制作的两个新的图标。第一个是时钟元素，受上面启发制作；另一个是铅笔元素，铅笔寓意“编辑经验”。 --Milky·Defer 2021年9月16日 (四) 12:53 (UTC)

---

理论上目前暂时采用英维版本图示对吧？所以都部署得怎么样了？—— Eric Liu _{创造は生命（留言．留名．学生会）} 2021年9月8日 (三) 09:15 (UTC)

@Sanmosa：之前纯粹因无共识而拒绝的编辑请求重新审视吧。--路西法人 • 留言 2021年9月11日 (六) 09:11 (UTC)

@Ericliu1912：目前采用当初公示的附图，。--Xiplus#Talk 2021年9月12日 (日) 11:50 (UTC)

---

粗略统计一下

选项2：1人

选项3：2人

选项4：5人（含作者票）

选项5：1人（含作者票）

选项clock：1人（含作者票）

选项pencil：1人（含作者票）

虽然选项4偏多，但整体参与人数过少，且没有更多留言了，看是要通过选项4还是办投票来吸引更多意见。--Xiplus#Talk 2021年9月28日 (二) 09:43 (UTC)

参考前例，付诸表决为宜。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2021年9月28日 (二) 11:13 (UTC)

我个人觉得这个讨论拖沓了很久，先提出的方案其实沾了时间长和站内关注者多的红利，对后提出的几个方案可能不是特别公平。建议再向全站征集方案后，交由投票决定。--Milky·Defer 2021年9月29日 (三) 19:29 (UTC)

那么再征集两周，之后两周投票。--Xiplus#Talk 2021年10月2日 (六) 02:33 (UTC)

“征集”要放布告板啦（-- Sunny00217  2021年10月3日 (日) 14:22 (UTC)

Wikipedia:投票/决定延伸确认图示。--Xiplus#Talk 2021年10月4日 (一) 01:46 (UTC)

漏了Sanmosa提议的（File:Extended-protection-wikimedia1-blue.svg.png） ——魔琴 [ 已经告假 留言 贡献 ] 2021年10月2日 (六) 09:45 (UTC)

---

请移动到Wikipedia:投票/决定延伸确认图示讨论。--Xiplus#Talk 2021年10月4日 (一) 09:47 (UTC)

---

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

擦边球

标题添加：羊羊 [ 留言 贡献 维猫报 古典音乐专题 ]

• 可悲，上面是不是没有半个人定义500次是否含擦边球，然后就公示了？更加快更多用户玩擦边球的游戏。标准维基百科的Bug，所以再讲几次都没有用。--Z7504非常建议必要时多关注评选（留言） 2021年8月9日 (一) 11:24 (UTC)

  Z7504好像有提出过条目空间500次结果被否了？ ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年8月9日 (一) 12:21 (UTC)

  条目空间500次的问题，从WMF的配置文件而言没有一个wiki有这样的配置；而且我高度怀疑这个需求在MediaWiki架构层面就没做这个设计，除非有人去phab开工单，然后等大佬改代码。--Milky·Defer 2021年8月9日 (一) 13:16 (UTC)

  又被说中了，果然是无法解决的Bug，不意外。慢慢搞吧，再见，就不给任何意见给早就有矛盾的讨论了。反正换个图示标志，说不定过没几年或几个月又有用户对图示标志有意见而提议互助客栈。如此反复的，根本和没共识一样，而且500次编辑数都早有问题了，果然可悲。--Z7504非常建议必要时多关注评选（留言） 2021年8月9日 (一) 15:58 (UTC)

  英维是500条目编辑数的，日维也是500，不肯定是否条目空间。之前是提过500条目空间，但有人不同意。--虫虫飞♡♡→♡℃※留言 2021年8月10日 (二) 08:41 (UTC)

  如果是条目编辑数那就是只能算正式条目的编辑数嘛，原来在zh有那么难定义500的计算方式。所以zh里面肯定早有人认为像是模组、模板、“WP:/Help:/Portal:/Wikiproject:”等开头的页面或者那两个现在似乎没什么差别的沙盒（Sandbox）和草稿（Draft）...等都算在500次里面就是了？怪不得zh很支持新手玩擦边球的游戏，又再一次见证神逻辑。--Z7504非常建议必要时多关注评选（留言） 2021年8月12日 (四) 08:36 (UTC)

  其实有相关方针处理作弊票，见WP:NOVOTE:“资格受争议者，抽出而交社群讨论，并由行政员决定是否符合资格。不当取得投票资格者，如重复编辑或回退、屡删屡加完整内容以增编辑数、大量无意义操作、多次提删无著作权问题页面、编写侵权或广告等，其投票应抽出交社群商议判断是否有意破坏，及作出适当处理。行政员凡基于事实及社群意向，均有权决定选票有效与否。”--虫虫飞♡♡→♡℃※留言 2021年8月12日 (四) 08:53 (UTC)

  • 判定是不是500次条目编辑或许可以通过abot，让机器人自行去判定再授权，而不是系统去自动授权。但这样有明显的滞后性和性能问题。--安忆^Talk 2021年8月13日 (五) 05:01 (UTC)
    • 条目空间的提议之前提过，但被否决了，英维和日维是系统自动授权的，如果要条目空间，系统也能做到，英维是条目空间500后，系统才自动授权。--虫虫飞♡♡→♡℃※留言 2021年8月13日 (五) 05:07 (UTC)

      否决了就算了。phab的developers估计也懒得改。--安忆^Talk 2021年8月13日 (五) 05:15 (UTC)

      虫虫飞持续进行不实陈述的行为已予以提报。--Xiplus#Talk 2021年8月15日 (日) 02:53 (UTC)

我3月11日那才获得权限，但编辑数早已经超过600，具体原因我也不清楚；条目空间数是我搞错，我致歉，但500编辑数在英维我是不能获得延确权限，我也不清楚原因。--虫虫飞♡♡→♡℃※留言 2021年8月15日 (日) 03:12 (UTC)

吉米python

谁可以通知一下Jimmy Xu修改相关的python，或者是另外写一个？--1233 （T / C） 2021年8月13日 (五) 11:02 (UTC)

• 1233您可以自行通知他。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2021年8月14日 (六) 16:21 (UTC)

• 已经请他改了。--虫虫飞♡♡→♡℃※留言 2021年8月20日 (五) 09:15 (UTC)

• 鉴于Jimmy的服务端脚本是直接查指定页面的，我就写了个查特定用户的，欢迎试用。在common.js中加入mw.loader.load('/wiki/User:AnYiLin/js/CheckEligibility.js?action=raw&ctype=text/javascript');后，将会在页面中的“Wiki工具”处添加按钮。在用户页（包括讨论页、用户贡献）点击将自动查询该用户，在其他页面点击会先要求输入要查询的用户名再查询。--安忆^Talk 2021年9月7日 (二) 02:51 (UTC)

题外话

符合要求的用户可以将{{User wikipedia/Extended confirmed}}及{{Extended confirmed topicon}}置于自己用户页。--东风（留言） 2021年8月16日 (一) 12:30 (UTC)

那张图可能还要改一下就是了......-- Sunny00217  2021年8月16日 (一) 12:41 (UTC)

建议给予延伸确认用户“移动时不留重定向”权限

我希望能给予延伸确认用户移动时不留重定向的权限。延伸确认用户有一定的经验，对相关方针较为熟悉。将该权限赋予给延伸确认用户，能节省挂删除模板的时间，也能减少管理员重定向删除工作。因此，我建议赋予延伸确认用户此权限。 --$8.7638\,$$\times$$\,10^{217134}$ 2021年11月27日 (六) 11:45 (UTC)

(＋)支持、(＋)跟进，绝对需要。ghren🐦吱吱吱...🔊 2021年11月27日 (六) 11:57 (UTC)

请具体举例您会在何种情况下使用“移动时不留重定向”权限。--安忆^Talk 2021年11月27日 (六) 12:07 (UTC)

比如一个页面名称错误，需要移动到正确名称？或者一个模板尚未被使用，需要修改它的名字？桐生ここ★[讨论] 2021年11月27日 (六) 13:36 (UTC)

例如将草稿页面移动至正式条目时。--$8.7638\,$$\times$$\,10^{217134}$ 2021年11月27日 (六) 13:45 (UTC)

那么二位相信大部分的延伸确认用户都会这么理解吗？他们只是有500次编辑而已，不需要看规则就可以做到500次。最后是会“利用权限于命名争议中夺取优势、无视命名争议而使用权限”，还是会在“重定向符合快速删除方针或须释放标题以便另一页面占用”时使用。对申请suppressredirect权限的人都应该有这么一问。--安忆^Talk 2021年11月28日 (日) 03:37 (UTC)

@AnYiLin：我觉得就移动战而言，“利用权限于命名争议中夺取优势、无视命名争议而使用权限”中的“权限”是移动权限本身，而不是“移动时不留重定向”权限。虽然你的这个问题是合理的，但在考虑到我前面说的话的前提下，这个问题是没有意义的。也因为如此，我不但不反对给予延伸确认用户“移动时不留重新导向”权限，甚至也如以往一样主张同时给予自动确认用户同样权限。Sanmosa _WAM 2021年11月28日 (日) 09:23 (UTC)

(＋)支持 减轻了管理员站务负担。桐生ここ★[讨论] 2021年11月27日 (六) 13:36 (UTC)

上方R2延伸到用户页也就是为了解决这个问题，这样我不用去挂O1。当然加了也只是少了我的负担，因为O1有bot处理。--ghren🐦吱吱吱...🔊 2021年11月27日 (六) 15:52 (UTC)

(－)反对，移动时不留重新导向属于变相删除的权限，不适宜由经验尚浅的延确持有，我反而建议让巡查豁免者持有此权限。--AT 2021年11月28日 (日) 09:20 (UTC)

@AT：我对于巡查豁免者是否适宜（单独）拥有此权限也有疑虑。虽然我不想针对个别用户，但我知道有个别巡查豁免者在移动战中是很STONEWALL的。Sanmosa _WAM 2021年11月28日 (日) 09:25 (UTC)

至少比延确好，而且在巡查和回退均持有此权限的前题下，如果要放宽的话，门槛更高的巡查豁免者显然是应有的选项。--AT 2021年11月28日 (日) 09:38 (UTC)

如果你是这样的想法的话，考虑到下面Ericliu1912的说法，我也不反对你的见解。下放总是比没下放好的，虽然我维持不反对给予延伸确认用户“移动时不留重新导向”权限，但如果只能下放给巡查豁免者我也没意见。--Sanmosa _WAM 2021年11月28日 (日) 10:00 (UTC)

(－)反对：意见同AT阁下。而且要知道，巡查豁免者几乎必然也是延伸确认使用者啊，就算不是也很大几率以后会是，所以将权限赋予前者必然比后者要佳。—— Eric Liu _{创造は生命（留言．留名．学生会．STE）} 2021年11月28日 (日) 09:43 (UTC)

@Ericliu1912：这不是两个没有绝对关联的东西吗...？-- Sunny00217  2021年11月28日 (日) 11:31 (UTC)

理论上是可以70个条目然后70个编辑的，不过常理来说不可能。--ghren🐦吱吱吱...🔊 2021年11月28日 (日) 11:38 (UTC)

事实上并不是没有关联。当然确实是没有绝对关联没错。—— Eric Liu _{创造は生命（留言．留名．学生会．STE）} 2021年11月28日 (日) 14:36 (UTC)

(－)反对：延伸确认用户的要求是“注册达90天并编辑达500次”，事实上，达到这一要求并不一定需要“对相关方针较为熟悉”，只需要注册时间满足要求并且进行了一定次数无大问题的编辑即可。--东风（留言） 2021年11月28日 (日) 14:48 (UTC)

我觉得还是有必要的，例如我今天看到有人不停将中日关系这种社群未有明确共识的，结果我又不能移回，因为我没有移动覆盖重定定向的能力。修改一些不合命名假如真的要巡查或者巡免才能做就变成我要不停挂request move,这样是没意思的。--以上未签名的留言由Ghrenghren（讨论｜贡献）于2021年11月28日 (日) 15:24 (UTC)加入。

我敢说申请巡查就是为了这个功能，实际也没有巡查多少条目 囧rz……Nrya ✰_{武汉肺炎两周年•Xi病毒来袭} 2021年12月1日 (三) 12:08 (UTC)

不要滥用职权啊，要干活啊。 囧rz……——Sakamotosan路过围观杯弓蛇影 | 避免做作，免敬 2021年12月1日 (三) 12:44 (UTC)

你申请回退权的话比较靠谱一些，一来有“移动时不留重新导向”权限，二来你一定有机会“干活”。 囧rz……--Sanmosa _Immortal 2021年12月2日 (四) 14:39 (UTC)

(－)反对，意见同AT，未能保证延确用户是可信，不会滥用此功能。--A1Cafel（留言） 2021年12月5日 (日) 03:33 (UTC)

题外话，在下今天写了一个脚本，能快速发布用户命名空间内的草稿。方法：在您的js中加入mw.loader.load('/w/index.php?title=User:魔琴/gadgets/Quick102/Quick102.js&action=raw&ctype=text/javascript');，在用户命名空间中，按下“更多”里的“快速102”，自动将草稿发布至条目（如，User:Example/sandbox/draft/foo/bar/地球移动至地球），不留重定向（若无此权限则自动标记O1）。在下完全不懂js，完全是边学边写，可能有很多问题，希望各位大佬能来测试改进 囧rz…… ——魔琴 [ 已经告假 留言 贡献 ] 2021年12月5日 (日) 08:46 (UTC)

多个API请求不用Promise/await很容易出问题，$(document).ready套娃，第五行也没看出有什么意义。--安忆^Talk 2021年12月5日 (日) 11:39 (UTC)

第五行是忘记删除了 囧rz……（当时用来检查脚本有没有载入）。$(document).ready删了内层的。API真的不会改（ ——魔琴 [ 已经告假 留言 贡献 ] 2021年12月5日 (日) 12:05 (UTC)

https://zh.javascript.info/promise-chaining --安忆^Talk 2021年12月5日 (日) 12:51 (UTC)

很努力地看了，看不懂😭（或者也许懂了但不知道怎么用？ ——魔琴 [ 已经告假 留言 贡献 ] 2021年12月6日 (一) 12:42 (UTC)

（我知道多了一个--） ——魔琴 [ 已经告假 留言 贡献 ] 2021年12月6日 (一) 13:25 (UTC)

参考资料

修订Wikipedia:用户权限级别#监督者

现行条文 监督者 拥有监督权限（Suppress）的用户（监督者）。就可以在接到要求后执行隐藏编辑版本的操作，并可以查看其它监督者的隐藏记录。

提议条文 监督员 拥有监督权限（Suppress）的用户（监督员）就可以在接到要求后执行隐藏编辑版本的操作，并可以查看其它监督员的隐藏记录。

按Wikipedia:监督提议修订本指引。

--BureibuNeko 2022年10月16日 (日) 10:38 (UTC)

看起来没什么问题。--冥王欧西里斯（留言） 2022年10月17日 (一) 05:06 (UTC)

再提取消文件移动员并下放权限

已通过：

提案已通过，phab已被合并，方针已修改。--在下荷花，请多指教（欢迎签到） 2023年3月13日 (一) 13:45 (UTC)

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

---

于Phabricator查看
编号T331691的任务
已解决

现今，文件移动员身份组仅有2人，且文件移动需求不高，在本地需移动的文件一般也无特别大的争议，故再次提议取消文件移动员并将权限下放，个人认为可下放至延伸确认用户。--在下荷花，请多指教（欢迎签到） 2023年2月11日 (六) 14:04 (UTC)

(＋)支持 感觉这个权限组没什么意义，建议将该权限进一步下放到自动确认用户。为避免移动破坏，保留“移动时不留重定向”给延伸确认用户。第一眼看到这个提案的反应是“什么，我们还有文件移动员？！”的顺颂时祺 ZhaoFJx^{（论•编）} 2023年2月12日 (日) 02:18 (UTC)^{[开玩笑的]}

我是，另外移动不留重定向在文件移动方面没有独立的权限，所以分不出来。--在下荷花，请多指教（欢迎签到） 2023年2月12日 (日) 03:09 (UTC)

唔，如果这样的话就不要下放了，因为移动破坏也不是不常见。——顺颂时祺 ZhaoFJx^{（论•编）} 2023年2月12日 (日) 03:12 (UTC)

不反对将文件移动权限（movefile）下放到延展确认用户。但移动后不留原名（suppressredirect）是否也下放到延展有保留。附，现在“文件移动”给了巡查阔免、巡查、文件移动组，“移动后不留原名”给了萝卜（bot）组、巡查、回退、跨维基导入。（或者说拿到巡查基本上都能用上）——Sakamotosan路过围观 | 避免做作，免敬 2023年2月12日 (日) 05:32 (UTC)

本案不提议下放不留重定向权限。--在下荷花，请多指教（欢迎签到） 2023年2月12日 (日) 06:31 (UTC)

(＋)支持下放 movefile 权限至延伸确认使用者并移除档案移动员使用者群组。--冥王欧西里斯（留言） 2023年2月15日 (三) 03:17 (UTC)

	上任日	除权日	用权数
Sanmosa的移动日志	2021年9月23日	2022年2月1日	0
RyanCray的移动日志	2020年11月12日	2022年12月7日	17
Minorax 的移动日志	2019年7月13日	至今	1
TimWu007的移动日志	2019年10月28日	2020年8月11日	32
和平至上的移动日志	2018年6月13日	2018年6月17日	0
hehua的移动日志	2022年2月22日	至今	67

更新于：2023年2月12日 (日) 10:09 (UTC) 再作了一次统计。Ghren🐦🕕 2023年2月12日 (日) 10:11 (UTC)

看起来好像还可以，我是觉得这个需求不是很大可以下放。--在下荷花，请多指教（欢迎签到） 2023年2月12日 (日) 14:01 (UTC)

(＋)支持&(！)意见：若下放至扩展确认，不建议取消文件移动员组别，应保留以备自动确认组或是确认用户组的用户申请；若下放至自动确认用户，则支持取消文件移动员组别。另外，个人支持权限下放，文件移动员组别的权限敏感度应当和普通页面移动权类似，没有必要加以限制。至于是下放到扩展确认还是自动确认，由于文件方针较普通页面更严，认为先行下放至扩展确认较为合适。H.Natsumi ™ 2023年2月12日 (日) 14:53 (UTC)

那也可以。--在下荷花，请多指教（欢迎签到） 2023年2月12日 (日) 15:27 (UTC)

• (＋)支持：就是不知道哪些天兵用户想出来的类似巡查豁免权一样的没屁用权限（有跟没有意思一样），这讨论看了就真可悲，应当直接废除这种没屁用权限才是。还有，这个讨论不是应该再邀请热衷于档案存废讨论的@Wcam来讨论才合理吗？也没有人提到要是档案名称与维基共享资源重复的问题？奇葩。总之，这讨论串基本上没什么好讨论的，独裁社群就是喜欢把简单的事情复杂化。--Z7504非常建议必要时多关注评选（留言） 2023年2月13日 (一) 15:53 (UTC)

现在来看基本上都支持下放至延确，但是对于是否取消用户组似乎还有不同意见，想问一下应不应该取消呢？个人是倾向取消，但是需要处理的移动文件分类可以保留。--在下荷花，请多指教（欢迎签到） 2023年2月15日 (三) 06:05 (UTC)

我个人倾向取消，毕竟中文维基百科目前的延伸确认使用者已有三千多人，都已经是英文维基百科的档案移动员人数的十倍左右了（不过英文维基百科的档案移动员仅有 movefile 而无 suppressredirect 权限），保留档案移动员使用者权限群组无甚必要，要找到延伸确认以上权限的使用者协助移动也不困难。--冥王欧西里斯（留言） 2023年2月15日 (三) 06:37 (UTC)

@S8321414中文的文件移动员也没有不留重定向。--在下荷花，请多指教（欢迎签到） 2023年2月15日 (三) 07:49 (UTC)

那么更没有问题了，更何况 movefile 在管理员、巡查员与巡查豁免都有，就算自确没有，要找到有此权限的人也应当不困难。--冥王欧西里斯（留言） 2023年2月15日 (三) 08:30 (UTC)

个人提议如果下放扩展确认仍保留文件移动员组别的原因其实就是Minorax的权限申请，确实无法排除存在跨域贡献者愿意参加本地文件移动的可能性，而目前中文维基百科的扩展确认门槛较高（如果先前没有自动创建中文的账号则需要等待90天），合理认为这样会影响到跨域贡献者的贡献（虽然可以提交移动请求，但是显然对于这一类人直接授权来的更好）。H.Natsumi ™ 2023年2月15日 (三) 08:40 (UTC)

这个也确实，@S8321414 您怎么认为？--在下荷花，请多指教（欢迎签到） 2023年2月15日 (三) 12:00 (UTC)

我个人还是倾向废除档案移动员群组，但暂时保留还算是可接受的选项（不过这个暂时不知道有多久就是了）。--冥王欧西里斯（留言） 2023年2月15日 (三) 12:45 (UTC)

@Hotaru Natsumi：经查，Minorax已系延确。另：个人建议档案移动员权限可改为仅以临时权限形式授予。Sanmosa _{Συ γάρ μοι και μοίρα εί και τύχη} 2023年2月16日 (四) 06:49 (UTC)

大概接近想法。将“文件移动”下放到延展用户，现有组保留并辞退现有组员，只作为临时授权给没到延展用户的后备，可以自行移除自己组。这样避免浪费组功能，也可以应对特定情况。——Sakamotosan路过围观 | 避免做作，免敬 2023年2月16日 (四) 07:24 (UTC)

啊不是说Minorax的权限会因此而被移除，而是说因为Minorax的例子个人认为这个组应该要保留，以避免后续如Minorax这样的跨域贡献者在存在经验可以获得该权限的情况下难以直接获得这一权限。另外关于仅授权临时权限，应是合理且必要的，确实若得到这一权限，保持活跃编辑不出12个月应当能够达到扩展确认权限门槛。H.Natsumi ™ 2023年2月16日 (四) 09:01 (UTC)

感觉没有必要仅授予临时权限，没什么意义，达到了再除权就完了。--在下荷花，请多指教（欢迎签到） 2023年2月16日 (四) 09:04 (UTC)

这样也行，就是扩展确认本身是自动授权的，有必要的话可以写个机器人自动提报或者自动除权。H.Natsumi ™ 2023年2月16日 (四) 09:25 (UTC)

也可以。--在下荷花，请多指教（欢迎签到） 2023年2月16日 (四) 10:48 (UTC)

我认为你搞错了一些点，保留组是为了临时授权的需要，实务上不再使用“文件移动员”组，延展用户的达标是需要一定的编辑量，临时授权是为了前面的情况（例如上面提到的Minorax，19年授权，但到21年才到延展）。——Sakamotosan路过围观 | 避免做作，免敬 2023年2月17日 (五) 00:29 (UTC)

@Cwekemm我没明白，请问这里的临时授权说的是不授予无限期权限还是什么别的？--在下荷花，请多指教（欢迎签到） 2023年2月17日 (五) 06:37 (UTC)

就是有期限的组别授权。组别不再长期授予，保留组别是为了应对没到延展的情况临时使用。——Sakamotosan路过围观 | 避免做作，免敬 2023年2月17日 (五) 06:45 (UTC)

啊，那授予多长时间呢？这要修改方针吧。--在下荷花，请多指教（欢迎签到） 2023年2月17日 (五) 06:54 (UTC)

因为提出Minorax这个案例，我也不太确定。因为原本就是干脆整组移除的，Minorax的按钮才考虑临时留下。如果参照的话，可以看LIPE的临时授予期？好像常见是半年。——Sakamotosan路过围观 | 避免做作，免敬

大致支持。另外，延伸确认用户得到的不是完整的“文件移动员”权限，没有suppressredirect，不排除有人希望不留重定向移动文件，且不是巡退员。可留作该用。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年2月17日 (五) 14:29 (UTC)

@魔琴文件移动员本来就没有suppressredirect权限。--在下荷花，请多指教（欢迎签到） 2023年2月18日 (六) 01:01 (UTC)

哦这样啊，恕在下失察，谨撤回意见。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年2月18日 (六) 04:41 (UTC)

不反对也不支持下放。目前除了文件移动员外，movefile权限还赋予了管理员、巡查员与巡查豁免，后两者的门槛不高，且移动文件似乎基本上就是巡查工作才需要使用吧。不过既然suppressredirect不下放，倒也不用担心错误移动文件导致红链的问题，因此中立。--BlackShadowG Slava Ukraini! 2023年2月19日 (日) 02:24 (UTC)

也会有一些上传的时候填错了名想改发现只能请求的情况。--在下荷花，请多指教（欢迎签到） 2023年2月19日 (日) 09:05 (UTC)

我觉得权限留着也没有什么大碍。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2023年2月20日 (一) 02:28 (UTC)

提议条文

看上去是没什么大的反对意见了，先放个条文修改如下：

WP:EXTENDEDCONFIRMED：

现行条文 一个已注册的用户会在注册达90天并编辑达500次后自动被授予该群组权限。该群组的权限允许用户编辑受到延伸确认保护的页面。

提议条文 一个已注册的用户会在注册达90天并编辑达500次后自动被授予该群组权限。该群组的权限允许用户编辑受到延伸确认保护的页面，且相较于自动确认用户，还可以移动文件。

WP:FM：

现行条文 档案移动员用户权限允许有经验的使用者，依据方针执行档案更名工作，以便享有如同自动确认用户移动维基百科条目的便利功能。 任何管理员可以在审慎考虑之下，授予可信任用户这个权限，该用户必须经常处理多媒体文件，且熟悉各类多媒体重新命名的相关方针与指引。档案移动员的资格基本资格要求是： 自首次编辑以来参与维基百科满30日； 至少250次编辑，以及过去3个月内（未满3个月之新注册用户，从注册之日起计算至当日）平均编辑次数多于1次；或曾经提出有效档案移动申请（包含维基共享资源）至少20次（将会从用户贡献中的档案编辑历程中查证）； 最近1年内未曾受到封禁处分（不合理封禁除外）；且 申请时须回答管理员或现有档案移动员相关方针与指引的知识及应用问题。 除此之外，档案移动员应当非常熟悉维基百科的图像与多媒体方针（尤其是本页面当中的重新命名指引）、对图像更名程序有充分了解和具有处理图像相关工作的经验。 如果用户曾在维基共享资源执行相同工作、使用相关工具以及其他多媒体档案的相关类似经验，管理员或许会将这些经验作为是否授予权限的考虑因素。 除非刚来的编辑者曾上传一定数量的档案，否则本用户权限一般不会授予此类编辑。 如果您有意为您或其他用户申请档案移动的权限，请到Wikipedia:权限申请/申请档案移动权申请。以下用户不需要去申请或是为他们增加本权限，他们本身已经获自动授予档案移动的权限： 管理员； 巡查员； 巡查豁免者。

提议条文 档案移动员用户权限允许有经验的使用者，依据方针执行档案更名工作，以便享有如同自动确认用户移动维基百科条目的便利功能。 文件移动权限已于?年?月?日并入延伸确认用户组，文件移动员权限组现仅保留以便授予未达延伸确认的跨域贡献者文件移动权。 如果您有意为您或其他用户申请档案移动的权限，请到Wikipedia:权限申请/申请档案移动权申请。申请人应当已于维基共享资源或其他维基媒体旗下项目取得相应的文件移动权限，且在其他维基媒体项目进行过一定数量的文件移动。 当持有文件移动员权限组的用户达到了延伸确认或是取得了巡查或巡查豁免资格，则应当自行移除文件移动员组别。 以下用户不需要去申请或是为他们增加本权限，他们本身已经获自动授予档案移动的权限： 管理员； 巡查员； 巡查豁免者； 延伸确认用户。

以上。H.Natsumi ™ 2023年2月24日 (五) 02:49 (UTC)

好！--在下荷花，请多指教（欢迎签到） 2023年2月24日 (五) 05:42 (UTC)

申请资格第二项看起来是多余的，是否是延伸确认使用者的笔误？--Xiplus#Talk 2023年2月24日 (五) 06:02 (UTC)

本意是不持有movefile这个权限，不是指文件移动员这个权限组，实际操作中有这个权限的应该也不会重复申请，想来确实可以移除这个条件，已修改。H.Natsumi ™ 2023年2月24日 (五) 08:24 (UTC)

(～)补充：此外Wikipedia:权限申请/申请档案移动权/header应当也要做相应更动，或者更加浅显地说，只保留欲申请档案移动权，请点击下方“增加新请求”。，并且加上：

注意：文件移动权已于?年?月?日并入延伸确认用户，此页面现仅供跨域贡献者在未达延伸确认要求，且未取得巡查员、巡查豁免者权限时临时申请文件移动权。普通用户不应在此申请文件移动权，而应使用{{Rename media}}代替，直到获得延伸确认用户权限、巡查权或巡查豁免权。详见Wikipedia:文件移动员。

供参。H.Natsumi ™ 2023年2月24日 (五) 08:43 (UTC)

(＋)支持--Evesiesta_{COVID-19感染中} 2023年2月26日 (日) 03:33 (UTC)

---

整案提出已近7天无反对意见，本案最终结果是下放文件移动员权限但不取消文件移动员，以方便跨维基贡献者进行文件移动。现 公示7日，2023年3月9日 (四) 13:48 (UTC) 结束。--在下荷花，请多指教（欢迎签到） 2023年3月2日 (四) 13:48 (UTC)

公示已通过(我还以为是今天)，晚点提phab，sorry。--在下荷花，请多指教（欢迎签到） 2023年3月10日 (五) 05:41 (UTC)

Phab已提交，暂不对本案进行存档。--在下荷花，请多指教（欢迎签到） 2023年3月10日 (五) 06:22 (UTC)

• 一个月已过（自2月13日发言，3月12日再看一次），基本上会是这种结果一点也不意外。因为这本来就是一种无用且是笑话的权限，类似巡查豁免权一样的没屁用权限（有跟没有意思一样）。--Z7504非常建议必要时多关注评选（留言） 2023年3月12日 (日) 16:51 (UTC)

  。。。--在下荷花，请多指教（欢迎签到） 2023年3月13日 (一) 00:28 (UTC)

---

已经合并，方针已修改，现有文件移动员请自行移除权限或提出除权由管理员处理。--在下荷花，请多指教（欢迎签到） 2023年3月13日 (一) 13:45 (UTC)

---

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

常年提案

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

---

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

• 降低自动确认用户的门槛
• 巡查员与回退员合并为巡退员
• 设立高级巡退员以查看私密过滤器
• 给界面管理员授予编辑被保护页面的权限
• 与基金会协商重新引入用户查核员

--Firedoge2023（留言） 2023年7月11日 (二) 08:55 (UTC)

---

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

再提重组用户权限组

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

• 降低自动确认用户的门槛
• 巡查员与回退员合并为巡退员
• 设立高级巡退员以查看私密过滤器
• 给界面管理员授予编辑被保护页面的权限
• 与基金会协商重新引入用户查核员--Firedoge2023（留言） 2023年7月13日 (四) 14:24 (UTC)

请勿在讨论版直接引用个人沙盒，这会使您此后的更改直接反馈到该页面，使讨论内容无法确定。此外关于用户组权限的调整，还请您不要自顾自地不给出任何理由直接提出自己的一系列想法，这无助于发现问题和解决问题，只是在创造问题。——暁月凛奈 (留言) 2023年7月13日 (四) 14:41 (UTC)

回复@暁月凛奈：这些想法也不是我提的呀，之前都有讨论--Firedoge2023（留言） 2023年7月13日 (四) 14:50 (UTC)

以上提议我觉得会因安全原因而不会通过，例如反对降低自动确认用户的门槛的原因是有长期破坏者喜欢通过刷编辑数来破坏被半保护的页面。--Lanwi1^Talk 2023年7月13日 (四) 15:56 (UTC)

可以限制为条目命名空间编辑--Firedoge2023（留言） 2023年7月14日 (五) 02:02 (UTC)

可能和mw技术实现有关，至少在P站申请得到mw开发人员支持改进出这个功能才能讨论。不过如果看自动确认和延伸确认两种类似机制下的授权方式有明显差异，感觉这个授权部分是屎山，没人想动。——Sakamotosan路过围观 | 避免做作，免敬 2023年7月14日 (五) 03:05 (UTC)

• 建议先论证"非常需要的更改权限提议"。--Temp3600（留言） 2023年7月13日 (四) 20:33 (UTC)

  @Temp3600：授予界面管理员编辑被保护页面的权限可能确实“（非常）需要”（？），其他的要么看不到什么必要性，要么就跟现在讨论中的提案全部或局部重复。Sanmosa _{In vain} 2023年7月14日 (五) 01:06 (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)

关于Wikipedia:用户权限级别中确认用户权和其他条文的衔接

根据Wikipedia:用户权限级别#确认用户，确认用户除无投票权外其他与确认用户相同，但该条文并未很好的与其他条文衔接，例如跨维基导入权。因此，我建议修正为：

现行条文 跨维基导入权：为自动确认用户，最近一年内没有受到封禁（不合理封禁除外），且管理员确认可信。

提议条文 跨维基导入权：为自动确认用户或确认用户，最近一年内没有受到封禁（不合理封禁除外），且管理员确认可信。

或

现行条文 此权与自动确认用户相同，乃用以授予准自动确认用户。但是确认用户没有投票权，除非这个用户加入百科超过7天且编辑次数超过50次。

提议条文 未特殊说明的，此权与自动确认用户相同，乃用以授予准自动确认用户。但是确认用户没有投票权，除非这个用户加入百科超过7天且编辑次数超过50次。

--Gaolezhe（留言） 2023年8月14日 (一) 06:46 (UTC)

(！)意见：本人建议第二种修改方式，因为与Wikipedia:用户权限级别#确认用户衔接不良的方针不少。--Gaolezhe（留言） 2023年8月14日 (一) 06:49 (UTC)

(－)反对。不是“未有很好的衔接”，而是根本没打算要衔接。确认用户始终跟自动确认不尽相同。--路西法人 2023年8月14日 (一) 12:08 (UTC)

同上。确认用户有普遍使用吗。相关事项可能是WP:IAR的。--YFdyh000（留言） 2023年8月15日 (二) 08:06 (UTC)

(：)回应：WP:IAR是指在规则没有问题且规则影响了维基百科，而这个规则本身就有误。对于@LuciferianThomas的说法，如果是确认用户始终跟自动确认不尽相同，那么就应该使用第二种方法修正确认用户的条文

--Gaolezhe（留言） 2023年8月15日 (二) 09:11 (UTC)

一处在说技术上的存取权限，一处在说申请条件，完全不同。投票权、申请其他权限条件均不属于技术存取权限，不存在“未特殊说明”的差异。--路西法人 2023年8月15日 (二) 10:40 (UTC)

确认使用者并不自动等于自动确认使用者。自动确认使用者门槛低的惊人，即使上述条文不是刻意设计，我也认为一般权限体系并不需要考虑编辑不到五十次的确认使用者。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2023年8月19日 (六) 14:42 (UTC)