Wikipedia:互助客栈/方针

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

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

公告欄

• [人事] 仲裁委員會選舉已有結果，10名用戶當選仲裁員。
• [公告] 用户组自我除权、GFDL相關規範加入及WP:ITNR字眼的小修訂已經通過。
• [公告] 引入WP:ONUS、修订用户名方针与用户页指引、修訂圖表説明結尾有無句號及仲裁委員會成立後的管理人員解任機制正在公示，如有意見請儘快提出。
• [討論] 互助客栈方针区正在討論擴充ITNR獲選類別，請踴躍參與討論。
• [討論] 互助客栈其他区正在討論是否应关闭中文维基百科以抗议基金会举措、管理人員任免制度檢討等事及本地部署安全投票及相关权限，請踴躍參與討論。
• [广告] 維基百科亞洲月及其分項北亞月現正舉行，直至11月30日完結，歡迎踴躍參與！

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

#	💭 話題	💬	👥	🙋 最新發言	🕒 (UTC+8)
1	关于WP:非原创研究方针是否适用于模板；以及判定模板为“原创研究”的客观标准	49	16	Nostalgiacn	2024-11-17 01:44
2	应允许保留/创建带书名号的重定向	27	7	Ericliu1912	2024-11-12 15:02
3	提议将金砖国家峰会纳入Wikipedia:新聞動態/重複發生的項目	29	11	Cmsth11126a02	2024-11-18 00:13
4	修正优特标准的翻译腔问题	21	9	自由雨日	2024-11-12 16:48
5	关于仲裁委员会职权的疑问	2	2	Ericliu1912	2024-10-27 02:16
6	仲裁委員會成立後的管理人員解任機制（續）	1	1	LuciferianThomas	2024-10-28 09:38
7	關於日本選舉的標題問題	15	5	Sanmosa	2024-11-13 11:39
8	准许各用户组自我除权	27	10	ZhaoFJx	2024-11-11 22:04
9	关于用户名方针与用户页指引的重大修订建议	18	10	Shwangtianyuan	2024-11-15 11:25
10	修訂娛樂產業內容相關共識之藝人條目綜藝節目列表章節	20	7	Factrecordor	2024-11-17 10:57
11	討論被錯誤理解達成共識應該怎樣做？	3	1	Factrecordor	2024-11-14 21:39
12	讨论邀请通告	1	1	自由雨日	2024-11-07 16:24
13	修订政治人物关注度指引	38	12	神秘悟饭	2024-11-16 11:02
14	完善WP:封禁「不限期不是永久」總方針	34	12	Shwangtianyuan	2024-11-17 20:58
15	有關簽名附帶的文字的問題（第三次）	40	8	薏仁將	2024-11-16 15:46
16	关于本地化资讯是否为琐碎内容的问题	18	6	Factrecordor	2024-11-16 20:47
17	导向重复的列表拆分逻辑是否成立？	39	2	猫猫的日记本	2024-11-17 12:59

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

正在廣泛徵求意見的議題

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

維基百科格式與命名

Wikipedia talk:格式手册/标点符号 § 推進圖註結尾有無句號共識

由於其餘版本被反對，擬採用並在不久後公示版本A，亦歡迎繼續評點其他版本。副知前次討論者@Lopullinen@HTinC23@捍粵者@PexEric@Evesiesta@Anghualee@InstantNull— Gohan 2024年11月5日 (二) 10:48 (UTC)

維基百科方針與指引

Wikipedia:互助客栈/方针 § 关于WP:非原创研究方针是否适用于模板；以及判定模板为“原创研究”的客观标准

現行條文 在先前有关WP:页面存废讨论中，若干编者多次以模板为“明显的原创总结”及WP:非原创研究方针提删。但这些编者没有回答区别这些模板为“原创总结”，而其他模板如 Template:生成式人工智能、Template:各国列表、Template:软件开发过程、Template:人工智能 等不是“原创总结”的客观标准。 现行WP:非原创研究方针提到： 条目不应该包含有对已发表材料的新式分析和总结，如若这些分析与总结产生了原始来源中并未明确的立场。 但方针文字中未直接涉及模板。

提議條文 因以上问题，提请社群就WP:非原创研究方针是否适用于模板，以及判定模板为“原创研究”的客观标准，予以讨论和澄清。 在此讨论未完成之前，请暂缓以“明显的原创总结”及WP:非原创研究方针为由删除模板。

--Zhenqinli（留言） 2024年8月8日 (四) 08:02 (UTC)

Wikipedia talk:字詞轉換處理 § 《WP:字詞轉換處理#歷史》一章中的“模板:Tq 只能用于讨论和项目页面。请勿在条目中使用。”

“在以前有繁简两版本的文章现在仍然需要人手合并，但目前已经大致完成。”这反映的应该是中文维基百科极早期的状态了吧？应该依事实修订为“目前早已完成”或“已于20XX年完成”？--自由雨日🌧️（留言｜贡献） 2024年8月24日 (六) 16:35 (UTC)

Talk:中国地理 § 中维“中国”一词的地理意义指什么？

条目名为“中国地理”，但通篇介绍的内容不是“中华人民共和国地理”就是“中国大陆地理”——即少部分涉及主权声索等问题时实质上是在介绍中华人民共和国地理，用“中国”一词代表了“中华人民共和国”，违规；其余不涉及主权等问题时则是单纯介绍中国大陆这片区域的地理，用“中国”一词代表了“中国大陆”，违规。如果是一般的条目，只消将条目名移动至“中华人民共和国地理”或“中国大陆地理”然后明确介绍范围即可。但“中国地理”本身是极重要的“中国”类条目，更是《中国》条目《地理》章节的主条目，可以说中维必须要存在一个名为“中国地理”的条目，因为这直接关系到中维“中国”一词的“地理”涵义（类似{{中国历史}}模板和《中国历史》条目对明确中维“历史意义的‘中国’一词指什么”的重要性）。综上，该如何处理本条目？或者说，在中文维基百科，“中国”一词的地理涵义是什么？--自由雨日🌧️（留言｜贡献） 2024年9月25日 (三) 19:25 (UTC)

Wikipedia talk:可供查證 § WP:V引入en:WP:ONUS

今天看到英维的这一段我们没有，并觉得这一段方针对于日常编辑时很有引导作用，以下是我大概翻译的版本，欢迎大家编辑改善，提出自己的意见。

存在可靠来源不保证内容被收录

任何条目中收录的内容应可由可靠来源验证，但这并不代表任何可供查证的信息都应写入条目中。特定内容可能通过共识决定没有改善其条目，也可能由其他方针指出并不应写入维基百科条目。此类内容应被省略或写入其他条目。希望添加存在争议的内容的编者有义务为添加该内容形成共识。--0xDeadbeef (留言) 2024年10月13日 (日) 04:08 (UTC)

Wikipedia talk:互助客栈 § 有關互助客棧方針版的長度壓力問題

此前，互助客棧方針版的長度一度逾60萬位元組，在我搬運了若干已結束或stale了的討論後才降到40多萬，然而這個長度還是比起其他互助客棧的版塊來得長（互助客棧其他版的長度現在是20多萬位元組，條目探討版是10多萬，消息、技術與求助版不超過10萬），而且在頁面載入與編輯上也產生了一些問題（我在電腦嘗試載入或編輯頁面的話，頁面完全載入所需的時間顯著地延長了）。有鑒於此前曾有討論提議以WP:徵求意見機制取代互助客棧方針版的機能，我認為現在是合適的時機來提出這件事情。Sanmosa _新朝雅政 2024年10月23日 (三) 00:30 (UTC)

Wikipedia talk:COVID-19條目共識 § 調整COVID-19條目共識的規定

承上討論，現提議修改WP:COVID-19條目共識的表述。草案正文，差異。Sanmosa _新朝雅政 2024年10月23日 (三) 02:00 (UTC)

Wikipedia talk:可靠来源 § （硕士论文）怎样的影响可以算作“显著学术影响”

• “硕士学位论文通常未经类似评估，因此不如博士学位论文可靠，除非其具有显著学术影响。”是否需要用信息页说明“显著学术影响”？
• 对于一般的（无“显著学术影响”）硕士论文而言，相关行文似乎也有模糊之处，只点出硕士论文“不如博士论文可靠”，而未明言其“不是可靠来源”。是否需要点出“除非具有显著学术影响，否则硕士论文不是可靠来源”（英维是明确点出的：“Masters dissertations and theses are considered reliable only if they can be shown to have had significant scholarly influence.”）？--自由雨日🌧️（留言｜贡献） 2024年10月23日 (三) 16:21 (UTC)

Wikipedia talk:消歧义 § 2020年10月修订案与格式讨论

修订案主要涉及#章节安排问题（最简单的做法只需将一个三级标题改为二级标题），以及#修订WP:消歧义命名的问题。格式讨论涉及主从消歧义页面编写方式（若有必要则亦应修改指引）。——自由雨日🌧️（留言｜贡献） 2024年10月25日 (五) 04:39 (UTC)

Wikipedia talk:管理員的離任 § 仲裁委員會成立後的管理人員解任機制（續）

經共識訂立的仲裁機制及其他過往討論中均就仲裁委員會在處理管理人員解任案獲得社群廣泛同意，在維基百科討論:仲裁委员会#管理人員解任中就達成了「仲裁委員會有權調查管理人員行為是否失當後交社群再行決議」，但就仲裁委員會如何行使有關職權仍有待商榷。我想將這個議題分拆成多個部分去探討，期望獲得最大程度的共識。本討論分為以下部分：

1. 彈劾機制；
2. 糾舉機制；
3. 直接除權；及
4. 依請求介入社群程序。

(※)注意：此四機制並非僅能採納其中一個，這四個機制的設計是完全可以共容的。

--路西法人 2024年10月27日 (日) 16:39 (UTC)

Wikipedia:互助客栈/方针 § 准许各用户组自我除权

八年前，有用户组自我除权之讨论已达共识，允当时所设用户组自我除权。然现有四个非管理的可申请用户组（过滤器助理、仲裁委员会委员、确认用户及模板编辑员）尚无移除自己账号的用户组权限。或可准许此等用户组自我除权，使各用户组权限一致，并减轻维基百科:申请解除权限负担。

提議條文 ……； 允许移除自己账号的用户组。

尚祈社群商议为荷。——即请秋安 ZhaoFJx_(论•签) 2024年10月29日 (二) 22:28 (UTC)

Wikipedia talk:格式手冊/電視 § 對於剛訂立的格式手冊/電視，細節上的疑問

由於在Wikipedia:互助客栈/条目探讨#是否建立各家平台或電視台之外購動畫、節目、特攝的分類項目，日漸離題地討論剛訂立的Wikipedia:格式手冊/電視，故在此再開話題。 討論的焦點在於

節目的OTT播放平台及網絡電視的節目可觀看地區均需列明來源，OTT播放平台及網絡電視平台播放清單不建議作為證明「可觀看地區」的來源，因為相關平台及播放清單通常不會明文記錄可觀看地區。若相關OTT播放平台及網絡電視平台播放清單明文記錄可觀看地區，則不受此限。

來源1號[1]：草擬人@HK5201314舉出的傳媒報道，作為符合要求的來源例子，相關內文為：「韓劇《重組家庭》於10月9日首播，共有16集，每週三連續播出2集，作為Viu Original劇集在香港、東南亞、中東及南非等16個地區於Viu網上平台獨家播出。」明確地列出了Viu平台的全部可觀看地區。

來源2號[2]及3號[3]：我所舉出的傳媒報道，不全面，相關內文為：「也特別聯合9大平台，中華電信MOD/Hami Video、LINE TV、遠傳friDay影音、巴哈姆特動畫瘋、MyVideo、KKTV、Muse木棉花-TW/Muse木棉花-HK、霹靂電視台、PILI線上看等，回顧《Thunderbolt Fantasy 東離劍遊紀》第1~3季及2部劇場版的精彩內容。」「首播平台爭戰最終敲定於4月3日開始，每周六晚間9:30於6大影音平台CATCHPLAY、遠傳friDay、台灣大哥大 myVideo、MOD中華電信、Hami Video與官方PILI線上準時播映。」我認為這些針對台灣地區的來源，已等同代表可觀看地區包括台灣，雖然沒有提及台灣以外（也許Muse木棉花-TW/Muse木棉花-HK除外）有哪些可觀看地區，但條文也沒有明文規定必須在來源的情況下列出全部「可觀看地區」才算及格，那麼就算只証明部分「可觀看地區」，也無不可。

它們都可算第三方來源，但相信當中的平台播放資訊都是來自宣傳稿，當然1號是平台本身的宣傳，2-3號是作品本身的宣傳。

相信訂立條文的精神，本是希望禁止羅列一些不三不四的盜版平台，以及對數量可能會太多的播放資訊進行適度篩選。我擔心過度執著証明平台所有地區版權，會變得本末倒置，不能公平地作出真正有效的篩選。我意思維基認為可用或不可用的驗證方法，對平台、對作品製作方、對傳媒、對觀眾來說，往往都未必需在意的事。一個平台的操作介面和宣傳稿，如果剛好習慣很明顯地顯示全觀看地區，它就會僥倖地在維基得到優勢，其他平台縱使合法性、覆蓋性相當，純粹因顯示區域的習慣不迎合，就不能寫，若在這種情況不能坐視不管。我們要做的是觀察各方普遍的習慣，從中拿捏出反映現實又寬緊恰當的篩選準則。如果我們定的準則，只是看誰的習慣僥倖地較能迎合，那就不是一個好的準則，應當修改。

另外，草擬人指出已通過的規則比英維更嚴，這是和某幾位參與者討論後，才越來越嚴格的。當時我不是持續關注那討論，但印象是積極發言者多是希望從寬。所以，懷疑大家對共識內容的解讀會有很大差異，需召集大家回來看看。--Factrecordor（留言） 2024年11月2日 (六) 18:19 (UTC)

Wikipedia talk:格式手册/标点符号 § 推進圖註結尾有無句號共識

由於其餘版本被反對，擬採用並在不久後公示版本A，亦歡迎繼續評點其他版本。副知前次討論者@Lopullinen@HTinC23@捍粵者@PexEric@Evesiesta@Anghualee@InstantNull— Gohan 2024年11月5日 (二) 10:48 (UTC)

Wikipedia talk:维基百科不是什么 § 提請修訂 維基百科不是什麼中的旅遊指南，新增「建築物附近交通資訊」的規管

現行條文 旅遊指南。例如，關於巴黎的條目應該敘述艾菲爾鐵塔、羅浮宮等名勝，但您最喜歡的酒店的電話號碼、香榭麗舍大道賣的牛奶咖啡的價錢……都不是適當的內容。維基百科不是建立酒店或美食指南、遊記等內容的地方。知名城市可能符合收錄標準，但最終條目不必包括每個旅遊景點、餐館、酒店或場地等。雖然每個城市的旅遊指南通常會提到鄰近城市的景點，但維基百科的每個城市條目應該僅列出實際位於該城市的景點。如果您確實希望幫助編寫旅行指南，我們非常歡迎您為我們的姊妹專案維基導遊做出貢獻。 需要注意的是，出於著作權上的考慮，請勿隨便抄錄其他文字，除非您是著作權持有者。

提議條文 旅遊指南。例如，關於巴黎的條目應該敘述艾菲爾鐵塔、羅浮宮等名勝，但您最喜歡的酒店的電話號碼、前往那間酒店的交通資訊、香榭麗舍大道賣的牛奶咖啡的價錢……都不是適當的內容。維基百科不是建立酒店或美食指南、遊記等內容的地方。知名城市可能符合收錄標準，但最終條目不必包括每個旅遊景點、餐館、酒店或場地等。雖然每個城市的旅遊指南通常會提到鄰近城市的景點，但維基百科的每個城市條目應該僅列出實際位於該城市的景點。如果您確實希望幫助編寫旅行指南，我們非常歡迎您為我們的姊妹專案維基導遊做出貢獻。 需要注意的是，出於著作權上的考慮，請勿隨便抄錄其他文字，除非您是著作權持有者。

目前，許多香港建築物條目均設有公共交通路線資料，讓遊客可透過維基百科了解如何前往該座建築物。但是，這不應是維基導遊及Google Map的職責嗎？於是建議新增這句 「前往那間酒店的交通資訊」。位置已透過粗體標示出來了。--唔好阻住我愛國（留言） 2024年11月5日 (二) 11:03 (UTC)

維基百科提議

Wikipedia talk:字詞轉換處理/公共轉換組 § 交集板塊：減少重複、節省資源

不少轉換規同時存在於兩個或多個公共轉換組，浪費資源，對此更新修正疲於奔波、亦浪費人力。不如設置可容多個公共轉換組嵌入的「交叉板塊」——相當於次級的公共轉換組。例如，Movie組、迪士尼組、Pixar組之間設置「交集板塊」「迪士尼-Pixar長片」，Movie組、迪士尼組之間設置「交集板塊」「迪士尼非Pixar長片」，Movie組、Pixar組之間設置「交集板塊」「Pixar非迪士尼長片」；如此，任何一個迪士尼或Pixar出品的電影長片的轉換規則都應收錄在以上三個「交集板塊」之一，而移出Movie組、迪士尼組、Pixar組頁面本身，最終轉換效果不變。另外，在提交公共轉換組編輯時，亦可警告不應增加已收錄在屬於本公共轉換組的「交集板塊」的字詞或要求復查。希望儘早提出此想法，以免導致上節「預儲」設計細節日後大改。--— Gohan 2024年7月10日 (三) 07:05 (UTC)

Wikipedia:互助客栈/其他 § 為管理人員任免制度檢討等事

近期又一管理人員解任投票，甫應用安全投票之新制，技術實務運作尚難稱熟稔；又逢顯著外來干涉及共識形成程序疑慮，遂致前所未有之困窘，亂象叢生、弊端頻出，社群矛盾對峙趨於激烈，此實無庸置疑。與此同時，定期審視更新管理人員任免制度，有助於人才新陳代謝，充實本站進階維護量能。時值仲裁委員會組織籌備停滯之際，「遠水難救近火」，故謹以此話題為首，先行就管理人員任免制度若干既存問題略作檢討，望社群踴躍發表意見。改革路程自不必操之過急，但求氣象有所更新爾。本人謹提出三個大問題，社群可撥冗予以回應，或自行提出其他值得專門討論之問題。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年8月18日 (日) 18:29 (UTC)

Wikipedia:互助客栈/其他 § 在本地啟用安全投票及electionadmin权限

原标题：SecurePoll elections with the electionadmin right

（我很抱歉用英语写作。请随意翻译此消息。）

Hello! My name is Joe Sutherland and I'm on the Trust and Safety team at the Wikimedia Foundation. In the past, your community has shown interest in holding elections with SecurePoll — perhaps you already have through votewiki. We are now looking into making this available to local communities to run elections themselves. This will require the "electionadmin" right to be enabled on your project, which is a right that allows access to sensitive information.

As such, it is likely that you will need to run a Request for Comment (or similar process) to ascertain consensus for the implementation of this feature. To help guide such a discussion, we've put together a Meta-Wiki page with more information about what enabling the right will mean for your community.

If your community does discuss and decides to move forward with this, T&S would like to support you — please let us know via email ( ca@wikimedia.org ) if and when consensus is reached. Thank you!--JSutherland (WMF)（留言） 2024年10月17日 (四) 20:07 (UTC)

Wikipedia talk:管理员错误自查表/封禁 § 有關此頁面新增內容，請大家協助確認及提供意見

Gluo88之前曾在Wikipedia:管理员错误自查表/封禁增加內容[4]（後來被Tisscherry及RainBeforeSun回退），最近Gluo88有重啟討論。我想讓多一些人參與討論，比較容易知道大家對此事的想法（之前的討論在上面，我就不自行做總結，怕我的表達扭曲任何一方的意思）--Wolfch (留言) 2024年10月20日 (日) 06:55 (UTC)

Wikipedia:互助客栈/其他 § WMF考虑向印度法院披露编辑身份信息，本站是否应该关站抗议

原标题为：WMF考虑向印度法院披露编辑身份信息，英维正在讨论关站抗议

参见：亚洲国际新闻诉维基媒体基金会案、Wikipedia:頁面存廢討論/記錄/2024/11/14 § 亚洲国际新闻诉维基媒体基金会案、en:Wikipedia:Community response to Asian News International vs. Wikimedia Foundation、en:Wikipedia:2024 open letter to the Wikimedia Foundation和en:Wikipedia talk:2024 open letter to the Wikimedia Foundation § Update from 14 November hearing

2024年11月14日17:29 (UTC)，也就是几个小时以前，英文维基百科用户发起民意调查，讨论是否就基金会考虑向印度法院披露编辑身份信息而闭站抗议。如果英维闭站抗议，本站是否跟随？ ——魔琴［身份声明 留言 贡献 新手2023］ 2024年11月14日 (四) 20:09 (UTC)

Wikipedia:互助客栈/其他 § 仲裁委員選舉結果

仲裁委員選舉已有結果，請參看Wikipedia:仲裁委员会/选举/2024年#結果，10名用戶當選為仲裁員。謝謝。--AT 2024年11月15日 (五) 17:31 (UTC)

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

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

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

没有意见。未见说明，但该表单似乎不受IPBE影响。关于填入IP地址，建议为可选而非隐含，以利隐私选择权。--YFdyh000（留言） 2022年7月16日 (六) 18:25 (UTC)

那啥，两个问题：

1. IP被封禁能提交得了这个表单么？
2. 这个扩展有啥防滥用机制么？会不会被利用来大量发送spam？--百無一用是書生 (☎) 2022年7月18日 (一) 02:22 (UTC)

这个扩展本质是Special:EmailUser套皮。如果使用者被禁止发送邮件，那么他们就用不了这个页面；页面的使用也受到邮件相关的速率控制。--MilkyDefer 2022年7月18日 (一) 14:29 (UTC)

尴尬，如果被封了是不能发邮件的；有一个可选的captcha。鉴于本提案无法实现，撤回。 Stang^★ 2022年7月18日 (一) 14:55 (UTC)

@Stang：奇怪的是，我在meta上用被封禁的IP（编辑页面，提示已封禁），可以用这个表单啊。之前尝试好像没见到验证码，这次尝试见到验证码。"Your account or IP address has been blocked."、"Email sent"。--YFdyh000（留言） 2022年7月19日 (二) 03:48 (UTC)

我强调一遍，是被撤除了邮件权力的人不能用。Stang作为前行政员在封人的时候不可能没见过“不能发送电子邮件”的选项吧？除非封锁一个IP用户，会导致受其影响的无账号人员不能发出请求代为创建账号的表单。--MilkyDefer 2022年7月19日 (二) 06:44 (UTC)

很奇怪的是我昨天用了某个不能编辑页面的IP在匿名情况下发现是无法使用这一功能的，但是刚刚我尝试复现的时候似乎又没法重新复现…？话说回来，这个扩展是用$user->isBlockedFromEmailuser()来判断的，那如果封一个匿名用户会干掉sendemail这个权限么，如果没有的话那还有继续讨论的余地。 Stang^★ 2022年7月19日 (二) 11:28 (UTC)

MilkyDefer已經完整說明了，我很意外前管理員怎麼會不熟悉封鎖的相關設定。--Xiplus#Talk 2022年7月22日 (五) 06:12 (UTC)

介面可以參考mw:Help:Blocking users/zh的附圖。--Xiplus#Talk 2022年7月22日 (五) 12:36 (UTC)

从未对匿名用户执行过禁止发送电子邮件的设置，因此完全不了解这一点。 Stang^★ 2022年7月24日 (日) 13:06 (UTC)

似乎没有明确的反对意见，故公示7天。 Stang^★ 2022年7月31日 (日) 17:46 (UTC)

表單的欄位是通過後再討論嗎？--Xiplus#Talk 2022年8月1日 (一) 01:00 (UTC)

可以同时或者之后讨论，我认为把要不要做和怎么做分开是合理的。 Stang^★ 2022年8月1日 (一) 08:11 (UTC)

公示完之後要做什麼？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年8月10日 (三) 08:00 (UTC)

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

再@Stang。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年8月27日 (六) 09:51 (UTC)

非常不好意思摸了这么久。对于表单内容，咱个人的意见是这样的：如果可能，应设计两个表单，分别针对未注册用户（用于申请账户）和注册用户申请IPBE权限；对于未注册用户，其应包括“当前使用的IP地址”、“封禁ID”（可选）、“申请注册的理由”、“意向用户名”；面向注册用户的表单基本类似，只是没有“用户名”这一个栏目；表单不记录用户的IP地址。这个想法可能不是很完善，自动封禁就不是很适用于这种情况，暂时没想好怎么做。（或者一个下拉选框让申请人选自己是原电子邮件发送指引中5种情况的哪一种？ Stang^★ 2022年9月5日 (一) 05:29 (UTC)

就如同您說的一樣，情況也不只2種而已，而且實務上仍然有人會填錯封鎖ID等欄位，設固定欄位感覺沒比較好，我建議只配置純文字的表單即可，也另外可以做個小工具來輔助產生郵件內容（我已經著手進行一點點，但平時繁忙可能沒這麼快弄出來）。--Xiplus#Talk 2022年9月6日 (二) 12:39 (UTC)

咱希望了解目前收到的邮件之中可以按照指引给出的模板正确填写的比例，这样判断一下“填错ID等栏目”等等情况属于少数还是占了不小的比例。感谢您可以投入去开发邮件辅助生成小工具（就跟 relgen.js 差不多的那种么）。 Stang^★ 2022年9月12日 (一) 04:16 (UTC)

統計了一下剛剛處理的38件申請。38件申請中有16件沒有依照WP:IPBEMAIL的格式，22件有依照格式；

1. 沒有依照格式的16件申請中，
   1. 有9件因此缺乏必要資料需要補件。
   2. 其餘7封雖然沒有按照格式，但有提供必要資訊，仍申請通過。
2. 有依照格式的22件申請中，
   1. 有2件提供的IP並沒有被封鎖，但提供的封鎖ID有被封鎖，仍申請通過。
   2. 有2件提供的封鎖ID錯誤（提供了不是封鎖ID的無用資料），
      1. 其中1件因為IP及封鎖ID皆錯誤而申請失敗。
   3. 有3件即使依照格式申請，但不知為何仍缺乏必要資訊，因此申請失敗。

我正在做的就類似relgen.js。--Xiplus#Talk 2022年9月12日 (一) 07:32 (UTC)

感谢提供以上信息，我支持使用纯文本的表单，此表单允许匿名用户进行填写，不在发送的邮件中包括填写者的IP地址。 Stang^★ 2022年9月13日 (二) 20:46 (UTC)

「不在發送的郵件中包括填寫者的IP位址」的意思是？使用表單自帶的IP嗎？--Xiplus#Talk 2022年9月14日 (三) 02:29 (UTC)

实装了一下，我所说的“填写者的IP”是指'IncludeIP' => true,这一特性可以把使用者的IP地址包含在主题中。如果启用了的话，对于匿名用户而言，邮件主题将形如“联系信息 (由[表单内填写的名称]在[IP地址])”；如果没有启用，主题将形如“联系信息（自[表单内填写的名称]）”。已登录的用户会有一个多选框决定是否“在此邮件中包含我的IP位置资料。”，如果勾选了，IP地址也将类似于匿名用户一样，显示在主题一栏中。 Stang^★ 2022年9月18日 (日) 22:34 (UTC)

暂拟的配置，非常简单：

// IS.php
'wmgUseContactPage' => [
	'zhwiki' => true,
],
// CS.php
if ( $wgDBname === 'zhwiki' ) {
	$wgContactConfig['acc'] = [
		'RecipientUser' => 'Unblock-zh',
		'SenderName' => '中文维基百科账户请求表单',
		'RequireDetails' => true,
		'IncludeIP' => true,
	];
}

acc代指账户请求，不过可以后期再议；默认主题应在MediaWiki:Contactpage-subject-acc这个页面自定义；“SenderName”暂时这么想，待议。 Stang^★ 2022年9月18日 (日) 22:34 (UTC)

不是要加 'IncludeIP' => true 嗎？--Xiplus#Talk 2022年9月21日 (三) 01:27 (UTC)

上面咱的提议是*不要*加 IncludeIP 啊。个人觉得这个可能会与privacy policy相抵触，以及IP数据这种东西可能会涉及到NDA的问题。 Stang^★ 2022年9月21日 (三) 06:16 (UTC)

您原先推薦ContactPage的理由之一為「管管無法驗證使用者對應的IP位址是否真的被封鎖了」，若不使用這個功能，那麼ContactPage就跟目前的方式相比就沒有額外優點了。--Xiplus#Talk 2022年9月21日 (三) 06:19 (UTC)

感谢快速的回应。blame了一下存在一个站点启用了包含IP地址这一功能，猜测要求这么做应当不会被拒绝。加了。 Stang^★ 2022年9月21日 (三) 06:24 (UTC)

简单 公示7日，2022年10月4日 (二) 22:06 (UTC) 結束。配置改完之后建议修改目前的操作手册，并建议申请者通过表单提交请求。 Stang^★ 2022年9月27日 (二) 22:06 (UTC)

「'IncludeIP' => true」 此舉將使未有簽署 NDA 的管理員可獲取屬非公開個人資訊的 IP 地址。

雖然現時也要求用戶提供 IP 地址，然而現時的為自願提供及可能有誤，而本提案為系統自動提供用戶的 IP 地址，與 CU 無疑。個人認為從法律屬面上基本上不可行。謝謝。--SCP-0000（留言） 2022年9月29日 (四) 03:57 (UTC)

IncludeIP也是可選的，請自己試試看就知道了。--Xiplus#Talk 2022年10月1日 (六) 03:06 (UTC)

考慮到「未有簽署 NDA 的管理員可獲取屬非公開個人資訊的 IP 地址」私隱及法律上的隱憂，個人認為應先聯絡基金會法律部門，以確認此提案確實可行。當然，就個人的認知，基金會法律部門原則上並不會允許未有簽署 NDA 者獲取非公開個人資訊。謝謝。--SCP-0000（留言） 2022年10月1日 (六) 03:21 (UTC)

为什么不可以使用Commons上这种的方法呢？--0xDeadbeef（留言） 2022年10月1日 (六) 07:04 (UTC)

Xiplus上面说了在开发一个（类似于这样）的的。 Stang^★ 2022年10月9日 (日) 22:09 (UTC)

歪个楼问一下，目前申请IPBE是否需要提供IP地址？至少在Wikipedia:權限申請/申請IP封禁例外權/存檔/2021年中有大量用户未提供IP地址。--Steven Sun（留言） 2022年10月1日 (六) 13:18 (UTC)

似乎是逐渐有了这样的趋势？之前给IPBE相对于现在宽松很多，当然也有了一些没有妥善备案的例子，目前给一下感觉可以理解。 Stang^★ 2022年10月9日 (日) 22:09 (UTC)

感觉社群方面似乎没有太大的问题，为了以防万一咱会给legal发邮件询问一下可不可以这么做。这个串应该可以存档了。 Stang^★ 2022年10月9日 (日) 22:09 (UTC)

這個功能應該不容許申請者使用圖像證明自己確實受到IP段封禁的影響，或有需要使用代理伺服器等科學上網手段（是這樣的，OA2021之後我曾經想過一個收緊IPBE的方案，其中一個環節就有這個要求，當然那個方案可以和表單的部署並行就是了）。然後同SCP-2000的疑慮。順便吐槽一下，你維的captcha太渣了，幹不過melon的買榜機械人還不止，聽說就甚至有盲人能輕鬆破解的。--春卷柯南－發前人所未知 ( 論功行賞 ) 2022年10月9日 (日) 22:36 (UTC)

@Stang：（話說要存檔到哪裡來著）—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年10月23日 (日) 14:44 (UTC)

---

所以現在是公示完畢了麼？之後還需要做些什麼？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年10月16日 (日) 08:56 (UTC)

依上方的討論，現已公示完畢。惟仍須等待法律部門的回覆，以確認此方案切實可行。--SCP-0000（留言） 2022年10月16日 (日) 09:35 (UTC)

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

Wikipedia:可靠来源:

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

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

Wikipedia:可供查證：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7日内无新留言。 公示7日，2022年9月3日 (六) 10:10 (UTC) 結束。--Steven Sun（留言） 2022年8月27日 (六) 10:10 (UTC)

我存在异议，并不是因为「普遍有效的帐户认证」才导致「用户生成内容通常是不可靠的」，这个因果关系并不必然，我看到User:YFdyh000也有提到这一点，结果提案还是在断言这一点。存在用户认证应该是直接可供查证，然后才是可能继承可靠性，这一点下文也有提及，因此删除首段「普遍有效的帐户认证」文字对提案具体内容没有太大影响。----Cat on the Mars 2022年8月30日 (二) 09:56 (UTC)

認為現更改版本、未充分吸收本編有關前置限定適用條件之要求，且版本涉及之WP:WIKISRC章節連帶WP:SPS章節，分屬不同指引之下位內容，而若僅單一修改各自表述不考慮連帶疊加影響等衍生效果、恐有生邏輯撕裂之呈現及衍生歧義等情相伴，在此認為擬定之修正案應：

WP:WIKISRC修正案應置於WP:評估可靠性之下位邏輯進行審視及修正草擬，章節條文如採本案理解之修訂、必須前置「在未滿足具備事實查核和帳戶認證」等條件之，而列明條文指定不滿足前置條件之特定「用戶生成內容」通常不具可靠性，而且不應以固定偏好列舉包含有關內容之特定載體，應避免行文先入為主而忽略掉在依足WP:PSTS及WP:SYN等指明評估下可能合規之特定情況。

而WP:SPS於本案現提案所修正之表述，訴諸以「言論」取代之限定指示、可能有任意擴大訴諸之風險，皆因該改動令整個章節述之邏輯涵蓋可遠超單一屬性標的物，依據前述之應具前置限制理論、即使重新修正該章節亦應依據WP:NOTRS置於旗下再行審定相關行文邏輯重置，姑且於章節內前置應列明（章節之限制條件）：前置「未滿足具備事實查核和帳戶認證」等條件之、單一屬於用戶生成內容或個體原創生成內容之來源載體。

暫有以上補充，同時要求中止相關公示程序、延長審視修正之時間，並建議將實質案內之各自獨立維基指引修正案，重新以獨立修正案形式分別提交程序進行討論、審查和研究，宜評核兼顧各分章節假定付諸之實效條件等慎重審視。——約克客（留言） 2022年8月30日 (二) 11:54 (UTC)

关于WP:SPS的问题，目前条文中的“开放性wiki、博客、论坛贴文”已超出了“自创网站”的范畴。使用“网络上发表言论”更符合“开放性wiki、博客、论坛贴文”的内容性质。--Steven Sun（留言） 2022年9月1日 (四) 14:15 (UTC)

依上方意见暂停公示。另外我也觉得应该删除首段的“普遍有效的帐户认证”。--Steven Sun（留言） 2022年8月30日 (二) 12:23 (UTC)

現提議分開表決、公示及討論

關於WP:可供查證的修正，建議按原先的公示期繼續餘下的公示

@CatOnMars、@Longway22、@Steven Sun，請問對WP:可供查證的修正有沒有問題？因為你們沒有就WP:可供查證的修正提出意見。

而WP:可靠來源的修正則有仍未有共識，建議繼續討論。--唔好阻住我愛國（留言） 2022年9月1日 (四) 08:55 (UTC)

請仔細閱讀既已提出意見所述之WP:SPS問題、即為對修正案連帶問題之一，且該問題會一併與來源問題相關聯相互有影響、斷不能獨立拆分單獨過橋。同時建議再協最下方議案相關進程一併檢視，待先行處理完備GUNREL上級章節之問題，以策萬全。--約克客（留言） 2022年9月1日 (四) 09:03 (UTC)

Wikipedia:可靠来源:

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

提議條文 个人网站、博客、网络论坛、社交媒体、粉丝网站、影片分享网站、网络相册、Wiki的内容或者Blog上的留言都絕不能成为可接受的一次或者二次来源。这是因为我们无法知道它们究竟是谁写的。对于Wiki的情形，文章的内容可能在任何时刻发生变化，而且没有编辑人员监管或者第三方核查事实。通常都含有用户生成内容。 在部分社交媒体中会有帐户认证，以表明某个社交媒体账户由真实个人或组织拥有并运营。在这种情况下，该账号的可靠性可能继承自这个人或组织本身的可靠性。

Wikipedia:可供查證：

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

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

如果在不更改原因解釋的前提下作適當的擴充，請問大家有沒有意見？畢竟新增的media與先前的性質類似。--唔好阻住我愛國（留言） 2022年9月1日 (四) 09:16 (UTC)

依據回案意和關聯案事，即使如簡化下級章節之當前先於上級之修訂案、亦不應排除經首發平台或轉載平台等而可能具備之查核&驗證因素，而英文版有關限制之定義為largely not acceptable或generally unacceptable，非當前中文呈文之武斷措辭，唯一絕對化限制指示在於不要利用有關內容作為獨立來源採編有關在世人士的內容，修正案應改變絕對限制條件至指定為針對WP:LIVING之來源採用，對其他範圍之定語為「一般不採用」或「大多情況不採用」而更好反映當前相關案事之共議理解等情。--約克客（留言） 2022年9月1日 (四) 10:00 (UTC)

现单独对Wikipedia:可供查證进行修订：

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

提議條文 任何人均可自费出书，或者在开放性平台中贡献内容。因而，绝大多数个人出版之书籍、业务通讯、个人网站、开放性Wiki、博客、用户生成内容及类似来源一般不被认可为可靠来源。

--Steven Sun（留言） 2022年9月1日 (四) 14:23 (UTC)

@Steven Sun：個人認為用戶生成內容可靠关鍵是誰來發佈。WP:SPS有說「在某些情形下，個人出版物亦仍可以被接受。例如......（從略）」，所以我覺得討論重點應是誰的發佈內容符合「仍可被接受」。另外，我記得有些條目是比較依賴社交媒體作可供查證。Fran·1001·hk 2022年9月5日 (一) 05:21 (UTC)

“用户生成内容”和“个人出版物”区别蛮大的。网络上的用户生成内容，有身份确定和内容固定两大难题，所以不易做到可供查证。个人出版物则是内容正确性、利益相关、版本存续等问题。--YFdyh000（留言） 2022年9月5日 (一) 06:53 (UTC)

UGC的问题显然比SPS要大，后者只有一个可靠性问题，前者可靠性和可供查证都不稳定，认证用户有失水准也不是一天两天的事情，即便是认证用户在UGC鲜有评审的背景下也有自说自话、靠粉丝「自圆其说」的时候（很多时候出事就赖实习生）。我觉得承接前两个讨论，大多数人支持的论点应该是机构或媒体认证账号相对可信，还不至于现在把所有认证账号都包括进来，比方说我前面讲的个人认证账号的问题，至少在我看来这不是可靠来源，最多只能用作观点。

附：翻译一下ENWP的UGC政策以供参考。

Content from websites whose content is largely user-generated is generally unacceptable. Sites with user-generated content include personal websites, personal and group blogs (excluding newspaper and magazine blogs), content farms, Internet forums, social media sites, fansites, video and image hosting services, most wikis and other collaboratively created websites.

有些网站的内容大多由用户生成，这些内容一般不是可接受的来源。这类网站涵盖个人网站、个人或集体博客（报刊杂志的博客除外（这里指代专栏博客））、内容农场、社交媒体、粉丝网站、音像或图片托管服务（共享网站？）、多数wiki以及其他集体协作创作内容的网站。

Examples of unacceptable user-generated sites are Ancestry.com, Facebook, Fandom, Find a Grave, Goodreads, IMDb, Instagram, ODMP, Reddit, TikTok, Tumblr, TV Tropes, Twitter, and Wikipedia (self referencing).

其中比较典型的有脸书、微博、Fandom、IMDb、Instagram、Reddit、抖音、推特和维基百科（自我引用），上述内容一般不是可接受的来源。（有删改）

Although review aggregators (such as Rotten Tomatoes) may be reliable when summarizing experts; otherwise, their ratings based on the opinions of their users are not.

In particular, a wikilink is not a reliable source.

尽管一些评论汇总网站（譬如烂番茄）在总结专家意见时或许可靠，但除此之外其基于用户评价的评分并不可靠。特别要强调的是，维基百科不是可靠来源。

----Cat on the Mars 2022年9月5日 (一) 15:39 (UTC)

• (－)反对以「絕不可以」作為字眼一刀切。少數有充分可查證來源的頻道或專頁應可豁免作為一手來源，如CGP Grey的影片就有被英維引用過-某人✉ 2022年9月11日 (日) 07:40 (UTC)

  「絕不可以」--Cat on the Mars 2022年9月11日 (日) 07:55 (UTC)

「(...)影片分享網站(...)都絕不能成為可接受的一次或者二次來源。(...)」-某人✉ 2022年9月11日 (日) 08:02 (UTC)

有關認證的段落，建議按以下方式修改，以涵蓋不同情況：

現行條文 在部分社交媒体中会有帐户认证，以表明某个社交媒体账户由真实个人或组织拥有并运营。在这种情况下，该账号的可靠性可能继承自这个人或组织本身的可靠性。

提議條文 部分社交平台帳號可以透過包括但不限於平台的帐户认证或其他方式來證明某社交媒体账户代表現實中的特定个人或组织。在这种情况下，這些账号所發表內容的可靠性一般可被視作等同於这个人或组织在其他場合所發表的內容。但要注意這些經證明能代表特定人物的社交平台帳號可能由經委託予他人所操作，因此未必能用於證實特定發言出自帳號持有者。

——C933103(留言) 2022年9月14日 (三) 13:27 (UTC)

(＋)支持--Yinyue200（留言） 2022年9月14日 (三) 14:37 (UTC)

改動似乎增加新的問題，必須進行單獨討論；如撤銷改動，採用回原句，則不必要再行修訂。--約克客（留言） 2022年9月15日 (四) 01:06 (UTC)

提案裁撤案內多餘章節

鑑於審視有關單一針對平台之章節已可用上級WP:GUNREL完全替代處理，適切相關議案之立論、可便利往後梳理審視單一性質之個案問題，特此提案：直接廢除WP:WIKISRC章節全部內容及超鏈接，由上級WP:GUNREL等繼續改進之一併完備有關後續。以上。——約克客（留言） 2022年9月1日 (四) 10:12 (UTC)

同意。此外我觉得Wikipedia:可靠来源#作者自行发表的材料也应一并废除。还有Wikipedia:可靠来源#在关于作者自己的条目中采用他们自行发表的来源也有点多余，似乎可以合并至Wikipedia:利益衝突中。--Steven Sun（留言） 2022年9月1日 (四) 13:57 (UTC)

(▲)同上。----Cat on the Mars 2022年9月5日 (一) 15:40 (UTC)

現行條文 自行發表的來源是一種未經過任何事實證實或是未經過第三者檢驗所發行的資料，其中包括個人網站以及為了滿足虛榮心所發行的刊物。 任何一個人都可以建立一個網站或是自己花錢來發行一本書，並且自稱是某領域的專家。基於這個理由，絕大多數自行發表的刊物、個人網站以及部落格等都不是可接受的資料來源。 不過也有一些特例是可以的，例如知名的專業研究人員在其自身專業領域中的自行發表或是一位顯著的專業新聞工作人員所自行發表的資料。這種資料在某些情況下是屬於可以使用的自行發表的資料來源，例如這些資料已經被可信的第三者發行過以及是以他們的真名發表而不是筆名或假名。 然而編輯者還是必須謹慎小心的使用，基於以下兩個理由：第一，如果在該專業研究人員的部落格上的資訊是真的值得發表，那麼有可能已經有人發表過了；第二，由於該資料是自行發表的，所以代表其內容的正確性並未經過任何第三者的驗證。

提議條文 任何人都可以建立网页、自行出版、或自称专家，自行发表的来源往往未经任何事实核查，缺乏独立第三方评审，因此绝大多数个人出版物、个人网站、博客、开放性wiki、网络论坛或社交媒体上的贴文以及其它类似来源通常不是可接受的来源。 不过也有一些特例，例如一些新闻媒体会以博客指代其网络专栏，如果专栏作者为专业人士其内容可能相对可靠；此外，如果某些内容专家已经在独立、可靠的出版机构发表过相关專業領域的个人作品，并且受到社会的普遍认可，那么其在相关專業領域的自行发表的内容也可能相对可靠。 編者仍需谨慎使用这类来源：一方面专栏的内容可能涉及作者个人观点，新闻媒体对专栏的事实核查也可能相对宽松，应该辨析专栏文章中的观点与事实，避免将作者的观点作为事实引用；另一方面，如果专家自行发表的内容值得发表，那麼可能已经有人做了相同的工作，存在独立第三方验证的可靠来源可以替代。 个人出版物不能作为有关在世人物的独立第三方来源，即便其作者是著名的职业调查员或作家。

說明

1. 第一句和第二句合并，前面半句为原因，「业务通讯」不知所指何物，因此删除归类到类似来源，同时原文「為了滿足虛榮心所發行的刊物」确系「自费出版商」英语Vanity Presses的误译，按ENWP似乎自费出版和自行出版在英美属于平行关系；

2. 「特例」同时参照en:WP:NEWSBLOG和en:WP:SPS以及现有内容进行修改，前一段中文中没有WP:NEWSBLOG，后一段WP:SPS也已经存在相似论述。（@YFdyh000、HTinC23：WP:V原文如下「但在某些情形下，个人出版物亦仍可以被接受。例如，出版人为受到肯定的专家，从事与条目主题相关领域的工作，并曾在可靠的第三方出版物中发表过該領域工作的文章。但是，此类来源的使用需要谨慎，并且如果有關信息的确值得记载，很可能已有他人做了相同的工作。」）

3. 最后一句补充自ENWP，en:WP:RS中称作「independent sources」，en:WP:V中称作「third-party sources」，统一为「独立第三方来源」。

WP:GUNREL是什么的缩写（Generally Unreliable?），我不清楚其是否对应ENWP的en:WP:RS/SPS，目前尽量保持两段SPS概述一致。最后想问一句是否存在共识删除WP:評估可靠性，将其归纳到WP:RS前面的「评估来源」一段，因为这应该也是先后翻译时间不同导致的同一段落重复问题，并且已有编者（@MilkyDefer：）指出这一段翻译水准不高。

以上。--Cat on the Mars 2022年9月11日 (日) 15:00 (UTC)

(＋)强烈支持--唔好阻住我愛國（留言） 2022年9月24日 (六) 06:27 (UTC)

@CatOnMars：

「社會的普遍認可」定義？--唔好阻住我愛國（留言） 2022年10月2日 (日) 15:29 (UTC)

原文是established，这个词比较重，韦氏解释是「 accepted and recognized or followed by many people」，综合上下文应该是指已经获得媒体或学术引用，或者有专业人士充分肯定。----Cat on the Mars 2022年10月3日 (一) 09:11 (UTC)

公示案其一

（A:WP:GUNREL總言變更）任何人都可以建立网页、自行出版或自称专家，自行发表的来源往往未经任何事实核查，缺乏独立第三方评审，因此绝大多数个人出版物、个人网站、博客、开放性wiki、网络论坛或社交媒体上的贴文以及其它类似来源通常不是可接受的来源。

不过也有一些特例，例如一些新闻媒体会以博客指代其网络专栏，如果专栏作者为专业人士其内容可能相对可靠；此外，如果某些内容专家已经在独立、可靠的出版机构发表过相关專業領域的个人作品，并且受到社会的普遍认可，那么其在相关專業領域的自行发表的内容也可能相对可靠。

編者仍需谨慎使用这类来源：一方面专栏的内容可能涉及作者个人观点，新闻媒体对专栏的事实核查也可能相对宽松，应该辨析专栏文章中的观点与事实，避免将作者的观点作为事实引用；另一方面，如果专家自行发表的内容值得发表，那麼可能已经有人做了相同的工作，存在独立第三方验证的可靠来源可以替代。

个人出版物不能作为有关在世人物的独立第三方来源，即便其作者是著名的职业调查员或作家。

（B:由A修正案並行，同時廢止WP:WIKISRC章節全部內容及超鏈接，全由A案之WP:GUNREL條文適用）

--唔好阻住我愛國（留言） 2022年10月4日 (二) 11:29 (UTC)

基於@CatOnMars版本進行 公示，公示7日。

@Longway22 @User:Steven_Sun@AINH@Kriz Ju@YFdyh000--唔好阻住我愛國（留言） 2022年10月4日 (二) 11:39 (UTC)

可否將廢除WP:WIKISRC章節全部內容及超鏈接之提案一併公示--約克客（留言） 2022年10月4日 (二) 13:49 (UTC)

@Longway22：

麻煩協助。--唔好阻住我愛國（留言） 2022年10月4日 (二) 13:52 (UTC)

已添加並行案，按UTC時間記錄為準--約克客（留言） 2022年10月4日 (二) 14:01 (UTC)

添加新定義，由現在重新公示。--唔好阻住我愛國（留言） 2022年10月5日 (三) 03:07 (UTC)

鑑於下方亦有相當多補充探討個案情況，認為需要延長議案審定及修正等之週期，建議再暫停公示為先。對下方情況看可能一些細節可再斟酌，並或需再進行分段討論。--約克客（留言） 2022年10月7日 (五) 10:15 (UTC)

技術探討

@Xiplus：我想問一下如果這修正案通過後，建立「使用者生成內容來源佈告版」並於該佈告版尋求個別媒體的共識，還是於ref直接列出其擔保資格。哪個方案較容易讓管理員管理wiki?--唔好阻住我愛國（留言） 2022年10月7日 (五) 11:49 (UTC)

管理員不負責管理wiki。--Xiplus#Talk 2022年10月7日 (五) 12:11 (UTC)

用錯了詞語，應使用「來源回退破壞」、「Abuse filter warning」、「添加不可靠來源」--唔好阻住我愛國（留言） 2022年10月7日 (五) 13:04 (UTC)

@HK5201314：根本看不懂你在問什麼，看了提案內容，沒看到什麼需要管理員介入的東西，後面補了這三個詞彙，是要問過濾器的事？--Xiplus#Talk 2022年10月11日 (二) 13:02 (UTC)

Yes，因為需要設立新佈告版、過濾器規則，看看可行性多大？--唔好阻住我愛國（留言） 2022年10月11日 (二) 13:48 (UTC)

過濾器是要？警告/禁止特定連結嗎？現在WP:RSN結案的處理方式之一不就是過濾器/連結黑名單嗎？還是要問其他的？--Xiplus#Talk 2022年10月11日 (二) 15:07 (UTC)

警告，詳細請看下方。簡單來說是對所有使用者生成內容添加使用警告。--唔好阻住我愛國（留言） 2022年10月11日 (二) 15:15 (UTC)

那跟WP:RSN程序有何不同嗎？如果沒有的話，在使用過濾器上面就沒有問題。--Xiplus#Talk 2022年10月11日 (二) 16:07 (UTC)

首先，cite模版新增一參數「user」，值是由佈告版提供的編號

比方說：

如果編輯者cite Facebook ，user沒有參數，編輯記錄提示列出

「沒有共識的使用者生成內容」

如果編輯者cite Facebook ，user有參數，編輯記錄提示列出

「有共識的使用者生成內容」。--唔好阻住我愛國（留言） 2022年10月11日 (二) 16:21 (UTC)

别改cite，单独建立一个标识模板就可以。目前来说，建立流程共识也许比过滤器等技术手段更优先。--YFdyh000（留言） 2022年10月11日 (二) 16:27 (UTC)

認同，如果未通過，則紙上談兵，不過只是技術探討。

新加cite user 模版？--唔好阻住我愛國（留言） 2022年10月11日 (二) 16:30 (UTC)

是要单弄一套cite？我觉得弄个标识模板指向讨论/状态说明页就好，放在ref标签内或外，cite保持原样。命名都可以，像是{{Verified UGC}}或{{checked UGC}}。--YFdyh000（留言） 2022年10月11日 (二) 16:37 (UTC)

新建布告板的目的是？Wikipedia:可靠来源/布告板或其子板块会否更好。我不理解并且认为“担保资格”效力欠缺共识，虽然设法提供/列明可能是有益的。--YFdyh000（留言） 2022年10月7日 (五) 13:13 (UTC)

意見商討

先卡一個(－)反对。由於HK5201314（唔好阻住我愛國）在孤獨搖滾！的編輯摘要中說「不能引用社交媒體網站」再支持條目中有關播映平台的內容，有違我對WP:ABOUTSELF的認知。希望有人可以釐清一下。－hiJK910 ^{走先喇 係咁先喇 下次再玩吖} 2022年10月4日 (二) 13:18 (UTC)

@Hijk910：請望一望上方就「社會的普遍認可」的定義，再看看你的來源是否符合定義。--唔好阻住我愛國（留言） 2022年10月4日 (二) 13:25 (UTC)

請不要ping我。請問這個我加進去的Facebook來源在你看來，可以加進去嗎？為甚麼可以/不可以呢？－hiJK910 ^{走先喇 係咁先喇 下次再玩吖} 2022年10月4日 (二) 13:28 (UTC)

根據定義，相關來源需「獲得媒體或學術引用，或者有專業人士充分肯定。」，意指「擔保制」。請問這個專頁有沒有得到acg專家肯定或被現時在可靠來源列表的媒體引用？--唔好阻住我愛國（留言） 2022年10月4日 (二) 13:37 (UTC)

曼迪傳播是業界人士、《孤獨搖滾！》的代理商，在你看來算不算ACG專家？－hiJK910 ^{走先喇 係咁先喇 下次再玩吖} 2022年10月4日 (二) 13:40 (UTC)

WP:Source指出「維基百科的條目應該依靠於可靠的、第三方的、公開的來源。」

先不論是不是ACG專家，Facebook並不是公開的來源，因為必須登入才能閱讀內裏的貼文。

.

另外，關於「ACG專家」的問題，由於這個專頁沒有得到Facebook認證或暫未望到有官網認證，所以無法確認這個專頁是不是屬於曼迪。--唔好阻住我愛國（留言） 2022年10月4日 (二) 13:50 (UTC)

1. 雖然我沒有登入，但是我也看到內容。2. 「需要登入」不等於不是「公開」；正如你要付錢申請圖書證才能借到書，給錢才能買到書一樣，這並不代表那項資料不公開。3. 曼迪傳播的官方網站有連到這個Facebook的連結（而且我是第二次跟你講這件事）。因此，這個Facebook專頁是曼迪的。所以我再問你一次：請問這個我加進去的Facebook來源在你看來，可以加進去嗎？為甚麼可以/不可以呢？－hiJK910 ^{走先喇 係咁先喇 下次再玩吖} 2022年10月4日 (二) 13:57 (UTC)

應該是考慮可替代度的問題吧？這裡如果討論起不同資料之情況，即應是對多個來源做比較，且可驗證度、公開度、可信度和專業度等等都應該一併作研判來決定在編輯當期時適切使用之基準。可能的話也要看共議時之參與度和協作度等等，也許這些可以作為建議性內容列入有關條文之中，即繼續引導使用者時刻注意到有關特定採編擔保之基礎。--約克客（留言） 2022年10月4日 (二) 14:10 (UTC)

暫時可以找到的，都只有第一手資料。以上面《孤獨搖滾！》為例子，要不就是代理商的Facebook帖文（嗯，甚至官方網站本身都沒有寫），要不就是播放平台本身（我不喜歡這個選項，複數播放平台會有腳註炸彈的問題，而且未必標明首播日期時間）。因此，請問這個Facebook來源可以用嗎？－hiJK910 ^{走先喇 係咁先喇 下次再玩吖} 2022年10月4日 (二) 14:21 (UTC)

「曼迪傳播的官方網站有連到這個Facebook的連結」，這句說話不應只跟我說，而應在ref中表達出來。如果沒有標示「擔保來源」，按照新規只會當作一般粉絲專頁處理，予以回退。--唔好阻住我愛國（留言） 2022年10月4日 (二) 14:25 (UTC)

你有很大的誤會——沒有規定要在條目中證明來源本身的可靠度，正如條文中「一些新聞媒體會以博客指代其網絡專欄」，也不需要在條目中給出證明。另外，很高興你承認了這個Facebook來源是可靠的。順帶一提，如果你想增加「標示擔保來源」這項要求，我第一個反對。－hiJK910 ^{走先喇 係咁先喇 下次再玩吖} 2022年10月4日 (二) 14:33 (UTC)

因為新規將絕大部份社交媒體列入不可接受的來源，你若要繞過這限制，必須證明如何受到社會的普遍認可。若然沒有證明，相關來源則無法進入「一些新聞媒體會以博客指代其網絡專欄」段落。--唔好阻住我愛國（留言） 2022年10月4日 (二) 14:40 (UTC)

但是「必須證明如何受到社會的普遍認可」不需要在條目中進行。－hiJK910 ^{走先喇 係咁先喇 下次再玩吖} 2022年10月4日 (二) 14:42 (UTC)

：若不在條目中進行，在哪進行？

另外，針對博客的問題，WP的方針是指出博客內容只屬個人意見。--唔好阻住我愛國（留言） 2022年10月4日 (二) 14:46 (UTC)

其實呢，WP:RSP只是一個歸納共識的地方。「若不在條目中進行，在哪進行？」不就是各種討論頁嗎？XD

現在你和我同意了這個Facebook專頁就是曼迪傳播的專頁，至少你就不能借故「當作一般粉絲專頁處理，予以回退」——因為你我已達成共識。－hiJK910 ^{走先喇 係咁先喇 下次再玩吖} 2022年10月4日 (二) 14:56 (UTC)

我的立論和結論是：1. 曼迪傳播等動畫代理商是「獲得媒體或學術引用，或者有專業人士充分肯定」中的「專業人士」，2. 若這些代理商的官方網站可以連到其社交媒體，則視為對這些社交媒體的擔保。3. 結論，代理商的社交媒體可用作「播放平台、日期時間」的參考資料。另外，證明這些社交媒體屬於代理商的理據並不需要在條目中列出。－hiJK910 ^{走先喇 係咁先喇 下次再玩吖} 2022年10月4日 (二) 14:56 (UTC)

執行共識的是管理員，很歡迎你隨便ping一位管理員，問一問他接不接受這個結論。

.

這個共識你知我知，但第三者不會知，不排除有其他只按照方針指引的編輯者予以回退，相關回退我會予以支持。

.

如果將這個結論推至其他來源，有需要展開新的佈告版，結構就像可靠來源佈告版一樣，需要等待至少一個月才知道這個內容可不可以使用。所以在條目中證明是高效的。--唔好阻住我愛國（留言） 2022年10月4日 (二) 15:07 (UTC)

1. 不是「執行共識的是管理員」，執行這個共識的是你和我。管理員的工作是「確保共識有好好地獲得執行」。2. 我是覺得沒有人會特別質疑「這個是不是曼迪的Facebook專頁」啦，一般人應該有常識。如果有第三個人質疑這個是不是「曼迪的Facebook專頁」，那討論一下就是了。如果有很多「第三個人」，可以考慮加指引。3a. 不過，因為暫時只有你有這麼特別的質疑，所以我先封住「HK5201314（唔好阻住我愛國）會回退這類編輯」這個選項吧。3b. 因此，我希望將共識擴展至所有動畫代理商——「官方網站有連去」就可以證明這些社交媒體是它們的，視為對這些社交媒體的擔保，亦因此所有代理商官方網站有連去的官方社交媒體都可用作「播放平台、日期時間」的參考資料。4. 我覺得這個問題不需要再浪費你我更多的時間。－hiJK910 ^{走先喇 係咁先喇 下次再玩吖} 2022年10月4日 (二) 15:17 (UTC)

(※)注意：我是在確認新條文會否影響我的編輯，主要就是「所有代理商官方網站有連去的官方社交媒體都可用作『播放平台、日期時間』的參考資料」的部份，因此並非如你所言是無關的。只要你承認你在孤獨搖滾！條目的編輯摘要的發言（完全不能引用社交媒體網站）是有誤的，而且保證不會因為新條文生效而去移除這些內容的話，那我就可以放心了。－hiJK910 ^{走先喇 係咁先喇 下次再玩吖} 2022年10月4日 (二) 16:10 (UTC)

我不會保證，亦不排除有第三者基於新方針而移除內容。--唔好阻住我愛國（留言） 2022年10月4日 (二) 16:23 (UTC)

現時計劃，舊連結暫時保留，直至有人轉移來源。

但新連結會按照新方針工作，需要詳細列明誰擔保了這個專頁。如新連結不按照新方針列明所需資料，不排除有其他編輯者舉報(破壞)或回退，即管看看管理員如何演繹新方針。--唔好阻住我愛國（留言） 2022年10月4日 (二) 16:28 (UTC)

我還在反對不能釋除我疑慮的新條文喔。請你反駁我上面的理據：1. 曼迪傳播等動畫代理商是「獲得媒體或學術引用，或者有專業人士充分肯定」中的「專業人士」，2. 若這些代理商的官方網站可以連到其社交媒體，則視為對這些社交媒體的擔保。3. 結論，代理商的社交媒體可用作「播放平台、日期時間」的參考資料。如果你不能反駁，我視之為你同意我的立論，並達成共識。－hiJK910 ^{走先喇 係咁先喇 下次再玩吖} 2022年10月4日 (二) 16:33 (UTC)

1及2同意，3不同意。因為3有更好的來源可以取代，如EPG及播放清單。--唔好阻住我愛國（留言） 2022年10月4日 (二) 16:53 (UTC)

另外，明明上面有段這樣的提議條文：「部分社交平台帳號可以透過包括但不限於平台的帳戶認證或其他方式來證明某社交媒體帳號代表現實中的特定個人或組織。」為甚麼不見了？－hiJK910 ^{走先喇 係咁先喇 下次再玩吖} 2022年10月4日 (二) 16:33 (UTC)

請向@Longway22、@CatOnMars了解。--唔好阻住我愛國（留言） 2022年10月4日 (二) 16:47 (UTC)

這個應確為原案其一項擔保條件，或應附加回現案當中。--約克客（留言） 2022年10月7日 (五) 10:18 (UTC)

最後，從來都沒有規定「需要詳細列明誰擔保了這個專頁」，沒有條目會標示着WP:RSP或是其他的方針指引。我在上面已經解釋：WP:RSP只是一個歸納共識的地方。「若不在條目中進行，在哪進行？」就是在各種討論頁。在討論頁記錄着得出共識的討論就可以了。－hiJK910 ^{走先喇 係咁先喇 下次再玩吖} 2022年10月4日 (二) 16:33 (UTC)

我不會阻止你等待至有共識才列出來源。--唔好阻住我愛國（留言） 2022年10月4日 (二) 16:50 (UTC)

閣下是否認同再於修正案內列明「對於不同的特定個案，如該章節條文未能涵蓋其相關特定情況，應遵循該版整體指引精神及其他專業知識內容等，討論判讀為來源提供擔保之條件是否適切而無礙編輯採信，同時參考既有歸納的不同個案及特定擔保情況、完備相應共議商定之基礎。」？--約克客（留言） 2022年10月7日 (五) 10:23 (UTC)

(＆)建議 “、或自称专家”。以及我想确认，“个人出版物”是由个别人完成出版主要流程（如撰稿、编审）的出版物，语出个人（如采访、自述）但经历可靠流程的出版物不是个人出版物，应以其他角度衡量可靠性。个人或小团体编撰后交由正式出版社发行的书籍，可能需个案辨别可靠性。“个人出版物不能作为有关在世人物的独立第三方来源”该如何理解？仍可能是观点的可靠来源，但不应是事实查核的可靠来源。--YFdyh000（留言） 2022年10月4日 (二) 13:24 (UTC)

(＆)建議按照論述的話，可能可以再清晰化有關「擔保」條件之體系作為該判讀之前設，即約定是具備擔保條件之純粹個人自行出版標的物、在列明後續接回有關約定之舉例說明；對於在生人士之限制條件必須同等加註之「即使合乎擔保條件」、而不能單一/唯一作為獨立第三方來源使用，而參照有關常規必需多個獨立來源並行使用。--約克客（留言） 2022年10月4日 (二) 13:47 (UTC)

@Longway22：

只有獲「社會的普遍認可」才具備擔保條件：相關專頁指已經獲得媒體或學術引用，或者有專業人士充分肯定。

.

應該會使用notetag功能表示在相關文字上。--唔好阻住我愛國（留言） 2022年10月4日 (二) 16:08 (UTC)

「社會的普遍認可」一詞執行起上來會容易引起爭拗。例如如果相關專頁曾接受媒體專訪或訪問[5][6]，這會否是「社會普遍認可」？又例如，知名人士（如議員）的專頁，又是否符合「社會普遍認可」？ThirdThink（留言） 2022年10月5日 (三) 02:21 (UTC)

因為是要證明這個專頁是屬於相關人士，由於2號TVB的來源不是直接引用專頁帖文(記者會形式)，所以無法證實相關專頁的擁有人。除非相關報導有提供引用的帖文連結。

1號明報的來源只是個人專訪，並沒有引用專頁提供的數據。

.

而關於知名人士的專頁，請查看上方就曼迪的討論。應該有不少的來源證明，如被政府肯定（電話簿）或被現時在可靠來源列表的媒體引用，甚至乎相關帳號有認證。--唔好阻住我愛國（留言） 2022年10月5日 (三) 02:49 (UTC)

第一段：「任何人都可以建立網頁、自行出版或自稱專家，自行發表的來源往往未經任何事實核查，缺乏獨立第三方評審，因此絕大多數個人出版物、個人網站、博客、開放性wiki、網絡論壇或社交媒體上的貼文以及其它類似來源通常不是可接受的來源。」

.

至少要證明相關專頁曾受第三方評審才能被引用。--唔好阻住我愛國（留言） 2022年10月5日 (三) 02:53 (UTC)

來源1有用截圖引述相關專頁的數據啊。「關注組經常在社交平台發帖，......（從略）」，「團隊亦會為交通服務規劃進行倡議，......（從略）」。ThirdThink（留言） 2022年10月5日 (三) 06:42 (UTC)

@Fran1001HK 囧rz……@ThirdThink：應該還有其他來源可以證實其專業資格，如沙田交通關注組主席是現時的公眾人物。--唔好阻住我愛國（留言） 2022年10月7日 (五) 11:54 (UTC)

(！)意見，我最近没有空参与讨论了，所以就三件事表达一下观点：第一点，回答U:YFdyh000的问题，首先个人出版物是专有名词，实际上专业出版社也有可能承接自费出版业务，主要差异还是在于编辑审核的流程；第二点，还是U:YFdyh000有关生者传记的问题，WP:生者传记已经规定不论批评还是赞美的观点都需要出自可靠来源，个人出版物的观点无论如何都不是生者传记观点的可靠来源，这是方针一致性要求；第三点，即便放在现有的方针里，存在更好来源或者可替代也不是删除已有相对可靠来源的理据，新的提案也没有强制在存在可替代来源的时候一定要使用更好来源，如果编者认为存在更好来源，应该自己举证并替代，原则上条目大部分内容应该是由可靠来源构成，比方facebook来源如果无法得到第三方证实可靠性则不应该用于构成条目的主要事实。以上。--Cat on the Mars 2022年10月5日 (三) 16:16 (UTC)

“个人出版物的观点无论如何都不是生者传记观点的可靠来源”，比如A的（出版自传/采访/博客）中包含对B的评价或者生平信息，是否都绝不能作A的观点或B的事实（声称）来引述，具体可靠性如何，我感觉要依情况商榷，难以一言概之。--YFdyh000（留言） 2022年10月6日 (四) 03:38 (UTC)

如對此句有任何問題，煩請你於下方另開新節提議修改WP:SPS(來自WP:生者傳記)。--唔好阻住我愛國（留言） 2022年10月7日 (五) 03:01 (UTC)

公示案其一（修正4）

（A:WP:GUNREL總言變更）任何人都可以建立网页、自行出版或自称专家，自行发表的来源往往未经任何事实核查，缺乏独立第三方评审。由於绝大多数个人出版物、个人网站、博客、开放性wiki、网络论坛或社交媒体上的贴文以及其它类似来源通常不是可接受的来源。因此所有使用者生成內容來源會被列入防濫用過濾器。

不过也有一些特例，例如一些新闻媒体会以博客指代其网络专栏，如果专栏作者为专业人士其内容可能相对可靠；此外，如果某些内容专家已经在独立、可靠的出版机构发表过相关專業領域的个人作品，并且受到社会的普遍认可，那么其在相关專業領域的自行发表的内容也可能相对可靠。

編者仍需谨慎使用这类来源：一方面专栏的内容可能涉及作者个人观点，新闻媒体对专栏的事实核查也可能相对宽松，应该辨析专栏文章中的观点与事实，避免将作者的观点作为事实引用；另一方面，如果专家自行发表的内容值得发表，那麼可能已经有人做了相同的工作，存在独立第三方验证的可靠来源可以替代。

由於絕大部份的使用者生成來源通常不是可接受的來源，編者使用相關來源前應到佈告版尋求共識，確定相關來源是否符合要求。若相關來源未在使用者生成內容布告板獲得共識，編者有責任在條目的合適位置或討論頁展示相關來源的擔保資格。未進行來源證明的內容可能會在沒有事先通知的情況下被他人移除。被移除的內容若能發現有效的補充材料，則可重新加入。請注意，所有使用者生成內容只能當作第一手資料，不論發佈人的身分及機構。

个人出版物不能作为有关在世人物的独立第三方来源，即便其作者是著名的职业调查员或作家。

（B:由A修正案並行，同時廢止WP:WIKISRC章節全部內容及超鏈接，全由A案之WP:GUNREL條文適用）

解釋（修正1）： 「由於絕大部份的使用者生成來源都是不是可接受的來源，編者使用相關來源前應到佈告版尋求共識，確定相關來源是否符合要求。」

• 現時可靠來源佈告版非強制使用，只是提供參考。而提議新建的佈告版是強制性使用，採取白名單制度。
• 考慮到上方動畫制作商及交通關注組的問題，部分機構依賴社群媒體作唯一官網，建立佈告版可讓編輯者確定相關網站是否真確及提供商確空間。
• 使用佈告版可減少重複提供擔保來源，減低編者多次使用重複來源的不便。

以上--唔好阻住我愛國（留言） 2022年10月7日 (五) 13:40 (UTC)

認為仍應適用以參考性質非強制性質，單一化名單制可能僅適合於對內容農場等平台標註、但不應作為對所有個人性質之一致規制化，應個人（專業）身份之變化等亦可能隨時發生並無法先驗其所有言論皆無法採信、有關名單或亦引致有違對個人觀點之推定原則；來源擔保條件之個例情形、適宜以個案不同情況判讀並加以釐清，故而討論專版如設立則應為加強專案協作及共議之機制、而非強化一致化規制--約克客（留言） 2022年10月8日 (六) 01:54 (UTC)

同约克客观点，不认为应该为布告板附加特殊效力。--Yinyue200（留言） 2022年10月8日 (六) 03:12 (UTC)

既然樓主指出「部分機構依賴社群媒體作唯一官網」，現在先把所有用戶生成內容來源會列入黑名單，然後在討論一番後又請示機械人解除相關專頁的黑名單限制，那「把所有用戶生成內容列入黑名單」整個操作不覺得有太大意義。ThirdThink（留言） 2022年10月8日 (六) 06:31 (UTC)

回應fran1001hk：理論上，獲豁免的使用者生成內容只是極少數，可能是億份之一，添加強制性佈告版是讓編者思考有沒有其他可靠的第二或第三級來源可取代。

.

回應longway22及yinyue200：是否應更改至「建立「使用者生成內容來源佈告版」並於該佈告版尋求個別媒體的共識，或於ref直接列出其擔保資格。」讓編者二選其一申報來源？--唔好阻住我愛國（留言） 2022年10月8日 (六) 07:08 (UTC)

@Hijk910：

換句說話來說，使用佈告版的可能每隔數年申報一次擔保資格，而直接於ref列出擔保來源的每一次也要申報。

這樣就減低布告板的特殊效力。--唔好阻住我愛國（留言） 2022年10月8日 (六) 07:13 (UTC)

如果真是希望編者思考有沒有其他可靠的第二或第三級來源可取代，設立相關過濾器（但不作用黑名單禁用相關來源）在寫手儲存編輯前提醒他們會較有效。ThirdThink（留言） 2022年10月8日 (六) 07:44 (UTC)

我也觉得过滤器方案比较好，这样也与当前的惯例相差不大。合理的编辑并不会因为是否事先履行了某些手续就变得合理或者不合理，维基百科不是官僚机构。--Yinyue200（留言） 2022年10月8日 (六) 08:56 (UTC)

可以使用提示版機制輔助編輯者判讀，並且佈告板機制亦可更靈活，以體現共識商議之慣常理路。--約克客（留言） 2022年10月8日 (六) 09:00 (UTC)

@Longway22@ThirdThink@Yinyue200

已按你們的要求更新。--唔好阻住我愛國（留言） 2022年10月8日 (六) 14:09 (UTC)

我仍然认为在“于来源引用中标示相关来源的担保资格”不太合理。我的建议是这样写：若相关来源未（在布告板）获得共识，编者应在条目的合适位置或讨论页体现出相关来源的担保资格。未进行标示的内容可能会被他人移除。被移除的内容若能发现有效的补充材料，则可重新加入。--Yinyue200（留言） 2022年10月10日 (一) 15:16 (UTC)

@Yinyue200：

已按要求修改。--唔好阻住我愛國（留言） 2022年10月11日 (二) 10:21 (UTC)

備註內時限之所謂三年是如何依據而設定？另外內文所有可接受之否定前設表述認為適宜使用「通常不是」，以合乎有關行文之商定檢視要求。--約克客（留言） 2022年10月11日 (二) 10:50 (UTC)

@Longway22：三年是基於WP:可靠來源佈告版，超過3年就自動列入「陳舊討論」。如果要改3年限期，可能要連同可靠來源佈告版指引一併修改。--唔好阻住我愛國（留言） 2022年10月11日 (二) 11:02 (UTC)

「該來源已有兩年未在可靠來源佈告板上討論，來源也可能隨著時間的推移，已出現新的變化，因此最近的共識可能會改變，因此需要重新討論，以形成更準確的評估。然而不包括被認為是通常不可靠的自行出版或呈現使用者生成的內容的來源，也不包括來源自身性質本身不會隨時間而變化的出版物或其他固定性質的媒體，也不包括已經結束出版的來源。」--唔好阻住我愛國（留言） 2022年10月11日 (二) 11:05 (UTC)

然而可靠来源布告板并未有其强制性。--Yinyue200（留言） 2022年10月11日 (二) 11:54 (UTC)

如果將上方的「3年」改為WP:CCC又如何？

而3年要求改為只是佈告版建議而不強制執行？--唔好阻住我愛國（留言） 2022年10月11日 (二) 13:45 (UTC)

@Longway22：已按要求更新。--唔好阻住我愛國（留言） 2022年10月12日 (三) 02:09 (UTC)

防濫用警告器內容(修正3)

使用者生成內容使用條件：注：不適用开放性wiki、网络论坛及與上述相關的社群網站

• 相關內容無法由其他更為可靠的來源替代
• 能辨認帳號持分者的身分（社群媒體的身分認證也接受）
• 帳號持有人/機構/受訪對象須達到WP:關注度要求
• 只接受與帳號持有人/機構相關專業領域的內容
• 以下二選一
  • 如相關帳號不屬任何機構，帳號需在指定狀況 （ref 至 上方文章）內獲得媒體或學術引用，或被專業人士充分肯定。过旧的证据可能不被考虑。（需要提供證明）
  • 如相關帳號屬於某機構／個人，需以其他官方或可靠第三方的形式展示帳號持有人的資歷/身分。（需要提供證明）

說明：上方四點必須遵守，缺一不可。下方二選其一。--唔好阻住我愛國（留言） 2022年10月8日 (六) 14:29 (UTC)

@CatOnMars@Longway22@User:Steven_Sun@AINH@Kriz Ju@YFdyh000@ThirdThink@Hijk910：Any question？If not，繼續公示--唔好阻住我愛國（留言） 2022年10月10日 (一) 11:07 (UTC)

「帳號需於「某年份」內獲得媒體或學術引用」，何謂「某年份」？「某年份」是指何年至何年？另外，「需以其他官方的形式展示帳號持有人的資歷／身分」中的「官方」建議改為「官方或可靠第三方」。ThirdThink（留言） 2022年10月10日 (一) 11:59 (UTC)

「某年份」正是要商確，相關年份需平衡可行性及時效性。請問有什麼建議？--唔好阻住我愛國（留言） 2022年10月10日 (一) 12:05 (UTC)

我觉得不适宜在这里订一些很硬性的规定，这类过于客观的标准很难覆盖所有情况，我觉得可以直接删除“某年份”的表述：如相关账号不属任何机构，账户需获得过媒体或学术引用，或被专业人士充分肯定。过旧的证据可能不被考虑。--Yinyue200（留言） 2022年10月10日 (一) 15:06 (UTC)

(－)反对任何硬性規定，例如一些YouTuber對條目當事人訪問等理應可作為第一手來源，但如果根據上述規定亦被排除在外-某人✉ 2022年10月10日 (一) 20:21 (UTC)

@AINH：請問你有沒有望清楚公示內容？--唔好阻住我愛國（留言） 2022年10月11日 (二) 09:55 (UTC)

我說的情境符合你的內容嗎？訪問條目當事人算是「專業內容」嗎(第四點)？而且不少Youtuber不見得將真實身份公開啊(第二點)-某人✉ 2022年10月11日 (二) 10:02 (UTC)

如果是訪問型youtuber ，其專業當然是訪問。如果是演藝型YouTuber ，其專業當然是演藝類。--唔好阻住我愛國（留言） 2022年10月11日 (二) 10:24 (UTC)

然而第二点您未解答，我觉得您提出草案的问题在于内容太过僵硬，用词太过绝对，不适宜广泛推广。现有方针很少有用词如此绝对的条文。--Yinyue200（留言） 2022年10月11日 (二) 11:56 (UTC)

其實我傾向直譯英維「NO」。

回應第二點，我沒有提議公開真實身分，只是要求能辨認是「誰」發出相關資料。基本上YouTuber 可無視此句，而Vtuber就不可以。--唔好阻住我愛國（留言） 2022年10月11日 (二) 13:41 (UTC)

正確來説這句出現的主要目的是過濾「秘密網」及「街訪（隨便捉一個路人分享個人看法）」。--唔好阻住我愛國（留言） 2022年10月11日 (二) 13:52 (UTC)

确实一般应当过滤“街访”--Yinyue200（留言） 2022年10月11日 (二) 15:59 (UTC)

我想引用這個編輯爭議(Wikipedia:管理员布告板/编辑争议#Foodsfoods)，如果這方針生效，此人應該不能添加fb群組連結，因為會違反新方針。本次提議只是減少同類事情發生的機會，如對同類事情有什麼預防措施，歡迎提出。--唔好阻住我愛國（留言） 2022年10月11日 (二) 14:53 (UTC)

(！)意見：以我自己的认知，满足前四条中的二、三和四条的时候，通常这个来源已经没法算作“用户生成内容”了。例如本身被视作可靠来源的传统媒体，其在社交平台经认证发布的属于新闻报道文体的文章，归入用户生成内容就不合适。但同样的一家媒体的评论员，以媒体账号在同样的平台发布的社论性质的文章，则又不宜。这其中的区别并不在于账户持有者的身份。二选一中的第一条满足的时候，引用它的媒体或学术来源就会应该就是替代来源，会自动让第一条不成立。(＆)建議：第一条的措辞可考虑修改为“相关内容无法由其他更为可靠的来源替代”，明确替代来源应该往什么方向寻找。--Tiger（留言） 2022年10月11日 (二) 15:43 (UTC)

謝謝您指點--唔好阻住我愛國（留言） 2022年10月11日 (二) 16:33 (UTC)

簡單回應:

綠色：已成定案，沒有顏色：仍有爭議

（A:WP:GUNREL總言變更）任何人都可以建立网页、自行出版或自称专家，自行发表的来源往往未经任何事实核查，缺乏独立第三方评审。由於绝大多数个人出版物、个人网站、博客、开放性wiki、网络论坛或社交媒体上的贴文以及其它类似来源通常不是可接受的来源。因此所有使用者生成內容來源會被列入防濫用過濾器。

不过也有一些特例，例如一些新闻媒体会以博客指代其网络专栏，如果专栏作者为专业人士其内容可能相对可靠；此外，如果某些内容专家已经在独立、可靠的出版机构发表过相关專業領域的个人作品，并且受到社会的普遍认可，那么其在相关專業領域的自行发表的内容也可能相对可靠。

編者仍需谨慎使用这类来源：一方面专栏的内容可能涉及作者个人观点，新闻媒体对专栏的事实核查也可能相对宽松，应该辨析专栏文章中的观点与事实，避免将作者的观点作为事实引用；另一方面，如果专家自行发表的内容值得发表，那麼可能已经有人做了相同的工作，存在独立第三方验证的可靠来源可以替代。

由於絕大部份的使用者生成來源都不是可接受的來源，編者使用相關來源前應到佈告版尋求共識，確定相關來源是否符合要求。若相關來源未在使用者生成內容布告板獲得共識，編者有責任在條目的合適位置或討論頁展示相關來源的擔保資格。未進行來源證明的內容可能會在沒有事先通知的情況下被他人移除。被移除的內容若能發現有效的補充材料，則可重新加入。請注意，所有使用者生成內容只能當作第一手資料，不論發佈人的身分及機構。

个人出版物不能作为有关在世人物的独立第三方来源，即便其作者是著名的职业调查员或作家。 （B:由A修正案並行，同時廢止WP:WIKISRC章節全部內容及超鏈接，全由A案之WP:GUNREL條文適用）

社會普遍認可（英文：established，已經獲得媒體或學術引用，或被專業人士（可以包括自己，但要以其他官方的形式展示其資歷。）充分肯定。）

• 如相關帳號不屬任何機構，帳號需曾獲得媒體或學術引用，或被專業人士充分肯定。若使用超過3年的证据，其他編輯者有權連帶相關段落一併移除。
• 如相關帳號屬於某機構／個人，需以其他官方或可靠第三方的形式展示帳號持有人的資歷/身分。

--唔好阻住我愛國（留言） 2022年10月11日 (二) 16:45 (UTC)

已按要求修改。--唔好阻住我愛國（留言） 2022年10月12日 (三) 02:17 (UTC)

(？)疑問：上面有多个讨论的子章节看起来有点像是公式的提案内容，不知先前参与讨论的几位可否澄清目前其中哪些正在公示？--Tiger（留言） 2022年10月11日 (二) 15:43 (UTC)

公示案其一（修正3）及 防濫用警告器內容(修正2)--唔好阻住我愛國（留言） 2022年10月11日 (二) 16:32 (UTC)

已移除“管理员意见”的标题。管理员身份在这里没有也不应该有任何作用，也请不要替我给我的意见加上标签。—Tiger（留言） 2022年10月11日 (二) 21:17 (UTC)

---

現在公示的內容（WP:GUNREL）：

（A:WP:GUNREL總言變更）任何人都可以建立网页、自行出版或自称专家，自行发表的来源往往未经任何事实核查，缺乏独立第三方评审。由於绝大多数个人出版物、个人网站、博客、开放性wiki、网络论坛或社交媒体上的贴文以及其它类似来源通常不是可接受的来源。因此所有使用者生成內容來源會被列入防濫用過濾器。

不过也有一些特例，例如一些新闻媒体会以博客指代其网络专栏，如果专栏作者为专业人士其内容可能相对可靠；此外，如果某些内容专家已经在独立、可靠的出版机构发表过相关專業領域的个人作品，并且受到社会的普遍认可，那么其在相关專業領域的自行发表的内容也可能相对可靠。

編者仍需谨慎使用这类来源：一方面专栏的内容可能涉及作者个人观点，新闻媒体对专栏的事实核查也可能相对宽松，应该辨析专栏文章中的观点与事实，避免将作者的观点作为事实引用；另一方面，如果专家自行发表的内容值得发表，那麼可能已经有人做了相同的工作，存在独立第三方验证的可靠来源可以替代。

由於絕大部份的使用者生成來源通常不是可接受的來源，編者使用相關來源前應到佈告版尋求共識，確定相關來源是否符合要求。若相關來源未在使用者生成內容布告板獲得共識，編者有責任在條目的合適位置或討論頁展示相關來源的擔保資格。未進行來源證明的內容可能會在沒有事先通知的情況下被他人移除。被移除的內容若能發現有效的補充材料，則可重新加入。請注意，所有使用者生成內容只能當作第一手資料，不論發佈人的身分及機構。

个人出版物不能作为有关在世人物的独立第三方来源，即便其作者是著名的职业调查员或作家。

（B:由A修正案並行，同時廢止WP:WIKISRC章節全部內容及超鏈接，全由A案之WP:GUNREL條文適用）

及防濫用警告器內容：

使用者生成內容使用條件：注：不適用开放性wiki、网络论坛及與上述相關的社群網站

• 相關內容無法由其他更為可靠的來源替代
• 能辨認帳號持分者的身分（社群媒體的身分認證也接受）
• 帳號持有人/機構/受訪對象/引用內容須達到WP:關注度要求
• 只接受與帳號持有人/機構相關專業領域的內容
• 以下二選一
  • 如相關帳號不屬任何機構，帳號需在指定狀況 （ref 至 上方文章）內獲得媒體或學術引用，或被專業人士充分肯定。其他編輯者有權移除使用过旧的证据及其相關引用的內容。（需要提供證明）
  • 如相關帳號屬於某機構／個人，需以其他官方或可靠第三方的形式展示帳號持有人的資歷/身分。（需要提供證明）

---

--唔好阻住我愛國（留言） 2022年10月12日 (三) 16:56 (UTC)

兩日內無新發言， 公示7日，由2022年10月16日00:06開始，如無反對則以此文案為最終定案。--唔好阻住我愛國（留言） 2022年10月15日 (六) 16:06 (UTC)

應重新檢視有關時效性之問題，如所謂落差之定性等是否過於寬泛且助長官僚化問題，資歷/身分之定性亦以不同專業認知有別，適宜對相關所謂證明之基礎性問題重新審視，且既已佈告板形式為導向仍應以維基層面之常識共識為主，避免商定導向受相關學術或專業利益所限。--約克客（留言） 2022年10月16日 (日) 02:22 (UTC)

的實際狀況存在重大落差時—>WP:CCC

說得沒有錯， 因為「資歷/身分之定性亦以不同專業認知有別」，所以才需要設立佈告版，按實際需要調整可引用的內容。--唔好阻住我愛國（留言） 2022年10月16日 (日) 02:54 (UTC)

注意結合WP:FORUMSHOP。--約克客（留言） 2022年10月16日 (日) 03:07 (UTC)

意思是？--唔好阻住我愛國（留言） 2022年10月16日 (日) 15:18 (UTC)

按照所謂15日開始自行執行所謂公示程序內實際，認為即使技術計算亦應按照19日計算是否開啟公示，現有議案問題認為根本有遊戲規程之問題，且遺留相當多問題而未有任何匹配之具體方案等產生，認為適宜第三方先行中止議案之通過公示程序及所謂通過宣佈，以重新著重處理討論過程及相關爭議之處裡。--約克客（留言） 2022年10月23日 (日) 07:15 (UTC)

閣下是否對維基共識等有所忽略而操之過急？討論時效衡常以七日為社區共認之客棧議案程序性固定週期--約克客（留言） 2022年10月16日 (日) 02:24 (UTC)

2個月了…--唔好阻住我愛國（留言） 2022年10月16日 (日) 02:54 (UTC)

每次修正後也不是重新計算七日時間嗎，不是說持續久一點就可以突然縮短週期吧--約克客（留言） 2022年10月16日 (日) 03:05 (UTC)

我在說文字內容是最終定案，定了卻無法即時實行，因佈告版及cite功能未到位。--唔好阻住我愛國（留言） 2022年10月16日 (日) 15:11 (UTC)

不支持条文即行生效，我还是认为当前条文的内容和原始条文的风格差异相差太大。原始条文基本上是在阐述一个行事的原则。新的规定则详细的多，尽管相比一开始的提议已经有所改善。我认为这样的提案一旦推行会对当前编辑维基百科的行为产生较大影响，需要凝聚更多共识。--Yinyue200（留言） 2022年10月16日 (日) 08:54 (UTC)

@Yinyue200：

最終定案不等於即時實行，因為還有更多細節需基於上述公示的內容加添，如佈告版細節及cite規範。配套未到位的話如何生效內容？--唔好阻住我愛國（留言） 2022年10月16日 (日) 15:22 (UTC)

一併回覆元上，引用WP:FORUMSHOP「討論將勝於堅持己見」，即有關議案目前共識相信亦為基於該題。--約克客（留言） 2022年10月17日 (一) 01:50 (UTC)

Yes--唔好阻住我愛國（留言） 2022年10月17日 (一) 10:48 (UTC)

註二可以分成註二註三嗎？還是有什麼排版指引推薦註解中用 * 多句描述，可以推薦一下，讓我前去拜讀嗎？--Anghualee（留言） 2022年10月18日 (二) 09:08 (UTC)

註二難以分成註二註三，排版問題。--唔好阻住我愛國（留言） 2022年10月19日 (三) 02:46 (UTC)

“因此所有用户生成内容来源会被列入防滥用过滤器”：过滤器有标签、警告和阻止等处理操作。这个地方没说明白执行何种操作。建议不要一刀切执行阻止操作。

个人建议用户生成内容使用条件不宜有过细的硬性规定。针对特定来源有问题，在布告版或者互助客栈讨论即可。另外Wikipedia:关注度中有讲关注度指引并不直接限制条目内容。不应直接按照关注度的要求来限制来源。--Steven Sun（留言） 2022年10月21日 (五) 08:14 (UTC)

1.warning & label

2.沒有錯，使用關注度要求正是要平衡英維標準及中文區的實際情況，理應引用要求比其他類型的資料高，況且共識建議不強制使用「布告版或者互助客棧討論」。--唔好阻住我愛國（留言） 2022年10月21日 (五) 09:15 (UTC)

原本是建議走「白名單制度」，強制於佈告版達成共識後方可使用。--唔好阻住我愛國（留言） 2022年10月21日 (五) 09:17 (UTC)

不认同白名单制度。--Yinyue200（留言） 2022年10月21日 (五) 13:27 (UTC)

原本！（過去式了）--唔好阻住我愛國（留言） 2022年10月21日 (五) 13:48 (UTC)

———

公示完成，通過！--唔好阻住我愛國（留言） 2022年10月23日 (日) 01:44 (UTC)

閣下這樣是強行通過吧？完全上方各方留言是對之提出各種異議，閣下似乎完全無視規程及共議等方面之意向而徑自宣佈，恐怕需要一併檢視。--約克客（留言） 2022年10月23日 (日) 04:24 (UTC)

冷靜點，上方沒有異議或反對聲音。--唔好阻住我愛國（留言） 2022年10月23日 (日) 07:01 (UTC)

WP:7DAYS：「互助客棧中的提案僅在7日內無新留言時或已討論達30日後，方可在已取得共識的前提下公示。」

本人是基於上述指引進行公示。如有問題，歡迎在下方提議修改。--唔好阻住我愛國（留言） 2022年10月23日 (日) 07:07 (UTC)

閣下要么按照2022年10月19日開始計算七日，不然上邊閣下也是一邊蒐集意見且未能釋除強行走自己程序之問題。請閣下重新考慮表面呈現程序是否適當，暫時不認同有關程序之自行執行，或需第三方判定程序本身技術是否存有瑕疵--約克客（留言） 2022年10月23日 (日) 07:12 (UTC)

@Xiplus：要求䆁法，公示程序問題。--唔好阻住我愛國（留言） 2022年10月23日 (日) 07:14 (UTC)

自10月16日開始，提案未被修改（修正四）。「封鎖」的黑名單在修正三，最後在共識提議後改為「警告及提示」的防濫用過濾器的修正四。--唔好阻住我愛國（留言） 2022年10月23日 (日) 07:20 (UTC)

@Longway22：

即使是19/10開始公示，今日己是25日，7天了，仍然沒有反對聲音。--唔好阻住我愛國（留言） 2022年10月25日 (二) 13:52 (UTC)

一個閣下未有在個人明確提出疑問時，重新計算可能具爭議之聲明，另一個如案內所現，有關異議一直有所提出，但閣下似乎有選擇地單獨回覆及單獨計算，所有異議情況應視為參與商議內對對該案之整體有一致於細節及可行度等方面仍有很多疑問，閣下雖有分項修訂之、但在如議案內當下仍有表述指明可能全案實施之時仍存在全案系統問題，即有關議案並非如閣下自行總結之、並未如實反映當前階段之共議實情，而亦需要所有原案參與人再行檢視為佳。--約克客（留言） 2022年10月25日 (二) 14:03 (UTC)

如果可以的話，希望閣下成為此議題的主導者，以閣下的方式走公示流程。--唔好阻住我愛國（留言） 2022年10月25日 (二) 14:10 (UTC)

@Longway22：--唔好阻住我愛國（留言） 2022年10月25日 (二) 14:11 (UTC)

就“仍然没有反对声音”，那我补充我的观点。新条文“可能”很有参考价值，但是否凝聚广泛共识仍很存疑，所涉来源价值定义的影响会非常广泛，讨论编者的广度和时长、实际效果不显著，没有达到过往的影响全站之政策的程度。个人而言，新条文对细节和流程的规定仍显复杂，与现有常见实践缺乏对比、疑存冲突，实际执行的可行性和公信力仍未显现，未参与讨论的编者未必接受，可靠性讨论也未必能得出可信结论。总结而言，我觉得它是半个指引、一份提案、一篇论述。还请加油，比如提出一些先后对比实例，将所需页面搭好框架、局部试行作参考。改cite模板我是反对的，改滥用过滤器我认为时候未到。--YFdyh000（留言） 2022年10月25日 (二) 14:12 (UTC)

@CatOnMars、Steven_Sun、AINH、Kriz Ju：@YFdyh000、ThirdThink、Hijk910、Tigerzeng：@HTinC23、MilkyDefer、C933103、Yinyue200：謹作為提示有關議案規程性問題，如叨擾還請見諒，皆因如上述之，審視系統實施之時是否可能並未盡共議及仍會擴大系統模糊、導致實際案例採用有所偏頗等。--約克客（留言） 2022年10月25日 (二) 14:21 (UTC)

觀乎上方討論，對於HK5201314閣下希望訂立的新程序（即「擔保制」、「預先尋求共識」、「用戶生成內容使用條件」等），除提案人外似乎未見明確支持，相反更多編者或是反對，或是沒有提出明確的反對但至少有提出其疑慮或有所保留的理由，因此如YFdyh000閣下及Longway22閣下所言，不能認為社群有達成共識，或至少是沒有達成與其對全站造成的影響相應強度的共識。在下認同Steven Sun閣下、AINH閣下、Yinyue200閣下的意見，「不宜有過細的硬性規定」，與現行程序（簡而言之「合則用，不合則刪，爭議藉討論（討論頁或佈告版等）解決」）相比，在下未見新程序的優勢或需要，恐怕新程序會如WP:避免說明氾濫所描述，易被社群視而不見。——$\definecolor {my}{rgb}{0.04,0,0.5}\color {my}{\mathsf {htc_{23}}}$（留言） 2022年10月25日 (二) 23:17 (UTC)

有人（@HTinC23 ）認為本人希望訂立的新程序缺乏共識，我只能回答相關字句都是由各語言的方針、指引及共識抄過來的。

以現行的程序來說，現時可靠來源共識只規管YouTube、Wechat，但不規管Meta、Twitter、Truth Social。是不是缺乏一視同仁？--唔好阻住我愛國（留言） 2022年10月26日 (三) 12:06 (UTC)

個人認為，防濫用過濾器的警告應該反映方針內容，而不應該脫離方針另訂標準，不同標並存會導致新手編者混亂。另外「用戶產生內容」定義上並不應該包括機構或大眾傳媒或政府等在社交平台或其他自行發佈平台所張貼的內容。作為例子，Wordpress是一個被廣泛採用的自行出版平台，但也有很多公司和機構使用Wordpress作為自己的網站發佈內容，將這些公司網站的內容視為「用戶產生內容」顯然為錯誤。——C933103(留言) 2022年10月26日 (三) 12:19 (UTC)

然而，現時社群媒體「容許」使用者模仿 機構或大眾傳媒或政府 建立專頁。

就我所知，Google嘅Blogspot現時在黑名單。由此可見，現時的方針非常模糊。--唔好阻住我愛國（留言） 2022年10月26日 (三) 12:47 (UTC)

存在模仿者並不構成否決特定來源的理由。其他媒介也同樣存在模仿者。且無論社交平台網站站方還是各機構以其他渠道官方發佈的資訊，都能證明特定帳號的身分。——C933103(留言) 2022年10月27日 (四) 12:02 (UTC)

佈告版制度

WP:GUNREL及防濫用警告器內容的實行日期：待佈告版指引完成公示後才生效，現時因配套內容未完成而不能即時生效。

---

已成文的內容（WP:GUNREL）：

（A:WP:GUNREL總言變更）任何人都可以建立网页、自行出版或自称专家，自行发表的来源往往未经任何事实核查，缺乏独立第三方评审。由於绝大多数个人出版物、个人网站、博客、开放性wiki、网络论坛或社交媒体上的贴文以及其它类似来源通常不是可接受的来源。因此所有使用者生成內容來源會被列入防濫用過濾器。

不过也有一些特例，例如一些新闻媒体会以博客指代其网络专栏，如果专栏作者为专业人士其内容可能相对可靠；此外，如果某些内容专家已经在独立、可靠的出版机构发表过相关專業領域的个人作品，并且受到社会的普遍认可，那么其在相关專業領域的自行发表的内容也可能相对可靠。

編者仍需谨慎使用这类来源：一方面专栏的内容可能涉及作者个人观点，新闻媒体对专栏的事实核查也可能相对宽松，应该辨析专栏文章中的观点与事实，避免将作者的观点作为事实引用；另一方面，如果专家自行发表的内容值得发表，那麼可能已经有人做了相同的工作，存在独立第三方验证的可靠来源可以替代。

由於絕大部份的使用者生成來源通常不是可接受的來源，編者使用相關來源前應到佈告版尋求共識，確定相關來源是否符合要求。若相關來源未在使用者生成內容布告板獲得共識，編者有責任在條目的合適位置或討論頁展示相關來源的擔保資格。未進行來源證明的內容可能會在沒有事先通知的情況下被他人移除。被移除的內容若能發現有效的補充材料，則可重新加入。請注意，所有使用者生成內容只能當作第一手資料，不論發佈人的身分及機構。

个人出版物不能作为有关在世人物的独立第三方来源，即便其作者是著名的职业调查员或作家。

（B:由A修正案並行，同時廢止WP:WIKISRC章節全部內容及超鏈接，全由A案之WP:GUNREL條文適用）

及防濫用警告器內容：

使用者生成內容使用條件：

注：不適用开放性wiki、网络论坛及與上述相關的社群網站

• 相關內容無法由其他更為可靠的來源替代
• 能辨認帳號持分者的身分（社群媒體的身分認證也接受）
• 帳號持有人/機構/受訪對象/引用內容須達到WP:關注度要求
• 只接受與帳號持有人/機構相關專業領域的內容
• 以下二選一
  • 如相關帳號不屬任何機構，帳號需在指定狀況 （ref 至 上方文章）內獲得媒體或學術引用，或被專業人士充分肯定。其他編輯者有權移除使用过旧的证据及其相關引用的內容。（需要提供證明）
  • 如相關帳號屬於某機構／個人，需以其他官方或可靠第三方的形式展示帳號持有人的資歷/身分。（需要提供證明）

---

現時不同佈告版有不同凝聚共識的方案：

• 五大佈告版：沒有（只是一個吵架平台）
• 可靠來源佈告版：有足夠數量的意見或立場大致相同的共識即可公示
• GA：七日內達六個贊成票
• 下方提議的FA：由一個角色主導整個流程，其他人提供意見。

採用哪個較好？--唔好阻住我愛國（留言） 2022年10月23日 (日) 01:56 (UTC)

閣下現在不應強行縮短規程及加速改變有關流程，可能進一步抵觸共識商定等之本地慣常要求，請閣下暫緩相關。--約克客（留言） 2022年10月23日 (日) 04:26 (UTC)

(－)反对。第一，与现行条文差别过大，不清楚到底要改什么，要解决什么问题。第二，“所有用户生成内容来源会被列入防滥用过滤器”这是管理员的责任还是谁的责任，如何列举“所有”？第三，“能辨认账号持分者的身份”，维基百科什么时候需要身份验证了？弗兰西斯·培根写文章没提交身份证吧，他就不是可靠来源了？总之，提议的条文跟现行条文相比，对编者的要求大大提高，不利于参与。--Gqqnb（留言） 2022年10月23日 (日) 08:50 (UTC)

@Gqqnb：

請先閱讀上方的討論，你的問題在上方已有解答。

況且已在公告欄公示了一個月，你現在才提出反對？--唔好阻住我愛國（留言） 2022年10月23日 (日) 10:28 (UTC)

回應第二問題，誰有權限修改Abuse filter? Thus, 可能需要引用英維的database，因為英維是明文禁止使用者生成內容，當然有database輔助。--唔好阻住我愛國（留言） 2022年10月23日 (日) 10:37 (UTC)

回應第三問題，是「辨認」，非「證實」。--唔好阻住我愛國（留言） 2022年10月23日 (日) 10:40 (UTC)

---

有人認為新方針對引用使用者生成內容較嚴苛，只要按照下列方式申報即可。--唔好阻住我愛國（留言） 2022年10月25日 (二) 13:54 (UTC)

關於「相關帳號屬於某機構」的狀況：

On this day: June 6【North Korea】, Wikipedia Asian Month 
由「維基百科亞洲月/2022 專題網站」證實專頁擁有身分。
--唔好阻住我愛國（留言） 2022年10月25日 (二) 14:02 (UTC)

关于航空事故的新闻动态候选获选标准

各位您好，好像每次航空事故都能上ITN大大小小的事故几乎每个都上了，请问有必要设一个标准吗?--Mikey (讨论页） 2022年9月22日 (四) 11:52 (UTC)

可以考虑列入WP:ITNR。--BlackShadowG 沉痛哀悼女王陛下 2022年9月22日 (四) 13:35 (UTC)

• 意思是增加一個意外類的ITNR準則?--Temp3600（留言） 2022年9月22日 (四) 13:41 (UTC)

  是的--Mikey (讨论页） 2022年9月22日 (四) 17:57 (UTC)

邀请经常参与ITN更新工作的用户参与讨论：@KOKUYO、Shizhao、Johnson.Xia、FK8438、Ericliu1912：。--BlackShadowG 沉痛哀悼女王陛下 2022年9月22日 (四) 13:44 (UTC)

用死傷人數來評量，似乎可行？但好像有點不太對勁，說不上來哪裡怪怪的。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年9月22日 (四) 13:47 (UTC)

沒必要。而且表示「每次航空事故都能上ITN」，卻連個事前調查工作也不做，這樣有什麼討論的基礎？--KOKUYO（留言） 2022年9月22日 (四) 14:40 (UTC)

至少今年提出的提名大部分都上了--Mikey (讨论页） 2022年9月22日 (四) 17:55 (UTC)

比如今年6月的存档，有5次航空事故的提名而且每个都上了或者关于军机坠毁比如像是中国空军歼7和空军官校AT-3这种军机坠毁且伤亡较小的事故该不该上。--Mikey (讨论页） 2022年9月22日 (四) 18:05 (UTC)

查了一下统计资料，一年航空事故（民用）全球不超过100次（经常50次都不到）。而且如果认为不合适的话，在候选区提出反对意见就好了--百無一用是書生 (☎) 2022年9月23日 (五) 06:21 (UTC)

作為長期泡ITN，航空事故的編輯及創建者，我認為設置這個標準是必要的，順便也可以搞關於交通器事故的關注度標準（認為可以有別於單純獨立來源）。

以下是我關於ITN標準的建議：

• 對於民用航空器（主要為普通固定翼民航機），至少1人遇難
• 對於僅有傷者，無人遇難的的話，不太建議上ITN
• 對於小型航空器或政府救援，海岸巡邏機事故，軍用戰機，直升機的話，建議假定符合，尤其死傷慘重（全部/大部分遇難）
• 假定全部一等航空事故符合，2，3等一般不符
• 對於普通飛機因事故報廢，就算有人受傷，一般可以不上
• 對於重要飛機（例如安225）等被毀，不論傷亡認為皆符合ITN

同時認為我們不妨搞一個Wikipedia:關注度 (運輸器事故)--FK8438 （留言） 2022年9月23日 (五) 07:48 (UTC)

(▲)同上--Mikey (讨论页） 2022年9月23日 (五) 11:25 (UTC)

原來2022年開始就能算長期泡ITN啊，那我和時昭是泡到可以醃漬了吧。--KOKUYO（留言） 2022年9月23日 (五) 11:35 (UTC)

本來就不需要了。而且ITN和條目的關注度根本沒有直接關聯（除了沒有主條目就不能提名ITN），從一開始就搞錯主題了。如果是要制定關注度的方針，那麼就和新聞動態沒關係。--KOKUYO（留言） 2022年9月23日 (五) 11:41 (UTC)

@KOKUYO第一，我是指從帳號建立以來。第二，我認為先搞完ITN標準，然後可以討論一下關注度。--FK8438 （留言） 2022年9月23日 (五) 12:41 (UTC)

(：)回應@KOKUYO君，关于交通事故的关注度也一直是个问题，比如很多新人不知道关于那种交通事故可以写和那一些不能写。举个例子，今年有人创建了条目“中华航空918（?）号航班”是关于单发熄火的，但是每年单发失效的案例数不胜数最后被删了。所以我想说的是在弄完ITN的标准之后再把关注度也完善一下。--Mikey (讨论页） 2022年9月23日 (五) 14:55 (UTC)

@Mikelolggmrox大家認為卑提出的草案如何？--FK8438 （留言） 2022年9月25日 (日) 09:49 (UTC)

@KOKUYO、Shizhao、Johnson.Xia、Ericliu1912：,歡迎閣下討論。FK8438 （留言） 2022年9月25日 (日) 09:46 (UTC)

平心而论，你觉得科比的空难是否适合上ITN？如果适合，又是根据你提出的准则的哪一条？--MilkyDefer 2022年9月28日 (三) 08:36 (UTC)

• ITNR是一個保證當選的準則。維基百科從不會訂立"必定不會xxx"這種的反向排除規則。--Temp3600（留言） 2022年9月25日 (日) 17:52 (UTC)

  就很莫名其妙啊，要制定關注度就去制定關注度，與ITN本來就無關了。--KOKUYO（留言） 2022年9月25日 (日) 23:34 (UTC)

  (：)回應 关注度的问题请在楼下讨论--Mikey (讨论页） 2022年9月26日 (一) 13:33 (UTC)

  那回到正题就这种小型航空事故是基于什么标准上的ITN?--Mikey (讨论页） 2022年9月26日 (一) 13:36 (UTC)

  以下是我修訂後的二稿：

  • 所有導致至少1人死亡的民航機墜毀
  • 通用航空器，搜救巡邏，農業機等導致名人（符合關注度且高影響，例如明星或政治/前政治人物）死亡，或機上加上地面導致死亡率超過50%（例如：如果事故造成機上10人5人遇難，地面2人遇難，死亡率計70%）
  • 軍機墜毀導致重大政治影響可在無遇難者情況下上ITNR，如果單純事故建議至少2人以上遇難，畢竟軍用航空事故的關注度和報導較低，嚴格一點也無妨
  • 重大飛機被毀（例如最後一架DC10，三星，安225等）（因為安225被鵝軍炸了之後上過）
  • 無人傷亡但導致重大政治事件（如果某國家的元首飛機或重要飛機墜毀，即使無人傷亡，尤其是那些足夠臭好久的，或者是裴洛西被東風打下之類的也該上。

  --FK8438 （留言） 2022年9月28日 (三) 09:00 (UTC)

  或者直接改為所有1等航空事故（造成人員傷亡加飛機重大或完全損毀），或重要意義的飛機被毀，導致名人死亡的事故，元首專機事故，空軍或通用航空器死亡率超過50%。--FK8438 （留言） 2022年9月28日 (三) 09:03 (UTC)

  如同時昭所說，不需要。結案。--KOKUYO（留言） 2022年9月28日 (三) 23:25 (UTC)

請等一下，「機上10人5人遇難，地面2人遇難，死亡率計70%」？恕我直言，這算法也太荒謬了。那要是機上10人8人遇難，地面4人遇難，死亡率不就${\frac {8+4}{10}}=120\%$？死亡率可以超過100%嗎？-游蛇脫殼/克勞棣 2022年9月28日 (三) 22:58 (UTC)

@克勞棣當然沒問題呀，你維都這麼寫的。--FK8438 （留言） 2022年9月30日 (五) 15:25 (UTC)

正确的算法是${\frac {5+2}{10+2}}={\frac {7}{12}}\approx 58.3\%$--0xDeadbeef（留言） 2022年10月4日 (二) 12:00 (UTC)

知道了。認為大家如果沒有什麼意見的話就這樣定了吧--FK8438 （留言） 2022年10月4日 (二) 14:00 (UTC)

請等一等。${\frac {5+2}{10+2}}={\frac {7}{12}}$還是說不通：分母的10是飛機上總人數，但與之相加的2卻不是地面總人數，而是地面遇難人數！？我無法理解這種統計學。難道「機上400人1人遇難，地面50人遇難」，死亡率$={\frac {1+50}{400+50}}={\frac {51}{450}}\approx 11.33\%$，所以這個事故不算嚴重嗎？當然有人會問，不然「地面總人數」要如何得知？坦白說我也不知道，我只知道把地面遇難人數納入死亡率的計算是在拿石頭砸自己的腳，因為正確的算法遠沒有那麼簡單。考慮總遇難人數就好，何必計算這難以計算的死亡率？-游蛇脫殼/克勞棣 2022年10月4日 (二) 17:42 (UTC)

这么纠结干什么。--0xDeadbeef（留言） 2022年10月6日 (四) 11:02 (UTC)

• 其實不怎麼必要。如果想設立，「1等航空事故」或許可行，但必須先確定意外發生後數小時就會有評級，不然就趕不及。--Temp3600（留言） 2022年10月7日 (五) 10:14 (UTC)

  一般來講，只要確認有人遇難就算是一級了，哪怕沒有評級也可以算。對了，對於航空器失蹤超過48小時（尤其是疑似墜毀）估計影響力應該也可以上。--FK8438 （留言） 2022年10月8日 (六) 04:38 (UTC)

  同Shizhao，不必特別弄一個標準--Sean0115 2022年10月8日 (六) 11:32 (UTC)

  我認為其實一般民航飛機墜毀的報導事件是完全具備關注度和影響力，這種事件發酵速度很快且影響非常大，不亞於其他ITNR，同時認為任何24小時內死亡超過100人的意外估計也沒有問題。而且這樣也可以避免無遇難者事故被人放上還吵了7天才結束。--FK8438 （留言） 2022年10月8日 (六) 15:08 (UTC)

  所以話說回來，這個標準是為了什麼緣故設立的？是為了排除小空難還是加入小空難？--Sean0115 2022年10月9日 (日) 01:52 (UTC)

  我表達的可能有些問題，但我認為專門設立以下即可：

  • 1等航空事故
  • 元首/議長等人於航空事故中喪生
  • 民用航空器失聯超過24小時

  通用航空器如果坐的是重要人物（不僅僅符合人物關注度）或者引起爭議符合第二條，否則影響力不大沒必要，尤其是之前都不會上。小事故（甚至7700）就不要提了。如果大家沒有統一意見就不如單獨1等航空事故上ITNR。--FK8438 （留言） 2022年10月11日 (二) 13:03 (UTC)

• ITNR是一個保證當選的準則。按照共識決的原則，任何通過討論的項目都可以獲選:維基制度本身就不容許設立排除式的規則。--Temp3600（留言） 2022年10月19日 (三) 11:14 (UTC)

中维的FA、GA、DYK等评选是否可以改为英维的审议制而非强制投票制？

目前许多地方的投票制已经引发社群多次质疑和讨论，动辄被认为有灌票嫌疑（甚至有不拉票即不能通过的说法），而且许多评选参与者不多，几乎将沦为虚设，强制性的票数界限反而使许多达标页面仅因为评选无人光顾而未能获选，关于改为英维审议制，社群又何看法？欢迎大家讨论。--有困扰的话，就让魔女用魔法帮你排忧吧！ 2022年9月26日 (一) 04:47 (UTC)

如果审议人审议通过了不合格的条目，该负什么样的责任？审议人审议条目，又能获得何种激励？好奇这个审议制度如何运行。Fire Ice 2022年9月26日 (一) 08:11 (UTC)

我也不了悉英维为何能这样运作而不至于出问题，亦不清楚中维是否这样运作会出问题--有困扰的话，就让魔女用魔法帮你排忧吧！ 2022年9月26日 (一) 10:31 (UTC)

英维似乎FA、GA、DYK都没有激励机制。看过一些GA就一个人审议，标准弹性很大。也存在公开交换审议的情况。--Benevolen（留言） 2022年9月26日 (一) 10:53 (UTC)

如果审议人审议通过了不合格的条目，该负什么样的责任？审议人审议条目，又能获得何种激励？ - 个人觉得这些问题不存在，而实话实说和这种话很像：如果IP用户写出了不合格的内容，该负怎么样的责任？IP用户编辑条目，又能获得何种激励？

关于不合格条目，可以读读英维重选流程。两种方式，并且可以以个人的方式进行重选。--0xDeadbeef（留言） 2022年9月26日 (一) 13:12 (UTC)

你应该和如下例子类比：如果巡查员巡查通过了不合格的内容，该负怎么样的责任？巡查员巡查条目，又能获得何种激励？当然，DYK、GA、FA比新条目巡查责任更为重大，他们将被推上首页，甚至读者要是点击图标，还能看到“优良条目是我们认为质量令人满意，但未达典范标准的条目”等内容，甚至是“我们认为这些条目详尽而深入，符合特定要求，是维基百科条目之杰出典范。”如果审议人把诸如远东华人强制流配的原版这类东西选为FA，将来媒体报道顺便提到某维基人“有三篇条目被评为优良条目，一篇被列为典范条目——此条目还被其他语言的维基百科用户翻译为英语、俄语、乌克兰语、罗马尼亚语以及阿拉伯语。”谁来负这个责任，该负什么样的责任？Fire Ice 2022年9月26日 (一) 13:56 (UTC)

GA、FA推上首页难道不是需要更多人审议吗？英维的DYK在上首页之前都需要管理员进行批准的。至于FA在英维上可也是需要多个人审核达成共识。所以GA真的责任重大，必须投票表决吗？如有问题则处理问题，无法处理问题则是另一个问题。如有GA捣乱的，轻者WP:TBAN，重者直接封禁不就行？--0xDeadbeef（留言） 2022年9月26日 (一) 14:06 (UTC)

当下GFA就是无人负责的，如果审议制度同样无人负责，和当下制度又有什么区别呢？Fire Ice 2022年9月26日 (一) 14:09 (UTC)

「維基百科不保證其內容正確無誤」，本來就不負責。只是換一個更高效的制度是可以考慮的，不過正如下面提到的同行審查也未必「高效」，甚至可能更糟糕。

目前限期評選還能變現推進審議流程，如果同行審查，條目若沒人有興趣的題材，掛幾年也是很正常的，又變成另一種積壓工作。--Nostalgiacn（留言） 2022年9月29日 (四) 08:12 (UTC)

如果是按标准打勾勾的话，只不过变成自动灌票罢了（一次提交，一次“自动”判断标准，一次同意通过）。如果是人审议的话，出现标准意见冲突怎么办？甚至说现在投票机制，有点像按标准进行人工审议罢了。——Sakamotosan路过围观 | 避免做作，免敬 2022年9月26日 (一) 09:01 (UTC)

我们至少需要具备基本的编辑经验/能力的用户才可能做好这一点吧？--百無一用是書生 (☎) 2022年9月26日 (一) 11:44 (UTC)

機制亦需要充分考慮到不同專業、個案和特型等方面，若果依據本地實際，認為僅能由特定試驗之專案做略為檢視操作，在全方面而言相關條件之現實門檻還需更多補足。--約克客（留言） 2022年9月26日 (一) 12:44 (UTC)

英維這套方法不適用中維啦。--~~Sid~~ 2022年9月26日 (一) 13:18 (UTC)

(？)疑問：萬一缺乏合適的人選怎麼辦？就好比折毛之前寫的若干篇FA、GA或者DYK有很長時間都沒有人發現造假，請問這到底是為什麼呢？所以目前還是先把人手不足這件事情解決了再說吧，人家英維的審議制也是典型因地制宜啦，中維不應該也是嘛。--紹💓煦^集思廣益 2022年9月26日 (一) 22:41 (UTC)

• 懶得再講什麼了，如果這種東西就是一種無法解決的Bug，那通通都是多講的，一點意思也沒有。「非強制投票制」這玩意，記得和以前共識制討論非常像。其實就是喊喊口號而已，但這種東西啊完全實施不起來。如果沒有辦法實施的，真的都是多講的，沒有討論必要性。--Z7504非常建議必要時多關注評選（留言） 2022年9月27日 (二) 07:05 (UTC)
• (▲)同上 仅是小范围中时而可行的乌托邦，很容易跑偏无共识。如果是想促成深入的同行评审，弄成可选机制、增加权重就好，流程参考还算能运转的DYK规则、PJ:AFC、典范/优良评选、WP:RSN等。--YFdyh000（留言） 2022年9月27日 (二) 07:45 (UTC)

折毛事件的時候也有過類似的討論，還是那個觀點「這個系統更像是各專題評級的升級版，各專題有一定數量的評選人員，才能比較好地進行實施這個系統。另外，基於不同評選人員的標準，質量可能會飄忽不定。」

另外同行審查也不能解決「评选无人光顾而未能获选」的情況，實施這個制度的粵維也有超過兩年（甚至三年）都沒有人開啟審查的情況。而且有些優特審查很水，如這個。--Nostalgiacn（留言） 2022年9月28日 (三) 13:58 (UTC)

粤维人数和中维不可同日而语吧--有困扰的话，就让魔女用魔法帮你排忧吧！ 2022年10月2日 (日) 10:01 (UTC)

抽取的時間記錄也不一樣啊，列舉個案是很早期之情形，如點入正版參閱（UTC時間總看得懂吧）可是輪候漫長呢～另外提示一點，粵維上了新一波管理用戶、整個體系在部分操作上可能比中維更中維化，所以到底比較起來怎麼樣都很難說咧--約克客（留言） 2022年10月2日 (日) 12:02 (UTC)

试行一次

吵这么凶大家都是在纸上谈兵，应该要实际做一次才能知道好不好才对。要不这样，我提议实际使用一个典范条目评选试行一次审议制度。这样有没有问题、会不会有问题就全部显现出来了。参考英维的评选制度，一名协调员拥有是否入选的最终决定权，这也解决了所谓的无人对审议结果负责的问题。

所以我就是说，大家是否愿意让下一篇典范条目评选由我作为协调员实际做给大家看一次是否可行，否则这个讨论永远都是没有任何论据的辩论，不及格。 --MilkyDefer 2022年9月28日 (三) 07:36 (UTC)

謹表( ✓ )同意示之。--約克客（留言） 2022年9月28日 (三) 09:09 (UTC)

( ✓ )同意 --0xDeadbeef（留言） 2022年9月28日 (三) 09:17 (UTC)

(＝)中立，反正上面都舉例過了，如果說學學Cdip150管理員建設一個過濾器的話，或許可以試試看。但在這就不再瞎扯些什麼了，估計又要來一個不知道得討論多久的討論串，不要玩到最後又是一個相同模子、不同包裝的討論，那真的一點意思都沒有。--Z7504非常建議必要時多關注評選（留言） 2022年9月28日 (三) 16:51 (UTC)

赞成。对于我熟悉的领域，我愿意作为评议人参与。（如果我有时间）--洛普利寧 2022年9月30日 (五) 02:55 (UTC)

支持，如果是我熟悉的领域，我愿意作为评审人参与。--——🦝英特浣熊耐尔 ^{就一定要实现}_{（留言・贡献）} 2022年10月2日 (日) 08:47 (UTC)

值得一試。--EzrealChen（留言） 2022年10月2日 (日) 09:05 (UTC)

• 儘管我不覺得能夠阻止什麼: RFA試行與條目評審試行其實有很大的分別。RFA總是能夠吸引大量用戶前來，制度本身無非是怎樣令大家服氣而已。條目評審的本質問題是對某一方面有專攻的用戶不足，因此如果按自己的初步觀念投票，就有亂投、灌票之嫌; 如果總是由兩三大佬投反對票，又有對新人不公云云。現在試行萬眾矚目，將各路精英聚集起來，自然能撐起場面，但日後又怎辦呢?--Temp3600（留言） 2022年10月7日 (五) 10:10 (UTC)
  • (：)回應：典范条目几大标准：全面、流畅、专业、考据全面、稳定、遵循格式手册、媒体使用恰当、长度合理，对审查者的能力标准要求是不一致的。审议制度允许审核者只针对这其中的部分标准提出支持，协调员会检查候选条目是否完整地接受了检查。因此，审议制度可以让评审者有力出力，回归典范条目标准，同时阻挡远东华人强制流放这种做了来源检查就能发现问题但是偏偏没人做就已经够票了的条目通过。投票制度在另一方面，投下支持票不需要说明理由，一个“符合典范条目标准”到底是否完整涵盖了所有标准呢？不知道。有责任心的人看到标准这么多没精力逐条确认所以不投；没责任心的人看着条目差不多符合流畅、遵循格式手册、长度合理就直接给支持票了。审议制度将典范条目标准进行足够细颗粒度的审视，有能力的人只要专心检查是否专业、是否与来源对得上号即可，专业能力欠缺的人就去检查行文是否流畅，格式是否得当等不需要专业知识的准则。将审核过程分工完成降低了所有人的负担，或可形成能力门槛降低的效果，更有亲和力。协调员是守门员，对他们的要求应当较高。 --MilkyDefer 2022年10月7日 (五) 11:37 (UTC)
  • 我擔憂的是，實施初期可能會有編輯秉著改善中維的決心去審視各提名條目，這當然是好事，但日子久了，參與人數或會穩定下降，最後典範條目評選重回多年前投票附理由的情況，即「內容充足、語句順暢，參考資料足以支撐全文，以支持票作獎勵。」之類。--銀の死神♠走馬燈劇場^{祝你在亂流下平安} 2022年10月8日 (六) 10:14 (UTC)

    不一样，如果害怕有这种现象就应该不允许投票带理由，而是给每一个条件打钩或给予评价，这样迫害捣乱评选者的时候就不可以以忘记了有这个规定的理由逃避迫害。--0xDeadbeef（留言） 2022年10月8日 (六) 10:33 (UTC)

    共识制评选的规定中，如果“评审员没有提供足够的信息来判断条目是否符合标准”，协调员可以判落选。

    此外，虽然共识制在中维可能做不到完美，但能避免投票制中的不少问题：比如不读条目就投yesFA（甚至我看到有提名人请求撤销FA时，都有用户上来就投yesFA……）、高质量的条目因为规定时间内少几个人投yesFA而落选等，我觉得总体而言共识制仍是一大进步。--BlackShadowG Slava Ukraini! 2022年10月8日 (六) 14:39 (UTC)

    • 我只是覺得，優良／典範條目評選引入所謂「英維式共識制」的確能夠隔絕劣質條目，但我對中維有沒有足夠審核人評核條目這點有所保留，畢業大家都是義工，吃力不討好的事沒有太多人願意做，而且會長篇大論指出條目各項錯處誤譯的編輯也走得七七八八。--銀の死神♠走馬燈劇場^{祝你在亂流下平安} 2022年10月9日 (日) 03:55 (UTC)

      • 這個是評委本身的學養問題。遺憾地，三個臭皮匠取代不了諸葛亮。然而，在最好的情況下，臭皮匠可以當個好助手，讓諸葛亮專心發揮所長，不用管官僚程序和低級問題。--Temp3600（留言） 2022年10月9日 (日) 09:19 (UTC)

        倒過來說，這種預審的好處，就是可能將臭皮匠們的權限壓縮在格式、來源一類的問題上，讓諸葛亮對內容的意見能夠突顯出來。然而，到底有沒有諸葛亮，這才是最根本的問題。-Temp3600（留言） 2022年10月9日 (日) 09:23 (UTC)

  • (：)回應：拆分FAN的審核流程可以算是一種預審。MilkyDefer上面的解釋很好，然而並沒有解決核心問題，即對內容本身的審核問題。換句話說，折毛的FA是奇狀怪狀的不良產品，日後有了預選後，至少可以產出金玉其外的不良產品。這或許是一個進步，但將其美名為「英維式的共識制」可就差遠了。--Temp3600（留言） 2022年10月8日 (六) 13:58 (UTC)

    我认为不管你如何想，有进步比原地踏步要好。如果能够透过改善一下优质条目整体水准的方式吸引一些学者来（而不是对英维趋之若鹜、对中维嗤之以鼻）的话，就更好了。--MilkyDefer 2022年10月8日 (六) 15:20 (UTC)

方案设定

那就这样，我先草拟一个方案，如下：

• 在该方案得到公示通过后，试行一次有效的评议制典范条目评选。
• 上一条当中的“有效”指的是，条目不满足快速落选准则，且不是典范条目重审。
• 选择的评选条目应该是在公示通过后，所提交的第一条典范条目评选。如果该候选条目不是有效的评选，则选择确定候选条目评选无效时刻起，下一条提交的候选条目，以此类推。
  • 例子：假如本方案于2022年11月1日凌晨3:47公示通过，同日凌晨4:13有人提交了条目A作为典范条目候选、上午9:24另有人提交了条目B、下午17:33有人提交了条目C。则条目A成为试行评议制的对象，条目B和条目C继续使用投票制。但是，在11月2日上午10:41时有人发现条目A含有大量侵犯版权的内容而导致其快速落选（参见即时不合标准准则第2条），则这一次对条目A的评审为无效评审。由于条目B和C已经在走投票流程甚至有人可能已经投票了不适合打搅，因此应当选择11月2日上午10:41后提交的第一条典范条目候选作为新的审议对象，以此类推。
• 该次使用审议制的评选，其结果拥有与现行投票制同等的效力。即，若审议为入选，则条目获得典范条目资格；若审议结果为落选，则条目同样落选，30日冷静期同样适用。
• 应该为该次试行开设评审专页，同时在典范条目评选主入口提供进入该次评审专页的链接。（这一条是为了防止评议发言过多影响其他条目的评选，可再做商议）
• 该次试行的协调人由我担任，毕竟是我提出要试行一次的。
• 试行结束后，我们继续讨论后续事宜。

如何？我还遗漏了什么要点吗？ --MilkyDefer 2022年10月2日 (日) 09:40 (UTC)

作为提案发起人表示原则性(＋)支持，唯我另发起了一个二十周年闭站抗议提案，可能时间上容易冲突--有困扰的话，就让魔女用魔法帮你排忧吧！ 2022年10月2日 (日) 09:47 (UTC)

基本上思路可以，謹表(＋)支持。不過應該需要另外開啟草稿版面，放置排版一下先吧，看上去一些細節也需要梳理一下，包括那個輪候遞補位列最好再看看怎麼排一下先。--約克客（留言） 2022年10月2日 (日) 11:56 (UTC)

@Longway22 所以具体而言有什么意见吗？你说的这些太宽泛了完全不懂。--MilkyDefer 2022年10月7日 (五) 03:15 (UTC)

在準方案討論版整合一下吧，主要一個是對可能進行試行標的對象（即被評價條目）遴選機制作一定清晰化。--約克客（留言） 2022年10月7日 (五) 10:40 (UTC)

没意见。--0xDeadbeef（留言） 2022年10月2日 (日) 12:02 (UTC)

(＋)强烈支持，我可以帮忙做一些准备工作。--BlackShadowG Slava Ukraini! 2022年10月2日 (日) 14:05 (UTC)

(＋)强烈支持：不错的决策！！----👻Cryberghost 2022年10月3日 (一) 03:50 (UTC)

(＋)支持--——🦝英特浣熊耐尔 ^{就一定要实现}_{（留言・贡献）} 2022年10月4日 (二) 04:15 (UTC)

(＋)支持。 --窝法乙烷 儿法梦碎 2022年10月4日 (二) 08:13 (UTC)

基本(＋)支持。--在下荷花，请多指教（欢迎签到） 2022年10月5日 (三) 09:55 (UTC)

(＋)支持——一只星步甲|留言|签名 2022年10月5日 (三) 16:45 (UTC)

筹备

我开始筹备了：Wikipedia:典范条目评选/共识制试行，目前在翻译英维的规则。——BlackShadowG Slava Ukraini! 2022年10月7日 (五) 04:46 (UTC)

目前英维相关规则/模板翻译进度：

1. 主页面：Wikipedia:典范条目评选/共识制试行（en:Wikipedia:Featured article candidates）完成
2. Template:FAC-instructions（en:Template:FAC-instructions）完成
3. Template:FAC/共识制试行（en:Template:FAC）完成
4. Template:Featured_article_candidates/共识制试行（en:Template:Featured_article_candidates）完成
5. Template:Featured_article_candidates/editintro（en:Template:Featured_article_candidates/editintro）完成
6. Wikipedia:Featured article preload（en:Wikipedia:Featured article preload）完成
7. Wikipedia:典范条目评选/存档方式（en:Wikipedia:Featured_article_candidates/archiving）完成

下方的页面在试行阶段并非必须，可以等正式改用共识制后再翻译/引入：

1. User:FACBot（维护FAC的机器人，主要的工作是存档已关闭的提名）
2. Wikipedia:典范条目评选/急需评审（en:Wikipedia:Featured article candidates/FAC urgents）
3. Wikipedia:典范条目评选/获选记录（en:Wikipedia:Featured article candidates/Featured log）入选的FAC由协调员加到这个页面
4. Wikipedia:典范条目评选/提名存档（en:Wikipedia:Featured article candidates/Archived nominations）落选的FAC由协调员加到这个页面

下方的页面可有可无：

1. Wikipedia:典范条目评选常见问题（en:Wikipedia:Wikipedia Signpost/2008-04-07/Dispatches）FAC的常见问题，没有也问题不大
2. Wikipedia:典范条目统计（en:Wikipedia:Featured article statistics）

--BlackShadowG Slava Ukraini! 2022年10月7日 (五) 08:42 (UTC)

此外@MilkyDefer：英维提名FAC评选的方式是让提名人往条目的讨论页上放{{subst:FAC}}（目前中维的模板位于{{subst:FAC/共识制试行}}），随机抽条目可能在程序上会与正式的不太相同。因此，比起抽一篇“幸运条目”用共识制，要不让有意让条目以共识制评审的主编自荐条目？--BlackShadowG Slava Ukraini! 2022年10月7日 (五) 09:32 (UTC)

我们实验的是审议制度，在审议之外的流程性质的东西不在实验范围啊。--MilkyDefer 2022年10月8日 (六) 05:31 (UTC)

OK。--BlackShadowG Slava Ukraini! 2022年10月8日 (六) 12:17 (UTC)

目前基本筹备已经完成，随时可以开始试行。--BlackShadowG Slava Ukraini! 2022年10月7日 (五) 09:49 (UTC)

据说要公示--0xDeadbeef（留言） 2022年10月7日 (五) 09:54 (UTC)

建議用GA做試行，個人認為FA非常不適合用審議制。另外建議協調員至少三人而非只有一人。--$\int$（☎） 2022年10月9日 (日) 20:07 (UTC)

能具体阐释一下你认为GA比FA更适合的原因吗？协调员的话一下子三个人就协调试行的一篇条目会不会多余了些？--MilkyDefer 2022年10月10日 (一) 01:12 (UTC)

FA是要多數社群認定的條目，GA則是在該主題內（換言之，FA跟GA的定位並不完全一樣，如果一樣為甚麼要分），我不認為區區幾名支持者就能代表多數社群的意見（FA的標準本來就應該比GA高了，不存在所謂標準太高而導致選不上的問題，選不上是因為品質不夠好），但我的確支持GA應該採審核制，畢盡有一些主題的條目就是不會引起很多人有興趣去讀，自然票數也會比較少。--$\int$（☎） 2022年10月10日 (一) 01:40 (UTC)

有一个问题。你为什么会认为FA是多数社群认定的条目？可能确实需要比GA多一点的人认同，但是夸张到多数是不可能的。在英维平均一个GA的审阅者1到2个；FA大概10个，怎么看都不是“多数”。要追求你想象中的多数，任何一个地方都没有。--MilkyDefer 2022年10月10日 (一) 03:14 (UTC)

我的意思是FA跟GA的根本不同在於GA是寫「怎麼樣能夠把內容或知識傳達給讀者」，而FA是寫「甚麼樣的內容或知識讀者會有興趣」（一言以蔽之：FA跟GA的不同就兩個：解釋行話和去蕪存菁。要讀得懂，也要讀了之後會對裡面提到的內容有興趣，進而自行去做更多研究）。之所以不會同意用審核制是因為一篇FA應該要能足夠吸引人去讓編輯去支持一篇條目成為FA（都吸引不了編者了，怎麼吸引讀者），而非少數人自行決定一篇條目是否適合大眾閱讀（用站內的說法叫「適合成為FA」或「符合FA標準」）。如果還是不懂的可以去看6+的用戶頁來理解為甚麼他寫FA寫的很開心。--$\int$（☎） 2022年10月10日 (一) 05:57 (UTC)

題外話：我能理解社群已經開始將FA跟GA慢慢有畫上大概等於的感覺，認為「FA只是更好的GA」，這裡有必要劃清FA跟GA的不同。--$\int$（☎） 2022年10月10日 (一) 05:57 (UTC)

FA并不是一定要为了让读者感兴趣。只能说是百科全书里面最优秀的条目，而往往很多优秀的条目都是能够让人感兴趣而已。

另外，感谢你的回复，解析失败 (带有PNG备选的SVG（MathML可通过浏览器插件启用）：从服务器“/mathoid/local/v1/”返回无效的响应（“Math extension cannot connect to Restbase.”）：): \int 。--0xDeadbeef（留言） 2022年10月10日 (一) 06:00 (UTC)

我能理解的確有些讀者讀完了FA之後還是會對該條目的相關內容沒有興趣，但起碼這是做為每位嘗試寫FA的編輯都應該要牢記在心的事。另外說真的，「百科全书里面最优秀的条目」是由誰評斷？個人認為這只是句很模糊的話，沒有甚麼實際意義。如果這個問題硬要討論下去的話我會說是由整個社群來評斷，但總不可能搞成像RFA那樣有勞整個社群來評價一位候選人吧。--$\int$（☎） 2022年10月10日 (一) 06:07 (UTC)

所以才会有典范条目标准，将「最优秀的条目」的标准明确化。--MilkyDefer 2022年10月10日 (一) 06:10 (UTC)

我並不認為當前標準足夠明確（此句同樣套用GA），仍留有許多供解釋的空間（註：這並不一定不是壞事）。

而且我不認為也有需要依此延伸下去的必要。我並不覺得將標準明確化（或模糊化）對當前提案有任何直接的影響/幫助。--$\int$（☎）dt 2022年10月10日 (一) 07:37 (UTC)

讨论状态：普遍相信采取审议制度可以相比于投票制度拥有更严格的把关。

现在事实：典范条目在品质上要求更优于优良条目。

所以不对典范条目严格，反而对次一级的优良条目严格，不符合直觉。--MilkyDefer 2022年10月11日 (二) 12:58 (UTC)

不見當前討論對「审议制度可以相比于投票制度拥有更严格的把关」達到共識。相反的，許多人認為審議制可能並不適合中維，如Benevolen提到的「標準彈性很大」和約克客提到的「相關條件之現實門檻還需更多補足」--$\int$（☎）dt 2022年10月11日 (二) 17:09 (UTC)

重申一次：我認為試行是可以的，但需要改善兩點

1. 改用GA進行試行
2. 至少三人作為協調員/共識執行人。--$\int$（☎）dt 2022年10月11日 (二) 17:12 (UTC)

我可以肯定，“审议制度可以相比于投票制度拥有更严格的把关”这句话所言绝对非虚。

如果说审议制“標準彈性很大”，那我可以说，投票制的所谓标准几乎可以视而不见。目前投票制是否入选不是依据“条目符合多少FA标准”，而是“多少人认为条目符合FA标准”。投下支持票的人可能没有读过条目，甚至可能知道FA要符合哪些标准，只要一定数量的用户投下支持票，条目就能入选，没有人能确定投票者是否有仔细审过（甚至是否审过）条目。即使有用户指出条目存在不少问题，只要支持票足以盖过他，那这些意见也可以视而不见。改用审议制度可以最大程度避免这种问题，至少审议制度中，仅仅表示支持是没有意义的。--BlackShadowG Slava Ukraini! 2022年10月12日 (三) 13:40 (UTC)

这样子说吧，请问你对于试行一次究竟有什么意见呢？改成GA和三个人总要有理由吧？英维的巨大RFC也只找了三个closer。如果和这个比起来是不是英维应该找三倍以上的人呢？不是说中维缺人吗？可现在一个无害的试运行都要求这么高了。--0xDeadbeef（留言） 2022年10月12日 (三) 13:49 (UTC)

三個人的話是依當前中文維基百科社群運作方式（尤其是評選）提出的最優解。我覺得不應該只尋求完全照搬英維規則，而是想辦法如何讓一個具有建設性的新機制在不造成過大風險（即協調員本身的三個問題：協調員自身可信度/是否值得社群信任、如何對可能的錯誤判斷負責〔是否協調員應該辭去該職〕及如何處理因改為審議制而造成其他可能的未知爭議）的情況下融入社群。尤其是第一項（協調員自身可信度/是否值得社群信任），若是無法得到社群信任極有可能造成爭議，變成遭人詬病的站務。

就如同之前的HAM，現在評選（起碼FA）沒什麼問題很大程度就是因為是：

1. 很簡單的加減乘除，幾乎不可能有人為操作空間。DYK、GA我不知道，但我長期關注FA，知道投票的就是那幾個人，多數時候也就只有那幾人投票，沒有拉票的問題。至於FA選不上的問題前面解釋過了，這裡就不多提。
2. 規定明文寫出（幾票就幾票，少數服從多數），沒有可以造成爭議的地方。
3. 所有參與者都享有同等地位，不會有人需要決定共識是甚麼，也自然不會有可信度的問題。

WP:沒壞別修。隨意完全引入（甚至只有部份）其他維基百科的機制並不一定對本地社群有益，反而有可能會造成更大的問題。雖然我自己也不是很喜歡見到本地不斷引入其他站的方針/指引來創建出新的職位（之前是調查助理、現在是協調員），但我也不會全然否認該方案可能的益處。這也是我部份(＋)支持這項提案的原因，尤其考量到我對除FA評選外的認知並不全面，因此我對DYK和GA的部分不予置評。

另外即使是试运行也應該當成正式評選來看，不論最終會不會實施。--$\int$（☎）dt 2022年10月13日 (四) 03:39 (UTC)

如果要三个人，那你对于协调员人选有什么推荐吗？在此次试行中，这些问题应该不存在吧。还是说，你觉得MilkyDefer没有社群信任/不可信？如果说FA评选没问题，那折毛事件如何解释？--0xDeadbeef（留言） 2022年10月13日 (四) 04:11 (UTC)

阁下认为FAC“没什么问题”是因为FAC有硬性标准，不会引发争议。但FAC最重要的目的，逐一检查条目是否符合WP:FACR，在投票制中完全无法落实，理由已如前述（例如：参与者完全可以不看条目/不知道FA标准就投票让条目入选，少数服从多数可以让重要意见直接视而不见）。共识制度即使有争议，也可以提高FA条目质量的把关。阁下认为“没坏别修”，在我看来这是已经坏了，而且坏得很严重，折毛事件就证明了这一点。

此外我不认为三个协调员是适合中文维基百科社群运作方式的做法。中维本身就人手不足，判断共识还需要三个人才能做到吗？再者，协调员出现争议又给谁来判断协调员的共识？“协调协调员的协调员”？到头来判断共识的权利还是会落到一个人手里。--BlackShadowG Slava Ukraini! 2022年10月13日 (四) 15:34 (UTC)

首先，拿折毛事件來證明應該要施行審議制本身就是一個問題。若有時間去重新看當時評選的人會發現三點即使用審議制也無法解決的問題：

1. 並不只有平時活躍於評選的人參與討論，相反的，有許多不常參與評選投票資深用戶（如河水、百戰天蟲）亦參與了討論，且並沒有參與討論的人發現這個問題。
2. 12支持，0反對，相信若是依所謂「判斷共識」而非「利用常識」來執行評選的協調員來說協調員也會選擇通過該條目。
3. 當時並沒有所謂「重要意見」點出條目的主要問題。

當然，假定新機制在過去的表現如何是沒有意義的。只用單次的突發性事件來作為幾乎完全改變當前體制（若是基於投票制作出改善，如提高當選所需票數那另當別論）的理由是沒有需要也沒有必要的行為，但就方案本身的想法我還是有一定程度的支持。

另外我對協調員的推荐不予置評，我雖然長期關注FAC，也熟知長期參與FAC的編輯，但我自認還沒有足夠能力去判別誰適合來判斷共識。我也沒有寫我不信任MilkyDefer，我只是希望有更多協調員能交換意見。當然共識的執行人確實只有一位，但是在有爭議的情況下多一兩人供執行人諮詢總是好事。--$\int$（☎）dt 2022年10月13日 (四) 16:31 (UTC)

诚然，审议制未必能完全防止折毛事件的发生，但能很大程度进行避免。当时远东华人强制流配的FAC中，没有用户检查来源，由于是投票制，因此即使没有用户做来源检查，条目也可以入选。如果是审议制，就更有可能有用户根据WP:FACR做来源检查（英维的伪条目Bicholim conflict就是在FAC被查出来的）。

鄙人仍不认为结案需要三个协调员，先不提中维是否有这么多人力，判断共识一个人足矣。协调员就相当于FAC的管理员，如果AFD要两三个管理员才能结案，显然不是什么好事。且会引起争议的评选，显然条目本身也是有问题的，即使被判落选，完善条目过一个月再来评选是个更好的方式。--BlackShadowG Slava Ukraini! 2022年10月15日 (六) 07:55 (UTC)

另外希望有3人的主要原因是因為在共識不明確的情況下由一人自行決定可能沒辦法做出最佳的判定，所以是希望有其他人也可以作為協調員交換意見。--$\int$（☎） 2022年10月10日 (一) 01:36 (UTC)

只是试行，必要性不大。英维这么大的社群也只需要四名协调员，一篇条目就是由一名协调员结案。需要注意的是，条目是否入选不是依据协调员的看法，而是依据审阅者的共识，协调员只是负责判断审阅者的共识。这就好比为何AFD只需要一名管理员就能结案一样。--BlackShadowG Slava Ukraini! 2022年10月11日 (二) 12:52 (UTC)

那如果一討論沒有明確共識的話該當選還是落選？另外AFD只需一名管理員結案也不過是在有明確共識的前提才會結案，不然通常會進到積壓討論，最後甚至無共識保留（不太確定這對協調員來說這套用到評選是當選還是落選）。--$\int$（☎）dt 2022年10月11日 (二) 17:15 (UTC)

根据目前英维的规则，“没有达成条目入选的共识”就是落选；这与审议制的GAC区别很大，审议制的GAC是一名审阅者主要负责审阅，其它编者也可以发表意见，只要基本没什么问题，审阅者就可以评定入选，这比FAC宽松很多，所以我不建议阁下提议的用GAC试行。--BlackShadowG Slava Ukraini! 2022年10月12日 (三) 13:15 (UTC)

如果最终决断有疑，可以依托之前意见再讨论和重选，多名协调员得出的共识也未必是普遍、可靠的共识，共识始终可推翻。如同存废讨论的异议路径是存废复核。--YFdyh000（留言） 2022年10月11日 (二) 18:35 (UTC)

現評選規定為一個月後才能重新提交評選，存廢複核並沒有限制必須要幾天後才能提請覆核。個人認為若只依协调员的決定將有爭議的條目選為典範，則必須等待一個月後才有可能重選。共识確實可推翻，但若無法及時改變則無法避免原可避免的負面影響。

再者，講難聽一點，我始終無法剔除掉有償協調員而引發爭議的可能性。這也是為何我會傾向有多名協調員的原因之一。--$\int$（☎）dt 2022年10月11日 (二) 19:57 (UTC)

如果决断并不违逆共识而只是偏颇，继续在客栈等位置讨论就好，然后再走重选手续。严重情况得到共识建议雪球以推翻决定，但争议议题就很麻烦。如果说的难听，我也无法排除两名协调员一同忽视共识或争议的可能性，以及协调员如何可信。--YFdyh000（留言） 2022年10月11日 (二) 20:14 (UTC)

BlackShadowG回应后了我又看了一遍，我还是搞不懂为何需要有三个协调员。如果你认为协调员关闭讨论的是en:WP:SUPERVOTE，那是不是在暗示你不认可MilkyDefer对于共识的判定？协调员的主要工作只有两个：第一是判断讨论中有没有达成共识，第二是保证讨论没有遗漏掉WP:FACR，且在共识作为提拔FA时有合理反对的权利。但是，并不是说明协调员能在多半人反对的情况下强行推进到FA。--0xDeadbeef（留言） 2022年10月12日 (三) 13:34 (UTC)

我可以简单地说，判断共识的工作最后肯定会落到一个人手中，这一点几乎不太可能改变。协调员是负责判断审阅者之间的共识的，如果要多名协调员对“判断共识”达成共识，那如果协调员间产生不同意见，又由谁来判断协调员间的共识？再设立一个“负责判断协调员的共识”的职位吗？我不认为这样一层层下去是件好事，让协调员作为那个判断共识的人，就足够了。--BlackShadowG Slava Ukraini! 2022年10月12日 (三) 13:52 (UTC)

建设性提议

试行本就是为了摆脱空想看到底好不好，试行提案还要提修正案争吵的话实质上就是延续了空想，因此我建议下面的修正案可以跳过去直接按原案试行一次-有困扰的话，就让魔女用魔法帮你排忧吧！ 2022年10月26日 (三) 07:21 (UTC)

试行一次修正提案

鉴于上面有人强烈要求对这一次试行做出两点修订，特列如下：

1. 这一次试行改针对一次优良条目评选
2. 增加这一次试行的协调员数量为三人

如果大家都没意见的话我也就从了吧。 --MilkyDefer 2022年10月12日 (三) 01:01 (UTC)

虽然觉得三个人评选优良条目很搞笑，但是如果觉得这样有意思，我可以当一个协调员--0xDeadbeef（留言） 2022年10月12日 (三) 04:36 (UTC)

(－)反对：一人、FA比较好，如果从GA试行那还不如从NYK试行呢。--有困扰的话，就让魔女用魔法帮你排忧吧！ 2022年10月17日 (一) 06:01 (UTC)

(－)反对:

1.英维GA的共识制评审方式与FA完全不同，GA通常是一名审阅者主要负责审阅，其它编者发表意见；FA则是需要多名审阅者达成共识，显然在中维先试行FA的共识制评审更为合适。

2.一篇条目只需要一名协调员判断共识，理由已在上方回复。--BlackShadowG Slava Ukraini! 2022年10月12日 (三) 13:08 (UTC)

• 我還是更關注誰來進行內容實質評審的問題。一個看版和一堆看版效果一樣。--Temp3600（留言） 2022年10月14日 (五) 10:23 (UTC)
• 我覺得GAC要3人負責「協調」過多了，FAC的話則沒有問題反正另外兩人都只是負責endorse。--銀の死神♠走馬燈劇場^{祝你在亂流下平安} 2022年10月16日 (日) 08:45 (UTC)

那不然鑑於這次只是試行改成三人就算了，就作GA試行一人協調就好。--$\int$（☎）dt 2022年10月16日 (日) 23:46 (UTC)

不建议改成GA试行，GA审议制是一名审阅者直接决定条目是否入选，不需要协调员。--BlackShadowG Slava Ukraini! 2022年10月17日 (一) 11:43 (UTC)

我觉得他可能想的是走出与英维不同的路子——GA审议，FA投票……--MilkyDefer 2022年10月17日 (一) 14:15 (UTC)

FA比GA标准更严格，却使用更宽松的投票制？怎么看都不合理吧。--BlackShadowG Slava Ukraini! 2022年10月18日 (二) 13:14 (UTC)

那把他召唤出来阐释一下吧@ATannedBurger--MilkyDefer 2022年10月18日 (二) 14:30 (UTC)

前面已經解釋過投票制並不一定比審議制寬鬆，及FA不適用審議制的原因。--$\int$（☎）dt 2022年10月18日 (二) 15:54 (UTC)

即使有使用者指出條目存在不少問題，只要支持票足以蓋過他，那這些意見也可以視而不見

，這是少數服從多數，我不認為在評選（尤其是高階評選如FA）需要有所謂共識執行員/協調員。FA評選現在沒什麼爭議（就看上過客棧的次數基本就知道了，相信有許多需要更高權限〔如管理〕處理的站務上過客棧的次數/爭議數比評選還多），那為甚麼要引入一個一望而知會造成爭議的制度？前面也有提到用折毛事件來證明評選需要改革是不需要也沒必要的行動。

評選講究公開透明，而非多出一級似乎像權限的用戶組來專門處理評選。上一個在中維這樣做的最後上了客棧被公開審判至少兩次了，我不希望評選也變成那個樣子。--$\int$（☎）dt 2022年10月18日 (二) 16:14 (UTC)

看了上面你提出「現在評選（起碼FA）沒什麼問題很大程度就是因為是」三個觀點，給人印象似乎是不願走出舒適區，習慣了固有的小圈子評選（投票的就是那幾個人）。

「少數服從多數」和「不會有人需要決定共識」過於理想化了。如下文提到現在評選員的標準是「自動確認用戶」即可，而且這也是目前DYKN、GA、FA的標準。一樣的評選員標準，也是票數積分，為何DYKN、GA就較多爭議，是否有爭議和評論制度好壞沒有邏輯關係。DYKN、GA就較多爭議更多是因為新人參與等更多，他們對格式行文用語不了解，所以條目質量不免殘次不齊，潛在爭議的可能性大。

如果英維這個比中維規模更大的社區，使用共識制沒有問題，現在的制度試行並沒有損失。折毛事件只是一個典型例子，深層的問題是現在DYKN、GA、FA都存在的「零意見支持票」，就算是方針也有因為沒人仔細看就通過的情況。共識制就是希望「有人对审议结果负责」，其實就算不進行審議，現行機制是可以對任何獲選GA、FA的條目提出複核，就算不試行這個制度，也可以變現組建複核審查小組，有條件進行攔截（如FA評選中，認為不符合標準，曲線將條目移交GA評選或複核）。--Nostalgiacn（留言） 2022年10月19日 (三) 17:09 (UTC)

(＋)支持「複核審查小組」，的確有許多可能連GA都不符合的條目因為水票問題而上了FA（就文筆而言，內容比較難發現，詳見現在在FAC進行的重選）。另外個人也建議在一條目得到FA提名前必須先有GA。

 吐槽：這不是舒適圈的問題，而是有沒有足以信服的專業人士（如寫過多條FA，個人認為10+條為佳，並清楚知道FAC應該如何運行的編輯）來監督的問題，但根據現狀時不時有反對權威（如「濫權管理員」一類）的事件發生，不建議引入「權威人士」來決定共識。--$\int$（☎）dt 2022年10月19日 (三) 20:03 (UTC)

個人對「複核審查小組」在FAC的角色理解為：檢查各條目是否即時不合規，且只有在即時不合規的情況下才可行使「落選權」。當選方式仍採用投票制，若一條目即使符合標準但未達一定票數仍落選。另外還是同一句話，我對GA跟DYK的相關提案沒有意見。--$\int$（☎）dt 2022年10月19日 (三) 20:22 (UTC)

看來我需要明確(－)反对現行的投票制。恕我直言，「沒有爭議」不見得是什麼好事，閣下覺得投票制沒有爭議，那是因為目前的投票制中審閱者不需要仔細檢查條目就能入選，「爭議點」都不被發現當然「沒有爭議」。FAC的目的是檢查條目「符合多少FA標準」，而不是投票制依賴的「多少人覺得FA符合標準」。即使「複核審查小組」也無法完全解決這個問題，很多條目的問題不是「即時不合規」，而是有不少問題以至於未達到FA標準，這不是增加一個攔截「即時不合規」條目的小組就能解決的問題。--BlackShadowG Slava Ukraini! 2022年10月20日 (四) 03:08 (UTC)

(！)意見承Black閣下所言之，關聯衍生之似乎為評審方面，在現行情況下，其投票體系和小圈子編組等特定問題本身即有所爭議，

可能研究對應之監察或覆核機制等，修正需明示當期參與之個體統計數之地位、以及評審組定論之標準地位，列明相關地位在有關特定情況下，必須基於條目內涵或專業等差異而對應調整當期評核檢視之尺度，並約定如需採用特定成員編組化之覆核等措施、必須不抵觸到條目內涵或專業等本身所具之合乎其內涵或專業等之採編知識尺度。

以上為暫定所建言之，謹供共議。--約克客（留言） 2022年10月20日 (四) 03:19 (UTC)

關於這點「目前的投票制中審閱者不需要仔細檢查條目就能入選」我還請您舉證，因我不見有這類情況發生。折毛事件上面有解釋過了，並不是水票的問題，而是當時社群絕大多數都無法辨別該條目的假資訊。這個問題自認用「複核審查小組」即可解決。

另外「FAC的目的是檢查條目『符合多少FA標準』，而不是投票制依賴的『多少人覺得FA符合標準』」本身就是一個奇怪的比較方式。若一FA符合標準則其應符合了許多FA標準中列出的諸多標準，多人認為一條目符合FA標準反而讓一FA當選更為嚴格。還有個人認為共識比標準更重要，若改為審議制勢必限縮其他參與者在FA中表示支持一條目當選FA的能力。讓決定和辨別共識從明文規定變成由「人」決定（協調員也是人，只要是人必定出錯）並不是好事，所以重要的是風險最小化。--$\int$（☎）dt 2022年10月20日 (四) 16:21 (UTC)

難道不覺得有點自相矛盾嗎？你支持所謂「複審組」，並且承認有許多可能連GA都不符合的條目因為水票問題而上了FA，但卻又認爲現在的FAC沒有任何問題。就算是投票沒有問題，但此討論中已經多次提到共識討論制的優點和好處，而有人去反駁這些觀點，並指出投票制相比共識討論之下的優點了嗎？我可不可以把現在討論「FAC投票是否存在問題」這種無意義的討論視爲稻草人論證呢？說到最後，到底對於FAC試行一次、一個負責人有什麼具體意見？難道你是不想看到共識制成功？還是你篤定共識制一定會失敗？無論如何我都很疑惑爲什麼如此push back這個提案，而對我來說「不願走出舒適區」都難以解釋這種行爲。--0xDeadbeef（留言） 2022年10月20日 (四) 17:31 (UTC)

FAC就機制上而言是沒有問題的，但不代表不能在這個機制之上建立其他能幫助這個機制運行更好的東西。對我來說，審議制相當於把評選「打掉重練」，且我也有指出「投票制相比共識討論之下的優點」，並指出共識討論的一些問題（如協調員獨大，可自行決定共識、有償協調員而導致協調員和評審員狼狽為奸、各評審員因其理據不同而在決定共識中不享有同等地位等問題），這些問題直到現在我還沒看到令人信服的回應。另外有許多可能連GA都不符合的條目因為水票問題而上了FA亦是為何FAC重審機制存在的原因，並不衝突。

據我理解，複審組只能落選一條目，不能當選一條目。--$\int$（☎）dt 2022年10月20日 (四) 19:48 (UTC)

“目前的投票制中审阅者不需要仔细检查条目就能入选”这点根本不需要我来举证吧，阁下觉得投下yesFA的编者一定仔细检查过条目了吗？再极端点说，一篇条目就算8名编者都没有看过条目投yesFA，条目照样能入选。

“FAC就机制上而言是没有问题的”这句话在大前提上就是不正确的，阁下认为FAC“没有问题”是说其“没有争议”，不用仔细检查条目当然没有争议。

至于您提到的共识讨论的一些问题（如协调员独大，可自行决定共识、有偿协调员而导致协调员和评审员狼狈为奸、各评审员因其理据不同而在决定共识中不享有同等地位等问题），我可以说，共识本身就伴随着争议，无论在互助客栈还是其它地方，只要有反对意见，争议就会存在，即使是让管理员来结案，也没法让所有人都信服。共识制FAC也是如此，有争议不是件坏事，这说明条目被仔细检查过才会引发争议，我也很乐于看到这种争议的出现。况且，有争议的条目其自身肯定也是有问题的，如果一篇条目收到大量的支持/反对意见，协调员再“独大”/“有偿”也没法改变既定的结果；真正会引发争议的只有那些支持和反对意见共存的条目，只有这些条目的结案会给协调员判断的空间，按照共识制的规则，这种条目通常会落选，在落选后的时间内，主编完全可以改善条目，把争议的问题去除再来提名，这是件好事。--BlackShadowG Slava Ukraini! 2022年10月21日 (五) 00:04 (UTC)

若是照您這麼說，我並無法得知共識制究竟有何好處。您覺得現在投票制不行（也算是產生爭議了，不然我們也不會在這裡討論），但共識制（據您所說）亦會導致爭議，「因為共識本身就伴隨爭議」，造成之後還會有人在這裡繼續討論共識制的爭議/問題。

還有，我並非認為共識制在中維無法施行，但有足夠理由相信共識制不適合當前維內風氣（包括用戶素質皆和英維非常不同，@Sidishandsome：這前面也有提到）、造成的麻煩可能比現有投票制還要多（可能的「濫權」、「不信任」等等，這我不列舉，您可去看前面第一次提出時反對聲浪有多大）且沒有任何理據表明審議制能有效遏制折毛事件再次發生（您可以說英維有經驗，但英維跟中維的社群組成並不一樣〔最明顯的：英維有arbcom，而中維沒有〕，建議不要隨便抄別人）。

一言以蔽之：弊大於利。另外以上這些並不是一次試行就能發現的問題，需要長期/反覆的試行而有朝一日（肯定不是只有施行一個月，甚至一年可能亦有不足）才能施行。若是根本不知道甚麼時候以上問題才能看到解方則個人認為無需浪費時間。--$\int$（☎）dt 2022年10月21日 (五) 03:13 (UTC)

@BlackShadowG：的觀點其實諷刺地說出了投票制的一個重要優點：保證能夠行禮如儀地完成評審。即使投票人全都是猴子，限期一到，總有一個結果，就可以照流程跑下去。搞共識制，就有爭議，就有可能產生無結論的情況。如果找不到資深的主委來評斷，評審就有可能無限延長下去，等待有才之士的出現。就行政來說，這當然不是什麼好事。互助客棧和VIP就是這類長期無結論案子的集中地。--Temp3600（留言） 2022年10月21日 (五) 14:11 (UTC)

如果從一家產出「條目」的公司來說，「照流程跑下去」的確是優點，但是維基百科不強迫任何人參與，又沒有KPI，就算有著超越英維的宏願也只能算個人口嗨。從認真做內容，保證FA的確符合「维基百科条目之杰出典范」的角度出發，投票制不夠好，審議制值得嘗試，也是負責任的做法。

個人目前最多只評選過GA，也只參與了解的內容的評選。不過我也看過一些FA評選充滿爭議的情況，讓我以紫式部的FA和GA評選為例。「紫式部」進行過兩次FA（落選），一次GA評選（通過），FA都因為Jarodalien的評價落選，而且Jarodalien發言之前，都獲得一定的「零意見支持票」。GA那一次獲得6個「零意見支持票」，個人發現有很嚴重的翻譯問題參與到討論中。

寫在最後，維基百科不保證其內容正確無誤，甚至也沒有義務去「修改錯誤或者參與到非正式的同行評審」。從這個角度出發，投票制的確很好，反正錯了也不用負責。--Nostalgiacn（留言） 2022年10月24日 (一) 06:14 (UTC)

一人一票制與平等思想密切相關。至於齊頭式平等是否良好制度，人人負責是不是就等於人人都不負責，就是另一個故事了。--Temp3600（留言） 2022年10月25日 (二) 12:20 (UTC)

• 問題還是實質評審：協調員作為主評審員，必須有足夠的學養，才能在其他評審員意見不一時選出更有道理的一方，正如法官本身必先是優秀的律師。如果希望推動評審制，現在是應該尋找人才，準備通訊名單，並思考那些主題可以找誰來當主委，而不是討論主席團要有多少人：一個看版與一堆堆看版效果一樣。--Temp3600（留言） 2022年10月19日 (三) 11:11 (UTC)

  GA和FA現在的評審員要求是「編輯註冊7日且編輯次數達50次的使用者」，本來就很水了。--Nostalgiacn（留言） 2022年10月19日 (三) 15:00 (UTC)

  是否因應在當期評審個案之情，對應設立通識提問之簡易遴選流程？--約克客（留言） 2022年10月20日 (四) 03:21 (UTC)

  可以考虑在评审的时候临时召集一两位熟悉相关领域条目编写的编者征取意见，就像你之前提到的，臭皮匠和诸葛亮的情况。常驻协调员要处理所有的评选条目，临时召集来的编者只需要在相关领域的评选出现时才来，协调员是投入（commit），其他评审含被召集人是参与（involve）。如果你要说会这个方向的编者只有提名人的话，其实在论文同行评审中最最冷门的方向也是差不多的情况。--MilkyDefer 2022年10月21日 (五) 02:20 (UTC)

  那萬一那段時間專家沒有上線那怎樣辦?以中維的人手，其實只能靠行政排班表來補足：接到評審要求後，先由普通評審員預審，排除格式、來源問題，然後預約主委來診症。要是沒有醫生來，或者搶不到號呢?那就只好回家繼續等了。--Temp3600（留言） 2022年10月21日 (五) 14:21 (UTC)

  如果沒有主審的情況下，可以讓協調員按現有意見來判斷，這就等於書記兼任主席，那可比現在的投票制糟糕多了。--Temp3600（留言） 2022年10月21日 (五) 14:24 (UTC)

  条目评审也不是搞得这么等级森严的吧？熟悉该领域的编者也不见得需要与其他编者要具有某种上下级关系；所谓的协调员，或者说，召集人，发出邀请让他们得知有他们可能熟悉的条目在进行评审。不见得他们就会成为听取下面普通评审员汇报工作的那种“主审”。但是他们的意见可以给协调员很重要的参考是不错的，有熟悉主题的人的认可的话，协调员做出判断也会更有把握一些；熟悉主题的人长期不出现的话，评审就会被拉长，要么更多普通人加入审阅提高置信度，要么这种“专家”出现。考虑到现在英维的FA最久的能拖三个月，可以预见这种事情会发生但是不太至于会导致灾难。FA评选数量本身就比较少，姑且是还能经得起这种延迟的。--MilkyDefer 2022年10月21日 (五) 14:54 (UTC)

  MilkyDefer說得很好。然而社群是否願意接受一場FA辦三個月?--Temp3600（留言） 2022年10月22日 (六) 14:54 (UTC)

  这个问题我不能替代社群回答。目前而言我是能接受的，我不能替代大家的看法。等其他人怎么说吧。--MilkyDefer 2022年10月22日 (六) 15:20 (UTC)

  我也能接受，FAC的所需时间的变长也代表着FA的评选标准以及条目质量的提高。再者，难度有哪家期刊同行评审几天就能完成的吗。--BlackShadowG Slava Ukraini! 2022年10月23日 (日) 02:27 (UTC)

  回覆一下兩個評論：

  保證能夠行禮如儀地完成評審。即使投票人全都是猴子，限期一到，總有一個結果，就可以照流程跑下去。搞共識制，就有爭議，就有可能產生無結論的情況。如果找不到資深的主委來評斷，評審就有可能無限延長下去，等待有才之士的出現。就行政來說，這當然不是什麼好事。互助客棧和VIP就是這類長期無結論案子的集中地。

  MilkyDefer說得很好。然而社群是否願意接受一場FA辦三個月?

  目前的論點是關於所謂「個別條目在審議制中產生爭議」的問題。對此我有以下幾個回覆：

  1. 既然這種無結論案子這麼多，意思是VIP和互助客棧也應該投票制嗎？這種論證很奇怪，因爲在我看來，維基百科是不需要持續產出FA的。FA到最後不就是一個條目右上角的一個五角星嗎？但是如果把中心放在「FA產出效率」上，那是不是就是想要引發FAC體制內的編者的反對呢？從我第一個問題應該就能看到這種比喻的問題了吧？共識制所謂的「無結論」情況指的是「no consensus」的結果，而對我來說，能把一些原本是noFA結果的條目變成no consensus是一個改善，因爲它能告訴編輯條目在於yesFA的邊緣，而更多的改善則能夠臨門一腳進入FA範圍。而對於把原來yesFA的結果變成no consensus，請看第二點。
  2. yesFA變成no consensus問題：從結果導向的角度來看的話，FA產出變少確實是不好的，但是這也可以說明社群對於FA的評選標準增高了。其實你要如果說這種轉變會把原來完美符合FA標準的條目變得no consensus，那就是在變相地說「中維FAC參與者都是猴子」這種假設是在某種層面上成立的。
  3. 「FA辦三個月」問題：這其實比較矛盾，因爲對於共識制的另一個不同意的觀點是在於「英維的東西不全適用中維」，而提出這個問題則是在隱性地將enwiki和zhwiki畫上一個等號。並且，如果你說FA可能辦到三個月，是什麼原因造成的呢？我目前能想象出來的就是討論太耗時而投票沒有那麼耗時，所以共識制討論會更長時間。但這不就代表使用共識制會更完全的對於一個條目是否符合FA標準進行評測嗎？之前有人否認投票制的人不好好檢查條目和FA標準就投票的問題，但是如果說投票制的人都很好地檢查FA標準而投票的話，那不就說明共識討論制和投票制應該需要相同的時間嗎？

  --0xDeadbeef（留言） 2022年10月22日 (六) 15:29 (UTC)

  若要討論no consensus對評選的影響應該這麼說，no consensus給人的感覺就是「不知道甚麼原因而沒有達成共識」。相對的，有一個明確的「入選」或「未入選」比較不會導致爭議（入選或沒入選肯定是有原因的）。若您也要做投票制和共識制在其他領域的比較，那為何RFA不採用共識制呢？我並不認為拿其他站務（而且類型還非常不同，那些站務是要剝奪編輯權限的站務，一次評選又不是剝奪條目入選資格）來比較是一個洽當的評判標準。正如WP:RTRL，別人闖了紅燈，但那人是警車執行公務啊。

  其實現在有沒有足夠的投票人數就另類形成所謂no consensus了，即沉默的反對（不想得罪人，但又不支持條目，免得搞得跟Sanmosa和6+一樣撕破臉），這在FAC尤其常見（這也是為何我不認為英維規則適合中維，習慣差太多了）。就如最近我修改了一篇GA後投了FAC，不少常駐FAC的編輯（如SickManWP）沒有投yesFA（但也沒人投noFA），我是在私底下問才知道問題的（有人覺得紅鏈太多，有人覺得可以翻得更好）。重點是我並不認為協調員可以偵測出/發現各編者對一條目的見解。

  我認為每個人都有權表示支持、反對或所謂「沉默的反對」，不論有沒有道理。就我看來，共識制將形成另類如同互助客棧的辯論平台（即哪方比較有理），而這並不是好的現象。強制徵求編者意見可能長期來看會損害各編者之間的關係。

  另外再回應一下三個月的問題，我個人認為不是時間的問題，而是那位敢放在FAC三個月的編輯的問題。既然明明知道沒有共識上FA（不然也不會積三個月）是不是應該先撤回，改善後再重新提名呢？我認為除非是那類非常固執的編輯（到目前為止我見過最極端的是6+，但他也不會因為一次、兩次、三次投票沒上而在那邊有怨言），不然應該也要明白一個人佔掉FAC三個月的資源是非常自私的行為。--$\int$（☎）dt 2022年10月25日 (二) 03:28 (UTC)

  所以你覺得沉默的反對比能在共識制上評論好嗎？現在的投票制本來已經邊緣化那些不投yes或no而只想評論的人了。至於若您也要做投票制和共識制在其他領域的比較：是Temp3600先說互助客棧和VIP就是這類長期無結論案子的集中地我才回覆的。關於RFA採用共識制的問題，我個人認爲能採用是好的，因爲英維也採用共識制。並且如果你讀一下你維的WP:RFA界面也能看到行政員負責在管理人員申請程序結束後，依照共識賦予當選人管理員或行政員權限。此外，行政员負責在困難的情況下決定投票共識及結論，所以一直以來是你覺得RFA就是超過百分比就自動通過嗎？至於你舉一個你認爲比喻不當的例子就能證明我的比喻不當的論證我無語了。我已經決定不再對你的評論回覆，因爲你的這些評論在我看來和「爲了反駁而反駁」而不是真正考慮別人的意見，並且我繼續回覆沒有任何意義。我也不指望你維能因爲WP:NOTBURO作出哪些改變，之前的一個在跨維基活躍的用戶早已從所有項目隱退了，我看我單一專注英維也是遲早的了。--0xDeadbeef（留言） 2022年10月25日 (二) 05:10 (UTC)

  那好啊，比中国人更看重人际关系以及读空气的日本人他们的制度又是什么呢？

  • 支持票通常都带上长篇大论
  • 投票持续最长三个月，特殊情况可延期一个月
  • 在上述期限内的任意时点达成“支持票三票且占有效总票数四分之三之上”的状态且持续一个礼拜即告入选。
  • 满足下列任意情况者快速落选：
    • 反对票至少三票且维持一个礼拜
    • 没有其他支持票且提名者撤回提名
    • 提名者是傀儡账号被不限期封锁，没有其他支持票

  现在论支持票是投一个yesFA走人，又说不能走讨论制度，两边都取不到好，真的要成文明洼地了。--MilkyDefer 2022年10月25日 (二) 05:19 (UTC)

  我不认为“沉默的反对”在FAC中是需要考虑的（无论是投票制还是共识制），既然对被评选的条目有意见，就应该在评选中提出来，既然无意提出自己的意见，就不应指望自己没提出的意见被纳入考量。协调员没有义务侦测出/发现各编者对一条目的见解，他们只需要依据提出意见的用户做出判断。

  鄙人不太认同共识制将形成另类如同互助客栈的辩论平台这一观点，共识制FAC不是正方与反方的“辩论”，且与客栈和RFA有本质上的不同。共识制FAC是反方指出条目不合标准的地方，让主编来改善，只要改善完成，再多的反对意见都可以解决，而不需要正方来“辩论”。--BlackShadowG Slava Ukraini! 2022年10月25日 (二) 10:23 (UTC)

  先回應一部分：

  有部份站務的確使用投票方式決定結果，例如维基百科:投票/二十週年紀念識別標誌就以投票方式產生。我無意詳細討論那種場合使用何種方式較有利，僅指出不同的決定方式皆有其優勢。

  FAC的目的之一當然是引起編者的反對，以進一步改善條目。編輯者們積極提出意見正說明社群活躍，氣氛良好。然而，世上沒有免費午餐，所有制度皆有成本。

  舉例來說，高考制度儘管有各種害處，在行政成本上有其重大優勢：單憑一個分值就能處理大學分派，以致作為對一個人終生學術水平的評估。投票制儘管將猴子當成人看，在保證明確得出結果這一點上可是很優秀。

  我會將BlackShadowG的說話反過來理解：如果要提高FA的評選水平，評審時間就必須延長，這就是代價（之一）。目前的FAC能夠在極短時間內處理某些冷門評審主題，正是將猴子當成人看，硬生生將no conenesus扭轉成yes FA. 這不是什麼好方案，但至少在行政上處理了問題。改成評審制很好，提高評審水平也很好。但誰來排班表？

  「英維的東西不全適用中維」，我覺得我們可以再悲觀一點，如果三個月後評審都辦不完要怎樣辦。在理想情況下，「共識討論制和投票制應該需要相同的時間」。然而，投票制可以犠牲品質來換取速度；共識討論制要麼堅持等待討論結果，要麼將向獨裁制轉化。這可比投票制的問題嚴重多了。--Temp3600（留言） 2022年10月25日 (二) 12:56 (UTC)

  能理解你的想法，感謝回應。在我看來我們的意見分歧應該在於品質和速度的權衡問題。之前也用過折毛事件作爲例子，而想表達的並不是共識制便能夠完全阻止這種事情的發生，而是說明共識制帶來的潛在品質可以更好地去提前發現這些問題，而不用像折毛一樣發現之後需要大量時間來清理打掃。也許這樣相比之下，共識制也能帶來省去一部分這種時間的好處。至於共識制是否能夠真正帶來更好的品質，這也是試行計劃想要證明的一部分。--0xDeadbeef（留言） 2022年10月25日 (二) 13:30 (UTC)

  可以補充：不單是速度，還有「穩定」。無論評審結果如何，只要努力兩個星期，事情就總算結束了。比如說只有暑假有空的話，大可以在八月中前提交評審，保證在開課前完成FAC。--Temp3600（留言） 2022年10月26日 (三) 15:23 (UTC)

  你說的對，但是我仍然覺得速度和穩定的問題都不大。共識制並不需要原來提交FAC的人在FAC的全程都跟進並且作出必要的改變。這和WP:OWN和WP:CHOICE都不相符。共識制作爲一個討論的平臺也許會激勵其他用戶在申請人Wikibreak的時候幫忙改進並提升至FA。我還認爲，如果共識制的一個FAC在兩個星期後都還沒有結果的話，在投票制也不一定就能有結果。--0xDeadbeef（留言） 2022年10月26日 (三) 15:37 (UTC)

  絕大部分情況還是主編按FAC的意見來改進條目的，長期不上線會有麻煩。--Temp3600（留言） 2022年10月26日 (三) 15:44 (UTC)

  繼續回應：

  「沉默的反對」是一個問題，但暫時沒有甚麼好方法。我個人在這類問題上的見解是引入匿名發言。不說話，主編就算希望改善條目，也不知從何入手。然而，即使在目前制度下，編輯仍能通過意見及中立票來影響「選情」，在DYK中，基於同情票問題，不少編者都改用意見代替反對票，只有對方拒絕改善時才會投反。FAC中大家不寫意見，只能說是懶惰了。

  至於「文明洼地」，這不就明擺着嗎。如果諸君願意投票時認真一點，嚴肅看待公民責任，今日何以至此？--Temp3600（留言） 2022年10月26日 (三) 15:41 (UTC)

  最後（？）說點「建設性想法」：

  事實上，我確信這次試行將會成功。只要選擇一個合適的時間，確保有足夠的大佬願意撐起場面，事先考慮評審條目的主題，要籌備一次FAC並不困難。困難在於日後千奇百怪的FAC出現時，評審制是否能夠承接這些工作量。

  因此，這次試行的成果與全面推展共識制可說是沒有關連，最多就是證明中維還是有一些認真的編輯者。

  目前而言，可以考慮將共識制拆分，僅於部分較活躍的專題組實行。比如ACG條目，MilkyDefer、Lopullinen等都可以當主委，要是沒空，可以拉cwek、eric liu來，應不致出現主委旁落，被外行人掌握的局面。至於其他主題，保持現狀為宜。--Temp3600（留言） 2022年10月26日 (三) 16:01 (UTC)

@MilkyDefer：目前未見人反對原本的提案，而ATannedBurger也在上面說過部分支持。因爲是試運行，還需要公示嗎？--0xDeadbeef（留言） 2022年10月26日 (三) 16:05 (UTC)

确实我们好像花了很多精力去解释可持续性的问题，但这跟仅仅一次的试行可以说是毫不影响。不过Temp3600说的也对，这次试行还是选择一篇相对熟悉的领域（对我而言是ACG与电脑）来审，而不是最开始设定的“无差别选择第一篇提交的条目”会不会好一些？如果试行的条目对领域存在限制的话，到时候我们就必须等待一篇相关领域内的条目提交到评选来，这个延时就不在可控范围内了。--MilkyDefer 2022年10月27日 (四) 10:14 (UTC)

西京的消歧義爭議

初期討論

• 目前發生爭議的頁面：西京。
• 我依照WP:DABSTYLE，回退U:RekishiEJ的Special:diff/73966392及Special:diff/73966924兩筆編輯。
• 參閱Talk:西京，我們暫時無法達成共識。
• 請社群提供意見，西京 (虛構城市)是否可以豁免WP:DABSTYLE的規則。

--CaryCheng（留言） 2022年10月6日 (四) 09:26 (UTC)

• 改個寫法「賈平凹小說《廢都》中的虛構城市，主要參照西安」這樣就好了吧？--迴廊彼端（留言） 2022年10月6日 (四) 09:44 (UTC)

感謝閣下的意見，閣下的寫法就是U:RekishiEJ被我回退的的Special:diff/73966924這筆編輯，而這個寫法終究違反了WP:DABSTYLE中只留一個引導連結的規則。--CaryCheng（留言） 2022年10月6日 (四) 14:35 (UTC)

User:CaryCheng我的版本前方並沒有「西京 (虛構城市)」這個紅連，類似寫法出現在Wikipedia:格式手冊/消歧義頁#链接至主要条目中天花的最後一例。--迴廊彼端（留言） 2022年10月7日 (五) 02:15 (UTC)

感謝閣下的意見。首先Wikipedia:格式手冊/消歧義頁#链接至主要条目還未採納為正式指引，僅供參考；其次我認為這種寫法比較像辭典，並不適合消歧義頁面；另外，U:Cdip150提出的看法似乎可行，我準備提案修改WP:DABSTYLE條文。--CaryCheng（留言） 2022年10月7日 (五) 17:15 (UTC)

• (！)意見，「一般」意味着並不是硬性規定，而且把該項目的藍連全部移除，其實又不符合「請至少包含一個存在的連結」，RekishiEJ君留下藍連的做法反而比較合規。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年10月6日 (四) 09:50 (UTC)

• User:Cdip150其實我有留，只是先前用nowiki語法包起來而已。--迴廊彼端（留言） 2022年10月6日 (四) 11:09 (UTC)

• 敝人的意見是在回應CaryCheng的做法，不是　閣下。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年10月6日 (四) 11:23 (UTC)

• 感謝街燈閣下的意見，我與閣下為了這個WP:DABSTYLE已在數個條目中爭議過，正好藉這次機會與社群討論形成新共識。
• 閣下說「一般」意味着並不是硬性規定，但是閣下與U:RekishiEJ均沒有說明西京 (虛構城市)是哪種特殊情況而不是一般情況。
• 閣下引用條文「請至少包含一個存在的連結」，這句條文來自Wikipedia:消歧义#消歧义的意义，原文是：

“ 如果消歧义页面包含不存在的条目，这时要小心，因为条目可能根本没人会写，因此也就没有消歧义的必要。
...節刪...
如果你一定要建立一个消歧义（当然这也是你的自由），请至少包含一个存在的链接（条目）。 ”

可知這句條文的要求是「消歧義頁面」應該「请至少包含一个存在的链接（条目）」，而不是要求「消歧義項目」「至少包含一个存在的链接」。--CaryCheng（留言） 2022年10月6日 (四) 14:35 (UTC)

一般情況下，消歧義項目可透過直接點擊藍連來讀取資訊，但是紅連不能，已經是個不折不扣的非一般情況了。又拿一個老薪常談的例子：「公園街 (基隆市)，臺灣基隆市仁愛區街道，得名自該街道旁、現已不存的高砂公園」，如果刪掉高砂公園的藍連，我不會覺得合適。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年10月6日 (四) 14:54 (UTC)

請參閱WP:DABSTYLE：

“ * 每項消歧義項目一般應該只有一個引導連結；多餘的連結將混淆讀者。例如：

• 马鞍山市，中国安徽省所辖的地级市。
• 马鞍山 (昆山市)，位于中国江苏省昆山市的一座山，盛产昆山石。
• 马鞍山 (昆山市)，位于中国江苏省昆山市的一座山，盛产昆山石。

”

指引寫得很清楚，即使马鞍山 (昆山市)只有紅連，該項目中仍然應該維持只有一個引導連結。--CaryCheng（留言） 2022年10月6日 (四) 14:59 (UTC)

马鞍山 (昆山市)後面的藍連與項目自身沒有太大關聯，添加藍連是會「混淆讀者」；但高砂公園與公園街 (基隆市)有明顯關聯，所以這種藍連並不構成「混淆讀者」，而且由於是唯一的藍連，故更加沒有構成「多餘」，所以援引的條例根本不適用。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年10月6日 (四) 15:14 (UTC)

昆山市跟马鞍山 (昆山市)就是直接關聯呀；另外，指引也沒有以「有沒有太大關聯」作為豁免規則的條件。也許過去社群曾經討論達成共識？請提供相關紀錄以供參考。--CaryCheng（留言） 2022年10月6日 (四) 15:30 (UTC)

昆山市條目內完全沒有提過马鞍山 (昆山市)，根本不能說有關聯。注意「混淆讀者」是要件，要證明的是高砂公園這個藍連到底有沒有也犯了「多餘的連結將混淆讀者」，如果沒有，根本不需要特別豁免也不會犯規。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年10月6日 (四) 15:44 (UTC)

閣下這個論點很好，應該可以說服我。但是我說個題外話，高砂公園中提到公園街的那段話，沒有標註來源，條目中的來源也沒有提到公園街的公園就是高砂公園。所以只要條目裡寫了一段話，不管有沒有來源佐證，都可以視為有關聯？--CaryCheng（留言） 2022年10月6日 (四) 16:28 (UTC)

先為高砂公園補了個來源。您這個是另一層面的問題了（因為即使某一消歧義項本身就是一個已存在的條目，假如該條目裏的內容都沒有來源，一樣會出現這樣的問題，這並不是紅連項目附上有藍連的描述才專有的問題），大概也跟正式條目中沒有來源的內容應該要怎樣處理一樣很難有統一答案。如果因為沒有來源的內容而造成了明顯可能錯誤的消歧義項，應該個別地抽出來研判。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年10月6日 (四) 17:00 (UTC)

同意。--CaryCheng（留言） 2022年10月7日 (五) 17:15 (UTC)

為什麼不直接寫"廢都，賈平凹獲費米娜外國文學獎小說，西京為小說中的故事發生地。"就好了，一來我不信西京 (虛構城市)有人會跑去建（然後就有人跑去了），二來是憑啥所有虛構城市的西京就得是賈平凹小說裡的那個西京？--Anghualee（留言） 2022年10月6日 (四) 11:41 (UTC)

• 感謝閣下的意見，只是這個作法違反WP:D，條文說了：「消歧义在维基百科中指消除由于「一词多义」所引起的歧义。这种情况可以通过建立消歧义页来实现。...節刪...編寫消歧義頁時，注意如果没有混淆的可能，尽量不要加消歧义。」
• 《廢都》這本小說並沒有別名「西京」，沒有混淆的可能，因此不應該加入「廢都」作為消歧義項目。
• 另外，並非所有虛構城市的西京就得是賈平凹小說裡的那個西京，而是目前沒有任何一個虛構西京佔用西京 (虛構城市)，才先指給賈平凹小說裡的那個西京。閣下當然可以要求這個項目改為西京 (賈平凹)或是西京 (廢都)，但是這稍微與目前的討論偏題，可能要另外開話題討論。--CaryCheng（留言） 2022年10月6日 (四) 14:35 (UTC)

  因為我覺得廢都除了是書名外，廢都二字本身指的就是故事發生點的西京，所以我覺得直接用廢都是沒有問題的。如果要堅持廢都就只是個書名，不涉指故事發生地的話，亦可以用"《廢都》小說中的故事發生地。"整句話做為消歧義內容。--Anghualee（留言） 2022年10月7日 (五) 09:15 (UTC)

感謝閣下回應，閣下的建議與U:迴廊彼端相似，我認為這種寫法比較像辭典，並不適合消歧義頁面。另外，U:Cdip150提出的看法似乎可行，我準備提案修改WP:DABSTYLE條文。--CaryCheng（留言） 2022年10月7日 (五) 17:15 (UTC)

實際上該項目根本就不應該留下，因為我沒見到足以收錄單一小說作品背景城市之理由。在條目中說明虛構之所謂「西京」與西安之關聯，才是比較妥當的。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年10月6日 (四) 13:01 (UTC)

感謝閣下的意見，其實我也想這樣做，兩年前我都以「依WP:DABSTYLE及WP:DDD，不要增添不含連結的項目，不要增添不會成為好條目的紅字連結。」刪除這些項目，後來遇到編輯爭議，現在只好把這些紅字項目都留著，盡量把消歧義頁面改得比較符合WP:D的規則。--CaryCheng（留言） 2022年10月6日 (四) 14:35 (UTC)

(＋)贊成，基本上我覺得是要弄個兩造可以接受的消歧義文句才會提可能適合的語句，如果刪除也是一個選項，當然刪除更好。--Anghualee（留言） 2022年10月7日 (五) 09:17 (UTC)

感謝閣下的意見，只是在消歧義頁面刪除紅字連結消歧義項目容易引發編輯爭議。U:Cdip150提出的看法似乎可行，我準備提案修改WP:DABSTYLE條文。--CaryCheng（留言） 2022年10月7日 (五) 17:15 (UTC)

---

上面有精力說那麼多，為何不直接為西京 (虛構城市)創建條目？創建了，問題就解決，當然如果條目質量不足被刪又是另一回事。--Nostalgiacn（留言） 2022年10月7日 (五) 05:31 (UTC)

可以先暂时建成重定向，然后消歧义里面的其他链接拿掉。--GZWDer（留言） 2022年10月7日 (五) 13:46 (UTC)

感謝兩位的建議，這樣做可以暫時解決西京 (虛構城市)的爭議，但是如公園街 (基隆市)的其他項目依舊可能再度發生爭議。U:Cdip150提出的看法似乎可行，我準備提案修改WP:DABSTYLE條文。--CaryCheng（留言） 2022年10月7日 (五) 17:15 (UTC)

提案條文

為使WP:DABSTYLE說明更具體，避免再度發生Special:diff/67511475及Special:diff/73966924的編輯爭議，提案修訂WP:DABSTYLE條文。

現行條文 每項消歧義項目一般應該只有一個引導連結；多餘的連結將混淆讀者。例如： 马鞍山市，中国安徽省所辖的地级市。 马鞍山 (昆山市)，位于中国江苏省昆山市的一座山，盛产昆山石。 马鞍山 (昆山市)，位于中国江苏省昆山市的一座山，盛产昆山石。

提議條文 每項消歧義項目一般應該只有一個引導連結；多餘的連結將混淆讀者。例如： 马鞍山市，中国安徽省所辖的地级市。 若該項消歧義項目尚未建立條目（紅字連結），才可加入一個與其高度相關的引導連結。例如： 马鞍山 (昆山市)，位于中国江苏省昆山市的一座山，盛产昆山石。 马鞍山 (昆山市)，位于中国江苏省昆山市的一座山，盛产昆山石。 公園街 (基隆市)，臺灣基隆市仁愛區街道，得名自該街道旁、現已不存的高砂公園。

請社群提供意見。--CaryCheng（留言） 2022年10月7日 (五) 18:18 (UTC)

馬鞍山還是跟馬鞍山放一起吧，公園街可以增加一個多幾個內連然後刪除線釣的例子以及增加一個移除內連也可以的例子，跟馬鞍山一樣擺三個。--Anghualee（留言） 2022年10月8日 (六) 11:19 (UTC)

那我建議這樣改，但覺得公園街增加一個多幾個內連然後刪除線釣的例子就夠：

現行條文 每項消歧義項目一般應該只有一個引導連結；多餘的連結將混淆讀者。例如： 马鞍山市，中国安徽省所辖的地级市。 马鞍山 (昆山市)，位于中国江苏省昆山市的一座山，盛产昆山石。 马鞍山 (昆山市)，位于中国江苏省昆山市的一座山，盛产昆山石。

提議條文 每項消歧義項目一般應該只有一個引導連結；多餘的連結將混淆讀者。例如： 马鞍山市，中国安徽省所辖的地级市。 马鞍山 (昆山市)，位于中国江苏省昆山市的一座山，盛产昆山石。 马鞍山 (昆山市)，位于中国江苏省昆山市的一座山，盛产昆山石。 若該項消歧義項目尚未建立條目（紅字連結），才可加入一個引導連結，且所引導連結的條目中應有提及該項消歧義項目（紅字連結）而又有可靠來源支持的內容。例如： 公園街 (基隆市)，臺灣基隆市仁愛區街道，得名自該街道旁、現已不存的高砂公園。 公園街 (基隆市)，臺灣基隆市仁愛區街道，得名自該街道旁、現已不存的高砂公園。

--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年10月8日 (六) 12:13 (UTC)

我想了一下，需要為「高度相關」做明確定義，建議再修訂如下：「...，才可加入一個與其高度相關的引導連結{{noteGT|「高度相關」定義為引導連結條目中應有提及該項消歧義項目（紅字連結）的內文，且該段內文有可靠來源支持。}}。例如：...」--CaryCheng（留言） 2022年10月8日 (六) 13:43 (UTC)

改了，也試着不用註解來表明有關規定。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年10月8日 (六) 14:55 (UTC)

感謝，(＋)支持這個版本。--CaryCheng（留言） 2022年10月8日 (六) 15:07 (UTC)

• 支持街燈的論證。--Temp3600（留言） 2022年10月8日 (六) 13:52 (UTC)

為什麼只是規定死只有一個呢？比如假設有個李杜的消歧義頁：

• 大李杜：唐代詩人李白與杜甫的合稱。
• 小李杜：唐代詩人李商隱與杜牧的合稱。
• 《後漢書》有李杜傳，為李固、杜喬合稱。

難道我要強行只保留當中的一個引導連結？--Ghren🐦🕑 2022年10月9日 (日) 06:32 (UTC)

或許不應該寫死連結數目，而是表明確實有需求且數量適當即可。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年10月9日 (日) 10:11 (UTC)

我講的壞心一點，就是如果你真的有多個合適的引導連結是跟紅鏈嚴重相關的話，好比說"李杜 (後漢)為《後漢書》李杜傳中的李固、杜喬合稱"，那就只留紅鏈當個陷阱坑人進去寫吧。--Anghualee（留言） 2022年10月9日 (日) 10:51 (UTC)

查了一下，《後漢書》的李杜沒有關注度，但是李固、杜喬兩個條目作為引導連結，明顥是有參考價值的。上面的公園街 (基隆市)也沒有關注度啊。--Ghren🐦🕓 2022年10月16日 (日) 09:07 (UTC)

• 首先，是的，依照目前WP:DABSTYLE的規則，就是只保留一個。
• 其次，WP:DABSTYLE是在Special:diff/11596354中由U:RalfX加入，未留下編輯摘要；Special:用户贡献/RalfX看來U:RalfX已停止編輯維基百科；在Wikipedia talk:消歧义/存档1中也沒有過去社群的討論紀錄。當初為何設定只有一個引導連結已不可考。
• 第三，我認為只保留一個引導連結是好的做法，符合WP:D整體條文精神。

--CaryCheng（留言） 2022年10月9日 (日) 14:41 (UTC)

根本上，其實我連「多餘的連結將混淆讀者」也不理解，讀者要看的連結已經在句子之首了，後面加上連結為什麼要混淆讀者呢？讀者不會看連結字眼是什麼的嗎？--Ghren🐦🕓 2022年10月16日 (日) 09:05 (UTC)

用語可以改一下，原意應該是指讓內容更集中，簡潔明了。就個人觀感而已，進入消歧義頁是想找到自己想要找的頁面，而不是被簡介部分的一堆內部連結分散注意力（指會誘導人訪問這些內部連結）。--Nostalgiacn（留言） 2022年10月19日 (三) 12:02 (UTC)

(！)意見同ghrenghren，另一個例子是宋元：「宋元 (朝代)，中國歷史上宋朝和元朝的合稱。」，如果把宋朝和元朝其中一個去掉，都不是好的做法。即便當初為何設定只有一個引導連結已不可考，但不可考不是合理維持的理由，在這種情況下非常沒必要去執著原有條文的精神。--Maccomcre（留言） 2022年10月16日 (日) 03:38 (UTC)

XX系列（遊戲、影視、文藝作品系列）的書名號位置？

請問遊戲、影視、文藝作品系列（的正文，不含條目標題）需要加上書名號嗎？如果要加，「系列」二字該被囊括在書名號之中嗎？MOS:書名號僅提及「系列著作的選題名」，但是有些系列作品的名稱本身沒有「系列」二字，例如：星海爭霸系列、紅色警戒系列的各項遊戲名稱皆沒有「系列」二字。

各位認為下列哪一項比較好：

1. XX遊戲/電影/小說系列
2. 《XX遊戲/電影/小說》系列
3. 《XX遊戲/電影/小說系列》

在此追問：作品的infobox當中的其他作品名稱建議加入書名號嗎？--Picture GN（留言） 2022年10月6日 (四) 18:48 (UTC)

名從主人原則，如果官方出品的時候作品的命名已經帶有「系列」，那麼就用「《XX遊戲/電影/小說系列》」；反之如果作品命名本身沒有「系列」，那麼就用「《XX遊戲/電影/小說》系列」。另外，在正文段落之中完全不用書名號（即「XX遊戲/電影/小說系列」）應該是不適當的。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年10月6日 (四) 19:02 (UTC)

謝謝指教！給了我明確的條目編輯方向。--Picture GN（留言） 2022年10月7日 (五) 00:54 (UTC)

好像这类作品系列性的条目，从命名到正文中都没有没有限定使用书名号，连“XX系列”这个命名逻辑也是基于作品的系列性自行产生的。而且命名常规也没有这个要求。——Sakamotosan路过围观 | 避免做作，免敬 2022年10月7日 (五) 01:18 (UTC)

敝人糾結的點在於，該不該把「XX系列」視為創作/作品的名稱，如果是，則應該要加上書名號；如果不是，系列就不應該在書名號之中，但XX是否要加上書名號？--Picture GN（留言） 2022年10月7日 (五) 05:45 (UTC)

除非特指名称含“系列”的出版物，否则书名号内不要包含“系列”。是否加书名号看需求，是否有强调目的。--YFdyh000（留言） 2022年10月7日 (五) 06:10 (UTC)

大部分情况都是出了作品的主名，然后沿着主名衍生了多个分作品，在本站点中将这些事物概括成一个“系列”再统合编写。可能很少作品原名（或系列名）即为“XXX系列”。似乎不能一概而论规定如何添加书名号。——Sakamotosan路过围观 | 避免做作，免敬 2022年10月8日 (六) 05:55 (UTC)

出版物本身是合集可能名称有“系列”。否则不应将总结而成的“系列”归入原名。--YFdyh000（留言） 2022年10月8日 (六) 07:32 (UTC)

我使用《XX遊戲/電影/小說》系列，也建議這麼用。除非作品名本身就有系列。-KRF（留言） 2022年10月7日 (五) 05:58 (UTC)

這種情況我通常不會加上書名號。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年10月7日 (五) 06:51 (UTC)

@Cdip150、@Cwek、@YFdyh000、@Ericliu1912、@Kerolf666：或許我們可以採用折衷的方式：將XX系列視為「複合名詞」（「XX」加上「系列」），換言之，就是將其視為「與XX（通常是作品名或作品名的一部分）劇情或世界觀相通的衍伸作品」，由於此不是著作名稱，而是大眾給這些作品的統稱，因此不使用書名號，而在正文中使用引號標註。（至少正文中第一次出現要加，下文可不限制是否加註引號）

敝人想在此詢問各位對這提議的意見。--Picture GN（留言） 2022年10月10日 (一) 00:10 (UTC)

所以變成《XX》「系列」？ --窝法乙烷 儿法梦碎 2022年10月15日 (六) 04:12 (UTC)

我的想法：「XX系列」（XX不加書名號）--Picture GN（留言） 2022年10月15日 (六) 06:16 (UTC)

「XX系列」這種情況下不可能是對的，就算是複合名詞也都是「《XX》」跟「系列」的複合。--Maccomcre（留言） 2022年10月23日 (日) 09:28 (UTC)

帮助:脚注是不是需要更新？还需要讲2005年的事吗？

该页面介绍了2005年之前标记脚注的方法和如何过渡到<ref>标签，这还需要留着吗，2013年的兼容性也不用再提了吧？还是说有纪念价值？

另外的一个小问题是，该页面的例子写<ref>张三. 2005. 太阳. 学术出版社, 香港. pp. 23.</ref>，但这是很不规范的参考资料写法，现代的用法应该是用cite模板了。虽然帮助:脚注是帮助，不是指引，我觉得最好也用上现代写法。--Gqqnb（留言） 2022年10月8日 (六) 16:44 (UTC)

始終是對新手介紹怎樣用ref的地方，一來到就說用cite模板，似乎又太難了。對比英文版的en:Help:Footnotes，範例也是<ref>''LibreOffice For Starters'', First Edition, Flexible Minds, Manchester, 2002, p. 18</ref>，也是不用cite模板的。2005年舊的註腳方法到了今天倒是還有上千個條目在使用中的說。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年10月8日 (六) 17:06 (UTC)

可以调整和更新文档，但历史信息建议保留（调整位置）而非移除。cite是更规范、利于维护等优势，但顺便问一下，是否有转换参考文献文本到cite参数的工具/机器人，有时想偷懒（直接从其他学术工具导出引用），不想手动填各字段。--YFdyh000（留言） 2022年10月8日 (六) 17:27 (UTC)

目前好像只有{{Cite doi}}可以偷懶？--Anghualee（留言） 2022年10月8日 (六) 19:41 (UTC)

doi自动生成的结果有时不全，且无法即时看到结果，不太放心。里面的[7]工具听上去不错且仍在更新，有待尝试。--YFdyh000（留言） 2022年10月9日 (日) 04:52 (UTC)

學術工具導出的話，你導出成BibTeX (.bib)引用格式，它是結構化的，應該很方便地用字符串替換的方法改成cite模板。--Gqqnb（留言） 2022年10月9日 (日) 02:17 (UTC)

感谢建议。不知道是否有已知的替换工具/脚本。--YFdyh000（留言） 2022年10月9日 (日) 04:53 (UTC)

2017原始碼編輯器支援根據輸入資訊自動生成註腳，通常只需要簡單覆核，可以省去一大半力氣。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年10月9日 (日) 10:09 (UTC)

Zotero (73782253) 抓取学术参考文献很方便的，也方便转换到Wikipedia格式，官方库支持大多数英文学术网站，中文库有中国大陆几个常见学术网站。另外，维基可视化编辑中的“添加引用”，其中支持抓取的网站和Zotero基本是同步的。--Kethyga（留言） 2022年10月9日 (日) 12:20 (UTC)

能加當然好，但是會用 Cite 模板的也不見得真的有照著用，我有修復的某些亂七八糟的情況就不說了，就連我自己有時候糾結一番也只能瞎填。好比說從{{youtube}}外部資源模板改成{{Cite AV media}}引用時，有時候我會拿location屬性來放該影片的頻道連結，自首可以從輕發落嗎。--Anghualee（留言） 2022年10月8日 (六) 19:57 (UTC)

YouTube一般用cite web了吧，我没有放过频道链接。cite格式细节挺多乱填，没有具体定论和检查（某些检查也很添麻烦）。像是新闻网站A转载媒体B的新闻，我会用cite web而非cite news，B填为作者，因为我不知道是否为媒体B原稿。我很想批评的是新浪等自媒体网页填website=新浪、作者不填，冒充可靠来源。--YFdyh000（留言） 2022年10月9日 (日) 04:50 (UTC)

例如Yahoo新聞這種的，我會一樣用 Cite news，website 放 yahoo新聞，然後真正的新聞發佈者（Udn、EtToday...etc）放 publisher，用這樣來表示網站轉載，因為他有點類似於新聞發佈者放 publisher，然後外電來自於路透社的話 agency 放路透社這樣的情況。別說author跟publisher了，有放 url 我就偷笑了，一堆空引用都是靠通靈能力下去修復的，最好<ref>{{cite web|||||}}</ref>是有人看得懂這想引用什麼鬼啦。--Anghualee（留言） 2022年10月9日 (日) 10:40 (UTC)

• 但“publisher”参数似乎指发行机构（单位）而非撰稿者……
• 我还想吐槽，cite最终展示效果的字段位置和含义，有时不是很好懂。包括期刊卷号、期号等本就不好理解和识别的概念。包括书籍主编、章节作者等如何体现区分。
• 刚刚一例，大同號輕巡洋艦“皮明庥. 罗致通. 中山舰风云录. 武汉出版社. 1998-10: 138. ISBN 7-5430-1812-8.”，谁能看出这是“page=138|chapter=罗致通”，用at参数则“|at=和|page=只需其一”，用“page=138 罗致通”似乎很怪。舍弃章节标题感觉损失少许信息。或许该手动加上双引号/单书名号……似乎cite应该默认加书名号彰显这是篇名。en:Template:Cite book的chapter参数是加了双引号。

--YFdyh000（留言） 2022年10月9日 (日) 11:01 (UTC)

• 例如我用這個新聞舉例，網站（website）是Yahoo新聞、發行單位（publisher）是TVBS新聞網（標題上方）、作者或撰稿者（author）是王馨儀（標題下方）。
• 對，這就是為什麼前面有人抱怨"很不規範的參考資料寫法"，因為其實規範很多，除了腳註說明頁面中的芝加哥格式以外，還有什麼 APA 等等，你符合其中一種通常就是其他規範的不規範。Cite 那一票模板具體是用哪個規範，我也沒有深究過，但是基本上學術界搞參考文獻是會這樣搞就是了。羅致通前面是句號，所以他不會是作者，然後如果是編輯的話我記得好像不在那個位置，還會多一個"編"。我是有看過有人用 title 放例如說"《中山艦風雲錄》羅致通"之類的，至於預設加不加書名號我就沒意見了。--Anghualee（留言） 2022年10月9日 (日) 11:26 (UTC)

想做就做啊！皮明庥. 〈罗致通〉. 《中山舰风云录》. 武汉出版社. 1998年10月: 138頁. ISBN 7-5430-1812-8. 。-游蛇脫殼/克勞棣 2022年10月9日 (日) 11:32 (UTC)

既然发现英文有加双引号，我觉得是中文的cite（CS1）可能要改，而非个例问题。但书名号还是双引号，书名号是否单双转换，就有点复杂了。--YFdyh000（留言） 2022年10月9日 (日) 11:55 (UTC)

剛剛發現有個{{Cite isbn}}的模板，底下有一堆子頁面，這個模板還有在繼續使用嗎？--Anghualee（留言） 2022年10月10日 (一) 04:10 (UTC)

南社 (72601569) 有在用，删除内容前，需要清理。另外，看这个模板可以在不同条目使用。--Kethyga（留言） 2022年10月10日 (一) 04:17 (UTC)

我会使用via参数，表明网站的内容通过第三方无关的服务提供。这个参数的存在感低到大家都不记得它。--MilkyDefer 2022年10月9日 (日) 11:17 (UTC)

你說的沒錯，參數的說明的確是把 Yahoo新聞放 via 會比較正確。--Anghualee（留言） 2022年10月9日 (日) 11:40 (UTC)

如果是在yahoo!新聞看到的新聞，那麼我不贊同這麼做。以您剛剛舉的例，url直接填TVBS新聞網的網址，而不填yahoo!新聞的網址，豈不是更好？不用填via，也不必區分website和publisher。我不理解為什麼許多編輯者引用在yahoo!新聞看到的新聞，會沿用yahoo的網址。人家已經告訴你，它轉載自哪家媒體了，那麼編輯者是否應該自己去找一找被轉載的媒體報導這則新聞的自家的網址？-游蛇脫殼/克勞棣 2022年10月9日 (日) 12:25 (UTC)

能找到原始的更好，但是有时候历史新闻的话，门户网站上还有，但是新闻机构的网站（比如TVBS）可能已经无法访问了，Yahoo新闻类似中国大陆的新浪、搜狐等。--Kethyga（留言） 2022年10月9日 (日) 12:31 (UTC)

撇開轉載新聞，有時候若在Google書籍上能夠找到某本書籍，不用親自去圖書館，那當然比較方便，這時我就會填寫相應之「via」參數。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年10月9日 (日) 12:41 (UTC)

我個人會用work搭配publisher展示主從關係。 --窝法乙烷 儿法梦碎 2022年10月10日 (一) 01:09 (UTC)

這種組合我通常只用於網站文章。畢竟Google書籍只是平臺，不是真的出版者。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年10月10日 (一) 07:06 (UTC)

对的，之前我建议过“插入”工具增加该字段，不过后来没继续下去。当时讨论中也有人提到是否加单双书名号、卷号用中文表明等。via同时有局限性，某些格式会被拒绝。--YFdyh000（留言） 2022年10月9日 (日) 12:02 (UTC)

的確需要更新一下。在那個年代（2005）還沒有那麼多平台網站，電子書等平台也是越來越多。應該恰當更新引用網絡來源時的格式，如via這類參數。

另外，Help:脚注的定位很明顯不是給新人看的，內在的要求就和寫論文時引用資料的格式要求一樣。置頂也有寫明「如果您是新手，建议您阅读《Help:如何引用来源》一文。」，那邊也是寫「如果您想要了解更高级、更复杂的来源引用方式，请参考《帮助:脚注》」。--Nostalgiacn（留言） 2022年10月19日 (三) 12:29 (UTC)

OTT平台能否作為影視作品的官方網站

根據Wikipedia:外部链接#應該要連結的網址，條目應加入一個官方網站連結，而在這個請求（viu.com）。

• （支持論點）申請人主張該OTT平台是 (1) 官方設立的 (2) 唯一有介紹該作品的 網站，能視為官方網站。
• （反對論點）但該網頁本質上是線上觀看該影片，劇情介紹只是附帶的，而且僅能在香港瀏覽該網頁，違反Wikipedia:外部链接#正常情況下應避免的連結第6條「在特定區域才能瀏覽的網站」。

OTT平台大多都需要付費或有區域限制，通常違反Wikipedia:外部链接#正常情況下應避免的連結第5條及第6條，因此不能加入，但是如果能視為官方網站，則可免除該限制（該章節首段「除非是關於條目主題的官方網站，否則應該要避免」），所以OTT線上看的網站能否視為官方網站？--Xiplus#Talk 2022年10月13日 (四) 03:25 (UTC)

应该讨论的是哪些OTT平台可以作为官方网站，因为Netflix这一个例子就能回答原问题：能。--Fung_Tze-Long（留言） 2022年10月13日 (四) 04:15 (UTC)

請說明為何Netflix就可以？--Xiplus#Talk 2022年10月13日 (四) 14:12 (UTC)

如果是Netflix，就更難符合可供查證要求。舉一個台劇-村裡來了個暴走女外科作例子，條目表明此劇在Netflix上架，我有Netflix帳號但不能在非台灣IP的Netflix找到此節目（這句還可能涉及原創研究的問題）。。另外請問如何證明每一個服務地區的IP地址都可看到相關播放清單。

.

相反，規模較小的OTT則沒有這個問題，因為相關OTT只在一至三個地方提供服務且任何人都可以閲讀播放清單。--唔好阻住我愛國（留言） 2022年10月13日 (四) 16:37 (UTC)

這裡討論的是能否作為官方網站，與可供查證無關。--Xiplus#Talk 2022年10月13日 (四) 16:41 (UTC)

已在這個請求填補網站。--唔好阻住我愛國（留言） 2022年10月13日 (四) 16:51 (UTC)

原則上，只考慮機器人可否對相關網站存檔，如不能則無法引用。--唔好阻住我愛國（留言） 2022年10月13日 (四) 16:53 (UTC)

这是“外部链接”问题，不是“引用”问题（？），而且付费墙（或者常规的内容地区墙）不影响这些判断（一票的订阅类新闻都有这样的问题），——Sakamotosan路过围观 | 避免做作，免敬 2022年10月14日 (五) 01:18 (UTC)

Wikipedia:外部链接：「本指引是關於外部連結，並非來源。」--Xiplus#Talk 2022年10月14日 (五) 02:06 (UTC)

一樣logic，機器人存不到檔的話有什麼意義？況且條目內有資料需要引用相關網站，但該人沒有引用。--唔好阻住我愛國（留言） 2022年10月14日 (五) 03:19 (UTC)

为什么以机器人为准？外部链接很多是有效就能用、失效就可以撤，视频等内容也很难存档。--YFdyh000（留言） 2022年10月14日 (五) 10:25 (UTC)

如果機器人沒有權限閲讀內容，一般讀者又如何閲讀？引用白紙也可以？

即使連結失效，但有備份內容供求證。--唔好阻住我愛國（留言） 2022年10月14日 (五) 11:42 (UTC)

外链通常不限于参考求证，而是使用目的。音乐、影集、YouTube视频、Google文档等，机器人存档的部分价值常常有限，只能证明确实有过某些信息。--YFdyh000（留言） 2022年10月14日 (五) 12:16 (UTC)

以這個情況來說：

(VIU 服務地區ip) 官方網站：xx播放清單

（其他）官方網站：白紙

現在是無法證實出現過這些資訊。除非wiki可以按地區修改內容，否則(－)反对添加此外部連結。--唔好阻住我愛國（留言） 2022年10月14日 (五) 13:47 (UTC)

網頁時光機是可以手工存档的，iabot是可以上去管理界面设置存档后的页面。如果作为参考注脚的话，我认为有必要做页面存档。但如果作为页尾的外部链接，视情况而定但一般没必要。——Sakamotosan路过围观 | 避免做作，免敬 2022年10月14日 (五) 14:42 (UTC)

仅限于播放作品是对应该OTT平台制作的情况下，可以接受。如果只是购买播放权的话，官方网站还是要找回原始制作方设立的官方网站。——Sakamotosan路过围观 | 避免做作，免敬 2022年10月13日 (四) 05:43 (UTC)

一般來說，當我輸入網絡播放的來源前，會先看連接vpn 及登出帳號後可否閲讀相關網頁，如不能，我不會添加來源，因為機器人無法存檔。如果是VIU 的狀況，@Hijk910通常會引用VIU 的Facebook 的帖文，可是現時對引用fb的方針較含蓄。--唔好阻住我愛國（留言） 2022年10月13日 (四) 07:43 (UTC)

这个问题跟维基百科讨论:电子游戏条目指引#提议在电子游戏条目指引中规范游戏数字发行平台外链类似，那里@Kriz Ju的倒数第二个版本的修订除了繁琐一点我看还行，应用到影视作品的话，就说“（中文版）首发于www.xxx.com”，同时回避是不是官方网站这个问题。--Gqqnb（留言） 2022年10月13日 (四) 12:24 (UTC)

篇幅较长，未重新看，过于复杂可能对共识和理解不利。“首发于”的措辞对收录标准似乎有误导性？同日、同月首发，或者首发但此后变为其他网站独家，都会影响作为官方网站的价值体现。--YFdyh000（留言） 2022年10月13日 (四) 12:59 (UTC)

那我简单来说就是OTT平台不能否作为影视作品的官方网站。但是OTT平台可以作为外部链接加入。加入方式就是“（中文版）首发于”，精确到日。你说的“首发但此后变为其他网站独家”，对我这个标准不影响。--Gqqnb（留言） 2022年10月23日 (日) 09:01 (UTC)

個人意見：OTT平台播放頁面（一般來說使用外部連結模板連接到的頁面）不應作為官網，無論該影片是否由該OTT平台製作、該頁面是否需登入才可觀看。OTT平台若另外有製作無須登入即可瀏覽的該影片專屬的推廣頁面，且該影片由該OTT平台製作，可考慮將該類推廣頁面當作官網。--Anghualee（留言） 2022年10月14日 (五) 03:25 (UTC)

• 如有多個OTT平台上映，放或不放某些平台就有推廣之嫌。--Temp3600（留言） 2022年10月14日 (五) 10:20 (UTC)

  你在說台灣OTT亂象？--唔好阻住我愛國（留言） 2022年10月14日 (五) 11:39 (UTC)

  实际上中国大陆的日本动画作品有一部分也是多平台上架的例如东京电视台（杭州都爱漫）代理的作品（选择这种方式的原因是为了方便分摊版权费）对于这种应该选用哪个平台的链接就真的不好选了。--相棒学园驻维基百科代办冲击钻突贯龙 2022年10月14日 (五) 12:06 (UTC)

  这并不影响，因为这些日本动画作品都有自己的官方网站，无需要放其代理商的播放平台网站链接。唯一要考虑的是类似某些平台自制的，一般没有专门的站点，近似于官方平台性质的就是平台的播放站点，所以作为近似对待。——Sakamotosan路过围观 | 避免做作，免敬 2022年10月14日 (五) 14:37 (UTC)

  WP:關注度??--唔好阻住我愛國（留言） 2022年10月14日 (五) 13:50 (UTC)

---

• (※)注意：與提案人Xiplus討論後，認為此提案的部分應該就OTT平台自製影集為主，且是作為官方網站列入外部連結，而非作為參考來源引註至條目中，所以還是希望各位的討論留意一下方向。—🍫巧克力～✿ 2022年10月17日 (一) 08:19 (UTC)

如果是外部連結，希望可以標示只供香港IP閱讀。--唔好阻住我愛國（留言） 2022年10月17日 (一) 10:46 (UTC)

外部連結本來就可以額外標示，如果需要將ISO 3166-1代入製作「僅限XX區域閱覽」模板，實際上也是可以做到的。--🍫巧克力～✿ 2022年10月20日 (四) 04:25 (UTC)

藝人參與綜藝節目列表

在Wikipedia:頁面存廢討論/記錄/2022/10/06#文彬影視作品列表引起的疑問。按2016年WikiProject_talk:歌手和演员#綜藝節目是否不應該放在明星條目呢?，達成了不應在個人條目羅列非固定班底綜藝的共識，如沒理解錯誤，當時@AT容許另作獨立列表條目作為折衷。@LuciferianThomas的教學中，以SpeXial影視作品作為例子。老實說，如按平日的條目獨立性討論，例如近來常有的馬來西亞政治人物分拆條目，這些列表可用「匪夷所思」來形容，SpeXial影視作品更是完全沒有來源的列表。我明白這可能是歷史遺下的問題，但也需要問清楚現在應按什麼標準去判定(1)分拆舊條目的內容、(2)建立新條目是否可接受。是否任何有條目的藝人，都有資格被建立綜藝節目列表條目？是否需要來源？另也徵詢第一個告知我此共識的@Wongan4614的意見。--Factrecordor（留言） 2022年10月13日 (四) 12:36 (UTC)

( π )题外话 吐槽 对于“罗列非固定班底综艺”的禁止性标准和清理，我个人不是很喜欢。如果内容不滥（比如每次必写、代言写全、溢美之词），参加综艺又存在一定的可说明的价值或重要性，我主观上认为有陈述和链接意义，对“构筑百科全书网络”也有帮助，有资料性价值，虽然时常踩在琐碎资料或原创总结的门槛。

SpeXial影视作品显然是WP:NOTIINFO了。“独立列表条目”难道是非琐碎资料、可供查证的“法外之地”？继维基语录、维基文库后，建立维基履历吧。^{[開玩笑的]}--YFdyh000（留言） 2022年10月13日 (四) 13:14 (UTC)

我本來的主張就是全數刪除，現在也是一樣。況且，共識雖然說可以建立列表，但是不代表就不需要遵守其他規定，仍然需要滿足WP:可供查證和Wikipedia:LIST等規定才能建立。--AT 2022年10月13日 (四) 14:31 (UTC)

來源方面好辦。然而WP:LISTD主要談的是篇幅，本來的標準就是篇幅太多又不能明確定義為瑣碎的東西，就可以分拆，但當非固定班底綜藝這種瑣碎內容容許分拆，那要如何理解？是不是某個藝人當了5個綜藝的一集嘉賓（假設都有新聞報道來源），篇幅太短，不能寫也不能作獨立列表，當他參加過的綜藝足夠多就可以作獨立列表了？怎樣才算足夠多？

另外，我的意見，組合的節目列表比個人的節目列表有意義，因人數多篇幅自然較多，也有助分析各成員的活動分佈。--Factrecordor（留言） 2022年10月16日 (日) 16:07 (UTC)

我隨便列的而已，WP:V還是需要遵守。幫忙找個例子是合規的幫我更新一下，確實不太恰當。--路西法人 2022年10月14日 (五) 01:12 (UTC)

已更新為少女時代影視作品列表。--CaryCheng（留言） 2022年10月14日 (五) 08:21 (UTC)

可，感謝Cary君，這個例子好多了。如果有需要的話歡迎更新該說明頁以更貼切反映方針指引要求。（該例子也是2020年末寫的了，那時剛入維不久大概率也沒想那麼多。--路西法人 2022年10月15日 (六) 03:12 (UTC)

重新明確藝人參與節目列表共識

過去和近期也曾有人提出過質疑指2016年討論達成共識不明確，我能理解他們的疑惑，該討論最終確實僅達成妥協共識；過去兩三年我根據該討論結果執行時，遇到的回退基本上都是不清楚規則或社群共識的新手，並未有巡查員、回退員或管理員提出質疑。故此，希望根據維護的經驗訂立更清晰的共識，以更好的規限此等過度詳細內容。以下是我的個人建議：

1. 演藝人員單次主持的大型節目或在一個時間跨度內固定參與（包括主持、代班主持及班底）的節目通常相對容易找到參與節目本身的影片以外的多條可靠來源支持：
   • 若節目本身具備關注度並存在條目，且條目中有包含主持人員變革的可靠來源，則直接連結節目條目即可，若可附註來源佐證加入和離任日期更佳；
   • 若節目本身可能具備關注度但未有建立條目，或並未符合關注度要求，則應當附註來源佐證參與節目及加入和離任的日期。
2. 演藝人員單次出席的大型活動節目或非固定參與（擔任飛行嘉賓）的節目屬於瑣碎資訊，尤其歌手或通告藝人可能會透過大量參與節目而獲取曝光。很多情況下都未必能有參與節目本身的影片以外的多條可靠來源支持，且並不對於有關人物構成足夠的影響或重要性從而被寫進條目中。若因參與節目而引起對人物事件的關注（如爭議），應當以摘要格式寫進條目內文中。
3. 若參演演藝作品佔篇幅過長，可分拆為獨立列表條目，但仍應遵從可供查證、非原創研究等方針。

以上供討論：@AT、YFdyh000、Factrecordor、CaryCheng。--路西法人 2022年10月18日 (二) 05:01 (UTC)

(＋)支持。--AT 2022年10月18日 (二) 23:37 (UTC)

(＋)支持。--CaryCheng（留言） 2022年10月19日 (三) 08:59 (UTC)

關於(2)算不算瑣碎資訊，沒有什麼既定看法。但有兩點想提一提。其一，按我的常識，縱使單次出席也並非「很多情況下都未必能有參與節目本身的影片以外的多條可靠來源支持」，反而是經常都有娛樂新聞報道（縱使並沒有特別事情發生過），當然也視乎那藝人有多紅，所以需釐清這裡對於「瑣碎」的判斷，是按其性質（例如單次出席）為主還是按來源的數量和深度為主。其二，單次出席大型活動、非固定參與節目，似乎本來是兩回事，據近來觀察，按過往共識嚴格執行刪除後者的人，也未必會去管前者。--Factrecordor（留言） 2022年10月19日 (三) 17:48 (UTC)

每集有不同嘉賓的節目，因應節目性質的不同，嘉賓角色在節目中的份量也可以相距很大，尤其訪談類節目，對於認識該嘉賓往往有很大作用。覺得還有一片空間介乎於(1)和(2)之間。--Factrecordor（留言） 2022年10月19日 (三) 18:16 (UTC)

「大型活動」意思是例如金鐘、金馬或跨年節目等大型節目（我應該是寫錯字了）。參與節目的收錄標準應是對於其本身有影響的（例如主持新節目），「認識該來賓」並非對演藝人員的重要性而僅是觀眾、粉絲的角度。維基百科不是宣傳工具，收錄的應該是普遍可公認對於傳主的身份有影響的內容而非「是否有助於讀者/觀眾認識」。至於是否瑣碎內容則應當是顯而易見的，一個人不可能同時主持20個節目，但可以在特定時期一口氣上20個不同的節目（例如宣傳期或通告藝人），每個節目的宣傳、訪談大同小異，顯然並不個別具備重要性的事件。WP:NOTDIARY也指出「例如名人和體育明星的新聞報道可能頻繁出現且涵蓋大量瑣事，但使用來源會導致條目過度詳細，看起來像本日記。不是每一場比賽、進球、或揮手都有足夠意義寫進人物傳記內。」正正清晰說明了不該「有來源就塞進去」這個道理，有來源之餘還得評量重要性。藝人作為嘉賓參與綜藝節目就有如球員參與單一賽事，而記錄作為班底參與則可類比為記錄參與一整季賽事，閣下可以依此比較一下根據方針的理解哪些適合收錄在條目之中。--路西法人 2022年10月20日 (四) 04:11 (UTC)

明白，不反對。--Factrecordor（留言） 2022年10月20日 (四) 13:22 (UTC)

我觉得不能解决争议问题，是否从节目中发掘出独家价值/信息，然后表格改写为散文/备注，参演就变为值得保留。（虽然大多可能是一手或非独立来源）。对身份有影响又包括何种影响，首次参加春晚的集体节目（配角/参演），首次成为大型品牌代言人，首次公布履历或家庭或婚姻情况，首次回应争议，首次以某某身份参演，或者仅限可靠来源介绍提及的可达标（可能十不存一），如果来源只提“某节目”那介绍节目名又是否得当。“是否有助于读者/观众认识”不重要、“对于传主的身份有影响的内容”重要，对于散文是没错的，但对于条目仍不可避免的列表/表格式陈列，可能损其完整性、编辑争议频发。--YFdyh000（留言） 2022年10月20日 (四) 13:48 (UTC)

先逐個例子回應：

• 「首次參加春晚的集體節目（配角/參演）」並不實際對於有關人員有長期的直接影響，演員上春晚唱個歌不會就因此成為了歌手（需要後續真的發歌才會真正改變身份），倒是主持幾乎是必然會被來源所提及的。單純的演出是否能當成其本人的「作品」我是不太認同。
• 「首次成為大型品牌代言人」離題，但有來源即可（雖然我是覺得有很濃烈的宣傳意味，畢竟不可能有人把「代言人」視為某藝人的主要身份之一）。
• 「首次公佈履歷或家庭或婚姻情況」「首次回應爭議」寫內文也頂多帶過節目名稱（來源有說就行），但同樣參演節目本身並不會改變藝人本身的身份（是其言論改變其本身，這個在什麼場合下都可能發生，是否參演節目無任何影響）。
• 「首次以某某身份參演」這個更離題了吧，現在沒在說規範參演影劇的列表？

列表不會因為是列表就不受WP:NOT規範，列表也是內文的一部分，固然應當受規範。當一個歌手每次發新歌或專輯的宣傳期上十餘個節目宣傳，發四首歌就上四十個節目了，音樂作品四項、參加節目四十項，到底他的正職是歌手還是通告藝人？就算是通告藝人好了，假設每個月上十幾二十次節目，一年就一百多項，又是否合理的收錄呢？足球員籃球員是不是每一項比賽都得紀錄呢？顯然不是。--路西法人 2022年10月21日 (五) 00:05 (UTC)

• 参加春晚等大型节目，对绝大多数艺人（同类参演小于3次），我觉得是值得提及列出的非琐碎事项（大型集体节目可能除外），对其人生和生涯也不能说低价值。简单以主持或固定参与判定琐碎，我认为仍不完善，且“主持”未必是节目重点、重要角色。
• 有粉丝参与的艺人条目，广告、代言等内容蛮多的，是否加入真不好说，我也觉得宣传意味很浓、很多该清理，例子。主要是“参与节目的收录标准应是对于其本身有影响”，粉丝加入代言内容显然是认为对人物本身产生影响，但我觉得大多没有，如此还是主观判断。其实“长期”、有知名度（独立有效介绍）的代言或许更重要。
• 正文为求完整，经常是时间+节目名+内容，那么同等内容的表格内容，是否就不算琐碎。是否节目含有新披露的“值得记载”的内容，就是讨论中的“对演艺人员的重要性”，这可能很模糊和广泛。
• 某某身份，我细化一些，比如某些粉丝、新闻或传记会称，加入某公司后的首部作品/首次出演某类型/首次以某身份参与制作，种种。再比如，知名演员早年的非知名作品/跑龙套，是否均是琐碎信息，但这有时存在有效介绍/对人物构成重要影响，是否有来源介绍就不琐碎。

--YFdyh000（留言） 2022年10月21日 (五) 01:21 (UTC)

• 仍不能認同，收錄標準不應因為傳主本身的知名度或關注度而變化。每個知名的演藝人員總會經過不怎麽知名的時期然後才開始獲邀參與大型節目，以閣下認為適合的標準不就成了起初符合收錄條件，出名後年年獲邀出席就變得瑣碎不該收錄，然後就刪除了？「對其人生和生涯也不能說低價值」往往只是主觀的判斷，主觀地我認同新晉藝人獲邀進行專訪或參與大型節目對其本人具備重要性，但客觀而言實際仍不對其有影響。
• 同意僅應收錄長期並有可靠來源佐證的代言，這部分完全沒有異議。
• 不清楚您表達的什麼，如果正文出現列表式或排比式的「時間+節目名+內容」那麼不是WP:NOTDIARY規範的日記形式是什麼？
• 「加入某公司後的首部作品/首次出演某類型/首次以某身份參與製作」不是本次討論的重點，請分開討論。

--路西法人 2022年10月21日 (五) 04:10 (UTC)

出席央視春晚和日本紅白這類節目對於藝人在該地區的「地位」顯然具廣泛公認的指標作用，等同拿了一個不大不小的獎，與一般節目不能同日而語。我同意有特別價值的演出，應多以散文陳述而非列表。至於什麼節目地位特別高，每個地區每個界別（如戲曲、動畫歌手）也不同，難以具體羅列，倒不如舉出一些重要例子，其他可由「多個獨立可靠二手來源皆描述其特別價值」去詮釋。--Factrecordor（留言） 2022年10月21日 (五) 15:24 (UTC)

再講，參與單次大型活動，不論主持和一個環節的演出者，能短時間內參與多少個的可能性根本就差不多，而且演出者獲得的關注往往都比主持人高得多，我敢肯定「相對容易找到參與節目本身的影片以外的多條可靠來源支持」一定是演出者方面（一些名氣很低的除外）。在單次大型活動上偏向主持是非常怪的。--Factrecordor（留言） 2022年10月21日 (五) 15:56 (UTC)

需要注意維基百科不是宣揚特定觀點的地方，出席央視春晚和日本紅白這類節目對於藝人在該地區的「地位」顯然具廣泛公認的指標作用，但維基百科不應用作反映一個人的主觀「地位」（尤其藝能界沒有明確的「地位」界線，一切都是主觀認定的），沒上的也不代表沒名氣；此外散文內文的部分並非本次討論的重點，但其實若同類型過度瑣碎的出席節目內容寫在內文裡面（例如A'N'D的過往版本）任誰都應該同意讀起來像是日記。

我發現這一部分有一個問題是各地的大型節目的舉辦方式有明顯的差異。香港各台的大型節目幾乎往往都是總動員出席，給每個人都收錄下去我個人不認為有太大的意義，而典禮的表演嘉賓往往也是得獎者，收錄沒特大的意義。台灣的大型節目（基本上就是紅白藝能大賞）比較貼近比賽形式，或許可參考比賽參賽者的模式紀錄；三金（金馬金曲金鐘）則固然最重的是獲提名者及得獎者（但這個獎項段落已經有，重複紀錄是在多餘），其次反而是主持人的表現（例如剛剛昨天舉行的金鐘就是這樣情況），表演的來源反而相對不及主持人的來源。--路西法人 2022年10月22日 (六) 05:34 (UTC)

還是主張多集綜藝節目無必要與單次節目綑綁討論。可先處理好前者，後者宜此後另行討論，徵詢更多意見。

我嘗試搜尋「金鐘獎」或「金鐘獎主持」，新聞主要內容是得獎名單包括最佳主持人獎得獎者，至於是屆主持是誰，有的略有提及，有的根本沒提及。

當初討論多集綜藝節目的理由是主持不可能短時間內參與多個，一集嘉賓卻能短時間內參與很多個，以致個人條目內容冗長，上面我已說過在單次節目中主持和嘉賓出席節目的密集程度分別不會大，主持人數少、嘉賓人數多是另一個問題，它影響的是節目條目內容長度，能類比的是電影電視劇演員名單。另外，單次節目的數量是不是真的很密集？

我堅持某些節目具指標性意義。--Factrecordor（留言） 2022年10月22日 (六) 12:05 (UTC)

可，我稍後處理。--路西法人 2022年10月22日 (六) 14:04 (UTC)

補充一下關於「按過往共識嚴格執行刪除後者的人，也未必會去管前者」，確實，但這次是等於重新訂立共識，有加減也並非不妥，合理即可。--路西法人 2022年10月20日 (四) 04:12 (UTC)

這意味清理範圍顯著加大，似乎應徵詢多些常編輯藝人條目的朋友。--Factrecordor（留言） 2022年10月20日 (四) 13:25 (UTC)

我個人過去清理的時候僅以來賓身份參與大型節目的項目也都給刪掉，反正本來就不符合「固定參與或主持」這一部分。是否真的擴大了範圍我不敢說。--路西法人 2022年10月20日 (四) 13:37 (UTC)

我覺得大膽清理就好，如果清理有問題，就請他簡單說明一下為何需要保留即可，我相信如果真的是具有足夠重要性的事件或者主持，清理的維基人一看解釋就知道這可以保留了，根據過往經驗比較常碰到的是為保留而保留的理由，我認為這才是後續清理比較會遇到的問題。--~~Sid~~ 2022年10月22日 (六) 14:20 (UTC)

我觉得可能需要WP:RSN那种集中讨论和列明标准的地方，不然就是主张删除和主张保留者在互列观点证据尝试说服对方（或者编辑战/放弃），而其他参与者不了解有讨论发生、无法感知标准。用客栈讨论也可以，但似乎容易话题变宽而最终无结论。--YFdyh000（留言） 2022年10月22日 (六) 18:54 (UTC)

(＋)支持。--~~Sid~~ 2022年10月22日 (六) 14:13 (UTC)

中国艺人条目序言章节的粉丝信息

一些艺人条目的序言章节有加入“粉丝名”、“应援色”、“应援口号”信息。请问是否有需要展示这类信息？对于粉丝、应援类信息，对于不同类型艺人是否有不同的方针？ 举例：

中国大陆《创造101》选秀艺人：孟美岐、吴宣仪、杨超越、段奧娟等；

中国大陆演员：赵露思、譚松韻、丁禹兮、彭小苒、庄达菲等；

中国大陆歌手：毛不易、张碧晨、刘宇宁等

--桃花影落飞神剑（留言） 2022年10月15日 (六) 06:50 (UTC)

除了应援色有限制，其他記得是無法可管，就算有法也只能防軍子不防小人。 --窝法乙烷 儿法梦碎 2022年10月15日 (六) 07:54 (UTC)

「粉絲名」已經不限於中國藝人條目了，但有些紅星的「粉絲名」的確會常被傳媒直接用作代稱，也算一種基本資訊。應不應放在導言沒意見。--Factrecordor（留言） 2022年10月16日 (日) 16:15 (UTC)

• 粉絲團體我覺得還好，有些粉絲團體挺有影響力，甚至會獨立於藝人進行活動。--Temp3600（留言） 2022年10月16日 (日) 16:58 (UTC)

  想問這些粉絲名或粉絲團體，是官方認證的嗎？--Mafalda4144（留言） 2022年10月16日 (日) 18:03 (UTC)

  如果是以韓國藝人來說，是的，通常韓國經紀公司會公告旗下藝人的粉絲名、應援色等資訊，而娛樂媒體報導也會以粉絲名作為對於該藝人粉絲的代稱。--🍫巧克力～✿ 2022年10月20日 (四) 04:33 (UTC)

没有必要，不是宣传工具，不收录不经筛选的内容。此类列入序言，应使用可靠独立的有效介绍证明价值，且最好得到具加入价值的共识，否则有理由移除。但粉丝参与的条目，交流协作是个大难题，会变成编辑战或持久战。如果有可靠来源（包括官方一手资料性或者可靠第二手），我倒是不反对列入信息框，但可能缺少相关字段。--YFdyh000（留言） 2022年10月16日 (日) 19:15 (UTC)

( π )题外话 官方颜色等维基数据属性，也许能收录部分杂乱但有来源的信息。而是否要、如何在条目中展示（已有或单独的信息框），我没有明确的想法，且不一定真的适合在条目中展示。口号与应援口号似有差异，可能没有相关属性。粉丝名/群组，可能多数没有写入正文的重要性及来源证明，只能沦为宣传而非介绍。--YFdyh000（留言） 2022年10月16日 (日) 19:30 (UTC)

依照我對百科全書該有的樣子，我認為嚴格來說這些是不該被收錄的。--~~Sid~~ 2022年10月22日 (六) 14:22 (UTC)

WP:格式手册有关百分数等的格式问题

現行條文 在反映一个具体数量时，国际计量局建议在阿拉伯数字与计量单位字母符号之间插入一个半角空格（例：0.1 cm、23 kg、45 °C、67 %），度分秒除外（例：89°、12′、3″）。

提議條文 在反映一个具体数量时，国际计量局建议在阿拉伯数字与计量单位字母符号之间插入一个半角空格（例：0.1 cm、23 kg、45 °C）。惟须注意百分数、角度、弧度、梯度等无量纲，不适用该条（例：67%、89°12′3″、$2\pi$、$0^{g}$），但弧度使用rad表记时除外（例：1 rad）。

现行条文对百分数的处理与常见用法不符，亦不合en:MOS:PERCENT；同时，弧度、梯度的情形需要补充。 --DvXg 📬 2022年10月15日 (六) 08:07 (UTC)

用明朝劍斬清朝官是不是搞錯什麼，英維不適用中維，而內文寫道「建议」並非強制執行。 --窝法乙烷 儿法梦碎 2022年10月15日 (六) 15:02 (UTC)

提及英维是因为西文是百分数如此表记的借入来源。如果这种建议既不合外语借入来源，也找不到相关的本语种标准，更不反映站内实际的使用情况（如百分数这个条目本身），那么这样的所谓“建议”显然是需要被修正的，否则任何误植的条文都可以用这一条辩护了。--DvXg 📬 2022年10月15日 (六) 15:19 (UTC)

如果您非要为这一条辩护的话，请自君始（您的用户页所上用的框就不符合这一规定）。--DvXg 📬 2022年10月15日 (六) 15:21 (UTC)

常见用法无异议、参考英维标准无异议。但是，应该查一下依据的标准和当初讨论。台湾國際單位制手冊第 9 版 (2019)第39页称“國際公認的符號%(百分比)可以與 SI 一起使用。使用時，應有一空格分隔數字和符號 %。”。The International System of Units (SI) - BIPM第37页为相同表述，"The internationally recognized symbol % (percent) may be used with the SI. When it is used, a space separates the number and the symbol %."，应是此项来源。en:Percent sign#Correct_style则详细提到了各语言常用的不同间隔风格。我觉得可以讨论条文是否要参照英文，依中文的实际情况和常见用法，允许或建议通常使用不符合该国际标准的规范，信息框、学术条目等领域又是否要例外。中国大陆的规范待查。--YFdyh000（留言） 2022年10月15日 (六) 15:43 (UTC)

感谢补充国际单位制的有关条文，不过台版标准第42页（PDF第46页）的“(10±0.01)%”像是自身亦不符本标准。另外，百分数本身并不由国际单位制定义，在数学教学中一般也不将其视作单位（如99%通常视若同0.99的数，惟更强调由比例导出）。

在数字排版领域，W3C起草中的《中文排版需求》内文实际使用的是无空格样式，其参考的已发布标准《日语排版需求》的3.1.10条e项则明确百分号前不加空格且不可断行，可做参考。--DvXg 📬 2022年10月15日 (六) 16:00 (UTC)

• 台版標準第42頁（PDF第46頁）的標題是"第 1 屆 CGPM，1889 年"，段落是"考量"。
• 現行條文寫得很明確，跟計量單位（SI）字母符號並用時加空格，麻煩請先點內連去看這是哪七種計量單位。這個段落只是在講 SI，所以引用的是 The International System of Units (SI) - BIPM，而 % 會被一併納入是因為這個條文寫的就是"跟計量單位（SI）字母符號並用時"（條文內文），而 % 是可以跟 SI 併用，這個時候 % 前面要加空格（symbol % (percent) may be used with the SI ... a space separates the number and the symbol %）。
• 你想要一個跟 SI 無涉，針對無量綱採用空格的說明，建議另開一條，不要併在 SI 那條裡面混雜，這樣既不符合 SI 對於空格的使用規定，也讓人搞不清楚該條目是不是專門在講 SI 的空格使用。

--Anghualee（留言） 2022年10月16日 (日) 05:25 (UTC)

• 不明白第一项是什么意思，引文也应该遵循排版要求。不过我认同国际单位制的要求的确如现行。
• 现行条文并未明确“并用”，界定“并用”也缺少明确界限。这条提议算是要替代而非增补这条实际上（de facto）并未完全被中文（乃至CJK）接纳的关于百分号的国际计量局规定：在数字排版领域的可参考标准中，《日语排版需求》的3.1.10条e项明确百分号前不加空格，而紧随的f项就给出了“75.123 4 kg”的例子。原条文中的“在反映一个具体数量时”是具有一定排他性的，即使要另开一条也需要改动既有的这一条，当然（如果能够达成这样的共识）是需要再修订草稿，改变条文中指定的上游标准的。
• 原条文使用百分号的方式，在维基的环境中大约只有计算式的情形下会用到（如计算热机效率$\eta ={\frac {10\ \mathrm {W} }{20\ \mathrm {W} }}=50\ \%$）。可以考虑在正文（遵循数字排版规则）和公式（遵循国际单位制要求）环境下作不同的规定。

--DvXg 📬 2022年10月16日 (日) 07:48 (UTC)

• 那是一個 quote，基本上就是照搬，不會為了刻意符合現代呈現標準去調整他，簡單來說就是不要去糾結46頁不符合，沒意義。
• 請問 % 是哪種 SI？這屬於有讀內連就懂。W3C 標準跟 SI 標準有什麼關係？為什麼針對 SI 的論述你要拿 W3C 標準來作依據？
  • 另開一條的部分你誤解了。
  • （好比說原條文是在這個星號）"在反映一個具...除外（例：89°、12′、3″）。"
  • （<- 換行打個星號以後，這邊放你的另開一條）
• 你當然可以根據實際狀況調整你想要的條文形式，我對此並無意見。

--Anghualee（留言） 2022年10月17日 (一) 06:58 (UTC)

引用W3C标准是因为格式手册提及关于数字与符号配合使用的规定只此一处，抱歉可能因为提案中没有改动上游标准的引用造成了误解。我对您对SI标准的解释并没有异议，只是 (1) 站内外的实际使用都更接近W3C标准；(2) W3C标准更综合，其面向数字排版的特点也更适合维基作为网站的格式手册引用。我明白现在的提案还需要更改，但是希望能在再一次修改提案之前先收集对“是否应当明确一般正文中百分号使用时无前导空格”这一点的意见。目前提案修改的大略想法是 (1) 替换原条文，引用W3C标准指引正文格式；(2) 将国际单位制的“并用”适用于公式环境，明确其与W3C标准在百分号运用上的不同。--DvXg 📬 2022年10月17日 (一) 17:32 (UTC)

W3C起草中的《中文排版需求》，首先他還只是個 draft。其次他的作用是什麼呢？根據目的裡面講的"作為實現這個責任的基礎，本文整理了中文（漢字）書寫系統在排版上的需求。一方面說明需求事項以明確描述中文排版之需求與問題；另一方面也提供與既有標準（如Unicode）的對應，冀求透過本文有效地促進實作。"簡單來說，如果你在排版上有特定的要求，比如說你想要直書，而非我們現在維基百科使用的橫書，那他就會把這個需求列到排版需求中，來去看看網頁標準怎樣可以達到這樣的需求。你哪怕引用NIST標準去支持加空格，或者引用芝加哥格式去支持不加空格，我都沒有意見。但是你引用《中文排版需求》，然後說 % 前面加不加空格怎樣。我直接問一句，請問加不加空格按一個空白鍵處理的這個事情，在網頁排版上是有什麼困難之處，需要什麼技術攻克，以致於到會需要寫到排版需求裡面去呢？除非你想用的是不斷行空白，那也頂多就是找 Unicode 的不斷行空白，不是嗎。當然你也可能想說你並不是引用 W3C 標準，只是用其中用到 % 的情況當作例子。而在排版需求的討論中貢獻者 kecrily 提到的"如 CSS 和 UI 设计中，普遍不加空格"就解釋了這個情況，因為排版需求中大部分是處理 CSS 和 UI 設計，對吧？--Anghualee（留言） 2022年10月18日 (二) 08:39 (UTC)

不对，您可能对《中文排版需求》所面向的领域有所误解。虽然这份标准由W3C旗下的兴趣组编写，但它所希望面向的对象是所有基于Unicode的数字排印，包括书籍印刷（如Adobe InDesign）、广告印刷（如Adobe Illustrator）、数字出版（如EPUB）等等，而非限于网页或者应用程序。其前辈《日语排版需求》，也是对JIS X 4051（日本語組版規則）标准的明确、细化与引导。虽然其对术语的使用有注意与CSS标准的相容性，但整篇标准事实上没有一处提到CSS、没有提到某项需求应当使用哪个CSS属性去实现，而是在总结中文排印的标准（事实上只有标点符号的使用部分有较为明确的明文标准）与常规。您说的

简单来说，如果你在排版上有特定的要求，比如说你想要直书，而非我们现在维基百科使用的横书，那他就会把这个需求列到排版需求中，来去看看网页标准怎样可以达到这样的需求。

这一点完全是不正确的，这篇标准的“需求”是对中文排印既有的实践的总结，而不涉及由谁实现、如何实现、在哪里实现。最明显的一处是，3.5节“行内调整”几乎所有的内容都无法用已经大致稳定、有实际浏览器实现的CSS属性实现，反而是同样草案中的CSS Text Module Level 4还在等待《中文排版需求》完成相关条文一并交由浏览器厂商参考。您在这个问题上完全颠倒了需求和实现（CSS）的关系。--DvXg 📬 2022年10月18日 (二) 09:44 (UTC)

上面那一段解釋了我為什麼要提問"W3C 標準跟 SI 標準有什麼關係？為什麼針對 SI 的論述你要拿 W3C 標準來作依據？"因為白話來講就是沒有關係，不該作為依據。接下來對於你提到的"更接近W3C標準"、"W3C標準更綜合"云云，他當然綜合，他把所有中文排版在網頁技術上遭遇到的困難都列出來說明可以怎麼達到，或者以後要怎麼促進實作去達到。他就是一個需求整理，一個當你排不出排版的時候，你可以去翻查對照到有什麼技術可以幫助你達成那種排版，並不是一個告訴你應該用什麼排版的標準。用維基百科來比喻的話，就是 Help 命名空間中某個列出所有模板然後跟你說什麼情況可以用什麼模板去解決的教學，不代表你在寫條目的時候就要用上該 Help 的所有模板，或者是裡面有講示亡號可以用 box 模板，就錯誤地跑去每個已逝人名加 box 模板，這種文件不是這樣運作的。--Anghualee（留言） 2022年10月18日 (二) 09:01 (UTC)

续上，您说的“网页技术上”不实，整篇标准通篇没有说是仅面向网页排版，兴趣小组挂在W3C名下并不能说明这是网页专用的，其编写目的也有填补中文排印标准的空白的考虑，而非仅限于中文网页排版标准。我当然知道这篇标准不是像芝加哥格式手册一样涉及语法、大小写一类细则、对应维基MoS的格式手册，但“此处是否加空格”这个问题不同于大小写，它和“此处是否可以断行”这个问题结合得相当紧密，后者则是一个排印问题，这也是我引用这项标准的原因。当然，我也同意加入西文的既有格式手册作为参考能更有说服力，但我不同意您对《中文排版需求》乃至《日语排版需求》与格式手册的空格问题完全无关的论断。--DvXg 📬 2022年10月18日 (二) 09:58 (UTC)

對我來說就是挑一個領域（例如網頁技術）舉完例子就好了，我沒有打算窮舉的意思，因為這樣既容易失焦，也容易搞不清楚我們在討論的問題是什麼。好比說我認為這並不是適用於我們現在在討論的維基編輯應該在原始碼編輯（我知道有其他如視覺化編輯方式，但是我不會提，因為對於討論沒有幫助）中 % 前面要加空格還是不加空格。而請問一下你在努力把書籍、廣告、數字印刷都拉進來，然後在最後面還補上"相關條文一併交由瀏覽器廠商參考"的例子，你有注意到你講的東西完完全全佐證了這就不是給使用者必須採納哪種排版（例如橫書、直書的挑選），而是讓廠商去了解有這些排版需求，讓他們實作出相關細節，當使用者要這樣排（且這種需求是有所本，例如裡面說這個是標點符號用法的規定、那個是輕小說在用，的時候），就可以透過廠商的實作來排出這樣的排版。所以在你窮舉領域以後，問題還是一樣啊：「請問加不加空格按一個空白鍵處理的這個事情，在網頁排版（甚至是你提到的書籍、廣告、數字印刷中）上是有什麼困難之處，需要什麼技術攻克（如你所說需要"相關條文一併交由瀏覽器廠商參考"），以致於到會需要寫到排版需求裡面去呢？」--Anghualee（留言） 2022年10月18日 (二) 21:48 (UTC)

"此處是否可以斷行"當然是一個問題，不然我也不會拋出來"除非你想用的是不斷行空白"，這在我前面貼過的討論中也提到"Latex ... U+202F"、"IEEE 的标准里也有些单位与数值间用的是 U+00A0"，但即便該 issue 已關閉，你有看到 Draft 中有多出任何應使用 U+202F、U+00A0 的條文嗎？可以拜託你，哪怕去那個 issue 裡面看到哪些標準，英国出的《Writing for Home Office Science 》、IEEE 的标准，甚至是上面你自己貼內連得芝加哥格式，抓哪個出來用都可以，因為這些都是要求作者去遵循的格式標準，都塞子彈給你了，為什麼你就是要糾結在一個不適合的引據上糾纏不清呢？--Anghualee（留言） 2022年10月18日 (二) 22:02 (UTC)

我同意用格式手册做引据啊，第一条留言我就引用了英维的MoS，要换成上游“一手的”手册我当然也没有意见，但是终归还是需要一个搭得上边的中文的（或者CJK的）标准做补充“中文确实有在这么用”啊。--DvXg 📬 2022年10月19日 (三) 04:55 (UTC)

从一开始我就直接打算对标英维的MoS为准，有人异议我才拉了CLREQ出来做论据，为什么您一直觉得是我非要拉这个做标准？至于用哪个Unicode码位做空格原条文和提案都没有涉及啊，如果想明确用{{nowrap}}还是 阻止断行，这是要补充另一项条文了罢。--DvXg 📬 2022年10月19日 (三) 05:02 (UTC)

我誤解我詢問"你在為什麼針對 SI 的論述你要拿 W3C 標準來作依據？"之後您對於 CLREQ 的說明是在強調該理據是有依據的，是我過多於糾結在旁支上了。至於要找跟中文搭得上邊的標準，台灣的標準與檢驗期刊中國際標準對SI單位之書寫建議和經濟部標準檢驗局法定度量衡單位使用指南，以及國家標準草案構成及格式指引前面有提到一些 CNS 標準，本身也有一些撰寫標準，你看看用不用得上。不斷行的議題也是在這些旁支討論中延伸冒出來的，若確定要加空格，有需要可以再另案討論或覺得合適的話就對這個部分補充。--Anghualee（留言） 2022年10月20日 (四) 00:14 (UTC)

42页的考量与前文的关系？不太懂“跟计量单位（SI）字母符号并用”概念，国际单位制计量单位如何与百分比符号共用。--YFdyh000（留言） 2022年10月16日 (日) 09:34 (UTC)

顯然原文之「89°、12′、3″」指的是不用「89 °」、「12 ′」、「3 ″」，而非指合作為「89°12′3″」。另外，百分比是數學符號而非計量單位（一百分之六十七不就是〇・六七嗎？），本來就不受相關規則約束，也因此無需另行規定例外。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年10月16日 (日) 12:46 (UTC)

啊，这处改动就是为了表示度分秒连写时不分开，您觉得这种格式不正确么？另外我确实认为百分比不是单位，但先行条文将其列出了，改为作为易于混淆的概念做出提示可能也是有必要的。--DvXg 📬 2022年10月16日 (日) 13:11 (UTC)

我覺得原文不是這個意思，當然連寫的時候確實也是不分開的。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年10月17日 (一) 05:23 (UTC)

这处算是想要利用举例来间接明确更多格式上的要求吧，要明文明确也可以？另外，也许应当在MOS:DATENUM明确分和秒应使用Unicode的专用码位，不应使用西文引号代替？--DvXg 📬 2022年10月17日 (一) 17:37 (UTC)

(＆)建議用JavaScript或服务器后端解决，不管在源代码里输入32cm还是32 cm，都自动呈现成合适的样子。至于合适的样子是什么，可以另外讨论。--Gqqnb（留言） 2022年10月23日 (日) 09:11 (UTC)

如何达到条文要求属于implementation的范畴，不在方针讨论之列。MoS恰恰是要讨论什么是“合适的样子”。--DvXg 📬 2022年10月24日 (一) 09:36 (UTC)

建议WP:管理員佈告板/編輯爭議未经解决则不得存档

如题。Fire Ice 2022年10月15日 (六) 14:50 (UTC)

取决于有无推进讨论，有无{{不存档}}。要不然，所有特定标准的讨论自动挂上不存档，需要手动移除？--YFdyh000（留言） 2022年10月15日 (六) 15:22 (UTC)

(＋)支持：應由行政員以上編輯者手動存檔。--唔好阻住我愛國（留言） 2022年10月15日 (六) 16:03 (UTC)

没必要，应减负，且单一行政员的决定也时常无法服众、引发复核（参考存废讨论）。--YFdyh000（留言） 2022年10月15日 (六) 16:36 (UTC)

不要问是否增加了管理员的负担，要问是否有利于你维。--Fire Ice 2022年10月15日 (六) 17:13 (UTC)

他说行政员。肯定不利，行政员的一般决定被质疑并不少。--YFdyh000（留言） 2022年10月15日 (六) 22:39 (UTC)

那麼，有沒有協調員等角色負責這類工作。若沒有，建議可由行政員指定一個相關類別的資深編輯者負責（如澳門交通類爭議由多次於澳門交通主題編輯及記錄良好及與編輯爭議無關的人負責。）--唔好阻住我愛國（留言） 2022年10月16日 (日) 03:00 (UTC)

(－)反对：超過一半的客棧討論（其實我想說的是99%以上）都在一段時間之後無人理會，許多提案討論者在提出問題之後也沒有推進討論凝聚共識，丟個議題出來就去忙別的事了。超過十天沒有人繼續討論的編輯爭議，不會在擺了兩年之後自動出現解決方案；不存檔只是讓客棧內容無限擴大，也不會自動解決爭議。--CaryCheng（留言） 2022年10月15日 (六) 19:10 (UTC)

我说的是WP:管理员布告板/编辑争议，不是客栈。Fire Ice 2022年10月16日 (日) 01:01 (UTC)

(－)反对此提議，但不反對延長未結束話題之自動存檔時間。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年10月16日 (日) 08:50 (UTC)

不現實，謝謝。--Ghren🐦🕓 2022年10月16日 (日) 09:02 (UTC)

有何不现实？--Fire Ice 2022年10月19日 (三) 05:23 (UTC)

• 在引入匿名發言前，冷處理怕是應對無理投訴的重要手段。--Temp3600（留言） 2022年10月16日 (日) 16:56 (UTC)

  既然无理，明言无理即是解决。--Fire Ice 2022年10月19日 (三) 05:23 (UTC)

  明言得罪人，然後各類評選就自討苦吃了。--Temp3600（留言） 2022年10月19日 (三) 11:04 (UTC)

  如果没有解决，那么如果条目以质量低的修改保留，则是有害于你维的。--Fire Ice 2022年10月19日 (三) 11:12 (UTC)

  個人與集體的利益時常不一致。怎樣調和就是立法者的工作了。--Temp3600（留言） 2022年10月19日 (三) 11:19 (UTC)

(－)反对，无人讨论了的话，基于WP:善意假定，认为嫌疑人没有问题，可以存档。--Gqqnb（留言） 2022年10月23日 (日) 09:15 (UTC)

持續出沒的破壞者記錄頁面

自從過往關於設立獨立LTA命名空間或私密維基的討論再度擱淺後，再無與持續出沒的破壞者記錄頁面相關的討論。然而，部分LTA記錄頁面的內容收錄混亂程度到無助於進行反破壞工作的程度，失去建立記錄頁面的意義；例如近期有用戶抱持「沒有規則說不可以」的心態在部分LTA頁面（1、2）列出大量曾受有關LTA破壞的頁面並聲稱用作連出更改監視，且在兩個舉出的LTA頁面中均無有效說明破壞模式。根據過往討論和經驗，我認為列出大量曾受影響不但無助於反破壞（基本上LTA都在看着自己的LTA頁面，列出來了不就知道不要去破壞那一個特定頁面嗎？）更可能導致模仿犯的出現（例如過往出現的攻擊性帳號破壞群）；跟管理員私下討論時管理員更是表示「不認識」，相信僅列出受影響條目而沒有充足（而不過多）的說明是完全無助管理員判斷甚或認知的。

雖然作為傀儡調查助理的職責，但在沒有相關指導下苦無執行辦法，且人非聖賢，自問並非熟知所有LTA的行為模式，無法單靠自己而進行清理，為免未來再有用戶抱持「規則沒寫」的心態而在反破壞工作上帶來反效果，建議在現有公開檢視的框架下新增關於LTA記錄頁面的編寫指導，並在年末前清理一下過往積累的（活躍）記錄頁面，以平衡反破壞和記錄過多資訊。

以下為英文維基百科WP:LTA頁面列出的注意事項：

英維條文 不要提供過多資訊 文本應在提供有用資訊和提供足以妨礙檢測的資訊之間謹慎平衡；一般而言此類資訊應僅與具有可信用戶分享。 有用資訊的提示 請考慮只記錄擾亂行為的性質和摘要、重要的提報頁面（SPI、AIV、ANM）和對有關破壞者過為模式和辨認方式熟悉的用戶名稱。 僅在有確實需要的時候進行記錄 請只記錄有確實需要進行辨認的案例，尤其是很可能被不熟悉其行為模式的用戶誤認為善意編輯的破壞者。此包括難以偵察到地操作傀儡、惡搞、推動非中立觀點和宣傳性質等行為；不需辨認為傀儡即可作純破壞用戶封禁的破壞者通常不需記錄。 小心用詞 不要使用任何可能美化破壞行為的用詞。不要使用空泛的相對時間詞如「近期」，應使用清晰用詞如「截至[日期]……」。

--路西法人 2022年10月17日 (一) 04:39 (UTC)

LTA:變身：「是一位會在影視作品條目添加與「變身」有關的擾亂性內容，或是在生者傳記條目捏造傳主逝世與暴力傾向的破壞者。」原來是無有效說明破壞模式，而LTA:A11早就說了，編輯傾向之後才要補上，可以繼續說謊沒關係。Special:链出更改/Wikipedia:持续出没的破坏者/User:A1111223、Special:链出更改/Wikipedia:持续出没的破坏者/User:劉濬瑜哪裡無助反破壞。收錄使用過的IP地址也意味著LTA也能看著過去IP不要去破壞那一個特定頁面，模仿犯也能透過LTA過往IP進行模仿，完全無關LTA頁面是否有列出受影響條目。別拿著沒有的規定打壓其他使用者，在反破壞工作上帶來反效果。--寒吉（留言） 2022年10月17日 (一) 05:46 (UTC)

2021年10月：Special:PermaLink/68145157（是一位喜歡在中文維基的影視作品條目加入偽造「變身」的破壞者。） → Special:Diff/68145166 → Special:重定向/logid/10921975 → Special:Diff/68191144（「閣下持續在不同條目增加與「變身」相關的不實條目」） → Special:Diff/68225264

2021年11月：Special:PermaLink/68760910（是一位會在影視作品條目添加與「變身」有關的擾亂性內容，或是在生者傳記條目捏造傳主逝世的破壞者。） → Special:Diff/68760919 → Special:重定向/logid/11028668。

原來這樣LTA:變身完全無助管理員判斷甚或認知。--寒吉（留言） 2022年10月17日 (一) 06:20 (UTC)

(－)反对，提案者並未說明是否屏除章節「使用IP位址」（Special:PermaLink/74046119#使用IP位址、Special:PermaLink/68952501#使用IP位址、Special:PermaLink/68068025#使用IP位址），在我眼裡章節「使用IP位址」與「受影響條目」同樣都能讓模仿犯進行模仿，而兩個章節都對反破壞均為有效資訊。LTA:變身有提供破壞模式與編輯差異（LTA:變身#參考資料）的情況下，仍被提案者刻意打壓、抹黑。--寒吉（留言） 2022年10月21日 (五) 06:19 (UTC)

反對者顯然在鑽牛角尖。IP地址可以偽造（VPN已經是很多網路使用者的基本常識），但模仿特定IP地址遠比模仿行為困難，上網隨便一搜都能知道，就算有一個列表的IP地址提供給你，完全偽造到準確落在一個特定的網路地址基本上是不可行（非不可能），可偽造的可能性微乎其微，此部分顯然為存在謬誤並無效的反對論據；而提案中錯誤提及其中一個LTA頁面沒有提供破壞摘要說明確實是我的失誤，我可以就此道歉，你可說我說謊、說錯，但絕不能說我打壓，過往社群的普遍意見（參考前幾次的LTA空間討論）也是規範和盡量限縮公開於站內的資訊。既然反對意見存在明顯謬誤，且留言剩餘部分就只是在對人非對事，故整體視作明顯無效的反對意見。--路西法人 2022年10月21日 (五) 11:00 (UTC)

模仿犯能透過LTA過往使用過的IP查看過去此名LTA的編輯傾向（編輯差異）進行模仿破壞模式，我可不是說模仿IP位址（「收錄使用過的IP地址也意味著LTA也能看著過去IP不要去破壞那一個特定頁面，模仿犯也能透過LTA過往IP進行模仿，完全無關LTA頁面是否有列出受影響條目」），你的提案即是對人不對事，就非得我投出反對票才打算要回覆我，我的個人討論頁也直接忽略不回答，這麼喜歡逃避，現在還直接說我的意見有謬誤而視作無效的反對意見，這就是打壓行為，自打巴掌。--寒吉（留言） 2022年10月21日 (五) 11:03 (UTC)

「用過的IP會被封禁，編輯過的條目會被保護，結果Wikipedia:持续出没的破坏者只能記錄使用過的IP，卻不能紀錄編輯過的條目，這樣會很矛盾，但無處有規定不能紀錄編輯過的條目」。所以為甚麼提案者只把章節「受影響條目」移除，不把章節「使用IP位址」也移除（Special:Diff/74124524、Special:Diff/74124518），兩者到底哪裡有差，而且LTA:變身與LTA:A11的編輯高機率都在過去編輯過的條目，在此兩個LTA頁面列出章節「受影響條目」幾乎不會常常出現如提案者所言噢，這些頁面被監視了，我去破壞別的，看你監視個寂寞，導致在LTA頁面列出章節「受影響條目」無助於進行反破壞工作。--寒吉（留言） 2022年10月22日 (六) 13:19 (UTC)

(＋)支持，考虑到部分现有LTA页面确实难以寻得有效信息并有可能招致模仿犯，我认为确实有必要规范LTA页面的编写规则。另，就私密维基事项，本人亦准备于此同时推进。（基于原先讨论，目前关于创建zh-lta wiki似已有共识，但对于访问权处于讨论状态，故我希望就此尽快推进访问权讨论）。--BureibuNeko 2022年10月17日 (一) 08:09 (UTC)

以一個最近才在學抓蟲的菜鳥來說，覺得列出被破壞的那些條目幫助薄弱，或許是想避免模仿行為，不過要一個個去找出差異、還要知道到哪裡找出來真心覺得累，若是有重點式寫出行為模式，對後進有心想要協助反破壞、或剛好遇上破壞的新人，能夠因此更快確認狀況。我的情形是看了好一陣子的通報，有前輩標註LTA，從而認識了有持續出沒破壞者。在更早的時候，其實不知道這樣的破壞行為，是要通報和可以回退的，曾經也只是當有趣，反應慢到後來才明白這有多大條。故若能有重點明確的行為模式紀錄，比起只是列出這個使用者破壞了這些條目，幫助會更大，也認同模仿行為會是個兩難，即使私人訪問藏起來或許好，但我還是喜歡維基百科全都攤開來不怕看只怕看不到，而且直球對決比較爽快不過呢都投直球了對方還自大到以為不是我就真的沒辦法了。對於持續出沒破壞者，有必要就用百科的方式建頁面，討論好收集的素材內容，百科不是省油的、自然有很厲害的方式解決，對吧是吧？--Mafalda4144（留言） 2022年10月20日 (四) 22:06 (UTC)

第四次提议LTA页面向私人wiki转变

是次提案基于先前关于申请制站务维基建立的讨论。

於Phabricator查看
編號T299590的任務

• 新的站务维基命名为：中文维基百科维护工作维基，zhwiki-maintenance-work（形如意大利语维基百科的sysopwiki，但是这个wiki的访问权不仅限于sysop）

• 新的站务维基的域名为：maintenance-zh.wikipedia.org

• wiki的访问权：傀儡调查助理、管理员（管理员）、回退员和其他经RFR申请得到访问权的用户。
• wiki访问权的具体获得方式：由申请者在RFR页面申请后，经任一已在wiki拥有账户的用户批准后（仿phab上Trusted-Contributors组），要求申请人向wiki管理员/wiki用户发送一封电子邮件以提供邮件地址，由wiki管理员或wiki用户注册账号。傀儡调查助理、管理员、回退员默认拥有访问权，无账号者仅需在RFR提出请求并向处理请求的向wiki管理员/wiki用户发送一封电子邮件即可，一般的，除非其被撤销过访问权，否则则不需进一步的讨论。

• RFR申请访问权基本门槛：已表现出有访问需要且有一定反破坏经验（可参考在VIP等页面的编辑）的可信延伸拓展用户或巡查员

• wiki需要启用的权限：跨维基导入者（zhwiki, meta） - 便于导入zhwiki LTA页面内的内容
• wiki需设置：$wgBlockDisablesLogin = true - 便于撤销访问权

除此之外，此wiki亦可以处理私有过滤器编辑讨论等问题（因为其访问权仅限sysop, rollbacker和部分可信用户）。

--BureibuNeko 2022年10月17日 (一) 08:09 (UTC)

過往討論中未曾提及站點管理員身份的部分，能否解釋一下刪除線的緣由嗎（雖然我沒想過要在設立站點之時就在本站管理員外提供進階權限）--路西法人 2022年10月17日 (一) 09:27 (UTC)

@LuciferianThomas：考虑了一下，基于访问者均为可信用户，wiki应该不会涉及过多需要管理员进行的操作（如保护、删除等），故此wiki并不需要过多管理员。BureibuNeko 2022年10月17日 (一) 09:31 (UTC)

同意，清楚解釋很好。不過那個刪除綫去掉比較好，不要誤導到別人了。--路西法人 2022年10月17日 (一) 10:32 (UTC)

好的。BureibuNeko 2022年10月17日 (一) 12:36 (UTC)

先纠正一个错误，目前私有站点可以设置$wgBlockDisablesLogin来阻止被封禁的账户登录，因此DisableAccount是不需要的（同时，这个扩展已经在prod被卸载了）。 Stang^★ 2022年10月17日 (一) 11:12 (UTC)

@Stang：好的好的，已经修改了，感谢提醒。BureibuNeko 2022年10月17日 (一) 12:36 (UTC)

根據當前描述，只有回退員可直接獲得訪問權，其餘用戶（包含傀儡調查助理、管理員、巡查員）均須在RFR頁面申請且「表現出有訪問需要且有一定反破壞經驗」才能獲得訪問權？雖然猜測只是文字敘述上的問題，但建議寫清楚一點以免爭議。另外，站點管理員如何產生？-Peacearth（留言） 2022年10月17日 (一) 19:16 (UTC)

感谢您的参与，关于访问权，“wiki的访问权：傀儡调查助理、管理员（管理员）、回退员、巡查员及其他经RFR申请得到访问权的用户”意思是傀儡调查助理、管理员（管理员）、回退员、巡查员不需要申请（或者仅需要向wiki管理员请求注册账号）且zhwiki管理员默认为wiki管理员，而其他人士需要在满足基本条件（“RFR申请访问权基本门槛：已表现出有访问需要且有一定反破坏经验（可参考在VIP等页面的编辑）的可信延伸拓展用户”）后在RFR页面申请。关于“（回退员申请方式如上，不过其除非已被撤销过访问权，否则可直接获得访问权。）”，那是之前默认傀儡调查助理也是管理员的，我忘删了，删了。--BureibuNeko 2022年10月17日 (一) 23:13 (UTC)

我看了讨论和前次讨论，仍未搞懂如下问题：一、现有处理方式有何不足？二、站务维基有什么用？三、设立站务维基的必要性在哪里？希望有人能够答疑。Fire Ice 2022年10月18日 (二) 06:26 (UTC)

“ “努力”破坏的人被社群“铭记在心、永恒流传”，还可以成为被“登载史册、正式收录”的对象，反倒对社群有贡献的善意用户随着逐渐淡出或离去，经过几年后，又有多少人或新进用户认识或记得他们曾经的贡献呢？这么说起来，是否破坏者破坏一阵之后，即可名留青史？善意的贡献用户还不见得可以轻易留名，就证明自己的“存在感”而言，当今的社群机制是否反倒在鼓励破坏者留名呢？ ” ——Kriz Ju

在此引用Kriz Ju一段话，私以为，增加LTA页面访问难度，使其仅限于真正想要学习与真正会做反破坏的人去查看（前者可以通过RFR申请，后者若非上述四种权限组成员，亦可通过RFR申请），从根本上打消部分愉快犯“留名青史”的目的，除此之外，站务维基可以使LTA不了解社群对这个LTA编辑方式的了解程度，从而尽可能的避免其见到LTA页面上有什么就避免做什么，从而可能使回退员认为其只是“好心办了坏事”的“编辑”而不能及时反应处理。

站务维基仅限于傀儡调查助理、管理员、回退员、巡查员和其他有一定反破坏经验的可信延伸拓展用户访问，基于这个条件，部分无法在zhwiki公开讨论的内容（如私有过滤器等）可以于此讨论，在此基础上，可以要求管理员在创建部分私有过滤器时先行于站务维基征求意见而后实行。

而以上内容实现的条件均为有一个仅供部分用户访问的私人空间，而基于T299546的回应，zhwiki并无法安装Lockdown组件，故实现的最好方式便为另辟新地。

--BureibuNeko 2022年10月18日 (二) 08:40 (UTC)

• (＋)支持能解決反破壞的一些目前無解的問題。-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年10月18日 (二) 09:03 (UTC)
• 支持，但我觉得有必要在本站留一些summary之类的东西，不能完全藏起来。 ——魔琴 [ 留言 贡献 ] 2022年10月21日 (五) 03:08 (UTC)

  有LTA:主頁啊。--路西法人 2022年10月21日 (五) 05:01 (UTC)

• (＋)支持 0xDeadbeef（留言） 2022年10月21日 (五) 05:27 (UTC)
• 所以此維基將含有什麼內容？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年10月21日 (五) 05:53 (UTC)

  除LTA空间内容外，还可用于讨论如私有过滤器等不便公开讨论的内容。--BureibuNeko 2022年10月21日 (五) 06:38 (UTC)

  巡查员不可看到私有过滤器，而且回退员是否应该看到仍有争议。 ——魔琴 [ 留言 贡献 ] 2022年10月21日 (五) 15:43 (UTC)

  已移除巡查员默认访问权限并允许其在自己不是延申拓展用户时可通过RFR申请。“回退员是否应该看到仍有争议”现在能看到对吧，那就不在讨论范围里。--BureibuNeko 2022年10月22日 (六) 03:08 (UTC)

• (－)反对，鴕鳥心態，不治根也不治本，大幅提升中維反破壞門檻。--寒吉（留言） 2022年10月21日 (五) 06:22 (UTC)

  @寒吉抱歉，但是可以请您说一下您为什么会认为“大幅提升中維反破壞門檻”吗？ 若是从LTA页面角度出发，这个维基并不会完全代替原有LTA页面，还是会留下能够判别的信息在LTA主页，只不过更多的描述被移动到wiki了而已，如果确有想法却受限于自己不属于上述用户组，可以在RFR申请访问权。私以为并不会提升反破坏门槛，而以最坏情况设想，也仅仅只是为zhwiki过滤了一批完全没有能力做站务的人而已。--BureibuNeko 2022年10月21日 (五) 06:42 (UTC)

• @桐生ここ、30000lightyears、Emojiwiki、Temp3600、1233、Hehua、忒有钱、Xiplus，ping一下之前参与讨论者，若有打扰还请谅解。另请了解上另有对LTA记录页面的编写指导的讨论，亦欢迎参与讨论。BureibuNeko 2022年10月22日 (六) 03:35 (UTC)

  • 感谢邀请，目前没什么问题。

  --在下荷花，请多指教（欢迎签到） 2022年10月22日 (六) 11:37 (UTC)

• 還是老問題：在明顯有破壞者擔任回退員時，private wiki能有那些作用。--Temp3600（留言） 2022年10月22日 (六) 14:52 (UTC)

  +1 ghrenghren为此+1了。：雞肋，棄之可惜，食之無所得。--Ghren🐦🕑 2022年10月23日 (日) 06:47 (UTC)

  这也是之前我推这个提案的时候，一个重要的反对原因……我觉得如果不改革回退员，搞什么都没用 ——魔琴 [ 留言 贡献 ] 2022年10月23日 (日) 07:22 (UTC)

  既然你这么认为的话我还是有点想请教一下你认为回退员 1) 为什么要改革； 2) 改革后应该达到什么样子； 3) 如果可能的话，你想使用什么方式（包括修订方针指引，或者其他程序性改动等）达成你的改革目标。--MilkyDefer 2022年10月25日 (二) 14:24 (UTC)

限制HTML註釋代碼在編輯條目的使用

近期發現有匿名及註冊用戶多次在條目加入下列「HTML註釋代碼」阻礙條目內容的顯示：

<!-- 這段文字不會在瀏覽器顯示 -->

這種做法可在不刪減條目位元組的情況下，便可阻止條目內容在讀者的瀏覽器上顯示，只需加入HTML註釋代碼括起不想被看見的條目章節，頁面的讀者就看不見被括起的章節，同時又可避免因為編輯歷史顯示有大量字節被刪減或章節被清空，而被近期巡查發現，加入7個位元組便能夠做到如同大量清空內容的顯示效果，故此HTML註釋代碼長期被用作鬼祟破壞，在下已將部分例證列於10月17日當前的破壞，下面將提供部分實例。

例證1：大口環根德公爵夫人兒童醫院，參考來源及內容被註釋，不能顯示[8]

例證2：福克兰群岛，108.184.199.21，整個「文化」章節被註釋，不能顯示[9]

例證3：兒童節，39.118.20.179先刪除香港及澳門章節[10]，同時在中國大陸及台灣章節重複加入冗餘的朝鮮參考來源，再於下一筆編輯使用HTML註釋代碼，阻礙整個台灣章節的顯示[11]

例證4：法定語文條例，96.60.113.141加入HTML註釋代碼，導致一大段內容不能顯示[12]

例證5：香港聖公會，整段「教育改革爭議」章節改為「教育」後[13]，再加入HTML註釋代碼，導致整個原「教育改革爭議」章節的內容不能顯示[14]

以上實例雖然條目及用戶編輯記錄的刪減字節不多，甚至顯示有條目相當位元組的內容擴充，惟實際上是將大段有來源內容、甚至整個章節以HTML代碼註釋，導致本百科的讀者在瀏覽器看不到相關的內容，破壞效果與大量清空內容無異，但往往因為編輯歷史顯示條目的位元組增加，巡查會以為條目是正常的內容擴充，故此不易及時發現條目實際上遭到破壞。

有鑑於此，建議收緊「HTML註釋代碼」在條目的使用：

1. 禁止匿名用戶及新用戶加入「HTML註釋代碼」或在現有「HTML註釋代碼」的括號範圍內加入內容；實行措施包括設置過濾器進行攔截，告知編者不可使用「HTML註釋代碼」。

2. 自動確認用戶或以上權限的編輯，在條目加入「HTML註釋代碼」或在現有「HTML註釋代碼」的括號範圍內加入新內容時，將會在發布變更時在編輯歷史被標籤，列入過濾器日誌，提示近期巡查者需要加以留意。

因為「HTML註釋代碼」在條目編輯上，並非毫無用處，所以不認為要禁絕，惟要防止及更易發現被不當使用。--Uranus1781（留言） 2022年10月18日 (二) 10:26 (UTC)

已建立監視用的過濾器。--Xiplus#Talk 2022年10月18日 (二) 14:48 (UTC)

你是建立「清空条目」這個標籤過濾器嗎？可是沒辦法使用此標籤當近期變更的篩選啊？---- Matt Zhuang表示有事按「此」留言 2022年10月18日 (二) 17:50 (UTC)

357 HTML註解。Special:标签中找到，点“x个更改”，可以筛选。--YFdyh000（留言） 2022年10月18日 (二) 18:15 (UTC)

調整了一下規則以提供更高的precision。--Xiplus#Talk 2022年10月19日 (三) 01:17 (UTC)

新建頁面將不會加上標籤。--Xiplus#Talk 2022年10月19日 (三) 10:54 (UTC)

357 HTML註解已足够。--Gqqnb（留言） 2022年10月23日 (日) 09:23 (UTC)

或者分階段去做，若然IP或新用戶仍持續使用HTML註釋代碼搞破壞，便採取攔截方式。--Uranus1781（留言） 2022年10月24日 (一) 09:45 (UTC)

对打标签和拦截新用户无意见。--YFdyh000（留言） 2022年10月18日 (二) 16:09 (UTC)

遇到藏內容的就直接幫忙整段刪除，如果是劇透相關一定幫他裸奔，WP:SW，藏甚麼真是的。過濾器會提醒有人用這個唷也蠻酷的。--Mafalda4144（留言） 2022年10月18日 (二) 18:21 (UTC)

我有时作为无来源或争议内容的移除意向使用，相当于仅编者（尤其是监视者）可见，取消隐藏的人要拿来源举证，移除隐藏内容视作二次确认——移除有基本共识。有些用户是将争议内容存至讨论页留档+供讨论，我觉得如果没有讨论或无争议，这样留存过于持久，且有时注意不到。直接移除有时太唐突或不明确，会引发“破坏”争议/质疑。主要用于旧有内容，如果是新进加入，则更多运用撤销和Ping来寻求来源或共识。隐藏有效内容的直接撤销。--YFdyh000（留言） 2022年10月18日 (二) 19:52 (UTC)

所以在下提案時已表示「HTML註釋代碼」在條目並非毫無用處，例如把英文版條目移植到中文版時，可將未翻譯的段落暫時隱藏，但這只適用於無爭議及明顯不適合顯示的內容，亦即直接移除，也不會被視為破壞。因為內容被加入「HTML註釋代碼」後，顯示出來的效果如同相關的內容被刪除，對於有爭議及有來源內容，也利用「HTML註釋代碼」隱藏，又沒有說明這樣做的原因，這樣確會牽涉破壞的問題。關於「取消隐藏的人要拿来源举证」的問題，這情況僅適用於缺乏來源的有爭議內容，並需要知會對方這樣做的原因，畢竟「HTML註釋代碼」對於條目的編輯和刪除沒有分別，可視為用戶對條目內容的擴充或刪除的操作。--Uranus1781（留言） 2022年10月19日 (三) 02:23 (UTC)

未翻譯段落不是應該用 TransH + TransF 兩個模板嗎？--Anghualee（留言） 2022年10月20日 (四) 13:54 (UTC)

不是每位編者都知道中文維基有這模板，很多功能模板都不好找，也不知其存在。--Uranus1781（留言） 2022年10月21日 (五) 11:03 (UTC)

大体(＋)支持，细则可以再议。--DvXg 📬 2022年10月18日 (二) 18:19 (UTC)

• 認為xiplus的af方案已經足夠，註釋代碼有其作用，如未翻譯的分類，不應全面禁止。--Temp3600（留言） 2022年10月19日 (三) 10:53 (UTC)

近一年來有多個浮動IP，濫用註釋代碼隱藏有參考來源的章節及段落，而且有多個條目受到影響。註釋代碼雖有其作用，但甚少須要使用到，IP更不見得在正常編輯使用，註釋代碼的效果如同大量移除條目內容，故此應採取如IP大量移除條目內容的措施，以過濾器攔截，IP如真的認為需要使用註釋代碼，可在討論頁提出並提交其草稿，由確認用戶代為編輯。--Uranus1781（留言） 2022年10月20日 (四) 03:28 (UTC)

一般來說，HTML隱藏功能是可以提示編輯者相關部分的共識是什麼，方便編輯者編輯內容，既然有過濾器提示新增HTML隱藏功能，為何沒有提示移除的通知？--唔好阻住我愛國（留言） 2022年10月20日 (四) 15:25 (UTC)

HTML註釋代碼並非完全無用，有部分模板內都有HTML代碼做提示註解，不一定要移除，現在的問題是因為有用戶濫用作為偷偷破壞條目的工具，所以除模板本身附帶的註釋代碼，IP及新用戶一般編輯不太可能在條目正文用到註釋代碼。--Uranus1781（留言） 2022年10月21日 (五) 11:03 (UTC)

只限制ip倒是可以考慮。--Temp3600（留言） 2022年10月21日 (五) 14:04 (UTC)

Wikipedia:格式手册/日期和数字增加“常用的数学符号”章节

提议在Wikipedia:格式手册/日期和数字增加“常用的数学符号”章节，置于“注釋”章节前作为正文的最后部分，内容如下：

常用的数学符号

参见：Wikipedia:格式手册/数学

• 一些数学符号难以直接输入，可使用编辑器菜单插入，或代之以此处所列的HTML字符实体引用（形如÷）。
• 若需要以不同于普通文本的形式显示数学公式，可使用{{mvar}}（用于单字母变量）和{{math}}（用于复杂表达式）模板。更多方法详见Help:数学公式。

常用的数学符号

符号名称	符号	HTML实体	备注
加号/正号	+	+
减号/负号	−	−	大多数程式語言则使用連字暨減號（-）表示减号/负号。
正負號	±	±
乘号	⋅	⋅	与间隔号（·）不同。
	×	×
除号	÷	÷	另有斜線（/）常用以表示除法或分數，如1/2可表示一除以二或二分之一。
等号	=	=	调用模板时若省略编号参数的参数名（形如1=），参数值中的等号会被错误解析，写上参数名或使用{{=}}魔术字即可避免。
約等號	≈	≈
不等號	≠	≠
小于号	<	&lt;
小于等于号	≤	&le;
大于号	>	&gt;
大于等于号	≥	&ge;

修订的出发点是为了规范减号/负号的码点为U+2212 − MINUS SIGN，同时注明在编程语言中则多以U+002D - HYPHEN-MINUS为减号/负号。先前与A2569875君的讨论可供参考。

提议条文来自en:WP:COMMONMATH，做了些简化，主要是删除了对空格的约束。英文原文规定在二元运算符两侧加空格，站内则并未统一，如1 + 1 + 1 + 1 + …有空格，1+1无空格。W3C《中文排版需求》草稿2.3.5节中的数学运算符两侧有空格与无空格都有出现，搜索其他中文标准规范尚无收获。因此不贸然对二元运算符两侧的空格做规定。--Lt2818（留言） 2022年10月18日 (二) 15:26 (UTC)

(＋)支持。在下亦曾爭論普通文本的減號應該用U+2212 − 抑或U+002D - （甚至有編者用U+FF0D － FULLWIDTH HYPHEN-MINUS……）。認同使用前者並支持加入格式手冊。——$\definecolor {my}{rgb}{0.04,0,0.5}\color {my}{\mathsf {htc_{23}}}$（留言） 2022年10月18日 (二) 22:19 (UTC)

• 是否需要在「大部分的程式語言……」加註與維基編輯相關的部分，如「若因技術限制在模板或模組內部可以使用連字暨減號，僅需要令輸出於條目文字的部分為減號即可。」以讓先前討論的結果有反映在修訂案內-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年10月20日 (四) 05:21 (UTC)

  这部分不止和减号有关，与-对应−类似的关系还有*对应×、/对应÷，可能写一起比较合适，但没想到好的行文。（表格内只提了减号是因为只有-与−形状相似，容易搞混。）“僅需要令輸出於條目文字的部分為減號”仅适用于模板/模組的编写，适用面不大，个人感觉不必特意写进格式手册。--Lt2818（留言） 2022年10月20日 (四) 06:26 (UTC)

(！)意見：我支持可以納入並建議維基編輯在一般條目原始碼編輯中使用U+2212當作負號或減號使用，不認為"大多數程式語言則使用連字暨減號（-）表示減號/負號。"為全面的觀點描述，反對任何"要求編輯不應在一般條目編輯中將U+002D當作減號或負號使用"的論點，另外質疑目前似乎沒有叉乘號的說法，依照乘號的內容："名稱為「乘號」，亦稱作「叉號」或「交叉」"。--Anghualee（留言） 2022年10月26日 (三) 04:33 (UTC)

• “大多数程式語言则使用連字暨減號（-）表示减号/负号”是事实而非观点，语出en:Hyphen-minus#Programming languages。如果该事实描述尚不全面的话，欢迎给出增改建议。
  • 许多MediaWiki扩展、模板、模块等只接纳U+002D而非U+2212作为输入，个人认为这些包括在“程式語言”的范畴中，加之格式手册规范条目最终呈现的性质甚于源码编排，因此没把这一点写进提议条文。
• 个人认为根据使用场景的不同，U+2212与U+002D中只有一个是最合适的符号，难以想象有两可的场景。虽不必将另一种符号视为错误，但若有心者愿意调整为最合适的符号，自然是好的。
• 叫「叉號」或「交叉」就看不到乘法运算的含义了；“乘號”是包括了⋅和×二者的（参考），但我没找到两种符号并列时各自的常用称谓。如果没有更好的方案，权将二者名称合并称为“乘號”吧。

--Lt2818（留言） 2022年10月26日 (三) 12:00 (UTC)

• 然後 en:Hyphen-minus#Programming languages 引用了兩種程式語言的手冊，而裡面壓跟沒提 hyphen-minus，其中一個引用還被打上"頁數呢？"。事實是現代大部分程式語言的原始檔編碼都支持 Unicode，而用鍵盤打程式碼來講，打出U+002D比打出U+2212快太多了，工程師幹嘛要直譯器或編譯器額外增加處理一個大家都不用的U+2212？我就好奇有哪個打字訓練軟體要求你打U+2212而非U+002D了？而且就算你堅持那個是事實，說真的，也不影響。因為重點在於不夠全面，事實上一般使用（不限於程式語言）上 hyphen-minus 可以作為減號使用，就是 en:Hyphen-minus 一開頭引用了 Unicode explained 的論述，同時也是更為全面的觀點。
• 當然如你所說，在可使用選擇更完整的情況下，會有更合適的符號（畢竟 Unicode explained 裡面也是這樣認為的），所以我一開始就說我支持"納入並建議使用U+2212"。但是考量 Legacy 支援，根據目前鍵盤還沒有廢除或者是完全將 minus 完全獨立（畢竟有無數字鍵鍵盤），也就是對一般使用者來說，依舊會有採用連字暨減號作為減號使用的狀況，自然完全就符合 Jukka K. Korpela 撰寫的 Unicode explained 中所述這屬於 ASCII Legacy 支援的部分。同樣在一般新聞使用上（好比說這篇）也一樣會使用。考量到以上狀況，避免造成一般編輯上的困擾，所以我也提出了反對"不使用U+002D"的意見。
• 根據使用場景的不同，⋅和×中只會有一個是乘號。而照 Unicode 來講的話，⋅叫 Dot operator。--Anghualee（留言） 2022年10月26日 (三) 13:17 (UTC)

• 我自己接触过的程式語言全部使用连字暨减号，但en:Plus and minus signs#Uses in computing列了两种语言不用它表示负数。不觉得把“大多数……”这句话当事实呈现有什么问题。
• 维基百科使用Unicode，个人认为不需要在格式手册里描述仅有ASCII编码时该如何写数学符号，感兴趣的读者点进链接看就行。否则ASCII使用*/表示乘除，也要一并写入了。
• 我觉得做好Legacy支援与标明最合适的符号并不冲突，譬如重定向即是一个方面，-1可以重定向到−1。
• Dot operator的名称也看不出乘法的含义，且搜索Dot operator出来的许多是程式語言中的概念。Unicode的字符名称未必覆盖使用场景，甚至出错了都不改，“杭州码子”的命名错误即是一例。

--Lt2818（留言） 2022年10月27日 (四) 02:45 (UTC)

這倒提醒我了，你用的en:Plus and minus signs#Uses in computing段落裡面就有用/（U+002F），即便不作為除號使用，分數（en:Fraction）的部分也該提到⁄（U+2044）吧？至於Dot operator我也只是提一下 Unicode 是用此名稱（其實⋅也看不出乘號），我基本上只對叉乘號有意見，對點乘號其實沒講話，畢竟點運算子跟點乘號我還真分不出來哪個比較醜，你自己改回乘號然後糾結，這跟我沒關係的呀。其實跟 hyphen-minus 一樣丟到備註去就好了，只是你自己過不去而已。--Anghualee（留言） 2022年10月27日 (四) 04:32 (UTC)

把/写进除号一栏的备注里了。把⋅丟到備註仍然需要介绍其HTML实体，还不如现在这样。--Lt2818（留言） 2022年10月27日 (四) 07:22 (UTC)

关于WP:命名常规与WP:POV的冲突

算一个比较长久的问题，现时对条目命名最直接影响的WP:命名常规，并没有提及POV的问题，而WP:POV对命名的观点主要是这样：

“

一篇维基百科条目须有一个确定的名称。防止分列观点的普遍限制同样适用于条目名称。如果与条目主题相关的命名争议的确存在，这一争议应当出现在条目内容当中，并以可靠来源加以证实。此外，维基百科编者不能为了解决非中立争议而使用标新立异的条目名称。将条目名称分段并列也是错误的做法，比如“地平说的地球／地圆说的地球”或“地平说的地球 (地圆说的地球)”的形式都是不正确的。合成词也可能是不适当的，如“地球的形状”或“地球 (形状上有争议)”；特别应注意不能为了解决分列的观点而刻意杜撰新名词。

有些时候，条目标题本身可能便是争议与对立的来源。特别是当描述性标题所表明的观点“支持”或“反对”某一特定议题时。中立的条目标题是非常重要的，因为它能确保文章的主题出现在合适的上下文中。因此，百科式的条目标题应能表现出最高程度的中立性。条目可以在尽量少用感情词汇的情况下涉及相同的内容，或为了确保中立观点而涉及更多的内容（例如将“对毒品的批评”修改为“对毒品的社会观点”）。中立的标题鼓励多种观点以及负责任的条目写作。

当条目标题为姓名等专有名词时，可能出现的争议往往是应不应该使用某一特定名称。维基百科对此倾向于描述而非指定，应使用在可查证的可靠来源中找到的常见中文名称。如果对象是地理特征等没有生命的实体时，一般应使用中文出版物中最常见的名称。参见Wikipedia:命名冲突以获取进一步的指引。

”

。

然后，在讨论一个条目命名的问题时，我跑去看了一下现时命名常规的来源（大概是？），en的en:Wikipedia:Article titles，然后留意到是有对POV的说明，初步翻译如右（User:Cwek/工作室/关于条目常规的一些备存），大概意思就是两类：如果来源够多，即使看上去用词不中立的现在常用的名称，可以用；或者可以创建一个使用中立词语的描述性用语。POV在en关于命名的章节也初步翻译过（意见：大致相似，但有部分差异）。另外，也列出了部分涉及是否考虑POV的命名常规讨论。

所以，我们是否考虑在命名常规中考虑POV的需要？ ——Sakamotosan路过围观 | 避免做作，免敬 2022年10月20日 (四) 08:35 (UTC)

补充，en命名常规关于POV的说明，初步找到是2010年5月时的。——Sakamotosan路过围观 | 避免做作，免敬 2022年10月20日 (四) 08:44 (UTC)

@Ch.Andrew、Shizhao、Reke、Mewaqua、Gakmo：，提及一下Wikipedia_talk:命名常规/存档10#关于修改维基百科:命名常规的建议_2有参与讨论仍有活跃的。——Sakamotosan路过围观 | 避免做作，免敬 2022年10月21日 (五) 01:16 (UTC)

@Peacearth、蘇州宇文宙武、Happyseeu：，提及一下Wikipedia_talk:命名常规/存档11#提議：命名常規不應違反中立性原則有参与讨论仍有活跃的。——Sakamotosan路过围观 | 避免做作，免敬 2022年10月21日 (五) 01:18 (UTC)

@Chiefwei、Silvermetals：，提及一下Wikipedia_talk:命名常规/存档11#中文維基百科命名常規引起的問題有参与讨论仍有活跃的。——Sakamotosan路过围观 | 避免做作，免敬 2022年10月21日 (五) 01:20 (UTC)

我的理解，所谓描述性用语是指那些非专有名词类的条目标题，例如“对xxx的批评”，“xxx争议”，“20xx年xxxx事件”，这一类不太会在其他出版物中使用的短语。所以，“如果来源够多，即使看上去用词不中立的现在常用的名称，可以用；或者可以创建一个使用中立词语的描述性用语。”。在我看来二者并不是“或”的关系，而是对两类标题的两种规范方式（专有名词：常用，可以POV；其他的描述性用语：应当尽可能NPOV），是并行的--百無一用是書生 (☎) 2022年10月21日 (五) 02:18 (UTC)

@Shizhao：，这个问题，一来命名常规早就讨论过几次，二来是来源于西藏和平解放‎‎的问题，因为一直有编辑认为需要体现POV（或者是他们的主观“中立”），需要更换命名，但我认为根据现有命名常规并没有POV的要求，而且POV对于命名中有提到这类有争议的有专有名词的，可以跟随命名常规的常用性。按照现有规则，这个命名暂时不需要修改（满足命名常规的常用，处于争议状态下的最后一个正常命名，而且属于POV排除情况）。但考虑这些编辑对于POV的执着，我看了en的做法，留意到en对于POV是有这样的表述，刚好对应提及的两种情况：“西藏和平解放”是（可能）不中立的但常用，他们也挑选了“中国吞并西藏”（我认为可以选择更中性的“中国占领西藏”）符合中立的描述性用语。

如果考虑修正命名常规和POV（由于涉及专有名词部分应该是排除性条件），则可以考虑上面两个方案再选择合适的命名，如果不修正的话，则可以说明“命名常规不需要考虑POV，POV即使作为支柱之一是可以忽略的（而且它的确有一个豁免条件）”，那除非挑战“西藏和平解放”的常用性（用其他更好的可以量化的判断方法），否则以POV作为命名调整的依据是不成立的。

这个改动可能影响广泛，大量现时以中国大陆观点并且满足命名常规常用原则的条目，就都可以POV来挑战。——Sakamotosan路过围观 | 避免做作，免敬 2022年10月21日 (五) 03:14 (UTC)

可以加入說明，但我也同意如書生所言，應該沒什麼衝突。就我的理解是如果專有名詞本身帶有POV，仍以常用為主。比方說國共內戰的許多戰事都有雙方命名，各在兩岸為常用語，此時無論用何者為主條目命名都POV，而維基並不能自創一個NPOV的名稱。但如果是描述性的標題，就要儘量NPOV。--Reke（留言） 2022年10月21日 (五) 03:27 (UTC)

• 如果追求名称绝对中立，也许意味着命名忌用入侵等负面词汇（如同条目中忌用感叹号），不局限于中国大陆问题。广泛原创出不常用命名的后果，恐怕很糟。使用文献中最常见、广泛的称呼，并在序言阐明，应能应对大多数情况，也利于读者搜索和对应概念。
• ( π )题外话，偽滿皇宮博物院、伪满洲国交通部旧址等本身是事物专有名称（保护建筑）但同时是事物描述的条目命名，又是否要“中立化”。后者如果改掉条目名，序言写清事物名称就比较啰嗦了。前者改名等于原创命名或变更主题。
• 另应参考WP:NPOVFAQ、WP:YESBIAS，绝对中立的后果可能是，伪科学叫“未被主流认可的科学体系”。

--YFdyh000（留言） 2022年10月21日 (五) 03:56 (UTC)

基于西藏和平解放的问题，1.我们需要为命名常规和POV添加关联性；2.如何行文？因为命名常规的POV注意是在“常用”中提及并单独一章，而en的POV也提到只要常用，就算对于某些人来说是非中立的，或者POV，也是可以的；3.如果确立了命名常规和POV的关联性，这个个例这样使用？是用可能是非中立但常用的“西藏和平解放”，还是略常用、非中立、带有描述性（？）的“中國吞併西藏”，还是一般常用、中立、带有描述性的“中国占领西藏”？关于常用的搜索引擎检查，这里一个记录：User:Cwek/工作室/西藏。——Sakamotosan路过围观 | 避免做作，免敬 2022年10月21日 (五) 04:56 (UTC)

作为百科全书，应该考虑检索问题。可以常用名称优先，即使它很偏离主流立场；如果有多个立场相互冲突的常用名称，则“先到先得”，或者用{{NoteTA}}处理，禁止无故移动条目名称。至于标题名称的问题，可以放到导言里面去详细讲述。--高文海（留言） 2022年10月26日 (三) 06:31 (UTC)

WP:TITLE和WP:POV綜合理解說就應當是以通用兼描述性地標明相關稱謂，但基於WP:地域中心等系統的影響而言有關實踐並在本地議題是否完滿，包括結論本身是否合乎通行維基尺度而言是很難定論的。

如有關WP:VPD可能仍存有爭議之個別裁判所命名問題，在主推議案人限定以中文圈之地方法院潛在導致一統本地既有或未來所有裁判所命名情況，該如何判定相關引用基礎之中立客觀？唯一強調法則即如以單一時限之中文文獻優先，不考慮日文與中文長久相互貫通因素、且有關術語亦並非罕見而見諸於中文文本自身含專業層面，是以強調採編仍以一統使用中文地區命名而限制有關客觀中立立足之下，命名優先之選擇問題，恐並非基於使用是否廣泛或是否合乎通常認知、語文沿襲習慣等法，而全賴於當期主事強調之時所採用之壓制化路線是否得以成型而定。

個案而言，有關通行規則本身在部分個案內被單獨孤立依照其本身採編單一意向而孤立援引之時，在如既已有既定之非以合乎綜合材料觀點研判、非以合乎參議之時所通俗理解或通常使用邏輯知識，僅以如whataboutism及變相堆砌無異議之單一意向氛圍下而強調合乎一切所謂商議並自行定論，有關命名移動等皆已無可挑戰、是以相應社區及社羣實際並未有適切比例地落實到一直以來需要各使用者盡力之協作及適當參與等維基要義。

方針問題即在於實際採用之時，是為基於合乎方針背後維基核心之超越系統局限而顯維基多元及廣泛知識面，或基於與之相反路線，矛盾不加制約，則可繼續舊往。--約克客（留言） 2022年10月26日 (三) 07:39 (UTC)

---

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

為使用者查核員選舉導入安全投票機制並修正被選舉資格

基於先前基金會對本地使用者查核權恢復的回應進行提案，有幾處進行修正：

修正WP:CU

現行條文 申请资格 （前略） 一般情况下，被提名候选人应具备以下条件（非正式条件）： 连续担任管理员3个月或以上； 按照维基方针和守则使用管理员权限，没有破坏规则或滥用权限； 积极行使管理员义务。 資格取消 具有用戶查核资格的用户帐号，如果超过半年没有活动，用戶查核资格将被取消。 （後略）

提議條文 申请资格 （前略） 一般情况下，被提名候选人应具备以下条件（正式条件）： 應具有調查助理資格達半年或以上； 其具備管理員權限資格一年或以上； 按照维基方针和守则使用管理员权限，没有破坏规则或滥用权限； 积极行使管理员义务。 資格取消 具有用戶查核资格的用户帐号，如果超过半年没有活动，用戶查核资格将被取消。使用者查核員的任期為兩年，期滿後其使用者查核員資格應取消，而連任則僅限一次並應重新辦理選舉。有人事任免投票資格的用戶可以安全地提出自己的質疑，此質疑有效期為一年，或是到下次用戶查核員選舉之前；如果有超過25人之質疑關切，就會在兩個月內觸發罷免，除非該查核員選擇不競選連任。 （後略）

修正WP:CUP

現行條文 取得權限 只有监管员、部分维基媒体基金会职员、申訴專員和极少数的用户有权获得用户查核权限。除了申訴專員外，用户只能获得本地权限。 （後略）

提議條文 取得權限 只有监管员、部分维基媒体基金会职员、申訴專員和极少数的用户有权获得用户查核权限。除了申訴專員外，用户只能获得本地权限。在授予權限之前，所有中文維基用戶查核員候選人都將會接受用戶查核員社群的培訓，以確保中文維基上的用戶查核實踐與全球社群一致。 （後略）

修正WP:RfA

現行條文 安全投票暫行規定 根據社群2022年9月的共识，未來一場管理員選舉將使用安全投票（SecurePoll）系統。 未來一場使用安全投票系統的管理員選舉將按照以下程序進行，不適用前述之一般流程： 提名或自薦：使用者可以提名自己為管理員，也可以提名另一個使用者為管理員。 檢驗冷靜期：當管理員被提名者先前之管理員選舉未通過或中途退選時，自投票終止或退選之時起，三個月（90日）內不應再次提出申請。在表態時謝絕提名者不受此限制。 投票過程： 预提名：未来一场选举将仿照此前的安全投票选举流程，统一在互助客栈其他区进行预提名。在第一位候选人预提名提出之时，为期七天的预提名程序即开始，在此七天内皆可提名其他候选人。在此七天内，愿意接受正式提名并回答前述三个基本问题、得到七位具人事任免投票资格之用户联署支持，且符合成为管理员之资格者，经行政员确认，即获得正式提名，并将统一进行选举，且应比照前述之一般流程另行设置个人选举页面。依照社群2022年4月的共识，此次预提名不受前次“检验冷静期”限制。 發表意見：在被提名者經行政員確認獲得正式提名之時起二週內，任何使用者都可以發表意見，包含提問及討論等。二週後，被提名者仍可以回答問題，而其他使用者則不應再提出新問題或繼續展開討論。與此同時，應儘速籌備安全投票。投票時間之起始點可以視乎實際準備情況需要提前或延後，惟發表意見之時間長短不應有所增減。 投票：安全投票开启后，应至少持续二周，并应有至少二位管理人员与其他监管员共同协助监票。在预提名开始时具人事任免投票资格，且在被提名者经行政员确认获得正式提名之时未被封禁或禁制编辑维基百科命名空间的用户可以投下支持票、反对票或中立票。投票期间，投票者可以随时改变自己的决定，其态度按投票截止时为准。选举之有效票比照前述之一般流程仅包括上述可投票者所投的支持票及反对票，中立票属无效票，仅将在临界情况下被考虑。 計票和評估：投票結束後，應由協助監票之管理人員計算出得票比率，並會同行政員根據前述之一般流程標準判斷投票是否達成共識。 執行結果：若投票通過，行政員或監管員將賦予被提名者管理員權限；不通過則做出相應的操作。

提議條文 安全投票暫行規定 根據社群2022年9月的共识，未來一場包含使用者查核員在內的管理人員選舉將使用安全投票（SecurePoll）系統。 未來一場使用安全投票系統的包含使用者查核員在內的管理人員選舉將按照以下程序進行，不適用前述之一般流程： 提名或自薦：使用者可以提名自己為包含使用者查核員在內的管理人員，也可以提名另一個使用者為包含使用者查核員在內的管理人員。 檢驗冷靜期：當包含使用者查核員在內的管理人員被提名者先前之包含使用者查核員在內的管理人員選舉未通過或中途退選時，自投票終止或退選之時起，三個月（90日）內不應再次提出申請。在表態時謝絕提名者不受此限制。 投票過程： 预提名：未来一场选举将仿照此前的安全投票选举流程，统一在互助客栈其他区进行预提名。在第一位候选人预提名提出之时，为期七天的预提名程序即开始，在此七天内皆可提名其他候选人。在此七天内，愿意接受正式提名并回答前述三个基本问题、得到七位具人事任免投票资格之用户联署支持，且符合成为相對應的管理人員之资格者，经行政员确认，即获得正式提名，并将统一进行选举，且应比照前述之一般流程另行设置个人选举页面。依照社群2022年4月的共识，此次预提名不受前次“检验冷静期”限制。 發表意見：在被提名者經行政員確認獲得正式提名之時起二週內，任何使用者都可以發表意見，包含提問及討論等。二週後，被提名者仍可以回答問題，而其他使用者則不應再提出新問題或繼續展開討論。與此同時，應儘速籌備安全投票。投票時間之起始點可以視乎實際準備情況需要提前或延後，惟發表意見之時間長短不應有所增減。 投票：安全投票开启后，应至少持续二周，并应有至少二位管理人员与其他监管员共同协助监票。在预提名开始时具人事任免投票资格，且在被提名者经行政员确认获得正式提名之时未被封禁或禁制编辑维基百科命名空间的用户可以投下支持票、反对票或中立票。投票期间，投票者可以随时改变自己的决定，其态度按投票截止时为准。选举之有效票比照前述之一般流程仅包括上述可投票者所投的支持票及反对票，中立票属无效票，仅将在临界情况下被考虑。 計票和評估：投票結束後，應由協助監票之管理人員計算出得票比率，並會同行政員根據前述之一般流程標準判斷投票是否達成共識。 執行結果：若投票通過，行政員或監管員將賦予被提名者相對應的管理人員權限；不通過則做出相應的操作。

以上提請社群討論。--🍫巧克力～✿ 2022年10月24日 (一) 04:37 (UTC)

别着急，修改CU选举机制的必要条件是社群同意重新引入CUer，而这件事看起来没那么容易 ——魔琴 [ 留言 贡献 ] 2022年10月24日 (一) 04:53 (UTC)

這部分我覺得可以先修方針，等之後社群確定要正式重啟，前置工作與改動範圍也不會那麼大。--🍫巧克力～✿ 2022年10月24日 (一) 05:00 (UTC)

問題：

1. 「應具有調查助理資格達半年或以上」：街燈慘被失去選CU資格。而且還變成了必要條件，沒有必要吧。
2. RFA還有很多問題要修。比如這處就是一例。現在討論也急了一點。
3. 先說服社群需要CU再搞這個提案。

--Ghren🐦🕛 2022年10月24日 (一) 04:54 (UTC)

• 事實上，「應具有調查助理資格達半年或以上」可以調整成為管理員、行政員或調查助理這三個條件並列則一即可，是可以視情況修正的。
• 每一次投票當然也會有事前討論與事後調整，這部分並不影響CU權限導入安全投票機制的問題，也因為是擴大套用，之後選舉流程在調整的過程中也會因為涵蓋範圍大而更有彈性一些。
• 如同我上面說的，這部分我覺得可以先修方針，等之後社群確定要正式重啟，前置工作與改動範圍也不會那麼大。

--🍫巧克力～✿ 2022年10月24日 (一) 05:09 (UTC)

不同意將「非正式條件」改為「正式條件」。調查助理的資歷可以是「加分」，但不應該強制納入權限之申請門檻。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年10月24日 (一) 05:27 (UTC)

• @ghrenghren、Ericliu1912：針對修正WP:CU，改成下列這樣：

現行條文 申请资格 （前略） 一般情况下，被提名候选人应具备以下条件（非正式条件）： 连续担任管理员3个月或以上； 按照维基方针和守则使用管理员权限，没有破坏规则或滥用权限； 积极行使管理员义务。 資格取消 具有用戶查核资格的用户帐号，如果超过半年没有活动，用戶查核资格将被取消。 （後略）

提議條文 申请资格 （前略） 一般情况下，被提名候选人应具备以下条件（非正式条件）： 其具備行政員、管理員等管理人員或調查助理權限資格一年或以上； 按照维基方针和守则使用管理人員权限，没有破坏规则或滥用权限； 积极行使管理人員义务。 資格取消 具有用戶查核资格的用户帐号，如果超过半年没有活动，用戶查核资格将被取消。使用者查核員的任期為兩年，期滿後其使用者查核員資格應取消，而連任則僅限一次並應重新辦理選舉。有人事任免投票資格的用戶可以安全地提出自己的質疑，此質疑有效期為一年，或是到下次用戶查核員選舉之前；如果有超過25人之質疑關切，就會在兩個月內觸發罷免，除非該查核員選擇不競選連任。 （後略）

以上。--🍫巧克力～✿ 2022年10月24日 (一) 05:33 (UTC)

此处原有文字已被原作者（User:Yining Chen）移除。2022年10月24日 (一) 07:48 (UTC)

為什麼「連任則僅限一次」？所以在你的方案下每個CUer都只能最多當四年？——〚 玖宸 〛 2022年10月24日 (一) 12:32 (UTC)

理論上可以當二任，間隔一任然後再參選，之後以此類推。不過個人覺得似乎是沒有必要這樣規定。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年10月25日 (二) 00:45 (UTC)

有關這部分設計是參考基金會回應當中有關連任的釋疑，那考量到長時間的任期處理高敏感隱私政策對社群來說可能不是那麼的健康，所以才提出限制連任的部分，那當然中間經過休息期，如劉醬所述，間隔一任然後再參選，之後以此類推，這樣是沒有太大的問題的。--🍫巧克力～✿ 2022年10月25日 (二) 04:44 (UTC)

若社群信任當事人處理某些隱私事務而賦予其使用者查核權限，那麼禁止維基人連任使用者查核員是否代表這種信任是有所謂「有效期限」的，還是會過了一段時間便「突然不信任」當事人？就此而言，我不甚認同該等規定。基金會之所以沒有限制使用者查核員連任，相信與此理據也不相差太遠；任期制本身就是一種確認社群對當事人信任之機制。而實際上來說，社群中是否有充足之人選可使吾人信任，多到能夠特地錯開任期、輪流「值班」的地步？這也是一個問題。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年10月25日 (二) 08:39 (UTC)

不同意只能連任一次，做的好為什麼要強迫炒魷魚？基金會的回應最多只是希望定期評核，怎麼也不是在說永久擔任是不健康的。我反倒支持擔任調查助理幾個月作為必要條件，這樣才能更有效驗證是否對調查程序十分了解，不必為街燈或者其它前度查核員大開綠燈。--Opky9407（留言） 2022年10月25日 (二) 11:47 (UTC)

(－)強烈反对clerk能够在不担任管理员的前提下选举成为用户查核员。若用户查核员选举只需“担任clerk满一年”即可参选，那岂不是意味着在中维，对用户查核员的要求甚至不如管理员？在中维尚有CU权限时曾出现过

“至少3個管理員，說過：把自己的管理員帳戶給我。但都被我拒絕。我回答：等你們什麼時候混成CUer了，再把帳戶給我。現在CUer才是王道。管理員雖然也重要，但可CUer相比差得遠。”

——KOKUYO（转述）

这种言论。假若在这种社群环境下依然继续降低用户查核员的标准，那该如何才能确保社群的信息安全，避免第二次事故发生？简而言之，个人不认为“连管理员都尚未担任”的用户有资格担任CUer。这样的用户可能并不值得社群信任。--Yining Chen（留言|签名页） 2022年10月26日 (三) 14:32 (UTC)