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

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

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

公告欄

• [人事] 仲裁委員會選舉已有結果，10名用戶當選仲裁員。
• [公告] 用户组自我除权、GFDL相關規範加入及WP:ITNR字眼的小修訂已經通過。
• [公告] 母公司子品牌列出規範、修訂优特标准、引入WP:ONUS、修订用户名方针与用户页指引、修訂圖表説明結尾有無句號及條目“大小”不宜移動、重定向或合併到題目“尺寸”一事與變更條件正在公示，如有意見請儘快提出。
• [討論] 互助客栈技术区正在討論修订过滤器警告信息，請踴躍參與討論。
• [討論] 互助客栈方针区正在討論在非原創方針新增例子以禁止綜合常識及可靠來源及擴充ITNR獲選類別，請踴躍參與討論。
• [討論] 互助客栈其他区正在討論是否应关闭中文维基百科以抗议基金会举措、管理人員任免制度檢討等事及本地部署安全投票及相关权限，請踴躍參與討論。
• [广告] 維基百科亞洲月及其分項北亞月現正舉行，直至11月30日完結，歡迎踴躍參與！

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

#	💭 話題	💬	👥	🙋 最新發言	🕒 (UTC+8)
1	关于WP:非原创研究方针是否适用于模板；以及判定模板为“原创研究”的客观标准	49	16	Nostalgiacn	2024-11-17 01:44
2	提议将金砖国家峰会纳入Wikipedia:新聞動態/重複發生的項目	31	11	Patrickov	2024-11-18 12:46
3	修正优特标准的翻译腔问题	29	10	自由雨日	2024-11-22 20:34
4	关于仲裁委员会职权的疑问	2	2	Ericliu1912	2024-10-27 02:16
5	仲裁委員會成立後的管理人員解任機制（續）	1	1	LuciferianThomas	2024-10-28 09:38
6	關於日本選舉的標題問題	16	5	FK8438	2024-11-18 13:02
7	关于用户名方针与用户页指引的重大修订建议	19	11	阿南之人	2024-11-19 23:33
8	修訂娛樂產業內容相關共識之藝人條目綜藝節目列表章節	21	8	CaryCheng	2024-11-18 10:50
9	討論被錯誤理解達成共識應該怎樣做？	3	1	Factrecordor	2024-11-14 21:39
10	修订政治人物关注度指引	39	12	CaryCheng	2024-11-18 12:15
11	完善WP:封禁「不限期不是永久」總方針	41	13	WiiUf	2024-11-20 18:04
12	有關簽名附帶的文字的問題（第三次）	41	9	Dryrace	2024-11-19 12:43
13	关于本地化资讯是否为琐碎内容的问题	18	6	Factrecordor	2024-11-16 20:47
14	导向重复的列表拆分逻辑是否成立？	42	3	红渡厨	2024-11-18 16:37
15	A/B分支仲裁	6	4	Iming	2024-11-19 21:29
16	关于Wikipedia:避免地域中心#地理，建议增加关于“来”字的论述	15	8	航站区	2024-11-24 11:34
17	關於非原創研究問題	40	10	航站区	2024-11-24 11:25
18	修订WP:外文重定向方针与首句MOS:外语名称格式指引，并将他们对应	10	4	自由雨日	2024-11-21 14:25
19	infobox nativename應否加粗	9	5	Sohryu Asuka Langley Not Shikinami	2024-11-23 15:38
20	部分基础条目是否应视为高风险主题及反破坏的方法	3	2	暁月凛奈	2024-11-23 18:57

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

正在廣泛徵求意見的議題

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

維基百科格式與命名

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 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:互助客栈/其他 § 為管理人員任免制度檢討等事

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

改革管理员的解任程序

為整合有關主題的討論，本討論已移動至Wikipedia:2021年基金會針對中文維基百科的行動/本地社群政策相關討論 § 改革管理员的解任程序進行集中討論。請至有關頁面發表意見。

執行人：Eric Liu _{歡慶雙十中國國慶（留言．留名．學生會）} 2021年10月8日 (五) 21:17 (UTC)

本討論章節會維持開放，暫時不按最後意見發表時間存檔，直到集中討論告一段落。欲讓機器人存檔，請移除本模板。留言請置於本模板上方。

管理人員選舉制度改革

為整合有關主題的討論，本討論已移動至Wikipedia:2021年基金會針對中文維基百科的行動/本地社群政策相關討論 § 管理人員選舉制度改革進行集中討論。請至有關頁面發表意見。

執行人：Eric Liu _{歡慶雙十中國國慶（留言．留名．學生會）} 2021年10月8日 (五) 21:17 (UTC)

本討論章節會維持開放，暫時不按最後意見發表時間存檔，直到集中討論告一段落。欲讓機器人存檔，請移除本模板。留言請置於本模板上方。

提议调整人事任免投票门槛

（前十个方案由于无共识，现已存档）

意见征集

根据以上讨论，现决定中止公示，但仍进行最后意见征集。以问卷调查的方式进行：

1. 注册满（180/150/120/90）天，且解任投票聯署提出或上任投票開始（120/90/60/30）天前，編輯至少500次。
2. 您是否支持收紧活跃度要求？若支持，则应收紧为（75/60/45/30）天？
3. 其他意见。

--12З4567（留言） 2021年12月14日 (二) 05:47 (UTC)

1. 注册满120天，且解任投票聯署提出或上任投票開始120天前，編輯至少500次。
2. 不支持，保持90天有1次编辑。
3. 编辑1500或3000次者，活跃度要求为六个月，与IPBE一样。

--桐生ここ★[讨论] 2021年12月14日 (二) 06:56 (UTC)

(！)意見1.本讨论宜以“无共识”终止。2.个人认为收紧活跃度限制这一做法可能无法起到任何预期效果。--Yining Chen（留言|签名页） 2021年12月20日 (一) 15:32 (UTC)

我认为能不能有预期效果还是得做了试行一段时间才能知道，现在这么讨论法也不会有什么结果。但我认为可以先不终止，得让更多人看到这讨论，继续发表意见。--Tazkeung（留言） 2021年12月25日 (六) 18:11 (UTC)

我的意见是：

1. 注册满120天，且解任投票联署提出或上任投票开始120天前，编辑至少500次。
2. 不支持，保持90天有1次编辑。
3. 没有其它意见。

--Lanwi1(留言) 2021年12月28日 (二) 04:31 (UTC)

• (！)意見：

1. 注册满120天，且解任投票聯署提出或上任投票開始120天前，編輯至少500次。
2. 不支持，保持90天有1次编辑。
3. 無。

--Kriz Ju（留言） 2022年1月6日 (四) 02:34 (UTC)

方案十一

意见征集已有一个月，共收集到4条有效意见，且意见均为“维持原状”。根据意见，现决定公示以下仅修饰语句、不做任何实质性的修改的版本：

現行條文 凡管理人員解任投票聯署或上任投票開始之前，注册满七天且符合以下兩項之至少一項條件者有權投票： 解任投票聯署提出或上任投票開始120天前，編輯至少500次；並在聯署提出或上任投票開始前90天內至少有1次編輯（不包括任何用戶頁及用戶對話頁）； 編輯至少3000次，或編輯條目至少1500次。 以上所称“编辑”，均指在中文維基百科的编辑，不含明显的破坏和测试。

提議條文 凡管理人員解任投票聯署或上任投票開始之前，符合以下條件者有權投票： 解任投票聯署提出或上任投票開始120天前，編輯至少500次；並在聯署提出或上任投票開始前90天內至少有1次編輯（不包括任何用戶頁、用戶對話頁及沙盒）；或 編輯至少3000次，或編輯條目至少1500次。 以上所称“编辑”，均指在中文維基百科的编辑，且不含明显的破坏和测试。

公示期为7天，若无异议则通过。--12З4567（留言） 2022年1月16日 (日) 08:10 (UTC)

怎麼挑出沙盒編輯？因編輯條目而在沙盒編輯算不算？而這又跟直接編輯條目有什麼差別？這裡的沙盒是否包含草稿？—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年1月16日 (日) 08:27 (UTC)

• @Ericliu1912：没有必要鸡蛋里挑骨头。沙盒是Tazkeung的意见。按照您这种说法，因編輯條目而在用戶頁編輯怎么处理？如果您想针对某个维基人，请点击此处。--12З4567（留言） 2022年1月16日 (日) 09:08 (UTC)
• 其他 說明：关于投票问题，能不投票尽量不投票，否则就会像WP:投票/缩减管理员不活动期限一样。“注册满七天”并不能起到实际限制的作用，因为第一条“120天前”即“注册满120天”，至于第二条，目前并没有注册不满七天且符合此项条件的用户，故删除。“兩項之至少一項”已用新增的“或”表示。桐生君把“注册满七天”改为120天，实际上等于收紧了第二项条件，不属于非实质性修改。（由于编辑冲突，实际发布时间应为08:30 (UTC)）--12З4567（留言） 2022年1月16日 (日) 09:12 (UTC)

  不好意思，我就是要「雞蛋裡挑骨頭」。修訂應當考慮到所有情形，另外現在我不挑剔，將來也會有人挑，因此這裡就由我來做這個角色。命名空間是明確的，但「沙盒」這個概念不明確。我自己就是在使用者頁面編輯條目，所以真要針對也是先針對我自己，還輪不到別人。—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年1月16日 (日) 18:45 (UTC)

  移动到条目时起视为条目空间编辑。--桐生ここ★[讨论] 2022年1月16日 (日) 18:57 (UTC)

  所以草稿是否為沙盒？如果是這樣那我建議把這裡的「沙盒」改為草稿與草稿討論命名空間，實際涵蓋範圍仍然不變。—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年1月16日 (日) 19:00 (UTC)

  在沙盒的编辑测试不可能移动到条目，而在沙盒的草稿可以发布移动到条目，所以编辑测试属于无效编辑，草稿属于有效编辑。桐生ここ★[讨论] 2022年1月17日 (一) 02:24 (UTC)

  我尋思有誰會刻意用WP:沙盒，草稿多半都是要發佈的，也不算是一個大問題。--Ghren🐦🕓 2022年1月17日 (一) 09:22 (UTC)

不同意移除「兩項之至少一項」，這兩項之中都有「且/或」連接詞，不是所有人都很清楚且跟或的優先順序，能轉為條列式就應該轉為條列式，並使用「以下條件之一」的構句來讓條件更加清晰易讀。--Xiplus#Talk 2022年1月17日 (一) 13:46 (UTC)

如果只是語意調整，請WP:沒壞別修。--Ghren🐦🕐 2022年1月19日 (三) 17:12 (UTC)

仅支持去掉那个“七天”，七天1500笔条目编辑也太恐怖了吧…… ——魔琴 [ 留言 贡献 ] 2022年1月27日 (四) 11:32 (UTC)

不行，万一真的行呢，还是把“七天”提进第二点里吧。 ——魔琴 [ 留言 贡献 ] 2022年1月27日 (四) 11:33 (UTC)

自確必定要7天啊，只要隨意清清消歧7天1500不太難吧。--Ghren🐦🕗 2022年1月27日 (四) 12:14 (UTC)

方案十二

現行條文 凡管理人員解任投票聯署或上任投票開始之前，注册满七天且符合以下兩項之至少一項條件者有權投票： 解任投票聯署提出或上任投票開始120天前，編輯至少500次；並在聯署提出或上任投票開始前90天內至少有1次編輯（不包括任何用戶頁及用戶對話頁）； 編輯至少3000次，或編輯條目至少1500次。 以上所称“编辑”，均指在中文維基百科的编辑，不含明显的破坏和测试。

提議條文 凡管理人員解任投票聯署提出或上任投票開始120天前，符合以下兩項至少一項條件者有權投票： 編輯至少500次；並在聯署提出或上任投票開始前90天內至少有1次編輯（不包括任何用戶頁、用戶對話頁及沙盒）； 編輯至少3000次，或編輯條目至少1500次。 以上所称“编辑”，均指在中文維基百科的编辑，且不含明显的破坏和测试。

这样比较好。桐生ここ★[讨论] 2022年1月27日 (四) 12:38 (UTC)

才看到上面的留言，确实是收紧了第二个条件，那这个只是供各位参考。桐生ここ★[讨论] 2022年1月27日 (四) 17:26 (UTC)

不过各位可以接受仅注册7天但有1500次条目编辑的用户投票吗？桐生ここ★[讨论] 2022年1月27日 (四) 17:27 (UTC)

（对整个讨论串的意见）我觉得老人条款应该要加一个六个月活跃。你六个月不活跃什么权都没了还能参加RfA不是很合理。-- ——魔琴 [ 留言 贡献 ] 2022年1月30日 (日) 10:28 (UTC)

不活躍除權是出於安全考慮。這跟有沒有投票權應該是兩回事。不過或許再長一些的不活躍期應該可矣。—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年1月30日 (日) 16:29 (UTC)

改成一年如何。桐生ここ★[讨论] 2022年1月30日 (日) 16:54 (UTC)

投票应该也要考虑帐号安全吧。我建议是210天（6月+延期的1月）。 ——魔琴 [ 留言 贡献 ] 2022年1月31日 (一) 08:38 (UTC)

方案十三

現行條文 凡管理人員解任投票聯署或上任投票開始之前，注册满七天且符合以下兩項之至少一項條件者有權投票： 解任投票聯署提出或上任投票開始120天前，編輯至少500次；並在聯署提出或上任投票開始前90天內至少有1次編輯（不包括任何用戶頁及用戶對話頁）； 編輯至少3000次，或編輯條目至少1500次。 以上所称“编辑”，均指在中文維基百科的编辑，不含明显的破坏和测试。

提議條文 凡管理人員解任投票聯署或上任投票開始之前，符合以下三項之至少一項條件者有權投票： 解任投票聯署提出或上任投票開始120天前，編輯至少500次；並在聯署提出或上任投票開始前90天內至少有1次編輯（不包括任何用戶頁及用戶對話頁）； 注册满七天，編輯至少3000次，並在聯署提出或上任投票開始前210天內至少有1次編輯； 注册满七天，編輯條目至少1500次，並在聯署提出或上任投票開始前210天內至少有1次編輯。 以上所称“编辑”，均指在中文維基百科的编辑，不含明显的破坏和测试。

 ——魔琴 [ 留言 贡献 ] 2022年1月31日 (一) 08:42 (UTC)

方案十四

現行條文 凡管理人員解任投票聯署或上任投票開始之前，注册满七天且符合以下兩項之至少一項條件者有權投票： 解任投票聯署提出或上任投票開始120天前，編輯至少500次；並在聯署提出或上任投票開始前90天內至少有1次編輯（不包括任何用戶頁及用戶對話頁）； 編輯至少3000次，或編輯條目至少1500次。 以上所称“编辑”，均指在中文維基百科的编辑，不含明显的破坏和测试。

提議條文 凡管理人員解任投票聯署或上任投票開始之前，符合以下兩項之至少一項條件者有權投票： 解任投票聯署提出或上任投票開始120天前，編輯至少500次；並在聯署提出或上任投票開始前90天內至少有1次編輯（不包括任何用戶頁及用戶對話頁）； 編輯至少3000次，或編輯條目至少1500次。 以上所称“编辑”，均指在中文維基百科的编辑，且不含明显的破坏和测试。

根据意见，修改后重新公示7天。--12З4567（留言） 2022年2月10日 (四) 14:50 (UTC)

這個方案的意思是說，賦予七日內註冊、編輯至少五百次者投票權？—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年2月10日 (四) 17:11 (UTC)

應該是編輯7天內編輯1500次條目就有權吧...--Ghren🐦🕑 2022年2月10日 (四) 18:14 (UTC)

刪除註冊滿七日之限制後，實際上就是允許投票前七日以內註冊、編輯至少五百次者投票。—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年2月11日 (五) 03:33 (UTC)

@Ericliu1912：但是怎可能在120天前編輯500次然後只注冊7天？--Ghren🐦🕐 2022年2月11日 (五) 05:00 (UTC)

7<120。我不會說達到這個門檻的可能性有多大，但此方案的效果即是如此。—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年2月11日 (五) 05:21 (UTC)

这是不可能的，“120天前，编辑至少500次”，说明120天前已经注册。但是注册七天内编辑3000次（或条目1500次）就有投票权。 ——魔琴 [ 留言 贡献 ] 2022年2月11日 (五) 08:20 (UTC)

「開始120日前編輯至少500次」，七日前也算在這120日前啊，開始七日前編輯至少500次就必然在開始120日前編輯至少500次了吧。這個前有歧義。—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年2月11日 (五) 17:33 (UTC)

「投票開始120天前，編輯至少500次」=「投票開始的120天前，編輯已滿500次」≠「投票開始前120天內，編輯至少500次」，這邊的人只有您誤解現行條文，看看下一句的「投票開始前90天內至少有1次編輯」就應該知道您錯在哪裡。--Xiplus#Talk 2022年2月12日 (六) 04:53 (UTC)

我昨天講完之後就自己去翻了一下討論，然後明白確實是自己誤會了。但我覺得條文可以寫的再清楚一些。—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年2月12日 (六) 08:16 (UTC)

可參考台灣的法令用詞：「員工應於離職日的10天前預告」，「雇主應於員工離職日的前10天內通報」。例如：「解任投票聯署提出或上任投票開始的120天前，至少已編輯達500次；並在解任投票聯署提出或上任投票開始的前90天內，至少有1次編輯（不包括任何使用者頁面及使用者對話頁）」--218.35.184.161（留言） 2022年2月13日 (日) 03:00 (UTC)

因为“注册七天内编辑3000次（或条目1500次）就有投票权”，所以反对。 ——魔琴 [ 留言 贡献 ] 2022年2月13日 (日) 11:33 (UTC)

你是跟Eric君有同一個誤解吧，請看Xiplus在2022年2月12日 (六) 04:53 (UTC)的留言。--路西法人☆ 2022年2月15日 (二) 03:32 (UTC)

他的反對意見和Ericliu1912的誤解不同。因本案首段刪除「註冊滿七天」後，第一項條件仍規定至少需註冊滿120天，第二項條件則只規定編輯數，未規定註冊時間。然而兩項條件只須符合其一即有權投票。--111.71.79.179（留言） 2022年2月15日 (二) 05:16 (UTC)

我覺得他的理解無誤。能不能不要在沒有人支持下不停公示？--Ghren🐦🕕 2022年2月15日 (二) 10:32 (UTC)

可以解释一下本章节内列出的14个方案是什么关系吗，是从其中要选择一个还是什么别的意思；有的小段落已经有超过三个月没有人讨论了，这些算是呗否决了吗。 Stang^★ 2022年2月24日 (四) 14:47 (UTC)

事實上我覺得這裡面沒有一案有共識的，不如維持原狀。—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年2月24日 (四) 16:05 (UTC)

這能不能雪球掉？都半年了。--Ghren🐦🕐 2022年2月25日 (五) 05:38 (UTC)+1 Yining Chen为此+1了。

• 最近因为有事，没有时间回复大家的意见，这些意见我也看过了，绝大部分是反对，而且反对的理由也很荒谬：“赋予编辑超1500次的非自动确认用户投票权”，标题也不知道被谁改成了“方案十四”。请问你们见过哪个新用户能在7天内编辑1500次（平均每天编辑214次），还能保证这1500个编辑全都是条目，而且恰好是投票前7天内作出的，而且全都是实质性编辑，没有一个破坏或测试？根据WP:最近编辑次数最多的用户统计，只有3个非机器人用户最近一周内编辑超过1500次，而且表中所有用户均为自动确认用户。大家可以自己找一下历史上有没有符合上述所有条件的用户，如果有的话可以在下面留言。假如真有这种用户，那么管理员难道不会以WP:游戏维基规则封禁之？希望大家认真思考这几个问题，当然也可以讨论，我先把上面的公示去掉，如果没有意见的话，我再公示。--12З4567（留言） 2022年2月25日 (五) 04:35 (UTC)

第三次推动设立LTA命名空间

由于今年LTA模仿犯泛滥，对本站站务造成困扰，我希望重提设立LTA命名空间，并通过引入扩展功能（mw:Extension:Lockdown）设置页面查看权限。

前期讨论

1. 部分用户认为不设置查看权限就没必要设置命名空间，有用户认为即使不设置查看权限也有必要设置命名空间。
2. 有用户认为，限缩查看权限不利于反破坏人员之养成、判定LTA，甚至沦为社群斗争工具。

设立流程

1. 社群讨论决定设立LTA空间。
2. 走mw:Writing an extension for deployment#Preparing for deployment的流程，同时社群讨论空间的细节。
3. 扩展功能可以启用后，通过phab:设立LTA空间，并设置查看权限。同时进行后续处理（如将LTA部分特征页面留在Wikipedia空间）。

以上，希望社群讨论。 ——魔琴 [ 已经告假 留言 贡献 ] 2021年12月31日 (五) 15:51 (UTC)

查看權限設置為回退員只能看，還是其他用戶組（巡查可能需要以掛板）為佳？問題就是LTA空間的內容一外漏影響就是永久的，很容易在網上流傳開去，需要再三考慮下。--Ghren🐦🕑 2021年12月31日 (五) 18:25 (UTC)

还不如把LTA页面移动到另一个wiki里面。--GZWDer（留言） 2022年1月1日 (六) 06:21 (UTC)

這樣說我覺得一些不宜公開討論的反破壞訊息可以全數移動到一個獨立的站點（Miraheze也好、wikimedia下的也好，都可以）--路西法人☆ 2022年1月1日 (六) 11:16 (UTC)

巡退、延伸确认、管。限缩得太紧的弊端已述。至于“LTA空间的内容一外漏影响就是永久的”，回退员也不一定可信啊……限缩主要是为了防模仿犯、反愉快犯，也防止LTA页面成为破坏者联络场所。-- ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月2日 (日) 05:23 (UTC)

不好意思，討論過長沒找到「弊端已述」。延確能否信任也是一個問題，但可以後議。--Ghren🐦🕙 2022年1月2日 (日) 14:42 (UTC)

@Ghrenghren：“不利于反破坏人员之养成、判定LTA，甚至沦为社群斗争工具”，完整版见Wikipedia:互助客栈/方针/存档/2021年8月#再次推动破坏者（LTA）成为名字空间中Kriz的留言。 ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月2日 (日) 15:06 (UTC)

請先確定Lockdown能夠確實引入，以免浪費大家時間來討論。--Xiplus#Talk 2022年1月3日 (一) 05:30 (UTC)

走引入流程可能需要社群共识：Your deployment tracking bug should point to on-wiki community consensus (and/or community support/desire) for having the extension installed on a particular wiki, if applicable. 所以这就是第一步“社群讨论决定设立LTA空间”，Ghren的提问其实是下一阶段的内容。 ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月3日 (一) 05:42 (UTC)

这不就死循环了吗？对LTA空间是否设立存在疑虑是因为不知道能否使用Lockdown扩展；若要知道能否使用Lockdown扩展，必须达成共识成立LTA空间；若要达成共识成立LTA空间，需要知道可以使用Lockdown扩展。这就是永远的死局了。 --Milky·Defer 2022年1月3日 (一) 07:36 (UTC)

所以我提议的流程是先达成启用的共识，如果可以启用再设置空间。 ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月3日 (一) 07:41 (UTC)

我覺得這是個死局。假如不能Lockdown其實沒什麼意義。姑且可以先支持，但假如Lockdown用不了就當時再移回去吧。--Ghren🐦🕓 2022年1月3日 (一) 08:42 (UTC)

所以唯一支持建立獨立的命名空間的理據是使用Lockdown嗎？那麼我不反對將設立命名空間跟引入Lockdown綁定討論，部署Lockdown跟新命名空間應同時進行，若最終Lockdown無法引入，建立命名空間直接作廢。--Xiplus#Talk 2022年1月3日 (一) 11:15 (UTC)

我的意思就是这个（不知道是不是表述不清楚），扩展功能可以启用后，通过phab:设立LTA空间。 ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月3日 (一) 12:10 (UTC)

• (！)意見：敝人路經此地，竊以為若暫且不論站友前述的專業技術工程，斗膽對所謂的LTA之存在和相關頁面表達個人看法。

先說結論，個人主張不限制閱覽權限，但進一步提高收錄門檻；若往後真限制閱覽權限，延伸確認以上權限之使用者可觀看。

首先，個人反對輕易增生所謂的LTA頁面。每每只因有無聊的反社會人士來搞破壞一段時間，社群就替他們「立傳」，竊以為未必具那麼大的迫切或必要性；個人認為大量建立LTA專屬頁面除了可能輕易幫那些破壞者樹立「戰績里程碑」之外，長久而言提供他們繼續追求「戰功和名望」之誘因，也替他們在維基世界和時間長河中留下「個人（可能值得紀念或回味）的歷史印記和足跡」，甚至恐成為有心人輕易反向濫用該頁面或散布特定資訊之良機。某些編輯行為究竟是否屬破壞，個人認為反破壞編者可自行依站內規範和經驗判斷；在破壞者「升級」成為LTA前，多數時候熱心用戶維護關注的目標以「條目」為主，應即可有效實踐反破壞之本意（若真有需要查緝傀儡帳號另當別論）。

其次，此類LTA頁面之使用方式分為編寫和閱覽兩個面向。就閱覽而言，個人仍認為應開放資訊供所有有心用戶閱覽揀用，原因如過往所述。然而就編寫而言，站內熱心站友常在發現有破壞者符合收錄門檻後，便熱心記錄描寫其特徵和行為，並建立相關頁面公示於眾；有時LTA的相關資訊情報甚為模糊，僅稍具輪廓雛形而已，又或是過多細節導致實難真正辨識，甚至套用於其他編者身上亦看似輕易符合，故個人認為可能需要進一步研擬限制措施。

因此，在概念上，個人主張採「無無虛無」（中二....）之策略，亦即「回退、封禁、不理會」之最大化延伸，盡可能削減破壞者戮力追求之名望、成就、意義、價值、榮譽感、存在感、個人風格等可供追求之心理反饋，故在記載上應提高登載收錄和訊息傳播門檻。

具體措施上，就登載收錄而言，個人建議維基百科:持續出沒的破壞者之情報頁面建立門檻為「持續破壞3個月以上，且編者提供之相關情報資訊經客棧討論公示通過」，方移置公開收錄於VIP室頁首。尤其對於有心藉由模仿或造謠等方式進行擾亂之破壞者而言，若經由少數人收集或判讀訊息、未經過濾便輕易建立可供收錄展示之「專屬頁面」、成為「維基館藏」，甚而因部分熱心關注者可能的誤判造成負面效果，竊以為實屬不妥。

就訊息傳播而言，敝人主張可考慮進一步將所有LTA按編號代碼予以編管，於「Wikipedia:持续出没的破坏者/<用户名>」創建情報頁面時改採流水號編碼，並以編碼建立相關重定向，以其編碼公示於VIP室，而原帳號名稱則記述於情報內文和資訊框，編碼方式和規律以可無限延伸、不具意義為基本概念，舉例如下：

1. 盡可能不依特定緣由或規律編號（如出現和破壞之時間、順序、編輯類型等規律或事由），於鄰近的號碼順序內，隨機進行編號。

2. 將英文字母和數字結合，持續延伸，列舉流水號樣式如下：

“ LTA：AA-0002 ～ LTA：AA-9998，

---> LTA：AB-0002 ～ LTA：AB-9998

---> LTA：AC-0002 ～ LTA：AC-9998.....

---> LTA：AZ-0002 ～ LTA：AZ-9998

---> LTA：BA-0002 ～ LTA：BA-9998

---> LTA：BB-0002 ～ LTA：BB-9998....

---> LTA：BZ-0002 ～ LTA：BZ-9998

---> LTA：CA-0002 ～ LTA：CA-9998..............

---> LTA：CZ-0002 ～ LTA：CZ-9998

---> LTA：ZA-0002 ～ LTA：ZA-9998..............

---> LTA：ZZ-0002 ～ LTA：ZZ-9998

---> LTA：AAA-0002 ～LTA：AAA-9998

---> LTA：AAB-0002 ～LTA：AAB-9998...........

---> LTA：AAZ-0002 ～LTA：AAZ-9998

---> LTA：ABA-0002............ ～.............LTA：ABZ-9998...........

---> LTA：ZZZ-0002 ～LTA：ZZZ-9998

---> LTA：AAAA-0002............

”

可無限延伸，若真有需要的一天（笑）。個人意見，供參。--Kriz Ju（留言） 2022年1月6日 (四) 02:24 (UTC)

我觉得，封闭LTA查看权限可能可以规避“冲战绩”的想法，毕竟自己看不到。至于阅览面向，我觉得给延伸确认就可以了。 ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月6日 (四) 04:31 (UTC)

別用流水帳，即使要DENY也不至於這樣，這樣太難記誰是誰了。--路西法人☆ 2022年1月11日 (二) 04:51 (UTC)

• (！)意見：敝人的用意就是要構成一種「雙向限制」的效果，不只限制LTA對外傳播個人「功績」，同時也提高社群對於相關訊息的資訊傳遞和討論門檻，甚至有時有心人正是藉此方式散布各種擾亂訊息。在此敝人斗膽挑戰一個概念：為何我們要記得或認識他們呢？「努力」破壞的人被社群「銘記在心、永恆流傳」，還可以成為被「登載史冊、正式收錄」的對象，反倒對社群有貢獻的善意用戶隨著逐漸淡出或離去，經過幾年後，又有多少人或新進用戶認識或記得他們曾經的貢獻呢？

這麼說起來，是否破壞者破壞一陣之後，即可名留青史？善意的貢獻用戶還不見得可以輕易留名，就證明自己的「存在感」而言，當今的社群機制是否反倒在鼓勵破壞者留名呢？

我們努力記住那些破壞者，卻放任社群遺忘曾經致力為社群貢獻的無名英雄，敢問這是什麼荒謬的現象或制度呢？

進一步而言，隨著時間過去，流水號越往後排越顯冗贅，而對於未來的LTA而言，他們公示於眾、留給世人的，就是這些他們自己也無法掌握、任人取名的「編號」，而不是他們要讓大家認識、甚至充滿個人風格、帶有個人色彩的「帳戶大名」。

竊以為就實務而言，既然提高資訊傳播門檻，加上若往後只有部分用戶具備閱覽權限，這表示只有真正願意投入研究的用戶，才能更熟悉這些訊息，亦即「反破壞」的相關資訊會進一步更接近為「帶有某種技術色彩」的站務，而不是只有「不會寫條目、不務正業」的用戶才會去玩的不入流把戲。

真正願意研究的人，肯定一段時間後就能辨識，尤其對於曝光率較高的那幾位遠古先生，不成大問題（比如有在投資的人就會了解，一段時間後對於投資標的代碼就可以如數家珍），甚至還可以提高用戶參與度和投入時間（事實上點進去頁面看一下即可，也不用硬記）；而無法辨識或閱覽資訊的人，是否願意投入反破壞行列，就看個人選擇了。--Kriz Ju（留言） 2022年1月12日 (三) 11:22 (UTC)

這樣只會造成反破壞工作更難進行。有名稱的作用是要可以立刻配出誰是誰，變成流水帳基本上沒人能辨識是哪一個破壞者。「事實上點進去頁面看一下即可，也不用硬記」但給出連結都成問題，怎樣點進去？辨識破壞者是必要的，我近期接觸大量LTA更感受到這一點，不然也不會提出改進破壞者辨認的SPI。--路西法人☆ 2022年1月13日 (四) 09:53 (UTC)

• 另外，考虑到 IP masking，我希望LTA空间对且仅对（未来）有权限查看IP地址的用户开放。 ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月8日 (六) 05:24 (UTC)

  對比開放予延伸確認用戶閱讀該命名空間，我更傾向魔琴提議僅開放予有權限查看IP地址的用戶閱讀有關頁面。--路西法人☆ 2022年1月9日 (日) 03:27 (UTC)

不知道是不是应该回复在这儿。这个扩展提供的限制非常鸡肋，您只需要在其他名字空间创建一个指向私有的LTA名字空间页面的重定向，再在另一个页面中嵌入前述重定向，即可浏览内容。--——ほしみ 2022年1月17日 (一) 15:59 (UTC)

注：调整 $wgNonincludableNamespaces 无法控制其他名字空间指向LTA名字空间的重定向之嵌入。--——ほしみ 2022年1月17日 (一) 16:04 (UTC)

啊这，您有去mw:Extension talk:Lockdown提过吗（ ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月17日 (一) 16:14 (UTC)

您可以自行测试后去提一下，我这边测试的结果是即使是master也没解决这个问题。这个问题就写在mw:Security_issues_with_authorization_extensions内，看Inclusion/transclusion一栏右侧评论栏的意思是部分解决了，那重定向嵌入可能没解决吧。只能说，这个扩展限制的read权限目前并不能阻止破坏者完全不能阅读。--——ほしみ 2022年1月17日 (一) 16:37 (UTC)

重定向问题可能可以通过AF解决？ ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月18日 (二) 03:58 (UTC)

AF没用的，单页面内预览就行了，甚至不需要创建页面。

例如Sandbox页面:

#重定向 [[LTA:Sandbox]]
{{:Sandbox}}

——ほしみ 2022年1月18日 (二) 04:29 (UTC)

Ghrenghren在站外提到可以“在所有LTApage 上加上個空白的onlyinclude”。 ——魔琴 [ 留言 贡献 ] 2022年1月19日 (三) 15:42 (UTC)

已確認，已報告。--Xiplus#Talk 2022年1月17日 (一) 16:36 (UTC)

另外，一般用户仍然可以在最近更改、最新页面、用户贡献等特殊页面看到私有名字空间内每一笔编辑的摘要，包括创建页面时自动生成的摘要。--——ほしみ 2022年1月17日 (一) 16:45 (UTC)

---

上述讨论中LTA收录门槛的讨论与本案无关，将分拆讨论。距离Kriz君在我的讨论页表示支持已过去七日，现拟出决议并 交付公示，为期7日，2022年1月24日 (一) 04:19 (UTC) 結束。

本社群达成共识：

一、本站将设立临时代号为“LTA”的命名空间，用于储存长期破坏的信息以反破坏，其它细节待议。

二、本站将申请部署mw:Extension:Lockdown以限制LTA命名空间的阅览权限。

三、LTA命名空间仅应在mw:Extension:Lockdown可以部署后设立。

 ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月17日 (一) 04:19 (UTC)

最好不要再像修訂巡查那樣擱淺。—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年1月17日 (一) 07:27 (UTC)

• 已經擱淺了。修訂巡查也是技術人員說「欲申請的擴展不會在任何維基媒體站點部屬」。本次議案也是技術人員說「欲申請的擴展不會在任何維基媒體站點部屬」。。。 囧rz……-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年1月22日 (六) 03:47 (UTC)

上面的說的在理，我們還要搞嗎 囧rz……--Ghren🐦🕗 2022年1月18日 (二) 00:10 (UTC)

唉，又是一次浪費社群時間的討論。—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年1月18日 (二) 00:33 (UTC)

单独设立空间本缺乏意义，但本案提及限制阅览权限的问题，其论述有说服力，故支持本案。但

1. 本案之二仍需明确，具有阅览权限的用户范围，该范围不易太窄。有用户提出以延伸确认为界，考虑到反破坏一般至少是具备一定经验的用户，我认为是适宜的。
2. 若能着手明确本案之二、三技术上是否确实可行，则更为稳妥。

以上。--Kirk # 2022年1月18日 (二) 04:15 (UTC)

现在讨论这个大概真是浪费社群时间……但是考虑到 IP masking, 我希望LTA空间对且仅对（未来）有权限查看IP地址的用户开放，而延伸确认肯定不是这种用户组。 ——魔琴 [ 留言 贡献 ] 2022年1月18日 (二) 10:41 (UTC)

---

撤下公示。 ——魔琴 [ 留言 贡献 ] 2022年1月19日 (三) 12:17 (UTC)

（对本讨论串整体的意见）在过去的反破坏工作中，我有九成把握可以说，能查阅私有过滤器者（回退员、管理员）中有人向外泄漏私有过滤器内容。所以不要对“限制阅读权限对保密有好处”抱有任何希望。谨此提醒参与本讨论的编者。至于防模仿、愉快犯的作用几何，我对此基本没有实感。--Tiger（留言） 2022年1月19日 (三) 13:21 (UTC)

我有一个限制阅读权限的另一个理由：IP masking 实施之后，普通用户组不能直接查看未登录用户的IP，而有权限查看的用户也不能向无权限的用户提供这个信息，而反破坏中IP也是很重要的，只能放在私密的命名空间里了（即使保密性存疑）。 ——魔琴 [ 留言 贡献 ] 2022年1月19日 (三) 13:58 (UTC)

這不是只有本地會遇到，而是所有wiki都會遇到，沒有必要本地硬想出方法（尤其還是個爛方法），參考其他wiki的作法也是可以的。--Xiplus#Talk 2022年1月26日 (三) 06:58 (UTC)

至于能查阅私有过滤器者（回退员、管理员）中有人向外泄漏私有过滤器内容，嗯，看起来不是什么新闻。 ——魔琴 [ 留言 贡献 ] 2022年1月19日 (三) 16:02 (UTC)

设立新维基

於Phabricator查看
編號T299546的工單
狀態：已拒絕

GZWDer在phab提出了相关task后，User:Martin Urbanec表示，因为MediaWiki的阅读限制很可能被绕过，“几乎可以肯定Lockdown不会在任何维基媒体维基安装”。他建议可以参考意大利语维基百科申请建立的https://sysop-it.wikipedia.org，可能更适合本站的需求。

於Phabricator查看
編號T299590的工單

GZWDer于是提出了Create zhltawiki 的task作为替代。有两种方案：一是传统私密维基，不连接SUL，符合要求的用户可以通过一个Toolfridge工具自动创建帐号；一是Miraheze式的私密维基，连接SUL列入“member”用户组的用户有权限查看私密内容。

User:Majavah表示CentralAuth并不支持Miraheze式方案。

现交付社群讨论是否建立LTA维基，以及其具体实现方式。 ——魔琴 [ 留言 贡献 ] 2022年1月21日 (五) 16:10 (UTC)

建议CentralAuth，但由BOT进行在主站有相应权限的用户的权限同步，把read给一个额外的用户组。--Wiki emoji | 😷🅔🅜🅞🅙🅘🅦🅘🅚🅘😷 _{祝百毒不侵～} 2022年1月21日 (五) 22:23 (UTC)

IP masking 實施之後，LTA WIKI（或Lockdown，但不可行）成为了宪制性必须存在的实体，故(＋)支持。--Wiki emoji | 😷🅔🅜🅞🅙🅘🅦🅘🅚🅘😷 _{祝百毒不侵～} 2022年1月21日 (五) 22:31 (UTC)

我覺得沒什麼必要。Tigerzeng閣下說的也挺明白了。—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年1月22日 (六) 02:08 (UTC)

(✓&)有条件同意：建立一个新维基就设立的通用一点，延伸确认用户维基，所有延伸确认用户可见，或站务维基（行政员、管理员、巡查员、回退员、经申请可查看者）。桐生ここ★[讨论] 2022年1月22日 (六) 02:40 (UTC)

我觉得可以（站务维基），而且我突然想到，编辑sysop-it的都是sysop，那么编辑zh-lta的就都是     ——魔琴 [ 留言 贡献 ] 2022年1月22日 (六) 15:53 (UTC)

有條件支持：私以为除非对查看者进行严格限制（如wiki查看权应使用类似于巡查回退的申请方法），否则LTAWiki的设立并无太大意义。—Regards, BureibuNeko 2022年1月22日 (六) 06:15 (UTC)

既然有管理員內鬼，這條路恐怕不通。--Temp3600（留言） 2022年1月22日 (六) 09:04 (UTC)

說起來，還有防濫用過濾器這條路可以硬塞LTA資訊的，不過有可能影響過濾器效率（--1233 （T / C） 2022年1月23日 (日) 03:27 (UTC)

(＋)支持，但是可访问用户的选择可能需要在延展用户的基础上增加一些特殊的限制，如规定最低Wikipedia名字空间编辑数。--Yining Chen（留言|签名页） 2022年1月23日 (日) 14:05 (UTC)

没意见。--三万光年 _GBAW 2022年1月25日 (二) 12:04 (UTC)

(＋)傾向支持,只要访问限制得当，就没有问题。--在下荷花，请多指教（欢迎签到） 2022年1月26日 (三) 04:09 (UTC)

應該先確定持權條件再來設立新維基，另外反對任何能夠自動獲權的門檻制，應採用申請制，不然洩漏內容的話不僅隱藏內容無用，反而將資料保存在獨立的wiki上，徒增麻煩而已。--Xiplus#Talk 2022年1月26日 (三) 06:56 (UTC)

(＋)支持，但(－)傾向反對CentralAuth的方案，我支持xiplus的申请制，并且我认为该wiki不应该搭建在wikipedia.org空间，而是自行在Toolforge上搭建，账号系统与基金会的CentralAuth完全分开。--忒有钱🌊塩水あります🐳（留言） 2022年2月3日 (四) 18:41 (UTC)

(～)補充：关于申请制，我认为应设立如下门槛：

1. 关于阅读权限，我认为至少是延伸确认用户才可申请；
2. 关于编辑权限，我认为必须是傀儡调查助理、用户查核员（若有本地查核权）/监管员（若无本地查核权）、管理员、行政员、监督员才可申请。

以上。--忒有钱🌊塩水あります🐳（留言） 2022年2月19日 (六) 13:50 (UTC)

wikipedia.org空間、Toolforge、CentralAuth其實是三件不相干的事情...沒有因果關係。--Xiplus#Talk 2022年2月19日 (六) 14:40 (UTC)

有條件支持：支持提案，但認同Xiplus君所言應優先決定持權條件再設立。另外能不能不要叫「LTA維基」 囧rz……--路西法人☆ 2022年2月9日 (三) 07:24 (UTC)

看起来就“设立”本身有了初步共识，可以进一步往下进行讨论。顺便一提关于IP masking方面的事项似乎现在处于停滞状态（原计划是在1月17日给出一个方案的），是否需要在此方面等待一下？如果那边有了推进（比如那边似乎是说要成立一个新的用户组可以看部分masked的IP），可以参考那边的组的门槛。 Stang^★ 2022年2月16日 (三) 20:25 (UTC)

就安全投票問題訂立管理員選舉暫行規定

社群日前進行投票表決通過，決定「在未來一場管理員選舉使用安全投票（SecurePoll）」。考慮到選舉提名與安全投票開啟之間具有時差，現請社群就選舉日程，包括討論期間、投票期間等面向訂立暫行規定，優先於既有之申請成為管理人員指引。—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年1月5日 (三) 14:18 (UTC)

我這裏寫個草案吧。考慮到農曆新年和動員令社群會比較忙，本次算是一次比較大型的選舉，選舉宜在二月下旬至七月進行。考慮到目前的站務積壓，目前應該以管理員數量為首要目的，畢竟最積極的蟲蟲飛消失了，其他WP:OA2021中被除權的9位也有相當的貢獻，理論上先提名曾任管理的用戶比較容易得到共識。而針對Spoll的數目而言，我個人認為一次應該避免超過5個以避免影響社群同時要關注過多的投票。因此大致草案如下：

2月15日-2月22日：曾任管理員者可以優先被提名。超出5個則暫時凍結。

2月22日起：假如提名者不足5個一般合Rfa要求者也可以參與。

2月22日-3月22日：對候選人作出提問，社群討論候選人是否合適。

3月22日至3月29日：開啟Spoll讓社群進行投票。（兩週或者提前開啟也可，另議。）

3月29日後：行政員再按投票結果得出結論。同時再考慮準備下一回的投票。4月至7月其間可以再進行另一場Rfa。

此外，也有其他問題，以此Securepoll而言，延長投票似乎不太實際。而且中立的票也難作考慮。故此可能要設立一個比較固定的標准，按以往近80%則延長投票的做法較難實行。--Ghren🐦🕐 2022年1月5日 (三) 17:55 (UTC)

此外一票兩投IA也是個問題。以往可以用文字說明支持IA但不支時Admin，但SPoll不能做到這點。--Ghren🐦🕐 2022年1月5日 (三) 17:57 (UTC)

這樣的話能不能分開spoll？有意願選介面的話多開一個，分開兩邊投。--AT 2022年1月5日 (三) 18:20 (UTC)

這很簡單，若當事人要選介面管理員，增設一問題即可。 —— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年1月5日 (三) 18:31 (UTC)

見下。—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年1月6日 (四) 07:22 (UTC)

RfA已经不能兼RfIA了吧 ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月6日 (四) 04:01 (UTC)

請注意投票結果是「未來一場」。多於一人參與會面臨要適用安全投票抑或一般投票方式的問題，且可能超出社群投票效力之範圍。故此僅建議以一人參與的情況來決定日程，這裡指的不是絕對的行事曆，而是相對的日數。之所以不直接決定往後採用，就是因為需要觀察。其實當初投票應該不要寫未來一場，而是寫「未來半年」之類的或許比較彈性一點呀。—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年1月5日 (三) 18:28 (UTC)

作為參考，目前的管理員選舉，討論與投票並行，為期共十四日。在尊重既有制度、不改變實際選舉時長的情況下，個人有三種方案：

1. 提名後立即開啟討論，為期七日，期間趕緊籌備安全投票，七日後開放投票，為期七日，總時長仍為十四日；（討七，投七）
2. 提名後立即開啟討論，期間趕緊籌備安全投票，七日後開放投票，但同時允許繼續討論，總時長仍為十四日；（討七，討／投七）
3. 提名後立即開始籌備安全投票，期間不得進行任何討論；安全投票開放後，同時開放討論，二者並行，為期共十四日。（討／投十四）

以上，請斟酌。—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年1月5日 (三) 18:36 (UTC)

籌備安全投票本身大概需時多久？--AT 2022年1月5日 (三) 18:38 (UTC)

或許@1233會清楚？—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年1月5日 (三) 18:45 (UTC)

我认为提名期和投票期搞得太紧安全投票会过于难安排。提名后不得讨论也过于高估社群的自制力。我认为投票期延长为妙。上次实际上也是延期了一周左右。当然事前预备好不是不行。但我认为安全投票的制度当初就有建议一年两场之类的意思，单纯选一个管理出来似乎效率有点低，总不行一年只出两个管理。--Ghren🐦🕗 2022年1月6日 (四) 00:20 (UTC)

七天搞起一個Spoll只怕也太難了，單是整理一份當時有人事任免資格的名單也已經用時甚久。假如共識認為一年兩場Spoll是比較合理的，日後的方案理論上應該往這個方案走，雖然這個共識沒有約束力。單問個人而言我認為第一屆還是合併數人舉行為好，但是作為第一次投票作為實驗性質也可以。--Ghren🐦🕗 2022年1月6日 (四) 00:46 (UTC)

那麼就是當初投票問題設計得不好了。為避免爭議，下一次選舉最好還是僅推舉一人。—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年1月6日 (四) 07:22 (UTC)

@Ericliu1912，這東西其實是沒有任何的標準的，但是細節是可以討論的。

我認為提名後就要籌備安全投票。期間應該是可以討論的。（禁止討論其實不切實際）。

反而投票的期間則應該仍然固定為十四天，而討論則可以在開始前繼續。另外，我認同一次選舉可以牽涉不同的人選，而不需要像現在那樣，一次選舉能投票給一位候選人。（可能是投票給兩至三位候選人）。

然後「整理一份當時有人事任免資格的名單」的問題其實不難解決，可以使用python或php等不同的方式整理就可，就像是這次的投票。而且該段code理應是可以重用的。--1233 （T / C） 2022年1月6日 (四) 03:24 (UTC)

遇上聖誕假期或是跟其他wiki投票衝突搞不好要推遲超過14天。--Xiplus#Talk 2022年1月17日 (一) 13:53 (UTC)

窩都可以，三個方案看要哪個社群決定好就好，不要又在那這不行那也不行。--~~Sid~~ 2022年1月14日 (五) 15:52 (UTC)

如果社群認同投票不能代替討論的話，應強制討論開始一段時間後才開始投票，讓大家都能透過討論更加認識候選人。--Xiplus#Talk 2022年1月17日 (一) 13:57 (UTC)

• Special:Diff/69512366#關於SecurePoll的一個緊急問題。 ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月7日 (五) 13:01 (UTC)

  實在是多難之秋。--Ghren🐦🕐 2022年1月7日 (五) 17:04 (UTC)

• 支持讨七，讨／投七方案，由于这次选举是使用SecurePoll的第一次有效力的选举，且使用的是临时方针，建议仅提名一人，这样可以不用对现行选举方针进行大幅改动，使社群容易适应。等将来决定长期使用SecurePoll选举后，可考虑同时提名多人的制度。——BlackShadowG（留言） 2022年1月9日 (日) 07:29 (UTC)

• 可以這樣呀。（或者管理員選舉可以嘗試改為2022年第一次管理員選舉？）--1233 （T / C） 2022年1月11日 (二) 20:23 (UTC)

同意。禁止讨论怎么看怎么不现实。 ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月14日 (五) 15:57 (UTC)

• 再來多一點腦震盪：未來一場，其實就大致上可以一票多投（例如可以修改為2022年第一次投票，然後就連往不同需要投票的議題（例如兩位參選管理員的用戶的問答頁），甚至可以包含其他選舉（例如基金會說的那個什麼查核員選舉）。我認為，根據這個投票的準備時間，一票多投是最好的方案。（至於其他公共議題還是先討論後明票吧）。1233 （T / C） 2022年1月14日 (五) 15:56 (UTC)

  個人不太同意任意擴大解釋。最好還是謹慎一點。—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年1月14日 (五) 19:00 (UTC)

  我覺得第一次的話真的是一個人又有什麼所謂，但是要確保Spoll的日程確實能定出來比較好，以安排技術上的問題。此外CU是兩週的話，Admin也是兩週為當。--Ghren🐦🕑 2022年1月15日 (六) 06:26 (UTC)

  如果要搞SecurePoll的話，其實最好是有一個Call for nominations的辦法，但是如果只是一位用戶參選管理員的話，那樣其實並不需要日程。--1233 （T / C） 2022年1月17日 (一) 07:09 (UTC)

  假如是一個人的話，解決了對面消息的技術問題就可以開始？但是一個人的話要投多少天？投票日期和被提名的日期要中間要差多少以安排技術問題？我記得試的時候是延了期的。--Ghren🐦🕕 2022年1月17日 (一) 10:38 (UTC)

  延期的原因是和其他投票有衝突的日期。現在來看，在短時間內是不會有這個問題的。--1233 （T / C） 2022年1月27日 (四) 13:36 (UTC)

• 有一个关于流程的问题，启用SP后，是要继续延续现在的“边投票边提问”还是要“先提问再投票”？等待SP部署时是否能提问？--Yichen Ding（留言|主账户） 2022年1月22日 (六) 14:53 (UTC)

  @Yichen Ding：「討／投十四」是完全的邊投票邊提問，「討七，投七」是完全的先提問再投票。「討七，討／投七」則是二者之間的折衷。—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年1月24日 (一) 13:20 (UTC)

  @AT@Ericliu1912@Yining Chen@魔琴@Xiplus：暫時是2人支持14天（我和1233），1人支持討七，討／投七方案（BlackShadowG），其他人有沒有其他意見？--Ghren🐦🕘 2022年1月28日 (五) 13:03 (UTC)

  支持討／投十四。--AT 2022年1月28日 (五) 13:10 (UTC)

  要不要关于这件事开一个投票讨论 --Yining Chen（留言|签名页） 2022年1月29日 (六) 07:25 (UTC)

• 如果已经决定下一次RFA要用SP，现在是否应该尽快得出一个（至少是临时的）方案？（毕竟这两年只有一个新管理员上任，还面临着上面提到过的问题，或许需要尽快处理好这件事然后尽快举行新的RFA 囧rz……） --Yining Chen（留言|签名页） 2022年2月2日 (三) 02:35 (UTC)

  再過幾天沒人提案，就把上面幾個選項拿去表決了。—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年2月2日 (三) 07:39 (UTC)

不如直接邀請他人他人提名/推薦，然後同時搞管理員/用戶查核員的SecurePoll，然後提名7天，討論7天/投票14天？（提名和投票期需要大約三天以準備投票人列表及問題），然後主頁面為WP:投票/2022年第一次安全投票。--1233 （T / C） 2022年2月2日 (三) 08:10 (UTC)

2022年社群願望清單調查中與此案相關之願望，大家可以去看看。—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年2月2日 (三) 15:17 (UTC)

---

現在的最大問題在於我們無法預期安全投票籌備要多久。—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年2月10日 (四) 11:25 (UTC)

所以我才提議預先指定一個提名日子，籌備安全投票的時間有太大風險。指定了就能解決所有問題。--Ghren🐦🕖 2022年2月10日 (四) 11:41 (UTC)

不就是嗎，而且還可以順便在同一時間搞CU的選舉--1233 （T / C） 2022年2月11日 (五) 13:53 (UTC)

根據他站社群（英維及波斯語維基百科）在去年於監管員佈告版請求監票之情況，他們在投票開始前（並非提名期開始前）大約一個月，已作出相關請求，可推斷開始投票前一個月便需作籌備。再者他們的選舉為定期進行，故如非定期進行可能需時更多。另可參考波斯語維基百科過往的籌備時間表。謝謝。--SCP-0000（留言） 2022年2月11日 (五) 14:54 (UTC)

---

抱歉，但目前這個議案己經放置在這一個月有餘但討論依然不足，我唯有按波斯語維基百科過往的籌備時間表，再加上上方的一些共識寫一個流程寫出來：

• D-Day：提名開始
• D+3：候選人如不合條件則重新開始
• D+7：選舉設置（導入名單、votewiki改為中文）
• D+10：投票期（發垃圾信息）
• D+24：投票結束（改回其他語言、點票）

此外尚有數點：

• 本次投票以一人為限，以最先得到提名而且合符投票過程要求者的優先進行選舉，其他的押後至下一次；
• 候選人應清楚說明是否參選界面管理員，如需要選票上應該另有一列；
• 選舉的關鍵日期應該預先決定以方便安排投票。

大概是這樣。Ghren🐦🕖 2022年2月14日 (一) 11:32 (UTC)

RfA已经不能兼RfIA，其余支持。 ——魔琴 [ 留言 贡献 ] 2022年2月14日 (一) 13:10 (UTC)

已經準備好投票頁面，細節待填。—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年2月14日 (一) 15:04 (UTC)

@Ericliu1912：現在依然以提出問題為宜。假如基金會對CU的要求是14天投票，其實管理另外再以七天制並不好。假如擔心過長的投票期使提名人辛苦的話可以另設冷靜期。Ghren🐦🕐 2022年2月15日 (二) 05:20 (UTC)

問題是基金會上次發了那則訊息以後就一點影子都沒有，不知道他們要做什麼。—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年2月15日 (二) 06:30 (UTC)

基金會是積極不干預政策吧？但是本身Rfa其實本身都沒有太多細節可以安排吧。--Ghren🐦🕒 2022年2月15日 (二) 07:19 (UTC)

安全投票的話，要不要發通知應該是最緊要的？除此之外要投票投幾天，支持率要多少，也要斟酌。—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年2月18日 (五) 06:37 (UTC)

支持率按慣例是80%。通知按其他維基做法只要公平即可，但是只為一個維基人選舉的發通知有些少拉票的感覺。投票似乎共識為14天。--Ghren🐦🕛 2022年2月18日 (五) 16:28 (UTC)

• 順帶一說，建議提早完結發問期，讓參選者在最後一天有足夠時間回答問題。--Temp3600（留言） 2022年2月22日 (二) 14:00 (UTC)

  這樣的話將發問期可能規定在20天，然後參選者可以慢慢答就好了。或者再縮短點也可以。--Ghren🐦🕗 2022年2月24日 (四) 12:32 (UTC)

---

那暫定提問期為21日，留三日讓候選人回答？—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年2月24日 (四) 13:05 (UTC)

21天會不會過長了？我擔心累死候選人了。我沒什麼所謂，畢竟回答與不是候選人的自由。--Ghren🐦🕘 2022年2月24日 (四) 13:14 (UTC)

@BlackShadowG@SCP-2000@Ericliu1912@Temp3600@AT。對於提問日數有什麼看法？--Ghren🐦🕐 2022年2月25日 (五) 05:40 (UTC)

那再縮短總時程，同時削減討論與提問時間？我記得之前不少人支持三週方案之類的。—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年2月25日 (五) 10:49 (UTC)

我認為太長，14天投票+討論就好。--AT 2022年2月26日 (六) 05:38 (UTC)

這樣？—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年2月26日 (六) 06:58 (UTC)

對。--AT 2022年2月26日 (六) 08:20 (UTC)

慢著，提問期可以再縮短些，投票期再延長點。例如5+10。--AT 2022年2月26日 (六) 08:21 (UTC)

這裡或許應該定義一下「提問」。在既有問題「之上」追問是否算是提問？如果追問也算是提問，那提問期可能要拉長一點。—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年2月26日 (六) 09:24 (UTC)

為什麼要減少投票時間？這樣的話又會有人投訴為什麼不延長投票時間之類的話了，而且和CU和其他站的習慣也不一致，我看不到有很大動機去做。--Ghren🐦🕓 2022年2月26日 (六) 09:55 (UTC)

那要視乎什麼時候回答提問。另外，不能提問和投票均同時是14天嗎？--AT 2022年2月26日 (六) 10:24 (UTC)

將圖2的版本改成14天就可以達成你的需要吧。--Ghren🐦🕖 2022年2月26日 (六) 11:05 (UTC)

另外我記得1233不知道在那個tg群說只少要一周的時間，不能再縮了。--Ghren🐦🕖 2022年2月26日 (六) 11:12 (UTC)

這是在臨時提出來的情況下吧，不是說要選定一段期間舉行選舉了嗎？—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年2月26日 (六) 11:46 (UTC)

我不敢肯定，但是時間越長總是越好的。@1233--Ghren🐦🕘 2022年2月26日 (六) 13:05 (UTC)

如果不選定一段時間舉行選舉，以上全部方案都難以確保能夠施行。我自己也擬過一堆方案，想了半天，還是跨不過這個坎。—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年2月26日 (六) 16:25 (UTC)

這樣的話其實現在就可以去監管員佈告板找人了。反正有個固定日期定了出來，之後到D Day的時候填個人名就可以了。投票開始和投票討論時間其實不會差得很遠吧。--Ghren🐦🕛 2022年2月26日 (六) 16:45 (UTC)

我呼吁社群关注限制RfA提问的提案，否则提问时间的制定总会在「不能及时知道」和「候选人负担太重」之间弹来弹去。 ——魔琴 [ 留言 贡献 ] 2022年2月26日 (六) 15:25 (UTC)

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

提议明确Wikipedia:格式手册/旗帜

一、Wikipedia:格式手册/旗帜#旗幟圖案不用於强调国籍目的和Wikipedia:格式手册/旗帜#有利于读者閱讀，而非装饰用途的规定对信息框是否有效。目前普遍存在信息框国家用国旗（甚至连清朝都有旗帜），党派用党旗（比如驴象代表民主共和两党），美国总统前面要加个，还有各种军衔、将星，电影产地要加{{美国电影}}{{英国电影}}{{日本电影}}；

二、上面举的例子如、军衔、{{美国电影}}{{英国电影}}{{日本电影}}这些是否应该视为旗帷，因为有用户明确主张美国是国旗模板，但美國不是国旗模板，

三、个人认为如果确定国旗可以在信息框使用，宗教旗帜、州旗、市旗、家族盾徽、党旗、军衔、国玺都没有理由限制，那么Wikipedia:格式手册/旗帜#不要使用太多的旗帜如何裁量，多少算“太多”？

我个人立场认为应该对信息框使用旗帜设限，除非能证明加个旗帜不止“装饰用途”，不会起“强调国籍”的效果，否则就不应该加。汉语读者不可能看到“国籍：美国”后不知道是美国，要看到“国籍：美国”才知道，读者也不会看到“民主党”不知道是民主党，要在前面加头动物才知道。电影“产地：美国”自然就说明是美国电影，“产地：美國”除了装饰、转移读者注意力实在想不出还有什么作用。--7（留言） 2022年1月11日 (二) 09:22 (UTC)

• 维基百科:格式手册/旗帜/英文维基百科版本可供参考，英文版是几乎完全禁止旗帜的使用，但这部分在中维没有通过。——BlackShadowG（留言） 2022年1月11日 (二) 11:19 (UTC)

我建议内链链接的不是国家的（如“美國”）就不要留旗帜了。 ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月11日 (二) 12:33 (UTC)

美國總統那個真的過分了，還妥妥的地域中心。—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年1月11日 (二) 13:39 (UTC)

@BlackShadowG：中文版Wikipedia:格式手册/旗帜采用了英维指引的理论；而按英文维基的理论，自然会导出Wikipedia:格式手册/旗帜/英文维基百科版本中的具体做法。中维把具体规则砍掉，但又不拿出其他理论，可不就碰到Po主说的问题了。

我的建议是旗帜表达额外意义，且有利于排版时，可以考虑加入——

• 比如“ 莫·法拉赫”表示“代表英国队参赛的莫·法拉赫”，“ 喬治·克列孟梭”表示“代表法国参战的喬治·克列孟梭”。而且相对于地区名称参差不齐，战争等信息框罗列多个项目时，使用旗帜的确更美观且避免过长换行。（想象一下World War I infobox，下方“指挥官与领导者”处将旗帜替换为汉字，这样就能看出旗帜的优点）
• 但是一般的公司/人物信息框，所有栏目全是文字，偏偏地区这个信息搞特殊非要加图像。而且公司地理位置坐落于美国，不表示公司代表美国开的。这种我认为是属于滥用旗帜了。

以上看法和Wikipedia:格式手册/旗帜/英文维基百科版本相同。我也认为Wikipedia:格式手册/旗帜/英文维基百科版本至少 字面上符合中文版指引Wikipedia:格式手册/旗帜的精神。当然，我知道“人物/公司信息框禁止加旗帜”的做法不符合目前惯例。但这是因为加图标真的利大于弊，还是纯粹尊重现实，这点还是希望能有明确说明。--洛普利寧 2022年1月11日 (二) 13:46 (UTC)

我认为加图标利大于弊，不过明确了地区的列表条目，如美国总统列表，可考虑限制。--驻军（留言） 2022年1月15日 (六) 04:32 (UTC)

@驻军：中文维基的WP:FLAG基本是参考英文维基制定的。同样的理论，英文维基的解读结果是弊大于利。所以中文维基如果认为利大于弊，是有其他理论，还是同一理论有相异的解读方式？--洛普利寧 2022年1月15日 (六) 15:03 (UTC)

英维没有{{美国电影}}{{法國電影}}这些电影产地模板，难道中维就一定要等同英维，拿掉电影产地模板？——驻军（留言） 2022年1月15日 (六) 04:32 (UTC)

@Jarodalien：我认为，在infobox中的“产地”“国籍”中，使用{{美国}}，应当被允许。但是在“产地”中使用{{美国电影产地}}，便不应当了，效果完全与国家模板相同。

关于何种内容属于滥用旗帜，我的观点如下。1.正文中不应当有旗帜：吸引读者注意力，有失中立。2.表格（包括信息框）可以有旗帜，只要不影响排版：上面那个美国总统，肯定得缩小点用，不然一是不美观，二是有失中立。

同时，旗帜内容、显示文本和内链应当一致，不能出现 清朝。

@Lopullinen：对于您“代表英国队参赛的莫·法拉赫”的用法，我不敢苟同。请问如果我打上“Christian Kouamé”，而且不给内链，请问读者能辨识出来吗？（Wikipedia:格式手册/旗帜#与国家名称一同使用）不要去查了，是科特迪瓦。我认为您提到的情况，应当另开一栏表国籍。而在旗帜上加内链的做法，对于触屏、打印都不友好，不建议这样做。

而您所询问的“所有栏目全是文字，偏偏地区这个信息搞特殊非要加图像”，翻了一下存档（Wikipedia_talk:格式手册/旗帜#調適案A），发现似乎是因为历来讨论均未得出共识，于是提案为正式指引时删去了相关内容，于是编者就按照惯例执行了。--落花有意12138 _{论 回复请ping我} 2022年1月17日 (一) 07:40 (UTC)

@落花有意12138：我的意思就是在Wikipedia:格式手册/旗帜#与国家名称一同使用的前提下，使用 Christian Kouamé。

倒是一般infobox中的“产地”“国籍”中或类似信息（比如上村雅之的两个旗帜），我认为没什么必要。我在上面说了旗帜的两个作用，表达意义和有利排版，但这条目并不具备。一方面如您所说，读者根据文字而非旗帜判断地区，此处旗帜没用表达意义的功能。另一方面，这些条目不需要用图示代替文字排版；反而是两个图标让信息框更加突兀（我认为他就职于任天堂的信息更加重要，总不能在「任天堂統合開發本部顧問」前面加任天堂的Logo吧）。--洛普利寧 2022年1月17日 (一) 07:56 (UTC)

@Lopullinen：1.我坚持对于不常有人认识的旗帜，距名称和旗帜同时出现的地方相隔较远使用时，恒带名称（此处“相隔较远”指的是5行以上）。真的有人会把整个大表格看完，并记得每个提到的旗帜的意义吗？对于那种需要折叠或者单立页面的大表格，用处似乎只是在需要时查询特定的一行或者列，甚至一个单元格，此时仅仅给出旗帜，让读者自己去找，就不方便了。--落花有意12138 _{论 回复请ping我} 2022年1月17日 (一) 08:11 (UTC)

@落花有意12138我的意思是，像国际运动会比赛、战役一类的条目，人物是代表地区的。比如在统计奖牌时，你要注明运动员代表科特迪瓦，而不是扔个名字上去。

直接用文字不好看：

• （科特迪瓦）Christian Kouamé
• （美国）XXXXXXXXXXX
• （特立尼达和多巴哥）YYYYYYYYYYYYYYY
• ……

所以用图标代替文字排版（这里的图标有表意作用）：

• Christian Kouamé
• XXXXXXXXXXX
• YYYYYYYYYYYYYYY
• ……

而图示需要图例，也就是之前图标要和文字出现一次：

• 科特迪瓦
• 美国
• 特立尼达和多巴哥
• ……

此处图标和文字并列，主要意义是图例而非表意（总不能说美国代表美国）。如果上面不用图标，这里也不用加。

虽然指引总基调是不鼓励图标，但上面例子都是连续一串图标+文字，有对齐名字的优势，这就有让使用图标有了豁免理由。当然，我不是说必须用图标，全换成文字也没有问题。

Template:World War I infobox是把大量图标集体压到最底下的，这种也OK。但人物信息框其他栏目大串文字，偏偏一两个图标刷存在感，而且还说不出要用的理由——这种才是问题。--洛普利寧 2022年1月17日 (一) 08:37 (UTC)

@Lopullinen：1.您说的有道理，但是在我上述的使用场景中，读者会知道这个图例在哪里吗？如果可以订立规范，使之更加明显、易找，最好放在表格开头，单立标题，就好了。

2.我同意您的观点，大片文字夹带少数图标，有失中立。但考虑到历来讨论均未有结果，如果阁下想要写入指引，请另起讨论。

另：您对此发言的讨论我将在今晚8点以后或者明天回复——落花有意12138 _{论 回复请ping我} 2022年1月17日 (一) 08:50 (UTC)

WP:FLAG是参考英维制定的，除非社群明确表示否决，否则自然会解读出和英维一样，不鼓励使用图标的结论。体育类条目使用图标，是因为找到了其他的理由。一般信息框如果不找出理由，就会不断有人提出和Po主一样，援引现行WP:FLAG提出问题。这是我想说明的。实际上这不是个例，中维不少方针指引都是从英维引入，然后切掉一块又不提出新的理念，结果造成方针理念和实际执行冲突情况。

至于您说的第一点。我的重点是想说图标要有表示意义的作用，而不是和美国一样重复说话。奥运类条目有个模板，效果大概是「 YYYYYYYYYYYYYYY（特立尼达和多巴哥）」，这应该能兼顾图标和文字的平衡。当然，我不编辑体育和战争类条目，具体方式由相关领域编辑确定比较好。--洛普利寧 2022年1月17日 (一) 09:06 (UTC)

战争条目的惯例（至少在英文维基百科）是，在信息框的“参战方”一栏同时列出国名和国旗，随后的“指挥官与领导者”和“兵力”一般只使用国旗。--BlackShadowG（留言） 2022年1月17日 (一) 13:09 (UTC)

@Lopullinen：1.同一提案6个月只讨论一次，加入常年提案定期讨论也可以。方针和指引的通过须要社群有明确共识，因此争议话题不应当被通过。而未通过的提案只要未有禁止，便可以如此做。

2.哪请问如何判定那些旗帜需要和名字一并出现呢？--落花有意12138 _{论 回复请ping我} 2022年1月18日 (二) 14:32 (UTC)

@落花有意12138：我的意思是使用旗帜必须要有理由。谁要在某些地方使用旗帜（和名字一起出现），就请他自行解释亮出旗帜理由。举不出图示使用理由的全禁掉我没有意见。--洛普利寧 2022年1月19日 (三) 12:36 (UTC)

@Lopullinen：方针应当规定至少2种的合法情况，然后根据常识允许合理性等同的情况。--落花有意12138 _{论 回复请ping我} 2022年1月29日 (六) 08:50 (UTC)

“两种合法情况”是指不符合“Wikipedia:格式手册/旗帜#旗幟圖案不用於强调国籍目的和Wikipedia:格式手册/旗帜#有利于读者閱讀，而非装饰用途”还是符合？符合的话暂时还没有理由限制，不符合的话那要例外就意味着推翻上面两条总纲。--7（留言） 2022年2月1日 (二) 08:56 (UTC)

图例也需要清晰可辨啊，你看看这些旗帜：

• 斯洛維尼亞
• 斯洛伐克
• 荷蘭
• 盧森堡
• 印度尼西亞
• 摩納哥
• 羅馬尼亞
• 乍得
• 澳大利亞
• 新西兰

 ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月17日 (一) 08:59 (UTC)

还有需要注意的是在信息框中大量使用国旗，其实我不太赞同英文维基百科完全禁止在人物信息框（{{Infobox person}}）中使用国旗，但看到中维某些传记条目，一名几乎没有海外活动的人，信息框中出生地点、逝世地点、国籍、居住地（或墓地）几个字段挂着一副一模一样的国旗，这都不是用于强调国籍目的我还真不信。--BlackShadowG（留言） 2022年1月17日 (一) 13:04 (UTC)

那么是否可以在上述几个字段如果相同时，限制只使用一次旗帜，或者出生逝世均不使用旗帜。--落花有意12138 _{论 回复请ping我} 2022年1月18日 (二) 14:35 (UTC)

支持沿用英维的规定，人物Infobox不应使用国旗。正文中更不应该使用国旗。--菲菇＠维基食用菌协会 2022年1月17日 (一) 20:06 (UTC)

我想说，这恐怕不是什么“人物Infobox”的问题，不用旗帜的核心思想在于“避免花哨华丽”，避免任何方面内容显得比其他内容更重要进而转移读者注意力。常见国家、地区、度量衡之类连内链都不应该加也是同样理由。如果因为是国家就有理由使用旗帜代表，但又凭什么认定宗教、党派图案不行，进而又凭什么说州旗市旗不行？各种旗帜、徽章、符号图案早已变成装饰品，根本没有提供任何额外信息，小小的图案又看不清楚、难以分辨（比如上面魔琴举例），来个极端点的，谁要是在X总统后代的条目给“父母”栏加上：父亲格罗弗·克利夫兰，岂不是都要赞赏一下用户的想象力？--7（留言） 2022年1月18日 (二) 10:48 (UTC)

作为Wikipedia:格式手册/旗帜的原初译者，我当然是全盘同意英维在旗帜徽章符号上的使用主张。只是人物infobox是此前多年来反对意见最为集中的地方，我当然要强调这点——国旗根本就不应该用在出生、死亡地点来暗示一个人的国籍。至于“避免花哨华丽”，我以为这已经是一个共识了（“旗帜图案应对读者的理解有用处，而非仅作装饰之用”），现在的问题多在于执行上。--菲菇＠维基食用菌协会 2022年1月26日 (三) 04:18 (UTC)

正文目前本就不能使用旗幟。—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年1月18日 (二) 10:52 (UTC)

由于上述讨论，我想到如果字段内容精确到一级以下的行政单位，那么如何标识旗帜？如何加内链？

如果加这个行政单位的地方旗帜，那么对于没有的怎么办？如果不加旗帜，那么如何与其他的统一？--落花有意12138 _{论 回复请ping我} 2022年1月18日 (二) 14:42 (UTC)

表格入面像2021年王者荣耀挑战者杯的使用也要提一下。--Ghren🐦🕛 2022年1月18日 (二) 16:57 (UTC)

我作為Wikipedia:格式手册/旗帜現版本的提出者，我有必要就現狀進行解說。我的原提案大體上是與enwiki一致的，但我收到相當的意見反對限制旗幟在Infobox的使用，因此改為現版本並通過。我不反對Jarodalien的提議或與enwiki看齊，也很歡迎如此提案，但我懷疑社羣是否真的能就此達致共識。Sanmosa _A-DWY³ 2022年1月23日 (日) 04:27 (UTC)

如果“人物infobox”还有争议，那么大家能否认同“非人物infobox”不用国旗呢？比如，地址、党旗、格罗弗·克利夫兰，还有上面所谓的“电影产地模板”？我提议删除所有电影产地模板。非要用国旗的就直接美国，不要拿什么美國来做文字游戏。--7（留言） 2022年2月1日 (二) 08:56 (UTC)

我覺得還有一點可以探討的是Navbox用國旗模板到底是不是有問題的，我提案當時的討論中也有人提過這點。如果可行的話，我很建議把Navbox也一同管制。Sanmosa _A-DWY³ 2022年2月1日 (二) 12:29 (UTC)

@Jarodalien：要提醒的一點是enwiki存在國歌Infobox使用國旗模板的例子，例如en:State Anthem of the Soviet Union。--Sanmosa _A-DWY³ 2022年2月1日 (二) 12:33 (UTC)

要按中維的習慣，List of successors那裡也會出現一堆flag……--洛普利寧 2022年2月1日 (二) 15:44 (UTC)

意见征集

1. Wikipedia:格式手册/旗帜下各项规定对信息框和正文同样适用，除非有其他明确规则（如体育、军事类），否则信息框和正文表格都不能使用国旗；

• (＋)支持。--7（留言） 2022年2月9日 (三) 02:56 (UTC)

2. Wikipedia:格式手册/旗帜下各项规定只对正文适用，对信息框不适用，信息框和正文表格无论是哪一类条目不限制使用国旗，即人物出生地、死亡地、下葬地均可加国旗、州旗、市旗，党派可加党派，官职可加，宗教信仰可加信仰旗帜，出版作品产地、发行地可加国旗、州旗、市旗等。

本着一视同仁，避免一碗水端不平的情况，以上仅列出一律适用和一律不适用两大类。如果大家有自认不存在争议的方案还请提供。--7（留言） 2022年2月9日 (三) 02:56 (UTC)

支持維持現狀。一律適用和一律不適用等「一刀切」方案都不盡理想。不過我個人對於國旗以外的各類旗幟都是比較不贊同使用的。—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年2月9日 (三) 05:25 (UTC)

现状不过就是打编辑战而已。每个人看法不同，你支持用国旗，现在也有实例支持用党旗、官职旗、家族纹章，要么就全部允许。所谓的维持现状只不过假装没有任何问题和争议。--7（留言） 2022年2月9日 (三) 06:44 (UTC)

只要先到先得原則得到實踐就沒有問題。—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年2月9日 (三) 09:38 (UTC)

先到先得意思是说，建立条目的那个人放了国旗，这个条目就可以放，没放国旗就不放？不然在这里怎么成立？而且既然实际效果是不限制，那就请表决支持不限制。--7（留言） 2022年2月9日 (三) 11:20 (UTC)

有無明文規定可確實是有差別的。現階段我不支持在格式手冊寫入上述任一方案。—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年2月10日 (四) 12:24 (UTC)

對於我言，在可以在表格或者資料框中使用旗幟以保持齊整、縮短字數和讀者看得懂作為原則。比如說今天的你的名字的條目，以旗幟列出大中華地區代理的書籍，名稱是比較合理的，因為保持了統一的大小，和減少了字數的使用。但是詳列各國上映時間就過火了，因為讀者根本不太能記得這個國旗。--Ghren🐦🕖 2022年2月9日 (三) 11:01 (UTC)

根据什么判断“读者看得懂”，每个读者看得懂的国旗可能不一样吧，而且很多旗帜相似，只要允许用就自然会全部用，不可能以任何国家“看不懂”为由拒绝，要觉得可以就请在上面表决不限制。--7（留言） 2022年2月9日 (三) 11:20 (UTC)

我倾向于支持信息框中涉及地点的时候才允许挂国旗。 ——魔琴 [ 留言 贡献 ] 2022年2月10日 (四) 12:59 (UTC)

請求維基追加新功能讓用戶自行選擇是否顯示國旗，--北極企鵝觀賞團（留言） 2022年2月11日 (五) 12:10 (UTC)

1案或維持現狀我都不反對。2是比1寬鬆的情形，我不支持任何放寬的提案。Sanmosa _A-DWY³ 2022年2月12日 (六) 04:16 (UTC)

較支持方案1。 --Loving You Is A Losing Game 2022年2月12日 (六) 15:41 (UTC)

傾向支持資訊框涉及國家政權之時仍用國旗，地點反而不應該用（尤其為有領土爭議之處）。--路西法人☆ 2022年2月15日 (二) 03:26 (UTC)

支持在信息库中适度使用旗帜，如用旗帜标注国家。(－)反对一刀切（禁止正文和信息框使用旗帜或无限制地使用旗帜）。--驻军（留言） 2022年2月16日 (三) 23:25 (UTC)

既然无法达成共识，那烦请社群明确以下不可调和的矛盾

上面的驻军用户坚持要在信息框使用电影产地模板，而我是坚持不使用的。这里我无意再讨论是非问题，只想明确一点：电影产地模板是不是一定要使用？谁能决定、拍板是否使用？出现这种无法调和的争议时到底是不是永远都只能按3RR处理？

从上面用户意见来看，许多用户都认为可以用国旗代表国家，那么在此建议：

一、废除Wikipedia:格式手册/旗帜下子项Wikipedia:格式手册/旗帜#旗幟圖案不用於强调国籍目的，和Wikipedia:格式手册/旗帜#有利于读者閱讀，而非装饰用途。

二、不废除但修改内容，“维基百科不是国家或民族自豪感的宣传工具。旗帜在视觉上引人注目，故在某事物旁放置国旗会让该事物的国家性或地区性看起来比其他属性更为重要”改成“用维基百科宣传国家或民族自豪感是可以接受的。旗帜在视觉上引人注目，可以放置国旗让国家或地区看起来比其他项目更重要”；“旗帜与其他图标经常被误用作装饰用途”改为“可以使用旗帜与其他图标作为装饰用途”。子标题“旗幟圖案不用於强调国籍目的”改成“旗幟圖案可用於强调国籍目的”，“有利于读者閱讀，也可用于装饰用途”。“Wikipedia:格式手册/旗帜#不要使用太多的旗帜”内容改成“国旗使用次数不限制，其他旗帜使用不要超过五千次”。

公示前表决。--7（留言） 2022年2月20日 (日) 04:41 (UTC)

就先不提整個提案本身有多刻意，「五千次」的標準是哪裡來的？—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年2月26日 (六) 16:28 (UTC)

@Jarodalien：您誇張了。我的建議條文如下：

提議條文 何時適合在條目中使用旗幟和徽章等圖標？ 使用時機 Y 合適的做法 N 不當的做法 Y 用於列表、表格和資訊框中：列表和表格可被用作並列出多個國家、地區、政權以至政黨、組織等的情事，而資訊框則是總結性的提綱列表，用作列出所述主題的重點。在列表、表格和資訊框中恰當地使用旗幟或徽章等圖標有助於讀者快速瀏覽重點和識別他們尋找的內容。 N 用於條目正文：旗幟和圖標僅應在列表、表格與資訊框模板中，而不應該使用於條目正文的段落中。圖標在視覺上引人注目，在條目正文中使用旗幟或徽章等圖標會將人物公民身份、國籍、國家地區政權或主權或政治身份的重要性強調於其他內文文字之上，這會破壞全文的連貫性。 Y 用於表示政權和國籍：國家或地區旗幟圖標可用於表述國家、地區或政權本身，例如中华人民共和国、香港（或香港特別行政區）、中華民國、美国等情況。此外，國家或地區旗幟也可用於在列表、表格和資訊框表述人物的國籍，以及人物或組織所代表的國家。另，應注意遵守兩岸四地用語指引和朝鮮半島用語指引。 N 用於表達地理位置：旗幟圖標用作表述地理區域可能與維基百科不是地方政治的宣傳工具的原則相違背，尤其在存在領土主權爭議的地區。例如，五星紅旗是中華人民共和國國旗，但不是中國大陸的旗幟，在表述中國大陸的時候使用五星紅旗並不妥當，中國大陸跟中華人民共和國不是同義詞。同理，臺灣和中華民國亦非同義詞，表述臺灣時使用青天白日滿地紅旗亦是不合適的做法。 N 在超出原有意義的情況下使用：旗幟和徽章等圖標代表某特定實體，在沒有適合旗幟使用的時候也不應套用於其他事物身上。例如，國家或地區旗幟用作表述非代表該國家或地區的個人或組織不妥當，例如英文維基百科某足球運動員條目的歷史版本中，將國旗標記在非代表國家的球隊前，會使旗幟圖標偏離原有意義；條目中反而沒有在國家代表隊前標記國旗，在此使用旗幟圖標的情況下屬於本末倒置；又例如，我們不應濫用聯合國旗幟以代表全世界，因為這不是正確使用國際組織旗幟的方法。 Y 在有利於讀者閱讀的情況下使用：僅應在有利於讀者閱讀的情況下使用旗幟或徽章等圖標，例如在多個人物或組織的列表中使用旗幟或徽章以供識別不同的國籍或政黨等資訊，或在單獨一個人的情況下用以表達其國籍或政黨等資訊。例如，在選舉結果列表中，使用圖標可供識別參選人所屬不同政黨；或在政治人物條目中，以旗幟和徽章表述人物國籍和所屬政黨。 N 用作裝飾用途：旗幟或徽章等圖標經常被誤用作裝飾用途。例如在「美國棒球代表隊」條目2015年的版本的成員名單中，雖然符合了在列表中使用的條件，但列表中所有人物項目的國籍均一樣，實際上無法達到在列表中添加旗幟該有協助識別不同項目之間的差別的作用。故此，不應在無助達到有利於讀者閱讀的情況下使用旗幟或徽章等圖標。 易讀、可用與可辨識 ...

這個版本只改了一小部分，先看看？--路西法人𖤐 2022年2月28日 (一) 06:06 (UTC)

噢還有，這個版本簡單而言就是使 中国大陆和 臺灣不應被使用--路西法人𖤐 2022年2月28日 (一) 07:43 (UTC)

Zh.WP checkuser re-introduction／重新引入中文維基百科用戶查核權限

原标题为：Zh.WP checkuser re-introduction/重新導入中文維基用戶查核權限

The members of the local Chinese language Wikipedia community and the Stewards, who currently provide CU support to Zh.WP, have indicated to the Foundation that it would be desirable to explore possibilities of reinstating local CheckUser privileges on Chinese language Wikipedia. These rights were revoked from the local community due to security concerns in 2018.

中文維基百科本地社群成員以及替中文維基百科提供用戶查核支援的監管員已向維基媒體基金會反映希望恢復中文維基百科的用戶查核權限。此權限基於安全考量，於2018年自本地社群移除。

As a Foundation, we strongly endorse community self-governance wherever feasible. We also realize that each community has unique challenges that require authentic approaches that tackle them. In this spirit, we would like to state that the Foundation would support reinstating local CU privileges if Zh.WP meets two conditions.

作為基金會，我們在許可範圍內強力支持社群自治；我們也同樣理解不同的社群有其特有的挑戰，亦需要用獨特的方式來應對。本著此精神，我們想聲明：若中文維基百科可以滿足下述兩個條件，基金會將會支持恢復本地社群之用戶查核權限。

First, that the local Chinese language Wikipedia community offer their commitment to uphold the global aspects that all communities with local CU privileges uphold. A critical element is policy compliance. Currently, all communities with local CheckUser privileges are required to adhere to binding policies governing the recruitment of CheckUsers and the use of the tool. The potentially elected Zh.WPs CU would need to strictly uphold the Compliance with the CheckUser Policy and Compliance with the Access to Non-Public Information Policy, including the NDA policy update 2021. The local community should in turn respect these instruments.

首先，中文維基百科本地社群必須承諾維護所有擁有本地用戶查核權限之社群的通用認知。其中一個關鍵要素為政策規範合規性。目前，所有擁有本地用戶查核權限之社群都被要求要遵守有關用戶查核者的招募及使用工具之約束性政策。未來中文維基百科中可能當選為用戶查核員之用戶必須恪守用戶查核政策與非公開個人資料存取政策，包含2021年更新之保密協議。本地社群必須尊重這些政策文件。

Secondly, the Foundation is aware that the Chinese language Wikipedia continues to have long-standing internal trust challenges unique to the local community. We are aware that the local community is confronting noteable difficulties in local collaboration both on the Chinese mainland and internationally. As a Foundation, we undertake to support the re-introduction of the local CU rights if:

再來，基金會已認知到中文維基百科持續面臨當地社群獨有的長期內部信任挑戰。我們理解本地社群在本地合作／協作上，不論是與中國大陸還是跟國際社群都窒礙難行。作為基金會，我們承諾在滿足以下情況下支持重新引入本地用戶查核權限:

1. Elections: All Zh.WP elections for CheckUser are conducted through SecurePoll elections (two weeks), with Steward scrutiny support. Doing so would provide greater safety to both candidates and voters. Further to this, the appointment tenure for CU user rights holders on Zh.WP to be two calendar years, at the end of which re-election of CheckUsers aiming to extend their tenure via SecurePoll will be required. Doing so would enable the local community, which does not have a NDA-signing ArbCom providing added accountability for CUs, to assess whether they still have sufficient trust in their local CUs after a meaningful period of time. There will be a recall mechanism for CUs. In it, voting-eligible users can safely register their voice in case they have lost confidence in a CU in-between elections. Once registered, a concern will be valid for a year or until the next re-election. 25 valid concerns related to a CU at the same time will trigger a recall election within two months, unless said CU decides not to run for re-election. Two years overall tenure in-between regular elections is in-line with long-standing re-election practices for CUs on German and Portuguese language Wikipedias, two other large communities with local CUs but without a NDA-signing ArbComs.
2. Training: All successful Zh.WP CU candidates to be trained in CU community best practices prior to the user rights change granting them CU rights. Doing so would ensure alignment of Zh.WP CU practices with the global community.
3. Audits: The Foundation will regularly audit CU activity on Zh.WP for at least a year; including an evaluation after a year whether or not to continue such audits. A practical way for that is keeping the current community consensus-based requests for checks. The community would comment on requests, which can then be audited for problematic users stacking against a certain user.

1. 選舉：所有中文維基百科之用戶查核員選舉必須透過SecurePoll秘密投票，每次選舉為期兩周，選舉期間必須有監管員支援監票，這樣做將有助於提供候選人及選舉人更大的安全保護。此外，當選之用戶查核員任期為兩年，在任期結束後必須要再度重新參與選舉，通過秘密投票來延長任期。這樣做將有助於社群，在缺乏簽署保密協議之仲裁委員會確保用戶查核員負責任的情況下，有一段時間去檢視和評估他們對於當地的用戶查核員是否有足夠的信任。用戶查核權限將有除權機制：有人事任免投票資格的用戶可以安全地提出自己的質疑，此質疑有效期為一年，或是到下次用戶查核員選舉之前；如果有超過25人之質疑關切，就會在兩個月內觸發罷免，除非該查核員選擇不競選連任。上述任期制度已由德語、葡萄牙語兩大有本地用戶查核權限但沒有簽署保密協議的仲裁委員會的社群採用。
2. 訓練：在授予權限之前，所有中文維基用戶查核員候選人都將會接受用戶查核員社群的培訓，以確保中文維基上的用戶查核實踐與全球社群一致。
3. 稽核：基金會將會定期稽核中文維基之用戶查核活動至少一年，此舉包含一年後是不是要繼續持續這樣的稽核機制等。目前針對稽核有一個實用的方式：持續目前基於社群共識作出的查核請求；社群將對這些請求發表評論，令基金會可以稽核這些評論，以便尋找針對特定用戶的問題用戶們。

Finally, the Foundation commits to facilitating the functionary-guided creation of a CU self-learning module, available in Chinese and English in the Wikimedia LMS in 2022. This will document global community best practices for the tool and its appropriate use in a local community context.

最後，基金會承諾會促成在行政人員（functionaries）指導下創建一個用戶查核權限自我學習模組，其中英雙語版本將於2022年在維基媒體LMS供查閱，此舉將把全球社群在使用該工具的經驗以及使用方式以當地社群語言妥善記錄。

WMFOffice（留言） 2022年1月13日 (四) 20:38 (UTC)

• 微調翻譯。（沒調整很多所以一些語氣生硬或隱含錯誤之類的實在幫不上忙）—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年1月13日 (四) 22:20 (UTC)
• 我搬回内地了，不然还真的会考虑一下申请这个工作。Itcfangye（留言） 2022年1月14日 (五) 04:11 (UTC)

“當選之用戶查核員任期為兩年，在任期結束後必須要再度重新參與選舉，通過秘密投票來延長任期....”WMF欽點了這個方法,那我認為可以在sysop上長遠使用啊?--Wiki emoji | 😷🅔🅜🅞🅙🅘🅦🅘🅚🅘😷 _{祝百毒不侵～} 2022年1月14日 (五) 08:30 (UTC)

不同意管理員任期制。另外我甚至反過來擔心這樣選使用者查核員會不會難產。—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年1月14日 (五) 10:04 (UTC)

難產的話，若有要查核就先轉交全域監管員？--0906_{（回復請Ping我）} 2022年1月14日 (五) 15:22 (UTC)

是的，如果难产，先转交至监管员。--夏雪若（留言） 2022年1月14日 (五) 15:28 (UTC)

難產也要。这是御旨。--Wiki emoji | 😷🅔🅜🅞🅙🅘🅦🅘🅚🅘😷 _{祝百毒不侵～} 2022年1月15日 (六) 05:51 (UTC)

我认为SRCU还有必要继续存在，鉴于社群目前的互信情况。不仅是CU员难产的问题，即使能选出CU员，社群对CU员的信任程度又有多少？到时候涉及老用户的查核可能还得监管员帮忙。另外我强烈建议CU的选举在管理员的安全投票试行一段时间后再举行。 ——魔琴 [ 已经告假 留言 贡献 ] 2022年1月14日 (五) 15:34 (UTC)

• 我支持CU员任期制，此工作的胜任难度比管理员高得多，CU相关工作是本地管理工作里最难的。按目前社群的互信情况，CU员真的难产。--Lanwi1(留言) 2022年1月15日 (六) 04:28 (UTC)

  話說上次是誰把cu數據洩露給中華愛國陣線的？--中文維基百科20021024（留言） 2022年1月15日 (六) 06:30 (UTC)

  我也不知道是谁泄露的，泄露的动机也有可能包括陷害他人。--Lanwi1(留言) 2022年1月15日 (六) 15:07 (UTC)

我想请问训练将在哪进行，以及训练一名用户查核员需要多长时间。--BlackShadowG（留言） 2022年1月17日 (一) 00:21 (UTC)

• 好家伙，比监督权严格多了。我的建议是监管员累死前大可不必接受这么勉强的本地查核回归，咱们大可多“不知好歹”一会。重建社区对CU的信任都已经很难了，还要来几尊基金会大佛盯着而且一年起步将来再议，这查核权属实烫手山芋。--南冥大鹏👈把我批判一番出偏差要负责👊微小的工作历史的进程✌ 2022年1月22日 (六) 02:06 (UTC)

对于重新引入不报希望，即便引入也是CU员难产。桐生ここ★[讨论] 2022年1月18日 (二) 05:11 (UTC)

• 如果已经明确计划好要恢复查核员，那对于无法签署NDA的大陆用户应该会造成更大规模的（无论主观或客观）歧视与不公平现象。毕竟曾经出现过

“ 至少3個管理員，說過：把自己的管理員帳戶給我。但都被我拒絕。我回答：等你們什麼時候混成CUer了，再把帳戶給我。現在CUer才是王道。管理員雖然也重要，但可CUer相比差得遠。 ” ——未知用户

这种话，而现在大陆用户连监督员都无法担任。--Yining Chen（留言|签名页） 2022年1月18日 (二) 14:34 (UTC)

基于上方理由，(－)強烈反对引入用户查核员，而且NDA不承认中国大陆的理由也合理无法反驳，不论对于歧视还是安全原因，都应维持现状。桐生ここ★[讨论] 2022年1月18日 (二) 14:46 (UTC)

我反对恢复本地CU权限的理由是大陆用户无法签署NDA以及对港台用户与居住在海外的大陆人的不信任，应该维持现状。--Lanwi1(留言) 2022年1月18日 (二) 14:57 (UTC)

既然这样，我建议自废武功，本地CU不能查有关延伸确认用户的请求，而应转交元维基；本地CU查到有关延伸确认用户的案件，应送报元维基核实。 ——魔琴 [ 留言 贡献 ] 2022年1月19日 (三) 04:19 (UTC)

所谓安全问题不是CU作出虚假结果，而是泄漏非公开数据，比如举报到香港国安处或者FBI，是编者的人身安全问题，即便CU值得信任，但是不能保证CU所在或所属的当局不会强迫CU进行查询，虽然大陆不能签署NDA，但比如香港、澳门实际上也是不安全的，要是排除这三个地方，就是一种歧视，因此不如维持现状。桐生ここ★[讨论]2022年1月19日 (三) 04:38 (UTC)

我觉得目前大概两点疑虑，一点是打击报复，我觉得我的方案可以解决；一点是CU数据的安全性，大陆人不能签NDA可以保证（至少很难被中华人民共和国获得）。另外我很疑惑的一点，为什么排除港澳就是歧视，排除大陆就不是？既然现在港澳还能签NDA，我们就没必要帮WMF担心。如果真的觉得港澳不安全，那就应该跟WMF建议撤销港澳人士的NDA。没有说港澳能签NDA但做CU不安全的道理。 ——魔琴 [ 留言 贡献 ] 2022年1月20日 (四) 04:29 (UTC)

支持合资格且有意向者申请用户查核权限，反对自我矮化主權，现今转交元维基的操作过于繁琐。先前对本地CU的担忧在于中共威胁与WMC渗透，基金会行动后已不是大问题。住所不为第三方所知的大陆用户仍然可以签NDA，而上方讨论中所说的“歧视与不公平现象”并无前例。--Lt2818（留言） 2022年1月19日 (三) 05:21 (UTC)

据我所知，User:Alexander_Misel的住所应该不为第三方所知，然而却有该笔日志（注意此日志发生在WP:OA2021之前，与OA无关）。第二点，只知道担心“中共威胁与WMC渗透”，那我们这些用户要不要担心“█国民主党和F█I威胁与H█U█渗透”？第三点，“歧视与不公平现象”没有前例，但正在发生。建议参考自基金会行动以后站内的几项所谓“决议”的流程。另：怎么看待上方在查核员尚未被废除时真实出现过的言论？只是维基人间“友好的交流”？现在为解决这种现象所做出的唯一努力就是“歧视大陆用户”吗？（可能违反WP:AGF，故自行删除）虽然基金会做出的决定改不了，这一点没错啦；但是还是很想知道类似这种“决定”的支持者是怎样思考问题的。--Yining Chen（留言|签名页） 2022年1月19日 (三) 14:39 (UTC)

具體住址是不知道，但是具體城市他曾經在QQ群公開過，他說那天他所在的城市居民包括他本人在內被全員核酸檢測。--中文維基百科20021024（留言） 2022年1月19日 (三) 14:27 (UTC)

我觉得住所不为第三方所知的大陆用户可以签NDA，也有大陆用户完全不愿公开自己的住址。--Lanwi1(留言) 2022年1月19日 (三) 15:43 (UTC)

即使“完全不愿公开自己的住址”，如果参加了任何线下活动，也很可能会有问题。甚至更极端的，在任何社交网站或者Zoom等地方公开了自己的照片，也有问题。更不用说真实身份早就众所周知的用户。--GZWDer（留言） 2022年1月21日 (五) 10:07 (UTC)

个人认为连六扇门都难以找到住所的用户才满足条件。至于上述个案，原因恐怕不止于此。--Lt2818（留言） 2022年1月20日 (四) 03:40 (UTC)

Wikipedia:河北维基人列表显示，该名用户现时住在石家庄。--Alexander Windsor^谈笑风生 2022年1月23日 (日) 07:13 (UTC)

個人意見同Lt2818閣下。—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年1月19日 (三) 07:41 (UTC)

除非 User:PMDdeSN 一事明了，否则(－)反对。--广雅 范★ 2022年1月19日 (三) 08:18 (UTC)

那看來洩露CU紀錄的事情不止一位，要是CU回歸中維的話大家應該做好心理準備。--中文維基百科20021024（留言） 2022年1月19日 (三) 08:36 (UTC)

是什么事？没有了解过。--Tranve (✉) 2022年1月20日 (四) 01:38 (UTC)

@Tranve：Wikipedia:互助客栈/其他/存档/2017年10月#用戶查核不得不說的事 --Lt2818（留言） 2022年1月20日 (四) 03:40 (UTC)

(！)意見如果本地重新獲得用戶查核權的話，可以保留元維基用戶查核請求權以處理有爭議的本地查核案。--🎋🎍 2022年1月22日 (六) 12:25 (UTC)

有爭議的话，找其他本地查核员复核较为合适，亦可找申诉专员。监管员不会有更高权威，君不见三位监管员确认之傀儡都能被抵赖掉。--Lt2818（留言） 2022年1月22日 (六) 14:17 (UTC)

如果要找申诉专员，可能会面临举证难题，而且这难道不是对一些 处于弱势且不精通外语的中国大陆用户 的一种歧视？（除非申诉专员里出现了zh-2用户）--Yichen Ding（留言|主账户） 2022年1月22日 (六) 14:49 (UTC)

就監管員吧，申诉专员處理效率肯定沒監管員好，不過可能要先問監管員願不願意。照規定來說，監管員不能處理有本地查核員的查核請求。--$\int$（☎） 2022年1月22日 (六) 18:32 (UTC)

個人認為基金會會推動本地CU建立，然後到時監管員就不用管咱的CU請求了。除非有人跟基金會討論過可不可以維持現狀，不然我覺得樓上提的關於CU的問題要面對只是早晚而已。--$\int$（☎） 2022年1月26日 (三) 23:58 (UTC)

基金會沒打算解釋一些細節麼？—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年2月11日 (五) 03:39 (UTC)

包括所謂的除權機制、當選人所接受的培訓，以及定期稽核等等，基金會都沒有給出足以讓本地社群討論或訂立規範的內容。—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年2月21日 (一) 12:28 (UTC)

读完了大家的讨论，我的观点也是给中维CU不够安全。原因有二，首先，WMC和中共不是我们唯二要防的信息泄露对象，前面各位点到的其他政权和团体对中维产生的潜在信息泄露威胁也不是空穴来风。其次，在没有办法向内地用户提供CU权限的情况下，也很难平衡不同地区的查核员的比例。除此以外，基金会这次给出的信息太过有限了，不知道该如何应对。Itcfangye（留言） 2022年2月26日 (六) 06:31 (UTC)

1. WMC和中共是特定于中文站点的担忧对象，其他实体或者未见对本地的危害迹象，或者对全域项目有影响（如NSA对维基百科的监控），不见得由监管员代替本地查核员即能消除信息泄露威胁。
2. 未见“平衡不同地区的查核员的比例”之必要性，这与查核工作能否安全有效运行并无关联。

--Lt2818（留言） 2022年2月27日 (日) 13:43 (UTC)

意见同上。另外，wikt:空穴來風。 ——魔琴 [ 留言 贡献 ] 2022年2月27日 (日) 15:20 (UTC)

本討論章節會維持開放，暫時不按最後意見發表時間存檔，直到情況有所進展。欲讓機器人存檔，請移除本模板。留言請置於本模板上方。

增修標點符號格式手冊

建議在標點符號格式手冊增修有關示亡號的使用，規範示亡號僅用作在列表中（包括點列式、表格或資訊框內）標記當前文字所表述的時間環境下此人已經逝世，例如在長壽節目製作播出期間演員或製作人員逝世，或是獎項追頒。{{金鐘獎特別貢獻獎}}、{{新闻联播播音员}}屬於合理使用示亡號的例子，而{{大紫荊勳章}}的例子就屬於濫用。--路西法人☆ 2022年1月14日 (五) 14:29 (UTC)

(＋)贊成，不然遲早會看到全部是示亡號的列表。--Wolfch (留言) 2022年1月15日 (六) 07:00 (UTC)

囧rz……(＋)支持 Wiki emoji | 😷🅔🅜🅞🅙🅘🅦🅘🅚🅘😷 _{祝百毒不侵～} 2022年1月25日 (二) 05:49 (UTC)

内容不可更新的纸媒列表使用示亡号比较常见，而内容可更新的网络列表是否必要使用？人总是要死的。乌拉跨氪 2022年1月17日 (一) 16:47 (UTC)

(＋)支持，甚至我覺得可以完全禁止使用，這個符號本來就不是什麼通用符號，再加上維基百科有內部連結，想知道一個人還在不在世用滑鼠放到上面不就知道了，點進長壽劇節目條目又不是想看甚麼「xx医院死亡演員列表」。至於獎項追頒應改為其他腳註符號，* † 之類的，又不是說活著拿獎的人就不能死，這樣會產生很多歧義。--Austin Zhang（留言） 2022年1月17日 (一) 19:36 (UTC)

(＋)支持。—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年1月25日 (二) 04:33 (UTC)

---

@LuciferianThomas：是否提出正式修訂草案並作公示？—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年2月2日 (三) 11:20 (UTC)

(＋)贊成限定使用范围，不然迟早全都是方框。--字节 2022年2月4日 (五) 02:52 (UTC)

(－)反对，反对额外的示亡标识，根本上不加。用连接到条目则可解决，如果对应人名没条目，可以简单补充生亡年份来代替。——Sakamotosan路过围观 | 避免做作，免敬 2022年2月8日 (二) 02:31 (UTC)

格式手冊可採「多數禁止，少數不建議」立場表達本站態度。—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年2月8日 (二) 11:34 (UTC)

同Eric君顧着搞SPI忘了我提過這個（草--路西法人☆ 2022年2月15日 (二) 03:25 (UTC)

反對在任何條件中使用示亡號，Special:Diff/70179631，founder部分看似符合提案人的要求，但等到其餘三位辭世，豈不是founder一欄出現四次示亡號。--寒吉 2022年2月15日 (二) 05:02 (UTC)

創辦之時未離世，董事長之位會被取代（不是其獨有）。--路西法人☆ 2022年2月16日 (三) 02:21 (UTC)

那我還是一樣反對在任何條件中使用示亡號。董事長當然會被取代啊，所以我上頭只提「founder部分」，沒提董事長。--寒吉 2022年2月16日 (三) 11:41 (UTC)

founder部分不會啊，不就說了「創辦之時未離世」嗎？--路西法人𖤐 2022年2月18日 (五) 05:57 (UTC)

我的回覆有質疑「創辦之時未離世」這句話嗎？我的看法就是一律禁用示亡號，只是恰巧你在此處提案，我順便提出Special:Diff/70179631詢問founder部分是否符合提案的要求，你回覆不符合，而我沒質疑這部分啊，我只是回覆為何你要回覆我沒提到的董事長部份而已，且founder部分不符合提案仍不會改變我持一律禁用示亡號的看法。--寒吉 2022年2月19日 (六) 11:42 (UTC)

先說我本人的淺見。我認為在百科全書標示亡號完全沒必要。百科全書是要流傳千古的，也就是說，總有一天書上所有條目裡的所有人名都是死人，那就全都要標示亡號。全都要標就等於全都不標，標了還浪費時間精力。百科全書皆如此，不獨維基為然。

可行的用法，就是在實際生活上的用法，也就是事件來臨時相關人物已經不在了。例如候選人於競選活動開始前死亡（美國發生過），影業人員在影片發行前死亡（如英雄本色中的石燕子，不過有疑義）等等。但現在某些維基編輯的用法是看到哪個公眾人物死了，就忙不迭把相關條目全翻出來，一個一個替人標示亡號。所以這就涉及定義了：示亡號是用於表示看到條目時人已經不在了，還是表示事件發生時人已經不在了？我認為是後一種，各位呢？這點要列為方針嗎？

前面說到疑義，是有的事件發生不止一次。例如英雄本色上映時間各國不同，以何為準？還是就乾脆不用標了？

謝謝各位撥冗看我囉唆一堆細節。--以上未簽名的留言由2603:8000:500:FB00:5011:1E64:1DB0:C8F1 （討論）加入。 —此條未加入日期時間的留言是于2022年2月20日 (日) 08:14 (UTC)之前加入的。

• 會否有人於古代條目為所有人標上示亡號?--Temp3600（留言） 2022年2月23日 (三) 14:58 (UTC)

  示亡號不應用於正文，也只應用於「進行中死亡」的情況。理論上是不行。--路西法人𖤐 2022年2月23日 (三) 15:46 (UTC)

對典範條目評選重選的提議

這討論曾建議本身GA的條目在評FA時可GA重審一次，而我在FA重審中想：FA要求比GA高，如果一曾通過FA評選條目因FA重審而變成非GA、非FA，有一點奇怪（特別是同時曾通過GA及FA評選條目）。在此我提議

現行條文 若條目本身是優良條目，其典範條目評選期間可提出優良條目評選以作重審一次（只限一次）。優良條目評選被提出時，其典範條目評選會被暫停，暫停期間在典範條目評選的投票將會視為無效，但仍可提供意見。而當其優良條目評選結束時： 如條目喪失優良條目資格，其典範條目評選則會被視為無效而結束並進行存檔。 如條目保留優良條目資格，其典範條目評選則會被恢復，且結束時間亦會相應延後以補回暫停期間的時間。

提議條文 若條目本身是優良或典範條目，其典範條目評選或重審期間可提出優良條目評選以作重審一次（只限一次）。優良條目評選被提出時，其典範條目評選或重審會被暫停，暫停期間在典範條目評選的投票將會視為無效，但仍可提供意見。而當其優良條目評選結束時： 如條目不符優良條目資格，其典範條目評選或重審則會被視為無效而結束並進行存檔。 如條目符合優良條目資格，其典範條目評選或重審則會被恢復，且結束時間亦會相應延後以補回暫停期間的時間。

徵求大家意見--Cmsth11126a02（留言） 2022年1月31日 (一) 16:57 (UTC)

的確有些需要重審，我是覺得應該要設優良條目當選到典範條目候選之間的冷卻機制，別一上來就直接用典範條目候選，有失公平性（除非曾經是典範條目落伍一段時間以外）！--小躍（撈出記錄） 2022年2月3日 (四) 00:06 (UTC)

@小躍：現在已有30天提名冷卻期。--Cmsth11126a02（留言） 2022年2月7日 (一) 05:49 (UTC)

邀請曾參與這討論的人@Z7504、Sanmosa、Cdip150、Cwek、Inufuusen、Opky9407：--Cmsth11126a02（留言） 2022年2月9日 (三) 04:54 (UTC)

(！)意見，這種情況我會建議FA/FL被撤銷後可以不須等30天直接提GAC，而不是FAR途中提出GAC。原因是當FAR途中的GAC結果是符合GA、而FAR恢復之後的結果是不符合FA，那麼條目是會降為GA還是完全撤銷？如果是前者，將導致FAR通過時，處理辦法出現不一的情況——有時是完全撤銷（如果期間沒有GAC）而有時是降為GA（如果期間有GAC），我擔心執行上會較易出錯；而如果是後者，則GAC又會變得蕩然無存。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年2月12日 (六) 04:36 (UTC)

---

@Z7504、Sanmosa、Cdip150、Cwek、Inufuusen、Opky9407：考慮街燈電箱意見，我改變原先建議，現建議修改優良條目評選條件中的

現行條文 同一個條目請勿在距上一次優良條目或典範條目評選結束後不滿30天內重複提名，否則該提名視為無效。

提議條文 同一個條目請勿在距上一次優良條目或典範條目評選（不包括典範條目重審）結束後不滿30天內重複提名，否則該提名視為無效。

因如重審成功，第六條的「若條目本身是典範條目，請勿對其進行優良條目評選」已阻止其被提名優良條目評選/重審。--Cmsth11126a02（留言） 2022年2月13日 (日) 01:37 (UTC)

题头的话，我认为是如果原来是GA，在通过FA评审时失败，应该先回落到GA，而不需要做GA重审，除非之后重新申请GA重审。至于怎样完善相关说明，我的想法如前述。——Sakamotosan路过围观 | 避免做作，免敬 2022年2月16日 (三) 03:50 (UTC)

@cwek：原GA在第一次評FA失敗時已會回落到GA，我指的是原GA->評FA成功->重審FA失敗而失去全部（例：阿梅莉亚·埃尔哈特）--Cmsth11126a02（留言） 2022年2月16日 (三) 07:34 (UTC)

除非更改典範條目評選整理步驟中的撤銷典範條目狀態⋯⋯--Cmsth11126a02（留言） 2022年2月16日 (三) 07:36 (UTC)

---

7日無新意見，以最新建議版本🕗 公示7日--Cmsth11126a02（留言） 2022年2月23日 (三) 08:01 (UTC)

@Z7504、Sanmosa、Cdip150、Cwek、Inufuusen、Opky9407：--Cmsth11126a02（留言） 2022年2月23日 (三) 08:10 (UTC)

• 沒意見，只是現在鮮少在用評選了，但可別忘了評選Bug是不太可能完全能解決的。--Z7504非常建議必要時多關注評選（留言） 2022年2月25日 (五) 10:50 (UTC)

快速刪除被全域禁制個人的編輯

為整合有關主題的討論，本討論已移動至Wikipedia_talk:快速删除方针 § 快速刪除被全域禁制個人的編輯進行集中討論。請至有關頁面發表意見。

執行人：Ghren🐦🕑 2022年2月2日 (三) 18:25 (UTC)

本討論章節會維持開放，暫時不按最後意見發表時間存檔，直到集中討論告一段落。欲讓機器人存檔，請移除本模板。留言請置於本模板上方。

统一WP:RFR权限不活跃时间

解除權限方針有這樣的規定：

當超過六個月沒有任何編輯活動，在Wikipedia:申请解除权限報告後如查明屬實便即時除權。

而目前各權限方針頁面的不活躍期限状态如下：

• 六个月
  • 巡查员
  • 回退员
  • 跨维基导入者
  • 自動維基瀏覽器
• 一年
  • 模板編輯員
• 不限期
  • 巡查豁免者
  • 大量訊息發送者
  • 大量帳號建立者
  • 檔案移動員
  • 机器用户

提议更改以上权限不活跃时间统一为一年，以安全理由来说，大量信息发送及大量账号建立显然更需要安全。对于使用完毕就除权的权限，是指未使用完毕但用户失踪的情况，因此统一设立一个一年的不活跃时间。确认用户参考自动确认用户，不设期限。IPBE另案考慮。

--桐生ここ★[讨论] 2022年2月1日 (二) 16:54 (UTC)

( π )题外话：同时是否应该统一允许上述用户组移除自身权限(自动维基浏览器除外)，比如模板编辑员目前不能自行移除。桐生ここ★[讨论] 2022年2月1日 (二) 19:12 (UTC)

既然管理员是六个月除权，那么这些也应该统一为六个月。->>Vocal&Guitar->>_留言 2022年2月2日 (三) 02:24 (UTC)

管理員是謎的六個月+一個月通知期呢，我認為應該順便廢除一個月通知期。--AT 2022年2月2日 (三) 03:08 (UTC)

已有复权方针，因此通知期似乎没有必要？桐生ここ★[讨论] 2022年2月2日 (三) 06:26 (UTC)

支持统一，另外一个月的缓冲期给了管理员“回归”并继续“挂机”的机会，与解任初衷不符。--东风（留言） 2022年2月2日 (三) 05:49 (UTC)

我認為管理員不活動除權的期限也應該延長至一年。通知期問題，大可改成前一個月通知，期限一到就除權，這樣才符合初衷。—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年2月2日 (三) 06:15 (UTC)

一年雖然不認同，但是改成前一個月通知則合理得多。不過，如果僅管理員需要通知的話，我認為是非常不合理，除非其他權限也提早一個月通知，否則也應完全廢除管理員的一個月通知，畢竟管理員不應該有任何特權。--AT 2022年2月2日 (三) 12:41 (UTC)

真熱愛維基的話一天不編輯都會難過，所以一年的確太長。因此應該一律半年（六個月）不活躍撤權，第五個月通知，適用於所有權限持有者。--中文維基百科20021024（留言） 2022年2月2日 (三) 12:48 (UTC)

管理員和上述其他權限之持有者，在重要程度和安全風險等方面都難以一概而論吧。還不如這樣，管理員維持半年，其他的統一為一年。除權的話一律提前一個月通知。—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年2月2日 (三) 17:01 (UTC)

管理員半年+提前一個月通知可能沒異議，讓這一點先通過公示吧。--中文維基百科20021024（留言） 2022年2月2日 (三) 17:06 (UTC)

支持。桐生ここ★[讨论] 2022年2月2日 (三) 17:17 (UTC)

巡查豁免者無任何編輯活動本身並不會構成任何安全性風險，因此我不建議為巡查豁免者設置不活躍除權機制。Bot無任何編輯活動的安全性風險我想聽取@Xiplus的意見。其餘權限我同意設置／保留不活躍除權機制並統一不活躍時長限制。Sanmosa _A-DWY³ 2022年2月2日 (三) 07:17 (UTC)

比如账号失窃大量建立破坏条目被自动巡查，使得巡查员不能及时发现？机器用户是Flood，机器人Bot的不活跃期限已经是一年。桐生ここ★[讨论] 2022年2月2日 (三) 07:24 (UTC)

那我不反對為巡查豁免者設定不活躍除權機制。--Sanmosa _A-DWY³ 2022年2月2日 (三) 10:34 (UTC)

不能說完全沒有風險，端看您能想到該怎麼濫用這個權限，例如竊取巡查豁免者的帳號來建立難以發現的惡作劇條目之類的。--Xiplus#Talk 2022年2月2日 (三) 11:13 (UTC)

所以我改了表態。感謝意見。--Sanmosa _A-DWY³ 2022年2月2日 (三) 11:20 (UTC)

AWB 應該不用設限吧？其餘我覺得可以設限半年！--小躍（撈出記錄） 2022年2月3日 (四) 00:11 (UTC)

AWB目前已经被设限。桐生ここ★[讨论] 2022年2月3日 (四) 03:59 (UTC)

AWB可以自己移除，只要在Toolforge架个OAuth程序当中介让AWB者进入自行除权。 Wiki emoji | 😷🅔🅜🅞🅙🅘🅦🅘🅚🅘😷 _{祝百毒不侵～} 2022年2月6日 (日) 11:31 (UTC)

這是甚麼麻煩的操作，況且你怎麼知道機器人會不會濫權（（（-- Sunny00217  2022年2月8日 (二) 01:34 (UTC)

現行條文 如有管理員的貢獻紀錄符合下列條件，則被視為處於不活動狀態： 最近六個月未曾做過在用戶貢獻或日誌中有記錄的編輯。 當达到上述条件時，該位管理員應經由以下方式得到通知： 用戶對話頁 其他通訊方式，如電郵、即時訊息、電話等 當某位管理人員在行政員布告板被提名，並且通知發出逾一個月（30天）后，該管理人員仍然沒有做過除用户、用户讨论命名空间的編輯，其便會被取消管理人員權限，而五項管理人員權限亦會同步移除。 如欲提請取消不活動管理人員的權限，請到行政員布告板提出。

提議條文 如有管理員的貢獻紀錄符合下列條件，則被視為處於不活動狀態： 最近六個月未曾做過在用戶貢獻或日誌中有記錄的編輯。 當达到上述条件時，該位管理員會被取消管理人員權限，而五項管理人員權限亦會同步移除。 如欲提請取消不活動管理人員的權限，請到行政員布告板提出。 在管理員未編輯和未操作時間達到第五個月時可以由以下方式得到通知： 用戶對話頁 其他通訊方式，如電郵、即時訊息、電話等。

—中文維基百科20021024（留言） 2022年2月16日 (三) 10:01 (UTC)

• @中文維基百科20021024：管理员的提案是否另开一题。->>Vocal&Guitar->>_留言 2022年2月25日 (五) 01:53 (UTC)

提案

Wikipedia:模板編輯員：

現行條文 模板編輯員在一年內沒有任何編輯。

提議條文 模板編輯員在六个月內沒有任何編輯。

Wikipedia:大量訊息發送者：

現行條文 若大量信息发送者有滥用权限的嫌疑（例如：利用大量信息发送功能发送广告信件），则用户在发现后，可以至Wikipedia:申请解除权限通报解除。

提議條文 若大量信息发送者有滥用权限的嫌疑（例如：利用大量信息发送功能发送广告信件），则用户在发现后，可以至Wikipedia:申请解除权限通报解除。当大量信息发送者超过六个月没有任何编辑活动，报告后查明属实便即时除权。

Wikipedia:大量帳號建立者：

現行條文 若大量账户创建者有滥用权限的嫌疑，则用户在发现后，可以至Wikipedia:申请解除权限通报解除。

提議條文 若大量账户创建者有滥用权限的嫌疑，则用户在发现后，可以至Wikipedia:申请解除权限通报解除。当大量账户创建者超过六个月没有任何编辑活动，报告后查明属实便即时除权。

Wikipedia:檔案移動員：

現行條文 -

提議條文 解除权限 若文件移动员有滥用权限的嫌疑，则用户在发现后，可以至Wikipedia:申请解除权限通报解除。当文件移动员超过六个月没有任何编辑活动，报告后查明属实便即时除权。

Wikipedia:巡查豁免權：

現行條文 -

提議條文 当巡查豁免者超过六个月没有任何编辑活动，报告后查明属实便即时除权。

具案，稍后开始公示。->>Vocal&Guitar->>_留言 2022年2月25日 (五) 01:53 (UTC)

我認為一年為宜，半年稍嫌短了。—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年2月25日 (五) 02:46 (UTC)

一年的必要性为何？退一步说即便因不活跃而除权，再申请也没有任何障碍，看不出有因此而影响用户贡献的情况。->>Vocal&Guitar->>_留言 2022年2月26日 (六) 05:17 (UTC)

就安全的角度來說，一年並不算長。另外與其讓有編輯gap的人（不少）重複走申請流程，還不如放寬一點。—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年2月26日 (六) 07:00 (UTC)

无根据的放宽只是不负责任而已。--。->>Vocal&Guitar->>_留言 2022年2月28日 (一) 01:18 (UTC)

無根據的緊縮只會增加行政負擔。要不規定一個月甚至一個禮拜沒上線就除權，不僅更加安全，而且再申請也沒有任何障礙。還是您要說，制定模板編輯員方針的人不負責任？管理人員手握重權，加上社群對其有一定程度的特殊期望，設置六個月活躍門檻尚情有可原；至於其他權限，則未見如此嚴格限制之必要。—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年2月28日 (一) 08:35 (UTC)

瀏覽算上線嗎？如果算上瀏覽的話，一個月不上線就除權也沒什麼問題。--中文維基百科20021024（留言） 2022年2月28日 (一) 08:43 (UTC)

制定模板編輯員方針的人當然是未盡責任，中文維基百科有權限申請方針和解除權限方針，不活躍的期限已規定在前述這兩個方針內，而英文維基百科沒有，所以不活躍期限是規定在各個權限方針/指引內；沒有意識到這個問題，直接採用英文方針的翻譯，未合適本地化，也未提出這個問題討論，才造成同層級的方針互相牴觸。一個好的反例是Wikipedia:權限申請#解任對於同時持有AWB使用權及機器人權限的帳號進行豁免，如果其他權限要採用不同期限，也應該如此記載。--Xiplus#Talk 2022年2月28日 (一) 09:18 (UTC)

照理說模板編輯員方針算是「特別法」，應該優先於其他權限解除的一般法，不嚴格有抵觸問題，不過本站似乎沒有相關概念，那還是得確定一下。—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年2月28日 (一) 12:27 (UTC)

以目前條文為了執法這樣解釋應該沒問題，但仍然修正為宜，至少加上「若個別權限有規定者則不在此限」等字樣。--Xiplus#Talk 2022年2月28日 (一) 14:15 (UTC)

除了模板編輯員值得討論以外，其餘覺得沒有必要，中文維基百科有權限申請方針和解除權限方針，不活躍的期限已規定在前述這兩個方針內，不同於英文維基百科沒有這兩個方針才需要逐個方針規定。--Xiplus#Talk 2022年2月28日 (一) 09:21 (UTC)

那相當於應該是把模板編輯員的期限字眼拿掉？--SunAfterRain 2022年2月28日 (一) 10:14 (UTC)

如果有其他撤權準則，條列在一起無所謂（即Wikipedia:模板編輯員#撤權準則），但單純複製貼上相同的條文到多個頁面就不必要了。--Xiplus#Talk 2022年2月28日 (一) 14:12 (UTC)

Wikipedia:维基百科不是词典嚴重滯後，請求按照現在的英文方針修改和擴充

我在维基百科:頁面存廢討論/記錄/2022/02/06#司寇討論中發現一個問題，就是現在的维基百科:维基百科不是词典的版本主要內容還是user:Shizhao2004年根據英維翻譯的版本，和現在的英維en:Wikipedia:Wikipedia is not a dictionary脫節嚴重。假如嚴格按照現在的维基百科:维基百科不是词典說法（「维基百科不是字典及词典，所以仅有一个定义而没有其它文字的条目不应该放在这里」），不管小條目是什麼類型，只有定義的話其實都可以去維基詞典，哪怕此類主題完全可以收錄進百科全書。而英文維基en:Wikipedia:Wikipedia is not a dictionary則開頭就列出了百科條目和詞典收錄範圍的異同（Each article in an encyclopedia is about a person, a people, a concept, a place, an event, a thing, etc., whereas a dictionary entry is primarily about a word, an idiom, or a term and its meanings, usage and history. In some cases, a word or phrase itself may be an encyclopedic subject, such as Macedonia (terminology) or truthiness.），下文還列出了表格作為比對，並且也沒有「维基百科不是字典及词典，所以仅有一个定义而没有其它文字的条目不应该放在这里（英文2004年版的方針：Wikipedia is not a dictionary, and an entry that consists of just a definition does not belong)」這句話了。--中文維基百科20021024（留言） 2022年2月6日 (日) 18:25 (UTC) 看了看Wikipedia:维基百科不是词典的討論頁，似乎該方針18年來只有一次討論。--中文維基百科20021024（留言） 2022年2月6日 (日) 18:57 (UTC)

同意。這個方針非常重要，應當更新。馬克西米利安一世（留言） 2022年2月8日 (二) 11:11 (UTC)

又來一個，维基百科:頁面存廢討論/記錄/2022/02/10#红土文化，user:A1Cafel的理由正如英文現今指引所提到的「One perennial source of confusion is that a stub encyclopedia article looks very much like a dictionary entry, and stubs are often poorly written; another is that some paper dictionaries, such as "pocket" dictionaries, lead users to the mistaken belief that dictionary entries are short, and that short article and dictionary entry are therefore equivalent.」（條目寫的太短，容易和詞典搞混）--中文維基百科20021024（留言） 2022年2月10日 (四) 06:17 (UTC)

真的應該移動到詞典的是维基百科:頁面存廢討論/記錄/2022/02/08#咩噗此類非百科內容的詞語、流行語解釋。--中文維基百科20021024（留言） 2022年2月10日 (四) 06:20 (UTC)

(＋)支持英維版本，精義就是en:Use–mention distinction，百科全書介紹紅土文化和司寇兩事物，詞典解釋「紅土文化」和「司寇」兩個詞。詞典要收定義不代表百科不能收定義，好的定義是應有的百科內容，可以保留，以待擴充。（當然若條目僅有差的定義，換言之無百科價值，仍應刪除。）——$\definecolor {my}{rgb}{0.04,0,0.5}\color {my}{\mathsf {htc_{23}}}$（留言） 2022年2月11日 (五) 00:28 (UTC)

Draft:Wikipedia:维基百科不是词典——$\definecolor {my}{rgb}{0.04,0,0.5}\color {my}{\mathsf {htc_{23}}}$（留言） 2022年2月13日 (日) 18:31 (UTC)更新

好，翻譯完的話是不是在這裡公示7天就行了？--中文維基百科20021024（留言） 2022年2月13日 (日) 01:19 (UTC)

應該是。—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年2月13日 (日) 08:52 (UTC)

已有初稿Draft:Wikipedia:维基百科不是词典，在下稍作 說明：

1. 一些段落對「不是詞典」加以闡釋，且在下認為是社群一早就有的共識，衹是未有明文寫下，應該較少爭議。但以下幾項可能爭議較大。
2. 如中維2002閣下所述，最大分別是廢除舊版的「僅有一個定義而沒有其它文字的條目不應該放在這裏」，僅有定義的小作品的存廢應（如常）按是否有百科價值（如是否屬「好定義」，是否小小作品，是否可直接用重定向代替）判斷。以「維基百科不是詞典」為由提刪將限於介紹標題用語本身而非標題所指代的主題的條目，如维基百科:頁面存廢討論/記錄/2022/02/08#咩噗，而不是维基百科:頁面存廢討論/記錄/2022/02/06#司寇，見Draft:Wikipedia:维基百科不是词典#格格不入的詞典詞條。
3. 有關新造詞（如網絡用語），重申來源使用某詞（以指代某事物）與介紹某詞（該詞本身）的分別，強調按關注度、可供查證、非原創研究等原則，有關新造詞的條目需要介紹該詞的來源，僅有可靠來源使用該詞不足以建立條目，見Draft:Wikipedia:维基百科不是词典#新造詞。本節並無新事，衹是從既有原則稍作延伸，但會有助澄清網絡用語條目的存廢。
4. 作為「不是詞典」的推論，維基百科的狗條目不是介紹「狗」這個詞（該詞指代某種動物），所以首句不寫成「狗指一種動物」，也不寫成「狗是動物的名稱」，而是介紹狗這種動物，寫成「狗是一種動物」。見Draft:Wikipedia:维基百科不是词典#修正首句的「指」，本節若獲採納可移入WP:格式手冊。
5. 標題詞性方面，英文有要求用名詞，但不符中文用法，所以相關段落在下已作修改，見Draft:Wikipedia:维基百科不是词典#不當標題。Wikipedia:命名常规對詞性保持沉默，實務上亦少見限制，所以希望寫明「未有限制條目標題的詞性」以作填補，防止因為詞性緣故令禁煙被移動至煙草禁制政策，燭之武退秦師被移動至燭之武退秦師事件（近來多有條目以「事件」或「爭議事件」為名，宜重申是可以但非必需）。本節若獲採納可移入Wikipedia:命名常规。
6. Draft:Wikipedia:维基百科不是词典#指向維基詞典建議啟用{{Wiktionary redirect}}，假如中文採用的話，使用狀況不是很明朗（？）。舉例英文有en:IMNSHO、en:Actions speak louder than words、en:Floccinaucinihilipilification，日文則有ja:重点、ja:保留。

以上，請求意見。——$\definecolor {my}{rgb}{0.04,0,0.5}\color {my}{\mathsf {htc_{23}}}$（留言） 2022年2月14日 (一) 21:22 (UTC)更新

第4點第一點可以接受是詞典的寫法。第二個表述，其實很多條目都在開頭講到「xx是指xxxxx」，本身這一表述可以算作百科方式的敘述。我再補充一條，假如說「狗是一個名詞，X朝就出現這一叫法」也算是一種詞典性質的寫法。--中文維基百科20021024（留言） 2022年2月15日 (二) 03:22 (UTC)

草稿原來已經都翻完了，厲害。--中文維基百科20021024（留言） 2022年2月15日 (二) 06:16 (UTC)

我移除了草稿中“維基百科不是宗譜辭典”一节，原因是该节在上下文中突兀，且“宗譜辭典”一词闻所未闻。相信英文世界同样如此，该词不仅没有条目，还要专门加个出处。中文常见的概念是家谱，这就不能称为词典了。--Lt2818（留言） 2022年2月19日 (六) 04:27 (UTC)

好。--中文維基百科20021024（留言） 2022年2月19日 (六) 06:13 (UTC)

第5点，百科条目标题严格上来说是由这个要求的，中文一般是要求名词或名词性的短语。“燭之武退秦師”可以视为是一个专有名词--百無一用是書生 (☎) 2022年2月22日 (二) 02:04 (UTC)

@HTinC23：，確實純名詞的話更容易寫成百科全書。--中文維基百科20021024（留言） 2022年2月22日 (二) 03:07 (UTC)

：🕗 公示7日，2022年3月7日 (一) 09:13 (UTC) 結束：無人反對，進入公示期。7天後草稿:Wikipedia:维基百科不是词典將代替Wikipedia:维基百科不是词典—-中文維基百科20021024（留言） 2022年2月28日 (一) 09:29 (UTC)

WP:UPNOT调整

WP:UPNOT的列举项并非全是“與維基百科無關的內容”，存在逻辑矛盾。为此我做了这笔修改，未实际更動指引内容，但由于调整了顺序，在此说明一下。--Lt2818（留言） 2022年2月13日 (日) 06:30 (UTC)

• 請直接具體說明你改了甚麼，並取得社群共識再去修改。那個修訂版本差別有夠難看，看了半天也看不出個所然。－hiJK910 ^{走先喇 係咁先喇 下次再玩吖} 2022年2月13日 (日) 08:57 (UTC)

• 我改了什么：把與“與維基百科無關的內容”無關的內容统一放在后面，前置“此外，用户页上亦不能放置”之句。
• “取得社群共識再去修改”：未修改方針指引文意的编辑可直接进行。
• “修訂版本差別有夠難看”：可以不用看版本差別，直接对比前后两个版本。

--Lt2818（留言） 2022年2月13日 (日) 09:22 (UTC)

@Lt2818：Wikipedia:共识#微小修訂簡易規定：“如該提案……為對方針指引等規定的單純語法調整、錯別字更正或現實性對應調整（事實性修訂），且無人對相關修訂提案是否單純語法調整、錯別字更正或現實性對應調整（事實性修訂）提出合理質疑……該修訂提案可立即執行，而毋須跟從基本規定。該修訂提案獲立即執行後，應在{{Bulletin}}的「公告」欄位加入連結宣告該修訂已獲進行。”我認為Hijk910的留言可能具足有人“對相關修訂提案是否單純語法調整、錯別字更正或現實性對應調整（事實性修訂）提出合理質疑”的要件（但如確認並不具足，此提案則確然可以立即執行）。Sanmosa _A-DWY³ 2022年2月15日 (二) 01:36 (UTC)

我的理解是这个应该只规范客栈提案（即，提案提出来了才这样做），否则我们相当于禁止未经公告的事实性修订，这个既不现实，又可能导致bulletin变成垃圾场。 ——魔琴 [ 留言 贡献 ] 2022年2月15日 (二) 02:03 (UTC)

此擬議修改牽涉以下修改：

• 序號修改：原2至4→8至10，原5至10→2至7（1、11至13序號不變）；
• 於新第8項（原2）前加入“此外，用戶頁上亦不能放置：”句；

以上。Sanmosa _A-DWY³ 2022年2月15日 (二) 01:45 (UTC)

@Hijk910。Sanmosa _A-DWY³ 2022年2月15日 (二) 01:47 (UTC)

我觉得这个很明显了，一望而知。版本差异功能没有那么智能，要习惯 囧rz…… ——魔琴 [ 留言 贡献 ] 2022年2月15日 (二) 02:00 (UTC)

謝謝多位，我沒有問題了。打擾了。－hiJK910 ^{走先喇 係咁先喇 下次再玩吖} 2022年2月15日 (二) 09:52 (UTC)

有加anchor就代表有人用過連結或用使用者頁面指引第XX條來指稱特定準則，調整序號順序並不適當。--Xiplus#Talk 2022年2月22日 (二) 04:59 (UTC)

建議限制內容翻譯

由於內容翻譯工具中有以下問題：

1. 翻譯拙劣；以及
2. 原文有問題（例如{{refimprove}}）但是翻譯版未解決問題，

因此提請限制內容翻譯工具（以致所有翻譯），有以下方案：

1. 內容翻譯只允許自動確認用戶使用；
2. 內容翻譯只可以發布到草稿以及用戶空間，並需經AFC（利益衝突：絕對絕對不是為AFC登廣告攢業績）；
3. 完全禁用內容翻譯；或
4. 以上任一方案（禁用方案除外），但擴展至任何翻譯；
5. 以上任一方案，但擴展至延伸確認用戶或只限制非延伸確認用戶。

以上。 Wiki emoji | 😷🅔🅜🅞🅙🅘🅦🅘🅚🅘😷 _{祝百毒不侵～} 2022年2月20日 (日) 04:38 (UTC)

註：此處原有文字，因為無助於討論且令人反感，已由SunAfterRain（留言）於2022年2月28日 (一) 10:06 (UTC)刪除，尚祈見諒。若有異議請至互助客棧或向管理員反映。

Wiki emoji | 😷🅔🅜🅞🅙🅘🅦🅘🅚🅘😷 _{祝百毒不侵～} 2022年2月20日 (日) 04:48 (UTC)

內容翻譯工具的使用體驗我給0分，且翻譯外語版本時不應該將外語版本的問題內容一起翻過來（但內容翻譯工具似乎默認必須全部翻譯？）。--🎋🎍 2022年2月20日 (日) 05:30 (UTC)

內容翻譯工具虽然有些难用，但是我自己用起来觉得还是很有帮助的，至少我用起来比不用內容翻譯工具的情况下，翻译效率明显要高。所以在我看来这只是如何用的问题，而不是用不用的问题。如果非要限制使用，那么我更倾向于“只可以發布到草稿以及用戶空間”这一条（不含AFC）--百無一用是書生 (☎) 2022年2月21日 (一) 02:45 (UTC)

沒有AFC等審核機制相當于無用，因為翻譯者大可立刻移動。 Wiki emoji | 😷🅔🅜🅞🅙🅘🅦🅘🅚🅘😷 _{祝百毒不侵～} 2022年2月26日 (六) 00:00 (UTC)

翻譯者改善完移動到條目空間有什麼問題？為什麼要強制移動到AFC？內容翻譯完的確需要改善一下，因為會出現一些奇怪問題，比如來源之間會有多餘空格。Wiki emoji以為這裡是英維嗎？強制AFC，什麼時候中維有英維那樣的編輯人數再說。--中文維基百科20021024（留言） 2022年2月28日 (一) 08:50 (UTC)

內容翻譯工具根本就沒規定要全部翻譯。（到底用沒用過啊？）--中文維基百科20021024（留言） 2022年2月28日 (一) 08:51 (UTC)

加个提议 5.内容翻译只允许延伸确认用户使用。倾向于支持2和5.  ——魔琴 [ 留言 贡献 ] 2022年2月21日 (一) 03:50 (UTC)

可以考虑开启投票。有关内容翻译的相关统计数据，可参见Special:内容翻译统计。--Steven Sun（留言） 2022年2月22日 (二) 03:46 (UTC)

修改一下Emojiwiki的提議：

1. 內容翻譯只允許自動確認用戶，或只允許延伸用戶使用
2. 建議內容翻譯先發布到草稿以及用戶空間，或者乾脆禁止發佈到條目空間，並需經AFC（利益衝突：絕對絕對不是為AFC登廣告攢業績）；
3. 完全禁用內容翻譯

--中文維基百科20021024（留言） 2022年2月28日 (一) 09:03 (UTC)

補充一下，在草稿或用戶空間使用內容翻譯會好一點，可能不用觸碰到太多的過濾器。--中文維基百科20021024（留言） 2022年2月28日 (一) 09:05 (UTC)

內容翻譯中的過濾器有著它觸發的奇怪原理（及顯示），不一定目標指向那裡就能避開--SunAfterRain 2022年2月28日 (一) 10:05 (UTC)

建議Emojiwiki先在用戶空間多試試內容翻譯再說，不要人云亦云。某人在telegram因為討厭內容翻譯，只看到缺點，妄圖搞一刀切和禁用。--中文維基百科20021024（留言） 2022年2月28日 (一) 09:08 (UTC)

 吐槽，這問題已經被提及很多次了，並非完全沒有意義，另請不要隱射任何人（我是不知道是誰就是了啦）--SunAfterRain 2022年2月28日 (一) 10:11 (UTC)

提議新建交通車輛條目內容方針2

本指引為交通車輛條目內容方針，統一格式將有助於閱讀及編輯維護上的便利性，以及減少特定章節的編輯戰，目的是幫助編者建立具有一致性的條目作品。

行文結構

鐵路車輛

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

客運/公車車輛

• 導言：簡述車輛製造商、車輛類型等，並精要概括正文。
• 資訊框：一般用用{{Infobox Automobile}}。模版應照文檔填寫。
• 概要：介紹車輛引進緣由、退役緣由（如已除役之車輛）、基本概述等。
• 相關條目：與條目相關的車型或車種可於此列出。
• 參考文獻：請列明來源！
• 外部連結：可連接其他維基計畫或是未達可靠來源門檻的百科性資源。

條目內容

不合適的內容

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

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

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

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

3. 過多的圖片：請勿於條目內放置各車號的照片，於資訊框模板一張代表即可，其他照片則放入共享資源並於底下納入共享資源連結導引。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

停用模板ConfirmationVRT

此模板在几乎一切情况下可以由{{PermissionTicket}}替代，维护两个模板并不会带来额外的好处且易造成混淆；其中的source参数某种意义上透露了工单内无必要公开的信息。这个东西应该发到VRT公告板，但是众所周知那个板块长期根本没人看，于是就丢到这里来了。-- Stang^★ 2022年2月20日 (日) 14:03 (UTC)

我的理解，两个模板一个是用在条目对话页，一个是用在文件描述页--百無一用是書生 (☎) 2022年2月21日 (一) 02:48 (UTC)

看链入得知事实并非如此啊。 Stang^★ 2022年2月21日 (一) 08:36 (UTC)

这两个模板都是英文引入的，原始用法就是如此。只是到了中文这边没人在乎，就乱了--百無一用是書生 (☎) 2022年2月22日 (二) 02:06 (UTC)

调整Wikipedia:非原创研究部分条文

現行條文 维基百科不是存放原创研究或原创观念的场所。在維基百科裡所谓原创研究或原创观念，指的是未发表的事实、争论、觀點、推论和想法；以及对已发表材料进行的未发表分析或总结，并产生了新的立场。以上意味着维基百科不是存放您的个人观点、经验或争论的场所。 （略） 来源 在本方针与另两大内容方针的限制下，对现有来源的内容进行收集与整理方面的研究是受到鼓励的：这样的研究是“基于来源的研究”，是撰写百科全书的基本功。但应注意，切勿超越来源中的表达，或者将来源用在与其本意不符的场合，譬如撰写与来源上下文无关的内容。简而言之，我们应该照着来源写。 如果没有可靠的第三方来源来支持某个主题，关于这一主题的条目不应出现在维基百科上。 （略） 对已发表材料的总结并提出立场 切勿对多个来源的信息进行综合，假若综合后的结论并未由任何来源明确提及。编辑者不应犯下这样的错误：因为A发表于可靠来源，B也发表于可靠来源，因此就可以在条目中将A和B综合起来得出结论C。这等同于原创研究，因为这是对已发表材料的总结，会产生新的立场。“因为A和B，所以C”只有在可靠来源也发表了与C相同的主张，且C主张与条目主题相关时才能出现。 仔细地对来源内容进行不改变原意的概括或改述并不构成原创总结——反而是应受鼓励的做法。写作维基百科条目的最好做法，是去研究大量与主题相关的可靠已发表来源，并用自己的话来概括其中的主张，让每一主张都能被归属到明确作过此等主张的来源去。

提議條文 维基百科不是存放原创研究或原创观念的场所。在維基百科裡所谓原创研究或原创观念，指的是未发表的事实、争论、觀點、推论和想法；以及对已发表材料进行的未发表分析、综合或总结，并产生或暗示新的结论。以上意味着维基百科不是存放您的个人观点、经验或争论的场所。 （略） 来源 维基百科建立在对可靠来源的收集和整理之上。如果没有可靠的第三方来源来支持某个主题，关于这一主题的条目不应出现在维基百科上。维基百科不是发表编者个人新发现的地方。 最好的做法是去研究与主题相关的可靠已发表来源，并在不改变原意的前提下，用自己的话改写各个来源所说的内容，让条目中的每一主张都能被归属到明确作过此等主张的来源去。但应注意，切勿超越来源中的表达，或者将来源用在与其本意不符的场合，譬如撰写与来源上下文无关的内容。简而言之，我们应该照着来源写。 （略） 对已发表材料的综合 切勿汇集、综合多个来源的信息或单个来源中的不同部分，以得出或暗示并未由来源明确提及的结论。编辑者不应犯下这样的错误：因为A发表于可靠来源，B也发表于可靠来源，因此就可以在条目中将A和B综合起来得出或暗示结论C。这等同于原创研究，因为这是对已发表材料的不恰当综合或总结，会产生新的立场。“因为A和B，所以C”只有在可靠来源也发表了与C相同的主张，且C主张与条目主题相关时才能出现。如果A和B出现在同一个来源的不同上下文处，但该来源没有将它们联系起来并论证得到结论C，则编者不应该在条目中采用C。

参考資料

原条文中部分表述——“产生新的立场”、“基于来源的研究”、“提出立场”、“不改变原意的概括或改述并不构成原创总结”等——有一定含混性。一些编者会综合多个来源作未发表的分析或总结，或者单纯罗列与条目主题无关的来源来表达暗示，并援引以上条文作为辩护。因此，提议调整部分条文。--Jhstriver（留言） 2022年2月21日 (一) 02:43 (UTC)

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

@Jhstriver：我覺得“对已发表材料的综合”可以再進一步簡化為“综合已发表材料”，其他的我不反對。Sanmosa _A-DWY³ 2022年2月21日 (一) 13:33 (UTC)

有道理，之后的公示版本会修改，感谢建议。--Jhstriver（留言） 2022年2月22日 (二) 05:44 (UTC)

有關模板的刪除理由

此前討論將《刪除方針》中的第9項刪除理由由“多餘無用的模板”更改為“多餘無用，且影響其他模板命名或者百科運作的模板”，然而此更改導致了部分用戶濫建重複模板的情形（其中一個例子），因此我認為有必要重新調整可刪除模板的情形。現提案如下：

現行條文 多餘無用，且影響其他模板命名或者百科運作的模板

提議條文 多餘無用、影響其他模板命名或影響維基百科運作的模板

以上。Sanmosa _A-DWY³ 2022年2月21日 (一) 13:31 (UTC)

@Ericliu1912。Sanmosa _A-DWY³ 2022年2月21日 (一) 13:31 (UTC)

行。另外百科應該可以寫全成維基百科吧。—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年2月21日 (一) 15:11 (UTC)

完成。Sanmosa _A-DWY³ 2022年2月22日 (二) 08:54 (UTC)

兼ping原案推動者@Bluedeck閣下。—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年2月21日 (一) 15:18 (UTC)

倾向同意，但是要确保无链入不是模板的删除理由，提删时要提出说明证明其多余无用。另同Ericliu1912，应写成维基百科。桐生ここ★[讨论] 2022年2月21日 (一) 20:02 (UTC)

會設這個限制還不是因為有人亂提刪模板，不少模板以subst方式使用，本來就不會有固定的引用數，就有人不懂模板運作原理又看到這個規則就直接以多餘無用提刪，試問這個問題怎麼解決？是否在該準則內詳細說明多餘無用的定義，例如「0引用」不等於「無用」。--Xiplus#Talk 2022年2月22日 (二) 05:55 (UTC)

@桐生ここ、Xiplus：或許我這樣理解：「0引用」的模板與「無用」的模板是兩個集，兩者有重複的地方，但不是同一個集。我覺得可以加一個註釋說“無引用的模板不一定為無用的模板”之類的，但我不太能想到一個合適的説法，不知道在這方面能不能幫一下忙。Sanmosa _A-DWY³ 2022年2月22日 (二) 08:53 (UTC)

如果无用与未使用可能存在部分重叠意思，或者可以换个无歧义的无意义？--Kethyga（留言） 2022年2月23日 (三) 04:22 (UTC)

“無意義”反倒是另一個意思了。現在的問題在於“無用”與“未使用”只是部分重疊，但有人誤解成完全重疊，所以只要弄一個説明解決這個問題就可以了。--Sanmosa _A-DWY³ 2022年2月23日 (三) 07:57 (UTC)

• 我記得bluedeck的觀點是，一些模版即使沒有用途，但當中的技術依然對其他人有參考價值。--Temp3600（留言） 2022年2月23日 (三) 14:52 (UTC)

  問題在於這種情況實屬少數，我倒是想知道{{Ping4}}的“技術”的參考價值何在？“技術”的參考價值需要足夠大才能成為保留理由，而不能單單因為“技術”的參考價值存在而成為保留理由。Sanmosa _A-DWY³ 2022年2月24日 (四) 07:10 (UTC)

  我覺得每個人的模板使用習慣都不同，同樣功能的{{Jp}}、{{jpn}}、{{nihongo}}，也一直存在，其實Ping4又不會影響其他用戶，因為這個模板的參數一般都不要修正的，其實有什麼所謂？--Ghren🐦🕓 2022年2月24日 (四) 08:10 (UTC)

  @Ghrenghren：嗯，我建議你先看一看Template talk:Jp#建议将Template:Jpn、Template:Nihongo、Template:Japanese-horizontal、Template:Jp合并（{{Japanese-horizontal}}直接併入{{jpn}}，{{jp}}成為{{jpn}}的定製資料盒）。Sanmosa _A-DWY³ 2022年2月26日 (六) 08:06 (UTC)

  我覺得定制資料盒的使用上來說，即使是定制了但依然是兩個模板。而假如有一定的使用人群的話就不能算作是多餘的模板。我不覺得ping4的使用上會比{{Vgnameq-nb}}這類型的低。我只是覺得要尊重他人使用習慣而己。--Ghren🐦🕓 2022年2月26日 (六) 09:26 (UTC)

明确如何处理真实姓名作为用户名的情况

現行條文 如果您的真名被封禁，敬請見諒。我們這樣做是要避免您的身分被偽冒。我們歡迎您使用您的真名，但在某些個案中，您可能需要證明您確實使用真實姓名參與維基百科。

提議條文 如果您的真名被封禁，敬請見諒。我們這樣做是要避免您的身分被偽冒。我們歡迎您使用您的真名，但在某些個案中，您可能需要发送邮件至info-zhwikimedia.org，附带相关的身份验证资料以证明您是这位知名人士本人。

参考了commons的做法，明确如果出现知名人士以真实姓名参与时如何验证身份。 Stang^★ 2022年2月21日 (一) 15:35 (UTC)

(＋)支持：另外也需要考虑有些名人只需要在微博、Twitter、Facebook之类的可以用证明其身份的认证帐号发一个帖，就可以证明其姓名，所以“身份验证资料”包含这种方式。桐生ここ★[讨论] 2022年2月21日 (一) 19:54 (UTC)

VRT还可以备份此类申报资料。鉴于站外内容无法控制是否日后删除，不建议单独允许站外方式。-Mys_721tx（留言） 2022年2月21日 (一) 21:25 (UTC)

没错。桐生ここ★[讨论] 2022年2月22日 (二) 03:24 (UTC)

如果是被封鎖要申訴的話，為什麼不是寄到unblock-zh？--Xiplus#Talk 2022年2月22日 (二) 03:33 (UTC)

需要隔离除姓名外可以验证身份的非公开数据。-Mys_721tx（留言） 2022年2月22日 (二) 04:07 (UTC)

unblock-zh裡面也一堆非公開數據...--Xiplus#Talk 2022年2月22日 (二) 04:44 (UTC)

unblock-zh中不能有身份证等证件级别的非公开数据。-Mys_721tx（留言） 2022年2月22日 (二) 20:52 (UTC)

“收信系统看不到图片，请用文字陈述”。 Stang^★ 2022年2月22日 (二) 05:25 (UTC)

實際上這個問題在遷移到hyperkitty後有所改善，我也很想要unblock-zh能轉移到VRT啊。--Xiplus#Talk 2022年2月22日 (二) 05:40 (UTC)

贵unblock-zh完全可以跟VRT相并列啊，这里用“转移”一词是不是有点不妥。不过这离题了。 Stang^★ 2022年2月22日 (二) 13:16 (UTC)

提议取消档案移动员 2

走完多年前的流程。一点答疑：

• 大量上次提案的反对原因在于“朝令夕改”；
• “如果档案管理员过了几个月真的无人申请”：Wikipedia:權限申請/申請檔案移動權内年均通过量少于2个；
• “需求少”：2021年全年共有561次文件移动，这个量看上去与move相比算很小的，且大多数都由非档案移动员执行；
• 其他用户组替代：先前有过允许所有自动确认用户执行操作的讨论，目前认为已经成熟。
• “自动确认用户的门槛太低了”：请论证移动文件相比于移动普通页面的额外危害；一名注册用户变成自动确认用户的时候可没有弹一个框让“请确认您已知晓何时不能移动页面”吧。

提案：

• 允许所有自动确认用户移动文件；
• 改写文件移动方针；
• 删除“filemover”组。 Stang^★ 2022年2月21日 (一) 21:48 (UTC)

emmm...在讨论结束之前来个管理员把权限给我好不好 囧rz……--在下荷花，请多指教（欢迎签到） 2022年2月22日 (二) 02:05 (UTC)

移动文件造成的问题主要是不留重定向移动后，如果不修改使用了文件的页面，会造成图片链接损坏。所以自动确认的话，的确是个风险。如果基本没人用这个权限，那就取消掉好了--百無一用是書生 (☎) 2022年2月22日 (二) 02:10 (UTC)

自動確認並不會擁有不留重新導向權限。--Xiplus#Talk 2022年2月22日 (二) 03:35 (UTC)

“自動確認並不會擁有不留重新導向權限。”这样的话，如果有需要不留重定向移动，就又是个问题--百無一用是書生 (☎) 2022年2月22日 (二) 04:01 (UTC)

G8删重定向页。--在下荷花，请多指教（欢迎签到） 2022年2月22日 (二) 04:03 (UTC)

诶等等不应该R6吗，方针该改了。--在下荷花，请多指教（欢迎签到） 2022年2月22日 (二) 04:08 (UTC)

如果某個檔案依據WP:FNC#9進行移動，在所有連結都更新完成後，請在遺留下來的重定向頁面放上G8

桐生ここ★[讨论] 2022年2月22日 (二) 04:21 (UTC)

然而G8现在不能由非管理员放.--在下荷花，请多指教（欢迎签到） 2022年2月22日 (二) 04:24 (UTC)

Template talk:Delete#關於快速刪除G8供参考，方针恐怕得改了。--在下荷花，请多指教（欢迎签到） 2022年2月22日 (二) 04:27 (UTC)

是啊，我去提案。桐生ここ★[讨论] 2022年2月22日 (二) 04:40 (UTC)

話說有WP:R6又有WP:FILEREDIRECT，那麼一個不屬於WP:FNC#不能接受的圖像名稱，但屬於WP:FMV/W的文件，是應該留下重定向，還是不留下重定向。桐生ここ★[讨论] 2022年2月22日 (二) 04:33 (UTC)

这也是问题，我觉得该留，但实际操作中很多人不留，我看英维好像是留的。--在下荷花，请多指教（欢迎签到） 2022年2月22日 (二) 08:28 (UTC)

给个参考，在commons除非为了改善明显不当的文件名称，否则禁止suppressredirect。 Stang^★ 2022年2月22日 (二) 05:27 (UTC)

同书生，给自确有风险；但不认因为有必要取消，权限组留着也不会破坏什么，或者造成什么不好的问题。如果提议回退员或巡免或延伸确认有filemover可以考虑。桐生ここ★[讨论] 2022年2月22日 (二) 03:21 (UTC)

巡免有。。。--在下荷花，请多指教（欢迎签到） 2022年2月22日 (二) 04:01 (UTC)

一時忘了 囧rz……，巡免沒有的是不留重定向移動。桐生ここ★[讨论] 2022年2月22日 (二) 04:15 (UTC)

对的。--在下荷花，请多指教（欢迎签到） 2022年2月22日 (二) 04:19 (UTC)

考虑一下，我觉得可能可以考虑给延确。然后差不多就可以去掉权限组。--在下荷花，请多指教（欢迎签到） 2022年2月23日 (三) 04:07 (UTC)

	上任日	除權日	用權數
Sanmosa的移動日志	2021年9月23日	2022年2月1日	0
RyanCray的移動日志	2020年11月12日	2022年12月7日	17
Minorax 的移動日志	2019年7月13日	至今	1
TimWu007的移動日志	2019年10月28日	2020年8月11日	32
和平至上的移動日志	2018年6月13日	2018年6月17日	0
SD_hehua的移動日志	2022年2月22日	至今	67

更新于：2023年2月12日 (日) 10:09 (UTC)

• 用權數大概共計50次左右，就看大家覺得要不要了。Ghren🐦🕑 2022年2月22日 (二) 06:03 (UTC)

我除權的原因是我現在擁有的其他權限已經有同樣功能。我自己是沒意見，看其他人。Sanmosa _A-DWY³ 2022年2月22日 (二) 09:03 (UTC)

• 支持移除该组，因为申请拥有权力者太少，核心功能单一，且已有为数众多的其他常见（管理）组别人员拥有（巡查：190人、巡查豁免：261人、管理员：……不想查，这本来是分内事……）。鼓励将移动文件请求放到如条目探讨或求助版或其他讨论请求页上让其他用户处理，该组别功能比鸡肋还糟糕。——Sakamotosan路过围观 | 避免做作，免敬 2022年2月23日 (三) 01:24 (UTC)

  那你是说其他人不能拥有权限自己移动吗（？--在下荷花，请多指教（欢迎签到） 2022年2月23日 (三) 02:58 (UTC)

  追加一句，关于自动确认用户对文件移动的处理，我参考shizhao的说法。——Sakamotosan路过围观 | 避免做作，免敬 2022年2月23日 (三) 03:07 (UTC)

修改WP:FMV/W

G8改R6

事實性修訂，已執行。Sanmosa _A-DWY³ 2022年2月22日 (二) 09:05 (UTC)

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

---

現行條文 如果某個檔案依據WP:FNC#9進行移動，在所有連結都更新完成後，請在遺留下來的重定向頁面放上{{d|G8}}（檔案移動員），或是直接依據{{d|G8}}的內容進行刪除（管理員）。更多資訊請參考快速刪除標準G8。

提議條文 如果某個檔案依據WP:FNC#9進行移動，在所有連結都更新完成後，請在遺留下來的重定向頁面放上{{d|R6}}（檔案移動員），或是直接依據{{d|R6}}的內容進行刪除（管理員）。更多資訊請參考快速刪除標準R6。

目前G8只能由管理员提出。 --桐生ここ★[讨论] 2022年2月22日 (二) 04:48 (UTC)

---

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

(？)異議：管理员能根据R6直接删除吗？ ——魔琴 [ 留言 贡献 ] 2022年2月23日 (三) 02:42 (UTC)

(：)回應我觉得移动不留重定向就好了。--在下荷花，请多指教（欢迎签到） 2022年2月23日 (三) 04:10 (UTC)

增加對有移動不留重新導向權限者的説明

还应该改的内容：有移动不留重定向权限者应直接不留重定向移动。--在下荷花，请多指教（欢迎签到） 2022年2月22日 (二) 08:26 (UTC)

(＋)支持。Sanmosa _A-DWY³ 2022年2月22日 (二) 09:05 (UTC)

Wikipedia:管理員

當中提及：

管理員不應該在一項事宜中使用普通用戶和管理員的雙重身份，而應該要麼使用普通用戶的身份，要麼使用管理員的身份，儘管用戶是同一個人。在以下場合的具體限制有：

保護：管理員不應該保護/解除保護他們牽扯進去的頁面，而應該像普通用戶一樣求助於其他管理員，這些頁面不包括諸如主頁等的常見保護頁面；

封禁：管理員不得僅因某用戶反對自己而封禁這個用戶；

刪除：管理員不得刪除自己提議刪除或者投票刪除的頁面；

在以上情況下，管理員應該以普通用戶的身份要求其他管理員協助。

但我覺得管理員應該可以刪除自己提議的O1、G10快速刪除，因為這樣通常不會對維基百科造成太大影響，也公平。
請各位在下面討論一下。Choi Chin Long 2022年2月22日 (二) 10:04 (UTC)

请允许我直接引用两条五大支柱：在不引起争议时，任何改善（或保护）维基百科的行为都没有太大问题--Kegns（留言） 2022年2月22日 (二) 13:42 (UTC)

与文明方针有何联系？ Stang^★ 2022年2月22日 (二) 13:48 (UTC)

• 不要忽略其他维基人的立场与结论。--Kegns（留言） 2022年2月22日 (二) 13:56 (UTC)

• 這樣繞過了其他管理員審查有關CSD的常規程序。恕反對。--Temp3600（留言） 2022年2月22日 (二) 13:55 (UTC)

正常流程是用户先提删，后管理员进行删除，而第一步为普通用户操作，第二步为管理操作，所以一位管理员不能单独完成这两个步骤。--东风（留言） 2022年2月23日 (三) 03:39 (UTC)

其實O1目前管理都是自己刪掉的，用bot刪還是人手刪有什麼分別？--Ghren🐦🕛 2022年2月23日 (三) 04:19 (UTC)

Wikipedia:FILEREDIRECT和WP:R6是否冲突？

过往设立讨论：Wikipedia_talk:快速删除方针/存档8#快速删除方针修订：明显不恰当的

看起来R6是将移动的所有重定向都删除，而文件重定向方针则认为除WP:FNC#8外都不应删除，请问方针是否矛盾？--在下荷花，请多指教（欢迎签到） 2022年2月23日 (三) 04:29 (UTC)

WP:独立后的爱好者内容的原创研究

鉴于中维游戏类条目爱好者内容堆积的问题，需要一个比较好的解决办法。目前，这还是一个很不成熟的草案，需要大家帮助，谢谢。--Taeas --以上未簽名的留言由Taeas（討論｜貢獻）於2022年2月26日 (六) 11:07‎加入。

@Taeas：感谢您的思考。实际上Wikipedia:电子游戏条目指引对爱好者内容已经有了要求：

• NOTONLYFORGAMER － 维基百科不收录只对爱好者有意义的内容。如果一个内容对不打算入坑的读者没有帮助，那这个内容就不该存在于维基百科条目中。所以，最好的做法是直接清理的爱好者内容，而不是将不合格的内容迁移到其他条目。
• WP:VG/ROLE － 维基百科游戏类条目的重点是现实世界内容（设计历程、业界评价）。对于独立角色列表中，现实世界内容应占内容的1/3。当然如您所说，清理角色和设定列表工作量大，所以很多时候选择了分割条目的“清理”方式。但是这个分割出来的列表，其实品质其实也是不合格的。只是现在通常睁一只眼闭一只眼没处理，未来就不好说了。
• WP:VG#SETTINGLIST － 纯粹的设定/世界观列表的确是拒绝收录的。世界观类内容基本不会单开条目，不过若能写到这个水平另说。
• WP:VG#参考来源 － 「常识性内容」应该是指从游戏流程中可以直接获得的内容。这种内容的来源就是游戏本身，可以使用{{Cite video game}}引用。但不易遭受质疑的不加脚注问题也不大，所以编辑平时都不加ref。这种叫「有来源没引用」，不属于原创研究。

维基百科是综合性百科，介绍游戏设定是为了帮助非玩家了解游戏。要让非玩家快速聚焦重点，条目就要做到内容精悍，无法像游戏专题站那样深挖细节。当然粉丝内容确实对玩家有用，直接删除我也认为很可惜。我也尝试和维基教科书等站讨论内容迁移，希望能在姊妹计划中保留内容。但很遗憾，粉丝类的确不适合写在维基百科这个网站。这类内容移走是对的，但迁移的目的地应该是其他网站，而不是维基百科其他条目。

另外电子游戏专题正在探讨虚构列表的写作方法，也欢迎您发表看法。--洛普利寧 2022年2月26日 (六) 11:51 (UTC)

很抱歉現行的方針沒有「適當的原創研究」，維基百科是講求可供查証而不是事實，你這些內容或者更為合適去萌娘或者維基學院甚至維基教科書。--Ghren🐦🕘 2022年2月26日 (六) 13:08 (UTC)

感谢@Ghrenghren和@Lopullinen的回复，将爱好者内容移至维基学院或维基教科书看起来是个很不错的方式！--Taeas（留言） 2022年2月26日 (六) 14:39 (UTC)

你可能詢問下相關的管理。我不太清楚你的內容具體是什麼。有些可以，有些不可以。--Ghren🐦🕙 2022年2月26日 (六) 14:44 (UTC)

如果针对拆分后的类似角色列表、设定列表等，还有Wikipedia:資料頁作为修订参考。当然我反对部分事无大小地列出对表现作品剧情没帮助的元素，或者说滥用分割页面，。——Sakamotosan路过围观 | 避免做作，免敬 2022年2月27日 (日) 09:37 (UTC)

限制RFA提问数量

为应对暂行安全投票的日程安排问题，拆分自管理人员选举制度改革。原提案者User:Ericliu1912。

修訂申請成為管理人員指引內容如下：

現行條文 參與方式 管理人員提名需要經過14天（即兩周）的投票。具人事任免投票資格的使用者可以投支持票、反對票或中立票，也可以僅發表意見、向候選人提問（候選人有權決定是否作答）。投票后票數會自動更新，如果發現錯誤可至此處手動更正票數。

提議條文 參與方式 管理人員提名需要經過14天（即兩周）的投票。具人事任免投票資格的使用者可以投支持票、反對票或中立票，也可以僅發表意見、向候選人提問（候選人有權決定是否作答）。就提問而言，每人最多可提問二題，並允許就提問開展相關討論；超過額度者，其問題將被直接刪除。禁止以多重問題或「小題」形式繞過限制，這樣將被視為遊戲維基規則。投票后票數會自動更新，如果發現錯誤可至此處手動更正票數。

鉴于原提案讨论中没有对提问数量限制提出明确的反对意见，故🕗 公示7日，2022年3月6日 (日) 02:02 (UTC) 結束。--Steven Sun（留言） 2022年2月27日 (日) 02:02 (UTC)

我想說中維的RFA問題和英維的問題根本是完全不同。中維的問題一向就是以快問快答的形式，問題短，答案也短。至現今的RFA，只有極少的參與者是真的可以做到只問兩條問題。然後，即使是不作制止，候選人依然去回答問題與否。以兩題的方式根本很難讓一個投票者去了解候選人本身，畢竟問一下會否活躍，選不選介管己經是兩條問題。我是想說，就算設這些限制，只是想問問題的人只會轉到Talk Page、電郵、TG其他地方問，然後這些情況就更難掌握。對於我而言只是削足適履的方案。此外，像User:Carrotkit/猴子孵育場這些應該怎樣算。這是六個分題，還是只是一個大問題？--Ghren🐦🕐 2022年2月27日 (日) 05:33 (UTC)

1. 候选人一般为社群较为活跃用户，在提名前社群一般就对候选人有大体的了解。不需要通过大量提问去从头了解候选人。况且问太多的低质问题，尤其是那些与维基百科无关的问题，同样也干扰投票者对候选人的认识。
2. 本指引应只限制投票页的提问数量。在其它地方提问只要不违反其它相关指引及方针即可（以前社群也没有在其它地方提问的习惯，而且不少人的讨论页也不经常回复别人）。但不能在投票页为其他页面的提问引流，否则视为绕过限制。--Steven Sun（留言） 2022年2月27日 (日) 08:13 (UTC)

   實際上當然是較為活躍的才可以被社群支持，但是提名本身是深入了解主張的行為。很多候選人沒有很具體的用戶論述，引致候選人雖然在某一方（比如專心在條目的用戶）很出色，但是對站務的主張卻可能不太具體的，只靠兩條發問實在難而得知具體立場。引流視作繞過規定基本上就只能(－)反对到底了。我想說低質問題就不應該回答。--Ghren🐦🕓 2022年2月27日 (日) 08:23 (UTC)

那得問多少題？幾百題是太過分了，你「問清楚」候選人的時候他也差不多要退選。引流這種「解壓縮」手段也是不怎麼可取，表面上一兩題，事實上得造成候選人數倍的負擔。—— Eric Liu _{創造は生命（留言．留名．學生會）} 2022年2月27日 (日) 15:52 (UTC)

 吐槽你至少也丟個幾天再公示吧 囧rz……--SunAfterRain 2022年2月28日 (一) 10:03 (UTC)