Bluedeck 歡迎您隨時留言
/頁面編輯之幫助/
[编辑]您好: 能幫我編輯第109回日劇學院賞的讀者、記者和評審票嗎? 因為本人現在比較忙,無法將剩下的頁面完成,有空的話您可以幫我一下嗎?----Ken1998225(留言) 2021年12月1日 (三) 01:00 (UTC)
投票通知:試行安全投票(SecurePoll)
[编辑]![](http://upload.wikimedia.org/wikipedia/commons/thumb/3/3c/Wiki_vote_box.svg/150px-Wiki_vote_box.svg.png)
由於2021年維基媒體基金會針對中文維基百科的行動暴露了本地社群自治的一些問題,社群展開了一連串的討論以嘗試修補此前選舉制度的漏洞。
參與討論的編者認為,使用安全投票(SecurePoll,一種維基媒體內部投票系統)可能可以解決一些既有問題,包括拉票等,但是是否施行此制度則需要社群共識決定。
據此,現決定舉行一場安全投票,以決定是否在管理人員選舉中試行安全投票制度。本次投票有三個問題,除了第一題為測試題以外,其他問題的結果都可能影響中文維基百科的未來發展。
本次投票之投票期為2021年12月11日 (六) 00:00 (UTC)至2021年12月25日 (六) 00:00 (UTC)。
- 關於安全投票:
- 保密:閣下投票之內容將獲得保密,除選舉管理員以外無人可以得知。本次投票將由基金會職員擔任選舉管理員。
- 自由:閣下投票後到截止前,可以任意改票。新的投票內容將覆蓋先前的投票內容。
- 公平:為避免傀儡操控投票結果,投票時將紀錄一些技術數據,此與閣下平常編輯維基百科時相同。
希望閣下能夠踴躍參與投票! MediaWiki message delivery(留言) 2021年12月11日 (六) 09:55 (UTC)
此訊息由大量訊息發送功能傳送給所有合資格投票人(包括延伸確認使用者或管理員權限持有者,在投票開始時被封禁者除外)。
如果您不希望在未來收到所有透過大量訊息發送功能發送的訊息,您可以在您的使用者對話頁內加入Category:不接受消息发送這個分類。
算法提問
[编辑]您好,想請問一下您身份驗證的 HIROSE-AES-256 要如何計算?哪裡找來這麼偏僻的算法(--拒食木瓜〽️心臓を捧げよ! 2021年12月19日 (日) 14:12 (UTC)
新年快乐,Bluedeck!
[编辑]通过将{{subst:新年煙火}}添加到用户对话页面来发送新年祝福。
How we will see unregistered users
[编辑]嗨!
因為您是維基媒體wiki的管理員,所以您收到此訊息。
現今當有人沒有登入就編輯維基媒體wiki時,我們會顯示他們的IP,也許您已經知道了,我們將無法在未來這麼做,這是由維基媒體基金會法律部門所做的決定,因為現在的隱私規範和規定已被修改。
我們將顯示隱藏的身分而非IP,您作為管理員仍然可以看到IP,對於那些需要看到未註冊使用者的完整IP以應對破壞、騷擾和垃圾訊息的非管理員,將提供新的使用者權限給他們,即使沒有此權限,巡查員也能夠看到部分的IP。我們也正在開發更好的工具來提供幫助。
如果您未曾知道此訊息,您可以在元維基了解更多資訊。如果您想要確保您不會錯過任何維基媒體wiki的技術變更,您可以訂閱每週的技術新聞。
我們有兩種此身分運作方式的建議,我們會非常感謝您認為在現在和未來對於您和您的wiki最合適的方式提供反饋,您可以在討論頁告訴我們,您可以用您的語言書寫,這些建議是在10月時發表,並且我們會在1月17日後做出決定。
谢谢您。 /Johan (WMF)
2022年1月4日 (二) 18:20 (UTC)
新年快樂!
[编辑]![]() |
新年快樂! 感謝您過去一年來對中文維基百科的貢獻!祝閣下新年快樂,萬事如意!—— Eric Liu 創造は生命(留言.留名.學生會) 2022年1月31日 (一) 17:57 (UTC)(模板使用方法參見此處)
|
图书馆存档来源时出错
[编辑]在oldid=70503222中,一位用户存档了一个页面。页面原本是正常的,但存到图书馆之后出现了参考来源错误。你能修一下脚本吗?--Q28(留言) 2022年3月7日 (一) 10:51 (UTC)
- 问题出在这里:
== 注释 == {{((}}Reflist|2|group="注"}}
- 因为很多模版自带分类,但是图书馆里的内容我不想让他显示在任何分类里,所以所有的模版都被“去模版化”(像这样{{((}})处理了。这导致reflist不显示,自然导致分类错误。我不能修改这个问题。Bluedeck 2022年3月8日 (二) 03:16 (UTC)
在座寫輕小說的各位,全都有病页面存废讨论通知
[编辑]![](http://upload.wikimedia.org/wikipedia/commons/thumb/e/ed/Icono_aviso_borrar.svg/40px-Icono_aviso_borrar.svg.png)
您好,您先前创建或编辑的页面「在座寫輕小說的各位,全都有病」已被提出存廢討論,正在討論该页面的存廢。
維基百科非常歡迎您的編輯,但請先看看編輯幫助和維基百科不是什麼,以免犯了常見的錯誤。
请不要自行移除页面存废模板,討論是因为有编者认为页面不適合维基百科。請参与頁面存廢討論,您亦可以與提刪的維基人進行溝通。在讨论期间歡迎繼續完善原先的页面,多謝合作!
幫助:互助客棧、刪除指導、存廢覆核請求、IRC聊天頻道--🚊。鐵路Railway 論 2022年4月11日 (一) 00:22 (UTC)
管理員布告板已經重啟
[编辑]管理員布告板日前已經重啟,歡迎 閣下監視該頁面,以即時處理管理員相關事務。當然,若已經監視,那自然是更好的。—— Eric Liu 創造は生命(留言・留名・學生會) 2022年5月15日 (日) 07:44 (UTC)
邀请您评估我编写的HanAssist小工具!
[编辑]您好,很抱歉打扰您!
为了解决中文维基百科小工具编写过程中的一些痛点(pain points),我编写了HanAssist小工具。它的文档位于此处,源代码位于GitHub上。
希望您可以评估此小工具是否能达到预期目的,并提出您宝贵的意见和建议。
互助客栈讨论区:Wikipedia:互助客栈/技术#介绍我编写的wgULS、wgUVS现代化替代品——HanAssist小工具
谢谢!--Diskdance 2022年6月22日 (三) 10:38 (UTC)
請教實時編輯衝突提示
[编辑]我已經複製 mw.loader.load("User:Bluedeck/serve/edit-conflict.js"); /*實時編輯衝突提示*/ 到User:葉又嘉/common.js 為何依然無法出現提示? 感謝指教--葉又嘉(留言) 2022年7月9日 (六) 04:06 (UTC)
蓝桌图书馆脚本建议支持存档旧版本
[编辑]即已打开的历史版本(oldid=)。目前始终存档条目的最新修订版本,有时我希望存档早期版本(如User:Bluedecklibrary/小南山文化)。存档历史记录信息就更好了(通过折叠或HTML注释),以及允许存档多个版本(到单独页面/历史记录;不过可能增加滥用性)。( π )题外话:[1]源码是手写还是转换过的,有点不太好读。ident作用不太懂,某种调试环境?源码是否默认采用网站的CC BY-SA 3.0许可,或者您另有偏好。--YFdyh000(留言) 2022年7月11日 (一) 21:13 (UTC)
![](http://upload.wikimedia.org/wikipedia/commons/thumb/e/ed/Icono_aviso_borrar.svg/40px-Icono_aviso_borrar.svg.png)
您好,您先前创建或编辑的页面「独裁宝典」已被提出存廢討論,正在討論该页面的存廢。
維基百科非常歡迎您的編輯,但請先看看編輯幫助和維基百科不是什麼,以免犯了常見的錯誤。
请不要自行移除页面存废模板,討論是因为有编者认为页面不適合维基百科。請参与頁面存廢討論,您亦可以與提刪的維基人進行溝通。在讨论期间歡迎繼續完善原先的页面,多謝合作!
幫助:互助客棧、刪除指導、存廢覆核請求、IRC聊天頻道--百战天虫(留言) 2022年9月24日 (六) 07:48 (UTC)
User talk:David S. Hwang的快速删除通知
[编辑]![](http://upload.wikimedia.org/wikipedia/commons/thumb/1/15/Ambox_warning_pn.svg/48px-Ambox_warning_pn.svg.png)
您好,有编者认为您创建的页面User talk:David S. Hwang内容不当,符合快速删除条件,该頁面很快会由管理员进行复核并决定是否保留。
維基百科非常歡迎您的編輯,但請先看看編輯幫助和維基百科不是什麼,以免犯了常見的錯誤。
请不要自行移除快速删除模板,快速删除旨在加快處理顯然不合適的頁面。若您认为删除理由不合適或您已对頁面做了改善,请在被提删页面快速删除模板的正下方加入{{Hang on}}
,并在頁面的讨论页中说明理由。您亦可以与提删的维基人进行沟通,多謝合作!
幫助:互助客棧 · 刪除指導 · 存廢覆核請求 · IRC聊天頻道--羅潔塔💎478940 2023年1月21日 (六) 03:28 (UTC)
新年快樂!
[编辑]![]() |
新年快樂! 感謝您過去一年來對中文維基百科的貢獻!祝閣下新年快樂,萬事如意!—— Eric Liu 創造は生命(留言・留名・學生會) 2023年1月22日 (日) 11:01 (UTC)(模板使用方法參見此處)
|
RM
[编辑]請求移動Template:AR/target至Template:Articleretrieval/target以統一命名--A1Cafel(留言) 2023年1月26日 (四) 11:04 (UTC)
Template:Good looking box页面存废讨论通知
[编辑]![](http://upload.wikimedia.org/wikipedia/commons/thumb/e/ed/Icono_aviso_borrar.svg/40px-Icono_aviso_borrar.svg.png)
您好,您先前创建或编辑的页面「Template:Good looking box」已被提出存廢討論,正在討論该页面的存廢。
維基百科非常歡迎您的編輯,但請先看看編輯幫助和維基百科不是什麼,以免犯了常見的錯誤。
请不要自行移除页面存废模板,討論是因为有编者认为页面不適合维基百科。請参与頁面存廢討論,您亦可以與提刪的維基人進行溝通。在讨论期间歡迎繼續完善原先的页面,多謝合作!
幫助:互助客棧、刪除指導、存廢覆核請求、IRC聊天頻道--A1Cafel(留言) 2023年6月29日 (四) 03:03 (UTC)
Need your input on a policy impacting gadgets and UserJS
[编辑]Dear interface administrator,
This is Samuel from the Security team and I hope my message finds you well.
There is an ongoing discussion on a proposed policy governing the use of external resources in gadgets and UserJS. The proposed Third-party resources policy aims at making the UserJS and Gadgets landscape a bit safer by encouraging best practices around external resources. After an initial non-public conversation with a small number of interface admins and staff, we've launched a much larger, public consultation to get a wider pool of feedback for improving the policy proposal. Based on the ideas received so far, the proposed policy now includes some of the risks related to user scripts and gadgets loading third-party resources, best practices for gadgets and UserJS developers, and exemptions requirements such as code transparency and inspectability.
As an interface administrator, your feedback and suggestions are warmly welcome until July 17, 2023 on the policy talk page.
Have a great day!Samuel (WMF), on behalf of the Foundation's Security team 2023年7月10日 (一) 12:08 (UTC)
Invitation to Rejoin the Healthcare Translation Task Force
[编辑]![](http://upload.wikimedia.org/wikipedia/commons/thumb/5/58/Wiki_Project_Med_Foundation_logo.svg/125px-Wiki_Project_Med_Foundation_logo.svg.png)
You have been a medical translators within Wikipedia. We have recently relaunched our efforts and invite you to join the new process. Let me know if you have questions. Best Doc James (talk · contribs · email) 12:34, 13 August 2023 (UTC)
關於藍桌圖書館擴充功能
[编辑]是否有可能在「圖書館」以外新增網際網路檔案館(或可簡稱為「檔案館」)之類顯示選項,便於尋找頁面存檔?—— Eric Liu 創造は生命(留言・留名・學生會) 2023年9月13日 (三) 14:54 (UTC)
- @Ericliu1912:请问这个档案馆的功能和图书馆的功能是何区别呢?存储的是图片还是维基源码呢,还是维基百科之外的内容。我有点没有理解。Bluedeck 2023年9月13日 (三) 16:37 (UTC)
- 其實就是已刪除內容查詢中常提到的「Wayback Machine」。很多人會存檔維基百科頁面到網際網路檔案館,雖然我不確定能不能從那裡面直接擷取維基原始碼,但肯定能就相關頁面提供有用資訊。—— Eric Liu 創造は生命(留言・留名・學生會) 2023年9月13日 (三) 16:52 (UTC)
- @Ericliu1912:也就是说,工具代替使用者搜寻一下Wayback Machine,然后显示wayback machine中的存档?Bluedeck 2023年9月13日 (三) 17:23 (UTC)
- 是的。—— Eric Liu 創造は生命(留言・留名・學生會) 2023年9月14日 (四) 02:57 (UTC)
- @Ericliu1912:哈哈,试了一下做不到,目前的浏览器安全政策要求被连接网站(也就是Wayback Machine)明确在连接前声明自己接受来自第三方网站页面脚本发出的连接,通过在HTTP报头说一句“Access-Control-Allow-Origin: ...”。由于Wayback Machine没有,所以浏览器会拒绝连接。Bluedeck 2023年9月16日 (六) 23:51 (UTC)
- 好吧 :( —— Eric Liu 創造は生命(留言・留名・學生會) 2023年9月17日 (日) 10:44 (UTC)
- @Ericliu1912:哈哈,试了一下做不到,目前的浏览器安全政策要求被连接网站(也就是Wayback Machine)明确在连接前声明自己接受来自第三方网站页面脚本发出的连接,通过在HTTP报头说一句“Access-Control-Allow-Origin: ...”。由于Wayback Machine没有,所以浏览器会拒绝连接。Bluedeck 2023年9月16日 (六) 23:51 (UTC)
- 是的。—— Eric Liu 創造は生命(留言・留名・學生會) 2023年9月14日 (四) 02:57 (UTC)
- @Ericliu1912:也就是说,工具代替使用者搜寻一下Wayback Machine,然后显示wayback machine中的存档?Bluedeck 2023年9月13日 (三) 17:23 (UTC)
- 其實就是已刪除內容查詢中常提到的「Wayback Machine」。很多人會存檔維基百科頁面到網際網路檔案館,雖然我不確定能不能從那裡面直接擷取維基原始碼,但肯定能就相關頁面提供有用資訊。—— Eric Liu 創造は生命(留言・留名・學生會) 2023年9月13日 (三) 16:52 (UTC)
邀請參與中文維基百科管治相關討論
[编辑]![](http://upload.wikimedia.org/wikipedia/commons/thumb/d/d1/Wikipedia_Administrator.svg/100px-Wikipedia_Administrator.svg.png)
2024年管理人員制度改革意向調查經已結束,調整管理人員上任標準、容許用戶獲得臨時管理員權限、設立仲裁委員會和修订管理员长期无活动解任方针已獲社群共識採納,目前正在討論實行的細節。請踴躍參與以上討論,提出建設性的意見。
MediaWiki message delivery(留言) 2024年1月5日 (五) 06:04 (UTC)
本条消息是使用群发消息功能发送给您的。如果您不希望在未来接受所有使用本功能发送的消息,请在您的讨论页加入Category:不接受消息发送这一分类。
新北市區公車綠5路線的快速删除通知
[编辑]![](http://upload.wikimedia.org/wikipedia/commons/thumb/1/15/Ambox_warning_pn.svg/48px-Ambox_warning_pn.svg.png)
您好,有编者认为您创建的页面新北市區公車綠5路線内容不当,符合快速删除条件,该頁面很快会由管理员进行复核并决定是否保留。
維基百科非常歡迎您的編輯,但請先看看編輯幫助和維基百科不是什麼,以免犯了常見的錯誤。
如果您想查看已刪除页面的頁面内容,您可访问已删除内容查询。如果您认为删除不当,请到存废复核请求处提出申请,多謝合作!
幫助:互助客棧 · 刪除指導 · 存廢覆核請求 · IRC聊天頻道--Mafalda4144(留言) 2024年1月13日 (六) 15:27 (UTC)
新北市區公車綠12路線页面存废讨论通知
[编辑]![](http://upload.wikimedia.org/wikipedia/commons/thumb/e/ed/Icono_aviso_borrar.svg/40px-Icono_aviso_borrar.svg.png)
您好,您先前创建或编辑的页面「新北市區公車綠12路線」已被提出存廢討論,正在討論该页面的存廢。
維基百科非常歡迎您的編輯,但請先看看編輯幫助和維基百科不是什麼,以免犯了常見的錯誤。
请不要自行移除页面存废模板,討論是因为有编者认为页面不適合维基百科。請参与頁面存廢討論,您亦可以與提刪的維基人進行溝通。在讨论期间歡迎繼續完善原先的页面,多謝合作!
幫助:互助客棧、刪除指導、存廢覆核請求、IRC聊天頻道--Mafalda4144(留言) 2024年1月13日 (六) 15:30 (UTC)
新北市區公車綠12路線的快速删除通知
[编辑]![](http://upload.wikimedia.org/wikipedia/commons/thumb/1/15/Ambox_warning_pn.svg/48px-Ambox_warning_pn.svg.png)
您好,有编者认为您创建的页面新北市區公車綠12路線内容不当,符合快速删除条件,该頁面很快会由管理员进行复核并决定是否保留。
維基百科非常歡迎您的編輯,但請先看看編輯幫助和維基百科不是什麼,以免犯了常見的錯誤。
如果您想查看已刪除页面的頁面内容,您可访问已删除内容查询。如果您认为删除不当,请到存废复核请求处提出申请,多謝合作!
幫助:互助客棧 · 刪除指導 · 存廢覆核請求 · IRC聊天頻道--Mafalda4144(留言) 2024年1月13日 (六) 15:45 (UTC)
新北市區公車紅38路線页面存废讨论通知
[编辑]![](http://upload.wikimedia.org/wikipedia/commons/thumb/e/ed/Icono_aviso_borrar.svg/40px-Icono_aviso_borrar.svg.png)
您好,您先前创建或编辑的页面「新北市區公車紅38路線」已被提出存廢討論,正在討論该页面的存廢。
維基百科非常歡迎您的編輯,但請先看看編輯幫助和維基百科不是什麼,以免犯了常見的錯誤。
请不要自行移除页面存废模板,討論是因为有编者认为页面不適合维基百科。請参与頁面存廢討論,您亦可以與提刪的維基人進行溝通。在讨论期间歡迎繼續完善原先的页面,多謝合作!
幫助:互助客棧、刪除指導、存廢覆核請求、IRC聊天頻道--Mafalda4144(留言) 2024年1月13日 (六) 15:58 (UTC)
Re: Slope_project
[编辑]Bluedeck君您好,谢谢您能关注这个计划。可惜的是,我只是在收集之前讨论中的主意,整理出一个框架或者说蓝图,计划提到phab看看有没人帮忙做。我本人没有学过现代的计算机语言(只有高中电脑课学过一学期VB,至于站内的js脚本都是我边抄边学的),可能没有开发这种项目的能力,非常抱歉! ——魔琴 [ 留言 贡献 新手2023计划 ] 2024年3月3日 (日) 08:11 (UTC)
Wikipedia:已删除内容查询/header2页面存废讨论通知
[编辑]![](http://upload.wikimedia.org/wikipedia/commons/thumb/e/ed/Icono_aviso_borrar.svg/40px-Icono_aviso_borrar.svg.png)
您好,您先前创建或编辑的页面「Wikipedia:已删除内容查询/header2」已被提出存廢討論,正在討論该页面的存廢。
維基百科非常歡迎您的編輯,但請先看看編輯幫助和維基百科不是什麼,以免犯了常見的錯誤。
请不要自行移除页面存废模板,討論是因为有编者认为页面不適合维基百科。請参与頁面存廢討論,您亦可以與提刪的維基人進行溝通。在讨论期间歡迎繼續完善原先的页面,多謝合作!
幫助:互助客棧、刪除指導、存廢覆核請求、IRC聊天頻道--鐵膠壹名 2024年3月24日 (日) 10:20 (UTC)
文明方針問題
[编辑]之前在不當行為提報區那裡,就有意見認為對於違反站內規則的處理方式是封禁而不是不文明行為(例如辱罵違規的人),而且假如沒有封禁這一措施,不文明行為本身也無法阻止違規的人繼續編輯。所以如果某人長期在站內辱罵他人,違反文明方針,而又沒有管理員出面處理,時間一長,是不是會讓人感覺那個人有站內不文明的特權?--日期20220626(留言) 2024年3月28日 (四) 12:13 (UTC)
回复通告
[编辑]阿米娅2011(留言) 2024年4月1日 (一) 11:13 (UTC)
給您的星章!
[编辑]![]() |
好主意星章 |
希望網頁版郵件申訴能夠早日落實,感謝貢獻! AT 2024年4月29日 (一) 09:15 (UTC) |
想问一下您对本站新变体对话框的看法
[编辑]之前一直想问您的看法都忘记问了,考虑到您是旧小蓝条的维护者,还是想问一下。--碟之舞📀💿 2024年4月29日 (一) 15:22 (UTC)
- 看到您的回复了。看上去您可能不了解背景,请见Wikipedia_talk:变体小助手#变体小助手第二版(有对话框截图)。这个小工具是我写的,替换掉了本站旧的变体跳转逻辑和小蓝条。工作机制请见[2]。
- 还有就是我订阅了这个话题,所以您直接在自己的用户页上回复我会收到通知(本站泪目新功能)。--碟之舞📀💿 2024年5月3日 (五) 15:19 (UTC)
- 哦这个呀,我早就看到过了,我当时还以为是MediaWiki官方的出品,哈哈哈。这个比蓝条好多了,本来蓝条就是为了别的东西而出现的,被套用在选择文字变体一直是驴唇不对马嘴的感觉。Bluedeck 2024年5月3日 (五) 15:22 (UTC)
- 另外我觉得桌面版设计的非常好,全部列出来非常易用,并且没有过多的挡住页面。Bluedeck 2024年5月3日 (五) 15:24 (UTC)
- 谢谢回复!那我就放心了。--碟之舞📀💿 2024年5月3日 (五) 15:28 (UTC)
问题
[编辑]看到过您在相关编者的讨论页留过言,好奇您会不会愿意处理 维基百科:管理员布告板/其他不当行为#日期20220626?(可以在这里直接回复,我会收到通知)--0xDeadbeef (留言) 2024年5月12日 (日) 11:13 (UTC)
- 目前的精力集中在unblock-zh上,并不打算处理uum/螺钉/日期相关的问题。Bluedeck 2024年5月13日 (一) 04:15 (UTC)
- OK--0xDeadbeef (留言) 2024年5月13日 (一) 07:37 (UTC)
管理人員選舉及問卷進行中
[编辑]![](http://upload.wikimedia.org/wikipedia/commons/thumb/d/d1/Wikipedia_Administrator.svg/100px-Wikipedia_Administrator.svg.png)
中文維基百科管理人員選舉正在進行,ASid、ATannedBurger、Manchiu、UjuiUjuMandan四名用戶參選管理員,另有行政員AT參選監督員。投票期為2024年5月29日至6月12日,誠邀您踴躍參與投票並表達對候選人的意見。
請注意管理人員選舉無當選限額,各候選人分開計票,支持票不限於一票。
社群亦正就未來仲裁委員會對管理人員除權的權力進行問卷調查,您可在上方投票链接找到表單匿名表達意見,或直接前往討論頁發表意見。
回饋請求服務已上線,誠邀您訂閱有興趣參與有關討論的話題。
MediaWiki message delivery(留言) 2024年5月29日 (三) 04:12 (UTC)
請管理員幫我移到妥協方案
[编辑]請移到我提出妥協方案版本,因為分拆沒共識,他狂打編輯戰,無視維基百科規則,用出巨魔行為--HYHJKJYUJYTTY(留言) 2024年6月7日 (五) 16:41 (UTC)
- 你们两人都违反了3RR,这个保护只能起到暂时作用,你们二人可以在这里尽量说出自己的编辑理由。如果1天后还不能解决此编辑争议,也不要因为保护结束继续打编辑战。要把底层的争议搞清楚。你可以先行说明一下自己编辑的理由。@u:Txkk你也要在这里说明一下你的理由。Bluedeck 2024年6月7日 (五) 16:46 (UTC)
- 我发你TG了。--Txkk(留言) 2024年6月7日 (五) 16:48 (UTC)
- 因為立法院改革爭議,是抗議主條目,法案只是背景,從頭到尾都是寫抗議,還有分拆沒有共識,還在討論,他就一直堅持自己主張,與事實不符--HYHJKJYUJYTTY(留言) 2024年6月7日 (五) 16:48 (UTC)
- 在還沒共識之前,他繼續搗亂維基,無視維基百科規則,惡意打編輯戰,我最後有提出妥協方案,在共識之前,都不要用,但他不聽,堅持自己主張搗亂觀點--HYHJKJYUJYTTY(留言) 2024年6月7日 (五) 16:51 (UTC)
- 討論:2024年立法院改革爭議,他應該繼續條目拆分討論,而不是打無意義編輯戰--HYHJKJYUJYTTY(留言) 2024年6月7日 (五) 16:56 (UTC)
- 妥協方案本身算是最好處理--HYHJKJYUJYTTY(留言) 2024年6月7日 (五) 17:03 (UTC)
- @Txkk请在这里讨论,否则HYH看不到。Bluedeck 2024年6月7日 (五) 17:07 (UTC)
- 他就堅持他的觀點,純亂,要不了早就這裡討論--HYHJKJYUJYTTY(留言) 2024年6月7日 (五) 17:09 (UTC)
- 他真的毫無理由巨魔行為--HYHJKJYUJYTTY(留言) 2024年6月7日 (五) 17:11 (UTC)
- 你還是移到妥協方案好了--HYHJKJYUJYTTY(留言) 2024年6月7日 (五) 17:12 (UTC)
- 他編輯理由就是沒有理由,認為自己就是對的,可惜與事實不符--HYHJKJYUJYTTY(留言) 2024年6月7日 (五) 17:14 (UTC)
- 他再不聽管理員的話,基本上是他真的沒有理由可以反駁,其實可以移到妥協方案--HYHJKJYUJYTTY(留言) 2024年6月7日 (五) 17:23 (UTC)
- 請回到2024年6月7日 (五) 15:11版本,要不了結束到,我主動恢復到妥協方案,他不要再無意議編輯戰--HYHJKJYUJYTTY(留言) 2024年6月7日 (五) 17:26 (UTC)
请讨论问题本身
[编辑]@u:HYHJKJYUJYTTY:为什么删去两个内部链接?可否给出简要的理由? @u:Txkk:如何从【4】号参考得知“被認為只是一部擴張了立法院權利的法案,並不是改革,同時引發了大規模抗議示威潮。”?4号参考的哪一部分内容能够说明这一点?请不要在TG回复。 两位编者请不要互相指责对方不符合方针,请就事论事。在这个章节下互相攻击的内容会被我删除。Bluedeck 2024年6月7日 (五) 18:05 (UTC)
- 刪去兩個內部連結主要是分拆沒共識,如果要加也是加立法院改革爭議的抗議主條目,我也加,但他打編輯戰,既然絕對反對,所以妥協方案就來了--HYHJKJYUJYTTY(留言) 2024年6月7日 (五) 18:14 (UTC)
- 原來是原創研究那就好解決,等解除,那就刪掉那段被認為只是一部擴張了立法院權利的法案,並不是改革,同時引發了大規模抗議示威潮不就好--HYHJKJYUJYTTY(留言) 2024年6月7日 (五) 19:06 (UTC)
- 既然有目前有两个条目,那么自然要内链到两个条目中去,我感觉这并不过分。你说分拆本身是没有共识的行为,如果是这样,那么等到分拆遭到了撤回,自然就可以撤回这两个内链。如果你想象一个体育场被一分为二,那么即使最后要合二为一,但是在合并前,开放两个入口,是不是很正常的想法?Bluedeck 2024年6月7日 (五) 19:24 (UTC)
- 第4号参考是当事者台湾民众党在今年1月15日发表的新闻稿,它是过时的来源,用作前面那句话(现况)的来源一点都不合适。之所以我没有动参考来源是因为当时该条目的内链不够多,不足以构筑百科全书的链接网络,我先把内链补齐再动参考来源。--Txkk(留言) 2024年6月10日 (一) 01:43 (UTC)
Easy Archive问题
[编辑]Wikipedia:互助客栈/求助#c-Wang31-20240609024200-Easy_Archive使用问题,我的讨论页也无法显示存档/删除按钮。但页面底部显示“ 本讨论页面使用 Easy Archive 快速存档(停用)。 存档地址:User_talk:ChasingAir/2024”。--ChasingAir留言 2024年6月10日 (一) 04:31 (UTC)
- 谢谢提报故障,我在客栈讨论这个问题了。Bluedeck 2024年6月10日 (一) 06:10 (UTC)
果仁蜜餅送給您!
[编辑]謝謝你的解封。 千村狐兔(留言) 2024年6月13日 (四) 00:58 (UTC) |
解封理由瑕疵
[编辑]- 首次发表与方针相违背言论本身并不是封禁的决定因素,在经纠正后持续试图强行曲解两方针属于游戏维基规则。游戏维基规则是封禁方针中的行为。
- Special:Diff/77127830/81797673中既然为翻译内容,却未在任何地方署名,已可见该用户违反CC-BY-SA之行为是系统性的。
- 编辑摘要中表示"从英文维基百科翻译"未提供条目名称、永久版本、作者列表、历史版本。维基数据项亦不固定。不符合CC-BY-SA对于来源的最低要求。("署名:当你使用维基百科的文字时,你被要求提供到你所引用页面的超链接或URL...")
- 英文维基百科是不可靠来源,从英文维基百科翻译无来源内容仍违反可供查证方针。添加内容的编辑有举证责任。
鉴于解封理由(尤其是版权分析)存在明显瑕疵,此案应恢复封禁再议。--Mys_721tx(留言) 2024年6月13日 (四) 01:21 (UTC)
- 1 -> 我理解到你说他游戏维基规则的行为是故意和方针唱反调,引起讨论,是这样吗?还是他的行为背后还有更深层次的目的我没有发现的?
- 2&3 -> 我同意。但是你举出的例子有点少。并且本用户添加了编辑摘要attribute,虽然不合规,但是足以让我AGF。另外TOU和英维基均允许编辑摘要attribute(当然,他缺少了interwiki link)。关于这一点,我在沙盒中最下方写了一点,请你看看是否有问题。
- 4 -> 同意,但是你所给出的例子不足以封禁。
- Bluedeck 2024年6月13日 (四) 01:31 (UTC)
- 明显不符合版权要求的编辑没有"不能构成查封理由"一说。长期不符合版权要求是明确的封禁理由。封禁方针与版权方针均规定该行为会导致封禁。"不能构成查封理由"一说无方针根据。
- 此处(Special:Diff/79628341)还将明显非自由版权内容翻译进条目。
- 根据文献总结出文献中没有直接支持内容是明显的原创研究。解封理由中"非原创研究"与"不能构成查封理由"一说无方针根据。
- 加入来源中没有内容亦非首次: Special:Diff/79840200、Special:Diff/79885782
- 明显不符合版权要求的编辑没有"不能构成查封理由"一说。长期不符合版权要求是明确的封禁理由。封禁方针与版权方针均规定该行为会导致封禁。"不能构成查封理由"一说无方针根据。
- --Mys_721tx(留言) 2024年6月13日 (四) 02:04 (UTC)
- 继续补充:
- 翻译明显非自由版权内容行为:Special:Diff/79715131/80209915、Special:Diff/80200379 见存档
- 复制翻译内容而未署名,来源中亦无此内容: Special:Diff/80200249
- --Mys_721tx(留言) 2024年6月13日 (四) 02:19 (UTC)
- 继续补充:
- 不存在于英文维基百科亦不存在于来源中的内容:Special:Diff/79421787、Special:Diff/79421626
- 翻译明显非自由版权内容:Special:Diff/78673915
- 来源中没有的内容:Special:Diff/78536738
- --Mys_721tx(留言) 2024年6月13日 (四) 03:54 (UTC)
- 我在沙盒中的说法有误,我想表达的意思不是“某种行为不能构成查封理由”,而是和mitigating factor一栏中的内容结合考虑后,我觉得可以不查封。您后来提供的讯息我会一并考虑。Bluedeck 2024年6月13日 (四) 04:43 (UTC)
- 继续补充来源中没有的内容:Special:Diff/78502357、Special:Diff/78486116、Special:Diff/78461141、Special:Diff/78459618、Special:Diff/77814194。--Mys_721tx(留言) 2024年6月13日 (四) 17:45 (UTC)
- 另外补充一处翻译明显非自由版权内容Special:Diff/65568515/65809184。其中禁用地区断言亦不存在于来源中。--Mys_721tx(留言) 2024年6月25日 (二) 08:51 (UTC)
- 继续补充来源中没有的内容:Special:Diff/78502357、Special:Diff/78486116、Special:Diff/78461141、Special:Diff/78459618、Special:Diff/77814194。--Mys_721tx(留言) 2024年6月13日 (四) 17:45 (UTC)
- 我在沙盒中的说法有误,我想表达的意思不是“某种行为不能构成查封理由”,而是和mitigating factor一栏中的内容结合考虑后,我觉得可以不查封。您后来提供的讯息我会一并考虑。Bluedeck 2024年6月13日 (四) 04:43 (UTC)
- Special:Diff/80200249属于内部复制自Special:PermaLink/80179400。--Mys_721tx(留言) 2024年6月14日 (五) 00:09 (UTC)
- @Bluedeck:苗君是指Special:Diff/80200249內容複製自LangChain,which in turn是翻譯自en:LangChain,而在Python條目或編輯摘要均沒有提供en:LangChain翻譯內容的合規attribution。--路西法人 2024年6月14日 (五) 08:33 (UTC)
- Bluedeck 2024年6月14日 (五) 21:55 (UTC) 啊,谢谢指出。我确实忽略了这一点。这么看是违规的。
- @Bluedeck:苗君是指Special:Diff/80200249內容複製自LangChain,which in turn是翻譯自en:LangChain,而在Python條目或編輯摘要均沒有提供en:LangChain翻譯內容的合規attribution。--路西法人 2024年6月14日 (五) 08:33 (UTC)
- 继续补充:
- 继续补充:
- 關於第一點,作為另一方當事人我的觀點如下:
- 被封鎖用戶提出這些觀點是為了扭曲共識方針對「共識」的要求(強行解讀為「共識」必須是民主制度、必須是多數決的說法),經指出仍持續堅持扭曲方針理解,以此試圖阻止未獲絕對多數同意但反方理據極度薄弱的提案通過。《遊戲維基規則》方針列明
故意謊稱某一觀點或立場受到方針的保護、管轄或支持,但是其實是違背方針的
為遊戲維基方針的行為,並以此試圖故意拖延討論、遊戲程序。《封鎖方針》列明遊戲維基規則為可被封鎖的行為,你沙盒中寫「不認同這種發言可以導致查封」,不認同不代表苗君封鎖不符合方針,這顯然不能作為解除封鎖理由。
- 被封鎖用戶提出這些觀點是為了扭曲共識方針對「共識」的要求(強行解讀為「共識」必須是民主制度、必須是多數決的說法),經指出仍持續堅持扭曲方針理解,以此試圖阻止未獲絕對多數同意但反方理據極度薄弱的提案通過。《遊戲維基規則》方針列明
- 其餘點我也依據我的個人理解回應一下:
- 第二、三點,經過警告後仍然持續侵犯版權可致封鎖,這是《侵犯版權》方針明確指出
不顧警告,多次張貼版權材料的貢獻者可以由任何管理員加以封禁,以阻止問題進一步產生。
你大可AGF,但這不構成你在沙盒中所寫「不能構成查封理由」,最多是「經承諾不再反則不再需要封鎖」。 - 針對沙盒中對Special:Diff/82768292/82807533的分析:(《非原創研究》方針指明
在維基百科裏所謂原創研究或原創觀念,指的是[...]對已發表材料進行的未發表分析、綜合或總結,並產生或暗示新的結論。
該差異中顯然存在自行總結已發表材料,來源中除了文獻一節甚至連文中提及的「vicious circle」都沒提及,顯然構成原創研究。
- 第二、三點,經過警告後仍然持續侵犯版權可致封鎖,這是《侵犯版權》方針明確指出
- 以上。閣下的解封理據中有眾多疏漏,還請重新檢視解封決定。--路西法人 2024年6月13日 (四) 02:11 (UTC)
如果能发现本用户更多更大量的违反2, 4,那么的确可以再检讨。
感谢阁下解封决定,也在此提供一些个人观点
[编辑]首先再次感谢Bluedeck阁下解封决定: 在下也在此提供一些个人观点(主要回应LucifertianThomas君):
- 一、
被封锁用户提出这些观点是为了扭曲共识方针对“共识”的要求
经指出仍持续坚持扭曲方针理解,以此试图阻止未获绝对多数同意但反方理据极度薄弱的提案通过。
本人发言是基于现实资料统合汇整的讯息,针对“共识”这一概念的个人解读,而不是维基百科上的方针。 - 根据五大之柱维基百科不墨守成规,就算在下发表了不是很符合维基百科政策的言论,如是为改善维基百科这一理由,则应予以假定善意(况且共识完全可逐渐予以修订,并非板上钉钉)。持相同看法者包括@桐生ここ。既然不是针对方针的本意进行扭曲,而是发表个人意见,那就更别提“
故意谎称某一观点或立场受到方针的保护、管辖或支持,但是其实是违背方针的
”是合理的。仅因此将在下言论谓之“是为了扭曲共识方针”“坚持扭曲理解”“阻止提案通过”明显违反AGF。 - 另,讨论页中被认为“强行推行”“不顾反方意见”将其定性为“未获绝对多数同意但反方理据极度薄弱”发布冗长讨论可能游戏共识形成者,显然有且仅有LucifertianThomas君一位。见下列评价:
- 但我想阁下这等高傲的态度,连移动讨论都能给人家扣扰乱帽子,大概是别想讨论了。——Ericliu1912
- 坏处只是你的主观认为,你现在的做法纯属强制推销,爱用RFC的可以在RFC推进讨论,不爱用或者不需要用到小心讨论可以维持在客栈进行。——Cwek
- 因为社群的惯性的确是将各种广泛性的问题放在客栈解决,而你斥之为陋习,就算你没直接声明需要“架空客栈”,但搞出一个RFC机制来分散讨论,甚至还期望强制设立共识确立位置的规定来限制客栈或者推广RFC的使用,但这些做法怎样看都是不满于RFC的利用不足而尝试架空客栈。——Sanmosa
- 如果提出来的方案得不到社群支持,使用,逆社群之习惯,只怕是得不偿失。——Ericliu1912
- 然而目前反对声音众,支持声音寡,非得要强硬闯关,浪费大量社群资源,实在不无遗憾。我已经可以想像您给什么说话我听了,无非是“Stoneball”“非合理意见”“老调重弹不新鲜”之类。我本就应该如Fire Ice所说的不别花这样多口水的。叹叹!——Ghren
- 确实,目前看来只有路西法君一人支持该提案。我本人虽认同他的初衷,但反对强制推行。——微肿头龙
- 以上,请阁下思之。
- 二、
不顾警告,多次张贴版权材料的贡献者可以由任何管理员加以封禁,以阻止问题进一步产生
在下完全同意。然而需要分清什么是“警告”什么是“不足的提醒”。根据阁下去年10月份在在下的留言,我可以视作善意提醒。但是这足以保证一位用户认知到持续此一行为将导致封禁甚至不限期封禁么?根据封禁政策的三项原则“确保用户熟悉规范”“确保目前无改善可能”“封禁始终为最后手段”,我认为当事管理员Mys 721tx君可以采取适当的措施教育用户(不仅仅是本人,而是每一个编者)指出问题,并熟悉有关政策(比如提请互助客栈讨论(见此案)、在本人讨论页面发可能受到封禁警告等,在下熟知后完全可以接受并改善审查过往问题),而非直接予以不限期封禁。政策原则已明确规定不能用于惩罚,也不能用作警告。 - 三、
该差异中显然存在自行总结已发表材料,来源中除了文献一节甚至连文中提及的“vicious circle”都没提及,显然构成原创研究。
为阁下的主观看法,是否属于原创总结,第三方管理员与在下均不如此认为。如果认为该条目有问题,可以在讨论页指出,以协助进一步改进。 - 四、最后是在下的个人想法,诚然在下过往的编辑并非没有问题(虽未经正当沟通程序,在下仍于此及讨论页郑重承诺会熟悉相关政策后,谨慎地作出有益维基百科编辑)。只是原始理据中诸多封禁严重瑕疵(包括曲解TPG政策以鲁莽指控他人行为不当、违反假定善意、两则链接涉嫌诽谤用户作出不符合封禁理由事实的行为、未经正当沟通之不当封禁)显示出当事管理员不良的用权与事前沟通态度习惯(这已被我在内多名用户指出),并且经指出后,对上方不当用权情事及封禁理据疏漏只字不谈,仅要求将本人重新封回,可合理认为Mys 721tx君意识不到自己的问题。
- 五、在下认为不宜在第三方管理员讨论页打扰,决定提请互助客栈评议,使广大社群用户重新审视涉事用户用权态度问题,以正视听。欢迎各位参与讨论。
--Gluo88(留言) 2024年6月13日 (四) 11:47 (UTC)
- 您在此處留言回應LucifertianThomas,又提到「不宜在第三方管理員討論頁打擾」,我感覺這二件事之間是不一致的--Wolfch (留言) 2024年6月13日 (四) 12:28 (UTC)
給您的友善星章!
[编辑]![]() |
友善星章 |
感謝您一切为了让中维变得更好努力, 非常感謝您的幫助! gluo88飲茶傾計·----🖊️ 2024年6月13日 (四) 12:14 (UTC) |
給您的星章!
[编辑]![]() |
勤奮星章 |
謝謝您對於gluo88封禁理由的分析 Wolfch (留言) 2024年6月14日 (五) 02:14 (UTC) |
Re:
[编辑]见Wikipedia talk:封禁方针#进一步增修封禁方针以及建立封禁申诉的本地共识与Wikipedia talk:封禁方针/存档6#重修封鎖方針及禁制方針中对于调整方针用词的讨论。由于封禁并不是惩罚,封禁长度是按照对用户是否能够改正违规行为实施的。我们可以合理推断用户初次违规属于不熟悉规则,因此也不需要过长的封禁时间阻止其编辑。有期限的封禁仅代表预计在封禁结束时用户会停止违规行为。管理工作难易程度的考虑亦是在此若用户在有限期封禁结束后继续违规行为,封禁时间亦据此加长。因此一天的封禁并不比一周的封禁轻,一个月的封禁亦不比一周的封禁重。对于纯破坏用户的不限期封禁是鉴于单一用途账户不太可能改正违规行为。对于严重违规行为的长时间乃至不限期编辑亦是因此考虑。若被封禁用户可证明自己认识到行为违规而不需要封禁,限期封禁与不限期封禁的任何一段时间中合理申诉即可获得有条件解封。--Mys_721tx(留言) 2024年6月15日 (六) 00:53 (UTC)
await
[编辑]所以Gluo88的解封操作你准备如何处理?既然在本页上方以及User:Bluedeck/etc/sandbox/box1718239888243#后续 已在初步复核下得出查封理由有欠缺这一论点不完全正确,建议请先自己回退你的管理操作再进一步讨论。作为管理员要为自己的操作负责,想必这一点你也清楚吧。(请在这里回复)--0xDeadbeef (留言) 2024年6月25日 (二) 09:14 (UTC)
- @0xDeadbeef:四项封锁理由,前两项是站不住脚的,后两项未经正当沟通与适当程序,并被多个用户认为存有态度问题,在下认为不全然符合封禁政策的精神。如果Bluedeck君选择全面回退这一已受广泛质疑的管理操作,需要非常全面面对后续争议(以为自己的操作负责)。版权或原创问题,在下已经承诺(如这里和这里)会根据第三方管理员的审核结果所给出的意见,审查过往编辑,未来根据方针指引作出有效改善。希望Bluedeck阁下能思之,在下行为是否非无限期封禁不可改变。谨此提供当事人意见,不过多打扰。--Gluo88(留言) 2024年6月25日 (二) 11:13 (UTC)
- 早已见过你扰乱讨论的情况,主命名空间下发生了什么我没时间看,你要想给Bluedeck留言别@我。我的意见仍然是封禁是对的。--0xDeadbeef (留言) 2024年6月25日 (二) 11:20 (UTC)
- 帮忙查证后续表中的一些内容:Special:Diff/79421787为alleged OR,实际为从远古时期加入的内容复制而来。经我个人查证,在 ISBN 9780141026169 The Blind Watchmaker 以及 ISBN 9780593055489 The God Delusion的书中搜索 Chance, Watch, Luck 关键词未见「幸运地产生一只表」这一论点。所以经本人判断为OR。--0xDeadbeef (留言) 2024年6月25日 (二) 18:05 (UTC)
- en:Watchmaker analogy:
--桐生ここ★[讨论] 2024年6月27日 (四) 02:12 (UTC)In his book The God Delusion, Dawkins argues that life was the result of complex biological processes. He makes the argument that the comparison to the lucky construction of a watch is fallacious because proponents of evolution do not consider evolution "lucky". Rather than luck, the evolution of human life is the result of billions of years of natural selection. He concludes that evolution is a fair contestant to replace God in the role of watchmaker.
- 好吧,这是在英文版本就有的OR。我加了Failed verification。--0xDeadbeef (留言) 2024年6月27日 (四) 02:47 (UTC)
- Dawkins没有把这一论述称作“watchmaker argument”,他称之为“technological argument”或“argument from design”(The God Delusion, p. 79),尤其考虑到他把这一论点归于佩利和他的《自然神学》。在后续章节(Ibid., p.113)有进一步叙述,里面没有类比钟表,而是类比的波音747。“达尔文的进化论有力地驳斥了钟表匠类比”这的确是Dawkins的观点,不过中间“proponents of evolution do not consider evolution lucky”看起来是过度总结。Irralpaca(留言) 2024年6月27日 (四) 03:10 (UTC)
- 我其实看到了波音747,我能理解为什么是这样写,但是过度总结就是原创研究的一种。--0xDeadbeef (留言) 2024年6月27日 (四) 03:29 (UTC)
- @u:0xDeadbeef:从后续一节可以看出,当初查封Gluo88不无道理。不过就算加上这些证据,让我来处理也不会是无限期封禁这个结果,所以我现在不能做出退回无限期查封的决定。然而,为这个解任Mys我认为理由不足。Gluo提出还有其他理由,我会再去看,看过再发表意见。Bluedeck 2024年6月27日 (四) 05:08 (UTC)
- 理解,感谢回复。其实我当时留言的时候没有想起来还有RFDA这一事情。我的疑问是解任这一案Gluo88已经quote你
第三方管理员认定不能构成查封理由
,而这一句与查封Gluo88不无道理
还是有冲突的。我看来更精确的说法应该是,认为查封理由有一定支持,但不同意以不限期封禁。这一点希望你能在RFDA澄清一下。--0xDeadbeef (留言) 2024年6月27日 (四) 05:35 (UTC) - 我基本认同蓝桌的观点。--桐生ここ★[讨论] 2024年6月27日 (四) 12:00 (UTC)
- 理解,感谢回复。其实我当时留言的时候没有想起来还有RFDA这一事情。我的疑问是解任这一案Gluo88已经quote你
- @u:0xDeadbeef:从后续一节可以看出,当初查封Gluo88不无道理。不过就算加上这些证据,让我来处理也不会是无限期封禁这个结果,所以我现在不能做出退回无限期查封的决定。然而,为这个解任Mys我认为理由不足。Gluo提出还有其他理由,我会再去看,看过再发表意见。Bluedeck 2024年6月27日 (四) 05:08 (UTC)
- 我其实看到了波音747,我能理解为什么是这样写,但是过度总结就是原创研究的一种。--0xDeadbeef (留言) 2024年6月27日 (四) 03:29 (UTC)
- Dawkins没有把这一论述称作“watchmaker argument”,他称之为“technological argument”或“argument from design”(The God Delusion, p. 79),尤其考虑到他把这一论点归于佩利和他的《自然神学》。在后续章节(Ibid., p.113)有进一步叙述,里面没有类比钟表,而是类比的波音747。“达尔文的进化论有力地驳斥了钟表匠类比”这的确是Dawkins的观点,不过中间“proponents of evolution do not consider evolution lucky”看起来是过度总结。Irralpaca(留言) 2024年6月27日 (四) 03:10 (UTC)
- 好吧,这是在英文版本就有的OR。我加了Failed verification。--0xDeadbeef (留言) 2024年6月27日 (四) 02:47 (UTC)
- 剛剛也試著驗證了Special:Diff/78486116的內容,以下是我個人見解:首先是英維原文是整個大段落引用,而非該次修改中的節錄部分,所以推測是自己總結的。接下來是查了此書及內容是否存在,也的確存在,所以推測該來源算可靠。再來看了引用,發現Gluo88閣下所quote的跟內文對不上,但倘若將範圍放大至整個文章後,雖然是能驗證這幾句,但還是有部分內容觀點(如科學與宗教是明確區分開的,但對科學的熱誠情感源自於宗教的領域)沒有寫進去,個人認為是引用及總結的不夠完整。--WiTo🐤💬 2024年7月3日 (三) 09:58 (UTC)
- 同意,用户确实对来源有过分总结的倾向,也有多个例子说明了引文和内文对不上号,特别是新儒家的那个例子,目前看似乎是臆造出来的。过分总结是一种OR,对不上号则没法分类,是单纯的错误讯息。整体而言需要大量依靠AGF、水平不足、编辑失误等等理由来解释,而被直接看成是违规也不是无本之木。Bluedeck 2024年7月12日 (五) 18:09 (UTC)
- 不知道Myx閣下是否是因為太多不算嚴重的OR及CV堆積上去,才決定以無限期禁止方式處理。(不過我不熟相關規範就不知道這樣是否妥適了)--WiTo🐤💬 2024年7月13日 (六) 02:16 (UTC)
- 封禁方针指出:“初犯者的封禁期限应为一天至数天,再犯者则应适当地加长封禁期限”;“不限期封禁是指无失效时限的封禁,通常用于防止严重扰乱维基百科正常运作的行为或严重违反维基百科方针指引的行为”;“封禁不可用作复仇、贬损或惩罚用户,更不应在无当前的行为问题下使用封禁。” Mys_721tx解释该封禁时理据时说,“不限期封禁比其他封禁‘重’的概念已被社群推翻”。--Gluo88(留言) 2024年7月13日 (六) 02:22 (UTC)
- 多谢您的复审工作。我目前也在好好反思我的需要改进的地方,会尽力避免以后再犯类似的问题。关于新儒家的条目,从我编辑的情况下,我也同意您的判断, 我是做的太差了,只是根据我以前的阅读,从记忆里整理, 没有认真把每一个判断列出来源。如果问copilot:“请评论一下上面段落是否正确? 能否找到参考材料支持?” 从回答中可以看出,该段落是有一定根据的。 但是,我是做的太差了,没有好好处理,列出来源。再次感谢您的工作。--Gluo88(留言) 2024年7月13日 (六) 02:18 (UTC)
- 谢谢您对自己工作的检讨。不过有必要指出,这些问题是Mys发现的。我相信您有提升编辑水平的意愿,也认为Mys发现这些问题是一个正面的影响。Bluedeck 2024年7月17日 (三) 18:18 (UTC)
- 所以说我觉得这里有一个系统性的错误。就是在处理解封请求的时候最好要和原封禁管理讨论。有些时候在翻一个人的贡献的时候,管理不一定就能够把所有「影响是否该封禁此人的判断」的所有编辑都列出来。如果我是第三方管理员,我在考虑是否解封的时候若认为封禁理由不足以不限期封禁的时候,我会先思考并搜寻是否有更多的证据证明此用户有「重复行为」以足以不限期封禁,而且我会事先与原封禁管理员讨论,是否应该直接解封(即被封禁用户是否表现出「理解被封禁的原因」又或者说是原始封禁原因完全不成立)。若讨论后仍然不同意对方的意见,则询问一下社群,看看是否通过更多人讨论来形成一个共识。在这些程序不完成的期间,我是不会轻易解封的。--0xDeadbeef (留言) 2024年7月13日 (六) 03:10 (UTC)
- 我同意。我认为解封前没有询问mys是我的失误。我将牢记以后对于任何比较重的查封的处理,都会咨询原管理员,并预留一定时间等候各方回答。Bluedeck 2024年7月17日 (三) 18:18 (UTC)
- 不知道Myx閣下是否是因為太多不算嚴重的OR及CV堆積上去,才決定以無限期禁止方式處理。(不過我不熟相關規範就不知道這樣是否妥適了)--WiTo🐤💬 2024年7月13日 (六) 02:16 (UTC)
- 同意,用户确实对来源有过分总结的倾向,也有多个例子说明了引文和内文对不上号,特别是新儒家的那个例子,目前看似乎是臆造出来的。过分总结是一种OR,对不上号则没法分类,是单纯的错误讯息。整体而言需要大量依靠AGF、水平不足、编辑失误等等理由来解释,而被直接看成是违规也不是无本之木。Bluedeck 2024年7月12日 (五) 18:09 (UTC)
- Bluedeck您好,有關之前對Gluo88的封禁,您在User:Bluedeck/etc/sandbox/box1718239888243#后续评论有提到:「認為一個有限期的封禁是合理的」,那麼,後續會考慮再進行有限期的封禁嗎?我理解這是管理員的權限,只是想知道您後續會如何處理,謝謝您。--Wolfch (留言) 2024年8月18日 (日) 15:19 (UTC)
- 解封当时的封禁时长已经超过了一个星期了,况且封禁也不是积分制,只要用户没有继续贸然加入不实信息,没有必要查封满多少天。Bluedeck 2024年8月19日 (一) 01:21 (UTC)
- 瞭解了,謝謝您的回覆--Wolfch (留言) 2024年8月19日 (一) 02:10 (UTC)
- 解封当时的封禁时长已经超过了一个星期了,况且封禁也不是积分制,只要用户没有继续贸然加入不实信息,没有必要查封满多少天。Bluedeck 2024年8月19日 (一) 01:21 (UTC)
一杯茶送给您!
[编辑]![]() |
早安!我已组队folding@home项目,来为科学出力 Yuki Rutygr (留言) 2024年7月13日 (六) 12:03 (UTC) |
管理人員解任投票通告
[编辑]![](http://upload.wikimedia.org/wikipedia/commons/thumb/d/d1/Wikipedia_Administrator.svg/100px-Wikipedia_Administrator.svg.png)
Mys_721tx的管理員解任投票(第2次)正在進行,投票期為2024年7月12日至7月26日,誠邀您踴躍參與投票。
- 投票须知
- 依据方针,本次投票必须按照指定格式在安全投票的“投票留言”框内填写文字来进行投票,并给出理由。
- 由于技术原因,因而保留空白的投票选项,但空白选项是无效的,请在“投票留言”一栏留下您的投票及理由。
- 请注意,中立票意见仅供参考,仅能计入总有效票數,但不会计入得票比率。
- 在系统中,每个用户只有一票会被储存。您可以在投票期间重复更改您的投票,但系统只会储存最新的投票,并覆盖之前的记录。
- 请尽可能让您的留言简洁。请注意,您的投票留言将在投票结束后打乱顺序并公开可见。
- 指定格式
- 支持解任:您的理由
- 反对解任:您的理由
- 中立:您的意见留言
建议在您的投票留言最前面写“支持解任”或“反对解任”或“中立”,之后是冒号“:”,接着是您的理由。
请明确填写“支持解任”或“反对解任”或“中立”并给出理由,中立票意见仅供参考不会计入得票比率,未填写“支持解任”或“反对解任”或“中立”的为无效票。
MediaWiki message delivery(留言) 2024年7月14日 (日) 14:29 (UTC)
EasyArchive已無法使用
[编辑]您好,由於MediaWiki章節格式變更,現EasyArchive已無法在WMF wikis上使用,還請有空時修復。--SunAfterRain 2024年7月15日 (一) 05:50 (UTC)
- 好的,我将在近期修复。Bluedeck 2024年8月1日 (四) 19:08 (UTC)
给您的果仁蜜饼!
[编辑]感谢为大陆用户编辑便利做出的贡献! 阿米娅2011(留言) 2024年7月31日 (三) 06:26 (UTC) |
反馈疑似bug
[编辑]hey,你好!我试图在Unblock-zh上给我自己IPBE续期时发现问题:点击提交工单无反应,多次点击会出现某种报错,但我想不起来报错信息是什么了。
查询工单时键入我的邮箱和工单号(提交工单不给我工单号,不过邮箱的确会给出来),的确会跳转页面,只不过是空白,不知道是什么原因。--嘉然小姐的猫猫5(留言) 2024年8月11日 (日) 14:24 (UTC)
- @嘉然小姐的猫猫5:可能是您的网络有点慢。我们这边看到了您提交的一共6个工单,是重复的,所以删除了其中五个,保留最初的一个(如果删掉的,那么就会查询不到)。应该给您发过邮件,在邮件中能够找到访问链接。Bluedeck 2024年8月11日 (日) 14:42 (UTC)
- 确认。我也看到了,当时我挂的并不是全局代理,不知道是不是此原因。--嘉然小姐的猫猫5(留言) 2024年8月11日 (日) 14:43 (UTC)
- @嘉然小姐的猫猫5:另外呢,IPBE的续期已经完成,见此。Bluedeck 2024年8月11日 (日) 14:44 (UTC)
- 确认。
謝謝您--嘉然小姐的猫猫5(留言) 2024年8月11日 (日) 14:46 (UTC)
- 确认。
- @嘉然小姐的猫猫5:另外呢,IPBE的续期已经完成,见此。Bluedeck 2024年8月11日 (日) 14:44 (UTC)
- 确认。我也看到了,当时我挂的并不是全局代理,不知道是不是此原因。--嘉然小姐的猫猫5(留言) 2024年8月11日 (日) 14:43 (UTC)
Re: Jimmy-abot {{blocked-proxy}} on IP range
[编辑]是人看的,觉得像是在数据中心这样。--Jimmy Xu 论 2024年8月22日 (四) 21:41 (UTC)
- 段里的确是有web server的,信息写成那样也看上去像fraud,但RIR没意见的话我也管不到就是了。如果您觉得应当解封的话我去修改bot。--Jimmy Xu 论 2024年8月22日 (四) 21:59 (UTC)
- 经已完成。--Jimmy Xu 论 2024年8月23日 (五) 02:57 (UTC)
- @Jimmy Xu
- 我对这个Bot的运行方式有不同意见:
- 1. 这个Bot封的是代理,但却参考是否有 web server。有web server和是公开/匿名代理之间我不认为有任何联系。有一些专门的API测试是否是公开/匿名代理;比如:https://ipinfo.io/products/proxy-vpn-detection-api
- 2. “看上去像fraud”又不一定是真正的fraud。我不赞成“看上去”是封禁的理由,除非有明确的证据例如wiki贡献历史证明是fraud。
- 请参考--2A0E:AA07:F004:1:BEEF:AAAA:7896:BED(留言) 2024年8月26日 (一) 22:59 (UTC)
- 如果提供web server,那么说明有hosting,有hosting就可以搭载VPN,我觉得这个说的通。Bluedeck 2024年8月27日 (二) 00:07 (UTC)
- 这属于slippery slope... https://zh.wikipedia.org/zh-cn/%E6%BB%91%E5%9D%A1%E8%AC%AC%E8%AA%A4
- hosting可以搭建vpn不代表这上面就一定有vpn。从另外一方面来说,维基百科的代理方针封禁的是代理服务器的IP地址或地址段,而不是可能被用作代理服务器的地址或地址段。--2A0E:AA07:F004:1:BEEF:AAAA:7896:BED(留言) 2024年8月27日 (二) 02:15 (UTC)
- 使用你的proxy-vpn-detection-api测试 45.32.76.182,这是Vultr的IP段,已知这上面肯定有VPN,但是vpn, proxy, tor, relay均为false,hosting为true。Bluedeck 2024年8月27日 (二) 02:48 (UTC)
- 45.32.76.182 是它那个页面为了演示显示的IP。。我这里默认显示的IP是43.241.71.120
- 你应该在上面直接输入2A0E:AA07:F004:1:BEEF:AAAA:7896:BED然后再看。这个api支持ipv6--2601:445:881:BE10:E85C:ED14:A6A4:81FE(留言) 2024年8月27日 (二) 02:55 (UTC)
- 没事我理解错了。不过Vultr IP我记得是默认全部封锁的?因为这个IP段上面有公开代理并且Vultr允许随意切换IP。--2601:445:881:BE10:E85C:ED14:A6A4:81FE(留言) 2024年8月27日 (二) 02:58 (UTC)
- Vultr应该是全部封锁的。我的point是你这个API他不是很靠谱。Bluedeck 2024年8月27日 (二) 03:02 (UTC)
- 我在外边刚才没仔细读,理解理解。--2601:445:881:BE10:E85C:ED14:A6A4:81FE(留言) 2024年8月27日 (二) 03:03 (UTC)
- Vultr应该是全部封锁的。我的point是你这个API他不是很靠谱。Bluedeck 2024年8月27日 (二) 03:02 (UTC)
- 没事我理解错了。不过Vultr IP我记得是默认全部封锁的?因为这个IP段上面有公开代理并且Vultr允许随意切换IP。--2601:445:881:BE10:E85C:ED14:A6A4:81FE(留言) 2024年8月27日 (二) 02:58 (UTC)
- 使用你的proxy-vpn-detection-api测试 45.32.76.182,这是Vultr的IP段,已知这上面肯定有VPN,但是vpn, proxy, tor, relay均为false,hosting为true。Bluedeck 2024年8月27日 (二) 02:48 (UTC)
- 如果提供web server,那么说明有hosting,有hosting就可以搭载VPN,我觉得这个说的通。Bluedeck 2024年8月27日 (二) 00:07 (UTC)
- 经已完成。--Jimmy Xu 论 2024年8月23日 (五) 02:57 (UTC)