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

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

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

公告欄

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

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

#	💭 話題	💬	👥	🙋 最新發言	🕒 (UTC+8)
1	提議提高條目評選投票資格門檻	65	21	Cdip150	2024-04-28 11:29
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)

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

可靠来源方针增加用户生成内容

Wikipedia:可靠来源:

現行條文 BBS和新闻组的帖子、Wiki的内容或者Blog上的留言都絕不能成为可接受的一次或者二次来源。这是因为我们无法知道它们究竟是谁写的。对于Wiki的情形，文章的内容可能在任何时刻发生变化，而且没有编辑人员监管或者第三方核查事实。

提議條文 由於缺乏事实查核以及普遍有效的帐户认证，用户生成内容通常是不可靠的。因为这些内容可能在任何时刻发生变化，而且没有编辑人员监管或者第三方进行事实查核。个人网站、博客、网络论坛、社交媒体、粉丝网站、视频分享网站、网络相册、Wiki通常都含有用户生成内容。 在部分社交媒体中会有帐户认证，以表明某个社交媒体账户由真实个人或组织拥有并运营。在这种情况下，该账号的可靠性可能继承自这个人或组织本身的可靠性。

Wikipedia:可供查證：

現行條文 任何人均可自创网站或自费出书，并借此声称自己是某领域的专家。因而，绝大多数个人出版之书籍、业务通讯、个人网站、开放性wiki、博客、论坛贴文及类似来源均不得被认可为可靠来源。。

提議條文 任何人均可在网络上发表言论或自费出书，并借此声称自己是某领域的专家。因而，绝大多数个人出版之书籍、业务通讯、个人网站、开放性wiki、博客、论坛贴文、社交媒体及类似来源均不得被认可为可靠来源。

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

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

  来源可靠性与账号是否认证，可能并无绝对关联。重点是内容是否被监督审查。--YFdyh000（留言） 2022年8月13日 (六) 22:08 (UTC)

  根据先前讨论，似乎只有YouTube和Facebook存在大量因订阅数不足而无法认证的问题。我觉得应该在WP:RSP单独说明YouTube这种特殊情况，而不是在可靠来源方针中列出。毕竟该提议的条文为：用户生成内容通常是不可靠的。并没有禁止所有用户生成内容。--Steven Sun（留言） 2022年8月14日 (日) 00:16 (UTC)

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

  中国大陆的社交平台也有类似的问题（例如某些官方认证的账号用是个人名义注册）--我永远喜欢搭档对战 2022年8月14日 (日) 07:49 (UTC)

“该账号的可靠性继承自这个人或组织本身的可靠性”建议改为“该账号的可靠性可能继承这个人或组织本身的可靠性”，有时某些断言会出现疑虑。其他方面基本支持，虽然修改后可能读者必须理解“用户生成内容”的准确意义。--YFdyh000（留言） 2022年8月13日 (六) 22:03 (UTC)

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

(※)注意：提议条文并没有完全禁止使用用户生成内容。允许给特殊情况留出讨论空间。相反的是，现有条文认为：BBS等...“都绝不能成为可接受的一次或者二次来源”--Steven Sun（留言） 2022年8月14日 (日) 08:13 (UTC)

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

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

「由於缺乏事实查核以及普遍有效的帐户认证，用户生成内容通常是不可靠的。因为这些内容可能在任何时刻发生变化，而且没有编辑人员监管或者第三方进行事实查核。个人网站、博客、网络论坛、社交媒体、粉丝网站、视频分享网站、网络相册、wiki通常都含有用户生成内容。

在部分社交媒体中会有帐户认证，.....（後略）」個人意見，供參。--Kriz Ju（留言） 2022年8月18日 (四) 23:16 (UTC)

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

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

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

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

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

我存在异议，并不是因为「普遍有效的帐户认证」才导致「用户生成内容通常是不可靠的」，这个因果关系并不必然，我看到User:YFdyh000也有提到这一点，结果提案还是在断言这一点。存在用户认证应该是直接可供查证，然后才是可能继承可靠性，这一点下文也有提及，因此删除首段「普遍有效的帐户认证」文字对提案具体内容没有太大影响。----Cat on the Mars 2022年8月30日 (二) 09:56 (UTC)

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

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

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

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

关于WP:SPS的问题，目前条文中的“开放性wiki、博客、论坛贴文”已超出了“自创网站”的范畴。使用“网络上发表言论”更符合“开放性wiki、博客、论坛贴文”的内容性质。--Steven Sun（留言） 2022年9月1日 (四) 14:15 (UTC)

依上方意见暂停公示。另外我也觉得应该删除首段的“普遍有效的帐户认证”。--Steven Sun（留言） 2022年8月30日 (二) 12:23 (UTC)

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

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

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

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

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

Wikipedia:可靠来源:

現行條文 BBS和新闻组的帖子、Wiki的内容或者Blog上的留言都絕不能成为可接受的一次或者二次来源。这是因为我们无法知道它们究竟是谁写的。对于Wiki的情形，文章的内容可能在任何时刻发生变化，而且没有编辑人员监管或者第三方核查事实。

提議條文 个人网站、博客、网络论坛、社交媒体、粉丝网站、影片分享网站、网络相册、Wiki的内容或者Blog上的留言都絕不能成为可接受的一次或者二次来源。这是因为我们无法知道它们究竟是谁写的。对于Wiki的情形，文章的内容可能在任何时刻发生变化，而且没有编辑人员监管或者第三方核查事实。通常都含有用户生成内容。 在部分社交媒体中会有帐户认证，以表明某个社交媒体账户由真实个人或组织拥有并运营。在这种情况下，该账号的可靠性可能继承自这个人或组织本身的可靠性。

Wikipedia:可供查證：

現行條文 任何人均可或自费出书，并借此声称自己是某领域的专家。因而，绝大多数个人出版之书籍、业务通讯、个人网站、开放性wiki、博客、论坛贴文及类似来源均不得被认可为可靠来源。。

提議條文 任何人均可自创网站、社群專頁或自费出书，并借此声称自己是某领域的专家。因而，绝大多数个人出版之书籍、业务通讯、个人网站、开放性wiki、博客、论坛贴文、社交媒体及类似来源均不得被认可为可靠来源。

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

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

现单独对Wikipedia:可供查證进行修订：

現行條文 任何人均可自创网站或自费出书，并借此声称自己是某领域的专家。因而，绝大多数个人出版之书籍、业务通讯、个人网站、开放性wiki、博客、论坛贴文及类似来源均不得被认可为可靠来源。。

提議條文 任何人均可自费出书，或者在开放性平台中贡献内容。因而，绝大多数个人出版之书籍、业务通讯、个人网站、开放性Wiki、博客、用户生成内容及类似来源一般不被认可为可靠来源。

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

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

“用户生成内容”和“个人出版物”区别蛮大的。网络上的用户生成内容，有身份确定和内容固定两大难题，所以不易做到可供查证。个人出版物则是内容正确性、利益相关、版本存续等问题。--YFdyh000（留言） 2022年9月5日 (一) 06:53 (UTC)

UGC的问题显然比SPS要大，后者只有一个可靠性问题，前者可靠性和可供查证都不稳定，认证用户有失水准也不是一天两天的事情，即便是认证用户在UGC鲜有评审的背景下也有自说自话、靠粉丝「自圆其说」的时候（很多时候出事就赖实习生）。我觉得承接前两个讨论，大多数人支持的论点应该是机构或媒体认证账号相对可信，还不至于现在把所有认证账号都包括进来，比方说我前面讲的个人认证账号的问题，至少在我看来这不是可靠来源，最多只能用作观点。

附：翻译一下ENWP的UGC政策以供参考。

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

有些网站的内容大多由用户生成，这些内容一般不是可接受的来源。这类网站涵盖个人网站、个人或集体博客（报刊杂志的博客除外（这里指代专栏博客））、内容农场、社交媒体、粉丝网站、音像或图片托管服务（共享网站？）、多数wiki以及其他集体协作创作内容的网站。

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

其中比较典型的有脸书、微博、Fandom、IMDb、Instagram、Reddit、抖音、推特和维基百科（自我引用），上述内容一般不是可接受的来源。（有删改）

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

In particular, a wikilink is not a reliable source.

尽管一些评论汇总网站（譬如烂番茄）在总结专家意见时或许可靠，但除此之外其基于用户评价的评分并不可靠。特别要强调的是，维基百科不是可靠来源。

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

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

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

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

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

現行條文 在部分社交媒体中会有帐户认证，以表明某个社交媒体账户由真实个人或组织拥有并运营。在这种情况下，该账号的可靠性可能继承自这个人或组织本身的可靠性。

提議條文 部分社交平台帳號可以透過包括但不限於平台的帐户认证或其他方式來證明某社交媒体账户代表現實中的特定个人或组织。在这种情况下，這些账号所發表內容的可靠性一般可被視作等同於这个人或组织在其他場合所發表的內容。但要注意這些經證明能代表特定人物的社交平台帳號可能由經委託予他人所操作，因此未必能用於證實特定發言出自帳號持有者。

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

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

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

提案裁撤案內多餘章節

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

同意。此外我觉得Wikipedia:可靠来源#作者自行发表的材料也应一并废除。还有Wikipedia:可靠来源#在关于作者自己的条目中采用他们自行发表的来源也有点多余，似乎可以合并至Wikipedia:利益衝突中。--Steven Sun（留言） 2022年9月1日 (四) 13:57 (UTC)

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

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

提議條文 任何人都可以建立网页、自行出版、或自称专家，自行发表的来源往往未经任何事实核查，缺乏独立第三方评审，因此绝大多数个人出版物、个人网站、博客、开放性wiki、网络论坛或社交媒体上的贴文以及其它类似来源通常不是可接受的来源。 不过也有一些特例，例如一些新闻媒体会以博客指代其网络专栏，如果专栏作者为专业人士其内容可能相对可靠；此外，如果某些内容专家已经在独立、可靠的出版机构发表过相关專業領域的个人作品，并且受到社会的普遍认可，那么其在相关專業領域的自行发表的内容也可能相对可靠。 編者仍需谨慎使用这类来源：一方面专栏的内容可能涉及作者个人观点，新闻媒体对专栏的事实核查也可能相对宽松，应该辨析专栏文章中的观点与事实，避免将作者的观点作为事实引用；另一方面，如果专家自行发表的内容值得发表，那麼可能已经有人做了相同的工作，存在独立第三方验证的可靠来源可以替代。 个人出版物不能作为有关在世人物的独立第三方来源，即便其作者是著名的职业调查员或作家。

說明

1. 第一句和第二句合并，前面半句为原因，「业务通讯」不知所指何物，因此删除归类到类似来源，同时原文「為了滿足虛榮心所發行的刊物」确系「自费出版商」英语Vanity Presses的误译，按ENWP似乎自费出版和自行出版在英美属于平行关系；

2. 「特例」同时参照en:WP:NEWSBLOG和en:WP:SPS以及现有内容进行修改，前一段中文中没有WP:NEWSBLOG，后一段WP:SPS也已经存在相似论述。（@YFdyh000、HTinC23：WP:V原文如下「但在某些情形下，个人出版物亦仍可以被接受。例如，出版人为受到肯定的专家，从事与条目主题相关领域的工作，并曾在可靠的第三方出版物中发表过該領域工作的文章。但是，此类来源的使用需要谨慎，并且如果有關信息的确值得记载，很可能已有他人做了相同的工作。」）

3. 最后一句补充自ENWP，en:WP:RS中称作「independent sources」，en:WP:V中称作「third-party sources」，统一为「独立第三方来源」。

WP:GUNREL是什么的缩写（Generally Unreliable?），我不清楚其是否对应ENWP的en:WP:RS/SPS，目前尽量保持两段SPS概述一致。最后想问一句是否存在共识删除WP:評估可靠性，将其归纳到WP:RS前面的「评估来源」一段，因为这应该也是先后翻译时间不同导致的同一段落重复问题，并且已有编者（@MilkyDefer：）指出这一段翻译水准不高。

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

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

@CatOnMars：

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

原文是established，这个词比较重，韦氏解释是「 accepted and recognized or followed by many people」，综合上下文应该是指已经获得媒体或学术引用，或者有专业人士充分肯定。----Cat on the Mars 2022年10月3日 (一) 09:11 (UTC)

公示案其一

（A:WP:GUNREL總言變更）任何人都可以建立网页、自行出版或自称专家，自行发表的来源往往未经任何事实核查，缺乏独立第三方评审，因此绝大多数个人出版物、个人网站、博客、开放性wiki、网络论坛或社交媒体上的贴文以及其它类似来源通常不是可接受的来源。

不过也有一些特例，例如一些新闻媒体会以博客指代其网络专栏，如果专栏作者为专业人士其内容可能相对可靠；此外，如果某些内容专家已经在独立、可靠的出版机构发表过相关專業領域的个人作品，并且受到社会的普遍认可，那么其在相关專業領域的自行发表的内容也可能相对可靠。

編者仍需谨慎使用这类来源：一方面专栏的内容可能涉及作者个人观点，新闻媒体对专栏的事实核查也可能相对宽松，应该辨析专栏文章中的观点与事实，避免将作者的观点作为事实引用；另一方面，如果专家自行发表的内容值得发表，那麼可能已经有人做了相同的工作，存在独立第三方验证的可靠来源可以替代。

个人出版物不能作为有关在世人物的独立第三方来源，即便其作者是著名的职业调查员或作家。

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

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

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

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

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

@Longway22：

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

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

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

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

技術探討

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

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

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

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

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

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

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

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

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

比方說：

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

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

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

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

别改cite，单独建立一个标识模板就可以。目前来说，建立流程共识也许比过滤器等技术手段更优先。--YFdyh000（留言） 2022年10月11日 (二) 16:27 (UTC)

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

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

是要单弄一套cite？我觉得弄个标识模板指向讨论/状态说明页就好，放在ref标签内或外，cite保持原样。命名都可以，像是{{Verified UGC}}或{{checked UGC}}。--YFdyh000（留言） 2022年10月11日 (二) 16:37 (UTC)

新建布告板的目的是？Wikipedia:可靠来源/布告板或其子板块会否更好。我不理解并且认为“担保资格”效力欠缺共识，虽然设法提供/列明可能是有益的。--YFdyh000（留言） 2022年10月7日 (五) 13:13 (UTC)

意見商討

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

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

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

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

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

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

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

.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

.

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

.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(＆)建議 “、或自称专家”。以及我想确认，“个人出版物”是由个别人完成出版主要流程（如撰稿、编审）的出版物，语出个人（如采访、自述）但经历可靠流程的出版物不是个人出版物，应以其他角度衡量可靠性。个人或小团体编撰后交由正式出版社发行的书籍，可能需个案辨别可靠性。“个人出版物不能作为有关在世人物的独立第三方来源”该如何理解？仍可能是观点的可靠来源，但不应是事实查核的可靠来源。--YFdyh000（留言） 2022年10月4日 (二) 13:24 (UTC)

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

@Longway22：

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

.

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

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

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

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

.

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

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

.

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

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

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

(！)意見，我最近没有空参与讨论了，所以就三件事表达一下观点：第一点，回答U:YFdyh000的问题，首先个人出版物是专有名词，实际上专业出版社也有可能承接自费出版业务，主要差异还是在于编辑审核的流程；第二点，还是U:YFdyh000有关生者传记的问题，WP:生者传记已经规定不论批评还是赞美的观点都需要出自可靠来源，个人出版物的观点无论如何都不是生者传记观点的可靠来源，这是方针一致性要求；第三点，即便放在现有的方针里，存在更好来源或者可替代也不是删除已有相对可靠来源的理据，新的提案也没有强制在存在可替代来源的时候一定要使用更好来源，如果编者认为存在更好来源，应该自己举证并替代，原则上条目大部分内容应该是由可靠来源构成，比方facebook来源如果无法得到第三方证实可靠性则不应该用于构成条目的主要事实。以上。--Cat on the Mars 2022年10月5日 (三) 16:16 (UTC)

“个人出版物的观点无论如何都不是生者传记观点的可靠来源”，比如A的（出版自传/采访/博客）中包含对B的评价或者生平信息，是否都绝不能作A的观点或B的事实（声称）来引述，具体可靠性如何，我感觉要依情况商榷，难以一言概之。--YFdyh000（留言） 2022年10月6日 (四) 03:38 (UTC)

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

公示案其一（修正4）

（A:WP:GUNREL總言變更）任何人都可以建立网页、自行出版或自称专家，自行发表的来源往往未经任何事实核查，缺乏独立第三方评审。由於绝大多数个人出版物、个人网站、博客、开放性wiki、网络论坛或社交媒体上的贴文以及其它类似来源通常不是可接受的来源。因此所有使用者生成內容來源會被列入防濫用過濾器。

不过也有一些特例，例如一些新闻媒体会以博客指代其网络专栏，如果专栏作者为专业人士其内容可能相对可靠；此外，如果某些内容专家已经在独立、可靠的出版机构发表过相关專業領域的个人作品，并且受到社会的普遍认可，那么其在相关專業領域的自行发表的内容也可能相对可靠。

編者仍需谨慎使用这类来源：一方面专栏的内容可能涉及作者个人观点，新闻媒体对专栏的事实核查也可能相对宽松，应该辨析专栏文章中的观点与事实，避免将作者的观点作为事实引用；另一方面，如果专家自行发表的内容值得发表，那麼可能已经有人做了相同的工作，存在独立第三方验证的可靠来源可以替代。

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

个人出版物不能作为有关在世人物的独立第三方来源，即便其作者是著名的职业调查员或作家。

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

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

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

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

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

同约克客观点，不认为应该为布告板附加特殊效力。--Yinyue200（留言） 2022年10月8日 (六) 03:12 (UTC)

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

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

.

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

@Hijk910：

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

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

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

我也觉得过滤器方案比较好，这样也与当前的惯例相差不大。合理的编辑并不会因为是否事先履行了某些手续就变得合理或者不合理，维基百科不是官僚机构。--Yinyue200（留言） 2022年10月8日 (六) 08:56 (UTC)

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

@Longway22@ThirdThink@Yinyue200

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

我仍然认为在“于来源引用中标示相关来源的担保资格”不太合理。我的建议是这样写：若相关来源未（在布告板）获得共识，编者应在条目的合适位置或讨论页体现出相关来源的担保资格。未进行标示的内容可能会被他人移除。被移除的内容若能发现有效的补充材料，则可重新加入。--Yinyue200（留言） 2022年10月10日 (一) 15:16 (UTC)

@Yinyue200：

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

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

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

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

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

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

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

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

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

使用者生成內容使用條件：注：不適用开放性wiki、网络论坛及與上述相關的社群網站

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

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

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

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

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

我觉得不适宜在这里订一些很硬性的规定，这类过于客观的标准很难覆盖所有情况，我觉得可以直接删除“某年份”的表述：如相关账号不属任何机构，账户需获得过媒体或学术引用，或被专业人士充分肯定。过旧的证据可能不被考虑。--Yinyue200（留言） 2022年10月10日 (一) 15:06 (UTC)

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

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

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

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

然而第二点您未解答，我觉得您提出草案的问题在于内容太过僵硬，用词太过绝对，不适宜广泛推广。现有方针很少有用词如此绝对的条文。--Yinyue200（留言） 2022年10月11日 (二) 11:56 (UTC)

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

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

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

确实一般应当过滤“街访”--Yinyue200（留言） 2022年10月11日 (二) 15:59 (UTC)

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

(！)意見：以我自己的认知，满足前四条中的二、三和四条的时候，通常这个来源已经没法算作“用户生成内容”了。例如本身被视作可靠来源的传统媒体，其在社交平台经认证发布的属于新闻报道文体的文章，归入用户生成内容就不合适。但同样的一家媒体的评论员，以媒体账号在同样的平台发布的社论性质的文章，则又不宜。这其中的区别并不在于账户持有者的身份。二选一中的第一条满足的时候，引用它的媒体或学术来源就会应该就是替代来源，会自动让第一条不成立。(＆)建議：第一条的措辞可考虑修改为“相关内容无法由其他更为可靠的来源替代”，明确替代来源应该往什么方向寻找。--Tiger（留言） 2022年10月11日 (二) 15:43 (UTC)

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

簡單回應:

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

（A:WP:GUNREL總言變更）任何人都可以建立网页、自行出版或自称专家，自行发表的来源往往未经任何事实核查，缺乏独立第三方评审。由於绝大多数个人出版物、个人网站、博客、开放性wiki、网络论坛或社交媒体上的贴文以及其它类似来源通常不是可接受的来源。因此所有使用者生成內容來源會被列入防濫用過濾器。

不过也有一些特例，例如一些新闻媒体会以博客指代其网络专栏，如果专栏作者为专业人士其内容可能相对可靠；此外，如果某些内容专家已经在独立、可靠的出版机构发表过相关專業領域的个人作品，并且受到社会的普遍认可，那么其在相关專業領域的自行发表的内容也可能相对可靠。

編者仍需谨慎使用这类来源：一方面专栏的内容可能涉及作者个人观点，新闻媒体对专栏的事实核查也可能相对宽松，应该辨析专栏文章中的观点与事实，避免将作者的观点作为事实引用；另一方面，如果专家自行发表的内容值得发表，那麼可能已经有人做了相同的工作，存在独立第三方验证的可靠来源可以替代。

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

个人出版物不能作为有关在世人物的独立第三方来源，即便其作者是著名的职业调查员或作家。 （B:由A修正案並行，同時廢止WP:WIKISRC章節全部內容及超鏈接，全由A案之WP:GUNREL條文適用）

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

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

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

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

(？)疑問：上面有多个讨论的子章节看起来有点像是公式的提案内容，不知先前参与讨论的几位可否澄清目前其中哪些正在公示？--Tiger（留言） 2022年10月11日 (二) 15:43 (UTC)

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

已移除“管理员意见”的标题。管理员身份在这里没有也不应该有任何作用，也请不要替我给我的意见加上标签。—Tiger（留言） 2022年10月11日 (二) 21:17 (UTC)

---

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

（A:WP:GUNREL總言變更）任何人都可以建立网页、自行出版或自称专家，自行发表的来源往往未经任何事实核查，缺乏独立第三方评审。由於绝大多数个人出版物、个人网站、博客、开放性wiki、网络论坛或社交媒体上的贴文以及其它类似来源通常不是可接受的来源。因此所有使用者生成內容來源會被列入防濫用過濾器。

不过也有一些特例，例如一些新闻媒体会以博客指代其网络专栏，如果专栏作者为专业人士其内容可能相对可靠；此外，如果某些内容专家已经在独立、可靠的出版机构发表过相关專業領域的个人作品，并且受到社会的普遍认可，那么其在相关專業領域的自行发表的内容也可能相对可靠。

編者仍需谨慎使用这类来源：一方面专栏的内容可能涉及作者个人观点，新闻媒体对专栏的事实核查也可能相对宽松，应该辨析专栏文章中的观点与事实，避免将作者的观点作为事实引用；另一方面，如果专家自行发表的内容值得发表，那麼可能已经有人做了相同的工作，存在独立第三方验证的可靠来源可以替代。

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

个人出版物不能作为有关在世人物的独立第三方来源，即便其作者是著名的职业调查员或作家。

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

及防濫用警告器內容：

使用者生成內容使用條件：注：不適用开放性wiki、网络论坛及與上述相關的社群網站

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

---

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

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

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

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

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

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

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

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

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

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

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

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

不支持条文即行生效，我还是认为当前条文的内容和原始条文的风格差异相差太大。原始条文基本上是在阐述一个行事的原则。新的规定则详细的多，尽管相比一开始的提议已经有所改善。我认为这样的提案一旦推行会对当前编辑维基百科的行为产生较大影响，需要凝聚更多共识。--Yinyue200（留言） 2022年10月16日 (日) 08:54 (UTC)

@Yinyue200：

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

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

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

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

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

“因此所有用户生成内容来源会被列入防滥用过滤器”：过滤器有标签、警告和阻止等处理操作。这个地方没说明白执行何种操作。建议不要一刀切执行阻止操作。

个人建议用户生成内容使用条件不宜有过细的硬性规定。针对特定来源有问题，在布告版或者互助客栈讨论即可。另外Wikipedia:关注度中有讲关注度指引并不直接限制条目内容。不应直接按照关注度的要求来限制来源。--Steven Sun（留言） 2022年10月21日 (五) 08:14 (UTC)

1.warning & label

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

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

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

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

———

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

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

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

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

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

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

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

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

@Longway22：

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

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

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

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

就“仍然没有反对声音”，那我补充我的观点。新条文“可能”很有参考价值，但是否凝聚广泛共识仍很存疑，所涉来源价值定义的影响会非常广泛，讨论编者的广度和时长、实际效果不显著，没有达到过往的影响全站之政策的程度。个人而言，新条文对细节和流程的规定仍显复杂，与现有常见实践缺乏对比、疑存冲突，实际执行的可行性和公信力仍未显现，未参与讨论的编者未必接受，可靠性讨论也未必能得出可信结论。总结而言，我觉得它是半个指引、一份提案、一篇论述。还请加油，比如提出一些先后对比实例，将所需页面搭好框架、局部试行作参考。改cite模板我是反对的，改滥用过滤器我认为时候未到。--YFdyh000（留言） 2022年10月25日 (二) 14:12 (UTC)

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

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

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

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

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

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

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

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

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

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

.

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

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

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

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

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

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

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

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

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

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

.

ref

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

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

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

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

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

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

佈告版制度

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

---

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

（A:WP:GUNREL總言變更）任何人都可以建立网页、自行出版或自称专家，自行发表的来源往往未经任何事实核查，缺乏独立第三方评审。由於绝大多数个人出版物、个人网站、博客、开放性wiki、网络论坛或社交媒体上的贴文以及其它类似来源通常不是可接受的来源。因此所有使用者生成內容來源會被列入防濫用過濾器。

不过也有一些特例，例如一些新闻媒体会以博客指代其网络专栏，如果专栏作者为专业人士其内容可能相对可靠；此外，如果某些内容专家已经在独立、可靠的出版机构发表过相关專業領域的个人作品，并且受到社会的普遍认可，那么其在相关專業領域的自行发表的内容也可能相对可靠。

編者仍需谨慎使用这类来源：一方面专栏的内容可能涉及作者个人观点，新闻媒体对专栏的事实核查也可能相对宽松，应该辨析专栏文章中的观点与事实，避免将作者的观点作为事实引用；另一方面，如果专家自行发表的内容值得发表，那麼可能已经有人做了相同的工作，存在独立第三方验证的可靠来源可以替代。

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

个人出版物不能作为有关在世人物的独立第三方来源，即便其作者是著名的职业调查员或作家。

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

及防濫用警告器內容：

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

注：不適用开放性wiki、网络论坛及與上述相關的社群網站

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

---

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

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

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

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

(－)反对。第一，与现行条文差别过大，不清楚到底要改什么，要解决什么问题。第二，“所有用户生成内容来源会被列入防滥用过滤器”这是管理员的责任还是谁的责任，如何列举“所有”？第三，“能辨认账号持分者的身份”，维基百科什么时候需要身份验证了？弗兰西斯·培根写文章没提交身份证吧，他就不是可靠来源了？总之，提议的条文跟现行条文相比，对编者的要求大大提高，不利于参与。--Gqqnb（留言） 2022年10月23日 (日) 08:50 (UTC)

@Gqqnb：

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

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

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

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

---

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

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

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

不认同强制在条目页申报，如相关账号身份确有疑点，有人提出后，添加者才有义务在讨论页回应。--Yinyue200（留言） 2022年11月2日 (三) 07:07 (UTC)

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

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

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

对，这是我的观点，我认为如果只是“有责任”而不是“必须”那其实和现有方针差异不大，但也要看社群的意见。--Yinyue200（留言） 2022年11月7日 (一) 12:19 (UTC)

---

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

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

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

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

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

我仍担忧可行性（共识、执行力和强制力）。建议您先试行流程以体现效果（如认可/不认可来源）和编者接受度，再研究条文及条目内标注的共识程度。--YFdyh000（留言） 2022年11月22日 (二) 04:14 (UTC)

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

中维的FA、GA、DYK等评选是否可以改为英维的审议制而非强制投票制？

目前许多地方的投票制已经引发社群多次质疑和讨论，动辄被认为有灌票嫌疑（甚至有不拉票即不能通过的说法），而且许多评选参与者不多，几乎将沦为虚设，强制性的票数界限反而使许多达标页面仅因为评选无人光顾而未能获选，关于改为英维审议制，社群又何看法？欢迎大家讨论。--有困扰的话，就让魔女用魔法帮你排忧吧！ 2022年9月26日 (一) 04:47 (UTC)

如果审议人审议通过了不合格的条目，该负什么样的责任？审议人审议条目，又能获得何种激励？好奇这个审议制度如何运行。Fire Ice 2022年9月26日 (一) 08:11 (UTC)

我也不了悉英维为何能这样运作而不至于出问题，亦不清楚中维是否这样运作会出问题--有困扰的话，就让魔女用魔法帮你排忧吧！ 2022年9月26日 (一) 10:31 (UTC)

英维似乎FA、GA、DYK都没有激励机制。看过一些GA就一个人审议，标准弹性很大。也存在公开交换审议的情况。--Benevolen（留言） 2022年9月26日 (一) 10:53 (UTC)

如果审议人审议通过了不合格的条目，该负什么样的责任？审议人审议条目，又能获得何种激励？ - 个人觉得这些问题不存在，而实话实说和这种话很像：如果IP用户写出了不合格的内容，该负怎么样的责任？IP用户编辑条目，又能获得何种激励？

关于不合格条目，可以读读英维重选流程。两种方式，并且可以以个人的方式进行重选。--0xDeadbeef（留言） 2022年9月26日 (一) 13:12 (UTC)

你应该和如下例子类比：如果巡查员巡查通过了不合格的内容，该负怎么样的责任？巡查员巡查条目，又能获得何种激励？当然，DYK、GA、FA比新条目巡查责任更为重大，他们将被推上首页，甚至读者要是点击图标，还能看到“优良条目是我们认为质量令人满意，但未达典范标准的条目”等内容，甚至是“我们认为这些条目详尽而深入，符合特定要求，是维基百科条目之杰出典范。”如果审议人把诸如远东华人强制流配的原版这类东西选为FA，将来媒体报道顺便提到某维基人“有三篇条目被评为优良条目，一篇被列为典范条目——此条目还被其他语言的维基百科用户翻译为英语、俄语、乌克兰语、罗马尼亚语以及阿拉伯语。”谁来负这个责任，该负什么样的责任？Fire Ice 2022年9月26日 (一) 13:56 (UTC)

GA、FA推上首页难道不是需要更多人审议吗？英维的DYK在上首页之前都需要管理员进行批准的。至于FA在英维上可也是需要多个人审核达成共识。所以GA真的责任重大，必须投票表决吗？如有问题则处理问题，无法处理问题则是另一个问题。如有GA捣乱的，轻者WP:TBAN，重者直接封禁不就行？--0xDeadbeef（留言） 2022年9月26日 (一) 14:06 (UTC)

当下GFA就是无人负责的，如果审议制度同样无人负责，和当下制度又有什么区别呢？Fire Ice 2022年9月26日 (一) 14:09 (UTC)

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

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

如果是按标准打勾勾的话，只不过变成自动灌票罢了（一次提交，一次“自动”判断标准，一次同意通过）。如果是人审议的话，出现标准意见冲突怎么办？甚至说现在投票机制，有点像按标准进行人工审议罢了。——Sakamotosan路过围观 | 避免做作，免敬 2022年9月26日 (一) 09:01 (UTC)

我们至少需要具备基本的编辑经验/能力的用户才可能做好这一点吧？--百無一用是書生 (☎) 2022年9月26日 (一) 11:44 (UTC)

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

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

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

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

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

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

粤维人数和中维不可同日而语吧--有困扰的话，就让魔女用魔法帮你排忧吧！ 2022年10月2日 (日) 10:01 (UTC)

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

 吐槽我的DYK恐惧症就是这么来的...-- B-MIKE -留|签 2022年10月31日 (一) 14:09 (UTC)

试行一次

吵这么凶大家都是在纸上谈兵，应该要实际做一次才能知道好不好才对。要不这样，我提议实际使用一个典范条目评选试行一次审议制度。这样有没有问题、会不会有问题就全部显现出来了。参考英维的评选制度，一名协调员拥有是否入选的最终决定权，这也解决了所谓的无人对审议结果负责的问题。

所以我就是说，大家是否愿意让下一篇典范条目评选由我作为协调员实际做给大家看一次是否可行，否则这个讨论永远都是没有任何论据的辩论，不及格。 --MilkyDefer 2022年9月28日 (三) 07:36 (UTC)

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

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

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

赞成。对于我熟悉的领域，我愿意作为评议人参与。（如果我有时间）--洛普利寧 2022年9月30日 (五) 02:55 (UTC)

支持，如果是我熟悉的领域，我愿意作为评审人参与。--——🦝英特浣熊耐尔 ^{就一定要实现}_{（留言・贡献）} 2022年10月2日 (日) 08:47 (UTC)

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

• 儘管我不覺得能夠阻止什麼: RFA試行與條目評審試行其實有很大的分別。RFA總是能夠吸引大量用戶前來，制度本身無非是怎樣令大家服氣而已。條目評審的本質問題是對某一方面有專攻的用戶不足，因此如果按自己的初步觀念投票，就有亂投、灌票之嫌; 如果總是由兩三大佬投反對票，又有對新人不公云云。現在試行萬眾矚目，將各路精英聚集起來，自然能撐起場面，但日後又怎辦呢?--Temp3600（留言） 2022年10月7日 (五) 10:10 (UTC)
  • (：)回應：典范条目几大标准：全面、流畅、专业、考据全面、稳定、遵循格式手册、媒体使用恰当、长度合理，对审查者的能力标准要求是不一致的。审议制度允许审核者只针对这其中的部分标准提出支持，协调员会检查候选条目是否完整地接受了检查。因此，审议制度可以让评审者有力出力，回归典范条目标准，同时阻挡远东华人强制流放这种做了来源检查就能发现问题但是偏偏没人做就已经够票了的条目通过。投票制度在另一方面，投下支持票不需要说明理由，一个“符合典范条目标准”到底是否完整涵盖了所有标准呢？不知道。有责任心的人看到标准这么多没精力逐条确认所以不投；没责任心的人看着条目差不多符合流畅、遵循格式手册、长度合理就直接给支持票了。审议制度将典范条目标准进行足够细颗粒度的审视，有能力的人只要专心检查是否专业、是否与来源对得上号即可，专业能力欠缺的人就去检查行文是否流畅，格式是否得当等不需要专业知识的准则。将审核过程分工完成降低了所有人的负担，或可形成能力门槛降低的效果，更有亲和力。协调员是守门员，对他们的要求应当较高。 --MilkyDefer 2022年10月7日 (五) 11:37 (UTC)
  • 我擔憂的是，實施初期可能會有編輯秉著改善中維的決心去審視各提名條目，這當然是好事，但日子久了，參與人數或會穩定下降，最後典範條目評選重回多年前投票附理由的情況，即「內容充足、語句順暢，參考資料足以支撐全文，以支持票作獎勵。」之類。--銀の死神♠走馬燈劇場^{祝你在亂流下平安} 2022年10月8日 (六) 10:14 (UTC)

    不一样，如果害怕有这种现象就应该不允许投票带理由，而是给每一个条件打钩或给予评价，这样迫害捣乱评选者的时候就不可以以忘记了有这个规定的理由逃避迫害。--0xDeadbeef（留言） 2022年10月8日 (六) 10:33 (UTC)

    共识制评选的规定中，如果“评审员没有提供足够的信息来判断条目是否符合标准”，协调员可以判落选。

    此外，虽然共识制在中维可能做不到完美，但能避免投票制中的不少问题：比如不读条目就投yesFA（甚至我看到有提名人请求撤销FA时，都有用户上来就投yesFA……）、高质量的条目因为规定时间内少几个人投yesFA而落选等，我觉得总体而言共识制仍是一大进步。--BlackShadowG Slava Ukraini! 2022年10月8日 (六) 14:39 (UTC)

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

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

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

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

    我认为不管你如何想，有进步比原地踏步要好。如果能够透过改善一下优质条目整体水准的方式吸引一些学者来（而不是对英维趋之若鹜、对中维嗤之以鼻）的话，就更好了。--MilkyDefer 2022年10月8日 (六) 15:20 (UTC)

方案设定

那就这样，我先草拟一个方案，如下：

• 在该方案得到公示通过后，试行一次有效的评议制典范条目评选。
• 上一条当中的“有效”指的是，条目不满足快速落选准则，且不是典范条目重审。
• 选择的评选条目应该是在公示通过后，所提交的第一条典范条目评选。如果该候选条目不是有效的评选，则选择确定候选条目评选无效时刻起，下一条提交的候选条目，以此类推。
  • 例子：假如本方案于2022年11月1日凌晨3:47公示通过，同日凌晨4:13有人提交了条目A作为典范条目候选、上午9:24另有人提交了条目B、下午17:33有人提交了条目C。则条目A成为试行评议制的对象，条目B和条目C继续使用投票制。但是，在11月2日上午10:41时有人发现条目A含有大量侵犯版权的内容而导致其快速落选（参见即时不合标准准则第2条），则这一次对条目A的评审为无效评审。由于条目B和C已经在走投票流程甚至有人可能已经投票了不适合打搅，因此应当选择11月2日上午10:41后提交的第一条典范条目候选作为新的审议对象，以此类推。
• 该次使用审议制的评选，其结果拥有与现行投票制同等的效力。即，若审议为入选，则条目获得典范条目资格；若审议结果为落选，则条目同样落选，30日冷静期同样适用。
• 应该为该次试行开设评审专页，同时在典范条目评选主入口提供进入该次评审专页的链接。（这一条是为了防止评议发言过多影响其他条目的评选，可再做商议）
• 该次试行的协调人由我担任，毕竟是我提出要试行一次的。
• 试行结束后，我们继续讨论后续事宜。

如何？我还遗漏了什么要点吗？ --MilkyDefer 2022年10月2日 (日) 09:40 (UTC)

作为提案发起人表示原则性(＋)支持，唯我另发起了一个二十周年闭站抗议提案，可能时间上容易冲突--有困扰的话，就让魔女用魔法帮你排忧吧！ 2022年10月2日 (日) 09:47 (UTC)

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

@Longway22 所以具体而言有什么意见吗？你说的这些太宽泛了完全不懂。--MilkyDefer 2022年10月7日 (五) 03:15 (UTC)

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

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

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

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

(＋)支持--——🦝英特浣熊耐尔 ^{就一定要实现}_{（留言・贡献）} 2022年10月4日 (二) 04:15 (UTC)

(＋)支持。 --窝法乙烷 儿法梦碎 2022年10月4日 (二) 08:13 (UTC)

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

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

筹备

我开始筹备了：Wikipedia:典范条目评选/共识制试行，目前在翻译英维的规则。——BlackShadowG Slava Ukraini! 2022年10月7日 (五) 04:46 (UTC)

目前英维相关规则/模板翻译进度：

1. 主页面：Wikipedia:典范条目评选/共识制试行（en:Wikipedia:Featured article candidates）完成
2. Template:FAC-instructions（en:Template:FAC-instructions）完成
3. Template:FAC/共识制试行（en:Template:FAC）完成
4. Template:Featured_article_candidates/共识制试行（en:Template:Featured_article_candidates）完成
5. Template:Featured_article_candidates/editintro（en:Template:Featured_article_candidates/editintro）完成
6. Wikipedia:Featured article preload（en:Wikipedia:Featured article preload）完成
7. Wikipedia:典范条目评选/存档方式（en:Wikipedia:Featured_article_candidates/archiving）完成

下方的页面在试行阶段并非必须，可以等正式改用共识制后再翻译/引入：

1. User:FACBot（维护FAC的机器人，主要的工作是存档已关闭的提名）
2. Wikipedia:典范条目评选/急需评审（en:Wikipedia:Featured article candidates/FAC urgents）
3. Wikipedia:典范条目评选/入选记录（en:Wikipedia:Featured article candidates/Featured log）入选的FAC由协调员加到这个页面
4. Wikipedia:典范条目评选/提名存档（en:Wikipedia:Featured article candidates/Archived nominations）落选的FAC由协调员加到这个页面

下方的页面可有可无：

1. Wikipedia:典范条目评选常见问题（en:Wikipedia:Wikipedia Signpost/2008-04-07/Dispatches）FAC的常见问题，没有也问题不大
2. Wikipedia:典范条目统计（en:Wikipedia:Featured article statistics）

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

此外@MilkyDefer：英维提名FAC评选的方式是让提名人往条目的讨论页上放{{subst:FAC}}（目前中维的模板位于{{subst:FAC/共识制试行}}），随机抽条目可能在程序上会与正式的不太相同。因此，比起抽一篇“幸运条目”用共识制，要不让有意让条目以共识制评审的主编自荐条目？--BlackShadowG Slava Ukraini! 2022年10月7日 (五) 09:32 (UTC)

我们实验的是审议制度，在审议之外的流程性质的东西不在实验范围啊。--MilkyDefer 2022年10月8日 (六) 05:31 (UTC)

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

目前基本筹备已经完成，随时可以开始试行。--BlackShadowG Slava Ukraini! 2022年10月7日 (五) 09:49 (UTC)

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

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

能具体阐释一下你认为GA比FA更适合的原因吗？协调员的话一下子三个人就协调试行的一篇条目会不会多余了些？--MilkyDefer 2022年10月10日 (一) 01:12 (UTC)

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

有一个问题。你为什么会认为FA是多数社群认定的条目？可能确实需要比GA多一点的人认同，但是夸张到多数是不可能的。在英维平均一个GA的审阅者1到2个；FA大概10个，怎么看都不是“多数”。要追求你想象中的多数，任何一个地方都没有。--MilkyDefer 2022年10月10日 (一) 03:14 (UTC)

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

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

FA并不是一定要为了让读者感兴趣。只能说是百科全书里面最优秀的条目，而往往很多优秀的条目都是能够让人感兴趣而已。

另外，感谢你的回复，解析失败 (带有PNG备选的SVG（MathML可通过浏览器插件启用）：从服务器“/mathoid/local/v1/”返回无效的响应（“Math extension cannot connect to Restbase.”）：): \int 。--0xDeadbeef（留言） 2022年10月10日 (一) 06:00 (UTC)

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

所以才会有典范条目标准，将「最优秀的条目」的标准明确化。--MilkyDefer 2022年10月10日 (一) 06:10 (UTC)

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

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

讨论状态：普遍相信采取审议制度可以相比于投票制度拥有更严格的把关。

现在事实：典范条目在品质上要求更优于优良条目。

所以不对典范条目严格，反而对次一级的优良条目严格，不符合直觉。--MilkyDefer 2022年10月11日 (二) 12:58 (UTC)

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

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

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

我可以肯定，“审议制度可以相比于投票制度拥有更严格的把关”这句话所言绝对非虚。

如果说审议制“標準彈性很大”，那我可以说，投票制的所谓标准几乎可以视而不见。目前投票制是否入选不是依据“条目符合多少FA标准”，而是“多少人认为条目符合FA标准”。投下支持票的人可能没有读过条目，甚至可能知道FA要符合哪些标准，只要一定数量的用户投下支持票，条目就能入选，没有人能确定投票者是否有仔细审过（甚至是否审过）条目。即使有用户指出条目存在不少问题，只要支持票足以盖过他，那这些意见也可以视而不见。改用审议制度可以最大程度避免这种问题，至少审议制度中，仅仅表示支持是没有意义的。--BlackShadowG Slava Ukraini! 2022年10月12日 (三) 13:40 (UTC)

这样子说吧，请问你对于试行一次究竟有什么意见呢？改成GA和三个人总要有理由吧？英维的巨大RFC也只找了三个closer。如果和这个比起来是不是英维应该找三倍以上的人呢？不是说中维缺人吗？可现在一个无害的试运行都要求这么高了。--0xDeadbeef（留言） 2022年10月12日 (三) 13:49 (UTC)

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

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

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

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

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

如果要三个人，那你对于协调员人选有什么推荐吗？在此次试行中，这些问题应该不存在吧。还是说，你觉得MilkyDefer没有社群信任/不可信？如果说FA评选没问题，那折毛事件如何解释？--0xDeadbeef（留言） 2022年10月13日 (四) 04:11 (UTC)

阁下认为FAC“没什么问题”是因为FAC有硬性标准，不会引发争议。但FAC最重要的目的，逐一检查条目是否符合WP:FACR，在投票制中完全无法落实，理由已如前述（例如：参与者完全可以不看条目/不知道FA标准就投票让条目入选，少数服从多数可以让重要意见直接视而不见）。共识制度即使有争议，也可以提高FA条目质量的把关。阁下认为“没坏别修”，在我看来这是已经坏了，而且坏得很严重，折毛事件就证明了这一点。

此外我不认为三个协调员是适合中文维基百科社群运作方式的做法。中维本身就人手不足，判断共识还需要三个人才能做到吗？再者，协调员出现争议又给谁来判断协调员的共识？“协调协调员的协调员”？到头来判断共识的权利还是会落到一个人手里。--BlackShadowG Slava Ukraini! 2022年10月13日 (四) 15:34 (UTC)

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

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

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

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

诚然，审议制未必能完全防止折毛事件的发生，但能很大程度进行避免。当时远东华人强制流配的FAC中，没有用户检查来源，由于是投票制，因此即使没有用户做来源检查，条目也可以入选。如果是审议制，就更有可能有用户根据WP:FACR做来源检查（英维的伪条目Bicholim conflict就是在FAC被查出来的）。

鄙人仍不认为结案需要三个协调员，先不提中维是否有这么多人力，判断共识一个人足矣。协调员就相当于FAC的管理员，如果AFD要两三个管理员才能结案，显然不是什么好事。且会引起争议的评选，显然条目本身也是有问题的，即使被判落选，完善条目过一个月再来评选是个更好的方式。--BlackShadowG Slava Ukraini! 2022年10月15日 (六) 07:55 (UTC)

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

只是试行，必要性不大。英维这么大的社群也只需要四名协调员，一篇条目就是由一名协调员结案。需要注意的是，条目是否入选不是依据协调员的看法，而是依据审阅者的共识，协调员只是负责判断审阅者的共识。这就好比为何AFD只需要一名管理员就能结案一样。--BlackShadowG Slava Ukraini! 2022年10月11日 (二) 12:52 (UTC)

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

根据目前英维的规则，“没有达成条目入选的共识”就是落选；这与审议制的GAC区别很大，审议制的GAC是一名审阅者主要负责审阅，其它编者也可以发表意见，只要基本没什么问题，审阅者就可以评定入选，这比FAC宽松很多，所以我不建议阁下提议的用GAC试行。--BlackShadowG Slava Ukraini! 2022年10月12日 (三) 13:15 (UTC)

如果最终决断有疑，可以依托之前意见再讨论和重选，多名协调员得出的共识也未必是普遍、可靠的共识，共识始终可推翻。如同存废讨论的异议路径是存废复核。--YFdyh000（留言） 2022年10月11日 (二) 18:35 (UTC)

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

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

如果决断并不违逆共识而只是偏颇，继续在客栈等位置讨论就好，然后再走重选手续。严重情况得到共识建议雪球以推翻决定，但争议议题就很麻烦。如果说的难听，我也无法排除两名协调员一同忽视共识或争议的可能性，以及协调员如何可信。--YFdyh000（留言） 2022年10月11日 (二) 20:14 (UTC)

BlackShadowG回应后了我又看了一遍，我还是搞不懂为何需要有三个协调员。如果你认为协调员关闭讨论的是en:WP:SUPERVOTE，那是不是在暗示你不认可MilkyDefer对于共识的判定？协调员的主要工作只有两个：第一是判断讨论中有没有达成共识，第二是保证讨论没有遗漏掉WP:FACR，且在共识作为提拔FA时有合理反对的权利。但是，并不是说明协调员能在多半人反对的情况下强行推进到FA。--0xDeadbeef（留言） 2022年10月12日 (三) 13:34 (UTC)

我可以简单地说，判断共识的工作最后肯定会落到一个人手中，这一点几乎不太可能改变。协调员是负责判断审阅者之间的共识的，如果要多名协调员对“判断共识”达成共识，那如果协调员间产生不同意见，又由谁来判断协调员间的共识？再设立一个“负责判断协调员的共识”的职位吗？我不认为这样一层层下去是件好事，让协调员作为那个判断共识的人，就足够了。--BlackShadowG Slava Ukraini! 2022年10月12日 (三) 13:52 (UTC)

建设性提议

试行本就是为了摆脱空想看到底好不好，试行提案还要提修正案争吵的话实质上就是延续了空想，因此我建议下面的修正案可以跳过去直接按原案试行一次-有困扰的话，就让魔女用魔法帮你排忧吧！ 2022年10月26日 (三) 07:21 (UTC)

试行一次修正提案

鉴于上面有人强烈要求对这一次试行做出两点修订，特列如下：

1. 这一次试行改针对一次优良条目评选
2. 增加这一次试行的协调员数量为三人

如果大家都没意见的话我也就从了吧。 --MilkyDefer 2022年10月12日 (三) 01:01 (UTC)

虽然觉得三个人评选优良条目很搞笑，但是如果觉得这样有意思，我可以当一个协调员--0xDeadbeef（留言） 2022年10月12日 (三) 04:36 (UTC)

(－)反对：一人、FA比较好，如果从GA试行那还不如从NYK试行呢。--有困扰的话，就让魔女用魔法帮你排忧吧！ 2022年10月17日 (一) 06:01 (UTC)

(－)反对:

1.英维GA的共识制评审方式与FA完全不同，GA通常是一名审阅者主要负责审阅，其它编者发表意见；FA则是需要多名审阅者达成共识，显然在中维先试行FA的共识制评审更为合适。

2.一篇条目只需要一名协调员判断共识，理由已在上方回复。--BlackShadowG Slava Ukraini! 2022年10月12日 (三) 13:08 (UTC)

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

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

不建议改成GA试行，GA审议制是一名审阅者直接决定条目是否入选，不需要协调员。--BlackShadowG Slava Ukraini! 2022年10月17日 (一) 11:43 (UTC)

我觉得他可能想的是走出与英维不同的路子——GA审议，FA投票……--MilkyDefer 2022年10月17日 (一) 14:15 (UTC)

FA比GA标准更严格，却使用更宽松的投票制？怎么看都不合理吧。--BlackShadowG Slava Ukraini! 2022年10月18日 (二) 13:14 (UTC)

那把他召唤出来阐释一下吧@ATannedBurger--MilkyDefer 2022年10月18日 (二) 14:30 (UTC)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

“目前的投票制中审阅者不需要仔细检查条目就能入选”这点根本不需要我来举证吧，阁下觉得投下yesFA的编者一定仔细检查过条目了吗？再极端点说，一篇条目就算8名编者都没有看过条目投yesFA，条目照样能入选。

“FAC就机制上而言是没有问题的”这句话在大前提上就是不正确的，阁下认为FAC“没有问题”是说其“没有争议”，不用仔细检查条目当然没有争议。

至于您提到的共识讨论的一些问题（如协调员独大，可自行决定共识、有偿协调员而导致协调员和评审员狼狈为奸、各评审员因其理据不同而在决定共识中不享有同等地位等问题），我可以说，共识本身就伴随着争议，无论在互助客栈还是其它地方，只要有反对意见，争议就会存在，即使是让管理员来结案，也没法让所有人都信服。共识制FAC也是如此，有争议不是件坏事，这说明条目被仔细检查过才会引发争议，我也很乐于看到这种争议的出现。况且，有争议的条目其自身肯定也是有问题的，如果一篇条目收到大量的支持/反对意见，协调员再“独大”/“有偿”也没法改变既定的结果；真正会引发争议的只有那些支持和反对意见共存的条目，只有这些条目的结案会给协调员判断的空间，按照共识制的规则，这种条目通常会落选，在落选后的时间内，主编完全可以改善条目，把争议的问题去除再来提名，这是件好事。--BlackShadowG Slava Ukraini! 2022年10月21日 (五) 00:04 (UTC)

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

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

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

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

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

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

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

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

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

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

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

  可以考虑在评审的时候临时召集一两位熟悉相关领域条目编写的编者征取意见，就像你之前提到的，臭皮匠和诸葛亮的情况。常驻协调员要处理所有的评选条目，临时召集来的编者只需要在相关领域的评选出现时才来，协调员是投入（commit），其他评审含被召集人是参与（involve）。如果你要说会这个方向的编者只有提名人的话，其实在论文同行评审中最最冷门的方向也是差不多的情况。--MilkyDefer 2022年10月21日 (五) 02:20 (UTC)

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

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

  条目评审也不是搞得这么等级森严的吧？熟悉该领域的编者也不见得需要与其他编者要具有某种上下级关系；所谓的协调员，或者说，召集人，发出邀请让他们得知有他们可能熟悉的条目在进行评审。不见得他们就会成为听取下面普通评审员汇报工作的那种“主审”。但是他们的意见可以给协调员很重要的参考是不错的，有熟悉主题的人的认可的话，协调员做出判断也会更有把握一些；熟悉主题的人长期不出现的话，评审就会被拉长，要么更多普通人加入审阅提高置信度，要么这种“专家”出现。考虑到现在英维的FA最久的能拖三个月，可以预见这种事情会发生但是不太至于会导致灾难。FA评选数量本身就比较少，姑且是还能经得起这种延迟的。--MilkyDefer 2022年10月21日 (五) 14:54 (UTC)

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

  这个问题我不能替代社群回答。目前而言我是能接受的，我不能替代大家的看法。等其他人怎么说吧。--MilkyDefer 2022年10月22日 (六) 15:20 (UTC)

  我也能接受，FAC的所需时间的变长也代表着FA的评选标准以及条目质量的提高。再者，难度有哪家期刊同行评审几天就能完成的吗。--BlackShadowG Slava Ukraini! 2022年10月23日 (日) 02:27 (UTC)

  回覆一下兩個評論：

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

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

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

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

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

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

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

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

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

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

  那好啊，比中国人更看重人际关系以及读空气的日本人他们的制度又是什么呢？

  • 支持票通常都带上长篇大论
  • 投票持续最长三个月，特殊情况可延期一个月
  • 在上述期限内的任意时点达成“支持票三票且占有效总票数四分之三之上”的状态且持续一个礼拜即告入选。
  • 满足下列任意情况者快速落选：
    • 反对票至少三票且维持一个礼拜
    • 没有其他支持票且提名者撤回提名
    • 提名者是傀儡账号被不限期封锁，没有其他支持票

  现在论支持票是投一个yesFA走人，又说不能走讨论制度，两边都取不到好，真的要成文明洼地了。--MilkyDefer 2022年10月25日 (二) 05:19 (UTC)

  我不认为“沉默的反对”在FAC中是需要考虑的（无论是投票制还是共识制），既然对被评选的条目有意见，就应该在评选中提出来，既然无意提出自己的意见，就不应指望自己没提出的意见被纳入考量。协调员没有义务侦测出/发现各编者对一条目的见解，他们只需要依据提出意见的用户做出判断。

  鄙人不太认同共识制将形成另类如同互助客栈的辩论平台这一观点，共识制FAC不是正方与反方的“辩论”，且与客栈和RFA有本质上的不同。共识制FAC是反方指出条目不合标准的地方，让主编来改善，只要改善完成，再多的反对意见都可以解决，而不需要正方来“辩论”。--BlackShadowG Slava Ukraini! 2022年10月25日 (二) 10:23 (UTC)

  先回應一部分：

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

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

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

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

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

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

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

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

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

  繼續回應：

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

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

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

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

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

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

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

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

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

确实我们好像花了很多精力去解释可持续性的问题，但这跟仅仅一次的试行可以说是毫不影响。不过Temp3600说的也对，这次试行还是选择一篇相对熟悉的领域（对我而言是ACG与电脑）来审，而不是最开始设定的“无差别选择第一篇提交的条目”会不会好一些？如果试行的条目对领域存在限制的话，到时候我们就必须等待一篇相关领域内的条目提交到评选来，这个延时就不在可控范围内了。--MilkyDefer 2022年10月27日 (四) 10:14 (UTC)

那我们现在需要先决定选什么领域的条目吗？--BlackShadowG Slava Ukraini! 2022年10月28日 (五) 10:02 (UTC)

首先先决定要不要选特定领域的条目，再考虑选什么领域的条目。不管是ACG还是电脑技术哪怕是初等中等数学，被送上FAC都是稀奇事，说不定到年底都见不到一篇。--MilkyDefer 2022年10月28日 (五) 10:29 (UTC)

我觉得选不选特定领域的条目均可。不过如果需要ACG相关的FAC条目的话，我之前主编的最后生还者就是FAC不够票落选的，30天冷静期过去后我会重新提名，如果实在缺条目的话也许可以等这篇。--BlackShadowG Slava Ukraini! 2022年10月28日 (五) 10:48 (UTC)

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

关于试行一次的公示

已通过：

至少没有人反对要试一次，那就这么定了。MilkyDefer 2022年11月11日 (五) 12:44 (UTC)

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

---

总之，在将近一个月的讨论（辩论？）当中，大家都中途偏离轨道开始讨论制度的可持续问题。这不应该成为试行一次的blocker。 公示7日：

• 兹试行一次有效的评议制典范条目评选。
• 上一条当中的“有效”指的是，条目不满足快速落选准则，且不是典范条目重审。
• 选择的评选条目应该是在公示通过后，提交的一篇落于ACG范畴或是电脑、资讯科技范畴的条目。（简化挑选准则，因为保底会有一篇最后生还者进行第二次典范条目评审）
• 该次使用审议制的评选，其结果拥有与现行投票制同等的效力。即，若审议为入选，则条目获得典范条目资格；若审议结果为落选，则条目同样落选，30日冷静期同样适用。在社群的反对意见极大的时候，不排除入选的条目还要重新投票的可能（我希望这种事情不要发生）。
• 应该为该次试行开设评审专页，同时在典范条目评选主入口提供进入该次评审专页的链接。（完成→Wikipedia:典范条目评选/共识制试行）
• 该次试行的协调人为MilkyDefer。

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

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

  我其实没有读懂你这段发言的意思，尤其是与现在公示内容的关系。如果你要说存档的话，由于将要试行一次的典范条目评选是单独开设子页面，届时的“存档”就是将整个评选子页面移动到对应的位置，甚至无需移动页面，直接在{{Article history}}填写上正确的讨论页面位置就可。若能引入FACbot的话整个过程就是真的不需要人来干预了。就我做过的存档而言，存档过程很繁琐。用作移动存档的那个模板（我记得是叫{{移动存档}}吧）的使用晦涩不好理解，修改{{Article history}}也并非容易，这都拉高了参与存档工作的门槛。没有相应的操作指南，会的都会，不会的也不知道怎么学，所以会有积压。

  补充一下移动存档的门槛有多高。大家都知道被移动的存档都会有一行近乎是统一的提示：“本讨论移动自XXXXX，执行人XXXXX”。这是统一利用了{{移动存档}}模板达成的。但是，在使用这个模板的时候做的都是替换引用，因此从编辑后的页面源代码中是看不出讨论是如何被移动的。想要移动存档对不熟悉的人可以说是连门都摸不着。--MilkyDefer 2022年11月2日 (三) 13:38 (UTC)

  英维的en:User:FACBot就是专门处理存档的机器人，但是是共识制的，如果共识制的提案通过，也许可以引入这个机器人（原作者有公开源码，应该问题不大）。似乎目前的投票制也可能可以用机器人存档，不过这就需要请熟悉相关技术的用户来专门就中维的存档机制编写机器人了。--BlackShadowG Slava Ukraini! 2022年11月2日 (三) 14:19 (UTC)

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

  emmm我是说有没有一种可能，存档机器人可以设计成只有在协调员下令要求其存档的时候才会运作？谁下令谁负责擦屁股这种道理应该是很明了的吧？--MilkyDefer 2022年11月3日 (四) 02:24 (UTC)

  英维本来就是这样啊……--BlackShadowG Slava Ukraini! 2022年11月3日 (四) 10:27 (UTC)

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

  我不认为接触站务工作必须要跟机器人抢工作（当然我是说有机器人的前提下），而且中维有大量站务工作可以帮忙处理。--BlackShadowG Slava Ukraini! 2022年11月3日 (四) 12:52 (UTC)

  刚好可以跟隔壁存废讨论联动一下，担心存档条目评选这份站务工作会被机器人抢了的可以去隔壁存废讨论积压解决{{Follow-up}}标出来的，已经有结论但没人执行的事情。--MilkyDefer 2022年11月4日 (五) 04:54 (UTC)

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

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

  我个人认为要是这种事情真的发生了，那评审结束后我第一个要求回到投票制度。只有纯支持票跟投票有什么区别？反而还显得变成动态入选门槛。--MilkyDefer 2022年11月6日 (日) 03:35 (UTC)

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

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

  本人甚少参与站务讨论，恕难以给出建设性意见。站在主编者的立场，惟希望条目评选的流程简便顺畅为佳。--慕尼黑啤酒（留言） 2022年11月9日 (三) 08:30 (UTC)

---

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

试行期间的交流

• @BlackShadowG：你看现在辐射 (游戏)被提交至FAC了，能协助开一下评审专页吗？毕竟是你导入的那些个模板以及页面。 MilkyDefer 2022年11月12日 (六) 13:48 (UTC)

  已在维基百科:典范条目评选/辐射 (游戏)/存档1创建。--0xDeadbeef（留言） 2022年11月12日 (六) 16:56 (UTC)

  抱歉昨天没空上维基，感谢0xDeadbeef君开设评审专页，目前程序上应该是没问题了。--BlackShadowG Slava Ukraini! 2022年11月13日 (日) 03:24 (UTC)

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

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

  看起来阁下没有看到页面上方的Wikipedia:典范条目评选/共识制试行#意见交流：“请不要为简短的支持或反对意见创建分段，简短的意见只需标上*{{支持}}、*{{反对}}或*{{意见}}并附上您的观点即可。”，简短的意见可以不用开子章节。--BlackShadowG Slava Ukraini! 2022年11月14日 (一) 11:47 (UTC)

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

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

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

  页顶就有（“典范条目评选的协调员：MilkyDefer，可决定每个提名程序的时间”）。--BlackShadowG Slava Ukraini! 2022年11月14日 (一) 11:48 (UTC)

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

  评审期时长比较灵活正是共识制的优点之一，如果评审者比较多，各项标准很快就完成了检查，那么条目在几天内就能完成评审；如果关注的人比较少，则可以延长直到各项标准检查完。--BlackShadowG Slava Ukraini! 2022年11月14日 (一) 13:02 (UTC)

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

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

  目前是试行，所有由最初提议试行的MilkyDefer君自荐担任。机制正式上路后肯定会进行正式的协调员选举等。--BlackShadowG Slava Ukraini! 2022年11月14日 (一) 13:33 (UTC)

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

  正式实行前显然是会的。不过我不建议在试行阶段未结束时开启协调员选举，这容易分散社群精力。--BlackShadowG Slava Ukraini! 2022年11月14日 (一) 13:44 (UTC)

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

藝人參與綜藝節目列表

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

( π )题外话 吐槽 对于“罗列非固定班底综艺”的禁止性标准和清理，我个人不是很喜欢。如果内容不滥（比如每次必写、代言写全、溢美之词），参加综艺又存在一定的可说明的价值或重要性，我主观上认为有陈述和链接意义，对“构筑百科全书网络”也有帮助，有资料性价值，虽然时常踩在琐碎资料或原创总结的门槛。

SpeXial影视作品显然是WP:NOTIINFO了。“独立列表条目”难道是非琐碎资料、可供查证的“法外之地”？继维基语录、维基文库后，建立维基履历吧。^{[開玩笑的]}--YFdyh000（留言） 2022年10月13日 (四) 13:14 (UTC)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我觉得不能解决争议问题，是否从节目中发掘出独家价值/信息，然后表格改写为散文/备注，参演就变为值得保留。（虽然大多可能是一手或非独立来源）。对身份有影响又包括何种影响，首次参加春晚的集体节目（配角/参演），首次成为大型品牌代言人，首次公布履历或家庭或婚姻情况，首次回应争议，首次以某某身份参演，或者仅限可靠来源介绍提及的可达标（可能十不存一），如果来源只提“某节目”那介绍节目名又是否得当。“是否有助于读者/观众认识”不重要、“对于传主的身份有影响的内容”重要，对于散文是没错的，但对于条目仍不可避免的列表/表格式陈列，可能损其完整性、编辑争议频发。--YFdyh000（留言） 2022年10月20日 (四) 13:48 (UTC)

先逐個例子回應：

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

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

• 参加春晚等大型节目，对绝大多数艺人（同类参演小于3次），我觉得是值得提及列出的非琐碎事项（大型集体节目可能除外），对其人生和生涯也不能说低价值。简单以主持或固定参与判定琐碎，我认为仍不完善，且“主持”未必是节目重点、重要角色。
• 有粉丝参与的艺人条目，广告、代言等内容蛮多的，是否加入真不好说，我也觉得宣传意味很浓、很多该清理，例子。主要是“参与节目的收录标准应是对于其本身有影响”，粉丝加入代言内容显然是认为对人物本身产生影响，但我觉得大多没有，如此还是主观判断。其实“长期”、有知名度（独立有效介绍）的代言或许更重要。
• 正文为求完整，经常是时间+节目名+内容，那么同等内容的表格内容，是否就不算琐碎。是否节目含有新披露的“值得记载”的内容，就是讨论中的“对演艺人员的重要性”，这可能很模糊和广泛。
• 某某身份，我细化一些，比如某些粉丝、新闻或传记会称，加入某公司后的首部作品/首次出演某类型/首次以某身份参与制作，种种。再比如，知名演员早年的非知名作品/跑龙套，是否均是琐碎信息，但这有时存在有效介绍/对人物构成重要影响，是否有来源介绍就不琐碎。

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

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

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

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

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

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

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

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

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

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

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

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

同意分开处理。

单次大型节目的表演和主持有不少值得收录，谁谁上过春晚、红白经常是说一辈子的事。英维上不少特色列表都收录了歌手在Grammy表演的资料，正文也会提及。

多集综艺有一些也有收录的价值，如Saturday Night Live上的表演往往引起长时间讨论，成为表演者生涯中的重要事件。--Benevolen（留言） 2022年11月7日 (一) 21:41 (UTC)

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

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

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

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

我觉得可能需要WP:RSN那种集中讨论和列明标准的地方，不然就是主张删除和主张保留者在互列观点证据尝试说服对方（或者编辑战/放弃），而其他参与者不了解有讨论发生、无法感知标准。用客栈讨论也可以，但似乎容易话题变宽而最终无结论。--YFdyh000（留言） 2022年10月22日 (六) 18:54 (UTC)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

WP:格式手册有关百分数等的格式问题

現行條文 在反映一个具体数量时，国际计量局建议在阿拉伯数字与计量单位字母符号之间插入一个半角空格（例：0.1 cm、23 kg、45 °C、67 %），度分秒除外（例：89°、12′、3″）。

提議條文 在反映一个具体数量时，国际计量局建议在阿拉伯数字与计量单位字母符号之间插入一个半角空格（例：0.1 cm、23 kg、45 °C）。惟须注意百分数、角度、弧度、梯度等无量纲，不适用该条（例：67%、89°12′3″、$2\pi$、$0^{g}$），但弧度使用rad表记时除外（例：1 rad）。

现行条文对百分数的处理与常见用法不符，亦不合en:MOS:PERCENT；同时，弧度、梯度的情形需要补充。 --DvXg 📬 2022年10月15日 (六) 08:07 (UTC)

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

提及英维是因为西文是百分数如此表记的借入来源。如果这种建议既不合外语借入来源，也找不到相关的本语种标准，更不反映站内实际的使用情况（如百分数这个条目本身），那么这样的所谓“建议”显然是需要被修正的，否则任何误植的条文都可以用这一条辩护了。--DvXg 📬 2022年10月15日 (六) 15:19 (UTC)

如果您非要为这一条辩护的话，请自君始（您的用户页所上用的框就不符合这一规定）。--DvXg 📬 2022年10月15日 (六) 15:21 (UTC)

常见用法无异议、参考英维标准无异议。但是，应该查一下依据的标准和当初讨论。台湾國際單位制手冊第 9 版 (2019)第39页称“國際公認的符號%(百分比)可以與 SI 一起使用。使用時，應有一空格分隔數字和符號 %。”。The International System of Units (SI) - BIPM第37页为相同表述，"The internationally recognized symbol % (percent) may be used with the SI. When it is used, a space separates the number and the symbol %."，应是此项来源。en:Percent sign#Correct_style则详细提到了各语言常用的不同间隔风格。我觉得可以讨论条文是否要参照英文，依中文的实际情况和常见用法，允许或建议通常使用不符合该国际标准的规范，信息框、学术条目等领域又是否要例外。中国大陆的规范待查。--YFdyh000（留言） 2022年10月15日 (六) 15:43 (UTC)

感谢补充国际单位制的有关条文，不过台版标准第42页（PDF第46页）的“(10±0.01)%”像是自身亦不符本标准。另外，百分数本身并不由国际单位制定义，在数学教学中一般也不将其视作单位（如99%通常视若同0.99的数，惟更强调由比例导出）。

在数字排版领域，W3C起草中的《中文排版需求》内文实际使用的是无空格样式，其参考的已发布标准《日语排版需求》的3.1.10条e项则明确百分号前不加空格且不可断行，可做参考。--DvXg 📬 2022年10月15日 (六) 16:00 (UTC)

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

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

• 不明白第一项是什么意思，引文也应该遵循排版要求。不过我认同国际单位制的要求的确如现行。
• 现行条文并未明确“并用”，界定“并用”也缺少明确界限。这条提议算是要替代而非增补这条实际上（de facto）并未完全被中文（乃至CJK）接纳的关于百分号的国际计量局规定：在数字排版领域的可参考标准中，《日语排版需求》的3.1.10条e项明确百分号前不加空格，而紧随的f项就给出了“75.123 4 kg”的例子。原条文中的“在反映一个具体数量时”是具有一定排他性的，即使要另开一条也需要改动既有的这一条，当然（如果能够达成这样的共识）是需要再修订草稿，改变条文中指定的上游标准的。
• 原条文使用百分号的方式，在维基的环境中大约只有计算式的情形下会用到（如计算热机效率$\eta ={\frac {10\ \mathrm {W} }{20\ \mathrm {W} }}=50\ \%$）。可以考虑在正文（遵循数字排版规则）和公式（遵循国际单位制要求）环境下作不同的规定。

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

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

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

引用W3C标准是因为格式手册提及关于数字与符号配合使用的规定只此一处，抱歉可能因为提案中没有改动上游标准的引用造成了误解。我对您对SI标准的解释并没有异议，只是 (1) 站内外的实际使用都更接近W3C标准；(2) W3C标准更综合，其面向数字排版的特点也更适合维基作为网站的格式手册引用。我明白现在的提案还需要更改，但是希望能在再一次修改提案之前先收集对“是否应当明确一般正文中百分号使用时无前导空格”这一点的意见。目前提案修改的大略想法是 (1) 替换原条文，引用W3C标准指引正文格式；(2) 将国际单位制的“并用”适用于公式环境，明确其与W3C标准在百分号运用上的不同。--DvXg 📬 2022年10月17日 (一) 17:32 (UTC)

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

不对，您可能对《中文排版需求》所面向的领域有所误解。虽然这份标准由W3C旗下的兴趣组编写，但它所希望面向的对象是所有基于Unicode的数字排印，包括书籍印刷（如Adobe InDesign）、广告印刷（如Adobe Illustrator）、数字出版（如EPUB）等等，而非限于网页或者应用程序。其前辈《日语排版需求》，也是对JIS X 4051（日本語組版規則）标准的明确、细化与引导。虽然其对术语的使用有注意与CSS标准的相容性，但整篇标准事实上没有一处提到CSS、没有提到某项需求应当使用哪个CSS属性去实现，而是在总结中文排印的标准（事实上只有标点符号的使用部分有较为明确的明文标准）与常规。您说的

简单来说，如果你在排版上有特定的要求，比如说你想要直书，而非我们现在维基百科使用的横书，那他就会把这个需求列到排版需求中，来去看看网页标准怎样可以达到这样的需求。

这一点完全是不正确的，这篇标准的“需求”是对中文排印既有的实践的总结，而不涉及由谁实现、如何实现、在哪里实现。最明显的一处是，3.5节“行内调整”几乎所有的内容都无法用已经大致稳定、有实际浏览器实现的CSS属性实现，反而是同样草案中的CSS Text Module Level 4还在等待《中文排版需求》完成相关条文一并交由浏览器厂商参考。您在这个问题上完全颠倒了需求和实现（CSS）的关系。--DvXg 📬 2022年10月18日 (二) 09:44 (UTC)

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

续上，您说的“网页技术上”不实，整篇标准通篇没有说是仅面向网页排版，兴趣小组挂在W3C名下并不能说明这是网页专用的，其编写目的也有填补中文排印标准的空白的考虑，而非仅限于中文网页排版标准。我当然知道这篇标准不是像芝加哥格式手册一样涉及语法、大小写一类细则、对应维基MoS的格式手册，但“此处是否加空格”这个问题不同于大小写，它和“此处是否可以断行”这个问题结合得相当紧密，后者则是一个排印问题，这也是我引用这项标准的原因。当然，我也同意加入西文的既有格式手册作为参考能更有说服力，但我不同意您对《中文排版需求》乃至《日语排版需求》与格式手册的空格问题完全无关的论断。--DvXg 📬 2022年10月18日 (二) 09:58 (UTC)

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

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

我同意用格式手册做引据啊，第一条留言我就引用了英维的MoS，要换成上游“一手的”手册我当然也没有意见，但是终归还是需要一个搭得上边的中文的（或者CJK的）标准做补充“中文确实有在这么用”啊。--DvXg 📬 2022年10月19日 (三) 04:55 (UTC)

从一开始我就直接打算对标英维的MoS为准，有人异议我才拉了CLREQ出来做论据，为什么您一直觉得是我非要拉这个做标准？至于用哪个Unicode码位做空格原条文和提案都没有涉及啊，如果想明确用{{nowrap}}还是 阻止断行，这是要补充另一项条文了罢。--DvXg 📬 2022年10月19日 (三) 05:02 (UTC)

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

42页的考量与前文的关系？不太懂“跟计量单位（SI）字母符号并用”概念，国际单位制计量单位如何与百分比符号共用。--YFdyh000（留言） 2022年10月16日 (日) 09:34 (UTC)

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

啊，这处改动就是为了表示度分秒连写时不分开，您觉得这种格式不正确么？另外我确实认为百分比不是单位，但先行条文将其列出了，改为作为易于混淆的概念做出提示可能也是有必要的。--DvXg 📬 2022年10月16日 (日) 13:11 (UTC)

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

这处算是想要利用举例来间接明确更多格式上的要求吧，要明文明确也可以？另外，也许应当在MOS:DATENUM明确分和秒应使用Unicode的专用码位，不应使用西文引号代替？--DvXg 📬 2022年10月17日 (一) 17:37 (UTC)

(＆)建議用JavaScript或服务器后端解决，不管在源代码里输入32cm还是32 cm，都自动呈现成合适的样子。至于合适的样子是什么，可以另外讨论。--Gqqnb（留言） 2022年10月23日 (日) 09:11 (UTC)

如何达到条文要求属于implementation的范畴，不在方针讨论之列。MoS恰恰是要讨论什么是“合适的样子”。--DvXg 📬 2022年10月24日 (一) 09:36 (UTC)

修订提案

現行條文 在反映一个具体数量时，国际计量局建议在阿拉伯数字与计量单位字母符号之间插入一个半角空格（例：0.1 cm、23 kg、45 °C、67 %），度分秒除外（例：89°、12′、3″）。

提議條文 在使用带有单位的数字时，阿拉伯数字与计量单位字母符号中应插入一个空格建议在阿拉伯数字与计量单位字母符号间插入一个空格（例：0.1 cm、23 kg、45 °C、90 deg、1 rad）。 角度、弧度、梯度等单位不使用西文单词缩写符号时，不应插入空格（例：89°、$2\pi$、$0^{g}$），度分秒之间连写时亦无空格（例：89°12′3″）。 在一般的半角空格的基础上，推荐在此情形下使用不间断空格（ ），公式中亦可按LaTeX习惯使用窄不间断空格（\,）。 特别地，百分数具有两种通行格式： 据《芝加哥格式手册》及中文正文排版实际，百分数的百分号前无空格（例：50%）； 国际计量局的标准建议，当百分数与国际单位制单位并用时，百分号前应插入空格（例：质量分数$\omega _{B}=50\,\%$）。

根据意见进行了一部分修订，部分细则也许可以参照英维移入Wikipedia:格式手册/日期和数字并加以扩充？DvXg 📬 2022年10月29日 (六) 10:57 (UTC)

(－)反对，这是要有间隔，而不是要有空格。这应该是技术层面去解决的问题--百無一用是書生 (☎) 2022年11月2日 (三) 02:58 (UTC)

所有的西文和中文标准来源都用的是空格（space character而非spacing），您提出只是用间隔的依据是什么呢？况且我的提案反而是收窄了空格的使用范围。

中文和西文之间的间隔不用空格，是因为有相关的排版特性支持（Word的“自动调整中文和西文的间距”、CSS在实现中的text-spacing等等），而单位前的间隔据我所知没有任何一个排版特性支持，并且也不可能在没有语义支持的情况下完成（排版引擎如何分辨长度“100 m”和带后缀的编号“100m”？）。如果是想藉由模板完成的话，一是LaTeX的包siunitx最终实现也还是落到了空格，二是这对中维翻译条目的所有编者全篇改用模板也不现实，三是想要通过CSS的padding或margin实现的话是会影响行首行尾的正常排版的，不知道您中意的不用空格字符的解决方案是什么？--DvXg 📬 2022年11月2日 (三) 04:54 (UTC)

根据等效采用国际标准ISO1000：1992《SI单位及其倍数单位和一些其他单位的应用推荐》的GB 3100-1993《国际单位制及其应用》，其中也只建议数值与符号之间保留适当空隙，而未要求加空格。而从日常工作和中文期刊中遇到的书写要求经验来看，也未见有要求加空格的--百無一用是書生 (☎) 2022年11月3日 (四) 02:31 (UTC)

中文物理期刊确是普遍加空格的：物理学报、光学学报。赞同David Xuang君所言，单位前的空隙不像中西文间的间隔一样易于自动实现，加空格是实现标准所要求的“空隙”的最自然手段。--Lt2818（留言） 2022年11月3日 (四) 04:26 (UTC)

看了物理学报的投稿模板，并未要求加空格，而且发表的文章中（至少你提供的这篇）也是有时加有时不加。另我又看了一下《化学进展》的投稿模板，也未要求加空格，而且模板中自己也是有的有空格，有的没有。我认为中文出版物的这个现象可能是受英文出版的影响，但中文本身并无规定和习惯（至少在我的经验中都是不加空格的）；也可能是不同领域的学术习惯问题导致--百無一用是書生 (☎) 2022年11月3日 (四) 08:45 (UTC)

相反，我认为有时不加空格恰恰是母语为汉语的人习惯性的忽略单词间的空格，日常对话中即使在连用两个外来西文词的时候，人们也常常忘记中间的空格。私以为这里加空格的原因在于：阿拉伯数字作为语法上的数词，而单位缩写则是语法上的量词，两个语法成分不同的词自然不是一个词；数字的文种虽然“中性”，单位缩写则明显是西文，两者连用应视同插入的西文；那么，中文中插入的西文自然应当适用西文的书写规则。--DvXg 📬 2022年11月3日 (四) 14:17 (UTC)

两篇论文中，我看到的计量单位字母前都是有空格的，不知是否有遗漏的情况。《化学进展》的投稿模板里有空格和无空格都有出现（“8 cm×5 cm 以内”“宽度不超过8cm”），或许模板本身并不严谨，不及出版的论文成品有说服力。--Lt2818（留言） 2022年11月4日 (五) 05:35 (UTC)

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

这就是我之前问的最后一个问题啊，空格也好padding、spacing也罢，您钟意的实现方案到底是什么呢？--DvXg 📬 2022年11月3日 (四) 14:19 (UTC)

关于“反而是收窄了”，现行条文“国际计量局建议”，新条文“应插入”，语气是强化了。建议维持建议级别。--YFdyh000（留言） 2022年11月3日 (四) 03:19 (UTC)

完成，改动比较小，就直接用删除线改掉了。DvXg 📬 2022年11月3日 (四) 14:22 (UTC)

对“百分号前应插入空格”有异议。以例子中的“质量分数”搜索到这篇论文，未见百分号前有空格者。标准中的规定看似未被普遍遵守，我觉得没有写入格式手册的必要。简单处理的话，把百分号直接从条文中删除即可。--Lt2818（留言） 2022年11月4日 (五) 05:35 (UTC)

大陆GB 3100未见百分号相关规定，而之前讨论中有用户找到的台湾政府标准沿用了这条SI的规定，大概可以找找台湾的学术论文，或者是政府标准（比如计量、环境监测相关的）？--DvXg 📬 2022年11月4日 (五) 05:47 (UTC)

如果最后没有地区普遍使用的话，那么支持将百分号直接并入度分秒比照处理或者可以直接限定在非中文环境（公式）适用？--DvXg 📬 2022年11月4日 (五) 05:48 (UTC)

以“質量分率”为关键词搜索台湾的论文，一篇混杂无定章，另一篇只在图内出现百分号前空格，图外则百分号前无空格。--Lt2818（留言） 2022年11月5日 (六) 06:40 (UTC)

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

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

……那么中文排版的实践情况用什么引证呢，还是说条文内此处不言自明不需要引证呢。--DvXg 📬 2022年11月4日 (五) 14:20 (UTC)

另外反对“持续”的说法：这明明才是第二稿，而这处引证是第一稿这一点被人质疑之后才加进去的，之前你在意见中只表达了“这不是对应领域的标准”而不是“此文件不能作为对既有中文排版实践的参考”，这里也确实只是作事实参考而非标准引用，“持续在定案内容中”明显不实。要是只是不想把这个插进引用、只需要有讨论存档作参考那就直接提出来，不要这样虚增一顶“持续忽略其他用户意见”的大帽子。--DvXg 📬 2022年11月4日 (五) 14:31 (UTC)

另外，顺便再回应一下您之前提供的几份标准链接：这里存在的问题是缺“一般情形下中文对百分号的使用”的参考，而非“在SI体系下使用百分号”的参考，两者对百分号的处理事实上就是不一致的。您提供再多计量、技术写作方面的标准，也都只是SI标准的延伸。而百分号并不只在度量衡体系下使用，其最常见的应用——增长率，并不与SI所定义的物理量相绑定：人口增长率的单位“人”、经济增长率的单位“不变价美元”，都和SI的单位体系没有关系，这里需要的是中文传统出版、新闻传媒领域的相关标准（就像AP和NYT的格式手册）。--DvXg 📬 2022年11月4日 (五) 14:50 (UTC)

Lt2818方案

我提个修改方案吧，条文在Wikipedia:格式手册#空格。

現行條文 在中文語境內，文字之間應該不留空格，惟仍有特例： …… 在反映一个具体数量时，国际计量局建议在阿拉伯数字与计量单位字母符号之间插入一个半角空格（例：0.1 cm、23 kg、45 °C、67 %），度分秒除外（例：89°、12′、3″）。 ……

提議條文 在中文語境內，文字之間應該不留空格，惟仍有特例： …… 在反映一个具体数量时，建议在阿拉伯数字与计量单位字母符号之间插入一个空格（例：0.1 cm、23 kg、45 °C、1 rad），但度分秒（例：89°12′3″）、百分度（例：100g）之类符号除外。建议使用不换行空格（ ）以禁止在该处换行。 ……

说明如下：

• 删除“国际计量局”字样，其规范有未被普遍遵守的情况，格式手册不必与之挂钩。其他外部规范也同样不必写入。
  • 百分号就是个例子，百分号前是否加空格没有共识，公式内亦然，因此从条文中删除了百分号。
• “半角”指的是宽度，由于更窄的空格亦可接受（如前一提案提到了“窄不间断空格”），故而删去。
  • 从Help:数学公式可见LaTeX中使用“窄不间断空格”的场景远不止计量单位。如果要讲公式的话，另行单独叙述可能更合适，这里就不加了。
• 前一提案中的deg似乎不是中文里规范或普遍使用的单位（与rad不同），没有写入。
• 前一提案中“不使用西文单词缩写符号”的总括有些问题，百分度^g也可以说是西文单词缩写符号。我就用“……之类符号”代指了，没想到更好的总括短语。
• 度分秒虽然不是“字母符号”，但有必要体现出和前半句例子中“45 °C”的差别，不宜删去。
  • 从89°12′3″的连写足以推出三种符号单用时的写法，不必赘述。
• 行文字眼从“推荐”到“建议”，语气从强到弱。

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

由于具体用法和共识仍模糊，倾向保持“建议”而非“推荐”，以免出现争议时据此力争。其他暂无意见。--YFdyh000（留言） 2022年11月9日 (三) 12:48 (UTC)

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

如果最后只是取消百分号的空格要求也可以，毕竟事实标准也会成没有空格，不过条纹内“度分秒”前最好还是加一个“惟”之类的连词明确一下语义。--DvXg 📬 2022年11月15日 (二) 09:04 (UTC)

加了一个“但”，不知是否更好些。“惟”可能被理解为排他性，“但”作连词使用时只表示转折。--Lt2818（留言） 2022年11月15日 (二) 10:04 (UTC)

没其他意见的话就 公示7日。--Lt2818（留言） 2022年11月24日 (四) 04:19 (UTC)

持續出沒的破壞者記錄頁面

自從過往關於設立獨立LTA命名空間或私密維基的討論再度擱淺後，再無與持續出沒的破壞者記錄頁面相關的討論。然而，部分LTA記錄頁面的內容收錄混亂程度到無助於進行反破壞工作的程度，失去建立記錄頁面的意義；例如近期有用戶抱持「沒有規則說不可以」的心態在部分LTA頁面（1、2）列出大量曾受有關LTA破壞的頁面並聲稱用作連出更改監視，且在兩個舉出的LTA頁面中均無有效說明破壞模式。根據過往討論和經驗，我認為列出大量曾受影響不但無助於反破壞（基本上LTA都在看着自己的LTA頁面，列出來了不就知道不要去破壞那一個特定頁面嗎？）更可能導致模仿犯的出現（例如過往出現的攻擊性帳號破壞群）；跟管理員私下討論時管理員更是表示「不認識」，相信僅列出受影響條目而沒有充足（而不過多）的說明是完全無助管理員判斷甚或認知的。

雖然作為傀儡調查助理的職責，但在沒有相關指導下苦無執行辦法，且人非聖賢，自問並非熟知所有LTA的行為模式，無法單靠自己而進行清理，為免未來再有用戶抱持「規則沒寫」的心態而在反破壞工作上帶來反效果，建議在現有公開檢視的框架下新增關於LTA記錄頁面的編寫指導，並在年末前清理一下過往積累的（活躍）記錄頁面，以平衡反破壞和記錄過多資訊。

以下為英文維基百科WP:LTA頁面列出的注意事項：

英維條文 不要提供過多資訊 文本應在提供有用資訊和提供足以妨礙檢測的資訊之間謹慎平衡；一般而言此類資訊應僅與具有可信用戶分享。 有用資訊的提示 請考慮只記錄擾亂行為的性質和摘要、重要的提報頁面（SPI、AIV、ANM）和對有關破壞者過為模式和辨認方式熟悉的用戶名稱。 僅在有確實需要的時候進行記錄 請只記錄有確實需要進行辨認的案例，尤其是很可能被不熟悉其行為模式的用戶誤認為善意編輯的破壞者。此包括難以偵察到地操作傀儡、惡搞、推動非中立觀點和宣傳性質等行為；不需辨認為傀儡即可作純破壞用戶封禁的破壞者通常不需記錄。 小心用詞 不要使用任何可能美化破壞行為的用詞。不要使用空泛的相對時間詞如「近期」，應使用清晰用詞如「截至[日期]……」。

--路西法人 2022年10月17日 (一) 04:39 (UTC)

LTA:變身：「是一位會在影視作品條目添加與「變身」有關的擾亂性內容，或是在生者傳記條目捏造傳主逝世與暴力傾向的破壞者。」原來是無有效說明破壞模式，而LTA:A11早就說了，編輯傾向之後才要補上，可以繼續說謊沒關係。Special:链出更改/Wikipedia:持续出没的破坏者/User:A1111223、Special:链出更改/Wikipedia:持续出没的破坏者/User:劉濬瑜哪裡無助反破壞。收錄使用過的IP地址也意味著LTA也能看著過去IP不要去破壞那一個特定頁面，模仿犯也能透過LTA過往IP進行模仿，完全無關LTA頁面是否有列出受影響條目。別拿著沒有的規定打壓其他使用者，在反破壞工作上帶來反效果。--寒吉（留言） 2022年10月17日 (一) 05:46 (UTC)

2021年10月：Special:PermaLink/68145157（是一位喜歡在中文維基的影視作品條目加入偽造「變身」的破壞者。） → Special:Diff/68145166 → Special:重定向/logid/10921975 → Special:Diff/68191144（「閣下持續在不同條目增加與「變身」相關的不實條目」） → Special:Diff/68225264

2021年11月：Special:PermaLink/68760910（是一位會在影視作品條目添加與「變身」有關的擾亂性內容，或是在生者傳記條目捏造傳主逝世的破壞者。） → Special:Diff/68760919 → Special:重定向/logid/11028668。

原來這樣LTA:變身完全無助管理員判斷甚或認知。--寒吉（留言） 2022年10月17日 (一) 06:20 (UTC)

(－)反对，提案者並未說明是否屏除章節「使用IP位址」（Special:PermaLink/74046119#使用IP位址、Special:PermaLink/68952501#使用IP位址、Special:PermaLink/68068025#使用IP位址），在我眼裡章節「使用IP位址」與「受影響條目」同樣都能讓模仿犯進行模仿，而兩個章節都對反破壞均為有效資訊。LTA:變身有提供破壞模式與編輯差異（LTA:變身#參考資料）的情況下，仍被提案者刻意打壓、抹黑。--寒吉（留言） 2022年10月21日 (五) 06:19 (UTC)

反對者顯然在鑽牛角尖。IP地址可以偽造（VPN已經是很多網路使用者的基本常識），但模仿特定IP地址遠比模仿行為困難，上網隨便一搜都能知道，就算有一個列表的IP地址提供給你，完全偽造到準確落在一個特定的網路地址基本上是不可行（非不可能），可偽造的可能性微乎其微，此部分顯然為存在謬誤並無效的反對論據；而提案中錯誤提及其中一個LTA頁面沒有提供破壞摘要說明確實是我的失誤，我可以就此道歉，你可說我說謊、說錯，但絕不能說我打壓，過往社群的普遍意見（參考前幾次的LTA空間討論）也是規範和盡量限縮公開於站內的資訊。既然反對意見存在明顯謬誤，且留言剩餘部分就只是在對人非對事，故整體視作明顯無效的反對意見。--路西法人 2022年10月21日 (五) 11:00 (UTC)

模仿犯能透過LTA過往使用過的IP查看過去此名LTA的編輯傾向（編輯差異）進行模仿破壞模式，我可不是說模仿IP位址（「收錄使用過的IP地址也意味著LTA也能看著過去IP不要去破壞那一個特定頁面，模仿犯也能透過LTA過往IP進行模仿，完全無關LTA頁面是否有列出受影響條目」），你的提案即是對人不對事，就非得我投出反對票才打算要回覆我，我的個人討論頁也直接忽略不回答，這麼喜歡逃避，現在還直接說我的意見有謬誤而視作無效的反對意見，這就是打壓行為，自打巴掌。--寒吉（留言） 2022年10月21日 (五) 11:03 (UTC)

「用過的IP會被封禁，編輯過的條目會被保護，結果Wikipedia:持续出没的破坏者只能記錄使用過的IP，卻不能紀錄編輯過的條目，這樣會很矛盾，但無處有規定不能紀錄編輯過的條目」。所以為甚麼提案者只把章節「受影響條目」移除，不把章節「使用IP位址」也移除（Special:Diff/74124524、Special:Diff/74124518），兩者到底哪裡有差，而且LTA:變身與LTA:A11的編輯高機率都在過去編輯過的條目，在此兩個LTA頁面列出章節「受影響條目」幾乎不會常常出現如提案者所言噢，這些頁面被監視了，我去破壞別的，看你監視個寂寞，導致在LTA頁面列出章節「受影響條目」無助於進行反破壞工作。--寒吉（留言） 2022年10月22日 (六) 13:19 (UTC)

(＋)支持，考虑到部分现有LTA页面确实难以寻得有效信息并有可能招致模仿犯，我认为确实有必要规范LTA页面的编写规则。另，就私密维基事项，本人亦准备于此同时推进。（基于原先讨论，目前关于创建zh-lta wiki似已有共识，但对于访问权处于讨论状态，故我希望就此尽快推进访问权讨论）。--BureibuNeko 2022年10月17日 (一) 08:09 (UTC)

以一個最近才在學抓蟲的菜鳥來說，覺得列出被破壞的那些條目幫助薄弱，或許是想避免模仿行為，不過要一個個去找出差異、還要知道到哪裡找出來真心覺得累，若是有重點式寫出行為模式，對後進有心想要協助反破壞、或剛好遇上破壞的新人，能夠因此更快確認狀況。我的情形是看了好一陣子的通報，有前輩標註LTA，從而認識了有持續出沒破壞者。在更早的時候，其實不知道這樣的破壞行為，是要通報和可以回退的，曾經也只是當有趣，反應慢到後來才明白這有多大條。故若能有重點明確的行為模式紀錄，比起只是列出這個使用者破壞了這些條目，幫助會更大，也認同模仿行為會是個兩難，即使私人訪問藏起來或許好，但我還是喜歡維基百科全都攤開來不怕看只怕看不到，而且直球對決比較爽快不過呢都投直球了對方還自大到以為不是我就真的沒辦法了。對於持續出沒破壞者，有必要就用百科的方式建頁面，討論好收集的素材內容，百科不是省油的、自然有很厲害的方式解決，對吧是吧？--Mafalda4144（留言） 2022年10月20日 (四) 22:06 (UTC)

第四次提议LTA页面向私人wiki转变

是次提案基于先前关于申请制站务维基建立的讨论。

於Phabricator查看
編號T299590的工單

• 新的站务维基命名为：中文维基百科维护工作维基，zhwiki-maintenance-work（形如意大利语维基百科的sysopwiki，但是这个wiki的访问权不仅限于sysop）

• 新的站务维基的域名为：maintenance-zh.wikipedia.org

• wiki的访问权：傀儡调查助理、管理员（管理员）、回退员和其他经RFR申请得到访问权的用户。
• wiki访问权的具体获得方式：由申请者在RFR页面申请后，经任一已在wiki拥有账户的用户批准后（仿phab上Trusted-Contributors组），要求申请人向wiki管理员/wiki用户发送一封电子邮件以提供邮件地址，由wiki管理员或wiki用户注册账号。傀儡调查助理、管理员、回退员默认拥有访问权，无账号者仅需在RFR提出请求并向处理请求的向wiki管理员/wiki用户发送一封电子邮件即可，一般的，除非其被撤销过访问权，否则则不需进一步的讨论。

• RFR申请访问权基本门槛：已表现出有访问需要且有一定反破坏经验（可参考在VIP等页面的编辑）的可信延伸拓展用户或巡查员

• wiki需要启用的权限：跨维基导入者（zhwiki, meta） - 便于导入zhwiki LTA页面内的内容
• wiki需设置：$wgBlockDisablesLogin = true - 便于撤销访问权

除此之外，此wiki亦可以处理私有过滤器编辑讨论等问题（因为其访问权仅限sysop, rollbacker和部分可信用户）。

--BureibuNeko 2022年10月17日 (一) 08:09 (UTC)

過往討論中未曾提及站點管理員身份的部分，能否解釋一下刪除線的緣由嗎（雖然我沒想過要在設立站點之時就在本站管理員外提供進階權限）--路西法人 2022年10月17日 (一) 09:27 (UTC)

@LuciferianThomas：考虑了一下，基于访问者均为可信用户，wiki应该不会涉及过多需要管理员进行的操作（如保护、删除等），故此wiki并不需要过多管理员。BureibuNeko 2022年10月17日 (一) 09:31 (UTC)

同意，清楚解釋很好。不過那個刪除綫去掉比較好，不要誤導到別人了。--路西法人 2022年10月17日 (一) 10:32 (UTC)

好的。BureibuNeko 2022年10月17日 (一) 12:36 (UTC)

先纠正一个错误，目前私有站点可以设置$wgBlockDisablesLogin来阻止被封禁的账户登录，因此DisableAccount是不需要的（同时，这个扩展已经在prod被卸载了）。 Stang^★ 2022年10月17日 (一) 11:12 (UTC)

@Stang：好的好的，已经修改了，感谢提醒。BureibuNeko 2022年10月17日 (一) 12:36 (UTC)

根據當前描述，只有回退員可直接獲得訪問權，其餘用戶（包含傀儡調查助理、管理員、巡查員）均須在RFR頁面申請且「表現出有訪問需要且有一定反破壞經驗」才能獲得訪問權？雖然猜測只是文字敘述上的問題，但建議寫清楚一點以免爭議。另外，站點管理員如何產生？-Peacearth（留言） 2022年10月17日 (一) 19:16 (UTC)

感谢您的参与，关于访问权，“wiki的访问权：傀儡调查助理、管理员（管理员）、回退员、巡查员及其他经RFR申请得到访问权的用户”意思是傀儡调查助理、管理员（管理员）、回退员、巡查员不需要申请（或者仅需要向wiki管理员请求注册账号）且zhwiki管理员默认为wiki管理员，而其他人士需要在满足基本条件（“RFR申请访问权基本门槛：已表现出有访问需要且有一定反破坏经验（可参考在VIP等页面的编辑）的可信延伸拓展用户”）后在RFR页面申请。关于“（回退员申请方式如上，不过其除非已被撤销过访问权，否则可直接获得访问权。）”，那是之前默认傀儡调查助理也是管理员的，我忘删了，删了。--BureibuNeko 2022年10月17日 (一) 23:13 (UTC)

我看了讨论和前次讨论，仍未搞懂如下问题：一、现有处理方式有何不足？二、站务维基有什么用？三、设立站务维基的必要性在哪里？希望有人能够答疑。Fire Ice 2022年10月18日 (二) 06:26 (UTC)

“ “努力”破坏的人被社群“铭记在心、永恒流传”，还可以成为被“登载史册、正式收录”的对象，反倒对社群有贡献的善意用户随着逐渐淡出或离去，经过几年后，又有多少人或新进用户认识或记得他们曾经的贡献呢？这么说起来，是否破坏者破坏一阵之后，即可名留青史？善意的贡献用户还不见得可以轻易留名，就证明自己的“存在感”而言，当今的社群机制是否反倒在鼓励破坏者留名呢？ ” ——Kriz Ju

在此引用Kriz Ju一段话，私以为，增加LTA页面访问难度，使其仅限于真正想要学习与真正会做反破坏的人去查看（前者可以通过RFR申请，后者若非上述四种权限组成员，亦可通过RFR申请），从根本上打消部分愉快犯“留名青史”的目的，除此之外，站务维基可以使LTA不了解社群对这个LTA编辑方式的了解程度，从而尽可能的避免其见到LTA页面上有什么就避免做什么，从而可能使回退员认为其只是“好心办了坏事”的“编辑”而不能及时反应处理。

站务维基仅限于傀儡调查助理、管理员、回退员、巡查员和其他有一定反破坏经验的可信延伸拓展用户访问，基于这个条件，部分无法在zhwiki公开讨论的内容（如私有过滤器等）可以于此讨论，在此基础上，可以要求管理员在创建部分私有过滤器时先行于站务维基征求意见而后实行。

而以上内容实现的条件均为有一个仅供部分用户访问的私人空间，而基于T299546的回应，zhwiki并无法安装Lockdown组件，故实现的最好方式便为另辟新地。

--BureibuNeko 2022年10月18日 (二) 08:40 (UTC)

• (＋)支持能解決反破壞的一些目前無解的問題。-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年10月18日 (二) 09:03 (UTC)
• 支持，但我觉得有必要在本站留一些summary之类的东西，不能完全藏起来。 ——魔琴 [ 留言 贡献 ] 2022年10月21日 (五) 03:08 (UTC)

  有LTA:主頁啊。--路西法人 2022年10月21日 (五) 05:01 (UTC)

• (＋)支持 0xDeadbeef（留言） 2022年10月21日 (五) 05:27 (UTC)
• 所以此維基將含有什麼內容？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年10月21日 (五) 05:53 (UTC)

  除LTA空间内容外，还可用于讨论如私有过滤器等不便公开讨论的内容。--BureibuNeko 2022年10月21日 (五) 06:38 (UTC)

  巡查员不可看到私有过滤器，而且回退员是否应该看到仍有争议。 ——魔琴 [ 留言 贡献 ] 2022年10月21日 (五) 15:43 (UTC)

  已移除巡查员默认访问权限并允许其在自己不是延申拓展用户时可通过RFR申请。“回退员是否应该看到仍有争议”现在能看到对吧，那就不在讨论范围里。--BureibuNeko 2022年10月22日 (六) 03:08 (UTC)

• (－)反对，鴕鳥心態，不治根也不治本，大幅提升中維反破壞門檻。--寒吉（留言） 2022年10月21日 (五) 06:22 (UTC)

  @寒吉抱歉，但是可以请您说一下您为什么会认为“大幅提升中維反破壞門檻”吗？ 若是从LTA页面角度出发，这个维基并不会完全代替原有LTA页面，还是会留下能够判别的信息在LTA主页，只不过更多的描述被移动到wiki了而已，如果确有想法却受限于自己不属于上述用户组，可以在RFR申请访问权。私以为并不会提升反破坏门槛，而以最坏情况设想，也仅仅只是为zhwiki过滤了一批完全没有能力做站务的人而已。--BureibuNeko 2022年10月21日 (五) 06:42 (UTC)

  以上反对视作无效意见，因其未给出详细原因以促成讨论。BureibuNeko 2022年10月30日 (日) 08:03 (UTC)

  可悲。--寒吉（留言） 2022年10月30日 (日) 08:06 (UTC)

  @寒吉：不過您是否考慮詳細展開一下論述？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年10月31日 (一) 00:51 (UTC)

• @桐生ここ、30000lightyears、Emojiwiki、Temp3600、1233、Hehua、忒有钱、Xiplus，ping一下之前参与讨论者，若有打扰还请谅解。另请了解上另有对LTA记录页面的编写指导的讨论，亦欢迎参与讨论。BureibuNeko 2022年10月22日 (六) 03:35 (UTC)

  • 感谢邀请，目前没什么问题。

  --在下荷花，请多指教（欢迎签到） 2022年10月22日 (六) 11:37 (UTC)

• 還是老問題：在明顯有破壞者擔任回退員時，private wiki能有那些作用。--Temp3600（留言） 2022年10月22日 (六) 14:52 (UTC)

这不应该是private wiki方面考虑的内容，换而言之，这是现行回退员体制的漏洞而非private wiki的漏洞，wiki创建的根本目的是让LTA无法了解到社群对其的认知程度，然而有LTA混到了你维回退员就实在没有什么办法了，谁知道管理员里有没有，行政员里有没有，监督员里有没有呢？这个wiki并非鸡肋，反而还能在授予访问权前在进行一次复核。BureibuNeko 2022年10月30日 (日) 08:01 (UTC)

private wiki如果堅持「把房子蓋在沙土上」，自己也得擔起部分責任吧。再收緊訪問權倒是有用，問題是可以怎樣複核？--Temp3600（留言） 2022年10月30日 (日) 12:08 (UTC)

• +1 ghrenghren为此+1了。：雞肋，棄之可惜，食之無所得。--Ghren🐦🕑 2022年10月23日 (日) 06:47 (UTC)

  这也是之前我推这个提案的时候，一个重要的反对原因……我觉得如果不改革回退员，搞什么都没用 ——魔琴 [ 留言 贡献 ] 2022年10月23日 (日) 07:22 (UTC)

  既然你这么认为的话我还是有点想请教一下你认为回退员 1) 为什么要改革； 2) 改革后应该达到什么样子； 3) 如果可能的话，你想使用什么方式（包括修订方针指引，或者其他程序性改动等）达成你的改革目标。--MilkyDefer 2022年10月25日 (二) 14:24 (UTC)

---

• 考虑到多数参与者持支持意见，而其中两个质疑其中一个质疑仅仅表达自己立场而无法继续促成讨论，另外一质疑仅仅只是对本身wiki必要性提出疑问（且已经回复）而非对成立本身提出质疑。由于讨论趋于停滞而结合先前讨论，现 公示七天，至2022年11月6日止。BureibuNeko 2022年10月30日 (日) 08:09 (UTC)

在解決回退員問題以前，(－)反对成立所謂「LTA維基」。我覺得這不是可以隨意忽視的意見。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年10月30日 (日) 11:04 (UTC)

考虑到此前和现在有关回退员的讨论，个人认为有关“制度改革”的相关内容很难在近期达成共识。或许可以取消回退员对新wiki站点的访问权限，而成立一类似clerk的权限。--Yining Chen（留言|签名页） 2022年11月4日 (五) 23:31 (UTC)

• 基于上述讨论意见，暂撤下公示，讨论暂且搁置（不存档）至Wikipedia:互助客栈/方针#再提拆分回退員之私密過濾器源碼閱讀權至另一用戶組案讨论结束后。BureibuNeko 2022年11月12日 (六) 13:03 (UTC)

  (－)反对，沒有必要，認為除非維媒伺服器內存爆滿^{[開玩笑的]}不然根本只會搞的更加混亂，而且不違反WP:NOT吧？--想看看FK8438的傑作嗎？（點此續命） 2022年11月20日 (日) 09:53 (UTC)

註：此留言已被原作者（User:SunAfterRain）移除。2022年11月16日 (三) 15:02 (UTC)

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

Wikipedia:格式手册/日期和数字增加“常用的数学符号”章节

提议在Wikipedia:格式手册/日期和数字增加“常用的数学符号”章节，置于“注釋”章节前作为正文的最后部分，内容如下：

常用的数学符号

参见：Wikipedia:格式手册/数学

• 一些数学符号难以直接输入，可使用编辑器菜单插入，或代之以此处所列的HTML字符实体引用（形如÷）。
• 若需要以不同于普通文本的形式显示数学公式，可使用{{mvar}}（用于单字母变量）和{{math}}（用于复杂表达式）模板。更多方法详见Help:数学公式。

常用的数学符号

符号名称	符号	HTML实体	备注
加号/正号	+	+
减号/负号	−	−	大多数程式語言则使用連字暨減號（-）表示减号/负号。
正負號	±	±
乘号	⋅	⋅	与间隔号（·）不同。
	×	×
除号	÷	÷	另有斜線（/）常用以表示除法或分數，如1/2可表示一除以二或二分之一。
等号	=	=	调用模板时若省略编号参数的参数名（形如1=），参数值中的等号会被错误解析，写上参数名或使用{{=}}魔术字即可避免。
約等號	≈	≈
不等號	≠	≠
小于号	<	&lt;
小于等于号	≤	&le;
大于号	>	&gt;
大于等于号	≥	&ge;

修订的出发点是为了规范减号/负号的码点为U+2212 − MINUS SIGN，同时注明在编程语言中则多以U+002D - HYPHEN-MINUS为减号/负号。先前与A2569875君的讨论可供参考。

提议条文来自en:WP:COMMONMATH，做了些简化，主要是删除了对空格的约束。英文原文规定在二元运算符两侧加空格，站内则并未统一，如1 + 1 + 1 + 1 + …有空格，1+1无空格。W3C《中文排版需求》草稿2.3.5节中的数学运算符两侧有空格与无空格都有出现，搜索其他中文标准规范尚无收获。因此不贸然对二元运算符两侧的空格做规定。--Lt2818（留言） 2022年10月18日 (二) 15:26 (UTC)

(＋)支持。在下亦曾爭論普通文本的減號應該用U+2212 − 抑或U+002D - （甚至有編者用U+FF0D － FULLWIDTH HYPHEN-MINUS……）。認同使用前者並支持加入格式手冊。——$\definecolor {my}{rgb}{0.04,0,0.5}\color {my}{\mathsf {htc_{23}}}$（留言） 2022年10月18日 (二) 22:19 (UTC)

• 是否需要在「大部分的程式語言……」加註與維基編輯相關的部分，如「若因技術限制在模板或模組內部可以使用連字暨減號，僅需要令輸出於條目文字的部分為減號即可。」以讓先前討論的結果有反映在修訂案內-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年10月20日 (四) 05:21 (UTC)

  这部分不止和减号有关，与-对应−类似的关系还有*对应×、/对应÷，可能写一起比较合适，但没想到好的行文。（表格内只提了减号是因为只有-与−形状相似，容易搞混。）“僅需要令輸出於條目文字的部分為減號”仅适用于模板/模組的编写，适用面不大，个人感觉不必特意写进格式手册。--Lt2818（留言） 2022年10月20日 (四) 06:26 (UTC)

(！)意見：我支持可以納入並建議維基編輯在一般條目原始碼編輯中使用U+2212當作負號或減號使用，不認為"大多數程式語言則使用連字暨減號（-）表示減號/負號。"為全面的觀點描述，反對任何"要求編輯不應在一般條目編輯中將U+002D當作減號或負號使用"的論點，另外質疑目前似乎沒有叉乘號的說法，依照乘號的內容："名稱為「乘號」，亦稱作「叉號」或「交叉」"。--Anghualee（留言） 2022年10月26日 (三) 04:33 (UTC)

• “大多数程式語言则使用連字暨減號（-）表示减号/负号”是事实而非观点，语出en:Hyphen-minus#Programming languages。如果该事实描述尚不全面的话，欢迎给出增改建议。
  • 许多MediaWiki扩展、模板、模块等只接纳U+002D而非U+2212作为输入，个人认为这些包括在“程式語言”的范畴中，加之格式手册规范条目最终呈现的性质甚于源码编排，因此没把这一点写进提议条文。
• 个人认为根据使用场景的不同，U+2212与U+002D中只有一个是最合适的符号，难以想象有两可的场景。虽不必将另一种符号视为错误，但若有心者愿意调整为最合适的符号，自然是好的。
• 叫「叉號」或「交叉」就看不到乘法运算的含义了；“乘號”是包括了⋅和×二者的（参考），但我没找到两种符号并列时各自的常用称谓。如果没有更好的方案，权将二者名称合并称为“乘號”吧。

--Lt2818（留言） 2022年10月26日 (三) 12:00 (UTC)

• 然後 en:Hyphen-minus#Programming languages 引用了兩種程式語言的手冊，而裡面壓跟沒提 hyphen-minus，其中一個引用還被打上"頁數呢？"。事實是現代大部分程式語言的原始檔編碼都支持 Unicode，而用鍵盤打程式碼來講，打出U+002D比打出U+2212快太多了，工程師幹嘛要直譯器或編譯器額外增加處理一個大家都不用的U+2212？我就好奇有哪個打字訓練軟體要求你打U+2212而非U+002D了？而且就算你堅持那個是事實，說真的，也不影響。因為重點在於不夠全面，事實上一般使用（不限於程式語言）上 hyphen-minus 可以作為減號使用，就是 en:Hyphen-minus 一開頭引用了 Unicode explained 的論述，同時也是更為全面的觀點。
• 當然如你所說，在可使用選擇更完整的情況下，會有更合適的符號（畢竟 Unicode explained 裡面也是這樣認為的），所以我一開始就說我支持"納入並建議使用U+2212"。但是考量 Legacy 支援，根據目前鍵盤還沒有廢除或者是完全將 minus 完全獨立（畢竟有無數字鍵鍵盤），也就是對一般使用者來說，依舊會有採用連字暨減號作為減號使用的狀況，自然完全就符合 Jukka K. Korpela 撰寫的 Unicode explained 中所述這屬於 ASCII Legacy 支援的部分。同樣在一般新聞使用上（好比說這篇）也一樣會使用。考量到以上狀況，避免造成一般編輯上的困擾，所以我也提出了反對"不使用U+002D"的意見。
• 根據使用場景的不同，⋅和×中只會有一個是乘號。而照 Unicode 來講的話，⋅叫 Dot operator。--Anghualee（留言） 2022年10月26日 (三) 13:17 (UTC)

• 我自己接触过的程式語言全部使用连字暨减号，但en:Plus and minus signs#Uses in computing列了两种语言不用它表示负数。不觉得把“大多数……”这句话当事实呈现有什么问题。
• 维基百科使用Unicode，个人认为不需要在格式手册里描述仅有ASCII编码时该如何写数学符号，感兴趣的读者点进链接看就行。否则ASCII使用*/表示乘除，也要一并写入了。
• 我觉得做好Legacy支援与标明最合适的符号并不冲突，譬如重定向即是一个方面，-1可以重定向到−1。
• Dot operator的名称也看不出乘法的含义，且搜索Dot operator出来的许多是程式語言中的概念。Unicode的字符名称未必覆盖使用场景，甚至出错了都不改，“杭州码子”的命名错误即是一例。

--Lt2818（留言） 2022年10月27日 (四) 02:45 (UTC)

這倒提醒我了，你用的en:Plus and minus signs#Uses in computing段落裡面就有用/（U+002F），即便不作為除號使用，分數（en:Fraction）的部分也該提到⁄（U+2044）吧？至於Dot operator我也只是提一下 Unicode 是用此名稱（其實⋅也看不出乘號），我基本上只對叉乘號有意見，對點乘號其實沒講話，畢竟點運算子跟點乘號我還真分不出來哪個比較醜，你自己改回乘號然後糾結，這跟我沒關係的呀。其實跟 hyphen-minus 一樣丟到備註去就好了，只是你自己過不去而已。--Anghualee（留言） 2022年10月27日 (四) 04:32 (UTC)

把/写进除号一栏的备注里了。把⋅丟到備註仍然需要介绍其HTML实体，还不如现在这样。--Lt2818（留言） 2022年10月27日 (四) 07:22 (UTC)

点乘和叉乘 ——魔琴 [ 留言 贡献 ] 2022年10月31日 (一) 08:22 (UTC)

点积、叉积，名稱看起來僅指運算，而非符號。--Lt2818（留言） 2022年10月31日 (一) 15:36 (UTC)

有結論了嗎？-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年11月7日 (一) 03:57 (UTC)

公示7日。感謝諸位的意見。--Lt2818（留言） 2022年11月7日 (一) 09:21 (UTC)

• 這收錄標準實在是不一。請問比如說sigma、幾階、角度等，難道都不算常用的數學符號嗎？雖然(＋)支持，但是這標準看了顯然是不行。請問若通過，那後面的用戶能否自行擴充相關數學符號？都可以隨便舉例3個也算常用的了。--Z7504非常建議必要時多關注評選（留言） 2022年11月8日 (二) 16:02 (UTC)

  确实没有定一个客观的收錄標準，个人认为在非数学领域也常用的数学符号可以收錄。上述例子中，我觉得只有“角度”在非数学领域常用，不过现在表格里还没有单位符号。用戶能否自行擴充相關數學符號，就看其他用户是否接受吧。--Lt2818（留言） 2022年11月9日 (三) 03:10 (UTC)

• 公示期過了吧。公示期間的意見有有效的解決方案嗎？-- 宇帆:雪菲🐉蛋糕🎂⇔娜娜奇🐰鮮果茶☕｜在維基尋求休閒是否搞錯了什麼（☎️·☘️） 2022年11月18日 (五) 00:40 (UTC)

  没有。--Lt2818（留言） 2022年11月19日 (六) 11:56 (UTC)

  • 不然就這個先通過，若要加其他符號再另開新修訂案？-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2022年11月26日 (六) 05:37 (UTC)

    可以啊，格式手册先前已更新。我觉得收錄標準不是大问题。--Lt2818（留言） 2022年11月26日 (六) 16:24 (UTC)

关于WP:命名常规与WP:POV的冲突

算一个比较长久的问题，现时对条目命名最直接影响的WP:命名常规，并没有提及POV的问题，而WP:POV对命名的观点主要是这样：

“

一篇维基百科条目须有一个确定的名称。防止分列观点的普遍限制同样适用于条目名称。如果与条目主题相关的命名争议的确存在，这一争议应当出现在条目内容当中，并以可靠来源加以证实。此外，维基百科编者不能为了解决非中立争议而使用标新立异的条目名称。将条目名称分段并列也是错误的做法，比如“地平说的地球／地圆说的地球”或“地平说的地球 (地圆说的地球)”的形式都是不正确的。合成词也可能是不适当的，如“地球的形状”或“地球 (形状上有争议)”；特别应注意不能为了解决分列的观点而刻意杜撰新名词。

有些时候，条目标题本身可能便是争议与对立的来源。特别是当描述性标题所表明的观点“支持”或“反对”某一特定议题时。中立的条目标题是非常重要的，因为它能确保文章的主题出现在合适的上下文中。因此，百科式的条目标题应能表现出最高程度的中立性。条目可以在尽量少用感情词汇的情况下涉及相同的内容，或为了确保中立观点而涉及更多的内容（例如将“对毒品的批评”修改为“对毒品的社会观点”）。中立的标题鼓励多种观点以及负责任的条目写作。

当条目标题为姓名等专有名词时，可能出现的争议往往是应不应该使用某一特定名称。维基百科对此倾向于描述而非指定，应使用在可查证的可靠来源中找到的常见中文名称。如果对象是地理特征等没有生命的实体时，一般应使用中文出版物中最常见的名称。参见Wikipedia:命名冲突以获取进一步的指引。

”

。

然后，在讨论一个条目命名的问题时，我跑去看了一下现时命名常规的来源（大概是？），en的en:Wikipedia:Article titles，然后留意到是有对POV的说明，初步翻译如右（User:Cwek/工作室/关于条目常规的一些备存），大概意思就是两类：如果来源够多，即使看上去用词不中立的现在常用的名称，可以用；或者可以创建一个使用中立词语的描述性用语。POV在en关于命名的章节也初步翻译过（意见：大致相似，但有部分差异）。另外，也列出了部分涉及是否考虑POV的命名常规讨论。

所以，我们是否考虑在命名常规中考虑POV的需要？ ——Sakamotosan路过围观 | 避免做作，免敬 2022年10月20日 (四) 08:35 (UTC)

补充，en命名常规关于POV的说明，初步找到是2010年5月时的。——Sakamotosan路过围观 | 避免做作，免敬 2022年10月20日 (四) 08:44 (UTC)

@Ch.Andrew、Shizhao、Reke、Mewaqua、Gakmo：，提及一下Wikipedia_talk:命名常规/存档10#关于修改维基百科:命名常规的建议_2有参与讨论仍有活跃的。——Sakamotosan路过围观 | 避免做作，免敬 2022年10月21日 (五) 01:16 (UTC)

@Peacearth、蘇州宇文宙武、Happyseeu：，提及一下Wikipedia_talk:命名常规/存档11#提議：命名常規不應違反中立性原則有参与讨论仍有活跃的。——Sakamotosan路过围观 | 避免做作，免敬 2022年10月21日 (五) 01:18 (UTC)

@Chiefwei、Silvermetals：，提及一下Wikipedia_talk:命名常规/存档11#中文維基百科命名常規引起的問題有参与讨论仍有活跃的。——Sakamotosan路过围观 | 避免做作，免敬 2022年10月21日 (五) 01:20 (UTC)

我的理解，所谓描述性用语是指那些非专有名词类的条目标题，例如“对xxx的批评”，“xxx争议”，“20xx年xxxx事件”，这一类不太会在其他出版物中使用的短语。所以，“如果来源够多，即使看上去用词不中立的现在常用的名称，可以用；或者可以创建一个使用中立词语的描述性用语。”。在我看来二者并不是“或”的关系，而是对两类标题的两种规范方式（专有名词：常用，可以POV；其他的描述性用语：应当尽可能NPOV），是并行的--百無一用是書生 (☎) 2022年10月21日 (五) 02:18 (UTC)

@Shizhao：，这个问题，一来命名常规早就讨论过几次，二来是来源于西藏和平解放‎‎的问题，因为一直有编辑认为需要体现POV（或者是他们的主观“中立”），需要更换命名，但我认为根据现有命名常规并没有POV的要求，而且POV对于命名中有提到这类有争议的有专有名词的，可以跟随命名常规的常用性。按照现有规则，这个命名暂时不需要修改（满足命名常规的常用，处于争议状态下的最后一个正常命名，而且属于POV排除情况）。但考虑这些编辑对于POV的执着，我看了en的做法，留意到en对于POV是有这样的表述，刚好对应提及的两种情况：“西藏和平解放”是（可能）不中立的但常用，他们也挑选了“中国吞并西藏”（我认为可以选择更中性的“中国占领西藏”）符合中立的描述性用语。

如果考虑修正命名常规和POV（由于涉及专有名词部分应该是排除性条件），则可以考虑上面两个方案再选择合适的命名，如果不修正的话，则可以说明“命名常规不需要考虑POV，POV即使作为支柱之一是可以忽略的（而且它的确有一个豁免条件）”，那除非挑战“西藏和平解放”的常用性（用其他更好的可以量化的判断方法），否则以POV作为命名调整的依据是不成立的。

这个改动可能影响广泛，大量现时以中国大陆观点并且满足命名常规常用原则的条目，就都可以POV来挑战。——Sakamotosan路过围观 | 避免做作，免敬 2022年10月21日 (五) 03:14 (UTC)

可以加入說明，但我也同意如書生所言，應該沒什麼衝突。就我的理解是如果專有名詞本身帶有POV，仍以常用為主。比方說國共內戰的許多戰事都有雙方命名，各在兩岸為常用語，此時無論用何者為主條目命名都POV，而維基並不能自創一個NPOV的名稱。但如果是描述性的標題，就要儘量NPOV。--Reke（留言） 2022年10月21日 (五) 03:27 (UTC)

• 如果追求名称绝对中立，也许意味着命名忌用入侵等负面词汇（如同条目中忌用感叹号），不局限于中国大陆问题。广泛原创出不常用命名的后果，恐怕很糟。使用文献中最常见、广泛的称呼，并在序言阐明，应能应对大多数情况，也利于读者搜索和对应概念。
• ( π )题外话，偽滿皇宮博物院、伪满洲国交通部旧址等本身是事物专有名称（保护建筑）但同时是事物描述的条目命名，又是否要“中立化”。后者如果改掉条目名，序言写清事物名称就比较啰嗦了。前者改名等于原创命名或变更主题。
• 另应参考WP:NPOVFAQ、WP:YESBIAS，绝对中立的后果可能是，伪科学叫“未被主流认可的科学体系”。

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

@YFdyh000：，根据我对en对于命名对中立观点的表述的理解，应该分为“不中立但常用的标题”和“非判断性的描述性标题”，而后者的举例是“吸烟对健康的影响”等类似“XXX的影响”、“XXX的反应”等无实事物的虚概念的命名，应该是不带褒贬的判断。而前者就对应存在实事物、形成一个专用用语、并且被大部分文献来源使用的。所以偽滿皇宮博物院等是事物专有名称的，不是属于像“影响”、“反应”等虚概念的，就可以第一个观点。而且从zh对于中立对命名的表述，看上去也体现了这两个观点，但不如en在命名常规中具有明确可行的描述。——Sakamotosan路过围观 | 避免做作，免敬 2022年11月9日 (三) 04:49 (UTC)

基于西藏和平解放的问题，1.我们需要为命名常规和POV添加关联性；2.如何行文？因为命名常规的POV注意是在“常用”中提及并单独一章，而en的POV也提到只要常用，就算对于某些人来说是非中立的，或者POV，也是可以的；3.如果确立了命名常规和POV的关联性，这个个例这样使用？是用可能是非中立但常用的“西藏和平解放”，还是略常用、非中立、带有描述性（？）的“中國吞併西藏”，还是一般常用、中立、带有描述性的“中国占领西藏”？关于常用的搜索引擎检查，这里一个记录：User:Cwek/工作室/西藏。——Sakamotosan路过围观 | 避免做作，免敬 2022年10月21日 (五) 04:56 (UTC)

作为百科全书，应该考虑检索问题。可以常用名称优先，即使它很偏离主流立场；如果有多个立场相互冲突的常用名称，则“先到先得”，或者用{{NoteTA}}处理，禁止无故移动条目名称。至于标题名称的问题，可以放到导言里面去详细讲述。--高文海（留言） 2022年10月26日 (三) 06:31 (UTC)

WP:TITLE和WP:POV綜合理解說就應當是以通用兼描述性地標明相關稱謂，但基於WP:地域中心等系統的影響而言有關實踐並在本地議題是否完滿，包括結論本身是否合乎通行維基尺度而言是很難定論的。

如有關WP:VPD可能仍存有爭議之個別裁判所命名問題，在主推議案人限定以中文圈之地方法院潛在導致一統本地既有或未來所有裁判所命名情況，該如何判定相關引用基礎之中立客觀？唯一強調法則即如以單一時限之中文文獻優先，不考慮日文與中文長久相互貫通因素、且有關術語亦並非罕見而見諸於中文文本自身含專業層面，是以強調採編仍以一統使用中文地區命名而限制有關客觀中立立足之下，命名優先之選擇問題，恐並非基於使用是否廣泛或是否合乎通常認知、語文沿襲習慣等法，而全賴於當期主事強調之時所採用之壓制化路線是否得以成型而定。

個案而言，有關通行規則本身在部分個案內被單獨孤立依照其本身採編單一意向而孤立援引之時，在如既已有既定之非以合乎綜合材料觀點研判、非以合乎參議之時所通俗理解或通常使用邏輯知識，僅以如whataboutism及變相堆砌無異議之單一意向氛圍下而強調合乎一切所謂商議並自行定論，有關命名移動等皆已無可挑戰、是以相應社區及社羣實際並未有適切比例地落實到一直以來需要各使用者盡力之協作及適當參與等維基要義。

方針問題即在於實際採用之時，是為基於合乎方針背後維基核心之超越系統局限而顯維基多元及廣泛知識面，或基於與之相反路線，矛盾不加制約，則可繼續舊往。--約克客（留言） 2022年10月26日 (三) 07:39 (UTC)

具体问题

作为重要的的方针问题，居然没人关注，只能说太麻木了。

如果在不考虑具体个案的话，不需要具体的评论，我们应该怎样决定：

1. 是否在涉及条目命名的命名常规中，考虑明显地体现中立的方针，而且是两边都需要互相提及，如同en所做的？是或否？
   1. 如果否的话，那怎样在两个方针体现这个观点“命名常规不考虑中立性”？
   2. 如果是是的话，同样，怎样在两个方针体现这个观点“命名常规考虑中立性”。是否参考en的做法，在“常用性”中提到要考虑中立性，而且对于这种情况有“不中立但常用的标题”和“非判断性的描述性标题”两种具体的操作情况？
2. 如果还是保持沉默的，是否意味这维持现状：“ 命名常规没有明显地考虑中立的观点，但中立的观点对于命名上存在‘条目标题本身可能便是争议与对立的来源。特别是当描述性标题所表明的观点“支持”或“反对”某一特定议题时……因此，百科式的条目标题应能表现出最高程度的中立性。条目可以在尽量少用感情词汇的情况下涉及相同的内容，或为了确保中立观点而涉及更多的内容（例如将“对毒品的批评”修改为“对毒品的社会观点”）。’和‘当条目标题为姓名等专有名词时，可能出现的争议往往是应不应该使用某一特定名称。维基百科对此倾向于描述而非指定，应使用在可查证的可靠来源中找到的常见中文名称。’两种观点”？

以上。也请不要说一些打太极的话。——Sakamotosan路过围观 | 避免做作，免敬 2022年11月9日 (三) 04:19 (UTC)

與其說沒人關注，不如說話題「太大」，難以總結。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年11月9日 (三) 07:59 (UTC)

所以我举出en的说法。en是命名和NPOV都互相提及对方，然后作为影响命名最直接的命名常规就说明了如何操作。但zh只有NPOV提及到在命名中关于NPOV的问题，也给出两个方案的概要，其中一个方案还是指向命名常规的常用，命名常规没有提及。所以如果遇到条目命名中提及以“中立性”（或者NPOV的话）为理由，怎样操作？单靠每次的条目共识解决？或者遇到解释不清的问题怎样解决？而且这个问题不是第一次，我列出了好几次的讨论。

所以我认为，参考en的命名常规、NPOV对于命名的处理：NPOV提到不能制造分立观点式的命名、可以对于虚概念制造描述性命名、但专有用词常用的话就跟随常用，即使POV的；命名常规则提到两种命名方式，常用但不中立的命名和非判断的描述性命名，正好对应NPOV的第三、二点。zh的NPOV基本上对应en的NPOV的说法，主要是命名常规怎样处理，是否定或不认同NPOV，还是参照en的做法补充相应的说明？——Sakamotosan路过围观 | 避免做作，免敬 2022年11月9日 (三) 09:35 (UTC)

可以英語維基百科的Article_titles作為參考，擴充漢語維基百科的命名常規。 -- 月都 ※ 2022年11月14日 (一) 07:46 (UTC)

(＋)贊成Eric_Liu，難以概括地用於所有情況，通常以命名常規作為參考；維基百科的規則不只有中立的觀點，有些時候以含義或知名度作為參考，需要透過共識解決。 -- 月都 ※ 2022年11月14日 (一) 07:54 (UTC)

共识无法解决的话？或者说方针可能出现冲突时，讨论双方都自持方针为依据，怎样解决？en在命名常规和NPOV上的说明我认为足够合理并提供了可行的操作方案，但zh这边实在难以操作。——Sakamotosan路过围观 | 避免做作，免敬 2022年11月14日 (一) 09:33 (UTC)

誰在這個網站朋黨最多，本身時間最多，或是嘴砲最強，就能贏-- Jason22  對話頁 貢獻 2022年11月22日 (二) 15:55 (UTC)

再提拆分回退員之私密過濾器源碼閱讀權至另一用戶組

過往多次討論見Wikipedia_talk:防滥用过滤器#提议修改维基百科:防滥用过滤器。簡介:鑑於目前回退員中有內鬼，過往數年洩漏過濾器詳情，導致反破壞工作受到不少影響。此事亦進一步影響到回退員可否兼領其他權限(如LTA private wiki的閱讀權限)的質疑，導致反破壞權限改革無法推進。

為此，再次建議拆分回退員之AF源碼閱讀權(abusefilter-view-private)，以收緊其獲得人數。該新用戶組的成員應高度可信，且在反破壞工作中保持活躍。

請諸君討論。--Temp3600（留言） 2022年10月30日 (日) 12:24 (UTC)

個人傾向(＋)支持，但應該考量到之前提出的問題（如對過濾器並沒有那麼了解的回退員間接造成接觸到的資訊差異）。我是有想過一折衷方案（前提是技術上可行）：過濾器觸發時只截取出觸發的部分，而非顯示過濾器完整結構。這樣也能幫助看不懂AF是做什麼的回退員比較能夠理解觸發原因。--$\int$（☎）dt 2022年10月31日 (一) 01:50 (UTC)

哇你这想法有点天方夜谭诶，过滤器做不到这一点，或者说我就没见过哪儿有能展示这种信息的东西。GDB和LLDB我都没印象有这种工具诶（--MilkyDefer 2022年10月31日 (一) 02:09 (UTC)

如果连回退员都看不懂触发器语法的话，要这个权限有什么意义，还不如支持AF助理方法，让懂得人自己去检查或者协助修改AF。而且展示出触发的语法部分估计现在AF的实现根本没有这样的功能，还要mw开发组来实现（或者自己推修改补丁）。只能说有点异想天开。——Sakamotosan路过围观 | 避免做作，免敬 2022年10月31日 (一) 02:19 (UTC)

程序上极难实现，只能人工处理，那似乎等同条文上允许某种“查阅请求”。--YFdyh000（留言） 2022年10月31日 (一) 02:28 (UTC)

那算了（看到時全域有沒有這個需求、mw開發出來再說，原本只是想有沒有人寫個小工具就可以解決），就把abusefilter-view-private去掉就好。「另一使用者群組」可以考慮由回退員之間選出，之後由管理授權吧。--$\int$（☎）dt 2022年10月31日 (一) 03:49 (UTC)

(＋)强烈支持。--路西法人 2022年10月31日 (一) 03:31 (UTC)

(！)意見：上一次讨论进行了近四个月，最终也没能达成共识。“共识是可以改变的，但如果你要提出类似的提案，应该解决过去的反驳意见”（WP:常年提案）。个人想知道此次讨论较上次讨论有何变化？另外，似乎最近由过滤器详情泄露引起的破坏有所减少？--Yining Chen（留言|签名页） 2022年10月31日 (一) 05:53 (UTC)

上一次的討論一開始沒有考慮分拆，而直接將權限收回管理員，引起不滿；後來又因為ip masking導致困難重重。這次只處理核心部分，即AF分家。其他問題容日後再處理。--Temp3600（留言） 2022年10月31日 (一) 10:03 (UTC)

更改一下说法，IP masking方面问题不大。 Stang^★ 2022年11月11日 (五) 19:10 (UTC)

感謝補充，但仍建議下一步再處理此問題。--Temp3600（留言） 2022年11月17日 (四) 04:35 (UTC)

我記得上次諸位就是同意居多，問題似乎在技術阻礙？個人對此提議自然是(＋)支持。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年10月31日 (一) 07:27 (UTC)

上次是提到了phab:T309318。如果不考慮IP masking的話就應該沒事。 ——魔琴 [ 留言 贡献 ] 2022年10月31日 (一) 08:01 (UTC)

对建立反LTA类型的用户组无异议，但希望同期建立有效、便捷渠道或规则为可信用户处理相关咨询，如回退员的合理询问和建议，以解决部分用户的偶发需求。--YFdyh000（留言） 2022年10月31日 (一) 07:37 (UTC)

這方面我有一計，但暫時想不出要怎樣配合中維的情況來實施：強化维基百科:反破壞工作小組的職能，將建立為「反破壞專家」的公會。--Temp3600（留言） 2022年10月31日 (一) 14:42 (UTC)

能不能提出什麼具體議案或者說服力的理據，「彷彿劇團每隔一段時間重複演出同樣的戲碼」，我是比較無奈的。上次不是說要將IPInfo和IP masking合併到這個新的用戶組，然後就沒下文了。--Ghren🐦🕓 2022年10月31日 (一) 09:09 (UTC)

這次希望先解決目前的問題，IP masking目前還沒有起色，合併進來的話就搞不下去了。--Temp3600（留言） 2022年10月31日 (一) 10:03 (UTC)

之前的討論參考了YF君提供的意見，我提出的意見的確有捨本逐末之嫌。既然回退員主要工作是快速回退破壞，那麽側重點應當是對回退相關方針的理解程度至少可以讓社群信服做與反破壞相關的工作。而不是技術（例如私密濫用過濾器）能力，因爲其側重點無法保證回退員具備此種能力或與其相對應的操守。所以(＋)支持拆分權限。--紹💓煦^集思廣益 2022年11月5日 (六) 07:44 (UTC)

(＋)支持拆出Wikipedia:過濾器助理。--冥王歐西里斯（留言） 2022年11月5日 (六) 12:37 (UTC)

註：此處原有文字，因為LTA傀儡發言，已由路西法人於2022年11月27日 (日) 09:26 (UTC)刪除，尚祈見諒。若有異議請至互助客棧或向管理員反映。

感谢X43现身说法证明拆分的需要。--Ghren🐦🕙 2022年11月26日 (六) 14:48 (UTC)

名字與細則

過往的方案見Wikipedia:過濾器助理。歡迎各位討論。--Temp3600（留言） 2022年11月5日 (六) 17:25 (UTC)

• 我先建議：回退員不可自動兼任過濾器助理，需要獨立申請。--Temp3600（留言） 2022年11月5日 (六) 17:25 (UTC)

  這是自然，不然就失去意義了。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年11月5日 (六) 23:48 (UTC)

• (＆)建議由了解相关技术的管理员，WP:IA或WP:BAG对候选人进行基本的技术上的考核，如给定中文维基或其他维基上的某个公开过滤器，令申请者说出其大致工作原理，以确认申请者有理解过滤器的能力。--Yining Chen（留言|签名页） 2022年11月6日 (日) 04:38 (UTC)
• 為防再有內鬼獲權後潛伏，以減少被社群發現的機會，因反破壞而獲權者應在有關工作上保持活躍。我建議過濾器助理如三個月沒有參與反破壞活動，經舉報後可提早除權。--Temp3600（留言） 2022年11月6日 (日) 16:22 (UTC)

  三个月的活跃度要求和防泄漏应该说关系不大，有心人自然很容易让自己达到需要的活跃度。--Tiger（留言） 2022年11月16日 (三) 14:05 (UTC)

  的確如此。這條的原意是讓過濾器助理多與社群中其他用戶交流，令破壞者更難隱藏自身性格。看來未必可行?--Temp3600（留言） 2022年11月17日 (四) 04:37 (UTC)

• 另外，同意Yining Chen的建議，申請者應對REGEX有一定了解才來申請。--Temp3600（留言） 2022年11月6日 (日) 16:22 (UTC)

(＋)支持以上提案。--冥王歐西里斯（留言） 2022年11月7日 (一) 03:05 (UTC)

• 另外，建議本權限必須由當事人主動提出申請。--Temp3600（留言） 2022年11月15日 (二) 15:42 (UTC)

題外話

( π )题外话 如果有查看已删除页面的权限（browsearchive、deletedtext，deletedhistory不确定）或用户组，可能更方便某些任务（侵权、G5、破坏等历史页面的核查）。--YFdyh000（留言） 2022年11月8日 (二) 13:38 (UTC)

您是不是要找：WP:删除员，WP:维护员。^{[開玩笑的]}--Yining Chen（留言|签名页） 2022年11月8日 (二) 14:11 (UTC)

准确说，去掉删除/恢复权限的“删除员”。不知道社群是否有兴趣加在新用户组上。目前是通过WP:AR，但时效性不好。--YFdyh000（留言） 2022年11月8日 (二) 14:59 (UTC)

？？去掉刪除/恢復權限還算是什麼刪除員。--Ghren🐦🕓 2022年11月11日 (五) 08:45 (UTC)

你的逻辑是不是有点混乱？这也没说这是要启用删除员，这只是探讨一个与删除员类似，在具体权限上有所限制的<未知>而已。--MilkyDefer 2022年11月11日 (五) 12:42 (UTC)

所以我说的不是删除员，而是能查阅私有（非公开）记录的另一组权限，是否能合进去，参考蓝桌图书馆、已删百科等需求。已知新权限开放给高度可信用户，唯低于管理员。大多数已删除页面，只是出于维护，可能没有保密需求，需要保密的要监督。权限组可以命名如“非公开记录查看员”（Non-public record viewer）。--YFdyh000（留言） 2022年11月11日 (五) 13:31 (UTC)

你这个“非公开记录”很容易让人联想到真的要签字且具有法律效力而且大陆人不能签的NDA欸，你要不改个名字吧。--MilkyDefer 2022年11月11日 (五) 15:35 (UTC)

这是考虑到私有对应的private与“隐私”相同，担心误解。要不然，“私有记录查看者（Non-public record viewer）”，中英非一致译法。或者，进阶记录查看者，但表意很模糊。--YFdyh000（留言） 2022年11月11日 (五) 16:12 (UTC)

查閱員這個名字如何？可以查看AR，也可以查看過濾器。桐生ここ★[讨论] 2022年11月12日 (六) 04:19 (UTC)

很难，或者你需要让这个组拥有类RfA的授予标准（社群页面公布请求、不少于7天的投票云云）。 Stang^★ 2022年11月11日 (五) 19:10 (UTC)

建議先完成分柝，再進一步調整，避免再次流產。--Temp3600（留言） 2022年11月14日 (一) 02:37 (UTC)

最近不授予回退权是不是和这有关？Evesiesta 2022年11月27日 (日) 17:07 (UTC)

不清楚，但應該沒有關係。--Temp3600（留言） 2022年11月27日 (日) 18:53 (UTC)

初步方案

按舊稿修改了一份草稿:過濾器助理，請諸君討論。--Temp3600（留言） 2022年11月15日 (二) 16:35 (UTC)

题外话#2：全域的m:Abuse filter helpers就是「过滤器助理」，不知道为什么要翻译成「防滥用编辑器帮助者」，是时候正名一下了（叫全域过滤器助理？会不会误以为是「全域过滤器」的助理？） ——魔琴 [ 留言 贡献 ] 2022年11月15日 (二) 16:46 (UTC)

@Liuxinyu970226：還在嗎--Temp3600（留言） 2022年11月15日 (二) 17:14 (UTC)

赞成更名，“全域过滤器助理”挺好的。“帮助者”应只是粗译遗留。--YFdyh000（留言） 2022年11月16日 (三) 11:03 (UTC)

问题一：對比中維和英維的兩個過濾器助理頁面，英維是只有admin以上的用戶有abusefilter-view-private權限，那在中維，abusefilter-view-private的權限應該是像現在一樣，回退員也有，還是管理員以上的才有這個權限？

問題二：查看垃圾链接阻止列表日志這個權限在英維得是過濾器助理以上的用戶才有，但是中維只要是個User就有了，要不要調整之類的。一直不理解為什麼為什麼過濾器39、92是不公開的，但是黑名單的閱讀權限就放得這樣低。（這算是個無關問題，只是剛好看到而已）

問題三：启用双重身份验证有這個需要嘛？在我的眼中這不是一個很重要的權限，不一定要雙因素驗證。--Ghren🐦🕘 2022年11月16日 (三) 01:53 (UTC)

1. 英维的管理员数量多很多。讨论的不就是该权限从回退员移到低于管理员的新用户组吗。2. 不了解这个权限。3. 有一定必要，已知需求源自“潜伏”风险，而查看过滤器不留日志，可能难以感知账号被盗用？--YFdyh000（留言） 2022年11月16日 (三) 11:07 (UTC)

啊，抱歉，我看錯了。問題一應該是這樣：對比中維和英維的兩個過濾器助理頁面，英維是只有admin以上的用戶有abusefilter-log-private權限（查看标记为非公开的滥用过滤器的过滤日志），那在中維，abusefilter-log-private的權限應該是像現在一樣，回退員也有，還是管理員以上的才有這個權限？我複製的時候沒看清楚。不好意思。我想知道「查看标记为非公开的滥用过滤器的过滤日志」這個權限是也是收回，還是繼續保留在回退員上比較好。--Ghren🐦🕘 2022年11月16日 (三) 13:04 (UTC)

一起移入新用户组。--YFdyh000（留言） 2022年11月16日 (三) 22:05 (UTC)

現在完全沒有討論要取消回退員abusefilter-log-private權限。也看出不出這個方案打算這樣辦。過去共識看來也不打算這樣辦。那是否要重複給這新用戶組這個權限就是個問題。要从回退員手中收回這個權限，要更深的討論。--Ghren🐦🕚 2022年11月17日 (四) 03:36 (UTC)

本提案讨论的是解除回退员的abusefilter-view-private权限；英维也是User持有，为什么放的这么低请参阅gerrit:405670；“须有良好账户保安操守，例如开启双重认证（2FA）、设立高强度密码、电脑不受恶意程序感染等”。 Stang^★ 2022年11月16日 (三) 12:37 (UTC)

• 感謝各位的回應。「拆分回退員之私密過濾器源碼閱讀權至另一用戶組」指的是移除回退員的abusefilter-view-private權限，並邀請社群中仍希望保留該權限的用戶申請加入新用戶組。回退員的abusefilter-log-private權限不在本討論範圍，但由於新用戶組的成員可獲得log-private權限，該權限獲得人數將可能上升。--Temp3600（留言） 2022年11月17日 (四) 04:45 (UTC)

  方案草稿中“资格要求”的第六点，在实际实行中似乎很难做到。缺乏有效的方式证明某用户是否可信。--Yining Chen（留言|签名页） 2022年11月17日 (四) 11:12 (UTC)

  我看英維這一條也是自由心證而已，總之沒有人對這一點提出質疑就算是過關。--Temp3600（留言） 2022年11月17日 (四) 14:54 (UTC)

  显然是基于共识，消除合理质疑。可能需要如一周或两周的公示期。--YFdyh000（留言） 2022年11月17日 (四) 15:25 (UTC)

  确实缺乏有效的方式，共识制要求社群成员的绝大多数对于何为可信任有良好的认知，并有良好的说理能力。但我不认为我们的社群能达到这个要求。英文维基百科以我有限的观察也只能说是勉强达到。实际做起来，做还是能做的，但多少会把问题积累起来到以后产生比较大的麻烦。--Tiger（留言） 2022年11月22日 (二) 17:03 (UTC)

  坦率說，在中維上高度可信要求可能無法嚴格地執行。但考慮到目前回退員持有view權是"沒有要求"，本項至少能收緊一些限制，並為解除不適合者的權限提供法規上的支持。--Temp3600（留言） 2022年11月27日 (日) 16:55 (UTC)

  尚且不谈中维潜在的地区（组织）割裂（不信任）问题，假若将标准放得如此低，那么是否反面说明不可信用户（潜在的破坏者）也可顺利担任回退员？换言之，假若该方案能够实施，那么就根本没有必要另设权限，只要找到“社群成员”对当前回退员列表逐一审查，把所有“不可信用户”都移权+封禁，即可解决问题。又若模拟权限设立后的“公示”，那么只要现在开放一个讨论，所有用户都可在其中指认自己认为“不可信”的回退员，最后统一公示一段时间以后直接移权即可，完全没必要设立新权限嘛。如果在措施不完善的情况下贸然设立一个新权限，恐怕无益于反破坏问题的解决，反而不如不设立AFH权限，而由管理员代为处理源码阅读请求。--Yining Chen（留言|签名页） 2022年11月28日 (一) 11:12 (UTC)

  首先，目前已經有破壞者現正擔任回退員，這在上次的討論已經有不少用戶和管理員表達過。您所指的「排查回退員」方案，上次也有人提議過，但執行十分困難——部份回退員並不活躍，或已經退出一線反破壞工作多年，現行方針並無任何規則可用於解任他們，而且單憑猜疑，解任用權恰當但沒有參與反破壞工作的回退員在實務上也不可行。現行機制的弱點，正是破壞者可以先混到回退員，然後保持低活躍狀態，以此逃避反破壞小組的監視，而使用abusefilter-view-private權限亦無任何紀錄可查，導致無任何方法可以找出此等內奸。其次，直接由管理員查閱的方案上一次也有討論過（應該先上一次最先就是討論此方案），並已經被社群駁回。--Temp3600（留言） 2022年11月29日 (二) 14:39 (UTC)

  您所说的“单凭猜疑”解任回退员，与“单凭猜疑”拒绝AFH申请有什么区别呢？--Yining Chen（留言|签名页） 2022年11月30日 (三) 01:55 (UTC)

  拒絕AFH申請的主要原因應是「用戶不符合資格要求」，即身為回退員但未有在反破壞工作中活躍；自稱將維護AF但沒有兌現承諾等。這些都是客觀的理由。至於分別，則在於AFH與回退員所需的信用等級不同。回退員如無法取閱敏感資料，則其權限可造成的破壞十分有限，要求先有違規行為後再解任依然合適；但AFH可以取得敏感資料，且缺乏監察途徑，即使沒有過違規行為，仍有可能不適合獲權。--Temp3600（留言） 2022年11月30日 (三) 03:25 (UTC)

  那么该如何处理地域问题呢？作为例子，2022年9月管理员选举中有两名候选人被质疑“與WMC關係千絲萬縷”“前與WMC的關係緊密”“WMC仍潛伏於社羣中”，可见某些人至今仍不能做到对WMC成员在处理隐私信息（广义）方面的基本信任。该如何才能确保此类偏见在AFH的申请过程中不会出现，并且不会对申请过程造成干扰呢？或是说AFH权限不接受WMC成员（即大陆用户）的申请？--Yining Chen（留言|签名页） 2022年11月30日 (三) 05:22 (UTC)

  另设用户组仅是遵循最小权限原则。对于双面人问题，目前权限机制（无日志）不能解决，要依靠其他方法。--YFdyh000（留言） 2022年11月30日 (三) 07:05 (UTC)

第一階段公示：確認分拆

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

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

提议DYK允许使用陈述句。

理由如下：

1. 一些编者为了让答案唯一而硬凑问题，叠加多个条件，导致问题变得非常冗长。
2. 一些问题根本没有吸引力，无法吸引读者点击，不如直接把答案展示出来。
3. 一些事实本身已经足够特殊，但是因为答案不唯一而不得不继续叠加一些其它条件，或者使用「除了……之外还有」的方式排除其它答案，这些都降低了可读性，不如改为陈述句，使用「最……之一」的用词。

举例：

1. Talk:開基天后宮，原问题为「臺灣府城唯二建於明鄭時期的媽祖廟除了大天后宮外還有哪一座媽祖廟？」我认为完全可以改为「开基天后宫修建于明郑时期，是台湾最早的妈祖庙之一」。
2. Talk:镭，问题为「除了钋以外，居里夫妇还发现了哪种化学元素？」存在更有吸引力但是答案不唯一的事实，例如「镭元素具有强烈的放射性，但是却曾被用作发光颜料。」
3. Talk:梼杌剑虎属，为了保证答案唯一而叠条件「并且是“半剑齿虎属—勇剑虎属—锯齿虎属”演化过程中产生的一个旁支」，导致问题过于专业化，欠缺对读者的吸引力，如果允许使用陈述句，就完全可以改成「2021年新发现的剑齿虎梼杌剑虎属的名字来源于中国古代传说中的凶兽。」
4. Talk:中华人民共和国机动车行驶证，完全可以改为「机动车驾驶人在中国内地驾车上路时必须随身携带机动车行驶证」。

--——🦝英特浣熊耐尔_{（留言・贡献）} 2022年11月2日 (三) 10:06 (UTC)

(＋)支持，每次都是绞尽脑汁想问题，好像在问题上花的时间比条目本身都要多了。-- B-MIKE -留|签 2022年11月2日 (三) 17:20 (UTC)

特别提示：过去曾经有过如下讨论：“提议调整新条目推荐问题指南时效性描述（暂时性折中方案）”，该讨论围绕DYK的时效性进行，并在中途有至少AT明确表示要求改革，而Temp3600等人也没有对其表示反对。魔琴表示过“不是很支持废除提问”但也不知道理由。我个人希望这次讨论不要再绕回“时效性”的老问题上画圈。 --MilkyDefer 2022年11月2日 (三) 14:01 (UTC)

(＋)支持，DYK问题过于苛刻，有些真的很丢吸引力。还有，什么都要加个「截止到某年某月」，很无聊，不写的话不就默认截止到现在吗？「中国历史上唯一的女皇帝是谁？」这个问题，在705年发表和在2022年发表又有什么区别？ ——魔琴 [ 留言 贡献 ] 2022年11月2日 (三) 12:33 (UTC)

您没有考虑万一将来中国大陆重新称帝的情况啊，怎能这样写啊。啊，怎能写到某年某月呢，万一明天就过期了得怎办呢。--Ghren🐦🕘 2022年11月2日 (三) 13:32 (UTC)

当你在按月份查看过去的新条目候选存档的时候你就应当已经知道这个DYK项目的有效时间点了。 --MilkyDefer 2022年11月2日 (三) 13:42 (UTC)

過往發生過有問題在首頁展示途中還未下架就發生「現在」已經失效的情況，所以才有這個要求。另外注意主題首頁的DYK存檔是不記時間的。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年11月2日 (三) 14:07 (UTC)

有按日存档的（Wikipedia:新条目推荐/供稿/2022年11月1日），只是Wikipedia:新条目推荐没有这样按日列举，可以参考英维的对应页面那样按天划分。如果是担心问题还未下架就失效，那能确保在短期（甚至只需要一天内）有效就行，何必需要永久呢。--BlackShadowG Slava Ukraini! 2022年11月2日 (三) 15:03 (UTC)

我想上次已經有說過，我們不能確定一個條目在哪一天登上首頁和Portal，以及一個條目會展示多久時間（Portal那邊試過有DYK條目放在首頁三年），所以确保在短期有效的可操作性不高。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年11月2日 (三) 15:10 (UTC)

算了这个时效性可以以后再谈，反正多几个字观感不会很差，重点是解决陈述句的问题。 ——魔琴 [ 留言 贡献 ] 2022年11月2日 (三) 16:12 (UTC)

(＋)支持，一个条目或多或少会有一两个所谓可以放上来的“冷知识”，但未必能问出问题来。 --MilkyDefer 2022年11月2日 (三) 13:42 (UTC)

我認為時效性還是要考慮的，不過就簡單加一個限制條件。至於廢除強制提問格式，倒是沒什麼意見，不過還是建議能提問就提問吧。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年11月2日 (三) 14:14 (UTC)

(＋)支持废除强制提问格式，我也常常不得不为一篇想不出有什么特别的条目硬生生地提出个根本没有吸引力问题，确实很没意义。不过需要(※)注意陈述句和疑问句并行可能导致读者观感不佳。--BlackShadowG Slava Ukraini! 2022年11月2日 (三) 14:37 (UTC)

• 建議"你知道.....嗎?"的偽裝型陳述問句。--Temp3600（留言） 2022年11月2日 (三) 15:50 (UTC)

  也许中文不好操作？读起来会有点怪。 ——魔琴 [ 留言 贡献 ] 2022年11月2日 (三) 16:15 (UTC)

我未见这些陈述句比原问句更有吸引力和趣味性，甚至可以说吸引力和趣味性几乎是不存在的。Fire Ice 2022年11月2日 (三) 16:45 (UTC)

• (＋)支持，終於有不少用戶覺得DYK一定要使用問句提問是很麻煩的了嗎？看誰以後還要提議把「新條目候選」更名為「條目候選」吧。這種早期中文維基百科的DYK制度真的該改改了，要不然以後還是都只能「截至某個時段為止」、「是哪個」等問句的問法。不過，也不應該說以後問句的問法就要廢除，這類陳述句的題目還是要有一定邏輯才行。還有，請問DYK題目的答案還要保持唯一性嗎？如果是，那就實質上來說還是沒有改革，到頭來就是美意打折扣而已。為何要確保DYK題目的答案唯一性呢？有不少名稱都有多種說法，憑什麼只能是其中一種說法當DYK題目的答案呢？也已經強調到爛掉不想說了，以後還想寫出「條目候選」的難度只會越來越難。因為條目都被前面的人寫去了，請問後面的人是要寫什麼？幾乎沒有東西了啊。這個獨裁社群倘若再不認真思考改革「條目候選」，也沒什麼人願意要寫維基百科了。因為若基本想要查詢的信息都可以在維基百科查得到，那樣哪還有寫「條目候選」的必要呢？更別提有時還因為沒有足夠支持票而落選DYK的不佔少數，呵呵。要不要鼓勵人拉票呢？獨裁社群仔細想過吧，「新」一字真的該廢除了。--Z7504非常建議必要時多關注評選（留言） 2022年11月2日 (三) 17:35 (UTC)
• (～)補充：講一個「條目候選」很明顯的例子：

“ 由羅伯特·R·布萊克和簡·莫頓于1964年共同建立的哪种風格模型理論划分出五种不同的領導风格？ ” ——管理方格理論的「條目候選」題目

答案：「管理方格理論」。那到底是為什麼就不能開放其它也是正確的答案（管理格道、五分式領導）當作「條目候選」的答案呢？難道還要執著「DYK題目的答案唯一性」嗎？--Z7504非常建議必要時多關注評選（留言） 2022年11月2日 (三) 17:40 (UTC)

• 我觉得明文允许一般陈述可能降低吸引力，显得乏味，但应明文不禁止非设问句，既指引级效力，DYK讨论认为可以就可以。前缀“你知道吗”也可以考虑，不过首页的标题处本来就有。时效性有意义但应注意常识。--YFdyh000（留言） 2022年11月2日 (三) 19:32 (UTC)

  前綴也不用總是牽強，一定要使用「你知道嗎？」吧？「你知道嗎？」是種問句，然後問句的後面居然可以不用問號結尾，不是很奇怪嗎？「條目推薦」或者其它更好的名稱難道不好嗎？這種「條目候選」真的是悲哀，不一定是合適的長久之計提案。「新」一字居然從來都不考慮廢除，以後的用戶真的會越來越難寫條目。--Z7504非常建議必要時多關注評選（留言） 2022年11月2日 (三) 19:53 (UTC)

  对于“新”，如果不考虑鼓励扩充和时事，或许首页放些条目评选或当选的轮转也不错。--YFdyh000（留言） 2022年11月2日 (三) 21:57 (UTC)

• (＋)强烈支持開放使用陳述句，另外再次重申支持取消時效性要求。--Wikimycota🧬 2022年11月3日 (四) 00:10 (UTC)
• (！)意見，看了眼en，似乎允许陈述性问句，类似“秃鹫号巡洋舰曾经在美国海军服役？”但我不建议过度使用陈述句。因为这是“DYK”，“Did you know”，“你知道吗”，正是这样的抛包袱问句来作为吸引读者注意的作用。过于平铺直白似乎失去了作为DYK的有趣点。对于时效性，由于这个问题需要存档等因素，我认为还是需要保留或者能以提出时为基点确认到答案。——Sakamotosan路过围观 | 避免做作，免敬 2022年11月3日 (四) 01:07 (UTC)

  BTW，居里夫妇共同发现的化学元素，根据条目的描述，除了钋，就是镭。这个答案唯一。而“机动驾驶证”那个如果用问句方式也可以表述为“机动车驾驶人在中国内地驾车上路时必须随身携带哪种证件？”——Sakamotosan路过围观 | 避免做作，免敬 2022年11月3日 (四) 01:11 (UTC)

  后者设问答案不唯一，需注意条目是行驶证而非驾驶证。另外，“随身携带”定义含糊（随车携带、电子行驶证、离车时是否携带）、似非法律明文规定，不算完美。--YFdyh000（留言） 2022年11月3日 (四) 01:46 (UTC)

  我认为提问的方式是很好的，只是目前非要把条目藏起来，什么条目几乎都是“哪个xxxx？”以上面举例的几个来看，完全可以这样提问：

  • 开基天后宫修建于何时？
  • 化学元素镭是谁发现的？
  • 2021年新发现的剑齿虎梼杌剑虎属的名字来源是什么？
  • 机动车驾驶人在中国内地驾车上路时需要随身携带机动车行驶证吗？

  不要拘泥于某一种提问方式就好了--百無一用是書生 (☎) 2022年11月3日 (四) 02:43 (UTC)

  我觉得这样不错，要问的不拘泥于条目标题，可能还更有吸引力。--YFdyh000（留言） 2022年11月3日 (四) 03:20 (UTC)

  同觉得这样不错。——Sakamotosan路过围观 | 避免做作，免敬 2022年11月3日 (四) 03:39 (UTC)

  这种想法很好啊，特别是「梼杌剑虎属」一问，比藏条目问题、陈述句效果好多了。不过对于「開基天后宮」，问「修建于何时」似乎没有「是台湾最早的妈祖庙（之一）」的效果来得好…… ——魔琴 [ 留言 贡献 ] 2022年11月3日 (四) 04:07 (UTC)

  (▲)同上附议。--DvXg 📬 2022年11月4日 (五) 06:50 (UTC)

为何不能问：管理方格理論是谁建立的？--百無一用是書生 (☎) 2022年11月3日 (四) 02:47 (UTC)

也就是說，不將新條目推薦問題之主體限定在條目本身，而是條目之內容亦可，對吧？我同上面幾位持類似看法，覺得這是一個不錯的形式。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年11月3日 (四) 03:58 (UTC)

確實可以這樣問，但此時問題可能就要變成整條都要藍連了。即：「管理方格理論是誰建立的？」--Z7504非常建議必要時多關注評選（留言） 2022年11月3日 (四) 05:12 (UTC)

不隐藏条目名就只链条目名，才对吧。--YFdyh000（留言） 2022年11月3日 (四) 05:27 (UTC)

管理方格理論是「由羅伯特·R·布萊克和簡·莫頓於1964年共同建立的領導風格模型理論」，如果要用同樣這個問題套用在這兩位上，請問該用羅伯特·R·布萊克還是簡·莫頓做答案才對？還是兩個同時上去？雖然知道這兩位不大可能被提名「條目候選」，但這樣顯然就已經不符合首先提過的「DYK題目的答案唯一性」了。--Z7504非常建議必要時多關注評選（留言） 2022年11月3日 (四) 05:35 (UTC)

没有强制用陈述句，只需“谁与某某一起创建了……”（嫌短可改成“哪位xx学家）。同时登上，顶多是谜底在谜面上，而且设定type参数似乎能避免此情况？--YFdyh000（留言） 2022年11月3日 (四) 06:00 (UTC)

(！)意見：如果允許不隱藏條目名稱的問句，那麼將有可能出現同一條問句但可以被兩個條目使用的情況，例如：

• 化学元素镭是哪位物理學家與他的妻子一起发现的？
• 化学元素镭是哪位物理學家與他的妻子一起发现的？

如果兩個條目同一時間參加評選，不怕在評選時會混淆投票者嗎？（例如投票者本來想投給鐳，但因為看錯了相同的問句而投錯給皮埃爾·居里）另外反對取消時效性，除非首頁隨時失效的問題有完美解決方案。--Maccomcre（留言） 2022年11月3日 (四) 05:04 (UTC)

您漏掉了，如果他的妻子也有知名度，也是可以參選的。如果要反對時效性用法，真的就是所謂的沒有改革結案而已，一點意思也沒有。總之，「條目候選」的問題本身就一大堆。「羅馬不是一天造成的」，如果想要認真改革「條目候選」那就仔細想清楚吧，否則以後這頁面就是逐漸往淘汰的方向了。--Z7504非常建議必要時多關注評選（留言） 2022年11月3日 (四) 05:12 (UTC)

不感觉会那么巧合。完全可以微调语句。可以指引级劝止同期采用相似句子。投票者看错是投票者责任，有加粗和条目名信息。--YFdyh000（留言） 2022年11月3日 (四) 05:29 (UTC)

投票看条目名应该是看那行小字吧（ ——魔琴 [ 留言 贡献 ] 2022年11月3日 (四) 07:57 (UTC)

如果DYKC的投票者們真的都是認真投的，我就不會問這個問題。但現實是DYKC很多人都是粗心隨意，說他們有責任感、會看小字而不會搞混，完全是痴人說夢話。--Maccomcre（留言） 2022年11月3日 (四) 08:35 (UTC)

不管是否同时、问题是否相似，看错/评错条目都可能发生。除非强制填写有意义的理由，但那是另一个议题。--YFdyh000（留言） 2022年11月3日 (四) 09:36 (UTC)

其它情況也會有這種混淆我當然知道，只是想說兩個相同問句以現在社群心態來看，混淆的機會應該會比較高。--Maccomcre（留言） 2022年11月3日 (四) 10:21 (UTC)

• (＋)支持，直接把首段定義句抽出來，方便又快捷，不用花費無謂的時間去想問題。—AT 2022年11月3日 (四) 09:44 (UTC)
• 初步衡量了上面的意見，敝人也不得不承認完全改為陳述句、完全廢除問句最好，那麼就完全不用爭論問句會產生甚麼問題。但陳述句還是有需要設置時效性，像是上面行驶证的例子至少也要改為「自(某個時間)起，机动车驾驶人在中国内地驾车上路时必须随身携带机动车行驶证」；單單「机动车驾驶人在中国内地驾车上路时必须随身携带机动车行驶证」的話，如果上首頁當日大陸政府突然推出新政策要帶另一種證還要即時生效，那就完了。首頁始終是可見度極高的地方，一些極端罕見的情況我們也不應該忽視。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年11月3日 (四) 10:11 (UTC)

  如此约束时效性我认为将过于复杂、舍本逐末，很多东西不可能用一句话准确概述，比如试点地区、政策曾经暂停、条件性许可等情况。“要带另一种证还要即时生效”可能不该过分担心、是设问句有问题，至少还有驾驶证，抬杠还有年检标（也已试点电子版）等。--YFdyh000（留言） 2022年11月3日 (四) 10:35 (UTC)

目前不赞成完全改成陈述句，风格变化过大，可能会有实际问题（比如地区词和别名处理？）。--YFdyh000（留言） 2022年11月3日 (四) 10:26 (UTC)

• (！)意見：必须用疑问句本来就是一个莫名其妙的陋习，早就该废除了。不过也不需要不准用疑问句。陈述句疑问句都允许不就好啦？ —ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2022年11月3日 (四) 11:12 (UTC)

  嗯，那我就以今天的DYK举个例子吧：

• • 哪艘德国U艇于1917年11月18日后在芬兰湾失踪？
  • 奥利维亚·羅德里戈单曲《既視感》取樣了泰勒·斯威夫特的2019年歌曲《残酷夏季》。
  • 英國、丹麥、挪威、瑞典等君主立憲制國家對王室成員使用哪一個敬稱，一般可以被簡稱為「HRH」？
  • 商業模式圖是用於描述企業組織開發新商業模式以及記錄現有商業模式的战略管理範本圖。
  • 青岛剧院建成于1940年，2010年因青岛东西快速路三期工程拆除。
  • 哪位波兰立陶宛联邦贵族建立了扎莫希奇城？

大概允许陈述句和疑问句并存会是这样的效果，不知社群怎么看。--BlackShadowG Slava Ukraini! 2022年11月3日 (四) 12:36 (UTC)

以上感觉很怪，但应该是文法问题，完全没有给出有吸引力的元素。以下如何：

• 美国歌手奥利维亚·羅德里戈的单曲《既視感》使其成为首位两支单曲空降Billboard Hot 100榜单前10的艺人。
• 商業模式圖，也称商业模型九宫格，是用於描述企業組織商業模式的战略管理範本圖。

--YFdyh000（留言） 2022年11月3日 (四) 13:18 (UTC)

• 應該就只有中文版會以疑問句為DYK條目作引吧，其他版本的做法一般是把介紹條目的短句套在「你知道⋯⋯嗎？」這問題裏頭，或者像日文版那樣，直接寫一段小作文介紹條目。我對是否解套陳述句沒甚麼意見，但感覺這個問題與其說是有沒有人支持的問題，倒不如說是執行上的問題：首先，總不能「（你知道）哪個鐵路站位於香港體育館和紅磡海底隧道的旁邊（嗎）？」和「（你知道）機動車駕駛人在中國內地駕車上路時必須隨身攜帶機動車行駛證（嗎）？」一起出現在DYK模板裏吧？撇除有趣沒趣這一點，這樣做對後者可能有點不公平（謎底都揭開了，讀者還會想去讀嗎？）。其次，你們如果要廢除問句，那可能就得畫一條界線，截止日之前提名的條目仍然要遵守既有的問題規範，之後提名的條目就適用新的介紹規範（？）。另外也要保證最後一條使用疑問句作引的條目不會上畫2小時後就被刷下來。至於時效性問題，我有想過能不能在DYK模板加一條備註去迴避這個問題（像「上述事實以條目當選時為準，詳情請參閱條目討論頁」這樣）。--春卷柯南－發前人所未知 ( 論功行賞 ) 2022年11月4日 (五) 02:51 (UTC)

  （你知道）機動車駕駛人在中國內地駕車上路時要不要隨身攜帶機動車行駛證（嗎）？--百無一用是書生 (☎) 2022年11月4日 (五) 03:24 (UTC)

  “謎底都揭開了，讀者還會想去讀嗎？”怎么就知道读者不会去读呢？有没有什么数据或理论支持这种假说？--百無一用是書生 (☎) 2022年11月4日 (五) 03:28 (UTC)

  英维基本绝大多数都是陈述句。我认为“镭元素具有强烈的放射性，但是却曾被用作发光颜料。”绝对比“除了钋以外，居里夫妇还发现了哪种化学元素？”更优吸引力。--——🦝英特浣熊耐尔_{（留言・贡献）} 2022年11月4日 (五) 09:01 (UTC)

  此句中“镭元素”改成“什么元素”，我觉得更有吸引力，但实践中可能有答案唯一等问题。不然它只是一句小知识，不太让我产生了解镭元素的动力。--YFdyh000（留言） 2022年11月4日 (五) 09:04 (UTC)

  答案确实不唯一。--——🦝英特浣熊耐尔_{（留言・贡献）} 2022年11月4日 (五) 13:25 (UTC)

  我想書生兄是看不到他想要的硬數據，但我想表達的意思是，單純的疑問句會顯得比單純的陳述句有趣，語文課本該有說過使用疑問句作引，可以利用讀者的好奇心，吸引他們的注意吧。不過，如果加入「是否有趣」這個變量，我這個立論可能就要打個折扣，好比我就說不出「（你知道）哪個政黨曾在2014年推出充斥着女子叫床聲的競選廣告（嗎）？」和「（你知道）《月亮代表我的心》是馬來西亞伊斯蘭黨的競選歌曲（嗎）？」哪個會比較有趣。-春卷柯南－發前人所未知 ( 論功行賞 ) 2022年11月4日 (五) 18:13 (UTC)

  就“谜底都揭开了，读者还会想去读吗”，有谜底我也未必想阅读，要看这个主题和可能涵盖的内容是否有意思。如果很容易猜到谜底，或者看了标题就大概知道写了什么，我可能同样不想阅读。--YFdyh000（留言） 2022年11月4日 (五) 04:27 (UTC)

• 部分(－)傾向反對。可以接受不再要求问题的“疑问代词”代替的一定是条目名（也即不要求谜底一定要是条目本身，如当前候选的“利沃夫在历史上曾归属于哪些国家？”），进一步地接受是非问题也可以（“中国内地是否要求机动车驾驶人必须随身携带行驶证？”）。但是允许直接直陈对形式统一的破坏太明显了，除非反过来要求必须用陈述句（但那样就完完全全失去了“谜语”的吸引力了）。DvXg 📬 2022年11月4日 (五) 07:04 (UTC)

  我认为只要是问了一个有意思的问题就行了，问的方式可以多样--百無一用是書生 (☎) 2022年11月4日 (五) 08:11 (UTC)

  “利沃夫在历史上曾归属于哪些国家？”，我可能会认为答案应该是“利沃夫曾归属的国家列表”或类似的，即使有粗体提示，也会产生这种直觉。谜底不是条目本身的提问个人认为观感不佳。--BlackShadowG Slava Ukraini! 2022年11月4日 (五) 10:20 (UTC)

  私以为这个联想的范围只要是条目主体的范围就可以（也就是读者打开链接可以找到答案、并且是主题的一部分就可以），不必要求全等。当然应当鼓励谜底对条目主题越重要越好。--DvXg 📬 2022年11月4日 (五) 16:32 (UTC)

  是非題在下實驗過「能否聽出一個鼓的形狀？」和「不含數字9的正整數倒數和，有限抑或無窮？」當時沒有受到反對。不過例如前者的確全篇條目就是圍繞該條是非題，其他條目可能較難問出佔條目比重足夠大的是非題？——$\definecolor {my}{rgb}{0.04,0,0.5}\color {my}{\mathsf {htc_{23}}}$（留言） 2022年11月4日 (五) 21:42 (UTC)

(？)異議：如果二者并存，設想疑問句在上，陳述句在下，毫無關聯的兩個事物相鄰可能會令讀者誤解，比如：

• 《港區國安法》首案被告是誰？
• 香港女子某某某由於在法庭對被告致辭鼓掌和召喚包青天，被判煽動罪成立。

如何解決此問題？——Gohan 2022年11月4日 (五) 14:00 (UTC)

这种情况不好解决，也许只能依靠使用相同的type参数来避免同时展示？即便只有设问句，也可能有此种巧合与误解发生吧，所以我觉得无须过度担忧。--YFdyh000（留言） 2022年11月4日 (五) 18:40 (UTC)

上條日本地理，下條台灣建築，並不少見。相同type意味著不同的輪候機制。--Gohan 2022年11月5日 (六) 01:53 (UTC)

个人认为不是什么大问题，非要解决的话可以把现在每项前面加上序号。--Kedouv（留言） 2022年11月5日 (六) 05:56 (UTC)

@神秘悟饭：我自己反而感覺疑問句與陳述句同時出現不會有太大的問題。就你舉的這個例子而言，正常人的閲讀是一定會看上文下理的，但凡看一看格式就知道這相鄰的兩項原則上並無關聯。Sanmosa _{Je sers} 2022年11月24日 (四) 15:05 (UTC)

(＋)滋磁，双手赞成。只要能顺接“你知道吗”，根本没有必要限定句式。当然以后评选时可以就标题的趣味性本身多做讨论，鼓励大众更积极的对评选中的DYK标题提供建设性意见。--南冥大鹏👈批判我一番报道有偏差Ω微小的工作历史的进程 2022年11月4日 (五) 23:52 (UTC)

關於是否會引入其他問題

• 借我們站内的大河内教授一言：“提案是否会引入其它问题？如果会，该问题是否重要？如重要，有何措施加以弥补？”

誠然推行允許陳述句格式能解決很多問題，然而也會出現新的問題；比如上面有編者就提到統一格式的混亂疑慮，這就進而衍生出了現行提問方法需不需同新法并行？如果有格式混亂，現行提問是否需廢除？我想截至目前各位的主流意見都是認爲陳述句可被允許，但也請探討之後的問題。如果後兩個問題沒能得解決，我認爲乃非各位一句“直接陳述好”“强制提問坏”的局限性表態能夠解決的。——咏梅阁—WMLO（留言） 2022年11月7日 (一) 23:44 (UTC)

對於格式混亂的問題，我認為可以通過輪流展示的方法來解決。比如已通過的提問形式DYK達到6篇的時候便可一同登上首頁，陳述形式也是一樣，這樣就沒有格式混亂的問題。--AT 2022年11月9日 (三) 02:38 (UTC)

由於不希望條目展示的時間少過半天，這樣做的話機械得最少隔半天才能更新一次，意味着機械將會很難自動調節頻率（不能逐條計算時間）。而一旦需要更新的其中一邊的下一個輪次花費了較長時間才等滿6個時，整個更新程序會出現拖延問題。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年11月9日 (三) 03:03 (UTC)

雖然我說了輪流，但是如果其中一邊較多的話，而另一邊不足6篇的時候，那可以讓更多的一邊先上首頁，這樣的話應該就沒有拖延的問題。--AT 2022年11月9日 (三) 04:06 (UTC)

這頂多衹能解一半問題吧，兩邊都不夠數的話就衹能讓人乾等了。就以上個月的排隊情況來看，同時至少10篇已確認數量的時數佔不到一半，假如上個月就已經這種方法來更新（也假設陳述句和問句使用情況是一比一），估計會令不少條目在投票完後還要等多約兩天才上到首頁。簡單說就是現有的方法評選越冷清就等得越短時間（完了幾乎即上）；而您提到的新方法就有點反了過來——評選冷清時等候的時間可能變長（完了再要等齊人）。如果因為條目太多而要久等這下還算正常，但條目太少也要久等的話這下就不十分好了。而且這種方法會否讓提名人產生跟大隊的心理？——明明想用陳述，但當下看見沒幾多人用陳述，為了避免花時間等齊人而放棄使用陳述。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年11月9日 (三) 05:37 (UTC)

這樣的話也許可以考慮同時採用定時制，比如說通過後一天內，如果任何一邊達6篇的話先上，兩邊都不足6篇的話，先讓近期未上的一邊先上。然後，再設下限，例如當已經通過超過兩天的DYK優先上首頁。具體來說，比如1月1號有12篇陳述，3篇提問通過，根據這個建議，先讓陳述的6篇先上首頁。之後一天內如果提問累積達6篇，便讓其先上首頁，再到陳述，如果提問仍然不足6篇的話，讓陳述剩餘的6篇先上。去到1月3日，無論陳述有多少篇均讓提問先上。當然這個時限是可以討論的，甚至上首頁的數目也可以商討，不一定是一天兩天或6篇。至於跟大隊的問題，我覺得DYK沒什麼好急，反正通過的話遲早都能驞，快點上也沒什麼特別的好處，因此誘因不大。況且，如果出現一邊倒的情況，導致有人願意妥協的話，我想那就是時候討論棄用沒人用的一邊了。--AT 2022年11月9日 (三) 07:06 (UTC)

衹能說機器的改造工程會很浩大吧，中間要計算的東西多了幾重，不太有信心可以很快改得好…… --街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年11月9日 (三) 07:40 (UTC)

要兼顧多方面下的必然結果...或者看看有沒有人有更好的方法吧。--AT 2022年11月9日 (三) 11:41 (UTC)

我覺得AT這個方案停怪（）如果每個句子前面加上一個小圖標會不會解決？

• 《港区国安法》首案被告是谁？
• 香港女子某某某由于在法庭对被告致辞鼓掌和召唤包青天，被判煽动罪成立。
• 机动车驾驶人在中国内地驾车上路时需要随身携带机动车行驶证吗？
• 开普勒定律是誰发现的？
• 开普勒定律是誰发现的？

以上举几例试验一下。 ——魔琴 [ 留言 贡献 ] 2022年11月10日 (四) 17:58 (UTC)

感觉有点乱，可能喧宾夺主。问号和叹号的区别不太明显。新增句式可能不错。不太赞成条目链接放在长句尾部，粗体不是很明显。如果多个内链，被内链的其他条目应同时保证足够的质量。--YFdyh000（留言） 2022年11月10日 (四) 18:05 (UTC)

• 《港区国安法》首案被告是谁？

---

• 香港女子某某某由于在法庭对被告致辞鼓掌和召唤包青天，被判煽动罪成立。

---

• 机动车驾驶人在中国内地驾车上路时需要随身携带机动车行驶证吗？

---

• 开普勒定律是誰发现的？

---

• 开普勒定律是誰发现的？

那我覺得這樣更好。—AT 2022年11月11日 (五) 04:42 (UTC)

占用空间变大了不少。长句如果折行（宽度受限）还好，不然排版可能不好看。--YFdyh000（留言） 2022年11月11日 (五) 13:07 (UTC)

1. 《港区国安法》首案被告是谁？
2. 香港女子某某某由于在法庭对被告致辞鼓掌和召唤包青天，被判煽动罪成立。
3. 机动车驾驶人在中国内地驾车上路时需要随身携带机动车行驶证吗？
4. 开普勒定律是誰发现的？
5. 开普勒定律是誰发现的？

有序列表呢？--Kedouv（留言） 2022年11月11日 (五) 06:19 (UTC)

本就不分先后、可能随机展示，所以不太建议有序列表，以免过度解读排名。--YFdyh000（留言） 2022年11月11日 (五) 13:07 (UTC)

上面的示例中的两个“开普勒定律是谁发现的？”就看起来很容易混淆。--BlackShadowG Slava Ukraini! 2022年11月20日 (日) 14:10 (UTC)

举了一个比较极端的例子，才能看得出问题 囧rz……所以该怎么解决，三个方案似乎都不是合适。 ——魔琴 [ 留言 贡献 ] 2022年11月22日 (二) 17:37 (UTC)

@AT@BlackShadowG@Cdip150@Kedouv@YFdyh000@魔琴 如果最终在这里没能讨论出统一的抉择方式，不妨使用公投解决如何？——咏梅阁—WMLO（留言） 2022年11月23日 (三) 21:36 (UTC)

如果全部方案都有缺點，且各自的缺點都足以導致不能使用，投票強行得出方案衹是徒然，因為都執行不了。而且綜觀以上各人的意見，敝人也認為全部方案都不行。況且，社群對於能不能同時混合兩種展示？就以上的意見來看也沒有明顯的共識，連這個共識都沒有的時候，直接票選方案也沒有意義。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年11月24日 (四) 04:36 (UTC)

那建议不妨先针对混合展示与否此议题提出公决，比如：“针对DYK之推广，您认为社群应从以下方案中选择哪项以应对现有之观感？

• 应维持现状继续使用提问式；
• 应废除提问式仿英维等使用陈述式；
• 应发展中维特色DYK推广主义，允许两类并行。

若前二项之一得到通过，那方案使用的问题也得到解决，因为这只是换道菜与否的问题。如果是第三项得到通过，可能比较麻烦，但届时也应有适当的环境针对此问题如何解决的讨论，就如同这一年来针对RFA选举的讨论一样。简单来说，应先解决最基本的问题，否则这类讨论最终显也只会无共识结案。——咏梅阁—WMLO（留言） 2022年11月24日 (四) 13:29 (UTC)

先前讨论有点杂。我觉得暂时“试行”允许陈述句（不强制要求问句）就好，如果“问题不当”，全可“用脚投票”，以便看出哪种更受欢迎、实际场景出现的问题。具体的展示和表述方式，似乎暂无共识，但可见当前方式存在多个反对，也非共识。--YFdyh000（留言） 2022年11月24日 (四) 13:39 (UTC)

不过有别于RFA、GA评审制这两个仅关联社群内部的试行方式；这次试行将直接牵涉到读者面对首页DYK的观感...关于这点，各位觉得没问题吗？——咏梅阁—WMLO（留言） 2022年11月24日 (四) 13:45 (UTC)

我自己是覺得允許兩類並行也沒大問題，畢竟也算Unity in diversity。Sanmosa _{Je sers} 2022年11月24日 (四) 15:08 (UTC)

目前應該盡早接納使用陳述形式，再來考慮如何並行或是否廢除提問形式。至於提問和陳述相衝的問題，基於type能夠擋掉大部分同類條目，我想問題不大。--AT 2022年11月24日 (四) 15:56 (UTC)

目前上方疑虑意见在于：1. 问题与陈述相连会误以为是设问；2. 同问句不同条目会导致混乱；3. 其它关于新句型的观感问题。我觉得1、2出现概率极小，而且正如AT君所说，type可以挡掉同类条目（即疑虑1「设问」，对应上方举例的1「国安法首案被告」和2「香港某女子」）。故我支持按现行格式试行接纳其它句式（陈述、不藏条目的问句）。 ——魔琴 [ 留言 贡献 ] 2022年11月24日 (四) 18:19 (UTC)

「同問句不同條目」若非刻意安排應較難出現，又或者等到兩個條目的提名皆通過，再合併成一句多個粗體條目上首頁？例如「開普勒定律是哪位天文學家發現的？」或者是en:Wikipedia:Did you know/Multiple Article Hook Hall of Fame的極端例子。假如僅有部分提名通過就衹為通過的條目加粗。——$\color [rgb]{0.04,0,0.5}{\mathsf {htc_{23}}}$（留言） 2022年11月24日 (四) 20:33 (UTC)

(－)反对試行，因為都已經看到效果是怎樣：

• 哪艘德国U艇于1917年11月18日后在芬兰湾失踪？
• 奥利维亚·羅德里戈单曲《既視感》取樣了泰勒·斯威夫特的2019年歌曲《残酷夏季》。
• 英國、丹麥、挪威、瑞典等君主立憲制國家對王室成員使用哪一個敬稱，一般可以被簡稱為「HRH」？
• 商業模式圖是用於描述企業組織開發新商業模式以及記錄現有商業模式的战略管理範本圖。
• 青岛剧院建成于1940年，2010年因青岛东西快速路三期工程拆除。
• 哪位波兰立陶宛联邦贵族建立了扎莫希奇城？

認同上面有人說兩種並行觀感不佳，結尾有時問號有時又句號，我也覺得是一團亂，完全感受不到趣味在哪裡。--Maccomcre（留言） 2022年11月25日 (五) 05:43 (UTC)

先从三个选项之中取一个基本的共识

@AT@BlackShadowG@Cdip150@HTinC23@Kedouv@Maccomcre@Sanmosa@YFdyh000：还是主张因先将此议题之基要（即维持现状、废提取陈或两类并行）付诸安全投票。应先取主流意见，再据此想办法解决。有一个基本的共识，才能有合适讨论的基础。否则就如街灯同志所言，连并行与否的共识目前都不知道，自然讨论是无法持续下去的。诚然，投票是解决问题的最终手段，可终究不想让此讨论无疾而终。——咏梅阁—WMLO（留言） 2022年11月25日 (五) 12:30 (UTC)

个人是支持两类并行的，但同时认为其他维基人提出的混合展示导致的混乱也有解决的必要，以上的讨论也是主要围绕这一问题展开的。暂且再提一方案：陈述与提问分别展示，推送新项时判断是哪一种类型，如新项为陈述句则展示陈述列表，反之亦然；特别的，开始时因陈述句不足六句则不展示，待数量达到时开始展示；此法唯须应对陈述最早的5项展示时间少于其余项（且越早时长越短），不过或许应该大概有人愿意。--Kedouv（留言） 2022年11月25日 (五) 14:11 (UTC)

或许会比AT的抱团方案清晰一些。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2022年11月25日 (五) 19:16 (UTC)

這樣做的話條目會出現當選條目上了不久又下下了不久又上（6次）的情況，敝人並不贊成這種展示方式。一來在確保每個條目展示至少12小時的技術難度比AT的方案還要大很多（AT的方案難度本來就已經不小），二來是這樣的上上落落可能會讓讀者疑惑：條目暫時下架的期間是否出現了甚麼問題。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年11月26日 (六) 04:46 (UTC)

按目前的更新频率即可保证每条最少12小时的展示时间（即6个更新等候时长），只是展示时间段变得碎片化，除了陈述句最开始的5条；另外读者大概不会一日内每隔一小段时间就访问一次首页并去看DYK，发现上上下下的可能性并不高。不过用AT案我也不反对。--Kedouv（留言） 2022年11月26日 (六) 11:07 (UTC)

每天一早一晚各看一次的讀者應該不少，而近期的更新頻率以每4至6小時為主，現行方法依照這個頻率會使一個條目由開始上架到真正下架需時24至36小時，而您的方案需時應該是現有的兩倍，即48至72小時，橫跨了兩三天。當有人第一天早上7時看到條目A，晚上10時條目A不在，第二天早上7時條目A又再出現……這樣讓人看到上上落落的可能性其實一點也不低。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年11月29日 (二) 09:44 (UTC)

反過來看，此討論的參與者似乎大多均支持使用陳述，而且大多反對使用提問或認為可以並行，似乎也未見有人堅持只採用提問形式。這樣的話，是否應該考慮先改成陳述，再看看提問形式應該廢除還是通過什麼技術手段達至並行？這樣更貼近目前討論的方向。--AT 2022年11月26日 (六) 13:26 (UTC)

整理引导新手的相关页面

目前用以帮助新人的页面实在庞杂。WP:欢迎、WP:入門、H:簡介和WP:參與貢獻内容都大差不差；WP:新手上路感觉也可和WP:第一印象等分享感受的页面合并；H:從這裡開始是不是另一种WP:新手簡明指南呢；WP:線上訓練整得不明不白，又出来了WP:維基百科大歷險。这些页面看似相同，实际偏向主题各不相同，但是新手看来只会感到困惑；且目前想快速编辑的新手也很难直接找到有用的帮助，是否应该参照英维在侧边栏放入引导页面的链接呢，比如H:簡介。--甘糸（留言） 2022年11月7日 (一) 02:57 (UTC)

很搞笑的事情是主页上的「人人可编辑」链接转到WP:欢迎，左右两边都是navbox，各种鲜艳晃眼的色彩。反观英维就好看得多了。--0xDeadbeef（留言） 2022年11月9日 (三) 10:27 (UTC)

WP:欢迎其实完全可以被H:简介取代。--BlackShadowG Slava Ukraini! 2022年11月9日 (三) 13:34 (UTC)

有一种上世纪网页的美，花花绿绿，要是再来点滚动屏就更像了^{[開玩笑的]}----诚挚的 ZhaoFJx^{（论•编）} 2022年11月14日 (一) 14:49 (UTC)

怕搞混的話，就在最上方放「論述」也行吧！空氣小貓（留言） 2022年11月15日 (二) 06:55 (UTC)

• 儘管支持，這可是個大工程。--Temp3600（留言） 2022年11月15日 (二) 16:46 (UTC)

建了个协作页面：WikiProject:維基百科發展/新手2023，个人觉得建立条目相关页面也需要优化整理。 ——魔琴 [ 留言 贡献 ] 2022年11月18日 (五) 09:08 (UTC)

認同有改革之必要，以確實分流。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年11月25日 (五) 18:18 (UTC)

關於WP:簽名方針/指引

WP:簽名方針/指引規定簽名長度不能超過255個位元組，但問題是包不包含簽名前方的兩槓（--）？當偏好設定裡簽名長度剛好是255位元組時，加上兩槓（--）就變成257了，這樣所以到底是可以還是不可以？因為觀察到有些人簽名前面沒有兩槓（--），如果算，那不就變成變相無故收緊簽名長度為253？我認為這個需要規定清楚，以免發生爭議。-- 宇帆-雪菲蛋糕🎂-娜娜奇🐰鮮果茶☕-在維基尋求休閒是否搞錯了什麼（☎️·☘️） 2022年11月18日 (五) 01:27 (UTC)

签名指的应当是~~~~会被替换为的字符，而--是系统的签名功能提供的，很多人会加，但事实上不是签名的一部分。个人认为这两杠不应受WP:SIGN限制。—— 月_樱_雪 (留言) 2022年11月18日 (五) 01:50 (UTC)

话说，讨论串功能的这个前缀可以改掉么，中文环境下用两个半角连接号总感觉怪怪的--DvXg 📬 2022年11月18日 (五) 16:33 (UTC)

(▲)同上。--YFdyh000（留言） 2022年11月18日 (五) 01:53 (UTC)

• (？)疑問：@月_樱_雪、YFdyh000：但是有人簽名的兩槓（--）用的不是-，例如User:魔琴簽名用的兩槓是—，佔3個位元組，跟-（佔1個位元組）不同，甚至有看過在兩槓（--）加內部連結、CSS的簽名，那麼這些情況是否應視為簽名的一部分？還是那兩槓不管用甚麼形式都不算簽名的一部分？-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2022年11月18日 (五) 02:49 (UTC)

  需注意“指引”是参考性的规范，本不应是硬限制。如果我每次留言都手打一个签名（比如“--出自~~~~”、--今天心情不错的~~~~），又是否算入签名，探讨可能没有止境。--为系统功能自动加入的签名前缀（比如“回复工具”会强制加，用户无法选择），不建议计入签名。而其他改版是否计入签名额度，也建议基于常识。--YFdyh000（留言） 2022年11月18日 (五) 03:09 (UTC)

  回复工具并不强制加，只要你写入一个~~~~，回复工具就不会帮你加签名。事实上，只要加入一个合法的用户链接（U, UT或Contribs，但不能是子页面）和一个合法时间戳（不早于1000年）就可以。另外prefix是写在MediaWiki:Discussiontools-signature-prefix里的。 ——魔琴 [ 留言 贡献 ] 2022年11月18日 (五) 03:33 (UTC)

  我的两杠是写进preferences的，如果你仔细观察的话我的两杠前还有一个 ，天哪，竟然浪费了12个字节啊^{[開玩笑的]}。 ——魔琴 [ 留言 贡献 ] 2022年11月18日 (五) 03:17 (UTC)

(！)意見，雖然指引是說255位元組，但一般都不會抓得太嚴，像是看見260位元組的簽名我通常都會覺得還是算了，太過在意這2個位元組好像有點兒無謂。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年11月18日 (五) 02:59 (UTC)

@Cdip150：問題是我位於疑似臨界就被警告了User_talk:A2569875#簽名問題。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2022年11月18日 (五) 03:02 (UTC)

那就是機械人沒有設置緩衝的問題了。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年11月18日 (五) 03:05 (UTC)

您不是第一位遇到，见Wikipedia:管理员布告板/其他不当行为/存档/2022年11月的Mikelolggmrox。我认为机器人对堪堪临界者提醒一次就可以了，纠结几个~十几个字节没有意义，变成254个字节也不会有多少好处。--YFdyh000（留言） 2022年11月18日 (五) 03:14 (UTC)

那这样约等于变相放宽限制。高考生迟到2分钟不让进考场？温州教育局：迟到17分钟 ——魔琴 [ 留言 贡献 ] 2022年11月18日 (五) 03:23 (UTC)

我想這不能類比吧，現實的考試有競爭性質，所以從嚴；但這裏的簽名沒有競爭性質，所以從寬。這大概就跟3.2元乘車但有人上車衹有3元那要不要趕他下車的問題一樣難辯。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年11月18日 (五) 03:38 (UTC)

如果260可以，那過沒多久就會有人覺得265可以，再來270可以，沒完沒了。我們不如改成「規定是200位元組，然後彈性容許到255」如何？這個彈性夠寬吧？--Xiplus#Talk 2022年11月18日 (五) 07:55 (UTC)

事实上如果没人投诉，我觉得机器人只应做提醒之用而无强制力。--YFdyh000（留言） 2022年11月18日 (五) 20:12 (UTC)

那之後就改以我的身分投訴，我覺得機器人或真人根本沒差別，違反規定的事實並不會改變。--Xiplus#Talk 2022年11月19日 (六) 02:07 (UTC)

那我会反投诉，因为我一直认为该规定是一则参考性建议，实际运用有缓冲。如果各方理念有差异，可能共识不成立，建议暂缓执行。态度指引为“用户应该尝试遵守此指引”，不是必须遵守此指引，“如果出现例外情况，最好使用常识判断此指引是否合适。”的例外就是临界点、过度干扰（而不超长）等情况。“因此，请使其保持最小的长度。”，如果256字节已经是实现目的（效果）的合理的最小代码长度，那么遵循了指引；如果不超长但代码明显可缩短（如夹带无关紧要的外观或不可见字符），则反而违背“最小的长度”，哪怕没达到字节限制。--YFdyh000（留言） 2022年11月19日 (六) 02:30 (UTC)

255已經夠長了吧？@A2569875目前的簽名在原始碼內（縮放100%，編輯框textarea寬度1290px）已經佔了整整一行，還不夠長？您說「如果256位元組已經是實現目的（效果）的合理的最小代碼長度，那麼遵循了指引」，那麼請問如果實現某個簽名的語法最小長度是1000位元組，那是否也遵守指引？如果不是，那麼請您直接說個合法的數字出來，我們指引就改成該數字。--Xiplus#Talk 2022年11月19日 (六) 02:56 (UTC)

應該反問為何要設計這麼長的簽名？我也可以直接在簽名內使用255個英文字（畢竟中文寬度占2個英文字但占3位元組），這樣的簽名就比A2569875還要長了，相對之下，A2569875的簽名就合理許多，255不是建議設計的簽名的平均/合適長度，而是不可逾越的上限，YFdyh000您的簽名也只有168啊？為何不設計成255呢？--Xiplus#Talk 2022年11月19日 (六) 03:03 (UTC)

我不认为255字节是“不可逾越的上限”，至多是参考了UI的技术限制，而且只参考了一部分。长度和是否混乱无法直接对等。--YFdyh000（留言） 2022年11月19日 (六) 03:07 (UTC)

確實是來自於UI，但現在已成為指引的一部分。我同意長度和是否混亂無法直接對等，但您已經也能同意1000位元組絕對是混亂的吧？我想要知道的就是這條界線，指引訂說255以內，結果實際上300也沒關係啦，那訂這個255根本毫無意義，所以應該直接訂定確實的上限。--Xiplus#Talk 2022年11月19日 (六) 03:12 (UTC)

为什么它是指引而非方针，就是因为确定性的上限（及外观限制）是不存在、目前无法形成共识的。--YFdyh000（留言） 2022年11月19日 (六) 03:18 (UTC)

那請問255這個數字的用途是？如果有人設500，並反駁說沒有超過255多少（畢竟沒有超過2倍哈哈），是不是就無法處理？--Xiplus#Talk 2022年11月19日 (六) 03:21 (UTC)

个人观点，如果个案共识认为可以（包括如很有特色、无法再减、影响不大），那么就可以，可盖过指引效力。社群非官僚体制，该限制也非机械执行或技术限制。--YFdyh000（留言） 2022年11月19日 (六) 03:07 (UTC)

如果简单粗暴理解该指引为字节数限制，那么“--用户一二三四五 (留言)”是一则合格的签名（247字节），源码如下。至于使用理由：用户是字符值引用爱好者。^{[開玩笑的]}

--[[用户:用户一二三四五|用户一二三四五]] ([[用户讨论:用户一二三四五|留言]])

--YFdyh000（留言） 2022年11月19日 (六) 03:07 (UTC)

我覺得沒問題啊，就沒有超過255。--Xiplus#Talk 2022年11月19日 (六) 03:17 (UTC)

255這個數字絕對是比您所謂的混亂還要客觀，請問您要怎麼定義混亂？我就覺得@A2569875的簽名很混亂啊，5個emoji，8條連結，到底為什麼是鮮果茶連結到用戶頁？我沒說出來就單純是因為他的簽名在255內而已，如果放寬，那是不是就要變成9條連結了？我要花多久才能知道到底哪個連結是用戶頁？--Xiplus#Talk 2022年11月19日 (六) 03:28 (UTC)

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

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

指引的想法可能是只是~~~~的字节量，至于惯例上签名习惯添加的破折号或连接号、或者手工加入类似签名的内容，可能是在打规则的擦边球？——我就是Sakamotosan路过围观 | 避免做作，免敬 2022年11月18日 (五) 05:46 (UTC)

问题在于尽管签名有着明确的定义（mw:Help:Signatures），但在实际操作中无法分辨哪部分是被~~~~替换而来的。实际并非签名但可能被视为签名的部分包括但不限于连字符和用户在签名时手动添加的文字。也许可以在实际操作中将个人观点之后用于表明发言者身份的内容全部作为签名处理？不知这样会不会有新的问题出现。如果有办法得知哪些字符是被~~~~替换而来的就好了。（顺便一提Wikipedia:強制顯示使用者預設簽名似乎完全没效果）—— 月_樱_雪 (留言) 2022年11月18日 (五) 07:09 (UTC)

• 如果你看得到這則留言才意味著Wikipedia:強制顯示使用者預設簽名失效或未啟用^{[開玩笑的]}（這則留言在Wikipedia:強制顯示使用者預設簽名作用下會完全消失）。--宇帆-雪菲蛋糕娜娜奇🐰鮮果茶在維基尋求休閒是否搞錯了什麼（☎️·☘️） 2022年11月18日 (五) 07:48 (UTC)

清除了缓存且启用了js，不知其他人是否遇到了同样的情况。—— 月_樱_雪 (留言) 2022年11月18日 (五) 07:57 (UTC)

• 剛才測試了一下，如果你原本沒有啟用顯示預設簽名功能，就開啟本頁在一個分頁，然後在新分頁開啟偏好設定啟用顯示預設簽名功能，再回頭來重新載入剛剛開啟的「沒啟用預設簽名功能」的分頁的話，確實會沒有效，但再開啟一個新分頁連至有簽名的討論頁就會生效了。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2022年11月18日 (五) 08:45 (UTC)

當然有辦法知道哪些部分是簽名語法產生的，就是您在偏好設定中設定的，不然您以為MediaWiki:Newusermessage-signatures更新簽名或我的機器人是怎麼做的？--Xiplus#Talk 2022年11月18日 (五) 07:57 (UTC)

了解了一下相关的文档，如果可以通过signatures.toolforge.org或类似的方式获得结果的话，应该就没有问题了吧，WP:SIGN中提到的长度限制适用于~~~~被替换为的字符，若有替换引用则展开后再计长度。—— 月_樱_雪 (留言) 2022年11月18日 (五) 08:33 (UTC)

• 實際上計算的是~~~吧，我記得留言的日期時間也不算在簽名長度規範內。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2022年11月18日 (五) 08:39 (UTC)

包括中文在内的多个语言版本都没有这一点的具体说明，不过实际上确实是按照~~~计算的。—— 月_樱_雪 (留言) 2022年11月18日 (五) 10:21 (UTC)

这样说的话，签名后面自动补全的日期算不算签名长度的一部分？----诚挚的 ZhaoFJx^{（论•编）} 2022年11月18日 (五) 15:20 (UTC)

那也是系統自動產生的，而且簽名之時間本質上就不應該算在簽名裡頭。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年11月18日 (五) 15:29 (UTC)

一直以來都不算。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2022年11月26日 (六) 05:35 (UTC)

提议引入加密货币及区块链项目关注度特别准则

加密货币是风口，Web3也是风口，虽然最近破产了一个FTX，但是依然挡不住人们的热情，以及迫切以“让更多人知道正确的有意义的资料”为由想在维基百科打广告的心情。为此考虑引入英维的en:WP:NCRYPTO，条文如下：

When establishing the notability of cryptocurrencies and other blockchain-related projects, the consensus is that crypto-centric news organizations—such as Coindesk or Bitcoin Magazine—generally cannot be used, as they do not provide coverage that can be considered "independent" from their subject for the purposes of WP:ORGCRITE. The notability of such projects must therefore be established on the basis of other sources, such as mainstream reliable news sources.

这里面有些东西是中维没有的，我将其替换成了核心思想等价的内容，如下：

現行條文 （无）

提議條文 （插入进Wikipedia:关注度 (组织)） 在确立加密货币以及其他基于区块链的项目的关注度时，请注意来自于诸如CoinDesk和Bitcoin Magazine这类以报导加密货币及区块链项目消息为业务核心的新闻机构的文章，一般是不可以被使用的。不应使用这些来源的原因是他们的报导通常不独立于条目所记载对象主体，因此不能满足通用关注度的要求。请使用其他来源，如大众、主流的新闻媒体的报导来确立这些主题的关注度。

细心的人可能会发现我把原文中的WP:ORGCRITE替换成了通用关注度，我认为这是合理的改动。英文维基百科的WP:ORGCRITE其实与GNG是一致的：

A company, corporation, organization, group, product, or service is presumed notable if it has been the subject of significant coverage in multiple reliable secondary sources that are independent of the subject.

这个条文与GNG的差异就是强调要多条独立二手可靠来源，但这应该不会有什么问题，因为——

• 在实务中如果只有一条有效来源的话在存废讨论中通常是不够的，所以实际上在操作上就有在要求多条。
• 提议的条文切入的是来源报导是否独立于条目主体，而非一条还是两条还是好几条。

条文以否定的方式拒绝了部分条目，条文没有以肯定的方式给出不符合通用关注度也能得到收录的第二途径。在我印象中，这在中维尚属首次，所以我再多写点。

常见问题

我不希望有条文对通用关注度做出限制，让满足通用关注度的条目得不到收录。

提议的条文不是对通用关注度的限制。通用关注度的用语非常模糊，独立、可靠、二手、深入、假定，都是可以有大做文章的解读的东西。隔壁可靠来源布告板生动地展示了“可靠”可以有多大的争论空间。

条文不是“限制”，而是对上述模糊用词的解释说明以及厘清，即明确指明某一类来源不能满足通用关注度所需的某些要求，从使用了这些来源而看似符合GNG的条目，实际上不符合通用关注度。提出删除的时候，理由应当是不符合通用关注度。

这个条文在否定某些来源，应该送入可靠来源布告板进行讨论。

可靠来源布告板真的有讨论过某些来源可靠但是否独立吗？没有的话我为什么要把它送入一个争论来源可靠度而非是否独立的地方。

条文没有说这些来源不可靠，也没有说这些来源不应在条目中使用。这些来源只是不能用以证明条目符合收录准则而已，没有禁止在正文佐证其他内容。写条目用的来源，与确定条目可以收录的来源，不一定划等号。

这些报导“通常不独立于条目所记载对象主体”，是事实吗？

我一个人没有也无法独断地确认，大家可以在下方讨论区进行讨论以确认是否如此。

可能还有更多想写的，先写到这里吧。留言的话请放到下面的讨论区，这样好看一些不至于杂乱。 --MilkyDefer 2022年11月20日 (日) 05:36 (UTC)

讨论区

• 我不确定涉及多少条目，是否有添加此细则的必要。将这些区块链专门媒体的消息或介绍稿件断为“自我宣传、广告”或“新闻稿”是否就可以。来源独立性和利益冲突方面，有时也许无法完全定义和撇清，例1：可靠的医学专业杂志详尽报道了一种新药，但其他来源都没有独立的有效介绍；例2：游戏杂志详细报道了一款新游戏，但缺乏其他来源；此时，这些来源是独立报道还是有利益的宣传稿件，似乎很难弄清，是否只能通过讨论共识决定是否可靠和值得记载。--YFdyh000（留言） 2022年11月21日 (一) 04:35 (UTC)

  这看起来像是区块链行业的特殊性导致的报道方式有别于其他行业？--百無一用是書生 (☎) 2022年11月22日 (二) 02:21 (UTC)

  可以從Wikipedia:可靠来源#对特定主题领域的建议做延伸，醫學來源有專門指引說那些可以用（WP:MEDRS）。當然就算完全符合所有標準，還有造假的風險（1、[5]），就算國際期刊上也有漏網之魚（[6]）。隔行如隔山，如果有相關的加密貨幣關注小組還能有深入的討論，門外漢只能路過看看而已。--Nostalgiacn（留言） 2022年11月22日 (二) 08:41 (UTC)

請制定懲處方針以警告持續破壞的使用者

現行條文 所有封禁均用作避免維基百科受到破壞，或減低潛在問題發生的機會。封禁應是阻止上述問題的最後手段，只用於應對以較溫和的方法不能解決的問題和持續違反方針的行為，而適當運用這手段能透過以下四個方法避免上述問題出現： 避免對維基百科進行迫切的或嚴重的破壞或干擾 透過增加有不當行為的用戶的編輯難度，制止該用戶對維基百科的干擾 讓有不當行為的用戶了解維基百科不能容忍其行為，應改善及避免該不當行為持續 鼓勵有不當行為的用戶以社群認同的有建設性、適當的編輯方式對維基百科進行貢獻 在某些情況下，管理員會延長封禁期限，以避免維基百科受到破壞及鼓勵用戶停止干擾維基百科，重新開始對維基百科作出貢獻。

提議條文 所有封禁均用作避免維基百科受到破壞，或減低潛在問題發生的機會。封禁應是阻止上述問題的最後手段，只用於應對以較溫和的方法不能解決的問題和持續違反方針的行為。在使用者屢勸不聽的情況下，或已受封禁三次及以上者，應永久禁止其對維基百科做出任何改變，亦應使用相同手段懲處該使用者的傀儡，以預防該使用者操控傀儡繼續破壞。而適當運用這手段能透過以下五個方法避免上述問題出現： 避免對維基百科進行迫切的或嚴重的破壞或干擾 透過增加有不當行為的用戶的編輯難度，制止該用戶對維基百科的干擾 讓有不當行為的用戶了解維基百科不能容忍其行為，應改善及避免該不當行為持續 鼓勵有不當行為的用戶以社群認同的有建設性、適當的編輯方式對維基百科進行貢獻 恩威並施，對破壞者進行警告及勸導，並設法使其知道不當行為帶來的後果 在某些情況下，管理員會延長封禁期限，以避免維基百科受到破壞及鼓勵用戶停止干擾維基百科，重新開始對維基百科作出貢獻。

理由如下：

• 對於某些破壞者，雖然管理員會予以封禁以阻止其行為，但時限一到便將解除，頂多給予口頭警告，使破壞者仍不知悔改，如此柔和的手段效果實在非常有限。在此提議制定一些有力的懲處方針，來整頓維基百科的秩序，降低有人搗亂的可能。以上提議希望能得到共識。--Jiaweipan（留言） 2022年11月20日 (日) 10:33 (UTC)
• (－)反对，根本做不到的事，或可能會造成的大量後遺症的事情不應寫入方針。--SunAfterRain 2022年11月20日 (日) 12:16 (UTC)
• 沒用的，愉快犯才不吃這一套。已知多位長期出沒的破壞者是明知後果還故意破壞的。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2022年11月20日 (日) 12:42 (UTC)
• 保持灵活性，没必要强制劝告。对于一些显然是愉快犯的解决策略是Wikipedia:回退、封禁、不理會，但管理员也视情况对于给予提醒来作为劝告，这些应该有管理员去自己分析确定。——Sakamotosan路过围观 | 避免做作，免敬 2022年11月21日 (一) 06:08 (UTC)

如果是能勸服的話，那一早就被勸服了，用不着改規則。Sanmosa _{Je sers} 2022年11月24日 (四) 15:07 (UTC)

註：此處原有文字，因為LTA傀儡發言，已由路西法人於2022年11月27日 (日) 09:26 (UTC)刪除，尚祈見諒。若有異議請至互助客棧或向管理員反映。

建議將Wikipedia:不要訴諸法律威脅提昇為法律方針

有鑑於最近發生的某些事件，我建議將WP:NLT正式升級為法律方針（如同英文維基百科），雖然可能沒辦法完全阻止類似的事情再次發生，但至少有個可以遵循的依據。--冥王歐西里斯（留言） 2022年11月20日 (日) 23:28 (UTC)

这是否需要法务或者具有法律背景的用户看看是否符合法律要求啊？--百無一用是書生 (☎) 2022年11月21日 (一) 03:04 (UTC)

或許，需要找人看看。--冥王歐西里斯（留言） 2022年11月21日 (一) 03:17 (UTC)

可能直接寄信給WMF法務部門請他們來看比較快？--SunAfterRain 2022年11月21日 (一) 09:07 (UTC)

页面未完善（有一句未翻译内容）和不算稳定。“法律方针”的概念？社群有权定义法律方针吗。也许更适合定为态度指引，但然严厉性可能弱很多。需注意，除了诉诸诉讼和举报，其他对行为合法性的暗示也可能在内和引致同等效果。非站内行为要约束吗，也许较难实现，但似乎很有意义（如WP:OA2021），但验证、警告和处置会相当麻烦。--YFdyh000（留言） 2022年11月21日 (一) 04:21 (UTC)

法律方針是指「These are policies with legal implications」。「不要訴諸法律威脅」此處理方式確實可能會造成法律上的影響。而英維亦將此視為法律方針。謝謝。--SCP-0000（留言） 2022年11月21日 (一) 04:41 (UTC)

那句應該是從英文維基百科來的，但說真的我也看不太懂那句是想要表達什麼。--冥王歐西里斯（留言） 2022年11月21日 (一) 05:28 (UTC)

看上下文是违反这些方针的内容不受WP:NOTCENSOR限制，可以管辖条目内容。-Mys_721tx（留言） 2022年11月21日 (一) 05:40 (UTC)

那我有更多問題了。法律威脅關條目內容什麼事？升格作法律方針又有什麼效力/效果？這種經紀公司直接見一個ban一個不就行了嗎？-某人✉ 2022年11月21日 (一) 08:31 (UTC)

(＋)贊成，對於某些法務方面的疑難，的確需要訂立方針加以規範，免得使用者們無意中觸法。--Jiaweipan（留言） 2022年11月21日 (一) 09:24 (UTC)

“无意中触法”与此方针是相悖的吧。--YFdyh000（留言） 2022年11月21日 (一) 10:23 (UTC)

目前我跟下方LuciferianThomas君的觀點比較像，雖然目前只是論述頁面，也已有與此相關的封禁事件，但畢竟只是論述而非方針，將其提昇為法律方針更能確立標竿，讓管理員與其他社群成員面對類似事件時更有底氣解決。--冥王歐西里斯（留言） 2022年11月22日 (二) 11:40 (UTC)

(＋)支持。正式訂立為法律方針可以確保針對法律威脅的封禁能夠有明確依據下執行。現今有關法律威脅的封鎖一般都僅以無任何地位的WP:LEGAL作為封禁理據，當然執行上並非一定有問題，但實際上仍然是一個程序漏洞可以給人鑽。--路西法人 2022年11月21日 (一) 14:56 (UTC)

我記得以前也有人以法律方式刪除條目內不實內容：楊受成控告維基媒體基金會事件，對方只要有心走法律途徑也能處理那些內容，當然這需要鈔能力。--Nostalgiacn（留言） 2022年11月22日 (二) 08:21 (UTC)

「已截圖存證」算是什麼樣的法律威脅？我真是想不明白啊。而且也不需要給這樣多的例子吧。--Ghren🐦🕓 2022年11月22日 (二) 08:25 (UTC)

畢竟有唐澤貴洋（幫在2chan遭到網暴的高中生，順著IP讓不少人入獄）的情況，雖然也很少見啦。--Nostalgiacn（留言） 2022年11月22日 (二) 08:47 (UTC)

截图的法律效力较弱，但哪些是法律威胁，哪些是正当或不当的威胁/警告提醒/沟通态度问题，还是很难说。比如“您在本条目的所为已存档并转交我司相关部门/人员”，是法律威胁呢，还是表示不满+等待后续沟通的意思，换成“法务”就一定是法律威胁吗，不明说就无事吗。“已对相关发言进行公证”“已对相关发言进行永久存档（网页存档）”在同一场景中有多少本质区别。涉嫌网暴、人肉搜索等风险的非法威胁，是否不考虑同等规制，而且起诉是权力，威胁才是不当的。--YFdyh000（留言） 2022年11月29日 (二) 16:06 (UTC)

截圖的法律效力較弱？看看香港的立場新聞涉煽動案件，其實截圖都可以作為法律證據。--Wpcpey（留言） 2022年11月29日 (二) 16:15 (UTC)

未经公证不能保证未篡改，无法作为证据，所以个人“已截图”说是法律威胁比较牵强。如果已截图算，已保存网页、已记录永久链接难道也算法律威胁了。--YFdyh000（留言） 2022年11月29日 (二) 17:41 (UTC)

那看起來截圖那條可以移除或是移動到其他相關的頁面，其他的例子呢？--冥王歐西里斯（留言） 2022年11月30日 (三) 03:13 (UTC)

复看了一下，也可能是当时管理员自作主张移除掉（虽然理由是以“没有来源及来源可信度不明”移除内容）？虽然现在的话，可以用Wikipedia:修订版本删除请求的RD2、RD4来申请版本移除。就算声明了发律师函给基金会，也要等基金会是否接受和以基金会行动的方式来直接处理，本地对于这种现实法棍没必要理会。——Sakamotosan路过围观 | 避免做作，免敬 2022年11月22日 (二) 10:15 (UTC)

(＋)支持：我的意見同LuciferianThomas君。--~~Sid~~ 2022年11月22日 (二) 15:51 (UTC)

是說目前似乎無人明顯反對，能進公示流程了嗎？--冥王歐西里斯（留言） 2022年11月29日 (二) 02:58 (UTC)

送公示吧。--路西法人 2022年11月29日 (二) 14:53 (UTC)

上方有些意見值得重視，但都未有展開有效討論。--Xiplus#Talk 2022年11月29日 (二) 15:34 (UTC)

同xiplus.建議將提昇為法律方針與更新案分開公示，兩案皆通過後再同時執行。--Temp3600（留言） 2022年11月29日 (二) 16:12 (UTC)

那麼法律方針本身的文字更新應該可以先公示了。--冥王歐西里斯（留言） 2022年11月29日 (二) 23:53 (UTC)

方針列表#法律方針不是任何指引。不需要公示。--Ghren🐦🕖 2022年11月30日 (三) 11:01 (UTC)

对于例子依然觉得不妥。例子重覆，而且引用同一案的说话也不免太多了。--Ghren🐦🕖 2022年11月30日 (三) 11:10 (UTC)

不如閣下直接動手改？--冥王歐西里斯（留言） 2022年11月30日 (三) 11:39 (UTC)

逐條討論

本章節對於特定條文進行深入討論，我已列出的都是與英文維基百科不同的，或是我不確定翻譯的，未列出則表示條文與英文維基百科一致，如果您覺得有其他條文需要討論，請按格式列出。為避免版面混亂，如果您認為條文都沒有問題，請不要對每一項都寫{{支持}}，請寫在前一個段落，這不是投票，請不要僅留下{{支持}}而不留下意見。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

（方針名稱）「不要訴諸法律威脅」

「法律威脅」一詞直接翻譯自en:Legal threat，但曾有人建議翻譯成「不要威脅訴諸法律」，發動法律行動實際上會稱為「訴諸法律行動」，而該方針是禁止「威脅要訴諸法律行動」，故縮短為「威脅訴諸法律」，但該稱呼似乎會跟en:Appeal to the law混淆。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

另建議動詞可以不要用訴諸，可改為「發布」、「張貼」等。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

（簡而言之）

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

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

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

（導言第一行）報告地點

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

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

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

（什麼不是法律威脅 - 著作權）歡迎您告訴我們該使用方式是否符合授權

不太確定「a clear statement about whether it is licensed for such use is welcome」的意思，暫時用我自己的話重寫。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

（什麼不是法律威脅 - 著作權）報告程序

Wikipedia:頁面存廢討論/疑似侵權放在首位，這是穩定執行的現有處理程序。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

（什麼不是法律威脅 - 有償編輯）「laws against undisclosed advertising」未翻譯

不太清楚那是什麼，暫未翻譯。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

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

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

（察覺法律威脅）標題

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

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

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

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

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

（設立方針的理由）這會造成寒蟬效應

原本寒蟬效應是連結，但我覺得直接寫出來該詞彙有助於理解。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

（設立方針的理由）衝突中的一方就有可能威脅並排斥另一方

原文「we risk one side of a dispute intimidating the other」，不確定翻譯是否正確。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

（設立方針的理由）社群與曾做出法律威脅的使用者會留下糟糕的經歷

原文「The project has had bad experiences with users who have posted legal threats in the past」，不太確定是指在（英文維基百科）以前曾發生糟糕的經歷，還是指一旦進行了法律威脅，日後社群在與該位編者協作時會想起這段糟糕的經歷。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

（設立方針的理由）只有在您已經嘗試了所有您知道的合理步驟來友善地解決問題，但爭議解決程序仍不能解決您的問題時，您才可以選擇採取法律行動。

原文「If the dispute resolution procedures do not resolve your problem, and you then choose to take legal action, you do so in the knowledge that you took all reasonable steps to resolve the situation amicably.」，不確定翻譯是否正確。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

（法律威脅的結論）防止在尋求他人協助後，又將對方變為法律上的對造。

原文「prevents a situation in which someone seeks to be a collaborative partner, while posting as if they were a legal adversary.」，實際上看了很久都無法理解這句話的意思，更舊的原文是「It prevents the difficult situation where a person is both seeking to be collaborative partner and also setting themselves up as litigatious adversary (in general those two roles are mutually exclusive).」，相關的討論請參見這裡。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

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

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

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

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

（法律威脅的結論）假定善意不是自殺協議

我其實不懂suicide pact的意思。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)

按照en:Wikipedia:Our social policies are not a suicide pact，是WP:IAR。在用户页面散发法律威胁因为影响范围较小不会被立即禁止编辑讨论页面，但是持续此类行为会禁止编辑讨论页。-Mys_721tx（留言） 2022年11月30日 (三) 16:10 (UTC)

更新对法律方针的描述

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

提議條文 以下方针有法律后果。除下列方针和基金会行动方针外，只要维基百科上的内容符合美国法律，维基百科不会对自身可能令人反感的内容进行审查，或采纳其他管辖内容的法律提案。法律问题需通过维基媒体基金会正式提出。

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

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

根据实际情况修改WP:NOR#原创图像中的表述

Wikipedia:非原创研究：

現行條文 由于各国的著作权法律，现有已发表的图像中，只有相对较少的图像可被用于维基百科。因此，维基百科编者创作的照片、绘画以及其他类型的图像成为了我们的主要图像来源。为了给条目增加插图，我们鼓励编者自行摄制照片、绘制画作或图表，并以GFDL或其他自由著作权协议上传到维基百科。根据NOR方针，由维基百科编者创作的原创图像不被视为原创研究——只要他们没有在图像中绘制或表现未发表的想法或观点。

提議條文 由于各国的著作权法律，现有已发表的图像中，只有相对较少的图像可被用于维基百科。因此，维基百科编者创作的照片、绘画以及其他类型的图像成为了我们的主要图像来源。为了给条目增加插图，我们鼓励编者自行摄制照片、绘制画作或图表，并以允许商业性使用和演绎的知识共享许可协议或其他自由著作权协议上传到维基共享资源并在维基百科中使用。根据NOR方针，由维基百科编者创作的原创图像不被视为原创研究——只要他们没有在图像中绘制或表现未发表的想法或观点。

第一处修改：根据c:COM:Licensing/zh#GNU自由文档许可协议，在该节列举的条件下，GFDL不允许作为唯一许可协议。结合c区著作权协议选用的实际，应进行上述修改（措辞可能存在优化空间）。( π )题外话，原链接本身也指向了消歧义页面。

第二处修改：WP:上传本身建议上传自由文件到c区，建议一步到位。--Teetrition（留言） 2022年11月24日 (四) 12:05 (UTC)

暂且慢着，因为允许GFDL单独授权是有时间限制的（Wikipedia:GNU自由文档许可证文本、Wikipedia:著作权信息）。——Sakamotosan路过围观 | 避免做作，免敬 2022年11月25日 (五) 00:18 (UTC)

该条文主要是为了新制作的文件。2009年之前的文件是单GFDL授权。2018年后Commons上亦不接受仅有GFDL的照片。修改措辞应不影响这些时间限制。--Mys_721tx（留言） 2022年11月25日 (五) 03:08 (UTC)

提议 西方人名重定向 增加 “姓氏，名称1·名称2” 格式

1、之前的提议 （User:PhiLiP的提议）

2、传统百科全书、传记词典，如《中国大百科全书》、台湾国教院中詹姆斯·杜威·沃森沃特森,詹姆斯、欧洲历史大辞典（ISBN 9787532623150）、《美国传统词典》Watson James Dewey、《二十世纪世界名人辞典》等，有条件的可以在读秀上搜“沃森，詹姆斯·杜威”。

3、中文里经常只称呼姓氏，该种格式可以减少建立姓氏重定向，更方便编辑时查找重姓的人物。比如，想找诺贝尔奖获得者 詹姆斯·杜威·沃森，可以用 沃森，詹姆斯·杜威，不用跑到沃森消歧义页面去查找。 --Kethyga（留言） 2022年11月25日 (五) 12:08 (UTC)

《中国大百科全书》第二版23册381页只是单用「沃森」。--Ghren🐦🕘 2022年11月25日 (五) 13:13 (UTC)

《欧州历史大辞典》没有这个人——那是《美国历史大辞典》（206页）吧。--Ghren🐦🕛 2022年11月26日 (六) 04:42 (UTC)

不限定具体某个人物。--Kethyga（留言） 2022年11月26日 (六) 07:33 (UTC)

金常政是这样说的：「词序按排考虑检索的方便，关键词可以移前，必要时也可以颠倒词序。例如外国人物条目以姓氏立目，而把名（本名、教名、父名等）放在姓氏之后，如『Smith, A.T.』」（《百科全书编纂概论》，山西人民出版社，1985年，79页）。一般百科全书为了方便读者检索，将关键词特意移前的百科全书可以说是汗牛充栋——但是放在维基百科，这样建重定向，能提升多少的检索效率？我不是在反对，这也是不能反对的，毕意这是一个出现在可靠来源的名称，但是我不看好这能提升什么效率。--Ghren🐦🕒 2022年11月26日 (六) 07:53 (UTC)

我觉得一个问题是，之所以传统百科这样做，是因为纸质出版的缘故，这样做编制索引方便检索，但是网络出版这样做的必要性就不大了--百無一用是書生 (☎) 2022年11月28日 (一) 03:01 (UTC)

但是中文在称呼的时候，经常不加人名直接称呼其姓氏，比如最近世界杯的球员，大多数也只是称呼球员的姓氏，只有少数的称呼其昵称，而且姓氏总有出现消歧义的情况。--Kethyga（留言） 2022年11月28日 (一) 03:52 (UTC)

您说的话是对的，可是和此案有什么关系？消歧义不能解决吗？--Ghren🐦🕒 2022年11月28日 (一) 07:40 (UTC)

• (－)傾向反對，理由如下：
  • 即便用了新格式，中間的間隔號「·」還是需要剪切粘貼，因此個人認為新格式對查找幫助不大。
  • 個人也不認為需要為此類重定向特別制訂方針，除非涉及到在條目正文中使用新格式重定向。如果單純是用於查找的話，方便個人使用就沒什麼問題。
• 以上。歡迎拍磚。📕📙📒📗📘📚📖^{強烈抗議維基基金會無理封禁中維管理員} 2022年11月26日 (六) 07:15 (UTC)

  目前维基百科的搜索似乎是忽略标点符号的，有没有标点不影响搜索， 即在维基内置搜索输入“詹姆斯杜威沃森”，搜索结果第一项也是“詹姆斯·杜威·沃森”。。没有确定的文字说明不利用存废讨论。--Kethyga（留言） 2022年11月26日 (六) 07:25 (UTC)

(？)疑問 这种页面命名，人物重名的概率大吗，会否增加消歧义需求反增维护负担。中国大百科全书第一版等，有采“马克思－艾威林，爱琳娜”格式，是否也要创建，MOS:连接号是否沿用、选用一字线，但指引中“汉语拼音、外来语内部的分合”是短横线。如果出于可靠来源使用、方便检索，林肯，A.、马斯特斯，E.L.是否均应建立重定向，或者只是鼓励或允许建立？--YFdyh000（留言） 2022年11月30日 (三) 07:48 (UTC)

西方人名的姓氏相对来说没有汉语集中，三名法一般歧义比较少（不代表没有）；连接号在人名中应该用短横线，如 Wikipedia:格式手册/标点符号#连接号中的 伊雷娜·约里奥-居里，人名中用短横线；林肯，A.（姓氏，名字首字母.），这种格式感觉只适合传统百科全书中出现的，不适合普遍应用。--Kethyga（留言） 2022年11月30日 (三) 10:26 (UTC)

“马克思-艾威林，爱琳娜”像是前两者为一个部分，未见任何来源使用，可能不应使用短横线。有一些来源使用“爱琳娜·马克思-艾威林”。--YFdyh000（留言） 2022年11月30日 (三) 15:04 (UTC)

“马克思-艾威林”算双姓吧，比如 弗雷德里克·约里奥-居里，读秀里面有 约里奥-居里，弗雷德里克。--Kethyga（留言） 2022年11月30日 (三) 15:56 (UTC)

设一事件的两个同性质条目，日后若合并是否应按照创立时间的优先次序，亦或品质或其他因素？

如题--咏梅阁—WMLO（留言） 2022年11月26日 (六) 12:33 (UTC)

时间。首先，在显示条目未创建的时候已经提示了你先去尝试进行搜寻，你不先去试着找就直接动笔开始写是你的失职。其次，品质或其他因素是主观标准，创建时间是客观标准，按照创建时间来办事最不会出现争议。第三，先到先得是行之有年的准则，早已成为习惯。最后，没有人说把A合并到B，B的内容就要一定override在A之上，你觉得xtools显示不出是你创建了条目，说实话，这种事情why care。--MilkyDefer 2022年11月26日 (六) 15:23 (UTC)

我觉得说是「失職」又过了。有时候确实建立时间很接近，搜尋时找不到很正常。--Ghren🐦🕚 2022年11月26日 (六) 15:59 (UTC)

首先，我一不是基金会的正式职员，也不是如您二位系本站的回退员、巡查员或管理员，说我失职之指控言过其实。至于“xtools显示不出是你创建了条目”;总的来说，未能显示是本人所创建之条目，亦将影响我未来申请有关荣誉、职权（即限定标准）。若尊敬的MilkyDefer阁下未曾申请维基ACG专题创作奖之类，我可能会被尹说服，毕竟说实话，这种事情why cares^{[開玩笑的]}。撇去以上个人利益的角度，如果社群多数意见认为时间优先，且未避免扩及条目所有权之行为，我亦不提出异议，但出于个人观感我不会主动移动。但也希望能获得更多讨论，这样日后争议也能少些。——咏梅阁—WMLO（留言） 2022年11月26日 (六) 17:31 (UTC)

方才知晓上海乌鲁木齐路抗议事件后，对此深受感触。诚然，无论在社群前还是社群外，我都不能在这里提及政治观点；但我看了现场影片后，我认为他人为了不干自身之事而挺身而出，是一种可贵的勇气，也令人敬佩，且在这样的气魄面前，任何的私利都显得微不足道。故请允许我收回上述发言，我将自行移动至2022年郑州富士康抗议。感谢各位的指教。——咏梅阁—WMLO（留言） 2022年11月27日 (日) 00:33 (UTC)

如果真的擔心直接合併重定向也無妨，這樣建立條目的紀錄也會在；至於維基榮譽的判定問題另外開一個討論串不是更好嗎？--SunAfterRain 2022年11月29日 (二) 04:19 (UTC)

按時間。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年11月27日 (日) 14:29 (UTC)

没有明确规定，协商，个人倾向保留较早、质量和内容尚可、历史记录和参与者较多的版本，此例牵扯多个因素，只能协商。“创建者”身份重要又真的不重要，在意者应自撰“主编（扩充）条目名单”。“较早创建”难有确切标准，比如A用几十笔建立了完善的草稿，B创建了一句话的正式条目，谁为先；又如存废复核复还（合并）、部分侵权重建、原条目下重写等情况，创建者身份都会失去。--YFdyh000（留言） 2022年11月30日 (三) 07:22 (UTC)