維基百科討論:管理員/存檔4
本頁是以往討論的存檔。請勿編輯本頁。若您想發起新討論或重啟現有討論,請在當前討論頁進行。 |
留言
管理員權力使用的規範
建議管理員使用權力時必須最少另一位管理員核准無誤方能落實。--218.250.198.229(留言) 2016年8月21日 (日) 04:16 (UTC)
- 這是個好習慣,最好先與其它管理員討論然後再執行操作。事實上,之所以快速刪除「一人掛板、另一人核准」就是需要兩個人判斷才能儘可能保證正確。但是有沒有人覺得不應該強制要求我就不知道了。或許可以在某些hard task上面加一些非強制性的條款。比如「執行封禁申訴時,請與原管理員討論。如無法聯繫到原管理員,強烈建議與另一位管理員交流。」等等。--Antigng(留言) 2016年8月21日 (日) 04:19 (UTC)
- (!)意見--這增加的是決定成本,而「使用權力」太過管泛,我不確定是否所有的權力需要這樣兩人搭配,請先限定哪些權力。--❦‽研究及來源 hanteng✉ 2016年8月21日 (日) 04:41 (UTC)
- 這涉及到修改多個方針。例如封禁方針、保護方針、3RR方針等需要管理權限的方針或指引。--秋意假髮濃(我已關閉了所有通知,所以@我看不到)(留言) 2016年8月21日 (日) 04:45 (UTC)
- 同Hanteng與秋意看法,需要再想想。不過,這一訴求,突顯一個問題,有些管理員在做決定時,疑似連事實都沒搞清楚、也沒有回應用戶及社群質疑的準備、甚至不理會,根本上不符合對管理員「說理」的要求。增加諮詢另位管理員,有一個好處是,用戶及社群有疑問時,另一位管理員也需補充說明。Wetrace歡迎參與人權專題 2016年8月21日 (日) 05:01 (UTC)
- (?)疑問:你的意思是導師制(一個老管理員帶新的?)--秋意假髮濃(我已關閉了所有通知,所以@我看不到)(留言) 2016年8月21日 (日) 05:04 (UTC)
- 同Hanteng與秋意看法,需要再想想。不過,這一訴求,突顯一個問題,有些管理員在做決定時,疑似連事實都沒搞清楚、也沒有回應用戶及社群質疑的準備、甚至不理會,根本上不符合對管理員「說理」的要求。增加諮詢另位管理員,有一個好處是,用戶及社群有疑問時,另一位管理員也需補充說明。Wetrace歡迎參與人權專題 2016年8月21日 (日) 05:01 (UTC)
- 我認為這並沒有什麼卵用。以目前維基上拉幫結派和抱團打架的現狀來看,想使用權力的話找到兩個立場相同的管理員不難吧?--20160821ax(留言) 2016年8月21日 (日) 11:05 (UTC)
- 首先感謝您對計劃的愛護。管理員的工作中也有比較沒那麼大爭議的(例如刪除侵權條目)和爭議比較大的(如封禁)。刪除侵權條目時如果要每個條目都要兩名管理員確認一遍的話,理論上是很好,但實際上減慢處理堆積的速度,而且讓本來已經比較枯燥的工作更加繁瑣,增加不必要的維護成本。至於封禁,真正具爭議的封禁即使兩名管理員處理也未必能服眾,尤其在目前的社群氛圍下。如果任何人對管理員的操作有異議,現在已經有很多機制處理:封禁申訴、存廢覆核和請求解除保護頁面等等,而且維基百科上大部分操作都可逆,所以希望您或其他人能提出一些更具體的方案供討論。--Lakokat 2016年8月21日 (日) 11:21 (UTC)
- 其實樓上的任期制提案與本討論的權力規範都是出自同一個原因:對於部分管理員的不信任。--秋意假髮濃(我已關閉了所有通知,所以@我看不到)(留言) 2016年8月21日 (日) 12:45 (UTC)
- 「必須最少另一位管理員核准」說來是好,實際上不見得能夠解決管理員的信任問題。從近年的管理員選舉,管理員解任投票,反覆封禁爭議,都可看出中文維基管理員及投票用戶存在分黨分派的情況,處理事件時甚至先看當事人是誰,再找方針指引自行解讀。「必須最少另一位管理員核准」只是多一個同聲同氣的管理員發聲,無助於提高爭議性封禁或解封的公信力。--Thomas.Lu(留言) 2016年8月21日 (日) 14:56 (UTC)
- 此一問題必須想出有效辦法根治,逐步排除造成爭議的亂源,不然社群氛圍永遠在惡性循環之中。--秋意假髮濃(我已關閉了所有通知,所以@我看不到)(留言) 2016年8月22日 (一) 07:26 (UTC)
- (ˉ▽ ̄~) 切~~,惡化為車輪戰之前其實不就是相互檢查嗎?現在更大的問題是有些人拉幫結派,把自己的人推上神台後就狐假虎威,其實肇事的管理員一旦被質疑,應該立即回應,而不是拒絕回答,要不然給人動機不純,留下把柄罷了。——路過圍觀的Sakamotosan 2016年8月22日 (一) 08:24 (UTC)
建議在管理員卸任中,新增一條,希望獲大家支持。
此舉旨在防止部分管理員在任期內不按照規矩行事,我知道此提案肯定會遭到大部分管理員和部分既得利益群體的反對,但想了想還是提上來吧。我們選管理員怎麼感覺和原始社會選酋長差不多啊,感覺選上之後個個成皇帝了,了不得了呀。我不否認這些酋長里有明君,但也出了個別暴君,即有人說的所謂民主+獨裁。所以建議在管理員卸任中,新增一條,在任期上加一個期限。任期為兩年或三年,任滿後重新選舉一次。大家怎麼看?--飛賊燕子(留言) 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)
- 既然問心無愧,又幹嘛怕等三年?--飛賊燕子(留言) 2016年8月21日 (日) 03:41 (UTC)
- 一點都不浪費時間,當誰最初是怎麼取得社群信任的,誰就應該在任職期間自然就懂得就應該怎麼把社群的信任保持下去。--飛賊燕子(留言) 2016年8月21日 (日) 04:01 (UTC)
- 對於社群信任的管理員,再開RfA沒有意義;對於社群不信任的管理員,有更直接的方法,就是解任投票,也不需要再開RfA。所以再開RfA就是浪費時間,沒有好處。--Antigng(留言) 2016年8月21日 (日) 04:03 (UTC)
- 是對管理員濫權沒好處吧。--飛賊燕子(留言) 2016年8月21日 (日) 04:05 (UTC)
- 對管理員濫權反而有好處,原來大家覺得管理員做事情不符合方針,只有立即解任投票一條路;現在大家可能會想,也不解任啦,下次不選他就是了。這反而給了濫權管理員三年時間緩衝。--Antigng(留言) 2016年8月21日 (日) 04:06 (UTC)
- 是對管理員濫權沒好處吧。--飛賊燕子(留言) 2016年8月21日 (日) 04:05 (UTC)
- 對於社群信任的管理員,再開RfA沒有意義;對於社群不信任的管理員,有更直接的方法,就是解任投票,也不需要再開RfA。所以再開RfA就是浪費時間,沒有好處。--Antigng(留言) 2016年8月21日 (日) 04:03 (UTC)
- 現在發生的問題不在於管理員「沒有任期限制」,而是管理員任免投票被「不恰當拉票」和「拉幫結派」嚴重影響。--Mewaqua(留言) 2016年8月21日 (日) 04:10 (UTC)
- 同樓上意見。另外,我認為根本問題就是管理員的選任不應採取投票制,應採用資格制,我們應該提拔勤於反破壞與巡查工作的維基人方為正辦,擅長寫條目的維基人不見得適合做管理員,近期爭議已證明了這一點。--秋意假髮濃(我已關閉了所有通知,所以@我看不到)(留言) 2016年8月21日 (日) 04:17 (UTC)
- 用任期制根本就是想無中生有,塑造維基百科內部有個管理員組成的管理階層,那麼以後要不要順便開設人民代表大會、人民法院、黨分部來多重監督?然後先劃定會投反對對象,這樣的提案還真是開放討論。--KOKUYO(留言) 2016年8月21日 (日) 04:11 (UTC)
- (-)反對先惡意假定管理員有問題所以需要定期任免的制度,有可能導致沒有問題的管理員在刻意的謀劃下被免除職務。會有劣幣驅逐良幣的現象。--健康欠安 (留言) 2016年8月21日 (日) 04:20 (UTC)
- (※)注意大家放心,此舉不會放棄解任投票,而是增加一條任期制,旨在防止部分管理員在任期內不按照規矩行事,我知道此提案肯定會遭到大部分不守規矩的管理和部分既得利益群體的大力反對,但為了長久之計,請大家務必認真考慮。--飛賊燕子(留言) 2016年8月21日 (日) 04:22 (UTC)
- 當然不會取消解任投票。但是不管怎麼說,任何人提解任投票是需要有勇氣的,而且要有比RfA更大的勇氣。如果只有解任投票一條路,很多用戶就會鼓起勇氣把事情說出來。在維基百科上,只有把事情勇敢地說出來才有價值。如果有了第二條路,相信即使兩種制度並存,不少原先選擇Rfda的人也會放棄他們的想法。這無論是對促進溝通,還是對及時罷免真正的不當使用權限的管理員都沒有好處。--Antigng(留言) 2016年8月21日 (日) 04:29 (UTC)
- (※)注意大家放心,此舉不會放棄解任投票,而是增加一條任期制,旨在防止部分管理員在任期內不按照規矩行事,我知道此提案肯定會遭到大部分不守規矩的管理和部分既得利益群體的大力反對,但為了長久之計,請大家務必認真考慮。--飛賊燕子(留言) 2016年8月21日 (日) 04:22 (UTC)
- (-)反對:同Antigng。--4Li 2016年8月21日 (日) 04:27 (UTC)
- (-)反對:同Antigng,浪費社群精力。--Lanwi1(留言) 2016年8月21日 (日) 04:31 (UTC)
- (-)反對:浪費社群精力。--晴空·和岩 討論頁·反互煮·協作計劃 2016年8月21日 (日) 04:36 (UTC)
- (-)反對:同Antigng及Lanwi1,或有轉移社群注意力的問題。--❦‽研究及來源 hanteng✉ 2016年8月21日 (日) 04:40 (UTC)
- 此提案不能有效反映現狀,當前我們有80位管理員,堅持默默做枯燥站務工作的不到一半人數,而會違反方針與指引的又是這少數管理員的極少數,大多數管理員都是遵守方針與指引的。因此應該討論的是,當管理員自己違規時,社群應有辦法對應此事,而任期制並無法解決管理員違規問題。(我承認我還是覺得有設立仲裁委員會或調解委員會的必要)--秋意假髮濃(我已關閉了所有通知,所以@我看不到)(留言) 2016年8月21日 (日) 04:42 (UTC)
- (-)反對:同Antigng及Lanwi1。Wetrace歡迎參與人權專題 2016年8月21日 (日) 04:58 (UTC)
- (-)反對:有嚴重違規會影響中文維基運作時應直接提罷免,而無違規疑慮的管理員,縱使只是偶爾執行任務也不會因此造成負面影響,提這種提案只是浪費社群資源。麻煩有閒時間搞這些不如拿去好好編輯條目!--泅水大象™ 訐譙☎ 2016年8月29日 (一) 02:33 (UTC)
關於整合站務各頁面的提議
現在站務頁面分作很多,例如WP:VIP、WP:存廢覆核請求、WP:移動請求等等,部分頁面的關注程度甚低,懂得門路找對頁面提出請求的用戶(尤其是新用戶)亦不多,導致很多逼切需要解決的站務問題處於積壓的狀態。因此,我建議將這些站務頁面統一歸類至WP:管理員協助請求或重新使用Wikipedia:請求管理員幫助也可,這不但便於用戶尋求協助,管理員也不需要東奔西跑去解決問題,而且部分問題可能是目前各種站務頁面未能涵概,例如索取被刪頁面紀錄、協助解決爭議、解答站務疑難、提報遊戲維基或擾亂行為、複核其他管理員的決定、修改首頁內容等等。整合後,相信有助用戶更容易提出請求,而管理員也可以一目了然應對各種問題,從而加強反破壞的效果。目前初步建議將以下站務頁面整合:
- Wikipedia:當前的破壞
- Wikipedia:移動請求
- Wikipedia:檔案存廢討論/無版權訊息或檔案來源
- Wikipedia:請求保護頁面
- Wikipedia:需要管理員注意的用戶名
- Wikipedia:修訂版本刪除請求
- Category:維基百科編輯被保護頁面請求
- Wikipedia:權限申請
- Wikipedia:合併請求(這個也荒廢得太厲害)
我明白技術上可能需要大幅調整,但是如果社群同意整合的話,預期效果應該不錯。不知大家意下如何?—AT 2016年9月26日 (一) 01:42 (UTC)
- 可以使用類似以前的管理員公告版模式,將這些頁面通過包含或者指引的方式告知這些頁面的存在,使用完全整合技術難度將可能會是「史無前例」。——路過圍觀的Sakamotosan 2016年9月26日 (一) 02:36 (UTC)
- 我初步的想法是製作類似存廢覆核請求般的提報功能,但是選項作一些變化。例如第一項是「相關頁面標題」、第二項是「求助理由」,然後自動生成第三項是「管理員判定」和「個人簽名」,存檔可以是一個月存一次或兩次,每滿50項存一次也可以,以目前的技術我想應該做得到,至於與機械人和TW之間的連動就需要技術達人的調整。另外,現Wikipedia:請求管理員幫助其實正發揮您所說的功能,但是效果不佳,因此我希望能夠作出改革。—AT 2016年9月26日 (一) 03:35 (UTC)
- (+)贊成站務頁面太複雜了。——星耀晨曦(留言) 2016年9月26日 (一) 11:12 (UTC)
- (!)意見可以參考WP:互助客棧的結構:把主要的站務按功能的分類,在客棧首頁放置一些目前正在進行的一些重要討論或者重要的通知。——星耀晨曦(留言) 2016年9月26日 (一) 11:12 (UTC)
- 基本上較熱門的話,我比較傾向不整合。例如侵權、速刪、存廢等等,其他則整合至同一頁面,讓各種請求能夠更靈活地得到處理。—AT 2016年9月26日 (一) 19:59 (UTC)
- (!)意見可以參考WP:互助客棧的結構:把主要的站務按功能的分類,在客棧首頁放置一些目前正在進行的一些重要討論或者重要的通知。——星耀晨曦(留言) 2016年9月26日 (一) 11:12 (UTC)
- 我初步的想法是製作類似存廢覆核請求般的提報功能,但是選項作一些變化。例如第一項是「相關頁面標題」、第二項是「求助理由」,然後自動生成第三項是「管理員判定」和「個人簽名」,存檔可以是一個月存一次或兩次,每滿50項存一次也可以,以目前的技術我想應該做得到,至於與機械人和TW之間的連動就需要技術達人的調整。另外,現Wikipedia:請求管理員幫助其實正發揮您所說的功能,但是效果不佳,因此我希望能夠作出改革。—AT 2016年9月26日 (一) 03:35 (UTC)
- 可以使用類似以前的管理員公告版模式,將這些頁面通過包含或者指引的方式告知這些頁面的存在,使用完全整合技術難度將可能會是「史無前例」。——路過圍觀的Sakamotosan 2016年9月26日 (一) 02:36 (UTC)
- Wikipedia:字詞轉換/修復請求,Category:封禁申訴?-和平、奮鬥、救地球!(留言) 2016年9月27日 (二) 00:23 (UTC)
- 字詞轉換可以考慮加入。但是封禁申訴者皆被封禁,無法在討論頁以提出請求吧,雖然其他人出來替其申訴的話也不是不可以。—AT 2016年9月27日 (二) 00:28 (UTC)
- 設定讓封禁者可以編輯某個Wikipedia名字空間的某個申請封禁申訴站務頁面如何?-- 宇帆(普通留言·Flow留言·聯絡) 2016年9月28日 (三) 04:15 (UTC)
- 這個我不知道能否做得到。—AT 2016年9月28日 (三) 04:17 (UTC)
- 和維基百科:編輯禁制方針差不多吧。——星耀晨曦(留言) 2016年9月28日 (三) 04:50 (UTC)
- 這個在中文維基尚未引入,而且只允許編輯某一頁面和禁制編輯某一頁面應該有很大差異。—AT 2016年9月28日 (三) 04:54 (UTC)
- 利用過濾器把可以編輯的申述頁面以外的頁面都禁制,這樣技術上可以做到吧。——星耀晨曦(留言) 2016年9月28日 (三) 05:02 (UTC)
- 我不確定。—AT 2016年9月28日 (三) 05:33 (UTC)
- 就算技術上可行,一定會有人濫用申訴,這就是問題。--1233C|嚴禁互煮|T 2016年9月28日 (三) 05:37 (UTC)
- 濫用的話完全禁止就好了,不成問題。現在封禁申訴也是這樣做。—AT 2016年9月28日 (三) 05:39 (UTC)
- 就算技術上可行,一定會有人濫用申訴,這就是問題。--1233C|嚴禁互煮|T 2016年9月28日 (三) 05:37 (UTC)
- 我不確定。—AT 2016年9月28日 (三) 05:33 (UTC)
- 話說回來,封禁申述是在自己的討論頁加入申述模板,然後自動歸類到Category:封禁申訴,而不是封禁用戶手動歸類吧。——星耀晨曦(留言) 2016年9月28日 (三) 05:42 (UTC)
- 當然是加模板後自動歸類。—AT 2016年9月28日 (三) 05:48 (UTC)
- 利用過濾器把可以編輯的申述頁面以外的頁面都禁制,這樣技術上可以做到吧。——星耀晨曦(留言) 2016年9月28日 (三) 05:02 (UTC)
- 這個在中文維基尚未引入,而且只允許編輯某一頁面和禁制編輯某一頁面應該有很大差異。—AT 2016年9月28日 (三) 04:54 (UTC)
- 設定讓封禁者可以編輯某個Wikipedia名字空間的某個申請封禁申訴站務頁面如何?-- 宇帆(普通留言·Flow留言·聯絡) 2016年9月28日 (三) 04:15 (UTC)
- 字詞轉換可以考慮加入。但是封禁申訴者皆被封禁,無法在討論頁以提出請求吧,雖然其他人出來替其申訴的話也不是不可以。—AT 2016年9月27日 (二) 00:28 (UTC)
有關管理員操作的一個問題
在哪些情形中,管理員可以在未接獲報告的情況下直接使用管理員權限進行操作?例如(包括但不限於):
- 直接刪除未掛速刪模板的頁面
- 直接封禁未被報告至VIP的用戶
- 直接保護未被報告至RFP的頁面
- 直接刪除未被報告至RDD的修訂版本
……
不能直接進行某項管理動作基本上都是出於避嫌考慮,如第1種情況,一人掛模板另一人執行刪除為慣例,這是為了使「問題條目」最少經過兩雙眼從而避免個人意見的偏頗。
在一些情況下,例如,某spammer大批量新建明顯的垃圾廣告條目,其中只有一部分被巡查員標記速刪,與立即使用Special:Nuke刪除全部相比,等所有垃圾條目被掛上速刪模板再去刪是不是太過於注重過程了?維基百科不是官僚體系。
說到底這也是WP:IAR的使用守則,我們須在WP:CIV的前提下使用WP:IAR來改善維基百科——尤其是在別人對這些管理動作提出意見的時候。--Kegns(留言) 2017年1月6日 (五) 16:24 (UTC)
- WP:CSD:「符合下列準則,而又掛有快速刪除模板的頁面或文件,管理員可直接刪除頁面或文件,無需通過存廢討論。」
- WP:BLOCK:「管理員有權將用戶封禁,以避免維基百科及其他用戶受到破壞或傷害。」
- WP:RVDL:「修訂版本刪除功能用來校訂嚴重不當的發表及日誌項目。允許管理員在依據校訂標準下使用。亦可移除某些人身攻擊和隱私侵害。」
- WP:PP:「儘管維基百科的宗旨是人人可編輯,但在某些特定情形下,管理員可以對頁面設定保護,防止用戶編輯或移動。」
- 所以問題的答案很明確,1不可以,234可以。--Antigng(留言) 2017年1月8日 (日) 02:33 (UTC)
- 我覺得那四個都是為了避嫌或是濫權的最後一道防線(雖然還是不能阻止),不過如果同個人持續創造垃圾條目的話可以考慮直接封鎖跟直接刪除條目,但是還要跟其他人討論。-Neville Wang 奈威 (留言) 2017年1月8日 (日) 14:01 (UTC)
- 第一個如果是管理員遇到破壞呢?或者處理到一個破壞頁面後用nuke清理同一個用戶的破壞頁面?——路過圍觀的Sakamotosan 2017年1月10日 (二) 00:38 (UTC)
- BTW,不過沒有見過有OP使用過保護中「歷史只讀」原則,有時想查看刪除頁面內容就不太方便了。 ——路過圍觀的Sakamotosan 2017年1月10日 (二) 00:38 (UTC)
- 那就是WP:IAR的問題了吧,比如有人想CSD條目,指明要給這人創建的100個條目csd,那麼他沒必要掛100個模板,說一句就行。不過我自己從來不想用NUKE,除非哪一天我的bot發抽創建大量無意義的頁面。--Antigng(留言) 2017年1月10日 (二) 00:41 (UTC)
將管理員的名字改為覆核員如何?
顯然管理這個字令人對管理員產生高人一等的印象。雖然權限上來說絕對是這樣的
理想化的管理員的工作實際上是透過參考方針、指引、共識,對一個決定(無論這個決定是個人的還是社群的)以客觀的角度進行覆核並付諸執行,所以也許改為覆核員也不錯的感覺。
順便還可以寫些覆核並非只有覆核員才能做,只是只有覆核員才能執行等等這類的東西,讓管理員更顯親民什麼的XD
只是問問--—歡迎參觀關注度不足博物館。以上有簽名的留言由R96340(對話)加入。 2017年2月25日 (六) 17:21 (UTC)
- 早期有操作員的說法,因為sysop。—菲菇@維基食用菌協會 2017年2月25日 (六) 17:24 (UTC)
- testwiki:Special:ListGroupRights#reviewer。-- Stang 103 2017年2月25日 (六) 17:28 (UTC)
- 只要新人沒「先入為主」的念頭,就不會產生維基百科的管理員和其它地方的管理員是差不多的錯覺。——꧁༺星耀晨曦༻꧂(留言|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)
維基百科已有其他權限叫行政員。+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)
- 名字改叫:「朝鮮勞動黨」了,所以就是勞動而不是統治百姓了?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)
- (-)反對,如果改名之後那麼所有頁面的"管理員"一詞將必須通通修改,避免貿然行動,維持現狀即可。4279計算過程 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)
訂立密碼方針
在2015年12月,英文版有兩名ADMIN的密碼因使用DOB和6位數字而被破。中文版過去亦發生過管理員被盜號的事件。
為此,我提議訂立密碼方針,要求管理員以上職階使用強式密碼,並定期接受審查(即基金會人員會定期嘗試破解密碼)。
--Temp3600(留言) 2017年7月8日 (六) 18:30 (UTC)
剛好有網站能測密碼強度[1],不過還是強烈(+)支持設立方針(#4279計算過程 2017年7月9日 (日) 06:07 (UTC)
(-)反對第一,上述的網站只能算是一個測試網站,嚴格來說和維基百科扯不上邊。第二,維基工具要如何發展此一工具?,第三,如果要這麼討論,不如順便設個密碼為限制好了,過短的密碼應重設-Z7504(留言) 2017年7月9日 (日) 12:04 (UTC)- (:)回應網站和提案無關。基金會已在英文版實施本政策,故無須擔心無法實行的問題。--Temp3600(留言) 2017年7月9日 (日) 13:21 (UTC)
- 一些補充資料:
- 經管理員測試,原來現在已經不能訂立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)
- (:)回應會由security team負責。--Temp3600(留言) 2017年7月9日 (日) 17:48 (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)
- 任何限制密碼格式的行為本質上都是縮小密鑰空間的行為,並沒有意義。維護強壯密碼是管理員的責任,必須假設任何管理員至少具備這個能力。Bluedeck 快速存檔 2017年7月9日 (日) 22:27 (UTC)
- 在Phabricator上已有類似提案(T11838︰多次嘗試登入失敗後發送通知予帳戶持有人)。而最後進度報告指已經交付測試。--J.Wong 2017年7月9日 (日) 16:51 (UTC)
- (:)回應的確,社群信任管理員能管理好自己的帳號。但如果多次使用弱密碼,屢勸不聽,自然可以作為失職事由要求解職。--Temp3600(留言) 2017年7月10日 (一) 14:09 (UTC)
- 這個不是說已經實施了麼?難道我記錯了?--百無一用是書生 (☎) 2017年7月10日 (一) 02:13 (UTC)
- 建議@Temp3600:詳細說明上述問題?--Z7504(留言) 2017年7月10日 (一) 03:31 (UTC)
- 的確,META方針已經實行。本案目的有二:
- 提供META方針的中文版本。
- 如有需要,給予社群機會討論是否需增加額外限制,如討論password audit的次數和方式。--Temp3600(留言) 2017年7月10日 (一) 05:39 (UTC)
- 這個只能是通過技術實現才行啊。規定有什麼用呢--百無一用是書生 (☎) 2017年7月10日 (一) 06:13 (UTC)
- (:)回應需要先有本地共識才能交到PHAB,在技術實面上落實。--Temp3600(留言) 2017年7月10日 (一) 14:07 (UTC)
- 這個只能是通過技術實現才行啊。規定有什麼用呢--百無一用是書生 (☎) 2017年7月10日 (一) 06:13 (UTC)
- 如果這個密碼方針通過後,如何實施呢。這得要求管理員使用高強度的密碼吧,如何證明管理員使用了高強度的密碼?——꧁༺星耀晨曦༻꧂(留言) 2017年7月10日 (一) 07:24 (UTC)
- (:)回應星耀晨曦的問題:
- 第一,技術上,會向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)
- 我覺得先討論幾個問題吧:
- 是否支持對ABCO組啟用強密碼定期例行測試,甚至二步驗證功能?
- 基金會是否有相應工作小組允許例行或請求進行密碼挑戰測試?(看上去已經有了)例行的頻率多長?自我申請的話允不允許?
- 如何判斷是強密碼?或者怎樣驗證或強密碼的要求?
- 三個問題能給出詳細方案的話,才好進行確立共識吧。——路過圍觀的Sakamotosan 2017年7月10日 (一) 07:04 (UTC)
- (:)回應
- 問題一:技術上二者皆可行。ABCO現在已經可以申請2FA,而強密碼定期例行測試則需要在獲取本地共識後,和基金會安全組再申請。但既然英文組亦有類似計劃,無理由中文區弄不出來。
- 問題二:基金會安全組。例行的頻率未確定(英文區尚未定案),我個人提議半年一次。自我申請不清楚,但meta看來對低權限用戶的密碼保安不太在意。
- 問題三:目前meta方針已禁止8位以下密碼。如果社群認為有必要,可要求加長,增加大小階/數字/符號要求,要求定期改密碼等等。個人對此未有太大想法,偏向維持目前要求。本案目的主要是新增password audit,但如果社群有意收緊密碼要求(如要所有用戶使用強密碼),當然可以提出。--Temp3600(留言) 2017年7月10日 (一) 15:09 (UTC)
- 如果我來回答的話,結合enRFC的做法
- 支持ABCO組定期進行密碼審計,ABCO組可以申請或建議一定要開二步認證(尤其C組)
- 如果基金會支持一經申請能定期自動審計並公布結果的話,就可以申請定期審計計劃,並按時公布結果。否則由本地定期去申請審計並接收結果並公布。周期初步為半年,不建議超過一年。個人申請的話感覺太麻煩,每次自己改完密碼然後申請審計再說我改了密碼沒問題的,太彆扭了。不要求自行改密碼就要申請審計,但不反對自行申請審計。
- 好像現在A組默認開啟長度要求,至於其他細則的話,例如大小寫數字符號非字典化單詞組合或個人公開信息等,可以作為一個至少倡議去約束,如果技術已實現的話,也可以去實行,密碼強度也有提供一些強度測試網站,可以用來自我初步測試。en的要求就是長於8字節和非常用密碼表en:Wikipedia:Most_common_passwords/10000中則可。——路過圍觀的Sakamotosan 2017年7月11日 (二) 01:44 (UTC)
- 另外本地群組不建議全部實現密碼強度限制,只要重要管理組(即ABCO)強制要求則可,另不知道普通用戶有沒興趣允許使用二步驗證的設定?——路過圍觀的Sakamotosan 2017年7月11日 (二) 01:46 (UTC)
- 就算是普通用戶也要有一定的密碼強度,避免攻破後淪陷為破壞者的傀儡。4279計算過程 2017年7月11日 (二) 02:44 (UTC)
- 不強制吧,畢竟不是這麼多人有這麼高的安全需求。——路過圍觀的Sakamotosan 2017年7月11日 (二) 03:29 (UTC)
- 就算是普通用戶也要有一定的密碼強度,避免攻破後淪陷為破壞者的傀儡。4279計算過程 2017年7月11日 (二) 02:44 (UTC)
- 元維基現正諮詢是否開放予普通用戶使用二步驗證。--J.Wong 2017年7月11日 (二) 05:23 (UTC)
- 兩步認證太可怕。wikitech上我的帳號就莫名其妙被兩步認證鎖死了,wmf那邊都沒辦法....所以對這個玩意,我一直心有餘悸不敢用--百無一用是書生 (☎) 2017年7月11日 (二) 06:52 (UTC)
技術上怎麼檢查密碼的強弱。。服務器上用戶的密碼都是被加密過的。——꧁༺星耀晨曦༻꧂(留言) 2017年7月12日 (三) 08:25 (UTC)
- 在存入數據庫之前是還沒有加鹽加hash的,而且瀏覽器提交之前也沒有做客戶端加密,所以這之間仍是明文,提交前的檢驗可以在這裡檢測。而後期審計,無非就是模擬登陸去撞,這是撞的密碼會加鹽加hash後和數據庫存儲的對比,並無問題。——路過圍觀的Sakamotosan 2017年7月12日 (三) 08:54 (UTC)
- 也就是說已經存在數據庫里的密碼無法檢驗。在用戶主動提交密碼的時候檢驗?——꧁༺星耀晨曦༻꧂(留言) 2017年7月12日 (三) 08:59 (UTC)
- 要看是檢驗什麼。--A2093064#Talk 2017年7月12日 (三) 09:08 (UTC)
- 已有的就是做審核,看一些已知的碰撞工具,可能包括彩虹表、字典、常用密碼表等去試撞,撞中了就可以認為密碼安全有問題了。——路過圍觀的Sakamotosan 2017年7月12日 (三) 09:28 (UTC)
- 還要檢查密碼是否有在其他網站使用(如YouTube、Facebook、Google、Niconico動畫等)--林勇智 2017年7月13日 (四) 12:06 (UTC)
- 我不喜歡這個提議,密碼強度夠為何還需檢查其他網頁,這屬私人事情了,其他網站的帳戶保安也要自己管,何況刻意嘗試密碼是否相同會給其他網站或用戶造成困擾(FB密碼錯又愛封解又要時間)。--Zest 2017年7月13日 (四) 12:13 (UTC)
- 如何檢查?無法檢查吧。--A2093064#Talk 2017年7月13日 (四) 12:28 (UTC)
- 英文版同樣因無法檢查而放棄此要求,然而我們應提醒管理員們。--Temp3600(留言) 2017年7月13日 (四) 14:05 (UTC)
- 還要檢查密碼是否有在其他網站使用(如YouTube、Facebook、Google、Niconico動畫等)--林勇智 2017年7月13日 (四) 12:06 (UTC)
- 也就是說已經存在數據庫里的密碼無法檢驗。在用戶主動提交密碼的時候檢驗?——꧁༺星耀晨曦༻꧂(留言) 2017年7月12日 (三) 08:59 (UTC)
- 反對限制密碼格式和長度的行為。如果要規避弱密碼,請使用真正能規避弱密碼的方法——信息熵限制。限制格式(大小寫、特殊符號等)這種方法對非字典窮舉攻擊是無效的。好的密碼強度算法應該是bin(optimalCompress(passphrase).length)>=80 && entropy(passphrase)>=80。如果真要限制,按這個限制。Bluedeck 劉曉波 2017年7月19日 (三) 20:54 (UTC)
對於「基金會將對管理員的密碼進行定期查核」這一點,英文版的方針里也早有類似的內容,但是似乎也並沒有落實。的確有能力實現嗎-- Ben.mq 2017年8月5日 (六) 21:02 (UTC)
添加一些新限制
- 為了進一步提高帳戶可靠性,建議採取下列措施。
所有管理員都需使用Template:User_committed_identity或類似措施。中文版對本項認知過低,不宜強行開展。- CUer的選舉中,增加一條必答題:你會在上任後啓用2fa嗎?如不會,請解釋。
- 對現有的cuer,邀請他們補答,並將結果存檔。
- 草稿:密碼方針已初步完工。
- 為了方針的一致性,需在Wikipedia:管理員的離任#解任理由增加"多次違反密碼方針"一項。--Temp3600(留言) 2017年7月26日 (三) 07:19 (UTC)
- PING人回來@TEntEn4279、Z7504、蘭斯特、Wong128hk、Bluedeck:--Temp3600(留言) 2017年7月27日 (四) 19:51 (UTC)
- PING人回來@Shizhao、cwek、A2093064、D2513850:--Temp3600(留言) 2017年7月27日 (四) 19:57 (UTC)
- (+)支持:順便修改了對應連結下--Z7504(留言) 2017年7月27日 (四) 19:56 (UTC)
- committed identity很頭痛啊。首先一個問題是社群里有幾個人知道committed idnetity的protocol是什麼?我看並不多。committed identity需要絕大多數參與成員都擁有很高的程序意識,而且一旦設定不能更改,原像一但丟失,就再也無法證明身份,而且無法重新設定,並且所有社群成員必須不承認重新設定的散列值。請問設定committed idnetity的人和社群有這個覺悟嗎。一年前,我曾經公開過一次自己的身份原像,但是我可以肯定地說:直到現在為止沒有一個人去驗證過,因為我使用的算法是一個罕見算法,網上沒有現成的驗證程序,也沒有人來問我要驗證程序,也沒有人來問我要散列paper去編程,也沒有人來問散列強壯型證明。這樣的committed identity等於沒有。而且散列值分布式存儲也是一個頭很大的問題。我的結論是committed identity在中文維基百科基本無用,安全性就只能靠良好的密碼practice和2FA。Bluedeck 2017年7月27日 (四) 20:00 (UTC)
- 確實如此。故改為建議,望日後有足夠認為後再立為方針。--Temp3600(留言) 2017年7月31日 (一) 08:47 (UTC)
- committed identity很頭痛啊。首先一個問題是社群里有幾個人知道committed idnetity的protocol是什麼?我看並不多。committed identity需要絕大多數參與成員都擁有很高的程序意識,而且一旦設定不能更改,原像一但丟失,就再也無法證明身份,而且無法重新設定,並且所有社群成員必須不承認重新設定的散列值。請問設定committed idnetity的人和社群有這個覺悟嗎。一年前,我曾經公開過一次自己的身份原像,但是我可以肯定地說:直到現在為止沒有一個人去驗證過,因為我使用的算法是一個罕見算法,網上沒有現成的驗證程序,也沒有人來問我要驗證程序,也沒有人來問我要散列paper去編程,也沒有人來問散列強壯型證明。這樣的committed identity等於沒有。而且散列值分布式存儲也是一個頭很大的問題。我的結論是committed identity在中文維基百科基本無用,安全性就只能靠良好的密碼practice和2FA。Bluedeck 2017年7月27日 (四) 20:00 (UTC)
- (+)支持:不能用低密碼強度的密碼(包括但不限於GitHub的資料或密碼強度條目所提及的密碼)--林勇智 2017年7月28日 (五) 08:25 (UTC)
- (?)疑問哪些會成為方針,Draft:密碼方針而已嗎,還是CUer和User_committed_identity也是?--A2093064#Talk 2017年7月28日 (五) 09:05 (UTC)
- (:)回應那部分開放給大家討論,我未寫進草案裏。--Temp3600(留言) 2017年7月28日 (五) 12:33 (UTC)
- (!)意見:根據「噗浪技術部」在噗浪的貼文,被駭客入侵的帳號所使用到的密碼大部分為其他網站洩漏的帳號密碼--林勇智 2017年7月28日 (五) 12:46 (UTC)
- 然而我們無法檢查維基人是否重用了密碼;最多只能在他們因重用密碼而被盜號時處罰他們而已。--Temp3600(留言) 2017年7月31日 (一) 08:47 (UTC)
結論?
- 近日已無討論。既然如此,決議:
- 在草稿:密碼方針之上,添加Cuer必答題"你會在上任後啓用2fa嗎?如不會,請解釋。",及修改對應Wikipedia:管理員的離任#解任理由。而WMF方的定期密碼檢查,則初步定為半年一檢。(這個要和WMF相討後才有最終答案)
- 現公示七日。--Temp3600(留言) 2017年8月3日 (四) 15:03 (UTC)
- Cuer必答題可直接加入{{RfA}}模板。--A2093064#Talk 2017年8月5日 (六) 03:21 (UTC)
- 無法執行。下面說明。試想,必答題寫好了,請問CUer怎麼回答社群算滿意呢?我有這麼幾個答案,你們看你們滿意嗎:
- 我不用2FA因為我經常損壞手機,2FA會把我自己鎖住。我使用24位強密碼。
- 我不用2FA。因為我使用24位強密碼足夠強,不想再麻煩。
- 我不使用2FA,我使用8位強密碼。
- 我不使用2FA,因為我沒有手機。
- 我不使用2FA,我定期修改密碼。
- 我使用2FA,同時我的密碼提供40位安全。
- 我使用2FA,同時我的密碼提供80位安全。
- 想好之後,看看我怎麼評論這些答案的,然後你是否覺得這仍然是一個可執行的提議。Bluedeck 2017年8月5日 (六) 06:58 (UTC)
- 回答得好不好由社群自行決定,如果有人覺得答得不好,自然會追問,或是投反對票。--Temp3600(留言) 2017年8月6日 (日) 03:28 (UTC)
- 你這是想吧問題丟給社群,我正是覺得這樣不可行才有此評論——社群的密碼學知識不足,無法判斷,甚至不知道自己無法判斷一個候選人提供的密碼信息是否在可能安全的範圍內。Bluedeck 2017年8月10日 (四) 01:05 (UTC)
- 回答得好不好由社群自行決定,如果有人覺得答得不好,自然會追問,或是投反對票。--Temp3600(留言) 2017年8月6日 (日) 03:28 (UTC)
- 無法執行。下面說明。試想,必答題寫好了,請問CUer怎麼回答社群算滿意呢?我有這麼幾個答案,你們看你們滿意嗎:
- Cuer必答題可直接加入{{RfA}}模板。--A2093064#Talk 2017年8月5日 (六) 03:21 (UTC)
- 另外,就「修改對應Wikipedia:管理員的離任#解任理由」而言,個人無法理解這句。是要為提高保安而創造另一個保安漏洞?如此解任豈不等於昭告天下該人帳戶不安全,歡迎去攻擊?--J.Wong 2017年8月5日 (六) 08:25 (UTC)
- 英文版將「把無法保障自己帳戶的管理員解職」的權力交給了ARBCOM,但中文版沒有arbcom,只好將這項權力交給社群了,不然本項無法執行。--Temp3600(留言) 2017年8月6日 (日) 03:33 (UTC)
- (?)疑問這個密碼方針草稿的一部分是基於WMF會對管理員的賬號進行安全審查。是否有數據說明WMF會定期審查管理員賬號?如果沒有,那麼這個方針就沒有強制性,誰違反了這個方針都不知道。——꧁༺星耀晨曦༻꧂(留言) 2017年8月5日 (六) 21:15 (UTC)
- 這一項的詳細內容要和WMF相議才有最終答案,但要先有本地共識才可以提上去PHAB。--Temp3600(留言) 2017年8月6日 (日) 03:25 (UTC)
- 意思是,得有本地共識,WMF才會對zhwiki的管理員進行安全審查?——꧁༺星耀晨曦༻꧂(留言) 2017年8月6日 (日) 06:04 (UTC)
- 正是如此,只能摸着石頭過河。--Temp3600(留言) 2017年8月7日 (一) 14:39 (UTC)
- 不建議作為方針,作為指引尚可。--百無一用是書生 (☎) 2017年8月8日 (二) 01:47 (UTC)
- @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)
- 與數位維基人交流後,在下決定撤回此提案,願日後由更熟識本方面的用戶處理帳號安全問題。--Temp3600(留言) 2017年8月16日 (三) 17:28 (UTC)
- 雖然這個方案不太可能通過成為方針。但是可以在這個基礎上,建立一個建議用戶提升自己賬戶安全的指引。——꧁༺星耀晨曦༻꧂(留言) 2017年8月16日 (三) 19:06 (UTC)
- 同意星耀晨曦--百無一用是書生 (☎) 2017年8月17日 (四) 02:28 (UTC)
通知︰管理員權限修訂
|
|
因應最新技術修訂而特此公告。--1233|點此與此廢青展開激情對話 | 千錯萬錯都是阿道夫的錯 2017年9月28日 (四) 10:57 (UTC)
- 結構化討論特質這個翻譯有點難以理解。--Kuailong™ 2017年9月28日 (四) 15:48 (UTC)
- flow開發團隊決定更改名稱為結構化討論。——꧁༺星耀晨曦༻꧂(留言) 2017年9月28日 (四) 23:51 (UTC)
- 好像技術版有機器人通知過吧,但是現在重新起的這名字有點尷尬啊。結構化討論……—雲間守望 · 在此留言💬 2017年9月29日 (五) 00:45 (UTC)
大量帳戶建立者方針及管理員方針修訂
- 下列討論已經關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
承上次討論及公示結果,有用戶對大量帳戶建立者方針及管理員方針作出前列修訂。謹此通知。--J.Wong 2018年6月26日 (二) 08:56 (UTC)
- 稍為再作修訂及刪去不能授予自動確認用戶要求。自動確認用戶本來就有相關權限,所以沒有需要特別要求不可以這樣做。多餘權限移除就是了。--J.Wong 2018年6月26日 (二) 09:11 (UTC)
- 註:此次修訂亦包含管理員能夠更變用戶的檔案移動員用戶組資格的事實性修訂。--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)
- 本討論已關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
提議修訂Wikipedia:管理員#避嫌部分內容
未完成,提案人請求關閉討論。如日後對管理員內文有其他問題者,再自行開個討論串即可。--Z7504非常建議必要時多關注評選(留言) 2020年2月25日 (二) 02:13 (UTC)
- 下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。
在下近期處理速刪請求時,有遇到TW自動刪除頁面附帶的討論頁的情況,從方針角度,是頁面雖符合G15標準,惟未有他人提案,故此並不符合Wikipedia:管理員#避嫌中的有關規定。為避免繁瑣,在此提議修訂條文。重定向頁同理。
|
|
以上。--Hamish論 2020年2月22日 (六) 05:38 (UTC)
- 我建議在提議條文中明示這是G15所允許的。ꓢꓯꓠꓟꓳꓢꓮ COVID-19 2020年2月22日 (六) 06:49 (UTC)
- 其實一向都可以在刪條目時直接刪去討論頁等孤立頁面,而不須等機器人提刪,而永封用戶甚至0解封後,也不用提刪,而直接g8刪去永封模板。--蟲蟲飛♡♡→♡℃※留言 2020年2月22日 (六) 07:10 (UTC)
- (&)建議:此外,管理員大量刪除破壞者的頁面,也是無須提刪,因此可能加註則較容易處理;或者修改g8及g15也行。不過不改,也問題不大,因為這算是IAR,過去多年都是這樣處理。--蟲蟲飛♡♡→♡℃※留言 2020年2月22日 (六) 07:44 (UTC)
- 這算個傳統吧,大部分都是這樣做的,既然要IAR,我的想法是在方針中明確說明,當然要IAR也不是不行。--Hamish論 2020年2月22日 (六) 10:48 (UTC)
- (?)疑問,何謂「前述要求」?在Wikipedia:管理員中並沒有提到有關前述。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2020年2月22日 (六) 09:01 (UTC)
- 那個「前述要求」是指「管理員不得刪除自己提議刪除或者投票刪除的頁面」這個,原文措辭不當,已修改。--Hamish論 2020年2月22日 (六) 10:48 (UTC)
- (?)疑問:雖然管理員也可以對條目提報快速刪除,但如果條目明顯符合快速刪除準則,為什麼不直接刪掉,還要經過提名程序?還不如管理員自己訂內規,哪些情況可以不經提名直接刪除就好(我也相信管理員內部會有如此共識),這樣也不用動到這條。Poem(留言) 2020年2月22日 (六) 14:07 (UTC)
- 基本上所有頁面都不能直接刪去,但有些如g15,有些管理員會等機器人提刪,有些不等,刪去等於符合IAR,即操作對維基有實際好處才用這條,g8是不可能提刪,因為全永封用戶頁是被全保護的,刪除以便移動也不可等其他人提刪。大量刪除破壞者頁面,是運用IAR,即對維基有好處。維基對於頁面的刪除是很審慎的,如果管理員可以隨意刪除,很多政治條目肯定會被無故刪去。--蟲蟲飛♡♡→♡℃※留言 2020年2月22日 (六) 14:41 (UTC)
- 改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)
- 本討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。
建議管理員三權分立
依部分用戶所請關閉。SANMOSA SPQR 2020年11月9日 (一) 07:09 (UTC)
- 下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。
誠然,現在的維基百科已經很穩定了,但我仍不能相信以後會不會發生由於管理員權力集中而導致的災難,或許可以說,這是一定的,管理員可以立方針,可以處罰,還可以執行處罰,我想起了一句話「當立法者,司法者,和行政者三者在一起的時候,就沒有任何自由了」雖然我似乎有些杞人憂天,但從另一個角度來講,把三個職位分開或許更有效率,我的意見是將現有管理員拆分為三個職位,分別是
- 方針設立管理員
- 判罰管理員
- 處罰管理員
方針設立管理員只能完成對於方針的建設和修復,判罰管理員只能對方針做合理解釋做判罰(合理解釋即為不超過語義,比如某路說禁止驢馬通行,而有一隻駱駝過去,是不應當被判罰的)另外,我認為如果被判罰者在違反方針時是違反的,但方針日後修改說明他不需要被罰,那他就不被罰,而其他的情況均應當以判罰時的方針為準,處罰管理員應當只處罰判罰管理員所要求的判罰,並不能加減處罰,而且,處罰管理員有權駁回處罰,並要求其他判罰管理員重新判罰。這是我對維基百科管理員職位的意見,望各位採納 --Catowen 2020年11月8日 (日) 00:45 (UTC)
- 管理員有避嫌規則;方針是社群討論的結果;其他管理員都可以處理不合理封禁。怎麼說呢…建議您還是先完整地看一下與這些有關的規則。--安憶Talk 2020年11月8日 (日) 01:20 (UTC)
- 設立方針及提議設立方針非管理員之專利。SANMOSA SPQR 2020年11月8日 (日) 02:50 (UTC)
- 題主所述的問題是真實存在,但我認為這問題無法解決。這就好比小國在聯合國大會提案要求取消安理會五大流氓的一票否決權,必然會被大國一票否決。--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)
- 此外,若說三權:立法權在社群、行政權在基金會、司法權在管理員。--光貓貓 Talk理性、證據、辯論 2020年11月8日 (日) 05:19 (UTC)
- @Catowen:(!)抗議設立「方針設立管理員」。現行制度,方針是由社群共識決定的,任何維基百科編者,無論資歷深淺,都有權提出方針提案或修正案,且通過與否,要經由社群共識檢驗,若社群無共識,方針提案就不應該通過。如果訂立方針變成一個職位,不就變成皇帝了,維基帝國危機帝國維基危機。哪會自由,直接獨裁化了吧,這種提案必須(!)抗議抗爭到底。小心到時基金會行動直接把中文維基給關掉,咱們都不用玩了。-- 來人啊,餵宮子吃布丁! ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2020年11月8日 (日) 08:43 (UTC)
- 建議你維實施議行合一制度,選出維基議會,在上面再選一個議會的理事會,再分出三個權來,必要時維基基金會中央可以直接把議會及其理事會解散了。[開玩笑的]--向前進!向前進!朝着勝利的方向!(留言) 2020年11月8日 (日) 12:55 (UTC)
- 我只能說樓主了解管理員制度後再來……Fire Ice 2020年11月8日 (日) 13:14 (UTC)
- 管理員當然有特權,可以自我解封,所以有沒有什麼辦法阻止管理員自我解封。--Googol19980904(留言) 2020年11月8日 (日) 14:19 (UTC)
- 現在管理員又能自我解封了?我記得上次測試的時候,自己把自己封禁後,還是叫別的管理員解封的.....--百無一用是書生 (☎) 2020年11月9日 (一) 02:00 (UTC)
- 應該不行吧,要麼就是Googol19980904致遠星歸來,要麼請一位管理員親身驗證下。——Sakamotosan路過圍觀杯弓蛇影| 避免做作,免敬 2020年11月9日 (一) 03:22 (UTC)
- 那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)
- 我記得看過一個設置,是限制了這種自解封的。——Sakamotosan路過圍觀杯弓蛇影| 避免做作,免敬 2020年11月9日 (一) 05:34 (UTC)
- 現在管理員又能自我解封了?我記得上次測試的時候,自己把自己封禁後,還是叫別的管理員解封的.....--百無一用是書生 (☎) 2020年11月9日 (一) 02:00 (UTC)
- 月經提議。🌜山西特產批發零售™️🌽🌶️🍎🍠🐓🐐(留言) 2020年11月9日 (一) 03:09 (UTC)
- Snow. 了解維基制度後再來,連怎樣運作都不知道就先別提案-某人✉ 2020年11月9日 (一) 03:43 (UTC)
- 本討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。