维基百科

维基百科讨论:介面管理員/存檔二

< 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”
返回到项目页面“介面管理員/存檔二”。