維基百科討論:用戶權限級別

成為自動確認用戶後,長時間不登陸賬號,賬號會怎麼樣?

下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

各位前輩大家好,我現在已經是自動確認用戶了,但是因為工作的原因,可能沒法每天都登陸維基百科,我想請教一下,如果我長時間(如一周/一月)不登陸維基百科,也不再有新的編輯,我現在的賬號會怎麼樣?等我之後再次登的時候還會是自動確認用戶麼?還是說會變成用戶界面不存在呢?希望可以得到各位前輩的解答,十分感謝!--Zsllong留言2021年7月26日 (一) 05:59 (UTC)回覆

是;什麼都不會變。--安憶Talk 2021年7月26日 (一) 06:12 (UTC)回覆
沒有權限職務的話,沒有變化。——Sakamotosan路過圍觀杯弓蛇影 | 避免做作,免敬 2021年7月26日 (一) 06:44 (UTC)回覆
可能會由於長期不編輯跳掉ipbe?但自動確認用戶是不是就有ipbe了--祝編安--pavlov2留言2021年7月26日 (一) 09:02 (UTC)回覆
沒有。您對這些東西還真的是一點都不熟悉啊。--Lightyears GBAW 2021年7月26日 (一) 09:04 (UTC)回覆
不是由於某人說疑似我不是新手嘛,懷疑我是wp:SPA,我得跟您說我確實是新手。我不熟悉。--祝編安--pavlov2留言2021年7月27日 (二) 14:02 (UTC)回覆
都可以建立兩岸四地甚麼會了還......-- Sunny00217  2021年7月30日 (五) 01:11 (UTC)回覆
自動確認用戶權限除了濫用過濾器,其他人吊銷不掉。 --Milky·Defer 2021年7月26日 (一) 13:12 (UTC)回覆
好的,我曉得了,非常感謝各位前輩的解答!我確實對這些都不是很熟悉,之前沒有接觸過呢,正在一點點的積纍經驗。感恩!--Zsllong留言2021年7月27日 (二) 01:48 (UTC)回覆
啊抱歉,之前我說的那句話不是對您說的。--Lightyears GBAW 2021年7月27日 (二) 02:01 (UTC)回覆
沒關係的。--Zsllong留言2021年7月27日 (二) 08:24 (UTC)回覆

本討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

設置新的保護類型

無共識:
下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

維基百科部分條目被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)回覆
這樣的話確實和模板保護有點重複。我有個反建議:延伸確認保護可以拿來處理人事任免投票資格@Lanwi1SANMOSA Σουέζ 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:SOPWP:BB的原則? 那樣的話,當時允許IP用戶編輯就是一個錯誤的決定. 最後讓維基百科變得與百度百科沒有任何區別. --Yining Chen留言|簽名2021年7月17日 (六) 07:42 (UTC)回覆
@Yining Chen:延伸確認保護不能亂用的,只有半保護無法保護的情況下,才能用,而且可以減少用「全保護」,所以不違反WP:SOPWP:BB,此外也與ip編輯無關,因為半保護下,ip也不能編輯,但您不因此反對半保護,防止破壞也很重要。--蟲蟲飛♡♡→♡℃留言 2021年7月17日 (六) 08:07 (UTC)回覆

本討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

引入延伸確認保護(第二稿)

已通過:
已公示七天,有關延伸確認用戶權及延伸保護的條文修訂已通過。--蟲蟲飛♡♡→♡℃留言 2021年7月24日 (六) 10:13 (UTC)回覆
下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

現根據第一稿的少數反對意見修訂如下,重新公示七天:

現行條文
提議條文
延伸確認權限條件
  1. 帳號已註冊3個月。
  2. 已經編輯500次。
  3. 符合條件後,系統自動授權。
延伸確認權保護
  1. 只能由延伸確認用戶編輯。
  2. 在半保護無法阻止破壞時才能用。
  3. 在半保護無法阻止的編輯戰時才能用。

以上。--蟲蟲飛♡♡→♡℃留言 2021年7月17日 (六) 10:13 (UTC)回覆


本討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

延伸確認權限後續討論 part1

反正你們都同意我也不管了,結-- Sunny00217  2021年7月28日 (三) 01:02 (UTC)回覆
下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

  • (※)注意:討論已超過一個月,最後一個修訂版公示七天期間,完全沒有人反對,共識很明顯。--蟲蟲飛♡♡→♡℃留言 2021年7月26日 (一) 04:27 (UTC)回覆
    蟲蟲飛:我不同意這是個合符程序的公示──通過方式是有嚴重瑕疵。有個簡單的問題──一個存在反對意見的提案,在經過修訂後能立即視為已取得共識嗎?顯然不能。提出修訂案後立即進行公示,是不當的。還有關鍵的一點──對原提案進行改良後,應當邀請原提案的反對者參與討論,讓他們知悉有關改動。而這點,蟲蟲飛是做不到的,以致於有反對者未知悉本提案。--Bookwith留言2021年7月26日 (一) 09:03 (UTC)回覆

公示公告的後續討論

  • 大家都在關注,只是您一個人沒關注公告內容和客棧的討論,而且提案已經按照方針規定完成公示14天,但是您在公示期間放棄討論,這是您自己的問題;這就像假設RFA期間您忘記投票,然後投票期結束了,您才出來鬧,這也是您自已的問題。--蟲蟲飛♡♡→♡℃留言 2021年7月27日 (二) 16:25 (UTC)回覆
    蟲蟲飛聲稱大家都在關注,卻出現7天公示期內無人討論的局面,請問這合理嗎?難道沒人提出意見還能視作通過?--Bookwith留言2021年7月27日 (二) 17:26 (UTC)回覆
@Sunny00217:公告欄同類通知應當合併。-- ——羊羊 [ 留言 貢獻 維貓報 古典音樂專題 ] 2021年7月27日 (二) 16:12 (UTC)回覆

本討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

關於權限的疑問

檢視防濫用過濾器非公開詳細資料存取日誌 (abusefilter-privatedetails-log)這個權限具體的作用是什麼?除了詳細資料存取日誌,還有什麼樣的資料存取會被記錄?存取「檢視防濫用過濾器非公開詳細資料存取日誌」是會被記錄的嗎?什麼樣的權限可以看到「存取『檢視防濫用過濾器非公開詳細資料存取日誌』日誌」?--Papayatrash留言2021年8月1日 (日) 13:04 (UTC)回覆

找mw看啊(mw:Extension:AbuseFilter),再不行去en或mw問啊。有可能AF還有一些類似CU的隱藏數據日誌,所以和CU數據一樣對等。——Sakamotosan路過圍觀杯弓蛇影 | 避免做作,免敬 2021年8月1日 (日) 13:24 (UTC)回覆
英文不好啊--Papayatrash留言2021年8月1日 (日) 13:34 (UTC)回覆
沒有隱藏數據日誌,管理員看到的和回退員看到的是一樣,管理員只是可以修改。--蟲蟲飛♡♡→♡℃留言 2021年8月1日 (日) 13:41 (UTC)回覆
@蟲蟲飛:這權限只有cu有--Papayatrash留言2021年8月1日 (日) 13:46 (UTC)回覆
[1]-- Sunny00217  2021年8月1日 (日) 13:42 (UTC)回覆
有看沒有懂--Papayatrash留言2021年8月1日 (日) 13:50 (UTC)回覆

延伸確認權限後續討論 part2

已解決:
優化案已公示七天通過。
下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

回退相關方針編輯:

  • 就人事任免投票資格調整部分,有關公告並未對「人事任免投票資格調整」這類重大事件有任何提及。
  • 就擴展用戶級別部分,個人認為上述討論並未達成非常顯著共識。--DreamerBlue留言2021年7月29日 (四) 01:56 (UTC)回覆

@XiplusLanwi1:這情況需要處理一下。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:X43LTA: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)回覆
@A2569875SANMOSA Σουέζ 2021年7月29日 (四) 05:52 (UTC)回覆
本人認為Tokisaki Kurumi的支持意見有說服力,另外希望各位能注意Lopullinen的意見。--DreamerBlue留言2021年7月29日 (四) 04:02 (UTC)回覆
@DreamerBlue:那原本的提議修改也是不恰當的,因為如果條文只在Lopullinen的情境實施,相關條文需要限制延伸確認保護的適用對象為模板空間和模組空間的頁面。如果能限制延伸確認保護的適用對象為模板空間和模組空間的頁面,並將CGroup與其他適合實施延伸確認保護的受模板保護頁面改用延伸確認保護,那我會支持如此提案。SANMOSA Σουέζ 2021年7月29日 (四) 05:52 (UTC)回覆
能否說下您為何堅持僅讓擴展保護適用於模板和模組?--ときさき くるみ 2021年7月29日 (四) 06:32 (UTC)回覆
因為這是Lopullinen的提案,如果連帶其他東西也適用的話,那個就不是他的提案,而需要當成另一個提案分開考慮。我現在之所以反對整個提案是因為蟲蟲飛聲稱現在的提案(甚麽也能用的提案)是我的提案,但我一開始的提案就只打算將延伸確認用戶權限用於判別人事任免投票資格。SANMOSA Σουέζ 2021年7月29日 (四) 06:42 (UTC)回覆
好的,知道了。--ときさき くるみ 2021年7月29日 (四) 07:42 (UTC)回覆
編輯衝突 × 4)  吐槽@Sanmosa:我在三天就已經問過了,見上方(另外刪除已經存檔的討論內容)。-- Sunny00217  2021年7月29日 (四) 04:02 (UTC)回覆
(※)注意:兩次的提案後續討論都是提到有用戶沒注意到提案,但並非反對提案,因此提案的共識是明顯,可以以「後續討論」的形式讓社群注意一下通過的提案內容也好。--蟲蟲飛♡♡→♡℃留言 2021年7月29日 (四) 04:15 (UTC)回覆
@蟲蟲飛:你有認真閱讀嗎?Sanmosa很明顯是反對的。-- Sunny00217  2021年7月29日 (四) 04:18 (UTC)回覆
延伸確認權附帶投票權是Sanmosa提出的,您為甚麼會認為Sanmosa會反對自己提出的提案呢?DreamerBlue上面也說他支持提案,您之前那個後續討論也說您「不反對」--蟲蟲飛♡♡→♡℃留言 2021年7月29日 (四) 04:22 (UTC)回覆
我說Sanmosa很明顯是反對的,為甚麼會有您之前那個後續討論也說您「不反對」?!-- Sunny00217  2021年7月29日 (四) 04:25 (UTC)回覆

想吐槽的是這種公示方法,貼出來就要公示且沒貼在佈告板,結果沒半個人留言,並非反對提案,謝謝-- Sunny00217 2021年7月26日 (一) 11:33 (UTC)

那句話如果是在說我的話,我完全沒説過我「不反對」提案,甚至我在2021年6月28日 (一) 00:23 (UTC)以後就沒有在那個討論串留過言SANMOSA Σουέζ 2021年7月29日 (四) 05:45 (UTC)回覆
  • (※)注意:延伸確認權附帶投票權是Sanmosa提出的,然後其他人支持,而且在公示期沒有反對意見下通過的。--蟲蟲飛♡♡→♡℃留言 2021年7月29日 (四) 05:57 (UTC)回覆

    這樣的話確實和模板保護有點重複。我有個反建議:延伸確認保護可以拿來處理人事任免投票資格。@Lanwi1。SANMOSA Σουέζ 2021年6月27日 (日) 01:18 (UTC)

    我認為當時其他人反對我那個提議,或至少並無對我那個提議表示支持。整個討論除了我自己和明確不贊同我的提議的人以外,所有人都只在討論編輯戰或LTA的問題SANMOSA Σουέζ 2021年7月29日 (四) 06:01 (UTC)回覆
    • 當時很多人支持您的提議,如我和宇帆都大力支持,然後在公示14天期間完全沒有反對下通過。--蟲蟲飛♡♡→♡℃留言 2021年7月29日 (四) 06:05 (UTC)回覆
      看漏了,我能確定你和他當時是支持我的提議的,但要注意的一點是我的提議是將延伸確認用戶權限用於判別人事任免投票資格(而且還是要把延伸確認用戶權限的獲取資格設定為人事任免投票資格)。而且,就算是僅將延伸確認用戶權限用於判別人事任免投票資格的提議,除了你們兩個外,就只有Lanwi1和Xiplus就此表達過意見,而他們兩個都是反對我的提議的,而且反對理由充分,因此也看不到有將延伸確認用戶權限用於判別人事任免投票資格的共識。把你們四個和我自己排除後,就真的沒人對我那個提議表示任何意見(包括支持意見)了,我認為應該理解成他們對我的提議不屑一顧。A2569875現在所希望做到的東西(處理LTA)並不是我一開始提議的東西。SANMOSA Σουέζ 2021年7月29日 (四) 06:13 (UTC)回覆
    • Lanwi1和Xiplus是覺得單純以您的建議作為理據去引入這個權限是不好,然後大家都圍繞這個話題去討論,包括防lta等理據,然後公示期,Lanwi1和Xiplus都沒再反對,而且在sunny 上面的「後續討論」中,Lanwi1還明確表示(+)支持。--蟲蟲飛♡♡→♡℃留言 2021年7月29日 (四) 06:19 (UTC)回覆
      Xiplus的情況應該理解為他對原提案本身並沒有任何的意見,那自然也不包含支持意見。Lanwi1方面我同意你的解讀。但就算如此,原討論串裏確實存在明顯的反對意見,我確實看不出來你有進行妥善處理。SANMOSA Σουέζ 2021年7月29日 (四) 06:30 (UTC)回覆
      「原討論串裏確實存在明顯的反對意見」[來源請求],除了提案通過幾天後出來鬧的,哪個用戶是反對的?只有Yining Chen是提出反對,但在第二稿已經根據他的意見優化提案,而且他在第二稿公示期沒再反對。此外,我看到您已經過去phab那邊反對,我建議在下面優化提案,以形成更明確的共識,而且不建議過去那邊爭論,否則洋人覺得中維很亂,影響將來其他提案的申請。--蟲蟲飛♡♡→♡℃留言 2021年7月29日 (四) 07:05 (UTC)回覆
蟲蟲飛修改此討論的名稱,由「延伸確認權限爭議 part2」改為「延伸確認權限後續討論 part2」[2],我不太贊成這樣的修改,標題是反映原來開始此一討論者的看法,不太確定目前的修改是反映了誰的看法?若只是修改者的看法,我是否也可以修改此一標題,再改為我的看法?--Wolfch (留言) 2021年7月29日 (四) 04:24 (UTC)回覆
其實討論最早的標題是「設置新的保護類型」(原始標題),並複製已存檔的部分,在下刪掉了存檔部分並改成「延伸確認權限爭議 part2」-- Sunny00217  2021年7月29日 (四) 04:27 (UTC)回覆
DreamerBlue本來的標題是「後續討論」,是sunny改為「爭議」的,我覺得提案人原先的標題較佳。--蟲蟲飛♡♡→♡℃留言 2021年7月29日 (四) 04:29 (UTC)回覆
那我沒有意見--Wolfch (留言) 2021年7月29日 (四) 04:48 (UTC)回覆

本討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

優化提案

已通過:
提案已討論兩個月,優化提案已再次公示七天,獲得絕大多數使用者支持,包括:A2569875、DreamerBlue、Lanwi1、Tokisaki Kurumi、Jonathan5566 、Sidishandsome、MCC214、LuciferianThomas、Eric liu、Newbamboo、30000lightyears、Sammypan、A1Cafel、CreeperDigital1903 等。
下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

提案雖然已經通過,但有用戶有疑慮,我建議可以把已經過的提案再優化,以形成更明確的共識,歡迎大家提出優化建議,已經通過的提案如下:
Wikipedia:用戶權限級別#延伸確認使用者(非方針指引)[分案A]
現行條文
提議條文

一個已註冊的用戶會在註冊達90天編輯達500次後自動獲得此權限。該用戶權限允許用戶編輯受到進階確認保護的頁面。機械人以及管理員都自動擁有此權限。

Wikipedia:保護方針#延伸確認保護[分案B]
現行條文
提議條文
 
延伸確認保護

延伸確認保護僅允許延伸確認使用者編輯,該使用者群組會在註冊達90天並編輯達500次時自動授予給註冊使用者。

管理員僅能在頁面已被半保護,且證實半保護仍無法阻止破壞或編輯戰的頁面上使用延伸確認保護。與半保護相同,不得對尚未發生的破壞或編輯戰進行預見性保護。亦不得將延伸確認保護使用於破壞或編輯戰以外的頁面上,應直接使用全保護(對於模板或模組可用模板保護)。

Wikipedia:人事任免投票資格[分案C]
現行條文
  1. 解任投票聯署提出或上任投票開始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個月內至少有一次編輯」好像不能有效提升維基人的積極性(三個月就才來一次,之後又不上來)。--MCC214Sign | 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)回覆
您自己可以另行提出嘛。--MCC214Sign | 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天內至少有一次編輯」,另聯署的門檻也要考慮作出相應調整。--MCC214Sign | 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天)了?--MCC214Sign | 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天。--MCC214Sign | 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)回覆
@Lanwi1Tokisaki KurumiA2569875SidishandsomeMCC214:邀請上面參與了討論的人也發表一下意見。--蟲蟲飛♡♡→♡℃留言 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:太魯閣號),那如何應對?--MCC214Sign | 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)回覆
@BookwithSanmosa:請兩位回應我上面的問題﹗--蟲蟲飛♡♡→♡℃留言 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)回覆
三個提案本身就有相輔相承的作用,少了一個都會使到本身所期望的作用大打折扣。--MCC214Sign | 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。--MCC214Sign | 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,您認為過濾器有用麼?--MCC214Sign | Contributions 2021年8月5日 (四) 12:56 (UTC)回覆
本人看法同MCC214。過濾器繞開太容易,封鎖太死的話假陽性太多。--DreamerBlue留言2021年8月5日 (四) 12:59 (UTC)回覆
我指的是過濾器可以實現和頁面保護類似的效果,您可能理解錯了。--Yining Chen留言|簽名2021年8月5日 (四) 13:06 (UTC)回覆
關注度提報又說可以用過濾器取代半保護,當年我也以為可以,但結果呢?--MCC214Sign | 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月相加。(當然如果社群有意將任免資格提高到這個標準,也是沒問題的。)副知@MCC214Xiplus. ——羊羊 [ 留言 貢獻 維貓報 古典音樂專題 ] 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。--MCC214Sign | Contributions 2021年8月10日 (二) 10:38 (UTC)回覆
移動權是自動確認權的,這個要另外提案討論。--蟲蟲飛♡♡→♡℃留言 2021年8月10日 (二) 07:21 (UTC)回覆

本討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

大量訊息發送者不在本文之列嗎

如題。還是已經列出但我沒找到?--洛普利寧 2021年8月28日 (六) 16:39 (UTC)回覆

@Lopullinen目前沒有列出,應當補充。—— Eric Liu 創造は生命(留言留名學生會 2021年9月6日 (一) 08:03 (UTC)回覆

延伸確認權限後續討論 part3

譯名

話說,社群究竟打算採用延伸確認、擴展確認,還是進階確認作為譯名啊?這三種我都有見過。—— Eric Liu 創造は生命(留言留名學生會 2021年8月2日 (一) 04:06 (UTC)回覆

進階確認吧,聽起來自然一點。--Lt2818留言2021年8月2日 (一) 05:02 (UTC)回覆
之前的情況好像是簡體用「高級確認」、繁體用「進階確認」,建議沿用。SANMOSA Σουέζ 2021年8月2日 (一) 06:51 (UTC)回覆
「進階」具有濃厚階級意味,個人認為「延伸」或「擴展」都比「進階」對新手友善。簡稱而言,「延確」「進確」「擴確」好像也就「延確」最順口。--路西法人留言 2021年8月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)回覆

圖標

下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

當前圖標是藍色的鎖裏頭一個人,與半保護的圖標只有配色上的差別,其意義恐難以與半保護做出區分。順便套用C區討論的一個論點,對於色盲/色弱人士他們難以區別這兩個保護。因此我提議修改圖標。個人初步想法是在人的旁邊放個加號之類的東西。 --Milky·Defer 2021年8月4日 (三) 02:15 (UTC)回覆

(+)支持:可以把圖標貼出來給大家看一下嗎?--蟲蟲飛♡♡→♡℃留言 2021年8月4日 (三) 02:40 (UTC)回覆

乾脆大家在這些選項當中選一個吧,或者有其他設計者也可提出: --Milky·Defer 2021年8月4日 (三) 06:22 (UTC)回覆


2號的加號太小了,根本看不見。我做了一個加大的版本:

 ——羊羊 [ 留言 貢獻 維貓報 古典音樂專題 ] 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)回覆
其實我是知道的。我改完了。副知@SidishandsomeAnYiLin ——羊羊 [ 留言 貢獻 維貓報 古典音樂專題 ] 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羊羊32521MilkyDeferCreeperDigital1903Sunny00217DreamerBlueXiplusAnYiLinOldmanson:為確保各模板能有共識修改正確顯示為延伸確認保護而不會fallback至其他與保護狀態不符的鎖圖案,先提出提案,在達成共識採用新鎖頭之前暫時採用英維E字鎖,防止新手被誤導或搞亂。--路西法人留言 2021年8月22日 (日) 13:28 (UTC)回覆

(✓)同意--蟲蟲飛♡♡→♡℃留言 2021年8月22日 (日) 13:34 (UTC)回覆
@SanmosaWP:SNOW了這個吧。麻煩幫忙改。--路西法人留言 2021年8月30日 (一) 01:32 (UTC)回覆

半保護之所以有個人頭,可能是在象徵『自動確認用戶』的一大特點 - 已經有了一個賬戶,一個身份,對維有了基本認識。所以我覺得延伸保護有個時鐘,可以象徵『延伸確認用戶』的一大特點 - 已經經過更長時間的認可。有點醜隨便吧,如果有誰覺得這想法還可以的話弄一個好點的吧。 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)回覆

還行嗎? 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)回覆

以上是我製作的兩個新的圖標。第一個是時鐘元素,受上面啟發製作;另一個是鉛筆元素,鉛筆寓意「編輯經驗」。 --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)回覆


本討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

擦邊球

標題添加:羊羊 [ 留言 貢獻 維貓報 古典音樂專題 ]

我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)回覆

建議給予延伸確認用戶「移動時不留重定向」權限

我希望能給予延伸確認用戶移動時不留重定向的權限。延伸確認用戶有一定的經驗,對相關方針較為熟悉。將該權限賦予給延伸確認用戶,能節省掛刪除模板的時間,也能減少管理員重定向刪除工作。因此,我建議賦予延伸確認用戶此權限。 --    2021年11月27日 (六) 11:45 (UTC)回覆

(+)支持(+)跟進,絕對需要。ghren🐦吱吱吱...🔊 2021年11月27日 (六) 11:57 (UTC)回覆
請具體舉例您會在何種情況下使用「移動時不留重定向」權限。--安憶Talk 2021年11月27日 (六) 12:07 (UTC)回覆
比如一個頁面名稱錯誤,需要移動到正確名稱?或者一個模板尚未被使用,需要修改它的名字?桐生ここ[討論] 2021年11月27日 (六) 13:36 (UTC)回覆
例如將草稿頁面移動至正式條目時。--    2021年11月27日 (六) 13:45 (UTC)回覆
那麼二位相信大部分的延伸確認用戶都會這麼理解嗎?他們只是有500次編輯而已,不需要看規則就可以做到500次。最後是會「利用權限於命名爭議中奪取優勢、無視命名爭議而使用權限」,還是會在「重定向符合快速刪除方針或須釋放標題以便另一頁面佔用」時使用。對申請suppressredirect權限的人都應該有這麼一問。--安憶Talk 2021年11月28日 (日) 03:37 (UTC)回覆
@AnYiLin:我覺得就移動戰而言,「利用權限於命名爭議中奪取優勢、無視命名爭議而使用權限」中的「權限」是移動權限本身,而不是「移動時不留重定向」權限。雖然你的這個問題是合理的,但在考慮到我前面説的話的前提下,這個問題是沒有意義的。也因為如此,我不但不反對給予延伸確認用戶「移動時不留重新導向」權限,甚至也如以往一樣主張同時給予自動確認用戶同樣權限。Sanmosa WAM 2021年11月28日 (日) 09:23 (UTC)回覆
(+)支持 減輕了管理員站務負擔。桐生ここ[討論] 2021年11月27日 (六) 13:36 (UTC)回覆
上方R2延伸到用戶頁也就是為了解決這個問題,這樣我不用去掛O1。當然加了也只是少了我的負擔,因為O1有bot處理。--ghren🐦吱吱吱...🔊 2021年11月27日 (六) 15:52 (UTC)回覆
(-)反對,移動時不留重新導向屬於變相刪除的權限,不適宜由經驗尚淺的延確持有,我反而建議讓巡查豁免者持有此權限。--AT 2021年11月28日 (日) 09:20 (UTC)回覆
@AT:我對於巡查豁免者是否適宜(單獨)擁有此權限也有疑慮。雖然我不想針對個別用戶,但我知道有個別巡查豁免者在移動戰中是很STONEWALL的。Sanmosa WAM 2021年11月28日 (日) 09:25 (UTC)回覆
至少比延確好,而且在巡查和回退均持有此權限的前題下,如果要放寬的話,門檻更高的巡查豁免者顯然是應有的選項。--AT 2021年11月28日 (日) 09:38 (UTC)回覆
如果你是這樣的想法的話,考慮到下面Ericliu1912的説法,我也不反對你的見解。下放總是比沒下放好的,雖然我維持不反對給予延伸確認用戶「移動時不留重新導向」權限,但如果只能下放給巡查豁免者我也沒意見。--Sanmosa WAM 2021年11月28日 (日) 10:00 (UTC)回覆
(-)反對:意見同AT閣下。而且要知道,巡查豁免者幾乎必然也是延伸確認使用者啊,就算不是也很大概率以後會是,所以將權限賦予前者必然比後者要佳。—— Eric Liu 創造は生命(留言留名學生會STE 2021年11月28日 (日) 09:43 (UTC)回覆
@Ericliu1912:這不是兩個沒有絕對關聯的東西嗎...?-- Sunny00217  2021年11月28日 (日) 11:31 (UTC)回覆
理論上是可以70個條目然後70個編輯的,不過常理來說不可能。--ghren🐦吱吱吱...🔊 2021年11月28日 (日) 11:38 (UTC)回覆
事實上並不是沒有關聯。當然確實是沒有絕對關聯沒錯。—— Eric Liu 創造は生命(留言留名學生會STE 2021年11月28日 (日) 14:36 (UTC)回覆
(-)反對:延伸確認用戶的要求是「註冊達90天並編輯達500次」,事實上,達到這一要求並不一定需要「對相關方針較為熟悉」,只需要註冊時間滿足要求並且進行了一定次數無大問題的編輯即可。--東風留言2021年11月28日 (日) 14:48 (UTC)回覆
我覺得還是有必要的,例如我今天看到有人不停將中日關係這種社群未有明確共識的,結果我又不能移回,因為我沒有移動覆蓋重定定向的能力。修改一些不合命名假如真的要巡查或者巡免才能做就變成我要不停掛request move,這樣是沒意思的。--以上未簽名的留言由Ghrenghren討論貢獻)於2021年11月28日 (日) 15:24 (UTC)加入。回覆
我敢說申請巡查就是為了這個功能,實際也沒有巡查多少條目  囧rz……Nrya ✰武漢肺炎兩週年•Xi病毒來襲 2021年12月1日 (三) 12:08 (UTC)回覆
不要濫用職權啊,要幹活啊。  囧rz……——Sakamotosan路過圍觀杯弓蛇影 | 避免做作,免敬 2021年12月1日 (三) 12:44 (UTC)回覆
你申請回退權的話比較靠譜一些,一來有「移動時不留重新導向」權限,二來你一定有機會「幹活」。  囧rz……--Sanmosa Immortal 2021年12月2日 (四) 14:39 (UTC)回覆
(-)反對,意見同AT,未能保證延確用戶是可信,不會濫用此功能。--A1Cafel留言2021年12月5日 (日) 03:33 (UTC)回覆
題外話,在下今天寫了一個腳本,能快速發佈用戶命名空間內的草稿。方法:在您的js中加入mw.loader.load('/w/index.php?title=User:魔琴/gadgets/Quick102/Quick102.js&action=raw&ctype=text/javascript');,在用戶命名空間中,按下「更多」里的「快速102」[1],自動將草稿發佈至條目(如,User:Example/sandbox/draft/foo/bar/地球移動至地球),不留重定向(若無此權限則自動標記O1[2])。在下完全不懂js,完全是邊學邊寫,可能有很多問題,希望各位大佬能來測試改進  囧rz…… ——魔琴 [ 已經告假 留言 貢獻 ] 2021年12月5日 (日) 08:46 (UTC)回覆
多個API請求不用Promise/await很容易出問題,$(document).ready套娃,第五行也沒看出有什麼意義。--安憶Talk 2021年12月5日 (日) 11:39 (UTC)回覆
第五行是忘記刪除了  囧rz……(當時用來檢查腳本有沒有載入)。$(document).ready刪了內層的。API真的不會改( ——魔琴 [ 已經告假 留言 貢獻 ] 2021年12月5日 (日) 12:05 (UTC)回覆
https://zh.javascript.info/promise-chaining --安憶Talk 2021年12月5日 (日) 12:51 (UTC)回覆
很努力地看了,看不懂😭(或者也許懂了但不知道怎麼用? ——魔琴 [ 已經告假 留言 貢獻 ] 2021年12月6日 (一) 12:42 (UTC)回覆
(我知道多了一個--) ——魔琴 [ 已經告假 留言 貢獻 ] 2021年12月6日 (一) 13:25 (UTC)回覆

參考資料

  1. ^ 只需要按一次,我不會寫確認窗口和完成提示,倒是加了一個自動刷新頁面的操作,但經測試在移動操作完成之前就刷新完了,所以沒用
  2. ^ 理論上是這樣,我還沒測試過

修訂Wikipedia:用戶權限級別#監督者


現行條文

監督者

擁有監督權限(Suppress)的用戶(監督者)。就可以在接到要求後執行隱藏編輯版本的操作,並可以查看其它監督者的隱藏記錄。

提議條文

監督員

擁有監督權限(Suppress)的用戶(監督員)就可以在接到要求後執行隱藏編輯版本的操作,並可以查看其它監督員的隱藏記錄。

Wikipedia:監督提議修訂本指引。

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

看起來沒什麼問題。--冥王歐西里斯留言2022年10月17日 (一) 05:06 (UTC)回覆

再提取消文件移動員並下放權限

已通過:
提案已通過,phab已被合併,方針已修改。--在下荷花請多指教歡迎簽到2023年3月13日 (一) 13:45 (UTC)回覆
下列討論已經關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。

現今,文件移動員身份組僅有2人,且文件移動需求不高,在本地需移動的文件一般也無特別大的爭議,故再次提議取消文件移動員並將權限下放,個人認為可下放至延伸確認用戶。--在下荷花請多指教歡迎簽到2023年2月11日 (六) 14:04 (UTC)回覆

(+)支持 感覺這個權限組沒什麼意義,建議將該權限進一步下放到自動確認用戶。為避免移動破壞,保留「移動時不留重定向」給延伸確認用戶。第一眼看到這個提案的反應是「什麼,我們還有文件移動員?!」的順頌時祺 ZhaoFJx 2023年2月12日 (日) 02:18 (UTC)[開玩笑的]回覆
我是,另外移動不留重定向在文件移動方面沒有獨立的權限,所以分不出來。--在下荷花請多指教歡迎簽到2023年2月12日 (日) 03:09 (UTC)回覆
唔,如果這樣的話就不要下放了,因為移動破壞也不是不常見。——順頌時祺 ZhaoFJx 2023年2月12日 (日) 03:12 (UTC)回覆
不反對將文件移動權限(movefile)下放到延展確認用戶。但移動後不留原名(suppressredirect)是否也下放到延展有保留。附,現在「文件移動」給了巡查闊免、巡查、文件移動組,「移動後不留原名」給了蘿蔔(bot)組、巡查、回退、跨維基導入。(或者說拿到巡查基本上都能用上)——Sakamotosan路過圍觀 | 避免做作,免敬 2023年2月12日 (日) 05:32 (UTC)回覆
本案不提議下放不留重定向權限。--在下荷花請多指教歡迎簽到2023年2月12日 (日) 06:31 (UTC)回覆
(+)支持下放 movefile 權限至延伸確認使用者並移除檔案移動員使用者群組。--冥王歐西里斯留言2023年2月15日 (三) 03:17 (UTC)回覆
上任日 除權日 用權數
Sanmosa的移動日誌 2021年9月23日 2022年2月1日 0
RyanCray的移動日誌 2020年11月12日 2022年12月7日 17
Minorax 的移動日誌 2019年7月13日 至今 1
TimWu007的移動日誌 2019年10月28日 2020年8月11日 32
和平至上的移動日誌 2018年6月13日 2018年6月17日 0
hehua的移動日誌 2022年2月22日 至今 67

更新於:2023年2月12日 (日) 10:09 (UTC) 再作了一次統計。Ghren🐦🕕 2023年2月12日 (日) 10:11 (UTC)回覆

看起來好像還可以,我是覺得這個需求不是很大可以下放。--在下荷花請多指教歡迎簽到2023年2月12日 (日) 14:01 (UTC)回覆
(+)支持&(!)意見:若下放至擴展確認,不建議取消文件移動員組別,應保留以備自動確認組或是確認用戶組的用戶申請;若下放至自動確認用戶,則支持取消文件移動員組別。另外,個人支持權限下放,文件移動員組別的權限敏感度應當和普通頁面移動權類似,沒有必要加以限制。至於是下放到擴展確認還是自動確認,由於文件方針較普通頁面更嚴,認為先行下放至擴展確認較為合適。H.Natsumi2023年2月12日 (日) 14:53 (UTC)回覆
那也可以。--在下荷花請多指教歡迎簽到2023年2月12日 (日) 15:27 (UTC)回覆
  • (+)支持:就是不知道哪些天兵用戶想出來的類似巡查豁免權一樣的沒屁用權限(有跟沒有意思一樣),這討論看了就真可悲,應當直接廢除這種沒屁用權限才是。還有,這個討論不是應該再邀請熱衷於檔案存廢討論@Wcam來討論才合理嗎?也沒有人提到要是檔案名稱與維基共享資源重複的問題?奇葩。總之,這討論串基本上沒什麼好討論的,獨裁社群就是喜歡把簡單的事情複雜化。--Z7504非常建議必要時多關注評選留言2023年2月13日 (一) 15:53 (UTC)回覆

現在來看基本上都支持下放至延確,但是對於是否取消用戶組似乎還有不同意見,想問一下應不應該取消呢?個人是傾向取消,但是需要處理的移動文件分類可以保留。--在下荷花請多指教歡迎簽到2023年2月15日 (三) 06:05 (UTC)回覆

我個人傾向取消,畢竟中文維基百科目前的延伸確認使用者已有三千多人,都已經是英文維基百科的檔案移動員人數的十倍左右了(不過英文維基百科的檔案移動員僅有 movefile 而無 suppressredirect 權限),保留檔案移動員使用者權限群組無甚必要,要找到延伸確認以上權限的使用者協助移動也不困難。--冥王歐西里斯留言2023年2月15日 (三) 06:37 (UTC)回覆
@S8321414中文的文件移動員也沒有不留重定向。--在下荷花請多指教歡迎簽到2023年2月15日 (三) 07:49 (UTC)回覆
那麼更沒有問題了,更何況 movefile 在管理員、巡查員與巡查豁免都有,就算自確沒有,要找到有此權限的人也應當不困難。--冥王歐西里斯留言2023年2月15日 (三) 08:30 (UTC)回覆
個人提議如果下放擴展確認仍保留文件移動員組別的原因其實就是Minorax的權限申請,確實無法排除存在跨域貢獻者願意參加本地文件移動的可能性,而目前中文維基百科的擴展確認門檻較高(如果先前沒有自動創建中文的賬號則需要等待90天),合理認為這樣會影響到跨域貢獻者的貢獻(雖然可以提交移動請求,但是顯然對於這一類人直接授權來的更好)。H.Natsumi2023年2月15日 (三) 08:40 (UTC)回覆
這個也確實,@S8321414 您怎麼認為?--在下荷花請多指教歡迎簽到2023年2月15日 (三) 12:00 (UTC)回覆
我個人還是傾向廢除檔案移動員群組,但暫時保留還算是可接受的選項(不過這個暫時不知道有多久就是了)。--冥王歐西里斯留言2023年2月15日 (三) 12:45 (UTC)回覆
@Hotaru Natsumi:經查,Minorax已係延確。另:個人建議檔案移動員權限可改為僅以臨時權限形式授予。Sanmosa Συ γάρ μοι και μοίρα εί και τύχη 2023年2月16日 (四) 06:49 (UTC)回覆
大概接近想法。將「文件移動」下放到延展用戶,現有組保留並辭退現有組員,只作為臨時授權給沒到延展用戶的後備,可以自行移除自己組。這樣避免浪費組功能,也可以應對特定情況。——Sakamotosan路過圍觀 | 避免做作,免敬 2023年2月16日 (四) 07:24 (UTC)回覆
啊不是說Minorax的權限會因此而被移除,而是說因為Minorax的例子個人認為這個組應該要保留,以避免後續如Minorax這樣的跨域貢獻者在存在經驗可以獲得該權限的情況下難以直接獲得這一權限。另外關於僅授權臨時權限,應是合理且必要的,確實若得到這一權限,保持活躍編輯不出12個月應當能夠達到擴展確認權限門檻。H.Natsumi2023年2月16日 (四) 09:01 (UTC)回覆
感覺沒有必要僅授予臨時權限,沒什麼意義,達到了再除權就完了。--在下荷花請多指教歡迎簽到2023年2月16日 (四) 09:04 (UTC)回覆
這樣也行,就是擴展確認本身是自動授權的,有必要的話可以寫個機械人自動提報或者自動除權。H.Natsumi2023年2月16日 (四) 09:25 (UTC)回覆
也可以。--在下荷花請多指教歡迎簽到2023年2月16日 (四) 10:48 (UTC)回覆
我認為你搞錯了一些點,保留組是為了臨時授權的需要,實務上不再使用「文件移動員」組,延展用戶的達標是需要一定的編輯量,臨時授權是為了前面的情況(例如上面提到的Minorax,19年授權,但到21年才到延展)。——Sakamotosan路過圍觀 | 避免做作,免敬 2023年2月17日 (五) 00:29 (UTC)回覆
@Cwekemm我沒明白,請問這裏的臨時授權說的是不授予無限期權限還是什麼別的?--在下荷花請多指教歡迎簽到2023年2月17日 (五) 06:37 (UTC)回覆
就是有期限的組別授權。組別不再長期授予,保留組別是為了應對沒到延展的情況臨時使用。——Sakamotosan路過圍觀 | 避免做作,免敬 2023年2月17日 (五) 06:45 (UTC)回覆
啊,那授予多長時間呢?這要修改方針吧。--在下荷花請多指教歡迎簽到2023年2月17日 (五) 06:54 (UTC)回覆
因為提出Minorax這個案例,我也不太確定。因為原本就是乾脆整組移除的,Minorax的按鈕才考慮臨時留下。如果參照的話,可以看LIPE的臨時授予期?好像常見是半年。——Sakamotosan路過圍觀 | 避免做作,免敬
大致支持。另外,延伸確認用戶得到的不是完整的「文件移動員」權限,沒有suppressredirect,不排除有人希望不留重定向移動文件,且不是巡退員。可留作該用。 ——魔琴 留言 貢獻 新手2023計劃 ] 2023年2月17日 (五) 14:29 (UTC)回覆
@魔琴文件移動員本來就沒有suppressredirect權限。--在下荷花請多指教歡迎簽到2023年2月18日 (六) 01:01 (UTC)回覆
哦這樣啊,恕在下失察,謹撤回意見。 ——魔琴 留言 貢獻 新手2023計劃 ] 2023年2月18日 (六) 04:41 (UTC)回覆
不反對也不支持下放。目前除了文件移動員外,movefile權限還賦予了管理員、巡查員與巡查豁免,後兩者的門檻不高,且移動文件似乎基本上就是巡查工作才需要使用吧。不過既然suppressredirect不下放,倒也不用擔心錯誤移動文件導致紅鏈的問題,因此中立。--BlackShadowG Slava Ukraini! 2023年2月19日 (日) 02:24 (UTC)回覆
也會有一些上傳的時候填錯了名想改發現只能請求的情況。--在下荷花請多指教歡迎簽到2023年2月19日 (日) 09:05 (UTC)回覆
我覺得權限留着也沒有什麼大礙。—— Eric Liu 創造は生命(留言留名學生會 2023年2月20日 (一) 02:28 (UTC)回覆

提議條文

看上去是沒什麼大的反對意見了,先放個條文修改如下:

WP:EXTENDEDCONFIRMED

現行條文

一個已註冊的用戶會在註冊達90天並編輯達500次後自動被授予該群組權限。該群組的權限允許用戶編輯受到延伸確認保護的頁面。

提議條文

一個已註冊的用戶會在註冊達90天並編輯達500次後自動被授予該群組權限。該群組的權限允許用戶編輯受到延伸確認保護的頁面,且相較於自動確認用戶,還可以移動文件

WP:FM

現行條文

檔案移動員用戶權限允許有經驗的使用者,依據方針執行檔案更名工作,以便享有如同自動確認用戶移動維基百科條目的便利功能。 任何管理員可以在審慎考慮之下,授予可信任用戶這個權限,該用戶必須經常處理多媒體文件,且熟悉各類多媒體重新命名的相關方針與指引。檔案移動員的資格基本資格要求是:

  1. 自首次編輯以來參與維基百科滿30日;
  2. 至少250次編輯,以及過去3個月內(未滿3個月之新註冊用戶,從註冊之日起計算至當日)平均編輯次數多於1次;或曾經提出有效檔案移動申請(包含維基共享資源)至少20次(將會從用戶貢獻中的檔案編輯歷程中查證);
  3. 最近1年內未曾受到封禁處分(不合理封禁除外);且
  4. 申請時須回答管理員或現有檔案移動員相關方針與指引的知識及應用問題。

除此之外,檔案移動員應當非常熟悉維基百科的圖像與多媒體方針(尤其是本頁面當中的重新命名指引)、對圖像更名程序有充分了解和具有處理圖像相關工作的經驗。

如果用戶曾在維基共享資源執行相同工作、使用相關工具以及其他多媒體檔案的相關類似經驗,管理員或許會將這些經驗作為是否授予權限的考慮因素。

除非剛來的編輯者曾上傳一定數量的檔案,否則本用戶權限一般不會授予此類編輯。

如果您有意為您或其他用戶申請檔案移動的權限,請到Wikipedia:權限申請/申請檔案移動權申請。以下用戶不需要去申請或是為他們增加本權限,他們本身已經獲自動授予檔案移動的權限:

提議條文

檔案移動員用戶權限允許有經驗的使用者,依據方針執行檔案更名工作,以便享有如同自動確認用戶移動維基百科條目的便利功能。

文件移動權限已於?年?月?日併入延伸確認用戶組,文件移動員權限組現僅保留以便授予未達延伸確認的跨域貢獻者文件移動權。

如果您有意為您或其他用戶申請檔案移動的權限,請到Wikipedia:權限申請/申請檔案移動權申請。申請人應當已於維基共享資源或其他維基媒體旗下項目取得相應的文件移動權限,且在其他維基媒體項目進行過一定數量的文件移動。

當持有文件移動員權限組的用戶達到了延伸確認或是取得了巡查或巡查豁免資格,則應當自行移除文件移動員組別。

以下用戶不需要去申請或是為他們增加本權限,他們本身已經獲自動授予檔案移動的權限:

以上。H.Natsumi2023年2月24日 (五) 02:49 (UTC)回覆

好!--在下荷花請多指教歡迎簽到2023年2月24日 (五) 05:42 (UTC)回覆
申請資格第二項看起來是多餘的,是否是延伸確認使用者的筆誤?--Xiplus#Talk 2023年2月24日 (五) 06:02 (UTC)回覆
本意是不持有movefile這個權限,不是指文件移動員這個權限組,實際操作中有這個權限的應該也不會重複申請,想來確實可以移除這個條件,已修改。H.Natsumi2023年2月24日 (五) 08:24 (UTC)回覆
(~)補充:此外Wikipedia:權限申請/申請檔案移動權/header應當也要做相應更動,或者更加淺顯地說,只保留欲申請檔案移動權,請點擊下方「增加新請求」。,並且加上:

注意:文件移動權已於?年?月?日併入延伸確認用戶,此頁面現僅供跨域貢獻者在未達延伸確認要求,且未取得巡查員巡查豁免者權限時臨時申請文件移動權。普通用戶不應在此申請文件移動權,而應使用{{Rename media}}代替,直到獲得延伸確認用戶權限、巡查權或巡查豁免權。詳見Wikipedia:文件移動員

供參。H.Natsumi2023年2月24日 (五) 08:43 (UTC)回覆
(+)支持--EvesiestaCOVID-19感染中 2023年2月26日 (日) 03:33 (UTC)回覆

整案提出已近7天無反對意見,本案最終結果是下放文件移動員權限但不取消文件移動員,以方便跨維基貢獻者進行文件移動。現  公示7日,2023年3月9日 (四) 13:48 (UTC) 結束。--在下荷花請多指教歡迎簽到2023年3月2日 (四) 13:48 (UTC)回覆

公示已通過(我還以為是今天),晚點提phab,sorry。--在下荷花請多指教歡迎簽到2023年3月10日 (五) 05:41 (UTC)回覆
Phab已提交,暫不對本案進行存檔。--在下荷花請多指教歡迎簽到2023年3月10日 (五) 06:22 (UTC)回覆

已經合併,方針已修改,現有文件移動員請自行移除權限或提出除權由管理員處理。--在下荷花請多指教歡迎簽到2023年3月13日 (一) 13:45 (UTC)回覆


本討論已關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。

常年提案

請勿修改下列討論。如有任何意見,請在合適的討論頁提出,而非編輯本討論。

以下列出中文維百常年不通過,但非常需要的更改權限提議:

  • 降低自動確認用戶的門檻
  • 巡查員與回退員合併為巡退員
  • 設立高級巡退員以查看私密過濾器
  • 給界面管理員授予編輯被保護頁面的權限
  • 與基金會協商重新引入用戶查核員

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


請勿修改本討論。如有任何意見,請在合適的討論頁提出,而非編輯本討論。

再提重組用戶權限組

以下列出中文維百常年不通過,但非常需要的更改權限提議:

請勿在討論版直接引用個人沙盒,這會使您此後的更改直接反饋到該頁面,使討論內容無法確定。此外關於用戶組權限的調整,還請您不要自顧自地不給出任何理由直接提出自己的一系列想法,這無助於發現問題和解決問題,只是在創造問題。——暁月凜奈 (留言) 2023年7月13日 (四) 14:41 (UTC)回覆
回復@暁月凛奈:這些想法也不是我提的呀,之前都有討論--Firedoge2023留言2023年7月13日 (四) 14:50 (UTC)回覆
以上提議我覺得會因安全原因而不會通過,例如反對降低自動確認用戶的門檻的原因是有長期破壞者喜歡通過刷編輯數來破壞被半保護的頁面。--Lanwi1Talk 2023年7月13日 (四) 15:56 (UTC)回覆
可以限制為條目命名空間編輯--Firedoge2023留言2023年7月14日 (五) 02:02 (UTC)回覆
可能和mw技術實現有關,至少在P站申請得到mw開發人員支持改進出這個功能才能討論。不過如果看自動確認和延伸確認兩種類似機制下的授權方式有明顯差異,感覺這個授權部分是屎山,沒人想動。 ——Sakamotosan路過圍觀 | 避免做作,免敬 2023年7月14日 (五) 03:05 (UTC)回覆
「再議回退員的角色(是否可以與巡查員進行簡併?)」、「提議重組現有的用戶權限組」不是已經在討論有關部分問題(包括合併巡查和回退,將回退看私密AF的權限正式轉給另一個用戶組)。至於其他(如「降低自動確認用戶的門檻」、「界面管理員編輯被保護頁面」),只是舉出常年理由並不足夠說服吧,至少說明現在為什麼要這麼做。——Sakamotosan路過圍觀 | 避免做作,免敬 2023年7月14日 (五) 01:11 (UTC)回覆
「界面管理員」本來就是防止管理員被盜後修改界面空間(例如Mediawiki空間的js腳本、css等)而將相應編輯權限拆出來提高安全性,「編輯被保護頁面」如果指全保護的話應該是管理員就可以吧?——Sakamotosan路過圍觀 | 避免做作,免敬 2023年7月14日 (五) 01:15 (UTC)回覆
PS,雖然現在來看,除了AnYiLin外,剩下的也是管理員(樂),有點脫褲子放屁的感覺,而且申請難度也和管理員接近。如果說好處的話, 就是收窄修改界面空間用戶的範圍,一些專注頁面管理、用戶管理的管理員通常不需要這個編輯能力。——Sakamotosan路過圍觀 | 避免做作,免敬 2023年7月14日 (五) 01:20 (UTC)回覆
那就剝奪幾個界面管理員的管理員身份[開玩笑的]--Firedoge2023留言2023年7月14日 (五) 02:07 (UTC)回覆
這不是開玩笑,畢竟這幾位的確是偏向技術維護的管理員。雖然從所謂安全性而已,是提出了拆分組別的要求,而基於其角色,他們看上去又好像沒有丟失了這些權力。——Sakamotosan路過圍觀 | 避免做作,免敬 2023年7月14日 (五) 03:24 (UTC)回覆
看了一下,應該給界管授予以下權限
editprotected
editcontentmodel
delete(僅限Mediawiki命名空間或CSSJS頁面)
undelete(僅限Mediawiki命名空間或CSSJS頁面)
suppressredirect(僅限Mediawiki命名空間或CSSJS頁面)--Firedoge2023留言2023年7月14日 (五) 02:24 (UTC)回覆
反對,界面管理員不應該有更改界面以外的任何權限,以上五個權限全部沒有技術上的命名空間限制,全部不應授予界面管理員。--西 2023年7月14日 (五) 02:39 (UTC)回覆
「界面管理員的可信程度不應亞於管理員,甚至應該更高。」可信程度更高,權限也應更高。--Firedoge2023留言2023年7月14日 (五) 02:51 (UTC)回覆
所以我曾經認為這句話說得不好,產生界面管理員組別的意義是為了隔離界面空間編輯功能而產生(或者說是拆分出來),實際上它的權限少於管理員,沒有什麼「可信程度不應亞於管理員,甚至應該更高」的意義。除了可以加些js腳本(可能引入私隱泄漏的破壞腳本),或者惡作劇性質的css外,遠不如管理員能刪除頁面、保護頁面、或者封鎖用戶更麻煩,前者直接用API也能繞開頁面修復。——Sakamotosan路過圍觀 | 避免做作,免敬 2023年7月14日 (五) 03:10 (UTC)回覆
我把這句話刪了--Firedoge2023留言2023年7月14日 (五) 03:24 (UTC)回覆
從技術上,有類似控制特定用戶組對特定頁面空間的動作控制插件:mw:Extension:Lockdown,不過可能需要確定基金會會不會允許使用這個插件。「editprotected」(編輯全保護頁面)感覺沒必要給,因為這本來是管理員主要權限之一、「editcontentmodel」可能可以考慮。至於其他要看插件功能來確定。——Sakamotosan路過圍觀 | 避免做作,免敬 2023年7月14日 (五) 03:20 (UTC)回覆
須證明日常工作中常用、必需,否則放在管理員權限組、雙人完成就好(活躍者少是另一問題)。可信程度高不代表要授予非必要的權限。--YFdyh000留言2023年7月18日 (二) 13:20 (UTC)回覆
請深思熟慮以後再提案,不要一股腦提出來。這些提案「常年不通過」是有原因的。從使用者查核員問題就可以看出,顯然提案人沒有對本站權限體系發展事先做過研究。—— Eric Liu 創造は生命(留言留名學生會 2023年7月14日 (五) 13:13 (UTC)回覆
我研究過--Firedoge2023留言2023年7月14日 (五) 13:39 (UTC)回覆
@Ericliu1912:雖然我個人也同樣不認可這次Firedoge2023的做法,但你用「這些提案『常年不通過』是有原因的」來批判他我也不認可。這樣説吧,我一開始在2018年重提設立編輯禁制方針(現稱「禁制方針」)的時候也沒有怎麽「深思熟慮」過,而且編輯禁制方針當時也是常年提案,但那時最終我的提案通過了。Sanmosa In vain 2023年7月14日 (五) 13:52 (UTC)回覆
我自已也不認可我的觀點。--Firedoge2023留言2023年7月14日 (五) 14:03 (UTC)回覆
提案人應對提案脈絡及意義有充分掌握,這是基本道理。操之過急而缺乏準備的提案不值得社群多花精力去「幫」提案人額外考慮。—— Eric Liu 創造は生命(留言留名學生會 2023年7月14日 (五) 14:12 (UTC)回覆
我的意思是説你先不要一來就假設對方完全沒有「對提案脈絡及意義有充分掌握」,這某程度上可以算是冒犯。Sanmosa In vain 2023年7月14日 (五) 14:28 (UTC)回覆
我只是就事論事。提案人如果明確知道為什麼要提案、怎麼解決過往討論未能解決的問題並合理說服社群,就不會出現「自顧自地不給出任何理由」等情況以及上方某些不明就裏的意見;如果認真、嚴肅地對待討論,就更不應該出現「那就剝奪幾個介面管理員的管理員身份[開玩笑的]」這種發言。—— Eric Liu 創造は生命(留言留名學生會 2023年7月14日 (五) 15:40 (UTC)回覆
😅--Firedoge2023留言2023年7月16日 (日) 02:52 (UTC)回覆

關於Wikipedia:用戶權限級別中確認用戶權和其他條文的銜接

根據Wikipedia:用戶權限級別#確認用戶,確認用戶除無投票權外其他與確認用戶相同,但該條文並未很好的與其他條文銜接,例如跨維基導入權。因此,我建議修正為:

現行條文

跨維基導入權:為自動確認用戶,最近一年內沒有受到封禁(不合理封禁除外),且管理員確認可信。

提議條文

跨維基導入權:為自動確認用戶或確認用戶,最近一年內沒有受到封禁(不合理封禁除外),且管理員確認可信。

現行條文

此權與自動確認用戶相同,乃用以授予准自動確認用戶。但是確認用戶沒有投票權,除非這個用戶加入百科超過7天且編輯次數超過50次。

提議條文

未特殊說明的,此權與自動確認用戶相同,乃用以授予准自動確認用戶。但是確認用戶沒有投票權,除非這個用戶加入百科超過7天且編輯次數超過50次。

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

(!)意見:本人建議第二種修改方式,因為與Wikipedia:用戶權限級別#確認用戶銜接不良的方針不少。--Gaolezhe留言2023年8月14日 (一) 06:49 (UTC)回覆
(-)反對。不是「未有很好的銜接」,而是根本沒打算要銜接。確認用戶始終跟自動確認不盡相同。--西 2023年8月14日 (一) 12:08 (UTC)回覆
同上。確認用戶有普遍使用嗎。相關事項可能是WP:IAR的。--YFdyh000留言2023年8月15日 (二) 08:06 (UTC)回覆
(:)回應WP:IAR是指在規則沒有問題且規則影響了維基百科,而這個規則本身就有誤。對於@LuciferianThomas的說法,如果是確認用戶始終跟自動確認不盡相同,那麼就應該使用第二種方法修正確認用戶的條文
--Gaolezhe留言2023年8月15日 (二) 09:11 (UTC)回覆
一處在說技術上的存取權限,一處在說申請條件,完全不同。投票權、申請其他權限條件均不屬於技術存取權限,不存在「未特殊說明」的差異。--西 2023年8月15日 (二) 10:40 (UTC)回覆
確認使用者並不自動等於自動確認使用者。自動確認使用者門檻低的驚人,即使上述條文不是刻意設計,我也認為一般權限體系並不需要考慮編輯不到五十次的確認使用者。—— Eric Liu 創造は生命(留言留名學生會 2023年8月19日 (六) 14:42 (UTC)回覆
返回專案頁面「用户权限级别」。