跳转到内容

维基百科:互助客栈/方针

添加话题
维基百科,自由的百科全书

此页面探讨维基百科的方针与指引


请注重礼仪、遵守方针与指引,一般问题请至互助客栈其他区知识问答提出,留言后请务必签名(点击 )。


发表前请先搜索存档,参考旧讨论中的内容可节省您的时间。
公告栏
# 💭 话题 💬 👥 🙋 最新发言 🕒 (UTC+8)
1 有关申请权限与申请解除权限的方针条文与申请区的放置问题 77 7 阿南之人 2025-07-11 17:13
2 重提允许巡查员自我增加与移除自动巡查权/将自动巡查与巡查员权限组分离 148 22 Mirfaek 2025-07-13 11:04
3 维基百科:禁制 1 1 1F616EMO 2025-07-05 10:44
4 持续出没的破坏者页面中曾用于破坏的IP记载去留问题 1 1 Stang 2025-07-07 10:45
5 讨论页行为的边界:是善意提醒还是骚扰攻击性的贴标签行为? 1 1 1F616EMO 2025-07-11 13:47
6 提议于优良条目、典范条目、特色列表以及特色图片等典优评选的“投票程序”增加一条文 1 1 自由雨日 2025-07-12 16:50
7 提议允许用户可按页面大小存档其他用户的讨论页 19 8 1F616EMO 2025-07-13 18:09
发言更新图例
  • 最近一小时内
  • 最近一日内
  • 一周内
  • 一个月内
  • 逾一个月
特殊状态
已移动至其他页面
或完成讨论之议题
手动设置
当列表出现异常时,
请先检查设置是否有误

正在广泛征求意见的议题

议题清单

以下讨论需要社群广泛关注:重新整理 维基百科格式与命名

Wikipedia talk:命名常规 § 重提在条目标题中正确使用书名号

因此我提议在条目标题中正确使用书名号,无论最终使用甲式还是乙式。

以上。 ——魔琴身份声明 留言 贡献 PJ:NEW23 2025年3月8日 (六) 19:53 (UTC)

Wikipedia talk:命名常规/音乐 § 提议使用拉丁原名作为歌曲的标题

理由如下:

  1. 目前流媒体收听音乐几乎碾压传统的唱片音乐,而几乎所有的流媒体服务商都主显原名。使用几个中文汉字会使人感到陌生,是“易于识别”的违反,也不符合“使用常用名称”。有一种下位法违反上位法之感。
  2. 中文用户普遍认识26个字母,即使可能无法理解其含义并朗读,但普遍有能力拼写、传递和辨别是否同一单词。
  3. 维基百科编者为了符合这一要求,不惜代价地去寻找一个中文名称,最后还弄得读者看不懂,徒劳无功,质量还不高。
  4. 大部分译文质量不高,做不到“信达雅”,可能只是一些人为了填补“译名”字段空白的草率产物,也不一定是作者原意。
  5. 一些找不到译名的条目和隔壁某百科使用原文,看上去也没什么问题,甚至更美观易懂。

--ZLin2222留言) 2025年3月17日 (一) 17:08 (UTC)

Wikipedia talk:格式手册/标点符号 § 提案:修订“书1”对于软件名的规定

中华人民共和国《标点符号用法》(GB/T 15834—2011)4. 15.3.3 规定“全中文或中文在名称中占主导地位的软件名”用书名号标注,但是实际上除了电子游戏(如“《原神》”)以外罕见。因此建议“书1”去除这项,并明确电子游戏使用书名号标示。提案如左。

现行条文
  • 书1:标示书名、书名篇名并举、报纸名、杂志名、图表名、文件名、全中文或中文在名称中占主导地位的软件名,电影、电视、诗歌、音乐、雕塑等各类用文字、声音、图像等表现的作品名用双书名号。嵌套书名号时,外层用双书名号,内层用单书名号。
提议条文
  • 书1:标示书名、书名篇名并举、报纸名、杂志名、图表名、文件名,以及电影、电视、诗歌、音乐、雕塑、电子游戏等各类用文字、声音、图像等表现的作品。嵌套书名号时,外层用双书名号,内层用单书名号。
    GB/T 15834—2011规定“全中文或中文在名称中占主导地位的软件名”使用书名号标示,但实际罕见。

顺便修改了行文。 ——魔琴留言 贡献 PJ:小学 PJ:两岸 2025年5月30日 (五) 20:47 (UTC)

Wikipedia talk:繁简处理 § 繁体模式以“台湾台语”为正,不受WP:台台限制

当前,中华民国对于台湾话的官方名称为“臺灣台語”,盖该政府的刻意用字,窃以为在繁体模式下不应受WP:台台限制。 ——魔琴留言 贡献 PJ:小学 PJ:两岸 2025年6月19日 (四) 06:38 (UTC)

Talk:GB 13000 § 建议更名:“GB 13000”→“GB/T 13000”

GB 13000” → “GB/T 13000”:该标准已自强制性标准更改为推荐性标准。Nebulas-Star留言) 2025年6月24日 (二) 08:42 (UTC)

Wikipedia talk:命名常规/音乐 § 提议取消对消歧义后缀“(EP)”的禁用

本命名常规在创建之初,就引入了“(迷你专辑)”为规范消歧义后缀。在2021年9月对“MediaWiki:Titleblacklist”的编辑请求中,为配合命名常规的需要,“(EP)”被禁止作为消歧义后缀。

2024年1月在互助客栈的讨论得出将“迷你专辑”改为消歧义、内容分拆为“EP”与“迷你密纹唱片”的结论后,中文维基百科内各处就停止了将“EP”翻译为“迷你专辑”,以与“mini album”(迷你密纹唱片)做区别。根据当前的共识,是否应该修订本命名常规?此处抛砖引玉提出2个方案:

方案一,考虑取消对“(EP)”的禁用,可以根据实际需要选用“(EP)”或“(迷你专辑)”。

方案二,考虑将当前非韩语、华语的EP由“(迷你专辑)”统一修改为“(EP)”;未来仍允许编者自主选用“(迷你专辑)”表示迷你密纹唱片。通过机器人可以实现。

副知命名常规的主要编写者与所有相关讨论的参与者@MilkypineSanmosaSoftyuPseudo Classes魔琴FactrecordorDavid XuangAbcet10Dabao qian。--SuperGrey (留言) 2025年7月10日 (四) 18:15 (UTC)

维基百科方针与指引

Wikipedia talk:页面评级 § 提议废除甲级、乙上级与丁级

现时本站条目质量有实质区分度的等级,是小、初、丙、优良、典范。设置没有有效差异而又没人使用的等级令人望而生畏,先不说激进的废除乙级,已经被社群冷落的甲级、乙上级与丁级诚可删除。--HoweyYuan留言) 2025年3月7日 (五) 15:22 (UTC)

Wikipedia talk:命名常规 § 重提在条目标题中正确使用书名号

因此我提议在条目标题中正确使用书名号,无论最终使用甲式还是乙式。

以上。 ——魔琴身份声明 留言 贡献 PJ:NEW23 2025年3月8日 (六) 19:53 (UTC)

Wikipedia talk:命名常规/音乐 § 提议使用拉丁原名作为歌曲的标题

理由如下:

  1. 目前流媒体收听音乐几乎碾压传统的唱片音乐,而几乎所有的流媒体服务商都主显原名。使用几个中文汉字会使人感到陌生,是“易于识别”的违反,也不符合“使用常用名称”。有一种下位法违反上位法之感。
  2. 中文用户普遍认识26个字母,即使可能无法理解其含义并朗读,但普遍有能力拼写、传递和辨别是否同一单词。
  3. 维基百科编者为了符合这一要求,不惜代价地去寻找一个中文名称,最后还弄得读者看不懂,徒劳无功,质量还不高。
  4. 大部分译文质量不高,做不到“信达雅”,可能只是一些人为了填补“译名”字段空白的草率产物,也不一定是作者原意。
  5. 一些找不到译名的条目和隔壁某百科使用原文,看上去也没什么问题,甚至更美观易懂。

--ZLin2222留言) 2025年3月17日 (一) 17:08 (UTC)

Wikipedia talk:格式手册/两岸四地用语 § 条目内文中提及“国家”的部分直接写“台湾”是否违反CS4D
死刑存废问题#各国死刑现况中提到

根据国际特赦组织(Amnesty International)的统计……其中被自由之家(Freedom House)评比为完全民主自由的经济高度发展国家而维持死刑的仅有美国、日本及台湾。

个人认为如果前文是“国家”不可以使用“中国大陆”(包括“大陆”,惟在前文未提及“中国大陆”的情况下直接简写“大陆”已违反CS4D)和“台湾”指代两岸政权,应使用中华人民共和国中华民国完整国号(或使用模板{{PRC}}和{{ROC}})来表述。但查阅CS4D发现并没有对该种情况做明确规定,所以我想确认上述内文是否违反CS4D?也希望在CS4D内文中对该情况做明确规定。--忒有钱 🌊塩水あります🐳留言) 2025年4月6日 (日) 18:40 (UTC)

Wikipedia talk:列明来源 § 强制列明原地更新的来源的存取时间
此讨论正在公示7天,直至2025年7月13日 (日) 14:29 (UTC)结束;如有意见请尽快提出。
维基百科:可供查证规定“写入维基百科的内容须要能被读者在可靠来源中得到验证”,一般而言,直接列出来源便可。惟部分资料出自随时原地更新信息的网站(例如MLB.com球员信息、社交网站订阅数信息),若没有列明何时存取以及提供存档,其来源其实依然不明;若内容已更新,但来源存取日期未更新,更会造成来源和内容不符的情况,即内容无法“在可靠来源中得到验证”。因此,我建议新增以下条文:以上,邀请社群讨论。--1F616EMO喵留言回复请ping) 2025年5月31日 (六) 10:18 (UTC)
Wikipedia talk:讨论页指引 § 关于“维护维基百科的方针”
此讨论正在公示7天,直至2025年7月16日 (三) 15:14 (UTC)结束;如有意见请尽快提出。
目前这一节翻译自英维于2007年2月14日 (三) 07:27的修订版本108026792,当时英维的讨论页方针只有顾及条目讨论命名空间的状况,故规定“适用于条目的政策亦同样适用于讨论页中”。惟目前版本已经涵盖“所有讨论页及具有讨论性质的项目页面”,使所有讨论符合WP:核心内容方针的标准尺度不切实际。(以防有人曲解我的言论,在此声明:此处言论仅指讨论内容无需死板地符合核心内容方针,惟所有讨论的发言以及结果均只能够提升其原则的应用和解释而不能逾越之。)此外,“maintain”一词亦有“坚持”一说,译为“维护”恐怕是早期的误译。因此,我建议翻译自英维的版本,将之修改如下:修改后的版本更能反映其泛用性,使讨论聚焦于符合维基百科宗旨的主题。以上,提请社群讨论。--1F616EMO喵留言回复请ping) 2025年6月1日 (日) 23:52 (UTC)
Wikipedia talk:中立的观点 § 对“Wikipedia:中立的观点”最近修改的异议

近日发现,Wikipedia:中立的观点最近做了一次比较大的修改,我认为此修改存在一些问题:

  1. 程序问题。说没有讨论吧,好像还讨论了;说讨论了吧,又是针对 Wikipedia:命名常规的讨论。问题是,“中立”是我们的“五大支柱”之一,但“命名常规”不是。这就好比,我们在讨论修订“刑法”的时候,发现我们打算发布的新条文跟“宪法”有矛盾,所以我们就顺便把“宪法”也改了。
  2. Wikipedia:是英文维基说的!此修改似乎是完全照搬了英维?(这个大家都懂,就不多解释了。)
  3. 重点)凌驾于“支柱”之上。此修改似乎特别拔高了“常用”的地位,特别是使其凌驾于“中立”这一“支柱”之上。“常用”本身只是一条普通方针,是需要与其它规则作平衡的,不是必须的。而支柱是必须遵守的。将任一方针凌驾于“支柱”之上,都是不可取的。
  4. 英文与中文的区别。(我英文水平有限,如果这一点说得不对,还望大家多多指教。)在中文里,“不偏向某一方观点”叫“中立”,“不褒不贬”叫“中性”;但在英文里似乎都是用的“Neutral”。所以在英维里,在讲“Neutral”的时候,似乎还包含了“不要褒也不要贬”含义。因此在所用例子中,似乎是有“把使用了贬义词(或褒义词)(而非偏向某一方观点)当作不 Neutral”的情况。如果我的理解没错,那么照搬英维就更不可取了。
  5. 晦涩难懂。不光是翻译的问题,英维本身就比较晦涩。当然,这是个次要问题,前面的问题解决了,才需要处理这个问题。

--Ma3r铁塔) 2025年6月8日 (日) 01:26 (UTC)

Wikipedia talk:用户页 § 关于wp:FAKEARTICLE

目前,若WP:FAKEARTICLE成立,绝大多数在用户空间的废弃草稿、幽默内容、久未编辑的沙盒等都应被提删,将影响逾千页面。因此,交予社群讨论。--WiiUf留言) 2025年6月12日 (四) 04:57 (UTC)

Wikipedia talk:存废复核 § 为修订存废复核方针放宽临时恢复制度事

最近经Wcam提醒,我才发现依据“存废复核方针”规定,临时恢复已删除条目供查看之制度,系置于“处理结果”一段,仅限于管理员特别“要求(社群)介入”时始得应用。我认为这不合理,因为以实务情况而言,若干比较困难的存废复核请求,几乎总是需要相当社群意见以达成共识,很少由管理员自行裁决;而已删条目一般情况下根本难以检阅,何况开放社群就其内容讨论原始存废决定妥适与否。是以仅允许管理员于“结案途中”恢复条目供社群讨论,不免限制过度。另查英文维基百科存废复核请求现行规定,则明文表示:“管理员经常受托恢复已删除页面以供查看,将内容替换为TempUndelete模板,同时允许所有人查阅(编辑)历史”(Admins participating in deletion reviews are routinely requested to restore deleted pages under review and replace the content with the {{TempUndelete}} template, leaving the history for review by everyone.),并未有其他介入要件(其余禁止恢复侵权内容等细节规定均同)。据此,本人提出“存废复核方针”修订案如下:

现行条文

管理员须知

  • 鉴于维基百科:管理员对管理员行为的限制,先前曾以下述形式参与待复核页面相关处理流程的管理员,原则上应避免处理存废复核的提案:
    • 存废讨论的提报、投票与讨论、结束讨论及目标页面处理,以及快速删除、修订版本删除的提报、提出异议、讨论和处理。

处理结果 管理员可就提案作以下回应︰

  1. 维持原决;或
  2. 发还至相关存废讨论,即重新提交讨论,先恢复后提案至相关讨论亦可,重新提交讨论时应于新讨论处附上存废复核存档和原讨论存档的内部链接;或
  3. 转介至存废讨论,当阁下认为速删决定有违快速删除准则,并应获得全面存废讨论时适用;或
  4. 推翻原决并代之以其他操作,唯须列明其他操作为何;或
  5. 要求介入,当管理员无法就提案下取决定,尤其涉及内容复审、方针指引规范未明或易于引发争议之提案,管理员可作此决定,要求社群介入讨论,用户则可用上述四项回应表达自己意见。启用此程序时,当事管理员应尽量阐明问题所在,以利讨论。为使社群有足够参与,管理员作此决定以后,须于公告栏互助客栈发出通知,亦应通知曾参与存废讨论用户。此程序一旦展开,一般为期一周,有需要时可列明理由延长时限,唯切勿缩短期限,亦莫应超越五周之限。期届以后,管理员应依照共识执行结果,结束提案。如果要求介入讨论以后,依旧未达共识,则应以无共识结束提案。在未有新理据前,不建议再就该(等)条目提案。如条目已经删除,管理员可临时恢复页面并悬挂{{Tempundelete}},以便社群讨论。然而,切勿恢复任何侵犯著作权、有违生者传记方针或其他方针禁止之内容当然,即使管理员未有作此决定,用户仍可随时就提案发表意见。

切记复核并非再就有问题内容发表意见之时机,而应用以纠正过程中所发生(未有重要新资料所引起)之缺失。故此,无论用户或管理员,使用第四项回应时,“其他操作”应可确切反映共识。

提议条文

管理员须知

  • 鉴于维基百科:管理员对管理员行为的限制,先前曾以下述形式参与待复核页面相关处理流程的管理员,原则上应避免处理存废复核的提案:
    • 存废讨论的提报、投票与讨论、结束讨论及目标页面处理,以及快速删除、修订版本删除的提报、提出异议、讨论和处理。
  • 如条目已经删除,管理员可依据共识临时恢复页面,并悬挂{{Tempundelete}},以便社群讨论。然而,切勿恢复任何侵犯著作权、有违生者传记方针或其他方针禁止之内容

处理结果 管理员可就提案作以下回应︰

  1. 维持原决;或
  2. 发还至相关存废讨论,即重新提交讨论,先恢复后提案至相关讨论亦可,重新提交讨论时应于新讨论处附上存废复核存档和原讨论存档的内部链接;或
  3. 转介至存废讨论,当阁下认为速删决定有违快速删除准则,并应获得全面存废讨论时适用;或
  4. 推翻原决并代之以其他操作,唯须列明其他操作为何;或
  5. 要求介入,当管理员无法就提案下取决定,尤其涉及内容复审、方针指引规范未明或易于引发争议之提案,管理员可作此决定,要求社群介入讨论,用户则可用上述四项回应表达自己意见。启用此程序时,当事管理员应尽量阐明问题所在,以利讨论。为使社群有足够参与,管理员作此决定以后,须于公告栏互助客栈发出通知,亦应通知曾参与存废讨论用户。此程序一旦展开,一般为期一周,有需要时可列明理由延长时限,唯切勿缩短期限,亦莫应超越五周之限。期届以后,管理员应依照共识执行结果,结束提案。如果要求介入讨论以后,依旧未达共识,则应以无共识结束提案。在未有新理据前,不建议再就该(等)条目提案。当然,即使管理员未有作此决定,用户仍可随时就提案发表意见。

切记复核并非再就有问题内容发表意见之时机,而应用以纠正过程中所发生(未有重要新资料所引起)之缺失。故此,无论用户或管理员,使用第四项回应时,“其他操作”应可确切反映共识。

以上,请社群讨论。此处修订案,仅涉及条文搬动,至于是否应比照英文维基百科,于悬挂模板时替换所有内容,本人则没有特别意见。—— Eric Liu 創造は生命(留言留名学生会 2025年6月14日 (六) 12:35 (UTC)

Wikipedia talk:删除 § 在存废讨论中禁止/建议避免使用图示标记立场

目前存废讨论使用众多带有图示的表态模板,例如“(×)删除”、“(○)保留”,共同点是在表态字样前带有着色的文字图示。这种图示过分的强调了删除/保留这种概括的立场,而非持某种立场背后的原因,容易使管理员判断共识时侧重于立场本身而非重视正当合理的意见。因此,我建议参照信息框旗帜“不必要地分散读者的注意力,并可能使众多文段中的特定文段过分突出”而禁用的共识,在存废讨论中禁止/建议避免使用图示标记立场。

英文维基百科曾经达成类似的共识,并最终删除相关投票模板。英维在2005年对{{支持}}、{{反对}}及{{中立}}模板的存废讨论中,编者达成共识,认为这些模板让存废讨论倾向于成为投票而非达成共识之处,且将注意力从编者的意见挪开后续对其他模板的存废讨论亦继续支持此共识,亦有人指出这些模板会助长投票(而非讨论)的行为。英维社群亦在不同的时间达成同样的共识,供各位参考。

就中维的状况而言,不同于英维模板的昙花一现,{{删除}}、{{保留}}等模板历史悠久,期望用户突然抛弃这类用法而转而手动使用粗体不切实际。因此,我建议在这类模板中检查嵌入页面是否存废讨论,并在存废讨论中隐藏图标,仅保留粗体,例子可见{{删除}}模板的沙盒。另提议在WP:删除 § 存废讨论中添加以下内容:

提议条文
存废讨论是讨论页面存废的场所……

为促进共识的创建,避免讨论流为投票,分散参与者和判断共识的管理员的注意力,进行讨论时不宜/不得用图示强调立场(例如“(×)删除”、“(○)保留”、“(►)移动”等),但使用粗体强调意向并没有问题。{{删除}}、{{保留}}等曾经会输出图示的存废意向模板会在存废讨论页自动隐藏图示,只会输出对应的粗体,可以照常使用。

除共识相当明显的情形……[下略]

关于应该使用“不宜”还是“不得”,私以为两者皆可。以上,提请社群讨论。--1F616EMO喵留言回复请ping) 2025年6月20日 (五) 16:12 (UTC)

Wikipedia talk:讨论页指引 § 建议统一讨论页及布告板的主题标题层级为二级标题

既然先前讨论串已有明确的修改共识,以下讨论该如何修改。除了下面提到的改动以外,还需对外观进行略微改动(如,去掉“提名区”2级标题),以及存档bot需要修改配置,这个因为很简单故不赘述。--SuperGrey (留言) 2025年6月24日 (二) 03:40 (UTC)

Wikipedia talk:傀儡 § 就临时账户修改退出编辑的相关条文


由于本站已经部署临时账户,但“在退出状态下编辑”一节尚未更新,现提议修订如下:

现行条文
在退出状态下编辑

在某些情况下,拥有账号的编辑者有可能会以未登录状态编辑维基百科,原因例如登录状态意外过期,以新设备访问维基百科,经其他网站编辑维基百科,遗忘账号密码等。未登录的编辑者不得主动欺骗其他编辑者,例如直接声明没有账号或将会话用于本方针前述列出的滥用多重账号的行为。为了保护隐私,在退出状态下编辑的编辑者永远不需要将其用户名与编辑时的IP地址相关联。

如使用多重IP地址进行编辑,以迷惑他人或违反上述原则,亦可视作是使用多重帐号的行为。注册用户在未登录情况下进行编辑,其IP地址亦会被视为另一个账户。故如果您因无心之失退出并作出编辑,您可联系管理员或拥有监督权限的用户以避免被误会。

如果您担心IP编辑者实际上是一个拥有账户的用户,并且在退出时以不适当的方式进行编辑,您可以将此方针通知IP编辑者({{subst:uw-login}}可用于此目的)。如果继续发生这种行为,您可通过傀儡调查页面发起调查。
提议条文
在退出状态下编辑

在某些情况下,拥有账号的编辑者有可能会以未登录状态编辑维基百科,原因例如登录状态意外过期,以新设备访问维基百科,经其他网站编辑维基百科,遗忘账号密码等。未登录的编辑者不得主动欺骗其他编辑者,例如直接声明没有账号或将会话用于本方针前述列出的滥用多重账号的行为由于临时账户的IP地址可被临时账户IP查看者存取,为了保护隐私,在退出状态下编辑的编辑者永远不需要将其用户名与其临时账户相关联。

如使用多个临时账户进行编辑,以迷惑他人或违反上述原则,亦可视作是使用多重帐号的行为。注册用户在未登录情况下进行编辑,其临时账户亦会被视为另一个账户;若用户清除了浏览器Cookie、手动退出了临时账户或切换了装置,在再次进行编辑时,亦会创建另一个临时账户。故如果您因无心之失退出并作出编辑,您可联系管理员或拥有监督权限的用户以避免被误会。

如果您担心使用临时账户的编者实际上是一个拥有注册账户的用户,并且在退出时以不适当的方式进行编辑,您可以将此方针通知该临时账户编者({{subst:uw-login}}可用于此目的)。如果继续发生这种行为,您可通过傀儡调查页面发起调查。

邀请@TigerzengStangA2569875。--1F616EMO喵留言回复请ping) 2025年7月1日 (二) 03:53 (UTC)

Wikipedia talk:界面管理员 § 修订界面管理员有关2FA的内容

众所周知,界面管理员用户组的创建就是降低安全风险,而双因素认证就是一个可以有效提高账号安全,从而避免账号被破解导致出现事故的工具。元维基已明确对当地的界面管理员用户组强制开启双因素认证,英文维基百科也参考了元维基的这一要求。本站长期缺乏这方面的要求,是时候在方针中明确强调这一点了。

同时,近日行政员拥有了查看一名用户是否启用了双因素认证的功能,因此合理提议,行政员在授予用户界面管理员权限时,应使用Special:VerifyOATHForUser确认对方已经启用了这一功能,否则不予授权。

提议修订如下:

现行条文

用户可经申请成为界面管理员,并长期持有权限。界面管理员须经票选产生,票选为期十四日,得至少25票支持为之有效,而支持者占其中总得票数至少75%才可通过。投票通过后,则由行政员授权。管理员如为2018年7月5日前上任,经三日投票,简单多数支持,则可以取得界面管理员权限。如果三日内未有任何用户投票,则应延长至七日。期后如仍无用户投票,则由行政员决定是否任命。用户如需申请短期权限,则可至行政员布告板申请。用户可参与讨论及表态是否赞同申请,并附以理据支持。最终由行政员按讨论内容决定是否批准申请。

提议条文

用户可经申请成为界面管理员,并长期持有权限。界面管理员须经票选产生,票选为期十四日,得至少25票支持为之有效,而支持者占其中总得票数至少75%才可通过。投票通过后,则由行政员授权。行政员在授权前,应使用Special:VerifyOATHForUser检查用户是否启用了双因素认证。如果用户无法启用这一功能,行政员应告知用户前往元维基申请启用双因素认证。在未启用双因素认证时,行政员不得授权。管理员如为2018年7月5日前上任,经三日投票,简单多数支持,则可以取得界面管理员权限。如果三日内未有任何用户投票,则应延长至七日。期后如仍无用户投票,则由行政员决定是否任命。用户如需申请短期权限,则可至行政员布告板申请。用户可参与讨论及表态是否赞同申请,并附以理据支持。最终由行政员按讨论内容决定是否批准申请。

希望可以参与讨论,谢谢。 Stang1298 2025年7月2日 (三) 15:10 (UTC)

Wikipedia talk:禁制 § 被禁止编辑项目命名空间的编者可否回应布告版上的指控

如果被禁制(禁止WP页面),然后被提报至 维基百科:管理员布告板/其他不当行为维基百科:当前的破坏 等页面,他回应的话 是否构成违反编辑禁制。
最近的例子 Wikipedia:管理员布告板/其他不当行为#HMOXDSS1_2。--—Jackyming留言贡献・这位编辑者是一位奶味蓝🤩) 2025年7月4日 (五) 16:52 (UTC)

Wikipedia talk:保护 § 事实修订用户页的预见性半保护

当前的半保护方针规定了允许用户出于预见性原因要求半保护自己的用户页面,然此写法显然会让人误会为只要申请基本上就可以通过。查@Bluedeck(这里是故意ping的)原始加入条文的澄清声明指出:

故我认为应该将这句写清楚。

现行条文
半保护政策用于保护受到严重破坏的页面和讨论页面的存档,例如编辑战等会对页面构成严重影响,这个政策不是用来保护具有争议的页面的,因为这会限制了部分用户编辑页面的自由。但是,允许用户出于预见性原因要求半保护自己的用户页面。管理员在执行这政策时应持与执行全保护政策时同一样的要求,不论是由他们自行决定还是由其他页面要求的,如请求管理员帮助、请求保护页面或其他相类的页面。
提议条文
半保护用于防止非自动确认用户对页面造成严重破坏,如编辑战等可能严重影响页面内容的行为,适用对象包括一般内容页面与讨论页面的存档。

半保护不应用于保护具有争议的页面,惟用户页若用户有合理的理由提出请求则不在此限。

管理员处理半保护请求时应与全保护的处理要求相同。

(我重写了整句话,因为不重写整句话要改实在很怪 囧rz……)--SunAfterRain 2025年7月5日 (六) 16:44 (UTC) 👍1

左右两边没有实际差别,并且右边更清晰,我觉得很好。不过题外话:现在我觉得如果用户想要半保护某个用户子页其实没什么不可以,而且我觉得半保护和全保护的标准要相同这一点我也不太同意。。。。Bluedeck 2025年7月5日 (六) 22:19 (UTC)
@Bluedeck我猜原本的意思是要同样的处理态度(例如不能说全保护要删五个字才叫破坏,但半保护只要删三个字就可以当成破坏)看待?问问原始加入者@Shizhao。--SunAfterRain 2025年7月6日 (日) 04:09 (UTC)
Wikipedia talk:收录标准/交通 § 建议巴士总站的收录标准

目前香港有大量巴士总站获得收录,但我检查后发现不少巴士总站只是单纯的路边巴士总站,实际上与普通路边巴士站无分别,收录价值甚低。建议更新收录标准指引,除非有大量传媒报导的路边巴士站(这样会直接符合GNG),否则应拒绝收录路边巴士总站。设有车坑的,则可被视为相对重要,值得收录,而巴士转车站可被视为设有1条车坑的巴士总站(而且设立时通常会有大量传媒报导)。这样,坑状巴士总站、锯齿型巴士总站、分层式巴士总站以及巴士转车站都符合标准,避免了大量删除巴士总站的可能性。另外,对于香港以外的巴士总站,亦可考虑采用类似方式处理,比如澳门的巴士总站、台湾的公路转运站、中国大陆的公路汽车站和长途客运站,乃至其他国家的类似巴士总站等等也大差不差。User:SanmosaUser:Foamposite,你们说呢?--owennson聊天室奖座柜) 2025年7月8日 (二) 19:14 (UTC)

Wikipedia talk:命名常规/音乐 § 提议取消对消歧义后缀“(EP)”的禁用

本命名常规在创建之初,就引入了“(迷你专辑)”为规范消歧义后缀。在2021年9月对“MediaWiki:Titleblacklist”的编辑请求中,为配合命名常规的需要,“(EP)”被禁止作为消歧义后缀。

2024年1月在互助客栈的讨论得出将“迷你专辑”改为消歧义、内容分拆为“EP”与“迷你密纹唱片”的结论后,中文维基百科内各处就停止了将“EP”翻译为“迷你专辑”,以与“mini album”(迷你密纹唱片)做区别。根据当前的共识,是否应该修订本命名常规?此处抛砖引玉提出2个方案:

方案一,考虑取消对“(EP)”的禁用,可以根据实际需要选用“(EP)”或“(迷你专辑)”。

方案二,考虑将当前非韩语、华语的EP由“(迷你专辑)”统一修改为“(EP)”;未来仍允许编者自主选用“(迷你专辑)”表示迷你密纹唱片。通过机器人可以实现。

副知命名常规的主要编写者与所有相关讨论的参与者@MilkypineSanmosaSoftyuPseudo Classes魔琴FactrecordorDavid XuangAbcet10Dabao qian。--SuperGrey (留言) 2025年7月10日 (四) 18:15 (UTC)

Wikipedia talk:讨论页指引 § 讨论页行为的边界:是善意提醒还是骚扰攻击性的贴标签行为?

核心问题:维基百科是否允许用户以“澄清误导”或“陈述事实”为由,在讨论页上对其他用户的发言逐条张贴其过往的、与发言内容本身无关的负面信息(如称“该用户曾被封禁“、“使用傀儡”等等)?

本次讨论的具体背景案例

我的子账户因使用程序违规而受到管理员Tigerzeng封禁6个月的处罚。随后之前与我就条目内容存在异议的用户Lvhis便以“傀儡发言”为由删除了本人(子账户)的讨论页发言,又以“偏离主题”为由删除了另一用户要求其留意他人意见、不要擅动条目的留言(special:diff/87892033)。后由其他用户根据管理员意见帮忙恢复。

但在管理员Tigerzeng多次告知Lvhis “已经不足以造成误导”、“已经没有理由去做更多的行动”,并明确建议若仍有分歧“应将问题暴露给更大范围的社群讨论”,以及有第三方用户明确反对Lvhis擅自去添加标注的情况下,用户Lvhis仍坚称“当时造成的误导还没消失”,并据此擅自采取行动,继续反复在本人的逐条留言上方添加其自定义的大字报式标签(“xxx系xxx违规创建的傀儡账号...已被封禁6个月”),又再次以Liu116提及本人两账号同属一人的发言属于“偏离条目主题”为由,删除了对其讨论页行为的批评意见。本人后续再次将该行为提报至ANM,但管理员仍未对其所有行为作出明确的裁定和判罚,导致争议僵持至今。

补充说明: 为帮助社群更全面了解情况,有必要指出,即便在遭到二位管理员的委婉反对后,用户Lvhis的行为模式仍在持续,坚持发表歪曲事实的言论

1.曲解管理员操作:声称管理员的干预是为了保护其添加的tmbox。而事实是,管理员的干预是在Liu116提请页面保护后,为了阻止其第三次删除他人留言而引发编辑战所采取的标准化行动。

2.坚持置若罔闻:依然在为自己删改他人留言的行为辩解,认为自己行为无错,并攻击第三方用户动机。

这种被管理员委婉反对后依然持续进行歪曲事实、攻击他人的行为,进一步凸显了探讨并明确相关规范和行为准则的紧迫性和必要性。

我的观点:

1.在讨论页利用自定义模板,给他人的发言逐段张贴非必要的负面标签的做法,是一种没有任何方针支持和允许的变相人身攻击和私刑,且违反WP:TPG。账户关系信息已在用户主页等处有方针指定的渠道公示,个人不应越权擅自发明规则。再欲强行在讨论页上进行重复的、非标准化的“示众”,唯一的目的就是羞辱和骚扰对手,而非善意澄清。如果社群对上例中Lvhis式的独断行为缺乏明确的反对,将会开启一个非常危险的先例和潘多拉魔盒。

傀儡方针中关于标注的规定,仅限于在用户页上进行标准化的公示。如果案例中这种无任何方针支持的、在讨论页四处“贴标签”的滥用行为(即便陈述了部分事实)被允许,那么谁都可以借对方的“黑历史”(如曾被封禁、曾创建不合格条目等)给他人留言逐条张贴大字报来进行变相的攻击(本质上是因人废言和人身攻击的一种形式),这将彻底毒化讨论页的协作环境,将其变为互贴标签的战场,与文明等方针完全背道而驰。

一个用户的程序性过失和身份无关乎其讨论发言的论证质量(除非因制造虚假多数意见而构成实际误导),更不应成为另一个用户对其进行无休止的、超出方针允许范围的骚扰攻击和私刑的理由。用户的身份、封禁记录等信息,应由其用户页的官方模板进行统一、中立的公示,不应由其他用户在各处进行个人的、非标准的“示众”。

2.程序上无视共识流程。在本案中Lvhis在管理员已明确建议“应将问题暴露给更大范围的社群讨论”且有第三方反对后,仍强行执行其单方面操作。这是对共识精神的根本破坏。任何有争议的操作,在进入社群讨论程序后都应暂停执行,何况存在明显反对。


建议:

提议社群明确(或对WP:TPGWP:NPA进行补充写入类似规定):在用户页已有官方模板进行身份或状态公示,且没有构成实际误导效果的情况下,任何用户不应在他人留言旁添加与讨论内容本身无关的、指向其个人历史或身份的标注。此类未经社群共识的“贴标签”行为应被视为扰乱,可由任何用户移除。--SK.留言) 2025年7月11日 (五) 00:40 (UTC)

Wikipedia talk:游戏维基规则 § 对《游戏维基规则》序言的若干小修订

本次拟议修订如下:

  1. 废除“恶意使用”,代以“故意以错误的方式使用”
    • 在中维的实践中,GAME这一概念中的“恶意”含义已经被淡化;在实践中,GAME多是作为一个行为被提述,而无暗示该行为的动机。如搜索ANM的存档,不难看到提述GAME的留言多用类似“构成WP:GAME”、“犯了WP:game”、“是WP:GAME的一种”的字眼。
    • 另参见英文维基百科关于移除“恶意”一词的讨论
  2. 废除“不应该视作是善意的失误”,代以“像善意的失误一样被处理”
    • 这一句自页面创建起已经存在,而英维的对应版本使用的是“should not be treated the same as a good faith mistake”,而非“should not be treated as a good faith mistake”,为中维误译。
  3. 废除“管理员的警告”,代以“他人的警告”

综上,提议修订序言如下:

现行条文
游戏维基规则Gaming the system)是指恶意使用维基百科方针和指引,阻碍维基百科目标实现的行为。游戏维基规则可能表现为滥用程序、扰乱性编辑或其他违反社群共识精神的行为。一般而言,编辑者游戏维基规则是为了阐释观点、持续打编辑战或强化某一特定的非中立观点
如果有编辑者发现规则中存在漏洞,使得他们可以侵犯社群标准或不当使用管理工具,那这种行为就不应该视作是善意的失误。但是,封禁是预防性措施而非惩罚性措施。一般而言,管理员的警告是阻止游戏维基规则的最佳方式,因为清晰的警告往往能协助纠正善意的失误和恶意的游戏行为。如果编辑者无视警告,重复其行为,或者他们发现新的方法来达成相同的扰乱目的,那么他们更有可能是在恶意游戏维基规则。
提议条文
游戏维基规则Gaming the system)是指故意以错误的方式使用维基百科方针和指引,阻碍维基百科目标实现的行为。游戏维基规则可能表现为滥用程序、扰乱性编辑或其他违反社群共识精神的行为。一般而言,编辑者游戏维基规则是为了阐释观点、持续打编辑战或强化某一特定的非中立观点
如果有编辑者发现规则中存在漏洞,使得他们可以侵犯社群标准或不当使用管理工具,那这种行为就不应该善意的失误一样被处理。但是,封禁是预防性措施而非惩罚性措施。一般而言,他人的警告是阻止游戏维基规则的最佳方式,因为清晰的警告往往能协助纠正善意的失误和恶意的游戏行为。如果编辑者无视警告,重复其行为,或者他们发现新的方法来达成相同的扰乱目的,那么他们更有可能是在恶意游戏维基规则。

以上,提请社群讨论。--1F616EMO喵留言回复请ping) 2025年7月12日 (六) 01:03 (UTC) 👍1

(+)支持--某人 2025年7月12日 (六) 02:20 (UTC)
Wikipedia talk:快速删除 § G15的具体含义
@Sanmosa上面问题没回我,所以User_talk:Xiplus/沙盒11User_talk:Xiplus/EditnoticeUser_talk:Xiplus/存档(这是个模板,不是讨论页存档,不符豁免条件)都符合G15?--Xiplus#Talk 2025年7月12日 (六) 03:28 (UTC)
Wikipedia talk:快速删除 § 跨命名空间重定向

我想在这里寻求大家对于以下情境的恰当性的看法:

  1. 位于非讨论页空间但指向讨论页空间的重定向(如Template指向Talk);
  2. 位于讨论页空间但指向非讨论页空间的重定向(如Talk指向Template);与
  3. 位于Draft talk空间但指向其他讨论页空间的重定向(如Draft talk指向Talk),
以上。Sanmosa DC23 2025年7月13日 (日) 01:25 (UTC)

维基百科提议

Wikipedia talk:新条目推荐/候选 § DYK上首页而地区词未转换

刚刚看首页发现,DYK的“问题”似乎没有要注意地区词转换,如现在有出现公交和高达,明显没有转换。在GA和FA以及新闻动态都因上首页需要注意手动转换的部分,因为我很少看DYK,对于相关运作不是很理解,有疑虑所以提出。--提斯切里留言) 2025年5月28日 (三) 13:43 (UTC)

Template talk:Welcomeip § 编辑请求
此讨论正在公示7天,直至2025年7月18日 (五) 15:45 (UTC)结束;如有意见请尽快提出。

由于目前匿名用户已不再被使用,故提议修改该模版如下:

修改后

欢迎加入维基百科! 您好!感谢您对维基百科的兴趣与贡献,希望您会喜欢这里,您可以继续以临时身份参与,但您的账号有效期仅有90天(不论活跃与否)。您不妨考虑登录或注册一个账户以永久使用您的账户,并拥有更多功能,例如您能够:

  1. 编辑受半保护页面;
  2. 选择一个属于您自己的用户名;
  3. 进行个性化的设置,添加增强工具;
  4. 拥有自己完整的贡献记录;
  5. 更方便地参加社群事务⋯⋯

此外,也请您了解以下重要文章:

有疑问?需要帮助?欢迎到互助客栈IRC频道询问。
祝您编辑愉快!

Welcome! If you can't understand Chinese, please feel free to ask or request anything here. Thank you for visiting!

欢迎您的维基人是:~~~~

WiiUf留言) 2025年6月25日 (三) 13:11 (UTC)

WikiProject talk:中国行政区划 § {{PRC admin}}及其子模板清理讨论
此讨论正在公示7天,直至2025年7月18日 (五) 17:34 (UTC)结束;如有意见请尽快提出。

该系列模板使用的包括但不限于区划代码、名称等数据已是10年前的版本,有鉴于:

  1. 国家统计局,也就是本站及wikidata使用的代码数据源,现在已经停止公开发布其统计代码,民政部现仍公开发布到乡级(第四级)深度的行政代码,两者代码在乡级编码上不尽相同;
  2. 对于村级(第五级)代码,统计代码停留在2023年版本,行政代码有零星省份的民政厅在官网上公开,但批量获取十分麻烦;
  3. {{PRC admin/children}}即用于条目页显示下级行政区划名称的模板,是提取对应条目之维基数据项目的P150值显示名称,而非使用本站现有Template:PRC admin/data/12/34/56/789/XXX,即村级区划模板数据页的值;
  4. 基于上方讨论链接的数据粗略计算,乡级部分民政部现用代码和2023年版本国家统计局代码差异量有1万条以上。

提请社群同意使用机器人对该系列模板按顺序执行如下操作:

  1. 将所有Template:PRC admin/data/12/34/56/789/XXX,即村级区划模板数据页的现有数据转移至维基数据;
  2. 在现有Template:PRC admin/data/12/34/56/XXX/000,即乡级区划模板数据页替换现有文本,一律使用新建模板{{PRC admin/showlist/town}}显示乡级区划的下级列表,该模板会自动拉取对应的P150值并显示下级行政区列表,显示示例在此
  3. 删除所有村级区划模板数据页;

以上。ping前次讨论参与者@KethygaKcx36Ericliu1912PexEric--Hamish T 2025年6月26日 (四) 18:37 (UTC)

Wikipedia talk:管理人员申请意向调查 § 就管理人员申请意向调查征集意见

英维的管理人员申请意向调查(英语:Optional RfA candidate poll)可以让编者知道申请成为管理人员的当选机会,接受社群在这方面的意见,并使编者了解到自己在这方面的弱点。为让拟申请成为管理人员的中维编者亦能受惠,我从英维翻译了该页面(WP:管理人员申请意向调查),并进行了以下修改:

由于启用意向调查无需将之订立为方针指引,因此无需公示等正式程序,我项目在征求足够广泛的意见并初步修改不足之处后,便会付诸实践,并继续检查机制是否存在问题。以上,提请社群讨论。--1F616EMO喵留言回复请ping) 2025年6月27日 (五) 08:23 (UTC)

Wikipedia talk:茶馆 § 建议将此页面改为软重定向

由于此页面已被搁置三年且未见实际用途,建议将其改为至WP:VPH的软重定向。--WiiUf留言) 2025年6月27日 (五) 14:10 (UTC)

有关申请权限与申请解除权限的方针条文与申请区的放置问题

[编辑]

WT:方针与指引#修订方针与指引的命名格式曾经提到有关申请权限与申请解除权限的方针条文与申请区的放置问题,当时Ericliu1912提议WP:解除权限比照WP:权限申请的处理并入WP:申请解除权限,而我则反建议WP:权限申请比照WP:解除权限WP:申请解除权限的处理分拆方针条文与申请区的页面。考虑到现在距离批量调整规则页面名称已经有一段时间,社群或许应该探讨到底要选择哪个方案,我自己对于两个方案均持开放态度。Sanmosa 新朝雅政 2025年4月20日 (日) 10:12 (UTC)回复

我主张合并的理由是解除权限方面的方针页跟申请页都比权限申请要短,而且两者并没有扞格问题,不必分立,也方便检阅者一次确认有关要件。—— Eric Liu 創造は生命(留言留名学生会 2025年4月20日 (日) 12:55 (UTC)回复
然后刚刚才注意到甚至申请页面整段说明都是“包含引用自维基百科:解除权限方针”,没有任何内容差异,所以实际上两者完全可以合并在一起啊== —— Eric Liu 創造は生命(留言留名学生会 2025年4月20日 (日) 12:56 (UTC)回复
合并在同一页不易查看方针指引的修订历史。--Xiplus#Talk 2025年4月22日 (二) 15:36 (UTC)回复
如果走Ericliu1912方案的话,可以让除权申请区改为比照现WP:权限申请的申请区处理,也就是每类除权申请一个独立的子页面。Sanmosa 新朝雅政 2025年4月25日 (五) 12:35 (UTC)回复
@Xiplus?还是说你比较倾向于分拆WP:权限申请页?Sanmosa 新朝雅政 2025年4月29日 (二) 07:18 (UTC)回复
我觉得应该废除该页的方针地位,因为该页面几乎都是复述各权限方针的内容而已。如果真的有任何应该属于方针层级的内容,应当拆分到各权限介绍页或另立“权限申请方针”页面。--Xiplus#Talk 2025年4月29日 (二) 14:45 (UTC)回复
@Ericliu1912Sanmosa 新朝雅政 2025年4月30日 (三) 01:58 (UTC)回复
这很值得考虑!—— Eric Liu 創造は生命(留言留名学生会 2025年4月30日 (三) 05:54 (UTC)回复
@XiplusEricliu1912如此,那WP:权限申请的版面或许需要重新设计,此外WP:申请解除权限引述现WP:解除权限方针的部分也需要作一定的调整,个人建议可以参考现WP:存废复核请求顶部的说明文字处理。Sanmosa 新朝雅政 2025年4月30日 (三) 14:45 (UTC)回复
改写成最合适的说明文字当然可以,但我不认为现在两个申请页的说明有什么不得不改的问题。--Xiplus#Talk 2025年5月4日 (日) 04:28 (UTC)回复
@Xiplus那我尝试在今日稍后给一个方案出来。Sanmosa 新朝雅政 2025年5月8日 (四) 04:47 (UTC)回复
现阶段拟定的方案是WP:权限申请移除“简介”与“要求”的全部内容,WP:申请解除权限引述现WP:解除权限方针的部分代之以现WP:权限申请“解任”的内容,并将其中指向WP:申请解除权限的内部链接替换为“本页”。另外,为确保页面命名一致性,现建议WP:权限申请更名为“WP:申请权限”,所有子页面同。Sanmosa 新朝雅政 2025年5月8日 (四) 23:48 (UTC)回复
会废除方针?--Xiplus#Talk 2025年5月10日 (六) 02:55 (UTC)回复
@Xiplus会,WP:权限申请的方针地位会被废除。Sanmosa 新朝雅政 2025年5月10日 (六) 10:01 (UTC)回复

“IP封禁豁免权及确认用户权限除外之权限切勿于本页外申请”一句应修订到各方针页。--Xiplus#Talk 2025年5月11日 (日) 00:53 (UTC)回复

@Xiplus可,我明天再看看具体要放到哪个方针页里。Sanmosa 新朝雅政 2025年5月11日 (日) 12:22 (UTC)回复
所有权限的方针都要吧(这两个除外),除非另立申请权限方针。--Xiplus#Talk 2025年5月11日 (日) 12:55 (UTC)回复
@Xiplus刚才统计了一下,理论上需要修订的页面应该包括WP:新页面巡查WP:回退功能WP:巡查豁免权WP:大量讯息发送者WP:AutoWikiBrowserWP:大量账号创建者WP:文件移动员WP:跨维基导入者WP:模板编辑员WP:过滤器助理WP:IP封禁豁免权授予者WP:活动组织者WP:过滤器编辑者,然而其中大部分的页面似乎已经有相关的描述了。此外,我留意到这些页面虽然大多数是方针,但还是有少数几个是指引,是否需要把那几个指引与现非规则的WP:巡查豁免权也提升为方针?Sanmosa 新朝雅政 2025年5月12日 (一) 07:39 (UTC)回复
用词不一样,并没有禁止在其他地方申请。提升方针与此无关,另案讨论。--Xiplus#Talk 2025年5月12日 (一) 13:01 (UTC)回复
@Xiplus那可以调整既有条文的用词至有禁止在其他地方申请的意思,但需要提具体方案吗?感觉这要做比较占这里的版面。提升为方针的事情我打算之后才处理,我也只是询问一下意向而已。Sanmosa 新朝雅政 2025年5月15日 (四) 13:51 (UTC)回复
(其实不用什么东西都提去方针⋯⋯)—— Eric Liu 創造は生命(留言留名学生会 2025年5月15日 (四) 16:17 (UTC)回复
应该要提具体方案。--Xiplus#Talk 2025年5月18日 (日) 05:13 (UTC)回复
@Xiplus具体方案:
以上。Sanmosa 新朝雅政 2025年5月18日 (日) 06:38 (UTC)回复
个人支持。--自由米花🌾🌼 2025年5月22日 (四) 15:46 (UTC)回复
这部分没有问题。--Xiplus#Talk 2025年5月24日 (六) 12:56 (UTC)回复
巡查豁免权一节有“本权限无需由申请者本人提出申请”,这是否表示其他权限必须由本人提出申请,不得提名?--Xiplus#Talk 2025年5月24日 (六) 12:59 (UTC)回复
@Xiplus按照过往的理解,确实如此(如果把IP封禁豁免权从“其他权限”排除掉的话)。Sanmosa 新朝雅政 2025年5月24日 (六) 13:26 (UTC)回复
自动维基浏览器使用权 :“管理员有权在申请者申请机器人权限前拒绝其自动维基浏览器使用权限申请。另外,对于已获机器人审核小组批准运作的机器人,可直接予以授权。”可能需列为方针?--Xiplus#Talk 2025年5月24日 (六) 13:02 (UTC)回复
可以列为章节方针,又或是如果合适的话,整个页面列为方针也未尝不可。Sanmosa 新朝雅政 2025年5月24日 (六) 13:29 (UTC)回复
解任一节“如机器人账户同时持有AWB使用权及机器人权限,不受此限并应该依据机器人方针活跃度要求,AWB使用权与机器人权限同步移除。”需移至Wikipedia:解除权限。--Xiplus#Talk 2025年5月24日 (六) 13:06 (UTC)回复
我无法找到这句话,还请指出出现的位置。Sanmosa 新朝雅政 2025年5月24日 (六) 13:31 (UTC)回复
应该是在Wikipedia:权限申请#解任。--Hamish T 2025年5月24日 (六) 15:16 (UTC)回复
@XiplusHamish那我更倾向于WP:权限申请#解任全段搬运。Sanmosa 新朝雅政 2025年5月24日 (六) 16:15 (UTC)回复
如果您有读过方针,就应该知道其他的句子都已经存在于解除权限方针。--Xiplus#Talk 2025年5月25日 (日) 12:04 (UTC)回复
无论如何,这事能办就是了。Sanmosa 新朝雅政 2025年5月26日 (一) 02:23 (UTC)回复
如果您不熟悉的话,那我直接反对这个提案,该方针没有任何严重问题需要修正,不用浪费大家时间讨论。--Xiplus#Talk 2025年5月30日 (五) 04:47 (UTC)回复
公示5月8日的提案5月18日的提案5月24日的提案7日。Sanmosa 新朝雅政 2025年6月9日 (一) 02:14 (UTC)回复
上面有点乱,请确定公示提案均未有明确反对?另请重新整理提案内容,感谢。—— Eric Liu 創造は生命(留言留名学生会 2025年6月9日 (一) 05:51 (UTC)回复
具体的公示内容如下:
  1. WP:权限申请废除方针地位,移除“简介”与“要求”的全部内容,并更名为“WP:申请权限”,所有子页面同。
  2. WP:申请解除权限引述现WP:解除权限方针的部分代之以现WP:权限申请“解任”的内容(下条所述的部分例外),并将其中指向WP:申请解除权限的内部链接替换为“本页”。
  3. WP:权限申请“解任”中“如机器人账户同时持有AWB使用权及机器人权限,不受此限并应该依据机器人方针活跃度要求,AWB使用权与机器人权限同步移除。”一句移至WP:解除权限
  4. 修改下列页面中有关权限申请位置的规定的文字描述:
以上。整个讨论串没有任何(明确的)反对意见,Xiplus说的“如果您不熟悉的话,那我直接反对这个提案”的前提是我不熟悉相关事宜,然而这个前提并不成立。@Ericliu1912Sanmosa 新朝雅政 2025年6月9日 (一) 13:47 (UTC)回复
@Xiplus看法如何?另外他的反对并非无理,因为你针对“如果您有读过方针”这句话的回复,不过是绕过他的质疑而已。—— Eric Liu 創造は生命(留言留名学生会 2025年6月9日 (一) 16:04 (UTC)回复
我倾向于这只是微小的沟通问题,而不是真的有意反对。Sanmosa 新朝雅政 2025年6月10日 (二) 00:44 (UTC)回复
我想那是因为你此前不甚庄重的态度所导致。在我来看,上面迳为宣告没有反对意见的态度,也与之差异无多。真的只是“微小的沟通问题”吗?—— Eric Liu 創造は生命(留言留名学生会 2025年6月10日 (二) 09:56 (UTC)回复
这也不是赌气的理由,赌气对于社群协作并无任何帮助。Sanmosa 新朝雅政 2025年6月10日 (二) 14:09 (UTC)回复
一堆显而易见的问题都是我提的,修订方针品质这么糟糕,怎么让人支持。--Xiplus#Talk 2025年6月10日 (二) 14:42 (UTC)回复
很不幸地,我相信我当时对于你说的话的具体含义出现了理解上的偏差。已停止公示程序。Sanmosa 新朝雅政 2025年6月10日 (二) 15:02 (UTC)回复
(-)反对,废除方针部分没有完整的配套方案,Wikipedia:AutoWikiBrowserWikipedia:巡查豁免权不是方针指引,废除方针将导致相关资格要求被免除。--Xiplus#Talk 2025年6月10日 (二) 14:40 (UTC)回复
干脆只拆页面,不调整文字,这样也不用一个字一个字读方针。--Xiplus#Talk 2025年6月10日 (二) 14:45 (UTC)回复
@XiplusWP:巡查豁免权的情况比较特别,它本身是作为信息页({{Information page}})存在的,而根据WP:COVID-19条目共识的前例,如果一个信息页根据共识被认定为规则,那该页面的效力会与方针、指引相当,成为既非方针又非指引的正式规则,因此我不认为废除方针会导致巡查豁免权的资格要求会被废除。我的建议是WP:AutoWikiBrowser也同样列为信息页,这样就能避免WP:权限申请废除方针地位后AWB权的资格要求被废除的问题。Sanmosa 新朝雅政 2025年6月10日 (二) 15:07 (UTC)回复
“效力会与方针、指引相当”直接就错了,Wikipedia:方针与指引已指出方针和指引的效力差距,我同意信息页可能有共识、是规则,但效力也会比较低。--Xiplus#Talk 2025年6月10日 (二) 15:31 (UTC)回复
WP:权限申请对于巡查豁免者有最近一年内没有受到封禁的要求,(现在)这是方针层级的,这与“建议门槛为创建75个有效条目”的强制力上有差距。--Xiplus#Talk 2025年6月10日 (二) 15:43 (UTC)回复
@Xiplus那我感觉我上面提到的事情就很有必要连带执行了,把所有现非方针的相关页面列为方针即可。Sanmosa 新朝雅政 2025年6月11日 (三) 05:35 (UTC)回复
您可以对AWB或巡查豁免个别提案,再回来推进此案,新设立方针指引事关重大,不适合一起推动。AWB现在包含不少可能不需要立为方针指引内容,需要详细规划。--Xiplus#Talk 2025年6月11日 (三) 13:53 (UTC)回复
WP:AutoWikiBrowser#注册与申请权限列为章节方针即可,“需要详细规划”也未免说得太夸张了。Sanmosa 新朝雅政 2025年6月12日 (四) 00:44 (UTC)回复
您有确认该章节全部都适合作为方针?没有不合时宜的规则?--Xiplus#Talk 2025年6月12日 (四) 11:36 (UTC)回复
@Xiplus那容我确认一下,该章节第五个自然段的内容是否至今仍然适用?经查,其余四个自然段的内容并无不合时宜与不对应现WP:权限申请的描述之处。Sanmosa 新朝雅政 2025年6月12日 (四) 14:47 (UTC)回复
第一段“由于安全原因,仅限于注册用户申请”到底怎么来的,在有编辑次数作为资格限制下,这句话显得冗余。第三段有任何方针而生的效力?像是不允许短期且量少的申请?若没有要强制要求的话,似乎不需要列为方针。第四段好像是机器人方针的范畴,不专属于AWB的。第五段的审核任务是否应该改成强制要求?--Xiplus#Talk 2025年6月12日 (四) 15:47 (UTC)回复
@Xiplus第一段的历史背景我不清楚,但考虑到现时临时账户机制的存在,这句话在现在的情况下仍然是有意义的,毕竟一个临时账户能维持90日,理论上还是能达到相关编辑次数的要求的。第三段在我看来属于建议性质,至少能让一开始打算申请权限的人三思是否真的有需要申请权限。第四段我怀疑是因为之前出过没bot权限AWB批次添加评级模板的job引发争议的缘故,在AWB页面提醒一下还是好的。同意第五段的审核任务应改为强制要求。Sanmosa 新朝雅政 2025年6月14日 (六) 15:05 (UTC)回复
技术上AWB能授权给临时账户?--Xiplus#Talk 2025年6月14日 (六) 15:31 (UTC)回复
@Xiplus不清楚,但可以肯定的是不能排除临时账户(的持有者)真有这种想法,留住第一段好歹能避免一个潜在的问题。Sanmosa 新朝雅政 2025年6月15日 (日) 23:36 (UTC)回复
其他权限不也是有一样的问题,那是不是应该保留权限申请方针,针对一些通用的定义进行规范?--Xiplus#Talk 2025年6月16日 (一) 12:29 (UTC)回复
@Xiplus巡查员、巡查豁免者与文件移动员可以引入同样的要求。其他权限中,有参与日数要求的,参与日数要求为至少90日以上,没有参与日数要求的,临时账户没有任何申请相关权限的合理理由。Sanmosa 新朝雅政 2025年6月17日 (二) 00:27 (UTC)回复
临时用户不会有用户组。 Stang1314 2025年6月17日 (二) 02:44 (UTC)回复
如Stang所说,如果技术上就是无法授权,那就不需要另订规则。--Xiplus#Talk 2025年6月17日 (二) 13:31 (UTC)回复
@Xiplus那AWB章节的第一段废除掉就是了。Sanmosa 新朝雅政 2025年6月18日 (三) 07:31 (UTC)回复
第三段不反对保留。--Xiplus#Talk 2025年6月19日 (四) 14:20 (UTC)回复
第四段应搬移至Wikipedia:机器人方针#对特定工作项目的额外限制。--Xiplus#Talk 2025年6月19日 (四) 14:20 (UTC)回复
@Xiplus不反对。最近较忙,我会在这几日内整理总体方案。Sanmosa 宫掖事秘莫能辨也 2025年6月23日 (一) 04:55 (UTC)回复
经整合的具体提案如下:
  1. WP:权限申请废除方针地位,移除“简介”与“要求”的全部内容,并更名为“WP:申请权限”,所有子页面同。
  2. WP:申请解除权限引述现WP:解除权限方针的部分代之以现WP:权限申请“解任”的内容(下条所述的部分例外),并将其中指向WP:申请解除权限的内部链接替换为“本页”。
  3. WP:权限申请“解任”中“如机器人账户同时持有AWB使用权及机器人权限,不受此限并应该依据机器人方针活跃度要求,AWB使用权与机器人权限同步移除。”一句移至WP:解除权限
  4. 修改下列页面中有关权限申请位置的规定的文字描述:
以上。Sanmosa 宫掖事秘莫能辨也 2025年6月27日 (五) 00:07 (UTC)回复
@Sanmosa:巡查豁免订为方针要不要在Wikipedia:互助客栈/方针#重提允许巡查员自我增加与移除自动巡查权/将自动巡查与巡查员权限组分离提出?--Xiplus#Talk 2025年6月30日 (一) 13:32 (UTC)回复
@Xiplus可。Sanmosa 宫掖事秘莫能辨也 2025年7月1日 (二) 03:23 (UTC)回复
@Xiplus考虑到下方讨论串的状况,WP:巡查豁免权立为方针的事情似乎不太好拆到那边处理。Sanmosa 宫掖事秘莫能辨也 2025年7月4日 (五) 09:19 (UTC)回复
提议条文

Wikipedia:AutoWikiBrowser#注册与申请权限订为章节方针:

欲于中文维基百科上使用此软件,须于申请页面申请自动维基浏览器使用权限。

申请者须达到基本资格:主命名空间非自动编辑250次以上或主命名空间编辑500次以上,自首次编辑以来参与维基百科30日以上,且最近一年内没有受到封禁(不合理封禁除外)。申请者须了解自动维基浏览器的用途和使用方法,在申请时阐明申请原因、使用计划及任务预定之编辑频率,管理员若在审核过程中有疑问,可邀请机器人审核小组成员发表意见。若您预计可能进行大量自动编辑,建议充分了解机器人方针,并申请机器人权限;管理员有权在申请者申请机器人权限前拒绝其自动维基浏览器使用权限申请。另外,对于已获机器人审核小组批准运作的机器人,可直接予以授权。

若您的申请事项仅为短期且量少的工作,建议先至机器人作业请求页面进行请求,或求助已有自动维基浏览器使用权限者协助完成。

Wikipedia:机器人方针#对特定工作项目的额外限制新增章节: 添加评级模板 批量在条目讨论页中添加评级模板须申请以下权限择一:

  1. 机器人权限。
  2. 机器用户巡查豁免权
@Sanmosa看看有无问题。--Xiplus#Talk 2025年6月27日 (五) 12:47 (UTC)回复
@Xiplus可。Sanmosa 宫掖事秘莫能辨也 2025年6月27日 (五) 12:58 (UTC)回复
若您预计可能进行大量自动编辑,建议充分了解机器人方针,并申请机器人权限 -> “申请者如预计可能进行大量自动编辑,应循机器人方针规定同时申请机器人权限”,原语句似乎没有明确是“管理员要建议申请者充分了解...”还是“申请者被建议充分了解...”,存在一定歧义。--Hamish T 2025年7月2日 (三) 00:25 (UTC)回复
不反对此调整。Sanmosa 宫掖事秘莫能辨也 2025年7月2日 (三) 23:57 (UTC)回复
@Sanmosa 七天内没有异议,请问现在能公示了吗?Пусть от победык победе ведёт! 2025年7月11日 (五) 09:13 (UTC)回复

重提允许巡查员自我增加与移除自动巡查权/将自动巡查与巡查员权限组分离

[编辑]

已通过:
通过
下列讨论已经关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。

由于我看到上面有这方面的讨论需求,所以我单独拉出来讨论提高效率也较易于分别社群共识。

过往讨论参见Wikipedia_talk:新页面巡查/存档3#提案四Wikipedia_talk:新页面巡查/存档3#使巡查员可以移除或增加自己的巡查豁免者权限

另外我对于提案是没有什么特别的意见,请不要因为我单独拉出讨论而视为我支持这个提案,谢谢。~~Sid~~ 2025年5月7日 (三) 14:30 (UTC)回复

@ASid如果是这样的话,倒不如把讨论拆得更完整些,两个提案各自一个小标题。Sanmosa 新朝雅政 2025年5月12日 (一) 07:44 (UTC)回复
OK的,不过现在没什么人要参予讨论,看起来又要凉了。:(--~~Sid~~ 2025年5月16日 (五) 01:32 (UTC)回复
edit.~~Sid~~ 2025年5月16日 (五) 01:33 (UTC)回复
@SunAfterRainYFdyh000Python6345Kurgenera自由雨日鐵路1August.CShizhaoAqurs1Znppo花开夜Hi here!很抱歉打扰各位了,鉴于讨论冷掉,故我把各位ping过来,
先不说提高巡查员标准的事情,为什么我说不用特地讨论标准的问题,因为“将自动巡查与巡查员权限组分离”已经一定程度上降低巡查员的标准,所以我才会说不用太过在意标准的部分。“允许巡查员自我增加与移除自动巡查权”,则是牵扯到自制力的部分,至于如果有人担心滥用自我授权自动巡查的问题,则以巡查员权限组将报告提到WP:RFDR即可(这部分可以在方针修订特别注明),再麻烦各位多加参予讨论了,谢谢。:)
Sanmosa我就不特别ping了。--~~Sid~~ 2025年5月16日 (五) 01:53 (UTC)回复
静等具体提案。--__Don't bite! 2025年5月16日 (五) 02:04 (UTC)回复
我觉得就算把自动巡查拆掉,巡查员依旧要拉高一些标准,毕竟没有帽子其实也能巡查条目(只是没办法用巡查员的那几个功能而已),并且要巡查条目也要基本理解怎么读条目,我不觉得要求应该比回退员低。--SunAfterRain 2025年5月16日 (五) 11:33 (UTC)回复
(-)倾向反对:提高硬门槛会让一定巡查经验者被迫再次检查被标记为已巡查之条目,虽必要时可IAR但可能引不必要之争议。如允许非巡查员使用隐藏已巡查的条目则对此(=)中立。Python6345(2025年5月16日 (五) 11:58 (UTC)回复
拔掉之后管理员授予巡查员时就不太需要考虑巡查豁免权的问题,尽管巡查员可以自我授权,但社群仍然可以监察,如果该巡查员让社群觉得他需要被巡查,那他就不该自我授权,如果自我授权就应该提报到WP:RFDR让社群讨论拔掉巡查员权限组的事情。额外一提但管理员与社群在考虑人选时就要特别评估该人过往的行为是否让人信任他自己的自制力,不过我觉得社群平时就会考虑这点,所以没什么好担心的。--~~Sid~~ 2025年5月17日 (六) 12:32 (UTC)回复
我依然认为由巡查员自行决定是否拥有巡免权是极其无理的,对单独取得巡免权者也非常不公。要拆就完全拆分,两权不再有任何相关。唯有一点我当时想了一阵也认为可以退让,即让巡查员可以巡查自己的条目,这样可以明确巡查动作与职权相符,避免某些因为他可以巡查其他条目所以他也一定可以保证自己条目质量的逻辑死亡。->>Vocal&Guitar->>留言 2025年5月18日 (日) 02:58 (UTC)回复
这也可行。—— Eric Liu 創造は生命(留言留名学生会 2025年5月18日 (日) 06:42 (UTC)回复
有条件支持:需可在Special:最近更改中排除巡查员之编辑。Python6345(2025年5月18日 (日) 07:40 (UTC)回复
这个页里任何人的编辑都会列在其中,你是要排除什么?--。->>Vocal&Guitar->>留言 2025年5月19日 (一) 07:21 (UTC)回复
一般可使用未巡查变更排除巡免和巡查之编辑。如拆巡查之巡免权且不允许自我授权,则本人需有办法在最近更改中排除巡查员之编辑以避免重复检查可能不需要复核之编辑。( π )题外话本人对回退员之编辑无法单独排除亦不满,但技术上无法排除故未提案。Python6345(2025年5月19日 (一) 07:47 (UTC)回复
我理解了,技术问题恕我我无能为力。--。->>Vocal&Guitar->>留言 2025年5月19日 (一) 23:46 (UTC)回复
有条件支持,意见同U:Python6345,希望技术问题早日解决。——南屿小十233对话 | 贡献 | 签名2025年6月2日 (一) 04:57 (UTC)回复
要这么做当然可以,但我只能说你们看要不要也讨论一下顺便也把管理员的自动巡查一并拆掉,原因是对于巡查员有自动巡查,本就是基于巡查员理应能处理好自己创建条目的信任,现在这种信任要单独拉出来讨论当然可以,管理员也理应如此,因为不是所有管理员都会写条目,我过往也不是没看过管理员写的东西,需要做一步处理。至于无理的部分我只能说这是对现有巡查员极度的不信任,对单独取得巡查豁免权的人不公的部分,如果这样的话我认为社群早该把巡查员权限组的自动巡查拆掉,而不是拖到现在,所以这里我不是很明白不公在哪,巡查员相对于巡查豁免权本就是比较好申请的,这我不否认,然而在怎么样都不该说这是不公,如果不公的话那社群早该拆解巡查员权限组。:(
额外一提,要这样做的话请自己说服表示这会大幅度增加巡查员负担的意见。:)
有人说管理员拆掉自动巡查,那自动巡查要谁授予,那当然还是管理员可以自我授权,同样的管理员滥用自我授权,那这种就应视为滥用权限,该除权,不过我知道社群没那个时间与精力以这种理由除管理员权就是。:(--~~Sid~~ 2025年5月18日 (日) 13:53 (UTC)回复
有些常年提案在若干年后也会有通过的一天,我不认为社群过往的决定能说明什么问题,相反反映出社群对巡查问题、对条目质量问题一贯的漠视。
经常创建新条目的巡查员自然已经达到巡查豁免者门槛,那么他们当然可以直接申请巡免权,不存在大幅增加巡查员负担的问题。
另外关于管理员,Stang已经提过相同意见,我完全同意。--。->>Vocal&Guitar->>留言 2025年5月18日 (日) 23:30 (UTC)回复
即便如此我仍认为“单独取得巡查豁免权的人不公”这里不该说不公,这个说法相当的不好至少我来说。此外你的想法我没意见,然而基于过往的讨论,我看到大家最可以接受的方式,仍然是这个,这次的讨论以目前来看也没什么人反对这个变革方式,我还是建议你可以考虑接受这个变革,起码有在改变,而不是僵持不下导致原地踏步。我不是要改变你的想法什么的,你可以继续坚持您的想法,但起码让情况有所转变,如果未来社群或您发现很多巡查员滥用自我授权,您再将情况提出来要求移除也不迟不是么。:)
管理员权限拆解的部分,我认为可能要再等等,因为过往的讨论针对这部分没有很多,应该没办法一并处理,社群对此可能会有很多地方需要磨合,我建议先处理巡查员权限组的部分。:)--~~Sid~~ 2025年5月19日 (一) 01:09 (UTC)回复
句句没意见,句句在反对,大可以直接一点反对就行了,我的案也不缺你一票反对。这个案过不过对我一点影响都没有,甚至我也是巡查员我的权限还会变少,我倒是很希望反对我案的巡查员一起来对赌,只要我案通过,大家一起永久辞任巡查员,看看到底是谁舍不得这顶帽子。
上一句还在说管理员也理应如此下一句就变成认为可能要再等等,变脸变这么快不怕自己信用破产吗?--。->>Vocal&Guitar->>留言 2025年5月19日 (一) 07:21 (UTC)回复
?--~~Sid~~ 2025年5月19日 (一) 08:24 (UTC)回复
我会说要再等等是因为这件事情不是我一个人说得算,社群过往也没有讨论,我没有任何基础推动。
我会说理应如此,这是基于我的观察而得出想法。
我建议你试着接受,是因为社群目前并整体上并不怎么接受你的意见。
我没意见也确实是真的,我不知道我话讲这么白,原因也说明白,还要被你冠上一句信用破产,你要跟别人对着干,对着骂我没意见,请不要坡及我。--~~Sid~~ 2025年5月19日 (一) 08:32 (UTC)回复
另外我也不知道你这是要赌什么,这有什么好赌的,不是很明白你的逻辑。--~~Sid~~ 2025年5月19日 (一) 08:36 (UTC)回复
我也再次澄清
Wikipedia:互助客栈/方针#c-ASid-20250519010900-Ohtashinichiro-20250518233000这里我有说到“基于过往的讨论,我看到大家最可以接受的方式,仍然是这个,这次的讨论以目前来看也没什么人反对这个变革方式,我还是建议你可以考虑接受这个变革,起码有在改变,而不是僵持不下导致原地踏步。我不是要改变你的想法什么的,你可以继续坚持您的想法,但起码让情况有所转变,如果未来社群或您发现很多巡查员滥用自我授权,您再将情况提出来要求移除也不迟不是么。”
我是要说服你暂时接受,让变革有所推动而不是在原地踏步,这是基于社群的讨论,而不是我的意见,你要坚持照着你的想法变革你可以说,用一副咄咄逼人的样子在对话,那你请自便。--~~Sid~~ 2025年5月19日 (一) 08:49 (UTC)回复
要这么做当然可以也是你说的,说服你暂时接受也是你说的,从我的角度我只看到你在变来变去,而没有对提案的实质意见。你如果真的没有意见,为什么反复搬出社群(还是两年前的),要建议我说服我接受呢?这一次的讨论里连你在内只有三个人回复了我,你为什么就判定现在的社群不接受我的意见呢?你有没有研究过我上一次为什么故意提一个很奇怪被社群全面反对的方案??为什么你的案就是变革有所推动,那如果你来支持我的案不就是变革大大地推动吗?--。->>Vocal&Guitar->>留言 2025年5月19日 (一) 23:44 (UTC)回复
我已经跟你说明过我对你的意见是真的没意见,社群即便执行你的方案,我也不会有意见也更加不会反对,这对我也没什么影响,也跟你说明过我不是要强行改变你的看法,所以你请自便吧。:)
如果需要帮你另开一个章节来讨论你的方案,我很乐意协助。此外我相信你对我的部分回应仍有些许疑惑,这里也跟您说声抱歉,我不太想特意解释。:)--~~Sid~~ 2025年5月21日 (三) 11:48 (UTC)回复
我很难想象移除“被认为是社群中有经验的成员”的管理员之自动巡查权限的必要性。如果连管理员权限都要如此阉割,那站内还能有谁符合具备自动巡查权限的要求?——南屿小十233对话 | 贡献 | 签名2025年6月2日 (一) 04:46 (UTC)回复
大致上支持“默认不巡查但可自行选择”的这个方向,有具体方针上的新增再看。--Aqurs 2025年5月19日 (一) 03:24 (UTC)回复

将自动巡查与巡查员权限组分离

[编辑]
“将自动巡查与巡查员权限组分离”已经上面是确定的共识,然而措施的部分仍然有人不同意,所以我开了下面的章节讨论,请注意这个只是确立“将自动巡查与巡查员权限组分离”的共识。 公示7日,2025年6月1日 (日) 13:34 (UTC)结束~~Sid~~ 2025年5月25日 (日) 13:34 (UTC)回复
请各位查看这则澄清留言,谢谢。--~~Sid~~ 2025年5月27日 (二) 13:59 (UTC)回复
这种提案居然能走到公示,真是神奇。唉。 ——魔琴留言 贡献 PJ:小学 PJ:两岸 2025年5月25日 (日) 15:47 (UTC)回复
那我觉得不如一并将“自动巡查”这个操作彻底拆分出来,包括巡查员和管理员都不应该自动获得这个权限。另外我觉得最大的遗憾就是技术上的问题导致PageTriage没法进行部署,不然整个操作都是水到渠成的:“巡查”这一操作只针对主空间的条目,可以反复对一个条目进行“巡查”(也就是标记可以逆操作),再加上配套的ui和脚本;“自动巡查”这个操作也只针对主空间新建的页面这个行为,也不会给巡查员带来很大的负担。 Stang1334 2025年5月27日 (二) 06:58 (UTC)回复
这部分没什么人去讨论到,现况无法处理,强硬公示会被说没有共识为何可以公示,您有空的时候可以推一推社群讨论。🫠--~~Sid~~ 2025年5月28日 (三) 05:50 (UTC)回复
可以,我就是顺口一说,公示的内容还是只针对巡查员的。另外再顺嘴一说,一些全域权限(比如全域回退员)附带的自动巡查功能实际上也是应该被去除的,只是做起来比较麻烦。这两个地方可以在未来如果需要的时候作为参考。@ASid Stang1333 2025年5月28日 (三) 05:55 (UTC)回复
我很难想象移除“被认为是社群中有经验的成员”的管理员之自动巡查权限的必要性。如果连管理员权限都要如此阉割,那站内还能有谁符合具备自动巡查权限的要求?——南屿小十233对话 | 贡献 | 签名2025年6月2日 (一) 04:59 (UTC)回复
公示通过WiiUf留言2025年5月31日 (六) 16:35 (UTC)回复
@WiiUfbro是不是忘了5月有31天 Stang1330 2025年6月1日 (日) 04:53 (UTC)回复
啊啊啊,抱歉--WiiUf留言2025年6月1日 (日) 10:00 (UTC)回复
@WiiUf公示期现在是否已完结?Sanmosa 新朝雅政 2025年6月4日 (三) 04:03 (UTC)回复
已经过几天了。- - 宇帆-娜娜奇🐰鲜果茶☕在维基百寻求休闲是否搞错了什么☎️·☘️2025年6月4日 (三) 04:08 (UTC)回复
是的呀。-- WiiUf🐉🕯️ 2025年6月4日 (三) 04:34 (UTC)回复

本讨论已关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。

提案“删除巡查员附带的巡查豁免权”已通过,下方段落将讨论具体如何执行,以及相关配套设施事项。 Stang1326 2025年6月4日 (三) 12:02 (UTC)回复

@Stang(调整了关闭范围并将公示章节降为四级章节)--SunAfterRain 2025年6月4日 (三) 12:07 (UTC)回复
Special:固定链接/87784727#提议提升巡查员的门槛起拆分为独立章节。--Steven Sun留言2025年6月16日 (一) 10:36 (UTC)回复

配套措施

[编辑]

讨论区

[编辑]
这里是讨论拔除后的配套措施,鉴于上面讨论的情况,我不想要来干涉这里的讨论了,即便我是没意见的,所以请各位自便。~~Sid~~ 2025年5月25日 (日) 13:34 (UTC)回复
请注意,本人同意两权分立的前提是允许巡查员保有巡查自己条目的权力,否则本人不会支持修订有关政策。—— Eric Liu 創造は生命(留言留名学生会 2025年5月25日 (日) 14:15 (UTC)回复
另外,我需要提出,原因取得巡查权限而合并巡查豁免权限者,届时均应自动重新授予之。—— Eric Liu 創造は生命(留言留名学生会 2025年5月26日 (一) 08:50 (UTC)回复
我开出了第一炮Wikipedia:权限申请/申请巡查豁免权#User:A2569875。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百寻求休闲是否搞错了什么☎️·☘️2025年5月27日 (二) 03:15 (UTC)回复
为什么巡查员要保有巡查自己条目的权力?本站上除非明显破坏,管理员可以删除自己添加快速删除模板的页面吗? Stang1334 2025年5月27日 (二) 07:00 (UTC)回复
原本是巡查豁免者,后来变成巡查员的巡查员本来就应该要保有巡查自己条目的权力。不然申请成为巡查员成为了处罚???? 处罚禁止继续巡查豁免者???????? 这样我申请巡查员我岂不是笨蛋???? 申请了个处罚???? 处罚自己???? 我申请巡查员时你哪只眼睛看到我申请“巡查豁免者除权”??? 你没事除我权理由是??? 很遗憾我只能理解为处罚。 @Stang另见我在Wikipedia:权限申请/申请巡查豁免权#User:A2569875的发言。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百寻求休闲是否搞错了什么☎️·☘️2025年5月28日 (三) 06:14 (UTC)回复
如果你曾经是巡查豁免者,在权限相关的配置更新之后就会被重新授予巡查豁免的权限,这个你无需担心。@A2569875 Stang1333 2025年5月28日 (三) 07:34 (UTC)回复
我问的这个问题好像没人讨论啊…如下措施实施后,巡查员是否可以标记自己的条目为已巡查?如果不能,看起来好像没法使用过滤器来自动阻止,只能人工的来发现 Stang1310 2025年6月20日 (五) 10:01 (UTC)回复
个人认为删除权限和标记巡查权限还是不太一样的:删除操作易引发争议,且删除后的内容对普通用户不可见,不易于复查,因此删除操作需要两名用户完成。而巡查操作争议较少,且易于复查,因此由一个用户完成(即巡查自己创建的条目)不会有太大的风险。--Steven Sun留言2025年6月20日 (五) 12:24 (UTC)回复

提案区

[编辑]
Python6345提案之一
[编辑]
  • 技术上移除巡查员之自动巡查权。
  • 允许巡查员自我授权或申请巡查豁免权。
  • 自我授权滥用时应同时除巡查权,申请权限滥用时仅除巡免权。

如拟议二无法实现则本人支持该方案。Python6345(2025年5月28日 (三) 07:09 (UTC)回复

“允许巡查员自我授权”意义何在? Stang1333 2025年5月28日 (三) 07:37 (UTC)回复
该疑虑,本人认为自我授权时可默认巡查员为自身条目摁下巡查按钮,此时除权也应对比滥用巡查权。Python6345(2025年5月28日 (三) 09:45 (UTC)回复
有条件支持,但同时也希望技术问题早日得到解决,避免站务巡察工作积压。——南屿小十233对话 | 贡献 | 签名2025年6月2日 (一) 05:01 (UTC)回复
抱歉,但我看不出这样分离的意义在哪里,只能(-)反对--SunAfterRain 2025年6月4日 (三) 12:11 (UTC)回复
Python6345提案之二
[编辑]
补丁已部署,提交了一批批量恢复权限请求。相关页面的描述将同步进行更新。 Stang1300 2025年6月30日 (一) 07:57 (UTC)回复
下列讨论已经关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。

  • 技术上禁止巡查员创建操作自动标记为已巡查。
  • 出于尊重,为现有巡查员授巡查豁免权。

本人希望之方案。Python6345(2025年5月28日 (三) 07:09 (UTC)回复

这是不可能的,目前自动巡查不区分这个。如果要在技术上支持这个功能,一个方法是Xiplus的一个分割创建/修改巡查的patch,但是code review方面已经很久没动静了;另一方面是引入PageTriage这个扩展,但是这个目前进度非常缓慢。另外“出于尊重,为现有巡查员授巡查豁免权”的意义何在,如果都授予了还分割什么权限啊。 Stang1333 2025年5月28日 (三) 07:41 (UTC)回复
参阅本人附加提案,可能有部分巡查员曾有巡免或条目已符合巡免标准。Python6345(2025年5月28日 (三) 09:42 (UTC)回复
不是“可能”,是活生生在你面前。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百寻求休闲是否搞错了什么☎️·☘️2025年5月28日 (三) 09:51 (UTC)回复
如果要在技术上支持这个功能,一个方法是Xiplus的一个分割创建/修改巡查的patch,但是code review方面已经很久没动静了;另一方面是引入PageTriage这个扩展,但是这个目前进度非常缓慢本提案为理想提案,如技术上无法实现本人无能为力,请参阅替代提案。Python6345(2025年5月28日 (三) 09:49 (UTC)回复
显然,原本已持有豁免权限(然后因并入而取消)的巡查员,在权限分割当下仍持有巡查权者,均应返还巡查豁免权。因为权限分割纯粹是技术问题,与往后是否弹劾无涉。—— Eric Liu 創造は生命(留言留名学生会 2025年6月5日 (四) 13:11 (UTC)回复
注:此处原有文字,因为本人眼瞎,已由Ohtashinichiro留言)于2025年6月5日 (四) 13:33 (UTC)删除,尚祈见谅。若有异议请至互助客栈或向管理员反映。回复
你确定吗?-- 宇帆-娜娜奇🐰鲜果茶☕在维基百寻求休闲是否搞错了什么☎️·☘️2025年6月5日 (四) 13:26 (UTC)回复
(!)抗议“不存在返还一说。”我都讲三次了,你们是故意当耳边风的吗?,如果是故意的,ANM见。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百寻求休闲是否搞错了什么☎️·☘️2025年6月5日 (四) 13:29 (UTC)回复
是我眼瞎,我收回言论,诚恳致歉。->>Vocal&Guitar->>留言 2025年6月5日 (四) 13:33 (UTC)回复
上方讨论已指出多名巡查员之条目不符合巡免质量,且涉有曾持巡免权者。故本人认为应集中讨论重审所有曾有巡免权之巡查员是否能于拆权后重获巡免权。Python6345(2025年6月5日 (四) 13:29 (UTC)回复
注:此处原有文字,因为误会,已由宇帆-娜娜奇🐰鲜果茶☕在维基百寻求休闲是否搞错了什么☎️·☘️)于2025年6月5日 (四) 14:02 (UTC)删除,尚祈见谅。若有异议请至互助客栈或向管理员反映。回复
误看成同一人留言。且我已经重新申请权限,“理论上”应该可能大概也许不会影响。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百寻求休闲是否搞错了什么☎️·☘️2025年6月5日 (四) 14:02 (UTC)回复
若有人不合格,请届时个别提出。请注意,原本拿过巡查豁免者,都是经过社群审核通过。我们这里应当专注处理技术问题,若认为达不到标准要除权,就应该重走程序,不是借此机会“一刀切”。除非默认烂人过半,否则此事免谈。—— Eric Liu 創造は生命(留言留名学生会 2025年6月6日 (五) 03:49 (UTC)回复
请@Sanmosa前来说明。Python6345(2025年6月6日 (五) 04:00 (UTC)回复
问题在于巡查员就从来没被特地检验过写条目的能力,Ericliu1912的言论基本上就是在令整件事情变得完全无法检验,他的reluctance没有把授权应有的谨慎当一回事。“巡查员从来没被特地检验过写条目的能力”是社群的共业,因此其成本必定要由社群整体负担,但看起来Ericliu1912似乎非常不愿意这样做。个人较倾向于下方的Python6345提案二之附加。Sanmosa 新朝雅政 2025年6月6日 (五) 07:24 (UTC)回复
现在的问题是,你所假定“曾持有巡查豁免权而后升格之巡查员一般没有写好条目的能力”一事,并没有确凿根据,而且不合常理。你上方的说法,更是混淆普通巡查员及合并巡查豁免权的巡查员;后者申请巡查豁免权限之际,本来就已经过“特地检验”,不存在你所谓“社群共业”问题。请注意,我从来不支持“为现有(全部)巡查员授巡查豁免权”,而仅是希望把原本谁有的权限还回去。随意基于假设剥夺他人权限,才真正缺乏“应有的谨慎”。如果你所说要处理的特别情况,例子举不出来,就不要诉诸情绪勒索;若例子真能举出来了,就去办那些例子。不清楚这有什么好讨论的。甚至我不清楚你我立足点是否相同,搞不好其中误会可大了,根本不是在谈一件事。—— Eric Liu 創造は生命(留言留名学生会 2025年6月10日 (二) 09:58 (UTC)回复
我们这里探讨的不是“自动恢复曾持有巡查豁免权的巡查员相关权限”吗?请问这有任何问题么? Stang1320 2025年6月10日 (二) 11:26 (UTC)回复
我看混了,上面的留言让我以为你们在说的是所有巡查员在权限分拆后自动授予巡查豁免权。Sanmosa 新朝雅政 2025年6月10日 (二) 15:12 (UTC)回复

上方长期讨论可判断“批量恢复曾持有巡查豁免权的巡查员相关权限”已达成共识, 公示7日,2025年6月27日 (五) 09:54 (UTC)结束。具体名单会在统计之后生成。 Stang1310 2025年6月20日 (五) 09:54 (UTC)回复

名单,共26名用户需恢复权限。 Stang1307 2025年6月24日 (二) 03:16 (UTC)回复
移除权限是否需要提前MMS通知相关权限持有者?上文关于“允许巡查员保有巡查自己条目的权力”的讨论尚未有共识。移除权限后是否允许“巡查员保有巡查自己条目的权力”?--Steven Sun留言2025年6月24日 (二) 13:11 (UTC)回复
@Steven Sun会;这样做的话我感觉不合适的地方在于,这样不就相当于什么也没变嘛,设想一个巡查员创建了条目之后点个按钮,和之前的情况也没什么区别啊。 Stang1305 2025年6月25日 (三) 06:39 (UTC)回复

这一公示已通过。等待补丁的部署,管理员可以对上述的用户的权限进行恢复。相关方针将被修改,MMS通知将在补丁执行后发送。 Stang1303 2025年6月27日 (五) 10:00 (UTC)回复

等通知发送再行授予权限吧(当然同步是最理想,不过有些困难?)。—— Eric Liu 創造は生命(留言留名学生会 2025年6月27日 (五) 10:15 (UTC)回复

本讨论已关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。
Python6345提案二之附加
[编辑]

由于确有多名巡查员所创建条目不合格,或可在授巡查豁免权之前全部公示,如公示期有其他巡查员反对则需讨论。Python6345(2025年5月28日 (三) 07:09 (UTC)于2025年6月10日 (二) 10:30 (UTC)撤回,无人可证大量曾有巡免之巡查员滥用巡免权以至于需集中重审,故支持授予所有曾有巡免权之巡查员巡免权。回复

既已移除权限,WP:巡豁信息页需要相应更新。--Zheng Zhou留言2025年6月30日 (一) 06:11 (UTC)回复
RainSun8942提案
[编辑]
  • 取消自己的编辑自动标示为已巡查,但仍可以巡查不具备巡查豁免权限之编辑,仅具备巡查豁免权限方可自动标示为已巡查。
  • 由于巡查豁免门槛较高,巡查门槛较低。除可以申请巡查权外,符合巡查豁免申请资格也可申请巡查豁免权限。
以上不知第一项技术上是否可行,另外管理员是否也需要比照办理。--雨朝Talk#SamekoSaba🐟 2025年6月5日 (四) 05:09 (UTC)回复
1不可行,标记为已巡查是不可逆的操作。2完全可以。管理员是否比照我觉得一步步来比较好,先把巡查员的情况处理好。 Stang1325 2025年6月5日 (四) 08:27 (UTC)回复
您看起来好像搞错了,我是指将自己的编辑取消自动标记为已巡查,而不是将已巡查逆转为未巡查的状态。--雨朝Talk#SamekoSaba🐟 2025年6月5日 (四) 09:22 (UTC)回复
原来如此,我理解错了。你的1所表述的就是上方共识事实上的效果:巡查员自己的编辑不再被自动标记为已巡查,他们仍然可以巡查其他无巡查豁免权的用户的编辑。 Stang1325 2025年6月5日 (四) 09:32 (UTC)回复
是的,仅取消巡查员自己的编辑自动标记为已巡查,此外1有提到自我巡查的部分,是否可以将等候巡查的按钮隐藏?--雨朝Talk#SamekoSaba🐟 2025年6月5日 (四) 10:21 (UTC)回复
@RainSun8942“等候巡查”的按钮是在哪里的,可以描述一下吗?咱因为不是巡查员看不到。猜测隐藏起来不难,来点css魔法就行了。 Stang1322 2025年6月9日 (一) 01:04 (UTC)回复
降低巡查豁免申请要求
[编辑]

创建75个条目的要求没查到当年相关讨论记录,大概是借用enwiki的标准。而enwiki早已将此标准降为25个条目。个人认为至少要将标准降低到50以下,最好是25-35之间。--Steven Sun留言2025年6月6日 (五) 03:23 (UTC)回复

(!)意见:本人认为硬标准可降至创建10个条目,但需要他人提名或最少一名延确支持后管理员可赋权。Python6345(2025年6月6日 (五) 03:52 (UTC)回复
不确定延确水平。前提定在两名有巡查权限者(净)支持如何?毕竟巡查豁免主要影响巡查员的工作。--YFdyh000留言2025年6月6日 (五) 05:19 (UTC)回复
(+)支持将前提定为需巡查员同意,但(-)反对投票。Python6345(2025年6月6日 (五) 06:04 (UTC)回复
考虑到特定申请可能有人反对,而明确的授权与反对标准较容易审视,即通过反对票来延缓授权进程。我也赞成可以宽松裁量是否授权,暂未考虑投票期限等约束。--YFdyh000留言2025年6月6日 (五) 06:42 (UTC)回复
反对者阐明理由,支持者反驳,如遇长期讨论而管理员无法判断共识之情况可考虑由行政员集体决定。本人不希望RFR和RFA一样成为选举。Python6345(2025年6月6日 (五) 06:51 (UTC)回复
引入DYK/GA/FA的写作数量作为可选条件也可以。比如可将10篇DYK或2篇GA/FA作为参考条件。--Steven Sun留言2025年6月6日 (五) 04:24 (UTC)回复
(+)支持引入,但(-)倾向反对上述写作数量,个人认为10篇DYK过少。--__Don't bite! 2025年6月14日 (六) 11:55 (UTC)回复
条目质量须被巡查员认可提案
[编辑]
现行条文

任何管理员均可将此权限授予熟知维基方针及指引(特别是生者传记收录标准)的可信赖用户。建议门槛为创建75个有效条目如您打算为您自己或其他用户申请此权,请移步至维基百科:权限申请/申请巡查豁免权

提议条文

任何管理员均可将此权限授予熟知维基方针及指引(特别是生者传记收录标准)的可信赖用户。建议门槛为创建10个有效条目,且条目质量被巡查员认可。如您打算为您自己或其他用户申请此权,请移步至维基百科:权限申请/申请巡查豁免权

本人认为巡免权主要需条目平均质量可通过巡查,且10个条目之建议已足够低,故提案未包含DYK/GA/FA之建议标准,如有例外请IAR处理。多日无人留言,如7日内无异议将公示。Python6345(2025年6月10日 (二) 10:47 (UTC)回复

10个条目未免真的太低,但我认同现有门槛确实过高,因此我较为倾向于enwiki的门槛(25个条目),这样可以确保巡免写的条目足够多,又避免为有意申请巡免者造成不必要的负担。Sanmosa 新朝雅政 2025年6月10日 (二) 15:16 (UTC)回复
保留DYK,又或者做7篇GA如何?--Mykola留言2025年6月14日 (六) 17:49 (UTC)回复
不认可将DYK/GA/FA纳入巡免申请要求,现时条目经少量改善并挂模板后即可通过巡查,无理由要求巡免之条目质量高于可通过巡查之基本标准。Python6345(2025年6月15日 (日) 09:26 (UTC)回复
不需要“经过巡查员认可”,重点是条目品质足够,这也就是“有效条目”的含义。—— Eric Liu 創造は生命(留言留名学生会 2025年6月10日 (二) 15:34 (UTC)回复
(:)回应:是否条目品质足够需用户判断,本人倾向由延确判断,但有人质疑延确判断能力且巡免确主要影响巡查员之工作。故在此拟议巡查员判断,阁下如有更好方案还请提出。Python6345(2025年6月14日 (六) 13:41 (UTC)回复
不必更改现况,由社群判断即可。说实话有什么权限也不影响能不能读条目吧?—— Eric Liu 創造は生命(留言留名学生会 2025年6月14日 (六) 17:46 (UTC)回复
理论上不影响,但连DYK都时常可见水票,且阅读一名用户所创之条目判断是否可获巡免耗费精力显高于阅读一篇条目,本人合理担忧出现更多不读条目就(+)支持而多日无人认真读条目提出合理反对意见,导致管理员误授权给质量过差之用户巡免权。本人认为此方案如通过而巡查员不读条目而支持,可以WP:CIR除权;普通用户如可给出合理解释表明认真阅读过条目亦可采纳。Python6345(2025年6月15日 (日) 09:24 (UTC)回复
照理说大部分申请应该会是“提出申请”、“符合基础门槛”、“无人反对”(有人支持的话会更快)、“管理员授权”;我们应该是鼓励社群(无论持有权限)参与第二部分过程,因为管理员也非全能。—— Eric Liu 創造は生命(留言留名学生会 2025年6月15日 (日) 12:14 (UTC)回复
让管理员判定即可,目前也不是由管理员判定并授权吗?--Steven Sun留言2025年6月16日 (一) 03:21 (UTC)回复
(-)强烈反对,10个也太少了吧。像LTA:Kurgenera这样的人申请巡免只会让你维更糟糕,个人认为50个适宜。(折中enwiki和中维)--__Don't bite! 2025年6月14日 (六) 11:49 (UTC)回复
(:)回应:此仅为建议标准,而非到达资格后必须授权。Python6345(2025年6月14日 (六) 13:43 (UTC)回复
认真写的条目,10-25个足以判断用户的写作水平。无需50个。况且这只是建议标准,是否授权仍需要管理员及其他用户综合判定写作水平。--Steven Sun留言2025年6月16日 (一) 03:12 (UTC)回复
简单降低标准提案
[编辑]
通过,将对相关页面进行描述修改。 Stang1300 2025年6月30日 (一) 09:15 (UTC)回复
下列讨论已经关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。

现行条文

任何管理员均可将此权限授予熟知维基方针及指引(特别是生者传记收录标准)的可信赖用户。建议门槛为创建75个有效条目。如您打算为您自己或其他用户申请此权,请移步至维基百科:权限申请/申请巡查豁免权

提议条文

任何管理员均可将此权限授予熟知维基方针及指引(特别是可供查证生者传记收录标准)的可信赖用户。建议门槛为创建或重写50个有效条目(重写的标准可参考Wikipedia:新条目推荐/候选内的说明)。如您打算为您自己或其他用户申请此权,请移步至维基百科:权限申请/申请巡查豁免权

-- Steven Sun留言2025年6月16日 (一) 03:43 (UTC)回复

考虑到上方多个提案已经详细的讨论过具体降低到什么样的门槛,可以视为讨论已经很充分,因此 公示7日,2025年6月27日 (五) 09:47 (UTC)结束 Stang1310 2025年6月20日 (五) 09:47 (UTC)回复
(-)反对,75→25过于宽松,未见有如此大幅下修的必要性。中文维基百科几乎无人在做二次巡查,对于巡免权限仍应慎重。->>Vocal&Guitar->>留言 2025年6月24日 (二) 11:28 (UTC)回复
虽然我不反对这个下调,但我感觉现在不是提这事的时机,这事应该另开讨论串处理。(补可供查证方针链接的事情倒是可以继续,因此公示或许暂时不必撤下。)Sanmosa 宫掖事秘莫能辨也 2025年6月24日 (二) 16:47 (UTC)回复
@Steven SunStangOhtashinichiroSanmosa是否可考虑先改为50篇条目?75篇确实偏多。—— Eric Liu 創造は生命(留言留名学生会 2025年6月27日 (五) 02:56 (UTC)回复
不反对。Sanmosa 宫掖事秘莫能辨也 2025年6月27日 (五) 05:08 (UTC)回复
不反对。--Steven Sun留言2025年6月27日 (五) 06:19 (UTC)回复
另外对现有条目的重写是否也可以计入“创建有效条目”?毕竟这个权限主要是考察条目写作能力,而“重写”与“创建”在能力考察上似乎没有太大区别。--Steven Sun留言2025年6月27日 (五) 06:31 (UTC)回复
很有道理,我觉得是可以这么看的,重写的判定标准可以从DYKC那里抄过来。 Stang1303 2025年6月27日 (五) 06:55 (UTC)回复
可以算,不如说之前不算有点厉害。要不改为“创建或全面重写”?—— Eric Liu 創造は生命(留言留名学生会 2025年6月27日 (五) 09:13 (UTC)回复
可。这样修改了公示的内容是否要重新计算公示期啊。 Stang1303 2025年6月27日 (五) 06:55 (UTC)回复
@Stang现在公示规定很复杂了,我其实看不太懂。如果要追求稳妥,那就再公示七日,要不然可以改成公示三日之类的,吧。总之,先确定条文改动为好。—— Eric Liu 創造は生命(留言留名学生会 2025年6月27日 (五) 09:13 (UTC)回复
@Ericliu1912那就延长3天的公示期吧, 延迟公示3日,2025年6月30日 (一) 09:47 (UTC)结束。对公示的内容进行了修改。刘酱同志如果有精力可以另开提案修改方针公示规定。 Stang1303 2025年6月27日 (五) 09:41 (UTC)回复
2025年6月30日是星期一。--夏冰 2025年6月30日 (一) 06:20 (UTC)回复
然后?@Summerize Stang1300 2025年6月30日 (一) 07:07 (UTC)回复
不好意思,我只是注意到“延迟公示3日”的日期和星期不符想说提醒一下,我不该留言的,抱歉打扰了。--夏冰 2025年6月30日 (一) 07:24 (UTC)回复
@Summerize啊,不好意思我都没注意到这一个地方 :),感谢你的留言,已经进行了修正。 Stang1300 2025年6月30日 (一) 07:37 (UTC)回复

本讨论已关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。
巡查豁免活跃度要求提案
[编辑]
现行条文
提议条文

此外,当超过3年没有任何编辑活动,报告后如查明属实时,则立即除权。

注意到巡查豁免权没有活跃度要求,并考虑到无编辑用户可能会不了解编辑方针与指引的变动,因此提出活跃度要求。--Steven Sun留言2025年6月16日 (一) 03:43 (UTC)回复

多此一举,已经有六个月未有编辑活动的规定。--雨朝Talk#SamekoSaba🐟 2025年6月16日 (一) 12:23 (UTC)回复
了解,那我 撤回请求。--Steven Sun留言2025年6月16日 (一) 12:51 (UTC)回复

综合条目数量与DYK数量提案

[编辑]
现行条文

任何管理员均可将此权限授予熟知维基方针及指引(特别是生者传记收录标准)的可信赖用户。建议门槛为创建75个有效条目。如您打算为您自己或其他用户申请此权,请移步至维基百科:权限申请/申请巡查豁免权

提议条文

任何管理员均可将此权限授予熟知维基方针及指引(特别是可供查证生者传记收录标准)的可信赖用户。建议门槛为创建25个有效条目至少拥有10个新条目推荐(1个典范/优良条目视为3个新条目推荐)。如您打算为您自己或其他用户申请此权,请移步至维基百科:权限申请/申请巡查豁免权

以上综合条目质量及数量。 —WiiUf留言2025年6月26日 (四) 04:45 (UTC)回复

(-)反对,DYK可做附加,但此权无任何绑定DYK的理由。--。->>Vocal&Guitar->>留言 2025年6月26日 (四) 11:30 (UTC)回复
同Ohtashinichiro,社群中总有不愿参与DYK的用户,维基百科不可强迫用户参与。Sanmosa 宫掖事秘莫能辨也 2025年6月27日 (五) 00:10 (UTC)回复
不同意直接纳入申请制度,理由同上。当然,社群还是要鼓励参与新条目推荐候选。—— Eric Liu 創造は生命(留言留名学生会 2025年6月27日 (五) 02:58 (UTC)回复
50个有效条目 或 25个有效条目且至少拥有10个新条目推荐(1个典范/优良条目视为3个新条目推荐),符合其一即可,如何?--Factrecordor留言2025年6月29日 (日) 13:06 (UTC)回复
支持门槛多样化,我当时也是用差不多条件取得巡免的(以IAR的方式以约5X条有效页面附带数篇GA与DYK的情况取得)。--WiTo🐤💬 2025年7月1日 (二) 07:34 (UTC)回复
我认为可以作为“同等能力”证明之一。-- 宇帆-娜娜奇🐰桑朵菈🌿草茶☕(留言☎️·签到☘️ 2025年6月30日 (一) 06:15 (UTC)回复

修订后提案

[编辑]
现行条文

任何管理员均可将此权限授予熟知维基方针及指引(特别是可供查证生者传记收录标准)的可信赖用户。建议门槛为创建或重写(重写的标准可参考Wikipedia:新条目推荐/候选内的说明) 50个有效条目。如您打算为您自己或其他用户申请此权,请移步至维基百科:权限申请/申请巡查豁免权

提议条文

任何管理员均可将此权限授予熟知维基方针及指引(特别是可供查证生者传记收录标准)的可信赖用户。建议门槛为:

  • 创建或重写[注 1]50个有效条目,或;
  • 创建或重写25个有效条目至少拥有10个新条目推荐(1个典范/优良条目视为3个新条目推荐)

如您打算为您自己或其他用户申请此权,请移步至维基百科:权限申请/申请巡查豁免权

  1. ^ 重写的标准可参考Wikipedia:新条目推荐/候选内的说明

综合上方部分用户的意见,修改提案。—WiiUf留言港区国安法5周年 2025年7月3日 (四) 08:35 (UTC)回复

其他想法

[编辑]

既然主要是要确认条目写出来有没有问题,那不妨加入“近期三个月内不得出现创建的条目(不含重定向)被提交CSD和AFD的纪录,或近期所有AFC均通过审核”之类的条件如何?-- 宇帆-娜娜奇🐰桑朵菈🌿草茶☕(留言☎️·签到☘️ 2025年7月1日 (二) 00:10 (UTC)回复

这完全有被大规模扰乱操作的空间,不赞同。Sanmosa 宫掖事秘莫能辨也 2025年7月1日 (二) 05:26 (UTC)回复
(-)反对拿AFD/CSD作为评判标准,你维某些蠢货会进行报复性提删这事不是一天两天了,完全是给扰乱者提供操作空间。——Mirfaek 2025年7月13日 (日) 03:04 (UTC)回复

维基百科:禁制

[编辑]

持续出没的破坏者页面中曾用于破坏的IP记载去留问题

[编辑]

讨论页行为的边界:是善意提醒还是骚扰攻击性的贴标签行为?

[编辑]

提议于优良条目、典范条目、特色列表以及特色图片等典优评选的“投票程序”增加一条文

[编辑]

提议允许用户可按页面大小存档其他用户的讨论页

[编辑]

鉴于某些用户(特别是近年没有再编辑的退休用户)的讨论页过长,这里提议让其他用户(又或只开放予巡查员或管理员)依照帮助:如何将讨论页存档,以页面大至某个元组之数量执行存档他人过长的用户页。个人认为十万元组或以下存一次档可为标准。抄送@魔琴(感谢意见)。——Mykola留言 · 签名 · 乌克兰专题 2025年7月12日 (六) 13:13 (UTC)回复

附议。 ——魔琴留言 贡献 PJ:小学 PJ:两岸 2025年7月12日 (六) 13:50 (UTC)回复
感觉执行方式及标准容易起争议。长页面可能涉及的讨论数难说,用户喜好也难说。是部分存档还是整页存档。--YFdyh000留言2025年7月12日 (六) 17:11 (UTC)回复
或许可以统一在达到一定大小就可以先代他们把额外元组除欢迎辞存档,将此设置为软性措施,先建议,如用户无回应则可以先为执行,如最后他们万一觉得不妥就撤销或再依他们喜好调整。又或许只将此计划推行于已几年没有编辑大概已退休的用户讨论页(毕竟afd等通知按一般处理手法程序发送予用户为佳?)——Mykola留言 · 签名 · 乌克兰专题 2025年7月13日 (日) 01:47 (UTC)回复
按时间如何?之前遇到过十多年的讨论全堆在讨论页的用户,由于加载过慢直接放弃交流了。——暁月凛奈 (留言) 2025年7月12日 (六) 22:18 (UTC)回复
这个也可考虑,但我觉得每个用户在订阅消息或其创建的页面被提删的数量之类可以差很多,可能有一年要存档一两百多个或只有十几个话题的情况出现。(个人认为设置数字门槛较为标准化?--Mykola留言 · 签名 · 乌克兰专题 2025年7月13日 (日) 02:15 (UTC)回复
(!)意见导入机器人自动存档,明确运作规则,确实布达运作规则,公告后试办,试办后无异常或其他意见,可全面推行。
  • 不需要人工处理
  • 需要确认运作规则
--Rastinition留言2025年7月13日 (日) 02:11 (UTC)回复
用户可能有不同的存档子页面命名惯例,机器人不一定明白。 ——魔琴留言 贡献 PJ:小学 PJ:两岸 2025年7月13日 (日) 06:23 (UTC)回复
我认为用户页和用户讨论页对于相应用户而言是具有一定程度的自主权,除非用户允许或者一些维护情况下(例如DYK更新等),尽量会排斥其他用户的操作。因此,没这个必要性。——Sakamotosan路过围观 | 避免做作,免敬 2025年7月13日 (日) 06:28 (UTC)回复
这本身就是“维护情况”。太长的用户讨论页会导致其他用户载入缓慢,阻碍沟通;到达MediaWiki允许的页面大小上限后甚至无法沟通。 ——魔琴留言 贡献 PJ:小学 PJ:两岸 2025年7月13日 (日) 08:12 (UTC)回复
我不认为如此,因为讨论页归档只是一种良好的惯例但不必须,也就是这不是强制需要的。如果对应用户不想做存档,你奈他不何,如果需要弄的话,他早就弄了。——Sakamotosan路过围观 | 避免做作,免敬 2025年7月13日 (日) 10:03 (UTC)回复
? ——魔琴留言 贡献 PJ:小学 PJ:两岸 2025年7月13日 (日) 10:05 (UTC)回复
他想不想是他自己的事,他不存档影响到我给他发消息了,这事就和我有关了。 ——魔琴留言 贡献 PJ:小学 PJ:两岸 2025年7月13日 (日) 10:08 (UTC)回复
同意。由其他用户进行存档应订立规定,只在不存档会造成严重阻碍时才进行存档,并尽量尊重原用户的存档习惯(如有)。--1F616EMO喵留言回复请ping2025年7月13日 (日) 10:09 (UTC)回复