維基百科

維基百科討論:介面管理員/存檔二

< Wikipedia talk:介面管理員
由Jimmy-bot在話題修訂WP:介面管理員上作出的最新留言：1 年前

提議為界面管理員追加若干權限

最新留言：3 年前22則留言8個人參與討論

本主題或以下段落文字，移動自Wikipedia:互助客棧/方針。執行者：Jimmy-bot（留言） 2021年2月22日 (一) 16:14 (UTC)。

種種變動牽扯方面過多且複雜，其影響雖深遠卻現時利益不足。我攜書劍下天山，未料人間不勝寒。
--安憶Talk 2021年2月19日 (五) 08:54 (UTC)

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

本人在近期處理任務的過程中，發現了此用戶組在權限方面上或有一些需要改善的地方（即權限不足）。 本人也是首個非sysop（admin、管理員）的IA（int-admin、界面管理員），所以對IA需要改善的方面更為了解，在對比英維、日維和中維本地的差異後，現擬提出以下改善建議：

為IA用戶組追加：

  • ipblock-exempt（繞過IP封禁、自動封禁和段封禁）
    • 為了使非sysop的IA繞過IP意外封禁（sysop有此權限）
  • suppressredirect（移動頁面時不在原頁面創建重定向）
    • 如此操作，IA在處理的過程中需要此權限（本人設想日後一定會有和本人一樣是非sysop的IA，而他們或許不會兼任回退員）

以下幾點，

  • editprotected（編輯保護級別為「僅允許管理員」的頁面）
  • editsemiprotected（編輯保護級別為「僅允許自動確認用戶」的頁面）
    • 以上兩點有先前討論（當時本人以為無法再為IA組追加權限）
  • delete（刪除頁面）
  • undelete（還原頁面）
  • move（移動頁面）
  • move-subpages（移動頁面及其子頁面）

如果難以產生「全部授權」的共識（這些權限在日維上獲得了通過），根據英維此表，本人還是希望可以將其授權於特定名稱空間，IA至少應對Mediawiki空間下的頁面有着完全的控制權。IA是一個受高度信任的用戶組（英維千餘名sysop中僅有十餘名IA），無需擔心權限被濫用。

    • 日維現有本地例外ウィキペディア日本語版で管理者の権限を持たずにインターフェース管理者の権限を得た場合、全てのページを保護狀態に関係なく編集できるようになり、削除などの機能も使用できるようになります//（如果在日維中沒有管理員權限但有界面管理員權限，則無論保護狀態如何，都可以編輯所有頁面，並且可以使用諸如刪除等功能）；…保護の設定や解除はできず//（無法設置或解除保護）

還有一項或可同時授予模板編輯員的補充權限：

  • editcontentmodel（編輯頁面的內容模型）
    • 如此請求[1][2][3]、此請求及其回復
      • 有關「頁面內容模型」的信息可見於mw:Content_handlers/zh（右框摘要），個人認為其可歸作「界面」，此權限在英日維百的IA用戶組中均沒有，是昨天在群組中討論時提到的

技術人員應該會在本地共識下處理（有先例），望各位酌情參與討論。--安憶Talk 2021年2月18日 (四) 12:13 (UTC)

ipblock-exempt，感覺兩可，需要的人通常已提前申請，技術層面上預防的必要性低。suppressredirect，比較贊成，技術上可能用到。提到的編輯、刪除和移動權限，不反對，但應有方針限制僅出於技術原因的操作。editcontentmodel，不了解需求率。--YFdyh000（留言） 2021年2月18日 (四) 12:29 (UTC)
這些技術上都是可以做到的，無需擔心這點。後端的php里有個數組，要加哪個權限補寫一行就行。--安憶Talk 2021年2月18日 (四) 12:40 (UTC)
先上車後補票，有點觀感不好。不過，我認為除了delete和undelete可能因為與介面管理員職能未必有太大關係且相對地存在討論空間外（畢竟刪除和還原是管理員的主要職能之一，尤其是出於傾斜的情況時職能分配就可能會失衡），其餘幾點我認為均可以接受。尤其是增加suppressredirect以及editprotected，相信有助於解決介管的權限還不及回退員或模板編輯員的離奇情況。--AT 2021年2月18日 (四) 12:39 (UTC)
嗯，主要是用了才知道。現在的IA除了我都是管理員，所以他們才沒體驗到[開玩笑的]；刪除和恢復可以考慮限定一下名稱空間。--安憶Talk 2021年2月18日 (四) 12:44 (UTC)
Mediawiki空間的話，我認為沒有太大問題，畢竟要刪或還原的可能性不高，如果操作上有需要或許也可以附加模板空間，其他空間應該在職能上不太相關吧。--AT 2021年2月18日 (四) 12:48 (UTC)
您可以看下此章節第一段末尾和這個表，我也是這個意思。--安憶Talk 2021年2月18日 (四) 12:54 (UTC)
「刪除和恢復可以考慮限定一下名稱空間」可是從PHP檔案結構中沒有找到對應設定的地方，不確定是否可行。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月18日 (四) 14:21 (UTC)
可以用本地方針來限制，不一定非要在技術層面上做。--安憶Talk 2021年2月18日 (四) 14:25 (UTC)
我認為除了editcontentmodel可討論外，其他與IA關係不大，也不是必須。--百無一用是書生 (☎) 2021年2月19日 (五) 02:21 (UTC)
其他均會用到，這是我在處理任務中實踐總結出來的。--安憶Talk 2021年2月19日 (五) 03:57 (UTC)
@Shizhao：閣下把{{不存檔}}給忽略了  囧rz……-- Sunny00217  2021年2月19日 (五) 03:12 (UTC)
ipblock-exempt和suppressredirect贊成可以加（要加後者的話，Wikipedia:重定向#移動時不留重定向也會需要連帶修改，不過到時候用事實性修訂處理就好）。editsemiprotected應該並非必須，介面管理員應該還是自動確認用戶（如果不是的話，那就一定要追加，不然會影響用戶權益）。editprotected、move和move-subpages贊成可以加。delete和undelete方面，我和AT有差不多的憂慮，但我明確贊成至少可以容許介面管理員在Mediawiki空間下啓用delete和undelete權限。editcontentmodel贊成可以加給介面管理員，不清楚熟悉CSS的模板編輯員有多少（比較少的話，我建議不用加給模板編輯員）。SANMOSA 誓山海而長在，似日月而無休 2021年2月19日 (五) 02:35 (UTC)
不太可能沒有editsemiprotected，如果是監管員自我授權遇到這問題時他們一定有辦法，另外@Sanmosa：為甚麼模板編輯員應該有權限editcontentmodel？-- Sunny00217  2021年2月19日 (五) 03:15 (UTC)
  1. 為什麼IA需要editprotected？IA已經可編輯被保護的mediawiki空間了。編輯其他被保護頁面不是IA的職責範圍。如果是要編輯被保護模板，可以單獨申請模板編輯員權限。
  2. ipblock-exempt與界面編輯沒有任何關係
  3. suppressredirect也與界面編輯無關，如果需要，可以請管理員代勞
  4. editsemiprotected同SANMOSA，即使不是自動確認用戶，也可以授權為確認用戶，因此完全沒有必要
  5. move和move-subpages與界面編輯無關，即使臨時需要，也可以請求管理員幫助
  6. delete和undelete更加與界面編輯無關，即使Mediawiki空間也不是必須delete和undelete，請記住有管理員可以刪除，而且需要通過刪除流程刪除，所以IA根本不需要這個權限
  7. editcontentmodel和界面編輯有微弱關係，但嚴格來說，界面編輯並不需要要editcontentmodel權限--百無一用是書生 (☎) 2021年2月19日 (五) 03:58 (UTC)
    1. 現時情況是不完全能編輯Mediawiki空間；
    2. 用戶組內置的權限和額外用戶組最大的區別就是後者可以被拿掉；按與xx沒有關係的說法，為什麼管理員會有此權限？
    3. 有關，上面已有舉例，而且管理員無法處理*.css/*.js的頁面；
    4. 同2；
    5. 同3；
    6. 這點我只是對比了英維，且同3；
    7. 基於實際需求。
    管理員現在並不是什麼都能做的。並且界面管理員的操作會有即時性、偶發性或緊急性，哪能到時候四處找人，求人不如求己。請以非管理員的角度考慮此提案。--安憶Talk 2021年2月19日 (五) 04:13 (UTC)
    1. 不完全能編輯Mediawiki空間是因為其他原因再次保護了Mediawiki空間造成的。應該解除相應的保護就可以避免這種問題。另外，還有一種可能就是不願許IA編輯某些Mediawiki空間，但我一時想不到這種場景
    2. 我仍然認為這與IA無關，管理員有是因為是管理員，而不是界面管理員
    3. 剛剛測試了，沒有發現你說的問題
    4. 仍然與IA無關，也未見有需要的可能（畢竟連自動確認用戶都不是，實際執行中不可能成為IA，雖然理論上有可能）
    5. 測試了一下，沒發現管理員不能移動
    6. 這個也測試了，沒發現管理員不能刪除
    7. 編輯mediawiki空間有需要用到改變editcontentmodel的地方嗎？
    總體而言，界面管理員，顧名思義就是可以修改界面的管理員，只要能滿足這個權限需求就可以了。就如同模板編輯員，只要能編輯模板就可以了--百無一用是書生 (☎) 2021年2月19日 (五) 07:02 (UTC)
    1. 有現有討論，其中有優缺點對比，缺點還是值得留意的；
    2. 因為是管理員所以就有？好像沒有什麼邏輯性；
    3. 「請管理員代勞」也不是什麼好理由，上面提到了，總不能要干本職工作之前都去申請個其他權限或者臨時到處找人預處理一下；同2；
    4. 這個是按照英維、日維和管理員用戶組現有權限照搬的，不是意外的情況下，確實沒有也行；
    5、6的話，是根據英維那邊的表，再參考英日維的做法而加的幾項權限，他們的管理員用戶組做不到。因為我不是中維管理員，不是十分清楚，如果中維管理員可以做到的話，為了明確二者的關係和安全性，或許我們也應該照着改一下，讓管理員做不到Create、Edit、Move和Restore；
    7的話，在此討論的最上面有說，這是個實際需求；單論Mediawiki空間的話，可能會在引用其他頁面的時候（action=raw這種）用到。總之上面有說如果難以產生「全部授權」的共識，本人還是希望可以將其授權於特定名稱空間，IA至少應對Mediawiki空間下的頁面有着完全的控制權。--安憶Talk 2021年2月19日 (五) 07:34 (UTC)
本討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。

管理員不能對mediawiki名字空間進行管理操作了？

最新留言：3 年前53則留言10個人參與討論

本主題或以下段落文字，移動自Wikipedia:互助客棧/技術。執行者：Jimmy-bot（留言） 2021年4月18日 (日) 08:14 (UTC)。

今天在處理Wikipedia:頁面存廢討論/記錄/2021/03/25#MediaWiki:JQuery-makeCollapsible.js、MediaWiki:JQuery-makeCollapsible.css時才發現管理員不能對mediawiki名字空間進行刪除、移動和保護操作了，之前討論的Wikipedia_talk:介面管理員#提議為界面管理員追加若干權限似乎實現了一部分？--百無一用是書生 (☎) 2021年4月1日 (四) 02:18 (UTC)

自從界面管理員設立之後就不能了。要刪除的頁面是css/js。--安憶Talk 2021年4月1日 (四) 02:26 (UTC)
實際情況是，刪除需要管理員權限，操作css/js頁面需要界面管理員權限。所以要兩個都有才行。--安憶Talk 2021年4月1日 (四) 02:27 (UTC)
是的，不過行政員可以臨時授予自己介管權限來進行相關操作。--AT 2021年4月1日 (四) 09:06 (UTC)
(？)疑問:如果本地有共識，能否修改為「所有mediawiki名字空間的頁面普通管理員都能刪及還原，只是不能編輯」？否則很影響站務處理。而且css/js頁面，現在普通管理員及行政員都能刪，但兩者刪後都不能還原，這種系統問題能修正嗎？--蟲蟲飛♡♡→♡℃※留言 2021年4月2日 (五) 03:02 (UTC)
現在的情況是，管理員對此空間下的一般頁面有着完全的操作權限，而界面管理員只能編輯。對於css/js頁面，中維的界面管理員沒有delete/move等權限，所以實際在進行刪除、移動和還原等操作時還是需要同時任管理員和界面管理員。
前提案中所涉及到的九項新權限，在我看來都是必要的。編輯被保護的頁面、移動（包括移動不留重定向）、刪除和還原給予界面管理員在此空間下的自由，IP封禁豁免使它不受意外封禁的影響。誠然，通過回退員和IP封禁豁免者可以獲得一部分不那麼重要的權限，但它們可以被其他管理員移除，這是和用戶組內置權限的本質區別。
我無法說服持有着管理員權限的諸位。我也想不明白為什麼界面管理員在中維變成了界面編輯員，甚至編輯權限都不完整，在MediaWiki空間下只能編輯非全保護的頁面。--安憶Talk 2021年4月2日 (五) 03:52 (UTC)
確實有必要添加權限。英文維基百科的界面管理員必須先有管理員權限，所以管理員已有的就不必重複。而本站允許單獨申請，現有的權限不完整。
看了下你上次的提案，個人認為沒有必要的是undelete（日文站點也沒這個權限）與ipblock-exempt（需要的話可以另外申請），其他的支持添加。--Lt2818（留言） 2021年4月2日 (五) 04:48 (UTC)
ipblock-exempt最好內置，因為不排除被惡意移除IPBE用戶組的可能，比如有人現在將我從中移除出去，我是沒辦法再編輯的。delete和undelete相輔相成，比如可以在誤刪頁面時即刻復原（MediaWiki空間下的頁面通常高度可見並及時反映），英維是這樣的。至少在MediaWiki空間給一下。--安憶Talk 2021年4月2日 (五) 05:09 (UTC)
要看每個站點的Special:ListGroupRights，英維的undelete屬於管理員。undelete若能限制名字空間的話也不反對。惡意移除用戶組的情況應該從源頭解決，跟惡意封禁沒兩樣。--Lt2818（留言） 2021年4月2日 (五) 05:56 (UTC)
對比了一下群組權限，發現中維和英維的IA組權限竟一模一樣，應該是當年討論時漏掉了。如您所說，對IA來說，中日維的管理員是可選項，而英維是必須基於它。所以我認為照搬一下ja:特別:利用者グループ権限，再根據實際需要追加一項editcontentmodel，以及和move相關的兩項即可。既然undelete在大維基均屬於管理員，中維就不開創這個先例了。--安憶Talk 2021年4月2日 (五) 06:23 (UTC)
補充一下：管理員只能刪除用戶空間的JS/CSS（無法編輯、還原），MediaWiki名字空間的JS/CSS一點權限都沒有。要使前項權限延伸到MediaWiki名字空間估計要改動軟件代碼，會影響全部站點。如此改動雖不會有安全問題（畢竟無權加新代碼），但MediaWiki名字空間中JS/CSS頁的刪除通常伴隨其他界面頁的修改，仍然需要界面管理員相助。--Lt2818（留言） 2021年4月2日 (五) 06:13 (UTC)
管理員可以編輯此空間下的一般頁面吧，比如MediaWiki:Bad_image_list，應該也可以刪除它。--安憶Talk 2021年4月2日 (五) 06:25 (UTC)
原先的表述可能有歧義，已經修改明確。--Lt2818（留言） 2021年4月2日 (五) 06:29 (UTC)
管理員無法編輯css/js頁面是正確的實現，而無法刪除MediaWiki空間下的相關頁面可能也是為了安全考慮，用戶的common.js刪就刪了，全站的不行。所以IA應該有自己的delete權限。
單看這個話題，問題所在是IA「在理論上」可以操作MediaWiki空間下的css/js頁面，但中維里單純的IA還不能delete，得雙持。而根本原因也正是我那個前提案所說的，是權限覆蓋不足，得改。--安憶Talk 2021年4月2日 (五) 06:45 (UTC)
理由很充分，可考慮再次提案。--Lt2818（留言） 2021年4月2日 (五) 06:53 (UTC)

重新提議為界面管理員增加權限

承接以上討論，重提安憶君先前提案。本站允許單獨申請界面管理員，而當前界面管理員的權限對於未兼任管理員者是不完整的。參考日文站點先例，提議為該用戶組增加以下權限：

  • delete（刪除頁面）
  • editcontentmodel（編輯頁面的內容模型）
  • move（移動頁面）
  • move-subpages（移動頁面及其子頁面）
  • suppressredirect（移動頁面時不在原頁面創建重定向）

--Lt2818（留言） 2021年4月2日 (五) 08:29 (UTC)

(－)反對，基金會不會給過的，@Lt2818：別再提這個案了-- Sunny00217  2021年4月2日 (五) 08:58 (UTC)
@Sunny00217：你不妨解釋一下為何日文維基百科的界面管理員有這些權限。--Lt2818（留言） 2021年4月2日 (五) 10:20 (UTC)
目前持有額外權限的he跟ja，皆是合併在IA設立前就有的使用者群組（類似IA層級的權限），與現在您想要授予一些管理員層級權限的情況不同。--Xiplus#Talk 2021年4月2日 (五) 11:07 (UTC)
Sunny00217君的這個說法希望能給出確切來源。界面管理員默認只是管理員的附加用戶組，而本站的情況有所不同。--Lt2818（留言） 2021年4月2日 (五) 11:21 (UTC)
InitialiseSettings.php L9551及L9851，註解有對應的Phab工單編號。--Xiplus#Talk 2021年4月2日 (五) 11:33 (UTC)
@Xiplus：我指的是「基金會不會給過的」這個說法存疑，不是要驗證你的發言。--Lt2818（留言） 2021年4月2日 (五) 11:41 (UTC)
對配置更改的限制#被禁止的更改。--Xiplus#Talk 2021年4月2日 (五) 12:06 (UTC)
這個在之前的提案提到了，當時舉的反例是ja，它有例外。ja之前有interface editor，現在也可以授權普通用戶包含interface editor權限的interface administrator；中維僅可以授權普通用戶interface administrator，而沒有interface editor；其他語言不能授權普通用戶interface administrator，這是關鍵的區別。加權限不行的話，加用戶組可以嗎？加一個interface editor。--安憶Talk 2021年4月2日 (五) 12:21 (UTC)
只要不包含edit*(js|css)權限就可以。--Xiplus#Talk 2021年4月2日 (五) 12:38 (UTC)
單設用戶組當interface administrator的DLC有點兒讓人迷惑…。用戶組叫interface-administrator-extra，然後包含提到的幾項權限，成為IA自動授權interface-administrator-extra？…--安憶Talk 2021年4月2日 (五) 12:46 (UTC)
這有點多此一舉……只能說明他們這個限制是愚蠢的，可以嘗試突破一下。實在不行你再申請個管理員就成。--Lt2818（留言） 2021年4月2日 (五) 12:52 (UTC)
難。並且這是妥協之道，萬一以後也有我這種單持的人呢，既然方針允許，就應該改正這個問題，或者，改變方針。--安憶Talk 2021年4月2日 (五) 13:04 (UTC)
我僅僅是基於Limits to configuration changes闡述事實，至於這麼做好不好，是另一回事。--Xiplus#Talk 2021年4月2日 (五) 12:56 (UTC)
是，您說的是事實。只是要是把我上面說的那個做法提到phab上，他們說不定都能笑出聲  囧rz……--安憶Talk 2021年4月2日 (五) 13:01 (UTC)
he在此限制出來之前就更改，ja則是在此限制出來之後的三個月，在ja之後就沒有了（未確定被拒絕數量）。--Xiplus#Talk 2021年4月2日 (五) 12:43 (UTC)
已確認。事由是某站點欲為界面管理員增加編輯過濾器權限，本站情況與之不同。為減少以類似理由拒絕之可能性，我刪除了提案中「編輯受保護頁面」權限，不便之處需要通過解除相關MediaWiki頁面之保護來解決。如果這樣仍然拒絕，則要請他們改代碼以允許管理員刪除MediaWiki名字空間的JS/CSS頁。--Lt2818（留言） 2021年4月2日 (五) 12:32 (UTC)
問題在於這樣一來，界面管理員就具有了大部分管理員權限，似乎不太妥當。除非界面管理員可以單獨為MediaWiki空間下的css/js頁面或全部MediaWiki空間頁面設置這些權限--百無一用是書生 (☎) 2021年4月2日 (五) 09:42 (UTC)
最可能有爭議的應該是「刪除頁面」權限，其他的爭議會小一點。該權限的必要性在於，現在單獨的管理員和界面管理員都無法刪除MediaWiki名字空間的JS/CSS頁，必須有兩個用戶組才能完成，徒添困擾。由於本站的界面管理員都通過RfA程序產生，受信任程度不亞於管理員，即使用該權限處理存廢討論也無可厚非。--Lt2818（留言） 2021年4月2日 (五) 10:34 (UTC)
日維的界面管理員是從界面編輯員遷移過去的（Merge bellow userrights from interface editor to interface administrator: ipblock-exempt, editprotected, editsemiprotected, editsitejson, delete and suppressredirect rights）然而，我們沒有界面編輯員這一過渡，是直接引入的interface administrator，可它的權限還不及人家被取消的interface editor，甚至在某種角度來看還趕不上我們的模板編輯員，是不是不太合理？中維管理員共64項權限，何來「具有了大部分管理員權限」之說。方針寫道：「…所以界面管理員的可信程度不應亞於管理員，甚至應該更高…」，其實際任免的流程和門檻也和管理員信任案無二，只是分管領域不同，何來「不太妥當」。--安憶Talk 2021年4月2日 (五) 10:53 (UTC)
64這個數值不準確，實際上管理員特有的權限只有31小項，本案提議授予其中4小項；但若把類似權限分類（例如刪除跟反刪除）成大項，則管理員特有刪除、封鎖、保護、過濾器、flow-create-board、markbotedits、move-subpages、editcontentmodel這8大項，而本提案涉及其中4大項（註：涉及不表示完全涵蓋）。--Xiplus#Talk 2021年4月2日 (五) 11:38 (UTC)
64是這裡列出的項目數。您給的工單我看了下，情況不太一樣，或者說是不太適用。he和ja的IA是由interface editor合併進去的，但它們的IA都可以由非管理員用戶來任，而其他的語言（除了中維）不是這樣。所以，相似的中維應該也添加一本地例外。--安憶Talk 2021年4月2日 (五) 11:52 (UTC)
照技術設置限制頁面所載，其實背後邏輯就是要減少可修改「MediaWiki」空間之下及其他指定之「.css/ .js」頁面之人數，降低保安風險。介面管理員能不能完全掌控這些頁面根本不在考慮之列。照這個邏輯再推演下去，就是應該將介面管理員限制成只有現任管理員才能申請，那就邏輯及運作上完全自洽。若然不想有這個修改，那就要承認會有這些限制，並且接納。完。--J.Wong 2021年4月3日 (六) 06:36 (UTC)
改方針也可，因為現在編輯權限也是受限的，這是最簡單的方式。是不是要重新討論下這個。--安憶Talk 2021年4月3日 (六) 06:46 (UTC)
(！)意見：刪除頁面拿掉，其他的可以整合進界面管理員權限。--Googol19980904（留言） 2021年4月3日 (六) 08:28 (UTC)
delete是這次話題的起點。--安憶Talk 2021年4月3日 (六) 10:17 (UTC)
找到一處討論界面管理員缺少權限的頁面：phab:T201052。從根源上檢討該問題，我認為界面管理員機制並未帶來安全性保障的質變，某種形式的變更覆核會好得多。而既然設立了該用戶組，就應使權責相配。如今一項操作依賴於兩項權限，設計者難辭其咎。--Lt2818（留言） 2021年4月3日 (六) 09:38 (UTC)
是沒什麼質變，只是用戶組人數變少了，少到英維一千多管理員只有14個界管。和RfA一樣的流程也沒帶來什麼增益。--安憶Talk 2021年4月3日 (六) 10:11 (UTC)
認為IA有這些責任應是錯誤的期待，除了刪除全站JS/CSS以外，都不是IA的工作，而是管理員的工作，介面管理員是「JS/CSS管理員」，不是「技術管理員」，這可能是源自於初期設立的命名不當，但現在必須糾正。--Xiplus#Talk 2021年4月3日 (六) 10:27 (UTC)
我沒這個誤解。剛剛研究了一下，要讓管理員能刪除全站JS/CSS只需改動此處代碼，而讓界面管理員僅能刪除全站JS/CSS估計要另立權限。--Lt2818（留言） 2021年4月3日 (六) 12:22 (UTC)
此回應是針對前次提議中對於editcontentmodel所列舉的請求，以及AnYiLin認為內容模型可歸作介面，這兩件事。--Xiplus#Talk 2021年4月3日 (六) 12:55 (UTC)
對於究竟能不能併進IA，系統管理員有最終決定權，想這麼提議的人請直接去問系統管理員，我們在這裡討論猜測沒有意義。--Xiplus#Talk 2021年4月3日 (六) 13:29 (UTC)
個人覺得是可以看能不能新增一個權限叫deletejscssjson能刪除那些內容模型的頁面，原本的delete則排除之類的比要求添加delete來的實在。
話說@Lt2818：為甚麼需要加move？貌似不必要。-- Sunny00217  2021年4月5日 (一) 14:21 (UTC)
  1. 需要改軟件代碼，改完後全都站點都適用，就不只是中文維基之事了。
  2. 不是我加的……可以看編輯歷史，我也無意再做更改。--Lt2818（留言） 2021年4月5日 (一) 17:01 (UTC)
    ...ok，看到了，只是@AnYiLin：巡查回退沒有move吧...-- Sunny00217  2021年4月7日 (三) 09:58 (UTC)
    有辦法只應用到單一站點。技術上該怎麼處理，這是系統管理員的事，但能不能這麼做，也是他們決定的，請諮詢他們。--Xiplus#Talk 2021年4月7日 (三) 10:57 (UTC)

早在近三月前，我便問過了編輯類權限。但，編輯類權限都要不來，我對刪除類權限和其他雜七雜八的權限更不抱什麼希望。提出這些討論只是看看在社群共識下能否使系統管理員做出些許改變。--安憶Talk 2021年4月8日 (四) 05:04 (UTC)

調整界面管理員方針之「權限取得」一節

最新留言：3 年前25則留言11個人參與討論

本主題或以下段落文字，移動自Wikipedia:互助客棧/方針。執行者：Jimmy-bot（留言） 2021年4月26日 (一) 08:14 (UTC)。

根據先前討論一和先前討論二，提議向「資格要求」追加一項「需現任管理員」，以達到邏輯和運作上的自洽。--安憶Talk 2021年4月4日 (日) 06:59 (UTC)

所以你自己這個案會怎樣處理？-某人✉ 2021年4月4日 (日) 08:06 (UTC)
是指權限不足？方針改了的話，這個問題就迎刃而解了。後來的人沒問題就行了，我自己可以暫時在需要的時候拜託其他是管理員的人。--安憶Talk 2021年4月4日 (日) 08:22 (UTC)
讓您成為唯一一位例外並不太好; 可是要求您辭職又更過分了。--Temp3600（留言） 2021年4月4日 (日) 18:40 (UTC)
我想這不是一個特別難解決的矛盾，不看這個，就方針本身的變動而言，請問有什麼意見嗎？--安憶Talk 2021年4月5日 (一) 02:30 (UTC)
由於我一向支持將技術組與行政組盡量分拆，我反對您的建議。--Temp3600（留言） 2021年4月10日 (六) 12:36 (UTC)
我認為，界面管理員確實有跛腳的問題，但尚沒有到必須要所有界管都一定要管理員權限的境地。有最好，但沒有的話也不是沒法開展工作。--痛心疾首 2021年4月5日 (一) 04:14 (UTC)
目前介面管理員沒有delete、editcontentmodel、move、move-subpages和suppressredirect等權限，就您的個案來看，這個提案是很實際的。不過對於臨時申請介面管理員的使用者（外站也有可能），這些權限可能不是那麼重要。如果提案通過，介面管理員將永遠不能申請臨時權限。-- 2021年4月5日 (一) 07:15 (UTC)
可以臨時授權管理員，歷史上有過先例，所以在迫切需要的時候，應該也可以臨時授權界管。--安憶Talk 2021年4月5日 (一) 07:23 (UTC)
我相信當初從管理員拆分出介面管理員有一定的道理，如果提案通過，那麼拆分還有什麼意義呢？臨時授權管理員又是另一回事了，因為管理員和介面管理員的業務內容不同，雙重授權必須要從許多方面考量，但是只依申請者的需求來單一授權，手續就不會那麼繁瑣，畢竟臨時授權可能是緊急的，如果從太多方面考量，時間必定會被拖延。這是我的個人意見。-- 2021年4月5日 (一) 17:59 (UTC)
(－)反對提案，不明白「達到邏輯和運作上的自洽」是甚麼意思，根本上介面管理員跟管理員做的事大都有所分別，如果一個人被信任在有權限編輯介面，不代表他/她能解決編輯爭議且能獲得Special:UserGroupRights#sysop中非常多的權限（不止上面列舉的那些）而不濫權。雖然不知道設立這方針時是怎麼想的，但我覺得介管不須管理員權限才能申請也是因為希望兩者是分工合作。--Sun8908 怯就輸一世 2021年4月5日 (一) 12:27 (UTC)
不贊同。理由同痛心疾首和空氣小貓。我認為只要可信任+有技術就可以當介面管理員。目前還沒有到需要先當上管理員來證明可信度的地步。至於權限不足，也不是什麼事情都不能做，而且可以由介面管理員提出編輯請求，讓管理員協助。--dqwyy (talk) 我們終將成為楓音鄉的過客 2021年4月6日 (二) 06:58 (UTC)
我還是覺得直接讓介面管理員擴權就可以。SANMOSA Σουέζ 2021年4月7日 (三) 05:36 (UTC)
@Sanmosa：早在近三月前，我便問過了編輯類權限。但連編輯類權限都要不來，更不要說其他雜七雜八的權限。--安憶Talk 2021年4月8日 (四) 05:08 (UTC)
我認為這是單純因為你使用個人名義請求的緣故。如果有社群共識的話，我估計可能會有所不同。SANMOSA Σουέζ 2021年4月8日 (四) 05:10 (UTC)
我也是這麼認為的，所以才有了之後的幾個提案，但現在看起來還是不太可行。--安憶Talk 2021年4月8日 (四) 05:18 (UTC)
現行條文

介面管理員持有下列權限：

  • editinterface︰修改MediaWiki名字空間頁面。
  • editsitecss︰修改MediaWiki名字空間下之CSS頁面。
  • editsitejs︰修改MediaWiki名字空間下之JS頁面。
  • editsitejson︰修改MediaWiki名字空間下之json頁面。
  • editusercss︰修改用戶名字空間下之CSS頁面。
  • edituserjs︰修改用戶名字空間下之JS頁面。
  • edituserjson︰修改用戶名字空間下之json頁面。
  • oathauth-enable︰可以開啟雙重認證（2FA）。
提議條文

介面管理員持有下列權限：

  • editcontentmodel：編輯頁面的內容模型。
  • editinterface︰修改MediaWiki名字空間頁面。
  • editsitecss︰修改MediaWiki名字空間下之CSS頁面。
  • editsitejs︰修改MediaWiki名字空間下之JS頁面。
  • editsitejson︰修改MediaWiki名字空間下之json頁面。
  • editusercss︰修改用戶名字空間下之CSS頁面。
  • edituserjs︰修改用戶名字空間下之JS頁面。
  • edituserjson︰修改用戶名字空間下之json頁面。
  • move-subpages：可以在移動主頁面時一併移動子頁面（上限100個）。
  • oathauth-enable︰可以開啟雙重認證（2FA）。
  • suppressredirect：可以移動時並不保留重定向。
  • templateeditor：編輯保護級別為「僅允許模板編輯員和管理員」的頁面。
請各位審閱。--悔晚齋（臆語） 2021年4月10日 (六) 14:57 (UTC)
(－)反對新增不是只有管理員擁有的權限，請留意介面管理員是能編輯全站CSS或JavaScript頁面的使用者群組，與編輯模板無關，更何況這兩個使用者群組的授權標準不同，如有需要另行申請即可。 2021年4月10日 (六) 15:11 (UTC)
@悔晚斋： (▲)同上 --痛心疾首 2021年4月12日 (一) 10:08 (UTC)

界面管理員的一些問題

最新留言：3 年前39則留言10個人參與討論

本主題或以下段落文字，移動自Wikipedia:互助客棧/其他。執行者：Jimmy-bot（留言） 2021年6月29日 (二) 08:14 (UTC)。

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

前日，界管U:AnYiLin在未經任何公開討論和通知的情況下，移除了小工具中的JavaScript標準庫（MediaWiki:Gadget-JSL），其後並以G8提刪頁面。本人翻閱了WP:IA，其中並未對持權者行為有明確指導準則。假「所以界面管理員的可信程度不應亞於管理員，甚至應該更高。」，而據WP:ADMIN：「他們看起來值得信任，……某些功能限制從他們身上解除。……唯能實現社群討論所得的共識。」故推論界管行事應有社群共識。當前增、修等一般在VPT有一定討論，但如前文提到的移除操作，仍有瑕疵。鑑於WP:IA「如果被濫用，……，後果將會非常嚴重，風險極高」，本人希望藉此例能完善程序正義，先行拋磚引玉。->>Vocal&Guitar->>留言 2021年6月5日 (六) 12:19 (UTC)

（我的觀點，在技術上，全站的js就相當於維基百科的方針指引，當前我們對方針的修改十分嚴格，在技術上也應有對應措施，至少做到留檔查詢。）。->>Vocal&Guitar->>留言 2021年6月5日 (六) 12:19 (UTC)

我不是很清楚您是否了解相關技術，您所提到的Gadget-JSL.js的作用是為不支持JavaScript 1.6的瀏覽器提供相關支持，但現在不支持JavaScript 1.6的瀏覽器已經不能訪問本站（指使用JS提供的功能），移除無問題。如Jon_(WMF)（對話頁 | 使用者貢獻）一樣，我近期也修正了不少Mediawiki空間和用戶空間的樣式或腳本，是否我在做此類修正之前都要「共識」？這是技術維護，即使需要共識，也是界面管理員或其他了解相關技術的用戶去事後複查，而不是等待事前的、普遍的社群共識。如我在AFD所說：只是按慣例放到AFD讓管理員看到去刪除而已。您的觀點之在技術上也應有對應措施，至少做到留檔查詢，您可以翻閱刪除日誌，移除、刪除理由均會被記錄在冊。當然，增設某小工具肯定是要共識的，但維護和修正並不需要。--安憶Talk 2021年6月5日 (六) 12:50 (UTC)
在未經任何公開討論和通知的情況下上面說過了，這需要的是懂技術的人去覆核，而不是廣泛性共識；移除了，我有一摘要為-deprecated gadget JSL.js請您詳閱，是因「過時而無用」，上面說明過了；JavaScript標準庫，您是不是看這個名字好像比較高大上所以才有此顧慮？；其後以G8提刪頁面，這是正常的CSD流程。既然您貼了「信任論」，我好像也沒濫用權限，就請不要吝嗇您的信任和善意，好像我一改了什麼本站就會爆炸一樣。您要是真特別關注我，可以跟在我後面，看我改一處您就複查一處，而不是提議事事需共識，--安憶Talk 2021年6月5日 (六) 13:14 (UTC)
Lynx不支援js, 但可以訪問本站，不知道理解有沒有錯誤--木瓜不是食物#留言 2021年6月5日 (六) 13:19 (UTC)
訪問本站不一定需要JS，但能訪問本站且支持JS的瀏覽器一定可以支持JS 1.6，是這個邏輯。--安憶Talk 2021年6月5日 (六) 13:32 (UTC)
我從未貼過「信任論」，我認為取得信任最好的方式是遵從程序正義，當然現在沒有這個程序，所以我才拋題討論。
您有充分的理由解釋您的操作我很滿意，我從不懷疑您的出發點。但我希望今後這些解釋的文字能在您操作之前貼出來。正因為懂技術的人是少數，我有足夠理由相信對於最普通的用戶，每一項技術改變（至少是對用戶肉眼可見），他們也有權力知悉會對他們造成哪些影響，並提出相關疑慮。另外我不樂見您刻意區分「懂或不懂技術」。
我再強調一遍，這篇討論目的在於確定程序正義，我對您本人沒有任何意見。如果社群認為您的操作妥當，無程序正義問題，則本人會當即關閉討論。->>Vocal&Guitar->>留言 2021年6月5日 (六) 13:57 (UTC)
您所說的「程序上的」我有回應，增設某小工具肯定是要共識的，但維護和修正並不需要，即使現在沒有成文，但大家都是這樣做的，有人（其實也就數得過來的幾位）有時間和興趣去在事後對維護和修改等複查即可，無需事事進行事前共識，否則只是在浪費社群精力和不必要地拖時間。界面管理員和管理員一樣是信任案，這意味着我現在做的關於界面有關的事是默認可信的，已然較為符合程序正義。信任我，將權限交予我，就應該默認信任我。說回來，一看您就不了解這JSL.js，它現在並沒有發揮任何作用（即使在我移除相關設置前亦然）。外行指導內行說得上是很可怕的一件事，懂的人一看就會知道某個人在做什麼，不懂的人只有一種「感覺、好像」他做了某些爭議行為，所以「懂或不懂技術」是很重要的一點。總之，您滿意就好。--安憶Talk 2021年6月5日 (六) 14:15 (UTC)
補充一下上一段的說法。移除可能有人使用的代碼需要共識（所以引入韓維小工具時欠缺充分討論值得詬病），但移除無用代碼都是直接進行，所以本例沒有問題。
安憶的發言也有可斟酌之處。討論技術問題的人確實有限，但沒有資格限制，一個人懂不懂技術也不是非此即彼。「一看您就不了解」等語句是對他人負面的推定，希望儘量避免。--Lt2818（留言） 2021年6月5日 (六) 18:01 (UTC)
您所提到的議案延續了一月多，期間收集意見、討論、公示、根據後來的意見提出各方案投票、再公示，在程序上應該是沒什麼問題的。此案公示結束後可能是Ohtashinichiro（記不太清了）提出異議，希望使用公示方案外的另一方案，當時我回復的是「公示期間您怎麼不提」，雖然說得直白，但道理是這個道理，時不我待，已經走完了7+7流程。我給的解決途徑是「另案重開以推翻公示結果」，現在我也維持這個意見，因為我的程序還算正義，我很遺憾Ohtashinichiro在上次信任案中以此為由加以反對。如果您也希望使用此案最終公示方案外的方案，請重開再議，結果不是不可以改變，刪除的頁面亦可還原。
一看就是為了引出所以懂或不懂技術是很重要的一點。舉個例子，如果是您移除了此腳本，我看的一定是它的用途、有沒有用和影響範圍等，這些沒問題那我也就沒什麼問題了，而不是看程序或其他什麼東西，據此以一看就對Ohtashinichiro做了一個合理推測。您第二段前半段可以算作經典老問題之「什麼是共識」，所有人都可以提意見這不假，但意見總要有一些取捨，各位的關注點會根據「懂或不懂」將有所不同。--安憶Talk 2021年6月6日 (日) 02:15 (UTC)
我也可以說「一看您就沒滿三十歲」，然後傳授一些人生經驗。但這顯然會引起反感，所以不妨換位思考一下。
「懂或不懂」的另一個重點在於推定，對他人做揣測總歸不合適，真的不懂也可以學。曾有多人以「專業不同」為由勸退我做某事，但真要論起專業程度，發言者不一定及得上我，此事可供參考。--Lt2818（留言） 2021年6月6日 (日) 04:31 (UTC)
如果您說的有道理、說的是對的，我不介意您以何種方式和語氣表達。我一看的前提是根據已經發生的事實進行推定，而您的意思好像我只是在憑空揣測。您要明白，我只能看到對方的外顯行為和特質，不會知道對方的心裡所想和其他特質，若不說亦不表現，我便不知。
真的不懂也可以學的說法總是對的，但那是馬後炮，應該學好了再來，沒多少人關心過程，大都只看結果。說起來，您近幾個月批評我表達方式多次了，討論到最後總是能說上幾句我的表達方式、語氣等有問題，說我喜歡反問會讓對方反感，說我不用敬語會讓對方反感，這次好一點，沒在意語氣，只是認為我在憑空揣測。這些是真的嗎？可能部分是，我向來說得比較直截了當。但從結果的角度來看，我做的好像也沒什麼問題。您正做着好為人師的行為，請您自重。…論起專業程度，發言者不一定及得上我，或許是真的，但也可能是達克效應。--安憶Talk 2021年6月6日 (日) 05:11 (UTC)
「好為人師」我不否認，我自己也歡迎別人對我如此，有道理的批評求之不得（當然貴用戶組對我的評頭論足多半不是這一類）。--Lt2818（留言） 2021年6月6日 (日) 05:17 (UTC)
沒道理可講就開始轉移焦點到WMC了嗎，它和我現在做的行為可以說沒有一點聯繫吧，我們還是不要跑偏為好。--安憶Talk 2021年6月6日 (日) 05:22 (UTC)
我在討論過程，而您始終在強調結果。「維護和修正並不需要共識」我持保留意見（限於處理影響到正常使用的bug），但顯然移除不在其中。我也好為人師一把，這件事情您在操作之前去VPT寫上一句「我要移除小工具里的XXX因為XXX」就結束了，這不會浪費社群任何精力，也不會有我這麼多的p話，這麼做對您取得社群信任幫助應該更大。->>Vocal&Guitar->>留言 2021年6月7日 (一) 04:15 (UTC)
另外雖然無關討論，特意貼出這個真的挺有意思[4]，有權者希望得到信任，卻又不想給出民主、平等、公正、透明，充分展現人類醜陋的一面，這才是社群的本質，我們要一起學習。->>Vocal&Guitar->>留言 2021年6月7日 (一) 04:15 (UTC)
  • 技術問題應盡可能尊重技術組的內部決定。我上次看過社群決議提上phab後，被整個退回，浪費了數個月討論精力的事情。--Temp3600（留言） 2021年6月5日 (六) 18:08 (UTC)
    • 您講的好像與討論無關。->>Vocal&Guitar->>留言 2021年6月7日 (一) 04:15 (UTC)
      • 意思就是技術組的制衡應依賴內部監察，互助客棧盡可能不要干涉他們的決策。--Temp3600（留言） 2021年6月7日 (一) 10:26 (UTC)
        • 我從上至下都未提到過「干涉決策」，我只是希望決策公開，並且這些公開不應是簡單的在摘要里打幾個單詞，而是應當做成一個帶有一定說明的changelog。另外我也不認為中文維基存在任何「內部監察」。->>Vocal&Guitar->>留言 2021年6月7日 (一) 13:09 (UTC)
          • 我認為changelog 是不必要的。BAG等其他技術組也不會提供changelog.正如管理員也不會交代封禁時長的理據及為AFD寫判詞。--Temp3600（留言） 2021年6月7日 (一) 14:53 (UTC)
            • 機器人怎麼玩不會影響其他用戶，這與全站js影響所有用戶根本是兩個問題，不寫理據本身就是異常情況，您卻認為這是合理的，我也算是明白為什麼有些管理員能如此蹦躂。->>Vocal&Guitar->>留言 2021年6月7日 (一) 23:08 (UTC)
                • 我當然認為在理想狀況中，管理員應該為AFD寫判詞，這也是我在RFA常問的考題之一；然而中文維基的人手不足，如果強行要求管理員為每個決定寫報告，站務處理將停擺。維基一向的做法，是如果您發現管理員犯錯，就可以在討論頁等展開討論。屆時管理員將有責任詳細解釋決定的理據。--Temp3600（留言） 2021年6月8日 (二) 06:37 (UTC)
              • 請勿試圖混淆視聽。「沒寫」和「寫了您沒看懂」完全是兩個概念。我用英語寫的「過時」，並以G8提刪相關頁面，和此討論涉及的相關已被刪除的頁面的中文摘要「G8，過時而無用的小工具」，二者可以說是相差無幾，是一個意思。我的摘要常常言簡意賅，比如「過時、per request」。雖然正義地說不應該對立「懂和不懂」的人，但這點的確十分重要，上面也有提到，至少可以不用單方面地花費時間解釋。您有疑問，上面也用數百字為您解釋了何謂「過時」。
              • 實質性進展是「changelog」這一提議，有價值，但歷史頁面（action=history）加上其中的編輯摘要不正實現了此提議。和速刪、封禁等一樣，以簡短的說明使了解相關規則或概念的人理解，這就夠了，何須長篇大論。明面上的區別就是，前者沒有Special:xx日誌（所以都放在歷史頁面），而後者有。
              • 希望公開，也有價值，但好像本案中也沒東西隱藏？沒有「編輯摘要被移除」，沒有版本刪除，也沒有監督。上面您說我「展示人性醜陋的一面」，您應該知道管理員處理申訴，部分階段是有隱私政策的（比如unblock-zh），沒辦法公開，做不到完全透明，二者不可相提並論。
              • 機器人會影響其他用戶，要不然也不會有提議封禁IAbot，而本案涉及的JS亦不會影響所有用戶（甚至可以說，不會影響任一用戶）。--安憶Talk 2021年6月8日 (二) 01:50 (UTC)
                • 您混淆視聽能力才是一流，我在回復Temp3600的不寫AFD理據，您要拉到您身上，我在上面回復您的話您卻視而不見。->>Vocal&Guitar->>留言 2021年6月8日 (二) 12:18 (UTC)
                  我上面回復的可是指昨天12:15的那兩段？那兩段回了，在今天09:50四段中的第一三段，我再拆開說說。我在討論過程，而您始終在強調結果，我比較現實，認為即使過程再好結果不如人意也沒什麼用，是用來回真的不懂也可以學的，和您沒什麼關係；下一句是您的意見，就不說什麼了，我的意見最開始說過了；去VPT寫上一句，這和我在編輯摘要寫有什麼顯著差異嗎？結合討論，要是真弄什麼changelog，以後是不是改一處就得特意跑到某頁面寫上詳細的原因過程方案結果，這有些不現實；下一段在上面第三段回過了，情境不同，不能生搬硬套。您最開始的期待是在技術上也應有對應措施，至少做到留檔查詢，後發展成changelog，我在四段中的第二段回復過了，沒有什麼對您視而不見的。--安憶Talk 2021年6月8日 (二) 14:29 (UTC)
      • (＋)支持User:Temp3600的概念。-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2021年6月8日 (二) 03:16 (UTC)
  • 其他語言維基百科是否有前例可供參考或遵循？—— Eric Liu 創造は生命（留言．留名．學生會） 2021年6月7日 (一) 00:41 (UTC)
  • 我不清楚為何你那麼執著於MediaWiki:Gadget-JSL.js，我只好給閣下做個逐行分析，  吐槽客棧容量會爆炸也許是因為維基人習慣硬要找碴的關係，其他維基人被逼迫一定要極端極端極端極端極端極端極端極端極端詳細詳細詳細詳細詳細詳細詳細詳細詳細詳細詳細詳細詳細詳細詳細詳細詳細詳細詳細詳細詳細詳細詳細詳細詳細詳細詳細詳細詳細說明導致的
  • 可以再補充一點（這個本來是我為了方針版的封禁理論而寫的）：社群的角色在於設立整體的指導性原則：例如在封禁方針上，明定那些行為可以被封禁；設立不同的用戶組，並分配它們的角色等。而日常操作本身則不應該通過社群討論去控制，例如具體封禁案的時長，某頁面是否應通過巡查等。如果發現了錯誤操作，社群可以檢討規則本身，或者主事者是否適合留在崗位，但是不應該逐個行為拿出來討論，給別人下指導棋（設立原則性的判例當然沒有問題）。用人不疑，疑人不用。--Temp3600（留言） 2021年6月8日 (二) 07:07 (UTC)
    • 我在special:diff/65949068已經講了，現在就在討論程序，您反覆抓不到討論核心，煩請不用繼續參與了。->>Vocal&Guitar->>留言 2021年6月8日 (二) 12:21 (UTC)
      • 那我只好再回覆您，您所指的changelog是不必要的。我們不為介管的具體行動設立程序，不是因為我們都不懂得寫方針，而是因為這些條款會妨礙介管的工作，而對社群的幫助卻不大。我們經權衡之下，不設立明文的條款，而僅要求界管在面對質疑時必須有能力解釋自己的行動。--Temp3600（留言） 2021年6月8日 (二) 13:39 (UTC)

與本案相關的現行規則

  • 與討論提出者所述不一致的是，現行規則——保護方針——對編輯受保護頁面尤其是mediawiki名字空間下的頁面有以下明確的限制：
  • 拋磚引玉，供討論雙方參考。--Antigng（留言） 2021年6月9日 (三) 13:52 (UTC)
    • 界面管理員（不限於AnYiLin，包括設立IA之前的MW操作）的操作是否極其謹慎我無法評估，但我樂意相信所有IA都充分理解後果。問題在於「確保相應問題已經在討論頁提出」，隨意翻了幾個MWtalk，除了編輯請求或VPT討論外，幾乎沒有見過任何一位管理員在操作前有過主動的公示或備案。簡而言之這一條從始至終是否被執行過？或者特權意識足以使此條不適用於管理員？。->>Vocal&Guitar->>留言 2021年6月14日 (一) 03:16 (UTC)
本討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。

下放移動主頁面時一併移動子頁面權限

最新留言：3 年前25則留言8個人參與討論

本主題或以下段落文字，移動自Wikipedia:互助客棧/方針。執行者：Jimmy-bot（留言） 2021年10月13日 (三) 16:14 (UTC)。

我在上方#提議設立維護員權限的討論中提到可以下放move-subpages權限予巡查員、回退員等用戶，現在我會提出具體提案，內容如下：

  • 權限內容：移動主頁面時一併移動最多100個子頁面
  • 下放對象：巡查員、回退員、介面管理員
  • 下放原因：方便回退員更有效率地回退涉及子頁面的移動爭議及破壞，方便巡查員、模板編輯員、介面管理員於為存在子頁面的頁面更名時更有效率地完成更名操作

就以上內容，現提出新增以下方針：

Wikipedia:介面管理員
Help:頁面重命名（設為章節方針）
Wikipedia:新頁面巡查、Wikipedia:回退功能、Wikipedia:模板編輯員

以上。可分別討論巡查員、回退員、模板編輯員、介面管理員是否適合擁有此權限。Sanmosa Outdia 2021年9月25日 (六) 03:31 (UTC)

(＝)中立，但建議給有suppressredirect的。--安憶Talk 2021年9月25日 (六) 05:15 (UTC)
註：有suppressredirect權限者包括管理員（本已有move-subpages權限）、巡查員、回退員。Sanmosa Outdia 2021年9月25日 (六) 08:01 (UTC)
看了看後續討論，感覺這個權限比較適合用來批量移動Mediawiki:xxx/* User:xxx/*，而不是用在和條目有密切關係的空間。--安憶Talk 2021年9月26日 (日) 16:19 (UTC)
(＋)傾向支持：有時候移動一個頁面還要檢查一大堆子頁面真的很痛苦。—— Eric Liu 創造は生命（留言．留名．學生會） 2021年9月25日 (六) 12:53 (UTC)
由於本功能的問題，使用本功能仍然要檢查一大堆子頁面，因此並沒有方便許多。--Xiplus#Talk 2021年10月4日 (一) 03:31 (UTC)
先想想有什麼具體情況會用到這個權限，才會知道對不同使用者群組的是否真的有幫助，找找曾經動用過本權限的具體案例對討論應相當有幫助。例如提案中「回退涉及子頁面的移動破壞」，破壞者通常沒有移動子頁面權限，我移動破壞還給你乖乖按著子頁面結構移動？當然是給你亂移動啊，因此「回退涉及子頁面的移動破壞」根本不切實際。--Xiplus#Talk 2021年9月26日 (日) 01:16 (UTC)
@Xiplus：或許我更正一下字眼：「移動爭議及破壞」。我不排除有LTA真的會按著子頁面結構移動，但考慮到更多情況下是編輯爭議所引發的移動戰，參與移動戰的用戶自然會按著子頁面結構移動，因此為回退移動戰，有必要授予此權限予回退員。Sanmosa Outdia 2021年9月26日 (日) 01:25 (UTC)
不反對您的說法啦，但無法說服我...移動子頁面的功能其實限制多，所以很難用，只有簡單的情況我才會去用它，不然都是一個一個移動比較穩當，所以我覺得很難用來處理移動戰。退一步來說就算能夠處理，回退員沒有足夠的權力來制止移動戰，只有管理員才有（即保護），回退員使用此權限也只是參與移動戰而已，而不是處理移動戰。--Xiplus#Talk 2021年9月26日 (日) 12:28 (UTC)
容許我舉之前的一個解除權限申請的案例：Antigng的提請理由是「在沒有附上編輯摘要的情況下回退爭議性編輯，有違回退方針對這種回退僅限於明顯非建設性編輯的限定」，我當時給的意見是「恢復編輯戰發生前的最後一個穩定版本是標準的編輯戰處理程序，基本上就是等管理員來保護而已」，結案的管理員Shizhao在我的意見的基礎上否決了除權申請。我認為只要回退員盡其所能恢復編輯戰發生前的最後一個穩定版本，那就已經算是某程度上的「處理」了，就算不是「處理」，也肯定是協助處理。Sanmosa Outdia 2021年9月26日 (日) 14:26 (UTC)
不同意，Wikipedia:保護方針#使用和處理編輯請求：「若頁面出現編輯爭議需要全保護，管理員可以在執行保護之後，由保護的管理員本人將頁面回退到爭議發生前的較早版本」，僅有執行保護的管理員本身可以決定是否要回退，若執行保護的管理員決定不回退，其他管理員也沒有權力回退，更不用說保護前回退員的回退行為，認定為處理編輯戰完全不正確。--Xiplus#Talk 2021年9月26日 (日) 15:23 (UTC)
劃綫：「執行保護之後」。如果回退員在管理員施行保護前已經恢復編輯戰發生前的最後一個穩定版本，那管理員自然在施行保護後不會進行回退，這可以算是為管理員省工夫，因此應該被認定為「協助處理」。Sanmosa Outdia 2021年9月29日 (三) 05:51 (UTC)
回退員不能保證在封禁/保護前是否會被再次回退，除非破壞內容相當嚴重（需要OS之類的），否則回退員不應堅持持續進行「反破壞戰」，僅沖刷頁面歷史而無明顯益處，使用該權限對大量頁面進行「反破壞戰」我更要反對了。--Xiplus#Talk 2021年9月29日 (三) 08:45 (UTC)
剛剛試了一下。大家應該都知道目標頁面存在時是無法移動過去的，管理員在移動介面會有一個額外選項是「移動同時刪除目標頁面」，但在移動子頁面時，就算勾了這個選項，只要某個子頁面目標頁面存在，該子頁面的移動會在沒有任何提示的情況下失敗，而其他頁面會移動成功，造成部分頁面未移動而分隔兩地，就算回退員發現該情況，也沒有刪除權限來修復，只會讓情況變得更糟。--Xiplus#Talk 2021年9月26日 (日) 12:45 (UTC)
@Xiplus：理論上可以通過把目標頁面臨時移開來解決（回退員有suppressredirect權限）。不知道能不能跟PHAB提議一下在使用移動主頁面時一併移動子頁面權限時，如果某個子頁面的目標頁面存在而導致移動失敗，系統能給個失敗提示。Sanmosa Outdia 2021年9月26日 (日) 14:26 (UTC)
我自己是反對這樣的操作，就算回退員移動開頁面，仍然需要管理員來執行刪除，回退員搶先操作並沒有減輕管理員的工作量，反而將頁面移動到不相干的名稱，讓刪除日誌保存在其他名稱之下，變成一個缺點。雖然問題很小，但我仍然認為這是對suppressredirect的濫用。--Xiplus#Talk 2021年9月26日 (日) 15:31 (UTC)
這個要直接上報phab了吧？-- Sunny00217  2021年10月5日 (二) 14:56 (UTC)
另外，也考慮到回退員有suppressredirect權限，可以協助處理移動請求（巡查員同），因此授予此權限予回退員亦可令回退員在協助處理移動請求上更為便利（我預想到的情況是{{Infobox road2}}）。Sanmosa Outdia 2021年9月26日 (日) 01:28 (UTC)
至少我能確定模板編輯員不會用到這個權限，如果要移動受模板保護的模板，必須待社群有共識才能移動，那麼由管理員執行就夠了，反正移動的積壓也不嚴重，更不用說同時移動子頁面。就需求來說，模板編輯員應該比較需要轉換內容模型的權限，畢竟光是測試CSS就要從模板移動到使用者頁面（我不相信CSS沙盒），太累了。 2021年9月28日 (二) 12:33 (UTC)
那可以把模板編輯員排除掉。Sanmosa Outdia 2021年9月29日 (三) 05:51 (UTC)
已去除，不存檔至Wikipedia talk:模板編輯員。 2021年9月29日 (三) 14:37 (UTC)
應該正面表列「可以使用的情況」，這才能做為支持該提案成立的理由，「為存在子頁面的頁面更名時更有效率地完成更名操作」是對於該功能的描述而不是下放權限的理由。--Xiplus#Talk 2021年10月4日 (一) 03:37 (UTC)

再提重組用戶權限組

最新留言：1 年前29則留言10個人參與討論

本主題或以下段落文字，移動自Wikipedia:互助客棧/方針。執行者：Jimmy-bot（留言） 2023年7月28日 (五) 16:14 (UTC)。

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

  • 降低自動確認用戶的門檻
  • 巡查員與回退員合併為巡退員
  • 設立高級巡退員以查看私密過濾器
  • 給界面管理員授予編輯被保護頁面的權限
  • 與基金會協商重新引入用戶查核員--Firedoge2023（留言） 2023年7月13日 (四) 14:24 (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)

修訂WP:介面管理員

最新留言：1 年前67則留言13個人參與討論

本主題或以下段落文字，移動自Wikipedia:互助客棧/方針。執行者：Jimmy-bot（留言） 2023年11月9日 (四) 16:14 (UTC)。

短期權限申請頁面

權限取得與喪失：

現行條文

用戶如需申請短期權限，則可至Wikipedia:申請成為介面管理員/臨時申請。

提議條文

用戶如需申請短期權限，則可至Wikipedia:互助客棧/其他申請。

這個頁面至今沒人建立，大概也不會有人注意，也不會有人用。--桐生ここ★[討論] 2023年10月9日 (一) 02:54 (UTC)

若行政員可以授權，那應該是去行政員布告板。—— Eric Liu 創造は生命（留言・留名・學生會） 2023年10月9日 (一) 06:28 (UTC)
不關事但為什麼行政員有權自己授予自己權限？--某人✉ 2023年10月9日 (一) 07:19 (UTC)
跟Steward可以授予自己本地CU權的原因相同。--路西法人 2023年10月9日 (一) 10:48 (UTC)
行政員既然可以臨時授權自己介管權限，那麼改為自動賦權也不過份吧？--AT 2023年10月9日 (一) 17:59 (UTC)
這就是另外一個提案了。--桐生ここ★[討論] 2023年10月10日 (二) 01:43 (UTC)
(－)強烈反對行政員無限擴權，2018年落日條款我不反對，但任何新權限都應該先得到社群批準。最重要的"They are bound by policy and consensus to only grant administrator or bureaucrat access when doing so reflects the wishes of the community"這句在中維硬生生直接沒了。可以未經社群批準就授予自己臨時權限我都已經覺得過分了--某人✉ 2023年10月10日 (二) 02:29 (UTC)
其實沒有什麼過份。介面管理員權限是由管理員權限之中分拆出去；而由行政員賦權。如果行政員都不能自我賦權卻可以賦權他人，豈非怪哉？--J.Wong 2023年10月14日 (六) 11:42 (UTC)
>介面管理員權限是由管理員權限之中分拆出去
沒錯，正因如此2018年前的管理員簡易投票上任的落日條款我不反對
---
>如果行政員都不能自我賦權卻可以賦權他人，豈非怪哉？
非常錯誤的觀念：行政員也不可以自己「賦權他人」，行政員是執行社群的共識，根據社群的授權而賦權他人。真正的問題是「其他用戶都需要社群同意而行政員卻不用，豈非怪哉？」得到社群授權後是「自我賦權」還是他人賦權都沒有問題--某人✉ 2023年10月14日 (六) 12:34 (UTC)
這是理論VS實際；理論上閣下所言當然沒錯；但實際授權者確實是行政員。
如果要論是否經過社群授權，自我授權這件事，本身是獲得社群授權，所以過份之處在？--J.Wong 2023年10月15日 (日) 05:47 (UTC)
( π )題外話：如果不懂JS/CSS的情況，自我授權的意義何在？--桐生ここ★[討論] 2023年10月15日 (日) 05:57 (UTC)
例如在顯然而見之場合或社群請求下協助刪除或移動JS/CSS頁面？--J.Wong 2023年10月15日 (日) 06:19 (UTC)
社群授權行政員的是執行社群的共識，社群從未授權行政員未經許可下自行賦權其他權限-某人✉ 2023年10月17日 (二) 04:36 (UTC)
不明所以然。怎麼說到行政員現在就不經社群共識般到處亂授權？--J.Wong 2023年10月17日 (二) 05:53 (UTC)
你確定我們on the same page? 在討論同一話題？--J.Wong 2023年10月17日 (二) 05:55 (UTC)
如果在說行政員自己授權自己一事，正如上面在下所說，此事是經過討論，社群共識，反覆確認才成行。從來都不是「未經授權下自行賦權其他權限」。而現在大家只是在想，有些行政員既然確實在長期需要，與其反覆除權授權，讓他們長期持權而已。怎麼就去到閣下所言那麼嚴重？--J.Wong 2023年10月17日 (二) 06:03 (UTC)
未經投票就自動長期持有權限不正正就是「不經社群共識」？--某人✉ 2023年10月20日 (五) 16:41 (UTC)
所以現在不就是在討論？在凝聚新共識？怎麼又變成「不經社群共識」？
這是循環嗎？所以連討論及提出都不可以嗎？連提出都已經是「不經社群共識」嗎？--J.Wong 2023年10月22日 (日) 03:18 (UTC)
還是閣下在哪裡見到有行政員違反相關規定？這是另一個議題。--J.Wong 2023年10月22日 (日) 03:22 (UTC)
怎麼好像越講越模糊了。你當然可以提出，但你提出的這個概念立意就是「行政員可不經社群投票的共識直接上任介管」，有沒有說錯？我沒有超譯吧？--某人✉ 2023年10月22日 (日) 07:46 (UTC)
錯，本身行政員已經是兼任介面管理員，而此乃社群共識。而目前只是討論是否修改如何兼任而已。--J.Wong 2023年10月23日 (一) 04:53 (UTC)
就算沒有社群共識，行政員既能授予自己界管權限，自然亦可引用IAR無視妨礙合理改進和維護維基百科的規則處理站務積壓，而一直以來未有人質疑，自然也存在沉默共識（英語：Wikipedia:Silence and consensus）。更何況實際情況是經過討論，有社群共識的操作？--路西法人 2023年10月17日 (二) 06:14 (UTC)
基於安全等因素，我認為維持目前「有需要時臨時自我授權」的辦法即可。—— Eric Liu 創造は生命（留言・留名・學生會） 2023年10月10日 (二) 09:47 (UTC)
同Eric Liu，界管技術能力很重要，自我授權應該是出於必要，以及對自身技術能力有自信的情況下才授權。--桐生ここ★[討論] 2023年10月10日 (二) 11:27 (UTC)
其實AT「自動賦權」是什麼意思？--J.Wong 2023年10月14日 (六) 11:38 (UTC)
就是行政員自動長期持有介管權限的意思。--AT 2023年10月14日 (六) 12:12 (UTC)
( π )題外話：即使監管員技術上可以授權自己在任何一個項目的管理員權限，也沒有任何一個監管員直接自我授權成為中維長期的管理員，只會出於必要情況下自我授權。--桐生ここ★[討論] 2023年10月15日 (日) 06:42 (UTC)
嘛，兩者有些分別；「社群是否已經授權」以及「該用戶是否有長期參與某專案」。本地行政員是經過社群授權可以自我授權，亦是中文維基百科長期參與者，並非僅因某一任務才突然出現。AT君這個提議，如果行政員自己本身懂JS/CSS，且有長期維護需要，個人覺得長期持有亦無可厚非。至於很像在下這種沒有長期持有需要，只有偶然需要，為防誤操作，就繼續目前安排即可。能當上行政員的，沒道理這種判斷也不能作出。個人意見。--J.Wong 2023年10月15日 (日) 10:44 (UTC)
我對於行政員自己認為有維護需要而自我長期授權沒有意見，實際上像對於Shizhao等長期維護JS/CSS或者技術力比較好的人我認為早就該長期賦權了，我不太贊同的是不管他是否需要，直接給所有行政員賦權。( π )題外話：另外社群需要明白，界面管理員的重要性不亞於監督員，因為JS會被執行，影響到的是所有人，包括純讀者，這比監督員更重要。--桐生ここ★[討論] 2023年10月17日 (二) 14:47 (UTC)
確實是有其重要之處，否則亦不會採取目前相關之安排。
如果大家都同意其實行政員確實有需要時，是可以長期持有權限，那在下稍後提案修訂相關條文。--J.Wong 2023年10月22日 (日) 03:32 (UTC)
上面也不是都同意吧，三日簡單投票和IAR應該已經足夠了。--桐生ここ★[討論] 2023年10月22日 (日) 03:38 (UTC)
所以IAR的部分是什麼？人事任命不應該有恆常IAR出現。--J.Wong 2023年10月23日 (一) 04:55 (UTC)
額，我很明顯不同意？--某人✉ 2023年10月22日 (日) 07:47 (UTC)
不如閣下先把方針及相關立案討論讀一讀再回來討論？--J.Wong 2023年10月23日 (一) 04:56 (UTC)
於2023年10月20日 (五) 09:27 (UTC)分拆討論，以免離題。Sanmosa Ινα κραζω σοι 2023年10月20日 (五) 09:27 (UTC)
若有人打算正式提案，是可以拆分新話題以為引言，但現在看起來明顯還沒有（甚至提案本身有沒有初步共識都存疑），而且相關討論在經過其他人排版以後實際上也不影響原提案公示，所以應當不需要急著拆分。若真的覺得某些發言太過離題，也可以考慮比照前例先折疊起來，到原提案通過以後再恢復。—— Eric Liu 創造は生命（留言・留名・學生會） 2023年10月20日 (五) 17:36 (UTC)
反對這個判斷，這不是影不影響原提案公示的問題，那些留言基本上就是佔用原話題討論無關事項，不拆出來會使其他看到討論串的人混肴。Sanmosa Ινα κραζω σοι 2023年10月21日 (六) 03:15 (UTC)
我認為這是「為拆而拆」。終歸是藉機討論普遍的介面管理員授權問題罷了，怎麼能說是完全無關呢？我不能同意這一見解。反正再怎麼說，我們把話擺在這裡以後，別人也就肯定不至於混淆了。—— Eric Liu 創造は生命（留言・留名・學生會） 2023年10月21日 (六) 15:00 (UTC)
今年6月時有關追廢DYK的爭議的討論也是你說的這個情況，足見這「藉機」本來就不該做，不然以後大家都可以這樣「藉機」使討論失焦了。Sanmosa Ινα κραζω σοι 2023年10月22日 (日) 00:58 (UTC)
離題討論確實不好。不過，目前兩個議題都與介面管理員授權相關。
另外，亦已經到接近提修訂案地步，在不影響原提案公示程序下，不建議將討論分拆，以免影響理解。--J.Wong 2023年10月22日 (日) 03:35 (UTC)

( π )題外話：一個疑問，界管的危險性很高甚至可以用來奪取監督員的帳戶，但為什麼界管的賦權流程卻沒有監督員的要求嚴格？桐生ここ★[討論] 2023年10月22日 (日) 07:20 (UTC)

你詳細説一下介面管理員在技術上可以如何奪取監督員的帳戶？這我以前沒聽過，但如果真有此事，那就不得不慎重考慮了。Sanmosa Ινα κραζω σοι 2023年10月22日 (日) 08:44 (UTC)
@Sanmosa：界管有直接編輯全站JS的權限，那麼都不需要XSS，直接就可以植入惡意代碼，然後盜取監督員Cookie，然後重放攻擊。或許MediaWiki有使用防範措施防止JS獲取cookie及重放，但是惡意JS也可以操控監督員賬戶執行一些非法的監督操作，就像Twinkle可以操控您的賬戶執行提報掛板回退一樣。不僅是對於監督員，還有行政員、管理員甚至訪問中維的監管員，以及在座的各位所有人。--桐生ここ★[討論] 2023年10月22日 (日) 10:02 (UTC)
能夠編輯全站JS，在技術上已經是站長了。社群目前是信任界面管理員不會做壞事，就像信任監督員不會泄露機密，信任行政員不會亂授權一樣，只是不能明白為什麼界管的要求低於監督員。
再來一個( π )題外話，我建議各位高級權限持有者不要調用站外JS及其他用戶空間下的JS，僅使用自己用戶空間下的JS。--桐生ここ★[討論] 2023年10月22日 (日) 10:11 (UTC)
那我建議剝奪行政員授予他人介面管理權的權限。Sanmosa Ινα κραζω σοι 2023年10月22日 (日) 12:28 (UTC)
這就離大譜了。—— Eric Liu 創造は生命（留言・留名・學生會） 2023年10月22日 (日) 17:44 (UTC)
那難道桐生說的話沒道理嗎？Sanmosa Ινα κραζω σοι 2023年10月23日 (一) 00:18 (UTC)
個人覺得這個與上面AT君提議可以一併討論。
首先，在下技術水平未到這麼高，未能判斷桐生君所言是否屬實。Sanmosa君就似乎有此水平？或者也請其他技術帝路過點評一二。但姑且判斷為屬實。任何介面管理員都有這個能力。但這是不是都有個前提？首先要有界面管理員權限？所以現在大家都突然不信任任命流程起上來？目前上任界面管理員最少要經歷一次管理員投票。而目前管理人員投票已經變成一年兩度，本站大事，萬眾聚焦。所以程度還不夠？所以行政員不能相信？所以為什麼監管員就能相信？目前行政員都是經歷貴站至少兩次表決，才選出來欸。--J.Wong 2023年10月23日 (一) 04:10 (UTC)
我剛剛在電腦上看了，MediaWiki是有設置HttpOnly的，所以js讀取不到會話狀態的關鍵Cookie，只不過惡意JS仍然可能控制監督員帳戶讀取非公開監督資料，或者執行非法監督操作。--桐生ここ★[討論] 2023年10月23日 (一) 05:03 (UTC)
  吐槽：誰來處理一下console一千多條的Use of "wgULS" is deprecated. Use HanAssist.conv instead.--桐生ここ★[討論] 2023年10月23日 (一) 05:20 (UTC)

有鑒於此權限會容許權限持有者修改全站代碼，同時讀者及編者的瀏覽器會執行該代碼，如果被濫用，植入惡意代碼，後果將會非常嚴重，風險極高，所以界面管理員的可信程度不應亞於管理員，甚至應該更高。

個人認為選界面管理員需要至少行政員一樣的可信程度。此外，行政員處理界面EP請求時，需要能夠理解此JS會執行什麼行為，比如能夠發現編輯請求中潛藏了一個eval留下XSS漏洞。--桐生ここ★[討論] 2023年10月23日 (一) 05:27 (UTC)
不信任的不是行政員，而是方針似乎允許一般用戶不需要經過RFA可以獲臨時授權。--桐生ここ★[討論] 2023年10月23日 (一) 11:09 (UTC)
就下面修訂條文。所以閣下認為要廢除相關條文？不過閣下確實應該明白MediaWiki空間下之JS/CSS不止commons.js/.css。如果閣下評估以後，仍然覺得應該廢除，那在下亦不反對。--J.Wong 2023年10月23日 (一) 12:51 (UTC)
反正這麼多年都沒人申請過，也證明本站未必有此需要。--J.Wong 2023年10月23日 (一) 12:52 (UTC)
原本寫的「若為濫權，則其權限會即時移除」還不夠嘛？另外你這比較條文差異沒有標記好。—— Eric Liu 創造は生命（留言・留名・學生會） 2023年10月23日 (一) 07:58 (UTC)
也不是想這樣說。當初之所以設立界面管理員就是為了應對提案者所言之風險及帳戶盜用問題。經MediaWiki開發人員社群評估後，訂立諮詢文件，本地定立出不亞之之方針。現在什麼都沒發生，然後就要大修一翻。就給人一種「我覺得有問題」的感覺。所以究竟是MediaWiki開發人員社群評估風險不周，還是現在發生了什麼事暴露了問題？--J.Wong 2023年10月23日 (一) 09:42 (UTC)
如果確是發現什麼漏洞，麻煩同時通知MediaWiki開發人員社群。因為界面管理員這東西，不是本地拍下腦袋產生出來的東西。閣下所說之事，在下相信當初已經全盤考慮。如果真的這麼擔心，　貴站要不要把全站JS/CSS權限也外判出去？（不是氣話，是認真）上面提案，根本解決不了所擔心的事情。--J.Wong 2023年10月23日 (一) 09:45 (UTC)
? ——魔琴 [ 留言 貢獻 新手2023計劃 ] 2023年10月23日 (一) 10:55 (UTC)

短期權限申請頁面公示

現行條文

用戶如需申請短期權限，則可至Wikipedia:申請成為介面管理員/臨時申請。

提議條文

用戶如需申請短期權限，則可至Wikipedia:行政員布告板申請。

改為行政員布告板。--桐生ここ★[討論] 2023年10月11日 (三) 15:08 (UTC)

(＋)贊成--冥王歐西里斯（留言） 2023年10月11日 (三) 23:51 (UTC)
(＋)支持。--東風（留言） 2023年10月14日 (六) 11:42 (UTC)
(＋)支持 --及時雨 留言 2023年10月19日 (四) 04:38 (UTC)

現公示10月11日版提案7日（不對提案進行實則性點評的意見不導致重算7日）。Sanmosa Ινα κραζω σοι 2023年10月20日 (五) 00:57 (UTC)

@Sanmosa：時間已到。--Cookai餅塊🍪（💬留言） 2023年10月30日 (一) 14:34 (UTC)
公示通過。已修改。--桐生ここ★[討論] 2023年10月30日 (一) 15:17 (UTC)
取自「https://zh.wikipedia.org/w/index.php?title=Wikipedia_talk:介面管理員/存檔二&oldid=80314435」
返回專案頁面「介面管理員/存檔二」。