維基百科討論:管理員/存檔5

由132.234.228.109在話題編輯請求 2023-09-24上作出的最新留言:7 個月前

討論應該如何理解和判定 Wikipedia:管理員#避嫌

  • (見Wikipedia:管理員#避嫌)「管理員不應該在一項事宜中使用普通用戶和管理員的雙重身份」, 網上了解了一下各種例子, 我覺得:本次「封禁」是視乎是由於同一「爭持」引發(緊接地管理員對該事件的警告應該看做 「同一事宜」)。 由於任何個人的見解都會帶有主觀性, 很需要聽一聽其它維基人「同一事宜」的看法, 類似於某些法院評判靠陪審團的成員,政治論題評判靠民意的多數。我也剛看到這件事, 感有關對方針的理解,權衡利弊, 多討論一些時間可能更好些, 能讓更多人參與使得討論更充分一些。「同一事宜」的 「爭持」中,管理員對該事件的警告帶有主觀性,甚至是報復性的警告,可能性極大,所以需要避嫌「同一事宜」的處理。--Gluo88留言2021年1月21日 (四) 14:46 (UTC)
    三個月的時間足夠長了,卻沒有得出任何結論。「對封禁或封禁期限不滿請去掛T:Unblock,然後等待其他管理員介入」,這是最行之有效的解決方案。--安憶Talk 2021年1月21日 (四) 14:23 (UTC)
    看來我與您在這個問題下的「時間是否足夠長」有不同見解。我也剛看到這件事後, 網上做了調研,提出上面的看法。 很想和大家心平氣和的理性地討論。 由於任何個人的見解都會帶有主觀性, 這也需要聽一聽其它維基人的觀點。--Gluo88留言2021年1月21日 (四) 14:32 (UTC)
    1. 我覺得討論三個月已經夠久了。2.建議不要在其他人留言之後,再重新在留言中加入新的標題,改變其他人留言所在的段落(例如這個),這有可能影響讀者對留言的解讀。--Wolfch (留言) 2021年1月21日 (四) 16:04 (UTC)
    事件內,此管理員以管理員身份做出警告,卻未被回應並被無視,才加以封禁處理;如提封禁申訴,此申訴是由其他的、事件之外的管理員處理的,並非由當事管理員處理。故無嫌可避。--安憶Talk 2021年1月22日 (五) 04:27 (UTC)
    封禁不是由爭執引起,而是作為管理員對於違規行為,經警告無效後的處理措施。--安憶Talk 2021年1月22日 (五) 04:30 (UTC)
    #Mys 721tx濫權,任意封禁用戶。考慮到此話題為中途插入,與原有討論的訴求無關聯,且「分割章節」的做法或影響他人對原有留言的理解,現將此話題獨立出來。--安憶Talk 2021年1月21日 (四) 16:57 (UTC)
  1. 本條目被從: Wikipedia:互助客棧/其他#Mys_721tx濫權,任意封禁用戶 分出來, 專門討論按Mys_721tx濫權中(Wikipedia:管理員#避嫌)方針 - 「管理員不應該在一項事宜中使用普通用戶和管理員的雙重身份」,對於「同一事宜」的各種不同看法。側重對方針的理解的討論。 比如上面討論中,在這裡只是想抽象出一個例子來討論。
  2. 由於任何個人的見解都會帶有主觀性, 很需要多聽一聽維基人「同一事宜」的各種不同看法。本論題很難像形式邏輯的命題,可以靠純粹的邏輯推理解決。而更像政治論題評判,主要靠充分的討論, 理解雙方論點和理由, 然後靠民意的多數。 比如,充分的討論後的投票等 (也許可以考慮按維基的 「共識」 和「公示」程序。 )。
  3. 也可考慮將本事件抽象出對以後的判別有參考價值的案例,補充到 Wikipedia:管理員#避嫌一節中。

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

@Mys 721tx: @Uranus1781: @AnYiLin: @Catowen: @Catowen: @Ericliu1912: @YFdyh000: @Mewaqua: @Sanmosa: @周雁棠: @Hjh474:(見Wikipedia:管理員#避嫌)「管理員不應該在一項事宜中使用普通用戶和管理員的雙重身份」, 網上了解了一下各種例子, 我覺得管理員和用戶「爭持」引發出該管理員的「警告」和「封號」這三個步驟是應該看做同「一項事宜」。「同一事宜」的 「爭持」中,管理員對該事件的警告帶有主觀性,甚至是報復性的警告,可能性極大,所以需要避嫌「同一事宜」的處理。 是否按 Wikipedia:管理員#避嫌 要求,管理員不應該自已「封號」和自己正在進行爭持的用戶?
--Gluo88留言2021年1月23日 (六) 03:43 (UTC)

  • 此管理員在執行封禁前並沒有和用戶爭執,故您的論據不存在,且搞錯了發生順序。此管理員為應對違規行為以管理員身份施以多次警告,均未被回應且被無視,才加以封禁。爭執的內容,即「爭執該不該永封」是在封禁後產生的。--安憶Talk 2021年1月23日 (六) 03:56 (UTC)
  1. 謝謝分享看法。這裡討論的是: 管理員和用戶「爭持」引發出該管理員的「警告」和「封號」這三個步驟的情況。關於你說的案例,不在這個提案討論範圍。
  2. 關於你說的案例是否屬於這種情況的個例(儘管我的觀點與你不同), 應該在Wikipedia:互助客棧/其他#Mys_721tx濫權,任意封禁用戶的討論範圍。
  3. 很想和大家心平氣和的理性地討論。 由於任何個人的見解都會帶有主觀性, 這也需要聽一聽其它維基人的觀點。
--Gluo88留言2021年1月23日 (六) 04:28 (UTC)
如果真的有某管理員和某用戶的爭執在此管理員對此用戶實施封禁前發生,可以警告,因為警告是所有人可以做的。但不可以自行封禁,應求助於其他管理員,這是現行方針的規定。所以您想改善什麼呢?--安憶Talk 2021年1月23日 (六) 04:34 (UTC)
謝謝分享看法。是否下面的解釋對應了你上面的說法:
  1. 如果真的發生爭執,按「避嫌」原則,只能用其普通用戶身份, 所以不可以自行封禁,應求助於其他管理員。
  2. 關於「如果真的發生爭執,可以警告,因為警告是所有人可以做的」。 但這時,發警告的身份應該看做是普通用戶, 而不是管理員。 可以發多次警告, 但不能以發了多次警告為理由,來實行封禁。
  3. 與其說改善我寧願說是澄清。
--Gluo88留言2021年1月23日 (六) 05:05 (UTC)
2有補充,「但不能以發了多次警告為理由,來實行封禁」改為「但此管理員不能以發了多次警告為理由,來實行封禁。應請求其他管理員介入並由其他管理員進行定奪。」--安憶Talk 2021年1月23日 (六) 05:14 (UTC)
User:愛學習的飯桶/免死金牌。-Mys_721tx留言2021年1月23日 (六) 05:28 (UTC)
  1. 我認同 U:AnYiLin的進一步補充, 多謝了。
  2. 請問Mys_721tx君是否同意經U:AnYiLin 進一步補充的觀點,謝謝。 也謝謝Mys_721tx君分享, User:愛學習的飯桶/免死金牌 開始就說:"本用戶頁因幽默而保留,請不要當真。"
--Gluo88留言2021年1月23日 (六) 12:52 (UTC)
  • (!)抗議Mys 721tx把到處批評他的User:醍醐的花見永久封禁,也是沒有避嫌。--124.217.188.96留言2021年1月23日 (六) 12:32 (UTC)
    建議去看封禁日誌和理由。此用戶持續添加侵犯版權內容、散發原創研究及使用傀儡,封禁由短及長,直至永封;後於八月申訴中承諾「再也不做」,結果又犯,再次被永封;在其他管理員實施單頁編輯限制後其又去其他頁面繼續進行違規行為,屢教不改再次招致永封。管理員的做法合規得不得了,有何嫌需避。--安憶Talk 2021年1月24日 (日) 04:04 (UTC)
    路過,留個言就走,不要期望我作進一步回應。個人認為上述案例某程度上存在問題。從當時站內外的討論,我覺得該用戶只是未能掌握防止侵犯版權以及不發佈原創內容之間的平衡,未見其編輯行為存在破壞性質,最佳做法應該是AGF、勸導並協助用戶改寫內容。封禁乃用作防止破壞而非懲罰用戶,這一點還是有些管理員會偶然越線(案例:Sanmosa君的對上一次封禁),而相反對於某些用戶卻存在過大的包容度,某程度上看見雙重標準的情況。以上只是我對於上述案例及某些管理員行徑的個人意見。--LuciferianThomas留言 2021年1月25日 (一) 08:26 (UTC)
    (▲)同上。-- 2021年1月31日 (日) 04:33 (UTC)

改進自我解封(unblockself)權限描述

現行條文

解除自我封鎖。[1]

提議條文

解除自我封鎖。 [2]

參考資料

  1. ^ 自我封鎖為自己對自己的封鎖,此功能由軟體直接實現。自2018年12月起,管理員已被取消「解除封鎖自己(unblockself)」的權限(T150826),但為了阻止被盜竊的管理員帳號,仍可在封鎖狀態下封鎖對自己執行封鎖的管理員。
  2. ^ 自我解封是解除對自己的封禁,此功能由MediaWiki軟體實現。因2018年11月曾發生多起管理員被盜號且在自我解封後繼續破壞的事件,2018年12月起,維基媒體基金會所屬計劃上的管理員已無「解除封鎖自己(unblockself)」權限(T150826),為預防被盜管理員賬號封禁其他管理員以持續破壞,被封禁的管理員能封禁對自己執行封禁的管理員。管理員一直能解除由自己對自己執行的封禁。

位於Wikipedia:管理員#封禁與解封用戶。主要是腳註。註:所用MediaWiki轉換組現有'zh-cn:封禁; zh-tw:封鎖; zh-hk:封鎖;',源碼中的「封鎖」變化請忽略。

另外,同段現有的「查封」用詞是否該統一為「封禁」,不必要的動詞形式?(無地區詞轉換)。--YFdyh000留言2021年2月10日 (三) 18:49 (UTC)

抱歉先暫停討論,{{inuse}},提案的敘述仍有問題。--YFdyh000留言2021年2月10日 (三) 19:03 (UTC)

修訂完成。考慮過「自我解封、解除自我封鎖。」這樣劃線以區分,但或許不易理解。--YFdyh000留言2021年2月10日 (三) 19:22 (UTC)

「但為了防止被竊的管理員賬戶封禁其他管理員後繼續破壞」是否更明確一點?--Lt2818留言2021年2月11日 (四) 07:02 (UTC)
@Lt2818:指換掉「但為了允許反封禁被竊的管理員賬戶」這句嗎。感覺不明確啊,除非「其他」換成「其他所有管理員」/「其他活躍管理員」。--YFdyh000留言2021年2月11日 (四) 07:15 (UTC)
沒必要加這些定語吧,我封禁【所有-1】或者【活躍+1】的管理員就不符合。另外下一句過長,可以保持原先【在封禁狀態下】的表述。--Lt2818留言2021年2月11日 (四) 07:25 (UTC)
活躍+1仍包括「其他活躍」。感覺看不懂「封禁其他管理員後繼續破壞」,因為此時沒明說被封禁時能否正常行使封禁權。想等待更多意見。--YFdyh000留言2021年2月11日 (四) 07:58 (UTC)
我先說明一下提議條文中的問題:「反封禁(此三字若無下文則不知所云)被竊的管理員賬戶」是手段而非目的,放在「為了」後不大合適。原文有些翻譯腔但可以理解。不妨再找找合適的行文。--Lt2818留言2021年2月11日 (四) 09:23 (UTC)
原本的描述是我原創的,居然被說翻譯腔,哈哈哈哈哈...。--Xiplus#Talk 2021年2月11日 (四) 13:02 (UTC)
我們中出了一個老外--YFdyh000留言2021年2月11日 (四) 16:15 (UTC)
「翻譯腔」是對文字風格的(負面)描述,並非指文字由翻譯得來。--Lt2818留言2021年2月12日 (五) 14:45 (UTC)
「為了允許」,允許後面放行為而非目的沒毛病吧,這樣設計的目的就是允許這樣的行為。--YFdyh000留言2021年2月11日 (四) 16:17 (UTC)
這條無所謂,問題不大。但是「反封禁」的確難以理解。--Lt2818留言2021年2月12日 (五) 14:49 (UTC)
我想說「反過來封禁」的意思,需要表達那麼清楚嗎(我不反對),會有人理解為unblock嗎……--YFdyh000留言2021年2月12日 (五) 14:51 (UTC)
我知道是這個意思(不是說unblock),展開了同樣難以理解。你這裡缺少一個「封禁其他管理員」的假設,否則「反過來封禁」難以成立。--Lt2818留言2021年2月12日 (五) 15:08 (UTC)
我的理解是「反封禁」隱含了自己被封禁的前提,才能反過來。總之,語句改了,再看一下。--YFdyh000留言2021年2月12日 (五) 15:25 (UTC)
沒問題,現在感覺好多了。--Lt2818留言2021年2月12日 (五) 16:08 (UTC)
「但為了防止被竊的管理員賬戶封禁其他管理員後無法被制止的情況出現」,這樣可能清晰一點,但行文比較長。--Lt2818留言2021年2月11日 (四) 09:50 (UTC)

新的質疑

管理員並沒有特權,這句話及以下整段話現在仍掛在條目正文中,這完全和現狀相悖,為何遲遲不進行修改?──以上未簽名的留言由子非魚何不食肉糜討論貢獻)於2021年7月21日 (三) 11:38 (UTC)加入。

關於管理員方針中「避嫌」一節的探討

據我所知,「避嫌」一節常在爭議中被引用,而大家對於此處的規定的理解各不相同,所以想要拿出來探討一下。以下是方針原文:

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

  • 保護:管理員不應該保護/解除保護他們牽扯進去的頁面,而應該像普通用戶一樣求助於其他管理員,這些頁面不包括諸如主頁等的常見保護頁面;
  • 封禁:管理員不得僅因某用戶反對自己而封禁這個用戶;
  • 刪除:管理員不得刪除自己提議刪除或者投票刪除的頁面;

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

以上規定似乎僅僅是關於某個用戶與管理員的二元關係,並沒有涉及到編輯團體或者地域的描述。當今中文維基社群內部較為複雜,很多情況下,事情會延伸到持不同觀點的編輯群體,抑或是來自不同地域的編輯群體。於是,我希望社群能夠明確以下情形中,「避嫌」是否適用,以及如何適用。

  1. 某一地區分會或用戶組的用戶(如台灣分會、大陸的WMC、香港的WMHK用戶組),成為爭議、擾亂、破壞等的主體的時候,該地區分會或用戶組內的管理員是否有避嫌的義務?
  2. 某一政治立場的用戶(如統派、獨派),成為爭議、擾亂、破壞等的主體的時候,與其持相同(政治)立場的管理員,是否有避嫌的義務?
  3. 站外行為是否能夠影響站內「避嫌」的適用?如果站外人身攻擊或者歧視呢?如果適用,相關的分會或用戶組的管理員又是否會連帶受限?
  4. 封禁明確的破壞(違反方針)的用戶,保護明顯受到破壞的頁面,是否應當不受「避嫌」的限制?
  5. (PLUS) 如果其他管理員有連帶的避嫌義務(無論是因為分會、用戶組還是立場),那麼是否會造成其他無組織、未表明立場的管理員在權力上超出有組織、有立場的管理員?

近期的一些問題以及以往遇到過的事實讓我想要看看大家對於這些怎麼看待。--1=0歡迎加入WP:維基百科維護專題 2021年7月16日 (五) 04:04 (UTC)

簡答:
  1. 視情況,因為分會或用戶組是實在而緊密的組織,確有組織集體行動/決策的可行性,但組織集體行動/決策並非必然。故此同屬同一分會或用戶組有明顯跡象表明為集體行動/決策(的結果)的情況下才可構成適用避嫌的情形。
  2. 不適用,因為「某一政治立場的用戶」是概念性而鬆散的羣體,並且其成員的實際具體理念可能也有一定的差異,因此組織集體行動的可行性低,集體決策的可行性則為零。故此同屬同一政治立場本身不構成適用避嫌的情形。
  3. 站外行為如果和站內行為有明確聯繫或關係,則適用。相關行為的「人身攻擊」或「歧視」的屬性本身需要社羣共識確定,如果社羣共識確定有相關屬性的話,可以不適用。分會或用戶組成員是否連帶受限取決於站外行為是否和站內行為有明確聯繫或關係有明顯跡象表明該站外行為為集體行動/決策(的結果)。
  4. 要視乎共識是否認可相關情形是否真的是「破壞」。如果真的是「破壞」,自然可以不適用。
  5. 技術上不存在權力「超出」的情況,因為沒有管理員因任何管理員有連帶避嫌義務而獲得永久額外權限,有永久額外權限的管理員只有行政員(和監督員)。連帶避嫌義務的生效僅為對具連帶避嫌義務的管理員在行使權力時暫時性的限制。
以上。SANMOSA Σουέζ 2021年7月16日 (五) 13:22 (UTC)
補充:1和2的分別在於前者的成員身分是確切、非有即無的,而後者的成員身分是模糊、可被詮釋的(有時候可以視為有,有時候可以視為無)。SANMOSA Σουέζ 2021年7月16日 (五) 13:27 (UTC)

嘗試重提管理員復任制度

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

在下一向認為,解任一段時間不活躍之管理員是考慮到帳號安全問題,而不是能力問題(如果是的話就應該走罷免路線),何況各種因為現實生活充實啊、暫時想休息啊之類因素而自行辭職的情況。只要其恢復活躍,一般而言,沒有不重新賦予其管理員權限,儘速恢復投入站務工作的理由。此外,目前所有管理員復任都要經過重新選舉,而選舉不僅費時費力(近年來問題愈加氾濫,數目更是直線上升到了候選人可能難以負荷的地步),且還曾經出現AT辭了又選選了又辭,選了6次這種例子(當然,這是極端情形)。故參考英文維基百科早先修訂之相關規定,提議設立管理員復任制度,概要如下:

  • 在自願辭職或因不活躍而離任的情況下,前管理員可提出管理員復任申請,由行政員審核。
    • 由於行政員布告板尚未開設,可考慮一併啟用之,或另設申請提出地點。
  • 若有以下情況,不應予以直接復任:
    • 當事人過往是在牽涉爭議之情況下自行辭職。
      • 此時,當事人應循一般申請管理人員程序重新上任,或至少先經社群廣泛討論,直至達成共識為止。
    • 長期不活躍,滿足其中一項條件:
      • 當事人自願辭職後二年以上沒有編輯,或因不活躍而離任後一年以上沒有編輯;
      • 當事人申請復任前已至少五年未進行管理操作。
      此時,當事人應循一般申請管理人員程序重新上任。
    • 無法保障當事人帳號之安全性。
  • 授權前,行政員應確信當事人已恢復活躍或將恢復活躍,並至少待申請提出達24小時。若過程中他人有所疑慮,行政員應推遲授權,並進行充分討論,直至達成共識為止。

考慮到本地顯然不能直接套用其他維基的制度,且過往社群對相關話題意見繁多,希望社群此次能再提出修訂意見,放鬆或加嚴規定,以期符合本地對於管理員行使職能之期望。此外,若對過往情形有所疑慮,社群亦可考慮不溯及既往。

註:因應近期之基金會行動,若有必要,可延後實施此制度,以防混亂。—— Eric Liu 創造は生命(留言留名學生會 2021年9月25日 (六) 18:27 (UTC)

「牽涉爭議之情況下自行辭職」應如何定義,英維是否曾有相關案例因而受到行政員拒絕復權?--NHC、才不是NPC呢哼!。:.゚ヽ(*´∀`)ノ゚.:。 2021年9月25日 (六) 18:54 (UTC)
舉個抽象的例子,假如某管理員被提起罷免,討論正激烈或已經進入連署階段,他意圖先辭職「避風頭」,待風頭過後再申請復任,這樣的情況就不應該被允許。具體案例可能要花一點時間尋找;此條文似乎近年來在英維不常被引用,長期不活躍才是當地歷來復任失敗的主因。關於因此進入深入討論,惟最後成功復任的案例可見此,在該案中同時對此條文進行了一些分析。—— Eric Liu 創造は生命(留言留名學生會 2021年9月25日 (六) 19:40 (UTC)
那PhiLiP是自願辭職,但原因是抗議愛孟解封,這種情況下適合直接復任嗎?--中文維基百科20021024留言2021年9月25日 (六) 22:04 (UTC)
他有直接牽涉進去守望者愛孟事件嗎?(比如:有在辭任前的相近時間在相關討論中表示反對解除封鎖守望者愛孟嗎?)Sanmosa Outdia 2021年9月26日 (日) 01:06 (UTC)
根據他的辭職理由,我感覺很可能有。--中文維基百科20021024留言2021年9月26日 (日) 01:50 (UTC)
那就可能不適合。不過討論這個也沒甚麽意義,因為他沒有表明自己希望恢復管理員權限。如果他根本不打算恢復管理員權限的話,那他能不能依照管理員復任制度恢復管理員權限就完全不重要了。Sanmosa Outdia 2021年9月26日 (日) 02:17 (UTC)
我不會嘗試不經投票就恢復權限的。可見的未來里也沒打算恢復權限(無論投票與否,但界面管理員可能除外,我還沒想好)。--菲菇維基食用菌協會 2021年9月26日 (日) 05:24 (UTC)
我認為管理員復任制度要註明一點:管理員復任制度僅適用於恢復管理員權限,自願辭職或因不活躍而離任前同時兼具的其他權限(如行政員、監督員)不因管理員權限的恢復而同時恢復,而仍須循一般申請管理人員程序重新上任。另:介面管理員或可同時適用管理員復任制度。Sanmosa Outdia 2021年9月26日 (日) 01:12 (UTC)
@Ericliu1912:根據上面的東西寫了Wikipedia:管理員的復任(參考了User:Aotfs2013/草稿列表/管理員的休任),有需要的話自行調整即可。有鑒於行政員佈告板尚未開設,而且我也不預期有大量管理員會提出復任,我覺得直接在「管理員的復任」頁面申請即可。Sanmosa Outdia 2021年9月26日 (日) 02:51 (UTC)
理論上不用另立頁面,寫入《管理員方針》、《行政員方針》即可;亦可直接開設行政員布告板,可預期該處除了處理管理員復任申請,還能處理機器人作業申請批准等行政員積壓工作。另外,英維那邊是允許同時取回行政員權限的,但考慮到本地可能對此產生爭議,可改為不允許直接復任。—— Eric Liu 創造は生命(留言留名學生會 2021年9月26日 (日) 04:59 (UTC)
@Ericliu1912:如果要開設行政員佈告板的話,我預期會導致頁面的大量移動,這需要另外尋求社羣許可。此外,zhwiki也單設了WP:管理員的離任頁面,我認為單設WP:管理員的復任會是較適合的安排。同意改為前管理員不允許直接恢復行政員權限。另:希望就介面管理員應否適用作回應。Sanmosa Outdia 2021年9月26日 (日) 05:33 (UTC)
應規定僅適用於管理員權限。另外不清楚開設行政員布告板會如何「導致頁面的大量移動」。我稍微修正一下我早前的說法,行政員布告板實際上以處理管理員請辭和不活躍解任為主要業務,若開設可將該二項業務併入行政員布告板。—— Eric Liu 創造は生命(留言留名學生會 2021年9月26日 (日) 05:41 (UTC)
我個人對於介面管理員應否適用沒大意見。就修正說法後的情況,那我就不預期會導致頁面的大量移動了,但由於還是需要整合頁面,這需要另外尋求社羣許可(可能還需要改方針)。Sanmosa Outdia 2021年9月26日 (日) 14:28 (UTC)
Sanmosa話說,其實我是有考慮重新將一些離任相關內容整併回管理員方針的(但要分階段處理,不適合在此處包裹提案),所以才覺得復任相關內容一開始就寫在管理員方針更加好。—— Eric Liu 創造は生命(留言留名學生會 2021年10月25日 (一) 03:09 (UTC)
假設某用戶於2010年自願辭任管理員後,在30年間一直有編輯,然後於2040年申請直接復任管理員,可以接受否?--Mewaqua留言2021年9月27日 (一) 15:48 (UTC)
要看當事人這三十年間做的主要是什麼類型的編輯。此外,對於這種極端情況,我想絕對會適用「他人有所疑慮」那一段,沒那麼容易直接復任。—— Eric Liu 創造は生命(留言留名學生會 2021年9月27日 (一) 17:35 (UTC)
考慮到原草案確實有點太寬鬆,修正了一下,這樣應該可以避免此情況發生了。—— Eric Liu 創造は生命(留言留名學生會 2021年9月27日 (一) 17:45 (UTC)

徵詢一下@AntigngAotfs2013之意見。—— Eric Liu 創造は生命(留言留名學生會 2021年10月5日 (二) 06:21 (UTC)

@Ericliu1912:你還打不打算推行?WP:7DAYS的説明是討論持續了30日就可以公示,所以最早10月25日就可以公示了。需要做甚麽調整的話請明示。Sanmosa WÖRK 2021年10月20日 (三) 02:45 (UTC)
當然有打算,但就現在這參與程度來看,強行公示也不見得能服眾,只能待更多人來參與。上面我ping的那二人都對復任制度有想法,只是可能他們最近忙吧,都沒有回應。—— Eric Liu 創造は生命(留言留名學生會 2021年10月20日 (三) 08:49 (UTC)
@Ericliu1912:或許你再另外ping幾個人來也可以,Bulletin單列一欄吸引關注也可以。Sanmosa WÖRK 2021年10月25日 (一) 03:13 (UTC)
AntigngAotfs2013再ping一次好了。—— Eric Liu 創造は生命(留言留名學生會 2021年10月22日 (五) 06:39 (UTC)

方針修訂草案

預定修訂管理員方針行政員方針,修訂內容暫定如下:

(管理員方針)(順便簡單整理一下相關段落)

現行條文

管理員的權限取得與喪失 如果你覺得自己或他人有資格成為管理員,請見Wikipedia:申請成為管理員的申請標準及程序。

管理員離任的具體辦法,或提請取消某位管理員的權限,請見Wikipedia:管理員的離任

提議條文

管理員的權限取得與喪失 申請 如果你覺得自己或他人有資格成為管理員,請見Wikipedia:申請成為管理員的申請標準及程序。

離任 管理員離任的具體辦法,或提請取消某位管理員的權限,請見Wikipedia:管理員的離任

復任 無論管理員為何離任,皆可以上方提及之一般程序重新申請成為管理人員。

而在自願辭職或因不活躍而離任的情況下,當事人可提出管理員復任申請,由行政員審核。基本上,復任申請除有以下情事外應可獲通過:

  • 牽涉爭議而辭職:若當事人過往是在牽涉重大爭議(例如被提起解任投票)之情況下自行辭職,則應循一般管理人員申請程序重新上任,或至少先經社群廣泛討論,直至對於當事人之地位達成共識為止。
  • 長期不活躍而滿足以下其中一項條件,此時行政員應當否決復任申請,而當事人應循一般管理人員申請程序重新上任:
    • 自願辭職後2年、不活躍離任後1年未有編輯:當事人在自願辭職後已至少2年沒有編輯,或因不活躍而離任後至少1年沒有編輯;
    • 申請復任前5年未有管理操作:在因不活躍而離任之情況下,當事人申請復任前已至少5年未進行管理操作。
  • 無法保障當事人帳號之安全性:有合理根據,可認為當事人帳號之安全性不受保障,以至於不適合直接取回重大權限。相關證據應當向行政員提出,並附詳細說明。

管理員復任申請應在行政員布告板提出,由行政員依據權限恢復程序操作。授權前,行政員應確信當事人已恢復活躍或將恢復活躍,並至少待申請提出達七日。若過程中他人有所疑慮,行政員應推遲授權,並進行充分討論,直至達成共識為止。

本制度不適用於介面管理員、行政員、使用者查核員與監督員。從這些職務上離任者應循一般管理人員申請程序重新上任。

(行政員方針)

現行條文

權限 (略)

提議條文

權限 (略)

恢復權限 若有復任申請在行政員布告板提出,行政員應當遵循以下程序操作:

  1. 確認當事人是否曾是管理員;
  2. 確認當事人離任原因為自願辭職或不活躍;
  3. 檢查當事人之使用者討論頁、相關布告板、互助客棧和其他討論,確認當事人是否因牽涉爭議而辭職;
  4. 為充分確認申請之合理性,行政員在授權前應至少待申請提出達7日,以讓其他行政員和編者發表意見。若有足以影響情況之新資訊出現,行政員可適當推遲授權時間;
  5. 若當事人在自願辭職後已至少2年沒有編輯,或因不活躍而離任後已至少1年沒有編輯,行政員應當否決申請,或轉介一般管理人員申請程序;
  6. 若當事人申請復任前已至少5年未進行管理操作,行政員應當否決申請,或轉介一般管理人員申請程序;
  7. 在恢復管理員權限前,行政員應確信當事人已恢復活躍或將恢復活躍;
  8. 若在復任申請之審核過程中他人有所疑慮,行政員應推遲授權,並進行充分討論,直至達成共識為止。

以上。請諸位為草案修訂提供更多意見。—— Eric Liu 創造は生命(留言留名學生會 2021年10月25日 (一) 04:36 (UTC)

24小時也太短了。可能長一點但不要至少的字眼。--ghren🐦吱吱吱...🔊 2021年10月25日 (一) 04:43 (UTC)
那延長至三日應該足夠了吧。—— Eric Liu 創造は生命(留言留名學生會 2021年10月25日 (一) 13:39 (UTC)
我覺得夠,但是你維是連公示廢話都要14天的,看看其他人意見。此外我頗擔心這制度會成了受爭議人物的捷徑,就像和奮球(節刪)而且本身也就試過高票落選,假如他去申請,新制下會如何處理呢?--ghren🐦吱吱吱...🔊 2021年10月25日 (一) 13:57 (UTC)
他辭職後二年以上沒有編輯,不得申請。假設他可以申請的話,他不是因為牽涉爭議而辭職的,或可適用「他人有所疑慮」這一段之敘述,由諸位行政員來斟酌。不過您確定您說的真的是他嗎?好像不太符合實際情形?—— Eric Liu 創造は生命(留言留名學生會 2021年10月25日 (一) 14:20 (UTC)
認錯人了,當他合乎辭職後二年有編輯算了。行政員會怎樣處理呢?不太喜歡有過於空洞的條文。特許一定是會推遲的。就怕一些牽涉重大爭議的人物過了投票後兩三年後辭職,然後用這機制上任時大家又要互撕,當然我是在WP:水晶球。--ghren🐦吱吱吱...🔊 2021年10月25日 (一) 15:09 (UTC)
如果會互撕的話,我覺得在這三天的時間內應該就會有其他編者來發表異議了,畢竟某種程度上來說管理員申請比方針修訂案之類的還要多人關注(從參與相關投票的人數比較可知一二)。加上行政員應有充分判斷能力,個人覺得問題應該不太大。---Peacearth留言2021年10月25日 (一) 15:50 (UTC)
不信任我維行政員的人不在少數,條文能寫清就最好了。--ghren🐦吱吱吱...🔊 2021年10月25日 (一) 17:56 (UTC)
@Ericliu1912沒人互煮就準備公示吧。--ghren🐦吱吱吱...🔊 2021年11月2日 (二) 02:14 (UTC)
(:)回應@Ghrenghren:本人並未參與RSN討論,何來在該處得罪其他主編之說?我更沒有上過ANB,您大概是認錯人了。-Peacearth留言2021年10月25日 (一) 14:31 (UTC)
尬了,記反了。不好意思啊,真的不好意思。ghren🐦吱吱吱...🔊 2021年10月25日 (一) 14:37 (UTC)
了解,沒關係的:)-Peacearth留言2021年10月25日 (一) 15:52 (UTC)

再收集討論一會。ghren🐦吱吱吱...🔊 2021年11月6日 (六) 18:36 (UTC)

參考7DAYS,72小時建議改成7天吧。桐生君[討論] 2021年11月14日 (日) 09:06 (UTC)

7DAYS只規範互助客棧,這理由説不通吧。Sanmosa Ázijský Mesiac/Asiatischer Monat 2021年11月14日 (日) 10:49 (UTC)
單純只是從7DAYS取了一個數,不是要遵循7DAYS方針,像是自確也是7天。桐生君[討論] 2021年11月14日 (日) 11:08 (UTC)
@Sanmosa這個從寬不從緊吧,就7天吧,三天可能真的未必夠時間表達反對意見,也不應該為這小問題而再拖復任方案了。--ghren🐦吱吱吱...🔊 2021年11月14日 (日) 12:34 (UTC)
我是沒大意見。@Ericliu1912。--Sanmosa Ázijský Mesiac/Asiatischer Monat 2021年11月14日 (日) 13:35 (UTC)
行吧。—— Eric Liu 創造は生命(留言留名學生會STE 2021年11月14日 (日) 13:45 (UTC)
WP:7DAYS,此案自2021年9月25日 (六) 18:27 (UTC)起已討論逾30日,故送公示。Sanmosa Hrom a peklo, márne vaše proti nám sú vzteky! 2021年11月16日 (二) 08:12 (UTC)
假如申請人在辭任或因不活躍而離任管理員後在行為上有重大違反、或近期的非輕微違反、或長期持續的非輕微違反中文維基百科或其它維基媒體計劃網站的方針或指引、維基媒體基金會決議或使用條款,是否可以用「在復任申請之審核過程中他人有所疑慮」反對復任申請?如果因此不予簡易復任,又是否與「基本上,復任申請除有以下情事外應可獲通過」有矛盾?--Mewaqua留言2021年11月16日 (二) 17:02 (UTC)
「基本上」與「一般情況下」等義,如果出現了特殊情況,那就算不是該部分所列出的情事也可以成為拒絕理由。你提到的那些情況屬於我剛才提到的「特殊情況」,因此如果行政員確實認為相關情節嚴重至不可復權,他可以以「在復任申請之審核過程中他人有所疑慮」為由拒絕,而如此為之並不會與「基本上,復任申請除有以下情事外應可獲通過」有矛盾,原因是「基本上」限定詞的存在。--Sanmosa Hrom a peklo, márne vaše proti nám sú vzteky! 2021年11月17日 (三) 02:04 (UTC)
@MewaquaSanmosa Hrom a peklo, márne vaše proti nám sú vzteky! 2021年11月17日 (三) 03:02 (UTC)
@Ericliu1912提案已通過。--Sanmosa WAM 2021年11月25日 (四) 05:45 (UTC)

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

「管理員」是否應該更名為「系統操作員」

目前看到當前方針板「增加管理員站務要求」的討論,管理員向一些用戶解釋管理員並不是一般人認知中的管理員,而是一名受到社區信任,被解除一些限制的用戶。 但是管理員這個詞,其實是具有刻板印象的一個詞,因此才造成一些人的誤解,是否應該將「管理員」改名為「系統操作員」? 系統操作員正好也是「sysop」的中文譯名,這樣用戶就能理解系統操作員跟模板編輯員之類的概念是一樣的,減少誤解。 --桐生君[討論] 2021年11月13日 (六) 17:03 (UTC)

WP:沒壞別修--Billytanghh 討論 歡迎參與亞洲月 2021年11月13日 (六) 18:16 (UTC)
那只是個論述,而WP:BOLD這還是指引,本人認為,如果更名為系統操作員,讓系統操作員有所謂的操作次數要求是不合理的,能有一個直觀上的感覺。桐生君[討論] 2021年11月14日 (日) 01:38 (UTC)
「管理員」是壞了?還是「修復」後就好了?既然不是壞了,要修?——Sakamotosan路過圍觀杯弓蛇影 | 避免做作,免敬 2021年11月14日 (日) 03:20 (UTC)
這個詞「修復」後就好了,因為社會大眾認知中的「管理員」是「站長」,而不是一名具有權限的用戶,「修復」後,所有人都能直觀的明白,「系統操作員」和「模板編輯員」是一樣的,因此要求「系統操作員」這一權限有站務要求可能不合理,因為「模板編輯員」也沒有站務要求。桐生君[討論] 2021年11月14日 (日) 03:42 (UTC)
感覺這是一種詞義正義的問題,而不是實務性的問題。在這裡管理員的職責,就有類似「站長」的性質,包括大部分前台性調控工作(可以編輯界面信息、腳本、CSS等)、日常維護(從功能性的,如刪除、保護等,到業務性的,例如從執行刪除的來源是速刪、討論刪除等)、社群管理(封鎖的執行本身就是根據社群已有的規則或共識等),雖然這個前台性的「站長」不擁有站點(站點是屬於基金會的)這一點與正式的站長有所差異。但不足以認為是問題。更嚴格來說「系統操作員」我認為更像是後台性的基金會硬件或系統的維護人員。——Sakamotosan路過圍觀杯弓蛇影 | 避免做作,免敬 2021年11月14日 (日) 08:21 (UTC)
其實也可以叫「管理操作員」,不過沒有共識的話,就結案吧。桐生君[討論] 2021年11月14日 (日) 08:48 (UTC)
「事務員」如何?Sanmosa Ázijský Mesiac/Asiatischer Monat 2021年11月14日 (日) 13:46 (UTC)
Wikipedia:管理員中提及的英文名稱有「Admin(或en的Administrator)」和「SysOp」,從早期翻譯來看已經選定了前者的翻譯。這已經是慣例性的用詞,不是實務性的損壞(例如:例如導致系統異常、或業務問題),無法認為這是「壞了」的問題。——Sakamotosan路過圍觀杯弓蛇影 | 避免做作,免敬 2021年11月15日 (一) 01:03 (UTC)
要問,我會說否;不問,一樣說否。 2021年11月18日 (四) 16:42 (UTC)
  • (+)支持更名。早就想提這個了。在本人看來某些人自認選上來便可「管理」他人,其職務名稱所引起他們莫名的自傲感是其中原因,進而忘了自己的本質與其他用戶僅是能處理站務與否的問題。建議更名為「系統操作員」或PerSanmosa更名為事務員,其「管理權限」更為「站務處理權限」。——WMLO留言2021年11月25日 (四) 21:46 (UTC)

題外話:關於巡查員

( π )題外話:甚至本人認為「巡查員」一詞也是需要「修復」的,站外人士,或新來的人很可能以為巡查員是某種「維基百科官員」,應改名「巡視員」。桐生君[討論] 2021年11月14日 (日) 03:48 (UTC)
我覺得兩個問題一點關係都沒有。--ghren🐦吱吱吱...🔊 2021年11月14日 (日) 05:33 (UTC)
「巡查」的「查」包括發現問題後的行動,而「巡視」的「視」只有看,一般認為不包括行動。——Sakamotosan路過圍觀杯弓蛇影 | 避免做作,免敬 2021年11月14日 (日) 08:25 (UTC)
巡查給人一種「是維基媒體基金會的官方人員,來到中文維基百科視察監督」的感覺。桐生君[討論] 2021年11月14日 (日) 08:46 (UTC)
管理員等也不是官方人員啊。或者只是你想多罷了。——Sakamotosan路過圍觀杯弓蛇影 | 避免做作,免敬 2021年11月14日 (日) 08:52 (UTC)
管理員的作用是管理網站,作為一般市民,當然會認為管理員是官方的人(或有官方支持 / 代表官方意見)。包括巡查員作為與新用戶的第一交手對象,也會被認為近似於管理員。事實是你不可能讓所有人都明白維基百科的運作方式,不是誰想多,而是你想太少。->>Vocal&Guitar->>留言 2021年11月14日 (日) 13:05 (UTC)
解釋清楚,而不是遷就蠢貨。——Sakamotosan路過圍觀杯弓蛇影 | 避免做作,免敬 2021年11月16日 (二) 00:41 (UTC)
要考慮巡查豁免者的名稱應該如何更改。Sanmosa Ázijský Mesiac/Asiatischer Monat 2021年11月14日 (日) 13:46 (UTC)
「免審閱者」、「免校閱者」如何。桐生君[討論] 2021年11月14日 (日) 15:36 (UTC)
隨着巡查員的更名而更名,例如如果巡查員更名為「巡視員」,那麼巡查豁免者就可以更名為「巡視豁免者」。--落花有意12138 回復請ping我 2021年11月22日 (一) 13:34 (UTC)
本站點從來沒有「官方」的組織,除了涉及後台硬件管理、軟件維護,還有涉及業務上的特殊情況是存在屬於正式的「官方」——基金會,這也是一直對所有不明站點人員結構的人們都這樣解釋。所以只是個別的語文理解問題,我不認為這是問題,或者是那些有問題的理解才是問題。——Sakamotosan路過圍觀杯弓蛇影 | 避免做作,免敬 2021年11月15日 (一) 01:07 (UTC)

巡查員改「校閱者」、「檢閱者」、「審閱者」、「審稿人」如何?意思是reviewer而不是patrol。桐生君[討論] 2021年11月14日 (日) 15:36 (UTC)

Wikipedia:管理員

當中提及:

管理員不應該在一項事宜中使用普通用戶和管理員的雙重身份,而應該要麼使用普通用戶的身份,要麼使用管理員的身份,儘管用戶是同一個人。在以下場合的具體限制有:
保護:管理員不應該保護/解除保護他們牽扯進去的頁面,而應該像普通用戶一樣求助於其他管理員,這些頁面不包括諸如主頁等的常見保護頁面;
封禁:管理員不得僅因某用戶反對自己而封禁這個用戶;
刪除:管理員不得刪除自己提議刪除或者投票刪除的頁面;
在以上情況下,管理員應該以普通用戶的身份要求其他管理員協助。

但我覺得管理員應該可以刪除自己提議的O1、G10快速刪除,因為這樣通常不會對維基百科造成太大影響,也公平。
請各位在下面討論一下。Choi Chin Long 2022年2月22日 (二) 10:04 (UTC)

請允許我直接引用兩條五大支柱:在不引起爭議時任何改善(或保護)維基百科的行為都沒有太大問題--Kegns留言2022年2月22日 (二) 13:42 (UTC)
與文明方針有何聯繫? Stang 2022年2月22日 (二) 13:48 (UTC)
正常流程是用戶先提刪,後管理員進行刪除,而第一步為普通用戶操作,第二步為管理操作,所以一位管理員不能單獨完成這兩個步驟。--東風留言2022年2月23日 (三) 03:39 (UTC)
其實O1目前管理都是自己刪掉的,用bot刪還是人手刪有什麼分別?--Ghren🐦🕛 2022年2月23日 (三) 04:19 (UTC)

我們要如何看到維基百科的各級管理員啊?

應該有一個列表把各級管理員啥的羅列出來吧? --AndyPKU留言2022年5月28日 (六) 02:22 (UTC)

管理員名單行政員名單回退員名單巡查員名單。另外可以在特殊:參數設置的小工具開啟「看哪個管理人員在線」及「在編輯記錄中標示用戶權限」功能。桐生ここ[討論] 2022年5月28日 (六) 02:34 (UTC)
非常感謝!--AndyPKU留言2022年5月28日 (六) 13:49 (UTC)

提議新設[email protected]

已經有人建立,可以關閉討論串了。--Z7504非常建議必要時多關注評選留言2022年6月16日 (四) 06:05 (UTC)
下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

借近期討論過濾器問題的契機,討論一下是否尋求管理員新設一電郵列表。探討此問題的動因是:
  1. 一方面,濫用過濾器匹配規則「事前泄密」的情況確實存在,縮小匹配規則查閱權限的持有範圍,在此情況下會成為一個很可能的選項;
  2. 另一方面,資深用戶在過濾器有關站務(比如,過濾器錯誤報告)上的確發揮了很大作用,儘管權限持有範圍可能出現限縮,但是對於公開匹配規則而無礙的過濾器,原則上也應儘可能公開;
  3. 同時,在編寫防濫用過濾器規則(ADM2)的過程中,感覺一小部分過濾器的公開性是可以檢討的;
  4. 但是相關討論可能會涉及匹配規則細節,所以私有的討論或許更為適宜。
新設一電郵列表的主要理由有下:
  1. 包括上述過濾器問題討論在內的很多站務問題,需要一個能包納所有管理員的平台開展討論。
  2. 現行的unblock-zh lists.wikimedia.org儘管包納所有管理員,但每天都會接收海量申請IP豁免的郵件,實際上已經不適合管理員用於討論站務。
以上。--Kirk # 2022年6月1日 (三) 05:56 (UTC)
歸納了一下本地或常與本地有關的郵件列表:
  • 公共列表
  • 私有列表
    • wikipedia-zh-afc-reviewer lists.wikimedia.org(似可停用)
    • unblock-zh lists.wikimedia.org:中文維基百科封禁申訴
    • otrs-zh lists.wikimedia.org:中文志願回復團隊
    • wikizh-bureaucrats lists.wikimedia.org:中文維基百科行政員
    • oversight-zh-wp wikipedia.org:中文維基百科監督員
以及Wikipedia:郵件列表或可更新。--Kirk # 2022年6月1日 (三) 06:25 (UTC)
  • (+)支持設立管理員郵件列表。另外上面那幾個郵件位址格式實在參差不齊,還有一些名稱過時了,日後有沒有辦法處理一下( —— Eric Liu 創造は生命(留言留名學生會 2022年6月1日 (三) 08:09 (UTC)
    (參差問題雖然是題外話)同表示不舒服,但估計會維持現狀。目前新設地址的基本上按照「<計劃全稱>-<語言代號>-<功能名稱> lists.wikimedia.org」的格式。監督員郵箱地址命名應該是從英文維基百科oversight-en類比遷移,行政員郵箱地址命名則遷移自公共主列表wikizh-l,估計是當時沒有制定統一的規則所致。--Kirk # 2022年6月1日 (三) 11:14 (UTC)
    意思說其實日後可以考慮 unblock-zh -> wikipedia-zh-unblock, wikizh-bureaucrats -> wikipedia-zh-bureaucrats, oversight-zh-wp -> wikipedia-zh-oversight ?--SunAfterRain 2022年6月8日 (三) 01:41 (UTC)
    「wikipedia-zh-oversight」wikipedia-zh-suppress* —— Eric Liu 創造は生命(留言留名學生會 2022年6月8日 (三) 09:09 (UTC)
不反對設立,但是對它能起多少作用不樂觀,很可能沒幾個人用甚至沒幾個人訂閱。--Tiger留言2022年6月1日 (三) 15:35 (UTC)
wikizh-l都沒人用....--百無一用是書生 () 2022年6月2日 (四) 03:57 (UTC)
如果是可以公開討論的內容,也就尋求充分利用一下wikizh-l了。--Kirk # 2022年6月2日 (四) 08:50 (UTC)
多一個正式管道總是好的。此外,給管理員開一個專用Telegram群組的效益或許會高一些?根據統計,至少約有四分之一的管理員持有Telegram帳號。—— Eric Liu 創造は生命(留言留名學生會 2022年6月2日 (四) 05:11 (UTC)
能提高效率,但TG的多個方面對歷史留檔不太友好(銷號/刪除歷史消息/賬號關聯性)。--YFdyh000留言2022年6月2日 (四) 06:07 (UTC)
從普遍的工作環境來看,我覺得使用郵件的存檔性、用戶關聯性比面向即時通信的tg更好。——Sakamotosan路過圍觀 | 避免做作,免敬 2022年6月2日 (四) 08:05 (UTC)
我想Telegram主要應該是作為管理員之間即時溝通的管道,至於任何正式決策都要在站內解決,或者有日誌存檔等。—— Eric Liu 創造は生命(留言留名學生會 2022年6月2日 (四) 09:58 (UTC)
TG作為即時便捷的輔助手段尚可。郵箱既是討論渠道,更是公示和存檔的渠道。--Kirk # 2022年6月2日 (四) 08:49 (UTC)
若無進一步意見,建議今日起開始公示。--Kirk # 2022年6月9日 (四) 04:26 (UTC)
這個要創建應該也不難,但是真正想使用的人有多少?公不公示估計也沒差,沒意見的話可能都可以直接創建就好了。--Z7504非常建議必要時多關注評選留言2022年6月9日 (四) 10:32 (UTC)
@KirkLUEricliu1912和平奮鬥救地球:講那麼多看起來沒有實質意義的討論,所以你們有沒有人要建立了?反正沒有人反對嘛。管理員,阿不是管理員的當然無感阿,不是管理員的討論這個意義在哪?--Z7504非常建議必要時多關注評選留言2022年6月13日 (一) 07:15 (UTC)

根據phab:T310465,目前私有列表wikipedia-zh-admin lists.wikimedia.org 已被建立。雖然目前存檔功能暫時被關閉,但有需要的話可隨時重新啟用。-Peacearth留言2022年6月13日 (一) 13:28 (UTC)


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

提議:是否應該提高管理員和行政員任內的要求?

除了提案人和HK5201314外未見其他支持者,雪球關閉--SunAfterRain 2022年10月11日 (二) 03:13 (UTC)
下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

絕大多數管理員和行政員憑藉撰寫優秀的條目內容登上高位,但是這些人的大多數在上任後鮮少有優秀的條目問世,只是沉迷於管理,難免會形成「官僚階層」,使普通用戶產生管理員和行政員是維基百科「站長」的錯覺。

不做過多贅述,我認為管理員應該每個月為維基百科貢獻一個優良條目,行政員應該每個月為維基百科貢獻一個典範條目。如果既是管理員又是行政員,每個月應該為維基百科貢獻一個典範條目和一個優良條目。如果行政員或者管理員達不到要求,第二個月降為臨時,第三個月除權。

我認為這是消除管理員制度現有弊端的最好方法。Assifbus留言2022年10月9日 (日) 13:39 (UTC)

您確定「憑藉撰寫優秀的條目內容登上高位」?管理人員本就非內容創作為先。創作方面接近的是WP:維基榮譽WP:CHOICE。--YFdyh000留言2022年10月9日 (日) 13:47 (UTC)
管理人員每日待處理的工作還不夠多嗎、增加這樣的制度檢視管理人員似有不妥、每日待處理事務有多少,光是封禁和保護就有得忙了,就算想寫什麼也要擠得出時間,每個人都是志願者,管理人員更是志願擔更多的維護責任的人,用「沉迷管理」來描述這個真的不太好吧。--Mafalda4144留言2022年10月9日 (日) 14:01 (UTC)
什麼破提議。管理員是拿掃帚的清潔工。而編輯條目的是工作人員。清潔工的權利就是能進入很多工作人員進不去的地方。w:WP:NOBIGDEAL--0xDeadbeef留言2022年10月9日 (日) 14:05 (UTC)
++ —— Eric Liu 創造は生命(留言留名學生會 2022年10月11日 (二) 00:53 (UTC)
相比之下,萌娘百科的管理員要求還真是德政啊。現在貴站有誰可以一個月寫一條GA啊。--Ghren🐦🕚 2022年10月10日 (一) 03:34 (UTC)
(+)強烈支持
作為一個編輯者,當然是希望以管理員級數為目標,如果管理員不提供參考予所謂破壞者,又對破壞者施加punishment,如何服眾?
(&)建議管理員、行政員、回退員、巡查員每一季挑選部分劣質條目並加以編輯。然後提交編輯比例至少達40%的5個GA或通過1個共議制FA,否則很難稱得上這個職位。--唔好阻住我愛國留言2022年10月10日 (一) 10:51 (UTC)
登上首頁的條目都是可供參考的範例,可每天新增的條目有多少以此為目標,佔數據空間的有多少?就算真的這麼要求管理群好了,這樣能減少我行我素的使用者無視規則建立條目嗎?有多少使用者知道什麼是典範或優良?一個佔數據空間的條目爽快建立,要存還廢要看是不是侵權還要想辦法幫他改善,覺得該要求管理群的各位平常有自願幫忙協助改善條目?這是所有維基人都可以做的事,為什麼只要求管理群要立標竿?破壞者比如LTA:KORTV根本才沒有管什麼目標,想破壞就破壞。--Mafalda4144留言2022年10月10日 (一) 11:07 (UTC)
管理員應該做更多,如果他沒有能力做更多的事情,理應辭職並當回普通編輯這一個。--唔好阻住我愛國留言2022年10月10日 (一) 11:15 (UTC)
這個所謂的「破提案」如果通過,動的是所有管理階層的蛋糕,但是能讓管理員和行政員的定位更明顯。管理員和行政員理應是所有用戶寫條目的「標杆」。
(:)回應如果是這樣的話,那管理員選舉也得改改。應該看候選人創作多少優良條目和典範條目,而不是看有多少WP:維基榮譽
WP:維基榮譽能「刷」出來,而優良條目和典範條目需要經過普通編輯者的篩選。Assifbus留言2022年10月9日 (日) 13:53 (UTC)
為什麼您認為管理員、行政員要「條目寫的好」,也有技術型管理員啊。只要對條目撰寫等規則的理解到位,不寫任何條目也行的。巡查員、回退員等同上,編寫條目只是證明能力的途徑,並不是強加在這些身份上的必然任務。--YFdyh000留言2022年10月9日 (日) 13:59 (UTC)
所以我說的是絕大多數。技術型管理員除外。Assifbus留言2022年10月9日 (日) 23:02 (UTC)
如果混合型怎麼辦?而且本來如果按照分工的話,就只有技術型和行政型的,一個臭寫條目的,做管理員就是邊寫條目邊封人嗎? 從立論就是有問題的,管理員等的當選與編寫條目數質並沒有直接的關聯。——Sakamotosan路過圍觀 | 避免做作,免敬 2022年10月10日 (一) 02:55 (UTC)
冒昧再說個,打算用這樣的標準檢視管理群之前,是否自己達到了這樣的標準呢?您建立的每個條目方方面面都符合優良以及典範嗎?或是退一步來說有符合到維基百科最基本的標準呢?—Mafalda4144留言2022年10月9日 (日) 14:13 (UTC)
對管理人員的要求理應要比其他用戶高。我承認自己有很多不足,所以也一直沒申請管理員。如果管理員申請時和在任時不撰寫優秀的條目內容,那麼我這種寫條目的「菜鳥」也可以當管理員,在處理站務方面會比一些人處理的更好。(玩笑話)@Mafalda4144Assifbus留言2022年10月9日 (日) 22:53 (UTC)
真的當管理員們申請頭銜擺放著好看的啊,寫個條目要花多少心力,處理站務差不多就死那麼多腦細胞了可能還更多,近期變更隨便看都會遇見破壞,您有沒有去逛過呢?用掉自己比金錢還珍貴的時間、自願出來擔這些比毛還毛的毛躁事、都不用管才可以專心寫條目好不好是不是?順帶一提若您想申請管理員也是可以的就跟著程序走,不過大家比較想要知道的,應該會是您在站務上打算協助哪方面的事喲,您可以現在開始去看「管理員忙什麼」。--Mafalda4144留言2022年10月10日 (一) 01:09 (UTC)
(-)反對。 ——魔琴 [ 留言 貢獻 ] 2022年10月10日 (一) 02:09 (UTC)
根本思想就已經不正確了。管理員與行政員不是什麼「高位」,因為他們擔負的義務遠高於享有的權利。另外,WP:維基榮譽能「刷」出來......嗎?閣下不妨著手先替自己「刷」看看,看刷不刷得出來,如果刷得出來,建議閣下可以更上一層樓,爭取「爭上高位」,享受種種「特權」,在下絕不會羨慕或忌妒您的。-游蛇脫殼/克勞 2022年10月10日 (一) 06:26 (UTC)
反駁一下。明明是享有的權利高於擔負的義務。如果管理員人人盡職盡責的話,我今天也不會提出這個議案了。很明顯一些人只充分的享受權利卻沒有盡多少義務。Assifbus留言2022年10月10日 (一) 09:52 (UTC)
我的提議值得通過,這會讓維基百科煥然一新。Assifbus留言2022年10月10日 (一) 23:52 (UTC)
本站之管理員權限,是任何獲社群信任者都有資格獲得,而不是要以什麼天大地大的苦勞來換取的,與所謂「法官」之流更是無從相比;不管會不會寫條目,能夠獲得社群信任,那麼就有資格能獲得管理員權限。強迫管理員「作業績」這種事——無論是寫條目還是處理站務——純屬不理解其制度宗旨的無稽之談。換個角度說,如果今天本站有足夠的管理員,還有必要硬是去壓榨剩餘之有限人力麼?終歸是社群「信任」不夠多人的緣故。請不要捨本逐末,把那些願意接下社群信任「掃帚」的「清潔工」都趕跑了。—— Eric Liu 創造は生命(留言留名學生會 2022年10月11日 (二) 00:53 (UTC)
另外說一句,寫條目越多,越容易捲入或引發編輯衝突,也就越難成為管理員(畢竟要經過社群投票),所以近年能「憑藉撰寫優秀的條目內容登上高位」者實已屈指可數矣。還有一個矛盾是,越常參與社群討論(例如現在這則話題),與他人意見相左、乃至於爭吵之頻率就越高,這同樣也會在管理員申請時成為明顯的阻礙。例如現在這則話題,我講了上面那一席話,豈不是會惹到不少人?這樣我即使想為、而且能夠為社群做事,也難成功了。—— Eric Liu 創造は生命(留言留名學生會 2022年10月11日 (二) 01:02 (UTC)
同意Eric閣下的看法,認為相應自治體代權機制之改進並不能以單一衡常編輯參與度等機械化數據為考慮依據,綜合來說相應問題在理想情況下適宜採用分權和複合設計而分攤相應站務之自治,但如Eric閣下所言之矛盾所反映之側面、相應事務亦可能於局限內。--約克客留言2022年10月11日 (二) 02:55 (UTC)
要這麼搞可以啊咱不反對,那誰給管理員行政員付錢,一個月10萬USD,年終獎金3個月,寫出一條FA1萬獎金GA5千獎金,付的下去再來提這些。--~~Sid~~ 2022年10月11日 (二) 02:43 (UTC)
(-)傾向反對。管理員的本質也僅是普通的編者,只是擁有更多的權限以便維護耳。要求提高顯然很荒謬。--  |2022年10月11日 (二) 03:00 (UTC)

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

Jimmy200001 騷擾多篇文章

Jimmy200001

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

整理管理員用戶組權限

下列討論已經關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。結論綜敘如下:
關閉特定方案,以下方小節聚焦問題核心為先。--西 2023年7月20日 (四) 07:02 (UTC)

為釐清管理員用戶組的權限的作用,我主張自管理員用戶組移除以下沒有管理作用、純粹重複其他用戶組的基礎編輯權限。移除這些權限不會影響管理員的任何操作,因他們屬於其他用戶組而仍然保留了這些權限:

一、所有自動確認用戶或更低權限者均持此權,而這些權限無法移除,管理員用戶組持此權實屬冗餘重複
  • 上傳文件 (upload)
  • 不受基於IP的速率限制 (autoconfirmed)
  • 執行觸發驗證碼的操作時無需驗證 (skipcaptcha)
  • 新建用戶賬戶 (createaccount)
  • 創建短鏈接 (urlshortener-create-url)
  • 將結構式討論話題標記為已解決 (flow-lock)
  • 查看當前轉碼活動的信息 (transcode-status)
  • 查看詳細過濾器日誌 (abusefilter-log-detail)
  • 移動分類頁面 (move-categorypages)
  • 移動根用戶頁面 (move-rootuserpages)
  • 移動頁面 (move)
  • 編輯保護級別為「僅允許自動確認用戶」的頁面 (editsemiprotected)
  • 編輯其他使用者的結構式討論話題的標題 (flow-edit-title)
  • 編輯其它用戶的結構式討論帖子 (flow-edit-post)
  • 覆蓋現存文件 (reupload)
  • 重置已失敗或已轉碼的視頻將其再次加入到作業隊列中 (transcode-reset)
二、修正設立XCON前的管理員不能自動提升為延伸確認用戶的問題(即令所有管理員都是XCON),後可直接繼承自延伸確認用戶組而非管理員用戶組的權限:
  • 編輯受延伸確認保護的頁面 (extendedconfirmed)
  • 移動文件 (movefile)
三、如可,將自動巡查從管理員分拆,因其不涉及主動的管理行為,而管理員又沒有「會寫條目」的要求(2023年7月20日 (四) 11:23 (UTC)增訂)
  • 使自己的編輯自動標記為已巡查 (autopatrol)

目標為使管理員用戶組與其他進階權限看齊,不持有與其他基礎用戶組重複的權限,便於往後判定何為「使用管理權限」;例如與如何判定其他用戶組(如巡查員)是否有「使用權限」(WP:RFDR慣常的討論重點)看齊。簡單來說,就是剩下的權限如回退、保護、封鎖等,用了就視為「作為管理員身份的行動」,依管理行動的相關程序申訴,而非視作「作為一般用戶身份的編輯」處理。上面要移除的都不是用作管理的,不需要由管理員額外重複持有。--西 2023年7月18日 (二) 17:16 (UTC)

(-)反對這提案,濫用上述權限應當同樣視為濫用管理權限,否則管理人員濫用權限的情況無法得到正視,因為管理人員不當使用上述權限所進行的操作相對於一般用戶更難處理(比如移動頁面)。Sanmosa In vain 2023年7月19日 (三) 00:22 (UTC)
管理員濫用權限包括但不等於也不限於濫用管理權限,也包括濫用一般編輯權限。管理員濫用管理權限毫無疑問是立即緊急除權,而濫用一般編輯權限則可與一般用戶一樣以封鎖處理,(然後再除權),完全不衝突。依照閣下的論述,管理員不當使用「編輯頁面 (edit)」權限(並不附於管理員用戶組上)就跟「移動頁面 (move)」有分別了?兩者同樣是「暴走的管理員可能會濫用的權限」,有何不同?
以最近一次Ws227的除權作為例子,最終先以不限期封鎖阻止濫用移動權(及移動不帶重定向權)再除權,與我的觀點完全一致。
這裏所分辨「管理權限」跟「一般編輯權限」的差異在於影響應作為管理行動申訴還是作為一般不當行為提報。若管理員濫用以上摘除的基礎權限,與庶民同罪一般用戶的處理方式應當相同,應當封鎖、禁制處理,以此預防進一步擾亂行為;上面沒有摘除的「管理權限」(如回退、保護、封鎖等)則應在管理員佈告板(主頁)申訴,有濫用則是在客棧討論除權。--西 2023年7月19日 (三) 01:20 (UTC) / 修訂於2023年7月19日 (三) 10:51 (UTC)
您目前的觀點是把「管理員濫用權限」和「濫用管理權限」混為一談。我這裏的目的是分辨清楚哪些是「用作管理的權限」和「一般編輯權限」,然後您的回應立馬就展現了把「管理權限」跟「編輯權限」混亂了的情況,更加佐證我分拆權限的需要。分拆了不會使管理員濫用一般編輯權限沒有後果,只是將後果與其他用戶同化(提報AIV、AN3、ANM)並被封鎖或禁制。
最佳的類比例子應如此:回退員濫用「編輯頁面 (edit)」權限,您也不能直接提報至WP:RFDR,而是該報AIV、AN3,然後再討論用戶是否適合繼續持有該權;只有濫用「快速回退最後一位用戶對某一頁面的編輯 (rollback)」或「移動頁面時不在原頁面創建重定向 (suppressredirect)」時才會提報WP:RFDR
補充上面:提報一般的不當編輯行為是AIV、AN3、ANM等,AN的子版面是「提報給(不涉事)管理員處理的案子」;AN本身則是「討論管理員操作的地方」,作用不同。--西 2023年7月19日 (三) 01:34 (UTC)
@LuciferianThomas:「管理員濫用管理權限毫無疑問是立即緊急除權」現在的情況並非如此,緊急除權的要求是濫用管理權限對維基百科造成巨大損害,其他情況就算真濫用了管理人員專有權限也是走解任投票,另參上方討論(該討論串中,有個別管理員甚至認為就算管理人員濫用管理權限且對維基百科造成巨大損害,也有不需要立即緊急除權的情況,雖然我自己肯定不認同就是了)。我個人的看法是既然管理員用戶組持有相關權限,那相關權限就是管理權限。Sanmosa In vain 2023年7月19日 (三) 10:19 (UTC)
所以緊急除權跟一般除權結論都是除權,不影響我論述啊。「個人的看法是既然管理員用戶組持有相關權限,那相關權限就是管理權限」,然而現在社群有成員(昨天TG討論)連回退都不承認是管理權限,您這過度延伸更不可能被他們接受。「管理員用戶組持有相關權限」但「該權限並非先由管理員用戶組賦予」,那麼該權限就不是管理權限,而是一般編輯權限。--西 2023年7月19日 (三) 10:28 (UTC)
「緊急除權跟一般除權結論都是除權」,但從過往經驗來看能真正除權的比率很小,論述不能流於理論。Telegram的討論不能當成社群共識,管理員用戶組持有的權限列表則是固定的,用管理員用戶組持有的權限列表來判定管理權限是甚麽顯然合理得多。Sanmosa In vain 2023年7月19日 (三) 10:40 (UTC)
您要不要看看您的意見與下方Cwek的意見有多衝突,您們二人的論述已經完全反駁對方的論述,是方便我把您們兩個自相矛盾的異議當成您們互相駁斥了嗎()。Telegram的討論不能當成社群共識,這是理所當然,問題是連那邊都未曾達成共識啊,不然我拔上來討論幹嘛。管理員用戶組持有的權限列表則是固定的:否,提案可以修改,那麼就不是固定的;且社群未曾認定那些是管理權限,已經過社群共識認定為管理權限的只有管理員方針所列之權限。我認同用管理員用戶組持有的權限列表來判定管理權限是甚麽顯然合理得多,但現今持有權限列表與方針所列「管理權限」相悖,所以才提案將不屬於社群認定的管理權限自管理員用戶組移除。--西 2023年7月19日 (三) 10:48 (UTC)
我有看過,但我為甚麽必須要看,反正我跟他都是來反對提案的,具體反對理由的差異不是我需要關心的事情。我説「Telegram的討論不能當成社群共識」這話的意思是Telegram群組裏的東西並不是這裏客棧討論應該關心的範疇,任何Telegram群組裏的討論都不能納入客棧討論共識的考量之內。既然你説到「管理員用戶組持有的權限列表」是「可以修改」的,那容我先問一個問題:誰在技術上有具體權限修改?Sanmosa In vain 2023年7月19日 (三) 10:59 (UTC)
「管理員用戶組持有的權限列表」是「可以在取得社群共識後提報phab:修改」啊。不存在社群無法修改管理員權限的部分,phab(正常來說)除了技術原因外也不能以技術問題以外的原因拒絕社群共識所得,自然是「可以修改」的。我有看過,但我為甚麽必須要看,反正我跟他都是來反對提案的。很簡單,既然兩位的異議是互相矛盾的,那我可以拿他的論述來反駁你的異議,再拿你的論述反駁他的異議,自然兩個都是WP:共識方針所視為已經反駁的異議啊。兩個完全矛盾的異議就代表兩個都是有問題的異議論述。--西 2023年7月19日 (三) 11:06 (UTC)
我問的是「誰在技術上有具體權限修改」,不過你既然都已經説了是phab那邊的人,那我也不執著於此太多了,但我們此前應該有一段很長的時間沒有報過phab那邊修改管理員用戶組持有的權限了,那權限列表相對而言比起管理員方針頁面穩定得多,因此權限列表的可參考性更大。「phab(正常來說)除了技術原因外也不能以技術問題以外的原因拒絕社群共識所得」(這句是不是有語病?),那這裏牽涉到兩個問題:(1)現在管理員用戶組持有的權限的設定有沒有背後的技術原因?這點我們完全不知道,假設是真有先前我們並不知道的技術原因的話,那就算這裏的用戶100%同意修改,這不也是徒勞嗎?(2)你提到「正常來說」,但你是否能夠確定你理解上的「正常來說」跟phab那邊理解的「正常來說」一致?phab會不會認為現在的情況不屬於「正常來說」的情形?不管如何,我覺得你應該先確認一下phab一般會不會處理這種移除「重複權限」的操作。Sanmosa In vain 2023年7月19日 (三) 11:22 (UTC)
但我們此前應該有一段很長的時間沒有報過phab那邊修改管理員用戶組持有的權限了:否,設立WP:XCON的時候就(被動)新增過管理員用戶組的「編輯延伸確認保護頁面」權限。我稍後會去問問技術上是否允許。--西 2023年7月19日 (三) 12:01 (UTC)
不理解歸類「管理權限」的意義。管理員被指創建質量不佳頁面,受到巡查豁免,也是濫用「管理權限」、可直接提報解任討論嗎。拒絕溝通和共識才是濫用,否則只是編輯爭議,涉及權限而便利但一般用戶也可做到同等效果的事情,應該歸類為一般操作。用到權限可能是無意識或者節省時間,而節省時間是因為社群對該用戶組有更高的信任度而授予,僅憑爭議涉便利權限來討論剝奪用戶組的實質權限是很奇怪的——仿佛用TW做了不妥回退,於是列入TW工具黑名單(假設存在)。--YFdyh000留言2023年7月19日 (三) 11:56 (UTC)
管理員持有巡查豁免這一問題跟巡查員是否應該持有巡查豁免一樣,如果社群在#提議重組現有的用戶權限組的討論中認定巡查員不應該巡查自己條目的話,那同樣應該剝奪管理員的巡查豁免權限,成為管理員的要求中也不存在獲得巡查豁免的要求,沒寫過幾個條目的也是可以成為管理員的(尤為站務、反破壞專長者),所以我不會拿巡查豁免來說。此案是回應閣下在TG群認為「回退不應視作管理行動」的觀點,我不否認存在管理員使用回退功能(帶編輯摘要)參與編輯爭議的可能,但「對回退操作有異議」是否如閣下所認為「必然歸類一般操作視作編輯爭議」並不認同。若管理員已判定對方不是對內容爭議而是明顯的破壞、侵權或擾亂回退,並以封鎖、保護、禁制等管理行動接續,那回退操作跟封鎖保護禁制等分開申訴顯然不合理,這是我的論點。--西 2023年7月19日 (三) 12:13 (UTC)
不看好剝奪管理員的巡查豁免。至少目前,巡查豁免是管理員用戶組的權限吧,所以按上文所說,創建頁面也變成了動用管理權限。我的觀點,附理由的回退功能應視作非管理行為,尤其是摘要認真對應回退內容時。無理由的回退,除非明顯的濫用或爭議或不回應,否則也可能出現對「明顯破壞」理解不同產生的無理由反破壞,而使用回退與使用撤銷、TW回退通常並無本質區別,操作更快是權限所給但絕非權限主體。除非摘要附上或另發警告,否則不認為回退是任何管理行動的前奏。--YFdyh000留言2023年7月19日 (三) 12:36 (UTC)
有點矯枉過正?例如其他項目區有沒將高階用戶組中清理在低階用戶組中已經包含的重複權限?——Sakamotosan路過圍觀 | 避免做作,免敬 2023年7月19日 (三) 01:04 (UTC)
別人沒做不代表我們不能做。既然是重複的,為何不摘除?既然有助分辨哪些是進階的管理權限(回退、巡查、封鎖、保護、過濾器編輯權)和一般用戶都有的普通權限(編輯、移動、上傳),為何就是矯枉過正?如何修到「超過了適切程度」?--西 2023年7月19日 (三) 01:23 (UTC)
Wikipedia:管理員指定了哪些是管理員的權責,不認為用戶組的權限配置與管理員的角色權責直接關聯來定論。用戶組配置權限的重複不影響功能的使用,我不認為。——Sakamotosan路過圍觀 | 避免做作,免敬 2023年7月19日 (三) 03:10 (UTC)
既然方針指明管理員只有哪些額外權責,那為何用戶組需要重複管理員已經有的權限?編輯延伸確認保護頁面不是管理員權責,為何該權限附於管理員用戶組而不是附於延伸確認用戶然後管理員能如一般用戶自動獲得延伸確認用戶組?移動權在「用戶」組,該權限為何需要重複附於管理員用戶組?那回退員持有移動不帶重定向權,又是否需要重複提供move權限確保他能移動條目?不是嘛。整個邏輯上既然不合理,技術上沒壞,意義上壞了。--西 2023年7月19日 (三) 04:39 (UTC)
可能技術原因,因為管理員用戶組最早並肯定存在,而其他用戶組和自動用戶組可能不曾存在,體驗權限首先給管理員而非新增用戶組,以及極特殊情況下可能(臨時)管理員用戶不具自動確認等用戶組。建議您先諮詢技術人員,看「清理權限」是否可行和被接受,至少英文維基沒這麼做。如果技術人員不願執行此操作,討論共識決定哪個頁面/哪些權限為「管理權限」就好,別用這個系統信息。--YFdyh000留言2023年7月19日 (三) 11:44 (UTC)
大致意見如此,建議去其他地方(例如mw的討論區、en的技術版)問一問技術上移除管理員組裡面這些權限有沒技術上的影響。如果不影響的話,再討論用戶組的權限與職務角色的權力是否關聯。——Sakamotosan路過圍觀 | 避免做作,免敬 2023年7月20日 (四) 00:15 (UTC)
再者,Wikipedia:管理員#權限完全只是基於用戶組的權限配置然後選擇了特定權限表達是管理權限,更加反映社群本來就有分辨哪些才是管理員額外於一般用戶擁有哪些權限。該列表更是不知道多久沒人更新了。既然該列表是基於用戶組的權限配置,那用戶組的權限配置就應該反映這些權限屬於管理權限的事實,然後直接引導用戶去看用戶組權限配置,而不是放一個static的表在那裏不更新。--西 2023年7月19日 (三) 04:52 (UTC)
純屬玩笑,也可能是mw初始化設置下的一個後備:一個用戶(user)授予了管理員(sysop),因為需要移動頁面權限(move)。——Sakamotosan路過圍觀 | 避免做作,免敬 2023年7月19日 (三) 03:14 (UTC)
很可能是初始遺留,那既不需要則應移除。--西 2023年7月19日 (三) 04:41 (UTC)
如果舉Ws227做例子的話,我認為,Ws227的移動操作實際上普通用戶也能弄(好像對應頁面是屬於「目標頁只有一個版本且是來源頁的重定向是可以覆蓋移動的」的情況),應該這個問題扔去AM3、ANM等處理的,但因為其「管理員」的身份,加上裝死般不回應,才提升到「是否適格作為管理員」的層面,但注意的是,他這個案例中並沒有用到「管理員」用戶組或者角色特有的管理性質權限,包括保護頁面、封禁用戶等,只是其行動的性質不符合作為「管理員」的期望(或者社群認為他這樣做根本不符合作為一名管理員),而且相關頁面以前他也這樣處理過,並且碰上「槍口」了。據上,實質上「管理員」用戶組所擁有的權限(無論是面向管理性質或者非管理性質)與作為「管理員」身份的權力並不直接關聯,而社群看管理員是否適格是看其行為而不是其使用權限,或者說使用到的權限(無論是來自於管理員用戶組還是其他附帶的用戶組)只是行為的表現,和是否需要清除用戶組所謂重複權限這個意見上,我認為是風馬牛不相干的,所以我認為這不是壞。——Sakamotosan路過圍觀 | 避免做作,免敬 2023年7月20日 (四) 00:39 (UTC)
否,Special:Log/delete/Ws227顯示存在覆寫刪除多於一個版本的重定向(需delete權限),且動用了多次undelete權限,顯然是濫用管理權限。--西 2023年7月20日 (四) 02:14 (UTC)
Special:Log/delete/Cwek那我呢?覆蓋移動是會觸發G8刪除。至於undelete的話,我再看看。——Sakamotosan路過圍觀 | 避免做作,免敬 2023年7月20日 (四) 05:52 (UTC)
嗯?那我大概記錯覆寫重定向的部分了;不過有幾則(1327644013276638)都似乎是一般的刪除動作。--西 2023年7月20日 (四) 06:12 (UTC)
歷史有點亂,有多筆新春移動後新建重定向頁的記錄,可能正在嘗試修正陰曆新年新春由於移動導致的內容異常關係,之後新春也經過其他管理員還原恢復過。如果從這裡看,可能是管理員用戶組特定(可能因為有delete權限)導致允許覆蓋移動時刪除掉多版本重定向頁,但並不是因為有delete權限或者有其他不相關的權限而認為是否適格管理員,而是從整個行為——包括這樣無意間利用權限的便利來處理頁面,而且並沒有討論共識等支持;及之後的不回應(即使上線後做過其他編輯)——認為這不是再適合作為管理員,與用戶組是否有那些權限無關,或者盲目地認為將管理員的權責與用戶組的權限簡單地關聯看待。——Sakamotosan路過圍觀 | 避免做作,免敬 2023年7月20日 (四) 06:30 (UTC)
部分缺失記錄(簡單來說,我不是管理員,看不到或看不出),但也不一定全是是壞的管理行為,例如納徵過大禮這一對,納徵其中有相鄰記錄是2022-02-10~2023-06-22,前面的有大量侵權內容處理,2023-05-25由Wing按照侵權刪除過,而Ws227在2023-05-27(納徵應該是還原到2022-02-07 InternetArchiveBot那筆)、2023-06-01(過大禮)做過相關的還原,可能是侵權刪除的原始內容修復處理。同上述的,部分相關的行為和用戶組存在那些可能重複於其他用戶組的權限需要處理有關係,而且我認為是以角色所做行為作為評判標準有關,而不單純依靠用戶組的權限設定。——Sakamotosan路過圍觀 | 避免做作,免敬 2023年7月20日 (四) 06:09 (UTC)
元宵節元宵節 (華人)元宵节 (华人)):丟失了太多和由於這次事件可能沒完全還原版本,我推測可能是元宵節移動元宵節 (華人)並且刪除了元宵节 (华人)(認為可以繁簡轉換而沒必要保留),可能利用了delete權限來處理他認為沒必要的頁面。——Sakamotosan路過圍觀 | 避免做作,免敬 2023年7月20日 (四) 06:48 (UTC)
Wikipedia_talk:管理員解任投票/Ws227/第3次:涉無故回退存廢討論的合併結論,同樣屬於管理操作。--西 2023年7月20日 (四) 06:51 (UTC)
2022-02-25T11:37:40由Wing按照侵權刪除(這時頁面位置為空?),2023-05-17T06:52:15有人創建了一頁新的頁面,2023-05-25由Wing按照侵權刪除,而Ws227在2023-05-27還原49個版本,大致數了一下,可能是去到「2022-02-07T21:37:09‎ InternetArchiveBot」的版本,之後Wong128hk再還原了3個版本,可能是2022-02-10的三筆版本,然後以侵權內容再隱藏了49+1版本。我猜測Ws227可能沒留意到更早的版本有侵權問題,或者到「2022-02-07T21:37:09‎ InternetArchiveBot」的版本並沒有問題,之後加了或者重新整頁為侵權內容按整頁刪除,然後Ws227恢復後,在這次混亂中將更早的版本當成侵權內容一併隱藏了。(由於更早的版本是隱藏的,無法比對現在內容, 只能推測如此)——Sakamotosan路過圍觀 | 避免做作,免敬 2023年7月20日 (四) 07:16 (UTC)
(+)支持--Firedoge2023留言2023年7月20日 (四) 05:20 (UTC)

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

管理行動與管理員的角色的判定

@CwekSanmosaYFdyh000:被三位搞到完全亂了。給三位整理一下上面完全矛盾、互相駁斥的論點:

  • 我主張儘量將不涉及「管理」社群的權限自管理員用戶組移除,並明顯屬於管理員專有權限(如保護、禁制、封鎖)接續的一系列的動作(包括管理及非管理操作,如回退、還原至某個版本、移動等)都視為管理行動的一部分
  • Cwek主張以管理員方針 § 權限一節及以角色所做行為作為[是否視作管理操作(?)]評判標準;
  • YFdyh主張回退無論怎樣只要有異議都能視為編輯爭議,按我對其留言的理解,其立場是「只要操作是普通人能做(不論什麼方式),就當成是普通人」;
  • Sanmosa的主張是現在Special:UserGroupRights#sysop所列所有權限都是管理權限。

我的方案是站在三位的正中央,三位是在三角形的三個角上,您們現在是在不斷反駁對方的論點,要不要先理順您們的異議論點。--西 2023年7月20日 (四) 06:28 (UTC) / 2023年7月20日 (四) 07:36 (UTC)修訂

但有一點我和另外兩位是一致的:必須先確認你提議的操作是否一般上可被phab接受。Sanmosa In vain 2023年7月20日 (四) 06:43 (UTC)
那是另一回事。提案的最終目的是判定什麼屬於管理員的角色、什麼屬於管理行動的一部分、什麼應該以申訴而非爭議形式處理。直接動用戶權限只是其中一個直接處理的辦法。--西 2023年7月20日 (四) 06:48 (UTC)
但如果不這樣做的話,討論很容易會失焦。現在的情況就是這樣。Sanmosa In vain 2023年7月20日 (四) 06:55 (UTC)
看來我不關討論您是看不懂我的意思。現在重點轉移了,重點是「什麼應判定為管理行動」,後續如何執行待此討論有什麼結論再說。--西 2023年7月20日 (四) 07:04 (UTC)
我覺得技術上有什麼權限根本不重要,重點在於是否有意或無意地以「管理員」的身份操作,否則就應視為與普通編者無異。當然,如果利用只有管理員有的權限,那自然算是管理操作,這也毫無疑問。—— Eric Liu 創造は生命(留言留名學生會 2023年7月20日 (四) 07:13 (UTC)
閣下所提出的判斷標準似乎非常主觀(有意和無意由誰定奪?似無客觀標準),難以作出有效評判;甚至管理員可以按照自己利益更改說法。就以站外討論時辯論的例子(雖然我沒明講是此例):管理員Mys_721tx印度等條目注意到用戶IAVZR(無視後續查核發現是傀儡一事,對事不對人)的侵權編輯(使用回退功能並在第一次回退附有「-rc(回退侵權)」的摘要;後續無再重複提供理由),並予以回退及封鎖。在此例中,沒有客觀標準判斷是否有意以管理員身份操作。爭議點是「是否管理操作影響後續處理如申訴/提報爭議等的合理性」:我主張回退本是管理操作,後續更接續明顯為管理的封鎖操作,回退一事應作為管理行為的一部分申訴;YFdyh認為回退只是加速版的編輯撤銷不屬於管理操作,應作為一般編輯爭議提報處理。--西 2023年7月20日 (四) 07:31 (UTC)
除了按管理員等方針規範,就是社群共識以及常識。只要有完整前後文脈絡,以常理即可判斷上述回退屬於管理操作的一部分,不應當分開來看。你確定YFdyh000君真的認為這種回退也算是單純編輯爭議?—— Eric Liu 創造は生命(留言留名學生會 2023年7月20日 (四) 08:01 (UTC)
我對其2023年7月19日 (三) 12:36 (UTC)的留言的理解正是如此。--西 2023年7月20日 (四) 08:26 (UTC)
「身份說」有用但會有主觀判斷的成分。回退屬於「管理行為」,但非管理員也能做所以不是「管理操作」。如果是處理侵權、存廢討論等提報中的操作之一,可能視作以管理員身份在結案的操作,但編輯條目本身可能仍不是「管理操作」,結案、保護、刪除等才是。如果是日常巡查中直接回退,只是在反破壞,其他人難以看出這是「管理員結論」,也沒必要看出這點;哪怕是「再加就封禁」編輯摘要或對話頁警告,普通人也能做,只是管理員的身份強化了執行力。一般編輯何時算「管理操作」的一環,具體走哪個申訴流程,我真的覺得影響不大,看操作結果是否符合共識和溝通就好了。投訴時將一般編輯歸入「該管理員的操作」我沒意見,但能投訴「濫用管理權限」我覺得很怪。--YFdyh000留言2023年7月20日 (四) 16:37 (UTC)
提案者是認為「管理員」的權責應該與「管理員」用戶組的權限直接關聯來規範定義「管理操作」;但我(或者包括其他用戶)認為應該以「行為」來判斷,權限只是行為下的使用表現(可能是有意無意的,例如覆蓋移動多版本重定向可能是delete權限的體現,但他可能認為只是在正常的編輯操作,這是可能是無意的;對於其他用戶的話,只能覆蓋移動單版本重定向,如果有用戶組也有delete權限,他也可能無意間做到類似「管理員」那樣的操作),我不認為以為了建立這種強關聯為由來清理所謂的與其他用戶組重複的權限。——Sakamotosan路過圍觀 | 避免做作,免敬 2023年7月20日 (四) 07:26 (UTC)
現在已先不討論是否技術上移除管理員用戶組的重複權限;我的立場亦有說明我認同應該以行為判斷,然而大家這一部分的標準完全不一致,這才是這個小節的討論之處。--西 2023年7月20日 (四) 07:33 (UTC)
這樣説,我對於管理員權限的認定分為「實權限」與「虛權限」,其中:
  • 「實權限」是管理員用戶組技術上可以行使的所有權限,其中再細分為:
    • 「非專有實權限」,即一般延伸確認用戶可以行使的權限,因為所有管理員都理論上是延伸確認用戶,以及
    • 「專有實權限」,即一般延伸確認用戶不能行使的權限,也就是技術上相對於延伸確認用戶而言僅容許被列入管理員用戶組的用戶行使的權限(例如頁面的刪除權與恢復權),而
  • 「虛權限」則是技術上任何延伸確認或以下用戶都能操作,但實務上只認定管理員的操作有效或不可直接推翻的權限(例如頁面存廢討論的保留決定,非管理員作出的決定可以直接重開,但管理員作出的決定不可以,只能經DRV決定推翻與否)。
我的意見是:
  • 從定義上而言,所有「虛權限」都依賴「實權限」操作,但並不一定依賴「專有實權限」操作,而「虛權限」可以是多個「實權限」的集合;
  • 從定義上而言,「專有實權限」與「虛權限」必然為「管理權限」,而「非專有實權限」則需視乎情況而定;
  • 「實權限」是技術上的東西,需要由技術站點特別授予,因此社群單設立本地規則而不做任何其他事情無法讓管理員獲得「實權限」;
  • 「虛權限」由於並不一定經常依賴「專有實權限」操作,因此並不是技術上的東西,繼而可以通過設立本地規則讓管理員獲得「虛權限」;
  • 濫用管理權限的情形包括:
    1. 濫用「專有實權限」、
    2. 濫用「非專有實權限」且該使用「非專有實權限」的情形被認定為屬於使用「管理權限」,以及
    3. 濫用「虛權限」。
因此,管理員故意在AFD將顯然不適合保留的頁面以「保留」結案雖然沒有濫用任何「專有實權限」,但仍然是濫用管理權限,不能因為該管理員沒有濫用任何「專有實權限」而認為他沒有濫用管理權限;
  • 管理員使用「非專有實權限」的情形是否屬於使用「管理權限」的判定權,以及是否使用了「虛權限」的判定權,均在於社羣,而非管理員本身。管理員可以自由心證,但如其自由心證不合理,社羣有權不予接納。社羣應以管理員的行為判定管理員使用「非專有實權限」的情形是否屬於使用「管理權限」或是否使用了「虛權限」。
以上。Sanmosa In vain 2023年7月20日 (四) 11:05 (UTC)
修改於2023年7月21日 (五) 00:44 (UTC)。Sanmosa In vain 2023年7月21日 (五) 00:44 (UTC)
您對於「實權限」的觀點已被YFdyh反駁:至少目前,巡查豁免是管理員用戶組的權限吧,所以按上文所說,建立頁面也變成了動用管理權限。2023年7月19日 (三) 12:36 (UTC))。以閣下的論點,管理員擁有editsemiprotected、autopatrol、extendedconfirmed等權限,編輯受延伸確認保護頁面(注意大部分管理員沒有延伸確認用戶組,即其延伸確認保護編輯權是管理員組授予)、創建新頁面也實際動用了Special:ListGroupRights#sysop所列sysop用戶組的權限,這顯然是不合理的。--西 2023年7月20日 (四) 11:12 (UTC)
我現在重新想了一下,我的意見是管理人員動用Special:群組權限中所示的「(全部)群組」所有的權限可以不視為動用管理權限。但是如果到了(自動)確認用戶專有的權限的層階的話我不支持,因為(自動)確認用戶專有的權限已經是相對於一般人(要考慮到整個網絡世界的範圍)而言較高階的權限,但動用管理權限的操作所針對的對象不一定全部都是(自動)確認用戶,所以管理員使用editsemiprotected、autopatrol、extendedconfirmed等管理員組所有的權限應該要視為動用了管理權限。Sanmosa In vain 2023年7月20日 (四) 13:24 (UTC)
閣下對「管理」二字有非常嚴重的誤解。editsemiprotected和extendedconfirmed等權限是無法主動摘除的,即使失去管理員狀態仍然存在,表示摘帽子仍然不會阻止其繼續享有該等權限者,顯然非「管理員特有的進階權限」更非「主動用作管理維基百科的權限」,不可能符合「管理權限」的意思。需要跟一般用戶一樣以封鎖處理,而不能單靠移除管理權限永久阻截該等行為的,就證明了「管理權限」跟「一般權限」的差異。--西 2023年7月20日 (四) 13:41 (UTC)
我覺得我沒有誤解,這應該就只是我跟你將拿來跟管理員組對比的用戶權限組別有分別而已。那我還有另一種認定方法,就是要視乎管理人員行使權限時主要影響的對象有甚麽人,如果上至延伸確認用戶的話,那行使與延伸確認用戶重複的權限不視為動用管理權限,但如果上至自動確認用戶(而非延伸確認用戶)的話,那行使與延伸確認用戶重複的權限就會視為動用管理權限,因為這個行駛重複權限的操作對自動確認用戶產生了實際的制約效果。這種認定方法的前設是假定用戶權限級別較低的用戶(比如非管理員、非延伸確認用戶的自動確認用戶)不完全熟悉用戶權限級別較高的用戶所有的權限。Sanmosa In vain 2023年7月20日 (四) 13:50 (UTC)
恕我吐槽,除非你維莫名空降管理員,否則管理員就算被解除管理員也依然會有editsemiprotected和extendedconfirmed此兩權限。既然都空降了,那自然是基金會行動了,根本不會受這個提案影響。--SunAfterRain 2023年7月20日 (四) 13:54 (UTC)
「注意大部分管理員沒有延伸確認用戶組,即其延伸確認保護編輯權是管理員組授予」,這是LuciferianThomas上邊的原話。Sanmosa In vain 2023年7月20日 (四) 14:03 (UTC)
這是WP:XCON當初配置的遺留問題,本來就是bug/錯誤配置(新的管理員如Ericliu1912和Peacearth都會在成為管理員前獲得延確)。顯然不是合理反駁太陽君所述的論點。--西 2023年7月20日 (四) 14:08 (UTC)
我想我可能看錯了一點東西,請容許我先冷靜一下以後再重看。Sanmosa In vain 2023年7月20日 (四) 14:13 (UTC)
延伸確認通過之時,預期所有符合500/90要求的用戶都應該成為延伸確認用戶,管理員也不應排除在外。該flag本來不能手動授予或移除,自然管理員應同樣自動獲得該權,但實際配置之時並無這樣做。延確是應該要像自確一樣如常附於管理員上。--西 2023年7月20日 (四) 14:17 (UTC)
延伸一下YFdyh的論點:擔任管理員的要求並不包含「會寫條目」,而管理員的autopatrol權限是管理員用戶組授予的(管理員不會同時持有巡查豁免、巡、退等用戶組),那麼是否管理員創建不合格條目(動用了autopatrolled權),就變成濫用管理員權限了?莫名其妙啊。--西 2023年7月20日 (四) 11:21 (UTC)
既然閣下會提議摘巡查員的巡查豁免,為何會提出同樣沒有寫條目要求的管理員應保留巡查豁免權,並將建立不當條目視作「濫用管理權限」呢?雖然我當初提案確實沒有指出巡查豁免權(因為不在原先兩個組別內),但上方我也曾提出過如果可以就連autopatrol都摘掉。為何閣下就一概而論全部(包括巡查豁免)都是管理權限,不能摘呢?何來之「可靠效力」呢?不是社群共識所得的東西,何來「效力」?--西 2023年7月20日 (四) 11:32 (UTC)
@LuciferianThomas:你這裏這樣把這個權限單獨摘出來講不合理,因為你當初的提議是把一籃子的權限都給移除掉,我反對的是把一籃子的權限都給移除掉的做法。如果你真要單獨拿出來講的話,那我建議你就此單獨新開提案,而不是在關了那個一籃子提案後單獨將這點抽出來批判我。你這裏既然說要先「判定什麼屬於管理員的角色、什麼屬於管理行動的一部分、什麼應該以申訴而非爭議形式處理」,那你就不要在這裏在牽扯到移除權限的事情,不然討論離題了大家也控制不住。Sanmosa In vain 2023年7月20日 (四) 13:12 (UTC)
閣下的立場是Special:ListGroupRights#sysop全部都視為管理權限,把巡查豁免作為一個例子論證閣下觀點有問題,又不行了?對我的立場而言,「摘權限」是跟「不視作管理操作」是同價的,別給我抓字眼。我表達的是閣下認為管理員現在持有的權限全部都應該視為管理權限的觀點錯誤,為何閣下就一概而論全部(包括巡查豁免)都是管理權限,不能摘呢?問的是為何閣下就不能從閣下的觀念中摘掉「巡查豁免」以至其他沒有管理作用的權限視作「管理權限」的觀點。--西 2023年7月20日 (四) 13:27 (UTC)
那你當初的提議是不是把一籃子的權限都給移除掉?我覺得你應該合理預期其他人會從宏觀的角度來看整件事情。你把這個權限單獨摘出來講的做法屬於從微觀角度來看,我從不同的微觀角度來看的答案跟從宏觀的角度來看的答案是有可能有不同的,所以如果你要知道我就這個微觀角度來看的答案的話,請明示。Sanmosa In vain 2023年7月20日 (四) 13:31 (UTC)
我對於我早前想要摘以及現在不認同認定為管理權限的每一個權限的立場都非常一致:全部都未曾也不該視作管理權限,不會像閣下一個一樣。如果閣下是大一回事小一回事的觀點,那請閣下先審視您自己的觀點為何會不一致和自相矛盾。再者,前面反對我摘權的,一個是覺得只要一般人能做到(以任何方式)的動作就都不是管理操作(管理權限的範圍比我還緊),一個是覺得純粹沒必要動,只有閣下是覺得全部都是管理操作,不應該動。四人中與自己、其他人立場最不一致的仍是閣下。--西 2023年7月20日 (四) 14:03 (UTC)
我之所以說我從不同的微觀角度來看的答案跟從宏觀的角度來看的答案是有可能有不同的,是因為有些時候某幾件事情分開來看各自是某種屬性,但集合在一起來看屬性會變化,我的答案的不一致是性質的變化所導致的,你在性質有變化的情況下仍保持完全一致的觀點會導致你的觀點在部分情況下有效、部分情況下無效。所以我還是這個問題:你到底要不要知道我就這個微觀角度來看的答案?Sanmosa In vain 2023年7月20日 (四) 14:08 (UTC)
我對於自相矛盾的觀點沒有興趣。--西 2023年7月20日 (四) 14:24 (UTC)
就算你根本完全不打算知道我的具體立場意見是甚麽,那請你至少也不要隨意將我的具體立場斷章取義。我相信我已經把我的話説得足夠明確了:這裏的情況分開看與一起看是不同的,不能一概而論。Sanmosa In vain 2023年7月20日 (四) 14:29 (UTC)
(-)反對:為了防止本討論在格式上偏向修訂方,專門設了這個子段。既未能證明造成嚴重的站務處理困擾,我也不明白此舉意義何在。留着無妨,改了也沒有顯著的益處。——WMLO議程表 2023年7月20日 (四) 22:21 (UTC)
現在沒有提案,純屬討論,沒有可以「反對」的事情。摘權的討論早已關閉。--西 2023年7月21日 (五) 00:07 (UTC)
我想了一下,其實為了讓所有管理員正常自動提升為延伸確認用戶而移除僅與延伸確認用戶重複的權限或許是可取的,但其他的我認為需要謹慎地個別考慮。Sanmosa In vain 2023年7月20日 (四) 23:59 (UTC)
管理員擁有延伸確認權並非無法自動提升延伸確認用戶的技術原因,最大可能是管理員用戶組停用了一切自動提升,這是不應該發生的事。再者,如果與延伸確認用戶重複的權限可以「不視作管理權限」(或移除),沒道理自確用戶擁有的權限autoconfirmed、editsemiprotected等權不能同樣辦理。--西 2023年7月21日 (五) 00:11 (UTC)
(1)如果「最大可能是管理員用戶組停用了一切自動提升」的話,那停用自動提升的技術原因(或稱bug)又是甚麽?移除與延伸確認用戶重複的權限能解決停用自動提升的技術問題嗎?如果不能的話,那解決的方法又是甚麽?(2)我相信你還記得我有説過「我想我可能看錯了一點東西,請容許我先冷靜一下以後再重看」這句話,我之後想了一下,好像確實是這樣的道理。這樣的話,請容許我調整我對「實權限」與「虛權限」的具體定義。Sanmosa In vain 2023年7月21日 (五) 00:24 (UTC)
XCON的解決方法最簡單粗暴就是共識後交phab工單。gerrit:712754的修訂(InitialiseSettings.php#L-14979)設定了[ '!', [ APCOND_INGROUPS, 'sysop' ] ],似乎是當初討論時直搬過來的問題(WP:XCON機械人以及管理員都自動擁有此權限,因此不會另外授予該群組權限,但在部署以後獲得管理員權限的用戶可能早已擁有此權限。)。現在導致{{If extendedconfirmed}}和MediaWiki:Group-extendedconfirmed.css等不適用於符合500/90條件的舊管理員的不合理情況。--西 2023年7月21日 (五) 01:18 (UTC)
既然移除僅與延伸確認用戶重複的權限不能解決停用自動提升的技術問題,我建議停用自動提升的技術問題應該另開討論。Sanmosa In vain 2023年7月21日 (五) 01:37 (UTC)
不過既然閣下已經修訂了對「實權」的觀點,不再一刀切將所有「管理員組擁有的權限」都視作「管理用的權限」已經跟其他用戶的觀點更為靠近了,那問題就大概解決了。技術問題本來是想跟摘權一併處理,那就稍後再分案處理。--西 2023年7月21日 (五) 02:03 (UTC)

編輯請求 2023-09-24

  請求已處理——暁月凜奈 (留言) 2023年9月24日 (日) 02:58 (UTC)

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

@暁月凛奈目前管理員人數仍然為{{#expr:{{NUMBEROFADMINS}} - 4}},請改為{{#expr:{{NUMBEROFADMINS}} - 3}}。--132.234.228.109留言2023年9月24日 (日) 04:43 (UTC)
返回專案頁面「管理员/存档5」。