Wikipedia:互助客栈/方针

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:交通車輛條目指引。

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

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

鐵路車輛

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

客運/公車車輛^{[註 1]}

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

條目內容 不合適的內容

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

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

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

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

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

   依據：非原創研究

備註

1. ^ 此指大客車、巴士，不含小客車、計程車，小型車請參見汽車一節。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

鐵路1（讨论 | 貢獻） ：

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

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

鐵路1（讨论 | 貢獻）：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

鐵路1（讨论 | 貢獻） ：

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

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

     @Fran1001hk：

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

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

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

    @Fran1001hk：

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

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

      @Fran1001hk：

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

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

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

@Wpcpey：

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

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

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

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

@Wpcpey：

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

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

(＆)建議

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

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

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

@Wpcpey：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(＋)强烈支持。不过可能存在一些因铁路交通工具的本地特殊性而需微调行文架构的问题，大概也应属于可接受范围？-- ${\displaystyle {\ce {_29^64Cu}}}$ ${\displaystyle {\ce {->}}}$ ${\displaystyle {\ce {_{29}^{?}Cu}}}$  ${\displaystyle +}$  ${\displaystyle 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)

@

本主題全部或部分段落文字，已移動至Wikipedia talk:格式手册/虚构。执行人：Jimmy-bot（留言） 2022年6月24日 (五) 16:14 (UTC)。

提议修改

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:防滥用过滤器。

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

    不反对单独用户组。很多偶尔使用可以通过如

    本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:典范条目评选、Wikipedia talk:特色列表评选、Wikipedia talk:優良條目評選。

    已通过：

    通過。2022年7月1日及之後的提名，將適用新規則。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年6月23日 (四) 16:06 (UTC)

    下列討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。

    ---

    這裏再度重提Wikipedia talk:典范条目评选/档案9#有關優特內容評選規則計票方式及格式的統一化處理的提案，原因是使評選過程更為謹慎；另外也重新提議明確Wikipedia talk:典范条目评选/档案9#關於評選中「30天期限」和「不合要求而撤銷提名」的問題的決議，因為之前其他人不斷意圖推翻或使之無效化，但從來沒有這樣的共識。Sanmosa _{Χαίρε, ω χαίρε, Ελευθεριά!} 2022年5月31日 (二) 04:59 (UTC)

    請閣下總結一下上述提案之內容，公布於此，謝謝。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年5月31日 (二) 07:42 (UTC)

    前者在我給的連結已經顯示具體差異了，不另外給了。後者就是在“同一個條目請勿在距上一次……評選結束後不滿30天內重複提名，否則該提名視為無效”後加上一句“惟上一次評選由提名人於提名後48小時內撤回者不受此限”。Sanmosa _{Χαίρε, ω χαίρε, Ελευθεριά!} 2022年5月31日 (二) 09:18 (UTC)

    調整於2022年5月31日 (二) 12:45 (UTC)。Sanmosa _{Χαίρε, ω χαίρε, Ελευθεριά!} 2022年5月31日 (二) 12:45 (UTC)

    調整於2022年6月1日 (三) 03:55 (UTC)。Sanmosa _{Χαίρε, ω χαίρε, Ελευθεριά!} 2022年6月1日 (三) 03:55 (UTC)

    調整於2022年6月1日 (三) 14:50 (UTC)。Sanmosa _{Χαίρε, ω χαίρε, Ελευθεριά!} 2022年6月1日 (三) 14:50 (UTC)

    調整於2022年6月5日 (日) 16:03 (UTC)。Sanmosa _{Χαίρε, ω χαίρε, Ελευθεριά!} 2022年6月5日 (日) 16:03 (UTC)

    既有調整，調整在哪？--Ghren🐦🕒 2022年6月9日 (四) 07:41 (UTC)

    @Ghrenghren：直接改原留言，調整了一圈後改回舊版。Sanmosa _{Χαίρε, ω χαίρε, Ελευθεριά!} 2022年6月10日 (五) 02:05 (UTC)

    • "自行撤銷"條款是否只針對"自行提名"?--Temp3600（留言） 2022年5月31日 (二) 09:55 (UTC)
      • @Temp3600：我原本確實是這樣想的（已明確此點），還是你覺得其他人提名但主編撤回也能適用？我是沒意見的。Sanmosa _{Χαίρε, ω χαίρε, Ελευθεριά!} 2022年5月31日 (二) 12:45 (UTC)
        • 我覺得主編婉拒他人的提名也可以。另外贊同限制在評選期接近結束時退選的行為。--Temp3600（留言） 2022年6月1日 (三) 01:33 (UTC)
          •  完成。Sanmosa _{Χαίρε, ω χαίρε, Ελευθεριά!} 2022年6月1日 (三) 03:55 (UTC)
    • 關於引入2/3比例，我沒有異議。而至於30天的間隔，我認為應該要嚴格一點：提名開始n小時後自行提出撤銷者下次仍須等30天才可再次提名（n值建議是24至72小時之間的範圍），以免有提名人在投票最後階段看到明顯不可能通過的情況下，以自行撤銷提名的方法來規避30天的限制。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年5月31日 (二) 10:08 (UTC)
      • @Cdip150：那我取個折衷值吧，48小時如何？Sanmosa _{Χαίρε, ω χαίρε, Ελευθεριά!} 2022年5月31日 (二) 12:45 (UTC)
        • 也可。另外，如果因為違規而導致提名被強制撤銷（如明顯違反WP:GA?、WP:CV等）是否應該等30天？我個人覺得應該要。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年6月1日 (三) 03:55 (UTC)

          @Cdip150：這不是“撤回”的情況，所以不能走撤回條款，但真要討論這種情況能不能不受30日限制的話請另開新提案。Sanmosa _{Χαίρε, ω χαίρε, Ελευθεριά!} 2022年6月1日 (三) 03:58 (UTC)

    (可能有點離題)有關主編是否可以婉拒其他人提名一事。目前的優良，典範評選也包括重新評審在內，我認為主編可以婉拒他人提名，但不能拒絕他人的重新評審。--2001:B400:E256:CEEC:A375:FCA5:4D5E:146A（留言） 2022年6月1日 (三) 04:38 (UTC)

    沒有人能壟斷條目擁有權，所以除非像是新條目推薦候選之類的評審，否則我認為不應該考慮所謂「主編」的意願。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年6月1日 (三) 08:12 (UTC)

    留意到在《你的名字。》的一次GA評選中，以「成為優良條目後的版本 一定會加劇編輯戰的發生」為由提出刪除提名。撤銷提名的理由真的五花八門。--Nostalgiacn（留言） 2022年6月1日 (三) 10:55 (UTC)

    @Nostalgiacn：那我有點擔憂我主編的其中兩個FA了，按他的理解的話，我（與其他用戶）當時把那兩個條目抬上神壇，那兩個條目現在豈不是要永久全保護？^{[開玩笑的]}我自己是覺得：（1）真的過於離譜的提名與撤回操作（例如像一次性提出60+個重審請求這種）都該被禁止，但具體要怎樣畫綫我暫時沒想法。（2）要是真發生編輯戰，不管條目是不是優特條目都還是會發生（我看到AN3那邊就已經無言以對了），但寫好條目並讓它們選上優特的一個好處是管理員留意得快，穩定版本容易釐定與形成，條目質素在長遠而言不會受嚴重影響。Sanmosa _{Χαίρε, ω χαίρε, Ελευθεριά!} 2022年6月1日 (三) 14:47 (UTC)

    @Ericliu1912：我再處理了一下。Sanmosa _{Χαίρε, ω χαίρε, Ελευθεριά!} 2022年6月1日 (三) 14:50 (UTC)

    承Ericliu1912的意見，不同於DYK，GA/FA/FL從來就沒有「主編」這個概念，不然應該一早就有主編不可投票的規則，所以「條目主編（重審不適用）於提名人提名後」並不可行。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年6月5日 (日) 11:17 (UTC)

    我覺得其他用戶可能對此有不同的觀點，適宜另外討論。但既然沒人反對不包含條目主編要求撤回的情形的話，那我就只處理自行提名的部分了。Sanmosa _{Χαίρε, ω χαίρε, Ελευθεριά!} 2022年6月5日 (日) 16:03 (UTC)

    根據

    承上宣佈之公示，亦公示擬修改的條文如下：

    • 在Wikipedia:優良條目評選/header、Wikipedia:典範條目評選/規則、Wikipedia:特色列表評選/規則中：

    現行條文 ……結束後不滿30天內重複提名，否則該提名視為無效。

    提議條文 ……結束後不滿30天內重複提名，否則該提名視為無效，惟上一次評選由提名人於提名後48小時內撤回者不受此限。

    懇請大家細閱。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年6月14日 (二) 04:05 (UTC)

    • 不想陪獨裁社群瞎鬨，但要不要增加也不參與討論。這種作法顯然就是給人玩擦邊球的機會。同樣的提名人是不是可以連續重複提名再撤銷、提名再撤銷來湊編輯次數？--Z7504非常建議必要時多關注評選（留言） 2022年6月14日 (二) 05:41 (UTC)

      先不説這種情形會不會直接被封鎖處理，真的要“湊編輯次數”的人也不用這樣湊編輯次數吧？Sanmosa _{Gottes Sonne strahl' in Frieden} 2022年6月14日 (二) 10:03 (UTC)

      對自動確認使用者來說當然沒差，且或許對新用戶來說也不會這樣搞，但不無可能以後有人真的這樣搞。--Z7504非常建議必要時多關注評選（留言） 2022年6月14日 (二) 12:27 (UTC)

      再講一個，FL評選居然可以出現侵犯版權然後刪除的（

      先引回上次提案的明細：

      • 在Wikipedia:典範條目評選/規則中：

      現行條文 評選/重選期為兩週（14日）。評選/重選期結束後，如果絕對票有至少8票是符合典範條目標準（「符合典範條目標準」和「不符合典範條目標準」相互抵消，如12符合，4不符合，絕對票就是8），且不符合典範條目標準的票數應低於或等於總票數的三分之一（如19符合11不符合，雖然絕對票為8，但「不符合典範條目標準」的票數超過總票數30的三分之一，故不通過。另中立票不計入總票數，僅有參考意義），該條目就會入選為典範條目或維持典範條目狀態（如果已經是典範條目）。假如時效已過，未能達到票數要求，提名條目將從名單中刪除，列入存檔。

      提議條文 評選期為14日。評選期結束後絕對票有至少8票符合典範條目標準（「符合典範條目標準」和「不符合典範條目標準」相互抵消，如12符合，4不符合，絕對票就是8），且不符合典範條目標準票數低於或等於總票數三分之一（如16符合8不符合。另中立票不計入總票數，僅有參考意義），該列表就入選或維持典範條目（如果已經是典範條目）。如時效已過未達要求，提名條目從名單刪除並存檔。

      • 在Wikipedia:特色列表評選/規則中：

      現行條文 評選/重選期分兩階段，分別為基礎評選期（14日）及延長期（14日），如有效票數未達8票則進入下一評選期。如基礎評選期除提名者外無人投符合標準票，則不延長評選。任一評選期結束後絕對票有至少8票符合特色列表標準（「符合特色列表標準」和「不符合特色列表標準」相互抵消，如12符合，4不符合，絕對票就是8），且不符合特色列表標準票數低於或等於總票數三分之一（如16符合8不符合。另中立票不計入總票數，僅有參考意義），該列表就入選或維持特色列表（如果已經是特色列表）。如時效已過未達要求，提名條目從名單刪除並存檔。

      提議條文 評選/重選期分兩階段，分別為基礎評選期（14日）及延長期（14日），如有效票數未達8票則進入下一評選期。如基礎評選期除提名者外無人投符合特色列表標準票，則不延長評選。任一評選期結束後絕對票有至少8票符合特色列表標準（「符合特色列表標準」和「不符合特色列表標準」相互抵消，如12符合，4不符合，絕對票就是8），且不符合特色列表標準票數低於或等於總票數三分之一（如16符合8不符合。另中立票不計入總票數，僅有參考意義），該列表就入選或維持特色列表（如果已經是特色列表）。如時效已過未達要求，提名條目從名單刪除並存檔。

      • 在Wikipedia:優良條目評選/header中：

      現行條文 投票期為一周（7天）。在投票期結束後，如果有至少6個投票認為條目符合優良條目標準（包括提名人票。如有人認為不符合，1票不符合抵消1票符合），該條目就會入選為優良條目，或免於從優良條目除名。假如時效已過，未能達到票數要求，提名條目將從名單中刪除，列入檔案；重選條目將撤銷優良條目狀態。

      提議條文 評選期為7日。評選期結束後絕對票有至少6票符合優良條目標準（「符合優良條目標準」和「不符合優良條目標準」相互抵消，如8符合，2不符合，絕對票就是6），且不符合優良條目標準票數低於或等於總票數三分之一（如16符合8不符合。另中立票不計入總票數，僅有參考意義），該列表就入選或維持優良條目（如果已經是優良條目）。如時效已過未達要求，提名條目從名單刪除並存檔。

      • 在Wikipedia:特色圖片評選/header中：

      現行條文 特色圖片評選的評選/重選期分兩階段，分別為基礎評選期（14日）及評選延長期（基礎評選期＋14日），如參與投票的有效票數未能滿足以下條件則將進入下一評選期。滿足以下條件的圖片可以當選特色圖片： 候選圖片獲得8張或以上的「符合特色圖片標準」票；「不符合特色圖片標準」票與「符合特色圖片標準」票1:1抵消。如下例所示： 圖片甲得到了10張「符合特色圖片標準」，2張「不符合特色圖片標準」票。當選特色圖片。 圖片乙得到了8張「符合特色圖片標準」，2張「不符合特色圖片標準」票。落選特色圖片。 提名者及投票者皆須擁有自動確認用戶資格，即註冊達7天及編輯達50次，否則該提名或投票會被視為無效。 參選特色圖片前，需上傳至維基共享資源且在中文（zh）維基百科中至少1個條目被使用，而提名前須確保圖片沒有在維基共享資源中被提刪的疑慮，否則提名無效。 一個評選／重審完結後，應設一道至少1個月的「冷靜期」，才可（再）提交評選／重審。 如基礎評選期內除提名人外無任何投符合標準票者，則不進行評選延長期。

      提議條文 評選/重選期分兩階段，分別為基礎評選期（14日）及延長期（14日），如有效票數未達8票則進入下一評選期。如基礎評選期除提名者外無人投符合特色圖片標準票，則不延長評選。任一評選期結束後絕對票有至少8票符合特色圖片標準（「符合特色圖片標準」和「不符合特色圖片標準」相互抵消，如12符合，4不符合，絕對票就是8），且不符合特色圖片標準票數低於或等於總票數三分之一（如16符合8不符合。另中立票不計入總票數，僅有參考意義），該列表就入選或維持特色圖片（如果已經是特色圖片）。如時效已過未達要求，提名圖片從名單刪除並存檔。 提名者及投票者皆須擁有自動確認用戶資格，即註冊達7天及編輯達50次，否則該提名或投票會被視為無效。 參選特色圖片前，需上傳至維基共享資源且在中文（zh）維基百科中至少1個條目被使用，而提名前須確保圖片沒有在維基共享資源中被提刪的疑慮，否則提名無效。

      @Ericliu1912、Ghrenghren、Temp3600、Nostalgiacn：煩請確認您們對於GAC和FPC加入2/3比例計算的部份是否沒有異議？--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年6月14日 (二) 17:47 (UTC)

      (？)疑問@Sanmosa：特色圖片評選的一個月冷靜期的條文為何刪除了？--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年6月14日 (二) 17:48 (UTC)

      @Cdip150：補回吧，但順道把「1個月」改為「30日」，當時應該是我操作失誤了。Sanmosa _{Gottes Sonne strahl' in Frieden} 2022年6月15日 (三) 01:10 (UTC)

      (！)意見，這樣改會比直接在評選結果補回更好——在Wikipedia:特色圖片評選/header#提名方法中：

      現行條文 ……，以增加候選圖片的入選機會。

      提議條文 ……，以增加候選圖片的入選機會。 同一幀圖片請勿在距上一次特色圖片評選結束後不滿30天內重複提名，否則該提名視為無效，惟上一次評選由提名人於提名後48小時內撤回者不受此限。

      因為應該在提名時就要讓人知道冷靜期，而不是結案時才讓人知道。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年6月16日 (四) 04:26 (UTC)

      • 16符合8不符合是什麼意思?--Temp3600（留言） 2022年6月16日 (四) 05:25 (UTC)

        符合GA/FA/FL/FP標準票。

        @Cdip150：公示期已過，上面的所有提案應均為通過。如果沒甚麼大問題的話，定於7月1日開始實行如何？Sanmosa _{Királyunk s a közhazát} 2022年6月21日 (二) 06:14 (UTC)

        由於最後提出的改法是於6月16日，故應等到6月23日，如果屆時沒有異議才視為通過，適用於7月1日及之後的提名，6月30日及之前的提名則沿用舊規則計票。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年6月21日 (二) 08:26 (UTC)

        @Cdip150：無意見。我最近可能比較忙碌，到時可能要麻煩你代為處理。Sanmosa _{Királyunk s a közhazát} 2022年6月21日 (二) 09:20 (UTC)

        @Cdip150：到了現在也未有異議，還請代為處理。Sanmosa _{Királyunk s a közhazát} 2022年6月23日 (四) 08:57 (UTC)

        ---

        本討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。

    關於接下來的管理員投票

    本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:申请成为管理人员。

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

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

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

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

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

    本章節暫時不存檔。欲讓機器人存檔，請移除本模板。留言請置於本模板上方。

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

    本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:權限申請、Wikipedia talk:巡查豁免權。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    所以打從一開始就說這種權限就跟笑話沒有兩樣嘛，這個獨裁社群真的應該重新檢視是否要較嚴格的審慎檢查版權之問題，並非所有編輯者都會在編輯時注意到是否有侵犯版權之問題。--

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

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

    不需要站内方针和批准，但对站内共识和上述讨论会产生影响，所以放这边了。简单来说，如果事后“复查”相对有效，那么巡查豁免的批准门槛就无需很高，并有助于被豁免条目的改进和权限合理性。如果巡查豁免权被软件补丁拆分，更是如此。
    

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

    看分類內頁面如何排吧，預設為Unicode（基本符合部首順序），也有設為原文、漢語拼音、日語羅馬字……的，還有使用㏮等給分類內頁面分組的。--紺野夢人 2022年6月15日 (三) 12:21 (UTC)

    沒有共識，自然也就沒有辦法統一分類排序規則。Ericliu1912（留言） 2022年6月23日 (四) 02:24 (UTC)

    是不是除了港澳之外，目前都有在使用汉语拼音，感觉可以用汉语拼音排序。如果不能统一的话，感觉至少可以添加个汉语拼音排序小工具。现在按照部首排序，应该大多数人看不懂。--

    本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:小作品。

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

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

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

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

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

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

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

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

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

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

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

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

    小作品沒有字數上限。很長的條目(比如上面ACG所指欠缺現實內容的條目)，只要在關鍵主題內容上有缺失，就依然是小作品。--Temp3600（留言） 2022年6月16日 (四) 05:22 (UTC)

    真是好樣的，那以前獨裁社群怎麼都說是要看字數判斷的？--Z7504非常建議必要時多關注評選（留言） 2022年6月16日 (四) 06:20 (UTC)

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

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

    「字數標準缺乏共識」，看吧，同樣的道理，這種字數是否和「巡查豁免權的創建75個條目標準」都叫做刻板印象呢？--Z7504非常建議必要時多關注評選（留言） 2022年6月16日 (四) 17:47 (UTC)

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

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

    @QiuLiming1：難道上面Lopullinen所述的「小作品字數定義變成純粹數字」、「被機器人綁架」沒看到嗎？如果這個獨裁社群真的有想要廢除字數限制，那麼這個機器人也可以停止。但是很可惜的是這個獨裁社群並不想廢除小小作品的規定，小小作品和小作品都不應該有字數限制的才是，所以才說嘛這樣還說想要鼓勵新手寫條目？這獨裁社群都把規則訂死了啊。請問這個獨裁社群有無想過一個新手要熟練這些規定需要多久時間嗎？條目也都越來越難寫出新的了。--Z7504非常建議必要時多關注評選（留言） 2022年6月16日 (四) 15:42 (UTC)

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

    我更願稱這為規則的進步。顯然英維也不是第一天就想到這個定義的。--Temp3600（留言） 2022年6月16日 (四) 12:29 (UTC)

    • 這種討論是不會進步，也不太可能進步的。看了小作品和小小作品的爭議就知道這種東西根本沒有討論的必要，完完全全就是再次證明了這個獨裁社群的提刪標準不一而已。同樣的道理，日食（或者月食也好）是否具有一定關注度？會影響多少？--Z7504非常建議必要時多關注評選（留言） 2022年6月14日 (二) 17:43 (UTC)

      管理员

      本主題或以下段落文字，在討論結束後應存檔至Template talk:Bulletin。

      社群總是不願意主動更新Bulletin模板就已經是事實了，現在連搞個Bulletin存檔都那麼機車是不是呢？明明以前存檔都沒管那麼嚴格的阿。如果存檔要管的那麼嚴格，要不要用固定連結版本（比如這樣）比較能說服人呢？因為機器人最終還是會自動存檔變成失效連結，所以這個獨裁社群就是喜歡變成失效連結、毫無意義的存檔囉？說社群很獨裁真的剛好而已，這個什麼時候有方針過了？--Z7504非常建議必要時多關注評選（留言） 2022年6月15日 (三) 06:41 (UTC)

      ？？？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年6月15日 (三) 09:39 (UTC)

      還不明白在說什麼嗎？那就直接說了。存檔格式應該是用：

      1. {{bulletin/item|討論|互助客栈[[Wikipedia:互助客栈/技术|技术區]]正在討論'''[[Wikipedia:格式手册/链接|调整跨语言链接颜色以使其对视障人士友好]]'''，敬請踴躍參與。}}
      2. {{bulletin/item|討論|互助客栈[[Wikipedia:互助客栈/技术|技术區]]正在討論'''[[Wikipedia:互助客栈/技术#绿链的颜色不符合WCAG AAA标准|调整跨语言链接颜色以使其对视障人士友好]]'''，敬請踴躍參與。}}
      3. {{bulletin/item|討論|互助客栈[[Wikipedia:互助客栈/技术|技术區]]正在討論'''[[Special:diff/72149602#绿链的颜色不符合WCAG AAA标准|调整跨语言链接颜色以使其对视障人士友好]]'''，敬請踴躍參與。}}（提案應用固定連結的範例）

      以上3個的哪一個？不用紅色標記，根本都不知道在抱怨什麼就是了嘛，奇葩社群，有標記的部份先看看差在哪吧。什麼時候連搞個存檔都這麼嚴格了？所以對社群存檔的作法當然不滿意阿。--Z7504非常建議必要時多關注評選（留言） 2022年6月15日 (三) 13:35 (UTC)

      我當然不是不知道，只是覺得閣下有點憤世嫉俗了，最近火氣挺大。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年6月16日 (四) 02:26 (UTC)

      还不是因为大家懶吧。反正最後我也是搜索標題，實話沒大分別。--Ghren🐦🕙 2022年6月15日 (三) 14:52 (UTC)

      • 說實話，手工存檔是挺麻煩的。我自己改公告時也不太想搞。--Temp3600（留言） 2022年6月16日 (四) 05:08 (UTC)

        不是已經有小工具可協助處理了嘛。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年6月16日 (四) 06:00 (UTC)

        什麼小工具，又是什麼無中生有的新概念？總之上面終於有人承認這個獨裁、奇葩社群就是懶的更新。--Z7504非常建議必要時多關注評選（留言） 2022年6月16日 (四) 06:16 (UTC)

        在信口開河之前最好先做一些研究比較好。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年6月16日 (四) 14:34 (UTC)

        但也沒聽過誰發明出了機器人可以自動更改為固定連結？這個獨裁社群的技術如果沒有厲害成這樣的話還是別提了吧，反正主要是要問是否應該用固定連結版本存檔Bulletin模板的公告。--Z7504非常建議必要時多關注評選（留言） 2022年6月16日 (四) 15:37 (UTC)

        个人倾向第二个，自行翻找存档页面。第一种也要翻找该时期的页面历史，并且看不到讨论，如果编辑摘要未注明/未{{saveto}}将很难找。第三个可能更好，但也可能更坏（如diff版本已删除，选用的版本不合适，或者公告存档后追加的新留言），而且很麻烦。--YFdyh000（留言） 2022年6月16日 (四) 16:39 (UTC)

        如果哪天真的出現惡質的管理員把版本刪除那就是有無良心公佈事實的問題，在正常情形之下管理員隨意刪除連結版本是最沒有辦法說服人的，因為叫做隱瞞事實。還是獨裁社群的意思是指所有用戶都得自己去翻存檔？就說了嘛，什麼時候那個模板的存檔有方針了？--Z7504非常建議必要時多關注評選（留言） 2022年6月16日 (四) 17:43 (UTC)

        求一個小工具連接(pia!)--Temp3600（留言） 2022年6月16日 (四) 12:25 (UTC)

        （見上）——

        本主題全部或部分段落文字，已移動至Wikipedia:互助客栈/条目探讨#用戶「折毛」古羅斯條目文獻問題。执行人：Ericliu1912（留言） 2022年6月17日 (五) 07:58 (UTC)。

        建議修改音樂關注度規則

        本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:關注度 (音樂)。

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

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

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

        歡迎討論。--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)

        確定是鄰國效應不是文化環境嗎？照地理來看比起希臘，賽普勒斯還比較靠近土耳其，但現實是兩著一家親。回到中國，先不提自家人沒官方榜單也不信任那些商業平台，香港台灣乃至於新加坡等華語圈也有榜單，如果真的要靠拉低榜單標準來達成關注度，那還不如刪掉算了。 --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)

        已修改。--

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

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

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

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

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

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

        三个模板的效果见此。

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

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

        嚯，真聰明，找到我新號了（）
        話說要不要搞一個反向Switch[[Category:不接受完整删除通知]]來讓新用戶（可能是重開）接受短通知？--和每個人好好相處（留言） 2022年6月21日 (二) 11:43 (UTC)

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

        魔琴改Module:Template:Delete的補丁卡住了，應該是難以驗證補丁不會毀損別的東西--SunAfterRain 2022年6月21日 (二) 15:01 (UTC)

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

        (＋)支持，老用户一般不需要详细的帮助链接，而且罐头通知篇幅过长很影响讨论页观感。--

        本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:新聞動態、Wikipedia talk:新闻动态候选。

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

        烏克蘭身為冠軍卻不能主辦比賽，這四捨五入也算符合事项吧？ --Loving You Is A Losing Game 2022年6月22日 (三) 05:08 (UTC)

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

        KOKUYO把提案快速上ITN好像是有依据的：

        “	一、根据先前的讨论，ITN的流程是在任何时间点（无论是尚未更新或者已经更新），若出现两人有反对意见，需延长讨论时间以取得更明确共识（这时候若已经更新至ITN模板，就必须撤下来等待更明确的共识）。若没有出现上述情况，那么依照流程，等待至少8个小时时间后即可更新。因此，上述提问根本上就是完全无视先前讨论出来的运作流程，才会问的奇怪问题。在古巴新闻中，更新当时只有一人反对，一人提醒要有主条目，因此改善后即可更新。中国新闻中，更新当时只有一人反对，也不符和需延长讨论的情境。	”
        ——KOKUYO，Template_talk:Itn

        话是这样说，但是并非符合条件的都能快速上ITN（这就有点WP:GAME的味道了，只说可以没说一定要)，长期观察下来似乎还有个隱藏标准，那就是“KOKUYO提的案就能提前上”（可以统计看看）。--I'm an ARTIST, I'm a PERFORMANCE ARTIST. 250 OK: QUEUED AS 0 〈讨论〉 2022年6月22日 (三) 12:02 (UTC)

        顺带一提，WP:ITN只是个草案，具体标准可能还未成文（只存在于过往讨论中）。--I'm an ARTIST, I'm a PERFORMANCE ARTIST. 250 OK: QUEUED AS 0 〈讨论〉 2022年6月22日 (三) 12:20 (UTC)

        不建議假定惡意，謝謝合作--SunAfterRain 2022年6月22日 (三) 12:27 (UTC)

        我假设此情形其实不存在才会用“似乎”、“可能”。从我个人观察，暂得不出其他可能性，但出於假定善意不一口咬定。--I'm an ARTIST, I'm a PERFORMANCE ARTIST. 250 OK: QUEUED AS 0 〈讨论〉 2022年6月22日 (三) 12:33 (UTC)

        不過就是個新聞，請問一年是要吵幾次呢？與其來這看新聞怎麼不直接去看第四權的就好了呢？「某年某月某地」條目都已經存在爭議了，甚至也有出現要寫成「某年年鑑」的說法，也和新聞有關啊。--Z7504非常建議必要時多關注評選（留言） 2022年6月22日 (三) 15:34 (UTC)

        “不過就是個新聞”、“与其来这看新闻怎么不直接去看第四权的就好了呢”，那不然(×)删除Template:Itn好了。--I'm an ARTIST, I'm a PERFORMANCE ARTIST. 250 OK: QUEUED AS 0 〈讨论〉 2022年6月22日 (三) 15:41 (UTC)

        這樣講沒有錯啊，如果為了新聞吵成這樣，為何這個奇葩獨裁社群不敢提刪、不敢廢除Itn模板呢？--Z7504非常建議必要時多關注評選（留言） 2022年6月22日 (三) 17:02 (UTC)

        那你提刪吧！反正我是不干 。这玩意要有的话就应该把程序搞好，不要有的话就不要了，但要不要留我没意见--I'm an ARTIST, I'm a PERFORMANCE ARTIST. 250 OK: QUEUED AS 0 〈讨论〉 2022年6月22日 (三) 17:21 (UTC)

        現行條文 符合基本候选资格的新闻动态提案，应提交新闻动态候选区讨论。当候选区内有新闻动态提案时，新闻动态栏目更新周期一般为8小时，原则上不超过24小时。 新闻动态候选区中的支持与反对意见并非用以进行投票表决，而是用以表达个人想法，使管理员便于判断共识所在。 管理员在每次更新栏目时，应当查看新闻动态候选区内所有提案。管理员认为提案符合新闻动态候选标准的，应予采纳；不符合候选标准的，应由管理员陈述意见后退回重审。有二名及以上维基人提出反对意见的，亦应当退回重审。 被退回重审的新闻动态提案，应于候选区进一步讨论，对提案进行适当修改以获取共识；原则上，对提案的修改应于8小时内完成，最长不应超过24小时。提案修改完成后，管理员应根据讨论共识，宣布通过或再次退回提案。 新闻动态提案的讨论期原则上以5日为限。若提案在讨论期间内未能达成共识，以致于该提案新闻发生时间早于栏目内最早一条新闻时，提案即自动作废

        提議條文 符合基本候选资格的新闻动态提案，应提交新闻动态候选区讨论。当候选区内有新闻动态提案时，新闻动态栏目更新周期一般为8小时，原则上不超过24小时，支持票数多且已有共识者优先採用。 新闻动态候选区中的支持与反对意见并非用以进行投票表决，而是用以表达个人想法，使管理员便于判断共识所在。 已有共识的新闻动态提案才可更新至栏目，且至少要有一个淨支持票（即支持減去反对至少一票）。 管理员在每次更新栏目时，应当查看新闻动态候选区内所有提案。管理员认为提案符合新闻动态候选标准的，应予采纳；不符合候选标准的，应由管理员陈述意见后退回重审。有二名及以上维基人提出反对意见的，亦应当退回重审。 被退回重审的新闻动态提案，应于候选区进一步讨论，对提案进行适当修改以获取共识；原则上，对提案的修改应于8小时内完成，最长不应超过24小时。提案修改完成后，管理员应根据讨论共识，宣布通过或再次退回提案。 新闻动态提案的讨论期原则上以5日为限。若提案在讨论期间内未能达成共识，以致于该提案新闻发生时间早于栏目内最早一条新闻时，提案即自动作废 條目內文未更新不得進入新聞動態。

        估且把WP:ITNC里的获选标准算作是成文方针了。兩个新增条文都是为了防止管理员有意挑选自已想上的新闻先上，前一个避免关注度高的新闻动态提案不能先上。--I'm an ARTIST, I'm a PERFORMANCE ARTIST. 250 OK: QUEUED AS 0 〈讨论〉 2022年6月22日 (三) 16:10 (UTC)

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

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

        我就知道有人会提这个，但没想到是你“己有共识的新闻动态提案⋯⋯”，也就是说反对意见要先都获得解決，才开始点票。这只是设个最底门槛，不是要点票代替共识的意思。我之所以强调是淨票数，是为防止在有反对票的情況，因为有一个支持就硬上了。之所以要有这个门槛，原因我也说了。要有新闻动态的话，这个问题总要避免，不然你有更好的方法吗？--I'm an ARTIST, I'm a PERFORMANCE ARTIST. 250 OK: QUEUED AS 0 〈讨论〉 2022年6月23日 (四) 07:04 (UTC)

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

        在防止管理员有意挑选自已想上的新闻先上，并避免关注度高的新闻动态提案不能先上这一问题上，这已是我能提出最好的方案，你如果有更好的就提出来。或者你认为这不重要，那你也要明说为什么。--I'm an ARTIST, I'm a PERFORMANCE ARTIST. 250 OK: QUEUED AS 0 〈讨论〉 2022年6月24日 (五) 06:58 (UTC)

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

        現狀是新聞候選區有人反對且無人支持的情況下管理員硬要把新聞登上新聞動態，並且這一行為已招致他人不滿，所以不應讓這種狀況持續下去。

        還有我加上了「條目內文沒更新不要登上新聞動態」，更新條目更有意義，而條目上了新聞動態後過了幾天就會撤下了。--中文維基百科20021024（留言） 2022年6月23日 (四) 17:08 (UTC)

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

        坦白說啦，新聞動態的新聞根本不配稱上「即時」，總有可能事件都發生過後的兩三天才上首頁，原因就是出自社群挑新聞而導致內容完全不新鮮了。所以才說與其來這看新聞，怎麼不直接去看第四權的新聞就好了呢？--Z7504非常建議必要時多關注評選（留言） 2022年6月23日 (四) 17:05 (UTC)

        本站之新聞動態本來就不追求「即時」。我們又不是媒體，搶快做什麼。Ericliu1912（留言） 2022年6月23日 (四) 17:48 (UTC)

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

        我不清楚新闻动态存在的目的为何，但我认为这个栏目应该不是为了作为新闻报道提供即时讯息，而是为了让读者和编者快速找到近期在新闻中特別受关注的主题所对应的条目。也许“新闻动态”这个翻译有点毛病，不过我暂时也想不出合适的译名。--I'm an ARTIST, I'm a PERFORMANCE ARTIST. 250 OK: QUEUED AS 0 〈讨论〉 2022年6月24日 (五) 06:38 (UTC)

        如果沒這個欄目也沒什麼，也不靠維基百科獲取新聞資訊。--中文維基百科20021024（留言） 2022年6月24日 (五) 06:53 (UTC)

        还是那句话“这玩意要有的话就应该把程序搞好，不要有的话就不要了，但要不要留我没意见”。--I'm an ARTIST, I'm a PERFORMANCE ARTIST. 250 OK: QUEUED AS 0 〈讨论〉 2022年6月24日 (五) 07:08 (UTC)

        把草案中有爭议的部分挑出来，达成共识以后，只要无人刻意阻拦，草案应该很快就能提升为正式方针。--I'm an ARTIST, I'm a PERFORMANCE ARTIST.

        本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:有償編輯方針。

        現行條文 （就中文維基百科非現有條目而言）在草稿命名空間或其自身的用戶頁及／或子頁面內進行寫作，並且提請{{AFC submission}}，審核通過後才能夠正式成為條目；

        提議條文 （就中文維基百科非現有條目而言）在草稿命名空間或其自身的用戶頁及／或子頁面內進行寫作，並且提請{{AFC submission}}，審核通過後才能夠正式成為條目，可使用條目嚮導完成此流程；

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