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

添加话题

本页提出或讨论维基百科政策、方针,请参看方针与指引方针列表
繁简处理的议题请前往字词转换讨论页
条目应当如何编辑才符合中立性原则寻求社群共识,请前往条目探讨留言。
请注重礼仪、遵守方针与指引,一般问题请至互助客栈其他区知识问答提出,留言后请务必签名(点击 )。


发表前请先搜索存档,参考旧讨论中的内容可节省您的时间。
公告栏
# 💭 话题 💬 👥 🙋 最新发言 🕒 (UTC+8)
1 提议新建交通车辆条目内容指引2 123 24 铁路1 2022-08-11 10:53
2 提议修改维基百科:防滥用过滤器 72 20 Kriz Ju 2022-08-16 03:01
3 关于接下来的管理员投票 161 32 Yining Chen 2022-08-15 11:16
4 建议修改音乐关注度规则 1 1 Jimmy-bot 2022-08-16 08:14
5 提议在电子游戏条目指引中规范游戏数字发行平台外链 43 12 YFdyh000 2022-08-15 18:17
6 修正快速删除方针 16 8 Kriz Ju 2022-08-17 02:25
7 提议设立容许查看私密信息的用户组/flag 11 10 Kriz Ju 2022-08-16 03:06
8 配置表单来方便用户发邮件申请账户或申请IPBE权限 15 6 Ericliu1912 2022-08-10 16:00
9 电视剧演员与角色排序指引 20 6 Kriz Ju 2022-08-14 05:12
10 有关节目列表条目的删除标准的补充讨论 9 3 Anicat233 2022-08-09 21:45
11 维基百科:关注度/提报问题 24 8 Kriz Ju 2022-08-12 06:40
12 修改"特色图片标准" 5 4 Kriz Ju 2022-08-17 03:26
13 提议将格式手册/序言章节#列明来源设为方针指引 73 11 Nostalgiacn 2022-08-12 22:26
14 提议创建中小学条目指引 17 7 Kriz Ju 2022-08-15 02:22
15 提议规定巡查时将页面移动至草稿的规则 5 5 Kriz Ju 2022-08-11 05:28
16 修订编辑战方针(二) 10 4 Kriz Ju 2022-08-17 03:17
17 修订傀儡方针涉法律威胁之字样 9 7 Kriz Ju 2022-08-14 05:15
18 可靠来源方针增加用户生成内容 10 5 Longway22 2022-08-14 16:28
19 WP:修订版本删除小修订 3 3 Kriz Ju 2022-08-17 04:11
20 提议将格式手册/音乐排行榜设为指引 24 7 Milkypine 2022-08-17 00:07
21 无法理解NT:SCHOOL为何对公立与私立高中区别对待 8 2 C933103 2022-08-16 12:34
发言更新图例
  • 最近一小时内
  • 最近一日内
  • 一周内
  • 一个月内
  • 逾一个月
特殊状态
已移动至其他页面
或完成讨论之议题
手动设置
当列表出现异常时,
请先检查设置是否有误

提议新建交通车辆条目内容指引2

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

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

铁路车辆

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

客运/公车车辆[注 1]

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

条目内容 不合适的内容

  1. 爱好者内容
    • 铁路车辆:请不要将车辆车次运用、车号机务段分配、改造期程、交车期程等琐碎信息加入条目内。
    • 客运/公车车辆:请勿将领牌车号、行驶路线、停靠站牌等琐碎信息加入条目内。
    依据:维基百科不是不经筛选的信息收集处-说明书
  2. 大量的短条目:通常一个较大的条目能提供对主题更有条理的介绍与背景联系。当大条目能做到时,请不要创建大量小条目。理想的条目是既不过大,也不过小。
    依据:维基百科的条目大小指引
  3. 过多的图片:请勿于条目内放置各车号的照片,于信息框模板一张代表即可,其他照片则放入共享资源并于底下纳入共享资源链接导引。
  4. 原创研究内容:原创研究内容建议写在维基学院内。
    依据:非原创研究

备注

  1. ^ 此指大客车、巴士,不含小客车、计程车,小型车请参见汽车一节。

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

似乎没有通知成功,重新标注一次@owennson心平星辰一片楓葉BIT0865Bus FollowerMys_721txNryaLuciferianThomasGhrenghrenSickManWP--🚊铁路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)
还有就是:DKZ4RG6023-A-M06C02VFI-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心平星辰一片楓葉BIT0865Bus FollowerMys_721txNryaLuciferianThomasGhrenghrenSickManWP@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:虽然目前尚未很完全,因铁路条目近期较混乱,在下的想法是将最大宗的共同问题先行初步整顿,预计后面还会再提出其他车辆或细项,希望在台铁的新车交车前先有个指引约束内容,避免与EMU900EMU3000条目一样混乱。--🚊铁路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)
(+)强烈支持。不过可能存在一些因铁路交通工具的本地特殊性而需微调行文架构的问题,大概也应属于可接受范围?--         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)

🕗 公示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)
@MaccomcreOpky9407ShizhaoLuciferianThomas:已进行修正,还请指教。--🚊铁路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)
(:)回应:把“统一格式”改为“同样格式”又再改为“相同格式”,真的不知道意思有什么改变,跟“请放手调整,不必拘泥于本文”还是矛盾。还有为什么铁路条目加了车辆保存,但是公车条目就没有加?这下子又出现了之前发生过的问题:这是按什么逻辑定的?逻辑不明的制定方法那只能(-)反对。--Opky9407留言) 2022年7月7日 (四) 13:02 (UTC)
@Opky9407
  1. 相同与统一在下认为还是用差异,统一为强制规定,相同则非强制,使用非强制呼应“请放手调整,不必拘泥于本文”是合适的,若阁下有更好的说明方式还请指教。
  2. 保存车辆的部分,铁路车辆依照过去阅读与编辑过的条目增加,而公车条目在下参照Category:巴士型号分类内的条目,随机看了数篇条目没发现有此介绍章节,故无新增。
  3. 不一定铁路有的公车就一定也要有阿...这样一条指引内容就干脆直接适用所有交通工具。--🚊铁路Railway 2022年7月7日 (四) 15:34 (UTC)
补2:观察约6、70篇左右。--🚊铁路Railway 2022年7月7日 (四) 15:50 (UTC)
梅赛德斯-奔驰Vario这款巴士就有车辆保存。相同和统一的意思我觉得一样,没有强不强制的差别。还是维持反对定这种架构的想法。--Maccomcre留言) 2022年7月17日 (日) 07:49 (UTC)
已更改--🚊铁路Railway 2022年7月18日 (一) 10:50 (UTC)
(?)疑问 “信息框:一般用用”这块是不是多了一个“用”。另外为什么铁路和公车的可靠来源说明不一样。--Yinyue200留言) 2022年7月20日 (三) 13:56 (UTC)
@Yinyue200:感谢提醒,已修正。公车的可靠来源有哪些在下不清楚,因此就没有举例。--🚊铁路Railway 2022年7月20日 (三) 16:36 (UTC)

  公示7日,2022年8月4日 (四) 00:21 (UTC) 结束:超过7日无新意见,公示7日。--🚊铁路Railway 2022年7月28日 (四) 00:21 (UTC)

  • 把相同改为相似,事实上没有解决到我提出的问题,就拿回我之前提到的“港铁中期翻新列车新干线E2系电力动车组日本国铁D51型蒸汽机车等香港、日本铁路车型都跟上面的架构有很大不同(JR东日本车辆形式里面就有大部分车型都跟上面的架构有很大不同)”,很大不同其实也意味着不相似,如果又是一大堆条目因为跟条文不相似而当成是有“特殊之处”来处理,那么定来的架构也是没有意义,所以继续(-)反对,维持宁可完全不要直接把行文结构定出来的想法,只规定不能有哪些内容就够了。--Maccomcre留言) 2022年8月3日 (三) 18:06 (UTC)
    @Maccomcre:就阁下所提与其他条目,在下观察下来统整,基本上架构不外乎以下大纲:引言、信息框、概要(概述、简史)、规格构造(内装、机电、涂装、结构、编组…)、各代车辆(子型号、外销型号…)与一两小节针对该车特殊小节。如上阁下所提的条目也就是换了不同名称与架构较分散介绍而已,例如E2系:“型式和车型”、“不同点”与“出国中国”可归类在各代车辆内,“编组”可并入构造底下,“速度实验”、“东北新干线的高速化实施”与“今后项目”可归类在历史内。指引主要是指引出建议大纲,不是要所有细节都要绑死。( π )题外话:此讨论已经从元旦讨论到现在已经足足8个月了,近期都是一周无人发言公示,然后又在公示结束前才又回复,这样时间拉距实在很没讨论效率,虽然可能大家平常时间很忙不常上线,但作为主提议的几乎每次等到公示结束前才等到回复感到无奈疲累疲😴,--🚊铁路Railway 2022年8月4日 (四) 02:49 (UTC)
    那样是叫有相似的元素,而不是相似的格式。--Maccomcre留言) 2022年8月16日(二) 22:00 (UTC)

  公示7日,2022年8月18日 (四) 02:53 (UTC) 结束:超过7日无新意见,公示7日。--🚊铁路Railway 2022年8月11日 (四) 02:53 (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)

(!)意见 不建议隐藏过滤器详情。倘若真的隐藏描述详情,部分回退员甚至可能无从得知这个过滤器是干什么用的。支持User:魔琴所总结的提高回退员申请门槛和重启讨论WP:EFH。 如果技术上可行,能不能给部分有实质性贡献且账号足够安全的回退员开放所谓的“防滥用过滤器简介”?与过滤器源码查看权限分开,并且简介可以写的比较空泛笼统(tips:不太了解具体的权限机制,不清楚回退员看的过滤器详情具体能精细到什么程度  囧rz……)——诚挚的 ZhaoFJx 2022年7月3日 (日) 11:17 (UTC)

现有回退员中可能已有“内奸”。提高往后权限申请之门槛无助于解决目前实际存在之问题。—— Eric Liu 創造は生命(留言留名学生会 2022年7月4日 (一) 10:19 (UTC)
但还是存在上面说到过的问题,开放EFH之后,这个权限的实际申请/应用场景是什么?----Yichen Ding留言|主账户) 2022年7月5日 (二) 14:50 (UTC)
场景是非熟练者(一般回退员)无需持有权限,以减少攻击面。并或许会促进一些讨论和流程。--YFdyh000留言) 2022年7月5日 (二) 15:23 (UTC)
检视破坏?维护?捉? ——魔琴 [ 留言 贡献 ] 2022年7月13日 (三) 17:22 (UTC)
我认为将权限分拆有助于专业分工。—— Eric Liu 創造は生命(留言留名学生会 2022年7月21日 (四) 13:50 (UTC)
(+)支持:个人支持划分相关权限,在综合考量相关功能实用性、公开程度必要性、用户站务经验和专业性、反破坏实务需求和可能的人力养成,以及许可信任机制等因素下,可考虑启用固有之维基百科:过滤器助理权限方案,或是在现有基础下增列进阶回退员权限(姑且暂称,若可能建议有个权限专属图示)。为期许具专业技术之可信回退员长期投入贡献且强化相关许可机制,直接在现有的回退员权限加增类似“进阶回退员”或“技术回退员”(暂称)之类的区隔(比如在《维基百科:回退功能的额外功能》章节附近加增改写),而具备相关条件的回退员若有实际需求,认为知道过滤器代码详情有助于自身的反破坏工作,且可以协助管理员维护甚至讨论代码内容,应可适当获得许可。
综观以上站友讨论,个人认为关键在于过滤器的代码设计内容对所有回退员公开是否有益,而非回退员权限之申请和权能本身具备何种弊端,且单纯提高该权限申请门槛,似已超过原先核心命题的“过滤器设计代码公开争议”,对于反破坏站务长期而言亦未必有益;因此我认为本质上应回归过滤器代码公开的对象范围及是否有益于多数回退员行权和执行反破坏站务,进一步而言可考量是否有益于具经验的可信用户进一步探索深耕或发展过滤器设计维护相关领域,而获权用户的持权操守仍回归“许可信任”相关问题。个人考量和理据如下:
  • 首先,就一般的用户需求而言,我不认为需要了解此种过滤器设计专业,而目前而言了解相关专业亦非获权之必备条件。一般回退员若仅需“反破坏”,实则看不懂相关程式代码设计的话(比如敝人完全看不懂),通常能看到“过滤器日志”便足够,所以我认为让真正有需要、了解相关专业、具丰富反破坏经验且自认能对社群和站务有益的可信任用户视实际需求申请即可。否则连一般反破坏都未必具足够经验,或不具程式代码相关专业,我认为若说要了解代码设计细节以有效分担站务或反破坏,实在难说具足够说服力。
  • 承上,因此个人建议规划权限,比如直接采用过滤器助理之规划;若社群对于新设该权限有所争议,亦可考虑在现有基础上直接于回退员权限增列“进阶回退员”,申请条件可考虑为:“持续于反破坏站务活跃之回退员依实务需求提出申请,经至少一名进阶回退员或具过滤器设计维护站务经验之管理员支持,由具相关站务经验之管理员综合考评后许可;若许可申请由具相关经验之管理员支持提请,则许可之管理员不得为同一人。当社群对申请人获权具足堪忧虑之具体事由,或参与讨论之进阶回退员意见显明歧异,则管理员不应许可。”(“活跃”标准可参考《维基百科:过滤器助理》另订之)。
  • 对于“防滥用过滤器管理”页面中提供的公开讯息(尤其是“所有过滤器”之动态列表),对一般用户公开之作用以及对于反破坏之利弊,个人认为社群可斟酌衡量(个人倾向该列表不应被所有人看见)。
  • 最后,个人认为将过滤器设计代码公开范围略作规划,并非保证过滤器讯息绝无外泄可能或此后可禁绝防堵相关破坏者,仍需仰赖获权用户自持自重。
以上为个人意见,供参。--Kriz Ju留言) 2022年7月26日 (二) 19:57 (UTC)
意见大致相同。申请条件还得待社群讨论。动态列表似乎不能隐藏。 ——魔琴 [ 留言 贡献 ] 2022年8月1日 (一) 06:36 (UTC)

#提议设立容许查看私密信息的用户组/flag。个人觉得既然直接移除权限不可能达成任何形式的共识,倒不如等候下方讨论更好。--西 2022年8月5日 (五) 08:50 (UTC)

同意。—— Eric Liu 創造は生命(留言留名学生会 2022年8月13日 (六) 17:06 (UTC)
下方技术问题似乎在短时间内无法得到解决,可能使这两个讨论串维持长时间开放但无法得到有效进展。故暂且移除下方“不存档”标记,待所有事务处理完毕后再进行讨论或许会更好。--Yining Chen留言|签名页) 2022年8月15日 (一) 03:23 (UTC)
(!)意见:若条件许可,个人发想之后或可将此案结合下方“提议设立容许查看私密信息的用户组/flag”做适当规划。--Kriz Ju留言) 2022年8月15日 (一) 19:01 (UTC)

关于接下来的管理员投票

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

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

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

@Lanwi11233中文維基百科20021024Z7504Yining ChenATEricliu1912SanmosaOutlookxp。--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)
@中文維基百科20021024Wikipedia 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.安全投票机制若能明确标注显示“中立票”之附含意见较为理想;若最终安全投票界面仍不具此功能,且社群或具权限之监、验票人员仍期待便于识别中立票内含之意见,窃以为于投票须知明确规范:“当用户投下中立票,应于投票意见栏明确表达该票附具之意见或评价为‘中立’,以便选举结果之识别判读。”即可(如投票用户应于意见栏写明:“中立,基于候选人....,但仍.....”;“投下中立票。平日候选人之站务表现已具XXX和OOO,往后可再加强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)
  • 普通投票的缺点已经很清楚了。暂时没有看出支持者有什么补救办法。--Temp3600留言) 2022年7月2日 (六) 19:28 (UTC)

若有什么人适合普通投票,大概以非被罢免的前管理员以及部分被WMF除权的前管理员居多,这些前管理员没有严重违规行为。--Lanwi1(留言) 2022年7月3日 (日) 04:04 (UTC)

 2016-08-20T17:44:49 Lanwi1 讨论 贡献 封禁解封了守望者爱孟 讨论 贡献 (封禁申诉)
--Mys_721tx留言) 2022年7月3日 (日) 13:27 (UTC)
@Mys 721tx:那是过去的我,我从爱孟被禁制后才明白自己的问题。现在的我已经不再是2018年4月以前的我了,人是有成长的。--Lanwi1(留言) 2022年7月3日 (日) 13:36 (UTC)
所以你觉得自己的问题是?--日期20220626留言) 2022年7月3日 (日) 13:38 (UTC)
我当时的问题是擅自解封,现在因为在爱孟事件中吸取教训,所以在Walter Grassroot事件中未犯相同错误。--Lanwi1(留言) 2022年7月3日 (日) 13:47 (UTC)
像上面这样的列出过去的问题对现在的我而言已经没有意义了,现在的我早已不想再碰像爱孟这样的封禁,在Walter Grassroot的封禁案我已经做到不想碰了。不明事理者就是不理解正常人犯错后会改进自己的行为,使自己不会再犯相同错误。--Lanwi1(留言) 2022年7月3日 (日) 18:04 (UTC)

(+)支持采用安全投票。“无法考虑中立票的意见”称不上是个问题,要想发表意见,可以去相应的RFA页面。“双轨并行”意味着仍要承受部分传统投票的缺点,我觉得没有必要;如果用户愿意,他们也可以在RFA页面表达支持或反对的意见。--CuSO4 2022年7月7日 (四) 04:23 (UTC)

如果要继续使用安全投票,是因为试验还没结束,需要“Key person”(指有影响力的关键人物)参选才能证明安全投票的效果。--Lanwi1(留言) 2022年7月11日 (一) 11:19 (UTC)

要不然就再“试行”几次?—— Eric Liu 創造は生命(留言留名学生会 2022年7月11日 (一) 13:48 (UTC)
不知道谁想参选。如果我有方案,那就让包括部分被WMF除权的在内的人集中参选,正好消除对去年的基金会行动的最大不满,即活跃的反破坏管理员被除权。--Lanwi1(留言) 2022年7月11日 (一) 16:18 (UTC)
看来按这社群速度,要不我们再临时数次试试看比较好。Ghren🐦🕛 2022年7月12日 (二) 16:25 (UTC)
我的意见就是再次试验,问题是谁想参选?--Lanwi1(留言) 2022年7月13日 (三) 01:52 (UTC)
上次试验通过后很快就有人提名。应该不用担心没人参选的问题。如果再次试验可以尝试一下多人同时参选。设立一周左右的提名期,通过提名的候选人集中使用安全投票选举。--Steven Sun留言) 2022年7月13日 (三) 09:22 (UTC)
多人同时参选最好,我已经想好提名谁了。--Lanwi1(留言) 2022年7月13日 (三) 09:42 (UTC)
但是再次“试行”安全投票是否需要社群许可?—— Eric Liu 創造は生命(留言留名学生会 2022年7月15日 (五) 03:19 (UTC)
跟上一次试验一样,再次试验。--Lanwi1(留言) 2022年7月15日 (五) 10:44 (UTC)
上次“试行”系经社群投票许可,这次虽然不一定要重新进行表决,但仍应得到社群共识。另外,还要多“试行”几次,这也需要讨论。—— Eric Liu 創造は生命(留言留名学生会 2022年7月15日 (五) 12:00 (UTC)

(!)意见:可以采用双轨制,但普通投票只能投带有意见的中立票,而且不能重复投。这相当于行政员只考虑没有使用安全投票的用户的意见。Acetophenone留言) 2022年7月14日 (四) 18:19 (UTC)

(+)支持完全使用安全投票,并可在对应的 RFA 页面发表意见。--冥王欧西里斯留言) 2022年7月12日 (二) 09:24 (UTC)


看样子要继续使用安全投票了,安全投票暂行规定是否需要修改?--Lanwi1(留言) 2022年7月20日 (三) 10:08 (UTC)

如果社群就相关议题达成共识,我可以协助调整规定内容。—— Eric Liu 創造は生命(留言留名学生会 2022年7月20日 (三) 13:01 (UTC)
整理一下上面的讨论?--冥王欧西里斯留言) 2022年7月24日 (日) 00:24 (UTC)
我觉得要讨论的议题至少有:安全投票是否与原投票方式并行;以及如何修改安全投票暂行规定以应用于未来之申请等。—— Eric Liu 創造は生命(留言留名学生会 2022年7月31日 (日) 07:43 (UTC)
如果此次决定要再次试验,建议在此前试行的基础上放开人数限制,即提名期达到票数要求即可参选。--Yining Chen留言|签名页) 2022年7月24日 (日) 01:02 (UTC)
暂时支持再次试验,意见同Yining。 ——魔琴 [ 留言 贡献 ] 2022年8月1日 (一) 06:37 (UTC)
这独裁社群真的在搞笑,原来过了一个多月的讨论了结果还是要用安全投票嘛,都已经故意不想理会了。那请问为何没有办法直接6月底、7月初左右的时候就说继续用安全投票,非要等到8月才能做出决定呢?肯定是因为维基百科已经是一个标准的“Parkinson's Law”了。搞笑的东西,原来要不要用安全投票要犹豫一个多月那么久?--Z7504非常建议必要时多关注评选留言) 2022年8月5日 (五) 17:59 (UTC)
社群讨论流程确实推进地有些慢,不过还轮不到您冷嘲热讽呢。—— Eric Liu 創造は生命(留言留名学生会 2022年8月6日 (六) 14:15 (UTC)
中维不重视,所以推进就是慢。--Lanwi1(留言) 2022年8月8日 (一) 03:43 (UTC)
好了好了,既然都知道推进慢就不要在没意义的讨论中浪费时间了。再次试验大概相比这次试验需要调整哪些内容?--BlackShadowG Slava Ukraini! 2022年8月8日 (一) 10:55 (UTC)
目前看起来大概就还要不要保留传统投票吧?但上面的讨论看起来似乎比较倾向仅供表达意见,不做投票用。--冥王欧西里斯留言) 2022年8月8日 (一) 11:47 (UTC)
安全投票暂行规定看起来不需要修改,只需要多人参选。--Lanwi1(留言) 2022年8月9日 (二) 04:38 (UTC)
但若需支持多人参选,就需要修改“暂行规定”;而且中维最终还是需要一个“永久”规定。所以不如趁此机会直接制定安全投票指引。 --Yining Chen留言|签名页) 2022年8月12日 (五) 15:19 (UTC)
建议安全投票暂行规定先继续实行,安全投票指引现在由于社群讨论流程慢而不宜直接制定。--Lanwi1(留言) 2022年8月12日 (五) 15:42 (UTC)
根据社群所达成共识之不同,亦有可能只须微调暂行规定以继续适用于当前之情况。—— Eric Liu 創造は生命(留言留名学生会 2022年8月12日 (五) 15:46 (UTC)
微调有可能,但不知道要等到什么时候才有共识。--Lanwi1(留言) 2022年8月12日 (五) 16:48 (UTC)

调整“安全投票暂行规定”

如果只需要支持多人参选,则可对现“暂行规定”中“预提名”一节进行如下微调:
现行条文

预提名:由于未来一场选举之被提名者以一人为限,应当在互助客栈其他区集中进行预提名作业;愿意接受正式提名并回答前述三个基本问题、最先得到七位具人事任免投票资格之用户联署支持,且符合成为管理员之资格者,经行政员确认,即获得正式提名,将优先进行选举,并应比照前述之一般流程另行设置个人选举页面。若最先获得足够联署支持者未能符合前述要求,则应依序递补以决定获正式提名者。

提议条文

预提名:未来一场选举将仿照此前的安全投票选举流程,进行预提名。愿意接受正式提名并回答前述三个基本问题、得到七位具人事任免投票资格之用户联署支持,且符合成为管理员之资格者,经行政员确认,即获得正式提名,将进行选举,应比照前述之一般流程另行设置个人选举页面。预提名期限为七天。

--Yining Chen留言|签名页) 2022年8月13日 (六) 03:57 (UTC)
别忘了修正投票资格,上次投票中发现的问题。--Xiplus#Talk 2022年8月13日 (六) 07:01 (UTC)

(+)支持--Lanwi1(留言) 2022年8月13日 (六) 05:45 (UTC)

(~)补充:对于上方提到的投票资格,结合上一次投票的实践,建议再向暂行规定中加入如下内容:
提议条文

投票资格 由于技术限制,依照Wikipedia:忽略所有规则,此次安全投票的投票资格要求与Wikipedia:人事任免投票资格之规定稍有差异。符合以下两项之至少一项条件者有权投票:

  1. 投票预提名结束开始120天前,编辑至少500次;并在预提名开始前90天内至少有1次编辑(不包括任何用户页及用户对话页);
  2. 编辑至少3000次,或编辑条目至少1500次。

另外,

  • 下列用户将被排除:
    • 被全站无限期封锁、全域锁定;预提名结束前被封锁、禁制维基百科命名空间。
    • 拥有机器人群组、用户页标记为机器人。
    • 用户名判断为隐退用户。
  • 下列用户不具有投票权,但不会被排除:
    • 合法多重账号;您仅可使用一个账号投票,否则会触犯傀儡方针
    • 候选人。

其余要求请参考人事任免投票资格、申请成为管理人员等方针指引。

希望能够就以上两项更改提议进行讨论并达成共识。--Yining Chen留言|签名页) 2022年8月13日 (六) 14:13 (UTC)
这是技术说明文件,不是指引应有的行文。指引可以规定工具应遵守的程序或功能,但不应规定仅能使用特定工具。--Xiplus#Talk 2022年8月14日 (日) 03:12 (UTC)
候选人的部分,我之前提供的列表是通用版本,因此不会排除候选人,但只要将这份列表再根据各别RFA进行处理,就可以排除候选人,在指引内写“由于技术限制”显然是不对的。--Xiplus#Talk 2022年8月14日 (日) 03:13 (UTC)
机器人和多重账户的部分,都是傀儡方针规定无投票权的范围,但因为机器人账户是技术上可自动排除的投票权人,所以才在自动列表上直接排除,但这不代表未被排除的就有投票权,一切都还是要看傀儡方针和其他方针的规定,因此在指引内复述是不必要且不正确的。--Xiplus#Talk 2022年8月14日 (日) 03:18 (UTC)
另外我不懂为何要提到IAR?制定规则的时候就不应该制定一个已经预期会有错误的规则,导致之后必须援引IAR。--Xiplus#Talk 2022年8月14日 (日) 03:34 (UTC)
关于首句“技术限制”及其后所提到的IAR,针对的都是上一次有人质疑的“基准时间问题”。毕竟依照现行Wikipedia:人事任免投票资格方针,所谓“基准时间”必须是“投票正式开始”的时间。所以把“技术限制”和“IAR”写入其中。如果要更改人事任免投票资格方针,可能需要另开讨论,整体的流程也可能会更加冗长。--Yining Chen留言|签名页) 2022年8月14日 (日) 03:42 (UTC)
直接继承人事任免投票资格方针并定义基准时间不就好了?例如“投票:...在预提名开始之时具人事任免投票资格...”--Xiplus#Talk 2022年8月14日 (日) 03:50 (UTC)
还有资格为何一个是预提名结束,另一个是开始?--Xiplus#Talk 2022年8月15日 (一) 01:22 (UTC)
  已解决。--Yining Chen留言|签名页) 2022年8月15日 (一) 03:16 (UTC)
考虑之后重拟一案。另外预提名作业之期限何以定为三日?—— Eric Liu 創造は生命(留言留名学生会 2022年8月14日 (日) 11:13 (UTC)
考虑到上一次预提名过程进行的速度,个人认为预提名时间过长可能会使候选人的数量超过社群能有效处理的范围,进而产生其他问题。--Yining Chen留言|签名页) 2022年8月14日 (日) 15:00 (UTC)
在以前也没有限制同时进行RFA的数量,增加预提名会有什么问题吗?--Xiplus#Talk 2022年8月14日 (日) 15:03 (UTC)
似乎确实无必要,因此参考WP:共识修改为七天。--Yining Chen留言|签名页) 2022年8月14日 (日) 15:49 (UTC)
目前看起来就这样了,还有什么要改的吗?--冥王欧西里斯留言) 2022年8月14日 (日) 23:31 (UTC)

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

建议修改音乐关注度规则

提议在电子游戏条目指引中规范游戏数字发行平台外链

针对WP:页面存废讨论/记录/2022/06/11#Template:Steam的讨论结果,结合WP:ELNO的具体条文,现拟议在WP:电子游戏条目指引中加入对游戏在线商店外链的规范:

现行条文

合适的外部链接-如果存在这些链接,应当在电子游戏条目中列出

  • 电子游戏官方主页(由开发商或发行商提供)。游戏如在中文区发售应优先列出中文版主页。如果是外文游戏,还应列出首发国家的语言版本并注明网站是外语。如果开发商和发行商提供的网站不同则应一并列出。

...

提议条文

合适的外部链接-如果存在这些链接,应当在电子游戏条目中列出

  • 电子游戏官方主页(由开发商或发行商提供)。游戏如在中文区发售应优先列出中文版主页。如果是外文游戏,还应列出首发国家的语言版本并注明网站是外语。如果开发商和发行商提供的网站不同则应一并列出。对于没有独立官方主页的电子游戏,可采用Steam等数字发行平台的页面作为官方主页,否则不可加入

...

以上。--百战天虫留言) 2022年7月10日 (日) 06:24 (UTC)

(!)意见 那为什么影视剧就可以加入付费观看的链接呢。--Yinyue200留言) 2022年7月10日 (日) 07:35 (UTC)
netflex自己的作品不放他的链接要放谁? --Loving You Is A Losing Game 2022年7月10日 (日) 08:17 (UTC)
  • 楼上提出了一个好问题。从情感上我认为适当提供Steam链接是方便且合理的,里面常提供详实的介绍、用户评价,以及方便的购买,但宣传平台的问题确实存在。观察存废讨论和现有指引,我发现之前的讨论可能有瑕疵:
  1. WP:ELYES第二项,有关“其它媒体”的条目,“应该链接到有放置该作品文件的网站”。
  2. WP:ELNO虽然要求避免“主要为贩卖物品或服务的网页”,但其例外的“官方网站”(网址、链接)包括“链接的内容由条目叙述的主题(组织或人物)所控制。”,而Steam页面的“主要内容”(游戏介绍)理所当然由作者(或授权代理)控制,并符合“主要是关于条目主题”。
    1. 该指引注明的粉丝网站、慈善网站,是其他人管理运营再转嫁收益的网页,非作者主导。
    2. 如果将内容框外的其他内容也计入内容,假如作品官网采用某些托管站,作者无法充分控制内容。
  3. 将链接数目减至最少,允许多个官方链接。滥加难以避免,即便删模板、立指引。提议允许“官方主页”不够优良时链接Steam页面以提供充分的介绍,或者允许链接足够热度的Steam页面。
  4. 对于“官方链接”例外,不知道是否有体验很差的官方主页作例,包括难以阅读/加载、广告多、链接难找等。
  5. 题外话:对于“电子游戏官方主页(由开发商或发行商提供)”,或许不完全符合WP:ELOFFICIAL的“内容由条目叙述的主题(组织或人物)所控制”,因为代理发行商可能脱离作者改变主页乃至游戏内容。如《我的世界》外链了网易的我的世界中国版,是否可作前者的“官方主页”,或是该算作授权代理商的衍生游戏的主页?
  6. 如果有模板通过一行/区块、多个参数、多个图标/链接展示多个游戏平台上的官方页面,减少行数占用,会更好吗,宣传性会提升还是降低。平台排序可能成争议,但可按字典序。感觉,可能被滥用。如果读Wikidata,可能会不错。--YFdyh000留言) 2022年7月10日 (日) 08:45 (UTC)
    规则的制定有时代背景,同时也会有一定局限性。在上个世纪和本世纪初,游戏制作是一件专门专业的内容,也要较大的投入。当时没有成规模的游戏社区,Steam这一类游戏平台方兴未艾,上网还靠黄页。制作官网算是聚拢人气和粉丝的方法。
    在当代随着成规模的游戏社区和游戏平台的完善,相当一部分的制作人已经放弃自建官网,而是使用成熟的社交平台制作官网,或者直接使用游戏平台内置的功能就算了。更重要的是游戏制作门槛变低,有很多独立游戏。我就遇过很多游戏利用Itch.io可以定制网页的功能,直接当作游戏的官网。考虑时代变化,支持这部分的修订。
    第六项是在说{{Authority control}}吧。--Nostalgiacn留言) 2022年7月10日 (日) 10:58 (UTC)
    对,差不多。以及类似的{{Commons category}}、{{External media}}。或许主要在于是商业性、直接营利的网站,很可能有违WP:SOAP,不然当作电子游戏领域的规范控制来源网站,可能很不错,并且可以标注该版适用于哪些电脑平台,乃至支持的特色(如成就、云存档、线上对战等)。--YFdyh000留言) 2022年7月11日 (一) 13:16 (UTC)
    有些游戏除了在线商店外,同时通过Amazon或者Gamestop实体贩售;而且在线商店内部Steam vs. Epic也有竞争关系。当然没有官网的游戏估计也不会推出实体版。而且中文维基是个小站,商业公司估计也不会到这找麻烦。但就是怕有什么商业方面的潜在问题。权威控制我是认为vndb等游戏数据库比较中立。--洛普利宁 2022年7月11日 (一) 15:00 (UTC)
详实的介绍如果对编写条目有帮助,应该以通过参考引用到条目正文(而且Steam上的游戏介绍百科性很差);用户评价不是收录内容,不应该以这个目的提供链接。维基百科不是为玩家服务的,读者可能根本不打算玩游戏。想买游戏的玩家Google也可以搜索到Steam。所以抛开“方便的购买”的理由不谈,为什么一定要加Steam链接?
如果链接满足WP:ELNO则不适用WP:ELYES(……在不违反#链接上的限制#正常情况下应避免的链接的情况下……)。WP:ELNO#4指出“主要为贩卖物品或服务的网页”,就说明这类网页优先度不高。WP:ELMIN不反对链接多个页面,但前提“各链接提供不同的内容”。而官方网站一般都有Steam链接,就更没理由重复放商店链接了。
另外英文版指引“Inappropriate external links”下面有这样一条:“Links to storefronts, per WP:ELNO #5 (Steam, Xbox Store, PlayStation Store, Google Play, GOG.com, etc.)”。(英维相关讨论)供本地讨论参考。--洛普利宁 2022年7月10日 (日) 10:20 (UTC)

如同存废讨论的意见,我赞同这笔修订。稍有疑虑的就是,同时在多个在线商店在线商店销售(SteamEpicGOG.com等),但又没有官网的该如何处理。--洛普利宁 2022年7月10日 (日) 11:24 (UTC)

另外没有官网时,理论上可以用游戏数据库替代。比如巴哈ACG资料库也有丰富的资料,也提供游戏商店的链接。但是巴哈会把跨平台游戏分成好几个页面,也是一堆链接。对于华语游戏,英文圈的{{MobyGames}}又不靠谱。所以有没有什么好点数据库?(不过要说商店链接,Wikidata倒是也有……)--洛普利宁 2022年7月10日 (日) 10:56 (UTC)
同Lopullinen。只宣传单一平台不太好,但都宣传可能没有空间?---Temp3600留言) 2022年7月10日 (日) 15:01 (UTC)
没有要宣传,只是作为官方网站展示,择其一即可。--百战天虫留言) 2022年7月11日 (一) 05:16 (UTC)
如果没有官网,我倾向选销量高的那个,以及官方且免费的(如果有)。有官网,就不太确定。--YFdyh000留言) 2022年7月11日 (一) 09:58 (UTC)
当年(?),《9-nine-》被Sekai Project代理出中文版的时候,他们把游戏界面的主页按钮从游戏的日文版官网改成了Steam商店的页面。虽然观感不好,但确实是中文页面。不知你作何想法?--MilkyDefer 2022年7月11日 (一) 14:29 (UTC)
我不确定“观感不好”的意思。将系列页面视作“官方链接”,有什么利弊。官网加载有点慢,且我怀疑无障碍性不好,我也很难从中找到游戏总体介绍、购买链接等。--YFdyh000留言) 2022年7月11日 (一) 14:46 (UTC)
这游戏貌似不止PC一个平台……而且觉得维基百科的总体介绍不好,Google不才是最好的选择吗,为什么老是只想着官方网站……--洛普利宁 2022年7月11日 (一) 15:38 (UTC)
@YFdyh000:我从来没有说过这游戏的日文版官网就是你贴出来的那个网址哟?看样子我要给你举个例子了:在第一章中,Sekai Project把游戏中的这个官网链接,改成了这个Steam商店链接,二三四章类推。你贴的那个网址是四章之后开发商一波全年龄化搞出来的网站。我的意思是说,条目列出官网,但是官网不是中文。有人说,明明有(代理商认证的)本地化官网为什么要为难我,结果所谓的本地化的官网是Steam商店页面,你打算怎么办?--MilkyDefer 2022年7月12日 (二) 09:41 (UTC)
不太明白,但只要是官方发布的可读性好的主页链接,我不介意都列,Steam也一样。不过“将链接数目减至最少”可能就不容易做到。以及网站的子页面是否能列,理论上不该,但指引毕竟是指引,如果利大于弊……如果没有官方主页,官方Steam页面又没多少有效内容,这种我反而觉得要斟酌一下,引流将大于介绍作用。--YFdyh000留言) 2022年7月12日 (二) 16:10 (UTC)
当然我们没有其他的意思,但这会不会被商业公司过度解读?比如跨平台游戏只放//一家的商店链接,或者电脑游戏只放Steam/Epic之一的链接:这样结果被其他公司指摘不够中立?因为WP:VGBOX有“如果游戏在多平台上的封面类似,应对封面图像进行编辑,使用不含任何平台标识的封面以表中立”这样一条,所以我想到了这点。--洛普利宁 2022年7月11日 (一) 15:17 (UTC)
(-)反对,都已经2022年了,有兴趣的人自己搜索一下什么都有,维基百科不是网址导航,无须给用户提供指路服务。->>Vocal&Guitar->>留言 2022年7月11日 (一) 11:26 (UTC)
哪里是指路啊,只不过是在没有官方网站的情况下展示平台网站而已。--百战天虫留言) 2022年7月11日 (一) 11:47 (UTC)
所以为什么要展示?。->>Vocal&Guitar->>留言 2022年7月13日 (三) 01:35 (UTC)
上方U:YFdyh000的论点中,一个重要的谬误是Steam页面的主要内容由作者提供,但最终由Steam控制,而显然Steam(及其他同类)是标准的“主要为贩卖物品或服务的网页”。因此,Steam链接不论如何都不应出现在条目中。同理,其他类似性质的网站,例如kindle电子书、apple music、爱奇艺等等, 也不应将非官方原创内容放入。->>Vocal&Guitar->>留言 2022年7月13日 (三) 01:35 (UTC)
我对此存有疑议。以itch.io作官方主页的游戏,其页面是否也为“itch.io”所控制而不属于官方链接,且该网站也提供销售功能。就爱奇艺而言,如果是独家非自制(网)剧,或许能“不建议”加,但对完全不能加我表示存疑。--YFdyh000留言) 2022年7月13日 (三) 02:01 (UTC)
从他们的term看不出这个站与steam有什么本质区别,所有内容都在他们的网站上,他们可以完整控制。->>Vocal&Guitar->>留言 2022年7月13日 (三) 02:26 (UTC)
en:WP:ELOFFICIAL "An official link is a link to a website or other Internet service that meets both of the following criteria",我不认为内容托管乃至在线销售服务就不能是官方链接。即便所有人自建网站,云服务商、执法或黑客事件等亦可能在少数情况下完全控制内容,不需要为此过度担心,且担心也没用。另外,人物的博客、微博是官方链接吗,演艺团体的官方微博又是或不是,以及官网网站的互联网文件馆版本又如何。我不解您追求的“控制”需何种程度,有多少价值,以及作者“完全控制”的网站真的最适合读者吗。--YFdyh000留言) 2022年7月13日 (三) 03:13 (UTC)
因为您提到的WP:ELOFFICIAL明确指出需要由该组织或人物所控制,您以这条来豁免ELNO#4,我认为不合适。扩展开来看,除官网之外的其他SNS平台,作为外部链接也应该谨慎。一个有意义的例子是特朗普的推特,他的发文被疯狂打标签,然后直到封号,那么到底是他在控制还是推特在控制?当然从读者的角度,适合他们的不是官网,也不是steam,是3dm这种从盗版到补丁到修改器到攻略一条龙的网站。
讲点不切实际的,在如今,想找某某人某某物在某平台的账号应该是十分简单的事,维基百科真的有必要把这些一五一十都列进来吗?我们要搞清楚这些链接真的帮助了这篇条目更加完善,或者只是让中立性多一分隐患。--。->>Vocal&Guitar->>留言 2022年7月13日 (三) 05:08 (UTC)
itch-io还在Epic商店上架。另外Steam和Epic是商业竞争关系,就像官方在天猫京东都开官方店。官方自己操控的网站,他放一个商店或几个商店的连接,那是他自己的事情。维基百科只放一个商店,说好一点是编者无意只知其一,说极端一点就成了“维基百科给XX电商公司导流”;全部放上去那就真成导购网站了。
当然对于一些品质很差、没有参考资料的新条目,我承认不放Steam外链,都不知道条目在说哪款游戏。(不过这个外链更适合用作参考)在线商店一般就是作品基本介绍,并摘选一些媒体的溢美之辞;这些内容都是维基百科的玩法和评价章节涵盖的。如果出于让读者“理解基础信息”而加入在线销售商店,那只能说是条目的失败。而且如Vocal&Guitar所言,“有兴趣的人自己搜索一下什么都有”。对比WP:ELMIN的“only one”和“does not provide a comprehensive web directory to every official website”,我认重点还是在“only one”。(更何况有编辑还认为在线商店不算官方网站)--洛普利宁 2022年7月13日 (三) 05:45 (UTC) [修改于2022年7月13日 (三) 06:49 (UTC)]
1980年的游戏没任何主页怎么办?--百無一用是書生 () 2022年7月13日 (三) 02:23 (UTC)
没有就不要加。->>Vocal&Guitar->>留言 2022年7月13日 (三) 02:26 (UTC)
外部链接不仅仅是主页啊--百無一用是書生 () 2022年7月13日 (三) 03:49 (UTC)
如果没有Steam一类的店面的话,可以加入到游戏数据库的链接,如IGBD莫比游戏。可以先去wikidata上找标识符。--BlackShadowG Slava Ukraini! 2022年7月13日 (三) 09:41 (UTC)

上面讨论比较乱,重新整理一下:

  1. 关于官方链接的定义。依照WP:VG/EL,官方主页限于“开发商或发行商提供”的;Steam商店网站store.steampowered.com由销售商Valve提供,因此不算官方网站。各位怎么看?
  2. 承上,如果Steam商店链接不算“官方网站”主页,但倾向有条件视其为“合适的外部链接”。那在没有“官方网站”时,Steam链接是按官方网站处理(放在首位且使用{{Official website}}),还是享受官网待遇,放在首位但只能写成[https://store.steampowered.com/app/123456 Steam商店]
  3. 如果倾向算作“不合适的外部链接”,但“不适合”也不是禁止。那有没有什么例外情况,Steam商店可以作为一般外链甚至第一外链加入?
  4. 在多个商店销售的游戏如何处理?比如电脑游戏在Steam、Epic等多家商店销售:对开发商来说,随机选哪个链接都一样;但对Steam、Epic等商业网站而言,这就是天壤之别。中国大陆手游也有类似问题:登陆多个应用商店(包括或不包括Google Play)。

以上。--洛普利宁 2022年7月13日 (三) 08:05 (UTC)

个人认为讨论的观点有点幸存者偏差。事实上,独立游戏开发者囊中羞涩游戏发布的平台当作官网来用是很常见的,因为他们没有发行商,就是在发行平台上自主发行作品。只是他们大部分作品往往不符合维基百科的收录要求,符合关注度的作品本来大多就有发行商负责宣发,也有余力架设官网。独立游戏很少多平台发行,因为平台上架费其实对也算小贵的。
中国大陆的开发者由于游戏版号问题,无法对游戏进行商业操作,回笼资金,只能透过境外发行作品,算是转空子。而境外拥有大量中文玩家的游戏平台目前就只有Steam一家。中国大陆特殊的游戏开发环境造成独立游戏集中以Steam为发行平台,也以Steam为官网这种特别的景象,也许是只此一家。
日本的独立游戏开发者也有类似的情况,如DLsite的同人开发者只在DLsite发行,还有直接用DLsite内置的博客ci-en作为开发日志发布地。
上文提到的网络指路问题,搜索系统并没有想像中的智能。特别是中国大陆社交平台局域网化,搜索系统不如想像中中用。
此外发行平台(商店)也可以下场做发行商,他们也会物色作品去承包发行。上文提到的itch.io作为发行平台,也会在Epic商店以发行商身份出现的情况,此外DLsite也在Steam商店以发行商身份发布作品。
题外话,如果发行平台有为作品“特设网页”,是否可以视作可以保留的外部链接,如《与奴隶的生活 -Teaching Feeling-》现在的情况。--Nostalgiacn留言) 2022年7月14日 (四) 16:29 (UTC)
所以你们的讨论是没有共识吗?--百战天虫留言) 2022年7月22日 (五) 07:27 (UTC)
(+)支持(!)意见:个人建议条文修订为“对于没有独立官方主页的电子游戏,可采用Steam等数字发行平台的页面作为具官方性质之介绍主页,否则不可加入。”大致综观以上站友讨论,敝人对相关主题不甚熟稔,在有效介绍条目主题、提供读者实用信息、丰富条目内容、适度结合外部资源、增进用户体验、吸引用户加入、推广维基百科平台,且相关规范需配合现实环境与时俱进等考量下,个人对上方站友汇整提问之意见如下:
  • 对于官方平台之核心特质,个人认为关键在于条目主题本身对其有效控制之力度、该平台或页面与条目主体之关系亲疏远近,以及其实质上平台或页面对于条目主体具备之“专属性”程度。若以上方提案内容而言,数位发行平台似属“官方页面”(作品既无开发商亦无发行商所设的专属官方网站);然而此类数位发行或下载平台其界面、功能以及同时存在诸多其他同类商品之宣传推广和强烈商业性,一眼看去并非条目主体之作品所专属,个人认为以平台使用界面和页面实质用途而言,对于一般读者的常识和主观认知是否能称为“官方”(比如:放眼望去处处可见其他作品,亦见其他知名大作同样上架于此等),争议颇大。
  • 承上,因此个人认为不适合使用官方网站模板,而依此案欲改善之问题且于使用上明确设限后,加入数位发行平台属合适链接,可享实质官网待遇,但限以介绍主页(随机以《数码宝贝 绝境求生》为例,收录形式类似Steam《数码宝贝 绝境求生》介绍主页)),或是仅提及平台名称之形式收录(如有站友提及的与奴隶的生活 -Teaching Feeling- DLsite(日语))。
  • 若遇复数平台发行者,仅可拣择页面内容最完整且具代表性者列出;若链接页面之内容相仿、雷同甚至相同,则拣取最具代表性之平台收录(简单说选择对条目主题的作品发行而言最大、最红、卖最好、销量最高的平台)。
以上为个人意见,供参。--Kriz Ju留言) 2022年7月31日 (日) 19:44 (UTC)
  • 非专属平台的链接不适用{{官方网站}}模板,我基本赞成。值得同时探究与参考维基数据、英文维基等讨论和实践。
  • 段落二的举例大致赞成,唯“介绍主页”用词需讨论。第二种似乎较好,但格式(-/,/,/其他)可能尚难统一。
  • 段落三的意见,我个人赞成,但很可能仍存争议,平台代表性、友好度、关系亲疏、宣传性等平衡均可能产生争议。比如游戏在Steam卖的最好、在公司/母公司的网站上有介绍但页面非游戏制作/宣发团队管理、在母公司经营的平台上有销售但销量很低,究竟哪个页面最“具代表性”和官方,又是否随各页面的更新频次、质量而有取舍。
  • WP:ELOFFICIAL之“官方链接”的控制程度争议,我认为仍模糊、共识不足。在某些方面,有时难以辨别官网内容的制作和维护者,可能为自行维护更新,可能为上级或其他宣传部门维护更新或编排内容,还可能交由第三方公司搭建和直接维护(技术支持),条目主体的“控制能力”是否绝对影响页面作为产品/机构的“官方链接”(门面)的身份。

现行条文

合适的外部链接-如果存在这些链接,应当在电子游戏条目中列出

  • 电子游戏官方主页(由开发商或发行商提供)。游戏如在中文区发售应优先列出中文版主页。如果是外文游戏,还应列出首发国家的语言版本并注明网站是外语。如果开发商和发行商提供的网站不同则应一并列出。

...

提议条文

合适的外部链接-如果存在这些链接,应当在电子游戏条目中列出

  • 电子游戏官方主页(由开发商或发行商提供)。游戏如在中文区发售应优先列出中文版主页。如果是外文游戏,还应列出首发国家的语言版本并注明网站是外语。如果开发商和发行商提供的网站不同则应一并列出。对于没有独立官方主页的电子游戏,可采用Steam等数字发行平台的页面作为具官方性质之介绍主页,否则不可加入

...

暂时采用Kriz Ju的方案,欢迎继续讨论。--百战天虫留言) 2022年8月9日 (二) 05:24 (UTC)
  公示7日。--百战天虫留言) 2022年8月14日 (日) 04:33 (UTC)
(-)反对WP:ELNO#4。->>Vocal&Guitar->>留言 2022年8月15日 (一) 03:14 (UTC)
  • 那么继续讨论。基于反对理由做一些设想,假设抛开电子游戏领域,如果某项有关注度的产品的厂商不设官方网站/介绍页面,但在网购平台设立有官方店铺和产品,提供产品销售页面作外部链接,可能的确有诸多问题:平台广告,产品介绍通常过度行销,销量和评价可能含虚假成分,平台有个性化用户跟踪等不当行为,条目构成引流。
    • 但放在特定的如电子游戏、音乐、影视等领域,很多厂商/出版商不会单独设立官网,而以某些代理发行平台为基础或独家销售,使用有一定公信力的销售兼资讯平台,不一定不可接受。但平台的选取是否得出共识,尚不确定。
  • 怎样的官方网站/链接能得以豁免和值得加入,我认为缺乏明确标准与共识,“主要为贩卖物品或服务的网页”如何判别(条文特地注明是网页而非网站),也稍有模糊。如厂商介绍特定手机型号规格与特色,顺带提供自有/外部销售链接或功能的页面。如购买页面是官方但主要贩卖销售故不合适(但它是“官方”控制,所以难道可“豁免”),规格参数以数据为主不确定是否合适(更适合作参考资料),兼具官方、介绍营销和销售的主页面是否官方和合适作型号条目的外部链接呢。
    • WP:ELNO#4条文中举例“手机条目里就不该有外部链接是连到贩卖、推销手机产品或服务的网页。”,但此处的“手机”是狭义,参考英文维基的条文(在第五项)“the mobile phone article”。--YFdyh000留言) 2022年8月15日 (一) 04:03 (UTC)
    对我来说,任何形式的引流都不可接受,鉴于本题的主旨是绕过EL损及中立性,我没有兴趣继续讨论,我也不会修改我的意见。->>Vocal&Guitar->>留言 2022年8月15日 (一) 09:41 (UTC)
    没事,目前回归讨论阶段,我亦欢迎其他人介入这段讨论。如果观点是任何引流皆不可接受,我感觉牵扯中的太多模板。社群对“官方性质网页”、“引流宣传问题与实用性”这两方面,可能欠缺共识。--YFdyh000留言) 2022年8月15日 (一) 10:17 (UTC)

修正快速删除方针

已通过:
已通过,将依公示版本条文进行修订。--Kriz Ju留言) 2022年8月16日 (二) 18:25 (UTC)
下列讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

R7快速删除准则自从2019年设立以来,屡次遭到滥用或扩大解读,已然背离重定向制度本身之精神、损及百科全书体系之运作。故在此提议修正快速删除方针如下:

现行条文

(略)

R7. 明显与导向目标所涵盖的主题无关或比导向目标所涵盖的主题更广泛重定向

(略)

提议条文

(略)

R7. 明显与导向目标所涵盖的主题无关的重定向

(略)

此提案仅影响一般无需讨论之快速删除操作,若欲提删者有扎实之提删理据,仍然可以按正常程序提交各种存废讨论,不受任何阻碍。—— Eric Liu 創造は生命(留言留名学生会 2022年7月11日 (一) 09:17 (UTC)

R7修订公示版本

现有的条文仍然相当含糊(参考w:WP:NEWCSD,快速删除条文应该详细到一般用户能明确判断一个页面是否符合快速删除标准)。建议改成如此(我其实2019年就提出了):

现行条文

R7. 明显与导向目标所涵盖的主题无关或比导向目标所涵盖的主题更广泛的重定向

提议条文

R7. 明显与导向目标所涵盖的主题无关或比导向目标所涵盖的主题更广泛的重定向

  • 条目完全未提及重定向的名称,或重定向名称比条目主题更广泛[1],但条目不含有重定向名称的有效介绍。同时,重定向名称并不是条目的别名或错误拼写。有争议的情况下,应提出存废讨论
  • 如果原重定向标题可改成消歧义页(或重定向至其他消歧义页),则不适用。
  • 挂有{{关注度重定向}}或{{合并重定向}}模板的页面亦不适用,请改为提出存废讨论
  • 如有用户对标题用字存在未解决的争议,则应交由存废讨论处理。

例如: (以下扩充中)

R7适用和不适用情况举例
重定向页 重定向目标 重定向目标是否提到重定向页名称 是否符合(修订后的)R7
1669 1000
1025 1000
梁新武 第16届桃园县议员列表
广台高速公路 广明高速公路 有提及但无有效介绍
杭长高速公路 杭新景高速公路2019年版本 有有效介绍
金三胖 金正恩 - 因为重定向页是重定向目标的别名,无论是否提及都不符合R7
28机步 乔尔诺莫尔西克 (敖德萨州)
王贯一 王贯一 (飞行员) - 否,可改成消歧义
赖瑞 拉里 (猫) - 否,可改成消歧义
陈彦廷 (台湾) 陈彦廷 (1982年) - 否,可重定向至陈彦廷
Bh (字母) Bh (二合字母) - 否,因为重定向页并无歧义,所以属于“是条目的别名”的情况
洗脑:思想控制的科学 洗脑心理学 - 否,英文标题的直译属于“是条目的别名”的情况
强制拆迁 中国强制拆迁 无有效介绍 是,但是原标题可以改成set index
民国时期货币 中华民国货币 (1912年-1949年) - 否,是条目的别名
2016年中国矿难列表 2016年中国大陆矿难列表 - 见下
白羊座流星雨 白天白羊座流星雨 - 否,可改成消歧义
芬兰冰人 奇米·雷克南 - 否,如无歧义:是条目的别名,如有歧义:可改成消歧义
诺里斯 兰多·诺里斯 - 否,可改成消歧义

--GZWDer留言) 2022年7月11日 (一) 16:45 (UTC)

(+)支持总体概念,GZWDer版更为清晰,(+)倾向支持该版本。--西 2022年7月12日 (二) 03:22 (UTC)
行。总之能避免滥用规则就好。—— Eric Liu 創造は生命(留言留名学生会 2022年7月12日 (二) 14:54 (UTC)
(+)支持(!)意见:以此列表而言,敝人表达个人意见:
  • 关于“金三胖”:目前未重定向至传主条目,亦未见于当前导向之条目“中国大陆网络热点事件列表”中存在相关内容(故目前实用性不明,抑或曾经人为移动编辑之类(笑))。个人揣想若回归站友提案修订之初衷以及一般“生者传记”的重定向论之,假设该重定向已导向至传主“金正恩”之条目,敝人倾向于:
  • “重定向目标是否提到重定向页名称”一栏认定为:“是,有提及但无有效介绍”,而“是否符合(修订后的)R7”一栏为:“否,对于具攻击或嘲讽性等负面或争议内容之生者传记重定向,由于事涉传主人身名誉保护法益和相关法律风险(含编者自身可能遭遇之法律或诉讼风险),故涉及在世传主人身形象评价之重定向于使用上,建议编者应确保该重定向同时符合可供查证、于公领域广为使用、具大量可靠来源证其具备并非短期之显明关注度,且其生成或存续之因果于公共领域具社会影响力为宜。”。
暂时没意见。Sanmosa Királyunk s a közhazát 2022年7月16日 (六) 15:53 (UTC)
所以,2016年中国矿难列表应该是不符合吧?--街燈電箱150號 开箱维修 抄表 检验证明 2022年7月17日 (日) 10:18 (UTC)
不符合。--Kriz Ju留言) 2022年7月17日 (日) 23:41 (UTC)

提案已14日且无反对意见,帮推一下,  公示7日,2022年8月1日 (一) 01:35 (UTC) 结束。--西 2022年7月25日 (一) 01:35 (UTC)

能否说明你要公示GZWDer版本还是Eric Liu 版本。--Ghren🐦🕕 2022年7月25日 (一) 10:28 (UTC)
帮ping@LuciferianThomas--🚊铁路Railway 2022年7月28日 (四) 00:30 (UTC)
有副标题#R7修订公示版本啊,而且公告栏的链接也是直指副标题。--西 2022年7月28日 (四) 03:49 (UTC)
我又不会从T:B直接点下去看。我认为现在的方案过于繁杂了,要合“新导向名称比条目主题更广泛”一项,则要排除“条目不含有重定向名称的有效介绍”、“重定向名称并不是条目的别名或错误拼写”、“重定向标题可改成消歧义页”三项,以这繁琐条件,基本上和废掉没有分别。还有什么“如果原重定向标题可改成消歧义页(或重定向至其他消歧义页),则不应删除。”,这里的意思应该是不合此款而不是“不应删除”吧。--Ghren🐦🕒 2022年7月29日 (五) 07:15 (UTC)
已代为对草案进行微调。—— Eric Liu 創造は生命(留言留名学生会 2022年8月8日 (一) 02:14 (UTC)
(!)意见:综观两案,若以快速删除方针主要用途为“加快处理显然不合适的页面或文件的情形,如果有争议的不应该适用。”之核心功能和意旨而言,上方提案精简有力,敝人亦无甚意见。就个人粗浅认知,综观站友所提两案之实际效果和用途皆为规限适用条件,而关键差异在于是否容许如“条目完全未提及重定向的名称”即可适用快速删除、“是否属于条目的别名”、“是否可改成消歧义页”等实务情境之明列,或可视实务需求考虑将下方提案之“例外排除情形的说明内文”适当纳入结合(当中条文的字面可考虑异动为“如果原重定向标题可改成消歧义页(或重定向至其他消歧义页),则不适用。”。若相关修订可增益于条文实务应用、减少误用和滥用、降低不必要的判断和无谓争议甚至维运成本,或皆有益处。--Kriz Ju留言) 2022年7月31日 (日) 22:25 (UTC)

参考资料

  1. ^ 不包括列表项目重定向到列表。

本讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

提议设立容许查看私密信息的用户组/flag

续上#提议修改维基百科:防滥用过滤器的讨论,建议将查看私密过滤器信息的权限连同新IPInfo检视权限分拆为另一用户组/flag,及后若推行IP masking此用户组亦可不需另加讨论容许此具有此flag的用户检视原始IP。原先仅将私密过滤器的查看权限分拆过于鸡肋,上方的讨论也似乎不会有共识;忽然想起还有IPInfo和未来IP masking的信息现在尚未可授予其他用户,故想到将这些权限一并置入新设用户flag。固然,这也代表回退员将被移除查看私密信息的权限,这个权限的申请要求将更加严谨。设置此用户组可在不需要额外调整既有的回退员申请标准之下同时达到改善私密信息的保密性。提请社群讨论是否设立此用户组、申请资格(个人倾向此部分以站务经验作为标准,再辅以简单的信任投票)以及用户组的名字。--西 2022年7月16日 (六) 15:17 (UTC)

通知参与上方讨论的用户。Sanmosa、​Temp3600、​Cwek、​Nishino_Asuka、​YFdyh000、​Antigng、​桐生ここ、​Tigerzeng、​KirkLU、​Ericliu1912、​脳内补完、​魔琴ZhaoFJx--西 2022年7月16日 (六) 15:22 (UTC)
感觉是值得考虑的方案,但是我简单想了一下发现实操会比较困难。既然是以查看隐私为主要目的的用户组,那么能否信任基本上是最最重要的考虑。在这个前提下考虑申请流程,我能想到的只会是类似于申请管理员的那种。社群又是否期待再多一个这样相对繁复的流程呢?--Tiger留言) 2022年7月16日 (六) 15:36 (UTC)
(+)支持 这样可以做到又防内鬼又能了解作用。不过不是特别建议合并,感觉有些冗余……?话说回来,倘若两者合并为同一权限组,可以在WP:EFH的基础上进行修改,不如叫“反破坏助理”() ——诚挚的 ZhaoFJx 2022年7月16日 (六) 15:43 (UTC)
当查看IP Masking权限之要求,基金会会如何设置仍是未知之数时,此案基本上无从说起。--J.Wong 2022年7月16日 (六) 16:17 (UTC)
T309318被回复之前,本提案无法推进,请等待。 Stang 2022年7月16日 (六) 17:17 (UTC)
(+)支持,很合理--脳補。◕‿◕。讨论 2022年7月21日 (四) 08:08 (UTC)
总感觉lta-wiki(或站务维基)也可能可以参考本案。 ——魔琴 [ 留言 贡献 ] 2022年8月1日 (一) 06:40 (UTC)
值得考虑,但需等待IP Masking权限之全景和颁授范围。--YFdyh000留言) 2022年8月4日 (四) 06:37 (UTC)
(-)反对在目前有些地区有不明朗的氛围和环境下,中维不适合设立任何容许查看私密信息的用户组。--Wpcpey留言) 2022年8月14日 (日) 15:24 (UTC)
(!)意见:若站友所论之基金会政策等相关前提条件许可,个人发想之后或可将此案结合上方“提议修改维基百科:防滥用过滤器”做适当规划。供参。--Kriz Ju留言) 2022年8月15日 (一) 19:06 (UTC)

配置表单来方便用户发邮件申请账户或申请IPBE权限

目前一个用户如果在自己的IP被封禁的情况下希望注册账户,或是第一次申请IPBE权限,其需依照本指引中的要求需要发送邮件至unblock-zh lists.wikimedia.org来申请。目前可以想象的已知问题包括:申请人遗漏了部分信息、申请人发的邮件未遵照模板难以阅读、管管无法验证用户对应的IP地址是否真的被封禁了。为解决这些问题,在此提议在本站安装ContactPage这一扩展,并书写对应的配置文件来定义表单。

这一扩展可以根据配置文件生成表单,其中包括若干必填或选填项,且注册用户和匿名用户均可使用。当提交表单时,扩展会将表单中填写的信息(甚至可以附带上填写人当时的IP地址)以一定的格式发送给某个用户(在本站就可以发给User:Unblock-zh)。比较不好的地方是表单的栏目需要手写配置文件(参考元维基的配置),但也算是一劳永逸。样例可以看这个位于元维基的表单。本扩展已于元维基、Governance Wiki和荷兰语维基百科安装,因此个人认为安装应该不成问题。希望获得社群共识。 -- Stang 2022年7月16日 (六) 17:15 (UTC)

没有意见。未见说明,但该表单似乎不受IPBE影响。关于填入IP地址,建议为可选而非隐含,以利隐私选择权。--YFdyh000留言) 2022年7月16日 (六) 18:25 (UTC)
那啥,两个问题:
  1. IP被封禁能提交得了这个表单么?
  2. 这个扩展有啥防滥用机制么?会不会被利用来大量发送spam?--百無一用是書生 () 2022年7月18日 (一) 02:22 (UTC)
这个扩展本质是Special:EmailUser套皮。如果用户被禁止发送邮件,那么他们就用不了这个页面;页面的使用也受到邮件相关的速率控制。--MilkyDefer 2022年7月18日 (一) 14:29 (UTC)
尴尬,如果被封了是不能发邮件的;有一个可选的captcha。鉴于本提案无法实现,撤回。 Stang 2022年7月18日 (一) 14:55 (UTC)
@Stang:奇怪的是,我在meta上用被封禁的IP(编辑页面,提示已封禁),可以用这个表单啊。之前尝试好像没见到验证码,这次尝试见到验证码。"Your account or IP address has been blocked."、"Email sent"。--YFdyh000留言) 2022年7月19日 (二) 03:48 (UTC)
我强调一遍,是被撤除了邮件权力的人不能用。Stang作为前行政员在封人的时候不可能没见过“不能发送电子邮件”的选项吧?除非封锁一个IP用户,会导致受其影响的无账号人员不能发出请求代为创建账号的表单。--MilkyDefer 2022年7月19日 (二) 06:44 (UTC)
很奇怪的是我昨天用了某个不能编辑页面的IP在匿名情况下发现是无法使用这一功能的,但是刚刚我尝试复现的时候似乎又没法重新复现…?话说回来,这个扩展是用$user->isBlockedFromEmailuser()来判断的,那如果封一个匿名用户会干掉sendemail这个权限么,如果没有的话那还有继续讨论的余地。 Stang 2022年7月19日 (二) 11:28 (UTC)
MilkyDefer已经完整说明了,我很意外前管理员怎么会不熟悉封禁的相关设置。--Xiplus#Talk 2022年7月22日 (五) 06:12 (UTC)
界面可以参考mw:Help:Blocking users/zh的附图。--Xiplus#Talk 2022年7月22日 (五) 12:36 (UTC)
从未对匿名用户执行过禁止发送电子邮件的设置,因此完全不了解这一点。 Stang 2022年7月24日 (日) 13:06 (UTC)
似乎没有明确的反对意见,故公示7天。 Stang 2022年7月31日 (日) 17:46 (UTC)
表单的字段是通过后再讨论吗?--Xiplus#Talk 2022年8月1日 (一) 01:00 (UTC)
可以同时或者之后讨论,我认为把要不要做和怎么做分开是合理的。 Stang 2022年8月1日 (一) 08:11 (UTC)
公示完之后要做什么?—— Eric Liu 創造は生命(留言留名学生会 2022年8月10日 (三) 08:00 (UTC)

电视剧演员与角色排序指引

简介 电视剧的演员排序无任何指引规范
问题背景 在编辑《基督山小姐》时,因为Wikipedia:格式手册/电视Template:电视节目信息框并未规范或明述演员排序如何罗列而引发编辑战。《基督山小姐》的片尾演职员与海报排序均为:“李昭娟、崔汝珍、鲜于龙女、李晃仪、⋯⋯、金美罗、景盛焕、李尚宝、李多海、⋯⋯”,但官网首页的출연(出演)标示“李昭娟、崔汝珍、景盛焕、李尚宝 等”,등장인물(登场人物)也是将四名演员所演的角色列在前四位,产生冲突。
我的观点
  1. 个人倾向参考MOS:TVCAST,应以影片本身的排序为首准,如片尾完整的演职员表等,而不是非影片本身及可能无法取得完整排序的官网。以《伊甸园之东》为例,李多海在片尾演职员表或是海报中,均被列在第三位,官网改版后,中途辞演的李多海在人物介绍中被移至第八位,不符合首播时的排序。
  2. 为避免造成解读差异,排序不得任意略过。
  3. 本人以所涉略之美、加、英、澳、台、日、韩、港等电视剧作为案例考量,若有疏漏其他案例可提出。
  4. Wikipedia:格式手册/电视制定指引后,同步于Template:电视节目信息框/doc的主演栏提及。
我的解决方案
现行条文

演员及角色资料 一般而言,电视剧条目之内,角色及演员资料会以角色表或演员表方式铺陈。角色表段落会包含“演员”、“角色”及“角色扼要介绍”;可参考天与地 (无线电视剧)。依据格式手册(文字格式),演员及角色不应用粗体或斜体标示。

另外,除非有多个可靠来源佐证,否则请勿标记角色性质,例如第一男主角、第二男主角、第一女主角等。至于演员条目内,如有参演电视剧列表,亦作类似安排,如无多个可靠来源佐证,请勿罗列角色性质,应以“主演”或“配角”代替。

提议条文

演员及角色资料 一般而言,电视剧条目之内,角色及演员资料会以角色表或演员表方式铺陈。角色表段落会包含“演员”、“角色”及“角色扼要介绍”;可参考天与地 (无线电视剧)。依据格式手册(文字格式),演员及角色不应用粗体或斜体标示。

另外,除非有多个可靠来源佐证,否则请勿标记角色性质,例如第一男主角、第二男主角、第一女主角等。至于演员条目内,如有参演电视剧列表,亦作类似安排,如无多个可靠来源佐证,请勿罗列角色性质,应以“主演”或“配角”代替。

演员与角色讯息(含信息框中的主演栏)一般可以正式官方网站公开发布讯息收录,若编者因对于作品之可靠官方来源选择或判定不一,或因其他理由,导致对于演员排序认定歧异,则依序以下列来源为依据:

  1. 影片中完整的演职员表(如片尾演职员表或片中的跑马字幕),若影片是依出场顺序排序则不适用。
  2. 影片片头的演职员排序,若影片是依出场顺序排序则不适用。
  3. 官方海报的演员名单排序。
  4. 官方网站的演员或人物介绍排序。
  5. 其他官方发行产品上的演员名单(如相关刊物、影音产品包装等其他多媒体)。
案例:
  1. 植剧场-荼蘼》的片头与片尾排序不同,但以片尾完整的演职员排序为准。
  2. 追杀夏娃》的片尾是依出场顺序罗列,《想见你》的片尾仅列配角演员名单,此情况则依序参考上列排序,如前者以片中的演职员跑马字幕为准,后者则参照片头演职员排序。
  3. 由于日剧演职员排序多为“主演、共演1、共演2、其他1、其他2、共演3、共演4”,条目中可将共演往前排序为“主演、共演1、共演2、共演3、共演4、其他1、其他2”。

若影片有不同官方版本(如因场次、地域、再版、媒介等因素而产生不同版本),导致演员名单排序不一,以作品首播、首映、首发之原产地版本为准。而演员退出、辞演或角色身亡、删除等,因考量资料收录完整性,仍可保留在名单之中。

此前的类似讨论

--Sa Young Sun留言) 2022年7月16日 (六) 19:14 (UTC)

不是啊,你这样写还是没解决《基督山小姐》的问题啊,影片中完整的演职员表、海报、官网谁的优先度高不就是问题所在。 --窝法乙烷 儿法梦碎 2022年7月17日 (日) 02:32 (UTC)
制定指引就是解决问题啊,且还得适用于所有电视剧,目前优良条目、典范条目都符合此方案,“我的观点”已明述我的立场,有异议欢迎提出来讨论,比如疏漏且不适用的特例等。以往影视条目的争议发客栈都没人要回应,就连删除来源的编辑争议都没人管,已经是走投无路了。  囧rz……--Sa Young Sun留言) 2022年7月17日 (日) 05:13 (UTC)
  • (!)意见:敝人认为,若编者产生强烈分歧致无法达成共识,个人倾向于以一般读者可简易公开查阅、可直接添加参考资料来源之官方来源为准;若该作品不仅具备单一公开官方来源(亦即可能有复数官方来源,可能二、三个以上之类,如官网和海报,或同时有官网或官方粉丝团等)或公开的官方来源有所异动致产生歧异,甚而不具公开可靠之官方来源(亦即可能官方来源本身没公布完整名单,或是可能只能自己查找影片名单之类),以编者达成共识为准。个人第一时间偏好“正式的官方网站”,若真无选择或始终无法达成共识,只得直接翻看“影片片尾的完整演、职员名单”(个人认为片头名单常仅见该作的主要演、职员)。
敝人主观以为如何排序或可寻求证明,惟未见明确规范之必要,其中区别对于一般不甚理解主题之读者或初来乍到之编者无显著差异。若须订立相关规范,细节可由热心站友共商。
  • 无适当理由移除可靠来源为破坏行为,遇此情形请适当以反破坏警示模板升级警醒相关编者,警谏等级提升后若仍未见改善,请再行提报。
  • 面对条目编辑争议,若有编者持续无适当理由而拒绝沟通或提供来源和理据,仅以编辑战反复回退,显为不当态度或行为,请相关编者于确认对方拒绝沟通、表达自身意见或提供理据后径行提报。
以上为个人意见,供参。--Kriz Ju留言) 2022年7月17日 (日) 13:40 (UTC)
如果出现同一影片不同版本(场次、地域、再版、媒介)的演员表排序不同的情况呢?如果官方来源随时间变化了呢(如赵薇被除名)?--Benevolen留言) 2022年7月17日 (日) 16:59 (UTC)
(!)意见:敝人已于前段表达:若该作品不仅具备单一公开官方来源,或公开的官方来源有所异动致产生歧异,甚而不具公开可靠之官方来源,以编者达成共识为准。若同作影片内的名单仍各有版本、相互歧异、错综复杂,个人偏好作品首播、首映或原产地版本(若阅读简易,有需要或可再补充与其他版本之名单差异,这部分应可由编者发挥),但编者能相互达成共识更好。至于遭除名者,为资料完整性考量,个人认为收录较佳,附注说明该演员遭除名之原因和事由即可。--Kriz Ju留言) 2022年7月17日 (日) 23:31 (UTC)
(:)回应:若是以官方网站为首准,这会影响到英、美、加、澳、台等电视剧条目,英美等地的演员排序会有冠上with或and的情况(韩国用그리고、日本为尾番),代表该演员虽然被列在名单的尾端但举足轻重(如《美丽心计》的梅莉·史翠普),这与官网的排序可能有出入,即无法表现,虽然一般读者可能没察觉。且演员究竟是主演、配角、guest还是special guest,也是要透过影片的演职员表才能确认。
我认为影片本身较能代表制作方的信息(且完整),官网是由电视台建构,未必能正确、完整揭露,此前的类似讨论中也点出官网不适用于港剧的例子,加上我所提及的案例,显示官网不确定性相对高。或者,若以官网为准时,要用什么但书来避免有误的情况。毕竟有共识还能从宽,但有争议就得参考指引。
关于影片也可能有异动,MOS:TVCAST: "their place in the list should be based on the order of credits in the first episode that they appear",以“首次”为概念的话,我也倾向参照“作品首播、首映或原产地版”。--Sa Young Sun留言) 2022年7月18日 (一) 07:07 (UTC)
要不要@当事人,他们反对不也是有他们的根据,把各种可能列出来大家也好看清楚哪种方式具有可行性,谁又比较好执行。 --窝法乙烷 儿法梦碎 2022年7月19日 (二) 14:18 (UTC)
@Stevencocoboy我的讨论页有他的回应,也可请他再做回应。--Sa Young Sun留言) 2022年7月20日 (三) 05:27 (UTC)
(!)意见:敝人对此类官方资料来源了解不深,稍加补充个人考量和理据。首先,个人认为太多版本、复杂、零散的来源多有歧异,所以海报或周边产品等来源并非首选,也太容易起争议。其次,如果连官方网站都不准,需要热心资深编者告知其中差异甚至引用规则,这对一般想参与编撰入门的编者恐怕不甚友善,所以我认为第一时间仍需考虑来源的公开易得性和用户直觉性。再次,的确是作品本身的片尾名单最完整。综合以上考量汇整内容为:
“演员与角色讯息(含信息框中的主演栏)一般可以正式官方网站公开发布讯息收录,若编者因对于作品之可靠官方来源选择或判定不一,或因其他理由,导致对于演员排序认定歧异,则依序以下列来源为依据:
1.影片中完整的演职员表(如片尾演职员表或片中的跑马字幕),若影片是依出场顺序排序则不适用。
2.影片片头的演职员排序,若影片是依出场顺序排序则不适用。
3.官方海报的演员名单排序。
4.官方网站的演员或人物介绍排序。
5.其他官方发行产品上的演员名单(如相关刊物、影音产品等其他多媒体)。
若影片有不同官方版本(如因场次、地域、再版、媒介等因素而产生不同版本),导致演员名单排序不一,以作品首播、首映、首发之原产地版本为准。(后略)”
个人意见,供参。--Kriz Ju留言) 2022年7月28日 (四) 21:25 (UTC)
已更新。同意有争议时,再行参考的方案不错。--Sa Young Sun留言) 2022年7月29日 (五) 02:13 (UTC)
(-)反对,规定先后顺序的意义是什么?为什么老是要无中生有制造一些毫无意义的问题,确定谁先出场、谁比较重要?这连 fandom 的各个 wiki 都不会这么干吧。请先证实问题的必要性再来讨论如何解决问题。--Austin Zhang留言) 2022年7月29日 (五) 19:12 (UTC)
(!)意见:个人认为,此提案产生的背景在于编者对于“演员顺序”所选择或偏好之资料来源认定不一,所产生难以达成共识之编辑战或相关争议,初步考古这似乎也是此主题争论已久的课题。以主要演员或主演群而言,演员排序大致上可提供诸如:演员所饰角色于剧中的分量或重要性、演员本身在业界的声望或地位等讯息,因此亦成为剧迷或影迷于条目中可能不断争论之焦点。此时,若对于究竟应以何种资料来源作为优先参考基准难以达成共识,除了让相关编者徒耗心力于相关争议上,亦某种程度妨碍编者将本就有限之时间和心力投入编著或创建条目,反倒有碍条目内容之增新充实;长久下来,除了参与的编者可能因不时产生的编辑战心力耗损,亦于用户间徒生磨擦和争议,进而干扰或妨碍彼此之间原先可能的合作空间。不论怎么看,对条目编辑和用户协作皆非美事,亦显无裨益。正因对一般读者而言可能不见得关注演员排序的细微差异,此类细节反而对活跃或资深且熟悉此领域的热心编者而言更为关注、重要,若能产生一个更有效率的来源判读争议解决方案,相信此后对于条目、编者、促进合作、减少过多争论以及难以解决之编辑战等面向将大有助益。--Kriz Ju留言) 2022年7月29日 (五) 20:13 (UTC)
你只是刚好没遇到疯子罢了,用音乐条目来看就是一群人大吵特吵哪个音乐类型先放、哪个制作人先放(好险饭圈只会争C位不会在乎幕后工作人员的辛劳)。 --窝法乙烷 儿法梦碎 2022年7月30日 (六) 02:50 (UTC)
我觉得你与其这么说,不如直接给他几个疯子发癫现场看一看……--MilkyDefer 2022年7月30日 (六) 11:25 (UTC)
  • (!)意见:个人希望再做些微调整,考量和理据如下:
  • 关于“官方海报的演员名单排序”等条文似乎少了句号,另个人建议“正式条文”和“文中案例”以括号略作分隔。
  • 关于“其他官方发行产品上的演员名单(如刊物、DVD等)”:个人认为随着时代背景差异、各种媒介载体有别,此处仅列出DVD,往后会否可能因载体差异而产生其他争议(如:BD、VCD、LD、录像带、原声带等)?个人的考量是以概括性统称不写死即可,最理想的情况其实是尽量避免列举式文字。另外,个人认知这里指的“DVD”是指“产品包装或外盒上的名单”;若否,则一开始不断谈及的“影片”为何,似有争议。
  • 关于“演员退出、辞演或角色身亡、删除等,仍应保留在名单之中,也不得任意略过。”:个人认为此条文似可再论,建议改为“演员退出、辞演或角色身亡、删除等,因考量资料收录完整性,仍可保留在名单之中。”即可。用“应....不得...。”将使此条文成为一种带有惩罚性禁制措施之“强制性规范”,个人认为不符比例原则,仿佛参与的编者只要没写好或未收录完整就要受到何种惩罚似的,那么万一编者因版本异动而不知、忽略或主动省略异动的演员而没写到是否要受罚呢?个人认为不甚妥适。且万一与下方作品首播、首映、首发之原产地版本名单相冲突(比如该版本名单未收录离开的演员),又产生矛盾。个人认为实务情境或许是:不想写或没写到的人没什么错,而想写的人能适当合规写上去并获保留、不另遭遇无谓争议即可,而非看似迫使编者没写到就得受罚。
  • 承上,因此以上方“名单的来源先后顺序”条文作为“一般性通则适用”,后者的“异动后仍保留名单”条文做为“豁免性个案处理”,敝人认为行文先后次序应对调方合乎原提案意旨、实务应用和读者理解。
  • 综上所述,敝人再汇整调整为:

“(前略)

1.影片中完整的演职员表(如片尾演职员表或片中的跑马字幕),若影片是依出场顺序排序则不适用。
2.影片片头的演职员排序,若影片是依出场顺序排序则不适用。
3.官方海报的演员名单排序。
4.官方网站的演员或人物介绍排序。
5.其他官方发行产品上的演员名单(如相关刊物、影音产品包装等其他多媒体)。
(案例略)
若影片有不同官方版本(如因场次、地域、再版、媒介等因素而产生不同版本),导致演员名单排序不一,以作品首播、首映、首发之原产地版本为准。而演员退出、辞演或角色身亡、删除等,因考量资料收录完整性,仍可保留在名单之中。”--Kriz Ju留言) 2022年8月1日 (一) 10:55 (UTC)
已更新,请复查。不过“正式条文”和“文中案例”以括号略作分隔这部分括号是建议加在何处?--Sa Young Sun留言) 2022年8月1日 (一) 15:41 (UTC)
敝人已直接自行稍作异动于“如片尾演职员表....”处,已无其他意见,请复查。--Kriz Ju留言) 2022年8月5日 (五) 21:05 (UTC)
了解,无异议,感谢!还请各位支持。--Sa Young Sun留言) 2022年8月13日 (六) 13:03 (UTC)
未有与提案条文和欲改善问题显明扞格之具体观点和理据,现以此条文版本公示七日。--Kriz Ju留言) 2022年8月13日 (六) 21:12 (UTC)

有关节目列表条目的删除标准的补充讨论

遇到的问题 有关节目列表条目的删除标准的补充讨论
问题背景 OO电视台外购XX节目列表的问题类似于OO节目列表
我的观点 相关外购节目列表有可能会违反下面的方针
  1. WP:NOTDB(“主题关系松散的数据库或列表”)
  2. WP:NOTIINFO(“维基百科的条目并不是过度统计清单。”)
  3. WP:VERIFY(编辑者应为条目中的内容及其引用提供可靠来源。(这些条目涉及的即将播出节目的资讯内容可能会涉及到不可查证来源(例如某家电视台的广告商节目表)以及不可靠来源(例如新浪微博网友的猜测))
  4. WP:NOTE(这些条目基本上都是从已有的列表中拆分出来的没有对应的独立关注度)
我的解决方案 参考WP:TVCONTENT的解决方案统一搬到相关的爱好者网站
此前的类似讨论
  • 此前有没有过与本提案主题类似的讨论?有没有人遇到过相同问题?
  • 请在这里罗列,并给出对应的链接。

Wikipedia_talk:格式手册/电视/存档二#有关节目列表条目的删除标准

--我永远喜欢末门牙王-第七号台风————查~帕~卡~——有——蓝屏死机 …….. 2022年7月18日 (一) 09:15 (UTC)


即使是英文维基百科也有en:List of television programmes broadcast by the BBC,而且已经存在了20年,所以我在5月说过“我不明白Wikipedia:维基百科不是什么明明是参考英文维基百科对应页面创建,但是在中文维基百科就发展成、被诠释成一套比英文维基百科那边更加严苛的标准。”另外,对于不懂俄文的中文维基百科用户来说,华语电视台的节目播放列表应该还是较古罗斯历史条目更易查证。--Mewaqua留言) 2022年7月20日 (三) 03:04 (UTC)

最后一点我不认同(之前和现在播出的节目还算是可以查证但是未来播出的节目真的很难查证(七天内播出的还好未来一个月两个月的就真的没法做到可供查证。(例如勇者斗恶龙 达尔的大冒险将于今年一月份在翡翠台播出的不实消息到了今年一月份之后被证实为假消息后才被删除)(因为涉及到不可查证来源之前在中维TG群探讨过相关问题结果就是类似于广告商节目表(这种东西一般都是属于商业机密算是不可查证来源)这类的消息以及新浪微博上发布的节目播出资讯(涉及到原创研究)都属于不可靠来源)以及某些动画自媒体可能会把维基百科当成可靠的来源去发布相关动画资讯甚至有的维基人把相关列表的内容写进维基百科的动画条目中这种行为本身也违背了维基百科本身不能作为参考来源的原则))--我永远喜欢末门牙王-第七号台风————查~帕~卡~——有——蓝屏死机 …….. 2022年7月20日 (三) 04:39 (UTC)
难以查证的“未来播出的节目”记项可以删除,就如假设有人在“地球”条目加入难以查证的文句,其他人看到之后,删除该等内容即可,而不是提出删除整个“地球”条目。--Mewaqua留言) 2022年7月20日 (三) 11:41 (UTC)
而且这些列表的话基本都是从别的列表中拆出来的(单独拆出来的话可能没有独立的关注度例如:Wikipedia:页面存废讨论/记录/2021/12/16#Now宽频电视/香港电视娱乐外购剧集列表)而且这些拆出来的列表基本都是属于POVFUN早就应该删除了只不过由于历史遗留原因才能存在至今--我永远喜欢末门牙王-第七号台风————查~帕~卡~——有——蓝屏死机 …….. 2022年7月21日 (四) 09:43 (UTC)
en:Lists of TVB dramas and seriesen:Category:Lists of television series by network。--Mewaqua留言) 2022年7月24日 (日) 03:11 (UTC)
实际上英语维基的节目列表根本就有按照节目是否外购来拆分节目列表(这个现象是中文维基独有(尤其涉及到香港电视相关的列表))建议这种内容还是搬到相关爱好者网站比较好--我永远喜欢末门牙王-第七号台风————查~帕~卡~——有——蓝屏死机 …….. 2022年7月24日 (日) 08:19 (UTC)
保留,如内容不可查证则可移除不可查证的内容。--Yinyue200留言) 2022年7月31日 (日) 12:49 (UTC)
删除不可查证内容算是可行的方案只不过有的不可查证内容是存在有争议性(例如ViuTV网站的节目表由于技术原因无法显示第7日23:30到00:00的节目表(香港以外的人通常都是从该电视台网站查询节目表)而在香港数码电视广播该频道的电子节目表中(EPG)第七日23:30到00:00的节目表是能够正常显示的(香港本地人更习惯看电子节目表来得知节目消息)相当于变相提高查证门槛(只能等到次日才能得知对应时段的节目内容)--永远喜欢搭档对战 2022年8月9日 (二) 13:45 (UTC)

维基百科:关注度/提报问题

请问这个页面中的条目一定要按照UTC时间才能算到期并提报吗?我今天在UTC+8 7:00左右提删6月27日提报的条目,铁路1在User talk:日期20220626#AFD叫我8:00(UTC+8)后提报,我对这个以UTC为中心的做法表示质疑,因为中文用户大部分都居住在UTC+8,自己没必要去跟着UTC来。

我在他的讨论页User talk:铁路1#AFD问题表示日语维基就按照他们UTC+9的时区行事。例如,7月24日 UTC+9 0:00过后提删的条目就算在7月24日的提删讨论页面,而此时UTC还是2022年7月23日。

我又来到twinkle的telegram群组询问xiplus([3]),twinkle提删能否自己设置时区(目前在UTC+8 8:00前用twinkle提删,条目或页面会算在前一天的存废讨论,除非自己手动更改),xiplus解释“站务运作遵循一套统一标准”,我表示为何要以UTC为标准,根本就没有多少人居住在UTC,不应UTC就是所谓的标准时区,一大堆UTC+8的人就要围着UTC团团转。--日期20220626留言) 2022年7月27日 (三) 02:22 (UTC)

方便技术实现吧,统一使用UTC作为时间划分标准,可以不用考虑因为时区差异而需要调整的处理。而且不要假设全部中文区编辑都在UTC+8区。——Sakamotosan路过围观 | 避免做作,免敬 2022年7月27日 (三) 03:00 (UTC)
不就跟北京时间#中国西部地区时间问题一样?不住在UTC+8的也要配合用UTC+8。--Xiplus#Talk 2022年7月27日 (三) 03:51 (UTC)
所以争议就出在要不要以某个时区为标准,这样的话UTC也好UTC+8也罢都一样,而且以前者为标准更不合理。--日期20220626留言) 2022年7月27日 (三) 04:18 (UTC)
其实吧,差八个小时而已,不一定要这么严格,早一点提报也没什么影响。—— Eric Liu 創造は生命(留言留名学生会 2022年7月27日 (三) 04:14 (UTC)
那个群你也在现场,xiplus居然直接跟我说这叫“捣乱”了。--日期20220626留言) 2022年7月27日 (三) 04:21 (UTC)
Special:Diff/72912490,故意在错误的日期提报存废讨论,以及故意不使用签名语法产生的时间戳格式,不仅仅是“捣乱”,而是WP:扰乱了。--Xiplus#Talk 2022年7月27日 (三) 06:35 (UTC)
就是因为现行的所谓UTC的机制,UTC+8 7月27日 7:28的提删,你们叫我去7/26的页面提报,到底哪个才是扰乱?非要一个生活在7月27日的人在维基穿越到7月26日?难道你们都生活在UTC+0以及以西的时区?
至于签名语法,纯粹是懒得改成“--~~~~”,倒不是故意要用+8。--日期20220626留言) 2022年7月27日 (三) 06:46 (UTC)
对啊,就是生活在这些时区啊。难道不存在这样的编辑者吗?--Xiplus#Talk 2022年7月27日 (三) 06:56 (UTC)
那这样的编辑算是多数还是少数?维基百科:统计#用户来源分布,编辑用户中UTC占比只有可怜的1.5%, 81.6% UTC+8的人难道真的要以UTC为准?--日期20220626留言) 2022年7月27日 (三) 07:12 (UTC)
示例:如果你希望改变现行的提删程序……理当争取大家的一致意见。而不要故意违反现行程序。--Xiplus#Talk 2022年7月27日 (三) 06:38 (UTC)
所以今天有人跟我意见不同,你在那个群也不同意我的做法,我不就来互助客栈讨论了吗?不要动不动说别人“故意”。“子非鱼,安知鱼之乐?”--日期20220626留言) 2022年7月27日 (三) 07:06 (UTC)
您不是先征求大家意见,而是已经做出错误的行为了。既然Twinkle或是站内的提删按钮都是指向7/26的页面,那您就是应该先遵从这个指示,再来提出这是否有问题,而不是径自违反这个指示。--Xiplus#Talk 2022年7月27日 (三) 07:16 (UTC)
我认为把本站时区改为UTC+8更合理。现有289个站点设置了自己的时区,技术上是没问题的。--Lt2818留言) 2022年7月27日 (三) 07:52 (UTC)
技术当然是没问题,但问题是需要调整许多的基础建设(模板、小工具、机器人)。--Xiplus#Talk 2022年7月27日 (三) 08:03 (UTC)
可能连一些管理数据会有问题,例如现在{{unsigned}}的时间是要求是UTC的,只需要直接复制页面历史的时间就可以了,改动了站点的时间设置会影响这个数据的录入。——Sakamotosan路过围观 | 避免做作,免敬 2022年7月27日 (三) 09:28 (UTC)
我认为技术实践优先于用户体验,如果强行修改站点时区,可能会影响很多“基础设施” 、涉及时间的规则的设计、配置、计算等。而且无法排除不在UTC+8外的用户,UTC是一个相对公正的时区标准。跨时间的影响可能有限,按照正常的作息从早上6点开始的话,到8点也就是2个小时的日期差。——Sakamotosan路过围观 | 避免做作,免敬 2022年7月27日 (三) 09:39 (UTC)
说到底还是路径依赖,而不是所谓的UTC有多么公正。--日期20220626留言) 2022年7月27日 (三) 09:51 (UTC)
使用UTC在“技术上公正”。--Xiplus#Talk 2022年7月27日 (三) 10:05 (UTC)
没办法,已经发生了。但还是可以灵活解决(例如一些依据日期提报但“放错”时间的提请,可以移到正确的时间上来回避)。——Sakamotosan路过围观 | 避免做作,免敬 2022年7月27日 (三) 11:51 (UTC)
改时区似乎并不能解决提报“放错”时间的问题吧?--百無一用是書生 () 2022年7月28日 (四) 02:18 (UTC)
改时区就可以使用#timel函数,会比较方便设计模板。--Xiplus#Talk 2022年7月28日 (四) 02:48 (UTC)
  • 因为迁移的技术成本+地域中心之说吵不出结果,所以一直沿用UTC。签名时间、存废讨论、首页内容等,都是按UTC在走。你说这造成不便,大家能理解,但说别人针对你、我就要按自己的理解来提交,我就不能理解了。
  • 并建议搜客栈存档,这个问题可说是WP:常年提案2005年就提出和深入讨论过,“xx中心”之说在那时就有。2013年1月等也有人提出过。2012年在客栈,就首页内容更新时差——Wikipedia_talk:历史上的今天#首页“历史上的今天”可否于每日UTC+8零时更新?吵得很凶,诞生了自选小工具方案,但问题是否算解决。也请参考其中的各种意见,不少用户认为“摒弃UTC”是地域中心之举。
  • 个人来说,UTC在我的维基生涯中偶尔造成不便(比如、尤其是填写{{未签名}}参数),更改对我有利,但我对说服部分用户所坚持的地域中心、地区/人数霸权等说法毫无信心,也对平稳迁移站内外所有工具没有信心,很多数据资料没有时区信息,势必造成不少千年虫式混乱。--YFdyh000留言) 2022年8月4日 (四) 10:33 (UTC)
  • (!)意见:个人不解技术,仅斗胆补充些许个人意见。先说结论:个人认为若技术许可(包含不对各式站内的基础建设和技术设置造成不良影响等前提下),本站时区显示若能依《Wikipedia_talk:历史上的今天#首页“历史上的今天”可否于每日UTC+8零时更新?》该篇讨论之热心站友建议,启用“可以根据用户设置的时区来修正时差,即是连海外华侨都能照顾得到,能做到照顾所有时区,并非只懂+8小时,而是能根据浏览器的设置作出正确调节,可设为所有用户预设选取”的传说中小工具,而敝人同时认为用户造访平台时,若能第一时间显示关于此方面之类似“用户许可协议”相关讯息或对话框,征求用户同意,并善尽平台告知义务,除可免除用户隐私相关疑虑,亦可更贴近更多用户需求,以期许平台之有效推广和深耕。个人考量和理据如下:
  • 首先,《维基百科:避免地域中心》主要用于规范条目内容,理想上可扩充延伸至指导编辑思维并引导社群行为。就个人认知和期待来说,若纯粹论及用户需求和体验,反而是越“地域中心”越好、越个人化越好(笑)。毕竟,所谓“地域中心”其实换个说法就是“本地化”,“深耕在地”不代表不能“放眼全球”,越能轻易本地化的技术和界面反而越证明其国际化或全球化,如此反倒摆脱涉及地域中心之疑虑;而最贴近个人且便于使用的技术、设计和界面,往往最容易为多数人接受,也最容易获得推广。
  • 其次,今日本站对于条目,来自不同地域的用户已可自由选择自己偏好或习惯、不同地区使用的“中文字体形式”,若有需要,条目内亦皆可加入“地区用词转换”;此外,现在用户亦可于刚进入页面时便直接选择个人偏好的各地区主要使用中文字体,这些功能难道是使用界面设计“触犯”地域中心的表现吗?显然不是,这一切皆显为致力于让使用体验更加本地化、个人化、便利化、人性化且贴近不同用户需求的界面功能和努力成果,反倒现有时区设置更像是一种地域中心,只是形式上“看起来更中立”而已。依此而言,若能连“时间或时区显示”都可以符合不同用户的需求,自然是好事一桩,亦已多有其他语言的维基百科显示其最主要时区。
  • 再次,若以推广中文维基百科而言,自当以开放的国际化和全球化精神为前提,然而这不意味此平台在提供用户功能和服务时不应贴近用户需求,两者可并行不悖,甚而理想上本应如此;因此,以浏览量最高、亦即本站最为广获使用、发展和推广最为成功之主要时区为优先考量,个人认为并无情理不通之处。换言之,该时区既然最为接受此平台,也可以说在某种程度最能接受或认可社群乃至每位用户投入贡献的心血结晶和努力成果,甚至很可能可说是本站最能广获影响力并持续深耕推广的时区,又岂有平台和社群反过来抵制或忽视该主要时区的合理需求、“自废武功”的道理呢?
况且,中文的主要使用地区和用户多位于同一时区,若考量其他地域或时区之用户,即便援引“避免地域中心”之概念(敝人认为难谓有何抵触),此平台亦已于“用户体验之合理需求”和该观念之间尽可能折衷妥处,个人认为无必要持续扩充引申。
  • 至于经敝人初步考古,直接使用该项调整小工具之争议或许主要在于“是否侵犯IP用户之信息和设备隐私”。事实上,首先,在本站善尽告知义务且建议用户注册个人账户的前提下,使用IP编辑的用户通常已相当于某种程度自愿提供相关用户信息,抑或原本就没那么注重隐蔽或保密相关信息之需求,可视为愿意提供相关讯息。同理,今日诸多网站亦于用户或访客造访其页面时,主动出现对话框告知用户该站“将基于何种目的收集哪类用户讯息,以达成何种效果”(比如:为增进用户体验,将收集用户的OO以增益于XX),相关内容应属“用户许可协议”之一部分。综上所述,若本站明确于用户造访浏览平台时在第一时间告知、供其选择同意与否(比如:若用户选择“不同意”则可维持原UTC设置之类),便已善尽平台义务,或无需过度忧虑。
以上为个人意见,供参。--Kriz Ju留言) 2022年8月11日 (四) 22:40 (UTC)

修改"特色图片标准"

已通过:
已完成公示,将协助代为依条文进行修订。--Kriz Ju留言) 2022年8月16日 (二) 19:26 (UTC)
下列讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

目前的特色图片标准中,有一条为“具有描述性、翔实且完整的英语文件描述”。这一条文由A1Cafel加入,猜测为对共享资源或别的项目类似标准的翻译;后由12З4567写入“评选程序”页面。由于这是一个中文站点,个人认为照搬其他语言项目/多语言项目的标准并不妥当,故提议修改为“具有描述性、翔实且完整的中文文件描述”,下面的详细说明同时进行微调。-- Stang 2022年7月29日 (五) 11:58 (UTC)

(+)支持--飞马🎠🎈 2022年7月29日 (五) 14:32 (UTC)
(+)支持--Yinyue200留言) 2022年7月31日 (日) 12:59 (UTC)
现行条文
  1. 具有描述性、翔实且完整的英语文件描述。一个完整的文件描述:
    • 准确分辨主体,包括拉丁语和技术名称(如适用)。
    • 描述照片、绘画或其他媒体的内文支持可识别地点的地理标记照片。这需要提供记录介质时相机的坐标,以适合不小于大约10平方公里的精密度(请参阅Commons:GeocodingTemplate:Coord如果图像托管在中文维基百科上)
    • 列出最相关的元细节(例如日期、位置事件、版本等)。建议在提名过程中把已知的其他相关资料随后列入文件描述中。
    • 可能包括英语以外的语言,但必须有符合此标准的英语版本。文件名称可能是英语以外的其他语言
提议条文
  1. 具有描述性、翔实且完整的中文文件描述。一个完整的文件描述:
    • 准确分辨主体,包括拉丁语和技术名称(如适用)。
    • 描述照片、绘画或其他多媒体文件的相关信息建议上传包含地理标签的照片
    • 列出最相关的元细节(例如拍摄日期、拍摄位置、相关事件、版本等)。建议将在提名过程了解到的其他相关资料在评选结束后列入文件描述中。
    • 可能包括中文以外的语言,但必须有符合此标准的中文版本。本要求不对文件名的语言进行限制

修了一些比较奇怪的语句,现公示7日。 Stang 2022年8月9日 (二) 12:33 (UTC)


本讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

提议将格式手册/序言章节#列明来源设为方针指引

近日Wikipedia:优良条目评选/提名区有编辑表示“Top(导言)整部分缺乏来源”,虽然大家长久以来都习惯不塞来源,但这毕竟是闯红灯行为,所以敝人提议将Wikipedia:格式手册/序言章节#列明来源设为方针,永绝后患。 --窝法乙烷 儿法梦碎 2022年7月29日 (五) 16:03 (UTC)

个人认为序言部分,经常有人“原创总结”,还有就是有些编辑习惯把新的内容加到序言,正文不加,导致序言不断膨胀。这些风尚没有改善,还是保有来源比较好。--Nostalgiacn留言) 2022年7月30日 (六) 02:18 (UTC)
虽然这样讲有点过分,但大哥你原神角色条目一堆导言没加来源耶。序言章节#列明来源写说可以不在导言列来源不等于内文不用,文章讲述“导言通常被写成是比条目主体层次较浅的概述,而在序言章节中无争议的东西看似是较少会被质疑的,继而看似是较少机会被要求列明来源;不过这不是说序言可以例外地绕过参照要求。序言是否有必要列明来源应个别地、以编者共识来处理。复杂的、正在发生的、或有争议的事项可能需要列明来源;其他的则列出少量甚或不用列出。这里不要求也不禁止条目的序言作出参照,而需视不同状况而定。”并没有禁止列明来源,而阁下担忧的序言膨胀不论此方针是否通过都没差,因为这是人的问题,看看同样防军子不防小人的Wikipedia:列明来源。 --窝法乙烷 儿法梦碎 2022年7月30日 (六) 16:49 (UTC)
确定是防君子不防小人。其实Wikipedia:格式手册/序言章节已经事实上作为GA的标准。如果只是针对优良条目评选的提名区“Top(导言)整部分缺乏来源”的情况,其实完全可以给出WP:LEADCITE说理。
过去个人是序言也加上来源的(《圣女战旗》),也就是评选了GA后,才发现WP:LEADCITE部分情况豁免,之后个人不再给序言的事实性描述和内文已经提及内容写来源。除去评选的情况,考虑到整体环境,还是收紧一下比较好。--Nostalgiacn留言) 2022年8月1日 (一) 04:32 (UTC)
虽然这两个作为长久以来的共识被执行,但实际上都不是方针。如同GA的展示日期,当时吵这么久不就是因为根本没有所谓的共识,数大必有枯枝,人多必有白痴,无论本提案是否通过我们都有其他手段处理这些人造成的序言膨胀和不列来源的问题。 --窝法乙烷 儿法梦碎 2022年8月2日 (二) 07:09 (UTC)
我去看了近日的GA评选,你提到“有编辑”HK5201314在旁人提及“导言不标来源是英维GA常见的写作方式”,HK5201314之后也给出赞成票,并没有到你说的“吵这么久”的地步。还不如把WP:GA?变成共识,所有评选标准就看齐了。--Nostalgiacn留言) 2022年8月3日 (三) 07:21 (UTC)
@Nostalgiacn:阁下请看看我打字到底打了些什么......,“如同GA的展示日期,当时吵这么久不就是因为根本没有所谓的共识”,相关讨论可以看这里。我要处理的问题很简单,就是允许导言可以不列来源,将GA评选列为方针不仅不是我的目标,同时也无法处理我想解决的问题。先不提可能要接续提Wikipedia:新条目推荐/候选#规则Wikipedia:典范条目标准,提GA评选意味要处理其他不受现有正式方针认可的标准,想想Wikipedia:条目长度讨论3遍会耗费多少时间。 --窝法乙烷 儿法梦碎 2022年8月3日 (三) 15:10 (UTC)
那么避免换灯泡的破事,加速通过应该没什么争议的WP:LEADCITE吧。--Nostalgiacn留言) 2022年8月3日 (三) 16:41 (UTC)
个人认为列明来源设为指引会比较合适。--飞马🎠🎈 2022年7月30日 (六) 04:23 (UTC)
WP:列明来源已经是中文维基百科的内容指引--Rastinition留言) 2022年8月4日 (四) 22:49 (UTC)
我还真是未看过摘要要加来源这种操作……btw 以常见的电影/电子游戏条目为例,导言通常会包含极简短的评价,但到了内文它就是好几段文字加上十多个来源,如果要硬性规定补上来源,就有机会演变成一句句子附有十多个来源佐证,这极为影响美观。另外上方Nostalgiacn君指的序言膨胀问题,其实这种情况有没有来源都是一样,就算规定了序言要加来源,亦不见得将来会减少。--银の死神走马灯剧场祝你在乱流下平安 2022年7月30日 (六) 15:41 (UTC)
行。—— Eric Liu 創造は生命(留言留名学生会 2022年7月31日 (日) 07:40 (UTC)
(+)支持,提议条文简而言之,就是导言避免列出多余来源,BLP有争议的必须列来源,其它有争议的看共识或常识。--BlackShadowG Slava Ukraini! 2022年7月31日 (日) 15:37 (UTC)
也可以说明下哪些争议适合列入导言,哪些不适合列入导言?--Kethyga留言) 2022年8月4日 (四) 13:21 (UTC)
同闪亮飞月,应设为指引而非方针。--街燈電箱150號 开箱维修 抄表 检验证明 2022年8月4日 (四) 03:28 (UTC)
我支持导言列来源,所有正文理应言之有据。“避免列出多余来源”在实践上含糊。赞成列为指引。(+)强烈建议将“列明来源”拆分为两个子章节,“导言必须符合可供查证、生者传记和其他方针”这段列为指引乃至方针,而第二段再进行一些考量和讨论。--YFdyh000留言) 2022年8月4日 (四) 06:43 (UTC)
蛤?恕敝人资质驽钝,阁下大打算要叫两个子章节什么? --窝法乙烷 儿法梦碎 2022年8月4日 (四) 08:33 (UTC)
设立子章节以利于标识。大概是这样。--YFdyh000留言) 2022年8月4日 (四) 09:13 (UTC)
不是啊,再有Wikipedia:可供查证Wikipedia:列明来源的基础下,讨论“原则”的意义何在? --窝法乙烷 儿法梦碎 2022年8月4日 (四) 09:46 (UTC)
因为此题是“提议将Wikipedia:格式手册/序言章节#列明来源设为方针”,且此处总不能直接写“参考可供查证和列明来源”。--YFdyh000留言) 2022年8月4日 (四) 10:02 (UTC)
还真的有,请参考Wikipedia:可供查证#可靠来源Wikipedia:可靠来源。该“原则”内容就是可供查证和列明来源,没必要花7天公示已经是方针的内容。关于错字,我加了删除号。 --窝法乙烷 儿法梦碎 2022年8月4日 (四) 10:34 (UTC)
简述还是有用的,方针页面较长、特定方面不够具体。而指引/方针的内容是否要讨论公示,目前不就是出现了争议。我对段落一无异议,但段落二我认为易导致误解,或者本身就有模糊地带,我不希望别人据此发表非社群共识。--YFdyh000留言) 2022年8月4日 (四) 10:42 (UTC)
@YFdyh000:简述的确有用,但没有简述也不影响导言需要罗列来源的事实,何苦浪费时间在段落一上?单刀直入段落二不好吗。 --窝法乙烷 儿法梦碎 2022年8月4日 (四) 12:37 (UTC)
“单刀直入段落二”就是如上所述,我不赞成它列为指引。那么段落一呢,您认为应该“去掉”?--YFdyh000留言) 2022年8月4日 (四) 22:37 (UTC)
我只是说没必要讨论已经是方针的内容,不等于段落一要去掉,你要去掉也是可以啦...。 --窝法乙烷 儿法梦碎 2022年8月5日 (五) 01:51 (UTC)
现行条文

列明来源 由于序言章节通常会与条目主体文字的资料重复,故编者应该在避免列出多余来源、与指导读者至受质疑内容的来源间,取得平衡。导言通常被写成是比条目主体层次较浅的概述,而在序言章节中无争议的东西看似是较少会被质疑的,继而看似是较少机会被要求列明来源;不过这不是说序言可以例外地绕过引用要求。序言是否有必要列明来源应个别地、以编者共识来处理。复杂的、正在发生的、或有争议的事项可能需要列明来源;其他的则列出少量甚或不用列出。这里不要求也不禁止条目的序言作出引用,而需视不同状况而定。

提议条文

列明来源 导言通常是比条目内容更为显浅的概述,同样需要符合可供查证等方针。序言章节一般会截取或复述条目内已经有列明来源的文段,相关文段可考虑不重复列出来源,只是在涉及复杂的、正在发生的、或有争议的内容时可能仍需列出来源。必要时编者可以在条目讨论页面、同行评审、互助客栈或其他讨论页面(包含评选)达成共识决定序言章节是否列明来源。简而言之,这里不要求也不禁止在条目的序言章节列出来源,而需视不同状况而定。

我想问一下,楼上几位有看过Wikipedia:格式手册/序言章节#列明来源吗?原文写道“序言是否有必要列明来源应个别地、以编者共识来处理。”,所以不用特地写出哪些争议适合列入导言,哪些不适合列入导言。而综观大半的DYK、优良、典范,避免列出多余来源在实践上可一点都不含糊(毕竟一堆不列的是要怎么含糊ˊ_>ˋ)。
@Nostalgiacn閃亮飛月RastinitionSilverReaperEricliu1912KethygaCdip150YFdyh000:我直接粗暴的将导言罗列来源的讨论挪到评选,反正不满意的可以投反对并表示编辑应该加来源,这方法不知道各位觉得怎么样。 --窝法乙烷 儿法梦碎 2022年8月5日 (五) 03:07 (UTC)
建议原文也修改一下,读起来不通顺,如“与指导读者至受质疑内容的来源”之类的用语也不太理解。
参考上面的说法,修改建议:
“导言通常是比条目内容更为显浅的概述,同样需要符合可供查证等方针。序言章节一般会截取条目内已经有列明来源的文段,截取的文段可考虑不重复列出来源,只是在涉及复杂的、正在发生的、或有争议的内容时可能仍需列出来源。必要时编者可以在讨论中达成共识决定序言章节是否列明来源。简而言之,这里不要求也不禁止在条目的序言章节列出来源,而需视不同状况而定。”--Nostalgiacn留言) 2022年8月5日 (五) 16:38 (UTC)
不应该以评选页面为讨论地点,多数条目从不上评选,写同行评审都好得多。不过,我是建议改为“在讨论页或同行评审等处取得编者共识”。—— Eric Liu 創造は生命(留言留名学生会 2022年8月6日 (六) 03:53 (UTC)
毕竟目前有编辑对导言有疑虑,而讨论页或同行评审的人气可想而知,到最后也是到条目讨论公审,而反对方都能在评选页面发表意见,没道理需要限流。 --窝法乙烷 儿法梦碎 2022年8月6日 (六) 14:05 (UTC)
那跟写进政策页面明示是两回事。我不赞成“评选至上主义”。优先级应该是条目讨论页面、同行评审、互助客栈、其他讨论页面(包含评选)。—— Eric Liu 創造は生命(留言留名学生会 2022年8月6日 (六) 15:31 (UTC)
@Ericliu1912Nostalgiacn:写成这样如何? --窝法乙烷 儿法梦碎 2022年8月7日 (日) 01:35 (UTC)
反对“截取”之类的字眼,不认为0段需要跟正文内的句子逐字相同。-hiJK910 走先喇 係咁先喇 下次再玩吖 2022年8月7日 (日) 02:09 (UTC)
可以描述修改一下:“序言章节一般会截取或复述条目内已经有列明来源的文段,相关文段可考虑不重复列出来源。”
结合上下文的表态,是否除了行文用字外,是支持其方向的。--Nostalgiacn留言) 2022年8月7日 (日) 05:36 (UTC)
这样呢。 --窝法乙烷 儿法梦碎 2022年8月7日 (日) 07:14 (UTC)
@Hijk910:看看修改如何。--Nostalgiacn留言) 2022年8月8日 (一) 05:19 (UTC)
“复述”会不会也有“截取”的歧义?-hiJK910 走先喇 係咁先喇 下次再玩吖 2022年8月10日 (三) 16:50 (UTC)
那么你认为使用那些字眼和描述没有歧义。--Nostalgiacn留言) 2022年8月11日 (四) 05:52 (UTC)
(▲)同上,上各种评选的相对来说质量还好,大多数受到质疑的一般不会选择评选。--Kethyga留言) 2022年8月7日 (日) 05:52 (UTC)
我突然想到,既然这条不是方针指引,那么是不是现有的DYK、GA、FA都不符合资格? --窝法乙烷 儿法梦碎 2022年8月6日 (六) 14:10 (UTC)
如果不是真的想撤销所有DYK、GA、FA资格的话,建议不要提出这种没有建设性的问题,让大家作无谓讨论,浪费大家的时间。时间是很宝贵的。-hiJK910 走先喇 係咁先喇 下次再玩吖 2022年8月6日 (六) 14:18 (UTC)
就是不想撤销所有资格才提案,但问题是现阶段无法取得共识,也没人想出两全其美的办法,还是我先提撤销这样大家才有感觉? --窝法乙烷 儿法梦碎 2022年8月7日 (日) 01:26 (UTC)
= =未取得共识和没有取得共识的分别可大了,讨论显然正在推进。因为我相信这项“正式化导言不必注脚”的提案终会通过,所以假如你实行你口中的核弹选项,最终只会让整个中文维基百科都成为你的敌人,让你被视为舞着炸弹的疯子。-hiJK910 走先喇 係咁先喇 下次再玩吖 2022年8月7日 (日) 02:05 (UTC)
还有啦,我一直认为,WP:CITELEAD并不是让导言可以豁免WP:VER(写入维基百科的内容须要能被读者在可靠来源中得到验证)和WP:CITE(内容添加者有义务列明来源),而是明文澄清导言不需要注脚也能彰显这两项规定。我并不认为你的核弹选项能够炸开来用。-hiJK910 走先喇 係咁先喇 下次再玩吖 2022年8月7日 (日) 02:40 (UTC)
还犯不着拆屋以开窗的地步,这算是习惯法变成文法,耐心地还是能通过的。--Nostalgiacn留言) 2022年8月7日 (日) 05:34 (UTC)
我还没炸就有人炸过了,我只是在评估要不要向那位开炸的人道歉。的确WP:CITELEAD并不是让导言豁免添加来源的手段,但不将其列为指引难道要继续闯红灯吗?看看我们身处的奇怪循环“评选时反应导言该加来源→有人反应自古以来都不用加→WP:CITELEAD不是指引→继续反应导言该加来源”,既然评选突破不了那就突破方针看看,好歹存档后可以让后人知道导言要加来源,也是美事一桩。 --窝法乙烷 儿法梦碎 2022年8月7日 (日) 07:14 (UTC)

好几天没有人就修订提出意见,要不要Ping一下进入公示阶段?--Nostalgiacn留言) 2022年8月10日 (三) 05:30 (UTC)

@Nostalgiacn閃亮飛月RastinitionSilverReaperCdip150BlackShadowGYFdyh000Ericliu1912KethygaHijk910:就以这个版本公示7日。 --窝法乙烷 儿法梦碎 2022年8月10日 (三) 16:36 (UTC)
忘了。上面回复了一下。-hiJK910 走先喇 係咁先喇 下次再玩吖 2022年8月10日 (三) 16:50 (UTC)
所以第一段决定怎么改。第二段的修改,比原本好了一些,作为“指引”的话,暂无太大意见。不过字眼细节上,相比“相关文段可考虑不重复列出来源,只是在涉及复杂的、正在发生的、或有争议的内容时可能仍需列出来源。”,个人倾向“相关文段可以避免重复列明来源,但复杂的、正在发生的或有争议的内容可能应尽量列明来源。”。理由:“可考虑不重复”似乎暗示支持“不重复”理据,“可能仍需”语气偏弱。--YFdyh000留言) 2022年8月10日 (三) 19:00 (UTC)
@YFdyh000:第一段维持原样,还是阁下认为有需要修改的部分? --窝法乙烷 儿法梦碎 2022年8月11日 (四) 06:00 (UTC)
@Milkypine 核心内容方针精神记录这些内容,违反核心内容方针的部分,个人不想发表过多意见因为核心内容方针声明所依据的原则不会被其他方针或指引,或者通过编辑者的共识所取代
  1. WP:核心内容方针这些方针可以作为维基百科条目类型和质量的标准。由于三个方针是互补的,所以编辑者不应该孤立地对方针相互理解。而这些方针声明所依据的原则不会被其他方针或指引,或者通过编辑者的共识所取代。这三个方针页只可以通过达成共识的编辑以提升其原则的应用和解释。
  2. WP:非原创研究要证明你没有发表原创研究,你必须列明与条目主题直接相关、且直接支援条目内容的可靠来源。
  3. WP:可供查证可供查证是维基百科内容的门槛,这意味着写入维基百科的内容须要能被读者在可靠来源中得到验证。
  4. WP:中立的观点需明确的一点是,可供查证是不能凌驾于中立性之上的。既可查证又有可靠来源支持的内容,有可能仍然会表达观点或有选择性地引用材料;在文字描述上使用赞成或否定的语气,而非中立描述的适当语气;让某一观点显得更为突出或更可质疑,而不是中立观点的呈现方式;排斥或给予某一观点不应有的地位;在描述中倾向于强化或弱化某一观点;以及其他可能令读者对主题产生偏见的因素。
针对公示的版本这里不要求也不禁止在条目的序言章节列出来源以及其他段落记录的可考虑不重复列出来源达成共识决定序言章节是否列明来源
  1. 抵触WP:非原创研究WP:可供查证精神
  2. 公示版本文字明确鼓励账户用共识取代核心内容方针
针对来源的使用,重复的来源应该使用模板<ref name>,而不是省略,如果引用更多来源也可以,这证明了关注度,但来源的使用不建议使用超过4个,过长的来源注记会影响阅读,可以想像一下在阅读条目时看到下面示例的现象时,阅读者会有什么感想或感受。
示例[4][5][6][7][8][9][10][11][12][13][14][15][16][17][18][19][20][21][22][23][24][25][26][27][28][29][30][31][32][33][34][35][36][37][38][39][40][41][42][43][44][45][46][47][48][49][50]
(~)补充尚未成为指引的翻译页面WP:序言章节记录的内容是序言内容素材的选取重心,应根据可靠的并已出版来源及主题的显著性,以序言章节的几句话来大致反映出条目主题的关注度——通常首段的头几句话应该就要证明到主题的关注度。如果意义重大的信息写了在导言章节后便不会再于条目余下的部分出现的话,那么这些信息不应在导言中出现编者应避免在序言章节中撰写长篇段落和说明得过于具体,特别是这些内容并非全个条目的中心。。--Rastinition留言) 2022年8月10日 (三) 22:48 (UTC)
@Rastinition::WP:CITELEAD不能成为指引→因为须符合可供查证和列名来源→某人在导言加来源→有人反应自古以来都不用加→某人撤除导言来源→有人反应不符方针。所以阁下有何高见处理这种爷孙骑驴的状况?你可别说大家导言应该加来源,看看现状和楼上的发言你就知道这有多不可能。 --窝法乙烷 儿法梦碎 2022年8月11日 (四) 06:03 (UTC)
WP:CITELEAD不能成为指引→因为须符合可供查证和列名来源→某人在导言加来源→有人反应自古以来都不用加→某人撤除导言来源→有人反应不符方针用简单的文字叙述后等于无共识,所以结案原因非常可能是无共识结案--Rastinition留言) 2022年8月11日 (四) 08:36 (UTC)
问你如何突破困境给我回答无共识,不想解决问题可以不用参与讨论,我们没人勉强你。 --窝法乙烷 儿法梦碎 2022年8月11日 (四) 12:31 (UTC)
你既然提到核心内容方针并表示“这些方针声明所依据的原则不会被其他方针或指引,或者通过编辑者的共识所取代”,那是否注意到后面有写“这三个方针页只可以通过达成共识的编辑以提升其原则的应用和解释”。非原创研究说到“要证明你没有发表原创研究,你必须列明与条目主题直接相关、且直接支援条目内容的可靠来源。”请问我内文哪里没有列?既然我内文有列,是不是符合可供查证?至于中立的观点,他和导言列不列来源有何干系。 --窝法乙烷 儿法梦碎 2022年8月11日 (四) 12:39 (UTC)
这时我要引用我讨厌之人的话。核心内容方针不是方针,讲难听点就是可以不理他。WP:方针与指引写到“一般而言,维基百科方针指引并非硬性规定,方针与指引仅列出了各项原则及社群认可的最佳做法。方针所列规范,为编者所应通常遵守;而指引则用以列出各个具体情况下标准做法为何,以资遵守方针所列规范。在援引或执行方针指引时,应始终保持理性及符合常识”,这点让本提案有可行性。 --窝法乙烷 儿法梦碎 2022年8月11日 (四) 12:52 (UTC)
既然你说起方针的话,核心方针还有一条名为不墨守成规。上面一再提到“综观大半的DYK、优良、典范,避免列出多余来源在实践上可一点都不含糊”的现实情况,始作俑者“这里不要求也不禁止条目的序言作出引用,而需视不同状况而定”那段也是翻译自英维。溯根求源的话,创始的英维已经“明确鼓励账户用共识取代核心内容方针”,中维不过亦步亦趋而已。--Nostalgiacn留言) 2022年8月11日 (四) 06:06 (UTC)
@Nostalgiacn请提供
  1. en.wikipedia.org相关讨论的网址和原文(和发表年份、日期、时间)
  2. 你叙述的的因en.wikipedia.org讨论而修改的核心内容方针版本差异链接--Rastinition留言) 2022年8月11日 (四) 08:32 (UTC)
英维对应的文段“The presence of citations in the introduction is neither required in every article nor prohibited in any article.”就是现在的版本。你不会自己找版本差异?你对英维观点有问题,应该回到旧版本,你应该去那边讨论。
中维这里的讨论,除了你在溯根求源之外,其他人目前观点是趋向认同修订的。--Nostalgiacn留言) 2022年8月11日 (四) 09:02 (UTC)
  1. 账户Nostalgiacn原始发言是那段也是翻译自英维。溯根求源的话,创始的英维已经“明确鼓励账户用共识取代核心内容方针”,经过确认,相关内容没有修改,原文仍维持The principles upon which these policy statements are based are not superseded by other policies or guidelines, or by editors' consensus.
  2. 在2022年8月11日 (四) 06:06 (UTC)这个时间之前没有人提到en.wikipedia.org,账户Nostalgiacn在2022年8月11日 (四) 08:32 (UTC)被询问2022年8月11日 (四) 06:06 (UTC)所提到的en.wikipedia.org详细信息后,在2022年8月11日 (四) 09:02 (UTC)后仍然没有附上链接,另外指控对英维观点有问题。对这个状况感到困惑,因为最开始是账户Nostalgiacn主动提起en.wikipedia.org及发表对英维观点见解的相关叙述。
  3. 检查页面Wikipedia:Core content policies没有检查到账号所叙述的原文段落或 The principles upon which these policy statements are based are not superseded by other policies or guidelines, or by editors' consensus.的修订记录--Rastinition留言) 2022年8月11日 (四) 09:57 (UTC)
    请从头看完整个讨论,整个修订的原因就是Milkypine因为近日GA评选有编辑提到“Top(导言)整部分缺乏来源”,2022年8月3日的时候我也由转引了近日GA评选的相关言论“导言不标来源是英维GA常见的写作方式”。Wikipedia talk:格式手册/序言章节一直就是GA评选的英维写作标准之一,中维也已经有一定接受度。讨论就是要将让这个英维的写作标准,从习惯法变成成文法(正式指引)。你说英维观点无关,我在2022年8月11日才提出,很明显就是状况外 --Nostalgiacn留言) 2022年8月12日 (五) 14:23 (UTC)
不违反WP:非原创研究WP:可供查证,正如阁下引用的,可供查证是指“写入维基百科的内容须要能被读者在可靠来源中得到验证”导言不列来源不意味着导言的内容无法查证,而是正文中已经列出来源确保可供查证,导言中没必要再重复列一遍而已,导言的内容仍然是可供查证的。--BlackShadowG Slava Ukraini! 2022年8月11日 (四) 11:30 (UTC)
导言没有使用<ref name>时,除了阅读全文外有其他方法确认正文中已经列出来源确保可供查证?如果没有,首段应该在正文中已经列出来源确保可供查证时使用<ref name>,以利阅读者快速找到对应来源,从阅读者的角度,页面的格式不应该设计成阅读者需要详细阅读内文才能找到感兴趣或必要信息的样式。对阅读者而言寻宝不是必要的,且对阅读者较不友善。
正文中没有列出来源确保可供查证时或者只有首段记录相关信息时,使用<ref>仍然是必要的--Rastinition留言) 2022年8月11日 (四) 11:51 (UTC)
导言的作用只是吸引读者阅读正文,并没有任何利于他人搜索资料之用。如果还要方便读者“快速找到对应来源”,为何要写导言?倒不如直接写正文罢了。--银の死神走马灯剧场祝你在乱流下平安 2022年8月11日 (四) 12:42 (UTC)
(?)疑问页面的格式不应该设计成阅读者需要详细阅读内文才能找到感兴趣或必要信息的样式为什么被解释成搜索资料之用?快速浏览资料的阅读者通常只会看首段,看首段时click参考(外部链接)或蓝字(内部链接)快速链接到对应的外部及内部资料,跟搜索有什么关系?
(~)补充条目内容非常短小或者只是小作品时,首段已经是正文。--Rastinition留言) 2022年8月11日 (四) 13:13 (UTC)
@Rastinition:这条允许导言不列来源的前提是正文有列,既然没有正文,那当然是导言承担这份工作。请问你是真的有看提案内容吗? --窝法乙烷 儿法梦碎 2022年8月12日 (五) 11:54 (UTC)
@Milkypine 2022年8月11日 (四) 13:13 (UTC)時的{{補充}}回应内容对应2022年8月11日 (四) 12:42 (UTC)提到的为何要写导言?倒不如直接写正文罢了。,不对应你的提案--Rastinition留言) 2022年8月12日 (五) 12:03 (UTC)
同YFdyh000阁下的意见。--飞马闪亮飞月 2022年8月11日 (四) 05:56 (UTC)
(+)支持。--BlackShadowG Slava Ukraini! 2022年8月11日 (四) 11:13 (UTC)
不错。—— Eric Liu 創造は生命(留言留名学生会 2022年8月11日 (四) 14:11 (UTC)
(=)中立,不支持不反对。所有意见/立场以最后签名时间为主,如果不希望更改意见/立场,请不要尝试在这个主题内{{ping}}或回复我留下的讯息。因为{{ping}}发生后,最后签名时间必定为回应{{ping}}而更新--Rastinition留言) 2022年8月12日 (五) 12:27 (UTC)
(+)支持从习惯法变成成文法,目前也就是指引用字上的小问题。--Nostalgiacn留言) 2022年8月12日 (五) 14:26 (UTC)

提议创建中小学条目指引

学校条目应涵盖内容,迄今没有一个标准,而这类条目又特别容易有受到破坏,或是加入宣传内容。因此,提议创建Wikipedia:中小学条目指引规范学校条目内容,并参考了WikiProject:学校/条目指引Draft:英文维基百科学校专题编写建议(上述二者均译自英文维基百科学校专题论述,分别经过主要编者修改,基本综合了内容指引与格式指引的性质)与历来讨论,试拟草稿,恳请赐予意见。

不将高等/大专院校纳入的原因,是因为中、英文维基百科的学校专题与大学学院专题都是分开的,可见两者性质略有不同,此处先行就较常被破坏,及条目内容详尽程度较常有争议的中小学部分拟定指引。

中小学条目指引是一篇内容指引,旨在规范中学小学相关条目。

信息框 对于中小学条目适用的信息框,社群已经在2020年间完成整合,请统一使用{{Infobox school}}。

建议避免填写项目

  • 联络方式:例如电话号码、传真号码、电子信箱。(维基百科不是电话簿
  • 副职领导人与临时职位:例如副校长、副主席、代理校长。
  • 尊称:前缀英语Pre-nominal letters后缀字(CEO、Dr、BA、BSc、MA、PhD等)及性别用语(先生、女士)。例如:不要使用“党委书记:王大华先生”,只需要写出“党委书记:王大华”就好了。

导言 条目定义句应提到该校的官方全衔、常见名称及历史上使用过的其他名称,并描述其类型与位置。如:

维基百科中学,简称维百中学,曾称吉米·威尔士中学,是一所位在美国加州旧金山市私立高级中学
源代码小学,简称源小,是日本的一间公立小学,位在茨城县潮来市

如果该校校名的原文并非汉语,请加注原文,但如中国大陆和台湾的绝大多数学校,其原文校名就是汉语者,则不应在第一句提到它的英文校名。

校歌歌词 校歌歌词应仅在确认其进入公有领域,或其他可以上传到维基的前提下,上传到维基文库,并于适当处(如学校象征章节,或末尾外部链接章节)给出链接,因为维基百科不应包含原始资料的副本

如果校歌歌词非自由著作权发布,允许列出其部分具有特殊意义的词句(以有文献专门探讨该句歌词为判定标准),但应说明其意义为何。

人物

家长会等相关组织领导者 历任家长会长、校友会长、教师会长、学生会长等信息,均不应列出。

教职员、学生与校友 教职员、学生与校友,都应该只在人物本身就具备关注度,独立第三方来源提及这位人士与学校的关系时,才被列入学校条目中。如果满足独立列表的要求,可以另以列表收录(可参阅方针《列表的概述》、指引《以地方划分的人物列表的收录标准》,并参考《维基百科:格式手册/列表之内容》以及《维基百科:独立列表之选择标准》创建相关列表)。

在学校条目内提及这些人物时,请以叙事散文为主,尽量避免使用表格或列点。

建筑与学校设施

各项学校建筑与设施,除非是古迹等特殊建筑,或者在可靠来源中具背景介绍或叙述者(不含单纯提及建筑/设施名称,或仅具建物楼层数、面积、建成日期等基本资料者),否则不应单独列出。

于条目中介绍建筑与设施相关背景资料时,应使用百科全书式的语调,撰写描述性质散文,尽量避免仅以列点形式罗列各项建物的名称,也请避免除了名称外,仅写出建物楼层数、面积、建成日期等统计资料。

前述“学校建筑与设施”泛指校园内之建筑物及其内含或附属之设施(包含但不限于校舍、运动场(含球场)、运动馆等建物,以及校舍内的实验室、专科教室、特别教室、建物旁的庭园等设施)。

交通信息 请避免在学校条目中列出如何到达该校、校门口设有什么公车站,停靠有什么路线等信息。(互助客栈2019年7月共识参照)

学生的考试成绩 有关升学考试成绩表现,均不应录入。例如:不应该提到“某高中有多少比例的学生高考在该省平均前50%”(中国大陆),也不应该提到“某国民中学全体学生均在国中教育会考获得B以上成绩”(台湾)。

学校特色 撰写此类文字,务必特别谨慎,以免流于宣传、广告。

开设课程 诸如该国语文、数学、科学、历史这种常见科目,不应该写出。但是,如果该校有特别的课程(例如台湾在108课纲中规定各校都应该要有“校订必修课”),则可以列出。

外部链接

学校条目中,请置放学校官方网站的链接,并使用{{Official Website}}或{{Url}}等模板,以统一格式。尽量使用语言代码模板(如{{zh-cn}})标注该网站的语言。

不要在学校条目中,加入该校社群网站专页、影音频道(如 Facebook, YouTube, 微博, Tiktok)账户,除非此账户实际上代替学校官方网站功能,且互联网上找不到这间学校的官方网站。

参见

Category:维基百科内容指引

至于历任校长、社团列表等先前较有争议的部分,等待上述第一阶段条文讨论完毕后,再行处理。

此前的相关讨论,除了已经以内部链接引用在提议条文中者,尚有:

--S099001留言) 2022年7月31日 (日) 04:48 (UTC)

我认为应当直接写入学校条目指引,不必再特地另立页面。—— Eric Liu 創造は生命(留言留名学生会 2022年7月31日 (日) 07:38 (UTC)
如果能有共识而能创建指引会较好,当然若在此处回响不大,过七天存档后,便会直接将之纳入学校专题的论述中了。--S099001留言) 2022年7月31日 (日) 07:47 (UTC)
不赞同列为指引。为什么学生在毕业后具备关注度就不能列入呢?列入校友栏目都不可以吗?不是很明白。似乎与现行论述内容不一致。
此外我觉得部分内容如果有可靠第三方来源的有效介绍的话,应该允许列入。--Yinyue200留言) 2022年7月31日 (日) 13:06 (UTC)
校舍、设施是学校条目的基本必须内容,亦会经过扩建或重建,甚至搬迁。而且设施标准和种类亦并非所有学校都有,不应删除。--Wpcpey留言) 2022年7月31日 (日) 13:18 (UTC)
@Yinyue200:“学生”原意仅指在学学生。我想就将学校相关人物统一改成类似标准,或许会好些,再请您看看:
现行条文

教职员与学生

教职员仅限本身具备关注度者,像胡适这样有名的教师可以列入

学生除非在学时就具备关注度,如丹尼尔·雷德克里夫等,否则不应列入

提议条文

教职员、学生与校友

教职员、学生与校友,都应该只在人物本身就具备关注度独立第三方来源提及这位人士与学校的关系时,才被列入学校条目中。

至于您提到“部分内容如果有可靠第三方来源的有效介绍”,还请您说明一下是哪些部分,可以将本指引草稿分成多节来讨论,不用一次通过的。--S099001留言) 2022年7月31日 (日) 13:29 (UTC)
至少我觉得“校舍、设施 ”应当是允许列入的。--Yinyue200留言) 2022年7月31日 (日) 13:32 (UTC)
@WpcpeyYinyue200:谢谢提醒,上述提案的确可再商榷。不过现在中小学条目,偶尔仍会见到将校内所有建筑物、设施列出清单。在中小学常见的篮球场、操场、物理实验室、化学实验室等,以及整栋大楼都是普通教室的建筑,并没有什么特别之处,基于维基百科不是目录,个人觉得可以不用录入。
同样地,参照WP:NOT方针提到避免“详尽的软件更新记录”,个人也认为不需要详述一栋大楼扩建、重建、搬迁的历史。当然,像是建国中学红楼这种具备独立关注度的建筑,是可以被列入的。提案稍后改为:
现行条文

校舍、设施

校舍除非是古迹等特殊建筑,否则不应列出。

运动场馆、实验室这类设施十分普遍,不应列出。

提议条文

建筑与学校设施

建筑与各项学校设施,除非是古迹等特殊建筑,或者在可靠来源中,有介绍该设施的叙述(单纯提及建筑/设施名称,或除了建筑/设施名称外,只有建物楼层数、面积、建成日期等统计资料者,都不算),否则不应列出。

前述“建筑”包含了校舍、运动场(含球场)、运动馆等建物,“学校设施”指其附属设施,例如校舍内的实验室、专科教室、特别教室,还有建物旁的庭园。

在学校主条目中提到建筑与各项学校设施,应当附上介绍,不要只罗列出各项建物的名称,也不要除了名称外,仅写出建物楼层数、面积、建成日期等统计资料。

--S099001留言) 2022年7月31日 (日) 13:54 (UTC)
个人认为设施的叙述还是不需要定立这么严格的要求,这些统计资料也是对读者有参考的价值。--Wpcpey留言) 2022年7月31日 (日) 14:31 (UTC)
13:54 (UTC) 更改条文的第三段,并不是说统计资料不值得写出来,而是除了这些基本资料以外,可以增加更多的叙述。主要配合前面第一段“...否则不应列出”已经要求,如果编者列出这些设施,应该也可以找到单纯统计资料以外、更多的介绍。--S099001留言) 2022年7月31日 (日) 14:48 (UTC)
参考Shizhao的意见,我个人不建议设施使用列表介绍,如果值得被记录,一定有可以用描述性语句介绍的内容。相关被介绍的内容一定有来自独立第三方来源(非第一手来源)的网页或纸本资料WP:可供查证。--Rastinition留言) 2022年8月2日 (二) 14:06 (UTC)
@Rastinition:修正如:
现行条文

建筑与各项学校设施,除非是古迹等特殊建筑,或者在可靠来源中,有介绍……,否则不应列出。

提议条文

建筑与各项学校设施,除非是古迹等特殊建筑,或者在可靠独立的第三方来源中,有介绍……,否则不应列出。

至于描述性语句,大致上如下方 2022年8月1日 (一) 07:22 (UTC) 修改版本,已经增列于草稿中,还请您检视。--S099001留言) 2022年8月3日 (三) 07:28 (UTC)
人员和设施应该强调用描述性的百科语句进行介绍,尽量不要用表格或点列的形式展现--百無一用是書生 () 2022年8月1日 (一) 03:17 (UTC)
已修改为:
现行条文

教职员、学生与校友 教职员、学生与校友,都应该只在人物本身就具备关注度,独立第三方来源提及这位人士与学校的关系时,才被列入学校条目中。

提议条文

教职员、学生与校友 教职员、学生与校友,都应该只在人物本身就具备关注度,独立第三方来源提及这位人士与学校的关系时,才被列入学校条目中。

提及这些人物时,请以叙事散文为主,尽量避免使用表格或列点。

现行条文

在学校条目中提到建筑与各项学校设施,应当附上介绍不要只罗列出各项建物的名称,也不要除了名称外,仅写出建物楼层数、面积、建成日期等统计资料。

提议条文

在学校条目中提到建筑与各项学校设施,应当附上介绍,并使用百科全书式的语调,撰写描述性质散文。尽量避免使用列点形式,只罗列出各项建物的名称,也请避免除了名称外,仅写出建物楼层数、面积、建成日期等统计资料。

--S099001留言) 2022年8月1日 (一) 07:22 (UTC)
(+)支持(!)意见:个人综合考量条目所具备之基本信息和易读性、来源可靠性、避免不断增生之过度细琐讯息,以及适当促进编者参与,支持相关修订,同时希望部分更动:
“各项学校建筑与设施,除非是古迹等特殊建筑,或者在可靠来源中具背景介绍或叙述者(不含单纯提及建筑/设施名称,或仅具建物楼层数、面积、建成日期等基本资料者),否则不应单独列出。
于条目中介绍建筑与设施相关背景资料时,应使用百科全书式的语调,撰写描述性质散文,尽量避免仅以列点形式罗列各项建物的名称。
前述“学校建筑与设施”泛指校园内之建筑物及其内含或附属之设施(包含但不限于校舍、运动场(含球场)、运动馆等建物,以及校舍内的实验室、专科教室、特别教室、建物旁的庭园等设施)。”--Kriz Ju留言) 2022年8月5日 (五) 23:40 (UTC)

谢谢您的建议,“建筑与学校设施”已经修改了,但是因为第一段还是提到了“仅具建物楼层数、面积、建成日期等基本资料者”不应列入条目中,因此还是将第二段“,也请避免除了名称外,仅写出建物楼层数、面积、建成日期等统计资料。”一句留住。至于“教职员、学生与校友”部分,独立列表似乎比条目类列出有更严格要求,因此表述为“如果满足独立列表的要求,可以另以列表收录。”具体差异见Special:Diff/73105184--S099001留言) 2022年8月7日 (日) 11:21 (UTC)

经适当讨论调整以此版本条文内容进行公示七日。--Kriz Ju留言) 2022年8月14日 (日) 18:22 (UTC)

提议规定巡查时将页面移动至草稿的规则

英文维基百科规定在一定情况下(比如条目质量严重不合标准但有可能有关注度)可以将条目“Draftify”(草稿化),在中维的存废讨论也确有一部分是这样处理的(例如Wikipedia:页面存废讨论/记录/2021/12/30#立普思),但还有一部分回退员/巡查员因把符合速删标准的条目移至草稿而引发争议(见WP:申请解除权限),所以敝人提议拟定将条目移至草稿的条件,英维的规则在en:WP:Draft,供大家参考。--QiuLiming1留言) 2022年8月2日 (二) 19:35 (UTC)

  说明:此前讨论见Wikipedia_talk:草稿命名空间/存档一#建议大修《草稿页指引》,以将“草稿化”纳入常规维护操作,当时的草案是Wikipedia:草稿命名空间/2019年更新草案#草稿化。相比之下en:WP:DRAFTIFY有更多细项规则,值得参考。(在下(+)支持订立“草稿化”指引,当然还要视乎实际条文。又:除权似乎是因将WP:G3条目草稿化,但en:WP:DRAFTIFY要“has some potential merit”,此前中文草案也要“具有发展成完整条目的潜力”,无价值的WP:G3条目仍应速删,因此指引与该次除权关系不大。)—— 留言) 2022年8月3日 (三) 12:02 (UTC)
或者和友善程度、具体执行有关?草稿的原本想法更像是让编辑自己提供可以公开编辑的草稿性质页面。条目一旦发布,就应该按照现有的规范去执行检查,如果巡查人员友善的话,可以标识完还专门说明一下哪里不符合规范,如果想做老好人的话,是可以考虑移到草稿,但如果将这个规则化下来,我认为不必要,因为上的条目空间就要考虑这个问题,也不是所有巡查都要做老好人。——Sakamotosan路过围观 | 避免做作,免敬 2022年8月4日 (四) 00:40 (UTC)
赞成翻译en:WP:DRAFTIFY之流程,但其页面也仅为流程而非方针或指引,在本地运用应仔细讨论和考量。赞成规范化,但目前运用应基于共识、“无争议”原则,出现争议时应协商共识或转入其他流程。--YFdyh000留言) 2022年8月4日 (四) 01:36 (UTC)
(!)意见:赞成翻译。综观以上站友讨论,个人补充认为页面巡查处理所仰赖之关键或仍在于具善意和效能之巡查站务经验累积和处置判断,而非相关流程本身必定足以确保效果,且若仅单纯制定各种流程规范,未获适当有效之执行,对于巡查站务长期而言亦未必明显有益;因此我认为本质上应回归是否有益于有效创建之新建页面内容改善多数巡查员行权和执行页面改善站务,进一步而言可考量是否有益于具经验的可信用户进一步投入深耕或发展页面巡查和促进社群合作相关领域
以上为个人意见,供参。--Kriz Ju留言) 2022年8月10日 (三) 21:28 (UTC)

修订编辑战方针(二)

问题背景

参见上方的修订讨论,本站现行编辑战方针在“豁免原则”的表述上存在歧义,需要修正。然而本人在为该案草拟更好的修订稿时发现,现行编辑战方针曾于2018年通过J. Wong君发起的讨论合并了原回退不过三原则中的内容。该案审议时未拟修订稿,实际执行时也仅将两方针复制至一处,而未有效整合,导致现行方针内文内容大量冗余、还存在一定的矛盾。

以“豁免原则”的表述为例,现行方针中就有两处,一则来自旧编辑战方针:

...
回退破坏不是编辑战。注意,重复张贴明显非真实的内容(例如“恶搞”语录)或重复移除大量内容常被视作破坏行径,但是正常情况下的少量不中立观点,正常的加入或删除内容,或其他善意的修改,都不应当视为破坏。(参见破坏的类型和不视作破坏的行为)。
为了维护更重要的方针而采取的回退举动不应视作编辑战。例如,依照生者传记相关方针,为了避免对当事人造成损害,有关生者的无来源负面内容如不修改,必须移除。
...

一则来自旧“回退不过三”方针:


...下述行为在适用回退不过三原则时,不视為一次回退:

回退自己的编辑(“自我回退”)。
回退在自己用户空间中的编辑,前提是你必须遵守用户页指引。
回退明显的破坏行为,即指任何一个假定他人的编辑是出于善意的用户都会认为是破坏的编辑,例如清空页面或是添加攻击性语言。
移除明显侵犯著作权,或是毫无疑义违反合理使用方针的内容。
移除明显违反维基百科服务器所在地——美国佛罗里达州法律的内容,例如儿童色情内容或盗版软件。
移除涉嫌诽谤、非中立、无来源或来源不充足,违反生者传记方针的争议材料。對於刪除何種內容可享有生者傳記方針豁免而不受回退不過三限制可能會存有爭議。遇有不清晰或有爭議,則建議先行提報至互助客棧,而非依賴前述豁免。
为了确保在首页展示的特色列表和优良条目的质量而进行的回退操作,给予用户一定的自由空间。
...

这不利于方针的阅读和执行。此外,部分不受合并影响内容也存在字句不通顺、不确切、行文逻辑不清晰等问题。现行方针第一句话“维基百科的页面都是透过社群讨论形成的”就不合乎事实。有鉴于此,本人提出了编辑战方针的修订草稿Wikipedia:编辑战/draft,其与现行方针的差异如该链接所示。具体如下:

引言

现行条文

维基百科的页面都是透过社群讨论形成的,用户需要遵循编辑守则,协力构筑共识,如果不起效果的话,应当设法解决争论并寻求帮助。如果两位或团体多位作者就一个问题无法达成协议,因此不断地互相删改或撤销对方的编辑内容时,就被称为“编辑战”。如果要提报参与编辑战的用户,请前往管理员通告板

对编辑战有一个明确原则,即“回退不过三”(3RR)原则。该原则是指编者在24小时之内,不得对同一页面进行超过三次的回退动作。回退是指撤销另一编者的编辑动作,无论每次涉及内容是否一致,违反者可能会被封禁。当然,未违反“回退不过三”原则的编辑战也可能招致封禁。

编辑战对于读者跟编辑者都是有害的行为,试图强行维持条目的某一版本,可能会造成中立性的缺失,也可能会导致用户互相敌视,阻碍共识的形成。在警告和封禁之后仍然执意进行编辑战的用户将可能永久失去对某些页面的编辑权

提议条文

编辑战是指两位以上编者就一个问题无法达成共识,因而不断地互相删改或撤销对方的编辑内容的行为。编辑战对于读者跟编辑者都有害,试图强行维持条目的某一版本,可能会造成中立性的缺失,也可能会导致编者互相敌视,阻碍共识的形成。

参与编辑战的编者应优先考虑进行沟通,设法解决争论或寻求其他编者帮助,否则可能遭暂时或永久剥夺部分全部页面的编辑权。处置编辑战时有一条界限供参考,即“回退不过三”(3RR)原则。该原则指出,编者在24小时之内,不得对同一页面进行超过三次的回退动作。该原则不应理解为回退频次上的合法配额;未违反“回退不过三”原则的编辑战参与者并不必然豁免管理措施。

管理员处置编辑战的基本原则是避免、制止争议行为,鼓励理性编辑,而非惩罚参与者。其它编者可通过管理员通告板提报编辑战的参与者。

  • 如同条目引言一样,方针的引言应当具有概括性。现行方针在该部分过多地交待了非必要的背景信息,却未能概括“管理员指引”中的内容。修订后本人删除了相应的背景信息,直接开宗明义地定义了“什么是编辑战”,并补充了“管理员指引”章节的内容。此外,“可能会被封禁”、“可能招致封禁”措辞调整为“暂时或永久剥夺部分全部页面的编辑权”,指明封禁和禁制均为可选项。

--Antigng留言) 2022年8月5日 (五) 13:57 (UTC)

什么是编辑战

现行条文

作为维基百科的一个核心理念,开放的系统可以产生高质量、中立的百科内容。但是不可避免的是,用户针对页面内容的某些方面会有不同的观点。当此类情况发生时,强烈建议编者透过文明的讨论达成共识,而不是在明知会招致反对时仍然固执己见,采取挑衅性的编辑行为,并且反复使用回退功能。后者称为编辑战

并非所有潜在的争议编辑行为,或是回退举动,都会被指为编辑战。应当注意以下的情形:

  • 维基百科鼓励编者勇于更新页面。一个潜在争议更改可能只是为了检测是否有反对声音,并开启讨论的手段。如果另一用户有充足的理由反对此项更改,他们可以采取回退行动。这就是所谓的更新,回退,讨论(BRD)循环,而非编辑战。只有在出现一系列非建设性,反复的编辑行为时,才构成编辑战。
  • 回退破坏不是编辑战。注意,重复张贴明显非真实的内容(例如“恶搞”语录)或重复移除大量内容常被视作破坏行径,但是正常情况下的少量不中立观点,正常的加入或删除内容,或其他善意的修改,都不应当视为破坏。(参见破坏的类型不视作破坏的行为)。
  • 为了维护更重要的方针而采取的回退举动不应视作编辑战。例如,依照生者传记相关方针,为了避免对当事人造成损害,有关生者的无来源负面内容如不修改,必须移除。

如果回退了他人的修改,请确保在编辑摘要中或讨论页中指明缘由(原因显而易见除外,例如回退破坏)。未给出适当理由的回退行为很有可能被理解为是挑衅。谨记回退操作是把其他编者的工作“丢到一旁”;或许你应当考虑改善文本质量,或是与其他编者进行沟通,而不是简单的撤销更改。

请牢记,例如TwinkleHuggle回退功能之类的反破坏工具不宜用来撤销有关条目内容的善意修改。

提议条文

维基百科的一项核心理念在于通过公众可参与的平台产出高质量、中立的百科内容。由此不可避免的是,不同编者针对页面内容的某些方面会有不同的观点。当此类情况发生时,编者应透过文明的讨论达成共识,而不是反复撤销他人的编辑,尤其是在明知会招致反对时故意而为,以示挑衅。后者称为编辑战

本方针范围内如无特别说明,“回退”一词均指任何在客观上撤消或部分撤消其他编者行动的编辑行为(或管理行为),不限于使用系统或工具(如Twinkle)提供的回退功能执行的操作。

本方针并非旨在消除所有具有潜在争议的编辑行为乃至回退举动。相反,本站鼓励编者大胆更新页面。某名编者进行编辑后,如有另一编者因充足的理由而反对此项更改,他完全可以采取回退行动,并展开沟通化解问题。这就是所谓的更新,回退,讨论(BRD)循环。这种良性循环并非编辑战。只有在出现一系列非建设性,反复的回退行为时,才构成编辑战。

例外 此外,下列回退行为即使反复发生,也不应纳入编辑战的考量:

  • 回退自己账户的编辑(“自我回退”)。
  • 回退在自己用户空间中的编辑,前提是您必须遵守用户页指引。
  • 回退明显的破坏行为,即指任何一个假定他人的编辑是出于善意的编者都会认为是破坏的编辑(例如无故清空页面、重复张贴明显非真实的内容、屡次添加攻击谩骂文字等)。但是正常情况下的少量不中立观点,正常地加入或删除内容,或其他善意的修改,都不应当视为破坏。(参见破坏的类型不视作破坏的行为)。
  • 为了维护更重要的方针,特别是法律相关方针,而采取的回退举动。例如,移除明显违反本站著作权方针、儿童色情、非主动公开的个人资料等涉嫌违反维基媒体服务器所在地法律的内容。移除明显违反生者传记方针的内容的回退(例如移除关于在世人物涉嫌诽谤、非中立、无来源或来源不充足的争议内容)也适用本条。但对于删除何种内容可享有生者传记方针豁免本身可能会存有争议。遇有不清晰或有争议,建议不要依赖此豁免。
  • 为了确保在首页展示的典范条目优良条目的质量而进行的回退操作,给予编者一定的自由空间。
  • 本章节合并了现行方针3RR部分的豁免原则,并将其另立为子章节“例外”加以阐述。在合并时,例外原则的措辞有一定调整:
    1. “回退自己的编辑”修改为“回退自己账户的编辑”:显然回退自己的合法分身帐户(例如机器人帐户)的编辑不应纳入编辑战的考量,故有此修改。
    2. “维护更重要的方针”“而采取的回退行动”补充说明“特别是法律相关方针”:列举的“受豁免”方针实质上均是本站的法律方针,故有此澄清。
    3. “移除涉嫌诽谤、非中立、无来源或来源不充足,违反生者传记方针的争议材料”调整措辞并入上一条:解决前一案的问题
  • 同时,本章节也合并了现行方针中,所有涉及“回退的定义”的内容,将其另立章节加以交待:“本方针范围内如无特别说明,‘回退’一词均指任何在客观上撤消或部分撤消其他编者行动的编辑行为(或管理行为),不限于使用系统或工具(如Twinkle)提供的回退功能执行的操作。”
  • 此外还有一些措辞方面的细微调整。

--Antigng留言) 2022年8月5日 (五) 13:57 (UTC)

编辑战的处理

现行条文

参与编辑战的用户很可能(通常在编辑战发生后)被封禁,以防止进一步的争端。尽管所有的编辑战行为都有可能导致此种处理,但有一条常用作封禁的明确界线——称作“回退不过三”(3RR)的原则。具体内容如下:

“回退不过三”原则

根据“回退不过三”原则:

一个“页面”意指维基百科上的所有页面,包括讨论页和计划空间。

这里提到的一次“回退”是指任何取消其他用户行动的编辑行为(或管理行为),无论是全页面还是部分内容。可能有的时候只是一个词的变动。在没有其他用户编辑的情况下,一个用户连续的一系列回退编辑视作一次回退。下述行为在适用回退不过三原则时,不视为一次回退:

  • 回退自己的编辑(“自我回退”)。
  • 回退在自己用户空间中的编辑,前提是你必须遵守用户页指引。
  • 回退明显的破坏行为,即指任何一个假定他人的编辑是出于善意的用户都会认为是破坏的编辑,例如清空页面或是添加攻击性语言。
  • 移除明显侵犯著作权,或是毫无疑义违反合理使用方针的内容。
  • 移除明显违反维基百科服务器所在地——美国佛罗里达州法律的内容,例如儿童色情内容或盗版软件。
  • 移除涉嫌诽谤、非中立、无来源或来源不充足,违反生者传记方针的争议材料。对于删除何种内容可享有生者传记方针豁免而不受回退不过三限制可能会存有争议。遇有不清晰或有争议,则建议先行提报至互助客栈,而非依赖前述豁免。
  • 为了确保在首页展示的典范条目优良条目的质量而进行的回退操作,给予用户一定的自由空间。

如果你认为自己的行为属于上述例外,请确保留下明确的编辑摘要或在讨论页的单独分段中阐明例外的原因。如果没有把握,请不要回退。可以代之以尝试解决争论,或者还可以针对特定的问题,前往相应的通告板求助,例如当前的编辑争议提报页面

如果出现四次或更多次的回退,无论每次针对的是否是同一段内容,都构成违反“回退不过三”原则。该原则按人计算,不按编辑次数计算;由多重帐号所做的回退按同一人计算。

初犯该方针的用户通常会被封禁24个小时。

切记管理员可能在任何时间,对他们认为构成进行编辑战的用户采取行动。即使在未违反回退不过三原则时,任何用户也都可以提报编辑战。该原则并不是给回退页面一个特定数量的配额

如果编者无心违反了“回退不过三”的原则,他们应当撤销自己最近的回退行为。例如,某个用户并不是经常性引起争端的编者,并且真诚的希望纠正自己的过失,管理员就可以将此考虑在内,并决定此种情况不再予以封禁。

其他回退规则

针对特定编者和/或特定页面,有时社群(参见Wikipedia:编辑禁制方针)会对其采取额外的回退限制。可能会用诸如1RR(回退不过一)或者0RR(回退零容忍)等术语指代这样的规则。“回退不过一”类似于上面所说的回退不过三,但是“多于一次回退”取代了原来规则中的“多于三次回退”。“回退零容忍”是指完全禁止进行回退操作(这其实是回退不过三原则的初衷)。

有时,编者会志愿执行更为严格的回退准则,或者是为了应对某一领域的问题,或者是作为自己的一种编辑哲学。详情参见Wikipedia:仅在必要时进行回退

提议条文

参与编辑战的编者很可能因编辑战而被剥夺编辑权限,以防止进一步的争端。尽管所有的编辑战行为都有可能导致此种处理,但有一条常用作判断的明确界线——称作“回退不过三”(3RR)的原则。具体内容如下:

“回退不过三”原则