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

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

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

公告欄

• [人事] 管理人員申請提名結果已出爐，現正在討論調整提問及投票日程，敬请关注参与。
• [公告] 現時已改為只有延伸確認用戶可以使用內容翻譯將頁面釋出到主條目空間，如有疑問及意見，歡迎參與相關討論。
• [公告] 回饋請求系統正在試運作中，誠邀用户訂閱以接收討論通知。用户訂閱有興趣參與的討論議題後，机器人會自動在新討論發起時隨機抽取部分用户發消息通知。
• [公告] 增修封禁方针已經通過。
• [公告] 將小紅書評為通常不可靠、关于{{Death}}和{{Deceased Wikipedian}}文案调整的方案及“阅读无障碍”功能字體大小更改及「大字體」小工具調整正在公示，如有意見請盡快提出。
• [討論] 互助客栈技术区正在討論ToolsRedirect创建的繁簡重定向問題及{{Infobox person}}中native_name参数的顯示位置問題，請踴躍參與討論。
• [討論] 互助客栈方针区正在討論再擬議立國際關係命名常規為方針，請踴躍參與討論。
• [討論] 互助客栈其他区正在討論IP封禁豁免权授予者的顶部图标及頁面評級與通用評級行政層面上的統合方案，請踴躍參與討論。
• [请求] 请协助处理修订版本删除请求积压！

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

#	💭 話題	💬	👥	🙋 最新發言	🕒 (UTC+8)
1	提議提高條目評選投票資格門檻	66	21	Y. Sean	2024-04-28 13:01
2	建立封禁申诉的本地共识	57	5	Shwangtianyuan	2024-04-18 13:58
3	再擬議立國際關係命名常規為方針	28	10	Ghren	2024-04-28 00:00
4	修订删除方针明确允许删除没有来源30日以上的条目	20	7	YFdyh000	2024-04-27 23:10
5	Quick CU introduction	10	5	日期20220626	2024-04-25 06:15
6	提議英維指引en: MOS:TVINTL經本地化後引入中維維基百科:格式手冊/電視	25	7	Cwek	2024-04-28 10:06

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

正在廣泛徵求意見的議題

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

維基百科格式與命名

Template talk:Infobox person § 修改 Infobox person 中 native_name 参数位置

可能需要进一步讨论以便获得共识。--Kethyga（留言） 2024年4月24日 (三) 05:15 (UTC)

維基百科方針與指引

Wikipedia talk:维基百科不是什么 § 修订方针维基百科不是维基物种

現行條文 維基百科不是手冊、攻略書、教科書、或科學雜誌 （略）

提議條文 維基百科不是手冊、攻略書、教科書、科學雜誌或物种列表 （上略） 8：維基百科有关于物种详细介绍的内容，但如仅列出物种列表，姊妹计划维基物种可能更适合这种内容。

--Python6345（留言） 2024年3月23日 (六) 02:26 (UTC)

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

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

Wikipedia:互助客栈/条目探讨 § 盛岡市的導言和宣傳的定義

https://zh.wikipedia.org/w/index.php?title=%E7%9B%9B%E5%B2%A1%E5%B8%82&diff=prev&oldid=82050595

如連結所示，user:tofugamay認為闡述盛岡市是縣內的人口、政治與經濟中心是在宣傳，但典範條目的札幌、函館與福岡皆有先例，且優良條目中的秋田市與新潟市也有前例，與因此想請問各位的意見。我個人認為隨意將看起來像在宣傳的文字直接定義成是在宣傳非常不妥，因典範與優良條目中皆有先例，若任意否決與經同行們審查並核可使用的相似形容，等於是無視當今編輯慣例與同行審查的過程，因為那些文字是在審查時就有的內容。而對方先前對於宣傳性的定義也相當不明理，認為導言涉及當地產業的簡述和特產的簡述就是在宣傳，但先前已有多位資深編輯員表示不違反規則，如user:AT和user:CryptidNext，而導言若只是簡單描述近年來某城鎮以發展觀光業為主，及當地特產為西瓜和蘋果等，我認為不至於在宣傳，因宣傳需帶有特定態度與字眼，不宜直接說死。這次的事已告知對方，但礙於之前我跟他才剛暫時結束一個大紛爭，只能來尋求版上各位的看法，因他也不一定會回我。

典範與優良條目連結如下: https://zh.wikipedia.org/zh-tw/%E7%A7%8B%E7%94%B0%E5%B8%82 、 https://zh.wikipedia.org/wiki/%E6%96%B0%E6%BD%9F%E5%B8%82 https://zh.wikipedia.org/wiki/%E7%A6%8F%E5%B2%A1%E5%B8%82 、https://zh.wikipedia.org/wiki/%E5%87%BD%E9%A4%A8%E5%B8%82 --雪雨73（留言） 2024年4月21日 (日) 13:19 (UTC)

Wikipedia talk:消歧义 § 请问以下消歧义的存在是否合理？

我发现到诸如阮副總統、蕭副總統、李副總統等一大堆“同姓称号消歧义”。请问这些消歧义的存在是否合理？另外，Category:假名消歧義和Category:諺文消歧義里的一堆消歧义的存在是否也合理？这些消歧义非中文/罗马字，请问中文维基需要这种消歧义吗？@Sdf：在此通知这些消歧义（大部分）的建立者。--微肿头龙（留言） 2024年4月25日 (四) 07:52 (UTC)

維基百科提議

Wikipedia talk:仲裁委员会 § RfC：2024年2月

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

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

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

Wikipedia talk:回饋請求服務 § 将回馈请求系统用于存废讨论和存废复核

感觉“回馈请求”就是之前为了解决存废讨论积压提出的“邀请讨论”类似的东西，此系统是否可以用于存废复核以便解决积压？--桐生ここ★[讨论] 2024年3月6日 (三) 04:01 (UTC)

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

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

Template talk:Twitter § Twitter改為X

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

@stang：--Ghren🐦🕛 2022年12月5日 (一) 04:34 (UTC)

了解。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年12月13日 (二) 07:49 (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)

@Ericliu1912:

共識已在10月尾達成並通過，相關公示亦在公示欄公示了10天，現在是先試行方針…--唔好阻住我愛國（留言） 2022年12月5日 (一) 02:00 (UTC)

我沒從這討論中看出什麼共識，只是各方一來一往拖拉了許久。方針較一般指引位階更高，即使是所謂「試行」亦應取得社群相當程度之共識。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年12月5日 (一) 02:27 (UTC)

WP:7DAYS「公示期間若無正當合理異議，提案作通過論。」--唔好阻住我愛國（留言） 2022年12月5日 (一) 04:59 (UTC)

不是有個前提「互助客棧中的提案僅在7日內無新留言時或已討論達30日後，方可在已取得共識的前提下公示」嗎？讀方針讀一半啊？從頭到尾沒有大部分同意或解決所有爭議的討論哪來的共識？--路西法人 2022年12月5日 (一) 10:21 (UTC)

上方絕大多數的提問也達到這個原則：「另外，為確保討論的連貫性，任何正當合理的意見（無論是否於公示前或公示後提出）若已獲提案人正當合理的回應，且自該回應起計的3日後無進一步再回應，應視為該意見已解決，且不再作為對該提案的正當合理的意見。」--唔好阻住我愛國（留言） 2022年12月5日 (一) 10:43 (UTC)

基於上方及下方的討論，個人認為此提案毫無疑問是未有共識的。個人建議，提案人可依上方討論的意見重新制訂新提案，而非一直強調達成所謂的共識及反覆利用規則。謝謝。--SCP-0000（留言） 2022年12月5日 (一) 16:05 (UTC)

「公示完成，通過！」以上的是共職，以下的全部也是規程問題。而規程問題篇幅佔整體已經一半--唔好阻住我愛國（留言） 2022年12月5日 (一) 16:31 (UTC)

我来问一个问题吧。「李老师不是你老师」的推文能否使用（针对过滤器部分）：

• 相關內容無法由其他更為可靠的來源替代（这种情况会有的）
• 能辨認帳號持分者的身分（我不是很清楚你这个「身份」具体要明晰到什么地步。自然人？还是机构法人？自然人的话要开盒到真实身份吗？）
• 帳號持有人/機構/受訪對象/引用內容須達到WP:關注度要求（要不你看看最近对李老师不是你老师的采访？条目都有了）
• 只接受與帳號持有人/機構相關專業領域的內容（接收群众投稿并发布算是它的专业领域，对吧？他自己也有做交叉验证、也会主动勘误，对吧？【笑】）
• 如相關帳號不屬任何機構，帳號需在指定狀況內獲得媒體或學術引用，或被專業人士充分肯定。其他編輯者有權移除使用过旧的证据及其相關引用的內容。（如果你有看新闻的话，这不需要我特别指证）

上面有人说要应对这条目Twitter来源过多的问题，想要快速通过提案。但是这么比对下来，好像并不能拦住诶。 --MilkyDefer 2022年12月6日 (二) 11:18 (UTC)

我们是人，我们不是机器人。我们不是那种读取一条指令就执行一条指令的机器人，我们不是把世界变成一条又一条逻辑语句加以组合的机器人。我们不是在立法，维基百科也不是官僚体系。但是现在这个条文就像是把模糊的、盘踞在大家潜意识里头的一套较为不一致的标准给强行具像化，这种条文使不得。--MilkyDefer 2022年12月6日 (二) 11:23 (UTC)

同意milky.--Temp3600（留言） 2022年12月13日 (二) 17:34 (UTC)

看漏了這一句…

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

那既然这一句准则能解决这个问题，你列出那么好几条又是与关系又是或关系的有必要吗？你能跟我保证你不是在构建一个过拟合的模型吗？--MilkyDefer 2022年12月10日 (六) 20:31 (UTC)

原先的提案是這樣的，基於現有的方針增加粗體詞語。大部分編者也同意，唯一小部分編者認為部分「社交媒體」帳號有引用價值，所以才這樣改。簡單來說，那篇很長的文章是限制引用來源的提供者，及配置具維基特色的認證制，並非限制引用量，因為已有其他指引規管引用量。

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

--唔好阻住我愛國（留言） 2022年12月11日 (日) 02:00 (UTC)

另外，有部分第三方傳媒使用社交網站作主要發佈途經，既然他使用了社交網站，證明了相關傳媒的規模較細，無法確保來源是否具價值；也有一些編輯者會選擇自我引用，引用數則貼文證明自己的論點。--唔好阻住我愛國（留言） 2022年12月11日 (日) 02:10 (UTC)

看到你这个回复我就放心了，我可以安心地喊(！)抗议了。

你分得清什么是来源的可靠和不可靠，以及来源的一手、二手三手吗？

你到底是想规管什么？你想把贴文打为“均不得被认可为可靠来源”，还是把贴文打为第一手资料？为什么不可以有可靠的第一手资料这种东西存在？--MilkyDefer 2022年12月11日 (日) 10:34 (UTC)

@MilkyDefer:

「絕大多數內容都不是可靠（非所有），一小部分除外，而在那一小部分經證實身分的為第一手來源，因此沒有抵觸。」

如果是第三方媒體，應引用媒體官網而非引用帖文。

可以的話看淸楚提案的一字一句。--唔好阻住我愛國（留言） 2022年12月11日 (日) 11:21 (UTC)

行，那我重新审视一下你要提出的条文。首先，条文内容很复杂，特别是滥用过滤器那里。你开出的滥用过滤器提示，相当于构建了一棵非常复杂的决策树，复杂模型只会给人一种无法理解，不能执行的印象。你甚至还要再开一个布告板，这个布告板是干什么的，审议用户生成内容的发布者的。维基百科什么时候成为资格审查委员会了？然后再看看你的方针修订，“所有用户生成内容只能当作第一手资料，不论发布人的身份及机构。”你真的很想对用户生成内容搞点一刀切；最开始一刀切掉可靠性不行，现在要一刀切一手二手来源。那么，那些转战内容发布平台的媒体怎么办呢？那些构建新媒体矩阵的机构怎么办呢？Channel C怎么办呢？娛壹怎么办呢？壹报怎么办呢？中天新闻台怎么办呢？只要你的提案还在一刀切，我就不会支持你的提案。--MilkyDefer 2022年12月11日 (日) 12:36 (UTC)

• 「你甚至還要再開一個布告板，這個布告板是幹什麼的，審議使用者生成內容的釋出者的。維基百科什麼時候成為資格審查委員會了？」上面有人問相同問題，請看我的解釋。
• 「那麼，那些轉戰內容釋出平台的媒體怎麼辦呢？那些構建新媒體矩陣的機構怎麼辦?」—>WP:QS
• 「Channel C怎麼辦呢？」—>應引用官網內容
• 「娛壹怎麼辦呢？」—>
• 「壹報怎麼辦呢？」—>應引用官網內容
• 「中天新聞台怎麼辦呢？」—>應引用官網內容

--唔好阻住我愛國（留言） 2022年12月11日 (日) 13:37 (UTC)

「既然他使用了社交網站，證明了相關傳媒的規模較細，無法確保來源是否具價值」這句不準確：因為某些傳媒的規模較細，所以多會使用社交網站發佈內容（例如娛壹）；但傳媒使用了社交網站發佈內容並不能代表相關傳媒的規模較細。正如無綫電視的「勁歌金榜」除了直接在勁歌金曲節目內公佈，就只有在其社交媒體公佈每周排名，加上「勁歌金榜」亦是五台排行榜之一，如果因此說引用無綫電視社交媒體中的「勁歌金榜」是不具價值顯然為錯誤。（所以我理解為何@MilkyDefer說整個提案一刀切，而@Temp3600亦同意MilkyDefer說「這種條文使不得」吧。）ThirdThink（留言） 2022年12月28日 (三) 05:00 (UTC)

總之看來討論內容過長，無條件(－)反对。建議開新貼重新討論。--Gqqnb（留言） 2022年12月17日 (六) 16:03 (UTC)

一點也不長，只是出現了規程問題。--唔好阻住我愛國（留言） 2022年12月18日 (日) 05:45 (UTC)

心很累！明明相關文字均由各編輯者brainstorm 出來，但礙於規程問題，差少少就可成文。

不知道是不是一些既得利益者無條件反對而累事。--唔好阻住我愛國（留言） 2022年12月27日 (二) 16:57 (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)

  「它是编写良好的」符合乙級標準之「沒有重大語法錯誤」（又稱「能看懂」），明顯不符合典範標準之「行文具有吸引力」。至於優良標準的「清晰簡潔」：這句清晰但不夠簡潔，條目偶爾出現這樣語句我會給過（畢竟總共也沒幾個字），但通篇如此（就如你舉出的頁面）那我會讓它掛掉的。--洛普利寧 2022年12月14日 (三) 17:22 (UTC)

後續討論

• 條目評選也算是大致完成，我對全面推行審議制的想法是：本站做不來。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年12月12日 (一) 12:05 (UTC)

  为什么呢？共识制度从英维搬来应该是一个很成熟的流程。至于有些人觉得评选不能在一个指定的时间内通过是一个很大的问题，但是我觉得这是一个十分现实的trade off。典范条目应该是百科条目中最好的，所以当不应该成为FA被投票选成FA的条目被发现了，这件事应该责怪谁呢？在投票制下，貌似谁都不用负责任。而审议制则能够提供证据，能至少对于「为什么被认为是典范条目」提供一个答案。如果中文维基的平均编辑水平没有英维高，那更要进行共识讨论。如果说有八个自动确认用户觉得符合标准，所以就应该是典范条目的话，那么是不是说明FA的门槛比较低？--0xDeadbeef（留言） 2022年12月12日 (一) 12:23 (UTC)

  (！)意見:簡單來說，審議制FA太花時間及人力資源。

  在審議制試行的第一個星期，不同編輯者嘗試提供意見（包括我），唯評審員只接納2位編輯者的意見，有點不太中立。

  在第二個星期，我刻意不回答相關解決方案，因為現有的方針（WP:共識 ）指出

  「另外，為確保討論的連貫性，任何正當合理的意見（無論是否於公示前或公示後提出）若已獲提案人正當合理的回應，且自該回應起計的3日後無進一步再回應，應視為該意見已解決」

  唯評審員仍然選擇ping本人回應。換句話說，評審員花了大量時間關心FA過程。

  在第三個星期，評審員宣布最後7日提出評審，該意見表格沒有更新。

  第四個星期，評審沒有依從時間結束討論。

  ——

  由此可見，一個評審已很混亂，評審員如何每月處理十則提名？--唔好阻住我愛國（留言） 2022年12月12日 (一) 13:27 (UTC)

  首先作为第一次试行所以不可能所有都能第一次搞到完美。至于你刻意不回应我是觉得不能作为不试行审议制的理由。既然是同行评审那就要有一个互相交流的过程。至于评审员是否花费了「大量时间」，根据这些也无法判断。至于不更新表格和没有按时结束，也许你想表达的是应该换个评审员？--0xDeadbeef（留言） 2022年12月12日 (一) 13:54 (UTC)

  首先，這不是評審員的錯，因為回答人數在四星期內仍不足最低人數（9人），判斷不出結果反而正常。換著是我以「收成期」價值觀做評審員，肯定會有不少人表達不滿。--唔好阻住我愛國（留言） 2022年12月12日 (一) 14:08 (UTC)

  看起来阁下好像理解出了些问题，不同编辑者尝试提供意见（包括我），唯评审员只接纳2位编辑者的意见，这是因为这两位编辑者（我觉得您是指我和0xDeadbeef）有详细依照FA的标准检查哪一项符合，而阁下只是提出了两个问题，没有进一步说明阁下认同条目符合哪些FA标准，不符合哪些FA标准，阁下没有说明当然协调员也没法纳入考虑。你引用的WP:共识的那段条文是仅限于互助客栈的，FA评选不适用。意见表格没更新不是什么大问题，没有依从时间结束讨论不知道指的是什么。--BlackShadowG Slava Ukraini! 2022年12月12日 (一) 14:06 (UTC)

  • 難道「審議制」不是「共識」的一環？
  • 反而覺得評審員直接在表格中簽名留下自己最關注的部分是最好。
  • 不是整點結束。
  • 第一條問題主要是關注標題是原創還是有根有據…

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

  第二個point是「編輯者」，非「評審員」。--唔好阻住我愛國（留言） 2022年12月12日 (一) 14:17 (UTC)

  你就没注意到你引用的那句话是在WP:共识的“互助客栈”这个大标题下面的吗？那个表格只是为了直观说明，怎么用都没多大差别。“不是整点结束”……你觉得结束时间多准确很重要吗？你提出有关条目的问题是OK，但审议制更多需要将条目依照FA的标准检查。我觉得你的关注点过于细枝末节了，没什么值得注意的。--BlackShadowG Slava Ukraini! 2022年12月12日 (一) 15:11 (UTC)

  關於那個表格，「沒有侵權」及「圖片版權」部分，其實是可以引入turnitin 那類的機器人測試，一般編輯者不會一字一句上Google 檢查抄襲率及版權問題，意思是在審議前篩走一些明顯不合資格的條目，節省人力資源。--唔好阻住我愛國（留言） 2022年12月12日 (一) 15:51 (UTC)

利益声明：1) 参与本次试行评审；2) 刷小作品的，没写过FA。

对于接近FA标准的作品，现在的评审生态多是直接给过，很有橡皮图章的倾向。本次评审中，多名编辑提出了翔实的意见，帮助文章迈向完美条目。因此，我认为这次试行是成功的。

但是悲观来看，我们还不具备遵照典范标准评审的条件：

• 典范标准是很高的要求，是远高于优良标准的要求。以行文方面为例。GA只需语句清晰，但FA就要行文优美。因此本次评审中，即使对于表意清晰的语句，我也会提出润色意见。不过实践中，在句子表意明确的基础上，评审人是否有愿意继续提出意见，提名人是否乐于接受，这是一个问题。
• 英维FAC之前有很多准备工作。例如英文版Fallout条目参选FA前就有1次GAN、1次copyedit、1次PR（同行评审）。其中GAN和PR中都有长篇意见。中维本次评审中，我注意到参选条目个别句子表意暧昧；而此类问题本是GAN中就应提出与解决的。尽管本条目直接参选FA，但即便先走GAN又能否解决这些问题，懂的都懂。而且对于翻译条目，我们比英维更需要copyedit，但可惜我们没有校订小组。因此，我们的FAC评审压力很大——不是提名者压力大，就是评审者压力大。

现行FA标准本站可能没几个人能hold住。在更容易评审的优良条目上套用这次的机制，或许还能降低评审人压力，鼓励他们严格按照标准评审，最终起到切实改善条目品质的效果。（至于为何更严谨的FA评选用投票？我认为我们的GA和FA评选严谨度没差，还不如改更有可能执行的那个。）--洛普利寧 2022年12月12日 (一) 16:47 (UTC)

感觉其实到头来最大的问题还是人力，即使我们使用英维一样的机制（GAN要求一名评审员认真评审，引入copyedit小组，提高PR的受关注程度），一篇条目按照这一套流程下来能得到的改善程度也比不上英维，但这也是没办法的事。

我认同在FAC前进行这一套提前改善条目的流程有助于降低FAC评审压力，这可能需要在FAC使用共识制同时，引入一些配套的措施，包括但不限于：修改GAN的机制，让编者在提名GA时就能让条目得到基本改善；提高PR的曝光度，鼓励提名者在FAC前先PR等。但无论如何，在人力的限制下，评审压力还是会存在的，速度和质量上也很难做到两全其美，例如如果跟以前一样用投票制，几天就能结束一个评审，但质量上没法把关；用审议制严格评审，就需要更多的时间和精力，这次评审有至少7人参与，耗时也达到了一个月。

至于“GA和FA评选严谨度没差”这个问题，虽然有WP:优良与典范条目标准对比，但事实上每个人对这两大评选的标准还是有一定的弹性空间。理想情况下，如果GA和FA评选都采用共识制，那么就有更多的机会来让评审员们达成“这个问题是GAN就需要解决的，还是FAC才要处理的？”这样的共识。但事实上主观因素还是会存在，比如假如我在GAC中说条目缺少某些内容，我可以以缺少这些内容就不符合GA标准的“涵盖面广”为由来要求主编改善；主编也可以说条目已经“涵盖面广”，那些内容是FA标准的“全面”才会要求的内容来反驳。--BlackShadowG Slava Ukraini! 2022年12月13日 (二) 12:32 (UTC)

我認為現行評審制度正是極度不符合人力資源現狀。一方面是GA/FA的6/8人的評審制度，而英文維基連FA評審都不用6人。另一方面是水土不服的英維WIAFA標準：比如行文方面，大家都忙著寫條目，提意見屬於有能力沒人力；而內容方面可能是連能力都沒有，所以不是借英維評審東風，就是信任編者有知識儲備（有時會炸雷）。這兩方面導致品質標準形同虛設，實際評審集體擺爛。更重要的問題是，一代又一代的新維基人也學會了擺爛。（如今的評審品質和十年前相比幾乎沒有進步）我認為只有引入新模式，才能改變這種現狀。（當然不一定是在FA/GA評審本身上改，也可以是PR，或者我在遊戲專題簡訊裡提到的專題評審。但無論如何，關鍵還是要有人認真審，且評審過程受到社區尊重。）

我並不期望本站評審達到英文維基的品質。我甚至期望用en:WP:WIAGA作為本站典範條目的標準：用一個力所能及的目標，換取評審者的認真參與，達到實際改善條目的效果。畢竟八張零意見支持票的結果是，條目既沒有得到改善，也未必符合字面上的FA標準。

當然，施行審議制終歸是費時間。且不說上面講的流程耗時問題，更不說與提名人互動的時間，單是一位編輯讀完條目的時間（還沒開始敲意見呢），都夠另一位用戶把本月所有條目全數支持一遍了。而且審議制能否順暢實行，還是要看有評審能力者——特別是FA、GA主編——的時間與精力。我這類小條目創建者來客串，總是沒甚麼說服力的。--洛普利寧 2022年12月13日 (二) 15:47 (UTC)

各專題人力相差太多。我能想到的可能性就只有我們電子遊戲專題自己辦評審，選出甲級條目或給予典範條目背書。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年12月14日 (三) 12:38 (UTC)

可能本站從GA評審入手比較合適，FA評審目前先放一邊。FA評審的一大問題是人力，但GA檢查並不需要專業人士，DYK參與者只要用心也能評審。評議制GA評審再說人少，就真是「不為」而非「不能為」了。另一方面FA檢查極其嚴苛，理論上評審者有更好的想法都要提出來；而我們已經習慣零意見投票制，突然開始嚴格要求，無論評審人或提名人都難以適應（這次評審估計SilverReaper君都想把我踢出去了）。GA評審在讀完全文的前提下「得過且過」，不需要提出海量的意見，也不會花費FAC那樣多的時間，我認為比較適合過渡。

找成熟專題試點是很好的方式。像遊戲專題、音樂專題、地震專題等都有成熟的編寫方案和評級隊伍，我認為這些專題可以試點「評議制準GA」（aka「乙上級」），將本次的FAC評審模式套用到準GA評審上。一方面有成熟編寫方案的加持，新編者和其他領域編者不至於在基本方向上錯評；另一方面評級制度活躍，說明領域內有編者把關。此舉可以吸收新鮮血液，並將評議制的理念逐漸傳播開來。等領域能比較成熟地評議GA後，再考慮FA就是水到渠成了。--洛普利寧 2022年12月14日 (三) 16:50 (UTC)

一臉得意於是就回到我上面說過的方向了嘛。「一部分專題可以先擴權」，有意願推動「非投票審」的專題，可以先向社群申請這方面的許可，然後當條目出現時，由主審者向FAC報備。搞雙軌制。--Temp3600（留言） 2022年12月14日 (三) 19:09 (UTC)

• 於是又回到中文站人少但條目多的老問題了。我沒有什麼好意見，想到再說吧。--Temp3600（留言） 2022年12月13日 (二) 17:36 (UTC)

  可能現時並不是全部具建設性的編輯者知道有FA,建議成立評審組，邀請 巡查員及回退員 或 延伸確認編輯者 加入。--唔好阻住我愛國（留言） 2022年12月14日 (三) 02:06 (UTC)

  組織化是可以的，但有不少準備工作。最開首要先建立一個通訊名單，當對應專題的條題被提交時，提示名單上的人可以去看看。--Temp3600（留言） 2022年12月14日 (三) 19:12 (UTC)

  各類工作組，委員會、專題，但反現在的制度都有人，完全沒有問題。近期還鼓弄個维基专题:創作物專案互進，轉眼「不活躍維基專題」。個人對新開小組沒有太大期望，盤活現在的各小組更實際。除非是想要一個XX小組創始人的頭銜。--Nostalgiacn（留言） 2022年12月15日 (四) 06:00 (UTC)

  舉個例，今天九龍巴士1A線參選FA。以現行的公示制度下，如何讓台灣公交編輯者在不留意WP事務的狀況下知道九龍巴士1A線正參與FA?--唔好阻住我愛國（留言） 2022年12月15日 (四) 15:24 (UTC)

  台灣公交編輯者應該主動參與台灣專題和交通專題，而不是等著他人通告。專題參與人數多了，自然就有人更新參選條目名單（就像這樣）。而且不留意WP事務的編輯未必有評審能力，就像不參與遊戲專題的編輯者，他們心中的遊戲優良條目很可能是遊戲道具大全這種負面典型。而且您看看現在的WP:FAC，就算把他們拉過去，他們也只會被{{yesFA}}--~~~~式評審傳染。--洛普利寧 2022年12月15日 (四) 15:52 (UTC)

  我得說"自然就有人更新參選條目名單"在目前而言只算是願望。--Temp3600（留言） 2022年12月16日 (五) 10:00 (UTC)

  那首先把专题搞起来再说。尤其是交通之类的大话题，DYK写公交的、写铁道的编辑大把，不可能说没有人。名单更新由机器人协助都OK，但专题都是死的bot也爱莫能助。虽然评审组也是一个办法，但FA这种依赖领域的评审，到头来还是要靠本领域（或者类似领域）的人把关。--洛普利寧 2022年12月16日 (五) 11:45 (UTC)

  「大部分條目主題都沒有活躍的專題組」 的確是阻礙推行評審制的重要原因之一。--Temp3600（留言） 2022年12月16日 (五) 14:13 (UTC)

  参选条目名单现在已经可以由机器人更新了，这倒确实不是问题。--BlackShadowG Slava Ukraini! 2022年12月16日 (五) 14:52 (UTC)

  个人想法，GA评审前条目顶部悬挂横幅2周，征集真实读者的意见，将意见适当纳入改进或评审的讨论环节。技术上尽量降低留言难度（包括快捷与可视化的操作，参考手册及常用模板，开放代理用户留言板等），以及优化横幅观感。--YFdyh000（留言） 2022年12月14日 (三) 17:38 (UTC)

• 話說回來，@SilverReaper：君自己怎樣看?--Temp3600（留言） 2022年12月14日 (三) 19:02 (UTC)
• 身体好些了。虽然距离完全恢复还要些时间，但我现在能说两句了。我认为评审能否顺利，最大的问题是人们会不会把自己的想法说出来。无论是多小的想法，模糊的感觉还是清晰的问题点，说出来总是要胜过得过且过。有些条目不管是在GA还是在FA，读过去感觉差一些，这个时候应当说出来，而不是当作没看到一样忽视这篇条目的评选而不投票。社群需要时间和努力去完成观念的转变。
• 我没有遵循英维的惯例，自顾自地开了一个「最终评论期」的东西，这个是我仿照Rust在GitHub上面的Final comment period做的，我无意搞成要挂在公告栏上的公示七天制。
• 正好最近我在英维接受蔚蓝条目的GA咨询，也获知了一点当地社群的看法。根据英维社群的看法，英维的GA评审实际上无限接近于橡皮图章状态，绝大部分的品质提升在提名条目前的同行评审就已经完成，而且在提名GA前需要征求条目主要贡献者的意见才可提名。GAC非常像把证人逼到当庭认罪后对被告宣判无罪的仪式性流程，所以只需要一个人、一两天即可。以上可供参考。 --MilkyDefer 2022年12月15日 (四) 10:08 (UTC)

  然后是评审标准表格的问题。对不起，我把这事忘了。表格语法我很头疼，经常写不对，而且很费力。我更希望探索一个更好的方案。--MilkyDefer 2022年12月15日 (四) 10:10 (UTC)

  准确来说，与其说是忘了，倒不如说是至少有三次看到那个表格想到要更新，然后看到我自己找到头昏的表格代码，放弃编辑。另外我没有每天都盯着评审专页看。--MilkyDefer 2022年12月15日 (四) 10:20 (UTC)

  （建议使用WP:VE--0xDeadbeef（留言） 2022年12月15日 (四) 11:13 (UTC)

  VE不在维基百科命名空间启用。--MilkyDefer 2022年12月15日 (四) 13:14 (UTC)

  我竟然忘了。。但是可以复制到沙盒之后再粘贴--0xDeadbeef（留言） 2022年12月15日 (四) 13:31 (UTC)

  条目评审前顶部悬挂横幅两周，开放代理用户留言板恕我保留意见。如果这样的话，中华民国总统大概是连GA都上不了了。试想一下开放代理用户留言板后发现人数一边倒地要求把台湾写成中国台湾省，中华民国总统要求改写成台湾地区领导人，总统只能写到李宗仁。--MilkyDefer 2022年12月15日 (四) 10:16 (UTC)

  作参考而不是指标，有编者引用、转述时再讨论。我设想的留言板，放在外部服务中，类似安全投票的附言公布，其他编者可以阅读和取其精华，忽略不合理留言与傀儡行为、可以考虑不存档（定期清除）。“人数一边倒地要求”在存废讨论偶有出现，照常处理即可。GA评审期间也可考虑摘掉或缩减横幅。对于冷门条目，可能不会有多少留言和影响（可以用追踪分类缓解），不影响已有流程。用以缓解评审可能没有兴致与精力仔细阅读条目内容的情况。如果留言点评机制足够方便，常态化更佳，其他百科和知识库系统已有这种反馈机制。--YFdyh000（留言） 2022年12月15日 (四) 10:28 (UTC)

  引入外人這一招不太可靠，除非是引入卓有聲譽之士。我敢說，維基百科人的水平還是比平均網民要好上不少。--Temp3600（留言） 2022年12月15日 (四) 15:44 (UTC)

  個人認為GA評選在英維成為「橡皮圖章」的情況是審議制實施之後結果，畢竟審議制，形式上無限接近同行評審。

  當然「橡皮圖章」也可能是部分觀點，起碼我也留意不少是沒有同行評審，直接提交GA，評審員指出了部分需要改善的內容，然後就是審查人沒有回應，落選了（1）。也有進行了同行評審，沒人回應，提交GA，在評審員和編者合力改善內容，通過的（1）。--Nostalgiacn（留言） 2022年12月15日 (四) 11:21 (UTC)

  基本上，這只能算是少數，多數優良條目與典範條目評選，還是「橡皮圖章」多（註：不能否認我個人也挺常充當「橡皮圖章」）。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年12月15日 (四) 21:13 (UTC)

  不太認同「橡皮圖章」是主流的說法。我去看了當下英維遊戲專題參與GA評選的條目，六個條目都沒有參與過同行評審，是直接提交GA的。

  優良和典範（特級）是兩個標準，正如下文「WP:WIAGA的要求比WP:WIAFA低很多」。「橡皮圖章」一說更適用於典範條目，「典範條目之路」（{{FAPath}}）就是推薦先提交「同行評審」後，再提交FA。--Nostalgiacn（留言） 2022年12月16日 (五) 14:33 (UTC)

其實換個角度看，我們對FA和GA的期望到底是怎樣的？比如對於翻譯條目，我甚至認為中維心目中的FA（i.e. 社區的最佳條目）就是：

• 接近WP:WIAFA要求的內容與來源（絕大部分內容enwp編者已經核實，除了個別誤譯）
• 接近WP:WIAGA要求的格式（中維沒那麼多格式手冊）
• 品質高於典型WP:WIACCA條目的行文（大部分內容能看懂，但也有些詰屈聱牙的句子）

這樣一方面，那些被指「投水票」的人其實也是認真投的，畢竟社群的期待就這麼低。另一方面從榮譽上來講，同樣都是FA，三項都努力逼近WIAFA標準的編者不是很吃虧？（雖然這樣的編者大概也不會對FA數量太感興趣）而FA評選亦非完美條目評選，既然乙級條目的行文可能就已經高於事實標準，評審者有沒有必要提出FA級甚至GA級的意見？--洛普利寧 2022年12月15日 (四) 13:33 (UTC)

中維的條目整體質量和標準存在脫節，中維的一些優特是沒有格式和指引的，近日魔女之旅剧集列表爭議也可見一斑（剧集列表类条目的写法规范）。但是由於翻譯自英維高質量內容已經常態化，所以會用英維的標準審視內容。問題可以簡化為：中維評選優特是以中維條目整體水平而論，還是直接對標英維的優特水平。--Nostalgiacn（留言） 2022年12月15日 (四) 14:48 (UTC)

一臉得意x2這個就是投票制好處：能夠按評審員的水平，動態地調節評審質量，以確保評審本身至少能維持下去。「穩定」、「行政簡便」、「榮譽與責任相抵」這些特質在擁有時或許很不起眼，沒有了可就得吃苦頭。---Temp3600（留言） 2022年12月15日 (四) 16:11 (UTC)

「而审议制则能够提供证据」可以是優勢，用得不好就變成實名負責制，大家都害怕背鍋。--Temp3600（留言） 2022年12月15日 (四) 16:14 (UTC)

我都認為中維事到如今都沒有鍋可言了。畢竟眼下只要條目不是特別差，就約等於無意見自動通過（甚至是無視合理意見通過）。所以評審人只要提出建設性意見，無論是否檢查出全部問題，都算是在做貢獻。（另外有問題就該提，自己不提結果條目通過，只能怪自己嘍～）至於爭議話題永遠達不成共識：反正FA/GA就是個自我參照，永遠選不上就永遠選不上唄。--洛普利寧 2022年12月15日 (四) 16:30 (UTC)

說到底還是中維對FA/GA的期望，一分貨值一分付出。英文FA和GA評審差距很大，可能GA評審30 kB過，FA擴到100 kB被打回三次還過不了。中文FA/GA/DYK就是票數的差距，本質上似乎沒有差別。要求低自然不值得多花時間，{{yesFA}}十連發非但不受譴責，反爾有人幫忙說是評審快，就這評審素質哪值得花十分鐘總結討論？每名評審都用一兩個小時認真看條目，那審議制的行政時間就算二十分鐘也叫零頭。--洛普利寧 2022年12月15日 (四) 19:24 (UTC)

要是單純從改善一分是一分的觀點來看，那麼投票制也好，什麼制都是可行的：中維的主編也不見得完全不理意見。分別在於意見有多重要，或者說，是否規定必須要先完成「一定的評審工作」，才可以當選。要是中維每篇條目都有一名（就夠了）評審願意拿一個小時來看條目，那我當然很支持評審。但如果根本沒有這個人呢？延長評審時間是對「等這個人有空前來」有幫助，但如果中維社群根本就沒有這方面的人選呢？是否每次都依賴主審將自己的私人時間當作預備隊，出現評審缺口就填進去？--Temp3600（留言） 2022年12月16日 (五) 09:57 (UTC)

所以说根本问题还是中维对FA/GA的事实定位。要是按B级条目要求评，一个人一天评十几篇当然没有问题。但问题是既然这样，那FA和GA的意义在哪里？如果供其他编者参考，B级条目真的就够用。所以我们FA/GA就是能上首页刷荣誉的B级条目？

如果真的想执行WP:WIAFA，那其他人的意见必不可少。这种程度的条目主编至少也看过两遍，大问题基本是没有。由于思维惯性、个人知识面和能力，再加上主编看条目已经麻木，一些问题主编自己是看不出来的。这些小问题只有让其他人检查、指点。评审时间本身就应该在在考虑之内：既想不花时间又想达到WIAFA要求，那是不可能的。而且这遍检查完后，编辑之后就会注意同样的问题，并帮助其他编辑发现类似问题，长期来看这对中文维基发展是有利的。如果没有本专业的人选，那近似领域的编辑检查就OK。毕竟我站能力摆在这里，能达到的「最佳品质」就是如此。但之前没有任何实质评审，就凭八个{{tl|yesFA}}--~~~~选出来的条目，我实在不认为代表我们的最佳品质。而且FA完全能少提精选——日维才97篇FA，网上照样一堆人喊「中维垃圾，我看日维都不看中维」；英维也要求每人同时提一个FAC（GAN随意），中维极端时还有一人同时进行10篇候选的。

WP:WIAGA的要求比WP:WIAFA低很多，我甚至认为两者是完全不同的要求。比如这次如果试行GAN，我的意见大概会少4/5。所以我上面一直强调，既然本站没有评议的习惯，那就从GAN开始逐渐培养风气。毕竟GAN评审不用那样耗时。但即便是这样，辐射条目正文1.1万字，仅仅是通读本身都要15分钟，而带着协助改善的思路阅读，时间至少加倍。既然主编愿意花很长的时间来写，而且愿意把条目写好，那我多花一些时间来评审，才是对主编努力的尊重，也是对条目评审流程的尊重。

如果社群对WP:WIAFA和WP:WIAGA不认同，或者认为执行不了，或者认为快餐式评审是最合适的。那坦诚参考WP:WIABCA，实事求是地制定标准会更好。--洛普利寧 2022年12月16日 (五) 11:45 (UTC)

「那麼投票制也好，什麼制都是可行的」- 投票制当然是可行的，因为中维做投票制都这么长时间了还说不可行不就有点夸大了问题了吗。关于GA的问题：首先我们要考虑一下英维是怎么干的。这我还挺熟悉，因为我之前搞了一个GA。首先，只有一个人来评审就行，但是必须在每一个要求后打Template:GAList/check。虽然说只是从多个人每人打一个Template:GAList/check到一个人打多个Template:GAList/check，但是区别还是很大的。其中一个区别就是责任的问题。当GA需要重审的时候会把之前让通过的reviewer揪出来批斗。--0xDeadbeef（留言） 2022年12月16日 (五) 14:33 (UTC)

中維的FA重要來源是英維同級條目的翻譯本，中維的FAC只是翻譯質量審查後追認其FA地位而已。如果需要進行對正文的實質審查，那麼的確是應該限制主編的同時提交數量。--Temp3600（留言） 2022年12月16日 (五) 14:25 (UTC)

「找成熟專題試點」我自己當然很支持。如果諸位有此意願，可以在VPP先行制訂專題組申請自行評審的框架方針，後面再自行商議小組內部細則。--Temp3600（留言） 2022年12月16日 (五) 14:31 (UTC)

+1，如果不限制参与者必须加入专题来评审，我觉得提议通过没什么很大的问题--0xDeadbeef（留言） 2022年12月16日 (五) 14:39 (UTC)

我的想法是增設「專題甲級評審」（≈FA的PR）和「專題乙上級評審」（≈GA的PR），大致類似en:Wikipedia:WikiProject Military history/Assessment/A-Class review。有興趣的專題可以向社區提出申請。社區通過後，在評審步驟上鼓勵相關條目先走專題評審，允許專題評審結果在{{Article history}}登記。簡單來說，專題接盤PR管改，正式GAN/FAC管審（關係到上首頁一類）。至於專題評審過程，所有用戶都可以自由參與，專題選一批協調員把關就OK。另外近似領域專題可以考慮合署評審，例如歐洲諸國專題可以在歐洲專題集中review。如果未來多數領域都能普遍運作下去，這種模式也是OK的。--洛普利寧 2022年12月16日 (五) 16:15 (UTC)

我的想法有些不同：專題組有權利自行舉辦GAC/FAC，在GAC/FAC報備以邀請社群參與後，專題組可按自己的內部程序進行評審，社群則直接認可結果。如果堅持走投票程序或是重審，則繼續走投票程序（這個部分日後可以按情況再擴大專題組權限）。PR我覺得沒什麼人在用，直接從我的想法中略過了。--Temp3600（留言） 2022年12月16日 (五) 16:33 (UTC)

這種作法能實行也OK。就是擔心由專題直接裁定結果，會不會把專題變成互煮客棧分棧：比如有人因為條目不通過，把意見轉嫁到個別專題，認為專題胡亂評審要求撤權。（畢竟再用投票制還是很容易直接通過，這樣專題好像經常做錯誤決定⋯⋯）--洛普利寧 2022年12月16日 (五) 16:54 (UTC)

主要是還是FA和GA牽扯到利益問題。比如有些用戶很重視上首頁的問題：例如先評GA，等GA上首頁後再評FA，這樣條目可以上兩次首頁。直接由專題評判不通過，這類用戶必然是很有意見的。而專題評審和PR只是建議性質，相對能保持專注內容的純潔性。畢竟如果個別專題而非全站實行，那個別專題就很容易成為出頭鳥。希望這只是我過於保守的想法。--洛普利寧 2022年12月16日 (五) 17:07 (UTC)

• 現在就等待有意願當先鋒的專題組了。--Temp3600（留言） 2022年12月22日 (四) 09:43 (UTC)

  我個人也支持開放部分專題以審議制評審條目，再由社群認可其背書之結果。相信這只會讓條目評選更嚴格（而非更寬鬆），在品質把關上是有益的。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年12月22日 (四) 10:32 (UTC)

  在遊戲專題留了個言。（雖然很多參與者已經在這裡發過言了）--洛普利寧 2022年12月22日 (四) 12:05 (UTC)

  其實我覺得「FA由於是『完美的』條目，應該採用這種評定標準，但仍然保留投票制，二者不得雙重提交，在任何評審30日內不得以同或另外的評審方式提交，而GA則先保持原有方案，不過可以在用戶對內容有爭議時參考，但不得用審議方式評審。」--FK8438祝您剩蛋快樂（簽名）🎄🎄 2022年12月26日 (一) 08:58 (UTC)

  你先定义一下什么是完美条目。WP:完美条目很可能是不可达到的，典范条目也不是完美的。--MilkyDefer 2022年12月26日 (一) 09:21 (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)

  我承認這個問題很難回答。維基百科的底層邏輯是信任社群共識，而您的說法意指社群共識本身就存在偏見，要求以另一種權力來源來平衡共識，這涉及複雜的權力平衡設計，恐怕不是我幾天內就能想像出來的。但或許我以下的觀點可稍為安慰：大體而言，社群的權限投票還是講證據的，在RFA的明票年代更是如此。計劃中AFH的申請不是投票，也不會使用securepoll，申請人無須擔心被流言暗箭攻擊而無從反駁。--Temp3600（留言） 2022年12月3日 (六) 15:23 (UTC)

Kriz Ju的建議：提高對AFH的技術要求

• (！)意見：個人支持方案草稿，綜觀上方站友討論，個人對相關條文微調意見如下：

• 「申請程序」：「如果您有意申請過濾器助理的權限，請親自到Wikipedia:權限申請/申請過濾器助理權限申請。申請時，經由至少一名已擁有此項權限的回退員，或者具備過濾器相關站務經驗的管理員具名支持後，由具備過濾器相關站務經驗的管理員綜合評估授權；進行授權的管理員不可和前述的具名支持者為同一人。申請者若由於合理因素而無法完成申請條件，可考慮提出具體事由，在客棧尋求協助或發起討論，而擁有相關站務經驗的管理員應對於獲得客棧討論認可的申請者直接完成授權。」
• 「資格要求」：
• 6.「經社群討論，認可為高度可信之使用者」
• 7.「申請者應對正则表達式有基本認識，並且須由擁有相關站務經驗的管理員授權。」個人意見，供參。--Kriz Ju（留言） 2022年12月9日 (五) 19:33 (UTC) --Kriz Ju（留言） 2022年12月13日 (二) 11:12 (UTC)--Kriz Ju（留言） 2022年12月19日 (一) 17:38 (UTC)

( π )题外话 &  吐槽：您所编写的草案条文似乎使用了太多文言表述，导致其理解时有一定难度 囧rz……--Yining Chen（留言|签名页） 2022年12月11日 (日) 01:53 (UTC)

(！)意見：OK，已嘗試直接依站友意見對上方條文進行異動。--Kriz Ju（留言） 2022年12月13日 (二) 11:12 (UTC)

• 「管理員具體考評」未必必要。管理員也未必是技術人才。--Temp3600（留言） 2022年12月19日 (一) 17:20 (UTC)

(！)意見：個人的想法是，無論是否考評，只有同時具備專業能力和社群信任度的用戶能獲權，因此亦僅能由具備該領域能力的管理員授權，才具備某種程度之公信力，否則管理員自己本身一無所知又何以評估是否授權呢？至於具體考評，是比照其他權限可能出現的審核考評，其實也是考給社群看，以獲公信，個人無甚意見，已依站友意見對上方條文意見調整文字，供參。--Kriz Ju（留言） 2022年12月19日 (一) 17:38 (UTC)

個人感覺這一要求略顯嚴格，唯亦不失為確立其地位的策略。看看社群諸君還有沒有什麼意見了。--Temp3600（留言） 2022年12月27日 (二) 16:27 (UTC)

• (！)意見：1.整个授权过程中涉及到两名以上管理员的参与，在实际实行过程中可能存在相当大的困难；2.“具備過濾器相關站務經驗”在判断标准上可能存在问题。仅对过滤器进行小范围的修改并不能证明这名管理员就具备操作过滤器的能力。3.假若该提案通过，想要判断某名管理员是否进行过与过滤器相关的站务处理将变得比较困难。某些管理员可能主要编辑private过滤器，这样普通用户就无法对相关问题进行查证。另一方面来说，想要找到某名用户编辑过滤器的所有记录也相当困难，除非由社群仿照Wikipedia:监督/统计维护一个“管理员参与过滤器编辑的记录列表”。--Yining Chen（留言|签名页） 2022年12月31日 (六) 04:00 (UTC)

第一階段公示：確認分拆

現按上方的共識，進行第一階段公示，確認將AF源碼閱讀權(abusefilter-view-private)從回退員權限中移除。本項的實施則預計在整套方案通過後一次過執行。現就此 公示7日。

新用戶組的細則則仍屬討論階段，誠邀各位就獲權細則，除權條件等細節作深入討論。--Temp3600（留言） 2022年11月27日 (日) 17:01 (UTC)

看来公示期结束了。那就等上边了。--Ghren🐦🕕 2022年12月6日 (二) 10:29 (UTC)

卡。--Temp3600（留言） 2022年12月19日 (一) 03:01 (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)

話說這些頁面的討論頁也挺亂的orz —— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年12月4日 (日) 16:27 (UTC)

下面有必要挂{{不存档}}吗？这应该是一个比较长期的工作，如果没有用户有意帮忙整理这些页面，似乎讨论串开着意义也不太大。--BlackShadowG Slava Ukraini! 2022年12月6日 (二) 12:21 (UTC)

那就先撤除模板吧，改日有進度再議。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年12月16日 (五) 17:03 (UTC)

老實說，目前wikiedu.org已經備有學生和教師的線上訓練，但全都是英文版。

雖然說保留本地版本的線上訓練是沒問題的，但小弟粗略看過了一下，還有不少頁面有待建立…--飄流書生（見山 · 客棧 · DC20） 2022年12月20日 (二) 15:26 (UTC)

新手編輯疑難支援

不另開新文，話說咱們應另行建立一個供新手詢問有關編輯事宜的地方（感覺既有的wp:VPD不太適合）。參考英維，新手大多所問的，均與一些編輯上的疑難有關。

而事實上，英維在其IRC免責聲明頁上有這樣一句：

“ Help is provided by volunteers, so it might take a few minutes before someone replies to your question. Try leaving the chat window open for a bit. If you don't get a reply before you need to leave, consider asking your question at the Teahouse instead. ”

故此，我們需要在既有站外疑難解答群的基礎上，另行建立一個站內版本，為新手編者提供詢問疑難的另一渠道。暫時茶館頁面已成雛形，有興趣可以看看。另可(＆)建議將wp:RD按不同主題分拆，歡迎討論。—飄流書生（見山 · 客棧 · DC20） 2022年12月19日 (一) 04:25 (UTC)

對於茶館，個人持正面態度，惟擔憂加劇疊床架屋之局面；對於知識問答，個人強烈推薦停止使用結構式討論，此技術非常不利於查詢及追溯過往話題。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年12月20日 (二) 13:23 (UTC)

天灭结构式讨论，加载起来巨慢，而且还不能查找 ----顺颂时祺 ZhaoFJx^{（论•编）} 2022年12月21日 (三) 14:44 (UTC)

那么WP:VPA呢？ ——魔琴 [ 留言 贡献 新手2023计划 ] 2022年12月31日 (六) 06:28 (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)

囧rz……怎麼開始討論起我的簽名了？@YFdyh000：您有甚麼看法？-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2022年12月3日 (六) 15:33 (UTC)

这正说明字节数与签名外观或源码是否混乱没有关系，而是否得当也是主观评价。255字节只是参考值而不是任何硬限制，相当于程序运行中可以给警告或通知（notice）日志作提醒，但程序拒绝用户无合理性，只是在偷懒一刀切。--YFdyh000（留言） 2022年12月3日 (六) 16:02 (UTC)

我如果請求@A2569875不要使用那麼多個連結和emoji，A2569875您是否會接受？--Xiplus#Talk 2022年12月4日 (日) 13:12 (UTC)

@Xiplus：我可以說不要嗎？你先訂立方針規定可用的字元（規範emoji）和加入的連結數量限制再說。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2022年12月4日 (日) 13:40 (UTC)

所以囉，255是為此限制的合理「上限值」。--Xiplus#Talk 2022年12月4日 (日) 13:46 (UTC)

@YFdyh000：您有甚麼看法？-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2022年12月19日 (一) 04:59 (UTC)

我表达很清楚了，指引应只是建议值，供讨论和参考使用，个案共识可以覆盖。指引原文“请保持”听上去强制力较高，类似“应当”或“必须”保持，但下文“请使其保持最小的长度”与实践明显不同，最小的程度是不加任何花俏，甚至“--Ex”。所以稍微超出未见构成明显不当。--YFdyh000（留言） 2022年12月21日 (三) 01:06 (UTC)

您前面對「請使其保持最小的長度」的詮釋是「字符值引用愛好者」，怎麼現在又變成越短越好了？這兩個並不衝突，在渲染結果相同的情況下，如果已經盡力縮短語法，卻還是超過255，那就表示該簽名真的太長了。--Xiplus#Talk 2022年12月21日 (三) 03:28 (UTC)

注意“但”，我指“越短越好”和“请保持”均只是态度建议。不认为255字节是个具执行意义的数值。--YFdyh000（留言） 2022年12月21日 (三) 04:46 (UTC)

那我就一句話，從指引移除255這個數字。--Xiplus#Talk 2022年12月21日 (三) 07:01 (UTC)

那這樣怎麼判定簽名是否過長？-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2022年12月29日 (四) 10:02 (UTC)

可以参考曾是英维用户名方针的关于超长用户名（“Usernames that are excessively lengthy and confusing”的条款，diff en:Wikipedia_talk:Username_policy/Archive_9#Inappropriate_names_change_proposal--YFdyh000（留言） 2022年12月21日 (三) 04:58 (UTC)

選擇較長的用戶名，意味著簽名的可變化性降低，這是選擇這麼做的使用者自身的問題，也是他們自己的選擇。--Xiplus#Talk 2022年12月21日 (三) 07:04 (UTC)

其实如果签名里面都是Emoji的话会看着很乱（——诚挚的 ZhaoFJx^{（论•编）} 2022年12月4日 (日) 17:44 (UTC)

這不是就偏好設定簽名那邊你填的那個空格裏面的東西不能超過255位元組嗎，有很不清楚嗎。那兩槓應該就不是那裏面的啊，按道理就不算，除非你在那空格裏面就有寫進去那兩槓了。——〚 玖宸 〛 2022年11月18日 (五) 03:09 (UTC)

@Arronwan：問題是你可以在框框裡填入{{subst:User:XXX/簽名模板}}，那麼關於{{User:XXX/簽名模板}}裡面可以塞多少位元組就不會受到框框裡填入字元數量的限制了。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2022年11月18日 (五) 03:15 (UTC)

@A2569875：那您可以去提個patch如果用subst的話頁面必須在userns、頁面不可以包含模板、如果超過255位元組就無法保存之類的。（突然發現這則留言無意中增加了討論串存檔時間將近七天，深感抱歉（））--SunAfterRain 2022年12月11日 (日) 09:09 (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)

建議將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)

看起來下面部份條文已經有可用的版本出來了。--冥王歐西里斯（留言） 2022年12月11日 (日) 14:01 (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)

(＋)部分支持：提出司法控訴、保留法律追究權、向警方報案，明確表示採取法律或行政手段，造成損害人身安全的風險；若被職員認為社群缺乏自我約束的能力，因此導致基金會行動，結果不是所有人樂見的。 -- 月都 ※ 2022年12月2日 (五) 16:05 (UTC)

(－)部分反對：具體細節需要討論。 -- 月都 ※ 2022年12月2日 (五) 16:05 (UTC)

閣下可在下方的逐條討論發表意見。--冥王歐西里斯（留言） 2022年12月2日 (五) 23:45 (UTC)

謝謝您的提醒，新增條文以淺綠色顯示，刪除條文以淺紅色顯示。 -- 月都 ※ 2022年12月3日 (六) 07:12 (UTC)

(＋)支持--Fox6667（留言） 2022年12月3日 (六) 18:02 (UTC)

(＋)支持。--Kriz Ju（留言） 2022年12月5日 (一) 19:01 (UTC)

(！)意見：“法律威胁的结论”一节加上“在被封禁前应该提醒用户不要诉诸法律威胁”之类的内容。理由：1.不是所有人都知道这一方针 2.用户可能并不是这个意思而对方会“感受到”法律威胁--落花有意12138 _{论 回复请ping我} 2022年12月21日 (三) 09:02 (UTC)

@冥王欧西里斯：(！)意見 导言第二行“您不应该发布法律威胁，而是应该尝试依照维基百科解决争议的程序来处理”后加上“除非前述程序未能达成您希望的结果”。理由：我们应当排斥的是不讨论就采取法律程序，而不是限制合法权利( π )题外话各位注意“权利”和“权力”的区别。--落花有意12138 _{论 回复请ping我} 2022年12月21日 (三) 10:12 (UTC)

反對落花有意的修訂建議，違背LEGAL方針的本意，就算無法達成希望的結果，維基百科也不是釋出法律威脅的地方。--路西法人 2022年12月21日 (三) 11:37 (UTC)

(！)意見：用戶擁有興訟之合法權利或採取各式法律途徑，是個人自由和行為，而法律恫嚇或要脅並非一般站內或社群相關活動應容忍之事，況且訴諸法律者即便不知道站內規範，亦絕無可能於當下毫無訴諸法律之用意，也就是總不可能不知道自己正在告知或施壓對方；反過來講，站內程序是否讓自己滿意，亦非有心於站內活動者公開或私下對他人揚言採行法律途徑，卻無適當理由之藉口。也就是說，人人可以有隨意法律興訟的自由，而站內和社群也可以有阻止此類用戶於此平台或社群內活動的權利；至於法律爭議孰是孰非，正因法律事件樣態複雜，個人才會建議授權管理員決定適當的處理措施。--Kriz Ju（留言） 2022年12月21日 (三) 17:27 (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)

如果是這樣的話，不如改用張貼吧。--冥王歐西里斯（留言） 2022年12月1日 (四) 06:47 (UTC)

(＆)建議：頁面標題維持現狀。序言章節已有「不要在維基百科上發佈法律威脅」，訴諸法律威脅的意思是利用法律威脅途徑解決問題。 -- 月都 ※ 2022年12月3日 (六) 07:27 (UTC)

(！)意見：個人傾向維持原標題。--Kriz Ju（留言） 2022年12月5日 (一) 19:02 (UTC)

(！)意見：看了一下，還是維持原標題好了，改成發佈或張貼似乎反而怪怪的。--冥王歐西里斯（留言） 2022年12月14日 (三) 07:18 (UTC)

（簡而言之）

除直接翻譯外，加上「未被警告的情況下」及「維基百科已有相應的程序處理這些問題」兩句。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

(＆)建議：保留「維基百科已有相應的程序處理這些問題」，這很好地解釋了為什麼不應動用法律手段。--Temp3600（留言） 2022年12月3日 (六) 18:23 (UTC)

(＋)支持：扼要地介紹了什麼不是法律威脅；就如設立方針的理由，首先應循爭議解決程序來解決問題，很多時候能避免訴諸法律來解決問題。 -- 月都 ※ 2022年12月3日 (六) 23:52 (UTC)

（導言第一行）法律威脅的定義

加上「訴訟、舉報、告發」作為舉例。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

（導言第一行）報告地點

未翻譯「elsewhere to an administrator」，原本想說統一報告到管理員布告板。但考量到提報人可能被變為訴訟對象，是不是應該提供私下報告方式比較好？可補翻譯加入「管理員列表」及「管理員專用郵件清單 wikipedia-zh-admin」。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

並列嗎？聽起來應該可以。--冥王歐西里斯（留言） 2022年12月1日 (四) 06:50 (UTC)

(＋)支持：提供相關通報管道更為完備。--Kriz Ju（留言） 2022年12月5日 (一) 19:54 (UTC)

（導言第三行）兩位使用者之間無論是在維基百科或其他地方有法律糾紛，只要沒有在維基百科上發布法律威脅，就不構成封鎖的理由。由於存在利益衝突，陷入法律糾紛的編輯者不應編輯與糾紛有關的條目。

(＆)建議：刪除上述條文。2021年維基媒體基金會行動，顯示了只要蒐集充足的證據，站外的法律威脅會遭到全域封鎖；不一定存在利益衝突，憤怒的時候也可以訴諸法律威脅。 -- 月都 ※ 2022年12月2日 (五) 16:05 (UTC)

(！)意見：建議異動為「使用者之間若因維基百科站內相關活動產生法律糾紛，並獲通報至站內，便可能構成管理員裁量是否以封鎖帳號等方式處理之理由。由於存在利益衝突，陷入法律糾紛的編輯者不應編輯與糾紛有關的條目，相關用戶亦應停止無建設性之不良互動。」由於各式法律爭議不一而足、樣態複雜，且身為志工之管理員通常實無必要或義務主動涉入其中，抑或心力或能力不足，加上此類爭端可能是非難論，此處建議賦予管理員較大之裁量空間。--Kriz Ju（留言） 2022年12月5日 (一) 19:54 (UTC)

（導言第三行）「The only concern of this policy is the posting of legal threats on Wikipedia」未翻譯。

暫未翻譯。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

此方針僅關注在維基百科上張貼的威脅？可能還需要潤一下文字。--冥王歐西里斯（留言） 2022年12月1日 (四) 06:51 (UTC)

(！)意見：個人傾向不需翻譯。--Kriz Ju（留言） 2022年12月5日 (一) 20:03 (UTC)

這得看上面那條的討論結果，如果站外也納入的話，此條就不需要加入，但若維持僅關心站內的法律威脅的話，此條還是寫上為佳。--冥王歐西里斯（留言） 2022年12月6日 (二) 01:26 (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)

WP:NOHIDDENADS吧，所以是指提醒對方關於不得張貼祕密廣告的這件事並不構成法律威脅。--冥王歐西里斯（留言） 2022年12月6日 (二) 07:52 (UTC)

（什麼不是法律威脅）擬增訂Wikipedia:生者傳記

有些請求可能涉及隱私或任何生者傳記規定事項，這些請求可能同時涉及法律威脅，但如果符合Wikipedia:生者傳記規定應移除內容，應優先接受請求，而非指控其法律威脅，以免事態升級。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

（察覺法律威脅）標題

原文為「Perceived 感知、察覺」，暫用察覺一詞。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

Perceived threat与real threat相对，指一方无控告的目的，而其措辞使另一方感觉受到了法律威胁。-Mys_721tx（留言） 2022年12月5日 (一) 20:06 (UTC)

（察覺法律威脅）法律威脅的範例

考量到本案當事人和其他新人不熟悉該方針，參考了Wikipedia:条目所有权#所有权的行为示例和Wikipedia:不要人身攻击#例子都有相關的舉例，給出範例能讓所有人更容易理解界線在哪裡，故目前給出很多範例。但我有在考慮方針是否真的適合收錄範例列表，獨立成一頁作為{{輔助說明}}可能更為合適。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

搬到輔助說明頁吧，這樣也比較好增修。--冥王歐西里斯（留言） 2022年12月1日 (四) 06:54 (UTC)

建議獨立成WP:NLT的子頁面。--冥王歐西里斯（留言） 2022年12月6日 (二) 07:53 (UTC)

(＆)建議：刪除整個章節的條文；任何人都可以不理會法律威脅，並且報告至Wikipedia:管理员布告板/其他不当行为。不必跟隨英語維基百科的版本，片面字句或指控性詞彙常被過於演繹，存在出於善意的可能性，因此嘗試給他人解釋的機會。 -- 月都 ※ 2022年12月5日 (一) 07:35 (UTC)

(！)意見：支持建立輔助說明頁和月都君條文，另建議條文微調為「任何用戶對於法律威脅皆可報告至Wikipedia:管理员布告板/其他不当行为等適當的協助管道。」--Kriz Ju（留言） 2022年12月5日 (一) 20:18 (UTC)

（察覺法律威脅）英文方針原本的舉例「if you repeatedly assert that another editor's comments are "defamatory" or "libelous"」未翻譯

續前，建議留下一個範例即可，但這兩個詞彙似乎都是誹謗，不知道怎麼翻譯，或許可以直接另外寫一個合適的範例。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

美国法律上libel和slander是defamation的子集，libel是书面出版的，slander是口头的。-Mys_721tx（留言） 2022年12月5日 (一) 20:16 (UTC)

(！)意見：個人認為條文可譯為「如果您持續斷言其他編輯的評論是各種誹謗或中傷。」--Kriz Ju（留言） 2022年12月19日 (一) 20:27 (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)

• 大約是指有能力作出法律威脅的一方可以脅迫另一方閉嘴，從而破壞條目的自由編輯制度，導致systemic bias云云。--Temp3600（留言） 2022年12月5日 (一) 14:06 (UTC)

(！)意見：個人認為條文可譯為「社群恐將產生任由爭端出現恫嚇脅迫等行為的風險」--Kriz Ju（留言） 2022年12月19日 (一) 20:40 (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)

(＆)建議：刪除上述條文，保障維基媒體基礎設施或用戶的安全。較為清楚地說明為甚麼不要訴諸法律威脅。 -- 月都 ※ 2022年12月2日 (五) 16:05 (UTC)

(▲)對於保留上述條文改為中立的態度，雖然bad一詞比較含糊。 -- 月都 ※ 2022年12月5日 (一) 07:35 (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)

(！)意見：個人認為條文可譯為「請您在選擇採取法律行動之前，確認已經嘗試所有可能的合理步驟友善解決問題，而相關的爭端調解程序卻仍未解決您的問題。」--Kriz Ju（留言） 2022年12月19日 (一) 20:54 (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)

這段話應該是闡述一種雙重標準定位的參與語境，舊文可能更好體現到旨在防範之風險問題，difficult、setting up和exclusive等是有更一步述明一定隱含之訴諸特徵，考慮結合精煉含義及原意，個人認為結論之闡述為「旨在避免出現以下某類參與者存在之複雜情況，即在社區過程內同時表現出兩種截然矛盾身份且不能調和之參與者，其一方面看似尋求與其他參與者通盤合作之，但另一方面看似尋求合作同時在訴諸對方為官司追查對象之代理顧問」。--約克客（留言） 2022年12月1日 (四) 09:14 (UTC)

簡單而言原提煉句基礎上也可能可以再簡練點，前設是閱覽時意識到其表述一種可能處於司法語境裡更顯矛盾之兩種身份——collaborative partner和litigatious adversary，好比合作證人和檢控方，即同一語境裡一方同時具有兩種角色表徵時即已存疑。--約克客（留言） 2022年12月1日 (四) 09:38 (UTC)

認同。維基人本應團結互助，善意假定，故是被此的 collaborative partner，但如果可能彼此是法律上的對造方，則合作時決不能真心誠意，此一身份矛盾即是維基人間不應以法律手段解決問題的原因。--Temp3600（留言） 2022年12月5日 (一) 10:20 (UTC)

（法律威脅的結論）在使用者討論頁上反覆進行法律威脅所能造成的擾亂及寒蟬效應範圍有限，除非已經合理嘗試發起文明的討論，否則不應禁止編輯他們的討論頁。

但在本案中的當事人實際上很快地（而不是多次提出申訴）被禁止討論頁及電子郵件，我個人不太認為本案（在被封討論頁當下）有達到非常嚴重的情況，如果本地社群決定更嚴厲執行該方針，或是給予管理員更靈活判斷的權力，應刪除本條。但其實本條是保障當事人申訴權利，及避免事態升級。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

(＆)建議：删除上述条文，于当前社群实践不符。--Fox6667（留言） 2022年12月4日 (日) 08:38 (UTC)

(＆)建議：刪除上述條文，在使用者討論頁上反覆進行法律威脅所能造成的擾亂及寒蟬效應範圍有限；如社群已經不可能阻止法律威脅的問題，或提供充分解釋後執意做出訴諸法律威脅的行為，則應禁止使用者編輯自己的討論頁面。有些時候找到代替的方法，意識到法律威脅的缺點，就不會重蹈覆轍，未來是一位建設維基百科的參與者；現實世界裏沒有採取或已完成法律行動或政府程序，參與者放棄追究相關責任，應該獲得解除封鎖的機會。 -- 月都 ※ 2022年12月5日 (一) 07:35 (UTC)

(！)意見：建議微調上述條文為「由於在使用者討論頁上反覆進行法律威脅所能造成的擾亂及寒蟬效應範圍有限，社群應考慮發起適當討論，否則不應未經警醒便禁止編輯他們的討論頁。在社群對相關用戶進行善意溝通後，管理人員可依事態發展適當裁處。」--Kriz Ju（留言） 2022年12月5日 (一) 20:51 (UTC)

續前，電子郵件是否構成法律威脅

翻譯前的原先文字有「如果您決定要訴諸法律行動，請與相關用戶以電郵聯絡，不要把問題放在維基論壇或討論頁。」，而且該方針的規範範圍似乎僅及於公開的地方（可從用戶討論頁就視為不夠公開而給予特別寬容看出），故電子郵件應該不包含在內，但本案中當事人實際上已被禁止電子郵件，另法律威脅已被定義為Wikipedia:騷擾#恐嚇和Wikipedia:不要人身攻击#例子的一種類型，而這兩項規範範圍理應包含電子郵件，因此有矛盾之處。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

(＆)建議：应当认为是法律威胁，因有其他方针如此规定。--Fox6667（留言） 2022年12月3日 (六) 18:10 (UTC)

(！)意見：構成的要件是讓人害怕受到法律行動或政府程序的影響；如使用Wikipedia的電郵聯絡此用戶功能進行法律威脅，或許需要實施封鎖。 -- 月都 ※ 2022年12月3日 (六) 23:52 (UTC)

私下威脅不見得比公開威脅好。--Temp3600（留言） 2022年12月5日 (一) 10:22 (UTC)

(！)意見：建議微調上述條文為「如果您決定要訴諸法律行動，建議您適當知會相關用戶，避免持續透過維基論壇或討論頁等平台相關頁面擴大爭端。」其實既已決定訴諸法律，透過何種途徑、管道或形式聯繫，似已非是否構成威脅恫嚇之關鍵；若前面已有「使用者之間若因維基百科站內相關活動產生法律糾紛，並獲通報至站內，便可能構成管理員裁量是否以封鎖帳號等方式處理之理由。」之條文，爭端仍回歸相關當事人之實際溝通狀況，以及管理員若獲報後之實務判斷。換言之，若相關用戶選擇不通報或已私下協調，則亦無訴諸何種媒介應如何處置的問題。--Kriz Ju（留言） 2022年12月5日 (一) 21:34 (UTC)

(？)疑問所謂私下之法律或他種活動云云，依據過往個案經驗等而言，似乎亦無法避免站域內定義Perceived threat或real threat之可能性，歸結其所隱含之尺度是一個非常需要關聯專業協作之課題，故而可能有必要另行展開專版及適當程序訂立處理，不能全由參與維基計劃之用戶自行承擔被訴諸之風險。--約克客（留言） 2022年12月6日 (二) 02:51 (UTC)

您是把legalwikimedia.org當作擺設嗎？--路西法人 2022年12月6日 (二) 03:43 (UTC)

(！)意見：這項相關規範主要只能用來約束真正有心參與的社群用戶和違規用戶而已（或許類似會員制），理想上希望盡可能提供能讓用戶安心編輯的環境，或至少在發生此類狀況時能有基本應對措施；然而對於站外各種形式的施壓，或是遇到有心人特地來「算帳」或爭執的情況，也僅能加以應對或取得對方理解而已，要是對方根本不參與站內活動，站內也無能為力吧（若涉及法律協助則已超出此規範原意）。因此只能提供各種管道讓用戶適當求助，只有先具備讓人安心、安全發聲反映的管道和規範基礎才有協助的空間。--Kriz Ju（留言） 2022年12月15日 (四) 17:06 (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)

(＆)建議：在阻止破壞的同時也應該假定善意，但假定善意不是自殺協議，持續或無理取鬧的申訴將導致使用者被禁止編輯他們的討論頁。條文與法律威脅無關。 -- 月都 ※ 2022年12月2日 (五) 16:05 (UTC)

不是很看得明白「自杀协议」以及上边两位的解释。--Ghren🐦🕓 2022年12月3日 (六) 09:52 (UTC)

淺紅色標示的是提議刪除條文，理由是僅限於假定善意和解除封鎖的範疇，未能解釋與法律威脅的關係；而且法律威脅的結論章節第一段，提到以原諒的態度對待放棄訴諸法律威脅者。 -- 月都 ※ 2022年12月3日 (六) 11:45 (UTC)

en:The Constitution is not a suicide pact:The phrase expresses the belief that constitutional restrictions on governmental power must be balanced against the need for survival of the state and its people. 大約是指規則設計出來並不是為了要弄死所有人的意思？「及陷於罪，然後從而刑之，是罔民也。」--Temp3600（留言） 2022年12月5日 (一) 13:59 (UTC)

(！)意見：支持刪去「在阻止破壞的同時也應該假定善意，但假定善意不是自殺協議」，但保留「，持續或無理取鬧的申訴將導致使用者編輯他們的討論頁。」；合併前面條文則為：「由於在使用者討論頁上反覆進行法律威脅所能造成的擾亂及寒蟬效應範圍有限，社群應考慮發起適當討論，否則不應未經警醒便禁止編輯他們的討論頁。在社群對相關用戶進行善意溝通後，管理人員可依事態發展適當裁處，持續或無理取鬧的不當申訴將導致使用者被禁止編輯他們的討論頁。」。個人意見，供參。--Kriz Ju（留言） 2022年12月5日 (一) 21:53 (UTC)

更新对法律方针的描述

現行條文 以下方針有法律上的後果。除這些方針外，基金會行動方針、維基百科不會審查內容也有法律上的意義。留意只要內容符合美國法律，維基不會對內容拖加限制。如想向維基百科提出法律投訴，可向維基媒體基金會提出正式投訴

提議條文 Mys 721tx 以下方针有法律后果。除下列方针和基金会行动方针外，只要维基百科上的内容符合美国法律，维基百科不会对自身可能令人反感的内容进行审查，或采纳其他管辖内容的法律提案。法律问题需通过维基媒体基金会正式提出。 月都 以下方針有法律後果。除下列方針和基金會行動方針外，只要維基百科内容符合美國法律，維基百科不會對自身可能令人反感的内容進行審查，或受其他管轄內容的法律提案約束。有關維基百科的法律問題，請參考爭議解決指引以及請不要訴諸法律威脅。 Kriz Ju 以下方針有法律後果。除下列方針和基金會行動方針外，只要維基百科上的内容符合美國法律，維基百科不會對自身可能令人反感的内容進行審查，或使其受其他內容約束或審查相關法律囿限。關於維基百科的法律問題，可參考爭議解決指引、請不要訴諸法律威脅；如想對維基百科提出法律投訴，請向維基媒體基金會正式提出。

顺手重新翻译了一下法律方针的描述。-Mys_721tx（留言） 2022年11月21日 (一) 05:50 (UTC)

(＋)支持：社群对不得进行法律威胁之条文虽现无明确列入其中，但已在实践过程中受到普遍性的承认。诸如WMC事件、修订傀儡方针涉及法胁内容以及诸管理员在封禁案例上也有体现。现在明文加入其中，显然是适当的。——2022年11月22日 (二) 15:37 (UTC)--以上未簽名的留言由維基百科最忠誠的反對者（討論｜貢獻）加入。

(！)意見：雖然法律與判刑存在密切關係，但法官或律師意見可能有助於改進維基百科，且不一定被社群採納。通常接受理性討論；通常不接受法律威脅，即針對個人、團體或組織。 -- 月都 ※ 2022年12月3日 (六) 07:12 (UTC)

(▲)鼓勵採用站內的爭議解決程序；不鼓勵以法律作為武器，強迫別人支持非方針或使用條款的法律觀點。 -- 月都 ※ 2022年12月5日 (一) 08:06 (UTC)

(＋)支持相關修訂，個人微微彙整上方兩位站友版本。--Kriz Ju（留言） 2022年12月5日 (一) 22:21 (UTC)

(＋)支持Kriz Ju的版本。--冥王歐西里斯（留言） 2022年12月6日 (二) 07:58 (UTC)

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

提議修改WP:共識

根據WP:7DAYS，沒有提及公示結束後的結案流程，例如誰負責按照共識修改方針及指引。現提議由行政員以上的編輯者宣布公示完成及存檔。如果整個公示沒有得到行政員以上的編輯者確認，視「討論未完成」論。
Q：為什麼這樣提議？
A：可靠來源方針公示通過後，管理員@U:Ericliu1912以不承認結果為由回退相關共識，他指出他「看不到相關共識」。由此看來，若管理員不承認相關共識，存檔亦沒有意義，畢竟管理員有共識解釋權。 --唔好阻住我愛國（留言） 2022年12月5日 (一) 05:13 (UTC)

感觉不太可行，公示的内容太多了，行政员估计没有那个精力。在这里号召改变7DAYS不如直接联系行政员--Fox6667（留言） 2022年12月5日 (一) 08:47 (UTC)

如果是基於現時的WP:7DAYS，我是可以回退管理員的回退，因為7日無新發言即可公示，方針亦無要求像wp:ga一樣有足夠票數才能完成公示，只要求公示日數，公示期間有問有答也可以。而本人提案的公示過了兩個月仍得不到管理員的回應。按照方針，沒有回應等於默許，因此沒有任何權力讓管理員否定公示結果。

直接聯繫行政員或管理員亦不是好結果，因為他們可以無視ping。根據公示版記錄，一個月內公示的內容不多於20則，而擁有行政員以上權力的編輯者有大約30個，因此沒有加大工作量的問題。--唔好阻住我愛國（留言） 2022年12月5日 (一) 09:57 (UTC)

什么叫「擁有行政員以上權力的編輯者有大約30個」？WP:行政员：「目前中文维基百科的行政员有7名」。--Ghren🐦🕖 2022年12月5日 (一) 11:07 (UTC)

行政員7個，管理員[5]個--唔好阻住我愛國（留言） 2022年12月5日 (一) 11:17 (UTC)

行政员拥有管理员所有权限，管理员则不然，所以管理员是不算的在「行政員以上權力的編輯者」中的。--Ghren🐦🕖 2022年12月5日 (一) 11:30 (UTC)

可能是我口誤，應指管理員及行政員。--唔好阻住我愛國（留言） 2022年12月5日 (一) 11:58 (UTC)

• 管理員擁有共識解釋權。如果行政員不出面，只能視為他們同意管理員的決定。--Temp3600（留言） 2022年12月5日 (一) 10:15 (UTC)

  管理員不是大法官，沒有“解釋”權，有解釋權的是社群。桐生ここ★[讨论] 2022年12月12日 (一) 08:37 (UTC)

  請問維基百科是實行「陪審團制」？--唔好阻住我愛國（留言） 2022年12月12日 (一) 10:03 (UTC)

很奇怪為什麼一定要管理員來講沒有明顯共識才要理會，SCP-2000君先前也有回退了Special:Diff/74738339，社群什麼事情都一定要管理員來講才會有人理會，應該不是這樣的吧，如果管理員們不說怎麼辦，社群是不是就這樣強推方針指引。然後我不是很認同上面所說只有管理員才有共識解釋權，這不是管理員獨有的。--~~Sid~~ 2022年12月5日 (一) 14:52 (UTC)

誰執行WP封鎖，誰就有共識解釋權。--唔好阻住我愛國（留言） 2022年12月5日 (一) 15:05 (UTC)

這個做法可以確保管理員在執行WP的價值觀與共識初衷一樣，管理員也可以向討論者提出一些問題釐清共識中的一些問題，以減少管理員詮釋共識的機會。--唔好阻住我愛國（留言） 2022年12月5日 (一) 15:12 (UTC)

那今天如果管理員不出面怎麼辦，其他編者不是管理員就不能釐清共識中的一些問題，應該不是這樣的吧，管理員本來就可以解釋共識，但這並不因為他是管理員，其他編者同樣能解釋，每一位編者(包含管理員)對共識方針指引的解讀解釋本來就會不太一樣，但基本上大同小異。你不能因為SCP-2000君不是管理員就無視掉他，你應該去尋求更強的共識。--~~Sid~~ 2022年12月5日 (一) 15:22 (UTC)

That is their duties. 我也可以解釋方針內容，也可以按照方針指示進行公示，但公示完成後兩個月才有管理員發覺不妥，會不會是管理員失職或沒有了解整個討論發生什麼事。另外，綜觀整個討論， SCP-2000沒有提出意見，只是提出規程問題，按照WP:7DAYS，相關問題並不是有效意見。--唔好阻住我愛國（留言） 2022年12月5日 (一) 15:32 (UTC)

复习管理员方针：“管理员……唯能实现社群讨论所得的共识”。社群必须有自己先有明确的共识，管理员才能执行，而不是管理员解释共识。--Tiger（留言） 2022年12月5日 (一) 15:41 (UTC)

何謂「實現」？如何「實現」？--唔好阻住我愛國（留言） 2022年12月5日 (一) 15:51 (UTC)

已按照WP:7DAYS進行完整公示的內容未得到管理員實現，會不會是WP:7DAYS的問題，還是管理員對共識不理解才有這個問題？--唔好阻住我愛國（留言） 2022年12月5日 (一) 15:54 (UTC)

修改方针文本和实现讨论得出的共识不是一件事。比如今天社群讨论说，禁止使用互助客栈。那去条文里写上“禁止使用互助客栈”不是实现方针，保护客栈页面才是。你的提案“由行政员以上的编辑者宣布、修改及存档”和“实现、执行共识”就是两件事。--Tiger（留言） 2022年12月5日 (一) 16:10 (UTC)

這個就是其中一個bug「今天社群討論說，禁止使用互助客棧。那去條文裡寫上「禁止使用互助客棧」不是實現方針，保護客棧頁面才是。」如果管理員在公示期間發現這個bug ,可以在實行前提供指引進行修正。因此由管理員以上的編輯者可宣佈發還重新討論以攔截相關的bug或實行共識。--唔好阻住我愛國（留言） 2022年12月6日 (二) 03:19 (UTC)

这不是bug，你错误理解了我说的话。--Tiger（留言） 2022年12月6日 (二) 03:31 (UTC)

重點是這句 「如果管理員在公示期間發現bug ,可以在實行前提供指引進行修正。因此由管理員以上的編輯者可宣佈發還重新討論以攔截相關的bug或實行共識。」--唔好阻住我愛國（留言） 2022年12月6日 (二) 11:06 (UTC)

管理員是有責任清楚了解共識內容及確認與現有的方針指引沒有衝突。上方清楚展示「管理員不出面」的最終結果，就是不斷的回退及復原。--唔好阻住我愛國（留言） 2022年12月5日 (一) 15:36 (UTC)

如果我有誤解你的意思，請糾正我謝謝。--~~Sid~~ 2022年12月5日 (一) 15:23 (UTC)

修正留言，如果有我誤解各位的意思，請糾正我謝謝。~~Sid~~ 2022年12月5日 (一) 14:55 (UTC)

我會說是位階的分別，就像AFD一樣。--Temp3600（留言） 2022年12月5日 (一) 15:04 (UTC)

了解。--~~Sid~~ 2022年12月5日 (一) 15:25 (UTC)

避免誤會，先澄清一下，我在判斷討論共識、回退相關編輯時並非有意識地以管理員身份執行操作，也沒有「以管理員身份不承認相關共識」（而且如Tigerzeng君所說的，個人應該也沒有這種權力），不過就此話題而言要把我視為一般編者或管理員都行。我個人主要考慮的是方針的穩定性，以及由此衍生修訂方針所需之共識基礎。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年12月5日 (一) 16:34 (UTC)

不好意思，但我也看不出且不看好那则讨论得出共识，所以更不用提“公示”之效果，只能说没有明确与坚决的反对，但这不代表充分支持，所以依旧建议您不要寄希望于7DAYS公示为其条文规定赋予相当大的强制力。某些提案能迅速得到许多{{支持}}，且无反对，这种情况下公示效果较好。而意味和效果含糊的提案哪怕有一些支持且无反对，并且公示相当久，实际广泛执行时仍可能出现许多未知情况和新增反对，此时不应该以“公示期满”盖过新增反对意见。--YFdyh000（留言） 2022年12月5日 (一) 18:25 (UTC)

唯WP:共識 並沒有要求以投票完成公示，只是要求公示足夠日數及無有效反對即可。在方針下「迅速得到許多{{{{支持}}}}」與「默許」的意思是一樣。--唔好阻住我愛國（留言） 2022年12月6日 (二) 03:02 (UTC)

難道你的意思是走「試行版FA」制才能凝聚共識？例如修改方針的話需要20個編輯者投支持票及解釋支持原因，修改指引的話需要10個編輯者投支持票及解釋支持原因，其他共識的話需要5個編輯者投支持票及解釋支持原因。--唔好阻住我愛國（留言） 2022年12月6日 (二) 03:06 (UTC)

[6]看來真的有這個需要修改共識方針。

建議的Points:

1. 建議在五大佈告版提出的討論必須以ping方式通知曾在一個月內編輯該條目及關聯條目的非ip使用者參與討論。

2. 公示內容必須以投票或其他形式統計「有效看法」，即「支持反對中立」+意見。

3. 沒有進行公示或公示失敗的提案均以「討論沒完成」處理，即等於無效。

4. 需由管理員或行政員宣布「公示完成」及由他們處理後續工作。包括存檔及實現共識。

5. 建立完善的共識庫，列出條目類別的所有共識，方便新編輯者遵守。--唔好阻住我愛國（留言） 2022年12月6日 (二) 15:19 (UTC)

這差不多等同成立秘書處了。我很懷疑社群有沒有足夠人志願參與這項工作。--Temp3600（留言） 2022年12月6日 (二) 15:21 (UTC)

@Temp3600:

請留意，現有的WP:RSN正正是走這個制度，現時也有不少討論引用這個經完整流程而產生的內容。--唔好阻住我愛國（留言） 2022年12月8日 (四) 16:19 (UTC)

RSN可不要求管理員或是別的成員必須承擔責任。實務上也不可能。--Temp3600（留言） 2022年12月13日 (二) 17:30 (UTC)

RSN是論述文件，影響有限。

而更改方針或共識會牽連數十至數千條目，影響較大。--唔好阻住我愛國（留言） 2022年12月14日 (三) 01:55 (UTC)

管理員並不是您或維基百科的員工，沒有天天上班處理站務的義務。普通用戶更不必說了。如果方針通過後要等一個月才有管理員前來改方針，那顯然還是現狀要好得多。至於共識庫，你現在就可以自己建立。事實上某君在自己的用戶子頁是有一個類似的圖書館的。--Temp3600（留言） 2022年12月14日 (三) 19:17 (UTC)

1. 請問一星期有多少個走足程序的共識通過？
2. 「某君」即是何君？難道他的首頁就是wiki首頁？

--唔好阻住我愛國（留言） 2022年12月21日 (三) 14:43 (UTC)

不支持。维基百科不是官僚主义。0xDeadbeef（留言） 2022年12月12日 (一) 14:23 (UTC)

基於目前的存檔制度，你可否在10分鐘內說出通過了什麼與TV相關的共識？--唔好阻住我愛國（留言） 2022年12月12日 (一) 14:33 (UTC)

你的提议没有改变存档制度的任何一部分--0xDeadbeef（留言） 2022年12月12日 (一) 14:58 (UTC)

「建立完善的共識庫，列出條目類別的所有共識，方便新編輯者遵守。」???--唔好阻住我愛國（留言） 2022年12月12日 (一) 15:26 (UTC)

哦。这个不反对，但是这个和管理员关闭共识讨论没关系。--0xDeadbeef（留言） 2022年12月13日 (二) 00:17 (UTC)

最主要是用作check bugs 及能否讓管理員清楚明白公示內容。--唔好阻住我愛國（留言） 2022年12月13日 (二) 03:53 (UTC)

(－)反对，憑什麼是行政員？那你要不要把所有方針與指引都行政員保護算了，還不用提出這個案子，多好，反正意思一樣嘛？（我當然知道這個保護級別不存在，請不要雞蛋裡挑骨頭）--SunAfterRain 2022年12月25日 (日) 15:33 (UTC)

(－)反对让共识的形成官僚主义化。--BlackShadowG Slava Ukraini! 2022年12月29日 (四) 02:23 (UTC)

增修MOS:两岸以促衡平

此前關於Wikipedia:格式手册/两岸四地用语#避免使用之詞彙列有「中共當局」而無「國民黨當局」、「民進黨當局」有過些微討論，現提議相應對等修訂，促進公正衡平：

現行條文 現行版本 基於中立原則，不應使用「中共當局」等詞語指代中華人民共和國。

提議條文 提案A版 基於中立原則，除非必要的原話直接引述，不應使用「中共當局」、「國民黨當局」、「民進黨當局」等詞語指代兩岸任何一方政權及其機關或部門。 提案B版 （另起一段） 基於中立原則，不應使用「中共當局」、「國民黨當局」、「民進黨當局」等詞語指代兩岸任何一方政權及其機關或部門，除非用於下列情境之一： 必要的單句原話直接引述，且該限制詞語不在句首或句末（故而難以轉寫）；或 必要的多句原話直接引述；或 兩岸之中一方政權的公民或團體用以指稱己方政權或其機關。

（有序列表皆爲新增條文，新增的條文模板跨越有序列表似乎失效，敬請見諒）

参考資料

一版言簡意賅、一版周詳全面，各具優勢，以供討論。--Gohan 2022年12月8日 (四) 10:42 (UTC)

（新增條文的部分沒有顯示顏色的部分用了些小伎倆處理了，但很抱歉html就是沒法用你原本的用法達到那個效果。--SunAfterRain 2022年12月10日 (六) 06:51 (UTC)）

考慮當局有政府之意，亦不可能拿「中共當局」來稱呼中華民國（反之同理），建議：

現行條文 基於中立原則，不應使用「中共當局」等詞語指代中華人民共和國。

提議條文 基於中立原則，不應使用「中共當局」等詞語指代中華人民共和國及其政府，也不應使用「國民黨當局」、「民進黨當局」等詞語指代中華民國及其政府。

以上。因格式手冊於原則章節即稱「除了專有名詞、引錄人物原話、檔案原文、機構正式名稱等既有內容之外」，故認為沒有特別重申之必要（否則此格式手冊每一章節都會充斥相同但書了）。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年12月8日 (四) 11:33 (UTC)

基本接受。但「國及其政府」側重「大」政府，可能有令人解讀為不適用於某某某内閣之虞，或許有在「國及其政府」後增加「、内閣或部門」的必要。 Gohan 2022年12月8日 (四) 12:35 (UTC)

考虑到存在“非正式政权”时期，及中立原则主要由于可能用于恶意贬损，不建议这样阐述。如中华人民共和国建国前的中共执政地区的政府。--YFdyh000（留言） 2022年12月11日 (日) 05:28 (UTC)

目前不考慮規範中共「建政」以前的情形。「中共當局」最主要也還是拿來指稱「中華人民共和國」及其「政府」。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年12月12日 (一) 01:52 (UTC)

方針主要在體會其精神。有沒有「國民黨當局」、「民進黨當局」不影響其執行效力。Ghren🐦🕗 2022年12月8日 (四) 12:26 (UTC)

也許有人詮釋此精神為中共前綴的機構用詞不可用，而非××當局。為免含混，字數較少的增修有益無弊。--Gohan 2022年12月8日 (四) 12:42 (UTC)

同上。--YFdyh000（留言） 2022年12月11日 (日) 05:28 (UTC)

補上兩個月前的討論內容。Wikipedia:互助客栈/方针/存档/2022年10月#維基百科:格式手冊/兩岸四地用語_需要澄清--唔好阻住我愛國（留言） 2022年12月8日 (四) 16:01 (UTC)

(－)反对:如要這樣實行，首先需存廢「中共當局」、「國民黨當局」、「民進黨當局」及重定向至「中國共產黨」、「國民黨」、「民進黨」，因為裹邊的消岐義內容直接承認「中共當局」=中國政府、「國民黨當局」、「民進黨當局」=台灣政府，現有消岐義內容與閣下的提案產生衝突。--唔好阻住我愛國（留言） 2022年12月8日 (四) 16:15 (UTC)

@HK5201314：這不矛盾。百科文字禁制是因爲涉有貶損意味，而讀者搜尋涉有貶損意味的文字可達通常説法是為便利，這不代表二者不等同或近似。而照閣下之意，不只是反對提案，更反對上列全部現行條文，不如您提出一版全部刪除的提案，供大家評選？ Gohan 2022年12月9日 (五) 01:56 (UTC)

• 重點是「及其政府」。
• 如果要提出這個提案，煩請將消歧義內容一併討論其去向。
• 如果台民黨成員當選台灣領導人職位，是不是又要更改方針？我的意思是請修改用詞至所有情況也合適。
• 好奇一問，美國會不會使用共和黨當局、民主黨當局? 英國會不會使用保守黨當局？建議這個地方可一併修改。

--唔好阻住我愛國（留言） 2022年12月9日 (五) 03:49 (UTC)

1. 原文和提案均不肯定、亦不否定「某黨當局」可指或等同「某黨政府」。惟「某黨當局」往往帶有貶抑意味，才在百科全書加以禁制。故無衝突。
2. 該消歧義頁無上述禁制詞語，并不冲突。重定向是便利讀者的捷徑，故標準應較寬鬆，其存在不意味認可其在百科全書各處均可用。格式手冊針對條目編寫，恐怕不適用於重定向。即使適用，指引也凌駕於先在的零星重定向，您可以此為据提出刪除，亦不衝突。重定向存廢顯然不適宜在此處討論。
3. 一例不足類比，但二、三例足以令正常人類比。何況有“等詞語”，“等”即此等。因此無需時時修改。若閣下仍有疑慮，「等詞語」可改爲「等黨名與「當局」構成之詞語」。
4. 中文媒體確會如此使用。某某政府已在不修訂的前文中提及，加之修訂阻力較大，況且這是两岸四地用语的指引，此次不修改。 —— Gohan 2022年12月9日 (五) 04:34 (UTC)

[7]：「另一種可能則是，拜登民主黨當局以至共和黨援烏派為了確保美國繼續援助烏克蘭，將利用美國上下一致的抗華共識......」

[8]：「和民主黨執政的非法移民庇護城市紐約、芝加哥等地，與民主黨當局開展一場非法移民遊戲。」--Ghren🐦🕑 2022年12月10日 (六) 06:57 (UTC)

現行條文 基於中立原則，不應使用「中共當局」等詞語指代中華人民共和國。

提議條文 基於中立原則，不應使用「政黨當局」指代任何政權及其機關或部門。除非是直接引述發言，否則編輯者需轉換詞語至相應的政治機構及部門。

--唔好阻住我愛國（留言） 2022年12月9日 (五) 04:26 (UTC)

您的提案與現有提案修訂方向一致，惟在二處措辭有別。 Gohan 2022年12月9日 (五) 06:08 (UTC)

提案第二句不必要，已有編者指出與原則章節重複。 Gohan 2022年12月9日 (五) 09:44 (UTC)

此为当前条文之扩展，已超出“两岸四地用语”范畴，建议慎重考虑再用。比如，“塔利班当局”是不中立内容吗，“塔利班”指政权还是政党是模糊地带。以及，如果有意写成“xx执政下的xxx部门”，仍会存在问题，该条文不能有效避免。--YFdyh000（留言） 2022年12月11日 (日) 05:28 (UTC)

1. 如果真的是中立的話，就不應在指引內點名某一政黨而忽略其他政黨。
2. 政府-（行政、立法、司法）均需以政黨名義100%全權控制才能使用政黨+當局。
   1. 中華人民共和國的立法機關-全國人大常委會內有多名人士也沒有中共背景，如譚耀宗。
   2. 台灣的藍綠之爭不用說吧！
   3. 香港及澳門人如要加入特區政府，需退黨。

由此可見，在兩岸四地中根本沒有「政黨當局」存在。

至於塔利班問題，請在建立全球政治用語格式手冊時再拿出來討論。--唔好阻住我愛國（留言） 2022年12月11日 (日) 08:32 (UTC)

各提案修訂方向一致，主要有二處用字各有差別：

• 基於中立原則，不應使用 ⟨ 甲 ⟩ 指代 ⟨ 乙 ⟩ ，也不應使用 ⟨ 甲 ⟩ 指代 ⟨ 乙 ⟩ 。
• 基於中立原則，不應使用 ⟨ 甲 ⟩ 指代 ⟨ 乙 ⟩ 。

⟨ 甲 ⟩ ：

• 1. 「中共當局」等詞語；「國民黨當局」、「民進黨當局」等詞語。
• 2. 「政黨當局」。

⟨ 乙 ⟩ ：

• 3. 中華人民共和國及其政府；中華民國及其政府。
• 4. 任何政權及其機關或部門。

——Gohan 2022年12月9日 (五) 10:36 (UTC)

@HK5201314：單是「政黨當局」可能令人理解為僅此四個字構成的專有名詞不可用，點名舉例在所難免，不妨將甲處文字改爲：「中共當局」、「國民黨當局」、「民進黨當局」等政黨名稱並合「當局」構成之詞語。—— Gohan 2022年12月11日 (日) 13:29 (UTC)

@HK5201314、Ericliu1912：國及政府、政權、内閣、機關、部門等乙處表述尤有分歧，不如二位分別闡述前述字詞的優勢與劣勢。—— Gohan 2022年12月11日 (日) 13:29 (UTC)

上方「2022年12月11日 (日) 08:32 (UTC)」時回應了。--唔好阻住我愛國（留言） 2022年12月11日 (日) 13:39 (UTC)

此格式手冊之目的是不全面、但精確地規範兩岸四地常用詞彙，無涉其他任何地區。除上方指出之語法問題，亦未見有擴大範圍至「任何政權及其機關或部門」之必要。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年12月12日 (一) 01:49 (UTC)

舉例來説，或許有人在疫苗采購等事件以「民進黨當局」指代蘇貞昌内閣、衛生福利部、流行疫情指揮部等，并認爲此條文不適用於如此指代，因此有必要擴展至「内閣、機關或部門」。至於「任何」，我的原提案有「兩岸」作爲前置定語，或可恢復此定語，但在兩岸四地的標題下此定語或許無必要。—— Gohan 2022年12月12日 (一) 12:27 (UTC)

• 難聽地說一句，「中什麼立啊」，只有不熟悉兩岸四地政制的編輯者才說這句話。正確的應該是依循現時兩岸四地的現有的憲法及當前的政治形勢，語出不存在一個政黨百份百控制整個政府。
• 「中共當局」、「國民黨當局」、「民進黨當局」等以政黨名稱並合「當局」構成之詞語。
• 政府=（行政、立法、司法、軍事），不管是否行政主導還是四權分立，總之不是以政黨名義控制整個政府就不能用。
• 所以準確來說是「行政部門、立法機關、司法機構、軍隊」。
• 標題寫「當局」。

--唔好阻住我愛國（留言） 2022年12月12日 (一) 02:13 (UTC)

建議表述改爲：基於中立原則，不應使用以政黨名稱並合「當局」構成之詞語指代兩岸任何政權及其機關、内閣或部門，例如「中共當局」、「國民黨當局」、「民進黨當局」等。 可一并解決二位的疑慮。—— Gohan 2022年12月12日 (一) 12:33 (UTC)

「政府」就包含「機關、内閣或部門」了。然後主要也就三種詞語常用，為什麼一定要強制揉合為所謂「以政黨名稱並合『當局』構成之詞語」，而不更明白地列舉呢？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年12月12日 (一) 13:33 (UTC)

如以中立方針，不應在指引內點名某一政黨而忽略其他政黨。『基於中立原則，不應使用「中共當局」等詞語指代中華人民共和國及其政府，也不應使用「國民黨當局」、「民進黨當局」等詞語指代中華民國及其政府。』，假如按照這句說話，如果將來國民黨及民進黨沒落，後人就不會知道當年是刻意點名這兩個政黨不能用，還是基於方針或政治形勢而禁止使用這個組合。--唔好阻住我愛國（留言） 2022年12月12日 (一) 14:26 (UTC)

方針與指引等規則是給人遵守的，自然要講實用主義，而不全然訴諸應用於條目中之「中立的觀點」原則。在現今海峽兩岸政治中，只有上開三黨可能出現「當局」用法，規範除此以外的其他政黨毫無意義，反而有「管太寬」之虞；而無論是內閣、行政機關或其他部門，在定義上本來就都是政府的一部分，範圍甚至有一些重疊，沒有見到特地拆開列舉的必要。還要指出，現今用「當局」，基本都是指政府，若指特定機關或部門，會直接寫在後面（例如「臺灣當局行政部門」）。前面提到中共批評民進黨防疫或外交等政策時，用「民進黨當局」，實際上也不會是指特定部門，而是整個（民進黨執政的）中華民國政府。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年12月13日 (二) 19:58 (UTC)

然而各下版本首句就說「基於中立原則」。--唔好阻住我愛國（留言） 2022年12月14日 (三) 02:00 (UTC)

那是兩回事。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年12月14日 (三) 04:18 (UTC)

不妨在正文「政府」後注釋：政府包括政府機關、政府部門或政府任何部分。在正文中可不提及機關、部門。 Gohan 2022年12月16日 (五) 14:14 (UTC)

海峡卫视：民进党当局相关负责人赖清德、游锡堃。--Gohan 2022年12月17日 (六) 00:23 (UTC)

整體包括部分，但不等同部分。不應指代整體不可推出不應指代部分。正如假定廢物不能指代人，不能推出廢物不能指代人的手脚。--Gohan 2022年12月12日 (一) 14:45 (UTC)

基本( ✓ )同意最初的提案A版。B版太长，不好理解。但是A版里机关是什么意思，海外说中文的人不好理解。建议改为“两岸任何一方政权及其政府部门”。不过要说“当局”，中文文化有个坏习惯就是喜欢把行政部门当成政权。英文比如Biden Administration，翻译成拜登行政部门，这样很明显拜登不控制立法、司法。--Gqqnb（留言） 2022年12月17日 (六) 16:19 (UTC)

中央或地方的一級機關有如行政院、立法院或中央人民政府、省市人民政府等，都不算是部門。構成機關的部分是部門，部門也可稱作機關，但一級機關不可稱爲部門。 Gohan 2022年12月18日 (日) 01:24 (UTC)

• 敝人在大致閱覽上方站友討論後，嘗試表達如下：

現行條文 基於中立原則，不應使用「中共當局」等詞語指代中華人民共和國。

提議條文 基於中立原則，不應使用以兩岸任一政黨作為代表之詞彙，包括但不限於「中共當局」、「國民黨當局」、「民進黨當局」等詞語，指代「中華人民共和國」或「中華民國」及其政府之全部或一部。

個人同時有個考量是：中文維基百科並非僅兩岸讀者閱覽，讀者可能來自世界各地，他們可能只覺得兩岸關係超級複雜而已；因此相關條文若能盡可能達到「有效規範、不致衝突」，讓編者好寫、讀者好讀、兩不相怨，或也算功德無量（雖然未必能這麼樂觀就是了（笑））。個人意見，供參。--Kriz Ju（留言） 2022年12月20日 (二) 22:12 (UTC)

不錯。 Gohan 2022年12月21日 (三) 04:27 (UTC)

(＋)支持--唔好阻住我愛國（留言） 2022年12月21日 (三) 14:44 (UTC)

这里我感觉有个小问题，中华人民共和国是国家，中共当局更类似于政府/政权，虽然差别不大，但我觉得在里面加入”政府“一词更好，即“指代‘中华人民共和国政府’或‘中华民国政府’”，虽然但是，我很赞成这个提案，毕竟原文只提到”中共当局“也是一种不公不中立嘛（笑），主要是这样以来清晰的多，语义上的不明也会小很多，覆盖的面也更广，我(＋)滋磁这个提案-- Xi_Ying • Talk 2022年12月23日 (五) 09:51 (UTC)

(＋)強烈芝士此提案，不只單單「中國當局」需要這樣的，而且內容更清晰。認為還是第一提議更好，因為簡潔性強，不過也可以合併為：

「基於中立原則，除引用外，不應使用「中共當局」、「國民黨當局」、「民進黨當局」等詞語指代中華人民共和國或中華民國/台灣的政府。」--FK8438祝您剩蛋快樂（簽名）🎄🎄 2022年12月26日 (一) 08:52 (UTC)

@Ericliu1912：閣下對此案意下如何？ Gohan 2022年12月27日 (二) 08:13 (UTC)

否。為什麼要混在一起？分兩句寫又沒差多少。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年12月27日 (二) 20:17 (UTC)

指代二方都是不當，寫在一起亦無不可。 Gohan 2022年12月28日 (三) 02:13 (UTC)

根本沒有必要寫在一起，徒增誤解。還缺那幾句空間好好指明？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年12月30日 (五) 11:31 (UTC)

那不是「基於中立原則」，而是因為這些詞語不清楚，才以更加精確的詞語表達而已嘛，和「基於中立原則」有什麼關係。Ghren🐦🕛 2022年12月27日 (二) 16:42 (UTC)

(？)疑問：“不应使用以两岸任一政党作为代表之词汇”是否包含以某黨執政下的政府，如“民進黨政府”“國民黨政府”以及“中國共產黨政府”？——WMLO（留言） 2022年12月28日 (三) 22:55 (UTC)

应该不包含吧。（仅为个人猜测）Walker114514（留言） 2022年12月30日 (五) 01:51 (UTC)

• (！)意見：敝人綜合回覆以上站友疑問：

1.關於加入政府一詞更好，即「指代『中華人民共和國政府』或『中華民國政府』」：個人認為這便是上方站友我愛國閣下的第一案內容，必與下方第二案Eric閣下的內容直接扞格（笑）。

2.如果不是為求用詞中立、避免「XXX當局」所可能隱含之歧視（即「非中立」）性質，此命題便應該不存在了。就此用語規範而言，個人認為僅談及避免不當使用特定詞彙，未深入挖掘或論及詞彙間的意涵；換言之，個人甚至認為談的是適當的寫作程序，而非實質專有名詞「中華人民共和國」和「中華民國」之間的指涉關係或意義。

3.「不應使用以兩岸任一政黨作為代表之詞彙」是否包含以某黨執政下的政府呢？敝人的條文言及：指代「中華人民共和國」或「中華民國」及其政府之全部或一部，因此就是指單以政黨稱為「XXX當局」不妥適稱呼其執政下的政府（包含上方站友討論已久的政府所屬機關（構）等各種專有名詞或詞彙，又或是政黨政治下的哪個政黨把持哪個政府機關等歧異）。

4.「XX黨政府」等詞彙之禁絕使用是否包含於此條文的限縮範圍內呢？個人的答案是一般情況下若以執政黨為首概括其政府則不包含，但是若以我愛國閣下上文的各種思考而言，或許也有人會有疑慮（比如若是政黨政治中的在野黨統領民意機構，但此種情況下，亦不會稱其為「某在野黨政府」，哪怕的確是政府的一部分，我愛國君的此類疑慮當然也是一種思路就是），因此個人的想法是：不禁絕使用執政黨政府之類的詞彙，惟使用上或需謹慎（比如談及中華人民共和國政府時，「中共政府」與「中共當局」是否可能涉及非中立或歧視？又或者是否暗示或指涉特定意涵和偏好的兩岸關係？兩個詞彙間的使用是否可能如何相通、混淆或相悖？兩者的意義和實際所指是否也有重疊之處？），亦不在此案明確規限內容或禁止範圍中（已明確列舉三個當局作為範例）。編輯實務上，個人認為除了「XXX當局」系列，其他「XX黨政府」之使用若出現疑慮，或屬編輯爭議，得視具體案例討論了。

5.為什麼要混在一起呢？依個人看來，前兩案顯然都有站友各自的觀點偏好，最後很可能幾乎不會有任何共識；既然如此，若同樣死局、死豬不怕滾水燙，敝人不過姑且折衷提出，除了字義上無實質異動，解決原本的問題，也希望盡可能在達成初始立意外，（嘗試）兼容各方需求。至於是否誰被誰吃豆腐，又或者誰占了更多便宜，無論如何只能說看看是否能各取所需了。--Kriz Ju（留言） 2022年12月30日 (五) 23:19 (UTC)

剧集列表类条目的写法规范

近期参考英维的FLen:List of Devil May Cry episodes撰写了魔女之旅剧集列表，并将其评选FL，使之成为中维首篇参选FL的剧集列表，但这次评选引发了不少争议，因此前来此处寻求社群关于剧集列表类条目写法的共识。

剧集列表（episode list）在英维是用于列出每一个电视剧（包括电视动画）作品的剧集，每篇剧集列表的写法通常是在导言简要介绍作品的信息，并使用{{Episode table}}和{{Episode list}}模板列明作品的所有剧集，带有各集的剧情摘要。

然而，这样的写法带到中维引发了一定的争议，有编者认为这样的剧集列表也需要包含与剧情摘要成比例的制作与发行等信息，也就是每集除了剧情摘要，还需要加入每集的制作和评价等现实世界内容，以确保现实世界内容和虚构内容成比例。持相反意见的编者（COI声明：包括我）则认为，制作与发行等信息应该写在主条目，放在剧集列表会与主条目重复，此外剧集列表是聚焦于虚构信息的条目，没有人会预期在名为“剧集列表”的条目里看到“制作”或“各集评论”的内容。

因此我将该问题提交至互助客栈，希望各位社群成员能提供更多的意见与共识。

根据EzrealChen君以及本人的整理，在英维，剧集列表可以大致分为以下几种：

• List of XXX episodes（=XXX剧集列表） - 这种剧集列表存在对应的电视剧的主条目，通常在只有一季的情况下使用。这类列表的写法通常是导言简要介绍作品，正文列明所有剧集，带有各集的剧情摘要。不会在首段以外介绍“制作”“制作人员”“各集评论”“所获奖项”等内容，这些内容是写在主条目。
  （示例：特色列表en:List of Hyouka episodes，除导言外不会列明大量制作与评价内容，这些内容都写在主条目en:Hyouka (TV series)）
• XXX (season Y)（=XXX (第Y季)） - 这种剧集列表是按季度划分，通常在作品有多季的情况下使用。这类列表的写法也是导言简要介绍作品，正文列明所有剧集，带有各集的剧情摘要，但是会带有该季度的“制作”、“评价”、“所获奖项”等内容。主条目只会写整个系列的制作与反响，各季度的制作与反响则是写在剧集列表里。
  （示例：特色列表en:Game of Thrones (season 1)，含有该季度的制作与评价等内容，主条目en:Game of Thrones则包括系列总体的制作与评价，不会深入到系列）
  • List of XXX episodes（=XXX剧集列表） - 这是在存在XXX (season Y) 这类条目的情况下创建的剧集列表。这类列表的写法是导言简要整个系列作品，正文中只会列明每季各集作品的标题等，不会含有剧情摘要。含有剧情摘要的详细内容在各个主条目，即XXX (season Y)。这样的实现方法是List of XXX episodes直接从XXX (season Y)嵌入内容，但不把剧情摘要嵌入（这是{{Episode list}}模板带有的功能）。
    （示例：特色列表en:List of The Good Place episodes，从en:The Good Place (season 1)、en:The Good Place (season 2)等页面嵌入，主列表不含剧情摘要，但各季的列表均含有剧情摘要）

在en:Wikipedia:Manual of Style/Television有详细的说明。本次引发争议的是第一种。

下方是对讨论可能有用的链接：

• en:Wikipedia:Manual of Style/Television#"List of ..." structure（英维的电视剧类条目格式手册）
• [9]或en:Category:FL-Class television articles（英维的特色列表级剧集列表）

本讨论已通知ACG专题、电子游戏专题、电视专题。--BlackShadowG Slava Ukraini! 2022年12月11日 (日) 03:47 (UTC)

這涉及一點原則問題，理想上維基百科裡的虛構內容目的就是為了現實內容打底，現實視覺已經不是質素的判別（你選的是FL呢）而是條目應有的基本要求。一般來說條目裡有整體角度看的現實內容，也應該有分集相關的現實內容，這種內容就好方便借虛構內容來打底，相配合來為讀者帶來有用資訊並給人好點的觀感。說的是嚴格點但實際上當然不預料100%虛構內容也是為了現實內容服務，但像你的條目的虛構內容完全沒有現實用途絕對不能接受。

現時你的條目可以說是因篇幅問題從主條目拆出的一個手段。雖然說是上方列出第一種，可你的條目的主條目與他們的有點根本的差別，在於上段說了也應該有的分集相關現實內容。以en:List of Hyouka episodes為例，誠然條目相關內容也不算多（可能是放在主條目的緣故），但編者還是有著意識寫進這種內容：

Hyouka features several real-life locations in Takayama. The Kamiyama Senior High School, which appears in the opening and each episode, is based on Hida Senior High School. The Kajibashi bridge, which goes across the Miyagawa river, is also featured in the opening and Episode 18. The Miyagawa Morning Market Street is also featured in the opening. The Arekusujinja Shirne, featured in Episode 20 and the opening, is based on the Hiejinja shrine. Other sites include the Yaoihashi Bridge shown in the opening and Episodes 11 and 18, the Hirayu Onsen Hot Springs shown in Episode 7, the Takayama City Library (as Kamiyama City Library) in Episode 18, and the Minashi Shrine and Garyu Cherry Trees shown in Episode 22.

其實這種有關分集的內容就剛好適合寫在劇集列表裡，不正能好好地對應同一條目裡上方的分集劇情，為什麼要寫在主條目裡？不如擺脫英維的既定做法，畢竟近年通過的英維ACG特表已經大大減低。如果不預期在名為「劇集列表」的條目裏看到「各集評論」的內容的話，那其實也不預期在名為「劇集列表」的條目裏看到「各集劇情」。這就是第二類別之下僅在劇集列表裡列明每季各集作品的標題的做法，然而拆出季度後的列表裡還是包括種種現實內容，這也是理想的列表條目方向。反對什麼‘劇集列表是聚焦於虛構資訊的條目’的說法，維基百科條目不是文學品，且本質上這條目本來就是因篇幅問題從主條目拆出的一個手段。--Iridium(IX) 2022年12月11日 (日) 04:18 (UTC)

en:List of Hyouka episodes找不到你说的这句话，你说的这句话正是在主条目en:Hyouka_(TV_series)#Production中的……且你提到的那句话是关于作品中的原型在哪集中登场，在主条目仍然是可以直接写入，或者说作品中地点的原型其实正是主条目的“制作”章节所需要的。虚构内容也是并非是为了现实内容服务，而是虚构内容和现实内容要兼收并蓄（WP:WAF），分集相关的虚构内容与之对应的同样也可以是关于系列总体的现实内容，这些内容是在主条目的。所以我说“劇集列表是聚焦於虛構資訊的條目”，同样的，我们也可以建立“XXX的制作”、“对XXX的评价”等聚焦于现实世界内容的条目，如果建立这种条目，也没必要要求这类条目的虚构内容也要成比例，因为它们就是聚焦于现实世界内容，剧集列表也同理。在剧集列表中加入直接与各个分集相关的现实内容应该是可选项，而不是必须项。

第二类别下的，“僅在劇集列表裡列明每季各集作品的標題的做法，然而拆出季度後的列表裡還是包括種種現實內容”，那样做的前提这些内容不会与主条目重复，因为主条目现实世界内容是关于整个系列，这样拆分出的季度的列表中就可以包括关于各个季度的详细的现实世界内容。但对于第一类条目，主条目的现实世界内容是关于整个系列，剧集列表中的内容也是整个系列的剧集，再在剧集列表中加入现实世界内容，就会与主条目重复。你上面提到的“分集相关的现实内容”也是如此，这些内容基本上都是主条目需要的内容，比如如果制作团队谈起作品的制作，提到作品的原型时经常也会提到在哪集登场，提到作品的制作过程也常会特别点名哪集的制作让人印象深刻等待；如果是评论家的评论，也可能会特别提到哪集最不错等等。这些内容也是关于整个作品的制作内容不可或缺的一部分，要是这些都塞到剧集列表去，主条目写什么呢。

另外说句题外话：“近年通過的英維ACG特表已經大大減低”这句话是虽然事实，但众所周知在西方比起ACG更受关注的是美剧等，大部分近年通过的都是这种列表（e.g.：en:List of HolbyBlue episodes），所以剧集列表类条目今年通过FL的频率并无降低趋势。--BlackShadowG Slava Ukraini! 2022年12月11日 (日) 05:14 (UTC)

你的理解能力依然堪憂，等待有沒有理解能力和思路好點的編者能表達下意見。此外‘條目應多着墨於開發、製作、意義等現實世界內容，之前的概述情節正是為給它們打底’（WP:PLOTONLY），別再什麼‘並非是為了現實內容服務，而是虛構內容和現實內容要兼收並蓄’，為現實內容服務和兼收並蓄沒衝突好不？‘現實世界的視角不是高質量條目的標準，而是對所有條目的基本要求。’，反正現時共識就是這樣。 --Iridium(IX) 2022年12月11日 (日) 05:36 (UTC)

實在是怕你看不見了。什麼‘要是這些都塞到劇集列表去，主條目寫什麼呢。’實在是不知所云

‘一般來說條目裏有整體角度看的現實內容，也應該有分集相關的現實內容’

‘其實這種有關分集的內容就剛好適合寫在劇集列表裏，不正能好好地對應同一條目裏上方的分集劇情，為什麼要寫在主條目裏？’--Iridium(IX) 2022年12月11日 (日) 05:38 (UTC)

那我也同样对你对CIV的遵守表示堪忧，并对你把提出不合你意的意见的编者称为“理解能力堪忧”表示遗憾。“現實世界的視角不是高質量條目的標準，而是對所有條目的基本要求。”，如果你有仔细看过这句话就能知道，这句话讲的是“现实世界视角”，现实世界视角是指把现实世界的事物和虚构事物区分开来，而不是塞进去一大堆制作过程才叫现实世界视角。（BTW，这句话当初是我翻译的，共识讨论我也是主要参与者之一，别当我什么都不知道）『一般來說條目裏有整體角度看的現實內容，也應該有分集相關的現實內容』『其實這種有關分集的內容就剛好適合寫在劇集列表裏，不正能好好地對應同一條目裏上方的分集劇情，為什麼要寫在主條目裏？』，如果你愿意耐心看完我说的话就能找到我上面有回应过，這些內容都是主條目需要的內容，“分集相關的現實內容”也是主条目中不可或缺的，不应将其放在剧集列表导致主条目的内容缺失。你上面摘了一大段英文的“分集相關的現實內容”全被英维写进主条目而非剧集列表就说明了这一点。--BlackShadowG Slava Ukraini! 2022年12月11日 (日) 06:55 (UTC)

‘「現實世界的視角不是高質量條目的標準，而是對所有條目的基本要求。」，如果你有仔細看過這句話就能知道，這句話講的是「現實世界視角」’，實在是很有道理，有道理到我也不知道該回應什麼了。其實是內容我就是說內容，是視角我就是說視角，提到現實世界視角意在你寫的對各集背景的塑造，現在也不必說了。

‘「分集相關的現實內容」也是主條目中不可或缺的。’這你有你說，我有我說，還是視乎最後公識吧。反正分集評價能放在分集劇情下方便讀者的事你不要，我不知道還能怎樣。反正‘但像你的條目的虛構內容完全沒有現實用途絕對不能接受。’--Iridium(IX) 2022年12月11日 (日) 08:13 (UTC)

‘en:List of Hyouka episodes找不到你說的這句話，你說的這句話正是在主條目en:Hyouka_(TV_series)#Production中的……’可不是麼，你又表演了你精彩的理解能力，總好過搞低級稻草人。我就覺得你需要個聰明人才能幫到你，像我這種傻子可不太適合--Iridium(IX) 2022年12月11日 (日) 08:18 (UTC)

希望多提些建設性意見，一直在咬文嚼字，無助於問題的解決。--Nostalgiacn（留言） 2022年12月11日 (日) 08:23 (UTC)

還在等待更多編者的意見來觀察初步或已有共識，現時難以再有補充，發發牢騷打擾了可抱歉--Iridium(IX) 2022年12月11日 (日) 08:30 (UTC)

不是方針的論述文章可能可以幫忙，建議藉此變成指引：維基百科:格式手冊/電視--唔好阻住我愛國（留言） 2022年12月11日 (日) 08:53 (UTC)

我去看了一下相關的格式文件，大概明白為何會有兩種觀點。中維和英維對劇集內容的標準是不一樣的，所以才有這種意見分歧。根據英維現行的相關標準，劇集列表也有一些現實內容要求，如編劇、導演、播放時間、收視率等，但是不包括評價、製作及發行等。

中維對應的指引尚未有共識，不過引述的「現實世界內容」觀點是近期通過的虛構內容指引的要求。英維的劇集列表本身就有很多前置的指引，支持這類型條目的出現，如列表的關注度問題（en:WP:LISTN），何時可以從主條目拆分出列表（WP:SIZE），相關的格式指引等等。而中維本地連劇集何時分拆出來都尚未有共識（WP:ACGN），列表的關注度也很迷（WP:虛構分割）。

具體到這次「魔女之旅劇集列表」的問題，本地沒有劇集的特色列表可以作橫向對比（WP:FL）。我翻看了英維的特色列表，發現劇集的特色列表有兩種類型，其中電視劇《Veronica Mars》十分典型適合舉例，一種是SIridiuM28提到的那種包括評價、製作（主要是演員方面）的內容en:Veronica Mars (season 2)、en:Veronica Mars (season 3)等，也有「魔女之旅劇集列表」這種類型的，沒有評價、製作的en:List of Veronica Mars episodes。

EzrealChen等人的觀點，認為評價、製作及發行的內容寫進去，劇集列表就越趨向成為一個動畫條目（即「魔女之旅劇集列表」》「魔女之旅 (電視動畫)」）。那麼實際上也有《Veronica Mars》的情況，那麼「魔女之旅 (電視動畫)」是否同時適用於GA和FL評選？--Nostalgiacn（留言） 2022年12月11日 (日) 08:13 (UTC)

英维的两种类型我在发起讨论串时的留言也提到了，其实就是各季度的剧集列表和总剧集列表的区别。

en:Veronica Mars (season 2)、en:Veronica Mars (season 3)是各个季度的剧集列表，所以可以写该季度的“制作”、“评价”、“所获奖项”等内容，这样写不会与其它的条目重复。en:List of Veronica Mars episodes是整个系列作品的剧集列表，列出的是所有季度的剧集，由于整个系列的“制作”、“评价”、“所获奖项”等内容是写在主条目en:Veronica Mars，因此剧集列表就没必要再把主条目的东西重复一遍。

现在来看魔女之旅剧集列表，这个作品是只有一季，有关该作品的制作的信息在主条目魔女之旅，如果我把该作品的制作和评价等信息在魔女之旅剧集列表再写一遍，无疑会与主条目重复。因此，这个剧集列表没有必要把制作和评价等信息再重复一遍。

即使我把《魔女之旅》的动画从整个系列拆出来，建立魔女之旅 (电视动画)，也没法让剧集列表的剧情概述一定能跟制作等内容在一个页面上。因为即使拆分出单独的动画条目，等动画条目发展成一定的长度，剧集列表还是得拆出来。例如en:Hyouka (TV series)这是个独立的动画条目，由于内容很充分（是篇GA），剧集列表en:List of Hyouka episodes还是给拆出来了，而且这篇列表还是篇FL，也不会写入详细的制作与评价等内容。--BlackShadowG Slava Ukraini! 2022年12月11日 (日) 11:22 (UTC)

你打算把nostalgia先前找到的分集評價寫進主條目裡？--Iridium(IX) 2022年12月11日 (日) 12:15 (UTC)

分集相关的现实内容如果与整个作品有很高的关联性，我会放在主条目。与整体关联不大的详细的分集评价放在各集的独立条目最好，要是一个剧集列表要把每集的制作和评价都塞进去，这样的长度足以拆成十几个独立条目。--BlackShadowG Slava Ukraini! 2022年12月11日 (日) 12:28 (UTC)

英維有「各季度的劇集列表和總劇集列表」的寫法，是基於他自己建構的標準和指引下。中維這類型條目的存在，現階段支撐的標準和指引不足，經常遭到愛好者內容等質疑，不論以前刪了一堆（WP:TVCONTENT），還是最近的妖幻三重奏漫畫章節列表提刪。現在「魔女之旅劇集列表」也遭到現實內容不足的質疑，也是同理的。

「魔女之旅劇集列表」現階段一個合理的質疑就是，為何不寫《魔女之旅 (電視動畫)》，而是直接寫《魔女之旅劇集列表》。妖幻三重奏的討論中我也提到，英維有拆分的標準，接著「熱門虛構作品的條目不斷膨脹，就會引致大量拆分。拆分的列表數量到了一定地步，又會引起討論達成格式指引的共識（何時能拆，怎樣拆，拆的格式等等）」。跳過了很多內容，直接對標英維的同類劇集列表的格式，有點WP:ENWPSAID。也許受到英維的內容先入為主，個人認為SIridiuM28先前的論點更多是對《魔女之旅 (電視動畫)》的要求，而不是《魔女之旅劇集列表》。寫這些內容應該是循序漸進，從主條目拆出劇集列表，主條目本身也應該有足夠的內容，否則不如合併回主條目，或者拆分的範圍擴大化（為何不寫《魔女之旅 (電視動畫)》）。

跳出《魔女之旅》這個個案，實際上劇集列表的內容在本地也有一定規模了（Category:電視節目各集列表）。也許又到了摸著石頭過河，追認國外先進標準的時候了（笑）。當然也可以選擇走另一條道路，增加比英維相關內容更多的要求。至於個人之前找到的分集評價，各集未被「拆分」之前，對於各集的評價也許應該屬於劇集列表之內。

PS：引用個人用戶名時請正確引用。--Nostalgiacn（留言） 2022年12月11日 (日) 13:46 (UTC)

想了一會還是有些東西想不透，這劇集列表說白了就是劇情列表，其他內容都已在主條目裡齊全。如果這些劇情部分沒有分裂出來的話倒好解決，畢竟原條目虛實比例頗為差劣，現實內容不齊全，虛構劇情內容不能達到‘概述情節正是為給它們打底’的作用，落選FA沒有懸念。這些劇情內容的存在本來就不能與主條目尤其是現實部分割裂。可現在獨立成為列表條目情況卻頗尷尬，總感覺有哪裡不適當而又說不出。

剛好在MOS:PLOT找到這句話：劇情簡介當以散文展示，不應淪為列表或時間線。

這句話無論在英維還是中維都非常的新。在英維是在2020年才被加入，看來並沒有受到注意。中維翻譯時該是照樣翻譯進來，想問一下社群多大程度上同意這一句話，不然的話就把它移除。

還是說這劇集列表裡的劇情並非劇情簡介，而是某種形式的詳細劇情演繹？然而原編又說自己寫的劇情已達到最大程度上的必要性和精簡。又似乎沒有方針提過這種內容的正當性及規範。這應如何詮釋？ Iridium(IX) 2022年12月11日 (日) 14:05 (UTC)

提供一个思路。每一集条目的介绍都应该像试播集 (我为喜剧狂)这样，包括该集的剧情、制作、评价。但是，许多作品单集剧情的现实部分写不到小作品以上的长度，不适合开设独立条目（参考Wikipedia:电子游戏条目指引#对待重制版）。这时就使用剧集列表，每一项都相当一个包括剧情、开发、评价的小条目。

剧情简介的列表或时间线是说这样。魔女之旅劇集列表这样的列表如上所言，相当于若干互相独立的小条目拼成的列表。而每个「小条目」内部使用的是散文。--洛普利寧 2022年12月12日 (一) 02:33 (UTC)

謝謝提出。你的意思是說現時魔女之旅劇集列表的情況是‘使用劇集列表，每一項都相當一個包括劇情、開發、評價的小條目。’，還是理想中魔女之旅劇集列表應該是‘使用劇集列表，每一項都相當一個包括劇情、開發、評價的小條目。’？ Iridium(IX) 2022年12月12日 (一) 09:07 (UTC)

現時魔女之旅劇集列表的情況是表格裡每一項都是純粹一段劇情‘簡介’，與那萌百的條目本質一樣，不過一個是時間線一個是列表 Iridium(IX) 2022年12月12日 (一) 09:09 (UTC)

我认为首先要明确的是，是否应该以集数为单位来介绍？以集数为单位介绍时，是否又能介绍只介绍剧情而不介绍其他方面？（打个不太恰当的比方：有人主张建立西游记回数列表罗列各回剧情，理由是主条目几段话的故事概要不足以帮助理解现实世界，比如连白骨精这样著名的角色都没有上下文。）

如果不允许以集数为单位来介绍，那可能只有把条目拆成各季条目，各季条目再写1,000字的剧情概要，达到使剧情介绍比较细致的效果。但是问题是日本电视动画该如何拆？按自然季/自然年拆，会碰到割裂剧情的情况。根据故事阶段按「XXX篇」拆，又可能有是原创研究。 耸肩

如果允许以集数为单位来介绍，我的想法（可能不成熟）是每集虚拟一篇条目（避免混入整季overview式的介绍），再把这些虚拟条目拼装为列表。至于是「每一集的劇情、開發、評價放一起」，还是「先分成劇情、開發、評價三个章节，每个章节下方分别罗列各集」，我没什么想法。当然具体效果怎样，我不写动画条目，没什么发言权。

如果以集数为单位介绍，且允许只介绍剧情，那列表的本质不可避免。比如：

第一集《魔女見習生伊蕾娜》于2020年10月2日首播。自小受“妮可的冒险谭”影响的蕾娜梦想环游世界，因此决定成为魔女……

第二集《魔法師之國》于10月9日首播。伊蕾娜来到了魔法使之国，在四处飞行时被另一个魔法使意外从扫帚上撞下……

…………

第十二集《所有一切平凡無奇的灰之魔女故事》于2020年12月18日首播。伊蕾娜来到一个声称能让愿望成真的国家……

这是十二段prose，完全没有套用表格语法。这一眼看去几乎就是条目，但本质上来说没有起承转合，还是一个（以现实世界视角而作的）列表。

--洛普利寧 2022年12月12日 (一) 10:39 (UTC)

使用剧集列表，每一项都相当一个包括剧情、开发、评价的小条目，看起来是一种比较理想的写法，但事实上对编者/读者而言，可行性/阅读收益可能没有想象的那么大。

首先需要说的是，每一集都能找到开发、评价等内容的作品可谓是少之又少，即使是新世纪福音战士这种在日本动画界前无古人后无来者的现象级作品，也很难保证每一集都能找到开发、评价等内容。很多作品，基本上开发和评价的资料都是针对整个系列作品，而不是针对各个剧集，即使有针对各集的内容，也基本上只是顺带一提，比如制作团队在访谈中特别提到哪一集制作很困难，评论家写review时格外赞扬了某一集等等（想想也能知道，制作团队在接受访谈时一般不会一集一集谈二十几集每集是怎么制作的，大部分主流媒体也不会给一部作品一集一集写二十几篇review）。对于大部分不突出，或者只是用作剧情过渡的剧集，基本没可能找到详细的开发和评价的内容，更别提能将其与剧情摘要能写到一定的比例。

在此之中还会衍生出一个问题，不少对于单集的简短的评论，事实上还是依附于整个作品，这些内容比起写在剧集列表，在主条目也是不可或缺的内容。比如说哪一集制作很困难，也是整个作品的制作过程中不可或缺的需要说明的一环；比如哪一集被评论家格外赞扬，这是也整个作品的评价中需要格外说明的一点。这些在主条目需要写的东西，在剧集列表再写一遍，会导致重复。

此外，如果真的有几集开发和制作的内容都很齐全，通常情况下可以创建独立的剧集条目（比如我早前翻译的GA使徒来袭）。独立的剧集条目中所涵盖的内容就是剧集的剧情、开发、评价，在剧集列表中也详细写剧集的剧情、开发、评价，会导致与独立剧集条目的重复，这样剧集列表就很难起到概述的作用。

同时，对阅读剧集列表条目的读者，看到各集的制作和评价的内容真的是有益的吗？也许是未必。如果读者想要阅读的是某个倍受关注的剧集的详细的制作与评价，那他可以去看独立的剧集条目。如果读者想要看的是整个作品中被特别“点名”的剧集，那主条目会有说明。但在读者做出这样的举动去阅读现实世界内容前，其前提就是，读者必须要先了解各集的剧集摘要，这就是剧集列表的作用。不了解虚构作品或事物的故事背景，领会现实世界信息就难以谈起（WP:WAF）。--BlackShadowG Slava Ukraini! 2022年12月12日 (一) 13:34 (UTC)

如果真有人說什麼有需要詳寫虛構細節相關的虛構內容以為虛構細節的現實內容打底，那通常這些虛構細節如人物之類有足夠關注度的話，倒可直接獨立成條，也自然能直接在獨立條目裡撥些字數寫寫為現實內容打底的虛構內容，就如你現在的白骨精一樣，但這條目空有一段虛構內容支持而沒有進一步用來支持現實內容，也實在是個混帳。因此如你所說，的確不太恰當。現時寫劇集列表的作用應該為直接以分集虛構內容打底各分集的現實相關內容。這樣與劇集分集的本身主題也頗為相關，因此直接把分集相關評價寫在劇集列表裡面並不礙事。

倒沒想過有人會以自然年拆，自然季的話，其實以集数分割劇情總比以自然季分割更破壞劇情脈絡。我也鮮寫動畫條目，不該有什麼發言權。不過以前曾經寫過一次動畫條目，質素不意外非常差劣，可是這動畫也有點混帳，主線不依時間順序，本來打算依分集寫劇情，最後還是要拆開重組以散文形式來寫。基本上來說複雜點的作品都不應以列表來寫。‘如果故事結構本身是非線性或實驗性的，條目就應以文段陳述這一事實，而非按故事結構本身複述。’我想那個用戶寫進‘劇情簡介當以散文展示，不應淪為列表或時間線。’也不以形式為最終目標，形式背後還是有些目的的。因此什麼‘一眼看去幾乎就是條目，本質還是列表’的東西也沒有意思。我個人覺得複雜的劇情本身就不應該以列表來寫，簡單的尤其是單元劇或許列表還是可以，那焦點就更放在現實部分之上。我也暫不考慮‘不應淪為列表’與散文本身更為優越的精簡性有沒有關係。（打的有點倉促，比較粗疏的話實在抱歉）

剛看到上面一些極端化的論點，好像評價不是特別詳細備受關注需要寫進獨立條目的就是有關被特別「點名」的劇集需要寫進主條目。多說無益，我想看看你那魔女條目來試刀，先寫進先前找到的評價內容再看看吧

--Iridium(IX) 2022年12月12日 (一) 14:03 (UTC)

關於散文的問題，更詳細的指引頁面在WP:PROSE，指引也說明「僅當列表展示效果勝過散文時，才考慮使用列表」。劇集列表的表現形式在中維尚未有的格式指引，但是英維已經在實踐中確立使用模板{{Episode list}}處理相關內容（FL條目的樣式）。{{Episode list}}的可讀性是足夠了，當然也具備所有表格的痛點，在手機瀏覽效果不佳（也許可以留待技術層面解決）。--Nostalgiacn（留言） 2022年12月13日 (二) 06:44 (UTC)

這討論好像也冷了，不知道是社群對相關標準劃定不感興趣，對所提及的問題無感還是怎樣。私心重提原先的FL評選，姑勿論條目的形式，或是現實內容放在主條目還是列表條目裡，你至少也先寫了相關連的現實內容才說吧（即便是放在主條目裡），現時12段劇情放在那也不知道要幹嘛，給些誠意才再參選吧--Iridium(IX) 2022年12月16日 (五) 16:00 (UTC)

BlackShadowG某種意義上已經在處理相關現實內容，目前動畫第一集《见习魔女伊蕾娜》獨立成條目，參與GA評選中。相信現實內容的處理還需要一段時間。--Nostalgiacn（留言） 2022年12月16日 (五) 16:25 (UTC)

注意到了，謝謝--Iridium(IX) 2022年12月17日 (六) 02:58 (UTC)

具體操作或建議

《见习魔女伊蕾娜》的評選已經告一段落，評選期間提到一個具體的問題，可以作為接下來討論的切入點。附上建議歡迎補充。

(？)疑問：劇情的邊幅應該多少才合適？

(＆)建議：最簡單的方式就是字數限制，論述WP:PLOTSUM也匯總了部分英維的字數建議。字數限制只作為一般建議，在評選中也有提到，劇情的邊幅和現實內容只要比例合理即可。

ACG专题建议“300～800字的2至4個段落，不超過1000字”；英語版小說格式指引建議「應該收斂在3或4個段落內」^{校：現在是400到700字}；電影格式指引建議在400至700之間；電視劇格式手冊建議每集故事100至200字，複雜的情節最多350字，獨立單集條目為200至500字^{校：現在是400字}。

WP:PLOTSUMMARIZE

《见习魔女伊蕾娜》是單集條目，這類型條目的編寫方式已經很清晰了，也就劇情邊幅有些爭議。若回到劇集列表的編寫，分歧就很多，我只能說很多前置的內容缺乏共識，直接問「英維那種寫法行不行」實在太籠統，不切中每個關鍵節點，這個討論大概會無疾而終，如果能就其中一兩個節點達成共識，也可以減少日後同類內容的爭議。最後也許真的需要一些思考工具或者計劃工具去梳理和提出問題了（笑）附上建議歡迎補充。

(？)疑問：什麼時候應該拆分出劇集列表？

(＆)建議：具體到劇集，本地相關內容無共識（WP:ACGN）。可以參考相關方針對獨立列表的要求，魔女之旅剧集列表是符合的，由於參選FL，也可以看看特色列表標準提到的WP:LSC和WP:CFORK（僅為舊版本英維指引翻譯，建議看英文版）。

列表不應僅單純地列出各項名稱，而應提供各項名称簡介或各項之間可比較的信息等其他資訊，即該列表不應該可簡單的由分類取代。

WP:LISTD

(？)疑問：劇集列表是否有推薦格式？

(＆)建議：一如上文，主體使用{{Episode list}}，這個模板的可讀性足夠，也支持很多樣式。下文提到是否需要列出「不知名人物」觀點其實WP:LSC也有提到，要視乎關注度和可靠來源的報道。獨立列表很多內容尚未有共識，單純以劇集的內容性質來說，格式手冊關於虛構的部分也會約束到列表內容的編寫。關於劇集列表的評價內容，參考en:Veronica Mars的情況，如第三季條目的評價在主體條目也有用到，只是引述同類來源時描述有更改。題外話：留意到季度條目有些是評FA而不是FL，英維「列表」定義也有些混亂。

(～)補充：上文提到的MOS:PLOT的觀點，由於是也是翻譯自英維，中維缺乏其他配套，所以使用到列表時有些格格不入。如果對比英維其他格式指引，會發現MOS:PLOT的場景是一個作品條目的劇情分節的編寫建議，而當條目為一個獨立列表時，格式和表達方式就改變了，如列表常見格式就包括：年表（各國年表/虛構年表）、時間線（星際爭霸戰時間線）、詞彙表（電子遊戲術語列表）等等。

--Nostalgiacn（留言） 2022年12月23日 (五) 10:55 (UTC)

劇情篇幅本身就要視情況而定。虛實比例對於篇幅的重要性經過多番強調後已在《見習魔女伊蕾娜》中得以體現。可是有另外一個比較隱晦的原則，就是虛構劇情本身的篇幅與其對現實內容的作用在比例上需不需要成對比的問題。在論述裡面有提過概述情節應為虛實比例打底，在我自己的角度虛構內容之所以被收錄自然是為現實說明部分內容提供依據，因此劇情寫得越多，便應有越多部分是有其作用。如果某主題的劇情本身缺乏二手來源從現實角度加以針對介紹/分析/解讀，那劇情篇幅反過來說便應因應需要有所壓縮。然而在此次魔女之旅劇集列表評選裡，即便算上主條目裡的現實內容，列表裡的全部劇情基本上都沒有為任何現實內容打底的作用。然而社群還是投下了6個支持票，我想了解社群在多大程度上重視這個原則。是不是即便一個條目的劇情完全沒有作用也能接受甚至推廣？在我眼中強調虛構劇情現實作用的重要性在於：

1.條目對廣泛讀者的時間效用，維基百科的廣泛讀者為何需要一大段沒有說明作用的虛構細節？

2.為虛實比例帶來真正的意義，如果條目裡寫一大段虛構設定後再寫一大段無關的現實內容，那麼強調這些虛構設定與無關的現實內容之間的比例究竟有多大意義？

3.保證劇情內容本身的可供查證性，現實方面的二手來源針對相關虛構劇情的引用展述本身就是對其可供查證性的保證。一段劇情越是沒有現實目的，便在越大空間上由條目編者本身主觀想法所塑造。因此我覺得魔女之旅劇集列表的主體內容本身合不合可供查證的要求也是頗為曖昧。

在魔女之旅劇集列表的案例上‘何時有需要分拆劇集列表’不過是一個偽命題。這作品所有的劇集資訊根本一直完好無缺地存在於主條目裡，唯一一個沒寫在主條目裡，只寫在列表裡的劇集內容就是劇情部分，因此真正的問題應該是‘何時有需要分拆（分集）劇情列表’。而這問題的答案也自然明顯。這終究還是視乎編者決定寫出什麼樣的東西。魔女之旅劇集列表這條目本身就是一個詭異的存在，你要編者添加一些二手來源與主體劇情相關的內容，他回應你沒有必要，這條目本身就是‘為了補充虛構情節內容’，然而這些劇情項目空有虛構內容沒有二手來源，又何來證明這些項目的關注度？是不是放個『週間番組表』一手來源就證明了這些項目的關注度？不該是這樣的吧？真要是向編者施壓，他又說就是要把現實內容放在主條目裡，那麼在評選裡評個列表條目的各個方面究竟應不應該把主條目的內容也一併考慮？這次倒好是一個比較熱門（已知來源較多）的作品沒人多注意關注度，這種寫法產生的內容究竟與寫一個缺乏關注度缺乏有效能用以拓展內容的條目有什麼分別？關注度並不能繼承，不是說你在內容摘要裡面摘要主條目的來源也一併證實了各分集的關注度吧。--Iridium(IX) 2022年12月26日 (一) 09:40 (UTC)

@Nostalgiacn： 知會回覆對象 Iridium(IX) 2022年12月26日 (一) 09:41 (UTC)

對於虛實比例的疑問，核心還是這種列表類型的接受程度，幾個月前有個一個相近的討論，是關於漫畫章節列表的，可以看看當時的討論。引述我當時的發言「至於WP:NOTIINFO的議題，這要麼是理解WP:NOT的方向錯了，要麼就是維基百科的定位已經脫離的實際需求」「某年某月的記事可以說是沿襲「年鉴」的功能，那麼章節標題是否也可以說是沿襲「目錄學」的功能，有存在的需求和合理性」

分拆不是偽命題，你的疑問本身在WP:LISTD哪裡已經有答案，是否合併到同源條目，或者刪除列表此前已經有「共識」。核心就是篇幅大小，遺憾的是，雖然因為篇幅拆分是「共識」，但是拆分的指引WP:SIZE一直沒有共識。這才是讓人迷惑和容易產生爭議的地方，你對始作俑者的顧慮，如果有達成共識的指引去設置精簡並刪除同源條目不必要內容的前提，再以列表中內容決定拆分標準就可以解決。這些都是個人認為接下來關鍵節點，同時這些都是目前沒有共識的特色列表標準要求。

列表若有「同源條目」，可先考慮「篇幅容許」的情況下，置於同源條目中而不單獨成條。「同源條目」即“XX”和“XX列表”之關係。

WP:LISTD

 吐槽：難以理解，一直以來中維都是在，部分評選標準的相關指引不是共識的情況下選拔「特色列表」。也許這就是所謂的「舒適區」吧。--Nostalgiacn（留言） 2022年12月27日 (二) 06:48 (UTC)

你真的看清楚我說的東西吧，兩段說的都不是我兩段說的東西--Iridium(IX) 2022年12月27日 (二) 11:31 (UTC)

一來我都已經說了我的重點現在不放在虛實比例上，而來我不是說分拆是一個偽命題，你真的讀清楚吧。--Iridium(IX) 2022年12月27日 (二) 11:35 (UTC)

也可以你先寫清楚，太多反問句和疑問句，可能會妨礙你的觀點的表達。--Nostalgiacn（留言） 2022年12月28日 (三) 03:42 (UTC)

開首第二句就已經寫了關注點。。。--Iridium(IX) 2022年12月28日 (三) 06:02 (UTC)

影視節目集數列表種類

現時維基百科影視節目集數列表有不同的種類

1.

話數	標題	分鏡	演出	動作監督	導演	監製	首播日期
1	維基百科人 （editor in wiki）	小明	小明	小明	小明	小明	2022年12月11日 (2022-12-11)
2022年12月，U:BlackShadowG發起這個討論。有编者认为剧集列表需要包含与剧情摘要成比例的制作与发行等信息，也就是每集除了剧情摘要，还需要加入每集的制作和评价等现实世界内容，以确保现实世界内容和虚构内容成比例。持相反意见的编者则认为，制作与发行等信息应该写在主条目，放在剧集列表会与主条目重复，此外剧集列表是聚焦于虚构信息的条目，没有人会预期在名为“剧集列表”的条目里看到“制作”或“各集评论”的内容。

2.

集數	標題	上線日期
1	維基百科人	2022年12月11日 (2022-12-11)
2022年12月，U:BlackShadowG發起這個討論。有编者认为剧集列表需要包含与剧情摘要成比例的制作与发行等信息，也就是每集除了剧情摘要，还需要加入每集的制作和评价等现实世界内容，以确保现实世界内容和虚构内容成比例。持相反意见的编者则认为，制作与发行等信息应该写在主条目，放在剧集列表会与主条目重复，此外剧集列表是聚焦于虚构信息的条目，没有人会预期在名为“剧集列表”的条目里看到“制作”或“各集评论”的内容。

3.

集數	原文標題	中文標題	編劇	分鏡	演出	動作監督	導演	首播日期
1	editor in wiki	維基百科人	小明	小明	小明	小明	小明	2022年 12月11日

4.

集數	播出日期	標題	導演	收視率
第1話	10月10日	維基百科人	小明	100%

5.

集數	標題	播出日期
第1話	維基百科人	10月10日

参考資料

--唔好阻住我愛國（留言） 2022年12月11日 (日) 04:17 (UTC)

5種方式，是時候制定一個富維基方式的標準列表。--唔好阻住我愛國（留言） 2022年12月11日 (日) 04:30 (UTC)

要讓寶可夢列表那種維基人沒有多少按照劇情原創輸出的空間的純虛構列表上特色列表可能要簡單許多。--🎋🍣 2022年12月11日 (日) 04:46 (UTC)

似乎我发起这个讨论串主要想讨论的不是这些……--BlackShadowG Slava Ukraini! 2022年12月11日 (日) 05:16 (UTC)

其实比较想说3。很多读者是没有看过动画的，条目提供这种分鏡、演出这种深入的的东西，都不愿意介绍更基础的剧情……--洛普利寧 2022年12月12日 (一) 02:44 (UTC)

分镜、动作监督、导演等人员单列，需有足够关注度和各集差异，如果各集基本一样或者多为不知名人物（无条目）则不如不写。“收视率”其实也是，如果没有“真实关注”，我不建议收录。剧情简介有自然是好的，质量差就算了。5算是基础版。--YFdyh000（留言） 2022年12月12日 (一) 04:01 (UTC)

換句話說，2及5是最低要求，「分鏡演出動作監督導演監製收視率」的每一個項目至少要有條目記錄相關人士、必須是由第三方發佈及有關注度方能出現？--唔好阻住我愛國（留言） 2022年12月12日 (一) 04:28 (UTC)

是。不是硬要求，但如果要“标准化”，应该避免仅基于一手来源写上不知名人物，那样就沦为资料库了。--YFdyh000（留言） 2022年12月12日 (一) 04:32 (UTC)

個人認為最好是1，不過目前中文維基活躍用戶容不下豐富資料，將“愛好者內容”不斷放大的時候，恐怕非常難做到。--Wpcpey（留言） 2022年12月12日 (一) 04:56 (UTC)

其实剧集列表没有那么多种格式，现在最为标准的方式就是用{{Episode list}}，用这个模板可以让源代码可读性强，且格式统一。

3-5是用的纯手工输入的表格，用{{Episode list}}代替即可。2其实也是用{{Episode list}}，只是各集的制作人员没有写全。--BlackShadowG Slava Ukraini! 2022年12月12日 (一) 12:13 (UTC)

相關列表是我從各影視節目條目抄下來的，沒有一個使用模版。--唔好阻住我愛國（留言） 2022年12月12日 (一) 14:28 (UTC)

格式指引

說到底，畢竟這還是格式指引的問題。咱們中文區這裡現時雖然已有電視方面的格式手冊頁，但這終究仍未完善（尤其是「XX列表」的架構指引）。就著這方面而論，小弟已參考英維，對該頁面增補了缺失的標題（雖然不少仍未有內容）—簡單而言，討論的地方有：

1. 既有主條目、各季節目和單一劇集節目架構的增補；
2. 角色條目架構；以及
3. 「XX列表」架構。

當中後兩者為現時中文區尚未引入之格式指引。

另外，鑒於英文區和中文區之間的那些微妙差異，字數等方面的要求亦需大家討論修訂，方能成事。這樣，我們豈不能夠建立更多與電視相關的條目囉？—飄流書生（見山 · 客棧 · DC20） 2022年12月24日 (六) 07:07 (UTC)

ACG专题建议“300～800字的2至4個段落，不超過1000字”；英語版小說格式指引建議「應該收斂在3或4個段落內」^{校：現在是400到700字}；電影格式指引建議在400至700之間；電視劇格式手冊建議每集故事100至200字，複雜的情節最多350字，獨立單集條目為200至500字^{校：現在是400字}。

WP:PLOTSUMMARIZE

個人建議中維的字數限制可建基於此，但必須把姓名及地點排除，免得出現翻譯問題。--唔好阻住我愛國（留言） 2022年12月25日 (日) 02:39 (UTC)

反对加之以严格的字数限制，剧情的长度只要与条目其它现实世界内容的比重合理即可。就如在GAC中提到这篇条目，条目若长达上万字，剧情占3000多字也不会导致比重失衡。--BlackShadowG Slava Ukraini! 2022年12月26日 (一) 02:16 (UTC)

如果不設字數限制的話，可能會出現侵犯版權的問題，個人是比較關注這一點。--唔好阻住我愛國（留言） 2022年12月26日 (一) 03:44 (UTC)

正確，案例。--路西法人 2022年12月26日 (一) 04:17 (UTC)

剧情的长度与侵犯著作权并无直接的联系，只要剧情是转述而非搬运/翻译自官方文案，应该便不会出现侵犯著作权的问题。见Wikipedia:格式手册/虚构#著作權“例如对于作品剧情，编者应当参考来源转述，切不可直接搬运/翻译官方文案（涉嫌侵权且常有文风问题）。”，“一些法庭案件认为，作品复述虚构类原创构思达到一定程度的，如果没有添加关于该作品的信息，或没有做出一定的分析和解释，就会按衍生作品或侵犯著作权论处”，显然维基百科上会对剧情做出分析和解释，也会添加关于该作品的信息。--BlackShadowG Slava Ukraini! 2022年12月26日 (一) 05:44 (UTC)

閣下複製少了「最低限度使用」，設立新格式手冊的項目必須要「可量化的」，否則與沒有設立無異。--唔好阻住我愛國（留言） 2022年12月26日 (一) 11:55 (UTC)

受著作权保护的文字才需要“最低限度使用”。如果是用自己的话转述应该可以规避这类问题。--BlackShadowG Slava Ukraini! 2022年12月26日 (一) 12:06 (UTC)

答案是不可以，以時事類條目為例，現時不成文做法是每一篇報道最多節錄兩句，以避免抄襲的問題。在學術界而言，如果只是改詞換字而不經整合，也屬於抄襲。--唔好阻住我愛國（留言） 2022年12月26日 (一) 13:33 (UTC)

本串討論的是版權問題，不是抄襲。版權保護思想的表達，不保護思想本身，「用自己的話轉述」沒有版權問題（除上述衍生作品「非轉化性使用」議題外；當然假如改寫不足構成en:Close paraphrase則仍屬侵權）。至於抄襲，學術上用自己的話轉述已有文獻但沒有標明出處也屬抄襲，但並非版權問題，而是學術倫理問題；另衹要標明出處就沒有抄襲問題，相反即使標明出處假如大量直接引用仍可能有版權問題。——$\color [rgb]{0.04,0,0.5}{\mathsf {htc_{23}}}$（留言） 2022年12月26日 (一) 22:53 (UTC) 更正

影視節目內容如何標示來源？以目前WP:外部連結規定，根本無法針對影視節目使用{{{cite video}}}。

雖然WP:抄襲現階段不是方針或指引，但如果成文化的話，魔女之旅第一集肯定會下ga榜。--唔好阻住我愛國（留言） 2022年12月26日 (一) 17:00 (UTC)

劇情簡介可以引用節目本身（MOS:IPLOT：「虛構作品自身即充當條目第一手來源，編者概述劇情時不引用外部來源亦可。」），若有需要列明可用{{cite episode}}等，另見WP:PLOTSUM#引用。不太理解WP:外部連結如何妨礙使用{{cite video}}。（WP:ELPOINTS指明「本指引不適用於來源和參考」，且{{cite episode}}或{{cite video}}並非必須給出url，可以引用線下影碟等。）——$\color [rgb]{0.04,0,0.5}{\mathsf {htc_{23}}}$（留言） 2022年12月26日 (一) 21:54 (UTC)

算啦！說抄襲的話有點兒離題。

說回著作權的問題，不是每一個編輯者有如@BlackShadowG寫魔女之旅一樣有自制能力。換一個例子，I SWIM有不少WP問題，特別是著作權問題，應該寫怎樣的格式手冊解決相關問題？--唔好阻住我愛國（留言） 2022年12月27日 (二) 01:53 (UTC)

是指I_SWIM#每集列表这一段？从其它来源拷贝而侵犯著作权的直接根据WP:COPYVIO处理即可，不需要在格式手册再提一遍。--BlackShadowG Slava Ukraini! 2022年12月27日 (二) 02:04 (UTC)

當然不止每集列表，難道閣下看不到有很多跑龍套的演員被列入條目？--唔好阻住我愛國（留言） 2022年12月27日 (二) 02:12 (UTC)

阁下上面不是说要讨论著作权问题吗，怎么又话锋一转跑到这来了……这种内容可以根据en:Wikipedia:Manual_of_Style/Television#Cast_and_characters_information处理。--BlackShadowG Slava Ukraini! 2022年12月27日 (二) 04:15 (UTC)

英維給出的轉述仍侵權的例子是en:WP:PLOTCOPYRIGHT，如此細節的描述加上"no transformative function"，相比之下「比重不失衡」的條目應該無需擔心此危險。——$\color [rgb]{0.04,0,0.5}{\mathsf {htc_{23}}}$（留言） 2022年12月26日 (一) 22:18 (UTC)

主條目、各季節目與單一劇集節目條目架構 由於討論範圍甚廣，故先由上述之第1點開始討論。 資訊框 要注意的是，電視類條目不僅限於節目主體，亦包含以下兩種變體：

• 各季節目條目；以及
• 個別集數條目（individual episode article）。

故此，此章節需予以修改，如下：

現行條文 主页面：Template:电视节目信息框 下為電視節目資訊框的模板。在編寫電視劇條目時，將以下程式碼複製使用，並填上相關參數，其中許多參數並不是每個條目都用得上。若演出名單過長，則應改用一個演員章節來收錄。模板的詳細說明與範例，以及討論可以至該模板頁了解。此外還有一些相關的模板如Template:Infobox television season、Template:Infobox reality music competition、Template:Infobox television episode

提議條文 以下為三個於專題裡所使用的主要模板，並附設代碼供編者複製使用： 用於主條目的{{电视节目信息框}}； 用於各季節目條目的{{infobox television season}}；及 用於各集節目條目的{{infobox television episode}}。 若對使用這些模板有任何問題或疑難，請參閱各模板的文件，又或於對應的討論頁發起討論。並非所有參數俱可用於任何條目中，皆因部份參數對於不少電視條目而言毫無關係。 若個別欄位（如starring參數）需要填寫多於一項參數，應使用{{plainlist}}或{{unbulleted list}}模板，而非<br />。此外，若單一欄位內容過於冗長，編者可利用內部連結，引導讀者前往條目內的對應章節—以starring為例，編者應將參數指向至「演員」、「角色」或「演員及角色」一節。

圖像 參考英維，建立以下內容：（已省略上載後事項）

視乎條目的類型，資訊框內應基於非自由內容使用準則，使用不同的圖像：

• 就節目的主條目而言，可使用能代表該節目的標題畫面（如顯示節目標題的截圖）或宣傳海報。若不能，則可使用家庭媒體封面。
• 就季度條目而言，應使用特定季度的宣傳海報、家庭媒體封面，又或特定季度的標題卡（如適用）。
• 個別集數條目甚少會有資訊框圖像，但若存在宣傳海報或圖像，則可使用。其他選項包括特定集數的標題卡、家庭媒體封面（若該集另有獨立發行），又或該集具重要性的情節/元素之截圖。最後者只能在符合非自由內容使用準則下方能使用—換言之，

(typically) it is required to illustrate the object of explicit, sourced analytical commentary, and where that commentary is in need of a visual support to be understood

（上述內容還待有心人翻譯）。

資訊框以外的其他圖像亦須符合非自由內容使用準則（即如上方所述），並在可行時應儘量使用自由圖像。自由圖像可從维基共享资源中取用。

其餘章節 還望有心人翻譯至格式手冊中了。

歡迎討論。—飄流書生（見山 · 客棧 · DC20） 2022年12月26日 (一) 11:11 (UTC)

其實為什麼要由英維翻譯至中維？如果100％翻譯，會出現水土不服的狀況。--唔好阻住我愛國（留言） 2022年12月26日 (一) 11:52 (UTC)

本地沒人提出解決方案，只能參照國外先進標準（笑）。可以先翻譯再逐章討論，進行本地化。--Nostalgiacn（留言） 2022年12月27日 (二) 06:49 (UTC)

上方提及的英維方針及指引，看看如何中維化。

1.en:Wikipedia:Manual_of_Style/Television#Cast_and_characters_information

2.en:WP:PLOTCOPYRIGHT

3.en:WP:PLOTSUMMARIZE

4.en:WP:LISTN

5.en:Wikipedia:Manual of Style/Television--唔好阻住我愛國（留言） 2022年12月27日 (二) 11:03 (UTC)

順帶一提，維基係跟美國佛羅里達州法律。相關著作權問題，以美國法律作準。--唔好阻住我愛國（留言） 2022年12月27日 (二) 11:07 (UTC)

快速删除分类

鄙人在做梦的时候想到了一个主意，就是在挂完提删模板后除Cat:快速删除候选以外是否可以再加一个提删原因分类让管理员的工作更轻松些。-- B-MIKE -留|签 2022年12月13日 (二) 20:31 (UTC)

例：R7这种一眼就能看出来该不该删的重定向就可以先加一个分类，这样可以让这些不需要什么时间去辨别的提删页面可以被“优先”删除而不是等1-2天后才被删。-- B-MIKE -留|签 2022年12月13日 (二) 20:36 (UTC)

我觉得这个提议很好。可以效仿英维那种分类，但英维的分类方法过于繁琐，过多的分类反而不利于维护工作。我提议的分类方法为：

• Category:快速删除候选/所有页面（G）
• Category:快速删除候选/条目（A）
• Category:快速删除候选/重定向页（R）
• Category:快速删除候选/文件（F）
• Category:快速删除候选/其他页面（O）

对于具体的快速删除理由，可以单字标签，例如G15可以使用“⑮”字标签。--12З4567（留言） 2022年12月14日 (三) 05:43 (UTC)

我個人認為這種辦法是可行的。只是不知道技術上之難度。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年12月14日 (三) 12:41 (UTC)

新建分类然后套用到快速删除模板上。-- B-MIKE -留|签 2022年12月14日 (三) 14:05 (UTC)

使用單字標籤的話就不需要新建分類了。效果等同於[[Category:快速删除候选|⑮]]。個人(＋)支持此方案，較新建分類簡便。（當前只有分「議」、「速」兩種標籤）-Peacearth（留言） 2022年12月24日 (六) 05:10 (UTC)

題外話+玩笑話：做夢夢到維基是維基中毒了，多休息。--路西法人 2022年12月14日 (三) 14:48 (UTC)

User:Xiplus/js/csd-reason-in-csd-cat.js可以起到類似的作用，在Cat:CSD顯示提刪理由。——$\color [rgb]{0.04,0,0.5}{\mathsf {htc_{23}}}$（留言） 2022年12月14日 (三) 15:17 (UTC)

提议删去延伸确认保护中要求先半保护的限制

在LTA:X43中，因已经可以直接确认半保护无效，管理员直接采用了延伸确认保护，引发了一定争议，但在本事件中管理员行为并无过错，是依照常识的正确判断，且有效的阻止了破坏，因此当方针与正确的行为相悖的情况下，我认为如果要使管理员的行事更合规，应对WP:ECP进行类似于如下的修改：

現行條文 管理员仅能在页面已被半保护，且证实半保护仍无法阻止破坏或编辑战的页面上使用延伸确认保护。与半保护相同，不得对尚未发生的破坏或编辑战进行预见性保护，亦不得将延伸确认保护使用于破坏或编辑战以外的页面上，应直接使用全保护（对于模板或模块可用模板保护）。

提議條文 管理员在执行延伸确认保护时破坏情况应比要执行半保护时相对严重，且不得对尚未发生的破坏或编辑战进行预见性保护，亦不得将延伸确认保护使用于破坏或编辑战以外的页面上，应直接使用全保护（对于模板或模块可用模板保护）。

鄙人拙见，只是抛砖引玉，可能还需要更好的措辞。 -- Xi_Ying • Talk 2022年12月24日 (六) 02:58 (UTC)

• 相關討論Wikipedia:互助客栈/其他#對管理員執行延伸保護的提醒-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2022年12月24日 (六) 03:01 (UTC)
• (＋)支持：現行條文之相關限制毫無必要。就如同全保護也沒有這類的限制，本就應視情況而定。保護是為了避免繼續被破壞或編輯戰，而不是為了保護而保護。-Peacearth（留言） 2022年12月24日 (六) 03:57 (UTC)

(＋)支持提案本質但語句不通順，建議條文：

管理員僅能在頁面已被半保護，且證實半保護仍無法阻止可在被未達延伸確認狀態的自動確認用戶持續破壞或編輯戰的頁面上使用延伸確認保護。與半保護相同，不得對尚未發生的破壞或編輯戰進行預見性保護，亦不得將延伸確認保護使用於破壞或編輯戰以外的頁面上，應直接使用全保護；於模板或模組可使用模板保護。

除了持續出沒的破壞者外，自動確認用戶作出的破壞和編輯戰不見得必定比非自確嚴重。--路西法人 2022年12月24日 (六) 04:02 (UTC)

• (＋)滋磁我觉得可以的。-- Xi_Ying • Talk 2022年12月24日 (六) 05:51 (UTC)

  其實對相關編輯者實行「回退零忍耐」不是更好？免得因為一小部份的編輯爭議而連累其他編輯者無法編輯。--唔好阻住我愛國（留言） 2022年12月25日 (日) 02:44 (UTC)

  離題，不是本次討論的重點。--路西法人 2022年12月25日 (日) 03:47 (UTC)

(＋)支持路西法人的版本，英維另外寫了一頁輔助說明頁來補充，或許可以拿過來用。--冥王歐西里斯（留言） 2022年12月26日 (一) 01:42 (UTC)

我們沒有ArbCom沒用啊……--路西法人 2022年12月28日 (三) 03:12 (UTC)

還是覺得路西法君提案可以再修改一下，「未達延伸確認狀態的自動確認用戶」很像有點累贅。會不會「非延伸確認用戶」就已經足夠呢？--J.Wong 2022年12月26日 (一) 03:33 (UTC)

感謝J.Wong君提問。我有考量過這點，「非延伸確認用戶」包含連自動確認都不到的用戶，僅由非自確用戶作出的破壞或編輯戰顯然不適用延伸確認保護，故只能釐清為「未達延伸確認狀態的自動確認用戶」。--路西法人 2022年12月26日 (一) 04:11 (UTC)

（还有个小bug，延伸确认实装时已成为管理员的用户是没有延确flag的，所以「非延确」或「未延确的自确」也包括一部分管理员 ——魔琴 [ 留言 贡献 新手2023计划 ] 2022年12月28日 (三) 06:05 (UTC)

管理員破壞或編輯戰就完全是另一回事了（（（--路西法人 2022年12月29日 (四) 07:29 (UTC)

@LuciferianThomas：(！)意見:可考慮定爲“管理员可在自动确认用户持续破坏或编辑战的页面上使用延伸确认保护。”如此優雅、潔煉之文段，豈不美哉。——WMLO（留言） 2022年12月28日 (三) 23:01 (UTC)

邏輯錯誤，延伸確認用戶也是自動確認用戶。延伸確認用戶持續破壞或編輯戰的頁面上使用延伸確認保護嗎？您維的一部分人那麼喜歡抓字眼，不能留bug給人抓。--路西法人 2022年12月29日 (四) 02:09 (UTC)

話說我原本也是覺得可以簡化措辭，幸好我有事先隨機選了一位延伸確認使用者確認延伸確認使用者必定同時為自動確認使用者，才沒輕易發言惹出笑話來。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年12月29日 (四) 04:49 (UTC)

延伸確認使用者的編輯次數與註冊天數要求都比自動確認使用者更高，因此前者必然包含後者。是說為什麼自動確認使用者是隱含使用者群組，延伸確認使用者就不是了……。--冥王歐西里斯（留言） 2022年12月29日 (四) 06:35 (UTC)

離題討論，用戶自己對號入座後魯莽指控他人譏諷。--路西法人 2022年12月31日 (六) 18:27 (UTC)

@Ericliu1912：首先我個人不會將有關言論稱之爲“輕易發言所惹出的笑話”（見其他不文明行爲#譏諷一段），這只是簡練與謹慎之間的分歧而已。用Wp:常識角度考慮，假使真的有人使用諸如“啊！延確也是自確，所以您維這樣是不對的！”我想大抵會被視作游戲維基規則，從而再吃一個封禁。應對延確破壞，在不考慮邏輯錯誤的前提下，自然是使用全保護。——WMLO（留言） 2022年12月30日 (五) 09:50 (UTC) 我這兒的「輕易發言惹出笑話來」當然是指自己，畢竟只有嚴以律己才能嚴以待人。—— Eric Liu 創造は生命（留言・留名・學生會） 2022年12月30日 (五) 14:52 (UTC) @Ericliu1912： 很遺憾您在鷹膺任管理員不到三個月的時間，便用了之前一些人的伎倆。無論是先前您爲我的失誤移動致以維基感謝，抑或“輕易發言惹出笑話來是指自己”，譏諷便是譏諷。不會因您的辯稱而有改變。——WMLO（留言） 2022年12月30日 (五) 17:51 (UTC) 啥？另外是「膺」，不是「鷹」。—— Eric Liu 創造は生命（留言・留名・學生會） 2022年12月30日 (五) 17:55 (UTC)

(＋)支持和(！)意見：由於考量方針規範之整體性，以及不同保護層級之層次（「延伸確認保護」是「半保護」的強化保護層級，而管理員使用「延伸確認保護」前，必先理解「半保護」的概念和使用條件），且綜合考量針對長期破壞者的實務判斷（如Wikipedia:互助客栈/其他#對管理員執行延伸保護的提醒的情形），個人建議條文為：

管理員僅能在頁面已被半保護，且證實半保護仍無法阻止可在經證實半保護難以發揮效用破壞或編輯戰的頁面上使用延伸確認保護。與半保護相同，不得對尚未發生的破壞或編輯戰進行預見性保護，亦不得將延伸確認保護使用於破壞或編輯戰以外的頁面上，應直接使用全保護；於模板或模組可使用模板保護。

個人意見，供參。--Kriz Ju（留言） 2022年12月29日 (四) 20:13 (UTC)

@Kriz Ju：不支持以如此含糊的方式表達，仍然存在可以被抓bug的可能性。--路西法人 2022年12月30日 (五) 02:37 (UTC)

若如此，那麼Wikipedia:互助客栈/其他#對管理員執行延伸保護的提醒的情形如何是好？往後是否反倒對管理員掣肘呢？如果嚴格要求必須先進行半保護，才能進一步提升為延伸確認保護，特定破壞者的情形除了難以應對以外，上述Wikipedia:互助客栈/其他#對管理員執行延伸保護的提醒提及的管理作為是否合乎程序可能就有疑慮了。--Kriz Ju（留言） 2022年12月30日 (五) 18:31 (UTC)

您的提案正正無法解決會被人抓bug說要先半保護的問題。請你從頭到尾將前面的留言和建議再讀一遍。--路西法人 2022年12月31日 (六) 00:58 (UTC)

建議第一階段放寬編輯權限

我留意了很多半保護條目，大部分的半保護日期皆歷史悠久，破壞已經是數年前的事了。這樣不但失去了防止破壞的作用，還影響了無數使用者編輯。因此我建議解除所有早於2015年實施的條目保護。請各位在下方討論，謝謝。彈不了拉三的小傢伙 2022年12月28日 (三) 05:27 (UTC)

想問一問管理員：

1.2015年前實施條目保護的清單？

2.相關數字

沒有這些資料的話無法支持此議案。--唔好阻住我愛國（留言） 2022年12月28日 (三) 07:15 (UTC)

看Special:已保护页面。

有需要的话，去WP:请求保护页面提出解除不就行了？——Sakamotosan路过围观 | 避免做作，免敬 2022年12月28日 (三) 07:45 (UTC)

太多了，需要機器人幫忙。彈不了拉三的小傢伙 2022年12月28日 (三) 08:05 (UTC)

真不多。以下是保护开始日未知或在2015年1月1日之前的仍受保护条目：

• 越南君主列表 （未知－不限期，越南相关）
• 丁朝‎ （未知－不限期，越南相关）
• 丁文雄 （未知－不限期，越南相关）
• 影武者 （未知－不限期）
• 法輪功 （未知－不限期）
• 越南政黨列表 （未知－不限期，越南相关）
• 阮芳鴛 （未知－不限期，越南相关）
• 阮祥叄‎ （未知－不限期，越南相关）
• 在台越南人‎ （未知－不限期，越南相关）
• 越南裔臺灣人‎‎ （未知－不限期，越南相关）
• 陳善謙‎ （2014－不限期，越南相关，KAGE）
• 楊文明‎‎ （2014－不限期，越南相关，KAGE）
• 琉球血淚新書‎ （2014－不限期，越南相关，KAGE）
• 闇影之心‎‎ （2014－不限期，KAGE）
• 闇影之心II‎‎‎ （2014－不限期，KAGE）
• 闇影之心：來自新世界‎ （2014－不限期，KAGE）
• 闇影之心2‎ （2014－不限期，KAGE）
• 阮文理‎ （2014－不限期，越南相关，KAGE）
• 陳智雄‎‎ （2014－不限期，KAGE）
• 最終幻想 探險者們 （2014－不限期，KAGE）
• 忍者蛇蛇丸君 櫻花公主與火龍的祕密‎ （2014－不限期，KAGE）
• 最終幻想：探險者們‎‎ （2014－不限期，KAGE）
• 2014年台北捷運隨機殺人事件 （2014－不限期）
• 阮金紅 （2014－不限期，越南相关）
• 乾坤元宝朝‎ （2014－不限期，萬聖至尊，不活跃）
• 阮金红 （2014－不限期，越南相关，KAGE）
• 馬丁·路德·金恩遇刺案‎ （2014－不限期，萬聖至尊，不活跃）
• 中国割据政权君主列表 （2014－不限期，萬聖至尊，不活跃）

绝大多数都是越南相关条目，背后一定有KAGE在。少数条目用膝盖都想得到必须得继续保护下去（法輪功，以及2015年被保护的中国共产党‎等）。考虑到KAGE现在仍然在活跃，我已经开始怀疑提案人是不是KAGE的傀儡了。 --MilkyDefer 2022年12月28日 (三) 08:56 (UTC)

@MilkyDefer ... 我是一位貢獻者，你是怎樣把我看成那垃圾的？彈不了拉三的小傢伙 2022年12月29日 (四) 02:24 (UTC)

如果這麼多頁面都不行，那就把2014年台北捷運隨機殺人事件、馬丁·路德·金恩遇刺案和中國割據政權君主列表解除保護吧。彈不了拉三的小傢伙 2022年12月29日 (四) 02:24 (UTC)

持续出没的破坏者的编写是否也需要方针来约束？

刚刚阅读KAGE的破坏者专页，请问虽然他是可恶至极的破坏者，但如果说公开居住地有助于IP判断的话，那么把他的姓名甚至照片公开出来对反破坏有何裨益？我经过阅读并没有看到他的用户名习惯会和这个本命有关系诶。这些做法是否合法、合情、合理呢？是否应当添加方针来约束持续出没的破坏者的专页的编纂规则？--向乌鲁木齐中路的英雄儿女致敬！ 2022年12月30日 (五) 12:29 (UTC)

您提的问题我也提过。我觉得LTA页确实有些写得很不好。但要不要定规则，还是先看有什么问题再说吧。 --ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2022年12月30日 (五) 12:45 (UTC)

初步認爲此專頁例子是過度喂食怪獸的典型，我想此人綫下大抵會説“哎呀維基那群人爲了我居然新建一個頁面，還那麽詳細欸！”從而開心的要死。當然，有些信息諸如Ip地址、破壞傾向為必要的，而我也認爲LTA界面的攥寫應僅為“偵測破壞者”這一目的，除此之外都是多餘的。建議移除照片、本名，如有必要，站内公開宣言部分也可移除。——WMLO（留言） 2022年12月30日 (五) 19:07 (UTC)

WP:百乐兔也放了一张他的头像 ——魔琴 [ 留言 贡献 新手2023计划 ] 2022年12月30日 (五) 21:20 (UTC)

WP:OUTING是针对所有用户的，所以LTA页面不应该含有用户的个人信息。--GZWDer（留言） 2022年12月30日 (五) 23:08 (UTC)

音樂關注度中「商業排行榜」字眼

根據NT:MUSIC：

作品至少登上一個具有一定規模的國家或地區月、年商業排行榜或兩個周商業排行榜頭十名內，但登上同一組織或單位發佈榜單的不同類別不在此列。

然而，根據維基百科:商業排行與認證，並非各地所有流行榜也有收錄有推薦來源，如香港般，五台流行榜（即商業電台的903專業推介、香港電台的中文歌曲龍虎榜、新城電台的新城勁爆流行榜、無綫電視的勁歌金榜，ViuTV的Chill Club 推介榜）亦非收錄全部五台；但相關五台本身在香港有認受性，在Wikipedia:格式手冊/音樂排行榜中，也有提及「可以考慮收錄具關注度且為該國或當地廣泛認同的榜單」。

因此，本人希望探討能否在音樂關注度中，「商業排行榜」的字眼是否可更改成類似「具認受性排行榜」的字眼。ThirdThink（留言） 2022年12月31日 (六) 02:21 (UTC)

正如我先前的評論，這項規則面向的是作品銷售、下載、派台、串流等商業成績，既然只討論商業表現那麼有投票成分的Chill Club 推介榜就不適用於該規則。至於其他派台排行，由於是單一平台也無法反應整個香港的商業成績。當然，不滿足此規則還有「曾獲得具關注度的國際性獎項（如葛萊美獎、朱諾獎、水星音樂獎、金曲獎、選擇音樂獎等）或該地區受廣泛認同的音樂獎項。」可以用，另外Wikipedia:格式手冊/音樂排行榜當初被眾人打槍，本身沒有任何效力 --窝法乙烷 儿法梦碎 2022年12月31日 (六) 03:32 (UTC)

• 中文歌曲龍虎榜不會見到方皓玟、Dear Jane
• Chill Club 推介榜不會見到炎明熹、After Class、吳若希
• 勁歌金榜不會見到MIRROR (組合)、張天賦、試當真
• 903專業推介少有見到環球音樂的藝人
• 新城勁爆流行榜 （幾乎所有派過台嘅歌手也有名次）

所以稱為「商業成績」沒有錯。--唔好阻住我愛國（留言） 2022年12月31日 (六) 08:08 (UTC)

將维基百科:命名常规 (国际关系)升格為本站格式指引

如題。此草案先前因某些原因未得通過，但此前經過大量討論，已有一些初步共識。現舊案重提，望能得到通過。

我個人是認爲基本上沒有什麽值得更改的了。故先表態(＋)支持。

另允許我由衷感謝Sanmosa君等人的先前討論，才能讓現在的討論環境相對輕鬆些。--WMLO（留言） 2022年12月31日 (六) 05:55 (UTC)

基本上支持此草案；個人一直以來皆反對用連接號（字）原創研究辨別國際關係性質之命名方法。不過同時要提醒，過往主要之爭議不在於統一所使用之連接號（字），而在於具體要用什麼連接號（字）。社群對此難以形成共識—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年12月31日 (六) 15:00 (UTC)