萌娘百科討論:提案/未通過提案/關於用戶權限體系調整的提案(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) 檢視濫用日誌中的非公開資料[改 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) - 檢視濫用日誌中的非公開資料
(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]； - 機器人及機器使用者的申請條件等見萌娘百科:機器人、萌娘百科:機器使用者；
修訂萌娘百科:行政員
新增權限：
- 進行或解封全域封鎖
(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)完成。
- ↑ 參考此次更改。
增
刪
改
- ↑ 1.0 1.1 1.2 1.3 1.4 1.5 1.6 依U:AnnAngela之意見，不應授予過濾器編輯權限給介面管理員，因此再把「濫用過濾器維護員」從草案原稿中加回來。
- ↑ 2.0 2.1 更改申請時他人意見的模糊表述
- ↑ 3.0 3.1 參考兩位行政員的建議，界管與指令碼編輯員的信任判斷改為投票程序。
- ↑ 4.0 4.1 合併指令碼編輯員的兩條申請要求，不再刻意要求模塊。
- ↑ 5.0 5.1 5.2 重構了機器使用者的申請條件與使用規範一節
- ↑ 6.0 6.1 依U:北極星與南十字的意見，刪除這段論述。改為在下方簡單描述。
- ↑ 依U:公的驅逐艦的意見，直接將指令碼編輯員和技術編輯員列入。
討論區
關於介面管理員 - 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)