萌娘百科 talk:提案/未通过提案/关于用户权限体系调整的提案(2021.10.08)
序言
草拟了一个萌娘百科用户权限体系调整的方案，此方案不影响既有的萌娘百科官方系（行政员＞管理员＞巡查姬）。
以下方案参考了其他多个维基项目，增设基于高度信任的技术类用户组，因安全等原因调整部分既有的用户组权限等。
个人认为，在管理员申请对内容维护要求高、多数现任管理员极少维护技术类内容的现状下，技术类用户组可解决一些现有的问题，有利于萌娘百科长远的技术类维护的正常进行。同时，技术类用户组的设立也可以调用一些不愿参与站务的技术人员的积极性，提高萌娘百科的技术维护效率。
下文所涉及新建的萌娘百科名字空间页面，如无特殊说明，均为方针级。
预讨论位于萌娘百科_talk:讨论版/方针政策#关于用户权限体系调整的预讨论 —— ほしみ 2021年10月8日 (五) 18:29 (CST)
正文
摘要/太长不看
- 新增「界面管理员」、「脚本编辑员」、「技术编辑员」
、「导入员」[删 1]、「滥用过滤器维护员」[改 1]这四个技术类用户组及其前三个用户组的方针； - 新增「机器用户」、「IP封禁豁免者」用户组及前者的方针；
- 调整「行政员」[提案注释 1]、「管理员」、「监督员」的权限；
- 删除「小部件编辑者」、「开发者(developer)」、「删除执行员」、「监管员(steward)」这四个不再使用的用户组；
- 修订与上述用户组设立/权限调整有关的政策等文件。
| 用户组 | 权限 | 备注 |
|---|---|---|
| 界面管理员 (interface-admin) |
+ 编辑全站CSS (editsitecss) | 新增用户组 将在MW升级至1.32+后默认持有左侧前7个权限 |
| + 编辑全站JSON (editsitejson) | ||
| + 编辑全站JavaScript (editsitejs) | ||
| + 编辑其他用户的CSS文件 (editusercss) | ||
| + 编辑其他用户的JSON文件 (edituserjson) | ||
| + 编辑其他用户的JavaScript文件 (edituserjs) | ||
| + 编辑用户界面 (editinterface) | ||
| + 编辑保护级别为“仅允许技术编辑员和管理员”的页面 (techedit) | ||
(widgeteditor) |
删除用户组 更名为「脚本编辑员」 | |
| 脚本编辑员 (scripteditor) |
+ 在 Widget 名字空间中创建和编辑小部件 (editwidgets) | 新增用户组 |
| + 编辑保护级别为“仅允许技术编辑员和管理员”的页面 (techedit) | ||
| 技术编辑员 (techeditor) |
+ 编辑保护级别为“仅允许技术编辑员和管理员”的页面 (techedit) | 新增用户组 新增保护级别 |
(importer) |
+ |
|
| + | ||
| + | ||
| 滥用过滤器维护员[改 1] (abusefilter-maintainer) |
+ 修改防滥用过滤器 (abusefilter-modify) | 新增用户组 |
| + 修改包含受限动作的防滥用过滤器 (abusefilter-modify-restricted) | ||
| + 撤销指定防滥用过滤器作出的所有更改 (abusefilter-revert) | ||
| + 查看滥用日志中的私有数据 (abusefilter-private) | ||
| 监督员 (suppress) |
+ 将条目在滥用日志中隐藏 (abusefilter-hide-log) | 新增用户权限 |
| + 查看隐藏的滥用日志条目 (abusefilter-hidden-log) | ||
| 管理员 (sysop) |
- |
调整用户权限 减少的用户权限将在MW升级至1.32+后实装 |
| - | ||
| - | ||
| - | ||
| + 编辑保护级别为“仅允许技术编辑员和管理员”的页面 (techedit) | ||
| + | ||
| + 添加/移除用户组：技术编辑员、机器用户 | ||
| + 添加/移除自己的用户组：界面管理员 | ||
| 机器用户 (flood) |
+ 被视为自动化过程 (bot) | 新增用户组 |
| + 不受速率限制影响 (noratelimit) | ||
| + 移除自己的用户组：机器用户 | ||
| IP封禁豁免者 (ipblock-exempt) |
+ 绕过IP封禁、自动封禁和段封禁 (ipblock-exempt) | 新增用户组 |
| 行政员 (bureaucrat) |
+ 进行或解封全域封锁 (globalblock)
|
转移自「steward」用户组 |
(steward) |
删除用户组，依现行方针权限并入行政员。 | |
(developer) |
删除用户组 | |
| 删除用户组 |
调整的细节参见user:星海子/UserGroup/LocalSettings。
新增萌娘百科:界面管理员
界面管理员(interface-admin)是能够编辑Mediawiki名字空间、全站所有CSS、JavaScript页面和滥用过滤器的用户组，属于萌娘百科技术系用户权限体系。 界面管理员不仅可以改进界面消息、提升访客阅读感受，还可以为用户增加更多可能需要的功能、引导编辑者合理使用小工具等。
权限
- 编辑全站CSS
(editsitecss)（在升级MW版本至1.32+后从editinterface拆分） - 编辑全站JSON
(editsitejson)（在升级MW版本至1.32+后从editinterface拆分） - 编辑全站JavaScript
(editsitejs)（在升级MW版本至1.32+后从editinterface拆分） - 编辑其他用户的CSS文件
(editusercss) - 编辑其他用户的JSON文件
(edituserjson) - 编辑其他用户的JavaScript文件
(edituserjs) - 编辑用户界面
(editinterface) 创建或修改滥用过滤器(abusefilter-modify)- 修改包含受限动作的滥用过滤器
(abusefilter-modify-restricted) - 撤销指定滥用过滤器作出的所有更改
(abusefilter-revert) ⧼Right-abusefilter-private⧽[改 1](abusefilter-private)- 编辑保护级别为“仅允许技术编辑员和管理员”的页面
(techedit)
申请与授权
当前仅允许管理员或巡查姬申请长期的界面管理员。符合下列申请条件的，可申请界面管理员用户组：
管理员
- 此用户组正式设立前的管理员无需申请，可在用户组正式设立的两周内授予自己不限期的界面管理员，否则视为自动放弃（行政员不视为自动放弃）。
- 管理员申请此用户组时，仅需向行政员证明有Gadgets的维护能力和CSS/JavaScript类页面的维护意向[方针注释 1]。
- 由于管理员本身可信任度较高，
因此，在申请发出后，若3日内无其他管理员或界面管理员的较多反对，行政员可审核无误后授予申请人用户组。[改 2]
- 由于管理员本身可信任度较高，
- 不担任界面管理员的管理员，可授予自己临时的界面管理员用户组（小于3日），以便短期执行JavaScript/CSS模型页面的移动、保护、删除[方针注释 2]等请求。
巡查姬
- 申请条件
- 在任巡查姬已满30个自然日；
- 符合以下一个或多个条件：
- 能够处理界面消息繁简转换；
- 具有Gadgets的维护能力，能参与全站性CSS/JavaScript类的维护；
能对滥用过滤器进行积极维护；[改 1]
- 注册满1年，且最近1年内无触犯封禁记录（不含滥用过滤器误封及维护组成员测试机制导致的非正常封禁，请注意甄别）；
- 除自行请辞外，发起申请前一个月内未被除去非临时的界面管理员用户组，也未发起过界面管理员申请。
- 授权程序[改 3]
- 使用权限变更版页顶模板的预设按钮发出合格式的申请（不合格式的申请将会作废）；
- 建议申请人在申请中列明主要界面维护方向，以便其他用户给出正确的评价意见。
- 申请发出后为意见发表期（一般为5天，行政员可单独决定延长或缩短），使用召唤术通知现任管理员、界面管理员，从能力等角度在指定区域发表意见。其他用户亦可在讨论区发表相关意见。
- 在意见发表期结束前未撤回申请的，在结束后，由管理员使用{{投票}}开始投票，时长7天，使用召唤术通知全体现任管理员，参考意见区的意见，对申请人进行信任度投票。
投票期结束后由现任管理员点票，管理员每人权重1票。
当同意票占总票数比例超过2/3，且参与率超过1/2时（此处参与率以参与人数而非投票权重计），投票通过；除此以外，投票不通过； - 投票通过后由行政员对计票结果予以确认，无误后授予申请人界面管理员用户组。
注意：若申请人已属于脚本编辑员用户组，行政员可选择跳过信任度投票程序。
界面管理员可维护全站的界面消息、创建或引入复杂工具等。若相关权限被滥用，后果将会非常严重，因此界面管理员的可信程度应不亚于管理员。
除权
符合以下任一除权条件的，应当进入除权程序：
- 用户不再属于管理员、巡查姬用户组时；
- 自行申请；
- 超过90个自然日在萌娘百科和子站模板(Template)、模块(Module)、Mediawiki名字空间
和滥用过滤器[改 1]的编辑次数小于3次； - 管理员未经批准，授予了自己不限期的界面管理员时，应改为临时用户组；
- 短时间内超过3次对CSS/JavaScript的编辑出现严重错误，经评估后可除权；
- 进行破坏或其他严重违反萌娘百科政策的行为；
- 行政员直接除权。
符合除权条件的，由行政员径行除权。其他用户发现有界面管理员符合除权条件的可到权限变更版提报。
义务与规范
- 页面复核
- 修改Mediawiki名字空间的CSS/JavaScript类页面时，有义务在摘要注明修改原因，以便其他界面管理员复核；
- 有义务时常查看萌娘百科:界面脚本动态页面，检查复核他人修改。[提案注释 2]
- 页面删除
- 由于技术原因，仍在使用的界面消息应当直接由管理员删除，巡查姬不应悬挂{{即将删除}}模板；
- 允许同属于巡查姬用户组的界面管理员在更改CSS/JavaScript等页面模型后挂删页面。
注释
新增萌娘百科:脚本编辑员
脚本编辑员(scripteditor)属于萌娘百科技术系用户权限体系。 基于多种原因，萌娘百科不再使用Widgets扩展提供的小部件编辑者(widgeteditor)用户组，改用自定义的脚本编辑员用户组。
Widgets扩展可以让正常的wikitext页面中嵌入原始的HTML页面，管理员和脚本编辑员可在Widget名字空间中创建/编辑页面。
权限
- 创建和编辑
Widget命名空间内的小部件(editwidgets) - 编辑保护级别为“仅允许技术编辑员和管理员”的页面
(techedit)
申请
申请条件
符合以下所有申请条件的，可以申请脚本编辑员用户组，一般建议已是技术编辑员：
- 萌娘百科和子站的主、模板、模块[改 4]、分类名字空间下编辑合计超过600次；
萌娘百科和子站的模板、模块名字空间的总编辑数编辑合计超过200次或模块名字空间的编辑总数大于50次；[改 4]- 能证明充分掌握Widget的使用方法，能写出安全可靠的代码，了解处理高风险页面的职责；
- 有意愿参与各类工具的合作编写，并且愿意、熟练使用诸如Github等管理工具；
- 注册满1年，且最近1年内无触犯封禁记录（不含滥用过滤器误封及维护组成员测试机制导致的非正常封禁，请注意甄别）。
授权程序
- 使用权限变更版页顶模板的预设按钮发出合格式的申请（不合格式的申请将会作废）[改 3]；
- 建议申请人在申请中提出证明自己符合申请条件的证据，以便其他用户给出正确的评价意见。
- 申请发出后为意见发表期（一般为5天，行政员可单独决定延长或缩短），使用召唤术通知现任管理员、脚本编辑员，从代码能力、合作能力等角度在指定区域发表意见。其他用户亦可在讨论区发表相关意见。
- 在意见发表期结束前未撤回申请的，在结束后，由管理员使用{{投票}}开始投票，时长7天，使用召唤术通知全体现任管理员，参考意见区的意见，对申请人进行信任度投票。
投票期结束后由现任管理员点票，管理员每人权重1票。
当同意票占总票数比例超过2/3，且参与率超过1/2时（此处参与率以参与人数而非投票权重计），投票通过；除此以外，投票不通过； - 投票通过后由行政员对计票结果予以确认，无误后授予申请人脚本编辑员用户组。
注意：若申请人已属于界面管理员用户组，行政员可选择跳过信任度投票程序。
如果相关权限被滥用，植入恶意代码，后果将会非常严重，风险极高，所以脚本编辑员的可信程度应不亚于管理员。
除权
符合以下任一除权条件的，应当进入除权程序：
- 用户属于管理员用户组；
- 自行申请；
- 超过90个自然日在萌娘百科和子站模板(Template)、模块(Module)和Widget名字空间页面的编辑次数小于3次；
- 在对任一Widget及其关联模板的编辑时无法充分的小心，导致出现严重错误，经评估后可除权；
- 拒绝与其他管理员或脚本编辑员合作，我行我素，经行政员评估后可除权；
- 进行破坏或其他严重违反萌娘百科政策的行为；
- 行政员直接除权。
符合除权条件的，由行政员径行除权。其他用户发现有脚本编辑者符合除权条件的可到权限变更版提报。
义务和规范
- 页面复核
- 修改Widget时（不含修改说明文档与在沙盒测试），有义务在摘要注明修改原因，以便其他管理员或脚本编辑员复核；
- 有义务时常查看萌娘百科:界面脚本动态页面，检查复核他人修改。[提案注释 2]
新增萌娘百科:技术编辑员
技术编辑员(techeditor)属于萌娘百科技术系用户权限体系，是被社群信任、精通复杂wikitext或熟悉Lua的编辑者，可编辑保护级别为“仅允许技术编辑员和管理员(techedit)”的模板或模块。
申请
申请条件
符合以下所有申请条件的，可以申请技术编辑员用户组：
- 萌娘百科和子站的模板(Template)、模块(Module)名字空间的总编辑数编辑合计超过200次或模块名字空间的编辑总数大于50次；
- 可证明精通复杂wikitext或熟悉Lua，了解处理高风险模板或模块的职责；
- 最近1个月内无触犯萌娘百科:方针#用户封禁政策的行为；无编辑战、人身攻击等行为；
- 除自行请辞外，发起申请前一个月内未被除去技术编辑员用户组，也未发起过技术编辑员申请。
申请程序
- 申请者须自行[增 1]使用权限变更版页顶模板的预设按钮发出合格式的申请；
- 建议列出主要维护的模块、复杂模板或其他方式以证明精通复杂wikitext或熟悉Lua，这样能提高通过的可能性；
- 在申请发出后，管理员应对申请人从能力、信任度等角度进行评估（或管理员邀请其他具有techedit权限的用户发表意见）[改 2]，审核无误后授予申请人用户组。
除权
符合以下任一除权条件的，应当进入除权程序：
- 用户同时属于管理员、界面管理员、脚本编辑员之一的用户组时；
- 自行申请；
- 超过180个自然日在萌娘百科和子站模板(Template)、模块(Module)名字空间页面编辑次数小于3次；
- 短时间内超过3次对任一模板、模块的编辑出现严重错误，经评估后可除权；
- 在编辑受保护的模板、模块时无法充分的小心，导致出现严重错误，经评估后可除权；
- 进行破坏或其他严重违反萌娘百科政策的行为；
- 行政员直接除权。
符合除权条件的，由行政员径行除权。其他用户发现有技术编辑员符合除权条件的可到权限变更版提报。
页面保护
保护级别“仅允许技术编辑员和管理员”仅适用于模板、模块名字空间，以及其他名字空间下的CSS、JavaScript及其关联的定义或帮助页面。
管理员对高流量或高风险的此类复杂页面进行保护时，可选择此编辑保护级别，以便这些页面得到技术人员的持续维护。若前述页面趋于稳定或极其重要时，可选择“仅允许管理员”的保护级别。此外，简单但重要的页面仍应选择“仅允许巡查姬和管理员”或“仅允许管理员”的保护级别。
特别地，由于移动页面需要编辑权限，若设置为“编辑=仅允许技术编辑员和管理员，移动=仅允许巡查姬和管理员“，则会要求页面移动人同时拥有前述两个权限。
|
新增萌娘百科:导入员导入员(importer)，又称跨维基导入员，属于萌娘百科技术系用户权限体系。 此用户组的用户可以使用Special:导入页面、Special:导出页面这两个特殊页面，可以从其他wiki导入页面。 权限
申请符合以下所有申请条件的，可以申请临时的导入员用户组：
申请者应在权限变更版申请此用户组，同时应尽可能写清使用相关权限的方向（例如需要导入的内容方向等）、需要的时长（不得超过3个月），行政员审核无误后发放用户组。 使用规范与义务管理员及导入员均应遵守此节所述要求：
除权符合以下任一除权条件的，应当进入除权程序：
|
新增萌娘百科:滥用过滤器维护员
本页面为论述，保护级别为[编辑=仅允许管理员和巡查姬] [移动=仅允许管理员]。
滥用过滤器维护员(abusefilter-maintainer)属于萌娘百科技术系用户权限体系。[改 1] 此用户组可临时授权于有能力完善滥用过滤器规则的非管理员，只有具有所需的良好判断力和技术熟练程度的用户才被允许配置过滤器。
权限
- 创建或修改滥用过滤器
(abusefilter-modify) - 修改包含受限动作的滥用过滤器
(abusefilter-modify-restricted) - 撤销指定滥用过滤器作出的所有更改
(abusefilter-revert) - ⧼Right-abusefilter-private⧽
(abusefilter-private)
申请与授权
暂无申请与授权程序。
监督员相关调整
此用户组旧称「Flow监督员」或「结构式讨论监督员」，现统一为「监督员」，Grouppage保持萌娘百科:监督不变。
出于安全考虑，滥用过滤器日志应当允许监督员(suppress)更改可见性。故新增下列权限：
- 将条目在滥用日志中隐藏
(abusefilter-hide-log) - 查看隐藏的滥用日志条目
(abusefilter-hidden-log)
在萌娘百科，监督员由行政员兼任，目前暂无监督员授权程序。
管理员相关调整
注：在升级至MW1.32+版本后，系统管理员(sysop)用户组不再自动持有编辑全站CSS (editsitecss)、编辑全站JavaScript (editsitejs)、编辑其他用户的CSS文件 (editusercss)、编辑其他用户的JavaScript文件 (edituserjs)权限。在MW1.31下，管理员仍然持有前述所有权限。
基于其他变动，管理员(sysop)新增下列权限：
- 编辑保护级别为“仅允许技术编辑员和管理员”的页面
(techedit) 导出页面[删 1](export)- 添加用户组：技术编辑员、机器用户
- 移除用户组：技术编辑员、机器用户
- 添加用户组至自己的账号：界面管理员
- 移除自己账号的用户组：界面管理员
新增萌娘百科:机器用户
机器用户(flood)通常用于编辑者执行大量重复性、无争议的操作，一般仅允许人类手动使用。
此用户组的用户进行任何操作时都会添加「机」的标注(Flood flag)，即不希望在Special:最近更改刷屏的同时能确保不需要检查编辑是否有误。
权限
- 被视为自动化过程
(bot) - 不受速率限制影响
(noratelimit) - 移除自己账号的用户组：机器用户
申请与授权
管理员在进行部分无争议、机械式的操作时，管理员可授予自己临时的[增 2]机器用户用户组。 非管理员亦可在需要手工执行大量无争议、机械式，且无法由全自动化程序执行的工作时，可在权限变更版或维护组内部申请此用户组。 一般不建议非维护人员或非技术人员申请此用户组，您可以至讨论版请求维护人员协助。
申请时应遵守如下规范[改 5]：
- 应尽可能使用主账户申请并进行工作；
- 应列明工作内容及工作时间；
- 应注明进行手动或半自动工作。若进行半自动工作，还应说明任务使用的半自动化工具及其预定之编辑频率；
经管理员审查无误后授予申请人临时[增 2]的用户组。
已经被删除的内容当管理员通过Special:替换文本替换文本时，若使用机器用户用户组并勾选「通过Special:最近更改和监视列表通知这些编辑」，则编辑记录可以在最近更改中被手动强制显示；若替换文本时取消勾选了「通过Special:最近更改和监视列表通知这些编辑」，则任何人无法通过最近更改查阅相关编辑记录。[改 6]
特别地，符合以下情形时，管理员不必自授权机器用户用户组：
- 对指定用户的贡献进行大量回退时，可直接在用户贡献页面URL后方添加
&bot=1，此时再点击回退可直接视为机器用户。 - 使用Special:替换文本进行替换文本，并取消勾选「通过Special:最近更改和监视列表通知这些编辑」，其编辑记录将在最近更改中强制隐藏。[改 6]
- 使用Special:批量正则编辑进行替换文本，默认为机器用户，其编辑记录可以在最近更改中被手动强制显示。
使用规范
当用户属于此用户组时，应该只进行预先获批准的操作。预定之操作执行完毕后，应立即自行除去机器用户用户组。
若用户使用自动维基浏览器(AutoWikiBrowser)执行相关操作，需在任何可以附加标签的操作时附加AWB标签；若用户使用其他半自动辅助工具执行相关操作，则需在任何可以附加标签的操作时附加Automation tool标签。[改 5]
急停
急停是指机器用户做出不被许可或意料之外的行为导致负面后果时，为避免影响扩大，由维护组成员给予临时封禁等措施。
符合以下任一急停条件的，应当执行急停程序：
- 执行了大量申请内容之外的工作或大量理应在最近更改显示的操作，但短期少量、注明测试且自行还原结果的操作可以被容忍；
- 若使用AWB或其他半自动辅助工具[改 5]，一小时内作出的操作中有5项或以上需要人为修正，这些操作占这一个小时内作出的所有使用前述工具操作的比例在30%或以上。
提醒：替换文本无法使用封禁或移除用户组进行紧急止损，目前仅有滥用过滤器可阻止相关操作。
除权
当执行完所有需要机器用户的操作时，应立即除去自己的机器用户用户组。
除此外，符合下列任一条件的机器用户将进入除权程序：
- 机器用户执行完任务后忘记取消此用户组；
- 机器用户执行了理应在最近更改显示的操作；
- 非管理员机器用户执行了未批准的操作;
- 机器用户经质询后不再需要此权限[增 3]
管理员可直接对符合上述情形的机器用户进行除权；若违反第3条规定，管理员可同时视情形对相关用户进行警告或封禁，此类行为可能被视为破坏。
保护萌娘百科:IP封禁豁免
暂不创建本页面，保护级别为[创建=仅允许管理员]。
此用户组仅拥有「绕过IP封禁、自动封禁和段封禁 (ipblock-exempt)」的权限。 当用户受其他用户的IP封禁影响时，可通过封禁申诉或其他渠道说明，经用户查核员进行确认后，可授予IP封禁豁免者用户组（一般情况下不建议时长超过对应IP的封禁到期时间），相关政策应在萌娘百科:用户查核方针完善后落实。
修订萌娘百科:机器人
- 序言「机器人账户一般只允许由自动化程序使用，不得由人类手动使用」修订为「机器人账户一般只允许由自动化程序使用，人类手动操作应使用机器用户」。
- 修订提权章节的序言和提权条件。
提权是指授予机器人管理员、巡查姬、界面管理员、脚本编辑员[删 2]或技术编辑员用户组，不得授予行政员权限。
- 提权条件
符合以下任一提权条件的，可以申请提权：
- 所有者为维护组成员时，可以任意申请提升其所有机器人账户的巡查姬或管理员用户组，但不得超过自身权限：
- 管理员可申请将机器人提升到管理员或巡查姬级别；
- 巡查姬仅可申请将机器人提升到巡查姬级别。
- 所有者为技术类用户组成员时，可以申请提升其所有机器人账户的界面管理员
、脚本编辑员[删 2]或技术编辑员用户组，但不得获取自身不具有的权限： - 若所有者确有提升到超出自身权限的必要，可以申请提权，但需要对其缘由作充分说明：
- 如一位非维护组成员开发了清理部分页面的受损文件链接的机器人，但这些页面有一部分被保护到巡查姬级别，此时就可以申请提升机器人到巡查姬级别。
- 修订降权章节的序言和提权条件。
降权指的是被授予管理员、巡查姬、界面管理员、脚本编辑员[删 2]或技术编辑员用户组的机器人因不符合提权条件后被除去相关权限。
- 降权条件
符合以下任一降权条件的，应当进入降权程序：
- 通过提权条件第1、2条获得提权，但所有者已经不再持有对应权限：
- 如管理员申请授予机器人管理员权限的，该管理员失去管理员权限时，该机器人将被降权；
- 由于管理员权限包含巡查姬、
脚本编辑员、[删 2]技术编辑员所有权限，不应将管理员视为不持有此类权限； - 但若所有者系因活跃度低失去权限，且机器人运作良好且仍然必须持有权限，则可暂缓降权，直至机器人完成任务、其他所有者活跃的机器人能完全替代该机器人完成任务或发生故障为止。
- 机器人在提权程序中所指明的任务之外使用权限：
- 这包括但不限于机器人超出范围的使用权限，以及所有者登录机器人账户手动使用相关权限，但短期少量、注明测试且自行还原结果的操作可以被容忍。
注意：
- 通过提权条件第3条获得的权限不随所有者权限变化而降权；
- 如果所有者失去了相关权限却仍然需要机器人持有权限，则需重新申请。
- 除权条件「机器人账户持有的维护组权限」修改为「机器人账户持有的附加用户组及其权限」。
修订萌娘百科:分身账户方针
修订「何时可以使用分身账户」一节「主账户的认定」第3条：
修订为：
- 人事用户组级别如此计算：行政员 > 管理员 > 巡查姬 > 脚本编辑员 > 优质编辑者/技术编辑员[改 7] > 自动确认用户 > （非确认）用户。其他用户组不考虑。
人事用户组级别如此计算：行政员 > 管理员 > 巡查姬 > 优质编辑者 > 自动确认用户 > （非确认）用户；- 在前一条的前提下，若优质编辑者或自动确认用户具有附加的脚本编辑员用户组，则具有前述技术类用户组的账户 > 其他账户；
其他用户组不考虑。
修订「何时可以使用分身账户」一节「单一账户权限」：
修订为
- 目前，只有行政员、用户查核员、监督员、管理员、巡查姬、界面管理员、脚本编辑员是同一自然人仅一个账户可以持有的用户组权限（依照萌娘百科:机器人#提权的规定进行提权的除外）。
修订萌娘百科:方针#用户权限体系
技术系（具有一定权限，但不具有人事权限，不视作萌娘百科官方）
- 人事权限
管理员：授予【巡查姬】、授予/移除【优质编辑者/技术编辑员/机器用户】
- 其他
- 技术系用户组的申请条件等见萌娘百科:界面管理员、萌娘百科:脚本编辑员、萌娘百科:技术编辑员
、萌娘百科:导入员[删 1]； - 机器人及机器用户的申请条件等见萌娘百科:机器人、萌娘百科:机器用户；
修订萌娘百科:行政员
新增权限：
- ⧼Right-globalblock⧽
(globalblock)
此权限由GlobalBlocking扩展提供，仅用于对全域的IP或IP块进行封禁，预定义给steward用户组。基于和widgeteditor类似的原因，依现行方针，仅行政员可执行此类操作，故将此权限从并入行政员，并删除steward(监管员)用户组。
在「行为规范」一节添加：
- 当跳过申请程序授予用户临时的用户组时，应在权限变更的原因栏注明必要的信息（如工作方向、何处申请等）。
修订萌娘百科:程序员招募中
- 变更为失效文档。[提案注释 3]
修订萌娘百科:官方群组
- 停止萌百程序猿群在此页面的展示。[提案注释 4]
- 新建萌百官方界面脚本维护群：
- 管理员、界面管理员、脚本编辑员限定。
其他
- 本次调整应同时应用于中文萌娘百科、萌娘共享、萌娘文库、英文萌娘百科、日文萌娘百科。
- 新建的多个方针页面中权限一节的文本应在用户组实装或MW版本升级后使用界面消息进行替换。[提案注释 5]
- 此提案通过后、后台调整用户权限体系前，应将所有用户的「小部件编辑者」、「developer」、「steward」、「删除执行员」用户组删除。
修订注释区
提案注释
- ↑ 行政员的权限调整为非实质修改。
- ↑ 2.0 2.1 设立类似Template:讨论版目录的页面，记录Mediawiki名字空间内CSS/JavaScript类页面和Widget名字空间内页面的最后修改时间、最后修改人和编辑摘要，同时利用Bot在相关群组内通知。
- ↑ 同时需要修改Template:编制人员等。
- ↑ 已由U:AnnAngela在2021年10月8日20:32(CST)完成。
- ↑ 参考此次更改。
增
删
改
讨论区
关于界面管理员 - User:AnnAngela
在经过仔细考虑后，我改变了我在讨论版的意见。我认为不应授予界管与滥用过滤器相关的权限，因为滥用过滤器本质上是应对破坏的扩展，此等权限应归类为行政权限，不应由技术组持有。其他内容我还需要思考。——From AnnAngela the Bureaucrat (Talk) 2021年10月8日 (五) 20:31 (CST)
- (＋)支持 单纯为了把developer的权限拆分而把滥用过滤器交给界管是不合理的。—— 屠麟傲血（讨论） 2021年10月8日 (五) 20:38 (CST)
- 草。那再拆回去吧，晚上来改 —— ほしみ 2021年10月8日 (五) 20:50 (CST)
屠麟傲血顺带一提，我认为即使界管的授权需要较高信任，特定的页面仍然需要全保护：
- 全站js页面：包括应用于全站、特定皮肤、特定小工具的js页面及其配置页面，如需编辑可提出编辑请求请其他管理复核；
- 各类黑白名单页面：包括各类扩展使用的黑名单、白名单页面，此类页面属管理员使用。
——From AnnAngela the Bureaucrat (Talk) 2021年10月8日 (五) 22:25 (CST)
- (＆)建议 萌百現狀的一個不便之處就是全站JS只有大佬您一個人在接受編輯請求吧。如果要加上全保護的話，希望將覆核技術類編輯請求加入介面管理員的義務和除權條件，並將接受已經過足量技術人員覆核同意的編輯請求加入兼任管理員的介面管理員的義務。——移动版用户 Bhsd 2021年10月9日 (六) 00:19 (CST)
- 问题是现在就您一个管理在接受编辑请求啊，其他管理没见过接受js类编辑请求的……这样吧：“最近30天内，若接受编辑请求的管理员不足2名，则全站的js页面下调至巡查和管理可编辑”。—— 屠麟傲血（讨论） 2021年10月9日 (六) 00:31 (CST)
- 我解释一下原草案中关于保护的内容被移除的原因。
- 第一，按两位行政员的意见，将界管的申请前置上调至巡查，不再适用原先制定的保护草案。
- 第二，我个人认为应当实事求是进行保护。对于界面消息来说，除了涉及站点基本信息的页面（可能只有MediaWiki:Copyright及其子页面）必须保护至管理员外，另外的部分应依照当前站点现状按需保护，例如：评论区/标题黑名单保护至管理员，转换表按现状不保护（直至超过3个活跃管理员熟悉并参与转换表的维护）。此外，管理员需要非管理员的界面管理员协助时（如复杂的正则等），也可以临时调整保护级别，这应该是弹性的。
- 那么对于SiteJS/siteCSS，我认为在现状下可能并不应当保护，兼任界面管理员、且能参与JS/CSS维护的管理员可能并不会很多，很可能有且仅有AnnA一个（按五大维基的数据，在界管设立前，仅8%管理员会经常参与JS/CSS页面的维护）。或许对于SiteJS/CSS，我们不应该从保护入手，需要从其他角度考虑此类页面的复核问题，或是设立一个弹性机制。
- —— ほしみ 2021年10月9日 (六) 01:45 (CST)
关于机器用户 - User:playymcmc007
emmm，我对机器用户有一些看法：
- 机器用户属于用户傀儡吗？（要不要遵守用户分身政策）
- 机器用户可以由多人操控吗？
- 人机合一的账户是不是机器用户？（有时人工有时机器我说的就是你User:机器娘，虽然机器娘已经没用了）
呃，会不会有点杠，总之问下这些问题解决一下我的疑问--
- 机器用户是权限不是另一个账户，可以理解为用于执行手动批量操作而不希望在最近更改刷屏时使用。
- 任何账户都不应当由多人使用。
- 建议将人工使用的账户与机器人账户分开。——From
月_樱_雪 (讨论) 2021年10月9日 (六) 10:31 (CST)
- @Playymcmc007：机器用户是一个临时的用户组，主要（唯一？）的权限是使自己的编辑默认不会在最近更改中显示（就像机器人一样，这个用户组的中文译名可能就是这么来的），但其操作仍由自然人手动进行，不是机器人，也不必是单独的分身账户，可以（且大多数情况下会）直接授予主账户。
- 举个例子，AnnAngela在2020年7月19日（见Special:用户权限/AnnAngela）授予自己【机器人】用户组以进行文本替换工作。在机器用户用户组设立后，此类授权将改为授予自己【机器用户】用户组。
- 根据MGP:分身账户方针，所有账户均应仅由一个自然人操控。
- 根据MGP:机器人方针，机器人所有者应当为机器人单独注册账户并申请权限，且该账户仅能由自动化程序操作。
这次权限体系更新后得写多少新论述才能讲清楚啊……（苦恼- ——C8H17OH（讨论） 2021年10月9日 (六) 15:34 (CST)
- @月_樱_雪那能不能给这权限改成伪机器用户避免出现歧义误会呢（个人意见）--
讨论 ） 2021年10月10日 (日) 00:12 (CST)- 这个用户组在transwiki有两个标准翻译，一个是「伪机器人」，一个是「机器用户」，相对而言后者正常一些。—— ほしみ 2021年10月10日 (日) 00:31 (CST)
- @月_樱_雪那能不能给这权限改成伪机器用户避免出现歧义误会呢（个人意见）--
对当前提案的提问与意见
通读当前提案后，我提出如下问题，请提案发起人回答：
- 这些用户组申请条件中的“较多反对”和“明显反对”究竟是何种含义？
- 提案发起人不设置明确数量条件，而以一模糊的说法代替之，要如何解决潜在的申请争议情况？
- 界面管理员的“未见较多反对”似乎比脚本编辑员的“未见明显反对”更加宽松，前者从字面上可理解为“有反对也不要紧，只要没达到多数”，后者则可以理解为“有反对就不行”，本应要求更严格的界面管理员用户组在这一点上却更加宽松，不知这是否是提案发起人的本意？如果是，这是否合理？
- 脚本编辑员的主要任务是编辑widget（js），这和模板与模块所涉及到的wikitext和lua没有多大联系，把模板与模块的编辑次数作为申请脚本编辑员的条件是否合理？
- 建议改为向行政员提供能证明自己widget/js编辑能力的材料。
- “当管理员通过Special:替换文本替换文本时，若使用机器用户用户组并勾选「通过Special:最近更改和监视列表通知这些编辑」，则编辑记录可以在最近更改中被手动强制显示；若替换文本时取消勾选了「通过Special:最近更改和监视列表通知这些编辑」，则任何人无法通过最近更改查阅相关编辑记录。”这段“机器用户”一节中的说明没有其他上下文，放在这里是何用意？是要禁止后一类行为？令人感到困惑。
- 为什么AWB的相关规定写在“机器用户”页面？这是否代表使用AWB必须申请机器用户？或是未申请机器用户的前提下使用AWB不受下列规定的限制？
- 前一个问题的衍生问题——如果某用户决定使用AWB进行大量编辑但并不申请机器用户，这种用户是否需要进行额外的申请（就像维基，要求AWB使用者必须先申请对应许可）？
- 另一个与AWB相关联的问题——“若使用AWB，一小时内作出的操作中有5项或以上需要人为修正，这些操作占这一个小时内作出的所有使用AWB操作的比例在30%或以上。”这里的两个条件是同时满足才应当被急停，还是只要满足其中一个就需要急停？
- 此外，和AWB具有类似功能的脚本/插件等，是否在该规定的约束范围内？如果答案是否，那这些脚本/插件是否也需要进行类似的约束？
此外，经与行政员讨论，我还提出如下两点意见：
- 导出页面的权限不应设立。
- 站点自迁入以前，直至现在，持续受到爬取全站内容与攻击的困扰。开放对应权限既无必要，也是徒增漏洞。
- 不应允许机器人账户持有界面管理员与脚本编辑员两个权限。
- 本提案仅增加了一个新的保护等级，只需要技术编辑员权限即可对对应被保护页面进行编辑，且必须要前两个用户组权限才能编辑的页面，也并不需要大量的自动化操作。
以上。--Sysop 北极星と南十字(注)（给我留言） 2021年10月9日 (六) 22:49 (CST)
顺带，我发现当前版本提案里界管的滥用过滤器相关权限还没去掉。--Sysop 北极星と南十字(注)（给我留言） 2021年10月9日 (六) 22:54 (CST)
将脚本编辑员的除权条件仅设定为Widget空间是不切实的，看一下Widget空间的编辑历史就可以知道。而且本身运行良好的脚本就毫无理由频繁编辑，如果写的代码没有问题一直不需要修，难道反而该受到惩罚吗？——移动版用户 Bhsd 2021年10月9日 (六) 23:39 (CST)- 关于申请条件中的“较多反对”和“明显反对”
- 此处要表达的是同样的意思。本意是不进行投票，而是推荐行政员/管理员（特别是不深度了解JS/CSS/Widget/lua的管理员）可以参考这些用户给出的意见进行评估，类似于云霞提出的副署。这里应该需要更换一个更好的表述。
- 关于脚本编辑员
- 脚本编辑员包含技术编辑员的所有权限，且widget应当和对应模板一并编写并使用，我还是认为此类考察是有必要的，至少是模板名字空间。证明自己有编写widget相关能力已是申请条件第三条了。
- 关于机器用户
- Special:替换文本 这段话我稍后删掉吧，这是论述类的内容了。本意是管理员可自行选择方式，但可能没有写在这里的必要。
- 此处只规定了机器用户同AWB共同使用，即申请机器用户的前提下使用AWB才受此规范。在未申请机器用户的前提下，非维护人员使用AWB有严格的速率限制（就和站内部分用户的机器人没有申请机器人权限一样），应当是允许的；若是维护人员使用AWB进行手动逐个编辑、且需要显示在最近更改的，也不需要申请机器用户用户组。
- 事实上机器用户用了何种工具是很难鉴定的。稍后把使用其他辅助工具的情形也写进去。
- 急停相关表述来自Project:机器人#急停，可能需要同步解释。
- 关于导出
- 从安全角度来说，导出页面是无法关闭的，目前也只是隐藏。任何用户始终可以通过API导出页面的最后版本；
- 现阶段英萌、日萌没有关闭导出，如果是安全需要的话，建议同步；
- 关于机器人
- 同时禁止导出和机器人持有界管，可能会阻碍了界面消息在主站、共享站、文库的大量同步，这时候应该使用主账户充当机器人（？），我对此仍抱有疑虑；
- 如果前一条允许主账户，那么还应当特别允许管理员的机器人账户持有界面管理员权限，以便进行保护/删除等操作。
- 关于申请条件中的“较多反对”和“明显反对”
- —— ほしみ 2021年10月10日 (日) 00:01 (CST)
关于导入员，在本站的使用主要是同步多站点之间的界面消息等，目前草案中的export+importupload的方法可能并不是上上策。- 本站目前没有配置import的来源站点，如果正确配置了$wgImportSources，在本站姊妹站点内同步是不需要「通过上传文件导入页面 (importupload)」权限的。
- 这么一来，机器人也不需要持有界管，导入员（无importupload，仅import）可以直接并入界面管理员，批量同步的目的也可以快速达成。
- 暂且不知Special:Export的隐藏是否会对上述操作造成影响。
—— ほしみ 2021年10月10日 (日) 03:28 (CST)- import必须要求export特殊页面开放，importupload通过上传文件导入不要求特殊页面存在。
- 关闭export的特殊页面只会让同步步骤增加，实际上倒是不影响。
- 但任何人依旧可以通过api导出页面，防爬虫这个理由实在站不住脚。
- —— ほしみ2021年10月10日 (日) 12:47 (CST)
补充
- 提案业已提及界面管理员及脚本编辑员需要不亚于管理员的可信度，然而截至目前的提案执行方案里依然未见如何通过条款确保界面管理员及脚本编辑员是“可信的”。若仅简单定义由行政员/管理员提权即视为“可信的”，则对照目前管理员的提权程序来说尚差得太多。这也会造成在目前的执行方案下，恐怕即使提案通过，短期内管理层人事用户组也不敢轻易授权相关敏感权限。方针政策版所提及的副署程序乃是（在三级用户组前提下）由上级技术用户组确认技术能力，再由管理层人事用户组确认社群信任度（类似于二重保险）后予以授权。
- 当然，上述所提及的执行方针均基于技术用户组类比人事用户组执行三级权限政策下提出的，然而在本提案中未有执行，因此我认为这是本提案最迫切需要解决的问题。
- 此外由于界管、脚本编辑、技术编辑的权限逐级大部分是向下覆盖的（仅脚本编辑员多一个+editwidgets的功能），而界管的权限则完全覆盖了技术编辑，因此我认为至少界管-技术编辑的二级权限体系是可行的。另外为何技术类用户组在分身方针中并入人事组序列中一并计算？有何用途？是为避免何种情境？颇为不解。
- 最后是导入员及机器用户的问题，由于此两类权限极易被滥用且后果严重，同时考虑到萌娘百科曾经遭遇过维护组人员与萌娘百科决裂、试图进行过激行为等原因，此两类权限仍应该仅限临时授权，并仅授予高信任度的用户组。在除权程序中也应附加“经质询后不在需要此权限，由行政员除权”等条款。--From KumoKasumi the Bureaucrat (Talk) 2021年10月10日 (日) 22:17 (CST)
- 关于可信度的判断，最常用的还是投票程序（原始草案要求界管经投票程序），但也有意见是不需要投票程序，我希望能得到一个关于投票的共识。
- 关于技术能力的判断，我不太认同上下级技术能力判断程序的可行性，这无法和人事用户组体系进行类比。正如前面的讨论中有提到的，“脚本编辑员的申请者未必有意向编辑复杂模板/模块”，界面管理员也未必对复杂模块有充分了解，而单申请技术编辑员的大多应为模块编辑者。此处赋予界管、脚本编辑员techedit的原因一是小工具/小部件涉及或关联的复杂模板可能需要此权限来维护，二是减少多用户组共存的复杂情形。不懂模块的界管又有什么能力来审核具有较强模块编辑能力的技术编辑员用户组申请人呢？我还是认为申请者技术能力的判断只能让有相应技术的来判断，即界管判断界管、管/脚判断脚本编辑等。
- —— ほしみ 2021年10月10日 (日) 23:47 (CST)
- 现在考虑到界管所需信任程度，我撤回我那条不需投票的意见。——From AnnAngela the Bureaucrat (Talk) 2021年10月11日 (一) 08:40 (CST)
- @云霞，我蛮对那个对分身账户方针修订的建议做个解释：我的理解是技术编辑员也是一类 elevated rights 用户组，其本质意义和优秀编辑者在我理解来是相同的（加个权限嘛）。这里应该可以解释为原方针此处用词的不当——优秀编辑者现在的确也不具有维护组人事、站务投票等各种地方的额外权利了，唯一的功能就是好看和自我巡查。在该方针的这个序列的作用只有在用户自己没有清晰描述主账户时让维护组可以有个确立一个用来标记用户的主账户的标准，没有别的功能，不应影响其他方针、指引处关于用户组权限排序的定义；这些新增的、无需维护组权限作为前序条件的非维护组类用户组自然和优质编辑者一样可以用来参考——即如具备技编权限的分身账户应该比普通自动确认用户更适合标记一个用户一样。
- 当然这样的简单列表的确不是特别优异。应该更好的方法是直接改写这一部分——例如，删去分身账户方针§用户账户-4，然后插入：
- 3. 持有维护人员用户组之权限最高的账户是主账户。依靠Project:方针定义维护人员梯队顺序。
- 4. 同时持有下列非维护人员用户组之总数最多的账户是主账户：
- 优秀编辑者，和任意技术系用户组。
- 此处各用户组和用户组总称之定义依照Project:方针§用户权限体系。
- 不过我个人对于如何分类这些用户组权限稍微有些不同想法就是了，一会儿另外开副标题细说吧。—萌百假期放傻了阿巴阿巴 ᕕ(｡∀°)ᕗ🎜🎝 用户名是公的驱逐舰的 壹陆 讨论·最近编辑 2021年10月14日 (四) 09:49 (CST)
界面管理员替代方案：代码审核员
看上去关于授权界面管理员的受信任度认定上还有较大争议，那么如果改为授权代码审核员+由行政员操纵的机器人界面管理员的制度呢？要求以后代码页面的新编辑请求需要更改为类似pushpull request的形式（如果原始编辑请求不是的话，可以由代码审核员代为修改格式），然后再经足量代码审核员同意后由机器人界面管理员自动接收请求。这样的话代码审核员并没有直接编辑站点代码的权限，且需要多人同意才会生效。编辑请求的格式可以参考中文维百，审核表决的投票制度可以参考gerrit。——移动版用户 Bhsd 2021年10月11日 (一) 00:25 (CST)
- （(…)吐槽 不是叫pull request吗…）“足量代码审核员同意→机器人自动接受请求”这个过程里，没太理解机器人如何能得知条件被满足？——C8H17OH（讨论） 2021年10月11日 (一) 01:18 (CST)
- 我把这个构想按当前提案的思路简化一下，大意是「非管理员的界面管理员编辑SiteJS/SiteCSS/SkinJS/SkinCSS/默认启用的Gadgets时，应在摘要注明多个参与代码复核的界面管理员，或是受理他人的编辑请求。违反规定除权。」大概是这样（？—— ほしみ 2021年10月11日 (一) 01:52 (CST)
- (：)回應User:C8H17OH 比如可以要求代碼審核員使用規定格式的摘要（如包含“同意”、“反對”字樣）在對應段落回復，然後機器人直接檢查最近更改，驗證發言人是否是代碼審核員以及最後一次合法表態就行。實際操作起來方法還挺多的，就看怎麼更準確和方便吧。
- (：)回應User:星海子 前面的討論對介面管理員的擔心似乎是破壞性質的吧？這樣的話除權條件就幫不上忙了。——移动版用户 Bhsd 2021年10月11日 (一) 02:09 (CST)
- 啊这，我的理解是代码安全性和稳定性。—— ほしみ 2021年10月11日 (一) 02:38 (CST)
关于投票
界面管理员和脚本编辑员属于高信任度用户组，投票算是信任度判断方法中相对简单的。
参考管理员申请，初版界管的申请方案如下：
- 使用权限变更版页顶模板的预设按钮发出合格式的申请（不合格式的申请将会作废）；
- 建议申请人在申请中列明主要界面维护方向，以便其他用户给出正确的评价。
- 申请发出后为意见发表期（一般为3天，行政员可单独决定延长或缩短），使用召唤术通知现任管理员、界面管理员，从能力角度在指定区域发表意见。其他用户亦可在讨论区发表意见。
- 在意见发表期结束前未撤回申请的，在结束后，由维护组成员使用{{投票}}开始投票，时长7天，使用{{大召唤术}}通知全体现任管理员和正式巡查姬，参考意见区的意见，对申请人进行信任度投票。
投票期结束后由现任管理员点票，管理员每人投票权重2票，巡查姬每人权重1票。
当同意票占总票数比例超过2/3，且管理员参与率超过2/3，管理员+巡查姬参与率超过1/2时（此处参与率以参与人数而非投票权重计），投票通过；除此以外，投票不通过； - 投票通过后由行政员对计票结果予以确认，无误后授予申请人界面管理员用户组。
这个方案整体较为繁琐，我个人建议仅管理员投票。另外，时长、计票方式什么的也可以再讨论讨论。我比较担心更多人因为不了解界管/脚编是做什么的而投弃权，或是跟风投票。—— ほしみ 2021年10月11日 (一) 16:46 (CST)
第二版：
- 使用权限变更版页顶模板的预设按钮发出合格式的申请（不合格式的申请将会作废）；
- 建议申请人在申请中列明主要界面维护方向，以便其他用户给出正确的评价意见。
- 申请发出后为意见发表期（一般为3天，行政员可单独决定延长或缩短），使用召唤术通知现任管理员、界面管理员，从能力等角度在指定区域发表意见。其他用户亦可在讨论区发表相关意见。
- 在意见发表期结束前未撤回申请的，在结束后，由管理员使用{{投票}}开始投票，时长7天，使用{{大召唤术}}通知全体现任管理员，参考意见区的意见，对申请人进行信任度投票。
投票期结束后由现任管理员点票，管理员每人权重1票。
当同意票占总票数比例超过2/3，且参与率超过1/2时（此处参与率以参与人数而非投票权重计），投票通过；除此以外，投票不通过； - 投票通过后由行政员对计票结果予以确认，无误后授予申请人界面管理员用户组。
—— ほしみ 2021年10月12日 (二) 17:29 (CST)
- (－)反对 质疑管理员有无能力对界面管理员投票。——移动版用户 Bhsd 2021年10月13日 (三) 01:21 (CST)
- 此处为信任票，并非能力评价意见。—— ほしみ 2021年10月13日 (三) 01:24 (CST)
- 在票权和参与率上多半很难达成一致，建议其他反对者也给出自己的方案，同时也希望得到其他维护人员、技术人员的意见和方案。—— ほしみ 2021年10月13日 (三) 01:35 (CST)
- 目前来看第二版方案算是当下最优的版本了，如果是以此方案选拔界管，那我同意只对黑白名单类界面消息页面进行保护。——From AnnAngela the Bureaucrat (Talk) 2021年10月13日 (三) 10:04 (CST)
- 已暂时将此方案写入提案正文，欢迎大家提出更好的方案～—— ほしみ 2021年10月13日 (三) 23:58 (CST)
关于荣誉维护组成员
- 虽然说这只是个称号系的用户组，但目前站内关于该用户组的说明似乎只有月 樱 雪在User:玄微子/萌百史记/维护组部分评论区中的解释（或许还有？），鉴于这个名称的“分量”与可能带来的误解（？），是否应该在萌娘百科:方针#用户权限体系的称号系中添加荣誉维护组成员，或者在别处对该用户组的授予条件进行一定正式的说明？
- 另，方针似乎没有提到维护组成员所指，是否需要说明该名词仅指行政员/管理员/巡查姬？—— 2021年10月12日 (二) 23:00 (CST)
关于页面保护等级
- 现有的提案对于保护等级为“仅允许巡查”和“仅允许技术编辑”是设计为两个完全独立的保护等级，那么在提案通过后，对于现有的保护等级为“仅允许巡查”的页面是否需要逐一检查并调整保护等级？
- 按照现有的保护等级体系，“仅允许巡查”等级包括了高流量以及复制模板两种情况，如果加入保护等级“仅允许技术编辑”的话，是否应当给巡查姬也赋予“技术编辑”权限？按照现有的保护体系来看，巡查本来就能够编辑这些保护页面，同时巡查的申请也包括了“熟悉wikitext”这一项，同时考虑到巡查本身的受信任程度以及当前的体系，还有如果设计为独立保护等级的话用户权限体系将更为复杂、页面维护可能会更困难。如果将保护等级形成（管理员->巡查姬->技术编辑）这样的关系的话，我觉得能在保持当前体系的情况下使得权限体系变得不那么复杂，也便于管理。--
SinonJZH(๑•̀ω•́๑)(讨论) 2021年10月16日 (六) 07:03 (CST)
- 我觉得这块可以讨论一下，我的想法是既然脚和界需要巡查前置，那么我觉得巡查可以拥有techedit权限。——From AnnAngela the Bureaucrat (Talk) 2021年10月16日 (六) 08:27 (CST)
- 脚本编辑员当前没有要求巡查前置，只是申请条件要求较高且和界管类似的授权程序；
- 当前已有的“仅允许巡查”等级的页面仅在模板、模块名字空间内（尤其是模块名字空间）可能会按需调整等级；“技术保护”可能会更多地应用于原先缺少保护的一些模块、模块等页面内；
- 我个人不太建议巡查拥有技术保护权限，一是部分巡查并不十分了解了解复杂wikitext、解析器函数的使用（也不乏自行修改/受理编辑请求修改炸了的情形），二是这可能会导致行政/内容维护和技术维护两个体系混杂，我认为不如单独按需申请来的便于管理。—— ほしみ 2021年10月16日 (六) 14:35 (CST)
- 如果是基于将行政和内容维护分开的考量的话，那我(＋)可以支持将两种保护等级分开的做法。不过按照现在的提案，技术编辑和巡查、界管/脚本和管理员在申请和考察方面基本类似，都具有较为繁复的申请手续，我怀疑这是否真的能起到吸引更多人参与维护的作用。
- 您提到要为“缺少保护”的页面增加保护，请问具体有哪些页面？另外我觉得也需要在方针中规定一个需要/允许启用保护的标准，以防止技术保护被滥用，反而阻止编辑者进行维护。比如说即使是仅嵌入了几十个条目的模板/模块，或者不那么复杂的页面却被添加了保护。--
- 据我所知，还是存在不小一部分编辑者无意参与全站内容维护但对部分技术类内容存在较大兴趣的，技术编辑员的申请程序并不算复杂。
- 没保护的举两个简单的例子，模块:Lyrics/colors、模块:Timeline，有几百几千嵌入，前者的编辑者并非都是维护人员，后者仍有极大的改进可能，这一类页面我觉得可以添加技术保护。还有一些过去保护等级较高的也可以调整。
- 目前页面保护基本都是弹性保护，问题不算很大。我觉得未来的保护相关政策可能需要结合版本删除、监督、名字空间或特定页面封禁（升级后的功能）一起考虑。
- —— ほしみ 2021年10月17日 (日) 19:43 (CST)
关于用户组权限的分类
虽然这不是本提案的主题，但考虑到本提案会新增数个用户组并提出了一个新的用户组分类，我还是想提一下我自己对这些分类的看法，供大家参考。之前写下的看法请参考我之前的发言。16再一次重新定义“一会儿”（
太长不读：建议将本提案新增的所有用户组权限和优质编辑者、机器人合并分为一类，称“功能性用户组”，并依此修改其他相关方针；另提出一些如何重新分类萌百剩余用户组的建议。
当前的P:方针将用户组权限分类为“萌娘百科官方系”和“称号系”；我认为这样的二元基础是合理的，但是应该稍微修改一下。依我的理解，所谓“官方系”和其他用户组权限的区别仅有两个：1.官方系具有萌娘百科官方代表的地位，2. 维护人员具有参与用户组权限变更的权利（无论是直接变更权限还是参与提降权投票）。技术上，所有用户组权限的区别仅有用户组赋予的额外权限不同而已，只不过萌娘百科的方针和共识认为部分权限（如封禁权）的持有和使用自然地带有萌百官方色彩；而至于用户组权限变更的权利，我倾向认为这是维护人员特有的权利（而非整个“官方性用户组”的特征）——原因是Etolli通过额外条文失去了这些权利、而似乎也可以视为官方的Staff用户组完全没有这类权利。顺带一提，“官方”的定义一直没有明文写明、又随着 Baskice 的退出和专业运营公司的引入变得模糊了一些（因为当前的维护组和运营实体是分离的），但是对于普通用户和路过读者而言，把维护人员和运维视为穿同一条裤子应该不会造成什么问题……？
相对的，原来的“称号系”分类我觉得改为“功能性用户组”更佳：目前唯一列出的称号系用户组，优质编辑者，虽然当前主要是称号但是的确具有实际的用户权限（非人事权限）——把自己的编辑自动标记为巡查。虽然现在的巡查操作没有那么大的意义，但我认为这仍然可以视为方便具有一定经验和名誉的普通编辑更高效的参与编辑、也方便维护人员减少工作量的权限——这是我对功能性用户组的理解：无官方地位，具有一定的"elevated priviledges"，通过权利下放来减少维护组工作量。当前的P:方针没有列出的机器人用户组我认为就是功能性用户组的一类（而将其分类为称号明显不大合适），而本提案新增的用户组自然应该都是功能性用户组
自然，原有的“称号系”分类也可以保留，用来分类那些不具备任何额外权限、完全仅有称号功能的用户组：这包括早已失效的前“分类分组”（新番组之类）、VIP用户组、和新增的“荣誉维护组”称号。
最后，为了方便，应该考虑在P:方针中定义好这些用户组类别后不一一列出具体的类别成员（官方类除外——如果需要增减，这本来就需要大规模的方针修改），而是让用来给这些新用户组的设立和提降权提供成文规定的具体方针来规定这些用户组属于哪一类别。期望这些相关方针可以加入到特定分类（或者直接准备一个论述型帮助）来方便查看这些分类中都有哪些用户组。
如果我的这些建议被完全采纳的话，我的期望会是将Project:方针#用户权限体系的开头修改为类似于这样的内容：
萌娘百科的用户组分类为以下三类：
- 官方性用户组（官方类）。这些用户组被视为萌娘百科官方的代表，其意见和行动除非特别说明，否则可以视为代萌娘百科官方作出。本类细分为二子类：
- 功能性用户组（功能类）。这些用户组不被视为萌娘百科官方，仅为获得了一些额外权限的普通用户。这些额外权限可以让具有一定能力、经验、和/或名誉的用户更方便的参与编辑（包括进行一些一般用户无法直接进行的
页面操作），降低萌娘百科的维护人员的维护工作量。本分类的用户组请参看分类:定义了功能性用户组的方针。 - 名誉性用户组（名誉类）。这些用户组不视为萌娘百科官方、也不具备任何额外权限，仅作为授予一些为萌娘百科作出较大贡献的用户一个特殊的荣誉称号而设立。本分类的用户组请参看分类:定义了名誉性用户组的方针。
另外应该删除P:方针关于优质编辑者的定义，将定义完全交给已经成为方针的Project:优质编辑者；如果认为可行，也应考虑删除行政、管理、和巡查在P:方针中的定义（对应单页均为方针）——当然可能要修改这些方针确保内容和现在的P:方针相同。如果需要在P:方针中定义“荣誉维护组”的话，可以把最后半句改成“本分类的用户组包含荣誉维护组，其他用户组请参看分类:定义了名誉性用户组的方针。”
好像有点像是尝试给这个提案绑上了一个很大规模的改动的样子……如果需要的话我可以近期开一个新提案，不过这些个东西我就先放在这里吧。电脑没电了，先写这些。— GAVIAL IS LIFE用户名是公的驱逐舰的 壹陆 讨论·最近编辑 2021年10月26日 (二) 10:11 (CST)
- 大体上我觉得没问题，但有一些不同意见。
打开这个段落就看到「本子」- 我认为技术类用户组的划分确有必要，或许可以在功能类下设一类。除了不开放申请过滤器维护员，它的显著特征是含有techedit权限，具有特定的义务，在多个文件中可能会用到这个词以便涵盖这些用户。
- 我倾向于把优质编辑者列入名誉性用户组一类，或是更名为荣誉系用户组。原因一是P:优编开头描述即为「优质编辑是萌娘百科授予优秀贡献者的荣誉称号之一」，二是优编目前确实不具有社群语义上的额外权限。这样一来，就是优编、荣、VIP一个组了。
- 如果按照前述2点进行改动，那么功能性用户组剩下的机器用户、机器人、IP封禁豁免这三个归为一组。这个组的特征是不需要参与您之前提出的分身账户方针§用户账户-4修改方案的排序，但可能不太好命名。
- 行政员和优编的比较好整，但把行管理员、巡查姬的一些内容移动到各个方针里改起来挺麻烦的，尤其是管理员方针已经很久没有同步更新了。最开始草案里也有类似的表述，但是因为
麻烦（ ）所以后来移除了（（（ - 另外，我个人不太喜欢用「权限」一词，mediawiki权限和社群语义的权限意思不同会导致歧义，得看看有没有什么更好的表述（
- 以上。—— ほしみ 2021年10月26日 (二) 15:26 (CST)
- (：)回应 @星海子，
- 中！分子类我没意见，要考虑一下子类要如何加入就是了。把用户组分类树（包括子类）留在P:方针里应该是可以的，反正理论上它不需要过多调整、而就算真的要拆解它这部分肯定也只会跟着“用户权限方针”而已。
- 或者，考虑使用“具有 techedit 权限”这个定义来统称以绕过“设立子类”。
- 或者，拆分 techedit 权限，所有技术类用户组的前置要求都是先获取技术编辑员用户组。（实际请求授权的时候可以同时申请技术编辑员和具体的高级技术类用户组——看起来满足高级技术类用户组申请要求的用户自然满足技术编辑员的申请要求——授权时一并授权即可。）（我喜欢这个！）
- 我认为这是一个应用上的问题——优编的原始功能仍在、Mediawiki 用户权限仍在，授予需要经验和名誉，分身账户方针也因此特别提及它用来协助判断主账户——而我的设想是新增的技术子类和优编应当平级用于主账户排序；对于“社群语义上的额外权限”，我的理解是技术子类用户组同样没有社群内的额外权限（特别是人事方面的）——如果把进行操作时不明显可见的权限全部视为“非社群语义上的权限”，那么IPBE是称号类用户组吗？我觉得不应因为优编用户组当前习惯上的应用而将其和其他完全无权限的名誉性用户组（或许改称荣誉性用户组更佳？）划分到一起，除非整个巡查系统被完全抛弃、优编退化成完全的荣誉名称。
- 然后发现这触发了一个很奇怪的问题：VIP自带“免验证码”MW权限，荣誉维护组自带“自动巡查”MW权限。我其实建议删去荣誉维护组的“自动巡查”权限，毕竟这和优编的权限一模一样、大可授予荣誉维护组的时候顺带授予优编即可，这样可以方便在各类方针中直接忽略这些除了名号没有别的功能的用户组。至于VIP……成员只有萌百站娘创作者，而免验证码现在还有意义吗？（当然还有一个方法是直接打个包“legacy usergroup”然后不管它……）
- 其实我认为机器用户和IPBE仍应当参与主账户认定的排序。机器人其实已经参与了排序：分身账户方针§用户账户-4.1记“机器人账户永远不会是主账户”。
- 如果这样的话，只要不考虑移动P:方针中的定义，就应考虑将这些小方针废弃为论述。尽管P:方针永远最高，但还是应当避免方针相互矛盾。
- You gotta work with what you have, man. 甚至说……“社群语义的权限”大概是个什么？如果没有好的定义，我宁愿将方针大部分的“权限”一词理解为Mediawiki 语义的权限。
- 中！分子类我没意见，要考虑一下子类要如何加入就是了。把用户组分类树（包括子类）留在P:方针里应该是可以的，反正理论上它不需要过多调整、而就算真的要拆解它这部分肯定也只会跟着“用户权限方针”而已。
- — GAVIAL IS LIFE用户名是公的驱逐舰的 壹陆 讨论·最近编辑 2021年10月27日 (三) 05:33 (CST)
- 同一类用户组不叠加主要是考虑授权/除权时更简单，不用像ZHWP那样叠罗汉（（（
- 没有任何Mediawiki权限是无法设立用户组的，任何用户组都具有Mediawiki权限。荣誉类用户组也是必定持有有特定权限的（“自动巡查”或“免验证码”），所以我认为优编列入称号/荣誉类是可接受的。旧番组什么的早已不在可授予的用户组内，这些历史用户组不需要考虑吧，去不掉是因为后台取消这个组的时候没有先去除这个组所有用户的用户组，所以这次写了#其他一节以避免此类事情的再次发生。
- 然后关于主账户定义。「机器用户」需要借助主账户的定义来发放，套娃不太好（ ，「IPBE」只能说没什么必要吧。
- 另外，我想了想，可以把「滥用过滤器维护员」从技术组里拉出来，它没有techedit，同时只是临时授予，不具有参与主账户排序的必要。
- 整理一下，我的想法是这样的：
- (：)回应 @星海子，
萌娘百科的用户组分类为以下三类：
提案终止
发起人终止提案。—— ほしみ 2021年10月29日 (五) 23:31 (CST)