维基百科:互助客栈/其他

快捷方式

本页讨论與維基百科有關的话题，但不包括新闻、方针、技术、求助、條目或繁简处理。

如果您需要就具体条目应当如何编辑才符合中立性原則寻求社区共识，请前往條目探討留言。
請在主題欄简明扼要地寫出問題主旨，不要使用如「新問題」等無意義的文字。
請勿公開姓名、地理位置、電話、Email地址等联系資料。我們通常只在此頁回應，並不利用Email或電話等私下回應。
無關維基百科專案的問題，請往知識問答相關頁面询問。

請注重礼仪、遵守方針與指引，一般問題請至互助客棧其他區或知识问答提出，留言后请务必签名（点击）。

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

8月14日之后没有新回應的议题會移动至相应的讨论页或存档。跳至本頁的：目錄 · 底端

公告欄

[公告] 設立頁面評級指引及快速刪除方針R7款的調整已經通過。
[公告] 微調放寬中文名註明位置、第一届仲裁委员会选举方案及提議引入CollapsibleToggle作為預設啟用可選擇關閉的小工具正在公示，如有意見請儘快提出。
[討論] 互助客栈方針区正在討論新聞動態/重複發生的項目中的領導人更替及公布管理人员任免案有资格投票者人数及名单，請踴躍參與討論。
[討論] 互助客栈其他区正在討論引進CampaignEvents擴充功能、设立编者著作权调查及管理人員任免制度檢討等事，請踴躍參與討論。
[討論] 快速删除方针討論頁正在討論快速刪除方針O4款的調整，請踴躍參與討論。
[公告] 討論頁話題索引現正重投測試。如有意見、建議或報錯，請至互助客棧的討論串提出。
[公告] 討論遞進機制正在試行中。如對實行過程及相關規範有疑問，可在討論頁提問。
[討論] Unblock-zh.org正在试运行。同时互助客栈继续对于其各项细节征求意见。
[通知] 深色模式現已供所有行動版及桌面版網站（Vector 2022和Minerva皮膚）的用戶使用。如有任何問題，歡迎在討論頁或透過頁面右側的回報功能提出。
[協作] 第二十二次動員令於7月6日至9月8日間舉行，歡迎踴躍參與！

[協作] 现有129个页面需维基化，337个条目需清理，30个移动请求正在讨论。

存檔

2003年	6月以前						7	8	9	10	11	12	月
2004年	1	2	3	4	5	6	7	8	9	10	11	12	月
2005年	1	2	3	4	5	6	7	8	9	10	11	12	月
2006年	1	2	3	4	5	6	7	8	9	10	11	12	月
2007年	1	2	3	4	5	6	7	8	9	10	11	12	月
2008年	1	2	3	4	5	6	7	8	9	10	11	12	月
2009年	1	2	3	4	5	6	7	8	9	10	11	12	月
2010年	1	2	3	4	5	6	7	8	9	10	11	12	月
2011年	1	2	3	4	5	6	7	8	9	10	11	12	月
2012年	1	2	3	4	5	6	7	8	9	10	11	12	月
2013年	1	2	3	4	5	6	7	8	9	10	11	12	月
2014年	1	2	3	4	5	6	7	8	9	10	11	12	月
2015年	1	2	3	4	5	6	7	8	9	10	11	12	月
2016年	1	2	3	4	5	6	7	8	9	10	11	12	月
2017年	1	2	3	4	5	6	7	8	9	10	11	12	月
2018年	1	2	3	4	5	6	7	8	9	10	11	12	月
2019年	1	2	3	4	5	6	7	8	9	10	11	12	月
2020年	1	2	3	4	5	6	7	8	9	10	11	12	月
2021年	1	2	3	4	5	6	7	8	9	10	11	12	月
2022年	1	2	3	4	5	6	7	8	9	10	11	12	月
2023年	1	2	3	4	5	6	7	8	9	10	11	12	月
2024年	1	2	3	4	5	6	7	8	9	10	11	12	月

#	💭 話題	💬	👥	🙋 最新發言	🕒 (UTC+8)
1	評級系統缺失問題	244	25	A2569875	2024-08-16 23:09
2	Unblock-zh.org	84	16	Bluedeck	2024-08-20 16:16
3	請求社群判斷已經數據過期的用戶是否為傀儡	5	3	Wetrace	2024-08-23 09:31
4	仲裁委员会的选举	30	8	0xDeadbeef	2024-08-20 20:55
5	IPBEG標	1	1	Jimmy-bot	2024-08-24 00:14
6	是否应该移除所有被 WMF 封禁的WMC管理员担任管理员或群主的群组信息	7	4	Hehua	2024-08-15 23:57
7	中華臺北、中國臺北、中國北京、中華北京都是高風險主題	7	5	Jusjih	2024-08-16 21:24
8	引進CampaignEvents擴充功能	4	3	Ericliu1912	2024-08-19 22:02
9	再议设立编者著作权调查	8	5	0xDeadbeef	2024-08-20 20:56
10	為管理人員任免制度檢討等事	25	11	Gluo88	2024-08-23 17:45
11	關於新建LTA頁面	13	5	Nostalgiacn	2024-08-23 18:06
12	管理操作覆核請求：被提报用户明显存在不文明行为时拒绝做出相应处理	16	6	Manchiu	2024-08-24 06:51

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

正在廣泛徵求意見的議題

您可在維基百科:回饋請求系統訂閱特定主題的徵求意見討論通知。

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

維基專題與協作

目前此主題無正在討論的議題

評級系統缺失問題

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:页面评级。

已完成：

已完成主要任務，最終結果為撤銷《通用評級》指引，並將之與《条目质量评级标准》、《条目重要度评级标准》整併到《頁面評級》，並將《頁面評級》提升為指引。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年8月16日 (五) 11:21 (UTC)[回复]

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

（原始標題為「將{{Classicon}}與{{Class/icon}}同步」配合公告欄調整標題。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月5日 (五) 07:47 (UTC)）[回复]

配合上方#Random_Thought: 跟进英维的WikiProject_banner_shell改版因此需要解決評級系統缺失問題，故提出以下議案-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月25日 (一) 09:49 (UTC)[回复]

預計辦理流程：
1. 修正評級系統被不當過濾掉的評級值： 公示通過已佈署
  讓評級系統Special:页面评级均能正確接收到評級值，以便讓{{WikiProject_banner_shell}}工作順利。
2. 同步各模板/块的評級值： 公示通過已佈署
  評級元模板調用了多個不同的評級值轉換模板，但各評級值轉換模板/块的評級值定義有所出入，將會影響{{WikiProject_banner_shell}}的運作，因此需要修正。
3. 將{{Classicon}}與{{Class/icon}}同步： 公示通過已佈署
  以上都完成後，目前評級系統的圖是在各評級定義模板/块不一致，且Style也不一致，為了與XTools也統一，故作出此提案。
4. 一切完成之後，將會同時把評級規範立起來（即立WP:QUALITY）為指引，以便完善評級系統的所有缺失部分。
目前先做到這樣，統整整個評級系統並修正評級系統缺失問題。若未來還有需要調整的會在辦理過程提出，滾動式修正，歡迎發表意見。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月5日 (五) 08:06 (UTC)[回复]
- 2024年3月20日 (三) 00:12 (UTC)更新狀態（註：以上情況為理想情況，實際狀況可能有所不同。如2024年3月19日晚上出現的千字文我不知道怎麼處理。~~提案可能在最後一里路擱淺~~。）-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月20日 (三) 00:12 (UTC)[回复]
  - 討論進行中。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年4月6日 (六) 08:26 (UTC)[回复]
    討論統整中。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年6月22日 (六) 06:15 (UTC)[回复]
    目前#第三階段：Wikipedia_talk:页面质量评级标准#WP:QUALITY_升為指引似乎有初步共識，有維基人正在整理共識中，請稍候。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年6月29日 (六) 15:52 (UTC)[回复]
    目前#第三階段：Wikipedia_talk:页面质量评级标准#WP:QUALITY_升為指引已經有人提出方案草案大綱。應該能推進成功。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年7月8日 (一) 15:05 (UTC)[回复]

最新進度：#c-For_Each_element_In_group_Next-20240710174500-T:_Grading_scheme，但有關指引有異動（Special:Diff/83586399/83586522、Special:Diff/83586695、Special:Diff/83586768），可能要討論如何修改。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年7月28日 (日) 23:44 (UTC)[回复]
最新進度：#公示準備，本議案已進入公示階段。 -- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年8月10日 (六) 03:39 (UTC)[回复]

主線三條任務完成。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年8月16日 (五) 11:21 (UTC)[回复]

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

第一階段：修正評級值不同步問題

議案1：將{{Classicon}}與{{Class/icon}}同步

本主題或以下段落文字，在討論結束後應存檔至Template talk:Class/icon。

已通過：

公示通過。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月16日 (二) 13:14 (UTC)[回复]

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

我認為應將{{Classicon}}與{{Class/icon}}進行同步。{{Class/icon}}提供了比{{Classicon}}更多種級別的圖示，如請求、未來、動態等評級的圖示，{{Classicon}}都沒有。而若{{Classicon}}與{{Class/icon}}合併的話，則等同於{{Classicon}}改成Module模式，需要社群共識，故發起討論。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月25日 (一) 09:49 (UTC)[回复]

(＋)支持合併，後者（{{Class/icon}}）目前只有在154頁上使用。-- Willy1018（留言） 2023年12月26日 (二) 01:33 (UTC)[回复]

(？)疑問：@Willy1018：那要不要{{Classicon}}重定向到{{Class/icon}}？剛才已補充{{Classicon}}所有功能到{{Class/icon}}了。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月26日 (二) 02:33 (UTC)[回复]

可以，但前者{{Classicon}}被全保護，只有管理員才能進行編輯，需要提{{ep}}。-- Willy1018（留言） 2023年12月26日 (二) 04:56 (UTC)[回复]

似乎未來之类的评级并未被整个评级系统完全支持？--百無一用是書生 (☎) 2023年12月28日 (四) 02:24 (UTC)[回复]

(：)回應：@Shizhao：有支持，顯示評級的最後一個調用是{{WPBannerMeta/qualityscale/mask}}，而{{WPBannerMeta/qualityscale/mask|future}}→「未来」，但在要送入{{#assessment:}}的{{Class_mask}}需要設|future=yes才有，不然會被濾掉。而要送入{{#assessment:}}的{{Class_mask}}直接寫死無法設定參數，故建議將要送入{{#assessment:}}的mask改用{{WPBannerMeta/qualityscale/mask}}，這樣才能正確支援。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月28日 (四) 02:50 (UTC)[回复]

@Shizhao：已提出編輯請求，Template_talk:WPBannerMeta/core#編輯請求_2023-12-28，處理完畢後未來之类的评级就能被支持了。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月28日 (四) 04:11 (UTC)[回复]

(＋)支持，沒特別的意見--Z7504非常建議必要時多關注評選（留言） 2023年12月28日 (四) 14:13 (UTC)[回复]

支持合并。不过纯模板实现也不错。--桐生ここ★[讨论] 2023年12月28日 (四) 21:48 (UTC)[回复]

@桐生ここ：完全不建議模板實現。現時模板實現是使用{{#switch:}}，您忘了2020年初{{#switch:}}爆炸事件Special:PermaLink/58036835#A_technical_issue_with_articles_of_French_communes導致中維崩潰的事件了嗎。{{#switch:}}的開銷要高於模組實現，所以建議使用模組實現，安全又有效率。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月29日 (五) 00:06 (UTC)[回复]

這邊最近在處理基礎條目與{{WikiProject banner shell}}的圖示問題（Wikipedia:互助客栈/条目探讨#引入enwiki近期{{WPBS}}之改版，暨將{{Vital_article}}併入{{WPBS}}），(＆)建議直接採用{{Icon}}會更通用。--Kanashimi（留言） 2024年1月2日 (二) 09:18 (UTC)[回复]

但我覺得要有專題專用模板。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月2日 (二) 09:33 (UTC)[回复]

我想採用不同模板來處理同一件事的問題是較不易維護。--Kanashimi（留言） 2024年1月2日 (二) 09:49 (UTC)[回复]

@Kanashimi：問題是目前{{Icon}}並未完整涵蓋Class/icon現有內容。改用{{Icon}}將會導致部分圖是消失，或發生變化。我認為專題圖示應該要統一的Style，但例如{{Icon|image}}

和{{Class/icon|image}}

就不一致，而且{{Icon|image}}

與以下圖示比較{{Class/icon|image}}

、{{Class/icon|A}}

、{{Class/icon|B}}

、{{Class/icon|C}}

明顯Style嚴重變調，故(－)反对。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月2日 (二) 10:13 (UTC)[回复]

或許我們可以擴展{{Icon}}使之涵蓋我們想要的範疇，例如採用{{Icon|image_class}}？--Kanashimi（留言） 2024年1月2日 (二) 10:20 (UTC)[回复]

@Kanashimi：我這個議案只是想先動全保護模板{{Classicon}}，至少先同步圖示，但您目前這樣介入會導致共識亂了，連同不都做不到了，會導致花費更多「跑流程」時間，我想先同步，也做好patch了，都準備好了被你弄沒了？我想先動全保護模板{{Classicon}}至少先同步圖示；至於以後怎麼維護可以再討論。而且您的提議「例如採用{{Icon|image_class}}」也還沒有patch，先現實一點吧，不要紙上談兵，我只想趕快同步圖示，並讓Style一致，評級圖示是評級圖示，其他圖示是其他圖示；評級圖示就該有評級圖示自己的Style，(！)抗议亂七八糟的不一致Style圖示。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月2日 (二) 10:29 (UTC)[回复]

也好。那就等這個討論結束再說吧。--Kanashimi（留言） 2024年1月2日 (二) 10:30 (UTC)[回复]

@Kanashimi：問題2{{Icon|image_class}}會導致評級模板輸出的值無法直接輸入此模板。評級模板肯定是輸出字尾沒有「_class」的結果，你這樣搞還要多寫一個轉換器，不是更難維護？-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月2日 (二) 10:33 (UTC)[回复]
我嘗試在Module:Icon/data加上下面的項目，似乎可以用？
```
	image_class = {
		image = "Symbol file class.svg",
		tooltip = "媒體文件頁",
	},
```
--Kanashimi（留言） 2024年1月2日 (二) 11:00 (UTC)[回复]
- @Kanashimi：您誤會了。我說評級模板「不會」輸出字尾有「_class」的結果，既然字尾沒有「_class」，那你又要怎麼從專題模板的輸出指到『image_class』？？？-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月2日 (二) 11:02 (UTC)[回复]
  如您前面所述，我想這些問題先等這次的合併作業完成之後再說吧。別弄亂了主線。--Kanashimi（留言） 2024年1月2日 (二) 11:10 (UTC)[回复]

此段落最後發言至今已逾七日，超過一周無新留言，因此根據WP:7DAYS準備進行公示。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月9日 (二) 12:56 (UTC)[回复]
公示7日-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月9日 (二) 12:56 (UTC)[回复]

公示期已過，期內無合理異議，提案通過，將進行佈署。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月16日 (二) 13:14 (UTC)[回复]

請管理員編輯Template_talk:Classicon#編輯請求_2024-01-16。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月16日 (二) 13:19 (UTC)[回复]

已由User:AT完成佈署-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月17日 (三) 04:49 (UTC)[回复]

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

議案2：修正評級系統被不當過濾掉的評級值

已通過：

公示通過。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月15日 (一) 14:41 (UTC)[回复]

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

「未來級」等級被正確識別（使用沙盒class mask避免被濾掉而實現的），見此[1]。

上方User:Shizhao提到「未來級」等評級級別無法被完整支持問題，是因為送入評級系統的評級值被不當過濾掉了，即使專題上層已啟用該等評級，但最終還是會被「未繼承上層參數的{{class mask}}」過濾掉，這樣的話就算專題啟用了該等評級也沒有用，都被濾掉了，根本裝飾，白啟用了，因此提議將送入評級系統的評級值改為{{WPBannerMeta/qualityscale/mask}}模板，見編輯請求Template_talk:WPBannerMeta/core#編輯請求_2023-12-28，修改前後的比較Special:PermaLink/80307466，可以看到原有的版本評級值大部分都被濾掉了，建議換成提議的Patch，以讓「未來級」等評級級別能真正被支持。同時，我也確認值接送未來級能正確被工具識別，見右圖，連圖示都有，代表評級系統是支援此輸出的，能正確地被讀取並識別。

因此提出本動議。不曉得各位有沒有異議或意見。Ping參與過相關討論的人@桐生ここ、Z7504、Shizhao、Willy1018：，上方參與過評級討論的也Ping一下@暁月凛奈、Lopullinen、Milkypine、MilkyDefer：-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月31日 (日) 08:29 (UTC)[回复]

支持。( π )题外话：台湾之星的标识现在还没改。--桐生ここ★[讨论] 2023年12月31日 (日) 10:36 (UTC)[回复]

資慈，我覺得行。 --窝法乙烷儿法梦碎 2024年1月1日 (一) 14:38 (UTC)[回复]

此段落最後發言至今已逾七日，超過一周無新留言，因此根據WP:7DAYS準備進行公示。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月8日 (一) 2024年1月8日 (一) 14:39 (UTC)[回复]
公示7日-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月8日 (一) 14:39 (UTC)[回复]

公示期已過，期內無合理異議，提案通過，將進行佈署。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月15日 (一) 14:41 (UTC)[回复]

請管理員編輯Template_talk:WPBannerMeta/core#編輯請求_2023-12-28。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月15日 (一) 14:45 (UTC)[回复]

已由User:AT完成佈署。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月17日 (三) 04:49 (UTC)[回复]

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

議案3：同步各模板/块的評級值

已通過：

公示通過。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月15日 (一) 14:40 (UTC)[回复]

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

目前有多個被全保護的評級模板/块的評級值（如有的有漏掉、有的圖案、顏色不一致）並不同步，因此提議同步各評級模板/块的評級值。不曉得各位有沒有異議或意見。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月31日 (日) 10:30 (UTC)[回复]

(～)補充相應的編輯請求Module_talk:Class/data#編輯請求_2023-12-28、Template_talk:Class_mask/core#編輯請求_2023-12-25和Template_talk:Class_mask#編輯請求_2024-01-05（和2023-12-25是配套的），顏色的部分：Template_talk:Class/colour#編輯請求_2024-01-05。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年12月31日 (日) 10:31 (UTC)[回复]

支持。--桐生ここ★[讨论] 2024年1月1日 (一) 09:03 (UTC)[回复]

就先改看看，讓其他用戶實際去測試這樣才準，而不是每天一直喊支持。不然只是一直放沙盒而不去實際更改的話，完全不知道到底能不能測試。雖然維基百科終於有認知要將其功能「進步」，但也不應每日這樣「無止盡的討論而沒有作為」才是。因此，這個討論就不用再多說什麼了。--Z7504非常建議必要時多關注評選（留言） 2024年1月1日 (一) 11:52 (UTC)[回复]

(：)回應：@Z7504：其實我有私下找User:AT了，但他一直說影響範圍太大要先討論

囧rz…………。我當然也希望能直接改啊，不然WP:7DAYS獲共識再公示7天半個月就過去了……-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月1日 (一) 12:05 (UTC)[回复]

還想說中文維基百科不是長期以來都對專題這個東西愛理不理的，這不就是專題模板在用的相關評級嗎？為什麼不直接修改讓其他人測試呢？建議AT直接幫忙修改吧。因為如果要叫維基百科廢除已經存在多年的專題，顯然是不可能的，更沒有討論是否要廢除專題的必要。--Z7504非常建議必要時多關注評選（留言） 2024年1月1日 (一) 13:45 (UTC)[回复]

此段落最後發言至今已逾七日，超過一周無新留言，因此根據WP:7DAYS準備進行公示。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月8日 (一) 14:36 (UTC)[回复]
公示7日-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月8日 (一) 14:36 (UTC)[回复]

公示期已過，期內無合理異議，提案通過，將進行佈署。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月15日 (一) 14:40 (UTC)[回复]

請管理員依照這則留言佈署相關編輯，也就是編輯以下模板：
-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月15日 (一) 14:44 (UTC)[回复]

已由User:AT完成佈署。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月17日 (三) 04:49 (UTC)[回复]

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

提案已通過請求佈署

已佈署：

已由User:AT完成佈署-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月17日 (三) 04:44 (UTC)[回复]

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

全案公示通過，請管理員依據以下留言：
#A2569875_2024年1月16日(二)13:19(UTC)

#A2569875_2024年1月15日(一)14:45(UTC)

#A2569875_2024年1月15日(一)14:44(UTC)

佈署相關編輯，也就是編輯以下模板：

-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月16日 (二) 13:23 (UTC)[回复]

已由User:AT完成佈署-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月17日 (三) 04:44 (UTC)[回复]

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

評級缺失問題目前辦理狀況

截至2024年1月5日 (五) 17:08 (UTC)已提出三案討論，三案皆在等待初步共識，以便公示。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月5日 (五) 17:08 (UTC)[回复]

評級缺失案辦理狀況
進度	討論中	公示中	部署中	已完成	後續維運
*通用評級設立	已獲共識	已通過	已完成	已完成	廢除，並已整併進《頁面評級指引》
*評級繼承機制	初步共識	公示通過	已完成		進行中
評級值同步	初步共識	公示通過	已完成		進行中
修正過度過濾評級值	初步共識	公示通過	已完成		進行中
評級圖示同步	初步共識	公示通過	已完成		進行中
完善評級系統規範	初步共識	公示通過	編輯請求中	已提升為指引
註：標有「*」表示是其他相關提案。

以上為截至2024年2月2日 (五) 09:45 (UTC)的辦理狀況。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月5日 (五) 17:08 (UTC)[回复]

2024年2月2日 (五) 09:45 (UTC)更新-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年2月2日 (五) 09:45 (UTC)[回复]

2024年8月10日 (六) 03:31 (UTC)更新-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年8月10日 (六) 03:31 (UTC)[回复]

完成：在本次更新中，以下模板的評級資料已獲同步：
- Template:评级
- Module:Class/definition.json
- Module:Class/data
- Module:Class/icon
- Module:Class/styles.css
- Template:Class/colour
- Template:Class mask
- Template:Class mask/core
- Template:Class mask/table
- Template:Class mask/templatepage
- Template:Articles by Quality
- Template:Articles by Quality/total
- phab:T360012（註：若下次要再變更，需要提交新工單）
-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月17日 (三) 08:55 (UTC)[回复]
報告：目前剩下指引修訂的部分待完成。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年6月7日 (五) 23:42 (UTC)[回复]
此案亦積壓過久，請考慮儘快結案。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年6月11日 (二) 16:22 (UTC)[回复]
無法苟同此言論，見此發言。(！)抗议惡意讓本案再次付諸流水的任何行動。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年6月16日 (日) 12:06 (UTC)[回复]
沒有要提案付諸流水，祇是因為已幾無人在意，即使想要在意也跟不上如此龐大的討論，那還不如儘快通過並存檔，避免占用互助客棧篇幅。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年6月23日 (日) 02:09 (UTC)[回复]
(：)回應：@Ericliu1912：目前已公示通過，就看#後續討論還有沒有什麼事項需要討論了。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年8月16日 (五) 11:36 (UTC)[回复]
@A2569875 补充一下，已经重新恢复Wikipedia:通用評級为存档页面，通用評級也因此成为中维最短命的指引（7个月）。Пусть от победы ☆к победе ведёт! 2024年8月16日 (五) 12:03 (UTC)[回复]

@A2569875 另外，根据Wikipedia:互助客栈/其他#第二階段：依據先前共識將不是條目命名空間的評級分類從「XX級條目」改為「XX級頁面」，你说到結尾為「XX重要度」的分類不會移動，不在本計畫內，但个人认为早晚也要移动，请问何时会操作？Пусть от победы ☆к победе ведёт! 2024年8月16日 (五) 14:37 (UTC)[回复]
@阿南之人我知道，但真的很抱歉，因為家庭狀況，近期可能有點困難。真的很抱歉，如果可以我也很想配合。甚至連我每年都會參加的維基盛事，今年我可能連動員令（WP:DC22）都無法參加。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年8月16日 (五) 15:09 (UTC)[回复]

第二階段：依據先前共識將不是條目命名空間的評級分類從「XX級條目」改為「XX級頁面」

已通過：

公示通過。分類改名涉頁面較多，會再進行公告；而Wikipedia:条目质量评级标准移動到Wikipedia:页面质量评级标准將會立即執行。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年2月13日 (二) 03:18 (UTC)[回复]

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

根據先前共識，需要將不是條目命名空間的評級「XX級條目」的分類改為「XX級頁面」，但因技術限制未能將「XX級條目」的分類改為「XX級頁面」，因此本案已提出新的方案，依據頁面命名空間添加分類，以實現該共識。具體執行方案在Template:WPBannerMeta/qualityscale/sandbox。同時將Wikipedia:条目质量评级标准移動到Wikipedia:页面质量评级标准，不知道各位有沒有異議？-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月17日 (三) 04:57 (UTC)[回复]

副知@Ma3r、Kanashimi、Z7504、桐生ここ：@Kethyga、暁月凛奈、MilkyDefer、Milkypine、Willy1018：-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月17日 (三) 04:58 (UTC)[回复]

沒有異議，~~就是不知道會不會出現突發狀況~~。 --窝法乙烷儿法梦碎 2024年1月17日 (三) 11:35 (UTC)[回复]

已在多面體專題進行測試，詳見Category:分类级多面体页面、Category:模板级多面体页面，目前測試整個多面體專題尚未出現問題。待本案正式通過之後才會正式(►)移动分類頁面。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月17日 (三) 11:39 (UTC)[回复]

沒有意見，但在專題頁面（WikiProject）中使用到的{{Articles by Quality and Importance}}模板應一併解決顯示異常之問題（前幾天似乎還有這問題，現在不知道），雖然這模板平常根本沒什麼人在意

囧rz……（所以沒解決可能也沒差吧？因為專題本來就沒什麼人在意了）--Z7504非常建議必要時多關注評選（留言） 2024年1月18日 (四) 14:26 (UTC)[回复]

首先，結尾為「XX重要度」的分類不會移動，不在本計畫內，而{{Articles by Quality and Importance}}是讀取結尾為「XX級XX重要度」的分類，故基本上本案不會影響{{Articles by Quality and Importance}}。再來，如果這個真的要處理，要本案通過後，分類全部清理好，分類全數移動完成後才能處理，不然現在處理數字都會變成0。故應是下一個階段要處理的（或者共識是暫不處理），不是此案此階段討論範圍。此外，如果是{{Articles by Quality}}的話，直接更新分類名稱即可。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月18日 (四) 16:02 (UTC)[回复]

已逾一周無新發言，根據WP:7DAYS七日無進一步發言視為已獲初步共識，如本聲明無人有異議，將準備進行公示。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月26日 (五) 00:32 (UTC)[回复]

已逾十日無新發言，根據WP:7DAYS一周無進一步發言視為社群「對以上『已有初步共識』的論述」沒有異議，因此將開始公示。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年2月5日 (一) 10:00 (UTC)[回复]
公示7日-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年2月5日 (一) 10:00 (UTC)[回复]
@A2569875：公示期滿，無人反對。Sanmosa _{起視四境　而秦兵又至矣} 2024年2月12日 (一) 13:39 (UTC)[回复]
- 公示期雖滿，但考慮到這將會影響數萬頁面，因此執行前我會再公告此事一周，公告完後再開始執行。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年2月13日 (二) 03:13 (UTC)[回复]

公示期已過，期內無合理異議，提案通過。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年2月13日 (二) 03:18 (UTC)[回复]

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

分類改名準備

已完成：

已完成移動。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月19日 (二) 10:44 (UTC)[回复]

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

雖Special:Diff/80961277已公示通過，但因涉及的頁面眾多，因此宜再進行全站公告。公告完後將進行兩個階段完成：

階段1：全保護頁面編輯請求：Template:WPBannerMeta/qualityscale和Template:Class
由於該等分類都是以上被全保護的模板自動添加的，因此需要執行以上編輯請求。等編輯請求完成後，數萬個頁面緩存自動清理完畢後，分類將自動從「XX級條目」改歸為「XX級頁面」。
階段2：正式(►)移动分類頁面（可能是約階段1完成後再過一周）
等緩存全部清完，再將「XX級條目」分類，逐個(►)移动到「XX級頁面」分類。

-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年2月13日 (二) 03:30 (UTC)[回复]

公告一周。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年2月13日 (二) 03:31 (UTC)[回复]

已提出編輯請求。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年2月25日 (日) 01:07 (UTC)[回复]
- 編輯請求已由User:Shizhao執行。等待系統清除緩存。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年2月27日 (二) 13:22 (UTC)[回复]
系統緩存已清除完畢，但Wikipedia:互助客栈/求助#「Category:模板级条目」的分類是不是應該移動至「Category:模板级页面」才對？有異議，因此移動作業暫時先暫緩一周，若下周二前沒有其他異議，才執行移動（本次實屬折騰，明明都WP:7DAYS+公示1周+公告1周+等待編輯請求與系統清除緩存，整個流程走了超過一個月，突然冒出異議到底是啥情況，而且該異議還跟本站無關。。。）。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月4日 (一) 03:50 (UTC)[回复]
Wikipedia:页面质量评级标准中标准级别都是针对条目的，只有非标准级别才有模板级、分类级这些评级，而且非条目命名空间的都不能评甲乙丙初之类的等级，所以评级主要针对的是条目。因此是否应当将其移回Wikipedia:条目质量评级标准，将页面评级作为扩展（专题条目类别标准→专题页面类别标准，需要修改{{Grading scheme}}），与Wikipedia:条目重要度评级标准统一。
此外，非条目页面不应该设置重要度，所以Category:不适用重要度条目及其子分类也应一并移动至Category:不适用重要度页面。--Kunjinkao（留言） 2024年3月8日 (五) 02:37 (UTC)[回复]
@Kunjinkao：我提此延伸案的目的就是為了Wikipedia_talk:页面质量评级标准#WP:QUALITY_升為指引，你現在越給我搞複雜，好啊WP:QUALITY永遠升不了指引都你害的。Category:XX重要度条目如果改名Category:XX重要度页面]且有的有改有的沒改，那你判斷統計的模板將被複雜化，這從12月折騰到現在，我已經沒有心力了，中間又被Z7504搞，既然你要這樣，那我不管這個案子了，你自己想辦法。且公示都已經通過了，你又來個「公示通過後」異議，是甚麼鬼？專門故意折騰我的是不是？-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月8日 (五) 03:55 (UTC)[回复]
@Kunjinkao：我近期沒有時間也沒有心力針對Module:Articles_by_Quality_and_Importance修改。「Category:不适用重要度条目及其子分类也应一并移动至Category:不适用重要度页面」Module:Articles_by_Quality_and_Importance判斷將會變得複雜，如您希望「Category:不适用重要度条目及其子分类也应一并移动至Category:不适用重要度页面」請您自己提出相應模板的修改patch。如無人提出，就會如Wikipedia_talk:条目质量评级标准#總結變成就算有共識也永遠不會實現，因為沒人寫程式。我自己的提案，我當然有義務寫完與該提案相關所需的程式碼，但並不意味著各種節外生枝我也需要幫忙寫程式，這樣根本沒完沒了。

本案先前早已公示7天通過+公告7天通過，在這之後冒出異議.....我實在不想評論如此行為。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月8日 (五) 04:11 (UTC)[回复]
@Kunjinkao：您好，由於議案已公示通過，若您覺得議案還有不妥之處還請另起章節修正，此處不受理已通過之議案之再變更，謝謝。--Sun After Rain 2024年3月8日 (五) 04:35 (UTC)[回复]
我没看到结尾为“XX重要度”的分类不会移动，不在本计划内，以为这是提案的一部分。既然如此那就放在后面说吧--Kunjinkao（留言） 2024年3月8日 (五) 04:42 (UTC)[回复]

至于{{Module:Articles_by_Quality_and_Importance}}，先看看名稱以「Category:分类级不适用」開頭的所有分类、名稱以「Category:模板级不适用」開頭的所有分类该怎么处理吧，这总该是分类改名共识的范畴吧。但我要说明一点，我是在指出实施时出现的问题，并不代表我想推翻共识。--Kunjinkao（留言） 2024年3月8日 (五) 05:34 (UTC)[回复]
本次共識從來都不包含任何分類名稱中含有「重要度」的部分（您所指的「不适用」全名叫做「不适用重要度」），請不要無關聯想，謝謝。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月8日 (五) 05:42 (UTC)[回复]
根據WP:7DAYS「若已獲提案人正當合理的回應，且自該回應起計的3日後無進一步再回應，應視為該意見已解決。」已逾時三日無新回應，視為該意見已解決。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月12日 (二) 11:26 (UTC)[回复]
(►)移动作業進行中。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月12日 (二) 05:02 (UTC)[回复]
(！)意見：绝大部分评级模板都指定了{{class}}的category参数，且都为“xx条目”，如此将导致非条目页面的专题横幅模板出现红链。模板参数需要考虑重新设计，比如仅使用“xx”并由模板判定后缀。--PexEric 💬|📝 2024年3月16日 (六) 12:08 (UTC)[回复]
- 先前的編輯請求已涵蓋有關內容。您所指的可能是不共用元模板的電子遊戲專題，而我也看到您已於電子遊戲專題提出編輯請求。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月16日 (六) 12:20 (UTC)[回复]

完成：(►)移动作業已完成。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月19日 (二) 10:44 (UTC)[回复]

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

第三階段：Wikipedia_talk:页面质量评级标准#WP:QUALITY_升為指引

已通過：

提案已通過，不過變更為《頁面評級》提升為指引-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年8月16日 (五) 10:40 (UTC)[回复]

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

本案最初的初衷就是完成此共識Wikipedia_talk:页面质量评级标准#WP:QUALITY_升為指引，來完成WP:QUALITY_升為指引一事，來正式解決「評級系統缺失問題」（指引/規範未立也算是本系統的一種「缺失」）。等上方都完成，此處將繼續。聲明：當這些「缺失」都解決後，本人將不再碰評級系統這塊了，這燙手山竽真是消磨人的精神。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月8日 (五) 04:40 (UTC)[回复]

可能我上面没说清楚，让你以为我是反对分类改名的，更不是什么越给我搞复杂，好啊WP:QUALITY永远升不了指引都你害的，不能有问题不让说是不是。总之是以下几点：

页面重新命名为Wikipedia:条目质量评级标准：因为评级针对的是WP:条目，其它模板级、分类级这些评级都是非标准级别（WP:QUALITY就是这么写的），那么页面应当以标准评级针对的对象命名，也就是条目质量评级标准。~~除非你打算搞什么甲级模板级，那不是更复杂。~~此外还存在Wikipedia:条目重要度评级标准，那是否要改成Wikipedia:页面重要度评级标准，总之得有一个要改
目前Wikipedia:条目重要度评级标准和Wikipedia:页面质量评级标准是正交的，所以有Category:分类级低重要度宗教条目这种东西的存在，那是不是得命名成Category:分类级低重要度宗教页面。既然分类级不属于标准评级，因此也不必设置重要度，引入更多复杂性，这类页面统统扔去Category:不适用重要度条目去（或者说Category:不适用重要度页面）。
{{Grading scheme}}修改，因为Wikipedia:页面质量评级标准调用了，这个就是作为WP:指引用词统一的问题

--Kunjinkao（留言） 2024年3月8日 (五) 05:20 (UTC)[回复]

無論是前次討論還是本次討論，都沒有提到重要度，因此認為重要度的那個論述怎麼樣，並不礙於WP:QUALITY升為指引一事。
此修改技術成本過大，且認為這樣修改與否並不礙於WP:QUALITY升為指引一事。由於目前架構問題，該修改技術上的複雜性，不建議做此修改。除非有人能提出具體的patch ，否則我不支持也不相信此修改能夠被實際執行。（當然，如果有人做patch 就另當別論）-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月8日 (五) 06:05 (UTC)[回复]
如果沒有人有異議，你可以自行修改。

-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月8日 (五) 06:05 (UTC)[回复]

关于第一点，重要度只是顺带提及，核心是评级针对的是WP:条目，其它模板级、分类级这些评级都是非标准级别，那么页面应当以标准评级针对的对象命名，也就是条目质量评级标准。--Kunjinkao（留言） 2024年3月8日 (五) 06:26 (UTC)[回复]

Wikipedia_talk:页面质量评级标准#c-Cdip150-2016-03-14T04:31:00.000Z-Liaon98-2016-03-14T02:44:00.000Z。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月8日 (五) 06:47 (UTC)[回复]

根據WP:7DAYS「若已獲提案人正當合理的回應，且自該回應起計的3日後無進一步再回應，應視為該意見已解決。」已逾時三日無新回應，視為該意見已解決。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月12日 (二) 04:58 (UTC)[回复]

第二階段正式完成後的第三階段討論

Wikipedia:互助客栈/其他#評級系統缺失問題已分階段按部就班完成，可以準備進入最終階段進行收尾：

已完成當時的共識Wikipedia_talk:页面质量评级标准#總結「將不是條目命名空間的評級分類從XX級條目改為XX級頁面」，因此將安排Wikipedia_talk:页面质量评级标准#WP:QUALITY_升為指引重新公示。重Ping當時參與討論的人：@Liaon98、JyunWaan、Lssrn：@Cdip150、Temp3600、Peacearth：。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月19日 (二) 10:49 (UTC)[回复]

当时的讨论是专题各自评级，而现在的情况是多了通用评级（WPBS）。所以时过境迁，WP:QUALITY要重新讨论了。我之前没有参与讨论，现在有不少想法：

WPBS评级是专题评级的容器，还是一套有自己标准的独立评级？现行做法属于前者：WPBS评级继承专题的评级，且受各专题各方面的干涉，因此评级原则看似「随意」。
一篇列表WPBS获评List级而非CL级，是因为它确实没到CL级。另一篇列表获评List级而非CL级，只是因为某个参评专题不设CL级。第三篇列表和第二篇品质相似却成功获评CL级，原因竟是不设CL级的专题没有「染指」该列表。
所以我的看法是，通用评级就该如WPBS模板所言，确实地「依照頁面品質評定標準」来独立评定，而不是在各专题评级间谋求公约数。可以参考专题评级，但把专题评级当爸爸就不对了😂
承上，如果我们确定WP:ASSESS本位而非专题评级本位，那就要讨论条目的WPBS该设立哪些级别？英维的PIQA是只支持FA、A、GA、B、C、Start、Stub、FL、List、Unassessed几个经典的「标准级别」。而我们的WPBS是大杂烩：既包括BL、CL这种品质向评级，也包括Future这种非品质向评级。所以WPBS评级所支持的「标准等级」该设哪些？
- BL、CL等品质向等级有两条出路。一是如同英维，只收录广为人知的传统评级，不收录BL、CL这种额外等级；个别专题想启用就在自己的横幅上评。二是将BL、CL升格为通用评级，全体专题横幅亦自动启用BL和CL；如果个别专题自己讨论后坚持不用BL，那可以用掩码把BL改成List或B。
- 对于Future级，一篇未来级条目可以很烂（Stub），也可以比较充实（C），那Future这个等级就没有实现「评价頁面质量」的作用。我能想到的用途是在话题中，用未来级作为宽限条目的标记，暂时不影响认定。但这个等级的确不够「通用」，或者说和条目所用的品质评级不是一个维度。
- 对于A级条目。英维的A级在军事史专题存活（且活得很好），但其他专题都是死的。因此英维多次讨论A级的出路，比如从PIQA里开除把A级之类。但你维是真的所有专题都不评A级；所以，把这个只有理论价值的等级从通用评级中灭了挺好。
- 上面的想法也会影响小工具的设定：包括对标准评级的契合，对各专题自定等级的支援，对非条目评级的简化（非条目空间一般人手评级无效）。
下文有提到「消歧义级条目/页面」。如果按照命名空间来理解，那就有一个问题：重定向在各个空间都有，那到底是叫「重定向级条目」还是「重定向级页面」？（或者两个都要，但这徒增烦恼）另一方面从实用性上看，专题统计「条目数」都是排除Disambig级的，那消歧义占据条目空间就成了bug而非feature。这次从「条目」移到「页面」更像是正名，但是后缀分家无论是技术实现上还是命名统一性上，带来的麻烦都不少。考虑将后缀统一为「页」，比如品质评级这边的「乙级条目页」「丙级列表页」「模板页」，重要度那边也可以叫「高重要度页」「未知重要度页」，这样观后缀就知道是页面评级体系在整活。

我明白很多内容都不在讨论范围内，但我认为之前讨论本身就是系統性不足。比如把非條目品質評級改爲「XX級頁面」，那爲何條目品質評級和非條目重要度分類不動？是改條目和重要度分類真的弊大於利，還是單純沒有討論過而已？作爲這套系統創始者，英文版的非條目還用articles的，個中原因是否值得參考？

--For Each element In group Next（留言） 2024年3月19日 (二) 16:05 (UTC)[回复]

提案問題大致解決，不過變更為《頁面評級》提升為指引-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年8月16日 (五) 10:40 (UTC)[回复]

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

爭議已消失：

上述爭議因進一步討論已展開，因此可以視為爭議已消失-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年6月1日 (六) 10:55 (UTC)[回复]

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

老實說我真的不懂你們這些這時候再來提意見是用什麼心態再看事情的，這個提案已經放超過三個月了，又不是放一個星期就說要公示，硬是等提案要準備收尾才來提意見是怎麼回事？！我可以當成你是打算擾亂干擾提案通過嗎？！--Sun After Rain 2024年3月19日 (二) 16:40 (UTC)[回复]

我几年前的主业之一就是评级理论。Wikipedia_talk:页面质量评级标准#WP:QUALITY_升為指引6年前甚至6个月前，我都会像推动MOS:FICT那样，亲自提出修改意见和方案（如WP:QUALITY第二段不符合新形式），让WP:QUALITY成为更优质的指引。但现在评级方面，我认为和这个装睡的社群去合作没有什么意义。所以我的做法就是不发言，看着这个社群未来到底走向哪里。出于对当初理想的怀念，我写下了这些明者自明的意见，但也仅此而已了。通过提案无非就是页面多个「指引」的标签；您看我用户页，就该知道我对这种「社群众评标签」有没有兴趣了。--For Each element In group Next（留言） 2024年3月20日 (三) 16:36 (UTC)[回复]

我不管你到底對這個議題有沒有興趣，反正你現在的意思是上方內容純粹是發牢騷你沒有要干擾這個提案？！--Sun After Rain 2024年3月20日 (三) 17:12 (UTC)[回复]

還沒有細看，但我對洛普利寧君遭到這樣的對待感到很悲哀。--Temp3600（留言） 2024年3月20日 (三) 17:43 (UTC)[回复]

最初提案开始时说「精神上支持」后消失三个月（2023年12月8日-2024年3月19日），等到提案东西都搞好，准备收尾时，冒出千字文异议，请问这样到底哪里恰当了？—38.46.221.138（留言） 2024年3月21日 (四) 04:10 (UTC)[回复]

在有用的討論串下面離題吵架實在無奈，但似乎VP環境已經如此。

WP:CON明確指出"共识应采纳多数人的意见，并和重要少数的意见作出适当妥协。"、"共识在维基百科是持续不断的过程"，對於方针修改，更再次明示"共识最终将根据支持和反对该议题的论点质量所决定"。方針中沒有任何字眼要求討論應"收尾"，反而暗示了討論本身是可以無限延長，以不斷修改共識更貼合實況的。所謂擾亂更是莫名其妙。

回到討論本身，如果有足以反駁洛普利寧君的理據，直接提出來就可以。如果反駁不了，甚至根本沒有考慮到這一討論角度，那顯然就說明"之前讨论本身就是系統性不足"，提案一方存有思考盲點，應該進一步討論下去。

回到這個提案。我與八年前一樣，支持將WP:ASSESS建立為指引。然而，洛普利寧的問題必須先得到回答:维基百科:通用評級與维基百科:页面质量评级标准之間有潛在矛盾。通用評級到底是獨立的評級系統，還是專題評級的平均分?我對這兩者沒有特別的見解，但WP:ASSESS應該清楚指明這一上下級關係。

如果不幸某頁面只有一個專題，而這個專題將頁面評為"未來級"等奇怪級別，通用評級是否跟隨?

請賜教。--Temp3600（留言） 2024年3月21日 (四) 19:45 (UTC)[回复]

那我倒覺得您來主持好了，包含修改模板模組的部分，反正您看起來很閒可以泡在客棧陪大家一直耗。--Sun After Rain 2024年3月22日 (五) 01:35 (UTC)[回复]

折騰了三個月，我已經沒有修改評級模組的心力了。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月22日 (五) 01:52 (UTC)[回复]
Special:PermaLink/81985508#第三階段：完善制度這裡有說，一切以维基百科:页面质量评级标准為主，當專題評完後，维基百科:通用評級再取各專題WP:ASSESS的公約數，不認為有矛盾。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月22日 (五) 02:00 (UTC)[回复]
- @A2569875：如果方针是FA级，指引是GA级，那现行WP:QUALITY+维基百科:通用評級大概只有C的水平，还需要很多工作完善：
  - WP:QUALITY说「评级主要由专题进行……」。那WPBS评级人是作为什么身份评的？社群成员，还是专题成员？现在WPBS开展一段时间了，相信大部分人的评级逻辑是直接对WPBS评级（而不是专门针对各个专题）。这就和「评级主要由专题进行……」矛盾。
  - 有了WPBS后，就有了「社群心目中的评级」，这个评级就是WPBS的评级。这样，大部分专题出于信任社群/懒得评级，而继承了通用评级。对于旧页面，现在的做法很好——假定WPBS评级为各专题评级的公约数。不过这个做法并非必然，我们也可以取各专题的最高值/最低值，只要社群愿意信赖专题。例如英维只有WP:MILHIST真正地在评A，而其他专题是评GA或者B，此时一个做法是取A，而非众数或向下取GA/B。
  - 但是下面的问题理论上和执行上都很成问题。例如维基百科:通用評級第5点要求「例如未啟用乙級的專題，通用級別遇到規則3判為乙級的情況時，則向下填寫為丙級……」。
    - 首先，很难判定专题是否启用某个级别。机器人运行者好像都说过做不到这个事情，就更不用说人工评级了。
    - 其次，如果B级是标准评级，且多数专题都评B级，那这个条目在社群心目中就是B级。我们不应该迁就特例独行的专题，否则公认的B级条目评C，那B和C还有什么可比性？应该是说，不设B级的专题应该自己收拾自己的摊子，例如专题评级继承B而表示为unassessed，或者用掩码改成C。
    - 第三，现在的BL是标准评级吗？如果不是标准评级，那应该呈现在社群通用的WPBS上吗？如果呈现在WPBS上，多数编者没见过BL，他们看得懂吗？如果你认为大家能看懂，且乐见对列表细致评级，那不如将BL升格为标准评级？如果升格为标准评级，就应该预设对所有专题的class mask启用BL，否则又回到上一点专题「特立独行」的老路。
  - 只有一个专题评Future，那WPBS技术上当然可以评Future（且只能评Future）。但上面BL甚至D级都是品质导向级别，那Future和他们并列（而不是attention之类的flag）是什么用意？还有，如果两个专题一个是CL，另一个是Future，而且两者都未设对方的级别，那WPBS到底听谁的？
  - 上述问题可以不断打补丁解决（维基百科:通用評級就是打补丁的成果），但这并非良方。大道至简，最实际的方法是：编者以社群成员的身份，以WP:QUALITY的标准评级中的选项为依据，针对WPBS评级。专题评级理论上和WPBS独立，但实践上的评级方式是信任社群评级。然后，我们讨论WPBS具体该支援哪些级别——对于条目，我建议支援传统级别，或传统级别+BL/CL/(SL?)；而Future、Merge不属于品质评估，而A级又极不活跃常常被人误解，这两类可以考虑从通用级别中除去。至于要修改的地方，无非就是修订WP:QUALITY、WPBS支援代码、class/mask预设启用代码，就像您说的，要改很简单。
  - 您可能看不懂我的留言，也可能看懂了但没有观点。建议您和有实际开设特殊级别的专题联络，看看他们的意见。我可以写出蓝本，但我不想干涉这件事情，也不想在这个物是人非的地方留言。
- @SunAfterRain：我可以當成你是打算擾亂干擾提案通過嗎？！。当然可以！您怎么想是您的权利。--For Each element In group Next（留言） 2024年3月22日 (五) 16:26 (UTC)[回复]
  你以為你維的評級模組是Module:Namespace/data這種隨手改一改就好的是吧，改一次的成本有多高您可以自己改看看，不是什麼看起來很簡單改一改就好--Sun After Rain 2024年3月23日 (六) 03:13 (UTC)[回复]
  我2015年到2016年大幅更改过WPBM相关子模组，比如引入bchecklist。而且如果WPBM不能满足我的需要，我也有能力手写模板。我固然不是A2569875那样的技术专家，但我也知道那些内容属于微调，哪些内容属于重炼。（那时候您似乎还没注册，如果您问一下八九年前一些关注评级的老用户，您大概会知道我都干过什么）
  
  上面的问题我早在两个月前就A2569875君交流过。当时他表示现在只讨论技术问题，具体制度问题可以后议。我的意见不是技术问题——等真正的技术修改部署后，对WPBS屏蔽某些等级就OK——所以的确可以后议。A2569875当时态度很激烈，我不想影响他的心情，而且他应该是没有看懂我的意见，所以我就没有继续争论下去。另一方面如果我做主导人，和议案有关的问题无论在发哪里讨论，我都会接受；而A2569875的思路就是a讨论页不谈b问题（我不知道这是不是今日你维的讨论规矩）。我们俩电波对不上，我也不想在客栈留言，所以就直接走了。现在的论题正是「第三階段（WP:QUALITY_升為指引）討論」，既然是讨论（而不是走形式直接通过）那我充分陈述我对WP:QUALITY的看法很合理吧？而且讨论3月19日开始，我也没有拖到26日要结案的时候发。
  
  就我看来，应该一开始就讨论WP:QUALITY评级这个哲学问题，讨论好方向之后再开始技术修改。而且有了修改体系背书，A2569875的技术修改也能一路绿灯，不用喊「折騰了三個月，我已經沒有修改評級模組的心力了」。不过中维人少，评级哲学上确实没几个人能想到这么深；就像技术方面没A2569875，其他人也推不了这个提案。最后我认为本站应该以理服人，而不是靠方针指引或没讨论深度的「共识」堵嘴：能指出问题的内容标上指引也是根基不牢，有道理的论述没有标签也应该令人尊敬。--For Each element In group Next（留言） 2024年3月23日 (六) 05:29 (UTC)[回复]
  別為你不參與討論找藉口，電波對不上不代表就可以事後再來批判，你說以理服人光是你用這個理由我就覺得你服不了人了
  
  另外你覺得你的意見不是技術問題但事實就是改動不小的技術問題，光是要改動一個分類就要牽涉到多少模板模組了--Sun After Rain 2024年3月23日 (六) 05:49 (UTC)[回复]
  您的考虑方向我很赞同。不过如果例子举成「改动一个模板就会牵涉多少分类的移动」，那会更有说服力 --For Each element In group Next（留言） 2024年3月23日 (六) 06:58 (UTC)[回复]
  你到底在舉什麼...--Sun After Rain 2024年3月23日 (六) 07:28 (UTC)[回复]

上述爭議主要是因為前期討論不夠充分所致。而近期進一步討論已展開，因此可以視為爭議已消失，引此這段「爭議」先關閉，討論主力請移動到這裡來繼續進行，以便凝聚共識。感謝配合。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年6月1日 (六) 10:55 (UTC)[回复]

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

第三階段的重新討論：《頁面評級》指引

已通過：

提案已通過，《頁面評級》提升為指引-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年8月16日 (五) 10:47 (UTC)[回复]

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

首先感謝宇凡君的努力，您辛苦了。順便說一點離題得罪人的話：

标题

目前方針版的種種問題，本質還是來源於青黃不接，人手不足。我所認識的宇凡更擅長技術工作和條目寫作，這次他會跳出來寫方針，相信真的是拖了太久，沒有辦法，只好自己來寫了。維基百科上一代的方針修改主力開始退役，但新一代又還沒有成長起來。這說來也是我們培養新人不力，總之人人都有責任就是了。

目前的問題如要解決，通用評級指引勢必重寫。問題只是要怎樣重寫而已。說白了，洛普利寧是反對通用評級的“由下而上”邏輯，再深挖下去，涉及專題組與社群整體之間的互動問題，對應現實生活中的中央－地方政府間，集權－分權的沖突。這樣展開就顯然太複雜了，我只是希望指出為什麼洛普利寧會認為這個指引寫得不好。

回到維基。儘管從憲法的觀點出發，確立各子組織間的權力分立應是建立規則的第一步，但考慮到中文維基並不怎麼關注這一問題，我就建議維持現狀好了，省得麻煩。反正即使是下而上，要修改專題評級，直接一起修改所有專題的評級就可以（顯然這就一次侵犯了數個專題的自主權，但上面說了，中維人這方面的理解力有限）。下而上的（理論上）優勢當然是“各專題組可以按各自所擅長的領域，共同對跨領域的條目進行評級，會比WPBS只用一個評級員來得準確”。實際上嘛，就是懶得改。

“WPBS评级人是作为什么身份评的”：從下而上的觀點而言，沒有專題組的條目評級，算是社群託管了該條目，留待專題組前來接收，等價於聯合國託管理事會。最終還是需要專題組的專家前來正式評級。

"标准评级":基於減少修改範圍（懶）的因素，建議只容許使用“标准级别”來評級。也就是說，暫時放棄將BL／CL加入WPBS，待更多專題啟用這些評級，更為人所熟悉後，再來討論。future等評級則不容許更新到WPBS上去，機械人應視這些條目為“沒有評級”，由人類前來處理。

最後，感謝@For Each element In group Next：前來，指出這些要點供大家討論。說實話我本來也不想發言的，打了這些東西花了我一個多小時。也希望你能與我一起堅持到這項修改完結。

以上。--Temp3600（留言） 2024年3月23日 (六) 03:33 (UTC)[回复]
如果硬要扯開這個話題，我反倒支持廢掉所有專輯的質量評級全部統一處理，因為你維專題參與人數實在少到除了幾個大專題之外沒有辦法給出一個真的符合自己專題的評級標準，而且去查大專題的評級標準實際上也與通用標準沒有差異，那這樣給各專題評質量有什麼意義？--Sun After Rain 2024年3月23日 (六) 05:54 (UTC)[回复]

（以上沒有要廢掉重要度評級）--Sun After Rain 2024年3月23日 (六) 05:56 (UTC)[回复]
如果完全廢除專題評級，將權力上移給WPBS，那就算不談這種集權行為是否影響了專題組的自治，也需要將目前已經由專題組評級的條目改為WPBS格式，並處理評級不一致的問題。我是不太看好能搞定啦。--Temp3600（留言） 2024年3月23日 (六) 07:10 (UTC)[回复]

@Temp3600：感谢您的解释！虽然讨论很不愉快，但至少讨论者都能理解我要引出的思考点了。现在我的任务大功告成了--For Each element In group Next（留言） 2024年3月23日 (六) 06:58 (UTC)[回复]
喂喂，不准跑掉（ --Temp3600（留言） 2024年3月23日 (六) 07:14 (UTC)[回复]
所以你知道為甚麼我說他明顯有意擾亂了吧（攤手--Sun After Rain 2024年3月23日 (六) 07:26 (UTC)[回复]

隨意的分段

另外回應SAR的是，技術人員與行政官僚本身就是兩項不同的工作，互相批評在我看來並無意義。nerd的下場，可以參考為什麼蘋果公司會趕走喬布斯。--Temp3600（留言） 2024年3月23日 (六) 03:37 (UTC)[回复]
- (：)回應：@Temp3600：最初的提案是Wikipedia:互助客栈/其他#沒有主題的頁面如何評級。起因是我遇到有條目不屬於任何專題，所以如果要評級，會有困難。（所以，我的動機很簡單，我本來就只是在寫條目，遇到了一個問題，我來客棧討論解方，結果折騰了三個月，途中不乏某些維基人精神攻擊，提案看起來快擱淺，精力消磨沒了，寫條目的動力也沒了。在本案開始之前，我一個月寫十幾個條目，本案開始之後，三個月我只寫了兩個條目。）。關於該問題由MilkyDefer給出的解決方案是修改{{WPBS}}，於是開始討論共識並執行，以及其配套的《評級系統缺失案》甚至還因技術需要跑了幾趟phab(如phab:T360012)。因為最原始的目的《沒有主題的頁面如何評級》，代表其討論頁會放置空{{WPBS}}，也就是沒有任何專題的{{WPBS}}，所以當然要能支援填寫所有評級級別，包括但不限於非標準級別（為此，我還特地翻過所有專題、所有維基百科上出現過的評級級別，統整出所有專題定義的所有級別，大概40幾個）。而當{{WPBS}}如果開始填入複數個專題，{{WPBS}}如果又要限制能填寫的級別，程式邏輯勢必變得複雜，所以我的解決方案是不改程式（你知道的，改全保護的程式不是那麼簡單），改立WP:通用評級指引制約，如可能也把評級系統的不同步級缺失補齊，其實目的也就只是《沒有主題的頁面如何評級》而已。而只是恰好Kanashimi要跑評級機器人，所以我索性再修改一下程式，跑客棧共識+公示流程，雖中間與Z7504發生爭議（其實消耗了我非常多精神）但最後都通過了，而「去match Kanashimi機器人」這部分其實已經超出我原本想編寫的程式內容了。後續所有技術案都通過了（過程中洛普利寧在客棧中不發一語）所以程式碼當然不會包含他所期望的部分啊。維基百科是志工性質，不強迫任何人參與，既然我已經寫好我想寫的程式，那我為何還要在最後「可能」可以收尾的時候，幫「洛普利寧的理想」寫程式？程式技術不難，但全保護和繁雜的評級系統，加上客棧不時出現精神攻擊，說實在我的精力已經耗盡。我提供的任何一段程式碼都沒有拿到任何薪水，純粹就是最初我想做、我想解決某些問題，但像現在這樣節外生枝是否生得太誇張了？-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月23日 (六) 04:13 (UTC)[回复]
我想，在洛普利寧的心中，他在最初就已經您解決了你的問題：維基百科有一個萬能專題{{WikiProject Article assessment}}，你只要將沒有專題的條目通通添加到這個專題下就可以，問題立刻解決，不需要碰WPBS。我也認為這是最簡單的方法。只需要跑一次機械人，把所有沒有專題的條目全部加入WikiProject Article assessment，就可以了。

順便一說，我自己也試過幫助條目找專題，但即便有新rater的協助，仍然很難。最大的問題是，我不知道有那些專題存在，又不知道他們的簡寫。如果宇凡你能改良rater，讓程式可以搜尋，甚至推介專題給我來選擇，會很有幫助。比如有一個英國足球隊條目，但還沒有專題，但分類已經寫了這是英國條目，rater能不能夠提示我加入英國專題（或者別的甚麼專題？）。

如果不行，可以考慮一個簡單一點的修改方案：當條目沒有專題時，rater預設添加WikiProject Article assessment，就可以照常評級了。

但現在WPBS已經生出來了，總不能走回頭路。但這個也不容易，一會兒再寫。--Temp3600（留言） 2024年3月23日 (六) 04:47 (UTC)[回复]
@Temp3600：這完全不是什麼兩種不同工作的問題，有意見之前重寫模組時一起納入考量重寫就好，那時候提出我想娜娜奇也會盡可能配合的，但洛普利寧同學是喔我支持改寫，人家寫完都開始運行了再來抱怨。不要跟我說什麼滾動式修正，他提出的意見很顯然不是因為模組上線才出現的。--Sun After Rain 2024年3月23日 (六) 05:38 (UTC)[回复]
然後回到“Template_talk:WPBannerMeta#編輯請求_2024-01-08”。洛普利寧的批評是對的：宇帆在這次重構中，只考慮了技術層面上如何實行WPBS的改版，忽略了行政上的架構問題：所謂通用評級，由於每個條目只能有一個，客觀上就有壓倒原來專題評級的意味。於是這就進一步產生了通用評級與專題評級的沖突，新建立的WPBS機關在權責上如何與原來的專題委員會劃分的問題。現在那些WPBS有沒有CL級，未來級的問題，本質上都是沒有完成項目定義就急於進入開發階段，結果現在開發成果不完全符合要求，但是要再更改，工作量又很大，於是卡住了。

所以現在還是要回到那個編輯請求，解決掉1月時的問題。然後由於技術負債，問題要盡量靠行政程序解決。這就是目前的工作。
宇凡那時的觀點，也不能說錯，畢竟維基百科也沒有技術可以阻止你發侵權垃圾內容對不對，但是我們有行政手段，有制度可以將侵權內容透過刪除頁面功能處理掉。我估計這邊最後也會採用相同的方向，WPBS模版支持很多參數，但在指引中，會指明只有部分參數才可以合法使用，如果用了其他值，即使能夠正常顯示評級，其他人也可以回退，警告這一套。--Temp3600（留言） 2024年3月23日 (六) 08:43 (UTC)[回复]
@Temp3600：問題就出在於，最早MilkyDefer的起草就有未來級、CL級等等，然後我還Ping了洛普利寧問他這樣可不可以，但他完全沒有任何答覆，到頭來還是只有一句「精神上支持」，我怎麼知道問題在哪，直到一月開發完成才開始說這裡不對、那裏不對，這樣我是要怎麼搞。反而User:Willy1018事先指出了具體問題，我得以依照他的問題在開發階段先行解決，並讓User:Willy1018說出了「感謝貢獻，目前已覆核已符合預期。」。完成後才再修改成本比較高，一開始又不講清楚，說完「精神上支持」然後跑掉，然後現在爭議後要叫我扛責任。我這樣消磨掉的精神狀況可能需要去放維基假期了-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月23日 (六) 09:00 (UTC)[回复]
A2569875：首先向您道歉，我没有及时回复您的提醒，在1月份的讨论中，我也没有坚持将意见表达清楚，因为我认为您将来会用掩蔽代码的方式处理WPBS评级。我也知道了为何SunAfterRain君会将我提报到破坏区。其次感谢您完成了迄今所有的技术工作。我的意见是针对政策层面，亦即评级体系如何开展。我不参与客栈讨论，亦不会干涉指引讨论的工作；因为很多等级都是我带起来的，我这次只提出我的想法，希望让社群自行讨论如何评级等级。如果讨论结果是敲定启用或不启用某些等级而需要修改模组，而您疲于修改模组，我可以参与技术工作吗？最后就像Temp3600君所言，在下确实有责任。--For Each element In group Next（留言） 2024年3月23日 (六) 09:40 (UTC)[回复]
(＋)支持User:Temp3600提的：不當使用WPBS參數時，其他人也可以回退，警告這一套。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月23日 (六) 09:11 (UTC)[回复]
如果能夠masking掉WPBS旳等級，待日後成熟等再開啟，那自然是最好；不行的話，單改指引也算是解決了問題。--Temp3600（留言） 2024年3月24日 (日) 03:25 (UTC)[回复]
另外拖@MilkyDefer：出來，future grade 條目要直接沿用還是怎樣處理(pia!) --Temp3600（留言） 2024年3月24日 (日) 03:33 (UTC)[回复]
什么叫沿用？事实上我连现在future grade的使用情况都不是很清楚，可否说明一下背景信息？--MilkyDefer 2024年3月24日 (日) 03:55 (UTC)[回复]
@MilkyDefer：例如en:Talk:Texas_State_Highway_32按你的構想，是什麼評級。背景資料....按我很初步的認識，英文WPBS的條目評級系統只容許BCStub等標準評級，但專題組可以按各自需要將條目評為future級等特殊等級。這與目前WP:QUALITY中建議的評級方案並不一致。--Temp3600（留言） 2024年3月24日 (日) 04:05 (UTC)[回复]
有什么……不一致吗？Future Class列在非标准等级下，并且写有“部分專題還會啟用附加等級。”看上去挺一致的欸。--Milky Defer 2024年3月24日 (日) 04:36 (UTC)[回复]
咦我寫錯了...en:Talk:Texas_State_Highway_32如果按维基百科:通用評級，它下面只有一個future-class的專題評級，那麼就不能評為stub.在我看來這是問題。--Temp3600（留言） 2024年3月24日 (日) 05:01 (UTC)[回复]
en:Template:WikiProject U.S. Roads列在en:Category:WikiProjects using a non-standard quality scale，因此此篇文章的評級沒問題。我覺得WPBS的評級主要是條目整體評價，在zhwiki實施起來基本上也是這個目的。只不過 zhwiki評級似乎比較複雜，所以允許各專題自訂標準，每個專題模板都算non-standard quality scale。這部分實施起來，其精神與enwiki也相同。--Kanashimi（留言） 2024年3月24日 (日) 05:12 (UTC)[回复]
按英文版的評級方式是沒有問題，但來到中維，维基百科:通用評級並不是英維的對等翻譯。於是就有了"若一條目僅有一個專題，其通用評級應與該專題所評的等級一致。"這樣的條款，影響到WPBS專註在內容評級的工作。順帶一說，這一點也和LP為什麼建議全面轉用英維制度，將內容評級由專題組上提到社群的精神一致。不過這樣就涉及更複雜的改動，恐怕還是免了。--Temp3600（留言） 2024年3月24日 (日) 05:30 (UTC)[回复]
我個人覺得這一條僅限於單一專題模板採用標準評級的情況下才有效。但假如所有專題模板都屬於 non-standard quality scale，則不如廢掉。--Kanashimi（留言） 2024年3月24日 (日) 05:49 (UTC)[回复]

@Temp3600：我覺得像Future、Current（某主題是否是新聞事件或未來事件完全取決於專題領域，例如某主題在A領域可能是一件大新聞，所以評Future，但另一個領域關它屁事所以評甲乙丙丁初之一）Merge、Need（這種通常都是向特定專題請求重定向擴充為條目的標記，無關專題就標通用評級的 重定向级吧）這些「聚焦於特定專題」的級別就讓相關的專題沿用吧，然後從通用評級的標準評級撤下變成非標準評級，我想問題應該就解決了。修訂的部分，我想等到下面確立哪些要設為標準評級之後，再將通用評級指引加上「只能用標準評級」之類的規範應該就能從行政手段解決了。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月26日 (二) 17:36 (UTC)[回复]
另另外我約略看了一下英維，看來它們已經將各專題評級整合起來，會個條目只有一個評級。這是你提出由上而下的背曔原因嗎?@For Each element In group Next：--Temp3600（留言） 2024年3月24日 (日) 03:38 (UTC)[回复]
我也认为WPBS是社群基于标准（WP:QUALITY）对条目做出的评价。当然，社群也允许专题依照自己的标准对条目做出评价，并标记在讨论页上。某种意义上，社群评级和专题评级是「人格独立」的，这里的「上」和「下」更像依赖的上下游，而不是官大一级的上下层。然后既然专题评级是独立的，那专题就可以选择各种策略：
- 社群人多力量大，自行评级太繁杂，WPBS填啥我填啥。（看起来就像评级被废了，但其实是选择和WPBS的做法一样）如果对专题成员评级不服，要么以社群成员身份找社群吵，要么推动专题退群。这就是英维绝大部分专题的策略。
- 预设继承社群评级，但也可以自行覆盖社群评级。这就是我们现在的状态。
- 不继承WPBS的评级，只要自己的class不填就是未评级。英维的退群专题（比如有BL的WP:MILHIST、没A的WP:VG）都是这个策略。不排除有些专题是想自己搞；但也有专题是只开除掉A级，其他等级想继承社群，但因为英维技术不支持策略2而被迫退的。
像SunAfterRain说的，绝大多数专题用策略1就够，而且理论上标准相同的专题应该评同样的等级。个别专题有特殊的评级标准，那就采用策略2。真有专题完全不想社群插手，那就上策略3。策略1那就是纯粹的自上而下了。此外，对上游的WPBS规定好标准等级后，将非标准等级映射到标准等级（假设规定BL->List、D->Start、Current->Unassessed），也可以让机器人参考策略2和3的专题填WPBS。
自下而上主要还是一堆奇葩等级，逻辑上没法搞。刻度尺测量物体长度，得到的结果应该是稳定的；一次测3 cm、一次测5 cm，就说明测量错了。但如果两次测量都操作无误，那你用的大概不是尺子 WPBS本来评CL，因为来了个不支持CL的专题就改评List，两次评级都没有错，这就说明该制度不适合衡量条目品质。如果将奇葩等级改成WPBS标准评级，或者拒绝参考非标准等级，那这个制度就可行；但这基本就又成了上面的问题。--For Each element In group Next（留言） 2024年3月24日 (日) 16:21 (UTC)[回复]
- 我覺得改動WPBS最少的可能是將所有「條目品質性」（甲乙丙丁初等）和「非條目類別性」（Disambig、SIA、Template等）的級別全部設為標準評級（含少數專題另設的Bplus和D、以及很少專題用的A級等[有專題用A級，如颱風之類的專題。]），「性質性」（Future、Current等）的級別全部設為非標準評級。這些「與條目品質無關」的評級就讓專題自己評，不影響WPBS，就不會出現要在CL級或Future級取捨的狀況了。然後各自專題不要的，自己去mask（到時全站公告一下，想接受的專題就接受，不想接受的專題就自行寫mask，這樣寫mask的責任就不會在此次修改上）。技術上成本最小。只不過以上作法因會將AL、BL、CL、SL也列入標準級別，代表List級別可能會變成沒有任何頁面會被評成List級，看是要廢除List級還是保留List級在代碼裡，不想跟進的專題自己mask。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月25日 (一) 04:43 (UTC)[回复]
- 然後主題專題自設的Complete、Substantial、Basic、Incomplete因WPBS預設在非條目命名空間時會因「Namespace優先」而評成「主題級」，所以我想應該也問題不大。如需在WPBS中禁掉，可可以將Module:PJBSClass#L-53的一堆if陳述式註解掉。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月25日 (一) 04:57 (UTC)[回复]
  - (～)補充提升為標準評級的級別：
    典范级、甲级、 优良级、 乙上级、乙级、丙级、丁级、初级、 小作品级、（ 小小作品级待討論，因為通常30天就被刪除了或提升為 小作品级以上）、 特色列表级、 甲级列表级、 乙级列表级、 丙级列表级、 列表级、 小列表级，以及列在Category:自動評級的頁面#分類索引中的所有評級（即一系列可由WPBS自動完成評級的級別）。
  - 設定為非標準評級的級別：
    动态级、 未来级、 合并级、 请求级、 搁置级-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月26日 (二) 02:16 (UTC)[回复]
  您说的也是可行方案。目前启用BL、CL的专题，List基本都是当和Start对等的级别来理解；如果都接受List级=初级列表，而不用新建等级，那留着List级也OK。唯一担心的是A级，倒不是有没有人用的问题。A级是高于GA的，英维也是A级评级比GA评级规格高：GA可以随便一个外行评，A级专题内部出三个专家评，FA是包括专题专家在内的社群集体评，所以有FA>A>GA的逻辑链。但是我们的FAC/GAN和英维评级模式完全是两码事，到头会不会还是社群认GA不认A？--For Each element In group Next（留言） 2024年3月25日 (一) 14:33 (UTC)[回复]
先多謝各位，意見都很有見地。希望在上方再拆一個小標題。A級與GA的問題是老大難了，我想這次還是先不處理為好。A級雖然很少用，但一直都算是標準評級，現在一下子移除不太好。List級對等於初級列表長遠是好主意，但要標記清楚，因為許多舊列表是list級。所以現在list級代表初級或以上的列表。或許長遠要建立start list?—Temp3600（留言） 2024年3月25日 (一) 23:35 (UTC)[回复]
- 現階段我不太建議增加或減少評級級別，因為除了要修改十餘個模組、模板外（不少是全保護），還需向phab報工單更新xtools資料表……；就算技術都就緒，考慮到同時影響近百萬個頁面清緩存，還需等待數天至數週不等……，麻煩程度堪比……（唉）。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月25日 (一) 23:44 (UTC)[回复]

D級與B+級等標準討論

接上文宇帆君列出的等级。新级别是要写文档的，所以下列意见供参考：

D级目前看来只有宇帆君活跃的多面體在用，其条目是介于C和Start之间。讲真，流行文化领域，因为关注粉丝向这种扣分内容，D级还是很好用的。
- 比如明星条目，内容上已经有C级该有的内容，但因为很多内容都以粉丝介绍口吻出现，需要大量清理和改写；这时评Start太可惜，就可以评D级。这基本就像多面体专题说的，「内容上可能达到C级水准，但其他方面有严重缺陷」。或者说，写条目的人擅长事实性内容，但不了解这里的格式手册，写出的东西很随意不像百科。
- 另一方面，虚构作品条目也强调要写反响等现实世界内容。一般来说，编者不写现实世界内容，就表示他不熟悉格式手册，所以条目格式、行文等方面也不会太好。这种条目又要清理又要扩充，就可以给Start。但也有从英维FA翻译一半的，条目序言完整、作品介绍也很规范，但该到制作历史和评价，他又他不翻译了。这种只用扩充不用清理的，也可以从Start抬升为D。
- 可以看到，流行文化领域这个D级主要还是可以彰显「内容杂乱/格式差」。但科学等领域大概没有「粉丝内容」，所以这个D级通常会怎么用？
- 另外有了D，是不是未来有可能对等增加DL？
B+只有英维数学专题有用过，而且现在删了；本地没有专题实装过，只在一些理论研究中提到，所以还是要想想标准怎么订。
- 之前B+的评级标准是「条目高于B级标准」，再把B级标准抄了一遍，这就比较不良定义。GA和B的区别主要在GA还要求中立性稳定性，且文笔和格式的要求高于B。如果要搞B+，那标准大概就是「不要求中立性和稳定性，但其他方面同GA标准」？PS：B6提到的WP:JARGON和地区词在GA标准里没有体现，所以B在某些方面还高于GA；不过现在的英维已经把JARGON要求增补到GA标准里了。
- 之前有提过增设优良列表（GL）。GL和FL的主要区别可以理解为GL不管红（绿）链，且序言不用太优美；这个境界就有点像B+和GA了。不过，FL和GL应该是要有本质差异的——类似WP:GVF的comperhensive和board coverage。例如对于游戏系列，FA应该像死忠那样列出小众改编作品，而GA可以只列出重要作品。（但是很多领域列表是不是没有这种问题？）
小小作品更像是一个临时状态，和未评级一样是不该长期存在的。而且小小作品只是长度短，问题还没有广告、侵权等小作品更严重，所以整体统计上把小小作品拆出来的意义是？从维护追踪角度考虑，WP:PETSCAN或者Shizhao的专题机器人通告应该都很好用了。--For Each element In group Next（留言） 2024年3月26日 (二) 15:50 (UTC)[回复]
- 感謝提供意見。關於增設新評級級別，如您提出的D-List和Temp君提出Start-List以及上述提到的GL，我想作為長遠目標來討論，現階段先不處理。一來是phab:T360012本站評級資料表更新工單根據API測試似乎已合併到主程式，而GL則是因為評選設立草案無共識所以工單中就沒有申請加入該等級，所以就算現在評了GL可能也無法被某些系統正確識別，同時，一直頻繁變更感覺對基金會人員也不太好意思；二來是又要改十餘個全保護模板了 囧rz……。（註：如果說有了D就要對等增加DL，那為何有了GA沒有對等增加GL😅 甚至圖片有「特色圖片」若對應FA的話，那為何沒有GA對應「優良圖片」、A對應「甲級圖片」、B對應「乙級圖片」^{[開玩笑的]}）另外您提供的D級條目用法也十分不錯，我(＋)附議這樣子的用法，科學上可能可以用在使用了太多行話術語導致多數人看不太懂的這種情況吧；而Bplus 我這邊是暫無其他想法，如果有其他維基人有什麼想法歡迎補充；小小作品級是當時評級系統開發階段進行測試時增加的級別，當時我找了幾篇正文少於50字的條目但沒被掛小小作品模板的「老條目」評上了此級，來試驗系統能否接受輸入，不過後來這些條目一些被提交AFD了、一些被擴充成小作品級了，但考慮到條目如果持續擴充也會持續升級啊，例如小作品升初級，這只是換成小小作品升小作品級而已，只是通常條目停留在 小小作品级的時間可能會非常短而已。另外，我前幾個小時仔細重看了一下每個級別，發現比較有問題的應該是deferred級（中維評級系統本次更新完顯示為 搁置级）經查，該級別於2015年被加入中維評級系統資料表中，但在WP:TG簡單討論並對照英文維基還有此級別的專題說明顯示，該級別代表的意義是「本專題不提供評級，轉介由涵蓋本專題的專題提供評級」所以可能也不叫做「 搁置级」，TG上有群友建議「轉介級」，不過這種級別對上通用評級的話，基本上存在感就沒了，~~阿卡林～~~，不過UUM表示這種轉介具有一定程度「重要性」，可能要討論一下，看是要改名還是乾脆就廢除掉，或者以「未評級」論之類的。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月26日 (二) 16:52 (UTC)[回复]
- 感謝宇凡的研究，這個轉介級我都沒聽說過。評級級別方面，宇凡君所指的技術困難確實存在，就像我們這幾天討論了一下，又想到找到這麼多評級。如果每次都去phab改，不免擾民。我初步的想法是，quality 指引的標準評級部分建立為指引，規定wpbs 目前社群認可的評級；專題評級維持論述級，方便專題修改，待有共識後再處理。至於wpbs模版，則不需修改原碼，只需在模版說明頁等寫清楚那一些評級因尚未有廣泛共識，暫不開放使用，就可以了。
- 標準級方面，我比較關注CL與乙上，大家懂不懂得評。雖說當成推廣也無不可。—Temp3600（留言） 2024年3月26日 (二) 23:53 (UTC)[回复]
  - 那我們現在就先以已登記於phab的級別為主，也就是我上面列出的那些以及列在Category:自動評級的頁面#分類索引中的所有評級（即一系列可由WPBS自動完成評級的級別）。CL級標準之前已經訂清楚了，所以我想，直接設為標準沒有問題，(＋)支持作為推廣；比較需要討論的會是 乙上级。我想就用洛普利寧提出的「不要求中立性和稳定性，但其他方面同GA标准」如何？@Temp3600：-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月27日 (三) 01:11 (UTC)[回复]
    - Template:Grading scheme可能也有關連，描述可能需按這兒的討論結果一拼修改。--Temp3600（留言） 2024年3月27日 (三) 04:50 (UTC)[回复]
      B+在我心中是"沖擊優良但失敗了"的意思(pia!)--Temp3600（留言） 2024年3月27日 (三) 09:53 (UTC)[回复]
      (？)疑問是指參選GA不幸落選，還是「已撤銷的GA」？-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月27日 (三) 10:09 (UTC)[回复]
      在我心中，B+是參選人認為有GA的水準了，先填一個B+，然後填上評選。評不上就只好卡在B+了（pia!)--Temp3600（留言） 2024年4月2日 (二) 11:24 (UTC)[回复]
      (：)回應@Temp3600：那結合下方的留言，我想我們應該已經對B+的標準有了初步共識了吧。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年4月2日 (二) 11:29 (UTC)[回复]
      同意。但quality還沒有B+，看來要先寫上去？--Temp3600（留言） 2024年4月2日 (二) 11:37 (UTC)[回复]
  - (～)補充轉介級有登記在phab上，只不過登記成了 搁置级；但如果又要去改，感覺沒幾天就又要去麻煩基金會技術人員好像不太好……因為2015年就這樣寫了，就先當歷史遺留吧😅-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月27日 (三) 01:17 (UTC)[回复]
    - 關於「轉介級」（現稱 搁置级），其也是目前中維{{WPBS}}可填的參數之一。您認為應該要如何處置呢？翻閱en:Wikipedia:WikiProject_Firearms#Quality_scale他似乎把它視為「品質等級」的一種，但實為將評級工作轉介至其他專題，然而如此的做法在有{{WPBS}}時就沒有存在意義了，因為轉介最終就會落回給{{WPBS}}提供評級，所以英文維基{{WPBS}}實施後其有關分類就被WP:O4了（他們好像叫做en:WP:CSD#C1），那所以我們應該要把他列為「非標準級別」還是直接列為「已停用級別」即在{{WPBS}}的Doc上說不要輸入此級別？-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月31日 (日) 10:08 (UTC)[回复]
      在WPBS而言，轉介級我覺得可以停用。。。它的原意應是“這個專題不評級，留給其他專題來評”，但都來到WPBS了，還可以轉介給誰呢？--Temp3600（留言） 2024年4月2日 (二) 11:32 (UTC)[回复]
      (？)疑問@Temp3600：是全面（對所有的專題）停用嗎？還是先暫時只對WBPS停用？-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年4月2日 (二) 11:36 (UTC)[回复]
      噢，我的意思是與英維一樣，通用評級不可以填deferred，專題組可以繼續用。--Temp3600（留言） 2024年4月2日 (二) 11:42 (UTC)[回复]
      也對，畢竟WPBS基本可以視為評級的最上級單位了，沒有更上級了，填deferred感覺不太合理（轉介對象不存在。轉給維基媒體基金會^{[開玩笑的]}）。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年4月2日 (二) 12:46 (UTC)[回复]
（有感而發）除了本子節開始的爭議外，以上討論與研究其實都滿有意義和價值的，如果能提前在去年十二月，也就是我當初Ping了洛普利寧時，他就發表了這些意見，並開展了我們現在所討論的東西，那我覺得WPBS應該會更完美。不過現在說這些都是後話了。另，跟大家說聲抱歉，我當時一心只想著如何把MilkyDefer起草的臨時方案開發成正式方案、如何pass所有testcases 和解決討論頁上各種問題回報（1、2等），一切考量都以技術為優先（我當時優先級最高的考量是：程式怎麼寫更省效能，於是出現了mw.loadData("Module:PJBSClass/page")用於讓該功能在整個頁面解析的過程只會跑一次，而不會每次調用通用評級時都跑以節省效能），卻忽略了行政上的執行問題，而導致了今次的爭議，我感到十分抱歉。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月27日 (三) 01:30 (UTC)[回复]
- 所謂「話到嘴邊留半句，理從是處讓三分」，我覺得是挺有道理的。得饒人處且饒人嘛。(當然這得看對象，要是遇到得寸進尺的惡人，這樣就行不通)
- 如果說程式碼是機器運行的邏輯，那麼行政可說是人類組織運作的邏輯。要做好事情，既需要機器運作暢順，也需要眾人合力。不同維基人從各自的強項出發，一起解決問題，這就是討論的意義嘛。--Temp3600（留言） 2024年3月27日 (三) 04:47 (UTC)[回复]
  - （(＊)提醒：本次提案推動技術修改的兩位「工程師」（User:Kanashimi、User:A2569875）都沒時間寫程式了...雖然我的原因是因為改到沒精力了）。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年4月1日 (一) 02:00 (UTC)[回复]
    - 维基百科:通用評級與WP：QUALITY都要弄修改草稿，行政組這邊也不好當呢...--Temp3600（留言） 2024年4月2日 (二) 11:40 (UTC)[回复]
    - 从这里入手，在Module:Class/conver外再套一个函数，把不支援的评级映射到未评级可行吗？--For Each element In group Next（留言） 2024年4月2日 (二) 16:31 (UTC)[回复]
      - (－)反对我想保留這些自動評級Category:自動評級的頁面#分類索引，不然phab白跑了。而且不想被濾的專題也會被你一刀切不當濾掉。後果不會是你想像的那麼簡單。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年4月2日 (二) 16:41 (UTC)[回复]
        自动评级的页面基本都是非条目，那不是属于PJBS支援的范畴吗……？对于条目，如果按照上面WPBS作为独立评级的思路，那PJBS就只应接受他自己的等级。比如PJBS不支援current，那PJBS的class就不应该填current（如果一定要填current，那PJBSClass.getClassByPage()也应该返回未评级）；所以到头来，WPBS只会告诉各个专题自己未对此页面评级。既然WPBS理论上都不会填写current，那支援current的专题就只能手填自己的class；据我所知，专题自己填写的class是优先的，那这时只要对专题模板自己的class套用Module:Class/convert规范化就OK。宇帆君的代码很模块化（不像我写代码什么东西都揉一起😂），我想这个问题应该的确不是复杂问题。当然，如果我们的总工程师说复杂，那就是复杂😂 另外，如果思路确实是要WPBS兼顾所有专题，比如PJBS评级未显示但往外传current，那这个想法就的确不成立了。--For Each element In group Next（留言） 2024年4月3日 (三) 14:16 (UTC)[回复]
        
        另外即使我的意见合理，宇帆君您也没有义务在近期执行技术修改（甚至没必要执行修改）。毕竟「这个想法很好，但碍于技术原因，目前无法实现；欢迎提议人自行解决」也是合理意见😂--For Each element In group Next（留言） 2024年4月3日 (三) 14:33 (UTC)[回复]
  - 感觉还是社群没有体系性讨论。比如日语罗马字表示方法讨论过好几次，但正经的日本格式手册却现在还推不出来。我之前不留言，基本也是感觉本站没救，什么都懒得说😂 当然只限条目编写方面；站务领域我看讨论挺热烈的。

B+我之前写过论述。鉴于中维的GAN机制（时间短、需求票数多，且评审者普遍社会惰性），B+当GAN预审还是很有生态位的。但是在务实上，等GAN评审素质普遍超过这个乙级评级，B+才会有得玩耸肩

我想B+（Bplus）的标准可以用WP:WIABCA的大纲来套用WP:WIAGA：

BP1 来源：所有断言均可查证、无原创研究；来源依版面佈局指引列出；特定资讯需内文引用可靠来源。

BP2 内容：介绍主题的重要方面；聚焦主題而不深入无谓細節。

BP3 结构：内容组织得当，，遵循版面佈局，含序言章節以及此类条目应有的章节。

BP4 行文：文字簡潔明了，遣词得当，无别字和语病；虛構事物和嵌入列表需遵循格式手册。

BP5 配图：若可行，则配以插图解说；圖像符合版权要求，且以題注妥当说明。

BP6 易读：行文应尽量让相应受众理解，包括解释或避开技术术语，处理地区词差异。

这样B级评审时也顺手按GA（B+）提意见。--For Each element In group Next（留言） 2024年3月28日 (四) 14:20 (UTC)[回复]

WPBS級別列表

目前{{WPBS}}能接受輸入的級別大部分都是phab:T360012向P站登記的級別以級在案《第一階段：修正評級值不同步問題》時所有評級Data模板統一同步更新的評級值列舉如下（共50個。此外由於表格過長，已折疊。請單擊[顯示]以展開表格）：

{{WPBS}}能接受的值
	標準類別級別		標準品質級別
	非页面级	（條目）	典范级	甲级	优良级	乙上级	乙级	丙级	丁级	初级	小作品级	小小作品级	无级
	非页面级	列表级	特色列表级	甲级列表级	优良列表级	N/A	乙级列表级	丙级列表级	N/A	小列表级			N/A
	非条目级	文件级	特色图片级	N/A
		主题级	特色主題	N/A			完成级	充實級	N/A	简单级	N/A
		消歧义级	N/A
		同类索引级
		重定向级
		沙盒级
		模板级
		模块级
		分类级
		草稿级
		专题级
		用户级
		使用说明级
		界面级
	非標準類別
	图书级
	音频級
未分類級別	非標準級別
N/A	未来级	动态级	合并级	请求级	搁置级
委员会级	N/A
錯誤級
未评级
未知级
輸入其他值{{WPBS}}會輸出：錯誤：無效的輸入

能夠由{{WPBS}}程式自動評級的級別（詳情）
典范	特色列表	特色图片	优良	小作品	列表	同类索引
消歧义	重定向	沙盒	模板	模块	分类	文件
草稿	主题	专题	用户	使用说明	界面	非条目

以下建議供行政組參考：

標準品質級別（可填寫在WPBS）：
典范级[FA]、 特色列表级[FL]、 特色图片级[FM]、甲级[A]、 甲级列表级[AL]、 优良级[GA]、 乙上级[B+]、乙级[B]、 乙级列表级[BL]、丙级[C]、 丙级列表级[CL]、丁级[D]、初级[Start]、 列表级[List]（暫時作為初级列表使用）、 小作品级[Stub]、 小列表级[SL]、 小小作品级[Substub]、无级[No]

標準類別級別（可填寫在WPBS）：
消歧义级[Disambig]、 同类索引级[SIA]、 重定向级[Redirect]、 沙盒级[Sandbox]、 模板级[Template]、 模块级[Module]、 分类级[Category]、 文件级[File]、 草稿级[Draft]、 主题级[Portal]、 专题级[Project]、 用户级[User]、 使用说明级[Help]、 界面级[interface]、 非条目级[NA]（如TimedText:空間）

非標準類別級別（不應該填寫在WPBS）：
图书级[Book]（曾有共識引入，但因技術原因部署無限期推遲）、 音频級[Audio]（只有少數專題將File級做細分，WPBS應都填入File級）、圖像級[Image]（(▲)同上）、 非页面级[NAPage]（只用於特殊專題）

非標準品質級別（不應該填寫在WPBS）：
优良列表级[GL]（討論尚無結果）、 特色主題[FPO]（未通過設立）、 完成级[Complete]、 充實級[Substantial]、 简单级[Basic]（完成、充實、簡單僅用於PJ:主題）

非標準級別（不應該填寫在WPBS）：
未来级[Future]、 动态级[Current]、 合并级[Merge]、 请求级[Needed]、 搁置级[Deferred]、

技術性級別（不應該填寫在WPBS）：
委员会级[council]（僅做圖示用途，不應手動輸入此級）、 錯誤級[Error]（出錯時會自動加入，不應手動輸入此級）、 未评级[Unassessed]（無提供時自動產生，不應手動輸入此級）、 未知级[Unknown]（無法正確識別的情況，應修正之，而不應手動輸入此級）

-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年4月6日 (六) 03:43 (UTC)[回复]

感谢总结。我有一些疑问：

Substub作为标准品质，似乎比较增加维护负担？会创建小小作品的基本都是新手，他们不懂得在讨论页挂{{WPBS}}填|class=substub。维护人员也都在条目页标记{{substub}}，然后打捞人员再从Category:小小作品追踪，这就基本就没人会管讨论页。而且就算有专题模板，如果利用讨论页的分类来维护，就要从讨论页跳转到主页面，也是比较低效的。（MilkyDeferBot可以根据讨论页横幅和条目页{{substub}}自动生成页面列表，这样也没必要用讨论页评级）此外如果substub是被人手填了，那就还要经常盯着条目，看评级是否过时。所以依靠评级模板来维护substub，感觉有种打捞一分钟，评级三十秒，性价比相当低。所以，WPBS层面统合到stub是否好些？
正规条目都应该有品质评级，尚未评估品质的条目是Unassessed，条目空间的Disambig等特殊页面也考虑进去了。看英维也没no这个级别，所以无级别的条目会是怎样的？

--For Each element In group Next（留言） 2024年4月6日 (六) 05:20 (UTC)[回复]

(：)回應@For Each element In group Next：no級（无级别）是由您建檔於評級系統的Special:Diff/72525905#L-149，我只是照抄，並同步到所有評級模板，以及提報到phab:T360012上。所以我也不知道具體會是甚麼，可能還需要諮詢您（因為由您加入的）。我在整理時看到它的理解為「沒有級別的」但我當時沒有仔細思考甚麼條目或頁面會「沒有級別」，您能否協助回想一下當時的時代背景下，您建檔No級時的想法或根據呢。 小小作品级我認為是有些條目可能加上了資訊框、圖片等被WP:小小作品指引PASS而保留，但正文還是不足50字的情況下可以評（我就是有用隨機頁面看過有很舊的頁面有這種狀況，但因為它是甚麼我沒聽過的小城鎮的條目，我不熟就沒去擴充，繼續按下一個隨機頁面）。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年4月6日 (六) 05:56 (UTC)[回复]
@A2569875：最早的时候{{Classicon}}里就有no级，我也是从那里搬过去的。做页面列表的时候可能会用到no这个概念，比如这个从英维搬运的名单，no可以用来标记不挂专题横幅的条目。至于用no给条目本身评级，我倒是没见过。
我明白您说的小小作品级了，这和WP:SUBSTUB又是两个概念，就类似「小作品级」和「小作品」了。我是认为对这么短的条目，精确数50字感觉都浪费时间（反正多20%到60字也一样很烂😂）。如要设立这个级别，换成「正文只有一两句话（约50字以下）的条目」，这样大概看下数量级会比较实用。当然我就只是抛个砖，评级能弄下去还是靠大家，所以这还是看看其他人有什么想法吧。--For Each element In group Next（留言） 2024年4月6日 (六) 06:16 (UTC)[回复]
- 所以沒有級別（no）是指未建立或已刪除的條目嗎（紅鏈）？這樣可能真的評不了 囧rz……，因為如果在一個紅鏈條目的討論頁掛一個{{WPBS|class=no}}就構成孤立頁面會被速刪😂，如果是刪除後建立成重定向頁也不會是no級會是redirect級。所以no級可能就變成一個永遠不會被填進{{WPBS}}的概念級別了。是否當作標準級別我覺得可以，畢竟您說了做页面列表的时候可能会用到no这个概念，那它應該列入標準，只不過這個標準級別可能永遠不會被填入{{WPBS}}罷了。 小小作品级我也想等看看其他人的意見。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年4月6日 (六) 06:29 (UTC)[回复]
  其实说no这个概念也不准确。英维早把不用的图标和等级（包括bplus和no）删了，中维就各种「集大成」从来不做减法，所以留下了一堆未定义的东西。我上面的用例准确来说，是页面已经建立且可能被WPBS评级，但因为没有挂游戏专题的横幅，所以表现出未由游戏专题维护。既然游戏专题不维护，那在专题内部就不用关心页面品质；但是所有页面都有图标，你不放个东西也不好看，所以才放了个图标。或者说，语义上这里应该用{{icon3|Wikivoyage outline icon.png|alt=未标记专题横幅}}，但因为偷懒才用了{{class/icon|no}}；毕竟从分类中根本抓不到no级，这里还是if判断页面已建立但未标游戏横幅，为True才拉到这个分类的。--For Each element In group Next（留言） 2024年4月6日 (六) 06:52 (UTC)[回复]
  已統整進#等級標準草案。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年4月6日 (六) 14:47 (UTC)[回复]
  - (：)回應：@For Each element In group Next：@洛普利寧：我知道甚麼東西可能是無級別條目了，大概是Category:维基百科纲要，這些條目基本是點列式（如戰爭綱要），讓人了解「主題綱要」之用。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年4月21日 (日) 01:31 (UTC)[回复]
    纲要也有完整和不完整的区别。这个相当于列表，也有级别。写得完整点的纲要就是CL/BL。--For Each element In group Next（留言） 2024年4月21日 (日) 03:35 (UTC)[回复]

等級標準小結

洛普利寧在上文提到的「PJBS之PJBSClass.getClassByPage()」自動評級（小勘誤：自動評級實由PJBSClass/main.getClassAuto()和PJBSClass.getAutoClass()共同完成，前者以頁面狀態和掛有模板判斷、後者只看Namespace），這些評級會根據頁面掛的模板、子頁面名稱、頁面狀況和所在命名空間等進行自動評級。這些評級分為兩類：不可被|class=參數複寫的評級以級可被|class=參數複寫的評級。

這些級別有：

不可被|class=參數複寫的評級： 重定向级、 特色图片级（註：|class=有值時會強制被改為File級）、 模板级、 模块级、 分类级、 文件级、 草稿级、 主题级、 专题级、 用户级、 使用说明级、 界面级、 非条目级
可被|class=參數複寫的評級： 典范级、 特色列表级、 优良级、 小作品级、 沙盒级、 列表级、 同类索引级、 消歧义级

上文提到，目前不在WP:QUALITY中的級別都需要補上文檔，因此我起了以下草稿供參考：

（註：如果有需要修改可以直接編輯本表格，無須經過我的同意(不被視為修改他人留言)）

（註2：下表只列出目前未出現於WP:QUALITY的級別）

（註3：由於表格過長，已折疊。請單擊[顯示]以展開表格）

預計種類分成三類：標準級別（描述條目品質）、標準類別（描述頁面種類）、非標準級別（專題自定的東西）

等級標準草案
預計種類	級別	代碼	評級方式	標準	詳細標準	讀者感受	編輯建議
標準級別	特色列表级	FL	手動	條目通過正式評審，現為特色列表。	（載於WP:特色列表標準）	專業水準。它完整覆蓋所屬範圍，通常能提供一個完整的列表，並為每一項提供有用的資訊。	除非列表所列之主題有了項目變動或所屬範圍有新發展，否則不應大量增改內容；可能需要改進文法、列表格式，讓列表整體更加優美。
	特色图片级	FM		圖片、文件或其他媒體通過正式評審，現為特色圖片。	（載於Wikipedia:特色圖片標準）	讀者能從該圖像、音頻、視頻或其他媒體以令人信服的方式說明該主題，使觀看者想要了解更多。且這個媒體能很大程度的讓讀者更了解文章的內容或主題。	通常不需要對媒體文件做出任何改動，除非能提升解析度或其他外觀品質。可能可以改進對於該特特圖片的描述文字或對應題目中的文法，讓特色圖片能更好地發揮其價值。
	甲级列表级	AL		(WP:QUALITY已有內容)
	乙上级	Bplus		條目已基本完成，有当选优良条目的潜质，經相關專題、討論页或其他管道評審，確認符合乙上級條目標準。	BP1 来源：所有断言均可查证、无原创研究；来源依版面佈局指引列出；特定资讯需内文引用可靠来源。 BP2 内容：介绍主题的重要方面；聚焦主題而不深入无谓細節。 BP3 结构：内容组织得当，遵循版面佈局，含序言章節以及此类条目应有的章节。 BP4 行文：文字簡潔明了，遣词得当，无别字和语病；虛構事物和嵌入列表需遵循格式手册。 BP5 配图：若可行，则配以插图解说；圖像符合版权要求，且以題注妥当说明。 BP6 易读：行文应尽量让相应受众理解，包括解释或避开技术术语，处理地区词差异。	無明顯問題，對幾乎所有讀者都實用。基本達到（未必完全符合）專業百科全書水準。	或需相关领域的编者和格式专家修改。可提名WP:同行評審以釐清與優良條目的差距，並進行改善。
	乙级列表级	BL		(WP:QUALITY已有內容)
	丙级列表级	CL		(WP:QUALITY已有內容)
	丁级	D		条目有所發展，较初級條目更为完整，但仍有重要内容缺失。条目可能在内容方面達丙級水準，但因行文、结构等問題無法获評丙級。	條目有些不錯的內容，也列出了些許可靠來源，但与丙級条目对比仍有明显缺陷。例如条目未遵循百科文風，文字条理性不足，大量内容仅面向特定圈子（如愛好者內容、科学專業術語或内容）。	條目有较多百科全书资讯，但可能也伴随较多难以理解的内容。读者可收获一定的资讯，但可能感到条目章法混乱、某些内容不易理解，难以通读全文。	仍需扩充资讯，且或需大幅清理与重组内容。
	列表级（作初級列表使用）	List		符合獨立列表的要求，较小列表更为完整，但未能達到丙級列表的水準。列表中的可靠來源可能引用充分，也可能不充分。尚未細分為甲、乙、丙級的列表也可能暫時歸為此類。	列表有些有用的内容，但是在许多方面仍有不足，通常缺乏参考资料。列表内容可能不适合百科全书，不符合格式手册的要求。但是列表必须满足最基本的内容方针和独立列表的基本要求，诸如关注度、生者传记，并提供足够符合可供查证要求的来源。初级的列表应无快速删除之虞。	已經列出了一些有意義的內容，但對於多數讀者仍屬不足。	應當儘快提供可靠來源，並需大幅更動和組織內容。此外也可改善語法、別字、寫作風格、術語的使用。
	小列表级	SL		(WP:QUALITY已有內容)
	小小作品级	Substub		對主題非常基本的描述，但正文不足50字。	條目有基本定義，但正文只有一两句话（约50字以下）的条目。其可能有資訊框、圖片或參考文獻。如正文不足50字的條目也缺乏資訊框、圖片或參考文獻，則其可能會被提請刪除。	有意義內容極少，可能跟典解釋差不多。	應當儘快將正文擴充至50字以上。
	无级	No		尚未建立或已被刪除的條目。通常用於建立條目清單時標記不存在頁面的級別。	N/A	由於條目不存在，因此讀者無法獲得任何資訊。	如該主題有建立條目的需求，可以視情況建立條目。
標準類別	同类索引级	SIA	由{{WPBS}}程式自動給予級別	任何同類索引條目（SIA）頁面都屬於此類。這些是關於一組具有相同（或相似）名稱的特定類型項目的清單文章。	掛有{{SIA}}模板的頁面	讀者能找到特定類型項目的文章。	請注意，同類索引條目對名稱和主題都有要求，即索引項目必須屬性相同且名稱相似。比如地震列表不是同類索引條目，但以X爲名的地震列表就因滿足同名、同主題兩項條件，屬於同類索引條目。
	沙盒级	Sandbox		社群認可用於測試的頁面。	掛有沙盒標示模板的頁面，或模板、模組的/sandbox子頁面	這個頁面的內容可能因為測試原因而頻繁變動，可能對任何讀者都不實用。	無建議。
	草稿级	Draft		任何草稿都屬於此類。這些通常位於Draft命名空間中，但也可能位於User命名空間中。	N/A	這可能是一個發展中的條目，因此可能有一些有意義內容，但對於多數讀者仍屬不足。	任何編輯或者增加內容都會有幫助。應當儘快增加有意義的內容。並儘快推動完成WP:AFC流程，解決相關問題以便成為正式條目。
	专题级	Project		任何維基專題相關頁面。	N/A	專題頁面主要是面相編者的資訊，對讀者而言可能沒有有用資訊。	編者應確保內容能反映專題或社群共識。
	用户级	User		任何屬於User名字空間的頁面	N/A	可能有些有用的資訊，也可能只包含特定編者的立場。	應遵守Wikipedia:用戶頁規範。
	使用说明级	Help		任何屬於Help名字空間的頁面	N/A	讀者能找到維基百科相關功能的使用說明。	編者應當確保說明內容不過時。
	界面级	Interface		任何屬於MediaWiki名字空間的頁面	N/A	定義介面的顯示方式，可能對任何讀者都不實用。	任何對系統介面的修改都應反映社群共識。有時會因技術需求或其他原因由维基媒体基金会職員進行修改。
非標準級別	搁置级	Deferred	只能手動給定	代表本頁面的評級作業轉介給涵蓋該頁面主題的其他專題。	任何編輯都可以在有開放此級別的專題指定此評級，但不能評於通用評級。應謹慎使用此評級，並且僅在其他專題完全覆蓋此專題導致冗餘的情況時使用。	由於對應專題沒有提供級別，因此實際情況可能會有所不同。

@Temp3600：您看看這些資訊對行政組作業有沒有幫助？（請單擊[顯示]以展開表格）-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年4月5日 (五) 10:48 (UTC)[回复]

感谢宇帆君的总结。我大胆做了一些调整，说明如下：

Bplus之于GA类似A之于FA。A级的标准和文档页指出要走比较正规评审，类似这种，而不能像评B、C那样随手改|class=。所以Bplus的要求中我也提了要做评审；不过这也就是这么一说，大家肯定还是会随手改的😂。另外A级开始才算专业，GA只能叫接近专业（我上面说的，英维A级需要专家来评审，而GA不需要），所以调整了一下措辞。
D级还是可能有格式问题的，基本上B级才算比较遵循格式手册，连C级可能都差一点，而且爱好者内容广义上也算格式问题。其他方面调整了一下语言，大体是说条目内容方面有含量，但其他方面比较差。

--For Each element In group Next（留言） 2024年4月5日 (五) 13:54 (UTC)[回复]

已經五天無新意見了，我先把資料整理進WP:QUALITY。如到時還有討論出新結論也可以再修改。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年4月10日 (三) 03:22 (UTC)[回复]

頁面評級與通用評級指引調整

- 非常感謝娜娜奇。但我因為現實原因(pia!)暫時不能積極參與討論。我預計會於19-21日的週末發言，這段時間麻煩諸位了。--Temp3600（留言） 2024年4月12日 (五) 11:29 (UTC)[回复]
  - 約略看過沒有問題。在格式上有一點想法: 每個類別還是找一個例子，當參考。另外，會否用Template:Guideline section，只將標準評級立為指引會較好?如果專題組日後創立新評級供內部使用，便無須經VP共識修改評級表，而可自行加入。不過倒過來，如果自行加入評級會弄壞模版，那麼還是經VP討論，協調好再修改較好。這方面我不清楚，請給意見。--Temp3600（留言） 2024年4月12日 (五) 11:58 (UTC)[回复]
    - @Temp3600：屆時，如果確定該等級都標準化的話，僅需要將{{Class_mask/core}}中，目前還沒標準化的級別做「開放」即可（不必改程式，只要改類似config(設置)的東東），而專題自建級別已有相應功能，無須動到核心模板，範例見{{WikiProject_Example}}，因此完全無需更動本次系列模板/模組或任何程式碼的核心，故自行加入評級不至於會弄壞模版。常見的專題非標準評級我覺得可以在WP:QUALITY提，在章節標題標註「本段不是指引」應該就可以了，就不必走VP共識了。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年4月12日 (五) 15:49 (UTC)[回复]
      - 先抱歉晚了許多上來...生活艱難QQ。
      - 如果如此，那麼标准级别一節立為指引就可以，並在非标准级别一節清楚列明專題可以如何自行加入新評級(好像在模版說明裏已經寫好?那麼就只需要提供連結)。--Temp3600（留言） 2024年5月5日 (日) 07:27 (UTC)[回复]

对于Wikipedia:页面质量评级标准（以及Wikipedia:通用评级）还有一些逻辑上的考量：

英文版的页面en:Wikipedia:Content assessment翻译过来是内容评级。其内涵理论上包括评级流程、评级标准等多个部分。而中文版的标题是「页面质量评级标准」，一只介绍标准本身，二又强调品质评级。而当前页面是从古早期英维版翻译过来，现在两边都改了很多，这就很微妙了。所以页面是否要改名「Wikipedia:页面评级」？
如果从标题强调质量评级来看，页面似乎应该将「标准质量评级」（≈条目）和「標準類別級別」（≈非条目）分设为两个大节。说约等于是因为特色图片属于非条目但又要评估品质，而同类索引（SIA）是自动评级但理论上属于条目。
- 对于条目品质评级部分，是否需要流程图辅助说明？（比如写入指引页，或放在论述页给个连接）
如何表述「通用评级」与「专题评级」的关系？从目前的讨论来看，可能还需要一个页面（可能是Wikipedia:页面评级）厘清：
- 社群和专题都可以各自独立地对页面评级。评级结果登记于条目讨论页顶部。
- 通用评级由社群编者评估，对社群负责。本页刊载的等级标准为通用标准，即适用于WPBS的通用评级。
- 专题评级由专题自行解释，但因为专题评级一般直接继承通用评级，所以也还是这套标准。部分专题可能自选启用或关闭级别，也可能重新诠释通用级别，这些内容具体在专题评级页刊载。

我希望听听其他编者的意见，所以暂时不会积极回复。--For Each element In group Next（留言） 2024年4月14日 (日) 15:17 (UTC)[回复]

那我再Ping一次討論開頭的那些人吧：@Liaon98、JyunWaan、Lssrn：@Cdip150、Temp3600、Peacearth：。還有User:Kanashimi Ping的那些人@Kethyga @Willy1018 @Z7504 @AT @Shizhao @Iokseng 能夠給些意見嗎？謝謝。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年4月14日 (日) 15:34 (UTC)[回复]
週末來研究 --Temp3600（留言） 2024年4月14日 (日) 15:47 (UTC)[回复]
只講這一句，其餘不說了：「WPBS模板目前看來機器人執行上是沒什麼問題的。另外，有些分類基本用不到（例如 同类索引级），不予評論」。反正評級功能沒什麼大問題，個人認為就不用再浪費時間在這種沒問題的上面，不打擾了。--Z7504非常建議必要時多關注評選（留言） 2024年4月18日 (四) 13:45 (UTC)[回复]
- 之前說過了，自動評級「有掛模板就能判斷」，既然{{同類索引}}模板存在，就能被自動判斷，且分類裡確實有東西，故不認同「用不到」一說（例三碘化物 (索引)既非消歧義也不是列表），真用不到的話，分類早就O4了。就這樣，我也不想就這個話題繼續（真要較勁的話，{{導論}}也有模板存在，病毒v.s.病毒 (導論)，也可以搞出 導論級[Introduction]^{[甚至是綱要級[Outline]]^{(如馬來西亞v.s.馬來西亞綱要)}]}，但因為導論也有品質，不像同類索引偏點列式，所以導論類條目就共用條目的甲乙丙丁初級）。哪壺不開提哪壺，我們在討論評級時的規範，而你在講機器人能不能工作，這完全兩碼子事，而且顯然現在貿然增減或棄用一個級別存在技術上的複雜性和已報上phab且工程師已完成作業還要頻繁去phab「吵他們」、「煩他們」顯然不是一個好的做法（這點Temp3600講過了不再贅述）。仍然主張維持放所有能自動判斷的級別設為標準級別。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年4月18日 (四) 13:57 (UTC)[回复]
- 然後，有點離題了，建議聚焦在頁面評級與通用評級指引邏輯上的考量。WPBS能使用哪些評級的議案已經公示通過，且能使用，機器人和系統自動評級的部分正正常工作著，故不必再浪費時間討論。從行政組的工作切入討論起來比較重要-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年4月18日 (四) 14:26 (UTC)[回复]
基於此，上面Ping的人已經有一個給出答覆了（Z7504）。其他人我再重Ping一次。@Liaon98、JyunWaan、Lssrn、Cdip150：@Temp3600、Peacearth、Kethyga、Willy1018：@AT、Shizhao：能夠給些意見嗎？謝謝。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年4月19日 (五) 15:28 (UTC)[回复]
抱歉，這幾個月都在搬東西，沒空上維百所以不知道閣下Ping我；

這8年我評級的條目應該沒10個，所以沒深入理解該評級論述，抱歉不能提供意見。--JyunWaan - Talk 2024年6月23日 (日) 12:45 (UTC)[回复]
所以现在是什么情况？2402:7500:579:89C4:84ED:51FA:80FD:F1D1（留言） 2024年4月26日 (五) 05:52 (UTC)[回复]
( π )题外话 我终于见识到条目重要度评级标准的存在感有多低了。L'Internationale, Sera le genre humain! 2024年4月27日 (六) 14:52 (UTC)[回复]
這其實是一個很不幸的情況......條目評級與條目評審是本站的QC，QC壞了，本站其他的管治水平也可想而知。--Temp3600（留言） 2024年5月5日 (日) 07:20 (UTC)[回复]
才發現通過了一整個指引。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年4月27日 (六) 15:20 (UTC)[回复]
@A2569875：注意到阁下修改了{{Grading scheme}}，添加了一些新的评级，但这些评级全部成为了默认选项。个人认为对于一些小型专题来说，可能不需要这么多类评级。建议把部分评级改为非默认的选项，只需把对应评级|trigger=参数的默认值yes移除即可。——BlackShadowG Slava Ukraini! 2024年5月3日 (五) 01:34 (UTC)[回复]

en:Wikipedia:Content assessment 有較多的內容，我認為這是因為他們是這個制度的來源地，所以有關於制度的歷史流變等可以寫。中維目前只是引入的制度，還沒有社群的經驗，因此沒有這部分的本地經驗可以立為指引，而只能寫一些硬規定。我認為這暫時不是問題，如日後成熟，自然可以再將這些段落引進，指引名字也可以更改。「页面质量评级标准」就暫時只寫標準，待评级流程成熟後，就可以加入這一部分的指引。

同意將「标准质量评级」與「標準類別級別」分立為兩個三級標題。這是一項不涉及本質的結構修改，不難。

流程图最好有，但要有人來畫...

「通用评级」与「专题评级」的关系:這是我最早就想改寫的部分。既然「通用评级」只可填標準評級而專題評級可以填其他自訂評級，那麼维基百科:通用評級就需要至少修改"若一條目僅有一個專題，其通用評級應與該專題所評的等級一致。"，最好是重新理順這一部分的邏輯。

整理目前的討論，建議"機器人會根據該頁面最多專題評等的評級等級作為通用評級"繼續保留，但機械人應檢查這會否導致WPBS被評為非正式級別，如發生這種情況，那麼機械人則跳過該條目(可以考慮加入"需要手動進行WPBS評級"的分類)，留待人類前來。

同意"社群和专题都可以各自独立地对页面评级"的基本策略。這樣就解決了list級的問題。即使專題的評級只有list級，WPBS仍可以手動評為更準確的CL/BL等細分級別。由機械人自動評的list級也與這個邏輯沒有沖突。

長遠的最終方向是，WPBS作為條目的內容評級，專題評級則為某一方面提供額外的資訊，類似tag.但這個需要將目前的評級邏輯反過來，我猜一兩年也無法完成，就寫在這而已。--Temp3600（留言） 2024年5月5日 (日) 08:10 (UTC)[回复]

修訂案

雖然我累得(今天)打不完整個修訂案，但至少可以生出一個大綱...--Temp3600（留言） 2024年5月5日 (日) 08:28 (UTC)[回复]

维基百科:通用評級

解決「通用评级」与「专题评级」的关系。斷開兩者的上下級關係。
通用評級只限填寫標準評級。
介紹一些其他功能，例如專題可以自行加入評級，不過這些不屬於WPBS的範圍，將它們指示到其他頁面去。

维基百科:页面质量评级标准

對應通用評級的改動，明確兩者間的關係。即: QUALITY負責規定那些級別屬於標準評級，及提供評級的參考。也提供其他非標準級別的介紹。通用評級指引則負責通用評級的流程，由社群負責，為條目的質量提供評級，而專題級模版級等請不要來找WPBS.
結構調整，將「标准质量评级」與「標準類別級別」分立為兩個三級標題。

T: Grading scheme

為所有標準類別補上例子。

--此條疑似遺漏簽名的留言由Temp3600（討論｜貢獻）於2024年5月6日 (一)加入。

似乎除了這筆移動外沒太大進展，那我就先寫個Draft:页面评级吧。T:Grading scheme的例子就沒辦法了，甲級估計社群這輩子也評不出來（現在的Talk:家牛也沒找到評審在哪）😂 --For Each element In group ... Next 2024年7月10日 (三) 17:45 (UTC)[回复]

路過說兩句。條目可以評甲級，前提應該已經是GA，之後再在專題裏要求評審？如果三個專家太難找也惟有懸空，也不用甚麼例子。之後誰來做這個評選再加上例子和過程吧。至於家牛的甲級，也許是FA落選前後的事？如果找不到流程，最快捷的方法是讓它重選GA，通過之後降回GA級？不過從這事引伸，甲級主要是在評FA時能用上？讓大家辨別哪些落選的條目其實「只差一點點」--派翠可夫 (留言按此) 2024年7月30日 (二) 03:53 (UTC)[回复]

按照原来的评级体系，甲级是专题评的，优良是社群评的，两者属于平行关系。而且这套体系是从英维搬过来的，英维GA不上首页。有的人看不上GA，直接找专题内的专家评甲级也不是不可能😂 当然本地改制后要求甲级需要GA资格也可以。

甲级的理念您说的对，可以当FA的预审。理想中的甲级评审应该长这样，但中维恐怕连FAC都做不到这点。而随便看看的话，乙、乙上、优良、甲、典范都长得差不多，根本区分不出来。我在上面也表达过个人想法，直接把甲级（和乙上级）冻结掉。但其他编者认为有保留更合适，所以我就写上去了。--For Each element In group ... Next 2024年8月2日 (五) 11:35 (UTC)[回复]

公示準備

根據已通過共識修改了下上方的草案，並就當前草案版本展開討論。若在七天內無明顯反對意見或反對意見都已解決，那麽就當前版本進行公示。--人间百态,独尊变态 (讨论) 2024年8月2日 (五) 06:15 (UTC)[回复]

按照上面的讨论，通用评级和专题评级互相独立。通用评级作为一个独立的评级，其标准就是这两个，不再直接依赖于其他专题怎么评。

这份草稿也是照此思路写的。原先的Wikipedia:通用评级更像是改制初期的供机器人批量填写等级的临时措施。如果草稿转正，就可以考虑去除指引地位了。--For Each element In group ... Next 2024年8月2日 (五) 11:21 (UTC)[回复]

已刪去草稿的對應章節--人间百态,独尊变态 (讨论) 2024年8月2日 (五) 13:11 (UTC)[回复]

抱歉現在才發表這樣的意見。其實現在「小作品」和「優良」級之間有「乙」、「丙」、「初」三級已經蠻多。「乙上」因為要容納落選「優良」的條目可以理解，但「丁」級直覺上有點多餘。我個人認為用DYKC／DC標準做分界線，達標當「丙」級，不達標而又高於小作品的叫「初」級就算，甚至初級直接改名丁級。當然，大家同意級別寫多幾個我不便置喙，只是執行評級的時候我傾向簡單一點而已--派翠可夫 (留言按此) 2024年8月4日 (日) 17:45 (UTC)[回复]

关于为何要设立“丁”级，这段讨论已经说明的很清楚。至于将DYKC作为丙级与初级分界线鄙人不敢苟同--且不说草稿已言明丙级与初级的评级标准，通过DYK参评的初级条目在维基百科也是案例的--人间百态,独尊变态 (讨论) 2024年8月5日 (一) 14:24 (UTC)[回复]

@人间百态：我就是覺得那段討論只是涵蓋了藝術影視類的作品的丁級，但沒有人談其他領域的丁級……不過我也先旨聲明，這個時候還想翻轉之前的結果是不合理的，所以您當我發個牢騷（或者說一下機制通過後自己會怎樣做評級）就好--派翠可夫 (留言按此) 2024年8月5日 (一) 17:17 (UTC)[回复]

公示7日，2024年8月16日 (五) 07:05 (UTC)結束：七天时间已过，就目前草案版本进行公示，公示通过后将目前草案版本设立为指引--人间百态,独尊变态 (讨论) 2024年8月9日 (五) 07:05 (UTC)[回复]

(＋)附議。最近因為為了找工作忙於跑各種行程（目前是有找到一家公司，應該會錄取），所以沒有甚麼時間上維基，感謝各維基人協力完善草案，以便能解決本案《評級系統缺失問題》之主要問題。WP:通用評級取消指引地位沒有意見（畢竟從草案看起來是預計整併進《頁面評級》指引了），畢竟那確實只是要讓機器人能上線而訂立的，如果機器人操作者沒有問題，那我自然也會覺得沒有問題。中途User:Temp3600 雖也因生活繁忙原因未能繼續完善法案，但感謝其他維基人的努力不懈。(＋)支持目前草案升格為正式指引。（@Temp3600：有空也上來說個話吧，不然「喂喂，不准跑掉（」不就一語成讖了嗎😅，雖然我也是因為日常生活繁忙而無法經常發言😅）-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年8月10日 (六) 02:56 (UTC)[回复]

公示已过，Wikipedia:页面评级正式成为指引。Пусть от победы ☆к победе ведёт! 2024年8月16日 (五) 07:07 (UTC)[回复]

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

後續討論

关于 rater.js 脚本

前面的讨论貌似没有涉及到老版本的rater.js脚本（User:Chiefwei/rater aka en:User:Kephir/gadgets/rater）。貌似enwiki那边已经废弃了老版本的rater.js，并且由Evad37推出了新版的rater.js（en:User:Evad37/rater）。我再考虑将新版本引入并做本地化，不知道目前是否已经有类似的工作了？--Ceba_robot 才不是机器人！ 2024年2月16日 (五) 17:57 (UTC)[回复]

有見到Ericliu1912和YFdyh000兩版。--Cookai餅塊🍪_{（💬留言）} 2024年2月16日 (五) 18:17 (UTC)[回复]

妥了，看起来YFdyh000的目前跟上游已经同步，还是不要做重复工作比较好（--Ceba_robot 才不是机器人！ 2024年2月16日 (五) 18:24 (UTC)[回复]

我也跟進借鑑了，至少現在用哪一個版本都不會落後。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年3月4日 (一) 11:51 (UTC)[回复]

目前仍有大量站內頁面連結至User:Chiefwei/rater，建議更新。--Temp3600（留言） 2024年3月3日 (日) 07:57 (UTC)[回复]
順便副知一下本人吧？@Chiefwei。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年3月4日 (一) 11:51 (UTC)[回复]
還真不知道rater.js有這東西，但這個社群對於專題過往都是冷漠處理的，沒想到近幾個月開始變得重視了。沒差，評級功能不要影響到就好，多說可能無益。--Z7504非常建議必要時多關注評選（留言） 2024年4月18日 (四) 13:47 (UTC)[回复]

Unblock-zh.org

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:IP封禁豁免、Wikipedia talk:Unblock-zh.org。

很久以前讨论过的一个项目，也就是unblock-zh的网站版，我最近给他做出来了，如果对测试版软件感兴趣的话，请去 https://unblock-zh.org 这里去看看。~~（注意测试版软件，你的用户最后很可能被删掉！）~~7月7日update：软件进入试运行阶段，此时产生的工单等数据将永久保留。Bluedeck 2024年7月8日 (一) 19:21 (UTC)[回复]

附带一个教学视频 https://www.youtube.com/watch?v=IImfyNnRB4M

目前站外用户申请账户的方式是Wikipedia:账号请求发送邮件，其实也没有太不方便。但是这个途径我觉得还是更直观一点，比邮件列表好用一点，尤其是管理员处理的时候。我的想法是网站可以和邮件列表并存，或者以后达成互联。欢迎提出意见。Bluedeck 2024年4月29日 (一) 04:05 (UTC)[回复]

PS. 已经收到tigerzeng的意见，允许用户自定义提供的IP地址字段，以解决部分代理的问题。Bluedeck 2024年4月29日 (一) 04:22 (UTC)[回复]

超英趕美 —— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年4月29日 (一) 08:09 (UTC)[回复]

我最期待的畫面出現了。--A T 2024年4月29日 (一) 09:14 (UTC)[回复]

好吧，终于把这个弄出来了——是蓝桌弄的？那就不出奇了。

赞——Sakamotosan路过围观 | 避免做作，免敬 2024年4月29日 (一) 09:29 (UTC)[回复]

非常好UX。至于是否方便了用户，我好奇能否在合理的范围内收集一些统计数据作对比，这样最有说服力。--碟之舞📀💿 2024年4月29日 (一) 14:10 (UTC)[回复]

另外这个工具让我想到了我很久之前做的维基媒体服务器连通性面板。--碟之舞📀💿 2024年4月29日 (一) 14:37 (UTC)[回复]

非常好软件。

不必要的功能建议：1.通过遍历封禁日志的摘要有无对应模板，显示是否是ip封禁。2.通过接口调用在界面一键创建账户（和授予ipbe？）

另外问一下数据托管在哪里？将来投入使用的话需要作为存档使用，所以数据需要备份好。--落花有意12138 2024年4月29日 (一) 14:42 (UTC)[回复]

一键创建账户/授予PIBE的话，有两种途径。第一，管理员通过oAuth授权unblock-zh.org，通过管理员账户操作，然后从本地日志看来，操作者是管理员。第二种途径是，成立一个机器人账户，比如名叫 unblock-helper-abot，并且赋予机器人管理权限，然后通过机器人操作，并在摘要里说明是根据哪个管理员的指令操作的。让我来决定的话，我倾向于使用第二种方式，因为我希望尽量不要向第三方授权我自己的账户，但是第一种方式的日志更加清晰。请问一下其他人的想法。Bluedeck 2024年4月29日 (一) 17:39 (UTC)[回复]

使用OAuth可以只需要简单的身份识别获得权限，用于确认是不是登录系统的对应是wiki的哪个用户。然后代理操纵的机器人可以标记操作人员的wiki用户名（通过前面获得的信息）。——Sakamotosan路过围观 | 避免做作，免敬 2024年4月30日 (二) 02:33 (UTC)[回复]

如果不改变单管理员授权模式，我倾向于第一种，这样和原先的工作模式保持一致，便于查询。

mw:OAuth/For_Developers称应用做的操作会有标签。--落花有意12138 2024年4月30日 (二) 11:04 (UTC)[回复]

在这里没有看到可以使用oauth给用户添加组别的选项，那么也是说IPBE的授予只能透过abot进行了。Bluedeck 2024年5月1日 (三) 21:41 (UTC)[回复]

的确只能这样。——Sakamotosan路过围观 | 避免做作，免敬 2024年5月2日 (四) 03:40 (UTC)[回复]

咱好像记着这种权限似乎不需要特别勾上某个选项就默认拥有，您要不尝试一下？ Stang^★ 2024年5月8日 (三) 01:14 (UTC)[回复]

真的假的，在授权的时候不声明却可以操作改变用户组这么重要的操作？如果是真的那也是个bug吧 Bluedeck 2024年5月11日 (六) 08:40 (UTC)[回复]

用API能查IP有没本地封或者全域封，好像不是必要。——Sakamotosan路过围观 | 避免做作，免敬 2024年4月30日 (二) 02:26 (UTC)[回复]

赞牛逼--Dnaimfz（留言） 2024年5月11日 (六) 04:04 (UTC)[回复]

話說可給管理員布告板抄送一份通知連結至此？—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年6月1日 (六) 08:43 (UTC)[回复]

想好奇請問是否有考慮過部屬在wikitech:Help:Cloud VPS？如果有，為什麼不選擇部屬在該處？--Sun After Rain 2024年6月4日 (二) 09:30 (UTC)[回复]

管理员通告版：不知道效果会怎么样啊。等上线后在ASN通告一下，然后TG呀IRC呀广播一下应该就行。CloudVPS：他的介绍说自己是标准的VPS，但是又有迹象表明他不是完全标准的环境，导致我不想把时间花在部署，测试，更换环境，以及踩坑上面。对我来说，写软件是趣味十足的事情，而调试环境则是让我胃肠不适的事情。目前我没有换环境的需求，因为开销太小。如果有我再考虑cloudvps。cloudvps的另一个问题是只有在virginia有DC，但这不是一个大问题。Bluedeck 2024年6月8日 (六) 04:00 (UTC)[回复]

以我個人看法，部屬在CloudVPS的隱私疑慮絕對會比一個外部網站好很多，當然你維社群願意接受那我也沒什麼意見就是了。雖然不清楚是筆誤還是什麼的，如果開銷太小的話我自己是會考慮換過去啦。--Sun After Rain 2024年6月10日 (一) 17:54 (UTC)[回复]

可以理解你所说的。我可以把cloudVPS当作一个长期目标，最终迁移到那上面去。Bluedeck 2024年6月14日 (五) 05:29 (UTC)[回复]

试运行

在过去的几周里，我增加了最后的一些的功能，分别是1）按日期搜索排列工单；2）邮件回复模板；3）管理员删除工单、删除消息界面；4）用户改名功能。我想知道大家觉得还缺少哪些网站本身的功能（邮件服务器、机器人授予IPBE除外）。如果感觉差不多了，那么可以进行试运行。试运行期间，再对可能发现的新的功能需求进行补充。试运行的提议正在进行公告。如果通过，将会将网站首页文字改为试运行，并暂时移除一些只具有展示效果的链接，然后在用户无法注册的提示页面加入网站的链接，这些操作大概最多需要一天就能完成。在试运行决议通过前，如果对网站有任何问题，欢迎在此讨论。Bluedeck 2024年5月13日 (一) 23:30 (UTC)[回复]

功能方面，个人认为管理员不应该有删除工单的能力，这个应该由维护者来做，比如遇到spam/扰乱性工单就打上相应的标签，若干天后自动删除；可不可以出个statistics大概写一下某月某人处理了多少工单之类的；反spam方面怎么样，你觉得需要加个recaptcha吗；模板建议是放到Github或者类似公开的地方，需要改的人发pr；可以考虑加一个link/merge功能么，比如一个用户就一个问题发了多个ticket，这个时候可以把它们关联起来；感觉可以把login改的小一点，或者让非管理人员意识到不需要登录就可以发ticket。

另外就是建议放到toolforge或者cloud VPS上。顺便问个问题，你觉得这个系统需要承担unblock-zh最原始的封禁申诉职能吗 Stang^★ 2024年5月14日 (二) 01:47 (UTC)[回复]

谢谢提议！简短回应：

删除工单就是为了应对扰乱才设计的功能。删除之后可以恢复或检视。（UI需要另外添加）工单的永久保留或删除问题在下面讨论。
反spam：UTRS目前是阻止同一个IP地址多次发送工单。但是我的方案不记录IP地址，无法阻止。我可以考虑一下记录ip地址的hash，并由此进行rate limit。我个人完全不喜欢captcha，除非不得已，我可能会考虑上captcha。在此之前我会尽量用其他手段处理spam问题。我有一些asymmetric proof of work的方法能防止自动化的spam。如果有人无聊到要手工spam，那么唯有记录IP并进行区段查封这一个办法。（但是这样一来，不就把本身的目的给击败了？？）
邮件模板：我不会放在github，毕竟不是每个管理员都会开PR，我简单的开一个用户页面存储目前的模板，谁想添加，给我留个言即可。邮件模板都是非常简单的纯文字模板。当然，如果你喜欢用gh，那么在前端的repo里有一个文件，你也可以直接PR这个文件。
link/merge：race condition太多，最多做成stack overflow/github issues那样，“标记为#109的duplicate。关闭”这种解决方案。
login改小：我肯定会让新用户看到不login就能发工单，这是一个重要的因素。
statistics：这个我一定会做，因为这会让处理工单变得很有趣，我的设想是做一个leaderboard，能够激发人们对于处理工单的无限潜能，哈哈哈哈。
Hosting：toolforge不能满足我的要求，CloudVPS不熟悉。将来打算支持图片上传，需要一个能挂载S3的环境，另外多区域host允许你把服务器托管在东京/首尔/LA。目前，服务器托管在Vultr的新泽西区上面。
这个网站做成网站的形式，是为了新用户方便的注册+IPBE（也就是unblock-zh-ipbe的功能）。处理被长期封禁的用户在邮件列表中50-100封邮件那么长的申诉，并不是网站初衷。如果有人就是要在网站上申诉，管理员也选择在网站上处理，那我不会站出来阻止，但是如果网站上出现了对维基百科历史有一定意义的讨论内容，我觉得有应当抄送一份到邮件列表。

Bluedeck 2024年5月14日 (二) 04:12 (UTC)[回复]

update: 已经增加了查看和恢复已删除工单的功能。Bluedeck 2024年5月19日 (日) 06:40 (UTC)[回复]

另外还有两个别的需要讨论的问题：

工单是否永久保存？永久保存是目前的默认，而且邮件列表也是永久保存的。但是我觉得比如挂上“处理结束”标记90/180天之后永久删除相关信息这个是更安全的做法，想征求一下大家的意见。
开源：从一开始我就设想开源。这个项目有4个repo，其中3个可以在最近开源。一个需要我检查一下有没有API Key之类的物品遗落在代码中，然后才能开源。请期待。
共同参与：如果您想共同参与开发，或者参与对服务器的运维，欢迎在这里提出来。Bluedeck 2024年5月14日 (二) 04:49 (UTC)[回复]

感謝貢獻，整體非常完善。如有需要可以協助維護。--Borschts^™^{歡迎外帶一碗羅宋湯} 2024年5月14日 (二) 13:32 (UTC)[回复]

存檔應保留，只是可以限制普通使用者存取。另外，也應考慮先行在站內撰寫說明頁面，或補充現有方針與指引不足，以便利用。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年5月14日 (二) 15:05 (UTC)[回复]

注意到兩點可以改善：

無法創建帳號者不應提供「我不想提供郵箱」的選項，創建帳號時需填寫對方電郵地址才能安全發送臨時密碼。如果不想提供郵箱則難以協助創建帳號。
需要添加提示文字，若不提供IP地址則申請有可能不獲受理（始終審批IPBE時需要驗證用戶是否使用proxy）。

--路西法人 2024年5月15日 (三) 07:52 (UTC)[回复]

我脑海中预想的不提供邮件的处理方式：网站生成一个强的随机密码并记录在工单中，用户通过随机密码登入。优点：用户不需要邮箱地址。缺点：不提供邮箱的用户等于需要不断的刷新页面查看处理进度，是一个糟糕的体验。对于管理员，需要复制粘贴网站生成的密码来创建账户，也是多了一个步骤。上面我只是说明了操作的可行性，至于这个功能是否保留，可以继续讨论决定。对于第二点，IPBEG如果有这个要求，那我完全可以添加这个提示文字（甚至可以在维基百科设置一个页面，比如Template:Unblock-zh/strings/new-ticket-notice，然后网站可以反映这个页面的任意文字。）Bluedeck 2024年5月19日 (日) 06:22 (UTC)[回复]

我的想法是只要有任何第三方人員可以接觸到任何密碼的方案都是不安全的，尤其在發送郵件時在此類第三方網站留存臨時密碼亦是相當危險的；即使我信任你會盡力保障網絡安全，但顯然不安全的操作應儘可能完全避免。郵件、代理IP地址等都尚算不太危險的資訊，密碼真的不行。--路西法人 2024年5月21日 (二) 01:25 (UTC)[回复]

我想了一下觉得你说得很有道理。如果有的用户收到临时密码后不加更改，那么等于这个用户的密码永远的挂在一个所有管理员都能看到的地方，是不妥的。我已经把界面改成如果请求账户，必须提供邮箱，否则无法提交。Bluedeck 2024年5月21日 (二) 01:50 (UTC)[回复]

一些minor的建议：about一页，Puzzle Globe似可译为“拼图球”，Wikibooks译名应为“维基教科书”非“维基图书”。不提供邮件的提示，“一串30几位的工单”应作“三十几位”。login界面没有明显的返回按钮，侧栏也消失了。lookup界面可以考虑加注工单号和邮箱择一提供即可。 ——魔琴［身份声明留言贡献新手2023］ 2024年5月21日 (二) 03:01 (UTC)[回复]

另外我在想讓其選擇點選提交IP的選項是否也應該把UA也提供給審核用戶檢閱（方便反破壞比對）。--路西法人 2024年5月23日 (四) 07:54 (UTC)[回复]

统一回复。1）login界面有意如此设计。2）必须同时输入工单号和邮件，否则任意人士可以通过广泛查询邮件探知私密工单。3）UA信息只有CU才能访问，所以显然不能提供。另外就算用户主动提供了，那么IPBE处理者拿什么进行比对呢？毕竟你又看不到LTA的UA。Bluedeck 2024年5月27日 (一) 06:11 (UTC)[回复]

2) 啊那就是提前提示創建工單時未提供電子郵件的須放空？ ——魔琴［身份声明留言贡献新手2023］ 2024年5月27日 (一) 06:29 (UTC)[回复]

没有提供电邮的工单号会比较长，所以我可以改一下软件，让这种工单号不论是否输入电邮都能够正常查询。这样可以不破坏界面简洁易用。Bluedeck 2024年5月29日 (三) 06:45 (UTC)[回复]

好的

赞 ——魔琴［身份声明留言贡献新手2023］ 2024年5月29日 (三) 07:32 (UTC)[回复]

将开始试运行。公示已经进行了一个多月，收集到了很多改进意见，并实施了很多更新。今天起，我将正式修改MediaWiki软件界面，在网站上标注试运行字样，并在公告栏和ASN中对社区和管理员们进行公告。Bluedeck 2024年7月7日 (日) 16:26 (UTC)[回复]

@Bluedeck：請問IPBEG們可以如何存取工單？--路西法人 2024年7月10日 (三) 03:25 (UTC)[回复]

我正在编写为IPBE权限持有者提供权限的功能。完成后，IPBE将获得和管理员基本一致的功能。目前编写的功能是对于下方讨论中方案一的实现。编写完成后，我将会在用户讨论页面通知IPBEG权限持有者。Bluedeck 2024年7月10日 (三) 18:46 (UTC)[回复]

@Bluedeck：能更新進度嗎？--路西法人 2024年7月22日 (一) 02:49 (UTC)[回复]

现在IPBE已经能取得权限使用了，但是目前用户界面和IPBE权限能做的事情不吻合，比如IPBE无权删除工单，但是会显示删除按钮，我正在改这些小问题。Bluedeck 2024年7月29日 (一) 07:08 (UTC)[回复]

@Bluedeck：預計試行多久？—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年7月20日 (六) 17:44 (UTC)[回复]

不知道，但是目前肯定不是一个完善的状态。比如我就发现了好多好多想要改进的地方，写在Roadmap中。Bluedeck 2024年7月29日 (一) 07:08 (UTC)[回复]

IPBEG的权限基本设置完成，测试可用，在此通知IPBEG组成员@user:AINH，@user:ASid，@user:Borschts，@user:LuciferianThomas，@user:SCP-2000，@user:だ＊ぜ。Bluedeck 2024年8月1日 (四) 01:43 (UTC)[回复]

感謝。希望未來能添加罐頭回覆（請求提供更多資訊如封鎖訊息、已授權〔時長〕）等。--路西法人 2024年8月1日 (四) 02:21 (UTC)[回复]

是的，我自己在处理中，也发现了罐头回复的重要性。我将会加入这个功能。Bluedeck 2024年8月2日 (五) 20:35 (UTC)[回复]

繁体支援

这个网站估计主要的受众是大陆梯子人士。但是，由于很多管理员是繁体使用者，那么我就增加了一系列的繁体支援，但是都是Google翻译的。请繁体管理员看看管理界面的翻译如果有很不和谐的地方，请指出来。如有需要，网站可以支援香港、台湾和澳门繁体的分别翻译。Bluedeck 2024年5月30日 (四) 08:15 (UTC)[回复]

感謝藍桌照顧繁體使用者，但我目前檢視似乎有一些介面仍然是簡體中文的，例如新建工單的部分，另查臺灣的教育部字典，work order這個詞在臺灣可以翻譯為「工令」、「工作命令」、「工作通知單」或「工作單」等，就是沒有查到稱之為「工單」之翻譯，惟我日常生活中前開所有詞彙均較為少見，平常類似功能之提交申請平臺反而被稱之為「電子表單」，這部分可能需要更多繁體使用者來指出正確的翻譯。--小過兒（留言） 2024年5月30日 (四) 15:30 (UTC)[回复]

新建工单的繁体化已经完成。关于工单这个用语的翻译，我参考了一下asus的网站，叫做“请求支援”、“搜寻案件”。不知道这算不算合适的翻译。如果觉得“案件”听其来正确，那么我就把繁体语言的工单改称案件。Bluedeck 2024年5月30日 (四) 23:49 (UTC)[回复]

「工單」是對應「ticket」而不是「work order」，比如Zendesk香港也是叫ticket作「工單」[2]。再甚者，直接「搜尋申請」也是得了，不需要特地什麼ticket不ticket的了。--路西法人 2024年6月1日 (六) 08:37 (UTC)[回复]

@Bluedeck：怎麼查閱或更改翻譯？—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年7月1日 (一) 19:44 (UTC)[回复]

通过改变浏览器的语言设置并刷新页面，可以查看不同的语言版本。目前要修改，可以直接留言告诉我哪里需要改。以后，会开放一个repo在github上可以pr。不熟悉sveltekit和github的用户仍然可以直接联系我。Bluedeck 2024年7月2日 (二) 06:00 (UTC)[回复]

理論上可以開twn（translatewiki.net） project啦，不過要擔心被亂改的問題。--Sun After Rain 2024年7月22日 (一) 07:02 (UTC)[回复]

工单的永久删除

目前没有这个功能。不过，根据欧盟GDPR要求，在用户请求的情况下，应该提供一种方法永久移除其个人信息。我想让管理员能够在工单上添加一个标记，被标记的工单约一个月后真正的删除。删除真正执行前可取消。这种删除只应该在特别的情况下进行（也就是用户请求）。（也可以单独只允许行政员执行真正删除，但是我觉得管理员已经足够可信，并且还有一个缓冲期间。）Bluedeck 2024年5月31日 (五) 23:04 (UTC)[回复]

这个功能不错。( π )题外话：我想知道维基百科不能删除账号是否符合GDPR，以及即使OS似乎也不是真删除，这是否符合GDPR。有人去举报一下是不是基金会就会实现这个功能了

。--桐生ここ★[讨论] 2024年5月31日 (五) 23:25 (UTC)[回复]

应该是不符合的，而且显示未登录用户ip这个似乎也有一定问题。然而我们要团结一致，不要把基金会举报给欧盟。

Bluedeck 2024年6月1日 (六) 05:34 (UTC)[回复]

让 IPBEG 在 Unblock-zh 上获得和管理员一样的权限

因为我觉得 IPBE 也是一大痛点，所以我觉得让 IPBEG 能够一起帮助处理会大有裨益。现在抛出几个方案讨论：

让IPBEG组和管理员同在unblock-zh.org/zhwp下有一样的（或者接近的）权限。
像邮件列表一样，单独新建 unblock-zh.org/zhwp-ipbe空间。
1. 网站面向用户的界面不改变，根据用户是否需要 IPBE，自动将工单分发至 zhwp 或 zhwp-ipbe
2. 网站设计改变，入口页面一分为二，用户需要自己选择是投递给zhwp还是zhwp-ipbe
不支持 IPBEG。

我觉得，从用户体验的角度，不希望入口一分为二。另外，不管选择 1 还是 2，都需要一段时间来修改网站的代码，但是 2 所花时间会更久一点，并且会增加日后维护的工作量（主要是会出现两套表单同步的问题）。关于用户隐私，由于 IPBEG 是签署 NDA 的，应该视为可信人员，所以我比较倾向 1。Bluedeck 2024年6月1日 (六) 09:25 (UTC)[回复]

設立IPBEG的本意就是許可IPBEG處理該類申請郵件，理論上可以說已有社群共識支持選項2，但已有共識未必支持選項1。IPBEG不能處理unblock-zh上非申請IPBE的工單。我是認為，一般而言封鎖申訴本應都是在公開場合發起，申訴內容多數都應該可被所有用戶檢視，實質需要使用郵件申訴封鎖的僅有無法編輯討論頁的情況。如你所言，IPBEG本有簽署NDA，就算看了也不應該會造成什麼問題（雖然能避免最好）。如果是最後採用最簡化的選項1，那我覺得您可以最低限度在處理人員的界面中加入標籤工單的功能，讓IPBEG能明確標記跟他們職務無關的申請，從IPBE隊列隱藏，僅能由添加標記的IPBEG（直至工單標籤被管理員確認）及管理員檢視。--路西法人 2024年6月2日 (日) 11:58 (UTC)[回复]

如果要让IPBEG不能看到非IPBE工单，那应该执行方式2更优。如果执行方式2，那么管理员、行政员也应该自动获得zhwp-ipbe空间权限，并进行工单自动分发。Bluedeck 2024年6月3日 (一) 08:34 (UTC)[回复]

不是「不能看到」，而是「不再跟IPBE有關的就沒必要繼續顯示在同一隊列，令其他正在處理IPBE申請的用戶不小心點進去」。「看到」大概是不會有什麼大問題的。--路西法人 2024年6月5日 (三) 02:22 (UTC)[回复]

分成两列或许方案2实现起来更简单？--桐生ここ★[讨论] 2024年6月5日 (三) 09:51 (UTC)[回复]

不是不行，但必須考量沒簽署NDA的管理人員是否有權限接觸unblock-zh內的工單，一般視乎工單是否涉及IP位址等可辨識資訊。如果要再這樣分就分成三列了。--路西法人 2024年6月6日 (四) 00:04 (UTC)[回复]

还是那句话，我无法理解WMF要求邮件列表内的IP必须有签署NDA才能接触，但允许使用unblock模板直接把IP公开。--桐生ここ★[讨论] 2024年6月6日 (四) 09:48 (UTC)[回复]

我一开始听说IPBEG需要NDA，但管理员不需要NDA的时候，我也觉得很费解。而且你知道吗，你用的任何JS组件要是对外部资源进行请求，那么就可能有意无意泄露IP。甚至你收到一封邮件，邮件里带个图，这图也能泄露IP。虽然说IP在wiki上被当作隐私，其实整个互联网对IP的保护可以用奇差来形容。Bluedeck 2024年6月8日 (六) 04:05 (UTC)[回复]

似乎是祇有涉及IP等隱私資訊時，纔要求管理員簽署相關協議。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年6月23日 (日) 02:13 (UTC)[回复]

只要不僭越社群賦予之權限，應儘可能以您自身方便為宜。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年6月6日 (四) 00:11 (UTC)[回复]

提供的IP问题

现在有个问题

如果申请者没有使用代理时使用此网站提交工单，被此网站自动带入的IP是其真实IP，而非使用代理且受到IP封禁的IP，对于IPBEG应该使用真实IP还是受到封禁的IP判断？如果有人使用代理访问此网站，有人不使用代理访问此网站，也会产生差异。
是否像传统邮件列表一样另外要求用户手动填入封禁界面上显示的受封禁的IP或封禁ID？这样也有好处，就是IPBEG可以看到申请者被封禁IP同时也能看到真实IP，确定申请者处于中国大陆等受限地区。但产生另外一个风险，就是如果确实提供的是中国大陆IP地址，一旦泄露可能产生严重后果。--桐生ここ★[讨论] 2024年6月6日 (四) 10:00 (UTC)[回复]
- 技术上有很多方法可以尽量避免记录IP，比如只记录部分IP、以及对管理员不显示IP，只显示IP是否处于封禁列表中。但是这些方法无一例外的会对管理员处理造成问题。我想到的各种方法中，只有一个值得实践的，是在工单解决之后将IP相关信息从工单中清除，避免永久留存。除此之外，就只有请管理员和IPBEG不要泄露IP地址。对于代理的问题，我可以加一个提示让用户记得开代理，再者就是干脆取消自动侦测IP这个功能，让用户自己填写IP和查封ID，和邮件列表保持一致。Bluedeck 2024年6月7日 (五) 07:43 (UTC)[回复]
  我有一个方案
  - 申请者不提供IP：不提交IP
  - 申请者选择提供IP：检测IP是否中国大陆或其他受限地区
    是：不提交IP地址，只自动提交申请者IP地区，并且要求申请者手动填写受封禁IP
    
    否：自动带入IP地址
  --桐生ここ★[讨论] 2024年6月7日 (五) 09:10 (UTC)[回复]
  补充：IP地区是提交由服务端判断，而不是在前端处理，所以实际上仍然会提交中国大陆IP，只是不会储存在服务器上。--桐生ここ★[讨论] 2024年6月7日 (五) 09:13 (UTC)[回复]
  检测IP是否中国大陆或其他受限地区这个感觉不是长久之计，GFW未来可能会给Unblock-zh上SNI封锁，用户会不得不套代理访问，这样Unblock-zh获取到的就不是真实IP--Yuki Rutygr (留言) 2024年7月9日 (二) 13:15 (UTC)[回复]
  - 我想过geoip定位这个方案，但是ip定位数据库需要每个月更新，而且并不完全准确。连维基媒体基金会都放弃了自己的geoip API（否则我就可以利用了）。有一个折衷办法，那就是查询封禁数据库。如果用户目前的IP不再封禁列表中，大概率说明没有开代理，此时我弹窗提示开代理。Bluedeck 2024年6月7日 (五) 19:59 (UTC)[回复]

(－)反对，考虑到Unblock-zh未来极有可能受到GFW封锁。--mije meli carrot_233 -- 讨论 2024年7月25日 (四) 11:33 (UTC)[回复]

网信办说的？ ——魔琴［身份声明留言贡献新手2023］ 2024年7月25日 (四) 15:07 (UTC)[回复]

这种网站大概率被墙。--mije meli carrot_233 -- 讨论 2024年7月30日 (二) 07:42 (UTC)[回复]

這反對理由太怪了，你維本來就被GFW刀了，有差嗎？--Sun After Rain 2024年7月27日 (六) 04:23 (UTC)[回复]

问题在于，如果Unblock-zh被GFW封锁，则中国大陆无法直连Unblock-zh，故无法获取真实IP。--mije meli carrot_233 -- 讨论 2024年7月30日 (二) 07:41 (UTC)[回复]

我们本来就不是为了获取用户的国内IP，因为目前邮件列表也只是看到你的查封ID和IP地址就对你进行授权，这被查封的IP地址往往都是VPN、代理地址。如果被墙后，还能解决代理不是全局的问题。因为没有被墙，有的代理会把没被墙的网站不走代理，导致我们接收到用户的没有被查封的IP地址，反而不是我们想要的。Bluedeck 2024年7月30日 (二) 16:50 (UTC)[回复]

罐头回复

经由路西法人的建议，增加了『罐头回复』功能。将常用的语句加入罐头回复列表，就能快速的一键回复工单。详见WP:Unblock-zh.org#罐头回复功能 Bluedeck 2024年8月12日 (一) 21:51 (UTC)[回复]

`ChooseNewName`标签

这是一个比较新的功能，当请求用户选择新的用户名时，加入`ChooseNewName`标签，同时摘掉`回复关闭`标签的情况下，工单用户界面会多出一个小工具，便于用户确认自己所选择的用户名是否可以注册。Bluedeck 2024年8月20日 (二) 08:16 (UTC)[回复]

請求社群判斷已經數據過期的用戶是否為傀儡

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:傀儡調查/案件/冏。

見相關SPI提報，現時最少有法國飲食文化、如懿傳、冊封體制受到影響（很可能還不止這些），請調查助理、管理員和其TA用戶判斷和徹底清查，謝謝！--MCC 214（Sign | Contributions） 2024年7月18日 (四) 05:12 (UTC)[回复]

外加一些賬號（包括SPA），請檢查是否為冏；

延伸內容

Fox T343（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

Lianfapi yizu（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

Konsstantinbao（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

BBuoyslemur（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

Shanmpin BO（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

巴斯克重乳酪（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

Taisclop（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

Aiyamayafaguocaiba（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

沃尔特密斯（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

橘紅的珍珠寶石（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

Berlaashe（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

ZHON-1138（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

Kobishitsu（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

DOVE-1314（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

阿偌（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

VeoTcukef（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

全景靚影（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

Admasuke（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

Hubbylei（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

武动仙人掌（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

Khan kanet（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

GUO-4080TTX（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

凯由（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

冥王夢魘（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

蟹粉小籠包（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

絲絲扣入情（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

Itypus（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

Yann1021232（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

Otterotuhm（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

古莱顿伯爵大人（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

Peessbyy（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

天使辣妹子（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

大栄光生徒（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

時空遷（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

慧炙之聖（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

Ugerrian（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

SA saudlabibibia（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

反误了卿卿性命（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

Tyessteel（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

光明熹（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

Elbehlian（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

西村小蝴蝶（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

Touty sarmor（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

西村小蝴蝶（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

Monke tuawen（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

Snowbsoliid（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

Balkviva（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

SWanapon（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

柳川步（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

Key queenslimn（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

Dustyrous（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

骷顱司乃帕（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

怎麼情感不傷（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

Planshabt（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

伊丽莎（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

遂遂阿年消得意（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

我您可否（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）
ZHzdishi（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

Doiluneyver（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

Haisily（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

Lauoudome（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

克魯克盧（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

韦斯卡奥兰托（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

Centachie（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

嵋姐姐（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

陳婉音（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

Morgen japanoiy（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

开花堕神（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

一心青梅（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

Sidelishi（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

后之霞（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

Locavie（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

Loyavchek（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

Vellyanchou（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

綠梅紅荔（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

Loyavchek（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

Rinudmee（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

傑頓宇宙（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

Bashang klut（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

Setspoyyu（讨论⁺ · 标记 · 贡献 · 已删贡献 · 日志 · 過濾器日志 · 封禁日志 · 封禁［傀儡］ · 全域帐户）

以上。--MCC 214（Sign | Contributions） 2024年7月18日 (四) 05:24 (UTC)[回复]

這難道不應該直接在傀儡調查頁面處理？—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年7月20日 (六) 17:39 (UTC)[回复]

這些Stale了的賬號，即使有可疑，放上SPI也查不了，所以只能放此。--MCC 214（Sign | Contributions） 2024年7月21日 (日) 05:32 (UTC)[回复]

(？)疑問-若數據過期，還能SPI嗎？是否主要以人工來判斷？Wetrace歡迎參與WP人權專題 2024年8月23日 (五) 01:31 (UTC)[回复]

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

仲裁委员会的选举

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:仲裁委员会。

今天看到Wikipedia talk:仲裁委员会#公示RFC結果及仲裁方針草案下早有公示过的仲裁委员会试行方案。在其之后仍有讨论关于是否有解任管理员的权力问题，但目前本人认为细节基本商榷的差不多了。目前唯一一个剩下的需要形成共识的事情就是在试行期间仲裁委员会需要多少支持率才能上任。定下这个可以直接开始筹备选举了。那么这下面先讨论支持率的问题吧？--0xDeadbeef (留言) 2024年8月2日 (五) 04:38 (UTC)[回复]

我个人认为支持率只需要50%就够了。首先考虑到仲裁委员会是一个需要社群高度信任的职务，在考量一人是否符合成为仲裁委员会的标准明显要比管理员的标准要高，于是反对的比率肯定会比管理员更高。本人希望中维能够选举出来第一届委员会，于是希望50%，这样既获取majority的支持（超过一半的人支持）也能给仲裁委员会给一个好的起点。（注：英维是采取60%以上可以任职委员会两年的机制，但因为这次试行所有人都是一年，故偏向50%。--0xDeadbeef (留言) 2024年8月2日 (五) 04:44 (UTC)[回复]

抄錄前一階段討論情況：

基本同意授予仲裁委員會委員「已刪除內容」、「非公開過濾器」、「IP信息」、「啟用雙因素驗證」等權限，
- 尚未有明確共識決定是否授予「查閱全站未受監視頁面」、「創建短連結」、「查看当前转码活动的信息」、「查看标题黑名单日志」等權限；
尚未有明確共識決定是否限制仲裁委員會委員在委員會既有職能外行使職權；
基本同意仲裁委員會委員（至少第一任期）選舉採相對多數（百分之五十）當選制；
- 尚未有明確共識決定是否按支持率多寡區分當選任期（如百分之五十以上為一年、百分之六十以上為兩年）；
基本同意仲裁委員會處理管理人員解任案件，係經調查確認存在操守違規事實後，方轉交社群決議是否除權；
- 尚未有明確共識決定如何區別或取捨仲裁委員會與社群既有解任管道；
基本同意仲裁委員會有權拒絕受理案件。

似乎第一屆確實不需要區分任期。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年8月2日 (五) 05:45 (UTC)[回复]

哎，当时的讨论有点久远，所以应该是不需要讨论支持率了？那我觉得可以直接开始筹备选举事宜。RFC先删掉，之后写点时间相关的内容。0xDeadbeef (留言) 2024年8月2日 (五) 06:19 (UTC)[回复]

但似乎還有若干職權問題必須商榷？要擱置也不是不行（仲裁委員會現有職權不少，也夠行使一整屆了吧？），但似乎想要快速推動仲委會設置提案者，目標都是希望該會介入（調查）管理人員解任，那就又不適合擱置？—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年8月2日 (五) 13:23 (UTC)[回复]

我选择先搁置管理人员解任问题是因为要是先选出来一批人，这一批人可以帮忙推动共识，也就是说在委员会成立之后再对于管理人员解任的事情帮忙推动共识。既然他们都选上了，他们来推动讨论、邀请社群成员来发表意见来形成共识个人觉得更合适--0xDeadbeef (留言) 2024年8月2日 (五) 14:12 (UTC)[回复]

(！)意見：對於「尚未有明確共識決定如何區別或取捨仲裁委員會與社群既有解任管道」：

1.若用戶未申請仲裁，自然可直接發起罷免解任。

2.若用戶申請仲裁，委員會決議不解任管理員，則社群在一段限制時間內不得以同一事由發起罷免（該段時間可議，比如半年、兩年等）；當該段限制時間過後，社群若以同一事由再次發起罷免，須出具自前次仲裁後出現的新事證（也就是新糾紛事件的時間點或所出具的證明實際發生在前一次仲裁後）。

3.若用戶申請仲裁，社群或相關用戶對委員會的決議不滿，可將委員會的決議，在具備可明確、合理、一般人所具智識即可辨識之理據或事證的前提下，向基金會投訴（也就是仲裁極其離譜，而如何為「極其離譜」，或可討論）。

4.若用戶申請仲裁，社群或相關用戶對委員會的決議不滿，可將委員會的決議發起公投，獲特定支持比率的情況下推翻。公投結果須具備數個條件方可具效力，如：不滿意仲裁結果的當事相關用戶須參與聯署（明言自願放棄表態或投票者除外）；總有效票須佔當時社群具投票資格用戶總數的相當比例（比如至少四分之一）；公投結果出爐起一段限制時間內（該段時間可議，比如半年、兩年等），不得就同一事項再發起公投；有效同意票超過不同意票。諸如此類。

5.若委員會決議遭推翻，社群自可再以同一事由發起罷免。惟為避免仲裁程序遭濫用或社群無謂虛耗空轉，社群在委員會決議正常生效、用戶不得以同一事由發起罷免原限制時段的二分之一期間內不得以同一事由發起罷免（該段時間可議，參見第2點，比如原本是半年或兩年不能再發起罷免，這種情況下須在三個月或一年後才可再發起罷免，但不須額外出具同一罷免事由的新事證）。

6.委員會決議遭推翻後，其仲裁結果之效力即自公投結果確認起解除；委員會決議遭推翻前，其仲裁結果之效力視為有效。

個人路過隨想意見，供參。--Kriz Ju（留言） 2024年8月2日 (五) 21:37 (UTC)[回复]

鉴于目前的闹剧，我不认为社群会信任仲裁委员会。--桐生ここ★[讨论] 2024年8月3日 (六) 05:57 (UTC)[回复]

同上，強烈反對以此次RFDA為由立即推動仲裁委員會上馬，社群有權就必須商榷的若干職權問題進行更加深入的討論。--🎋竹生🎍 2024年8月3日 (六) 11:50 (UTC)[回复]

首先，我并没有“以此次rfda为由”，而只是有人提到“若已有仲裁委员会，则可能此事处理能够更加妥当”的想法而选择推动。选择推动委员会选举，并不是代表不讨论职权问题，但是，早已为仲裁委员会的职权形成共识（其并不包含对于管理人员除权相关的事宜），则说明社群已有仲裁委员会上任的基础共识，所以我个人觉得你反对的理由无法站住脚的，欢迎你提出另外的理由。--0xDeadbeef (留言) 2024年8月3日 (六) 12:42 (UTC)[回复]

你可以解释一下这两者（目前的闹剧、社群对于仲裁委员会的信任）之间的关系。顺便，若是你自己表达不信任无妨，但请不要代替社群说话。--0xDeadbeef (留言) 2024年8月3日 (六) 12:34 (UTC)[回复]

一个RFDA案就已经出现某人或某些人（无法确定是不是WMLO）发送拉票（或伪装成拉票）的邮件，意图使RFDA通过或不通过。如果为解决RFDA而急于成立的仲裁委员会，难以想象是否会有更多对仲裁委员候选人的拉票（或伪装成拉票）的邮件试图让人当选或不当选。--桐生ここ★[讨论] 2024年8月3日 (六) 14:07 (UTC)[回复]

是的，所以我觉得先完善仲裁委员会的选举流程以杜绝不公平情况，然后再在这群人获得社群各方信任的情况下推动共识，是比较好的做法。至于急不急的问题，看社群可以搁置多久。我觉得久一点并无太大问题，毕竟一套完善的流程建立起来之后很多问题都会迎刃而解。--碟之舞📀💿 2024年8月3日 (六) 14:17 (UTC)[回复]

不要稻草人，我在这里讨论筹办选举又不是为了解决RFDA而急于成立的。--0xDeadbeef (留言) 2024年8月3日 (六) 14:19 (UTC)[回复]

不过这里要澄清一下就是我确实有在主群说过「在选出仲裁委员会再来调查」这一说法，实际上在我后来想过之后不现实，因为成立仲裁委员会之后估计RFDA案没有什么可调查的了。因此此次提出完全就是为了流程上继续推进而已。--0xDeadbeef (留言) 2024年8月3日 (六) 14:21 (UTC)[回复]

同樣支持50%。至於相關權限等問題，個人認為仍須回歸社群如何看待此權限及信任程度，如果目前的確認程度已經不需釐清所有細節，個人現無意見。--Kriz Ju（留言） 2024年8月5日 (一) 13:38 (UTC)[回复]

七日已过，总结一下上方的讨论。目前参与讨论的用户基本同意（至少在第一届）选举中采取相对多数当选原则，并就选举结束后继续推动仲裁委员会相关共识上基本达成共识。就此，我提议在今年9月份展开管理员选举的同时举行第一届仲裁委员会选举，七日内若无人反对或反对意见已解决的话就进行公示。--人间百态,独尊变态 (讨论) 2024年8月12日 (一) 11:36 (UTC)[回复]

在確定仲裁委員會權限及仲裁程序以前，選舉仲裁委員會委員沒有意義。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年8月12日 (一) 14:49 (UTC)[回复]

赞同。我们应该等到委员之权限得到确定之后再选举。--CuSO₄ · 龙年大吉 2024年8月12日 (一) 18:25 (UTC)[回复]

@Ericliu1912: Happy to talk about this off-wiki if you want. 首先在Wikipedia talk:仲裁委员会#公示RFC結果及仲裁方針草案下WP:仲裁/方针已经通过公示，于是以下为已确定（有共识，被社群接受的方针）的仲裁委员会的职权：

中文維基百科社群委託委員會處理以下事務：
在無法通過社群討論及管理程序等常規流程解決的嚴重用戶衝突中擔任最高爭議解決機關，作出具約束力的裁決；

處理管理人員解任請求（自請者除外）及

處理仲裁裁決有關之封鎖及禁制申訴。

至于仲裁程序也在方针下「流程」的section已经定下，不知道有什么还需要确定的。而基本权限部分也在Wikipedia talk:仲裁委员会#RfC：2024年2月定好。

目前唯一存在争议的是仲裁委员是否可以经决定直接解任管理员，而这一小细节不应阻止我们选出委员会吧？--0xDeadbeef (留言) 2024年8月13日 (二) 02:51 (UTC)[回复]

不，管理员仲裁解任权（暂且这么叫它吧）关乎“處理管理人員解任請求”的实施形式，是先前讨论的焦点之一。在下相信社群对于“谁适合当选没有管理员仲裁解任权的仲裁委员”和“谁适合当选有管理员仲裁解任权的仲裁委员”这两个问题的看法是有差异的。管理员仲裁解任权问题未解决就举行选举，无异于认为这种差异可以忽略。窃以为，这种差异值得得到关注，如果在解决管理员仲裁解任权问题前就选举，就操之过急了。--CuSO₄ · 龙年大吉 2024年8月13日 (二) 07:13 (UTC)[回复]

@CopperSulfate：我并不觉得属于操之过急，因为我觉得这是一个循环依赖 (en:circular dependency)。比如说，在讨论委员会是否应当有仲裁解任权的时候，便有人以「社群不一定信任委员会而支持其有这样的权力」来反驳我个人认为应当拥有此权力的观点。但是呢，如果人已经选出来了，那么讨论委员会到底是否应当有这种权力则可以在以选出的人作为context。比如说如果我个人信任被选出来的人，我个人就会对于委员会有这种权力更放心。如果我个人不信任被选出来的人，我可能就不会希望委员会有这样的权力。

另外，根据之前的匿名问卷，貌似已有大概共识在「仲裁委员不应有仲裁解任权，而是调查查证报告给社群」这一观点，所以以「委员会在前期很有可能不会有直接解任管理员的权限」来选举是合理的。

你觉得这样的解释是否合理？--0xDeadbeef (留言) 2024年8月13日 (二) 07:42 (UTC)[回复]

可以准备公示了。--0xDeadbeef (留言) 2024年8月19日 (一) 02:15 (UTC)[回复]

公示7日，2024年8月26日 (一) 11:54 (UTC)結束--0xDeadbeef (留言) 2024年8月19日 (一) 11:54 (UTC)[回复]

想問下不考慮技術原因，你們覺得選舉應該跟管理人員申請錯開還是一起辦？兩者性質畢竟不同，我當初提個「管理人員當然席位」還一直被打槍。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年8月19日 (一) 14:11 (UTC)[回复]

另外連個具體流程都沒有出臺就公示，未免操之過急。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年8月19日 (一) 20:59 (UTC)[回复]

个人认为试运行为方便放在一起。仲裁系统成熟后应错开。--0xDeadbeef (留言) 2024年8月20日 (二) 03:07 (UTC)[回复]

@0xDeadbeef(！)意見：鉴于社群在仲裁解任问题上已有模糊的共识雏形，如果不给予新当选的仲裁委员“管理员仲裁解任权”的话，我不反对尽早开始选举。--CuSO₄ · 龙年大吉 2024年8月19日 (一) 20:04 (UTC)[回复]

(？)異議：應先就選舉具體流程達成共識。另(？)疑問在「不需要考慮當選人有無權限決定管理員罷免」的情況下選出仲裁委員後，要進一步讓社群「信任他們能夠有權決定管理員罷免」豈不是更難？應先確定和細化「仲裁委員不應有仲裁解任權，而是調查查證報告給社群」的初步共識，這樣豈不更快。--🎋竹生🎍 2024年8月20日 (二) 02:48 (UTC)[回复]

@Ericliu1912 @Newbamboo，那就与管理员选举相似，一周预讨论（与管理员选举同时进行），一周提名期（可自己提名也可由他人提名，每个候选人应提供自我介绍），两周意见期（可提问、讨论），两周投票期如何？--0xDeadbeef (留言) 2024年8月20日 (二) 12:55 (UTC)[回复]

IPBEG標

本主題全部或部分段落文字，已移動至Wikipedia talk:IP封鎖豁免權授予者。执行人：Jimmy-bot（留言） 2024年8月23日 (五) 16:14 (UTC)。[回复]

是否应该移除所有被 WMF 封禁的WMC管理员担任管理员或群主的群组信息

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:QQ交流群、Wikipedia talk:中国大陆维基人用户组。

本人于之前加入了几个QQ群，发现有几个群组里面的管理员为之前受全域封禁之WMC用户，在我没有主动要求之前Techyan主动回应我，就在最近，他在另一个群组批判并论断我的身份，这令我感到不适。所以，我们是否应当移除所有被 WMF 封禁的WMC管理员担任管理员或群主的群组信息？

情况描述已在提案：移除所有被_WMF_封禁管理员担任管理员的群组信息发起讨论，另见讨论WMC准备启动新站建设、移除WP:QQ的QQ群904780983。 --Hzt0208042508415531 tw（留言） 2024年8月13日 (二) 21:14 (UTC)[回复]

@Hzt0208042508415531 tw你信WMLO嗎？：< -Lemonaka 2024年8月14日 (三) 03:30 (UTC)[回复]

我先听取意见，无谓真假对错--Hzt0208042508415531 tw（留言） 2024年8月14日 (三) 08:09 (UTC)[回复]

刚才才看到ta是傀儡，忽略ta吧--Hzt0208042508415531 tw（留言） 2024年8月14日 (三) 08:15 (UTC)[回复]

先不说这个有没有必要，你发之前不仔细看的吗……你把WMLO@出来，等下他傀儡又跳出来骚扰你和其他用户了，汗。别捅马蜂窝好吧，好不容易才消停一阵。个人建议关闭这个话题。--45.149.92.65（留言） 2024年8月14日 (三) 17:10 (UTC)[回复]

我在QQ群页面看到过这个号码，确实有提到受WMC控制的情况，但并非所有QQ群都受他们控制。因此，我们应该进行区分。他们在宣传求闻百科，可能会让人误以为求闻百科与维基百科有联系（这一点应该告知）。考虑到求闻百科运营公司的性质，他们的宣传有商业推广的嫌疑。此外，他们无故踢人，宣传求闻百科的行为可能导致用户流失并误导用户，这对维基百科造成负面影响，因此我建议移除相关信息。--Hzt0208042508415531 tw（留言） 2024年8月15日 (四) 09:20 (UTC)[回复]

已在提案页回复，现在已经有相关页面单独存放wmc关联的qq群，并有相关模板提示，如果还有留在主页面的类似qq群可以直接列入，无需采取其他行动，另外，你在提案中提及的qq群号未在站内其他位置出现过。--在下荷花，请多指教（欢迎签到） 2024年8月15日 (四) 15:57 (UTC)[回复]

中華臺北、中國臺北、中國北京、中華北京都是高風險主題

Wikipedia:頁面存廢討論/記錄/2024/08/09#中華北京很多用戶的留言未必中立公正。正試行中華北京重定向到中華台北#「中華台北」與「中華北京」，仍有不服的用戶先編輯戰，再宣稱“章節的中立性有争议。”故依照Wikipedia:高風險主題#指定高風險主題在此請求秉持公平、公正、中立的观点、公事公辦、對事不對人的管理員介入：

中華北京頁面存廢討論第一時間可避免，但就是有用戶小事重大化。請公正結案，至少應保留重定向，以及加入編輯提示，告知是高風險主題。林昶佐提出的“中華北京”是公事公辦而形成的“中華臺北”相反詞，因此重定向到中華台北段落是强調公共事宜，不是單純的私人看法。
Talk:中華台北#關於「中華台北」與「中華北京」一節是延伸中華北京頁面存廢討論的。也請公正應付。
請對事不對人的集體善意勸告留言用戶维基百科:高風險主題是重要方針。不希望任何用戶遭到編輯限制。
中國臺北以及中國北京也請加入編輯提示，告知是高風險主題。--Jusjih（留言） 2024年8月15日 (四) 12:14 (UTC)[回复]

(＊)提醒@Jusjih你的用戶組是管理員(從2008年起)--Rastinition（留言） 2024年8月15日 (四) 12:24 (UTC)[回复]

謝謝提醒，但依照Wikipedia:管理员#避嫌，中華北京頁面存廢討論已涉事，才有請其他公正管理員。也祝身體健康，才能更好的參與維基。--Jusjih（留言） 2024年8月15日 (四) 12:32 (UTC)[回复]

是不是WP:CS4D高風險？ -Lemonaka 2024年8月15日 (四) 13:03 (UTC)[回复]

可列入海峽兩岸四地政治高風險主題。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年8月15日 (四) 14:53 (UTC)[回复]

通通算WP:CTOP/CSRPS一部分？--Sinsyuan✍️🌏🚀 2024年8月15日 (四) 15:19 (UTC)[回复]

是的。通通算WP:CS4D高風險以及WP:CTOP/CSRPS一部分。--Jusjih（留言） 2024年8月16日 (五) 13:24 (UTC)[回复]

引進CampaignEvents擴充功能

路過看到這一擴充功能，因本站時常舉行編輯松，似乎可以引進來測試一下看看效果，不知諸位覺得如何？—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年8月16日 (五) 02:05 (UTC)[回复]

(＋)支持：顺便把扩展主页翻译到中文了 ——即请秋安 ZhaoFJx_{（论•编）} 2024年8月16日 (五) 09:37 (UTC)[回复]

個人不反對此等引入。不過，現階段如何運用該功能？就個人理解，本站編輯松的註冊大多利用維基上的頁面（如動員令）或 fountain（如亞洲月），似乎它略簡單的註冊功能（缺乏計分功能）未必適用本站？而它的邀請功能雖明顯有利編輯松的參與度，但現在仍測試中。謝謝。--SCP-0000（留言） 2024年8月18日 (日) 13:12 (UTC)[回复]

@SCP-2000：所以正應該引進來試試操作，反正不適合就擱著不用，也無大礙。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年8月19日 (一) 14:02 (UTC)[回复]

再议设立编者著作权调查

之前的讨论见此。

在上次的讨论中，讨论用户就设立编者著作权调查一事基本达成一致。根据此共识，鄙人在此提出编者著作权调查的草案。若草案有不足之处还请指出。--人间百态,独尊变态 (讨论) 2024年8月17日 (六) 13:00 (UTC)[回复]

字句及流程问题：

“多次撰写”，很多侵权文字不算撰写。“多次”的断句有风险。建议“多次上传侵犯版权的内容（文字或图片）的用户”。
“长期且大量的侵权行为”的长期是否能去掉呢。
“五处及以上侵权行为”改成“至少五例侵权行为”。
“（包括修订版本和图片）”的含义模糊，次数计算方式需要摸索和设定常识（如过往已结案案例与承诺；同一条目的多次或连续编辑）。
“已被封禁则不必通知”的含义，对于近期封禁、申诉中仍可能需要？尽可能通知仍允许？
“此前未参与该调查申请”的含义，支持提报或提供证据算参与吗，与“提报人以外”的差别是？
未见拒绝的时间点，拒绝后如何抗议。
创建子页面及填入数据的流程指南。
“用户如果批准了一个调查申请，那么就需”->“批准调查申请的用户需要”。
已删除内容的审阅，可能需要借助站外工具或管理员，而非以?结案？

总体而言支持试行，具体流程慢慢来定，以讨论和共识为基准。--YF dyh000（留言） 2024年8月17日 (六) 13:31 (UTC)[回复]

已微调第一条的建议。--YF dyh000（留言） 2024年8月17日 (六) 14:37 (UTC)[回复]

「沒有證據的調查申請可能會被認定為是擾亂行為」這句中的「擾亂行為」可以考慮連結到Wikipedia:游戏维基规则。
還有如何判定調查申請的理由是否充足，有沒有相關標準？
另外還有User:YFdyh000提到的兩點：被拒絕申請後如何上訴；建立子頁面及填入數據的流程指南何在。--Benho7599 | Talk 2024年8月17日 (六) 13:57 (UTC)[回复]

@Hoben7599、YFdyh000：在这里统一回复下两人的问题

YFdyh000：

已修改
已去除
已修改
上次讨论中对于如何算一次侵权行为，基本认为如果用户在一个修订中有上传侵权内容行为就算一次侵权。不过含义模糊这点也确实存在，所以这处我已经改成了对侵权行为本身的举例描述。
已修改
已修改为提报人以外
已添加相关内容
已添加相关内容
已修改
已添加相关语句，但?确有存在的必要。例如搁置以等待管理员查阅，或表示该内容不值得审阅。

Hoben7599：

关于如何判定调查申请的理由是否充足，我已经在草案中给出了标准--看调查申请给出的证据是否能够证明该用户是否存在至少五处侵权行为。至于如何判断为侵权行为，这就不是这个草案该解决的问题了。

--人间百态,独尊变态 (讨论) 2024年8月18日 (日) 06:12 (UTC)[回复]

中文現階段可能不需要個別案件子頁面（我預計此種專門調查不會如傀儡調查頻繁），全部放在同一請求主頁面即可。這樣也可以加快立案流程，減少技術負擔。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年8月18日 (日) 10:44 (UTC)[回复]

设立案件子页面恰恰是为了分担主页面内容。如果将贡献数据全堆在主页面的话反而会显得主页面有些臃肿，所以在设计时我才沿袭了英维的分页面处理方案。--人间百态,独尊变态 (讨论) 2024年8月18日 (日) 12:29 (UTC)[回复]

支持，上次讨论就是我发起的（--0xDeadbeef (留言) 2024年8月20日 (二) 12:56 (UTC)[回复]

為管理人員任免制度檢討等事

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:申请成为管理人员、Wikipedia talk:管理員解任投票、Wikipedia talk:管理員解任投票/Mys 721tx/第2次。

近期又一管理人員解任投票，甫應用安全投票之新制，技術實務運作尚難稱熟稔；又逢顯著外來干涉及共識形成程序疑慮，遂致前所未有之困窘，亂象叢生、弊端頻出，社群矛盾對峙趨於激烈，此實無庸置疑。與此同時，定期審視更新管理人員任免制度，有助於人才新陳代謝，充實本站進階維護量能。時值仲裁委員會組織籌備停滯之際，「遠水難救近火」，故謹以此話題為首，先行就管理人員任免制度若干既存問題略作檢討，望社群踴躍發表意見。改革路程自不必操之過急，但求氣象有所更新爾。本人謹提出三個大問題，社群可撥冗予以回應，或自行提出其他值得專門討論之問題。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年8月18日 (日) 18:29 (UTC)[回复]

安全投票問題

目前，本站之管理人員任免案，均採行安全投票制度。安全投票之匿名，優缺點一體兩面，優點在於得脫離現實外力束縛，保障自由表達意見，有助於完整呈現社群意志；缺點則在於幾無制衡極端之手段，如此次投票之若干附言，或因涉及與當事人之私人恩怨，極盡猥瑣下流之能事，對部分群體及特定個人之攻訐、人身攻擊及無理羞辱等暴言（本人不擬重述各種不堪入耳之文字於此，請自行閱讀相關內容），不僅早已背離解任投票本身形成有效共識之意旨，更遠遠超出社群應容忍之文明底限，而顯難以「可受公評」為藉口。此外，安全投票雖號稱得以防堵大規模公然拉票之威脅，惟迄今其效果不僅有待商榷，而社群因該制度高度封閉之特性，反而難以協助查核投票細節；如此次投票雖有嚴重擾亂之指控，但僅有少數電子郵件等書面證據，社群無法對比既有編輯貢獻，或額外確認許多可疑相關內容。又安全投票長期未能由本地社群完整掌握，須受制於全域社群等客觀限制；投票設定程序繁瑣冗長，更屢生不可抗力之技術問題，若與其他因素疊加，結果甚至可能損及管理人員任免案本身之公信力。安全投票本為預防若干外部勢力之現實威脅而設，此種威脅既已有消退跡象（與本站志趣不合之同志，多已分道揚鑣不復歸），加之以前述安全投票之弊端，雖難謂前述惡意影響蕩然無存（此處須特別強調仍不應低估危險），惟兩相權衡下，認為有酌加商榷該制度應用之必要，至少亦應有些許合理討論。謹嘗試提出問題如下：

一、社群過往執行安全投票，就可自行控制之部分（不包含須迎合全域動態之技術安排等），有何應從速改善之處（如事前人事選定等籌備作業、事後點票及公告程序等）？

二、社群應是否繼續於管理人員申請及管理員解任投票採行安全投票？或研議若干指標，持續評估是否沿用，乃至於採取行動，制裁投票過程可能出現違反方針與指引之舉？—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年8月18日 (日) 18:29 (UTC)[回复]

就管理员解任而言，我个人觉得非常有必要返回公开讨论的机制。

1、安全投票所带来的「隐私」实际弊大于利，共识应当是一个持有不同意见的人互相尝试说服对方的过程，而无法回复他人意见导致事实查核无法有效反驳（例：Bluedeck原话说不至于不限期封禁，在解任界面持续被说成第三方管理员不认同可构成查封理由，而Bluedeck实际上会有限期封禁。）另外，安全投票对于外部影响有混淆的负面效果，如果有人平时没有编辑的突然在解任案上发表意见，则可能是被拉票。公开投票则让社群更能够找出可能影响。

2、安全投票程序复杂，给志愿者带来不必要的工作

3、未发现公开讨论有哪些弊端，目前的恶意影响有利用信息不透明的嫌疑，因此不认为站内投票会加强恶意影响。--0xDeadbeef (留言) 2024年8月19日 (一) 02:35 (UTC)[回复]

1、可自行控制之部分之后基金会可能允许直接在本地维基上举行安全投票，有关要求可以跟基金会提。

2、安全投票可以保证意见不受干扰，虽然WP:暴力威胁风险降低，但也有公开表达意见者遭受WP:骚扰的问题，因此社群應繼續採行安全投票。

3、对于制裁投票過程可能出現违反CIV、PA等投票内容，应该可以宣告辱骂他人等违反方针的投票无效，相信很多人就不会发出违反方针的内容了。必要情况下也可以请求基金会协助，因为技术上还是能找到这个人的。

4、投票前就可以讨论并尝试达成共识，投票中也仍然可以在站内讨论，也可以回复他人意见。另外也建议公开投票人名单即可找出可能的影响。

--桐生ここ★[讨论] 2024年8月19日 (一) 03:34 (UTC)[回复]

有公开表达意见者遭受WP:骚扰的问题 - 如何证明安全投票减少骚扰，或公开投票骚扰现象会更多？ 0xDeadbeef (留言) 2024年8月19日 (一) 11:18 (UTC)[回复]

使用安全投票，骚扰者不知道你的态度，所以根本不会骚扰你，因为他根本不知道你的意见和他一致还是相反。使用记名投票，骚扰者知道你的选择和他不同，自然可以骚扰你。你维现在也有邮件骚扰这种事。--桐生ここ★[讨论] 2024年8月19日 (一) 13:07 (UTC)[回复]

这个和安全投票防止暴力威胁的原理是差不多的。--桐生ここ★[讨论] 2024年8月19日 (一) 13:10 (UTC)[回复]

并不觉得这种未经证实的事情（你只是提供了「公开投票可能有更多骚扰行为」的解释，你并没有证明这实际上会发生）可以作为以投票代替讨论的理由。共识就应该以讨论来产生，安全投票只会导致原本愿意沟通的人更加两级分裂（参考此次解任案）而对于对方的合理观点不予理会。--0xDeadbeef (留言) 2024年8月19日 (一) 13:17 (UTC)[回复]

附议。甚至之于管理员选举等重要议事事项也未尝不能恢复到公开投票的模式。--SheltonMartin留言|签名 2024年8月20日 (二) 06:31 (UTC)[回复]

@SheltonMartin：可否澄清一下此附议是指哪一个留言--0xDeadbeef (留言) 2024年8月20日 (二) 12:58 (UTC)[回复]

您的。--SheltonMartin留言|签名 2024年8月22日 (四) 02:37 (UTC)[回复]

(！)意見虽然安全投票可以很好地隐藏发言人，并且在结束前无法得知意见，但这也催生了一些可从本次投票窥见的问题。A. 安全投票能保护投票人，可能会有人抱着找不到我的心态投票，导致一些公开投票不会出现的留言；B. 依WP:投票不能代替讨论，隐藏意见对共识的取得是致命的，无疑盲人摸象。就好比辩论双方只能写意见到白板上，裁判喊321同时亮牌子并直接打分。纵观RFA/AFD投票，经常会有人被他人说服后改票。

直接取消安全投票也可，但我也想了两种不成熟的折中方案，供社群参考，抛砖引玉：

先行投票是否启用SecurePoll

在依方针举行SecurePoll前，先请各位维基人对是否启用安全投票进行投票。投票完毕后，则按照结果正常执行程序。补充：也可考虑仅允许投票选择投票方式的用户参加正式投票，此举一可以避免群发讨论页信息，二可提前筛选用户。

安全投票之优势在于避免受他人威胁与保护自我隐私，如果上述二种诉求不强烈，大可采用更便捷的公开投票。缺点则会使过程冗长。

自愿隐藏投票者

与旧投票方式无异，但是用户可自行选择隐藏投票签名者。目前能想到的办法是请求监督隐藏编辑者用户名？

优点是便于划无效票，并及时知道他人意见以供参考。缺点则会增加监督工作量。——即请秋安 ZhaoFJx_{(论•欢迎签名)} 2024年8月20日 (二) 15:52 (UTC)[回复]

涉及管理權限爭議之過渡仲裁措施

此次投票，一大理據涉及管理權限特定爭議。此種複雜之爭議，本應考慮由具公信及專業之第三方維基人組織仲裁，詳加審核相關操作及證據，並經深入思索提出報告供參為宜。「管理員的離任方針」亦明確強調，解任投票屬最終手段，當有十足充分之考量而行之；若能藉由仲裁措施或處分有效釐清雙方權責過失，並藉由溝通有效緩和爭議、化解雙方分歧，最終往往毋須訴諸解任。惟本地現有制度，尚未提供前述第三方仲裁措施之基礎；如管理員布告板，向來無力處理特別嚴重之爭端，而此次投票縱有若干管理員等社群成員就解任理據獨立從事查證，惟其受時間、人力等客觀限制，亦難稱臻至完善，且未能獲社群正式背書，效力恐有所折扣。近年來本站籌設仲裁委員會，固有就此問題予以釜底抽薪之可能，惟社群現階段仍在討論組織及人事細節，望其短時間內付諸運轉、乃至於樹立適當權威，自是天方夜譚。值此一過渡之際，實有賴社群即時研議臨時仲裁措施，以處理涉及管理權限之爭議。謹嘗試提出問題如下：

一、社群對於現有個別管理員難以處理龐大管理權限爭議之情況（如管理員布告板各子布告板等），有何協助應對之可能方案？

二、社群現階段於嚴重權限爭議及解任投票「決戰」夾縫間，是否可能留有任何緩衝之選擇？如比照相關權限方針，引進停權警惕機制？甚或搭配獨立第三方調查制度，由行政員、管理員或其他有能社群成員聯席組織，以停權當事人之臨時處分，換取些許餘裕，得為有限期而妥當之調查報告，而免於驟然躍進解任投票之地步？

註：有關仲裁委員會之組織細節，請繼續踴躍參與上方相關段落討論。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年8月18日 (日) 18:29 (UTC)[回复]

“解任投票屬最終手段”这话没错，而且社群也遵循了这一规则：反正都不能沟通，当然要使用战争手段，而你维的战争手段不就是拼人数吗。说了多少遍了，你们非要从众而不是从贤。 --ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年8月20日 (二) 09:38 (UTC)[回复]

「臨時」管理員任期問題

社群晚近引進「臨時」管理員機制，為尚待爭取社群充分信任者提供有限期權限以為鍛鍊。惟「申請成為管理人員方針」指出：「臨時權限與一般不限期權限無異，但需在任期結束前重新申請，並經社群投票確認，才能繼續保留權限。」對於所謂「投票確認」之細節語焉不詳，尤未有聲明此種「臨時」之有限效期是否得以連續申請無條件延長（形同「任期無限」），此於本年新一輪管理人員申請前當有所解決，方得迴避無謂混亂。謹嘗試提出問題如下：

一、社群是否應保留「臨時」管理員機制？抑或取消之，或再研議其他制度以為替代？

二、社群是否應就「臨時」管理員之任期有所限制？如限定任一期或連任特定次數以後，次輪（下輪）申請累積信任須達到正式通過門檻，否則即應收回「臨時」權限，越次輪（下下輪）始得重行申請？或改為逐步提高次一任期之通過門檻，直至正式通過為止？

註：特副知目前本站唯一「臨時」管理員@ATannedBurger。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年8月18日 (日) 18:29 (UTC)[回复]

臨時管理員機制既然是提供給還沒取得社群充分信任的人爭取社群信任，那麼臨時管理員就應該把握時間讓大家認可他，加上臨時管理員權限與一般管理員無異，代表臨時管理員在下一次申請前能充分表現，若是經過一次任期仍無法取得社群足夠的信任，那或許就是暫時還不適任，因此我認為臨時管理員在次輪申請時需至少達到正式通過門檻，若無法達到則應收回臨時權限，下下輪才能再申請。--PC 2024年8月18日 (日) 20:36 (UTC)[回复]

我認為臨時管理員機制多少還是有些必要性。不論是因為當前社群對永久管理員門檻的下調程度有限，又或者是在實務上能幫助社群多認識和了解新管理員處理事務的方式，貿然取消當前制度的話很可能導致經常被詬病的管理員難產問題再次重現。

第二個問題的話大致上同PC君的觀點。考量到臨時管理員的當選區間（65% ~ 75%）並沒有很大，逐步提高次一任期之通過門檻究竟是需要離上次當選差多少百分比（換句話說，多少的提升才無法用誤差範圍/臨界值來解釋），為了避免此類爭議，我覺得倒不如選擇較為乾脆的處理方式會比較洽當。--

\int

（☎）dt 2024年8月18日 (日) 20:52 (UTC)[回复]

1、若现在取消临时管理员，那么这个试验期太短，无法评判临时管理员制度效果，因此建议目前保留。

2、大致认同PC意见。--桐生ここ★[讨论] 2024年8月19日 (一) 03:40 (UTC)[回复]

停止以投票决定结果

具体意见与前次RFC相同。在维基百科的权限得失上用投票得结果不过是拙劣的cosplay。既然这么喜欢互煮，建议改成就某人是否能担任管理员一题不设时间限制辩论至得出共识为止。——暁月凛奈 (留言) 2024年8月21日 (三) 08:36 (UTC)[回复]

所謂「投票」是有必要的，因為以社群規模永遠不可能純經討論得出共識，最後還是會變成「類似投票」（!vote）。其實管理人員申請及解任投票理論上一直都是「類似投票」；個人反而覺得「解任投票」目前看來很有必要降低純「投票」的成份（儘管社群整體意見仍占有極高比重）。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年8月22日 (四) 13:53 (UTC)[回复]

澄清解任过程中发言的不同解读

关于0xdeadbeef阁下在讨论中提到（例：Bluedeck原话说不至于不限期封禁，在解任界面持续被说成第三方管理员不认同可构成查封理由，而Bluedeck实际上会有限期封禁。），在下认为是不当解读，澄清可见于：澄清解任过程中发言的不同解读。 --Gluo88（留言） 2024年8月23日 (五) 09:45 (UTC)[回复]

其他意見

此處供社群發表雜項意見，若有重要問題提出者，歡迎於上方新置章節。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年8月18日 (日) 18:29 (UTC)[回复]

除放置公告欄外，是否亦考慮寄送使用者討論頁通告，俾便廣大社群知悉參與？—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年8月18日 (日) 18:29 (UTC)[回复]

同意应该寄送。 ——魔琴［身份声明留言贡献新手2023］ 2024年8月20日 (二) 12:01 (UTC)[回复]

简要模仿管治讨论做了一份通告模板供参考。——即请秋安 ZhaoFJx_{(论•欢迎签名)} 2024年8月21日 (三) 06:44 (UTC)[回复]

關於新建LTA頁面

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:持续出没的破坏者/原神、米哈遊相關破壞。

如題，本人昨天依據部分經驗以及日文維基百科片段建立了LTA:GNSN頁面，但根據LTA創建指示，只有在破壞易誤會為善意編輯時有需要創建頁面。

然GNSN之破壞行為皆非常明顯，不易誤認，請問各位此頁面是否有存在之必要？--William is Wikipedia! 2024年8月21日 (三) 07:30 (UTC)[回复]

我认为没必要，列入LTA反而让其目的达成。回退、封禁、不理会即可。--自由雨日🌧️（留言｜贡献） 2024年8月21日 (三) 08:09 (UTC)[回复]

不过William指出这些破坏者应当提交全域锁定，不知道这和列入LTA是否有相关性？

思考...--自由雨日🌧️（留言｜贡献） 2024年8月21日 (三) 08:11 (UTC)[回复]

(～)補充：据最新资料显示，中维的原神破坏者似并非LTA:GNSN（我认为该“声明”可信度较高）。他列出的那些傀儡账号或IP，行为确实和疑似真正的LTA:GNSN创建的GoogleRitz 2行为有异。--自由雨日🌧️（留言｜贡献） 2024年8月21日 (三) 08:50 (UTC)[回复]

(：)回應，如果聲明沒有騙人，那我們其實也沒什麼需要花太多時間討論這個了...不過我想連ja那邊應該也還不知道這個GNSN是假的。--William is Wikipedia! 2024年8月21日 (三) 09:37 (UTC)[回复]

ja那边有关注到我们中维的这个“假GNSN”吗？--自由雨日🌧️（留言｜贡献） 2024年8月21日 (三) 10:51 (UTC)[回复]

看起來還沒，不過這可能就要勞煩較為熟知日語及日語維基的人幫忙了。--William is Wikipedia! 2024年8月21日 (三) 12:36 (UTC)[回复]

我的意思是，日维那边“是否知道中维最近两个月出现了这个假GNSN”，而不是“是否已经知道中维的这个GNSN是假的”，如果是“完全没有注意到中维的这个人”的话，那应该就什么也不用做？不过看您的回复，应该是后者，即他们“已经知道了，但还不知道是假的”这种情况……--自由雨日🌧️（留言｜贡献） 2024年8月21日 (三) 12:42 (UTC)[回复]

抱歉是我沒表達清楚，但我從日語的破壞者紀錄頁面發現他們也有記錄到這幾個假的GNSN（他們在ja也有破壞被封禁）他們似乎還不知道這些最近才出沒的LTA是假的。--William is Wikipedia! 2024年8月21日 (三) 12:54 (UTC)[回复]

同意自由雨日的說法，攻擊太明顯了，大多數情況下長期破壞者並不需要被記錄。--Nostalgiacn（留言） 2024年8月23日 (五) 08:31 (UTC)[回复]

LTA:2077、LTA:QCHM、LTA:RF、LTA:WOW等用戶也是純破壞或攻擊。另WP:RBI不是正式方針。--132.234.228.192（留言） 2024年8月23日 (五) 08:58 (UTC)[回复]

他們是LTA方針修訂前納入的LTA，不一定適用新案例--—— Matt Zhuang表示有事按「此」留言 2024年8月23日 (五) 09:38 (UTC)[回复]

如Matt Zhuang所言，記錄指南這個記錄標準，是2023年2月才通過。很多標準在變，這個不溯及既往的規則，所以舊的不以新標準評判。--Nostalgiacn（留言） 2024年8月23日 (五) 10:06 (UTC)[回复]

管理操作覆核請求：被提报用户明显存在不文明行为时拒绝做出相应处理

本主題或以下段落文字，在討論結束後應存檔至Wikipedia:管理操作覆核請求/存檔。

此請求是根據Wikipedia:管理操作覆核請求所提出，請先閱讀相關內容。

操作： Special:Diff/83911370

执行者： Manchiu （討論 · 貢獻 · 日誌）

先前讨论：Wikipedia:管理员布告板/其他不当行为#Zhenqinli

如题。 --——— 红渡厨（留言・贡献） 2024年8月22日 (四) 04:23 (UTC)[回复]

首先紅渡廚閣下只對這個版本發出了警告，未見雙向留言溝通。個人認為紅渡廚閣下提出的每個版本裡，能看到紅渡廚閣下的文字，非常地很有個人風格，對比Zhenqinli的文字，兩位都很有自己的直率文字格調。將心比心，在假定善意且為初次提報之下，管理員處置並無不妥，若經過溝通無效加上數次警告後，提報才是最後考慮。（另建議，中文字儘量避免使用斜體。）--提斯切里（留言） 2024年8月22日 (四) 14:25 (UTC)[回复]

斜体是AARV模板附带的，大家熟悉一下，请各位阅读Wikipedia:管理操作覆核請求，这是本站第一个AARV

--桐生ここ★[讨论] 2024年8月22日 (四) 14:41 (UTC)[回复]

原來是這樣啊、我的誤解、非常抱歉請見諒。--提斯切里（留言） 2024年8月22日 (四) 14:59 (UTC)[回复]

我认为您说的是有道理的，我这几天会找时间与被提报用户沟通，感谢您的意见。（另外，阁下说的斜体是指的“此请求是根据Wikipedia:管理操作复核请求所提出，请先阅读相关内容。”吗？）--——— 红渡厨（留言・贡献） 2024年8月22日 (四) 14:42 (UTC)[回复]

見桐生君解釋後明白是我的誤解，都是模板不好（?），請見諒。--提斯切里（留言） 2024年8月22日 (四) 15:02 (UTC)[回复]

没事。--——— 红渡厨（留言・贡献） 2024年8月22日 (四) 15:09 (UTC)[回复]

一般按照以往案例来说，违反CIV而采取封禁的都是显而易见带脏字的辱骂他人。--桐生ここ★[讨论] 2024年8月22日 (四) 14:35 (UTC)[回复]

我也認同，雖然言論可能有些許不妥，但離CIV還遠了。--William is Wikipedia! 2024年8月22日 (四) 14:47 (UTC)[回复]

懂了，在你维可以随便阴阳怪气，随便恶意揣测他人动机。--——— 红渡厨（留言・贡献） 2024年8月22日 (四) 14:49 (UTC)[回复]

非此意，只是依以往案例，比較像AGF而已，並沒有要贊同這種行為。--William is Wikipedia! 2024年8月22日 (四) 14:55 (UTC)[回复]

同WilliamSkyWalk。--桐生ここ★[讨论] 2024年8月22日 (四) 14:58 (UTC)[回复]

你们是不是此意不重要，关键是有管理员觉得可以啊，反正像《Wikipedia:管理员布告板/其他不当行为#Zhenqinli》这样恶意揣测，只会得到管理员的一句不痛不痒的提醒，那我以后也这么讲话咯。--——— 红渡厨（留言・贡献） 2024年8月22日 (四) 15:08 (UTC)[回复]

在假定善意之下，個人認為紅渡廚閣下盡量試看看先跟對方溝通，請他避免自我揣測。就像現在，我覺得您直接認為管理員沒有看出對方的「惡意」的發言略帶有「攻擊性結論」。每個人感受到不同，可能也許或者我猜您會說我就是這樣說話，但對方或許也是呢。還是試著聊聊吧。--提斯切里（留言） 2024年8月22日 (四) 15:14 (UTC)[回复]

我還是希望大家多溝通為宜。--千村狐兔（留言） 2024年8月23日 (五) 22:51 (UTC)[回复]

你维很多人确实有一种愚蠢的文明观：只要不带脏字，怎么骂人，怎么冒犯，怎么诽谤都可以。但是。你要说人家是诽谤，也要说清楚为什么是诽谤吧？ --ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2024年8月23日 (五) 08:51 (UTC)[回复]

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