跳转到内容

Bluedeck欢迎您随时留言

页面内容不支持其他语言。
维基百科，自由的百科全书
English messages accepted. / 日本語のメッセージも受け付けております。
  • 接受来自所有用户及BOT的所有类型的留言。
  • 欢迎简要、直截了当的留言。如有必要，不必担心篇幅。离题内容偶尔会被处理，但这不妨碍您继续留言。
  • 现在，Bluedeck 这边是下午 0 点钟。
Bluedeck 向您安利
明日への扉
川嶋あい

去听歌

/页面编辑之帮助/

[编辑]

您好: 能帮我编辑第109回日剧学院赏的读者、记者和评审票吗? 因为本人现在比较忙，无法将剩下的页面完成，有空的话您可以帮我一下吗?----Ken1998225（留言） 2021年12月1日 (三) 01:00 (UTC)[回复]

投票通知：试行安全投票（SecurePoll）

[编辑]

由于2021年维基媒体基金会针对中文维基百科的行动暴露了本地社群自治的一些问题，社群展开了一连串的讨论以尝试修补此前选举制度的漏洞。

参与讨论的编者认为，使用安全投票（SecurePoll，一种维基媒体内部投票系统）可能可以解决一些既有问题，包括拉票等，但是是否施行此制度则需要社群共识决定。

据此，现决定举行一场安全投票，以决定是否在管理人员选举中试行安全投票制度。本次投票有三个问题，除了第一题为测试题以外，其他问题的结果都可能影响中文维基百科的未来发展。

本次投票之投票期为2021年12月11日 (六) 00:00 (UTC)至2021年12月25日 (六) 00:00 (UTC)。

关于安全投票：
  1. 保密：阁下投票之内容将获得保密，除选举管理员以外无人可以得知。本次投票将由基金会职员担任选举管理员。
  2. 自由：阁下投票后到截止前，可以任意改票。新的投票内容将覆盖先前的投票内容。
  3. 公平：为避免傀儡操控投票结果，投票时将纪录一些技术数据，此与阁下平常编辑维基百科时相同。

参与投票

希望阁下能够踊跃参与投票！ MediaWiki message delivery（留言） 2021年12月11日 (六) 09:55 (UTC)[回复]

此讯息由大量讯息发送功能传送给所有合资格投票人（包括延伸确认使用者或管理员权限持有者，在投票开始时被封禁者除外）。
如果您不希望在未来收到所有透过大量讯息发送功能发送的讯息，您可以在您的使用者对话页内加入Category:不接受消息发送这个分类。

算法提问

[编辑]

您好，想请问一下您身份验证的 HIROSE-AES-256 要如何计算？哪里找来这么偏僻的算法（--拒食木瓜〽️心臓を捧げよ！ 2021年12月19日 (日) 14:12 (UTC)[回复]

新年快乐，Bluedeck!

[编辑]
新年快乐!

Bluedeck，
感谢您对维基百科的贡献，祝您有一个愉快、充实并富有成效的新年。
--在下荷花，请多指教（欢迎签到） 2022年1月1日 (六) 02:57 (UTC)[回复]

   通过将{{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)[回复]

@Q28：问题出在这里：
== 注释 ==
{{((}}Reflist|2|group="注"}}
因为很多模版自带分类，但是图书馆里的内容我不想让他显示在任何分类里，所以所有的模版都被“去模版化”（像这样{{((}}）处理了。这导致reflist不显示，自然导致分类错误。我不能修改这个问题。Bluedeck 2022年3月8日 (二) 03:16 (UTC)[回复]

在座写轻小说的各位，全都有病页面存废讨论通知

[编辑]

您好，您先前创建或编辑的页面“在座写轻小说的各位，全都有病”已被提出存废讨论，正在讨论该页面的存废。
维基百科非常欢迎您的编辑，但请先看看编辑帮助和维基百科不是什么，以免犯了常见的错误。
请不要自行移除页面存废模板，讨论是因为有编者认为页面不适合维基百科。请参与页面存废讨论，您亦可以与提删的维基人进行沟通。在讨论期间欢迎继续完善原先的页面，多谢合作！
帮助：互助客栈、删除指导、存废复核请求、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)[回复]

独裁宝典页面存废讨论通知

[编辑]

您好，您先前创建或编辑的页面“独裁宝典”已被提出存废讨论，正在讨论该页面的存废。
维基百科非常欢迎您的编辑，但请先看看编辑帮助和维基百科不是什么，以免犯了常见的错误。
请不要自行移除页面存废模板，讨论是因为有编者认为页面不适合维基百科。请参与页面存废讨论，您亦可以与提删的维基人进行沟通。在讨论期间欢迎继续完善原先的页面，多谢合作！
帮助：互助客栈、删除指导、存废复核请求、IRC聊天频道--百战天虫（留言） 2022年9月24日 (六) 07:48 (UTC)[回复]

User talk:David S. Hwang的快速删除通知

[编辑]

您好，有编者认为您创建的页面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页面存废讨论通知

[编辑]

您好，您先前创建或编辑的页面“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

[编辑]

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)[回复]

邀请参与中文维基百科管治相关讨论

[编辑]

2024年管理人员制度改革意向调查经已结束，调整管理人员上任标准、容许用户获得临时管理员权限、设立仲裁委员会和修订管理员长期无活动解任方针已获社群共识采纳，目前正在讨论实行的细节。请踊跃参与以上讨论，提出建设性的意见。

MediaWiki message delivery（留言） 2024年1月5日 (五) 06:04 (UTC)[回复]

本条消息是使用群发消息功能发送给您的。如果您不希望在未来接受所有使用本功能发送的消息，请在您的讨论页加入Category:不接受消息发送这一分类。

新北市区公车绿5路线的快速删除通知

[编辑]

您好，有编者认为您创建的页面新北市区公车绿5路线内容不当，符合快速删除条件，该页面很快会由管理员进行复核并决定是否保留。
维基百科非常欢迎您的编辑，但请先看看编辑帮助和维基百科不是什么，以免犯了常见的错误。

如果您想查看已删除页面的页面内容，您可访问已删除内容查询。如果您认为删除不当，请到存废复核请求处提出申请，多谢合作！
帮助：互助客栈 · 删除指导 · 存废复核请求 · IRC聊天频道--Mafalda4144（留言） 2024年1月13日 (六) 15:27 (UTC)[回复]

新北市区公车绿12路线页面存废讨论通知

[编辑]

您好，您先前创建或编辑的页面“新北市区公车绿12路线”已被提出存废讨论，正在讨论该页面的存废。
维基百科非常欢迎您的编辑，但请先看看编辑帮助和维基百科不是什么，以免犯了常见的错误。
请不要自行移除页面存废模板，讨论是因为有编者认为页面不适合维基百科。请参与页面存废讨论，您亦可以与提删的维基人进行沟通。在讨论期间欢迎继续完善原先的页面，多谢合作！
帮助：互助客栈、删除指导、存废复核请求、IRC聊天频道--Mafalda4144（留言） 2024年1月13日 (六) 15:30 (UTC)[回复]

新北市区公车绿12路线的快速删除通知

[编辑]

您好，有编者认为您创建的页面新北市区公车绿12路线内容不当，符合快速删除条件，该页面很快会由管理员进行复核并决定是否保留。
维基百科非常欢迎您的编辑，但请先看看编辑帮助和维基百科不是什么，以免犯了常见的错误。

如果您想查看已删除页面的页面内容，您可访问已删除内容查询。如果您认为删除不当，请到存废复核请求处提出申请，多谢合作！
帮助：互助客栈 · 删除指导 · 存废复核请求 · IRC聊天频道--Mafalda4144（留言） 2024年1月13日 (六) 15:45 (UTC)[回复]

新北市区公车红38路线页面存废讨论通知

[编辑]

您好，您先前创建或编辑的页面“新北市区公车红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页面存废讨论通知

[编辑]

您好，您先前创建或编辑的页面“Wikipedia:已删除内容查询/header2”已被提出存废讨论，正在讨论该页面的存废。
维基百科非常欢迎您的编辑，但请先看看编辑帮助和维基百科不是什么，以免犯了常见的错误。
请不要自行移除页面存废模板，讨论是因为有编者认为页面不适合维基百科。请参与页面存废讨论，您亦可以与提删的维基人进行沟通。在讨论期间欢迎继续完善原先的页面，多谢合作！
帮助：互助客栈、删除指导、存废复核请求、IRC聊天频道--铁胶壹名 2024年3月24日 (日) 10:20 (UTC)[回复]

文明方针问题

[编辑]

之前在不当行为提报区那里，就有意见认为对于违反站内规则的处理方式是封禁而不是不文明行为（例如辱骂违规的人），而且假如没有封禁这一措施，不文明行为本身也无法阻止违规的人继续编辑。所以如果某人长期在站内辱骂他人，违反文明方针，而又没有管理员出面处理，时间一长，是不是会让人感觉那个人有站内不文明的特权？--日期20220626（留言） 2024年3月28日 (四) 12:13 (UTC)[回复]

回复通告

[编辑]
您有新的留言 您好，Bluedeck。您在Wikipedia:互助客栈/求助有新的留言或与您有关的消息。
此回复通告添加于2024年4月1日 (一) 11:13 (UTC)，您可以通过移除{{Talkback}}随时移除本通知。

阿米娅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)[回复]

管理人员选举及问卷进行中

[编辑]

中文维基百科管理人员选举正在进行，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)[回复]

果仁蜜饼送给您！

[编辑]
谢谢你的解封。 千村狐兔（留言） 2024年6月13日 (四) 00:58 (UTC)[回复]

解封理由瑕疵

[编辑]
  1. 首次发表与方针相违背言论本身并不是封禁的决定因素，在经纠正后持续试图强行曲解两方针属于游戏维基规则。游戏维基规则是封禁方针中的行为。
  2. Special:Diff/77127830/81797673中既然为翻译内容，却未在任何地方署名，已可见该用户违反CC-BY-SA之行为是系统性的。
  3. 编辑摘要中表示"从英文维基百科翻译"未提供条目名称、永久版本、作者列表、历史版本。维基数据项亦不固定。不符合CC-BY-SA对于来源的最低要求。（"署名：当你使用维基百科的文字时，你被要求提供到你所引用页面的超链接或URL..."）
  4. 英文维基百科是不可靠来源，从英文维基百科翻译无来源内容仍违反可供查证方针。添加内容的编辑有举证责任。

鉴于解封理由（尤其是版权分析）存在明显瑕疵，此案应恢复封禁再议。--Mys_721tx（留言） 2024年6月13日 (四) 01:21 (UTC)[回复]

1 -> 我理解到你说他游戏维基规则的行为是故意和方针唱反调，引起讨论，是这样吗？还是他的行为背后还有更深层次的目的我没有发现的？
2&3 -> 我同意。但是你举出的例子有点少。并且本用户添加了编辑摘要attribute，虽然不合规，但是足以让我AGF。另外TOU和英维基均允许编辑摘要attribute（当然，他缺少了interwiki link）。关于这一点，我在沙盒中最下方写了一点，请你看看是否有问题。
4 -> 同意，但是你所给出的例子不足以封禁。
@Mys_721tx：如果能发现本用户更多更大量的违反2, 4，那么的确可以再检讨。Bluedeck 2024年6月13日 (四) 01:31 (UTC)[回复]
  1. 明显不符合版权要求的编辑没有"不能构成查封理由"一说。长期不符合版权要求是明确的封禁理由。封禁方针与版权方针均规定该行为会导致封禁。"不能构成查封理由"一说无方针根据。
    此处（Special:Diff/79628341）还将明显非自由版权内容翻译进条目。
  2. 根据文献总结出文献中没有直接支持内容是明显的原创研究。解封理由中"非原创研究"与"不能构成查封理由"一说无方针根据。
    加入来源中没有内容亦非首次： Special:Diff/79840200、Special:Diff/79885782
--Mys_721tx（留言） 2024年6月13日 (四) 02:04 (UTC)[回复]
继续补充：
  1. 翻译明显非自由版权内容行为：Special:Diff/79715131/80209915、Special:Diff/80200379 见存档
  2. 复制翻译内容而未署名，来源中亦无此内容： Special:Diff/80200249
--Mys_721tx（留言） 2024年6月13日 (四) 02:19 (UTC)[回复]
继续补充：
  1. 不存在于英文维基百科亦不存在于来源中的内容：Special:Diff/79421787、Special:Diff/79421626
  2. 翻译明显非自由版权内容：Special:Diff/78673915
  3. 来源中没有的内容：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/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)[回复]
@LuciferianThomas：啊，谢谢指出。我确实忽略了这一点。这么看是违规的。Bluedeck 2024年6月14日 (五) 21:55 (UTC)[回复]
关于第一点，作为另一方当事人我的观点如下：
被封锁用户提出这些观点是为了扭曲共识方针对“共识”的要求（强行解读为“共识”必须是民主制度、必须是多数决的说法），经指出仍持续坚持扭曲方针理解，以此试图阻止未获绝对多数同意但反方理据极度薄弱的提案通过。《游戏维基规则》方针列明故意谎称某一观点或立场受到方针的保护、管辖或支持，但是其实是违背方针的为游戏维基方针的行为，并以此试图故意拖延讨论、游戏程序。《封锁方针》列明游戏维基规则为可被封锁的行为，你沙盒中写“不认同这种发言可以导致查封”，不认同不代表苗君封锁不符合方针，这显然不能作为解除封锁理由。
其余点我也依据我的个人理解回应一下：
  • 第二、三点，经过警告后仍然持续侵犯版权可致封锁，这是《侵犯版权》方针明确指出不顾警告，多次张贴版权材料的贡献者可以由任何管理员加以封禁，以阻止问题进一步产生。你大可AGF，但这不构成你在沙盒中所写“不能构成查封理由”，最多是“经承诺不再反则不再需要封锁”。
  • 针对沙盒中对Special:Diff/82768292/82807533的分析：（《非原创研究》方针指明在维基百科里所谓原创研究或原创观念，指的是[...]对已发表材料进行的未发表分析、综合或总结，并产生或暗示新的结论。该差异中显然存在自行总结已发表材料，来源中除了文献一节甚至连文中提及的“vicious circle”都没提及，显然构成原创研究。
以上。阁下的解封理据中有众多疏漏，还请重新检视解封决定。--路西法人 2024年6月13日 (四) 02:11 (UTC)[回复]

感谢阁下解封决定，也在此提供一些个人观点

[编辑]

首先再次感谢Bluedeck阁下解封决定： 在下也在此提供一些个人观点（主要回应LucifertianThomas君）：

一、被封锁用户提出这些观点是为了扭曲共识方针对“共识”的要求经指出仍持续坚持扭曲方针理解，以此试图阻止未获绝对多数同意但反方理据极度薄弱的提案通过。本人发言是基于现实资料统合汇整的讯息，针对“共识”这一概念的个人解读，而不是维基百科上的方针。
根据五大之柱维基百科不墨守成规，就算在下发表了不是很符合维基百科政策的言论，如是为改善维基百科这一理由，则应予以假定善意（况且共识完全可逐渐予以修订，并非板上钉钉）。持相同看法者包括@桐生ここ。既然不是针对方针的本意进行扭曲，而是发表个人意见，那就更别提“故意谎称某一观点或立场受到方针的保护、管辖或支持，但是其实是违背方针的”是合理的。仅因此将在下言论谓之“是为了扭曲共识方针”“坚持扭曲理解”“阻止提案通过”明显违反AGF。
另，讨论页中被认为“强行推行”“不顾反方意见”将其定性为“未获绝对多数同意但反方理据极度薄弱”发布冗长讨论可能游戏共识形成者，显然有且仅有LucifertianThomas君一位。见下列评价：
就LucifertianThomas君讨论态度之评价
  1. 但我想阁下这等高傲的态度，连移动讨论都能给人家扣扰乱帽子，大概是别想讨论了。——Ericliu1912
  2. 坏处只是你的主观认为，你现在的做法纯属强制推销，爱用RFC的可以在RFC推进讨论，不爱用或者不需要用到小心讨论可以维持在客栈进行。——Cwek
  3. 因为社群的惯性的确是将各种广泛性的问题放在客栈解决，而你斥之为陋习，就算你没直接声明需要“架空客栈”，但搞出一个RFC机制来分散讨论，甚至还期望强制设立共识确立位置的规定来限制客栈或者推广RFC的使用，但这些做法怎样看都是不满于RFC的利用不足而尝试架空客栈。——Sanmosa
  4. 如果提出来的方案得不到社群支持，使用，逆社群之习惯，只怕是得不偿失。——Ericliu1912
  5. 然而目前反对声音众，支持声音寡，非得要强硬闯关，浪费大量社群资源，实在不无遗憾。我已经可以想像您给什么说话我听了，无非是“Stoneball”“非合理意见”“老调重弹不新鲜”之类。我本就应该如Fire Ice所说的不别花这样多口水的。叹叹！——Ghren
  6. 确实，目前看来只有路西法君一人支持该提案。我本人虽认同他的初衷，但反对强制推行。——微肿头龙
以上，请阁下思之。
二、不顾警告，多次张贴版权材料的贡献者可以由任何管理员加以封禁，以阻止问题进一步产生在下完全同意。然而需要分清什么是“警告”什么是“不足的提醒”。根据阁下去年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:

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.

--桐生ここ★[讨论] 2024年6月27日 (四) 02:12 (UTC)[回复]
好吧，这是在英文版本就有的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)[回复]
刚刚也试着验证了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)[回复]
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)[回复]

一杯茶送给您！

[编辑]
早安！我已组队folding@home项目，来为科学出力 Yuki Rutygr (留言) 2024年7月13日 (六) 12:03 (UTC)[回复]

管理人员解任投票通告

[编辑]

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)[回复]

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)[回复]

邀请您参与管理人员任免及仲裁委员会制度讨论

[编辑]
注：此通告由MediaWiki message delivery（留言）于2024年9月21日 (六) 13:39 (UTC)寄送。若您未来长期或目前暂时不欲接收任何类似讯息，可考虑婉拒消息发送。[回复]

管理人员及仲裁委员会选举（2024年10月）

[编辑]
管理人员选举
二〇二四年十月梯次
2024年10月梯次管理员选举一览
申请成为管理员一览 申请页 安全投票页
0xDeadbeef → →
ASid → →
ATannedBurger（申请续任） → →
S8321414 → →
SCP-2000 → →
申请成为行政员 申请页 安全投票页
Peacearth → →
申请成为监督员 申请页 安全投票页
Peacearth → →

2024年10月梯次管理人员选举正在进行。本梯次有五名用户申请成为管理员，并有一名管理员申请成为行政员及监督员。您因符合投票资格而收到此讯息。

投票期从2024年10月25日 (五) 00:00 (UTC)起至2024年11月8日 (五) 00:00 (UTC)结束，您可在右方（或上方）的一览工具栏找到每名候选人的个人选举页面及投票连结；诚邀您踊跃参与投票。请注意所有符合当选条件的候选人均会当选；各候选人的支持率均分别计算，支持票不限于一票。

第一届 仲裁委员会选举
二〇二四年

经社群超过一年的持续讨论，中文维基百科仲裁委员会将在2025年1月正式成立，而首届仲裁委员会选举将在十一月举行。本届仲裁委员会选举共有16名编者参选，其中12名编者获确认符合参选资格。您因符合投票资格而收到此讯息。

您可点击此连结查看获确认符合参选资格的候选人名单及对应的参选声明和问答页面。

投票期从2024年11月1日 (五) 00:00 (UTC)起至2024年11月15日 (五) 00:00 (UTC)结束，您可点击此连结参与投票；诚邀您踊跃参与投票。

请注意本届仲裁委员会选举共开放13个席位，首13名符合当选条件的候选人均会当选；各候选人的支持率均分别计算，支持票不限于一票。

回馈请求服务已上线，诚邀您订阅有兴趣参与有关讨论的话题。

MediaWiki message delivery（留言） 2024年10月25日 (五) 06:09 (UTC)[回复]

unblock-zh.org证书过期，请及时续签

[编辑]

unblock-zh.org证书过期，请阁下及时续签，谢谢！--User:NNNH 2024年11月23日 (六) 09:00 (UTC)[回复]

好的 感谢提醒。以后我会设置日历 Bluedeck 2024年11月23日 (六) 17:44 (UTC)[回复]
检索自“https://zh.wikipedia.org/w/index.php?title=User_talk:Bluedeck&oldid=85075525”