维基百科:互助客栈 (全部)

本頁互助客棧 (全部)是供以方便瀏覽所有討論而特別設置。如果您想要新增討論內容，請在互助客棧中選擇最合適的版面。

按此刷新頁面。

		歡迎光臨互助客棧！
	互助客栈是維基人議事相助之處，用以討論消息、方针、技术以及编辑、求助等議題。 發表議題之前請搜索先前文章，遵守指導及禮儀。任何與維基百科無關的問題，请前往知识问答。
消息	方针	技术	求助	條目探討	其他
討論維基相關新聞與消息	討論方針與草案	解決或報告技術疑難	解決在維基百科中所遇疑難	條目、模板、主題相關探討	未符任何分區之議題
发表 | 监视	发表 | 监视	发表 | 监视	发表 | 监视	发表 | 监视	发表 | 监视
查看全部討論
帮助目录 · 提出疑问 · wikitext基础 · 常见问题 · 常见错误 · 布告板 · 了解术语 · 即时协助 · 規則简述 · 使用指南
维基百科社群 事务討論 方针提案 其他提案 协作讨论 提问 条目探讨 請求 专题 维护 部门 目录 帮助 规则 社群媒體 Discord IRC QQ Telegram 互联群 即時聯繫維基人 聚会
If you don't use Chinese, and want to contact Chinese Wikipedia, please leave your message here.

我想要……	请前往……
如何有效並安全地访问维基百科的方法	如何访问维基百科
与繁简处理有关的问题	字词转换
協助或尋求條目的改善意见	同行评审
对某些特定来源的讨论	可靠来源布告栏
寻找参考文献	文献传递
參與即時讨论或通过电子邮件进行讨论	「即時討論」或者「邮件列表」

---

消息

Wikidata weekly summary #425

Here's your quick overview of what has been happening around Wikidata over the last week.

• Discussions
  • Closed request for comments:
    • Integration of POTD template
  • Closed request for comments:
    • How to avoid to use male form as a generic form in property labels in French ? has been closed. Property labels in French should now includes both male and female or a verbal form if relevant (see P50).

• Events
  • Upcoming:
    • Next installment of the LD4 Wikibase Working Hour: Featuring speaker Barbara Fischer, Liaison Counsel at the German National Library’s Agency for Standardization (DNB). On behalf of the DNB, Fischer initiated the WikiLibrary Manifesto. Fischer works to increase the quality of metadata through Authority Control to foster retrieval and linked data. Where: Zoom (Registration link). When: 30 June 2022, 11AM-12PM Eastern US (Time zone converter)
    • Data Quality Days (July 8-10): you can propose discussion topics or sessions until June 19th.
    • Small wiki toolkits: Upcoming bots & scripts workshop on Thursday, June 30th, 16:00 UTC "This workshop will introduce participants to Toolforge, how to create a developer account, access to Toolforge via ssh, and run bots and scripts on Toolforge and in background mode."
    • (Tutorial) OpenRefine - A fundamental tool for every librarian's toolbox. Thursday 23 June - 17: 00-19: 30. Write to laz-corsiaib.it to book and receive the link of the event.
    • Wikidata:Wiki Mentor Africa 3rd edition - Creating tools on Wikimedia Toolforge using Python and Flask. Friday 24th June and Sunday 26th June 2022 - 16:00 - 17:00 (UTC)
    • Collect, archive and provide games - a "panel about video game metadata". Fri. 24.6.2022 – Sat. June 25, 2022
  • Ongoing:
    • Weekly Lexemes Challenge #47, Numbers (3/n)

• Press, articles, blog posts, videos
  • Blogs
    • Working With Wikidata and Wikimedia Commons: Poetry Pamphlets and Lotus Sutra Manuscripts
    • Using Wikidata Identifiers to Enhance Agent Discovery
  • Videos
    • Wikidata editing tools (in Spanish) - YouTube
    • Dagbani Wikipedia Saha Episode 6: Creating Wikidata items from scratch (in Dagbani) - YouTube
    • Fun with lexemes in some language! by Mahir256 - Twitch

• Tool of the week
  • Wikidata Card Game Generator: generate card games from Wikidata!

• Other Noteworthy Stuff
  • Job opening: UX Researcher - Wikidata at Wikimedia Deutschland
  • Wikimedia Deutschland welcomes new Wikibase.cloud Product Manager, Evelien Zandbergen
  • Developer Portal is launched! Discover Wikimedia’s technical areas and how to contribute
  • Starting on June 21, all Wikimedia wikis can use Wikidata Lexemes in Lua (discussions welcome on the project talk page)
  • Deutschland looking for a partner affiliate to organize the WikidataCon 2023

• Did you know?
  • Newest properties:
    • General datatypes: preceding halt on service, following station on service, number of housing units, last entry, homophone form, fastest laps
    • External identifiers: HaBama person ID, Shopee shop ID, Scottish Highland Bridges ID, Rusakters.ru ID, Proza.ru author ID, neftegaz.ru person ID, National Union Catalog ID, MAYA site company ID, Kino.mail.ru series ID, Kino.mail.ru person ID, Kino.mail.ru film ID, Ethereum token address, BelTA dossier ID, Talent Data Bank ID, IRIS UNIVAQ author ID, ARUd'A author ID, IRIS UNITE author ID, COR form ID, level 1, COR lemma ID, niveau 1, WorldCat Entities ID
  • New property proposals to review:
    • General datatypes: opus number, Palmares Cultural Foundation process number, U.S. vaccine status, theme, has narrative theme, Grammatical Person, title match pattern, Bartsch Nummer
    • External identifiers: Theatrical Index person ID, National Archives of Australia Entity ID, Mozilla Hacks author ID, CVX vaccine code, BVMC Corporate Body, ClimateCultures Directory ID, Korean Academy of Science and Technology member ID, Teresianum authority ID, GSAFD ID, Bioconductor project, MUSE book ID, Truth Social username, Telmore Musik, Beamish peerages database ID, Beamish peerages database person ID, gov.uk person ID, Komoot ID, Kieler Gelehrtenverzeichnis ID, Internet Sacred Text Archive ID
  • Query examples:
    • Islands with at least 1 spring or freshwater body (source)
    • Notable people who you share a birthday with (find the string "1966-08-25" and replace it with your date of birth) (source)
    • List of filmmakers with whom Jean-Louis Trintignant has played (source)
    • Cemeteries in France near churches (source)

• Development
  • Lexicographical data:
    • Enabled Lua access to Lexemes for all Wikimedia projects
    • Continued work on improving the language search for Lexeme languages on the new Special:NewLexeme page (phab:T307869)
    • Improving the accessibility of a design system component and the new Special:NewLexeme page (phab:T290733)
    • Making it easier to understand what to do when the spelling variant isn't available on the new Special:NewLexeme page (phab:T298146)
  • REST API: Continuing work on making it possible to add a statement to an Item

You can see all open tickets related to Wikidata here. If you want to help, you can also have a look at the tasks needing a volunteer.

• Monthly Tasks
  • Add labels, in your own language(s), for the new properties listed above.
  • Comment on property proposals: all open proposals
  • Contribute to a Showcase item.
  • Help translate or proofread the interface and documentation pages, in your own language!
  • Help merge identical items across Wikimedia projects.
  • Help write the next summary!

Read the full report · Unsubscribe · Mohammed Sadat (WMDE) 2022年6月20日 (一) 14:57 (UTC)

The Signpost: 26 June 2022

News, reports and features from the English Wikipedia's weekly journal about Wikipedia and Wikimedia

• News and notes: WMF inks new rules on government-ordered takedowns, blasts Russian feds' censor demands, spends big bucks

• In the media: Editor given three-year sentence, big RfA makes news, Guy Standing takes it sitting down

• Special report: "Wikipedia's independence" or "Wikimedia's pile of dosh"?

• Discussion report: MoS rules on CCP name mulled, XRV axe plea nulled, BLPPROD drafting bid pulled

• Opinion: Picture of the Day – how Adam plans to ru(i)n it

• Featured content: Articles on Scots' clash, Yank's tux, Austrian's action flick deemed brilliant prose

• Essay: RfA trend line haruspicy: fact or fancy?

• Recent research: Wikipedia versus academia (again), tables' "immortality" probed

• Serendipity: Was she really a Swiss lesbian automobile racer?

• News from the WMF: Wikimedia Enterprise signs first deals

• Traffic report: Top view counts for shows, movies, and celeb lawsuit that keeps on giving

• Gallery: Celebration of summer, winter

• Humour: Shortcuts, screwballers, Simon & Garfunkel

Read this Signpost in full · Single-page · Unsubscribe · Global message delivery 2022年6月26日 (日) 22:33 (UTC)

《維基百科政策簡報》2022年3月號

維 基 百 科 政 策 簡 報

— 每月一期，掌握政策脈動 —

過去一個月（2022年3月1日至2022年3月31日）內，中文維基百科之重要人事及政策變動大致如下，個別項目基本依變動或施行時間先後排序：

方針與指引重要變動：重大的方針與指引修訂。過去一個月內，互助客棧方針區共有方針與指引相關新提案28項，另有3項方針與指引相關提案獲得通過：

1. 《維基百科不是詞典》：以英文維基百科版本方針為基礎，重寫長年未更新之內容。（討論紀錄）
2. 《非原創研究方針》：澄清部分條文之表述。（討論紀錄）
3. 《人事任免投票資格方針》：刪除註冊滿七日始具人事任免投票資格之條件。（討論紀錄）

其他方針與指引雜項修訂，包括未於互助客棧方針區討論而進行之小修改、方針與指引之相應修訂或事實性修訂等。請核查此等修訂，若有需要，可提案至互助客棧方針區復議。

• 方針：《管理员方針》、《快速删除方针》、《维基百科不是什么》、《介面管理員方針》、《修訂版本刪除方針》、《保護方針》、《基金會行動方針》、《可供查證方針》、《有償編輯方針》、《条目所有权方針》、《监督方針》、《機械人方針》、《五大支柱》、《避免地域中心方針》及《命名常规》。
• 指引：《利益衝突指引》、《关注度指引》、《重定向指引》、《申请成为管理人员指引》、《不要伤害新手指引》、《消歧义指引》、《建设性意见指引》、《签名指引》、《勇于更新页面指引》、《剧透内容指引》、《格式手册（嵌入列表）》、《命名常规（音乐）》、《格式手册（虚构）》、《关注度指引（人物）》、《繁简处理指引》、《用戶頁指引》、《过度分类指引》及《格式手册（链接）》。

其他重要社群動態：此處列出的動態雖不一定與正式方針或指引有關，惟對維基百科之社群或站務運作有一定影響。

• 過去一個月內，共有1名維基人獲提名維基獎勵並通過：HenryXVII獲授傳記特別貢獻。

• 討論本期政策簡報
• 調整訂閱
• 歷年簡報存檔
• MediaWiki message delivery（留言） 2022年6月27日 (一) 06:19 (UTC)

Wikidata weekly summary #426

Here's your quick overview of what has been happening around Wikidata over the last week.

• Discussions
  • New requests for permissions/Bot:
    • William Avery Bot 7. Task/s: Merge multiple references on the same claim citing Accademia delle Scienze di Torino.

• Events
  • Upcoming:
    • The next Wikibase live session is 15:00 UTC on Thursday 30th June 2022 (17:00 Berlin time). What are you working on around Wikibase? You're welcome to come and share your project with the community.
    • Next Linked Data for Libraries LD4 Wikidata Affinity Group call June 28, 2022: Andrew McAllister will introduce us to Scribe, an app that provides keyboards for second-language learners, and its use of Wikidata. This presentation should appeal to anyone who has worked on or is interested in learning more about the applications of lexicographical data in Wikidata as well as anyone who has an interest in language, open information, data and programming. Agenda
    • Live editing session on Twitch, in French, by Vigneron, June 28 at 19:00 CEST (UTC+2)
    • 1 July: Abstract submission deadline for the Biodiversity Data Standards Conference TDWG 2022, including for a session on "The role of the Wikimedia ecosystem in linking biodiversity data"
    • July 8-10: Data Quality Days (see the first version of the program and the list of participants)
    • The Third Wikidata Workshop: Second Call for Papers. Papers due: Friday, 29 July 2022
    • Celtic Knot Conference 2022: presentations from 12 projects communities working on minoritized languages on the Wikimedia projects - YouTube
  • Past:
    • 21 June: Presentation Wikidata as a data collaboration across multiple boundaries at SciDataCon

• Press, articles, blog posts, videos
  • Papers
    • Connecting a French Dictionary from the Beginning of the 20th Century to Wikidata
    • Practices of Linked Open Data in Archaeology and Their Realisation in Wikidata
    • What Can Tweets and Knowledge Graphs Tell Us About Eating Disorders?
  • Videos
    • Dagbani Wikipedia Saha Episode 7: Adding references and qualifiers to Wikidata items (in Dagbanli) - YouTube
    • The Joys of Connecting Your Collections to Wikidata - YouTube
    • Using Wikidata to Enhance Discovery & Faculty Interest in Rapid Publishing - YouTube
  • Podcasts
    • Data Quality Days Discussion With Lydia Pintscher & Lèa Lacroix
  • Other
    • Documented queries: a proposal, feedback is welcome here

• Tool of the week
  • IsisCB Explore - is a research tool for the history of science whose books and subjects use imagery from Wikidata.

• Other Noteworthy Stuff
  • Template Item documentation now includes a query to the corresponding lexemes. This is an attempt to make navigation between lexemes and items easier. For the record, Item documentation is available in the header of the talk page for each item.

• Did you know?
  • Newest properties:
    • General datatypes: inker, penciller
    • External identifiers: Talent Data Bank ID, IRIS UNIVAQ author ID, ARUd'A author ID, IRIS UNITE author ID, COR form ID, level 1, COR lemma ID, niveau 1, WorldCat Entities ID, Great Plant Picks ID, BVMC organization ID, UK Beetles ID
  • New property proposals to review:
    • General datatypes: theme, has narrative theme, Grammatical Person, title match pattern, Bartsch Nummer, foliage type
    • External identifiers: GSAFD ID, Bioconductor project, MUSE book ID, Truth Social username, Telmore Musik, Beamish peerages database ID, Beamish peerages database person ID, gov.uk person ID, Komoot ID, Kieler Gelehrtenverzeichnis ID, Internet Sacred Text Archive ID, Copains d'avant ID, P. League+ ID, WO2 Thesaurus ID, Super Basketball League ID, DeSmog ID, Met Constituent ID, IRFA ID, Adequat agency person ID, Israeli Company Registration Number, UKAT term ID, TGbus game ID, TGbus franchise ID, Austria-Forum person ID, Catalogus Professorum (TU Berlin) person ID, Odnoklassniki group numeric ID, VocaDB Artist ID, VocaDB Album ID, VocaDB Song ID, Moepedia ID
  • Query examples:
    • "Queries of the week" archive (sources)
    • Graph of fictional wars and their participants (source)
    • The 100 most common species as subjects of publications known to Wikidata (source)
    • Map of birthplaces of ASM Clermont Auvergne players (source)

• Development
  • Lexicographical data: We are wrapping up the coding on the new Special:NewLexeme page. Testing and rolll-out will follow soon. We are still working on making it easier to find languages in the language selector on the Special:NewLexeme page. (phab:T307869)
  • REST API: We are continuing to code on the ability to create statements on an Item (phab:T306667)
  • Investigating an issue with labels not being shown after merges (phab:T309445)
  • Preparation for upcoming work: We are planning the next work on the Mismatch Finder to address feedback we have received so far as well as EntitySchemas to make them more integrated with other areas of Wikidata.

You can see all open tickets related to Wikidata here. If you want to help, you can also have a look at the tasks needing a volunteer.

• Monthly Tasks
  • Add labels, in your own language(s), for the new properties listed above.
  • Comment on property proposals: all open proposals
  • Contribute to a Showcase item.
  • Help translate or proofread the interface and documentation pages, in your own language!
  • Help merge identical items across Wikimedia projects.
  • Help write the next summary!

Read the full report · Unsubscribe · Mohammed Sadat (WMDE) 2022年6月27日 (一) 15:08 (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)

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

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

@Wpcpey：

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

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

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

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

@Wpcpey：

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

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

(＆)建議

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

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

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

@Wpcpey：

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

關於接下來的管理員投票

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

以前公開投票的時候有相互吵架的，對投反對票冷嘲熱諷的，還有我上面討論提到的有人投了反對票還會被人拉清單，就沒發現公開投票好在哪裡。--日期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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

豁免条目复审机制

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

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

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

• 社群應該再把上面已經提及過且很明確在FL評選中發生的侵權問題重新檢視才是，這種討論估計也得花上不少時間。然而居然已經至少4天都沒有動靜了，表示社群對於侵犯著作權實在太過於鬆散而不想嚴格實施嘛。是否跟一開始就講過「該權限就是笑話」符合呢？--Z7504非常建議必要時多關注評選（留言） 2022年6月20日 (一) 11:37 (UTC)

分类索引排序规则问题

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

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

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

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

关于日食小作品

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

建議修改音樂關注度規則

由於部份國家或地區歌曲／歌手大多只在當地的流行歌曲排行榜上榜，在現有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)

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

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

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

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

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

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

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

三个模板的效果见此。

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

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

更新：
1. Special:Diff/72389736：速刪理由模塊中，CSD加上<strong>標籤，SD通知完整預覽見此：Special:PermaLink/72391472。其實 Custom rationale 不應該用strong的，下次研究研究在哪改；
2. Special:Diff/72391444：VfD通知的clear:both;改成clear:left;（預覽無差別）
 ——魔琴 [ 留言 贡献 ] 2022年6月27日 (一) 16:58 (UTC)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

一開始竟然就隨便預設前提，我所講的流程本來就是幾年前經過互助客棧/方針討論並公示過後，我和時昭、以及其他管理員都應該遵循的規則，過往的存檔紀錄都可以證實此事。另外，如果您想要暗示「KOKUYO提的案就能提前上」是長期現象，也就是說我提的案通常能夠少於8小時就被處理，請去統計並證明，否則我認為這是惡意的暗示。--KOKUYO（留言） 2022年6月26日 (日) 07:58 (UTC)

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

所以現在就是先到處亂指控別人，反正到時候再說是猜想就好？為何您不乾脆地承認，您找不到我經常讓自己提出的案，經常少於8小時就登上ITN的首頁的事實。還是這是您故意的行為？--KOKUYO（留言） 2022年6月26日 (日) 08:46 (UTC)

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

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

現在是怎樣，一下暗示別人正在違反方針流程，一下又說自己沒有講過這些事情？是不是到時候就會說，如果我忙的時候，卻在某個剛好8個小時的時候沒有做更新，就是抵制某些新聞；然後我有空的時候一次更新，就是想要濫用權限。同時，我還不能對新聞提名感到疑惑，放著等其他人發表意見。反正所有的話都給您講就好了啊。--KOKUYO（留言） 2022年6月26日 (日) 09:14 (UTC)

早在2020年的時候，就已經把明確成文的部分早更新到頁面了，結果現在是您不知道這件事情？--KOKUYO（留言） 2022年6月26日 (日) 09:20 (UTC)

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

證明一個頁面哪些文字是方針指引，不是去找討論紀錄，難不成是靠您的感覺？--KOKUYO（留言） 2022年6月26日 (日) 09:37 (UTC)

另外，既然您的指控不是違反方針指引的，那就只是想要找一個近十年經常在ITN執行無聊行政的人，隨便湊湊紀錄羅織罪名而已。真的是很無聊。--KOKUYO（留言） 2022年6月26日 (日) 09:49 (UTC)

而且即便整理出我提案的處理時間真的比較短，老實說也不能代表什麼。我能處理ITN的時間，就代表只是剛好是生活中有空的環節。所以，提名是一個要花一段時間的有空環結（例如晚餐時間），更新是另一個要花一段時間的有空環結（例如早餐時間）。而那些沒有剛好在這個環節裡提名的案子，自然就得等到下一個有空環結去處理（例如在下午茶時間提名，因為晚餐時間還沒超過8小時，就等到早餐時間處理）。這還不包含生活要忙其他事情、或中間突然有空可以處理，或其他情況（空閒時間只夠處理一部分內容，其他內容得等下一環結、或交給其他人處理）。

所以您即便整理出了什麼跡象，老實講也不能證明什麼。當然，您也可以像很久之前，有一次我更新完新聞動態後，就去忙論文和其他自己想做的事情，沒有特別去管其他ITN更新。結果當時就被指控是要讓特意新聞登上首頁，如果您想要特意整理某些跡象再做出指控，誰也攔不住您；就像可以指控一個正在忙論文的管理員，他沒心情更新ITN是在霸佔ITN一樣。--KOKUYO（留言） 2022年6月26日 (日) 10:19 (UTC)

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

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

我始終遵守過往的討論共識，結果您利用沒意義的東西抹黑別人，然後再說必須去處理。這是您的興趣？--KOKUYO（留言） 2022年6月26日 (日) 10:37 (UTC)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

「有二名及以上維基人提出反對意見的」這個經過互助客棧討論並公告的內容，要怎麼把這句話看成「有一名及以上維基人提出反對意見的」，還麻煩提出一下。另外，一個人的反對能被稱做「共識」，是和誰達成共識？--KOKUYO（留言） 2022年6月26日 (日) 08:05 (UTC)

KOKUYO最近就強行讓2票傾向反對、無人支持的新聞強行上首頁。雖然不是破壞，但是吃相不太好。--中文維基百科20021024（留言） 2022年6月26日 (日) 02:39 (UTC)

請明確指出哪一個是有兩張反對票（而且反對票是不可解決之問題），然後被登上首頁的情況？尤其是當其他人只是反對個別提出的意見、而沒有反對整個提案的時候，結果您卻無法看出來是這個意思的時候。--KOKUYO（留言） 2022年6月26日 (日) 08:03 (UTC)

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

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

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

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

Liu116雖然沒有直接(－)反对但是很明顯可以看得出他是不支持刊登，甚至在你硬要刊登後別人還發了句小牢騷。--中文維基百科20021024（留言） 2022年6月26日 (日) 08:20 (UTC)

在我看來，那個就只是意見表達，不是反對更新至ITN的意見（不然他就會直接加入反對模板了）。關於後半部分，他為何會覺得至少從2012年登上ITN的歐洲歌唱大賽叫做「近幾年」，這我就不知道了。--KOKUYO（留言） 2022年6月26日 (日) 08:35 (UTC)

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

如果真的誤解意思，其實真的是因為重要性問題不想要讓這個新聞不想要上，那下次就麻煩明確地一點使用反對模板，然後管理員們會判斷這個意見情況（是覺得整個新聞不能上，或者是某些問題處理修正即可），就能減少這裡面的誤會。--KOKUYO（留言） 2022年6月26日 (日) 08:53 (UTC)

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

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

新聞動態那邊有點有趣，KOKUYO提名的幾個新聞一堆人反對，而「美國墮胎不再受憲法保護」一堆人投支持票的情況下KOKUYO投了反對票並且認為「不重要」 。--中文維基百科20021024（留言） 2022年6月26日 (日) 06:24 (UTC)

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

如果連「反對：加入槍枝法案。（加入槍枝法案）那是另外一件事情，而且（加入槍枝法案）目前看來沒有值得登上ITN的關注度和重要性。」這句話都看不懂，還得要貼心地去標記才行，那我沒其他意見；反正其他管理員看得懂就好。--KOKUYO（留言） 2022年6月26日 (日) 07:49 (UTC)

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

我幹嘛縮排，從所有語句順序根本就沒必要再多做處理，我只要這要這樣就能表達意見不應加入槍枝的意見了。如果您沒有辦法看懂別人的意見，就不要亂惡意指控，這只是讓人很不舒服。--KOKUYO（留言） 2022年6月26日 (日) 08:08 (UTC)

上面那位解釋很到位啊，你是沒義務一定要縮排，但這種排版和表述確實容易讓人誤解。--中文維基百科20021024（留言） 2022年6月26日 (日) 08:15 (UTC)

只要母語是中文的應該都不會理解成是這樣吧，那不然為什麼「要提那是另外一件事情」？在討論A新聞是否有登上ITN的意見中，反而提到「A新聞是另外一件事情」？這個邏輯是？--KOKUYO（留言） 2022年6月26日 (日) 08:27 (UTC)

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

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

我發現許多人不清楚前因後果的情況，就開始直接發表意見，甚至還有人在明知道錯誤的情況下，繼續在這邊混淆社群的判斷。首先，我過去提到的處理流程，是在2020年的時候，經過互助客棧/方針討論，以及標準的公告流程所創建的，自然就就是如同方針指引方要遵照執行，也就是我和時昭所遵循的。這個執行流程是假定所有的提名在經過8個小時等待意見期之後，就可已認定有共識可以登上ITN。相反地，在任何時間「有二名及以上維基人提出反對意見」時，應當去延長討論時間、或者是從模板上退回重審。--KOKUYO（留言） 2022年6月26日 (日) 08:21 (UTC)

因此基於前述ITN的更新流程，對於目前提到的幾個意見，大概是回應如下：

• 「支持票數多且已有共識者優先採用」：非常不建議。目前ITN共有四則新聞擺放位置，每則新聞會擺放至少放1天時間（曾經有人提出此建議）。依此規則，假若有1、2則新聞被提前更新，後續更新新聞的空間大幅壓縮，甚至幾則新聞會在不足1天的時間換下。在新聞動態不講求時間效率之下，沒有必要要提前更新（反正都一定會更新到，且都能夠保留至少1天時間）。
• 「已有共識的新聞動態提案才可更新至欄目，且至少要有一個淨支持票（即支持減去反對至少一票）」：非常不建議。如同時昭所言，「不是每次都有票可點」。同時，過度強化「第一張反對票」的效力，只要用任何理由（例如「我覺得不重要」、「我不喜歡」），就必須得要出現兩張票。甚至，這種規定可能會想把ITN候選變質成惡性投票、報復處，今天您投我反對票，明天我投您反對票。另外，假如第二點的效力還包含只要違反此要件者，就會被視為不符合此要件而必須撤下ITN的話，那麼將有更大機會製造行政流程的混亂。相反地，現行規定要求出現相對明確的反對共識（至少2人的反對意見）後，在不同時候都得拉入更長時間的討論。
• 「條目內文未更新不得進入新聞動態。」：目前沒有想到會產生的問題。我自己都會做這樣，只是現階段不會強求別人的。--KOKUYO（留言） 2022年6月26日 (日) 11:02 (UTC)

然後對於幾個提案者的無端的指控，我也一併回應：

• 「管理員有意挑選自已想上的新聞先上」：就我的部分，答案是沒有。就依照順序，從時間久的開始一個個處理，有兩張反對票的就擱置更長的討論。我相信時昭也是如此。至於他似乎現在想要從一些紀錄上，硬是要聲稱存在這件事情。那麼，我只能說這就像因為我沒心情去更新ITN，然後其他管理員也沒有更新，就來指控我有意讓某些新聞登上首頁一樣無聊。
• 「關注度高的新聞動態提案不能先上」：第一，已經有多人指出新聞動態不強求時間即時性，只要沒有進入要延長討論的環結，早更新與晚更新都是會登上首頁；第二，提前更新只會響讓慢一點被注意到而提名的重要新聞更容易失去登上首頁的機會，特別是如果還要確保每則新聞都至少能登上首頁1天的時間。
• 「至少有一個門檻」：我認為現在的規定是主動去相信，所有提名者提出的新聞動態內容，無論大小，都已經經過自身判斷後足以可以登上首頁。因此，雖然門檻只是設定成在8個小時不要有2張反對票，但很明確是有一個門檻存在，且這個門檻是可以隨時達成並生效（即便已經更新至ITN了，不符合此門檻而得到2個反對意見的話，便應依照規定重新撤回），而不是某些人無端指控的「沒有門檻」。
• 「給定一個機械化的排序依據」：現在的處理方式就是照時間順序，一個個依照事件發生先後處理提案，無論是我、還是時昭都是如此。反之，「優先採用」這一點才是破壞「機械化的排序依據」，是自相矛盾的說法。--KOKUYO（留言） 2022年6月26日 (日) 11:27 (UTC)

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

您提的東西要麼就是多餘的，影響處理流程，甚至與自己論點自相矛盾的；要麼就是無法解決問題，破壞原先的共識運作機制（在有相對明確反對共識下，延長討論時間，以讓提名獲得更廣泛的共識），甚至是顯示出將讓ITN候選出現相互投反對票報復的情況，為此自然是有必要在討論反對您的部分。--KOKUYO（留言） 2022年6月26日 (日) 12:09 (UTC)

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

那時候的所有參與討論的人都知道要照時間順序處理，這就是一種常識的做法；同時，也知道管理員可能認為需要更多時間判斷，而會給予更多時間來讓共識更為明確。所以我不知道您想要反對什麼，除非您是認為，在一堆提名之中，管理員不照時間順序，挑選自已想上的新聞先上比較好；但如果這是您的意思的話，就和您前面講的完全相反。

另外，我都不知道原來現在維基百科的機器人已經能夠看懂人類語句，知道哪些情況是可以解決的問題，哪些情況是要等待更多意見，還是您已經默默開發出這個機器人了，只是我還不知道嗎？--KOKUYO（留言） 2022年6月26日 (日) 13:06 (UTC)

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

我明明已經提到，現行規則是在沒有兩人以上的反對（或是解決反對意見的情況下），可以更新ITN。而這樣的操作方式是有先行討論提供共識基礎的，且這樣的討論是因為我們相信每個人都能夠裡性判斷，同時也留了時間讓其他人可以對此進行覆核。所以我完全不知道您前面的根據在哪裡，難不成機器人能夠處理反對意見的差異？這又是因為您開發出了那個機器人，又或者只是猜想這個流程是長怎麼樣子？--KOKUYO（留言） 2022年6月26日 (日) 13:33 (UTC)

還有啊，您一直說「管理員有意挑選自已想上的新聞先上」，那麼您又是指哪一個案例呢？您連整個案例細節長怎樣都不提，就開始說有問題存在，這又要怎麼討論呢？--KOKUYO（留言） 2022年6月26日 (日) 13:39 (UTC)

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

這整套流程照規定做下來，請問又要如何讓「管理員有意挑選自已想上的新聞先上」？請實際說明您所設想會發生的情境，並提出來討論，不然是浪費大家的精力。--KOKUYO（留言） 2022年6月26日 (日) 14:13 (UTC)

還是您根本連問題實際長怎樣都不知道，就直接跳下來跑來討論？就像全世界都知道要解決貧窮問題，但是別人問說您想解決哪一個地方的貧窮問題，然後就一直說「就是貧窮問題」。--KOKUYO（留言） 2022年6月26日 (日) 14:16 (UTC)

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

1. 中文維基百科的方法與英語維基百科有顯著不同，整體社群運作及參與程度都不一樣，拿其他語言維基百科的內容當參考還行，但是無視現實情況直接套用明顯就是有問題。
2. 如果在多則新聞之中，比較後面時間的新聞先上，有可能是因為該管理員覺得真的相當重要，又或者前面幾則提名需要更長時間以產生更明確的共識判斷，請問要如何用僵化的文字去說明？
3. 我不知道您為何不斷片面地擷取片面的文字，而無視整體的運作，這樣的意義是要幹嘛？現行規則是在沒有得到兩人反對意見下，即可視為初步具有共識而更新至ITN，並可以因不同情況（例如得到兩名反對意見）延長時間以得到更明確共識。同時諷刺地，您們一方面表示沒有計算到未使用反對模板之意見，現在卻又說可以使用機器人，而無視機器人指能讀取反對模板的存在。有想過意見連貫性嗎？
4. 您拿一個有被掛上刪除模板的新聞提名，需要時間處理條目上的刪除模板的問題，結果用在現在去做一些指控別人的猜想？這是認真的嗎？還是從頭到尾就把討論當成遊戲？那您現在都有既有的成見和想要達成的結論了，真的能夠準確看出當時為何這樣決定更新，還是只是一樣拿來當成指控別人的工具（例如看到時間好像真比其他提名長幾個小時，就開始嚷嚷著這是濫權，卻完全無視其他人有自己的生活規律）？--KOKUYO（留言） 2022年6月26日 (日) 16:52 (UTC)

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

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

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

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

   如果點擊新聞動態的條目，發現條目內並沒有新聞動態顯示的內容，感覺很怪，甚至有一種被欺騙的感覺。雖然最近大部分都更新後再上新聞動態，但以前遇到過幾回。--中文維基百科20021024（留言） 2022年6月27日 (一) 02:59 (UTC)

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

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

   所以，一票反對票就能叫做有擱置更新的共識？為何不去看當初討論是怎麼討論的、或這個有經過互助客棧討論的流程是寫什麼，且去思考現在的運作情況是怎樣？那是不是下一個人就要覺得，要像DYK那樣4張支持票、互助客棧至少3人參與討論、優良條目至少6張支持票，或者像管理員選舉一樣的做法，才叫做達成共識？--KOKUYO（留言） 2022年6月27日 (一) 07:46 (UTC)

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

   第一，您表面上說要依照方針要求更高程度的流程（也就是上面提到的互助客棧流程），但是又不考慮互助客棧流程的做法，實際上只不過是隨自己地任意設定門檻。假設要遵照互助客棧討論非方針指引事項的層級，方針已經明確提到，只有提案人以外的3人同意、且無人反對的情況下，才可以在等待3天之後直接執行。很明顯的，要麼您引用的流程明顯無法適用新聞動態候選，要麼就是您曲解了方針的內容，不過是隨自己心意解釋（我甚至還沒有提到公示7天的制定方針指引作法）。第二，也不需要所有地方的討論都得要遵照互助客棧的運作方式，而可以視自身的運作特性處理，所以一昧地只是拿別的地方的方式去建議、而無視沒有執行性的觀點，明顯是不可行的。第三，方針也已經明確提到，「沒有異議或不被其他編者回退的編輯，均可假定其具備共識」，因此宣稱既有作法是錯誤的，不過就是片面地解讀方針。--KOKUYO（留言） 2022年6月27日 (一) 09:25 (UTC)

   所以沒有任何支持票和反對票的提案，自然默認可以執行更新動作的共識。只有一張反對票或意見的提案，則尚未形成要延長討論時間的共識，則應繼續更新。假若有增加至兩位反對意見，應撤回延長討論。--KOKUYO（留言） 2022年6月27日 (一) 09:31 (UTC)

   另外，我與時昭所提到的流程是明確經過互助客棧的方針制定程序討論、公告7天的內容，所有參與的人也都知道在維基百科上的方針指引規定。換言之，現在講的流程具有方針指引的地位，只是因為頁面不需要特別掛上模板，故根本不存在您所謂的「優先級與約束力」問題（甚至您所引用的那一句，是針對在專題、討論頁的討論共識，而不是針對在互助客棧/方針依照制定程序提案並社群廣泛討論的條文）。我不覺得隨便拿一個別處的方針指引，片面引用部分片段和解讀後，就要所有人依照那個片面解讀走，這樣的做法是適宜的。--KOKUYO（留言） 2022年6月27日 (一) 09:53 (UTC)

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

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

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

維護模板這件事情根本不可行，反而是要讓管理員還要多承擔審查條目質量的工作，且更容易遭到無理的攻擊。我真的是希望大家是可以全盤地設想運作時候會發生什麼事情，而不是只是因為感覺好像都是對的，就題提出根本無法執行的意見。--KOKUYO（留言） 2022年6月27日 (一) 09:06 (UTC)

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

在從上面得知您不理解新聞動態候選運作，及說要考慮互助客棧模式卻又不知道該模式如何執行的情況下，增加一個讓您往後可以繼續操作的文字、製造後續的爭論，沒有必要吧？--KOKUYO（留言） 2022年6月27日 (一) 09:35 (UTC)

然後前面已經講了，現在中文維基百科的運作模式明明就和英語為基百科存在差異，結果還一直要浪費時間推WP:ITN（而且還一堆人不知道過往討論，甚至連哪些地方不可行都不知道），我真的不知道您們何不把時間弄在更有意義的地方，例如寫條目、作站外推廣什麼的？--KOKUYO（留言） 2022年6月27日 (一) 09:37 (UTC)

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

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

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

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

再次提议设立ITN方针

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

以前討論的流程明明就都是經過討論、公示並成文列出，現在卻還一直說是不成文？這樣不斷散播錯誤資訊的言論（可以從討論紀錄、編輯紀錄證實整個流程設立成文的過程，就能知道相關言論為錯誤資訊），社群是不是應該要考慮處理一下？--KOKUYO（留言） 2022年6月27日 (一) 11:21 (UTC)

同時，社群可以注意到此用戶經常片面擷取他人文字，並去脈絡使用的情形。例如，當我陳述最早相關文字大概是2012年或2013年左右由我翻譯、並提供其他人作為論述參考的歷史事實，卻在這邊與其他地方被該用戶去脈絡利用，藉此聲稱我的意見是在否定2020年在互助客棧依照方針制定程序建立的更新流程，進而塑造ITN新聞更新流程沒有明文規定、管理員濫用權限的錯誤形象。如此藉由片面擷取他人言論進行操作、並經說明後還持續未有改善，已經延續了好幾年的時間了。--KOKUYO（留言） 2022年6月27日 (一) 11:39 (UTC)

對於管理員能否提名、並依照更新流程同一人更新，當初在互助客棧的討論中就已經明確指出，該制度設計就是允許管理員A提名、A結案。--KOKUYO（留言） 2022年6月27日 (一) 12:10 (UTC)

講「避嫌」其實也就是個大笑話罷了，誰會知道到底有無「避嫌」？這種東西不論是誰提名都肯定是管理員去結案的嘛。不然ITN模板是有要開放給一般用戶修改嗎？如果沒有，再怎麼樣討論所謂方針也沒屁用，永遠無法改變是否有「避嫌」的問題。--Z7504非常建議必要時多關注評選（留言） 2022年6月28日 (二) 14:13 (UTC)

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

又開始在此處片面擷取他人文字利用，不肯承認自己的錯誤，甚至模糊時間發展。在2020年以前，新聞動態更新就是依照慣例去執行，其中包括延續長期以來管理員直接更新新聞動態的做法、及由我等人在2012年提議讓其他用戶也可以提供更新建議，也就是以雙軌制方式進行。在2020年後，社群制定出現行現行更新流程，確立所有更新都得要經過候選頁面的討論，也討論到此制度設計就是允許管理員A提名、A結案，並獲得方針制定流程討論通過。這項關於新聞動態更新流程的討論依照標準的方針指引制定流程進行，為最新且最高級別的方針指引共識。然而，特定用戶試圖藉由更早以前的討論內容（甚至只是討論，而不是經過標準流程確立的共識），隨便否定、取消這項最高層級並得到廣泛認同的共識。同時，在中文維基百科發展中，新聞動態從管理員直接更新制、管理員直接更新與一般用戶提出建議後更新的雙軌制、到新聞動態候選頁面單軌制這件事情，都是現有紀錄能查得到的內容。結果大家可以見到，特定用戶執意拿過往不同時間的討論去混淆社群視聽，無視在中文維基百科長期的發展中，新聞動態的運作與規則已經有數次變化，甚至如我前面提到持續片面擷取社群的文字、去脈絡詮釋，只為了達成自己的想要達成的目的。--KOKUYO（留言） 2022年6月28日 (二) 15:39 (UTC)

同時，大家在2012年的討論之中也可以見到，最初有關新聞更新規範的內容，就是由我參考英語維基百科翻譯過來，作為除了管理員直接更新這種長期以來的做法之外，讓一般用戶也能夠參與新聞動態運作的補充途徑。在這討論過程，也有其他人有對於該參考內容的可行性不同建議，但是因為只是參考實驗用的論述，所以先試試看該補充新制度。因此在當時，可以見到我和幾位用戶在扮演的是提出一種實驗做法，補充只由管理員更新新聞動態的方式（而不是取代之），因此我完全不知道特定用戶想要用2012年的這場討論，指控我做了什麼？難不成是又要錯誤地提出指控，說是因為我對新聞動態的更新，引發其他用戶反對，為了安撫大家才創建候選頁面？--KOKUYO（留言） 2022年6月28日 (二) 16:03 (UTC)

修改WP:PAID/ALT

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

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

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

寫一份面向新手的指南比起微調方針好，無論怎麼微調方針，幾乎不適合直接讓新手閱讀。--Xiplus#Talk 2022年6月25日 (六) 13:51 (UTC)

修改 uw-ublock 系列模板样式

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

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

技術

偽綠鏈二三事

1. 追蹤偽綠鏈並將這類條目歸入Category:有蓝链却未移除内部链接助手模板的页面的程式碼有待完善。照分類紀錄Special:Diff/71332757這次編輯就已經把該模板從分類中移除，但逐筆比對後可發現仍有「{{link-en|索马里兰银行|Bank of Somaliland}}」（實際連結到索馬利蘭銀行，條目建立於2022年3月28日）、「{{link-en|斯里兰卡中央银行|Central Bank of Sri Lanka}}」（實際連結到斯里蘭卡中央銀行，條目建立於2022年4月9日）。由此可知追蹤程式碼可能無法處理繁簡、地區詞等問題，希望可以修復，也提醒User:Comrade John清理時留意。
2. 目前User:Cewbot僅清理Category:有蓝链却未移除内部链接助手模板的页面中的條目命名空間、模板、Category 或 Wikipedia，但有部分偽綠鏈存在於Portal空間如Portal:東南亞]、User talk空間如User talk:221.9.13.45/存檔、WT空間如Wikipedia talk:並不是所有頁面都需要標籤難以人力處理窮盡，希望可建立「讓Cewbot請理所有空間」的共識，謝謝，也副知User:Kanashimi。--迴廊彼端（留言） 2022年4月27日 (三) 11:55 (UTC)
3. 又希望建立共識加快Cewbot的清理速度。Category:有蓝链却未移除内部链接助手模板的页面近期的數字大致上在15500-14800之間浮動，但User:Cewbot/需要修正的跨語言連結近期的數字是14000以下，Cewbot每週了不起完全清理100多條，差距其實挺大。--迴廊彼端（留言） 2022年4月29日 (五) 17:17 (UTC)

1. 我只在乎Category:有蓝链却未移除内部链接助手模板的页面消失與否。閣下所指的問題，我已知悉一段時間，但這並非我能夠獨自處理，而且逐筆比對費時失事，所以我對偽綠鏈，找到的就改，找不到的就算。
2. 其實Cewbot要提升它的編輯頻率，很懷念上年Category:有蓝链却未移除内部链接助手模板的页面短短幾天，由30000多個頁面，清至10000多個頁面呢。-- 約翰同志－條目裱糊匠（留言） 2022年4月27日 (三) 12:07 (UTC)

   其實能處理的大概都處理完了。您可以參照使用者:Cewbot/需要修正的跨語言連結，現在留下來的大概都是需要人工判別的。--Kanashimi（留言） 2022年4月27日 (三) 21:19 (UTC)

謝謝User:Comrade John、User:Kanashimi兩位辛苦，我會提出上述方案就是希望Cewbot清理簡單、但沒人注意到的偽綠鏈，讓有志者可以專心處理使用者:Cewbot/需要修正的跨語言連結，裡面問題真的太多。我目前找到的清法是把該頁面紀錄的原文人名、媒體名等專有名詞做重定向，像是Los Angeles Daily News、亚马逊MP3這類的讓機器人去跑，前陣子認真做的時候算蠻有成效，每週可以清一百多個。不過另一方面真的建議Cewbot加快速度，像凌晨一點到六點這種伺服器理應比較空閒的時段（如果我講錯請指正我），也常看到Cewbot除更新討論列表外只清了五、六筆偽綠鏈。--迴廊彼端（留言） 2022年4月29日 (五) 17:17 (UTC)

歸納一下討論狀況，目前我跟User:Comrade John都認為Cewbot應加快清理速度，請問一下Comrade John那邊有建議速率嗎？此外我昨天修了一筆將近兩年都沒被Cewbot修復的偽綠鏈（井上和香這個條目建立於2019年5月），這個效率真的是有點不妙。--迴廊彼端（留言） 2022年5月9日 (一) 17:40 (UTC)

速率吧.....它的速率其實沒有問題，而是頻率的問題，Cewbot每星期才清理偽藍鏈一次，可以說那一次所清理的數量，遠遠不及一星期所增加的偽藍鏈數量，最好是每日一次。確實，維基百科:不要搶機械人的工作，但前提是它們完全能夠獨自清理某些工作吧。-- 約翰同志－條目裱糊匠（留言） 2022年5月9日 (一) 18:26 (UTC)

我觀察了好一段時間，目前Cewbot幾乎每天都會清，只是清的份量多少而已，所以我傾向認為是速率問題。--迴廊彼端（留言） 2022年5月19日 (四) 16:28 (UTC)

速度的問題，主要是因為每一筆連結都要查詢各項資料以做確認，並且真正能改的不多。所以雖然一直在跑，卻大多改不了。依照當初的討論，能改的連結有限制，例如新文章必須過一禮拜才能當作穩定，您可參考原始碼。或許您可以提供一些應該能讓機器人自動更改，不必列在問題頁面的例子？--Kanashimi（留言） 2022年5月19日 (四) 22:38 (UTC

關於使用者:Cewbot/需要修正的跨語言連結目前我沒想法，謝謝辛苦。速度部分也謝謝您的解說，不過有些偽綠鏈毫無問題也被擱置了半年，您之前清完快取再運行機器人後我仍找到擱置兩年的偽綠鏈Special:Diff/55339541/71554938，這難免讓我好奇有沒有提升清理效能的方法，例如提升機器人整體運行速度、避免機器人總是在特定條目打轉之類的。--迴廊彼端（留言） 2022年6月4日 (六) 13:33 (UTC)

@迴廊彼端 您在發現有些模板能改卻一直放著沒改時，或許能告知這邊一下，以利逐筆檢查。謝謝。--Kanashimi（留言） 2022年6月18日 (六) 21:31 (UTC)

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

模板:Infobox ship begin等子模板合併事宜

英維社群目前正在討論模板:Infobox ship begin等子模板合併為一個模板事宜，詳情請看此。

如英維社群決定合併，一定會影響有引進此模板的中維，如果我們不跟着它們合併，長遠會影響中維翻譯英維船舶條目的工作（需要轉換原始碼，費時失事）。

我想問：有沒有熟悉模板編輯（主要是熟悉模板合併）的用戶處理此等事宜 ? 有沒有能夠進行成千上萬的船舶條目的原始碼轉換的機器人 ?--約翰同志－條目裱糊匠（留言） 2022年4月30日 (六) 20:22 (UTC)

副知@Cwek、Vozhuo：可能需要進行模板合併的準備。-- 約翰同志－條目裱糊匠（留言） 2022年4月30日 (六) 20:45 (UTC)

首先Template:Infobox_ship是跟随en的更新？其次可以以并行切换的方式，逐步淘汰基于模块思路的Infobox ship XX模板组（告知不要使用，和转换方法），如同{{BS}}RDT系列逐步从模板型转为Lua型。思路可以跟随en，但做法可以有所调整。——Sakamotosan路过围观 | 避免做作，免敬 2022年5月1日 (日) 01:32 (UTC)

Infobox ship在英維現時是重定向至Infobox ship begin，想不到在中維還在。令人擔心引進英維模板框架的中維與英維的滯後。-- 約翰同志－條目裱糊匠（留言） 2022年5月1日 (日) 07:32 (UTC)

是英语太快，Infobox ship目前有35个外语版呢，Infobox ship begin有48个。是否等英语那边稳定和出现实际问题再研究。Infobox ship begin有1178个链入，似乎没有那么严重。相较而言，PRC admin系列的可维护性更值得中维关注，比如数据难以修订；比如暨南街道坏了，目前坏了53条。--YFdyh000（留言） 2022年5月1日 (日) 08:14 (UTC)

是否等英語那邊穩定和出現實際問題再研究，我也是這樣認為的。我出帖的目的，是提醒社群，英維社群對該模板可能有大動作，以免別人合併了，我們還慒然不知，影響中維翻譯英維船舶條目的工作。-- 約翰同志－條目裱糊匠（留言） 2022年5月1日 (日) 08:33 (UTC)

我觉得首先应该先把{{軍艦模板}}（1287引用）、{{軍艦艦型模板}}（111引用）、{{潜艇}}（121引用）、{{艦型模板}}（18引用）这四个以中文参数为主的模板合并成一个覆盖范围更广的模板，比如{{船舶信息框}}。然后再以这个新合并的模板为基础，去扩展兼容英文的参数（从英维提议合并的作者的想法来看，中维上面这几个模板在结构上会和英维合并后的单一模板相似，就有了扩展的可能）。中文维基一直以来就有中英文两套船舶模板，正好趁这个机会先把自己的问题解决了，要不然等英维模板变成新的，中维再引进，就变成三套了，以后就越来越乱了。其实{{軍艦模板}}是有英文参数的，它的英文参数应该是原来英维的{{Infobox_ship}}，你把中维引用Infobox_ship条目的模板名字换成"軍艦模板"显示出来的参数也少不了几个，这是一个很好的合并起点。--Vozhuo_whisper 2022年5月1日 (日) 14:00 (UTC)

@Vozhuo：雖然沒有解決中維的問題，但直接跟隨英維的做法，不是更容易嗎 ? 進行翻譯英維船舶條目的工作的用戶，哪有心機去將Template:Infobox ship轉換成自家的船舶模板。-- 約翰同志－條目裱糊匠（留言） 2022年5月1日 (日) 15:43 (UTC)

我说的都是进行模板合并的工作，和写条目的用户没有关系的。事实上我刚才就已经做了一个初步的版本{{Template:軍艦模板/sandbox}}，把上面我说的四个模板合并了起来（样例：Template:軍艦模板/testcases），比我想象中要简单的多。到时候把英文合并后的模板和这个模板做个整合，也未必是件困难的事情。--Vozhuo_whisper 2022年5月1日 (日) 16:37 (UTC)

@Vozhuo：模板:Infobox service record能兼容嗎 ? 有些潛艇條目帶有這個模板。字體能和Infobox ship begin等子模板一樣大小嗎 ? 最後，Infobox ship begin等子模板有不同國家服役和多次服役退役的功能，能放上去嗎 ? 謝謝。-- 約翰同志－條目裱糊匠（留言） 2022年5月1日 (日) 18:41 (UTC)

这得等到英文那边整合好了再说。--Vozhuo_whisper 2022年5月2日 (一) 05:02 (UTC)

同意。-- 約翰同志－條目裱糊匠（留言） 2022年5月2日 (一) 07:33 (UTC)

目標應該是全部整合進Infobox ship，相容中文與英文參數。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年5月2日 (一) 01:02 (UTC)

英維社群已同意將模板:Infobox ship begin等子模板合併為一個模板，現正整合中。-- 約翰同志－條目裱糊匠（留言） 2022年5月11日 (三) 09:27 (UTC)

本章節暫時不存檔，直到英文維基百科完成子模板合併，中文維基百科更新完成為止。欲讓機器人存檔，請移除本模板。留言請置於本模板上方。

Google 错误地索引 .m 链接

於Phabricator查看
編號T307359的任務

目前只在搜索中文维基百科遇到过这种情况。比如搜索“机甲小宝 Wikipedia”，第一条是 https://zh.m.wikipedia.org/zh-hans/%E9%93%81%E7%94%B2%E5%B0%8F%E5%AE%9D

--Fireattack（留言） 2022年5月1日 (日) 12:43 (UTC)

Google还会索引可视化编辑器（?veaction=edit [3][4]）呢！--Txkk（留言） 2022年5月5日 (四) 13:42 (UTC)

現在google似乎將行動版wiki設為預設，使敝人必須每次手動切換成電腦版。不知其他維基人如何解決這問題？--es91213（留言） 2022年5月7日 (六) 05:43 (UTC)

奇怪，“机甲小宝+Wikipedia”我反而搜到wiki没语言缀的为第一条。不过偶然会搜到zh-tw语言缀的，可能与Google个人搜索算法有关。——Sakamotosan路过围观 | 避免做作，免敬 2022年5月7日 (六) 07:38 (UTC)

希望Google編制搜尋索引時能只收集一種網址版本（無論是內容變體還是行動版／電腦版等等），避免混亂。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年5月7日 (六) 10:23 (UTC)