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

互助客栈： 消息  方针  技术  求助  条目探讨  其他 |  知识问答

发表前请先搜索存档，参考旧讨论中的内容可节省您的时间。

公告栏

• [人事] 于2024年5月管理人员申请中，AT当选监督员、Manchiu当选管理员及ATannedBurger当选“临时”管理员。
• [公告] 互助客栈正在对于Unblock-zh.org的各项细节征求意见。
• [公告] 再拟设立文化遗产关注度指引、将地理特征关注度指引中有关道路的部分改为在交通关注度指引中列出及修改RFA流程相关规定已经通过。
• [公告] 修改{{Infobox person}}中native name参数位置、破坏方针重修条文及规范讨论发起步骤正在公示，如有意见请尽快提出。
• [讨论] 互助客栈方针区正在讨论电视条目播放信息增加收录准则及修订高风险主题回退限制，请踊跃参与讨论。
• [讨论] 互助客栈技术区正在讨论更改未登录用户的默认字体大小及增加外观选单，请踊跃参与讨论。
• [讨论] 互助客栈其他区正在讨论页面评级与通用评级行政层面上的统合方案及将法轮功及台湾政治订为高风险主题，请踊跃参与讨论。
• [广告] 第二十二次动员令将于7月6日至9月8日间举行，现正在提议、协调主题，另现正进行主持人选举，欢迎踊跃参与！
• [广告] 维基百科非洲月现正举行，直至6月30日完结，欢迎踊跃参与！

• [协作] 现有125个页面需维基化，289个条目需清理，17个移动请求正在讨论。

#	💭 话题	💬	👥	🙋 最新发言	🕒 (UTC+8)
1	再拟设立国际关系命名常规为方针	120	13	Ericliu1912	2024-06-13 01:54
2	提议英维指引en: MOS:TVINTL经本地化后引入中维维基百科:格式手册/电视	112	10	Nostalgiacn	2024-06-12 21:16
3	关于国籍的原创研究	27	9	UjuiUjuMandan	2024-06-10 11:28
4	必须防止滥用“防滥用过滤器”	1	1	Jimmy-bot	2024-06-12 08:14
5	提议外部链接指引WP:ELNO同时编入WP:可供查证。	19	6	YFdyh000	2024-06-09 14:32
6	单纯罗列名称的列表要不要删除	7	7	Nostalgiacn	2024-06-05 00:59
7	提议统一整合维基百科:命名常规 (电子游戏)及维基百科:命名常规 (日本动漫游戏条目)	146	9	HK5201314	2024-06-12 19:26
8	人工智能生成内容是否适用快速删除准则	11	9	Ericliu1912	2024-06-05 14:33
9	就重修破坏方针征求意见（讨论通知）	2	1	LuciferianThomas	2024-06-11 00:13
10	关于列表条目中，编者自行选出部分项目置于条目顶端，是否符合中立观点	24	5	自由雨日	2024-06-12 00:52
11	过滤器创建方针讨论	8	4	Cwek	2024-06-07 14:01
12	是否应参考英维更新维基百科:独立第三方来源?	33	6	MINQI	2024-06-11 03:28
13	有关维基百科:高风险主题中回退限制的修订意见	40	7	Sanmosa	2024-06-12 14:38

发言更新图例
最近一小时内
最近一日内
一周内
一个月内
逾一个月
特殊状态
已移动至其他页面 或完成讨论之议题
手动设置
当列表出现异常时， 请先检查设置是否有误

正在广泛征求意见的议题

以下讨论需要社群广泛关注：（重新整理）

维基百科格式与命名

Template talk:Infobox person § 修改 Infobox person 中 native_name 参数位置

此讨论正在公示7天；如有意见请尽快提出。

可能需要进一步讨论以便获得共识。--Kethyga（留言） 2024年4月24日 (三) 05:15 (UTC)

Wikipedia talk:格式手册/列表 § 关于族群之知名人物是否需于条目中罗列

如题，关于族群之知名人物目前有三种型式：

1. 以散文形式进行书写，并附加简短说明。如，华人、德裔美国人，
2. 以列表形式进行书写，并附加列入理由。如，华裔美国人、日本裔美国人
3. 不书写知名人物内容。如，德意志人、朝鲜民族

目前以形式二书写的条目近乎皆成为人物罗列为主的条目内容，甚至成为字节怪兽般存在，是否应该废止形式二的书写方式。以华裔美国人及日本裔美国人为例，前者52,541字节中相关罗列内容便占13,565字节，后者9,359字节中相关罗列内容便占3,000字节。--赤羽苍玄（留言） 2024年5月29日 (三) 14:15 (UTC)

Wikipedia talk:命名常规 (人名) § 中国历代君主的金末帝

WP:命名常规_(人名)#中国历代君主的“3. 唐朝至元朝间各朝代的继任君主”段落中，有以下内容：

亦无谥号者，或依照其固定专称命名，如金末帝，

其中金末帝在2013年通过共识时，仍为介绍完颜承麟人物的页面。但在2023年的Special:diff/76206809中，U:Newbamboo将其移动至完颜承麟，并将金末帝改为消歧义页面。

请问是否有其他合适的历史人物，可以在此段落取代金末帝？--CaryCheng（留言） 2024年6月12日 (三) 16:51 (UTC)

维基百科方针与指引

Wikipedia talk:非原创研究 § 提议：对WP:日常计算做小修改

此讨论意在修订既有WP:日常计算的规定。Sanmosa _{全方贫工之联合} 2024年5月14日 (二) 15:50 (UTC)

Wikipedia talk:共识 § 共识创建的递进步骤

此讨论正在公示7天；如有意见请尽快提出。

是否应该修改互助客栈及达成共识的流程，规范讨论必须先在条目讨论页发起，如有必要才发起征求意见或互助客栈讨论，并限缩互助客栈的使用范围？台湾杉在此发言 (会客室) 2024年5月29日 (三) 12:37 (UTC)

Wikipedia talk:破坏 § 重修破坏方针

此讨论正在公示7天，直至2024年6月17日 (一) 16:11 (UTC)结束；如有意见请尽快提出。

终于有时间写好破坏方针的重修版本，建议条文版本在此。主要是重整翻译腔文句（我的版本可能仍有部分翻译腔需要进一步修整），并调整破坏分类和应对破坏指导。内容大致翻译自英文维基百科版方针。--路西法人 2024年6月1日 (六) 17:36 (UTC)

维基百科提议

Wikipedia talk:仲裁委员会 § RfC：2024年2月

接续上段，继续提请讨论仲裁委员会的执行细节。目前讨论中的范畴包括：

• 授予权限：向仲裁委员会授予什么权限？
• 权限限制：如何限制仲裁员在委员会职务以外使用权限？
• 选举信任度下限：目前以50%为最低可当选门槛，是否有需要调高？
• 管理人员解任处理：管理人员解任在多大程度由仲裁委员会处理？
• 其他准备工作：包含相关页面筹备与部署、技术问题及其他需要处理之事项。

--路西法人 2024年2月16日 (五) 02:13 (UTC)

Wikipedia talk:监督/统计 § 有关本页的去留

本页自2021年9月设立以来，仅更新约1年。自2022年10月数据更新后，已有一年半未曾更新，故提请社群讨论是否仍保留此页，请活跃监督员继续更新，还是将本页存档不再更新，谢谢。--在下荷花，请多指教（欢迎签到） 2024年6月12日 (三) 03:23 (UTC)

改革管理员的解任程序

为整合有关主题的讨论，本讨论已移动至Wikipedia:2021年基金会针对中文维基百科的行动/本地社群政策相关讨论 § 改革管理员的解任程序进行集中讨论。请至有关页面发表意见。

执行人：Eric Liu _{欢庆双十中国国庆（留言．留名．学生会）} 2021年10月8日 (五) 21:17 (UTC)

本讨论章节会维持开放，暂时不按最后意见发表时间存档，直到集中讨论告一段落。欲让机器人存档，请移除本模板。留言请置于本模板上方。

管理人员选举制度改革

为整合有关主题的讨论，本讨论已移动至Wikipedia:2021年基金会针对中文维基百科的行动/本地社群政策相关讨论 § 管理人员选举制度改革进行集中讨论。请至有关页面发表意见。

执行人：Eric Liu _{欢庆双十中国国庆（留言．留名．学生会）} 2021年10月8日 (五) 21:17 (UTC)

本讨论章节会维持开放，暂时不按最后意见发表时间存档，直到集中讨论告一段落。欲让机器人存档，请移除本模板。留言请置于本模板上方。

提议调整人事任免投票门槛

（前十个方案由于无共识，现已存档）

意见征集

根据以上讨论，现决定中止公示，但仍进行最后意见征集。以问卷调查的方式进行：

1. 注册满（180/150/120/90）天，且解任投票联署提出或上任投票开始（120/90/60/30）天前，编辑至少500次。
2. 您是否支持收紧活跃度要求？若支持，则应收紧为（75/60/45/30）天？
3. 其他意见。

--12З4567（留言） 2021年12月14日 (二) 05:47 (UTC)

1. 注册满120天，且解任投票联署提出或上任投票开始120天前，编辑至少500次。
2. 不支持，保持90天有1次编辑。
3. 编辑1500或3000次者，活跃度要求为六个月，与IPBE一样。

--桐生ここ★[讨论] 2021年12月14日 (二) 06:56 (UTC)

(！)意见1.本讨论宜以“无共识”终止。2.个人认为收紧活跃度限制这一做法可能无法起到任何预期效果。--Yining Chen（留言|签名页） 2021年12月20日 (一) 15:32 (UTC)

我认为能不能有预期效果还是得做了试行一段时间才能知道，现在这么讨论法也不会有什么结果。但我认为可以先不终止，得让更多人看到这讨论，继续发表意见。--Tazkeung（留言） 2021年12月25日 (六) 18:11 (UTC)

我的意见是：

1. 注册满120天，且解任投票联署提出或上任投票开始120天前，编辑至少500次。
2. 不支持，保持90天有1次编辑。
3. 没有其它意见。

--Lanwi1(留言) 2021年12月28日 (二) 04:31 (UTC)

• (！)意见：

1. 注册满120天，且解任投票联署提出或上任投票开始120天前，编辑至少500次。
2. 不支持，保持90天有1次编辑。
3. 无。

--Kriz Ju（留言） 2022年1月6日 (四) 02:34 (UTC)

方案十一

意见征集已有一个月，共收集到4条有效意见，且意见均为“维持原状”。根据意见，现决定公示以下仅修饰语句、不做任何实质性的修改的版本：

现行条文 凡管理人员解任投票联署或上任投票开始之前，注册满七天且符合以下两项之至少一项条件者有权投票： 解任投票联署提出或上任投票开始120天前，编辑至少500次；并在联署提出或上任投票开始前90天内至少有1次编辑（不包括任何用户页及用户对话页）； 编辑至少3000次，或编辑条目至少1500次。 以上所称“编辑”，均指在中文维基百科的编辑，不含明显的破坏和测试。

提议条文 凡管理人员解任投票联署或上任投票开始之前，符合以下条件者有权投票： 解任投票联署提出或上任投票开始120天前，编辑至少500次；并在联署提出或上任投票开始前90天内至少有1次编辑（不包括任何用户页、用户对话页及沙盒）；或 编辑至少3000次，或编辑条目至少1500次。 以上所称“编辑”，均指在中文维基百科的编辑，且不含明显的破坏和测试。

公示期为7天，若无异议则通过。--12З4567（留言） 2022年1月16日 (日) 08:10 (UTC)

怎么挑出沙盒编辑？因编辑条目而在沙盒编辑算不算？而这又跟直接编辑条目有什么差别？这里的沙盒是否包含草稿？—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年1月16日 (日) 08:27 (UTC)

• @Ericliu1912：没有必要鸡蛋里挑骨头。沙盒是Tazkeung的意见。按照您这种说法，因编辑条目而在用户页编辑怎么处理？如果您想针对某个维基人，请点击此处。--12З4567（留言） 2022年1月16日 (日) 09:08 (UTC)
• 其他 说明：关于投票问题，能不投票尽量不投票，否则就会像WP:投票/缩减管理员不活动期限一样。“注册满七天”并不能起到实际限制的作用，因为第一条“120天前”即“注册满120天”，至于第二条，目前并没有注册不满七天且符合此项条件的用户，故删除。“两项之至少一项”已用新增的“或”表示。桐生君把“注册满七天”改为120天，实际上等于收紧了第二项条件，不属于非实质性修改。（由于编辑冲突，实际发布时间应为08:30 (UTC)）--12З4567（留言） 2022年1月16日 (日) 09:12 (UTC)

  不好意思，我就是要“鸡蛋里挑骨头”。修订应当考虑到所有情形，另外现在我不挑剔，将来也会有人挑，因此这里就由我来做这个角色。命名空间是明确的，但“沙盒”这个概念不明确。我自己就是在用户页编辑条目，所以真要针对也是先针对我自己，还轮不到别人。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年1月16日 (日) 18:45 (UTC)

  移动到条目时起视为条目空间编辑。--桐生ここ★[讨论] 2022年1月16日 (日) 18:57 (UTC)

  所以草稿是否为沙盒？如果是这样那我建议把这里的“沙盒”改为草稿与草稿讨论命名空间，实际涵盖范围仍然不变。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年1月16日 (日) 19:00 (UTC)

  在沙盒的编辑测试不可能移动到条目，而在沙盒的草稿可以发布移动到条目，所以编辑测试属于无效编辑，草稿属于有效编辑。桐生ここ★[讨论] 2022年1月17日 (一) 02:24 (UTC)

  我寻思有谁会刻意用WP:沙盒，草稿多半都是要发布的，也不算是一个大问题。--Ghren🐦🕓 2022年1月17日 (一) 09:22 (UTC)

不同意移除“两项之至少一项”，这两项之中都有“且/或”连接词，不是所有人都很清楚且跟或的优先级，能转为条列式就应该转为条列式，并使用“以下条件之一”的构句来让条件更加清晰易读。--Xiplus#Talk 2022年1月17日 (一) 13:46 (UTC)

如果只是语意调整，请WP:没坏别修。--Ghren🐦🕐 2022年1月19日 (三) 17:12 (UTC)

仅支持去掉那个“七天”，七天1500笔条目编辑也太恐怖了吧…… ——魔琴 [ 留言 贡献 ] 2022年1月27日 (四) 11:32 (UTC)

不行，万一真的行呢，还是把“七天”提进第二点里吧。 ——魔琴 [ 留言 贡献 ] 2022年1月27日 (四) 11:33 (UTC)

自确必定要7天啊，只要随意清清消歧7天1500不太难吧。--Ghren🐦🕗 2022年1月27日 (四) 12:14 (UTC)

方案十二

现行条文 凡管理人员解任投票联署或上任投票开始之前，注册满七天且符合以下两项之至少一项条件者有权投票： 解任投票联署提出或上任投票开始120天前，编辑至少500次；并在联署提出或上任投票开始前90天内至少有1次编辑（不包括任何用户页及用户对话页）； 编辑至少3000次，或编辑条目至少1500次。 以上所称“编辑”，均指在中文维基百科的编辑，不含明显的破坏和测试。

提议条文 凡管理人员解任投票联署提出或上任投票开始120天前，符合以下两项至少一项条件者有权投票： 编辑至少500次；并在联署提出或上任投票开始前90天内至少有1次编辑（不包括任何用户页、用户对话页及沙盒）； 编辑至少3000次，或编辑条目至少1500次。 以上所称“编辑”，均指在中文维基百科的编辑，且不含明显的破坏和测试。

这样比较好。桐生ここ★[讨论] 2022年1月27日 (四) 12:38 (UTC)

才看到上面的留言，确实是收紧了第二个条件，那这个只是供各位参考。桐生ここ★[讨论] 2022年1月27日 (四) 17:26 (UTC)

不过各位可以接受仅注册7天但有1500次条目编辑的用户投票吗？桐生ここ★[讨论] 2022年1月27日 (四) 17:27 (UTC)

（对整个讨论串的意见）我觉得老人条款应该要加一个六个月活跃。你六个月不活跃什么权都没了还能参加RfA不是很合理。-- ——魔琴 [ 留言 贡献 ] 2022年1月30日 (日) 10:28 (UTC)

不活跃除权是出于安全考虑。这跟有没有投票权应该是两回事。不过或许再长一些的不活跃期应该可矣。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年1月30日 (日) 16:29 (UTC)

改成一年如何。桐生ここ★[讨论] 2022年1月30日 (日) 16:54 (UTC)

投票应该也要考虑帐号安全吧。我建议是210天（6月+延期的1月）。 ——魔琴 [ 留言 贡献 ] 2022年1月31日 (一) 08:38 (UTC)

方案十三

现行条文 凡管理人员解任投票联署或上任投票开始之前，注册满七天且符合以下两项之至少一项条件者有权投票： 解任投票联署提出或上任投票开始120天前，编辑至少500次；并在联署提出或上任投票开始前90天内至少有1次编辑（不包括任何用户页及用户对话页）； 编辑至少3000次，或编辑条目至少1500次。 以上所称“编辑”，均指在中文维基百科的编辑，不含明显的破坏和测试。

提议条文 凡管理人员解任投票联署或上任投票开始之前，符合以下三项之至少一项条件者有权投票： 解任投票联署提出或上任投票开始120天前，编辑至少500次；并在联署提出或上任投票开始前90天内至少有1次编辑（不包括任何用户页及用户对话页）； 注册满七天，编辑至少3000次，并在联署提出或上任投票开始前210天内至少有1次编辑； 注册满七天，编辑条目至少1500次，并在联署提出或上任投票开始前210天内至少有1次编辑。 以上所称“编辑”，均指在中文维基百科的编辑，不含明显的破坏和测试。

 ——魔琴 [ 留言 贡献 ] 2022年1月31日 (一) 08:42 (UTC)

方案十四

现行条文 凡管理人员解任投票联署或上任投票开始之前，注册满七天且符合以下两项之至少一项条件者有权投票： 解任投票联署提出或上任投票开始120天前，编辑至少500次；并在联署提出或上任投票开始前90天内至少有1次编辑（不包括任何用户页及用户对话页）； 编辑至少3000次，或编辑条目至少1500次。 以上所称“编辑”，均指在中文维基百科的编辑，不含明显的破坏和测试。

提议条文 凡管理人员解任投票联署或上任投票开始之前，符合以下两项之至少一项条件者有权投票： 解任投票联署提出或上任投票开始120天前，编辑至少500次；并在联署提出或上任投票开始前90天内至少有1次编辑（不包括任何用户页及用户对话页）； 编辑至少3000次，或编辑条目至少1500次。 以上所称“编辑”，均指在中文维基百科的编辑，且不含明显的破坏和测试。

根据意见，修改后重新公示7天。--12З4567（留言） 2022年2月10日 (四) 14:50 (UTC)

这个方案的意思是说，赋予七日内注册、编辑至少五百次者投票权？—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年2月10日 (四) 17:11 (UTC)

应该是编辑7天内编辑1500次条目就有权吧...--Ghren🐦🕑 2022年2月10日 (四) 18:14 (UTC)

删除注册满七日之限制后，实际上就是允许投票前七日以内注册、编辑至少五百次者投票。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年2月11日 (五) 03:33 (UTC)

@Ericliu1912：但是怎可能在120天前编辑500次然后只注册7天？--Ghren🐦🕐 2022年2月11日 (五) 05:00 (UTC)

7<120。我不会说达到这个门槛的可能性有多大，但此方案的效果即是如此。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年2月11日 (五) 05:21 (UTC)

这是不可能的，“120天前，编辑至少500次”，说明120天前已经注册。但是注册七天内编辑3000次（或条目1500次）就有投票权。 ——魔琴 [ 留言 贡献 ] 2022年2月11日 (五) 08:20 (UTC)

“开始120日前编辑至少500次”，七日前也算在这120日前啊，开始七日前编辑至少500次就必然在开始120日前编辑至少500次了吧。这个前有歧义。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年2月11日 (五) 17:33 (UTC)

“投票开始120天前，编辑至少500次”=“投票开始的120天前，编辑已满500次”≠“投票开始前120天内，编辑至少500次”，这边的人只有您误解现行条文，看看下一句的“投票开始前90天内至少有1次编辑”就应该知道您错在哪里。--Xiplus#Talk 2022年2月12日 (六) 04:53 (UTC)

我昨天讲完之后就自己去翻了一下讨论，然后明白确实是自己误会了。但我觉得条文可以写的再清楚一些。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年2月12日 (六) 08:16 (UTC)

可参考台湾的法令用词：“员工应于离职日的10天前预告”，“雇主应于员工离职日的前10天内通报”。例如：“解任投票联署提出或上任投票开始的120天前，至少已编辑达500次；并在解任投票联署提出或上任投票开始的前90天内，至少有1次编辑（不包括任何用户页及用户对话页）”--218.35.184.161（留言） 2022年2月13日 (日) 03:00 (UTC)

因为“注册七天内编辑3000次（或条目1500次）就有投票权”，所以反对。 ——魔琴 [ 留言 贡献 ] 2022年2月13日 (日) 11:33 (UTC)

你是跟Eric君有同一个误解吧，请看Xiplus在2022年2月12日 (六) 04:53 (UTC)的留言。--路西法人☆ 2022年2月15日 (二) 03:32 (UTC)

他的反对意见和Ericliu1912的误解不同。因本案首段删除“注册满七天”后，第一项条件仍规定至少需注册满120天，第二项条件则只规定编辑数，未规定注册时间。然而两项条件只须符合其一即有权投票。--111.71.79.179（留言） 2022年2月15日 (二) 05:16 (UTC)

我觉得他的理解无误。能不能不要在没有人支持下不停公示？--Ghren🐦🕕 2022年2月15日 (二) 10:32 (UTC)

可以解释一下本章节内列出的14个方案是什么关系吗，是从其中要选择一个还是什么别的意思；有的小段落已经有超过三个月没有人讨论了，这些算是呗否决了吗。 Stang^★ 2022年2月24日 (四) 14:47 (UTC)

事实上我觉得这里面没有一案有共识的，不如维持原状。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年2月24日 (四) 16:05 (UTC)

这能不能雪球掉？都半年了。--Ghren🐦🕐 2022年2月25日 (五) 05:38 (UTC)+1 Yining Chen为此+1了。

• 最近因为有事，没有时间回复大家的意见，这些意见我也看过了，绝大部分是反对，而且反对的理由也很荒谬：“赋予编辑超1500次的非自动确认用户投票权”，标题也不知道被谁改成了“方案十四”。请问你们见过哪个新用户能在7天内编辑1500次（平均每天编辑214次），还能保证这1500个编辑全都是条目，而且恰好是投票前7天内作出的，而且全都是实质性编辑，没有一个破坏或测试？根据WP:最近编辑次数最多的用户统计，只有3个非机器人用户最近一周内编辑超过1500次，而且表中所有用户均为自动确认用户。大家可以自己找一下历史上有没有符合上述所有条件的用户，如果有的话可以在下面留言。假如真有这种用户，那么管理员难道不会以WP:游戏维基规则封禁之？希望大家认真思考这几个问题，当然也可以讨论，我先把上面的公示去掉，如果没有意见的话，我再公示。--12З4567（留言） 2022年2月25日 (五) 04:35 (UTC)

第三次推动设立LTA命名空间

由于今年LTA模仿犯泛滥，对本站站务造成困扰，我希望重提设立LTA命名空间，并通过引入扩展功能（mw:Extension:Lockdown）设置页面查看权限。

前期讨论

1. 部分用户认为不设置查看权限就没必要设置命名空间，有用户认为即使不设置查看权限也有必要设置命名空间。
2. 有用户认为，限缩查看权限不利于反破坏人员之养成、判定LTA，甚至沦为社群斗争工具。

设立流程

1. 社群讨论决定设立LTA空间。
2. 走mw:Writing an extension for deployment#Preparing for deployment的流程，同时社群讨论空间的细节。
3. 扩展功能可以启用后，通过phab:设立LTA空间，并设置查看权限。同时进行后续处理（如将LTA部分特征页面留在Wikipedia空间）。

以上，希望社群讨论。 ——魔琴 [ 已经告假 留言 贡献 ] 2021年12月31日 (五) 15:51 (UTC)

查看权限设置为回退员只能看，还是其他用户组（巡查可能需要以挂板）为佳？问题就是LTA空间的内容一外漏影响就是永久的，很容易在网上流传开去，需要再三考虑下。--Ghren🐦🕑 2021年12月31日 (五) 18:25 (UTC)

还不如把LTA页面移动到另一个wiki里面。--GZWDer（留言） 2022年1月1日 (六) 06:21 (UTC)

这样说我觉得一些不宜公开讨论的反破坏讯息可以全数移动到一个独立的站点（Miraheze也好、wikimedia下的也好，都可以）--路西法人☆ 2022年1月1日 (六) 11:16 (UTC)

巡退、延伸确认、管。限缩得太紧的弊端已述。至于“LTA空间的内容一外漏影响就是永久的”，回退员也不一定可信啊……限缩主要是为了防模仿犯、反愉快犯，也防止LTA页面成为破坏者联络场所。-- ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月2日 (日) 05:23 (UTC)

不好意思，讨论过长没找到“弊端已述”。延确能否信任也是一个问题，但可以后议。--Ghren🐦🕙 2022年1月2日 (日) 14:42 (UTC)

@Ghrenghren：“不利于反破坏人员之养成、判定LTA，甚至沦为社群斗争工具”，完整版见Wikipedia:互助客栈/方针/存档/2021年8月#再次推动破坏者（LTA）成为命名空间中Kriz的留言。 ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月2日 (日) 15:06 (UTC)

请先确定Lockdown能够确实引入，以免浪费大家时间来讨论。--Xiplus#Talk 2022年1月3日 (一) 05:30 (UTC)

走引入流程可能需要社群共识：Your deployment tracking bug should point to on-wiki community consensus (and/or community support/desire) for having the extension installed on a particular wiki, if applicable. 所以这就是第一步“社群讨论决定设立LTA空间”，Ghren的提问其实是下一阶段的内容。 ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月3日 (一) 05:42 (UTC)

这不就死循环了吗？对LTA空间是否设立存在疑虑是因为不知道能否使用Lockdown扩展；若要知道能否使用Lockdown扩展，必须达成共识成立LTA空间；若要达成共识成立LTA空间，需要知道可以使用Lockdown扩展。这就是永远的死局了。 --Milky·Defer 2022年1月3日 (一) 07:36 (UTC)

所以我提议的流程是先达成启用的共识，如果可以启用再设置空间。 ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月3日 (一) 07:41 (UTC)

我觉得这是个死局。假如不能Lockdown其实没什么意义。姑且可以先支持，但假如Lockdown用不了就当时再移回去吧。--Ghren🐦🕓 2022年1月3日 (一) 08:42 (UTC)

所以唯一支持创建独立的命名空间的理据是使用Lockdown吗？那么我不反对将设立命名空间跟引入Lockdown绑定讨论，部署Lockdown跟新命名空间应同时进行，若最终Lockdown无法引入，创建命名空间直接作废。--Xiplus#Talk 2022年1月3日 (一) 11:15 (UTC)

我的意思就是这个（不知道是不是表述不清楚），扩展功能可以启用后，通过phab:设立LTA空间。 ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月3日 (一) 12:10 (UTC)

• (！)意见：敝人路经此地，窃以为若暂且不论站友前述的专业技术工程，斗胆对所谓的LTA之存在和相关页面表达个人看法。

先说结论，个人主张不限制阅览权限，但进一步提高收录门槛；若往后真限制阅览权限，延伸确认以上权限之用户可观看。

首先，个人反对轻易增生所谓的LTA页面。每每只因有无聊的反社会人士来搞破坏一段时间，社群就替他们“立传”，窃以为未必具那么大的迫切或必要性；个人认为大量创建LTA专属页面除了可能轻易帮那些破坏者树立“战绩里程碑”之外，长久而言提供他们继续追求“战功和名望”之诱因，也替他们在维基世界和时间长河中留下“个人（可能值得纪念或回味）的历史印记和足迹”，甚至恐成为有心人轻易反向滥用该页面或散布特定信息之良机。某些编辑行为究竟是否属破坏，个人认为反破坏编者可自行依站内规范和经验判断；在破坏者“升级”成为LTA前，多数时候热心用户维护关注的目标以“条目”为主，应即可有效实践反破坏之本意（若真有需要查缉傀儡账号另当别论）。

其次，此类LTA页面之使用方式分为编写和阅览两个面向。就阅览而言，个人仍认为应开放信息供所有有心用户阅览拣用，原因如过往所述。然而就编写而言，站内热心站友常在发现有破坏者符合收录门槛后，便热心记录描写其特征和行为，并创建相关页面公示于众；有时LTA的相关信息情报甚为模糊，仅稍具轮廓雏形而已，又或是过多细节导致实难真正辨识，甚至套用于其他编者身上亦看似轻易符合，故个人认为可能需要进一步研拟限制措施。

因此，在概念上，个人主张采“无无虚无”（中二....）之策略，亦即“回退、封禁、不理会”之最大化延伸，尽可能削减破坏者戮力追求之名望、成就、意义、价值、荣誉感、存在感、个人风格等可供追求之心理反馈，故在记载上应提高登载收录和讯息传播门槛。

具体措施上，就登载收录而言，个人建议维基百科:持续出没的破坏者之情报页面创建门槛为“持续破坏3个月以上，且编者提供之相关情报信息经客栈讨论公示通过”，方移置公开收录于VIP室页首。尤其对于有心借由模仿或造谣等方式进行扰乱之破坏者而言，若经由少数人收集或判读讯息、未经过滤便轻易创建可供收录展示之“专属页面”、成为“维基馆藏”，甚而因部分热心关注者可能的误判造成负面效果，窃以为实属不妥。

就讯息传播而言，敝人主张可考虑进一步将所有LTA按编号代码予以编管，于“Wikipedia:持续出没的破坏者/<用户名>”创建情报页面时改采流水号编码，并以编码创建相关重定向，以其编码公示于VIP室，而原账号名称则记述于情报内文和信息框，编码方式和规律以可无限延伸、不具意义为基本概念，举例如下：

1. 尽可能不依特定缘由或规律编号（如出现和破坏之时间、顺序、编辑类型等规律或事由），于邻近的号码顺序内，随机进行编号。

2. 将英文字母和数字结合，持续延伸，列举流水号样式如下：

“ LTA：AA-0002 ～ LTA：AA-9998，

---> LTA：AB-0002 ～ LTA：AB-9998

---> LTA：AC-0002 ～ LTA：AC-9998.....

---> LTA：AZ-0002 ～ LTA：AZ-9998

---> LTA：BA-0002 ～ LTA：BA-9998

---> LTA：BB-0002 ～ LTA：BB-9998....

---> LTA：BZ-0002 ～ LTA：BZ-9998

---> LTA：CA-0002 ～ LTA：CA-9998..............

---> LTA：CZ-0002 ～ LTA：CZ-9998

---> LTA：ZA-0002 ～ LTA：ZA-9998..............

---> LTA：ZZ-0002 ～ LTA：ZZ-9998

---> LTA：AAA-0002 ～LTA：AAA-9998

---> LTA：AAB-0002 ～LTA：AAB-9998...........

---> LTA：AAZ-0002 ～LTA：AAZ-9998

---> LTA：ABA-0002............ ～.............LTA：ABZ-9998...........

---> LTA：ZZZ-0002 ～LTA：ZZZ-9998

---> LTA：AAAA-0002............

”

可无限延伸，若真有需要的一天（笑）。个人意见，供参。--Kriz Ju（留言） 2022年1月6日 (四) 02:24 (UTC)

我觉得，封闭LTA查看权限可能可以规避“冲战绩”的想法，毕竟自己看不到。至于阅览面向，我觉得给延伸确认就可以了。 ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月6日 (四) 04:31 (UTC)

别用流水账，即使要DENY也不至于这样，这样太难记谁是谁了。--路西法人☆ 2022年1月11日 (二) 04:51 (UTC)

• (！)意见：敝人的用意就是要构成一种“双向限制”的效果，不只限制LTA对外传播个人“功绩”，同时也提高社群对于相关讯息的信息传递和讨论门槛，甚至有时有心人正是借此方式散布各种扰乱讯息。在此敝人斗胆挑战一个概念：为何我们要记得或认识他们呢？“努力”破坏的人被社群“铭记在心、永恒流传”，还可以成为被“登载史册、正式收录”的对象，反倒对社群有贡献的善意用户随着逐渐淡出或离去，经过几年后，又有多少人或新进用户认识或记得他们曾经的贡献呢？

这么说起来，是否破坏者破坏一阵之后，即可名留青史？善意的贡献用户还不见得可以轻易留名，就证明自己的“存在感”而言，当今的社群机制是否反倒在鼓励破坏者留名呢？

我们努力记住那些破坏者，却放任社群遗忘曾经致力为社群贡献的无名英雄，敢问这是什么荒谬的现象或制度呢？

进一步而言，随着时间过去，流水号越往后排越显冗赘，而对于未来的LTA而言，他们公示于众、留给世人的，就是这些他们自己也无法掌握、任人取名的“编号”，而不是他们要让大家认识、甚至充满个人风格、带有个人色彩的“账户大名”。

窃以为就实务而言，既然提高信息传播门槛，加上若往后只有部分用户具备阅览权限，这表示只有真正愿意投入研究的用户，才能更熟悉这些讯息，亦即“反破坏”的相关信息会进一步更接近为“带有某种技术色彩”的站务，而不是只有“不会写条目、不务正业”的用户才会去玩的不入流把戏。

真正愿意研究的人，肯定一段时间后就能辨识，尤其对于曝光率较高的那几位远古先生，不成大问题（比如有在投资的人就会了解，一段时间后对于投资标的代码就可以如数家珍），甚至还可以提高用户参与度和投入时间（事实上点进去页面看一下即可，也不用硬记）；而无法辨识或阅览信息的人，是否愿意投入反破坏行列，就看个人选择了。--Kriz Ju（留言） 2022年1月12日 (三) 11:22 (UTC)

这样只会造成反破坏工作更难进行。有名称的作用是要可以立刻配出谁是谁，变成流水账基本上没人能辨识是哪一个破坏者。“事实上点进去页面看一下即可，也不用硬记”但给出链接都成问题，怎样点进去？辨识破坏者是必要的，我近期接触大量LTA更感受到这一点，不然也不会提出改进破坏者辨认的SPI。--路西法人☆ 2022年1月13日 (四) 09:53 (UTC)

• 另外，考虑到 IP masking，我希望LTA空间对且仅对（未来）有权限查看IP地址的用户开放。 ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月8日 (六) 05:24 (UTC)

  对比开放予延伸确认用户阅读该命名空间，我更倾向魔琴提议仅开放予有权限查看IP地址的用户阅读有关页面。--路西法人☆ 2022年1月9日 (日) 03:27 (UTC)

不知道是不是应该回复在这儿。这个扩展提供的限制非常鸡肋，您只需要在其他命名空间创建一个指向私有的LTA命名空间页面的重定向，再在另一个页面中嵌入前述重定向，即可浏览内容。--——ほしみ 2022年1月17日 (一) 15:59 (UTC)

注：调整 $wgNonincludableNamespaces 无法控制其他命名空间指向LTA命名空间的重定向之嵌入。--——ほしみ 2022年1月17日 (一) 16:04 (UTC)

啊这，您有去mw:Extension talk:Lockdown提过吗（ ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月17日 (一) 16:14 (UTC)

您可以自行测试后去提一下，我这边测试的结果是即使是master也没解决这个问题。这个问题就写在mw:Security_issues_with_authorization_extensions内，看Inclusion/transclusion一栏右侧评论栏的意思是部分解决了，那重定向嵌入可能没解决吧。只能说，这个扩展限制的read权限目前并不能阻止破坏者完全不能阅读。--——ほしみ 2022年1月17日 (一) 16:37 (UTC)

重定向问题可能可以通过AF解决？ ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月18日 (二) 03:58 (UTC)

AF没用的，单页面内预览就行了，甚至不需要创建页面。

例如Sandbox页面:

#重定向 [[LTA:Sandbox]]
{{:Sandbox}}

——ほしみ 2022年1月18日 (二) 04:29 (UTC)

Ghrenghren在站外提到可以“在所有LTApage 上加上个空白的onlyinclude”。 ——魔琴 [ 留言 贡献 ] 2022年1月19日 (三) 15:42 (UTC)

已确认，已报告。--Xiplus#Talk 2022年1月17日 (一) 16:36 (UTC)

另外，一般用户仍然可以在最近更改、最新页面、用户贡献等特殊页面看到私有命名空间内每一笔编辑的摘要，包括创建页面时自动生成的摘要。--——ほしみ 2022年1月17日 (一) 16:45 (UTC)

---

上述讨论中LTA收录门槛的讨论与本案无关，将分拆讨论。距离Kriz君在我的讨论页表示支持已过去七日，现拟出决议并 交付公示，为期7日，2022年1月24日 (一) 04:19 (UTC) 结束。

本社群达成共识：

一、本站将设立临时代号为“LTA”的命名空间，用于储存长期破坏的信息以反破坏，其它细节待议。

二、本站将申请部署mw:Extension:Lockdown以限制LTA命名空间的阅览权限。

三、LTA命名空间仅应在mw:Extension:Lockdown可以部署后设立。

 ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月17日 (一) 04:19 (UTC)

最好不要再像修订巡查那样搁浅。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年1月17日 (一) 07:27 (UTC)

• 已经搁浅了。修订巡查也是技术人员说“欲申请的扩展不会在任何维基媒体站点部属”。本次议案也是技术人员说“欲申请的扩展不会在任何维基媒体站点部属”。。。 囧rz……-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鲜果茶☕]（☎️·☘️） 2022年1月22日 (六) 03:47 (UTC)

上面的说的在理，我们还要搞吗 囧rz……--Ghren🐦🕗 2022年1月18日 (二) 00:10 (UTC)

唉，又是一次浪费社群时间的讨论。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年1月18日 (二) 00:33 (UTC)

单独设立空间本缺乏意义，但本案提及限制阅览权限的问题，其论述有说服力，故支持本案。但

1. 本案之二仍需明确，具有阅览权限的用户范围，该范围不易太窄。有用户提出以延伸确认为界，考虑到反破坏一般至少是具备一定经验的用户，我认为是适宜的。
2. 若能着手明确本案之二、三技术上是否确实可行，则更为稳妥。

以上。--Kirk # 2022年1月18日 (二) 04:15 (UTC)

现在讨论这个大概真是浪费社群时间……但是考虑到 IP masking, 我希望LTA空间对且仅对（未来）有权限查看IP地址的用户开放，而延伸确认肯定不是这种用户组。 ——魔琴 [ 留言 贡献 ] 2022年1月18日 (二) 10:41 (UTC)

---

撤下公示。 ——魔琴 [ 留言 贡献 ] 2022年1月19日 (三) 12:17 (UTC)

（对本讨论串整体的意见）在过去的反破坏工作中，我有九成把握可以说，能查阅私有过滤器者（回退员、管理员）中有人向外泄漏私有过滤器内容。所以不要对“限制阅读权限对保密有好处”抱有任何希望。谨此提醒参与本讨论的编者。至于防模仿、愉快犯的作用几何，我对此基本没有实感。--Tiger（留言） 2022年1月19日 (三) 13:21 (UTC)

我有一个限制阅读权限的另一个理由：IP masking 实施之后，普通用户组不能直接查看未登录用户的IP，而有权限查看的用户也不能向无权限的用户提供这个信息，而反破坏中IP也是很重要的，只能放在私密的命名空间里了（即使保密性存疑）。 ——魔琴 [ 留言 贡献 ] 2022年1月19日 (三) 13:58 (UTC)

这不是只有本地会遇到，而是所有wiki都会遇到，没有必要本地硬想出方法（尤其还是个烂方法），参考其他wiki的作法也是可以的。--Xiplus#Talk 2022年1月26日 (三) 06:58 (UTC)

至于能查阅私有过滤器者（回退员、管理员）中有人向外泄漏私有过滤器内容，嗯，看起来不是什么新闻。 ——魔琴 [ 留言 贡献 ] 2022年1月19日 (三) 16:02 (UTC)

设立新维基

于Phabricator查看
编号T299546的工单
状态：已拒绝

GZWDer在phab提出了相关task后，User:Martin Urbanec表示，因为MediaWiki的阅读限制很可能被绕过，“几乎可以肯定Lockdown不会在任何维基媒体维基安装”。他建议可以参考意大利语维基百科申请创建的https://sysop-it.wikipedia.org，可能更适合本站的需求。

于Phabricator查看
编号T299590的工单

GZWDer于是提出了Create zhltawiki 的task作为替代。有两种方案：一是传统私密维基，不连接SUL，符合要求的用户可以通过一个Toolfridge工具自动创建帐号；一是Miraheze式的私密维基，连接SUL列入“member”用户组的用户有权限查看私密内容。

User:Majavah表示CentralAuth并不支持Miraheze式方案。

现交付社群讨论是否创建LTA维基，以及其具体实现方式。 ——魔琴 [ 留言 贡献 ] 2022年1月21日 (五) 16:10 (UTC)

建议CentralAuth，但由BOT进行在主站有相应权限的用户的权限同步，把read给一个额外的用户组。--Wiki emoji | 😷🅔🅜🅞🅙🅘🅦🅘🅚🅘😷 _{祝百毒不侵～} 2022年1月21日 (五) 22:23 (UTC)

IP masking 实施之后，LTA WIKI（或Lockdown，但不可行）成为了宪制性必须存在的实体，故(＋)支持。--Wiki emoji | 😷🅔🅜🅞🅙🅘🅦🅘🅚🅘😷 _{祝百毒不侵～} 2022年1月21日 (五) 22:31 (UTC)

我觉得没什么必要。Tigerzeng阁下说的也挺明白了。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年1月22日 (六) 02:08 (UTC)

(✓&)有条件同意：创建一个新维基就设立的通用一点，延伸确认用户维基，所有延伸确认用户可见，或站务维基（行政员、管理员、巡查员、回退员、经申请可查看者）。桐生ここ★[讨论] 2022年1月22日 (六) 02:40 (UTC)

我觉得可以（站务维基），而且我突然想到，编辑sysop-it的都是sysop，那么编辑zh-lta的就都是     ——魔琴 [ 留言 贡献 ] 2022年1月22日 (六) 15:53 (UTC)

有条件支持：私以为除非对查看者进行严格限制（如wiki查看权应使用类似于巡查回退的申请方法），否则LTAWiki的设立并无太大意义。—Regards, BureibuNeko 2022年1月22日 (六) 06:15 (UTC)

既然有管理员内鬼，这条路恐怕不通。--Temp3600（留言） 2022年1月22日 (六) 09:04 (UTC)

说起来，还有防滥用过滤器这条路可以硬塞LTA信息的，不过有可能影响过滤器效率（--1233 （T / C） 2022年1月23日 (日) 03:27 (UTC)

(＋)支持，但是可访问用户的选择可能需要在延展用户的基础上增加一些特殊的限制，如规定最低Wikipedia命名空间编辑数。--Yining Chen（留言|签名页） 2022年1月23日 (日) 14:05 (UTC)

没意见。--三万光年 _GBAW 2022年1月25日 (二) 12:04 (UTC)

(＋)倾向支持,只要访问限制得当，就没有问题。--在下荷花，请多指教（欢迎签到） 2022年1月26日 (三) 04:09 (UTC)

应该先确定持权条件再来设立新维基，另外反对任何能够自动获权的门槛制，应采用申请制，不然泄漏内容的话不仅隐藏内容无用，反而将资料保存在独立的wiki上，徒增麻烦而已。--Xiplus#Talk 2022年1月26日 (三) 06:56 (UTC)

(＋)支持，但(－)倾向反对CentralAuth的方案，我支持xiplus的申请制，并且我认为该wiki不应该搭建在wikipedia.org空间，而是自行在Toolforge上搭建，账号系统与基金会的CentralAuth完全分开。--忒有钱🌊塩水あります🐳（留言） 2022年2月3日 (四) 18:41 (UTC)

(～)补充：关于申请制，我认为应设立如下门槛：

1. 关于阅读权限，我认为至少是延伸确认用户才可申请；
2. 关于编辑权限，我认为必须是傀儡调查助理、用户查核员（若有本地查核权）/监管员（若无本地查核权）、管理员、行政员、监督员才可申请。

以上。--忒有钱🌊塩水あります🐳（留言） 2022年2月19日 (六) 13:50 (UTC)

wikipedia.org空间、Toolforge、CentralAuth其实是三件不相干的事情...没有因果关系。--Xiplus#Talk 2022年2月19日 (六) 14:40 (UTC)

有条件支持：支持提案，但认同Xiplus君所言应优先决定持权条件再设立。另外能不能不要叫“LTA维基” 囧rz……--路西法人☆ 2022年2月9日 (三) 07:24 (UTC)

看起来就“设立”本身有了初步共识，可以进一步往下进行讨论。顺便一提关于IP masking方面的事项似乎现在处于停滞状态（原计划是在1月17日给出一个方案的），是否需要在此方面等待一下？如果那边有了推进（比如那边似乎是说要成立一个新的用户组可以看部分masked的IP），可以参考那边的组的门槛。 Stang^★ 2022年2月16日 (三) 20:25 (UTC)

就安全投票问题订立管理员选举暂行规定

社群日前进行投票表决通过，决定“在未来一场管理员选举使用安全投票（SecurePoll）”。考虑到选举提名与安全投票开启之间具有时差，现请社群就选举日程，包括讨论期间、投票期间等面向订立暂行规定，优先于既有之申请成为管理人员指引。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年1月5日 (三) 14:18 (UTC)

我这里写个草案吧。考虑到农历新年和动员令社群会比较忙，本次算是一次比较大型的选举，选举宜在二月下旬至七月进行。考虑到目前的站务积压，目前应该以管理员数量为首要目的，毕竟最积极的虫虫飞消失了，其他WP:OA2021中被除权的9位也有相当的贡献，理论上先提名曾任管理的用户比较容易得到共识。而针对Spoll的数目而言，我个人认为一次应该避免超过5个以避免影响社群同时要关注过多的投票。因此大致草案如下：

2月15日-2月22日：曾任管理员者可以优先被提名。超出5个则暂时冻结。

2月22日起：假如提名者不足5个一般合Rfa要求者也可以参与。

2月22日-3月22日：对候选人作出提问，社群讨论候选人是否合适。

3月22日至3月29日：开启Spoll让社群进行投票。（两周或者提前开启也可，另议。）

3月29日后：行政员再按投票结果得出结论。同时再考虑准备下一回的投票。4月至7月其间可以再进行另一场Rfa。

此外，也有其他问题，以此Securepoll而言，延长投票似乎不太实际。而且中立的票也难作考虑。故此可能要设立一个比较固定的标准，按以往近80%则延长投票的做法较难实行。--Ghren🐦🕐 2022年1月5日 (三) 17:55 (UTC)

此外一票两投IA也是个问题。以往可以用文字说明支持IA但不支时Admin，但SPoll不能做到这点。--Ghren🐦🕐 2022年1月5日 (三) 17:57 (UTC)

这样的话能不能分开spoll？有意愿选界面的话多开一个，分开两边投。--AT 2022年1月5日 (三) 18:20 (UTC)

这很简单，若当事人要选界面管理员，增设一问题即可。 —— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年1月5日 (三) 18:31 (UTC)

见下。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年1月6日 (四) 07:22 (UTC)

RfA已经不能兼RfIA了吧 ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月6日 (四) 04:01 (UTC)

请注意投票结果是“未来一场”。多于一人参与会面临要适用安全投票抑或一般投票方式的问题，且可能超出社群投票效力之范围。故此仅建议以一人参与的情况来决定日程，这里指的不是绝对的行事历，而是相对的日数。之所以不直接决定往后采用，就是因为需要观察。其实当初投票应该不要写未来一场，而是写“未来半年”之类的或许比较弹性一点呀。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年1月5日 (三) 18:28 (UTC)

作为参考，目前的管理员选举，讨论与投票并行，为期共十四日。在尊重既有制度、不改变实际选举时长的情况下，个人有三种方案：

1. 提名后立即开启讨论，为期七日，期间赶紧筹备安全投票，七日后开放投票，为期七日，总时长仍为十四日；（讨七，投七）
2. 提名后立即开启讨论，期间赶紧筹备安全投票，七日后开放投票，但同时允许继续讨论，总时长仍为十四日；（讨七，讨／投七）
3. 提名后立即开始筹备安全投票，期间不得进行任何讨论；安全投票开放后，同时开放讨论，二者并行，为期共十四日。（讨／投十四）

以上，请斟酌。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年1月5日 (三) 18:36 (UTC)

筹备安全投票本身大概需时多久？--AT 2022年1月5日 (三) 18:38 (UTC)

或许@1233会清楚？—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年1月5日 (三) 18:45 (UTC)

我认为提名期和投票期搞得太紧安全投票会过于难安排。提名后不得讨论也过于高估社群的自制力。我认为投票期延长为妙。上次实际上也是延期了一周左右。当然事前预备好不是不行。但我认为安全投票的制度当初就有建议一年两场之类的意思，单纯选一个管理出来似乎效率有点低，总不行一年只出两个管理。--Ghren🐦🕗 2022年1月6日 (四) 00:20 (UTC)

七天搞起一个Spoll只怕也太难了，单是整理一份当时有人事任免资格的名单也已经用时甚久。假如共识认为一年两场Spoll是比较合理的，日后的方案理论上应该往这个方案走，虽然这个共识没有约束力。单问个人而言我认为第一届还是合并数人举行为好，但是作为第一次投票作为实验性质也可以。--Ghren🐦🕗 2022年1月6日 (四) 00:46 (UTC)

那么就是当初投票问题设计得不好了。为避免争议，下一次选举最好还是仅推举一人。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年1月6日 (四) 07:22 (UTC)

@Ericliu1912，这东西其实是没有任何的标准的，但是细节是可以讨论的。

我认为提名后就要筹备安全投票。期间应该是可以讨论的。（禁止讨论其实不切实际）。

反而投票的期间则应该仍然固定为十四天，而讨论则可以在开始前继续。另外，我认同一次选举可以牵涉不同的人选，而不需要像现在那样，一次选举能投票给一位候选人。（可能是投票给两至三位候选人）。

然后“整理一份当时有人事任免资格的名单”的问题其实不难解决，可以使用python或php等不同的方式整理就可，就像是这次的投票。而且该段code理应是可以重用的。--1233 （T / C） 2022年1月6日 (四) 03:24 (UTC)

遇上圣诞假期或是跟其他wiki投票冲突搞不好要推迟超过14天。--Xiplus#Talk 2022年1月17日 (一) 13:53 (UTC)

窝都可以，三个方案看要哪个社群决定好就好，不要又在那这不行那也不行。--~~Sid~~ 2022年1月14日 (五) 15:52 (UTC)

如果社群认同投票不能代替讨论的话，应强制讨论开始一段时间后才开始投票，让大家都能通过讨论更加认识候选人。--Xiplus#Talk 2022年1月17日 (一) 13:57 (UTC)

• Special:Diff/69512366#关于SecurePoll的一个紧急问题。 ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月7日 (五) 13:01 (UTC)

  实在是多难之秋。--Ghren🐦🕐 2022年1月7日 (五) 17:04 (UTC)

• 支持讨七，讨／投七方案，由于这次选举是使用SecurePoll的第一次有效力的选举，且使用的是临时方针，建议仅提名一人，这样可以不用对现行选举方针进行大幅改动，使社群容易适应。等将来决定长期使用SecurePoll选举后，可考虑同时提名多人的制度。——BlackShadowG（留言） 2022年1月9日 (日) 07:29 (UTC)

• 可以这样呀。（或者管理员选举可以尝试改为2022年第一次管理员选举？）--1233 （T / C） 2022年1月11日 (二) 20:23 (UTC)

同意。禁止讨论怎么看怎么不现实。 ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月14日 (五) 15:57 (UTC)

• 再来多一点脑震荡：未来一场，其实就大致上可以一票多投（例如可以修改为2022年第一次投票，然后就连往不同需要投票的议题（例如两位参选管理员的用户的问答页），甚至可以包含其他选举（例如基金会说的那个什么查核员选举）。我认为，根据这个投票的准备时间，一票多投是最好的方案。（至于其他公共议题还是先讨论后明票吧）。1233 （T / C） 2022年1月14日 (五) 15:56 (UTC)

  个人不太同意任意扩大解释。最好还是谨慎一点。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年1月14日 (五) 19:00 (UTC)

  我觉得第一次的话真的是一个人又有什么所谓，但是要确保Spoll的日程确实能定出来比较好，以安排技术上的问题。此外CU是两周的话，Admin也是两周为当。--Ghren🐦🕑 2022年1月15日 (六) 06:26 (UTC)

  如果要搞SecurePoll的话，其实最好是有一个Call for nominations的办法，但是如果只是一位用户参选管理员的话，那样其实并不需要日程。--1233 （T / C） 2022年1月17日 (一) 07:09 (UTC)

  假如是一个人的话，解决了对面消息的技术问题就可以开始？但是一个人的话要投多少天？投票日期和被提名的日期要中间要差多少以安排技术问题？我记得试的时候是延了期的。--Ghren🐦🕕 2022年1月17日 (一) 10:38 (UTC)

  延期的原因是和其他投票有冲突的日期。现在来看，在短时间内是不会有这个问题的。--1233 （T / C） 2022年1月27日 (四) 13:36 (UTC)

• 有一个关于流程的问题，启用SP后，是要继续延续现在的“边投票边提问”还是要“先提问再投票”？等待SP部署时是否能提问？--Yichen Ding（留言|主账户） 2022年1月22日 (六) 14:53 (UTC)

  @Yichen Ding：“讨／投十四”是完全的边投票边提问，“讨七，投七”是完全的先提问再投票。“讨七，讨／投七”则是二者之间的折衷。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年1月24日 (一) 13:20 (UTC)

  @AT@Ericliu1912@Yining Chen@魔琴@Xiplus：暂时是2人支持14天（我和1233），1人支持讨七，讨／投七方案（BlackShadowG），其他人有没有其他意见？--Ghren🐦🕘 2022年1月28日 (五) 13:03 (UTC)

  支持讨／投十四。--AT 2022年1月28日 (五) 13:10 (UTC)

  要不要关于这件事开一个投票讨论 --Yining Chen（留言|签名页） 2022年1月29日 (六) 07:25 (UTC)

• 如果已经决定下一次RFA要用SP，现在是否应该尽快得出一个（至少是临时的）方案？（毕竟这两年只有一个新管理员上任，还面临着上面提到过的问题，或许需要尽快处理好这件事然后尽快举行新的RFA 囧rz……） --Yining Chen（留言|签名页） 2022年2月2日 (三) 02:35 (UTC)

  再过几天没人提案，就把上面几个选项拿去表决了。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年2月2日 (三) 07:39 (UTC)

不如直接邀请他人他人提名/推荐，然后同时搞管理员/用户查核员的SecurePoll，然后提名7天，讨论7天/投票14天？（提名和投票期需要大约三天以准备投票人列表及问题），然后主页面为WP:投票/2022年第一次安全投票。--1233 （T / C） 2022年2月2日 (三) 08:10 (UTC)

2022年社群愿望清单调查中与此案相关之愿望，大家可以去看看。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年2月2日 (三) 15:17 (UTC)

---

现在的最大问题在于我们无法预期安全投票筹备要多久。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年2月10日 (四) 11:25 (UTC)

所以我才提议预先指定一个提名日子，筹备安全投票的时间有太大风险。指定了就能解决所有问题。--Ghren🐦🕖 2022年2月10日 (四) 11:41 (UTC)

不就是吗，而且还可以顺便在同一时间搞CU的选举--1233 （T / C） 2022年2月11日 (五) 13:53 (UTC)

根据他站社群（英维及波斯语维基百科）在去年于监管员布告版请求监票之情况，他们在投票开始前（并非提名期开始前）大约一个月，已作出相关请求，可推断开始投票前一个月便需作筹备。再者他们的选举为定期进行，故如非定期进行可能需时更多。另可参考波斯语维基百科过往的筹备时间表。谢谢。--SCP-0000（留言） 2022年2月11日 (五) 14:54 (UTC)

---

抱歉，但目前这个议案己经放置在这一个月有余但讨论依然不足，我唯有按波斯语维基百科过往的筹备时间表，再加上上方的一些共识写一个流程写出来：

• D-Day：提名开始
• D+3：候选人如不合条件则重新开始
• D+7：选举设置（导入名单、votewiki改为中文）
• D+10：投票期（发垃圾信息）
• D+24：投票结束（改回其他语言、点票）

此外尚有数点：

• 本次投票以一人为限，以最先得到提名而且合符投票过程要求者的优先进行选举，其他的押后至下一次；
• 候选人应清楚说明是否参选界面管理员，如需要选票上应该另有一列；
• 选举的关键日期应该预先决定以方便安排投票。

大概是这样。Ghren🐦🕖 2022年2月14日 (一) 11:32 (UTC)

RfA已经不能兼RfIA，其余支持。 ——魔琴 [ 留言 贡献 ] 2022年2月14日 (一) 13:10 (UTC)

已经准备好投票页面，细节待填。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年2月14日 (一) 15:04 (UTC)

@Ericliu1912：现在依然以提出问题为宜。假如基金会对CU的要求是14天投票，其实管理另外再以七天制并不好。假如担心过长的投票期使提名人辛苦的话可以另设冷静期。Ghren🐦🕐 2022年2月15日 (二) 05:20 (UTC)

问题是基金会上次发了那则讯息以后就一点影子都没有，不知道他们要做什么。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年2月15日 (二) 06:30 (UTC)

基金会是积极不干预政策吧？但是本身Rfa其实本身都没有太多细节可以安排吧。--Ghren🐦🕒 2022年2月15日 (二) 07:19 (UTC)

安全投票的话，要不要发通知应该是最紧要的？除此之外要投票投几天，支持率要多少，也要斟酌。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年2月18日 (五) 06:37 (UTC)

支持率按惯例是80%。通知按其他维基做法只要公平即可，但是只为一个维基人选举的发通知有些少拉票的感觉。投票似乎共识为14天。--Ghren🐦🕛 2022年2月18日 (五) 16:28 (UTC)

• 顺带一说，建议提早完结发问期，让参选者在最后一天有足够时间回答问题。--Temp3600（留言） 2022年2月22日 (二) 14:00 (UTC)

  这样的话将发问期可能规定在20天，然后参选者可以慢慢答就好了。或者再缩短点也可以。--Ghren🐦🕗 2022年2月24日 (四) 12:32 (UTC)

---

那暂定提问期为21日，留三日让候选人回答？—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年2月24日 (四) 13:05 (UTC)

21天会不会过长了？我担心累死候选人了。我没什么所谓，毕竟回答与不是候选人的自由。--Ghren🐦🕘 2022年2月24日 (四) 13:14 (UTC)

@BlackShadowG@SCP-2000@Ericliu1912@Temp3600@AT。对于提问日数有什么看法？--Ghren🐦🕐 2022年2月25日 (五) 05:40 (UTC)

那再缩短总时程，同时削减讨论与提问时间？我记得之前不少人支持三周方案之类的。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年2月25日 (五) 10:49 (UTC)

我认为太长，14天投票+讨论就好。--AT 2022年2月26日 (六) 05:38 (UTC)

这样？—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年2月26日 (六) 06:58 (UTC)

对。--AT 2022年2月26日 (六) 08:20 (UTC)

慢著，提问期可以再缩短些，投票期再延长点。例如5+10。--AT 2022年2月26日 (六) 08:21 (UTC)

这里或许应该定义一下“提问”。在既有问题“之上”追问是否算是提问？如果追问也算是提问，那提问期可能要拉长一点。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年2月26日 (六) 09:24 (UTC)

为什么要减少投票时间？这样的话又会有人投诉为什么不延长投票时间之类的话了，而且和CU和其他站的习惯也不一致，我看不到有很大动机去做。--Ghren🐦🕓 2022年2月26日 (六) 09:55 (UTC)

那要视乎什么时候回答提问。另外，不能提问和投票均同时是14天吗？--AT 2022年2月26日 (六) 10:24 (UTC)

将图2的版本改成14天就可以达成你的需要吧。--Ghren🐦🕖 2022年2月26日 (六) 11:05 (UTC)

另外我记得1233不知道在那个tg群说只少要一周的时间，不能再缩了。--Ghren🐦🕖 2022年2月26日 (六) 11:12 (UTC)

这是在临时提出来的情况下吧，不是说要选定一段期间举行选举了吗？—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年2月26日 (六) 11:46 (UTC)

我不敢肯定，但是时间越长总是越好的。@1233--Ghren🐦🕘 2022年2月26日 (六) 13:05 (UTC)

如果不选定一段时间举行选举，以上全部方案都难以确保能够施行。我自己也拟过一堆方案，想了半天，还是跨不过这个坎。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年2月26日 (六) 16:25 (UTC)

这样的话其实现在就可以去监管员布告板找人了。反正有个固定日期定了出来，之后到D Day的时候填个人名就可以了。投票开始和投票讨论时间其实不会差得很远吧。--Ghren🐦🕛 2022年2月26日 (六) 16:45 (UTC)

我呼吁社群关注限制RfA提问的提案，否则提问时间的制定总会在“不能及时知道”和“候选人负担太重”之间弹来弹去。 ——魔琴 [ 留言 贡献 ] 2022年2月26日 (六) 15:25 (UTC)

本讨论章节会维持开放，暂时不按最后意见发表时间存档。欲让机器人存档，请移除本模板。留言请置于本模板上方。

提议明确Wikipedia:格式手册/旗帜

一、Wikipedia:格式手册/旗帜#旗帜图案不用于强调国籍目的和Wikipedia:格式手册/旗帜#有利于读者阅读，而非装饰用途的规定对信息框是否有效。目前普遍存在信息框国家用国旗（甚至连清朝都有旗帜），党派用党旗（比如驴象代表民主共和两党），美国总统前面要加个，还有各种军衔、将星，电影产地要加{{美国电影}}{{英国电影}}{{日本电影}}；

二、上面举的例子如、军衔、{{美国电影}}{{英国电影}}{{日本电影}}这些是否应该视为旗帷，因为有用户明确主张美国是国旗模板，但 美国不是国旗模板，

三、个人认为如果确定国旗可以在信息框使用，宗教旗帜、州旗、市旗、家族盾徽、党旗、军衔、国玺都没有理由限制，那么Wikipedia:格式手册/旗帜#不要使用太多的旗帜如何裁量，多少算“太多”？

我个人立场认为应该对信息框使用旗帜设限，除非能证明加个旗帜不止“装饰用途”，不会起“强调国籍”的效果，否则就不应该加。汉语读者不可能看到“国籍：美国”后不知道是美国，要看到“国籍：美国”才知道，读者也不会看到“民主党”不知道是民主党，要在前面加头动物才知道。电影“产地：美国”自然就说明是美国电影，“产地： 美国”除了装饰、转移读者注意力实在想不出还有什么作用。--7（留言） 2022年1月11日 (二) 09:22 (UTC)

• 维基百科:格式手册/旗帜/英文维基百科版本可供参考，英文版是几乎完全禁止旗帜的使用，但这部分在中维没有通过。——BlackShadowG（留言） 2022年1月11日 (二) 11:19 (UTC)

我建议内链链接的不是国家的（如“ 美国”）就不要留旗帜了。 ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月11日 (二) 12:33 (UTC)

美国总统那个真的过分了，还妥妥的地域中心。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年1月11日 (二) 13:39 (UTC)

@BlackShadowG：中文版Wikipedia:格式手册/旗帜采用了英维指引的理论；而按英文维基的理论，自然会导出Wikipedia:格式手册/旗帜/英文维基百科版本中的具体做法。中维把具体规则砍掉，但又不拿出其他理论，可不就碰到Po主说的问题了。

我的建议是旗帜表达额外意义，且有利于排版时，可以考虑加入——

• 比如“ 莫·法拉赫”表示“代表英国队参赛的莫·法拉赫”，“ 乔治·克列孟梭”表示“代表法国参战的乔治·克列孟梭”。而且相对于地区名称参差不齐，战争等信息框罗列多个项目时，使用旗帜的确更美观且避免过长换行。（想象一下World War I infobox，下方“指挥官与领导者”处将旗帜替换为汉字，这样就能看出旗帜的优点）
• 但是一般的公司/人物信息框，所有栏目全是文字，偏偏地区这个信息搞特殊非要加图像。而且公司地理位置坐落于美国，不表示公司代表美国开的。这种我认为是属于滥用旗帜了。

以上看法和Wikipedia:格式手册/旗帜/英文维基百科版本相同。我也认为Wikipedia:格式手册/旗帜/英文维基百科版本至少 字面上符合中文版指引Wikipedia:格式手册/旗帜的精神。当然，我知道“人物/公司信息框禁止加旗帜”的做法不符合目前惯例。但这是因为加图标真的利大于弊，还是纯粹尊重现实，这点还是希望能有明确说明。--洛普利宁 2022年1月11日 (二) 13:46 (UTC)

我认为加图标利大于弊，不过明确了地区的列表条目，如美国总统列表，可考虑限制。--驻军（留言） 2022年1月15日 (六) 04:32 (UTC)

@驻军：中文维基的WP:FLAG基本是参考英文维基制定的。同样的理论，英文维基的解读结果是弊大于利。所以中文维基如果认为利大于弊，是有其他理论，还是同一理论有相异的解读方式？--洛普利宁 2022年1月15日 (六) 15:03 (UTC)

英维没有{{美国电影}}{{法国电影}}这些电影产地模板，难道中维就一定要等同英维，拿掉电影产地模板？——驻军（留言） 2022年1月15日 (六) 04:32 (UTC)

@Jarodalien：我认为，在infobox中的“产地”“国籍”中，使用{{美国}}，应当被允许。但是在“产地”中使用{{美国电影产地}}，便不应当了，效果完全与国家模板相同。

关于何种内容属于滥用旗帜，我的观点如下。1.正文中不应当有旗帜：吸引读者注意力，有失中立。2.表格（包括信息框）可以有旗帜，只要不影响排版：上面那个美国总统，肯定得缩小点用，不然一是不美观，二是有失中立。

同时，旗帜内容、显示文本和内链应当一致，不能出现 清朝。

@Lopullinen：对于您“代表英国队参赛的莫·法拉赫”的用法，我不敢苟同。请问如果我打上“Christian Kouamé”，而且不给内链，请问读者能辨识出来吗？（Wikipedia:格式手册/旗帜#与国家名称一同使用）不要去查了，是科特迪瓦。我认为您提到的情况，应当另开一栏表国籍。而在旗帜上加内链的做法，对于触屏、打印都不友好，不建议这样做。

而您所询问的“所有栏目全是文字，偏偏地区这个信息搞特殊非要加图像”，翻了一下存档（Wikipedia_talk:格式手册/旗帜#调适案A），发现似乎是因为历来讨论均未得出共识，于是提案为正式指引时删去了相关内容，于是编者就按照惯例执行了。--落花有意12138 _{论 回复请ping我} 2022年1月17日 (一) 07:40 (UTC)

@落花有意12138：我的意思就是在Wikipedia:格式手册/旗帜#与国家名称一同使用的前提下，使用 Christian Kouamé。

倒是一般infobox中的“产地”“国籍”中或类似信息（比如上村雅之的两个旗帜），我认为没什么必要。我在上面说了旗帜的两个作用，表达意义和有利排版，但这条目并不具备。一方面如您所说，读者根据文字而非旗帜判断地区，此处旗帜没用表达意义的功能。另一方面，这些条目不需要用图示代替文字排版；反而是两个图标让信息框更加突兀（我认为他就职于任天堂的信息更加重要，总不能在“任天堂统合开发本部顾问”前面加任天堂的Logo吧）。--洛普利宁 2022年1月17日 (一) 07:56 (UTC)

@Lopullinen：1.我坚持对于不常有人认识的旗帜，距名称和旗帜同时出现的地方相隔较远使用时，恒带名称（此处“相隔较远”指的是5行以上）。真的有人会把整个大表格看完，并记得每个提到的旗帜的意义吗？对于那种需要折叠或者单立页面的大表格，用处似乎只是在需要时查询特定的一行或者列，甚至一个单元格，此时仅仅给出旗帜，让读者自己去找，就不方便了。--落花有意12138 _{论 回复请ping我} 2022年1月17日 (一) 08:11 (UTC)

@落花有意12138我的意思是，像国际运动会比赛、战役一类的条目，人物是代表地区的。比如在统计奖牌时，你要注明运动员代表科特迪瓦，而不是扔个名字上去。

直接用文字不好看：

• （科特迪瓦）Christian Kouamé
• （美国）XXXXXXXXXXX
• （特立尼达和多巴哥）YYYYYYYYYYYYYYY
• ……

所以用图标代替文字排版（这里的图标有表意作用）：

• Christian Kouamé
• XXXXXXXXXXX
• YYYYYYYYYYYYYYY
• ……

而图示需要图例，也就是之前图标要和文字出现一次：

• 科特迪瓦
• 美国
• 特立尼达和多巴哥
• ……

此处图标和文字并列，主要意义是图例而非表意（总不能说美国代表美国）。如果上面不用图标，这里也不用加。

虽然指引总基调是不鼓励图标，但上面例子都是连续一串图标+文字，有对齐名字的优势，这就有让使用图标有了豁免理由。当然，我不是说必须用图标，全换成文字也没有问题。

Template:World War I infobox是把大量图标集体压到最底下的，这种也OK。但人物信息框其他栏目大串文字，偏偏一两个图标刷存在感，而且还说不出要用的理由——这种才是问题。--洛普利宁 2022年1月17日 (一) 08:37 (UTC)

@Lopullinen：1.您说的有道理，但是在我上述的使用场景中，读者会知道这个图例在哪里吗？如果可以订立规范，使之更加明显、易找，最好放在表格开头，单立标题，就好了。

2.我同意您的观点，大片文字夹带少数图标，有失中立。但考虑到历来讨论均未有结果，如果阁下想要写入指引，请另起讨论。

另：您对此发言的讨论我将在今晚8点以后或者明天回复——落花有意12138 _{论 回复请ping我} 2022年1月17日 (一) 08:50 (UTC)

WP:FLAG是参考英维制定的，除非社群明确表示否决，否则自然会解读出和英维一样，不鼓励使用图标的结论。体育类条目使用图标，是因为找到了其他的理由。一般信息框如果不找出理由，就会不断有人提出和Po主一样，援引现行WP:FLAG提出问题。这是我想说明的。实际上这不是个例，中维不少方针指引都是从英维引入，然后切掉一块又不提出新的理念，结果造成方针理念和实际执行冲突情况。

至于您说的第一点。我的重点是想说图标要有表示意义的作用，而不是和美国一样重复说话。奥运类条目有个模板，效果大概是“ YYYYYYYYYYYYYYY（特立尼达和多巴哥）”，这应该能兼顾图标和文字的平衡。当然，我不编辑体育和战争类条目，具体方式由相关领域编辑确定比较好。--洛普利宁 2022年1月17日 (一) 09:06 (UTC)

战争条目的惯例（至少在英文维基百科）是，在信息框的“参战方”一栏同时列出国名和国旗，随后的“指挥官与领导者”和“兵力”一般只使用国旗。--BlackShadowG（留言） 2022年1月17日 (一) 13:09 (UTC)

@Lopullinen：1.同一提案6个月只讨论一次，加入常年提案定期讨论也可以。方针和指引的通过须要社群有明确共识，因此争议话题不应当被通过。而未通过的提案只要未有禁止，便可以如此做。

2.哪请问如何判定那些旗帜需要和名字一并出现呢？--落花有意12138 _{论 回复请ping我} 2022年1月18日 (二) 14:32 (UTC)

@落花有意12138：我的意思是使用旗帜必须要有理由。谁要在某些地方使用旗帜（和名字一起出现），就请他自行解释亮出旗帜理由。举不出图示使用理由的全禁掉我没有意见。--洛普利宁 2022年1月19日 (三) 12:36 (UTC)

@Lopullinen：方针应当规定至少2种的合法情况，然后根据常识允许合理性等同的情况。--落花有意12138 _{论 回复请ping我} 2022年1月29日 (六) 08:50 (UTC)

“两种合法情况”是指不符合“Wikipedia:格式手册/旗帜#旗帜图案不用于强调国籍目的和Wikipedia:格式手册/旗帜#有利于读者阅读，而非装饰用途”还是符合？符合的话暂时还没有理由限制，不符合的话那要例外就意味着推翻上面两条总纲。--7（留言） 2022年2月1日 (二) 08:56 (UTC)

图例也需要清晰可辨啊，你看看这些旗帜：

• 斯洛文尼亚
• 斯洛伐克
• 荷兰
• 卢森堡
• 印度尼西亚
• 摩纳哥
• 罗马尼亚
• 乍得
• 澳大利亚
• 新西兰

 ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月17日 (一) 08:59 (UTC)

还有需要注意的是在信息框中大量使用国旗，其实我不太赞同英文维基百科完全禁止在人物信息框（{{Infobox person}}）中使用国旗，但看到中维某些传记条目，一名几乎没有海外活动的人，信息框中出生地点、逝世地点、国籍、居住地（或墓地）几个字段挂着一副一模一样的国旗，这都不是用于强调国籍目的我还真不信。--BlackShadowG（留言） 2022年1月17日 (一) 13:04 (UTC)

那么是否可以在上述几个字段如果相同时，限制只使用一次旗帜，或者出生逝世均不使用旗帜。--落花有意12138 _{论 回复请ping我} 2022年1月18日 (二) 14:35 (UTC)

支持沿用英维的规定，人物Infobox不应使用国旗。正文中更不应该使用国旗。--菲菇＠维基食用菌协会 2022年1月17日 (一) 20:06 (UTC)

我想说，这恐怕不是什么“人物Infobox”的问题，不用旗帜的核心思想在于“避免花哨华丽”，避免任何方面内容显得比其他内容更重要进而转移读者注意力。常见国家、地区、度量衡之类连内链都不应该加也是同样理由。如果因为是国家就有理由使用旗帜代表，但又凭什么认定宗教、党派图案不行，进而又凭什么说州旗市旗不行？各种旗帜、徽章、符号图案早已变成装饰品，根本没有提供任何额外信息，小小的图案又看不清楚、难以分辨（比如上面魔琴举例），来个极端点的，谁要是在X总统后代的条目给“父母”栏加上：父亲格罗弗·克利夫兰，岂不是都要赞赏一下用户的想象力？--7（留言） 2022年1月18日 (二) 10:48 (UTC)

作为Wikipedia:格式手册/旗帜的原初译者，我当然是全盘同意英维在旗帜徽章符号上的使用主张。只是人物infobox是此前多年来反对意见最为集中的地方，我当然要强调这点——国旗根本就不应该用在出生、死亡地点来暗示一个人的国籍。至于“避免花哨华丽”，我以为这已经是一个共识了（“旗帜图案应对读者的理解有用处，而非仅作装饰之用”），现在的问题多在于执行上。--菲菇＠维基食用菌协会 2022年1月26日 (三) 04:18 (UTC)

正文目前本就不能使用旗帜。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年1月18日 (二) 10:52 (UTC)

由于上述讨论，我想到如果字段内容精确到一级以下的行政单位，那么如何标识旗帜？如何加内链？

如果加这个行政单位的地方旗帜，那么对于没有的怎么办？如果不加旗帜，那么如何与其他的统一？--落花有意12138 _{论 回复请ping我} 2022年1月18日 (二) 14:42 (UTC)

表格入面像2021年王者荣耀挑战者杯的使用也要提一下。--Ghren🐦🕛 2022年1月18日 (二) 16:57 (UTC)

我作为Wikipedia:格式手册/旗帜现版本的提出者，我有必要就现状进行解说。我的原提案大体上是与enwiki一致的，但我收到相当的意见反对限制旗帜在Infobox的使用，因此改为现版本并通过。我不反对Jarodalien的提议或与enwiki看齐，也很欢迎如此提案，但我怀疑社群是否真的能就此达致共识。Sanmosa _A-DWY³ 2022年1月23日 (日) 04:27 (UTC)

如果“人物infobox”还有争议，那么大家能否认同“非人物infobox”不用国旗呢？比如，地址、党旗、格罗弗·克利夫兰，还有上面所谓的“电影产地模板”？我提议删除所有电影产地模板。非要用国旗的就直接美国，不要拿什么 美国来做文字游戏。--7（留言） 2022年2月1日 (二) 08:56 (UTC)

我觉得还有一点可以探讨的是Navbox用国旗模板到底是不是有问题的，我提案当时的讨论中也有人提过这点。如果可行的话，我很建议把Navbox也一同管制。Sanmosa _A-DWY³ 2022年2月1日 (二) 12:29 (UTC)

@Jarodalien：要提醒的一点是enwiki存在国歌Infobox使用国旗模板的例子，例如en:State Anthem of the Soviet Union。--Sanmosa _A-DWY³ 2022年2月1日 (二) 12:33 (UTC)

要按中维的习惯，List of successors那里也会出现一堆flag……--洛普利宁 2022年2月1日 (二) 15:44 (UTC)

意见征集

1. Wikipedia:格式手册/旗帜下各项规定对信息框和正文同样适用，除非有其他明确规则（如体育、军事类），否则信息框和正文表格都不能使用国旗；

• (＋)支持。--7（留言） 2022年2月9日 (三) 02:56 (UTC)

2. Wikipedia:格式手册/旗帜下各项规定只对正文适用，对信息框不适用，信息框和正文表格无论是哪一类条目不限制使用国旗，即人物出生地、死亡地、下葬地均可加国旗、州旗、市旗，党派可加党派，官职可加，宗教信仰可加信仰旗帜，出版作品产地、发行地可加国旗、州旗、市旗等。

本着一视同仁，避免一碗水端不平的情况，以上仅列出一律适用和一律不适用两大类。如果大家有自认不存在争议的方案还请提供。--7（留言） 2022年2月9日 (三) 02:56 (UTC)

支持维持现状。一律适用和一律不适用等“一刀切”方案都不尽理想。不过我个人对于国旗以外的各类旗帜都是比较不赞同使用的。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年2月9日 (三) 05:25 (UTC)

现状不过就是打编辑战而已。每个人看法不同，你支持用国旗，现在也有实例支持用党旗、官职旗、家族纹章，要么就全部允许。所谓的维持现状只不过假装没有任何问题和争议。--7（留言） 2022年2月9日 (三) 06:44 (UTC)

只要先到先得原则得到实践就没有问题。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年2月9日 (三) 09:38 (UTC)

先到先得意思是说，创建条目的那个人放了国旗，这个条目就可以放，没放国旗就不放？不然在这里怎么成立？而且既然实际效果是不限制，那就请表决支持不限制。--7（留言） 2022年2月9日 (三) 11:20 (UTC)

有无明文规定可确实是有差别的。现阶段我不支持在格式手册写入上述任一方案。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年2月10日 (四) 12:24 (UTC)

对于我言，在可以在表格或者资料框中使用旗帜以保持齐整、缩短字数和读者看得懂作为原则。比如说今天的你的名字的条目，以旗帜列出大中华地区代理的书籍，名称是比较合理的，因为保持了统一的大小，和减少了字数的使用。但是详列各国上映时间就过火了，因为读者根本不太能记得这个国旗。--Ghren🐦🕖 2022年2月9日 (三) 11:01 (UTC)

根据什么判断“读者看得懂”，每个读者看得懂的国旗可能不一样吧，而且很多旗帜相似，只要允许用就自然会全部用，不可能以任何国家“看不懂”为由拒绝，要觉得可以就请在上面表决不限制。--7（留言） 2022年2月9日 (三) 11:20 (UTC)

我倾向于支持信息框中涉及地点的时候才允许挂国旗。 ——魔琴 [ 留言 贡献 ] 2022年2月10日 (四) 12:59 (UTC)

请求维基追加新功能让用户自行选择是否显示国旗，--北极企鹅观赏团（留言） 2022年2月11日 (五) 12:10 (UTC)

1案或维持现状我都不反对。2是比1宽松的情形，我不支持任何放宽的提案。Sanmosa _A-DWY³ 2022年2月12日 (六) 04:16 (UTC)

较支持方案1。 --Loving You Is A Losing Game 2022年2月12日 (六) 15:41 (UTC)

倾向支持信息框涉及国家政权之时仍用国旗，地点反而不应该用（尤其为有领土争议之处）。--路西法人☆ 2022年2月15日 (二) 03:26 (UTC)

支持在信息库中适度使用旗帜，如用旗帜标注国家。(－)反对一刀切（禁止正文和信息框使用旗帜或无限制地使用旗帜）。--驻军（留言） 2022年2月16日 (三) 23:25 (UTC)

既然无法达成共识，那烦请社群明确以下不可调和的矛盾

上面的驻军用户坚持要在信息框使用电影产地模板，而我是坚持不使用的。这里我无意再讨论是非问题，只想明确一点：电影产地模板是不是一定要使用？谁能决定、拍板是否使用？出现这种无法调和的争议时到底是不是永远都只能按3RR处理？

从上面用户意见来看，许多用户都认为可以用国旗代表国家，那么在此建议：

一、废除Wikipedia:格式手册/旗帜下子项Wikipedia:格式手册/旗帜#旗帜图案不用于强调国籍目的，和Wikipedia:格式手册/旗帜#有利于读者阅读，而非装饰用途。

二、不废除但修改内容，“维基百科不是国家或民族自豪感的宣传工具。旗帜在视觉上引人注目，故在某事物旁放置国旗会让该事物的国家性或地区性看起来比其他属性更为重要”改成“用维基百科宣传国家或民族自豪感是可以接受的。旗帜在视觉上引人注目，可以放置国旗让国家或地区看起来比其他项目更重要”；“旗帜与其他图标经常被误用作装饰用途”改为“可以使用旗帜与其他图标作为装饰用途”。子标题“旗帜图案不用于强调国籍目的”改成“旗帜图案可用于强调国籍目的”，“有利于读者阅读，也可用于装饰用途”。“Wikipedia:格式手册/旗帜#不要使用太多的旗帜”内容改成“国旗使用次数不限制，其他旗帜使用不要超过五千次”。

公示前表决。--7（留言） 2022年2月20日 (日) 04:41 (UTC)

就先不提整个提案本身有多刻意，“五千次”的标准是哪里来的？—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年2月26日 (六) 16:28 (UTC)

@Jarodalien：您夸张了。我的建议条文如下：

提议条文 何时适合在条目中使用旗帜和徽章等图标？ 使用时机 Y 合适的做法 N 不当的做法 Y 用于列表、表格和信息框中：列表和表格可被用作并列出多个国家、地区、政权以至政党、组织等的情事，而信息框则是总结性的提纲列表，用作列出所述主题的重点。在列表、表格和信息框中恰当地使用旗帜或徽章等图标有助于读者快速浏览重点和识别他们寻找的内容。 N 用于条目正文：旗帜和图标仅应在列表、表格与信息框模板中，而不应该使用于条目正文的段落中。图标在视觉上引人注目，在条目正文中使用旗帜或徽章等图标会将人物公民身份、国籍、国家地区政权或主权或政治身份的重要性强调于其他内文文字之上，这会破坏全文的连贯性。 Y 用于表示政权和国籍：国家或地区旗帜图标可用于表述国家、地区或政权本身，例如中华人民共和国、香港（或香港特别行政区）、中华民国、美国等情况。此外，国家或地区旗帜也可用于在列表、表格和信息框表述人物的国籍，以及人物或组织所代表的国家。另，应注意遵守两岸四地用语指引和朝鲜半岛用语指引。 N 用于表达地理位置：旗帜图标用作表述地理区域可能与维基百科不是地方政治的宣传工具的原则相违背，尤其在存在领土主权争议的地区。例如，五星红旗是中华人民共和国国旗，但不是中国大陆的旗帜，在表述中国大陆的时候使用五星红旗并不妥当，中国大陆跟中华人民共和国不是同义词。同理，台湾和中华民国亦非同义词，表述台湾时使用青天白日满地红旗亦是不合适的做法。 N 在超出原有意义的情况下使用：旗帜和徽章等图标代表某特定实体，在没有适合旗帜使用的时候也不应套用于其他事物身上。例如，国家或地区旗帜用作表述非代表该国家或地区的个人或组织不妥当，例如英文维基百科某足球运动员条目的历史版本中，将国旗标记在非代表国家的球队前，会使旗帜图标偏离原有意义；条目中反而没有在国家代表队前标记国旗，在此使用旗帜图标的情况下属于本末倒置；又例如，我们不应滥用联合国旗帜以代表全世界，因为这不是正确使用国际组织旗帜的方法。 Y 在有利于读者阅读的情况下使用：仅应在有利于读者阅读的情况下使用旗帜或徽章等图标，例如在多个人物或组织的列表中使用旗帜或徽章以供识别不同的国籍或政党等信息，或在单独一个人的情况下用以表达其国籍或政党等信息。例如，在选举结果列表中，使用图标可供识别参选人所属不同政党；或在政治人物条目中，以旗帜和徽章表述人物国籍和所属政党。 N 用作装饰用途：旗帜或徽章等图标经常被误用作装饰用途。例如在“美国棒球代表队”条目2015年的版本的成员名单中，虽然符合了在列表中使用的条件，但列表中所有人物项目的国籍均一样，实际上无法达到在列表中添加旗帜该有协助识别不同项目之间的差别的作用。故此，不应在无助达到有利于读者阅读的情况下使用旗帜或徽章等图标。 易读、可用与可辨识 ...

这个版本只改了一小部分，先看看？--路西法人𖤐 2022年2月28日 (一) 06:06 (UTC)

噢还有，这个版本简单而言就是使 中国大陆和 台湾不应被使用--路西法人𖤐 2022年2月28日 (一) 07:43 (UTC)

Zh.WP checkuser re-introduction／重新引入中文维基百科用户查核权限

原标题为：Zh.WP checkuser re-introduction/重新导入中文维基用户查核权限

The members of the local Chinese language Wikipedia community and the Stewards, who currently provide CU support to Zh.WP, have indicated to the Foundation that it would be desirable to explore possibilities of reinstating local CheckUser privileges on Chinese language Wikipedia. These rights were revoked from the local community due to security concerns in 2018.

中文维基百科本地社群成员以及替中文维基百科提供用户查核支援的监管员已向维基媒体基金会反映希望恢复中文维基百科的用户查核权限。此权限基于安全考量，于2018年自本地社群移除。

As a Foundation, we strongly endorse community self-governance wherever feasible. We also realize that each community has unique challenges that require authentic approaches that tackle them. In this spirit, we would like to state that the Foundation would support reinstating local CU privileges if Zh.WP meets two conditions.

作为基金会，我们在许可范围内强力支持社群自治；我们也同样理解不同的社群有其特有的挑战，亦需要用独特的方式来应对。本着此精神，我们想声明：若中文维基百科可以满足下述两个条件，基金会将会支持恢复本地社群之用户查核权限。

First, that the local Chinese language Wikipedia community offer their commitment to uphold the global aspects that all communities with local CU privileges uphold. A critical element is policy compliance. Currently, all communities with local CheckUser privileges are required to adhere to binding policies governing the recruitment of CheckUsers and the use of the tool. The potentially elected Zh.WPs CU would need to strictly uphold the Compliance with the CheckUser Policy and Compliance with the Access to Non-Public Information Policy, including the NDA policy update 2021. The local community should in turn respect these instruments.

首先，中文维基百科本地社群必须承诺维护所有拥有本地用户查核权限之社群的通用认知。其中一个关键要素为政策规范合规性。目前，所有拥有本地用户查核权限之社群都被要求要遵守有关用户查核者的招募及使用工具之约束性政策。未来中文维基百科中可能当选为用户查核员之用户必须恪守用户查核政策与非公开个人资料存取政策，包含2021年更新之保密协议。本地社群必须尊重这些政策文件。

Secondly, the Foundation is aware that the Chinese language Wikipedia continues to have long-standing internal trust challenges unique to the local community. We are aware that the local community is confronting noteable difficulties in local collaboration both on the Chinese mainland and internationally. As a Foundation, we undertake to support the re-introduction of the local CU rights if:

再来，基金会已认知到中文维基百科持续面临当地社群独有的长期内部信任挑战。我们理解本地社群在本地合作／协作上，不论是与中国大陆还是跟国际社群都窒碍难行。作为基金会，我们承诺在满足以下情况下支持重新引入本地用户查核权限:

1. Elections: All Zh.WP elections for CheckUser are conducted through SecurePoll elections (two weeks), with Steward scrutiny support. Doing so would provide greater safety to both candidates and voters. Further to this, the appointment tenure for CU user rights holders on Zh.WP to be two calendar years, at the end of which re-election of CheckUsers aiming to extend their tenure via SecurePoll will be required. Doing so would enable the local community, which does not have a NDA-signing ArbCom providing added accountability for CUs, to assess whether they still have sufficient trust in their local CUs after a meaningful period of time. There will be a recall mechanism for CUs. In it, voting-eligible users can safely register their voice in case they have lost confidence in a CU in-between elections. Once registered, a concern will be valid for a year or until the next re-election. 25 valid concerns related to a CU at the same time will trigger a recall election within two months, unless said CU decides not to run for re-election. Two years overall tenure in-between regular elections is in-line with long-standing re-election practices for CUs on German and Portuguese language Wikipedias, two other large communities with local CUs but without a NDA-signing ArbComs.
2. Training: All successful Zh.WP CU candidates to be trained in CU community best practices prior to the user rights change granting them CU rights. Doing so would ensure alignment of Zh.WP CU practices with the global community.
3. Audits: The Foundation will regularly audit CU activity on Zh.WP for at least a year; including an evaluation after a year whether or not to continue such audits. A practical way for that is keeping the current community consensus-based requests for checks. The community would comment on requests, which can then be audited for problematic users stacking against a certain user.

1. 选举：所有中文维基百科之用户查核员选举必须通过SecurePoll秘密投票，每次选举为期两周，选举期间必须有监管员支援监票，这样做将有助于提供候选人及选举人更大的安全保护。此外，当选之用户查核员任期为两年，在任期结束后必须要再度重新参与选举，通过秘密投票来延长任期。这样做将有助于社群，在缺乏签署保密协议之仲裁委员会确保用户查核员负责任的情况下，有一段时间去查看和评估他们对于当地的用户查核员是否有足够的信任。用户查核权限将有除权机制：有人事任免投票资格的用户可以安全地提出自己的质疑，此质疑有效期为一年，或是到下次用户查核员选举之前；如果有超过25人之质疑关切，就会在两个月内触发罢免，除非该查核员选择不竞选连任。上述任期制度已由德语、葡萄牙语两大有本地用户查核权限但没有签署保密协议的仲裁委员会的社群采用。
2. 训练：在授予权限之前，所有中文维基用户查核员候选人都将会接受用户查核员社群的培训，以确保中文维基上的用户查核实践与全球社群一致。
3. 稽核：基金会将会定期稽核中文维基之用户查核活动至少一年，此举包含一年后是不是要继续持续这样的稽核机制等。目前针对稽核有一个实用的方式：持续目前基于社群共识作出的查核请求；社群将对这些请求发表评论，令基金会可以稽核这些评论，以便寻找针对特定用户的问题用户们。

Finally, the Foundation commits to facilitating the functionary-guided creation of a CU self-learning module, available in Chinese and English in the Wikimedia LMS in 2022. This will document global community best practices for the tool and its appropriate use in a local community context.

最后，基金会承诺会促成在行政人员（functionaries）指导下创建一个用户查核权限自我学习模块，其中英双语版本将于2022年在维基媒体LMS供查阅，此举将把全球社群在使用该工具的经验以及使用方式以当地社群语言妥善记录。

WMFOffice（留言） 2022年1月13日 (四) 20:38 (UTC)

• 微调翻译。（没调整很多所以一些语气生硬或隐含错误之类的实在帮不上忙）—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年1月13日 (四) 22:20 (UTC)
• 我搬回内地了，不然还真的会考虑一下申请这个工作。Itcfangye（留言） 2022年1月14日 (五) 04:11 (UTC)

“当选之用户查核员任期为两年，在任期结束后必须要再度重新参与选举，通过秘密投票来延长任期....”WMF钦点了这个方法,那我认为可以在sysop上长远使用啊?--Wiki emoji | 😷🅔🅜🅞🅙🅘🅦🅘🅚🅘😷 _{祝百毒不侵～} 2022年1月14日 (五) 08:30 (UTC)

不同意管理员任期制。另外我甚至反过来担心这样选用户查核员会不会难产。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年1月14日 (五) 10:04 (UTC)

难产的话，若有要查核就先转交全域监管员？--0906_{（回复请Ping我）} 2022年1月14日 (五) 15:22 (UTC)

是的，如果难产，先转交至监管员。--夏雪若（留言） 2022年1月14日 (五) 15:28 (UTC)

难产也要。这是御旨。--Wiki emoji | 😷🅔🅜🅞🅙🅘🅦🅘🅚🅘😷 _{祝百毒不侵～} 2022年1月15日 (六) 05:51 (UTC)

我认为SRCU还有必要继续存在，鉴于社群目前的互信情况。不仅是CU员难产的问题，即使能选出CU员，社群对CU员的信任程度又有多少？到时候涉及老用户的查核可能还得监管员帮忙。另外我强烈建议CU的选举在管理员的安全投票试行一段时间后再举行。 ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月14日 (五) 15:34 (UTC)

• 我支持CU员任期制，此工作的胜任难度比管理员高得多，CU相关工作是本地管理工作里最难的。按目前社群的互信情况，CU员真的难产。--Lanwi1(留言) 2022年1月15日 (六) 04:28 (UTC)

  话说上次是谁把cu数据泄露给中华爱国阵线的？--中文维基百科20021024（留言） 2022年1月15日 (六) 06:30 (UTC)

  我也不知道是谁泄露的，泄露的动机也有可能包括陷害他人。--Lanwi1(留言) 2022年1月15日 (六) 15:07 (UTC)

我想请问训练将在哪进行，以及训练一名用户查核员需要多长时间。--BlackShadowG（留言） 2022年1月17日 (一) 00:21 (UTC)

• 好家伙，比监督权严格多了。我的建议是监管员累死前大可不必接受这么勉强的本地查核回归，咱们大可多“不知好歹”一会。重建社区对CU的信任都已经很难了，还要来几尊基金会大佛盯着而且一年起步将来再议，这查核权属实烫手山芋。--南冥大鹏👈把我批判一番出偏差要负责👊微小的工作历史的进程✌ 2022年1月22日 (六) 02:06 (UTC)

对于重新引入不报希望，即便引入也是CU员难产。桐生ここ★[讨论] 2022年1月18日 (二) 05:11 (UTC)

• 如果已经明确计划好要恢复查核员，那对于无法签署NDA的大陆用户应该会造成更大规模的（无论主观或客观）歧视与不公平现象。毕竟曾经出现过

“ 至少3个管理员，说过：把自己的管理员账户给我。但都被我拒绝。我回答：等你们什么时候混成CUer了，再把账户给我。现在CUer才是王道。管理员虽然也重要，但可CUer相比差得远。 ” ——未知用户

这种话，而现在大陆用户连监督员都无法担任。--Yining Chen（留言|签名页） 2022年1月18日 (二) 14:34 (UTC)

基于上方理由，(－)强烈反对引入用户查核员，而且NDA不承认中国大陆的理由也合理无法反驳，不论对于歧视还是安全原因，都应维持现状。桐生ここ★[讨论] 2022年1月18日 (二) 14:46 (UTC)

我反对恢复本地CU权限的理由是大陆用户无法签署NDA以及对港台用户与居住在海外的大陆人的不信任，应该维持现状。--Lanwi1(留言) 2022年1月18日 (二) 14:57 (UTC)

既然这样，我建议自废武功，本地CU不能查有关延伸确认用户的请求，而应转交元维基；本地CU查到有关延伸确认用户的案件，应送报元维基核实。 ——魔琴 [ 留言 贡献 ] 2022年1月19日 (三) 04:19 (UTC)

所谓安全问题不是CU作出虚假结果，而是泄漏非公开数据，比如举报到香港国安处或者FBI，是编者的人身安全问题，即便CU值得信任，但是不能保证CU所在或所属的当局不会强迫CU进行查询，虽然大陆不能签署NDA，但比如香港、澳门实际上也是不安全的，要是排除这三个地方，就是一种歧视，因此不如维持现状。桐生ここ★[讨论]2022年1月19日 (三) 04:38 (UTC)

我觉得目前大概两点疑虑，一点是打击报复，我觉得我的方案可以解决；一点是CU数据的安全性，大陆人不能签NDA可以保证（至少很难被中华人民共和国获得）。另外我很疑惑的一点，为什么排除港澳就是歧视，排除大陆就不是？既然现在港澳还能签NDA，我们就没必要帮WMF担心。如果真的觉得港澳不安全，那就应该跟WMF建议撤销港澳人士的NDA。没有说港澳能签NDA但做CU不安全的道理。 ——魔琴 [ 留言 贡献 ] 2022年1月20日 (四) 04:29 (UTC)

支持合资格且有意向者申请用户查核权限，反对自我矮化主权，现今转交元维基的操作过于繁琐。先前对本地CU的担忧在于中共威胁与WMC渗透，基金会行动后已不是大问题。住所不为第三方所知的大陆用户仍然可以签NDA，而上方讨论中所说的“歧视与不公平现象”并无前例。--Lt2818（留言） 2022年1月19日 (三) 05:21 (UTC)

据我所知，User:Alexander_Misel的住所应该不为第三方所知，然而却有该笔日志（注意此日志发生在WP:OA2021之前，与OA无关）。第二点，只知道担心“中共威胁与WMC渗透”，那我们这些用户要不要担心“█国民主党和F█I威胁与H█U█渗透”？第三点，“歧视与不公平现象”没有前例，但正在发生。建议参考自基金会行动以后站内的几项所谓“决议”的流程。另：怎么看待上方在查核员尚未被废除时真实出现过的言论？只是维基人间“友好的交流”？现在为解决这种现象所做出的唯一努力就是“歧视大陆用户”吗？（可能违反WP:AGF，故自行删除）虽然基金会做出的决定改不了，这一点没错啦；但是还是很想知道类似这种“决定”的支持者是怎样思考问题的。--Yining Chen（留言|签名页） 2022年1月19日 (三) 14:39 (UTC)

具体住址是不知道，但是具体城市他曾经在QQ群公开过，他说那天他所在的城市居民包括他本人在内被全员核酸检测。--中文维基百科20021024（留言） 2022年1月19日 (三) 14:27 (UTC)

我觉得住所不为第三方所知的大陆用户可以签NDA，也有大陆用户完全不愿公开自己的住址。--Lanwi1(留言) 2022年1月19日 (三) 15:43 (UTC)

即使“完全不愿公开自己的住址”，如果参加了任何线下活动，也很可能会有问题。甚至更极端的，在任何社交网站或者Zoom等地方公开了自己的照片，也有问题。更不用说真实身份早就众所周知的用户。--GZWDer（留言） 2022年1月21日 (五) 10:07 (UTC)

个人认为连六扇门都难以找到住所的用户才满足条件。至于上述个案，原因恐怕不止于此。--Lt2818（留言） 2022年1月20日 (四) 03:40 (UTC)

Wikipedia:河北维基人列表显示，该名用户现时住在石家庄。--Alexander Windsor^谈笑风生 2022年1月23日 (日) 07:13 (UTC)

个人意见同Lt2818阁下。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年1月19日 (三) 07:41 (UTC)

除非 User:PMDdeSN 一事明了，否则(－)反对。--广雅 范★ 2022年1月19日 (三) 08:18 (UTC)

那看来泄露CU纪录的事情不止一位，要是CU回归中维的话大家应该做好心理准备。--中文维基百科20021024（留言） 2022年1月19日 (三) 08:36 (UTC)

是什么事？没有了解过。--Tranve (✉) 2022年1月20日 (四) 01:38 (UTC)

@Tranve：Wikipedia:互助客栈/其他/存档/2017年10月#用户查核不得不说的事 --Lt2818（留言） 2022年1月20日 (四) 03:40 (UTC)

(！)意见如果本地重新获得用户查核权的话，可以保留元维基用户查核请求权以处理有争议的本地查核案。--🎋🎍 2022年1月22日 (六) 12:25 (UTC)

有争议的话，找其他本地查核员复核较为合适，亦可找申诉专员。监管员不会有更高权威，君不见三位监管员确认之傀儡都能被抵赖掉。--Lt2818（留言） 2022年1月22日 (六) 14:17 (UTC)

如果要找申诉专员，可能会面临举证难题，而且这难道不是对一些 处于弱势且不精通外语的中国大陆用户 的一种歧视？（除非申诉专员里出现了zh-2用户）--Yichen Ding（留言|主账户） 2022年1月22日 (六) 14:49 (UTC)

就监管员吧，申诉专员处理效率肯定没监管员好，不过可能要先问监管员愿不愿意。照规定来说，监管员不能处理有本地查核员的查核请求。--$\int$（☎） 2022年1月22日 (六) 18:32 (UTC)

个人认为基金会会推动本地CU创建，然后到时监管员就不用管咱的CU请求了。除非有人跟基金会讨论过可不可以维持现状，不然我觉得楼上提的关于CU的问题要面对只是早晚而已。--$\int$（☎） 2022年1月26日 (三) 23:58 (UTC)

基金会没打算解释一些细节么？—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年2月11日 (五) 03:39 (UTC)

包括所谓的除权机制、当选人所接受的培训，以及定期稽核等等，基金会都没有给出足以让本地社群讨论或订立规范的内容。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年2月21日 (一) 12:28 (UTC)

读完了大家的讨论，我的观点也是给中维CU不够安全。原因有二，首先，WMC和中共不是我们唯二要防的信息泄露对象，前面各位点到的其他政权和团体对中维产生的潜在信息泄露威胁也不是空穴来风。其次，在没有办法向内地用户提供CU权限的情况下，也很难平衡不同地区的查核员的比例。除此以外，基金会这次给出的信息太过有限了，不知道该如何应对。Itcfangye（留言） 2022年2月26日 (六) 06:31 (UTC)

1. WMC和中共是特定于中文站点的担忧对象，其他实体或者未见对本地的危害迹象，或者对全域项目有影响（如NSA对维基百科的监控），不见得由监管员代替本地查核员即能消除信息泄露威胁。
2. 未见“平衡不同地区的查核员的比例”之必要性，这与查核工作能否安全有效运行并无关联。

--Lt2818（留言） 2022年2月27日 (日) 13:43 (UTC)

意见同上。另外，wikt:空穴来风。 ——魔琴 [ 留言 贡献 ] 2022年2月27日 (日) 15:20 (UTC)

本讨论章节会维持开放，暂时不按最后意见发表时间存档，直到情况有所进展。欲让机器人存档，请移除本模板。留言请置于本模板上方。

增修标点符号格式手册

建议在标点符号格式手册增修有关示亡号的使用，规范示亡号仅用作在列表中（包括点列式、表格或信息框内）标记当前文字所表述的时间环境下此人已经逝世，例如在长寿节目制作播出期间演员或制作人员逝世，或是奖项追颁。{{金钟奖特别贡献奖}}、{{新闻联播播音员}}属于合理使用示亡号的例子，而{{大紫荆勋章}}的例子就属于滥用。--路西法人☆ 2022年1月14日 (五) 14:29 (UTC)

(＋)赞成，不然迟早会看到全部是示亡号的列表。--Wolfch (留言) 2022年1月15日 (六) 07:00 (UTC)

囧rz……(＋)支持 Wiki emoji | 😷🅔🅜🅞🅙🅘🅦🅘🅚🅘😷 _{祝百毒不侵～} 2022年1月25日 (二) 05:49 (UTC)

内容不可更新的纸媒列表使用示亡号比较常见，而内容可更新的网络列表是否必要使用？人总是要死的。乌拉跨氪 2022年1月17日 (一) 16:47 (UTC)

(＋)支持，甚至我觉得可以完全禁止使用，这个符号本来就不是什么通用符号，再加上维基百科有内部链接，想知道一个人还在不在世用鼠标放到上面不就知道了，点进长寿剧节目条目又不是想看什么“xx医院死亡演员列表”。至于奖项追颁应改为其他脚注符号，* † 之类的，又不是说活着拿奖的人就不能死，这样会产生很多歧义。--Austin Zhang（留言） 2022年1月17日 (一) 19:36 (UTC)

(＋)支持。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年1月25日 (二) 04:33 (UTC)

---

@LuciferianThomas：是否提出正式修订草案并作公示？—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年2月2日 (三) 11:20 (UTC)

(＋)赞成限定使用范围，不然迟早全都是方框。--字节 2022年2月4日 (五) 02:52 (UTC)

(－)反对，反对额外的示亡标识，根本上不加。用连接到条目则可解决，如果对应人名没条目，可以简单补充生亡年份来代替。——Sakamotosan路过围观 | 避免做作，免敬 2022年2月8日 (二) 02:31 (UTC)

格式手册可采“多数禁止，少数不建议”立场表达本站态度。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年2月8日 (二) 11:34 (UTC)

同Eric君顾着搞SPI忘了我提过这个（草--路西法人☆ 2022年2月15日 (二) 03:25 (UTC)

反对在任何条件中使用示亡号，Special:Diff/70179631，founder部分看似符合提案人的要求，但等到其余三位辞世，岂不是founder一栏出现四次示亡号。--寒吉 2022年2月15日 (二) 05:02 (UTC)

创办之时未离世，董事长之位会被取代（不是其独有）。--路西法人☆ 2022年2月16日 (三) 02:21 (UTC)

那我还是一样反对在任何条件中使用示亡号。董事长当然会被取代啊，所以我上头只提“founder部分”，没提董事长。--寒吉 2022年2月16日 (三) 11:41 (UTC)

founder部分不会啊，不就说了“创办之时未离世”吗？--路西法人𖤐 2022年2月18日 (五) 05:57 (UTC)

我的回复有质疑“创办之时未离世”这句话吗？我的看法就是一律禁用示亡号，只是恰巧你在此处提案，我顺便提出Special:Diff/70179631询问founder部分是否符合提案的要求，你回复不符合，而我没质疑这部分啊，我只是回复为何你要回复我没提到的董事长部分而已，且founder部分不符合提案仍不会改变我持一律禁用示亡号的看法。--寒吉 2022年2月19日 (六) 11:42 (UTC)

先说我本人的浅见。我认为在百科全书标示亡号完全没必要。百科全书是要流传千古的，也就是说，总有一天书上所有条目里的所有人名都是死人，那就全都要标示亡号。全都要标就等于全都不标，标了还浪费时间精力。百科全书皆如此，不独维基为然。

可行的用法，就是在实际生活上的用法，也就是事件来临时相关人物已经不在了。例如候选人于竞选活动开始前死亡（美国发生过），影业人员在影片发行前死亡（如英雄本色中的石燕子，不过有疑义）等等。但现在某些维基编辑的用法是看到哪个公众人物死了，就忙不迭把相关条目全翻出来，一个一个替人标示亡号。所以这就涉及定义了：示亡号是用于表示看到条目时人已经不在了，还是表示事件发生时人已经不在了？我认为是后一种，各位呢？这点要列为方针吗？

前面说到疑义，是有的事件发生不止一次。例如英雄本色上映时间各国不同，以何为准？还是就干脆不用标了？

谢谢各位拨冗看我啰唆一堆细节。--以上未签名的留言由2603:8000:500:FB00:5011:1E64:1DB0:C8F1 （讨论）加入。 —此条未加入日期时间的留言是于2022年2月20日 (日) 08:14 (UTC)之前加入的。

• 会否有人于古代条目为所有人标上示亡号?--Temp3600（留言） 2022年2月23日 (三) 14:58 (UTC)

  示亡号不应用于正文，也只应用于“进行中死亡”的情况。理论上是不行。--路西法人𖤐 2022年2月23日 (三) 15:46 (UTC)

对典范条目评选重选的提议

这讨论曾建议本身GA的条目在评FA时可GA重审一次，而我在FA重审中想：FA要求比GA高，如果一曾通过FA评选条目因FA重审而变成非GA、非FA，有一点奇怪（特别是同时曾通过GA及FA评选条目）。在此我提议

现行条文 若条目本身是优良条目，其典范条目评选期间可提出优良条目评选以作重审一次（只限一次）。优良条目评选被提出时，其典范条目评选会被暂停，暂停期间在典范条目评选的投票将会视为无效，但仍可提供意见。而当其优良条目评选结束时： 如条目丧失优良条目资格，其典范条目评选则会被视为无效而结束并进行存档。 如条目保留优良条目资格，其典范条目评选则会被恢复，且结束时间亦会相应延后以补回暂停期间的时间。

提议条文 若条目本身是优良或典范条目，其典范条目评选或重审期间可提出优良条目评选以作重审一次（只限一次）。优良条目评选被提出时，其典范条目评选或重审会被暂停，暂停期间在典范条目评选的投票将会视为无效，但仍可提供意见。而当其优良条目评选结束时： 如条目不符优良条目资格，其典范条目评选或重审则会被视为无效而结束并进行存档。 如条目符合优良条目资格，其典范条目评选或重审则会被恢复，且结束时间亦会相应延后以补回暂停期间的时间。

征求大家意见--Cmsth11126a02（留言） 2022年1月31日 (一) 16:57 (UTC)

的确有些需要重审，我是觉得应该要设优良条目当选到典范条目候选之间的冷却机制，别一上来就直接用典范条目候选，有失公平性（除非曾经是典范条目落伍一段时间以外）！--小跃（捞出记录） 2022年2月3日 (四) 00:06 (UTC)

@小躍：现在已有30天提名冷却期。--Cmsth11126a02（留言） 2022年2月7日 (一) 05:49 (UTC)

邀请曾参与这讨论的人@Z7504、Sanmosa、Cdip150、Cwek、Inufuusen、Opky9407：--Cmsth11126a02（留言） 2022年2月9日 (三) 04:54 (UTC)

(！)意见，这种情况我会建议FA/FL被撤销后可以不须等30天直接提GAC，而不是FAR途中提出GAC。原因是当FAR途中的GAC结果是符合GA、而FAR恢复之后的结果是不符合FA，那么条目是会降为GA还是完全撤销？如果是前者，将导致FAR通过时，处理办法出现不一的情况——有时是完全撤销（如果期间没有GAC）而有时是降为GA（如果期间有GAC），我担心执行上会较易出错；而如果是后者，则GAC又会变得荡然无存。--街燈電箱150號 开箱维修 抄表 检验证明 2022年2月12日 (六) 04:36 (UTC)

---

@Z7504、Sanmosa、Cdip150、Cwek、Inufuusen、Opky9407：考虑街灯电箱意见，我改变原先建议，现建议修改优良条目评选条件中的

现行条文 同一个条目请勿在距上一次优良条目或典范条目评选结束后不满30天内重复提名，否则该提名视为无效。

提议条文 同一个条目请勿在距上一次优良条目或典范条目评选（不包括典范条目重审）结束后不满30天内重复提名，否则该提名视为无效。

因如重审成功，第六条的“若条目本身是典范条目，请勿对其进行优良条目评选”已阻止其被提名优良条目评选/重审。--Cmsth11126a02（留言） 2022年2月13日 (日) 01:37 (UTC)

题头的话，我认为是如果原来是GA，在通过FA评审时失败，应该先回落到GA，而不需要做GA重审，除非之后重新申请GA重审。至于怎样完善相关说明，我的想法如前述。——Sakamotosan路过围观 | 避免做作，免敬 2022年2月16日 (三) 03:50 (UTC)

@cwek：原GA在第一次评FA失败时已会回落到GA，我指的是原GA->评FA成功->重审FA失败而失去全部（例：阿梅莉亚·埃尔哈特）--Cmsth11126a02（留言） 2022年2月16日 (三) 07:34 (UTC)

除非更改典范条目评选整理步骤中的撤销典范条目状态⋯⋯--Cmsth11126a02（留言） 2022年2月16日 (三) 07:36 (UTC)

---

7日无新意见，以最新建议版本🕗 公示7日--Cmsth11126a02（留言） 2022年2月23日 (三) 08:01 (UTC)

@Z7504、Sanmosa、Cdip150、Cwek、Inufuusen、Opky9407：--Cmsth11126a02（留言） 2022年2月23日 (三) 08:10 (UTC)

• 没意见，只是现在鲜少在用评选了，但可别忘了评选Bug是不太可能完全能解决的。--Z7504非常建议必要时多关注评选（留言） 2022年2月25日 (五) 10:50 (UTC)

快速删除被全域禁制个人的编辑

为整合有关主题的讨论，本讨论已移动至Wikipedia_talk:快速删除方针 § 快速删除被全域禁制个人的编辑进行集中讨论。请至有关页面发表意见。

执行人：Ghren🐦🕑 2022年2月2日 (三) 18:25 (UTC)

本讨论章节会维持开放，暂时不按最后意见发表时间存档，直到集中讨论告一段落。欲让机器人存档，请移除本模板。留言请置于本模板上方。

统一WP:RFR权限不活跃时间

解除权限方针有这样的规定：

当超过六个月没有任何编辑活动，在Wikipedia:申请解除权限报告后如查明属实便即时除权。

而目前各权限方针页面的不活跃期限状态如下：

• 六个月
  • 巡查员
  • 回退员
  • 跨维基导入者
  • 自动维基浏览器
• 一年
  • 模板编辑员
• 不限期
  • 巡查豁免者
  • 大量讯息发送者
  • 大量账号创建者
  • 文件移动员
  • 机器用户

提议更改以上权限不活跃时间统一为一年，以安全理由来说，大量信息发送及大量账号创建显然更需要安全。对于使用完毕就除权的权限，是指未使用完毕但用户失踪的情况，因此统一设立一个一年的不活跃时间。确认用户参考自动确认用户，不设期限。IPBE另案考虑。

--桐生ここ★[讨论] 2022年2月1日 (二) 16:54 (UTC)

( π )题外话：同时是否应该统一允许上述用户组移除自身权限(自动维基浏览器除外)，比如模板编辑员目前不能自行移除。桐生ここ★[讨论] 2022年2月1日 (二) 19:12 (UTC)

既然管理员是六个月除权，那么这些也应该统一为六个月。->>Vocal&Guitar->>_留言 2022年2月2日 (三) 02:24 (UTC)

管理员是谜的六个月+一个月通知期呢，我认为应该顺便废除一个月通知期。--AT 2022年2月2日 (三) 03:08 (UTC)

已有复权方针，因此通知期似乎没有必要？桐生ここ★[讨论] 2022年2月2日 (三) 06:26 (UTC)

支持统一，另外一个月的缓冲期给了管理员“回归”并继续“挂机”的机会，与解任初衷不符。--东风（留言） 2022年2月2日 (三) 05:49 (UTC)

我认为管理员不活动除权的期限也应该延长至一年。通知期问题，大可改成前一个月通知，期限一到就除权，这样才符合初衷。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年2月2日 (三) 06:15 (UTC)

一年虽然不认同，但是改成前一个月通知则合理得多。不过，如果仅管理员需要通知的话，我认为是非常不合理，除非其他权限也提早一个月通知，否则也应完全废除管理员的一个月通知，毕竟管理员不应该有任何特权。--AT 2022年2月2日 (三) 12:41 (UTC)

真热爱维基的话一天不编辑都会难过，所以一年的确太长。因此应该一律半年（六个月）不活跃撤权，第五个月通知，适用于所有权限持有者。--中文维基百科20021024（留言） 2022年2月2日 (三) 12:48 (UTC)

管理员和上述其他权限之持有者，在重要程度和安全风险等方面都难以一概而论吧。还不如这样，管理员维持半年，其他的统一为一年。除权的话一律提前一个月通知。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年2月2日 (三) 17:01 (UTC)

管理员半年+提前一个月通知可能没异议，让这一点先通过公示吧。--中文维基百科20021024（留言） 2022年2月2日 (三) 17:06 (UTC)

支持。桐生ここ★[讨论] 2022年2月2日 (三) 17:17 (UTC)

巡查豁免者无任何编辑活动本身并不会构成任何安全性风险，因此我不建议为巡查豁免者设置不活跃除权机制。Bot无任何编辑活动的安全性风险我想听取@Xiplus的意见。其余权限我同意设置／保留不活跃除权机制并统一不活跃时长限制。Sanmosa _A-DWY³ 2022年2月2日 (三) 07:17 (UTC)

比如账号失窃大量创建破坏条目被自动巡查，使得巡查员不能及时发现？机器用户是Flood，机器人Bot的不活跃期限已经是一年。桐生ここ★[讨论] 2022年2月2日 (三) 07:24 (UTC)

那我不反对为巡查豁免者设置不活跃除权机制。--Sanmosa _A-DWY³ 2022年2月2日 (三) 10:34 (UTC)

不能说完全没有风险，端看您能想到该怎么滥用这个权限，例如窃取巡查豁免者的账号来创建难以发现的恶作剧条目之类的。--Xiplus#Talk 2022年2月2日 (三) 11:13 (UTC)

所以我改了表态。感谢意见。--Sanmosa _A-DWY³ 2022年2月2日 (三) 11:20 (UTC)

AWB 应该不用设限吧？其余我觉得可以设限半年！--小跃（捞出记录） 2022年2月3日 (四) 00:11 (UTC)

AWB目前已经被设限。桐生ここ★[讨论] 2022年2月3日 (四) 03:59 (UTC)

AWB可以自己移除，只要在Toolforge架个OAuth程序当中介让AWB者进入自行除权。 Wiki emoji | 😷🅔🅜🅞🅙🅘🅦🅘🅚🅘😷 _{祝百毒不侵～} 2022年2月6日 (日) 11:31 (UTC)

这是什么麻烦的操作，况且你怎么知道机器人会不会滥权（（（-- Sunny00217  2022年2月8日 (二) 01:34 (UTC)

现行条文 如有管理员的贡献纪录符合下列条件，则被视为处于不活动状态： 最近六个月未曾做过在用户贡献或日志中有记录的编辑。 当达到上述条件时，该位管理员应经由以下方式得到通知： 用户对话页 其他通讯方式，如电邮、即时讯息、电话等 当某位管理人员在行政员布告板被提名，并且通知发出逾一个月（30天）后，该管理人员仍然没有做过除用户、用户讨论命名空间的编辑，其便会被取消管理人员权限，而五项管理人员权限亦会同步移除。 如欲提请取消不活动管理人员的权限，请到行政员布告板提出。

提议条文 如有管理员的贡献纪录符合下列条件，则被视为处于不活动状态： 最近六个月未曾做过在用户贡献或日志中有记录的编辑。 当达到上述条件时，该位管理员会被取消管理人员权限，而五项管理人员权限亦会同步移除。 如欲提请取消不活动管理人员的权限，请到行政员布告板提出。 在管理员未编辑和未操作时间达到第五个月时可以由以下方式得到通知： 用户对话页 其他通讯方式，如电邮、即时讯息、电话等。

—中文维基百科20021024（留言） 2022年2月16日 (三) 10:01 (UTC)

• @中文維基百科20021024：管理员的提案是否另开一题。->>Vocal&Guitar->>_留言 2022年2月25日 (五) 01:53 (UTC)

提案

Wikipedia:模板编辑员：

现行条文 模板编辑员在一年内没有任何编辑。

提议条文 模板编辑员在六个月内没有任何编辑。

Wikipedia:大量讯息发送者：

现行条文 若大量信息发送者有滥用权限的嫌疑（例如：利用大量信息发送功能发送广告信件），则用户在发现后，可以至Wikipedia:申请解除权限通报解除。

提议条文 若大量信息发送者有滥用权限的嫌疑（例如：利用大量信息发送功能发送广告信件），则用户在发现后，可以至Wikipedia:申请解除权限通报解除。当大量信息发送者超过六个月没有任何编辑活动，报告后查明属实便即时除权。

Wikipedia:大量账号创建者：

现行条文 若大量账户创建者有滥用权限的嫌疑，则用户在发现后，可以至Wikipedia:申请解除权限通报解除。

提议条文 若大量账户创建者有滥用权限的嫌疑，则用户在发现后，可以至Wikipedia:申请解除权限通报解除。当大量账户创建者超过六个月没有任何编辑活动，报告后查明属实便即时除权。

Wikipedia:文件移动员：

现行条文 -

提议条文 解除权限 若文件移动员有滥用权限的嫌疑，则用户在发现后，可以至Wikipedia:申请解除权限通报解除。当文件移动员超过六个月没有任何编辑活动，报告后查明属实便即时除权。

Wikipedia:巡查豁免权：

现行条文 -

提议条文 当巡查豁免者超过六个月没有任何编辑活动，报告后查明属实便即时除权。

具案，稍后开始公示。->>Vocal&Guitar->>_留言 2022年2月25日 (五) 01:53 (UTC)

我认为一年为宜，半年稍嫌短了。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年2月25日 (五) 02:46 (UTC)

一年的必要性为何？退一步说即便因不活跃而除权，再申请也没有任何障碍，看不出有因此而影响用户贡献的情况。->>Vocal&Guitar->>_留言 2022年2月26日 (六) 05:17 (UTC)

就安全的角度来说，一年并不算长。另外与其让有编辑gap的人（不少）重复走申请流程，还不如放宽一点。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年2月26日 (六) 07:00 (UTC)

无根据的放宽只是不负责任而已。--。->>Vocal&Guitar->>_留言 2022年2月28日 (一) 01:18 (UTC)

无根据的紧缩只会增加行政负担。要不规定一个月甚至一个礼拜没上线就除权，不仅更加安全，而且再申请也没有任何障碍。还是您要说，制定模板编辑员方针的人不负责任？管理人员手握重权，加上社群对其有一定程度的特殊期望，设置六个月活跃门槛尚情有可原；至于其他权限，则未见如此严格限制之必要。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年2月28日 (一) 08:35 (UTC)

浏览算上线吗？如果算上浏览的话，一个月不上线就除权也没什么问题。--中文维基百科20021024（留言） 2022年2月28日 (一) 08:43 (UTC)

制定模板编辑员方针的人当然是未尽责任，中文维基百科有权限申请方针和解除权限方针，不活跃的期限已规定在前述这两个方针内，而英文维基百科没有，所以不活跃期限是规定在各个权限方针/指引内；没有意识到这个问题，直接采用英文方针的翻译，未合适本地化，也未提出这个问题讨论，才造成同层级的方针互相抵触。一个好的反例是Wikipedia:权限申请#解任对于同时持有AWB使用权及机器人权限的账号进行豁免，如果其他权限要采用不同期限，也应该如此记载。--Xiplus#Talk 2022年2月28日 (一) 09:18 (UTC)

照理说模板编辑员方针算是“特别法”，应该优先于其他权限解除的一般法，不严格有抵触问题，不过本站似乎没有相关概念，那还是得确定一下。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年2月28日 (一) 12:27 (UTC)

以目前条文为了执法这样解释应该没问题，但仍然修正为宜，至少加上“若个别权限有规定者则不在此限”等字样。--Xiplus#Talk 2022年2月28日 (一) 14:15 (UTC)

除了模板编辑员值得讨论以外，其余觉得没有必要，中文维基百科有权限申请方针和解除权限方针，不活跃的期限已规定在前述这两个方针内，不同于英文维基百科没有这两个方针才需要逐个方针规定。--Xiplus#Talk 2022年2月28日 (一) 09:21 (UTC)

那相当于应该是把模板编辑员的期限字眼拿掉？--SunAfterRain 2022年2月28日 (一) 10:14 (UTC)

如果有其他撤权准则，条列在一起无所谓（即Wikipedia:模板编辑员#撤权准则），但单纯复制贴上相同的条文到多个页面就不必要了。--Xiplus#Talk 2022年2月28日 (一) 14:12 (UTC)

Wikipedia:维基百科不是词典严重滞后，请求按照现在的英文方针修改和扩充

我在维基百科:页面存废讨论/记录/2022/02/06#司寇讨论中发现一个问题，就是现在的维基百科:维基百科不是词典的版本主要内容还是user:Shizhao2004年根据英维翻译的版本，和现在的英维en:Wikipedia:Wikipedia is not a dictionary脱节严重。假如严格按照现在的维基百科:维基百科不是词典说法（“维基百科不是字典及词典，所以仅有一个定义而没有其它文字的条目不应该放在这里”），不管小条目是什么类型，只有定义的话其实都可以去维基词典，哪怕此类主题完全可以收录进百科全书。而英文维基en:Wikipedia:Wikipedia is not a dictionary则开头就列出了百科条目和词典收录范围的异同（Each article in an encyclopedia is about a person, a people, a concept, a place, an event, a thing, etc., whereas a dictionary entry is primarily about a word, an idiom, or a term and its meanings, usage and history. In some cases, a word or phrase itself may be an encyclopedic subject, such as Macedonia (terminology) or truthiness.），下文还列出了表格作为比对，并且也没有“维基百科不是字典及词典，所以仅有一个定义而没有其它文字的条目不应该放在这里（英文2004年版的方针：Wikipedia is not a dictionary, and an entry that consists of just a definition does not belong)”这句话了。--中文维基百科20021024（留言） 2022年2月6日 (日) 18:25 (UTC) 看了看Wikipedia:维基百科不是词典的讨论页，似乎该方针18年来只有一次讨论。--中文维基百科20021024（留言） 2022年2月6日 (日) 18:57 (UTC)

同意。这个方针非常重要，应当更新。马克西米利安一世（留言） 2022年2月8日 (二) 11:11 (UTC)

又来一个，维基百科:页面存废讨论/记录/2022/02/10#红土文化，user:A1Cafel的理由正如英文现今指引所提到的“One perennial source of confusion is that a stub encyclopedia article looks very much like a dictionary entry, and stubs are often poorly written; another is that some paper dictionaries, such as "pocket" dictionaries, lead users to the mistaken belief that dictionary entries are short, and that short article and dictionary entry are therefore equivalent.”（条目写的太短，容易和词典搞混）--中文维基百科20021024（留言） 2022年2月10日 (四) 06:17 (UTC)

真的应该移动到词典的是维基百科:页面存废讨论/记录/2022/02/08#咩噗此类非百科内容的词语、流行语解释。--中文维基百科20021024（留言） 2022年2月10日 (四) 06:20 (UTC)

(＋)支持英维版本，精义就是en:Use–mention distinction，百科全书介绍红土文化和司寇两事物，词典解释“红土文化”和“司寇”两个词。词典要收定义不代表百科不能收定义，好的定义是应有的百科内容，可以保留，以待扩充。（当然若条目仅有差的定义，换言之无百科价值，仍应删除。）——$\definecolor {my}{rgb}{0.04,0,0.5}\color {my}{\mathsf {htc_{23}}}$（留言） 2022年2月11日 (五) 00:28 (UTC)

Draft:Wikipedia:维基百科不是词典——$\definecolor {my}{rgb}{0.04,0,0.5}\color {my}{\mathsf {htc_{23}}}$（留言） 2022年2月13日 (日) 18:31 (UTC)更新

好，翻译完的话是不是在这里公示7天就行了？--中文维基百科20021024（留言） 2022年2月13日 (日) 01:19 (UTC)

应该是。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年2月13日 (日) 08:52 (UTC)

已有初稿Draft:Wikipedia:维基百科不是词典，在下稍作 说明：

1. 一些段落对“不是词典”加以阐释，且在下认为是社群一早就有的共识，只是未有明文写下，应该较少争议。但以下几项可能争议较大。
2. 如中维2002阁下所述，最大分别是废除旧版的“仅有一个定义而没有其它文字的条目不应该放在这里”，仅有定义的小作品的存废应（如常）按是否有百科价值（如是否属“好定义”，是否小小作品，是否可直接用重定向代替）判断。以“维基百科不是词典”为由提删将限于介绍标题用语本身而非标题所指代的主题的条目，如维基百科:页面存废讨论/记录/2022/02/08#咩噗，而不是维基百科:页面存废讨论/记录/2022/02/06#司寇，见Draft:Wikipedia:维基百科不是词典#格格不入的词典词条。
3. 有关新造词（如网络用语），重申来源使用某词（以指代某事物）与介绍某词（该词本身）的分别，强调按关注度、可供查证、非原创研究等原则，有关新造词的条目需要介绍该词的来源，仅有可靠来源使用该词不足以创建条目，见Draft:Wikipedia:维基百科不是词典#新造词。本节并无新事，只是从既有原则稍作延伸，但会有助澄清网络用语条目的存废。
4. 作为“不是词典”的推论，维基百科的狗条目不是介绍“狗”这个词（该词指代某种动物），所以首句不写成“狗指一种动物”，也不写成“狗是动物的名称”，而是介绍狗这种动物，写成“狗是一种动物”。见Draft:Wikipedia:维基百科不是词典#修正首句的“指”，本节若获采纳可移入WP:格式手册。
5. 标题词性方面，英文有要求用名词，但不符中文用法，所以相关段落在下已作修改，见Draft:Wikipedia:维基百科不是词典#不当标题。Wikipedia:命名常规对词性保持沉默，实务上亦少见限制，所以希望写明“未有限制条目标题的词性”以作填补，防止因为词性缘故令禁烟被移动至烟草禁制政策，烛之武退秦师被移动至烛之武退秦师事件（近来多有条目以“事件”或“争议事件”为名，宜重申是可以但非必需）。本节若获采纳可移入Wikipedia:命名常规。
6. Draft:Wikipedia:维基百科不是词典#指向维基词典建议启用{{Wiktionary redirect}}，假如中文采用的话，使用状况不是很明朗（？）。举例英文有en:IMNSHO、en:Actions speak louder than words、en:Floccinaucinihilipilification，日文则有ja:重点、ja:保留。

以上，请求意见。——$\definecolor {my}{rgb}{0.04,0,0.5}\color {my}{\mathsf {htc_{23}}}$（留言） 2022年2月14日 (一) 21:22 (UTC)更新

第4点第一点可以接受是词典的写法。第二个表述，其实很多条目都在开头讲到“xx是指xxxxx”，本身这一表述可以算作百科方式的叙述。我再补充一条，假如说“狗是一个名词，X朝就出现这一叫法”也算是一种词典性质的写法。--中文维基百科20021024（留言） 2022年2月15日 (二) 03:22 (UTC)

草稿原来已经都翻完了，厉害。--中文维基百科20021024（留言） 2022年2月15日 (二) 06:16 (UTC)

我移除了草稿中“维基百科不是宗谱辞典”一节，原因是该节在上下文中突兀，且“宗谱辞典”一词闻所未闻。相信英文世界同样如此，该词不仅没有条目，还要专门加个出处。中文常见的概念是家谱，这就不能称为词典了。--Lt2818（留言） 2022年2月19日 (六) 04:27 (UTC)

好。--中文维基百科20021024（留言） 2022年2月19日 (六) 06:13 (UTC)

第5点，百科条目标题严格上来说是由这个要求的，中文一般是要求名词或名词性的短语。“烛之武退秦师”可以视为是一个专有名词--百無一用是書生 (☎) 2022年2月22日 (二) 02:04 (UTC)

@HTinC23：，确实纯名词的话更容易写成百科全书。--中文维基百科20021024（留言） 2022年2月22日 (二) 03:07 (UTC)

：🕗 公示7日，2022年3月7日 (一) 09:13 (UTC) 结束：无人反对，进入公示期。7天后草稿:Wikipedia:维基百科不是词典将代替Wikipedia:维基百科不是词典—-中文维基百科20021024（留言） 2022年2月28日 (一) 09:29 (UTC)

WP:UPNOT调整

WP:UPNOT的列举项并非全是“与维基百科无关的内容”，存在逻辑矛盾。为此我做了这笔修改，未实际更动指引内容，但由于调整了顺序，在此说明一下。--Lt2818（留言） 2022年2月13日 (日) 06:30 (UTC)

• 请直接具体说明你改了什么，并取得社群共识再去修改。那个修订版本差别有够难看，看了半天也看不出个所然。－hiJK910 ^{走先喇 係咁先喇 下次再玩吖} 2022年2月13日 (日) 08:57 (UTC)

• 我改了什么：把与“与维基百科无关的内容”无关的内容统一放在后面，前置“此外，用户页上亦不能放置”之句。
• “取得社群共识再去修改”：未修改方针指引文意的编辑可直接进行。
• “修订版本差别有够难看”：可以不用看版本差别，直接对比前后两个版本。

--Lt2818（留言） 2022年2月13日 (日) 09:22 (UTC)

@Lt2818：Wikipedia:共识#微小修订简易规定：“如该提案……为对方针指引等规定的单纯语法调整、错别字更正或现实性对应调整（事实性修订），且无人对相关修订提案是否单纯语法调整、错别字更正或现实性对应调整（事实性修订）提出合理质疑……该修订提案可立即执行，而毋须跟从基本规定。该修订提案获立即执行后，应在{{Bulletin}}的“公告”字段加入链接宣告该修订已获进行。”我认为Hijk910的留言可能具足有人“对相关修订提案是否单纯语法调整、错别字更正或现实性对应调整（事实性修订）提出合理质疑”的要件（但如确认并不具足，此提案则确然可以立即执行）。Sanmosa _A-DWY³ 2022年2月15日 (二) 01:36 (UTC)

我的理解是这个应该只规范客栈提案（即，提案提出来了才这样做），否则我们相当于禁止未经公告的事实性修订，这个既不现实，又可能导致bulletin变成垃圾场。 ——魔琴 [ 留言 贡献 ] 2022年2月15日 (二) 02:03 (UTC)

此拟议修改牵涉以下修改：

• 序号修改：原2至4→8至10，原5至10→2至7（1、11至13序号不变）；
• 于新第8项（原2）前加入“此外，用户页上亦不能放置：”句；

以上。Sanmosa _A-DWY³ 2022年2月15日 (二) 01:45 (UTC)

@Hijk910。Sanmosa _A-DWY³ 2022年2月15日 (二) 01:47 (UTC)

我觉得这个很明显了，一望而知。版本差异功能没有那么智能，要习惯 囧rz…… ——魔琴 [ 留言 贡献 ] 2022年2月15日 (二) 02:00 (UTC)

谢谢多位，我没有问题了。打扰了。－hiJK910 ^{走先喇 係咁先喇 下次再玩吖} 2022年2月15日 (二) 09:52 (UTC)

有加anchor就代表有人用过链接或用用户页指引第XX条来指称特定准则，调整序号顺序并不适当。--Xiplus#Talk 2022年2月22日 (二) 04:59 (UTC)

建议限制内容翻译

由于内容翻译工具中有以下问题：

1. 翻译拙劣；以及
2. 原文有问题（例如{{refimprove}}）但是翻译版未解决问题，

因此提请限制内容翻译工具（以致所有翻译），有以下方案：

1. 内容翻译只允许自动确认用户使用；
2. 内容翻译只可以发布到草稿以及用户空间，并需经AFC（利益冲突：绝对绝对不是为AFC登广告攒业绩）；
3. 完全禁用内容翻译；或
4. 以上任一方案（禁用方案除外），但扩展至任何翻译；
5. 以上任一方案，但扩展至延伸确认用户或只限制非延伸确认用户。

以上。 Wiki emoji | 😷🅔🅜🅞🅙🅘🅦🅘🅚🅘😷 _{祝百毒不侵～} 2022年2月20日 (日) 04:38 (UTC)

注：此处原有文字，因为无助于讨论且令人反感，已由SunAfterRain（留言）于2022年2月28日 (一) 10:06 (UTC)删除，尚祈见谅。若有异议请至互助客栈或向管理员反映。

Wiki emoji | 😷🅔🅜🅞🅙🅘🅦🅘🅚🅘😷 _{祝百毒不侵～} 2022年2月20日 (日) 04:48 (UTC)

内容翻译工具的使用体验我给0分，且翻译外语版本时不应该将外语版本的问题内容一起翻过来（但内容翻译工具似乎默认必须全部翻译？）。--🎋🎍 2022年2月20日 (日) 05:30 (UTC)

内容翻译工具虽然有些难用，但是我自己用起来觉得还是很有帮助的，至少我用起来比不用内容翻译工具的情况下，翻译效率明显要高。所以在我看来这只是如何用的问题，而不是用不用的问题。如果非要限制使用，那么我更倾向于“只可以发布到草稿以及用户空间”这一条（不含AFC）--百無一用是書生 (☎) 2022年2月21日 (一) 02:45 (UTC)

没有AFC等审核机制相当于无用，因为翻译者大可立刻移动。 Wiki emoji | 😷🅔🅜🅞🅙🅘🅦🅘🅚🅘😷 _{祝百毒不侵～} 2022年2月26日 (六) 00:00 (UTC)

翻译者改善完移动到条目空间有什么问题？为什么要强制移动到AFC？内容翻译完的确需要改善一下，因为会出现一些奇怪问题，比如来源之间会有多余空格。Wiki emoji以为这里是英维吗？强制AFC，什么时候中维有英维那样的编辑人数再说。--中文维基百科20021024（留言） 2022年2月28日 (一) 08:50 (UTC)

内容翻译工具根本就没规定要全部翻译。（到底用没用过啊？）--中文维基百科20021024（留言） 2022年2月28日 (一) 08:51 (UTC)

加个提议 5.内容翻译只允许延伸确认用户使用。倾向于支持2和5.  ——魔琴 [ 留言 贡献 ] 2022年2月21日 (一) 03:50 (UTC)

可以考虑开启投票。有关内容翻译的相关统计数据，可参见Special:内容翻译统计。--Steven Sun（留言） 2022年2月22日 (二) 03:46 (UTC)

修改一下Emojiwiki的提议：

1. 内容翻译只允许自动确认用户，或只允许延伸用户使用
2. 建议内容翻译先发布到草稿以及用户空间，或者干脆禁止发布到条目空间，并需经AFC（利益冲突：绝对绝对不是为AFC登广告攒业绩）；
3. 完全禁用内容翻译

--中文维基百科20021024（留言） 2022年2月28日 (一) 09:03 (UTC)

补充一下，在草稿或用户空间使用内容翻译会好一点，可能不用触碰到太多的过滤器。--中文维基百科20021024（留言） 2022年2月28日 (一) 09:05 (UTC)

内容翻译中的过滤器有着它触发的奇怪原理（及显示），不一定目标指向那里就能避开--SunAfterRain 2022年2月28日 (一) 10:05 (UTC)

建议Emojiwiki先在用户空间多试试内容翻译再说，不要人云亦云。某人在telegram因为讨厌内容翻译，只看到缺点，妄图搞一刀切和禁用。--中文维基百科20021024（留言） 2022年2月28日 (一) 09:08 (UTC)

 吐槽，这问题已经被提及很多次了，并非完全没有意义，另请不要隐射任何人（我是不知道是谁就是了啦）--SunAfterRain 2022年2月28日 (一) 10:11 (UTC)

提议新建交通车辆条目内容方针2

本指引为交通车辆条目内容方针，统一格式将有助于阅读及编辑维护上的便利性，以及减少特定章节的编辑战，目的是帮助编者创建具有一致性的条目作品。

行文结构

铁路车辆

• 导言：简述车辆所属的铁路公司、制造商、服务路线、投入服务日期等，并精要概括正文。
• 信息框：一般用用{{鐵路車輛}}，亦可使用{{鐵路車輛2}}。模版应照文档填写。
• 概要：介绍车辆引进缘由、役缘由（如已除役之车辆）、基本概述等。
• 规格与构造：介绍车辆基本构造、机电设备、外观涂装、设备规格、编组方式等。
• 重大事故：若车辆曾经发生过重大铁路事故可初步简述事故经过，并使用{{main}}作主条目导向。
• 相关条目：与条目相关的车型或车种可于此列出。
• 参考文献：请列明来源！报章杂志、铁路公司官网的车辆简介、车辆制造商的车辆简介与政府出国报告书都是好的来源。切记，不可使用部落格与营运单位的内部文件作为来源。
• 外部链接：可连接其他维基计划或是未达可靠来源门槛的百科性资源。

客运/公车车辆

• 导言：简述车辆制造商、车辆类型等，并精要概括正文。
• 信息框：一般用用{{Infobox Automobile}}。模版应照文档填写。
• 概要：介绍车辆引进缘由、退役缘由（如已除役之车辆）、基本概述等。
• 相关条目：与条目相关的车型或车种可于此列出。
• 参考文献：请列明来源！
• 外部链接：可连接其他维基计划或是未达可靠来源门槛的百科性资源。

条目内容

不合适的内容

1. 爱好者内容：
   • 铁路车辆：请不要将车辆车次运用、车号机务段分配、改造期程、交车期程等琐碎信息加入条目内。
   • 客运/公车车辆：请勿将领牌车号、行驶路线、停靠站牌等琐碎信息加入条目内。

   依据：维基百科不是不经筛选的信息收集处－说明书

2. 大量的短条目：通常一个较大的条目能提供对主题更有条理的介绍与背景联系。当大条目能做到时，请不要创建大量小条目。理想的条目是既不过大，也不过小。

   依据：维基百科的条目大小指引

3. 过多的图片：请勿于条目内放置各车号的照片，于信息框模板一张代表即可，其他照片则放入共享资源并于底下纳入共享资源链接导引。

因讨论被机器人存档，且尚未完成讨论故接续提案，部分内容已依照上次讨论提议更新--🚊。铁路Railway ^论 2022年2月20日 (日) 05:24 (UTC)

• 这边邀请上次有参与的维基人接续讨论@心平星辰、owennson、BIT0865、Bus Follower、一片楓葉、Ghrenghren、SickManWP、Mys_721tx、Nrya、LuciferianThomas--🚊。铁路Railway ^论 2022年2月20日 (日) 05:32 (UTC)

似乎没有通知成功，重新标注一次@owennson、心平星辰、一片楓葉、BIT0865、Bus Follower、Mys_721tx、Nrya、LuciferianThomas、Ghrenghren、SickManWP--🚊。铁路Railway ^论 2022年2月21日 (一) 12:56 (UTC)

(＋)支持，另外建议增加关注度方针。--Nrya ✰_{沿路看风雨漫漫} 2022年2月21日 (一) 13:02 (UTC)

@Nrya：阁下的意思是再额外创建关注度方针、于此方针中加入还是于NT:T中加入？--🚊。铁路Railway ^论 2022年2月21日 (一) 13:26 (UTC)

“行文结构”的“参考文献”一条，部落格的消息确实不敢保证真实性，但是营运单位的内部文件……抱歉，中国大陆有不少地铁列车都没法不用它，参见武汉地铁DKZ8型电动车组的参考文献。--BIT0865 · Discussion · 燕房线永远的神！ 2022年2月21日 (一) 13:32 (UTC)

@BIT0865：噢....若将“文件”更换成“公文”呢？呢因为台湾的车辆条目经常出现使用短期且快速更新的内部资料编辑爱好者内容，当初使用文件一词是为了阻止此状况，而这些引用属公文电报，更改引述应该可行吧0.0--🚊。铁路Railway ^论 2022年2月21日 (一) 14:08 (UTC)

内部文件关键应该是非公开的文件。公开文件是没问题的，这种文件应该是可以网站找到，或者图书馆可以找到的，而不是那种要爱好者拍一次，再上传才可以找到的的文献。“武汉轨道交通一号线一期工程车辆使用维护说明书”这种文件虽然是官方的，但是理论上不外传的吧，这样的话其实不应该用。--Ghren🐦🕑 2022年2月22日 (二) 06:11 (UTC)

协助标注@BIT0865--🚊。铁路Railway ^论 2022年2月23日 (三) 10:30 (UTC)

但是如果没有那本说明书的话，那个条目我可以直接提删了——因为没加说明书的内容之前条目里面确实没什么东西——很多地铁列车的小条目都有这样的遗留问题。--BIT0865 · Discussion · 燕房线永远的神！ 2022年2月23日 (三) 11:32 (UTC)

还有就是，“而不是那种要爱好者拍一次，再上传才可以找到的的文献”……那我甚至可以退出维基了，请看这里的“各种 VVVF 铭牌”。--BIT0865 · Discussion · 燕房线永远的神！ 2022年2月23日 (三) 11:34 (UTC)

@BIT0865：若逆向搜索能搜索到可靠来源则直接使用新的可靠来源，应该很多东西都是逆向搜索找到正确的参考资料，不一定要以照片为唯一来源--🚊。铁路Railway ^论 2022年2月23日 (三) 14:57 (UTC)

有文献可查的话，能不拍铭牌就尽量不拍，铭牌充其量用作保底，典型的例子是广州地铁A1型和广州地铁A5型。但是像DKZ16的情况，① 太平湖车辆段有介绍各种铭牌的小册子，② 车辆段的小站台边上也可以经常拍铭牌；但是不用这两种方法，（在将铭牌照片传到维基共享资源之前）根本搜不到 MAP-184-75VD177，就比较为难了。--BIT0865 · Discussion · 燕房线永远的神！ 2022年2月23日 (三) 15:29 (UTC)

甚至于，有时查到的某个型号也不能确定属于哪种车型。比如 MAP-184-75V208 可能属于四种车的一种，MAP-164-15V230 可能属于两种车的一种，这两个型号都是单一来源，不去问员工的话，没有其他来源协助确定，但是问员工却不巧又出现了困难。所以说白了，新车到段之前就把车底下查完真的很重要。--BIT0865 · Discussion · 燕房线永远的神！ 2022年2月23日 (三) 15:35 (UTC)

大致(＋)支持相关方针改动。很抱歉由于健康问题（右眼失明）本人不太有时间参与相关方针的建设。--SickManWP_{邀请您加入❤️边缘人小组·🖊️签到} 2022年2月21日 (一) 15:18 (UTC)

支持。-Mys_721tx（留言） 2022年2月21日 (一) 17:36 (UTC)

(＋)支持：支持另建方针。呈上，如果中国大陆境内有此情况，那可能就采取共用大架构，另立小特别款？毕竟台湾这端出现在拿未确定是否可公开外流的台铁内部行车电报来放此举应不妥；图片部分车号是指大的编组，举例以言之，TEMU1000型全编8辆，放这8辆图片可，但每一编组（TEMU1001+1002～1015+1016）均放或可议，毕竟适量的放图片有助于阅读跟版面配置，其他放共享资源；车辆车次运用、车号机务段分配、改造期程、交车期程等这些就放入学院吧，维基是阻止不了的，那就面对现实导入比较可行的维基学院吧，以上相关资源则在条目内设链接引导。消波块（留言） 2022年2月22日 (二) 01:47 (UTC)

这里展开说下“中国大陆境内有此情况”：
① 不少爱好者遇见新车（尤其新车）只顾着看外观，没有查证设备的意识，等到新车上线了再去查往往非常困难。
② 中国大陆没有专门介绍地铁或者铁路车辆的报刊杂志，因此情况 ① 的直接后果就是不得不求助于员工。
③ 即便是求助于员工也不能保证马上得到反馈，尤其是铁路车辆，一些动车组的裙板非常重，不是所有员工都愿意动不动打开裙板去看里面有什么。
--BIT0865 · Discussion · 燕房线永远的神！ 2022年2月23日 (三) 12:21 (UTC)

@BIT0865：关于第二点据在下所知有《铁道知识》期刊，国际标准书号为ISSN 1000-0372，如北京地铁DKZ13型电动车组刚刚在下已协助增加来源。--🚊。铁路Railway ^论 2022年2月23日 (三) 13:16 (UTC)

感谢添加文献，但是《铁道知识》似乎不如中国铁路总公司的《铁路机车概要》详细，里面应该没有记VFI-HR2420E和SVI-H116A（铭牌上有写，但是铭牌太小并且靠近车厢底板，所以站台上看不见，只能问员工）。--BIT0865 · Discussion · 燕房线永远的神！ 2022年2月23日 (三) 13:30 (UTC)

@BIT0865：若是反向搜索来源应该可以吧...知道型号和厂牌之后去制造商官网找相关资料。--🚊。铁路Railway ^论 2022年2月23日 (三) 14:07 (UTC)

你想得太天真了：DKZ13的牵引系统，《日立评论》倒是详细介绍了工作原理，但是对型号只字不提，不知何故；《东洋电机技报》里有关 SFM04/04A 和 DKZ32/33/34 的情况亦如是，它们的VVVF型号全是靠格式规律插值推出来的，然后再靠铭牌确认。--BIT0865 · Discussion · 燕房线永远的神！ 2022年2月23日 (三) 15:18 (UTC)

@BIT0865：若查无可靠来源算原创研究，可能要改写到维基学院了。--🚊。铁路Railway ^论 2022年2月26日 (六) 07:39 (UTC)

补充：回复上面，问员工也算原创研究--🚊。铁路Railway ^论 2022年2月26日 (六) 10:02 (UTC)

情况很严峻啊，我和 @LuisRichmond 很早就燕房线DKZ70型的条目讨论过原创研究的事，结果他一副无所谓的样子，我也没辙。BIT0865 · Discussion · 燕房线永远的神！ 2022年2月26日 (六) 11:06 (UTC)

还有就是：DKZ4的RG6023-A-M和06C02的VFI-HD1420B我觉得不算原创研究。--BIT0865 · Discussion · 燕房线永远的神！ 2022年2月26日 (六) 16:00 (UTC)

@BIT0865：若真的没办法符合维基方针的内容就移至维基学院吧…，台湾近期也是有很多内容移到学院。这种找不到来源的信息，台湾条目也有遇过，现在大部分都移到学院了。--🚊。铁路Railway ^论 2022年2月26日 (六) 16:53 (UTC)

现在主要讨论的是条目的整体架构，若整个条目或是部分内容都没有适合的来源，就如上的方法解决吧…0.0

这边邀请上面同样有回复此问题的@Ghrenghren一起讨论。--🚊。铁路Railway ^论 2022年2月26日 (六) 17:05 (UTC)

(＋)支持，方针内容全面。--一片🍁枫叶^展望未来 2022年2月22日 (二) 09:37 (UTC)

(＋)支持，但应为内容指引级别而非方针级别，关注度同。--路西法人𖤐 2022年2月22日 (二) 10:45 (UTC)

停用模板ConfirmationVRT

此模板在几乎一切情况下可以由{{PermissionTicket}}替代，维护两个模板并不会带来额外的好处且易造成混淆；其中的source参数某种意义上透露了工单内无必要公开的信息。这个东西应该发到VRT公告板，但是众所周知那个板块长期根本没人看，于是就丢到这里来了。-- Stang^★ 2022年2月20日 (日) 14:03 (UTC)

我的理解，两个模板一个是用在条目对话页，一个是用在文件描述页--百無一用是書生 (☎) 2022年2月21日 (一) 02:48 (UTC)

看链入得知事实并非如此啊。 Stang^★ 2022年2月21日 (一) 08:36 (UTC)

这两个模板都是英文引入的，原始用法就是如此。只是到了中文这边没人在乎，就乱了--百無一用是書生 (☎) 2022年2月22日 (二) 02:06 (UTC)

调整Wikipedia:非原创研究部分条文

现行条文 维基百科不是存放原创研究或原创观念的场所。在维基百科里所谓原创研究或原创观念，指的是未发表的事实、争论、观点、推论和想法；以及对已发表材料进行的未发表分析或总结，并产生了新的立场。以上意味着维基百科不是存放您的个人观点、经验或争论的场所。 （略） 来源 在本方针与另两大内容方针的限制下，对现有来源的内容进行收集与整理方面的研究是受到鼓励的：这样的研究是“基于来源的研究”，是撰写百科全书的基本功。但应注意，切勿超越来源中的表达，或者将来源用在与其本意不符的场合，譬如撰写与来源上下文无关的内容。简而言之，我们应该照着来源写。 如果没有可靠的第三方来源来支持某个主题，关于这一主题的条目不应出现在维基百科上。 （略） 对已发表材料的总结并提出立场 切勿对多个来源的信息进行综合，假若综合后的结论并未由任何来源明确提及。编辑者不应犯下这样的错误：因为A发表于可靠来源，B也发表于可靠来源，因此就可以在条目中将A和B综合起来得出结论C。这等同于原创研究，因为这是对已发表材料的总结，会产生新的立场。“因为A和B，所以C”只有在可靠来源也发表了与C相同的主张，且C主张与条目主题相关时才能出现。 仔细地对来源内容进行不改变原意的概括或改述并不构成原创总结——反而是应受鼓励的做法。写作维基百科条目的最好做法，是去研究大量与主题相关的可靠已发表来源，并用自己的话来概括其中的主张，让每一主张都能被归属到明确作过此等主张的来源去。

提议条文 维基百科不是存放原创研究或原创观念的场所。在维基百科里所谓原创研究或原创观念，指的是未发表的事实、争论、观点、推论和想法；以及对已发表材料进行的未发表分析、综合或总结，并产生或暗示新的结论。以上意味着维基百科不是存放您的个人观点、经验或争论的场所。 （略） 来源 维基百科创建在对可靠来源的收集和整理之上。如果没有可靠的第三方来源来支持某个主题，关于这一主题的条目不应出现在维基百科上。维基百科不是发表编者个人新发现的地方。 最好的做法是去研究与主题相关的可靠已发表来源，并在不改变原意的前提下，用自己的话改写各个来源所说的内容，让条目中的每一主张都能被归属到明确作过此等主张的来源去。但应注意，切勿超越来源中的表达，或者将来源用在与其本意不符的场合，譬如撰写与来源上下文无关的内容。简而言之，我们应该照着来源写。 （略） 对已发表材料的综合 切勿汇集、综合多个来源的信息或单个来源中的不同部分，以得出或暗示并未由来源明确提及的结论。编辑者不应犯下这样的错误：因为A发表于可靠来源，B也发表于可靠来源，因此就可以在条目中将A和B综合起来得出或暗示结论C。这等同于原创研究，因为这是对已发表材料的不恰当综合或总结，会产生新的立场。“因为A和B，所以C”只有在可靠来源也发表了与C相同的主张，且C主张与条目主题相关时才能出现。如果A和B出现在同一个来源的不同上下文处，但该来源没有将它们联系起来并论证得到结论C，则编者不应该在条目中采用C。

参考资料

原条文中部分表述——“产生新的立场”、“基于来源的研究”、“提出立场”、“不改变原意的概括或改述并不构成原创总结”等——有一定含混性。一些编者会综合多个来源作未发表的分析或总结，或者单纯罗列与条目主题无关的来源来表达暗示，并援引以上条文作为辩护。因此，提议调整部分条文。--Jhstriver（留言） 2022年2月21日 (一) 02:43 (UTC)

支持。-Mys_721tx（留言） 2022年2月21日 (一) 03:54 (UTC)

@Jhstriver：我觉得“对已发表材料的综合”可以再进一步简化为“综合已发表材料”，其他的我不反对。Sanmosa _A-DWY³ 2022年2月21日 (一) 13:33 (UTC)

有道理，之后的公示版本会修改，感谢建议。--Jhstriver（留言） 2022年2月22日 (二) 05:44 (UTC)

有关模板的删除理由

此前讨论将《删除方针》中的第9项删除理由由“多余无用的模板”更改为“多余无用，且影响其他模板命名或者百科运作的模板”，然而此更改导致了部分用户滥建重复模板的情形（其中一个例子），因此我认为有必要重新调整可删除模板的情形。现提案如下：

现行条文 多余无用，且影响其他模板命名或者百科运作的模板

提议条文 多余无用、影响其他模板命名或影响维基百科运作的模板

以上。Sanmosa _A-DWY³ 2022年2月21日 (一) 13:31 (UTC)

@Ericliu1912。Sanmosa _A-DWY³ 2022年2月21日 (一) 13:31 (UTC)

行。另外百科应该可以写全成维基百科吧。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年2月21日 (一) 15:11 (UTC)

完成。Sanmosa _A-DWY³ 2022年2月22日 (二) 08:54 (UTC)

兼ping原案推动者@Bluedeck阁下。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年2月21日 (一) 15:18 (UTC)

倾向同意，但是要确保无链入不是模板的删除理由，提删时要提出说明证明其多余无用。另同Ericliu1912，应写成维基百科。桐生ここ★[讨论] 2022年2月21日 (一) 20:02 (UTC)

会设这个限制还不是因为有人乱提删模板，不少模板以subst方式使用，本来就不会有固定的引用数，就有人不懂模板运作原理又看到这个规则就直接以多余无用提删，试问这个问题怎么解决？是否在该准则内详细说明多余无用的定义，例如“0引用”不等于“无用”。--Xiplus#Talk 2022年2月22日 (二) 05:55 (UTC)

@桐生ここ、Xiplus：或许我这样理解：“0引用”的模板与“无用”的模板是两个集，两者有重复的地方，但不是同一个集。我觉得可以加一个注释说“无引用的模板不一定为无用的模板”之类的，但我不太能想到一个合适的说法，不知道在这方面能不能帮一下忙。Sanmosa _A-DWY³ 2022年2月22日 (二) 08:53 (UTC)

如果无用与未使用可能存在部分重叠意思，或者可以换个无歧义的无意义？--Kethyga（留言） 2022年2月23日 (三) 04:22 (UTC)

“无意义”反倒是另一个意思了。现在的问题在于“无用”与“未使用”只是部分重叠，但有人误解成完全重叠，所以只要弄一个说明解决这个问题就可以了。--Sanmosa _A-DWY³ 2022年2月23日 (三) 07:57 (UTC)

• 我记得bluedeck的观点是，一些模版即使没有用途，但当中的技术依然对其他人有参考价值。--Temp3600（留言） 2022年2月23日 (三) 14:52 (UTC)

  问题在于这种情况实属少数，我倒是想知道{{Ping4}}的“技术”的参考价值何在？“技术”的参考价值需要足够大才能成为保留理由，而不能单单因为“技术”的参考价值存在而成为保留理由。Sanmosa _A-DWY³ 2022年2月24日 (四) 07:10 (UTC)

  我觉得每个人的模板使用习惯都不同，同样功能的{{Jp}}、{{jpn}}、{{nihongo}}，也一直存在，其实Ping4又不会影响其他用户，因为这个模板的参数一般都不要修正的，其实有什么所谓？--Ghren🐦🕓 2022年2月24日 (四) 08:10 (UTC)

  @Ghrenghren：嗯，我建议你先看一看Template talk:Jp#建议将Template:Jpn、Template:Nihongo、Template:Japanese-horizontal、Template:Jp合并（{{Japanese-horizontal}}直接并入{{jpn}}，{{jp}}成为{{jpn}}的定制资料盒）。Sanmosa _A-DWY³ 2022年2月26日 (六) 08:06 (UTC)

  我觉得定制资料盒的使用上来说，即使是定制了但依然是两个模板。而假如有一定的使用人群的话就不能算作是多余的模板。我不觉得ping4的使用上会比{{Vgnameq-nb}}这类型的低。我只是觉得要尊重他人使用习惯而己。--Ghren🐦🕓 2022年2月26日 (六) 09:26 (UTC)

明确如何处理真实姓名作为用户名的情况

现行条文 如果您的真名被封禁，敬请见谅。我们这样做是要避免您的身份被伪冒。我们欢迎您使用您的真名，但在某些个案中，您可能需要证明您确实使用真实姓名参与维基百科。

提议条文 如果您的真名被封禁，敬请见谅。我们这样做是要避免您的身份被伪冒。我们欢迎您使用您的真名，但在某些个案中，您可能需要发送邮件至info-zh-hanswikimedia.org，附带相关的身份验证资料以证明您是这位知名人士本人。

参考了commons的做法，明确如果出现知名人士以真实姓名参与时如何验证身份。 Stang^★ 2022年2月21日 (一) 15:35 (UTC)

(＋)支持：另外也需要考虑有些名人只需要在微博、Twitter、Facebook之类的可以用证明其身份的认证帐号发一个帖，就可以证明其姓名，所以“身份验证资料”包含这种方式。桐生ここ★[讨论] 2022年2月21日 (一) 19:54 (UTC)

VRT还可以备份此类申报资料。鉴于站外内容无法控制是否日后删除，不建议单独允许站外方式。-Mys_721tx（留言） 2022年2月21日 (一) 21:25 (UTC)

没错。桐生ここ★[讨论] 2022年2月22日 (二) 03:24 (UTC)

如果是被封禁要申诉的话，为什么不是寄到unblock-zh？--Xiplus#Talk 2022年2月22日 (二) 03:33 (UTC)

需要隔离除姓名外可以验证身份的非公开数据。-Mys_721tx（留言） 2022年2月22日 (二) 04:07 (UTC)

unblock-zh里面也一堆非公开数据...--Xiplus#Talk 2022年2月22日 (二) 04:44 (UTC)

unblock-zh中不能有身份证等证件级别的非公开数据。-Mys_721tx（留言） 2022年2月22日 (二) 20:52 (UTC)

“收信系统看不到图片，请用文字陈述”。 Stang^★ 2022年2月22日 (二) 05:25 (UTC)

实际上这个问题在迁移到hyperkitty后有所改善，我也很想要unblock-zh能转移到VRT啊。--Xiplus#Talk 2022年2月22日 (二) 05:40 (UTC)

贵unblock-zh完全可以跟VRT相并列啊，这里用“转移”一词是不是有点不妥。不过这离题了。 Stang^★ 2022年2月22日 (二) 13:16 (UTC)

提议取消文件移动员 2

走完多年前的流程。一点答疑：

• 大量上次提案的反对原因在于“朝令夕改”；
• “如果文件管理员过了几个月真的无人申请”：Wikipedia:权限申请/申请文件移动权内年均通过量少于2个；
• “需求少”：2021年全年共有561次文件移动，这个量看上去与move相比算很小的，且大多数都由非文件移动员执行；
• 其他用户组替代：先前有过允许所有自动确认用户执行操作的讨论，目前认为已经成熟。
• “自动确认用户的门槛太低了”：请论证移动文件相比于移动普通页面的额外危害；一名注册用户变成自动确认用户的时候可没有弹一个框让“请确认您已知晓何时不能移动页面”吧。

提案：

• 允许所有自动确认用户移动文件；
• 改写文件移动方针；
• 删除“filemover”组。 Stang^★ 2022年2月21日 (一) 21:48 (UTC)

emmm...在讨论结束之前来个管理员把权限给我好不好 囧rz……--在下荷花，请多指教（欢迎签到） 2022年2月22日 (二) 02:05 (UTC)

移动文件造成的问题主要是不留重定向移动后，如果不修改使用了文件的页面，会造成图片链接损坏。所以自动确认的话，的确是个风险。如果基本没人用这个权限，那就取消掉好了--百無一用是書生 (☎) 2022年2月22日 (二) 02:10 (UTC)

自动确认并不会拥有不留重定向权限。--Xiplus#Talk 2022年2月22日 (二) 03:35 (UTC)

“自动确认并不会拥有不留重定向权限。”这样的话，如果有需要不留重定向移动，就又是个问题--百無一用是書生 (☎) 2022年2月22日 (二) 04:01 (UTC)

G8删重定向页。--在下荷花，请多指教（欢迎签到） 2022年2月22日 (二) 04:03 (UTC)

诶等等不应该R6吗，方针该改了。--在下荷花，请多指教（欢迎签到） 2022年2月22日 (二) 04:08 (UTC)

如果某个文件依据WP:FNC#9进行移动，在所有链接都更新完成后，请在遗留下来的重定向页面放上G8

桐生ここ★[讨论] 2022年2月22日 (二) 04:21 (UTC)

然而G8现在不能由非管理员放.--在下荷花，请多指教（欢迎签到） 2022年2月22日 (二) 04:24 (UTC)

Template talk:Delete#关于快速删除G8供参考，方针恐怕得改了。--在下荷花，请多指教（欢迎签到） 2022年2月22日 (二) 04:27 (UTC)

是啊，我去提案。桐生ここ★[讨论] 2022年2月22日 (二) 04:40 (UTC)

话说有WP:R6又有WP:FILEREDIRECT，那么一个不属于WP:FNC#不能接受的图像名称，但属于WP:FMV/W的文件，是应该留下重定向，还是不留下重定向。桐生ここ★[讨论] 2022年2月22日 (二) 04:33 (UTC)

这也是问题，我觉得该留，但实际操作中很多人不留，我看英维好像是留的。--在下荷花，请多指教（欢迎签到） 2022年2月22日 (二) 08:28 (UTC)

给个参考，在commons除非为了改善明显不当的文件名称，否则禁止suppressredirect。 Stang^★ 2022年2月22日 (二) 05:27 (UTC)

同书生，给自确有风险；但不认因为有必要取消，权限组留着也不会破坏什么，或者造成什么不好的问题。如果提议回退员或巡免或延伸确认有filemover可以考虑。桐生ここ★[讨论] 2022年2月22日 (二) 03:21 (UTC)

巡免有。。。--在下荷花，请多指教（欢迎签到） 2022年2月22日 (二) 04:01 (UTC)

一时忘了 囧rz……，巡免没有的是不留重定向移动。桐生ここ★[讨论] 2022年2月22日 (二) 04:15 (UTC)

对的。--在下荷花，请多指教（欢迎签到） 2022年2月22日 (二) 04:19 (UTC)

考虑一下，我觉得可能可以考虑给延确。然后差不多就可以去掉权限组。--在下荷花，请多指教（欢迎签到） 2022年2月23日 (三) 04:07 (UTC)

	上任日	除权日	用权数
Sanmosa的移动日志	2021年9月23日	2022年2月1日	0
RyanCray的移动日志	2020年11月12日	2022年12月7日	17
Minorax 的移动日志	2019年7月13日	至今	1
TimWu007的移动日志	2019年10月28日	2020年8月11日	32
和平至上的移动日志	2018年6月13日	2018年6月17日	0
SD_hehua的移动日志	2022年2月22日	至今	67

更新于：2023年2月12日 (日) 10:09 (UTC)

• 用权数大概共计50次左右，就看大家觉得要不要了。Ghren🐦🕑 2022年2月22日 (二) 06:03 (UTC)

我除权的原因是我现在拥有的其他权限已经有同样功能。我自己是没意见，看其他人。Sanmosa _A-DWY³ 2022年2月22日 (二) 09:03 (UTC)

• 支持移除该组，因为申请拥有权力者太少，核心功能单一，且已有为数众多的其他常见（管理）组别人员拥有（巡查：190人、巡查豁免：261人、管理员：……不想查，这本来是分内事……）。鼓励将移动文件请求放到如条目探讨或求助版或其他讨论请求页上让其他用户处理，该组别功能比鸡肋还糟糕。——Sakamotosan路过围观 | 避免做作，免敬 2022年2月23日 (三) 01:24 (UTC)

  那你是说其他人不能拥有权限自己移动吗（？--在下荷花，请多指教（欢迎签到） 2022年2月23日 (三) 02:58 (UTC)

  追加一句，关于自动确认用户对文件移动的处理，我参考shizhao的说法。——Sakamotosan路过围观 | 避免做作，免敬 2022年2月23日 (三) 03:07 (UTC)

修改WP:FMV/W

G8改R6

事实性修订，已执行。Sanmosa _A-DWY³ 2022年2月22日 (二) 09:05 (UTC)

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

---

现行条文 如果某个文件依据WP:FNC#9进行移动，在所有链接都更新完成后，请在遗留下来的重定向页面放上{{d|G8}}（文件移动员），或是直接依据{{d|G8}}的内容进行删除（管理员）。更多信息请参考快速删除标准G8。

提议条文 如果某个文件依据WP:FNC#9进行移动，在所有链接都更新完成后，请在遗留下来的重定向页面放上{{d|R6}}（文件移动员），或是直接依据{{d|R6}}的内容进行删除（管理员）。更多信息请参考快速删除标准R6。

目前G8只能由管理员提出。 --桐生ここ★[讨论] 2022年2月22日 (二) 04:48 (UTC)

---

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

(？)异议：管理员能根据R6直接删除吗？ ——魔琴 [ 留言 贡献 ] 2022年2月23日 (三) 02:42 (UTC)

(：)回应我觉得移动不留重定向就好了。--在下荷花，请多指教（欢迎签到） 2022年2月23日 (三) 04:10 (UTC)

增加对有移动不留重定向权限者的说明

还应该改的内容：有移动不留重定向权限者应直接不留重定向移动。--在下荷花，请多指教（欢迎签到） 2022年2月22日 (二) 08:26 (UTC)

(＋)支持。Sanmosa _A-DWY³ 2022年2月22日 (二) 09:05 (UTC)

Wikipedia:管理员

当中提及：

管理員不應該在一項事宜中使用普通用戶和管理員的雙重身份，而應該要麼使用普通用戶的身份，要麼使用管理員的身份，儘管用戶是同一個人。在以下場合的具體限制有：

保護：管理員不應該保護/解除保護他們牽扯進去的頁面，而應該像普通用戶一樣求助於其他管理員，這些頁面不包括諸如主頁等的常見保護頁面；

封禁：管理員不得僅因某用戶反對自己而封禁這個用戶；

刪除：管理員不得刪除自己提議刪除或者投票刪除的頁面；

在以上情況下，管理員應該以普通用戶的身份要求其他管理員協助。

但我觉得管理员应该可以删除自己提议的O1、G10快速删除，因为这样通常不会对维基百科造成太大影响，也公平。
请各位在下面讨论一下。Choi Chin Long 2022年2月22日 (二) 10:04 (UTC)

请允许我直接引用两条五大支柱：在不引起争议时，任何改善（或保护）维基百科的行为都没有太大问题--Kegns（留言） 2022年2月22日 (二) 13:42 (UTC)

与文明方针有何联系？ Stang^★ 2022年2月22日 (二) 13:48 (UTC)

• 不要忽略其他维基人的立场与结论。--Kegns（留言） 2022年2月22日 (二) 13:56 (UTC)

• 这样绕过了其他管理员审查有关CSD的常规程序。恕反对。--Temp3600（留言） 2022年2月22日 (二) 13:55 (UTC)

正常流程是用户先提删，后管理员进行删除，而第一步为普通用户操作，第二步为管理操作，所以一位管理员不能单独完成这两个步骤。--东风（留言） 2022年2月23日 (三) 03:39 (UTC)

其实O1目前管理都是自己删掉的，用bot删还是人手删有什么分别？--Ghren🐦🕛 2022年2月23日 (三) 04:19 (UTC)

Wikipedia:FILEREDIRECT和WP:R6是否冲突？

过往设立讨论：Wikipedia_talk:快速删除方针/存档8#快速删除方针修订：明显不恰当的

看起来R6是将移动的所有重定向都删除，而文件重定向方针则认为除WP:FNC#8外都不应删除，请问方针是否矛盾？--在下荷花，请多指教（欢迎签到） 2022年2月23日 (三) 04:29 (UTC)

WP:独立后的爱好者内容的原创研究

鉴于中维游戏类条目爱好者内容堆积的问题，需要一个比较好的解决办法。目前，这还是一个很不成熟的草案，需要大家帮助，谢谢。--Taeas --以上未签名的留言由Taeas（讨论｜贡献）于2022年2月26日 (六) 11:07‎加入。

@Taeas：感谢您的思考。实际上Wikipedia:电子游戏条目指引对爱好者内容已经有了要求：

• NOTONLYFORGAMER － 维基百科不收录只对爱好者有意义的内容。如果一个内容对不打算入坑的读者没有帮助，那这个内容就不该存在于维基百科条目中。所以，最好的做法是直接清理的爱好者内容，而不是将不合格的内容迁移到其他条目。
• WP:VG/ROLE － 维基百科游戏类条目的重点是现实世界内容（设计历程、业界评价）。对于独立角色列表中，现实世界内容应占内容的1/3。当然如您所说，清理角色和设置列表工作量大，所以很多时候选择了分割条目的“清理”方式。但是这个分割出来的列表，其实品质其实也是不合格的。只是现在通常睁一只眼闭一只眼没处理，未来就不好说了。
• WP:VG#SETTINGLIST － 纯粹的设置/世界观列表的确是拒绝收录的。世界观类内容基本不会单开条目，不过若能写到这个水平另说。
• WP:VG#参考来源 － “常识性内容”应该是指从游戏流程中可以直接获得的内容。这种内容的来源就是游戏本身，可以使用{{Cite video game}}引用。但不易遭受质疑的不加脚注问题也不大，所以编辑平时都不加ref。这种叫“有来源没引用”，不属于原创研究。

维基百科是综合性百科，介绍游戏设置是为了帮助非玩家了解游戏。要让非玩家快速聚焦重点，条目就要做到内容精悍，无法像游戏专题站那样深挖细节。当然粉丝内容确实对玩家有用，直接删除我也认为很可惜。我也尝试和维基教科书等站讨论内容迁移，希望能在姊妹计划中保留内容。但很遗憾，粉丝类的确不适合写在维基百科这个网站。这类内容移走是对的，但迁移的目的地应该是其他网站，而不是维基百科其他条目。

另外电子游戏专题正在探讨虚构列表的写作方法，也欢迎您发表看法。--洛普利宁 2022年2月26日 (六) 11:51 (UTC)

很抱歉现行的方针没有“适当的原创研究”，维基百科是讲求可供查证而不是事实，你这些内容或者更为合适去萌娘或者维基学院甚至维基教科书。--Ghren🐦🕘 2022年2月26日 (六) 13:08 (UTC)

感谢@Ghrenghren和@Lopullinen的回复，将爱好者内容移至维基学院或维基教科书看起来是个很不错的方式！--Taeas（留言） 2022年2月26日 (六) 14:39 (UTC)

你可能询问下相关的管理。我不太清楚你的内容具体是什么。有些可以，有些不可以。--Ghren🐦🕙 2022年2月26日 (六) 14:44 (UTC)

如果针对拆分后的类似角色列表、设置列表等，还有Wikipedia:资料页作为修订参考。当然我反对部分事无大小地列出对表现作品剧情没帮助的元素，或者说滥用分割页面，。——Sakamotosan路过围观 | 避免做作，免敬 2022年2月27日 (日) 09:37 (UTC)

限制RFA提问数量

为应对暂行安全投票的日程安排问题，拆分自管理人员选举制度改革。原提案者User:Ericliu1912。

修订申请成为管理人员指引内容如下：

现行条文 参与方式 管理人员提名需要经过14天（即两周）的投票。具人事任免投票资格的用户可以投支持票、反对票或中立票，也可以仅发表意见、向候选人提问（候选人有权决定是否作答）。投票后票数会自动更新，如果发现错误可至此处手动更正票数。

提议条文 参与方式 管理人员提名需要经过14天（即两周）的投票。具人事任免投票资格的用户可以投支持票、反对票或中立票，也可以仅发表意见、向候选人提问（候选人有权决定是否作答）。就提问而言，每人最多可提问二题，并允许就提问开展相关讨论；超过额度者，其问题将被直接删除。禁止以多重问题或“小题”形式绕过限制，这样将被视为游戏维基规则。投票后票数会自动更新，如果发现错误可至此处手动更正票数。

鉴于原提案讨论中没有对提问数量限制提出明确的反对意见，故🕗 公示7日，2022年3月6日 (日) 02:02 (UTC) 结束。--Steven Sun（留言） 2022年2月27日 (日) 02:02 (UTC)

我想说中维的RFA问题和英维的问题根本是完全不同。中维的问题一向就是以快问快答的形式，问题短，答案也短。至现今的RFA，只有极少的参与者是真的可以做到只问两条问题。然后，即使是不作制止，候选人依然去回答问题与否。以两题的方式根本很难让一个投票者去了解候选人本身，毕竟问一下会否活跃，选不选介管己经是两条问题。我是想说，就算设这些限制，只是想问问题的人只会转到Talk Page、电邮、TG其他地方问，然后这些情况就更难掌握。对于我而言只是削足适履的方案。此外，像User:Carrotkit/猴子孵育场这些应该怎样算。这是六个分题，还是只是一个大问题？--Ghren🐦🕐 2022年2月27日 (日) 05:33 (UTC)

1. 候选人一般为社群较为活跃用户，在提名前社群一般就对候选人有大体的了解。不需要通过大量提问去从头了解候选人。况且问太多的低质问题，尤其是那些与维基百科无关的问题，同样也干扰投票者对候选人的认识。
2. 本指引应只限制投票页的提问数量。在其它地方提问只要不违反其它相关指引及方针即可（以前社群也没有在其它地方提问的习惯，而且不少人的讨论页也不经常回复别人）。但不能在投票页为其他页面的提问引流，否则视为绕过限制。--Steven Sun（留言） 2022年2月27日 (日) 08:13 (UTC)

   实际上当然是较为活跃的才可以被社群支持，但是提名本身是深入了解主张的行为。很多候选人没有很具体的用户论述，引致候选人虽然在某一方（比如专心在条目的用户）很出色，但是对站务的主张却可能不太具体的，只靠两条发问实在难而得知具体立场。引流视作绕过规定基本上就只能(－)反对到底了。我想说低质问题就不应该回答。--Ghren🐦🕓 2022年2月27日 (日) 08:23 (UTC)

那得问多少题？几百题是太过分了，你“问清楚”候选人的时候他也差不多要退选。引流这种“解压缩”手段也是不怎么可取，表面上一两题，事实上得造成候选人数倍的负担。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2022年2月27日 (日) 15:52 (UTC)

 吐槽你至少也丢个几天再公示吧 囧rz……--SunAfterRain 2022年2月28日 (一) 10:03 (UTC)