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

互助客棧： 消息  方針  技術  求助  條目探討  其他 |  知識問答

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

公告欄

• [人事] Manchiu、UjuiUjuMandan、ASid、ATannedBurger獲提名為管理員，AT獲提名為監督員，歡迎踴躍參與提問和討論。
• [公告] 現時已改為只有延伸確認用戶可以使用內容翻譯將頁面釋出到主條目空間，如有疑問及意見，歡迎參與相關討論。
• [公告] 回饋請求系統正在試運作中，誠邀使用者訂閱以接收討論通知。使用者訂閱有興趣參與的討論議題後，機器人會自動在新討論發起時隨機抽取部分使用者發訊息通知。
• [公告] 修訂維基百科不是維基物種及IP封禁豁免權授予者的頂部圖標已經通過。
• [公告] 規範討論發起步驟正在公示，如有意見請儘快提出。
• [討論] 互助客棧方針區正在討論電視條目播放資訊增加收錄準則及再擬議立國際關係命名常規為方針，請踴躍參與討論。
• [討論] 互助客棧技術區正在討論ToolsRedirect建立的繁簡重新導向問題，請踴躍參與討論。
• [討論] 互助客棧其他區正在討論對新聞動態獲選標準及ITNR規則的小修訂及頁面評級與通用評級行政層面上的統合方案，請踴躍參與討論。
• [廣告] 第二十二次動員令現正徵求主題及決定舉辦時間。另主持人選舉時程及規則公示至5月14日止，歡迎踴躍參與！

• [協作] 現有125個頁面需維基化，271個條目需清理，20個移動請求正在討論。
• [獎勵] 現有1名使用者獲提名維基獎勵，歡迎投票。

#	💭 話題	💬	👥	🙋 最新發言	🕒 (UTC+8)
1	提議提高條目評選投票資格門檻	87	23	Temp3600	2024-05-06 01:45
2	再擬議立國際關係命名常規為方針	48	10	Ghren	2024-05-12 15:52
3	修訂刪除方針明確允許刪除沒有來源30日以上的條目	54	9	August0422	2024-05-09 18:22
4	提議英維指引en: MOS:TVINTL經本地化後引入中維維基百科:格式手冊/電視	73	8	HK5201314	2024-05-11 08:47
5	提議：允許使用開放代理編輯WP:RFR，並在WP:RFR中加入「註冊賬號申請」	2	2	YFdyh000	2024-05-06 09:43
6	提議：對WP:日常計算做小修改	1	1	自由雨日	2024-05-08 16:30
7	管理員就職宣誓	6	6	暁月凜奈	2024-05-09 22:44
8	提議對中國大陸的文物保護單位設立關注度豁免	22	10	YFdyh000	2024-05-12 15:16
9	附帶有限追蹤檢查的無IP的IPBE	11	6	Manchiu	2024-05-12 19:52

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

正在廣泛徵求意見的議題

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

維基百科格式與命名

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

可能需要進一步討論以便獲得共識。--Kethyga（留言） 2024年4月24日 (三) 05:15 (UTC)

維基百科方針與指引

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

此討論正在公示7天，直至2024年5月18日 (六) 02:45 (UTC)結束；如有意見請儘快提出。

推行RFC後，我發現很多人沒理會非強制性的提示，導致WP:VPD持續過長。我提議調整方針，明確共識建立的遞進步驟，確保各討論頁獲得善用。--路西法人 2024年4月8日 (一) 09:58 (UTC)

維基百科提議

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

接續上段，繼續提請討論仲裁委員會的執行細節。目前討論中的範疇包括：

• 授予權限：向仲裁委員會授予什麼權限？
• 權限限制：如何限制仲裁員在委員會職務以外使用權限？
• 選舉信任度下限：目前以50%為最低可當選門檻，是否有需要調高？
• 管理人員解任處理：管理人員解任在多大程度由仲裁委員會處理？
• 其他準備工作：包含相關頁面籌備與部署、技術問題及其他需要處理之事項。

--路西法人 2024年2月16日 (五) 02:13 (UTC)

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

近年有些公共轉換組越來越大，導致所嵌入的各條目等頁面_{（爲便説明下稱「條目」但不限於條目）}載入越來越慢，爲人詬病。而若條目預先儲存公共轉換組中與條目中字詞相匹配的轉換規則，並適時更新：— Gohan 2024年3月12日 (二) 05:00 (UTC)

Template talk:Twitter § Twitter改為X

因應Twitter已改名X一段時間了，因此提請討論是否做相應更改。臺灣杉在此發言 (會客室) 2024年4月18日 (四) 04:10 (UTC)

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

此前的相關討論：

• 建議修改新聞動態發表程序
• 建立ITN獲選標準門檻

---

最近Wikipedia:新聞動態候選出了一些問題：

第一，在社群討論沒有得出支持刊登的情況，管理員自行刊登內容，如Wikipedia:新聞動態候選/存檔/2024年3月#亞倫·布什內爾自焚事件；

第二，部分內容在刊登之前沒有收到反對意見，刊出之後被質疑關注度或重大性不夠，如Wikipedia:新聞動態候選/存檔/2024年4月#習馬二會；

第三，涉及中國載人航天工程的條目近期在提名時多被社群以不具備突破性為由反對，見Wikipedia:新聞動態候選/存檔/2022年6月#神舟十四號、Wikipedia:新聞動態候選/存檔/2023年6月#神舟十六號、Wikipedia:新聞動態候選/存檔/2023年10月#神舟十七號和Wikipedia:新聞動態候選#神舟十八號。

針對以上的第一條及第二條問題，提案對現行的ITN獲選標準作出如下修訂：

現行條文 管理員在每次更新欄目時，應當查看新聞動態候選區內所有提案。管理員認為提案符合新聞動態候選標準的，應予採納；不符合候選標準的，應由管理員陳述意見後退回重審。有二名及以上維基人提出反對意見的，亦應當退回重審。

提議條文 管理員在每次更新欄目時，應當查看新聞動態候選區內所有提案。管理員認為提案符合新聞動態候選標準，或支持刊登的意見占大多數的，應予採納；不符合候選標準的，應由管理員陳述意見後退回重審。有二名及以上維基人提出反對意見的，亦應當退回重審。 對於刊登之後出現反對意見提案，管理員應暫時移除相關內容，直至社群得到支持刊登的共識。對於沒有得到絕對結論的提案，需要有二名及以上的管理員進行商討，以最終決定是否刊登。 提案新聞內容涉及需要地區詞轉換的用字，提案人需要先自行處理。

針對以上的第三條問題，提案對現行的WP:ITNR作出如下修訂：

現行條文 載人軌道航天器的發射升空；一個國家首次成功完成自主發展的軌道發射；發射空間站或其主要組成部分；航天器抵達月球或更遠的目的地；重大航天任務失敗

提議條文 每款載人軌道航天器首次發射升空；每款載人軌道航天器與特定空間站首次成功對接；一個國家首次成功完成自主發展的軌道發射；發射空間站或其主要組成部分；航天器抵達月球或更遠的目的地；重大航天任務失敗

---

正如WP:NOTNEWS所說，維基百科不是新聞報道。新聞動態候選和Portal:新聞動態設立的初衷也不是為了提供新聞報道，「是為了鼓勵增訂或更新相關的條目，而不是用作新聞報道」。由此可見，社群應該從百科性的角度來提報及衡量新聞動態條目，一些不具備百科性的條目能不提報就不提報，能不刊登就儘量不刊登，畢竟「維基百科不是新聞報道」。所以，新聞動態的標準也儘量嚴謹。上述的修改意見只不過是拋磚引玉，歡迎社群在此提案的基礎上踴躍討論。--Jeffchu2014（留言） 2024年4月28日 (日) 17:08 (UTC)

Template talk:Hang on § {{hangon}}

Template:Db-meta的格式在之前的討論中，無法解決標記提速刪頁面上的速刪狀態；如果用機器人的方式來處理，是否可行？臺灣杉在此發言 (會客室) 2024年4月30日 (二) 08:33 (UTC)

配置表單來方便用戶發郵件申請賬戶或申請IPBE權限

目前一個用戶如果在自己的IP被封禁的情況下希望註冊賬戶，或是第一次申請IPBE權限，其需依照本指引中的要求需要發送郵件至unblock-zhlists.wikimedia.org來申請。目前可以想象的已知問題包括：申請人遺漏了部分信息、申請人發的郵件未遵照模板難以閱讀、管管無法驗證用戶對應的IP地址是否真的被封禁了。為解決這些問題，在此提議在本站安裝ContactPage這一擴展，並書寫對應的配置文件來定義表單。

這一擴展可以根據配置文件生成表單，其中包括若干必填或選填項，且註冊用戶和匿名用戶均可使用。當提交表單時，擴展會將表單中填寫的信息（甚至可以附帶上填寫人當時的IP地址）以一定的格式發送給某個用戶（在本站就可以發給User:Unblock-zh）。比較不好的地方是表單的欄目需要手寫配置文件（參考元維基的配置），但也算是一勞永逸。樣例可以看這個位於元維基的表單。本擴展已於元維基、Governance Wiki和荷蘭語維基百科安裝，因此個人認為安裝應該不成問題。希望獲得社群共識。 -- Stang^★ 2022年7月16日 (六) 17:15 (UTC)

沒有意見。未見說明，但該表單似乎不受IPBE影響。關於填入IP地址，建議為可選而非隱含，以利隱私選擇權。--YFdyh000（留言） 2022年7月16日 (六) 18:25 (UTC)

那啥，兩個問題：

1. IP被封禁能提交得了這個表單麼？
2. 這個擴展有啥防濫用機制麼？會不會被利用來大量發送spam？--百無一用是書生 (☎) 2022年7月18日 (一) 02:22 (UTC)

這個擴展本質是Special:EmailUser套皮。如果使用者被禁止發送郵件，那麼他們就用不了這個頁面；頁面的使用也受到郵件相關的速率控制。--MilkyDefer 2022年7月18日 (一) 14:29 (UTC)

尷尬，如果被封了是不能發郵件的；有一個可選的captcha。鑑於本提案無法實現，撤回。 Stang^★ 2022年7月18日 (一) 14:55 (UTC)

@Stang：奇怪的是，我在meta上用被封禁的IP（編輯頁面，提示已封禁），可以用這個表單啊。之前嘗試好像沒見到驗證碼，這次嘗試見到驗證碼。"Your account or IP address has been blocked."、"Email sent"。--YFdyh000（留言） 2022年7月19日 (二) 03:48 (UTC)

我強調一遍，是被撤除了郵件權力的人不能用。Stang作為前行政員在封人的時候不可能沒見過「不能發送電子郵件」的選項吧？除非封鎖一個IP用戶，會導致受其影響的無賬號人員不能發出請求代為創建賬號的表單。--MilkyDefer 2022年7月19日 (二) 06:44 (UTC)

很奇怪的是我昨天用了某個不能編輯頁面的IP在匿名情況下發現是無法使用這一功能的，但是剛剛我嘗試復現的時候似乎又沒法重新復現…？話說回來，這個擴展是用$user->isBlockedFromEmailuser()來判斷的，那如果封一個匿名用戶會幹掉sendemail這個權限麼，如果沒有的話那還有繼續討論的餘地。 Stang^★ 2022年7月19日 (二) 11:28 (UTC)

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

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

從未對匿名用戶執行過禁止發送電子郵件的設置，因此完全不了解這一點。 Stang^★ 2022年7月24日 (日) 13:06 (UTC)

似乎沒有明確的反對意見，故公示7天。 Stang^★ 2022年7月31日 (日) 17:46 (UTC)

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

可以同時或者之後討論，我認為把要不要做和怎麼做分開是合理的。 Stang^★ 2022年8月1日 (一) 08:11 (UTC)

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

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

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

非常不好意思摸了這麼久。對於表單內容，咱個人的意見是這樣的：如果可能，應設計兩個表單，分別針對未註冊用戶（用於申請賬戶）和註冊用戶申請IPBE權限；對於未註冊用戶，其應包括「當前使用的IP地址」、「封禁ID」（可選）、「申請註冊的理由」、「意向用戶名」；面向註冊用戶的表單基本類似，只是沒有「用戶名」這一個欄目；表單不記錄用戶的IP地址。這個想法可能不是很完善，自動封禁就不是很適用於這種情況，暫時沒想好怎麼做。（或者一個下拉選框讓申請人選自己是原電子郵件發送指引中5種情況的哪一種？ Stang^★ 2022年9月5日 (一) 05:29 (UTC)

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

咱希望了解目前收到的郵件之中可以按照指引給出的模板正確填寫的比例，這樣判斷一下「填錯ID等欄目」等等情況屬於少數還是占了不小的比例。感謝您可以投入去開發郵件輔助生成小工具（就跟 relgen.js 差不多的那種麼）。 Stang^★ 2022年9月12日 (一) 04:16 (UTC)

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

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

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

感謝提供以上信息，我支持使用純文本的表單，此表單允許匿名用戶進行填寫，不在發送的郵件中包括填寫者的IP地址。 Stang^★ 2022年9月13日 (二) 20:46 (UTC)

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

實裝了一下，我所說的「填寫者的IP」是指'IncludeIP' => true,這一特性可以把使用者的IP地址包含在主題中。如果啟用了的話，對於匿名用戶而言，郵件主題將形如「聯絡訊息 (由[表單內填寫的名稱]在[IP地址])」；如果沒有啟用，主題將形如「聯絡訊息（自[表單內填寫的名稱]）」。已登錄的用戶會有一個多選框決定是否「在此訊息中引用我的 IP 位址。」，如果勾選了，IP地址也將類似於匿名用戶一樣，顯示在主題一欄中。 Stang^★ 2022年9月18日 (日) 22:34 (UTC)

暫擬的配置，非常簡單：

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

acc代指賬戶請求，不過可以後期再議；默認主題應在MediaWiki:Contactpage-subject-acc這個頁面自定義；「SenderName」暫時這麼想，待議。 Stang^★ 2022年9月18日 (日) 22:34 (UTC)

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

上面咱的提議是*不要*加 IncludeIP 啊。個人覺得這個可能會與privacy policy相牴觸，以及IP數據這種東西可能會涉及到NDA的問題。 Stang^★ 2022年9月21日 (三) 06:16 (UTC)

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

感謝快速的回應。blame了一下存在一個站點啟用了包含IP地址這一功能，猜測要求這麼做應當不會被拒絕。加了。 Stang^★ 2022年9月21日 (三) 06:24 (UTC)

簡單 公示7日，2022年10月4日 (二) 22:06 (UTC) 結束。配置改完之後建議修改目前的操作手冊，並建議申請者通過表單提交請求。 Stang^★ 2022年9月27日 (二) 22:06 (UTC)

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

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

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

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

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

Xiplus上面說了在開發一個（類似於這樣）的的。 Stang^★ 2022年10月9日 (日) 22:09 (UTC)

歪個樓問一下，目前申請IPBE是否需要提供IP地址？至少在Wikipedia:權限申請/申請IP封鎖豁免權/存檔/2021年中有大量用戶未提供IP地址。--Steven Sun（留言） 2022年10月1日 (六) 13:18 (UTC)

似乎是逐漸有了這樣的趨勢？之前給IPBE相對於現在寬鬆很多，當然也有了一些沒有妥善備案的例子，目前給一下感覺可以理解。 Stang^★ 2022年10月9日 (日) 22:09 (UTC)

感覺社群方面似乎沒有太大的問題，為了以防萬一咱會給legal發郵件詢問一下可不可以這麼做。這個串應該可以存檔了。 Stang^★ 2022年10月9日 (日) 22:09 (UTC)

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

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

---

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

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

@SCP-2000：所以大約還要多久？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年11月7日 (一) 15:18 (UTC)

@Ericliu1912： 不清楚，個人預計至少一個月以上。另外，其實是 Stang 君詢問法律部門，往後如有關於法律部門回覆的疑問，詢問他為宜。謝謝。--SCP-0000（留言） 2022年11月7日 (一) 16:41 (UTC)

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

可靠來源方針增加用戶生成內容

Wikipedia:可靠來源:

現行條文 BBS和新聞組的帖子、Wiki的內容或者Blog上的留言都絕不能成為可接受的一次或者二次來源。這是因為我們無法知道它們究竟是誰寫的。對於Wiki的情形，文章的內容可能在任何時刻發生變化，而且沒有編輯人員監管或者第三方核查事實。

提議條文 由於缺乏事實查核以及普遍有效的帳戶認證，用戶生成內容通常是不可靠的。因為這些內容可能在任何時刻發生變化，而且沒有編輯人員監管或者第三方進行事實查核。個人網站、博客、網絡論壇、社交媒體、粉絲網站、視頻分享網站、網絡相冊、Wiki通常都含有用戶生成內容。 在部分社交媒體中會有帳戶認證，以表明某個社交媒體賬戶由真實個人或組織擁有並運營。在這種情況下，該賬號的可靠性可能繼承自這個人或組織本身的可靠性。

Wikipedia:可供查證：

現行條文 任何人均可自創網站或自費出書，並藉此聲稱自己是某領域的專家。因而，絕大多數個人出版之書籍、業務通訊、個人網站、開放性wiki、博客、論壇貼文及類似來源均不得被認可為可靠來源。。

提議條文 任何人均可在網絡上發表言論或自費出書，並藉此聲稱自己是某領域的專家。因而，絕大多數個人出版之書籍、業務通訊、個人網站、開放性wiki、博客、論壇貼文、社交媒體及類似來源均不得被認可為可靠來源。

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

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

  來源可靠性與賬號是否認證，可能並無絕對關聯。重點是內容是否被監督審查。--YFdyh000（留言） 2022年8月13日 (六) 22:08 (UTC)

  根據先前討論，似乎只有YouTube和Facebook存在大量因訂閱數不足而無法認證的問題。我覺得應該在WP:RSP單獨說明YouTube這種特殊情況，而不是在可靠來源方針中列出。畢竟該提議的條文為：用戶生成內容通常是不可靠的。並沒有禁止所有用戶生成內容。--Steven Sun（留言） 2022年8月14日 (日) 00:16 (UTC)

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

  中國大陸的社交平台也有類似的問題（例如某些官方認證的賬號用是個人名義註冊）--我永遠喜歡搭檔對戰 2022年8月14日 (日) 07:49 (UTC)

「該賬號的可靠性繼承自這個人或組織本身的可靠性」建議改為「該賬號的可靠性可能繼承這個人或組織本身的可靠性」，有時某些斷言會出現疑慮。其他方面基本支持，雖然修改後可能讀者必須理解「用戶生成內容」的準確意義。--YFdyh000（留言） 2022年8月13日 (六) 22:03 (UTC)

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

(※)注意：提議條文並沒有完全禁止使用用戶生成內容。允許給特殊情況留出討論空間。相反的是，現有條文認為：BBS等...「都絕不能成為可接受的一次或者二次來源」--Steven Sun（留言） 2022年8月14日 (日) 08:13 (UTC)

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

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

「由於缺乏事實查核以及普遍有效的帳戶認證，用戶生成內容通常是不可靠的。因為這些內容可能在任何時刻發生變化，而且沒有編輯人員監管或者第三方進行事實查核。個人網站、博客、網絡論壇、社交媒體、粉絲網站、視頻分享網站、網絡相冊、wiki通常都含有用戶生成內容。

在部分社交媒體中會有帳戶認證，.....（後略）」個人意見，供參。--Kriz Ju（留言） 2022年8月18日 (四) 23:16 (UTC)

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

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

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

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

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

我存在異議，並不是因為「普遍有效的帳戶認證」才導致「用戶生成內容通常是不可靠的」，這個因果關係並不必然，我看到User:YFdyh000也有提到這一點，結果提案還是在斷言這一點。存在用戶認證應該是直接可供查證，然後才是可能繼承可靠性，這一點下文也有提及，因此刪除首段「普遍有效的帳戶認證」文字對提案具體內容沒有太大影響。----Cat on the Mars 2022年8月30日 (二) 09:56 (UTC)

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

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

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

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

關於WP:SPS的問題，目前條文中的「開放性wiki、博客、論壇貼文」已超出了「自創網站」的範疇。使用「網絡上發表言論」更符合「開放性wiki、博客、論壇貼文」的內容性質。--Steven Sun（留言） 2022年9月1日 (四) 14:15 (UTC)

依上方意見暫停公示。另外我也覺得應該刪除首段的「普遍有效的帳戶認證」。--Steven Sun（留言） 2022年8月30日 (二) 12:23 (UTC)

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

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

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

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

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

Wikipedia:可靠來源:

現行條文 BBS和新聞組的帖子、Wiki的內容或者Blog上的留言都絕不能成為可接受的一次或者二次來源。這是因為我們無法知道它們究竟是誰寫的。對於Wiki的情形，文章的內容可能在任何時刻發生變化，而且沒有編輯人員監管或者第三方核查事實。

提議條文 個人網站、博客、網絡論壇、社交媒體、粉絲網站、影片分享網站、網絡相冊、Wiki的內容或者Blog上的留言都絕不能成為可接受的一次或者二次來源。這是因為我們無法知道它們究竟是誰寫的。對於Wiki的情形，文章的內容可能在任何時刻發生變化，而且沒有編輯人員監管或者第三方核查事實。通常都含有用戶生成內容。 在部分社交媒體中會有帳戶認證，以表明某個社交媒體賬戶由真實個人或組織擁有並運營。在這種情況下，該賬號的可靠性可能繼承自這個人或組織本身的可靠性。

Wikipedia:可供查證：

現行條文 任何人均可或自費出書，並藉此聲稱自己是某領域的專家。因而，絕大多數個人出版之書籍、業務通訊、個人網站、開放性wiki、博客、論壇貼文及類似來源均不得被認可為可靠來源。。

提議條文 任何人均可自創網站、社群專頁或自費出書，並藉此聲稱自己是某領域的專家。因而，絕大多數個人出版之書籍、業務通訊、個人網站、開放性wiki、博客、論壇貼文、社交媒體及類似來源均不得被認可為可靠來源。

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

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

現單獨對Wikipedia:可供查證進行修訂：

現行條文 任何人均可自創網站或自費出書，並藉此聲稱自己是某領域的專家。因而，絕大多數個人出版之書籍、業務通訊、個人網站、開放性wiki、博客、論壇貼文及類似來源均不得被認可為可靠來源。。

提議條文 任何人均可自費出書，或者在開放性平台中貢獻內容。因而，絕大多數個人出版之書籍、業務通訊、個人網站、開放性Wiki、博客、用戶生成內容及類似來源一般不被認可為可靠來源。

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

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

「用戶生成內容」和「個人出版物」區別蠻大的。網絡上的用戶生成內容，有身份確定和內容固定兩大難題，所以不易做到可供查證。個人出版物則是內容正確性、利益相關、版本存續等問題。--YFdyh000（留言） 2022年9月5日 (一) 06:53 (UTC)

UGC的問題顯然比SPS要大，後者只有一個可靠性問題，前者可靠性和可供查證都不穩定，認證用戶有失水準也不是一天兩天的事情，即便是認證用戶在UGC鮮有評審的背景下也有自說自話、靠粉絲「自圓其說」的時候（很多時候出事就賴實習生）。我覺得承接前兩個討論，大多數人支持的論點應該是機構或媒體認證賬號相對可信，還不至於現在把所有認證賬號都包括進來，比方說我前面講的個人認證賬號的問題，至少在我看來這不是可靠來源，最多只能用作觀點。

附：翻譯一下ENWP的UGC政策以供參考。

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

有些網站的內容大多由用戶生成，這些內容一般不是可接受的來源。這類網站涵蓋個人網站、個人或集體博客（報刊雜誌的博客除外（這裡指代專欄博客））、內容農場、社交媒體、粉絲網站、音像或圖片託管服務（共享網站？）、多數wiki以及其他集體協作創作內容的網站。

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

其中比較典型的有臉書、微博、Fandom、IMDb、Instagram、Reddit、抖音、推特和維基百科（自我引用），上述內容一般不是可接受的來源。（有刪改）

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

In particular, a wikilink is not a reliable source.

儘管一些評論匯總網站（譬如爛番茄）在總結專家意見時或許可靠，但除此之外其基於用戶評價的評分並不可靠。特別要強調的是，維基百科不是可靠來源。

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

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

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

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

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

現行條文 在部分社交媒體中會有帳戶認證，以表明某個社交媒體賬戶由真實個人或組織擁有並運營。在這種情況下，該賬號的可靠性可能繼承自這個人或組織本身的可靠性。

提議條文 部分社交平台帳號可以透過包括但不限於平台的帳戶認證或其他方式來證明某社交媒體賬戶代表現實中的特定個人或組織。在這種情況下，這些賬號所發表內容的可靠性一般可被視作等同於這個人或組織在其他場合所發表的內容。但要注意這些經證明能代表特定人物的社交平台帳號可能由經委託予他人所操作，因此未必能用於證實特定發言出自帳號持有者。

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

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

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

提案裁撤案內多餘章節

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

同意。此外我覺得Wikipedia:可靠來源#作者自行發表的材料也應一併廢除。還有Wikipedia:可靠來源#在關於作者自己的條目中採用他們自行發表的來源也有點多餘，似乎可以合併至Wikipedia:利益衝突中。--Steven Sun（留言） 2022年9月1日 (四) 13:57 (UTC)

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

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

提議條文 任何人都可以建立網頁、自行出版、或自稱專家，自行發表的來源往往未經任何事實核查，缺乏獨立第三方評審，因此絕大多數個人出版物、個人網站、博客、開放性wiki、網絡論壇或社交媒體上的貼文以及其它類似來源通常不是可接受的來源。 不過也有一些特例，例如一些新聞媒體會以博客指代其網絡專欄，如果專欄作者為專業人士其內容可能相對可靠；此外，如果某些內容專家已經在獨立、可靠的出版機構發表過相關專業領域的個人作品，並且受到社會的普遍認可，那麼其在相關專業領域的自行發表的內容也可能相對可靠。 編者仍需謹慎使用這類來源：一方面專欄的內容可能涉及作者個人觀點，新聞媒體對專欄的事實核查也可能相對寬鬆，應該辨析專欄文章中的觀點與事實，避免將作者的觀點作為事實引用；另一方面，如果專家自行發表的內容值得發表，那麼可能已經有人做了相同的工作，存在獨立第三方驗證的可靠來源可以替代。 個人出版物不能作為有關在世人物的獨立第三方來源，即便其作者是著名的職業調查員或作家。

說明

1. 第一句和第二句合併，前面半句為原因，「業務通訊」不知所指何物，因此刪除歸類到類似來源，同時原文「為了滿足虛榮心所發行的刊物」確係「自費出版商」英語Vanity Presses的誤譯，按ENWP似乎自費出版和自行出版在英美屬於平行關係；

2. 「特例」同時參照en:WP:NEWSBLOG和en:WP:SPS以及現有內容進行修改，前一段中文中沒有WP:NEWSBLOG，後一段WP:SPS也已經存在相似論述。（@YFdyh000、HTinC23：WP:V原文如下「但在某些情形下，個人出版物亦仍可以被接受。例如，出版人為受到肯定的專家，從事與條目主題相關領域的工作，並曾在可靠的第三方出版物中發表過該領域工作的文章。但是，此類來源的使用需要謹慎，並且如果有關信息的確值得記載，很可能已有他人做了相同的工作。」）

3. 最後一句補充自ENWP，en:WP:RS中稱作「independent sources」，en:WP:V中稱作「third-party sources」，統一為「獨立第三方來源」。

WP:GUNREL是什麼的縮寫（Generally Unreliable?），我不清楚其是否對應ENWP的en:WP:RS/SPS，目前儘量保持兩段SPS概述一致。最後想問一句是否存在共識刪除WP:評估可靠性，將其歸納到WP:RS前面的「評估來源」一段，因為這應該也是先後翻譯時間不同導致的同一段落重複問題，並且已有編者（@MilkyDefer：）指出這一段翻譯水準不高。

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

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

@CatOnMars：

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

原文是established，這個詞比較重，韋氏解釋是「 accepted and recognized or followed by many people」，綜合上下文應該是指已經獲得媒體或學術引用，或者有專業人士充分肯定。----Cat on the Mars 2022年10月3日 (一) 09:11 (UTC)

公示案其一

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

不過也有一些特例，例如一些新聞媒體會以博客指代其網絡專欄，如果專欄作者為專業人士其內容可能相對可靠；此外，如果某些內容專家已經在獨立、可靠的出版機構發表過相關專業領域的個人作品，並且受到社會的普遍認可，那麼其在相關專業領域的自行發表的內容也可能相對可靠。

編者仍需謹慎使用這類來源：一方面專欄的內容可能涉及作者個人觀點，新聞媒體對專欄的事實核查也可能相對寬鬆，應該辨析專欄文章中的觀點與事實，避免將作者的觀點作為事實引用；另一方面，如果專家自行發表的內容值得發表，那麼可能已經有人做了相同的工作，存在獨立第三方驗證的可靠來源可以替代。

個人出版物不能作為有關在世人物的獨立第三方來源，即便其作者是著名的職業調查員或作家。

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

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

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

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

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

@Longway22：

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

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

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

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

技術探討

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

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

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

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

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

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

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

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

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

比方說：

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

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

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

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

別改cite，單獨建立一個標識模板就可以。目前來說，建立流程共識也許比過濾器等技術手段更優先。--YFdyh000（留言） 2022年10月11日 (二) 16:27 (UTC)

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

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

是要單弄一套cite？我覺得弄個標識模板指向討論/狀態說明頁就好，放在ref標籤內或外，cite保持原樣。命名都可以，像是{{Verified UGC}}或{{checked UGC}}。--YFdyh000（留言） 2022年10月11日 (二) 16:37 (UTC)

新建布告板的目的是？Wikipedia:可靠來源/布告板或其子板塊會否更好。我不理解並且認為「擔保資格」效力欠缺共識，雖然設法提供/列明可能是有益的。--YFdyh000（留言） 2022年10月7日 (五) 13:13 (UTC)

意見商討

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

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

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

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

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

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

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

.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

.

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

.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(＆)建議 「、或自稱專家」。以及我想確認，「個人出版物」是由個別人完成出版主要流程（如撰稿、編審）的出版物，語出個人（如採訪、自述）但經歷可靠流程的出版物不是個人出版物，應以其他角度衡量可靠性。個人或小團體編撰後交由正式出版社發行的書籍，可能需個案辨別可靠性。「個人出版物不能作為有關在世人物的獨立第三方來源」該如何理解？仍可能是觀點的可靠來源，但不應是事實查核的可靠來源。--YFdyh000（留言） 2022年10月4日 (二) 13:24 (UTC)

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

@Longway22：

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

.

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

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

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

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

.

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

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

.

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

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

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

(！)意見，我最近沒有空參與討論了，所以就三件事表達一下觀點：第一點，回答U:YFdyh000的問題，首先個人出版物是專有名詞，實際上專業出版社也有可能承接自費出版業務，主要差異還是在於編輯審核的流程；第二點，還是U:YFdyh000有關生者傳記的問題，WP:生者傳記已經規定不論批評還是讚美的觀點都需要出自可靠來源，個人出版物的觀點無論如何都不是生者傳記觀點的可靠來源，這是方針一致性要求；第三點，即便放在現有的方針里，存在更好來源或者可替代也不是刪除已有相對可靠來源的理據，新的提案也沒有強制在存在可替代來源的時候一定要使用更好來源，如果編者認為存在更好來源，應該自己舉證並替代，原則上條目大部分內容應該是由可靠來源構成，比方facebook來源如果無法得到第三方證實可靠性則不應該用於構成條目的主要事實。以上。--Cat on the Mars 2022年10月5日 (三) 16:16 (UTC)

「個人出版物的觀點無論如何都不是生者傳記觀點的可靠來源」，比如A的（出版自傳/採訪/博客）中包含對B的評價或者生平信息，是否都絕不能作A的觀點或B的事實（聲稱）來引述，具體可靠性如何，我感覺要依情況商榷，難以一言概之。--YFdyh000（留言） 2022年10月6日 (四) 03:38 (UTC)

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

公示案其一（修正4）

（A:WP:GUNREL總言變更）任何人都可以建立網頁、自行出版或自稱專家，自行發表的來源往往未經任何事實核查，缺乏獨立第三方評審。由於絕大多數個人出版物、個人網站、博客、開放性wiki、網絡論壇或社交媒體上的貼文以及其它類似來源通常不是可接受的來源。因此所有使用者生成內容來源會被列入防濫用過濾器。

不過也有一些特例，例如一些新聞媒體會以博客指代其網絡專欄，如果專欄作者為專業人士其內容可能相對可靠；此外，如果某些內容專家已經在獨立、可靠的出版機構發表過相關專業領域的個人作品，並且受到社會的普遍認可，那麼其在相關專業領域的自行發表的內容也可能相對可靠。

編者仍需謹慎使用這類來源：一方面專欄的內容可能涉及作者個人觀點，新聞媒體對專欄的事實核查也可能相對寬鬆，應該辨析專欄文章中的觀點與事實，避免將作者的觀點作為事實引用；另一方面，如果專家自行發表的內容值得發表，那麼可能已經有人做了相同的工作，存在獨立第三方驗證的可靠來源可以替代。

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

個人出版物不能作為有關在世人物的獨立第三方來源，即便其作者是著名的職業調查員或作家。

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

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

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

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

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

同約克客觀點，不認為應該為布告板附加特殊效力。--Yinyue200（留言） 2022年10月8日 (六) 03:12 (UTC)

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

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

.

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

@Hijk910：

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

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

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

我也覺得過濾器方案比較好，這樣也與當前的慣例相差不大。合理的編輯並不會因為是否事先履行了某些手續就變得合理或者不合理，維基百科不是官僚機構。--Yinyue200（留言） 2022年10月8日 (六) 08:56 (UTC)

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

@Longway22@ThirdThink@Yinyue200

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

我仍然認為在「於來源引用中標示相關來源的擔保資格」不太合理。我的建議是這樣寫：若相關來源未（在布告板）獲得共識，編者應在條目的合適位置或討論頁體現出相關來源的擔保資格。未進行標示的內容可能會被他人移除。被移除的內容若能發現有效的補充材料，則可重新加入。--Yinyue200（留言） 2022年10月10日 (一) 15:16 (UTC)

@Yinyue200：

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

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

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

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

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

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

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

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

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

使用者生成內容使用條件：註：不適用開放性wiki、網絡論壇及與上述相關的社群網站

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

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

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

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

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

我覺得不適宜在這裡訂一些很硬性的規定，這類過於客觀的標準很難覆蓋所有情況，我覺得可以直接刪除「某年份」的表述：如相關賬號不屬任何機構，賬戶需獲得過媒體或學術引用，或被專業人士充分肯定。過舊的證據可能不被考慮。--Yinyue200（留言） 2022年10月10日 (一) 15:06 (UTC)

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

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

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

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

然而第二點您未解答，我覺得您提出草案的問題在於內容太過僵硬，用詞太過絕對，不適宜廣泛推廣。現有方針很少有用詞如此絕對的條文。--Yinyue200（留言） 2022年10月11日 (二) 11:56 (UTC)

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

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

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

確實一般應當過濾「街訪」--Yinyue200（留言） 2022年10月11日 (二) 15:59 (UTC)

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

(！)意見：以我自己的認知，滿足前四條中的二、三和四條的時候，通常這個來源已經沒法算作「用戶生成內容」了。例如本身被視作可靠來源的傳統媒體，其在社交平台經認證發布的屬於新聞報道文體的文章，歸入用戶生成內容就不合適。但同樣的一家媒體的評論員，以媒體賬號在同樣的平台發布的社論性質的文章，則又不宜。這其中的區別並不在於賬戶持有者的身份。二選一中的第一條滿足的時候，引用它的媒體或學術來源就會應該就是替代來源，會自動讓第一條不成立。(＆)建議：第一條的措辭可考慮修改為「相關內容無法由其他更為可靠的來源替代」，明確替代來源應該往什麼方向尋找。--Tiger（留言） 2022年10月11日 (二) 15:43 (UTC)

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

簡單回應:

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

（A:WP:GUNREL總言變更）任何人都可以建立網頁、自行出版或自稱專家，自行發表的來源往往未經任何事實核查，缺乏獨立第三方評審。由於絕大多數個人出版物、個人網站、博客、開放性wiki、網絡論壇或社交媒體上的貼文以及其它類似來源通常不是可接受的來源。因此所有使用者生成內容來源會被列入防濫用過濾器。

不過也有一些特例，例如一些新聞媒體會以博客指代其網絡專欄，如果專欄作者為專業人士其內容可能相對可靠；此外，如果某些內容專家已經在獨立、可靠的出版機構發表過相關專業領域的個人作品，並且受到社會的普遍認可，那麼其在相關專業領域的自行發表的內容也可能相對可靠。

編者仍需謹慎使用這類來源：一方面專欄的內容可能涉及作者個人觀點，新聞媒體對專欄的事實核查也可能相對寬鬆，應該辨析專欄文章中的觀點與事實，避免將作者的觀點作為事實引用；另一方面，如果專家自行發表的內容值得發表，那麼可能已經有人做了相同的工作，存在獨立第三方驗證的可靠來源可以替代。

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

個人出版物不能作為有關在世人物的獨立第三方來源，即便其作者是著名的職業調查員或作家。 （B:由A修正案並行，同時廢止WP:WIKISRC章節全部內容及超鏈接，全由A案之WP:GUNREL條文適用）

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

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

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

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

(？)疑問：上面有多個討論的子章節看起來有點像是公式的提案內容，不知先前參與討論的幾位可否澄清目前其中哪些正在公示？--Tiger（留言） 2022年10月11日 (二) 15:43 (UTC)

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

已移除「管理員意見」的標題。管理員身份在這裡沒有也不應該有任何作用，也請不要替我給我的意見加上標籤。—Tiger（留言） 2022年10月11日 (二) 21:17 (UTC)

---

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

（A:WP:GUNREL總言變更）任何人都可以建立網頁、自行出版或自稱專家，自行發表的來源往往未經任何事實核查，缺乏獨立第三方評審。由於絕大多數個人出版物、個人網站、博客、開放性wiki、網絡論壇或社交媒體上的貼文以及其它類似來源通常不是可接受的來源。因此所有使用者生成內容來源會被列入防濫用過濾器。

不過也有一些特例，例如一些新聞媒體會以博客指代其網絡專欄，如果專欄作者為專業人士其內容可能相對可靠；此外，如果某些內容專家已經在獨立、可靠的出版機構發表過相關專業領域的個人作品，並且受到社會的普遍認可，那麼其在相關專業領域的自行發表的內容也可能相對可靠。

編者仍需謹慎使用這類來源：一方面專欄的內容可能涉及作者個人觀點，新聞媒體對專欄的事實核查也可能相對寬鬆，應該辨析專欄文章中的觀點與事實，避免將作者的觀點作為事實引用；另一方面，如果專家自行發表的內容值得發表，那麼可能已經有人做了相同的工作，存在獨立第三方驗證的可靠來源可以替代。

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

個人出版物不能作為有關在世人物的獨立第三方來源，即便其作者是著名的職業調查員或作家。

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

及防濫用警告器內容：

使用者生成內容使用條件：註：不適用開放性wiki、網絡論壇及與上述相關的社群網站

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

---

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

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

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

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

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

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

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

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

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

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

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

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

不支持條文即行生效，我還是認為當前條文的內容和原始條文的風格差異相差太大。原始條文基本上是在闡述一個行事的原則。新的規定則詳細的多，儘管相比一開始的提議已經有所改善。我認為這樣的提案一旦推行會對當前編輯維基百科的行為產生較大影響，需要凝聚更多共識。--Yinyue200（留言） 2022年10月16日 (日) 08:54 (UTC)

@Yinyue200：

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

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

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

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

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

「因此所有用戶生成內容來源會被列入防濫用過濾器」：過濾器有標籤、警告和阻止等處理操作。這個地方沒說明白執行何種操作。建議不要一刀切執行阻止操作。

個人建議用戶生成內容使用條件不宜有過細的硬性規定。針對特定來源有問題，在布告版或者互助客棧討論即可。另外Wikipedia:關注度中有講關注度指引並不直接限制條目內容。不應直接按照關注度的要求來限制來源。--Steven Sun（留言） 2022年10月21日 (五) 08:14 (UTC)

1.warning & label

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

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

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

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

———

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

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

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

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

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

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

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

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

@Longway22：

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

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

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

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

就「仍然沒有反對聲音」，那我補充我的觀點。新條文「可能」很有參考價值，但是否凝聚廣泛共識仍很存疑，所涉來源價值定義的影響會非常廣泛，討論編者的廣度和時長、實際效果不顯著，沒有達到過往的影響全站之政策的程度。個人而言，新條文對細節和流程的規定仍顯複雜，與現有常見實踐缺乏對比、疑存衝突，實際執行的可行性和公信力仍未顯現，未參與討論的編者未必接受，可靠性討論也未必能得出可信結論。總結而言，我覺得它是半個指引、一份提案、一篇論述。還請加油，比如提出一些先後對比實例，將所需頁面搭好框架、局部試行作參考。改cite模板我是反對的，改濫用過濾器我認為時候未到。--YFdyh000（留言） 2022年10月25日 (二) 14:12 (UTC)

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

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

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

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

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

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

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

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

所以提案就是要在來源引用中「證明特定帳號的身分」，非身分證身分。

現時維基方針有以下的前設，如有編輯者反對這個前設，應展示證據去否定這個前設。然而以舊方針來說，沒有提供任何方法讓編輯者否定這個前設；所以新方針就是提供一個方法給編輯者否定這個前設。

.

任何人都可以建立網頁、自行出版或自稱專家，自行發表的來源往往未經任何事實核查，缺乏獨立第三方評審。由於絕大多數個人出版物、個人網站、博客、開放性wiki、網絡論壇或社交媒體上的貼文以及其它類似來源通常不是可接受的來源。--唔好阻住我愛國（留言） 2022年10月28日 (五) 13:55 (UTC)

例如要否定缺乏第三方評審，則需展示曾獲第三方評審。

例如要否定 自稱專家，則需展示專家身分，去確認真的是專家。--唔好阻住我愛國（留言） 2022年10月28日 (五) 14:01 (UTC)

重新解䆁修改方針的因由及對應方針指引和共識

Q.為什麼修改方針？--唔好阻住我愛國（留言） 2022年10月28日 (五) 14:52 (UTC)

A:有編輯者提名九龍巴士1A線至WP:GA，當中使用了缺乏署名的個人雲碟的來源，本人已該條目違反WP:OR為由認為不合資格。其後翻查現有的方針WP:GUNREL，發現「自行發表的刊物」並不是可接受的數據源，基於此方針，再查看WP:RSP有沒有關於雲碟或其他使用者生成內容的敘述，發現只有 「YouTube 風聞社區 bilibili AcFun Quora Reddit 微信公眾號 網易號 新浪微博 搜狐號」指明不可靠來源。於是在WP:RSN詢問其他編輯者個人雲盤是不是可靠來源，最後的結果是一致認為不可靠，當時亦是首次拋出「擔保制」，因有編輯者認為「非每個雲端硬碟分享檔案都無法追溯，無法驗證」。

𠄘上方的WP:RSP研讀，發現並沒有meta旗下的媒體，有編輯者建議直接修訂可靠來源方針，針對社交媒體這一類來源統一管理，因舊方針只出現「自行發表的刊物、個人網站以及部落格等」字眼。所以為何會有這個討論。--唔好阻住我愛國（留言） 2022年10月28日 (五) 15:16 (UTC)

Q.新方針對應方針指引和共識

任何人都可以建立網頁、自行出版或自稱專家，自行發表的來源往往未經任何事實核查，缺乏獨立第三方評審。由於絕大多數個人出版物、個人網站、博客、開放性wiki、網絡論壇或社交媒體上的貼文以及其它類似來源通常不是可接受的來源。因此所有使用者生成內容來源會被列入防濫用過濾器。 —>英維

當中使用「防濫用過濾器」非原文的「黑名單」是因為眾多編輯者反對完全禁止使用及「白名單」制度。

.

ref

Self-published sources (online and paper)段落 & User-generated content段落--唔好阻住我愛國（留言） 2022年10月28日 (五) 15:27 (UTC)

由於絕大部份的使用者生成來源通常不是可接受的來源，編者使用相關來源前應到佈告版尋求共識，確定相關來源是否符合要求。若相關來源未在使用者生成內容布告板獲得共識，編者有責任在條目的合適位置或討論頁展示相關來源的擔保資格。—>WP:CON及上方的擔保制

未進行來源證明的內容可能會在沒有事先通知的情況下被他人移除。被移除的內容若能發現有效的補充材料，則可重新加入。—>WP:OR列名來源段落

請注意，所有使用者生成內容只能當作第一手資料，不論發佈人的身分及機構。 —>WP:第一手來源--唔好阻住我愛國（留言） 2022年10月28日 (五) 15:36 (UTC)

如相關帳號不屬任何機構，引用文章或影片時需展示出相關帳號曾獲得媒體或學術引用，或被專業人士充分肯定的證明。若相關媒體在獲得媒體或學術引用或被專業人士充分肯定當刻的狀況與實際文章或影片發佈時的實際狀況存在重大落差時，其他編輯者有權連帶相關段落一併移除，但需在條目的討論頁或佈告版解釋移除原因。

如相關帳號屬於某機構／個人，需以其他官方或可靠第三方的形式展示帳號持有人的資歷/身分。—>WP:IAR-abg--唔好阻住我愛國（留言） 2022年10月28日 (五) 15:38 (UTC)

佈告版制度

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

---

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

（A:WP:GUNREL總言變更）任何人都可以建立網頁、自行出版或自稱專家，自行發表的來源往往未經任何事實核查，缺乏獨立第三方評審。由於絕大多數個人出版物、個人網站、博客、開放性wiki、網絡論壇或社交媒體上的貼文以及其它類似來源通常不是可接受的來源。因此所有使用者生成內容來源會被列入防濫用過濾器。

不過也有一些特例，例如一些新聞媒體會以博客指代其網絡專欄，如果專欄作者為專業人士其內容可能相對可靠；此外，如果某些內容專家已經在獨立、可靠的出版機構發表過相關專業領域的個人作品，並且受到社會的普遍認可，那麼其在相關專業領域的自行發表的內容也可能相對可靠。

編者仍需謹慎使用這類來源：一方面專欄的內容可能涉及作者個人觀點，新聞媒體對專欄的事實核查也可能相對寬鬆，應該辨析專欄文章中的觀點與事實，避免將作者的觀點作為事實引用；另一方面，如果專家自行發表的內容值得發表，那麼可能已經有人做了相同的工作，存在獨立第三方驗證的可靠來源可以替代。

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

個人出版物不能作為有關在世人物的獨立第三方來源，即便其作者是著名的職業調查員或作家。

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

及防濫用警告器內容：

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

註：不適用開放性wiki、網絡論壇及與上述相關的社群網站

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

---

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

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

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

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

(－)反對。第一，與現行條文差別過大，不清楚到底要改什麼，要解決什麼問題。第二，「所有用戶生成內容來源會被列入防濫用過濾器」這是管理員的責任還是誰的責任，如何列舉「所有」？第三，「能辨認賬號持分者的身份」，維基百科什麼時候需要身份驗證了？弗蘭西斯·培根寫文章沒提交身份證吧，他就不是可靠來源了？總之，提議的條文跟現行條文相比，對編者的要求大大提高，不利於參與。--Gqqnb（留言） 2022年10月23日 (日) 08:50 (UTC)

@Gqqnb：

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

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

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

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

---

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

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

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

不認同強制在條目頁申報，如相關賬號身份確有疑點，有人提出後，添加者才有義務在討論頁回應。--Yinyue200（留言） 2022年11月2日 (三) 07:07 (UTC)

按照你的意思，相關方針可即時實行？

「有責任」不等於「必須」。如按照新方針，擔保來源可以後補。

是這樣意思嗎？--唔好阻住我愛國（留言） 2022年11月4日 (五) 09:45 (UTC)

對，這是我的觀點，我認為如果只是「有責任」而不是「必須」那其實和現有方針差異不大，但也要看社群的意見。--Yinyue200（留言） 2022年11月7日 (一) 12:19 (UTC)

---

初步結論，基於方針「有責任」的關鍵詞，擔保來源可以後補。因此建議此方針於2022年12月1日開始生效。--唔好阻住我愛國（留言） 2022年11月14日 (一) 13:32 (UTC)

草案目前異議歸結起來，應該還是以當個案有明確針對身份疑點提出、而舉證必須毫無合理疑點下再行於討論版展開為主吧。另外所謂生效時間安排不是應繼續和佈告板討論並行嗎？即在更新條文內容同時、亦附加有關繼續商討之告示，有關繼續商定及調整時長亦要相應計算在案內（或跟進案）--約克客（留言） 2022年11月14日 (一) 13:46 (UTC)

延遲生效時間只是為了減少不必要的編輯爭議。--唔好阻住我愛國（留言） 2022年11月21日 (一) 16:04 (UTC)

閣下沒有回答問題，且案內共識基礎應是仍不足以通過閣下主推之完全方案。--約克客（留言） 2022年11月21日 (一) 22:43 (UTC)

非也，其實是足以通過，因為我只是一個推手及將所有共識合一，所有內容都是由各編輯者一起撰寫，而且是每句地審議，而部分用詞是參考上方的WP寫的（重新解䆁修改方針的因由及對應方針指引和共識）。不妨告訴你，我收到不少私下「感謝」通知。--唔好阻住我愛國（留言） 2022年11月22日 (二) 03:49 (UTC)

我仍擔憂可行性（共識、執行力和強制力）。建議您先試行流程以體現效果（如認可/不認可來源）和編者接受度，再研究條文及條目內標註的共識程度。--YFdyh000（留言） 2022年11月22日 (二) 04:14 (UTC)

其實我正等待防濫用過濾器的部分，WP:GUNREL已添加此版本但隱藏了，因為當中「列入防濫用過濾器」的句子未準備好。如果要試的話，#建議將Wikipedia:不要訴諸法律威脅提昇為法律方針的「某件事件」正討論這個問題（濫用社群媒體作來源）。--唔好阻住我愛國（留言） 2022年11月22日 (二) 04:19 (UTC)

所以通過完全方案確實為時尚早，共識目前仍應是密切檢視評估方案之為準。--約克客（留言） 2022年11月22日 (二) 07:18 (UTC)

的確，但由於關鍵的warning未準備好，無法看見方案的成效，故無法公示試行。但此方案至少比黑名單或聲稱「加強內容質素」好。--唔好阻住我愛國（留言） 2022年11月22日 (二) 15:16 (UTC)

另外，我看過新條文後，發現如果相關社群專頁已獲媒體的身分認證後，又需以其他官方或可靠第三方的形式展示帳號持有人的資歷或身分，這程序感覺會有所重覆。因為既然相關專頁已獲社群身份認證，這便可證明該專頁的確由官方真實擁有（有錯請指）。ThirdThink（留言） 2022年11月22日 (二) 05:06 (UTC)

不會重複呀，因為相關身分認證的可信度存疑。[3]--唔好阻住我愛國（留言） 2022年11月22日 (二) 05:15 (UTC)

如果單只是Twitter有這個問題，個人認為可以分開處理。正如傳媒也有報導如何透過藍剔來分辨真假Meta帳戶[4]。--ThirdThink（留言） 2022年11月25日 (五) 00:59 (UTC)

但是現在問題在於所謂認證機制，亦可能因部分平台之資方政策變動而有所異變，本地機制如以該案之細節調整等恐亦需本地進一步共議檢視，判讀有關設想之實際可行與否。--約克客（留言） 2022年11月25日 (五) 07:06 (UTC)

在此感謝首富馬斯克大大，如果不是他破壞了社群媒體認證制度，原先預計應該不會有人支持「擔保條件」制度。--唔好阻住我愛國（留言） 2022年11月26日 (六) 07:39 (UTC)

基於反對動態清零政策運動濫用Twitter作來源，有急切需要作試行，請求此方針試行版儘快實行。請問如何在WP:GUNREL實施試行版方針？

@Longway22、@ThirdThink、@YFdyh000、@Yinyue200--唔好阻住我愛國（留言） 2022年11月30日 (三) 03:44 (UTC)

---

全域用戶@SCP-2000： 你好像不知道這個討論的結果是先試行，並非仍在討論階段，若回退的話則無法達到試行效果，為何回退呢？ --唔好阻住我愛國（留言） 2022年11月24日 (四) 02:07 (UTC)

試行不需要寫在指引頁上。即使有需要，也請先達成共識。--SCP-0000（留言） 2022年11月24日 (四) 02:13 (UTC)

試行應寫在哪？若非寫在指引頁上，則無法達至試行效果，因拿不出「WP:」出來嚇人。--唔好阻住我愛國（留言） 2022年11月24日 (四) 02:16 (UTC)

應該先達成共識。目前來看，這討論是沒有「試行」的共識。--SCP-0000（留言） 2022年11月24日 (四) 02:24 (UTC)

@Tigerzeng,@Xiplus ，現在請求試行。--唔好阻住我愛國（留言） 2022年11月24日 (四) 03:01 (UTC)

@SCP-2000:請先閱讀整個討論。--唔好阻住我愛國（留言） 2022年11月24日 (四) 03:02 (UTC)

中維的FA、GA、DYK等評選是否可以改為英維的審議制而非強制投票制？

目前許多地方的投票制已經引發社群多次質疑和討論，動輒被認為有灌票嫌疑（甚至有不拉票即不能通過的說法），而且許多評選參與者不多，幾乎將淪為虛設，強制性的票數界限反而使許多達標頁面僅因為評選無人光顧而未能獲選，關於改為英維審議制，社群又何看法？歡迎大家討論。--有困擾的話，就讓魔女用魔法幫你排憂吧！ 2022年9月26日 (一) 04:47 (UTC)

如果審議人審議通過了不合格的條目，該負什麼樣的責任？審議人審議條目，又能獲得何種激勵？好奇這個審議制度如何運行。Fire Ice 2022年9月26日 (一) 08:11 (UTC)

我也不了悉英維為何能這樣運作而不至於出問題，亦不清楚中維是否這樣運作會出問題--有困擾的話，就讓魔女用魔法幫你排憂吧！ 2022年9月26日 (一) 10:31 (UTC)

英維似乎FA、GA、DYK都沒有激勵機制。看過一些GA就一個人審議，標準彈性很大。也存在公開交換審議的情況。--Benevolen（留言） 2022年9月26日 (一) 10:53 (UTC)

如果審議人審議通過了不合格的條目，該負什麼樣的責任？審議人審議條目，又能獲得何種激勵？ - 個人覺得這些問題不存在，而實話實說和這種話很像：如果IP用戶寫出了不合格的內容，該負怎麼樣的責任？IP用戶編輯條目，又能獲得何種激勵？

關於不合格條目，可以讀讀英維重選流程。兩種方式，並且可以以個人的方式進行重選。--0xDeadbeef（留言） 2022年9月26日 (一) 13:12 (UTC)

你應該和如下例子類比：如果巡查員巡查通過了不合格的內容，該負怎麼樣的責任？巡查員巡查條目，又能獲得何種激勵？當然，DYK、GA、FA比新條目巡查責任更為重大，他們將被推上首頁，甚至讀者要是點擊圖標，還能看到「優良條目是我們認為質量令人滿意，但未達典範標準的條目」等內容，甚至是「我們認為這些條目詳盡而深入，符合特定要求，是維基百科條目之傑出典範。」如果審議人把諸如遠東華人強制流配的原版這類東西選為FA，將來媒體報道順便提到某維基人「有三篇條目被評為優良條目，一篇被列為典範條目——此條目還被其他語言的維基百科用戶翻譯為英語、俄語、烏克蘭語、羅馬尼亞語以及阿拉伯語。」誰來負這個責任，該負什麼樣的責任？Fire Ice 2022年9月26日 (一) 13:56 (UTC)

GA、FA推上首頁難道不是需要更多人審議嗎？英維的DYK在上首頁之前都需要管理員進行批准的。至於FA在英維上可也是需要多個人審核達成共識。所以GA真的責任重大，必須投票表決嗎？如有問題則處理問題，無法處理問題則是另一個問題。如有GA搗亂的，輕者WP:TBAN，重者直接封禁不就行？--0xDeadbeef（留言） 2022年9月26日 (一) 14:06 (UTC)

當下GFA就是無人負責的，如果審議制度同樣無人負責，和當下制度又有什麼區別呢？Fire Ice 2022年9月26日 (一) 14:09 (UTC)

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

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

如果是按標準打勾勾的話，只不過變成自動灌票罷了（一次提交，一次「自動」判斷標準，一次同意通過）。如果是人審議的話，出現標準意見衝突怎麼辦？甚至說現在投票機制，有點像按標準進行人工審議罷了。——Sakamotosan路過圍觀 | 避免做作，免敬 2022年9月26日 (一) 09:01 (UTC)

我們至少需要具備基本的編輯經驗/能力的用戶才可能做好這一點吧？--百無一用是書生 (☎) 2022年9月26日 (一) 11:44 (UTC)

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

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

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

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

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

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

粵維人數和中維不可同日而語吧--有困擾的話，就讓魔女用魔法幫你排憂吧！ 2022年10月2日 (日) 10:01 (UTC)

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

 吐槽我的DYK恐懼症就是這麼來的...-- B-MIKE -留|簽 2022年10月31日 (一) 14:09 (UTC)

試行一次

吵這麼凶大家都是在紙上談兵，應該要實際做一次才能知道好不好才對。要不這樣，我提議實際使用一個典範條目評選試行一次審議制度。這樣有沒有問題、會不會有問題就全部顯現出來了。參考英維的評選制度，一名協調員擁有是否入選的最終決定權，這也解決了所謂的無人對審議結果負責的問題。

所以我就是說，大家是否願意讓下一篇典範條目評選由我作為協調員實際做給大家看一次是否可行，否則這個討論永遠都是沒有任何論據的辯論，不及格。 --MilkyDefer 2022年9月28日 (三) 07:36 (UTC)

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

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

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

贊成。對於我熟悉的領域，我願意作為評議人參與。（如果我有時間）--洛普利寧 2022年9月30日 (五) 02:55 (UTC)

支持，如果是我熟悉的領域，我願意作為評審人參與。--——🦝英特浣熊耐爾 ^{就一定要實現}_{（留言・貢獻）} 2022年10月2日 (日) 08:47 (UTC)

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

• 儘管我不覺得能夠阻止什麼: RFA試行與條目評審試行其實有很大的分別。RFA總是能夠吸引大量用戶前來，制度本身無非是怎樣令大家服氣而已。條目評審的本質問題是對某一方面有專攻的用戶不足，因此如果按自己的初步觀念投票，就有亂投、灌票之嫌; 如果總是由兩三大佬投反對票，又有對新人不公云云。現在試行萬眾矚目，將各路精英聚集起來，自然能撐起場面，但日後又怎辦呢?--Temp3600（留言） 2022年10月7日 (五) 10:10 (UTC)
  • (：)回應：典範條目幾大標準：全面、流暢、專業、考據全面、穩定、遵循格式手冊、媒體使用恰當、長度合理，對審查者的能力標準要求是不一致的。審議制度允許審核者只針對這其中的部分標準提出支持，協調員會檢查候選條目是否完整地接受了檢查。因此，審議制度可以讓評審者有力出力，回歸典範條目標準，同時阻擋遠東華人強制流放這種做了來源檢查就能發現問題但是偏偏沒人做就已經夠票了的條目通過。投票制度在另一方面，投下支持票不需要說明理由，一個「符合典範條目標準」到底是否完整涵蓋了所有標準呢？不知道。有責任心的人看到標準這麼多沒精力逐條確認所以不投；沒責任心的人看着條目差不多符合流暢、遵循格式手冊、長度合理就直接給支持票了。審議制度將典範條目標準進行足夠細顆粒度的審視，有能力的人只要專心檢查是否專業、是否與來源對得上號即可，專業能力欠缺的人就去檢查行文是否流暢，格式是否得當等不需要專業知識的準則。將審核過程分工完成降低了所有人的負擔，或可形成能力門檻降低的效果，更有親和力。協調員是守門員，對他們的要求應當較高。 --MilkyDefer 2022年10月7日 (五) 11:37 (UTC)
  • 我擔憂的是，實施初期可能會有編輯秉著改善中維的決心去審視各提名條目，這當然是好事，但日子久了，參與人數或會穩定下降，最後典範條目評選重回多年前投票附理由的情況，即「內容充足、語句順暢，參考資料足以支撐全文，以支持票作獎勵。」之類。--銀の死神♠走馬燈劇場^{祝你在亂流下平安} 2022年10月8日 (六) 10:14 (UTC)

    不一樣，如果害怕有這種現象就應該不允許投票帶理由，而是給每一個條件打鈎或給予評價，這樣迫害搗亂評選者的時候就不可以以忘記了有這個規定的理由逃避迫害。--0xDeadbeef（留言） 2022年10月8日 (六) 10:33 (UTC)

    共識制評選的規定中，如果「評審員沒有提供足夠的信息來判斷條目是否符合標準」，協調員可以判落選。

    此外，雖然共識制在中維可能做不到完美，但能避免投票制中的不少問題：比如不讀條目就投yesFA（甚至我看到有提名人請求撤銷FA時，都有用戶上來就投yesFA……）、高質量的條目因為規定時間內少幾個人投yesFA而落選等，我覺得總體而言共識制仍是一大進步。--BlackShadowG Slava Ukraini! 2022年10月8日 (六) 14:39 (UTC)

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

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

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

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

    我認為不管你如何想，有進步比原地踏步要好。如果能夠透過改善一下優質條目整體水準的方式吸引一些學者來（而不是對英維趨之若鶩、對中維嗤之以鼻）的話，就更好了。--MilkyDefer 2022年10月8日 (六) 15:20 (UTC)

方案設定

那就這樣，我先草擬一個方案，如下：

• 在該方案得到公示通過後，試行一次有效的評議制典範條目評選。
• 上一條當中的「有效」指的是，條目不滿足快速落選準則，且不是典範條目重審。
• 選擇的評選條目應該是在公示通過後，所提交的第一條典範條目評選。如果該候選條目不是有效的評選，則選擇確定候選條目評選無效時刻起，下一條提交的候選條目，以此類推。
  • 例子：假如本方案於2022年11月1日凌晨3:47公示通過，同日凌晨4:13有人提交了條目A作為典範條目候選、上午9:24另有人提交了條目B、下午17:33有人提交了條目C。則條目A成為試行評議制的對象，條目B和條目C繼續使用投票制。但是，在11月2日上午10:41時有人發現條目A含有大量侵犯版權的內容而導致其快速落選（參見即時不合標準準則第2條），則這一次對條目A的評審為無效評審。由於條目B和C已經在走投票流程甚至有人可能已經投票了不適合打攪，因此應當選擇11月2日上午10:41後提交的第一條典範條目候選作為新的審議對象，以此類推。
• 該次使用審議制的評選，其結果擁有與現行投票制同等的效力。即，若審議為入選，則條目獲得典範條目資格；若審議結果為落選，則條目同樣落選，30日冷靜期同樣適用。
• 應該為該次試行開設評審專頁，同時在典範條目評選主入口提供進入該次評審專頁的鏈接。（這一條是為了防止評議發言過多影響其他條目的評選，可再做商議）
• 該次試行的協調人由我擔任，畢竟是我提出要試行一次的。
• 試行結束後，我們繼續討論後續事宜。

如何？我還遺漏了什麼要點嗎？ --MilkyDefer 2022年10月2日 (日) 09:40 (UTC)

作為提案發起人表示原則性(＋)支持，唯我另發起了一個二十周年閉站抗議提案，可能時間上容易衝突--有困擾的話，就讓魔女用魔法幫你排憂吧！ 2022年10月2日 (日) 09:47 (UTC)

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

@Longway22 所以具體而言有什麼意見嗎？你說的這些太寬泛了完全不懂。--MilkyDefer 2022年10月7日 (五) 03:15 (UTC)

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

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

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

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

(＋)支持--——🦝英特浣熊耐爾 ^{就一定要實現}_{（留言・貢獻）} 2022年10月4日 (二) 04:15 (UTC)

(＋)支持。 --窩法乙烷 兒法夢碎 2022年10月4日 (二) 08:13 (UTC)

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

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

籌備

我開始籌備了：Wikipedia:典範條目評選/共識制試行，目前在翻譯英維的規則。——BlackShadowG Slava Ukraini! 2022年10月7日 (五) 04:46 (UTC)

目前英維相關規則/模板翻譯進度：

1. 主頁面：Wikipedia:典範條目評選/共識制試行（en:Wikipedia:Featured article candidates）完成
2. Template:FAC-instructions（en:Template:FAC-instructions）完成
3. Template:FAC/共識制試行（en:Template:FAC）完成
4. Template:Featured_article_candidates/共識制試行（en:Template:Featured_article_candidates）完成
5. Template:Featured_article_candidates/editintro（en:Template:Featured_article_candidates/editintro）完成
6. Wikipedia:Featured article preload（en:Wikipedia:Featured article preload）完成
7. Wikipedia:典範條目評選/存檔方式（en:Wikipedia:Featured_article_candidates/archiving）完成

下方的頁面在試行階段並非必須，可以等正式改用共識制後再翻譯/引入：

1. User:FACBot（維護FAC的機器人，主要的工作是存檔已關閉的提名）
2. Wikipedia:典範條目評選/急需評審（en:Wikipedia:Featured article candidates/FAC urgents）
3. Wikipedia:典範條目評選/入選記錄（en:Wikipedia:Featured article candidates/Featured log）入選的FAC由協調員加到這個頁面
4. Wikipedia:典範條目評選/提名存檔（en:Wikipedia:Featured article candidates/Archived nominations）落選的FAC由協調員加到這個頁面

下方的頁面可有可無：

1. Wikipedia:典範條目評選常見問題（en:Wikipedia:Wikipedia Signpost/2008-04-07/Dispatches）FAC的常見問題，沒有也問題不大
2. Wikipedia:典範條目統計（en:Wikipedia:Featured article statistics）

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

此外@MilkyDefer：英維提名FAC評選的方式是讓提名人往條目的討論頁上放{{subst:FAC}}（目前中維的模板位於{{subst:FAC/共识制试行}}），隨機抽條目可能在程序上會與正式的不太相同。因此，比起抽一篇「幸運條目」用共識制，要不讓有意讓條目以共識制評審的主編自薦條目？--BlackShadowG Slava Ukraini! 2022年10月7日 (五) 09:32 (UTC)

我們實驗的是審議制度，在審議之外的流程性質的東西不在實驗範圍啊。--MilkyDefer 2022年10月8日 (六) 05:31 (UTC)

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

目前基本籌備已經完成，隨時可以開始試行。--BlackShadowG Slava Ukraini! 2022年10月7日 (五) 09:49 (UTC)

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

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

能具體闡釋一下你認為GA比FA更適合的原因嗎？協調員的話一下子三個人就協調試行的一篇條目會不會多餘了些？--MilkyDefer 2022年10月10日 (一) 01:12 (UTC)

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

有一個問題。你為什麼會認為FA是多數社群認定的條目？可能確實需要比GA多一點的人認同，但是誇張到多數是不可能的。在英維平均一個GA的審閱者1到2個；FA大概10個，怎麼看都不是「多數」。要追求你想象中的多數，任何一個地方都沒有。--MilkyDefer 2022年10月10日 (一) 03:14 (UTC)

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

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

FA並不是一定要為了讓讀者感興趣。只能說是百科全書裡面最優秀的條目，而往往很多優秀的條目都是能夠讓人感興趣而已。

另外，感謝你的回覆，解析失敗 (帶有PNG備選的SVG（MathML可通過瀏覽器插件啟用）：從服務器「/mathoid/local/v1/」返回無效的響應（「Math extension cannot connect to Restbase.」）：): \int 。--0xDeadbeef（留言） 2022年10月10日 (一) 06:00 (UTC)

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

所以才會有典範條目標準，將「最優秀的條目」的標準明確化。--MilkyDefer 2022年10月10日 (一) 06:10 (UTC)

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

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

討論狀態：普遍相信採取審議制度可以相比於投票制度擁有更嚴格的把關。

現在事實：典範條目在品質上要求更優於優良條目。

所以不對典範條目嚴格，反而對次一級的優良條目嚴格，不符合直覺。--MilkyDefer 2022年10月11日 (二) 12:58 (UTC)

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

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

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

我可以肯定，「審議制度可以相比於投票制度擁有更嚴格的把關」這句話所言絕對非虛。

如果說審議制「標準彈性很大」，那我可以說，投票制的所謂標準幾乎可以視而不見。目前投票制是否入選不是依據「條目符合多少FA標準」，而是「多少人認為條目符合FA標準」。投下支持票的人可能沒有讀過條目，甚至可能知道FA要符合哪些標準，只要一定數量的用戶投下支持票，條目就能入選，沒有人能確定投票者是否有仔細審過（甚至是否審過）條目。即使有用戶指出條目存在不少問題，只要支持票足以蓋過他，那這些意見也可以視而不見。改用審議制度可以最大程度避免這種問題，至少審議制度中，僅僅表示支持是沒有意義的。--BlackShadowG Slava Ukraini! 2022年10月12日 (三) 13:40 (UTC)

這樣子說吧，請問你對於試行一次究竟有什麼意見呢？改成GA和三個人總要有理由吧？英維的巨大RFC也只找了三個closer。如果和這個比起來是不是英維應該找三倍以上的人呢？不是說中維缺人嗎？可現在一個無害的試運行都要求這麼高了。--0xDeadbeef（留言） 2022年10月12日 (三) 13:49 (UTC)

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

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

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

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

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

如果要三個人，那你對於協調員人選有什麼推薦嗎？在此次試行中，這些問題應該不存在吧。還是說，你覺得MilkyDefer沒有社群信任/不可信？如果說FA評選沒問題，那折毛事件如何解釋？--0xDeadbeef（留言） 2022年10月13日 (四) 04:11 (UTC)

閣下認為FAC「沒什麼問題」是因為FAC有硬性標準，不會引發爭議。但FAC最重要的目的，逐一檢查條目是否符合WP:FACR，在投票制中完全無法落實，理由已如前述（例如：參與者完全可以不看條目/不知道FA標準就投票讓條目入選，少數服從多數可以讓重要意見直接視而不見）。共識制度即使有爭議，也可以提高FA條目質量的把關。閣下認為「沒壞別修」，在我看來這是已經壞了，而且壞得很嚴重，折毛事件就證明了這一點。

此外我不認為三個協調員是適合中文維基百科社群運作方式的做法。中維本身就人手不足，判斷共識還需要三個人才能做到嗎？再者，協調員出現爭議又給誰來判斷協調員的共識？「協調協調員的協調員」？到頭來判斷共識的權利還是會落到一個人手裡。--BlackShadowG Slava Ukraini! 2022年10月13日 (四) 15:34 (UTC)

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

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

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

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

誠然，審議制未必能完全防止折毛事件的發生，但能很大程度進行避免。當時遠東華人強制流配的FAC中，沒有用戶檢查來源，由於是投票制，因此即使沒有用戶做來源檢查，條目也可以入選。如果是審議制，就更有可能有用戶根據WP:FACR做來源檢查（英維的偽條目Bicholim conflict就是在FAC被查出來的）。

鄙人仍不認為結案需要三個協調員，先不提中維是否有這麼多人力，判斷共識一個人足矣。協調員就相當於FAC的管理員，如果AFD要兩三個管理員才能結案，顯然不是什麼好事。且會引起爭議的評選，顯然條目本身也是有問題的，即使被判落選，完善條目過一個月再來評選是個更好的方式。--BlackShadowG Slava Ukraini! 2022年10月15日 (六) 07:55 (UTC)

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

只是試行，必要性不大。英維這麼大的社群也只需要四名協調員，一篇條目就是由一名協調員結案。需要注意的是，條目是否入選不是依據協調員的看法，而是依據審閱者的共識，協調員只是負責判斷審閱者的共識。這就好比為何AFD只需要一名管理員就能結案一樣。--BlackShadowG Slava Ukraini! 2022年10月11日 (二) 12:52 (UTC)

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

根據目前英維的規則，「沒有達成條目入選的共識」就是落選；這與審議制的GAC區別很大，審議制的GAC是一名審閱者主要負責審閱，其它編者也可以發表意見，只要基本沒什麼問題，審閱者就可以評定入選，這比FAC寬鬆很多，所以我不建議閣下提議的用GAC試行。--BlackShadowG Slava Ukraini! 2022年10月12日 (三) 13:15 (UTC)

如果最終決斷有疑，可以依託之前意見再討論和重選，多名協調員得出的共識也未必是普遍、可靠的共識，共識始終可推翻。如同存廢討論的異議路徑是存廢覆核。--YFdyh000（留言） 2022年10月11日 (二) 18:35 (UTC)

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

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

如果決斷並不違逆共識而只是偏頗，繼續在客棧等位置討論就好，然後再走重選手續。嚴重情況得到共識建議雪球以推翻決定，但爭議議題就很麻煩。如果說的難聽，我也無法排除兩名協調員一同忽視共識或爭議的可能性，以及協調員如何可信。--YFdyh000（留言） 2022年10月11日 (二) 20:14 (UTC)

BlackShadowG回應後了我又看了一遍，我還是搞不懂為何需要有三個協調員。如果你認為協調員關閉討論的是en:WP:SUPERVOTE，那是不是在暗示你不認可MilkyDefer對於共識的判定？協調員的主要工作只有兩個：第一是判斷討論中有沒有達成共識，第二是保證討論沒有遺漏掉WP:FACR，且在共識作為提拔FA時有合理反對的權利。但是，並不是說明協調員能在多半人反對的情況下強行推進到FA。--0xDeadbeef（留言） 2022年10月12日 (三) 13:34 (UTC)

我可以簡單地說，判斷共識的工作最後肯定會落到一個人手中，這一點幾乎不太可能改變。協調員是負責判斷審閱者之間的共識的，如果要多名協調員對「判斷共識」達成共識，那如果協調員間產生不同意見，又由誰來判斷協調員間的共識？再設立一個「負責判斷協調員的共識」的職位嗎？我不認為這樣一層層下去是件好事，讓協調員作為那個判斷共識的人，就足夠了。--BlackShadowG Slava Ukraini! 2022年10月12日 (三) 13:52 (UTC)

建設性提議

試行本就是為了擺脫空想看到底好不好，試行提案還要提修正案爭吵的話實質上就是延續了空想，因此我建議下面的修正案可以跳過去直接按原案試行一次-有困擾的話，就讓魔女用魔法幫你排憂吧！ 2022年10月26日 (三) 07:21 (UTC)

試行一次修正提案

鑑於上面有人強烈要求對這一次試行做出兩點修訂，特列如下：

1. 這一次試行改針對一次優良條目評選
2. 增加這一次試行的協調員數量為三人

如果大家都沒意見的話我也就從了吧。 --MilkyDefer 2022年10月12日 (三) 01:01 (UTC)

雖然覺得三個人評選優良條目很搞笑，但是如果覺得這樣有意思，我可以當一個協調員--0xDeadbeef（留言） 2022年10月12日 (三) 04:36 (UTC)

(－)反對：一人、FA比較好，如果從GA試行那還不如從NYK試行呢。--有困擾的話，就讓魔女用魔法幫你排憂吧！ 2022年10月17日 (一) 06:01 (UTC)

(－)反對:

1.英維GA的共識制評審方式與FA完全不同，GA通常是一名審閱者主要負責審閱，其它編者發表意見；FA則是需要多名審閱者達成共識，顯然在中維先試行FA的共識制評審更為合適。

2.一篇條目只需要一名協調員判斷共識，理由已在上方回復。--BlackShadowG Slava Ukraini! 2022年10月12日 (三) 13:08 (UTC)

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

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

不建議改成GA試行，GA審議制是一名審閱者直接決定條目是否入選，不需要協調員。--BlackShadowG Slava Ukraini! 2022年10月17日 (一) 11:43 (UTC)

我覺得他可能想的是走出與英維不同的路子——GA審議，FA投票……--MilkyDefer 2022年10月17日 (一) 14:15 (UTC)

FA比GA標準更嚴格，卻使用更寬鬆的投票制？怎麼看都不合理吧。--BlackShadowG Slava Ukraini! 2022年10月18日 (二) 13:14 (UTC)

那把他召喚出來闡釋一下吧@ATannedBurger--MilkyDefer 2022年10月18日 (二) 14:30 (UTC)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

「目前的投票制中審閱者不需要仔細檢查條目就能入選」這點根本不需要我來舉證吧，閣下覺得投下yesFA的編者一定仔細檢查過條目了嗎？再極端點說，一篇條目就算8名編者都沒有看過條目投yesFA，條目照樣能入選。

「FAC就機制上而言是沒有問題的」這句話在大前提上就是不正確的，閣下認為FAC「沒有問題」是說其「沒有爭議」，不用仔細檢查條目當然沒有爭議。

至於您提到的共識討論的一些問題（如協調員獨大，可自行決定共識、有償協調員而導致協調員和評審員狼狽為奸、各評審員因其理據不同而在決定共識中不享有同等地位等問題），我可以說，共識本身就伴隨着爭議，無論在互助客棧還是其它地方，只要有反對意見，爭議就會存在，即使是讓管理員來結案，也沒法讓所有人都信服。共識制FAC也是如此，有爭議不是件壞事，這說明條目被仔細檢查過才會引發爭議，我也很樂於看到這種爭議的出現。況且，有爭議的條目其自身肯定也是有問題的，如果一篇條目收到大量的支持/反對意見，協調員再「獨大」/「有償」也沒法改變既定的結果；真正會引發爭議的只有那些支持和反對意見共存的條目，只有這些條目的結案會給協調員判斷的空間，按照共識制的規則，這種條目通常會落選，在落選後的時間內，主編完全可以改善條目，把爭議的問題去除再來提名，這是件好事。--BlackShadowG Slava Ukraini! 2022年10月21日 (五) 00:04 (UTC)

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

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

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

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

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

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

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

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

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

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

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

  可以考慮在評審的時候臨時召集一兩位熟悉相關領域條目編寫的編者征取意見，就像你之前提到的，臭皮匠和諸葛亮的情況。常駐協調員要處理所有的評選條目，臨時召集來的編者只需要在相關領域的評選出現時才來，協調員是投入（commit），其他評審含被召集人是參與（involve）。如果你要說會這個方向的編者只有提名人的話，其實在論文同行評審中最最冷門的方向也是差不多的情況。--MilkyDefer 2022年10月21日 (五) 02:20 (UTC)

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

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

  條目評審也不是搞得這麼等級森嚴的吧？熟悉該領域的編者也不見得需要與其他編者要具有某種上下級關係；所謂的協調員，或者說，召集人，發出邀請讓他們得知有他們可能熟悉的條目在進行評審。不見得他們就會成為聽取下面普通評審員匯報工作的那種「主審」。但是他們的意見可以給協調員很重要的參考是不錯的，有熟悉主題的人的認可的話，協調員做出判斷也會更有把握一些；熟悉主題的人長期不出現的話，評審就會被拉長，要麼更多普通人加入審閱提高置信度，要麼這種「專家」出現。考慮到現在英維的FA最久的能拖三個月，可以預見這種事情會發生但是不太至於會導致災難。FA評選數量本身就比較少，姑且是還能經得起這種延遲的。--MilkyDefer 2022年10月21日 (五) 14:54 (UTC)

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

  這個問題我不能替代社群回答。目前而言我是能接受的，我不能替代大家的看法。等其他人怎麼說吧。--MilkyDefer 2022年10月22日 (六) 15:20 (UTC)

  我也能接受，FAC的所需時間的變長也代表着FA的評選標準以及條目質量的提高。再者，難度有哪家期刊同行評審幾天就能完成的嗎。--BlackShadowG Slava Ukraini! 2022年10月23日 (日) 02:27 (UTC)

  回覆一下兩個評論：

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

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

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

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

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

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

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

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

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

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

  那好啊，比中國人更看重人際關係以及讀空氣的日本人他們的制度又是什麼呢？

  • 支持票通常都帶上長篇大論
  • 投票持續最長三個月，特殊情況可延期一個月
  • 在上述期限內的任意時點達成「支持票三票且占有效總票數四分之三之上」的狀態且持續一個禮拜即告入選。
  • 滿足下列任意情況者快速落選：
    • 反對票至少三票且維持一個禮拜
    • 沒有其他支持票且提名者撤回提名
    • 提名者是傀儡賬號被不限期封鎖，沒有其他支持票

  現在論支持票是投一個yesFA走人，又說不能走討論制度，兩邊都取不到好，真的要成文明窪地了。--MilkyDefer 2022年10月25日 (二) 05:19 (UTC)

  我不認為「沉默的反對」在FAC中是需要考慮的（無論是投票制還是共識制），既然對被評選的條目有意見，就應該在評選中提出來，既然無意提出自己的意見，就不應指望自己沒提出的意見被納入考量。協調員沒有義務偵測出/發現各編者對一條目的見解，他們只需要依據提出意見的用戶做出判斷。

  鄙人不太認同共識制將形成另類如同互助客棧的辯論平台這一觀點，共識制FAC不是正方與反方的「辯論」，且與客棧和RFA有本質上的不同。共識制FAC是反方指出條目不合標準的地方，讓主編來改善，只要改善完成，再多的反對意見都可以解決，而不需要正方來「辯論」。--BlackShadowG Slava Ukraini! 2022年10月25日 (二) 10:23 (UTC)

  先回應一部分：

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

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

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

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

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

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

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

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

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

  繼續回應：

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

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

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

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

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

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

  確實一次的試行和全面推展並沒有關聯，也不存在「因為試行成功所以應該拓展到整站」的理論，個人認為可以姑且一試。

  當然也應考慮試行後當選的條目是否仍要重走投票制。--$\int$（☎）dt 2022年10月28日 (五) 05:39 (UTC)

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

確實我們好像花了很多精力去解釋可持續性的問題，但這跟僅僅一次的試行可以說是毫不影響。不過Temp3600說的也對，這次試行還是選擇一篇相對熟悉的領域（對我而言是ACG與電腦）來審，而不是最開始設定的「無差別選擇第一篇提交的條目」會不會好一些？如果試行的條目對領域存在限制的話，到時候我們就必須等待一篇相關領域內的條目提交到評選來，這個延時就不在可控範圍內了。--MilkyDefer 2022年10月27日 (四) 10:14 (UTC)

那我們現在需要先決定選什麼領域的條目嗎？--BlackShadowG Slava Ukraini! 2022年10月28日 (五) 10:02 (UTC)

首先先決定要不要選特定領域的條目，再考慮選什麼領域的條目。不管是ACG還是電腦技術哪怕是初等中等數學，被送上FAC都是稀奇事，說不定到年底都見不到一篇。--MilkyDefer 2022年10月28日 (五) 10:29 (UTC)

我覺得選不選特定領域的條目均可。不過如果需要ACG相關的FAC條目的話，我之前主編的最後生還者就是FAC不夠票落選的，30天冷靜期過去後我會重新提名，如果實在缺條目的話也許可以等這篇。--BlackShadowG Slava Ukraini! 2022年10月28日 (五) 10:48 (UTC)

也可以哦……只要不是原神相關。--MilkyDefer 2022年10月29日 (六) 11:25 (UTC)

關於試行一次的公示

已通過：

至少沒有人反對要試一次，那就這麼定了。MilkyDefer 2022年11月11日 (五) 12:44 (UTC)

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

---

總之，在將近一個月的討論（辯論？）當中，大家都中途偏離軌道開始討論制度的可持續問題。這不應該成為試行一次的blocker。 公示7日：

• 茲試行一次有效的評議制典範條目評選。
• 上一條當中的「有效」指的是，條目不滿足快速落選準則，且不是典範條目重審。
• 選擇的評選條目應該是在公示通過後，提交的一篇落於ACG範疇或是電腦、資訊科技範疇的條目。（簡化挑選準則，因為保底會有一篇最後生還者進行第二次典範條目評審）
• 該次使用審議制的評選，其結果擁有與現行投票制同等的效力。即，若審議為入選，則條目獲得典範條目資格；若審議結果為落選，則條目同樣落選，30日冷靜期同樣適用。在社群的反對意見極大的時候，不排除入選的條目還要重新投票的可能（我希望這種事情不要發生）。
• 應該為該次試行開設評審專頁，同時在典範條目評選主入口提供進入該次評審專頁的鏈接。（完成→Wikipedia:典範條目評選/共識制試行）
• 該次試行的協調人為MilkyDefer。

--MilkyDefer 2022年10月31日 (一) 05:06 (UTC)

• 可以準備打包走人了。這個社群一定要至少先示範幾十個存檔，這樣才能考慮要不要再用存檔。不然就可以走退休了吧？看看最近一個月（2022年10月）以來，其他願意幫忙用存檔的似乎只有看見@SilverReaper而已，如上面所述，根本也見不到哪個管理員來出手，就人手而言顯然就已經不夠了。以後想要靠這個拿到站務獎的用戶啊，難度一定升高了不少，因為真的是有看沒有懂。如果沒有示範存檔的話，估計就是準備走向類似存廢討論一樣成為積壓的頁面，因為都沒人敢動存檔。算了，反正對那些本來也就寫不出至少GA等級的條目來講那是真的沒差，要不然為何每次寫在DYK提名時都得強調「不考慮{{produceEncouragement}}、GA或FA」呢？因為條目和是否為一個GA或FA完全無關，GA或FA也就是一個條目而已，並不會因此變成多個條目。--Z7504非常建議必要時多關注評選（留言） 2022年10月31日 (一) 14:46 (UTC)

  我其實沒有讀懂你這段發言的意思，尤其是與現在公示內容的關係。如果你要說存檔的話，由於將要試行一次的典範條目評選是單獨開設子頁面，屆時的「存檔」就是將整個評選子頁面移動到對應的位置，甚至無需移動頁面，直接在{{Article history}}填寫上正確的討論頁面位置就可。若能引入FACbot的話整個過程就是真的不需要人來干預了。就我做過的存檔而言，存檔過程很繁瑣。用作移動存檔的那個模板（我記得是叫{{移動存檔}}吧）的使用晦澀不好理解，修改{{Article history}}也並非容易，這都拉高了參與存檔工作的門檻。沒有相應的操作指南，會的都會，不會的也不知道怎麼學，所以會有積壓。

  補充一下移動存檔的門檻有多高。大家都知道被移動的存檔都會有一行近乎是統一的提示：「本討論移動自XXXXX，執行人XXXXX」。這是統一利用了{{移動存檔}}模板達成的。但是，在使用這個模板的時候做的都是替換引用，因此從編輯後的頁面源代碼中是看不出討論是如何被移動的。想要移動存檔對不熟悉的人可以說是連門都摸不着。--MilkyDefer 2022年11月2日 (三) 13:38 (UTC)

  英維的en:User:FACBot就是專門處理存檔的機器人，但是是共識制的，如果共識制的提案通過，也許可以引入這個機器人（原作者有公開源碼，應該問題不大）。似乎目前的投票制也可能可以用機器人存檔，不過這就需要請熟悉相關技術的用戶來專門就中維的存檔機制編寫機器人了。--BlackShadowG Slava Ukraini! 2022年11月2日 (三) 14:19 (UTC)

  怎麼不乾脆說以後這些存檔都不用手工存檔就好了呢？全機器人、全自動化。呵呵，那就要保證存檔絕對不會出錯餒，怎麼可能？啊如果機器人存檔真的不會出錯，真的能打包走人了啊，還需要普通用戶在維基百科做存檔幹啥呢？也免了吧。當然，若以後交由給機器人存檔提名，還可以完全避免掉「移動存檔的人是提名人自己提名的條目」這問題呢，反倒是優點，因為解決了一小部分的Bug。--Z7504非常建議必要時多關注評選（留言） 2022年11月2日 (三) 19:46 (UTC)

  emmm我是說有沒有一種可能，存檔機器人可以設計成只有在協調員下令要求其存檔的時候才會運作？誰下令誰負責擦屁股這種道理應該是很明了的吧？--MilkyDefer 2022年11月3日 (四) 02:24 (UTC)

  英維本來就是這樣啊……--BlackShadowG Slava Ukraini! 2022年11月3日 (四) 10:27 (UTC)

  我想Z7504君其中一個意思是，雖然機器人存檔可以避免之前提及「自己結束自己的提名」的風險，也省卻了人力，但至少現時的人手存檔機制是一個途徑讓用戶接觸站務工作（甚至獲得維基獎勵）。--銀の死神♠走馬燈劇場^{祝你在亂流下平安} 2022年11月3日 (四) 12:27 (UTC)

  我不認為接觸站務工作必須要跟機器人搶工作（當然我是說有機器人的前提下），而且中維有大量站務工作可以幫忙處理。--BlackShadowG Slava Ukraini! 2022年11月3日 (四) 12:52 (UTC)

  剛好可以跟隔壁存廢討論聯動一下，擔心存檔條目評選這份站務工作會被機器人搶了的可以去隔壁存廢討論積壓解決{{Follow-up}}標出來的，已經有結論但沒人執行的事情。--MilkyDefer 2022年11月4日 (五) 04:54 (UTC)

  機械人取代人類，將人類從低價值的重覆文書工作中解放出來，不是百利而無一害嗎。--Temp3600（留言） 2022年11月6日 (日) 16:30 (UTC)

• 想問一個比較尷尬的問題，如果公示期完結後無人自薦條目，而保底的《最後生還者》也沒有可供協調員參考的明確意見（有機會發生的是一堆純支持票，我在英維FAC也見過有編輯投這類），是否要等待下一條屬於相關範疇的條目有興趣參選FA才會再次試行？--銀の死神♠走馬燈劇場^{祝你在亂流下平安} 2022年11月6日 (日) 03:22 (UTC)

  我個人認為要是這種事情真的發生了，那評審結束後我第一個要求回到投票制度。只有純支持票跟投票有什麼區別？反而還顯得變成動態入選門檻。--MilkyDefer 2022年11月6日 (日) 03:35 (UTC)

  這個時候就考驗主委的功力了。主委作為整個評審的召集人，除了自己需熟識有關主題，能發表意見引領眾人思考外，也有邀請合適的編審者協助評審的職能。如果只有無用的純支持票，條目旳狀態就是「無共識」，須等主委邀請更多高明之士前來發表意見。--Temp3600（留言） 2022年11月6日 (日) 16:30 (UTC)

• @慕尼黑啤酒、Suicasmo、A1Cafel、卡達：召喚一些（我印象中）時常提名條目參與FAC但未退休的編輯給予更多意見。--銀の死神♠走馬燈劇場^{祝你在亂流下平安} 2022年11月7日 (一) 10:59 (UTC)
• @慕尼黑啤酒、Suicasmo、A1Cafel、卡達：我也來ping一次。在長達9天的公示過程中Z7504提出了一個很奇怪的意見後得到回應。我等到這周五晚上6點（UTC+8），如果沒有其它問題的話就告通過了。 --MilkyDefer 2022年11月9日 (三) 07:55 (UTC)

  本人甚少參與站務討論，恕難以給出建設性意見。站在主編者的立場，惟希望條目評選的流程簡便順暢為佳。--慕尼黑啤酒（留言） 2022年11月9日 (三) 08:30 (UTC)

---

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

試行期間的交流

• @BlackShadowG：你看現在輻射 (遊戲)被提交至FAC了，能協助開一下評審專頁嗎？畢竟是你導入的那些個模板以及頁面。 MilkyDefer 2022年11月12日 (六) 13:48 (UTC)

  已在維基百科:典範條目評選/輻射 (遊戲)/存檔1創建。--0xDeadbeef（留言） 2022年11月12日 (六) 16:56 (UTC)

  抱歉昨天沒空上維基，感謝0xDeadbeef君開設評審專頁，目前程序上應該是沒問題了。--BlackShadowG Slava Ukraini! 2022年11月13日 (日) 03:24 (UTC)

  剛剛嘗試發表意見，整個介面不user friendly。如提出問題需要按「編輯原始碼」，然後仿照上一手的格式提出意見。非以往的只需按「回覆」。--唔好阻住我愛國（留言） 2022年11月13日 (日) 15:49 (UTC)

  因為要逐名用戶清晰地提出意見嘛，正如管理員選舉中，閣下提出問題時，也是開多一章節「XXX的意見／問題」，這便可在條目進行評選時，更容易留意到有甚麼用戶提出意見。ThirdThink（留言） 2022年11月14日 (一) 01:05 (UTC)

  看起來閣下沒有看到頁面上方的Wikipedia:典範條目評選/共識制試行#意見交流：「請不要為簡短的支持或反對意見創建分段，簡短的意見只需標上*{{支持}}、*{{反对}}或*{{意见}}並附上您的觀點即可。」，簡短的意見可以不用開子章節。--BlackShadowG Slava Ukraini! 2022年11月14日 (一) 11:47 (UTC)

  如果是這樣的話，建議開一新四級段落，專門給予編輯者對條目作出簡短建議，標題可以是「簡段評審」。--唔好阻住我愛國（留言） 2022年11月14日 (一) 13:25 (UTC)

  已開。--BlackShadowG Slava Ukraini! 2022年11月14日 (一) 13:29 (UTC)

• 建議協調員名字在開始評選區列出來。--Temp3600（留言） 2022年11月14日 (一) 02:32 (UTC)

  頁頂就有（「典範條目評選的協調員：MilkyDefer，可決定每個提名程序的時間」）。--BlackShadowG Slava Ukraini! 2022年11月14日 (一) 11:48 (UTC)

  之後可能要談談評審期時長的問題，現時的設定有點廣泛。--銀の死神♠走馬燈劇場^{祝你在亂流下平安} 2022年11月14日 (一) 12:47 (UTC)

  評審期時長比較靈活正是共識制的優點之一，如果評審者比較多，各項標準很快就完成了檢查，那麼條目在幾天內就能完成評審；如果關注的人比較少，則可以延長直到各項標準檢查完。--BlackShadowG Slava Ukraini! 2022年11月14日 (一) 13:02 (UTC)

  「典範條目評選的協調員」是如何產生？誰有資格擔任這個角色？

  這個問題非常重要！--唔好阻住我愛國（留言） 2022年11月14日 (一) 13:27 (UTC)

  目前是試行，所有由最初提議試行的MilkyDefer君自薦擔任。機制正式上路後肯定會進行正式的協調員選舉等。--BlackShadowG Slava Ukraini! 2022年11月14日 (一) 13:33 (UTC)

  建議機制正式實行前需制定整個提名流程及資格，否則不宜實行。--唔好阻住我愛國（留言） 2022年11月14日 (一) 13:37 (UTC)

  正式實行前顯然是會的。不過我不建議在試行階段未結束時開啟協調員選舉，這容易分散社群精力。--BlackShadowG Slava Ukraini! 2022年11月14日 (一) 13:44 (UTC)

• 對整個條目綜合地發表意見雖然有用，但如果能將意見明確地按準則劃分，即：編寫良好的, 全面的, 考證充足的,中立的, 穩定的, 遵循格式手冊, 媒體恰當, 圖像遵循文件使用方針, 長度合理; 則更方便協調員審閱這些方面的意見。--Temp3600（留言） 2022年11月15日 (二) 15:28 (UTC)
• 插句嘴，我覺得優良典範條目的標準可能要重譯（寫）一下……「它是編寫良好的」怎麼看怎麼不像中文🚬 ——魔琴 [ 留言 貢獻 新手2023計劃 ] 2022年11月24日 (四) 18:27 (UTC)

藝人參與綜藝節目列表

在Wikipedia:頁面存廢討論/記錄/2022/10/06#文彬影視作品列表引起的疑問。按2016年WikiProject_talk:歌手和演員#綜藝節目是否不應該放在明星條目呢?，達成了不應在個人條目羅列非固定班底綜藝的共識，如沒理解錯誤，當時@AT容許另作獨立列表條目作為折衷。@LuciferianThomas的教學中，以SpeXial影視作品作為例子。老實說，如按平日的條目獨立性討論，例如近來常有的馬來西亞政治人物分拆條目，這些列表可用「匪夷所思」來形容，SpeXial影視作品更是完全沒有來源的列表。我明白這可能是歷史遺下的問題，但也需要問清楚現在應按什麼標準去判定(1)分拆舊條目的內容、(2)建立新條目是否可接受。是否任何有條目的藝人，都有資格被建立綜藝節目列表條目？是否需要來源？另也徵詢第一個告知我此共識的@Wongan4614的意見。--Factrecordor（留言） 2022年10月13日 (四) 12:36 (UTC)

( π )題外話 吐槽 對於「羅列非固定班底綜藝」的禁止性標準和清理，我個人不是很喜歡。如果內容不濫（比如每次必寫、代言寫全、溢美之詞），參加綜藝又存在一定的可說明的價值或重要性，我主觀上認為有陳述和鏈接意義，對「構築百科全書網絡」也有幫助，有資料性價值，雖然時常踩在瑣碎資料或原創總結的門檻。

SpeXial影視作品顯然是WP:NOTIINFO了。「獨立列表條目」難道是非瑣碎資料、可供查證的「法外之地」？繼維基語錄、維基文庫後，建立維基履歷吧。^{[開玩笑的]}--YFdyh000（留言） 2022年10月13日 (四) 13:14 (UTC)

我本來的主張就是全數刪除，現在也是一樣。況且，共識雖然說可以建立列表，但是不代表就不需要遵守其他規定，仍然需要滿足WP:可供查證和Wikipedia:LIST等規定才能建立。--AT 2022年10月13日 (四) 14:31 (UTC)

來源方面好辦。然而WP:LISTD主要談的是篇幅，本來的標準就是篇幅太多又不能明確定義為瑣碎的東西，就可以分拆，但當非固定班底綜藝這種瑣碎內容容許分拆，那要如何理解？是不是某個藝人當了5個綜藝的一集嘉賓（假設都有新聞報道來源），篇幅太短，不能寫也不能作獨立列表，當他參加過的綜藝足夠多就可以作獨立列表了？怎樣才算足夠多？

另外，我的意見，組合的節目列表比個人的節目列表有意義，因人數多篇幅自然較多，也有助分析各成員的活動分佈。--Factrecordor（留言） 2022年10月16日 (日) 16:07 (UTC)

我隨便列的而已，WP:V還是需要遵守。幫忙找個例子是合規的幫我更新一下，確實不太恰當。--路西法人 2022年10月14日 (五) 01:12 (UTC)

已更新為少女時代影視作品列表。--CaryCheng（留言） 2022年10月14日 (五) 08:21 (UTC)

可，感謝Cary君，這個例子好多了。如果有需要的話歡迎更新該說明頁以更貼切反映方針指引要求。（該例子也是2020年末寫的了，那時剛入維不久大概率也沒想那麼多。--路西法人 2022年10月15日 (六) 03:12 (UTC)

重新明確藝人參與節目列表共識

過去和近期也曾有人提出過質疑指2016年討論達成共識不明確，我能理解他們的疑惑，該討論最終確實僅達成妥協共識；過去兩三年我根據該討論結果執行時，遇到的回退基本上都是不清楚規則或社群共識的新手，並未有巡查員、回退員或管理員提出質疑。故此，希望根據維護的經驗訂立更清晰的共識，以更好的規限此等過度詳細內容。以下是我的個人建議：

1. 演藝人員單次主持的大型節目或在一個時間跨度內固定參與（包括主持、代班主持及班底）的節目通常相對容易找到參與節目本身的影片以外的多條可靠來源支持：
   • 若節目本身具備關注度並存在條目，且條目中有包含主持人員變革的可靠來源，則直接連結節目條目即可，若可附註來源佐證加入和離任日期更佳；
   • 若節目本身可能具備關注度但未有建立條目，或並未符合關注度要求，則應當附註來源佐證參與節目及加入和離任的日期。
2. 演藝人員非固定參與（擔任飛行嘉賓）的節目屬於瑣碎資訊，尤其歌手或通告藝人可能會透過大量參與節目而獲取曝光。很多情況下都未必能有參與節目本身的影片以外的多條可靠來源支持，且並不對於有關人物構成足夠的影響或重要性從而被寫進條目中。若因參與節目而引起對人物事件的關注（如爭議），應當以摘要格式寫進條目內文中。
3. 若參演演藝作品佔篇幅過長，可分拆為獨立列表條目，但仍應遵從可供查證、非原創研究等方針。

以上供討論：@AT、YFdyh000、Factrecordor、CaryCheng。--路西法人 2022年10月18日 (二) 05:01 (UTC)

(＋)支持。--AT 2022年10月18日 (二) 23:37 (UTC)

(＋)支持。--CaryCheng（留言） 2022年10月19日 (三) 08:59 (UTC)

關於(2)算不算瑣碎資訊，沒有什麼既定看法。但有兩點想提一提。其一，按我的常識，縱使單次出席也並非「很多情況下都未必能有參與節目本身的影片以外的多條可靠來源支持」，反而是經常都有娛樂新聞報道（縱使並沒有特別事情發生過），當然也視乎那藝人有多紅，所以需釐清這裡對於「瑣碎」的判斷，是按其性質（例如單次出席）為主還是按來源的數量和深度為主。其二，單次出席大型活動、非固定參與節目，似乎本來是兩回事，據近來觀察，按過往共識嚴格執行刪除後者的人，也未必會去管前者。--Factrecordor（留言） 2022年10月19日 (三) 17:48 (UTC)

每集有不同嘉賓的節目，因應節目性質的不同，嘉賓角色在節目中的份量也可以相距很大，尤其訪談類節目，對於認識該嘉賓往往有很大作用。覺得還有一片空間介乎於(1)和(2)之間。--Factrecordor（留言） 2022年10月19日 (三) 18:16 (UTC)

「大型活動」意思是例如金鐘、金馬或跨年節目等大型節目（我應該是寫錯字了）。參與節目的收錄標準應是對於其本身有影響的（例如主持新節目），「認識該來賓」並非對演藝人員的重要性而僅是觀眾、粉絲的角度。維基百科不是宣傳工具，收錄的應該是普遍可公認對於傳主的身份有影響的內容而非「是否有助於讀者/觀眾認識」。至於是否瑣碎內容則應當是顯而易見的，一個人不可能同時主持20個節目，但可以在特定時期一口氣上20個不同的節目（例如宣傳期或通告藝人），每個節目的宣傳、訪談大同小異，顯然並不個別具備重要性的事件。WP:NOTDIARY也指出「例如名人和體育明星的新聞報道可能頻繁出現且涵蓋大量瑣事，但使用來源會導致條目過度詳細，看起來像本日記。不是每一場比賽、進球、或揮手都有足夠意義寫進人物傳記內。」正正清晰說明了不該「有來源就塞進去」這個道理，有來源之餘還得評量重要性。藝人作為嘉賓參與綜藝節目就有如球員參與單一賽事，而記錄作為班底參與則可類比為記錄參與一整季賽事，閣下可以依此比較一下根據方針的理解哪些適合收錄在條目之中。--路西法人 2022年10月20日 (四) 04:11 (UTC)

明白，不反對。--Factrecordor（留言） 2022年10月20日 (四) 13:22 (UTC)

我覺得不能解決爭議問題，是否從節目中發掘出獨家價值/信息，然後表格改寫為散文/備註，參演就變為值得保留。（雖然大多可能是一手或非獨立來源）。對身份有影響又包括何種影響，首次參加春晚的集體節目（配角/參演），首次成為大型品牌代言人，首次公布履歷或家庭或婚姻情況，首次回應爭議，首次以某某身份參演，或者僅限可靠來源介紹提及的可達標（可能十不存一），如果來源只提「某節目」那介紹節目名又是否得當。「是否有助於讀者/觀眾認識」不重要、「對於傳主的身份有影響的內容」重要，對於散文是沒錯的，但對於條目仍不可避免的列表/表格式陳列，可能損其完整性、編輯爭議頻發。--YFdyh000（留言） 2022年10月20日 (四) 13:48 (UTC)

先逐個例子回應：

• 「首次參加春晚的集體節目（配角/參演）」並不實際對於有關人員有長期的直接影響，演員上春晚唱個歌不會就因此成為了歌手（需要後續真的發歌才會真正改變身份），倒是主持幾乎是必然會被來源所提及的。單純的演出是否能當成其本人的「作品」我是不太認同。
• 「首次成為大型品牌代言人」離題，但有來源即可（雖然我是覺得有很濃烈的宣傳意味，畢竟不可能有人把「代言人」視為某藝人的主要身份之一）。
• 「首次公佈履歷或家庭或婚姻情況」「首次回應爭議」寫內文也頂多帶過節目名稱（來源有說就行），但同樣參演節目本身並不會改變藝人本身的身份（是其言論改變其本身，這個在什麼場合下都可能發生，是否參演節目無任何影響）。
• 「首次以某某身份參演」這個更離題了吧，現在沒在說規範參演影劇的列表？

列表不會因為是列表就不受WP:NOT規範，列表也是內文的一部分，固然應當受規範。當一個歌手每次發新歌或專輯的宣傳期上十餘個節目宣傳，發四首歌就上四十個節目了，音樂作品四項、參加節目四十項，到底他的正職是歌手還是通告藝人？就算是通告藝人好了，假設每個月上十幾二十次節目，一年就一百多項，又是否合理的收錄呢？足球員籃球員是不是每一項比賽都得紀錄呢？顯然不是。--路西法人 2022年10月21日 (五) 00:05 (UTC)

• 參加春晚等大型節目，對絕大多數藝人（同類參演小於3次），我覺得是值得提及列出的非瑣碎事項（大型集體節目可能除外），對其人生和生涯也不能說低價值。簡單以主持或固定參與判定瑣碎，我認為仍不完善，且「主持」未必是節目重點、重要角色。
• 有粉絲參與的藝人條目，廣告、代言等內容蠻多的，是否加入真不好說，我也覺得宣傳意味很濃、很多該清理，例子。主要是「參與節目的收錄標準應是對於其本身有影響」，粉絲加入代言內容顯然是認為對人物本身產生影響，但我覺得大多沒有，如此還是主觀判斷。其實「長期」、有知名度（獨立有效介紹）的代言或許更重要。
• 正文為求完整，經常是時間+節目名+內容，那麼同等內容的表格內容，是否就不算瑣碎。是否節目含有新披露的「值得記載」的內容，就是討論中的「對演藝人員的重要性」，這可能很模糊和廣泛。
• 某某身份，我細化一些，比如某些粉絲、新聞或傳記會稱，加入某公司後的首部作品/首次出演某類型/首次以某身份參與製作，種種。再比如，知名演員早年的非知名作品/跑龍套，是否均是瑣碎信息，但這有時存在有效介紹/對人物構成重要影響，是否有來源介紹就不瑣碎。

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

• 仍不能認同，收錄標準不應因為傳主本身的知名度或關注度而變化。每個知名的演藝人員總會經過不怎麽知名的時期然後才開始獲邀參與大型節目，以閣下認為適合的標準不就成了起初符合收錄條件，出名後年年獲邀出席就變得瑣碎不該收錄，然後就刪除了？「對其人生和生涯也不能說低價值」往往只是主觀的判斷，主觀地我認同新晉藝人獲邀進行專訪或參與大型節目對其本人具備重要性，但客觀而言實際仍不對其有影響。
• 同意僅應收錄長期並有可靠來源佐證的代言，這部分完全沒有異議。
• 不清楚您表達的什麼，如果正文出現列表式或排比式的「時間+節目名+內容」那麼不是WP:NOTDIARY規範的日記形式是什麼？
• 「加入某公司後的首部作品/首次出演某類型/首次以某身份參與製作」不是本次討論的重點，請分開討論。

--路西法人 2022年10月21日 (五) 04:10 (UTC)

出席央視春晚和日本紅白這類節目對於藝人在該地區的「地位」顯然具廣泛公認的指標作用，等同拿了一個不大不小的獎，與一般節目不能同日而語。我同意有特別價值的演出，應多以散文陳述而非列表。至於什麼節目地位特別高，每個地區每個界別（如戲曲、動畫歌手）也不同，難以具體羅列，倒不如舉出一些重要例子，其他可由「多個獨立可靠二手來源皆描述其特別價值」去詮釋。--Factrecordor（留言） 2022年10月21日 (五) 15:24 (UTC)

再講，參與單次大型活動，不論主持和一個環節的演出者，能短時間內參與多少個的可能性根本就差不多，而且演出者獲得的關注往往都比主持人高得多，我敢肯定「相對容易找到參與節目本身的影片以外的多條可靠來源支持」一定是演出者方面（一些名氣很低的除外）。在單次大型活動上偏向主持是非常怪的。--Factrecordor（留言） 2022年10月21日 (五) 15:56 (UTC)

需要注意維基百科不是宣揚特定觀點的地方，出席央視春晚和日本紅白這類節目對於藝人在該地區的「地位」顯然具廣泛公認的指標作用，但維基百科不應用作反映一個人的主觀「地位」（尤其藝能界沒有明確的「地位」界線，一切都是主觀認定的），沒上的也不代表沒名氣；此外散文內文的部分並非本次討論的重點，但其實若同類型過度瑣碎的出席節目內容寫在內文裡面（例如A'N'D的過往版本）任誰都應該同意讀起來像是日記。

我發現這一部分有一個問題是各地的大型節目的舉辦方式有明顯的差異。香港各台的大型節目幾乎往往都是總動員出席，給每個人都收錄下去我個人不認為有太大的意義，而典禮的表演嘉賓往往也是得獎者，收錄沒特大的意義。台灣的大型節目（基本上就是紅白藝能大賞）比較貼近比賽形式，或許可參考比賽參賽者的模式紀錄；三金（金馬金曲金鐘）則固然最重的是獲提名者及得獎者（但這個獎項段落已經有，重複紀錄是在多餘），其次反而是主持人的表現（例如剛剛昨天舉行的金鐘就是這樣情況），表演的來源反而相對不及主持人的來源。--路西法人 2022年10月22日 (六) 05:34 (UTC)

還是主張多集綜藝節目無必要與單次節目綑綁討論。可先處理好前者，後者宜此後另行討論，徵詢更多意見。

我嘗試搜尋「金鐘獎」或「金鐘獎主持」，新聞主要內容是得獎名單包括最佳主持人獎得獎者，至於是屆主持是誰，有的略有提及，有的根本沒提及。

當初討論多集綜藝節目的理由是主持不可能短時間內參與多個，一集嘉賓卻能短時間內參與很多個，以致個人條目內容冗長，上面我已說過在單次節目中主持和嘉賓出席節目的密集程度分別不會大，主持人數少、嘉賓人數多是另一個問題，它影響的是節目條目內容長度，能類比的是電影電視劇演員名單。另外，單次節目的數量是不是真的很密集？

我堅持某些節目具指標性意義。--Factrecordor（留言） 2022年10月22日 (六) 12:05 (UTC)

可，我稍後處理。--路西法人 2022年10月22日 (六) 14:04 (UTC)

同意分開處理。

單次大型節目的表演和主持有不少值得收錄，誰誰上過春晚、紅白經常是說一輩子的事。英維上不少特色列表都收錄了歌手在Grammy表演的資料，正文也會提及。

多集綜藝有一些也有收錄的價值，如Saturday Night Live上的表演往往引起長時間討論，成為表演者生涯中的重要事件。--Benevolen（留言） 2022年11月7日 (一) 21:41 (UTC)

補充一下關於「按過往共識嚴格執行刪除後者的人，也未必會去管前者」，確實，但這次是等於重新訂立共識，有加減也並非不妥，合理即可。--路西法人 2022年10月20日 (四) 04:12 (UTC)

這意味清理範圍顯著加大，似乎應徵詢多些常編輯藝人條目的朋友。--Factrecordor（留言） 2022年10月20日 (四) 13:25 (UTC)

我個人過去清理的時候僅以來賓身份參與大型節目的項目也都給刪掉，反正本來就不符合「固定參與或主持」這一部分。是否真的擴大了範圍我不敢說。--路西法人 2022年10月20日 (四) 13:37 (UTC)

我覺得大膽清理就好，如果清理有問題，就請他簡單說明一下為何需要保留即可，我相信如果真的是具有足夠重要性的事件或者主持，清理的維基人一看解釋就知道這可以保留了，根據過往經驗比較常碰到的是為保留而保留的理由，我認為這才是後續清理比較會遇到的問題。--~~Sid~~ 2022年10月22日 (六) 14:20 (UTC)

我覺得可能需要WP:RSN那種集中討論和列明標準的地方，不然就是主張刪除和主張保留者在互列觀點證據嘗試說服對方（或者編輯戰/放棄），而其他參與者不了解有討論發生、無法感知標準。用客棧討論也可以，但似乎容易話題變寬而最終無結論。--YFdyh000（留言） 2022年10月22日 (六) 18:54 (UTC)

(＋)支持。--~~Sid~~ 2022年10月22日 (六) 14:13 (UTC)

(？)疑問除了影片外沒有其他可靠來源的情況下，如何判斷第2點中有關人物構成足夠的影響或重要性；按照個人了解，中國內地的綜藝節目難以找到可靠來源，能否提供判斷標準，謝謝。--Abcet10（留言） 2022年10月28日 (五) 16:35 (UTC)

綜藝節目方面現在提出的就是「不是主持、班底就不收錄」，我不清楚會不會連主持、班底都沒有來源，但擔任來賓有沒有來源也不是應該收進去就是了。--路西法人 2022年10月30日 (日) 01:42 (UTC)

我覺得無論是什麼類型的活動也好，能得到節目/活動以外的多條可靠來源支持都不是很容易。那假如有很多可靠來源說這件事，說明此事很有可能不是垃圾內容。從另一個方面看，能以摘要方式寫進內容的應該也可以寫進表格就是了。所以嘛，我認為說如果非固定參與（擔任飛行嘉賓）的節目可以得到節目本身的影片以外的多條可靠來源支持，抄進表裏也應該可以的。反是內容代言應該提一下，沒有第三方來源說明的就不應該收錄，不然就成了宣傳某公司的內容了。--Ghren🐦🕒 2022年10月30日 (日) 07:35 (UTC)

似乎各個地方有差異。上面提到中國大陸很難找到獨立可靠來源，以有來源為標準的話數量不會太多。但是香港我印象中每集嘉賓的報道不少。還有就是略帶一提名字算不算呢？要用上有效介紹概念？--Factrecordor（留言） 2022年11月7日 (一) 17:26 (UTC)

我覺得略帶名字的不算。--Ghren🐦🕛 2022年11月25日 (五) 04:04 (UTC)

WP:NOTDIARY清晰指出「即使個體值得關注，並非所有涉及的事件都是如此。例如名人和體育明星的新聞報道可能頻繁出現且涵蓋大量瑣事，但使用來源會導致條目過度詳細，看起來像本日記。」凡是若是有來源提及就寫進條目，那麼所有主要的條目都大概率會非常臃腫冗餘。現在主要不是有沒有來源之談，而是是否對於有關個體來說是瑣碎內容的問題。個別單次參與綜藝節目顯然在大部分情況下並非對於名人有明顯的關聯或影響。大型節目尚且不談，歌手、演員等去一般的綜藝遊戲節目或訪談作宣傳可以一段時間內上很多然後一段時間完全一個都不上，對於藝人來源顯然不具有任何顯著的重要性。上面有些用戶及過往交集過的用戶提到過訪談節目是否對於藝人有所影響，我並不認為上訪談節目本身具有重要性，具有關注度的是裏面所談到的內容，若有關注度自然有報道，也同樣自然可寫進條目內文中。若一個老演員老歌手出道數十年，上過的節目達數百條，是否應當全數列出？我們應當訂立的標準是不論是老藝人新生代都能適用的標準，不是剛出道就統統「對他有意義」，出名後就變成瑣碎資料那樣。--路西法人 2022年11月17日 (四) 03:02 (UTC)

• 「個別單次參與綜藝節目顯然在大部分情況下並非對於名人有明顯的關聯或影響。」是「顯然」的，我想這是整個討論的出發點——所以就說了要多條來源支持。
• 「上訪談節目本身具有重要性」：是的。「具有關注度的是裏面所談到的內容」：是的。「若有關注度自然有報道，也同樣自然可寫進條目內文中。」不是。比如徐向前這種條目，年譜幾百頁厚，有好幾本為他寫的傳記，那是不是代表那幾本傳記寫的內容都可以寫進來正文中？不是。一樣有可能有WP:NOTDIARY的情況。「若一個老演員老歌手出道數十年，上過的節目達數百條，是否應當全數列出？」不是。將所有有多條來源支持的單個節目/活動乃至非固定參與寫進出也一樣有可能是瑣碎資料。我只是認為，沒有「多條可靠來源」支持的，極大可能是瑣碎資料而已。我只是認為不直接認定演藝人員非固定參與（擔任飛行嘉賓）的節目屬於瑣碎資訊而已。而且「若因參與節目而引起對人物事件的關注」這種東西假如不是指什麼社會層面上的爭議的話，其實也不是很難達到。這寫進條目也是不太合理的，那倒不如寫進列表。

--Ghren🐦🕛 2022年11月25日 (五) 04:27 (UTC)

(＋)支持。--桃花影落飛神劍（留言） 2022年11月3日 (四) 06:18 (UTC)

既然都挖了2016年的留言，要不順便把當事人也叫來，不然又被說是小圈圈討論，不具效力。@Datou 1996、Softyu、Taiwanno1best、Joshua_Zhan、Light0113、Gqqnb、Liaon98：。 --窩法乙烷 兒法夢碎 2022年11月6日 (日) 03:09 (UTC)

@Zhu2005125、Punkhippie、TodayIs2019：另外也ping一下韓圈人。 --窩法乙烷 兒法夢碎 2022年11月6日 (日) 03:12 (UTC)

@LuciferianThomas：想請問一下若能得出共識，將修改哪一些方針與指引？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年11月16日 (三) 18:00 (UTC)

不需額外修改方針指引，僅是重新確立過往討論共識和確認WP:NOTDIARY等的執行細節而已。--路西法人 2022年11月17日 (四) 03:03 (UTC)

---

1. 演藝人員單次主持的大型節目或在一個時間跨度內固定參與（包括主持、代班主持及班底）的節目通常相對容易找到參與節目本身的影片以外的多條可靠來源支持：
   • 若節目本身具備關注度並存在條目，且條目中有包含主持人員變革的可靠來源，則直接連結節目條目即可，若可附註來源佐證加入和離任日期更佳；
   • 若節目本身可能具備關注度但未有建立條目，或並未符合關注度要求，則應當附註來源佐證參與節目及加入和離任的日期。
2. 演藝人員非固定參與（擔任飛行嘉賓）的節目屬於瑣碎資訊，尤其歌手或通告藝人可能會透過大量參與節目而獲取曝光。很多情況下都未必能有參與節目本身的影片以外的多條可靠來源支持，且並不對於有關人物構成足夠的影響或重要性從而被寫進條目中。若因參與節目而引起對人物事件的關注（如爭議），應當以摘要格式寫進條目內文中。
3. 若參演演藝作品佔篇幅過長，可分拆為獨立列表條目，但仍應遵從可供查證、非原創研究等方針。

由於已經數週無額外意見且反對意見已處理， 公示7日，2022年12月2日 (五) 02:12 (UTC) 結束，公示內容如上；無需寫入方針指引，僅為明確WP:NOTDIARY等方針指引的執行共識。--路西法人 2022年11月25日 (五) 02:12 (UTC)

建議建立{{輔助說明}}頁。--Xiplus#Talk 2022年11月25日 (五) 03:15 (UTC)

可，但模板恐怕不合適吧，該模板「此頁是一篇論述，內容代表編者們的意見，因此內容僅供參考」一句不能反映共識地位。--路西法人 2022年11月25日 (五) 03:24 (UTC)

更高層級應該就到指引了，不考慮立為指引嗎？--Xiplus#Talk 2022年11月25日 (五) 04:24 (UTC)

我傾向用WP:CC19的{{infopage}}。--路西法人 2022年11月25日 (五) 06:07 (UTC)

WP:格式手冊有關百分數等的格式問題

現行條文 在反映一個具體數量時，國際計量局建議在阿拉伯數字與計量單位字母符號之間插入一個半角空格（例：0.1 cm、23 kg、45 °C、67 %），度分秒除外（例：89°、12′、3″）。

提議條文 在反映一個具體數量時，國際計量局建議在阿拉伯數字與計量單位字母符號之間插入一個半角空格（例：0.1 cm、23 kg、45 °C）。惟須注意百分數、角度、弧度、梯度等無量綱，不適用該條（例：67%、89°12′3″、$2\pi$、$0^{g}$），但弧度使用rad表記時除外（例：1 rad）。

現行條文對百分數的處理與常見用法不符，亦不合en:MOS:PERCENT；同時，弧度、梯度的情形需要補充。 --DvXg 📬 2022年10月15日 (六) 08:07 (UTC)

用明朝劍斬清朝官是不是搞錯什麼，英維不適用中維，而內文寫道「建議」並非強制執行。 --窩法乙烷 兒法夢碎 2022年10月15日 (六) 15:02 (UTC)

提及英維是因為西文是百分數如此表記的借入來源。如果這種建議既不合外語借入來源，也找不到相關的本語種標準，更不反映站內實際的使用情況（如百分數這個條目本身），那麼這樣的所謂「建議」顯然是需要被修正的，否則任何誤植的條文都可以用這一條辯護了。--DvXg 📬 2022年10月15日 (六) 15:19 (UTC)

如果您非要為這一條辯護的話，請自君始（您的用戶頁所上用的框就不符合這一規定）。--DvXg 📬 2022年10月15日 (六) 15:21 (UTC)

常見用法無異議、參考英維標準無異議。但是，應該查一下依據的標準和當初討論。台灣國際單位制手冊第 9 版 (2019)第39頁稱「國際公認的符號%(百分比)可以與 SI 一起使用。使用時，應有一空格分隔數字和符號 %。」。The International System of Units (SI) - BIPM第37頁為相同表述，"The internationally recognized symbol % (percent) may be used with the SI. When it is used, a space separates the number and the symbol %."，應是此項來源。en:Percent sign#Correct_style則詳細提到了各語言常用的不同間隔風格。我覺得可以討論條文是否要參照英文，依中文的實際情況和常見用法，允許或建議通常使用不符合該國際標準的規範，信息框、學術條目等領域又是否要例外。中國大陸的規範待查。--YFdyh000（留言） 2022年10月15日 (六) 15:43 (UTC)

感謝補充國際單位制的有關條文，不過台版標準第42頁（PDF第46頁）的「(10±0.01)%」像是自身亦不符本標準。另外，百分數本身並不由國際單位制定義，在數學教學中一般也不將其視作單位（如99%通常視若同0.99的數，惟更強調由比例導出）。

在數字排版領域，W3C起草中的《中文排版需求》內文實際使用的是無空格樣式，其參考的已發布標準《日語排版需求》的3.1.10條e項則明確百分號前不加空格且不可斷行，可做參考。--DvXg 📬 2022年10月15日 (六) 16:00 (UTC)

• 台版標準第42頁（PDF第46頁）的標題是"第 1 屆 CGPM，1889 年"，段落是"考量"。
• 現行條文寫得很明確，跟計量單位（SI）字母符號並用時加空格，麻煩請先點內連去看這是哪七種計量單位。這個段落只是在講 SI，所以引用的是 The International System of Units (SI) - BIPM，而 % 會被一併納入是因為這個條文寫的就是"跟計量單位（SI）字母符號並用時"（條文內文），而 % 是可以跟 SI 併用，這個時候 % 前面要加空格（symbol % (percent) may be used with the SI ... a space separates the number and the symbol %）。
• 你想要一個跟 SI 無涉，針對無量綱採用空格的說明，建議另開一條，不要併在 SI 那條裡面混雜，這樣既不符合 SI 對於空格的使用規定，也讓人搞不清楚該條目是不是專門在講 SI 的空格使用。

--Anghualee（留言） 2022年10月16日 (日) 05:25 (UTC)

• 不明白第一項是什麼意思，引文也應該遵循排版要求。不過我認同國際單位制的要求的確如現行。
• 現行條文並未明確「並用」，界定「並用」也缺少明確界限。這條提議算是要替代而非增補這條實際上（de facto）並未完全被中文（乃至CJK）接納的關於百分號的國際計量局規定：在數字排版領域的可參考標準中，《日語排版需求》的3.1.10條e項明確百分號前不加空格，而緊隨的f項就給出了「75.123 4 kg」的例子。原條文中的「在反映一個具體數量時」是具有一定排他性的，即使要另開一條也需要改動既有的這一條，當然（如果能夠達成這樣的共識）是需要再修訂草稿，改變條文中指定的上游標準的。
• 原條文使用百分號的方式，在維基的環境中大約只有計算式的情形下會用到（如計算熱機效率$\eta ={\frac {10\ \mathrm {W} }{20\ \mathrm {W} }}=50\ \%$）。可以考慮在正文（遵循數字排版規則）和公式（遵循國際單位制要求）環境下作不同的規定。

--DvXg 📬 2022年10月16日 (日) 07:48 (UTC)

• 那是一個 quote，基本上就是照搬，不會為了刻意符合現代呈現標準去調整他，簡單來說就是不要去糾結46頁不符合，沒意義。
• 請問 % 是哪種 SI？這屬於有讀內連就懂。W3C 標準跟 SI 標準有什麼關係？為什麼針對 SI 的論述你要拿 W3C 標準來作依據？
  • 另開一條的部分你誤解了。
  • （好比說原條文是在這個星號）"在反映一個具...除外（例：89°、12′、3″）。"
  • （<- 換行打個星號以後，這邊放你的另開一條）
• 你當然可以根據實際狀況調整你想要的條文形式，我對此並無意見。

--Anghualee（留言） 2022年10月17日 (一) 06:58 (UTC)

引用W3C標準是因為格式手冊提及關於數字與符號配合使用的規定只此一處，抱歉可能因為提案中沒有改動上游標準的引用造成了誤解。我對您對SI標準的解釋並沒有異議，只是 (1) 站內外的實際使用都更接近W3C標準；(2) W3C標準更綜合，其面向數字排版的特點也更適合維基作為網站的格式手冊引用。我明白現在的提案還需要更改，但是希望能在再一次修改提案之前先收集對「是否應當明確一般正文中百分號使用時無前導空格」這一點的意見。目前提案修改的大略想法是 (1) 替換原條文，引用W3C標準指引正文格式；(2) 將國際單位制的「並用」適用於公式環境，明確其與W3C標準在百分號運用上的不同。--DvXg 📬 2022年10月17日 (一) 17:32 (UTC)

W3C起草中的《中文排版需求》，首先他還只是個 draft。其次他的作用是什麼呢？根據目的裡面講的"作為實現這個責任的基礎，本文整理了中文（漢字）書寫系統在排版上的需求。一方面說明需求事項以明確描述中文排版之需求與問題；另一方面也提供與既有標準（如Unicode）的對應，冀求透過本文有效地促進實作。"簡單來說，如果你在排版上有特定的要求，比如說你想要直書，而非我們現在維基百科使用的橫書，那他就會把這個需求列到排版需求中，來去看看網頁標準怎樣可以達到這樣的需求。你哪怕引用NIST標準去支持加空格，或者引用芝加哥格式去支持不加空格，我都沒有意見。但是你引用《中文排版需求》，然後說 % 前面加不加空格怎樣。我直接問一句，請問加不加空格按一個空白鍵處理的這個事情，在網頁排版上是有什麼困難之處，需要什麼技術攻克，以致於到會需要寫到排版需求裡面去呢？除非你想用的是不斷行空白，那也頂多就是找 Unicode 的不斷行空白，不是嗎。當然你也可能想說你並不是引用 W3C 標準，只是用其中用到 % 的情況當作例子。而在排版需求的討論中貢獻者 kecrily 提到的"如 CSS 和 UI 設計中，普遍不加空格"就解釋了這個情況，因為排版需求中大部分是處理 CSS 和 UI 設計，對吧？--Anghualee（留言） 2022年10月18日 (二) 08:39 (UTC)

不對，您可能對《中文排版需求》所面向的領域有所誤解。雖然這份標準由W3C旗下的興趣組編寫，但它所希望面向的對象是所有基於Unicode的數字排印，包括書籍印刷（如Adobe InDesign）、廣告印刷（如Adobe Illustrator）、數字出版（如EPUB）等等，而非限於網頁或者應用程序。其前輩《日語排版需求》，也是對JIS X 4051（日本語組版規則）標準的明確、細化與引導。雖然其對術語的使用有注意與CSS標準的相容性，但整篇標準事實上沒有一處提到CSS、沒有提到某項需求應當使用哪個CSS屬性去實現，而是在總結中文排印的標準（事實上只有標點符號的使用部分有較為明確的明文標準）與常規。您說的

簡單來說，如果你在排版上有特定的要求，比如說你想要直書，而非我們現在維基百科使用的橫書，那他就會把這個需求列到排版需求中，來去看看網頁標準怎樣可以達到這樣的需求。

這一點完全是不正確的，這篇標準的「需求」是對中文排印既有的實踐的總結，而不涉及由誰實現、如何實現、在哪裡實現。最明顯的一處是，3.5節「行內調整」幾乎所有的內容都無法用已經大致穩定、有實際瀏覽器實現的CSS屬性實現，反而是同樣草案中的CSS Text Module Level 4還在等待《中文排版需求》完成相關條文一併交由瀏覽器廠商參考。您在這個問題上完全顛倒了需求和實現（CSS）的關係。--DvXg 📬 2022年10月18日 (二) 09:44 (UTC)

上面那一段解釋了我為什麼要提問"W3C 標準跟 SI 標準有什麼關係？為什麼針對 SI 的論述你要拿 W3C 標準來作依據？"因為白話來講就是沒有關係，不該作為依據。接下來對於你提到的"更接近W3C標準"、"W3C標準更綜合"云云，他當然綜合，他把所有中文排版在網頁技術上遭遇到的困難都列出來說明可以怎麼達到，或者以後要怎麼促進實作去達到。他就是一個需求整理，一個當你排不出排版的時候，你可以去翻查對照到有什麼技術可以幫助你達成那種排版，並不是一個告訴你應該用什麼排版的標準。用維基百科來比喻的話，就是 Help 命名空間中某個列出所有模板然後跟你說什麼情況可以用什麼模板去解決的教學，不代表你在寫條目的時候就要用上該 Help 的所有模板，或者是裡面有講示亡號可以用 box 模板，就錯誤地跑去每個已逝人名加 box 模板，這種文件不是這樣運作的。--Anghualee（留言） 2022年10月18日 (二) 09:01 (UTC)

續上，您說的「網頁技術上」不實，整篇標準通篇沒有說是僅面向網頁排版，興趣小組掛在W3C名下並不能說明這是網頁專用的，其編寫目的也有填補中文排印標準的空白的考慮，而非僅限於中文網頁排版標準。我當然知道這篇標準不是像芝加哥格式手冊一樣涉及語法、大小寫一類細則、對應維基MoS的格式手冊，但「此處是否加空格」這個問題不同於大小寫，它和「此處是否可以斷行」這個問題結合得相當緊密，後者則是一個排印問題，這也是我引用這項標準的原因。當然，我也同意加入西文的既有格式手冊作為參考能更有說服力，但我不同意您對《中文排版需求》乃至《日語排版需求》與格式手冊的空格問題完全無關的論斷。--DvXg 📬 2022年10月18日 (二) 09:58 (UTC)

對我來說就是挑一個領域（例如網頁技術）舉完例子就好了，我沒有打算窮舉的意思，因為這樣既容易失焦，也容易搞不清楚我們在討論的問題是什麼。好比說我認為這並不是適用於我們現在在討論的維基編輯應該在原始碼編輯（我知道有其他如視覺化編輯方式，但是我不會提，因為對於討論沒有幫助）中 % 前面要加空格還是不加空格。而請問一下你在努力把書籍、廣告、數字印刷都拉進來，然後在最後面還補上"相關條文一併交由瀏覽器廠商參考"的例子，你有注意到你講的東西完完全全佐證了這就不是給使用者必須採納哪種排版（例如橫書、直書的挑選），而是讓廠商去了解有這些排版需求，讓他們實作出相關細節，當使用者要這樣排（且這種需求是有所本，例如裡面說這個是標點符號用法的規定、那個是輕小說在用，的時候），就可以透過廠商的實作來排出這樣的排版。所以在你窮舉領域以後，問題還是一樣啊：「請問加不加空格按一個空白鍵處理的這個事情，在網頁排版（甚至是你提到的書籍、廣告、數字印刷中）上是有什麼困難之處，需要什麼技術攻克（如你所說需要"相關條文一併交由瀏覽器廠商參考"），以致於到會需要寫到排版需求裡面去呢？」--Anghualee（留言） 2022年10月18日 (二) 21:48 (UTC)

"此處是否可以斷行"當然是一個問題，不然我也不會拋出來"除非你想用的是不斷行空白"，這在我前面貼過的討論中也提到"Latex ... U+202F"、"IEEE 的標準里也有些單位與數值間用的是 U+00A0"，但即便該 issue 已關閉，你有看到 Draft 中有多出任何應使用 U+202F、U+00A0 的條文嗎？可以拜託你，哪怕去那個 issue 裡面看到哪些標準，英國出的《Writing for Home Office Science 》、IEEE 的標準，甚至是上面你自己貼內連得芝加哥格式，抓哪個出來用都可以，因為這些都是要求作者去遵循的格式標準，都塞子彈給你了，為什麼你就是要糾結在一個不適合的引據上糾纏不清呢？--Anghualee（留言） 2022年10月18日 (二) 22:02 (UTC)

我同意用格式手冊做引據啊，第一條留言我就引用了英維的MoS，要換成上游「一手的」手冊我當然也沒有意見，但是終歸還是需要一個搭得上邊的中文的（或者CJK的）標準做補充「中文確實有在這麼用」啊。--DvXg 📬 2022年10月19日 (三) 04:55 (UTC)

從一開始我就直接打算對標英維的MoS為準，有人異議我才拉了CLREQ出來做論據，為什麼您一直覺得是我非要拉這個做標準？至於用哪個Unicode碼位做空格原條文和提案都沒有涉及啊，如果想明確用{{nowrap}}還是 阻止斷行，這是要補充另一項條文了罷。--DvXg 📬 2022年10月19日 (三) 05:02 (UTC)

我誤解我詢問"你在為什麼針對 SI 的論述你要拿 W3C 標準來作依據？"之後您對於 CLREQ 的說明是在強調該理據是有依據的，是我過多於糾結在旁支上了。至於要找跟中文搭得上邊的標準，台灣的標準與檢驗期刊中國際標準對SI單位之書寫建議和經濟部標準檢驗局法定度量衡單位使用指南，以及國家標準草案構成及格式指引前面有提到一些 CNS 標準，本身也有一些撰寫標準，你看看用不用得上。不斷行的議題也是在這些旁支討論中延伸冒出來的，若確定要加空格，有需要可以再另案討論或覺得合適的話就對這個部分補充。--Anghualee（留言） 2022年10月20日 (四) 00:14 (UTC)

42頁的考量與前文的關係？不太懂「跟計量單位（SI）字母符號並用」概念，國際單位制計量單位如何與百分比符號共用。--YFdyh000（留言） 2022年10月16日 (日) 09:34 (UTC)

顯然原文之「89°、12′、3″」指的是不用「89 °」、「12 ′」、「3 ″」，而非指合作為「89°12′3″」。另外，百分比是數學符號而非計量單位（一百分之六十七不就是〇・六七嗎？），本來就不受相關規則約束，也因此無需另行規定例外。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年10月16日 (日) 12:46 (UTC)

啊，這處改動就是為了表示度分秒連寫時不分開，您覺得這種格式不正確麼？另外我確實認為百分比不是單位，但先行條文將其列出了，改為作為易於混淆的概念做出提示可能也是有必要的。--DvXg 📬 2022年10月16日 (日) 13:11 (UTC)

我覺得原文不是這個意思，當然連寫的時候確實也是不分開的。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年10月17日 (一) 05:23 (UTC)

這處算是想要利用舉例來間接明確更多格式上的要求吧，要明文明確也可以？另外，也許應當在MOS:DATENUM明確分和秒應使用Unicode的專用碼位，不應使用西文引號代替？--DvXg 📬 2022年10月17日 (一) 17:37 (UTC)

(＆)建議用JavaScript或服務器後端解決，不管在源代碼里輸入32cm還是32 cm，都自動呈現成合適的樣子。至於合適的樣子是什麼，可以另外討論。--Gqqnb（留言） 2022年10月23日 (日) 09:11 (UTC)

如何達到條文要求屬於implementation的範疇，不在方針討論之列。MoS恰恰是要討論什麼是「合適的樣子」。--DvXg 📬 2022年10月24日 (一) 09:36 (UTC)

修訂提案

現行條文 在反映一個具體數量時，國際計量局建議在阿拉伯數字與計量單位字母符號之間插入一個半角空格（例：0.1 cm、23 kg、45 °C、67 %），度分秒除外（例：89°、12′、3″）。

提議條文 在使用帶有單位的數字時，阿拉伯數字與計量單位字母符號中應插入一個空格建議在阿拉伯數字與計量單位字母符號間插入一個空格（例：0.1 cm、23 kg、45 °C、90 deg、1 rad）。 角度、弧度、梯度等單位不使用西文單詞縮寫符號時，不應插入空格（例：89°、$2\pi$、$0^{g}$），度分秒之間連寫時亦無空格（例：89°12′3″）。 在一般的半角空格的基礎上，推薦在此情形下使用不間斷空格（ ），公式中亦可按LaTeX習慣使用窄不間斷空格（\,）。 特別地，百分數具有兩種通行格式： 據《芝加哥格式手冊》及中文正文排版實際，百分數的百分號前無空格（例：50%）； 國際計量局的標準建議，當百分數與國際單位制單位並用時，百分號前應插入空格（例：質量分率$\omega _{B}=50\,\%$）。

根據意見進行了一部分修訂，部分細則也許可以參照英維移入Wikipedia:格式手冊/日期和數字並加以擴充？DvXg 📬 2022年10月29日 (六) 10:57 (UTC)

(－)反對，這是要有間隔，而不是要有空格。這應該是技術層面去解決的問題--百無一用是書生 (☎) 2022年11月2日 (三) 02:58 (UTC)

所有的西文和中文標準來源都用的是空格（space character而非spacing），您提出只是用間隔的依據是什麼呢？況且我的提案反而是收窄了空格的使用範圍。

中文和西文之間的間隔不用空格，是因為有相關的排版特性支持（Word的「自動調整中文和西文的間距」、CSS在實現中的text-spacing等等），而單位前的間隔據我所知沒有任何一個排版特性支持，並且也不可能在沒有語義支持的情況下完成（排版引擎如何分辨長度「100 m」和帶後綴的編號「100m」？）。如果是想藉由模板完成的話，一是LaTeX的包siunitx最終實現也還是落到了空格，二是這對中維翻譯條目的所有編者全篇改用模板也不現實，三是想要通過CSS的padding或margin實現的話是會影響行首行尾的正常排版的，不知道您中意的不用空格字符的解決方案是什麼？--DvXg 📬 2022年11月2日 (三) 04:54 (UTC)

根據等效採用國際標準ISO1000：1992《SI單位及其倍數單位和一些其他單位的應用推薦》的GB 3100-1993《國際單位制及其應用》，其中也只建議數值與符號之間保留適當空隙，而未要求加空格。而從日常工作和中文期刊中遇到的書寫要求經驗來看，也未見有要求加空格的--百無一用是書生 (☎) 2022年11月3日 (四) 02:31 (UTC)

中文物理期刊確是普遍加空格的：物理學報、光學學報。贊同David Xuang君所言，單位前的空隙不像中西文間的間隔一樣易於自動實現，加空格是實現標準所要求的「空隙」的最自然手段。--Lt2818（留言） 2022年11月3日 (四) 04:26 (UTC)

看了物理學報的投稿模板，並未要求加空格，而且發表的文章中（至少你提供的這篇）也是有時加有時不加。另我又看了一下《化學進展》的投稿模板，也未要求加空格，而且模板中自己也是有的有空格，有的沒有。我認為中文出版物的這個現象可能是受英文出版的影響，但中文本身並無規定和習慣（至少在我的經驗中都是不加空格的）；也可能是不同領域的學術習慣問題導致--百無一用是書生 (☎) 2022年11月3日 (四) 08:45 (UTC)

相反，我認為有時不加空格恰恰是母語為漢語的人習慣性的忽略單詞間的空格，日常對話中即使在連用兩個外來西文詞的時候，人們也常常忘記中間的空格。私以為這裡加空格的原因在於：阿拉伯數字作為語法上的數詞，而單位縮寫則是語法上的量詞，兩個語法成分不同的詞自然不是一個詞；數字的文種雖然「中性」，單位縮寫則明顯是西文，兩者連用應視同插入的西文；那麼，中文中插入的西文自然應當適用西文的書寫規則。--DvXg 📬 2022年11月3日 (四) 14:17 (UTC)

兩篇論文中，我看到的計量單位字母前都是有空格的，不知是否有遺漏的情況。《化學進展》的投稿模板里有空格和無空格都有出現（「8 cm×5 cm 以內」「寬度不超過8cm」），或許模板本身並不嚴謹，不及出版的論文成品有說服力。--Lt2818（留言） 2022年11月4日 (五) 05:35 (UTC)

(▲)同上--YFdyh000（留言） 2022年11月3日 (四) 04:30 (UTC)

這就是我之前問的最後一個問題啊，空格也好padding、spacing也罷，您鍾意的實現方案到底是什麼呢？--DvXg 📬 2022年11月3日 (四) 14:19 (UTC)

關於「反而是收窄了」，現行條文「國際計量局建議」，新條文「應插入」，語氣是強化了。建議維持建議級別。--YFdyh000（留言） 2022年11月3日 (四) 03:19 (UTC)

完成，改動比較小，就直接用刪除線改掉了。DvXg 📬 2022年11月3日 (四) 14:22 (UTC)

對「百分號前應插入空格」有異議。以例子中的「質量分數」搜索到這篇論文，未見百分號前有空格者。標準中的規定看似未被普遍遵守，我覺得沒有寫入格式手冊的必要。簡單處理的話，把百分號直接從條文中刪除即可。--Lt2818（留言） 2022年11月4日 (五) 05:35 (UTC)

大陸GB 3100未見百分號相關規定，而之前討論中有用戶找到的台灣政府標準沿用了這條SI的規定，大概可以找找台灣的學術論文，或者是政府標準（比如計量、環境監測相關的）？--DvXg 📬 2022年11月4日 (五) 05:47 (UTC)

如果最後沒有地區普遍使用的話，那麼支持將百分號直接併入度分秒比照處理或者可以直接限定在非中文環境（公式）適用？--DvXg 📬 2022年11月4日 (五) 05:48 (UTC)

以「質量分率」為關鍵詞搜索台灣的論文，一篇混雜無定章，另一篇只在圖內出現百分號前空格，圖外則百分號前無空格。--Lt2818（留言） 2022年11月5日 (六) 06:40 (UTC)

您有什麼想法麼？除了公式內應該還需要沿用SI格式之外，我不太確定其他地方是不是就完全不用了。--DvXg 📬 2022年11月8日 (二) 15:57 (UTC)

(－)反對：持續在最終方針文字定案內容中夾雜沒必要加入方針的外部草稿文件作為案例，隱示或暗示W3C標準建議該做法，或使用類似方式為符合W3C標準的做法。--Anghualee（留言） 2022年11月4日 (五) 09:16 (UTC)

……那麼中文排版的實踐情況用什麼引證呢，還是說條文內此處不言自明不需要引證呢。--DvXg 📬 2022年11月4日 (五) 14:20 (UTC)

另外反對「持續」的說法：這明明才是第二稿，而這處引證是第一稿這一點被人質疑之後才加進去的，之前你在意見中只表達了「這不是對應領域的標準」而不是「此文件不能作為對既有中文排版實踐的參考」，這裡也確實只是作事實參考而非標準引用，「持續在定案內容中」明顯不實。要是只是不想把這個插進引用、只需要有討論存檔作參考那就直接提出來，不要這樣虛增一頂「持續忽略其他用戶意見」的大帽子。--DvXg 📬 2022年11月4日 (五) 14:31 (UTC)

另外，順便再回應一下您之前提供的幾份標準鏈接：這裡存在的問題是缺「一般情形下中文對百分號的使用」的參考，而非「在SI體系下使用百分號」的參考，兩者對百分號的處理事實上就是不一致的。您提供再多計量、技術寫作方面的標準，也都只是SI標準的延伸。而百分號並不只在度量衡體系下使用，其最常見的應用——增長率，並不與SI所定義的物理量相綁定：人口增長率的單位「人」、經濟增長率的單位「不變價美元」，都和SI的單位體系沒有關係，這裡需要的是中文傳統出版、新聞傳媒領域的相關標準（就像AP和NYT的格式手冊）。--DvXg 📬 2022年11月4日 (五) 14:50 (UTC)

Lt2818方案

我提個修改方案吧，條文在Wikipedia:格式手冊#空格。

現行條文 在中文語境內，文字之間應該不留空格，惟仍有特例： …… 在反映一個具體數量時，國際計量局建議在阿拉伯數字與計量單位字母符號之間插入一個半角空格（例：0.1 cm、23 kg、45 °C、67 %），度分秒除外（例：89°、12′、3″）。 ……

提議條文 在中文語境內，文字之間應該不留空格，惟仍有特例： …… 在反映一個具體數量時，建議在阿拉伯數字與計量單位字母符號之間插入一個空格（例：0.1 cm、23 kg、45 °C、1 rad），但度分秒（例：89°12′3″）、百分度（例：100g）之類符號除外。建議使用不換行空格（ ）以禁止在該處換行。 ……

說明如下：

• 刪除「國際計量局」字樣，其規範有未被普遍遵守的情況，格式手冊不必與之掛鉤。其他外部規範也同樣不必寫入。
  • 百分號就是個例子，百分號前是否加空格沒有共識，公式內亦然，因此從條文中刪除了百分號。
• 「半角」指的是寬度，由於更窄的空格亦可接受（如前一提案提到了「窄不間斷空格」），故而刪去。
  • 從Help:數學公式可見LaTeX中使用「窄不間斷空格」的場景遠不止計量單位。如果要講公式的話，另行單獨敘述可能更合適，這裡就不加了。
• 前一提案中的deg似乎不是中文裡規範或普遍使用的單位（與rad不同），沒有寫入。
• 前一提案中「不使用西文單詞縮寫符號」的總括有些問題，百分度^g也可以說是西文單詞縮寫符號。我就用「……之類符號」代指了，沒想到更好的總括短語。
• 度分秒雖然不是「字母符號」，但有必要體現出和前半句例子中「45 °C」的差別，不宜刪去。
  • 從89°12′3″的連寫足以推出三種符號單用時的寫法，不必贅述。
• 行文字眼從「推薦」到「建議」，語氣從強到弱。

--Lt2818（留言） 2022年11月9日 (三) 06:02 (UTC)

由於具體用法和共識仍模糊，傾向保持「建議」而非「推薦」，以免出現爭議時據此力爭。其他暫無意見。--YFdyh000（留言） 2022年11月9日 (三) 12:48 (UTC)

已改。--Lt2818（留言） 2022年11月9日 (三) 13:04 (UTC)

如果最後只是取消百分號的空格要求也可以，畢竟事實標準也會成沒有空格，不過條紋內「度分秒」前最好還是加一個「惟」之類的連詞明確一下語義。--DvXg 📬 2022年11月15日 (二) 09:04 (UTC)

加了一個「但」，不知是否更好些。「惟」可能被理解為排他性，「但」作連詞使用時只表示轉折。--Lt2818（留言） 2022年11月15日 (二) 10:04 (UTC)

沒其他意見的話就 公示7日。--Lt2818（留言） 2022年11月24日 (四) 04:19 (UTC)

持續出沒的破壞者記錄頁面

自從過往關於設立獨立LTA命名空間或私密維基的討論再度擱淺後，再無與持續出沒的破壞者記錄頁面相關的討論。然而，部分LTA記錄頁面的內容收錄混亂程度到無助於進行反破壞工作的程度，失去建立記錄頁面的意義；例如近期有用戶抱持「沒有規則說不可以」的心態在部分LTA頁面（1、2）列出大量曾受有關LTA破壞的頁面並聲稱用作連出更改監視，且在兩個舉出的LTA頁面中均無有效說明破壞模式。根據過往討論和經驗，我認為列出大量曾受影響不但無助於反破壞（基本上LTA都在看着自己的LTA頁面，列出來了不就知道不要去破壞那一個特定頁面嗎？）更可能導致模仿犯的出現（例如過往出現的攻擊性帳號破壞群）；跟管理員私下討論時管理員更是表示「不認識」，相信僅列出受影響條目而沒有充足（而不過多）的說明是完全無助管理員判斷甚或認知的。

雖然作為傀儡調查助理的職責，但在沒有相關指導下苦無執行辦法，且人非聖賢，自問並非熟知所有LTA的行為模式，無法單靠自己而進行清理，為免未來再有用戶抱持「規則沒寫」的心態而在反破壞工作上帶來反效果，建議在現有公開檢視的框架下新增關於LTA記錄頁面的編寫指導，並在年末前清理一下過往積累的（活躍）記錄頁面，以平衡反破壞和記錄過多資訊。

以下為英文維基百科WP:LTA頁面列出的注意事項：

英維條文 不要提供過多資訊 文本應在提供有用資訊和提供足以妨礙檢測的資訊之間謹慎平衡；一般而言此類資訊應僅與具有可信用戶分享。 有用資訊的提示 請考慮只記錄擾亂行為的性質和摘要、重要的提報頁面（SPI、AIV、ANM）和對有關破壞者過為模式和辨認方式熟悉的用戶名稱。 僅在有確實需要的時候進行記錄 請只記錄有確實需要進行辨認的案例，尤其是很可能被不熟悉其行為模式的用戶誤認為善意編輯的破壞者。此包括難以偵察到地操作傀儡、惡搞、推動非中立觀點和宣傳性質等行為；不需辨認為傀儡即可作純破壞用戶封禁的破壞者通常不需記錄。 小心用詞 不要使用任何可能美化破壞行為的用詞。不要使用空泛的相對時間詞如「近期」，應使用清晰用詞如「截至[日期]……」。

--路西法人 2022年10月17日 (一) 04:39 (UTC)

LTA:變身：「是一位會在影視作品條目添加與「變身」有關的擾亂性內容，或是在生者傳記條目捏造傳主逝世與暴力傾向的破壞者。」原來是無有效說明破壞模式，而LTA:A11早就說了，編輯傾向之後才要補上，可以繼續說謊沒關係。Special:鏈出更改/Wikipedia:持續出沒的破壞者/User:A1111223、Special:鏈出更改/Wikipedia:持續出沒的破壞者/User:劉濬瑜哪裡無助反破壞。收錄使用過的IP地址也意味著LTA也能看著過去IP不要去破壞那一個特定頁面，模仿犯也能透過LTA過往IP進行模仿，完全無關LTA頁面是否有列出受影響條目。別拿著沒有的規定打壓其他使用者，在反破壞工作上帶來反效果。--寒吉（留言） 2022年10月17日 (一) 05:46 (UTC)

2021年10月：Special:PermaLink/68145157（是一位喜歡在中文維基的影視作品條目加入偽造「變身」的破壞者。） → Special:Diff/68145166 → Special:重定向/logid/10921975 → Special:Diff/68191144（「閣下持續在不同條目增加與「變身」相關的不實條目」） → Special:Diff/68225264

2021年11月：Special:PermaLink/68760910（是一位會在影視作品條目添加與「變身」有關的擾亂性內容，或是在生者傳記條目捏造傳主逝世的破壞者。） → Special:Diff/68760919 → Special:重定向/logid/11028668。

原來這樣LTA:變身完全無助管理員判斷甚或認知。--寒吉（留言） 2022年10月17日 (一) 06:20 (UTC)

(－)反對，提案者並未說明是否屏除章節「使用IP位址」（Special:PermaLink/74046119#使用IP位址、Special:PermaLink/68952501#使用IP位址、Special:PermaLink/68068025#使用IP位址），在我眼裡章節「使用IP位址」與「受影響條目」同樣都能讓模仿犯進行模仿，而兩個章節都對反破壞均為有效資訊。LTA:變身有提供破壞模式與編輯差異（LTA:變身#參考資料）的情況下，仍被提案者刻意打壓、抹黑。--寒吉（留言） 2022年10月21日 (五) 06:19 (UTC)

反對者顯然在鑽牛角尖。IP地址可以偽造（VPN已經是很多網路使用者的基本常識），但模仿特定IP地址遠比模仿行為困難，上網隨便一搜都能知道，就算有一個列表的IP地址提供給你，完全偽造到準確落在一個特定的網路地址基本上是不可行（非不可能），可偽造的可能性微乎其微，此部分顯然為存在謬誤並無效的反對論據；而提案中錯誤提及其中一個LTA頁面沒有提供破壞摘要說明確實是我的失誤，我可以就此道歉，你可說我說謊、說錯，但絕不能說我打壓，過往社群的普遍意見（參考前幾次的LTA空間討論）也是規範和盡量限縮公開於站內的資訊。既然反對意見存在明顯謬誤，且留言剩餘部分就只是在對人非對事，故整體視作明顯無效的反對意見。--路西法人 2022年10月21日 (五) 11:00 (UTC)

模仿犯能透過LTA過往使用過的IP查看過去此名LTA的編輯傾向（編輯差異）進行模仿破壞模式，我可不是說模仿IP位址（「收錄使用過的IP地址也意味著LTA也能看著過去IP不要去破壞那一個特定頁面，模仿犯也能透過LTA過往IP進行模仿，完全無關LTA頁面是否有列出受影響條目」），你的提案即是對人不對事，就非得我投出反對票才打算要回覆我，我的個人討論頁也直接忽略不回答，這麼喜歡逃避，現在還直接說我的意見有謬誤而視作無效的反對意見，這就是打壓行為，自打巴掌。--寒吉（留言） 2022年10月21日 (五) 11:03 (UTC)

「用過的IP會被封禁，編輯過的條目會被保護，結果Wikipedia:持續出沒的破壞者只能記錄使用過的IP，卻不能紀錄編輯過的條目，這樣會很矛盾，但無處有規定不能紀錄編輯過的條目」。所以為甚麼提案者只把章節「受影響條目」移除，不把章節「使用IP位址」也移除（Special:Diff/74124524、Special:Diff/74124518），兩者到底哪裡有差，而且LTA:變身與LTA:A11的編輯高機率都在過去編輯過的條目，在此兩個LTA頁面列出章節「受影響條目」幾乎不會常常出現如提案者所言噢，這些頁面被監視了，我去破壞別的，看你監視個寂寞，導致在LTA頁面列出章節「受影響條目」無助於進行反破壞工作。--寒吉（留言） 2022年10月22日 (六) 13:19 (UTC)

(＋)支持，考慮到部分現有LTA頁面確實難以尋得有效信息並有可能招致模仿犯，我認為確實有必要規範LTA頁面的編寫規則。另，就私密維基事項，本人亦準備於此同時推進。（基於原先討論，目前關於創建zh-lta wiki似已有共識，但對於訪問權處於討論狀態，故我希望就此儘快推進訪問權討論）。--BureibuNeko 2022年10月17日 (一) 08:09 (UTC)

以一個最近才在學抓蟲的菜鳥來說，覺得列出被破壞的那些條目幫助薄弱，或許是想避免模仿行為，不過要一個個去找出差異、還要知道到哪裡找出來真心覺得累，若是有重點式寫出行為模式，對後進有心想要協助反破壞、或剛好遇上破壞的新人，能夠因此更快確認狀況。我的情形是看了好一陣子的通報，有前輩標註LTA，從而認識了有持續出沒破壞者。在更早的時候，其實不知道這樣的破壞行為，是要通報和可以回退的，曾經也只是當有趣，反應慢到後來才明白這有多大條。故若能有重點明確的行為模式紀錄，比起只是列出這個使用者破壞了這些條目，幫助會更大，也認同模仿行為會是個兩難，即使私人訪問藏起來或許好，但我還是喜歡維基百科全都攤開來不怕看只怕看不到，而且直球對決比較爽快不過呢都投直球了對方還自大到以為不是我就真的沒辦法了。對於持續出沒破壞者，有必要就用百科的方式建頁面，討論好收集的素材內容，百科不是省油的、自然有很厲害的方式解決，對吧是吧？--Mafalda4144（留言） 2022年10月20日 (四) 22:06 (UTC)

第四次提議LTA頁面向私人wiki轉變

是次提案基於先前關於申請制站務維基建立的討論。

於Phabricator查看
編號T299590的工單

• 新的站務維基命名為：中文維基百科維護工作維基，zhwiki-maintenance-work（形如意大利語維基百科的sysopwiki，但是這個wiki的訪問權不僅限於sysop）

• 新的站務維基的域名為：maintenance-zh.wikipedia.org

• wiki的訪問權：傀儡調查助理、管理員（管理員）、回退員和其他經RFR申請得到訪問權的用戶。
• wiki訪問權的具體獲得方式：由申請者在RFR頁面申請後，經任一已在wiki擁有賬戶的用戶批准後（仿phab上Trusted-Contributors組），要求申請人向wiki管理員/wiki用戶發送一封電子郵件以提供郵件地址，由wiki管理員或wiki用戶註冊賬號。傀儡調查助理、管理員、回退員默認擁有訪問權，無賬號者僅需在RFR提出請求並向處理請求的向wiki管理員/wiki用戶發送一封電子郵件即可，一般的，除非其被撤銷過訪問權，否則則不需進一步的討論。

• RFR申請訪問權基本門檻：已表現出有訪問需要且有一定反破壞經驗（可參考在VIP等頁面的編輯）的可信延伸拓展用戶或巡查員

• wiki需要啟用的權限：跨維基導入者（zhwiki, meta） - 便於導入zhwiki LTA頁面內的內容
• wiki需設置：$wgBlockDisablesLogin = true - 便於撤銷訪問權

除此之外，此wiki亦可以處理私有過濾器編輯討論等問題（因為其訪問權僅限sysop, rollbacker和部分可信用戶）。

--BureibuNeko 2022年10月17日 (一) 08:09 (UTC)

過往討論中未曾提及站點管理員身份的部分，能否解釋一下刪除線的緣由嗎（雖然我沒想過要在設立站點之時就在本站管理員外提供進階權限）--路西法人 2022年10月17日 (一) 09:27 (UTC)

@LuciferianThomas：考慮了一下，基於訪問者均為可信用戶，wiki應該不會涉及過多需要管理員進行的操作（如保護、刪除等），故此wiki並不需要過多管理員。BureibuNeko 2022年10月17日 (一) 09:31 (UTC)

同意，清楚解釋很好。不過那個刪除綫去掉比較好，不要誤導到別人了。--路西法人 2022年10月17日 (一) 10:32 (UTC)

好的。BureibuNeko 2022年10月17日 (一) 12:36 (UTC)

先糾正一個錯誤，目前私有站點可以設置$wgBlockDisablesLogin來阻止被封禁的賬戶登錄，因此DisableAccount是不需要的（同時，這個擴展已經在prod被卸載了）。 Stang^★ 2022年10月17日 (一) 11:12 (UTC)

@Stang：好的好的，已經修改了，感謝提醒。BureibuNeko 2022年10月17日 (一) 12:36 (UTC)

根據當前描述，只有回退員可直接獲得訪問權，其餘用戶（包含傀儡調查助理、管理員、巡查員）均須在RFR頁面申請且「表現出有訪問需要且有一定反破壞經驗」才能獲得訪問權？雖然猜測只是文字敘述上的問題，但建議寫清楚一點以免爭議。另外，站點管理員如何產生？-Peacearth（留言） 2022年10月17日 (一) 19:16 (UTC)

感謝您的參與，關於訪問權，「wiki的訪問權：傀儡調查助理、管理員（管理員）、回退員、巡查員及其他經RFR申請得到訪問權的用戶」意思是傀儡調查助理、管理員（管理員）、回退員、巡查員不需要申請（或者僅需要向wiki管理員請求註冊賬號）且zhwiki管理員默認為wiki管理員，而其他人士需要在滿足基本條件（「RFR申請訪問權基本門檻：已表現出有訪問需要且有一定反破壞經驗（可參考在VIP等頁面的編輯）的可信延伸拓展用戶」）後在RFR頁面申請。關於「（回退員申請方式如上，不過其除非已被撤銷過訪問權，否則可直接獲得訪問權。）」，那是之前默認傀儡調查助理也是管理員的，我忘刪了，刪了。--BureibuNeko 2022年10月17日 (一) 23:13 (UTC)

我看了討論和前次討論，仍未搞懂如下問題：一、現有處理方式有何不足？二、站務維基有什麼用？三、設立站務維基的必要性在哪裡？希望有人能夠答疑。Fire Ice 2022年10月18日 (二) 06:26 (UTC)

“ 「努力」破壞的人被社群「銘記在心、永恆流傳」，還可以成為被「登載史冊、正式收錄」的對象，反倒對社群有貢獻的善意用戶隨着逐漸淡出或離去，經過幾年後，又有多少人或新進用戶認識或記得他們曾經的貢獻呢？這麼說起來，是否破壞者破壞一陣之後，即可名留青史？善意的貢獻用戶還不見得可以輕易留名，就證明自己的「存在感」而言，當今的社群機制是否反倒在鼓勵破壞者留名呢？ ” ——Kriz Ju

在此引用Kriz Ju一段話，私以為，增加LTA頁面訪問難度，使其僅限於真正想要學習與真正會做反破壞的人去查看（前者可以通過RFR申請，後者若非上述四種權限組成員，亦可通過RFR申請），從根本上打消部分愉快犯「留名青史」的目的，除此之外，站務維基可以使LTA不了解社群對這個LTA編輯方式的了解程度，從而儘可能的避免其見到LTA頁面上有什麼就避免做什麼，從而可能使回退員認為其只是「好心辦了壞事」的「編輯」而不能及時反應處理。

站務維基僅限於傀儡調查助理、管理員、回退員、巡查員和其他有一定反破壞經驗的可信延伸拓展用戶訪問，基於這個條件，部分無法在zhwiki公開討論的內容（如私有過濾器等）可以於此討論，在此基礎上，可以要求管理員在創建部分私有過濾器時先行於站務維基徵求意見而後實行。

而以上內容實現的條件均為有一個僅供部分用戶訪問的私人空間，而基於T299546的回應，zhwiki並無法安裝Lockdown組件，故實現的最好方式便為另闢新地。

--BureibuNeko 2022年10月18日 (二) 08:40 (UTC)

• (＋)支持能解決反破壞的一些目前無解的問題。-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年10月18日 (二) 09:03 (UTC)
• 支持，但我覺得有必要在本站留一些summary之類的東西，不能完全藏起來。 ——魔琴 [ 留言 貢獻 ] 2022年10月21日 (五) 03:08 (UTC)

  有LTA:主頁啊。--路西法人 2022年10月21日 (五) 05:01 (UTC)

• (＋)支持 0xDeadbeef（留言） 2022年10月21日 (五) 05:27 (UTC)
• 所以此維基將含有什麼內容？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年10月21日 (五) 05:53 (UTC)

  除LTA空間內容外，還可用於討論如私有過濾器等不便公開討論的內容。--BureibuNeko 2022年10月21日 (五) 06:38 (UTC)

  巡查員不可看到私有過濾器，而且回退員是否應該看到仍有爭議。 ——魔琴 [ 留言 貢獻 ] 2022年10月21日 (五) 15:43 (UTC)

  已移除巡查員默認訪問權限並允許其在自己不是延申拓展用戶時可通過RFR申請。「回退員是否應該看到仍有爭議」現在能看到對吧，那就不在討論範圍里。--BureibuNeko 2022年10月22日 (六) 03:08 (UTC)

• (－)反對，鴕鳥心態，不治根也不治本，大幅提升中維反破壞門檻。--寒吉（留言） 2022年10月21日 (五) 06:22 (UTC)

  @寒吉抱歉，但是可以請您說一下您為什麼會認為「大幅提升中維反破壞門檻」嗎？ 若是從LTA頁面角度出發，這個維基並不會完全代替原有LTA頁面，還是會留下能夠判別的信息在LTA主頁，只不過更多的描述被移動到wiki了而已，如果確有想法卻受限於自己不屬於上述用戶組，可以在RFR申請訪問權。私以為並不會提升反破壞門檻，而以最壞情況設想，也僅僅只是為zhwiki過濾了一批完全沒有能力做站務的人而已。--BureibuNeko 2022年10月21日 (五) 06:42 (UTC)

  以上反對視作無效意見，因其未給出詳細原因以促成討論。BureibuNeko 2022年10月30日 (日) 08:03 (UTC)

  可悲。--寒吉（留言） 2022年10月30日 (日) 08:06 (UTC)

  @寒吉：不過您是否考慮詳細展開一下論述？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年10月31日 (一) 00:51 (UTC)

• @桐生ここ、30000lightyears、Emojiwiki、Temp3600、1233、Hehua、忒有钱、Xiplus，ping一下之前參與討論者，若有打擾還請諒解。另請了解上另有對LTA記錄頁面的編寫指導的討論，亦歡迎參與討論。BureibuNeko 2022年10月22日 (六) 03:35 (UTC)

  • 感謝邀請，目前沒什麼問題。

  --在下荷花，請多指教（歡迎簽到） 2022年10月22日 (六) 11:37 (UTC)

• 還是老問題：在明顯有破壞者擔任回退員時，private wiki能有那些作用。--Temp3600（留言） 2022年10月22日 (六) 14:52 (UTC)

這不應該是private wiki方面考慮的內容，換而言之，這是現行回退員體制的漏洞而非private wiki的漏洞，wiki創建的根本目的是讓LTA無法了解到社群對其的認知程度，然而有LTA混到了你維回退員就實在沒有什麼辦法了，誰知道管理員里有沒有，行政員里有沒有，監督員里有沒有呢？這個wiki並非雞肋，反而還能在授予訪問權前在進行一次覆核。BureibuNeko 2022年10月30日 (日) 08:01 (UTC)

private wiki如果堅持「把房子蓋在沙土上」，自己也得擔起部分責任吧。再收緊訪問權倒是有用，問題是可以怎樣複核？--Temp3600（留言） 2022年10月30日 (日) 12:08 (UTC)

• +1 ghrenghren為此+1了。：雞肋，棄之可惜，食之無所得。--Ghren🐦🕑 2022年10月23日 (日) 06:47 (UTC)

  這也是之前我推這個提案的時候，一個重要的反對原因……我覺得如果不改革回退員，搞什麼都沒用 ——魔琴 [ 留言 貢獻 ] 2022年10月23日 (日) 07:22 (UTC)

  既然你這麼認為的話我還是有點想請教一下你認為回退員 1) 為什麼要改革； 2) 改革後應該達到什麼樣子； 3) 如果可能的話，你想使用什麼方式（包括修訂方針指引，或者其他程序性改動等）達成你的改革目標。--MilkyDefer 2022年10月25日 (二) 14:24 (UTC)

---

• 考慮到多數參與者持支持意見，而其中兩個質疑其中一個質疑僅僅表達自己立場而無法繼續促成討論，另外一質疑僅僅只是對本身wiki必要性提出疑問（且已經回復）而非對成立本身提出質疑。由於討論趨於停滯而結合先前討論，現 公示七天，至2022年11月6日止。BureibuNeko 2022年10月30日 (日) 08:09 (UTC)

在解決回退員問題以前，(－)反對成立所謂「LTA維基」。我覺得這不是可以隨意忽視的意見。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年10月30日 (日) 11:04 (UTC)

考慮到此前和現在有關回退員的討論，個人認為有關「制度改革」的相關內容很難在近期達成共識。或許可以取消回退員對新wiki站點的訪問權限，而成立一類似clerk的權限。--Yining Chen（留言|簽名頁） 2022年11月4日 (五) 23:31 (UTC)

• 基於上述討論意見，暫撤下公示，討論暫且擱置（不存檔）至Wikipedia:互助客棧/方針#再提拆分回退員之私密過濾器源碼閱讀權至另一用戶組案討論結束後。BureibuNeko 2022年11月12日 (六) 13:03 (UTC)

  (－)反對，沒有必要，認為除非維媒伺服器內存爆滿^{[開玩笑的]}不然根本只會搞的更加混亂，而且不違反WP:NOT吧？--想看看FK8438的傑作嗎？（點此續命） 2022年11月20日 (日) 09:53 (UTC)

註：此留言已被原作者（User:SunAfterRain）移除。2022年11月16日 (三) 15:02 (UTC)

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

Wikipedia:格式手冊/日期和數字增加「常用的數學符號」章節

提議在Wikipedia:格式手冊/日期和數字增加「常用的數學符號」章節，置於「注釋」章節前作為正文的最後部分，內容如下：

常用的數學符號

參見：Wikipedia:格式手冊/數學

• 一些數學符號難以直接輸入，可使用編輯器菜單插入，或代之以此處所列的HTML字符實體引用（形如÷）。
• 若需要以不同於普通文本的形式顯示數學公式，可使用{{mvar}}（用於單字母變量）和{{math}}（用於複雜表達式）模板。更多方法詳見Help:數學公式。

常用的數學符號

符號名稱	符號	HTML實體	備註
加號/正號	+	+
減號/負號	−	−	大多數程式語言則使用連字暨減號（-）表示減號/負號。
正負號	±	±
乘號	⋅	⋅	與間隔號（·）不同。
	×	×
除號	÷	÷	另有斜線（/）常用以表示除法或分數，如1/2可表示一除以二或二分之一。
等號	=	=	調用模板時若省略編號參數的參數名（形如1=），參數值中的等號會被錯誤解析，寫上參數名或使用{{=}}魔術字即可避免。
約等號	≈	≈
不等號	≠	≠
小於號	<	&lt;
小於等於號	≤	&le;
大於號	>	&gt;
大於等於號	≥	&ge;

修訂的出發點是為了規範減號/負號的碼點為U+2212 − MINUS SIGN，同時註明在編程語言中則多以U+002D - HYPHEN-MINUS為減號/負號。先前與A2569875君的討論可供參考。

提議條文來自en:WP:COMMONMATH，做了些簡化，主要是刪除了對空格的約束。英文原文規定在二元運算符兩側加空格，站內則並未統一，如1 + 1 + 1 + 1 + …有空格，1+1無空格。W3C《中文排版需求》草稿2.3.5節中的數學運算符兩側有空格與無空格都有出現，搜索其他中文標準規範尚無收穫。因此不貿然對二元運算符兩側的空格做規定。--Lt2818（留言） 2022年10月18日 (二) 15:26 (UTC)

(＋)支持。在下亦曾爭論普通文本的減號應該用U+2212 − 抑或U+002D - （甚至有編者用U+FF0D － FULLWIDTH HYPHEN-MINUS……）。認同使用前者並支持加入格式手冊。——$\definecolor {my}{rgb}{0.04,0,0.5}\color {my}{\mathsf {htc_{23}}}$（留言） 2022年10月18日 (二) 22:19 (UTC)

• 是否需要在「大部分的程式語言……」加註與維基編輯相關的部分，如「若因技術限制在模板或模組內部可以使用連字暨減號，僅需要令輸出於條目文字的部分為減號即可。」以讓先前討論的結果有反映在修訂案內-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年10月20日 (四) 05:21 (UTC)

  這部分不止和減號有關，與-對應−類似的關係還有*對應×、/對應÷，可能寫一起比較合適，但沒想到好的行文。（表格內只提了減號是因為只有-與−形狀相似，容易搞混。）「僅需要令輸出於條目文字的部分為減號」僅適用於模板/模組的編寫，適用面不大，個人感覺不必特意寫進格式手冊。--Lt2818（留言） 2022年10月20日 (四) 06:26 (UTC)

(！)意見：我支持可以納入並建議維基編輯在一般條目原始碼編輯中使用U+2212當作負號或減號使用，不認為"大多數程式語言則使用連字暨減號（-）表示減號/負號。"為全面的觀點描述，反對任何"要求編輯不應在一般條目編輯中將U+002D當作減號或負號使用"的論點，另外質疑目前似乎沒有叉乘號的說法，依照乘號的內容："名稱為「乘號」，亦稱作「叉號」或「交叉」"。--Anghualee（留言） 2022年10月26日 (三) 04:33 (UTC)

• 「大多數程式語言則使用連字暨減號（-）表示減號/負號」是事實而非觀點，語出en:Hyphen-minus#Programming languages。如果該事實描述尚不全面的話，歡迎給出增改建議。
  • 許多MediaWiki擴展、模板、模塊等只接納U+002D而非U+2212作為輸入，個人認為這些包括在「程式語言」的範疇中，加之格式手冊規範條目最終呈現的性質甚於源碼編排，因此沒把這一點寫進提議條文。
• 個人認為根據使用場景的不同，U+2212與U+002D中只有一個是最合適的符號，難以想象有兩可的場景。雖不必將另一種符號視為錯誤，但若有心者願意調整為最合適的符號，自然是好的。
• 叫「叉號」或「交叉」就看不到乘法運算的含義了；「乘號」是包括了⋅和×二者的（參考），但我沒找到兩種符號並列時各自的常用稱謂。如果沒有更好的方案，權將二者名稱合併稱為「乘號」吧。

--Lt2818（留言） 2022年10月26日 (三) 12:00 (UTC)

• 然後 en:Hyphen-minus#Programming languages 引用了兩種程式語言的手冊，而裡面壓跟沒提 hyphen-minus，其中一個引用還被打上"頁數呢？"。事實是現代大部分程式語言的原始檔編碼都支持 Unicode，而用鍵盤打程式碼來講，打出U+002D比打出U+2212快太多了，工程師幹嘛要直譯器或編譯器額外增加處理一個大家都不用的U+2212？我就好奇有哪個打字訓練軟體要求你打U+2212而非U+002D了？而且就算你堅持那個是事實，說真的，也不影響。因為重點在於不夠全面，事實上一般使用（不限於程式語言）上 hyphen-minus 可以作為減號使用，就是 en:Hyphen-minus 一開頭引用了 Unicode explained 的論述，同時也是更為全面的觀點。
• 當然如你所說，在可使用選擇更完整的情況下，會有更合適的符號（畢竟 Unicode explained 裡面也是這樣認為的），所以我一開始就說我支持"納入並建議使用U+2212"。但是考量 Legacy 支援，根據目前鍵盤還沒有廢除或者是完全將 minus 完全獨立（畢竟有無數字鍵鍵盤），也就是對一般使用者來說，依舊會有採用連字暨減號作為減號使用的狀況，自然完全就符合 Jukka K. Korpela 撰寫的 Unicode explained 中所述這屬於 ASCII Legacy 支援的部分。同樣在一般新聞使用上（好比說這篇）也一樣會使用。考量到以上狀況，避免造成一般編輯上的困擾，所以我也提出了反對"不使用U+002D"的意見。
• 根據使用場景的不同，⋅和×中只會有一個是乘號。而照 Unicode 來講的話，⋅叫 Dot operator。--Anghualee（留言） 2022年10月26日 (三) 13:17 (UTC)

• 我自己接觸過的程式語言全部使用連字暨減號，但en:Plus and minus signs#Uses in computing列了兩種語言不用它表示負數。不覺得把「大多數……」這句話當事實呈現有什麼問題。
• 維基百科使用Unicode，個人認為不需要在格式手冊里描述僅有ASCII編碼時該如何寫數學符號，感興趣的讀者點進鏈接看就行。否則ASCII使用*/表示乘除，也要一併寫入了。
• 我覺得做好Legacy支援與標明最合適的符號並不衝突，譬如重定向即是一個方面，-1可以重定向到−1。
• Dot operator的名稱也看不出乘法的含義，且搜索Dot operator出來的許多是程式語言中的概念。Unicode的字符名稱未必覆蓋使用場景，甚至出錯了都不改，「杭州碼子」的命名錯誤即是一例。

--Lt2818（留言） 2022年10月27日 (四) 02:45 (UTC)

這倒提醒我了，你用的en:Plus and minus signs#Uses in computing段落裡面就有用/（U+002F），即便不作為除號使用，分數（en:Fraction）的部分也該提到⁄（U+2044）吧？至於Dot operator我也只是提一下 Unicode 是用此名稱（其實⋅也看不出乘號），我基本上只對叉乘號有意見，對點乘號其實沒講話，畢竟點運算子跟點乘號我還真分不出來哪個比較醜，你自己改回乘號然後糾結，這跟我沒關係的呀。其實跟 hyphen-minus 一樣丟到備註去就好了，只是你自己過不去而已。--Anghualee（留言） 2022年10月27日 (四) 04:32 (UTC)

把/寫進除號一欄的備註里了。把⋅丟到備註仍然需要介紹其HTML實體，還不如現在這樣。--Lt2818（留言） 2022年10月27日 (四) 07:22 (UTC)

點乘和叉乘 ——魔琴 [ 留言 貢獻 ] 2022年10月31日 (一) 08:22 (UTC)

點積、叉積，名稱看起來僅指運算，而非符號。--Lt2818（留言） 2022年10月31日 (一) 15:36 (UTC)

有結論了嗎？-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年11月7日 (一) 03:57 (UTC)

公示7日。感謝諸位的意見。--Lt2818（留言） 2022年11月7日 (一) 09:21 (UTC)

• 這收錄標準實在是不一。請問比如說sigma、幾階、角度等，難道都不算常用的數學符號嗎？雖然(＋)支持，但是這標準看了顯然是不行。請問若通過，那後面的用戶能否自行擴充相關數學符號？都可以隨便舉例3個也算常用的了。--Z7504非常建議必要時多關注評選（留言） 2022年11月8日 (二) 16:02 (UTC)

  確實沒有定一個客觀的收錄標準，個人認為在非數學領域也常用的數學符號可以收錄。上述例子中，我覺得只有「角度」在非數學領域常用，不過現在表格里還沒有單位符號。用戶能否自行擴充相關數學符號，就看其他用戶是否接受吧。--Lt2818（留言） 2022年11月9日 (三) 03:10 (UTC)

• 公示期過了吧。公示期間的意見有有效的解決方案嗎？-- 宇帆:雪菲🐉蛋糕🎂⇔娜娜奇🐰鮮果茶☕｜在維基尋求休閒是否搞錯了什麼（☎️·☘️） 2022年11月18日 (五) 00:40 (UTC)

  沒有。--Lt2818（留言） 2022年11月19日 (六) 11:56 (UTC)

  • 不然就這個先通過，若要加其他符號再另開新修訂案？-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2022年11月26日 (六) 05:37 (UTC)

    可以啊，格式手冊先前已更新。我覺得收錄標準不是大問題。--Lt2818（留言） 2022年11月26日 (六) 16:24 (UTC)

關於WP:命名常規與WP:POV的衝突

算一個比較長久的問題，現時對條目命名最直接影響的WP:命名常規，並沒有提及POV的問題，而WP:POV對命名的觀點主要是這樣：

“

一篇維基百科條目須有一個確定的名稱。防止分列觀點的普遍限制同樣適用於條目名稱。如果與條目主題相關的命名爭議的確存在，這一爭議應當出現在條目內容當中，並以可靠來源加以證實。此外，維基百科編者不能為了解決非中立爭議而使用標新立異的條目名稱。將條目名稱分段並列也是錯誤的做法，比如「地平說的地球／地圓說的地球」或「地平說的地球 (地圓說的地球)」的形式都是不正確的。合成詞也可能是不適當的，如「地球的形狀」或「地球 (形狀上有爭議)」；特別應注意不能為了解決分列的觀點而刻意杜撰新名詞。

有些時候，條目標題本身可能便是爭議與對立的來源。特別是當描述性標題所表明的觀點「支持」或「反對」某一特定議題時。中立的條目標題是非常重要的，因為它能確保文章的主題出現在合適的上下文中。因此，百科式的條目標題應能表現出最高程度的中立性。條目可以在儘量少用感情詞彙的情況下涉及相同的內容，或為了確保中立觀點而涉及更多的內容（例如將「對毒品的批評」修改為「對毒品的社會觀點」）。中立的標題鼓勵多種觀點以及負責任的條目寫作。

當條目標題為姓名等專有名詞時，可能出現的爭議往往是應不應該使用某一特定名稱。維基百科對此傾向於描述而非指定，應使用在可查證的可靠來源中找到的常見中文名稱。如果對象是地理特徵等沒有生命的實體時，一般應使用中文出版物中最常見的名稱。參見Wikipedia:命名衝突以獲取進一步的指引。

”

。

然後，在討論一個條目命名的問題時，我跑去看了一下現時命名常規的來源（大概是？），en的en:Wikipedia:Article titles，然後留意到是有對POV的說明，初步翻譯如右（User:Cwek/工作室/關於條目常規的一些備存），大概意思就是兩類：如果來源夠多，即使看上去用詞不中立的現在常用的名稱，可以用；或者可以創建一個使用中立詞語的描述性用語。POV在en關於命名的章節也初步翻譯過（意見：大致相似，但有部分差異）。另外，也列出了部分涉及是否考慮POV的命名常規討論。

所以，我們是否考慮在命名常規中考慮POV的需要？ ——Sakamotosan路過圍觀 | 避免做作，免敬 2022年10月20日 (四) 08:35 (UTC)

補充，en命名常規關於POV的說明，初步找到是2010年5月時的。——Sakamotosan路過圍觀 | 避免做作，免敬 2022年10月20日 (四) 08:44 (UTC)

@Ch.Andrew、Shizhao、Reke、Mewaqua、Gakmo：，提及一下Wikipedia_talk:命名常規/存檔10#關於修改維基百科:命名常規的建議_2有參與討論仍有活躍的。——Sakamotosan路過圍觀 | 避免做作，免敬 2022年10月21日 (五) 01:16 (UTC)

@Peacearth、蘇州宇文宙武、Happyseeu：，提及一下Wikipedia_talk:命名常規/存檔11#提議：命名常規不應違反中立性原則有參與討論仍有活躍的。——Sakamotosan路過圍觀 | 避免做作，免敬 2022年10月21日 (五) 01:18 (UTC)

@Chiefwei、Silvermetals：，提及一下Wikipedia_talk:命名常規/存檔11#中文維基百科命名常規引起的問題有參與討論仍有活躍的。——Sakamotosan路過圍觀 | 避免做作，免敬 2022年10月21日 (五) 01:20 (UTC)

我的理解，所謂描述性用語是指那些非專有名詞類的條目標題，例如「對xxx的批評」，「xxx爭議」，「20xx年xxxx事件」，這一類不太會在其他出版物中使用的短語。所以，「如果來源夠多，即使看上去用詞不中立的現在常用的名稱，可以用；或者可以創建一個使用中立詞語的描述性用語。」。在我看來二者並不是「或」的關係，而是對兩類標題的兩種規範方式（專有名詞：常用，可以POV；其他的描述性用語：應當儘可能NPOV），是並行的--百無一用是書生 (☎) 2022年10月21日 (五) 02:18 (UTC)

@Shizhao：，這個問題，一來命名常規早就討論過幾次，二來是來源於西藏和平解放‎‎的問題，因為一直有編輯認為需要體現POV（或者是他們的主觀「中立」），需要更換命名，但我認為根據現有命名常規並沒有POV的要求，而且POV對於命名中有提到這類有爭議的有專有名詞的，可以跟隨命名常規的常用性。按照現有規則，這個命名暫時不需要修改（滿足命名常規的常用，處於爭議狀態下的最後一個正常命名，而且屬於POV排除情況）。但考慮這些編輯對於POV的執着，我看了en的做法，留意到en對於POV是有這樣的表述，剛好對應提及的兩種情況：「西藏和平解放」是（可能）不中立的但常用，他們也挑選了「中國吞併西藏」（我認為可以選擇更中性的「中國占領西藏」）符合中立的描述性用語。

如果考慮修正命名常規和POV（由於涉及專有名詞部分應該是排除性條件），則可以考慮上面兩個方案再選擇合適的命名，如果不修正的話，則可以說明「命名常規不需要考慮POV，POV即使作為支柱之一是可以忽略的（而且它的確有一個豁免條件）」，那除非挑戰「西藏和平解放」的常用性（用其他更好的可以量化的判斷方法），否則以POV作為命名調整的依據是不成立的。

這個改動可能影響廣泛，大量現時以中國大陸觀點並且滿足命名常規常用原則的條目，就都可以POV來挑戰。——Sakamotosan路過圍觀 | 避免做作，免敬 2022年10月21日 (五) 03:14 (UTC)

可以加入說明，但我也同意如書生所言，應該沒什麼衝突。就我的理解是如果專有名詞本身帶有POV，仍以常用為主。比方說國共內戰的許多戰事都有雙方命名，各在兩岸為常用語，此時無論用何者為主條目命名都POV，而維基並不能自創一個NPOV的名稱。但如果是描述性的標題，就要儘量NPOV。--Reke（留言） 2022年10月21日 (五) 03:27 (UTC)

• 如果追求名稱絕對中立，也許意味着命名忌用入侵等負面詞彙（如同條目中忌用感嘆號），不局限於中國大陸問題。廣泛原創出不常用命名的後果，恐怕很糟。使用文獻中最常見、廣泛的稱呼，並在序言闡明，應能應對大多數情況，也利於讀者搜索和對應概念。
• ( π )題外話，偽滿皇宮博物院、偽滿洲國交通部舊址等本身是事物專有名稱（保護建築）但同時是事物描述的條目命名，又是否要「中立化」。後者如果改掉條目名，序言寫清事物名稱就比較囉嗦了。前者改名等於原創命名或變更主題。
• 另應參考WP:NPOVFAQ、WP:YESBIAS，絕對中立的後果可能是，偽科學叫「未被主流認可的科學體系」。

--YFdyh000（留言） 2022年10月21日 (五) 03:56 (UTC)

@YFdyh000：，根據我對en對於命名對中立觀點的表述的理解，應該分為「不中立但常用的標題」和「非判斷性的描述性標題」，而後者的舉例是「吸煙對健康的影響」等類似「XXX的影響」、「XXX的反應」等無實事物的虛概念的命名，應該是不帶褒貶的判斷。而前者就對應存在實事物、形成一個專用用語、並且被大部分文獻來源使用的。所以偽滿皇宮博物院等是事物專有名稱的，不是屬於像「影響」、「反應」等虛概念的，就可以第一個觀點。而且從zh對於中立對命名的表述，看上去也體現了這兩個觀點，但不如en在命名常規中具有明確可行的描述。——Sakamotosan路過圍觀 | 避免做作，免敬 2022年11月9日 (三) 04:49 (UTC)

基於西藏和平解放的問題，1.我們需要為命名常規和POV添加關聯性；2.如何行文？因為命名常規的POV注意是在「常用」中提及並單獨一章，而en的POV也提到只要常用，就算對於某些人來說是非中立的，或者POV，也是可以的；3.如果確立了命名常規和POV的關聯性，這個個例這樣使用？是用可能是非中立但常用的「西藏和平解放」，還是略常用、非中立、帶有描述性（？）的「中國吞併西藏」，還是一般常用、中立、帶有描述性的「中國占領西藏」？關於常用的搜索引擎檢查，這裡一個記錄：User:Cwek/工作室/西藏。——Sakamotosan路過圍觀 | 避免做作，免敬 2022年10月21日 (五) 04:56 (UTC)

作為百科全書，應該考慮檢索問題。可以常用名稱優先，即使它很偏離主流立場；如果有多個立場相互衝突的常用名稱，則「先到先得」，或者用{{NoteTA}}處理，禁止無故移動條目名稱。至於標題名稱的問題，可以放到導言裡面去詳細講述。--高文海（留言） 2022年10月26日 (三) 06:31 (UTC)

WP:TITLE和WP:POV綜合理解說就應當是以通用兼描述性地標明相關稱謂，但基於WP:地域中心等系統的影響而言有關實踐並在本地議題是否完滿，包括結論本身是否合乎通行維基尺度而言是很難定論的。

如有關WP:VPD可能仍存有爭議之個別裁判所命名問題，在主推議案人限定以中文圈之地方法院潛在導致一統本地既有或未來所有裁判所命名情況，該如何判定相關引用基礎之中立客觀？唯一強調法則即如以單一時限之中文文獻優先，不考慮日文與中文長久相互貫通因素、且有關術語亦並非罕見而見諸於中文文本自身含專業層面，是以強調採編仍以一統使用中文地區命名而限制有關客觀中立立足之下，命名優先之選擇問題，恐並非基於使用是否廣泛或是否合乎通常認知、語文沿襲習慣等法，而全賴於當期主事強調之時所採用之壓制化路線是否得以成型而定。

個案而言，有關通行規則本身在部分個案內被單獨孤立依照其本身採編單一意向而孤立援引之時，在如既已有既定之非以合乎綜合材料觀點研判、非以合乎參議之時所通俗理解或通常使用邏輯知識，僅以如whataboutism及變相堆砌無異議之單一意向氛圍下而強調合乎一切所謂商議並自行定論，有關命名移動等皆已無可挑戰、是以相應社區及社羣實際並未有適切比例地落實到一直以來需要各使用者盡力之協作及適當參與等維基要義。

方針問題即在於實際採用之時，是為基於合乎方針背後維基核心之超越系統局限而顯維基多元及廣泛知識面，或基於與之相反路線，矛盾不加制約，則可繼續舊往。--約克客（留言） 2022年10月26日 (三) 07:39 (UTC)

具體問題

作為重要的的方針問題，居然沒人關注，只能說太麻木了。

如果在不考慮具體個案的話，不需要具體的評論，我們應該怎樣決定：

1. 是否在涉及條目命名的命名常規中，考慮明顯地體現中立的方針，而且是兩邊都需要互相提及，如同en所做的？是或否？
   1. 如果否的話，那怎樣在兩個方針體現這個觀點「命名常規不考慮中立性」？
   2. 如果是是的話，同樣，怎樣在兩個方針體現這個觀點「命名常規考慮中立性」。是否參考en的做法，在「常用性」中提到要考慮中立性，而且對於這種情況有「不中立但常用的標題」和「非判斷性的描述性標題」兩種具體的操作情況？
2. 如果還是保持沉默的，是否意味這維持現狀：「 命名常規沒有明顯地考慮中立的觀點，但中立的觀點對於命名上存在『條目標題本身可能便是爭議與對立的來源。特別是當描述性標題所表明的觀點「支持」或「反對」某一特定議題時……因此，百科式的條目標題應能表現出最高程度的中立性。條目可以在儘量少用感情詞彙的情況下涉及相同的內容，或為了確保中立觀點而涉及更多的內容（例如將「對毒品的批評」修改為「對毒品的社會觀點」）。』和『當條目標題為姓名等專有名詞時，可能出現的爭議往往是應不應該使用某一特定名稱。維基百科對此傾向於描述而非指定，應使用在可查證的可靠來源中找到的常見中文名稱。』兩種觀點」？

以上。也請不要說一些打太極的話。——Sakamotosan路過圍觀 | 避免做作，免敬 2022年11月9日 (三) 04:19 (UTC)

與其說沒人關注，不如說話題「太大」，難以總結。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年11月9日 (三) 07:59 (UTC)

所以我舉出en的說法。en是命名和NPOV都互相提及對方，然後作為影響命名最直接的命名常規就說明了如何操作。但zh只有NPOV提及到在命名中關於NPOV的問題，也給出兩個方案的概要，其中一個方案還是指向命名常規的常用，命名常規沒有提及。所以如果遇到條目命名中提及以「中立性」（或者NPOV的話）為理由，怎樣操作？單靠每次的條目共識解決？或者遇到解釋不清的問題怎樣解決？而且這個問題不是第一次，我列出了好幾次的討論。

所以我認為，參考en的命名常規、NPOV對於命名的處理：NPOV提到不能製造分立觀點式的命名、可以對於虛概念製造描述性命名、但專有用詞常用的話就跟隨常用，即使POV的；命名常規則提到兩種命名方式，常用但不中立的命名和非判斷的描述性命名，正好對應NPOV的第三、二點。zh的NPOV基本上對應en的NPOV的說法，主要是命名常規怎樣處理，是否定或不認同NPOV，還是參照en的做法補充相應的說明？——Sakamotosan路過圍觀 | 避免做作，免敬 2022年11月9日 (三) 09:35 (UTC)

可以英語維基百科的Article_titles作為參考，擴充漢語維基百科的命名常規。 -- 月都 ※ 2022年11月14日 (一) 07:46 (UTC)

(＋)贊成Eric_Liu，難以概括地用於所有情況，通常以命名常規作為參考；維基百科的規則不只有中立的觀點，有些時候以含義或知名度作為參考，需要透過共識解決。 -- 月都 ※ 2022年11月14日 (一) 07:54 (UTC)

共識無法解決的話？或者說方針可能出現衝突時，討論雙方都自持方針為依據，怎樣解決？en在命名常規和NPOV上的說明我認為足夠合理並提供了可行的操作方案，但zh這邊實在難以操作。——Sakamotosan路過圍觀 | 避免做作，免敬 2022年11月14日 (一) 09:33 (UTC)

誰在這個網站朋黨最多，本身時間最多，或是嘴砲最強，就能贏-- Jason22  對話頁 貢獻 2022年11月22日 (二) 15:55 (UTC)

再提拆分回退員之私密過濾器源碼閱讀權至另一用戶組

過往多次討論見Wikipedia_talk:防濫用過濾器#提議修改維基百科:防濫用過濾器。簡介:鑑於目前回退員中有內鬼，過往數年洩漏過濾器詳情，導致反破壞工作受到不少影響。此事亦進一步影響到回退員可否兼領其他權限(如LTA private wiki的閱讀權限)的質疑，導致反破壞權限改革無法推進。

為此，再次建議拆分回退員之AF源碼閱讀權(abusefilter-view-private)，以收緊其獲得人數。該新用戶組的成員應高度可信，且在反破壞工作中保持活躍。

請諸君討論。--Temp3600（留言） 2022年10月30日 (日) 12:24 (UTC)

個人傾向(＋)支持，但應該考量到之前提出的問題（如對過濾器並沒有那麼了解的回退員間接造成接觸到的資訊差異）。我是有想過一折衷方案（前提是技術上可行）：過濾器觸發時只截取出觸發的部分，而非顯示過濾器完整結構。這樣也能幫助看不懂AF是做什麼的回退員比較能夠理解觸發原因。--$\int$（☎）dt 2022年10月31日 (一) 01:50 (UTC)

哇你這想法有點天方夜譚誒，過濾器做不到這一點，或者說我就沒見過哪兒有能展示這種信息的東西。GDB和LLDB我都沒印象有這種工具誒（--MilkyDefer 2022年10月31日 (一) 02:09 (UTC)

如果連回退員都看不懂觸發器語法的話，要這個權限有什麼意義，還不如支持AF助理方法，讓懂得人自己去檢查或者協助修改AF。而且展示出觸發的語法部分估計現在AF的實現根本沒有這樣的功能，還要mw開發組來實現（或者自己推修改補丁）。只能說有點異想天開。——Sakamotosan路過圍觀 | 避免做作，免敬 2022年10月31日 (一) 02:19 (UTC)

程序上極難實現，只能人工處理，那似乎等同條文上允許某種「查閱請求」。--YFdyh000（留言） 2022年10月31日 (一) 02:28 (UTC)

那算了（看到時全域有沒有這個需求、mw開發出來再說，原本只是想有沒有人寫個小工具就可以解決），就把abusefilter-view-private去掉就好。「另一使用者群組」可以考慮由回退員之間選出，之後由管理授權吧。--$\int$（☎）dt 2022年10月31日 (一) 03:49 (UTC)

(＋)強烈支持。--路西法人 2022年10月31日 (一) 03:31 (UTC)

(！)意見：上一次討論進行了近四個月，最終也沒能達成共識。「共識是可以改變的，但如果你要提出類似的提案，應該解決過去的反駁意見」（WP:常年提案）。個人想知道此次討論較上次討論有何變化？另外，似乎最近由過濾器詳情泄露引起的破壞有所減少？--Yining Chen（留言|簽名頁） 2022年10月31日 (一) 05:53 (UTC)

上一次的討論一開始沒有考慮分拆，而直接將權限收回管理員，引起不滿；後來又因為ip masking導致困難重重。這次只處理核心部分，即AF分家。其他問題容日後再處理。--Temp3600（留言） 2022年10月31日 (一) 10:03 (UTC)

更改一下說法，IP masking方面問題不大。 Stang^★ 2022年11月11日 (五) 19:10 (UTC)

感謝補充，但仍建議下一步再處理此問題。--Temp3600（留言） 2022年11月17日 (四) 04:35 (UTC)

我記得上次諸位就是同意居多，問題似乎在技術阻礙？個人對此提議自然是(＋)支持。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年10月31日 (一) 07:27 (UTC)

上次是提到了phab:T309318。如果不考慮IP masking的話就應該沒事。 ——魔琴 [ 留言 貢獻 ] 2022年10月31日 (一) 08:01 (UTC)

對建立反LTA類型的用戶組無異議，但希望同期建立有效、便捷渠道或規則為可信用戶處理相關諮詢，如回退員的合理詢問和建議，以解決部分用戶的偶發需求。--YFdyh000（留言） 2022年10月31日 (一) 07:37 (UTC)

這方面我有一計，但暫時想不出要怎樣配合中維的情況來實施：強化維基百科:反破壞工作小組的職能，將建立為「反破壞專家」的公會。--Temp3600（留言） 2022年10月31日 (一) 14:42 (UTC)

能不能提出什麼具體議案或者說服力的理據，「彷彿劇團每隔一段時間重複演出同樣的戲碼」，我是比較無奈的。上次不是說要將IPInfo和IP masking合併到這個新的用戶組，然後就沒下文了。--Ghren🐦🕓 2022年10月31日 (一) 09:09 (UTC)

這次希望先解決目前的問題，IP masking目前還沒有起色，合併進來的話就搞不下去了。--Temp3600（留言） 2022年10月31日 (一) 10:03 (UTC)

之前的討論參考了YF君提供的意見，我提出的意見的確有捨本逐末之嫌。既然回退員主要工作是快速回退破壞，那麽側重點應當是對回退相關方針的理解程度至少可以讓社群信服做與反破壞相關的工作。而不是技術（例如私密濫用過濾器）能力，因爲其側重點無法保證回退員具備此種能力或與其相對應的操守。所以(＋)支持拆分權限。--紹💓煦^集思廣益 2022年11月5日 (六) 07:44 (UTC)

(＋)支持拆出Wikipedia:過濾器助理。--冥王歐西里斯（留言） 2022年11月5日 (六) 12:37 (UTC)

註：此處原有文字，因為LTA傀儡發言，已由路西法人於2022年11月27日 (日) 09:26 (UTC)刪除，尚祈見諒。若有異議請至互助客棧或向管理員反映。

感謝X43現身說法證明拆分的需要。--Ghren🐦🕙 2022年11月26日 (六) 14:48 (UTC)

名字與細則

過往的方案見Wikipedia:過濾器助理。歡迎各位討論。--Temp3600（留言） 2022年11月5日 (六) 17:25 (UTC)

• 我先建議：回退員不可自動兼任過濾器助理，需要獨立申請。--Temp3600（留言） 2022年11月5日 (六) 17:25 (UTC)

  這是自然，不然就失去意義了。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年11月5日 (六) 23:48 (UTC)

• (＆)建議由了解相關技術的管理員，WP:IA或WP:BAG對候選人進行基本的技術上的考核，如給定中文維基或其他維基上的某個公開過濾器，令申請者說出其大致工作原理，以確認申請者有理解過濾器的能力。--Yining Chen（留言|簽名頁） 2022年11月6日 (日) 04:38 (UTC)
• 為防再有內鬼獲權後潛伏，以減少被社群發現的機會，因反破壞而獲權者應在有關工作上保持活躍。我建議過濾器助理如三個月沒有參與反破壞活動，經舉報後可提早除權。--Temp3600（留言） 2022年11月6日 (日) 16:22 (UTC)

  三個月的活躍度要求和防泄漏應該說關係不大，有心人自然很容易讓自己達到需要的活躍度。--Tiger（留言） 2022年11月16日 (三) 14:05 (UTC)

  的確如此。這條的原意是讓過濾器助理多與社群中其他用戶交流，令破壞者更難隱藏自身性格。看來未必可行?--Temp3600（留言） 2022年11月17日 (四) 04:37 (UTC)

• 另外，同意Yining Chen的建議，申請者應對REGEX有一定了解才來申請。--Temp3600（留言） 2022年11月6日 (日) 16:22 (UTC)

(＋)支持以上提案。--冥王歐西里斯（留言） 2022年11月7日 (一) 03:05 (UTC)

• 另外，建議本權限必須由當事人主動提出申請。--Temp3600（留言） 2022年11月15日 (二) 15:42 (UTC)

題外話

( π )題外話 如果有查看已刪除頁面的權限（browsearchive、deletedtext，deletedhistory不確定）或用戶組，可能更方便某些任務（侵權、G5、破壞等歷史頁面的核查）。--YFdyh000（留言） 2022年11月8日 (二) 13:38 (UTC)

您是不是要找：WP:刪除員，WP:維護員。^{[開玩笑的]}--Yining Chen（留言|簽名頁） 2022年11月8日 (二) 14:11 (UTC)

準確說，去掉刪除/恢復權限的「刪除員」。不知道社群是否有興趣加在新用戶組上。目前是通過WP:AR，但時效性不好。--YFdyh000（留言） 2022年11月8日 (二) 14:59 (UTC)

？？去掉刪除/恢復權限還算是什麼刪除員。--Ghren🐦🕓 2022年11月11日 (五) 08:45 (UTC)

你的邏輯是不是有點混亂？這也沒說這是要啟用刪除員，這只是探討一個與刪除員類似，在具體權限上有所限制的<未知>而已。--MilkyDefer 2022年11月11日 (五) 12:42 (UTC)

所以我說的不是刪除員，而是能查閱私有（非公開）記錄的另一組權限，是否能合進去，參考藍桌圖書館、已刪百科等需求。已知新權限開放給高度可信用戶，唯低於管理員。大多數已刪除頁面，只是出於維護，可能沒有保密需求，需要保密的要監督。權限組可以命名如「非公開記錄查看員」（Non-public record viewer）。--YFdyh000（留言） 2022年11月11日 (五) 13:31 (UTC)

你這個「非公開記錄」很容易讓人聯想到真的要簽字且具有法律效力而且大陸人不能簽的NDA欸，你要不改個名字吧。--MilkyDefer 2022年11月11日 (五) 15:35 (UTC)

這是考慮到私有對應的private與「隱私」相同，擔心誤解。要不然，「私有記錄查看者（Non-public record viewer）」，中英非一致譯法。或者，進階記錄查看者，但表意很模糊。--YFdyh000（留言） 2022年11月11日 (五) 16:12 (UTC)

查閱員這個名字如何？可以查看AR，也可以查看過濾器。桐生ここ★[討論] 2022年11月12日 (六) 04:19 (UTC)

很難，或者你需要讓這個組擁有類RfA的授予標準（社群頁面公布請求、不少於7天的投票云云）。 Stang^★ 2022年11月11日 (五) 19:10 (UTC)

建議先完成分柝，再進一步調整，避免再次流產。--Temp3600（留言） 2022年11月14日 (一) 02:37 (UTC)

最近不授予回退權是不是和這有關？Evesiesta 2022年11月27日 (日) 17:07 (UTC)

不清楚，但應該沒有關係。--Temp3600（留言） 2022年11月27日 (日) 18:53 (UTC)

初步方案

按舊稿修改了一份草稿:過濾器助理，請諸君討論。--Temp3600（留言） 2022年11月15日 (二) 16:35 (UTC)

題外話#2：全域的m:Abuse filter helpers就是「過濾器助理」，不知道為什麼要翻譯成「防濫用編輯器幫助者」，是時候正名一下了（叫全域過濾器助理？會不會誤以為是「全域過濾器」的助理？） ——魔琴 [ 留言 貢獻 ] 2022年11月15日 (二) 16:46 (UTC)

@Liuxinyu970226：還在嗎--Temp3600（留言） 2022年11月15日 (二) 17:14 (UTC)

贊成更名，「全域過濾器助理」挺好的。「幫助者」應只是粗譯遺留。--YFdyh000（留言） 2022年11月16日 (三) 11:03 (UTC)

問題一：對比中維和英維的兩個過濾器助理頁面，英維是只有admin以上的用戶有abusefilter-view-private權限，那在中維，abusefilter-view-private的權限應該是像現在一樣，回退員也有，還是管理員以上的才有這個權限？

問題二：檢視垃圾連結封鎖清單日誌這個權限在英維得是過濾器助理以上的用戶才有，但是中維只要是個User就有了，要不要調整之類的。一直不理解為什麼為什麼過濾器39、92是不公開的，但是黑名單的閱讀權限就放得這樣低。（這算是個無關問題，只是剛好看到而已）

問題三：啟用雙因素驗證有這個需要嘛？在我的眼中這不是一個很重要的權限，不一定要雙因素驗證。--Ghren🐦🕘 2022年11月16日 (三) 01:53 (UTC)

1. 英維的管理員數量多很多。討論的不就是該權限從回退員移到低於管理員的新用戶組嗎。2. 不了解這個權限。3. 有一定必要，已知需求源自「潛伏」風險，而查看過濾器不留日誌，可能難以感知賬號被盜用？--YFdyh000（留言） 2022年11月16日 (三) 11:07 (UTC)

啊，抱歉，我看錯了。問題一應該是這樣：對比中維和英維的兩個過濾器助理頁面，英維是只有admin以上的用戶有abusefilter-log-private權限（檢視標記為非公開的濫用過濾器日誌項目），那在中維，abusefilter-log-private的權限應該是像現在一樣，回退員也有，還是管理員以上的才有這個權限？我複製的時候沒看清楚。不好意思。我想知道「檢視標記為非公開的濫用過濾器日誌項目」這個權限是也是收回，還是繼續保留在回退員上比較好。--Ghren🐦🕘 2022年11月16日 (三) 13:04 (UTC)

一起移入新用戶組。--YFdyh000（留言） 2022年11月16日 (三) 22:05 (UTC)

現在完全沒有討論要取消回退員abusefilter-log-private權限。也看出不出這個方案打算這樣辦。過去共識看來也不打算這樣辦。那是否要重複給這新用戶組這個權限就是個問題。要從回退員手中收回這個權限，要更深的討論。--Ghren🐦🕚 2022年11月17日 (四) 03:36 (UTC)

本提案討論的是解除回退員的abusefilter-view-private權限；英維也是User持有，為什麼放的這麼低請參閱gerrit:405670；「須有良好賬戶保安操守，例如開啟雙重認證（2FA）、設立高強度密碼、電腦不受惡意程序感染等」。 Stang^★ 2022年11月16日 (三) 12:37 (UTC)

• 感謝各位的回應。「拆分回退員之私密過濾器源碼閱讀權至另一用戶組」指的是移除回退員的abusefilter-view-private權限，並邀請社群中仍希望保留該權限的用戶申請加入新用戶組。回退員的abusefilter-log-private權限不在本討論範圍，但由於新用戶組的成員可獲得log-private權限，該權限獲得人數將可能上升。--Temp3600（留言） 2022年11月17日 (四) 04:45 (UTC)

  方案草稿中「資格要求」的第六點，在實際實行中似乎很難做到。缺乏有效的方式證明某用戶是否可信。--Yining Chen（留言|簽名頁） 2022年11月17日 (四) 11:12 (UTC)

  我看英維這一條也是自由心證而已，總之沒有人對這一點提出質疑就算是過關。--Temp3600（留言） 2022年11月17日 (四) 14:54 (UTC)

  顯然是基於共識，消除合理質疑。可能需要如一周或兩周的公示期。--YFdyh000（留言） 2022年11月17日 (四) 15:25 (UTC)

  確實缺乏有效的方式，共識制要求社群成員的絕大多數對於何為可信任有良好的認知，並有良好的說理能力。但我不認為我們的社群能達到這個要求。英文維基百科以我有限的觀察也只能說是勉強達到。實際做起來，做還是能做的，但多少會把問題積累起來到以後產生比較大的麻煩。--Tiger（留言） 2022年11月22日 (二) 17:03 (UTC)

  坦率說，在中維上高度可信要求可能無法嚴格地執行。但考慮到目前回退員持有view權是"沒有要求"，本項至少能收緊一些限制，並為解除不適合者的權限提供法規上的支持。--Temp3600（留言） 2022年11月27日 (日) 16:55 (UTC)

  尚且不談中維潛在的地區（組織）割裂（不信任）問題，假若將標準放得如此低，那麼是否反面說明不可信用戶（潛在的破壞者）也可順利擔任回退員？換言之，假若該方案能夠實施，那麼就根本沒有必要另設權限，只要找到「社群成員」對當前回退員列表逐一審查，把所有「不可信用戶」都移權+封禁，即可解決問題。又若模擬權限設立後的「公示」，那麼只要現在開放一個討論，所有用戶都可在其中指認自己認為「不可信」的回退員，最後統一公示一段時間以後直接移權即可，完全沒必要設立新權限嘛。如果在措施不完善的情況下貿然設立一個新權限，恐怕無益於反破壞問題的解決，反而不如不設立AFH權限，而由管理員代為處理源碼閱讀請求。--Yining Chen（留言|簽名頁） 2022年11月28日 (一) 11:12 (UTC)

  首先，目前已經有破壞者現正擔任回退員，這在上次的討論已經有不少用戶和管理員表達過。您所指的「排查回退員」方案，上次也有人提議過，但執行十分困難——部份回退員並不活躍，或已經退出一線反破壞工作多年，現行方針並無任何規則可用於解任他們，而且單憑猜疑，解任用權恰當但沒有參與反破壞工作的回退員在實務上也不可行。現行機制的弱點，正是破壞者可以先混到回退員，然後保持低活躍狀態，以此逃避反破壞小組的監視，而使用abusefilter-view-private權限亦無任何紀錄可查，導致無任何方法可以找出此等內奸。其次，直接由管理員查閱的方案上一次也有討論過（應該先上一次最先就是討論此方案），並已經被社群駁回。--Temp3600（留言） 2022年11月29日 (二) 14:39 (UTC)

  您所說的「單憑猜疑」解任回退員，與「單憑猜疑」拒絕AFH申請有什麼區別呢？--Yining Chen（留言|簽名頁） 2022年11月30日 (三) 01:55 (UTC)

  拒絕AFH申請的主要原因應是「用戶不符合資格要求」，即身為回退員但未有在反破壞工作中活躍；自稱將維護AF但沒有兌現承諾等。這些都是客觀的理由。至於分別，則在於AFH與回退員所需的信用等級不同。回退員如無法取閱敏感資料，則其權限可造成的破壞十分有限，要求先有違規行為後再解任依然合適；但AFH可以取得敏感資料，且缺乏監察途徑，即使沒有過違規行為，仍有可能不適合獲權。--Temp3600（留言） 2022年11月30日 (三) 03:25 (UTC)

  那麼該如何處理地域問題呢？作為例子，2022年9月管理員選舉中有兩名候選人被質疑「與WMC關係千絲萬縷」「前與WMC的關係緊密」「WMC仍潛伏於社羣中」，可見某些人至今仍不能做到對WMC成員在處理隱私信息（廣義）方面的基本信任。該如何才能確保此類偏見在AFH的申請過程中不會出現，並且不會對申請過程造成干擾呢？或是說AFH權限不接受WMC成員（即大陸用戶）的申請？--Yining Chen（留言|簽名頁） 2022年11月30日 (三) 05:22 (UTC)

  另設用戶組僅是遵循最小權限原則。對於雙面人問題，目前權限機制（無日誌）不能解決，要依靠其他方法。--YFdyh000（留言） 2022年11月30日 (三) 07:05 (UTC)

第一階段公示：確認分拆

現按上方的共識，進行第一階段公示，確認將AF源碼閱讀權(abusefilter-view-private)從回退員權限中移除。本項的實施則預計在整套方案通過後一次過執行。現就此 公示7日。

新用戶組的細則則仍屬討論階段，誠邀各位就獲權細則，除權條件等細節作深入討論。--Temp3600（留言） 2022年11月27日 (日) 17:01 (UTC)

提議DYK允許使用陳述句。

理由如下：

1. 一些編者為了讓答案唯一而硬湊問題，疊加多個條件，導致問題變得非常冗長。
2. 一些問題根本沒有吸引力，無法吸引讀者點擊，不如直接把答案展示出來。
3. 一些事實本身已經足夠特殊，但是因為答案不唯一而不得不繼續疊加一些其它條件，或者使用「除了……之外還有」的方式排除其它答案，這些都降低了可讀性，不如改為陳述句，使用「最……之一」的用詞。

舉例：

1. Talk:開基天后宮，原問題為「臺灣府城唯二建於明鄭時期的媽祖廟除了大天后宮外還有哪一座媽祖廟？」我認為完全可以改為「開基天后宮修建於明鄭時期，是台灣最早的媽祖廟之一」。
2. Talk:鐳，問題為「除了釙以外，居禮夫婦還發現了哪種化學元素？」存在更有吸引力但是答案不唯一的事實，例如「鐳元素具有強烈的放射性，但是卻曾被用作發光顏料。」
3. Talk:檮杌劍虎屬，為了保證答案唯一而疊條件「並且是「半劍齒虎屬—勇劍虎屬—鋸齒虎屬」演化過程中產生的一個旁支」，導致問題過於專業化，欠缺對讀者的吸引力，如果允許使用陳述句，就完全可以改成「2021年新發現的劍齒虎檮杌劍虎屬的名字來源於中國古代傳說中的凶獸。」
4. Talk:中華人民共和國機動車行駛證，完全可以改為「機動車駕駛人在中國內地駕車上路時必須隨身攜帶機動車行駛證」。

--——🦝英特浣熊耐爾_{（留言・貢獻）} 2022年11月2日 (三) 10:06 (UTC)

(＋)支持，每次都是絞盡腦汁想問題，好像在問題上花的時間比條目本身都要多了。-- B-MIKE -留|簽 2022年11月2日 (三) 17:20 (UTC)

特別提示：過去曾經有過如下討論：「提議調整新條目推薦問題指南時效性描述（暫時性折中方案）」，該討論圍繞DYK的時效性進行，並在中途有至少AT明確表示要求改革，而Temp3600等人也沒有對其表示反對。魔琴表示過「不是很支持廢除提問」但也不知道理由。我個人希望這次討論不要再繞回「時效性」的老問題上畫圈。 --MilkyDefer 2022年11月2日 (三) 14:01 (UTC)

(＋)支持，DYK問題過於苛刻，有些真的很丟吸引力。還有，什麼都要加個「截止到某年某月」，很無聊，不寫的話不就默認截止到現在嗎？「中國歷史上唯一的女皇帝是誰？」這個問題，在705年發表和在2022年發表又有什麼區別？ ——魔琴 [ 留言 貢獻 ] 2022年11月2日 (三) 12:33 (UTC)

您沒有考慮萬一將來中國大陸重新稱帝的情況啊，怎能這樣寫啊。啊，怎能寫到某年某月呢，萬一明天就過期了得怎辦呢。--Ghren🐦🕘 2022年11月2日 (三) 13:32 (UTC)

當你在按月份查看過去的新條目候選存檔的時候你就應當已經知道這個DYK項目的有效時間點了。 --MilkyDefer 2022年11月2日 (三) 13:42 (UTC)

過往發生過有問題在首頁展示途中還未下架就發生「現在」已經失效的情況，所以才有這個要求。另外注意主題首頁的DYK存檔是不記時間的。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年11月2日 (三) 14:07 (UTC)

有按日存檔的（Wikipedia:新條目推薦/供稿/2022年11月1日），只是Wikipedia:新條目推薦沒有這樣按日列舉，可以參考英維的對應頁面那樣按天劃分。如果是擔心問題還未下架就失效，那能確保在短期（甚至只需要一天內）有效就行，何必需要永久呢。--BlackShadowG Slava Ukraini! 2022年11月2日 (三) 15:03 (UTC)

我想上次已經有說過，我們不能確定一個條目在哪一天登上首頁和Portal，以及一個條目會展示多久時間（Portal那邊試過有DYK條目放在首頁三年），所以確保在短期有效的可操作性不高。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年11月2日 (三) 15:10 (UTC)

算了這個時效性可以以後再談，反正多幾個字觀感不會很差，重點是解決陳述句的問題。 ——魔琴 [ 留言 貢獻 ] 2022年11月2日 (三) 16:12 (UTC)

(＋)支持，一個條目或多或少會有一兩個所謂可以放上來的「冷知識」，但未必能問出問題來。 --MilkyDefer 2022年11月2日 (三) 13:42 (UTC)

我認為時效性還是要考慮的，不過就簡單加一個限制條件。至於廢除強制提問格式，倒是沒什麼意見，不過還是建議能提問就提問吧。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年11月2日 (三) 14:14 (UTC)

(＋)支持廢除強制提問格式，我也常常不得不為一篇想不出有什麼特別的條目硬生生地提出個根本沒有吸引力問題，確實很沒意義。不過需要(※)注意陳述句和疑問句並行可能導致讀者觀感不佳。--BlackShadowG Slava Ukraini! 2022年11月2日 (三) 14:37 (UTC)

• 建議"你知道.....嗎?"的偽裝型陳述問句。--Temp3600（留言） 2022年11月2日 (三) 15:50 (UTC)

  也許中文不好操作？讀起來會有點怪。 ——魔琴 [ 留言 貢獻 ] 2022年11月2日 (三) 16:15 (UTC)

我未見這些陳述句比原問句更有吸引力和趣味性，甚至可以說吸引力和趣味性幾乎是不存在的。Fire Ice 2022年11月2日 (三) 16:45 (UTC)

• (＋)支持，終於有不少用戶覺得DYK一定要使用問句提問是很麻煩的了嗎？看誰以後還要提議把「新條目候選」更名為「條目候選」吧。這種早期中文維基百科的DYK制度真的該改改了，要不然以後還是都只能「截至某個時段為止」、「是哪個」等問句的問法。不過，也不應該說以後問句的問法就要廢除，這類陳述句的題目還是要有一定邏輯才行。還有，請問DYK題目的答案還要保持唯一性嗎？如果是，那就實質上來說還是沒有改革，到頭來就是美意打折扣而已。為何要確保DYK題目的答案唯一性呢？有不少名稱都有多種說法，憑什麼只能是其中一種說法當DYK題目的答案呢？也已經強調到爛掉不想說了，以後還想寫出「條目候選」的難度只會越來越難。因為條目都被前面的人寫去了，請問後面的人是要寫什麼？幾乎沒有東西了啊。這個獨裁社群倘若再不認真思考改革「條目候選」，也沒什麼人願意要寫維基百科了。因為若基本想要查詢的資訊都可以在維基百科查得到，那樣哪還有寫「條目候選」的必要呢？更別提有時還因為沒有足夠支持票而落選DYK的不佔少數，呵呵。要不要鼓勵人拉票呢？獨裁社群仔細想過吧，「新」一字真的該廢除了。--Z7504非常建議必要時多關注評選（留言） 2022年11月2日 (三) 17:35 (UTC)
• (～)補充：講一個「條目候選」很明顯的例子：

「 由羅伯特·R·布萊克和簡·莫頓於1964年共同建立的哪種風格模型理論劃分出五種不同的領導風格？ 」 ——管理方格理論的「條目候選」題目

答案：「管理方格理論」。那到底是為什麼就不能開放其它也是正確的答案（管理格道、五分式領導）當作「條目候選」的答案呢？難道還要執著「DYK題目的答案唯一性」嗎？--Z7504非常建議必要時多關注評選（留言） 2022年11月2日 (三) 17:40 (UTC)

• 我覺得明文允許一般陳述可能降低吸引力，顯得乏味，但應明文不禁止非設問句，既指引級效力，DYK討論認為可以就可以。前綴「你知道嗎」也可以考慮，不過首頁的標題處本來就有。時效性有意義但應注意常識。--YFdyh000（留言） 2022年11月2日 (三) 19:32 (UTC)

  前綴也不用總是牽強，一定要使用「你知道嗎？」吧？「你知道嗎？」是種問句，然後問句的後面居然可以不用問號結尾，不是很奇怪嗎？「條目推薦」或者其它更好的名稱難道不好嗎？這種「條目候選」真的是悲哀，不一定是合適的長久之計提案。「新」一字居然從來都不考慮廢除，以後的用戶真的會越來越難寫條目。--Z7504非常建議必要時多關注評選（留言） 2022年11月2日 (三) 19:53 (UTC)

  對於「新」，如果不考慮鼓勵擴充和時事，或許首頁放些條目評選或當選的輪轉也不錯。--YFdyh000（留言） 2022年11月2日 (三) 21:57 (UTC)

• (＋)強烈支持開放使用陳述句，另外再次重申支持取消時效性要求。--Wikimycota🧬 2022年11月3日 (四) 00:10 (UTC)
• (！)意見，看了眼en，似乎允許陳述性問句，類似「禿鷲號巡洋艦曾經在美國海軍服役？」但我不建議過度使用陳述句。因為這是「DYK」，「Did you know」，「你知道嗎」，正是這樣的拋包袱問句來作為吸引讀者注意的作用。過於平鋪直白似乎失去了作為DYK的有趣點。對於時效性，由於這個問題需要存檔等因素，我認為還是需要保留或者能以提出時為基點確認到答案。——Sakamotosan路過圍觀 | 避免做作，免敬 2022年11月3日 (四) 01:07 (UTC)

  BTW，居里夫婦共同發現的化學元素，根據條目的描述，除了釙，就是鐳。這個答案唯一。而「機動駕駛證」那個如果用問句方式也可以表述為「機動車駕駛人在中國內地駕車上路時必須隨身攜帶哪種證件？」——Sakamotosan路過圍觀 | 避免做作，免敬 2022年11月3日 (四) 01:11 (UTC)

  後者設問答案不唯一，需注意條目是行駛證而非駕駛證。另外，「隨身攜帶」定義含糊（隨車攜帶、電子行駛證、離車時是否攜帶）、似非法律明文規定，不算完美。--YFdyh000（留言） 2022年11月3日 (四) 01:46 (UTC)

  我認為提問的方式是很好的，只是目前非要把條目藏起來，什麼條目幾乎都是「哪個xxxx？」以上面舉例的幾個來看，完全可以這樣提問：

  • 開基天后宮修建於何時？
  • 化學元素鐳是誰發現的？
  • 2021年新發現的劍齒虎檮杌劍虎屬的名字來源是什麼？
  • 機動車駕駛人在中國內地駕車上路時需要隨身攜帶機動車行駛證嗎？

  不要拘泥於某一種提問方式就好了--百無一用是書生 (☎) 2022年11月3日 (四) 02:43 (UTC)

  我覺得這樣不錯，要問的不拘泥於條目標題，可能還更有吸引力。--YFdyh000（留言） 2022年11月3日 (四) 03:20 (UTC)

  同覺得這樣不錯。——Sakamotosan路過圍觀 | 避免做作，免敬 2022年11月3日 (四) 03:39 (UTC)

  這種想法很好啊，特別是「檮杌劍虎屬」一問，比藏條目問題、陳述句效果好多了。不過對於「開基天后宮」，問「修建於何時」似乎沒有「是台灣最早的媽祖廟（之一）」的效果來得好…… ——魔琴 [ 留言 貢獻 ] 2022年11月3日 (四) 04:07 (UTC)

  (▲)同上附議。--DvXg 📬 2022年11月4日 (五) 06:50 (UTC)

為何不能問：管理方格理論是誰建立的？--百無一用是書生 (☎) 2022年11月3日 (四) 02:47 (UTC)

也就是說，不將新條目推薦問題之主體限定在條目本身，而是條目之內容亦可，對吧？我同上面幾位持類似看法，覺得這是一個不錯的形式。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年11月3日 (四) 03:58 (UTC)

確實可以這樣問，但此時問題可能就要變成整條都要藍連了。即：「管理方格理論是誰建立的？」--Z7504非常建議必要時多關注評選（留言） 2022年11月3日 (四) 05:12 (UTC)

不隱藏條目名就只鏈條目名，才對吧。--YFdyh000（留言） 2022年11月3日 (四) 05:27 (UTC)

管理方格理論是「由羅伯特·R·布萊克和簡·莫頓於1964年共同建立的領導風格模型理論」，如果要用同樣這個問題套用在這兩位上，請問該用羅伯特·R·布萊克還是簡·莫頓做答案才對？還是兩個同時上去？雖然知道這兩位不大可能被提名「條目候選」，但這樣顯然就已經不符合首先提過的「DYK題目的答案唯一性」了。--Z7504非常建議必要時多關注評選（留言） 2022年11月3日 (四) 05:35 (UTC)

沒有強制用陳述句，只需「誰與某某一起創建了……」（嫌短可改成「哪位xx學家）。同時登上，頂多是謎底在謎面上，而且設定type參數似乎能避免此情況？--YFdyh000（留言） 2022年11月3日 (四) 06:00 (UTC)

(！)意見：如果允許不隱藏條目名稱的問句，那麼將有可能出現同一條問句但可以被兩個條目使用的情況，例如：

• 化學元素鐳是哪位物理學家與他的妻子一起發現的？
• 化學元素鐳是哪位物理學家與他的妻子一起發現的？

如果兩個條目同一時間參加評選，不怕在評選時會混淆投票者嗎？（例如投票者本來想投給鐳，但因為看錯了相同的問句而投錯給皮埃爾·居里）另外反對取消時效性，除非首頁隨時失效的問題有完美解決方案。--Maccomcre（留言） 2022年11月3日 (四) 05:04 (UTC)

您漏掉了，如果他的妻子也有知名度，也是可以參選的。如果要反對時效性用法，真的就是所謂的沒有改革結案而已，一點意思也沒有。總之，「條目候選」的問題本身就一大堆。「羅馬不是一天造成的」，如果想要認真改革「條目候選」那就仔細想清楚吧，否則以後這頁面就是逐漸往淘汰的方向了。--Z7504非常建議必要時多關注評選（留言） 2022年11月3日 (四) 05:12 (UTC)

不感覺會那麼巧合。完全可以微調語句。可以指引級勸止同期採用相似句子。投票者看錯是投票者責任，有加粗和條目名信息。--YFdyh000（留言） 2022年11月3日 (四) 05:29 (UTC)

投票看條目名應該是看那行小字吧（ ——魔琴 [ 留言 貢獻 ] 2022年11月3日 (四) 07:57 (UTC)

如果DYKC的投票者們真的都是認真投的，我就不會問這個問題。但現實是DYKC很多人都是粗心隨意，說他們有責任感、會看小字而不會搞混，完全是痴人說夢話。--Maccomcre（留言） 2022年11月3日 (四) 08:35 (UTC)

不管是否同時、問題是否相似，看錯/評錯條目都可能發生。除非強制填寫有意義的理由，但那是另一個議題。--YFdyh000（留言） 2022年11月3日 (四) 09:36 (UTC)

其它情況也會有這種混淆我當然知道，只是想說兩個相同問句以現在社群心態來看，混淆的機會應該會比較高。--Maccomcre（留言） 2022年11月3日 (四) 10:21 (UTC)

• (＋)支持，直接把首段定義句抽出來，方便又快捷，不用花費無謂的時間去想問題。—AT 2022年11月3日 (四) 09:44 (UTC)
• 初步衡量了上面的意見，敝人也不得不承認完全改為陳述句、完全廢除問句最好，那麼就完全不用爭論問句會產生甚麼問題。但陳述句還是有需要設定時效性，像是上面行駛證的例子至少也要改為「自(某個時間)起，機動車駕駛人在中國內地駕車上路時必須隨身攜帶機動車行駛證」；單單「機動車駕駛人在中國內地駕車上路時必須隨身攜帶機動車行駛證」的話，如果上首頁當日大陸政府突然推出新政策要帶另一種證還要即時生效，那就完了。首頁始終是可見度極高的地方，一些極端罕見的情況我們也不應該忽視。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年11月3日 (四) 10:11 (UTC)

  如此約束時效性我認為將過於複雜、捨本逐末，很多東西不可能用一句話準確概述，比如試點地區、政策曾經暫停、條件性許可等情況。「要帶另一種證還要即時生效」可能不該過分擔心、是設問句有問題，至少還有駕駛證，抬槓還有年檢標（也已試點電子版）等。--YFdyh000（留言） 2022年11月3日 (四) 10:35 (UTC)

目前不贊成完全改成陳述句，風格變化過大，可能會有實際問題（比如地區詞和別名處理？）。--YFdyh000（留言） 2022年11月3日 (四) 10:26 (UTC)

• (！)意見：必須用疑問句本來就是一個莫名其妙的陋習，早就該廢除了。不過也不需要不准用疑問句。陳述句疑問句都允許不就好啦？ —ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2022年11月3日 (四) 11:12 (UTC)

  嗯，那我就以今天的DYK舉個例子吧：

• • 哪艘德國U艇於1917年11月18日後在芬蘭灣失蹤？
  • 奧莉維亞·羅德里戈單曲《既視感》取樣了泰勒絲的2019年歌曲〈慘痛夏日〉。
  • 英國、丹麥、挪威、瑞典等君主立憲制國家對王室成員使用哪一個敬稱，一般可以被簡稱為「HRH」？
  • 商業模式圖是用於描述企業組織開發新商業模式以及記錄現有商業模式的策略管理範本圖。
  • 青島劇院建成於1940年，2010年因青島東西快速路三期工程拆除。
  • 哪位波蘭立陶宛聯邦貴族建立了扎莫希奇城？

大概允許陳述句和疑問句並存會是這樣的效果，不知社群怎麼看。--BlackShadowG Slava Ukraini! 2022年11月3日 (四) 12:36 (UTC)

以上感覺很怪，但應該是文法問題，完全沒有給出有吸引力的元素。以下如何：

• 美國歌手奧莉維亞·羅德里戈的單曲《既視感》使其成為首位兩支單曲空降Billboard Hot 100榜單前10的藝人。
• 商業模式圖，也稱商業模型九宮格，是用於描述企業組織商業模式的策略管理範本圖。

--YFdyh000（留言） 2022年11月3日 (四) 13:18 (UTC)

• 應該就只有中文版會以疑問句為DYK條目作引吧，其他版本的做法一般是把介紹條目的短句套在「你知道⋯⋯嗎？」這問題裏頭，或者像日文版那樣，直接寫一段小作文介紹條目。我對是否解套陳述句沒甚麼意見，但感覺這個問題與其說是有沒有人支持的問題，倒不如說是執行上的問題：首先，總不能「（你知道）哪個鐵路站位於香港體育館和紅磡海底隧道的旁邊（嗎）？」和「（你知道）機動車駕駛人在中國內地駕車上路時必須隨身攜帶機動車行駛證（嗎）？」一起出現在DYK模板裏吧？撇除有趣沒趣這一點，這樣做對後者可能有點不公平（謎底都揭開了，讀者還會想去讀嗎？）。其次，你們如果要廢除問句，那可能就得畫一條界線，截止日之前提名的條目仍然要遵守既有的問題規範，之後提名的條目就適用新的介紹規範（？）。另外也要保證最後一條使用疑問句作引的條目不會上畫2小時後就被刷下來。至於時效性問題，我有想過能不能在DYK模板加一條備註去迴避這個問題（像「上述事實以條目當選時為準，詳情請參閱條目討論頁」這樣）。--春卷柯南－發前人所未知 ( 論功行賞 ) 2022年11月4日 (五) 02:51 (UTC)

  （你知道）機動車駕駛人在中國內地駕車上路時要不要隨身攜帶機動車行駛證（嗎）？--百無一用是書生 (☎) 2022年11月4日 (五) 03:24 (UTC)

  「謎底都揭開了，讀者還會想去讀嗎？」怎麼就知道讀者不會去讀呢？有沒有什麼數據或理論支持這種假說？--百無一用是書生 (☎) 2022年11月4日 (五) 03:28 (UTC)

  英維基本絕大多數都是陳述句。我認為「鐳元素具有強烈的放射性，但是卻曾被用作發光顏料。」絕對比「除了釙以外，居里夫婦還發現了哪種化學元素？」更優吸引力。--——🦝英特浣熊耐爾_{（留言・貢獻）} 2022年11月4日 (五) 09:01 (UTC)

  此句中「鐳元素」改成「什麼元素」，我覺得更有吸引力，但實踐中可能有答案唯一等問題。不然它只是一句小知識，不太讓我產生了解鐳元素的動力。--YFdyh000（留言） 2022年11月4日 (五) 09:04 (UTC)

  答案確實不唯一。--——🦝英特浣熊耐爾_{（留言・貢獻）} 2022年11月4日 (五) 13:25 (UTC)

  我想書生兄是看不到他想要的硬數據，但我想表達的意思是，單純的疑問句會顯得比單純的陳述句有趣，語文課本該有說過使用疑問句作引，可以利用讀者的好奇心，吸引他們的注意吧。不過，如果加入「是否有趣」這個變量，我這個立論可能就要打個折扣，好比我就說不出「（你知道）哪個政黨曾在2014年推出充斥着女子叫床聲的競選廣告（嗎）？」和「（你知道）《月亮代表我的心》是馬來西亞伊斯蘭黨的競選歌曲（嗎）？」哪個會比較有趣。-春卷柯南－發前人所未知 ( 論功行賞 ) 2022年11月4日 (五) 18:13 (UTC)

  就「謎底都揭開了，讀者還會想去讀嗎」，有謎底我也未必想閱讀，要看這個主題和可能涵蓋的內容是否有意思。如果很容易猜到謎底，或者看了標題就大概知道寫了什麼，我可能同樣不想閱讀。--YFdyh000（留言） 2022年11月4日 (五) 04:27 (UTC)

• 部分(－)傾向反對。可以接受不再要求問題的「疑問代詞」代替的一定是條目名（也即不要求謎底一定要是條目本身，如當前候選的「利沃夫在歷史上曾歸屬於哪些國家？」），進一步地接受是非問題也可以（「中國內地是否要求機動車駕駛人必須隨身攜帶行駛證？」）。但是允許直接直陳對形式統一的破壞太明顯了，除非反過來要求必須用陳述句（但那樣就完完全全失去了「謎語」的吸引力了）。DvXg 📬 2022年11月4日 (五) 07:04 (UTC)

  我認為只要是問了一個有意思的問題就行了，問的方式可以多樣--百無一用是書生 (☎) 2022年11月4日 (五) 08:11 (UTC)

  「利沃夫在歷史上曾歸屬於哪些國家？」，我可能會認為答案應該是「利沃夫曾歸屬的國家列表」或類似的，即使有粗體提示，也會產生這種直覺。謎底不是條目本身的提問個人認為觀感不佳。--BlackShadowG Slava Ukraini! 2022年11月4日 (五) 10:20 (UTC)

  私以為這個聯想的範圍只要是條目主體的範圍就可以（也就是讀者打開鏈接可以找到答案、並且是主題的一部分就可以），不必要求全等。當然應當鼓勵謎底對條目主題越重要越好。--DvXg 📬 2022年11月4日 (五) 16:32 (UTC)

  是非題在下實驗過「能否聽出一個鼓的形狀？」和「不含數字9的正整數倒數和，有限抑或無窮？」當時沒有受到反對。不過例如前者的確全篇條目就是圍繞該條是非題，其他條目可能較難問出佔條目比重足夠大的是非題？——$\definecolor {my}{rgb}{0.04,0,0.5}\color {my}{\mathsf {htc_{23}}}$（留言） 2022年11月4日 (五) 21:42 (UTC)

(？)異議：如果二者並存，設想疑問句在上，陳述句在下，毫無關聯的兩個事物相鄰可能會令讀者誤解，比如：

• 《港區國安法》首案被告是誰？
• 香港女子某某某由於在法庭對被告致辭鼓掌和召喚包青天，被判煽動罪成立。

如何解決此問題？——Gohan 2022年11月4日 (五) 14:00 (UTC)

這種情況不好解決，也許只能依靠使用相同的type參數來避免同時展示？即便只有設問句，也可能有此種巧合與誤解發生吧，所以我覺得無須過度擔憂。--YFdyh000（留言） 2022年11月4日 (五) 18:40 (UTC)

上條日本地理，下條台灣建築，並不少見。相同type意味著不同的輪候機制。--Gohan 2022年11月5日 (六) 01:53 (UTC)

個人認為不是什麼大問題，非要解決的話可以把現在每項前面加上序號。--Kedouv（留言） 2022年11月5日 (六) 05:56 (UTC)

@神秘悟饭：我自己反而感覺疑問句與陳述句同時出現不會有太大的問題。就你舉的這個例子而言，正常人的閲讀是一定會看上文下理的，但凡看一看格式就知道這相鄰的兩項原則上並無關聯。Sanmosa _{Je sers} 2022年11月24日 (四) 15:05 (UTC)

(＋)滋磁，雙手贊成。只要能順接「你知道嗎」，根本沒有必要限定句式。當然以後評選時可以就標題的趣味性本身多做討論，鼓勵大眾更積極的對評選中的DYK標題提供建設性意見。--南冥大鵬👈批判我一番報道有偏差Ω微小的工作歷史的進程 2022年11月4日 (五) 23:52 (UTC)

關於是否會引入其他問題

• 借我們站內的大河內教授一言：「提案是否會引入其它問題？如果會，該問題是否重要？如重要，有何措施加以彌補？」

誠然推行允許陳述句格式能解決很多問題，然而也會出現新的問題；比如上面有編者就提到統一格式的混亂疑慮，這就進而衍生出了現行提問方法需不需同新法並行？如果有格式混亂，現行提問是否需廢除？我想截至目前各位的主流意見都是認爲陳述句可被允許，但也請探討之後的問題。如果後兩個問題沒能得解決，我認爲乃非各位一句「直接陳述好」「強制提問壞」的局限性表態能夠解決的。——詠梅閣—WMLO（留言） 2022年11月7日 (一) 23:44 (UTC)

對於格式混亂的問題，我認為可以通過輪流展示的方法來解決。比如已通過的提問形式DYK達到6篇的時候便可一同登上首頁，陳述形式也是一樣，這樣就沒有格式混亂的問題。--AT 2022年11月9日 (三) 02:38 (UTC)

由於不希望條目展示的時間少過半天，這樣做的話機械得最少隔半天才能更新一次，意味着機械將會很難自動調節頻率（不能逐條計算時間）。而一旦需要更新的其中一邊的下一個輪次花費了較長時間才等滿6個時，整個更新程序會出現拖延問題。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年11月9日 (三) 03:03 (UTC)

雖然我說了輪流，但是如果其中一邊較多的話，而另一邊不足6篇的時候，那可以讓更多的一邊先上首頁，這樣的話應該就沒有拖延的問題。--AT 2022年11月9日 (三) 04:06 (UTC)

這頂多衹能解一半問題吧，兩邊都不夠數的話就衹能讓人乾等了。就以上個月的排隊情況來看，同時至少10篇已確認數量的時數佔不到一半，假如上個月就已經這種方法來更新（也假設陳述句和問句使用情況是一比一），估計會令不少條目在投票完後還要等多約兩天才上到首頁。簡單說就是現有的方法評選越冷清就等得越短時間（完了幾乎即上）；而您提到的新方法就有點反了過來——評選冷清時等候的時間可能變長（完了再要等齊人）。如果因為條目太多而要久等這下還算正常，但條目太少也要久等的話這下就不十分好了。而且這種方法會否讓提名人產生跟大隊的心理？——明明想用陳述，但當下看見沒幾多人用陳述，為了避免花時間等齊人而放棄使用陳述。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年11月9日 (三) 05:37 (UTC)

這樣的話也許可以考慮同時採用定時制，比如說通過後一天內，如果任何一邊達6篇的話先上，兩邊都不足6篇的話，先讓近期未上的一邊先上。然後，再設下限，例如當已經通過超過兩天的DYK優先上首頁。具體來說，比如1月1號有12篇陳述，3篇提問通過，根據這個建議，先讓陳述的6篇先上首頁。之後一天內如果提問累積達6篇，便讓其先上首頁，再到陳述，如果提問仍然不足6篇的話，讓陳述剩餘的6篇先上。去到1月3日，無論陳述有多少篇均讓提問先上。當然這個時限是可以討論的，甚至上首頁的數目也可以商討，不一定是一天兩天或6篇。至於跟大隊的問題，我覺得DYK沒什麼好急，反正通過的話遲早都能驞，快點上也沒什麼特別的好處，因此誘因不大。況且，如果出現一邊倒的情況，導致有人願意妥協的話，我想那就是時候討論棄用沒人用的一邊了。--AT 2022年11月9日 (三) 07:06 (UTC)

衹能說機器的改造工程會很浩大吧，中間要計算的東西多了幾重，不太有信心可以很快改得好…… --街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年11月9日 (三) 07:40 (UTC)

要兼顧多方面下的必然結果...或者看看有沒有人有更好的方法吧。--AT 2022年11月9日 (三) 11:41 (UTC)

我覺得AT這個方案停怪（）如果每個句子前面加上一個小圖標會不會解決？

• 《港區國安法》首案被告是誰？
• 香港女子某某某由於在法庭對被告致辭鼓掌和召喚包青天，被判煽動罪成立。
• 機動車駕駛人在中國內地駕車上路時需要隨身攜帶機動車行駛證嗎？
• 開普勒定律是誰發現的？
• 開普勒定律是誰發現的？

以上舉幾例試驗一下。 ——魔琴 [ 留言 貢獻 ] 2022年11月10日 (四) 17:58 (UTC)

感覺有點亂，可能喧賓奪主。問號和嘆號的區別不太明顯。新增句式可能不錯。不太贊成條目鏈接放在長句尾部，粗體不是很明顯。如果多個內鏈，被內鏈的其他條目應同時保證足夠的質量。--YFdyh000（留言） 2022年11月10日 (四) 18:05 (UTC)

• 《港區國安法》首案被告是誰？

---

• 香港女子某某某由於在法庭對被告致辭鼓掌和召喚包青天，被判煽動罪成立。

---

• 機動車駕駛人在中國內地駕車上路時需要隨身攜帶機動車行駛證嗎？

---

• 開普勒定律是誰發現的？

---

• 開普勒定律是誰發現的？

那我覺得這樣更好。—AT 2022年11月11日 (五) 04:42 (UTC)

占用空間變大了不少。長句如果折行（寬度受限）還好，不然排版可能不好看。--YFdyh000（留言） 2022年11月11日 (五) 13:07 (UTC)

1. 《港區國安法》首案被告是誰？
2. 香港女子某某某由於在法庭對被告致辭鼓掌和召喚包青天，被判煽動罪成立。
3. 機動車駕駛人在中國內地駕車上路時需要隨身攜帶機動車行駛證嗎？
4. 開普勒定律是誰發現的？
5. 開普勒定律是誰發現的？

有序列表呢？--Kedouv（留言） 2022年11月11日 (五) 06:19 (UTC)

本就不分先後、可能隨機展示，所以不太建議有序列表，以免過度解讀排名。--YFdyh000（留言） 2022年11月11日 (五) 13:07 (UTC)

上面的示例中的兩個「開普勒定律是誰發現的？」就看起來很容易混淆。--BlackShadowG Slava Ukraini! 2022年11月20日 (日) 14:10 (UTC)

舉了一個比較極端的例子，才能看得出問題 囧rz……所以該怎麼解決，三個方案似乎都不是合適。 ——魔琴 [ 留言 貢獻 ] 2022年11月22日 (二) 17:37 (UTC)

@AT@BlackShadowG@Cdip150@Kedouv@YFdyh000@魔琴 如果最終在這裡沒能討論出統一的抉擇方式，不妨使用公投解決如何？——詠梅閣—WMLO（留言） 2022年11月23日 (三) 21:36 (UTC)

如果全部方案都有缺點，且各自的缺點都足以導致不能使用，投票強行得出方案衹是徒然，因為都執行不了。而且綜觀以上各人的意見，敝人也認為全部方案都不行。況且，社群對於能不能同時混合兩種展示？就以上的意見來看也沒有明顯的共識，連這個共識都沒有的時候，直接票選方案也沒有意義。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年11月24日 (四) 04:36 (UTC)

那建議不妨先針對混合展示與否此議題提出公決，比如：「針對DYK之推廣，您認為社群應從以下方案中選擇哪項以應對現有之觀感？

• 應維持現狀繼續使用提問式；
• 應廢除提問式仿英維等使用陳述式；
• 應發展中維特色DYK推廣主義，允許兩類並行。

若前二項之一得到通過，那方案使用的問題也得到解決，因為這只是換道菜與否的問題。如果是第三項得到通過，可能比較麻煩，但屆時也應有適當的環境針對此問題如何解決的討論，就如同這一年來針對RFA選舉的討論一樣。簡單來說，應先解決最基本的問題，否則這類討論最終顯也只會無共識結案。——詠梅閣—WMLO（留言） 2022年11月24日 (四) 13:29 (UTC)

先前討論有點雜。我覺得暫時「試行」允許陳述句（不強制要求問句）就好，如果「問題不當」，全可「用腳投票」，以便看出哪種更受歡迎、實際場景出現的問題。具體的展示和表述方式，似乎暫無共識，但可見當前方式存在多個反對，也非共識。--YFdyh000（留言） 2022年11月24日 (四) 13:39 (UTC)

不過有別於RFA、GA評審制這兩個僅關聯社群內部的試行方式；這次試行將直接牽涉到讀者面對首頁DYK的觀感...關於這點，各位覺得沒問題嗎？——詠梅閣—WMLO（留言） 2022年11月24日 (四) 13:45 (UTC)

我自己是覺得允許兩類並行也沒大問題，畢竟也算Unity in diversity。Sanmosa _{Je sers} 2022年11月24日 (四) 15:08 (UTC)

目前應該盡早接納使用陳述形式，再來考慮如何並行或是否廢除提問形式。至於提問和陳述相衝的問題，基於type能夠擋掉大部分同類條目，我想問題不大。--AT 2022年11月24日 (四) 15:56 (UTC)

目前上方疑慮意見在於：1. 問題與陳述相連會誤以為是設問；2. 同問句不同條目會導致混亂；3. 其它關於新句型的觀感問題。我覺得1、2出現概率極小，而且正如AT君所說，type可以擋掉同類條目（即疑慮1「設問」，對應上方舉例的1「國安法首案被告」和2「香港某女子」）。故我支持按現行格式試行接納其它句式（陳述、不藏條目的問句）。 ——魔琴 [ 留言 貢獻 ] 2022年11月24日 (四) 18:19 (UTC)

「同問句不同條目」若非刻意安排應較難出現，又或者等到兩個條目的提名皆通過，再合併成一句多個粗體條目上首頁？例如「開普勒定律是哪位天文學家發現的？」或者是en:Wikipedia:Did you know/Multiple Article Hook Hall of Fame的極端例子。假如僅有部分提名通過就衹為通過的條目加粗。——$\color [rgb]{0.04,0,0.5}{\mathsf {htc_{23}}}$（留言） 2022年11月24日 (四) 20:33 (UTC)

(－)反對試行，因為都已經看到效果是怎樣：

• 哪艘德國U艇於1917年11月18日後在芬蘭灣失蹤？
• 奧莉維亞·羅德里戈單曲《既視感》取樣了泰勒絲的2019年歌曲〈慘痛夏日〉。
• 英國、丹麥、挪威、瑞典等君主立憲制國家對王室成員使用哪一個敬稱，一般可以被簡稱為「HRH」？
• 商業模式圖是用於描述企業組織開發新商業模式以及記錄現有商業模式的策略管理範本圖。
• 青島劇院建成於1940年，2010年因青島東西快速路三期工程拆除。
• 哪位波蘭立陶宛聯邦貴族建立了扎莫希奇城？

認同上面有人說兩種並行觀感不佳，結尾有時問號有時又句號，我也覺得是一團亂，完全感受不到趣味在哪裡。--Maccomcre（留言） 2022年11月25日 (五) 05:43 (UTC)

先從三個選項之中取一個基本的共識

@AT@BlackShadowG@Cdip150@HTinC23@Kedouv@Maccomcre@Sanmosa@YFdyh000：還是主張因先將此議題之基要（即維持現狀、廢提取陳或兩類並行）付諸安全投票。應先取主流意見，再據此想辦法解決。有一個基本的共識，才能有合適討論的基礎。否則就如街燈同志所言，連並行與否的共識目前都不知道，自然討論是無法持續下去的。誠然，投票是解決問題的最終手段，可終究不想讓此討論無疾而終。——詠梅閣—WMLO（留言） 2022年11月25日 (五) 12:30 (UTC)

個人是支持兩類並行的，但同時認為其他維基人提出的混合展示導致的混亂也有解決的必要，以上的討論也是主要圍繞這一問題展開的。暫且再提一方案：陳述與提問分別展示，推送新項時判斷是哪一種類型，如新項為陳述句則展示陳述列表，反之亦然；特別的，開始時因陳述句不足六句則不展示，待數量達到時開始展示；此法唯須應對陳述最早的5項展示時間少於其餘項（且越早時長越短），不過或許應該大概有人願意。--Kedouv（留言） 2022年11月25日 (五) 14:11 (UTC)

或許會比AT的抱團方案清晰一些。 ——魔琴 [ 留言 貢獻 新手2023計劃 ] 2022年11月25日 (五) 19:16 (UTC)

這樣做的話條目會出現當選條目上了不久又下下了不久又上（6次）的情況，敝人並不贊成這種展示方式。一來在確保每個條目展示至少12小時的技術難度比AT的方案還要大很多（AT的方案難度本來就已經不小），二來是這樣的上上落落可能會讓讀者疑惑：條目暫時下架的期間是否出現了甚麼問題。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年11月26日 (六) 04:46 (UTC)

按目前的更新頻率即可保證每條最少12小時的展示時間（即6個更新等候時長），只是展示時間段變得碎片化，除了陳述句最開始的5條；另外讀者大概不會一日內每隔一小段時間就訪問一次首頁並去看DYK，發現上上下下的可能性並不高。不過用AT案我也不反對。--Kedouv（留言） 2022年11月26日 (六) 11:07 (UTC)

每天一早一晚各看一次的讀者應該不少，而近期的更新頻率以每4至6小時為主，現行方法依照這個頻率會使一個條目由開始上架到真正下架需時24至36小時，而您的方案需時應該是現有的兩倍，即48至72小時，橫跨了兩三天。當有人第一天早上7時看到條目A，晚上10時條目A不在，第二天早上7時條目A又再出現……這樣讓人看到上上落落的可能性其實一點也不低。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年11月29日 (二) 09:44 (UTC)

反過來看，此討論的參與者似乎大多均支持使用陳述，而且大多反對使用提問或認為可以並行，似乎也未見有人堅持只採用提問形式。這樣的話，是否應該考慮先改成陳述，再看看提問形式應該廢除還是通過什麼技術手段達至並行？這樣更貼近目前討論的方向。--AT 2022年11月26日 (六) 13:26 (UTC)

整理引導新手的相關頁面

目前用以幫助新人的頁面實在龐雜。WP:歡迎、WP:入門、H:簡介和WP:參與貢獻內容都大差不差；WP:新手上路感覺也可和WP:第一印象等分享感受的頁面合併；H:從這裡開始是不是另一種WP:新手簡明指南呢；WP:線上訓練整得不明不白，又出來了WP:維基百科大歷險。這些頁面看似相同，實際偏向主題各不相同，但是新手看來只會感到困惑；且目前想快速編輯的新手也很難直接找到有用的幫助，是否應該參照英維在側邊欄放入引導頁面的鏈接呢，比如H:簡介。--甘糸（留言） 2022年11月7日 (一) 02:57 (UTC)

很搞笑的事情是主頁上的「人人可編輯」鏈接轉到WP:歡迎，左右兩邊都是navbox，各種鮮艷晃眼的色彩。反觀英維就好看得多了。--0xDeadbeef（留言） 2022年11月9日 (三) 10:27 (UTC)

WP:歡迎其實完全可以被H:簡介取代。--BlackShadowG Slava Ukraini! 2022年11月9日 (三) 13:34 (UTC)

有一種上世紀網頁的美，花花綠綠，要是再來點滾動屏就更像了^{[開玩笑的]}----誠摯的 ZhaoFJx^{（論•編）} 2022年11月14日 (一) 14:49 (UTC)

怕搞混的話，就在最上方放「論述」也行吧！空氣小貓（留言） 2022年11月15日 (二) 06:55 (UTC)

• 儘管支持，這可是個大工程。--Temp3600（留言） 2022年11月15日 (二) 16:46 (UTC)

建了個協作頁面：WikiProject:維基百科發展/新手2023，個人覺得建立條目相關頁面也需要優化整理。 ——魔琴 [ 留言 貢獻 ] 2022年11月18日 (五) 09:08 (UTC)

認同有改革之必要，以確實分流。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年11月25日 (五) 18:18 (UTC)

關於WP:簽名方針/指引

WP:簽名方針/指引規定簽名長度不能超過255個位元組，但問題是包不包含簽名前方的兩槓（--）？當偏好設定裡簽名長度剛好是255位元組時，加上兩槓（--）就變成257了，這樣所以到底是可以還是不可以？因為觀察到有些人簽名前面沒有兩槓（--），如果算，那不就變成變相無故收緊簽名長度為253？我認為這個需要規定清楚，以免發生爭議。-- 宇帆-雪菲蛋糕🎂-娜娜奇🐰鮮果茶☕-在維基尋求休閒是否搞錯了什麼（☎️·☘️） 2022年11月18日 (五) 01:27 (UTC)

簽名指的應當是~~~~會被替換為的字符，而--是系統的簽名功能提供的，很多人會加，但事實上不是簽名的一部分。個人認為這兩槓不應受WP:SIGN限制。—— 月_櫻_雪 (留言) 2022年11月18日 (五) 01:50 (UTC)

話說，討論串功能的這個前綴可以改掉麼，中文環境下用兩個半角連接號總感覺怪怪的--DvXg 📬 2022年11月18日 (五) 16:33 (UTC)

(▲)同上。--YFdyh000（留言） 2022年11月18日 (五) 01:53 (UTC)

• (？)疑問：@月_樱_雪、YFdyh000：但是有人簽名的兩槓（--）用的不是-，例如User:魔琴簽名用的兩槓是—，佔3個位元組，跟-（佔1個位元組）不同，甚至有看過在兩槓（--）加內部連結、CSS的簽名，那麼這些情況是否應視為簽名的一部分？還是那兩槓不管用甚麼形式都不算簽名的一部分？-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2022年11月18日 (五) 02:49 (UTC)

  需注意「指引」是參考性的規範，本不應是硬限制。如果我每次留言都手打一個簽名（比如「--出自~~~~”、--今天心情不错的~~~~），又是否算入簽名，探討可能沒有止境。--為系統功能自動加入的簽名前綴（比如「回復工具」會強制加，用戶無法選擇），不建議計入簽名。而其他改版是否計入簽名額度，也建議基於常識。--YFdyh000（留言） 2022年11月18日 (五) 03:09 (UTC)

  回復工具並不強制加，只要你寫入一個~~~~，回復工具就不會幫你加簽名。事實上，只要加入一個合法的用戶鏈接（U, UT或Contribs，但不能是子頁面）和一個合法時間戳（不早於1000年）就可以。另外prefix是寫在MediaWiki:Discussiontools-signature-prefix里的。 ——魔琴 [ 留言 貢獻 ] 2022年11月18日 (五) 03:33 (UTC)

  我的兩槓是寫進preferences的，如果你仔細觀察的話我的兩槓前還有一個 ，天哪，竟然浪費了12個字節啊^{[開玩笑的]}。 ——魔琴 [ 留言 貢獻 ] 2022年11月18日 (五) 03:17 (UTC)

(！)意見，雖然指引是說255位元組，但一般都不會抓得太嚴，像是看見260位元組的簽名我通常都會覺得還是算了，太過在意這2個位元組好像有點兒無謂。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年11月18日 (五) 02:59 (UTC)

@Cdip150：問題是我位於疑似臨界就被警告了User_talk:A2569875#簽名問題。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2022年11月18日 (五) 03:02 (UTC)

那就是機械人沒有設定緩衝的問題了。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年11月18日 (五) 03:05 (UTC)

您不是第一位遇到，見Wikipedia:管理員布告板/其他不當行為/存檔/2022年11月的Mikelolggmrox。我認為機器人對堪堪臨界者提醒一次就可以了，糾結幾個~十幾個字節沒有意義，變成254個字節也不會有多少好處。--YFdyh000（留言） 2022年11月18日 (五) 03:14 (UTC)

那這樣約等於變相放寬限制。高考生遲到2分鐘不讓進考場？溫州教育局：遲到17分鐘 ——魔琴 [ 留言 貢獻 ] 2022年11月18日 (五) 03:23 (UTC)

我想這不能類比吧，現實的考試有競爭性質，所以從嚴；但這裏的簽名沒有競爭性質，所以從寬。這大概就跟3.2元乘車但有人上車衹有3元那要不要趕他下車的問題一樣難辯。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年11月18日 (五) 03:38 (UTC)

如果260可以，那過沒多久就會有人覺得265可以，再來270可以，沒完沒了。我們不如改成「規定是200位元組，然後彈性容許到255」如何？這個彈性夠寬吧？--Xiplus#Talk 2022年11月18日 (五) 07:55 (UTC)

事實上如果沒人投訴，我覺得機器人只應做提醒之用而無強制力。--YFdyh000（留言） 2022年11月18日 (五) 20:12 (UTC)

那之後就改以我的身分投訴，我覺得機器人或真人根本沒差別，違反規定的事實並不會改變。--Xiplus#Talk 2022年11月19日 (六) 02:07 (UTC)

那我會反投訴，因為我一直認為該規定是一則參考性建議，實際運用有緩衝。如果各方理念有差異，可能共識不成立，建議暫緩執行。態度指引為「用戶應該嘗試遵守此指引」，不是必須遵守此指引，「如果出現例外情況，最好使用常識判斷此指引是否合適。」的例外就是臨界點、過度干擾（而不超長）等情況。「因此，請使其保持最小的長度。」，如果256字節已經是實現目的（效果）的合理的最小代碼長度，那麼遵循了指引；如果不超長但代碼明顯可縮短（如夾帶無關緊要的外觀或不可見字符），則反而違背「最小的長度」，哪怕沒達到字節限制。--YFdyh000（留言） 2022年11月19日 (六) 02:30 (UTC)

255已經夠長了吧？@A2569875目前的簽名在原始碼內（縮放100%，編輯框textarea寬度1290px）已經佔了整整一行，還不夠長？您說「如果256位元組已經是實現目的（效果）的合理的最小代碼長度，那麼遵循了指引」，那麼請問如果實現某個簽名的語法最小長度是1000位元組，那是否也遵守指引？如果不是，那麼請您直接說個合法的數字出來，我們指引就改成該數字。--Xiplus#Talk 2022年11月19日 (六) 02:56 (UTC)

應該反問為何要設計這麼長的簽名？我也可以直接在簽名內使用255個英文字（畢竟中文寬度占2個英文字但占3位元組），這樣的簽名就比A2569875還要長了，相對之下，A2569875的簽名就合理許多，255不是建議設計的簽名的平均/合適長度，而是不可逾越的上限，YFdyh000您的簽名也只有168啊？為何不設計成255呢？--Xiplus#Talk 2022年11月19日 (六) 03:03 (UTC)

我不認為255字節是「不可逾越的上限」，至多是參考了UI的技術限制，而且只參考了一部分。長度和是否混亂無法直接對等。--YFdyh000（留言） 2022年11月19日 (六) 03:07 (UTC)

確實是來自於UI，但現在已成為指引的一部分。我同意長度和是否混亂無法直接對等，但您已經也能同意1000位元組絕對是混亂的吧？我想要知道的就是這條界線，指引訂說255以內，結果實際上300也沒關係啦，那訂這個255根本毫無意義，所以應該直接訂定確實的上限。--Xiplus#Talk 2022年11月19日 (六) 03:12 (UTC)

為什麼它是指引而非方針，就是因為確定性的上限（及外觀限制）是不存在、目前無法形成共識的。--YFdyh000（留言） 2022年11月19日 (六) 03:18 (UTC)

那請問255這個數字的用途是？如果有人設500，並反駁說沒有超過255多少（畢竟沒有超過2倍哈哈），是不是就無法處理？--Xiplus#Talk 2022年11月19日 (六) 03:21 (UTC)

個人觀點，如果個案共識認為可以（包括如很有特色、無法再減、影響不大），那麼就可以，可蓋過指引效力。社群非官僚體制，該限制也非機械執行或技術限制。--YFdyh000（留言） 2022年11月19日 (六) 03:07 (UTC)

如果簡單粗暴理解該指引為字節數限制，那麼「--用户一二三四五 (留言)」是一則合格的簽名（247字節），源碼如下。至於使用理由：用戶是字符值引用愛好者。^{[開玩笑的]}

--[[用户:用户一二三四五|用户一二三四五]] ([[用户讨论:用户一二三四五|留言]])

--YFdyh000（留言） 2022年11月19日 (六) 03:07 (UTC)

我覺得沒問題啊，就沒有超過255。--Xiplus#Talk 2022年11月19日 (六) 03:17 (UTC)

255這個數字絕對是比您所謂的混亂還要客觀，請問您要怎麼定義混亂？我就覺得@A2569875的簽名很混亂啊，5個emoji，8條連結，到底為什麼是鮮果茶連結到用戶頁？我沒說出來就單純是因為他的簽名在255內而已，如果放寬，那是不是就要變成9條連結了？我要花多久才能知道到底哪個連結是用戶頁？--Xiplus#Talk 2022年11月19日 (六) 03:28 (UTC)

這不是就偏好設定簽名那邊你填的那個空格裏面的東西不能超過255位元組嗎，有很不清楚嗎。那兩槓應該就不是那裏面的啊，按道理就不算，除非你在那空格裏面就有寫進去那兩槓了。——〚 玖宸 〛 2022年11月18日 (五) 03:09 (UTC)

@Arronwan：問題是你可以在框框裡填入{{subst:User:XXX/簽名模板}}，那麼關於{{User:XXX/簽名模板}}裡面可以塞多少位元組就不會受到框框裡填入字元數量的限制了。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2022年11月18日 (五) 03:15 (UTC)

指引的想法可能是只是~~~~的字節量，至於慣例上簽名習慣添加的破折號或連接號、或者手工加入類似簽名的內容，可能是在打規則的擦邊球？——我就是Sakamotosan路過圍觀 | 避免做作，免敬 2022年11月18日 (五) 05:46 (UTC)

問題在於儘管簽名有着明確的定義（mw:Help:Signatures），但在實際操作中無法分辨哪部分是被~~~~替換而來的。實際並非簽名但可能被視為簽名的部分包括但不限於連字符和用戶在簽名時手動添加的文字。也許可以在實際操作中將個人觀點之後用於表明發言者身份的內容全部作為簽名處理？不知這樣會不會有新的問題出現。如果有辦法得知哪些字符是被~~~~替換而來的就好了。（順便一提Wikipedia:強制顯示使用者預設簽名似乎完全沒效果）—— 月_櫻_雪 (留言) 2022年11月18日 (五) 07:09 (UTC)

• 如果你看得到這則留言才意味著Wikipedia:強制顯示使用者預設簽名失效或未啟用^{[開玩笑的]}（這則留言在Wikipedia:強制顯示使用者預設簽名作用下會完全消失）。--宇帆-雪菲蛋糕娜娜奇🐰鮮果茶在維基尋求休閒是否搞錯了什麼（☎️·☘️） 2022年11月18日 (五) 07:48 (UTC)

清除了緩存且啟用了js，不知其他人是否遇到了同樣的情況。—— 月_櫻_雪 (留言) 2022年11月18日 (五) 07:57 (UTC)

• 剛才測試了一下，如果你原本沒有啟用顯示預設簽名功能，就開啟本頁在一個分頁，然後在新分頁開啟偏好設定啟用顯示預設簽名功能，再回頭來重新載入剛剛開啟的「沒啟用預設簽名功能」的分頁的話，確實會沒有效，但再開啟一個新分頁連至有簽名的討論頁就會生效了。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2022年11月18日 (五) 08:45 (UTC)

當然有辦法知道哪些部分是簽名語法產生的，就是您在偏好設定中設定的，不然您以為MediaWiki:Newusermessage-signatures更新簽名或我的機器人是怎麼做的？--Xiplus#Talk 2022年11月18日 (五) 07:57 (UTC)

了解了一下相關的文檔，如果可以通過signatures.toolforge.org或類似的方式獲得結果的話，應該就沒有問題了吧，WP:SIGN中提到的長度限制適用於~~~~被替換為的字符，若有替換引用則展開後再計長度。—— 月_櫻_雪 (留言) 2022年11月18日 (五) 08:33 (UTC)

• 實際上計算的是~~~吧，我記得留言的日期時間也不算在簽名長度規範內。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2022年11月18日 (五) 08:39 (UTC)

包括中文在內的多個語言版本都沒有這一點的具體說明，不過實際上確實是按照~~~計算的。—— 月_櫻_雪 (留言) 2022年11月18日 (五) 10:21 (UTC)

這樣說的話，簽名後面自動補全的日期算不算簽名長度的一部分？----誠摯的 ZhaoFJx^{（論•編）} 2022年11月18日 (五) 15:20 (UTC)

那也是系統自動產生的，而且簽名之時間本質上就不應該算在簽名裡頭。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年11月18日 (五) 15:29 (UTC)

一直以來都不算。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2022年11月26日 (六) 05:35 (UTC)

提議引入加密貨幣及區塊鏈項目關注度特別準則

加密貨幣是風口，Web3也是風口，雖然最近破產了一個FTX，但是依然擋不住人們的熱情，以及迫切以「讓更多人知道正確的有意義的資料」為由想在維基百科打廣告的心情。為此考慮引入英維的en:WP:NCRYPTO，條文如下：

When establishing the notability of cryptocurrencies and other blockchain-related projects, the consensus is that crypto-centric news organizations—such as Coindesk or Bitcoin Magazine—generally cannot be used, as they do not provide coverage that can be considered "independent" from their subject for the purposes of WP:ORGCRITE. The notability of such projects must therefore be established on the basis of other sources, such as mainstream reliable news sources.

這裡面有些東西是中維沒有的，我將其替換成了核心思想等價的內容，如下：

現行條文 （無）

提議條文 （插入進Wikipedia:關注度 (組織)） 在確立加密貨幣以及其他基於區塊鏈的項目的關注度時，請注意來自於諸如CoinDesk和Bitcoin Magazine這類以報導加密貨幣及區塊鏈項目消息為業務核心的新聞機構的文章，一般是不可以被使用的。不應使用這些來源的原因是他們的報導通常不獨立於條目所記載對象主體，因此不能滿足通用關注度的要求。請使用其他來源，如大眾、主流的新聞媒體的報導來確立這些主題的關注度。

細心的人可能會發現我把原文中的WP:ORGCRITE替換成了通用關注度，我認為這是合理的改動。英文維基百科的WP:ORGCRITE其實與GNG是一致的：

A company, corporation, organization, group, product, or service is presumed notable if it has been the subject of significant coverage in multiple reliable secondary sources that are independent of the subject.

這個條文與GNG的差異就是強調要多條獨立二手可靠來源，但這應該不會有什麼問題，因為——

• 在實務中如果只有一條有效來源的話在存廢討論中通常是不夠的，所以實際上在操作上就有在要求多條。
• 提議的條文切入的是來源報導是否獨立於條目主體，而非一條還是兩條還是好幾條。

條文以否定的方式拒絕了部分條目，條文沒有以肯定的方式給出不符合通用關注度也能得到收錄的第二途徑。在我印象中，這在中維尚屬首次，所以我再多寫點。

常見問題

我不希望有條文對通用關注度做出限制，讓滿足通用關注度的條目得不到收錄。

提議的條文不是對通用關注度的限制。通用關注度的用語非常模糊，獨立、可靠、二手、深入、假定，都是可以有大做文章的解讀的東西。隔壁可靠來源布告板生動地展示了「可靠」可以有多大的爭論空間。

條文不是「限制」，而是對上述模糊用詞的解釋說明以及釐清，即明確指明某一類來源不能滿足通用關注度所需的某些要求，從使用了這些來源而看似符合GNG的條目，實際上不符合通用關注度。提出刪除的時候，理由應當是不符合通用關注度。

這個條文在否定某些來源，應該送入可靠來源布告板進行討論。

可靠來源布告板真的有討論過某些來源可靠但是否獨立嗎？沒有的話我為什麼要把它送入一個爭論來源可靠度而非是否獨立的地方。

條文沒有說這些來源不可靠，也沒有說這些來源不應在條目中使用。這些來源只是不能用以證明條目符合收錄準則而已，沒有禁止在正文佐證其他內容。寫條目用的來源，與確定條目可以收錄的來源，不一定劃等號。

這些報導「通常不獨立於條目所記載對象主體」，是事實嗎？

我一個人沒有也無法獨斷地確認，大家可以在下方討論區進行討論以確認是否如此。

可能還有更多想寫的，先寫到這裡吧。留言的話請放到下面的討論區，這樣好看一些不至於雜亂。 --MilkyDefer 2022年11月20日 (日) 05:36 (UTC)

討論區

• 我不確定涉及多少條目，是否有添加此細則的必要。將這些區塊鏈專門媒體的消息或介紹稿件斷為「自我宣傳、廣告」或「新聞稿」是否就可以。來源獨立性和利益衝突方面，有時也許無法完全定義和撇清，例1：可靠的醫學專業雜誌詳盡報道了一種新藥，但其他來源都沒有獨立的有效介紹；例2：遊戲雜誌詳細報道了一款新遊戲，但缺乏其他來源；此時，這些來源是獨立報道還是有利益的宣傳稿件，似乎很難弄清，是否只能通過討論共識決定是否可靠和值得記載。--YFdyh000（留言） 2022年11月21日 (一) 04:35 (UTC)

  這看起來像是區塊鏈行業的特殊性導致的報道方式有別於其他行業？--百無一用是書生 (☎) 2022年11月22日 (二) 02:21 (UTC)

  可以從Wikipedia:可靠來源#對特定主題領域的建議做延伸，醫學來源有專門指引說那些可以用（WP:MEDRS）。當然就算完全符合所有標準，還有造假的風險（1、[5]），就算國際期刊上也有漏網之魚（[6]）。隔行如隔山，如果有相關的加密貨幣關注小組還能有深入的討論，門外漢只能路過看看而已。--Nostalgiacn（留言） 2022年11月22日 (二) 08:41 (UTC)

請制定懲處方針以警告持續破壞的使用者

現行條文 所有封禁均用作避免維基百科受到破壞，或減低潛在問題發生的機會。封禁應是阻止上述問題的最後手段，只用於應對以較溫和的方法不能解決的問題和持續違反方針的行為，而適當運用這手段能透過以下四個方法避免上述問題出現： 避免對維基百科進行迫切的或嚴重的破壞或干擾 透過增加有不當行為的用戶的編輯難度，制止該用戶對維基百科的干擾 讓有不當行為的用戶了解維基百科不能容忍其行為，應改善及避免該不當行為持續 鼓勵有不當行為的用戶以社群認同的有建設性、適當的編輯方式對維基百科進行貢獻 在某些情況下，管理員會延長封禁期限，以避免維基百科受到破壞及鼓勵用戶停止干擾維基百科，重新開始對維基百科作出貢獻。

提議條文 所有封禁均用作避免維基百科受到破壞，或減低潛在問題發生的機會。封禁應是阻止上述問題的最後手段，只用於應對以較溫和的方法不能解決的問題和持續違反方針的行為。在使用者屢勸不聽的情況下，或已受封禁三次及以上者，應永久禁止其對維基百科做出任何改變，亦應使用相同手段懲處該使用者的傀儡，以預防該使用者操控傀儡繼續破壞。而適當運用這手段能透過以下五個方法避免上述問題出現： 避免對維基百科進行迫切的或嚴重的破壞或干擾 透過增加有不當行為的用戶的編輯難度，制止該用戶對維基百科的干擾 讓有不當行為的用戶了解維基百科不能容忍其行為，應改善及避免該不當行為持續 鼓勵有不當行為的用戶以社群認同的有建設性、適當的編輯方式對維基百科進行貢獻 恩威並施，對破壞者進行警告及勸導，並設法使其知道不當行為帶來的後果 在某些情況下，管理員會延長封禁期限，以避免維基百科受到破壞及鼓勵用戶停止干擾維基百科，重新開始對維基百科作出貢獻。

理由如下：

• 對於某些破壞者，雖然管理員會予以封禁以阻止其行為，但時限一到便將解除，頂多給予口頭警告，使破壞者仍不知悔改，如此柔和的手段效果實在非常有限。在此提議制定一些有力的懲處方針，來整頓維基百科的秩序，降低有人搗亂的可能。以上提議希望能得到共識。--Jiaweipan（留言） 2022年11月20日 (日) 10:33 (UTC)
• (－)反對，根本做不到的事，或可能會造成的大量後遺症的事情不應寫入方針。--SunAfterRain 2022年11月20日 (日) 12:16 (UTC)
• 沒用的，愉快犯才不吃這一套。已知多位長期出沒的破壞者是明知後果還故意破壞的。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2022年11月20日 (日) 12:42 (UTC)
• 保持靈活性，沒必要強制勸告。對於一些顯然是愉快犯的解決策略是Wikipedia:回退、封禁、不理會，但管理員也視情況對於給予提醒來作為勸告，這些應該有管理員去自己分析確定。——Sakamotosan路過圍觀 | 避免做作，免敬 2022年11月21日 (一) 06:08 (UTC)

如果是能勸服的話，那一早就被勸服了，用不着改規則。Sanmosa _{Je sers} 2022年11月24日 (四) 15:07 (UTC)

註：此處原有文字，因為LTA傀儡發言，已由路西法人於2022年11月27日 (日) 09:26 (UTC)刪除，尚祈見諒。若有異議請至互助客棧或向管理員反映。

建議將Wikipedia:不要訴諸法律威脅提昇為法律方針

有鑑於最近發生的某些事件，我建議將WP:NLT正式升級為法律方針（如同英文維基百科），雖然可能沒辦法完全阻止類似的事情再次發生，但至少有個可以遵循的依據。--冥王歐西里斯（留言） 2022年11月20日 (日) 23:28 (UTC)

這是否需要法務或者具有法律背景的用戶看看是否符合法律要求啊？--百無一用是書生 (☎) 2022年11月21日 (一) 03:04 (UTC)

或許，需要找人看看。--冥王歐西里斯（留言） 2022年11月21日 (一) 03:17 (UTC)

可能直接寄信給WMF法務部門請他們來看比較快？--SunAfterRain 2022年11月21日 (一) 09:07 (UTC)

頁面未完善（有一句未翻譯內容）和不算穩定。「法律方針」的概念？社群有權定義法律方針嗎。也許更適合定為態度指引，但然嚴厲性可能弱很多。需注意，除了訴諸訴訟和舉報，其他對行為合法性的暗示也可能在內和引致同等效果。非站內行為要約束嗎，也許較難實現，但似乎很有意義（如WP:OA2021），但驗證、警告和處置會相當麻煩。--YFdyh000（留言） 2022年11月21日 (一) 04:21 (UTC)

法律方針是指「These are policies with legal implications」。「不要訴諸法律威脅」此處理方式確實可能會造成法律上的影響。而英維亦將此視為法律方針。謝謝。--SCP-0000（留言） 2022年11月21日 (一) 04:41 (UTC)

那句應該是從英文維基百科來的，但說真的我也看不太懂那句是想要表達什麼。--冥王歐西里斯（留言） 2022年11月21日 (一) 05:28 (UTC)

看上下文是違反這些方針的內容不受WP:NOTCENSOR限制，可以管轄條目內容。-Mys_721tx（留言） 2022年11月21日 (一) 05:40 (UTC)

那我有更多問題了。法律威脅關條目內容什麼事？升格作法律方針又有什麼效力/效果？這種經紀公司直接見一個ban一個不就行了嗎？-某人✉ 2022年11月21日 (一) 08:31 (UTC)

(＋)贊成，對於某些法務方面的疑難，的確需要訂立方針加以規範，免得使用者們無意中觸法。--Jiaweipan（留言） 2022年11月21日 (一) 09:24 (UTC)

「無意中觸法」與此方針是相悖的吧。--YFdyh000（留言） 2022年11月21日 (一) 10:23 (UTC)

目前我跟下方LuciferianThomas君的觀點比較像，雖然目前只是論述頁面，也已有與此相關的封禁事件，但畢竟只是論述而非方針，將其提昇為法律方針更能確立標竿，讓管理員與其他社群成員面對類似事件時更有底氣解決。--冥王歐西里斯（留言） 2022年11月22日 (二) 11:40 (UTC)

(＋)支持。正式訂立為法律方針可以確保針對法律威脅的封禁能夠有明確依據下執行。現今有關法律威脅的封鎖一般都僅以無任何地位的WP:LEGAL作為封禁理據，當然執行上並非一定有問題，但實際上仍然是一個程序漏洞可以給人鑽。--路西法人 2022年11月21日 (一) 14:56 (UTC)

我記得以前也有人以法律方式刪除條目內不實內容：楊受成控告維基媒體基金會事件，對方只要有心走法律途徑也能處理那些內容，當然這需要鈔能力。--Nostalgiacn（留言） 2022年11月22日 (二) 08:21 (UTC)

「已截圖存證」算是什麼樣的法律威脅？我真是想不明白啊。而且也不需要給這樣多的例子吧。--Ghren🐦🕓 2022年11月22日 (二) 08:25 (UTC)

畢竟有唐澤貴洋（幫在2chan遭到網暴的高中生，順著IP讓不少人入獄）的情況，雖然也很少見啦。--Nostalgiacn（留言） 2022年11月22日 (二) 08:47 (UTC)

截圖的法律效力較弱，但哪些是法律威脅，哪些是正當或不當的威脅/警告提醒/溝通態度問題，還是很難說。比如「您在本條目的所為已存檔並轉交我司相關部門/人員」，是法律威脅呢，還是表示不滿+等待後續溝通的意思，換成「法務」就一定是法律威脅嗎，不明說就無事嗎。「已對相關發言進行公證」「已對相關發言進行永久存檔（網頁存檔）」在同一場景中有多少本質區別。涉嫌網暴、人肉搜索等風險的非法威脅，是否不考慮同等規制，而且起訴是權力，威脅才是不當的。--YFdyh000（留言） 2022年11月29日 (二) 16:06 (UTC)

截圖的法律效力較弱？看看香港的立場新聞涉煽動案件，其實截圖都可以作為法律證據。--Wpcpey（留言） 2022年11月29日 (二) 16:15 (UTC)

未經公證不能保證未篡改，無法作為證據，所以個人「已截圖」說是法律威脅比較牽強。如果已截圖算，已保存網頁、已記錄永久鏈接難道也算法律威脅了。--YFdyh000（留言） 2022年11月29日 (二) 17:41 (UTC)

那看起來截圖那條可以移除或是移動到其他相關的頁面，其他的例子呢？--冥王歐西里斯（留言） 2022年11月30日 (三) 03:13 (UTC)

復看了一下，也可能是當時管理員自作主張移除掉（雖然理由是以「沒有來源及來源可信度不明」移除內容）？雖然現在的話，可以用Wikipedia:修訂版本刪除請求的RD2、RD4來申請版本移除。就算聲明了發律師函給基金會，也要等基金會是否接受和以基金會行動的方式來直接處理，本地對於這種現實法棍沒必要理會。——Sakamotosan路過圍觀 | 避免做作，免敬 2022年11月22日 (二) 10:15 (UTC)

(＋)支持：我的意見同LuciferianThomas君。--~~Sid~~ 2022年11月22日 (二) 15:51 (UTC)

是說目前似乎無人明顯反對，能進公示流程了嗎？--冥王歐西里斯（留言） 2022年11月29日 (二) 02:58 (UTC)

送公示吧。--路西法人 2022年11月29日 (二) 14:53 (UTC)

上方有些意見值得重視，但都未有展開有效討論。--Xiplus#Talk 2022年11月29日 (二) 15:34 (UTC)

同xiplus.建議將提昇為法律方針與更新案分開公示，兩案皆通過後再同時執行。--Temp3600（留言） 2022年11月29日 (二) 16:12 (UTC)

那麼法律方針本身的文字更新應該可以先公示了。--冥王歐西里斯（留言） 2022年11月29日 (二) 23:53 (UTC)

方針列表#法律方針不是任何指引。不需要公示。--Ghren🐦🕖 2022年11月30日 (三) 11:01 (UTC)

對於例子依然覺得不妥。例子重覆，而且引用同一案的說話也不免太多了。--Ghren🐦🕖 2022年11月30日 (三) 11:10 (UTC)

不如閣下直接動手改？--冥王歐西里斯（留言） 2022年11月30日 (三) 11:39 (UTC)

逐條討論

本章節對於特定條文進行深入討論，我已列出的都是與英文維基百科不同的，或是我不確定翻譯的，未列出則表示條文與英文維基百科一致，如果您覺得有其他條文需要討論，請按格式列出。為避免版面混亂，如果您認為條文都沒有問題，請不要對每一項都寫{{支持}}，請寫在前一個段落，這不是投票，請不要僅留下{{支持}}而不留下意見。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

（方針名稱）「不要訴諸法律威脅」

「法律威脅」一詞直接翻譯自en:Legal threat，但曾有人建議翻譯成「不要威脅訴諸法律」，發動法律行動實際上會稱為「訴諸法律行動」，而該方針是禁止「威脅要訴諸法律行動」，故縮短為「威脅訴諸法律」，但該稱呼似乎會跟en:Appeal to the law混淆。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

另建議動詞可以不要用訴諸，可改為「發布」、「張貼」等。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

（簡而言之）

除直接翻譯外，加上「未被警告的情況下」及「維基百科已有相應的程序處理這些問題」兩句。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

（導言第一行）法律威脅的定義

加上「訴訟、舉報、告發」作為舉例。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

（導言第一行）報告地點

未翻譯「elsewhere to an administrator」，原本想說統一報告到管理員布告板。但考量到提報人可能被變為訴訟對象，是不是應該提供私下報告方式比較好？可補翻譯加入「管理員列表」及「管理員專用郵件清單 wikipedia-zh-admin」。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

（導言第三行）「The only concern of this policy is the posting of legal threats on Wikipedia」未翻譯。

暫未翻譯。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

（什麼不是法律威脅 - 著作權）歡迎您告訴我們該使用方式是否符合授權

不太確定「a clear statement about whether it is licensed for such use is welcome」的意思，暫時用我自己的話重寫。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

（什麼不是法律威脅 - 著作權）報告程序

Wikipedia:頁面存廢討論/疑似侵權放在首位，這是穩定執行的現有處理程序。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

（什麼不是法律威脅 - 有償編輯）「laws against undisclosed advertising」未翻譯

不太清楚那是什麼，暫未翻譯。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

（什麼不是法律威脅）擬增訂Wikipedia:生者傳記

有些請求可能涉及隱私或任何生者傳記規定事項，這些請求可能同時涉及法律威脅，但如果符合Wikipedia:生者傳記規定應移除內容，應優先接受請求，而非指控其法律威脅，以免事態升級。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

（察覺法律威脅）標題

原文為「Perceived 感知、察覺」，暫用察覺一詞。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

（察覺法律威脅）法律威脅的範例

考量到本案當事人和其他新人不熟悉該方針，參考了Wikipedia:條目所有權#所有權的行為示例和Wikipedia:不要人身攻擊#例子都有相關的舉例，給出範例能讓所有人更容易理解界線在哪裡，故目前給出很多範例。但我有在考慮方針是否真的適合收錄範例列表，獨立成一頁作為{{輔助說明}}可能更為合適。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

（察覺法律威脅）英文方針原本的舉例「if you repeatedly assert that another editor's comments are "defamatory" or "libelous"」未翻譯

續前，建議留下一個範例即可，但這兩個詞彙似乎都是誹謗，不知道怎麼翻譯，或許可以直接另外寫一個合適的範例。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

（設立方針的理由）這會造成寒蟬效應

原本寒蟬效應是連結，但我覺得直接寫出來該詞彙有助於理解。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

（設立方針的理由）衝突中的一方就有可能威脅並排斥另一方

原文「we risk one side of a dispute intimidating the other」，不確定翻譯是否正確。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

（設立方針的理由）社群與曾做出法律威脅的使用者會留下糟糕的經歷

原文「The project has had bad experiences with users who have posted legal threats in the past」，不太確定是指在（英文維基百科）以前曾發生糟糕的經歷，還是指一旦進行了法律威脅，日後社群在與該位編者協作時會想起這段糟糕的經歷。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

（設立方針的理由）只有在您已經嘗試了所有您知道的合理步驟來友善地解決問題，但爭議解決程序仍不能解決您的問題時，您才可以選擇採取法律行動。

原文「If the dispute resolution procedures do not resolve your problem, and you then choose to take legal action, you do so in the knowledge that you took all reasonable steps to resolve the situation amicably.」，不確定翻譯是否正確。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

（法律威脅的結論）防止在尋求他人協助後，又將對方變為法律上的對造。

原文「prevents a situation in which someone seeks to be a collaborative partner, while posting as if they were a legal adversary.」，實際上看了很久都無法理解這句話的意思，更舊的原文是「It prevents the difficult situation where a person is both seeking to be collaborative partner and also setting themselves up as litigatious adversary (in general those two roles are mutually exclusive).」，相關的討論請參見這裡。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

（法律威脅的結論）在使用者討論頁上反覆進行法律威脅所能造成的擾亂及寒蟬效應範圍有限，除非已經合理嘗試發起文明的討論，否則不應禁止編輯他們的討論頁。

但在本案中的當事人實際上很快地（而不是多次提出申訴）被禁止討論頁及電子郵件，我個人不太認為本案（在被封討論頁當下）有達到非常嚴重的情況，如果本地社群決定更嚴厲執行該方針，或是給予管理員更靈活判斷的權力，應刪除本條。但其實本條是保障當事人申訴權利，及避免事態升級。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

續前，電子郵件是否構成法律威脅

翻譯前的原先文字有「如果您決定要訴諸法律行動，請與相關用戶以電郵聯絡，不要把問題放在維基論壇或討論頁。」，而且該方針的規範範圍似乎僅及於公開的地方（可從用戶討論頁就視為不夠公開而給予特別寬容看出），故電子郵件應該不包含在內，但本案中當事人實際上已被禁止電子郵件，另法律威脅已被定義為Wikipedia:騷擾#恐嚇和Wikipedia:不要人身攻擊#例子的一種類型，而這兩項規範範圍理應包含電子郵件，因此有矛盾之處。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

（法律威脅的結論）假定善意不是自殺協議

我其實不懂suicide pact的意思。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

按照en:Wikipedia:Our social policies are not a suicide pact，是WP:IAR。在用戶頁面散發法律威脅因為影響範圍較小不會被立即禁止編輯討論頁面，但是持續此類行為會禁止編輯討論頁。-Mys_721tx（留言） 2022年11月30日 (三) 16:10 (UTC)

更新對法律方針的描述

現行條文 以下方針有法律上的後果。除這些方針外，基金會行動方針、維基百科不會審查內容也有法律上的意義。留意只要內容符合美國法律，維基不會對內容拖加限制。如想向維基百科提出法律投訴，可向維基媒體基金會提出正式投訴

提議條文 以下方針有法律後果。除下列方針和基金會行動方針外，只要維基百科上的內容符合美國法律，維基百科不會對自身可能令人反感的內容進行審查，或採納其他管轄內容的法律提案。法律問題需通過維基媒體基金會正式提出。

順手重新翻譯了一下法律方針的描述。-Mys_721tx（留言） 2022年11月21日 (一) 05:50 (UTC)

(＋)支持：社群對不得進行法律威脅之條文雖現無明確列入其中，但已在實踐過程中受到普遍性的承認。諸如WMC事件、修訂傀儡方針涉及法脅內容以及諸管理員在封禁案例上也有體現。現在明文加入其中，顯然是適當的。——2022年11月22日 (二) 15:37 (UTC)--以上未簽名的留言由維基百科最忠誠的反對者（討論｜貢獻）加入。

根據實際情況修改WP:NOR#原創圖像中的表述

Wikipedia:非原創研究：

現行條文 由於各國的著作權法律，現有已發表的圖像中，只有相對較少的圖像可被用於維基百科。因此，維基百科編者創作的照片、繪畫以及其他類型的圖像成為了我們的主要圖像來源。為了給條目增加插圖，我們鼓勵編者自行攝製照片、繪製畫作或圖表，並以GFDL或其他自由著作權協議上傳到維基百科。根據NOR方針，由維基百科編者創作的原創圖像不被視為原創研究——只要他們沒有在圖像中繪製或表現未發表的想法或觀點。

提議條文 由於各國的著作權法律，現有已發表的圖像中，只有相對較少的圖像可被用於維基百科。因此，維基百科編者創作的照片、繪畫以及其他類型的圖像成為了我們的主要圖像來源。為了給條目增加插圖，我們鼓勵編者自行攝製照片、繪製畫作或圖表，並以允許商業性使用和演繹的知識共享許可協議或其他自由著作權協議上傳到維基共享資源並在維基百科中使用。根據NOR方針，由維基百科編者創作的原創圖像不被視為原創研究——只要他們沒有在圖像中繪製或表現未發表的想法或觀點。

第一處修改：根據c:COM:Licensing/zh#GNU自由文檔許可協議，在該節列舉的條件下，GFDL不允許作為唯一許可協議。結合c區著作權協議選用的實際，應進行上述修改（措辭可能存在優化空間）。( π )題外話，原鏈接本身也指向了消歧義頁面。

第二處修改：WP:上傳本身建議上傳自由文件到c區，建議一步到位。--Teetrition（留言） 2022年11月24日 (四) 12:05 (UTC)

暫且慢着，因為允許GFDL單獨授權是有時間限制的（Wikipedia:GNU自由文檔許可證文本、Wikipedia:著作權信息）。——Sakamotosan路過圍觀 | 避免做作，免敬 2022年11月25日 (五) 00:18 (UTC)

該條文主要是為了新製作的文件。2009年之前的文件是單GFDL授權。2018年後Commons上亦不接受僅有GFDL的照片。修改措辭應不影響這些時間限制。--Mys_721tx（留言） 2022年11月25日 (五) 03:08 (UTC)

提議 西方人名重定向 增加 「姓氏，名稱1·名稱2」 格式

1、之前的提議 （User:PhiLiP的提議）

2、傳統百科全書、傳記詞典，如《中國大百科全書》、台灣國教院中詹姆斯·杜威·沃森沃特森,詹姆斯、歐洲歷史大辭典（ISBN 9787532623150）、《美國傳統詞典》Watson James Dewey、《二十世紀世界名人辭典》等，有條件的可以在讀秀上搜「沃森，詹姆斯·杜威」。

3、中文裡經常只稱呼姓氏，該種格式可以減少建立姓氏重定向，更方便編輯時查找重姓的人物。比如，想找諾貝爾獎獲得者 詹姆斯·杜威·沃森，可以用 沃森，詹姆斯·杜威，不用跑到沃森消歧義頁面去查找。 --Kethyga（留言） 2022年11月25日 (五) 12:08 (UTC)

《中國大百科全書》第二版23冊381頁只是單用「沃森」。--Ghren🐦🕘 2022年11月25日 (五) 13:13 (UTC)

《歐州歷史大辭典》沒有這個人——那是《美國歷史大辭典》（206頁）吧。--Ghren🐦🕛 2022年11月26日 (六) 04:42 (UTC)

不限定具體某個人物。--Kethyga（留言） 2022年11月26日 (六) 07:33 (UTC)

金常政是這樣說的：「詞序按排考慮檢索的方便，關鍵詞可以移前，必要時也可以顛倒詞序。例如外國人物條目以姓氏立目，而把名（本名、教名、父名等）放在姓氏之後，如『Smith, A.T.』」（《百科全書編纂概論》，山西人民出版社，1985年，79頁）。一般百科全書為了方便讀者檢索，將關鍵詞特意移前的百科全書可以說是汗牛充棟——但是放在維基百科，這樣建重定向，能提升多少的檢索效率？我不是在反對，這也是不能反對的，畢意這是一個出現在可靠來源的名稱，但是我不看好這能提升什麼效率。--Ghren🐦🕒 2022年11月26日 (六) 07:53 (UTC)

我覺得一個問題是，之所以傳統百科這樣做，是因為紙質出版的緣故，這樣做編制索引方便檢索，但是網絡出版這樣做的必要性就不大了--百無一用是書生 (☎) 2022年11月28日 (一) 03:01 (UTC)

但是中文在稱呼的時候，經常不加人名直接稱呼其姓氏，比如最近世界盃的球員，大多數也只是稱呼球員的姓氏，只有少數的稱呼其暱稱，而且姓氏總有出現消歧義的情況。--Kethyga（留言） 2022年11月28日 (一) 03:52 (UTC)

您說的話是對的，可是和此案有什麼關係？消歧義不能解決嗎？--Ghren🐦🕒 2022年11月28日 (一) 07:40 (UTC)

• (－)傾向反對，理由如下：
  • 即便用了新格式，中間的間隔號「·」還是需要剪切粘貼，因此個人認為新格式對查找幫助不大。
  • 個人也不認為需要為此類重定向特別制訂方針，除非涉及到在條目正文中使用新格式重定向。如果單純是用於查找的話，方便個人使用就沒什麼問題。
• 以上。歡迎拍磚。📕📙📒📗📘📚📖^{強烈抗議維基基金會無理封禁中維管理員} 2022年11月26日 (六) 07:15 (UTC)

  目前維基百科的搜索似乎是忽略標點符號的，有沒有標點不影響搜索， 即在維基內置搜索輸入「詹姆斯杜威沃森」，搜索結果第一項也是「詹姆斯·杜威·沃森」。。沒有確定的文字說明不利用存廢討論。--Kethyga（留言） 2022年11月26日 (六) 07:25 (UTC)

(？)疑問 這種頁面命名，人物重名的概率大嗎，會否增加消歧義需求反增維護負擔。中國大百科全書第一版等，有采「馬克思－艾威林，愛琳娜」格式，是否也要創建，MOS:連接號是否沿用、選用一字線，但指引中「漢語拼音、外來語內部的分合」是短橫線。如果出於可靠來源使用、方便檢索，林肯，A.、馬斯特斯，E.L.是否均應建立重定向，或者只是鼓勵或允許建立？--YFdyh000（留言） 2022年11月30日 (三) 07:48 (UTC)

西方人名的姓氏相對來說沒有漢語集中，三名法一般歧義比較少（不代表沒有）；連接號在人名中應該用短橫線，如 Wikipedia:格式手冊/標點符號#連接號中的 伊雷娜·約里奧-居里，人名中用短橫線；林肯，A.（姓氏，名字首字母.），這種格式感覺只適合傳統百科全書中出現的，不適合普遍應用。--Kethyga（留言） 2022年11月30日 (三) 10:26 (UTC)

「馬克思-艾威林，愛琳娜」像是前兩者為一個部分，未見任何來源使用，可能不應使用短橫線。有一些來源使用「愛琳娜·馬克思-艾威林」。--YFdyh000（留言） 2022年11月30日 (三) 15:04 (UTC)

「馬克思-艾威林」算雙姓吧，比如 弗雷德里克·約里奧-居里，讀秀裡面有 約里奧-居里，弗雷德里克。--Kethyga（留言） 2022年11月30日 (三) 15:56 (UTC)

設一事件的兩個同性質條目，日後若合併是否應按照創立時間的優先次序，亦或品質或其他因素？

如題--詠梅閣—WMLO（留言） 2022年11月26日 (六) 12:33 (UTC)

時間。首先，在顯示條目未創建的時候已經提示了你先去嘗試進行搜尋，你不先去試着找就直接動筆開始寫是你的失職。其次，品質或其他因素是主觀標準，創建時間是客觀標準，按照創建時間來辦事最不會出現爭議。第三，先到先得是行之有年的準則，早已成為習慣。最後，沒有人說把A合併到B，B的內容就要一定override在A之上，你覺得xtools顯示不出是你創建了條目，說實話，這種事情why care。--MilkyDefer 2022年11月26日 (六) 15:23 (UTC)

我覺得說是「失職」又過了。有時候確實建立時間很接近，搜尋時找不到很正常。--Ghren🐦🕚 2022年11月26日 (六) 15:59 (UTC)

首先，我一不是基金會的正式職員，也不是如您二位系本站的回退員、巡查員或管理員，說我失職之指控言過其實。至於「xtools顯示不出是你創建了條目」;總的來說，未能顯示是本人所創建之條目，亦將影響我未來申請有關榮譽、職權（即限定標準）。若尊敬的MilkyDefer閣下未曾申請維基ACG專題創作獎之類，我可能會被尹說服，畢竟說實話，這種事情why cares^{[開玩笑的]}。撇去以上個人利益的角度，如果社群多數意見認為時間優先，且未避免擴及條目所有權之行為，我亦不提出異議，但出於個人觀感我不會主動移動。但也希望能獲得更多討論，這樣日後爭議也能少些。——詠梅閣—WMLO（留言） 2022年11月26日 (六) 17:31 (UTC)

方才知曉上海烏魯木齊路抗議事件後，對此深受感觸。誠然，無論在社群前還是社群外，我都不能在這裡提及政治觀點；但我看了現場影片後，我認為他人為了不干自身之事而挺身而出，是一種可貴的勇氣，也令人敬佩，且在這樣的氣魄面前，任何的私利都顯得微不足道。故請允許我收回上述發言，我將自行移動至2022年鄭州富士康抗議。感謝各位的指教。——詠梅閣—WMLO（留言） 2022年11月27日 (日) 00:33 (UTC)

如果真的擔心直接合併重定向也無妨，這樣建立條目的紀錄也會在；至於維基榮譽的判定問題另外開一個討論串不是更好嗎？--SunAfterRain 2022年11月29日 (二) 04:19 (UTC)

按時間。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年11月27日 (日) 14:29 (UTC)

沒有明確規定，協商，個人傾向保留較早、質量和內容尚可、歷史記錄和參與者較多的版本，此例牽扯多個因素，只能協商。「創建者」身份重要又真的不重要，在意者應自撰「主編（擴充）條目名單」。「較早創建」難有確切標準，比如A用幾十筆建立了完善的草稿，B創建了一句話的正式條目，誰為先；又如存廢覆核復還（合併）、部分侵權重建、原條目下重寫等情況，創建者身份都會失去。--YFdyh000（留言） 2022年11月30日 (三) 07:22 (UTC)