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

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

發表前請先搜索存档，參考舊討論中的内容可節省您的時間。

公告欄

• [人事] Manchiu、UjuiUjuMandan、ASid、ATannedBurger获提名为管理员，AT获提名为监督员，欢迎踊跃参与提问和讨论。
• [公告] 互助客栈正在对于Unblock-zh.org试运行征求意见。
• [公告] 修改模板:No source及修訂維基百科不是維基物種已經通過。
• [公告] 再擬議立國際關係命名常規為方針、关于{{Death}}和{{Deceased Wikipedian}}文案调整的方案及規範討論發起步驟正在公示，如有意見請儘快提出。
• [討論] 互助客栈方针区正在討論修改RFA流程相關規定，請踴躍參與討論。
• [討論] 互助客栈技术区正在討論ToolsRedirect创建的繁簡重定向問題，請踴躍參與討論。
• [討論] 互助客栈条目探讨区正在討論Rightmost模板與Str rightc模板重複的問題，請踴躍參與討論。
• [討論] 互助客栈其他区正在討論对新闻动态获选标准及ITNR规则的小修订及頁面評級與通用評級行政層面上的統合方案，請踴躍參與討論。
• [廣告] 第二十二次動員令現正徵求主題及主持人中，另舉辦時間公示至5月21日，歡迎踴躍參與！

• [協作] 现有126个页面需维基化，276个条目需清理，37个移动请求正在讨论。
• [獎勵] 現有3名用户獲提名维基奖励，欢迎投票。

#	💭 話題	💬	👥	🙋 最新發言	🕒 (UTC+8)
1	提議提高條目評選投票資格門檻	1	1	Sanmosa	2024-05-14 19:00
2	再擬議立國際關係命名常規為方針	52	11	Sanmosa	2024-05-20 13:10
3	修订删除方针明确允许删除没有来源30日以上的条目	1	1	Jimmy-bot	2024-05-20 00:14
4	提議英維指引en: MOS:TVINTL經本地化後引入中維維基百科:格式手冊/電視	81	9	HK5201314	2024-05-20 09:37
5	提议：允许使用开放代理编辑WP:RFR，并在WP:RFR中加入“注册账号申请”	1	1	Sanmosa	2024-05-14 19:01
6	提议：对WP:日常计算做小修改	1	1	Sanmosa	2024-05-14 23:49
7	提议对中国大陆的文物保护单位设立关注度豁免	1	1	Sanmosa	2024-05-14 23:01
8	附带有限追踪检查的无IP的IPBE	13	8	Bluedeck	2024-05-17 17:01
9	关于国籍的原创研究	19	7	Ericliu1912	2024-05-14 01:04
10	关于跨行政区域的实体，是否应该使用多个分类	15	6	克勞棣	2024-05-15 01:00
11	必須防止濫用「防濫用過濾器」	17	12	2603...8171:3A9	2024-05-19 10:53
12	提議外部連結指引WP:ELNO同時編入WP:可供查證。	14	4	HK5201314	2024-05-18 15:47
13	把会让人产生不适感的图片做一层遮掩与提示怎么样？	11	5	世界解放者	2024-05-19 08:45
14	修改RFA流程相關規定	4	3	CopperSulfate	2024-05-20 14:50
15	關於WP:CTOP/BLP方針	3	3	Kethyga	2024-05-20 13:20

發言更新圖例
最近一小時內
最近一日內
一週內
一個月內
逾一個月
特殊狀態
已移動至其他頁面 或完成討論之議題
手動設定
當列表出現異常時， 請先檢查設定是否有誤

正在廣泛徵求意見的議題

以下討論需要社群廣泛關注：（重新整理）

維基百科格式與命名

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

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

維基百科方針與指引

Wikipedia talk:共识 § 共識建立的遞進步驟

此討論正在公示7天，直至2024年5月25日 (六) 02:45 (UTC)結束；如有意見請儘快提出。

推行RFC後，我發現很多人沒理會非強制性的提示，導致WP:VPD持續過長。我提議調整方針，明確共識建立的遞進步驟，確保各討論頁獲得善用。--路西法人 2024年4月8日 (一) 09:58 (UTC)

Wikipedia talk:關注度 (文化遺產) § 提议对中国大陆的文物保护单位设立关注度豁免

如题。--——— 红渡厨（留言・贡献） 2024年5月10日 (五) 06:05 (UTC)

Wikipedia talk:关注度 (地理特征) § 建議將地理特徵關注度指引中有關道路的部分改為在交通關注度指引中列出

如題，我一直以來都感覺道路與地理特徵關注度指引中其他的被規範對象的性質比較不同，因此我尋思著應該把道路相關的規定移到交通關注度指引比較好，於是趁著現在有時間提起此事了。具體的做法是WP:關注度 (交通)#道路現有的內容由WP:关注度 (地理特征)#道路現有的內容取代，WP:关注度 (地理特征)#道路全節刪去。Sanmosa _{全方貧工之聯合} 2024年5月14日 (二) 10:25 (UTC)

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

此討論意在修訂既有WP:日常计算的規定。Sanmosa _{全方貧工之聯合} 2024年5月14日 (二) 15:50 (UTC)

維基百科提議

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

接續上段，繼續提請討論仲裁委員會的執行細節。目前討論中的範疇包括：

• 授予權限：向仲裁委員會授予什麼權限？
• 權限限制：如何限制仲裁員在委員會職務以外使用權限？
• 選舉信任度下限：目前以50%為最低可當選門檻，是否有需要調高？
• 管理人員解任處理：管理人員解任在多大程度由仲裁委員會處理？
• 其他準備工作：包含相關頁面籌備與部署、技術問題及其他需要處理之事項。

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

Wikipedia talk:字詞轉換處理/公共轉換組 § 思路：條目預儲公共轉換組中匹配的規則，減少載入時間

近年有些公共轉換組越來越大，導致所嵌入的各條目等頁面_{（爲便説明下稱「條目」但不限於條目）}載入越來越慢，爲人詬病。而若條目預先儲存公共轉換組中與條目中字詞相匹配的轉換規則，並適時更新：— Gohan 2024年3月12日 (二) 05:00 (UTC)

Template talk:Twitter § Twitter改為X

因應Twitter已改名X一段時間了，因此提請討論是否做相應更改。臺灣杉在此發言 (會客室) 2024年4月18日 (四) 04:10 (UTC)

Wikipedia:互助客栈/其他 § 对ITN获选标准及ITNR的小修订

此前的相关讨论：

• 建议修改新闻动态发表程序
• 建立ITN获选标准门槛

---

最近Wikipedia:新闻动态候选出了一些问题：

第一，在社群讨论没有得出支持刊登的情况，管理员自行刊登内容，如Wikipedia:新闻动态候选/存档/2024年3月#亚伦·布什内尔自焚事件；

第二，部分内容在刊登之前没有收到反对意见，刊出之后被质疑关注度或重大性不够，如Wikipedia:新闻动态候选/存档/2024年4月#習馬二會；

第三，涉及中国载人航天工程的条目近期在提名时多被社群以不具备突破性为由反对，见Wikipedia:新闻动态候选/存档/2022年6月#神舟十四号、Wikipedia:新闻动态候选/存档/2023年6月#神舟十六号、Wikipedia:新闻动态候选/存档/2023年10月#神舟十七号和Wikipedia:新闻动态候选#神舟十八号。

针对以上的第一条及第二条问题，提案对现行的ITN获选标准作出如下修订：

現行條文 管理员在每次更新栏目时，应当查看新闻动态候选区内所有提案。管理员认为提案符合新闻动态候选标准的，应予采纳；不符合候选标准的，应由管理员陈述意见后退回重审。有二名及以上维基人提出反对意见的，亦应当退回重审。

提議條文 管理员在每次更新栏目时，应当查看新闻动态候选区内所有提案。管理员认为提案符合新闻动态候选标准，或支持刊登的意见占大多数的，应予采纳；不符合候选标准的，应由管理员陈述意见后退回重审。有二名及以上维基人提出反对意见的，亦应当退回重审。 对于刊登之后出现反对意见提案，管理员应暂时移除相关内容，直至社群得到支持刊登的共识。对于没有得到绝对结论的提案，需要有二名及以上的管理员进行商讨，以最终决定是否刊登。 提案新闻内容涉及需要地区词转换的用字，提案人需要先自行处理。

针对以上的第三条问题，提案对现行的WP:ITNR作出如下修订：

現行條文 载人轨道航天器的发射升空；一个国家首次成功完成自主发展的轨道发射；发射空间站或其主要组成部分；航天器抵达月球或更远的目的地；重大航天任务失败

提議條文 每款载人轨道航天器首次发射升空；每款载人轨道航天器與特定空间站首次成功對接；一个国家首次成功完成自主发展的轨道发射；发射空间站或其主要组成部分；航天器抵达月球或更远的目的地；重大航天任务失败

---

正如WP:NOTNEWS所说，维基百科不是新闻报道。新闻动态候选和Portal:新闻动态设立的初衷也不是为了提供新闻报道，“是为了鼓励增订或更新相关的条目，而不是用作新闻报道”。由此可见，社群应该从百科性的角度来提报及衡量新闻动态条目，一些不具备百科性的条目能不提报就不提报，能不刊登就尽量不刊登，毕竟“维基百科不是新闻报道”。所以，新闻动态的标准也尽量严谨。上述的修改意见只不过是抛砖引玉，欢迎社群在此提案的基础上踊跃讨论。--Jeffchu2014（留言） 2024年4月28日 (日) 17:08 (UTC)

Template talk:Hang on § {{hangon}}

Template:Db-meta的格式在之前的討論中，無法解決标记提速删页面上的速删状态；如果用機器人的方式來處理，是否可行？臺灣杉在此發言 (會客室) 2024年4月30日 (二) 08:33 (UTC)

提議新建交通車輛條目內容指引2

本指引為交通車輛條目內容指引，由各專業領域的維基達成的條目編寫共識。相似元素有助於閱讀及編輯維護上的便利性，以及減少特定章節的編輯戰，目的是提供編者符合編輯格式參考指引。果您有想法或疑問，請在討論頁面進行討論。除此之外，您還應該熟悉更優秀條目寫作指南。

行文結構 本節介紹了幾類條目的大綱，實際條目的分節方式和標題無需完全對應下文。若您的條目有特殊之處，請放手調整，不必拘泥於本文。

鐵路車輛

• 導言：簡述車輛所屬的鐵路公司、製造商、服務路線、投入服務日期等，並精要概括正文。
• 資訊框：一般用用{{鐵路車輛}}，亦可使用{{鐵路車輛2}}。模版應照文檔填寫。
• 概要：介紹車輛引進緣由、役緣由（如已除役之車輛）、基本概述等。
• 規格與構造：介紹車輛基本構造、機電設備、外觀塗裝、設備規格、編組方式等。
• 各代車輛：若車輛型號生產不只一代或子型號，依照各代不同之處進行介紹。
• 重大事故：若車輛曾經發生過重大鐵路事故可初步簡述事故經過，並使用{{main}}作主條目導向。
• 車輛保存：若車輛已退役，並且公開保存，針對保存位置以及緣由進行介紹。
• 相關條目：與條目相關的車型或車種可於此列出。
• 參考文獻：請列明來源！報章雜誌、鐵路公司官網的車輛簡介、車輛製造商的車輛簡介與政府出國報告書都是好的來源。切記，不可使用部落格與營運單位的內部文件作為來源。
• 外部連結：可連接其他維基計畫或是未達可靠來源門檻的百科性資源。

客運/公車車輛

• 導言：簡述車輛製造商、車輛類型等，並精要概括正文。
• 資訊框：一般用{{Infobox Automobile}}。模版應照文檔填寫。
• 概要：介紹車輛引進緣由、退役緣由（如已除役之車輛）、基本概述等。
• 規格與構造：介紹車輛基本構造、設備規格等。
• 各代車輛：若車輛型號生產不只一代，依照各代不同之處進行介紹。
• 重大事故：若車輛曾經發生過重大交通事故可初步簡述事故經過，並使用{{main}}作主條目導向。
• 車輛保存：若車輛已退役，並且公開保存，針對保存位置以及緣由進行介紹。
• 相關條目：與條目相關的車型或車種可於此列出。
• 參考文獻：請列明來源！
• 外部連結：可連接其他維基計畫或是未達可靠來源門檻的百科性資源。

條目內容 不合適的內容

1. 愛好者內容：
   • 鐵路車輛：請不要將車輛車次運用、車號機務段分配、改造期程、交車期程等瑣碎資訊加入條目內。
   • 客運/公車車輛：請勿將領牌車號、行駛路線、停靠站牌等瑣碎資訊加入條目內。

   依據：維基百科不是不經篩選的資訊收集處－說明書

2. 大量的短條目：通常一個較大的條目能提供對主題更有條理的介紹與背景聯繫。當大條目能做到時，請不要創建大量小條目。理想的條目是既不過大，也不過小。

   依據：維基百科的條目大小指引

3. 過多的圖片：請勿於條目內放置各車號的照片，於資訊框模板一張代表即可，其他照片則放入共享資源並於底下納入共享資源連結導引。
4. 原創研究內容：原創研究內容建議寫在維基學院內。

   依據：非原創研究

備註

因討論被機器人存檔，且尚未完成討論故接續提案，部分內容已依照上次討論提議更新--🚊。鐵路Railway ^論 2022年2月20日 (日) 05:24 (UTC)

• 這邊邀請上次有參與的維基人接續討論@心平星辰、owennson、BIT0865、Bus Follower、一片楓葉、Ghrenghren、SickManWP、Mys_721tx、Nrya、LuciferianThomas--🚊。鐵路Railway ^論 2022年2月20日 (日) 05:32 (UTC)

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

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

@Nrya：閣下的意思是再額外建立關注度方針、於此方針中加入還是於NT:T中加入？--🚊。鐵路Railway ^論 2022年2月21日 (一) 13:26 (UTC)

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

@BIT0865：噢....若將「檔案」更換成「公文」呢？呢因為臺灣的車輛條目經常出現使用短期且快速更新的內部資料編輯愛好者內容，當初使用檔案一詞是為了阻止此狀況，而這些引用屬公文電報，更改引述應該可行吧0.0--🚊。鐵路Railway ^論 2022年2月21日 (一) 14:08 (UTC)

內部文件關鍵應該是非公開的文件。公開文件是沒問題的，這種文件應該是可以網站找到，或者圖書館可以找到的，而不是那種要愛好者拍一次，再上傳才可以找到的的文獻。「武汉轨道交通一号线一期工程车辆使用维护说明书」這種文件雖然是官方的，但是理論上不外傳的吧，這樣的話其實不應該用。--Ghren🐦🕑 2022年2月22日 (二) 06:11 (UTC)

協助標註@BIT0865--🚊。鐵路Railway ^論 2022年2月23日 (三) 10:30 (UTC)

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

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

@BIT0865：若逆向搜索能搜索到可靠來源則直接使用新的可靠來源，應該很多東西都是逆向搜索找到正確的參考資料，不一定要以照片為唯一來源--🚊。鐵路Railway ^論 2022年2月23日 (三) 14:57 (UTC)

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

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

大致(＋)支持相關方針改動。很抱歉由於健康問題（右眼失明）本人不太有時間參與相關方針的建設。--SickManWP_{邀請您加入❤️邊緣人小組·🖊️簽到} 2022年2月21日 (一) 15:18 (UTC)

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

(＋)支持：支持另建方針。呈上，如果中國大陸境內有此情況，那可能就採取共用大架構，另立小特別款？畢竟台灣這端出現在拿未確定是否可公開外流的台鐵內部行車電報來放此舉應不妥；圖片部分車號是指大的編組，舉例以言之，TEMU1000型全編8輛，放這8輛圖片可，但每一編組（TEMU1001+1002～1015+1016）均放或可議，畢竟適量的放圖片有助於閱讀跟版面配置，其他放共享資源；車輛車次運用、車號機務段分配、改造期程、交車期程等這些就放入學院吧，維基是阻止不了的，那就面對現實導入比較可行的維基學院吧，以上相關資源則在條目內設連結引導。消波塊（留言） 2022年2月22日 (二) 01:47 (UTC)

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

@BIT0865：關於第二點據在下所知有《鐵道知識》期刊，國際標準書號為ISSN 1000-0372，如北京地铁DKZ13型电动车组剛剛在下已協助增加來源。--🚊。鐵路Railway ^論 2022年2月23日 (三) 13:16 (UTC)

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

@BIT0865：若是反向搜索來源應該可以吧...知道型號和廠牌之後去製造商官網找相關資料。--🚊。鐵路Railway ^論 2022年2月23日 (三) 14:07 (UTC)

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

@BIT0865：若查無可靠來源算原創研究，可能要改寫到維基學院了。--🚊。鐵路Railway ^論 2022年2月26日 (六) 07:39 (UTC)

補充：回復上面，問員工也算原創研究--🚊。鐵路Railway ^論 2022年2月26日 (六) 10:02 (UTC)

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

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

@BIT0865：若真的沒辦法符合維基方針的內容就移至維基學院吧…，臺灣近期也是有很多內容移到學院。這種找不到來源的資訊，臺灣條目也有遇過，現在大部分都移到學院了。--🚊。鐵路Railway ^論 2022年2月26日 (六) 16:53 (UTC)

現在主要討論的是條目的整體架構，若整個條目或是部分內容都沒有適合的來源，就如上的方法解決吧…0.0

這邊邀請上面同樣有回覆此問題的@Ghrenghren一起討論。--🚊。鐵路Railway ^論 2022年2月26日 (六) 17:05 (UTC)

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

(＋)支持，但應為內容指引級別而非方針級別，關注度同。--路西法人𖤐 2022年2月22日 (二) 10:45 (UTC)

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

---

🕗 公示7日，2022年3月13日 (日) 07:52 (UTC) 結束：贊成者多數，且7日無新留言，進入公示期。--🚊。鐵路Railway ^論 2022年3月6日 (日) 07:52 (UTC)

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

有些部落格的內容其實不錯且有公信力（例如[1]），不能當成來源有點可惜。--Poem（留言） 2022年3月6日 (日) 15:15 (UTC)

🕗 暫停公示：公示期間有新提議，故暫停公示並進行討論。--🚊。鐵路Railway ^論 2022年3月6日 (日) 16:33 (UTC)

暫時來說比較半吊子，觀望下。--Ghren🐦🕐 2022年3月7日 (一) 05:32 (UTC)

@Ghrenghren：雖然目前尚未很完全，因鐵路條目近期較混亂，在下的想法是將最大宗的共同問題先行初步整頓，預計後面還會再提出其他車輛或細項，希望在台鐵的新車交車前先有個指引約束內容，避免與EMU900、EMU3000條目一樣混亂。--🚊。鐵路Railway ^論 2022年3月7日 (一) 14:47 (UTC)

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

---

且慢。抱歉有點久沒有登入維基百科。重點，本人想針對客運/公車車輛做些修正：

1. 關於草案上文中的使用「資訊框」部分，若草案真的實行，代表舊有的翻掀式資訊需全部打掉重練。則請問是由何君來實施全臺近百家客運業者的條目整理呢？或是維持現狀？
2. 再者，本人找到了關於公車客運使用車種的可靠參考來源（ https://www.mvdis.gov.tw/m3-emv-mk3/freeway/query ），行政院交通部公路總局的"公路客運公司列表"，應該可行吧？以屏東客運為例，則該客運的使用車種依據為此（ https://www.mvdis.gov.tw/m3-emv-mk3/freeway/query?method=queryCarDetailByDisplaytag#anchor ），若此方案可行，本人可協助補充於各客運上。
3. 移動到維基學院的問題：本人發現@鐵路君最近移動了一些客運的使用車種，但本人看見的是許多紅連，覺得跟維基百科的相互連結有大落差。

最後：可否請@鐵路1延後公示時間？ -- Bus Follower（留言） 2022年3月6日 (日) 15:42 (UTC)

Bus Follower君留言連結是公開資料，且來源為政府機關，是可靠來源。Poem（留言） 2022年3月6日 (日) 16:09 (UTC)

@Bus Follower：1.翻頁式排版不易閱讀，且不符合維基基礎格式應盡量改善，可參見第三點的存廢討論紀錄。2.雖然閣下提供的參考來源為政府機關之可靠來源，但是車牌號碼實屬瑣碎資訊與愛好者內容，非愛好者並不會想要知道車號，另外在下建立主要是針對Category:巴士型號分類中的條目。3.使用車種在下查了編輯紀錄，在下僅移動豐原客運的內容，豐原客運的鏈結剛才以修整，而使用車種應該要使用表格式而非折疊式列表，且內容過於瑣碎，請參見Wikipedia:頁面存廢討論/記錄/2021/09/05#國光客運使用車種之討討論紀錄。--🚊。鐵路Railway ^論 2022年3月7日 (一) 14:37 (UTC)

了解，本人一看討論就知道大部分用戶對這塊是不怎麽友善的...不過君的意思應該是不要把使用/歷史車種寫在維基百科上，而是改寫至維基學院，對吧？如果是這樣的話，本人可以接受。也辛苦君對豐客的整理。但是關於什麼改成表格的部分，本人覺得還是先照舊吧...雖然舊的"畸形"式折疊式列表已不建議寫在維基百科上，但還是回到原點，若由君自己更新全台客運業的條目應該有困難吧

順帶一提，有看見君想要整理Category:巴士型號的分類，不過可笑的是，台灣最常見的DAEWOO BS120CN低底盤公車條目竟然被刪除了。本人發現只要有關於「公車」的條目幾乎都被提刪，不知道這種風氣在流行什麼，且刪除的原因都是什麼關注度不足的鬼，但事實上這些公車都滿街跑，怎麼會「關注度不足」？真是感到失望。當然這不是鐵路君的錯，關於其他編者的舊有固執思念，嗯。應該永遠也不會改吧，哈哈... --Bus Follower（留言） 2022年3月9日 (三) 13:55 (UTC)

@Bus Follower：在下雖未找到提刪的討論紀錄或日誌，但從鏡像網頁的相關條目所看到的排版除了排版不符合編輯手冊，另外車輛介紹完全沒有列出任何參考文獻，若被關注度刪除據在下所知另外可能就是查無相關文獻或未提供相關文獻。在下主編的是鐵路相關的條目，公車的條目很不熟悉，也很難幫忙改善0ω0--🚊。鐵路Railway ^論 2022年3月10日 (四) 16:18 (UTC)

Wikipedia:頁面存廢討論/記錄/2021/07/23#大宇BS120CN。--Ghren🐦🕛 2022年3月10日 (四) 16:28 (UTC)

---

鐵路1（讨论 | 貢獻） ：

你好，不知道為什麼，最近才看到這個討論。作為一個大規模刪減香港巴士路線條目的編輯員（詳見九龍巴士1-30號所有路線），看到這篇討論後，發現有超過50%內容可以刪減，包括行車路線、車站、用車限制（因涉及ABc綜合）、車牌，對嗎？

這樣刪減的話還有什麼可以表述？--HK5201314（留言） 2022年3月9日 (三) 01:04 (UTC)

鐵路1（讨论 | 貢獻）：

順帶一提，早前可靠來源佈告版已將一個經常被引用的香港巴士愛好者網站列入防濫用保護器內，限制編輯者引用，不知你會不會提出更多網站供限制？--HK5201314（留言） 2022年3月9日 (三) 01:17 (UTC)

在維基百科內找不到公共交通總方針，只找到交通車輛方針，請問這里會不會跟進公共交通總方針（如車站、路線、車型）？--HK5201314（留言） 2022年3月9日 (三) 01:36 (UTC)

個人認為香港巴士的情況與海外有非常大的差別，車型是非常多元化（特別是1990年代至2010年代初），也可以證明路線歷史的變遷。如果要強硬刪除的話，個人認為有關條目失去了應有的意義。感覺中維對“瑣碎資訊與愛好者內容”的定義無限放大，並不是好事。--Wpcpey（留言） 2022年3月9日 (三) 01:45 (UTC)

@Wpcpey：路線、車站可參見NT:T指引，用車若車型不多可參見環狀線 (台北捷運)#電聯車的方式，若車型較多可參見橫須賀線#使用車輛，在路線條目中列出車型與簡介，詳細介紹則再另外的主條目進行介紹。另外，此指引主要是針對車輛，路線已有NT:T，在路線的條目中羅列停靠站還算正常，但是再車輛的條目再次出現行駛路線的車站就顯得過於重複，用車可稍微提及行駛路線與路線簡介，但不篇幅不要太長，不然就變成不是介紹車輛而是介紹路線，車牌號碼的部分，除愛好者外，一般民眾不太會去注意，且車牌號碼只要轉讓/轉手可能就又會更換一組號碼，屬不穩定的資訊，原創研究的內容應寫到維基學院，不是百科。--🚊。鐵路Railway ^論 2022年3月9日 (三) 05:44 (UTC)

對於我來說，其實不是有特別多的可靠來源記載一個路線的用車變遷。香港來說其實來來去去都是那幾本巴士書而己，實際使用可以記載車型使用的巴士路線實際上就不多，沒必要加上這條規定。列出簡介應該沒有問題的，只要不將車型過於陳述和原創研究就沒問題了。--Ghren🐦🕚 2022年3月10日 (四) 15:04 (UTC)

@Ghrenghren：：但最大的問題是，用戶HK5201314仍然認為“用車變遷”是愛好者內容而刪除。加上目前的環境，會有人花時間查看巴士書再記載車型使用嗎？而那幾本巴士書是在2000年代初出版，之後又有一段空白期。而路線使用的車輛也可以反映人口，地理環境和需求情況。香港的巴士路線用車情況不能夠與其他地方比較的。--Wpcpey（留言） 2022年3月26日 (六) 14:09 (UTC)

---

🕗 延長公示7日，2022年3月21日 (一) 04:12 (UTC) 結束：經討論後新提議有其他方式可替代，故延長公示。--🚊。鐵路Railway ^論 2022年3月14日 (一) 04:12 (UTC)

• @鐵路1：「客運/公車車輛：請勿將領牌車號、行駛路線、停靠站牌等瑣碎資訊加入條目內」，單是一個汽車車型的條目不會無故有「停靠站牌」這資訊吧。Fran·1001·hk 2022年3月16日 (三) 08:31 (UTC)

  @‪Fran1001hk‬：幾個月以前在下是曾經看過有車型條目內還羅列停靠站牌0.0--🚊。鐵路Railway ^論 2022年3月16日 (三) 09:02 (UTC)

• 且慢。抱歉有點久沒有登入維基百科。重點，的士也是一種公共客運，但是使用車種如豐田Hiace、馬自達6等根本不可能依照這個架構去寫，這個指引未有考慮到私人和公共客運兩棲車種的情況。--Maccomcre（留言） 2022年3月20日 (日) 23:34 (UTC)

  @Maccomcre：由於計程車與一般私家汽車使用車型相同，關於汽車稍後會有另一波的提議，目前正在準備中。--🚊。鐵路Railway ^論 2022年3月21日 (一) 12:12 (UTC)

  不同意這樣區分，巴士和的士都可能用上私家車型，而且像是豐田Coaster巴士車型都不應該是這種架構。--Maccomcre（留言） 2022年3月28日 (一) 07:53 (UTC)

  @Maccomcre：若以載客量區分，大客車適用巴士，小客車、計程車以汽車為主呢？--🚊。鐵路Railway ^論 2022年3月31日 (四) 03:07 (UTC)

  補充：在下主編鐵路相關條目，客運、計程車不是很熟悉，若閣下有跟更適合的指引條文，還請直接提出，感謝。(•‿•)--🚊。鐵路Railway ^論 2022年3月31日 (四) 03:31 (UTC)

  不同意以載客量區分，像是VDL DB300的大巴其實跟豐田Coaster的小巴的模式相似。而且VDL DB300這種大巴士車型都不應該是這種架構。--Maccomcre（留言） 2022年4月6日 (三) 23:41 (UTC)

  @Maccomcre：還請閣下提出條文，在下已想不到如何修改條文，公車條目在下不在行。--🚊。鐵路Railway ^論 2022年4月7日 (四) 03:16 (UTC)

  就以臺灣的法律來看，是以載客量區分車輛類型，不分客運用還是計程車用。--🚊。鐵路Railway ^論 2022年4月7日 (四) 03:19 (UTC)

User:鐵路1，有個小問題，類似香港小巴這種型式的交通會否納入？又，渡輪船隻飛機直升機之類交通可否納入？--owennson（聊天室、獎座櫃） 2022年3月22日 (二) 06:16 (UTC)

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

User:鐵路1，個人對地鐵使用車輛內容直接放入路線條目有異議，畢竟有可能出現幾條地鐵線共用同一個車型。而且搞模板、分類時也十分不便。還是建議一個車型一個條目較好。--owennson（聊天室、獎座櫃） 2022年3月24日 (四) 00:42 (UTC)

@owennson： 捂脸這根本已經不是維基的格式準則了…。直接修正就好了，另請教有哪些條目？0W0--🚊。鐵路Railway ^論 2022年3月24日 (四) 04:02 (UTC)

那就好，不是範圍內。因為我想幫上海地鐵03A02、04A02型建立條目，這種橫跨兩線的車型是不可能也不應重定向到路線條目的。--owennson（聊天室、獎座櫃） 2022年3月24日 (四) 05:08 (UTC)

(！)意見@owennson：若命名空間是模板，直接移動不留重定向後將內容更正即可，若是拆分在2個頁面的則直接除內容貼到新條目內吧。--🚊。鐵路Railway ^論 2022年3月24日 (四) 05:50 (UTC)

---

鐵路1（讨论 | 貢獻） ：

救命！原來我已有半年沒有參與香港巴士愛好者內容回退事宜，發現有大量ip用戶重新加入愛好者內容，單憑我一人之力無法處理這些內容，請問可否代為申請大規模限制ip或沒有自動確認用戶編輯交通模版及號召編輯員進行刪減？否則只好放棄數以千計的愛好者內容回退。--HK5201314（留言） 2022年3月26日 (六) 08:53 (UTC)

• 1. @HK5201314：這裏是指「車輛條目」，不是「路線條目」。
  2. 如何限制？除非把所有維基百科條目半保護^{[開玩笑的]}。Fran·1001·hk 2022年3月26日 (六) 09:35 (UTC)

     @Fran1001hk：

     Yes，將巴士路線條目半保護，或號召編輯員都可以。

     畢竟需要刪減愛好者內容的數量太大--HK5201314（留言） 2022年3月26日 (六) 11:15 (UTC)

  • @HK5201314：我想如果按閣下所說，其實不止香港，世界其他地方的巴士路線條目應該如你般「刪減愛好者內容」，可是條目數量會是很多很多（我也无法統計）。如果閣下只針對香港，只會引發更多爭議。Fran·1001·hk 2022年3月27日 (日) 06:04 (UTC)

    @Fran1001hk：

    你大可以問問@DarkWizard21，他在香港交通模板的刪減動作完全獲得管理員的支持及認可。沒有任何管理員可以對他作出懲罰，所以如果單針對香港，不會引發爭議。--HK5201314（留言） 2022年3月27日 (日) 06:57 (UTC)

    • @HK5201314：編輯模板本身會影響極大量的條目，除非是小修小補，否則未有共識而刪減裏面的內容會有挑起編輯戰風險。舉個例子，如閣下把模板:Infobox bus route中的Data14和16（即所屬車廠和路線用車）兩欄逕自刪去，便會有挑起編輯戰的風險。Fran·1001·hk 2022年3月27日 (日) 11:31 (UTC)

      @Fran1001hk：

      請問你可否提供來源證明留下Data14&16的意義？--HK5201314（留言） 2022年3月27日 (日) 12:58 (UTC)

      @HK5201314：DarkWizard21的刪減只限於香港交通模板，影響的條目僅局限於香港。可是，使用模板:Infobox bus route的條目不止於香港，还有中國大陸和其他地区，你進行任何刪減動作便會影響海量條目。Fran·1001·hk 2022年4月19日 (二) 02:09 (UTC)

個人認為“用車變遷”並不是愛好者內容，明顯是巴士路線條目基本的內容吧，根本不應該刪除。--Wpcpey（留言） 2022年3月26日 (六) 14:09 (UTC)

@Wpcpey：

當然以為用車變遷不是愛好者內容

只不過現時用車型號、車牌及車廠屬於愛好者內容。

如果單刪減上述三項內容，爭議性應該不大。--HK5201314（留言） 2022年3月27日 (日) 06:59 (UTC)

個人認為用車型號是不可缺少的內容，特別是在香港的巴士路線，80年代至2010年代中有非常多類型的巴士在同一路線服務。其他地區和國家也沒有香港這樣的情況。--Wpcpey（留言） 2022年3月27日 (日) 13:27 (UTC)

@Wpcpey：

來源？這些內容很容易判為愛好者內容，更何況每一款巴士原則上沒有指定行駛哪條路線

舉個例，上年秋季某日西貢鄉郊發生水浸，ITtalk 報導原本派出的雙層巴士全部改為單層巴士，車款五花八門，請問這些每日不同的資料寫入合適嗎？

(＆)建議

我在上面講過，不改動用車變遷，畢竟涉及歷史問題

而家IG咁多巴士記錄者，問佢哋攞幾幅相證明曾經使用相關車型咪ok囉（後以gallery形式顯示），當用車變遷就算啦（曾經），用不著寫入data16，因為沒有硬性規定一定要使用這款車，而寫得入data16的是該路線指定使用該車款。--HK5201314（留言） 2022年3月27日 (日) 14:20 (UTC)

你說不改動用車變遷，但是閣下在去年在多條巴士條目已經刪除有關內容了。更甚的是那些巴士記錄者會願意拿出照片到維基證明嗎？特別是80年代至2010年代中那段時期。本人建議用不同年代描述主要車型（差不多5-10年為一個週期）。不需要再將資料細分到每日/每月，這樣就真是愛好者內容。--Wpcpey（留言） 2022年3月27日 (日) 14:29 (UTC)

@Wpcpey：

如果有相片會比較合適，使用文字會有紙上談兵的感覺，有作故事的可能，畢竟無法確認真偽。

況且不是有一本書講述80-00年代的用車變遷，引用isbn 應該不是問題。

如果有人在HKItalk以CC By Sa 3.0徵集照片，應該很多人支持，畢竟有推廣的可能，況且最後還要標示相片是來自相關人士的page，變相可協助他們增加page的關注度。--HK5201314（留言） 2022年3月27日 (日) 14:42 (UTC)

鐵路條目有規格與構造和重大事故，但是公車條目就沒有？這是按什麼邏輯定的？十分不解。--Opky9407（留言） 2022年4月13日 (三) 11:53 (UTC)

@Opky9407：在下是參照目前現有條目格式訂的，參照條目也不多，可能疏漏了，公車條目在下不是很熟悉(• ▽ •;)--~~--🚊。鐵路Railway ^論 2022年4月14日 (四) 01:38 (UTC)

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

建議「行文結構」一章參考电子游戏条目指引，在開頭加上類似的一段話：“本節介紹了幾類條目的結構，實際條目的分節方式和標題無需完全對應下文。若您的條目有特殊之處，請放手調整，不必拘泥於本文。 ”。條目不必强制統一格式，畢竟有些條目會有其特殊的地方。--Jhstriver（留言） 2022年4月24日 (日) 09:07 (UTC)

@Jhstriver：感謝建議，已增加。--🚊。鐵路Railway ^論 2022年5月2日 (一) 05:11 (UTC)

---

🕗 公示7日，2022年5月9日 (一) 05:15 (UTC) 結束：7日無新意見，且主文變動不大，進入最後公示。--🚊。鐵路Railway ^論 2022年5月2日 (一) 05:15 (UTC)

(－)反对：到底你是怎樣參照條目的？上面有人給出的公車條目，其實有寫規格和構造，反而沒有重大事故，但是你卻在公車車輛那裡加了重大事故，規格和構造卻沒有，完全不明白為什麼會有這樣反過來的操作？感覺改得很隨便，所以只能反對繼續公示,需要再改。--Opky9407（留言） 2022年5月8日 (日) 15:26 (UTC)

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

其實，鐵路那部分都有問題，像是英國鐵路373型電力動車組都跟提出的架構有很大不同。條文太過以台灣為重心去制定，用在其它國家的車型應該會很容易出問題吧。要是問我怎樣修改，我寧可完全不要直接把行文結構定出來，因為各地和各類車型根本不可能完全共用同一個結構。只規定哪些內容是不能寫應該還要實際。--Maccomcre（留言） 2022年5月9日 (一) 05:13 (UTC)

@Maccomcre：在下大部分是參照日本、香港、臺灣、韓國、中國大陸以及少數美國、印尼、越南鐵路車輛條目進行規劃，應該是少數車輛不適合吧...，若就少數車輛不適用可利用「本節介紹了幾類條目的結構，實際條目的分節方式和標題無需完全對應下文。若您的條目有特殊之處，請放手調整，不必拘泥於本文。 」這條應對修改ㄚ。--🚊。鐵路Railway ^論 2022年5月9日 (一) 12:52 (UTC)

(：)回應：港鐵中期翻新列車、新幹線E2系電力動車組、日本國鐵D51型蒸汽機車等香港、日本鐵路車型都跟上面的架構有很大不同（JR東日本車輛形式裡面就有大部分車型都跟上面的架構有很大不同），所以是很多車型都不適合，而不是少數。如果很多車型都要當成有“特殊之處”去調整，那麼定出來的架構完全沒有意義，所以還是(－)反对。--Maccomcre（留言） 2022年5月24日 (二) 15:52 (UTC)

(－)反对：擔心會有其他用戶會用此標準而進行大規模刪除，近年的環境已經趕走了很多人不願更新了。--Wpcpey（留言） 2022年5月9日 (一) 12:59 (UTC)

在下建立初衷是許多新編輯加入不適合維基百科的內容或是格式不統一才提議的。--🚊。鐵路Railway ^論 2022年5月9日 (一) 13:56 (UTC)

問題是“不適合的內容”範圍越來越大，很多過去10多年來可以收錄的東西，由2020年起也不能再收錄。看看電視和鐵路條目就知道了。--Wpcpey（留言） 2022年5月9日 (一) 14:16 (UTC)

有些是沒人清理就一直加下去，例如臺鐵的列車運用車輛配屬本來就不適合維基百科，是近期才清理到維基學院的。--🚊。鐵路Railway ^論 2022年5月10日 (二) 03:42 (UTC)

🕗 公示7日，2022年5月24日 (二) 17:47 (UTC) 結束：7日無新發言，公示。--🚊。鐵路Railway ^論 2022年5月17日 (二) 17:47 (UTC)

(＋)支持建立相關規範--一個喜歡新興科技的維基人（留言） 2022年5月18日 (三) 07:38 (UTC)

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

• 竟然連支持的人都出現了疑問。其實再看開頭的那兩段說話已經很有問題，先是「統一格式將有助於閱讀及編輯維護上的便利性」，然後又說「請放手調整，不必拘泥於本文」，明顯前後矛盾的語句，讓人放手調整那麼就不可能是統一了。另外，本來提案人也承認了參考的條目不多，之後提案人對於結構的修改就好像見到什麼就加什麼的，其實每個條目都有很多不同之處，事實上很難舉出所有都用到的章節，與其這樣的大混雜，還不如上面有人說索性不要把結構釘起來，只告訴大家哪些內容是屬於愛好者等不適合百科全書，更來得實際。--Opky9407（留言） 2022年5月24日 (二) 14:17 (UTC)

在下是主編鐵路車輛相關條目，對鐵路車輛較了解，大部分鐵路車輛應該都是可適用，公車相關的確是參考比較少--🚊。鐵路Railway ^論 2022年5月24日 (二) 17:12 (UTC)

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

• 順帶一提，這顯然是指引而非方針。--Temp3600（留言） 2022年6月1日 (三) 01:41 (UTC)

  @Temp3600：是指引沒錯，只是討論標題沒有改--🚊。鐵路Railway ^論 2022年6月2日 (四) 00:44 (UTC)

---

🕗 公示7日，2022年6月8日 (三) 01:07 (UTC) 結束：7日無新發言，公示。--🚊。鐵路Railway ^論 2022年6月1日 (三) 01:07 (UTC)

• (：)回應：「統一格式」和「同樣格式」根本沒有改變意思吧，改了跟沒改真的沒什麼差別，跟「請放手調整，不必拘泥於本文」的矛盾仍然存在，只能繼續反對。--Opky9407（留言） 2022年6月7日 (二) 13:57 (UTC)

• (：)回應：感覺完全無視了我提出的問題，我重複再提一次：「港鐵中期翻新列車、新幹線E2系電力動車組、日本國鐵D51型蒸汽機車等香港、日本鐵路車型都跟上面的架構有很大不同（JR東日本車輛形式裡面就有大部分車型都跟上面的架構有很大不同），所以是很多車型都不適合，而不是少數。如果很多車型都要當成有“特殊之處”去調整，那麼定出來的架構完全沒有意義，所以還是(－)反对」。--Maccomcre（留言） 2022年6月8日 (三) 01:01 (UTC)

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

同Shizhao，早前都沒留意到。放維基學院的條件是具有「研究」成分，不是愛好者內容就拋去學院的。--路西法人 2022年6月8日 (三) 04:03 (UTC)

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

@Maccomcre、Opky9407、Shizhao、LuciferianThomas：已進行修正，還請指教。--🚊。鐵路Railway ^論 2022年6月21日 (二) 15:04 (UTC)

---

🕗 公示7日，2022年7月7日 (四) 15:11 (UTC) 結束：超過7日無新意見，公示7日。--🚊。鐵路Railway ^論 2022年6月30日 (四) 15:11 (UTC)

@鐵路1：請同時於公告欄進行公示。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年7月1日 (五) 16:33 (UTC)

(：)回應：把「統一格式」改為「同樣格式」又再改為「相同格式」，真的不知道意思有什麼改變，跟「請放手調整，不必拘泥於本文」還是矛盾。還有為什麼鐵路條目加了車輛保存，但是公車條目就沒有加？這下子又出現了之前發生過的問題：這是按什麼邏輯定的？邏輯不明的制定方法那只能(－)反对。--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)

  @Maccomcre：已修改。--🚊。鐵路Railway ^論 2022年8月17日 (三) 00:44 (UTC)

  既然不是相似格式，那就不是行文結構了。還有把「速度實驗」歸類在歷史？好像不太對。--Maccomcre（留言） 2022年8月18日 (四) 02:05 (UTC)

  @Maccomcre：已修正。在下的習慣實驗。會寫在歷史內，因屬於測試實驗過程的歷史介紹--🚊。鐵路Railway ^論 2022年8月19日 (五) 14:32 (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:500（Wikipedia:投票/是否在管理員選舉啟用SecurePoll）的共識，社群已經試行了一次安全投票（Wikipedia:申请成为管理员/和平奮鬥救地球/第5次），但是接下來社群如何進行投票是沒有充份共識的，引至出現了這種問題。因此，希望大家認真討論一下：

1. 接下來的「申請成為管理員」，以及是其他管理人員職務是否使用安全投票？
   1. 如果決定不使用，（除了是在原地打轉之外，）如何滿足、解決「阻止拉票和人身威脅」的問題。
   2. 如果決定使用安全投票，如何決定程序，時間，方針對應的調整也是需要考慮的。

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

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

支持2，免得自己支持或反對被人議論紛紛。和平奮鬥救地球的選舉流程應該沒什麼大問題吧，一些人提名+正式投票。--中文維基百科20021024（留言） 2022年6月5日 (日) 08:20 (UTC)

@Ghrenghren：（我倒是覺得你先等Steward公佈了正式投票結果以後才開這討論串比較好，但現在開也不要緊）我覺得之後繼續使用安全投票是必然的事情，雖説不可能阻止拉票，但不使用也阻止不了，而且人身威脅問題明顯是基金會與社群極度關注的問題，必須優先處理，而且我也不認為基金會方面會容許社群在人身威脅問題上開倒車。我覺得程序可以比照Wikipedia:申请成为管理员/和平奮鬥救地球/第5次來擬定，這樣能省卻不少麻煩。Sanmosa _{Χαίρε, ω χαίρε, Ελευθεριά!} 2022年6月5日 (日) 08:28 (UTC)

問題沒法根除的情況下就選最好的一種解決方案。--中文維基百科20021024（留言） 2022年6月5日 (日) 08:44 (UTC)

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

我個人支持繼續採用安全投票。不過基於安全投票需要籌備的時間相對較長，因此建議集中提名，一次過投，這樣比較有效率，比如可能一年兩次提名期之類的。--AT 2022年6月5日 (日) 08:57 (UTC)

一年一次應該也夠吧，但我考慮到Steward選舉的情形，也同意集中提名與統一投票期的舉措。Sanmosa _{Χαίρε, ω χαίρε, Ελευθεριά!} 2022年6月5日 (日) 16:06 (UTC)

就籌備時間的問題來說，一年兩次或一年一次的區別應該不大。但相較後者而言，前者可讓有意申請或提名管理員的用戶不必等那麼久。-Peacearth（留言） 2022年6月10日 (五) 20:44 (UTC)

事實上頻率還可以更高。沒有必要把選管理員搞得像在選監管員一樣。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年6月11日 (六) 13:52 (UTC)

作為兩次安全投票監票人，覺得有些事情是要提醒社群，在作出上述決定之前是必須考慮︰

是否允許使用Proxy︰以本社群組成部分而言，如果使用安全投票，禁止使用Proxy幾乎等於阻斷相當一部分合資格用戶參與投票，但在投票意向隱藏之下，允許使用Proxy將會大幅度減弱監票效果。

臨界狀況︰因為安全投票與傳統方法差異不少，若出現傳統上臨界狀況，即75至80%時，行政員幾乎無法介入去作出決定。例如使用中立票去判斷候選人是否當選。

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

禁止使用Proxy幾乎相當於不讓居住在中國大陸境內的人投票，貌似免proxy使用Wikipedia比較繁瑣。--中文維基百科20021024（留言） 2022年6月5日 (日) 09:05 (UTC)

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

在登錄賬戶的情況下使用proxy投票會有什麼問題嗎？--中文維基百科20021024（留言） 2022年6月5日 (日) 09:07 (UTC) 表现为部分投票用户使用IP相同或相近，有傀儡的可能。--东风（留言） 2022年6月5日 (日) 10:50 (UTC) 過往情況下不是有投票有資格限制嘛，那安全投票可以自動阻止不符合資格的人投票嗎？而且以前投票的時候不也沒有限制proxy。--中文維基百科20021024（留言） 2022年6月5日 (日) 11:06 (UTC) 但過去是明票，投票意向跟編輯紀錄都是一覽無遺……--J.Wong 2022年6月5日 (日) 11:18 (UTC) 讓監管員把參與投票的人都CU一遍？--中文維基百科20021024（留言） 2022年6月5日 (日) 11:22 (UTC) 不太明白……--J.Wong 2022年6月5日 (日) 11:43 (UTC) 维基百科:用戶查核，總不見得不讓中國用戶投票吧。--中文維基百科20021024（留言） 2022年6月5日 (日) 12:14 (UTC) 对投票用户全部进行查核理论上可行，因为即使存在相同或相近IP，使用设备存在差异也会生成 不相关，但这无疑给监管员增加了（极大）工作量，我感觉他们的回应可能不会很积极。--东风（留言） 2022年6月5日 (日) 12:24 (UTC) 那正好可以藉著這個機會把查核權要回來。--中文維基百科20021024（留言） 2022年6月5日 (日) 12:26 (UTC) @中文維基百科20021024：Wikipedia talk:申请成为管理人员/存档7中有説明基金會對於恢復zhwiki用戶查核權的要求：以安全投票進行選舉、用戶查核員任期制（任期為2年）、基金會定除權機制（直接看連結吧，我懶得打出來了）、強制接受基金會培訓、基金會定期稽核。我覺得先處理好管理員選舉問題以後才處理恢復用戶查核權的事情會比較有説服力。Sanmosa Χαίρε, ω χαίρε, Ελευθεριά! 2022年6月5日 (日) 15:54 (UTC) 真的建議兩位先去了解一下什麼是secure poll，然後再來討論。--J.Wong 2022年6月5日 (日) 12:45 (UTC) 我对代理这部分的理解是这样的，那可能并不正确。--东风（留言） 2022年6月5日 (日) 13:23 (UTC)

中立票之意見是否會顯示，以協助行政員判斷結果？-Peacearth（留言） 2022年6月5日 (日) 13:22 (UTC)

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

原來如此。這樣的話的確不太能用來協助判斷。-Peacearth（留言） 2022年6月6日 (一) 03:21 (UTC)

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

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

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

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

考慮到基金會在此前因為安全理由而要求中國大陸用戶自行請辭重要權限一事（注意當時基金會所提到的“安全理由”沒包括Proxy），我有理由認為基金會並不信任中國大陸用戶。另一方面，基金會一向並不鼓勵使用Proxy。雖然禁止使用Proxy相當於不容許身處中國大陸的人投票，我認為這是唯一保證投票安全性的辦法，而且基金會不會對此有任何意見。Sanmosa _{Χαίρε, ω χαίρε, Ελευθεριά!} 2022年6月5日 (日) 15:47 (UTC)

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

還需要決定是否通知選舉人投票事宜。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年6月5日 (日) 10:27 (UTC)

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

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

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

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

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

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

重寫方針是比較簡單的部分；甚至不需要廢除既有之全部內容，只需要能夠反映採用安全投票的現實即可。當然根據相關討論，人事任免資格方針也得修一下了。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年6月5日 (日) 16:29 (UTC)

我要特別聲明一點：我反對任何容許以舊投票方式進行選舉的方案，並行方案也不行。只有安全投票能保證投票人的人身安全，因此只能統一使用安全投票。Sanmosa _{Χαίρε, ω χαίρε, Ελευθεριά!} 2022年6月5日 (日) 15:49 (UTC)

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

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

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

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

不行，我覺得受人身威脅者也會被威脅不得到安全伺服器投票，所以不可容許安全伺服器投票以外的任何投票方法。另外，提醒一下大家安全投票機制只會讓大家知道誰已經投了，而沒人知道誰怎麼投。Sanmosa _{Χαίρε, ω χαίρε, Ελευθεριά!} 2022年6月6日 (一) 06:03 (UTC)

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

@Antigng：還有一點，由於選舉期間所有人都能夠看到了誰已經投票，所以進行人身威脅者是會知道受人身威脅者有在安全投票那邊投票的，進行人身威脅者可以威脅受人身威脅者撤回在安全投票那邊投的票。Sanmosa _{Χαίρε, ω χαίρε, Ελευθεριά!} 2022年6月6日 (一) 06:34 (UTC)

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

@Antigng：實務上不可行。安全投票是P站那邊負責的，所以那邊在投票結束後會直接給出所有參與安全投票的人的名單，進行人身威脅者還是可以知道受人身威脅者有沒有在安全投票那邊投票（而且還有考慮到被基金會除權的人包括管理員與行政員）。我主張只容許安全投票的原因是進行人身威脅者會失去得悉受人身威脅者是否有投票的誘因。Sanmosa _{Χαίρε, ω χαίρε, Ελευθεριά!} 2022年6月6日 (一) 06:43 (UTC)

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

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

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

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

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

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

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

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

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

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

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

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

對於將已投票名單改設置為對公眾不可見的提案表示支持。但對於「投票意見」的部分，個人看法同Shizhao在下面說的，當前投票時已容許用戶發表意見，已足以供大眾及行政員判斷是否合理，而無需知道該意見提出者是否投了支持/反對/中立票、更不需要知道是哪位特定用戶所做出的。-Peacearth（留言） 2022年6月10日 (五) 20:40 (UTC)

這會不會就是共識制？--J.Wong 2022年6月12日 (日) 04:53 (UTC)

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

好像也是。不過至少「行政員可考慮中立票」的部分可能需要稍加修訂，雖然實質上並無太大區別。-Peacearth（留言） 2022年6月10日 (五) 20:32 (UTC)

• 順帶一說，我覺得看投票留言比看中立票更能判斷共識。以理服人嘛。--Temp3600（留言） 2022年6月7日 (二) 14:27 (UTC)
• 至少真的是不記名投票，意見那邊有說過了。而且，投票期間結束後確實無法再投票，安全投票可行性是有的。就是...維基百科有無要創建一個頁面叫做「Wikipedia:安全投票」？--Z7504非常建議必要時多關注評選（留言） 2022年6月9日 (四) 11:01 (UTC)

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

  也是喔，不過看看獨裁社群這樣搞，好像玩不起安全投票一樣，也就是說還是有人無法接受新格式的事實，就像Wikipedia:申请成为管理员/Lanwi1/第4次一樣。如果明知選不上管理員的奉勸就別選了，以免浪費很多寶貴時間，又不代表使用安全投票就一定能選上。還有喔，喊拉票的風聲去哪了？意思是說拉票經過安全投票過的也算過囉？--Z7504非常建議必要時多關注評選（留言） 2022年6月13日 (一) 08:36 (UTC)

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

  然而拉票這玩意也講過了啊，拉票是一種防不勝防的情況啊。只要有去討論過GA評選的爭議就知道了，GA評選就有出現過拉票的爭議了。為何這個獨裁社群沒有想過呢？--Z7504非常建議必要時多關注評選（留言） 2022年6月13日 (一) 11:24 (UTC)

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

  我覺得必須。拉票問題比起投票人受威脅的問題實在微不足道。Sanmosa _{Gottes Sonne strahl' in Frieden} 2022年6月13日 (一) 14:02 (UTC)

  還會被人拉清單--中文維基百科20021024（留言） 2022年6月13日 (一) 14:19 (UTC)

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

• 所以呢？要不要用安全投票是不是也要用安全投票決定呢？看吧都沒動靜了。--Z7504非常建議必要時多關注評選（留言） 2022年6月16日 (四) 15:43 (UTC)

  從這個沒有動靜的看法，能否認為大家都覺得以後都要使用安全投票呢？上文除了討論兩者並行的方案外，不見明確的反對，如實在是沒有反對意見的話，不如就公示？--Ghren🐦🕕 2022年6月19日 (日) 10:28 (UTC)

  @Ghrenghren：問題是結論是甚麼，沒看出結論--SunAfterRain 2022年6月20日 (一) 00:16 (UTC)

  @SunAfterRain：我也沒看出在具體怎樣實行安全投票方面有什麼結論。但是如果可以有個初部共識決定以後都是用安全投票的話，對之下來的討論應該有幫助？--Ghren🐦🕙 2022年6月20日 (一) 02:42 (UTC)

  @Ghrenghren：如果不一次把這個討論串了結的話，我認為下一場選舉的準備時間還會拉長好幾倍（拖在討論時間）--SunAfterRain 2022年6月20日 (一) 07:39 (UTC)

  獨裁社群最好的方式真的是能拖延就拖延，導致一個討論串可能超過10萬位元組都不為過，沒想到要不要用安全投票居然都可以那麼的墨跡。--Z7504非常建議必要時多關注評選（留言） 2022年6月20日 (一) 11:34 (UTC)

• (！)意見：(＋)支持往後使用安全投票，至於有關此機制之技術性問題，竊以為應由基金會提供技術援助或解決（如投票介面、中立票、資訊顯示或隱藏、監驗票等功能設計或修訂）。個人認為，諸多站友既已花費大量時間、心力貢獻於此平台，提供平台所需之條目、站務、維運、構想、智慧等寶貴要素，甚而亦有用戶不吝捐款、出錢出力，且人事選舉相關議題紛擾已久，實應獲得有效解決。況且，中文社群亦已對相關議題發起討論至今，可謂集思廣益、盡心戮力了。綜觀站友意見，敝人斗膽表達意見和考量如下：

1.一切活動應以安全為優先考量。如果用戶光是上網投個票都不安全，或需承擔各種風險，甚至已經遭受到實質安全威脅，個人認為理當以自身安全為首要考量。若用戶真已感受到任何形式之人身安全脅迫（不論被迫以何種形式如何表態），敝人建議：先暫停維基百科內相關活動，必要時請求當地司法機構協助，在條件許可下向基金會具體陳情以尋求適當協助。在此之前，使用介面和機制之規劃應有所為。

2.投票過程中的已投票用戶名單等動態資訊不應對一般用戶公開。

3.投票結果若處於臨界狀態，行政員可綜合考慮用戶投票意見和理由予以裁定。

4.安全投票機制若能明確標註顯示「中立票」之附含意見較為理想；若最終安全投票介面仍不具此功能，且社群或具權限之監、驗票人員仍期待便於識別中立票內含之意見，竊以為於投票須知明確規範：「當用戶投下中立票，應於投票意見欄明確表達該票附具之意見或評價為『中立』，以便選舉結果之識別判讀。」即可（如投票用戶應於意見欄寫明：「中立，基於候選人....，但仍.....」；「投下中立票。平日候選人之站務表現已具ＸＸＸ和ＯＯＯ，往後可再加強AAA，....」）。

5.若設立選舉投票事宜通知機制，可供用戶自由選擇訂閱。

6.其他技術性事項回歸安全投票機制所具功能，具投票資格用戶應皆可合規投票。

7.投票期間若發生異常或灌票現象，竊以為應可由具監、驗票權限之站務人員核查處置。

8.現行投票頁面上方已有「意見」區，欲發言、討論、評論之站友應已有適合之區域，可供品評論議；站務人員選舉中「討論交流或評論表達以形成共識」之機制，竊以為此區塊應可具相當之功能，與「實際投票功能或機制」並行不悖。若有其他考量，或可對於「意見」區之規劃再行增補調整。

9.對於中立票之意義或代表性，過往已有相關討論及爭議，似懸而未決。敝人初步考古後認為，所謂中立票實則未必「中立」，觀諸過往中立票之具體意見和內容，所顯露之實質意向往往「偏向反對或不甚支持」（除去先置板凳、卡個位、看風向、只求個參與或真的沒意見等未帶實質意見內容者），亦即當投票用戶對參選人感到不太滿意或至少不夠滿意的情況下，仍希望參與投票並藉此加以評價，以對候選人表達「委婉反對」、「尚待加強」之意見或評價；竊以為講白了，其實幾乎就是偏向「不太支持」。用戶特地至此投下這一票，若對於候選人真毫無個人立場或意見偏好，又何必如此費力呢？個人認為其實就是不太支持參選人，可能基於種種考量，而不直接投下反對票，僅透過參與以表達意見或在投票結果臨界時期待發揮效用。若實行安全投票機制，行政員應仍可依據投票用戶留下的意見做出裁定，而投下中立票之用戶亦應明確其自身投票性質；否則，所謂「中立票」之存在意義甚至可供深入討論了。

以上為個人意見，供參。--Kriz Ju（留言） 2022年6月20日 (一) 06:01 (UTC)

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

還不是有人不知道普通投票和安全投票的差別嗎？這種討論都可以一直沒動靜，基本上不用玩了，既然完全說服不了人還要考慮選管理員？最後恐怕就是互相投反對、浪費時間而已的奇葩社群。--Z7504非常建議必要時多關注評選（留言） 2022年6月22日 (三) 15:30 (UTC)

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

投票方式的共识

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

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

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

• 為何要並行呢？總之總有人搞不清楚何謂安全投票和普通投票的差別嘛，現在這個獨裁社群連以後要不要實施安全投票都可以無法做決定了，真的無法說服大眾，扯。請問如果要並行，那票是不是可以兩邊投阿？--Z7504非常建議必要時多關注評選（留言） 2022年6月23日 (四) 16:53 (UTC)

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

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

(！)意見：不好意思，敝人不確定候選人輕生是否指特定人士；若然如此，我強烈建議精神狀態不佳的站友敬請審酌衡量自身身心狀態，以個人安全和健康為重，如果的確身心狀態不佳，請立即停止所有維基百科相關活動，並尋求適當心理或醫療協助。況且，若用戶心神狀態確實如此，顯然不適合參與人事選舉等較可能產生火花之社群活動，亦敬請站友多多關心身邊的社群用戶。--Kriz Ju（留言） 2022年6月27日 (一) 19:03 (UTC)

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

中國大陸使用者是否輕生率較高敝人不認為可以從這一個簡單的投票介面和主題加以驗證，而仰賴投票介面表達意見自由致影響個人生命安全和身心健康或產生可能疑慮，我認為顯然亦非健康思維和應有舉措。敝人會建議，請各位站友多多關注生活和人生的美好面向，切勿因投入任何網路相關活動致影響生活平衡。與諸位站友共勉之。--Kriz Ju（留言） 2022年6月28日 (二) 04:58 (UTC)

沒什麼屁用，就算用實體投票一樣也可以惡意投反對票。--Z7504非常建議必要時多關注評選（留言） 2022年6月28日 (二) 14:08 (UTC)

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

為什麼我覺得恰恰相反？反倒是非安全投票下容易造成心理問題？（如果候選人的確有的話）非安全投票下投票會有壓力。--日期20220626（留言） 2022年6月28日 (二) 14:36 (UTC)

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

不，對易被幫派排擠的候選人的而言，在沒有安全投票的情況下才容易造成心理問題。請不要將以前WMCUG干預RFA的情形視而不見。Sanmosa _{Királyunk s a közhazát} 2022年6月29日 (三) 01:56 (UTC)

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

我感覺把你說成同時存在的兩個「幫派」比較一下的話，就算這兩個「幫派」都真的同時存在，「反WMC的幫派」所產生的問題明顯不能與「親WMC的幫派」所產生的問題相提並論，至少「反WMC的幫派」不可能像「親WMC的幫派」一樣有羣體策劃的欺凌（包括但不限於網絡上與現實上）。Sanmosa _{Királyunk s a közhazát} 2022年6月29日 (三) 15:25 (UTC)

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

以前公開投票的時候有相互吵架的，對投反對票冷嘲熱諷的，還有我上面討論提到的有人投了反對票還會被人拉清單，就沒發現公開投票好在哪裡。--日期20220626（留言） 2022年6月29日 (三) 03:08 (UTC)

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

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

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

那麼哪些情況下使用安全投票，根據候選人意願嗎？--日期20220626（留言） 2022年6月29日 (三) 17:15 (UTC)

(！)意見：竊以為若技術可行，折衷方法或可考慮為「雙軌並行」，兩邊介面重複投票者計屬廢票，且該用戶視為擾亂選舉。若候選人於表態參選時指定選擇個人偏好之特定形式（不論「公開具名」或「安全匿名」形式），於七名用戶投下反對該候選人指定形式之反對票後，亦即相當於同時投下「反對候選人和其指定形式」之反對票（相當於雙重反對），則回歸雙軌並行制。之所以為七名反對者，敝人取自「罷免連署投票」之門檻；而同時反對候選人乃至出具理由反對其偏好形式，可見反對用戶對於參選人之「強烈反對或不信任」，以致其偏好之投票形式皆反對（此時投下之七票反對票為公開投票），此時則回歸雙軌並行。個人意見，供參。--Kriz Ju（留言） 2022年6月29日 (三) 20:39 (UTC)

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

上面就講過了嘛，這社群連看都沒在看，還在雙軌投票並行制？完全說服不了人就說了吧，真是有夠扭捏的。--Z7504非常建議必要時多關注評選（留言） 2022年7月1日 (五) 15:57 (UTC)

• 普通投票的缺點已經很清楚了。暫時沒有看出支持者有什麼補救辦法。--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页面表达支持或反对的意见。--CuSO₄ 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)

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

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

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

提議條文 预提名：未来一场选举将仿照此前的安全投票选举流程，统一在互助客栈其他区进行预提名。在第一位候选人预提名提出之时，为期七天的预提名程序即开始，在此七天内皆可提名其他候选人。在此七天内，愿意接受正式提名并回答前述三个基本问题、得到七位具人事任免投票资格之用户联署支持，且符合成为管理员之资格者，经行政员确认，即获得正式提名，并将统一进行选举，且应比照前述之一般流程另行设置个人选举页面。依照社群2022年4月的共识，此次预提名不受前次“检验冷静期”限制。

--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:人事任免投票資格之规定稍有差异。符合以下两项之至少一项条件者有权投票： 投票预提名开始120天前，编辑至少500次；并在预提名开始前90天内至少有1次编辑（不包括任何用户页及用户对话页）； 编辑至少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)

@Xiplus、S8321414、Ericliu1912、Lanwi1：若无进一步意见，是否可以在近几日对此更改进行公示，或是如Ericliu1912所言，由其重拟一案？--Yining Chen（留言|签名页） 2022年8月18日 (四) 10:38 (UTC)

目前修改的條文應該還可以，暫時沒看到重擬一案的必要。--冥王歐西里斯（留言） 2022年8月18日 (四) 11:36 (UTC)

封鎖對投票資格的影響檢查時間點仍然定在通過提名之時沒有問題嗎？例如是否也改成提名開始之時或這段區間都算？--Xiplus#Talk 2022年8月18日 (四) 12:00 (UTC)

另外打算再次進行實驗的理由是要支持多人參選，但目前規定看起來並沒有針對多人這方面做出規範，例如在多長時間段內通過預提名的候選人可以「合併進行選舉」。--Xiplus#Talk 2022年8月18日 (四) 12:01 (UTC)

1. 这个问题似乎与是否采用安全投票无关，不太清楚以前的普通投票实践中是否出现过与封禁期限有关的问题（如在RFA进行期间被解封的用户是否有投票权）？
2. 依照现在草拟的方案，是（符合相关条件的）候选人在预提名进行的七天内，只要有七名用户投票支持，就算作符合标准。并未再试图设立一个“从预提名到投票数达标”的时间限制。--Yining Chen（留言|签名页） 2022年8月18日 (四) 12:54 (UTC)

   (1). 普通投票中只要能編輯投票頁就有投票權，相反來說，投票期間只要持續被封鎖（含部分封鎖）以致無法編輯投票頁，就等於無投票權，但因為安全投票需要預先設定投票權人名單，極不可能在投票過程中更改，所以才要決定判定被封鎖無投票權的規則，上次安全投票定為提名通過之時，不過與人事任免投票資格的基準時間為提名開始之時不同，我才在此提出是否要再次考慮定這個時間是否合理。 (2). 我的意思是，在第一個提名通過就會開始準備安全投票，但假設之後又有新的候選人提名通過，理應可以於同一個投票中一併投票（因為安全投票籌備需要不少時間），但若之後持續又有新的提名通過（假設每3天就有新提名通過，即第1、4、7、10、13...天都有新提名通過），那麼究竟哪些候選人能夠趕上同一個投票，哪些候選人就裁定排到下次投票（畢竟不可能無限等候後面的候選人提名通過）。--Xiplus#Talk 2022年8月18日 (四) 13:09 (UTC)

   (1)问题，我个人认为或可以延续先前做法，但或许需要等待其他意见。(2)问题，上文的表述可能不是很清楚。并不是针对每一个候选人单独开投票，而是所有用户统一在先前计划好的的某七天内进行预提名操作，也就是说，该修正案只对下一次的安全投票选举负责；在整体的投票过程中，只会出现“一个”七天的预提名。--Yining Chen（留言|签名页） 2022年8月18日 (四) 14:09 (UTC)

   (2) 不同的候選人要怎麼在同一個7天內進行預提名？提出預提名的時間本來就會有所不同，如果這個7天預提名進行到第3天，是否可再提名一個候選人？--Xiplus#Talk 2022年8月19日 (五) 01:31 (UTC)

   (2) 既然已经留出了7天的时间，那么在这七天内的任意一天提名都应当是可以的。毕竟时间相对较充裕，即使是在预提名第二日再提名，与第一日相比效果或许也不会相差很多。--Yining Chen（留言|签名页） 2022年8月19日 (五) 02:50 (UTC)

   那如果第7天才提名另一位候選人呢？另外這個7天期限是單一位候選人的期限，還是這次聯合選舉的提名期限？--Xiplus#Talk 2022年8月19日 (五) 02:55 (UTC)

   “第七天才提名”，这是提名人自己的选择，即使大概率失败也与他人无关；另外，这个“七天”的期限在整体的投票过程中，只出现“一次”，或许也就是指“联合选举的提名期限”。--Yining Chen（留言|签名页） 2022年8月19日 (五) 03:01 (UTC)

   我理解了，不過在目前提議條文看不出這個意思。我重新整理一下規定：「未來一場選舉將仿照此前的安全投票選舉流程，統一進行預提名。在第一位候選人預提名提出之時，為期七天的預提名程序即開始，在此七天內皆可提名其他候選人，願意接受正式提名並回答前述三個基本問題、在此七天內得到七位具人事任免投票資格之使用者聯署支持，且符合成為管理員之資格者，經行政員確認，皆可獲得正式提名，並將一併進行選舉，且應比照前述之一般流程另行設定個人選舉頁面。」--Xiplus#Talk 2022年8月19日 (五) 03:14 (UTC)

   感谢。已整理并更新修正草案。--Yining Chen（留言|签名页） 2022年8月19日 (五) 03:26 (UTC)

   「在此七天內得到七位具人事任免投票資格之使用者聯署支持」應明確說明需在這個七天內的連署才有效。--Xiplus#Talk 2022年8月20日 (六) 05:52 (UTC)

   已尝试修改文本。--Yining Chen（留言|签名页） 2022年8月20日 (六) 10:10 (UTC)

我认为没有意见也不需要重拟一案。--Lanwi1(留言) 2022年8月18日 (四) 13:04 (UTC)

我也认为没问题----脳補｡◕‿◕｡讨论 2022年8月19日 (五) 13:42 (UTC)

預提名地點「互助客棧其他區」為何被刪掉了？--Xiplus#Talk 2022年8月20日 (六) 05:50 (UTC)

操作疏忽，现 已解决。--Yining Chen（留言|签名页） 2022年8月20日 (六) 10:10 (UTC)

我個人認為不需要在第二部分修正案內引用「忽略所有規則」，因為特別法本就優先於普通法，而且不必另開章節，直接置於原〈安全投票暫行規定〉一節中即可：

現行條文 （略） （略） （略） 投票過程： （略） 投票：安全投票開啟後，應至少持續二週，並應有至少二位管理人員與其他監管員共同協助監票。具人事任免投票資格，且在被提名者經行政員確認獲得正式提名之時未被封鎖或禁制編輯維基百科命名空間的使用者可以投下支持票、反對票或中立票。投票期間，投票者可以隨時改變自己的決定，其態度按投票截止時為準。選舉之有效票比照前述之一般流程僅包括上述可投票者所投的支持票及反對票，中立票屬無效票，僅將在臨界情況下被考慮。 （略） （略）

提議條文 （略） （略） （略） 投票過程： （略） 投票：安全投票開啟後，應至少持續二週，並應有至少二位管理人員與其他監管員共同協助監票。符合以下二項中至少一項條件，且在預提名結束前未被封鎖或禁制編輯維基百科命名空間的使用者可以投下支持票、反對票或中立票： 投票預提名開始120日前編輯至少500次，並在預提名開始前90日內編輯至少1次（不包括任何使用者頁面及使用者討論頁面）； 編輯至少3,000次，或編輯條目至少1,500次。 投票期間，投票者可以隨時改變自己的決定，其態度按投票截止時為準。選舉之有效票比照前述之一般流程僅包括上述可投票者所投的支持票及反對票，中立票屬無效票，僅將在臨界情況下被考慮。 （略） （略）

以上。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年8月21日 (日) 06:23 (UTC)

建議將差異部份上色，如此會更為清楚。--冥王歐西里斯（留言） 2022年8月22日 (一) 03:01 (UTC)

已經照辦。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年8月22日 (一) 15:56 (UTC)

也就是說，這次會修正暫行規定的「預提名」與「投票」兩條沒錯吧？--冥王歐西里斯（留言） 2022年8月22日 (一) 23:30 (UTC)

(－)傾向反對将限制条件嵌于流程正文当中。因为或许会使正文重点内容不够突出，格式上个人认为似乎也稍显不协调。--Yining Chen（留言|签名页） 2022年8月23日 (二) 14:42 (UTC)

(！)意見：那麼閣下認為要放在哪裡呢？目前看起來這是必要的修正。--冥王歐西里斯（留言） 2022年8月23日 (二) 23:45 (UTC)

如我在上文所写，另开一节（原暂行规定中有关的要求内容当然需要删掉，但上文未写出）。--Yining Chen（留言|签名页） 2022年8月24日 (三) 11:00 (UTC)

我不認為投票資格應該單開章節放置，這樣比重反而不均；將其置於既有之流程中毫無問題，至多以註釋處理也就已經足夠。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年8月24日 (三) 13:10 (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)

如同存废讨论的意见，我赞同这笔修订。稍有疑虑的就是，同时在多个在线商店在线商店销售（Steam、Epic、GOG.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之“官方链接”的控制程度争议，我认为仍模糊、共识不足。在某些方面，有时难以辨别官网内容的制作和维护者，可能为自行维护更新，可能为上级或其他宣传部门维护更新或编排内容，还可能交由第三方公司搭建和直接维护（技术支持），条目主体的“控制能力”是否绝对影响页面作为产品/机构的“官方链接”（门面）的身份。
  • 在en:Wikipedia_talk:External_links的讨论存档中，对ELOFFICIAL的判断标准，似乎也屡有争议。例如将内容版权所有者的YouTube视频/频道视作ELOFFICIAL的看法、2009年类似讨论。2022年将社交媒体视作ELOFFICIAL的短暂讨论。--YFdyh000（留言） 2022年8月4日 (四) 08:07 (UTC)

---

現行條文 合适的外部链接－如果存在这些链接，应当在电子游戏条目中列出 电子游戏官方主页（由开发商或发行商提供）。游戏如在中文区发售应优先列出中文版主页。如果是外文游戏，还应列出首发国家的语言版本并注明网站是外语。如果开发商和发行商提供的网站不同则应一并列出。 ...

提議條文 合适的外部链接－如果存在这些链接，应当在电子游戏条目中列出 电子游戏官方主页（由开发商或发行商提供）。游戏如在中文区发售应优先列出中文版主页。如果是外文游戏，还应列出首发国家的语言版本并注明网站是外语。如果开发商和发行商提供的网站不同则应一并列出。对于没有独立官方主页的电子游戏，可采用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)

  没事，目前回归讨论阶段，我亦欢迎其他人介入这段讨论。如果观点是任何引流皆不可接受，我感觉牵扯Category:外部资源模板中的太多模板。社群对“官方性质网页”、“引流宣传问题与实用性”这两方面，可能欠缺共识。--YFdyh000（留言） 2022年8月15日 (一) 10:17 (UTC)

• 個人再斗膽嘗試補充提出(！)意見：

• 此類外部連結在《維基百科:外部連結》指引中「正常情況下應避免的連結」章節開宗明義所言的「除非是關於條目主題的官方網站，否則應該要避免」標準觀之，自當考量此前提是否符合，而非逕以該條文第四項「主要為販賣物品或服務的網頁」加以一律禁制，於《維基百科:外部連結之官方連結》章節亦另有「官方連結不受正常情況下應避免的連結所限制」；換言之，相關條文皆顯為本平台環繞此議題已具有之豁免性內容。此外，若任何有導引或增加流量之嫌的外部連結皆不妥適，以今日商業或主題性網站之多樣性而言，那大概一大半都不太能放了（笑），比如YouTube、部落格、社群媒體、新聞網站、新聞媒體的影音網站，甚至有些正式的官方網站也會統計訪客人數、瀏覽量等流量數據。

然而，縱使介紹條目主體之官方頁面未偏離主題，加以目前收錄頁面連結類型之爭點（如類似電商平台之介面和形式，顯然幾乎以宣傳銷售為主），雖然目前於相關規範中尚未明確規管甚至字面上符合規範，然而若言之為「合宜的官方網站」，又太挑戰觀者常識認知了，顯然不妥適。因此綜合而言，個人認為至今此命題仍回歸頁面是否具「官方代表性」、「主題專屬性和條目主體主導力度」，以及因時代演進如何衡量檢視「具電子商務功能之官方頁面」及其常有的商業宣傳性爭議。此三面向以今日社會之網路和商業多樣性發展，皆具一定程度難以界線分明、一言蔽之、完整含括之爭論，然而本站平台或仍需配合社會發展，嘗試約略理出不悖離常識和時代脈動之定義輪廓，或較有助於平台和社群來日之長期發展。

• 以站友舉例「華為P50系列」條目而言，相關案例例一之「華為P50系列購買頁面」，充斥行銷、促銷活動和價格，顯非適合收錄選項（大致等同電商平台之介面和形式）；例二之「華為P50系列規格參數介紹」或可用於資料來源，個人認為除提供詳盡主題資料，亦未見強烈宣傳行銷廣告等溢美文宣（雖有購買連結之類）；例三之「條目主體華為P50系列」官方主頁，所提供內容和訊息之性質、範疇和調性約介於前兩例之間，大致最符合一般人對於所謂「官方主頁」之概念，既為官方主頁，當中自帶有各式宣傳溢美之圖文，而一般讀者常理而言在拜訪閱覽此類頁面前，以現代社會之約定俗成和經驗法則亦大概已具相當的心理預期認知。

再以《與奴隸的生活 -Teaching Feeling- DLsite頁面》為例（先說一下敝人沒玩過這款遊戲，也並非對其有何特定偏好（笑）），即便個人不懂日文，也不會第一時間直接認為這根本不算官方網站；換言之，個人認為此類議題通常仍需考量一般讀者常識性判斷，究竟其「主題專屬性和條目主體主導力度」是否達到相當程度，且避免過多離題或其他商品之商業宣傳性，乃不致於挑戰觀者常識，且於現有規範和實務間求取平衡。

• 綜上所述，個人認為關鍵仍在於條目中加入具備何種標準可謂有某種程度「官方代表性」之頁面，是否損及本站所言之「中立性」？若對於加入外部連結之頁面形式仍有疑慮，個人建議或可加入部分限制條款加以規約，強化中立性，避免衍生過多無謂且顯明商業色彩之爭議，加上前面其他站友談及之各種官網版本問題，試提條文如下：

「對於沒有獨立官方主頁的電子遊戲，若有特定頁面同時符合以下條件時，可將該頁面視為此遊戲作品具官方性質之介紹主頁，或該作品於公眾領域之專屬頁面，否則不可加入：

1. 未顯明牴觸《維基百科:官方連結》指引規範。

2. 合法授權內容：該頁面介紹之主題和核心訊息顯明經作品設計、生產、製作或發行方授權認可於此頁面公開展示，且相關內容以官方提供、主導或產製關於作品之原創性訊息或素材為主。

3. 專屬主題與版面：該頁面介紹之主題和核心訊息就其內容、版面、篇幅閱覽，顯明以該作品為主體，符合一般觀者之經驗法則，未有偏離作品主體或致使一般觀者混淆內容或訊息主題之虞。一般而言，此頁面難見其他業者之商品得以共享介紹或宣傳曝光之篇幅、欄位或版面。

4. 增益資訊多樣性與讀者體驗：該頁面介紹之主題和核心訊息明顯包含有益於讀者理解或體驗該作品，惟未必易於取得或適於盡數置入條目，且由官方提供、主導或產製關於作品之多媒體訊息或素材。

5. 避免過多偏離主題之商業行銷訊息：該頁面應避免提供過多顯益於促成商業交易，卻未必有益於介紹或已悖離條目主題之行銷訊息（同時包括但不限於諸如：促銷贈品、分期付款、消費積分、會員點數、捆綁銷售、交易形式、貨運物流、售後服務等訊息）。

6. 平台知名度和代表性：該頁面所屬平台具獨立關注度。

該外部連結僅限以提及平台名稱之形式收錄，此類官方或公開專屬介紹頁面連結應以一個為限。

若同時存有不同官方性質之平台（如因地域差異、作品版本、遊玩媒介多元等因素而產生不同介紹推廣、發行銷售或上架之平台管道），導致編者認知不一，以作品首推、首售、首發之中文版本頁面優先，若無中文版本則以原產地版本為準。

若因時序遷移，導致官方消息、作品版本（如：原版本更新或補充、系列作或續作推出等）、平台定位或代表性、發行或上架管道多元性、官方性質頁面內容或其他項目更新或異動，以致編者認為既有頁面或連結之代表性隨之異動時，可逕行更新異動；若編者間有爭議則應進行討論以達成共識。」以上為個人意見，供參。--Kriz Ju（留言） 2022年8月17日 (三) 02:13 (UTC)

长篇大论先射箭后画靶，不就正好论述了您发明的“官方代表性”和“官方网站”是两码事吗？又以世间常识、时代潮流来做后盾，只能体现您难以在方针内做出解释。浪费您时间也浪费我时间，令人遗憾。->>Vocal&Guitar->>_留言 2022年8月17日 (三) 05:46 (UTC)

成文和判断标准稍显复杂，仍需个例讨论判断，但整体而言，我不反对。--YFdyh000（留言） 2022年8月17日 (三) 12:15 (UTC)

(＋)支持：Kriz Ju的方案。如果任何形式的导流都不能接受那建议删掉所有YouTube外链。--Yinyue200（留言） 2022年8月17日 (三) 03:52 (UTC)

真巧，这件事我已经做了很久了。->>Vocal&Guitar->>_留言 2022年8月17日 (三) 05:46 (UTC)

那么，IMDB、豆瓣网等也是商业性网站呢，网页会引流Hulu[3]、需购买VIP的视频网站等。我认为您的标准过严，与共识及常识不符。如果如此严格执行，参考文献也不能放链接了，绝大多数是商业网站，有“相关文章”、广告等。--YFdyh000（留言） 2022年8月17日 (三) 12:12 (UTC)

我只是在回应Youtube，目前我还不想增加其他工作内容。->>Vocal&Guitar->>_留言 2022年8月19日 (五) 00:16 (UTC)

(！)意見：敝人認為若未明顯牴觸《維基百科:官方連結》之指引，加上有站友提及今日遊戲製作生態變遷及可能的各種地域差異，且當今網站面貌相當多元，難逕以簡單文句理清實務樣態，敝人只得嘗試來個「適當準用」之概念，正面表述將通常觀者難以接受、直觀顯明的商業交易平台或頁面加以排除（所以顯非全然兩碼事（笑））；而若條文已對相關頁面連結賦予適當規範和標準才得以收錄，個人認為於平台規範上亦已適當規管且訂定收錄門檻。若有站友能以簡易標準理清箇中定義和樣態間之紛雜繁複，也是美事一樁。就我個人而言，嘗試解決或改善問題的努力，皆難以說是浪費時間，如果任何人嘗試努力都是浪費時間，那麼任何討論和行動皆不應進行，包括今日來到此站的活動和客棧功能的存在亦然（笑），更何況此命題本屬至今複雜之議題。還請諸多參與討論之站友，不吝對相關標準和規範逕行增刪補充或精編完彙，感謝。--Kriz Ju（留言） 2022年8月18日 (四) 18:44 (UTC)

現行條文 合适的外部链接－如果存在这些链接，应当在电子游戏条目中列出 电子游戏官方主页（由开发商或发行商提供）。游戏如在中文区发售应优先列出中文版主页。如果是外文游戏，还应列出首发国家的语言版本并注明网站是外语。如果开发商和发行商提供的网站不同则应一并列出。 ...

提議條文 合适的外部链接－如果存在这些链接，应当在电子游戏条目中列出 电子游戏官方主页（由开发商或发行商提供）。游戏如在中文区发售应优先列出中文版主页。如果是外文游戏，还应列出首发国家的语言版本并注明网站是外语。如果开发商和发行商提供的网站不同则应一并列出。 對於不具獨立官方主頁的電子遊戲，若有特定頁面同時符合以下條件時，可將其視為具官方性質之作品介紹主頁或專屬頁面，否则不可加入： 未顯明牴觸《維基百科:官方連結》。 合法授權內容：該頁面介紹之主題和核心訊息顯明經作品設計、生產、製作或發行方授權認可於此公開展示，且相關內容以官方提供、主導或產製關於作品之原創性訊息或素材為主。 專屬主題與版面：該頁面介紹之主題和核心訊息就其內容、版面、篇幅閱覽，顯明以該作品為主體，符合一般觀者之經驗法則，未有偏離作品主體或致使一般觀者混淆內容或訊息主題之虞。一般而言，此頁面難見其他同行業者之作品得以共享介紹或宣傳曝光之篇幅、欄位或版面。 增益資訊多樣性與讀者體驗：該頁面介紹之主題和核心訊息明顯包含有益於讀者理解或體驗該作品，惟未必易於取得或適於盡數置入條目，且由官方提供、主導或產製關於作品之多媒體訊息或素材。 避免過多偏離主題之商業行銷訊息：該頁面未大量提供過多顯益於促成商業交易，惟未必有益於介紹或已悖離條目主題之行銷訊息（同時包括但不限於諸如：促銷贈品、分期付款、消費積分、會員點數、捆綁銷售、交易形式、貨運物流、售後服務等訊息）。 平台知名度和代表性：該頁面所屬平台具獨立關注度。 此類官方或公開專屬介紹頁面連結應以一個為限。若因時序遷移，導致官方消息、作品版本（如：原版本更新或補充、系列作或續作推出等）、平台定位或代表性、發行或上架管道多元性、官方性質頁面內容或其他項目更新或異動，以致有編者認為既有頁面或連結之代表性隨之異動時，可逕行更新異動；若編者間有爭議則應進行討論以達成共識。 ...

經討論且排除不宜收錄之頁面和內容類型後，敝人嘗試綜合並彙整內容如上。請參閱，感謝。--Kriz Ju（留言） 2022年8月24日 (三) 18:50 (UTC)

“仅限以提及平台名称之形式收录”具体形式（如平台名被外链、无链接还是内链）及必要存疑，怎样解决宣传性问题与争议。“以作品首推、首售、首发之中文版本页面优先”建议不作约定，会有太多争议（简中和繁中版本并行之事；假设A地区首发，但B地区热销；假设页面中文但发售版本无中文，或反之；假设发售的是阉割版），标准十分模糊。其他不反对，但已暂时不看好该议题得出共识。--YFdyh000（留言） 2022年8月24日 (三) 20:47 (UTC)

已依意見刪修。--Kriz Ju（留言） 2022年8月24日 (三) 21:06 (UTC)

提議設立容許查看私密資訊的用戶組／flag

於Phabricator查看
編號T309318的工單

續上#提议修改维基百科:防滥用过滤器的討論，建議將查看私密過濾器資訊的權限連同新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-zhlists.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)

@Stang：可以開始討論表單的欄位了？--Xiplus#Talk 2022年8月18日 (四) 08:30 (UTC)

電視劇演員與角色排序指引

已通過：

已完成公示，將依條文進行修訂。--Kriz Ju（留言） 2022年8月23日 (二) 19:54 (UTC)

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

---

簡介	電視劇的演員排序無任何指引規範
問題背景	在編輯《基督山小姐》時，因為Wikipedia:格式手冊/電視與Template:电视节目信息框並未規範或明述演員排序如何羅列而引發編輯戰。《基督山小姐》的片尾演職員與海報排序均為：「李昭娟、崔汝珍、鮮于龍女、李晃儀、⋯⋯、金美羅、景盛煥、李尚寶、李多海、⋯⋯」，但官網首頁的출연（出演）標示「李昭娟、崔汝珍、景盛煥、李尚寶 等」，등장인물（登場人物）也是將四名演員所演的角色列在前四位，產生衝突。
我的觀點	個人傾向參考MOS:TVCAST，應以影片本身的排序為首準，如片尾完整的演職員表等，而不是非影片本身及可能無法取得完整排序的官網。以《伊甸園之東》為例，李多海在片尾演職員表或是海報中，均被列在第三位，官網改版後，中途辭演的李多海在人物介紹中被移至第八位，不符合首播時的排序。 為避免造成解讀差異，排序不得任意略過。 本人以所涉略之美、加、英、澳、臺、日、韓、港等電視劇作為案例考量，若有疏漏其他案例可提出。 在Wikipedia:格式手冊/電視制定指引後，同步於Template:电视节目信息框/doc的主演欄提及。
我的解決方案	現行條文 演員及角色資料 一般而言，電視劇條目之內，角色及演員資料會以角色表或演員表方式鋪陳。角色表段落會包含「演員」、「角色」及「角色扼要介紹」；可參考天與地 (無綫電視劇)。依據格式手冊（文字格式），演員及角色不應用粗體或斜體標示。 另外，除非有多個可靠來源佐證，否則請勿標記角色性質，例如第一男主角、第二男主角、第一女主角等。至於演員條目內，如有參演電視劇列表，亦作類似安排，如無多個可靠來源佐證，請勿羅列角色性質，應以「主演」或「配角」代替。 提議條文 演員及角色資料 一般而言，電視劇條目之內，角色及演員資料會以角色表或演員表方式鋪陳。角色表段落會包含「演員」、「角色」及「角色扼要介紹」；可參考天與地 (無綫電視劇)。依據格式手冊（文字格式），演員及角色不應用粗體或斜體標示。 另外，除非有多個可靠來源佐證，否則請勿標記角色性質，例如第一男主角、第二男主角、第一女主角等。至於演員條目內，如有參演電視劇列表，亦作類似安排，如無多個可靠來源佐證，請勿羅列角色性質，應以「主演」或「配角」代替。 演員與角色訊息（含信息框中的主演欄）一般可以正式官方網站公開發布訊息收錄，若編者因對於作品之可靠官方來源選擇或判定不一，或因其他理由，導致對於演員排序認定歧異，則依序以下列來源為依據： 影片中完整的演職員表（如片尾演職員表或片中的跑馬字幕），若影片是依出場順序排序則不適用。 影片片頭的演職員排序，若影片是依出場順序排序則不適用。 官方海報的演員名單排序。 官方網站的演員或人物介紹排序。 其他官方發行產品上的演員名單（如相關刊物、影音產品包裝等其他多媒體）。 案例： 《植劇場－荼蘼》的片頭與片尾排序不同，但以片尾完整的演職員排序為準。 《追殺夏娃》的片尾是依出場順序羅列，《想見你》的片尾僅列配角演員名單，此情況則依序參考上列排序，如前者以片中的演職員跑馬字幕為準，後者則參照片頭演職員排序。 由於日劇演職員排序多為「主演、共演1、共演2、其他1、其他2、共演3、共演4」，條目中可將共演往前排序為「主演、共演1、共演2、共演3、共演4、其他1、其他2」。 若影片有不同官方版本（如因場次、地域、再版、媒介等因素而產生不同版本），導致演員名單排序不一，以作品首播、首映、首發之原產地版本為準。而演員退出、辭演或角色身亡、刪除等，因考量資料收錄完整性，仍可保留在名單之中。
此前的類似討論	Wikipedia_talk:格式手冊/電視/存檔一#劇集條目主角次序指引草案

--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)

你只是剛好沒遇到瘋子罷了，用音樂條目來看就是一群人大吵特吵哪個音樂類型先放、哪個製作人先放（好險飯圈只會爭Ｃ位不會在乎幕後工作人員的辛勞）。 --窝法乙烷 儿法梦碎 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节目列表
我的观点	相关外购节目列表有可能会违反下面的方针 WP:NOTDB(“主题关系松散的数据库或列表”) WP:NOTIINFO(“维基百科的条目并不是过度统计清单。”) WP:VERIFY(编辑者应为条目中的内容及其引用提供可靠来源。（这些条目涉及的即将播出节目的资讯内容可能会涉及到不可查证来源（例如某家电视台的广告商节目表）以及不可靠来源（例如新浪微博网友的猜测)） 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 series、en: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)

(！)意見：敝人僅補充些許個人意見：不適單獨成條目之列表或對於未來播出節目之預告相關資料可收納至適當平台，或可使條目維護更輕鬆簡易；而可供查證且補充資料來源、具獨立成表條件者，可以修訂保留；而過度細瑣、顯將持續增生或已具備龐大集數和簡介者，不宜無限加長，亦應妥適處理。個人意見，供參。--Kriz Ju（留言） 2022年8月18日 (四) 18:09 (UTC)

提議將格式手冊/序言章節#列明來源設為方針指引

已通過：

已完成公示，將依條文進行修訂。--Kriz Ju（留言） 2022年8月23日 (二) 20:12 (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、閃亮飛月、Rastinition、SilverReaper、Ericliu1912、Kethyga、Cdip150、YFdyh000：我直接粗暴的將導言羅列來源的討論挪到評選，反正不滿意的可以投反對並表示編輯應該加來源，這方法不知道各位覺得怎麼樣。 --窝法乙烷 儿法梦碎 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)

@Ericliu1912、Nostalgiacn：寫成這樣如何？ --窝法乙烷 儿法梦碎 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、閃亮飛月、Rastinition、SilverReaper、Cdip150、BlackShadowG、YFdyh000、Ericliu1912、Kethyga、Hijk910：就以這個版本公示7日。 --窝法乙烷 儿法梦碎 2022年8月10日 (三) 16:36 (UTC)

忘了。上面回覆了一下。－hiJK910 ^{走先喇 係咁先喇 下次再玩吖} 2022年8月10日 (三) 16:50 (UTC)

所以第一段决定怎么改。第二段的修改，比原本好了一些，作为“指引”的话，暂无太大意见。不过字眼细节上，相比“相关文段可考虑不重复列出来源，只是在涉及复杂的、正在发生的、或有争议的内容时可能仍需列出来源。”，个人倾向“相关文段可以避免重复列明来源，但复杂的、正在发生的或有争议的内容可能应尽量列明来源。”。理由：“可考虑不重复”似乎暗示支持“不重复”理据，“可能仍需”语气偏弱。--YFdyh000（留言） 2022年8月10日 (三) 19:00 (UTC)

@YFdyh000：已根據閣下的意見進行修改。第一段會維持原樣，還是閣下認為有需要修改的部分？ --窝法乙烷 儿法梦碎 2022年8月16日 (二) 23: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)

最後版本如下

現行條文 列明來源 導言必須符合可供查證、生者傳記和其他方針，Wikipedia:可供查證中規定：「所有引言以及任何被質疑或可能被質疑的內容都應使用內嵌引用來提供可靠、公開的來源。」對於在世人物的任何有爭議的語句則一定要每次列明來源，包括序言章節。 由於序言章節通常會與條目主體文字的資料重複，故編者應該在避免列出多餘來源、與指導讀者至受質疑內容的來源間，取得平衡。導言通常被寫成是比條目主體層次較淺的概述，而在序言章節中無爭議的東西看似是較少會被質疑的，繼而看似是較少機會被要求列明來源；不過這不是說序言可以例外地繞過引用要求。序言是否有必要列明來源應個別地、以編者共識來處理。複雜的、正在發生的、或有爭議的事項可能需要列明來源；其他的則列出少量甚或不用列出。這裡不要求也不禁止條目的序言作出引用，而需視不同狀況而定。

提議條文 列明來源 導言必須符合可供查證、生者傳記和其他方針，Wikipedia:可供查證中規定：「所有引言以及任何被質疑或可能被質疑的內容都應使用內嵌引用來提供可靠、公開的來源。」對於在世人物的任何有爭議的語句則一定要每次列明來源，包括序言章節。 導言通常是比條目內容更為顯淺的概述，同樣需要符合可供查證等方針。序言章節一般會截取或複述條目內已經有列明來源的文段，相關文段可以避免重複列明來源，但複雜的、正在發生的或有爭議的內容可能應儘量列明來源。必要時編者可以在條目討論頁面、同行評審、互助客棧或其他討論頁面（包含評選）達成共識決定序言章節是否列明來源。簡而言之，這裡不要求也不禁止在條目的序言章節列出來源，而需視不同狀況而定。

同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)

(＋)支持--飛馬（閃亮飛月） 2022年8月17日 (三) 02:42 (UTC)

(＋)支持：但是建议明确一下最后版本是什么。--Yinyue200（留言） 2022年8月17日 (三) 03:59 (UTC)

(＋)支持。--Kriz Ju（留言） 2022年8月18日 (四) 19:16 (UTC)

---

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

提議建立中小學條目指引

學校條目當前遇到了一些問題：

1. 應涵蓋內容，迄今沒有社群共識標準（請參閱下方「此前的相關討論」一節）；
2. 經常有編者身為校友，基於忠誠、自豪，加入對學校有利、宣傳性的敘述；
3. 或是在學學生不滿，刻意破壞、加入對學校的負面評論。

因此，提議建立Wikipedia:中小學條目指引規範學校條目內容，並參考了WikiProject:學校/條目指引、Draft:英文維基百科學校專題編寫建議（上述二者均譯自英文維基百科學校專題論述，分別經過主要編者修改，基本綜合了內容指引與格式指引的性質）與歷來討論，試擬草稿，懇請賜予意見。

不將高等／大專院校納入的原因，是因為中、英文維基百科的學校專題與大學學院專題都是分開的，可見兩者性質略有不同，此處先行就較常被破壞，及條目內容詳盡程度較常有爭議的中小學部分擬定指引。

中小學條目指引是一篇內容指引，旨在規範中學、小學相關條目。

資訊框 對於中小學條目適用的資訊框，社群已經在2020年間完成整合，請統一使用{{Infobox school}}。

建議避免填寫項目

• 聯絡方式：例如電話號碼、傳真號碼、電子信箱。（維基百科不是電話簿）
• 副職領導人與臨時職位：例如副校長、副主席、代理校長。
• 尊稱：前綴或後綴字（CEO、Dr、BA、BSc、MA、PhD等）及性別用語（先生、女士）。例如：不要使用「黨委書記：王大華先生」，只需要寫出「黨委書記：王大華」就好了。

導言 條目定義句應提到該校的官方全銜、常見名稱及歷史上使用過的其他名稱，並描述其類型與位置。如：

維基百科中學，簡稱維百中學，曾稱吉米·威爾士中學，是一所位在美國加州舊金山市的私立高級中學。

原始碼小學，簡稱源小，是日本的一間公立小學，位在茨城縣潮來市。

如果該校校名的原文並非漢語，請加註原文，但如中國大陸和臺灣的絕大多數學校，其原文校名就是漢語者，則不應在第一句提到它的英文校名。

校歌歌詞 校歌歌詞應僅在確認其進入公有領域，或其他可以上傳到維基的前提下，上傳到維基文庫，並於適當處（如學校象徵章節，或末尾外部連結章節）給出連結，因為維基百科不應包含原始資料的副本。

如果校歌歌詞非自由版權釋出，允許列出其部分具有特殊意義的詞句（以有文獻專門探討該句歌詞為判定標準），但應說明其意義為何。

人物

家長會等相關組織領導者 歷任家長會長、校友會長、教師會長、學生會長等資訊，均不應列出。

教職員、學生與校友 教職員、學生與校友，都應該只在人物本身就具備關注度，且有獨立第三方來源提及這位人士與學校的關係時，才被列入學校條目中。如果滿足獨立列表的要求，可以另以列表收錄（可參閱方針《列表的概述》、指引《以地方劃分的人物列表的收錄標準》，並參考《維基百科:格式手冊/列表之內容》以及《維基百科:獨立列表之選擇標準》建立相關列表）。

在學校條目內提及這些人物時，請以敘事散文為主，盡量避免使用表格或列點。

建築與學校設施

各項學校建築與設施，除非是古蹟等特殊建築，或者在可靠來源中具背景介紹或敘述者（不含單純提及建築／設施名稱，或僅具建物樓層數、面積、建成日期等基本資料者），否則不應單獨列出。

於條目中介紹建築與設施相關背景資料時，應使用百科全書式的語調，撰寫描述性質散文，盡量避免僅以列點形式羅列各項建物的名稱，也請避免除了名稱外，僅寫出建物樓層數、面積、建成日期等統計資料。

前述「學校建築與設施」泛指校園內之建築物及其內含或附屬之設施（包含但不限於校舍、運動場（含球場）、運動館等建物，以及校舍內的實驗室、專科教室、特別教室、建物旁的庭園等設施）。

交通資訊 請避免在學校條目中列出如何到達該校、校門口設有什麼公車站，停靠有什麼路線等資訊。（互助客棧2019年7月共識參照）

學生的考試成績 有關升學考試成績表現，均不應錄入。例如：不應該提到「某高中有多少比例的學生高考在該省平均前50%」（中國大陸），也不應該提到「某國民中學全體學生均在國中教育會考獲得B以上成績」（臺灣）。

學校特色 撰寫此類文字，務必特別謹慎，以免流於宣傳、廣告。

開設課程 諸如該國語文、數學、科學、歷史這種常見科目，不應該寫出。但是，如果該校有特別的課程（例如臺灣在108課綱中規定各校都應該要有「校訂必修課」），則可以列出。

外部連結

主页面：Wikipedia:外部链接

學校條目中，請置放學校官方網站的連結，並使用{{Official Website}}或{{Url}}等模板，以統一格式。盡量使用語言代碼模板（如{{zh-cn}}）標註該網站的語言。

不要在學校條目中，加入該校社群網站專頁、影音頻道（如 Facebook, YouTube, 微博, Tiktok）帳號，除非此帳號實際上代替學校官方網站功能，且網際網路上找不到這間學校的官方網站。

參見

• Wikipedia:关注度 (组织)#教育機構：學校條目關注度適用教育機構關注度指引。
• 維基專題:學校/條目指引：更詳細的論述，但是並未經社群共識認可，僅供參考。

Category:維基百科內容指引

至於歷任校長、社團列表等先前較有爭議的部分，等待上述第一階段條文討論完畢後，再行處理。

此前的相關討論，除了已經以內部連結引用在提議條文中者，尚有：

• Wikipedia talk:香港維基人佈告板/2019年5月#多個香港中學條目被刪除大量內容
• Wikipedia:互助客栈/条目探讨/存档/2019年6月#香港中學條目編寫規範討論
• Wikipedia:互助客栈/方针/存档/2017年1月#学校、日期等条目中校友、某人诞辰内容的收录标准（註：校友部分暫時擱置，留待後續討論）
• Wikipedia:互助客栈/方针/存档/2008年9月#公司行號機關等條目不應列出詳細地址及電話

--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)

@Wpcpey、Yinyue200：謝謝提醒，上述提案的確可再商榷。不過現在中小學條目，偶爾仍會見到將校內所有建築物、設施列出清單。在中小學常見的籃球場、操場、物理實驗室、化學實驗室等，以及整棟大樓都是普通教室的建築，並沒有什麼特別之處，基於維基百科不是目錄，個人覺得可以不用錄入。

同樣地，參照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)

( ✓ )同意：有關教職員、學生與校友的提議條文，我確實認為不論是否當時學生亦需要獨立第三方來源提及，因為過去有不少香港藝人或紅人會被加入條目，亦可以避免破壞（因為如果需要加入有關人士，必需要先有來源，這樣較容易查核）。--幻柘（留言） 2022年8月19日 (五) 01:21 (UTC)

謝謝您的建議，「建築與學校設施」已經修改了，但是因為第一段還是提到了「僅具建物樓層數、面積、建成日期等基本資料者」不應列入條目中，因此還是將第二段「，也請避免除了名稱外，僅寫出建物樓層數、面積、建成日期等統計資料。」一句留住。至於「教職員、學生與校友」部分，獨立列表似乎比條目類列出有更嚴格要求，因此表述為「如果滿足獨立列表的要求，可以另以列表收錄。」具體差異見Special:Diff/73105184--S099001（留言） 2022年8月7日 (日) 11:21 (UTC)

---

經適當討論調整以此版本條文內容進行公示七日。--Kriz Ju（留言） 2022年8月14日 (日) 18:22 (UTC)

(＋)支持公示版本。--飛馬（閃亮飛月） 2022年8月17日 (三) 02:47 (UTC)

請問現在還可以提意見嗎？-游蛇脫殼/克勞棣 2022年8月17日 (三) 21:25 (UTC)

請克勞棣閣下直接提出，感謝。--Kriz Ju（留言） 2022年8月18日 (四) 17:23 (UTC)

• • • • 「原始碼小學，簡稱源小，是日本的一間公立小學，位在茨城縣潮來市。」，請問為什麼簡稱「源小」，而不是「原小」呢？簡稱用字原則上不是應取用全稱裡的用字嗎？還是純粹筆誤？
      • 請問資訊框為什麼不能寫代理校長呢？如果校長下午下班出車禍，當天晚上不治身亡，突發狀況，一個月之內難以合法產生新校長，但校務又不能一個月無人綜理，明明有人實際執掌全校，為什麼寧讓「校長=」留空，而不寫「校長=許黛麗<small>（代理）</small>」呢？我大致認同臨時職位不要寫，但是校長不是學務長、輔導主任或課程組長，他是整所學校的最高領導人，即使是代理的。
      • 以上。謝謝。-游蛇脫殼/克勞棣 2022年8月19日 (五) 01:09 (UTC)

        zh-cn:源代码;zh-tw:原始码 囧rz…… ——魔琴 [ 留言 贡献 ] 2022年8月19日 (五) 03:13 (UTC)

        • 那麼我只能說這個例子不當，「擬真性」太差。一所學校的「校名本身」如果本來就是漢字，則實務上其校名本身不應被地區詞轉換。一所臺灣的小學如果被命名為雷射國民小學，被中國大陸用戶瀏覽到，難道不該是雷射国民小学，反倒變成激光国民小学嗎？況且S099001君的原始碼就是源原並用的，因此我仍認為是筆誤。-游蛇脫殼/克勞棣 2022年8月19日 (五) 06:55 (UTC)

          那麼換個例子或許較佳。--S099001（留言） 2022年8月19日 (五) 15:24 (UTC)

(！)意見：個人認為依站友所言，收錄重要教職人員於資訊框似確實合理，亦無甚大礙，且資訊框可動態調整內容，也可供熱心編者持續維護更新。再請教原提案S099001閣下有無其他觀點或考量，或是如何小作更新，感謝。--Kriz Ju（留言） 2022年8月19日 (五) 05:53 (UTC)

收錄代理校長應該是合理的，感謝克勞棣君提出。「副職領導人與臨時職位：例如副校長、副主席、代理校長。」修改為「副職領導人：例如副校長、副主席。」代理校長是一個不當的舉例疏漏，個人原意暫時職位參考自英文維基百科學校專題論述，「temporary position」指的應該是類似於「任務編組的領導職位」，不過要描述這部分的話，一時想不到恰當條文，還是先移除了。--S099001（留言） 2022年8月19日 (五) 15:17 (UTC)

2022年8月19日，依照上述討論，修正部分條文如下（修正後全文請見Special:固定链接/73308475）：

現行條文 原始碼小學，簡稱源小 副職領導人與臨時職位：例如副校長、副主席、代理校長。

提議條文 維基小學，簡稱維小 副職領導人：例如副校長、副主席。

--S099001（留言） 2022年8月19日 (五) 15:24 (UTC)

• (？)疑問：請問「導言」一節有沒有規範香港的中學不能標註英文名？－hiJK910 ^{走先喇 係咁先喇 下次再玩吖} 2022年8月19日 (五) 16:12 (UTC)

  沒有。舉「中國大陸和臺灣」，是舉例。「但如中國大陸和臺灣的絕大多數學校，其原文校名就是漢語者」，如果改為「但原文校名就是漢語者（如中國大陸和臺灣的絕大多數學校）」，不知道能不能減輕這方面疑慮？--S099001（留言） 2022年8月20日 (六) 00:43 (UTC)

  (！)意見：一、建議將「漢語」改為「中文」；二、香港中學原文校名也是中文，只是基於英文中學制度、曾為英國殖民地、英文是官方語言等考量，認為可明文豁免香港的學校條目。三、新加坡等地可能也有這個問題。－hiJK910 ^{走先喇 係咁先喇 下次再玩吖} 2022年8月20日 (六) 03:30 (UTC)

  先行修正為「如果該校校名的原文並非中文，請加註原文，但原文校名就是中文者（如中國大陸和臺灣的絕大多數學校），則不應在第一句提到中文校名的其它語言翻譯。」（修正後全文請見Special:固定链接/73308492）：

現行條文 如果該校校名的原文並非漢語，請加註原文，但如中國大陸和臺灣的絕大多數學校，，其原文校名就是漢語者，則不應在第一句提到它的英文校名。

提議條文 如果該校校名的原文並非中文，請加註原文，但原文校名就是中文者（如中國大陸和臺灣的絕大多數學校），則不應在第一句提到中文校名的其它語言翻譯。

• 想到臺灣可能也有要不要加入臺灣話、客家話校名的問題，尚在考慮是否撤回這一段落的條文。--S099001（留言） 2022年8月20日 (六) 14:28 (UTC)

  我覺得澳門學校的葡萄牙文名稱、广西壮族自治区學校的壯文名稱等，由於這些文字與中文同為該地官方文字，形式上應可以加。--紺野夢人 2022年8月24日 (三) 18:24 (UTC)

  現改為：

導言 條目定義句應提到該校的官方全銜、常見名稱及歷史上使用過的其他名稱，並描述其類型與位置。如：

維基百科中學（英文：英語：Wikipedia High School），簡稱維百中學，曾稱吉米·威爾士中學，是一所位在美國加州舊金山市的私立高級中學。

維基小學（日文：日语：ウィキ小学校），簡稱維小，是日本的一間公立小學，位在茨城縣潮來市。

是否在條目首句以括號加註中文以外的校名，請依下列原則判斷：

• 如果該校校名的原文並非中文，請以括號加註原文。
• 學校所在地區廣泛使用中文，但亦有其它官方語言者，可以加註其它官方語言名稱。例如：澳門、新加坡兩地的學校，可以加註葡萄牙文、英文校名。
• 中國大陸少數民族自治區域，也可以加註少數民族語文校名，例如延邊朝鮮族自治州的學校，除了中文校名，還可以加註朝鮮語文校名。其它地區有類似情況者，以及臺灣的「原住民重點學校」，依此類推。
• 除了上述情況，原文校名就是中文者（如中國大陸和臺灣的絕大多數學校），不建議加註中文校名的其它語言翻譯。

• @Hijk910、Yumeto：前後差異請見Diff，現提議條文請見Draft:Wikipedia:中小學條目指引。--S099001（留言） 2022年8月25日 (四) 00:16 (UTC)

• (？)疑問：請問「學生的考試成績」禁止加入編寫升學成績的理據是？－hiJK910 ^{走先喇 係咁先喇 下次再玩吖} 2022年8月19日 (五) 16:14 (UTC)

  主要是很多時候加入的語句會被視為宣傳，如「學校2022年某某升學考試達全國PR 95以上者有15人，是全市第一」可能違反維基百科不是宣傳工具方針。英文維基百科另外有en:Wikipedia:Avoid academic boosterism，是中立方針的延伸論述，也是訂定「學生的考試成績」一節的部分依據。--S099001（留言） 2022年8月20日 (六) 01:02 (UTC)

  en:Wikipedia:Avoid academic boosterism並沒有禁止加入學生考試成績、學校排名之類的內容，只是作出規範而已。－hiJK910 ^{走先喇 係咁先喇 下次再玩吖} 2022年8月20日 (六) 03:30 (UTC)

  那麼，以草稿條文來看（「有關升學考試成績表現，均不應錄入。」），您認為直接移除草稿中該章節是否適當？--S099001（留言） 2022年8月20日 (六) 14:16 (UTC)

  已移除「學生的考試成績」章節，修正後版本見Special:固定链接/73313377。--S099001（留言） 2022年8月21日 (日) 15:36 (UTC)

• (！)意見：「影音頻道（如 Facebook, YouTube, 微博, Tiktok）帳號」應使用頓號。－hiJK910 ^{走先喇 係咁先喇 下次再玩吖} 2022年8月19日 (五) 16:17 (UTC)

  謝謝建議，上方2022-08-19條文已將該處修改。因為不影響實質內容，所以沒有更新比較條文模板。--S099001（留言） 2022年8月20日 (六) 01:09 (UTC)

• (？)疑問：請問優良條目新加坡南侨中学#学术科目符合「開設課程」一節的規定嗎？－hiJK910 ^{走先喇 係咁先喇 下次再玩吖} 2022年8月19日 (五) 16:23 (UTC)

  個人是不太了解新加坡學制，不過如果依條目所述，這些應該都是新加坡的共同科目。「開設課程」一節認為「這種常見科目，不應該寫出」。--S099001（留言） 2022年8月20日 (六) 01:09 (UTC)

• (！)意見：不認為要硬性規定不能加入校歌，如優良條目南京市金陵中学#校歌、江苏省苏州中学#校歌、池州市第一中学#校歌看起來沒甚麼問題。－hiJK910 ^{走先喇 係咁先喇 下次再玩吖} 2022年8月19日 (五) 16:25 (UTC)

(！)意見草稿並無硬性規定不能加入校歌。閣下舉的這些校歌（不只三首歌）有列出歌詞全文者，其歌詞都古老到已進入公有領域，反之，版權未到期者，只是描述其資訊，並無列出歌詞全文。故，草稿與之尚無扞挌之處。-游蛇脫殼/克勞棣 2022年8月19日 (五) 17:10 (UTC)

你再看一次，現草稿要求將歌詞全文放在文庫，僅可留下往文庫的連結。－hiJK910 ^{走先喇 係咁先喇 下次再玩吖} 2022年8月19日 (五) 17:23 (UTC)

如此說來，草稿忽略了WP:不要包含原始資料的副本的例外情況：版权自由、相对较短的文稿全文则可以在文章中全部引用。考慮到校歌歌詞通常較短（相對於散文、極短篇以上的小說、長篇詩作等），在版權自由的前提下，是否可於條目全文照錄，應重做考量。-游蛇脫殼/克勞棣 2022年8月19日 (五) 18:21 (UTC)

個人目前還是傾向不放入全文，最多引述一些詞句。就算該校校歌具有獨立關注度，而能自成一篇條目，方針WP:NOTLYRICS對於這種情況還是建議「引述歌曲應該保持合理長度，相對於條目其餘部分，且有助於討論或闡述作品風格；全文可以放在維基文庫並在條目建立連結。」像江苏省苏州中学#校歌這一章節，幾乎是以歌詞為主體，其他部分相當少。如果引述一些詞句後，讀者真的有瀏覽需求，可以點入維基文庫或學校網站繼續看剩下的歌詞。另外，音樂專題論述維基百科:歌詞和詩句同樣建議「歌曲或詩歌作品應該滿足關注度，才有必要引述詞句內容。」

「校歌歌詞應僅在...前提下，上傳到維基文庫，並於適當處...給出連結」硬性規定確實嚴格了些，待想想如何改進，或許可以將「應上傳到維基文庫，並於適當處給出連結」改為「建議上傳到維基文庫」？--S099001（留言） 2022年8月20日 (六) 14:03 (UTC)

建議加一句，「如果校歌本身或特定詞句有特殊意義的話，可以在引用參考來源佐證的前提下，合理引用部分詞句以助說明。」不建議因為長度作調整，短不代表值得收錄--——C933103(留言) 2022年8月21日 (日) 04:48 (UTC)

但是，短也不代表不值得收錄吧？對於全文已進入公有領域的短歌詞，硬性規定不能加入歌詞全文的理由是？-游蛇脫殼/克勞棣 2022年8月21日 (日) 08:17 (UTC)

不是一定不能收錄，而是視乎意義。--——C933103(留言) 2022年8月21日 (日) 08:27 (UTC)

(？)疑問要同時討論是否調整過濾器297?

如果不修改過濾器297，(＆)建議原則上禁止，有加入需要時再發起編輯請求由管理員設置相關歌詞內容至條目中。--Rastinition（留言） 2022年8月21日 (日) 08:50 (UTC)

過濾器297似乎僅針對新用戶，另外全文硬性禁止確實過於嚴苛了，提案改為：

校歌歌詞 在合乎著作權規定的前提下，可以在條目中加入校歌歌詞。有不少學校的校歌並不滿足這一情況，因此，過濾器會阻止編輯次數少於250次的編者將校歌歌詞加入條目，以避免不小心侵害著作權的情況。如果遇到這種情況，您可以將在討論頁提起編輯請求，將會有熟稔著作權規定的編輯與您討論加入歌詞是否合適。

如果您欲加入歌詞全文，基於方針《維基百科不是歌詞庫》、指引《不要包含原始資料副本》，請您考慮是否改將之寫進維基百科的姊妹計畫維基文庫。

如果校歌本身或特定詞句有特殊意義的話，可以在引用參考來源佐證的前提下，引用部分詞句以助說明其意義。注意到：如果歌詞不合乎上述著作權規定，您僅能合理使用。

現行提案全文請見Draft:Wikipedia:中小學條目指引，此次更改的差異請見Special:Diff/73354120。--S099001（留言） 2022年8月24日 (三) 12:19 (UTC)

(：)回應：感謝S099001君費心擬定規範草稿，並願察納建言，在下務必會再逐字逐詞細心地審閱、思考，以不負閣下的信任。-游蛇脫殼/克勞棣 2022年8月19日 (五) 16:32 (UTC)

如果像真光女書院#班级结构那樣，列出課程的目的為反映不同課程在不同班別所採用的教學語言的性質呢？--——C933103(留言) 2022年8月21日 (日) 04:44 (UTC)

另外，對於香港高中的選擇性科目來說，常見與否的定義為何？--——C933103(留言) 2022年8月21日 (日) 04:50 (UTC)

試改為下列條文（修正後全文，見Special:固定链接/73308848）：

現行條文 諸如該國語文、數學、科學、歷史這種常見科目，不應該寫出。但是，如果該校有特別的課程（例如臺灣在108課綱中規定各校都應該要有「校訂必修課」），則可以列出。

提議條文 請避免在條目中列出由當地教育主管機關統一規定必須教授的課程，諸如該國語文、數學、科學、歷史等常見科目，經常屬於這一種課程。但是，如果該校開設獨特的課程（例如臺灣在108課綱中規定各校都應該開設「校訂必修課」），則可以列出。

如果當地教育主管機關統一訂定必須教授某些科目，則這些科目就算「常見」，不應寫入。如果是該間學校特有的科目，便具有寫入的價值。真光女書院#班級結構的個案，看起來像是為了解釋「班級結構」而非僅列出「課程列表」，對此個人認為不屬於提案討論中「不應該寫出」的範疇。--S099001（留言） 2022年8月21日 (日) 10:22 (UTC)

在香港，高中只要求設置中文英文數學公民四科，其餘所有科目均為選擇性，包括所有普遍認知的文科和理科科目。而初中階段則只要求中國歷史科獨立設置，其餘所有科目均可由學校自行選擇如何組合。--——C933103(留言) 2022年8月21日 (日) 11:46 (UTC)

進一步修正（修正後全文見Special:固定链接/73313314）：

現行條文 請避免在條目中列出由當地教育主管機關統一規定必須教授的課程，諸如該國語文、數學、科學、歷史等常見科目，經常屬於這一種課程。

提議條文 請避免在條目中列出由當地教育主管機關①規定必須教授，或②統一規劃，允許各校決定是否教授的課程，諸如該國語文、數學、科學、歷史等常見科目，經常屬於這種課程。

上述修正條文，旨在將「是由教育主管機關規劃其授課大綱或綱要，但是各校可以自由選擇是否安排的課程」納入「建議避免寫出」範疇。實際以港、臺舉例：香港方面包含但不限於「高中各學習領域的選修科目」（第28頁），臺灣高中以下學校則僅包含「部定課程」（第8-12頁）。--S099001（留言） 2022年8月21日 (日) 15:27 (UTC)

但香港高中選修科也有部份只有幾百甚至幾十人修讀。--——C933103(留言) 2022年8月22日 (一) 16:04 (UTC)

個人仍是認為，如果是政府規定的課程，就具有共通性，可以寫在香港教育，而不需要寫在各校條目內。--S099001（留言） 2022年8月24日 (三) 12:01 (UTC)

加上應用學習科目就應該過百科了，怕會成為雜項列表--——C933103(留言) 2022年8月25日 (四) 00:34 (UTC)

修订编辑战方针（二）

已通過：

已完成公示，將依條文進行修訂。--Kriz Ju（留言） 2022年8月23日 (二) 21:10 (UTC)

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

---

问题背景

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

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

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

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

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

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

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

引言

現行條文 维基百科的页面都是透過社群讨论形成的，用户需要遵循编辑守则，协力构筑共识，如果不起效果的话，应当设法解决争论并寻求帮助。如果两位或团体多位作者就一个问题无法达成协议，因此不断地互相删改或撤銷对方的编辑內容时，就被称为“编辑战”。如果要提报参与编辑战的用户，请前往管理員通告板。 对编辑战有一个明确原则，即“回退不过三”（3RR）原则。该原则是指编者在24小时之内，不得对同一页面进行超过三次的回退动作。回退是指撤销另一编者的编辑动作，无论每次涉及内容是否一致，违反者可能会被封禁。当然，未违反“回退不过三”原则的编辑战也可能招致封禁。 編輯戰對於讀者跟編輯者都是有害的行為，试图强行维持条目的某一版本，可能会造成中立性的缺失，也可能会导致用户互相敌视，阻碍共识的形成。在警告和封禁之后仍然执意进行编辑战的用户将可能永久失去对某些页面的编辑权。

提議條文 编辑战是指两位以上编者就一个问题无法达成共识，因而不断地互相删改或撤銷对方的编辑內容的行为。編輯戰對於讀者跟編輯者都有害，试图强行维持条目的某一版本，可能会造成中立性的缺失，也可能会导致编者互相敌视，阻碍共识的形成。 参与编辑战的编者应優先考慮進行溝通，设法解决争论或寻求其他編者帮助，否則可能遭暂时或永久剥夺部分或全部页面的编辑权。处置编辑战时有一条界限供参考，即“回退不过三”（3RR）原则。该原则指出，编者在24小时之内，不得对同一页面进行超过三次的回退动作。该原则不应理解为回退频次上的合法配额；未违反“回退不过三”原则的编辑战参与者并不必然豁免管理措施。 管理员处置编辑战的基本原则是避免、制止争议行为，鼓励理性编辑，而非惩罚参与者。其它编者可通过管理員通告板提报编辑战的参与者。

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

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

什么是编辑战

現行條文 作为维基百科的一个核心理念，开放的系统可以产生高质量、中立的百科内容。但是不可避免的是，用户针对页面内容的某些方面会有不同的观点。当此类情况发生时，强烈建议编者透過文明的讨论达成共识，而不是在明知会招致反对时仍然固执己见，采取挑衅性的编辑行为，并且反复使用回退功能。后者称为编辑战。 并非所有潜在的争议编辑行为，或是回退举动，都会被指为编辑战。应当注意以下的情形： 维基百科鼓励编者勇于更新页面。一个潜在争议更改可能只是为了检测是否有反对声音，并开启讨论的手段。如果另一用户有充足的理由反对此项更改，他们可以采取回退行动。这就是所谓的更新，回退，讨论（BRD）循环，而非编辑战。只有在出现一系列非建设性，反复的编辑行为时，才構成编辑战。 回退破坏不是编辑战。注意，重复张贴明显非真实的内容（例如“恶搞”语录）或重复移除大量内容常被视作破坏行径，但是正常情况下的少量不中立观点，正常的加入或删除内容，或其他善意的修改，都不应当视为破坏。（参见破坏的类型和不视作破坏的行为）。 为了维护更重要的方针而采取的回退举动不应视作编辑战。例如，依照生者传记相关方针，为了避免对当事人造成损害，有关生者的无来源负面内容如不修改，必须移除。 如果回退了他人的修改，请确保在编辑摘要中或讨论页中指明缘由（原因显而易见除外，例如回退破坏）。未给出适当理由的回退行为很有可能被理解为是挑衅。谨记回退操作是把其他编者的工作“丢到一旁”；或许你应当考虑改善文本质量，或是与其他编者进行沟通，而不是简单的撤销更改。 请牢记，例如Twinkle、Huggle和回退功能之类的反破坏工具不宜用來撤销有关条目内容的善意修改。

提議條文 维基百科的一项核心理念在于通过公众可参与的平台产出高质量、中立的百科内容。由此不可避免的是，不同编者针对页面内容的某些方面会有不同的观点。当此类情况发生时，编者应透過文明的讨论达成共识，而不是反复撤销他人的编辑，尤其是在明知会招致反对时故意而为，以示挑衅。后者称为编辑战。 本方针范围内如无特别说明，“回退”一词均指任何在客观上撤消或部分撤消其他编者行动的编辑行为（或管理行为），不限于使用系统或工具（如Twinkle）提供的回退功能执行的操作。 本方针并非旨在消除所有具有潜在争议的编辑行为乃至回退举动。相反，本站鼓励编者大胆更新页面。某名编者进行编辑后，如有另一编者因充足的理由而反对此项更改，他完全可以采取回退行动，并展开沟通化解问题。这就是所谓的更新，回退，讨论（BRD）循环。这种良性循环并非编辑战。只有在出现一系列非建设性，反复的回退行为时，才構成编辑战。 例外 此外，下列回退行为即使反复发生，也不应纳入编辑战的考量： 回退自己账户的编辑（“自我回退”）。 回退在自己用户空间中的编辑，前提是您必须遵守用户页指引。 回退明显的破坏行为，即指任何一个假定他人的编辑是出于善意的编者都会认为是破坏的编辑（例如无故清空页面、重复张贴明显非真实的内容、屡次添加攻击谩骂文字等）。但是正常情况下的少量不中立观点，正常地加入或删除内容，或其他善意的修改，都不应当视为破坏。（参见破坏的类型和不视作破坏的行为）。 为了维护更重要的方针，特别是法律相关方针，而采取的回退举动。例如，移除明显违反本站著作权方针、儿童色情、非主动公开的个人资料等涉嫌违反维基媒体服务器所在地法律的内容。移除明显违反生者传记方针的内容的回退（例如移除关于在世人物涉嫌诽谤、非中立、无来源或来源不充足的争议内容）也适用本条。但對於刪除何種內容可享有生者傳記方針豁免本身可能會存有爭議。遇有不清晰或有爭議，建議不要依賴此豁免。 为了确保在首页展示的典范条目和优良条目的质量而进行的回退操作，给予编者一定的自由空间。

• 本章节合并了现行方针3RR部分的豁免原则，并将其另立为子章节“例外”加以阐述。在合并时，例外原则的措辞有一定调整：
  1. “回退自己的编辑”修改为“回退自己账户的编辑”：显然回退自己的合法分身帐户（例如机器人帐户）的编辑不应纳入编辑战的考量，故有此修改。
  2. “维护更重要的方针”“而采取的回退行动”补充说明“特别是法律相关方针”：列举的“受豁免”方针实质上均是本站的法律方针，故有此澄清。
  3. “移除涉嫌诽谤、非中立、无来源或来源不充足，违反生者传记方针的争议材料”调整措辞并入上一条：解决前一案的问题。
• 同时，本章节也合并了现行方针中，所有涉及“回退的定义”的内容，将其另立章节加以交待：“本方针范围内如无特别说明，‘回退’一词均指任何在客观上撤消或部分撤消其他编者行动的编辑行为（或管理行为），不限于使用系统或工具（如Twinkle）提供的回退功能执行的操作。”
• 此外还有一些措辞方面的细微调整。

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

编辑战的处理

現行條文 参与编辑战的用户很可能（通常在编辑战发生后）被封禁，以防止进一步的争端。尽管所有的编辑战行为都有可能导致此种处理，但有一条常用作封禁的明确界线——称作“回退不过三”（3RR）的原则。具体内容如下： “回退不过三”原则   「WP:3RR」重定向至此。關於處理編輯爭議的管理員布告板，請見「维基百科:管理员布告板/编辑争议」。 根据“回退不过三”原则： 一个“页面”意指维基百科上的所有页面，包括讨论页和计划空间。 这里提到的一次“回退”是指任何取消其他用户行动的编辑行为（或管理行为），无论是全页面还是部分内容。可能有的时候只是一个词的变动。在没有其他用户编辑的情况下，一个用户连续的一系列回退编辑视作一次回退。下述行为在适用回退不过三原则时，不视為一次回退： 回退自己的编辑（“自我回退”）。 回退在自己用户空间中的编辑，前提是你必须遵守用户页指引。 回退明显的破坏行为，即指任何一个假定他人的编辑是出于善意的用户都会认为是破坏的编辑，例如清空页面或是添加攻击性语言。 移除明显侵犯著作权，或是毫无疑义违反合理使用方针的内容。 移除明显违反维基百科服务器所在地——美国佛罗里达州法律的内容，例如儿童色情内容或盗版软件。 移除涉嫌诽谤、非中立、无来源或来源不充足，违反生者传记方针的争议材料。對於刪除何種內容可享有生者傳記方針豁免而不受回退不過三限制可能會存有爭議。遇有不清晰或有爭議，則建議先行提報至互助客棧，而非依賴前述豁免。 为了确保在首页展示的典范条目和优良条目的质量而进行的回退操作，给予用户一定的自由空间。 如果你认为自己的行为属于上述例外，请确保留下明确的编辑摘要或在讨论页的单独分段中阐明例外的原因。如果没有把握，请不要回退。可以代之以尝试解决争论，或者还可以针对特定的问题，前往相应的通告板求助，例如当前的編輯爭議提报页面。 如果出现四次或更多次的回退，无论每次针对的是否是同一段内容，都构成违反“回退不过三”原则。该原则按人计算，不按编辑次数计算；由多重帐号所做的回退按同一人计算。 初犯该方针的用户通常会被封禁24个小时。 切记管理员可能在任何时间，对他们认为构成进行编辑战的用户采取行动。即使在未违反回退不过三原则时，任何用户也都可以提报编辑战。该原则并不是给回退页面一个特定数量的配额。 如果编者无心违反了“回退不过三”的原则，他们应当撤销自己最近的回退行为。例如，某个用户并不是经常性引起争端的编者，并且真诚的希望纠正自己的过失，管理员就可以将此考虑在内，并决定此种情况不再予以封禁。 其他回退规则 针对特定编者和／或特定页面，有时社群（参见Wikipedia:编辑禁制方针）会对其采取额外的回退限制。可能会用诸如1RR（回退不过一）或者0RR（回退零容忍）等术语指代这样的规则。“回退不过一”类似于上面所说的回退不过三，但是“多于一次回退”取代了原来规则中的“多于三次回退”。“回退零容忍”是指完全禁止进行回退操作（这其实是回退不过三原则的初衷）。 有时，编者会志愿执行更为严格的回退准则，或者是为了应对某一领域的问题，或者是作为自己的一种编辑哲学。详情参见Wikipedia:仅在必要时进行回退。

提議條文 参与编辑战的编者很可能因编辑战而被剥夺编辑权限，以防止进一步的争端。尽管所有的编辑战行为都有可能导致此种处理，但有一条常用作判断的明确界线——称作“回退不过三”（3RR）的原则。具体内容如下： “回退不过三”原则   「WP:3RR」重定向至此。關於處理編輯爭議的管理員布告板，請見「维基百科:管理员布告板/编辑争议」。 本原则所述“页面”包括本站所有页面，包括讨论页和计划空间。 本原则所述“回退”不计入属例外情形的回退。 在没有他人编辑的情况下，特定编者对特定页面连续的一系列编辑视作一次编辑；如其总体效果涉及回退，则计为一次回退。 如果出现四次或更多次的回退，无论每次针对的是否是同一段内容，都构成违反“回退不过三”原则。该原则按人计算，不按编辑次数计算；由多重帐号所做的回退按同一人计算。 初犯该方针的编者通常会被封禁24个小时。 切记该原则并未给回退行为赋予特定频次的配额。未违反回退不过三原则的编辑战仍然是编辑战；如有必要，管理员仍可能在任何时间对其参与者采取适当的行动，任何编者也可以将其提报至管理员布告板。 其他回退规则 针对特定编者和／或特定页面，有时社群（参见Wikipedia:编辑禁制方针）会采取更为严格的回退限制。例如1RR（回退不过一）或者0RR（回退零容忍）。“回退不过一”类似于上面所说的回退不过三，但是“多于一次回退”取代了原来规则中的“多于三次回退”。“回退零容忍”是指完全禁止进行回退操作（这其实是回退不过三原则的初衷）。 即使未有明确规定或社群共识，编者也可能主动执行更为严格的回退准则——或者是为了应对某一领域的问题，或者是作为自己编辑哲学的一部分。详情参见Wikipedia:仅在必要时进行回退。

• 本节修订后删去了与上一节冗余的“豁免”、应归属于下面的“管理员指引”等内容，并调整了相应的字句。一处比较明显的修订是，“在没有其他用户编辑的情况下，一个用户连续的一系列回退编辑视作一次回退”更改为“在没有他人编辑的情况下，特定编者对特定页面连续的一系列编辑视作一次编辑；如其总体效果涉及回退，则计为一次回退。”很显然现行版本的条文存在这样的漏洞：一名用户先回退了另一名用户的编辑，然后又撤销了自己的回退，按现行方针这“连续一系列回退”仍然会被计作一次回退。但这并不合理。

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

应对编辑战行为

現行條文 发现编辑战你应当采取的行动 如果发生编辑战，参与者应当尝试在讨论页上讨论争论议题，并努力化解分歧 与其打编辑战，不如把重心放在争论议题上，寻求帮助。当分歧变得明显时，参加编辑战的一方或双方应当停战，并尝试通过对话页讨论该议题，或者通过适当途径寻求帮助。 如果出现即使努力尝试化解矛盾，参与的一名或多名用户仍然不肯罢休，拒绝协作，无视提供给他们的信息，或是不愿采取适当的解决争论的方法，则应通过向当前的破坏提报，请求管理员介入。此时并不一定需要进行警告，但如果用户表现出对“不允许编辑战”此一方针的不了解，可以通过在其对话页中挂上{{subst:uw-3rr}}信息模板来提示他们。如果你本人牵涉进编辑战中，请避免使用通用警告模板，以防止被视作是在挑衅。可以考虑自行撰写一条适当的留言，并明确地表示希望化解矛盾。 有经验的编者如何避免涉入编辑战 一般而言，交流是避免争端的良方：请务必遵守编辑守则。当发现存在争论时，避免仅通过编辑摘要交流，而应当前往条目的讨论页进行协商。讨论的争论的主要途径应是该条目的讨论页，这样当管理员检讨此事时，可以在其中发现试图解决争论的证据。 有必要提醒您，在维基百科没有最后期限，用户可以添加适当的清理标记来指出根据现有讨论存在问题的段落。如果讨论没有结果，可以在更广的范围内（如：互助客棧）征求意见，以达成和解。得知争论的中立编者会协助限制不良编辑，并协助建立共识。如果这些方法都以失败告终，请寻求非正式或正式方法解决争论。 许多有经验的编者会刻意只对上述的例外排除编辑进行回退，或者只进行一次回退；如果有更多的争论，他们会寻求对话或外部帮助，而非让局面恶化。如果希望只在上述例外排除情形才进行回退，参见仅在必要时回退。该策略针对一些争议性话题特别恰当，因为当观点两极分化，情绪激动时，编辑战也会更加频繁地发生。 记住底线：使用常识进行判断，不要参与编辑战。与其反复回退，不如同他人讨论；如果回退是必要的，另一名用户或许也有同样的想法并付诸行动（你并没怂恿他），这样针对此行为就产生了共识。另外，请求保护页面比起通过回退参与争论要明智的多。

提議條文 如果发生编辑战，参与者应当尝试在讨论页上讨论争论议题，并努力化解分歧 如何避免涉入编辑战 请务必遵守编辑守则，谨慎回退：谨记回退操作是把其他编者的工作“丢到一旁”。在“回退”之外，您还有“改善”、“与其他编者先行沟通”等其他选项。许多有经验的编者会刻意只对上述的例外排除编辑进行回退，或者至多进行一次回退；如果争议持续，他们会寻求对话或外部帮助，而非让局面恶化，参见仅在必要时回退。该策略针对一些可预期会引起编辑争议的话题（例如：该话题在现实世界中观点严重两极分化且双方阵营互不相让）特别恰当。 如果您确实要回退他人的修改，也请确保在编辑摘要中或讨论页中指明合理的缘由（原因显而易见除外，例如回退破坏）。未给出适当理由的回退行为很有可能被理解为是挑衅。Twinkle、Huggle和系统自带的回退功能之类的反破坏工具不应用來回退善意修改。 若编辑争议已经出现，请避免通过编辑战来解决；若编辑战已经发生，您应当立即停战。一般而言，良好的沟通仍然是化解争端的关键。通过回退编辑摘要交流并非良好的沟通方式。您应当前往讨论页进行协商，这样当其它编者乃至管理员参与时，可以在其中发现试图解决争论的证据。请避免使用通用警告模板或反破坏工具提供的警告功能跟对方“沟通”，这可能被视作挑衅；您可以考虑手工在对方用户讨论页撰写一条适当的留言，并明确地表示希望化解矛盾。此外，您还可以主动撤销自己最近的回退行为。 有必要提醒您，在维基百科没有最后期限，“短期内化解争议”并非必然能达成的目标。编者可以添加适当的清理标记来指出根据现有讨论存在问题的段落。如果讨论页对话没有结果，可以在更广的范围内（如：互助客棧）征求意见，以达成共识。得知争论的第三方编者会协助限制不良编辑，并协助建立共识。如果这些方法都以失败告终，请寻求非正式或正式方法解决争论。 记住底线：使用常识进行判断，不要参与编辑战。与其反复回退，不如同他人讨论；如果回退是必要的，另一名编者或许也独立地产生了同样的想法并付诸行动，这样针对此行为就产生了共识。另外，请求保护页面比起通过回退参与争论要明智的多。 发现他人编辑战您可以采取的行动 避免貿然參戰。您可以把重心放在争论议题上，尝试调解矛盾，必要时寻求帮助。若努力尝试化解矛盾后，参与的一名或多名编者仍然不肯罢休，拒绝协作，无视提供给他们的信息，或是不愿采取适当的解决争论的方法，您可通过向管理员通告板提报，请求管理员介入。此时并不一定需要进行警告，但如果编者表现出对“不允许编辑战”此一方针的不了解，可以通过在其对话页中挂上{{subst:uw-3rr}}信息模板来提示他们。

• 现行方针中“发现编辑战你应当采取的行动”子章节既叙述了编辑战参与者的行为，也叙述了第三方编者的行为，“有经验的编者如何避免涉入编辑战”子章节主要阐述编辑争议和编辑战参与者的行为，行文较为混乱。本次修订将其整理为“如何避免涉入编辑战”和“发现他人编辑战您可以采取的行动”，分别为“参与者”和“第三方用户”提供指引。
• 修改后“第三方用户”的指引中，除了“不要参战”唯一一条严厉措辞，其它现行方针中针对第三方用户的严厉措辞，如“你应采取的行动”，均软化为“可以”、“可”——毕竟没有理由“要求”留意到编辑战的用户参与调解或进行举报。
• 而涉及“参与者”的指引，则按照争议的发展态势整理并阐述：“谨慎回退，考虑回退之外的选项”、“如果需要回退，除非理由显而易见否则请指明回退理由，勿用反破坏工具回退善意编辑”、“如确实出现编辑争议/编辑战，请避免/立即停止编辑战，考虑沟通化解争议，请手动留言、勿向对方挂警告当沟通，考虑主动撤销回退”、“如讨论未见共识，考虑解决争论的其它途径”。

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

管理员指引

現行條文 管理员决定对于编辑战参与用户是予以警告还是封禁或編輯禁制；采取这些行动是为了避免、制止争议行为，鼓励理性编辑，而不是为此惩罚用户。初次封禁可能是因为违反回退不过三原则或是有编辑战行为，而持续的编辑战行为会导致进一步的封禁。当适应采取封禁手段时，对于初犯通常给予24小时的封禁期；管理员对于累犯者或是挑衅意味明显的违反者可能会延长封禁期，同时还会考虑其他因素，如文明。当出现多个用户参与编辑战或违反3RR时，管理员应该通盘考量，否则不公正的处理可能会让事端扩大。 管理员的行动主要是为了警告正在进行中的编辑战。如果编辑战已经明显结束，没有明显地或可预见的进一步行为时，可以考虑采取警告或（对于反复的情形）其他管理手段，例如在告示板中进行讨论或保护页面。累犯可能会发现自己因为最近的一次编辑战而被封禁；这种情形下，封禁不是对过去编辑战的阻止或是对上次监管的补偿，而是对其进行的威慑和强制教育，防止其在未来再次发起编辑战。（参见封禁的用途和方针） 本方针和“回退不过三”原则，都是为了防止和限制编辑战而设计的。它们不是配额制，不是鼓励用户将回退作为一种编辑技巧。进行扰乱性编辑的用户即便没有违反3RR，也仍然会因编辑战受到封禁，特别是当他们在回退页面时试图游戏维基规则。管理员会将用户在过去涉及编辑战的封禁记录考虑在内，常常会在出现仅仅出现破坏或编辑战行为时就采取行动。 管理员在尝试解决争论的时候，常常需要判定行为是否为编辑战。总体而言，没有共识或充分讨论支持的反复回退，以及其他常见形式的破坏性和扰乱性行为更可能被判定为编辑战。这样的判定常常要考虑用户是否表现出故意地阻止他人编辑的行为，尤其是通过游戏维基规则有意为之，以及采用其他更加有计划或性质更为恶劣的手法，如通过间断性地回退进行一场缓慢的编辑战，不恰当地与其他用户联手回退、滥用多重帐号或是挑衅式地反复使用回退。

提議條文 管理员决定对于编辑战参与者是予以警告还是封禁或編輯禁制；采取这些行动是为了避免、制止争议行为，鼓励理性编辑，而不是为此惩罚编者。初次封禁可能是因为违反回退不过三原则或是有编辑战行为，而持续的编辑战行为会导致进一步的封禁。当适宜采取封禁手段时，对于初犯通常给予24小时的封禁期；管理员对于累犯者或是挑衅意味明显的违反者可能会延长封禁期，对于不常引起争端且真诚改过的违反者可能会免除封禁。同时还会考虑其他因素，如文明。当出现多个编者参与编辑战或违反3RR时，管理员应该通盘考量，否则不公正的处理可能会让事端扩大。 管理员的行动主要是为了警告正在进行中的编辑战。如果编辑战已经明显结束，没有明显地或可预见的进一步行为时，可以考虑采取警告或（对于反复的情形）其他管理手段，例如在告示板中进行讨论或保护页面。累犯可能会发现自己因为最近的一次编辑战而被封禁；这种情形下，封禁不是对过去编辑战的阻止或是对上次监管的补偿，而是对其进行的威慑和强制教育，防止其在未来再次发起编辑战。（参见封禁的用途和方针） 本方针和“回退不过三”原则，都是为了防止和限制编辑战而设计的。它们不是配额制，不是鼓励编者将回退作为一种编辑技巧。进行扰乱性编辑的编者即便没有违反3RR，也仍然会因编辑战受到封禁，特别是当他们在回退页面时试图游戏维基规则。管理员会将编者在过去涉及编辑战的封禁记录考虑在内，常常会在出现仅仅出现破坏或编辑战行为时就采取行动。 管理员在尝试解决争论的时候，常常需要判定行为是否为编辑战。总体而言，没有共识或充分讨论支持的反复回退，以及其他常见形式的破坏性和扰乱性行为更可能被判定为编辑战。这样的判定常常要考虑编者是否表现出故意地阻止他人编辑的行为，尤其是通过游戏维基规则有意为之，以及采用其他更加有计划或性质更为恶劣的手法，如通过间断性地回退进行一场缓慢的编辑战，不恰当地与其他编者联手回退、滥用多重帐号或是挑衅式地反复使用回退。

• 主要是并入了现行方针“3RR”章节中的内容。--Antigng（留言） 2022年8月5日 (五) 13:57 (UTC)

讨论区

该修改妥否？请社群审议。--Antigng（留言） 2022年8月5日 (五) 13:57 (UTC)

• (＋)支持及(！)意見：敝人認為明晰易讀且釐清補充實務考量，同時希望能就以下條文字面稍作補充：
  • 對於「引言」的「參與編輯戰的編者可能暫時或永久剝奪部分或全部頁面的編輯權。」：個人傾向稍加補充調整為「参与编辑战的编者应優先考慮進行溝通，设法解决争论或寻求其他編者帮助，否則可能遭暂时或永久剥夺部分或全部页面的编辑权。」
  • 對於「什麼是編輯戰」的「本方針並非旨在規避所有具有潛在爭議的編輯行為乃至回退舉動。」：個人傾向使用表達中性之功能性的「消除」，稍調整為「本方針並非旨在消除所有具有潛在爭議的編輯行為乃至回退舉動。」。
  • 對於「應對編輯戰行為」之「發現他人編輯戰您可以採取的行動」的「不要參戰。」：由於對應前文提及「如果回退是必要的，另一名編者或許也獨立地產生了同樣的想法並付諸行動」，為避免讀者在理解上可能產生之判斷模糊空間，且內文已多次提醒讀者可能產生之風險和代價，個人傾向稍調整為「避免貿然參戰。」。--Kriz Ju（留言） 2022年8月7日 (日) 00:50 (UTC)
• 基本(＋)支持：感謝閣下所做之整理。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年8月7日 (日) 04:22 (UTC)

基本(＋)支持，题外话：那个用户又以“诽谤”为由打编辑站了。--QiuLiming1（留言） 2022年8月13日 (六) 19:17 (UTC)

• 未見顯明扞格之理據，敝人代為微調彙整上方意見至相關條文，以大致屬於事實性修訂之提議版本條文公示七日。--Kriz Ju（留言） 2022年8月16日 (二) 19:17 (UTC)
  • (＋)支持您的修改。--Antigng（留言） 2022年8月17日 (三) 05:18 (UTC)

---

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

修訂傀儡方針涉法律威脅之字樣

已通過：

已完成公示，將依條文進行修訂。--Kriz Ju（留言） 2022年8月23日 (二) 20:47 (UTC)

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

---

現行條文 警告：滥用多重账号严重违反了社群对您的信任，将很可能导致您所有曾使用的账号和IP地址被封禁。（在极端情况下，操作傀儡的账号会被永久封禁，不得再参与维基百科的编辑。）此外，其他维基人可能提议将此事转交您所在地的相关执法部门处理。这将会严重影响您的雇主、朋友、家人及传媒对您在网上活动方面的看法。故此，请勿滥用多重账号。

提議條文 警告：滥用多重账号严重违反了社群对您的信任，将很可能导致您所有曾使用的账号和IP地址被封禁。（在极端情况下，操作傀儡的账号会被永久封禁，不得再参与维基百科的编辑。）

如題。--WMLO（留言） 2022年8月8日 (一) 02:10 (UTC)

(＋)支持。桐生ここ★[讨论] 2022年8月8日 (一) 02:12 (UTC)

(＋)支持。--Wikij1089（留言） 2022年8月8日 (一) 12:38 (UTC)

(＋)支持。--YFdyh000（留言） 2022年8月9日 (二) 05:51 (UTC)

(！)意見：法律追責的描述，能說一下原來為何會有一段嗎？也許以前發生過一些事情，所以才有這一段，也許有必要性。--Nostalgiacn（留言） 2022年8月10日 (三) 11:53 (UTC)

2010年4月9日加入，参考Wikipedia_talk:傀儡/档案1，是该页面在中文维基百科确立为方针的第一版。同时期的英文维基页面有同等内容，是翻译而来。2010年10月19日，英文维基一名用户删掉了该内容。--YFdyh000（留言） 2022年8月10日 (三) 12:23 (UTC)

我還以為是出現過法律訴訟的案件，特意加上一段類似免責提醒的內容。畢竟美國是訴訟大國。原來只是翻譯自英維，沒事了。--Nostalgiacn（留言） 2022年8月11日 (四) 06:13 (UTC)

(＋)支持。--CuSO₄ 2022年8月11日 (四) 07:13 (UTC)

(＋)支持。--Kriz Ju（留言） 2022年8月13日 (六) 21:15 (UTC)

• 因經過適當討論，現以修訂版本內容公示七日。--Kriz Ju（留言） 2022年8月18日 (四) 17:32 (UTC)

(＋)支持。--飛馬（閃亮飛月） 2022年8月22日 (一) 13:26 (UTC)

---

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

可靠来源方针增加用户生成内容

Wikipedia:可靠来源:

現行條文 BBS和新闻组的帖子、Wiki的内容或者Blog上的留言都絕不能成为可接受的一次或者二次来源。这是因为我们无法知道它们究竟是谁写的。对于Wiki的情形，文章的内容可能在任何时刻发生变化，而且没有编辑人员监管或者第三方核查事实。

提議條文 用户生成内容通常是不可靠的。因为这些内容可能在任何时刻发生变化，而且没有编辑人员监管或者第三方进行事实查核。个人网站、博客、网络论坛、社交媒体、粉丝网站、视频分享网站、网络相册、wiki通常都含有用户生成内容。 在部分社交媒体中会有帐户认证，以表明某个社交媒体账户由真实个人或组织拥有并运营。在这种情况下，该账号的可靠性可能继承自这个人或组织本身的可靠性。

Wikipedia:可供查證：

現行條文 任何人均可自创网站或自费出书，并借此声称自己是某领域的专家。因而，绝大多数个人出版之书籍、业务通讯、个人网站、开放性wiki、博客、论坛贴文及类似来源均不得被认可为可靠来源。。

提議條文 任何人均可在网络上发表言论或自费出书，并借此声称自己是某领域的专家。因而，绝大多数个人出版之书籍、业务通讯、个人网站、开放性wiki、博客、论坛贴文、社交媒体及类似来源均不得被认可为可靠来源。

此前的相关讨论：Wikipedia:可靠来源/布告板#所有社群媒體的來源是否可靠？、Wikipedia:可靠来源/布告板/存档/2021年10月#2021年10月#微信公众号的來源是否可靠？。 --Steven Sun（留言） 2022年8月13日 (六) 14:22 (UTC)

• (！)意見：不是所有第一手來源都有帳戶認證。－hiJK910 ^{走先喇 係咁先喇 下次再玩吖} 2022年8月13日 (六) 16:10 (UTC)

  来源可靠性与账号是否认证，可能并无绝对关联。重点是内容是否被监督审查。--YFdyh000（留言） 2022年8月13日 (六) 22:08 (UTC)

  根据先前讨论，似乎只有YouTube和Facebook存在大量因订阅数不足而无法认证的问题。我觉得应该在WP:RSP单独说明YouTube这种特殊情况，而不是在可靠来源方针中列出。毕竟该提议的条文为：用户生成内容通常是不可靠的。并没有禁止所有用户生成内容。--Steven Sun（留言） 2022年8月14日 (日) 00:16 (UTC)

  Twitter也很多。另外，影片分享網站需地區詞轉換。－hiJK910 ^{走先喇 係咁先喇 下次再玩吖} 2022年8月14日 (日) 06:52 (UTC)

  中国大陆的社交平台也有类似的问题（例如某些官方认证的账号用是个人名义注册）--我永远喜欢搭档对战 2022年8月14日 (日) 07:49 (UTC)

“该账号的可靠性继承自这个人或组织本身的可靠性”建议改为“该账号的可靠性可能继承这个人或组织本身的可靠性”，有时某些断言会出现疑虑。其他方面基本支持，虽然修改后可能读者必须理解“用户生成内容”的准确意义。--YFdyh000（留言） 2022年8月13日 (六) 22:03 (UTC)

已修改。--Steven Sun（留言） 2022年8月13日 (六) 23:42 (UTC)

(※)注意：提议条文并没有完全禁止使用用户生成内容。允许给特殊情况留出讨论空间。相反的是，现有条文认为：BBS等...“都绝不能成为可接受的一次或者二次来源”--Steven Sun（留言） 2022年8月14日 (日) 08:13 (UTC)

(！)意見認為該修正案可能反映一定對觀點之審查偏好且更易受濫用，需要限制有關條文之適用條件和範圍。一個方面看使用者發佈內容二元而言也可分門為虛構和非虛構兩類，有關事實查核和帳戶認證等條件應當前置、是可更好防止條文被不當任意使用之；另傳統媒介或其他受認證機構等可能發佈特定所謂「用戶生成內容」之，有關若依足WP:PSTS及WP:SYN等具認受屬性，相信亦不應受本地既有或擬定條文之制限。建議基於發佈之確鑿個人、團體或代理人等之查核及信譽等綜合水平，作為來源檢視之尺度。--約克客（留言） 2022年8月14日 (日) 08:28 (UTC)

• (＋)支持及(！)意見：或可考慮稍作彙整站友意見微調為：

「由於缺乏事实查核以及普遍有效的帐户认证，用户生成内容通常是不可靠的。因为这些内容可能在任何时刻发生变化，而且没有编辑人员监管或者第三方进行事实查核。个人网站、博客、网络论坛、社交媒体、粉丝网站、视频分享网站、网络相册、wiki通常都含有用户生成内容。

在部分社交媒体中会有帐户认证，.....（後略）」個人意見，供參。--Kriz Ju（留言） 2022年8月18日 (四) 23:16 (UTC)

挺好。但不知道最终写哪个版本。--YFdyh000（留言） 2022年8月19日 (五) 03:17 (UTC)

(＋)支持--唔好阻住我愛國（留言） 2022年8月19日 (五) 07:53 (UTC)

值得留意的是Meta旗下的社群媒體連結均無法存檔，因為Meta已為機器人IP（包括VPN及網際網絡博物館）設下過濾器，相關IP的使用者必須登入方能閱讀帖文。--唔好阻住我愛國（留言） 2022年8月19日 (五) 07:58 (UTC)

WP:修订版本删除小修订

現行條文 在英文版维基百科，修订版本删除功能适用于管理员和监督员。

提議條文 在中文维基百科，修订版本删除功能适用于管理员和监督员。

不知道为什么要提英文维基百科--QiuLiming1（留言） 2022年8月13日 (六) 19:19 (UTC)

要不要提WP:行政员--YFdyh000（留言） 2022年8月15日 (一) 04:29 (UTC)

(＋)支持小修訂執行。-Kriz Ju（留言） 2022年8月16日 (二) 20:11 (UTC)

已修改，这种小修订应该不需要公示吧。--QiuLiming1（留言） 2022年8月21日 (日) 21:05 (UTC)

提議將格式手冊/音樂排行榜設為指引

@Billytanghh、JShipster、Abcet10、Zack2021、愛子棋枰、Naverad、Yumeto、Joshua Zhan、Edwardzo、AT：@NTUPikachu、百战天虫、Arivgao、Leehsiao、Cceellur、Will629、Bbene98、Renamed user Jy43acE5MQ8uh03Dig、Knowledgeism、Sinsyuan：敝人作了篇指引展示榜單表格如何撰寫，還請各位給點意見。 --窝法乙烷 儿法梦碎 2022年8月14日 (日) 06:40 (UTC)

@Austin Zhang、Pseudo_Classes、生米一粒、Sanmosa、卡達、Jacklamf1d14、Hijk910、Joker6666、JuneAugust、Za9941：@翰翔、恩力、Tw drama、Apple v、Billytanghh、Hisa312、Fake12345、Hikki、Drippinpunch、BRDN：人有點多，容我分次處理。 --窝法乙烷 儿法梦碎 2022年8月14日 (日) 06:48 (UTC)

@Easterlies、EclipsedL、CBNWGBB、H2226、Jarodalien、ByMeng、Kv626、Punkhippie、Detective Akai、Ryti😈M：@Nrya、Paristung、Crowley666、Kunamazuka、陳寅恪、Inoari、FredYYoo、Nnnupp：常和榜單打交道的應該就這麼幾位了。 --窝法乙烷 儿法梦碎 2022年8月14日 (日) 07:02 (UTC)

• (！)意見：榜單排列順序方面，認為原產地應該排最頭。另外，「表格不該以任何形式詳細羅列作品排名變遷和走勢」是否已取得社群共識？我自己並不太同意這點，排名變遷和走勢不一定是不經篩選的資訊收集處，例如：en:Gangnam Style#Viral spread，走勢本身可以是對主題的有效介紹。－hiJK910 ^{走先喇 係咁先喇 下次再玩吖} 2022年8月14日 (日) 06:56 (UTC)
  • 應該排最頭的「最頭」是甚麼？至於走勢，老實說我腦中浮現的狀況是E先生 連環不幸事件，當然目前尚未取得共識，所以才ping各位看看怎麼處理。 --窝法乙烷 儿法梦碎 2022年8月14日 (日) 07:05 (UTC)
    • 「最頭」（最前、最先、第一）即獨立於「依據每個國家的英文字母順序排列」規則以外，放在榜單排列的首項。至於走勢，我表達了我的立場了，先讓子彈飛一會。－hiJK910 ^{走先喇 係咁先喇 下次再玩吖} 2022年8月14日 (日) 07:10 (UTC)
      • 感謝回復。原產地這詞有點籠統，你這裡的定義是考量到作詞作曲家等幕後人員還是單指藝人（歌手和團體），此外產地是依據人員國籍、主要活動地點還是兩者皆是。 --窝法乙烷 儿法梦碎 2022年8月14日 (日) 07:39 (UTC)
        • 認為應以常識上，或者一般語感上，用「這是甚麼地方的作品」的「甚麼地方」作判斷。通常會是發行地點，有時會是主唱藝人的根據地。－hiJK910 ^{走先喇 係咁先喇 下次再玩吖} 2022年8月14日 (日) 07:47 (UTC)
          • 我對部分人的常識感到擔憂。除了這沒有過往案例，我認為執行方面有困難：
          • 馬來西亞歌手梁靜茹主要活動於台灣，因此其專輯排行成績以台灣為先。
          • 少女时代成員Tiffany於韓國經紀公司期間發行的作品成績以韓國為先，她之後透過環球發行的專輯成績改以美國。
          • 作為美國人宇多田光主要活動於日本，其日語專輯排行成績以日本為先，美國活動時的專輯成績需改用美國，那麼她最新於全球推出的雙語專輯該算哪國成績還是都不算？
          • 希臘歌手艾勒尼·弗雷拉的歌曲由希臘唱片公司發行，但本作代表賽普勒斯參戰歐洲歌唱大賽，又在西班牙打單，這成績要算誰身上？ --窝法乙烷 儿法梦碎 2022年8月14日 (日) 08:21 (UTC)
            • 雖然執行上有困難，但我猜你應該能理解我的「原產地優先」的原意。我不認為要簡單的案例遷就複雜的案例，建議指引寫得寬鬆一點。另外，個人認為複數國作品建議都算。－hiJK910 ^{走先喇 係咁先喇 下次再玩吖} 2022年8月14日 (日) 08:39 (UTC)

(？)疑問：

• 如模板或歌曲模板中已提及榜單排名，則不用在表格中重復記錄?如模板:Oricon單曲週榜冠軍 (2021年)、模板:Billboard JAPAN Hot 100 週榜冠軍 (2021年)；
• 韓國音源使用範例中的年榜建議可供編輯者自由選擇記錄或不記錄；如記錄建議使用{{TBA}}，因為韓國打榜期一般為兩週至一個月，謝謝。--Abcet10（留言） 2022年8月16日 (二) 15:41 (UTC)

@Abcet10：除非是打算創立條目沒打算擴充，否則我不建議僅收錄模板。尤其是Billboard沒條目也沒來源，很難查證成績。模板:Gaon專輯週榜冠軍 (2021年)是還好，剛好2021年Gaon專輯冠軍作品列表有附來源。至於韓國音源年榜，除非你家藝人音源成績真的差到上不了榜，不然一定要寫（可以每小時追蹤成績但不能一年看一次成績這也太不合理了吧）。　--窝法乙烷 儿法梦碎 2022年8月17日 (三) 06:43 (UTC)

@Milkypine針對韓國音源年榜，閣下意思是上榜一定要寫，沒上榜可以不寫?另外有關Bugs沒有音源年榜，相關的年榜應查找哪個?--Abcet10（留言） 2022年8月18日 (四) 15:29 (UTC)

我把Bugs砍了，這麼多年沒人動到年榜真的沒注意ˊ_>ˋ。 --窝法乙烷 儿法梦碎 2022年8月18日 (四) 16:07 (UTC)

將埋在字海的指引草稿撈出來：Wikipedia:格式手冊/音樂排行榜。－hiJK910 ^{走先喇 係咁先喇 下次再玩吖} 2022年8月14日 (日) 08:41 (UTC)

• 稍微吐槽一下，看不太懂提案標題，是要將該格式手冊升格為指引？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年8月14日 (日) 11:14 (UTC)
  • 忘了加設... --窝法乙烷 儿法梦碎 2022年8月14日 (日) 11:19 (UTC)

• 我有四个问题：1. 像流行音樂全金榜这种多国及地区的榜单怎么办？2. 参考来源的蓝链，我之前一般是标在峰值那一栏的数字后面，是不是也可以？3. 有时候好几个榜单的参考来源是同一个，在表格外面的文字里说明一下，或者在峰值那一栏后面增加一个备注项，合并备注几个榜单，是不是也可以？4. QQ音乐的APP里点开一首歌曲的音乐卡片，可以看到这首歌曲的上榜情况汇总，但是网页版似乎没有这个功能，我不知道怎么设置APP里歌曲的蓝链到维基，有没有什么好的方法处理这种情况？多谢！生米一粒（留言） 2022年8月14日 (日) 13:02 (UTC)
  • @生米一粒：參照瑞士法語區，流行音樂全金榜可以寫成「全球華語區（流行音樂全金榜）」。從歷史脈絡上來看，来源蓝链位置是配合模板，雖然我很想說不行，但在沒為指引前這種自成一格的方式沒有不行（再次吐槽在表格中加入作品欄位的行為，單一歌曲的我在这 挺好的成績難道會出現在卡布叻船长嗎？）。來源是可以重複引用的，備註比較適合展示成績異常（例如買榜等情況），用它展示來源有幾個榜那前面也不用把榜列出來了。跟QQ音乐不熟，但我想應該可以分享產出音乐卡片的連結吧？如果不能...那就土法煉鋼展示巔峰榜、地區榜和特色榜吧。 --窝法乙烷 儿法梦碎 2022年8月15日 (一) 15:00 (UTC)

• 我觉得所谓原产地没那么复杂，我基本认同Hijk910君的观点，即理论上应以“原产地”为先。但问题在于技术上判断“原产地”其实存在困难，毕竟这个东西是主观判断，虽然一般情况可以依照唱片公司、语言、宣发地、打榜地等一系列依据推出最适合的所谓原产地，但无疑缺乏硬性指标和标准。当然要是放宽标准其实也不难，但作为指引这部分我觉得比较难起草。不过以在下拙见“发行地”是个不错的参考依据。假如不存在发行地这一说（比如前面提到的宇多田光那张），就以主要宣传的地点（我不知道，但推测是日本，毕竟电台都是日本的吧）为准。至于假如出现没有任何宣发和不明发行地的情况则以该歌手主要活动的区域为准。

PS：其实没必要抠那么细啦......绝大多数人都不会在意什么榜打头的吧 囧rz…… --🌒-🌖 2022年8月15日 (一) 02:33 (UTC)

• 扣除判定問題，我想請問這麼做的用意何在？如果要展示原产地，導言會寫、發行章節也會寫。如果是本地保護主義，放眼過往的中維條目也早就特化出專屬章節（如IT'z Different、殘響散歌/晨曦將至、5 (B1A4專輯)）。當然不是沒這樣做過，但我上次看到還是2018年左右的韓團條目（WJ Please?），畢竟現在一堆都馬複製貼上英維，幹嘛還需要自己寫表格。 --窝法乙烷 儿法梦碎 2022年8月15日 (一) 10:34 (UTC)
  • 一、在你的草稿中，讀者看一首韓文歌的排行時，會先看到澳洲。我認為是違反常識，不分輕重。不必煞有介事地弄個「本地保護主義」之類的新詞，用常識判斷即可。二、將指引寫得寬鬆一點並不難，加一些例外，如「可以將少數主要發行地、主要宣傳地等放在表格首項，或獨立成章」，將判斷權交給編者，又不失規範。－hiJK910 ^{走先喇 係咁先喇 下次再玩吖} 2022年8月15日 (一) 13:13 (UTC)
    • 如果是飯圈女孩，她們絕對會很開心自家哥哥海外出名（一方面也是大家只關注音源不怎麼在乎GAON）。而非飯圈人士對此有意見也尚未可知（我是想用獲獎與提名列表當反例，但這類條目本來按時間排列，應該是沒人靠北寄生上流獲獎與提名列表怎麼不先放韓國獎項）。指引寫得寬鬆不難，但你好歹有個範例吧（香港沒寫是因為除了羅列走勢外，剩下基本都和其他國家的榜單放在一起），其他都有就他沒有你４８４歧視它。
    • 按照維基歷史和樓上現成的例子電視劇演員與角色排序，將判斷權交給編者，不失規範，但會造成論戰。台北101的舉世盛名、日本首發的真性情和Gangnam Style爆紅後的多國活動是否屬於主要宣傳地？有祖宗１８代派台清單的義大利是否屬於主要發行地？我是覺得你寫如此寬鬆還不如不寫，畢竟編輯沒有過往條目可以參考、指引也沒有相關範例，那麼到頭來很可能就是複製貼上英維內容完事，並在評選時被人抱怨怎麼沒有按照原产地排序（這情節感覺跟導言來源有87%像）。 --窝法乙烷 儿法梦碎 2022年8月15日 (一) 14:31 (UTC)
      • 「寫如此寬鬆還不如不寫」？滑坡推論是一種非形式謬誤喔。我一般參與討論時，只關心我的守備範圍。這次給你優惠，把我的底牌掀給你看——我的目標是「J-POP條目中可以將日本排行榜優先排列，或獨立成章」，不能達成這個目標就一律反對，原因已在上面說明。－hiJK910 ^{走先喇 係咁先喇 下次再玩吖} 2022年8月16日 (二) 16:01 (UTC)
        • @Hijk910：像独特自我或向夜晚奔去這類可以簡單分類當然沒有問題，但國際社會下的音樂作品往往不是這麼簡單，先不論何謂少數主要發行地、主要宣傳地？交由各編輯決定只會變成我倆互相爭執然後瘋狂編輯戰。獨立成章可行（我都把香港、韓國寫出來了有啥不可以），但章節內容如何描寫閣下可以想想。 --窝法乙烷 儿法梦碎 2022年8月17日 (三) 07:03 (UTC)
          • 我很忙，只會反對不恰當的東西。－hiJK910 ^{走先喇 係咁先喇 下次再玩吖} 2022年8月18日 (四) 15:34 (UTC)
• 是否可以把成绩最好的榜单放在最前面，如果一首歌在原产地成绩一般但是在另外的地方成绩更好，那就把另外那个地方写在前面，也算是有道理的吧。例如《不见就散》这首歌按产地应该是香港，但是在大陆成绩更好。《泡沫 (鄧紫棋歌曲)》是在大陆爆红后再扩散到全球华语区的。--生米一粒（留言） 2022年8月15日 (一) 20:36 (UTC)

  我認為可以跟據成績來排名，即成績最好的地方放最前。另外也可以將該名歌手的活躍地的成績排最前喔。如果跟據原產地來排名的話是很難排的，因為很難去確定一首歌的原產地，特別是現在很多歌曲都在網上發行。Akai 博士【天主保佑！】（意見收集箱） 2022年8月16日 (二) 11:17 (UTC)

  兩位是指像下面這樣嗎？這會不會太支離破碎 --窝法乙烷 儿法梦碎 2022年8月17日 (三) 07:06 (UTC)

  • 是的，就是成绩好的榜单放前面，然后按照成绩依次往后排列。这样一眼就可以看到拿了几个榜单的冠军或亚军。--生米一粒（留言） 2022年8月17日 (三) 20:33 (UTC)

  其實表格按一下就能根據成績高低分類。 --窝法乙烷 儿法梦碎 2022年8月18日 (四) 03:01 (UTC)

  • 确实。但是国家地区那一栏也可以自动排序的。所以我的建议是就不要加以规定了，由编者自己决定哪个放前面哪个放后面吧。--生米一粒（留言） 2022年8月18日 (四) 06:19 (UTC)

香港（903專業推介）	1
比利时佛兰德（Ultratop五十強單曲榜）	2
香港（勁歌金榜）	3
比利時瓦隆（Ultratop五十強單曲榜）	4

• 关于日榜，有些榜单只有日榜，例如飙升榜，这是新歌发布之后第一个可能上榜的榜单，因此对这个榜单的关注还挺多的。我觉得是日榜是可以放进来的，只要写清楚榜单类型是日榜就可以了吧。另外，音乐条目的收录标准里面，两个国家或地区榜单前十，这个是包括日榜的。--生米一粒（留言） 2022年8月18日 (四) 06:23 (UTC)
  • 排序我改成根據編輯需求，至於日榜，音乐条目的收录标准里面並沒有包括日榜。 --窝法乙烷 儿法梦碎 2022年8月18日 (四) 07:34 (UTC)

    • 哇，刚去看了一眼，确实音乐条目的收录标准上个星期改了，现在不需要两个国家或地区的榜单了，只要一个月榜以上，或两个不同的周榜前十就可以了。多谢提醒！关于日榜，我又看了一下，写的是“不建议”，不过也没禁止，就还是看编辑的想法吧。--生米一粒（留言） 2022年8月18日 (四) 14:41 (UTC)

(？)疑問：該指引應該是不會禁止，也不會規範表格以外的對排行榜的描述的吧？像是紅蓮華這款的。－hiJK910 ^{走先喇 係咁先喇 下次再玩吖} 2022年8月18日 (四) 15:44 (UTC)

紅蓮華描述榜單的地方有很多，但基本上這裡只管編輯寫表格時可以怎麼寫而已。 --窝法乙烷 儿法梦碎 2022年8月18日 (四) 16:07 (UTC)

認為草稿中「榜單應該整合在一份表格中」會讓人有這個誤解，建議修改。－hiJK910 ^{走先喇 係咁先喇 下次再玩吖} 2022年8月18日 (四) 16:43 (UTC)

指引都寫了表格，如果這樣還會造成誤解那我也不曉得用甚麼方式描述。你覺得如何描述可以避免？infobox除外？ --窝法乙烷 儿法梦碎 2022年8月19日 (五) 06:50 (UTC)

「榜單可以整合在一份表格中，並須按照可靠來源列出正確名稱。」你覺得如何？－hiJK910 ^{走先喇 係咁先喇 下次再玩吖} 2022年8月19日 (五) 16:34 (UTC)

謝謝，已修改。 --窝法乙烷 儿法梦碎 2022年8月20日 (六) 04:14 (UTC)

認同「榜單成績必須附上參考文獻」這點，但是有一個問題是銷售成績（如RIAJ）屬於此指引草稿的範疇嗎？此外，像是RIAJ無法「直接」取得參考文獻的網頁，是要直接附上查詢網頁，還是有其他方式取代呢？空氣小貓（留言） 2022年8月20日 (六) 00:45 (UTC)

「導向排名成績的連結」按照古法，這類來源可以透過|quote=展示，當然也可以利用網頁存檔存取（Webpage archive效果較好，但僅能儲存當前頁面，過往內容要看有緣人）。 --窝法乙烷 儿法梦碎 2022年8月20日 (六) 04:14 (UTC)

無法理解NT:SCHOOL為何對公立與私立高中區別對待

在閱讀過建立相關關注度時的討論後也找不到相關說明。唯一一個看起來相關的發言是有位編者提出在編寫雲南專題相關條目時，「以前的編寫經驗是一個縣搭配一所公立高中，小學初中和私立高中不寫條目」，但並未說明為什麼作出這樣的區分。無法理解。

經網上搜尋，貌似公立高中比較受重視的可能原因之一為中國大陸的公立高中教學質素一般比民辦為高，但a.)此對比只適用於中國大陸，而不一定適用於世界各地的公立高中、b.)本人認為「教學質素」不應成為決定學校是否符合關注度的條件之一。

因此，本人建議刪除NT:SCHOOL中「公立高中」的「公立」二字。

現行條文 公立高中假定具备关注度，应予以收录。

提議條文 高中假定具备关注度，应予以收录。

--——C933103(留言) 今天, 02:42 pm (UTC+8)

留言格式问题已修正。--YFdyh000（留言） 2022年8月15日 (一) 07:04 (UTC)

对于条文仅限“公立”，个人认为合理。公立机构的设立一般经政府相关机构、机制的审慎评估，并具有长期影响，而私人或商业机构未必经过足够级别的评估，不宜假定具有关注度，可能是假文凭、假学校。如有足够资料，可以为特定地区的民办教学机构设定标准，但更建议用来源证明已具关注度。--YFdyh000（留言） 2022年8月15日 (一) 07:10 (UTC)

条文已纳入“公办民营”。如果进一步放宽，是否意味着未经教育界批准的私立民办“高中”机构，亦具备关注度？仅是名字和机制上类似高中，但教材、文凭等与所在国家认可的高中没有关系，可能只办一两年、招生人数不定。--YFdyh000（留言） 2022年8月15日 (一) 07:19 (UTC)

那只需要寫上，「營辦當地政府批准課程的高中或已獲認可的國際學校」就可以解決這問題了吧，為什麼要限定公立？在日本和美國等等地方，公立高中比私立的也說不上有什麼優勢--——C933103(留言) 2022年8月15日 (一) 08:46 (UTC)

我对各地“批准课程或认可”的执行标准及判断方法不了解，暂存疑虑。相关学校是否可能只开几年，或者只招收少量学生、没有公开信息披露等。如果相关学校有满足通用关注度的来源，完全可以忽略该关注度指引，而如果没有，它可能只是一个一般民办机构（公司）。--YFdyh000（留言） 2022年8月15日 (一) 09:52 (UTC)

例如日本東京都政府有這樣的認可私立學校列表：https://www.seikatubunka.metro.tokyo.lg.jp/shigaku/ninka/0000000140.html，美國加州的認可私立學校列表：https://www.cde.ca.gov/ds/si/ps/index.asp，台灣：中華民國普通型高級中等學校列表等等。對於「相關學校是否可能只開幾年，或者只招收少量學生、沒有公開資訊披露等。」這些關注我並不認為具備普適性。

至於你說「如果相關學校有滿足通用關注度的來源，完全可以忽略該關注度指引，而如果沒有，它可能只是一個一般民辦機構」，那為什麼公立高中可以豁免？--——C933103(留言) 2022年8月15日 (一) 10:30 (UTC)

“公立高中”的豁免我理解为，假定其通常可找到关注度来源（如媒体报道、地方志等），少数特例经讨论“有机会不会收纳”。“私立学校”的排除，历史讨论中挺多、也有争议，可能讨论中没有得出共识，所以最终未列入，适用通用关注度。--YFdyh000（留言） 2022年8月15日 (一) 12:14 (UTC)

有什麼原因導致公立高中比私立的被認為更有可能於報體報導或地方志等找到來源？--——C933103(留言) 2022年8月16日 (二) 04:34 (UTC)

像我最近在看到臺北市立螢橋國民中學條目裡面被人更換校長的時候，想要去確認一下這是破壞還是真的，就從台北市政府教育局找到一個臺北市111學年度市立國民中學校長遴選委員會發布的公告—臺北市111學年度市立國民中學校長遴選第二階段第二次轉任審議結果及校長出缺學校名單當成來源貼進去當參考，雖然因為校長列表落落長，被跟著一起被砍掉就是了。但凡教育局或類似機構有做事，公立學校的一些重大事務都會有相應的公告吧。--Anghualee（留言） 2022年8月17日 (三) 08:11 (UTC)

這個很視乎具體國家的情況不同吧，而且公立民營也適用相同標準嗎？--——C933103(留言) 2022年8月17日 (三) 22:38 (UTC)

應該要先從整個條文去看，從整個高等到初階的收錄標準是越變越嚴的。光看高中前後就有差異了，大學全部假定有關注度，初中則要有多名校友有關注度，才會收錄。所以你覺得用公立一刀切的標準不好，那需要討論的是怎樣的標準去切分，才能讓值得被收錄的高中條目透過這個關注度標準被保留，而不是直接刪除收緊的標準（好比說公立）導致直接比照大學全部假定有關注度。--Anghualee（留言） 2022年8月17日 (三) 08:01 (UTC)

或者比照初等中學的標準也可以呀？--——C933103(留言) 2022年8月17日 (三) 22:36 (UTC)

根据Wikipedia_talk:关注度_(组织)/存檔一改成这样或许比较合适。

現行條文 公立高中假定具备关注度，应予以收录。 初級中學若有多名校友被中文維基百科收錄傳記條目，即可收錄。

提議條文 公立高中假定具备关注度，应予以收录。（此条不修改） 其他类别的中學阶段学校若有多名校友被中文維基百科收錄傳記條目，即可收錄。

--GZWDer（留言） 2022年8月17日 (三) 16:22 (UTC)

不反对。--YFdyh000（留言） 2022年8月17日 (三) 17:07 (UTC)

关注度指引多了之后，会不会造成有些人建立条目时怠于添加参考文献，并以指引为由反对删除？是否需要强调一下 “如果没有可靠、第三方的来源，维基百科有机会不会收纳这些条目”？ “应予以收录” 和 “即可收录”，是否要统一？--Kethyga（留言） 2022年8月18日 (四) 03:41 (UTC)

个人理解，关注度子指引的假定具有关注度，本来就是给不加关注度来源/可靠来源/任何来源开口子。而“有机会不会收纳”，我的理解是得到存废讨论等共识，决定相应条目无需收录/删除。这种开口子，可能是避免已创建条目的来源不满足可靠性&关注度，但已知主体满足关注度、很可能有关注度来源、信息无明显错误。某些批量创建的条目，所用来源就是不合格，但用关注度或无来源提删对条目内容来说可能是损失，所以开这种口子。--YFdyh000（留言） 2022年8月18日 (四) 07:09 (UTC)

理論上那些校友就是可靠的、第三方的來源，前提是那些校友的條目中關於學歷的部分都有好好的被把關...--Anghualee（留言） 2022年8月18日 (四) 07:20 (UTC)

問題是維基百科有傳記條目的人，有多少是在中學階段對學校構成知名度的？--——C933103(留言) 2022年8月19日 (五) 11:05 (UTC)

指引并未要求在学校阶段对学校构成知名度吧？如果“对学校构成知名度”，那不就满足通用关注度了？个人理解，指引中说多名（至少两名）校友条目存在可靠来源说曾在某学校就读，既先行假定认为该学校有一定的作用和历史价值、有可能存在文献。--YFdyh000（留言） 2022年8月19日 (五) 13:48 (UTC)

感覺索性所有中等教育機關都像小學那樣用通用關注度就好了。校友如果是在政商界有成就的話還能算可能和中學有關，但如果有校友是因為成為殺人犯和軍隊將軍而獲得關注度的話，對於他們所曾就讀的中學的維基百科條目而言有多少意義存疑。--——C933103(留言) 2022年8月20日 (六) 09:39 (UTC)

註釋

強烈建議制訂或修訂關於國家/地區體育代表隊的命名規則

諸位好。本人現強烈建議制訂或修訂關於國家/地區體育代表隊的命名規則，將單講男子代表隊的「某某國家隊/某某代表隊」更名為「某某國家男子隊/某某男子代表隊」，以跟上性別平等的時代潮流。

以上。祝編安。📕📙📒📗📘📚📖^{強烈抗議維基基金會無理封禁中維管理員} 2022年8月18日 (四) 05:08 (UTC)

• ( π )题外话 性别平等是对的，但只修正特定领域的命名方式，这个理由是否不太够、会不会显得“不平等”。如中国共产党第二十次全国代表大会代表名单等名单中，女性人物会单独标注“女”，而男性不会标、默认男性，是否算不平等，难道也标上“男”，但会显得太乱、与原件不统一，仅为此改为表格又不值得。只标注少数民族（非汉族），又是否民族不平等，或者有注明乃至无注明则可接受。
• 除非证据表明已普遍改用“男子代表队”，不然依此原创写法规范可能不是时候。不过，从我搜到的来源来看，中国国家足球队改为中国国家男子足球队似乎合理，后者新闻似乎更多，且官网目前这样写。--YFdyh000（留言） 2022年8月18日 (四) 07:28 (UTC)

  感觉可以移动，毕竟男队和女队都有，且女队也获得了足够地关注和报道。Googel搜索“中国国家足球队”，似乎大多数会强队男足还是女足。另外，如果移动，条目内的历史部分可以得重新遣词造句。国家级或者国际间，男队和女队都有且同时参加比赛的情况可以考虑。其他联赛级别的似乎女队的关注度比较低，比如英超、欧冠。--Kethyga（留言） 2022年8月18日 (四) 07:48 (UTC)

  仅赞成这一例移动，其他条目的统一化欠研究，提案陈述的理由不足。--YFdyh000（留言） 2022年8月18日 (四) 08:39 (UTC)

  • 1. 本人本提案只討論國家/地區體育代表隊，不擴展到職業聯賽或其他範疇。
  • 2. 以下幾個國家/地區的足協都已經不再用「國足」默認指代男足：
    • 德國：「Männer-Nationalmannschaft / Frauen-Nationalmannschaft」
    • 加拿大：「Men's National Team / Women's National Team」（法語：「Équipe nationale masculine / Équipe nationale féminine」）
    • 蘇格蘭：「Scotland Men's A / SWNT」
    • 英格蘭：「Men's Senior / Women's Senior」
    • 葡萄牙：「Seleções → Futebol Masculino / Futebol Femenino」
    • 澳洲（不過用的是暱稱）：「Socceroos / Matildas」
    • 米國：「USMNT / USWNT」
  • 以上。📕📙📒📗📘📚📖^{強烈抗議維基基金會無理封禁中維管理員} 2022年8月18日 (四) 13:46 (UTC)

感覺像是WP:OFFICIALNOT的觀點。個人覺得你要不要考慮去弄個性別平等重導向的分類去專門搞這個。--Anghualee（留言） 2022年8月18日 (四) 07:32 (UTC)

目前的趋势是各大媒体都是称呼男子/女子XX队，个人建议制定一个命名规则，避免每个条目命名不一致给人造成困惑。----脳補｡◕‿◕｡讨论 2022年8月19日 (五) 13:45 (UTC)

个人建议名从主人、基于来源，必要时避免误解，但不要为平等或统一命名法而原创命名。有些国家代表队的官方名称不带性别，en:Category:National_sports_teams可作参考。新西兰国家板球队（另有女子队），Google有三千多条结果，而"新西兰国家男子板球队"是5条结果，极不常用。en:Singapore national cricket team等英维/官方命名同上。以及"肯尼亚田径队"（en）3000条、"肯尼亚国家田径队"30条、"肯尼亚国家男子田径队"6条（有多个新闻来源），但重点是似乎并无女子田径队、女子选手似乎被计入该队。所以全面统一命名个人感觉稍欠火候，但这不妨碍有官方来源支持的情况下选用清楚的“男子队”。--YFdyh000（留言） 2022年8月19日 (五) 14:15 (UTC)

條文

綜合以上諸位的意見，以下是本人提出的條文：

現行條文 （無）

提議條文 條目名稱: 符合以下三項條件的男子代表隊，不應命名為「某某國家/地區體育（代表）隊」，而應命名為「某某國家/某某地區男子體育（代表）隊」： 管轄此男子隊的政治實體有對應的女子隊。 官方網站或新聞公告等不使用體育名稱默認指代此男子隊，而使用「男子（代表）隊」。 此男子隊不接收女子運動員，而女子運動員的成績也不算入此男子隊。（某些體育的國家/地區代表隊已經向所有性別開放。例如：加拿大國家腦癱足球隊從去年開始允許女子球員參加選拔。） 若官方使用體育名稱默認指代男子隊，但中文媒體大量使用「男子隊」的話，也可以使用「某某國家/某某地區男子體育（代表）隊」，或提出改名。 不符合以上條件，則暫時不移動相關條目。 不建議將「某某國家/某某地區男子體育（代表）隊」移動到「某某國家/某某地區體育（代表）隊」，除非此代表隊已經對非男子運動員開放。 條目分類: [[分類:某某國家/地區體育（代表）隊]]應作為母分類，包含[[分類:某某國家/地區男子體育（代表）隊]]和[[分類:某某國家/地區女子體育（代表）隊]]等子分類。

歡迎拍磚。《條目名稱》和《條目分類》兩部份分別投票，不作捆綁。📕📙📒📗📘📚📖^{強烈抗議維基基金會無理封禁中維管理員} 2022年8月21日 (日) 02:42 (UTC)

还行。但应明确“此代表队不接收女子运动员，而女子运动员的成绩也不算入此代表队”条件的前提是存在“女子队”。对于代表队仅有男性成员，但官方未明文限制或者不称“男子队”的情况，我仍有顾虑。--YFdyh000（留言） 2022年8月21日 (日) 08:56 (UTC)

@YFdyh000：已增加。📕📙📒📗📘📚📖^{強烈抗議維基基金會無理封禁中維管理員} 2022年8月21日 (日) 17:07 (UTC)

我怎麼覺得這個條文更偏重於用因政治或宣傳等因素製造的第三方宣傳來替代掉官方名稱呢？比如說奧會官方認定的代表隊名稱是中華台北，如果中文媒體大量使用奧運台灣男子代表隊的話，條目就可以申請改名移動去奧運台灣男子代表隊了？感覺這規則有炎上的潛質呢（點訂閱）--Anghualee（留言） 2022年8月21日 (日) 15:53 (UTC)

@Anghualee：此項提議只涉及是否在條目名稱中使用「男子」字眼，不涉及政治實體名稱。📕📙📒📗📘📚📖^{強烈抗議維基基金會無理封禁中維管理員} 2022年8月21日 (日) 17:02 (UTC)

即便媒体大量使用台湾指称中华台北（这种情况在去年的东京奥运开始明显频繁起来），依然可以根据国际体育组织的称呼，及Wikipedia:格式手册/两岸四地用语#非官方機構及國際活動之规定维持使用中华台北。--🔨（留言） 2022年8月21日 (日) 23:56 (UTC)

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

参见先前讨论，我简单翻译了一下en:WP:DRAFTIFY，并做出了一些调整，请社群判断是否合理。

在新页面巡查的过程中，如一个未被巡查的页面满足以下所条件，巡查员可将其移动至草稿命名空间。

1. 该页面具有发展成完整条目的潜力
2. 该条目的质量明显不符合标准
3. 没有证据证明编者正在改善此条目，且
4. 该条目没有侵犯著作权的内容，或
5. 该条目的作者清楚地表明了其有利益冲突。

--QiuLiming1（留言） 2022年8月21日 (日) 21:20 (UTC)

建議在這邊寫明排除符合快速刪除標準的頁面，雖然巡查員理應知道這點，不過還是寫進去會更清楚一點。--冥王歐西里斯（留言） 2022年8月22日 (一) 02:58 (UTC)

若按英維原意，並非全部符合速刪的頁面都要排除，例如衹有{{infobox}}的條目，可以WP:A2速刪，但假如主題「具有发展成完整条目的潜力（條件1）」，且符合其他條件，則可以移至草稿，WP:A2是其「质量明显不符合标准（條件2）」的理由。相反，WP:G3惡作劇頁面不具有发展成完整条目的潜力（不滿足條件1），因此不應移至草稿。——$\definecolor {my}{rgb}{0.04,0,0.5}\color {my}{\mathsf {htc_{23}}}$（留言） 2022年8月22日 (一) 03:08 (UTC)