维基百科讨论:封禁方针
![]() 存檔 |
---|
|
編輯請求 2024-01-28
请求已拒绝
解除临时性质的封禁一章中“临时性质的封禁应当在确认情况已解决的时候解除,此包括:
......
获得审核批准或已修复故障的机器人;及”
其中“获得审核批准或已修复故障的机器人;及”一行语意不明,应该删去“;及”。--阿米娅激推(留言) 2024年1月28日 (日) 09:16 (UTC)
未完成:
--Cookai餅塊🍪(💬留言) 2024年1月28日 (日) 10:42 (UTC)不再用作開放代理伺服器的IP位址及區段;↲ 獲得審核批准或已修復故障的機器人;及↲ 已撤回的法律威脅。
- 依然没见到改动,我看到的仍然是“获得审核批准或已修复故障的机器人;及”而非上者。--阿米娅激推(留言) 2024年1月28日 (日) 11:20 (UTC)
- 請看下去。--Cookai餅塊🍪(💬留言) 2024年1月28日 (日) 11:22 (UTC)
- 那么改动应该是“不再用作开放代理服务器的IP地址及区段;↲ 获得审核批准或已修复故障的机器人;↲ 及已撤回的法律威胁。”除此之外在“不应解除封禁的情况”一节中也是这个问题。已查看源代码。--阿米娅激推(留言) 2024年1月28日 (日) 11:24 (UTC)
- 您若認為不適,可至WP:互助客棧發起討論。這並非個例,此用法在這頁就用了5次。個人認為把「及」放在後面的原因可簡單解釋為「那不重要」。
- A項;
- B項;
- C項;及
- D項;
- 和
- A項;
- B項;
- C項;
- 及D項;
- 顯然是前者能較明確展示各項。--Cookai餅塊🍪(💬留言) 2024年1月28日 (日) 11:38 (UTC)
- 您若認為不適,可至WP:互助客棧發起討論。這並非個例,此用法在這頁就用了5次。個人認為把「及」放在後面的原因可簡單解釋為「那不重要」。
- 依然没见到改动,我看到的仍然是“获得审核批准或已修复故障的机器人;及”而非上者。--阿米娅激推(留言) 2024年1月28日 (日) 11:20 (UTC)
进一步增修封禁方针以及建立封禁申诉的本地共识
- 下列討論已經關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
User:LuciferianThomas(路西法人,或称路君)于2023年3月提出了封禁方针的重大修订,尽管方针大部分内容引自英文版方针。
在2024年2月我因不当行为被不限期封禁之后(不到两天被解封),有用户在我讨论页评论的时候仍把“不限期封禁”称为“永久封鎖”,这明显违背了“不限期封禁”方针所制定的目标“不代表该封禁永恆不可變”。而我被封的时候也看到了路君的回复,也是自此时开始即对封禁方针进行了重新翻阅,又看了英维里的方针,发现有部分方针内容是需要改进的,尤其是“不限期封禁”方针需要进一步修订,毕竟“永久封鎖”的说法在英维里早就被“否定”了。
结合当前情况考虑,我提议对封禁方针的部分内容作出增修,重点修订“不限期封禁”方针,同时新增“请求封禁”方针以及修订“解除封禁”方针(小修改)。另外我提议建立封禁申诉的本地共识。以上工作的目的是,填补过去中维在封禁方针指引上的漏洞,让相关方针指引如同英维一样健全,将封禁方针指引更加程序化、系统化。提议共四条(章节),请大家分章节讨论,谢谢。
还有必要称呼“永久封鎖”吗?
|
在路君修订“不限期封禁”方针之前,封禁方针关于“永久封禁”的方针内容如下:
永久封禁是一个永不失效的封禁。永久封禁通常用于防止严重干扰或威胁维基百科正常运作的行为,或严重侵犯维基百科政策的行为。这能避免该用户的行为产生更多的问题。 对于社群来说,永久封禁一个用户可被理解为完全禁止该用户进行编辑(如无管理员解封的话)。但在一般情况下,我们建议给该用户一个最后机会——在某段时间暂时解封该用户,并在被观察的情况下继续编辑,以确保该用户未来不再违反维基百科的政策。
虽然修订后已将其更名为“不限期封禁”,但条文中仍提到“或稱永久封鎖”。2024年2月我被无限期封的时候,也一直以为就是永久封鎖,永远不给解封了。按照方针所述“不限期封鎖並不代表永恆不可變,而僅代表未有訂立封鎖時長,封鎖不會自動過期解除”,另外用户确有反省不再违规的话是可以解封的。因此,严格来说“永久封鎖”这个说法不妥当,这会对用户造成误解,而且这是前后矛盾,模棱两可。而且“永久”和“不限期”本身意思和真实语景应用中有很大区别(大家可以上网搜索)。在英文版方针中有一句话直接“否定”其为“永久封禁”:
Indefinite does not mean "infinite" or "permanent"
意思就是,“不限期”不应理解为“无限”或“永久”。但基于中文语境情况,我提议修订的条文改为“不应理解为‘永久’或‘终身’”。
同样,我在英文版的封禁申诉指引也找到了这一句话:
"Indefinite" does not necessarily mean "forever" or "infinite". It means "however long is needed for the user to address the issue". This can be minutes, hours – or indeed the user may never do so.
意思是,“不限期”不一定是“永久”或“无限”。其意思是“用户需要多长时间来解决问题”。这可能是几分钟、几小时——或者实际上用户可能永远不会这样做。
为了避免对其他用户造成进一步的误解,我提出修订建议,参照英維的方针作进一步修订,具体提议内容见上。--Shwangtianyuan 不忘初心 牢记使命 2024年4月2日 (二) 16:08 (UTC)
- 支持修订。不赞成“终身”,非“无限”就足够了。--YFdyh000(留言) 2024年4月2日 (二) 16:34 (UTC)
- 不反對如此修訂。Sanmosa Szégyen a futás, de hasznos 2024年4月3日 (三) 07:48 (UTC)
- 我在文內保留括號(或稱永久封鎖)是基於讓後來的人能再查看前人所說「永久封鎖」是什麼意思,如果連括號都容易造成誤會,那麼也請改成註釋,寫例如
無失效時限的封鎖曾稱為「永久封鎖」;因與實際意義不相符而在2023年3月[[Special:Diff/XXXXXX|修訂方針]]後改為現稱。過往稱「永久封鎖」的意思應視同「不限期封鎖」之意,同樣非「永久不可變」;詳見§ 不限期封鎖一節的第二段。
這樣。 - 另外我記得當初我決定寫「不限期」而不是「無限期」是因為後者中的「無限」容易誤導他人以為是「infinite」的意思。我不清楚YF的意思是怎樣,但提案人所列出「不應理解為終身」我認為是相當合理的。--路西法人 2024年4月3日 (三) 09:36 (UTC)
- 個人不反對註釋化處理,@Shwangtianyuan、YFdyh000。Sanmosa Szégyen a futás, de hasznos 2024年4月3日 (三) 10:25 (UTC)
- 可以。只是不赞成引入“终身”用词,封禁是针对账号而非诉诸人身的,虽然禁止绕过封禁。--YFdyh000(留言) 2024年4月3日 (三) 11:10 (UTC)
- 文內正是說「不應理解為終身」,本來就是說「不是」,不知道你是在反對什麼……?--路西法人 2024年4月3日 (三) 15:03 (UTC)
- 有时封禁的是账号(对于用户名违规),身更接近实体,不想将此概念混入。如“不应理解为终身”可能理解为有期限的封禁身。--YFdyh000(留言) 2024年4月3日 (三) 16:06 (UTC)
- 「不應理解」ABC不等於「可以理解為」DEF。「不應理解為終身」本來就只有「不應理解為終身」的意思,任何其他理解都是超譯,不需考慮。--路西法人 2024年4月4日 (四) 12:40 (UTC)
- 有时封禁的是账号(对于用户名违规),身更接近实体,不想将此概念混入。如“不应理解为终身”可能理解为有期限的封禁身。--YFdyh000(留言) 2024年4月3日 (三) 16:06 (UTC)
- 文內正是說「不應理解為終身」,本來就是說「不是」,不知道你是在反對什麼……?--路西法人 2024年4月3日 (三) 15:03 (UTC)
- 标注注释的话应该没什么问题,虽然它并不一定是永久性的。--Shwangtianyuan 不忘初心 牢记使命 2024年4月3日 (三) 14:58 (UTC)
- 根據上述意見於2024年4月4日 (四) 05:43 (UTC)代為調整提案。Sanmosa Szégyen a futás, de hasznos 2024年4月4日 (四) 05:43 (UTC)
- 基本上认可修订后的提案。--Shwangtianyuan 不忘初心 牢记使命 2024年4月4日 (四) 14:04 (UTC)
新增“请求封禁”方针
参照其他项目及其他语言版本的封禁方针,提议新增“请求封禁”方针,内容在“不適用封鎖的情況”之后,“封禁指导”之前,以此将封禁方针更为程序化。具体如下:
用户可以在当前的破坏页面或者在管理员布告板/其他不当行为页面请求封禁,请求的同时亦应提供充分的证据,但管理员有权拒绝执行被请求的封禁,并可以进行独立的调查。在实施封禁之前,管理员应当充分熟悉具体情况。参见解釋封鎖原因。
待方针通过后,建立快捷方式WP:BLOCKREQUESTS和WP:BLOCKREQ。--Shwangtianyuan 不忘初心 牢记使命 2024年4月2日 (二) 16:08 (UTC)
- 原则上支持。提供充分的依据是否更好,证据不能覆盖方针,理据不能覆盖证据。“被请求的封禁”称“封禁请求”就好。未理解“并可以进行独立的调查”的强调原因,何为独立的调查,是独自调查还是能发起单独调查、询问或征询,有无具体要求。--YFdyh000(留言) 2024年4月2日 (二) 16:34 (UTC)
- 同YFdyh000。除此以外,我覺得AN3是否屬於潛在可請求封鎖的場所也值得探討。Sanmosa Szégyen a futás, de hasznos 2024年4月3日 (三) 07:53 (UTC)
- 贊同,但應避免直接列出對應頁面,始終理論上什麼地方都可以用來請求封鎖:例如社群在客棧達成封鎖某名用戶的共識,也是一個非常邊緣但完全合理合規的請求封鎖模式。提案人可考慮將擬新增條文中列出頁面的位置改成「用戶可於適當的佈告板上提出封鎖請求」。
- YF所指也是應當參考,可以考慮改成「須附上清晰理據,例如用戶違反了什麼方針指引、如何構成不當行為等。」(後面不需要「但」管理員了,這個轉折似乎沒太大必要。)
- 我建議可以改成這樣:
- 用戶可於適當的佈告板提報不當行為,並必須附上清晰理據,例如用戶違反了什麼方針指引、如何構成不當行為等。管理員在接獲提報時應自行複檢提報所列理據是否有效,並在符合本(封鎖)方針規定下執行封鎖。若管理員認為提報有問題(如不符合實際情況、不符合方針賦予管理員封鎖的情況),則有權拒絕提報。--路西法人 2024年4月3日 (三) 09:46 (UTC)
- 基本接受阁下的方案,没什么问题。反正,报告请求就是需要提供有效、足以证明的证据,证据不足或者不符合的都应予拒绝。--Shwangtianyuan 不忘初心 牢记使命 2024年4月3日 (三) 15:00 (UTC)
修订“解除封禁”方针
模板第二次機會是重新赢得社群信任的一种手段,主要针对过往有破坏、扰乱性编辑的用户。但中维因为方针没有提及,导致此模板一次都没用上。我在这里也是提议引入英维的方针,将“第二次機會”成为本地方针。具体内容如下:
如果用户声称希望做出建设性贡献,但管理员对其承诺存在疑问,则可以使用{{第二次機會}}模板作为解除封禁的条件,来展示用户将如何为百科全书做出贡献,以此相信用户提出的修改能够帮助维基百科。
拟引入的方针待通过后,提议加入于“封禁申诉”一节,在“任何用户均可参与……”之前。--Shwangtianyuan 不忘初心 牢记使命 2024年4月2日 (二) 16:08 (UTC)
- 这个想法很好。虽然我对被封禁者重新写的条目的质量很不乐观,但至少让他们审视一下自己写的条目也是好的。--ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨᡩ᠋ᠠᠨMandan 2024年4月3日 (三) 03:52 (UTC)
- 不反對如此修訂,我不清楚PoisonHK算不算一個例子。另外,建議將“聲稱”改為“聲明”,中文裏“聲稱”通常伴隨著負面的用法,在中性的行文裏用可能不太合適。Sanmosa Szégyen a futás, de hasznos 2024年4月3日 (三) 07:49 (UTC)
- 這不錯啊。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年4月4日 (四) 15:45 (UTC)
- (+)支持。--冥王歐西里斯(留言) 2024年4月11日 (四) 09:58 (UTC)
公示
依照WP:共识#提案討論及公示時間,互助客棧中的提案僅在7日內無新留言時或已討論達30日後,方可在已取得共識的前提下公示,其中“新留言”不包含不對提案進行實則性點評的意見。有鑒於此討論串中最近一個對提案進行實則性點評的意見在2024年4月4日 (四) 14:04 (UTC)發表,此處已滿足公示的條件,故現公示上述3個提案7日。Sanmosa Szégyen a futás, de hasznos 2024年4月11日 (四) 15:58 (UTC)
- 本討論已關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
管理操作复核的议题
原标题为:提议设立请求封禁机制以及扩大AARV的使用
提议设立请求封禁机制以及扩大AARV的使用
我建议社群考虑设置类似“请求封禁”的机制,即对于非纯破坏行为,有共识后再执行封禁,而非管理员独自判断引起争议。
对于解封请求,我建议扩大WP:AARV的使用,申请人可以选择请求任何一名用户协助提出AARV,由社群进行判断封禁是否适当。
提请各位讨论,有关方针条文也请踊跃发表。--桐生ここ★[讨论] 2024年6月14日 (五) 07:53 (UTC)
- Ping有对提案发表意见的人@日期20220626、ChiuHsiao1221、Shwangtianyuan、HYHJKJYUJYTTY。--桐生ここ★[讨论] 2024年6月14日 (五) 07:55 (UTC)
- 本人是(+)支持,社群考慮設定類似「請求封鎖」的機制,確實能解決很多不必要爭議,非純破壞行為,至於解封請求,建議擴大WP:AARV的使用,我也支持,--HYHJKJYUJYTTY(留言) 2024年6月14日 (五) 08:10 (UTC)
- 本人亦是倾向(+)支持。针对某位编辑账号的封禁无异于是在维基百科范围类对某人“执行死刑”。既然现实里文明国家的死刑都有复核和救济制度,那我认为维基社群也应该考虑。除了机器人账号或纯粹破坏行为外,针对其他行为的封锁账号行为要给于“拟被封所账号者”一个申诉和申请复核的渠道。--Chiu Hsiao (✉️Message) 2024年6月14日 (五) 08:20 (UTC)
- 原則上同意擴大AARV,但實際執行上對社群整體正確解讀及執行方針有極大疑慮。在社群本身已經存在失能、有不少用戶連最基本的方針指引都願意無視的情況下,我不認為當前的社群整體而言有足夠能力作出完全合乎方針指引及背後原則理解,以此判讀管理人員的管理行為是否恰當。光是社群中仍對於「不限期」錯誤理解為「永久」或「比其他更重」的觀點(WP:不限期不等於永久才是正確理解)已經反映社群缺乏判讀封鎖是否恰當的能力。在多個解封案例中,多名用戶未有真的分析封鎖理據、沒有考量方針指引要求、未有從執行人的視角去看事件,甚至只是因為跟管理人員的個人恩怨就直接提出反對,反映社群缺乏作此判斷的能力。原則上AARV是一件好事,但實際需要達到的效果目標及需要的技巧跟擔任仲裁員無異;而仲裁委員會都尚會是社群經選舉選上去的一群人,AARV的參與社群卻是未經社群檢視資質的用戶技能參與,粗暴點說就是平民版仲裁,跟仲裁委員會的公信力還要差個天差地別。
- 請求封鎖有極度嚴重社群程序官僚化及暴民政治的風險,如同上方所述,社群整體而言本身缺乏正確判讀什麼情況適合或不適合封鎖的能力,也往往主張採取不足以阻截擾亂編輯的措施。請求封鎖涉及管理員權限,又是由誰來判讀共識又是一大問題:社群本身缺乏判讀共識的能力(永遠只會點人頭而不看論據強弱),管理員自己判讀共識又產生一個會起疑的點,簡單來說就是沒解決任何問題,還產生了更多的問題的提案。--路西法人 2024年6月14日 (五) 09:57 (UTC)
- 反對引入仲裁制度的人,卻提案引入一個目標近似仲裁的機制,但這機制極度取決於社群能力(惟社群已經展現其失能),卻也完全沒有仲裁要求的嚴謹。在社群缺乏有關判斷能力、扭曲理解方針、無視方針原則的行為獲得控制前,AARV就只是一個跟當前RFDA沒分別,只會製造更多爭議的體制。--路西法人 2024年6月14日 (五) 10:27 (UTC)
- 那这么说吧,蓝桌的调查报告很好,如果封禁非纯破坏用户前,要求管理员写一份调查报告呢?--桐生ここ★[讨论] 2024年6月14日 (五) 11:11 (UTC)
- 包括所有差异链接,逐条说明为什么违反方针,决定量刑多久,决定量刑的理由。如果当事人怎样做可以获得原谅和解封。或者遭不限期封禁者,多久之后提出申诉可以考虑解封。--桐生ここ★[讨论] 2024年6月14日 (五) 11:17 (UTC)
- 管理員在封鎖理據中已經提供理由和對應的diff即可視作已提供封鎖報告。如果處理每一個非破壞用戶都需要這樣寫的話,用意是好但極度官僚,手續過多可能導致願意處理此類封鎖的管理員越來越少,反而變成放任了這些擾亂者繼續搞事。不過,我是同意可以要求管理員在執行不限期封鎖時在封鎖訊息下寫出不限期封鎖的考量,並在有可預見的改善可能(即不屬VOA、SPA或再次封鎖的用戶)情況下提供WP:不限期不等於永久的說明,並寫說需要對方瞭解什麼方針指引即可獲得解封(第二次機會)。
- 至於詳細的封鎖報告,則應是在AARV或仲裁的情形下提供。惟發起AARV的門檻過低,除了擔憂AARV參與者素質外,還擔憂會被濫用以針對特定管理員,製造毫不必要的工作量。--路西法人 2024年6月15日 (六) 00:24 (UTC)
- 你维管理员封禁此类人士已经圣母到极致,若是再加调查报告这种减速带我看你维是不想请捣乱的人离开了?--0xDeadbeef (留言) 2024年7月6日 (六) 16:16 (UTC)
- Wikipedia:管理员布告板/编辑争议和Wikipedia:管理员布告板/其他不当行为已经复杂到我不愿意碰了,再弄这个的话更不会没事去看了....--百無一用是書生 (☎) 2024年6月17日 (一) 02:14 (UTC)
- 包括所有差异链接,逐条说明为什么违反方针,决定量刑多久,决定量刑的理由。如果当事人怎样做可以获得原谅和解封。或者遭不限期封禁者,多久之后提出申诉可以考虑解封。--桐生ここ★[讨论] 2024年6月14日 (五) 11:17 (UTC)
- 社群針對此議題是不是討論過不少次了?為什麼我感覺幾個月以前纔有一次。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月14日 (五) 12:50 (UTC)
- 基本上這種制度是聊勝於無,比起現在的情況肯定是利大於弊。但也要指出,管理員執行封鎖操作時,理論上已經要確定當事人違反本站政策,「独自判断引起争议」可以是對管理員裁量權的事後合理質疑,但不是限制管理員行使封鎖權限的前提。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月14日 (五) 12:52 (UTC)
- 支持,帮助明确共识。但裁量权目前还是得有。--YFdyh000(留言) 2024年6月14日 (五) 14:24 (UTC)
- 理解提案的用意,樂見其成。但在實踐上可能會如路西法人君所說產生更多問題,或許會造成另一個管理員布告板。明白提案及用戶對管理權運用的憂慮。-千村狐兔(留言) 2024年6月14日 (五) 15:53 (UTC)
- 註:此留言已被原作者(User:月都)移除。
- 我覺得也應該探討一下為什麼管理員們不願意碰WP:ANMWP:AN3,如果ANM、AN3都不願意碰,再開一個AARV事實上只會讓管理員的事情變更多,我想這某種程度上並沒有解決問題,反而多了另一個問題,再提醒一下管理員也是"志願者"。
- 社群願意的話亦可探討為什麼管理員越來越不活躍,還有什麼方法吸引管理員回來幫忙掃地,或是另外尋求一條出路解決這個問題。--~~Sid~~ 2024年6月17日 (一) 13:04 (UTC)
- 額外補充我並不是要反對提案,只是不希望社群設立之後卻沒有達到預想的效果。--~~Sid~~ 2024年6月17日 (一) 13:05 (UTC)
- 以“有共識後再執行封鎖”來處理“管理員獨自判斷”的潛在弊端可能不符比例原則,我更傾向於引入類似助言的機制,要求管理員在執行不限期封鎖前應先取得至少一位未涉事的第三方用戶的同意,以確保所有不限期封鎖的執行都不違反比例原則。Sanmosa Snipe–Clam Grapple 2024年6月18日 (二) 13:35 (UTC)
- 我認為這個方法可行。--~~Sid~~ 2024年6月18日 (二) 14:59 (UTC)
- 少打字,修正留言。~~Sid~~ 2024年6月18日 (二) 15:00 (UTC)
- 不合適。破壞者還要助言?說這是明顯例外吧,但又有什麼應該是例外呢?到頭來還是要爭吵。如此官僚主義弊病過重,我想事後複查比事前在那邊極其複雜地商榷認定界線要容易得多。另外我還是要指出,理論上若管理員是依據社群討論通過的方針與指引執行封鎖,就是在確保社群共識得到實踐;故除理據不清之外,通常不能說管理員「未依共識」執行封鎖,至多是對方針與指引認知有爭議。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月18日 (二) 17:46 (UTC)
- 啊,我忘了提及「非純破壞行為」的前設。Sanmosa 蚌埠 2024年6月19日 (三) 05:47 (UTC)
- 支持@Sanmosa的助言机制,这个方法应该可行。--桐生ここ★[讨论] 2024年6月20日 (四) 19:20 (UTC)
- 有点怀疑“未涉事的第三方用户”的评判可能出现争议,并可能使部分用户有意避嫌、延后表态(私下抱团沟通)。--YFdyh000(留言) 2024年6月21日 (五) 11:57 (UTC)
- 關於「私下抱團溝通」,根據WP:共識,僅建議不應私下討論維基百科相關的事項,個人建議需更改這段的用詞至嚴禁私下討論維基百科相關的事項,並配合利益申報 (如該名編輯者曾在外站討論,則應當「涉事用戶」處理並應主動向社群申報),否則的話也沒有意思。關於最近私下討論的例子,就是路西法人的共識議案,完全將跳過了共識形成過程便產生共識,此不合程序公義。如果之後AARV容許私下抱團溝通,那只好反對。
- .
- 「維基外的討論。我們不鼓勵編者在其他網站、論壇、聊天工具、電子郵件或其他本專案外的地方討論。這些討論在「維基內」決定共識時是不予考慮的,並在它們被揭發後會引發猜疑和不信任情緒。儘管我們需要在維基外討論少數問題以顧及隱私,但絕大多數維基百科相關的事項都應在維基百科上討論,這樣它們將對所有參與者可見。」--唔好阻住我愛國(留言) 2024年6月21日 (五) 12:40 (UTC)
- 我認為這個方法可行。--~~Sid~~ 2024年6月18日 (二) 14:59 (UTC)
- 我覺得與其在客棧提案(現行寫法),不如改置管理員布告板的子布告板(可命名為「管理操作覆核」),集中處理涉及高階權限的使用行為。既有之「其他不當行為」子布告板,則繼續留作解決普通使用者爭議之處。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月24日 (一) 01:09 (UTC)
- (+)支持。--桐生ここ★[讨论] 2024年6月29日 (六) 21:17 (UTC)
- 誠如書生君所言,本站處理相關問題之場所一向不缺——Wikipedia:管理员布告板/编辑争议和Wikipedia:管理员布告板/其他不当行为。所以這個與前列兩者分別何在?固然多一人一起討論如何行使權限,未嘗不可。但本站有足夠人手麼?在下甚是疑惑。本提案立意良善,但欠缺具體系統設計。坦白說,就是怕管理員濫權,但又沒有給管理員足夠配套。然後,調查事情不一定要管理員權限,所以又有多少人有能力且願意擔起此責?--J.Wong 2024年7月1日 (一) 13:46 (UTC)
- 我只是特别羡慕ja有这个;对于解封,en有这个,看起来都是和气的达成了共识,不知道为什么在zh,最后都是客栈吵得不可开交,甚至上RFDA解决。--桐生ここ★[讨论] 2024年7月1日 (一) 14:12 (UTC)
- 立意就是希望大家多用AARV,最后不用走到RFDA这一步。--桐生ここ★[讨论] 2024年7月1日 (一) 14:28 (UTC)
- 所以這次有提出過使用嗎?有空間容許第三方審核及說話的餘地嗎?--J.Wong 2024年7月2日 (二) 05:46 (UTC)
- 其實這次事件當中是見到Bluedeck有意願作出獨立調查,但本站社群之中,竟然未見有人願意伸出援手。
- 然後就去羨慕這個,羨慕那個……
- 縱觀整個討論,在下見到大家更關心程序,數夠票就下一步,甚少理會雙方所言是否在理,能否經得起第三方審核。如果這點不變,開再多討論空間,閣下都只能繼續羨慕。--J.Wong 2024年7月2日 (二) 05:57 (UTC)
- 立意就是希望大家多用AARV,最后不用走到RFDA这一步。--桐生ここ★[讨论] 2024年7月1日 (一) 14:28 (UTC)
- 我只是特别羡慕ja有这个;对于解封,en有这个,看起来都是和气的达成了共识,不知道为什么在zh,最后都是客栈吵得不可开交,甚至上RFDA解决。--桐生ここ★[讨论] 2024年7月1日 (一) 14:12 (UTC)
将管理操作复核设置为管理員布告板的子布告板
如题,见上方讨论,将管理操作复核设置为管理員布告板的子布告板,将作为集中處理涉及高階權限的使用行為。桐生ここ★[讨论] 2024年6月29日 (六) 21:23 (UTC)
- 或者是直接指定管理員布告板本身也行吧?要評估一下流量。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月30日 (日) 04:13 (UTC)
- 应该不行,管理員布告板本身没法提供那些AARV的规则。再说管理員布告板本身也没有人会去用,目前貌似只是一个为存在而存在的东西。--桐生ここ★[讨论] 2024年6月30日 (日) 07:32 (UTC)
- 其實也可說是「製造」用途⋯⋯ —— Eric Liu 創造は生命(留言・留名・學生會) 2024年7月1日 (一) 19:21 (UTC)
- 应该不行,管理員布告板本身没法提供那些AARV的规则。再说管理員布告板本身也没有人会去用,目前貌似只是一个为存在而存在的东西。--桐生ここ★[讨论] 2024年6月30日 (日) 07:32 (UTC)
关于被无限期封禁者的用户页清空问题
我有一个问题,就是根据观察,被无限期封禁者(及被全域锁定者、被WMF封禁者)的用户页基本上都会被清空,然后再挂上各类无限期封禁模板。请问清空用户页这点在中维有无相关规定指引?反正在英维,无限期封禁者的用户页不会被清空,只是会额外挂上无限期封禁模板而已。--BigBullfrog(𓆏) 2024年7月8日 (一) 03:32 (UTC)
- 请参阅这里。Python6345(留言) 2024年7月8日 (一) 05:50 (UTC)
- 這條文僅限indef封鎖。全域鎖定雖然實務上比照indef封鎖的方式辦理,但並無本地成文規定。全域禁制一般不是本地處理的。Sanmosa 蚌埠 2024年7月8日 (一) 05:58 (UTC)
- 由於 維基百科:不限期不等於永久 不是方針,故管理員可以清空使用者頁面。--唔好阻住我愛國(留言) 2024年7月8日 (一) 14:54 (UTC)
現時的傀儡方針中的在非登入狀態下進行編輯以誤導他人一節的描述為:
如使用多重IP位址進行編輯,以迷惑他人或違反上述原則,亦可視作是使用多重帳號的行為。
在臨時帳號正式使用後,將會改以cookie的方法分辨用戶。用戶在更換IP後仍為該臨時帳號,但不能使用第二個裝置登入該臨時帳號。考慮到有人會使用兩個或以上的裝置編輯以及cookie可以移除,請問是否需要規範臨時帳號與另一臨時帳號的關係(例如要求在其用戶頁表明關係)?此外,臨時帳號啟用後,只有部分用戶能查看其IP,由於IP地址是用戶私隱,故此是否需要規範何時才可以使用IP封鎖?--132.234.229.111(留言) 2024年8月5日 (一) 08:34 (UTC)
- 傀儡部分,应该是仅限于已注册并“正式”的用户(相对于这次IP Masking机制下的“临时”用户),可能需要适当的描述调整,或者补充一个关于用户类型的定义说明mw:User_account_type(正式用户、临时用户、IP用户)。
- IP部分,暂时只有管理员等拥有相应权限的用户可以查看,还是交由管理员去自行裁量某一组临时用户与IP的关系而判断是否连带IP(段)封锁,如果考虑IP隐私问题,或者单独IP(段)封锁并且涉及特定临时用户时是否声明这些关联。还有一个功能是“自动封禁该账号使用的IP地址”,暂时来看(Special:封禁列表),封锁一个用户并连带自动封锁对应IP段地址是不是不会显示相应地址段,应该已经技术上处理过这个问题(?)。——Sakamotosan路过围观 | 避免做作,免敬 2024年8月5日 (一) 09:15 (UTC)
- 可待技術措施正式出臺,再研議如何調整相關方針。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年8月14日 (三) 18:13 (UTC)