维基百科讨论:保护方针/存档4

页面内容不支持其他语言。
维基百科，自由的百科全书

Mediawiki空间的全保护是否有必要

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

如题，在MediaWiki软件调整之后，此空间下的页面均被系统自动加以MediaWiki保护，在没有editinterface权限（授权给sysop和int-admin）的情况下是无法改动的。但现在除级联保护的特殊情况外，此空间下的有些页面依然被加以全保护，我想这或许是一个历史遗留问题。是否应该批量解除此空间下页面的全保护？Techyan和Ericliu1912--安忆Talk 2021年1月28日 (四) 10:29 (UTC)

不太明白，可以举个例子么？--百無一用是書生 (☎) 2021年1月28日 (四) 11:56 (UTC)
是全保护的例子吗？比如这个就是全保护。尽管此页面的全保护是为了使它所使用的五个模板形成级联保护，但也应该去对那些模板进行全保护而不是对此页面，此空间下的页面有MediaWiki保护就足够了。--安忆Talk 2021年1月28日 (四) 12:18 (UTC)
您不能编辑全保护的界面页吗？-- 2021年1月28日 (四) 12:36 (UTC)
不能，其实主要也是因为这个才有此一问。因为除了举例的这个页面，之前也碰到过其他的，等了几天才由其他admin处理掉。因为这个，我当时还去phab问了一下，他们说不再给IA加权限了，理由是怕有人为了得到某权限去申请IA（???）虽然我感觉他这理由不是什么理由…但我也没再穷追猛打问他为什么jawiki有这个权限了。[开玩笑的]--安忆Talk 2021年1月28日 (四) 12:55 (UTC)
我认为MediaWiki保护加上连锁保护无所谓，但是没有连锁保护只留MediaWiki保护即可。-- 2021年1月28日 (四) 18:19 (UTC)
既然MediaWIki空间的页面多与界面有关，我认为就不必要全保护了，不然界面管理员也没办法更改。其实我原本认为保护只会生效其中一个，那么如果要采用MediaWiki的连锁保护，有可能实现吗？-- 2021年1月28日 (四) 18:19 (UTC)
“采用MediaWiki的连锁保护”是什么意思呢？现在Mediawiki空间下某页面有全保护都是为了使嵌入那个页面的模板或模块形成级联（比如Template:Namespace_pagename表面上是半保护，但因为它被嵌入到了全保护页面而形同全保护）。我认为即便真的需要全保护，这个全保护也是应该去对那些模板和模块做的，而不是对Mediawiki空间下的页面。--安忆Talk 2021年1月29日 (五) 05:12 (UTC)
@AnYiLin：有没有可能使用MediaWiki级的连锁保护，而不是全保护级的，那句话的意思是这样。此外，我认为连锁保护较简单，单独保护则较复杂，如果采取单独保护，可能需要借助机器人的力量。-- 2021年1月29日 (五) 13:58 (UTC)
MediaWiki保护是自动的，但不能在Mediawiki空间之外；单独保护其实之前实行模板保护的时候有做过，是由机器人进行的。类比一下，对高风险模板进行全保护应该大同小异。--安忆Talk 2021年1月29日 (五) 15:12 (UTC)
@AnYiLin：IA是什么?-- Sunny00217  2021年1月29日 (五) 05:00 (UTC)
是Interface Admin的缩写。--安忆Talk 2021年1月29日 (五) 05:04 (UTC)
居然没注意到是捷径 囧rz……-- Sunny00217  2021年1月30日 (六) 12:52 (UTC)
啊，意思是说MediaWiki空间本身已经只有管理员和界面管理员能编辑，但某些页面却又加了一个全保护在上面？这样的话，我觉得不是特殊情况，没有必要再加一层保护--百無一用是書生 (☎) 2021年1月29日 (五) 07:19 (UTC)
大体上是这个意思。特殊情况就是上面提到的，但我认为在那种情况下去针对那些模板和模块加全保护或者模板保护才是对的。--安忆Talk 2021年1月29日 (五) 07:27 (UTC)
MediaWiki空间下的连锁保护全部都是我做出的，所以我前来说明理由。MediaWiki空间下的页面由系统直接施加全保护，只有管理员能编辑，而为了防止透过修改嵌入模板而导致实质上非管理员更动界面，根据保护方针所有嵌入的模板都应该全保护，而为了方便自动保护嵌入的模板，可以使用系统的“连锁保护”功能，连锁保护在以前与分别保护所有嵌入模板无异；然而新增界面管理员（IA）之后，IA也可以编辑MW空间的讯息，若使用连锁保护将导致IA无法编辑该等MW页面，故AnYiLin才建议应采取分别保护的方式。--Xiplus#Talk 2021年1月30日 (六) 07:31 (UTC)
是的，您所说的（指sysop与IA独立后中维的IA没有编辑全保护页面的权限）就是我提出分别进行保护的原因。为了形成级联保护而对父页面进行全保护是方便之举，但也会影响一些操作（比如说在这个编辑请求中需要再去提出另一个编辑请求）。是故，不知您是否可以考虑一下我的建议。--安忆Talk 2021年1月30日 (六) 08:03 (UTC)
连锁保护 分别保护
IA能否编辑MediaWiki:Foo 否 能
IA能否编辑Template:Bar 否 否（除非为模板保护且IA同时为模板编辑员）
优点 修改界面时，不用检查哪些嵌入需保护/解除保护 IA可以编辑MW页面
缺点 IA不能编辑MW页面 需检查哪些模板要保护
提供上表比较两种方法的差异，以上假设MediaWiki:Foo中嵌入了Template:Bar，且个别模板的保护是全保护。因此我认为连锁保护对于嵌入模板的保护/解除保护相当方便的优点，与界面管理员无法编辑单一个MW页面的缺点权衡，所以我之前采取了连锁保护的方案。--Xiplus#Talk 2021年1月30日 (六) 07:48 (UTC)
@Xiplus：我认为IA可以编辑Mediawiki空间下的页面是一个合理的预期；但如果“需检查哪些模板要保护”工作量很大的话，保持现状也可。其实我最开始是想能否在技术上给予IA在Mediawiki空间下无视任何保护编辑页面的权限，但后在元维基上看到一表，上面列有多次提出但无效的提案，其中有一项就是给IA以XX权限，所以我只好转到这里看看能否从保护页面本身着手，并提出对模板模块分别保护的建议。--安忆Talk 2021年1月30日 (六) 08:21 (UTC)
我是觉得有此情况的界面讯息其实不多，不过我已经在准备自动保护的机器人了。--Xiplus#Talk 2021年1月30日 (六) 08:46 (UTC)
这个问题或许可以采用c:Commons:Auto-protected files的这种方式进行保护？--百無一用是書生 (☎) 2021年1月30日 (六) 12:16 (UTC)
好主意，已经编写机器人并产生列表Wikipedia:被连锁保护的项目/嵌入在MediaWiki命名空间。--Xiplus#Talk 2021年1月31日 (日) 10:54 (UTC)
所以技术上不可能搞个模板连锁保护吗www？？？-- Sunny00217  2021年1月30日 (六) 12:54 (UTC)
技术上可以，但是注意编辑被连锁保护的页面本身（不含引用的模板）要protect权限。--GZWDer（留言） 2021年2月2日 (二) 19:02 (UTC)
给IA编辑模板保护的页面就好，他们会选上也算是精通这类东西。不过短期不可能搞-- Sunny00217  2021年2月11日 (四) 14:34 (UTC)
@Sunny00217：就算长期估计也不行，m:Limits_to_configuration_changes：Grant Interface admins other permissions: ...Granting other rights to this group may encourage wikis to grant this right when their intention is different，此讨论最开始也有提到。--安忆Talk 2021年2月15日 (一) 18:04 (UTC)

公示对保护方针做出的修订

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

各位好，根据内容推测，已对上述方针做出可能存在的事实性修订，特此公示。--Hamish with w. 2021年6月1日 (二) 02:00 (UTC)

设置新的保护类型

本主题或以下段落文字，移动自Wikipedia:互助客栈/方针。执行者：Jimmy-bot（留言） 2021年7月28日 (三) 00:14 (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)
如果要这样做的话，那必须将自动确认用户的要求进一步提高（可以把要求提升到与对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)

初步提案如下：

现行条文
提议条文
延伸确认权限条件
  1. 账号已注册3个月。
  2. 已经编辑条目空间500次。(不含用户页及用户讨论页)
  3. 符合条件后，系统自动授权。
延伸确认权保护
  1. 只能由延伸确认用户编辑。
现行条文
  1. 解任投票联署提出或上任投票开始1个月前，编辑100次或以上；并在联署提出或上任投票开始前3个月内至少有一次编辑（不包括任何使用者页面及使用者对话页）；
  2. 编辑3000次或以上，或编辑1500次条目或以上。
提议条文
  1. 解任投票联署提出或上任投票开始1个月前，拥有延伸确认权限；并在联署提出或上任投票开始前3个月内至少有一次编辑；
  2. 编辑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月24日 (六) 10:13 (UTC)
下列讨论已经关闭，请勿修改。如有任何意见，请至合适的讨论页进行，并不要再次编辑本讨论。
于Phabricator查看
编号 T287322的任务

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

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

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

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

延伸确认权限后续讨论 part1

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

反正你们都同意我也不管了，结-- Sunny00217  2021年7月28日 (三) 01:02 (UTC)
下列讨论已经关闭，请勿修改。如有任何意见，请至合适的讨论页进行，并不要再次编辑本讨论。
  • (※)注意:讨论已超过一个月，最后一个修订版公示七天期间，完全没有人反对，共识很明显。--虫虫飞♡♡→♡℃※留言 2021年7月26日 (一) 04:27 (UTC)
    虫虫飞：我不同意这是个合符程序的公示──通过方式是有严重瑕疵。有个简单的问题──一个存在反对意见的提案，在经过修订后能立即视为已取得共识吗？显然不能。提出修订案后立即进行公示，是不当的。还有关键的一点──对原提案进行改良后，应当邀请原提案的反对者参与讨论，让他们知悉有关改动。而这点，虫虫飞是做不到的，以致于有反对者未知悉本提案。--Bookwith（留言） 2021年7月26日 (一) 09:03 (UTC)

公示公告的后续讨论

  • 大家都在关注，只是您一个人没关注公告内容和客栈的讨论，而且提案已经按照方针规定完成公示１４天，但是您在公示期间放弃讨论，这是您自己的问题；这就像假设ＲＦＡ期间您忘记投票，然后投票期结束了，您才出来闹，这也是您自已的问题。--虫虫飞♡♡→♡℃※留言 2021年7月27日 (二) 16:25 (UTC)
    虫虫飞声称大家都在关注，却出现7天公示期内无人讨论的局面，请问这合理吗？难道没人提出意见还能视作通过？--Bookwith（留言） 2021年7月27日 (二) 17:26 (UTC)
@Sunny00217：公告栏同类通知应当合并。-- ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年7月27日 (二) 16:12 (UTC)
本讨论已经关闭，请勿修改。如有任何意见，请至合适的讨论页进行，并不要再次编辑本讨论。

延伸确认权限后续讨论 part2

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

已解决：
优化案已公示七天通过。
下列讨论已经关闭，请勿修改。如有任何意见，请至合适的讨论页进行，并不要再次编辑本讨论。
于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”[1]，我不太赞成这样的修改，标题是反映原来开始此一讨论者的看法，不太确定目前的修改是反映了谁的看法？若只是修改者的看法，我是否也可以修改此一标题，再改为我的看法？--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. 解任投票联署提出或上任投票开始1个月前，编辑100次或以上；并在联署提出或上任投票开始前3个月内至少有1次编辑（不包括任何用户页及用户对话页）；
  2. 编辑3000次或以上，或编辑1500次条目或以上。
提议条文
  1. 解任投票联署提出或上任投票开始120天前，编辑至少500次；并在联署提出或上任投票开始前90天内至少有1次编辑（不包括任何用户页及用户对话页）；
  2. 编辑至少3000次，或编辑条目至少1500次。

以上。--虫虫飞♡♡→♡℃※留言 2021年7月29日 (四) 06:58 (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)
虫虫飞认为已通过的提案不适宜推翻，我倒是反对。这个提案即使优化，也不会带来显著的改变──我依然对提案没有好感。--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日 (四) 13:07 (UTC)
  • 您的理据是什么?没记错，英维的投票权就是延伸确认用户，中维没cu，RFA等傀儡投票过去也是有的，现时刷傀儡投票账号太容易了，而且某个lta整天在教人改ua，刷投票傀儡，已经让全站的人都懂得改ua规避cu去刷傀儡投票了，这个问题您觉得可以怎样解决?--虫虫飞♡♡→♡℃※留言 2021年7月30日 (五) 04:14 (UTC)
    假设由管理员授权，道德太有弹性了。且管理员可以控制投票者，这事本身就有问题。“人事任免由于管理员审批受主观因素影响，建议还是通过硬性的编辑数注册时间来确定。”但反破坏的角度来说，应该由管理员授权，这样可以某种程度防范LTA。所以这两件事情不应缠在一起。--Papayatrash｛留言｝ 2021年7月30日 (五) 06:15 (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)
@蟲蟲飛：我的建议是把人事任免投票资格的提升的讨论与这里的讨论分开处理，其实我有一个更大胆的提案。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)
好吧，提案大家都给了意见，说是谁的不重要，这是xiplus修订差异:

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

@Bookwith：如果把非编辑战的授权条件放宽，您能否接受提案?--虫虫飞♡♡→♡℃※留言 2021年8月1日 (日) 09:10 (UTC)
对于人事任免投票门槛的调整，我认为仍有讨论空间，或者需要评估各种门槛的优劣后再作决定。--Bookwith（留言） 2021年8月2日 (一) 19:24 (UTC)
支持上述三个提案，但现在有一个可能性存在的问题：如果遇上有未符提案一要求的人申请权限，且申请获批之后，及后才被发现进行鬼崇破坏（User:太鲁阁号），那如何应对？--MCC214（Sign | Contributions） 2021年8月1日 (日) 09:51 (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)
分案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)
不要以为过滤器是万能工具，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)
投票权没要求注册时间，延确才有注册时间要求，所以两种情况的投票权获得的时间是一样的。是有些分别，但改为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)
本讨论已经关闭，请勿修改。如有任何意见，请至合适的讨论页进行，并不要再次编辑本讨论。

延伸确认权限后续讨论 part3

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

译名

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

进阶确认吧，听起来自然一点。--Lt2818（留言） 2021年8月2日 (一) 05:02 (UTC)
之前的情况好像是简体用“高级确认”、繁体用“进阶确认”，建议沿用。SANMOSA Σουέζ 2021年8月2日 (一) 06:51 (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)

本主题或以下段落文字，移动自Wikipedia:互助客栈/方针。执行者：Jimmy-bot（留言） 2021年10月7日 (四) 16:14 (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
    1
  • 2
    2
  • 3
    3
2号的加号太小了，根本看不见。我做了一个加大的版本：
  • 4
    4
  • 5
    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的加号能再粗一点 --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)
个人觉得此应视乎最后通过使用的译名，延伸用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)
保护级别 图标
全保护
全保护
全保护
模板保护
模板保护
模板保护
半保护
半保护
半保护
创建保护
创建保护
创建保护
移动保护
移动保护
移动保护
文件保护
文件保护
文件保护
基金会保护
基金会保护
基金会保护
连锁保护
连锁保护
连锁保护

 ——魔琴 [ 喀布尔陷落 ] 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)
@Sanmosa：WP:SNOW了这个吧。麻烦帮忙改。--路西法人 • 留言 2021年8月30日 (一) 01:32 (UTC)
  • Icon with clock
    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
    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
    Modified
  • Pencil
    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)

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

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

擦边球

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

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

吉米python

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

更改“受模板保护的公共转换组”之定性

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

现行Wikipedia:模板编辑员#行使权力制定时，高引用量公共转换组循例半保护处理。后来某个时间点开始，高引用量转换组也执行模板保护。但转换组模板属内容系模板，需要时常更新，且技术含量不高；这和通常受保护模板的技术向对比鲜明。而方针当初大概没有考虑这个问题，于是有了如下不够完善的地方：

按模板修改三级制，更动转换组会实质影响条目内容。字面上看，其修改等级应该严于“需进行公示”（会轻微影响使用方式和外观显示的编辑……需在提交编辑请求后等待七天）。然而实际执行是，很多转换组更改请求，都最宽松的即时批准。

因为转换组属于内容向模板，模板编辑员擅长技术的优点无法发挥，甚至可以说和普通编辑没有区别。好心处理积压工作直接批准掉，之后有人提出异议，模板编辑员似乎要担当不察的责任。如果等待熟悉领域的模板编辑员确认，估计又很长时间办不成事。而我作为模板编辑员，编辑熟悉领域的转换组就有如此体验：直接动手，方针字面上是不同意的；提个修改请求，其他模板编辑员又说我可以IAR自己改。

然而对于上述问题，用IAR解释终究不是长久之计。这里有三个方向，希望社群考量并表达意向：

  1. “高引用量转换组”照旧预设半保护。
  2. “高风险转换组”执行延伸确认保护而非模板保护：能防范许多风险，也不会卡住有经验的编者；在半保护和模板编辑间取得平衡。
  3. “高风险转换组”继续执行模板保护，但在“可立即进行”上增补“非明显破坏的转换组编辑”一项。

--洛普利宁 2021年8月24日 (二) 17:33 (UTC)

倾向2，这点我在之前的讨论也表达过。Sanmosa Outdia 2021年8月24日 (二) 23:49 (UTC)
倾向第二点或第三点。—— Eric Liu 创造は生命（留言．留名．学生会） 2021年8月25日 (三) 00:42 (UTC)
转换组根据引用量施以不同保护是根据高风险模板指引的建议，本身并无错误，反而这样才是对的。较高的引用量意味着错误的转换语法会导致转换错误的条目数更多，因此使用更高的保护层级也是合理的。--Xiplus#Talk 2021年8月25日 (三) 00:47 (UTC)
另外根据Wikipedia:保护方针#使用和处理编辑请求，更动转换组我认为属于“需进行公示”等级，提出来只要等7天无反对就可以改，不认为这叫做积压。--Xiplus#Talk 2021年8月25日 (三) 00:53 (UTC)
@Xiplus： 转换组模板语法相对简单，大部分时间只是加一条规则，或者补充一个zh-hk定义，也不用考虑级联影响其他模板使用的事情。因为语法问题可以即刻看出，所以单从技术角度而言，等不等7天其实意义不大。
有疑问的地方还是具体转换内容。但转换组讨论页关注率低，放7天可能一个意见都没有。而模板编辑员未必有更多的判断能力，只能看一眼没到7天的关掉页面，7天到期的机械式批准。所以即便有问题，也是实做之后，路人读条目时发现。最后往往还是只能防低级破坏。
技术上不需要模板编辑员等级的能力，内容上模板编辑员可能无能为力，更新上存在频繁性。这是我觉得转换组和一般模板不一样的地方。—洛普利宁 2021年8月25日 (三) 02:37 (UTC)
我说的语法错误不是指程式上语法错误，而是设定转换规则造成邻近字词的转换错误（例如这个请求指出的问题），而这个影响非常容易被忽视（就是您认为等7天没有意义，但事实上如果有人看到想到就能提出意见）。--Xiplus#Talk 2021年8月25日 (三) 03:14 (UTC)
转换组和全局转换还不大一样。前者只在局部范围工作，主要转换术语和专有名词，很少涉及常用词转换；后者影响中文维基120万条目，还要让不同领域的条目都不出岔子。以游戏转换组为例，绝大部分定义都是各种奇特的作品名，本身就不容易出现分词错误。所以转换组看着引用量大，实际风险并没有那么高。即便有错误，也只会牵涉出现该作品的个别条目，而不是使用此转换组几千个的条目。所以我觉得没必要太保守：无明显问题的转换直接加入，发现有问题也随时可以回退。这样动态维护我认为是比较平衡的做法。—洛普利宁 2021年8月25日 (三) 04:05 (UTC)
2可以讨论，1按照近期状况太可怕了-- Sunny00217  2021年8月25日 (三) 06:26 (UTC)
1的话其实也就是打回原形的意思，所以同上。Sanmosa Outdia 2021年8月25日 (三) 06:47 (UTC)
{{Wikipedia policies and guidelines}}其实也应该改为执行延伸确认保护。Sanmosa Outdia 2021年8月27日 (五) 02:07 (UTC)
反对第2点，讨论很久的延伸确认保护已经确立禁止将其应用于模板（破坏编辑战例外）。--Xiplus#Talk 2021年9月1日 (三) 01:45 (UTC)
共识可以更改，不然的话打回原形变回1我也不是不可以。Sanmosa Outdia 2021年9月2日 (四) 10:08 (UTC)
当然可以，但应该要有相当程度或是更强的共识。我以及自动保护机器人之前都是采取模式1啊，就是自从有人提高保护后，这个非成文豁免就消失了。--Xiplus#Talk 2021年9月4日 (六) 01:26 (UTC)
@Xiplus：那我建议变回1好了，转换组这种东西不适合经常麻烦管理员和模板编辑员，但这样做需要共识通过或修改任何现行规定吗？Sanmosa Outdia 2021年9月8日 (三) 12:54 (UTC)
建议将其加入到Wikipedia:高风险模板#不同条件下的保护方式的门槛值豁免，范例：“但保存转换组语法的模板及模组不受以上引用量限制，一律设为半保护”。--Xiplus#Talk 2021年9月8日 (三) 12:57 (UTC)
我弄一个修改版本出来（但由于我一向也主张{{Wikipedia policies and guidelines}}也应该降低保护级别，所以我也把{{Wikipedia policies and guidelines}}模板写进去）：
现行条文

不同条件下的保护方式 使用永久全保护的条件：

  • 被引用的页面达到100,000+
  • 使用率很高的系统管理或站务模板

基于下列情况可以考虑使用模板保护：

  • 被引用的页面达到5,000+

基于下列情况可以考虑使用半保护：

提议条文

不同条件下的保护方式 使用永久全保护的条件：

  • 被引用的页面达到100,000+
  • 使用率很高的系统管理或站务模板

基于下列情况可以考虑使用模板保护：

  • 被引用的页面达到5,000+

基于下列情况可以考虑使用半保护：

一切保存转换组语法的模板及模组一律不考虑使用模板保护。

以上。@Xiplus。Sanmosa Outdia 2021年9月8日 (三) 13:03 (UTC)

转换组语法有可能达到全保护等级的引用量，建议写在最后面（不缩排）。另外Wikipedia policies and guidelines原先是全保护，但我个人是觉得没有理由全保护或模板保护啦，考虑直接降为半保护，不用写进豁免。--Xiplus#Talk 2021年9月8日 (三) 13:16 (UTC)
可。不过{{Wikipedia policies and guidelines}}保护降级的处理也应该公示一下，公示时要特别提及这点。Sanmosa Outdia 2021年9月8日 (三) 23:43 (UTC)
谨慎反对。高用量转换组的重要性不亚于全局转换规则表，如果后者受到保护，前者理应也受到保护。--菲菇＠维基食用菌协会 2021年9月13日 (一) 20:47 (UTC)
@PhiLiP：此案不妨碍引用量达到100,000+的转换组施行全保护，因此希望阁下澄清是否反对引用量少于100,000但逾5,000的转换组改用半保护。Sanmosa Outdia 2021年9月14日 (二) 04:39 (UTC)
我觉得100,000的门槛太高（已经覆盖1/12的条目），但也同意5,000的门槛略低。提至10,000或者20,000（施加全保护）我便可以接受。--菲菇＠维基食用菌协会 2021年9月21日 (二) 04:15 (UTC)
@Xiplus：请求现施行模板保护的转换组的引用数。Sanmosa Outdia 2021年9月27日 (一) 09:01 (UTC)
Wikipedia:数据库报告/高引用量模板列表，资料有点旧，但应该可供参考。--Xiplus#Talk 2021年9月27日 (一) 09:07 (UTC)
这么说来，所有的引用了Module:CGroup/core也没有超过100,000，如果这个修改成行，没有任何一个CGroup模版够得上全保护的门槛。我维持前述反对：施加全保护的下限就应该是5,000，10,000都嫌多。--菲菇＠维基食用菌协会 2021年10月5日 (二) 03:31 (UTC)
按照这个说法其实Module:NoteTA也是只能用半保护（文字游戏 囧rz……），要求修改文句-- Sunny00217  2021年9月21日 (二) 03:25 (UTC)
并非。Module:NoteTA现时使用全保护，此后仍为全保护。Sanmosa Outdia 2021年9月27日 (一) 09:03 (UTC)

可以为用户讨论页申请半保护么？

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

如题。原因当然是为了挡住IP用户的扰乱--我是火星の石榴（留言） 2021年10月20日 (三) 06:16 (UTC)

可以啊，那位最勤奋的前管理员的讨论页就多次被半保护过--Milky·Defer 2021年10月20日 (三) 17:43 (UTC)
(＊)提醒@MilkyDefer：被WMFBAN的用户不是金日成家族，没有必要避讳。--爬行数码1903高雄火灾46死 2021年10月23日 (六) 09:07 (UTC)

提议所有已经关闭的讨论自动“延伸确认保护”，避免被破坏

包括Wikipedia_talk:维基百科不是什么/存档6以及Wikipedia:当前的破坏/存档/2021年10月等页面，已经显示“下列讨论已经关闭，请勿修改。如有任何意见，请至合适的讨论页进行，并不要再次编辑本讨论。”或者“本页是以往讨论的存档。请勿编辑本页。若您想发起新讨论或重启现有讨论，请在当前讨论页进行。”了，在此建议“延伸确认保护”（可由机器人自动延伸确认保护），避免存档被恶意破坏。2402:7500:900:6C90:18C0:1A08:3D8E:25F1（留言） 2021年12月10日 (五) 07:35 (UTC)

WP:ECP：不得对尚未发生的破坏或编辑战进行预见性保护。--安忆Talk 2021年12月10日 (五) 07:41 (UTC)
@AnYiLin：照你的逻辑，被永久封禁的使用者页面也不应该保护。2402:7500:900:6C90:18C0:1A08:3D8E:25F1（留言） 2021年12月10日 (五) 07:51 (UTC)
或者你也可以考虑设置过滤器来禁止这些页面被编辑（我不知道目前有没有这样的过滤器）。2402:7500:900:6C90:18C0:1A08:3D8E:25F1（留言） 2021年12月10日 (五) 07:52 (UTC)

WP:高风险模板引入延伸确认保护

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

翻查至下依然暂时难以找到说服社群引入的证据似乎整个高风险模板讨论中都没什么实际证据，雪球关闭吧。ghren🐦吱吱吱...🔊 2021年12月10日 (五) 03:55 (UTC)
下列讨论已经关闭，请勿修改。如有任何意见，请至合适的讨论页进行，并不要再次编辑本讨论。
̩不同条件下的保护方式

使用永久全保护的条件：

被引用的页面达到100,000+

  • 使用率很高的系统管理或站务模板

基于下列情况可以考虑使用模板保护：

  • 被引用的页面达到5,000+

基于下列情况可以考虑使用延伸确认保护：

  • 被引用的页面达到2,500+

基于下列情况可以考虑使用半保护：

  • 被引用的页面达到500+
  • 维基百科工具模板
  • 使用率较低的管理或站务模板

引入延伸保护后没有对此指引进行更新，引致现在“跳级式”保护的问题，希望参考英维的相关指引引入。--ghren🐦吱吱吱...🔊 2021年11月30日 (二) 11:24 (UTC)

设立延伸确认保护就已经决定不适用于模板了（WP:ECP：“不得将延伸确认保护使用于破坏或编辑战以外的页面上，应直接使用全保护（对于模板或模组可用模板保护）”），条目亦不适用模板保护，同属“跳级式保护”，跳级式保护根本不是一个问题。--Xiplus#Talk 2021年11月30日 (二) 12:15 (UTC)
@Xiplus：共识是可以更改的，WP:ECP有如此条文大可以废除。虽然跳级式保护未必在所有情况下都会构成问题，但在对模板、模组页的保护方式中多加一个intermediate并非坏事。Sanmosa WAM 2021年12月1日 (三) 02:24 (UTC)
@Sanmosa：共识可以改变不是可以任意推翻有充分讨论决议的借口，该但书是通过该方针重要的协商成果，我相信提案人应该是未充分了解该方针设立的要旨就鲁莽提出新议案（从“引入延伸保护后没有对此指引进行更新”可看出提案人根本没注意到““不得将延伸确认保护使用于破坏或编辑战以外的页面”这规定），所以我才解释给他听。--Xiplus#Talk 2021年12月1日 (三) 03:08 (UTC)
我是知道WP:ECP的相关规定的，我比较希望对应指引有了结论之后才倒过来引入去ECP这处。这处是我没说清楚。英维是虫虫飞引入前一两个月才决定要在模板中引入延伸保护的。[2]但我承认这议案是属于一些“WP:没坏别修”的情况，提的时候有点不太谨慎。ghren🐦吱吱吱...🔊 2021年12月1日 (三) 03:17 (UTC)
@Ghrenghren：那么您应该说明为什么需要在模板实施延伸确认保护，现有的半保护为何不足？--Xiplus#Talk 2021年12月1日 (三) 04:25 (UTC)
别忘了英文维基百科的自动确认门槛比我们低很多，这应该是他们普遍认为半保护不够的原因。--Xiplus#Talk 2021年12月1日 (三) 04:43 (UTC)
“共识可以改变不是可以任意推翻有充分讨论决议的借口”，所以才会有VPP啊。而且要留意的一点是WP:ECP是在OA前通过的，因此不能排除通过前的讨论有被带风向的情形，那该但书的存在必要性也是值得怀疑的。--Sanmosa Immortal 2021年12月1日 (三) 10:22 (UTC)
所以我才解释清楚并请提案人也解释清楚提案理由啊，您拿共识可以改变反驳我很奇怪，说的好像是共识必须每个月都改变一样--Xiplus#Talk 2021年12月1日 (三) 11:45 (UTC)
我记得当时的讨论不是只有我一个提出过延伸确认保护可用于模板或模组的保护。--Sanmosa Immortal 2021年12月2日 (四) 14:27 (UTC)
Lopullinen提出过可以给使用量大的CGroup上ECP，而非模版保护。--Milky·Defer 2021年12月3日 (五) 01:53 (UTC)
这个也是一个理由，还有一个问题就是有部分LTA是会去更改一些比较高风险，多人使用的模板。就像是LTA:X43这样的，像{{进制}}已经被antigng实行了延伸确认保护。引入之后能够解决LTA破坏模板的问题。LTA编辑数过50并不是很难的事情。--ghren🐦吱吱吱...🔊 2021年12月3日 (五) 11:28 (UTC)
当初引入延伸确认保护理由之一就是为了应对LTA，本来就适用破坏保护规定的，现行就可以进行保护，不能混为一谈。--Xiplus#Talk 2021年12月3日 (五) 11:33 (UTC)
方针写的是“不得将延伸确认保护使用于破坏或编辑战以外的页面上”，这个是适用于破坏保护的。但假如将高引用模板的条件引入，X43这样的情况的破坏就可以得到预见性的阻止。毕竟{{进制}}是个4000引用的模板，破坏很容易延伸至其他页面。--ghren🐦吱吱吱...🔊 2021年12月3日 (五) 15:03 (UTC)
方针禁止对破坏行为进行预见性保护。--Xiplus#Talk 2021年12月4日 (六) 04:03 (UTC)
不是这个意思，我是想说明任何破坏又或者单纯改坏的风险都会扩大至所有模板身上而己，无论是善意改坏也好，还是恶意破坏也好。另外也有个LTA去动{{中华民国与越南关系}}，我没意搞破坏预见性保护，当然高引用量模板的风险本身是有破坏风险存在的。--ghren🐦吱吱吱...🔊 2021年12月4日 (六) 17:44 (UTC)
如果您要主张LTA会进行破坏，那就是按照破坏进行个别保护，不然您就举出非LTA进行破坏的例子。--Xiplus#Talk 2021年12月5日 (日) 00:46 (UTC)
只靠编辑次数自动授权的延伸确认用户≠半个通过人工批准的模板编辑员。--安忆Talk 2021年12月3日 (五) 11:40 (UTC)
你的立场是？--ghren🐦吱吱吱...🔊 2021年12月4日 (六) 17:46 (UTC)
(－)倾向反对，我还没有看到合适的理由。--安忆Talk 2021年12月5日 (日) 04:46 (UTC)
(－)反对。 2021年12月4日 (六) 18:45 (UTC)
(－)倾向反对：同Xiplus--A1Cafel（留言） 2021年12月6日 (一) 04:03 (UTC)
本讨论已经关闭，请勿修改。如有任何意见，请至合适的讨论页进行，并不要再次编辑本讨论。

“延伸确认保护”改为“延伸保护”或“延伸半保护”

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

如题。只允许“自动确认用户”或“确认用户”编辑的保护类型叫做“半保护”，而不叫“自动确认保护”或“确认保护”；那么只允许“延伸确认用户”编辑的保护类型也应该叫做“延伸保护”或“延伸半保护”，而不是“延伸确认保护”。本人提议将“延伸确认保护”改为“延伸保护”或“延伸半保护”，现征求大家的意见。--12З4567（留言） 2021年10月19日 (二) 16:08 (UTC)

不赞同。前者有语意残缺的问题。后者又“延伸”又“半”，中文不是黏着语。Sanmosa WÖRK 2021年10月20日 (三) 01:32 (UTC)
我觉得提案可行。@Sanmosa：半保护也不叫“确认保护”，无所谓语意完整；“延伸半保护”是通顺的，跟黏着语毫无关系。--Lt2818（留言） 2021年10月20日 (三) 03:46 (UTC)
不好意思，我还是感觉语感有问题。Sanmosa WÖRK 2021年10月20日 (三) 04:01 (UTC)
“延伸”这两个字本来就很翻译腔，我觉得不如叫“强保护”。 --维基续命师R(Edit) 2021年10月20日 (三) 04:23 (UTC)
本来“延伸确认用户”就很翻译腔，为什么不是“进阶确认保护”？--ghren🐦吱吱吱...🔊 2021年10月20日 (三) 04:35 (UTC)
简而言之，因为“进阶”具有浓厚阶级意味不适合采用，而且“延确”简称念起来也比较顺口。您是不是没有参与之前的译名讨论？—— Eric Liu 创造は生命（留言．留名．学生会） 2021年10月20日 (三) 08:55 (UTC)
不如叫“四分之三保护”，因为以前的自动确认可编辑的保护叫“半保护”（二分之一保护）。——Sakamotosan路过围观杯弓蛇影 | 避免做作，免敬 2021年10月21日 (四) 01:46 (UTC)
有没有反对，没有，没有，通过，更名作“四分之三保护”。[开玩笑的]ghren🐦吱吱吱...🔊 2021年10月21日 (四) 03:53 (UTC)
我认真地觉得“四分之三保护”与“半保护”“（全）保护”更加具有一致性。--Yangwenbo99论 诚邀诸君参与自主隔离运动 2021年10月22日 (五) 01:44 (UTC)
社群是认真的吗。。。这不就哈利波特的梗。--ghren🐦吱吱吱...🔊 2021年10月23日 (六) 15:09 (UTC)
不如改回“扩展保护”、“扩展确认用户”，“延伸”过于翻译腔了，而且连选词都不好选的。HotaruTalk 2021年10月21日 (四) 07:53 (UTC)
(＋)支持扩展保护。 --维基续命师R(Edit) 2021年10月21日 (四) 07:58 (UTC)
考虑到目前的译名，建议作“强保护”。 ——魔琴 [ 已经告假 留言 贡献 ] 2021年10月21日 (四) 14:56 (UTC)
“弱保护”=“半保护”，“强保护”=“延伸保护”，“铁幕”=“全保护”？“未保护”=未保护？——Sakamotosan路过围观杯弓蛇影 | 避免做作，免敬 2021年10月22日 (五) 01:43 (UTC)
“强保护”会使人误以为强过“（全）保护”。--Yangwenbo99论 诚邀诸君参与自主隔离运动 2021年10月22日 (五) 01:45 (UTC)
全是完全的意思，什么会比完全强呢？ ——魔琴 [ 已经告假 留言 贡献 ] 2021年10月24日 (日) 03:04 (UTC)
“强”的比较对象是什么？了解维基百科方针的读者会知道，是相对于“半保护”。但对于不了解维基百科方针的读者，“全”保护会自然而然地被认为是“普通”的“保护”，而半保护则是部分执行的“保护”。所以可能会被当作比“全保护”还要强。--Yangwenbo99论 诚邀诸君参与自主隔离运动 2021年10月26日 (二) 06:38 (UTC)
不反对“扩展保护”不带确认二字，但反对Hotaru提出将“延伸确认”改成“扩展确认”，完全不顺口；既然以往都没有跟随用户组命名保护名称的习惯，扩展保护无需跟从“延伸确认”的名称。当初用“延伸确认保护”纯粹是因为其他语言都是extended confirmed protection。--路西法人 • 留言 2021年10月22日 (五) 04:53 (UTC)
取名做“扩展保护”可能被误会比“（全）保护”层级要高，还不如“扩展半保护”。—— Eric Liu 创造は生命（留言．留名．学生会） 2021年10月22日 (五) 06:42 (UTC)
但“延伸半保护”与“扩展半保护”都是黏着语的情形。另一种办法是将半保护改称“（自动）确认保护”。Sanmosa WÖRK 2021年10月22日 (五) 09:57 (UTC)
¾保护感觉不错Nrya ✰我听见有个声音～ 2021年10月23日 (六) 14:47 (UTC)
“四分之三保护”意外的还蛮直觉的，或可采用。—— Eric Liu 创造は生命（留言．留名．学生会） 2021年10月23日 (六) 15:02 (UTC)
要考虑“四分之三保护”在不同地方的语文的语感。我的感觉是语感还是不太对。Sanmosa WÖRK 2021年10月24日 (日) 02:35 (UTC)
四三保护[开玩笑的] ——魔琴 [ 已经告假 留言 贡献 ] 2021年10月24日 (日) 03:08 (UTC)
上方提的“强保护”，我觉得可以将“半保护”改叫“弱保护”（Cwek提的）。 ——魔琴 [ 已经告假 留言 贡献 ] 2021年10月24日 (日) 03:08 (UTC)
我很确定后面加了狗头。看来数量还是不太够。——Sakamotosan路过围观杯弓蛇影 | 避免做作，免敬 2021年10月25日 (一) 06:23 (UTC)
确实，但仔细思考一下我是资瓷的（毕竟半保护确实很弱 ——魔琴 [ 已经告假 留言 贡献 ] 2021年10月25日 (一) 08:58 (UTC)
个人(－)强烈反对“四分之三保护”，这种表达更像是为了显示这种保护介于半、全之间而表达，看上去很奇怪，如果要突出介于全、半的属性，可以考虑把“半保护”改作“一级保护”，“延伸确认保护”改作“二级保护”，“全保护”不变或改为“三级保护”。HotaruTalk 2021年10月24日 (日) 10:33 (UTC)
这种也行Nrya ✰我听见有个声音～ 2021年10月24日 (日) 12:11 (UTC)

候选名称

序号 名称 提案人 备注
1 延伸保护 12З4567
2 延伸半保护 12З4567
3 扩展保护 Hotaru Natsumi
4 扩展半保护 Ericliu1912
5 强保护 Ruincrez
6 四分之三保护 Cwek
7 二级保护 Hotaru Natsumi “半保护”改为“一级保护”

粗略的统计了一下，我觉得现在可以开一个投票了。（欢迎补充）--12З4567（留言） 2021年10月26日 (二) 04:49 (UTC)

还有“维持原状”。—— Eric Liu 创造は生命（留言．留名．学生会） 2021年10月26日 (二) 06:28 (UTC)
还有反过来将半保护改称“（自动）确认保护”。Sanmosa WÖRK 2021年10月26日 (二) 15:30 (UTC)
芝，看来狗头都没啥用了。一个开玩笑的例子怎么能上位了？ 囧rz……——Sakamotosan路过围观杯弓蛇影 | 避免做作，免敬 2021年10月27日 (三) 01:37 (UTC)
反正开玩笑的页面我也能写认真的版本。基本上提案看起来能用的话都能上去，我们不排除任何的可能性。Sanmosa WÖRK 2021年10月27日 (三) 01:44 (UTC)
搞定图标投票再扔过去开启新投票吧。--路西法人 • 留言 2021年10月27日 (三) 02:18 (UTC)
  • (※)注意：“延伸确认保护”原文为Extended confirmed protection，在电脑科技名词的语境下，按照《英、繁、简电脑专有名词对照表 1.4》（cpatch_core14.zip）作者黄国书（Kii Ali）在2003年修订的“Extended”一词对照如下：
英文 繁体中文 简体中文
extended Backus-Naur Form 延伸巴克斯格式 扩展巴克斯格式
extended Stored Procedure 延伸预存程序 扩展预存程序
extended object 扩充物件 扩充对象
extended properties 扩充特性 扩充特性
extended style 延伸样式 扩展样式
（以上内容取自glossary_basic.csv，修订者kiiali, 2003/05/01）
因此需留意，如果最后结果决定Extended在简体中文译作“扩展”时，请一并在NoteTA繁体中文标签下同时转换成“延伸”或“扩充”。--章安德鲁（留言） 2021年10月27日 (三) 19:13 (UTC)
问题来了，延伸确认使用者之译名已经确定，是否转换？抑或重新选择译名？—— Eric Liu 创造は生命（留言．留名．学生会） 2021年10月27日 (三) 20:40 (UTC)
事实上是“延伸”这个词在简体语境下几乎不被使用，更广泛的使用是“扩展”，这一点从输入法选词就可以看得出来了。个人支持对译名进行转换，对于简体使用者显示“扩展”，繁体使用者显示“延伸”。HotaruTalk 2021年11月1日 (一) 11:28 (UTC)
话说如果要进行转换的话，候选名称的1、3，2、4可以合并。HotaruTalk 2021年11月1日 (一) 11:30 (UTC)

Wikipedia:投票/修改各级保护用名。--路西法人 • 留言 2021年11月7日 (日) 10:17 (UTC)

@12З4567、Sanmosa、Lt2818、Ruincrez、Ghrenghren、Ericliu1912、Cwek、Yangwenbo99、Hotaru Natsumi、Nrya、@魔琴、Ohtashinichiro。--路西法人 • 留言 2021年11月7日 (日) 13:14 (UTC)

投票现已结束。关于投票的意见和问题，应在此处讨论。--12З4567（留言） 2021年12月8日 (三) 04:50 (UTC)

由于本次投票前并未讨论投票规则相关事项，投票中出现了票数非常接近的问题，现讨论是否应当再次进行投票（即另开一个页面重新投票，非第二轮投票），以更好地达成共识。--12З4567（留言） 2021年12月8日 (三) 05:31 (UTC)

我认为提案之间应当有冷却期，要不然选完不满意就再选，直到选出符合某些人想法的方案就不选了，成何体统。—— Eric Liu 创造は生命（留言．留名．学生会．STE） 2021年12月8日 (三) 08:23 (UTC)
投票规则11月9日就提出，直到投票开始11月22日前都可以进行讨论，既然没人有异议，也没有“无法执行投票结果”的问题，投票自当有效并确定结果。--Xiplus#Talk 2021年12月8日 (三) 11:14 (UTC)
关于“票数非常接近的问题”，投票规则已经明订“最高票选项获选，若有同票则进第二轮投票”，若“差距0票”就“进第二轮投票”，若“差距1, 2, 3...票”则“最高票选项获选”，完全没有问题。--Xiplus#Talk 2021年12月8日 (三) 11:16 (UTC)
投票后有用户对规则提出合理异议，则投票仍然有效，但结果仅供参考，不得执行；且应在冷却期后重新制定投票规则，再次投票。本人拟在2022年2-3月重新发起10个选项的投票。--12З4567（留言） 2021年12月9日 (四) 16:02 (UTC)
并无所谓“对规则有异议结果即不得执行”之说。且以本次投票来说，执行结果与否皆无影响。—— Eric Liu 创造は生命（留言．留名．学生会．STE） 2021年12月9日 (四) 22:45 (UTC)

决定界面保护图标

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

候选图标

选项 图标 提案人 提案理念 备注
1 Chubit·📞
2 Milky·Defer
3 Milky·Defer
4 Winston Sung（留言）

讨论

--Chubit·📞 2021年11月8日 (一) 09:49 (UTC)

重提转换组模板及模组改用半保护的提案

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

现重提转换组模板及模组改用半保护的提案，原因之一与上次提案的理由一样：“转换组模板属内容系模板，需要时常更新，且技术含量不高”，另一原因是转换组模板属较低风险的模板（容易理解语法与维护的模板），不适宜使用模板保护。提案包括对Wikipedia:高风险模板#不同条件下的保护方式的修改（1）与对Wikipedia:保护方针#模板保护的修改（2），谨列出如下：

1
现行条文

不同条件下的保护方式 使用永久全保护的条件：

  • 被引用的页面达到100,000+
  • 使用率很高的系统管理或站务模板

基于下列情况可以考虑使用模板保护：

  • 被引用的页面达到5,000+

基于下列情况可以考虑使用半保护：

提议条文

不同条件下的保护方式 使用永久全保护的条件：

  • 被引用的页面达到100,000+
  • 使用率很高的系统管理或站务模板

基于下列情况可以考虑使用模板保护：

  • 被引用的页面达到5,000+

基于下列情况可以考虑使用半保护：

Module:CGroup/core外的所有保存转换组语法的模板及模组一律不适用模板保护，最多仅能使用半保护。

2
现行条文

模板保护

模版保护
模版保护
方针快捷方式

受到模板保护的页面只能由管理员或模板编辑员编辑。但只能用于模板命名空间及模块命名空间。模板保护只适用于被引用的页面超过5,000的高风险模板，也由于风险因素，模板保护相当于全保护。

此保护级别是为了取代仅是高风险模板而受到的全保护而设立。较低风险的模板不适用模板保护，仅能使用半保护。

提议条文

模板保护

模版保护
模版保护
方针快捷方式

受到模板保护的页面只能由管理员或模板编辑员编辑。但只能用于模板命名空间及模块命名空间。模板保护只适用于被引用的页面超过5,000的高风险模板，也由于风险因素，模板保护相当于全保护。

此保护级别是为了取代仅是高风险模板而受到的全保护而设立。较低风险的模板与Module:CGroup/core外的所有保存转换组语法的模板及模组均不适用模板保护，最多仅能使用半保护。

以上。考虑到Module:CGroup/core本身定义了转换组语法机制，我把它排除在只能使用半保护的范围外（我个人建议提升为全保护）。@Xiplus。Sanmosa A-DWY3 2022年1月23日 (日) 12:48 (UTC)

就最好不要有人不小心改坏，我没什么好说的。--Xiplus#Talk 2022年1月23日 (日) 12:59 (UTC)
@Xiplus：有没有先前改坏的例子？（现在是半保护或无保护的都行）--Sanmosa A-DWY3 2022年1月23日 (日) 13:21 (UTC)
不常关注CGroup，不知道。--Xiplus#Talk 2022年1月23日 (日) 14:50 (UTC)
反对半保护，太容易达到要求了。--东风（留言） 2022年1月23日 (日) 15:18 (UTC)
@Easterlies：我想澄清一下，你的意思是反对对所有保存转换组语法的模板及模组施行任何程度的保护？Sanmosa A-DWY3 2022年1月24日 (一) 05:17 (UTC)
我比较倾向延伸保护，不过上次的讨论我好像没有参加，不清楚其他人的想法。--东风（留言） 2022年1月24日 (一) 05:34 (UTC)
@Easterlies：那你直接看下面我与Xiplus的说明就可以了，之前Xiplus明确表明延伸确认保护不能这样用（在不修改保护方针的延伸确认保护部分的前提下）。连同保护方针的延伸确认保护部分一同修改理论上不是不可以，但我感觉这更容易让提案难产。Sanmosa A-DWY3 2022年1月24日 (一) 05:43 (UTC)
我的想法是保护等级大于半保护，小于等于模板保护。自动确认太容易达到，高引用量模板模块不宜允许过多的人有权限进行编辑，而字词转换这类模板模块的复杂性确实不如其他模板模块，再加上模板编辑员不多，处理这类请求的模板编辑员相对来说更少一点，所以我觉得或者下调保护等级，或者为有志处理这类请求的用户授权，处理人手足够的话，也就不需要变更保护等级。--东风（留言） 2022年1月24日 (一) 06:17 (UTC)
“自动确认太容易达到”担心的是什么？“处理人手足够的话，也就不需要变更保护等级”那么解决方法应该是让处理人手足够，您自己都说了，变更保护等级不是正确的解决方法。--Xiplus#Talk 2022年1月24日 (一) 06:23 (UTC)
以前抱怨管理员处理编辑请求慢，所以设立了模板编辑员，现在抱怨模板编辑员处理编辑请求慢，不知道还能怎样处理。--Xiplus#Talk 2022年1月24日 (一) 06:41 (UTC)
当时“抱怨管理员处理编辑请求慢”这点好像不止在说转换组模板及模组，就其他模板及模组来说，现时的机制还是足够快的。--Sanmosa A-DWY3 2022年1月24日 (一) 13:15 (UTC)
那么为什么转换组特别慢？前次提出来不就说公示7天就能改了吗？不符合这个条件？--Xiplus#Talk 2022年1月26日 (三) 07:35 (UTC)
@Xiplus如果主条目的1=和转换组定义不一致，即其他条目的用词和主条目不一致，这对读者是很不友好的。不要说7天，7个小时都特别慢。--洛普利宁 2022年1月26日 (三) 07:50 (UTC)
等待7天是能够让别人提出潜在的问题，如果您直接改，您能保证不会有转换错误？您要为转换错误负责？在其他条目造成转换错误对读者就友好？--Xiplus#Talk 2022年1月26日 (三) 07:55 (UTC)
@Xiplus：电子游游戏转换组模板开放编辑十几年，很少出现问题。我认为自动确认用户自发维护就够。模板编辑员熟悉技术但未必熟悉领域命名规则（如WP:VG/GL），我认为强势介入意义不大。改错再退回来就可以，影响不了多少条目，只要不是恶意破坏就没多大责任。--洛普利宁 2022年1月26日 (三) 08:16 (UTC)
模板编辑员当然不一定熟悉相关领域，模板编辑员只需要负责确认语法没问题就行了，所以才要等7天让相关领域的编辑者来指出地区词本身有没有问题。--Xiplus#Talk 2022年1月26日 (三) 08:21 (UTC)
@Xiplus：内容方面我是认为不需要每次讨论7天。
WP:VG指出条目内容应当使用常用名称（即和条目同名）。如果编者修改条目转换，则意味着他修改主题常用名称，因此其他条目名称也需要更改，这就需要变更转换组。电子游戏领域，这一套工作以往都是放给一般用户去做的，而且做得还不错。
编者自己认为可能有争议的会主动发起讨论（比如Mario大陆译名“马里奥”改官方译名“马力欧”这种影响真的重大的）。剩下影响不了多少条目的，相信编者对于命名常规的理解就好。
少逗号作废整个转换组当然是个问题。但能找到转换组的编辑都有一定水平，我是认为不需要太担心。如果能设过滤器提示当然也不错。
我是认为转换组除了破坏影响大量页面，其他和移动页面再更新其他条目的文字属于一个类别。而后者普通编辑是有能力负担这个责任的。
模板编辑员无语法错误直接批准，延伸保护预防性避免简单刷50次编辑破坏，或者和以前一样半保护，这三种做法我认为都可以。内容方面承担得起先修改后补票的错误，技术上没什么难度，等7天拉长战线是没什么必要。—洛普利宁 2022年1月26日 (三) 09:57 (UTC)
我觉得比照很久之前用半保护好了，有破坏再依照条目标准升级保护。--Xiplus#Talk 2022年1月27日 (四) 05:27 (UTC)
@Xiplus：更改模板实质内容至少要七天无异议，但主条目的手工转换又是可以即时更新。这样就算模板编辑员人手再够也没用啊，总有七天是主条目转换和其他条目转换不一致。上次我问能不能转换组无需讨论直接更新，又没人给个话。
以游戏转换组为例。现在一个游戏条目名在转换组中有定义；有编者要调整游戏译名，一看转换组模版保护，就嫌麻烦直接在主条目里加了个1=。这就造成该条目和其他条目用词不一致，不利于条目维护。现在作为模板编辑员，现在我是技术原因径自更新转换组，还是把他的1=回退掉让他提交编辑请求？
现在高风险的意义是什么？如果担心反复parser，我们又有“不要担心性能”。如果担心变更内容影响页面效果，那只需要锁定出现在5000个条目中的规则（许多规则只有几十个页面使用，半保护都不够格）。如果担心恶意破坏影响上千页面，那既然500+调用能预防性半保护，何又规定不能预防性进阶保护？
另一个角度考虑，转换组或许只是占了模板空间的非模版。假设新开一个转换组名字空间，或者直接把转换组定义放到WikiProject下。这就不会受模板保护制约，但也都说得通？--洛普利宁 2022年1月26日 (三) 07:42 (UTC)
回应第2行：您自己提编辑请求，7天后修改；回应第3行：确实改坏一个转换规则，只会影响少数的页面，但如果少个括号逗点，就会影响5000+个页面了，而这都是编辑同一个页面造成的，我们不可能在保护上区分这两个风险，延伸确认保护回应见下；回应第4行：高风险模板保护（其一）是根据引用量执行，跟命名空间无关。--Xiplus#Talk 2022年1月26日 (三) 08:02 (UTC)
“高引用量模板模组不宜允许过多的人有权限进行编辑”这个我们一直以来都当成金科玉律的规条在我现在看来对于转换组模板及模组而言是不适用的。--Sanmosa A-DWY3 2022年1月24日 (一) 13:17 (UTC)
似乎有提议过延伸确认保护。--GZWDer（留言） 2022年1月23日 (日) 19:34 (UTC)
@GZWDer：之前讨论的意见是延伸确认保护只适用于出现页面被破坏的情形，因此除非有证据表明转换组模板及模组经常广泛地遭到破坏，不然我不认为这能成事。Sanmosa A-DWY3 2022年1月24日 (一) 05:20 (UTC)
@Xiplus：有劳确认一下我的理解是否正确。Sanmosa A-DWY3 2022年1月24日 (一) 05:23 (UTC)
延伸确认使用者不比自动确认使用者有更多对于模板（下称模板皆包含模组）编辑的知识，如果认为半保护不足以防止模板遭到不熟悉语法的使用者意外毁损，就应该使用模板保护，只允许经过能力经过审核的模板编辑员编辑；反之若认为模板不需要模板编辑员的能力即可编辑，就应该仅用半保护。如果半保护不足以应对如同条目会遇到的破坏行为，可以比照保护条目的标准来对特定模板予以延伸确认保护。--Xiplus#Talk 2022年1月24日 (一) 05:41 (UTC)
我的考量是所有转换组模板及模组的语法基本上一样，如果半保护不足以防止转换组模板及模组遭到不熟悉语法的用户意外毁损，那理论上就算相关转换组模板及模组使用量低，也应该予以模板保护，但现时施行半保护的或并无施行保护的转换组模板及模组未有遭到不熟悉语法的用户意外毁损的情形，所以我建议全部最多使用半保护处理即可。--Sanmosa A-DWY3 2022年1月24日 (一) 05:49 (UTC)
部分转换组模组被模板保护的考量点仅仅是引用量高而已（意思是意外遭到毁损会影响多少个页面），跟转换组语法本身简单还是复杂无关，就算转换组语法简单到几乎不会改错，被毁损所影响到页面数量仍是技术上事实存在的风险，就看社群能否接受这个风险而已，而高引用量模板高层级保护就是在降低这个风险。--Xiplus#Talk 2022年1月24日 (一) 06:01 (UTC)
那我自己是觉得这个风险是可接受的（这对于其他用户而言是一个取舍，但对我来说这个选择是毋庸置疑的）。Sanmosa A-DWY3 2022年1月24日 (一) 13:13 (UTC)
建议延确保护--Wiki emoji | 😷🅔🅜🅞🅙🅘🅦🅘🅚🅘😷 祝百毒不侵～ 2022年1月24日 (一) 13:39 (UTC)
@Emojiwiki：我直接请你见上Xiplus的解说好了，我自己是不乐意让提案难产的。Sanmosa A-DWY3 2022年1月24日 (一) 14:14 (UTC)
@Sanmosa 我这个就是因为考虑到风险高而别自动确认那么简单，又需要时常更新，故采延确保护为佳。 Wiki emoji | 😷🅔🅜🅞🅙🅘🅦🅘🅚🅘😷 祝百毒不侵～ 2022年1月24日 (一) 23:46 (UTC)
我认为转换组模板及模组不属于高风险模板。--Sanmosa A-DWY3 2022年1月25日 (二) 07:11 (UTC)
不属于高风险模板，所以不应该进行任何保护吗？--Xiplus#Talk 2022年1月26日 (三) 07:31 (UTC)
但至少要让更多的人edit-accessible。--Sanmosa A-DWY3 2022年1月26日 (三) 11:51 (UTC)
不保护就是完全的accessible了。--Xiplus#Talk 2022年1月26日 (三) 12:04 (UTC)
或许我的用词不太准确：我认为转换组模板及模组不属于高于半保护级别保护的高风险模板。--Sanmosa A-DWY3 2022年1月26日 (三) 13:55 (UTC)
对于未达半保护标准的转换组应该是不保护还是半保护？--Xiplus#Talk 2022年1月27日 (四) 05:29 (UTC)
不保护。我“不属于高于半保护级别保护的高风险模板”这句话中的“高于半保护级别保护的高风险模板”是一个完整词语，没有保护的模板并不在“高于半保护级别保护的高风险模板”的范围内。Sanmosa A-DWY3 2022年1月28日 (五) 08:57 (UTC)
“一律不适用模板保护”有仍可使用全保护的歧义，“仅能使用半保护”有不得不保护的歧义。改成“...的模板及模组最高使用半保护”比较好吧？--Xiplus#Talk 2022年1月28日 (五) 12:30 (UTC)
可，你看看我这样改是否可以。--Sanmosa A-DWY3 2022年1月29日 (六) 02:53 (UTC)
同意Sanmosa的观点，采用模板保护方式保护转换组不利于公共转换组维护。PATLABOR 英格拉姆Ingram Talk 2022年1月26日 (三) 15:11 (UTC)
另外第二部分的修订，转换组并没有“较低风险”，只是社群容许使用较低保护而已，此修订与技术事实不符。--Xiplus#Talk 2022年1月28日 (五) 12:36 (UTC)
这部分我已经连同“仅能使用半保护”的部分一同调整了。--Sanmosa A-DWY3 2022年2月1日 (二) 12:54 (UTC)
我觉得没必要同一个条文同时写在两处，再说一个方针一个指引，那这条文究竟是方针还是指引。--Xiplus#Talk 2022年2月2日 (三) 11:31 (UTC)
Wikipedia:高风险模板是Wikipedia:保护方针的延伸，因此既是方针，亦是指引。Wikipedia:高风险模板与Wikipedia:保护方针两者有一定程度上的差别，考虑到指引需要细节性、方针具备优位性，我觉得还是有必要两边都写，否则要么就会出现条文意义不明的问题，要么就会出现条文互相冲突的问题。--Sanmosa A-DWY3 2022年2月3日 (四) 09:42 (UTC)
“既是方针，亦是指引”无法理解您的逻辑。--Xiplus#Talk 2022年2月3日 (四) 12:30 (UTC)
方针说模板可以（但非必须）用模板保护，至于具体怎么样的模板应该用模板保护，用下级的指引来规定比较合适吧，而且与现存于高风险模板指引的其他规则一起列出。--Xiplus#Talk 2022年2月2日 (三) 11:33 (UTC)
见上。--Sanmosa A-DWY3 2022年2月3日 (四) 09:43 (UTC)

关于再次进行更新保护方针图示投票

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

否决：
提案数日无任何支持，反而有大量反对，且提案人明显对投票相关规范的理解有根本性的谬误，提案人亦完全无法针对反对者提出的问题作出妥当的回应，属没有被程序接受的可能的提案，按雪球法则关闭此次讨论。--路西法人𖤐 2022年3月8日 (二) 09:19 (UTC)
下列讨论已经关闭，请勿修改。如有任何意见，请至合适的讨论页进行，并不要再次编辑本讨论。

我想到以下几个更好凡保护图示：

意思：

  • 一支笔代表编辑保护
  • 加号代表白纸保护
  • 向右箭头代表移动保护
  • 向上箭头代表上传保护

届时，页面的右上角可能会出现两个保护图示。

另外，将会弃用。

获得共识后会开设投票。

若有其他图片提议或意见，欢迎在下面讨论。--以上未签名的留言由Cyron Choi（讨论｜贡献）于2022年3月3日 (四) 09:51 (UTC)加入。

这样根本看不清右上角的图案。--安忆Talk 2022年3月3日 (四) 10:42 (UTC)
你有什么改进版本？Choi Chin Long 2022年3月3日 (四) 10:49 (UTC)
我没有，但不妨碍我说出问题。--安忆Talk 2022年3月3日 (四) 10:56 (UTC)
很好。用放大镜才能看得到，充分考验读者视力。--Ghren🐦🕖 2022年3月3日 (四) 11:02 (UTC)
否。不佳。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年3月3日 (四) 11:07 (UTC)
(－)反对per Ghren( π )题外话提案发起人没有签名，谁发表的？--在下荷花，请多指教（欢迎签到） 2022年3月3日 (四) 11:16 (UTC)
Why?现在的版本又有什么问题？没坏别修-某人✉ 2022年3月3日 (四) 11:10 (UTC)
别尬黑，放大镜都看不出哪个是哪个，不信你们浏览器缩放一下，看看右边几个图标(示)：，看看渲染成了什么样子 ——魔琴 [ 留言 贡献 ] 2022年3月3日 (四) 12:03 (UTC)
其实发布此信息的原意是获得把白纸保护、移动保护和上传保护的共识。Choi Chin Long 2022年3月3日 (四) 12:34 (UTC)
这是在Firefox上缩放500%的显示效果.
魔琴和Cyron Choi如右图, 能看到3个“+” 囧rz……。--Yining Chen（留言|签名页） 2022年3月3日 (四) 13:59 (UTC)
意念很完美，现实很残酷。不是每个人都有心情放大五百倍看。(＋)支持理念，但请改变一下实现方式。 Wiki emoji | 😷🅔🅜🅞🅙🅘🅦🅘🅚🅘😷 祝百毒不侵～ 2022年3月3日 (四) 23:50 (UTC)
例如，锁头上面的颜色？ Wiki emoji | 😷🅔🅜🅞🅙🅘🅦🅘🅚🅘😷 祝百毒不侵～ 2022年3月3日 (四) 23:51 (UTC)
这里不是讨论我的图片，而是讨论是否支持把白纸保护、移动保护、上传保护分拆开。Choi Chin Long 2022年3月4日 (五) 01:38 (UTC)
你发起讨论的标题是更新保护的图示，当然大家就会在讨论这个啊...——〚 玖宸 〛 2022年3月4日 (五) 02:09 (UTC)
看了一下，右上角的icon应该20px正方的，修正一下显示：

如果不放大页面，还是能看出保护信息的话，可以考虑一下。——Sakamotosan路过围观 | 避免做作，免敬 2022年3月4日 (五) 02:52 (UTC)
勉强。 Wiki emoji | 😷🅔🅜🅞🅙🅘🅦🅘🅚🅘😷 祝百毒不侵～ 2022年3月4日 (五) 02:53 (UTC)
无放大页面
。
很好，只看到个点点，能想出这样的设计果然是天才。——Sakamotosan路过围观 | 避免做作，免敬 2022年3月4日 (五) 02:59 (UTC)
(－)强烈反对
哪个天才大聪明，如此设计新图形。
不要人夸设计好，但留微臣俩眼睛。
@_@--Pavlov2（留言） 2022年3月7日 (一) 18:23 (UTC)
Wiki emoji | 😷🅔🅜🅞🅙🅘🅦🅘🅚🅘😷 祝百毒不侵～ 2022年3月4日 (五) 03:00 (UTC)
这里不是讨论我的图片的！！--Choi Chin Long 2022年3月4日 (五) 03:25 (UTC)
那列出这些图标干嘛？？这是坏了吗¿——Sakamotosan路过围观 | 避免做作，免敬 2022年3月4日 (五) 03:31 (UTC)
讨论是否支持把白纸保护、移动保护、上传保护分拆开。Choi Chin Long 2022年3月4日 (五) 03:43 (UTC)
真看不出有这样意思。一来一开始的图标设计实际使用就很有问题；二来对于白纸、移动、上传是否需要精细到按用户级别显示更差异的图标，有这样的需要？或者说管理员有这样的需要？——Sakamotosan路过围观 | 避免做作，免敬 2022年3月4日 (五) 05:49 (UTC)
看到问题吗？
Choi Chin Long 2022年3月4日 (五) 07:56 (UTC)
这是哪个页面的移动保护？最多只能说明信息不清晰，没有说清楚移动保护后只能哪些人员进行移动操作。——Sakamotosan路过围观 | 避免做作，免敬 2022年3月4日 (五) 08:02 (UTC)
首页Choi Chin Long 2022年3月4日 (五) 08:06 (UTC)
问题是移动保护分为延伸确认保护、模板保护和全保护三个阶层，只看不会知道的。Choi Chin Long 2022年3月4日 (五) 08:12 (UTC)
啊是不会阅读旁边的文字吗？如果把所有资讯都包含在图示里面，写文字干嘛？--Xiplus#Talk 2022年3月6日 (日) 05:33 (UTC)

如果你看过延确保护的图标投票的话，就应该知道最开始那个设计的加号都被抱怨说小了。现在你搞的这个比刚开始的那个加号还要小，这说不过去吧。 --MilkyDefer 2022年3月4日 (五) 06:37 (UTC)

大概明白了，意思就是四种针对用户级别的页面编辑保护（自动、延伸、模板编辑、管理员）和剩余几种行为保护（白纸、移动、上传）的图标区分不清晰，因为后者是可以附加用户级别的，但图标上区分不出。很难说是坏了，好像后面少见附加其他用户级别，附加管理员的会常见的。但这套图标也是给页面右上角的icon使用，现有这个设计的这些信息“现实残酷”。——Sakamotosan路过围观 | 避免做作，免敬 2022年3月4日 (五) 08:08 (UTC)
我的建议是，如果真的要把上传、移动、白纸体现在图标中，可以考虑把锁改成箭头或加号。 ——魔琴 [ 留言 贡献 ] 2022年3月4日 (五) 10:33 (UTC)
其实原本的计划是经这里讨论后就建立投票页，投票开始前欢迎用户加入自己设计，再投选哪个设计更好。Choi Chin Long 2022年3月4日 (五) 11:11 (UTC)
没坏别修。更何况这几个设计都不怎么样，可见性太差了。 三万光年 GBAW 2022年3月5日 (六) 00:05 (UTC)

2.0 version：保留保护级别图标，颜色代表保护范围。今次应该不会再“意念很完美，现实很残酷”了吧……Choi Chin Long 2022年3月5日 (六) 03:41 (UTC)

如果需要区分，应该从两个维度来区分：图标代表行动类型，颜色代表用户级别。图标尽可能在低尺寸下也要足够清晰。——Sakamotosan路过围观 | 避免做作，免敬 2022年3月5日 (六) 04:52 (UTC)
可能需要管理员的参与，其他非编辑的保护行为对于用户级别的设定差异度有多大（例如移动保护多为全保护还是自动确认多），技术上这些现有的体系能否实现支持或者需要适配。感觉这些由技术方向的管理员提出并实施会更适合。——Sakamotosan路过围观 | 避免做作，免敬 2022年3月5日 (六) 04:56 (UTC)
好点了吗？Choi Chin Long 2022年3月5日 (六) 05:37 (UTC)
你要知道，当时说要改延确图标的原因就是光靠颜色区分对色弱色盲人士不友好。--MilkyDefer 2022年3月5日 (六) 05:13 (UTC)
看MilkyDefer君这么一说，也觉得光靠颜色来区分还是算了吧，不过以前的保护图标就是光靠颜色来区分的哦。--🔨（留言） 2022年3月6日 (日) 01:29 (UTC)
我用色盲滤镜看过，没有什么大问题。Choi Chin Long 2022年3月6日 (日) 02:23 (UTC)
全色盲人士还是不行啊。没坏别修，现在提案人比较像是为修而修。——〚 玖宸 〛 2022年3月6日 (日) 14:51 (UTC)
请问维基百科有多少个全色盲用户呢？Choi Chin Long 2022年3月7日 (一) 08:20 (UTC)
(※)注意维基百科本来就应该要照顾所有色盲/色弱读者，不一定仅包括是编者。维基百科本来就不是“编者自己写好看的”，本应考虑照顾全球有色盲/色弱的人。您的言行好似在歧视色盲/色弱/或其他色彩障碍患者似的，相当不妥。见此Template_talk:Isotope_nav#同位素模板颜色更换已有先例大篇幅讨论如何照顾色盲患者，提案者疑似想草草带过在此(！)强烈抗议，我没有色盲/色弱，但我愿声援色盲/色弱抗战到底！。维基百科是国际网站，应相当谨慎的处理，谴责随便呼拢色盲的行为。-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鲜果茶☕]（☎️·☘️） 2022年3月7日 (一) 08:29 (UTC)
呼叫颜色纠察队@Zero00072：-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鲜果茶☕]（☎️·☘️） 2022年3月7日 (一) 08:35 (UTC)
保护图示并不是读者用的东西，仅用来维护维基百科。Choi Chin Long 2022年3月7日 (一) 13:15 (UTC)
我并没有歧视他们！Choi Chin Long 2022年3月7日 (一) 13:16 (UTC)
没有歧视他们那为何要很故意地要硬推无法照顾他们的提案？-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鲜果茶☕]（☎️·☘️） 2022年3月7日 (一) 14:07 (UTC)
好了，我明天有时间做一个新版本了。Choi Chin Long 2022年3月7日 (一) 14:09 (UTC)
我是觉得，不要为改而改。——〚 玖宸 〛 2022年3月7日 (一) 15:48 (UTC)
感谢 PING。感觉都是保护，差别不大。重点是锁头，区别不是很重要。我对此保持(＝)中立。--赤迷迭（留言） 2022年3月8日 (二) 03:07 (UTC)
其实，以前的保护图示就很不照顾全色盲人士。2019年开始扁平化+往里面塞图标之后当然就变得对全色盲人士友好一些了。--🔨（留言） 2022年3月8日 (二) 03:38 (UTC)
用颜色区分保护范围难看，(－)反对--SunAfterRain 2022年3月7日 (一) 11:22 (UTC)
请提案人@Cyron Choi先解释一下非要更新保护方针图示的原因，不然这整个讨论就都没有意义。——〚 玖宸 〛 2022年3月7日 (一) 16:18 (UTC)
Choi Chin Long 2022年3月8日 (二) 00:20 (UTC)

File:Protection locks.png终于改善完成了！Choi Chin Long 2022年3月8日 (二) 01:38 (UTC)

(...) 吐槽这……最后一个有点像墓碑。 Wiki emoji | 😷🅔🅜🅞🅙🅘🅦🅘🅚🅘😷 祝百毒不侵～ 2022年3月8日 (二) 01:43 (UTC)
除此之外还有什么问题？Choi Chin Long 2022年3月8日 (二) 01:51 (UTC)
还是算了吧，越改越可怖（ —— Eric Liu 創造は生命（留言・留名・学生会） 2022年3月8日 (二) 01:52 (UTC)
我照样会建立投票，投票开始前希望看一下其他用户的design。Choi Chin Long 2022年3月8日 (二) 02:02 (UTC)
“我照样会建立投票”，WP:投票：如投票是关于方针与指引和其他重大事项，宜先在维基百科:互助客栈得到相应讨论，然后按照多数人的意见发起投票，并应该事先在公告栏公告1至2日以后再进行正式的投票。多数人的意见是这些图标存在极大问题，不适合使用，完全不符合进行投票的条件。--路西法人𖤐 2022年3月8日 (二) 03:05 (UTC)
这是什么？人头变成一枝铅笔、人头变成一个加号，太猎奇了吧，维基百科不是恐怖故事。你至少也参照某个心理学学派来设计吧。颜色、图案不够用你可以改变锁的外框阿，非得硬挤在一起很难识别。且这个设计已经用得很极限了，建议不要为改而改。-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鲜果茶☕]（☎️·☘️） 2022年3月8日 (二) 03:45 (UTC)
图标区分不清晰这其实是一个历史遗留问题了，不论是2019年开始用新图标还是这之前只用颜色来区分保护类型及级别的时期都是如此的，当然这个问题也不仅限于本站有，印象中别的语言版本也都是一样的情况。改善确实可以考虑，只要技术上允许，不过如果没有能够让大家满意的新图标设计的话，倒还不如继续维持原样。--🔨（留言） 2022年3月8日 (二) 03:33 (UTC)

囧rz……事后发现只要放大一些右上角图案就可以了 Choi Chin Long 2022年3月8日 (二) 03:40 (UTC)

就连这个png都这么清楚。Choi Chin Long 2022年3月8日 (二) 03:45 (UTC)
赞 Wiki emoji | 😷🅔🅜🅞🅙🅘🅦🅘🅚🅘😷 祝百毒不侵～ 2022年3月8日 (二) 03:47 (UTC)
从美观上我仍然不支持这个方案。 而且缩到20px后我看大概几个之间也不太能分辨得出来。——〚 玖宸 〛 2022年3月8日 (二) 04:30 (UTC)
因为这是个png。Choi Chin Long 2022年3月8日 (二) 04:37 (UTC)
并不是。不管什么档案格式，缩很小加号和箭号本来就都超难分辨，故仍然(－)反对-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鲜果茶☕]（☎️·☘️） 2022年3月8日 (二) 04:47 (UTC)
把移动箭头变成绿色、把上传箭头变成紫色、把加号变成浅蓝色，怎么样？--Choi Chin Long 2022年3月8日 (二) 08:09 (UTC)
还有，铅笔在左上角，移动箭头在右上角，加号在左下角，上传箭头在右下角，不会影响色盲人士。Choi Chin Long 2022年3月8日 (二) 08:16 (UTC)
越改越晕头转向。。。。。拜托别再折腾了好吗-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鲜果茶☕]（☎️·☘️） 2022年3月8日 (二) 08:23 (UTC)
一齐使用的效果。Choi Chin Long 2022年3月8日 (二) 08:45 (UTC)
单一使用的效果。Choi Chin Long 2022年3月8日 (二) 08:52 (UTC)
本讨论已经关闭，请勿修改。如有任何意见，请至合适的讨论页进行，并不要再次编辑本讨论。

Afd合并遗留重定向问题

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

可否规定如果afd讨论结果为合并的话将遗留重定向设为永久半保护？因为发生很多次新用户将关注到合并的重定向手动回退到原本版本的事件。毕竟就算这些关注度重定向的后来关注度发生改变，以致其可以重建条目，程序上也应该是先到drv而不是直接重建。这些重定向理论上应无编辑需要-某人✉ 2022年3月24日 (四) 11:52 (UTC)

虽然可预想数量是很多，但实际比例是多少？这个比例有高到需要从“遇到问题再保护”（保护方针要旨）变成“不论情况一律保护”吗？--Xiplus#Talk 2022年3月24日 (四) 12:04 (UTC)
方针死的人是活的。容我反问就这样留下来不保护意义何在？反正又没有合理理由需要编辑。比例我不知道，但至少我自己回退的我记得的至少已经超过十几次--某人✉ 2022年3月24日 (四) 12:10 (UTC)
需要保护的是遭受破坏的页面，没有人编辑就保护根本没道理。--Xiplus#Talk 2022年3月24日 (四) 13:46 (UTC)
现在不是因为没有人编辑所以就保护，是因为有高机会受破坏而且没有必要编辑所以才保护--某人✉ 2022年3月24日 (四) 17:42 (UTC)
“高机会”所以我上面问这个机会究竟是多少，有超过50%吗？--Xiplus#Talk 2022年3月25日 (五) 01:31 (UTC)
技术上除了半保护与过滤器外，还有没有其他机制能阻止新用户进行特定编辑操作的？Sanmosa Avec cœur 2022年3月24日 (四) 12:27 (UTC)
过滤器是最灵活的机制了，不然您希望有怎么样的机制？--Xiplus#Talk 2022年3月24日 (四) 13:47 (UTC)
没有，我就只是想问一下技术上操作的可能性而已。我觉得真要处理这问题的话，用过滤器是不错的选择。Sanmosa Avec cœur 2022年3月25日 (五) 00:36 (UTC)
Wikipedia talk:删除方针/存档5#关于过滤器阻止曾被存废复核通过还原或存废讨论予以保留的条目再挂上notability或提删无效 过滤器做不了才提这个方案吧。--Ghren🐦🕛 2022年4月3日 (日) 04:54 (UTC)
反对永久保护，但支持理念；建议加模板标记并使用过滤器阻挡并提示。--路西法人𖤐 2022年3月24日 (四) 12:04 (UTC)
反对永久保护，但可适当标记追踪。—— Eric Liu 創造は生命（留言・留名・学生会） 2022年3月24日 (四) 14:10 (UTC)
现有{{R FAILS N}}和Special:滥用过滤器/185但是印象中在关注度不足而合并时并非每次皆有使用该模板。--（留言） 2022年3月24日 (四) 16:26 (UTC)
这滥用过滤器185真的没问题吗……从原理上--MilkyDefer 2022年3月24日 (四) 17:36 (UTC)
时刻跟踪Special:相关更改/Category:关注度重定向会不会更好些？--MilkyDefer 2022年3月24日 (四) 17:41 (UTC)
无法，准确来说应该要跟踪该分类的“成员近期变更”而非“相关变更”，一旦页面从分类移除，就不会出现在相关变更中，但这个修改会记录在近期变更上。--Xiplus#Talk 2022年3月28日 (一) 07:45 (UTC)

提议更换Mediawiki保护标志

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

鉴于目前模板保护与Mediawiki保护标志相同，我与User:FoolPiasar设计与制作了一版标志：

橙色和mw图标代表Mediawiki，代表保护是由Mediawiki自动作出的。

--中维金苹果，时不时给维基人们加buff（留言） 2022年4月1日 (五) 00:04 (UTC)

(＋)支持 Buenos※Días 2022年4月1日 (五) 01:12 (UTC)
可以的。--Tranve (✉) 2022年4月1日 (五) 01:43 (UTC)
(？)疑问：这个标志中有锯齿状圆环，但是缩小到一定程度后完全看不出锯齿图案。所以为什么不直接使用光滑的圆环呢？--Yining Chen（留言|签名页） 2022年4月1日 (五) 01:56 (UTC)
因为那样就不是mediawiki了啊（笑--InsaneGuo（留言） 2022年4月1日 (五) 01:59 (UTC)
Telegram群里面已经有人反映了此问题，我已经上传了一版新的（由于这几个名字我全部写错了，已经提出移动请求，移动后别忘了把这里的改了）--中维金苹果，时不时给维基人们加buff（留言） 2022年4月1日 (五) 02:07 (UTC)
(＋)支持 十分好康 --InsaneGuo（留言） 2022年4月1日 (五) 01:56 (UTC)
(！)意见：一看就知道各位不记得过往讨论了吧…… --MilkyDefer 2022年4月1日 (五) 02:44 (UTC)
囧rz……--中维金苹果，时不时给维基人们加buff（留言） 2022年4月1日 (五) 03:10 (UTC)
(＋)支持Abcd715（留言） 2022年4月5日 (二) 01:59 (UTC)
感觉可以，反正现时使用中的保护标志并无环状图案，就算看成“O”也没太大关系。Sanmosa Avec cœur 2022年4月6日 (三) 07:46 (UTC)
如果一定要这样想也不是不行，但是明明有更适合小图标的mw花瓣版本--MilkyDefer 2022年4月6日 (三) 13:02 (UTC)
是指File:MediaWiki-2020-small-icon.svg吗？我也是觉得如果能用这个标志做成保护图标效果更好。--BlackShadowG（留言） 2022年4月7日 (四) 12:05 (UTC)
(＋)支持--以上未签名的留言由孟天皓（讨论｜贡献）于2022年4月8日 (五) 13:31‎ (UTC)加入。
(＋)支持--罗洁塔🍰463292 2022年4月11日 (一) 07:00 (UTC)
方针内混杂了“保护层级”（自确、延确等）、“保护类型”（编辑、移动等）和“保护原因”，“MediaWiki保护”是一种保护原因，其包括两种保护层级为全保护跟界面管理员保护，而Wikipedia:保护方针#MediaWiki保护章节所使用的图示指的是“界面管理员保护层级”而非“MediaWiki保护原因”（参见英文维基百科en:Wikipedia:Protection policy#Interface protection、en:Template:Protection table，图示为），因此本提案想决定MediaWiki保护的图示，我认为并不适合。--Xiplus#Talk 2022年4月11日 (一) 12:02 (UTC)
缺乏的是界面管理员保护层级图示，现时借用模板保护的图示（因为同样都是技术工作）。--Xiplus#Talk 2022年4月11日 (一) 12:05 (UTC)
我觉得把File:New MediaWiki protection shackle.svg直接定作界面管理员保护层级图示也不是不可以，毕竟File:New MediaWiki protection shackle.svg上的锯齿状圆环图案并非真正的MediaWiki标志，至于底色是否要换成棕色我没意见。Sanmosa Avec cœur 2022年4月13日 (三) 08:39 (UTC)
(－)倾向反对锯齿真的太小了，一个圆环当界面保护的图案太诡异了 囧rz……--SunAfterRain 2022年4月14日 (四) 14:31 (UTC)

关于被全域锁定的用户页

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

本站对于已经永久封禁但未创建的用户页会通过机器人直接采取全保护的措施（也就是白纸保护），而是否应该扩展到被全域锁定的用户页。另外对于一些拥有愉快犯倾向的例如SLIME、QCHM则不宜创建或标记用户页。

大多数情况下被全域锁定的维基人都是LTA，极少数情况下是已被确认过世的用户，例如U:Ig2000。而白纸保护被全域锁定的用户页似乎很有必要--Buenos※Días 2022年4月22日 (五) 03:53 (UTC)

@Seele2021：我先提醒一点的是，全保护与白纸保护并不等同，全保护页面只能由管理员进行编辑，而白纸保护既有可能是阻止非自动确认用户创建一条目，又有可能是阻止非延伸确认用户/管理员创建。也就是说，在受保护权限的层级方面而言，全保护是白纸保护的充分不必要条件。--绍💓煦四季如春 2022年4月22日 (五) 21:00 (UTC)
其次，若是全域锁定，在该用户在本地未有贡献的情况下，继续标注Global banned或进行PDP没有意义，阁下是否还记得两个月前的类似事件？--绍💓煦四季如春 2022年4月22日 (五) 21:20 (UTC)
就这么不受控，非要技术手段禁止才能不去做吗？--Xiplus#Talk 2022年4月23日 (六) 01:51 (UTC)

延伸确认保护和半保护的区别

如题，在该方面延伸确认保护的具体操作，影响？和半保护的区别。 Hzt1234 eletrionicengineer（留言） 2022年5月11日 (三) 10:01 (UTC)

WP:EXTENDEDCONFIRMED--YFdyh000（留言） 2022年5月11日 (三) 10:17 (UTC)

小修改提议

维基百科的方针和指引（半保护＋移动保护）。 => 维基百科的方针和指引（永久半保护＋移动保护）。--QiuLiming1（清理小作品 讨论） 2022年6月21日 (二) 21:40 (UTC)

取自“https://zh.wikipedia.org/w/index.php?title=Wikipedia_talk:保護方針/存檔4&oldid=78261917”