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

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

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

公告栏

• [讨论] 用户“折毛”主编条目伪造问题正进行集中讨论，欢迎踊跃参与。
• [人事] 请踊跃参与此后管理员申请投票制度之修订事宜。
• [公告] 改善虚构格式手册并恢复其指引地位、调整优特内容评选规则及台湾行政区条目人口段落共识已经通过。
• [公告] 交通车辆条目指引正在公示，如有意见请尽快提出。
• [讨论] 互助客栈方针区正在讨论修改防滥用过滤器可见性、修改巡查豁免权的简介及申请条件及新闻动态发表程序问题，敬请踊跃参与。
• [讨论] 互助客栈技术区正在讨论部署HanAssist小工具，敬请踊跃参与。
• [讨论] 互助客栈条目探讨区正在讨论“中国航空集团”条目合并争议，敬请踊跃参与。
• [讨论] 互助客栈其他区正在讨论首页“你知道吗？”板块的问题及提议将设计奖并入绘图奖，敬请踊跃参与。
• [讨论] 运动策略论坛正在讨论通用行为准则执行规范如何才能对中文社群有最大效益，敬请踊跃参与。
• [广告] 第二十次动员令现正进行主题投票（至7月2日截止）及设计方案投票（至7月7日截止），欢迎踊跃参与！
• [投票] 提议增设“建筑特别贡献”的投票正在进行中，欢迎踊跃参与！

• [协作] 现有71个页面需维基化，16个条目需清理，4个移动请求正在讨论。
• [奖励] 现有3名用户获提名维基奖励，欢迎投票。

#	话题	发言	参与	最新发言	最后更新(UTC+8)
1	提议新建交通车辆条目内容方针2	112	24	Ericliu1912	2022-07-02 00:33
2	提议修改维基百科:防滥用过滤器	60	18	魔琴	2022-07-01 22:04
3	关于接下来的管理员投票	108	27	Z7504	2022-07-01 23:57
4	修改巡查豁免权的简介及申请条件	47	14	范博2004	2022-07-01 18:38
5	分类索引排序规则问题	5	5	Temp3600	2022-06-30 23:50
6	关于日食小作品	28	7	Z7504	2022-06-30 23:13
7	建议修改音乐关注度规则	38	9	Milkypine	2022-07-02 12:43
8	再次重提精简用户讨论页的罐头通知	15	7	Yining Chen	2022-06-30 23:04
9	建议修改新闻动态发表程序	123	16	KOKUYO	2022-07-01 00:03
10	修改WP:PAID/ALT	3	3	Temp3600	2022-06-30 01:56
11	修改 uw-ublock 系列模板样式	3	3	Temp3600	2022-06-30 01:59

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

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

本指引为交通车辆条目内容指引，由各专业领域的维基达成的条目编写共识。相同格式有助于阅读及编辑维护上的便利性，以及减少特定章节的编辑战，目的是提供编者符合编辑格式参考指引。果您有想法或疑问，请在讨论页面进行讨论。除此之外，您还应该熟悉更优秀条目写作指南。

行文结构 本节介绍了几类条目的结构，实际条目的分节方式和标题无需完全对应下文。若您的条目有特殊之处，请放手调整，不必拘泥于本文。

铁路车辆

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

客运/公车车辆

• 导言：简述车辆制造商、车辆类型等，并精要概括正文。
• 信息框：一般用用{{Infobox Automobile}}。模版应照文档填写。
• 概要：介绍车辆引进缘由、退役缘由（如已除役之车辆）、基本概述等。
• 规格与构造：介绍车辆基本构造、设备规格等。
• 各代车辆：若车辆型号生产不只一代，依照各代不同之处进行介绍。
• 重大事故：若车辆曾经发生过重大交通事故可初步简述事故经过，并使用{{main}}作主条目导向。
• 相关条目：与条目相关的车型或车种可于此列出。
• 参考文献：请列明来源！
• 外部链接：可连接其他维基项目或是未达可靠来源门槛的百科性资源。

条目内容 不合适的内容

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

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

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

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

3. 过多的图片：请勿于条目内放置各车号的照片，于信息框模板一张代表即可，其他照片则放入共享资源并于底下纳入共享资源链接导引。
4. 原创研究内容：原创研究内容建议建议写在维基学院内。

   依据：非原创研究

备注

因讨论被机器人存档，且尚未完成讨论故接续提案，部分内容已依照上次讨论提议更新--🚊。铁路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)

(！)意见 可以引导爱好者将相关内容发布至维基学院。另认为应当为内容指引而不是方针。--Yinyue200（留言） 2022年3月30日 (三) 17:19 (UTC)

---

🕗 公示7日，2022年3月13日 (日) 07:52 (UTC) 结束：赞成者多数，且7日无新留言，进入公示期。--🚊。铁路Railway ^论 2022年3月6日 (日) 07:52 (UTC)

通知@owennson、心平星辰、一片楓葉、BIT0865、Bus Follower、Mys_721tx、Nrya、LuciferianThomas、Ghrenghren、SickManWP@Qazwsaedx--🚊。铁路Railway ^论 2022年3月6日 (日) 08:54 (UTC)

有些部落格的内容其实不错且有公信力（例如[1]），不能当成来源有点可惜。--Poem（留言） 2022年3月6日 (日) 15:15 (UTC)

🕗 暂停公示：公示期间有新提议，故暂停公示并进行讨论。--🚊。铁路Railway ^论 2022年3月6日 (日) 16:33 (UTC)

暂时来说比较半吊子，观望下。--Ghren🐦🕐 2022年3月7日 (一) 05:32 (UTC)

@Ghrenghren：虽然目前尚未很完全，因铁路条目近期较混乱，在下的想法是将最大宗的共同问题先行初步整顿，预计后面还会再提出其他车辆或细项，希望在台铁的新车交车前先有个指引约束内容，避免与EMU900、EMU3000条目一样混乱。--🚊。铁路Railway ^论 2022年3月7日 (一) 14:47 (UTC)

部落格本身就是用户生成内容，出了引述观点外几乎完全不能用。--路西法人𖤐 2022年3月8日 (二) 02:46 (UTC)

---

且慢。抱歉有点久没有登录维基百科。重点，本人想针对客运/公车车辆做些修正：

1. 关于草案上文中的使用“信息框”部分，若草案真的实行，代表旧有的翻掀式信息需全部打掉重练。则请问是由何君来实施全台近百家客运业者的条目整理呢？或是维持现状？
2. 再者，本人找到了关于公车客运使用车种的可靠参考来源（ https://www.mvdis.gov.tw/m3-emv-mk3/freeway/query ），行政院交通部公路总局的"公路客运公司列表"，应该可行吧？以屏东客运为例，则该客运的使用车种依据为此（ https://www.mvdis.gov.tw/m3-emv-mk3/freeway/query?method=queryCarDetailByDisplaytag#anchor ），若此方案可行，本人可协助补充于各客运上。
3. 移动到维基学院的问题：本人发现@铁路君最近移动了一些客运的使用车种，但本人看见的是许多红连，觉得跟维基百科的相互链接有大落差。

最后：可否请@鐵路1延后公示时间？ -- Bus Follower（留言） 2022年3月6日 (日) 15:42 (UTC)

Bus Follower君留言链接是公开资料，且来源为政府机关，是可靠来源。Poem（留言） 2022年3月6日 (日) 16:09 (UTC)

@Bus Follower：1.翻页式排版不易阅读，且不符合维基基础格式应尽量改善，可参见第三点的存废讨论记录。2.虽然阁下提供的参考来源为政府机关之可靠来源，但是车牌号码实属琐碎信息与爱好者内容，非爱好者并不会想要知道车号，另外在下创建主要是针对Category:巴士型号分类中的条目。3.使用车种在下查了编辑记录，在下仅移动丰原客运的内容，丰原客运的链接刚才以修整，而使用车种应该要使用表格式而非折叠式列表，且内容过于琐碎，请参见Wikipedia:页面存废讨论/记录/2021/09/05#国光客运使用车种之讨讨论记录。--🚊。铁路Railway ^论 2022年3月7日 (一) 14:37 (UTC)

了解，本人一看讨论就知道大部分用户对这块是不怎么友善的...不过君的意思应该是不要把使用/历史车种写在维基百科上，而是改写至维基学院，对吧？如果是这样的话，本人可以接受。也辛苦君对丰客的整理。但是关于什么改成表格的部分，本人觉得还是先照旧吧...虽然旧的"畸形"式折叠式列表已不建议写在维基百科上，但还是回到原点，若由君自己更新全台客运业的条目应该有困难吧

顺带一提，有看见君想要整理Category:巴士型号的分类，不过可笑的是，台湾最常见的DAEWOO BS120CN低底盘公车条目竟然被删除了。本人发现只要有关于“公车”的条目几乎都被提删，不知道这种风气在流行什么，且删除的原因都是什么关注度不足的鬼，但事实上这些公车都满街跑，怎么会“关注度不足”？真是感到失望。当然这不是铁路君的错，关于其他编者的旧有固执思念，嗯。应该永远也不会改吧，哈哈... --Bus Follower（留言） 2022年3月9日 (三) 13:55 (UTC)

@Bus Follower：在下虽未找到提删的讨论记录或日志，但从镜像网页的相关条目所看到的排版除了排版不符合编辑手册，另外车辆介绍完全没有列出任何参考文献，若被关注度删除据在下所知另外可能就是查无相关文献或未提供相关文献。在下主编的是铁路相关的条目，公车的条目很不熟悉，也很难帮忙改善0ω0--🚊。铁路Railway ^论 2022年3月10日 (四) 16:18 (UTC)

Wikipedia:页面存废讨论/记录/2021/07/23#大宇BS120CN。--Ghren🐦🕛 2022年3月10日 (四) 16:28 (UTC)

---

铁路1（讨论 | 贡献） ：

你好，不知道为什么，最近才看到这个讨论。作为一个大规模删减香港巴士路线条目的编辑员（详见九龙巴士1-30号所有路线），看到这篇讨论后，发现有超过50%内容可以删减，包括行车路线、车站、用车限制（因涉及ABc综合）、车牌，对吗？

这样删减的话还有什么可以表述？--HK5201314（留言） 2022年3月9日 (三) 01:04 (UTC)

铁路1（讨论 | 贡献）：

顺带一提，早前可靠来源布告版已将一个经常被引用的香港巴士爱好者网站列入防滥用保护器内，限制编辑者引用，不知你会不会提出更多网站供限制？--HK5201314（留言） 2022年3月9日 (三) 01:17 (UTC)

在维基百科内找不到公共交通总方针，只找到交通车辆方针，请问这里会不会跟进公共交通总方针（如车站、路线、车型）？--HK5201314（留言） 2022年3月9日 (三) 01:36 (UTC)

个人认为香港巴士的情况与海外有非常大的差别，车型是非常多元化（特别是1990年代至2010年代初），也可以证明路线历史的变迁。如果要强硬删除的话，个人认为有关条目失去了应有的意义。感觉中维对“琐碎信息与爱好者内容”的定义无限放大，并不是好事。--Wpcpey（留言） 2022年3月9日 (三) 01:45 (UTC)

@Wpcpey：路线、车站可参见NT:T指引，用车若车型不多可参见环状线 (台北捷运)#电联车的方式，若车型较多可参见横须贺线#使用车辆，在路线条目中列出车型与简介，详细介绍则再另外的主条目进行介绍。另外，此指引主要是针对车辆，路线已有NT:T，在路线的条目中罗列停靠站还算正常，但是再车辆的条目再次出现行驶路线的车站就显得过于重复，用车可稍微提及行驶路线与路线简介，但不篇幅不要太长，不然就变成不是介绍车辆而是介绍路线，车牌号码的部分，除爱好者外，一般民众不太会去注意，且车牌号码只要转让/转手可能就又会更换一组号码，属不稳定的信息，原创研究的内容应写到维基学院，不是百科。--🚊。铁路Railway ^论 2022年3月9日 (三) 05:44 (UTC)

对于我来说，其实不是有特别多的可靠来源记载一个路线的用车变迁。香港来说其实来来去去都是那几本巴士书而己，实际使用可以记载车型使用的巴士路线实际上就不多，没必要加上这条规定。列出简介应该没有问题的，只要不将车型过于陈述和原创研究就没问题了。--Ghren🐦🕚 2022年3月10日 (四) 15:04 (UTC)

@Ghrenghren：：但最大的问题是，用户HK5201314仍然认为“用车变迁”是爱好者内容而删除。加上目前的环境，会有人花时间查看巴士书再记载车型使用吗？而那几本巴士书是在2000年代初出版，之后又有一段空白期。而路线使用的车辆也可以反映人口，地理环境和需求情况。香港的巴士路线用车情况不能够与其他地方比较的。--Wpcpey（留言） 2022年3月26日 (六) 14:09 (UTC)

---

🕗 延长公示7日，2022年3月21日 (一) 04:12 (UTC) 结束：经讨论后新提议有其他方式可替代，故延长公示。--🚊。铁路Railway ^论 2022年3月14日 (一) 04:12 (UTC)

• @鐵路1：“客运/公车车辆：请勿将领牌车号、行驶路线、停靠站牌等琐碎信息加入条目内”，单是一个汽车车型的条目不会无故有“停靠站牌”这信息吧。Fran·1001·hk 2022年3月16日 (三) 08:31 (UTC)

  @‪Fran1001hk‬：几个月以前在下是曾经看过有车型条目内还罗列停靠站牌0.0--🚊。铁路Railway ^论 2022年3月16日 (三) 09:02 (UTC)

• 且慢。抱歉有点久没有登录维基百科。重点，的士也是一种公共客运，但是使用车种如丰田Hiace、马自达6等根本不可能依照这个架构去写，这个指引未有考虑到私人和公共客运两栖车种的情况。--Maccomcre（留言） 2022年3月20日 (日) 23:34 (UTC)

  @Maccomcre：由于计程车与一般私家汽车使用车型相同，关于汽车稍后会有另一波的提议，目前正在准备中。--🚊。铁路Railway ^论 2022年3月21日 (一) 12:12 (UTC)

  不同意这样区分，巴士和的士都可能用上私家车型，而且像是丰田Coaster巴士车型都不应该是这种架构。--Maccomcre（留言） 2022年3月28日 (一) 07:53 (UTC)

  @Maccomcre：若以载客量区分，大客车适用巴士，小客车、计程车以汽车为主呢？--🚊。铁路Railway ^论 2022年3月31日 (四) 03:07 (UTC)

  补充：在下主编铁路相关条目，客运、计程车不是很熟悉，若阁下有跟更适合的指引条文，还请直接提出，感谢。(•‿•)--🚊。铁路Railway ^论 2022年3月31日 (四) 03:31 (UTC)

  不同意以载客量区分，像是VDL DB300的大巴其实跟丰田Coaster的小巴的模式相似。而且VDL DB300这种大巴士车型都不应该是这种架构。--Maccomcre（留言） 2022年4月6日 (三) 23:41 (UTC)

  @Maccomcre：还请阁下提出条文，在下已想不到如何修改条文，公车条目在下不在行。--🚊。铁路Railway ^论 2022年4月7日 (四) 03:16 (UTC)

  就以台湾的法律来看，是以载客量区分车辆类型，不分客运用还是计程车用。--🚊。铁路Railway ^论 2022年4月7日 (四) 03:19 (UTC)

User:铁路1，有个小问题，类似香港小巴这种型式的交通会否纳入？又，渡轮船只飞机直升机之类交通可否纳入？--owennson（聊天室、奖座柜） 2022年3月22日 (二) 06:16 (UTC)

@Owennson：小巴也算是大客车，见[2]，只要座位10人以上都算，目前指引名称是交通车辆，若加入可能要改成交通载具的了--🚊。铁路Railway ^论 2022年3月22日 (二) 06:32 (UTC)

User:铁路1，个人对地铁使用车辆内容直接放入路线条目有异议，毕竟有可能出现几条地铁线共用同一个车型。而且搞模板、分类时也十分不便。还是建议一个车型一个条目较好。--owennson（聊天室、奖座柜） 2022年3月24日 (四) 00:42 (UTC)

@owennson： 捂脸这根本已经不是维基的格式准则了…。直接修正就好了，另请教有哪些条目？0W0--🚊。铁路Railway ^论 2022年3月24日 (四) 04:02 (UTC)

那就好，不是范围内。因为我想帮上海地铁03A02、04A02型创建条目，这种横跨两线的车型是不可能也不应重定向到路线条目的。--owennson（聊天室、奖座柜） 2022年3月24日 (四) 05:08 (UTC)

(！)意见@owennson：若命名空间是模板，直接移动不留重定向后将内容更正即可，若是拆分在2个页面的则直接除内容贴到新条目内吧。--🚊。铁路Railway ^论 2022年3月24日 (四) 05:50 (UTC)

---

铁路1（讨论 | 贡献） ：

救命！原来我已有半年没有参与香港巴士爱好者内容回退事宜，发现有大量ip用户重新加入爱好者内容，单凭我一人之力无法处理这些内容，请问可否代为申请大规模限制ip或没有自动确认用户编辑交通模版及号召编辑员进行删减？否则只好放弃数以千计的爱好者内容回退。--HK5201314（留言） 2022年3月26日 (六) 08:53 (UTC)

• 1. HK5201314这里是指“车辆条目”，不是“路线条目”。
  2. 如何限制？除非把所有维基百科条目半保护^{[开玩笑的]}。Fran·1001·hk 2022年3月26日 (六) 09:35 (UTC)

     @Fran1001hk：

     Yes，将巴士路线条目半保护，或号召编辑员都可以。

     毕竟需要删减爱好者内容的数量太大--HK5201314（留言） 2022年3月26日 (六) 11:15 (UTC)

  • HK5201314我想如果按阁下所说，其实不止香港，世界其他地方的巴士路线条目应该如你般“删减爱好者内容”，可是条目数量会是很多很多（我也无法统计）。如果阁下只针对香港，只会引发更多争议。Fran·1001·hk 2022年3月27日 (日) 06:04 (UTC)

    @Fran1001hk：

    你大可以问问@DarkWizard21，他在香港交通模板的删减动作完全获得管理员的支持及认可。没有任何管理员可以对他作出惩罚，所以如果单针对香港，不会引发争议。--HK5201314（留言） 2022年3月27日 (日) 06:57 (UTC)

    • HK5201314编辑模板本身会影响极大量的条目，除非是小修小补，否则未有共识而删减里面的内容会有挑起编辑战风险。举个例子，如阁下把模板:Infobox bus route中的Data14和16（即所属车厂和路线用车）两栏径自删去，便会有挑起编辑战的风险。Fran·1001·hk 2022年3月27日 (日) 11:31 (UTC)

      @Fran1001hk：

      请问你可否提供来源证明留下Data14&16的意义？--HK5201314（留言） 2022年3月27日 (日) 12:58 (UTC)

      HK5201314DarkWizard21的删减只限于香港交通模板，影响的条目仅局限于香港。可是，使用模板:Infobox bus route的条目不止于香港，还有中国大陆和其他地区，你进行任何删减动作便会影响海量条目。Fran·1001·hk 2022年4月19日 (二) 02:09 (UTC)

个人认为“用车变迁”并不是爱好者内容，明显是巴士路线条目基本的内容吧，根本不应该删除。--Wpcpey（留言） 2022年3月26日 (六) 14:09 (UTC)

@Wpcpey：

当然以为用车变迁不是爱好者内容

只不过现时用车型号、车牌及车厂属于爱好者内容。

如果单删减上述三项内容，争议性应该不大。--HK5201314（留言） 2022年3月27日 (日) 06:59 (UTC)

个人认为用车型号是不可缺少的内容，特别是在香港的巴士路线，80年代至2010年代中有非常多类型的巴士在同一路线服务。其他地区和国家也没有香港这样的情况。--Wpcpey（留言） 2022年3月27日 (日) 13:27 (UTC)

@Wpcpey：

来源？这些内容很容易判为爱好者内容，更何况每一款巴士原则上没有指定行驶哪条路线

举个例，上年秋季某日西贡乡郊发生水浸，ITtalk 报导原本派出的双层巴士全部改为单层巴士，车款五花八门，请问这些每日不同的资料写入合适吗？

(＆)建议

我在上面讲过，不改动用车变迁，毕竟涉及历史问题

而家IG咁多巴士记录者，问佢哋攞几幅相证明曾经使用相关车型咪ok啰（后以gallery形式显示），当用车变迁就算啦（曾经），用不着写入data16，因为没有硬性规定一定要使用这款车，而写得入data16的是该路线指定使用该车款。--HK5201314（留言） 2022年3月27日 (日) 14:20 (UTC)

你说不改动用车变迁，但是阁下在去年在多条巴士条目已经删除有关内容了。更甚的是那些巴士记录者会愿意拿出照片到维基证明吗？特别是80年代至2010年代中那段时期。本人建议用不同年代描述主要车型（差不多5-10年为一个周期）。不需要再将资料细分到每日/每月，这样就真是爱好者内容。--Wpcpey（留言） 2022年3月27日 (日) 14:29 (UTC)

@Wpcpey：

如果有相片会比较合适，使用文字会有纸上谈兵的感觉，有作故事的可能，毕竟无法确认真伪。

况且不是有一本书讲述80-00年代的用车变迁，引用isbn 应该不是问题。

如果有人在HKItalk以CC By Sa 3.0征集照片，应该很多人支持，毕竟有推广的可能，况且最后还要标示相片是来自相关人士的page，变相可协助他们增加page的关注度。--HK5201314（留言） 2022年3月27日 (日) 14:42 (UTC)

铁路条目有规格与构造和重大事故，但是公车条目就没有？这是按什么逻辑定的？十分不解。--Opky9407（留言） 2022年4月13日 (三) 11:53 (UTC)

@Opky9407：在下是参照目前现有条目格式订的，参照条目也不多，可能疏漏了，公车条目在下不是很熟悉(• ▽ •;)--~~--🚊。铁路Railway ^论 2022年4月14日 (四) 01:38 (UTC)

已增加。--🚊。铁路Railway ^论 2022年5月2日 (一) 05:11 (UTC)

建议“行文结构”一章参考电子游戏条目指引，在开头加上类似的一段话：“本节介绍了几类条目的结构，实际条目的分节方式和标题无需完全对应下文。若您的条目有特殊之处，请放手调整，不必拘泥于本文。 ”。条目不必强制统一格式，毕竟有些条目会有其特殊的地方。--Jhstriver（留言） 2022年4月24日 (日) 09:07 (UTC)

@Jhstriver：感谢建议，已增加。--🚊。铁路Railway ^论 2022年5月2日 (一) 05:11 (UTC)

---

🕗 公示7日，2022年5月9日 (一) 05:15 (UTC) 结束：7日无新意见，且主文变动不大，进入最后公示。--🚊。铁路Railway ^论 2022年5月2日 (一) 05:15 (UTC)

(－)反对：到底你是怎样参照条目的？上面有人给出的公车条目，其实有写规格和构造，反而没有重大事故，但是你却在公车车辆那里加了重大事故，规格和构造却没有，完全不明白为什么会有这样反过来的操作？感觉改得很随便，所以只能反对继续公示,需要再改。--Opky9407（留言） 2022年5月8日 (日) 15:26 (UTC)

@Opky9407：感谢指教，已更新。--🚊。铁路Railway ^论 2022年5月9日 (一) 04:10 (UTC)

其实，铁路那部分都有问题，像是英国铁路373型电力动车组都跟提出的架构有很大不同。条文太过以台湾为重心去制定，用在其它国家的车型应该会很容易出问题吧。要是问我怎样修改，我宁可完全不要直接把行文结构定出来，因为各地和各类车型根本不可能完全共用同一个结构。只规定哪些内容是不能写应该还要实际。--Maccomcre（留言） 2022年5月9日 (一) 05:13 (UTC)

@Maccomcre：在下大部分是参照日本、香港、台湾、韩国、中国大陆以及少数美国、印尼、越南铁路车辆条目进行规划，应该是少数车辆不适合吧...，若就少数车辆不适用可利用“本节介绍了几类条目的结构，实际条目的分节方式和标题无需完全对应下文。若您的条目有特殊之处，请放手调整，不必拘泥于本文。 ”这条应对修改ㄚ。--🚊。铁路Railway ^论 2022年5月9日 (一) 12:52 (UTC)

(：)回应：港铁中期翻新列车、新干线E2系电力动车组、日本国铁D51型蒸汽机车等香港、日本铁路车型都跟上面的架构有很大不同（JR东日本车辆形式里面就有大部分车型都跟上面的架构有很大不同），所以是很多车型都不适合，而不是少数。如果很多车型都要当成有“特殊之处”去调整，那么定出来的架构完全没有意义，所以还是(－)反对。--Maccomcre（留言） 2022年5月24日 (二) 15:52 (UTC)

(－)反对：担心会有其他用户会用此标准而进行大规模删除，近年的环境已经赶走了很多人不愿更新了。--Wpcpey（留言） 2022年5月9日 (一) 12:59 (UTC)

在下创建初衷是许多新编辑加入不适合维基百科的内容或是格式不统一才提议的。--🚊。铁路Railway ^论 2022年5月9日 (一) 13:56 (UTC)

问题是“不适合的内容”范围越来越大，很多过去10多年来可以收录的东西，由2020年起也不能再收录。看看电视和铁路条目就知道了。--Wpcpey（留言） 2022年5月9日 (一) 14:16 (UTC)

有些是没人清理就一直加下去，例如台铁的列车运用车辆配属本来就不适合维基百科，是近期才清理到维基学院的。--🚊。铁路Railway ^论 2022年5月10日 (二) 03:42 (UTC)

🕗 公示7日，2022年5月24日 (二) 17:47 (UTC) 结束：7日无新发言，公示。--🚊。铁路Railway ^论 2022年5月17日 (二) 17:47 (UTC)

(＋)支持创建相关规范--一个喜欢新兴科技的维基人（留言） 2022年5月18日 (三) 07:38 (UTC)

(＋)强烈支持。不过可能存在一些因铁路交通工具的本地特殊性而需微调行文架构的问题，大概也应属于可接受范围？-- ${\ce {_29^64Cu}}$${\ce {->}}$${\ce {_{29}^{?}Cu}}$ $+$ $e^{\pm }$ 2022年5月21日 (六) 11:03 (UTC)

• 竟然连支持的人都出现了疑问。其实再看开头的那两段说话已经很有问题，先是“统一格式将有助于阅读及编辑维护上的便利性”，然后又说“请放手调整，不必拘泥于本文”，明显前后矛盾的语句，让人放手调整那么就不可能是统一了。另外，本来提案人也承认了参考的条目不多，之后提案人对于结构的修改就好像见到什么就加什么的，其实每个条目都有很多不同之处，事实上很难举出所有都用到的章节，与其这样的大混杂，还不如上面有人说索性不要把结构钉起来，只告诉大家哪些内容是属于爱好者等不适合百科全书，更来得实际。--Opky9407（留言） 2022年5月24日 (二) 14:17 (UTC)

在下是主编铁路车辆相关条目，对铁路车辆较了解，大部分铁路车辆应该都是可适用，公车相关的确是参考比较少--🚊。铁路Railway ^论 2022年5月24日 (二) 17:12 (UTC)

引言有稍作修改了。--🚊。铁路Railway ^论 2022年6月1日 (三) 01:07 (UTC)

• 顺带一提，这显然是指引而非方针。--Temp3600（留言） 2022年6月1日 (三) 01:41 (UTC)

  @Temp3600：是指引没错，只是讨论标题没有改--🚊。铁路Railway ^论 2022年6月2日 (四) 00:44 (UTC)

---

🕗 公示7日，2022年6月8日 (三) 01:07 (UTC) 结束：7日无新发言，公示。--🚊。铁路Railway ^论 2022年6月1日 (三) 01:07 (UTC)

• (：)回应：“统一格式”和“同样格式”根本没有改变意思吧，改了跟没改真的没什么差别，跟“请放手调整，不必拘泥于本文”的矛盾仍然存在，只能继续反对。--Opky9407（留言） 2022年6月7日 (二) 13:57 (UTC)

• (：)回应：感觉完全无视了我提出的问题，我重复再提一次：“港铁中期翻新列车、新干线E2系电力动车组、日本国铁D51型蒸汽机车等香港、日本铁路车型都跟上面的架构有很大不同（JR东日本车辆形式里面就有大部分车型都跟上面的架构有很大不同），所以是很多车型都不适合，而不是少数。如果很多车型都要当成有“特殊之处”去调整，那么定出来的架构完全没有意义，所以还是(－)反对”。--Maccomcre（留言） 2022年6月8日 (三) 01:01 (UTC)

  "爱好者内容建议建议写在维基学院内。 "确定这些爱好者内容是维基学院的收录对象么？--百無一用是書生 (☎) 2022年6月8日 (三) 01:51 (UTC)

同Shizhao，早前都没留意到。放维基学院的条件是具有“研究”成分，不是爱好者内容就抛去学院的。--路西法人 2022年6月8日 (三) 04:03 (UTC)

已修正原创研究部分，上面格式的部分在下在想几天一下如何修改。--🚊。铁路Railway ^论 2022年6月11日 (六) 16:53 (UTC)

@Maccomcre、Opky9407、Shizhao、LuciferianThomas：已进行修正，还请指教。--🚊。铁路Railway ^论 2022年6月21日 (二) 15:04 (UTC)

---

🕗 公示7日，2022年7月7日 (四) 15:11 (UTC) 结束：超过7日无新意见，公示7日。--🚊。铁路Railway ^论 2022年6月30日 (四) 15:11 (UTC)

铁路1请同时于公告栏进行公示。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2022年7月1日 (五) 16:33 (UTC)

提议修改维基百科:防滥用过滤器

问题概述	目前，防滥用过滤器是反破坏的重要工具之一，隐藏过滤器日志和详情管理员和回退员都可见。
问题背景	此前曾出现过某些LTA可有效针对性地绕过防滥用过滤器的情况，尽管进行了快速的调整，但仍能多次被某些LTA破坏群在短时间内迅速绕过。 中文维基的回退员众多，既往任免门槛较低，因此可能会存在一定的破坏者通过GHBH策略或直接与回退员合作获取隐藏过滤器详情的情况。 (～)补充在过往的一些案例中，Tigerzeng等管理员观察到，破坏者未被新增的私有过滤器规则拦截而直接绕过了新增的那条规则。这是明确的监视过滤器更改并泄露过滤器规则，而非泄露日志详情的证据
我的解决方案	提议收紧可查看私有防滥用过滤器详情的人员，将其限制为管理员，隐藏过滤器日志对于管理员与回退员开放。 现行条文 用户可以查看所有公开过滤器的详情及触发记录，而隐藏过滤器则只对于管理员与回退员开放。 提议条文 用户可以查看所有公开过滤器的详情及触发记录，隐藏过滤器日志对于管理员与回退员开放，而隐藏过滤器详情只对于管理员开放。
此前的类似讨论	Wikipedia_talk:防滥用过滤器#引入过滤器助理（EFH）权限 Wikipedia_talk:防滥用过滤器#进一步讨论“滥用过滤器编辑者”事宜 Wikipedia_talk:防滥用过滤器#有关防滥用过滤器

--PAVLOV 2022年5月25日 (三) 13:27 (UTC)

(－)强烈反对，隐藏过滤器详情只对于管理员开放会大幅度降低高程度的反破坏，反破坏行动占多数的非管理员用户完全不知道过滤器在干嘛的会很大程度降低透过过滤器监察破坏或找出错判情况，也使用户促使管理员更新过滤器以及监察管理员使用过滤器的情况变得完全不可能。至今仍然不少LTA傀儡被过滤器拦截而封禁，硬撞几次撞出漏洞并不出为奇，不再开放隐藏过滤器详情予反破坏的回退员而言弊远远大于利。--路西法人 2022年5月26日 (四) 02:39 (UTC)

我不太感觉这种可能性存在。又不是刚执行OA过后，这种情况的出现机会非常小。你如果是7个月前来提案的话，我可能会支持。Sanmosa _{Χαίρε, ω χαίρε, Ελευθεριά!} 2022年5月26日 (四) 06:14 (UTC)

亡羊补牢为时未晚，现在进行有效的重整也不迟。况乎OA有针对回退员的封锁或除权吗？

( π )题外话与主题无关，阁下能否解释一下曾经在删除讨论中，要对我请求基金会行动是基于什么？我只是步骤性提删，我的确不知道我是做了什么需要基金会来介入一下？--PAVLOV 2022年5月26日 (四) 20:48 (UTC)

• (＋)支持, 至少不能让所有回退都接触到。目前已有回退内鬼，公开af结构只会让破坏者得利。--Temp3600（留言） 2022年5月26日 (四) 15:52 (UTC)

  对答如下，兼答路西法人。

  既往某攻击性账号破坏群，很显然不是通过撞几次找出过滤器漏洞的，尤见QCHM的早期傀儡，（近期傀儡破坏方式改变，故略去）高度特征性绕过过滤器，且在多次小修补后仍能绕过，通过硬撞的可能性不高于（1- 可能)。

  近期，哈密瓜油的用户查核案件，查核到傀儡user:ST680让我们看到lta傀儡甚至可以通过GHBH策略轻松混到巡查员，随后沉睡。如果某lta用相同策略，亦可快速得到回退员权限，随后沉睡，至于有没有，心证即可。

  这类的沉睡傀儡甚至是用户查核亦难以发现的，见早期对QCHM的用户查核，该用户特异性地修改技术信息导致用户查核失效，下面的推论以及可能的做法说出来就有教导破坏的嫌疑了。--PAVLOV 2022年5月26日 (四) 21:03 (UTC)

  @Temp3600：此说是否属实？如是，我感觉直接解任全体回退员能较快处理，反正安装了Twinkle后实际回退功能不会丧失。Sanmosa _{Χαίρε, ω χαίρε, Ελευθεριά!} 2022年5月27日 (五) 00:11 (UTC)

  提醒，系统级rollback和盖版本的编辑“回退”是两码事，详见WP:回退功能。——Sakamotosan路过围观 | 避免做作，免敬 2022年5月27日 (五) 01:04 (UTC)

  (＊)提醒：回退员除了rollback权限外至少还有方便的unwatchedpages和supressredirect这两大方便权限。--MilkyDefer 2022年5月27日 (五) 03:18 (UTC)

  巡查员也有unwatchedpages与supressredirect这2个权限，而且申请门槛更低，也有一定数量的回退员同为巡查员，因此我感觉影响不大。真的需要unwatchedpages与supressredirect权限的非巡查员回退员可以申请巡查员权限。Sanmosa _{Χαίρε, ω χαίρε, Ελευθεριά!} 2022年5月27日 (五) 04:34 (UTC)

  这点我是清楚的，但Twinkle机制与回退功能机制的效果其实差不太远，所以我才说“实际回退功能”。Sanmosa _{Χαίρε, ω χαίρε, Ελευθεριά!} 2022年5月27日 (五) 04:37 (UTC)

  “差不多”，指core-rollback可以绕过黑名单、过滤器，而盖版本编辑不能。——Sakamotosan路过围观 | 避免做作，免敬 2022年5月27日 (五) 06:03 (UTC)

其实我认为解决这一问题，应当对回退员的申请门槛进行改革，过去中维申请回退权限只是申请人提供一些（至少五个）回退实例用于佐证对回退权方针、破坏方针等的熟悉程度。但是回退员也有查看标记为私密的过滤器的过滤日志、查看被标记为私密的防滥用过滤器两项权限，在申请时恰恰却忽略了私密过滤器方面的职业操守。倘若这一提案得到通过，就会出现像路西法人所说之大幅度降低高程度的反破坏等情况，同样治标不治本。--绍💓煦^意见箱 2022年5月26日 (四) 20:00 (UTC)

反对，舍本逐末。如果只是担心规则暴露且技术上可行，回退员取消查看规则的权限吧，私下请求并由管理员告知（比如经过邮件列表）。--YFdyh000（留言） 2022年5月26日 (四) 20:04 (UTC)

技术非常可行。且这是目前最快的解决涉隐私的滥用过滤器暴露的方法。至于权限改革，或可日后再谈，因涉及权限改革之事往往在中维寸步难行。--PAVLOV 2022年5月26日 (四) 20:44 (UTC)

回退员的本职工作是批量运用回退功能，该功能的危害性相对不大（如上方用户的意见，TW也有回退，只是慢一些/不能绕过黑名单过滤器的限制等），也正是因为如此申请门槛才低，不涉及隐私问题。对于回退员来说，过滤器的日志记录了被阻挡的编辑的细节（试图添加/删除的内容，时间，用户名，摘要）等，对反破坏确实有益；但过滤器的代码本身对反破坏的贡献不见得非常大。上方有用户提到回退员查阅过滤器代码可协助管理员发现错判漏判的情况，但是：不见得回退员都熟悉正则表达式，以至于需要默认地给回退员这种权限；过滤器的错判漏判理应从结果（某笔适当/不适当的编辑->有/没有挡住）就能看出来。发现错误后除错和改错的任务可以让管理员一并完成，而无需回退员先除错，再交给管理员改错。最后，就算提高回退员门槛也无助于解决既有回退员中可能存在“内鬼”的问题。因此上，我认为“为过滤器查看权限的不当下放去提高回退员的门槛”，才是一种“舍本逐末”而且“治标不治本”的方法。--Antigng（留言） 2022年5月27日 (五) 05:50 (UTC)

技术上说，abusefilter-log-private和abusefilter-view-private是两个独立、可单独配置的权限。另外事实上，依过往讨论的存档，当时社群“几乎所有人同意可以给予某定用户（回退员）查阅隐密过滤器的日志，不过只有约一半的人同意可以给予某定用户查阅隐密过滤器的详情，其余一半则认为只应由管理员查阅”。将非公开过滤器代码的查看权限和日志的查看权限一并给回退员，可能本来就是wmf那边执行社群意见时出错所致。--Antigng（留言） 2022年5月27日 (五) 05:27 (UTC)

或者重提“过滤器助理”方案？——Sakamotosan路过围观 | 避免做作，免敬 2022年5月27日 (五) 06:05 (UTC)

本身我想提出这个，但考虑到引入一新权限的提议往往很容易在中文社群流产，而这类的权限调整则相对容易，故此先提出本提议。但阁下的提议非常有用，如阁下有空或可尽快起草。--PAVLOV 2022年5月27日 (五) 06:25 (UTC)

要是真的搞这个玩意，回退员的核心就只有回退一个功能，而实话和TW回退不是差特别多了。过滤器编辑的积压已经放了一整年了，也好先搞好过滤器再说？--Ghren🐦🕒 2022年5月27日 (五) 07:10 (UTC)

本来巡查员/回退员/IPBE/巡查豁免/模板编辑/MMS之类的权限都分别只有一个核心功能。另外过滤器编辑请求积压与否与该提案的关系不大。目前即使回退员能查看非公开过滤器的代码，他们也没有修改权限。无论修改前还是修改后，决速步都在管理员这一边。--Antigng（留言） 2022年5月27日 (五) 07:21 (UTC)

我会认为是反破坏的问题并不是在于什么人能看到过滤器，而是过滤器的更新是否可以贴近破坏者的行为。你上面不是谈到“而无需回退员先除错，再交给管理员改错”这事吗？要是回退员能处理了简单的前期问题，例如问题成立不成立之类的，我相信帮助还是会有的。如果你们真的打算要修的话，我想隐藏过滤器还是要解除掉一部分，例如Special:滥用过滤器/39之类的玩意，毕竟黑名单是公开的。--Ghren🐦🕒 2022年5月27日 (五) 07:44 (UTC)

我认为去检查过滤器规则的回退员不太多，拆分权限到单独的组或者渠道（如私密邮件列表）、工具（如编写于toolforge）会比较好。--YFdyh000（留言） 2022年5月27日 (五) 18:54 (UTC)

(－)反对：查看过滤器有助于反破坏，意见同路西法人。桐生ここ★[讨论] 2022年5月27日 (五) 08:53 (UTC)

查看过滤器“代码”何以有助于反破坏？--Antigng（留言） 2022年5月27日 (五) 08:55 (UTC)

Antigng如某名用户的某笔编辑被96号过滤器或134号过滤器所拦截，此时若不知道过滤器实施细节，对于一般用户来说很难从日志中得到有意义的结论。--Yining Chen（留言|签名页） 2022年5月29日 (日) 07:58 (UTC)

(－)反对：如此前有新手用户创建条目时被某私有过滤器拦截，经其求助后对照过滤器源码，最终找到被拦截的词汇为“垃圾”相关词语，经修改后得以发布。如果在这种情况下无法得知过滤器实施细节，那么想要从一篇文章中找到未知的“敏感词”会变得十分艰难。--Yining Chen（留言|签名页） 2022年5月29日 (日) 07:58 (UTC)

(：)回应第一，遇到这种情况，如果条目质量没问题，帮助新手的普通用户完全可以在确认的前提下直接代新用户发布，同时及时报告给管理员修复错误；如果条目质量有问题，那么应向其指出条目质量的问题和改善方式，“不带金丝雀”并不是解决矿井下有瓦斯问题的方法。无论哪种情况都不需要教导新用户绕过过滤器；“教导新用户绕过过滤器”这一行为本身也存在风险。第二，退一步说，即使存在个别场景“非查看过滤器源码不可”——这里恐怕也没有人否认“查看过滤器源码”的价值。但问题回退员的本职工作是回退、反破坏，其低申请门槛也是围绕这一工作的特性而设计的。下放重要权限给低申请门槛的用户组不是没有利，而是很可能弊大于利，被有心人士利用（本人不止一次从站外渠道获悉有LTA获取过滤器规则的状况）。就好比即使不考虑WMF的限制，我们也不会将“用户查核日志”的查看权限下放给管理员或回退员，供社群监督查核权限的使用状况一样。--Antigng（留言） 2022年5月29日 (日) 11:10 (UTC)

首先，AF应该是反破坏过程中十分有用的工具。而与CU不同的是，一般用户接触AF的概率应该要远远高于CU（除某些热衷于傀儡调查的用户及傀儡调查助理外），而且CU可能包含用户隐私信息，因此本人认为将AF与CU混为一谈可能并不妥当。第二点，目前是否有证据表明泄露过滤器信息的人是回退员而不是管理员？根据我的了解，在2020年-2021年期间有不只一名管理员被质疑为LTA提供相关信息（站内似乎曾有过相关讨论）。回退员数量约为管理员人数的3倍。换句话说，把这些回退员的abusefilter-view-private权限剥夺，未必能避免过滤器源码泄露。如果仅仅是因为某几名回退员的一些行为，便要剥夺所有回退员的相关权限，那么这对反破坏工作造成的困扰与过滤器源码泄露造成的后果相比，很难判断孰优孰劣。以目前的情况，提升回退员门槛或设立AFH/AFM貌似是更佳的选择。( π )题外话：据我所知，代替他人发布文章可能会存在一些著作权方面的隐患与问题。--Yining Chen（留言|签名页） 2022年5月29日 (日) 12:11 (UTC)

1. 提案人与本人都不否认“AF应该是反破坏过程中十分有用的工具”，但认为这种有用应该且仅应该体现在“通过过滤器日志查阅疑似滥用者的编辑细节”上。而本提案也无意于剥夺回退员查阅过滤器日志的权限，而是旨在剥夺回退员查阅过滤器代码的权限。然而您以及上方提出反对意见的用户却始终未阐明“剥夺回退员查看过滤器代码”的权限会对“反破坏工作”带来何种“困扰”。也如上方列出的旧讨论存档所示，社群甚至从一开始就没有共识将过滤器“代码”的查看权限下放给回退员。2. 本人过去从未看到有用户发起讨论来质疑管理员向LTA提供过滤器代码（LTA在站外途径提供的信息除外），如您有请列于此处供评估。此外，单纯比较管理员和回退员“人数”的意义并不大，两者的“遴选标准和门槛”均存在较大程度的差异。3. 最后，“设立AFH/AFM”与本提案不是二选一的关系。正如提案人所述，后续提案中可以考虑设立此类职位。--Antigng（留言） 2022年5月29日 (日) 12:50 (UTC)

(：)回应对这一提议下的诸多疑问做一个总体的回复。过滤器代码和过滤器日志本身是不同的，看过滤器代码则可导致可看到所有的过滤词汇，看过滤器日志相当于你能看到diff，看到他的编辑是如何的。

如果你能看到他的编辑是如何的，仅仅剥夺了看过滤器代码的权限，这难道也会降低反破坏的效率吗？

本提议与提升回退员门槛、引入AFH等并不矛盾，只是提升门槛、引入AFH等或许可事后再论。--仁爱亲诚的PAVLOV 2022年5月29日 (日) 16:24 (UTC)

提门槛和引入AFH此类提案在可以预见的一段时间内很难达成共识。--Yichen Ding（留言|主账户） 2022年5月30日 (一) 14:56 (UTC)----Yichen Ding（留言|主账户） 2022年5月30日 (一) 14:56 (UTC)

提供防滥用过滤器规则(ADM2)的第16条（设置过滤器私有的事由）、第18条（私有过滤器的泄密报告）作参考。--Kirk # 2022年5月31日 (二) 11:17 (UTC)

在配套措施完善之情形下，我认为应该考虑将权限交还予管理员。滥用过滤器内容之泄漏，对于本站反破坏工作之威胁明显较严重。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2022年5月31日 (二) 15:08 (UTC)

首先更正本案的“问题背景”。在过往的一些案例中，我（和其他几位管理员）观察到的是，破坏者未被新增的私有过滤器规则拦截而直接绕过了新增的那条规则。这是明确的监视过滤器更改并泄露过滤器规则，而非泄露日志详情的证据。其次，回退员的门槛过低确实是一个问题，但是现在来提高门槛一不能解决现任回退员中有不可信任之人的问题，二涉及回退员这个权限本身的定位，又需要更多讨论。从回退权限本身反破坏的工作范围来说，协助新手编辑也不是回退权限的目的。查看过滤器拦截日志已足以排查有问题的编者并追踪回退。因此(＋)支持。--Tiger（留言） 2022年5月31日 (二) 21:55 (UTC)

限制AF源码对反破坏有影响是不错，但如果LTA能看到源码，那反破坏简直就无法工作下去了。--Temp3600（留言） 2022年6月1日 (三) 01:36 (UTC)

前述讨论多次提到过滤器助理的问题。但感觉单设过滤器助理似无必要。这里提供一个思路，考虑到反破坏工作内容的相关性，可以令傀儡调查助理当然成为过滤器助理。--Kirk # 2022年6月2日 (四) 10:56 (UTC)

(－)强烈反对为傀儡调查助理增加特权。从最初的讨论中就已经确定“傀儡调查助理无任何别于其他用户的特权”。如果有AFH，那么就应该把申请相关权限的权力扩展到所有用户，而不应该只是限定于只有几名特定的用户才能有申请相关权限的权力（毕竟反破坏的范围十分宽泛，有多项反破坏工作与AF有直接关联，而不仅仅是SPI）。--Yining Chen（留言|签名页） 2022年6月3日 (五) 09:39 (UTC)

我的意见是如果涉及隐私问题，那在这里讨论是没有任何意思的，应该直接在全域站点反映，然后让他们立即移除相关权限。Sanmosa _{Χαίρε, ω χαίρε, Ελευθεριά!} 2022年6月3日 (五) 13:40 (UTC)

(？)异议，应该直接在全域站点反映，然后让他们立即移除相关权限？中文社群的事情在全域讨论很难成功有结论吧？--仁爱亲诚的PAVLOV 2022年6月8日 (三) 07:30 (UTC)

如果是涉及到隐私问题的事情的话，不及时处理会引起基金会的法律责任。我觉得只要有证据证明确实引发隐私问题，他们不能不立即移除相关权限。Sanmosa _{Χαίρε, ω χαίρε, Ελευθεριά!} 2022年6月8日 (三) 08:16 (UTC)

过滤器规则基本上不涉及用户隐私，只是反破坏层面的隐私。如果牵扯到隐私，没签署保密协议的管理员都无权接触了。--YFdyh000（留言） 2022年6月9日 (四) 00:14 (UTC)

(：)回应：

仍然抱持反对意见，我完全不认同撤除了回退员检视私有过滤器的权限就能完全堵截破坏者获得过滤器反破坏信息。与其说回退员泄漏过滤器信息，还不如说是他们已经清楚了解了过滤器的运作，直接各种花样来扰乱。印象中早期该等破坏者曾声称有管理人员提供协助，但自从OA2021之后好像越来越少听到这样的声称，且有关的破坏者的破坏力度也明显降低了许多。该等破坏者也曾在伪基声称持有某些（非维基媒体）站点的管理权和CU权，可以从此看到该等破坏者已经非常充分地了解如何钻反破坏的漏洞，也非常清楚反破坏工具的限制。该等破坏者懂得回避查核是否代表他们持有查核的信息？

再者，本站的过滤器一直以来并未能设计到能阻挡破坏者的扰乱行为，且未登录的编辑者都能在Special:AbuseFilter看到过滤器是否曾有更改，要知道有更新过滤器有多难？又请问自OA2021后你们观察到哪些破坏者仍有看似完全了解过滤器的资料而“绕过过滤器”的破坏行为？我甚至想说，挡的过滤器都写得不甚严密，何谈“绕过”？近期又有多少LTA破坏行径被写进过滤器里了？（心内知晓，不用回答）

PAVLOV又提及ST680的例子，在过往SPI的讨论中应该也有说过，不论是两个号都是他创、还是两个号都是被盗了，都有被同一人在同一装置控制过，同样会显示为 已确认。早于2021年4月已经声明过两个账户的关系，如果是破坏者盗号同样的密码就能都盗了。从ST680出现前的其他查核可见，这两个账户从未被监管员查出，代表当时并大概率未被持有其他傀儡账户的破坏者控制或使用。账户安全问题则不论是谁都是同样的问题，这个不会扯上只有回退员才会有这样的风险。

由于我未看到近期（2022年来）明显知晓过滤器信息而绕过的情况，故仍不能支持此提案。此外@Yining Chen，你大概率理解错了KirkLU的意思，他是说“当然成为”，并非“只有他们才能”，但我也是觉得不需要额外特定SPI/C是当然的AFH啦，如果设AFH，申请时管理员还是会按照其经验和可信程度来判断，SPI/C只是协助判断可信程度的因素而已，不用直接特定当然担任这些了。--路西法人 2022年6月9日 (四) 07:27 (UTC)

@Temp3600。另外想看看Xiplus有没有相关数据。另外，我可以给一个大胆的假设，就是回退员的账户在自己不知情的情况下被入侵，使入侵者得以看到过滤器相关信息。如果这个情况成立，所有回退员都会因安全性不能获得保障而被除权；我之前请辞回退员权限也是因为这个缘故。Sanmosa _{Χαίρε, ω χαίρε, Ελευθεριά!} 2022年6月10日 (五) 02:11 (UTC)

@Sanmosa：什么数据？--Xiplus#Talk 2022年6月10日 (五) 02:13 (UTC)

@Xiplus：2021年与2022年潜在因知晓隐藏过滤器内容而绕过隐藏过滤器的操作。Sanmosa _{Χαίρε, ω χαίρε, Ελευθεριά!} 2022年6月10日 (五) 02:16 (UTC)

怎么可能有这种数据，也难以现在回归去计算。--Xiplus#Talk 2022年6月10日 (五) 02:18 (UTC)

@Sanmosa这个要求不能做，就算有这类的数据，直接公布也是BEAN或是未经许可的信息披露。--仁爱亲诚的PAVLOV 2022年6月12日 (日) 01:53 (UTC)

哎，其实我应该ping Tigerzeng的。Sanmosa _{Χαίρε, ω χαίρε, Ελευθεριά!} 2022年6月10日 (五) 02:16 (UTC)

我相信提出这个问题的管理员们（包含我）根据他们使用过滤器的经验，都觉得将其解释为“过滤器规则被泄漏”比起“熟悉过滤器设计”、“得知过滤器已更改”更为合理。--Xiplus#Talk 2022年6月10日 (五) 02:31 (UTC)

(－)反对：一般用户也可以根据日志确定那些广告机器人有绕过滥用器的尝试方式，从而针对性的提议改进，隐藏并不能阻止机器人尝试其他方法绕过，但却能阻挡一般用户的可见性，等于把任务全交给管理员了。--脳補｡◕‿◕｡讨论 2022年6月14日 (二) 08:14 (UTC)

机器人？—— Eric Liu _{創造は生命（留言・留名・学生会）} 2022年6月14日 (二) 09:36 (UTC)

我支持该权限的调整，并建议引入过滤器助手之类的职务。毕竟回退员没有看到过滤器详情的必要。为什么？因为回退员不一定看得懂RegEx（比如在下，虽然看关键字也能猜出一些）。有志于研究过滤器的回退员可以申请高阶职务。 ——魔琴 [ 留言 贡献 ] 2022年6月15日 (三) 05:03 (UTC)

？人都去哪了 ——魔琴 [ 留言 贡献 ] 2022年6月23日 (四) 07:15 (UTC)

我觉得一个比较可行的办法是在取消回退员查看防滥用过滤器权限的同时，引入防滥用过滤器助理之类的职务供有需求者申请。Ericliu1912（留言） 2022年6月23日 (四) 12:01 (UTC)

• 看来是卡住了。较可行的方法是eric的大修方案。--Temp3600（留言） 2022年6月23日 (四) 14:42 (UTC)
  • 但仔细考虑实际场景可能会发现，AFH引入中维后的实际应用可能会十分尴尬。假若该提案成立，那么任何申请AFH的请求都可用“无必要检查AF详情”来回绝（但问题在于查看AF详情是有必要的）。几乎无法找到任何合理的申请AFH理由。--Yichen Ding（留言|主账户） 2022年6月24日 (五) 05:25 (UTC)

    不反对单独用户组。很多偶尔使用可以通过如WP:AR的机制查询（应有尽快响应，以及某些标准/机制减少曝光度），而熟练者通过申请自然而然（有LTA潜入的风险，但这是不得不承担，至少比现在更好）。--YFdyh000（留言） 2022年6月24日 (五) 05:32 (UTC)

拆分权限

目前讨论有一个走向是取消回退员的“查看私有过滤器详情”权限（abusefilter-view-private）并设置新的用户组接收。我建议可以从“1.申请资格；2.申请理由”两方面斟酌，看如何既能满足需要此权限的用户，又能一定程度上保护私有过滤器详情不被泄漏。 ——魔琴 [ 留言 贡献 ] 2022年7月1日 (五) 14:04 (UTC)

关于接下来的管理员投票

应上一次WP:500（Wikipedia:投票/是否在管理员选举启用SecurePoll）的共识，社群已经试行了一次安全投票（Wikipedia:申请成为管理员/和平奋斗救地球/第5次），但是接下来社群如何进行投票是没有充份共识的，引至出现了这种问题。因此，希望大家认真讨论一下：

1. 接下来的“申请成为管理员”，以及是其他管理人员职务是否使用安全投票？
   1. 如果决定不使用，（除了是在原地打转之外，）如何满足、解决“阻止拉票和人身威胁”的问题。
   2. 如果决定使用安全投票，如何决定程序，时间，方针对应的调整也是需要考虑的。

希望社群讨论。--Ghren🐦🕓 2022年6月5日 (日) 08:11 (UTC)

@Lanwi1、1233、中文維基百科20021024、Z7504、Yining Chen、AT、Ericliu1912、Sanmosa、Outlookxp。--Ghren🐦🕓 2022年6月5日 (日) 08:14 (UTC)

支持2，免得自己支持或反对被人议论纷纷。和平奋斗救地球的选举流程应该没什么大问题吧，一些人提名+正式投票。--中文维基百科20021024（留言） 2022年6月5日 (日) 08:20 (UTC)

@Ghrenghren：（我倒是觉得你先等Steward公布了正式投票结果以后才开这讨论串比较好，但现在开也不要紧）我觉得之后继续使用安全投票是必然的事情，虽说不可能阻止拉票，但不使用也阻止不了，而且人身威胁问题明显是基金会与社群极度关注的问题，必须优先处理，而且我也不认为基金会方面会容许社群在人身威胁问题上开倒车。我觉得程序可以比照Wikipedia:申请成为管理员/和平奋斗救地球/第5次来拟定，这样能省却不少麻烦。Sanmosa _{Χαίρε, ω χαίρε, Ελευθεριά!} 2022年6月5日 (日) 08:28 (UTC)

问题没法根除的情况下就选最好的一种解决方案。--中文维基百科20021024（留言） 2022年6月5日 (日) 08:44 (UTC)

（我是本来是这样打算的，但是有些人比较心急。）--Ghren🐦🕓 2022年6月5日 (日) 08:45 (UTC)

我个人支持继续采用安全投票。不过基于安全投票需要筹备的时间相对较长，因此建议集中提名，一次过投，这样比较有效率，比如可能一年两次提名期之类的。--AT 2022年6月5日 (日) 08:57 (UTC)

一年一次应该也够吧，但我考虑到Steward选举的情形，也同意集中提名与统一投票期的举措。Sanmosa _{Χαίρε, ω χαίρε, Ελευθεριά!} 2022年6月5日 (日) 16:06 (UTC)

就筹备时间的问题来说，一年两次或一年一次的区别应该不大。但相较后者而言，前者可让有意申请或提名管理员的用户不必等那么久。-Peacearth（留言） 2022年6月10日 (五) 20:44 (UTC)

事实上频率还可以更高。没有必要把选管理员搞得像在选监管员一样。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2022年6月11日 (六) 13:52 (UTC)

作为两次安全投票监票人，觉得有些事情是要提醒社群，在作出上述决定之前是必须考虑︰

是否允许使用Proxy︰以本社群组成部分而言，如果使用安全投票，禁止使用Proxy几乎等于阻断相当一部分合资格用户参与投票，但在投票意向隐藏之下，允许使用Proxy将会大幅度减弱监票效果。

临界状况︰因为安全投票与传统方法差异不少，若出现传统上临界状况，即75至80%时，行政员几乎无法介入去作出决定。例如使用中立票去判断候选人是否当选。

以上。--J.Wong 2022年6月5日 (日) 08:59 (UTC)

禁止使用Proxy几乎相当于不让居住在中国大陆境内的人投票，貌似免proxy使用Wikipedia比较繁琐。--中文维基百科20021024（留言） 2022年6月5日 (日) 09:05 (UTC)

避免（可能的）不正确信息造成误导，折叠。--东风（留言） 2022年6月8日 (三) 11:34 (UTC)

在登录账户的情况下使用proxy投票会有什么问题吗？--中文维基百科20021024（留言） 2022年6月5日 (日) 09:07 (UTC) 表现为部分投票用户使用IP相同或相近，有傀儡的可能。--东风（留言） 2022年6月5日 (日) 10:50 (UTC) 过往情况下不是有投票有资格限制嘛，那安全投票可以自动阻止不符合资格的人投票吗？而且以前投票的时候不也没有限制proxy。--中文维基百科20021024（留言） 2022年6月5日 (日) 11:06 (UTC) 但过去是明票，投票意向跟编辑记录都是一览无遗……--J.Wong 2022年6月5日 (日) 11:18 (UTC) 让监管员把参与投票的人都CU一遍？--中文维基百科20021024（留言） 2022年6月5日 (日) 11:22 (UTC) 不太明白……--J.Wong 2022年6月5日 (日) 11:43 (UTC) 维基百科:用户查核，总不见得不让中国用户投票吧。--中文维基百科20021024（留言） 2022年6月5日 (日) 12:14 (UTC) 对投票用户全部进行查核理论上可行，因为即使存在相同或相近IP，使用设备存在差异也会生成 不相关，但这无疑给监管员增加了（极大）工作量，我感觉他们的回应可能不会很积极。--东风（留言） 2022年6月5日 (日) 12:24 (UTC) 那正好可以借着这个机会把查核权要回来。--中文维基百科20021024（留言） 2022年6月5日 (日) 12:26 (UTC) @中文維基百科20021024：Wikipedia talk:申请成为管理人员/存档7中有说明基金会对于恢复zhwiki用户查核权的要求：以安全投票进行选举、用户查核员任期制（任期为2年）、基金会定除权机制（直接看链接吧，我懒得打出来了）、强制接受基金会培训、基金会定期稽核。我觉得先处理好管理员选举问题以后才处理恢复用户查核权的事情会比较有说服力。Sanmosa Χαίρε, ω χαίρε, Ελευθεριά! 2022年6月5日 (日) 15:54 (UTC) 真的建议两位先去了解一下什么是secure poll，然后再来讨论。--J.Wong 2022年6月5日 (日) 12:45 (UTC) 我对代理这部分的理解是这样的，那可能并不正确。--东风（留言） 2022年6月5日 (日) 13:23 (UTC)

中立票之意见是否会显示，以协助行政员判断结果？-Peacearth（留言） 2022年6月5日 (日) 13:22 (UTC)

几乎无法辨识留言是否由投中立票之用户留下。--J.Wong 2022年6月5日 (日) 21:44 (UTC)

原来如此。这样的话的确不太能用来协助判断。-Peacearth（留言） 2022年6月6日 (一) 03:21 (UTC)

安全投票的缺点是禁止使用Proxy的话就几乎等于不让居住在中国大陆境内的人投票，行政员也几乎无法介入去作出决定。--Lanwi1(留言) 2022年6月5日 (日) 13:56 (UTC)

vote.wikimedia.org在中国大陆似乎可以正常访问，但大陆用户可能很难适应在投票前先关闭代理，如要禁用可能很多用户会误操作。此外，这次安全投票也有可选填的投票附言，临界状况下行政员也许可以根据这些意见进行判断？但安全投票似乎很难延长，所以行政员可能只能判当选或落选，而没法延长投票了？--BlackShadowG Slava Ukraini! 2022年6月5日 (日) 15:04 (UTC)

vote.wikimedia.org在中国大陆不可正常访问，不用Proxy就无法投票。--Lanwi1(留言) 2022年6月5日 (日) 19:49 (UTC)

只受到IP污染罢了，hosts半直连。--Liuxinyu970226（留言） 2022年6月21日 (二) 07:35 (UTC)

考虑到基金会在此前因为安全理由而要求中国大陆用户自行请辞重要权限一事（注意当时基金会所提到的“安全理由”没包括Proxy），我有理由认为基金会并不信任中国大陆用户。另一方面，基金会一向并不鼓励使用Proxy。虽然禁止使用Proxy相当于不容许身处中国大陆的人投票，我认为这是唯一保证投票安全性的办法，而且基金会不会对此有任何意见。Sanmosa _{Χαίρε, ω χαίρε, Ελευθεριά!} 2022年6月5日 (日) 15:47 (UTC)

我认为这是滑坡谬误。我有理由认为这个“有理由认为”的理由不充分。--YFdyh000（留言） 2022年6月6日 (一) 11:58 (UTC)

还需要决定是否通知选举人投票事宜。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2022年6月5日 (日) 10:27 (UTC)

我觉得默认情况下没有必要，毕竟并不是所有活跃用户都关注人事任免。私以为可以像站内刊物那样制作一个发送名单，让用户自行选择是否订阅。--BlackShadowG Slava Ukraini! 2022年6月6日 (一) 12:20 (UTC)

同意--0906_{（回复请Ping我）} 2022年6月7日 (二) 14:34 (UTC)

对一部分前管理员参选不使用安全投票不会有问题吧？--Lanwi1(留言) 2022年6月5日 (日) 14:26 (UTC)

Lanwi1如果两种投票方式并行，是否应给予候选人自主选择投票方式的机会，或是由社群整理出一份“强制记名投票候选人名单”？这样看起来会不会有些不公平（无论是对采用SP的候选人或是采用普通流程的候选人）？而且这样做可能意味着社群需要准备两份投票规则。--Yining Chen（留言|签名页） 2022年6月5日 (日) 14:48 (UTC)

不建议让候选人自主选择，这可能导致不愿公开投票倾向（可能出于安全原因）的用户无法参与部分投票。--BlackShadowG Slava Ukraini! 2022年6月5日 (日) 15:07 (UTC)

支持继续使用安全投票。但继续使用安全投票可能意味着社群需要对RFA方针的全部内容进行讨论并重写。关于Proxy，在以往的投票中也未能有很好的方法来排除傀儡干扰（但在实际投票中，似乎是因为投票要求较高，所以很少见到过滥用傀儡投票），因此反对排除使用Proxy的用户。--Yining Chen（留言|签名页） 2022年6月5日 (日) 14:48 (UTC)

重写方针是比较简单的部分；甚至不需要废除既有之全部内容，只需要能够反映采用安全投票的现实即可。当然根据相关讨论，人事任免资格方针也得修一下了。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2022年6月5日 (日) 16:29 (UTC)

我要特别声明一点：我反对任何容许以旧投票方式进行选举的方案，并行方案也不行。只有安全投票能保证投票人的人身安全，因此只能统一使用安全投票。Sanmosa _{Χαίρε, ω χαίρε, Ελευθεριά!} 2022年6月5日 (日) 15:49 (UTC)

PS提一句，如果Proxy是非公开的话，那是不是容许的范围，因为meta:No open proxies提到“Publicly available proxies (including paid proxies) may be blocked for any period at any time.”，现有的IP的Proxy封锁似乎也是基于怀疑是VPS常用的AS来判断（是否包括Proxy探测不能确定），如果存在Private Proxy（只有一个用户专用的Proxy），那应该不属于meta:No open proxies的情况？——Sakamotosan路过围观 | 避免做作，免敬 2022年6月6日 (一) 02:32 (UTC)

如果考虑利用CU排查的话，结合安排安全投票的配置和CU工作的效率，可以这样安排：每个两个月集中安排一次投票（CU默认保留3个月的数据，每个月开一次密度可能过高，取一个中间值），投票完毕后由CU进行事后复核，先按用户名查一次，再集合IP信息反向查一次，并且结合IP的whois等信息排除掉普通用户和private proxy类（IP是属于VPS但只有一个用户）的用户，剩下的大量集中特定VPS的可以考虑为明确的Publicly proxy。这些数据也最好记录在cuwiki中作为日后复查。CU将怀疑在Publicly proxy的用户名单交给行政员，再结合投票结果，决定是否排除这些用户的投票，然后再宣布正式的投票结果？——Sakamotosan路过围观 | 避免做作，免敬 2022年6月6日 (一) 02:32 (UTC)

除了“让候选人自主选择”之外另一个选项是“让投票人自主选择”。愿意承担风险者可以沿用既有投票方式，但须列明合理理由；不愿承担风险者可以去安全服务器投票。若重复投票，以安全服务器上的投票为准。这样遇到临界情形也有判别共识的依据。--Antigng（留言） 2022年6月6日 (一) 05:51 (UTC)

此外避免“社群在人身威胁问题上开倒车”的关键在于要有良好的预防和应对“人身威胁”的站内机制。仅仅在管理人员选举层面各种加码并无助于从根源上解决问题，就算没有管理人员选举也有条目争议封禁争议等其它类型的争议，没有上述这种机制，样样都可能引发“人身威胁”。--Antigng（留言） 2022年6月6日 (一) 06:01 (UTC)

不行，我觉得受人身威胁者也会被威胁不得到安全服务器投票，所以不可容许安全服务器投票以外的任何投票方法。另外，提醒一下大家安全投票机制只会让大家知道谁已经投了，而没人知道谁怎么投。Sanmosa _{Χαίρε, ω χαίρε, Ελευθεριά!} 2022年6月6日 (一) 06:03 (UTC)

既然安全服务器可以看见谁已经投票，那么监票的行政员只要看到该用户投票，就可以自动将站内投票忽略，从而不会引发任何问题。此外，受威胁用户可以假意于站内页面顺应威胁者的意思，但在安全服务器表达真实意见。这样TA既表达了真实意见，也不再会受到威胁者的威胁。因此“以安全服务器上的投票为准”便可解决您所提出的问题。--Antigng（留言） 2022年6月6日 (一) 06:25 (UTC)

@Antigng：还有一点，由于选举期间所有人都能够看到了谁已经投票，所以进行人身威胁者是会知道受人身威胁者有在安全投票那边投票的，进行人身威胁者可以威胁受人身威胁者撤回在安全投票那边投的票。Sanmosa _{Χαίρε, ω χαίρε, Ελευθεριά!} 2022年6月6日 (一) 06:34 (UTC)

那么可以把这条信息关掉，使之对公众不可见，变成真正的安全投票。事后再让监票行政员汇总出一份结合站内外投票用户的名单，按字符先后顺序排列。--Antigng（留言） 2022年6月6日 (一) 06:37 (UTC)

@Antigng：实务上不可行。安全投票是P站那边负责的，所以那边在投票结束后会直接给出所有参与安全投票的人的名单，进行人身威胁者还是可以知道受人身威胁者有没有在安全投票那边投票（而且还有考虑到被基金会除权的人包括管理员与行政员）。我主张只容许安全投票的原因是进行人身威胁者会失去得悉受人身威胁者是否有投票的诱因。Sanmosa _{Χαίρε, ω χαίρε, Ελευθεριά!} 2022年6月6日 (一) 06:43 (UTC)

1. 修改代码能解决的问题实务上并不算是问题；wmf的技术员也是为实现社群需要功能而服务的“打工人”而已。
2. 此外，单纯“只容许安全投票”并不见得能使“进行人身威胁者”“失去得悉受人身威胁者是否有投票的诱因”。且不论威胁者可能非理性地照威胁不误，TA还完全可能“理性地”要求被威胁者在安全服务器进行投票，并出示投票的截图才放过。采用本人提出的方案，被威胁者遇到这种情况可以简单、假意地在站内投票。毕竟证有（投票）容易，证无（投票）难，威胁者有办法迫使被威胁者出示“在安全服务器进行投票”的证据，却没有办法迫使被威胁者出示“没有私下里去安全服务器投票、改票”的证据的，除非进行监视、非法拘禁等。--Antigng（留言） 2022年6月6日 (一) 06:53 (UTC)

   安全投票是可以改票的，被威胁者即使被要求放出投票的截图也可以重新再投一次，因此进行人身威胁者无法得知受人身威胁者在安全服务器的投票意向，当然监视、非法拘禁是另当别论。--BlackShadowG Slava Ukraini! 2022年6月6日 (一) 09:55 (UTC)

有理。但至少本人提出的方案相较于“只容许安全投票”不会更利于威胁者对被威胁者展开威胁。

试行的方案，只容许安全投票的场景下：威胁者可以威胁投票人参加安全投票并出示截图等证明，也可以威胁投票人不投票；投票人可以分别采取“事后改票”、“秘密参与安全投票”的方式应对；

本人的方案，容许投票人选择安全与非安全投票的场景下：威胁者可以威胁投票人参加投票并提供证明，也可以威胁投票人不投票；投票人可以分别采取“在站内假意投票，事后去安全服务器表达真实意见”、“秘密参与安全投票”的方式应对；

有安全服务器“托底”，两方案的安全风险应该是相当的。而本人的方案更利于解决Wong128hk提出的临界状况不好判断的情形。--Antigng（留言） 2022年6月6日 (一) 10:06 (UTC)

@Antigng：本人没能理解您的新方案是如何解决“临界状况不好判断”这一问题的。而且个人认为非安全投票与安全投票同步进行（该方案）很可能为投票增加了原本不存在的风险。--Yining Chen（留言|签名页） 2022年6月6日 (一) 10:30 (UTC)

过去的投票之所以临界情况可以交由行政员裁决是因为投票与理由一一对应，通过理由可以判断哪一方的意见更有力；安全投票无法实现这一点。同时保留安全与非安全投票两个选项的前提下，如果最终出现了临界情况，而通过检验发现安全与非安全投票两个样本没有统计显著的差异，就可以站内非安全投票的样本进行类似的判读，决定投票延长还是直接不通过。--Antigng（留言） 2022年6月6日 (一) 10:43 (UTC)

我觉得这会增强点票的难度。此外，由于同时使用两种投票方案需要比对重复票数，使用安全投票的用户的名单需要公开以便核对，这样就使威胁者可以要求被威胁者不投票。如果只使用安全投票，可以不公开投票的用户名单，以确保安全性。--BlackShadowG Slava Ukraini! 2022年6月6日 (一) 12:06 (UTC)

此外，我觉得即使是安全投票某种程度上也可以让行政员裁决临界情况：虽然用户的投票意向不会公开，但所有用户的投票附言会打乱顺序后公开，私以为行政员可以依据用户留下的意见来做出判决。--BlackShadowG Slava Ukraini! 2022年6月6日 (一) 12:10 (UTC)

一是如前述，可以从技术上限制普通帐户对已投票用户列表的访问，而仅允许监票行政员获取所有使用安全投票用户的名单。一旦用户出现在该名单中，站内投票自动作废；选举结束，站内外结果合并给出得票比例，监票行政员只给出站内外投票用户的总名单。这样威胁者就无从查证被威胁者有否使用安全投票进行改票。二是安全投票并不存在真正的讨论，参与者彼此看不见对方的留言，只是各说各话，难以归纳总结。此外，还不按照时间顺序排列，以至于无法识别“短期涌入大量支持/反对票”等异常情况。--Antigng（留言） 2022年6月6日 (一) 12:22 (UTC)

那不如在选举页面开启“投票意见”章节，使用户可自愿公布其投票意向和理由，也可回复他人的意见，但最终结果仍以安全投票的结果为准。这样既便于行政员判断临界情况，也降低了计票的难度，安全性也没有问题。--BlackShadowG Slava Ukraini! 2022年6月6日 (一) 12:38 (UTC)

对于将已投票名单改设置为对公众不可见的提案表示支持。但对于“投票意见”的部分，个人看法同Shizhao在下面说的，当前投票时已容许用户发表意见，已足以供大众及行政员判断是否合理，而无需知道该意见提出者是否投了支持/反对/中立票、更不需要知道是哪位特定用户所做出的。-Peacearth（留言） 2022年6月10日 (五) 20:40 (UTC)

这会不会就是共识制？--J.Wong 2022年6月12日 (日) 04:53 (UTC)

“投票与理由一一对应，通过理由可以判断哪一方的意见更有力”，这点完全没有必要，只要看理由是不是合理，根本不需要知道某个理由是谁说的、是哪方说的--百無一用是書生 (☎) 2022年6月8日 (三) 01:58 (UTC)

好像也是。不过至少“行政员可考虑中立票”的部分可能需要稍加修订，虽然实质上并无太大区别。-Peacearth（留言） 2022年6月10日 (五) 20:32 (UTC)

• 顺带一说，我觉得看投票留言比看中立票更能判断共识。以理服人嘛。--Temp3600（留言） 2022年6月7日 (二) 14:27 (UTC)
• 至少真的是不记名投票，意见那边有说过了。而且，投票期间结束后确实无法再投票，安全投票可行性是有的。就是...维基百科有无要创建一个页面叫做“Wikipedia:安全投票”？--Z7504非常建议必要时多关注评选（留言） 2022年6月9日 (四) 11:01 (UTC)

  等到正式确立相关方针再创建也不迟。--Yining Chen（留言|签名页） 2022年6月12日 (日) 09:06 (UTC)

  也是喔，不过看看独裁社群这样搞，好像玩不起安全投票一样，也就是说还是有人无法接受新格式的事实，就像Wikipedia:申请成为管理员/Lanwi1/第4次一样。如果明知选不上管理员的奉劝就别选了，以免浪费很多宝贵时间，又不代表使用安全投票就一定能选上。还有喔，喊拉票的风声去哪了？意思是说拉票经过安全投票过的也算过啰？--Z7504非常建议必要时多关注评选（留言） 2022年6月13日 (一) 08:36 (UTC)

  社群应该考虑拉票的问题。Lanwi第四次竞选符合先前共识（上次只说进行一次SP投票，没有说SP投票完就暂停RfA选举。 ——魔琴 [ 留言 贡献 ] 2022年6月13日 (一) 10:29 (UTC)

  然而拉票这玩意也讲过了啊，拉票是一种防不胜防的情况啊。只要有去讨论过GA评选的争议就知道了，GA评选就有出现过拉票的争议了。为何这个独裁社群没有想过呢？--Z7504非常建议必要时多关注评选（留言） 2022年6月13日 (一) 11:24 (UTC)

  问题是今后的RFA是否必须安全投票。--Lanwi1(留言) 2022年6月13日 (一) 13:42 (UTC)

  我觉得必须。拉票问题比起投票人受威胁的问题实在微不足道。Sanmosa _{Gottes Sonne strahl' in Frieden} 2022年6月13日 (一) 14:02 (UTC)

  还会被人拉清单--中文维基百科20021024（留言） 2022年6月13日 (一) 14:19 (UTC)

  我觉得这个投票非常好，但是中立票也能显示最好，而且不止管理员选举，罢免之类的也可以开启。--脳補｡◕‿◕｡讨论 2022年6月13日 (一) 15:31 (UTC)

• 所以呢？要不要用安全投票是不是也要用安全投票决定呢？看吧都没动静了。--Z7504非常建议必要时多关注评选（留言） 2022年6月16日 (四) 15:43 (UTC)

  从这个没有动静的看法，能否认为大家都觉得以后都要使用安全投票呢？上文除了讨论两者并行的方案外，不见明确的反对，如实在是没有反对意见的话，不如就公示？--Ghren🐦🕕 2022年6月19日 (日) 10:28 (UTC)

  @Ghrenghren：问题是结论是什么，没看出结论--SunAfterRain 2022年6月20日 (一) 00:16 (UTC)

  @SunAfterRain：我也没看出在具体怎样实行安全投票方面有什么结论。但是如果可以有个初部共识决定以后都是用安全投票的话，对之下来的讨论应该有帮助？--Ghren🐦🕙 2022年6月20日 (一) 02:42 (UTC)

  @Ghrenghren：如果不一次把这个讨论串了结的话，我认为下一场选举的准备时间还会拉长好几倍（拖在讨论时间）--SunAfterRain 2022年6月20日 (一) 07:39 (UTC)

  独裁社群最好的方式真的是能拖延就拖延，导致一个讨论串可能超过10万字节都不为过，没想到要不要用安全投票居然都可以那么的墨迹。--Z7504非常建议必要时多关注评选（留言） 2022年6月20日 (一) 11:34 (UTC)

• (！)意见：(＋)支持往后使用安全投票，至于有关此机制之技术性问题，窃以为应由基金会提供技术援助或解决（如投票界面、中立票、信息显示或隐藏、监验票等功能设计或修订）。个人认为，诸多站友既已花费大量时间、心力贡献于此平台，提供平台所需之条目、站务、维运、构想、智慧等宝贵要素，甚而亦有用户不吝捐款、出钱出力，且人事选举相关议题纷扰已久，实应获得有效解决。况且，中文社群亦已对相关议题发起讨论至今，可谓集思广益、尽心戮力了。综观站友意见，敝人斗胆表达意见和考量如下：

1.一切活动应以安全为优先考量。如果用户光是上网投个票都不安全，或需承担各种风险，甚至已经遭受到实质安全威胁，个人认为理当以自身安全为首要考量。若用户真已感受到任何形式之人身安全胁迫（不论被迫以何种形式如何表态），敝人建议：先暂停维基百科内相关活动，必要时请求当地司法机构协助，在条件许可下向基金会具体陈情以寻求适当协助。在此之前，使用界面和机制之规划应有所为。

2.投票过程中的已投票用户名单等动态信息不应对一般用户公开。

3.投票结果若处于临界状态，行政员可综合考虑用户投票意见和理由予以裁定。

4.安全投票机制若能明确标注显示“中立票”之附含意见较为理想；若最终安全投票界面仍不具此功能，且社群或具权限之监、验票人员仍期待便于识别中立票内含之意见，窃以为于投票须知明确规范：“当用户投下中立票，应于投票意见栏明确表达该票附具之意见或评价为‘中立’，以便选举结果之识别判读。”即可（如投票用户应于意见栏写明：“中立，基于候选人....，但仍.....”；“投下中立票。平日候选人之站务表现已具ＸＸＸ和ＯＯＯ，往后可再加强AAA，....”）。

5.若设立选举投票事宜通知机制，可供用户自由选择订阅。

6.其他技术性事项回归安全投票机制所具功能，具投票资格用户应皆可合规投票。

7.投票期间若发生异常或灌票现象，窃以为应可由具监、验票权限之站务人员核查处置。

8.现行投票页面上方已有“意见”区，欲发言、讨论、评论之站友应已有适合之区域，可供品评论议；站务人员选举中“讨论交流或评论表达以形成共识”之机制，窃以为此区块应可具相当之功能，与“实际投票功能或机制”并行不悖。若有其他考量，或可对于“意见”区之规划再行增补调整。

9.对于中立票之意义或代表性，过往已有相关讨论及争议，似悬而未决。敝人初步考古后认为，所谓中立票实则未必“中立”，观诸过往中立票之具体意见和内容，所显露之实质意向往往“偏向反对或不甚支持”（除去先置板凳、卡个位、看风向、只求个参与或真的没意见等未带实质意见内容者），亦即当投票用户对参选人感到不太满意或至少不够满意的情况下，仍希望参与投票并借此加以评价，以对候选人表达“委婉反对”、“尚待加强”之意见或评价；窃以为讲白了，其实几乎就是偏向“不太支持”。用户特地至此投下这一票，若对于候选人真毫无个人立场或意见偏好，又何必如此费力呢？个人认为其实就是不太支持参选人，可能基于种种考量，而不直接投下反对票，仅透过参与以表达意见或在投票结果临界时期待发挥效用。若实行安全投票机制，行政员应仍可依据投票用户留下的意见做出裁定，而投下中立票之用户亦应明确其自身投票性质；否则，所谓“中立票”之存在意义甚至可供深入讨论了。

以上为个人意见，供参。--Kriz Ju（留言） 2022年6月20日 (一) 06:01 (UTC)

又没动静了。(＋)支持安全投票，并认为现在就可以直接用普通投票的方式，来决定是否在以后的选举中采用安全投票。投票结束后，再讨论相关事宜也来得及。--50829!（留言） 2022年6月22日 (三) 06:13 (UTC)

还不是有人不知道普通投票和安全投票的差别吗？这种讨论都可以一直没动静，基本上不用玩了，既然完全说服不了人还要考虑选管理员？最后恐怕就是互相投反对、浪费时间而已的奇葩社群。--Z7504非常建议必要时多关注评选（留言） 2022年6月22日 (三) 15:30 (UTC)

• 以上似乎对于使用安全投票没有明确的反对意见。下一步应该讨论投票的举行时间（定期举办或有人提名就举办）和修订相关方针指引了。至于投票流程，个人认为暂行规定的“发表意见”至“执行结果”部分可以继续沿用。--Steven Sun（留言） 2022年6月23日 (四) 02:31 (UTC)

投票方式的共识

因为上方讨论过于冗长，因此在此开一个小节进行整理。希望能够推进讨论的进行。目前主要问题集中在以下两点：

• 使用安全投票后，无法考虑中立票的意见；
• 是否应转而使用安全投票与普通投票并行的方式。

但就目前共识而言，似乎并没有出现明确的反对使用安全投票的意见。是否可以认为大家已就“在接下来的投票中继续使用安全投票”这一点达成共识，并可以进行公示？或是需要举行投票来做出决定？另外，就以上两点问题，是否也可以通过举行另一场与此前类似的投票来进行选择？--Yining Chen（留言|签名页） 2022年6月23日 (四) 15:10 (UTC)

• 为何要并行呢？总之总有人搞不清楚何谓安全投票和普通投票的差别嘛，现在这个独裁社群连以后要不要实施安全投票都可以无法做决定了，真的无法说服大众，扯。请问如果要并行，那票是不是可以两边投阿？--Z7504非常建议必要时多关注评选（留言） 2022年6月23日 (四) 16:53 (UTC)

我认为安全投票的缺点是成本比普通投票高，也就是说安全投票太消耗精力。--Lanwi1(留言) 2022年6月25日 (六) 23:56 (UTC)

我最担心的是有人利用安全投票来恶意投反对票，最坏的结果是候选人退出维基甚至是轻生，所以对一部分候选人而言，普通投票好一些。--Lanwi1(留言) 2022年6月27日 (一) 17:00 (UTC)

(！)意见：不好意思，敝人不确定候选人轻生是否指特定人士；若然如此，我强烈建议精神状态不佳的站友敬请审酌衡量自身身心状态，以个人安全和健康为重，如果的确身心状态不佳，请立即停止所有维基百科相关活动，并寻求适当心理或医疗协助。况且，若用户心神状态确实如此，显然不适合参与人事选举等较可能产生火花之社群活动，亦敬请站友多多关心身边的社群用户。--Kriz Ju（留言） 2022年6月27日 (一) 19:03 (UTC)

谁想轻生的话我也不知道，大陆用户轻生的可能性比港澳台用户高，因为大陆的言论管制，不能在现实生活中诉求自己的遭遇，所以更要多多关心依赖维基百科的渴望自由的大陆用户。--Lanwi1(留言) 2022年6月28日 (二) 00:36 (UTC)

中国大陆用户是否轻生率较高敝人不认为可以从这一个简单的投票界面和主题加以验证，而仰赖投票界面表达意见自由致影响个人生命安全和身心健康或产生可能疑虑，我认为显然亦非健康思维和应有举措。敝人会建议，请各位站友多多关注生活和人生的美好面向，切勿因投入任何网络相关活动致影响生活平衡。与诸位站友共勉之。--Kriz Ju（留言） 2022年6月28日 (二) 04:58 (UTC)

没什么屁用，就算用实体投票一样也可以恶意投反对票。--Z7504非常建议必要时多关注评选（留言） 2022年6月28日 (二) 14:08 (UTC)

实体的话可见，现在中维帮派化太重。--Lanwi1(留言) 2022年6月28日 (二) 14:33 (UTC)

为什么我觉得恰恰相反？反倒是非安全投票下容易造成心理问题？（如果候选人的确有的话）非安全投票下投票会有压力。--日期20220626（留言） 2022年6月28日 (二) 14:36 (UTC)

对易被帮派排挤的候选人的而言，在安全投票下容易造成心理问题。--Lanwi1(留言) 2022年6月28日 (二) 14:57 (UTC)

不，对易被帮派排挤的候选人的而言，在没有安全投票的情况下才容易造成心理问题。请不要将以前WMCUG干预RFA的情形视而不见。Sanmosa _{Királyunk s a közhazát} 2022年6月29日 (三) 01:56 (UTC)

对易被WMC排挤的候选人的而言，不在安全投票下就容易造成心理问题，但我所说的帮派指的是反WMC的。--Lanwi1(留言) 2022年6月29日 (三) 03:17 (UTC)

我感觉把你说成同时存在的两个“帮派”比较一下的话，就算这两个“帮派”都真的同时存在，“反WMC的帮派”所产生的问题明显不能与“亲WMC的帮派”所产生的问题相提并论，至少“反WMC的帮派”不可能像“亲WMC的帮派”一样有群体策划的欺凌（包括但不限于网络上与现实上）。Sanmosa _{Királyunk s a közhazát} 2022年6月29日 (三) 15:25 (UTC)

亲WMC的帮派和反WMC的帮派不是同一类型，WMC的目的是获得地位，反WMC的帮派的目的是守住地位并排除WMC，此外还有一部分人的态度太强横，让人难以亲近。这两个帮派的区别是反WMC的帮派的地位比亲WMC的帮派高，我还认为有地位的违规者的危害比没地位的高。--Lanwi1(留言) 2022年6月29日 (三) 16:05 (UTC)

以前公开投票的时候有相互吵架的，对投反对票冷嘲热讽的，还有我上面讨论提到的有人投了反对票还会被人拉清单，就没发现公开投票好在哪里。--日期20220626（留言） 2022年6月29日 (三) 03:08 (UTC)

中文维基百科过去有人事任免时的集体行动，今后也不会完全消失。个人的观察是此类集体行动受胁迫的成分少，人情的成分多。公开投票下，此类集体行动藏不住，谁重人情而眛事实，清清楚楚。倘若前几年WMC活跃时就启用了安全投票，想必只会掩盖而非制止媚世者的不当行为。至于上面说到的身心健康问题，也不止和人事任免相关，维基百科上有各种各样的事情会招致攻击；个人领教过WMC群组内的肆意谩骂，和人事任免无关的亦有很多。仅把RfA换成安全投票，恐怕治标不治本。上面讨论中支持安全投票者多，但本人的意见不同，供诸君参考。--Lt2818（留言） 2022年6月29日 (三) 06:16 (UTC)

对，过去的拉票和在RfA时恶意投反对票基本上以人情的成分居多，例如以看不顺眼为由恶意投反对票。按照中维的现状，安全投票就是治标不治本，一切根源就是心怀不轨的人，WMC拉票的动机也包括对心怀不轨的人感到不满。--Lanwi1(留言) 2022年6月29日 (三) 09:46 (UTC)

我不支持完全采用安全投票而直接弃过往的投票方式不用，二者各有利弊。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2022年6月29日 (三) 17:09 (UTC)

那么哪些情况下使用安全投票，根据候选人意愿吗？--日期20220626（留言） 2022年6月29日 (三) 17:15 (UTC)

(！)意见：窃以为若技术可行，折衷方法或可考虑为“双轨并行”，两边界面重复投票者计属废票，且该用户视为扰乱选举。若候选人于表态参选时指定选择个人偏好之特定形式（不论“公开具名”或“安全匿名”形式），于七名用户投下反对该候选人指定形式之反对票后，亦即相当于同时投下“反对候选人和其指定形式”之反对票（相当于双重反对），则回归双轨并行制。之所以为七名反对者，敝人取自“罢免连署投票”之门槛；而同时反对候选人乃至出具理由反对其偏好形式，可见反对用户对于参选人之“强烈反对或不信任”，以致其偏好之投票形式皆反对（此时投下之七票反对票为公开投票），此时则回归双轨并行。个人意见，供参。--Kriz Ju（留言） 2022年6月29日 (三) 20:39 (UTC)

如果无法决定最终“胁迫投票”和“监督拉票”最终应选那个，似乎只能考虑某种双轨并行制。Kriz案二的“双重反对”部分不是很支持。看看其他人的意见。 ——魔琴 [ 留言 贡献 ] 2022年7月1日 (五) 13:26 (UTC)

上面就讲过了嘛，这社群连看都没在看，还在双轨投票并行制？完全说服不了人就说了吧，真是有够扭捏的。--Z7504非常建议必要时多关注评选（留言） 2022年7月1日 (五) 15:57 (UTC)

修改巡查豁免权的简介及申请条件

简介	修改巡查豁免权的简介及申请条件
问题背景	目前，本站权限申请方针对“巡查豁免权”的描述为：“为减轻巡查员工作量，可信用户均可获本权限。”申请要求为：“熟悉方针及指引且经常创建页面者，许可者均可依其判断予权。前句所述以生者传记及关注度指引为首重。”
我的观点	“可信用户”这一表述过于宽泛。一名用户在解决技术问题方面可信，不必然意味着其在创建页面方面可信，反之亦然。巡查豁免权关乎的是创建页面的品质是否足以豁免巡查，此处应予以细化，明确为“在创建页面品质方面受信任的用户”。申请条件作配套性修改，为“经常创建页面且创建的页面品质均良好者”。 现行方针对巡查员、回退员等其它权限的申请要求包括“最近一年内没有受到封禁（不合理封禁除外）”，而更需要社群信任的巡查豁免者权限却无此要求。本站一年前曾出现过因条目质量问题被封禁的用户数月后却获得巡查豁免权的极不理想状况。固然，上一条修改已明确要求授权前检查被授权者创建的页面的品质；为巡查豁免权补回“最近一年内没有受到封禁（不合理封禁除外）”的要求，一方面有助于进一步判断用户受信任的状况，另一方面因为“一年内没有受到封禁”是相对客观的条件，可以迫使管理人员在授权之间进行例行性、机械性的检查，从而进一步减少管理人员的疏失导致上述“极不理想状况”发生的可能性。
我的解决方案	现行条文 巡查豁免权 ... 为减轻巡查员工作量，可信用户均可获本权限。持权用户所创建页面会自动标示为“已巡查”，而毋须接受侵权等多项检查。因此，许可者需肯定获权者为可信用户。本权限毋须由申请者本人提出申请。 ... 巡查豁免者：熟悉方针及指引且经常创建页面者，许可者均可依其判断予权。前句所述以生者传记及关注度指引为首重。 ... 提议条文 巡查豁免权 ... 为减轻巡查员工作量，在创建页面品质方面受信任的用户可获本权限。持权用户所创建页面会自动标示为“已巡查”，而无需接受侵权等多项检查。因此，许可者需肯定获权者为创建页面品质方面受信任的用户。本权限无需由申请者本人提出申请。 ... 巡查豁免者：最近一年内没有受到封禁（不合理封禁除外），熟悉方针及指引，经常创建页面且创建的页面品质均良好者，许可者可依其判断予权。前句所述以生者传记及关注度指引为首重。 ...

该修改妥否？请社群审议。--Antigng（留言） 2022年6月9日 (四) 03:46 (UTC)

觉得可以，不过“在创建页面品质方面受信任的用户”要如何认定？--冥王欧西里斯（留言） 2022年6月9日 (四) 03:56 (UTC)

具体条件为“经常创建页面且创建的页面品质均良好者”。再细就没办法细化了，毕竟问题页面各有各的问题。--Antigng（留言） 2022年6月9日 (四) 04:44 (UTC)

基本(＋)支持。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2022年6月9日 (四) 04:15 (UTC)

75个条目限制被删掉了？--中文维基百科20021024（留言） 2022年6月9日 (四) 05:49 (UTC)

那是非方针的信息页中的建议门槛，从来不是正式方针的内容。--Antigng（留言） 2022年6月9日 (四) 05:56 (UTC)

大致(＋)支持。当然这对于短时间内大量刷条目的用户不大友好。--🔨（留言） 2022年6月9日 (四) 09:07 (UTC)

如果不是以获取权限为目的的刷条目的话其实没什么影响。--中文维基百科20021024（留言） 2022年6月9日 (四) 10:30 (UTC)

我这里说的大量刷条目一般都是刷内容短小的，这类条目就算不是小小作品，在品质上也绝不能说的上能够受信任，如果有infobox的话可能另说。--🔨（留言） 2022年6月10日 (五) 01:15 (UTC)

不过品质受信任如果有更具体一些的标准可能更好。--🔨（留言） 2022年6月10日 (五) 05:36 (UTC)

基本(＋)支持。--YFdyh000（留言） 2022年6月9日 (四) 09:40 (UTC)

(？)疑问：维基百科的口语使用“毋须”而非“不须”真的妥当吗？顺便再说一个：现在的条目要再建一个新的真的很难，别再总是用“75个条目”作为刻板印象，但为了小作品和小小作品标准而有多起争议，所以“75个条目”并非好建议。因为可以创长篇75个条目（如果创建条目能力很强的话），但也能刻意创75个小作品和小小作品的条目。--Z7504非常建议必要时多关注评选（留言） 2022年6月9日 (四) 10:11 (UTC)

“75个”从来不是正式方针的内容，认为“75个”是方针内容自然如您所说是不正确的“刻板印象”。相关信息页中的建议随时都可以随方针正文的更正而更新。--Antigng（留言） 2022年6月9日 (四) 10:20 (UTC)

个人认为，“而毋须接受侵权等多项检查。”应该变成“而不须接受侵权等多项检查。”。维基百科的口语至少也该有吧，每个人都知道“毋须”吗？就好像“系指”（是指）那种用法，说实在很不恰当。最后要说的是，个人并不会考虑这个权限，这个权限不等于就是免死金牌、不因破坏而封禁，所以就支持反对的部分不表态了。--Z7504非常建议必要时多关注评选（留言） 2022年6月9日 (四) 10:26 (UTC)

改成“无需”如何？--Antigng（留言） 2022年6月9日 (四) 10:28 (UTC)

“无需”应该比“不需”好一些，可能就中文用法习惯上差异而已，就“无需”吧。--Z7504非常建议必要时多关注评选（留言） 2022年6月9日 (四) 10:31 (UTC)

站内在方针/通知模板/讨论中用类文言，是一些维基人的习惯，约定俗成了，虽然我不赞成，但总会有。--YFdyh000（留言） 2022年6月9日 (四) 10:46 (UTC)

“毋须”显然并非高度艰涩之词汇，未见更改之必要。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2022年6月10日 (五) 07:20 (UTC)

修正妥当，支持。另，以个人理解，其实巡查员其实比巡查豁免者更需要社群信任。巡查员本身就自带巡查豁免，在此基础上还要巡查其他用户的条目。我认为用户成为巡查员应以至少先适合持有巡查豁免权为基础，这样才是比较合理的、循序渐进的信任路线。--Kirk # 2022年6月9日 (四) 10:22 (UTC)

那顺带把巡查员也一道修订？此外比巡查员更高的管理员也要类似的条件吗？或者说因为管理员有过投票程序，所以这一点可以免？--中文维基百科20021024（留言） 2022年6月9日 (四) 10:28 (UTC)

个人不确定是否应修订，两权限皆不是以硬门槛作为唯一标准，私以为更重要的是理解权限和授权的思路或可作转变。即便有必要修订，亦不宜并案讨论，以免本案讨论时间被连带延长。--Kirk # 2022年6月9日 (四) 13:06 (UTC)

这个以前讨论过，但进阶难度上不现实。自带巡查豁免本质是技术问题。--YFdyh000（留言） 2022年6月9日 (四) 10:36 (UTC)

我觉得或可从授权理念上理解，巡查豁免权限合格者为创建页面品质良好；巡查权限合格者为除创建页面品质良好外，尚在巡查新页面（提挂适当的模板、进行适当的快速删除提报）方面展现出一定的能力。这既不涉及技术上的问题，也不要求方针上有显著的变动。大致想法是这样。（上述观点只是因为提案人在“我的观点”部分的发言而引发）--Kirk # 2022年6月9日 (四) 13:11 (UTC)

巡查豁免 = 创建页面都不被删？还是 巡查豁免 = 创建页面品质都优良？我以为社群普遍觉得是接近后者。--Xiplus#Talk 2022年6月9日 (四) 15:29 (UTC)

如果是“为减轻巡查员工作量”，那标准介于两者中间，比如条目至少内文都要有来源；格式、标点符号都要对，Wikidata有没有连上。就是让巡查员看了不用挂板或手动改善的那种地步。--中文维基百科20021024（留言） 2022年6月9日 (四) 15:39 (UTC)

个人是能赞同上述“比如”所描述的条目水平。我个人认为，这些既是巡查的目标，又是对持有巡查豁免权限用户的合理期待。--Kirk # 2022年6月10日 (五) 02:48 (UTC)

如果是朝着创建条目品质都优良的话那也没必要搞巡查豁免了，因为一天下来都没有几篇条目能达到这个标准。--中文维基百科20021024（留言） 2022年6月9日 (四) 15:42 (UTC)

讲难听一点就是这种“豁免权”本来就是种笑话了。如果写了一堆条目就能换来免死金牌、不因破坏而封禁可能还有用吧，但就不是嘛，上面也说过了。所以维基人写了一堆条目只是为了这种可能没什么实质意义的权利？还是说这种真的是这些写了一堆条目的所谓成就感吗？--Z7504非常建议必要时多关注评选（留言） 2022年6月9日 (四) 17:12 (UTC)

关于Xiplus君的论述，我自己主要想法有两方面：

• 其一，我认为社群普遍认知的巡查豁免只比前者略高，且远不及后者，原因有二：
  1. 巡查和巡查豁免是相联系的：社群对巡查工作的理解，不是审视所有不足以达到优良条目标准的条目，而是通过巡查排除不应存在（需要快速删除或存废讨论）或存在基本问题（需要即行修缮或使用维护模板加以注释的）的新条目。那么对应来说，豁免巡查就是信任此人创建的页面——通俗来说——通常不会被删、不用挂模板。
  2. 将非优良确立为巡查目标缺乏意义：条目提升到优良往往非常复杂，需要逐个条目仔细思考，且更加不“公式化”、更“个性化”；巡查量巨大，巡查的目标本应是通过巡查保证基本质量，解决或者至少标记一些能用模板说清楚的通病。当然，我能理解您本意并无这方面意思，但这一点其实同第1点相关，即对巡查和巡查豁免的其他具有高度对应关系，如果把“巡查豁免 = 创建页面品质都优良”代入进这种关系，会导致不可行。
• 其二，其实我的要点甚至不主要在于说，巡查、巡查豁免应当达到怎样的绝对高度（优良也好、不被删除也好）。而应当说巡查应当达到具备巡查豁免的要求基础上，并在一定程度熟悉巡查工作。纯口语来说：
  1. 巡查员既然有豁免权，那么他自己创建条目的通常质量，应当达到豁免水平；
  2. 巡查员既然有能力审视别人的条目，那么他至少自己创建条目的时候，也同样知道需要达到哪些最基本的要求。

我个人大致是这样一个逻辑，以上。--Kirk # 2022年6月10日 (五) 02:39 (UTC)

我认为，新页面巡查有“自动标记自己已巡查”功能是源于技术因素而不一定是业务因素（例如给用户留言、提删讨论等可能需要新建页面，而这些是没必要让别人巡查的），当然有能力指出别人新页面（条目）存在基本的质量问题，可能本身也需要有能力编写出避免这些问题的新页面（条目）（但不排除某些人会钻牛角尖，认为后者不可能存在）。——Sakamotosan路过围观 | 避免做作，免敬 2022年6月10日 (五) 02:51 (UTC)

私以为“最近一年内没有受到封禁”并无必要，用户被封禁的原因可能是文明等方面的原因，不一定是条目质量的原因（例如写了数百篇GA FA但因出言不逊一年被多次封禁的7君），也许可以改为“最近一年内没有因条目质量问题受到封禁”。--BlackShadowG Slava Ukraini! 2022年6月10日 (五) 12:41 (UTC)

有道理。--中文维基百科20021024（留言） 2022年6月10日 (五) 12:48 (UTC)

(？)疑问：什么叫做“最近一年内没有因条目质量问题受到封禁”？封禁不都是因为某些个人原因（如破坏、文明）才有可能的吗？完完全全跟“要不要写条目”无关啊。如果说一年内不写任何条目就会被封禁，那早晚都会被封的（生命早晚都会死的），为何不整个砍掉就好了呢？现在搞得好像怎么改都不对。比如说“经常创建页面且创建的页面品质均良好”是谁来判断？用何种理由判断？至于“最近一年内没有受到封禁（不合理封禁除外）”这句嘛，没什么大意见。只是还是那句，这种权利就是上面已经讲过的“可能毫无实质意义的权利”、“并非免死金牌”。就像那75个条目，那种刻板印象的标准真的观感很差。--Z7504非常建议必要时多关注评选（留言） 2022年6月10日 (五) 14:38 (UTC)

大体上支持。但“文明等方面”的问题乃至封禁不必然不应在授予巡查豁免权时纳入考量。宣称条目所有权，霸占条目不允许他人进行合理的修改、加挂合理的模板也属于此类问题，对于相关用户，如授予巡查豁免权将令其所创建的页面变得更为不可见，可能变相地助长此类行为。--Antigng（留言） 2022年6月10日 (五) 15:47 (UTC)

理解，确实我们很难清晰界定封禁原因是否完全与条目质量无关，有文明等方面问题的用户，其创建的条目可能也会受到一定的影响，换言之未必能完全得到社群的信任，也确实有必要接受巡查员的检验，授予巡查豁免权还是需谨慎起见。--BlackShadowG Slava Ukraini! 2022年6月13日 (一) 13:15 (UTC)

(＋)支持理由合理--飞马🎠🎈 2022年6月11日 (六) 14:00 (UTC)

(＋)支持修改的到位--脳補｡◕‿◕｡讨论 2022年6月13日 (一) 16:04 (UTC)

• 从最近的港铁车站艺术品列表侵犯著作权事件中，很明显的可以得知“，而毋须接受侵权等多项检查”应当砍掉。故应该修订成：

现行条文 巡查豁免权 ... 为减轻巡查员工作量，可信用户均可获本权限。持权用户所创建页面会自动标示为“已巡查”，而毋须接受侵权等多项检查。因此，许可者需肯定获权者为可信用户。本权限毋须由申请者本人提出申请。 ...

提议条文 巡查豁免权 ... 为减轻巡查员工作量，在创建页面品质方面受信任的用户可获本权限。持权用户所创建页面会自动标示为“已巡查”。因此，许可者需肯定获权者为创建页面品质方面受信任的用户。本权限无需由申请者本人提出申请。 ...

要不然就如同上面讲过的根本是种笑话而已，看来这个侵权的FL已经又再次验证了。--Z7504非常建议必要时多关注评选（留言） 2022年6月16日 (四) 06:31 (UTC)

(＋)支持，这改动我也支持，著作权问题是维基立足根本，无法依靠自觉来维护。但是目前wiki程序应该不支持单独标记为著作权已巡查。----脳補｡◕‿◕｡讨论 2022年6月17日 (五) 08:06 (UTC)

所以打从一开始就说这种权限就跟笑话没有两样嘛，这个独裁社群真的应该重新检视是否要较严格的审慎检查著作权之问题，并非所有编辑者都会在编辑时注意到是否有侵犯著作权之问题。--Z7504非常建议必要时多关注评选（留言） 2022年6月18日 (六) 14:07 (UTC)

---

目前Antigng的提案似乎未见明显反对，Antigng是否提请公示？Ericliu1912（留言） 2022年6月28日 (二) 06:12 (UTC)

Antigng应该把上面已经提出的事实做出回应才是，而并非一昧的公示却继续放任侵犯著作权之问题。--Z7504非常建议必要时多关注评选（留言） 2022年6月28日 (二) 14:10 (UTC)

豁免条目复审机制

1. 提供另一个角度。相较于上方详细讨论获权门槛，个人建议定期（如每周）生成一组列表，列明因豁免而未被巡查的条目，便于有志者选择检查、改善或了解。并可选做简单标记，例如已检查/已批量检查/已标注问题/讨论中/问题已解决等。频出问题的豁免者可参考WP:REVOKE的处理机制。
2. 巡查豁免应该视作一种行政上的减少巡查积压的“免检”手段，尤其是用于大量创建同主题条目的编者，相信条目满足基本要求且不是破坏。但免检不宜不检，更应该“抽检”，放在“聚光灯”下，在一定程度上成为范本和近期动态，以及条目评选候选。
3. 身负巡查豁免时，其实个人更多感觉到压力（更重责任）和某些不便。这意味着不再有至少一名编者为我“查漏补缺”，如果条目出现疏漏，更难以被早期察觉，冷门条目也更难得到一则评审和意见（即便标注{{校对翻译}}等；除非积极提报DYK等），无利于条目和个人提升。也因为该权限毋须申请，可能很少有人主动要求解除该权限，相当于驳回好意和增加巡查工作量。
4. 此外，该机制也可检查列出移动自用户或草稿命名空间，且未被巡查的条目，这些页面常被巡查工作所遗漏。
5. 以上意见不影响上方的方针修订进行。--YFdyh000（留言） 2022年6月11日 (六) 09:27 (UTC)

   (＋)强烈支持。应该对于巡查豁免者所创建的条目进行抽查。——范博_{邮局 · 探讨 · 留名} 2022年7月1日 (五) 10:38 (UTC)

上述第一条的实施并不需要站内共识，任何机器人操作者都可以创建维护相应的WP:资料库报告页面。有了页面后，愿意参与的用户即可执行上述第二条和第四条。--Antigng（留言） 2022年6月13日 (一) 16:36 (UTC)

不需要站内方针和批准，但对站内共识和上述讨论会产生影响，所以放这边了。简单来说，如果事后“复查”相对有效，那么巡查豁免的批准门槛就无需很高，并有助于被豁免条目的改进和权限合理性。如果巡查豁免权被软件补丁拆分，更是如此。
WP:资料库报告我初次见，似乎关注度不高。已手动生成一期列表，但有效率心里没谱，如何自动化暂不了解。类似的百家号来源清理响应不多。--YFdyh000（留言） 2022年6月13日 (一) 17:01 (UTC)

• 社群应该再把上面已经提及过且很明确在FL评选中发生的侵权问题重新检视才是，这种讨论估计也得花上不少时间。然而居然已经至少4天都没有动静了，表示社群对于侵犯著作权实在太过于松散而不想严格实施嘛。是否跟一开始就讲过“该权限就是笑话”符合呢？--Z7504非常建议必要时多关注评选（留言） 2022年6月20日 (一) 11:37 (UTC)

分类索引排序规则问题

关于排序规则，看了分类讨论区的存档，好像一直有所争论，没有明显的共识，现在普遍使用的排序规则是什么呢？有统一了吗，求解答。--Rachel.cdy（留言） 2022年6月12日 (日) 10:55 (UTC)

看分类内页面如何排吧，预设为Unicode（基本符合部首顺序），也有设为原文、汉语拼音、日语罗马字……的，还有使用㏮等给分类内页面分组的。--绀野梦人 2022年6月15日 (三) 12:21 (UTC)

没有共识，自然也就没有办法统一分类排序规则。Ericliu1912（留言） 2022年6月23日 (四) 02:24 (UTC)

是不是除了港澳之外，目前都有在使用汉语拼音，感觉可以用汉语拼音排序。如果不能统一的话，感觉至少可以添加个汉语拼音排序小工具。现在按照部首排序，应该大多数人看不懂。--Kethyga（留言） 2022年6月23日 (四) 02:52 (UTC)

• 开发小工具当然是好事。统一分类排序恐怕就不是了。--Temp3600（留言） 2022年6月30日 (四) 15:50 (UTC)

关于日食小作品

本人在测试申请的机器人时，发现有蛮多日食条目都超过250字。管理员Shizhao也认为，超过200字并不是说条目就不是小作品了，可以看出社群对小作品定义还有争议，所以提报至此--QiuLiming1（留言） 2022年6月12日 (日) 16:18 (UTC)

WP:小作品 “此页是英语维基百科的编辑指引，但是中文维基百科尚无采纳共识。”。200字个人认为是参考性指标。个人也比较反对自动移除3000字节条目的小作品模板，因为有时正文没什么内容，明显需要扩充基本介绍。--YFdyh000（留言） 2022年6月12日 (日) 16:27 (UTC)

( π )题外话 我不定期会把机器人判定的所有小作品手动加到QiuLiming-bot/超过250个汉字的小作品中。可以作为参考--QiuLiming1（讨论 清理小作品） 2022年6月13日 (一) 02:40 (UTC)

可以考虑纳入WP:资料库报告。--Antigng（留言） 2022年6月13日 (一) 12:59 (UTC)

我有个(？)疑问：所有小作品模板都连接到WP:小作品，里面有规定是说超过200字的就不是小作品，那么如果反对意见这么多的话要不要修改WP:小作品页面本身？--QiuLiming1（讨论 清理小作品） 2022年6月14日 (二) 04:10 (UTC)

新建了一个投票页面：Wikipedia:投票/小作品判定条件修正案/第2次--QiuLiming1（清理小作品 讨论） 2022年6月20日 (一) 22:02 (UTC)

我想暂时没有开设投票决定标准的共识。个人意见是字数为关键指标但非唯一指标，只考虑字数的标准均是死板或图省事的行为。--YFdyh000（留言） 2022年6月21日 (二) 00:20 (UTC)

那能不能删除“此页是英语维基百科的编辑指引，但是中文维基百科尚无采纳共识。”这句话？字数标准在英文维基也不是指引。--QiuLiming1（清理小作品 讨论） 2022年6月21日 (二) 00:58 (UTC)

“此页在英语维基百科是编辑指引”或者“英语维基百科中的此页面是编辑指引”可能更准确得当，不知道是否有人反对修改。另外，指引只是参考性指标。--YFdyh000（留言） 2022年6月21日 (二) 01:34 (UTC)

"A stub is an article that, although providing some useful information, lacks the breadth of coverage expected from an encyclopedia, and that is capable of expansion."是中文版翻译引进不及时的锅。--Temp3600（留言） 2022年6月14日 (二) 02:31 (UTC)

基于WP:是英文维基说的，引进翻译不能解决所有问题，需要讨论和公示来确立字数标准的共识情况。--YFdyh000（留言） 2022年6月16日 (四) 00:59 (UTC)

需不需要搞个投票？--QiuLiming1（讨论 清理小作品） 2022年6月16日 (四) 02:55 (UTC)

小作品没有字数上限。很长的条目(比如上面ACG所指欠缺现实内容的条目)，只要在关键主题内容上有缺失，就依然是小作品。--Temp3600（留言） 2022年6月16日 (四) 05:22 (UTC)

真是好样的，那以前独裁社群怎么都说是要看字数判断的？--Z7504非常建议必要时多关注评选（留言） 2022年6月16日 (四) 06:20 (UTC)

@YFdyh000：小作品标签挂十年条目也不会怎样。又不是小小作品，非要有一个可以无脑执行的标准以便提删……而且比如游戏条目有50字百科内容和3950字攻略。如果攻略里面也没有有价值的内容，那它的有效内容就只有50字（而且因为涉及清理，内容可以说比只有那50字还差）。这种就不是数字数能解决的。--洛普利宁 2022年6月16日 (四) 07:05 (UTC)

(※)注意 我是赞成“字数标准”是缺乏共识的，移除小作品模板应该人工判断。如何演变为额定标准不太清楚，3000字节我认为该是指引（仅作参考）、不一定适合中文（文字信息熵不同）。如果小作品模板能部分取代已停用的{{扩充}}和不太常用且不美观的{{缺少信息}}，将是个好事。--YFdyh000（留言） 2022年6月16日 (四) 16:09 (UTC)

“字数标准缺乏共识”，看吧，同样的道理，这种字数是否和“巡查豁免权的创建75个条目标准”都叫做刻板印象呢？--Z7504非常建议必要时多关注评选（留言） 2022年6月16日 (四) 17:47 (UTC)

@Z7504：最开始3000字节是为了方便机器人移除小作品模板。原版“一般而言，超过3000字节通常不被认为是小作品……”有个“一般而言”“通常”还说得过去。结果后来越搞越歪变成纯粹数字了。感觉人被都机器人给绑架了。--洛普利宁 2022年6月16日 (四) 06:56 (UTC)

如果是这样的话，为什么有机器人清理超过三千字节的小作品呢？--QiuLiming1（讨论 清理小作品） 2022年6月16日 (四) 15:11 (UTC)

@QiuLiming1：难道上面Lopullinen所述的“小作品字数定义变成纯粹数字”、“被机器人绑架”没看到吗？如果这个独裁社群真的有想要废除字数限制，那么这个机器人也可以停止。但是很可惜的是这个独裁社群并不想废除小小作品的规定，小小作品和小作品都不应该有字数限制的才是，所以才说嘛这样还说想要鼓励新手写条目？这独裁社群都把规则订死了啊。请问这个独裁社群有无想过一个新手要熟练这些规定需要多久时间吗？条目也都越来越难写出新的了。--Z7504非常建议必要时多关注评选（留言） 2022年6月16日 (四) 15:42 (UTC)

@Z7504 我是回复Temp3600。另外，既然这个机器人可以工作，为什么我的机器人又引起争议呢？--QiuLiming1（讨论 清理小作品） 2022年6月16日 (四) 19:23 (UTC)

我更愿称这为规则的进步。显然英维也不是第一天就想到这个定义的。--Temp3600（留言） 2022年6月16日 (四) 12:29 (UTC)

• 这种讨论是不会进步，也不太可能进步的。看了小作品和小小作品的争议就知道这种东西根本没有讨论的必要，完完全全就是再次证明了这个独裁社群的提删标准不一而已。同样的道理，日食（或者月食也好）是否具有一定关注度？会影响多少？--Z7504非常建议必要时多关注评选（留言） 2022年6月14日 (二) 17:43 (UTC)

  管理员和平奋斗救地球说了，TA创建这些日食条目有考虑到这种条目一般都有几个外语版本才创建的，我认为有足够的关注度（可能有人就是为了查资料而看的）--QiuLiming1（讨论 清理小作品） 2022年6月19日 (日) 20:18 (UTC)

• 有关注度的条目也可以是小作品。--Temp3600（留言） 2022年6月30日 (四) 13:50 (UTC)

  看看QiuLiming1开的投票什么时候要正式开始吧？虽然不能代替讨论啦。--Z7504非常建议必要时多关注评选（留言） 2022年6月30日 (四) 14:23 (UTC)

  其实现在我自己也觉得有些小作品没有字数限制了。--QiuLiming1（清理小作品 留言） 2022年6月30日 (四) 14:51 (UTC)

  标准的刻板印象。--Z7504非常建议必要时多关注评选（留言） 2022年6月30日 (四) 15:13 (UTC)

建议修改音乐关注度规则

由于部分国家或地区歌曲／歌手大多只在当地的流行歌曲排行榜上榜，在现有Wikipedia:关注度 (音乐)的情况下大多不符合“作品至少登上两个国家或地区的音乐榜单前十名内，但不适用于登上同一个榜单的不同类别与单一国家或地区内的多个榜单”的条件，因此建议作以下修订：

现行条文 音乐家与音乐团体 维基百科中有许多乐团、歌手与其他音乐家、音乐团体的条目。 如果满足以下条件其中之一，音乐家或音乐团体（包含乐团、歌手、饶舌歌手、乐队、嘻哈乐团、DJ、音乐剧团等）被视为具有关注度： 他们曾经被多份独立于该音乐家或团体以外的已出版可靠来源所提及。 作品至少登上两个国家或地区的音乐榜单前十名内，但不适用于登上同一个榜单的不同类别与单一国家或地区内的多个榜单。 在至少一个国家或地区取得金唱片或更高级的唱片认证。 曾经获得主要的音乐奖项，例如格莱美奖、朱诺奖、水星音乐奖、金曲奖或选择音乐奖等。 另外，通常音乐团体成员的条目比较适合重定向到该拥有关注度的团体条目中，而非设置独立的个人条目，除非他们有足够个人关注度，比如拥有个人专辑等等。 作词家与作曲家 对于作曲家、填词家或编曲家，符合以下条件之一，具有关注度： 作品取得金唱片或更高级的唱片认证。 曾经获得主要的音乐奖项，例如格莱美奖、朱诺奖、水星音乐奖、金曲奖或选择音乐奖等 作品至少登上两个国家或地区的音乐榜单前十名内，但不适用于登上同一个榜单的不同类别与单一国家或地区内的多个榜单。 音乐作品 音乐作品需要满足下列条件之一才符合关注度： 该作品在至少在一地取得金唱片或更高级的唱片认证 该作品赢得了具关注度的国际性奖项（如格莱美奖、朱诺奖、水星音乐奖等）或该地区受广泛认同的音乐奖项。 作品至少登上两个国家或地区的音乐榜单前十名内，但不适用于登上同一个榜单的不同类别与单一国家或地区内的多个榜单。 不满足关注度标准的作品条目应该被合并到相关条目（如专辑、艺人、词曲创作人或制作人等等）条目中。 参考资料

提议条文 音乐家与音乐团体 维基百科中有许多乐团、歌手与其他音乐家、音乐团体的条目。 如果满足以下条件其中之一，音乐家或音乐团体（包含乐团、歌手、饶舌歌手、乐队、嘻哈乐团、DJ、音乐剧团等）被视为具有关注度： 他们曾经被多份独立于该音乐家或团体以外的已出版可靠来源所提及。 作品至少登上两个具有一定规模且获一个国家或地区认证或成立榜单的头十名内，但登上同一个榜单的不同类别不在此列。 在至少一个国家或地区取得金唱片或更高级的唱片认证。 曾经获得主要的音乐奖项，例如格莱美奖、朱诺奖、水星音乐奖、金曲奖或选择音乐奖等。 另外，通常音乐团体成员的条目比较适合重定向到该拥有关注度的团体条目中，而非设置独立的个人条目，除非他们有足够个人关注度，比如拥有个人专辑等等。 作词家与作曲家 对于作曲家、填词家或编曲家，符合以下条件之一，具有关注度： 作品取得金唱片或更高级的唱片认证。 曾经获得主要的音乐奖项，例如格莱美奖、朱诺奖、水星音乐奖、金曲奖或选择音乐奖等 作品至少登上两个具有一定规模且获一个国家或地区认证或成立榜单的头十名内，但登上同一个榜单的不同类别不在此列。 音乐作品 音乐作品需要满足下列条件之一才符合关注度： 该作品在至少在一地取得金唱片或更高级的唱片认证 该作品赢得了具关注度的国际性奖项（如格莱美奖、朱诺奖、水星音乐奖等）或该地区受广泛认同的音乐奖项。 作品至少登上两个具有一定规模且获一个国家或地区认证或成立榜单的头十名内，但登上同一个榜单的不同类别不在此列。 不满足关注度标准的作品条目应该被合并到相关条目（如专辑、艺人、词曲创作人或制作人等等）条目中。 参考资料

欢迎讨论。--Billytanghh 讨论 欢迎参与亚洲月 2022年6月20日 (一) 12:59 (UTC)

(＋)支持，但一个关注点是哪些音乐榜单可被用作有效判断关注度的标准？不怕被引用出任一不知名音乐榜单就当成满足此项？--路西法人 2022年6月20日 (一) 16:21 (UTC)

其实原有备注会被保留。--Billytanghh 讨论 欢迎参与亚洲月 2022年6月20日 (一) 16:47 (UTC)

注释已代为补上。--Kirk # 2022年6月20日 (一) 22:52 (UTC)

修订主旨似乎是放宽到任意两合乎要求的榜单即可，“至少两个……，或一个……的两个或以上”的描述是否重复累赘。或可直接合并注释，似宜描述为“作品至少登上两个具有一定规模且国家或地区认证或成立榜单，但登上同一个榜单的不同类别不在此列”即可。--Kirk # 2022年6月20日 (一) 22:43 (UTC)

另，第1.2（作词家与作曲家）章节亦有“作品至少登上两个国家或地区的音乐榜单前十名内……”的要求，但修正案未提出修改，不知道是漏了（刚好可以补上），还是对词曲作家的标准另有考量（刚好可以详细说明一下）？--Kirk # 2022年6月20日 (一) 22:55 (UTC)

已修改。--Billytanghh 讨论 欢迎参与亚洲月 2022年6月21日 (二) 01:53 (UTC)

(＋)支持：建议“成立榜单”改为“成立周榜单”，至少以周为单位。是说我想提议一条“作品至少登上一个具有一定规模且国家或地区认证或成立周榜单前三名，名次限制随着登榜时间增长而递减。” --Loving You Is A Losing Game 2022年6月21日 (二) 02:55 (UTC)

与其是写一定规模的榜单，为什么不写有关注度的榜单？这样的话争议相对少很多吧。--Ghren🐦🕛 2022年6月21日 (二) 04:25 (UTC)

这样还要定义谁是符合关注度的榜单，很不方便。 --Loving You Is A Losing Game 2022年6月21日 (二) 06:03 (UTC)

我的关注点跟闲闲君一样，何谓“一定规模”？--路西法人 2022年6月22日 (三) 01:06 (UTC)

个人认为一定规模是指具可与比肩官方的榜单。像国内方面有日本Oricon公信榜和俄罗斯Tophit，国际方面则有拉美监控、告示牌 (杂志)具有高市占率，而某种程度上也担任官方角色发布相关认证。当然这只是我认为，如果要归纳总结，大概会发展出谁是现任法国国王一样长篇论战。 --Loving You Is A Losing Game 2022年6月22日 (三) 05:05 (UTC)

是否直接定义符合通用关注度标准的榜单才能视作有效关注度条件？--路西法人 2022年6月22日 (三) 05:11 (UTC)

改成奖项规定形式OK。 --Loving You Is A Losing Game 2022年6月22日 (三) 15:54 (UTC)

所以重点是不用在十名之内？那不错。--中文维基百科20021024（留言） 2022年6月23日 (四) 16:59 (UTC)

其实我的确认为需要头十名内，已补回。--Billytanghh 讨论 欢迎参与亚洲月 2022年6月23日 (四) 18:15 (UTC)

那这样不是和你之前的提议原因抵触了吗？原话是“由于部分国家或地区歌曲／歌手大多只在当地的流行歌曲排行榜上榜”，如果加回前10名，不是和先前的版本没实质上的区别？--中文维基百科20021024（留言） 2022年6月23日 (四) 18:19 (UTC)

可能具体语句需要再修修，目前的修订版本乍一看依旧强调“前十名”。--中文维基百科20021024（留言） 2022年6月23日 (四) 18:21 (UTC)

先前版本要求两个国家或地区，修订版本只要求两个具有一定规模且国家或地区认证或成立榜单便可，同一地区的两张都可以。--Billytanghh 讨论 欢迎参与亚洲月 2022年6月23日 (四) 18:52 (UTC)

你是指同一地区的“两榜”都可以吗？敝人反对，比利时还能解释成地区（一个荷兰一个法国），但日本韩国作品因为国内有两榜算符合条件也太松散了，倒不如加上名次限制。 --Loving You Is A Losing Game 2022年6月24日 (五) 01:30 (UTC)

不松吧，至少一国之内有知名度了，应该够了。--中文维基百科20021024（留言） 2022年6月24日 (五) 03:17 (UTC)

我是觉得这个条款太有益于小国了。小国随便和邻国加起来两个榜就行，假如是中国的话，一首歌那怕是好几个省都上榜了也不行，其实多少有些不公平。--Ghren🐦🕖 2022年6月24日 (五) 11:02 (UTC)

怎么不松？以日本为例，除了比较具有标示性的Oricon、告示牌还有RecoChoku、Mora等其他榜单，这还没包括根据不同格式产生的不同类型榜单们，日本金唱片认证好歹要你卖100,000张，靠这张你只要国内榜单够多，卖个1千拿个100名符合关注真的很松。 --Loving You Is A Losing Game 2022年6月24日 (五) 13:53 (UTC)

那“同一个榜单”改成“同一个公司发布的榜单”如何？这种情况下，以告示牌为例，Oricon、RecoChoku与Mora都当成一个榜单。Sanmosa _{Királyunk s a közhazát} 2022年6月25日 (六) 04:10 (UTC)

@Billytanghh、Milkypine。Sanmosa _{Királyunk s a közhazát} 2022年6月25日 (六) 04:11 (UTC)

这样改是比较严谨，但我反对降低标准，仅支持至少两个具有一定规模且国家或地区认证或成立榜单（关注度符合）。 --Loving You Is A Losing Game 2022年6月25日 (六) 05:04 (UTC)

我没意见，我甚至觉得为求严谨，可以进一步改成“至少两个具备关注度、具备一定规模且国家或地区认证或成立的榜单（同一组织或单位发布的榜单视为同一榜单）”。Sanmosa _{Királyunk s a közhazát} 2022年6月28日 (二) 05:23 (UTC)

确定是邻国效应不是文化环境吗？照地理来看比起希腊，塞浦路斯还比较靠近土耳其，但现实是两著一家亲。回到中国，先不提自家人没官方榜单也不信任那些商业平台，香港台湾乃至于新加坡等华语圈也有榜单，如果真的要靠拉低榜单标准来达成关注度，那还不如删掉算了。 --Loving You Is A Losing Game 2022年6月24日 (五) 13:53 (UTC)

“具有一定规模”，“一定规模”有没有什么标准？--BlackShadowG Slava Ukraini! 2022年6月24日 (五) 12:25 (UTC)

建议条文和现行条文有什么分别？我没看出来。--AT 2022年6月24日 (五) 12:44 (UTC)

现行条文要求两个国家或地区的两个榜单或以上，建议条文只要求一个国家或地区的两个榜单或以上。--Billytanghh 讨论 欢迎参与亚洲月 2022年6月24日 (五) 17:16 (UTC)

“作品至少登上两个具有一定规模且国家或地区认证或成立榜单的头十名内，但登上同一个榜单的不同类别不在此列”看不出来一个在哪里。 --Loving You Is A Losing Game 2022年6月24日 (五) 17:34 (UTC)

已修改。--Billytanghh 讨论 欢迎参与亚洲月 2022年6月24日 (五) 19:38 (UTC)

改成一国两榜的话，前十位实在太容易了，前三位的话可以考虑。这样也可以同时保留原本的两国两国前十的条文。--AT 2022年6月26日 (日) 13:44 (UTC)

一定规模榜单

参见：Wikipedia:音乐排行与认证

@Ohtashinichiro、和平至上、Leehsiao、Sanmosa、Tombus20032000、百战天虫、Kriz Ju、生米一粒、Pseudo Classes、KodokunaSmile：@Easterlies、AT、卡達、Yumeto、SickManWP、羊羊32521、EdwardAlexanderCrowley、Zhaoweizhi0325、MoonLight3650、HXXXX：@Punkhippie、Louis0921gee、Peace 621、Whykitty、Moonshimmer93、夜来南风起、Fake12345、TreasureBabe325、Hijk910、Jacklamf1d14：@Ericliu1912、Naverad、Softyu、Sammypan、Tw drama、Shingkei、Hikki、李新阳、CHih-See Hsie、Pv163：@JoJo_append、Lopullinen、AnYiLin、Yel D'ohan、Temp3600、Bigbullfrog1996、陳寅恪、Tenhumantenok、Prince of Erebor、K.Y.K.Z.K.：@Arivgao、FredYYoo、Apple v、Tfcheng5597、Comrade John、Adsa562、Austin Zhang、Gracelllee、Shwangtianyuan、星巴克女王：@金善賢、老奋、Lilychen1388、Drippinpunch、Lienwingyan、Bbene98、Paristung、Joshua Zhan、Achanhk：@Billytanghh、Sinsyuan、Jane9306、JuneAugust、Ryti😈M、Factrecordor、Will629、Detective Akai、Hisa312、愛子棋枰：@恩力：我大概写了一下符合条件，欢迎各位参观。 --Loving You Is A Losing Game 2022年7月1日 (五) 12:03 (UTC)

前面讨论有提议改符合关注度的榜单，但后来想想这样东西会太多太杂，所以列了符合条件和不符合条件。抱歉Billytanghh大我回退你的内容，但这里放入单一渠道榜单并不合适，至少你要加应该把“避免内容”的“它仅凭借单一发行商或渠道的成绩制作榜单”砍掉，另一方面是像HKRIA著作权风波的情况，歌曲丧失上榜资格无法展现商业表现。 --Loving You Is A Losing Game 2022年7月1日 (五) 12:03 (UTC)

其实五台榜单不太算是“单一渠道榜单”，叱咤乐坛流行榜的排名要同时参考香港电台的播放数字，Chill Club 推介榜也是由各唱片公司代表投票决定的。--Billytanghh 讨论 欢迎参与亚洲月 2022年7月2日 (六) 01:45 (UTC)

Billytanghh投票的Chill Club 推介榜可能没法放在这里，至于叱咤乐坛流行榜，有没有直接导向的网站？我看都导到903推介，还是现在903推介继承他的业务。 --Loving You Is A Losing Game 2022年7月2日 (六) 04:43 (UTC)

再次重提精简用户讨论页的罐头通知

先前讨论：2021年10月、2022年1月

大家应该都收到过速删通知和提删通知模板吧。它们告诉页面创建者应该做什么（不能擅自移除{{d}}，可以去WP:AR找回条目），还提供了一些很实用的链接（比如编辑帮助和IRC）。但是对于老用户来说，这些东西没什么意义，而这么大一个模板，有用的信息仅有“xx页面被提删/速删了”。故，我希望老用户能收到更加精炼的消息。

方案：Twinkle自动给未在讨论页挂上[[Category:接受完整删除通知]]的延伸确认用户发送短的罐头通知。

在下已经制作了VfD通知和SD通知的短模板。两个模板除了通知哪个页面被删除，还附有删除原因和到关于此通知的更多信息的链接。

• VfD和SD通知模板已经支持Flow，发送时加入参数flow=1即可。
• SD通知模板能兼容{{Delete}}，参数是一样的，只多了一个{{{p}}}(目标页面名)。它调用了Module:沙盒/魔琴/SDR，是在下从Module:Template:Delete的某个古早版本修改来的。因为在下不懂Lua，所以只能看着Lua手册连蒙带猜乱删改，可能会有冗余的代码，希望大佬能协助修改 囧rz……（之前好像有人说要改Module:Template:Delete来着？）

此外在下先前还制作了{{Uw-short}}，用于替代第一级警告的罐头通知，模板文档写得很详细了，就不啰嗦了（）

三个模板的效果见此。

• 上面提到的页面：提删通知
• 速删通知
• 速删理由模块
• 更多信息
• 短警告
• 模板效果

Ping一下先前讨论的参与者：@94rain、AnYiLin、Temp3600、LuciferianThomas、Glerium、Ericliu1912、和每個人好好相處、MilkyDefer、SunAfterRain、Xiplus （嚯，正好十个） ——魔琴 [ 留言 贡献 ] 2022年6月21日 (二) 11:16 (UTC)

更新：
1. Special:Diff/72389736：速删理由模块中，CSD加上<strong>标签，SD通知完整预览见此：Special:PermaLink/72391472。其实 Custom rationale 不应该用strong的，下次研究研究在哪改；
2. Special:Diff/72391444：VfD通知的clear:both;改成clear:left;（预览无差别）
 ——魔琴 [ 留言 贡献 ] 2022年6月27日 (一) 16:58 (UTC)

嚯，真聪明，找到我新号了（）
话说要不要搞一个反向Switch[[Category:不接受完整删除通知]]来让新用户（可能是重开）接受短通知？--和每个人好好相处（留言） 2022年6月21日 (二) 11:43 (UTC)

乐，这类似我的第一版方案。并行也不是不行。看看社群决定用哪种吧。 ——魔琴 [ 留言 贡献 ] 2022年6月21日 (二) 15:56 (UTC)

魔琴改Module:Template:Delete的补丁卡住了，应该是难以验证补丁不会毁损别的东西--SunAfterRain 2022年6月21日 (二) 15:01 (UTC)

(＋)支持。桐生ここ★[讨论] 2022年6月22日 (三) 07:20 (UTC)

(＋)支持，老用户一般不需要详细的帮助链接，而且罐头通知篇幅过长很影响讨论页观感。--BlackShadowG Slava Ukraini! 2022年6月24日 (五) 12:16 (UTC)

(＋)支持使用Category:不接受完整删除通知，同时建议在模板中包含常用链接，这样会更方便一点（与地球有利益冲突，没毛病）--落花有意12138 _{论 回复请ping我} 2022年6月26日 (日) 04:32 (UTC)

@落花有意12138：比如什么链接？ ——魔琴 [ 留言 贡献 ] 2022年6月27日 (一) 14:38 (UTC)

@魔琴：提删讨论处的链接之类的？--落花有意12138 _{论 回复请ping我} 2022年6月28日 (二) 11:42 (UTC)

@落花有意12138：已经有了啊？ ——魔琴 [ 留言 贡献 ] 2022年6月28日 (二) 13:26 (UTC)

(＆)建议：留白过大，是否能有更佳的显示效果？--Yining Chen（留言|签名页） 2022年6月27日 (一) 10:22 (UTC)

@Yining Chen：如果您指的是VfD通知垃圾桶底下到提删理由中间的空白，呃，那是因为我加了一个{{Clear}}防止无序列表的bullet跑掉，您看这个版本如何？（似乎还和我签名的font-size:17px;有关系 囧rz……）如果是说页面右侧太空，我觉得目前这样比较方便定位理由的位置。 ——魔琴 [ 留言 贡献 ] 2022年6月27日 (一) 14:50 (UTC)

这样想我应该用clear:left;而不是clear:both;…… ——魔琴 [ 留言 贡献 ] 2022年6月27日 (一) 14:52 (UTC)

看起来似乎好一些。--Yining Chen（留言|签名页） 2022年6月30日 (四) 15:04 (UTC)

建议修改新闻动态发表程序

本人近期经常发现某管理员在没有获得社群支持并且新闻内容不属于WP:ITNR所列出的事项下将新闻强行写入ITN中的情况（我所知的最近一次是2023年欧洲歌唱大赛，见Special:Diff/72246071），因此，本人在此提议要求凡需要在新闻动态评选的内容必须有获得支持票才可刊登，尽量阻止滥权行为的发生。另欢迎其他人继续在此提出自己的意见。--忒有钱🌊塩水あります🐳（留言） 2022年6月21日 (二) 18:19 (UTC)

乌克兰身为冠军却不能主办比赛，这四舍五入也算符合事项吧？ --Loving You Is A Losing Game 2022年6月22日 (三) 05:08 (UTC)

ITNR里列出的与欧洲歌唱大赛相关的事项只有该比赛的冠军，并没有该比赛本身。--忒有钱🌊塩水あります🐳（留言） 2022年6月22日 (三) 14:34 (UTC)

注：此留言已被原作者（User:车智贤）移除。2022年6月26日 (日) 18:37 (UTC)

注：此留言已被原作者（User:车智贤）移除。2022年6月27日 (一) 11:54 (UTC)

不建议假定恶意，谢谢合作--SunAfterRain 2022年6月22日 (三) 12:27 (UTC)

注：此留言已被原作者（User:车智贤）移除。2022年6月27日 (一) 11:54 (UTC)

不过就是个新闻，请问一年是要吵几次呢？与其来这看新闻怎么不直接去看第四权的就好了呢？“某年某月某地”条目都已经存在争议了，甚至也有出现要写成“某年年鉴”的说法，也和新闻有关啊。--Z7504非常建议必要时多关注评选（留言） 2022年6月22日 (三) 15:34 (UTC)

注：此留言已被原作者（User:车智贤）移除。2022年6月27日 (一) 11:54 (UTC)

这样讲没有错啊，如果为了新闻吵成这样，为何这个奇葩独裁社群不敢提删、不敢废除Itn模板呢？--Z7504非常建议必要时多关注评选（留言） 2022年6月22日 (三) 17:02 (UTC)

一开始竟然就随便预设前提，我所讲的流程本来就是几年前经过互助客栈/方针讨论并公示过后，我和时昭、以及其他管理员都应该遵循的规则，过往的存档记录都可以证实此事。另外，如果您想要暗示“KOKUYO提的案就能提前上”是长期现象，也就是说我提的案通常能够少于8小时就被处理，请去统计并证明，否则我认为这是恶意的暗示。--KOKUYO（留言） 2022年6月26日 (日) 07:58 (UTC)

注：此留言已被原作者（User:车智贤）移除。2022年6月27日 (一) 11:54 (UTC)

所以现在就是先到处乱指控别人，反正到时候再说是猜想就好？为何您不干脆地承认，您找不到我经常让自己提出的案，经常少于8小时就登上ITN的首页的事实。还是这是您故意的行为？--KOKUYO（留言） 2022年6月26日 (日) 08:46 (UTC)

注：此留言已被原作者（User:车智贤）移除。2022年6月27日 (一) 11:54 (UTC)

注：此留言已被原作者（User:车智贤）移除。2022年6月27日 (一) 11:54 (UTC)

现在是怎样，一下暗示别人正在违反方针流程，一下又说自己没有讲过这些事情？是不是到时候就会说，如果我忙的时候，却在某个刚好8个小时的时候没有做更新，就是抵制某些新闻；然后我有空的时候一次更新，就是想要滥用权限。同时，我还不能对新闻提名感到疑惑，放着等其他人发表意见。反正所有的话都给您讲就好了啊。--KOKUYO（留言） 2022年6月26日 (日) 09:14 (UTC)

早在2020年的时候，就已经把明确成文的部分早更新到页面了，结果现在是您不知道这件事情？--KOKUYO（留言） 2022年6月26日 (日) 09:20 (UTC)

注：此留言已被原作者（User:车智贤）移除。2022年6月27日 (一) 11:54 (UTC)

证明一个页面哪些文字是方针指引，不是去找讨论记录，难不成是靠您的感觉？--KOKUYO（留言） 2022年6月26日 (日) 09:37 (UTC)

另外，既然您的指控不是违反方针指引的，那就只是想要找一个近十年经常在ITN执行无聊行政的人，随便凑凑记录罗织罪名而已。真的是很无聊。--KOKUYO（留言） 2022年6月26日 (日) 09:49 (UTC)

而且即便整理出我提案的处理时间真的比较短，老实说也不能代表什么。我能处理ITN的时间，就代表只是刚好是生活中有空的环节。所以，提名是一个要花一段时间的有空环结（例如晚餐时间），更新是另一个要花一段时间的有空环结（例如早餐时间）。而那些没有刚好在这个环节里提名的案子，自然就得等到下一个有空环结去处理（例如在下午茶时间提名，因为晚餐时间还没超过8小时，就等到早餐时间处理）。这还不包含生活要忙其他事情、或中间突然有空可以处理，或其他情况（空闲时间只够处理一部分内容，其他内容得等下一环结、或交给其他人处理）。

所以您即便整理出了什么迹象，老实讲也不能证明什么。当然，您也可以像很久之前，有一次我更新完新闻动态后，就去忙论文和其他自己想做的事情，没有特别去管其他ITN更新。结果当时就被指控是要让特意新闻登上首页，如果您想要特意整理某些迹象再做出指控，谁也拦不住您；就像可以指控一个正在忙论文的管理员，他没心情更新ITN是在霸占ITN一样。--KOKUYO（留言） 2022年6月26日 (日) 10:19 (UTC)

注：此留言已被原作者（User:车智贤）移除。2022年6月27日 (一) 11:54 (UTC)

注：此留言已被原作者（User:车智贤）移除。2022年6月26日 (日) 18:37 (UTC)

我始终遵守过往的讨论共识，结果您利用没意义的东西抹黑别人，然后再说必须去处理。这是您的兴趣？--KOKUYO（留言） 2022年6月26日 (日) 10:37 (UTC)

注：此留言已被原作者（User:车智贤）移除。2022年6月27日 (一) 11:54 (UTC)

注：此留言已被原作者（User:车智贤）移除。2022年6月27日 (一) 11:54 (UTC)

根据以往来看，我不太赞成需要有人投支持票才可以上ITN。

1. 我认为提名8小时以后如无人提出不同的合理意见，管理员就可以更新到ITN。（有时候没人明确反对，但会有人提出语句、事实等瑕疵需要修改，或者虽无明确说“反对”，但提出的意见很明显是反对意见）
2. 而且前面刚说完“新闻动态候选区中的支持与反对意见并非用以进行投票表决”，后面就在数票数，也很矛盾啊。--百無一用是書生 (☎) 2022年6月23日 (四) 06:40 (UTC)

注：此留言已被原作者（User:车智贤）移除。2022年6月27日 (一) 11:54 (UTC)

不是每次都有票可点--百無一用是書生 (☎) 2022年6月24日 (五) 06:39 (UTC)

注：此留言已被原作者（User:车智贤）移除。2022年6月27日 (一) 11:54 (UTC)

点票并不能防止“管理员有意挑选自已想上的新闻先上，并避免关注度高的新闻动态提案不能先上”这一问题--百無一用是書生 (☎) 2022年6月25日 (六) 12:38 (UTC)

注：此留言已被原作者（User:车智贤）移除。2022年6月27日 (一) 11:54 (UTC)

现状是新闻候选区有人反对且无人支持的情况下管理员硬要把新闻登上新闻动态，并且这一行为已招致他人不满，所以不应让这种状况持续下去。

还有我加上了“条目内文没更新不要登上新闻动态”，更新条目更有意义，而条目上了新闻动态后过了几天就会撤下了。--中文维基百科20021024（留言） 2022年6月23日 (四) 17:08 (UTC)

车智贤根据管理员KOKUYO此前的说法，所谓“基本候选标准”：“本来就是给大家参考用，有遵循很好、没有遵循也罢。”可见该标准在长期以来负责ITNC的管理员KOKUYO看来并无实际约束力。因此创建ITN方针才是解决ITNC长期以来问题的关键（至少是有建设性意义的第一步）。--Yining Chen（留言|签名页） 2022年6月23日 (四) 14:47 (UTC)

坦白说啦，新闻动态的新闻根本不配称上“即时”，总有可能事件都发生过后的两三天才上首页，原因就是出自社群挑新闻而导致内容完全不新鲜了。所以才说与其来这看新闻，怎么不直接去看第四权的新闻就好了呢？--Z7504非常建议必要时多关注评选（留言） 2022年6月23日 (四) 17:05 (UTC)

本站之新闻动态本来就不追求“即时”。我们又不是媒体，抢快做什么。Ericliu1912（留言） 2022年6月23日 (四) 17:48 (UTC)

先写动态再写条目岂不是更即时。^{[开玩笑的]}--YFdyh000（留言） 2022年6月24日 (五) 01:09 (UTC)

注：此留言已被原作者（User:车智贤）移除。2022年6月27日 (一) 11:54 (UTC)

如果没这个栏目也没什么，也不靠维基百科获取新闻信息。--中文维基百科20021024（留言） 2022年6月24日 (五) 06:53 (UTC)

注：此留言已被原作者（User:车智贤）移除。2022年6月27日 (一) 11:54 (UTC)

注：此留言已被原作者（User:车智贤）移除。2022年6月27日 (一) 11:54 (UTC)

不建议加入有关“数票”的内容，但可考虑需有共识才可上更新，无明确共识需继续讨论。按以往“常识”来看，某一提名收到一反对（或有异议），无支持，这种情况下是能登上首页的（如Wikipedia:新闻动态候选/存档/2022年5月#萨拉托加酒店）。--东风（留言） 2022年6月26日 (日) 02:37 (UTC)

“有二名及以上维基人提出反对意见的”这个经过互助客栈讨论并公告的内容，要怎么把这句话看成“有一名及以上维基人提出反对意见的”，还麻烦提出一下。另外，一个人的反对能被称做“共识”，是和谁达成共识？--KOKUYO（留言） 2022年6月26日 (日) 08:05 (UTC)

KOKUYO最近就强行让2票倾向反对、无人支持的新闻强行上首页。虽然不是破坏，但是吃相不太好。--中文维基百科20021024（留言） 2022年6月26日 (日) 02:39 (UTC)

请明确指出哪一个是有两张反对票（而且反对票是不可解决之问题），然后被登上首页的情况？尤其是当其他人只是反对个别提出的意见、而没有反对整个提案的时候，结果您却无法看出来是这个意思的时候。--KOKUYO（留言） 2022年6月26日 (日) 08:03 (UTC)

“提名者意见：重要文化新闻，已上德语首页。--KOKUYO（留言） 2022年06月20日, 星期一 (6日前), 02:42 am (UTC+8)

最好等下届比赛的主办地正式确认了再刊登。--🔨（留言） 2022年06月20日, 星期一 (6日前), 09:22 am (UTC+8)

(－)反对，(▲)同上，且重要性及关注度均不足。--以上未签名的留言由Zheng.Z.Xu（讨论｜贡献）于2022年06月20日, 星期一 (6日前), 12:41 pm (UTC+8)加入。

不清楚管理员是依据什么来判断不需要考虑我这个意见的。欧洲歌唱大赛大致也是近几年才开始有机会登上本站首页新闻板块的，考虑其重要程度（不如世界杯奥运会）显然等到下届举办地正式确定下来再一并刊登才更好。--🔨（留言） 2022年06月20日, 星期一 (6日前), 09:52 pm (UTC+8)

Liu116虽然没有直接(－)反对但是很明显可以看得出他是不支持刊登，甚至在你硬要刊登后别人还发了句小牢骚。--中文维基百科20021024（留言） 2022年6月26日 (日) 08:20 (UTC)

在我看来，那个就只是意见表达，不是反对更新至ITN的意见（不然他就会直接加入反对模板了）。关于后半部分，他为何会觉得至少从2012年登上ITN的欧洲歌唱大赛叫做“近几年”，这我就不知道了。--KOKUYO（留言） 2022年6月26日 (日) 08:35 (UTC)

@Liu116：发表一下意见？--中文维基百科20021024（留言） 2022年6月26日 (日) 08:38 (UTC)

如果真的误解意思，其实真的是因为重要性问题不想要让这个新闻不想要上，那下次就麻烦明确地一点使用反对模板，然后管理员们会判断这个意见情况（是觉得整个新闻不能上，或者是某些问题处理修正即可），就能减少这里面的误会。--KOKUYO（留言） 2022年6月26日 (日) 08:53 (UTC)

老实说我没有精力回应这事情的，不过看在管理员上面说的一些话我还是回应一下。关于欧洲歌唱大赛2012年就有登的事情被我误说成近几年才有，这个确实是因为我加入本站的前四五年注意itn比较少，多谢纠正，但也并不能改变欧洲歌唱大赛重要度不如（足球）世界杯和奥运会的事实，再加上以前我也看到过一部分已登上一次首页的持续性更新的事件，在出现进一步消息之后却没有再次被提名的情形，所以我才觉得合并刊登更好。至于硬性规定两票反对才重审的，我也是最近才注意到，虽然我不知道什么时候开始有的，不过新闻动态评选毕竟相对于其他评选更偏向于看共识，投票模板更多用于表达个人想法而非表决，至少我的理解是，表达个人想法不一定要靠投票模板，尤其评选规则说明里面“共识”的字眼摆在那里，当然我最初的意见在语气上确实引起了一些误会，这个我以后会注意。没这时间深入参与这个讨论，就说这些。--🔨（留言） 2022年6月27日 (一) 02:19 (UTC)

注：此留言已被原作者（User:车智贤）移除。2022年6月27日 (一) 11:54 (UTC)

新闻动态那边有点有趣，KOKUYO提名的几个新闻一堆人反对，而“美国堕胎不再受宪法保护”一堆人投支持票的情况下KOKUYO投了反对票并且认为“不重要” 。--中文维基百科20021024（留言） 2022年6月26日 (日) 06:24 (UTC)

注：此留言已被原作者（User:车智贤）移除。2022年6月27日 (一) 11:54 (UTC)

如果连“反对：加入枪支法案。（加入枪支法案）那是另外一件事情，而且（加入枪支法案）目前看来没有值得登上ITN的关注度和重要性。”这句话都看不懂，还得要贴心地去标记才行，那我没其他意见；反正其他管理员看得懂就好。--KOKUYO（留言） 2022年6月26日 (日) 07:49 (UTC)

注：此留言已被原作者（User:车智贤）移除。2022年6月27日 (一) 11:54 (UTC)

我干嘛缩排，从所有语句顺序根本就没必要再多做处理，我只要这要这样就能表达意见不应加入枪支的意见了。如果您没有办法看懂别人的意见，就不要乱恶意指控，这只是让人很不舒服。--KOKUYO（留言） 2022年6月26日 (日) 08:08 (UTC)

上面那位解释很到位啊，你是没义务一定要缩排，但这种排版和表述确实容易让人误解。--中文维基百科20021024（留言） 2022年6月26日 (日) 08:15 (UTC)

只要母语是中文的应该都不会理解成是这样吧，那不然为什么“要提那是另外一件事情”？在讨论A新闻是否有登上ITN的意见中，反而提到“A新闻是另外一件事情”？这个逻辑是？--KOKUYO（留言） 2022年6月26日 (日) 08:27 (UTC)

注：此留言已被原作者（User:车智贤）移除。2022年6月27日 (一) 11:54 (UTC)

注：此留言已被原作者（User:车智贤）移除。2022年6月26日 (日) 18:37 (UTC)

我发现许多人不清楚前因后果的情况，就开始直接发表意见，甚至还有人在明知道错误的情况下，继续在这边混淆社群的判断。首先，我过去提到的处理流程，是在2020年的时候，经过互助客栈/方针讨论，以及标准的公告流程所创建的，自然就就是如同方针指引方要遵照执行，也就是我和时昭所遵循的。这个执行流程是假定所有的提名在经过8个小时等待意见期之后，就可已认定有共识可以登上ITN。相反地，在任何时间“有二名及以上维基人提出反对意见”时，应当去延长讨论时间、或者是从模板上退回重审。--KOKUYO（留言） 2022年6月26日 (日) 08:21 (UTC)

因此基于前述ITN的更新流程，对于目前提到的几个意见，大概是回应如下：

• “支持票数多且已有共识者优先采用”：非常不建议。目前ITN共有四则新闻摆放位置，每则新闻会摆放至少放1天时间（曾经有人提出此建议）。依此规则，假若有1、2则新闻被提前更新，后续更新新闻的空间大幅压缩，甚至几则新闻会在不足1天的时间换下。在新闻动态不讲求时间效率之下，没有必要要提前更新（反正都一定会更新到，且都能够保留至少1天时间）。
• “已有共识的新闻动态提案才可更新至栏目，且至少要有一个净支持票（即支持减去反对至少一票）”：非常不建议。如同时昭所言，“不是每次都有票可点”。同时，过度强化“第一张反对票”的效力，只要用任何理由（例如“我觉得不重要”、“我不喜欢”），就必须得要出现两张票。甚至，这种规定可能会想把ITN候选变质成恶性投票、报复处，今天您投我反对票，明天我投您反对票。另外，假如第二点的效力还包含只要违反此要件者，就会被视为不符合此要件而必须撤下ITN的话，那么将有更大机会制造行政流程的混乱。相反地，现行规定要求出现相对明确的反对共识（至少2人的反对意见）后，在不同时候都得拉入更长时间的讨论。
• “条目内文未更新不得进入新闻动态。”：目前没有想到会产生的问题。我自己都会做这样，只是现阶段不会强求别人的。--KOKUYO（留言） 2022年6月26日 (日) 11:02 (UTC)

然后对于几个提案者的无端的指控，我也一并回应：

• “管理员有意挑选自已想上的新闻先上”：就我的部分，答案是没有。就依照顺序，从时间久的开始一个个处理，有两张反对票的就搁置更长的讨论。我相信时昭也是如此。至于他似乎现在想要从一些记录上，硬是要声称存在这件事情。那么，我只能说这就像因为我没心情去更新ITN，然后其他管理员也没有更新，就来指控我有意让某些新闻登上首页一样无聊。
• “关注度高的新闻动态提案不能先上”：第一，已经有多人指出新闻动态不强求时间即时性，只要没有进入要延长讨论的环结，早更新与晚更新都是会登上首页；第二，提前更新只会响让慢一点被注意到而提名的重要新闻更容易失去登上首页的机会，特别是如果还要确保每则新闻都至少能登上首页1天的时间。
• “至少有一个门槛”：我认为现在的规定是主动去相信，所有提名者提出的新闻动态内容，无论大小，都已经经过自身判断后足以可以登上首页。因此，虽然门槛只是设置成在8个小时不要有2张反对票，但很明确是有一个门槛存在，且这个门槛是可以随时达成并生效（即便已经更新至ITN了，不符合此门槛而得到2个反对意见的话，便应依照规定重新撤回），而不是某些人无端指控的“没有门槛”。
• “给定一个机械化的排序依据”：现在的处理方式就是照时间顺序，一个个依照事件发生先后处理提案，无论是我、还是时昭都是如此。反之，“优先采用”这一点才是破坏“机械化的排序依据”，是自相矛盾的说法。--KOKUYO（留言） 2022年6月26日 (日) 11:27 (UTC)

注：此留言已被原作者（User:车智贤）移除。2022年6月27日 (一) 11:54 (UTC)

您提的东西要么就是多余的，影响处理流程，甚至与自己论点自相矛盾的；要么就是无法解决问题，破坏原先的共识运作机制（在有相对明确反对共识下，延长讨论时间，以让提名获得更广泛的共识），甚至是显示出将让ITN候选出现相互投反对票报复的情况，为此自然是有必要在讨论反对您的部分。--KOKUYO（留言） 2022年6月26日 (日) 12:09 (UTC)

注：此留言已被原作者（User:车智贤）移除。2022年6月27日 (一) 11:54 (UTC)

那时候的所有参与讨论的人都知道要照时间顺序处理，这就是一种常识的做法；同时，也知道管理员可能认为需要更多时间判断，而会给予更多时间来让共识更为明确。所以我不知道您想要反对什么，除非您是认为，在一堆提名之中，管理员不照时间顺序，挑选自已想上的新闻先上比较好；但如果这是您的意思的话，就和您前面讲的完全相反。

另外，我都不知道原来现在维基百科的机器人已经能够看懂人类语句，知道哪些情况是可以解决的问题，哪些情况是要等待更多意见，还是您已经默默开发出这个机器人了，只是我还不知道吗？--KOKUYO（留言） 2022年6月26日 (日) 13:06 (UTC)

注：此留言已被原作者（User:车智贤）移除。2022年6月27日 (一) 11:54 (UTC)

我明明已经提到，现行规则是在没有两人以上的反对（或是解决反对意见的情况下），可以更新ITN。而这样的操作方式是有先行讨论提供共识基础的，且这样的讨论是因为我们相信每个人都能够里性判断，同时也留了时间让其他人可以对此进行复核。所以我完全不知道您前面的根据在哪里，难不成机器人能够处理反对意见的差异？这又是因为您开发出了那个机器人，又或者只是猜想这个流程是长怎么样子？--KOKUYO（留言） 2022年6月26日 (日) 13:33 (UTC)

还有啊，您一直说“管理员有意挑选自已想上的新闻先上”，那么您又是指哪一个案例呢？您连整个案例细节长怎样都不提，就开始说有问题存在，这又要怎么讨论呢？--KOKUYO（留言） 2022年6月26日 (日) 13:39 (UTC)

注：此留言已被原作者（User:车智贤）移除。2022年6月27日 (一) 11:54 (UTC)

这整套流程照规定做下来，请问又要如何让“管理员有意挑选自已想上的新闻先上”？请实际说明您所设想会发生的情境，并提出来讨论，不然是浪费大家的精力。--KOKUYO（留言） 2022年6月26日 (日) 14:13 (UTC)

还是您根本连问题实际长怎样都不知道，就直接跳下来跑来讨论？就像全世界都知道要解决贫穷问题，但是别人问说您想解决哪一个地方的贫穷问题，然后就一直说“就是贫穷问题”。--KOKUYO（留言） 2022年6月26日 (日) 14:16 (UTC)

注：此留言已被原作者（User:车智贤）移除。2022年6月27日 (一) 11:54 (UTC)

1. 中文维基百科的方法与英语维基百科有显著不同，整体社群运作及参与程度都不一样，拿其他语言维基百科的内容当参考还行，但是无视现实情况直接套用明显就是有问题。
2. 如果在多则新闻之中，比较后面时间的新闻先上，有可能是因为该管理员觉得真的相当重要，又或者前面几则提名需要更长时间以产生更明确的共识判断，请问要如何用僵化的文字去说明？
3. 我不知道您为何不断片面地撷取片面的文字，而无视整体的运作，这样的意义是要干嘛？现行规则是在没有得到两人反对意见下，即可视为初步具有共识而更新至ITN，并可以因不同情况（例如得到两名反对意见）延长时间以得到更明确共识。同时讽刺地，您们一方面表示没有计算到未使用反对模板之意见，现在却又说可以使用机器人，而无视机器人指能读取反对模板的存在。有想过意见连贯性吗？
4. 您拿一个有被挂上删除模板的新闻提名，需要时间处理条目上的删除模板的问题，结果用在现在去做一些指控别人的猜想？这是认真的吗？还是从头到尾就把讨论当成游戏？那您现在都有既有的成见和想要达成的结论了，真的能够准确看出当时为何这样决定更新，还是只是一样拿来当成指控别人的工具（例如看到时间好像真比其他提名长几个小时，就开始嚷嚷着这是滥权，却完全无视其他人有自己的生活规律）？--KOKUYO（留言） 2022年6月26日 (日) 16:52 (UTC)

注：此留言已被原作者（User:车智贤）移除。2022年6月27日 (一) 11:54 (UTC)

1. 目前在ITN用机器人似乎技术上不太可行。用机器人的话，很可能造成没意见的一直上，有意见或意见已经处理等情况的一直上不去，最后因为过期而不能上--百無一用是書生 (☎) 2022年6月27日 (一) 02:30 (UTC)

   另外，“支持票数多且已有共识者优先采用”完全违背了ITN的处理原则，登上ITN最重要的参数不是票数，而是时间。一直以来都是按照时间顺序更新ITN，从最老的一个提名开始，如果最老的提名没有争议就登上ITN，有争议就暂时搁置，看次老的提名的状况，如是检视。票数优先只有在没有时间要求的情况下才有可能实行，如果在ITN实行票数优先，就有可能只是仅仅因为票数少而过期无法登上ITN（ITN评选和其他评选最大的不同点就是存在过期的概念）。正如KOKUYO所言，ITN的处理原则是只要没有争议，哪怕无人参与，也默认为共识是同意的--百無一用是書生 (☎) 2022年6月27日 (一) 02:45 (UTC)

   所以目前这个提案，唯一值得讨论的就是“条目内文未更新不得进入新闻动态。”这一条。其他完全无法落地，不可行--百無一用是書生 (☎) 2022年6月27日 (一) 02:50 (UTC)

   如果点击新闻动态的条目，发现条目内并没有新闻动态显示的内容，感觉很怪，甚至有一种被欺骗的感觉。虽然最近大部分都更新后再上新闻动态，但以前遇到过几回。--中文维基百科20021024（留言） 2022年6月27日 (一) 02:59 (UTC)

   我也同意这一点。其实一直以来也是这么操作的（只是有时候可能管理员没注意到条目内容没更新），更加明确化有必要。--百無一用是書生 (☎) 2022年6月27日 (一) 03:55 (UTC)

   不，某个提名一票反对，无支持，这不叫无争议，不叫有共识，但还是能上首页。--东风（留言） 2022年6月27日 (一) 04:17 (UTC)

   所以，一票反对票就能叫做有搁置更新的共识？为何不去看当初讨论是怎么讨论的、或这个有经过互助客栈讨论的流程是写什么，且去思考现在的运作情况是怎样？那是不是下一个人就要觉得，要像DYK那样4张支持票、互助客栈至少3人参与讨论、优良条目至少6张支持票，或者像管理员选举一样的做法，才叫做达成共识？--KOKUYO（留言） 2022年6月27日 (一) 07:46 (UTC)

   十个人参与一个人反对可能属于有共识；两个人参与一个人反对一定不属于有共识。倒不如考虑下WP:共识的优先级及约束力是高于所谓“经过互助客栈讨论的流程”的：“部分编者在特定地方和时间所达成的共识，不能凌驾更广泛的社群共识。”此外也没人要求必须“4张支持票”、“至少3人参与讨论”这种要求，没人参与讨论可以算成默认共识，两人参与且两人不同意自然不属于有共识。“理想情况下，共识不会存在任何反对意见；但假如无法实现这点，共识应采纳多数人的意见，并和重要少数的意见作出适当妥协。重大修改更应获得绝大多数的同意。”--东风（留言） 2022年6月27日 (一) 08:41 (UTC)

   第一，您表面上说要依照方针要求更高程度的流程（也就是上面提到的互助客栈流程），但是又不考虑互助客栈流程的做法，实际上只不过是随自己地任意设置门槛。假设要遵照互助客栈讨论非方针指引事项的层级，方针已经明确提到，只有提案人以外的3人同意、且无人反对的情况下，才可以在等待3天之后直接执行。很明显的，要么您引用的流程明显无法适用新闻动态候选，要么就是您曲解了方针的内容，不过是随自己心意解释（我甚至还没有提到公示7天的制定方针指引作法）。第二，也不需要所有地方的讨论都得要遵照互助客栈的运作方式，而可以视自身的运作特性处理，所以一昧地只是拿别的地方的方式去建议、而无视没有执行性的观点，明显是不可行的。第三，方针也已经明确提到，“没有异议或不被其他编者回退的编辑，均可假定其具备共识”，因此宣称既有作法是错误的，不过就是片面地解读方针。--KOKUYO（留言） 2022年6月27日 (一) 09:25 (UTC)

   所以没有任何支持票和反对票的提案，自然默认可以执行更新动作的共识。只有一张反对票或意见的提案，则尚未形成要延长讨论时间的共识，则应继续更新。假若有增加至两位反对意见，应撤回延长讨论。--KOKUYO（留言） 2022年6月27日 (一) 09:31 (UTC)

   另外，我与时昭所提到的流程是明确经过互助客栈的方针制定程序讨论、公告7天的内容，所有参与的人也都知道在维基百科上的方针指引规定。换言之，现在讲的流程具有方针指引的地位，只是因为页面不需要特别挂上模板，故根本不存在您所谓的“优先级与约束力”问题（甚至您所引用的那一句，是针对在专题、讨论页的讨论共识，而不是针对在互助客栈/方针依照制定程序提案并社群广泛讨论的条文）。我不觉得随便拿一个别处的方针指引，片面引用部分片段和解读后，就要所有人依照那个片面解读走，这样的做法是适宜的。--KOKUYO（留言） 2022年6月27日 (一) 09:53 (UTC)

注：此留言已被原作者（User:车智贤）移除。2022年6月27日 (一) 11:54 (UTC)

注：此留言已被原作者（User:车智贤）移除。2022年6月27日 (一) 11:54 (UTC)

注：此留言已被原作者（User:车智贤）移除。2022年6月27日 (一) 11:54 (UTC)

维护模板这件事情根本不可行，反而是要让管理员还要多承担审查条目质量的工作，且更容易遭到无理的攻击。我真的是希望大家是可以全盘地设想运作时候会发生什么事情，而不是只是因为感觉好像都是对的，就题提出根本无法执行的意见。--KOKUYO（留言） 2022年6月27日 (一) 09:06 (UTC)

建议修改第三点为“管理员认为提案符合新闻动态候选标准且有共识同意更新至首页的，应予采纳”，具体措辞可细调。--东风（留言） 2022年6月27日 (一) 09:14 (UTC)

在从上面得知您不理解新闻动态候选运作，及说要考虑互助客栈模式却又不知道该模式如何执行的情况下，增加一个让您往后可以继续操作的文字、制造后续的争论，没有必要吧？--KOKUYO（留言） 2022年6月27日 (一) 09:35 (UTC)

然后前面已经讲了，现在中文维基百科的运作模式明明就和英语为基百科存在差异，结果还一直要浪费时间推WP:ITN（而且还一堆人不知道过往讨论，甚至连哪些地方不可行都不知道），我真的不知道您们何不把时间弄在更有意义的地方，例如写条目、作站外推广什么的？--KOKUYO（留言） 2022年6月27日 (一) 09:37 (UTC)

“原则上依提名先后顺序更新”与当前的实际情况完全矛盾。更新顺序一直以来大体上都是按照事件发生的先后顺序更新，而从未按照过提名的先后顺序更新。如果按照提名的先后顺序更新，一来提名是要求按照时间的发生顺序来放置提名的位置，如果按照提名的先后顺序更新，找起来比较麻烦；二来按照提名的先后顺序更新的话，可能提名较晚但发生时间较早的新闻有可能只是因为提名晚而无法更新（在过期之前），比如6月27日提名了一个6月23日的新闻，ITN已经更新到6月22日，而这个6月27日提名的6月23日新闻，在他之前还有比他提名早的4条新闻等待更新，如果按照提名的先后顺序更新，那么这条新闻就很可能会因为提名太晚而无法更新，而按照现在按照事件发生的先后顺序更新的话，就能够在8小时后更新这条新闻，除非极端情况，否则不会出现无法更新的情况。

最后，强烈建议提出建议前先把整个方针和流程搞清楚再提出来。--百無一用是書生 (☎) 2022年6月27日 (一) 10:02 (UTC)

就以今天的ITN更新而言，6月26日提名的发生在6月22日的沉船新闻，如果按照提名顺序更新的话，根本不可能更新到ITN，而按照事件发生顺序更新的话，就完全可以更新到ITN--百無一用是書生 (☎) 2022年6月27日 (一) 10:07 (UTC)

我个人撤回所有留言和提案。--I'm an ARTIST, I'm a PERFORMANCE ARTIST. 250 OK: QUEUED AS 0 〈讨论〉 2022年6月27日 (一) 11:54 (UTC)

再次提议设立ITN方针

Shizhao、​KOKUYO、​Easterlies、​车智贤、​YFdyh000和Z7504由于Shizhao建议拿出完整的方案（以及目前并不存在的“方针”^{[开玩笑的]}），本人希望能够将此前编写的方针草案拿出，再次对其进行讨论（没有使用WP:ITN是因为该草案尚未翻译完成）。本人已将与此次讨论的相关内容编写到方针草案当中，集中反映在“基本要求及流程”与“获选标准及流程”两节当中。同时在此对上方KOKUYO对有关用户的恶意推定表示(！)强烈抗议。将有关用户的相关提议说成是“增加一个让您往后可以继续操作的文字”，本人非常好奇，明明所有的讨论都是公平公开进行的，为什么会变成只有某名用户可以继续“操作”？这种言论让人十分疑惑。此外，KOKUYO在讨论的前半部分中说“相关文字仅供参考”，在后半部分又说设立ITN方针“没有意义”，综合来看，很难不让人认为ITN是一个靠所谓“不成文规定”运行的机制。将一切规则都清楚地写在相关方针中，个人认为只有利处，没有害处。最后，有一点问题本人一直存在疑问，管理员在编辑ITN时是否也应适当“避嫌”？--Yining Chen（留言|签名页） 2022年6月27日 (一) 11:12 (UTC)

以前讨论的流程明明就都是经过讨论、公示并成文列出，现在却还一直说是不成文？这样不断散播错误信息的言论（可以从讨论记录、编辑记录证实整个流程设立成文的过程，就能知道相关言论为错误信息），社群是不是应该要考虑处理一下？--KOKUYO（留言） 2022年6月27日 (一) 11:21 (UTC)

同时，社群可以注意到此用户经常片面撷取他人文字，并去脉络使用的情形。例如，当我陈述最早相关文字大概是2012年或2013年左右由我翻译、并提供其他人作为论述参考的历史事实，却在这边与其他地方被该用户去脉络利用，借此声称我的意见是在否定2020年在互助客栈依照方针制定程序创建的更新流程，进而塑造ITN新闻更新流程没有明文规定、管理员滥用权限的错误形象。如此借由片面撷取他人言论进行操作、并经说明后还持续未有改善，已经延续了好几年的时间了。--KOKUYO（留言） 2022年6月27日 (一) 11:39 (UTC)

对于管理员能否提名、并依照更新流程同一人更新，当初在互助客栈的讨论中就已经明确指出，该制度设计就是允许管理员A提名、A结案。--KOKUYO（留言） 2022年6月27日 (一) 12:10 (UTC)

讲“避嫌”其实也就是个大笑话罢了，谁会知道到底有无“避嫌”？这种东西不论是谁提名都肯定是管理员去结案的嘛。不然ITN模板是有要开放给一般用户修改吗？如果没有，再怎么样讨论所谓方针也没屁用，永远无法改变是否有“避嫌”的问题。--Z7504非常建议必要时多关注评选（留言） 2022年6月28日 (二) 14:13 (UTC)

@KOKUYO：KOKUYO所言“该制度设计就是允许管理员A提名、A结案。”，跟据我所查阅的讨论，2017年，有用户质疑KOKUYO的此类操作，得到的回复概括来说是“这是惯例”。然而在2017年到2022年这一段时间内，本人也未能找到相关讨论。这件事令人很疑惑。一件事物在五年前是惯例，结果到五年后又变成了“有共识的讨论”。另外，KOKUYO负责ITN以来，WT:ITNC中至少有11次讨论直接质疑KOKUYO（不包括其他负责ITN的管理员）处理ITNC的流程存在问题。甚至从最早的存档中，2012年9月便可找到相关质疑（而且所质疑的内容与现在惊人地一致）。这个讨论是所有和ITNC有关的讨论中最早的讨论，因此可以基本确定，KOKUYO现在的行为并没有所谓“讨论”支持。为了严谨起见，本人翻阅了ITNC中所有的讨论，终于在2020年1月的讨论中找到了相关社群共识（即KOKUYO所说的“经过讨论的流程”）。但遗憾的是，该讨论的目的显然并非是解决上述11次讨论中的问题，而仅仅是对维持ITNC运转的最基本内容进行了讨论。该讨论与现在所提议创建ITN方针没有任何矛盾之处。本人很想知道，KOKUYO是否认为这11次讨论的发起都是在“恶意指控”呢？--Yining Chen（留言|签名页） 2022年6月28日 (二) 15:19 (UTC)

又开始在此处片面撷取他人文字利用，不肯承认自己的错误，甚至模糊时间发展。在2020年以前，新闻动态更新就是依照惯例去执行，其中包括延续长期以来管理员直接更新新闻动态的做法、及由我等人在2012年提议让其他用户也可以提供更新建议，也就是以双轨制方式进行。在2020年后，社群制定出现行现行更新流程，确立所有更新都得要经过候选页面的讨论，也讨论到此制度设计就是允许管理员A提名、A结案，并获得方针制定流程讨论通过。这项关于新闻动态更新流程的讨论依照标准的方针指引制定流程进行，为最新且最高级别的方针指引共识。然而，特定用户试图借由更早以前的讨论内容（甚至只是讨论，而不是经过标准流程确立的共识），随便否定、取消这项最高层级并得到广泛认同的共识。同时，在中文维基百科发展中，新闻动态从管理员直接更新制、管理员直接更新与一般用户提出建议后更新的双轨制、到新闻动态候选页面单轨制这件事情，都是现有记录能查得到的内容。结果大家可以见到，特定用户执意拿过往不同时间的讨论去混淆社群视听，无视在中文维基百科长期的发展中，新闻动态的运作与规则已经有数次变化，甚至如我前面提到持续片面撷取社群的文字、去脉络诠释，只为了达成自己的想要达成的目的。--KOKUYO（留言） 2022年6月28日 (二) 15:39 (UTC)

同时，大家在2012年的讨论之中也可以见到，最初有关新闻更新规范的内容，就是由我参考英语维基百科翻译过来，作为除了管理员直接更新这种长期以来的做法之外，让一般用户也能够参与新闻动态运作的补充途径。在这讨论过程，也有其他人有对于该参考内容的可行性不同建议，但是因为只是参考实验用的论述，所以先试试看该补充新制度。因此在当时，可以见到我和几位用户在扮演的是提出一种实验做法，补充只由管理员更新新闻动态的方式（而不是取代之），因此我完全不知道特定用户想要用2012年的这场讨论，指控我做了什么？难不成是又要错误地提出指控，说是因为我对新闻动态的更新，引发其他用户反对，为了安抚大家才创建候选页面？--KOKUYO（留言） 2022年6月28日 (二) 16:03 (UTC)

即使您现在说“此制度设计就是允许管理员A提名、A结案”，但没有任何方针条文明确规定，而这“双轨制”竟然只能从历史讨论存档中找到蛛丝马迹，这本身或许就是一件令人匪夷所思的事情（关键的问题是本人并没能从（2012年后的）历史讨论中找到这点）。并不是所有用户都有时间、有能力去查阅所有历史讨论存档。另外，为什么社群自2012年讨论得到的共识至今还没有得到整理，变成能够实际执行的方针条文，却依然停留在类似“论述”的阶段，这一点也令人感到很奇怪。最后，在没有ITN方针约束的前提下，本人很希望能够知道，如果某名管理员长期在处理ITNC的过程中带入个人倾向与偏见，并已有多名用户反映（体现出与之沟通的无效或低效），但其“严重程度”却尚未达到RFDA的标准。在这种情况下该怎么办才好呢？--Yining Chen（留言|签名页） 2022年6月29日 (三) 14:44 (UTC)

相信社群可以见到，特定用户再次混淆概念，试图误导社群的判断。该用户片面地否定了现有流程的讨论内容，试图借由去脉络的意见（无视明确经由讨论所下达的结论），以达成其错误的指控。同时，他也不断无视过往讨论情况，无端地拿过去运作模式提出指责，只是为了攻击特定人士。换言之，当有用户不断无视社群发展历程，不断片面地扭曲事实真相，而在其他用户说明整个发展历程后却还持续攻击、散播错误信息，我认为社群应该要警觉。--KOKUYO（留言） 2022年6月29日 (三) 17:28 (UTC)

您似乎在尽量避免回答某些问题。您反复指控本人“混淆概念，试图误导社群的判断”“片面地否定了 ...... 以达成其错误的指控”，但您自始至终也没举出一个讨论链接，只谈到了一个和本议题几乎无关的“2020年讨论”。能否请您就具体讨论来进行说明，而不是在此凭着可能根本不存在或不相关的讨论来攻击本人“不断无视社群发展历程，不断片面地扭曲事实真相”？--Yining Chen（留言|签名页） 2022年6月30日 (四) 14:50 (UTC)

您先拿不存在的社群发展历史指控人（宣称管理员直接更新制与双轨制不存在，把提供参考的页面直接宣称是有共识的），然后又把过往存在的制定流程讨论当成没有价值的东西（宣称方针制定流程的共识只不过无意义的、无关的东西），这不是“不断无视社群发展历程，不断片面地扭曲事实真相”，不然是什么？--KOKUYO（留言） 2022年6月30日 (四) 15:28 (UTC)

我没细阅具体情况，但这事或许值得送一送去用户查核。之前几次提出这个常年提案的时候也是差不多的事件背景，我感觉有些像是具针对性和目的性的。Sanmosa _{Királyunk s a közhazát} 2022年6月29日 (三) 15:32 (UTC)

@KOKUYO。Sanmosa _{Királyunk s a közhazát} 2022年6月29日 (三) 15:33 (UTC)

如果社群持续容许少数人在讨论中运用错误、片面的意见，并随之起舞的话，我们似乎就不能讶异为何WGUC或被特定团体集体攻击与造谣，为何台湾分会会被特定团体指责是台独分会，为何新闻动态被特定团体攻击与试图影响结果，以及为何最后是由基金会采取行动，而不是社群就能够自行处理。--KOKUYO（留言） 2022年6月30日 (四) 15:45 (UTC)

• 方针需要人来执行。如果ITN继续依赖kokuyo来更新，方针更动恐怕没有什么意义。他最多就放弃这一块而已。---Temp3600（留言） 2022年6月29日 (三) 17:55 (UTC)

  之后多选几位愿意协助更新新闻动态的管理员就好了。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2022年6月30日 (四) 07:49 (UTC)

  以社群这种态度来看，根本不可能选出来。互相投出反对的管理员选举、要不要用安全投票都在那墨迹的，如何选得出来？这样的话是不是谁都能直接当管理员不用选举了？因为此选举会容易把想更新ITN模板的用户人才给舍弃掉嘛。--Z7504非常建议必要时多关注评选（留言） 2022年6月30日 (四) 12:24 (UTC)

  尽管维基的志愿者们都很有责任感，假设工作自然会有人接手仍不是很理想的做法。--Temp3600（留言） 2022年6月30日 (四) 13:48 (UTC)

  降低ITN编辑资格或许也是一种解决方案。--Yining Chen（留言|签名页） 2022年6月30日 (四) 14:41 (UTC)

  技术上应该是有方法的，但是这终归是治标不治本。--Ghren🐦🕚 2022年6月30日 (四) 15:00 (UTC)

  请别忘记连锁保护这玩意。--Z7504非常建议必要时多关注评选（留言） 2022年6月30日 (四) 15:08 (UTC)

  辨法总比困难多。--Ghren🐦🕚 2022年6月30日 (四) 15:20 (UTC)

  所谓“依赖我更新”这个前提就是有问题的讲法，我从来没有说中文维基百科管理员只有我和时昭能更新，也从没有阻挡其他管理员要参与这部分。只要依照既有的规则，要更新什么新闻我都没意见。假若有不符合更新规则的，退回并和该管理员说明即可。--KOKUYO（留言） 2022年6月30日 (四) 15:51 (UTC)

  现在很明显的问题应该是，一小部分人对于当前经过互助客栈的方针和流程都还不清楚，就开始因为不同原因，以自己所以为的东西，来指责他人根据流程进行更新是滥用权限。当然，讨论都是可以的（我相信时昭也是这么想），但是如果是持续从错误的基础提出指控，我想这也是为何时昭会会在前面讲出重话了。--KOKUYO（留言） 2022年6月30日 (四) 16:03 (UTC)

  “依赖我更新”一句中，我想表达的是“目前kokuyo处理的ITN更新量占了总体工作量的大部分”。当然不是指职责划分或是占地为王的意思。--Temp3600（留言） 2022年6月30日 (四) 16:02 (UTC)

修改WP:PAID/ALT

现行条文 （就中文维基百科非现有条目而言）在草稿命名空间或其自身的用户页及／或子页面内进行写作，并且提请{{AFC submission}}，审核通过后才能够正式成为条目；

提议条文 （就中文维基百科非现有条目而言）在草稿命名空间或其自身的用户页及／或子页面内进行写作，并且提请{{AFC submission}}，审核通过后才能够正式成为条目，可使用条目向导完成此流程；

这个方针对于某些新手来说可能比较不好理解，提供一个向导对于新手来说比较易于理解，而且条目向导中也有关于关注度、有偿编辑等的指导。 --桐生ここ★[讨论] 2022年6月24日 (五) 06:34 (UTC)

写一份面向新手的指南比起微调方针好，无论怎么微调方针，几乎不适合直接让新手阅读。--Xiplus#Talk 2022年6月25日 (六) 13:51 (UTC)

• 不反对这项修改，但长远计是应该写指南。但这项改动也没有坏处。-Temp3600（留言） 2022年6月29日 (三) 17:56 (UTC)

修改 uw-ublock 系列模板样式

相当一部分因用户名不当而被封禁的用户并不具有刻意进行破坏的动机，这种情况下使用与其他永久封禁样式的警告模板通知其已被封禁，未免会影响其参与贵站的念头。正如Template:Uw-ublock模板文档页所描述的，用户名封禁系列模板是存在两种的，一种是Twinkle所使用的“假定善意”向，另一种则是使用人数相对较少的“假定恶意”向的。既然称之为假定善意，那使用一个相对友好点的布局/配色方案就非常自然了。个人推荐借鉴隔壁英文维基的样式：蓝色（而非橙色）背景、使用information系列的icon而非一个大叉号。 Stang^★ 2022年6月27日 (一) 20:56 (UTC)

建议改成使用Template:Uw-block/doc/Block_templates/Username列出，包含更具体理由的模板。--Xiplus#Talk 2022年6月28日 (二) 05:52 (UTC)

• 支持方向。等待本地化版本。--Temp3600（留言） 2022年6月29日 (三) 17:59 (UTC)