本站页面（多半）转载自萌娘百科的同名页面，依CC BY-NC-SA 3.0引入，贡献者可以在历史页查询。
因各种原因页面内容可能和源页面有所出入，非本站特有页面内容请以萌娘百科为准。此外，因萌百的api限制，本站部分页面和图片同步自另一个镜像站。
置顶公告：【置顶】关于临时开启评论区所有功能的公告(2022.10.22) | 【置顶】关于本站Widget恢复使用的公告
  • 你好～！欢迎来到萌娘百科镜像站！如需查看或编辑，请联系本站管理员注册账号。
  • 本镜像站和其他萌娘百科的镜像站无关，请注意分别。
本頁使用了標題或全文手工轉換

萌娘百科討論:提案/已通過提案/關於用戶權限體系更新的提案(2021.12.01)

萌娘百科，萬物皆可萌的百科全書！轉載請標註來源頁面的網頁連結，並聲明引自萌娘百科。內容不可商用。
跳至導覽 跳至搜尋

前言

本提案與萌娘百科_talk:提案/未通過提案/關於用戶權限體系調整的提案(2021.10.08)不同，涉及萌娘百科全部用戶權限體系的更新。

下文所涉及新建的萌娘百科名字空間頁面，如無特殊說明，均為方針級。—— ほしみ 2021年11月17日 (三) 17:29 (CST)

正文

用戶組權限變更
權限名稱 權限用途 用戶組 備註
globalblock 進行或解封全域封鎖 使用者查核員 轉移自steward
加入群組：IP封鎖例外者 新增權限
移除群組：IP封鎖例外者
abusefilter-hide-log 隱藏在濫用日誌的項目 監督員 新增權限
abusefilter-hidden-log 檢視已隱藏的濫用日誌項目
deletebatch 批量刪除頁面 管理員 轉移自行政員
deleterevision 刪除及取消刪除指定的頁面修訂 新增權限
techedit 編輯保護級別為「僅允許技術編輯員和管理員」的頁面
加入群組：技術編輯員、機器使用者
移除群組：技術編輯員、機器使用者、榮譽維護人員
在自己的帳號中加入的多個群組：介面管理員
移除自己帳號中的多個群組：介面管理員
suppressredirect 移動頁面時不在原頁面建立重新導向 巡查姬 新增權限
reupload 覆蓋現有的檔案
unwatchedpages 查看未受監視的頁面
reupload-own 覆蓋自己上傳的現有檔案 優質編輯者 新增權限
reupload-own 覆蓋自己上傳的現有檔案 榮譽維護人員 新增權限
suppressredirect 移動頁面時不在原頁面建立重新導向 機器人 恢復權限
skipcaptcha ⧼right-skipcaptcha⧽ STAFF 新增權限
autopatrol 將自己的編輯自動標示為已巡查
autoconfirmed 不受基於IP的使用頻率限制
noratelimit 不受使用頻率限制
ipblock-exempt 略過IP封鎖、自動封鎖及範圍封鎖檢查
在自己的帳號中加入的多個群組：管理員、介面管理員、指令碼編輯員
移除自己帳號中的多個群組：管理員、介面管理員、指令碼編輯員
editsitecss 編輯全站CSS 介面管理員 新增用戶組
editsitejson 編輯全站JSON
editsitejs 編輯全站JavaScript
editusercss 編輯其他使用者的 CSS 檔
edituserjson 編輯其他使用者的 JSON 檔
edituserjs 編輯其他使用者的 JavaScript 檔
editinterface 編輯使用者介面
techedit 編輯保護級別為「僅允許技術編輯員和管理員」的頁面
editwidgets 建立並編輯 Widget 命名空間中的 微件 指令碼編輯員 新增用戶組
techedit 編輯保護級別為「僅允許技術編輯員和管理員」的頁面
techedit 編輯保護級別為「僅允許技術編輯員和管理員」的頁面 技術編輯員 新增用戶組
abusefilter-modify 建立或修改防濫用過濾器 濫用過濾器維護員 新增用戶組
abusefilter-modify-restricted 修改防濫用過濾器使用已限制的動作
abusefilter-revert 還原所有指定防濫用過濾器做的變更
abusefilter-log-private 檢視標記為非公開的濫用過濾器日誌項目
bot 將其視為自動程序 機器使用者 新增用戶組
noratelimit 不受使用頻率限制
移除自己帳號中的多個群組：機器使用者
ipblock-exempt 略過IP封鎖、自動封鎖及範圍封鎖檢查 IP封鎖例外者 新增用戶組
微件編輯者 刪除用戶組
steward 刪除用戶組
⧼group-developer⧽ 刪除用戶組
刪除執行員 刪除用戶組

方針#用戶權限體系

萌娘百科的用戶組分類為以下三類：

  1. 官方用戶組。具有一定權限，意見視為萌娘百科官方。本類細分為二子類：
    1. 維護人員：行政員、管理員、巡查姬。其用戶組等級和意見效力亦按此順序遞減。他們具有較高維護權限和參與用戶組權限變更事宜的權利，有義務參與站點方針/指引的制定。其中，行政員還可能兼有使用者查核員、監督員用戶組。
    2. 運維人員：STAFF。 他們是萌娘百科的在職工作人員，不直接具有額外人事權限，作為萌娘百科的運營實體在萌娘百科的代表。
      • 特別地，官方賬戶萌娘百科[更多]對話頁貢獻上傳歷史封鎖及歷史被刪貢獻移動日誌巡查日誌使用者權限及日誌使用者查核不計入投票基數，不適用活躍度限制。
  2. 榮譽用戶組：優質編輯者、榮譽維護人員、VIP。這些用戶組不視為萌娘百科官方，僅為嘉獎一些為萌娘百科作出特定貢獻的用戶而設立。
  3. 功能用戶組：僅為獲得了一些額外權限的普通用戶，不視為萌娘百科官方。本類細分為三子類：
    1. 技術類：介面管理員、指令碼編輯員、技術編輯員。這些用戶組均擁有「編輯保護層級為「僅允許管理員和技術編輯員」的頁面」的權限，前二者還擁有一些其他權限。這些額外權限可以讓具有一定能力、經驗的用戶更方便的參與編輯（包括進行一些一般用戶無法直接進行的操作）。
    2. 機器類：機器人、機器使用者。這些用戶組均擁有「將其視為自動程序」的權限，用於協助用戶執行大量任務。
    3. 其它類：濫用過濾器維護員、IP封鎖例外者。

各用戶組權限參見Special:用戶組權限，申請條件等參見各用戶組方針/論述頁面。

維護人員的基本義務

萌娘百科的維護人員必須遵守本方針規定之義務與禁忌。

安全義務

  1. 不得將賬號借予他人使用；
  2. 使用與其他網站不同的高強度密碼；
  3. 應在安全的網絡環境下進行維護。

維護義務

  1. 有義務按萌娘百科:維護人員的維護任務進行維護；
  2. 當發現其他維護人員行為有誤或者可以改進時要即時提出；
  3. 維護人員有義務謹慎進行受限操作，儘可能避免重大操作失誤；
  4. 維護人員有義務關注站點頁頂公告欄中的重要站內事務；
  5. 管理員[改 1]有義務將萌娘百科_talk:討論版及其子頁面加入監視列表並定期查看討論以及提問。

維護禁忌

  1. 不允許參與任何涉及編輯獎勵的編輯，收費刪除（或美化/詆毀）的行為被嚴厲禁止；
  2. 不得在站外以萌娘百科維護人員等名義進行罵街、打嘴炮、引戰等行為；
  3. 若非反破壞等維護需求，[增 1]管理員不得公開濫用過濾器私有詳情中涉及個人隱私的信息；
  4. 若非反破壞等維護需求，使用者查核員不得公開使用者查核中涉及個人隱私的信息；[增 2]
  5. 非萌娘百科對外宣傳人員，不得以萌娘百科名義在站外與第三者進行交涉。

行政員

有的時候，身為行政員也需要付出一些代價。

行政員（Bureaucrats，bureaucrat）可以編輯所有人的（包括自己）用戶組權限。行政員須具備在出現複雜情況的時候處理爭議或敏感內容、決定討論共識及結論，並能有效地對這些決定做出全面解釋的能力。

行政員屬於管理員的附加用戶組，一般情況下同時兼任使用者查核員和監督員。

權限

  • 不受使用頻率限制 (noratelimit)；
  • 合併使用者 (usermerge)——由於技術限制，暫時不開放申請；
  • 編輯所有使用者的權限 (userrights)；
  • 覆蓋欺騙檢查 (override-antispoof)；
  • 重新命名使用者 (renameuser)——由於技術限制，暫時不開放申請。

申請與授權

申請條件
  1. 連續擔任管理員或臨時行政員至少6個月；
  2. 過去6個月內超過30日內有編輯或其他操作行為；
  3. 6個月內積極行使管理員職責，未有不活躍警告；
  4. 未曾進行破壞萌娘百科的行為；
  5. 發起申請前三個月內未被除去行政員、使用者查核員或監督員用戶組，也未發起過行政員申請。
授權程序
  1. 在權限變更版使用預設的申請模板發出合格式的申請（不合格式的申請將會作廢）；
    • 建議申請人在申請中說明申請的緣由，否則可能難以取得信任從而獲得足夠多的同意票；
    • 申請人可以在申請時選擇放棄使用者查核員、監督員中一個或多個用戶組，這可能會影響用戶投票；
  2. 申請發出後在詢問期內（一般為發起申請後7日內，行政員可單獨決定延長或縮短），其他用戶可向申請人提出關於萌娘百科維護、行政員及其權限和萌百未來發展等的提問。
    • 提問只能在申請後3日內發出，申請人回答後的追問不作限制；
    • 建議申請人在自己的能力範圍內回應適量的問題，一般建議申請人回答現任行政員的所有提問；
    • 追問和對追問的回答參上規定。
  3. 在詢問期滿3日後，由維護人員開啟投票，投票期時長7日。
  4. 投票期結束後由現任維護人員點票：
    • 管理員每人投票權重2票，巡查姬每人權重1票。
    • 在維護人員參與率超過2/3的前提下，同意票占總票數之比例超過2/3，且管理員反對票占管理員總票權數之比不足1/2，投票通過；除此以外，投票不通過。
    • 當同意票占總票數比例超過2/3，管理員+巡查姬參與率超過2/3時，投票通過；除此以外，投票不通過。[改 2]
  5. 投票通過後由行政員對計票結果予以確認，無誤後授予申請人行政員、使用者查核員、監督員用戶組。
  • 注意：因為個人原因（而不是面臨社群質疑）申請暫離的行政員，在六個月內重新申請，行政員可選擇跳過授權程序直接授權。

義務與職責

  • 根據社群投票結果，授予或除去相應用戶的各類用戶組；
    • 當跳過申請程序授予用戶臨時的用戶組時，應在Special:用戶權限的原因欄註明必要的信息（如工作方向、申請地點等）。
  • 執行各用戶組方針中的快速降權程序，以減少萌娘百科的損失；
  • 審核機器人並發放機器人用戶組；
  • 積極參與與站點運維方（STAFF）的溝通；
  • 在出現爭議或敏感內容等特殊情形時，需決定討論共識及結論，並能有效地對這些決定做出全面解釋；
  • 行使最終決定權，並向運維方通報執行意見；
  • 其他方針、指引中額外規定的特殊情形。

降權與除權

  • 活躍度不足：
    • 過去30日內，有編輯或其他操作行為的日數不足3日，在萌娘百科和萌娘共享（主，模板Template，分類Category，幫助Help，萌娘百科Project，文件File）名字空間編輯次數不足5次。其他人留言詢問後，7日內無回復和操作行為；
    • 連續2次維護人員人事案或提案未參與投票或被視為未參與投票，該行政員將會受到警告：
      1. 此處維護人員人事案、提案未參與數分別單獨計算；
      2. 如果不能在一周內闡明自己連續不投票的原因或原因不能被至少2位行政員接受，則會被除去行政員用戶組；
      3. 而在答覆後的下一次維護人員人事案和提案投票中仍投棄權票或未參與投票的，將被直接除去行政員用戶組。
  • 被成功彈劾，須經彈劾程序：
    1. 自動確認使用者可在權限變更版發起行政員彈劾程序：
      • 若已有對相應行政員彈劾投票程序正在進行，原則上應在此彈劾案內補充陳述、證據、討論等內容，不應新發起重複的彈劾程序；
      • 若行政員彈劾程序未通過，不可對行政員發起管理員彈劾程序。
    2. 彈劾發起且有效後進入7日的質詢期，被彈劾的行政員可以回應彈劾，有票權的用戶亦可參與質詢討論。此階段內發起人可隨時撤回彈劾；
    3. 在質詢期滿7日後，若彈劾未撤回，由維護人員開啟投票，投票期時長7日。
    4. 投票期結束後由現任維護人員點票：
      • 被彈劾人沒有票權，其他管理員每人投票權重2票，巡查姬每人權重1票。
      • 在維護人員參與率超過2/3的前提下，同意票占總同意+總反對票比例超過2/3時，同意票占總票數比例超過2/3，且管理員反對票占管理員總票權數之比不足1/2，[改 2]投票通過；除此以外，投票不通過。
      • 自動確認使用者在行政員彈劾投票中，可以表達意見但不計票數。
    5. 投票通過後行政員對計票結果予以確認，無誤後除去被彈劾人行政員、使用者查核員、監督員用戶組。
  • 自行申請。

其他

管理員

人人都可以是管理員。

管理員（媛）（Administrators，sysop）是統籌管理萌娘百科全站的站點維護人員，擁有大量管理權限。管理員作為萌娘百科的高階編輯，有能力且有義務引導用戶正確編輯、參與討論版討論，同時也需要參與提案、人事變動等重大站務的討論與投票表決。

申請與授權

申請條件
  1. 已任巡查姬滿30日，且30日內未有不活躍警告；
  2. 已知曉並確保可以遵守萌娘百科:維護人員的基本義務；
  3. 已經通讀了萌娘百科:維護人員的維護任務；
  4. 在萌娘百科的主（namespace=0）、模板（template:）、分類（category:）名字空間下編輯合計超過600次；
  5. 在萌娘共享的文件（file:）、分類（category:）名字空間下編輯合計超過50次；
  6. 熟練掌握wiki代碼/分類/模板/文件的使用方法，可以讀懂較複雜的wikitext；
  7. 有10個由自己主力編寫的條目，證明自己已經熟悉wiki代碼，能寫出高質量條目；
  8. 了解萌娘百科、萌娘共享的各類方針/指引文件；
  9. 能基本保證每日在線維護半小時或以上；
  10. 最近1個月內無觸犯萌娘百科:方針#用戶封禁政策和其它方針有關封禁規定的行為；
  11. 發起申請前一個月內未被除去管理員用戶組，也未發起過管理員申請。
授權程序
  1. 在權限變更版使用預設的申請模板發出合格式的申請（不合格式的申請將會作廢）；
    • 建議申請人在申請中說明申請的緣由，否則可能難以取得信任從而獲得足夠多的同意票。
  2. 申請發出後在詢問期內（一般為發起申請後7日內，行政員可單獨決定延長或縮短），其他用戶可向申請人提出關於萌娘百科維護、行政員及其權限和萌百未來發展等的提問。
    • 提問只能在申請後3日內發出，申請人回答後的追問不作限制；
    • 建議申請人在自己的能力範圍內回應適量的問題，一般建議回答不超過25個問題，並儘可能回答更多現任維護人員的提問；
    • 追問和對追問的回答參上規定。
  3. 在詢問期滿3日後，由維護人員開啟投票，投票期時長7日。
  4. 投票期結束後由現任維護人員點票：
    • 管理員每人投票權重2票，巡查姬每人權重1票；
    • 在維護人員參與率超過2/3的前提下，同意票占總同意+反對票之比例超過2/3，且管理員反對票占管理員總票權數之比不足1/2，投票通過；除此以外，投票不通過。
  5. 投票通過後由行政員對計票結果予以確認，無誤後授予申請人管理員用戶組。
  • 注意：因為個人原因（而不是面臨社群質疑）申請暫離的管理員，在六個月內重新申請巡查姬或管理員用戶組，行政員可選擇跳過授權程序直接授權。

義務與職責

除基本義務與維護任務外，管理員還應：

  1. 積極受理巡查姬、技術編輯員等用戶組的申請；
  2. 積極參與人事案、提案的討論和投票；
  3. 受理巡查姬等用戶組無法做到的維護任務、編輯請求；
  4. 合併提案、快速提案內容至方針或指引頁面，實現社群討論所得的共識；
  5. 定期檢查私有過濾器日誌，改進濫用過濾器；
  6. 履行其它方針或指引中管理員的工作職責；
  7. 儘可能為用戶提供更好的訪問感受。

降權與除權

快速降權

符合下列條件時，應當將管理員快速降至巡查姬用戶組：

  • 所發放的巡查姬在發放不滿三個月的情況下因其不合申請條件、被彈劾或嚴重違規而被撤銷，且第一次和第三次間隔不足一年的，可認為其維護標準與社群意見差距很大；
  • 在短期內大量操作失誤，經行政員評估需要儘快減少損失；
  • 因觸犯萌娘百科:方針#用戶封禁政策和其它方針有關封禁規定的行為而遭到短期封禁。

行政員可以在降級時指定15日或30日察看期，察看期結束後方可恢復管理員身份，期間不可自行申請管理員權限。

除權程序
  • 活躍度不足：
    • 過去30日內，在萌娘百科和萌娘共享（主，模板Template，分類Category，幫助Help，萌娘百科Project，文件File）名字空間編輯次數不足3次。其他人留言詢問後，7日內無回復和操作行為；
    • 在其他管理員於用戶討論頁提醒參與維護人員人事案投票至投票結束期間，若在萌娘百科和萌娘共享有超過2次編輯行為，但仍未參與投票，該管理員將會受到警告：
      • 如果不能在兩周內闡明自己不投票的原因或原因不能被超過1/3的管理員接受則會被除去管理員用戶組；
    • 連續3次維護人員人事案、技術人員人事案或提案投棄權票、未參與投票或被視為未參與投票，該管理員將會受到警告：
      1. 如果不能在兩周內闡明自己連續棄權/不投票的原因或原因不能被超過1/3的管理員接受則會被除去管理員用戶組；
      2. 而在答覆後的下一次人事案和提案投票中仍投棄權票或未參與投票的，將被直接除去管理員用戶組。
  • 被成功彈劾，須經彈劾程序：
    1. 自動確認使用者可在權限變更版發起管理員彈劾程序：
      • 若已有對相應管理員彈劾投票程序正在進行，原則上應在此彈劾案內補充陳述、證據、討論等內容，不應新發起重複的彈劾程序；
      • 若行政員彈劾程序未通過，不可對行政員發起管理員彈劾程序。
    2. 彈劾發起且有效後進入7日的質詢期，被彈劾的管理員可以回應彈劾，有票權的用戶亦可參與質詢討論。此階段內發起人可隨時撤回彈劾；
    3. 在質詢期滿7日後，若彈劾未撤回，則由維護人員開啟投票，投票期時長7日。
    4. 投票期結束後由現任維護人員點票：
      • 被彈劾人沒有票權，管理員每人投票權重4票，巡查姬每人權重2票，自動確認使用者每人1票；
      • 在總同意票占維護人員總票權數比例超過1/3的前提下，維護人員同意票占維護人員總票權數比例超過2/3，或總同意票占總同意+總反對票比例超過2/3時，投票通過；除此以外，投票不通過。
    5. 投票通過後行政員對計票結果予以確認，無誤後除去被彈劾人管理員用戶組。
  • 自行申請。

巡查姬

巡查姬ですの！

巡查姬（Patrollers，patroller）是對萌娘百科進行日常性維護的站務維護人員。巡查姬作為萌娘百科中階至高階編輯，有義務對萌娘百科的頁面進行巡查，且對未達到質量標準的條目進行維護性操作。

申請與授權

申請條件
  1. 已成為自動確認使用者超過30日；
  2. 已知曉並確保可以遵守萌娘百科:維護人員的基本義務；
  3. 已經通讀了萌娘百科:維護人員的維護任務；
  4. 在萌娘百科的主（namespace=0）、模板（template:）、分類（category:）名字空間下編輯合計超過200次；
  5. 在萌娘共享的文件（file:）、分類（category:）名字空間下編輯合計超過25次；
  6. 掌握wiki代碼/分類/模板/文件的基本使用方法；
  7. 有1個由自己主力編寫的條目，證明自己已經會用wiki代碼，能寫出條目；
  8. 有10個維護過的頁面的特定歷史記錄點，通過編輯歷史證明自己明白如何提高頁面質量；
  9. 最近1個月內無觸犯萌娘百科:方針#用戶封禁政策和其它方針有關封禁規定的行為；
  10. 發起申請前一個月內未被除去管理員、巡查姬用戶組，也未發起過巡查姬申請。
授權程序
  1. 在權限變更版使用預設的申請模板發出合格式的申請（不合格式的申請將會作廢）；
    • 建議申請人在申請中提出證明自己符合申請條件的證據（如相關編輯的鏈接等），否則可能難以取得信任從而獲得授權。
  2. 管理員審核確認符合申請條件後授予申請人相應用戶組。
    • 管理員應授予申請人時長15日的巡查姬用戶組作為實習期，詳見#實習考核制度之規定；
    • 若7日內無管理員受理巡查姬申請，視為自動拒絕。

實習考核制度

實習
  1. 申請成為巡查姬後，會有15日的實習期，在此期間若正常執行了維護工作且滿足了相應標準，則轉為正式巡查姬。若實習期未予通過，30日內不可進行二次申請；
  2. 實習巡查姬不代表萌娘百科官方人員，但仍需遵守萌娘百科:維護人員的基本義務；
  3. 實習巡查姬在人事/提案投票中仍被視為其擔任巡查姬前的用戶組；
  4. 結合萌娘百科:維護人員的維護任務，積極參與維護工作，沒有出現重大編輯錯誤；
  5. 無觸犯萌娘百科:方針#用戶封禁政策及其他方針規定封禁之行為；
  6. 實習期滿7日後，若實習期未被中止，實習巡查姬可選擇加入維護組群，參與更多的社群討論和公開度不那麼高的討論。
考核
  1. 維護人員可在權限變更版指定區域對實習巡查姬進行簡單提問或評價；
    • 若有簡單提問，申請人可選擇不超過5個問題進行回答（問題數量不以提問人計）；
    • 其他用戶亦可在討論區發表意見。
  2. 若實習巡查姬在實習期間存在嚴重違反萌娘百科現行方針/指引的行為，經維護人員討論後，授權的管理員可選擇中止實習期；
  3. 授權的管理員有義務幫助實習巡查熟悉萌娘百科的方針/指引；
  4. 授權的管理員可在實習期第14日起3日內，結合維護人員的意見，對實習巡查姬進行考核，若通過則授予正式的巡查姬用戶組；
    • 若授權的管理員因各種意外情況而無法在實習期到期前及時進行考核，其他管理員可代為考核。
  5. 管理員可選擇對因為個人原因（而不是面臨社群質疑）申請暫離、在六個月內重新申請巡查姬的用戶跳過實習考核制度。

降權與除權

  • 活躍度不足：
    • 過去30日內，在萌娘百科和萌娘共享（主，模板Template，分類Category，幫助Help，萌娘百科Project，文件File）名字空間編輯次數不足3次。其他人留言詢問後，7日內無回復和操作行為；
    • 在其他管理員於用戶討論頁提醒參與維護人員人事案投票至投票結束期間，若在萌娘百科和萌娘共享有超過2次編輯行為，但仍未參與投票，該巡查姬將會受到警告：
      • 如果不能在兩周內闡明自己不投票的原因或原因不能被超過1/3的管理員接受則會被除去巡查姬用戶組；
    • 連續3次維護人員人事案或提案投棄權票、未參與投票或被視為未參與投票，該巡查姬將會受到警告：
      1. 如果不能在兩周內闡明自己連續投棄權/不投票的原因或原因不能被超過1/3的管理員接受則會被除去巡查姬用戶組；
      2. 而在答覆後的下一次人事案和提案投票中仍投棄權票或未參與投票的，將被直接除去巡查姬用戶組。
  • 被成功彈劾，須經彈劾程序：
    1. 自動確認使用者可在權限變更版發起巡查姬彈劾程序：
      • 若已有對相應巡查姬彈劾投票程序正在進行，原則上應在此彈劾案內補充陳述、證據、討論等內容，不應新發起重複的彈劾程序；
      • 通過快速降權程序降權為巡查姬的原管理員，仍應按管理員彈劾程序進行彈劾。
    2. 彈劾發起且有效後進入7日的質詢期，被彈劾的巡查姬可以回應彈劾，有票權的用戶亦可參與質詢討論。此階段內發起人可隨時撤回彈劾；
    3. 在質詢期滿7日後，若彈劾未撤回，則由維護人員開啟投票，時長7日。
    4. 投票期結束後由現任維護人員點票：
      • 被彈劾人沒有票權，管理員每人投票權重4票，巡查姬每人權重2票，自動確認使用者每人1票；
      • 在總同意票占維護人員總票權數比例超過1/3的前提下，維護人員同意票占維護人員總票權數比例超過1/2，或總同意票占總同意+總反對票比例超過1/2時，投票通過；除此以外，投票不通過。
    5. 投票通過後行政員對計票結果予以確認，無誤後除去被彈劾人巡查姬用戶組。
  • 自行申請。

STAFF

此方針將在最終決定權恢復行使後升級為站點基本信息。

是的，他們幹活是有工資的。

萌娘百科網自2020年3月起由紹興萌派網絡有限公司（以下簡稱紹興萌派）持有，紹興萌派自此為萌娘百科提供服務器與技術等方面的支持，負責萌娘百科的對外宣傳。STAFF（staff）用戶組即是授予紹興萌派在萌娘百科的在職工作人員持有。

權限

  • ⧼right-skipcaptcha⧽ (skipcaptcha)
  • 將自己的編輯自動標示為已巡查 (autopatrol)
  • 不受基於IP的使用頻率限制 (autoconfirmed)
  • 不受使用頻率限制 (noratelimit)
  • 解除封鎖自己 (unblockself)
  • 略過IP封鎖、自動封鎖及範圍封鎖檢查 (ipblock-exempt)
  • 在自己的帳號中加入的多個群組：管理員、介面管理員、指令碼編輯員
  • 移除自己帳號中的多個群組：管理員、介面管理員、指令碼編輯員

STAFF添加用戶組至自己的賬戶時，應遵守如下規範：

  • 可自授權任意期限的介面管理員、指令碼編輯員用戶組，以便改進萌娘百科技術問題；
  • 僅可在緊急事項或確有維護需要時自授權有限期的管理員用戶組，使用完畢應及時除去相應用戶組。

官方賬戶

此為萌娘百科的官方賬戶，名義上的站長，持有行政員、管理員、介面管理員、監督員、使用者查核員、STAFF用戶組。

其他

榮譽維護人員

榮譽維護人員（Honored maintainers，honoredmaintainer）是萌娘百科授予因個人原因而離職的維護人員的榮譽用戶組。榮譽維護人員雖然不再被視為萌娘百科官方人員，但他們是萌娘百科堅定的支持者，曾經為萌娘百科做出較大貢獻。

在此用戶組設立後，萌娘百科不再向離任的維護人員自動發放「優質編輯者」用戶組。

權限

  • 將自己的編輯自動標示為已巡查 (autopatrol)
  • 覆蓋自己上傳的現有檔案 (reupload-own)

授權條件

  • 已任或曾任維護人員滿30日，因個人原因（而非面臨社群問責）而主動辭職。
  • 已任或曾任維護人員滿90日，最後一個任期最後90日內不活躍警告次數不滿2次，因不活躍自動去職。
  • 其他經維護人員討論、行政員認定可發放的特殊情形。
    • 若維護人員因各種原因宣布辭去或放棄一切用戶組，或是拒絕接受該用戶組，則不授予此用戶組。

授權程序

  • 此用戶組設立後，符合授權條件的在任維護人員在辭職或去職時將默認發放此用戶組。
  • 此用戶組設立前，符合授權條件的前任維護人員可在討論版權限變更區申請此榮譽用戶組。
    • 若存在確有需要主動[改 3]回溯發放的特殊情形，由行政員直接發放。

用戶組的收回

  • 當持有此用戶組的用戶重新成為萌娘百科的維護人員時，收回此用戶組。
    • 特別地，當用戶重新申請成為巡查姬而需要進行實習期考核時，在正式授予巡查姬用戶組前仍保留此用戶組。
  • 因嚴重違反站點方針而遭到封禁時，可收回該榮譽稱號。
  • 用戶自願放棄用戶組時，收回該用戶組。

優質編輯者

每個優秀條目背後都有一位……

優質編輯者（Good editors，goodeditor）是萌娘百科授予優秀貢獻者的榮譽用戶組。

作為共筆型網站，充實的內容和編輯者的貢獻緊密相連。萌娘百科會不定期授予一些能夠十分熟練地編輯萌百、熟知編輯規範、並做出大量貢獻的用戶，以嘉獎他們勤耕不輟的精神。

權限

  • 將自己的編輯自動標示為已巡查 (autopatrol)
  • 覆蓋自己上傳的現有檔案 (reupload-own)

優質編輯者們可以將自己的編輯自動標示為已巡查，這樣可以跳過頁面的初步檢查，這是由於他們通常獲得了社群的初步信任。優質編輯者們雖然不被視作萌娘百科的官方人員，但他們是萌娘百科堅定的支持者，而且正在通過自己的努力使萌娘百科這個項目趨於完善。

申請與授權

  1. 任何編輯質量優異，無需返工的編輯者都可直接被維護人員授予該稱號。
  2. 如果希望自己/其他用戶獲得該稱號，可主動向任一維護人員申請，或是在討論版公開提出申請/提名。
  • 維護人員在授予優質編輯者時：
    • 應當在Special:用戶權限正確填寫原因。
    • 應向其用戶討論頁告知用戶組變更的信息，以及覆蓋自己上傳的現有檔案權限的使用說明。

用戶組的移除

  1. 超過3名維護人員認為編輯質量不符合「巡查豁免」的標準；[增 4]
  2. 短時間內超過3次編輯質量達不到最低標準需要維護人員補救；
  3. 進行破壞或其他嚴重違反萌娘百科方針/指引的行為；
  4. 無法正確使用「覆蓋自己上傳的現有檔案」的權限，經評估造成不良後果；
  5. 自行申請放棄。

介面管理員

介面管理員（Interface administrators，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)
  • 編輯保護級別為「僅允許技術編輯員和管理員」的頁面 (techedit)

申請與授權

當前僅允許管理員、巡查姬和指令碼編輯員申請長期的介面管理員。符合下列申請條件的，可申請介面管理員用戶組：

管理員
  • 此用戶組正式設立前的管理員無需申請，可在用戶組正式設立的兩周內授予自己不限期的介面管理員，否則視為自動放棄（行政員不視為自動放棄）。
  • 管理員申請此用戶組時，僅需向行政員證明有Gadgets的維護能力和CSS/JavaScript類頁面的維護意向[ia 1]。
    • 由於管理員本身可信任度較高，行政員可審核無誤後授予申請人用戶組。
  • 不擔任介面管理員的管理員，可授予自己臨時的介面管理員用戶組（不超過3日），以便短期執行JavaScript/CSS模型頁面的移動、保護、刪除[ia 2]等請求。
巡查姬/指令碼編輯員
申請條件
  1. 在任巡查姬或指令碼編輯員已滿30日；
  2. 符合以下一個或多個條件：
    • 能夠處理界面消息繁簡轉換；
    • 具有Gadgets的維護能力，能參與全站性CSS/JavaScript類的維護；
  3. 註冊滿1年，且最近1年內無觸犯萌娘百科:方針#用戶封禁政策和其它方針有關封禁規定導致的封禁記錄[改 4]；
  4. 除自行請辭外，發起申請前一個月內未被除去非臨時的介面管理員用戶組，也未發起過介面管理員申請。
授權程序
  1. 在權限變更版使用預設的申請模板發出合格式的申請（不合格式的申請將會作廢）[改 4]；
    • 建議申請人在申請中列明主要界面維護方向，以便其他用戶給出正確的評價意見。
  2. 申請發出後為意見發表期（一般為7日，行政員可單獨決定延長或縮短），使用召喚術通知現任管理員、介面管理員，從能力等角度在指定區域發表意見。其他用戶亦可在討論區發表相關意見。
  3. 在意見發表期滿3日後，由管理員開啟投票，時長7日，使用召喚術通知全體現任管理員，參考意見區的意見，對申請人進行信任度投票。
  4. 投票期結束後由現任管理員點票：
    • 管理員每人權重1票。
    • 當同意票占總票數比例超過2/3，且參與率超過1/2時，投票通過；除此以外，投票不通過。
  5. 投票通過後由行政員對計票結果予以確認，無誤後授予申請人介面管理員用戶組。

注意：若申請人已屬於指令碼編輯員用戶組，行政員可選擇跳過信任度投票程序直接授予介面管理員用戶組[改 4]。

介面管理員可維護全站的界面消息、創建或引入複雜工具等。若相關權限被濫用，後果將會非常嚴重，因此介面管理員的可信程度應不亞於管理員。

除權

符合以下任一除權條件的，應當進入除權程序：

  1. 用戶不再屬於管理員、巡查姬、指令碼編輯員用戶組時；
  2. 自行申請；
  3. 過去90日內，在萌娘百科和萌娘共享（模板Template、模塊Module和MediaWiki）名字空間編輯次數不足3次[改 4]；
  4. 管理員未經批准，授予了自己不限期的介面管理員時，應改為臨時用戶組；
  5. 短時間內超過3次對CSS/JavaScript的編輯出現嚴重錯誤，經評估後可除權；
  6. 進行破壞或其他嚴重違反萌娘百科方針/指引的行為。
  7. 行政員直接除權。[刪 1]

符合除權條件的，由行政員徑行除權。其他用戶發現有介面管理員符合除權條件的可到權限變更版提報。

義務與規範

頁面覆核
  1. 修改Mediawiki名字空間的CSS/JavaScript類頁面時，有義務在摘要註明修改原因，以便其他介面管理員覆核；
  2. 有義務時常查看萌娘百科:界面腳本動態頁面，檢查覆核他人修改。[ia 3]
頁面刪除
  1. 由於技術原因，仍在使用的界面消息應當直接由管理員刪除，巡查姬不應懸掛{{即將刪除}}模板；
  2. 允許同屬於巡查姬用戶組的介面管理員在更改CSS/JavaScript等頁面模型後掛刪頁面。

注釋

  1. ↑ 管理員默認持有editinterface權限，處理界面消息繁簡轉換無需申請此用戶組。
  2. ↑ 用戶名字空間下的JavaScript/CSS模型頁面無需臨時自授權也可以直接刪除。
  3. ↑ 設立類似Template:討論版目錄的頁面，記錄MediaWiki名字空間內CSS/JavaScript類頁面和Widget名字空間內頁面的最後修改時間、最後修改人和編輯摘要，同時利用Bot在相關群組內通知。

指令碼編輯員

指令碼編輯員（Script editors，scripteditor）是萌娘百科的技術類功能用戶組。基於多種原因，萌娘百科不再使用Widgets擴展預定義的小部件編輯者(widgeteditor)用戶組，改用自定義的指令碼編輯員用戶組。

Widgets擴展可以讓正常的wikitext頁面中嵌入原始的HTML頁面，管理員和指令碼編輯員可在Widget名字空間中創建/編輯頁面。

權限

  • 建立並編輯 Widget 命名空間中的 微件 (editwidgets)
  • 編輯保護級別為「僅允許技術編輯員和管理員」的頁面 (techedit)

申請與授權

申請條件

符合以下所有申請條件的，可以申請指令碼編輯員用戶組，一般建議已是技術編輯員：

  1. 在萌娘百科和萌娘共享的主（namespace=0）、模板（template:）、分類（category:）名字空間下編輯合計超過500次[改 5]；
  2. 能證明充分掌握Widget的使用方法，能寫出安全可靠的代碼，了解處理高風險頁面的職責；
  3. 有意願參與各類工具的合作編寫，並且願意、熟練使用諸如Github等管理工具；
  4. 註冊滿1年，且最近1年內無觸犯萌娘百科:方針#用戶封禁政策和其它方針有關封禁規定導致的封禁記錄[改 5] ；。
授權程序
  1. 在權限變更版使用預設的申請模板發出合格式的申請（不合格式的申請將會作廢）[改 5] ；
    • 建議申請人在申請中提出證明自己符合申請條件的證據，以便其他用戶給出正確的評價意見。
  2. 申請發出後為意見發表期（一般為7日，行政員可單獨決定延長或縮短），使用召喚術通知現任管理員、指令碼編輯員，從代碼能力、合作能力等角度在指定區域發表意見。其他用戶亦可在討論區發表相關意見。
  3. 在意見發表期滿3日後，由管理員開啟投票，時長7日，使用召喚術通知全體現任管理員，參考意見區的意見，對申請人進行信任度投票。
  4. 投票期結束後由現任管理員點票：
    • 管理員每人權重1票；
    • 當同意票占總票數比例超過2/3，且參與率超過1/2時，投票通過；除此以外，投票不通過。
  5. 投票通過後由行政員對計票結果予以確認，無誤後授予申請人指令碼編輯員用戶組。

注意：若申請人已屬於介面管理員用戶組，行政員可選擇跳過信任度投票程序直接授予指令碼編輯員用戶組[改 5]。

如果相關權限被濫用，植入惡意代碼，後果將會非常嚴重，風險極高，所以指令碼編輯員的可信程度應不亞於管理員。

除權

符合以下任一除權條件的，應當進入除權程序：

  1. 用戶屬於管理員用戶組；
  2. 自行申請；
  3. 過去90日內，在萌娘百科和萌娘共享（模板Template、模塊Module和Widget）名字空間編輯次數不足3次[改 5]；
  4. 在對任一Widget及其關聯模板的編輯時無法充分的小心，導致出現嚴重錯誤，經評估後可除權；
  5. 拒絕與其他管理員或指令碼編輯員合作，我行我素，經行政員評估後可除權；
  6. 進行破壞或其他嚴重違反萌娘百科方針/指引的行為。
  7. 行政員直接除權。[刪 2]

符合除權條件的，由行政員徑行除權。其他用戶發現有腳本編輯者符合除權條件的可到權限變更版提報。

義務和規範

頁面覆核
  1. 修改Widget時（不含修改說明文檔與在沙盒測試），有義務在摘要註明修改原因，以便其他管理員或指令碼編輯員覆核；
  2. 有義務時常查看萌娘百科:界面腳本動態頁面，檢查覆核他人修改。

技術編輯員

技術編輯員（Technical editors，techeditor）是萌娘百科授予被社群信任、精通複雜wikitext或熟悉Lua編輯者的技術類功能用戶組。技術編輯員可編輯保護級別為「僅允許技術編輯員和管理員(techedit)」的模板或模塊等頁面。

申請與授權

申請條件

符合以下所有申請條件的，可以申請技術編輯員用戶組：

  1. 萌娘百科和萌娘共享的模板(Template)、模塊(Module)名字空間的總編輯數編輯合計超過200次或模塊名字空間的編輯總數大於50次；
  2. 可證明精通複雜wikitext或熟悉Lua，了解處理高風險模板或模塊的職責；
  3. 最近30日內無觸犯萌娘百科:方針#用戶封禁政策和其它方針有關封禁規定導致的封禁記錄[改 6]；無編輯戰、人身攻擊等行為；
  4. 除自行請辭外，發起申請前一個月內未被除去技術編輯員用戶組，也未發起過技術編輯員申請。
授權程序
  1. 申請者須自行使用權限變更版頁頂模板的預設按鈕發出合格式的申請；
    • 建議列出主要維護的模塊、複雜模板或其他方式以證明精通複雜wikitext或熟悉Lua，這樣能提高通過的可能性；
  2. 在申請發出後，授權的管理員應對申請人從能力、信任度等角度進行評估（或管理員邀請其他具有techedit權限的用戶發表意見），審核無誤後授予申請人用戶組；
    • 若7日內無管理員受理技術編輯員申請，視為自動拒絕。

除權

符合以下任一除權條件的，應當進入除權程序：

  1. 用戶同時屬於管理員、介面管理員、指令碼編輯員之一的用戶組時；
  2. 自行申請；
  3. 過去180日內，在萌娘百科和萌娘共享（模板Template、模塊Module）名字空間編輯次數不足3次[改 6]；
  4. 短時間內超過3次對任一模板、模塊的編輯出現嚴重錯誤，經管理員[增 5]評估後可除權；
  5. 在編輯受保護的模板、模塊時無法充分的小心，導致出現嚴重錯誤，經管理員[增 5]評估後可除權；
  6. 進行破壞或其他嚴重違反萌娘百科方針/指引的行為。

符合除權條件的，由管理員徑行除權。其他用戶發現有技術編輯員符合除權條件的可到權限變更版提報。

頁面保護

保護級別「僅允許技術編輯員和管理員」僅適用於模板、模塊名字空間，以及其他名字空間下的CSS、JavaScript及其關聯的定義或幫助頁面。

管理員對高流量或高風險的此類複雜頁面進行保護時，可選擇此編輯保護級別，以便這些頁面得到技術人員的持續維護。若前述頁面趨於穩定或極其重要時，可選擇「僅允許管理員」的保護級別。此外，簡單但重要的頁面仍應選擇「僅允許巡查姬和管理員」或「僅允許管理員」的保護級別。

特別地，由於移動頁面需要編輯權限，若設置為「[編輯=僅允許技術編輯員和管理員] [移動=僅允許巡查姬和管理員]」，則會要求頁面移動人同時擁有前述兩個權限。

濫用過濾器維護員

本頁面為論述，保護級別為[編輯=僅允許管理員和巡查姬] [移動=僅允許管理員]。

濫用過濾器維護員（Abusefilter Maintainers，abusefilter-maintainer）是萌娘百科授予有能力完善濫用過濾器規則編輯者的功能用戶組。

權限

  • 建立或修改防濫用過濾器 (abusefilter-modify)
  • 修改防濫用過濾器使用已限制的動作 (abusefilter-modify-restricted)
  • 還原所有指定防濫用過濾器做的變更 (abusefilter-revert)
  • 檢視標記為非公開的濫用過濾器日誌項目 (abusefilter-log-private)

申請與授權

此用戶組可臨時授權於有能力完善濫用過濾器規則的非管理員，只有具有所需的良好判斷力和技術熟練程度的用戶才被允許配置過濾器。

機器使用者

機器使用者（Bot users，flood）通常用於編輯者執行大量重複性、無爭議的操作，一般僅允許人類手動使用。

此用戶組的用戶進行任何操作時都會添加「機」的標註（bot flag），即不希望在Special:最近更改刷屏的同時能確保不需要檢查編輯是否有誤。

權限

  • 將其視為自動程序 (bot)
  • 不受使用頻率限制 (noratelimit)
  • 移除自己帳號中的多個群組：機器使用者

申請與授權

管理員在進行部分無爭議、機械式的操作時，可授予自己臨時的機器使用者用戶組。 非管理員亦可在需要手工執行大量無爭議、機械式，且無法由全自動化程序執行的工作時，可在權限變更版或維護組內部申請此用戶組。 一般不建議非維護人員或非技術人員申請此用戶組，您可以至討論版請求維護人員協助。

申請時應遵守如下規範：

  • 應儘可能使用主賬戶申請並進行工作；
  • 應列明工作內容及工作時間；
  • 應註明進行手動或半自動工作。若進行半自動工作，還應說明任務使用的半自動化工具及其預定之編輯頻率。

經管理員審查無誤後授予申請人臨時的用戶組。

特別地，符合以下情形時，管理員不必自授權機器使用者用戶組：

  • 對指定用戶的貢獻進行大量回退時，可直接在用戶貢獻頁面URL後方添加&bot=1，此時再點擊回退可直接視為機器使用者。
  • 使用Special:替換文本進行替換文本，並取消勾選「通過Special:最近更改和監視列表通知這些編輯」，其編輯記錄將在最近更改中強制隱藏。
  • 使用Special:批量正則編輯進行替換文本，默認為機器使用者，其編輯記錄可以在最近更改中被手動強制顯示。

使用規範

當用戶屬於此用戶組時，應該只進行預先獲批准的操作。預定之操作執行完畢後，應立即自行除去機器使用者用戶組。

用戶通過Api執行相關操作時，應主動打開bot flag，否則將不會被識別為機器使用者。[增 6]

此外，若用戶使用自動維基瀏覽器(AutoWikiBrowser)執行相關操作，需在任何可以附加標籤的操作時附加AWB標籤；若用戶使用其他半自動輔助工具執行相關操作，則需在任何可以附加標籤的操作時附加Automation tool標籤。

急停

急停是指機器使用者做出不被許可或意料之外的行為導致負面後果時，為避免影響擴大，由維護組成員給予臨時封禁等措施。

符合以下任一急停條件的，應當執行急停程序：

  • 執行了大量申請內容之外的工作或大量理應在最近更改顯示的操作，但短期少量、註明測試且自行還原結果的操作可以被容忍；
  • 若使用AWB或其他半自動輔助工具，一小時內作出的操作中超過30%（且超過5項）出現嚴重錯誤，需要人為修正。

注意：替換文本無法使用封禁或移除用戶組進行緊急止損，目前僅有濫用過濾器可阻止相關操作。

除權

當執行完所有需要機器使用者的操作時，應立即除去自己的機器使用者用戶組。

除此外，符合下列任一條件的機器使用者將進入除權程序：

  1. 機器使用者執行完任務後忘記取消此用戶組；
  2. 機器使用者執行了理應在最近更改顯示的操作；
  3. 非管理員機器使用者執行了未批准的操作;
  4. 機器使用者經維護人員質詢後不再需要此用戶組。

管理員可直接對符合上述情形的機器使用者進行除權；若違反第3條規定，管理員可同時視情形對相關用戶進行警告或封禁，此類行為可能被視為破壞。

機器人（修訂）

  • 序言「機器人賬戶一般只允許由自動化程序使用，不得由人類手動使用」修訂為「機器人賬戶一般只允許由自動化程序使用，人類手動操作應使用機器使用者」。
  • 權限章節、申請章節特有權限一節的新增內容。
  1. 移動頁面時不在原頁面建立重新導向 (suppressredirect)

一小時內作出的操作中超過30%（且超過5項）出現嚴重錯誤，需要人為修正。

  • 修訂提權章節的序言和提權條件。

提權是指授予機器人管理員、巡查姬、介面管理員或技術編輯員用戶組，不得授予行政員權限。

提權條件

符合以下任一提權條件的，可以申請提權：

  1. 所有者為維護組成員時，可以任意申請提升其所有機器人賬戶的巡查姬或管理員用戶組，但不得超過自身權限：
    • 管理員可申請將機器人提升到管理員或巡查姬級別；
    • 巡查姬僅可申請將機器人提升到巡查姬級別。
  2. 所有者為技術類用戶組成員時，可以申請提升其所有機器人賬戶的介面管理員或技術編輯員用戶組，但不得獲取自身不具有的權限：
    • 介面管理員可申請將機器人提升到介面管理員級別，但需要對其緣由作充分說明；
    • 管理員、介面管理員、指令碼編輯員、技術編輯員可申請將機器人提升到技術編輯員級別；
  3. 若所有者確有提升到超出自身權限的必要，可以申請提權，但需要對其緣由作充分說明：
    • 如一位非維護組成員開發了清理部分頁面的受損文件鏈接的機器人，但這些頁面有一部分被保護到巡查姬級別，此時就可以申請提升機器人到巡查姬級別。
  • 修訂降權章節的序言和提權條件。

降權指的是被授予管理員、巡查姬、介面管理員或技術編輯員用戶組的機器人因不符合提權條件後被除去相關權限。

降權條件

符合以下任一降權條件的，應當進入降權程序：

  • 通過提權條件第1、2條獲得提權，但所有者已經不再持有對應權限：
    • 如管理員申請授予機器人管理員權限的，該管理員失去管理員權限時，該機器人將被降權；
    • 由於管理員權限包含巡查姬、技術編輯員所有權限，不應將管理員視為不持有此類權限；
    • 但若所有者系因活躍度低失去權限，且機器人運作良好且仍然必須持有權限，則可暫緩降權，直至機器人完成任務、其他所有者活躍的機器人能完全替代該機器人完成任務或發生故障為止。
  • 機器人在提權程序中所指明的任務之外使用權限：
    • 這包括但不限於機器人超出範圍的使用權限，以及所有者登錄機器人賬戶手動使用相關權限，但短期少量、註明測試且自行還原結果的操作可以被容忍。

注意：

  • 通過提權條件第3條獲得的權限不隨所有者權限變化而降權；
  • 如果所有者失去了相關權限卻仍然需要機器人持有權限，則需重新申請。
  • 除權條件「機器人賬戶持有的維護組權限」修改為「機器人賬戶持有的附加用戶組及其權限」。

IP封鎖例外者

暫不創建本頁面，保護級別為[創建=僅允許管理員]。

此用戶組僅擁有「繞過IP封禁、自動封禁和段封禁 (ipblock-exempt)」的權限。 當用戶受其他用戶的IP封禁影響時，可通過封禁申訴或其他渠道說明，經使用者查核員進行確認後，可授予IP封鎖例外者用戶組（一般情況下不建議時長超過對應IP的封禁到期時間），相關政策應在萌娘百科:使用者查核方針完善後落實。

分身賬戶方針（修訂）

修訂「主賬戶的認定」一節第3條「人事用戶組級別最高的賬戶是主賬戶」： 修訂為

  • 用戶組級別最高的是主賬戶：
  • 用戶組級別如此排序：持有官方用戶組的賬戶 > 同時持有榮譽用戶組和技術類用戶組之總數最多的賬戶 > 自動確認使用者 > （非確認）用戶。其他用戶組不考慮。

修訂「何時可以使用分身賬戶」一節「單一賬戶權限」： 修訂為

  • 目前，只有行政員、使用者查核員、監督員、管理員、巡查姬、介面管理員、指令碼編輯員是同一自然人僅一個賬戶可以持有的用戶組（依照萌娘百科:機器人#提權的規定進行提權的除外）。

投票方針

在萌娘百科，投票制度是作為社群內遭遇重大分歧或爭議且無法達成一致時，取得進展的一種手段。投票制度能夠讓萌娘百科的用戶在獲得足夠人數和支持比例的前提下，修訂萌娘百科中特定的方針、指引，以達成（多數人認可的）共識。

本文所述提案包括指萌娘百科:提案與萌娘百科:快速提案[刪 3]；

本文及萌娘百科各方針指引論述文件所稱維護人員人事案包括行政員、管理員的申請，和行政員、管理員、巡查姬的彈劾；技術人員人事案包括介面管理員、指令碼編輯員申請。

基本政策

  1. 可發起/參與人事案或提案、有票權的用戶必須是自然人；
  2. 投票參與者有義務知曉人事案之重要性或理解提案內容後再投票；
  3. 可發起/參與人事案或提案、有票權的非維護人員須滿足以下條件：
    • 必須是主賬戶；
    • 30日前（以發起人事案或提案時起計，下同）已成為自動確認使用者；
    • 60日前到投票結束的期間內無因觸犯萌娘百科:方針#用戶封禁政策和其它方針有關封禁規定而被封禁之記錄；
    • 過去30日內在萌娘百科（主，模板Template，分類Category，幫助Help，萌娘百科Project名字空間頁面）有編輯行為；
    • 若在人事案或提案發起後、投票結束前因觸犯萌娘百科:方針#用戶封禁政策和其它方針有關封禁規定而被封禁，視為無效投票。
  4. 投票區格式：
    • 投票區開頭應說明投票規則，使用{{投票}}標明投票起始、截至時間點；
    • 投票區應按照用戶組劃分區域，以方便用戶組票權的核查統計；
      • 例如，提案設立四個三級標題「管理員」「巡查姬」「參與討論的自動確認使用者」「無票權用戶意見」。
  5. 投票專用定義：
    • 各項投票政策中所述的「以上」「以下」，包括本數；「超過」「不足」，均不包含本數；
    • 總票數指參與投票的用戶的票權數總和；
    • 維護人員總票權數指除被彈劾人外（若有），所有管理員和巡查姬的票權數總和；管理員總票權數指除申請人外（若有），所有管理員的票權數總和；
    • 維護人員參與率以參與人數而非投票權重計。
  6. 投票通知：
    • 投票開始時，應使用{{大召喚術}}通知全體有票權的維護人員；
    • 距離投票結束不足3日時，管理員（或其機器人）應通過用戶討論頁通知未參與投票的維護人員。
  7. 有效票種為(＋)同意 、(∅)棄權 、(－)反對 ，其餘選項視作未參與投票且不計入參與人數；
    • 無理由投同意/棄權/反對票視為未參與投票；
    • 投票未簽名或簽名不規範視為未參與投票；
    • 意見長度應限制在140字以內，超過長度請寫在討論區。
  8. 維護人員投票政策：
    • 投票權於發起投票時的用戶組確定。即投票開始後獲得/失去管理員、巡查姬用戶組的用戶，依然按發起投票時的用戶組權限計算票權；
      • 通過快速降權程序降權為巡查姬的原管理員，仍應按管理員用戶組計算票權。
      • 投票權重不可分割，分割投票視作未參與投票且不計入參與人數；
  9. 投票一般持續7日，如7日內無中國大陸法定節假日或周末休息日，則延長投票結束日期直至包含法定節假日或周末休息日一日以上；
  10. 未投票者不得補票。

違規行為

  1. 在30日內連續對同一個維護人員發起的彈劾案，及同一個用戶連續對多個維護人員發起的多個彈劾案，行政員有權在考量其合理性後，對這些彈劾案進行合併或駁回處理，並警告提起彈劾案的相應用戶，情節嚴重（如明顯構成騷擾行為）的可在警告無效後進行封禁處理。
  2. 任何人不得以威脅、賄賂、私下交易、人身攻擊等手段影響投票。如果發現則對操縱者和受賄者進行永久封禁懲罰，涉及到的投票一律視為無效票（即去掉對應投票，下同）。
  3. 一位自然人當且僅當投票一次。發現使用多賬號擾亂提案投票者時，應當將該自然人所控制賬戶的所有投票視作無效票，並視情形對其所有或部分賬戶進行永久封禁。
  4. 修改他人投票的，警告並責令其被修改的投票恢復原狀，投票結束前拒不改正的，視情形由維護人員改正其賬戶處以30日以下封禁。
  5. 冒充他人投票的，應當將該冒充者的所有投票視作無效票，並由維護人員對其賬戶處以30日以上封禁，同時進行嚴重警告。

其他

  1. 用戶權限調整應同時應用於中文萌娘百科、萌娘共享、萌娘文庫、英文萌娘百科、日文萌娘百科；
  2. 停用「小部件編輯者」、「developer」、「steward」、「刪除執行員」用戶組，並在此提案通過後、後台調整用戶權限體系前將所有用戶移出前述4個用戶組。
  3. 將萌娘百科:巡查姬的巡查任務重命名為萌娘百科:維護人員的維護任務，並適當修訂更新；
  4. 將萌娘百科:程序員招募中變更為失效文檔；
  5. 將萌娘百科:提案中涉及投票的規則移除，改為指向萌娘百科:投票方針[增 7]。

修訂注釋區

增

  1. ↑ 封禁IP時會無可避免的公開破壞者的ip信息，故豁免，下同。
  2. ↑ 補充使用者查核員的維護禁忌
  3. ↑ 3.0 3.1 按此前維護組群內的討論進行補充。
  4. ↑ 增補一條優編去職條件。
  5. ↑ 5.0 5.1 補充評估人。
  6. ↑ 補充機器使用者的使用說明
  7. ↑ 非實質性調整。

刪

  1. ↑ 刪除本句。
  2. ↑ 刪除本句。
  3. ↑ 還沒有快速提案方針。

改

  1. ↑ 小修改。
  2. ↑ 2.0 2.1 修復轉寫時的錯誤
  3. ↑ 小修改，寫清是主動發放。
  4. ↑ 4.0 4.1 4.2 4.3 非實質修改，修改表述
  5. ↑ 5.0 5.1 5.2 5.3 5.4 非實質修改，修改表述
  6. ↑ 6.0 6.1 非實質修改，修改表述

討論區

關於機器使用者的實現

機器人標識需要通過在進行操作時在url中添加&bot=1實現，而若申請的目的是為了手動修改大量頁面、調整分類等情況時，在每次修改前手動修改url反倒會造成效率的極大降低。所以在推出此用戶組前，我覺得應當先引入一個能夠自動在執行操作時添加&bot=1標識的小工具。否則此用戶組也只有在使用腳本或是半自動工具時有意義，而這和機器人用戶組差別並不大。--SinonJZH(๑•̀ω•́๑)(討論) 2021年11月17日 (三) 19:25 (CST)

不用小工具應該，屆時可以直接寫在Mediawiki:Group-flood.js里。—— ほしみ 2021年11月17日 (三) 20:41 (CST)
不對啊，屬於這個用戶組之後，如果不通過api、在站內執行手動操作，自動就會標註「機」flag。—— ほしみ 2021年11月17日 (三) 20:57 (CST)
啊這，我似乎沒有看到有使用此用戶組就會自動添加bot標記的相關說明……但如果有的話那就沒問題了。--SinonJZH(๑•̀ω•́๑)(討論) 2021年11月18日 (四) 00:03 (CST)
emmm...移動、刪除、通過默認編輯器編輯的編輯會自動帶上bot flag，wiki+/ipe等小工具沒有開啟bot=true就不會帶flag。這需要修改相關工具，改url沒啥用（
推薦使用AWB，有bot flag的可選開關—— ほしみ 2021年11月18日 (四) 01:13 (CST)

關於「IP封鎖例外者」的疑問

剛好之前也在討論版發過這個問題，所以特地看了一下這個新添加的用戶組。不知是由於個人原因還是萌百的原因，先前編輯遭遇IP封禁時顯示的「尋求幫助」按鈕貌似是直接指向一個新的討論串（或者頁面？裡面只有幾行被注釋化的代碼）的，然而這個討論串或頁面由於IP被封無法被編輯，只能繼續點擊「尋求幫助」按鈕，隨後便進入了無窮無盡的套娃時間……所以IP被封禁的情況下無法在站內發送封禁申訴是真的嗎

到時倘若使用者查核的各項工作完成，是否通過查核在被封禁IP下的破壞者和申請者不是同一個人就可以申請這個用戶組了？

( ¡ )題外話 受到我學校某位破壞者的影響，學校的某棟樓的某幾個特定的校園網wifi仍然無法編輯萌百……所以一旦這個用戶組建立起來我肯定第一個申請（確信）

以上。 --花落丿天使→瘡痍之路File:殘機素材.pngxFile:Bomb素材.png冷清茶舍 2021年11月17日 (三) 20:27 (CST)

(▲)同上 同一個校園網的受害者（——Mj2p.gif這是一張遺漏的二餅（請聯繫失主） 2021年11月18日 (四) 08:03 (CST)
看了一下，封ip一般都沒有封禁討論頁，不太可能無法申訴。並且和您使用同一個校園網的用戶有正常提出過申訴，參見User talk:Hal9000。—— ほしみ 2021年11月19日 (五) 01:52 (CST)
@星海子那或許是我的打開方式不對（我只是點擊了那個「尋求幫助」就無限套娃了）。下次再遇到我會仔細觀察過程，如有疑問我會去討論版提問。 --花落丿天使→瘡痍之路File:殘機素材.pngxFile:Bomb素材.png冷清茶舍 2021年11月19日 (五) 21:21 (CST)

為什麼管理員的申請難度比行政員更大

我發現管理員的通過要求里有「管理員反對票占管理員總票權數之比不足1/2」這一項，等級更高權限更大的行政員卻沒有這方面的要求，這是為什麼？--北湖3（討論） 2021年11月17日 (三) 22:21 (CST)

粘貼錯地方了…寫到彈劾那節了（ 過會兒修正一下—— ほしみ 2021年11月17日 (三) 22:47 (CST)

關於行政員的部分疑問

  1. 關於行政員兼任使用者查核員、監督員的問題
  2. 關於AnnAngela和雲霞的職務的問題

——C8H17OH（討論） 2021年11月18日 (四) 00:13 (CST)

  1. 還沒怎麼考慮使用者查核和監督，目前的行政員行為規範中寫沒提這兩個用戶組的具體使用，只在申請中有簡單提及。
    我倒是覺得使用者查核和監督員應該也和一樣是管理員的附加用戶組，應該允許單獨申請、組合申請。
    我認為使用者查核員的具體內容交由相關專案就好，之後通過了就來修訂這裡嘛，問題不算太大；監督的我打算先緩緩，我覺得並不是那麼迫切（我懶了）（
  2. 是，按照最初baskice的提降權日誌，Ann和雲霞應該是「臨時行政員」，那麼他們仍應通過投票成為正式行政員。只有管理員申請的投票規則更改會影響他們的管理員復職程序，其他不影響。
—— ほしみ 2021年11月18日 (四) 01:46 (CST)
第1個問題已理解。第2個問題，考慮到本提案如通過可能早於兩位行政員的管理員復職程序開始，如果如此，他們是需要先完成管理員復職，才能進行行政員的正式申請程序嗎？——C8H17OH（討論） 2021年11月20日 (六) 23:21 (CST)
管理員復職和行政員申請確實是兩個程序，我是這麼想的。如果要立即申請正式的行政員，目前唯一的問題在於兩位臨時行政員可能無法達成「連續擔任管理員任滿6個月」這一要求，可能得想辦法豁免一下。你這邊怎麼想呢？—— ほしみ 2021年11月20日 (六) 23:58 (CST)
草，我都沒注意到這個問題。那或許可以考慮給兩位現任行政員特別設立一個臨時程序，比如豁免六個月條件，或者將行政員和管理員的當選程序合併，反正公告允許通過提案提出其他方案來代替管理員復職程序。畢竟他們一直擔任行政員（無論是不是「臨時」或者「代理」），顯然是相當受信任的，因此特別設立一個程序也並非不可。——C8H17OH（討論） 2021年11月21日 (日) 00:07 (CST)
或許也可以，但其實我覺得沒太大必要（要不你寫一個特別程序？），從程序規範上來說確實是走兩次比較好。但如果要這麼做，可能必須進行提問程序而非僅僅進行投票程序了吧？不然還是給人一種現任維護組硬點的感覺。—— ほしみ 2021年11月21日 (日) 00:33 (CST)
等六個月倒也無妨，反正至少現在還在臨時任職，不會產生行政員缺位的問題。特別程序的話……其實可以考慮，比如說，在豁免六個月條件的前提下，允許跳過管理員復職而直接發起行政員申請程序（包含問詢程序），畢竟發公告時管理員申請的投票還是傳統的2+1票權模式；不過考慮到提案通過後管理員申請會變成4+2+1，這樣的話確實會有維護組「欽點」的嫌疑，所以大概還是也可以不搞特殊程序。——C8H17OH（討論） 2021年11月21日 (日) 00:59 (CST)
還是2+1，但兩個用戶組要求的同意票數是不一樣的，你可能看成了彈劾（？ 如果直接發起行政員程序有一個問題，萬一（我說萬一），萬一真的沒有通過，要怎麼授權呢（？ 可能最不複雜的就是豁免六個月或者什麼都不動吧—— ほしみ 2021年11月21日 (日) 01:12 (CST)
哦，記錯了（）那要不就先不管了（——C8H17OH（討論） 2021年11月21日 (日) 01:22 (CST)
這種情況下可以用最終決定權跳過嗎——Mj2p.gif這是一張遺漏的二餅（請聯繫失主） 2021年11月22日 (一) 08:59 (CST)

質疑此提案是否符合方針

@星海子 根據萌娘百科:提案#發起條件，這個與萌娘百科_talk:提案/未通過提案/關於用戶權限體系調整的提案(2021.10.08)有大量相似內容的提案不應被重複發起。我認為應該移除所有關於功能用戶組的內容，留待期限滿足後重新討論。——移動版用戶 Bhsd 2021年11月18日 (四) 04:34 (CST)

兩個提案並非完全相同，未通過提案是在不變更現有體系的前提下新增部分用戶組，當前提案是對整個用戶權限體系的更新，主題相似但內容、目的不同。借用anna在萌娘百科_talk:提案/已通過提案/關於移除權限申請中『萌娘百科的提問』段落的提案(2020.10.03)中的解釋，「關於「相同或相似的提案」，不能從形式上去判斷，說只要兩個提案關於同一主題就算相似，而是應該從實質出發，是否能達到實質性相似的程度，也就是目的和手段的本質都相似才應該認為是相似提案，「相同」以此類推。」—— ほしみ 2021年11月18日 (四) 04:43 (CST)
那就請把實質上相同的部分移除出去。——移動版用戶 Bhsd 2021年11月18日 (四) 04:45 (CST)
應以整個提案是否相似為判斷，而不是其中的一部分。—— ほしみ 2021年11月18日 (四) 04:53 (CST)
有玩文字遊戲鑽空子之嫌。——移動版用戶 Bhsd 2021年11月18日 (四) 04:58 (CST)
這個時候我倒覺得不應該以此為依據反對本提案——不僅本提案事實上對萌百有好處，而且上一個相似版本未通過的原因並非社群或維護組反對。
雖然沒有「不墨守成規」作為「方針」可用，但是我尋思對應21專案子案的廣泛討論足以證明本提案的積極作用——也有可能能提供足夠的支持本提案正常進行的觀點。
懂了，這就寫提案修改「投票後未通過」和「發起者撤回」分別對待（不是 — STICK TOGETHER用戶名是公的驅逐艦的 壹陸 討論·最近編輯 2021年11月18日 (四) 13:39 (CST)
@公的驱逐舰 那就請先去改方針。——移動版用戶 Bhsd 2021年11月18日 (四) 14:16 (CST)
(－)不支持 這好比汽車裡裝了椅子，所以認為汽車和椅子相似，建議把椅子拆掉或者直接報廢汽車一樣。——Mj2p.gif這是一張遺漏的二餅（請聯繫失主） 2021年11月19日 (五) 11:29 (CST)

關於彈劾行政員

是不是應該添加一句「對行政員的彈劾案不得利用最終決定權干預」，雖然實際不太可能發生但是為了體現迴避原則還是加一下。——Mj2p.gif這是一張遺漏的二餅（請聯繫失主） 2021年11月19日 (五) 11:02 (CST)

最終決定權的一般行使情境中不含前述情形，且行政員無法單獨干預此類人事案。如果確實出現了無可避免地需要行使該權力的情況，也未必不會出現確實需要干預的情形。我覺得沒必要在這裡加，在最終決定權那邊限制好就可以了（加了彷彿行政員是什麼大惡人似的。—— ほしみ 2021年11月19日 (五) 13:41 (CST)
其實來這邊提這事兒就是因為現行方針其實也沒有彈劾行政員程序，不好直接在提案裡面寫不相關且不存在的東西，只能來這邊提了（——Mj2p.gif這是一張遺漏的二餅（請聯繫失主） 2021年11月19日 (五) 20:54 (CST)
我覺得應該在你那邊進行限制，限制在非極特殊情況下最終決定權不能做什麼。—— ほしみ 2021年11月21日 (日) 00:00 (CST)
雖然在這匯報感覺怪怪的，但是完成——Mj2p.gif這是一張遺漏的二餅（請聯繫失主） 2021年11月22日 (一) 08:49 (CST)

一些小疑問

  1. #維護人員的基本義務→維護禁忌中，「不允許參與任何涉及編輯獎勵的編輯」，是僅包括了受託進行編輯，還是同時包括了委託或受託進行編輯？
  2. #巡查姬→考核中，「申請人可選擇不超過5個問題進行回答」的限制有何原因？
  3. #榮譽維護人員→授權程序中，「此用戶組設立前，符合授權條件的前任維護人員」一條似乎有點難懂，具體指的是什麼情況？和下一條的「回溯發放」的區別是什麼？

——Krypton glow (Talk) 2021年11月21日 (日) 00:06 (CST)

  1. 兩者都。不可以又當運動員又當裁判員；
  2. 本身巡查姬沒有提問程序，隨着遴選標準的提高，此前總有維護人員會進行提問。考慮到社群對巡查姬的潛在能力要求，這次明確設立了可提問的環節，但又考慮巡查姬的回答壓力，增加了一些限制，回答少量問題、選擇自己能回答的進行回復應該是可以且應當的。
  3. 這用戶組設立還沒太久，很多歷史上的維護人員沒有獲得、但也可能希望獲得這個榮譽稱號。即滿足「已任或曾任維護人員滿90日，最後一個任期最後90日內不活躍警告次數不滿2次，因不活躍自動去職」條件，在討論版申請這個稱號的用戶可獲得這個稱號。回溯指的是主動回溯，已修復。
—— ほしみ 2021年11月21日 (日) 00:26 (CST)

小修改

除了剛剛被回退的那些變更希望提案人能夠考慮一下以外，「維護組群」應做「維護人員群組」，另外濫用過濾器維護員頁面直接提升為政策應該沒問題？其他一些詞語不統一跟贅詞就放著不管了，畢竟不自己改一個一個提出來太麻煩，自己改了又會被回退，所以隨便啦。—— Eric Liu 創造は生命（留言） 2021年11月22日 (一) 16:40 (CST)

(ｉ)注意 提案正文只允許發起人修改，其次不應該使用二級標題作為你發起的討論段落標題，我已經替你修改了。——Mj2p.gif這是一張遺漏的二餅（請聯繫失主） 2021年11月22日 (一) 20:51 (CST)

關於維護人員收費編輯

參見：zhwp:對維基百科涉及利益衝突的編輯

萌娘百科_talk:提案/討論中提案/關於用戶權限體系更新的提案#維護禁忌提到：

1.不允許參與任何涉及編輯獎勵的編輯，收費刪除（或美化/詆毀）的行為被嚴厲禁止；
2.不得在站外以萌娘百科維護人員等名義進行罵街、打嘴炮、引戰等行為；

就第一點來說，利益相關不一定導致有失偏頗。對於收費編輯，應該從編輯行為本身是否符合萌娘百科的中立性要求、質量要求和寫作風格來評判，而非質疑其動機。萌娘百科應當反對不中立和低質量內容，而非收費編輯。

另外，什麼是「編輯獎勵」也很值得考慮。不過萌娘百科:編輯獎勵方針還尚未創建，我只能猜了：①只有金錢算，②現實的一些物品和行為也算，③虛擬世界的一些信息（如遊戲貨幣、照片文字）也算。

如果規範不清，可能有被濫用的風險。而且考慮到僱傭者可能也會反偵察（如使用QQ電話等不留痕跡交流方式而非會留下證據的文字聊天），禁止收費編輯的意義更渺茫了。

第二點來說，萌娘百科的一切獎賞理論上都應該圍繞用戶在站內的行為，將管轄範圍擴展到站外是不合適的。另外，如果真的要破格這麼規定，「罵街、打嘴炮」也有點太口語化了，建議改為「侮辱誹謗他人，發表一般社會道德規範所不能接受的言論」——以上未簽名(註)本條留言未簽名，留言後請記得用--~~~~簽名！的留言由Caibeyan（討論·貢獻）於2021年11月25日 (四) 00:37‎ (CST)添加。

投票區

正在加載中……
  • 投票開始時間： |
  • 投票結束時間： |
  • 投票總用時 7 天，正在計算中……

截至目前，用戶權限體系更新相關的內容已經在專案和本頁面討論了25天，且相關內容近期無較大變動，故開啟投票程序。@蓝羽汇，弗霖凯，Lyhic，星海子，Sivlovski，AkizukiSaitou，Rg224，Hlwan03，Luenshi007，Bbrabbit，宇文天启，平塚八兵衛，空翊，サンムル，Vcfch843875618，HetmesAskalana，不是液氮，Func，红石小蝈，Xzonn，C8H17OH，Chko08022003，Bete1geuse，月 樱 雪，Leranjun，玄微子，一位史蒂夫，小乃，Qaolp0，LUO1P，TsanconBYin，公的驱逐舰，泠佛.，西尾哈鲁卡，Siw19981998，Wrong Scenario —— ほしみ 2021年11月24日 (三) 17:13 (CST)

補ping一下還沒有參與投票的有票權的自動確認使用者@花落丿天使，bhsd，Krypton glow—— ほしみ 2021年11月24日 (三) 23:05 (CST)

管理員

同意
  1. (＋)同意 本次用戶權限體系更新是符合站點發展趨勢的，但其中仍有一些潛在的問題和不足之處。若能通過，我會在實施一段時間後發起修正案。—— ほしみ 2021年11月24日 (三) 19:08 (CST)
  2. (＋)同意 從內容向的角度來看，我認為我所可理解的相關權限調整在當下並無問題；然而，顯然地，這份更新在之後勢必需要更多修正案的修正。不過就當下來看，這份冗長的提案已經做到很多了。--Thus Spoke Sivlovski.「討論」 2021年11月27日 (六) 19:08 (CST)
  3. (＋)同意 加把勁.--飢餓之聲-弗霖凱（討論） 2021年11月28日 (日) 13:14 (CST)
  4. (＋)同意 朝着更完善的方向邁出了一步。--Lyhic（討論） 2021年11月28日 (日) 23:27 (CST)
  5. (＋)同意 這也算是災後重建了。——絲毫沒有存在感的某藍色管理員（討論） 2021年11月30日 (二) 22:41 (CST)
反對
棄權

巡查姬

同意
  1. (＋)同意 或許還有問題，但是作為大規模修訂已經相當完備了。——Mj2p.gif這是一張遺漏的二餅（請聯繫失主） 2021年11月24日 (三) 17:39 (CST)
  2. (＋)同意 較之之前的版本有了更為完整的架構，對自動確認使用者有權參與管理員罷免案的修正表示歡迎。-- Wrong Scenario (討論·貢獻) 2021年11月24日 (三) 17:42 (CST)
  3. (＋)同意 沒有理由不同意。——From 泠佛. (討論) 2021年11月24日 (三) 17:53 (CST)
  4. (＋)同意 沒啥好說的—— 冬月下的二重奏 LUO1P✾ 2021年11月24日 (三) 18:13 (CST)
  5. (＋)同意 符合當前發展趨勢——From 月_櫻_雪 (討論) 2021年11月24日 (三) 18:36 (CST)
  6. (＋)同意 有點複雜，不過應該沒啥大的問題 -- 宇文西修ิิۣۣۖۖۖ特拉瑟☺ 2021年11月24日 (三) 19:08 (CST)
  7. (＋)同意 沒大問題，我比較期待新增介面管理員、指令碼編輯員、技術編輯員這三個新用戶組為萌百所帶來的變化。--By CHKO (Talk) @ 2021年11月24日 (三) 19:23 (CST)
  8. (＋)同意 整理之後會更加清楚。--由使用者樂然（議）撰於 2021年11月24日 (三) 23:02 (CST)
  9. (＋)同意 提案的主題已經歷上個提案、專案、本次提案三個階段，在站內外已廣泛徵求意見。儘管對於部分細節可能尚存爭議，但整體上是符合共識的，且有益於萌百的發展進步。後續如發現需調整，再提修正案也不遲。感謝提案發起人一直以來的推動努力。——C8H17OH（討論） 2021年11月25日 (四) 01:02 (CST)
  10. (＋)同意 積極的修正。——From 引夢者濁華(討論) 2021年11月25日 (四) 13:23 (CST)
  11. (＋)同意 對此次修訂持樂觀態度。剩下的問題就在實際運用中調整吧。--Qaolp0 with nightmare (討論) 2021年11月25日 (四) 14:32 (CST)
  12. (＋)同意 對此次修訂表示歡迎！——From 西尾哈魯卡 (討論) 2021年11月25日 (四) 21:57 (CST)
  13. (＋)同意 目前看來並無大問題，其餘的實行後再修正即可。 --空翊（留言） 2021年11月26日 (五) 00:05 (CST)
  14. (＋)同意 用戶組確實需要一次大的更新。--bbrabbitからの評論 #討論# 2021年11月26日 (五) 11:10 (CST)
  15. (＋)同意 個人表示支持。--Vcfch843875618（討論） 2021年11月26日 (五) 17:24 (CST)
  16. (＋)同意：已經很完善了, can't agree more.———— LN2 不是液氮 (討論•貢獻) 2021年11月27日 (六) 18:39 (CST)
  17. (＋)同意 沒有不同意的理由。--Bete1geuse（討論） 2021年11月27日 (六) 23:09 (CST)
  18. (＋)同意 希望這些調整能讓更多有能力的用戶充分發揮自己的能力。——Xzonn（聊天） 2021年11月28日 (日) 08:29 (CST)
  19. (＋)同意 無意見--極樂賽博宮醬 2021年11月28日 (日) 14:28 (CST)
  20. (＋)同意 樂見修訂-- 小乃 (討論) 2021年11月29日 (一) 17:26 (CST)
  21. (＋)同意 可能是利益相關，不過現在怎樣都好了。--存在即是罪惡的 Func（討論·貢獻） 2021年11月29日 (一) 22:58 (CST)
  22. (＋)同意 就像從三菜一湯變成了年夜飯，好看又好用。--サンムル（討論） 2021年11月30日 (二) 16:14 (CST)
  23. (＋)同意 沒有意見--已經是一條死魚的HetmesAskalana 2021年11月30日 (二) 19:50 (CST)
  24. (＋)同意 內容已經很詳盡了。-- Welcome to the Hotel California 2021年12月1日 (三) 06:23 (CST)
反對
棄權

參與討論的自動確認使用者

同意
  1. (＋)同意 較之前版本不僅僅局限於技術系用戶組，而且對巡查和優編下放了一些權限，並修正了管理員投票的「管理員參與率」等不合理規定，還增加了行政員授權/除權程序——北湖3（討論） 2021年11月24日 (三) 18:47 (CST)
  2. (＋)同意 可行。（不知道為什麼要寫理由不過嘛青菜）—— Eric Liu 創造は生命（留言） 2021年11月24日 (三) 19:19 (CST)
  3. (＋)同意 太長不看（完善了權限體系，支持，但部分內容在執行中可能尚需修訂。PS，@星海子好像忘了@自確了（--SinonJZH(๑•̀ω•́๑)(討論) 2021年11月24日 (三) 21:32 (CST)
  4. (＋)同意 我看不懂，但我大受震撼表示絕對支持，只要是為社群有利的為何不同意呢並且若能通過我第一個申請IP封鎖例外 --花落丿天使→瘡痍之路File:殘機素材.pngxFile:Bomb素材.png冷清茶舍 2021年11月25日 (四) 07:27 (CST)
反對
  1. (－)反對 理由見討論。——移動版用戶 Bhsd 2021年11月30日 (二) 04:40 (CST)
棄權

無票權用戶意見

同意
  1. (＋)同意 ，更新很重要，而且彌補了大量體系漏洞。在專案參與了討論的算不算參與討論啊（——「今日も一日がんばるぞい！」(沼澤 • 討論) 2021年11月24日 (三) 18:29 (CST)
  2. (＋)同意 好！--wenzuxiaot（talk）· Stick together! 2021年11月24日 (三) 18:40 (CST)
  3. (＋)同意 無異議 —— GreenHal Talk with me now~Blue Bird.png 2021年11月24日 (三) 21:43 (CST)
  4. (＋)同意 整體來說沒有什麼問題。—— DaiGui（討論） 2021年11月25日 (四) 08:24 (CST)
  5. (＋)同意 沒有大的問題。話說我有投票權嗎？--File:蘇維埃國旗.jpg社會主義陣營支持者Jingkela1123(參加全俄代表大會)(對人民的貢獻) 2021年11月25日 (四) 21:26 (CST)
  6. (＋)同意 無異議--TNLHK（sign|talk） 2021年11月26日 (五) 17:25 (CST)
  7. (＋)同意 雖然大部分都跟維基差不多但還是可以吧。--最低さいていな記憶きおくと蓋ふたを綴とじた　僕ぼくら(廢人|來玩數獨) 2021年11月27日 (六) 10:45 (CST)
  8. (＋)同意 能讓優編覆蓋自己上傳的文件，感覺會很實用。--Nait_Talk 2021年11月27日 (六) 15:10 (CST)
  9. (＋)同意 善。--流浪者-瀧澤さくね（討論） 2021年11月27日 (六) 17:36 (CST)
  10. (＋)同意 好耶！--W3jc（討論） 2021年11月28日 (日) 23:35 (CST)
  11. (＋)同意 無任何異議。--愛吃麵包的Hooonooka（討論） 2021年11月30日 (二) 02:45 (CST)
反對
棄權
  1. (∅)棄權 不知道幹了啥，反正也沒票權。--SD hehua（討論） 2021年11月24日 (三) 17:50 (CST)
  2. (∅)棄權 我等修正案下鍋。—— 屠麟傲血（討論） 2021年11月24日 (三) 23:14 (CST)


計票與結論

根據萌娘百科:提案：具有投票權的用戶為：【管理員】、【巡查姬】、在討論階段參與了提案討論的已註冊達30天、遵守方針的活躍【自動確認使用者】。在提案有至少2位管理員參與投票時，【投票有效】。

  1. 投票開始時共有5名參與站務的管理員；其中，
    • 5人(＋)同意 ，
    • 0人(－)反對 ，
    • 0人(∅)棄權 。
  2. 投票開始時共有31名正式巡查姬；其中，
    • 24人(＋)同意 ，
    • 0人(－)反對 ，
    • 0人(∅)棄權 ，
    • 7人沒有參與投票（Hlwan03、Luenshi007、平塚八兵衛、紅石小蟈、一位史蒂夫、公的驅逐艦、Siw19981998）。
  3. 共有5名有票權的自動確認使用者參與了投票；其中，
    • 4人(＋)同意 ，
    • 1人(－)反對 ，
    • 0人(∅)棄權 。
  4. 另有13位無票權用戶發表了意見。

當前提案有5位管理員參與並投有效票，大於等於要求的2名，該提案投票有效。

統計計票結果，全部投票之同意：反對票數量為 33:1，【同意】票數大於【反對】，且管理員的【同意】票數不小於【反對】，【提案通過】。—— ほしみ 2021年12月1日 (三) 17:19 (CST)

取自「https://moegirl.uk/index.php?title=萌娘百科_talk:提案/已通过提案/关于用户权限体系更新的提案(2021.12.01)&oldid=753088」