维基百科

维基百科讨论:介面管理员/存档二

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