維基百科:互助客棧/方針

本頁使用了標題或全文手工轉換
維基百科，自由的百科全書
< Wikipedia:互助客栈

這是本頁的一個歷史版本，由Jimmy-bot（留言 | 貢獻）在2022年2月28日 (一) 16:14 （机器人: 1个讨论已移除，其中1个讨论已存档；已保留的讨论中0个已修改）編輯。這可能和目前版本存在著巨大的差異。

捷徑

此頁面探討維基百科的方針與指引。


請注重禮儀、遵守方針與指引，一般問題請至互助客棧其他區或知識問答提出，留言後請務必簽名（點擊 ）。


發表前請先搜尋存檔，參考舊討論中的內容可節省您的時間。

議題最後回應時間為5月6日之前（正在公示者除外）或者該議題已經標記為結束達三日，則該議題會存檔至相關討論頁或存檔頁。討論存檔至相關討論頁後，相關討論標題則會於一日後存檔。跳至本頁的：目錄 · 底端

公告欄
# 💭 話題 💬 👥 🙋 最新發言 🕒 (UTC+8)
1 提議提高條目評選投票資格門檻 1 1 Sanmosa 2024-05-14 19:00
2 再擬議立國際關係命名常規為方針 49 10 Sanmosa 2024-05-12 22:19
3 修訂刪除方針明確允許刪除沒有來源30日以上的條目 54 9 August0422 2024-05-09 18:22
4 提議英維指引en: MOS:TVINTL經在地化後引入中維維基百科:格式手冊/電視 75 8 Milkypine 2024-05-16 22:33
5 提議：允許使用開放代理編輯WP:RFR，並在WP:RFR中加入「註冊帳號申請」 1 1 Sanmosa 2024-05-14 19:01
6 提議：對WP:日常計算做小修改 1 1 Sanmosa 2024-05-14 23:49
7 提議對中國大陸的文物保護單位設立關注度豁免 1 1 Sanmosa 2024-05-14 23:01
8 附帶有限追蹤檢查的無IP的IPBE 12 7 魔琴 2024-05-12 22:18
9 關於國籍的原創研究 19 7 Ericliu1912 2024-05-14 01:04
10 關於跨行政區域的實體，是否應該使用多個分類 15 6 克勞棣 2024-05-15 01:00
11 必須防止濫用「防濫用過濾器」 9 6 魔琴 2024-05-16 20:13
發言更新圖例
  • 最近一小時內
  • 最近一日內
  • 一週內
  • 一個月內
  • 逾一個月
特殊狀態
已移動至其他頁面
或完成討論之議題
手動設定
當列表出現異常時，
請先檢查設定是否有誤

正在廣泛徵求意見的議題

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

維基百科格式與命名

Template talk:Infobox person § 修改 Infobox person 中 native_name 參數位置

維基百科方針與指引

Wikipedia talk:共識 § 共識建立的遞進步驟

Wikipedia talk:關注度 (文化遺產) § 提議對中國大陸的文物保護單位設立關注度豁免

Wikipedia talk:關注度 (地理特徵) § 建議將地理特徵關注度指引中有關道路的部分改為在交通關注度指引中列出

Wikipedia talk:非原創研究 § 提議：對WP:日常計算做小修改

維基百科提議

Wikipedia talk:仲裁委員會 § RfC：2024年2月

Wikipedia talk:字詞轉換處理/公共轉換組 § 思路：條目預儲公共轉換組中匹配的規則，減少載入時間

Template talk:Twitter § Twitter改為X

Wikipedia:互助客棧/其他 § 對ITN獲選標準及ITNR的小修訂

Template talk:Hang on § {{hangon}}

條目主題
非條目主題
提示
要將某一個討論加入上述列表中：
  • 在討論頁中的對應討論章節頂端加上{{rfc|xxx}}標籤，其中「xxx」為分類縮寫。各類分類縮寫已列於上方項目中，並應將其插入{{rfc}}中。多個分類請使用管道符號分開，如{{rfc|xxx|yyy}}，其中「xxx」為第一個分類，「yyy」為第二個分類。
更多資訊請參閱Wikipedia:徵求意見。請在Wikipedia talk:徵求意見回報有關錯誤。本列表由LuciferianBot於每個小時進行更新。

改革管理員的解任程序

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

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

管理人員選舉制度改革

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

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

提議調整人事任免投票門檻

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:人事任免投票資格。

（前十個方案由於無共識，現已存檔）

意見徵集

根據以上討論，現決定中止公示，但仍進行最後意見徵集。以問卷調查的方式進行：

  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)[回覆]
不同意移除「兩項之至少一項」，這兩項之中都有「且/或」連接詞，不是所有人都很清楚且跟或的優先順序，能轉為條列式就應該轉為條列式，並使用「以下條件之一」的構句來讓條件更加清晰易讀。--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)[回覆]

方案十三

現行條文

凡管理人員解任投票聯署或上任投票開始之前，註冊滿七天且符合以下兩項之至少一項條件者有權投票：

  1. 解任投票聯署提出或上任投票開始120天前，編輯至少500次；並在聯署提出或上任投票開始前90天內至少有1次編輯（不包括任何使用者頁面及使用者對話頁）；
  2. 編輯至少3000次，或編輯條目至少1500次。

以上所稱「編輯」，均指在中文維基百科的編輯，不含明顯的破壞和測試。

提議條文

凡管理人員解任投票聯署或上任投票開始之前，符合以下三項之至少一項條件者有權投票：

  1. 解任投票聯署提出或上任投票開始120天前，編輯至少500次；並在聯署提出或上任投票開始前90天內至少有1次編輯（不包括任何使用者頁面及使用者對話頁）；
  2. 註冊滿七天，編輯至少3000次，並在聯署提出或上任投票開始前210天內至少有1次編輯；
  3. 註冊滿七天，編輯條目至少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 [回覆]
  • 最近因為有事，沒有時間回復大家的意見，這些意見我也看過了，絕大部分是反對，而且反對的理由也很荒謬：「賦予編輯超1500次的非自動確認使用者投票權」，標題也不知道被誰改成了「方案十四」。請問你們見過哪個新使用者能在7天內編輯1500次（平均每天編輯214次），還能保證這1500個編輯全都是條目，而且恰好是投票前7天內作出的，而且全都是實質性編輯，沒有一個破壞或測試？根據WP:最近編輯次數最多的使用者統計，只有3個非機器人使用者最近一周內編輯超過1500次，而且表中所有使用者均為自動確認使用者。大家可以自己找一下歷史上有沒有符合上述所有條件的使用者，如果有的話可以在下面留言。假如真有這種使用者，那麼管理員難道不會以WP:遊戲維基規則封鎖之？希望大家認真思考這幾個問題，當然也可以討論，我先把上面的公示去掉，如果沒有意見的話，我再公示。--12З4567（留言） 2022年2月25日 (五) 04:35 (UTC)[回覆]

第三次推動設立LTA命名空間

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:命名空間/2021年設立新命名空間及偽命名空間。

由於今年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. 將英文字母和數字結合，持續延伸，列舉流水號樣式如下：
可無限延伸，若真有需要的一天（笑）。個人意見，供參。--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)[回覆]
不知道是不是應該回復在這兒。這個擴展提供的限制非常雞肋，您只需要在其他命名空間建立一個指向私有的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……--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)[回覆]

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

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

社群日前進行投票表決通過，決定「在未來一場管理員選舉使用安全投票（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)[回覆]
同意。禁止討論怎麼看怎麼不現實。 ——魔琴 [ 已經告假 留言 貢獻 ] 2022年1月14日 (五) 15:57 (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)[回覆]


那暫定提問期為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 talk:格式手冊/旗幟。

一、Wikipedia:格式手冊/旗幟#旗幟圖案不用於強調國籍目的和Wikipedia:格式手冊/旗幟#有利於讀者閱讀，而非裝飾用途的規定對資訊框是否有效。目前普遍存在資訊框國家用國旗（甚至連清朝都有旗幟），黨派用黨旗（比如驢象代表民主共和兩黨），美國總統前面要加個，還有各種軍階、將星，電影產地要加{{美國電影}}{{英國電影}}{{日本電影}}；

二、上面舉的例子如、軍階、{{美國電影}}{{英國電影}}{{日本電影}}這些是否應該視為旗帷，因為有使用者明確主張 美國是國旗模板，但 美國不是國旗模板，

三、個人認為如果確定國旗可以在資訊框使用，宗教旗幟、州旗、市旗、家族盾徽、黨旗、軍階、國璽都沒有理由限制，那麼Wikipedia:格式手冊/旗幟#不要使用太多的旗幟如何裁量，多少算「太多」？

我個人立場認為應該對資訊框使用旗幟設限，除非能證明加個旗幟不止「裝飾用途」，不會起「強調國籍」的效果，否則就不應該加。漢語讀者不可能看到「國籍：美國」後不知道是美國，要看到「國籍： 美國」才知道，讀者也不會看到「民主黨」不知道是民主黨，要在前面加頭動物才知道。電影「產地：美國」自然就說明是美國電影，「產地： 美國」除了裝飾、轉移讀者注意力實在想不出還有什麼作用。--7（留言） 2022年1月11日 (二) 09:22 (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-DWY3 2022年1月23日 (日) 04:27 (UTC)[回覆]
如果「人物infobox」還有爭議，那麼大家能否認同「非人物infobox」不用國旗呢？比如，地址、黨旗、格羅弗·克利夫蘭，還有上面所謂的「電影產地模板」？我提議刪除所有電影產地模板。非要用國旗的就直接 美國，不要拿什麼 美國來做文字遊戲。--7（留言） 2022年2月1日 (二) 08:56 (UTC)[回覆]
我覺得還有一點可以探討的是Navbox用國旗模板到底是不是有問題的，我提案當時的討論中也有人提過這點。如果可行的話，我很建議把Navbox也一同管制。Sanmosa A-DWY3 2022年2月1日 (二) 12:29 (UTC)[回覆]
@Jarodalien：要提醒的一點是enwiki存在國歌Infobox使用國旗模板的例子，例如en:State Anthem of the Soviet Union。--Sanmosa A-DWY3 2022年2月1日 (二) 12:33 (UTC)[回覆]
要按中維的習慣，List of successors那裡也會出現一堆flag……--洛普利寧 2022年2月1日 (二) 15:44 (UTC)[回覆]

意見徵集

1. Wikipedia:格式手冊/旗幟下各項規定對資訊框和正文同樣適用，除非有其他明確規則（如體育、軍事類），否則資訊框和正文表格都不能使用國旗；
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-DWY3 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：您誇張了。我的建議條文如下：
提議條文

何時適合在條目中使用旗幟和徽章等圖標？ 使用時機

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

易讀、可用與可辨識 ...

這個版本只改了一小部分，先看看？--路西法人𖤐 2022年2月28日 (一) 06:06 (UTC)[回覆]
噢還有，這個版本簡單而言就是使 中國大陸和 臺灣不應被使用--路西法人𖤐 2022年2月28日 (一) 07:43 (UTC)[回覆]

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

原標題為：Zh.WP checkuser re-introduction/重新匯入中文維基使用者查核權限

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:使用者查核、Wikipedia talk:使用者查核請求、Wikipedia talk:使用者查核方針、Wikipedia talk:申請成為管理人員。

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)[回覆]

「當選之使用者查核員任期為兩年，在任期結束後必須要再度重新參與選舉，通過秘密投票來延長任期....」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)[回覆]
我想請問訓練將在哪進行，以及訓練一名使用者查核員需要多長時間。--BlackShadowG（留言） 2022年1月17日 (一) 00:21 (UTC)[回覆]

對於重新引入不報希望，即便引入也是CU員難產。桐生ここ★[討論] 2022年1月18日 (二) 05:11 (UTC)[回覆]

  • 如果已經明確計劃好要恢復查核員，那對於無法簽署NDA的大陸使用者應該會造成更大規模的（無論主觀或客觀）歧視與不公平現象。畢竟曾經出現過
這種話，而現在大陸使用者連監督員都無法擔任。--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)[回覆]
就監管員吧，申訴專員處理效率肯定沒監管員好，不過可能要先問監管員願不願意。照規定來說，監管員不能處理有本地查核員的查核請求。--（☎） 2022年1月22日 (六) 18:32 (UTC)[回覆]
個人認為基金會會推動本地CU建立，然後到時監管員就不用管咱的CU請求了。除非有人跟基金會討論過可不可以維持現狀，不然我覺得樓上提的關於CU的問題要面對只是早晚而已。--（☎） 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)[回覆]

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

增修標點符號格式手冊

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:格式手冊/標點符號。

建議在標點符號格式手冊增修有關示亡號的使用，規範示亡號僅用作在列表中（包括點列式、表格或資訊框內）標記當前文字所表述的時間環境下此人已經逝世，例如在長壽節目製作播出期間演員或製作人員逝世，或是獎項追頒。{{金鐘獎特別貢獻獎}}、{{新聞聯播播音員}}屬於合理使用示亡號的例子，而{{大紫荊勳章}}的例子就屬於濫用。--路西法人☆ 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)之前加入的。[回覆]

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

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:典範條目評選、Wikipedia talk:優良條目評選。

這討論曾建議本身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)[回覆]

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

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

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

統一WP:RFR權限不活躍時間

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:解除權限方針、Wikipedia talk:模板編輯員、Wikipedia talk:大量訊息發送者、Wikipedia talk:大量帳號建立者、Wikipedia talk:檔案移動員、Wikipedia talk:巡查豁免權。

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

當超過六個月沒有任何編輯活動，在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-DWY3 2022年2月2日 (三) 07:17 (UTC)[回覆]
比如帳號失竊大量建立破壞條目被自動巡查，使得巡查員不能及時發現？機器使用者是Flood，機器人Bot的不活躍期限已經是一年。桐生ここ★[討論] 2022年2月2日 (三) 07:24 (UTC)[回覆]
那我不反對為巡查豁免者設定不活躍除權機制。--Sanmosa A-DWY3 2022年2月2日 (三) 10:34 (UTC)[回覆]
不能說完全沒有風險，端看您能想到該怎麼濫用這個權限，例如竊取巡查豁免者的帳號來建立難以發現的惡作劇條目之類的。--Xiplus#Talk 2022年2月2日 (三) 11:13 (UTC)[回覆]
所以我改了表態。感謝意見。--Sanmosa A-DWY3 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)[回覆]

提案

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:維基百科不是詞典嚴重滯後，請求按照現在的英文方針修改和擴充

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:維基百科不是詞典。

我在維基百科:頁面存廢討論/記錄/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，百科全書介紹紅土文化和司寇兩事物，詞典解釋「紅土文化」和「司寇」兩個詞。詞典要收定義不代表百科不能收定義，好的定義是應有的百科內容，可以保留，以待擴充。（當然若條目僅有差的定義，換言之無百科價值，仍應刪除。）——（留言） 2022年2月11日 (五) 00:28 (UTC)[回覆]
6/8Draft:Wikipedia:維基百科不是詞典——（留言） 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:保留。

以上，請求意見。——（留言） 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調整

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:使用者頁面。

WP:UPNOT的列舉項並非全是「與維基百科無關的內容」，存在邏輯矛盾。為此我做了這筆修改，未實際更動指引內容，但由於調整了順序，在此說明一下。--Lt2818（留言） 2022年2月13日 (日) 06:30 (UTC)[回覆]

  • 我改了什麼：把與「與維基百科無關的內容」無關的內容統一放在後面，前置「此外，使用者頁面上亦不能放置」之句。
  • 「取得社群共識再去修改」：未修改方針指引文意的編輯可直接進行。
  • 「修訂版本差別有夠難看」：可以不用看版本差別，直接對比前後兩個版本。
--Lt2818（留言） 2022年2月13日 (日) 09:22 (UTC)[回覆]
@Lt2818：Wikipedia:共識#微小修訂簡易規定：「如該提案……為對方針指引等規定的單純語法調整、錯別字更正或現實性對應調整（事實性修訂），且無人對相關修訂提案是否單純語法調整、錯別字更正或現實性對應調整（事實性修訂）提出合理質疑……該修訂提案可立即執行，而毋須跟從基本規定。該修訂提案獲立即執行後，應在{{Bulletin}}的「公告」欄位加入連結宣告該修訂已獲進行。」我認為Hijk910的留言可能具足有人「對相關修訂提案是否單純語法調整、錯別字更正或現實性對應調整（事實性修訂）提出合理質疑」的要件（但如確認並不具足，此提案則確然可以立即執行）。Sanmosa A-DWY3 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-DWY3 2022年2月15日 (二) 01:45 (UTC)[回覆]
@Hijk910。Sanmosa A-DWY3 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)[回覆]

精神分裂症使用者編輯

本主題全部或部分段落文字，已移動至Wikipedia:互助客棧/其他。執行人：Eric Liu 創造は生命（留言．留名．學生會） 2022年2月23日 (三) 06:13 (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

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

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

行文結構

鐵路車輛

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

客運/公車車輛

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

條目內容

不合適的內容

  1. 愛好者內容：
    • 鐵路車輛：請不要將車輛車次運用、車號機務段分配、改造期程、交車期程等瑣碎資訊加入條目內。
    • 客運/公車車輛：請勿將領牌車號、行駛路線、停靠站牌等瑣碎資訊加入條目內。
    依據：維基百科不是不經篩選的資訊收集處－說明書
  2. 大量的短條目：通常一個較大的條目能提供對主題更有條理的介紹與背景聯繫。當大條目能做到時，請不要建立大量小條目。理想的條目是既不過大，也不過小。
    依據：維基百科的條目大小指引
  3. 過多的圖片：請勿於條目內放置各車號的照片，於資訊框模板一張代表即可，其他照片則放入共享資源並於底下納入共享資源連結導引。

因討論被機器人存檔，且尚未完成討論故接續提案，部分內容已依照上次討論提議更新--🚊。鐵路Railway 論 2022年2月20日 (日) 05:24 (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:非原創研究部分條文

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:非原創研究。

現行條文

維基百科不是存放原創研究或原創觀念的場所。在維基百科裡所謂原創研究或原創觀念，指的是未發表的事實、爭論、觀點、推論和想法；以及對已發表材料進行的未發表分析或總結，並產生了新的立場。以上意味著維基百科不是存放您的個人觀點、經驗或爭論的場所。

（略） 來源 在本方針與另兩大內容方針的限制下，對現有來源的內容進行收集與整理方面的研究是受到鼓勵的：這樣的研究是「基於來源的研究」，是撰寫百科全書的基本功。但應注意，切勿超越來源中的表達，或者將來源用在與其本意不符的場合，譬如撰寫與來源上下文無關的內容。簡而言之，我們應該照著來源寫。

如果沒有可靠的第三方來源來支持某個主題，關於這一主題的條目不應出現在維基百科上。

（略）

對已發表材料的總結並提出立場

切勿對多個來源的資訊進行綜合，假若綜合後的結論並未由任何來源明確提及。編輯者不應犯下這樣的錯誤：因為A發表於可靠來源，B也發表於可靠來源，因此就可以在條目中將A和B綜合起來得出結論C。這等同於原創研究，因為這是對已發表材料的總結，會產生新的立場。[1]「因為A和B，所以C」只有在可靠來源也發表了與C相同的主張，且C主張與條目主題相關時才能出現。

仔細地對來源內容進行不改變原意的概括或改述並不構成原創總結——反而是應受鼓勵的做法。寫作維基百科條目的最好做法，是去研究大量與主題相關的可靠已發表來源，並用自己的話來概括其中的主張，讓每一主張都能被歸屬到明確作過此等主張的來源去。

提議條文

維基百科不是存放原創研究或原創觀念的場所。在維基百科裡所謂原創研究或原創觀念，指的是未發表的事實、爭論、觀點、推論和想法；以及對已發表材料進行的未發表分析、綜合或總結，並產生或暗示新的結論。以上意味著維基百科不是存放您的個人觀點、經驗或爭論的場所。

（略） 來源 維基百科建立在對可靠來源的收集和整理之上。如果沒有可靠的第三方來源來支持某個主題，關於這一主題的條目不應出現在維基百科上。維基百科不是發表編者個人新發現的地方。

最好的做法是去研究與主題相關的可靠已發表來源，並在不改變原意的前提下，用自己的話改寫各個來源所說的內容，讓條目中的每一主張都能被歸屬到明確作過此等主張的來源去。但應注意，切勿超越來源中的表達，或者將來源用在與其本意不符的場合，譬如撰寫與來源上下文無關的內容。簡而言之，我們應該照著來源寫。

（略）

對已發表材料的綜合

切勿匯集、綜合多個來源的資訊或單個來源中的不同部分，以得出或暗示並未由來源明確提及的結論。編輯者不應犯下這樣的錯誤：因為A發表於可靠來源，B也發表於可靠來源，因此就可以在條目中將A和B綜合起來得出或暗示結論C。這等同於原創研究，因為這是對已發表材料的不恰當綜合或總結，會產生新的立場。[2]「因為A和B，所以C」只有在可靠來源也發表了與C相同的主張，且C主張與條目主題相關時才能出現。如果A和B出現在同一個來源的不同上下文處，但該來源沒有將它們聯繫起來並論證得到結論C，則編者不應該在條目中採用C。

參考資料

  1. ^ 針對對歷史理論的總結，吉米·威爾士曾說過：「有些人可能完全理解維基百科不應根據實驗結果來發表新奇物理理論的要求，也理解我們不能根據它們總結出新的東西來，但卻往往忽視了這一點同樣適用於歷史方面。」（威爾斯，吉米．〈原創研究〉，2004年12月6日．原文：「Some who completely understand why Wikipedia ought not create novel theories of physics by citing the results of experiments and so on and synthesizing them into something new, may fail to see how the same thing applies to history.」）
  2. ^ 針對對歷史理論的總結，吉米·威爾士曾說過：「有些人可能完全理解維基百科不應根據實驗結果來發表新奇物理理論的要求，也理解我們不能根據它們總結出新的東西來，但卻往往忽視了這一點同樣適用於歷史方面。」（威爾斯，吉米．〈原創研究〉，2004年12月6日．原文：「Some who completely understand why Wikipedia ought not create novel theories of physics by citing the results of experiments and so on and synthesizing them into something new, may fail to see how the same thing applies to history.」）

原條文中部分表述——「產生新的立場」、「基於來源的研究」、「提出立場」、「不改變原意的概括或改述並不構成原創總結」等——有一定含混性。一些編者會綜合多個來源作未發表的分析或總結，或者單純羅列與條目主題無關的來源來表達暗示，並援引以上條文作為辯護。因此，提議調整部分條文。--Jhstriver（留言） 2022年2月21日 (一) 02:43 (UTC)[回覆]

支持。-Mys_721tx（留言） 2022年2月21日 (一) 03:54 (UTC)[回覆]
@Jhstriver：我覺得「對已發表材料的綜合」可以再進一步簡化為「綜合已發表材料」，其他的我不反對。Sanmosa A-DWY3 2022年2月21日 (一) 13:33 (UTC)[回覆]
有道理，之後的公示版本會修改，感謝建議。--Jhstriver（留言） 2022年2月22日 (二) 05:44 (UTC)[回覆]

有關模板的刪除理由

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

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

現行條文

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

提議條文

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

以上。Sanmosa A-DWY3 2022年2月21日 (一) 13:31 (UTC)[回覆]

@Ericliu1912。Sanmosa A-DWY3 2022年2月21日 (一) 13:31 (UTC)[回覆]
行。另外百科應該可以寫全成維基百科吧。—— Eric Liu 創造は生命（留言．留名．學生會） 2022年2月21日 (一) 15:11 (UTC)[回覆]
完成。Sanmosa A-DWY3 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-DWY3 2022年2月22日 (二) 08:53 (UTC)[回覆]
如果無用與未使用可能存在部分重疊意思，或者可以換個無歧義的無意義？--Kethyga（留言） 2022年2月23日 (三) 04:22 (UTC)[回覆]
「無意義」反倒是另一個意思了。現在的問題在於「無用」與「未使用」只是部分重疊，但有人誤解成完全重疊，所以只要弄一個説明解決這個問題就可以了。--Sanmosa A-DWY3 2022年2月23日 (三) 07:57 (UTC)[回覆]

明確如何處理真實姓名作為使用者名稱的情況

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:使用者名稱。

現行條文

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

提議條文

如果您的真名被封鎖，敬請見諒。我們這樣做是要避免您的身分被偽冒。我們歡迎您使用您的真名，但在某些個案中，您可能需要發送郵件至info-zh-hant@wikimedia.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 talk:檔案移動員。

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

  • 大量上次提案的反對原因在於「朝令夕改」；
  • 「如果檔案管理員過了幾個月真的無人申請」：Wikipedia:權限申請/申請檔案移動權內年均通過量少於2個；
  • 「需求少」：2021年全年共有561次檔案移動，這個量看上去與move相比算很小的，且大多數都由非檔案移動員執行；
  • 其他使用者群組替代：先前有過允許所有自動確認使用者執行操作的討論，目前認為已經成熟。
  • 「自動確認使用者的門檻太低了」：請論證移動檔案相比於移動普通頁面的額外危害；一名註冊使用者變成自動確認使用者的時候可沒有彈一個框讓「請確認您已知曉何時不能移動頁面」吧。

提案：

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)

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

修改WP:FMV/W

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

G8改R6

事實性修訂，已執行。Sanmosa A-DWY3 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-DWY3 2022年2月22日 (二) 09:05 (UTC)[回覆]

Wikipedia:管理員

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

當中提及： 

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

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

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

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

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

但我覺得管理員應該可以刪除自己提議的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)[回覆]
正常流程是使用者先提刪，後管理員進行刪除，而第一步為普通使用者操作，第二步為管理操作，所以一位管理員不能單獨完成這兩個步驟。--東風（留言） 2022年2月23日 (三) 03:39 (UTC)[回覆]
其實O1目前管理都是自己刪掉的，用bot刪還是人手刪有什麼分別？--Ghren🐦🕛 2022年2月23日 (三) 04:19 (UTC)[回覆]

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

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:檔案移動員、Wikipedia talk:快速刪除方針。

過往設立討論：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)[回覆]
取自「https://zh.wikipedia.org/w/index.php?title=Wikipedia:互助客栈/方针&oldid=70391087」