Wikipedia talk:管理员/存档4

thread_title:  留言 

message: 建議管理員使用權力時必須最少另一位管理員核准無誤方能落實。--218.250.198.229（留言） 2016年8月21日 (日) 04:16 (UTC)
replies: text: 这是个好习惯，最好先与其它管理员讨论然后再执行操作。事实上，之所以快速删除“一人挂板、另一人核准”就是需要两个人判断才能尽可能保证正确。但是有没有人觉得不应该强制要求我就不知道了。或许可以在某些hard task上面加一些非强制性的条款。比如“执行封禁申诉时，请与原管理员讨论。如无法联系到原管理员，强烈建议与另一位管理员交流。”等等。--Antigng（留言） 2016年8月21日 (日) 04:19 (UTC)

text: (！)意見--這增加的是決定成本，而「使用權力」太過管泛，我不確定是否所有的權力需要這樣兩人搭配，請先限定哪些權力。--❦‽研究及來源 hanteng✉ 2016年8月21日 (日) 04:41 (UTC)

text: 這涉及到修改多個方針。例如封禁方針、保護方針、3RR方針等需要管理權限的方針或指引。--秋意假髮濃(我已關閉了所有通知，所以@我看不到)（留言） 2016年8月21日 (日) 04:45 (UTC)
replies: text: :同Hanteng與秋意看法，需要再想想。不過，這一訴求，突顯一個問題，有些管理員在做決定時，疑似連事實都沒搞清楚、也沒有回應用戶及社群質疑的準備、甚至不理會，根本上不符合對管理員「說理」的要求。增加諮詢另位管理員，有一個好處是，用戶及社群有疑問時，另一位管理員也需補充說明。Wetrace歡迎參與人權專題 2016年8月21日 (日) 05:01 (UTC)
replies: text: ::(？)疑問：你的意思是導師制(一個老管理員帶新的?)--秋意假髮濃(我已關閉了所有通知，所以@我看不到)（留言） 2016年8月21日 (日) 05:04 (UTC)

text: 我认为这并没有什么卵用。以目前维基上拉帮结派和抱团打架的现状来看，想使用权力的话找到两个立场相同的管理员不难吧？--20160821ax（留言） 2016年8月21日 (日) 11:05 (UTC)

text: 首先感谢您对计划的爱护。管理员的工作中也有比较没那么大争议的（例如删除侵权条目）和争议比较大的（如封禁）。删除侵权条目时如果要每个条目都要两名管理员确认一遍的话，理论上是很好，但实际上减慢处理堆积的速度，而且让本来已经比较枯燥的工作更加繁琐，增加不必要的维护成本。至于封禁，真正具争议的封禁即使两名管理员处理也未必能服众，尤其在目前的社群氛围下。如果任何人对管理员的操作有异议，现在已经有很多机制处理：封禁申诉、存废复核和请求解除保护页面等等，而且维基百科上大部分操作都可逆，所以希望您或其他人能提出一些更具体的方案供讨论。--Lakokat 2016年8月21日 (日) 11:21 (UTC)

text: 其實樓上的任期制提案與本討論的權力規範都是出自同一個原因：對於部分管理員的不信任。--秋意假髮濃(我已關閉了所有通知，所以@我看不到)（留言） 2016年8月21日 (日) 12:45 (UTC)

text: 「必須最少另一位管理員核准」说来是好，实际上不见得能够解决管理员的信任问题。从近年的管理员选举，管理员解任投票，反复封禁争议，都可看出中文维基管理员及投票用户存在分党分派的情况，处理事件时甚至先看当事人是谁，再找方针指引自行解读。「必須最少另一位管理員核准」只是多一个同声同气的管理员发声，无助于提高争议性封禁或解封的公信力。--Thomas.Lu（留言） 2016年8月21日 (日) 14:56 (UTC)
replies: text: :此一問題必須想出有效辦法根治，逐步排除造成爭議的亂源，不然社群氛圍永遠在惡性循環之中。--秋意假髮濃(我已關閉了所有通知，所以@我看不到)（留言） 2016年8月22日 (一) 07:26 (UTC)

text: (ˉ▽￣～) 切~~，恶化为车轮战之前其实不就是相互检查吗？现在更大的问题是有些人拉帮结派，把自己的人推上神台后就狐假虎威，其实肇事的管理员一旦被质疑，应该立即回应，而不是拒绝回答，要不然给人动机不纯，留下把柄罢了。——路过围观的Sakamotosan 2016年8月22日 (一) 08:24 (UTC)
thread_title: 管理員權力使用的規範

message: 此举旨在防止部分管理员在任期内不按照规矩行事，我知道此提案肯定会遭到大部分管理员和部分既得利益群体的反对，但想了想还是提上来吧。我们选管理员怎么感觉和原始社会选酋长差不多啊，感觉选上之后个个成皇帝了，了不得了呀。我不否认这些酋长里有明君，但也出了个别暴君，即有人说的所谓民主+独裁。所以建议在管理员卸任中，新增一条，在任期上加一个期限。任期为两年或三年，任满后重新选举一次。大家怎么看？--飞贼燕子（留言） 2016年8月21日 (日) 02:26 (UTC)
*(－)反对，浪费时间。不按方针指引来的管理员直接按照解任程序处理，等三年干什么？--Antigng（留言） 2016年8月21日 (日) 02:41 (UTC)
**既然问心无愧，又干嘛怕等三年？--飞贼燕子（留言） 2016年8月21日 (日) 03:41 (UTC)
***浪费时间。zhWP有时间同时开90个RfA？你以为这里是meta的steward 选举或enWP的仲裁员选举？每次仲裁员选举也没有90个人同时选。--Antigng（留言） 2016年8月21日 (日) 03:46 (UTC)
replies: text: 一点都不浪费时间，当谁最初是怎么取得社群信任的，谁就应该在任职期间自然就懂得就应该怎么把社群的信任保持下去。--飞贼燕子（留言） 2016年8月21日 (日) 04:01 (UTC)
replies: text: :对于社群信任的管理员，再开RfA没有意义；对于社群不信任的管理员，有更直接的方法，就是解任投票，也不需要再开RfA。所以再开RfA就是浪费时间，没有好处。--Antigng（留言） 2016年8月21日 (日) 04:03 (UTC)
replies: text: ::是对管理员滥权没好处吧。--飞贼燕子（留言） 2016年8月21日 (日) 04:05 (UTC)
replies: text: :::对管理员滥权反而有好处，原来大家觉得管理员做事情不符合方针，只有立即解任投票一条路；现在大家可能会想，也不解任啦，下次不选他就是了。这反而给了滥权管理员三年时间缓冲。--Antigng（留言） 2016年8月21日 (日) 04:06 (UTC)

text: 現在發生的問題不在於管理員「沒有任期限制」，而是管理員任免投票被「不恰當拉票」和「拉幫結派」嚴重影響。--Mewaqua（留言） 2016年8月21日 (日) 04:10 (UTC)
replies: text: :同樓上意見。另外，我認為根本問題就是管理員的選任不應採取投票制，應採用資格制，我們應該提拔勤於反破壞與巡查工作的維基人方為正辦，擅長寫條目的維基人不見得適合做管理員，近期爭議已證明了這一點。--秋意假髮濃(我已關閉了所有通知，所以@我看不到)（留言） 2016年8月21日 (日) 04:17 (UTC)

text: 用任期制根本就是想無中生有，塑造維基百科內部有個管理員組成的管理階層，那麼以後要不要順便開設人民代表大會、人民法院、黨分部來多重監督？然後先劃定會投反對對象，這樣的提案還真是開放討論。--KOKUYO（留言） 2016年8月21日 (日) 04:11 (UTC)

text: (－)反对先惡意假定管理員有問題所以需要定期任免的制度，有可能導致沒有問題的管理員在刻意的謀劃下被免除職務。會有劣幣驅逐良幣的現象。--健康欠安 (留言) 2016年8月21日 (日) 04:20 (UTC)
replies: text: :(※)注意大家放心，此举不会放弃解任投票，而是增加一条任期制，旨在防止部分管理员在任期内不按照规矩行事，我知道此提案肯定会遭到大部分不守规矩的管理和部分既得利益群体的大力反对，但为了长久之计，请大家务必认真考虑。--飞贼燕子（留言） 2016年8月21日 (日) 04:22 (UTC)
replies: text: ::当然不会取消解任投票。但是不管怎么说，任何人提解任投票是需要有勇气的，而且要有比RfA更大的勇气。如果只有解任投票一条路，很多用户就会鼓起勇气把事情说出来。在维基百科上，只有把事情勇敢地说出来才有价值。如果有了第二条路，相信即使两种制度并存，不少原先选择Rfda的人也会放弃他们的想法。这无论是对促进沟通，还是对及时罢免真正的不当使用权限的管理员都没有好处。--Antigng（留言） 2016年8月21日 (日) 04:29 (UTC)

text: (－)反对：同Antigng。--4Li 2016年8月21日 (日) 04:27 (UTC)

text: (－)反对：同Antigng，浪费社群精力。--Lanwi1(留言) 2016年8月21日 (日) 04:31 (UTC)

text: (－)反对：浪费社群精力。--晴空·和岩 讨论页·反互煮·协作计划 2016年8月21日 (日) 04:36 (UTC)

text: (－)反对：同Antigng及Lanwi1，或有轉移社群注意力的問題。--❦‽研究及來源 hanteng✉ 2016年8月21日 (日) 04:40 (UTC)
*此提案不能有效反映現狀，當前我們有80位管理員，堅持默默做枯燥站務工作的不到一半人數，而會違反方針與指引的又是這少數管理員的極少數，大多數管理員都是遵守方針與指引的。因此應該討論的是，當管理員自己違規時，社群應有辦法對應此事，而任期制並無法解決管理員違規問題。(我承認我還是覺得有設立仲裁委員會或調解委員會的必要)--秋意假髮濃(我已關閉了所有通知，所以@我看不到)（留言） 2016年8月21日 (日) 04:42 (UTC)

text: (－)反对：同Antigng及Lanwi1。Wetrace歡迎參與人權專題 2016年8月21日 (日) 04:58 (UTC)

text: (－)反对：有嚴重違規會影響中文維基運作時應直接提罷免，而無違規疑慮的管理員，縱使只是偶爾執行任務也不會因此造成負面影響，提這種提案只是浪費社群資源。麻煩有閒時間搞這些不如拿去好好編輯條目！--泅水大象™ 訐譙☎ 2016年8月29日 (一) 02:33 (UTC)
thread_title:  建议在管理员卸任中，新增一条，希望获大家支持。 

message: 現在站務頁面分作很多，例如WP:VIP、WP:存廢覆核請求、WP:移動請求等等，部分頁面的關注程度甚低，懂得門路找對頁面提出請求的用戶（尤其是新用戶）亦不多，導致很多逼切需要解決的站務問題處於積壓的狀態。因此，我建議將這些站務頁面統一歸類至WP:管理員協助請求或重新使用Wikipedia:请求管理员帮助也可，這不但便於用戶尋求協助，管理員也不需要東奔西跑去解決問題，而且部分問題可能是目前各種站務頁面未能涵概，例如索取被刪頁面紀錄、協助解決爭議、解答站務疑難、提報遊戲維基或擾亂行為、複核其他管理員的決定、修改首頁內容等等。整合後，相信有助用戶更容易提出請求，而管理員也可以一目了然應對各種問題，從而加強反破壞的效果。目前初步建議將以下站務頁面整合：
#Wikipedia:当前的破坏
#Wikipedia:移動請求
#Wikipedia:檔案存廢討論/無版權訊息或檔案來源
#Wikipedia:请求保护页面
#Wikipedia:需要管理員注意的用戶名
#Wikipedia:修訂版本刪除請求
#:Category:維基百科編輯被保護頁面請求
#Wikipedia:權限申請
#Wikipedia:合并请求（這個也荒廢得太厲害）
我明白技術上可能需要大幅調整，但是如果社群同意整合的話，預期效果應該不錯。不知大家意下如何？—AT 2016年9月26日 (一) 01:42 (UTC)
replies: text: :可以使用类似以前的管理员公告版模式，将这些页面通过包含或者指引的方式告知这些页面的存在，使用完全整合技术难度将可能会是“史无前例”。——路过围观的Sakamotosan 2016年9月26日 (一) 02:36 (UTC)
replies: text: ::我初步的想法是製作類似存廢覆核請求般的提報功能，但是選項作一些變化。例如第一項是「相關頁面標題」、第二項是「求助理由」，然後自動生成第三項是「管理員判定」和「個人簽名」，存檔可以是一個月存一次或兩次，每滿50項存一次也可以，以目前的技術我想應該做得到，至於與機械人和TW之間的連動就需要技術達人的調整。另外，現Wikipedia:请求管理员帮助其實正發揮您所說的功能，但是效果不佳，因此我希望能夠作出改革。—AT 2016年9月26日 (一) 03:35 (UTC)
replies: text: ::*(＋)贊成站务页面太复杂了。——星耀晨曦（留言） 2016年9月26日 (一) 11:12 (UTC)
replies: text: ::::(！)意見可以参考WP:互助客栈的结构：把主要的站务按功能的分类，在客栈首页放置一些目前正在进行的一些重要讨论或者重要的通知。——星耀晨曦（留言） 2016年9月26日 (一) 11:12 (UTC)
replies: text: :::::基本上較熱門的話，我比較傾向不整合。例如侵權、速刪、存廢等等，其他則整合至同一頁面，讓各種請求能夠更靈活地得到處理。—AT 2016年9月26日 (一) 19:59 (UTC)

text: Wikipedia:字词转换/修复请求，:Category:封禁申诉?-和平、奮鬥、救地球！（留言） 2016年9月27日 (二) 00:23 (UTC)
replies: text: :字詞轉換可以考慮加入。但是封禁申訴者皆被封禁，無法在討論頁以提出請求吧，雖然其他人出來替其申訴的話也不是不可以。—AT 2016年9月27日 (二) 00:28 (UTC)
replies: text: ::設定讓封禁者可以編輯某個Wikipedia名字空間的某個申請封禁申訴站務頁面如何？--　宇帆（普通留言·Flow留言</sub>·聯絡） 2016年9月28日 (三) 04:15 (UTC)
replies: text: :::這個我不知道能否做得到。—AT 2016年9月28日 (三) 04:17 (UTC)

text: :::和维基百科:编辑禁制方针差不多吧。——星耀晨曦（留言） 2016年9月28日 (三) 04:50 (UTC)
replies: text: ::::這個在中文維基尚未引入，而且只允許編輯某一頁面和禁制編輯某一頁面應該有很大差異。—AT 2016年9月28日 (三) 04:54 (UTC)
replies: text: :::::利用过滤器把可以编辑的申述页面以外的页面都禁制，这样技术上可以做到吧。——星耀晨曦（留言） 2016年9月28日 (三) 05:02 (UTC)
replies: text: ::::::我不確定。—AT 2016年9月28日 (三) 05:33 (UTC)
replies: text: :::::::就算技術上可行，一定會有人濫用申訴，這就是問題。--1233C|嚴禁互煮|T 2016年9月28日 (三) 05:37 (UTC)
replies: text: ::::::::濫用的話完全禁止就好了，不成問題。現在封禁申訴也是這樣做。—AT 2016年9月28日 (三) 05:39 (UTC)

text: :::::话说回来，封禁申述是在自己的讨论页加入申述模板，然后自动归类到:Category:封禁申诉，而不是封禁用户手动归类吧。——星耀晨曦（留言） 2016年9月28日 (三) 05:42 (UTC)
replies: text: ::::::當然是加模板後自動歸類。—AT 2016年9月28日 (三) 05:48 (UTC)
thread_title:  關於整合站務各頁面的提議 

message: 在哪些情形中，管理员可以在未接获报告的情况下直接使用管理员权限进行操作？例如（包括但不限于）：
#直接删除未挂速删模板的页面
#直接封禁未被报告至VIP的用户
#直接保护未被报告至RFP的页面
#直接删除未被报告至RDD的修订版本
……
replies: text: --Tiger（留言） 2017年1月6日 (五) 15:44 (UTC)
不能直接进行某项管理动作基本上都是出于避嫌考虑，如第1种情况，一人挂模板另一人执行删除为惯例，这是为了使「问题条目」最少经过两双眼从而避免个人意见的偏颇。
在一些情况下，例如，某spammer大批量新建明显的垃圾广告条目，其中只有一部分被巡查员标记速删，与立即使用Special:Nuke删除全部相比，等所有垃圾条目被挂上速删模板再去删是不是太过于注重过程了？维基百科不是官僚体系。
说到底这也是WP:IAR的使用守则，我们须在WP:CIV的前提下使用WP:IAR来改善维基百科——尤其是在别人对这些管理动作提出意见的时候。--Kegns（留言） 2017年1月6日 (五) 16:24 (UTC)

text: WP:CSD：“符合下列準則，而又掛有快速刪除模板的頁面或文件，管理员可直接删除頁面或文件，无需通过存廢討論。”

text: WP:BLOCK：“管理員有權将用戶封禁，以避免維基百科及其他用戶受到破壞或傷害。”

text: WP:RVDL：“修訂版本刪除功能用來校訂嚴重不當的發表及日誌項目。允許管理員在依據校訂標準下使用。亦可移除某些人身攻擊和隱私侵害。”

text: WP:PP：“尽管维基百科的宗旨是人人可编辑，但在某些特定情形下，管理员可以对页面设定保护，防止用户编辑或移动。”

text: 所以问题的答案很明确，1不可以，234可以。--Antigng（留言） 2017年1月8日 (日) 02:33 (UTC)
replies: text: :我覺得那四個都是為了避嫌或是濫權的最後一道防線(雖然還是不能阻止)，不過如果同個人持續創造垃圾條目的話可以考慮直接封鎖跟直接刪除條目，但是還要跟其他人討論。-Neville Wang 奈威  （留言） 2017年1月8日 (日) 14:01 (UTC)

text: 第一个如果是管理员遇到破坏呢？或者处理到一个破坏页面后用nuke清理同一个用户的破坏页面？——路过围观的Sakamotosan 2017年1月10日 (二) 00:38 (UTC)

text: BTW，不过没有见过有OP使用过保护中“历史只读”原则，有时想查看删除页面内容就不太方便了。 ——路过围观的Sakamotosan 2017年1月10日 (二) 00:38 (UTC)
replies: text: :那就是WP:IAR的问题了吧，比如有人想CSD条目，指明要给这人创建的100个条目csd，那么他没必要挂100个模板，说一句就行。不过我自己从来不想用NUKE，除非哪一天我的bot发抽创建大量无意义的页面。--Antigng（留言） 2017年1月10日 (二) 00:41 (UTC)
thread_title:  有关管理员操作的一个问题 

message: 顯然管理這個字令人對管理員產生高人一等的印象。雖然權限上來說絕對是這樣的
理想化的管理員的工作實際上是透過參考方針、指引、共識，對一個決定（無論這個決定是個人的還是社群的）以客觀的角度進行覆核並付諸執行，所以也許改為覆核員也不錯的感覺。
順便還可以寫些覆核並非只有覆核員才能做，只是只有覆核員才能執行等等這類的東西，讓管理員更顯親民什麼的XD
 只是問問--—歡迎參觀關注度不足博物館。以上有簽名的留言由R96340（對話）加入。 2017年2月25日 (六) 17:21 (UTC)
replies: text: 早期有操作员的说法，因为sysop。—菲菇＠维基食用菌协会 2017年2月25日 (六) 17:24 (UTC)
replies: text: :testwiki:Special:ListGroupRights#reviewer。-- Stang 103 2017年2月25日 (六) 17:28 (UTC)

text: 只要新人没“先入为主”的念头，就不会产生维基百科的管理员和其它地方的管理员是差不多的错觉。——꧁༺星耀晨曦༻꧂（留言|2017年监管员选举） 2017年2月25日 (六) 18:56 (UTC)
*不如叫「資深用戶」吧。--persona non grata 2017年2月27日 (一) 02:53 (UTC)
*这个“管理”只是系统层面的管理，而非社群或者组织的管理。——路过围观的Sakamotosan 2017年2月27日 (一) 09:13 (UTC)
*我認為重要的是群眾對於現時維基管理員產生的印象是什麼。權力不對等不是問題，權力不對等的矛盾才是問題（不論是否有明確的制度，權力不對等總會在社會自然產生）。看到閣下使用的刪除線，我猜閣下感受到管理員和一般用戶的相處不是很和陸。請不要高估管理員稱呼的改變帶來的幫助，因為權力矛盾的存在和掌權者的稱呼沒有關系。管理員一字出於英文的Administrator，而「管理」一字給人擁有權威的印象，我建議改名為「行政員」、「事務員」、「常務員」、「理事員」等中性、概括、僅描述工作性質的用字。——愚蠢的人類 2017年2月27日 (一) 12:47 (UTC)
維基百科已有其他權限叫行政員。10^2+4179計算過程 2017年2月27日 (一) 13:43 (UTC)
*(＋)贊成，「管理」一字給人擁有權威的印象--葉又嘉（留言） 2017年2月27日 (一) 14:20 (UTC)
*好奇，這個問題真的單純靠改名就可以解決麼？--J.Wong 2017年2月27日 (一) 15:17 (UTC)
**就像「官員」改稱「幹部」。--Mewaqua（留言） 2017年2月28日 (二) 02:09 (UTC)
*若真的這麼做，我認為算是一個實驗的好機會，對結果有一個明確的推測，但事實有可能相異的實驗才是最有趣的實驗。如果管理員不再被稱作管理員，會發生什麼事情？並非期待會有什麼改變，而是看看會發生什麼事情—這才是實驗的真諦。--—歡迎參觀關注度不足博物館。以上有簽名的留言由R96340（對話）加入。 2017年2月27日 (一) 15:27 (UTC)
*于是这样一来滥权管理员就变成了滥权事务员了，这真是帮了大忙。:D Bluedeck 2017年2月27日 (一) 23:32 (UTC)
*Template:清洁工--逆襲的天邪鬼（留言） 2017年2月28日 (二) 10:57 (UTC)
** 两个提议都(＋)贊成。杜绝不当幻想。——Artoria2e5编 讨论要完整，回复请用ping。 2017年3月25日 (六) 15:27 (UTC)
*名字改叫：“朝鲜劳动党”了，所以就是劳动而不是统治百姓了？galaxyharrylion（留言） 2017年2月28日 (二) 11:38 (UTC)
*(－)反对：在下认为没必要。--Dqwyy（談笑風生）正在沉迷CLANNAD回復請ping我 2017年2月28日 (二) 15:55 (UTC)
*对改名本身没看法，但我估计真的改了成本会很大，有一大堆显示文字要改，而且不能完全交给bot。 --砜中嘌呤的白磷萃取 打谱 2017年3月1日 (三) 03:22 (UTC)
*(＋)贊成，建議改名為「事務員」--Vinct_1998（留言）（叮噹呀,誰都喜歡你,小貓也自豪!） 2017年3月10日 (五) 09:11 (UTC)
*(－)反对改名，簡單明瞭，難道還要改成「史蒂芬」嗎？--小躍（撈出記錄） 2017年3月15日 (三) 01:29 (UTC)
無意見。形象問題。--61.224.18.54（留言） 2017年3月16日 (四) 12:56 (UTC)
*(＋)贊成，改名是第一步，不能因为这一步不能立即起效而连这一步都不迈出，在十分饥饿的情况下，第一口饭绝对不会让你吃饱，但难道这就是不吃饭的理由？——平头哥（留言） 2017年3月21日 (二) 13:46 (UTC)
*如果改名能夠大幅減低對「管理員」工作性質的不當幻想，以及增進維基媒體社群的相互尊重，我認為可以試試看。臺灣杉在此發言 (會客室) 2017年3月27日 (一) 14:01 (UTC)
*(－)反对，如果改名之後那麼所有頁面的＂管理員＂一詞將必須通通修改，避免貿然行動，維持現狀即可。10^24279計算過程 2017年4月4日 (二) 11:56 (UTC)
*(－)反对，显然管理员这个头衔的认知度更高，而且改成复核员的话会名不对事（复核啥？）又容易混淆（比如存废复核员[開玩笑的]（？）等）。--Jerre Jiang 　讨论│参与清理积压站务　 2017年4月4日 (二) 12:08 (UTC)
*(＋)贊成改为操作员，高级操作的核验与执行者。有助社群理解职能与义务，也符合sysop=系统操作员的本意，这与常见意义的Administrator（管理员）存在不小差异。复核员就算了，像是校对或复核审计，地位过低、增加误解。如果担心修改所有页面，可以先作为一篇论述或者指引来达成共识而创建和建议使用--YFdyh000（留言） 2017年4月10日 (一) 15:11 (UTC)
*(＋)贊成將管理員這稱呼改名：之前已在相關討論中提出類似的建議。至於要改為什麼名字，似乎還有討論空間。個人不是很支持繼續使用「某某員」的用法，或許「進階用戶」是個更常見且親和的稱呼方式？--泅水大象™ 訐譙☎ 2017年4月17日 (一) 05:09 (UTC)
*(－)反对，administrator 中外翻譯一向是管理員。--Temp3600（留言） 2017年4月17日 (一) 06:26 (UTC)
**個人認為維基媒體計畫的特殊性質，可以不用一昧遵循中外翻譯的慣例。臺灣杉在此發言 (會客室) 2017年4月21日 (五) 06:37 (UTC)
*(＋)贊成，可以试一试。虽说很难改过来，不过形式上的更改也是迈出平等的一步嘛燃⁠灯 谈笑风生 微小贡献 2017年4月23日 (日) 08:36 (UTC)
*(！)意見，其实管理员的意义只在于系统的前台性维护，并没有问题。——路过围观的Sakamotosan 2017年4月24日 (一) 01:07 (UTC)
*(！)意見：很有創意的想法。不過，大廈管理員、社區管理員，都是「服務性質」的管理員。維基百科管理員，依據方針明確是「服務社群」。關鍵還是管理員群的心態與自我認知。Wetrace歡迎參與人權專題 2017年4月27日 (四) 11:07 (UTC)
*(－)反对：越是想改名称叫朝鲜劳动党，越是证明了骑在老百姓头上作威作福。galaxyharrylion（留言） 2017年5月1日 (一) 13:51 (UTC)
*(－)反对不只有复核工作。--淺藍雪❉ 2017年5月1日 (一) 20:02 (UTC)
thread_title: 將管理員的名字改為覆核員如何？

message: 在2015年12月，英文版有兩名ADMIN的密碼因使用DOB和6位數字而被破。中文版過去亦發生過管理員被盜號的事件。
為此，我提議訂立密碼方針，要求管理員以上職階使用強式密碼，並定期接受審查(即基金會人員會定期嘗試破解密碼)。
--Temp3600（留言） 2017年7月8日 (六) 18:30 (UTC)
剛好有網站能測密碼強度，不過還是強烈(＋)-{支持}-設立方針(#10^24279計算過程 2017年7月9日 (日) 06:07 (UTC)
*(－)反对第一，上述的網站只能算是一個測試網站，嚴格來說和維基百科扯不上邊。第二，維基工具要如何發展此一工具？，第三，如果要這麼討論，不如順便設個密碼為限制好了，過短的密碼應重設-Z7504（留言） 2017年7月9日 (日) 12:04 (UTC)
*(：)回應網站和提案無關。基金會已在英文版實施本政策，故無須擔心無法實行的問題。--Temp3600（留言） 2017年7月9日 (日) 13:21 (UTC)
replies: text: 一些補充資料:
*英文版RFC
*元維基RFC
*PHAB上的實行

text: 經管理員測試，原來現在已經不能訂立8位以下的密碼。大家希望將限制擴展至所有用戶，又或增加更多限制嗎?--Temp3600（留言） 2017年7月9日 (日) 15:02 (UTC)
*(？)疑問@-{Temp3600}-：是請誰測試呢?--Z7504（留言） 2017年7月9日 (日) 15:34 (UTC)
**(：)回應會由security team負責。--Temp3600（留言） 2017年7月9日 (日) 17:48 (UTC)
***security team，慢慢整修版本吧，改(＋)-{支持}-了--Z7504（留言） 2017年7月10日 (一) 01:36 (UTC)
*(＋)-{支持}-具有影響站務權限的用戶密碼需自我有所防備，當被不法入侵會引響多數頁面造成困擾，個人贊同此提議，另外八位數以下在有心與有技術的人在數分鐘的數小時內破解，八位元以上的時間差數倍以上，具有較好的保護能力，如果包含用戶頁上的一些資訊如生日在密碼上更容易破解，拒絕傻瓜密碼、連號密碼。--Zest 2017年7月9日 (日) 16:20 (UTC)
*(！)意見技術上不知道可不可行，如果有人試圖破解密碼則通知用戶(密碼多次打錯、短時間內多次輸入)提醒修改密碼或增加第二層驗證行為。--Zest 2017年7月9日 (日) 16:20 (UTC)
**在Phabricator上已有類似提案（T11838︰多次嘗試登入失敗後發送通知予帳戶持有人）。而最後進度報告指已經交付測試。--J.Wong 2017年7月9日 (日) 16:51 (UTC)
***任何限制密码格式的行为本质上都是缩小密钥空间的行为，并没有意义。维护强壮密码是管理员的责任，必须假设任何管理员至少具备这个能力。Bluedeck 快速存档 2017年7月9日 (日) 22:27 (UTC)
****其實查核員也應要有這能力吧，不然很難被相信算是個真正的用戶查核員（雖然一般密碼盜密機率不像傀儡這麼多...）--Z7504（留言） 2017年7月10日 (一) 01:39 (UTC)
replies: text: :::(：)回應的確，社群信任管理員能管理好自己的帳號。但如果多次使用弱密碼，屢勸不聽，自然可以作為失職事由要求解職。--Temp3600（留言） 2017年7月10日 (一) 14:09 (UTC)

text: :这个不是说已经实施了么？难道我记错了？---{百無一用是書生}- (☎) 2017年7月10日 (一) 02:13 (UTC)
*建議@-{Temp3600}-：詳細說明上述問題?--Z7504（留言） 2017年7月10日 (一) 03:31 (UTC)

text: :的確，META方針已經實行。本案目的有二:

text: :提供META方針的中文版本。

text: :如有需要，給予社群機會討論是否需增加額外限制，如討論password audit的次數和方式。--Temp3600（留言） 2017年7月10日 (一) 05:39 (UTC)
replies: text: ::这个只能是通过技术实现才行啊。规定有什么用呢---{百無一用是書生}- (☎) 2017年7月10日 (一) 06:13 (UTC)
replies: text: :::(：)回應需要先有本地共識才能交到PHAB，在技術實面上落實。--Temp3600（留言） 2017年7月10日 (一) 14:07 (UTC)
*如果这个密码方针通过后，如何实施呢。这得要求管理员使用高强度的密码吧，如何证明管理员使用了高强度的密码？——꧁༺星耀晨曦༻꧂（留言） 2017年7月10日 (一) 07:24 (UTC)

text: :(：)回應星耀晨曦的問題:
*第一，技術上，會向PHAB請求，禁止管理員使用某些弱密碼(事實上目前管理員已經不能使用8位以下的密碼，這裏討論是否需要再加強)
*第二，會向wmf安全組請求，讓他們定期對本地admin進行密碼測試，嘗試攻入帳號。如果密碼一攻就破，強度自然成疑。--Temp3600（留言） 2017年7月10日 (一) 14:16 (UTC)
*(＋)-{支持}-為什麼要反對呢 ？--我要真普選   Asdfugil （留言 | 簽名） 留言於香港特別行政區。 2017年8月16日 (三) 01:22 (UTC)
=== 整理 ===
(我覺得cwek君的問題是很好的重點整理，特搬來此處﹐方便回應。)--Temp3600（留言） 2017年7月10日 (一) 14:56 (UTC)

text: 我觉得先讨论几个问题吧：

text: #是否支持对ABCO组启用强密码定期例行测试，甚至二步验证功能？

text: #基金会是否有相应工作小组允许例行或请求进行密码挑战测试？（看上去已经有了）例行的频率多长？自我申请的话允不允许？

text: #如何判断是强密码？或者怎样验证或强密码的要求？

text: 三个问题能给出详细方案的话，才好进行确立共识吧。——路过围观的Sakamotosan 2017年7月10日 (一) 07:04 (UTC)

text: (：)回應

text: 問題一:技術上二者皆可行。ABCO現在已經可以申請2FA，而强密码定期例行测试則需要在獲取本地共識後，和基金會安全組再申請。但既然英文組亦有類似計劃，無理由中文區弄不出來。

text: 問題二:基金會安全組。例行的频率未確定(英文區尚未定案)，我個人提議半年一次。自我申请不清楚，但meta看來對低權限用戶的密碼保安不太在意。

text: 問題三:目前meta方針已禁止8位以下密碼。如果社群認為有必要，可要求加長，增加大小階/數字/符號要求，要求定期改密碼等等。個人對此未有太大想法，偏向維持目前要求。本案目的主要是新增password audit，但如果社群有意收緊密碼要求(如要所有用戶使用強密碼)，當然可以提出。--Temp3600（留言） 2017年7月10日 (一) 15:09 (UTC)

text: 如果我来回答的话，结合enRFC的做法

text: #支持ABCO组定期进行密码审计，ABCO组可以申请或建议一定要开二步认证（尤其C组）

text: #如果基金会支持一经申请能定期自动审计并公布结果的话，就可以申请定期审计计划，并按时公布结果。否则由本地定期去申请审计并接收结果并公布。周期初步为半年，不建议超过一年。个人申请的话感觉太麻烦，每次自己改完密码然后申请审计再说我改了密码没问题的，太别扭了。不要求自行改密码就要申请审计，但不反对自行申请审计。

text: #好像现在A组默认开启长度要求，至于其他细则的话，例如大小写数字符号非字典化单词组合或个人公开信息等，可以作为一个至少倡议去约束，如果技术已实现的话，也可以去实行，密码强度也有提供一些强度测试网站，可以用来自我初步测试。en的要求就是长于8字节和非常用密码表:en:Wikipedia:Most_common_passwords/10000中则可。——路过围观的Sakamotosan 2017年7月11日 (二) 01:44 (UTC)

text: 另外本地群组不建议全部实现密码强度限制，只要重要管理组（即ABCO）强制要求则可，另不知道普通用户有没兴趣允许使用二步验证的设定？——路过围观的Sakamotosan 2017年7月11日 (二) 01:46 (UTC)
replies: text: :就算是普通用戶也要有一定的密碼強度，避免攻破後淪陷為破壞者的傀儡。10^24279計算過程 2017年7月11日 (二) 02:44 (UTC)
replies: text: ::不强制吧，毕竟不是这么多人有这么高的安全需求。——路过围观的Sakamotosan 2017年7月11日 (二) 03:29 (UTC)

text: 元維基現正諮詢是否開放予普通用戶使用二步驗證。--J.Wong 2017年7月11日 (二) 05:23 (UTC)
replies: text: :两步认证太可怕。wikitech上我的帐号就莫名其妙被两步认证锁死了，wmf那边都没办法....所以对这个玩意，我一直心有余悸不敢用---{百無一用是書生}- (☎) 2017年7月11日 (二) 06:52 (UTC)
技术上怎么检查密码的强弱。。服务器上用户的密码都是被加密过的。——꧁༺星耀晨曦༻꧂（留言） 2017年7月12日 (三) 08:25 (UTC)

text: 在存入数据库之前是还没有加盐加hash的，而且浏览器提交之前也没有做客户端加密，所以这之间仍是明文，提交前的检验可以在这里检测。而后期审计，无非就是模拟登陆去撞，这是撞的密码会加盐加hash后和数据库存储的对比，并无问题。——路过围观的Sakamotosan 2017年7月12日 (三) 08:54 (UTC)
replies: text: :也就是说已经存在数据库里的密码无法检验。在用户主动提交密码的时候检验？——꧁༺星耀晨曦༻꧂（留言） 2017年7月12日 (三) 08:59 (UTC)
replies: text: ::要看是檢驗什麼。--A2093064#Talk 2017年7月12日 (三) 09:08 (UTC)

text: ::已有的就是做审核，看一些已知的碰撞工具，可能包括彩虹表、字典、常用密码表等去试撞，撞中了就可以认为密码安全有问题了。——路过围观的Sakamotosan 2017年7月12日 (三) 09:28 (UTC)
replies: text: :::還要檢查密碼是否有在其他網站使用（如YouTube、Facebook、Google、Niconico動畫等）--林勇智 2017年7月13日 (四) 12:06 (UTC)
replies: text: ::::我不喜歡這個提議，密碼強度夠為何還需檢查其他網頁，這屬私人事情了，其他網站的帳戶保安也要自己管，何況刻意嘗試密碼是否相同會給其他網站或用戶造成困擾(FB密碼錯又愛封解又要時間)。--Zest 2017年7月13日 (四) 12:13 (UTC)

text: ::::如何檢查？無法檢查吧。--A2093064#Talk 2017年7月13日 (四) 12:28 (UTC)

text: ::::英文版同樣因無法檢查而放棄此要求，然而我們應提醒管理員們。--Temp3600（留言） 2017年7月13日 (四) 14:05 (UTC)

text: 反对限制密码格式和长度的行为。如果要规避弱密码，请使用真正能规避弱密码的方法——信息熵限制。限制格式（大小写、特殊符号等）这种方法对非字典穷举攻击是无效的。好的密码强度算法应该是bin(optimalCompress(passphrase).length)>=80 && entropy(passphrase)>=80。如果真要限制，按这个限制。Bluedeck 刘晓波 2017年7月19日 (三) 20:54 (UTC)
对于“基金会将对管理员的密码进行定期查核”这一点，英文版的方针里也早有类似的内容，但是似乎也并没有落实。的确有能力实现吗-- Ben.mq 2017年8月5日 (六) 21:02 (UTC)
=== 添加一些新限制 ===

text: 為了進一步提高帳戶可靠性，建議採取下列措施。

text: 所有管理員都需使用Template:User_committed_identity或類似措施。 中文版對本項認知過低，不宜強行開展。

text: CUer的選舉中，增加一條必答題:你會在上任後啓用2fa嗎?如不會，請解釋。

text: 對現有的cuer，邀請他們補答，並將結果存檔。
replies: text: :--Temp3600（留言） 2017年7月22日 (六) 18:40 (UTC)

text: 草稿:密碼方針已初步完工。

text: 為了方針的一致性，需在Wikipedia:管理員的離任#解任理由增加"多次違反密碼方針"一項。--Temp3600（留言） 2017年7月26日 (三) 07:19 (UTC)

text: PING人回來@-{TEntEn4279、Z7504、蘭斯特、Wong128hk、Bluedeck}-：--Temp3600（留言） 2017年7月27日 (四) 19:51 (UTC)

text: PING人回來@-{Shizhao、cwek、A2093064、D2513850}-：--Temp3600（留言） 2017年7月27日 (四) 19:57 (UTC)
*(＋)-{支持}-：順便修改了對應連結下--Z7504（留言） 2017年7月27日 (四) 19:56 (UTC)
replies: text: :committed identity很头痛啊。首先一个问题是社群里有几个人知道committed idnetity的protocol是什么？我看并不多。committed identity需要绝大多数参与成员都拥有很高的程序意识，而且一旦设定不能更改，原像一但丢失，就再也无法证明身份，而且无法重新设定，并且所有社群成员必须不承认重新设定的散列值。请问设定committed idnetity的人和社群有这个觉悟吗。一年前，我曾经公开过一次自己的身份原像，但是我可以肯定地说：直到现在为止没有一个人去验证过，因为我使用的算法是一个罕见算法，网上没有现成的验证程序，也没有人来问我要验证程序，也没有人来问我要散列paper去编程，也没有人来问散列强壮型证明。这样的committed identity等于没有。而且散列值分布式存储也是一个头很大的问题。我的结论是committed identity在中文维基百科基本无用，安全性就只能靠良好的密码practice和2FA。Bluedeck 2017年7月27日 (四) 20:00 (UTC)
replies: text: ::確實如此。故改為建議，望日後有足夠認為後再立為方針。--Temp3600（留言） 2017年7月31日 (一) 08:47 (UTC)
*(＋)-{支持}-：不能用低密码强度的密碼（包括但不限於GitHub的資料或密码强度條目所提及的密碼）--林勇智 2017年7月28日 (五) 08:25 (UTC)
*(？)疑問哪些會成為方針，Draft:密碼方針而已嗎，還是CUer和User_committed_identity也是？--A2093064#Talk 2017年7月28日 (五) 09:05 (UTC)

text: :(：)回應那部分開放給大家討論，我未寫進草案裏。--Temp3600（留言） 2017年7月28日 (五) 12:33 (UTC)
*(！)意見：根據「噗浪技術部」在噗浪的貼文，被駭客入侵的帳號所使用到的密碼大部分為其他網站洩漏的帳號密碼--林勇智 2017年7月28日 (五) 12:46 (UTC)

text: :然而我們無法檢查維基人是否重用了密碼;最多只能在他們因重用密碼而被盜號時處罰他們而已。--Temp3600（留言） 2017年7月31日 (一) 08:47 (UTC)
=== 結論? ===

text: 近日已無討論。既然如此，決議:

text: 在草稿:密碼方針之上，添加Cuer必答題"你會在上任後啓用2fa嗎?如不會，請解釋。"，及修改對應Wikipedia:管理員的離任#解任理由。而WMF方的定期密碼檢查，則初步定為半年一檢。(這個要和WMF相討後才有最終答案)

text: 現公示七日。--Temp3600（留言） 2017年8月3日 (四) 15:03 (UTC)
replies: text: :Cuer必答題可直接加入模板。--A2093064#Talk 2017年8月5日 (六) 03:21 (UTC)
replies: text: ::无法执行。下面说明。试想，必答题写好了，请问CUer怎么回答社群算满意呢？我有这么几个答案，你们看你们满意吗：

text: ::#我不用2FA因为我经常损坏手机，2FA会把我自己锁住。我使用24位强密码。

text: ::#我不用2FA。因为我使用24位强密码足够强，不想再麻烦。

text: ::#我不使用2FA，我使用8位强密码。

text: ::#我不使用2FA，因为我没有手机。

text: ::#我不使用2FA，我定期修改密码。

text: ::#我使用2FA，同时我的密码提供40位安全。

text: ::#我使用2FA，同时我的密码提供80位安全。

text: ::想好之后，看看我怎么评论这些答案的，然后你是否觉得这仍然是一个可执行的提议。Bluedeck 2017年8月5日 (六) 06:58 (UTC)
replies: text: ::::回答得好不好由社群自行決定，如果有人覺得答得不好，自然會追問，或是投反對票。--Temp3600（留言） 2017年8月6日 (日) 03:28 (UTC)
replies: text: :::::你这是想吧问题丢给社群，我正是觉得这样不可行才有此评论——社群的密码学知识不足，无法判断，甚至不知道自己无法判断一个候选人提供的密码信息是否在可能安全的范围内。Bluedeck 2017年8月10日 (四) 01:05 (UTC)

text: 另外，就「修改對應Wikipedia:管理員的離任#解任理由」而言，個人無法理解這句。是要為提高保安而創造另一個保安漏洞？如此解任豈不等於昭告天下該人帳戶不安全，歡迎去攻擊？--J.Wong 2017年8月5日 (六) 08:25 (UTC)
replies: text: :::英文版將“把無法保障自己帳戶的管理員解職”的權力交給了ARBCOM，但中文版沒有arbcom,只好將這項權力交給社群了,不然本項無法執行。--Temp3600（留言） 2017年8月6日 (日) 03:33 (UTC)
*(？)疑問这个密码方针草稿的一部分是基于WMF会对管理员的账号进行安全审查。是否有数据说明WMF会定期审查管理员账号？如果没有，那么这个方针就没有强制性，谁违反了这个方针都不知道。——꧁༺星耀晨曦༻꧂（留言） 2017年8月5日 (六) 21:15 (UTC)

text: 這一項的詳細內容要和WMF相議才有最終答案，但要先有本地共識才可以提上去PHAB。--Temp3600（留言） 2017年8月6日 (日) 03:25 (UTC)
replies: text: :意思是，得有本地共识，WMF才会对zhwiki的管理员进行安全审查？——꧁༺星耀晨曦༻꧂（留言） 2017年8月6日 (日) 06:04 (UTC)

text: :正是如此，只能摸着石頭過河。--Temp3600（留言） 2017年8月7日 (一) 14:39 (UTC)
replies: text: ::不建议作为方针，作为指引尚可。---{百無一用是書生}- (☎) 2017年8月8日 (二) 01:47 (UTC)

text: @-{Shizhao}-：這個與WMF談判有關，我不確定拿指引過去是否可行。--Temp3600（留言） 2017年8月11日 (五) 16:39 (UTC)
让我正经地谈一谈这个问题：
# 作为方针而言，它没有可操作性：虽然可以要求WMF去检查，但是仍然无法在本地判断方针是否已经得到执行。“違反上述要求的管理員可能會被暫時除權，直到他們解決保安問題為止”，那么本地社区如何得知他违反要求和解决问题呢？
# 它没有解决问题：因为强密码不意味着安全，而且安全不一定必须通过强密码来实现。另外证明自己身份的方法很多，“User committed identity”只是其中一种，而且我们也无法保证管理员们能够正确地使用这个工具（所以幸亏没提出强制要求来命令管理员使用这个东西）。
# 后果过重：发现问题解决就行——改个密码而已，没必要以“除权”来威胁。当然我们可以威胁“一旦账号被盗并且产生了严重后果，那么会导致除权”，相比之下这个更实际吧，而且同样可以起到督促保障账号安全的作用。
# “添加Cuer必答題你會在上任後啓用2fa嗎?如不會，請解釋”这个问题有很多缺陷：
## 2FA只是保护安全的方式之一，我们为什么非要通过这一种方法来解决安保问题呢？如果非要问，不如问“你采用了哪些办法来保护账号安全？”
## 前面Bluedeck已经提到，社区没法对答案进行评估，或者说因为大家可能并不懂这个东西，得出的结论很可能是偏颇的。一个只在维基百科有活动的管理员可能只要开了2FA，密码设成123456789也无所谓，而在各个网站注册账号的管理员即使把密码设到20位也有安全风险——实际上是哲学问题。
### 续这个问题，对于维基百科而言，10位密码和100位密码对提高安全程度来说可能没什么区别。拒绝常见弱密码已经足够。
## 监督员也是签署过隐私协议的人，难道监督员不需要回答吗？为什么只有查核员需要回答这个问题呢？
# 虽然我们没法要求管理员必须遵守方针，但是我们可以“强烈建议”，而且以实际后果进行威胁“一旦真的出事了，……”
# 用一句话总结一下：“密码方针”是君子协定，而且其出发点有偏差，所以可以考虑换角度思考（账号安全）、降低成建议级的要求（例如星耀晨曦所言）或考虑修订解任方案。
--逆襲的天邪鬼（留言） 2017年8月13日 (日) 12:34 (UTC)

text: 與數位維基人交流後，在下決定撤回此提案，願日後由更熟識本方面的用戶處理帳號安全問題。--Temp3600（留言） 2017年8月16日 (三) 17:28 (UTC)
*虽然这个方案不太可能通过成为方针。但是可以在这个基础上，建立一个建议用户提升自己账户安全的指引。——꧁༺星耀晨曦༻꧂（留言） 2017年8月16日 (三) 19:06 (UTC)
**同意星耀晨曦---{百無一用是書生}- (☎) 2017年8月17日 (四) 02:28 (UTC)
thread_title:  訂立密碼方針 

message: (我覺得cwek君的問題是很好的重點整理，特搬來此處﹐方便回應。)--Temp3600（留言） 2017年7月10日 (一) 14:56 (UTC)
replies: text: 我觉得先讨论几个问题吧：

text: #是否支持对ABCO组启用强密码定期例行测试，甚至二步验证功能？

text: #基金会是否有相应工作小组允许例行或请求进行密码挑战测试？（看上去已经有了）例行的频率多长？自我申请的话允不允许？

text: #如何判断是强密码？或者怎样验证或强密码的要求？

text: 三个问题能给出详细方案的话，才好进行确立共识吧。——路过围观的Sakamotosan 2017年7月10日 (一) 07:04 (UTC)

text: (：)回應

text: 問題一:技術上二者皆可行。ABCO現在已經可以申請2FA，而强密码定期例行测试則需要在獲取本地共識後，和基金會安全組再申請。但既然英文組亦有類似計劃，無理由中文區弄不出來。

text: 問題二:基金會安全組。例行的频率未確定(英文區尚未定案)，我個人提議半年一次。自我申请不清楚，但meta看來對低權限用戶的密碼保安不太在意。

text: 問題三:目前meta方針已禁止8位以下密碼。如果社群認為有必要，可要求加長，增加大小階/數字/符號要求，要求定期改密碼等等。個人對此未有太大想法，偏向維持目前要求。本案目的主要是新增password audit，但如果社群有意收緊密碼要求(如要所有用戶使用強密碼)，當然可以提出。--Temp3600（留言） 2017年7月10日 (一) 15:09 (UTC)

text: 如果我来回答的话，结合enRFC的做法

text: #支持ABCO组定期进行密码审计，ABCO组可以申请或建议一定要开二步认证（尤其C组）

text: #如果基金会支持一经申请能定期自动审计并公布结果的话，就可以申请定期审计计划，并按时公布结果。否则由本地定期去申请审计并接收结果并公布。周期初步为半年，不建议超过一年。个人申请的话感觉太麻烦，每次自己改完密码然后申请审计再说我改了密码没问题的，太别扭了。不要求自行改密码就要申请审计，但不反对自行申请审计。

text: #好像现在A组默认开启长度要求，至于其他细则的话，例如大小写数字符号非字典化单词组合或个人公开信息等，可以作为一个至少倡议去约束，如果技术已实现的话，也可以去实行，密码强度也有提供一些强度测试网站，可以用来自我初步测试。en的要求就是长于8字节和非常用密码表:en:Wikipedia:Most_common_passwords/10000中则可。——路过围观的Sakamotosan 2017年7月11日 (二) 01:44 (UTC)

text: 另外本地群组不建议全部实现密码强度限制，只要重要管理组（即ABCO）强制要求则可，另不知道普通用户有没兴趣允许使用二步验证的设定？——路过围观的Sakamotosan 2017年7月11日 (二) 01:46 (UTC)
replies: text: :就算是普通用戶也要有一定的密碼強度，避免攻破後淪陷為破壞者的傀儡。10^24279計算過程 2017年7月11日 (二) 02:44 (UTC)
replies: text: ::不强制吧，毕竟不是这么多人有这么高的安全需求。——路过围观的Sakamotosan 2017年7月11日 (二) 03:29 (UTC)

text: 元維基現正諮詢是否開放予普通用戶使用二步驗證。--J.Wong 2017年7月11日 (二) 05:23 (UTC)
replies: text: :两步认证太可怕。wikitech上我的帐号就莫名其妙被两步认证锁死了，wmf那边都没办法....所以对这个玩意，我一直心有余悸不敢用---{百無一用是書生}- (☎) 2017年7月11日 (二) 06:52 (UTC)
技术上怎么检查密码的强弱。。服务器上用户的密码都是被加密过的。——꧁༺星耀晨曦༻꧂（留言） 2017年7月12日 (三) 08:25 (UTC)

text: 在存入数据库之前是还没有加盐加hash的，而且浏览器提交之前也没有做客户端加密，所以这之间仍是明文，提交前的检验可以在这里检测。而后期审计，无非就是模拟登陆去撞，这是撞的密码会加盐加hash后和数据库存储的对比，并无问题。——路过围观的Sakamotosan 2017年7月12日 (三) 08:54 (UTC)
replies: text: :也就是说已经存在数据库里的密码无法检验。在用户主动提交密码的时候检验？——꧁༺星耀晨曦༻꧂（留言） 2017年7月12日 (三) 08:59 (UTC)
replies: text: ::要看是檢驗什麼。--A2093064#Talk 2017年7月12日 (三) 09:08 (UTC)

text: ::已有的就是做审核，看一些已知的碰撞工具，可能包括彩虹表、字典、常用密码表等去试撞，撞中了就可以认为密码安全有问题了。——路过围观的Sakamotosan 2017年7月12日 (三) 09:28 (UTC)
replies: text: :::還要檢查密碼是否有在其他網站使用（如YouTube、Facebook、Google、Niconico動畫等）--林勇智 2017年7月13日 (四) 12:06 (UTC)
replies: text: ::::我不喜歡這個提議，密碼強度夠為何還需檢查其他網頁，這屬私人事情了，其他網站的帳戶保安也要自己管，何況刻意嘗試密碼是否相同會給其他網站或用戶造成困擾(FB密碼錯又愛封解又要時間)。--Zest 2017年7月13日 (四) 12:13 (UTC)

text: ::::如何檢查？無法檢查吧。--A2093064#Talk 2017年7月13日 (四) 12:28 (UTC)

text: ::::英文版同樣因無法檢查而放棄此要求，然而我們應提醒管理員們。--Temp3600（留言） 2017年7月13日 (四) 14:05 (UTC)

text: 反对限制密码格式和长度的行为。如果要规避弱密码，请使用真正能规避弱密码的方法——信息熵限制。限制格式（大小写、特殊符号等）这种方法对非字典穷举攻击是无效的。好的密码强度算法应该是bin(optimalCompress(passphrase).length)>=80 && entropy(passphrase)>=80。如果真要限制，按这个限制。Bluedeck 刘晓波 2017年7月19日 (三) 20:54 (UTC)
对于“基金会将对管理员的密码进行定期查核”这一点，英文版的方针里也早有类似的内容，但是似乎也并没有落实。的确有能力实现吗-- Ben.mq 2017年8月5日 (六) 21:02 (UTC)
thread_title:  整理 

message: :為了進一步提高帳戶可靠性，建議採取下列措施。
replies: text: 所有管理員都需使用Template:User_committed_identity或類似措施。 中文版對本項認知過低，不宜強行開展。

text: CUer的選舉中，增加一條必答題:你會在上任後啓用2fa嗎?如不會，請解釋。

text: 對現有的cuer，邀請他們補答，並將結果存檔。
replies: text: :--Temp3600（留言） 2017年7月22日 (六) 18:40 (UTC)

text: 草稿:密碼方針已初步完工。

text: 為了方針的一致性，需在Wikipedia:管理員的離任#解任理由增加"多次違反密碼方針"一項。--Temp3600（留言） 2017年7月26日 (三) 07:19 (UTC)

text: PING人回來@-{TEntEn4279、Z7504、蘭斯特、Wong128hk、Bluedeck}-：--Temp3600（留言） 2017年7月27日 (四) 19:51 (UTC)

text: PING人回來@-{Shizhao、cwek、A2093064、D2513850}-：--Temp3600（留言） 2017年7月27日 (四) 19:57 (UTC)
*(＋)-{支持}-：順便修改了對應連結下--Z7504（留言） 2017年7月27日 (四) 19:56 (UTC)
replies: text: :committed identity很头痛啊。首先一个问题是社群里有几个人知道committed idnetity的protocol是什么？我看并不多。committed identity需要绝大多数参与成员都拥有很高的程序意识，而且一旦设定不能更改，原像一但丢失，就再也无法证明身份，而且无法重新设定，并且所有社群成员必须不承认重新设定的散列值。请问设定committed idnetity的人和社群有这个觉悟吗。一年前，我曾经公开过一次自己的身份原像，但是我可以肯定地说：直到现在为止没有一个人去验证过，因为我使用的算法是一个罕见算法，网上没有现成的验证程序，也没有人来问我要验证程序，也没有人来问我要散列paper去编程，也没有人来问散列强壮型证明。这样的committed identity等于没有。而且散列值分布式存储也是一个头很大的问题。我的结论是committed identity在中文维基百科基本无用，安全性就只能靠良好的密码practice和2FA。Bluedeck 2017年7月27日 (四) 20:00 (UTC)
replies: text: ::確實如此。故改為建議，望日後有足夠認為後再立為方針。--Temp3600（留言） 2017年7月31日 (一) 08:47 (UTC)
*(＋)-{支持}-：不能用低密码强度的密碼（包括但不限於GitHub的資料或密码强度條目所提及的密碼）--林勇智 2017年7月28日 (五) 08:25 (UTC)
*(？)疑問哪些會成為方針，Draft:密碼方針而已嗎，還是CUer和User_committed_identity也是？--A2093064#Talk 2017年7月28日 (五) 09:05 (UTC)

text: :(：)回應那部分開放給大家討論，我未寫進草案裏。--Temp3600（留言） 2017年7月28日 (五) 12:33 (UTC)
*(！)意見：根據「噗浪技術部」在噗浪的貼文，被駭客入侵的帳號所使用到的密碼大部分為其他網站洩漏的帳號密碼--林勇智 2017年7月28日 (五) 12:46 (UTC)

text: :然而我們無法檢查維基人是否重用了密碼;最多只能在他們因重用密碼而被盜號時處罰他們而已。--Temp3600（留言） 2017年7月31日 (一) 08:47 (UTC)
thread_title:  添加一些新限制 

message: :近日已無討論。既然如此，決議:
replies: text: 在草稿:密碼方針之上，添加Cuer必答題"你會在上任後啓用2fa嗎?如不會，請解釋。"，及修改對應Wikipedia:管理員的離任#解任理由。而WMF方的定期密碼檢查，則初步定為半年一檢。(這個要和WMF相討後才有最終答案)

text: 現公示七日。--Temp3600（留言） 2017年8月3日 (四) 15:03 (UTC)
replies: text: :Cuer必答題可直接加入模板。--A2093064#Talk 2017年8月5日 (六) 03:21 (UTC)
replies: text: ::无法执行。下面说明。试想，必答题写好了，请问CUer怎么回答社群算满意呢？我有这么几个答案，你们看你们满意吗：

text: ::#我不用2FA因为我经常损坏手机，2FA会把我自己锁住。我使用24位强密码。

text: ::#我不用2FA。因为我使用24位强密码足够强，不想再麻烦。

text: ::#我不使用2FA，我使用8位强密码。

text: ::#我不使用2FA，因为我没有手机。

text: ::#我不使用2FA，我定期修改密码。

text: ::#我使用2FA，同时我的密码提供40位安全。

text: ::#我使用2FA，同时我的密码提供80位安全。

text: ::想好之后，看看我怎么评论这些答案的，然后你是否觉得这仍然是一个可执行的提议。Bluedeck 2017年8月5日 (六) 06:58 (UTC)
replies: text: ::::回答得好不好由社群自行決定，如果有人覺得答得不好，自然會追問，或是投反對票。--Temp3600（留言） 2017年8月6日 (日) 03:28 (UTC)
replies: text: :::::你这是想吧问题丢给社群，我正是觉得这样不可行才有此评论——社群的密码学知识不足，无法判断，甚至不知道自己无法判断一个候选人提供的密码信息是否在可能安全的范围内。Bluedeck 2017年8月10日 (四) 01:05 (UTC)

text: 另外，就「修改對應Wikipedia:管理員的離任#解任理由」而言，個人無法理解這句。是要為提高保安而創造另一個保安漏洞？如此解任豈不等於昭告天下該人帳戶不安全，歡迎去攻擊？--J.Wong 2017年8月5日 (六) 08:25 (UTC)
replies: text: :::英文版將“把無法保障自己帳戶的管理員解職”的權力交給了ARBCOM，但中文版沒有arbcom,只好將這項權力交給社群了,不然本項無法執行。--Temp3600（留言） 2017年8月6日 (日) 03:33 (UTC)
*(？)疑問这个密码方针草稿的一部分是基于WMF会对管理员的账号进行安全审查。是否有数据说明WMF会定期审查管理员账号？如果没有，那么这个方针就没有强制性，谁违反了这个方针都不知道。——꧁༺星耀晨曦༻꧂（留言） 2017年8月5日 (六) 21:15 (UTC)

text: 這一項的詳細內容要和WMF相議才有最終答案，但要先有本地共識才可以提上去PHAB。--Temp3600（留言） 2017年8月6日 (日) 03:25 (UTC)
replies: text: :意思是，得有本地共识，WMF才会对zhwiki的管理员进行安全审查？——꧁༺星耀晨曦༻꧂（留言） 2017年8月6日 (日) 06:04 (UTC)

text: :正是如此，只能摸着石頭過河。--Temp3600（留言） 2017年8月7日 (一) 14:39 (UTC)
replies: text: ::不建议作为方针，作为指引尚可。---{百無一用是書生}- (☎) 2017年8月8日 (二) 01:47 (UTC)

text: @-{Shizhao}-：這個與WMF談判有關，我不確定拿指引過去是否可行。--Temp3600（留言） 2017年8月11日 (五) 16:39 (UTC)
让我正经地谈一谈这个问题：
# 作为方针而言，它没有可操作性：虽然可以要求WMF去检查，但是仍然无法在本地判断方针是否已经得到执行。“違反上述要求的管理員可能會被暫時除權，直到他們解決保安問題為止”，那么本地社区如何得知他违反要求和解决问题呢？
# 它没有解决问题：因为强密码不意味着安全，而且安全不一定必须通过强密码来实现。另外证明自己身份的方法很多，“User committed identity”只是其中一种，而且我们也无法保证管理员们能够正确地使用这个工具（所以幸亏没提出强制要求来命令管理员使用这个东西）。
# 后果过重：发现问题解决就行——改个密码而已，没必要以“除权”来威胁。当然我们可以威胁“一旦账号被盗并且产生了严重后果，那么会导致除权”，相比之下这个更实际吧，而且同样可以起到督促保障账号安全的作用。
# “添加Cuer必答題你會在上任後啓用2fa嗎?如不會，請解釋”这个问题有很多缺陷：
## 2FA只是保护安全的方式之一，我们为什么非要通过这一种方法来解决安保问题呢？如果非要问，不如问“你采用了哪些办法来保护账号安全？”
## 前面Bluedeck已经提到，社区没法对答案进行评估，或者说因为大家可能并不懂这个东西，得出的结论很可能是偏颇的。一个只在维基百科有活动的管理员可能只要开了2FA，密码设成123456789也无所谓，而在各个网站注册账号的管理员即使把密码设到20位也有安全风险——实际上是哲学问题。
### 续这个问题，对于维基百科而言，10位密码和100位密码对提高安全程度来说可能没什么区别。拒绝常见弱密码已经足够。
## 监督员也是签署过隐私协议的人，难道监督员不需要回答吗？为什么只有查核员需要回答这个问题呢？
# 虽然我们没法要求管理员必须遵守方针，但是我们可以“强烈建议”，而且以实际后果进行威胁“一旦真的出事了，……”
# 用一句话总结一下：“密码方针”是君子协定，而且其出发点有偏差，所以可以考虑换角度思考（账号安全）、降低成建议级的要求（例如星耀晨曦所言）或考虑修订解任方案。
--逆襲的天邪鬼（留言） 2017年8月13日 (日) 12:34 (UTC)

text: 與數位維基人交流後，在下決定撤回此提案，願日後由更熟識本方面的用戶處理帳號安全問題。--Temp3600（留言） 2017年8月16日 (三) 17:28 (UTC)
*虽然这个方案不太可能通过成为方针。但是可以在这个基础上，建立一个建议用户提升自己账户安全的指引。——꧁༺星耀晨曦༻꧂（留言） 2017年8月16日 (三) 19:06 (UTC)
**同意星耀晨曦---{百無一用是書生}- (☎) 2017年8月17日 (四) 02:28 (UTC)
thread_title:  結論? 

message: ;舊有條文
=== 設計並修訂維基介面 ===
* 管理员可以编辑MediaWiki名字空间来改变网站的介面文字。并且防止其他人破坏MediaWiki。（editinterface）
* 透過修改CSS：MediaWiki:Common.css來編輯介面樣式。（editinterface）
* 可修改任何用戶的CSS及Javascript頁面。（editusercss,edituserjs）	
;現行條文
=== 設計並修訂維基介面 ===
* 管理员可以编辑MediaWiki名字空间来改变网站的介面文字。并且防止其他人破坏MediaWiki。（editinterface）
* 透過修改CSS：MediaWiki:Common.css來編輯介面樣式。（editinterface）
* 可修改任何用戶的CSS及Javascript頁面。（editusercss,edituserjs）
=== 建立具有结构化讨论特質的頁面 ===
* 管理員可以建立具结构化讨论特質的討論頁面。（結構化討論以前稱為Flow）（flow-create-board）
因應最新技術修訂而特此公告。--1233|點此與此廢青展開激情對話 | 千錯萬錯都是阿道夫的錯 2017年9月28日 (四) 10:57 (UTC)
*结构化讨论特质这个翻译有点难以理解。--Kuailong™ 2017年9月28日 (四) 15:48 (UTC)
**flow开发团队决定更改名称为结构化讨论。——꧁༺星耀晨曦༻꧂（留言） 2017年9月28日 (四) 23:51 (UTC)
replies: text: :好像技术版有机器人通知过吧，但是现在重新起的这名字有点尴尬啊。结构化讨论……—云间守望 · 在此留言💬 2017年9月29日 (五) 00:45 (UTC)
*@-{1233}-：不要再在中使用章節或子章節了，已nowiki。目錄很亂。--PatrollerAAAA（討論|留名） 2017年9月29日 (五) 16:14 (UTC)
thread_title:  通知︰管理員權限修訂 

message: 承上次討論及公示結果，有用戶對大量帳戶建立者方針及管理員方針作出前列修訂。謹此通知。--J.Wong 2018年6月26日 (二) 08:56 (UTC)
replies: text: 稍為再作修訂及刪去不能授予自動確認用戶要求。自動確認用戶本來就有相關權限，所以沒有需要特別要求不可以這樣做。多餘權限移除就是了。--J.Wong 2018年6月26日 (二) 09:11 (UTC)

text: 註：此次修訂亦包含管理員能夠更變用戶的檔案移動員用戶組資格的事實性修訂。--1233( T / C） 2018年6月26日 (二) 09:19 (UTC)
*不反對。SænmōsàI'll find a way, or I'll make one. 2018年6月26日 (二) 13:16 (UTC)
*等待Phabricator部署修補程式，暫時請勿存檔。--J.Wong 2018年7月5日 (四) 03:26 (UTC)
thread_title:  大量帳戶建立者方針及管理員方針修訂 

message: 未完成，提案人請求關閉討論。如日後對管理員內文有其他問題者，再自行開個討論串即可。--Z7504非常建議必要時多關注評選（留言） 2020年2月25日 (二) 02:13 (UTC)
replies: text: 下列討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。
----
在下近期处理速删请求时，有遇到TW自动删除页面附带的讨论页的情况，从方针角度，是页面虽符合G15标准，惟未有他人提案，故此并不符合Wikipedia:管理员#避嫌中的有关规定。为避免繁琐，在此提议修订条文。重定向页同理。
;現行條文
删除：管理员不得删除自己提议删除或者投票删除的页面	
;提議條文
删除：管理员不得删除自己提议删除或者投票删除的页面，处理其他提案时，同时删除页面讨论页或到此页的重定向页的除外
以上。--Hamish論 2020年2月22日 (六) 05:38 (UTC)

text: 我建議在提議條文中明示這是G15所允許的。ꓢꓯꓠꓟꓳꓢꓮ COVID-19 2020年2月22日 (六) 06:49 (UTC)
*其實一向都可以在刪條目時直接刪去討論頁等孤立頁面，而不須等機器人提刪，而永封用戶甚至0解封後，也不用提刪，而直接g8刪去永封模板。--蟲蟲飛♡♡→♡℃※留言 2020年2月22日 (六) 07:10 (UTC)

text: (＆)建議:此外，管理員大量刪除破壞者的頁面，也是無須提刪，因此可能加註則較容易處理；或者修改g8及g15也行。不過不改，也問題不大，因為這算是IAR,過去多年都是這樣處理。--蟲蟲飛♡♡→♡℃※留言 2020年2月22日 (六) 07:44 (UTC)

text: 這算個傳統吧，大部分都是這樣做的，既然要IAR，我的想法是在方針中明確說明，當然要IAR也不是不行。--Hamish論 2020年2月22日 (六) 10:48 (UTC)

text: (？)疑問，何謂「前述要求」？在Wikipedia:管理员中並沒有提到有關前述。---{街燈電箱150號}- 開箱維修 抄錶 檢驗證明 2020年2月22日 (六) 09:01 (UTC)

text: 那個“前述要求”是指“管理员不得删除自己提议删除或者投票删除的页面”這個，原文措辭不當，已修改。--Hamish論 2020年2月22日 (六) 10:48 (UTC)

text: (？)疑問：雖然管理員也可以對條目提報快速刪除，但如果條目明顯符合快速刪除準則，為什麼不直接刪掉，還要經過提名程序？還不如管理員自己訂內規，哪些情況可以不經提名直接刪除就好（我也相信管理員內部會有如此共識），這樣也不用動到這條。Poem（留言） 2020年2月22日 (六) 14:07 (UTC)
*基本上所有頁面都不能直接刪去，但有些如g15，有些管理員會等機器人提刪，有些不等，刪去等於符合IAR，即操作對維基有實際好處才用這條，g8是不可能提刪，因為全永封用戶頁是被全保護的，刪除以便移動也不可等其他人提刪。大量刪除破壞者頁面，是運用IAR,即對維基有好處。維基對於頁面的刪除是很審慎的，如果管理員可以隨意刪除，很多政治條目肯定會被無故刪去。--蟲蟲飛♡♡→♡℃※留言 2020年2月22日 (六) 14:41 (UTC)

text: 改G15就可以了，無必要改這條。--SCP-2000 2020年2月22日 (六) 15:16 (UTC)
* 在相信管理員會謹慎使用wp:IAR下，我不認為這條需要寫得很明；寫得太明白反而綁手綁腳。在看不出修改後會帶來助益下，不贊同這個修正案。Poem（留言） 2020年2月23日 (日) 04:24 (UTC)
* (▲)同上，社群共識這種屬WP:IAR就好了-- Sunny00217  2020年2月23日 (日) 12:29 (UTC)
* 在下遵守社群共识，留题待其余意见，亦可由其余维基人自行关闭。--Hamish論 2020年2月24日 (一) 13:07 (UTC)
----

text: 本討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。
thread_title:  提议修订[[Wikipedia:管理员#避嫌]]部分内容 

message: 依部分用戶所請關閉。SANMOSA SPQR 2020年11月9日 (一) 07:09 (UTC)
replies: text: 下列討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。
----
诚然，现在的维基百科已经很稳定了，但我仍不能相信以后会不会发生由于管理员权力集中而导致的灾难，或许可以说，这是一定的，管理员可以立方针，可以处罚，还可以执行处罚，我想起了一句话“当立法者，司法者，和行政者三者在一起的时候，就没有任何自由了”虽然我似乎有些杞人忧天，但从另一个角度来讲，把三个职位分开或许更有效率，我的意见是将现有管理员拆分为三个职位，分别是
* 方针设立管理员
* 判罚管理员
* 处罚管理员
方针设立管理员只能完成对于方针的建设和修复，判罚管理员只能对方针做合理解释做判罚（合理解释即为不超过语义，比如某路说禁止驴马通行，而有一只骆驼过去，是不应当被判罚的）另外，我认为如果被判罚者在违反方针时是违反的，但方针日后修改说明他不需要被罚，那他就不被罚，而其他的情况均应当以判罚时的方针为准，处罚管理员应当只处罚判罚管理员所要求的判罚，并不能加减处罚，而且，处罚管理员有权驳回处罚，并要求其他判罚管理员重新判罚。这是我对维基百科管理员职位的意见，望各位采纳
--Catowen 2020年11月8日 (日) 00:45 (UTC)

text: 管理员有避嫌规则；方针是社群讨论的结果；其他管理员都可以处理不合理封禁。怎么说呢…建议您还是先完整地看一下与这些有关的规则。--安忆Talk 2020年11月8日 (日) 01:20 (UTC)

text: 設立方針及提議設立方針非管理員之專利。SANMOSA SPQR 2020年11月8日 (日) 02:50 (UTC)

text: 题主所述的问题是真实存在，但我认为这问题无法解决。这就好比小国在联合国大会提案要求取消安理会五大流氓的一票否决权，必然会被大国一票否决。--Remaining silent is not Majority's fault. 2020年11月8日 (日) 04:24 (UTC)
*(－)反对：理据：
1.管理员需避嫌。
2.管理员依方针行事，而方针由社群讨论得出。
3.任何管理员皆可处理任何不合理封禁。
4.至于处罚管理员："管理员没有任何高于其他用户的特权，唯能实现社群讨论所得的共识"(WP:Sysop)。
以上。
题外话:要是真这么搞了互助客栈是不是该易名了？
--光猫猫 Talk理性、证据、辩论 2020年11月8日 (日) 05:15 (UTC)

text: 此外，若说三权：立法权在社群、行政权在基金会、司法权在管理员。--光猫猫 Talk理性、证据、辩论 2020年11月8日 (日) 05:19 (UTC)
*@-{Catowen}-：(！)抗议設立「方針設立管理員」。現行制度，方針是由社群共識決定的，任何維基百科編者，無論資歷深淺，都有權提出方針提案或修正案，且通過與否，要經由社群共識檢驗，若社群無共識，方針提案就不應該通過。如果訂立方針變成一個職位，不就變成皇帝了，維基帝國危機帝國維基危機。哪會自由，直接獨裁化了吧，這種提案必須(！)抗议抗爭到底。小心到時基金會行動直接把中文維基給關掉，咱們都不用玩了。-- 來人啊，餵宮子吃布丁！  ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2020年11月8日 (日) 08:43 (UTC)
* 建议你维实施议行合一制度，选出维基议会，在上面再选一个议会的理事会，再分出三个权来，必要时维基基金会中央可以直接把议会及其理事会解散了。[開玩笑的]--向前进！向前进！朝着胜利的方向！（留言） 2020年11月8日 (日) 12:55 (UTC)

text: 我只能说楼主了解管理员制度后再来……Fire Ice 2020年11月8日 (日) 13:14 (UTC)

text: 管理員當然有特權，可以自我解封，所以有沒有什麼辦法阻止管理員自我解封。--Googol19980904（留言） 2020年11月8日 (日) 14:19 (UTC)
replies: text: :现在管理员又能自我解封了？我记得上次测试的时候，自己把自己封禁后，还是叫别的管理员解封的.....---{百無一用是書生}- (☎) 2020年11月9日 (一) 02:00 (UTC)
replies: text: ::应该不行吧，要么就是Googol19980904致远星归来，要么请一位管理员亲身验证下。——Sakamotosan路过围观杯弓蛇影| 避免做作，免敬 2020年11月9日 (一) 03:22 (UTC)

text: ::那2019年4月18日  04:12 Shizhao 解封了Shizhao、2017年5月10日  06:47 AT 解封了AT和2017年10月5日 23:43 霧島聖 解封了霧島聖是什麼意思？現在不能自我解封了？--Googol19980904（留言） 2020年11月9日 (一) 04:22 (UTC)
replies: text: :::我记得看过一个设置，是限制了这种自解封的。——Sakamotosan路过围观杯弓蛇影| 避免做作，免敬 2020年11月9日 (一) 05:34 (UTC)

text: 月经提议。🌜山西特产批发零售™️🌽🌶️🍎🍠🐓🐐（留言） 2020年11月9日 (一) 03:09 (UTC)
*Snow. 了解維基制度后再来，連怎樣運作都不知道就先別提案-某人✉ 2020年11月9日 (一) 03:43 (UTC)
----

text: 本討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。
thread_title:  建议管理员三权分立