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

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

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

公告欄

• [人事] 請踴躍參與用户查核員選舉規定及人事任免投票提問環節規範之修訂事宜。
• [公告] 修改刪除方針第9項刪除理由、修改管理員的離任、修改CS1系列引文格式模板（第四阶段）：新增name-list-style和url-access参数、修改一級行政區道路特殊收錄限制列表及管理員安全投票選舉暫行規定正在公示，如有意見請盡快提出。
• [討論] 互助客栈方针區正在討論设立站务维基及修訂繁簡處理指引，請踴躍參與討論。
• [討論] 互助客栈技术區正在討論启用共享資源刪除通知機器人之事宜及调整绿链以免超过模板限制，請踴躍參與討論。
• [討論] 互助客栈其他區正在討論有关The Wiki的中立性问题，請踴躍參與討論。

• [協作] 现有63个页面需维基化，50个条目需清理，23个移动请求正在讨论。
• [獎勵] 現有1名用户獲提名维基奖励，欢迎投票。

#	話題	發言	參與	最新發言	最後更新(UTC+8)
1	就安全投票問題訂立管理員選舉暫行規定	102	13	Ghrenghren	2022-04-07 19:55
2	Zh.WP checkuser re-introduction／重新引入中文維基百科用戶查核權限	67	26	Antigng	2022-04-06 18:00
3	提議新建交通車輛條目內容方針2	81	17	鐵路1	2022-04-07 11:19
4	有關模板的刪除理由	103	12	Lt2818	2022-04-05 16:38
5	規範人事任免投票的提問環節	42	14	WPTO	2022-04-07 09:19
6	提議增設文化遺產關注度	53	6	Sanmosa	2022-03-29 20:03
7	WP:SIGN矛盾	57	12	A2569875	2022-03-29 21:18
8	设立站务维基	30	13	魔琴	2022-04-05 09:03
9	提议引入CSD:U5	23	12	魔琴	2022-04-05 09:12
10	绿链模板的用意，以及是否支持Wikidata？	13	6	YFdyh000	2022-04-03 17:29
11	提议为引用网络资源不填URL链接参数的行为设立警告或过滤器	10	6	Ghrenghren	2022-04-03 15:19
12	修改一級行政區道路特殊收錄限制列表	7	3	Ghrenghren	2022-04-07 13:32
13	修改Wikipedia:管理員的離任	23	7	Ghrenghren	2022-04-05 23:10
14	提議引入活動協調員	14	6	Stang	2022-04-04 23:49
15	假如有很簡潔扼要的方法能解決繁簡轉換問題，是否有必要特地使用複雜的手工轉換標籤？	80	21	LuciferianThomas	2022-04-06 12:19
16	Afd合併遺留重定向問題	18	9	Ghrenghren	2022-04-03 12:54
17	仅含虚构内容的独立角色条目的存废问题	85	15	Nickice	2022-04-07 22:10
18	提议Wikipedia:格式手册/虚构成为正式指引	36	9	Nostalgiacn	2022-03-31 23:38
19	修订可靠来源	5	3	Fire-and-Ice	2022-04-07 22:36
20	提議將过度分类的包含主观性的标准定為指引	7	6	BlackShadowG	2022-04-07 20:31
21	再议设立删除员	22	11	Ericliu1912	2022-04-08 00:30
22	关于中华民国籍香港居民	10	4	AT	2022-04-03 15:39
23	提议更换Mediawiki保护标志	13	9	BlackShadowG	2022-04-07 20:05
24	提议设立官方维基百科镜像供国内直连访问和编辑	52	18	BlackShadowG	2022-04-07 20:22
25	帶括弧重定向去留	9	8	Kethyga	2022-04-06 16:51
26	引入A7速刪	19	13	Temp3600	2022-04-07 17:52

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

---

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

社群日前進行投票表決通過，決定「在未來一場管理員選舉使用安全投票（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)

現在的問題是我們連方案什麼時候能喬好都不一定，何況去找監管員。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年3月13日 (日) 10:59 (UTC)

其實只需要依舊投14，討論14，達到方針原意就可以了。現在的情況可以達到這個目的，就不用改方案了。--Ghren🐦🕖 2022年3月13日 (日) 11:04 (UTC)

讓用戶自選時間，已經「應戰」得很吃力，如果是規定用戶在選舉期活躍，則必須縮減選舉本身的規模。--Temp3600（留言） 2022年3月13日 (日) 12:05 (UTC)

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

目前SecurePoll即将支持在投票时附加上可选的理由，中文社群可以考虑加上这一功能。 Stang^★ 2022年3月2日 (三) 17:26 (UTC)

『可選的理由』會否讓投票變成明票?--Temp3600（留言） 2022年3月13日 (日) 12:00 (UTC)

@Temp3600： 可參考UCoC投票，他們會將理由整合成摘要來避免辨識投票者的身份，理由只有監票員才可看到。--SCP-0000（留言） 2022年3月18日 (五) 08:39 (UTC)

---

所以現在有沒有任何可行的方案？我想我們需要先決定是否指定一段期間進行選舉（即不允許隨時展開），然後再據此決定時程。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年3月23日 (三) 16:41 (UTC)

達成目前討投14的目的的話，隨意即可。日期就隨意定為4月15號吧，反正這個日期具體來說什麼日子也沒所謂。--Ghren🐦🕐 2022年3月23日 (三) 17:19 (UTC)

不能隨意定，還要給社群時間提名人選。但我估計大家不可能只推選一個人，這樣得怎麼辦？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年3月23日 (三) 20:49 (UTC)

还要找合适的人选。--Lanwi1(留言) 2022年3月23日 (三) 22:02 (UTC)

現在的問題時沒有人想選（--1233 （T / C） 2022年3月29日 (二) 13:04 (UTC)

這不是問題。相信我。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年3月29日 (二) 15:47 (UTC)

這也不過是提前數天要求候選人要拿到一定的提名而己，然後不只一個人的話就只對最先得到足夠提名人數進行投票即可。我覺得實行上有很多種方法，然後實際上每一種差別實際上都不大，社群不應該為這些末節打轉三個月。--Ghren🐦🕙 2022年3月24日 (四) 02:45 (UTC)

---

• 本次投票以一人為限，以最先得到提名而且合符投票過程要求者的優先進行選舉，其他的押後至下一次；

• <s提名時間最早者或者；
• 抽籤；
• 最早得到七票（參考WP:RFDA）者，但提名票不直接算進票數，提名人的提名和投票取向不一定也不需要一致；

• 候選人應清楚說明是否參選界面管理員，如需要選票上應該另有一列一條問題；
• 選舉的關鍵日期應該預先決定以方便安排投票；
• 討論、提問的時間規定在14天，以得滿足提名條件且得行政員確認一刻起算作14天，14天結束後候選人依然可以回答問題，但不應該再展開討論，也不應該提出新問題；
• 投票時間起始點可以視乎準備人員需要提前或延後，討論時間不應該因此增加或減少；
• 參與準備工作的人員沒有投票權（應該要避嫌吧？）被選舉權。Ghren🐦🕛 2022年3月29日 (二) 16:48 (UTC)

不給被選舉權我覺得就可以了。--1233 （T / C） 2022年3月31日 (四) 13:28 (UTC)

我倒是沒有所謂。--Ghren🐦🕙 2022年3月31日 (四) 14:38 (UTC)

如果沒有意見的話，就按「最早得到七票」、「參與準備工作的人員有投票權但沒有被選舉權」的方案在3天後公示就好了。--Ghren🐦🕓 2022年4月3日 (日) 08:44 (UTC)

RfA已经不能兼RfIA了……要我说多少遍…… ——魔琴 [ 留言 贡献 ] 2022年4月3日 (日) 08:58 (UTC)

@魔琴似乎最初的目的之一是因為計票困難，但是在SPoll情況下根本不可能有計票困難的情況？我覺得現行情況下似乎不需要分開，但是假如是基於速速通過的概念上，我也不介意先放一邊。--Ghren🐦🕓 2022年4月3日 (日) 09:39 (UTC)

可也。那就是四栏“IA+A”“A”“N”“O”？ ——魔琴 [ 留言 贡献 ] 2022年4月3日 (日) 10:01 (UTC)

應該是

Admin：同意 中立 反對

IA：同意 中立 反對

這個樣子吧，可以提供自由度讓選民反對其中之一，或支持其一。--Ghren🐦🕕 2022年4月3日 (日) 10:09 (UTC)

哦对，我忘记了IA可以不是A。那加的应该是一行不是一列。 ——魔琴 [ 留言 贡献 ] 2022年4月3日 (日) 10:11 (UTC)

啊，地域詞地域詞，反正就是橫行或者橫列的意思（列_(資料庫)） 囧rz……。--Ghren🐦🕕 2022年4月3日 (日) 10:42 (UTC)

啊呀，我不知道这也是地区词（ ——魔琴 [ 留言 贡献 ] 2022年4月3日 (日) 11:06 (UTC)

公示

• 本次投票以一人為限，以最早得到七票（參考WP:RFDA，提名票不直接算進票數，提名人的提名和投票取向不一定也不需要一致）者，而且合乎投票過程要求者的優先進行選舉，其他的押後至下一次；
• 候選人應清楚說明是否參選界面管理員，如需要選票上應該另有一條問題；
• 選舉的關鍵日期應該預先決定以方便安排投票；
• 討論、提問的時間規定在14天，以得滿足提名條件且得行政員確認一刻起算作14天，14天結束後候選人依然可以回答問題，但不應該再展開討論，也不應該提出新問題；
• 投票時間起始點可以視乎準備人員需要提前或延後，討論時間不應該因此增加或減少；
• 參與準備工作的人員沒有被選舉權，但可以投票。

🕗 公示7日。Ghren🐦🕐 2022年4月7日 (四) 05:30 (UTC)

• 誰會當這次的監票組?還是這案通過後才會產生?--Temp3600（留言） 2022年4月7日 (四) 06:42 (UTC)

  理論上是行政員和監管員，應該是之後再決定的。--Ghren🐦🕑 2022年4月7日 (四) 06:47 (UTC)

• 「參與準備工作的人員」具體來說是哪些人？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年4月7日 (四) 06:58 (UTC)

  參考英維，應該最少有兩個監察員。想了想行政員似乎真的未必有角色。--Ghren🐦🕓 2022年4月7日 (四) 09:29 (UTC)

  行政員不過就是最後授權管理員罷了。不過這讓我想到，如果有臨界情況怎麼辦？行政員沒辦法判斷票源。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年4月7日 (四) 11:22 (UTC)

  请问临界情况指的是？--BlackShadowG（留言） 2022年4月7日 (四) 11:53 (UTC)

  其他維基是讓Cuer參與監票工作，行政員似乎不能做什麼。但是行政員如果有需要的話應該可以給予權限讓他們看票源名單，決定臨界的問題。當然數據要脫敏告知社群。--Ghren🐦🕖 2022年4月7日 (四) 11:55 (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)

TranveWikipedia:互助客栈/其他/存档/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)

---

re-meta:Special:Diff/22831347

1. 在公告“具备投票资格的用户可以安全发表自己的声音，以防他们在 CU 选举之间失去信心。”，具体步骤是什么？

   社区需要决定什么是合格的选民。安全选举是 SecurePoll 选举。社区已经设计了不同的方式来表明在定期选举之间失去信心。例如，德语维基百科强制使用该系统。

2. “所有成功的 Zh.WP CU 候选人都将在 CU 社区接受培训”如何培训？在哪里培训？ 培训一位用户查核员需要多少时间？

   全球志愿者社区和基金会需要共同开发一个培训模块。培训模块可以托管在 learn.wiki 上，总共可能需要大约 2-4 小时。

3. 2017 年发生了一起事件，当地用户查核员公开披露了 CU 数据。我理解 T&S 出于隐私和法律原因无法发布详细信息。但事件已经解决了吗？

   默认情况下，基金会不会公开讨论其调查案件的细节或状态。

4. 当地讨论中有一个提议，如果有复杂的案件，即使有当地的用户查核员，也可以要求 CU 管理人员调查。这个提议可以接受吗？

   这是当地社区直接与管理人员进行的对话。基金会要求尊重相关政策和标准，但当地 CU 或管理人员是否调查案件取决于当地和全球社区，而不仅仅是基金会的观点。

5. 本地讨论中表现出对本地 CU 结果难以接受的担忧。因为语言障碍，一些本地用户的英语可能不太流利。有什么方法可以帮助当地社区成员轻松上诉？

   防止用户查核员滥用的第一层控制在于其他用户查核员。这就是为什么全球用户查核员政策总是要求有一个由两人组成的本地团队。这样总有其他人可以看到 CU 数据并且产生制衡。如果仍担心和怀疑滥用 CU 工具，可以随时将此类问题提交给申诉专员委员会，可以使用任何语言向申诉专员委员会提出问题。--WMFOffice（留言） 2022年3月1日 (二) 03:47 (UTC)

假如連WMF出來回答了也沒人給反應的話，我唯有移走不存檔模板當大家都不想要CU了。Ghren🐦🕓 2022年3月10日 (四) 08:33 (UTC)

确实有支持也有反对……WMF也解答了一些反对票的疑惑。我们是不是可以整理一下各方观点看看有没有突破口。 ——魔琴 [ 留言 贡献 ] 2022年3月10日 (四) 23:17 (UTC)

问题是 WMF 说的不明不白：在 18 年行动之前有 6 名查核员，除去WP:CU中记载的推定离任的那几位还剩下三位。这三位到时候是直接复职还是要经过上面的 secure poll 投票？推定离任的是确实像 OS 那样已经经过邮件确认离任还是要再 lock 一次然后发邮件申请离任？从上面的讨论来看至少有两次 CU 数据泄露，站外的和站内的，但是从 18 年到现在 WMF 既不告知调查结果也没有见到 WMF 对当时的查核员做出行动。可否推断 WMF 对此事也是无结论？如何能确保将来不再发生此事？--广雅 范★ 2022年3月11日 (五) 15:33 (UTC)

应该是不能直接复职。 ——魔琴 [ 留言 贡献 ] 2022年3月11日 (五) 15:46 (UTC)

同魔琴君，應該不能直接複任，並需重新經過上述投票。「如何能确保将来不再发生此事？」根據WMF現有提供的資訊，應該是藉培訓、監察機制及秘密投票來確保查核員的素質，從而防止洩露事件的出現。謝謝。--SCP-0000（留言） 2022年3月11日 (五) 16:37 (UTC)

说实话我不认为这些方法可能有用。User:PMDdeSN 虽然各人有一定猜测，但现在都没有确定是当时哪位查核员泄露的数据。如果知道的话当时就可以发起解任投票，而不用等到基金会介入。在大家都没有证据确定是谁的话安全投票无法确保社群的监督机制。而且所有查核员都签署过 NDA，新开一个一次性账号也能证明此人是清楚这种行为是严重违反规定的，因此培训能达成的功效也有限。当时此事通报基金会后基金会肯定也进行过一系列调查，但就像我之前说的，至今都没有发现有相应的 office action 出来，因此我怀疑监察机制能否达到预期。--广雅 范★ 2022年3月12日 (六) 13:46 (UTC)

(▲)同上。基金会在这件事上似乎除了移除中维查核权限外束手无策。很让人怀疑基金会是否真正有有效方法来避免以后出现同样的问题。不要等到刚刚恢复CU权限第一天就出现隐私泄漏事故。^{[開玩笑的]}----Yichen Ding（留言|主账户） 2022年3月15日 (二) 15:20 (UTC)

最糟糕的情況下，也不過就是禁止前使用者查核員競選罷了。又或者等個幾十年，所有相關人士全死光了才能選新的？我個人不希望將本地查核作業永遠丟給監管員來做。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年3月23日 (三) 16:53 (UTC)

禁止前查核员竞选也不能保证新查核员没问题吧，毕竟当时选前查核员时也没料到会出当时的事情。我本身不反对本地拿到 CU 权限，但问题是之前出的事情总得有个交代。不然现在都知道查核员自己用傀儡连基金会都没法查出来了，难保不会出现第二次第三次。还有上面提到的查核员个人私下将数据泄露给第三方的问题。--广雅 范★ 2022年3月24日 (四) 02:11 (UTC)

@范、Ericliu1912、Yining Chen： 近日向基金會詢問他們有沒有其他方式來應對洩漏CU數據的問題，他們的回覆可見此。另也可參考一位英維管理員的意見。謝謝。--SCP-0000（留言） 2022年3月26日 (六) 00:26 (UTC)

---

若不能滿足以下兩個條件，不論誰參選用戶查核員，一律投反對票。

IP	Internet Protocol Address	網際 協定 位址
UA	User Agent	使用者 代理

• 私隱：現行的設置總有漏網之魚。這權限應改成不能查核IP用戶，也不能顯示註冊用戶的IP和UA，每次只能查核某註冊用戶之間的關係，均為系統過濾後的結論，類似於全域監管員的答覆，去除不必要的安全憂慮。
• 監察：任何人都可以請求查核用戶，唯決定權在於用戶查核員。使用權限前必須通知被查核的用戶；使用權限時提供充足的理由來解釋，只有懷疑濫用傀儡的情況才需要查核；使用權限後系統應自行記錄，讓任何人都能看見。

--月都（留言） 2022年3月29日 (二) 23:46 (UTC)

(＋)支持公開查核記錄，但(－)反对關於隱私的設定更改，明顯存在對用戶查核工具的錯誤理解。監管員給予的答案均是不能簡單以編碼代替的，況且用戶查核員本身還需要（因應請求和合適情況）進行查核以延長自動封鎖（WP:CUP#1）和查核用戶請求IP封鎖例外是否與其申訴／申請所言相符才授予權限（WP:CUP#3，現在都沒有在執行）。同時(－)反对使用權限前必須通知被查核用戶，不可能預先通知LTA他們即將被查核。無論是操作上還是原理上，這些要求都是完全不合理的。--路西法人⛧𖤐 2022年3月30日 (三) 03:07 (UTC)

用點常識就知道不可能公開查核日誌了好嗎？如果日誌上寫著已查核User:Example，然後緊接著已查核IP:1.2.3.4，那麼有點邏輯的人都知道User:Example的IP是啥了。--Xiplus#Talk 2022年3月30日 (三) 04:48 (UTC)

感謝兩位提出意見，參考RBI論述應不理會LTA，使用權限前必須通知被查核用戶，這要求或有不妥之處，故此添加删除線；縱上有用戶指出潛在泄漏資訊的威脅，過去已發生泄漏數據的事件，恢復本地社群之用戶查核權限前，私隱安全需要得到重視，不然如桐生所說維持現狀。 --月都（留言） 2022年3月30日 (三) 05:16 (UTC)

查核日誌僅針對用戶，而IP用戶則僅標記XXX查核了「某個IP」（真的是「某個IP」）這樣即可。沒人說一定要顯示出來的。另外，執行WP:CUP#1的時候，監管員或用戶查核員封鎖個別IP的時候，不也是同樣一邊出查核結果，一邊進行{{checkuserblock}}嗎（監管員的封禁日誌）？我覺得MASK了IP就已經能符合查核日誌的私隱要求了。--路西法人⛧𖤐 2022年3月30日 (三) 10:14 (UTC)

(＋)支持查核日誌僅針對用戶，不顯示IP位址；在保證私隱沒有外泄的可能時，同意本地引入用戶查核權限。 --月都（留言） 2022年3月30日 (三) 13:54 (UTC)

@LuciferianThomas：有時會對封鎖日誌進行監督，就是為了隱私，或是等一段時間才封鎖等緩解措施。--Xiplus#Talk 2022年3月30日 (三) 13:56 (UTC)

確實如此，那麼除對查核員及監管員外不顯示IP的查核日誌是否合理的技術性保護用戶途徑？此外，亦必須向基金會詢問不具有查核權限的用戶透過建立鏡像站而獲得類同用戶查核的資訊是否符合隱私政策。--路西法人⛧𖤐 2022年3月30日 (三) 14:13 (UTC)

(＋)支持，甚至即使不公开对IP用户的查核记录也无妨。--Yining Chen（留言|签名页） 2022年3月31日 (四) 14:08 (UTC)

那麼應該先諮詢技術團隊跟法律團隊。--Xiplus#Talk 2022年3月31日 (四) 16:08 (UTC)

把「•公開」修改為社群「•監察」，以防止查核員濫用職權。 --月都（留言） 2022年3月31日 (四) 16:57 (UTC)

原則上只要不公開IP和帳號之間的關係就可，或可考慮只公開查核涉及對象而不公開相關IP。謝謝。--SCP-0000（留言） 2022年3月30日 (三) 15:56 (UTC)

“改成不能查核IP用戶，也不能顯示註冊用戶的IP和UA，每次只能查核某註冊用戶之間的關係，均為系統過濾後的結論”并不可行。用户查核工作面对的是多样且未知的情况，需要查核员接触尽可能多的原始信息，例如：

某一位疑似LTA的用户的某一笔编辑显示的IP位于北京，该IP不是校园、公司等共享IP；而另一位疑似LTA的用户5分钟后的另一笔编辑显示的IP位于广州，同样不是共享IP。那么查核员可以推断除非共享账号，否则两位用户几乎不可能是同一人。但

1. 如果不是5分钟，而是5小时，那就有可能是这位用户坐飞机去了广州；
2. 如果后者是校园网IP，那可能是一位在北京的用户，挂了广州某高校的VPN，这种可能性要进一步通过对该名LTA本身的了解来进一步证实或证否；

这些信息都是单纯的“查关系”所查不出来的。--Antigng（留言） 2022年4月6日 (三) 10:00 (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)

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

---

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

---

鐵路1（讨论 | 貢獻） ：

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

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

鐵路1（讨论 | 貢獻）：

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

鐵路1（讨论 | 貢獻） ：

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

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

     @Fran1001hk：

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

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

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

    @Fran1001hk：

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

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

      @Fran1001hk：

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

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

@Wpcpey：

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

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

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

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

@Wpcpey：

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

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

(＆)建議

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

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

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

@Wpcpey：

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

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

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

有關模板的刪除理由

此前討論將《刪除方針》中的第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)

当初把条文改严格的原因：1、subst模版引用数可以是0，你是看不出来是否有用的。有人想当然，提删一堆subst模版，造成很多不便。2、历史曾用模版，现在不用了的，大有人在，引用数也是0，但是都在历史里，这种模版一删，等于删除很多页面的历史。这两个问题你们觉得有道理没？总之因为此原因，模版区不是一个可以让喜欢整理电脑内容的洁癖用户每日打扫的区域。至于反复滥建模版，确实令人不舒服，但是实际上的不良影响何在？Bluedeck 2022年3月4日 (五) 08:04 (UTC)

1的根本原因是部分用戶誤解「無用」與「未使用」兩個集的關係（「未使用」的模板與「無用」的模板是兩個集，兩者有重合的地方，但不是完全重合或包含與被包含），因此正解為澄清「無用」與「未使用」兩個集的關係，加一個註釋說“無引用的模板不一定為無用的模板”之類的可能有用。2無法從根源上防止其他用戶誤用或執意使用已棄用模板的行徑（而且還要考慮到現在有用戶公然包庇那些執意使用已棄用模板的行徑的情形），不利於模板的維護（至少就Infobox而言是如此，不良影響的話請看MOS:IBT）。Sanmosa _{Veritas Vincit} 2022年3月9日 (三) 14:01 (UTC)

Re 2: 參考en:Template:Template for discussion#Display on articles顯示小型警示文字，讓「目前」的引用能被注意，在閱讀「歷史」的引用又不太過於干擾。--Xiplus#Talk 2022年3月10日 (四) 05:19 (UTC)

這只能處理誤用的問題，而不能處理（包庇）執意使用的問題，然而（包庇）執意使用的問題才是比較嚴重與發生頻率較高的情況。Sanmosa   2022年3月11日 (五) 05:08 (UTC)

寫個bot確保加入了Xiplus所提模板的模板可以自動清理調這些不合理使用的就行了吧。--Ghren🐦🕘 2022年3月13日 (日) 13:15 (UTC)

“ 加一個註釋說「無引用的模板不一定為無用的模板」之類的可能有用。 ”

我95%不相信这个文字会起作用的，根据我的经验，脑子里存在“看不出为什么有用 == 无用”这一等式的用户并不在少数。Bluedeck 2022年3月12日 (六) 15:17 (UTC)

但不能質疑的一點是，如果要避免用戶誤解「無用」與「未使用」兩個集的關係，加註釋比起設立為濫建模板大開門路的條文更為恰當。因此，重點其實在於註釋的行文該怎樣表達才能使用戶正確理解「無用」與「未使用」兩個集的關係。Sanmosa _{Avec cœur} 2022年3月12日 (六) 23:27 (UTC)

就算改回舊版，我也不覺得Ping4符合刪除條件，建立者不是已經很好的展現使用的狀況了嗎？--Xiplus#Talk 2022年3月13日 (日) 01:29 (UTC)

如果相關模板使用率（注意我説的不是“連入”）極低，而且機能很明顯能夠被其他模板替代，那相關模板很明顯就是無用的。假設性的使用狀況不能用於證明模板有用。Sanmosa _{Avec cœur} 2022年3月21日 (一) 08:47 (UTC)

什麼叫機能能被取代？那為什麼不手動輸入{{Ping}}的內容呢？沒有複雜到需要使用模板啊？那是不是{{Ping}}也能刪了？--Xiplus#Talk 2022年3月21日 (一) 08:52 (UTC)

注意我上面提到的兩個條件都需要被滿足。{{ping}}很明顯不是“使用率極低”的模板，因此不能歸入“無用模板”的屬性。Sanmosa _{Avec cœur} 2022年3月21日 (一) 08:56 (UTC)

哪個模板剛建立的時候使用率是高的？這是在論斷每個新模板都是無用模板嗎？--Xiplus#Talk 2022年3月21日 (一) 08:59 (UTC)

我重申一次：注意我上面提到的兩個條件都需要被滿足。假設我新建立了一個新主題的導航模板，裏頭的内容很明顯是任何其他模板從未覆蓋的，所以就算它一開始使用率極低，由於不滿足“機能很明顯能夠被其他模板替代”的條件，因此仍不能歸入「無用模板」的屬性。Sanmosa _{Avec cœur} 2022年3月21日 (一) 09:04 (UTC)

所以說{{Ping}}其實應該在它被建立的時候就迅速的被提刪，然後如同Ping4一樣被刪掉嗎？Ping模板還不是經過長時間使用才會累積引用數，它在「建立的那個時間點」「使用率極低」。--Xiplus#Talk 2022年3月21日 (一) 09:07 (UTC)

你這裏的一個邏輯謬誤是假定這裏擬定的規則可以無限追溯。在這裏談論“當初”的事情是完全沒任何意義的。Sanmosa _{Avec cœur} 2022年3月21日 (一) 09:12 (UTC)

我沒有要讓「現在的規則」追溯「以前的情況」，但是假設這個規則在2013年就存在，那麼「以前的規則」處理「以前的情況」，Ping模板就會被刪掉。--Xiplus#Talk 2022年3月21日 (一) 09:15 (UTC)

所以我才説你有邏輯謬誤啊，這種情景下是無法進行有意義的假設的。Sanmosa _{Avec cœur} 2022年3月21日 (一) 09:19 (UTC)

那換個時間的方向，怎麼認定Ping4未來不會變得非常多人用？--Xiplus#Talk 2022年3月21日 (一) 09:25 (UTC)

沒人推廣。試問建立人自己也沒有開始使用模板，又沒有特別在客棧特地公佈他建立模板的消息，會有多少人會真的留意到該模板？如果連該模板也留意不到的話，那就別説有沒有人用了。Sanmosa _{Avec cœur} 2022年3月21日 (一) 13:06 (UTC)

那麼Ping4建立者自己不就使用了嗎？--Xiplus#Talk 2022年3月21日 (一) 13:08 (UTC)

有嗎？--Sanmosa _{Avec cœur} 2022年3月21日 (一) 13:10 (UTC)

我記憶有偏差，實際上是建立者主張過去有44則留言可改為Ping4模板，至於有沒有用過我不確定。--Xiplus#Talk 2022年3月21日 (一) 13:15 (UTC)

Wikipedia:頁面存廢討論/記錄/2021/11/06#Template:Ping4，這裡有人表示有連入頁面，就是有人使用了啊。--Xiplus#Talk 2022年3月24日 (四) 04:08 (UTC)

我没有使用，但是确实提删时有链入。 ——魔琴 [ 留言 贡献 ] 2022年4月3日 (日) 11:21 (UTC)

難道每一次都建新模板都要在客棧先寫一次，我建了新模板啦，大家快點來用，難道這樣好嗎。--Ghren🐦🕙 2022年3月21日 (一) 14:12 (UTC)

@Ghrenghren：但至少也要自己先開始用啊，{{CSD Link}}（部分連入現在在{{CSD Reason}}那邊，因為模板原名是{{sdr}}）我也是自己先使用一會兒，然後也就多了使用率啊。Sanmosa _{Avec cœur} 2022年3月22日 (二) 03:14 (UTC)

建了只有一個月，又怎樣判斷使用率？--Ghren🐦🕛 2022年3月22日 (二) 04:49 (UTC)

但至少也要自己先開始用啊，重點在這裏啊，連自己都沒有真的在用的模板，其他人用來又有甚麽意思？Sanmosa _{Avec cœur} 2022年3月24日 (四) 00:05 (UTC)

這個你去問魔琴去。誰知道到底是用了被人還是沒有用--Ghren🐦🕒 2022年3月24日 (四) 07:04 (UTC)

舉一個實例，{{Ping2}}功能與{{Ping}}相差沒有多少，完全可以透過改{{Ping}}來涵蓋，但現在已經1500+使用了，而Ping4與Ping2就模板功能上情況類似，但Ping4沒有等到很多人用就刪除了。--Xiplus#Talk 2022年3月21日 (一) 09:27 (UTC)

(－)反对：即使是“无用”模板，在某些情况下也可能有用。且假若修改条文后，那只需要把所有所谓“无用，滥建的模板”都标记上{{needsubst}}不就可以一劳永逸了吗？而且从根本上来说，没有任何理由去删除这些模板。从服务器端来讲没有问题，从本地来看也几乎没有任何影响。WP:没坏别修。--Yichen Ding（留言|主账户） 2022年3月20日 (日) 15:19 (UTC)

我認為這種事情不能一概而論，只能個別論證。我不認為可以在不就每個模板個別討論的情況下統一認定所有模板“某些情況下也可能有用”，而需要就每個模板各自分別進行論證，而且論證的有效性還需要分別獲得社群認可。Sanmosa _{Avec cœur} 2022年3月21日 (一) 08:42 (UTC)

舉證責任還不是變成在保留那方，提刪者都不用證明「多餘無用」，只需要留下這四字就能提刪了。--Xiplus#Talk 2022年3月21日 (一) 08:49 (UTC)

我不認同“變成”這個説法，畢竟舉證責任本來就只在主張保留方。Sanmosa _{Avec cœur} 2022年3月21日 (一) 09:00 (UTC)

確實不是「變成」，而是本來就是這種有問題的情況；說的好像提刪不需要寫理由似的。--Xiplus#Talk 2022年3月21日 (一) 09:03 (UTC)

沒辦法，畢竟一個模板（頁面）就算不是無用的，只要有其他合理的刪除理由，就算一開始的刪除理由不成立，模板（頁面）還是會被刪除，而且勇于更新页面對模板是不適用的。Sanmosa _{Avec cœur} 2022年3月21日 (一) 09:07 (UTC)

那麼除了「多餘無用」4個字，「其他合理的刪除理由」在哪？--Xiplus#Talk 2022年3月21日 (一) 09:10 (UTC)

你問我，我又能問誰？難道你覺得我會參與（或參與了）此前與此後的所有存廢討論？存廢討論期間參與的用戶提出新論點是正常不過的事情，而新論點可以是刪除理由。Sanmosa _{Avec cœur} 2022年3月21日 (一) 09:14 (UTC)

而且，容許我在這裏重申：無用模板不利於模板的維護，因此有刪除的必要。Sanmosa _{Avec cœur} 2022年3月21日 (一) 09:10 (UTC)

那麼現有條文「多餘無用，且影響百科運作的模板」不就完全符合您的提刪理由嗎？--Xiplus#Talk 2022年3月21日 (一) 09:30 (UTC)

如果你是這樣認為的話，那這也意味著所有多餘無用的模板都必然會影響百科運作，那一開始在條文中加入“且影響百科運作”作為限定條件也是無意義的。所以，我有必要向你問清楚一件事：“不利於模板的維護”是否“影響百科運作”的其中一種情況？Sanmosa _{Avec cœur} 2022年3月21日 (一) 13:03 (UTC)

是。但怎樣叫做「不利於模板的維護」？--Xiplus#Talk 2022年3月21日 (一) 13:05 (UTC)

不利統一格式、不利重複使用、不利管理，諸如此類，都屬於「不利於模板的維護」，但「不利於模板的維護」是必然跟隨「多餘無用」出現的。--Sanmosa _{Avec cœur} 2022年3月21日 (一) 13:13 (UTC)

那具體來說Ping4有什麼問題？格式跟重複利用感覺沒有，不利管理嗎？--Xiplus#Talk 2022年3月21日 (一) 13:19 (UTC)

當然是不利管理了。ping4直接copy{{ping}}或{{ping2}}的原始碼，也就是説如果未來要調整相關模板，我們要分開改4個模板，難道是有利管理的情形嗎？Sanmosa _{Avec cœur} 2022年3月22日 (二) 03:23 (UTC)

那麼按照下方所述的預制資料盒設計不就解決了嗎？--Xiplus#Talk 2022年3月22日 (二) 03:27 (UTC)

我又不知道有多少個預制資料盒（除非我特地建一個分類來檢查，但又不是所有預制資料盒都有加{{Wraps infobox}}，{{Wraps infobox}}的那個分類機制甚至還是我自己改出來的），而且我動了主模板後其實有可能還是需要對預制資料盒進行調整的。Sanmosa _{Avec cœur} 2022年3月22日 (二) 03:57 (UTC)

所以預制資料盒是個好設計還是爛設計？--Xiplus#Talk 2022年3月22日 (二) 04:37 (UTC)

要看情況。如果是已經有比較多人用的模板，改成預制資料盒還是好設計；如果是沒甚麽人用，甚至完全沒人用的模板，改成預制資料盒就是浪費時間與資源。Sanmosa _{Avec cœur} 2022年3月24日 (四) 00:04 (UTC)

假如我將{{ping}}前面加上{{#if:{{{ping|}}}|ping}}然後將{{ping4}}變成了{{ping|ping=1|1={{1|}}|[...]}}，將ping4變成預制資料盒你能接受嗎？Ghren🐦🕙 2022年3月21日 (一) 14:18 (UTC)

預制資料盒使用的條件是原本的模板已經有一定的使用率，又難以全部替換掉的情形，所以我覺得不太行。Sanmosa _{Avec cœur} 2022年3月22日 (二) 03:17 (UTC)

重提KirkLU方案

翻了翻近期提删模板的理由，有这样一些：

• 無必要以模板顯示平壤市的標誌
• 已無導航作用之模板
• 可被其他模板取代的模板
• 過時圖表
• WP:CRYSTAL

很难说这些模板“影響其他模板命名或者百科運作”，因而该项条件实际上是被忽略的。我认同Bluedeck修改条文的两个出发点，但条文中却并无体现，以使阅读者留意。在此推荐KirkLU的修改方案（此处的“合并后新提案”）。--Lt2818（留言） 2022年3月22日 (二) 03:30 (UTC)

不反對。Sanmosa _{Avec cœur} 2022年3月22日 (二) 03:59 (UTC)

• 無必要以模板顯示平壤市的標誌 版權不明確，違反DP2
• 可被其他模板取代的模板 內容分歧，違反DP5
• 過時圖表 WP:NOT，即DP14
• WP:CRYSTAL WP:NOT，即DP14

除了已無導航作用之模板是在討論之範圍內，其他都和DP9無關。Ghren🐦🕐 2022年3月22日 (二) 05:11 (UTC)

所以不能大大方方承认这些模板“多余无用”吗？不见得要寻章摘句凑理由（DP5说的是條目，DP14为百搭的兜底条款）。--Lt2818（留言） 2022年3月22日 (二) 05:31 (UTC)

DP5對應的方針還沒定立，但是英維沒有將其只包括在條目內。只是(such as Wikipedia articles or inter-wiki objects)而己。中維連方針成立討論都沒有討論過就別談了。--Ghren🐦🕑 2022年3月22日 (二) 06:06 (UTC)

Sanmosa和Lt2818(－)反对：该提案对subst相关模板依然兼容性差。例如，本人创建了一个模板{{rawsign}}，用来生成一个原始签名，这个模板（乃至CAT:应被替换引用的模板）理论上（除某些特殊页面外）不会有任何页面引用，而且也几乎不可能调查该模板是否“正在（被）使用”。对于这种情况，从该提案原始目的：删除“无用模板”来说，该提案是否就无能为力了？--Yining Chen（留言|签名页） 2022年3月25日 (五) 15:37 (UTC)

Yining Chen我把“替換引用”的内容补充进了该修改方案，您可以看看下方提案如何。--Lt2818（留言） 2022年3月25日 (五) 16:21 (UTC)

调整了KirkLU方案的行文，提案如下：

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

提議條文 9. 多餘無用的模板 模板未被任何页面嵌入并非提删的充分理由，如被系统界面使用与应替换引用的模版可以无嵌入。此外亦应从是否有助于主要历史版本完整呈现、是否有机会再被使用等方面考量是否仍有存在价值。

删除的部分与实践脱节，见上。增加的注释将此前修改的出发点书面化，使阅读者可知其所以然。--Lt2818（留言） 2022年3月25日 (五) 16:17 (UTC)

建議嵌入的連結換成Wikipedia:嵌入包含。--Xiplus#Talk 2022年3月26日 (六) 00:16 (UTC)

另建議以WP:RD2的格式，換行縮排小字的方式來說明，而非使用ref，比較容易看到。--Xiplus#Talk 2022年3月26日 (六) 00:21 (UTC)

已修改。--Lt2818（留言） 2022年3月26日 (六) 02:18 (UTC)

不過如果模板有任何嵌入還可以使用此款提刪嗎？--SunAfterRain 2022年3月26日 (六) 13:45 (UTC)

可以，模板无嵌入不是提刪的必要条件，见此例。--Lt2818（留言） 2022年3月26日 (六) 14:36 (UTC)

现在有一个新问题，如果某人创建了一个新模板（例如{{Nwarn}}或{{ping3}}），貌似可能没有其他人会使用到，但该名用户表示自己和自己的朋友将要或已经在条目与讨论中多次使用该模板（不在用户页下创建子页面，理由之一是使用时需要输入较多的无用字符）。对于这种情况，是否应算作“无用模板”？如果在这种情况下需要“灵活决定”，那是否意味着“多余无用”这一词语范围过于模糊，不适合用于方针内？--Yining Chen（留言|签名页） 2022年3月26日 (六) 14:06 (UTC)

“灵活决定”没啥错，存废讨论就是专门做这事的。方针规定原则即可，不需要事无巨细。“多余无用”一语源自en:Wikipedia:Deletion policy#10；何者算多余无用，还是要具体问题具体分析。--Lt2818（留言） 2022年3月26日 (六) 14:52 (UTC)

🕗 公示7日。--Lt2818（留言） 2022年4月2日 (六) 15:10 (UTC)

请参考下方提案。--Yining Chen（留言|签名页） 2022年4月3日 (日) 09:50 (UTC)

我認為我這方案對於「多餘無用」給了還可以的定義，應該暫停公示。--Ghren🐦🕓 2022年4月3日 (日) 09:56 (UTC)

该小节的方案只需优于现行条文即可。如果您的方案被接受的话，那么再次修改也无妨。我对您的方案的意见会稍晚些给出。--Lt2818（留言） 2022年4月3日 (日) 10:08 (UTC)

(－)反对。“如被系统界面使用与应替换引用的模版可以无嵌入。此外亦应从是否有助于主要历史版本完整呈现”。。。。。。怎么考虑？怎么知道一个模版是不是被subst的模版？怎么知道一个模版对历史的影响？当初就是因为这些问题都无解，才改的删除标准。你不能现在就通过“请注意一下哦”的一段告示就把这个问题绕过去了。Bluedeck 2022年4月5日 (二) 06:47 (UTC)

举个例子。假如要在VFD里面以多余无用这个理由删除模版，应该怎么举证说明这个模版多余无用？根据新版多余无用的删除标准，我认为应该首先下载整个中文维基数据库，在历史版本中检索该模版的使用情况，然后再采访中文维基百科的所有用户，询问是否subst使用此模版。显然这个标准完全无法实现。因此这不是个好标准。Bluedeck 2022年4月5日 (二) 06:52 (UTC)

很简单，凭常识。判断历史使用情况需要下载数据库吗？有{{Needsubst}}的提示在，需要采访中文维基百科的所有用户吗？况且都不是硬性条件，只是让用户在讨论存废时去考量而已。我可以一样反问：怎么知道影响其他模板命名？（先到先得岂非更好）怎么知道影响百科運作？（硬说过时图表和滥建的用户框不影响百科運作，好像也挺有道理的）

如果这都不行的话，那么我主张删除小字部分，恢复原始版本，毕竟英维的条文到现在没见谁觉得不妥。您的方案不仅在当时有Shizhao等人反对，事后亦有KirkLU、Sanmosa与在下提出修改意向，且其在实际存废讨论中遭到忽略，实难称为社群共识。即使您能阻挡本次修改，今后也一定会有人认为此条不妥而再次提案。--Lt2818（留言） 2022年4月5日 (二) 08:38 (UTC)

Ghrenghren方案

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

---

模板_(a)沒有功能^[1]或所提供的功能可以被其他模板或等效方式取代，_(b)又或者缺乏合理預期模板有實際用途的模板^[2]。

---

_[1]

功能不只包括直接調用以使用其功能，包括但不限於：

• 模板提供了除錯功能；
• 模板的有助於主要歷史版本完整呈現；
• 技術上或內容上有供後人參考價值；
• 正文因為超出模板限制而統計資料改為放置在模板內等等。

_[2]

• 需要被subst使用的模板：_(a)內容可以可以直接輸入代替，_(b)引致用戶一般直接輸入；
• Navbox：_(a)包含的條目缺乏實際預期可以建立的可能性，無法預期模板有導航作用，沒有功能；
• 其他模板：_(b)模板沒有一定的使用量或者無法預期有使用量，_(a)而提供的功能可代替。

我的建議是這樣。Ghren🐦🕐 2022年4月2日 (六) 17:25 (UTC)

(－)反对：“Navbox”一节过于严格。--Yining Chen（留言|签名页） 2022年4月3日 (日) 03:03 (UTC)

預期建立也就是說這些Navbox應該的連結最少應該是綠連，或者是預期可以被建立的紅連。本來「導航模板提供導覽「現有」頁面」的功能，所以理論上最好是全部建立。以實際建立的可能性來說已經可以保留這些，而且相當於其他維基來說這樣寫已經寬得多了（「這事情可能應該開個投票處理，一了百了。除了zhwiki以外，較大規模的維基百科基本都一致認同全紅連無導航／消歧義作用這點，我認為zhwiki的情況屬於常識認知問題／差異。」sanmosa語。），另外更改了一點--Ghren🐦🕑 2022年4月3日 (日) 06:16 (UTC)

• 上下标的结构看起来过于复杂了，难以读懂。
• 上标[2]的三项内容性质不一致。“一般模板”讲保留条件，“需要被subst使用的模板”和“Navbox”却讲删除条件。
• 有的词意味不明。
  • 何为“除錯功能”？产生追蹤分類是否包括在内？
  • 何为“一般模板”？我猜意指“除下方列举项外的其他模板”，但叫“一般模板”就含混不清。
• 从设计思路上讲，该方案尝试将各种情况包罗进来，乃至出现了Navbox的特定模板名称。此类行文即使现在把漏洞都补上，也预期会带来今后的高维护量。印度宪法世界最长，代价是在七十余年间修订了105次。

--Lt2818（留言） 2022年4月3日 (日) 11:37 (UTC)

上下標的方法主要是為了分開「多餘」和「無用」這兩個看似相同但是意義上未必一致的刪除理由。我想單純提供追蹤分類的模板只怕不能計算在內，模板沒有被使用自然難以產生追蹤分類，我指的除錯功能指的是{{1}}{{2}}之類的模板。附注二按這個情況來說不一定是需要的，最好還是另外找個輔助說明頁來寫，這樣的話主條文就不需要分開a款和b款。--Ghren🐦🕘 2022年4月3日 (日) 13:01 (UTC)

英维是写“多余或其他情况无用”（redundant or otherwise useless），不过我看中文维持“多余无用”亦可，固定搭配容易理解。--Lt2818（留言） 2022年4月3日 (日) 13:35 (UTC)

事實上就是有上方的理解分歧才是需要更改，多餘不一定是無用的，無用不一定是多餘的。多餘和無用是並列的關係，而英維的詞語是or，也就是中維的詞語表達上不清晰而引致有上方的爭議。Navbox刪除是因為多餘而是不無用，{{動員令/11}}是無用但不多餘。但是作為成語去理解就是一個字「冗」的意思，這是一個問題。--Ghren🐦🕙 2022年4月3日 (日) 14:49 (UTC)

非也，英维条文的逻辑是redundant ⊂ useless。汉语辞典里多餘有多个义项，理解作“多出來的”抑或“不必要的”皆可。我认为此处让人快速理解为上，不必作形式化描述。--Lt2818（留言） 2022年4月3日 (日) 15:36 (UTC)

我無法從a or otherwise b 理解出a是b的子集，即使理解出來，兩次更改條文的原因都是條文不清晰，引致不能判斷什麼是多餘引致的。在此情況下，更改無不當，不然就不會有ping4的DRV。「多餘無用」不清晰是整個討論串的前提，而沒有人按DP規則來是枝節而己。--Ghren🐦🕐 2022年4月4日 (一) 05:14 (UTC)

您可以问问熟练英语的人对此句的理解。这里有一些同样结构的语句：“glossed over or otherwise handled”“All of the books had been burned or otherwise destroyed”。更改以正确理解为前提。--Lt2818（留言） 2022年4月4日 (一) 06:16 (UTC)

這句很明顯是「書籍要麼被燒，否則就銷毀掉」。otherwise只是排除了同時不被燒和不被銷毀的可能性，或者其他的可能性而己，而常識推理來說燒和銷毀是兩個動作。Result = burn XOR destoyed。「glossed over or otherwise handled」是Result =glossed over XOR handled，然後子集"glossed over" 和"handled"是"method"的子集，"method"減去"glossed over"形成了補集 "handled"，如果強行將動詞這樣理解的話。畢竟Wikipedia:是英文维基说的！，這個理解成OR就可以了，沒必要拉到是子集不子集之類的，還是歸來說回模板問題吧。--Ghren🐦🕑 2022年4月4日 (一) 06:44 (UTC)

希望其他人来评论一下吧。我觉得无能为力。--Lt2818（留言） 2022年4月4日 (一) 06:56 (UTC)

不對，你指的是理解成「除了多餘之外，還需是無用的模板」？似乎意思想了想也無不妥。Ghren🐦🕒 2022年4月4日 (一) 07:03 (UTC)

這樣的話應該是A$\cap$B，然後假如出現了redundent 但 usefull的情況再去制造出其useless的情況？--Ghren🐦🕒 2022年4月4日 (一) 07:21 (UTC)

除了询问他人外，亦可把这两句过一下翻译工具看看结果。我认为您的理解有误。--Lt2818（留言） 2022年4月4日 (一) 08:15 (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)

(－)反对，就之前管理員選舉的情況來看很多人提的問題數量都遠超兩題，此提案顯然不當。--🎋🎍 2022年3月1日 (二) 03:08 (UTC)

你这什么逻辑啊？因为之前很多人提的问题数量远超两题（我承认我也超过），所以现在提出限制每个人只能问最多两个问题。你的反对理据恰恰是这个提案要针对的问题；你自己说说，你这个反驳有效吗？--MilkyDefer 2022年3月1日 (二) 14:26 (UTC)

以人為單位其實換湯不換藥，你用盡「配額」，還可以找人替你追問啊，只要不被識穿就行了。我懶得翻查原來的討論紀錄了，但去年我想過一個方案：限制問題的總數（當時設想是14條左右），設立小組/專員審查問題，然後從獲批的問題抽籤；也許還可以考慮禁止必答和選答的選項（三條必答題出外）。這樣做對候選人負擔說不定會比公示方案小，但問題是誰來審查。--春卷柯南－發前人所未知 ( 論功行賞 ) 2022年3月1日 (二) 09:56 (UTC)

供参考：Stewards organise the elections themselves... Therefore, stewards create an election committee for every election consisting of volunteers for the following tasks...，其中包括了划去不合要求的问题。 Stang^★ 2022年3月1日 (二) 13:47 (UTC)

🕗 暫停公示。--Steven Sun（留言） 2022年3月1日 (二) 11:27 (UTC)

我覺得比較可行的做法是讓社群意識到候選人拒絕回答不重要或有偏謬的問題的權利是絕對的（我不説候選人拒絕回答所有問題的權利是絕對的的原因是如果相關問題屬於合理憂慮的話，我認為任何人都會想問，而且候選人的回答有助釋疑）。Sanmosa _A-DWY³ 2022年3月3日 (四) 05:51 (UTC) +2 Jonathan5566ghrenghren为此+1了。

• 被選人本來就有不回答問題的權利。問題是，怎樣避免投票者因而投下反對票。--Temp3600（留言） 2022年3月17日 (四) 12:25 (UTC)

  根本不可能避免，尤其是假如改採安全投票形式的話，就更難以用投票理由判斷投票有效程度。（加上籌備投票程序之複雜，我已經不怎麼支持管理人員選舉採用安全投票了）—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年3月17日 (四) 12:52 (UTC)

  倒不是不可能避免，但避免的方式可能會很極端：如果規定候選人只需要作答三個基本問題，並禁止任何人進行任何其他的非程序性提問，那投票人不可能因為候選人拒絕回答三個基本問題以外的問題而投反對票，因為他一開始的非程序性提問已經違反規則了。Sanmosa _{Avec cœur} 2022年3月17日 (四) 13:52 (UTC)

規範問答環節提案

既然都+2了，我就提個反建議好了：

現行條文 參與方式 管理人員提名需要經過14天（即兩周）的投票。具人事任免投票資格的使用者可以投支持票、反對票或中立票，也可以僅發表意見、向候選人提問（候選人有權決定是否作答）。投票后票數會自動更新，如果發現錯誤可至此處手動更正票數。 誰可以投票：為了確保使用者對於維基社群的運作有一定了解，僅限於符合人事任免投票資格者才能參與投票。投票者請先閱讀申請成為管理員的討論中應避免的理由。 誰不可以投票：未登录或未註冊使用者，以及不符合人事任免投票資格的註冊使用者不可以投票，非常新的使用者如果被懷疑是欺詐，如傀儡，則有可能會被視為無效票。 加入你的投票：点击相關使用者的“在此投票”，並在相應的標題下簽上你的名字，以表明你是支持、反對还是中立。與相應的標題相互矛盾的投票有可能被視為無效票。 可以投中立票：中立票將不計算在有效票數中，但當投票結果處於通過標準的臨界時（如支持25票，反对6票），行政員會在評估結果時考慮中立票。 為你的投票做出解釋：最好給出一個簡短的原因，尤其在投反對票時。這樣候選人及他人可以理解你的想法並給予答覆。 注意尊重所有人：有時對話雙方可能愈來愈激動，甚至爭吵起來。請記住，所有人都是有感覺、情緒和自尊的。 討論：詳細的討論請在意見區進行。任何人都可以討論或發表意見，包括匿名使用者。

提議條文 參與方式 管理人員提名需要經過14天（即兩周）的投票。具人事任免投票資格的使用者可以投支持票、反對票或中立票，也可以僅發表意見、向候選人提問。投票后票數會自動更新，如果發現錯誤可至此處手動更正票數。 誰可以投票：為了確保使用者對於維基社群的運作有一定了解，僅限於符合人事任免投票資格者才能參與投票。投票者請先閱讀申請成為管理員的討論中應避免的理由。 誰不可以投票：未登录或未註冊使用者，以及不符合人事任免投票資格的註冊使用者不可以投票，非常新的使用者如果被懷疑是欺詐，如傀儡，則有可能會被視為無效票。 加入你的投票：点击相關使用者的“在此投票”，並在相應的標題下簽上你的名字，以表明你是支持、反對还是中立。與相應的標題相互矛盾的投票有可能被視為無效票。 可以投中立票：中立票將不計算在有效票數中，但當投票結果處於通過標準的臨界時（如支持25票，反对6票），行政員會在評估結果時考慮中立票。 為你的投票做出解釋：最好給出一個簡短的原因，尤其在投反對票時。這樣候選人及他人可以理解你的想法並給予答覆。 注意尊重所有人：有時對話雙方可能愈來愈激動，甚至爭吵起來。請記住，所有人都是有感覺、情緒和自尊的。 討論：詳細的討論請在意見區進行。任何人都可以討論或發表意見，包括匿名使用者。 提問：任何人都可以向候選人提問，包括匿名使用者。請確保相關問題於維基百科或候選人在維基百科的活動而言屬重要，而且並不存在任何不當預設的謬誤，否則相關問題會造成候選人的困擾。候選人有權拒絕作答三個基本問題以外的一切問題，偏執要求候選人作答與維基百科或候選人在維基百科的活動無關或存在不當預設的謬誤的問題可被視為扰乱。

以上。@Ericliu1912、Jonathan5566、ghrenghren、Steven Sun。Sanmosa _{Veritas Vincit} 2022年3月9日 (三) 14:15 (UTC)

支持概念。提出以下較細化的提問規則：

提議條文 參與方式 ... 向候選人提問 在管理員選舉中，候選人回答提問有助投票人作出是否支持此候選人成為管理員的決定。候選人自薦或接受提名時，需要回答三條基本問題（請見#流程一節）。除此之外，任何人都可以向候選人提出問題。為確保問題素質，防止程序被擾亂，問題應先在討論頁提出，若十二小時內未獲合理反對並獲得另一名具有投票權的用戶支持提出問題後，則可轉發至投票頁面的提問區。每一名具有投票權的用戶僅能支持或反對提出一條問題。提出的問題應當保持語調中立，不應明示或暗示投票立場，並應與維基百科或候選人於維基百科的活動相關，且不存在不當預設的謬誤，以確保問答環節能作為一個具建設性的對話環境。候選人有權拒絕作答三個基本問題以外的一切提問，但建議（不強制要求）說明拒絕作答及原因。在候選人回應後追加延伸問題是可接受的行為，但追加的問題必須與原先問題及候選人的回答有關；候選人同樣有權拒絕回應追加的問題。就要求候選人回應問題進行施壓，包括但不限於以選票威脅回應和在候選人明確表明拒絕作答時仍反覆要求作答等行為均可被視作擾亂程序的行為。 補充說明

@Sanmosa：看看這樣會不會對各方都更加友善？--路西法人𖤐 2022年3月10日 (四) 03:46 (UTC)

@LuciferianThomas：我還是如之前説的一樣：我不説候選人拒絕回答所有問題的權利是絕對的的原因是如果相關問題屬於合理憂慮的話，我認為任何人都會想問，而且候選人的回答有助釋疑。如果社群合理地認為某問題於維基百科或候選人在維基百科的活動而言非常重要，而且將會影響維基百科日後的運作情況，我認為任何一個或多個社群成員要求他回答是合理的，這種情況應當排除於“偏執要求作答”的情形外。我不反對禁止“威脅作出回答”，但我還是想就“威脅作出回答”的定義請求澄清：假如我提問時表示“候選人的回答會影響我的投票決定”（對，這就是原話）的話，這算是“威脅作出回答”嗎（我自己覺得這個措辭應該算是委婉）？Sanmosa _{Veritas Vincit} 2022年3月10日 (四) 07:57 (UTC)

「候選人的回答會影響我的投票決定」不算威脅，確實符合中立語調也起碼算是禮貌，不過仍稍有施壓意味（我本來好像不是想寫威脅而是施壓，不過我當時想不起這個詞 囧rz……）。個人不建議說出來，因為這一句是沒有意義的，也不是給候選人的提問。

讓RFA不要成為一個toxic的環境是為此修訂的重點。關於社群要求作答的部分，如果候選人拒絕回答就沒有不斷要求作答的必要了，反正也不見得會改變到候選人的主意。其實我的寫法反而是想強調RFA提問的禮儀，而不是限制這個限制那個。禮貌地在討論中提到「希望能回答有關問題」的問題不大，但就算是多禮貌的說法，重複就會造成施壓，這才是我這個提議條文重心要避免的情況。候選人拒絕回答某些問題或在拒絕回答時是否提出合理理由應足以影響投票人的意見，施壓是完全不必要的行為。--路西法人𖤐 2022年3月10日 (四) 09:53 (UTC)

這樣說好像也是。而且，就算沒有施壓的意味，「候選人的回答會影響我的投票決定」這句話其實也形同廢話，因為就算提問人不説，候選人的回答本來就是大家的投票決定的合理影響因素之一（除非投票人鐵了心要支持或反對），因此我同意你修改後的版本。--Sanmosa   2022年3月10日 (四) 14:07 (UTC)

微調了字眼。--路西法人𖤐 2022年3月10日 (四) 13:27 (UTC)

@LuciferianThomas、Sanmosa：

1. 不建议给 支持/反对 限额。不可行。建议删去此条，转发门槛的1支持改为2支持，其余不变。
2. 追加延伸（有这样说的吗？）问题是否需要再经过遴选？
3. 提问的截止时间应提早一天。
4. 个人认为新开独立页面作为提问（遴选）区可能更好。
5. 不建议用tooltip。
6. 为确保问题素质和，防止程序被扰乱。【翻译腔】
7. 所有问题均应先在讨论页提出。【无用且重复】
8. 但建议可以（但不强制要求）说明拒绝作答及原因【累赘】

 ——魔琴 [ 留言 贡献 ] 2022年3月10日 (四) 16:27 (UTC)

感謝魔琴君的意見。

1. 對支持、反對限額的作用是防止某些維基人因為不喜歡候選人而大量同意對候選人提出質疑的問題，幾個支持都沒分別，有一件事情叫組團。有限制之後組團來提出質疑性問題拉低投票人的很容易發現，因為得玩互相支持問題的套路。
2. 我有想過這個問題，但跟上面一樣，防止灌問題。某程度上是跟限制問題數量相似，不過確實可以提出無限問題，只不過大家看到你這樣水問題有多少人會都給你全灌下去而已。
3. 這個嘛……看上面投票時間討論成怎樣先吧。
4. 不評論，不是不行，但好像又不太必要。
5. 純粹是提案給你們參考字眼用，寫進指引不會包含。

後面三個您可以直接修訂，小問題（--路西法人𖤐 2022年3月10日 (四) 16:38 (UTC)

1. 但是，这个提问是流动的。也就是说，第一天，我不知道我第13天会不会看到一个我需要去支持或反对的问题。而且如果大量灌问题，似乎也无法有效反对（当然也没人支持就是）。针对组团的事情，反对票可以解决……吧？

因为提问提出后不能直接被回答，提前一天截止可以防止提问废掉（而且上面讨论的好像只是临时）

已修改。

 ——魔琴 [ 留言 贡献 ] 2022年3月10日 (四) 23:05 (UTC)

（回覆見下，忘了ping）--路西法人𖤐 2022年3月11日 (五) 12:03 (UTC)

不知所云。假如每個有權者只能支持一條問題的話，事實上是將上邊的兩條問題收至一條，然後還再加上「十二小時」的規定約束之，四捨五入就是不要問問題。制度複雜，為候選人和投票者增加不必要的負擔。--Ghren🐦🕚 2022年3月11日 (五) 03:56 (UTC)

您的理解似乎誤會了這裡的意思。每個人仍然可以提出無限條問題，不過需要有其他用戶也覺得這題值得回答才送去問答區，不提問的當然也可以支持問題，我相信算下來會協助篩選題目的用戶數量應該比提問者數量多。A用戶可以提出五條問題，全部都是非常具有建設性的問題，態度也非常良好，那麼有另外五個個別的用戶來支持提出這些問題絕對不是難事。相反，如果B用戶提出五條沒建設性或者重複的問題，自然一條都不值得被轉過去。總而言之，這不是像上面的提案那樣按量去限制個別用戶的提問數量，而是按質去篩選題目（支持和反對題目可以看到題目是否真的值得提出）。以和平奮鬥救地球君的上次RFA有32個題目分段，且大部分發問者均提出多條問題，問題數多達百題，即使假設所有題目都是具有建設性的，不論在7天也好14天也好的提問期都明顯讓候選人不太可能招架。在這個新框架下，提問數量應比較可能控制在20至30題左右（7天提問期的話就應該15到20題左右），同一人當然仍然可以提出數道題目，但是不是每一題都具備對RFA的同等重要性，其他用戶就可以選擇說覺得哪些題目更具有重要性並支持提出有關問題，那麼就能讓最重要的議題能獲優先提問，次重要的就未必需要提出。關於魔琴的問題，我甚至覺得可以改成五天收集問題，兩天給所有延伸確認用戶篩選問題。我不覺得所有參與投票的都會跑去支持題目，這樣算下來應該能平衡流動性的問題。--路西法人𖤐 2022年3月11日 (五) 11:06 (UTC)

另一個可行方案是如上面所說，有五天收集問題（同樣容許一人多題），兩天進行問題篩選，然後僅轉發有限量的題目。甚至說，收集題目也可以匿名化，那樣就不會被「這個那個用戶提出的哦，支持／反對好了」影響。包括提問者和沒有提問的人均可兩票支持兩票反對，然後按照提問的支持率去篩選題目。這樣也可以確保題目數量對候選人而言比較可控的情況下回答具有重要性的題目。--路西法人𖤐 2022年3月11日 (五) 11:13 (UTC)

我沒有誤會這裏的意思。首先，本來每個用戶在方案一本來是可以是提出兩條問題的。但是，在新方案之下，實際上每個用戶被規定在一個問題上，只是用戶可以自由分配給誰問問題，實效來說就是一題。也就是說，實際上的問題數只會大概和投票人數之下，因為確實是有些用戶是不參與答辯的，不愛關注提問區，只是看一回就投了，然後假如是收集問題制，希望問問題的人又要以多餘的時間關注在提問之上，不然又會錯過了提問期；又或者要花時間在支持問題上，兩天支持一條問題，你實在是看得起整個社群的活動能力，中維的社群活躍度其實高度集中在百餘個用戶上，留意到與否也是一個問題。問題就是在於，在縮小題目數至一個極端的時候，實際上影響和候選人之間的交流。而且，你首先要將問題放在討論頁，然後要人支持，還需要人去確認支持的用戶是否有權，然後確定只是有一次，再放至主頁面，只是為了讓候選人回答。對於我來說就是為了換一個燈炮，然後出動了整村人，增加整倍的時間，只是為了候選人不敢果斷拒絕問題而擔心。整個方案充滿對社群的不信任。ADMIN的工作是自願的，候選人本來就沒有責任去回答所有的問題，自由權本來就應該在候選人上，而不是在社群之上。

我覺得可以探討的是沒投票權用戶提問的優次，可以像萌娘一樣明確要他們的提問是較為次要的，又或者禁止IP提問之類的。差不多IP提問都是各種傀儡，問題價值差不多就是零。--Ghren🐦🕗 2022年3月11日 (五) 12:38 (UTC)

萌娘百科那樣行得通是因為只有少數人有投票資格。在本站符合人事任免資格者眾。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年3月18日 (五) 19:11 (UTC)

即使如此，每一屆都有IP和無投權者問問題，而這些人的問題質量明顯低下。--Ghren🐦🕘 2022年3月24日 (四) 13:07 (UTC)

確實。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年4月2日 (六) 09:02 (UTC)

匿名化太難了，難不成每次都要用安全投票之類的問？--SunAfterRain 2022年3月13日 (日) 09:46 (UTC)

（沒有說必要）--路西法人𖤐 2022年3月24日 (四) 12:50 (UTC)

「所有問題均應先在討論頁提出」何也？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年3月10日 (四) 17:59 (UTC)

我猜可能是指RFA页面对应的讨论页？--Steven Sun（留言） 2022年3月11日 (五) 02:42 (UTC)

是。--路西法人𖤐 2022年3月11日 (五) 10:24 (UTC)

我的意思是，為什麼要這樣進行？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年3月11日 (五) 16:59 (UTC)

如同Temp3600下面所言，如果維基人能夠自律，當然不用……需要的原因還是因為防止灌題而已。--路西法人𖤐 2022年3月24日 (四) 12:48 (UTC)

• 支持上述的軟性規範。說到底，維基人如果能自律，就能減少這類難以設立有效規範的情況。另外，再次建議設立問題庫。--Temp3600（留言） 2022年3月17日 (四) 14:42 (UTC)
• 支持概念版。细化版或可作为指引，作方针需要评估试行再说，并且“明确要求”难以避免很多问题。“仅能支持或反对提出一条问题。”需要改掉，非常像仅有一笔投票权。--YFdyh000（留言） 2022年4月6日 (三) 16:57 (UTC)
• 能否由行政员和管理员作为提问主持人根据提问参与度选出10个以内相关度高的问题，同时根据提问数量也可再加选出5个以内呼声高的问题作为补充提问。不限制提问数量，不限制每个人的问题的入选数量。-- ★WPTO★ 2022年4月7日 (四) 01:19 (UTC)

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

提議增設文化遺產關注度

個人認為各地的文化遺產理論上應具備關注度，不單是世界遺產，國家級以至城市級的文化遺產等等也應如此，例如全國重點文物保護單位或新竹縣文化資產等等。希望得到各位的意見。--AT 2022年3月2日 (三) 20:16 (UTC)

(＋)滋磁，市级以上应该都是具备一定关注度的。--南冥大鹏👈把我批判一番出偏差要负责👊微小的工作历史的进程✌ 2022年3月2日 (三) 23:12 (UTC)

我記得我找了很久都沒找到余家老宅似樣點的來源。要是市級政府本身都沒有出版一些有效介紹的來源的話，直接算作有關注度是沒有依據的。--Ghren🐦🕚 2022年3月3日 (四) 03:33 (UTC)

不同地区的政务水平差距极大，黄山的文物保护单位属实是懒，而政府官网更是重量级，省级文物保护名录直接是403都打不开 囧rz……--南冥大鹏👈把我批判一番出偏差要负责👊微小的工作历史的进程✌ 2022年3月3日 (四) 04:54 (UTC)

@AT：現行WP:GEOFEAT的規定是“被列入國家級及以上保護名單（例如世界文化遺產、全國重點文物保護單位、國家史跡名錄等），以及獲得知名獎項的建築，只要有多於簡單統計數據的可供查證資訊，就可以假定具有關注度”，因此國家級的文化遺產在現時已被自動假定為具備關注度。地區行政區劃級別的文化遺產是否可以如此比照我認為需要審慎考慮，而且我認為至少還是得要求有多於簡單統計數據的可供查證資訊。Sanmosa _A-DWY³ 2022年3月3日 (四) 05:36 (UTC)

文化遺產不是只有建築物啊。就算不到城市級，省級也應該足夠吧。--AT 2022年3月3日 (四) 05:48 (UTC)

@AT：等會，我發現現在根本沒有人認真考慮過“文化遺產”的定義範圍：究竟這裏討論的“文化遺產”是只限物質文化遺產，還是也包括非物質文化遺產？（如果也包括非物質文化遺產的話，為文化遺產單設關注度指引是合理的）物質文化遺產與非物質文化遺產具備關注度的基本層級是否會有所不同？（例如會不會物質文化遺產的關注度假定到省級、地級是可取的，但非物質文化遺產的關注度最多只能假定到國家級、省級？）這些都是需要考慮的。Sanmosa _A-DWY³ 2022年3月3日 (四) 05:56 (UTC)

同問。我這裏只是按例子猜是建築。--Ghren🐦🕑 2022年3月3日 (四) 06:03 (UTC)

我自己是認為可以包括非物質文化遺產，而且也非常肯定世界級與國家級的文化遺產必然可以假定具備關注度。所以討論的方向其實在於那條綫在物質文化遺產與非物質文化遺產兩邊分別要拉到哪個位置。--Sanmosa _A-DWY³ 2022年3月3日 (四) 06:06 (UTC)

我原意是都包含。--AT 2022年3月3日 (四) 06:07 (UTC)

那我覺得物質文化遺產與非物質文化遺產假定具備關注度的基本層級不能拉到同一條綫上。世界級、國家或地區（非國家之獨立或高度自治政治實體）級的任何類型的文化遺產我覺得直接假定具備關注度是完全沒問題的，（實際上的）一級行政區劃級的物質文化遺產假定具備關注度也應該不會產生太大的問題，但二級或以下行政區劃級的任何類型的文化遺產、一級行政區劃級的非物質文化遺產要劃一地假定具備關注度我還是有些憂慮。Sanmosa _A-DWY³ 2022年3月3日 (四) 06:14 (UTC)

可以再討論，沒有既定立場。--AT 2022年3月3日 (四) 08:18 (UTC)

或許我這樣説：中國大陸的省會城市與其他重要城市的物質文化遺產是可以考慮收錄的，但如何界定“重要城市”是一個問題；中國大陸的省級行政區的非物質文化遺產數量極其龐大，如果不理會是否符合關注度的情況下而照單全收可能會損害條目平均品質；不是所有地方都會設置一級行政區劃級的非物質文化遺產。--Sanmosa _A-DWY³ 2022年3月3日 (四) 08:43 (UTC)

我覺得可以在省級行政區文物上放寬點獨立的規定。比如是政府有有效介紹也算之類的。大陸省級文物管理太差了，要是還是簡單資訊的規定也太寬了。--Ghren🐦🕓 2022年3月3日 (四) 09:04 (UTC)

(＋)支持--AT 2022年3月3日 (四) 15:00 (UTC)

插一句，所有国家都是按照行政区划级别对文化遗产进行保护管理的吗？--百無一用是書生 (☎) 2022年3月4日 (五) 07:13 (UTC)

總有例外吧，一些小國應該就不會分得那麼細。--AT 2022年3月4日 (五) 07:22 (UTC)

我记得之前看到过有国家（或x国）（1、2、3...）级这类的，似乎有些国家可能不按行政区划进行分级管理，而是按照一个定好的标准进行分级管理？放到这个讨论里就是几级以上的文化遗产是当然有关注度的？几级以下的是需要讨论的？--百無一用是書生 (☎) 2022年3月4日 (五) 07:32 (UTC)

最高一級就國家級吧，然後依序下去一級行政區級、城市級等等吧。以香港為例，最高級的就是法定古蹟，一級行政區等於一級歷史建築，城市級對應二級歷史建築，三級歷史建築就不算？--AT 2022年3月4日 (五) 07:42 (UTC)

這樣類比有點不妥當，“歷史建築”的地位與“（物質）文化遺產”的地位的關係在不同地方有一定的差別。--Sanmosa _{Veritas Vincit} 2022年3月8日 (二) 03:01 (UTC)

舊提案

我建議現階段將物質文化遺產與非物質文化遺產的關注度指引提案分開處理，並先處理前者。就前者而言，建議修改WP:GEOFEAT如下：

現行條文 建筑物（包括私人住宅和地产项目），如果得到了通用关注度指引所要求的第三方可靠来源的有效介绍，即可假定具有关注度。这包括对该建筑物的历史、文化、经济、建筑意义的介绍。特别地，被列入国家级及以上保护名单（例如世界文化遗产、全国重点文物保护单位、国家史迹名录等），以及获得知名奖项的建筑，只要有多于简单统计数据的可供查证信息，就可以假定具有关注度。 参考資料

提議條文 建筑物（包括私人住宅和地产项目），如果得到了通用关注度指引所要求的第三方可靠来源的有效介绍，即可假定具有关注度。这包括对该建筑物的历史、文化、经济、建筑意义的介绍。特别地，被列入國際級（如世界遗产、歐洲遺產等）、國家／地區級（如全国重点文物保护单位、国家史迹名录等）與一級行政區級（如河北省文物保护单位、亞伯達省省級歷史地標等）物質文化遺產名錄的建築，以及获得知名奖项的建筑，只要有多于简单统计数据的可供查证信息，就可以假定具有关注度。 参考資料

以上。Sanmosa _{Veritas Vincit} 2022年3月10日 (四) 08:37 (UTC)

@AT、南冥大鹏、Ghrenghren、Shizhao。在這個定義下，假如某國或行政區存在多於一個同級別的物質文化遺產名錄，那幾個物質文化遺產名錄不存在優次之分。以塞爾維亞為例，塞爾維亞的國家級物質文化遺產名錄有4個，每個名錄下依重要性再細分3個級別（具體情況可以參見en:List of heritage registers#Serbia），那在該4個名錄下各自最高的兩個級別的物質文化遺產（Exceptional Importance與Great Importance）都可以假定具備關注度【當然，我個人是覺得國家級物質文化遺產可以完全假定具備關注度，而無需考慮該名錄是否有細分不按行政區劃但按重要性劃分的分級】。Sanmosa _{Veritas Vincit} 2022年3月10日 (四) 08:48 (UTC)

我覺得不用細分。--AT 2022年3月10日 (四) 10:33 (UTC)

那我調整一下（這時候假如某國存在多於一個國家級物質文化遺產名錄，那幾個物質文化遺產名錄内的所有項目不論其分級都一律假定具備關注度）。雖然説不細分也是我的意願，但我也預感到像我原本的提案那樣細分會被質疑説是“拍腦袋得出來”的辦法。Sanmosa _{Veritas Vincit} 2022年3月10日 (四) 13:16 (UTC)

物質文化遺產不只是建築物吧？--AT 2022年3月10日 (四) 13:49 (UTC)

這樣説好像也是。我先擬個稿子。Sanmosa   2022年3月10日 (四) 14:12 (UTC)

@AT：寫了WP:關注度 (文化遺產)，基本囊括上面的提案的内容，另外因為UNESCO非物质文化遗产名录内的項目應該能毫無爭議地假定具備關注度，所以我也寫進去了。如果要分拆獨立的關注度指引的話，WP:GEOFEAT只需要移除上面的“比較條文”中標紅色的地方就可以了，不需要加標綠色的地方。Sanmosa   2022年3月10日 (四) 14:30 (UTC)

不錯，不過舉例還是藍連比較好。--AT 2022年3月10日 (四) 14:42 (UTC)

我盡可能想每個級別都舉兩個例子，而且避免為同一國家，因此實在是沒辦法。--Sanmosa   2022年3月11日 (五) 01:06 (UTC)

我想在這裏問大家幾個問題，希望大家回答，這樣有助我決定草案究竟該怎樣寫：

1. 一個項目被列入國家／地區級物質文化遺產名錄可以作為假定該項目具備關注度的條件嗎？
2. 一個項目被列入一級行政區級物質文化遺產名錄可以作為假定該項目具備關注度的條件嗎？
3. 一個項目被列入國家／地區級非物質文化遺產名錄可以作為假定該項目具備關注度的條件嗎？
4. 一個項目被列入一級行政區級非物質文化遺產名錄可以作為假定該項目具備關注度的條件嗎？

以上。@AT、南冥大鹏、Ghrenghren、Shizhao。Sanmosa _{Avec cœur} 2022年3月12日 (六) 12:53 (UTC)

个人认为1和3是无疑的，也完全支持2，对4倾向支持。不过我觉得物质文化遗产和非物质文化遗产的标准最好还是能尽量统一不做细分，长远来看这样能避免很多潜在的非议。--南冥大鹏👈把我批判一番出偏差要负责👊微小的工作历史的进程✌ 2022年3月12日 (六) 18:15 (UTC)

哎，看上去沒太多人回應，那我就確定被列入國家／地區級物質文化遺產名錄、一級行政區級物質文化遺產名錄、國家／地區級非物質文化遺產名錄都可以作為假定該項目具備關注度的條件了，一級行政區級非物質文化遺產名錄我就先不處理了。

這裏也重新明確我現在的提案：

• 將WP:關注度 (文化遺產)設為指引；
• 將WP:GEOFEAT修改如下：

現行條文 建筑物（包括私人住宅和地产项目），如果得到了通用关注度指引所要求的第三方可靠来源的有效介绍，即可假定具有关注度。这包括对该建筑物的历史、文化、经济、建筑意义的介绍。特别地，被列入国家级及以上保护名单（例如世界文化遗产、全国重点文物保护单位、国家史迹名录等），以及获得知名奖项的建筑，只要有多于简单统计数据的可供查证信息，就可以假定具有关注度。 参考資料

提議條文 建筑物（包括私人住宅和地产项目），如果得到了通用关注度指引所要求的第三方可靠来源的有效介绍，即可假定具有关注度。这包括对该建筑物的历史、文化、经济、建筑意义的介绍。特别地，获得知名奖项的建筑，只要有多于简单统计数据的可供查证信息，就可以假定具有关注度。 参考資料

以上。Sanmosa _{Avec cœur} 2022年3月15日 (二) 08:10 (UTC)

我覺得大陸的一級行政區的名單也是挺水的，大約抽了河省的十個來看，有兩個其實都不合關注度標准，而且連官方來源擴充的資料都沒有，比如說石氏家族墓、西张村遗址。我覺得假如基本資訊的什麼是排除像「曹鼐墓(A)，是位於中國河北省邢台市東王里村(B)的明代(F)古墓葬(D)，於1993年7月15日(E)公佈為省級文物保護單位(C)。」的簡單資訊，然後除了收錄這些資料之外有其他資料之外方可考慮。--Ghren🐦🕕 2022年3月15日 (二) 10:12 (UTC)

我剛想到一點是考慮假定文化遺產的創作或保有組織具備關注度？如果只有文化遺產本身符合資格，以非物質文化遺產的來源程度來推測，可能出現篇幅相對較短或者是本來就應該至適合併入至創作或保有組織來寫的情況。因此，如果不作出假定的話，那在非物質文化遺產方面，此關注度的作用可能非常有限，例如ja:来派、ja:函館市縄文文化交流センター等等。物質文化遺產方面，如果指定的只是某範圍內的部分建築或物品的話，可能會有人質疑其直屬上級主題不符合文化遺產關注度的要求，然而實際上又不可能只寫其部分建築或物品，這樣通常篇幅過短，而且不合情理。我自己雖然也覺得這可能有點杞人憂天，不過為了以防萬一，可能還是寫清楚一點比較好，比如ja:法源寺 (北海道松前町)只有山門是重要文化財，總不能只寫山門，去寫該寺的話，卻又出現無法援引此關注度的詭異情況。--AT 2022年3月15日 (二) 10:24 (UTC)

@Ghrenghren：在WP:關注度 (文化遺產)緊急補充了“且有多於簡單統計數據的可供查證資訊”的要求。@AT：那還是回到“物質文化遺產與非物質文化遺產假定具備關注度的基本層級不能拉到同一條綫上”的問題上，但這次涉及到的又是另一個範疇。“文化遺產的創作或保有組織具備關注度”（A）就非物質文化遺產而言，我個人是認可的，類似的概念應該是像非物质文化遗产代表性传承人這樣的，我覺得收錄無可厚非，但（B）就物質文化遺產而言，我個人並不認可，“可能會有人質疑其直屬上級主題不符合文化遺產關注度的要求”這完全不用“可能”，文化遺產的直屬上級主題除非自身也是文化遺產，否則不會符合文化遺產關注度的要求，就像你舉出來的那個jawiki條目的例子，條目内容如此單薄，我真看不出來這樣的内容能讓讀者有甚麽資訊上的獲益，這種情況下我真心覺得不要寫比較好。Sanmosa _{Avec cœur} 2022年3月16日 (三) 01:59 (UTC)

日維條目是單薄沒錯，但是這並不代表此東西可以寫的內容就是這麼少。例如《日本歷史地名大系》便有收錄此佛寺，字數更達1300字之多，松前町也有對其作出介紹，我自己手裡的《日本名剎大事典》以及《北海道大百科事典》也有收錄此佛寺。然而這也不是重點，重點仍然在於目前文化遺產關注度的有效範圍只限於山門，不包含寺，實際上卻又不可能只寫山門不寫寺。如果連您這樣的資深用戶也注意不到此主題實際是否有收錄價值，單純只看到外文條目單薄就覺得不值得寫，然後這些主題又得不到文化遺產關注度的保障的話，那可以想像到有多少實際上有意義的條目將會不經不覺地消失。也就是說，只寫物質文化遺產（例如山門）本身可能會造成篇幅過短，而且必然地不夠全面，導致有礙理解，同時又會導致部分物質文化遺產有建條目的權利，卻發揮不到條目應有的作用，這種情況下編寫上級主題去把有關連的文化遺產都放在一起介紹我認為是比較合適的（例如瑞龍寺 (高岡市)雖然沒有日本國史跡指定，但是其中的建築物很多都是重要文化財，甚至是國寶，要全部分拆來寫並不現實），而且保有這些文化遺產的組織往往具備關注度，就如我隨便找的法源寺一樣，只是僅通過網絡來源去驗證的話存在一定的難度罷了。在這些情況下，文化遺產關注度能夠發揮的作用非常有限，這類主題還是挽救不來或是無法作出快速判斷，這不是我的本意。--AT 2022年3月16日 (三) 13:32 (UTC)

我覺得整件事件風險太大了。首先要假定物質遺產有關注度，然後再去假定這個持有者有關注度，整個設計上是矛盾的。專題關注度不宜去將太多的東西一環套一環。假如是這個情況我建議是直接使用通用關注度研判。我實在沒有自信說得出文化遺產的持有者必要有關注度的之類的說詞，本質上這個關注度己經多多少少有為早期機器人寫的條目開綠燈的意味了。在大陸一級行政區以大省來說假定有關注度還說得去，畢竟還有相當的專著，但是小省就實在沒有什麼理想的來源。特別是非物質遺產，他們的管有者是可以變動的，未必說真的和他們的管有者有很大的關連，如果按關注度不是一時的原則，我感覺會有很多奇怪意想不到的情況出現。我覺得按現行寫法「在這些主題關注度不明確的情形下，通常可以將相關內容寫入一篇主題更廣泛的文章，例如某一隧道的資訊可以寫入其所屬的道路或其穿越的山脈中去。」，這樣就不錯了，要是法源寺有關注度就併過去，要是沒有就沒有。--Ghren🐦🕘 2022年3月16日 (三) 13:59 (UTC)

我問一個問題，如果有人寫了個法源寺山門，以至是瑞龍寺山門、瑞龍寺大茶堂什麼的，在您無法驗證法源寺和瑞龍寺是否具備關注度的情況下，請問要怎麼辦？況且，如果某地的文化遺產制度有問題的話，那應該對該地施加限制，甚至排除，而不應反過來將其他地方的文化遺產制度拉下水。--AT 2022年3月16日 (三) 14:14 (UTC)

首先要決定大家討論的前提是重要文化財都有關注度還是怎樣的。假設重要文化財有關注度的話，就應該預計有一定的文字去陳述這個物體，也就是說不論是以官方來源也好，帶利益衝突的來源也好，應該預計有一定的文字量。如果沒有，這個規制就不要定為好。也就是說這個山門本身按理來說應該還是有什麼的內容，假如是後邊的情況，當一個建築所包含的物質文化遺產考慮有關注度可以考慮一下。--Ghren🐦🕚 2022年3月16日 (三) 15:24 (UTC)

文字量按不同主題必然會存在變化，足夠多的當然應該獨立成篇，不夠多的就應與上級條目一同編寫，以便整理。例如對法源寺山門的介紹實在不多，根據已知來源，我認為應該與法源寺結合起來編寫。這也不僅僅是法源寺的問題，重要文化財有別於日本國史跡，絕大多數均不是全體指定，目前的條文對於部分指定的文化遺產方面，涵蓋不到全面性的問題，反而可能會導致有人建立大量瑣碎條目，得不償失。--AT 2022年3月16日 (三) 16:32 (UTC)

【我一同回應你前面幾個留言】法源寺如果是這種情況的話就根本無需考慮文化遺產關注度指引了，GNG已經能夠處理，而各關注度指引本身並不限制將相關内容放在同一條目敘述（“編者不應以本指引作為建立條目的唯一依據。即使符合條件，也不一定需要為其建立獨立條目”）。Sanmosa _{Avec cœur} 2022年3月17日 (四) 02:20 (UTC)

這是當然的，不過就像我先前所說的一樣：「如果連您這樣的資深用戶也注意不到此主題實際是否有收錄價值，單純只看到外文條目單薄就覺得不值得寫，然後這些主題又得不到文化遺產關注度的保障的話，那可以想像到有多少實際上有意義的條目將會不經不覺地消失。（中略）就如我隨便找的法源寺一樣，只是僅通過網絡來源去驗證的話存在一定的難度罷了。在這些情況下，文化遺產關注度能夠發揮的作用非常有限，這類主題還是挽救不來或是無法作出快速判斷，這不是我的本意。」--AT 2022年3月17日 (四) 03:52 (UTC)

見下。--Sanmosa _{Avec cœur} 2022年3月17日 (四) 06:59 (UTC)

你給出來的前提是我沒辨法確認法源寺有沒有來源。我沒法確認自然是假定是沒有來源的，沒有來源自然就沒有可能成為主條目的價值。要是反過來法源寺有來源的話，自然就應該以法源寺為主題。要是法源寺本身真的沒有來源，在山門前面加上一句「法源寺在日本某處，其內的山門是重要文化財」不會使文章質量增加。反而會引致頭重腳輕的問題。--Ghren🐦🕐 2022年3月17日 (四) 05:19 (UTC)

對，我也是這個意思。--Sanmosa _{Avec cœur} 2022年3月17日 (四) 07:03 (UTC)

沒有來源跟沒有關注度來源不是同一回事，找後者要比找前者要難，我想這很清楚。另外，仍然是同一個問題，如果有人以文化遺產關注度創建法源寺山門，以至是瑞龍寺山門、瑞龍寺大茶堂等等，請問應如何處埋？我擔心的是有人不知就裡，將部分指定的文化遺產逐一創建的話，顯然地對於理解整個主題方面存在相當的困難，也不是條目應有的風格。至少我認為在「山門前面加上一句「法源寺在日本某處，其內的山門是重要文化財」」也比有人只創建法源寺山門要好得多。如果要我類比的話，這跟WP:MUSIC中的音樂家與音樂團體的關注度定義類同，重要文化財就好比金唱片，佛寺與山門之間的關連程度相信不遜於音樂家與唱片之間的關連度。換成音樂關注度的話，您現在的意思好像就是在說唱片可以獨立成條目，但是音樂家則不能。--AT 2022年3月17日 (四) 13:21 (UTC)

金唱片可以合理預期作曲家至少會有一些其他作品，但是文化遺產不會有。文化遺產可以預期大多數時間是非商業性質的，關注在其建築本身，而管理機構完全可能是商業或者私人的，不可互比。建議我己經給在了上方了。--Ghren🐦🕙 2022年3月17日 (四) 14:22 (UTC)

我的見解是管理文化遺產的組織本身也絕大多數具備關注度，只不過來源難找，就如法源寺一樣，所以我認為與音樂關注度是完全可以類比的。而且，您說的這種我姑且稱為主從關係，但是像山門本身就是佛寺的組成部分，這樣的密切程度已經完全超越主從關係，在無法只寫法源寺山門的情況下，如要編寫此主題的話，在寫佛寺的時候同時介紹山門才是一般條目應有陳述方式。另外，一個組織也可以有多於一項的文化遺產，例如法源寺古文書就是松前町指定文化財，瑞龍寺的文化遺產數目更是多不勝數，所以您這個合理預期本身也可以，甚至是應該套用到文化遺產上。文化遺產最大的特徵就是隨著時間流逝，其存在價值自然地與日俱增，今後只要建築物尚存，就有可能獲得指定，所以如果金唱片也可以算是合理預期的話，那文化遺產的合理預期程度比金唱片還要高，畢竟文化遺產今後獲指定的可能性比舊唱片突然大賣的可能性要高。--AT 2022年3月17日 (四) 15:16 (UTC)

反之，如果無法就此問題達成共識的話，所有部分指定的文化遺產均不應在文化遺產關注度的適用範圍之內。也就是說，法源寺不能根據此關注度來建條目的話，法源寺山門也不行。--AT 2022年3月17日 (四) 15:33 (UTC)

《中华人民共和国文物保护法》将文物分为可移动文物和不可移动文物，建议WP:關注度 (文化遺產)的物质文化遗产小节加入类似国家一级文物等可移动文物陈述。--Kethyga（留言） 2022年3月27日 (日) 15:43 (UTC)

@Kethyga：完成（但我增補了另一個例子）。Sanmosa _{Avec cœur} 2022年3月29日 (二) 04:12 (UTC)

下面的传承者小节是否可以添加国家级非物质文化遗产代表性传承人列表（共3063人，5人资格取消）？资料可能来自[3]（中国非物质文化遗产网）--Kethyga（留言） 2022年3月29日 (二) 09:32 (UTC)

我覺得相關概念不難理解，不至於需要舉例説明。Sanmosa _{Avec cœur} 2022年3月29日 (二) 12:03 (UTC)

WP:SIGN矛盾

章節「簽名的外觀和顏色」「HTML/XML標籤」：

此外，由於技術原因，您不應在簽名中使用……過時的HTML標籤（注：包含<font></font>）

章節「簽名的外觀和顏色」「長度」：

雖然如此會使用到W3C已經鼓勵用<span>來取代的<font>元素，不過在瀏覽器依然相容的情況下，仍然可以這麼做。

嚴重矛盾。至於保留何者，我無法定奪，提請討論。--Wiki emoji | 😷🅔🅜🅞🅙🅘🅦🅘🅚🅘😷 _{祝百毒不侵～} 2022年3月3日 (四) 00:16 (UTC)

技术与方针的矛盾，但是font只是作为span需要调色时允许的兼容替代品，应该只是“允许特例，但不建议常理”？。——Sakamotosan路过围观 | 避免做作，免敬 2022年3月3日 (四) 00:52 (UTC)

现在不支持CSS的浏览器还能访问维基百科？--Steven Sun（留言） 2022年3月3日 (四) 02:44 (UTC)

不是，是CSS2和CSS3、HTML4和HTML5的分別 Wiki emoji | 😷🅔🅜🅞🅙🅘🅦🅘🅚🅘😷 _{祝百毒不侵～} 2022年3月4日 (五) 00:12 (UTC)

可討論是否禁用過時標籤。先前看到有機器人在批次改掉簽名的過時標籤，因為lint error。—- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年3月11日 (五) 10:18 (UTC)

• mw:New_requirements_for_user_signatures#Proposal:_signature_validation_requirements_(2020)，簽名不能有Special:Lint錯誤；過時的HTML標籤，應禁止。-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年3月13日 (日) 03:55 (UTC)
• @cwek、Emojiwiki、Steven Sun：見phab:T140606此工單，有Special:Lint錯誤與過時的HTML標籤的簽名應被禁止，因為未來簽名識別工具將不支援，硬是使用等於繞過系統簽名辨識工具。同時Ping上次討論關於「phabricator自2019年起逐漸更新簽名限制」議題（存檔）的用戶：@Temp3600、SunAfterRain、Sanmosa、Ochloese、Xiplus：@1233、Ghrenghren：如無異議，應根據上次關於「phabricator自2019年起逐漸更新簽名限制」議題（存檔）的作法，刪除「允許在簽名中使用過時的HTML標籤」之條文。-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年3月13日 (日) 04:07 (UTC)

  這樣的話就應該刪掉再換掉例子。--Ghren🐦🕛 2022年3月13日 (日) 04:09 (UTC)

  只有部分的lint error被系統禁止，font似乎不在目前的禁止項目之內。--Xiplus#Talk 2022年3月13日 (日) 04:35 (UTC)

  • 未來會逐步淘汰，建議現在應該要「不鼓勵使用」。-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年3月13日 (日) 04:42 (UTC)

  但從REST BASE（/w/rest.php/zh.wikipedia.org/v3/transform/wikitext/to/lint，define at here，new mw.Rest().post("/zh.wikipedia.org/v3/transform/wikitext/to/lint",{wikitext:"<your signature here>"}).always(console.log);）似乎font標籤也被列入黑名單了--SunAfterRain 2022年3月13日 (日) 08:47 (UTC)

  • (！)意見與其一個一個標籤在那邊測試能不能用，不如直接禁止使用過時的標籤。—- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年3月13日 (日) 08:55 (UTC)

     吐槽：你直接一坨標籤都拿去請求啊，Linter又不是每次只返回一個問題 囧rz……--SunAfterRain 2022年3月13日 (日) 09:48 (UTC)

    @SunAfterRain：你誤會了，我的意思是不可能測一測後給指引列一堆「例外」。如果指引要列一大堆例外，那不如不要這樣立。-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年3月21日 (一) 10:58 (UTC)

    喔喔誤會了。--SunAfterRain 2022年3月22日 (二) 12:01 (UTC)

    所以要怎麼修-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年3月29日 (二) 13:18 (UTC)

章節「簽名的外觀和顏色」「外部連結與模板」：

但是，還是希望您能將簽名簡化，空出更多寶貴的伺服器資源，協助維基百科繼續發展。

不要擔心性能！這句大可移除，或者至少不是空出伺服器的而是客戶端的GPU資源。 Wiki emoji | 😷🅔🅜🅞🅙🅘🅦🅘🅚🅘😷 _{祝百毒不侵～} 2022年3月3日 (四) 00:19 (UTC)

前后语境不同吧，这一句是对应“签名使用模板的话尽量subst，而不是嵌套引用”，因为“嵌套引用”浪费解析性能，并不冲突。PS.感觉在揪字眼？——Sakamotosan路过围观 | 避免做作，免敬 2022年3月3日 (四) 00:46 (UTC)

引用回不要担心性能的话“服务器资源确实很重要，但那是系统管理员们的事情，不要以自己对性能的理解来说事。”，简单就是，签名你可以弄的花里胡哨，但被基金会的系统管理员以性能理由介入的话，那就是严重的问题，请协助处理。最好签名简单点，太花里胡哨、炫技的签名在一堆讨论里面找结尾也挺麻烦的。——Sakamotosan路过围观 | 避免做作，免敬 2022年3月3日 (四) 01:00 (UTC)

• 儘管理由是有點牽強，但鼓勵使用簡單的簽名是維基的既定政策。在想到更適合的語句前，我反對移除本條。--Temp3600（留言） 2022年3月13日 (日) 11:57 (UTC)
  • 同意-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年3月21日 (一) 10:56 (UTC)

開放在簽名中使用模板

技術限制無法實施：

phabricator自2019年起逐漸更新簽名限制，導致目前MW系統拒絕在簽名用模板的，系統同時也不允許subst後仍是同個模板的特殊模板，也就是說此案就算通過也會礙於技術限制而無法實施-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年3月13日 (日) 04:17 (UTC)

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

---

（標題添加）-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年3月13日 (日) 04:10 (UTC)

其实我觉得如果没有安全隐患，模版签名挺好的，每个人都有一个签名模版，代码本身反而会减少很多。想换签名时，不准修改旧模版（永久全保护）直接换一个模版，也不会有缓存废除的性能问题。Bluedeck 2022年3月4日 (五) 08:21 (UTC)

@Bluedeck：但現行的規定是「一旦留言儲存編輯後，簽名不能發生變化」，那麼如果用了模板，模板就必須全保護，創建者也不能編輯，就會導致使用者如果要改簽名，就只能再創新的模板（編輯請求就違反簽名方針「一旦留言儲存編輯後，簽名不能發生變化」），也就是到時每個使用者會產生大量簽名模板（假如想常換簽名），這樣不太好吧。-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年3月10日 (四) 04:48 (UTC)

不是所有人都会更换很多签名吧 囧rz……我觉得一年内换四到五次已经算是最大值了。--Yining Chen（留言|签名页） 2022年3月10日 (四) 14:55 (UTC)

@Yining_Chen：一年內換5次，兩年就產生了10個模板了耶；萬一簽名模板筆誤了怎麼辦？-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年3月11日 (五) 05:18 (UTC)

我還是認為即使全保護了可能還是會有違反「一旦留言儲存編輯後，簽名不能發生變化」的狀況。比如簽名模板中引用了其他模板，難道需要連鎖保護？如果把自己的簽名模板CSD掉或移動，那先前的簽名將顯示為紅鏈，不就也違反了「一旦留言儲存編輯後，簽名不能發生變化」-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年3月11日 (五) 05:15 (UTC)

系統的許多功能、小工具和機器人等等辨識簽名的方法並不允許這麼做，無法妥善的辨識簽名模板。--Xiplus#Talk 2022年3月4日 (五) 13:02 (UTC)

魔術字（如{{!}}）的使用似乎沒有問題（不然為啥很多年前就有Wikipedia:签名#其他這段，也未見有功能、小工具和機器人出問題的討論），問題應該是出在「|」符號，即模板參數，代表純粹{{...}}的解析是沒有問題的，但{{...|...}}可能會有狀況。或許可以禁止簽名模板使用參數。-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年3月4日 (五) 16:55 (UTC)

不是說支持放寬（暫時中立），但辨識簽名模板方面，只要簡單規定模板必須得在用戶頁的子頁面的話，其實不難修改小工具和機械人，簡單把辨識用戶連結的REGEX改成同時辨識(?:\[\[|\{\{)而已吧。回覆工具等功能方面，他們是認HTML連結的（你用外部連結他也能給你認出來），回覆工具就不太會有問題。--路西法人𖤐 2022年3月10日 (四) 02:18 (UTC)

• (：)回應「簡單把辨識用戶連結的REGEX改成同時辨識(?:\[\[|\{\{)而已」@LuciferianThomas：：不是吧。先前就有人簽名用魔術字（如{{!}}）了，且好幾年前到上個月都有，且未見有功能、小工具和機器人等等辨識簽名的功能出問題，說明符號{不是問題啊。-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年3月10日 (四) 04:33 (UTC)

  大家都在說{{User:Example/sign}}這種模板，不是{{!}}啊……你完全理解錯誤了啊。--路西法人𖤐 2022年3月10日 (四) 04:35 (UTC)

  @LuciferianThomas：不是阿，{{User:Example/sign}}在原始碼就是{組成的阿，所以如果含有{的簽名沒有出錯，那問題就不會是出在REGEX是否要補上{符號這個問題啊。-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年3月10日 (四) 04:37 (UTC)

  ……不是。正常來說簽名是要{{subst:User:Example/sign}}，要替換使用，沒有人會把{{User:Example}}放在簽名吧，{{User:Example/sign}}現在也尚不合規，辨認簽名原始碼必然是內部連結[[User:Example]]的方括號，跟簽名其餘部分是否含有{沒有半點關聯。--路西法人𖤐 2022年3月10日 (四) 04:42 (UTC)

  如果是解析用戶名的問題可以要求原始碼要有直接連向用戶頁的連結之規定阿-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年3月10日 (四) 04:39 (UTC)

  你似乎不知道問題在哪裏。嵌入的模板有用戶頁連結，但在原始碼的部分直接使用簽名模板而不替換是不會無端有用戶頁連結的，以往也不會刻意擴展模板再辨認簽名（因為有直接的內連）。同學你是完全錯誤理解問題所在了啊。--路西法人𖤐 2022年3月10日 (四) 04:45 (UTC)

  @LuciferianThomas：你沒有理解我說的，我是說「儲存在討論頁的原始碼」要有「直接連向用戶頁的連結」，而不是模板裡。-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年3月10日 (四) 04:52 (UTC)

  那你就是沒理解我第一則留言所說的，只要簡單規定模板必須得在用戶頁的子頁面的話，嵌入用戶(子)頁也算是直接連向用戶頁的連結。--路西法人𖤐 2022年3月10日 (四) 04:57 (UTC)

那樣怎麼區分一般的使用者頁面嵌入還是簽名模板？--Xiplus#Talk 2022年3月10日 (四) 04:42 (UTC)

直接地說，不用管用戶用什麼子頁面名稱，你用戶頁不符合簽名標準的一定會先被罵，然後工具或機械人原始碼找(?:\[\[|\{\{)(?:U(?:ser)?(?:[ _]t(?:alk)?)?\:|Special:(?:(?:用戶|使用者)貢獻|用户贡献)\/)([^\|\]\}\/\#]+)辨認用戶頁連結或嵌入用戶頁面就行了。--路西法人𖤐 2022年3月10日 (四) 04:55 (UTC)

那如果嵌入了非簽名模板的頁面作為留言的一部分，但忘了嵌入簽名模板，那究竟是有沒有簽名呢？那要怎麼判斷呢？--Xiplus#Talk 2022年3月10日 (四) 04:59 (UTC)

這個我覺得可以算成有簽名但簽名不符合規則（必須附有任一用戶頁頁面連結、不能超過255位元等規則）。另外還有日期時間那些也包含在~~~~的簽名裡，這個就能判斷了。--路西法人𖤐 2022年3月10日 (四) 05:12 (UTC)

那如果嵌入其他人用戶頁不就會被算成別人的留言了嗎？--Xiplus#Talk 2022年3月10日 (四) 05:14 (UTC)

以现在的程序，如果在留言后不加自己的签名，而是加上 User:Example（User talk:Example）~~~~~ ，也会出问题吧 --Yining Chen（留言|签名页） 2022年3月10日 (四) 15:06 (UTC)

re Xiplus，會，不過就是冒簽，等同一般簽名中加入別人的連結一樣道理，跟現在的處理不會有什麼分別。--路西法人𖤐 2022年3月11日 (五) 10:23 (UTC)

「{{User:Example/某留言模板}}--~~~~」可以，「{{User:Example/某留言模板}}--{{User:Xiplus/簽名}}~~~~~」不行，是什麼道理？--Xiplus#Talk 2022年3月11日 (五) 10:42 (UTC)

嗯？不同啊，後面那個是可以的啊，不在簽名範圍內嘛（尤其還有兩個橫線分辨出來的時候）。我這個留言中包含了User:Xiplus這個連結不代表我冒充你的身份簽名啊。另外，（機械人和工具）邏輯上也是應該看最後一個連結用戶頁連結或模板，就像我這個留言就當成是Xiplus君你的留言了嗎？理論上是應該不會的，也是不通的道理。編程邏輯上，只要最後一個連結符合就沒問題；在規範上，只要你每個簽名都包含的部分（我的是路西法人）不包含其他用戶的連結就行，前面其他用戶的連結也好模板也好都是留言的一部分而已，不算是簽名啊。--路西法人𖤐 2022年3月11日 (五) 15:23 (UTC)

这些问题确实都有道理，我又觉得模版签名不是个好主意了 Bluedeck 2022年3月12日 (六) 15:19 (UTC)

不是想潑大家冷水，但是MW系統現在是拒絕在簽名用模板的，就算在參數設置把簽名設定為模板如{{User:Example/sign}}，保存後系統都會自動強行safesubst一次。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年3月12日 (六) 17:15 (UTC)

• 難怪上次討論要禁止「"nested" substitution」（即safesubst後還是原本模板的情況，如{{Unsubst}}防止替換引用的模板），mw:New_requirements_for_user_signatures#Proposal:_signature_validation_requirements_(2020)。那這個討論可以以「技術限制」為由關閉了。-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年3月13日 (日) 03:59 (UTC)

---

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

圖片

@Bluedeck：那麼您對於開放使用File名字空間的引用（如圖片）有什麼看法？-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年3月13日 (日) 04:30 (UTC)

圖片可被重新上傳更新內容，跟模板同理。--Xiplus#Talk 2022年3月13日 (日) 04:51 (UTC)

簽名用圖片全保護？—- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年3月13日 (日) 05:16 (UTC)

絕大多數的圖片都在共享資源上，我想應該不是本地可以用此理由干涉的。--Xiplus#Talk 2022年3月13日 (日) 06:27 (UTC)

另外Wikipedia:签名#外观也列出了5個理由，您全都不同意嗎？--Xiplus#Talk 2022年3月13日 (日) 06:37 (UTC)

@Bluedeck：—- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年3月13日 (日) 06:39 (UTC)

设立站务维基

於Phabricator查看
編號T299590的任務

在下提议设立本站的站务用维基。前期讨论存档在此，概述如下：去年LTA模仿犯泛滥，困扰站务，故在下重提设立LTA命名空间。后由于此提议不可行，社群转而讨论设立LTA维基的可行性，部分建议认为新维基用途不宜局限于LTA，并提出站务维基的构想。另外，设立站务维基也有配合IP masking等方面的考虑。

目前站务维基设立大致需要讨论两方面内容：

1. 是否应设立，或只作为LTA维基
2. access的门槛和申请方式（CA志愿者认为不能SUL）

以上。 ——魔琴 [ 留言 贡献 ] 2022年3月4日 (五) 16:12 (UTC)

仍然認為沒有設立之必要。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年3月4日 (五) 18:29 (UTC)

根据雪球法则 ,(－)強烈反对--Pavlov2（留言） 2022年3月5日 (六) 18:57 (UTC)

我上次來都沒留意到，雪球法則不是隨便拋出來就用來反對提案什麼的，你好歹也解釋一下吧。--路西法人𖤐 2022年3月15日 (二) 13:33 (UTC)

改票( ✓ )同意。sysop们辛苦了----仁爱亲诚的Pavlov2 2022年3月17日 (四) 15:50 (UTC)

反破壞工具的建立刻不容緩。-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年3月29日 (二) 13:21 (UTC)

雞肋。不會反對，但是不值得投入心力。--Ghren🐦🕐 2022年3月7日 (一) 05:28 (UTC)

不反對，雖然上次是說有條件支持，但還是覺得必要性不大。要兩個維基之間切換以進行同一項目的維護工作偏麻煩。--路西法人𖤐 2022年3月8日 (二) 02:49 (UTC)

• 疊床架屋很好玩？-某人✉ 2022年3月12日 (六) 03:58 (UTC)
  • @AINH、Pavlov2：您可能有所誤會。這是去年年初的命名空間案，當時討論的MOS、LTA和維基專題，維基專題順利成為名字空間；LTA命名空间雖然公示通過，但LTA命名空间因技術限制（僅特定權限的用戶能訪問特定名字空間的擴展不會在任何維基站點部屬這跟當時WP:修訂巡查狀況很像，本地公示通過，但基金會技術人員說「此擴展不會在任何維基站點部屬」。）而無法實施，被phab人員拒絕部屬，phab:T299546，而基金會技術人員則建議創立新維基來達成「僅特定權限的用戶能訪問」的等價效果（先例 https://sysop-it.wikipedia.org phab:T256545）。phab:T299590。-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年3月12日 (六) 04:18 (UTC)
    • @AINH：簡而言之，這並非疊床架屋，而是去年的已通過的共識的提案，被基金會技術人員評估技術上可能有困難，而建議的折衷方案，與其說疊床架屋，我認為更是需求和工程師實作之間的衝突。同時基金會技術人員提出的折衷方案因與原始社群共識通過的提案有所不同，因此基金會技術人員才叫我們社群再討論一次，然而現在大家因不了解實情又反悔，這樣對基金會技術人員工程師很不禮貌。-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年3月12日 (六) 04:31 (UTC)
      • 大家同意的技術上不可行的方案跟大家不同意的技術上可行的方案可是兩回事。這只體現本地立法常常未有諮詢技術意見的無奈事實而已。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年3月12日 (六) 09:28 (UTC)
        • (：)回應@Ericliu1912：並非未有諮詢技術意見。相關擴展去年U:魔琴去meta問過了，他們說可以跑跑看流程，結果共識出來提到PHAB後卻變成「此擴展不會在任何維基站點部屬」；上次的Wikipedia_talk:修訂巡查#引入修訂巡查_(重提編輯審核/穩定版本)也是，一開始PHAB也有再嘗試弄，但弄到一半又變成「此擴展不會在任何維基站點部屬」；Help:圖書也是，通過共識後說甚麼pdf繁簡轉換系統爆了，所以不部屬。怎麼能說「並非未有諮詢技術意見」？是他們評估不夠全面吧。-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年3月12日 (六) 10:42 (UTC)

          @A2569875：他是說要有人維護吧（修訂巡查是寫最早版本的人的錯，要在其他地方用得有人重寫）--SunAfterRain 2022年3月13日 (日) 09:29 (UTC)

          • 結論還不是都「此擴展不會在任何維基站點部屬」，照樣就是無法使用。-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年3月20日 (日) 07:28 (UTC)

Correction：LTA命名空间没过公示，但只是技术原因，本地在公示期间未提出其它反对意见。上次讨论站务维基的时候一片绿色，我重提一下又反应平平 囧rz…… ——魔琴 [ 留言 贡献 ] 2022年3月12日 (六) 11:58 (UTC)

• 不反對-某人✉ 2022年3月12日 (六) 22:00 (UTC)

不反对。--在下荷花，请多指教（欢迎签到） 2022年3月21日 (一) 12:50 (UTC)

---

鉴于无反对意见，且即使计入讨论FlagRev的留言也已两次触及WP:7DAYS，故🕗 公示设立站务维基，为期7日，2022年4月9日 (六) 15:35 (UTC) 結束。 ——魔琴 [ 留言 贡献 ] 2022年4月2日 (六) 15:35 (UTC)

是不是應該討論了一些基本規則才公示較妥。--Ghren🐦🕛 2022年4月2日 (六) 16:33 (UTC)

(－)反对：我不認為現階段值得建立獨立於本站的系統。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年4月3日 (日) 05:38 (UTC)

你就當作這只是一個新命名空間，只是這個「命名空間」放得比較「遠」。且本案原先就是命名空間案，但是被基金會技術人員說技術限制提出的折衷方案。—- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年4月3日 (日) 06:14 (UTC)

且不認為是「獨立」只是為了做檢視權限管控。且這也是本意—- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年4月3日 (日) 06:15 (UTC)

兩個站就是兩個站。分開的必要性為何？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年4月3日 (日) 14:57 (UTC)

欲设置限制检视权限只能分设一站。 ——魔琴 [ 留言 贡献 ] 2022年4月5日 (二) 01:03 (UTC)

目前(－)傾向反對，架构和细节缺乏讨论，过于模糊。历史数据迁移会是麻烦事。打算如何避免门槛过高或过低、复制泄露内容？phabricator中有人提到基于Toolforge的工具，是否有可能。--YFdyh000（留言） 2022年4月3日 (日) 09:26 (UTC)

• 鑑於目前出現明確反對理由，公示暫停直到共識重新產生。--拒食木瓜 2022年4月3日 (日) 13:00 (UTC)

  应该先讨论（1）放在哪里，可以是WMF production、Cloud VPS或者Toolforge；（2）用途：只用于放LTA还是其他和站务相关；（3）名称：zh-lta/zh-internal/zh-maintanence等等。明确之前不应该立即公示。--GZWDer（留言） 2022年4月4日 (一) 18:16 (UTC)

  更关键的是，如何保障数据安全（完整性和防泄露），进入门槛是明确还是模糊审核，不然只是将数据转入看似安全的黑箱。--YFdyh000（留言） 2022年4月4日 (一) 18:42 (UTC)

  Toolforge上放不了MediaWiki实例吧。Cloud VPS的效果可以参考一下这个站点，但存在一个比较麻烦的问题是依赖于少数社群成员的维护（换句话说如果维护者不活跃了就很麻烦）。如果是如phab提案那样放到s5的话，那整体流程可以参考意大利语那个现成的例子。另外还需要确认的是准入门槛的问题。 Stang^★ 2022年4月5日 (二) 00:43 (UTC)

提议引入CSD:U5

在英文维基中，CSD：U5是常用于删除与维基百科无关的用户页的快速删除的理据。在中文维基中似乎缺乏相关的用户页面快速删除准则，致使部分明显违例的用户页面需要使用存废讨论，乃至多次存废讨论。

U5. Blatant misuse of Wikipedia as a web host

Pages in userspace consisting of writings, information, discussions, or activities not closely related to Wikipedia's goals, where the owner has made few or no edits outside of user pages, except for plausible drafts and pages adhering to Wikipedia:User pages#What may I have in my user pages?. It applies regardless of the age of the page in question.

Before placing this template or deleting a page under this criterion:

Read Wikipedia:User pages#Handling inappropriate content and Wikipedia:User pages#Deletion of user pages.

Consider blanking pages with a significant history unrelated to the content that is being deleted.

For draft articles that are on a user's main page and which do not otherwise qualify for speedy deletion, consider moving it to a sub-page.

机械翻译大概是这样的

U5. 公然滥用维基百科作为网络空间

用户空间中的页面由与维基百科目标不密切相关的文字、信息、讨论或活动组成，所有者在用户页面之外几乎没有进行编辑，除了看似合理的草稿和遵循Wikipedia:用戶頁

无论相关页面的持续存在的日期如何，它都适用。

在放置此模板或根据此标准删除页面之前： 阅读wp:UPNOT和WP:D-UP。

考虑将具有与正在删除的内容无关的重要历史记录的页面清空。

对于用户主页上的草稿文章并且不符合快速删除的条件，请考虑将其移至子页面。

引入这一CSD可能能加快部分涉及用户页面的删除争议问题的解决速度？

--Pavlov2（留言） 2022年3月5日 (六) 19:03 (UTC)

支持引入。--Jhstriver（留言） 2022年3月9日 (三) 02:43 (UTC)

有「刪除爭議問題」不就應該在存廢討論中討論嗎？此提案很矛盾喔。--Xiplus#Talk 2022年3月9日 (三) 07:16 (UTC)

如果這話是在2021年OA前說的話，我會同意，但現在這種情況我覺得「刪除爭議問題」未必存在。Sanmosa _{Veritas Vincit} 2022年3月9日 (三) 13:48 (UTC)

实质上，所谓的“删除争议问题”并非争议，

本身就严重违反用户页方针的用户页面也能多次在本地得到保留，甚至AFD不通过，是某种变相的拉票或管理战的结果。--Pavlov2（留言） 2022年3月10日 (四) 07:01 (UTC)

社群在用户（子）页面是否符合（快速）删除要求这一点上无明确共识。--东风（留言） 2022年3月9日 (三) 08:32 (UTC)

對於被濫用的用戶空間頁面是否符合快速刪除要求並無（明確）共識的原因是從未就此進行針對性的討論。對於被濫用的用戶空間頁面是否符合刪除要求並非並無共識，至少OA後的多個AFD都已經明確支持刪除被濫用的用戶空間頁面。Sanmosa _{Veritas Vincit} 2022年3月9日 (三) 13:50 (UTC)

部分WMC成员或非WMC成员，持续地用户页滥用，由于中文百科缺乏这方面的方针，因而多次以无共识逃避删除。这正是提出引用此类CSD的直接原因。

感谢阁下的指点--Pavlov2（留言） 2022年3月10日 (四) 06:59 (UTC)

不明所己，這樣的話你修錯位置了。--Ghren🐦🕖 2022年3月10日 (四) 11:31 (UTC)

注意U5的適用限制：「所有者幾乎衹編輯用戶頁面，不計看似合理的草稿和遵循WP:UP的頁面。」這CSD不是用來快速處理內容有爭議的用戶頁（例如判斷是否違反WP:UPNOT之12，經存廢討論較為適宜），而是用來處理例如已因WP:NOTHERE或WP:GAME（用戶頁刷編輯數）為由封禁的用戶的用戶頁，較無爭議。引入U5亦無妨，但目前此類情況似乎並未泛濫到需要專屬CSD處理（？）。引入CSD不能加快處理任何爭議，因為CSD向來衹能用於毫無爭議之處。--$\definecolor {my}{rgb}{0.04,0,0.5}\color {my}{\mathsf {htc_{23}}}$（留言） 2022年3月10日 (四) 12:04 (UTC)

【1】本地化時可以調整相關適用限制。【2】有關刪除被濫用的用戶空間頁面是否有爭議這點，請參見我與Pavlov2對Xiplus於2022年3月9日 (三) 07:16 (UTC)的留言的回應。Sanmosa _{Veritas Vincit} 2022年3月10日 (四) 13:35 (UTC)

完全認同【1】，但不贊成放寬。關於【2】，刪除被濫用的用戶空間頁面沒有爭議，但是頁面是否屬於濫用可能存在爭議；也認同對於一些頁面，「刪除爭議問題」未必存在，此時存廢討論將輕易通過，例如「OA後的多個AFD都已經明確支持刪除被濫用的用戶空間頁面」，但是，「刪除爭議問題」雖然未必存在，仍可能存在，每個頁面狀況不同，支持以存廢討論定奪，而不應加速，CSD衹應適用於完全沒有爭議的情況。--$\definecolor {my}{rgb}{0.04,0,0.5}\color {my}{\mathsf {htc_{23}}}$（留言） 2022年3月10日 (四) 14:14 (UTC)（2022年3月10日 (四) 14:21 (UTC)追加說明）

我覺得中文維基百科的用戶在OA過後應該不至於如此是非不分，那些“爭議”其實從一開始也就是那些人瞎搞出來的，所以我能肯定OA過後那些“爭議”不存在。基本上會寫出那種用戶頁的人有很大一部分都是別有用心的。Sanmosa   2022年3月10日 (四) 14:33 (UTC)

https://zh.wikipedia.org/wiki/User:%E7%8E%8B%E6%BC%A2%E7%91%8B 这个就是一个经典的U5--Pavlov2（留言） 2022年3月12日 (六) 05:07 (UTC)

這是G3/G12，尤其見「豐功瑋業」一節。--$\definecolor {my}{rgb}{0.04,0,0.5}\color {my}{\mathsf {htc_{23}}}$（留言） 2022年3月12日 (六) 15:03 (UTC)

Wikipedia:頁面存廢討論/記錄/2022/03/22#User:Felixwuuuu这个讨论看得我恼火，英文维基一个U5就飞过去了。----仁爱亲诚的Pavlov2 2022年3月22日 (二) 15:29 (UTC)

• 用來處理不編輯維基條目的人或許有用；也不確定這類情況是否常見。另外，不同意放寛。--Temp3600（留言） 2022年3月17日 (四) 12:16 (UTC)

  不放宽的基础上，也可行。----仁爱亲诚的Pavlov2 2022年3月17日 (四) 15:49 (UTC)

有这种行为的用户多吗？--Tranve (✉) 2022年3月26日 (六) 08:42 (UTC)

多，而且倔。----仁爱亲诚的Pavlov2 2022年3月27日 (日) 04:25 (UTC)

(！)意見：虽然这种想法的初衷是好的，但是一下子照搬英文维基的标准社群会难以快速适应，不过对于U5的标准首先应该有以下几个标准

1.把用户页当作个人博客网站

2.用户页仅有用户及相关人员的联系方式

3.大量的宣传性内容（如果满足G11则以G11开始删除）

4.将用户页用作角色扮演游戏，如果是明显的恶作剧则应该以G3快速删除--Buenos※Días 2022年3月29日 (二) 09:36 (UTC)

不看好管理员执行该标准的一致性和友好性，速删难以追溯，所以还是存废讨论吧。--YFdyh000（留言） 2022年4月4日 (一) 18:46 (UTC)

或者说这个速删只能提到AfD，有争议的话就煮，没争议的话收到(×)快速删除票再速删？ ——魔琴 [ 留言 贡献 ] 2022年4月5日 (二) 01:12 (UTC)

绿链模板的用意，以及是否支持Wikidata？

根据WP:MOSIW，ilh的主要作用字面上看是标注原名。但是这也就是「字面上看」。实际上，现在绿链模板用法有多种解读：

1. 作为外语扩展阅读，或引诱编辑创建条目：无论何种语言事物，尽可能链接英文维基（而非对应语言维基），毕竟懂英文的人最多。如果没有英文版，则链接其他语言。
2. 作为权威认证，或方便维护跨语言链接：链接语言中立的Wikidata。但模板不支持Wikidata，所以链接任意维基百科（一般是英维）。
3. 作为原文标注。标注外文顺便链接对应语言维基，对应语言维基无条目则红链括号。

我个人倾向第三种解读。比如某英国事物在英文维基按无关注度删除了，但存在阿拉伯语版条目；我是红链加注原文也不{{link-ar}}（tsl手机版效果很奇怪）。但有编辑认为能链尽链，会加阿拉伯语维基链接。所以对于这种绿链的使用目的，是否考虑重新讨论？另外各维基条目创建门槛不完全一致，加入绿色链接时，是否要像普通红链一样考量本地条目创建可能性（关注度等）？

此外很多项目有Wikidata数据，却没有任何维基百科条目。而Wikidata可以方便标注原文并添加基础的辨识信息。条文创建时Wikidata还没有开放，那是否考虑让ilh支持链接Wikidata？--洛普利寧 2022年3月10日 (四) 16:37 (UTC)

• 2年前已有相關模板，且也有一定使用量{{WikidataLink}}、{{link-wd}}（此提示是怕有人去重造輪子。。。。。）-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年3月10日 (四) 16:44 (UTC)

  A2569875「年以已」是什麼意思（ —— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年3月20日 (日) 20:28 (UTC)

  1.已修正@Ericliu1912：；2.請User:Lopullinen看一下兩年前就已建好並投入使用且被以高風險模板為由保護的模板{{WikidataLink}}、{{link-wd}}。-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年3月21日 (一) 10:53 (UTC)

  看到了，连接Wikidata技术上没有问题了。但是綠鏈模板的用意还是不明确。--洛普利寧 2022年3月27日 (日) 09:02 (UTC)

  可能是因為沒有DOC所以比較少人知道。抱歉，因為之前較為忙碌所以最近才補上Doc（遲了2年的DOC）。兩年前法國城鎮模板大爆炸拖累維基百科伺服器多個語言版本而被基金會人員來本地刪除法國城鎮模板並要求應使用wikidata 後不久這個模板{{WikidataLink}}就投入使用了。不過後來遇到課業繁忙所以沒空寫Doc ，導致雖然已有大量頁面使用了本模板但知道的人卻不多的情況—- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年3月27日 (日) 09:11 (UTC)

  • (～)補充見Template:WikidataLink#概要-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年3月22日 (二) 17:09 (UTC)
• 如果不提升編輯模板的地位、權益和榮譽，任何嘗試對模板的編輯行為設限，提升至類同條目般的，都是無理的。行之有效，沒有出現事故的東西，不用更改，更沒有討論的必要。--約翰同志－條目裱糊匠（留言） 2022年3月21日 (一) 10:31 (UTC)

我覺得不能把所有模板裏的{{ilh}}都説成是3。就導航性質的模板而言，這跟條目內的{{ilh}}的目的是一樣的，因此屬於1的情形。Sanmosa _{Avec cœur} 2022年3月25日 (五) 00:46 (UTC)

我的意思是，如果把ilh规定为3，那导航模板可能就不应放绿链（=红链+外语加注）。但现在导航模板里面放绿色链接是普遍情况，然而指引又没有明确表示绿色链接的意义不是3。而且加绿色链接也存在定义1或者定义2，以及主题是否能通过中维关注度审查的问题。现在我自己使用时都比较迷茫。--洛普利寧 2022年3月27日 (日) 08:26 (UTC)

同意導航模板不應放綠鏈，現在導航模板的綠鏈常常都綠到超出模板限制然後壞掉了 囧rz……—- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年3月27日 (日) 08:35 (UTC)

主要是因為綠鏈為了配合站內的小工具跳出框框，因此每個綠鏈都有一段span 標籤，導致一多起來塞爆模板了。建議專為導航模板設計一個短一點的模板。或者修改小工具，讓他更智能地直接識別 將 紅鏈+括弧的跨wiki鏈 自動換成綠鏈，而非原始碼保留綠鏈。—- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年3月27日 (日) 08:40 (UTC)

同意，此处另见VPT，我认为技术改进可行。绿链用法我赞成讨论，但建议将技术原因单独考虑。--YFdyh000（留言） 2022年4月3日 (日) 09:29 (UTC)

提议为引用网络资源不填URL链接参数的行为设立警告或过滤器

今天巡查尹锡悦条目时发现有编辑照搬英文版和韩文版引入的网络资源，但是没有附上相应的网址。虽然相关问题已被本人修复，但本人觉得引用网络资源时一定要填网址，方便读者查找相关内容出处。在此提议设置警告或过滤器，提醒编辑者添加网址。--百战天虫（留言） 2022年3月10日 (四) 16:49 (UTC)

編輯差異？--Xiplus#Talk 2022年3月12日 (六) 04:13 (UTC)

是说这篇条目的？--百战天虫（留言） 2022年3月13日 (日) 07:10 (UTC)

對，最好再多提供幾個其他條目的。--Xiplus#Talk 2022年3月15日 (二) 04:57 (UTC)

编辑差异见这里，相关问题纽黑文也有。--百战天虫（留言） 2022年3月16日 (三) 09:32 (UTC)

如果能提醒一下比较好，看了前面的尹锡悦，好像原编辑像是直接从视觉化编辑上复制的，也有可能不太熟悉使用 {{cite xxxx}}模板，也有些是直接用书目数据库提供的引用格式。如果用源代码模式复制参考文献比较好。--Kethyga（留言） 2022年3月24日 (四) 13:38 (UTC)

看過了，不過ref標籤又不是僅能用在參考文獻，也可能正常輸入純文字的情況吧？應該無法用過濾器判斷。--Xiplus#Talk 2022年3月24日 (四) 13:43 (UTC)

如何判斷？是說在應用Cite web模板時沒有添加URL參數之類的操作嗎？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年3月23日 (三) 17:03 (UTC)

T:cite news允許不用填url參數(有些來源只有線下資料)-- Matt Zhuang表示有事按「此」留言 2022年4月3日 (日) 06:13 (UTC)

應該這樣說，Cite web一定要網址，但是Cite news不一定。--Ghren🐦🕒 2022年4月3日 (日) 07:19 (UTC)

修改一級行政區道路特殊收錄限制列表

擴大《一級行政區道路特殊收錄限制列表》的適用範圍

建議將《一級行政區道路特殊收錄限制列表》更名為《道路特殊收錄限制列表》、刪除“一覽表”表格中的欄位，並進行以下修改：

現行條文 本列表旨在列出所有在《道路關注度指引》上有特殊施行限制的國家一級行政區公路。本列表內的特殊施行限制的任何修改或調整應依照《道路關注度指引》的規定和WP:互助客棧/方針頁的討論共識進行。

提議條文 本列表旨在列出所有在《道路關注度指引》上有特殊施行限制的公路。本列表內的特殊施行限制的任何修改或調整應依照《道路關注度指引》的規定和WP:互助客棧/方針頁的討論共識進行。

Wikipedia:关注度 (地理特征)#道路亦將連帶修改：

現行條文 道路 跨國公路網（如歐洲高速公路、亚洲公路网）、國家級公路網（如中华人民共和国国家高速公路网、中华人民共和国国道、美國州際公路系統、美國國道）、一級行政區（如省、州、大區，視乎各地而定）公路網，於一般而言，皆具有關注度；而二級或更低級行政區公路網、地區道路網、單一城鄉道路、街道、公路服務區和交流道等的關注度可能會因所在地不同而亦有所不同，故而在具有以該路段為主題的可靠二手來源的前提下，可假定該路段具有關注度。 参考資料

提議條文 道路 跨國公路網（如歐洲高速公路、亚洲公路网）、國家級公路網（如中华人民共和国国家高速公路网、中华人民共和国国道、美國州際公路系統、美國國道）、一級行政區（如省、州、大區，視乎各地而定）公路網，於一般而言，皆具有關注度；而二級或更低級行政區公路網、地區道路網、單一城鄉道路、街道、公路服務區和交流道等的關注度可能會因所在地不同而亦有所不同，故而在具有以該路段為主題的可靠二手來源的前提下，可假定該路段具有關注度。 参考資料

增列英國公路至《道路特殊收錄限制列表》

建議將英國公路增列至《道路特殊收錄限制列表》如下：

國家	詳細施行限制	討論共識位置
日本	日本既有的一級行政區公路（即：都、道、府或縣道）一律不自動視為一級行政區道路，而以下道路（無論是否既有的一級行政區公路）則取而代之視為日本的“一級行政區公路”： （特例）主要地方道； 日本法律所規定的都市高速道路。	Special:PermaLink/52793108#最新方案 Special:PermaLink/68637876#調整一級行政區道路特殊收錄限制列表對特定道路的限制範圍
英国	英國各公路，除高速公路（Motorway）與A級公路（A road）外，一概不視為國家級或一級行政區級道路。雖然如此，已被編入跨國公路網的公路縱非高速公路或A級公路，仍可獲假定具有關注度。	（討論通過後新增的對應PermaLink連結）

以上。Sanmosa _{Avec cœur} 2022年3月20日 (日) 05:34 (UTC)

建议同时检讨对日本一栏增加修订，主要是其“地域高规格道路”是否可以认定一级行政区道路。--Liuxinyu970226（留言） 2022年3月26日 (六) 02:23 (UTC)

@Liuxinyu970226：這個比較適宜分開討論，因為這次修訂的目的是要處理像英國這樣只有國家級公路而沒有一級行政區級公路的情形。Sanmosa _{Avec cœur} 2022年3月29日 (二) 04:07 (UTC)

@Sanmosa最好还是一口气提出来一体化调整更好，因为如果这次只修订英国相关的，那么对于德法等其他欧洲国家的道路条目贡献者而言将会受到巨大震撼，很容易发生群体指责英国编辑者搞双标。--Liuxinyu970226（留言） 2022年3月29日 (二) 04:29 (UTC)

@Liuxinyu970226：我倒不是這樣認為。如果把所有事情都混同討論的話很容易讓討論失焦，而且《（一級行政區）道路特殊收錄限制列表》是對道路條目收錄施行較嚴格的限制的規定，像法國與德國沒有被（提議）列入列表的情形而言，兩國道路的收錄標準相對於現在的日本與之後的英國而言是相對寬鬆的，我合理地認為相關用戶不會求著我們讓他們寫的條目在之後會更容易被刪除。Sanmosa _{Avec cœur} 2022年3月29日 (二) 12:01 (UTC)

已滿足WP:7DAYS的條件，現公示7日。Sanmosa _{Avec cœur} 2022年4月6日 (三) 07:49 (UTC)

我能否認為這個限制表是優先於Wikipedia:關注度 (地理特徵)#道路。--Ghren🐦🕐 2022年4月7日 (四) 05:32 (UTC)

修改Wikipedia:管理員的離任

如题，原Wikipedia:管理員的離任/提請取消不活動管理員的權限中通知管理员方式含相应模板（{{subst:Inactive admin}}），现该页面已被重定向到Wikipedia:行政員布告板，Wikipedia:管理員的離任#長期沒有活動解任方针中未标注上述模板，每次通知需重新查找。现提议

現行條文 當达到上述条件時，該位管理員應經由以下方式得到通知： 用戶對話頁 其他通訊方式，如電郵、即時訊息、電話等

提議條文 當达到上述条件時，該位管理員應經由以下方式得到通知： 用戶對話頁（可使用模板{{subst:Inactive admin}}） 其他通訊方式，如電郵、即時訊息、電話等

--东风（留言） 2022年3月22日 (二) 07:36 (UTC)

• 支持。--Temp3600（留言） 2022年3月22日 (二) 08:53 (UTC)

  可以加上腳注說明就可以了。--Ghren🐦🕓 2022年3月22日 (二) 09:58 (UTC)

說到口臭系列：「應將通知期設於第五個月，第六個月內仍然沒有操作的話除權。」相對地其他權限沒有通知，半年不活躍就直接除權，管理員特別通知先不談，還要6+1就太過了。--AT 2022年3月22日 (二) 10:56 (UTC)

其他權限除權之前也有通知吧。可能只是不強制？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年3月22日 (二) 11:56 (UTC)

那就差很多了，而且目前確實是滿六個月直接除權，也沒有通知的餘地，這跟管理員離任標準不一致。--AT 2022年3月22日 (二) 15:40 (UTC)

畢竟管理員是重要權限。當然我也認可提前通知、準時除權的方案，但我覺得也可以考慮學習英維，多通知幾次。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年3月23日 (三) 17:05 (UTC)

認可就行。另外，如果要通知幾次也不是不可以，不過相對地應該縮短不活躍的期限，例如三個月的話，就算每過一個月通知一次我認為也是沒有問題的。--AT 2022年3月24日 (四) 04:48 (UTC)

倒是不必縮短期限。前一個月通知一次，前一週再通知一次，這樣就應足矣。英維最近在討論一段長時間內要做一定編輯，或可交換將短時間不活躍期限略微拉長，納入之後改革的考量。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年3月24日 (四) 06:57 (UTC)

我倒是覺得不需要三催四請，從其他權限皆不通知的角度來看，提早一個月通知已經是非常容忍了。至於，交換不活躍期限，來點日誌操作的話可以考慮。--AT 2022年3月24日 (四) 11:11 (UTC)

兩次應該也說不上是「三催四請」w —— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年3月24日 (四) 23:35 (UTC)

哎，雖然之前沒有參與到這裏的討論，但我還是有些話想説的。「三催四請」的形容確實有點誇張，但我同樣覺得事前只通知一次，甚至不通知，都是合理的安排，畢竟我不相信能擔任管理員的用戶是不知道管理員不活躍6個月就會除權的規定的，而且現在還有復任機制。Sanmosa _{Avec cœur} 2022年3月25日 (五) 00:40 (UTC)

現在有復任機制，除權還可以再申請，緊一點應該是相當合理了。--Ghren🐦🕛 2022年3月22日 (二) 16:30 (UTC)

上次RFR的讨论是不是无疾而终了。--东风（留言） 2022年3月23日 (三) 02:48 (UTC)

---

公示7日。--东风（留言） 2022年4月3日 (日) 16:21 (UTC)

不加我上面提到的在第五個月通知嗎？這點在上面討論應該是沒人反對的啊。--AT 2022年4月4日 (一) 14:31 (UTC)

不是很敢确定，毕竟我没有在讨论串列出提议条文。--东风（留言） 2022年4月4日 (一) 14:57 (UTC)

反對AT的提議。缺乏顯著效益，沒壞別修。--章安德魯（留言） 2022年4月4日 (一) 17:30 (UTC)

現在談的基礎是6+1+12，一個管理員要19個月不編輯這個權才能真正摘掉，有什麼問題呢。--Ghren🐦🕐 2022年4月5日 (二) 05:15 (UTC)

不建議節外生枝或包裹提案。先將此案通過為宜。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年4月5日 (二) 08:09 (UTC)

這是一個可以雪球的議案。--Ghren🐦🕓 2022年4月5日 (二) 08:46 (UTC)

當提案有顯著疑慮或反對意見時，就明顯不適合以雪球法則處理了。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年4月5日 (二) 14:56 (UTC)

很抱歉我縮排錯了，我指的是加上{{subst:Inactive admin}}的議案。「可」只是一個建議而沒有約束力，實際上在對話頁留下字句也無不妥，不好意思。--Ghren🐦🕚 2022年4月5日 (二) 15:10 (UTC)

提議引入活動協調員

編輯松是一種鼓勵參加者成為維基人的方式，在歐美等英語系國家盛行。雖然中文區這裡也有看到一些聚會，但除wp:動員令等恆常活動外，看似沒有舉辦過甚麼編輯松。小弟雖然(＆)建議中文區也能多舉辦一些編輯松（線上或線下俱可），但為確保維基人在舉辦這類活動時得到適切的協助（尤以線下編輯松為甚），現提議參考英維引入活動協調員（英語：Event coordinator），大致如下（原文見此）：

• 給予編者權限，以繞過單一IP地址建立新帳戶的數量限制
• 容許編者臨時給予活動參加者「確認用戶」狀態，以繞過正常「須建立帳戶滿7天」的限制；參加者能直接創建新條目、移動草稿頁面至正式頁面等，詳見wp:AL

中文區頁面將容後建立，歡迎討論。--小文人（見山 ‧ 客棧） 2022年3月24日 (四) 07:03 (UTC)

技術上來説，就是大量帳號建立者附加可授權其他用戶「確認用戶」的權力（下稱「授權確認用戶權」）。我留意到此前舉行過的一些offline編輯松或編輯活動的主持人都會申請大量帳號建立者權限，因此我覺得可以討論的一點是能不能讓管理員視乎情況選擇性為適合的用戶授權大量帳號建立者權限時，同時授權「授權確認用戶權」。Sanmosa _{Avec cœur} 2022年3月25日 (五) 00:52 (UTC)

先看看Wikipedia talk:大量帳號建立者#修訂Wikipedia:大量帳號建立者方針，賦予額外權限的討論內容。--Xiplus#Talk 2022年3月25日 (五) 03:48 (UTC)

但小弟硬是認為，既然是為參加者而創建帳戶，為何不獨立拆分一個活動協調員？英維頁面有這樣的一句話：

“ This right was previously granted to individuals involved with off-wiki outreach events to help them create accounts for participants. In May 2018 a new user group, event coordinator, was created, which allows individuals to not be affected by the rate limit on creating accounts without the other abilities granted to account creator. Editors who previously would have been eligible for account creator should instead request the eventcoordinator user group. ”

簡單而言，

• 管理員自動賦予活動協調員權限
• 其他用戶一律須透過指定頁面申請（參考英維做法）
• 活動協調員賦予編者noratelimit權限，但沒有MAC的其他權限

再看看英維對於MAC的定義：

“ The account creator user group (accountcreator user group) grants access to a tool which permits trusted Wikipedia contributors to make a large number of accounts for other people who request them. ”

MAC只在別人請求下才創建大量帳戶，不包括活動，當中亦有一些flag是活動協調員用不著的。--小文人（見山 ‧ 客棧） 2022年3月25日 (五) 08:29 (UTC)

如同您上面引用的enwiki方針，enwiki的WP:ACC程序是由accountcreator處理，而本地ACC程序是由管理員處理，所以本地並無需區分accountcreator和eventcoordinator的需求，向活動協調員授予accountcreator並無問題。--Xiplus#Talk 2022年3月25日 (五) 16:28 (UTC)

簡單來說，從方針跟技術上來說都是，enwiki eventcoordinator = zhwiki accountcreator，而enwiki accountcreator於zhwiki不存在對應權限。--Xiplus#Talk 2022年3月25日 (五) 16:37 (UTC)

除动员令外的编辑松参与度如何？--东风（留言） 2022年3月25日 (五) 15:51 (UTC)

5月會舉辦非洲月，不然以非洲月測試一下？Sanmosa _{Avec cœur} 2022年3月25日 (五) 16:07 (UTC)

此權限應該主要用於線下編輯松？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年3月25日 (五) 17:04 (UTC)

擬議的「活動協調員」權限適用於各種由維基人主持的編輯松（不包括動員令、非洲月、亞洲月等活動），不論是線上抑或線下。

簡單而言，就是那些在英維相關頁面（中文版翻譯中）所提及的那類編輯松。

• 這裡所指的「編輯松」通常會在一個指定的時間、地點進行，並且需報名。
• 為吸引非維基人參與，可透過非維基渠道作宣傳。

同時，(＆)建議參考英維修訂大量帳戶創建者的權限設置，以與活動協調員權限有明顯分別。（為吸引更多人成為維基編者的行列，小弟不反對在中文區多弄一些線上／線下編輯松，像英語區那樣）--小文人（見山 ‧ 客棧） 2022年3月26日 (六) 14:30 (UTC)

本地就沒有大量帳戶建立者的需求啊？--Xiplus#Talk 2022年3月28日 (一) 08:22 (UTC)

現在擬議的做法是在既有MAC的基礎上，參考英維新增2種權限：

1. 繞過「防假」（anti-spoof）機制，容許帳戶創建者建立與現有帳戶名稱相似的帳戶（override-antispoof權限）
2. 繞過「黑名單」檢查，容許帳戶創建者建立被列入meta:Title blacklist的帳戶（tboverride-account權限）

而這兩種權限是活動協調員沒有的。透過重新劃分「大量帳戶創建者」和「活動協調員」的定位，相信本地編者日後就舉行編輯松等線下聚會而需建立帳戶時，會較為好一點。［至於大量帳戶創建者⋯倒不如留給那些不是為活動而短暫豁免限制的編者吧。］--小文人（見山 ‧ 客棧） 2022年4月4日 (一) 13:13 (UTC)

為什麼要容許建立那些帳號名稱？被系統禁止的帳號名稱通常都觸犯用户名方針，實務上都是要求更換用户名。--Xiplus#Talk 2022年4月4日 (一) 13:22 (UTC)

同样反对此两项权限——您们不应该在非特殊情况下创建这些本不应被创建的账户。另外，提案人可以看看另一条路子（不过这个更适合于线下环境）。咱觉得说的很对啊，Experience shows that encouraging participants to create their own accounts often helps them feel more engaged。如果需要部署的话这边也有不少人会帮忙的。 Stang^★ 2022年4月4日 (一) 15:49 (UTC)

假如有很簡潔扼要的方法能解決繁簡轉換問題，是否有必要特地使用複雜的手工轉換標籤？

下方已詳細説明正式提案，故暫時摺疊先前討論，討論結束後存檔前再恢復。--路西法人𖤐 2022年3月24日 (四) 11:17 (UTC)

大家好。這邊在編輯冬季战争時，發現其實我們有很簡單的方法可以解決繁簡轉換： 原文 蘇聯空軍在整場戰爭中都緊握著[[制空權]] 手工轉換法 蘇聯空軍在整場戰爭中都緊握-{zh-hant:著;zh-hans:着}-[[制空權]] 更改文字法 蘇聯空軍在整場戰爭中都緊握着[[制空權]] 手工轉換法大概是現行維基百科所推薦的方法，然而這方法複雜，感覺不但會有許多類似的情況，還不利於機器語義分析。相形之下，更改文字法簡潔多了，也方便人類閱讀。假如就這種不更改就會產生繁簡顯示錯誤的情況，特別通融以簡單扼要的方法解決繁簡轉換問題，不曉得大家認為會有哪些顧慮？--Kanashimi（留言） 2021年10月10日 (日) 07:02 (UTC) 因為有時會被編者認為繁簡改動違反方針。為了避免這個問題，甚至有人把他模板化，例如{{著}}。—- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2021年10月10日 (日) 07:08 (UTC) 假如是這樣，那每個簡繁轉換一對多列表、繁簡轉換一對多列表裡的字都需要獨列模板了。方針不是死的，我們可否修改方針？--Kanashimi（留言） 2021年10月10日 (日) 07:11 (UTC) 我也覺得應該改方針比較恰當，畢竟用模板窮舉所有情況是不切實際的，也浪費效能…………—- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2021年10月10日 (日) 07:14 (UTC) 我也覺得這樣比較方便。說實話，這跟刻意的繁簡破壞應該有差，很好辨別，不然也可以指定編輯摘要。—— Eric Liu 歡慶雙十中國國慶（留言．留名．學生會） 2021年10月10日 (日) 08:09 (UTC) 诶？原来这还是方针不允许的吗？我已经这么干了有段时间了（捂脸）--Milky·Defer 2021年10月10日 (日) 10:14 (UTC) 理论上说“为了更简便的修复/避免错误的繁简转换而更改文字”可以视作繁简转换的正当理由（参WP:CST#勿手动转换条目繁简语句），不过可能会产生争议。Itcfangye（留言） 2021年10月10日 (日) 11:37 (UTC) 我认为这种理由不够尊重“不转换”，所以主张使用手工转换。--7（留言） 2021年10月11日 (一) 10:46 (UTC) 這邊發現手工轉換還可能造成參差不齊。例如上面舉的例子其實不夠完善，較完善的的確該使用{{著}}裡面的-{zh-hans:着;zh-hk:着;zh-tw:著;}-。也就是說不同人可能就有不同的、有缺陷並且必須再修正的手工轉換修正方法。比較保險的應該採用更改文字法，或{{著}}。然而假如正規使用這些文字轉換模板（包括簡繁轉換一對多列表、繁簡轉換一對多列表裡面所有的文字），猜測其中一些恐怕會成為使用率前百名的模板。如此恐怕會有前述效能問題。這或許不是偏好問題，而是技術性問題。--Kanashimi（留言） 2021年10月11日 (一) 11:03 (UTC) 希望有其他管理員看看是否還有其他疑慮，否則就上面討論看來，似乎應該允許此類型修正？--Kanashimi（留言） 2021年10月11日 (一) 20:23 (UTC) 如果非要点名管理员的话，那我说一下。我记得以前是不时有见到或进行此类修改的，也没见有人提出异议，虽然我不知道近些年有没有其他讨论。{{著}}这类模板，我觉得只有必要在上下文比较复杂的时候使用（具体例子没想到），而不是把每一个遇到的着/著字都改成模板。另外说一点，虽然对这个案例并不适用，以前大家会单独使用里面没有东西的-{}-来提示分词，然后让系统自动转换，好像现在这么用的越来越少了，而是更倾向于在-{}-里面具体指定需要的转换效果？（直接写或者用类似{{著}}的模板）我提及这个是从标题的“簡潔扼要的方法/複雜的手工轉換標籤”想到的。Liangent（留言） 2021年10月11日 (一) 21:21 (UTC) 作为（前）繁简转换维护者来说两句：简繁转换并不是一一对应的，大多情况都是一简对多繁，而像“著”和“着”则是一繁对多简。我觉得手工把“著”改为“着”，是符合Wikipedia:繁简处理#勿手动转换条目繁简语句中要求的“正当理由”的（因此，现有规则即允许这样做）。反过来的例子会更多，比如ref group用“註”而不用“注”，表示动词时用“幹”不用“干”等等。这些一多对应的文字，的确可以为常见组合增加转换规则，但我不觉得这个能覆盖完整，而且也不是所有情况都能加规则解决，比如<ref group="註">和<ref group="注">。因此，遇到了这种毛病，手改没问题，提报一下看能不能安全地将其文字组合加进全局转换则是进阶要求。--菲菇＠维基食用菌协会 2021年10月11日 (一) 22:15 (UTC) 同上。Sanmosa WÖRK 2021年10月12日 (二) 14:47 (UTC) 通商。 — 𝕏ℂ𝕠𝕞𝕙𝕘𝕙𝕒𝕝𝕝 talk 2021年10月16日 (六) 22:51 (UTC) 感謝各位的意見。感覺更改文字法應該可以算作共識了。--Kanashimi（留言） 2021年10月13日 (三) 22:43 (UTC) 是否應該考慮明文寫入指引，作為案例？—— Eric Liu 創造は生命（留言．留名．學生會） 2021年10月14日 (四) 13:49 (UTC) 或許在方針裡提一下比較好?--Kanashimi（留言） 2021年10月14日 (四) 20:30 (UTC) 附議。 — 𝕏ℂ𝕠𝕞𝕙𝕘𝕙𝕒𝕝𝕝 talk 2021年10月16日 (六) 22:51 (UTC) 我也認同「现有规则即允许这样做」，支持指引加一句提醒。——遲來的HTinC23（留言） 2021年10月23日 (六) 13:45 (UTC) 反对写入规则，选择“不转换”的用户不希望强制看到外语文字。--7（留言） 2021年10月30日 (六) 15:25 (UTC) 又不是規定一定要這樣做，只是「除罪化」，保證不會因此觸犯方針或指引而已。偏好手工轉換者，大可繼續手工轉換。—— Eric Liu 創造は生命（留言．留名．學生會） 2021年10月30日 (六) 20:25 (UTC) 实际效果一样，“保證不會因此觸犯方針或指引”也就意味着能够以此为理由强行把他人使用的手工转换改掉，而且有方针支持的情况下还能对3RR豁免。--7（留言） 2021年11月1日 (一) 08:58 (UTC) 如上述討論，這或許不只是個偏好問題。您可以針對上面討論的贊同論點一一提出您的解方，如此更能說服人。--Kanashimi（留言） 2021年11月1日 (一) 20:02 (UTC) 他就是不想處理而已，反正他也沒打算認真進行討論。--Sanmosa Ázijská Práca 2021年11月2日 (二) 08:19 (UTC) 我的主张就是当其他用户已经用手工转换时不以这种“理由”去改（等于阻止）。如果双方都坚持原来的用法，那要么先到先得，要么就不管谁坚持改都按3RR处理。如果修改前后在“不转换”下显示的文字一样，我没有意见；如果为了所谓“簡潔扼要”，代价却是强制不转换用户看到不同文字，这我无法接受。--7（留言） 2021年11月2日 (二) 12:43 (UTC) 現在的情況就是一個合法，一個可能違法，需要明文「除罪化」；在已經有既有轉換方式之下，採納「先到先得」原則應該是沒有問題。—— Eric Liu 創造は生命（留言．留名．學生會） 2021年11月10日 (三) 14:38 (UTC) 「選擇『不轉換』的用戶不希望強制看到外語文字」這句我看不懂，不轉換不是本來就一堆所謂「外語」文字嗎？--路西法人⛧ 2021年11月28日 (日) 16:11 (UTC) 同意。--Nrya ✰我聽見有個聲音～ 2021年10月31日 (日) 03:41 (UTC) @Kanashimi：如果要擬文說明以上這種變更的性質，您會怎麼描述？—— Eric Liu 創造は生命（留言．留名．學生會） 2022年1月17日 (一) 02:51 (UTC) 或許可這樣: “ 编辑维基百科条目的时候，如果缺乏正当理由，请不要手动地将条目源码中的繁体语句转为简体，或將简体转为繁体（广义地也包括将一个地区用词转换成另一地区用词，如港澳繁体转换成臺灣正體），以免影响他人的编辑和阅读。手动做这种转换可能将被视为“繁简破坏”，见Wikipedia:破坏#破坏类型中的“繁简破坏”一条。 ” 改成: “ 编辑维基百科条目的时候，如果缺乏正当理由，请不要手动地将条目源码中的繁体语句转为简体，或將简体转为繁体（广义地也包括将一个地区用词转换成另一地区用词，如港澳繁体转换成臺灣正體），以免影响他人的编辑和阅读。手动做这种转换可能将被视为“繁简破坏”，见Wikipedia:破坏#破坏类型中的“繁简破坏”一条。一種例外是當繁簡並非一對一轉換時，為了更簡便的避免錯誤的繁簡轉換，可更改成不容易產生歧義的文字。例如單純使用着一個字，會比-{zh-hans:着; zh-hk:着;zh-tw:著;}-更具可讀性，這種情況下允許手動更改文字。其他例子可參見下表。 ” --Kanashimi（留言） 2022年1月17日 (一) 03:40 (UTC) 原本 改為 能否接受 握著 握着 修正簡體下轉換錯誤 握著 握{{subst:著}} 修正簡體下轉換錯誤 握著 握{{著}} 可以，但不推薦的修復方式。 握著 握-{zh-hans:着; zh-hk:着;zh-tw:著;}- 可以，但不推薦的修復方式。 握著 握-{zh-cn:着;zh-tw:著;}- 造成香港模式下轉換錯誤 握著 握-{zh-hans:着;zh-hant:著;}- 造成香港模式下轉換錯誤 握着 握著 造成簡體下轉換錯誤 握着 握{{着}} 不必要的行為 握着 握-{zh-hans:着; zh-hk:着;zh-tw:著;}- 不必要的行為 握-{zh-hans:着; zh-hk:着;zh-tw:著;}- 握著 造成簡體下轉換錯誤 -{zh-hans:着; zh-hk:着;zh-tw:著;}-、{{著}}或{{着}} 着或{{subst:著}}或{{subst:着}} 簡化原始碼 {{著}}或{{着}} 著 造成簡體下轉換錯誤 著名 着名 錯誤用詞 其他繁簡文字可類推 原系朝廷辦公官署 原係朝廷辦公官署 修正繁體下轉換錯誤「原系」 只语片言 隻语片言 修正繁體下轉換錯誤「只語」 提供涵蓋所有變換的表格，看看是否符合上面的共識。--Xiplus#Talk 2022年1月22日 (六) 03:22 (UTC) 唉，這表格真是太簡單明瞭了。--Kanashimi（留言） 2022年1月22日 (六) 06:22 (UTC) 我觉得{{著}}或{{着}}改成着其实应该允许且鼓励。一来提高源码可读性，二来减少不必要的模版调用。--菲菇＠维基食用菌协会 2022年1月22日 (六) 06:25 (UTC) 感覺只要不會造成轉換錯誤，「着」比「{{著}}或{{着}}」略優。「著」到「{{著}}」一類可以在手頭沒有簡體輸入法時，只打括號做權宜之計。但長久來看，使用視覺化編輯器或語法凸顯工具時，模板太搶眼。--洛普利寧 2022年1月22日 (六) 06:36 (UTC) 以更改繁體以避免加入切斷標記的方法也是可以囉？例如將「一刀不剪发布影片」改成「一刀不剪發布影片」以避免「剪发」被轉換也是可以的？--Ghren🐦🕘 2022年1月22日 (六) 13:30 (UTC) 是這意思。我加上了這個例子。 --Kanashimi（留言） 2022年1月22日 (六) 23:48 (UTC) 这个情况其实稍微有些不一样。“著=>着”和“注=>註”是那种不改字就没法修复的转换问题；而“头发”、“剪发”的转换取决于两字连续出现，这种情况加上-{}-就可以修复而无须改字。 当然，并不是说这种情况就不能改字，我觉得断词和改字都可以允许，不过略倾向于推荐断词。--菲菇＠维基食用菌协会 2022年1月31日 (一) 08:05 (UTC) support. ——魔琴 [ 留言 贡献 ] 2022年1月31日 (一) 08:31 (UTC) 其實「活著」本身在繁簡體下都會正確轉換，不是好例子；應該是因為系統設定。這邊改了一下例子。假如我們把「握著」也加入系統設定，那即便在連詞的情況下，也會如您所提，只要加入「-{}-」就可以解決。當然把太多詞加入系統轉換表恐非良策就是。 --Kanashimi（留言） 2022年1月31日 (一) 08:48 (UTC) 是可以尽可能地做连词，但这样需要有界面管理员长期维护全局转换表。相比于允许任何人发现了就能改，前者就显得不那么wiki了。--菲菇＠维基食用菌协会 2022年1月31日 (一) 15:47 (UTC) 那可以把{{著}}的內容改成「着」，並將使用方式改成{{subst:著}}。--Xiplus#Talk 2022年1月23日 (日) 09:47 (UTC) 赞同。—菲菇＠维基食用菌协会 2022年1月31日 (一) 07:57 (UTC) 已相应修改表格。--菲菇＠维基食用菌协会 2022年2月8日 (二) 19:01 (UTC) 這個表格不錯，不過怎麼轉換為政策條文呢？三言兩語似乎很難說清楚。—— Eric Liu 創造は生命（留言．留名．學生會） 2022年2月8日 (二) 16:39 (UTC) 就直接當範例貼上的話，會有什麼樣的顧慮嗎？--Kanashimi（留言） 2022年2月8日 (二) 20:44 (UTC) 可能還是得用文字說明一下通則如何？—— Eric Liu 創造は生命（留言・留名・學生會） 2022年3月2日 (三) 06:31 (UTC) @Ericliu1912 更新了一下上面的通則說明。煩請看看這樣有沒有比較理想。--Kanashimi（留言） 2022年3月2日 (三) 06:44 (UTC) 感覺可以，是否轉移至方針區公示？—— Eric Liu 創造は生命（留言・留名・學生會） 2022年3月15日 (二) 06:32 (UTC) Yes.--Kanashimi（留言） 2022年3月15日 (二) 08:17 (UTC) 我的感觉是，这相当于是维基百科的“推荐用字”。即，當繁简不是一一映射的關係時，優先选择不容易產生歧义的字形。如 你维字形 简体、港澳字形 台湾字形 助词、附着 着 着 著 明也，标著也 著 著 你维字形 简体字形 繁體字形 疏也 註 注 註 灌也 注 注 你维字形 简体字形 繁體字形 犯也，求也 干 干 干 能事也 幹 幹 燥也 乾 乾 卦名 -{乾}- 乾  ——魔琴 [ 留言 贡献 ] 2022年2月9日 (三) 12:13 (UTC) 你可以這樣說。一簡對多繁的時候，繁是被推薦的；一繁對多簡的時候，簡是被推薦的。--Ghren🐦🕘 2022年2月11日 (五) 13:49 (UTC) 然。--菲菇＠维基食用菌协会 2022年2月13日 (日) 18:32 (UTC)

繁簡處理修訂案

第1版

現行條文 勿手动转换条目繁简语句 对于读者来说...（略）...总之手动转换条目繁简语句是没有必要的。 提議條文 勿手动转换条目繁简语句 对于读者来说...（略）...总之手动转换条目繁简语句是没有必要的。一種例外是當繁簡並非一對一轉換，且該字不與上下文形成詞彙而不適宜使用全文轉換時，為了簡便地修復錯誤的繁簡轉換，可改為不會造成轉換錯誤的用字，例如將握著改為握着，會比握-{zh-hans:着; zh-hk:着;zh-tw:著;}-更具可讀性，具體規則請參見下表。 修改前原始碼 修改後原始碼 是否允許 握著 握着 修正簡體下轉換錯誤，可使用{{subst:著}} 握著 握{{著}} 可以，但不推薦 握著 握-{zh-hans:着; zh-hk:着;zh-tw:著;}- 可以，但不推薦 握著 握-{zh-cn:着;zh-tw:著;}- 造成香港繁體下轉換錯誤 握著 握-{zh-hans:着;zh-hant:著;}- 造成香港繁體下轉換錯誤 握着 握著 造成簡體下轉換錯誤 握着 握{{着}} 不必要的行為 握着 握-{zh-hans:着; zh-hk:着;zh-tw:著;}- 不必要的行為 握-{zh-hans:着; zh-hk:着;zh-tw:著;}- 握著 造成簡體下轉換錯誤 -{zh-hans:着; zh-hk:着;zh-tw:著;}-、{{著}}或{{着}} 着 簡化原始碼，可使用{{subst:著}}或{{subst:着}} {{著}}或{{着}} 著 造成簡體下轉換錯誤 活著 活着 「活著」一詞系統能正確轉換 著名 着名 錯誤用詞 其他繁簡文字可類推 原系朝廷辦公官署 原係朝廷辦公官署 修正繁體下轉換錯誤「原系」 找只鸡把毛除去 找隻鸡把毛除去 修正繁體下轉換錯誤「找只鸡」

修改自User:Kanashimi的提議條文，特別限定 1. 無法使用全文轉換 2. 僅限轉換有錯誤時 才能如此修正。原先表格部分第1、2行合併，增列「活著」一行不應轉換。請再看看目前版本有無問題。--Xiplus#Talk 2022年3月24日 (四) 10:03 (UTC)

不確定「其他繁簡文字可類推」兩行是否需要，另「隻語片言」應較常作「片言隻語」，且這是一個詞彙，應該加入轉換詞庫而非一律使用這種方式修復吧？--Xiplus#Talk 2022年3月24日 (四) 10:30 (UTC)

請當初加入此行的Kanashimi說明一下「此人原係蘇氏人馬」是什麼？或是換成別的常見句子，或移除。--Xiplus#Talk 2022年3月24日 (四) 11:49 (UTC)

改成了寺廟中的例子。 --Kanashimi（留言） 2022年3月24日 (四) 22:26 (UTC)

@Kanashimi：那麼「片言隻語」呢？--Xiplus#Talk 2022年3月25日 (五) 03:51 (UTC)

改成定義謬誤中的用法。 --Kanashimi（留言） 2022年3月25日 (五) 08:35 (UTC)

(＋)支持容許修復一繁多簡或一簡多繁而導致錯誤轉換的修復不視作繁簡破壞。一個影響不大的小問題：我覺得應該將例子和條文分開。--路西法人𖤐 2022年3月24日 (四) 11:21 (UTC)

您的意思是例子不作為指引的一部分嗎？--Xiplus#Talk 2022年3月24日 (四) 11:32 (UTC)

不是，純粹是字句分句分段而已。格式的小問題。--路西法人𖤐 2022年3月24日 (四) 12:05 (UTC)

「可改為不會造成轉換錯誤的用字 / 例如將」這邊應該換段落的意思嗎？--Xiplus#Talk 2022年3月24日 (四) 13:49 (UTC)

是。--路西法人𖤐 2022年3月25日 (五) 04:24 (UTC)

微调了一下表述，如果有疑问请ping我。--Tranve (✉) 2022年3月24日 (四) 11:35 (UTC)

(＋)支持--Yinyue200（留言） 2022年3月26日 (六) 06:36 (UTC)

着著的例子感觉可以换一个，握着直接塞进表里需要加的防过度转换规则几乎没有。比如改成[展體表實兌]現著？屠麟傲血（留言） 2022年3月28日 (一) 06:22 (UTC)

偷偷問一下，「著」只有在讀「ㄓㄨˋ」的時候簡體字才跟繁體字相同，其他時候（讀「ㄓㄜ˙」、「ㄓㄨㄛˊ」、「ㄓㄠˊ」、「ㄓㄠˉ」的時候）簡體字都是「着」？--北有戰鬥陀螺（留言） 2022年4月1日 (五) 14:04 (UTC)

第2版

提議條文 勿手动转换条目繁简语句 对于读者来说...（略）...总之手动转换条目繁简语句是没有必要的。 例外：修復繁簡一對多轉換錯誤 一種例外是當繁簡並非一對一轉換，且該字不與上下文形成詞彙而不適宜使用全文轉換時，為了簡便地修復錯誤的繁簡轉換，可改為不會造成轉換錯誤的用字。修復錯誤轉換時，應優先使用不存在歧義且不會造成錯誤轉換的字形。以下提供一組非一對一繁簡轉換且常見出現轉換錯誤的字形供參考，其他字形亦可類推。 例子：「着」、「著」 字義 建議字形 简体字形 港澳字形 台灣字形 助词、附着 着 着 着 著 明也，标著也 著 著 著 轉換例子 為簡化圖表： -{zh-hans:着;zh-hk:着;zh-tw:著;}-以「Ａ」表示； -{zh-cn:着;zh-tw:著;}-以「Ｂ」表示； -{zh-hans:着;zh-hant:著;}-以「Ｃ」表示。 修改前 → 修改後 ↓ 握著 握着 握{{着}}、握{{著}} 握Ａ 握Ｂ、握Ｃ 握著 需要修復 簡體、港澳顯示錯誤 握着 建議做法 無需修復 簡化代碼 建議做法 握{{着}}、握{{著}} 可以但不推薦 不必要的行為 可不修復 簡化代碼 可以但不推薦 握Ａ 不必要的行為 可不修復 握Ｂ、握Ｃ 港澳顯示錯誤 需要修復 修改前原始碼 修改後原始碼 是否允許 Ａ 着 簡化代碼 {{着}} {{著}} 活著 活着 系統能夠正確轉換「活著」，不必要的手動轉換行為 著名 着名 錯誤用詞

這樣？Xiplus--路西法人⛧𖤐 2022年3月28日 (一) 09:22 (UTC)

(＋)支持 目测没有可见问题。--Yinyue200（留言） 2022年3月30日 (三) 16:51 (UTC)

感覺長到已經是{{輔助說明}}了，舉例挑一個最具代表性的就行了吧？--Xiplus#Talk 2022年3月31日 (四) 01:21 (UTC)

那麼僅保留「着」的例子就行了。--路西法人⛧𖤐 2022年3月31日 (四) 07:05 (UTC)

(＊)提醒：以下列出三组一组非一对一转换--MilkyDefer 2022年3月31日 (四) 13:21 (UTC)

我覺得還是全部用文字敘述比較好，表格放輔助說明。--Xiplus#Talk 2022年3月31日 (四) 15:59 (UTC)

附註說明也是可以。--路西法人⛧𖤐 2022年4月1日 (五) 03:09 (UTC)

是輔助說明頁，不是附註說明。--Xiplus#Talk 2022年4月1日 (五) 04:25 (UTC)

打錯字 囧rz……--路西法人 2022年4月3日 (日) 04:41 (UTC)

提議條文 勿手动转换条目繁简语句 对于读者来说...（略）...总之手动转换条目繁简语句是没有必要的。 一種例外是當繁簡並非一對一轉換，且該字不與上下文形成詞彙而不適宜使用全文轉換時，為了簡便地修復錯誤的繁簡轉換，可改為不會造成轉換錯誤的用字。修復錯誤轉換時，應優先使用不存在歧義且不會造成錯誤轉換的字形。例如在簡體和港澳繁體有「着」、「著」兩種字形，在臺灣正體僅有「著」字形，在原始碼輸入「着」時可由系統自動轉換成臺灣正體「著」，但反之則不會轉換，因此以台灣正體輸入「握著」一詞時無法正確轉換為簡體和港澳繁體，此時容許直接將原始碼修正為「握着」以修正轉換錯誤，如果在內文直接使用轉換規則（例如「握-{zh-hans:着; zh-hk:着;zh-tw:著;}-」）時，也允許將原始碼簡化為「握着」。更詳細的範例可參考Wikipedia:非一對一字詞轉換錯誤修正指南。

LuciferianThomas第3版，表格內容全部放到上述的獨立頁面（為{{輔助說明}}）。--Xiplus#Talk 2022年4月6日 (三) 01:28 (UTC)

支持。--路西法人 2022年4月6日 (三) 04:19 (UTC)

Afd合併遺留重定向問題

可否規定如果afd討論結果為合併的話將遺留重定向設為永久半保護？因為發生很多次新用戶將關注到合併的重定向手動回退到原本版本的事件。畢竟就算這些關注度重定向的後來關注度發生改變，以致其可以重建條目，程序上也應該是先到drv而不是直接重建。這些重定向理論上應無編輯需要-某人✉ 2022年3月24日 (四) 11:52 (UTC)

• CC U:Sidishandsome-某人✉ 2022年3月24日 (四) 11:54 (UTC)

  我覺得可以喔!!--~~Sid~~ 2022年3月24日 (四) 11:56 (UTC)

雖然可預想數量是很多，但實際比例是多少？這個比例有高到需要從「遇到問題再保護」（保護方針要旨）變成「不論情況一律保護」嗎？--Xiplus#Talk 2022年3月24日 (四) 12:04 (UTC)

方針死的人是活的。容我反問就這樣留下來不保護意義何在？反正又沒有合理理由需要編輯。比例我不知道，但至少我自己回退的我記得的至少已經超過十幾次--某人✉ 2022年3月24日 (四) 12:10 (UTC)

需要保護的是遭受破壞的頁面，沒有人編輯就保護根本沒道理。--Xiplus#Talk 2022年3月24日 (四) 13:46 (UTC)

現在不是因為沒有人編輯所以就保護，是因為有高機會受破壞而且沒有必要編輯所以才保護--某人✉ 2022年3月24日 (四) 17:42 (UTC)

「高機會」所以我上面問這個機會究竟是多少，有超過50%嗎？--Xiplus#Talk 2022年3月25日 (五) 01:31 (UTC)

技術上除了半保護與過濾器外，還有沒有其他機制能阻止新用戶進行特定編輯操作的？Sanmosa _{Avec cœur} 2022年3月24日 (四) 12:27 (UTC)

過濾器是最靈活的機制了，不然您希望有怎麼樣的機制？--Xiplus#Talk 2022年3月24日 (四) 13:47 (UTC)

沒有，我就只是想問一下技術上操作的可能性而已。我覺得真要處理這問題的話，用過濾器是不錯的選擇。Sanmosa _{Avec cœur} 2022年3月25日 (五) 00:36 (UTC)

Wikipedia talk:删除方针/存档5#關於過濾器阻止曾被存廢覆核通過還原或存廢討論予以保留的條目再掛上notability或提刪無效 過濾器做不了才提這個方案吧。--Ghren🐦🕛 2022年4月3日 (日) 04:54 (UTC)

反對永久保護，但支持理念；建議加模板標記並使用過濾器阻擋並提示。--路西法人𖤐 2022年3月24日 (四) 12:04 (UTC)

反對永久保護，但可適當標記追蹤。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年3月24日 (四) 14:10 (UTC)

現有{{R FAILS N}}和Special:滥用过滤器/185但是印象中在關注度不足而合併時並非每次皆有使用該模板。--$\definecolor {my}{rgb}{0.04,0,0.5}\color {my}{\mathsf {htc_{23}}}$（留言） 2022年3月24日 (四) 16:26 (UTC)

这滥用过滤器185真的没问题吗……从原理上--MilkyDefer 2022年3月24日 (四) 17:36 (UTC)

时刻跟踪Special:相关更改/Category:关注度重定向会不会更好些？--MilkyDefer 2022年3月24日 (四) 17:41 (UTC)

無法，準確來說應該要跟蹤該分類的「成員近期變更」而非「相關變更」，一旦頁面從分類移除，就不會出現在相關變更中，但這個修改會記錄在近期變更上。--Xiplus#Talk 2022年3月28日 (一) 07:45 (UTC)

仅含虚构内容的独立角色条目的存废问题

近我在清理角色信息框的过程中，发现中维有大量独立的ACGN角色条目只有剧情、角色特征、使用的道具等虚构视角的内容，且几乎完全没有现实世界视角的内容。于是我将这类条目全部提报存废讨论（见3月24日和3月25日的存废讨论），提出的理由是其违反WP:NOTPLOT方针（“维基百科的条目并不是：仅关于虚构作品情节的介绍。维基百科采用百科全书的方式描述具有关注度的虚构作品，介绍它们的受欢迎程度和它们的意义。一般情况下，简洁的情节概述是可以包含在这些介绍中的。”）。

而有讨论参与者表示，条目可以等待改善，且多数条目的其它语言版本都有现实影响的内容，可以据其扩充。但据我观察，大多数此类条目已经建立了几年甚至十几年的时间，自其创建以来就只有剧情和设定，也从来没有编者往其中加入现实影响相关的内容。因此我对是否有编者愿意改善这类条目表示怀疑。

由于影响范围较广，且可能引起大量争议，因此在此发起议题，望请求社群的意见。即：只有剧情、设定等虚构视角的独立角色条目是否应该删除或合并至角色列表条目？如果等待改善，那是否有必要设立等待的最后期限？存在此类问题，且没有编者愿意改善的条目该如何处理？--BlackShadowG（留言） 2022年3月25日 (五) 07:10 (UTC)

為什麼要有等待最後期限？而且不是每位讀者、編者都知道具體的內容方針，遇到此類有問題的條目加上模板{{real world}}就好，如果真的想刪，每天提刪一兩個，至少要讓人有時間來改善。一天提刪幾十個，誰有那麼多時間幫忙改善？维基百科:只有情节介绍的虚构作品条目的意思很明確，如果ACGN角色条目沒有潛力可以改善，再合併或刪除，昨天你提刪的幾個條目英維就是這麼做的。--中文維基百科20021024（留言） 2022年3月25日 (五) 07:29 (UTC)

我不认为单纯得挂上real world模板能解决问题，好几个条目real world挂了几年了也没得到任何改善。我提删的那些几十个条目基本都建立了好几年的时间，也没得到改善。有潜力改善，但没有人愿意改善的条目，除了合并和删除，还能有什么解决方法。--BlackShadowG（留言） 2022年3月25日 (五) 07:40 (UTC)

所以就像我前面所說的，慢慢來，不要急，要提刪就爭取控制在一天1-2個，一天提刪幾十條這種做法肯定不可取。--中文維基百科20021024（留言） 2022年3月25日 (五) 07:49 (UTC)

挂着标识好几年的条目，按着分类找都能找到一大堆，这本来是老大难没银弹的问题，我不认为这样牟然删除是银弹方案，尤其是部分条目可以确认是有办法去改善，而提案者只图省事的话，我乍看都是在GAME。——Sakamotosan路过围观 | 避免做作，免敬 2022年3月25日 (五) 07:59 (UTC)

之前有一个类似走fanpov的都被“祭旗”过一次（暂时看来，那个人暂时冷静下来了），我不介意再整理一下再“祭旗”一次。——Sakamotosan路过围观 | 避免做作，免敬 2022年3月25日 (五) 08:04 (UTC)

“Careful, Chief. You dig up the past, all you get is dirty. ”，每次都换着理由来提删，还不如感兴趣的参与改善，要不然的话，编辑是志愿性质，搞不了就别搞。——Sakamotosan路过围观 | 避免做作，免敬 2022年3月25日 (五) 07:56 (UTC)

说是有改善空间，几年了也没人改善；要提删又被说是GAME。我也不知道该怎么样才好了，看来这些方针的执行力真的是可有可无。--BlackShadowG（留言） 2022年3月25日 (五) 08:23 (UTC)

要想執行方針前提是認同這個理念，不好的方針寧願修掉。而且中維好多方針在2000年代初直接翻譯英維來的，估計沒怎麼公示就直接通過，而英維那邊都改了，中維都不變。--中文維基百科20021024（留言） 2022年3月25日 (五) 08:39 (UTC)

提刪的按鈕實在出現得太簡單了，刪當然是很簡單，假如一個角色有關注度的話，不太可能沒有現實的影響和評論，我覺得不應該以提刪作為迫其他編者改善。--Ghren🐦🕓 2022年3月25日 (五) 08:20 (UTC)

(！)意見具體問題具體分析，我看了一下基本上比較邊緣的（差不多就是那些在英文維基百科沒條目的）條目情況明顯比在英文維基百科有條目的糟糕。要保留其實非常簡單，就是把一些冗餘的夾雜原創研究的東西刪一下然後把英文維基的評價翻譯過來。--🎋🎍 2022年3月25日 (五) 09:47 (UTC)

我的意思是情況實在是比較糟糕的條目沒必要保留，那些明顯能按英文維基百科改善的也沒必要這麽急著拉到AFD。--🎋🎍 2022年3月25日 (五) 09:51 (UTC)

一兩個是簡單，幾十條就不簡單了。在英文維基百科沒條目的我也不反對刪除。--中文維基百科20021024（留言） 2022年3月25日 (五) 10:00 (UTC)

經查凌曉雨、蕾貝卡·錢伯斯、烏蘇拉、源靜香、路克·天行者、尤達、邪惡博士、菲比·布菲、亞森·羅蘋、李小狼、木之本櫻、翠迪鳥、白卜庭、魁剛·金、蘇珊·梅耶在英文維基有質量較好的條目或在法語等版本有高品質條目，這幾個的AFD可以先停了，其他的要麽在英文維基被合併要麽在英文維基的版本也是趨向虛擬世界視角，建議討論完後繼續AFD流程。--🎋🎍 2022年3月25日 (五) 15:06 (UTC)

BlackShadowG已經暫停提刪，如果剩下的你覺得有問題的話可以明天重新提刪。--中文維基百科20021024（留言） 2022年3月25日 (五) 15:11 (UTC)

補充：黛西公主、联合军、札克斯·菲爾、固蛇、彩女、尼克·貝里克、金家藩、埃奇歐·奧狄托雷·迪·佛羅倫斯。--🎋🎍 2022年3月25日 (五) 16:02 (UTC)

還有一個伏地魔。--🎋🎍 2022年3月26日 (六) 08:50 (UTC)

你维挂板条目比比皆是，好多都挂了好几年，凭什么就real world要迫使我们改善？Fire Ice 2022年3月25日 (五) 08:38 (UTC)

我的意思是，你维烂条目多人所共知，有一份热发一份光很好，不要以删除为压力迫使我们去改善。（个别烂的不得了的条目除外）--Fire Ice 2022年3月25日 (五) 08:41 (UTC)

BlackShadowG大部分提刪的條目，無非缺少的是reception一節而已。即使是只有虛擬情節也不並非不能接受，除非虛擬情節是編者在胡寫，與原作劇情設定有極大出入。--中文維基百科20021024（留言） 2022年3月25日 (五) 08:46 (UTC)

若是只有虚拟情节的条目也可以存在，那我可以理解为各位并不认同WP:NOTPLOT的理念，那这边我们可以讨论是否有必要修改这条方针，而不是等执行的时候再来一堆反对意见。--BlackShadowG（留言） 2022年3月25日 (五) 08:51 (UTC)

滑坡是吧？我只是提出可以改善而避免提删，或者不应该利用程序来压迫其他志愿者去做“改善”，你认为这些编辑就是不尊重规则？有些太烂的，我认为可以考虑往主体条目或者对应的元素类表合并处理，但很明显这次部分条目有部分有外语条目，而且部分的质量足以用于改善条目，为了行使自己的主张，来一次过提删，我不觉得是好的行为。——Sakamotosan路过围观 | 避免做作，免敬 2022年3月25日 (五) 08:57 (UTC)

阁下对我的指控我无法接受，我把一堆不合规则的条目提删，为何就是对其他志愿者的“压迫”？对应的外语条目质量高，中维的条目不合规则，就只能改善，不能提删吗？确实，我提删条目时没有试图自己去改善，但改善只不过是避免提删的途径，我从不觉得提删不合规条目这一程序本来有什么问题。如果真要说我是在“行使自己的主张”，那我的主张就是，中维的条目，理应照中维的方针管理，外语条目的质量再高，中文条目不合规则的就应该删除或合并。--BlackShadowG（留言） 2022年3月25日 (五) 10:11 (UTC)

我覺得問題還是出在短時、大量提刪明顯可以改善的條目，我不認為這一做法是合適的。--中文維基百科20021024（留言） 2022年3月25日 (五) 10:31 (UTC)

除了我上面列舉的那些外，其他的改善空間都非常狹窄甚至沒有，除了少數幾個我私底下認為有點激進外，不認為提刪不合適。--🎋🎍 2022年3月26日 (六) 08:49 (UTC)

如果英維那邊都重定向的話重新再提刪好了。也可以用關注度解決，先掛個模板再說。--中文維基百科20021024（留言） 2022年3月26日 (六) 08:54 (UTC)

我已经把没有英维条目的纯剧情中文条目重新提删。--BlackShadowG（留言） 2022年3月27日 (日) 04:31 (UTC)

Wikipedia:Articles for deletion/Lynette Scavo上來就是一個keep，（Keep and trim appropriately. The first four Google Scholar links all appear to be substantively about this character. One is paywalled, one is dead, but each appears from title/abstract to be on topic. ）--中文維基百科20021024（留言） 2022年3月27日 (日) 06:19 (UTC)

那正好暴露了這一方針本來就可能有問題，不然也不會有那麼多反對意見。--中文維基百科20021024（留言） 2022年3月25日 (五) 08:58 (UTC)

英維已經沒有「仅含虚构内容」 這一點了，我不知道虛擬情節是不是當初從英維那邊搬來的，要翻一下歷史討論了。--中文維基百科20021024（留言） 2022年3月25日 (五) 09:00 (UTC)

指正：現在還有英維en:WP:NOTPLOT，「Summary-only descriptions of works.」。--Nostalgiacn（留言） 2022年3月25日 (五) 12:36 (UTC)

方针问题不大，如果秉承作为网络版的传统百科全书的话，让一个独立条目的主体被现实世界关注是NOTPLOT的“guideline”。但显然地通过这样来逼宫就有点“人干事”了。——Sakamotosan路过围观 | 避免做作，免敬 2022年3月25日 (五) 14:31 (UTC)

@中文維基百科20021024、Nostalgiacn、Fire-and-Ice：，既然某位编辑如此“捡鸡毛当令箭”的话，只能尽量“花时间”处理部分能改善的已提报条目（原则上，能找到现实的关注，包括评价、有（可能）被现实关注的排名，基本上问题不大。如果没有的话，就真的是太糟糕了，只能往主题条目或者对应的元素列表合并），毕竟人家花了这么多时间逐个打开页面，点开TW，逐个条目复制理由来提交吧，肯定是经过深思熟虑思考过，觉得自己动手改善是劳心劳力，还不如“破坏”掉干手净脚，对不？我是个社畜和半个现充，只能摸下鱼陪下freshfish玩法棍游戏了。——Sakamotosan路过围观 | 避免做作，免敬 2022年3月25日 (五) 14:23 (UTC)

• 有關注度就證明了條目可以寫出現實視角內容，只是誰有空去寫而已。--Temp3600（留言） 2022年3月25日 (五) 16:36 (UTC)

  又是维基百科:维基百科并不需要你出來的時候。虛構角色在動漫及遊戲專題有「维基专题:ACG/維基ACG專題創作獎」進行一種榮譽性的鼓勵。全面的有维基百科:条目质量提升计划。维基百科:動員令過去有過幾屆也會給完善內容給積分。

  如果真的有心，可以作為活動主持人發起小型的動員令，編輯松活動。--Nostalgiacn（留言） 2022年3月26日 (六) 05:52 (UTC)

  短時間大量提刪「能看但有潛力、目前暫時不合規」 的條目行為很難達成共識。--中文維基百科20021024（留言） 2022年3月26日 (六) 05:58 (UTC)

  本質和方針WP:STUBIFY「如果一个页面能透过编辑和讨论得到改善，应当展开讨论，勇于编辑进而改善页面，而不需要将它删除。」相抵。對條目質量不滿，個人認為改為動員令一類的活動更為合適。

  而且事實上，準備中的Wikipedia:互助客栈/其他#第二十次動員令，他們正苦惱該次活動的範圍。--Nostalgiacn（留言） 2022年3月26日 (六) 06:06 (UTC)

面对一篇有关注度的广告条目，我们要么删除，要么真的尽快改善。不会有人说「这篇广告条目的主题有关注度。虽然条目现在写得不好，但未来大有可为。所以我们应该应该保留这篇条目，挂上{{advert}}等其他人改善」。关注度是说明条目有写好的潜力，但我们的最终目标是将这个潜力变成现实。广告条目内容足够差，和我们的目标相左，那结果就是被处理掉，不用在这里谈什么潜力了。

对于虚构条目，我认为这也是内容品质差的问题，应该尽快处理而不是分析关注度。WP:PLOT指出要“采用百科全书的方式描述具有关注度的虚构作品”。只有虚构内容的条目无法反映角色的现实影响，是不符合百科全书的方式描述的，换句话说就是写得不好。这和广告条目一样，都是需要立即改善的。把Reception写出来，条目品质达标了，关注度也不证自明。

和广告条目相比，纯剧情条目的负面影响不很明显，但长远来看确实值得关注。上面说纯剧情条目几年没人改。然而没人改都要谢天谢地了，很多条目改完之后虚构内容越来越多、格式越来越差，现实世界内容依然没有影子，最后都没法清理。回退到最初版本，那最初版本也是WP:PLOT，也不符合标准。而且新编辑创建条目也是模仿现有内容。如果既有内容的编写方向不对，那就是把人带到沟里了。如果条目只有故事介绍，但写得不错（GA级），我认为现在也可以不处理。毕竟中文社群对纯剧情条目有一定容忍度，而且我们还有很多其他要做的事情，而且新编辑模仿优质的故事介绍也是一种学习。我担心的是，这种条目按经验往往会被粉丝改得越来越差，一方面成为负面典型，另一方面清理要浪费不少人力。

我认为这种虚构条目重定向到主条目，或者移动到草稿空间比较好。原有内容都有底子，谁想改可以接着改。直接删除我认为有点可惜，而且做法太过激进，容易引发编辑反感。--洛普利寧 2022年3月27日 (日) 06:24 (UTC)

主要问题是做法激进，而且在知道有办法改进的情况下，还是进行提删，而且还假惺惺地说可惜。我怎样看都觉得这种做法“可笑”。纯广告的条目几乎没有改善之处，甚至必要时可以提速删，不会说任何无来源，原创研究，不符合NOT的有速删的必要？而且有用户提及有BlackShadowG引入一堆没翻译内容，最后被发现后由其他人重写改善，反而倒是有时间逐个打开页面，点击TW提删，看来工具的确方便，按几下鼠标比在键盘码一大坨字还要省事。——Sakamotosan路过围观 | 避免做作，免敬 2022年3月28日 (一) 01:23 (UTC)

做法激进我承认，但我从不认为这次提删有问题。要是一篇广告宣传条目，就算英文版写得再好（就算是GA），要么就直接删除，要么就尽快改善，不会有人说“这篇条目有改善空间，所有不能删”，而且估计一天提多少篇就删多少篇；现在换成了几篇同样违反方针，根据WP:DP#14应该删除的条目就不一样了，会被人说“明显有改善空间”所有不能删，问改善给不给最后期限会被人说“迫使”他人改善，一次提太多还会被人送上AN。同样的方针，放在不同条目上标准就不一样了对吧？

把我以前写的条目拿来指责我是更想不到的，我3月初创建的俄乌战争期间对乌克兰的援助列表本来想一个晚上全部翻译完的，但由于现实生活中的一些缘故没能翻完，第二天向继续翻译时发现已经被AINH移动到草稿了。那时英文维基百科的条目本来也很不稳定，当时我就想既然已经被移动到草稿了，不如等英文条目稳定了再来翻译，就去翻译另一篇GA去了。这还能被人说是“该做的不做”更是令人想不到的。--BlackShadowG（留言） 2022年3月28日 (一) 02:50 (UTC)

“尽快改善”，除了少数有明确迫切性限期的，例如速删、提删、关注度提报，大部分能挂修饰标识的，都没给设定明确的修葺期限，你倒是一口一个“可惜”然后转手提删，让其他编辑帮你“打工”。所以本质上你没认为自己存在问题：编辑是志愿性质，删除方针是提议能改善的尽量改善先。系统是完美的，如果存在缺陷，人是缺陷。——Sakamotosan路过围观 | 避免做作，免敬 2022年3月28日 (一) 03:21 (UTC)

就算是看上去是广告，如果有改善的空间（例如部分描述具有百科性），都会尽量修葺，除非全是黄婆麻瓜的描述，那就直接提SD，也省得讨论，而且至少少见这样大量的广告类似的条目出现。——Sakamotosan路过围观 | 避免做作，免敬 2022年3月28日 (一) 03:31 (UTC)

这种明知道有改善空间，甚至知道存在相应的编辑社群能合作处理，然后就转手提删来倒逼其他人“帮手协助”，我不认为这是好情况，可能会变成恶性现象，毕竟现状是问题条目多，处理人员少，某些编辑只需动几下鼠标，就把一堆人拖着键盘来四处奔波，显得自己业务了得。这不应该是理想的编辑合作方式。——Sakamotosan路过围观 | 避免做作，免敬 2022年3月28日 (一) 03:36 (UTC)

事件本來有更好的處理方式，能從其他語種維基得知關注度的，加上一句和現實相關的內容，讓條目有現實觀點，加一點內容不費幾分鐘。角色對應作品條目存在，或者角色列表存在，存廢提出重定向和合併也是一種恰當的處理。個人認為部分條目的WP:NOTPLOT指控也不合理，如趙靈兒（提刪時，目前版本完善了一些）的和林月如，有提到「影視作品」，角色有現實人物飾演，已經是與現實相關內容，而且也有相關演出的新聞報道，說明這個角色具有關注度（有人關注誰去飾演這個角色）。

直接提刪一大片就像明明通風只需要開窗就能解決的問題，偏偏要提出把房子拆了一樣，關注這些房子的人當然不滿。--Nostalgiacn（留言） 2022年3月28日 (一) 02:42 (UTC)

一刀切的提刪「僅含虛構作品的劇情內容」條目，就像以「多年來一直無列出來源」為理由提刪德奧合併和慕尼黑協定條目。--Mewaqua（留言） 2022年3月28日 (一) 18:39 (UTC)

提删的应该是「只会有虛構作品的劇情內容」條目，而不是「僅含虛構作品的劇情內容」條目--百無一用是書生 (☎) 2022年3月29日 (二) 02:47 (UTC)

• 之前就曾提議過「撰寫虛構/非現實」內容比例過高（或幾乎仅含虚构内容的独立角色条目）的條目應建立一個比照關注度30天候AFD的流程，但最終因User:Cwek提出異議而未通過，改為僅在{{Fansite}}標誌「非強制性」地若要提刪「至少確定模板已掛30天」模式。社群也可以在研擬是否要當條目「撰寫虛構/非現實」內容比例過高（或幾乎仅含虚构内容的独立角色条目）的條目應建立一個比照關注度30天候AFD的流程，或者30天太短也可以60天，弄成像關注度流程那樣，過期自動提刪，這樣「刪除性模板掛30(或60)天」也是可以「更立即地」提醒編者應著手改善吧（(？)疑問@Cwek：上次未通過的理由好像只是您不希望「限期改善否則提刪」的模式，但這次社群好像傾向這模式？）-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年3月29日 (二) 03:27 (UTC)

  我怎麼看到好像只有BlackShadowG傾向於「限期改善」？Lopullinen倒是提到了可以重定向或者草稿，他也承認「直接删除我认为有点可惜，而且做法太过激进」。--中文維基百科20021024（留言） 2022年3月29日 (二) 03:33 (UTC)

  • 因為已經提出，所以如過這次當條目「撰寫虛構/非現實」內容比例過高（或幾乎仅含虚构内容的独立角色条目）的條目應建立一個比照關注度30天候AFD的流程也沒通過，大概要列入WP:常年提案了吧 囧rz……。-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年3月29日 (二) 03:38 (UTC)

“ ” ——Wikipedia talk:資料頁

• 建議重啟是否啟用本模板的討論。-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年3月29日 (二) 03:33 (UTC)

如果要啟用的話是不是有專門的Category，在裡面應該要看到所有被掛上模板的條目，就像小小作品（[[Category:小小作品]]）那樣。--中文維基百科20021024（留言） 2022年3月29日 (二) 03:39 (UTC)

感觉提及的讨论有点混为一谈吧？如果只就“盾之勇者成名錄角色列表 ”案例，本来Wikipedia:关注度 (虚构)、Wikipedia:資料頁有相应的如何拆分建立（其中关注度是建议先开讨论，但实际上没人看这一条说明），所以对于这个情况是我建议合并回主条目。对于普遍性问题，有没有必要设修订限期，类似的原没有来源、原创内容等修饰标识都属于同样重要的问题，为什么要为这个主题的修订设立限期？所以我质疑这个规则的必要性。而且复盘了以前的讨论，主要针对Wikipedia:資料頁（包括虚构元素的列表、化学物的性质表等）的定义和处理有了决议。对于这个问题好像并没有提及？——Sakamotosan路过围观 | 避免做作，免敬 2022年3月29日 (二) 04:54 (UTC)

• 是。所以我下面有補充「是否啟用限期模板」。至少規定限期模板就能防止條目被「秒刪」，類似關注度提早刪會被暫時保留關閉討論的方式。我上次的觀點也是這樣。此規範可以防止編者在還不知道的情況下，條目被「秒提刪」。—- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年3月29日 (二) 05:31 (UTC)

書生在上面提出一個很重要的指正「『只会有虛構作品的劇情內容』條目，而不是『僅含虛構作品的劇情內容』條目」。「只會有」代表沒有改善的空間，而「僅含」不能排除有可以擴充的空間。

BlackShadowG上面也列出WP:PLOTONLY（「仅关于虚构作品情节的介绍」的連結），雖然不是方針，只是論述，但是目前對相關內容的做法差不多都是按照這個原則。內文建議的做法「按照我们的删除守则，假如条目永远只能小作品，就应易名、合并，或同相关话题重构冲出小作品。三者皆不可行则应删除。」Lopullinen的相關觀點也是來自此，優先的處理方法是合併一類的操作，只有「无望扩充」才到刪除的地步。林月如之類的虛擬角色一再被提刪，保留下來的理由都是有擴充的空間，符合WP:PLOTONLY的「起码要能找到几条来源，证明这一话题受关注。换言之，找不出来源的条目会遭删除」判別方法。

個人認為不如直接讓WP:PLOTONLY變成指引好了，反正判別存留都是這個原則。--Nostalgiacn（留言） 2022年3月29日 (二) 04:56 (UTC)

可以。--中文維基百科20021024（留言） 2022年3月29日 (二) 05:00 (UTC)

感觉这是在射箭画靶一样，没有点明出这次大量提删存在的根本问题：是没考虑到这些“仅虚构内容”并不是“只会有虚构内容”，因为相当部分可以被改善的（轻则只需要补充现实影响的描述，重则也可以合并至相应的主体条目或列表条目），但显然地这些提删人似乎知道可以改善却还是大量提请删除（而且就是意见“删除”，而不是类似“合并”之类），我认为这就是游戏规则的问题（删除方针也说过删除前应该考虑改善的处理）。所以暂时不需要扩大讨论范围，现有的机制（例如挂修葺标识提醒，参照NOT，还有资料页、关注度等处理方法去改善）基本上足以应付。——Sakamotosan路过围观 | 避免做作，免敬 2022年3月29日 (二) 06:21 (UTC)

修改了上文一些描述。認同現有機制可以處理相關問題。另外「限期改善否則提刪」的建議，其實和{{Notability}}沒有什麼區別，最後也是對簿公堂，在存廢頁面給來源證明話題受關注。--Nostalgiacn（留言） 2022年3月29日 (二) 07:50 (UTC)

如果设立期限，可能也会变成一个“缺陷”：以前SM就是用关注度的方法来这样搞过。所以我认为这与其他类似没来源、原创研究等的问题，既然那些也没有设立期限，这个我也不认为有着同样的迫切性。——Sakamotosan路过围观 | 避免做作，免敬 2022年3月29日 (二) 07:56 (UTC)

所以说规则是“完美”的，如果有缺陷，那就是人。提报的原则不算是太大的问题，问题是在知道可以改善的情况下，通过大量提报来“强迫”处理，而不是通过提出（既然也知道有相应的社群）让其他用户志愿协助，或者可以选择放着不管。——Sakamotosan路过围观 | 避免做作，免敬 2022年3月29日 (二) 07:59 (UTC)

如是以箝制為導向下、不認為規則「完美」或應該「完美」之於提報體系範疇，而同時是認為社羣和社區相應必要、根據時下之批量對維基內容具不可逆/不可補救之操作可能濫用，需要一定監管和其他社羣討論等之協作，以遏制相應非建設傾向有惡化之--約克客（留言） 2022年4月3日 (日) 07:06 (UTC)

PS.请白话化。简单而言，在能改善的情况下，滥用条目（整篇的）删除程序，我不认为是合适的做法。这些情景式写法或者基于编者对作品的理解而产生的虚构元素个体条目（当然一部分是相应的规范比这些条目的存在还要晚出现或者没人留意到）是老焦油坑，清坑是好事，但没能力处理的话，没必要强硬自己去处理，或者使用不友好的编辑手段。——Sakamotosan路过围观 | 避免做作，免敬 2022年4月5日 (二) 08:02 (UTC)

反過來說，是否可以籍此次論題，探尋適當規勸濫用程序製造非建設積案之手段？畢竟有繼續違背維基協助合作之坑洞，適宜檢討回整個規制修訂之理路實施，可基於現有案例定向拆除有關規限，例如先特定禁制對一切虛構類型條目之批量霹靂提刪活動--約克客（留言） 2022年4月5日 (二) 14:55 (UTC)

我是认为盲目删除和一味保留都值得讨论。一些条目不宜删除，是因为它的内容对未来编写有用，并不是说这它本身有多好。我认为虚构条目可以分为两类，编辑能执行三种操作：

Y 内容可作为独立条目展示

N 内容不宜作为独立条目展示

(○)保留
保留独立条目资格

(►)重定向
取消独立条目资格，但存留历史记录

(×)删除
删除历史记录

纯剧情条目中有些内容是未来能用到的，这删除历史记录的确不太合适。比如彩女的人物介绍品质很好，这次删除下次就要重写，而且重写都不见得能写到这般好。但是这篇条目本身是有方向性问题的：WP:PLOT明确指出，故事介绍相当于调料，现实影响才是主菜。如果一味保留，无疑会给其他编辑（尤其是新手）带来理念上的错误认知，让他们误以为这不是什么大的问题。这种条目我认为重定向是比较好的处理方式，能明确告知中文维基的编写理念，也不会让有参考价值的内容消失。（当然如果条目介绍的全是阿猫阿狗之类的小NPC，对未来编写合格条目没帮助，那删了也就删了。）

另外关于楼下说的“愛好者內容總比沒有內容好”，这点我认为正好是相反的。过度的爱好者内容一定要及时从条目中移除，千万不要给新编辑模仿的机会！如果放任不管，最终结果就是出现这种中维第一长游戏条目，编辑想动手清理都无能为力。这种条目可能有些好的内容，但保留的微弱好处抵不上错误示范的坏处。有能力清理过度内容的的是粉丝，但堆积这些不当内容的也正是粉丝。模板主要是给编辑看的，但虚构内容编辑不了解作品事很难清理的。有能力清理的是粉丝，而加入不当内容的也是粉丝；重定向倒逼粉丝重写，中间吸引认同维基编写方案的粉丝、劝退不认同维基书写风格的粉丝，我认为反而是一种良方。--洛普利寧 2022年4月5日 (二) 16:32 (UTC)

新人知道虛擬作品的寫作規範嗎？不如讓他們直接了解相關指引，這樣更好。重定向也不見得能解決這個問題，因為他們不一定知道正確寫法是怎樣的。--中文維基百科20021024（留言） 2022年4月5日 (二) 17:04 (UTC)

新人不知道虚拟作品的写作规范，所以他们会模仿现有条目。将有问题的条目重定向，让他们看不到错误范本，或者看到错误范本的结局是重定向，这样的确能解决很多问题。而且有些新人你给他说了他听不懂（或者不理你），继续自己干自己的。这种时候要想说服他们，基本只能亲自动手重写。他们写的内容往往只能让粉丝看懂，但我不可能熟悉每个游戏，贸然修改可能会有细节错误，然后会被他喷一顿。这样想劝他们了解指引就更难了。（没错，我是被呛过好几次）而且你举写作规范，他就能举出劣质内容被保留，这让人怎么说？另外我这几年的新游戏角色列表都有在看，只见劣质列表数量和比例都是双双向上。可见保留没有让虚构内容越来越好。--洛普利寧 2022年4月5日 (二) 17:19 (UTC)

我只支持沒有潛力擴充的小人物重定向，至於比較知名的，從英文那邊把相關內容拿過來就行。遊戲角色列表和小人物本身靠通用關注度就能刪除或重定向。不過對於讓人如何用現實角度去寫虛擬人物也確實是一個不能忽視的問題。--中文維基百科20021024（留言） 2022年4月5日 (二) 17:41 (UTC)

WP:PLOT云，「维基百科采用百科全书的方式描述具有关注度的虚构作品，介绍它们的受欢迎程度和它们的意义」。条目不管有没有关注度，不写现实世界内容就是“没有介绍它们的受欢迎程度和它们的意义”。“仅关于虚构作品情节的介绍”和“仅关于作品的现实世界介绍”都是内容缺失，但WP:NOT特别列出前者。这说明虚构条目没有现实内容是个严重的问题。

正如我开始所说，现在的问题就是条目实际品质问题，而不是发展可能性问题。中维虚构角色条目很多时候都轮不到谈关注度：把现实内容写出来条目，自然能证明有关注度；不写出现实内容，无论角色多知名条目都有严重问题；至于没有关注度，你也写不出现实内容。您轻描淡写的“從英文那邊把相關內容拿過來就行”正是现在的实际问题。如果在AfD投个保留就能自动让条目变好，我相信我比在座大部分编辑投保留都积极 维基百科:只有情节介绍的虚构作品条目说的是「假如条目永远只能小作品就重定向」，而不是“凡条目可能超过小作品，无论品质多差皆不得重定向”。该文的主旨是“虛構類條目不應止於情節介紹”，而不是“只写剧情问题也不大”。按照中文维基的状况，一味保留只会得到相反结果：编辑更加不会写现实内容。

删除能警示编者，但会失去一些比较好的内容记录，这不是一个好操作。重定向能警示编者，没有删除历史记录的副作用，扩充完可以随时恢复显示，这样我认为是最平衡的。至于保留，说“条目有严重问题，这次先放一马，要求尽快改善”也行，定了个调子我后面还有个话说。现在一些保留票像是“你可以扩充，但这不是多大问题，不扩条目品质也不差”，这让人怎么解释？--洛普利寧 2022年4月5日 (二) 19:03 (UTC)

所以到頭來還是沒有補救方案嗎？不見得不斷加高製造更多壁壘可以推進改寫和衡平之類的方向，現實問題就是這種武斷採用規限手段的事務本身就背離了友善互助之維基社區原處位置，已經是在不斷製造新矛盾而且更加難以吸引新手或者其他可能貢獻的羣體注入動力。歸根結底，要具有積極意義之衡平良策，首先必須打破審查標準極化導致之嚴苛編輯評審體系，不得強硬一統化邏輯不斷地壓縮其他共識空間，反過來需要重新鼓勵回依托不同編輯和背景理解相互補正之互惠方式、促使溝通不同編輯貢獻維基社區--約克客（留言） 2022年4月6日 (三) 04:38 (UTC)

BlackShadowG的問題明明就是批量提刪大量條目，誰救得過來，這個問題不提，在指引那邊兜圈子，如果他只是提刪一兩個我也會從英文那邊搬東西過來。--中文維基百科20021024（留言） 2022年4月6日 (三) 04:49 (UTC)

真把这个视为我的“问题”倒是有趣了，那我现在起每天就提删几个，问题就能解决了？纯剧情角色条目问题长期累积，总条目数量乐观估计也有600+，不从方针层面批量清理，这类条目只会越积越多，后续的编者也会继续参考这种写作模式，对中维带来很多的负面影响。--BlackShadowG（留言） 2022年4月6日 (三) 05:22 (UTC)

如果真是每天能改善几个算几个，问题严重的直接走合并和重定向。这不就解决了问题？我认为你只是偷懒又想显摆罢了。——Sakamotosan路过围观 | 避免做作，免敬 2022年4月7日 (四) 01:15 (UTC)

如果仅仅是强调可以改善而不去改善而保留，这不是好的编辑风格（例如一堆关注度提删时挂一些链接就算了，好歹匹配内容写到条目中啊）。如果能被改善而且确实改善了，这才是好的编辑风格。有些编辑人不干事（摆烂不管）就算了，还干不人事（某些看上去像删除派、说起话像删除派，办起事来像像删除派的），那就不是好事情。——Sakamotosan路过围观 | 避免做作，免敬 2022年4月7日 (四) 01:28 (UTC)

规则的话，现有的Wikipedia:关注度 (虚构)、Wikipedia:資料頁应该足够避免不合适的增量问题（这可能需要新巡查和资深编辑去“阻挡”），现有存量的话，既然能（理论上）阻止到增量，那存量只要不摆烂，还是能慢慢清下来，我看不出这样严重性的问题。——Sakamotosan路过围观 | 避免做作，免敬 2022年4月7日 (四) 01:34 (UTC)

另外写出一堆需要最后用不到的内容真不如不写。别忘了清理内容也是需要时间的。--洛普利寧 2022年4月5日 (二) 17:22 (UTC)

認為閣下單獨列舉如是，最好再斟酌一下補充衡平論述，重複單一傾向對於解決官僚化問題可能沒有意義--約克客（留言） 2022年4月6日 (三) 04:41 (UTC)

首先容我强调，按照WP:PLOT和WP:VG/ROLE的要求，大部分电子游戏虚构列表的品质不足以作为独立条目给读者展示。保留是情分，处理才是本分。

至于要清理的条目，比如英雄傳說 軌跡系列角色列表，清理需要实现“虚构内容长度在现实世界内容长度两倍左右以内”，并确保内容聚焦主线剧情。清理者必须同时熟悉编写方案和作品内容，而这样的编辑是很稀有的。只熟悉编写方案的编辑（比如我）无法分辨主线内容，不知道该清理哪些文字。非要清理也不是不行，硬着头皮玩上一百小时不喜欢的游戏便是，但有这时间清理其他条目不好吗？只熟悉作品的编辑（粉丝）……这些不合适内容的不就是他们写的吗？这不是掌握通用清理准则就能解决的事情。保留等待其他编辑改写，九成以上等于没人改写。

但是这篇条目如果今天不处理，明天就会更难清理，后天则会有更多类似的条目涌现；这就一种恶性循环。在改善条目无法落实的情况下，重定向是避免情况继续恶化的最好方法。读者来维基百科是看现实世界内容的，想看剧情的编辑应当去其他网站。大量爱好者内容只会显得我们是粉丝向网站而非综合百科。这种条目应该回归本源，不给读者呈现。另一方面，粉丝知道作品内容，只是不熟悉/不重视编写方案。通过重定向引发他对编写规则的重视，让他自己收拾自己的坑，我认为是最好的。

我巡查电子游戏新条目多年，虚构列表什么水平还是清楚的。最近又把角色列表看了一遍。不是我官僚化，我一条一条分析，得出的结论就是大部分条目的确“不适合独立开条”。

上面都是方向性的问题，至于实际看法：

1. 没有现实内容只是缺失，不需要额外返工。粉丝内容需要清理，一增一删浪费两份人力。后者应该积极处理，这也是我一直强调的；前者不用太着急。
2. 至少处理品质最差的一批条目，明确表示中文维基关注虚构内容品质。以后给其他编辑讲解时也能举出例子。
3. 游戏领域角色条目（不是角色列表）多是现实内容缺失问题，需要清理的内容不多，这种条目就算被模仿也不难处理。关键还是整改角色列表。
4. 清理内容时给编辑留言说明，编者大多是可以理解的。说不定还能把他发展成优秀的活跃编辑者。
5. 以上内容主要针对角色列表。好吧我跑题了。

--洛普利寧 2022年4月6日 (三) 14:19 (UTC)

有改善空間的條目可不刪除，的確應該留下餘地讓人改善。但那些只有幾千字數冗贅劇情細節甚至是趣聞之類的東西在有人改善之前或可直接先行全部砍掉，只讓條目留下基本的資料。這樣在有人改善之前不會有過度佔比虛構/愛好者內容，同時留下個基礎讓人可以擴充 Iridium(IX) 2022年3月29日 (二) 16:15 (UTC)

這方面我是保留派。如果沒有人來改劇情介紹，愛好者內容總比沒有內容好。--Temp3600（留言） 2022年3月31日 (四) 11:22 (UTC)

‘只讓條目留下基本的資料’與沒有內容分別頗大，沒有內容的話倒不如刪除

內容少自然不是一件正面的事，但至少不會反過來產生些害處，可冗贅愛好者內容就是後者

不刪除條目不是問題，但如果連冗贅愛好者內容也不允許刪除實在是有點過分--Iridium(IX) 2022年3月31日 (四) 13:08 (UTC)

認為Iridium閣下最好應該自行收回有關所謂過分的說法，並建議Iridium閣下和其他可能同一有清理過往貢獻之內容和共識之編輯，可以認真重新閱讀本案所指出之：可謂日益嚴重之強制擴大使用政策之批量重洗，是否應當得到適當限制之？本地有關一些「批量重洗工程」是對維基本地活動之重大重塑，如無特別框架等適度監管之、恐進一步壓制百科內容之發展，認為社羣應適當提案或討論等之而密切跟進，防止可能濫用政策與關聯活動等之進一步不當影響--約克客（留言） 2022年4月3日 (日) 07:01 (UTC)

@Longway22： acg專題本來我就沒有關注，只有一次刪減過些愛好者內容，亦從沒做過任何所謂清理的行動，更從來沒支持過什麼‘日益嚴重之強制擴大使用政策之批量重洗’或‘批量重洗工程’。

本案談的是批量刪除條目，強行刪除有可能改善的條目連寫也不能寫自然‘壓制百科內容之發展’，不刪除條目而只刪除有害的冗贅愛好者內容如何‘壓制百科內容之發展’？現在是不允許你重新拓寫條目基本部分增補有益內容，還是如何？冗贅愛好者內容不適合維基也容易夾藏愛好者原創內容等的問題顯而易見，你找一個幾萬字的角色列表條目大多也能發現這個問題，什麼叫濫用政策？無需要的刪除卻強行說是政策允許算是濫用政策，刪除冗贅幾萬字劇情如何叫做濫用政策？我連行動也沒行動過，你如何聯想出以上一堆與我所說東西無關的東西？

‘冗贅愛好者內容也不允許刪除實在是有點過分’這句話是有什麼問題？廣泛讀者需要這些冗贅愛好者內容？強行保留如何不是過分？看你說話一本正經之來之去，希望你能說出些更有意義的話來--Iridium(IX) 2022年4月3日 (日) 12:22 (UTC)

首先對於本編可能有定性先設之措辭表示一定歉意，希理解有關脈絡之於當前、即如Cwek閣下等上所言近似於「大拆房子」之，即函需垂注無建設可言之事幹——如理解不妥還望指正。另閣下如再自審提論、有無同樣定性先設之？如閣下鮮有涉獵關聯專案、何以立即取「有害」或非主流等之為專案處理之定奪先行？若是以取採同上提舉等先斬而後快、罔顧處理協作等繁務，恐更無助於打理專案後續。

如欲辨所謂冗贅否，非適一張大刀數門戶落地，宜遵單獨個案視之、並保證留備協作編輯於閒時空暇，以持久友善支援之議理、拔除妨擾之壁壘，方可續之而定後著--約克客（留言） 2022年4月3日 (日) 13:00 (UTC)

我雖不太參與這專題，但自有對其觀察。愛好者內容的問題不乏討論，指引裡也有略談。愛好者內容本帶貶義，一段精簡準確闡述劇情大意、過程、結果的段落自然不會與愛好者內容拉上關係。至於具建設性與否和其意義，你可以去問問WP:OR、WP:NOT或WP:WEIGHT

我本沒說過要不分皂白全部刪除，是否冗贅編者自有判斷。愛好者內容的辨別對有點經驗的編者而言本來就顯而易見，不構成所謂的‘定奪先行’，麻煩往往只是在後續處理的問題。除非編者有意針對，不然編輯條目自然是各個單獨判斷。一篇遊戲角色如果評價部分的內容仍然全是對角色虛構層面強度或玩法的評價，對愛好者以外並完全沒有存在意義，與其留下加劇失衡不如直接砍掉。虛構劇情相對棘手，但如果是如不少角色列表裡面有綜述段落和‘各分集劇情’，前者乃必須，後者也明顯可先直接砍掉留下前者慢慢改善。如果某一大段的愛好者內容中混了組成條目的必須部分，那的確不宜直接砍除而只能等待相關編者刪減。

所謂「大拆房子」，如果結構基礎早已崩壞，那留下除了構成危險外對重建毫無幫助，倒不如先完全拆除讓出空間重建。這完全並不妨礙後續條目的改善

另外你的文字越發難以解讀，請你用更為白話的方式不然有礙溝通--Iridium(IX) 2022年4月3日 (日) 15:29 (UTC)

感謝回覆，不過基於文書提法之特點、本編傾向恰恰相反，是需要避免一些所謂現有話語之制限、以鮮明指出現階段部分環境下，包括採用不合比例之霹靂手段到表面可能多數暴力等種種、都是本地急需規制之取向，否則難以容許社區繼續談論可持續之改善和發展之共識。--約克客（留言） 2022年4月5日 (二) 14:49 (UTC)

• 現在維基百科也太過矯枉過正了吧，連覆雨翻雲角色列表、大唐雙龍傳角色列表、盛唐三部曲角色列表這些角色列表也給刪除，關注度、虛構事物都符合收錄標準，但卻給一個Fanpov輕輕給刪除，然後又再走一次牛年馬月不知何時才處理的Wikipedia:存廢覆核請求，根本浪費時間人力物力行政程序。－日月星辰｜留言簿 2022年4月7日 (四) 14:10 (UTC)

提议Wikipedia:格式手册/虚构成为正式指引

该论述近期已依据英维现行版本进行修订，让我们帮助它成为正式指引！--Taeas（留言） 2022年3月25日 (五) 15:31 (UTC)

笑死了，维基百科并不隐藏、避免或努力在情节摘要或类似材料中标记破坏者，但破坏者只应在提供完整的情节以达到百科全书式的目的时才被列入，要不我们来探讨一下这个破坏者是什么呢？--MilkyDefer 2022年3月25日 (五) 16:51 (UTC)

同MilkyDefer，在改善好語文部分前程序性(－)反对。--路西法人𖤐 2022年3月26日 (六) 02:13 (UTC)

@MilkyDefer @LuciferianThomas 已将“破坏者”修改为“剧透内容”--Taeas（留言） 2022年3月26日 (六) 03:04 (UTC)

粗看了一下，好像留意到一些怪异的术语，不知道是不是翻译有问题。另外有部分没必要的着重号，视乎在刻意地模仿en的行文，这些行文是否具有必要性？先暂时(－)反对。——Sakamotosan路过围观 | 避免做作，免敬 2022年3月26日 (六) 03:12 (UTC)

再补充，里面有一些链接到当地的指引等规则的页面，但在本地的可能是还没有进行规则化（或者还处于草稿或者不健全的），可能会导致执行起来会无规则可依或者会被扩大解释。而且仅仅靠屏蔽这些链接也不是好方法，也就是影响引用这些链接的条目的合规性。——Sakamotosan路过围观 | 避免做作，免敬 2022年3月26日 (六) 03:50 (UTC)

这类页面可以点出来，顺带一起修订。--Taeas（留言） 2022年3月26日 (六) 03:53 (UTC)

例如：Wikipedia:格式手冊/瑣碎章節、Wikipedia:条目长度、Wikipedia:格式手册/列表（只有部分章节性指引）、Wikipedia:日本動漫遊戲條目指導（这个也具有指引化的潜质，但是同样也是面对同样的问题）。——Sakamotosan路过围观 | 避免做作，免敬 2022年3月26日 (六) 15:36 (UTC)

翻译可能有点问题，不过最好能将“怪异的术语”点出来。--Taeas（留言） 2022年3月26日 (六) 03:15 (UTC)

另外，考虑到最近所发生的各种翻旧账行为，虽然这个草案的想法是很好的，但我担心这会成为鸡毛令牌，有可能完全打破现有编辑平衡（旧账愿意管才处理，新问题尽量能避免则应该避免）。——Sakamotosan路过围观 | 避免做作，免敬 2022年3月26日 (六) 03:37 (UTC)

这方面的担忧并非没有道理，不过我认为向前看还是很有必要的。--Taeas（留言） 2022年3月26日 (六) 03:48 (UTC)

如果基于令条目质量得以冲评价的话，是有好处的。但是基于现状的话（人手、该类条目的普遍质量、编辑的普遍编写风格），把这些弄成白纸黑字就不一定是好事。或者我的想法为：为好的编写内容用规则来背书，而不是利用规则扣字眼般来地清理旧账。尤其是某些急行军一样地彰显业务了得的编辑。——Sakamotosan路过围观 | 避免做作，免敬 2022年3月26日 (六) 04:06 (UTC)

是有可能被用于清理旧账，但它对新条目的规范作用也是巨大的。--Taeas（留言） 2022年3月26日 (六) 04:13 (UTC)

有个概念是祖父条款，按照这里的意义就是规范新条目的格式，鼓励旧条目向这个方向靠拢但不应作为删除理据。--MilkyDefer 2022年3月26日 (六) 04:18 (UTC)

这是个不错的想法，不过旧条目如何界定或许需要探讨一下。--Taeas（留言） 2022年3月26日 (六) 04:29 (UTC)

规则问题不大，问题是有些编辑拿着“鸡毛”用这种压迫性的方式来驱使其他编辑去跟着他们的屁股去收拾残局，而没考虑过方针存在弹性的考虑或者自己尝试去改善，Wikipedia:维基百科并不需要你真的很适合他们，按照现状，“摆烂”才是常见状态，做大刀阔斧的“卫道士”不一定有益处。——Sakamotosan路过围观 | 避免做作，免敬 2022年3月26日 (六) 09:03 (UTC)

我认为直接点出如何才能让提案通过的可能性较大会更好一些。--Taeas（留言） 2022年3月26日 (六) 15:02 (UTC)

我觉得更像是：这个指引（草案）对于改善条目质量（例如用于评级）是有好处的，但不想将它变成给某些固执的编辑递刀子。——Sakamotosan路过围观 | 避免做作，免敬 2022年3月26日 (六) 15:39 (UTC)

怎样才不算是递刀子？另外，一些编辑的做法在程序上是没有问题的。--Taeas（留言） 2022年3月26日 (六) 15:46 (UTC)

如果不是没问题，为什么会引起其他一些编辑的反感，甚至被拉到编辑争议版上？而且这个指引草稿存在了多年，为什么突然被拉出来讨论了？规则没问题，问题是如何和怎样去使用规则。——Sakamotosan路过围观 | 避免做作，免敬 2022年3月26日 (六) 15:53 (UTC)

1.程序和一些人的主观是存在差异的。2.“存在了多年”而未成为正式指引即可成为理由。

如果愿意探讨“如何和怎样去使用规则”，我想这对提案的帮助远大于以上内容。--Taeas（留言） 2022年3月26日 (六) 16:27 (UTC)

上次一天之內說幾十個條目是fans所以要移動到維基學院是你吧？你和BlackShadowG偶爾提一兩個是沒問題，提幾十個就是有問題，讓「改善條目」這條道路被堵死。--中文維基百科20021024（留言） 2022年3月27日 (日) 06:07 (UTC)

甚至，BlackShadowG提刪伏地魔的時候竟然在編輯摘要說了一聲「可惜」，自己都覺得可惜還提刪，不知道你們怎麼想的。--中文維基百科20021024（留言） 2022年3月27日 (日) 06:09 (UTC)

BlackShadowG有空去提刪怎麼不去完善自己曾經寫的半成品呢？BlackShadowG 3月初創建的俄乌战争期间对乌克兰的援助列表有大量英文未翻譯就直接發佈，幸虧被AINH發現退回到草稿，3月24日才被Yinyue200重新完善。該做的不做，提刪倒是很起勁。--中文維基百科20021024（留言） 2022年3月27日 (日) 06:14 (UTC)

甚至BlackShadowG是知道有电子游戏群组的存在，完全可以提出来，让人逐点清理，而不是一股脑地提删。——Sakamotosan路过围观 | 避免做作，免敬 2022年3月27日 (日) 06:18 (UTC)

我觉得“可惜”是这个条目能写很多现实内容，现在写成纯剧情违反方针还得提删才觉得“可惜”。

把我以前写的条目拿来指责我是更想不到的，我3月初创建的俄乌战争期间对乌克兰的援助列表本来想一个晚上全部翻译完的，但由于现实生活中的一些缘故没能翻完，第二天向继续翻译时发现已经被AINH移动到草稿了。那时英文维基百科的条目本来也很不稳定，当时我就想既然已经被移动到草稿了，不如等英文条目稳定了再来翻译，就去翻译另一篇GA去了。这还能被人说是“该做的不做”更是令人想不到的。--BlackShadowG（留言） 2022年3月28日 (一) 02:55 (UTC)

“规则”是“完美”的，如果有缺陷，那就是人。鉴于最近的事件，这就是缺陷所在。——Sakamotosan路过围观 | 避免做作，免敬 2022年3月27日 (日) 06:18 (UTC)

中維不是英文維基百科中文版，雖然很多都這樣做。個人對相關內容甚至連例子都照搬感到不解，「《巨蟒与圣杯》中有一些笑话和短语已经进入了流行语」，「例如，不要写『现在是公元34,500年，特朗托里亚帝国大约涵盖了半个银河系』，而要写『《空间的潮流》的背景是公元34,500年，特朗托里亚帝国大约涵盖了半个银河系』」，請改為中文使用者更容易理解的例子，謝謝。如英維的天是藍的（Wikipedia:You don't need to cite that the sky is blue），中維是维基百科:孙中山是男性无须引用。

不明就裡的例子，看完之後反而更困惑。此外中維也有相當數量的GA和FA條目可以作為具體條目類型的例子，英維有舉出，中維的如何不舉出？？--Nostalgiacn（留言） 2022年3月26日 (六) 05:13 (UTC)

已更改，确保所举例子在中维皆有条目。--Taeas（留言） 2022年3月26日 (六) 06:42 (UTC)

非原生中文作品的，大部分都有地區詞。此外，改為一些原生中文作品的例子真的很難嗎？--Nostalgiacn（留言） 2022年3月26日 (六) 07:05 (UTC)

不难，但是使用非原生中文作品的例子对阐述指引观点并无影响。且，大部分影视类GA/FA条目为非原生中文作品。如，《E.T.外星人》为FA条目。--Taeas（留言） 2022年3月26日 (六) 07:16 (UTC)

• 想到本土例子當然很好，如您能提出一些就最好了。但如果沒有人想到更好的例子，沿用英文例子顯然是最簡便的做法。--Temp3600（留言） 2022年3月30日 (三) 11:07 (UTC)

  古有四大名著（{{中國文學名著}}），今有{{金庸作品}}、《三體系列》《仙劍奇俠傳系列》等等多不勝數。個人十分懷疑翻譯的人知不知道原文想表達的意思。早期就是翻譯錯誤，過去相關指引半知半解，甚至刪除條目內有價值的相關現實內容。--Nostalgiacn（留言） 2022年3月31日 (四) 04:09 (UTC)

  过去并不代表当前指引有问题。至于例子的问题，方便使用本土例子的就尽量使用，有时间我会去找找。当然，使用当前例子“对阐述指引观点并无影响”。--Taeas（留言） 2022年3月31日 (四) 04:24 (UTC)

  本土例子差不多是沒有。中維在這方面差不多都是翻譯為主。--Ghren🐦🕕 2022年3月31日 (四) 10:28 (UTC)

  上面我還提到「非原生中文作品的，大部分都有地區詞」，現在頁面提到的作品都沒有地區詞處理，很明顯提案人連中維特色的地區詞的規範都不甚了解。

  如果明了原文的意思，舉例可以說信手捏來，如「《星艦奇航記》系列中的星际舰队的历史会以类似于美国空军的方式来描述」，可以換成「《GUNDAM 00》中的人類革新聯盟的歷史以類似東盟的方式描述」，甘道夫的例子改成「郭靖是金庸筆下的武功高手」等等。接地氣的例子比比皆是，也更容易讓中文使用者理解，而且還不用考慮地區詞。--Nostalgiacn（留言） 2022年3月31日 (四) 15:38 (UTC)

本章節暫時不存檔，需要时间修改里面的例子。欲讓機器人存檔，請移除本模板。留言請置於本模板上方。

修订可靠来源

“硕士学位论文通常未经类似评估，因此不如博士学位论文可靠，除非其具有显著学术影响。”改为“硕士学位论文通常未经类似评估，因此通常不如博士学位论文可靠。”-Fire Ice 2022年3月26日 (六) 16:50 (UTC)

• Why?-某人✉ 2022年3月27日 (日) 08:36 (UTC)
  • 删除学术影响（可能为负面）判定，避免误解。Fire Ice 2022年3月27日 (日) 08:53 (UTC)

    刪除的話不是更會造成基於學位的偏見判讀嗎？原句更有保障效果吧。--約克客（留言） 2022年4月3日 (日) 07:10 (UTC)

    没看懂。我认为：一、你维对优秀硕博论文不够重视。二、显著学术影响不能保证作为事实来源的可靠性（但是能说明作为观点来源的重要性），以删掉为妙。--Fire Ice 2022年4月7日 (四) 14:36 (UTC)

提議將过度分类的包含主观性的标准定為指引

提議將Wikipedia:过度分类下包含主觀性的標準一節定為指引。

本節內容符合中文維基百科存廢討論的共識（見條文之例子），將其定為指引可供編者參考。--【和平至上】💬 2022年3月26日 (六) 17:32 (UTC)

行。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年3月27日 (日) 19:41 (UTC)

• (－)強烈反对「主觀」的判定本身就是主觀，而明顯缺乏常識的你維明顯沒法判定何謂主觀。毛澤東我給了好幾個經過同濟互評的論文證明是Category:極權主義領導人仍然被回退又怎麼算？-某人✉ 2022年3月27日 (日) 21:03 (UTC)

你那是可能违反cat，和这个主观有啥关系。Fire Ice 2022年3月28日 (一) 04:42 (UTC)

對閣下的理據感到費解。你那個例子明明是因為WP:CAT所以被反覆回退，跟這裏的主觀性有何關係？如果你是指條文裏對中立性的要求，那麼你應該提請修改WP:NPOV以及WP:CAT，因為這一章節根本對你所舉的例子沒有任何影響。基於閣下言辭中欠缺積極參與討論的態度（「明顯缺乏常識的你維明顯沒法判定何謂主觀」），以及你所舉的例子根本與本提案無關，我認為閣下的觀點並非有效的反對意見。--【和平至上】💬 2022年4月2日 (六) 12:22 (UTC)

支持。--东风（留言） 2022年4月4日 (一) 15:55 (UTC)

(＋)支持，我觉得提议条文应该已经算是常识了。--BlackShadowG（留言） 2022年4月7日 (四) 12:31 (UTC)

再议设立删除员

第一次设立删除员的建议出现在2019年。当时的反对意见概括如下：一、删除需要管理员的核心能力，因此删除员门槛不应低于管理员。（Antigng）二、afd、drv积压的原因是讨论不充分，而不是管理员不勤奋。（Techyan）三、“会使得条目删除和其他诸如封禁用户之类的站务维护相脱节”。（Techyan）

第二次设立删除员的讨论出现在2021年。当时的反对意见概括如下：一、删除需要管理员的核心能力，因此删除员门槛不应低于管理员。（Antigng）二、“如果是因为选管理员的问题，那么应该去想办法解决管理员难选的问题”。（shizhao，安忆）三、afd、drv积压也没问题，不用专门设立删除员处理积压。（Googol19980904）

如我概括的反对意见有所遗漏，欢迎补充。我认为：一、由于rfa困难，且目前来看难以改善，二、降低afd和drv积压是有必要的，因为长久挂着afd和drv板不是个事，中文维基百科应当设立删除员。最低要求可以等同管理员，但不应成为另一个rfa，有效票要求应当降低。此外除权门槛应当降低，可以考虑30%至50%同意即可除权，即相当于设立一个高风险的专于删除的管理员职位。

前次讨论结果在WP:删除员，欢迎继续讨论！--Fire Ice 2022年3月27日 (日) 17:58 (UTC)

如果一定要設立，選舉模式和有效票應該和管理員應該一樣，可以考虑30%至50%同意即可除权，而且必須曾經多次參與過afd和drv討論才行，而且每天像機器人一樣將Wikipedia:关注度/提报中的條目提交至afd的人不算。--中文維基百科20021024（留言） 2022年3月27日 (日) 18:09 (UTC)

而且還要考慮一個問題，刪除員萬一偷偷刪除不經過討論也沒有被提交至快速刪除的條目怎麼辦？或者刪除員不想呆在維基了，臨走前一天刪除個幾百、幾千個條目也是可以的、雖然理論上這些情況可以提出罷免或者走drv。所以這樣考慮下來刪除員不見得重要性就不如管理員。--中文維基百科20021024（留言） 2022年3月27日 (日) 18:14 (UTC)

技术上能否设置删除限额？比如一天内不能删多于十个条目之类。Fire Ice 2022年3月27日 (日) 18:16 (UTC)

這個可以，而且要刪也是優先刪沒人有異議的條目。--中文維基百科20021024（留言） 2022年3月27日 (日) 18:21 (UTC)

另外telegram有人提議刪除員不能删除「未提删的條目」，自己不能删除「自己提删的條目」，不知技術上是否能實現。--中文維基百科20021024（留言） 2022年3月27日 (日) 18:28 (UTC)

無法實現。--Xiplus#Talk 2022年3月28日 (一) 07:42 (UTC)

這是有多不信任刪除員。以政策規定即可。--Ghren🐦🕓 2022年3月28日 (一) 08:34 (UTC)

「刪除員不想呆在維基了，臨走前一天刪除個幾百、幾千個條目也是可以的、雖然理論上這些情況可以提出罷免或者走drv」

I mean the same thing could be said with admin?-某人✉ 2022年3月27日 (日) 18:27 (UTC)

是的，所以說刪除員重要性不亞於管理員。--中文維基百科20021024（留言） 2022年3月27日 (日) 18:29 (UTC)

1.建議直接報告到meta.wikimedia.org申請全域鎖定

2.建議在meta.wikimedia.org申請恢復被破壞的內容--Rastinition（留言） 2022年3月28日 (一) 04:54 (UTC)

「由於rfa困難，且目前來看難以改善」，都不去討論管理員選舉改革，怎麼有可能改善？社群甚至連一個安全投票的暫行規定都討論不出來，盡想著繞道，設立各種「有限度的管理員」；然而刪除或封鎖等都是管理員的核心技能，即使捨本逐末地將這其中某幾項權限分拆出來，也相當於五分之四個管理員了，我不認為可以就此特別降低遴選標準，至少相對於管理員而言。為什麼不好好討論一下如何適度調整管理員的遴選標準，或檢討一下社群在心理上對其過於「完美」的要求？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年3月27日 (日) 19:25 (UTC)

我这一段时间一直在处理存废，就我的观察，造成积压的主要原因不是关闭存废的人手不足，而是讨论不充分造成无法及时关闭讨论。所以即使有大量删除员，情况也并不会有什么改善--百無一用是書生 (☎) 2022年3月29日 (二) 02:54 (UTC)

就怕删除员不看是否充分討論而是看自己的喜好選擇是否刪除條目，這種不合格的刪除員寧願不要。--中文維基百科20021024（留言） 2022年3月29日 (二) 03:15 (UTC)

我的观察，恰恰和您相反：造成积压的主要原因不是讨论不充分，而是管理员缺乏决断。到现在，管理员关掉的许多存废讨论也很长时间没有新讨论了，那么为什么不能早点关掉呢？--Fire Ice 2022年4月7日 (四) 14:13 (UTC)

(＋)支持设立删除员，如果担心删除员的操作有争议可以设立公示制，删除员必须公示3天后删除。还应该设立保护员，规定保护员只能保护自己未涉入编辑争议的页面，保护员可以设定或解除全保护但不能编辑全保护页面。另可参考V:WV:看守員，设立准管理员。桐生ここ★[讨论] 2022年3月29日 (二) 08:09 (UTC)

如果有條目要淪落到公示才能刪除，那實際上管理員早就已經刪除了。--中文維基百科20021024（留言） 2022年3月29日 (二) 08:30 (UTC)

不支持将管理员的权限拆分成多个用户组，与其这样，还不如多关注一下管理员选举怎么改革（这个议题OA时讨论几天后又没声音了，看来社群也没想修这个机制）。--BlackShadowG（留言） 2022年3月29日 (二) 08:35 (UTC)

“与其……不如……”是你维很多人反对某项改良的经典句式。那么“不如”不如不起来怎么办？只好把手一摊：都怪社群不努力！--Fire Ice 2022年4月7日 (四) 14:10 (UTC)

只在技術上提出一個可能性。在這個基礎上新增一條快速刪除方針，當刪除員掛上這個快速刪除模板的時候，就可以刪除，然後寫個過濾器阻止一般用戶加上這個快速刪除模板。這樣的話可以做一個「只刪除」的偽用戶組。--Ghren🐦🕙 2022年4月7日 (四) 14:48 (UTC)

這倒是跟萌娘百科的巡查員有點像。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年4月7日 (四) 16:30 (UTC)

註：此處原有文字，因為DENY，已由路西法人於2022年4月5日 (二) 18:32 (UTC)刪除，尚祈見諒。若有異議請至互助客棧或向管理員反映。

关于中华民国籍香港居民

1949年前在内地出生的中华民国国民，在1949年前移居香港后，如果没有主动办理丧失手续，至今是否依然拥有中华民国国籍？如果是，是否意味着这些人既是中华人民共和国藉香港永久居民，又是中华民国国民？也就是说可以同时使用Wikipedia:格式手册/两岸四地用语的制定样式5和7。如果不是，这些人是否在1949年或1997年自动丧失中华民国国籍？会问这些问题是因为注意到陳日君枢机的国籍标识由中华人民共和国（香港）被改为中华民国，我认为两者似乎都是有道理的，因此根据Wikipedia:格式手册/两岸四地用语第13条像黎智英这样并列标识为佳，却又不十分确定。黎智英在出生时是中华民国国民，条目的标注是延续至今，而诸如郭沫若这样一直居住在内地的人的中华民国国籍仅标识到49年，不知道中华民国国籍法对于香港居民和大陆居民的相关规定是否不同。--立日（留言） 2022年3月29日 (二) 17:13 (UTC)

說了很多遍了，除非他本人有公開國籍，否則不要添加國籍資訊。因為您無法保證他到底是否有其他國家的國籍或有沒有放棄所謂的原本國籍，尤其是香港有多重國籍的人多不勝數，也有很大可能已經放棄了原國籍而未有公開。--AT 2022年3月29日 (二) 17:27 (UTC)

认同需要来源，但来源的种类可能会有些模糊。现在大部分条目人物的国籍，要么和WP:孙文一样，“孙中山有中华民国国籍”应该也无需引用；要么像黎智英的几个国籍标注，中华民国和英国是引用媒体来源，其他都是引用相关法律的。我认为即使本人没有明确阐述自己的国籍，依据国籍相关法律判断国籍也是可以的，所以才希望能明确一下中华民国藉香港居民的问题。可能会写上被放弃而未公开的国籍，但总比都不写好，像香港出生的馬英九并没有明确是否持有英国国籍，但如果因此就不写中华民国国籍了对这个条目而言反而遗漏了一个重要信息。--立日（留言） 2022年3月29日 (二) 18:38 (UTC)

這仍然是在假定，沒有排除到當事人可能已經放棄國籍的可能性，況且國籍也不是什麼重要資訊，像英維日維的馬英九條目均沒有此項目。任何憶測的資訊均應該避免，Wikipedia:孙中山是男性无须引用說的是：「「孫中山是男性」這類顯然的信息不需要引用」國籍不如性別顯然，就算是顯然易見也不代表就一定要寫進去，就像孫文是男性也不見得就一定要寫進首段或資訊框，國籍也是同一道理，更何況可能存在爭議呢。--AT 2022年3月30日 (三) 04:33 (UTC)

不认同国籍不是重要資訊--葉又嘉（留言） 2022年4月1日 (五) 05:55 (UTC)

無論重要與否，請提出可靠來源來證實，不要假設。--AT 2022年4月3日 (日) 07:39 (UTC)

除非是台灣人來到香港定居，否則所謂中华民国籍香港居民是不是和中華民國籍大陸居民一樣沒有什麼太大意義？這類人在台灣又沒有公民權。--中文維基百科20021024（留言） 2022年3月31日 (四) 11:35 (UTC)

主要是1949年前出生的人出生时确实是中华民国国民，但是这些人在国籍期间上应该怎么表述格式手册没有明确，如果是香港居民又更复杂了，这样其实会有潜在的中立性问题，比如为什么郭沫若标到49年而黎智英则是从48年开始一直延续，陈日君国籍写中华民国是否合适等。像AT说的不确定就不写可能更好，但是目前方针没有明确。--立日（留言） 2022年3月31日 (四) 11:57 (UTC)

如同丘成桐 是有的--葉又嘉（留言） 2022年4月1日 (五) 05:58 (UTC)

丘成桐在1997年前就移居美国了，这样就不涉及中华人民共和国的标识问题。不过我这里比较关注的是一直居住在香港的中华民国国民，在97年后按法律就有了中华人民共和国国籍，这样在标识上难免出现争议，到底是只标中华民国好呢，还是只标中华人民共和国（香港）好呢，还是两者都标上好呢。国籍的持续时间也是个问题。--立日（留言） 2022年4月3日 (日) 07:23 (UTC)

提议更换Mediawiki保护标志

鉴于目前模板保护与Mediawiki保护标志相同，我与User:FoolPiasar设计与制作了一版标志：

橙色和mw图标代表Mediawiki，代表保护是由Mediawiki自动作出的。

--中维金苹果，时不时给维基人们加buff（留言） 2022年4月1日 (五) 00:04 (UTC)

(＋)支持 Buenos※Días 2022年4月1日 (五) 01:12 (UTC)

可以的。--Tranve (✉) 2022年4月1日 (五) 01:43 (UTC)

(？)疑問：这个标志中有锯齿状圆环，但是缩小到一定程度后完全看不出锯齿图案。所以为什么不直接使用光滑的圆环呢？--Yining Chen（留言|签名页） 2022年4月1日 (五) 01:56 (UTC)

因为那样就不是mediawiki了啊（笑--InsaneGuo（留言） 2022年4月1日 (五) 01:59 (UTC)

Telegram群里面已经有人反映了此问题，我已经上传了一版新的（由于这几个名字我全部写错了，已经提出移动请求，移动后别忘了把这里的改了）--中维金苹果，时不时给维基人们加buff（留言） 2022年4月1日 (五) 02:07 (UTC)

(＋)支持 十分好康 --InsaneGuo（留言） 2022年4月1日 (五) 01:56 (UTC)

(！)意見：一看就知道各位不记得过往讨论了吧…… --MilkyDefer 2022年4月1日 (五) 02:44 (UTC)

囧rz……--中维金苹果，时不时给维基人们加buff（留言） 2022年4月1日 (五) 03:10 (UTC)

(＋)支持Abcd715（留言） 2022年4月5日 (二) 01:59 (UTC)

感覺可以，反正現時使用中的保護標誌並無環狀圖案，就算看成“O”也沒太大關係。Sanmosa _{Avec cœur} 2022年4月6日 (三) 07:46 (UTC)

如果一定要这样想也不是不行，但是明明有更适合小图标的mw花瓣版本--MilkyDefer 2022年4月6日 (三) 13:02 (UTC)

是指File:MediaWiki-2020-small-icon.svg吗？我也是觉得如果能用这个标志做成保护图标效果更好。--BlackShadowG（留言） 2022年4月7日 (四) 12:05 (UTC)

提议设立官方维基百科镜像供国内直连访问和编辑

首先提醒一下，这不是纯粹的技术问题，只有社群确定“这样做合适”之后才应该讨论技术细节。

这是我在近期乌克兰战争的背景下产生的想法。如果设立官方镜像，以下问题可以解决：

1. 国内用户无法直连访问（不考虑少部分技术能力强的用户）
2. 国内用户编辑必须要通过代理及申请IPBE，步骤繁琐（这是本站长期以来的痛点）

然后关于能不能实现，我问了几个技术人员，回答是“有难度但并非完全不可行”。

以上。好久没来客栈了，总之欢迎各位留言，谢谢。--Tranve (✉) 2022年4月1日 (五) 01:43 (UTC)

如果好不容易建起來然後就被封了怎麼辦？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年4月1日 (五) 01:47 (UTC)

当然是打一枪换一个阵地。域名封一个换一个。IP的话可以考虑用CDN，GFW一般不会封CDN的IP。--Tranve (✉) 2022年4月1日 (五) 01:49 (UTC)

2021年维基媒体基金会针对中文维基百科的行动里面中国政府的态度还不够明确？这种跟土共打游击的玩法没啥意义，就算是CDN，CDN的IP一样有办法扬掉（github等有几个CDN服务商的IP被长期盯死了）。——Sakamotosan路过围观 | 避免做作，免敬 2022年4月1日 (五) 02:37 (UTC)

设立官方维基百科镜像，就需要走合规途径。“当然是打一枪换一个阵地。域名封一个换一个。IP的话可以考虑用CDN，GFW一般不会封CDN的IP”。这是完全不合规的做法--百無一用是書生 (☎) 2022年4月1日 (五) 03:14 (UTC)

嗯……我想你误解我的意思了。如果你的“规定”指的是中国法律的话，那上维基百科本来就犯法了，还管它干什么？如果是基金会的相关规定，我的本意就是想现在这里沟通然后再去和基金会提意见。--Tranve (✉) 2022年4月2日 (六) 02:11 (UTC)

这种不合CDN服务商的规定，最终结果就是CDN被GFW封掉，GFW为了封掉Twitter可是把Fastly封了，于是没有CDN会愿意为维基百科提供服务。桐生ここ★[讨论] 2022年4月3日 (日) 14:33 (UTC)

为什么不合规？Fire Ice 2022年4月1日 (五) 14:23 (UTC)

多让一个人上维基百科就是意义。你维到底为十四亿人接触自由知识做了什么！？--Fire Ice 2022年4月1日 (五) 16:02 (UTC)

這些話你找習近平說更好，為什麼不讓中國人瀏覽維基百科，為什麼要把翻墻瀏覽維基百科的中國人拘留。如果要找基金會，就像我下面所說的，勸他們允許使用代理服務器的用戶直接免IPBE就能編輯。--中文維基百科20021024（留言） 2022年4月1日 (五) 16:45 (UTC)

现在是客观条件无法改变，只能指望基金会主观努力了。--Fire Ice 2022年4月2日 (六) 12:35 (UTC)

基金会没有主观努力的必要，只要不按照中国政府的要求进行内容审查，主观努力反而会得罪中国政府，彻底被认证为境外颠覆势力，造成基金会人士或社群知名人士进入中国境内的人身安全风险。你见Facebook、Twitter、Google有主观努力和GFW打游击战吗？桐生ここ★[讨论] 2022年4月3日 (日) 14:26 (UTC)

@Cwek：首先那些服务商都没有被完全扬掉，只是间歇性抽风。退一万步讲，就算你维真的被这样针对，也比现在的情况好太多了。现在可是完全不能访问啊！--Tranve (✉) 2022年4月2日 (六) 02:13 (UTC)

是CDN服务商的部分IP。推断是路由黑洞。——Sakamotosan路过围观 | 避免做作，免敬 2022年4月2日 (六) 02:26 (UTC)

是的，阁下提出了一个可能有机会解决问题的方法，与其解决镜像站的准入标准，不如使用官方镜像站。--Pavlov2仁爱亲诚 2022年4月1日 (五) 12:55 (UTC)

與其提供中國直連不如允許中文站無需IPBE直接代理編輯更好。因為中國直連這一方式政治上走不通。代理編輯由與基金會政策違背，除非基金會願意特殊對待中文站。如果說說服中共和基金會的話，好像說服基金會相對更容易一些？--中文維基百科20021024（留言） 2022年4月1日 (五) 16:41 (UTC)

又是閆那個消極對待開放代理的方法嗎？--Ghren🐦🕛 2022年4月1日 (五) 16:53 (UTC)

消極對待開放代理是指？--中文維基百科20021024（留言） 2022年4月1日 (五) 17:04 (UTC)

之前Techyan等提出开放代理不应该自动封禁，而是有破坏再去封，方便大陆用户注册使用，然后Jimmy-abot就停止自动封禁开放代理。（節刪）[2021年9月]被推翻。 ——魔琴 [ 留言 贡献 ] 2022年4月3日 (日) 03:22 (UTC)

因為techyan被封禁所以那個措施就要被推翻？誰提出的？--中文維基百科20021024（留言） 2022年4月3日 (日) 03:27 (UTC)

Wikipedia:互助客栈/其他/存档/2021年9月#重启“机器人自动封禁机房IP段的任务”的提议，和913没啥关系。--Lt2818（留言） 2022年4月3日 (日) 03:50 (UTC)

忘记具体时间了，已经节删。 ——魔琴 [ 留言 贡献 ] 2022年4月3日 (日) 06:39 (UTC)

我只能说techyan这么做，为LTA逃脱CU大开方便之门--Pavlov2仁爱亲诚 2022年4月3日 (日) 07:57 (UTC)

我猜测肯定之前有人讨论过这个方案，但是事实上中维并没有放开IPBE，估计这么做肯定是遇到问题了。--Tranve (✉) 2022年4月2日 (六) 14:07 (UTC)

(～)補充：澄清一下上方的误会。我的想法是我们可以像某些VPN服务商、NSFW网站和樱花动漫一样，搞一系列的官方镜像站，通过多种渠道散播其地址。如果一个被封了，就换另一个顶替。--Tranve (✉) 2022年4月2日 (六) 02:10 (UTC)

因为是官方镜像站，所以技术上我们是可以知道访问者的真实IP的，这样就从根本上规避了IPBE的问题。

我知道这个做法比较难看，但它却是最符合中国国情的方案——对新手友好，学习成本低。想想看Help:如何访问维基百科里头有多少技术范的方案，但是又有几个新手会用呢？--Tranve (✉) 2022年4月2日 (六) 02:22 (UTC)

维基百科条目常被引注，其链接需要长期保持可用。如果搞一系列的官方镜像站，那么每个域名都不能随意抛弃，要考虑长期维护域名的成本。--Lt2818（留言） 2022年4月2日 (六) 04:56 (UTC)

确实有这个情况。但我觉得在镜像站里写好“引注使用原网址”，像安忆的镜像站一样，就好。总之感谢各位的意见。--Tranve (✉) 2022年4月2日 (六) 14:06 (UTC)

官方镜像站八成不会有，“封一个换一个”不是说的那么简单的，无论是域名还是IP，很显然要考虑成本问题。树大容易招风，镜像站本就应该小众，才能降低被封的几率，官方提供镜像站做不到维持小众，而且维基百科本就受到墙的重视，要不然不至于五个IP有三个被封。--🔨（留言） 2022年4月2日 (六) 08:56 (UTC)

成本问题我觉得WMF自己最清楚吧。到时候可以问问他们。--Tranve (✉) 2022年4月2日 (六) 14:04 (UTC)

域名也是要钱的，同时维护镜像站也需要一定的人力。假如说每换一个域名都是没过几天就被墙，还不如干脆不搞。--🔨（留言） 2022年4月2日 (六) 14:59 (UTC)

咱不知道基金会能不能做，咱只知道安忆的镜像站没钱了（ ——魔琴 [ 留言 贡献 ] 2022年4月2日 (六) 15:42 (UTC)

2020年Techyan就提过几乎相同的提案：m:Wikimedians of Mainland China/Draft proposal on establishing an official mirror site of Wikimedia projects for mainland Chinese users。--GZWDer（留言） 2022年4月2日 (六) 20:25 (UTC)

这个似乎只是草稿，还没有正式讨论。--Tranve (✉) 2022年4月2日 (六) 23:22 (UTC)

真要合规运营，我估计必须在镜像站删掉一些（甚至大量）“敏感内容”，这就是彻底把WP:NOTCENSOR当摆设了。--BlackShadowG（留言） 2022年4月3日 (日) 07:23 (UTC)

用镜像站和GFW打游击战这种方式，WMF肯定是不会做的，倒是可以中维社群设立一个社群官方镜像站。WMF服务器通过捐款运营，那么社群官方镜像站也可以通过捐款运营，可以成立一个维基百科组织负责运营官方镜像站，并且可以和WMF一样在中文维基百科打募集捐款的广告，这个组织可以写入方针指引，就像WP:機械人審核小組一样。桐生ここ★[讨论] 2022年4月3日 (日) 14:44 (UTC)

我觉得这个想法很好啊！--Fire Ice 2022年4月3日 (日) 14:50 (UTC)

如此镜像站运营者面临极高法律风险，相当于外国基金会注资的代理人；用户数据安全也成问题；捐款同样有法律问题。官方性质或背书的镜像站运营我认为不可行，推广亦同样需慎重低调，希望各位先想清楚。如果是通过工具或网站代理访问，面临渠道被封和IPBE、反破坏问题。--YFdyh000（留言） 2022年4月3日 (日) 15:19 (UTC)

我们都不是WMF，谁也不能代替他们发言吧？--Tranve (✉) 2022年4月3日 (日) 15:59 (UTC)

这个想法不错，不过还是那句话，树大招风，而且还要考虑“内鬼”的问题，如果能够确保维持小众低调，镜像站自然活得久一些，同时也能够尽最大可能节省成本。--🔨（留言） 2022年4月3日 (日) 16:58 (UTC)

• 要是這樣可行,google等早就做了，何必等我們提出。--Temp3600（留言） 2022年4月4日 (一) 02:18 (UTC)

  WMF出面也不是没有可行性。一种可能合规的偷鸡办法是WMF在GFW自由港租用服务器设立缓存代理，中国大陆IP访问维基百科直接路由到这里的服务器。因为GFW自由港位于GFW之内又不受GFW管控，所以中国大陆用户应该可以自由访问维基百科。这个办法最大的问题是如何在GFW自由港租用到服务器？--百無一用是書生 (☎) 2022年4月6日 (三) 02:41 (UTC)

  “GFW自由港”是什么东西啊。@Shizhao： Stang^★ 2022年4月6日 (三) 13:48 (UTC)

  HK？--BlackShadowG（留言） 2022年4月7日 (四) 00:07 (UTC)

  Shizhao，你对大陆的理解有点脱节了吧，港澳都算是中国大陆境外的，一样要过墙的。——Sakamotosan路过围观 | 避免做作，免敬 2022年4月7日 (四) 01:00 (UTC)

  北京、上海等少数几个城市有专为外资服务的数据中心，这些数据中心不受GFW管控，不用过墙，同时又位于墙内。我一时不知道怎么说这个事，可以类比于中国大陆境内的自由贸易区，故以“GFW自由港”称之--百無一用是書生 (☎) 2022年4月7日 (四) 02:01 (UTC)

  我不认为这些自由贸易区的网络和中国互联网骨干网之间不过墙（好处就是国外企业可以直接在中国大陆落地，减少过海的通信延迟，不用像中国电信主力出口都在美国西海岸或者德国，自动增加100ms加抖得要命的抖动，对于国外CDN来说会体验改善不少），而且按照一如既往的中国政府态度，内容审核是逃不过。结果就是，如果直接放在国内网络，肯定要做内容审核；放在贸易区，除了延时和丢包抖动会大幅减少，该过墙的还是过墙，和放在香港某些非专线的服务器一样没啥区别（例如移动的出口主要在香港，算上过墙延迟也在60ms左右，基本就是国内骨干网的常态）。——Sakamotosan路过围观 | 避免做作，免敬 2022年4月7日 (四) 02:20 (UTC)

  说的是墙内节点走专线做CDN？我不认为这可能通过审批/备案和稳定运行，同时高成本。安全性也很难兼顾，似乎比较安全的CloudFlare Keyless SSL非标准化。--YFdyh000（留言） 2022年4月7日 (四) 07:55 (UTC)

  取得任何物理位置在中华人民共和国（含港澳）内的服务器之掌控权对于官老爷来说可谓轻而易举，所谓的“GFW自由港”也不会例外。--🔨（留言） 2022年4月7日 (四) 02:59 (UTC)

  就算当地政府允许，wmf本身都不会同意吧。目前wmf甚至不允许居住地在中国大陆且该信息为他人所知的用户持CU权限，以免权限遭破解；直接把服务器设在中国大陆就不怕用物理手段破解权限了么？--Antigng（留言） 2022年4月6日 (三) 14:26 (UTC)

  这个讨论总是想技术上有没问题，就没有考虑过内容有没问题。从内容而言，一堆不符合中国政府意见的内容，这足以断掉满足“合规”的想法，如果把接入服务器（无论是类似现在基金会使用的准静态缓存机制，还是现在常见的动态反向代理）放在中国大陆境内互联网的，就肯定无法通过域名或者服务器接入审批，就算打游击，被端掉是迟早的事；如果放在离中国大陆近但属于“境外”的网络，例如自由贸易区和香港等，该过墙的还是和现在的一样，除了延迟减少了，没啥区别；如果搞配合内容审查的，那就和百度百科那些不就一丘之貉？简而言之，在内容问题没解决之前，技术不是主要问题。——Sakamotosan路过围观 | 避免做作，免敬 2022年4月7日 (四) 09:06 (UTC)

  果然还是绕不开内容问题。这样我能想到的最多也就是在大陆建立一个会过滤内容，只可浏览，不可编辑的镜像站（有点类似于蜻蜓计划）。这样能让更多的大陆用户看到维基百科的一些比较优质的条目，有利于吸引更多大陆用户来主站编辑，且应该也不会让维基百科沦落成百度百科那样，毕竟真的想来编辑的还是得绕开GFW的。--BlackShadowG（留言） 2022年4月7日 (四) 12:22 (UTC)

帶括弧重定向去留

重定向的意義是讓讀者可以搜尋搜尋其他別名都可以搞到相應的條目，照此邏輯任何無連入括弧重定向都不會發揮到導航的作用。我的想法是把R8延伸到任何帶著括弧的重新導向都適用，看一下意見-某人✉ 2022年4月5日 (二) 07:31 (UTC)

1.搜索建议。2.内链目标。个人建议个例/批量存废讨论，而不是全盘处理。另外，删除这些重定向只有成本而没有收益，移动产生的重定向（例中國 (電腦遊戲)）改掉链入、速删掉，产生价值吗。--YFdyh000（留言） 2022年4月5日 (二) 08:08 (UTC)

之前可能有討論過？或可翻翻相關討論。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年4月5日 (二) 08:15 (UTC)

括號連結本身己經修得麻煩了，李鵬飛已經由主條目移至李鵬飛 (香港)，然後有同名香港演員，又移去(政治人物)，然後有同名政治人物，又要移動。在此情況下，無用的生年括號重定向是否真的沒有必要？只怕未必。猴年馬月依然顯得出他們的作用，即使像李鵬飛這樣的例子，很長時間括號重定向沒有被使用也好，但是因為預先建立而吸引了編者使用，後人移動的時候價值上就可以修少一個，所以我不太同意說沒有連入就刪掉，重定向只有利益可言。--Ghren🐦🕓 2022年4月5日 (二) 09:15 (UTC)

中正区 (台北市)→中正區 (臺北市)、雪梨 (城市)→悉尼這類重新導向刪除會導致輸入zh-cn、zh-tw等模式顯示標題無法跳轉，直接連結形成紅連結。其他無連入的重新導向我覺得沒甚麼用，刪除無妨。 紺野夢人 2022年4月5日 (二) 10:40 (UTC)

速删无链入可能导致一个问题，假设我觉得China (樂團)导言的"中国合唱团"更不错于是移动，链入（5项）被我或机器人改掉，然后China (樂團)作重定向速删、管理员看符合标准执行。不久后我或其他人觉得这样命名有问题，再移动回去、纠正内链。所以，没必要就别动这些重定向和内链。--YFdyh000（留言） 2022年4月5日 (二) 15:29 (UTC)

反对删除——还有一个理由：例如李鵬飛 (香港)被移动到李鵬飛 (政治人物)，后面有人又想建另一个叫李鵬飛的条目，如果重定向还在那么创建者可以知道该标题有歧义从而换一个标题写。同理，仍然有歧义的条目名称应重定向到消歧义页，以免被人误建成条目。--GZWDer（留言） 2022年4月5日 (二) 17:09 (UTC)

可能会导致繁简转换的问题，比如传染病 (电影)→全境擴散，如果删除该重定向，大陆用户就难以找到条目。--BlackShadowG（留言） 2022年4月6日 (三) 00:09 (UTC)

这种不少，最近刚建立的异形大战铁血战士 (游戏)，如果删去可能某些语言区的用户会搜索不到条目。另外还有作者笔名、表字问题。--Kethyga（留言） 2022年4月6日 (三) 08:51 (UTC)

引入A7速刪

現行條文 (無)

提議條文 A7. 明顯不會有關注度的事物 適用於任何真實存在，但根據常理明顯不可能達到關注度準則的事物。如果此主題不是非常明顯地不符合關注度應該轉交存廢討論或走30天關注度流程。

現在經常有些明顯沒有關注度的的事物立條目，例如訂閱數一百幾十的youtube channel，而這些又不一定可以套用G11 (這些情況被管理員駁回也不在少數)，所以建議引入英維這條速刪準則以處理這個不足-某人✉ 2022年4月6日 (三) 07:13 (UTC)

A7以前是有實行過（即WP:CSD#A4），但是已經被廢除。「常理明顯不可能」在以往的經驗裏經常容易引起爭議，所以才被廢除並改為現在的一律轉交存廢討論。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年4月6日 (三) 08:15 (UTC)

要不廢除關注度三十天提刪流程，覺得沒關注度直接提刪算了。--中文維基百科20021024（留言） 2022年4月6日 (三) 08:42 (UTC)

(－)反对並(！)強烈抗议廢除關注度30天流程。上次「Wikipedia_talk:关注度/存档11#关注度程序30日过长。」就引起強烈社群反彈。光是縮短30天流程就引起那麼大的七萬字社群反彈。抗議。你們故意移除30天流程等於是「惡意讓編者沒有時間尋找線下來源」這也是上次討論的結論之一或觀點之一。「條目裡面沒有來源不是刪除條目的理由，努力找找不到才是」（這句antigng說的，出處，請遵守方針），我也強烈抗議「0奈秒瞬間秒刪」、「秒刪」的行為，我無論如何都要認為這種行為極端惡意，惡意至極，維基百科又沒有最後期限，你們在趕什麼？趕火車？趕飛機？留意一下前次討論的一些觀點：「為甚麼要急於刪去條目呢？用戶也要有足夠時間改善條目，而且來源不只限於線上，線下來源需要更多時間去尋找，一兩個星期沒能抽空到圖書館，就要刪去條目嗎？何必急於刪去條目呢？；有些新手寫了條目後，要多花時間去找來源，我們要給予足夠時間讓新手有足夠時間去改善條目，急於提刪條目會嚇怕新手；巡查條目不能只看線上來源，對於已存在於條目的線下來源，巡查員也要花時間到圖書館驗證，這都需要足夠的時間；google 自己也說他們不會把所有來源都呈現在搜尋器中，而且涉及版權問題，有很多來源都不會放在線上，線上來源始終有限，大部分來源都存在於線下，我們須給予用戶足夠時間尋找線下來源；明顯不符合關注度的可以雪球提刪，何必急於刪去可能符合關注度要求的條目呢？；在沒有給多足夠改善時間，就急於提刪條目，是很容易引起爭議的；方針訂明刪除應是最後手段」，維基對於提刪及刪除條目都傾向審慎的，在提刪前，應給予足夠的改善時間。」基本(！)抗议未給緩衝就提刪的行為！這是惡意行為！！—- [雪菲蛋糕] >梓< [娜娜奇鮮果茶]（留言·簽到） 2022年4月6日 (三) 09:21 (UTC)

想再來一次七萬字？我可以ping來當時所有人！！—- [雪菲蛋糕] >梓< [娜娜奇鮮果茶]（留言·簽到） 2022年4月6日 (三) 09:46 (UTC)

@A2569875，我們都很清楚您的意思，也請您避免「大喊大叫」。--🎋竹生🎍 2022年4月6日 (三) 11:18 (UTC)

(：)回應我把部分文字弄灰了，有看起來比較「小聲」一點嗎？-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年4月6日 (三) 11:21 (UTC)

• 而且你們可以留意一下我下方的留言#A2569875 2022年4月6日 (三) 09:30 (UTC)，我並非為反對而反對，我有明指「不要一刀切」，不要全部不分青紅皂白地「瞬間現在立刻馬上提刪」，「符合WP:雪球」本應當可刪，其餘的緩個幾天何嘗不可？維基百科不應強迫編者，你們至少也給編者合理的空間和時間嘛，好不好。-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年4月6日 (三) 11:29 (UTC)

• (＋)支持即便如此，我也支持明顯WP:雪球的提刪。—- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年4月6日 (三) 09:30 (UTC)

鉴于执行标准不统一、“常理”标准含糊，这种还是得提存废，期间有可能被改进扩充，而不是直接被删。大量出现有G11/G3/“批量提删”讨论可用。--YFdyh000（留言） 2022年4月6日 (三) 15:28 (UTC)

(＋)支持，提删和速删之间目前是存在一些可以填补的空间。有些新建条目整个页面只有用于避开A1的寥寥几句话，且明显无法满足关注度要求，可是缺乏严格对应的速删选项。还有类似来自某某中学的学生个人传记这种...几乎每个月都能看见好几个，要说G3也未必，人家自己写的还很上头，当真是找不到完全满足的速删选项。这些条目所有人都知道明显是留不下来的，但最后全都只能走一遍关注度或者提删流程，所以A7的加入能够很好的处理这类情况。当然A7容易给人一种泛用速删选项的感觉，可能会增加管理员把关的工作量，不过我个人认为是利大于弊的。--南冥大鹏👈把我批判一番出偏差要负责👊微小的工作历史的进程✌ 2022年4月6日 (三) 22:02 (UTC)

(－)反对，应该参考之前速删A4的问题。——Sakamotosan路过围观 | 避免做作，免敬 2022年4月7日 (四) 00:58 (UTC)

(－)反对：走個存廢討論有這麼難嗎？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年4月7日 (四) 02:44 (UTC)

你说的存废讨论是不是那种，一个“雪球关注度”为理由，一堆支持删除的附和意见的那种；那有什么显著区别。 Stang^★ 2022年4月7日 (四) 03:24 (UTC)

区别是挂7天，想拯救条目的人有时间搜集和改写，而不是任一管理员附和一下就删掉内容，其他人还得及时发现、考虑查询、存废复核。--YFdyh000（留言） 2022年4月7日 (四) 07:58 (UTC)

区别是至少有其他人看過是不是真沒救了。--Temp3600（留言） 2022年4月7日 (四) 09:52 (UTC)

上面有提到“提删和速删之间目前是存在一些可以填补的空间”，这个空间可以考虑引入英文站的提议删除机制，即“不开讨论，只挂模板，若干日无人反对即删；如反对再转xfd”来填补，而不是将明显浪费xfd资源的讨论直接下放到快速删除。--Antigng（留言） 2022年4月7日 (四) 04:27 (UTC)

不過有的頁面瀏覽量並不高，即使被人看到了也有可能是純讀者，不知道如何反對，此時刪除與否似乎就取決於瀏覽量了。--中文維基百科20021024（留言） 2022年4月7日 (四) 04:54 (UTC)

現在侵權和部份圖片快速刪除的機制事實上來說是一種提議刪除的機制，不是說不行，但是一樣都會有持續7天的時間，這似乎和提案者初衷不同。Ghren🐦🕐 2022年4月7日 (四) 05:00 (UTC)