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

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

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

公告欄

• [離任] Kuon.Haku已離任管理員，感謝其任內貢獻。
• [通知] 深色模式現已供所有行動版及桌面版網站（Vector 2022和Minerva皮膚）的用戶使用。如有任何問題，歡迎在討論頁或透過頁面右側的回報功能提出。
• [人事] Mys 721tx的管理員解任投票正在进行，参见投票頁面，歡迎踴躍參與。
• [公告] 討論頁話題索引現正重投測試。如有意見、建議或報錯，請至互助客棧的討論串提出。
• [公告] 討論遞進機制正在試行中。如對實行過程及相關規範有疑問，可在討論頁提問。
• [公告] 修訂本地更改用戶名方針敘述及修订条目内嵌入人物列表的收录标准已經通過。
• [公告] 設立教育佈告板、快速刪除方針G18款的調整、增加快速刪除因關注度問題被刪除而又被重建的條目的規定、調整放置原文重新導向的來源的規定、將通用評級指引併入頁面評級的提議及修订著作权验证模板与提报侵权流程正在公示，如有意見請儘快提出。
• [討論] Unblock-zh.org正在试运行。同时互助客栈继续对于其各项细节征求意见。
• [討論] 快速删除方针討論頁正在討論R7款的調整及O4款的調整，請踴躍參與討論。
• [協作] 第二十二次動員令於7月6日至9月8日間舉行，歡迎踴躍參與！

• [協作] 现有129个页面需维基化，323个条目需清理，35个移动请求正在讨论。

#	💭 話題	💬	👥	🙋 最新發言	🕒 (UTC+8)
1	提議英維指引en: MOS:TVINTL經本地化後引入中維維基百科:格式手冊/電視	239	17	甜甜圈真好吃	2024-07-23 15:17
2	有關維基百科:高風險主題中回退限制的修訂意見	91	12	Wetrace	2024-07-18 19:21
3	電視劇演員名單序列	37	11	Sa Young Sun	2024-07-18 00:41
4	提议修订著作权验证模板与提报侵权流程	18	6	Sanmosa	2024-07-23 19:20
5	提議將通用評級指引併入頁面評級	11	6	Ericliu1912	2024-07-22 22:46
6	提議清楚定義何謂「正當合理的回應」	31	8	LuciferianThomas	2024-07-24 10:36
7	提案修正Wikipedia:用户名#更改用戶名	1	1	Jimmy-bot	2024-07-24 00:14
8	原文重定向的可靠来源	11	5	Sanmosa	2024-07-21 15:39
9	有關公布管理人員任免案投票人數等事	7	5	Sanmosa	2024-07-23 12:47
10	重提注音格式要求	16	10	Sanmosa	2024-07-17 22:16
11	Wikipedia:中立的观点#条目命名微调建议	19	8	Cwek	2024-07-23 13:37
12	关于Wikipedia:格式手冊/文字格式#颜色及内联图像的问题	21	7	Ericliu1912	2024-07-24 06:59
13	可否訂明繞過存廢討論，自行清空分類，屬於不當行為？	25	12	SunAfterRain	2024-07-22 00:15
14	提议修改维基百科:命名常规 (音乐)	47	11	Ericliu1912	2024-07-24 23:10
15	布告板更名	6	6	BigBullfrog	2024-07-24 20:08

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

正在廣泛徵求意見的議題

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

維基百科格式與命名

Wikipedia talk:格式手册/朝鲜半岛用语 § Module:CGroup/Korea

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

根据调查修改马来西亚和新加坡的朝鲜半岛用词。

• 南韩→韩国
• 北韩→朝鲜
• 南北韩→朝韩
• 韩语，暂时不变

--Kethyga（留言） 2024年6月24日 (一) 03:44 (UTC)

Talk:香港車輛號牌 § 香港車輛號牌使用07時日期格式違反MOS:DATE

使用魔術字自動更新資料月份是否合適？--路西法人 2024年6月26日 (三) 08:18 (UTC)

維基百科方針與指引

Wikipedia talk:格式手册/朝鲜半岛用语 § Module:CGroup/Korea

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

根据调查修改马来西亚和新加坡的朝鲜半岛用词。

• 南韩→韩国
• 北韩→朝鲜
• 南北韩→朝韩
• 韩语，暂时不变

--Kethyga（留言） 2024年6月24日 (一) 03:44 (UTC)

Wikipedia talk:共识/讨论页及共识方针试行案 § 試行案期中及期末報告呈現方式討論

本節討論共識試行方案的期中及期末報告如何實現及呈現指標。臺灣杉在此發言 (會客室) 2024年6月26日 (三) 04:02 (UTC)

Wikipedia talk:快速删除方针 § 調整快速刪除方針G18款的用詞，並擴大適用範圍

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

現提議調整快速刪除方針G18款的用詞，並擴大適用範圍至模板。Sanmosa _蚌埠 2024年7月10日 (三) 12:34 (UTC)

Wikipedia talk:快速删除方针 § 建議增加快速刪除因關注度問題被刪除而又被重建的條目的規定

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

此前社羣曾經討論過是否可以設置“關注度G5”的問題，我認為這點值得社羣重新認真探討，然而我經過思考後認為“關注度G5”（即快速刪除此前已因關注度而刪除的條目）的性質與一般的G5不同，因此我建議單開一個A項快速刪除條款。Sanmosa _蚌埠 2024年7月12日 (五) 16:23 (UTC)

Wikipedia talk:快速删除方针 § 規範化快速刪除方針O4款的規定

其實社羣此前已經多次討論過現行O4款的規定的合理性問題（過寬的比如兩年前的討論與上面的討論，過窄的比如三年前的討論），雖説我自己對於現時O4的規定沒太大的意見，但顯然地社羣的總體意見並非如此，因此我認為或許有必要規範化O4款的相關規定。Sanmosa _蚌埠 2024年7月14日 (日) 00:36 (UTC)

Wikipedia talk:快速删除方针 § 修訂G15以將不存在註冊使用者的使用者討論頁一併納入速刪範圍

Wikipedia:頁面存廢討論/記錄/2024/07/18#User_talk:User_talk:Cryberghost，這種頁面理論上其實可以直接速刪的（雖然其實原本不在速刪範圍卻被我提速刪然後還被刪掉就是了 囧rz……）。--SunAfterRain 2024年7月19日 (五) 15:22 (UTC)

Wikipedia talk:快速删除方针 § 調整快速刪除方針R7款的用詞

現提議調整快速刪除方針R7款的用詞。Sanmosa _蚌埠 2024年7月20日 (六) 00:51 (UTC)

維基百科提議

Wikipedia talk:共识/讨论页及共识方针试行案 § 試行案期中及期末報告呈現方式討論

本節討論共識試行方案的期中及期末報告如何實現及呈現指標。臺灣杉在此發言 (會客室) 2024年6月26日 (三) 04:02 (UTC)

巡豁条目复审机制

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

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

   @YFdyh000：建议另开一个话题，个人认为此举非常有必要。——范博_{邮局 · 探讨 · 留名} 2022年7月3日 (日) 07:12 (UTC)

   @范博2004：没什么响应，目前不想新开话题，或许很多人志不在此或有所顾忌。如需意见或协助可以ping我。--YFdyh000（留言） 2022年7月4日 (一) 12:27 (UTC)

(＋)支持：敝人認為此機制可結合並補充上方站友提出之修訂。--Kriz Ju（留言） 2022年7月12日 (二) 22:56 (UTC)

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

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

• 社群應該再把上面已經提及過且很明確在FL評選中發生的侵權問題重新檢視才是，這種討論估計也得花上不少時間。然而居然已經至少4天都沒有動靜了，表示社群對於侵犯著作權實在太過於鬆散而不想嚴格實施嘛。是否跟一開始就講過「該權限就是笑話」符合呢？--Z7504非常建議必要時多關注評選（留言） 2022年6月20日 (一) 11:37 (UTC)
• 老实说，定期复审什么的，从实际执行的角度上来说不太现实，肯定要有人愿意并且有能力长期维护并跟进才行……现在本站光是别的一些站务就已经出现了不少积压。--🔨（留言） 2022年7月4日 (一) 03:55 (UTC)

  頁面存廢討論就是一種典型的積壓例子，反正能拖延則拖延、擺爛就擺爛嘛，著作權問題都擺著了。--Z7504非常建議必要時多關注評選（留言） 2022年7月4日 (一) 13:32 (UTC)

• (！)意見：敝人綜觀諸位站友之討論，對於上述「豁免条目复审机制」，竊以為可於「維基百科:巡查豁免權」頁面的適當位置設置該專屬頁面連結，供熱心編者參閱或協助校閱改善，而巡查員亦可不時自行巡查。

承上，雖然此類編輯或巡查行動任何編者皆可執行，但經適當制度化之後，可獲社群共識和公信力，亦可反向補充上述豁免權限修訂之疑慮，並期許發揮「提醒擁有豁免權之用戶自持自重」、「維護豁免權之公信力和有效性」、「藉公開透明之資訊揭露減少濫用權限之情形」，進而「增進維護平台和社群聲譽」等效果。以上為個人意見，供參。--Kriz Ju（留言） 2022年7月12日 (二) 23:06 (UTC)

感谢支持，不过目前还比较初步，也无太多反响和活动，列入方针页面或许为时过早。有意者也可尝试自行生成和整理，无需拘泥于我创建的列表。--YFdyh000（留言） 2022年7月13日 (三) 00:51 (UTC)

不仅是autoreviewer，patroller也应列入。->>Vocal&Guitar->>_留言 2022年7月13日 (三) 00:34 (UTC)

是列入的，具有（使用到）巡查豁免的应该都有。不过目前脚本无法生成已超过30天的记录，以及移动到条目空间的条目。--YFdyh000（留言） 2022年7月13日 (三) 00:48 (UTC)

(＋)支持，提议在最近更改过滤器中加入由有特殊权限用户做出的编辑项、标签中加入巡查豁免标记---- ★WPTO★ 2022年7月21日 (四) 09:19 (UTC)

(＋)支持，需要有一个因豁免而未予巡查的页面，方便审核侵权。每个月自动生成这样就可以了。--脳補｡◕‿◕｡讨论 2022年7月21日 (四) 08:12 (UTC)

• 在社群里建一个工作小组，维基人自愿加入，专门干这个事如何？感觉只有组建一个有关于此的工作小组，并保持它的活跃，才能让这件事始终有人干，才能起到监督作用。（其实最好是开一个“巡查因巡查豁免而未巡查的巡查员”，但是感觉没啥必要）——范博_{邮局 · 探讨 · 留名} 2022年7月22日 (五) 02:54 (UTC)。

---

• 此事尚無眉目，故我將其分離出來供繼續討論。如我這樣做不符合規範，請將它刪除。謝謝！——范博_{邮局 · 探讨 · 留名} 2022年7月31日 (日) 11:42 (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這款巴士就有車輛保存。相同和統一的意思我覺得一樣，沒有強不強制的差別。還是維持反對定這種架構的想法。--u: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)

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

问题概述	目前，防滥用过滤器是反破坏的重要工具之一，隐藏过滤器日志和详情管理员和回退员都可见。
問題背景	此前曾出现过某些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)

關於接下來的管理員投票

應上一次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)

本討論章節會維持開放，暫時不按最後意見發表時間存檔，直至社群達成共識。欲讓機器人存檔，請移除本模板。留言請置於本模板上方。

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

已通過：

已完成公示，將依公示稿進行修訂。--Kriz Ju（留言） 2022年7月29日 (五) 19:19 (UTC)

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

---

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

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

覺得可以，不過「在建立頁面品質方面受信任的使用者」要如何認定？--冥王歐西里斯（留言） 2022年6月9日 (四) 03:56 (UTC)

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

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

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

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

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

如果不是以獲取權限為目的的刷條目的話其實沒什麼影響。--中文維基百科20021024（留言） 2022年6月9日 (四) 10:30 (UTC)

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

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

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

(？)疑問：維基百科的口语使用「毋須」而非「不須」真的妥當嗎？順便再說一個：現在的條目要再建一個新的真的很難，別再總是用「75個條目」作為刻板印象，但為了小作品和小小作品標準而有多起爭議，所以「75個條目」並非好建議。因為可以創長篇75個條目（如果創建條目能力很強的話），但也能刻意創75個小作品和小小作品的條目。--Z7504非常建議必要時多關注評選（留言） 2022年6月9日 (四) 10:11 (UTC)

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

個人認為，「而毋須接受侵權等多項檢查。」應該變成「而不須接受侵權等多項檢查。」。維基百科的口語至少也該有吧，每個人都知道「毋須」嗎？就好像「係指」（是指）那種用法，說實在很不恰當。最後要說的是，個人並不會考慮這個權限，這個權限不等於就是免死金牌、不因破壞而封鎖，所以就支持反對的部份不表態了。--Z7504非常建議必要時多關注評選（留言） 2022年6月9日 (四) 10:26 (UTC)

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

「無需」應該比「不需」好一些，可能就中文用法習慣上差異而已，就「無需」吧。--Z7504非常建議必要時多關注評選（留言） 2022年6月9日 (四) 10:31 (UTC)

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

「毋須」顯然並非高度艱澀之詞彙，未見更改之必要。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年6月10日 (五) 07:20 (UTC)

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

那順帶把巡查員也一道修訂？此外比巡查員更高的管理員也要類似的條件嗎？或者說因為管理員有過投票程序，所以這一點可以免？--中文維基百科20021024（留言） 2022年6月9日 (四) 10:28 (UTC)

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

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

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

巡查豁免 = 建立頁面都不被刪？還是 巡查豁免 = 建立頁面品質都優良？我以為社群普遍覺得是接近後者。--Xiplus#Talk 2022年6月9日 (四) 15:29 (UTC)

如果是「為減輕巡查員工作量」，那標準介於兩者中間，比如條目至少內文都要有來源；格式、標點符號都要對，Wikidata有沒有連上。就是讓巡查員看了不用掛板或手動改善的那種地步。--中文維基百科20021024（留言） 2022年6月9日 (四) 15:39 (UTC)

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

如果是朝著建立條目品質都優良的話那也沒必要搞巡查豁免了，因為一天下來都沒有幾篇條目能達到這個標準。--中文維基百科20021024（留言） 2022年6月9日 (四) 15:42 (UTC)

講難聽一點就是這種「豁免權」本來就是種笑話了。如果寫了一堆條目就能換來免死金牌、不因破壞而封鎖可能還有用吧，但就不是嘛，上面也說過了。所以維基人寫了一堆條目只是為了這種可能沒什麼實質意義的權利？還是說這種真的是這些寫了一堆條目的所謂成就感嗎？--Z7504非常建議必要時多關注評選（留言） 2022年6月9日 (四) 17:12 (UTC)

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

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

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

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

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

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

(？)疑問：什麼叫做「最近一年內沒有因條目質量問題受到封鎖」？封鎖不都是因為某些個人原因（如破壞、文明）才有可能的嗎？完完全全跟「要不要寫條目」無關啊。如果說一年內不寫任何條目就會被封鎖，那早晚都會被封的（生命早晚都會死的），為何不整個砍掉就好了呢？現在搞得好像怎麼改都不對。比如說「經常建立頁面且建立的頁面品質均良好」是誰來判斷？用何種理由判斷？至於「最近一年內沒有受到封鎖（不合理封鎖除外）」這句嘛，沒什麼大意見。只是還是那句，這種權利就是上面已經講過的「可能毫無實質意義的權利」、「並非免死金牌」。就像那75個條目，那種刻板印象的標準真的觀感很差。--Z7504非常建議必要時多關注評選（留言） 2022年6月10日 (五) 14:38 (UTC)

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

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

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

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

(＋)支持。桐生ここ★[讨论] 2022年7月5日 (二) 02:42 (UTC)

(＋)支持及(！)意見：敝人綜觀諸位站友之討論，對於相關提案同時希望可考慮結合下方站友第二案刪去「，而毋須接受侵權等多項檢查」，以及站友額外建議的「豁免條目覆審機制」，個人意見和理據如下：

1.「豁免權」不代表獲權用戶「自此得以拒絕或抵制接受巡查和檢查」，或是「可藉此『特權』甚而濫用權限不需注意基本原則」。在絕大多數情況下，每位一般用戶可對任何條目等頁面加以閱覽審視，包括對於任何其他用戶獲取之權限亦然。

2.承上，既為在撰寫、編輯或建立條目等頁面上身為「可信編輯」甚至獲取此「豁免權」，自不應建立大量侵權條目。個人認為在原本的行文表述中，只是為完整說明而如此行文，即便將該文句刪除，授權實務上仍將此條件納入考量。

3.承上，惟為明確提醒獲權者維持自省自覺，以及盡可能維護該資格或權限之公信力和有效性，仍應對此權限及獲權用戶賦予適當要求，此時自可回歸「維基百科:申請解除權限」機制加以審查甚而除權；因此竊以為目前運行之機制仍可對於獲此權限之用戶適當課責約束。

4.承上，此外，此案對豁免權限補充審核條件，除綜整社群規範和用戶活動之綜合性考量，對獲權用戶加強約束，加入此條件亦可使管理員和社群對獲權用戶更易於有效行權及審核考評。當然即便多了這條資格限制作為考評標準，不保證對於獲權用戶未來的行為就能「防患未然」，或是授權的管理人員以人格和信用對相關用戶「作保或背書」，敝人反倒認為獲權用戶自此或須自我惕勵、承擔更大責任或他人的不定時監督考評（笑）。

5.承上，因此若結合下方另一案，刪去「，而毋須接受侵權等多項檢查」一句，敝人認為不過是「回歸實際授權運作審核」、對應實務運作的字面修訂；換言之，不論這句話怎麼寫、或存或廢，獲權之編者都得接受綜合性考評，個人認為刪除反倒更為精簡。

6.此修訂或可緩解或改善長期以來社群對於平台相關規範和實務不時可能出現之疑義或矛盾，諸如：「巡查員本身自帶巡查豁免權，卻未必能夠大量編寫創建合規甚至優質條目？」；「大量創建編寫條目之編者，僅需以條目編寫為重，未必須考量或配合其他社群規範和平台精神？」；「巡查豁免者從此於條目或頁面之創建編輯彷彿獲得『免死金牌』、不容爭議？」；「巡查員獲權之資格及行權不時遭受質疑非議？」；「社群長期以來對於條目『編寫』和『維護』脣齒相依之辯證關係，不時以單向『二分法』切割劃分、互相拉踩、排擠傾軋之撕裂爭論」等爭議。

7.結合下方有站友提及之「豁免條目覆審機制」，可於「維基百科:巡查豁免權」頁面的適當位置設置該專屬頁面連結，供熱心編者參閱或協助校閱改善，而巡查員亦可不時自行巡查。

8.承上，雖然此類編輯或巡查行動任何編者皆可執行，但經適當制度化之後，可獲社群共識和公信力，亦可反向補充上述豁免權限修訂之疑慮，並期許發揮「提醒擁有豁免權之用戶自持自重」、「維護豁免權之公信力和有效性」、「藉公開透明之資訊揭露減少濫用權限之情形」，進而「增進維護平台和社群聲譽」等效果。

以上為個人意見，供參。--Kriz Ju（留言） 2022年7月12日 (二) 22:41 (UTC)

• 從最近的港鐵車站藝術品列表侵犯版權事件中，很明顯的可以得知「，而毋須接受侵權等多項檢查」應當砍掉。故應該修訂成：

現行條文 巡查豁免權 ... 為減輕巡查員工作量，可信用戶均可獲本权限。持權用戶所创建頁面會自動標示為「已巡查」，而毋須接受侵權等多項檢查。因此，授權者需肯定獲權者為可信用戶。本权限毋須由申請者本人提出申請。 ...

提議條文 巡查豁免權 ... 為減輕巡查員工作量，在创建页面品质方面受信任的用戶可獲本权限。持權用戶所创建頁面會自動標示為「已巡查」。因此，授權者需肯定獲權者為创建页面品质方面受信任的用戶。本权限无需由申請者本人提出申請。 ...

要不然就如同上面講過的根本是種笑話而已，看來這個侵權的FL已經又再次驗證了。--Z7504非常建議必要時多關注評選（留言） 2022年6月16日 (四) 06:31 (UTC)

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

所以打從一開始就說這種權限就跟笑話沒有兩樣嘛，這個獨裁社群真的應該重新檢視是否要較嚴格的審慎檢查版權之問題，並非所有編輯者都會在編輯時注意到是否有侵犯版權之問題。--Z7504非常建議必要時多關注評選（留言） 2022年6月18日 (六) 14:07 (UTC)

---

目前Antigng的提案似乎未見明顯反對，@Antigng：是否提請公示？Ericliu1912（留言） 2022年6月28日 (二) 06:12 (UTC)

Antigng應該把上面已經提出的事實做出回應才是，而並非一昧的公示卻繼續放任侵犯版權之問題。--Z7504非常建議必要時多關注評選（留言） 2022年6月28日 (二) 14:10 (UTC)

@Antigng君不知有何看法？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年7月12日 (二) 14:59 (UTC)

(！)意見：敝人已於上方提案區塊嘗試綜合表達相關意見，或可供站友參閱。--Kriz Ju（留言） 2022年7月12日 (二) 23:55 (UTC)

公示稿

最后一笔意见距今已满七日，现采纳上方部分用户的意见删去“无需侵权检查”这句本是描述“实务”却容易被误解为“权限”的描述。提出以下公示稿，公示七日：

現行條文 巡查豁免權 ... 為減輕巡查員工作量，可信用戶均可獲本权限。持權用戶所创建頁面會自動標示為「已巡查」，而毋須接受侵權等多項檢查。因此，授權者需肯定獲權者為可信用戶。本权限毋須由申請者本人提出申請。 ... 巡查豁免者：熟悉方針及指引且經常創建頁面者，授權者均可依其判斷予權。前句所述以生者傳記及關注度指引為首重。 ...

提議條文 巡查豁免權 ... 為減輕巡查員工作量，在创建页面品质方面受信任的用戶可獲本权限。持權用戶所创建頁面會自動標示為「已巡查」。因此，授權者需肯定獲權者為创建页面品质方面受信任的用戶。本权限无需由申請者本人提出申請。 ... 巡查豁免者：最近一年内没有受到封禁（不合理封禁除外），熟悉方針及指引，經常創建頁面且创建的页面品质均良好者，授權者可依其判斷予權。前句所述以生者傳記及關注度指引為首重。 ...

--Antigng（留言） 2022年7月19日 (二) 16:01 (UTC)

@Antigng：公示早已过七天。--🔨（留言） 2022年7月29日 (五) 01:43 (UTC)

两点愚见：

1. “为减轻巡查员工作量”要不要改成“为减轻巡查员的工作量”或“为减轻巡查工作量”（更为通顺一点）？

2. 何为“在创建页面品质方面受信任”？用户“佛祖西来”创建的大量小作品算不算？--QiuLiming1（留言） 2022年7月29日 (五) 02:35 (UTC)

不過都知道佛祖西來創建的條目都是什麼樣子，有必要再去巡查嗎？，他連維基五大支柱都沒有違反。而且他那個條目，除了掛Template:Expand或是miss infomation，其他也沒有什麼模板好掛了。--日期20220626（留言） 2022年7月29日 (五) 02:50 (UTC)

正如阁下所说，我认为“在创建页面品质方面受信任”比较模糊，佛祖西来创建的条目品质都不高。另外我建议可以挂小作品模板。--QiuLiming1（留言） 2022年7月29日 (五) 02:55 (UTC)

我記得小作品模板他自己也會掛，雖然是個人都知道這是小作品，掛不掛區別不大，--日期20220626（留言） 2022年7月29日 (五) 02:57 (UTC)

从没见过他自己挂小作品模板……有小作品模板也都是别人挂……--🔨（留言） 2022年7月29日 (五) 03:20 (UTC)

那說明他現在變懶了，我以前記得他掛的，好像是前2年的事情。--日期20220626（留言） 2022年7月29日 (五) 03:37 (UTC)

其实之前就有人质疑过受信任标准的模糊问题了，不过当时Antigng回应说“再细就没办法细化”……--🔨（留言） 2022年7月29日 (五) 03:28 (UTC)

模糊记得以前见过有人在佛祖创建的一篇条目挂onesource的……--🔨（留言） 2022年7月29日 (五) 03:28 (UTC)

我印象中大部分是有2-3條來源的。不過有幾次他的條目被人用A1提交速刪，還有一次被人提交到AFD，說是條目內容太短，不過內文已經超過50字了。--日期20220626（留言） 2022年7月29日 (五) 03:39 (UTC)

你这些印象大多都停留在三四年前，你应该再看看他最近创建的一些运动员条目。话说回来，其实我之前也提到过如果能够明确标准更好，不止佛祖，一部分拥有巡查豁免权的用户也是会短时间内大量创建小作品级别的条目，但至少会放infobox所以就算真的遭质疑了也没被除权，这点就好过现在的佛祖。--🔨（留言） 2022年7月29日 (五) 03:48 (UTC)

巡豁条目复审机制

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

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

   @YFdyh000：建议另开一个话题，个人认为此举非常有必要。——范博_{邮局 · 探讨 · 留名} 2022年7月3日 (日) 07:12 (UTC)

   @范博2004：没什么响应，目前不想新开话题，或许很多人志不在此或有所顾忌。如需意见或协助可以ping我。--YFdyh000（留言） 2022年7月4日 (一) 12:27 (UTC)

(＋)支持：敝人認為此機制可結合並補充上方站友提出之修訂。--Kriz Ju（留言） 2022年7月12日 (二) 22:56 (UTC)

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

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

• 社群應該再把上面已經提及過且很明確在FL評選中發生的侵權問題重新檢視才是，這種討論估計也得花上不少時間。然而居然已經至少4天都沒有動靜了，表示社群對於侵犯著作權實在太過於鬆散而不想嚴格實施嘛。是否跟一開始就講過「該權限就是笑話」符合呢？--Z7504非常建議必要時多關注評選（留言） 2022年6月20日 (一) 11:37 (UTC)
• 老实说，定期复审什么的，从实际执行的角度上来说不太现实，肯定要有人愿意并且有能力长期维护并跟进才行……现在本站光是别的一些站务就已经出现了不少积压。--🔨（留言） 2022年7月4日 (一) 03:55 (UTC)

  頁面存廢討論就是一種典型的積壓例子，反正能拖延則拖延、擺爛就擺爛嘛，著作權問題都擺著了。--Z7504非常建議必要時多關注評選（留言） 2022年7月4日 (一) 13:32 (UTC)

• (！)意見：敝人綜觀諸位站友之討論，對於上述「豁免条目复审机制」，竊以為可於「維基百科:巡查豁免權」頁面的適當位置設置該專屬頁面連結，供熱心編者參閱或協助校閱改善，而巡查員亦可不時自行巡查。

承上，雖然此類編輯或巡查行動任何編者皆可執行，但經適當制度化之後，可獲社群共識和公信力，亦可反向補充上述豁免權限修訂之疑慮，並期許發揮「提醒擁有豁免權之用戶自持自重」、「維護豁免權之公信力和有效性」、「藉公開透明之資訊揭露減少濫用權限之情形」，進而「增進維護平台和社群聲譽」等效果。以上為個人意見，供參。--Kriz Ju（留言） 2022年7月12日 (二) 23:06 (UTC)

感谢支持，不过目前还比较初步，也无太多反响和活动，列入方针页面或许为时过早。有意者也可尝试自行生成和整理，无需拘泥于我创建的列表。--YFdyh000（留言） 2022年7月13日 (三) 00:51 (UTC)

不仅是autoreviewer，patroller也应列入。->>Vocal&Guitar->>_留言 2022年7月13日 (三) 00:34 (UTC)

是列入的，具有（使用到）巡查豁免的应该都有。不过目前脚本无法生成已超过30天的记录，以及移动到条目空间的条目。--YFdyh000（留言） 2022年7月13日 (三) 00:48 (UTC)

(＋)支持，提议在最近更改过滤器中加入由有特殊权限用户做出的编辑项、标签中加入巡查豁免标记---- ★WPTO★ 2022年7月21日 (四) 09:19 (UTC)

(＋)支持，需要有一个因豁免而未予巡查的页面，方便审核侵权。每个月自动生成这样就可以了。--脳補｡◕‿◕｡讨论 2022年7月21日 (四) 08:12 (UTC)

• 在社群里建一个工作小组，维基人自愿加入，专门干这个事如何？感觉只有组建一个有关于此的工作小组，并保持它的活跃，才能让这件事始终有人干，才能起到监督作用。（其实最好是开一个“巡查因巡查豁免而未巡查的巡查员”，但是感觉没啥必要）——范博_{邮局 · 探讨 · 留名} 2022年7月22日 (五) 02:54 (UTC)。

---

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

建議修改音樂關注度規則

由於部份國家或地區歌曲／歌手大多只在當地的流行歌曲排行榜上榜，在現有Wikipedia:關注度 (音樂)的情況下大多不符合「作品至少登上兩個國家或地區的音樂榜單前十名內，但不適用於登上同一個榜單的不同類別與單一國家或地區內的多個榜單」的條件，因此建議作以下修訂：

現行條文 音樂家與音樂團體 維基百科中有許多樂團、歌手與其他音樂家、音樂團體的條目。 如果滿足以下條件其中之一，音樂家或音樂團體（包含樂團、歌手、饒舌歌手、樂隊、嘻哈樂團、DJ、音樂劇團等）被视为具有關注度： 他們曾經被多份獨立於該音樂家或團體以外的已出版可靠來源所提及。 作品至少登上兩個國家或地區的音樂榜單前十名內，但不適用於登上同一個榜單的不同類別與單一國家或地區內的多個榜單。 在至少一個國家或地區取得金唱片或更高級的唱片認證。 曾經獲得主要的音樂獎項，例如葛萊美獎、朱諾獎、水星音樂獎、金曲獎或选择音乐奖等。 另外，通常音樂團體成員的條目比較適合重定向到該擁有關注度的團體條目中，而非設置獨立的個人條目，除非他們有足夠個人關注度，比如擁有個人專輯等等。 作詞家與作曲家 對於作曲家、填詞家或編曲家，符合以下條件之一，具有關注度： 作品取得金唱片或更高級的唱片認證。 曾經獲得主要的音樂獎項，例如葛萊美獎、朱諾獎、水星音樂獎、金曲獎或选择音乐奖等 作品至少登上兩個國家或地區的音樂榜單前十名內，但不適用於登上同一個榜單的不同類別與單一國家或地區內的多個榜單。 音樂作品 音樂作品需要满足下列条件之一才符合关注度： 该作品在至少在一地取得金唱片或更高級的唱片認證 该作品赢得了具關注度的國際性奖项（如葛萊美獎、朱諾獎、水星音樂獎等）或該地區受廣泛認同的音樂獎項。 作品至少登上兩個國家或地區的音樂榜單前十名內，但不適用於登上同一個榜單的不同類別與單一國家或地區內的多個榜單。 不满足關注度标准的作品條目應該被合併到相关条目（如專輯、艺人、词曲创作人或制作人等等）條目中。 参考資料

提議條文 音樂家與音樂團體 維基百科中有許多樂團、歌手與其他音樂家、音樂團體的條目。 如果滿足以下條件其中之一，音樂家或音樂團體（包含樂團、歌手、饒舌歌手、樂隊、嘻哈樂團、DJ、音樂劇團等）被视为具有關注度： 他們曾經被多份獨立於該音樂家或團體以外的已出版可靠來源所提及。 作品至少登上两个具有一定规模且獲一個国家或地区认证或成立榜单的頭十名內，但登上同一个榜单的不同类别不在此列。 在至少一個國家或地區取得金唱片或更高級的唱片認證。 曾經獲得主要的音樂獎項，例如葛萊美獎、朱諾獎、水星音樂獎、金曲獎或选择音乐奖等。 另外，通常音樂團體成員的條目比較適合重定向到該擁有關注度的團體條目中，而非設置獨立的個人條目，除非他們有足夠個人關注度，比如擁有個人專輯等等。 作詞家與作曲家 對於作曲家、填詞家或編曲家，符合以下條件之一，具有關注度： 作品取得金唱片或更高級的唱片認證。 曾經獲得主要的音樂獎項，例如葛萊美獎、朱諾獎、水星音樂獎、金曲獎或选择音乐奖等 作品至少登上两个具有一定规模且獲一個国家或地区认证或成立榜单的頭十名內，但登上同一个榜单的不同类别不在此列。 音樂作品 音樂作品需要满足下列条件之一才符合关注度： 该作品在至少在一地取得金唱片或更高級的唱片認證 该作品赢得了具關注度的國際性奖项（如葛萊美獎、朱諾獎、水星音樂獎等）或該地區受廣泛認同的音樂獎項。 作品至少登上两个具有一定规模且獲一個国家或地区认证或成立榜单的頭十名內，但登上同一个榜单的不同类别不在此列。 不满足關注度标准的作品條目應該被合併到相关条目（如專輯、艺人、词曲创作人或制作人等等）條目中。 参考資料

歡迎討論。--Billytanghh 討論 歡迎參與亞洲月 2022年6月20日 (一) 12:59 (UTC)

(＋)支持，但一個關注點是哪些音樂榜單可被用作有效判斷關注度的標準？不怕被引用出任一不知名音樂榜單就當成滿足此項？--路西法人 2022年6月20日 (一) 16:21 (UTC)

其實原有備註會被保留。--Billytanghh 討論 歡迎參與亞洲月 2022年6月20日 (一) 16:47 (UTC)

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

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

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

已修改。--Billytanghh 討論 歡迎參與亞洲月 2022年6月21日 (二) 01:53 (UTC)

(＋)支持：建議「成立榜單」改為「成立週榜單」，至少以週為單位。是說我想提議一條「作品至少登上一個具有一定規模且國家或地區認證或成立週榜單前三名，名次限制隨著登榜時間增長而遞減。」 --Loving You Is A Losing Game 2022年6月21日 (二) 02:55 (UTC)

与其是写一定規模的榜單，為什麼不寫有關注度的榜單？這樣的話爭議相對少很多吧。--Ghren🐦🕛 2022年6月21日 (二) 04:25 (UTC)

這樣還要定義誰是符合關注度的榜單，很不方便。 --Loving You Is A Losing Game 2022年6月21日 (二) 06:03 (UTC)

我的關注點跟閑閑君一樣，何謂「一定規模」？--路西法人 2022年6月22日 (三) 01:06 (UTC)

個人認為一定規模是指具可與比肩官方的榜單。像國內方面有日本Oricon公信榜和俄羅斯Tophit，國際方面則有拉美監控、告示牌 (雜誌)具有高市占率，而某種程度上也擔任官方角色發布相關認證。當然這只是我認為，如果要歸納總結，大概會發展出誰是現任法國國王一樣長篇論戰。 --Loving You Is A Losing Game 2022年6月22日 (三) 05:05 (UTC)

是否直接定義符合通用關注度標準的榜單才能視作有效關注度條件？--路西法人 2022年6月22日 (三) 05:11 (UTC)

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

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

其實我的確認為需要頭十名內，已補回。--Billytanghh 討論 歡迎參與亞洲月 2022年6月23日 (四) 18:15 (UTC)

那這樣不是和你之前的提議原因抵觸了嗎？原話是「由於部份國家或地區歌曲／歌手大多只在當地的流行歌曲排行榜上榜」，如果加回前10名，不是和先前的版本沒實質上的區別？--中文維基百科20021024（留言） 2022年6月23日 (四) 18:19 (UTC)

可能具體語句需要再修修，目前的修訂版本乍一看依舊強調「前十名」。--中文維基百科20021024（留言） 2022年6月23日 (四) 18:21 (UTC)

先前版本要求兩個國家或地區，修訂版本只要求兩個具有一定规模且国家或地区认证或成立榜單便可，同一地區的兩張都可以。--Billytanghh 討論 歡迎參與亞洲月 2022年6月23日 (四) 18:52 (UTC)

你是指同一地區的「兩榜」都可以嗎？敝人反對，比利時還能解釋成地區（一個荷蘭一個法國），但日本韓國作品因為國內有兩榜算符合條件也太鬆散了，倒不如加上名次限制。 --Loving You Is A Losing Game 2022年6月24日 (五) 01:30 (UTC)

不鬆吧，至少一國之內有知名度了，應該夠了。--中文維基百科20021024（留言） 2022年6月24日 (五) 03:17 (UTC)

我是覺得這個條款太有益於小國了。小國隨便和鄰國加起來兩個榜就行，假如是中國的話，一首歌那怕是好幾個省都上榜了也不行，其實多少有些不公平。--Ghren🐦🕖 2022年6月24日 (五) 11:02 (UTC)

怎麼不鬆？以日本為例，除了比較具有標示性的Oricon、告示牌還有RecoChoku、Mora等其他榜單，這還沒包括根據不同格式產生的不同類型榜單們，日本金唱片認證好歹要你賣100,000張，靠這張你只要國內榜單夠多，賣個1千拿個100名符合關注真的很鬆。 --Loving You Is A Losing Game 2022年6月24日 (五) 13:53 (UTC)

那“同一個榜單”改成“同一個公司發佈的榜單”如何？這種情況下，以告示牌為例，Oricon、RecoChoku與Mora都當成一個榜單。Sanmosa _{Királyunk s a közhazát} 2022年6月25日 (六) 04:10 (UTC)

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

這樣改是比較嚴謹，但我反對降低標準，僅支持至少两个具有一定规模且国家或地区认证或成立榜单（關注度符合）。 --Loving You Is A Losing Game 2022年6月25日 (六) 05:04 (UTC)

我沒意見，我甚至覺得為求嚴謹，可以進一步改成“至少兩個具備關注度、具備一定規模且國家或地區認證或成立的榜單（同一組織或單位發佈的榜單視為同一榜單）”。Sanmosa _{Királyunk s a közhazát} 2022年6月28日 (二) 05:23 (UTC)

確定是鄰國效應不是文化環境嗎？照地理來看比起希臘，賽普勒斯還比較靠近土耳其，但現實是兩著一家親。回到中國，先不提自家人沒官方榜單也不信任那些商業平台，香港台灣乃至於新加坡等華語圈也有榜單，如果真的要靠拉低榜單標準來達成關注度，那還不如刪掉算了。 --Loving You Is A Losing Game 2022年6月24日 (五) 13:53 (UTC)

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

建議條文和現行條文有什麼分別？我沒看出來。--AT 2022年6月24日 (五) 12:44 (UTC)

現行條文要求兩個國家或地區的兩個榜單或以上，建議條文只要求一個國家或地區的兩個榜單或以上。--Billytanghh 討論 歡迎參與亞洲月 2022年6月24日 (五) 17:16 (UTC)

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

已修改。--Billytanghh 討論 歡迎參與亞洲月 2022年6月24日 (五) 19:38 (UTC)

改成一國兩榜的話，前十位實在太容易了，前三位的話可以考慮。這樣也可以同時保留原本的兩國兩國前十的條文。--AT 2022年6月26日 (日) 13:44 (UTC)

(？)疑問，其他地域不是特别清楚，但就中国大陆地区而言，音乐榜单实在是太多了，仅以QQ音乐为例，其就包括了所谓“巅峰新歌榜”、“巅峰人气榜”、“巅峰流行指数榜”等等，其中这些榜单还包括所谓“日榜”、“周榜”、“月榜”。个人观点，对所谓“榜单”应有更明确限制，否则仍然无法满足关注度之要求。--SheltonMartin留言|签名 2022年7月7日 (四) 01:37 (UTC)

我認為應該將榜單限制至「週榜」或以上。--Billytanghh 討論 歡迎參與亞洲月 2022年7月16日 (六) 11:54 (UTC)

(！)意見：對於相關條文，敝人認為或可同時保留具備跨國或跨地域知名度，以及增列於單一國家或地區之流行或傳播代表性的收錄門檻，因此個人傾向仍保留「作品至少登上兩個國家或地區的音樂榜單前十名內」之條文，同時異動增列的條文為「作品至少登上一個具有一定規模的國家或地區月、年排行榜或兩個周排行榜前三名內，但登上同一個榜單的不同類別不在此列。」。--Kriz Ju（留言） 2022年7月18日 (一) 00:36 (UTC)

@Kriz Ju：兩個周排行榜本身就是很嚴格的條件，個人認為不用加改為前三名。 --窝法乙烷 儿法梦碎 2022年7月19日 (二) 02:33 (UTC)

不然依Milkypine君您研究所得看看好了，個人無甚意見。--Kriz Ju（留言） 2022年7月20日 (三) 15:45 (UTC)

既然要改順便整理一下其他內容好了。周榜單仍維持前10，另加上年月，是說不符榜單限制也可以曲線救國，畢竟符合一般關注度。 --窝法乙烷 儿法梦碎 2022年7月17日 (日) 16:07 (UTC)

現行條文 音樂家與音樂團體 維基百科中有許多樂團、歌手與其他音樂家、音樂團體的條目。 如果滿足以下條件其中之一，音樂家或音樂團體（包含樂團、歌手、饒舌歌手、樂隊、嘻哈樂團、DJ、音樂劇團等）被视为具有關注度： 他們曾經被多份獨立於該音樂家或團體以外的已出版可靠來源所提及。 作品至少登上兩個國家或地區的音樂榜單前十名內，但不適用於登上同一個榜單的不同類別與單一國家或地區內的多個榜單。 在至少一個國家或地區取得金唱片或更高級的唱片認證。 曾經獲得主要的音樂獎項，例如葛萊美獎、朱諾獎、水星音樂獎、金曲獎或选择音乐奖等。 另外，通常音樂團體成員的條目比較適合重定向到該擁有關注度的團體條目中，而非設置獨立的個人條目，除非他們有足夠個人關注度，比如擁有個人專輯等等。 作詞家與作曲家 對於作曲家、填詞家或編曲家，符合以下條件之一，具有關注度： 作品取得金唱片或更高級的唱片認證。 曾經獲得主要的音樂獎項，例如葛萊美獎、朱諾獎、水星音樂獎、金曲獎或选择音乐奖等 作品至少登上兩個國家或地區的音樂榜單前十名內，但不適用於登上同一個榜單的不同類別與單一國家或地區內的多個榜單。 音樂作品 音樂作品需要满足下列条件之一才符合关注度： 该作品在至少在一地取得金唱片或更高級的唱片認證 该作品赢得了具關注度的國際性奖项（如葛萊美獎、朱諾獎、水星音樂獎等）或該地區受廣泛認同的音樂獎項。 作品至少登上兩個國家或地區的音樂榜單前十名內，但不適用於登上同一個榜單的不同類別與單一國家或地區內的多個榜單。 不满足關注度标准的作品條目應該被合併到相关条目（如專輯、艺人、词曲创作人或制作人等等）條目中。 参考資料

提議條文 音樂家與音樂團體 維基百科中有許多樂團、歌手與其他音樂家、音樂團體的條目。 如果滿足以下條件其中之一，音樂家或音樂團體（包含樂團、歌手、饒舌歌手、樂隊、嘻哈樂團、DJ、音樂劇團等）被视为具有關注度： 他們曾經被多份獨立於該音樂家或團體以外的已出版可靠來源所提及。 作品至少在一地取得金唱片或更高級的唱片認證。 曾獲得具關注度的國際性奖项（如葛萊美獎、朱諾獎、水星音樂獎、金曲獎、选择音乐奖等）或該地區受廣泛認同的音樂獎項。 作品至少登上一个具有一定规模的国家或地区月、年音樂銷售（銷量）排行榜或两个周音樂銷售（銷量）排行榜頭十名內，但登上同一組織或單位發佈榜單的不同类别不在此列。 另外，通常音樂團體成員的條目比較適合重定向到該擁有關注度的團體條目中，而非設置獨立的個人條目，除非他們有足夠個人關注度，比如擁有個人專輯等等。 作詞家與作曲家 對於作曲家、填詞家或編曲家，符合以下條件之一，具有關注度： 作品至少在一地取得金唱片或更高級的唱片認證。 曾獲得具關注度的國際性奖项（如葛萊美獎、朱諾獎、水星音樂獎、金曲獎、选择音乐奖等）或該地區受廣泛認同的音樂獎項。 作品至少登上一个具有一定规模的国家或地区月、年音樂銷售（銷量）排行榜或两个周音樂銷售（銷量）排行榜頭十名內，但登上同一組織或單位發佈榜單的不同类别不在此列。 音樂作品 音樂作品需要满足下列条件之一才符合关注度： 作品至少在一地取得金唱片或更高級的唱片認證。 作品獲得具關注度的國際性奖项（如葛萊美獎、朱諾獎、水星音樂獎、金曲獎、选择音乐奖等）或該地區受廣泛認同的音樂獎項。 作品至少登上一个具有一定规模的国家或地区月、年音樂銷售（銷量）排行榜或两个周音樂銷售（銷量）排行榜頭十名內，但登上同一組織或單位發佈榜單的不同类别不在此列。 不满足關注度标准的作品條目應該被合併到相关条目（如專輯、艺人、词曲创作人或制作人等等）條目中。 参考資料

1. 排行榜條文改為「作品至少登上一个具有一定规模的国家或地区月、年音樂銷售（銷量）排行榜或两个周音樂銷售（銷量）排行榜頭十名內，但登上同一組織或單位發佈榜單的不同类别不在此列」
2. 排行榜中的一定规模定義為「涵蓋多個來源的銷售或播送渠道，並由公認的可靠來源組織和機構製作、發佈」

@Kriz Ju、Billytanghh、SheltonMartin、AT、BlackShadowG、Sanmosa、ghrenghren：@中文維基百科20021024、LuciferianThomas、魔琴、Benevolen：公示前，想先確認各位是否可以接受以上內容。 --窝法乙烷 儿法梦碎 2022年7月21日 (四) 01:09 (UTC)

我的观点与Kriz Ju一致，排行榜应该具有跨地域或跨国限制，至少应该在两个（含）以上的国家和地区登上榜单方可认为具有关注度。--SheltonMartin留言|签名 2022年7月21日 (四) 02:02 (UTC)

(＋)支持相關修訂：個人認為此類條目通常以面向大眾讀者（和聽眾）為主，細觀既已有一定規模榜單之限制，當中提及「由公認的可靠來源發佈或是公認的國家觀測公司」（已要求此類榜單須具跨地域之知名度或代表性），亦「涵蓋多個來源的銷售或播送渠道」（已要求此類作品之銷量和播出管道涵蓋完整性），對於相關條目所具備之「公眾關注」和「市場成績」應已有最低限度要求，也有助於關注此領域的所有熱心編者往後能建立在商業市場具一定關注度的音樂領域條目分享給讀者。題外話，個人前面已表達「個人無甚意見」，未和樓上站友意見一致，感謝（笑）。--Kriz Ju（留言） 2022年7月23日 (六) 22:14 (UTC)

看來是沒啥問題，那就用這個版本公示7日。 --窝法乙烷 儿法梦碎 2022年7月29日 (五) 08:07 (UTC)

一定规模榜單

参见：Wikipedia:音樂銷量排行與認證

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

前面討論有提議改符合關注度的榜單，但後來想想這樣東西會太多太雜，所以列了符合條件和不符合條件。抱歉Billytanghh大我回退你的內容，但這裡放入單一渠道榜單並不合適，至少你要加應該把「避免內容」的「它僅憑藉單一發行商或渠道的成績製作榜單」砍掉，另一方面是像HKRIA版權風波的情況，歌曲喪失上榜資格無法展現商業表現。 --Loving You Is A Losing Game 2022年7月1日 (五) 12:03 (UTC)

其實五台榜單不太算是「單一渠道榜單」，叱咤樂壇流行榜的排名要同時參考香港電台的播放數字，Chill Club 推介榜也是由各唱片公司代表投票決定的。--Billytanghh 討論 歡迎參與亞洲月 2022年7月2日 (六) 01:45 (UTC)

@Billytanghh：投票的Chill Club 推介榜可能沒法放在這裡，至於叱咤樂壇流行榜，有沒有直接導向的網站？我看都導到903推介，還是現在903推介繼承他的業務。 --Loving You Is A Losing Game 2022年7月2日 (六) 04:43 (UTC)

请教“投票的Chill Club 推介榜可能沒法放在這裡”的原因是？Grammy和Academy也是投票决定的哦？--Benevolen（留言） 2022年7月17日 (日) 16:50 (UTC)

這裡是銷售排行不是投票排行，況且應該沒有人認為Grammy和Academy是排行吧。 --窝法乙烷 儿法梦碎 2022年7月19日 (二) 03:17 (UTC)

我的理解“作品至少登上兩個國家或地區的音樂榜單”并未暗示必须是“銷售排行”。音乐市场数字化之前华语乐坛也并没有专门的单曲销量榜，音樂榜單等同于传媒的流行榜，类似今天的“投票”榜。--Benevolen（留言） 2022年7月19日 (二) 04:05 (UTC)

這裡的音樂榜單是“銷售（销量）排行”（上面提案也特別寫道為「一定規模的音樂榜單是指該榜單涵蓋多個來源的銷售或播送渠道，並由公認的可靠來源組織和機構製作、發佈」），還是你覺得各大評論的年度專輯年度歌曲算音樂榜單？不學Everyday、髮箍#銷售排行榜那年代用銷售除了懶，多少也考慮到電台或串流無法用銷售代稱，但這不表示投票就該納入，串流好歹聽個１０００次會讓一人收到錢，投票可不會，況且投票門檻低，只要創帳號甚至不用都可以參與，就算公信力沒問題，它的性質更適合擺在「評價」而非跟其他「銷售（销量）排行」擺在一起

先不吐槽幹嘛自甘墮落不看銷量，销量榜可是一直都有，例如大陸的信诺榜、台灣的Hito排行榜、香港的叱咤樂壇流行榜。 --窝法乙烷 儿法梦碎 2022年7月19日 (二) 05:22 (UTC)

上面的长篇提案，其实目的就一个：证明关注度。销售和播送当然反映关注度，像Grammy和Academy等专业评选也是关注度。“Chill Club 推介榜也是由各唱片公司代表投票決定的”，代表了业内人士的专业意见，Chill Club 推介榜和历史更长、性质类似的劲歌金榜在当地都有广泛认受性，加在这里合理啊。至于“各大評論的年度專輯年度歌曲”，那得看“各大評論”是不是“由公認的可靠來源組織和機構製作、發佈”了，如果New York Times选出个年度华语歌曲呢？--Benevolen（留言） 2022年7月19日 (二) 06:28 (UTC)

目前為止標準有4條，你的要求完全能夠通過其它3條，甚至是一般關注度實現，音樂榜單這項只根據销售和播送認證關注度，想要有其它要求應該是另聘新規，而不是音樂榜單，Chill Club 推介榜不適用於此不等於它不能證明關注度。 --窝法乙烷 儿法梦碎 2022年7月19日 (二) 07:09 (UTC)

原来阁下一直坚持评选榜单不算榜单的原因是阁下最近从英维翻译过来的论述里有类似提法，怪不得在这里总辩不明白。上面讨论的其实是英维对“榜单”的理解是不是该照搬过来。本人觉得如果告诉一位香港人说勁歌金榜不是一份音乐榜单将会是违背常识的。--Benevolen（留言） 2022年7月19日 (二) 08:00 (UTC)

扯英維之前你有沒有想過為啥投票榜不在上面的原因？因為這裡討論的就是銷量，你現在跟我槓誰是音樂榜單，難道承認用詞不精準還不行嗎？再說，這裡唯一一個打字有出現勁歌金榜不是一份音乐榜单的人是你，如果你覺得音乐榜单這四個字無法符合你的期待，那就是改成銷售（销量）排行。 --窝法乙烷 儿法梦碎 2022年7月19日 (二) 13:10 (UTC)

回首過去，當初的確沒想這麼多，雖然討論銷量但名詞卻沒能讓讀者接受到訊息，造成誤會。至於一定規模的探討...當初應該用草稿OTZ。 --窝法乙烷 儿法梦碎 2022年7月19日 (二) 13:27 (UTC)

本人的确想过“為啥投票榜不在上面的原因”所以特地找了阁下翻译的论述的原文，发现论述中的两句“須避免以下幾點......它由票選產生”是阁下的原创标准，而阁下提供的例子“匈牙利唱片公司協會「Editors' Choice Top 40 slágerlista」和《滾石》「五百大專輯」等編輯評選榜單”似乎是单一机构的内部评选，与上面讨论提及的“Chill Club 推介榜......由各唱片公司代表投票決定”可能能代表更广泛、多方面意见的情况并不相同。“改成銷售（销量）排行”的确能解决概念不清的问题，至于这样一来大家是否仍然能认同新规则、Chill Club 推介榜和劲歌金榜之类榜单是不是对NMSUIC完全不起作用则需另商。--Benevolen（留言） 2022年7月19日 (二) 15:12 (UTC)

老實說銷量和評選是兩回事，這也是為啥嚴格算是獎項的唱片認證會和獎項分開，对NMSUIC完全不起作用也不是什麼大問題，看看Wikipedia:关注度#通用關注度指引，Chill Club 推介榜要是不符合就不會有條目了。至於這類榜單的詳細應用，就交給閣下想了。 --窝法乙烷 儿法梦碎 2022年7月19日 (二) 15:59 (UTC)

一次性ping 50个人以上不会有效果。 ——魔琴 [ 留言 贡献 ] 2022年7月4日 (一) 14:24 (UTC)

原來超過50...，那我分批。 --Loving You Is A Losing Game 2022年7月4日 (一) 15:14 (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)

修正快速刪除方針

R7快速刪除準則自從2019年設立以來，屢次遭到濫用或擴大解讀，已然背離重新導向制度本身之精神、損及百科全書體系之運作。故在此提議修正快速刪除方針如下：

現行條文 （略） R7. 明顯與導向目標所涵蓋的主題無關或比導向目標所涵蓋的主題更廣泛的重定向。 （略）

提議條文 （略） R7. 明顯與導向目標所涵蓋的主題無關的重定向。 （略）

此提案僅影響一般無需討論之快速刪除操作，若欲提刪者有扎實之提刪理據，仍然可以按正常程序提交各種存廢討論，不受任何阻礙。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年7月11日 (一) 09:17 (UTC)

R7修訂公示版本

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

現行條文 R7. 明顯與導向目標所涵蓋的主題無關或比導向目標所涵蓋的主題更廣泛的重定向。 掛有{{关注度重定向}}或{{合併重定向}}模板的頁面不適用，請改為提出存廢討論。 如有用戶對標題用字存在未解決的爭議，則應交由存廢討論處理。

提議條文 R7. 明顯與導向目標所涵蓋的主題無關或比導向目標所涵蓋的主題更廣泛的重定向。 条目完全未提及重定向的名称，或重定向名称比条目主题更广泛，但条目不含有重定向名称的有效介绍。同时，重定向名称并不是条目的别名或错误拼写。有争议的情况下，应提出存廢討論。 如果原重定向标题可改成消歧义页（或重定向至其他消歧义页），则不应删除。 掛有{{关注度重定向}}或{{合併重定向}}模板的頁面不適用，請改為提出存廢討論。 如有用戶對標題用字存在未解決的爭議，則應交由存廢討論處理。

例如： （以下扩充中）

R7适用和不适用情况举例

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

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

(＋)支持總體概念，GZWDer版更為清晰，(＋)傾向支持該版本。--路西法人 2022年7月12日 (二) 03:22 (UTC)

行。總之能避免濫用規則就好。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年7月12日 (二) 14:54 (UTC)

(＋)支持及(！)意見：以此列表而言，敝人表達個人意見：

• 關於「金三胖」：目前未重定向至傳主條目，亦未見於當前導向之條目「中國大陸網路熱點事件列表」中存在相關內容（故目前實用性不明，抑或曾經人為移動編輯之類（笑））。個人揣想若回歸站友提案修訂之初衷以及一般「生者傳記」的重定向論之，假設該重定向已導向至傳主「金正恩」之條目，敝人傾向於：

• 「重新導向目標是否提到重新導向頁面名稱」一欄認定為：「是，有提及但無有效介紹」，而「是否符合（修訂後的）R7」一欄為：「否，對於具攻擊或嘲諷性等負面或爭議內容之生者傳記重定向，由於事涉傳主人身名譽保護法益和相關法律風險（含編者自身可能遭遇之法律或訴訟風險），故涉及在世傳主人身形象評價之重定向於使用上，建議編者應確保該重定向同時符合可供查證、於公領域廣為使用、具大量可靠來源證其具備並非短期之顯明關注度，且其生成或存續之因果於公共領域具社會影響力為宜。」。

• 關於「廣台高速公路」：已自成條目。個人意見，供參。--Kriz Ju（留言） 2022年7月14日 (四) 21:23 (UTC)

暫時沒意見。Sanmosa _{Királyunk s a közhazát} 2022年7月16日 (六) 15:53 (UTC)

所以，2016年中国矿难列表應該是不符合吧？--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年7月17日 (日) 10:18 (UTC)

不符合。--Kriz Ju（留言） 2022年7月17日 (日) 23:41 (UTC)

---

提案已14日且無反對意見，幫推一下， 公示7日，2022年8月1日 (一) 01:35 (UTC) 結束。--路西法人 2022年7月25日 (一) 01:35 (UTC)

能否說明你要公示GZWDer版本還是Eric Liu 版本。--Ghren🐦🕕 2022年7月25日 (一) 10:28 (UTC)

幫ping@LuciferianThomas--🚊。鐵路Railway ^論 2022年7月28日 (四) 00:30 (UTC)

有副標題#R7修訂公示版本啊，而且公告欄的連結也是直指副標題。--路西法人 2022年7月28日 (四) 03:49 (UTC)

我又不會從T:B直接點下去看。我認為現在的方案過於繁雜了，要合「新導向名稱比條目主題更廣泛」一項，則要排除「條目不含有重新導向名稱的有效介紹」、「重新導向名稱並不是條目的別名或錯誤拼寫」、「重新導向標題可改成消歧義頁」三項，以這繁瑣條件，基本上和廢掉沒有分別。還有什麼「如果原重新導向標題可改成消歧義頁（或重新導向至其他消歧義頁），則不應刪除。」，這裏的意思應該是不合此款而不是「不應刪除」吧。--Ghren🐦🕒 2022年7月29日 (五) 07:15 (UTC)

(！)意見：綜觀兩案，若以快速刪除方針主要用途為「加快處理顯然不合適的頁面或檔案的情形，如果有爭議的不應該適用。」之核心功能和意旨而言，上方提案精簡有力，敝人亦無甚意見。就個人粗淺認知，綜觀站友所提兩案之實際效果和用途皆為規限適用條件，而關鍵差異在於是否容許如「條目完全未提及重定向的名稱」即可適用快速刪除、「是否屬於條目的別名」、「是否可改成消歧義頁」等實務情境之明列，或可視實務需求考慮將下方提案之「例外排除情形的說明內文」適當納入結合（當中條文的字面可考慮異動為「如果原重定向標題可改成消歧義頁（或重定向至其他消歧義頁），則不適用。」。若相關修訂可增益於條文實務應用、減少誤用和濫用、降低不必要的判斷和無謂爭議甚至維運成本，或皆有益處。--Kriz Ju（留言） 2022年7月31日 (日) 22:25 (UTC)

参考資料

修订编辑战方针

現行條文 下述行为在适用回退不过三原则时，不视为一次回退。 ... 移除涉嫌诽谤、非中立、无来源或来源不充足，违反生者传记方针的争议材料。

提議條文 移除涉嫌诽谤、非中立、无来源或来源不充足且违反生者传记方针的争议材料。

鄙人认为该方针有修改的必要性，因为某用户就以来源不充足为由在中华人民共和国条目大肆回退。“来源不充足”的理由可以适用于很多回退，故应加以限制。--QiuLiming1（留言） 2022年7月12日 (二) 05:19 (UTC)

(－)強烈反对，可供查證是維基百科的核心方針，此與是否編輯戰無關。方針不是給你改來改去搬龍門的。--路西法人 2022年7月12日 (二) 09:03 (UTC)

您看方针页面后半句不都写着这个有争议吗？如果编者A，B都一直回退别人的编辑且都没来源，那这样岂不是可以无穷无尽回退？--QiuLiming1（留言） 2022年7月12日 (二) 15:31 (UTC)

在英维问了一下 [3]，他们均认为回退无来源的非生者传记是属于编辑战，应按照Wp:争议的解决处理。虽然WP:ENWPSAID，但可以作为参考。--QiuLiming1（留言） 2022年7月13日 (三) 22:50 (UTC)

Special:diff/46256983等修改看得出這是為了生者傳記定的，和你這個中華人民共和國有什麼關係。--Ghren🐦🕛 2022年7月12日 (二) 16:22 (UTC)

[4] 方针写的是“或”，也就是如果少来源就可以回退，不需要属于生者传记，我就建议改一个字而已。--QiuLiming1（留言） 2022年7月12日 (二) 16:38 (UTC)

他整句的意思是假如相關內容是「誹謗、非中立、無來源或來源不充足」且是「在世人物的傳記內容」，就合符相關的規定，而不是單純「不中立」、「沒有來源」就不作3RR之內，以此作為非3RR的理由必需要其內容不合於生者傳記方針。--Ghren🐦🕐 2022年7月12日 (二) 17:46 (UTC)

是断句问题？先前条文和当前提案感觉都不太好。另见en:Wikipedia:3RRNO的英文原文。建议：

• 方案1：“移除涉及生者传记方针的涉嫌诽谤、有偏见、无来源或来源欠佳的争议材料。”
• 方案2：“移除涉及生者传记方针的涉嫌诽谤、有偏见、无来源或来源不充分的争议材料。”
• 方案3：“移除涉及生者传记方针的涉嫌诽谤或有偏见的无来源或来源欠佳的争议材料。”

相关想法：1. 仅观提案中的条文，我最初以为针对非生者的诽谤材料（如针对产品的指控）也因此条豁免3RR。2. “涉及生者传记方针”应是不限于人物条目，也包括其他条目中对生者的介绍和评价。3. 个人建议称“有偏见”（英文方针原文biased）而非“非中立”，非常中立的来源和评价并不多，宣传性语调等问题也不需豁免反复回退。4. “来源不充足”或难以判断，而“来源欠佳”是否比较容易，观其可靠性即可，充足性问题应经讨论决定（如所有来源的宣传性/地域中心）。英文原文poorly sourced。不过此条也可再议。5. 方案3想法是将无来源但不具明显问题的材料排除3RR豁免，虽有WP:GAME方针，如果有用户坚持移除生者传记条目中所有无来源脚注的材料（并拒绝自行查证、{{fact}}等方案），具此豁免是否不合适。--YFdyh000（留言） 2022年7月12日 (二) 18:20 (UTC)

偏向第一条，都说了是争议材料不需要重复。--QiuLiming1（留言） 2022年7月12日 (二) 18:47 (UTC)

(！)意見 “非中立”说的应该是写在维基百科条目的内容“非中立”，并不要求来源是中立的。--Yinyue200（留言） 2022年7月13日 (三) 14:39 (UTC)

(－)反对：若这样修改，回退IP用户的多次破坏就会违反3RR。--BlackShadowG Slava Ukraini! 2022年7月13日 (三) 09:57 (UTC)

@BlackShadowG："回退破坏不是编辑战"，前面已经写了，不需重复规定。--QiuLiming1（留言） 2022年7月13日 (三) 15:36 (UTC)

那鄙人支持此项修订。看了英文维基百科的原文，那边写的就是违反BLP的才算，可能是最初翻译不佳，导致现在被过度解读了。--BlackShadowG Slava Ukraini! 2022年7月17日 (日) 13:59 (UTC)

從頁面的敘述，修改的內容和下面的內容無關

回退自己的編輯（「自我回退」）。回退在自己使用者空間中的編輯，前提是你必須遵守使用者頁面指引。回退明顯的破壞行為，即指任何一個假定他人的編輯是出於善意的使用者都會認為是破壞的編輯，例如清空頁面或是添加攻擊性語言。移除明顯侵犯著作權，或是毫無疑義違反合理使用方針的內容。移除明顯違反維基百科伺服器所在地——美國佛羅里達州法律的內容，例如兒童色情內容或盜版軟體。為了確保在首頁展示的特色列表和優良條目的品質而進行的回退操作，給予使用者一定的自由空間。

(？)疑問 @QiuLiming1 移除涉嫌誹謗、非中立、無來源或來源不充足，違反生者傳記方針的爭議材料。對於刪除何種內容可享有生者傳記方針豁免而不受回退不過三限制可能會存有爭議。遇有不清晰或有爭議，則建議先行提報至互助客棧，而非依賴前述豁免。為什麼有必要改成移除涉嫌誹謗、非中立、無來源或來源不充足且違反生者傳記方針的爭議材料。對於刪除何種內容可享有生者傳記方針豁免而不受回退不過三限制可能會存有爭議。遇有不清晰或有爭議，則建議先行提報至互助客棧，而非依賴前述豁免。差別只有將，換成且--Rastinition（留言） 2022年7月17日 (日) 14:07 (UTC)

@Rastinition： 已换成YF君的方案，“移除涉及生者传记方针的涉嫌诽谤、有偏见、无来源或来源欠佳的争议材料。”--QiuLiming1（留言） 2022年7月17日 (日) 15:22 (UTC)

重申一遍现在的观点：改成移除涉及生者传记方针的涉嫌诽谤、有偏见、无来源或来源欠佳的争议材料。

另外我看到英维也在讨论相关条文（en:Wikipedia_talk:Edit_warring#Making_WP:3RRNO_point_7_more_specific），要不要等到他们讨论完后再做决定？--QiuLiming1（留言） 2022年7月20日 (三) 22:32 (UTC)

(！)意見：個人認為可待英文維基百科相關討論結束後看看是否有可挪用補充之內容。--Kriz Ju（留言） 2022年7月29日 (五) 21:34 (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)

本討論章節會維持開放，暫時不按最後意見發表時間存檔，直到相關技術問題解決。欲讓機器人存檔，請移除本模板。留言請置於本模板上方。

配置表单来方便用户发邮件申请账户或申请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)

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

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

確認頁面空間條目與學校相關內容是否需建立獨立方針/指引頁

近期編輯的頁面因為傀儡的關係，大多是學校頁面，但zh.wikipedia.org似乎沒有方針/指引頁系統性的提到學校頁面應該如何撰寫

參考en.wikipedia.org的論述Wikipedia:WikiProject_Schools/Article_advice整理成Draft:英文維基百科學校專題編寫建議

想確認這個草稿是否具備被社群編修、討論或投票程序而成為指引的價值，如果頁面沒有成為指引的價值，就依草稿流程等候刪除或者改標題後設置在論述中。--Rastinition（留言） 2022年7月17日 (日) 00:44 (UTC)

竊以為當中多數內容和觀點已為一般內容收錄準則所規範，該建議頁面亦為熱心編者之經驗分享和提示，敝人認為主要屬「個人論述」，或可提供有興趣之站友參閱討論。感謝翻譯。--Kriz Ju（留言） 2022年7月17日 (日) 13:07 (UTC)

@Rastinition：可參閱WikiProject:學校。--S099001（留言） 2022年7月27日 (三) 13:11 (UTC)

已經看到維基專題:學校/條目指引頁面，謝謝--Rastinition（留言） 2022年7月27日 (三) 13:29 (UTC)

不知道您有沒有興趣將您撰寫的草稿與學校專題的條目指引論述合併，再送交互助客棧討論。學校類條目如果能有一個專門的指引，會是很棒的一件事，學校條目要不是常常被拿來廣告，就是被不滿的學生上來破壞。--S099001（留言） 2022年7月27日 (三) 15:00 (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)

提议修改优特内容评选规则

提议修改所有优特内容评选规则，提名人或主编需回应所有意见，除明显的扰乱性意见以外，对于合理意见，应当按照意见修改候选条目，对于不合理意见，应当说明其不合理之处。到投票期结束为止，未对意见做出合理回应者，即使票数达标，也应当落选。--——٩(๑❛ᴗ❛๑)۶这里是浣熊君(Raccoozzy)【浣熊窝欢迎您】 2022年7月19日 (二) 14:08 (UTC)

以优良条目为例：

現行條文 评选期为7日。评选期结束后绝对票有至少6票符合优良条目标准（“符合优良条目标准”和“不符合优良条目标准”相互抵消，如8符合，2不符合，绝对票就是6），且不符合优良条目标准票数低于或等于总票数三分之一（如16符合8不符合。另中立票不计入总票数，仅有参考意义），该列表就入选或维持优良条目（如果已经是优良条目）。如时效已过未达要求，提名条目从名单删除并存档。

提議條文 评选期为7日。评选期结束后绝对票有至少6票符合优良条目标准（“符合优良条目标准”和“不符合优良条目标准”相互抵消，如8符合，2不符合，绝对票就是6），不符合优良条目标准票数低于或等于总票数三分之一（如16符合8不符合。另中立票不计入总票数，仅有参考意义），且提名人对所有意见给出合理回应（对于合理意见，应当按照意见改进候选条目，对于不合理意见，应当说明其不合理之处，明显的扰乱性意见除外），该列表就入选或维持优良条目（如果已经是优良条目）。如时效已过未达要求，提名条目从名单删除并存档。

——٩(๑❛ᴗ❛๑)۶这里是浣熊君(Raccoozzy)【浣熊窝欢迎您】 2022年7月19日 (二) 14:23 (UTC)

如此者投票期理應相應延長以讓編者有時間修改。--Ghren🐦🕙 2022年7月19日 (二) 14:47 (UTC)

這是否能算是內容評選從投票制轉向共識制的一種跡象？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年7月19日 (二) 14:55 (UTC)

不算。共識制也不是波蘭式一票否決權。Sanmosa _{Királyunk s a közhazát} 2022年7月19日 (二) 15:03 (UTC)

(－)反对，提案很明顯可以被鑽漏洞，也為參與評選者帶來不必要的麻煩。雖然情況較極端，但中文維基百科之前在其他類型的投票都有類似的問題，所以還是舉一下例：假設現在有一個FA評選已有足夠票數通過，有人在評選期結束的幾分鐘前加插一個意見，就算他投的是yesFA，根據提案，該FA評選亦將作不通過論，這明顯是不合理的，也同時違背該投票人的意願。提案人應無此意，但各內容評選中刻意找條目主編或提名人的麻煩的用戶並不在少數，我認為此提案就算作出任何的微調均無法妥善解決此一根本性問題。Sanmosa _{Királyunk s a közhazát} 2022年7月19日 (二) 15:03 (UTC)

感谢阁下的建议，您说的情况我也考虑过，我认为可以相应修改评选期的规定，例如，在距离评选期截止不足24小时的时间内添加新的意见的，评选期延长至自该意见添加之时的24小时后（具体时间可以讨论）。反复在截止前添加无意义的意见或明显的扰乱性意见，导致评选无法结束的用户视为破坏。——٩(๑❛ᴗ❛๑)۶这里是浣熊君(Raccoozzy)【浣熊窝欢迎您】 2022年7月19日 (二) 15:18 (UTC)

問題未獲根本性解決。假設延長的次數是有限的，我上方提到的問題顯然仍然存在，而假設延長的次數是無限的，可以被鑽的漏洞就變成不斷提意見使評選期遭無限延長，此無異於延宕否決（suspensive veto），就優特內容評選而言實屬浪費社羣資源。另一方面，「反覆」的定義不明，而且有些人是會刻意隔幾個月這樣來一兩次的，也不算「反覆」。我認為如果真的想從投票制轉向共識制的話，惟一可行的辦法是一次性直接變更制度為共識制。Sanmosa _{Királyunk s a közhazát} 2022年7月19日 (二) 15:26 (UTC)

隔几个月这样来一两次似乎问题不大，不过是每隔几个月有一两个评选被延长一天而已。我所说的「反复」指的是在同一次评选中的「反复」，导致该次评选无法结束的。--——٩(๑❛ᴗ❛๑)۶这里是浣熊君(Raccoozzy)【浣熊窝欢迎您】 2022年7月19日 (二) 15:41 (UTC)

那還是回到「反覆」的定義不明的問題了，不同管理員的判斷均不同，這樣很容易令主編直接放棄條目。Sanmosa _{Királyunk s a közhazát} 2022年7月19日 (二) 15:56 (UTC)

個人樂見這種轉變，但是感覺執行上有系統性問題。比如提名者可否用「意見是FA標準的要求，現在只解決不符合GA標準的問題」（可能措辭更委婉）回應？如果這樣謝絕修改算有效回應，那我認為我們現在的方針指引和操作慣例還跟不上。畢竟「符合GA標準」的條目是甚麼樣，大家看法可能都很不一樣。--洛普利寧 2022年7月19日 (二) 15:15 (UTC)

提名人與投票人意見走向兩極是常有的事，現在DYKC就一個已連續5次落選的案例，每一次都在爭論同一個問題。如果這類案例發生在GAC/FAC，雙方到了限期尾聲仍不斷持續爭論，假如新規則又可以無限延長，有否想過這可能造成的積壓？--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年7月20日 (三) 14:43 (UTC)

这种情况下可能需要第三方的介入。总之我也很乐于见到条目评选从纯投票制到共识制的转变。--BlackShadowG Slava Ukraini! 2022年7月21日 (四) 12:41 (UTC)

不太赞同，GA和FA不需要是完美的条目。--Yinyue200（留言） 2022年7月31日 (日) 12:54 (UTC)

快速删除方针的G1准则

WP:CSD里的G1标准“没有实际内容的页面”没有提是否适用于条目讨论页，这版编辑被提G1速删，最后速删模板被管理员移除，本人还见过一些类似页面（空白讨论页面）被提出速删，故想寻求社群共识，明确规定关于讨论页是否使用G1准则。--QiuLiming1（留言） 2022年7月22日 (五) 05:47 (UTC)

「所有頁面必須保證無任何版本可回退，才可提報快速刪除。」如果有一個版本不符合「沒有實際內容的頁面」，那麼只要回退到那個版本就可以消除G1的情況，因此不符速刪準則。--Xiplus#Talk 2022年7月22日 (五) 06:06 (UTC)

是的，但是按照那个例子，我经过他人提醒，自行回退了那个编辑，这个难道要强制回退？--QiuLiming1（留言） 2022年7月22日 (五) 06:09 (UTC)

退一步说，即使真的是空白，增加一个维基专题也不是很难吧。--QiuLiming1（留言） 2022年7月22日 (五) 06:11 (UTC)

若單看此案，使用G10管理員可能會酌情刪除。--Xiplus#Talk 2022年7月22日 (五) 06:13 (UTC)

我的建议是加进去

• 对于条目讨论页，建议加入相应条目的维基专题--QiuLiming1（留言） 2022年7月22日 (五) 19:55 (UTC)

维基百科:关注度/提报問題

請問這個頁面中的條目一定要按照UTC時間才能算到期並提報嗎？我今天在UTC+8 7:00左右提刪6月27日提報的條目，鐵路1在User talk:日期20220626#AFD叫我8：00（UTC+8）後提報，我對這個以UTC為中心的做法表示質疑，因為中文使用者大部分都居住在UTC+8，自己沒必要去跟著UTC來。

我在他的討論頁User talk:鐵路1#AFD問題表示日語維基就按照他們UTC+9的時區行事。例如，7月24日 UTC+9 0:00過後提刪的條目就算在7月24日的提刪討論頁面，而此時UTC還是2022年7月23日。

我又來到twinkle的telegram群組詢問xiplus（[5]），twinkle提刪能否自己設置時區（目前在UTC+8 8:00前用twinkle提刪，條目或頁面會算在前一天的存廢討論，除非自己手動更改），xiplus解釋「站務運作遵循一套統一標準」，我表示為何要以UTC為標準，根本就沒有多少人居住在UTC，不應UTC就是所謂的標準時區，一大堆UTC+8的人就要圍著UTC團團轉。--日期20220626（留言） 2022年7月27日 (三) 02:22 (UTC)

方便技术实现吧，统一使用UTC作为时间划分标准，可以不用考虑因为时区差异而需要调整的处理。而且不要假设全部中文区编辑都在UTC+8区。——Sakamotosan路过围观 | 避免做作，免敬 2022年7月27日 (三) 03:00 (UTC)

不就跟北京时间#中国西部地区时间问题一樣？不住在UTC+8的也要配合用UTC+8。--Xiplus#Talk 2022年7月27日 (三) 03:51 (UTC)

所以爭議就出在要不要以某個時區為標准，這樣的話UTC也好UTC+8也罷都一樣，而且以前者為標準更不合理。--日期20220626（留言） 2022年7月27日 (三) 04:18 (UTC)

其實吧，差八個小時而已，不一定要這麼嚴格，早一點提報也沒什麼影響。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年7月27日 (三) 04:14 (UTC)

那個群你也在現場，xiplus居然直接跟我說這叫「搗亂」了。--日期20220626（留言） 2022年7月27日 (三) 04:21 (UTC)

Special:Diff/72912490，故意在錯誤的日期提報存廢討論，以及故意不使用簽名語法產生的時間戳格式，不僅僅是「搗亂」，而是WP:擾亂了。--Xiplus#Talk 2022年7月27日 (三) 06:35 (UTC)

就是因為現行的所謂UTC的機制，UTC+8 7月27日 7:28的提刪，你們叫我去7/26的頁面提報，到底哪個才是擾亂？非要一個生活在7月27日的人在維基穿越到7月26日？難道你們都生活在UTC+0以及以西的時區？

至於簽名語法，純粹是懶得改成「--~~~~」，倒不是故意要用+8。--日期20220626（留言） 2022年7月27日 (三) 06:46 (UTC)

對啊，就是生活在這些時區啊。難道不存在這樣的編輯者嗎？--Xiplus#Talk 2022年7月27日 (三) 06:56 (UTC)

那這樣的編輯算是多數還是少數？维基百科:统计#用户来源分布，編輯用戶中UTC佔比只有可憐的1.5%， 81.6% UTC+8的人難道真的要以UTC為準？--日期20220626（留言） 2022年7月27日 (三) 07:12 (UTC)

示例：如果你希望改變現行的提刪程序……理當爭取大家的一致意見。而不要故意違反現行程序。--Xiplus#Talk 2022年7月27日 (三) 06:38 (UTC)

所以今天有人跟我意見不同，你在那個群也不同意我的做法，我不就來互助客棧討論了嗎？不要動不動說別人「故意」。「子非魚，安知魚之樂？」--日期20220626（留言） 2022年7月27日 (三) 07:06 (UTC)

您不是先徵求大家意見，而是已經做出錯誤的行為了。既然Twinkle或是站內的提刪按鈕都是指向7/26的頁面，那您就是應該先遵從這個指示，再來提出這是否有問題，而不是逕自違反這個指示。--Xiplus#Talk 2022年7月27日 (三) 07:16 (UTC)

我认为把本站时区改为UTC+8更合理。现有289个站点设置了自己的时区，技术上是没问题的。--Lt2818（留言） 2022年7月27日 (三) 07:52 (UTC)

技術當然是沒問題，但問題是需要調整許多的基礎建設（模板、小工具、機器人）。--Xiplus#Talk 2022年7月27日 (三) 08:03 (UTC)

可能连一些管理数据会有问题，例如现在{{unsigned}}的时间是要求是UTC的，只需要直接复制页面历史的时间就可以了，改动了站点的时间设置会影响这个数据的录入。——Sakamotosan路过围观 | 避免做作，免敬 2022年7月27日 (三) 09:28 (UTC)

我认为技术实践优先于用户体验，如果强行修改站点时区，可能会影响很多“基础设施” 、涉及时间的规则的设计、配置、计算等。而且无法排除不在UTC+8外的用户，UTC是一个相对公正的时区标准。跨时间的影响可能有限，按照正常的作息从早上6点开始的话，到8点也就是2个小时的日期差。——Sakamotosan路过围观 | 避免做作，免敬 2022年7月27日 (三) 09:39 (UTC)

說到底還是路徑依賴，而不是所謂的UTC有多麼公正。--日期20220626（留言） 2022年7月27日 (三) 09:51 (UTC)

使用UTC在「技術上公正」。--Xiplus#Talk 2022年7月27日 (三) 10:05 (UTC)

没办法，已经发生了。但还是可以灵活解决（例如一些依据日期提报但“放错”时间的提请，可以移到正确的时间上来回避）。——Sakamotosan路过围观 | 避免做作，免敬 2022年7月27日 (三) 11:51 (UTC)

改时区似乎并不能解决提报“放错”时间的问题吧？--百無一用是書生 (☎) 2022年7月28日 (四) 02:18 (UTC)

改時區就可以使用#timel函數，會比較方便設計模板。--Xiplus#Talk 2022年7月28日 (四) 02:48 (UTC)

修改"特色图片标准"

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

(＋)支持--飛馬🎠🎈 2022年7月29日 (五) 14:32 (UTC)

(＋)支持--Yinyue200（留言） 2022年7月31日 (日) 12:59 (UTC)

提議新增一條有關條目評級的指引

由於在維基百科中有許多的專題是十分不活躍的，甚至有的已經廢除，所以在下想新增一條指引，來處理這些沒有所屬專題條目的評級，而在下製作的草本為wp:ge，翻譯至英維，並做出了修改。（此草案在英維為編輯指引）--飛馬🎠🎈 2022年7月29日 (五) 14:47 (UTC)

(＋)支持。如果通過，建議後續在不活躍專題的評級頁面中，增加連結到此頁面。不過因為草稿最後使用了「條目評級專題」的用語，或許可以考慮重啟WikiProject:條目質量評級，並將該專題覆蓋範圍改成類似「凡無所屬專題，及所屬專題已不活躍或廢除的條目，由本專題負責評級其品質」的定義（不包含重要度評等）。--S099001（留言） 2022年7月31日 (日) 06:59 (UTC)

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

近日Wikipedia:優良條目評選/提名區有編輯表示「Top（導言）整部分缺乏來源」，雖然大家長久以來都習慣不塞來源，但這畢竟是闖紅燈行為，所以敝人提議將Wikipedia:格式手冊/序言章節#列明來源設為方針，永絕後患。 --窝法乙烷 儿法梦碎 2022年7月29日 (五) 16:03 (UTC)

個人認為序言部分，經常有人「原創總結」，還有就是有些編輯習慣把新的內容加到序言，正文不加，導致序言不斷膨脹。這些風尚沒有改善，還是保有來源比較好。--Nostalgiacn（留言） 2022年7月30日 (六) 02:18 (UTC)

雖然這樣講有點過分，但大哥你原神角色條目一堆導言沒加來源耶。序言章節#列明來源寫說可以不在導言列來源不等於內文不用，文章講述「導言通常被寫成是比條目主體層次較淺的概述，而在序言章節中無爭議的東西看似是較少會被質疑的，繼而看似是較少機會被要求列明來源；不過這不是說序言可以例外地繞過參照要求。序言是否有必要列明來源應個別地、以編者共識來處理。複雜的、正在發生的、或有爭議的事項可能需要列明來源；其他的則列出少量甚或不用列出。這裡不要求也不禁止條目的序言作出參照，而需視不同狀況而定。」並沒有禁止列明來源，而閣下擔憂的序言膨脹不論此方針是否通過都沒差，因為這是人的問題，看看同樣防軍子不防小人的Wikipedia:列明来源。 --窝法乙烷 儿法梦碎 2022年7月30日 (六) 16:49 (UTC)

個人認為列明來源設為指引會比較合適。--飛馬🎠🎈 2022年7月30日 (六) 04:23 (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)

提議建立中小學條目指引

學校條目應涵蓋內容，迄今沒有一個標準，而這類條目又特別容易有受到破壞，或是加入宣傳內容。因此，提議建立Wikipedia:中小學條目指引規範學校條目內容，並參考了WikiProject:學校/條目指引、Draft:英文維基百科學校專題編寫建議（上述二者均譯自英文維基百科學校專題論述，分別經過主要編者修改，基本綜合了內容指引與格式指引的性質）與歷來討論，試擬草稿，懇請賜予意見。

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

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

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

建議避免填寫項目

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

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

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

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

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

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

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

人物

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

教職員、學生與校友 教職員、學生與校友，都應該只在人物本身就具備關注度，且有獨立第三方來源提及這位人士與學校的關係時，才被列入學校條目中。

建築與學校設施

建築與各項學校設施，除非是古蹟等特殊建築，或者在可靠來源中，有介紹該設施的敘述（單純提及建築／設施名稱，或除了建築／設施名稱外，只有建物樓層數、面積、建成日期等統計資料者，都不算），否則不應列出。

前述「建築」包含了校舍、運動場（含球場）、運動館等建物，「學校設施」指其附屬設施，例如校舍內的實驗室、專科教室、特別教室，還有建物旁的庭園。

在學校主條目中提到建築與各項學校設施，應當附上介紹，不要只羅列出各項建物的名稱，也不要除了名稱外，僅寫出建物樓層數、面積、建成日期等統計資料。

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

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

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

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

外部連結 學校條目中，請置放學校官方網站的連結，並使用{{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)