跳至內容

維基百科討論:保護方針/存檔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://wikicn.playgoteam.workers.dev/w/index.php?title=Wikipedia_talk:保護方針/存檔4&oldid=78261917」