跳转到内容

Wikipedia:互助客栈/其他：修订间差异

本页使用了标题或全文手工转换
维基百科，自由的百科全书
以互动方式浏览历史
←上一版本下一版本→
删除的内容 添加的内容
可视化wikitext
小 =
第1,026行： 第1,026行：
::如此想必可以进一步盘活讨论页。各专题协作起来也更高效。--<span style="text-shadow:0 1px 10px #FFF;background:linear-gradient(30deg,#FAE3CB,#D8A3D5,#7B8DDD);border-radius:999px;padding:0 15px">[[u:PexEric|<span style="color:#fff">'''PexEric'''</span>]]</span>[[ut:PexEric|💬]]&#124;[[u:PexEric/签名簿|📝]] 2024年7月22日 (一) 13:45 (UTC)
::如此想必可以进一步盘活讨论页。各专题协作起来也更高效。--<span style="text-shadow:0 1px 10px #FFF;background:linear-gradient(30deg,#FAE3CB,#D8A3D5,#7B8DDD);border-radius:999px;padding:0 15px">[[u:PexEric|<span style="color:#fff">'''PexEric'''</span>]]</span>[[ut:PexEric|💬]]&#124;[[u:PexEric/签名簿|📝]] 2024年7月22日 (一) 13:45 (UTC)
:GA、FA、FL評選完移至條目討論頁存檔的話題，也會出現在索引頁內，建議索引頁可以排除這些「存檔」性質的話題。--[[User:巴波|巴波]]（[[User talk:巴波|留言]]） 2024年7月28日 (日) 22:22 (UTC)
:GA、FA、FL評選完移至條目討論頁存檔的話題，也會出現在索引頁內，建議索引頁可以排除這些「存檔」性質的話題。--[[User:巴波|巴波]]（[[User talk:巴波|留言]]） 2024年7月28日 (日) 22:22 (UTC)
::我早前就加了filter篩除這些存檔話題，如果還有遺漏請將標題添加nowiki標記報告給我，我加到filter上。--'''[[U:LuciferianThomas|<span style=color:#b00>路</span>]][[UT:LuciferianThomas|<span style=color:#b00>西</span>]][[Special:用户贡献/LuciferianThomas|<span style=color:#b00>法</span>]][[路西法主義|<span style=color:#b00>人</span>]]''' 2024年7月29日 (一) 02:04 (UTC)


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

2024年7月29日 (一) 02:04的版本

快捷方式

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

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


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


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

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

公告欄
# 💭 話題 💬 👥 🙋 最新發言 🕒 (UTC+8)
1 仲裁委员会的选举 1 1 LuciferianThomas 2024-10-22 10:22
2 引進CampaignEvents擴充功能 36 9 ZhaoFJx 2024-10-29 08:44
3 為管理人員任免制度檢討等事 139 33 Ericliu1912 2024-10-27 05:43
4 管理人員申請預討论（2024年9月） 119 32 Ericliu1912 2024-10-27 05:49
5 仲裁委员会选举预讨论 1 1 LuciferianThomas 2024-10-22 10:24
6 IPBEG選舉改革 19 10 ZhaoFJx 2024-10-28 08:39
7 提醒：互联网档案馆暫時無法使用 4 3 Ericliu1912 2024-10-27 05:51
8 Internet Archive已暫停多日 16 10 So47009 2024-10-30 21:38
9 在本地啟用安全投票及electionadmin权限 26 9 LuciferianThomas 2024-10-28 12:29
10 Category:使用创建条目精灵建立的页面是否应有机器人自动移除？ 3 2 忒有钱 2024-10-28 00:34
11 亚洲月2024 18 10 魔琴 2024-10-29 14:17
12 慨歎，今天GAN清空 6 4 Sanmosa 2024-10-21 22:21
13 能否折叠一下存档 6 4 Ericliu1912 2024-10-24 16:50
14 关于图片的版权问题 3 2 Thyj 2024-10-24 09:20
15 Globan ban request against User:Won1017 4 4 魔琴 2024-10-26 15:55
16 关于仲裁委员会职权的疑问 78 17 Newbamboo 2024-10-30 19:55
17 仲裁委员会候选人在站外个人群组拉票一事 39 14 薏仁將 2024-10-30 16:33
18 仲裁委员会退选程序 11 9 0xDeadbeef 2024-10-30 16:51
發言更新圖例
  • 最近一小時內
  • 最近一日內
  • 一週內
  • 一個月內
  • 逾一個月
特殊狀態
已移動至其他頁面
或完成討論之議題
手動設定
當列表出現異常時，
請先檢查設定是否有誤

正在廣泛徵求意見的議題

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

維基專題與協作

Template talk:Duck § 更正默認提示文字？

@Cookai1205、Yoyolin0409：參見 WP:DUCK。確有理由更改、去除「一望而知」字樣。冀達成共識。— 𝕏ℂ𝕠𝕞𝕙𝕘𝕙𝕒𝕝𝕝 talk 2024年9月24日 (二) 02:18 (UTC)

評級系統缺失問題

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

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

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

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

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

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

我認為應將{{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)[回复]
支持合并。不过纯模板实现也不错。--桐生ここ★[讨论] 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)[回复]
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

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

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

「未來級」等級被正確識別（使用沙盒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)[回复]
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

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

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

目前有多個被全保護的評級模板/块的評級值（如有的有漏掉、有的圖案、顏色不一致）並不同步，因此提議同步各評級模板/块的評級值。不曉得各位有沒有異議或意見。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 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)[回复]
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

提案已通過請求佈署

已佈署：
下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。
佈署相關編輯，也就是編輯以下模板：
-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年1月16日 (二) 13:23 (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年4月6日 (六) 08:29 (UTC)更新-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年4月6日 (六) 08:29 (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)[回复]

沒有異議，就是不知道會不會出現突發狀況。 --窝法乙烷 儿法梦碎 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)[回复]
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

分類改名準備

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

雖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)[回复]

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

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

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

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

可能我上面没说清楚，让你以为我是反对分类改名的，更不是什么越给我搞复杂，好啊WP:QUALITY永远升不了指引都你害的，不能有问题不让说是不是。总之是以下几点：
  1. 页面重新命名为Wikipedia:条目质量评级标准：因为评级针对的是WP:条目，其它模板级、分类级这些评级都是非标准级别（WP:QUALITY就是这么写的），那么页面应当以标准评级针对的对象命名，也就是条目质量评级标准。除非你打算搞什么甲级模板级，那不是更复杂。此外还存在Wikipedia:条目重要度评级标准，那是否要改成Wikipedia:页面重要度评级标准，总之得有一个要改
  2. 目前Wikipedia:条目重要度评级标准和Wikipedia:页面质量评级标准是正交的，所以有Category:分类级低重要度宗教条目这种东西的存在，那是不是得命名成Category:分类级低重要度宗教页面。既然分类级不属于标准评级，因此也不必设置重要度，引入更多复杂性，这类页面统统扔去Category:不适用重要度条目去（或者说Category:不适用重要度页面）。
  3. {{Grading scheme}}修改，因为Wikipedia:页面质量评级标准调用了，这个就是作为WP:指引用词统一的问题
--Kunjinkao（留言） 2024年3月8日 (五) 05:20 (UTC)[回复]
  1. 無論是前次討論還是本次討論，都沒有提到重要度，因此認為重要度的那個論述怎麼樣，並不礙於WP:QUALITY升為指引一事。
  2. 此修改技術成本過大，且認為這樣修改與否並不礙於WP:QUALITY升為指引一事。由於目前架構問題，該修改技術上的複雜性，不建議做此修改。除非有人能提出具體的patch ，否則我不支持也不相信此修改能夠被實際執行。（當然，如果有人做patch 就另當別論）-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月8日 (五) 06:05 (UTC)[回复]
  3. 如果沒有人有異議，你可以自行修改。
-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 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)[回复]

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

已完成當時的共識Wikipedia_talk:页面质量评级标准#總結「將不是條目命名空間的評級分類從XX級條目改為XX級頁面」，因此將安排Wikipedia_talk:页面质量评级标准#WP:QUALITY_升為指引重新公示。重Ping當時參與討論的人：@Liaon98、JyunWaan、Lssrn：@Cdip150、Temp3600、Peacearth：。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月19日 (二) 10:49 (UTC)[回复]
  • 当时的讨论是专题各自评级，而现在的情况是多了通用评级（WPBS）。所以时过境迁，WP:QUALITY要重新讨论了。我之前没有参与讨论，现在有不少想法：
  1. WPBS评级是专题评级的容器，还是一套有自己标准的独立评级？现行做法属于前者：WPBS评级继承专题的评级，且受各专题各方面的干涉，因此评级原则看似「随意」。

    一篇列表WPBS获评List级而非CL级，是因为它确实没到CL级。另一篇列表获评List级而非CL级，只是因为某个参评专题不设CL级。第三篇列表和第二篇品质相似却成功获评CL级，原因竟是不设CL级的专题没有「染指」该列表。

    所以我的看法是，通用评级就该如WPBS模板所言，确实地「依照頁面品質評定標準」来独立评定，而不是在各专题评级间谋求公约数。可以参考专题评级，但把专题评级当爸爸就不对了😂
  2. 承上，如果我们确定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级；所以，把这个只有理论价值的等级从通用评级中灭了挺好。
    • 上面的想法也会影响小工具的设定：包括对标准评级的契合，对各专题自定等级的支援，对非条目评级的简化（非条目空间一般人手评级无效）。
  3. 下文有提到「消歧义级条目/页面」。如果按照命名空间来理解，那就有一个问题：重定向在各个空间都有，那到底是叫「重定向级条目」还是「重定向级页面」？（或者两个都要，但这徒增烦恼）另一方面从实用性上看，专题统计「条目数」都是排除Disambig级的，那消歧义占据条目空间就成了bug而非feature。这次从「条目」移到「页面」更像是正名，但是后缀分家无论是技术实现上还是命名统一性上，带来的麻烦都不少。考虑将后缀统一为「页」，比如品质评级这边的「乙级条目页」「丙级列表页」「模板页」，重要度那边也可以叫「高重要度页」「未知重要度页」，这样观后缀就知道是页面评级体系在整活。
我明白很多内容都不在讨论范围内，但我认为之前讨论本身就是系統性不足。比如把非條目品質評級改爲「XX級頁面」，那爲何條目品質評級和非條目重要度分類不動？是改條目和重要度分類真的弊大於利，還是單純沒有討論過而已？作爲這套系統創始者，英文版的非條目還用articles的，個中原因是否值得參考？--For Each element In group Next（留言） 2024年3月19日 (二) 16:05 (UTC)[回复]
爭議已消失：
上述爭議因進一步討論已展開，因此可以視為爭議已消失-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年6月1日 (六) 10:55 (UTC)[回复]
下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。
@For Each element In group Next：老實說我真的不懂你們這些這時候再來提意見是用什麼心態再看事情的，這個提案已經放超過三個月了，又不是放一個星期就說要公示，硬是等提案要準備收尾才來提意見是怎麼回事？！我可以當成你是打算擾亂干擾提案通過嗎？！--SunAfterRain 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)[回复]
@For Each element In group Next：我不管你到底對這個議題有沒有興趣，反正你現在的意思是上方內容純粹是發牢騷你沒有要干擾這個提案？！--SunAfterRain 2024年3月20日 (三) 17:12 (UTC)[回复]
還沒有細看，但我對洛普利寧君遭到這樣的對待感到很悲哀。--Temp3600（留言） 2024年3月20日 (三) 17:43 (UTC)[回复]
在有用的討論串下面離題吵架實在無奈，但似乎VP環境已經如此。
WP:CON明確指出"共识应采纳多数人的意见，并和重要少数的意见作出适当妥协。"、"共识在维基百科是持续不断的过程"，對於方针修改，更再次明示"共识最终将根据支持和反对该议题的论点质量所决定"。方針中沒有任何字眼要求討論應"收尾"，反而暗示了討論本身是可以無限延長，以不斷修改共識更貼合實況的。所謂擾亂更是莫名其妙。
回到討論本身，如果有足以反駁洛普利寧君的理據，直接提出來就可以。如果反駁不了，甚至根本沒有考慮到這一討論角度，那顯然就說明"之前讨论本身就是系統性不足"，提案一方存有思考盲點，應該進一步討論下去。
回到這個提案。我與八年前一樣，支持將WP:ASSESS建立為指引。然而，洛普利寧的問題必須先得到回答:维基百科:通用評級與维基百科:页面质量评级标准之間有潛在矛盾。通用評級到底是獨立的評級系統，還是專題評級的平均分?我對這兩者沒有特別的見解，但WP:ASSESS應該清楚指明這一上下級關係。
如果不幸某頁面只有一個專題，而這個專題將頁面評為"未來級"等奇怪級別，通用評級是否跟隨?
請賜教。--Temp3600（留言） 2024年3月21日 (四) 19:45 (UTC)[回复]
@Temp3600：那我倒覺得您來主持好了，包含修改模板模組的部分，反正您看起來很閒可以泡在客棧陪大家一直耗。--SunAfterRain 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這種隨手改一改就好的是吧，改一次的成本有多高您可以自己改看看，不是什麼看起來很簡單改一改就好--SunAfterRain 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)[回复]
      別為你不參與討論找藉口，電波對不上不代表就可以事後再來批判，你說以理服人光是你用這個理由我就覺得你服不了人了
      另外你覺得你的意見不是技術問題但事實就是改動不小的技術問題，光是要改動一個分類就要牽涉到多少模板模組了--SunAfterRain 2024年3月23日 (六) 05:49 (UTC)[回复]
      您的考虑方向我很赞同。不过如果例子举成「改动一个模板就会牵涉多少分类的移动」，那会更有说服力 --For Each element In group Next（留言） 2024年3月23日 (六) 06:58 (UTC)[回复]
      你到底在舉什麼...--SunAfterRain 2024年3月23日 (六) 07:28 (UTC)[回复]
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。
  • 首先感謝宇凡君的努力，您辛苦了。順便說一點離題得罪人的話：
标题

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

  • 目前的問題如要解決，通用評級指引勢必重寫。問題只是要怎樣重寫而已。說白了，洛普利寧是反對通用評級的“由下而上”邏輯，再深挖下去，涉及專題組與社群整體之間的互動問題，對應現實生活中的中央－地方政府間，集權－分權的沖突。這樣展開就顯然太複雜了，我只是希望指出為什麼洛普利寧會認為這個指引寫得不好。
    回到維基。儘管從憲法的觀點出發，確立各子組織間的權力分立應是建立規則的第一步，但考慮到中文維基並不怎麼關注這一問題，我就建議維持現狀好了，省得麻煩。反正即使是下而上，要修改專題評級，直接一起修改所有專題的評級就可以（顯然這就一次侵犯了數個專題的自主權，但上面說了，中維人這方面的理解力有限）。下而上的（理論上）優勢當然是“各專題組可以按各自所擅長的領域，共同對跨領域的條目進行評級，會比WPBS只用一個評級員來得準確”。實際上嘛，就是懶得改。
    “WPBS评级人是作为什么身份评的”：從下而上的觀點而言，沒有專題組的條目評級，算是社群託管了該條目，留待專題組前來接收，等價於聯合國託管理事會。最終還是需要專題組的專家前來正式評級。
    "标准评级":基於減少修改範圍（懶）的因素，建議只容許使用“标准级别”來評級。也就是說，暫時放棄將BL／CL加入WPBS，待更多專題啟用這些評級，更為人所熟悉後，再來討論。future等評級則不容許更新到WPBS上去，機械人應視這些條目為“沒有評級”，由人類前來處理。
    最後，感謝@For Each element In group Next：前來，指出這些要點供大家討論。說實話我本來也不想發言的，打了這些東西花了我一個多小時。也希望你能與我一起堅持到這項修改完結。
    以上。--Temp3600（留言） 2024年3月23日 (六) 03:33 (UTC)[回复]
    如果硬要扯開這個話題，我反倒支持廢掉所有專輯的質量評級全部統一處理，因為你維專題參與人數實在少到除了幾個大專題之外沒有辦法給出一個真的符合自己專題的評級標準，而且去查大專題的評級標準實際上也與通用標準沒有差異，那這樣給各專題評質量有什麼意義？--SunAfterRain 2024年3月23日 (六) 05:54 (UTC)[回复]
    （以上沒有要廢掉重要度評級）--SunAfterRain 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)[回复]
    所以你知道為甚麼我說他明顯有意擾亂了吧（攤手--SunAfterRain 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：這完全不是什麼兩種不同工作的問題，有意見之前重寫模組時一起納入考量重寫就好，那時候提出我想娜娜奇也會盡可能配合的，但洛普利寧同學是喔我支持改寫，人家寫完都開始運行了再來抱怨。不要跟我說什麼滾動式修正，他提出的意見很顯然不是因為模組上線才出現的。--SunAfterRain 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列在非标准等级下，并且写有“部分專題還會啟用附加等級。”看上去挺一致的欸。--MilkyDefer 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)[回复]
      您说的也是可行方案。目前启用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)[回复]

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)[回复]
  • （有感而發）除了本子節開始的爭議外，以上討論與研究其實都滿有意義和價值的，如果能提前在去年十二月，也就是我當初Ping了洛普利寧時，他就發表了這些意見，並開展了我們現在所討論的東西，那我覺得WPBS應該會更完美。不過現在說這些都是後話了。另，跟大家說聲抱歉，我當時一心只想著如何把MilkyDefer起草的臨時方案開發成正式方案、如何pass所有testcases 和解決討論頁上各種問題回報（1、2等），一切考量都以技術為優先（我當時優先級最高的考量是：程式怎麼寫更省效能，於是出現了mw.loadData("Module:PJBSClass/page")用於讓該功能在整個頁面解析的過程只會跑一次，而不會每次調用通用評級時都跑以節省效能），卻忽略了行政上的執行問題，而導致了今次的爭議，我感到十分抱歉。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月27日 (三) 01:30 (UTC)[回复]

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

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

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

WPBS級別列表

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

能夠由{{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)[回复]

等級標準小結

洛普利寧在上文提到的「PJBS之PJBSClass.getClassByPage()」自動評級（小勘誤：自動評級實由PJBSClass/main.getClassAuto()和PJBSClass.getAutoClass()共同完成，前者以頁面狀態和掛有模板判斷、後者只看Namespace），這些評級會根據頁面掛的模板、子頁面名稱、頁面狀況和所在命名空間等進行自動評級。這些評級分為兩類：不可被|class=參數複寫的評級以級可被|class=參數複寫的評級。
這些級別有：
  • 不可被|class=參數複寫的評級：重定向级 重定向级、特色图片级 特色图片级（註：|class=有值時會強制被改為File級）、模板级 模板级、模块级 模块级、分类级 分类级、文件级 文件级、草稿级 草稿级、主题级 主题级、专题级 专题级、用户级 用户级、使用说明级 使用说明级、使用说明级 界面级、非条目级 非条目级
  • 可被|class=參數複寫的評級：典范级 典范级、特色列表级 特色列表级、优良级 优良级、小作品级 小作品级、沙盒级 沙盒级、列表级 列表级、同类索引级 同类索引级、消歧义级 消歧义级
上文提到，目前不在WP:QUALITY中的級別都需要補上文檔，因此我起了以下草稿供參考：
（註：如果有需要修改可以直接編輯本表格，無須經過我的同意(不被視為修改他人留言)）
（註2：下表只列出目前未出現於WP:QUALITY的級別）
（註3：由於表格過長，已折疊。請單擊[顯示]以展開表格）
預計種類分成三類：標準級別（描述條目品質）、標準類別（描述頁面種類）、非標準級別（專題自定的東西）
@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)[回复]

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

    • 非常感謝娜娜奇。但我因為現實原因(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)[回复]

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

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

整理目前的討論，建議"機器人會根據該頁面最多專題評等的評級等級作為通用評級"繼續保留，但機械人應檢查這會否導致WPBS被評為非正式級別，如發生這種情況，那麼機械人則跳過該條目(可以考慮加入"需要手動進行WPBS評級"的分類)，留待人類前來。
同意"社群和专题都可以各自独立地对页面评级"的基本策略。這樣就解決了list級的問題。即使專題的評級只有list級，WPBS仍可以手動評為更準確的CL/BL等細分級別。由機械人自動評的list級也與這個邏輯沒有沖突。
長遠的最終方向是，WPBS作為條目的內容評級，專題評級則為某一方面提供額外的資訊，類似tag.但這個需要將目前的評級邏輯反過來，我猜一兩年也無法完成，就寫在這而已。--Temp3600（留言） 2024年5月5日 (日) 08:10 (UTC)[回复]

修訂案

维基百科:通用評級
  • 解決「通用评级」与「专题评级」的关系。斷開兩者的上下級關係。
  • 通用評級只限填寫標準評級。
  • 介紹一些其他功能，例如專題可以自行加入評級，不過這些不屬於WPBS的範圍，將它們指示到其他頁面去。
维基百科:页面质量评级标准
  • 對應通用評級的改動，明確兩者間的關係。即: QUALITY負責規定那些級別屬於標準評級，及提供評級的參考。也提供其他非標準級別的介紹。通用評級指引則負責通用評級的流程，由社群負責，為條目的質量提供評級，而專題級模版級等請不要來找WPBS.
  • 結構調整，將「标准质量评级」與「標準類別級別」分立為兩個三級標題。
T: Grading scheme
  • 為所有標準類別補上例子。

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

Unblock-zh.org

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)[回复]
我最期待的畫面出現了。--AT 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)[回复]
@Bluedeck：話說可給管理員布告板抄送一份通知連結至此？—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月1日 (六) 08:43 (UTC)[回复]
@Bluedeck：想好奇請問是否有考慮過部屬在wikitech:Help:Cloud VPS？如果有，為什麼不選擇部屬在該處？--SunAfterRain 2024年6月4日 (二) 09:30 (UTC)[回复]
管理员通告版：不知道效果会怎么样啊。等上线后在ASN通告一下，然后TG呀IRC呀广播一下应该就行。CloudVPS：他的介绍说自己是标准的VPS，但是又有迹象表明他不是完全标准的环境，导致我不想把时间花在部署，测试，更换环境，以及踩坑上面。对我来说，写软件是趣味十足的事情，而调试环境则是让我胃肠不适的事情。目前我没有换环境的需求，因为开销太小。如果有我再考虑cloudvps。cloudvps的另一个问题是只有在virginia有DC，但这不是一个大问题。Bluedeck 2024年6月8日 (六) 04:00 (UTC)[回复]
以我個人看法，部屬在CloudVPS的隱私疑慮絕對會比一個外部網站好很多，當然你維社群願意接受那我也沒什麼意見就是了。雖然不清楚是筆誤還是什麼的，如果開銷太小的話我自己是會考慮換過去啦。--SunAfterRain 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)[回复]

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

  1. 工单是否永久保存？永久保存是目前的默认，而且邮件列表也是永久保存的。但是我觉得比如挂上“处理结束”标记90/180天之后永久删除相关信息这个是更安全的做法，想征求一下大家的意见。
  2. 开源：从一开始我就设想开源。这个项目有4个repo，其中3个可以在最近开源。一个需要我检查一下有没有API Key之类的物品遗落在代码中，然后才能开源。请期待。
  3. 共同参与：如果您想共同参与开发，或者参与对服务器的运维，欢迎在这里提出来。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)[回复]
@LuciferianThomas：我正在编写为IPBE权限持有者提供权限的功能。完成后，IPBE将获得和管理员基本一致的功能。目前编写的功能是对于下方讨论中方案一的实现。编写完成后，我将会在用户讨论页面通知IPBEG权限持有者。Bluedeck 2024年7月10日 (三) 18:46 (UTC)[回复]
@Bluedeck：能更新進度嗎？--路西法人 2024年7月22日 (一) 02:49 (UTC)[回复]
@Bluedeck：預計試行多久？—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月20日 (六) 17:44 (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啦，不過要擔心被亂改的問題。--SunAfterRain 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 能够一起帮助处理会大有裨益。现在抛出几个方案讨论：

  1. 让IPBEG组和管理员同在unblock-zh.org/zhwp下有一样的（或者接近的）权限。
  2. 像邮件列表一样，单独新建 unblock-zh.org/zhwp-ipbe空间。
    1. 网站面向用户的界面不改变，根据用户是否需要 IPBE，自动将工单分发至 zhwp 或 zhwp-ipbe
    2. 网站设计改变，入口页面一分为二，用户需要自己选择是投递给zhwp还是zhwp-ipbe
  3. 不支持 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)[回复]
@Bluedeck：只要不僭越社群賦予之權限，應儘可能以您自身方便為宜。—— 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)[回复]
這反對理由太怪了，你維本來就被GFW刀了，有差嗎？--SunAfterRain 2024年7月27日 (六) 04:23 (UTC)[回复]

新用户通过撰写新条目的方式“完成学科作业”的处理讨论

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:教育專案佈告板、Wikipedia talk:教育專案、Wikipedia talk:给老师们的提示。

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

近日巡查当中发现疑似存在新用户通过撰写新条目的方式“完成学科作业”，目前主要涉及两位用户U:JINJINYAN和U:ZixuanHE以及其创建的四篇条目，见人权史（Draft:人权史）、中朝关系史（Draft:中朝关系史）、Draft:修理权、Draft:性别薪酬差距（目前的处理为：已全部转移至草稿空间，部分被绕过草稿空间重新发布的条目已提报存废讨论）。四篇条目均为机翻或者潦草翻译，且未进行维基化。据ZixuanHE所述，这些条目的创建疑似为“学科作业”，且必须发布才有可能拿到“节课的成绩”（见UT:ZixuanHE#阁下所创建条目已被移动至草稿）。

鉴于此类行为为显然带有倾向性或非百科编辑性动机的条目创建行为（可能不符合但类似于维基百科:有偿编辑方针），故提出此话题以寻求如何处理该类问题。--Sinet（讨论） 2024年6月14日 (五) 08:43 (UTC)[回复]

在下认为，无论以何种理由对中维条目进行编辑，都必须依照维基百科的方针和标准进行。完成学科作业并不是提交质量不佳的条目的理由。Sinet君将条目暂移至草稿空间以便于编者继续编辑的做法得体适当。--SheltonMartin留言|签名 2024年6月14日 (五) 08:49 (UTC)[回复]
看兩人的對話確實像是要完成作業。但我記得本來就會有一些計劃是讓學生練習寫條目的？--Rice King 信箱 · 留名．邊緣人 2024年6月14日 (五) 09:30 (UTC)[回复]
enwp那边有类似的教学/课堂行为，参考那边的处理方式？--Leiem（留言·签名·维基调查） 2024年6月14日 (五) 09:31 (UTC)[回复]
en:Wikipedia:Wiki_Ed/Massachusetts_Institute_of_Technology/Organometallics_(Spring_2024) ← 找到了这个。--Leiem（留言·签名·维基调查） 2024年6月15日 (六) 08:34 (UTC)[回复]
中文維基有Wikipedia:给老师们的提示，另外，台灣維基人在推的教育專案（Wikipedia:臺灣教育專案），是讓作業放在教育專案以下的空間（如Wikipedia:臺灣教育專案/臺大物理系服務學習二_(107-1)/物理學家），該計劃有維基人在該空間進行評分，符合維基百科標準的再移動到正式條目空間。以我的印象，中文維基百科的人力不太夠幫助老師修正（或評改）同學的作業， 而新手若沒有人協助的話， 也不太可能在短期（例如一週）產出符合維基百科規定， 不會被提刪的條目。--Wolfch (留言) 2024年6月14日 (五) 09:48 (UTC)[回复]
此為韓國漢陽大學的教育專案，而教育專案顯非「有償編輯」。如果條目存在機械翻譯等問題，移至草稿即可。另外，本站或許應建立專門討論教育專案的佈告板，如英文維基的 en:Wikipedia:Education noticeboard？謝謝。cc @Hanyangprofessor2：--SCP-0000（留言） 2024年6月14日 (五) 13:20 (UTC)[回复]
我好像听过这个事情，这位教授好像在我的讨论页面中提到过这个项目。--MilkyDefer 2024年6月14日 (五) 15:35 (UTC)[回复]
Yes, they are my students. They are Chinese nationals and supposedly fluent in Chinese (I do not speak Chinese, apologies). They are required to proofread their works so that it reads well in Chinese (instructions are at en:User:Piotrus/Ideas for students; I explicitly ask them to read 维基百科:翻譯指引). They are also encouraged to ask for feedback at Chinese Discord or at 维基百科:同行评审. I am afraid some some students may not follow the instructions (yes, I am sure you are all shocked), for which I can only apologize, and some try to finish the Wikipedia-writing assignment (which is supposed to take ~3 months) in less time (say, a week or two before the class is supposed to be finished...). On the other hand, I'll also note that we should not assume that all poor translation is the result on reliance on machine translation - some people (students) may not know how to write properly, and the errors may be of their own making, rather than the fault of the translation software (just a thought). To end, I'll repeat the idea I mentioned few months ago here (at Chinese Wikipedia) - to create a Chinese equivalent of the en:Wikipedia:Education noticeboard mentioned above, as well as a dedicated space for students to list their works and ask for a review (so that their assignments do not flood the 维基百科:同行评审). PS. If anyone feels like this, one of my students got blocked again and their case could use a review, once they apply for an unblock, as I told them to (of course, I expect them to read and understand the reasons for their block...). User:Liangyiqiao2004
是的，他們是我的學生。他們是中國公民，據說中文很流利（我不會說中文，抱歉）。他們需要校對自己的作品，以便其中文可讀性良好（學生的說明位於：en:User:Piotrus/Ideas；我明確要求他們閱讀維基百科：翻譯指引）。我們也鼓勵他們在 Chinese Discord 或維基百科：同行評審中尋求回饋。我擔心有些學生可能不遵循指示（是的，我相信你們都感到震驚），對此我只能表示歉意，還有一些學生嘗試完成維基百科寫作作業（預計需要大約 3 個月的時間）在更短的時間內（例如，在課程結束前一兩週…）。另一方面，我還要指出，我們不應該假設所有糟糕的翻譯都是依賴機器翻譯的結果 - 有些人（學生）可能不知道如何正確書寫，並且錯誤可能是他們自己造成的，而不是翻譯軟體的錯（只是一個想法）。最後，我將重複幾個月前在這裡（中文維基百科）提到的想法——創建一個相當於上面提到的en:Wikipedia:Education 佈告欄的中文版本，以及一個專門的空間，供學生列出他們的作品和要求審查（這樣他們的作業就不會淹沒維基百科：同行評審）。附言。如果有人有這樣的感覺，我的一個學生再次被屏蔽，一旦他們申請解鎖，他們的案件就可以進行審查，正如我告訴他們的那樣（當然，我希望他們閱讀並理解屏蔽的原因。 ..) 。使用者：Liangyiqiao2004--Hanyangprofessor2（留言） 2024年6月17日 (一) 10:00 (UTC)[回复]
@Hanyangprofessor2：I'm afraid that the block would stay on for a while for Liangyiqiao until he/she/they answers the question from local admin @Tigerzeng： on the user talk page. I understand that there might be deadlines for students to reach, but if Liangyiqiao is not able to answer the question that Tigerzeng presents, it would be hard to convince the admins (I supposed that is at least Tigerzeng and myself) that he/she/they understands the reason for the block.
恐怕Liangyiqiao的封鎖將會持續一段時間，直到他在用戶討論頁上回答Tigerzeng的問題。我理解學生很有可能有繳交作品的截止日期需要達成，但如果Liangyiqiao無法回答Tigerzeng提出的問題，這將會很難讓管理員（我想至少是Tigerzeng和我自己）相信他自己已經了解了封鎖的原因。
註：原文是以英文寫出後再翻譯，若有不同之處請以英文為準。--（☎）dt 2024年6月21日 (五) 02:00 (UTC)[回复]
@ATannedBurger Of course, I understand. It is the student's responsibility to monitor messages and answer them in a timely manner. 当然，我明白。查看信息并及时回复是学生的责任。--Hanyangprofessor2（留言） 2024年6月22日 (六) 03:57 (UTC)[回复]
又有一個。--Rice King 信箱 · 留名．邊緣人 2024年6月15日 (六) 07:26 (UTC)[回复]
英维也有这种，主框架是Wikipedia:教育專案，具体课程例子比如 https://en.wikipedia.org/wiki/Wikipedia:Wiki_Ed/University_of_Southern_California_Viterbi_School_of_Engineering/WRIT_340_for_Engineers_-_Spring_2024_(Spring_2024) ，这种页面注明了哪个大学，哪个课程，哪个学期，哪个讲师，并有维基编辑审核。但中文维基只有这个“教育專案”的主页面，实际页面内没有规范。--桃花影落飞神剑（留言） 2024年6月15日 (六) 15:02 (UTC)[回复]
社群可以趁此機會完善相關的頁面與規定，就我的觀察教育專案在中維的需求不算低，但也沒有到頻繁。--~~Sid~~ 2024年6月17日 (一) 09:29 (UTC)[回复]
(＋)支持，可以对en:Wikipedia:Education进行引入或者设计其他暂行方针以标准化相关内容的处理。--Sinet（讨论） 2024年6月17日 (一) 12:52 (UTC)[回复]
(＋)支持，同上--HYHJKJYUJYTTY（留言） 2024年6月21日 (五) 07:40 (UTC)[回复]
(＋)支持--Rice King 信箱 · 留名．邊緣人 2024年6月22日 (六) 04:27 (UTC)[回复]
@SCP-2000 @ATannedBurger @Flyinet Hello. Can you tell me why majority of my students contribution was removed from those two articles? 性别薪酬差距 and 修理权 . I am afraid I cannot understand the problem from edit summar or article's history, they look mostly fine to me? If there is a problem, I can tell the student to fix it in the near future, but I need to know what the problem is first. (Content was removed by @日期20220626)
你好。你能告诉我为什么我学生的大部分贡献被从这两篇文章中删除吗？ 性别薪酬差距和修理权 。恐怕我无法从编辑摘要或文章历史中了解问题所在，它们对我来说大部分都很好？如果有问题，我可以告诉学生在不久的将来修复它，但我需要先知道问题是什么。（内容被@日期20220626删除）--Hanyangprofessor2（留言） 2024年6月22日 (六) 08:28 (UTC)[回复]
There are comments about these two articles on User talk:JINJINYAN from user:ZixuanHE "However, the structure of some of your sentences is relatively complex, which affects the reading fluency".--Wolfch (留言) 2024年6月22日 (六) 08:52 (UTC)[回复]
@Hanyangprofessor2: Hello, if I understand correctly, 日期20220626 shortened articles and removed content with poor translation quality (i.e. translated by machine translation) and lack of Wikify, so that they can be published in the main namespace.
Students can write in the draft namespace and submit it for AFC review (by adding code {{subst:submit}} on the top of the page). Thanks.--SCP-0000（留言） 2024年6月22日 (六) 09:08 (UTC)[回复]
Hi, I am the patroller who reviewed the articles created by your two students. Overall, the reasons for the articles being disqualified can be summarized into three categories:
  1. The most severe and obvious reason is the massive presence of machine translation appearance throughout the articles. There are numerous noticeable signs of machine translation, including but not limited to: evident translation tone, incorrect Chinese proper nouns, and English-style sentence structures. These issues are easily detectable to native Chinese readers, leading to the articles being directly judged as unqualified.
  2. The articles lack proper "Wikification." They consist mainly of plain text and line breaks, without using any syntax to design headings or organize the article structure, resulting in poor readability. Additionally, some terminologies lack internal links or have incorrect links. These are obvious mistakes, making the articles clearly fail to meet Wikipedia's inclusion standards.
  3. The articles are primarily composed of assertive sentences without any connectors or transitional paragraphs. This results in a lack of coherence and logical flow, making the articles very difficult to read.
--Sinet（讨论） 2024年6月22日 (六) 09:27 (UTC)[回复]
@Flyinet @SCP-2000 @Wolfch Thank you for the explanation. I will ask the student @JINJINYAN to address those problems. 谢谢你的解释。我会请同学@JINJINYAN 解决这些问题。--Hanyangprofessor2（留言） 2024年6月23日 (日) 03:32 (UTC)[回复]

設立教育佈告板

根據上方的討論共識，已設立教育佈告板的草案，歡迎各位前來討論。--人间百态,独尊变态(讨论) 2024年6月22日 (六) 11:06 (UTC)[回复]

Ping一下相關用戶@Flyinet、SheltonMartin、RiceKing、Leiem、SCP-2000、MilkyDefer、Hanyangprofessor2、ATannedBurger、桃花影落飞神剑、ASid、HYHJKJYUJYTTY：--人间百态,独尊变态(讨论) 2024年6月22日 (六) 11:12 (UTC)[回复]

你設計還不錯--HYHJKJYUJYTTY（留言） 2024年6月22日 (六) 11:17 (UTC)[回复]
據我所知，目前有教育專案，都是在互助客棧其他區通報。至於是否需要獨立的教育專案布告板，則尚待商榷。但無論具體地點如何，總是應鼓勵教育專案主持人通報，俾利於社群覆核。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月23日 (日) 02:20 (UTC)[回复]
「教育」佈告板此稱呼較含糊，或許改為「教育專案」佈告板？謝謝。--SCP-0000（留言） 2024年6月23日 (日) 15:52 (UTC)[回复]
完成--人间百态,独尊变态(讨论) 2024年6月24日 (一) 13:29 (UTC)[回复]
教育專案佈告板看起來不錯。--冥王歐西里斯（留言） 2024年6月27日 (四) 01:33 (UTC)[回复]
我觉得这个设计的不错，支持。--桐生ここ★[讨论] 2024年6月25日 (二) 16:21 (UTC)[回复]
在看草案之前我以为是用来通报/报备教学计划的布告板，但起来好像不是这个用途。
  • “参与教育专案的学生的条目作业已产生或可能产生的问题”是不是在条目讨论页或用户讨论页讨论相关问题会比较直接？除此之外还有互助客栈的条目讨论版。
  • “教育专案运行中产生的问题”需要为这些问题设立布告板吗？相关问题的讨论频率似乎不多，是否可以继续在互助客栈讨论？
  • “关于维基教育基金会的讨论”个人对这个基金会了解不多，其曾经在中文维基百科举办过什么活动吗？
--Steven Sun（留言） 2024年7月2日 (二) 02:11 (UTC)[回复]
@人间百态：感覺通報教育專案也可以納入範圍。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月2日 (二) 04:24 (UTC)[回复]
不反對。--冥王歐西里斯（留言） 2024年7月2日 (二) 04:44 (UTC)[回复]
建议加入一个列表备案当前进行中的教育项目，并要求教育项目的主管者填报，备案信息可包括：
  • 项目名称（相关机构名称）
  • 教育项目编写的条目性质（翻译或原创）
  • 教育项目的主管者用户ID以及其他监管者ID
  • 教育项目的参与者ID
  • 教育项目内正在编写的条目列表
方便巡查员和社群了解正在进行的项目信息。--Sinet（讨论） 2024年7月2日 (二) 15:26 (UTC)[回复]
@Flyinet，已完成。--人间百态,独尊变态(讨论) 2024年7月3日 (三) 14:20 (UTC)[回复]
已將通报教育项目納入範圍，順便回復一下Steven Sun君的疑問。我對教育專案佈告板設計的定位和英維是大致相同的，即集中處理維基教育專案的老師和學生在編寫維基百科時可能產生的問題。条目讨论页、用户讨论页、互助客栈，這些地方確實比佈告板直接不少，但這些頁面比起佈告板來或曝光度不足，或查閲困難。佈告板設立後能夠讓社群更加有效的處理相關問題，并提供存檔供用戶查閲如何處理相關話題。--人间百态,独尊变态(讨论) 2024年7月2日 (二) 13:57 (UTC)[回复]
又想了一下，教育项目运行中产生的问题的討論頻率確實不是很大，就算出現大部分也是有關學生的作業質量問題。故此已將学生的作业质量问题一項并入教育项目运行中产生的问题之中。--人间百态,独尊变态(讨论) 2024年7月2日 (二) 14:10 (UTC)[回复]
  • 我想請問這個佈告欄未來如何運作？目前看不出來有任何方法可以使想發起作業的老師能提前知道要來通報，而且如果要用維基介面寫通報，大概使用率會很低；社群依然會一天到晚先被作業洗，然後才通知老師去登記，完全沒有發揮預警效果。如果是合作社群要去登記……目前大宗會有合作案的就台灣社群，但我們已經有教育專案頁面了。--Reke（留言） 2024年7月6日 (六) 15:02 (UTC)[回复]
    interesting的問題。不知道Reke君有沒有關注過近來英維的教育佈告板的討論記録，在近幾年中也幾乎沒有人用該佈告板來提報項目。一來英維老師通常會使用Wiki ED進行課程，二來在英維老師也是不太管注教育佈告板的。實際上這個佈告板本來就不是為了“預警效果”而設計的，其目的正如上方的回復所說為了讓社群“集中处理维基教育项目的老师和学生在编写维基百科时可能产生的问题”。佈告板的確無法改變社群始終慢一步的事實，但它能在事情發生後讓社群更加直接的處理相關問題並通知有關用戶。--人间百态,独尊变态(讨论) 2024年7月7日 (日) 03:30 (UTC)[回复]
    感謝，我是看上方討論都要把通報列入當中，而且目前板面說明中也容許提報教育專案，所以才這樣問的。
    如果單就集中處理問題來講，我建議不如在互助客棧開設一個「/教育專案」的分頁面？這樣子看互助客棧的其他版面時，也就可以順便去關切一下。--Reke（留言） 2024年7月9日 (二) 04:14 (UTC)[回复]
    我個人是傾向不要再開客棧的子頁面啦，況且看客棧的特定子頁面的時候也未必會去看其他子頁面就是了。--冥王歐西里斯（留言） 2024年7月9日 (二) 05:20 (UTC)[回复]
    同意，挺不错的设计。--SheltonMartin留言|签名 2024年7月11日 (四) 06:38 (UTC)[回复]

公示7日，2024年7月26日 (五) 13:51 (UTC) 結束：最后一条留言距今已过7日且所有意见已解决，進入公示期。--人间百态,独尊变态(讨论) 2024年7月19日 (五) 13:51 (UTC)[回复]

或许可以考虑m:CampaignEvents？--百無一用是書生 (☎) 2024年7月21日 (日) 06:55 (UTC)[回复]
不反对，不过中维有引入这个插件吗--人间百态,独尊变态(讨论) 2024年7月21日 (日) 07:08 (UTC)[回复]
教育專案不會用。至於如果您是指編輯松，建議另開新討論。謝謝。--SCP-0000（留言） 2024年7月21日 (日) 07:11 (UTC)[回复]
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

討論頁話題自動索引

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:討論頁話題索引。

為配合WP:CON/TRIAL鼓勵用戶多善用條目討論頁，我嘗試重製了類似過往Shizhao君製作的Talkindexbot（WP:TALKINDEX），自動索引各討論頁的近期話題。目前索引暫時置於本人用戶空間（User:LuciferianThomas/討論頁索引），未來將正式申請機械人任務更新WP:TALKINDEX。若各位對索引測試有任何意見或建議，歡迎在此提出。--路西法人 2024年7月6日 (六) 12:51 (UTC)[回复]

支持這個initiative（雖説這在WP:CON/TRIAL的提議出現前就該出現了）。Sanmosa 蚌埠 2024年7月6日 (六) 13:53 (UTC)[回复]
挺好的，不过我也发现了点问题，但恐怕并不容易修复：
  1. 有些讨论已经结束（比如，编辑请求解决了），却仍会出现在此索引上，导致其十分冗长
  2. 有些讨论发起时间比较早，或讨论较长时间都没有人回应，就不会出现在此索引上；这可能并不利于问题的解决/共识的形成
--古怪的Wang31（讨论 | 贡献） 2024年7月7日 (日) 13:09 (UTC)[回复]
聊勝於無，有問題可以之後慢慢改善。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月7日 (日) 15:35 (UTC)[回复]
  1. 現在仍然在初步測試階段，未來將參考Cewbot，將已經結束（已有Archive框模板）的討論以另一種方式標記；其餘標籤如已解決之編輯請求、移動請求等亦可納入考量。此部分還請社群協助列舉。
  2. 目前機械人設計為每次都搜索最近14天的RC來弄這個列表，未來或許會以暫存方式優化；但起始搜索RC也最多只能到30天，而14天的討論串數量已貼近400大關，可以想像起始數據需要索引蠻久的（以防轟炸資料庫）。不是做不了，但最多也只能做30天，但也還是會多串到用戶難以索引不再有效的地步。另一個方法是恢復{{indiscussion}}模板以防拖延時間過長討論不被索引，這又是另一個需要社群去討論的議題。
--路西法人 2024年7月7日 (日) 15:51 (UTC)[回复]
其实很多讨论就没有结束，或即使结束了也未必有任何标记来表示已结束。我认为话题索引只索引最多30天内有进行讨论的就好了，30天都没人参与的讨论那就是暂时没人在意或没能力参与，或者讨论页的留言就只是对条目内容的一个注记，没有讨论必要。討論頁話題自動索引最大的意义是让人能够了解和检索近期发生在討論頁的所有讨论，以期达到能够有更多人关注参与讨论的目的--百無一用是書生 (☎) 2024年7月8日 (一) 02:45 (UTC)[回复]
目前确实其实是没什么大问题的，我提的只是算是一点细枝末节的问题，得不出结论也无伤大雅。
  1. 讨论结束的，通过一些模板标记可以排除；当然，这对机器人在技术上的设计要求就会比较高。要是总体上没有特别多活跃讨论，直接忽略其实也问题不大
  2. 没解决但没人回复的讨论，确实是个比较矛盾的问题。无限索引就的讨论无论从技术上还是价值上肯定都是不太现实的，还是要考虑是否需要一种“标记”。一方面，就让这些讨论不了了之，感觉也不太好，尤其一些争议要是总是不解决，可能容易产生积患；另一方面，如果真的把所有“未结束”的讨论都列出来，却没人想去讨论，那仍然会让索引变得越来越长，失去意义。（突然想到，这个问题其实也可以类比存废讨论的积压讨论的存在，关键在于讨论的问题到底重不重要）
    我也给个我的建议，可以考虑先恢复{{indiscussion}}（我不清楚模板具体内容，总之是恢复或创建一种标识“此处有讨论正在进行”的模板），试用一段时间，要是积压的讨论越来越多，就还是用按日期索引的方案。
--古怪的Wang31（讨论 | 贡献） 2024年7月9日 (二) 14:37 (UTC)[回复]
當初的刪除理由是「在讨论页开新段落自然是寻求讨论，无必要专门用一模板彰显」。我覺得可以改成預設索引對象包含兩者，一種像現在這樣一定時間內發起討論，另一種就是特別標示有此模板的話題（無論發起多久）。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月17日 (三) 08:02 (UTC)[回复]
正是我上方留言所說的做法。--路西法人 2024年7月17日 (三) 08:41 (UTC)[回复]
有關頁面整體內容過多問題，可以考慮同過往一般，按命名空間拆分子頁面。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月20日 (六) 17:42 (UTC)[回复]
这样算是有点共识了，那要不就弄个模板吧。
要弄的话，我觉得大概可以类似{{rfc}}的样子，但是可以更小（比如只占个角落（像那个存档的框）），并且不需要分那么多类（只需要标记“在讨论”就好）
（当然，我不太会搞……）--古怪的Wang31（讨论 | 贡献） 2024年7月26日 (五) 13:21 (UTC)[回复]
已更新至WP:TALKINDEX。--路西法人 2024年7月17日 (三) 03:12 (UTC)[回复]
我觉得可以加上对话页对应页面的状态，如保护、特色、优良以及页面不存在等--百無一用是書生 (☎) 2024年7月21日 (日) 06:14 (UTC)[回复]
若祇是索引話題，是否有一些多餘？當然，若機器人能做到，那仍可以圖示為附註之類。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月21日 (日) 08:04 (UTC)[回复]
确实很实用。感觉可以考虑下放给各专题。以专题分类索引相关条目的讨论页话题，做成状态通告那样可以自定义的工作流，不知在技术是否会有难度。--PexEric💬|📝 2024年7月22日 (一) 13:43 (UTC)[回复]
如此想必可以进一步盘活讨论页。各专题协作起来也更高效。--PexEric💬|📝 2024年7月22日 (一) 13:45 (UTC)[回复]
GA、FA、FL評選完移至條目討論頁存檔的話題，也會出現在索引頁內，建議索引頁可以排除這些「存檔」性質的話題。--巴波（留言） 2024年7月28日 (日) 22:22 (UTC)[回复]
我早前就加了filter篩除這些存檔話題，如果還有遺漏請將標題添加nowiki標記報告給我，我加到filter上。--路西法人 2024年7月29日 (一) 02:04 (UTC)[回复]

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

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

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

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

這難道不應該直接在傀儡調查頁面處理？—— Eric Liu 創造は生命（留言・留名・學生會） 2024年7月20日 (六) 17:39 (UTC)[回复]
這些Stale了的賬號，即使有可疑，放上SPI也查不了，所以只能放此。--MCC214（Sign | Contributions） 2024年7月21日 (日) 05:32 (UTC)[回复]

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

有沒有「勿添加違法網址」的警示模板？

本主題或以下段落文字，在討論結束後應存檔至Talk:創意私房。

因為又有人在創意私房加入網站網址，雖然網址被台灣政府停止解析，但仍有從其他國家進入的可能，添加網址會違反使用條款。所以我想要不要在條目頂端放個警示模板，但不知道要去哪裡找。--世界解放者（留言） 2024年7月20日 (六) 05:28 (UTC)[回复]

添加网址并不等于ToU中提到的那些。网址本身并非色情内容。——暁月凛奈 (留言) 2024年7月20日 (六) 05:45 (UTC)[回复]
之前User:SCP-2000是用這個理由刪去網址，雖然台灣的法律張貼網址可能不違法，但美國的法律我不清楚。--世界解放者（留言） 2024年7月20日 (六) 07:00 (UTC)[回复]
网址与网站内容是两回事，直接将内容，比如截图甚至视频发布至维基百科显然是违反使用条款的，但网址只是一串字符，和条目标题性质相同。提供链接不等于提供内容，用户自行访问和分享内容不是维基百科的问题。您也可以参考涉及版权纠纷的网站案例。——暁月凛奈 (留言) 2024年7月20日 (六) 09:44 (UTC)[回复]
好像在有些州，僅是觀看也可能觸法。我不認為「和條目標題性質相同」，一般來說連結就是要點開來看的，一個不能點的連結又有什麼添加的必要？而且Google會移除不當的搜尋結果，目前搜尋「創意私房」是找不到網站的。--世界解放者（留言） 2024年7月20日 (六) 12:28 (UTC)[回复]
我在英維搜尋了一下，雖然沒有正式的相關規定，但用戶的共識是不要貼，包括暗網之類的連結。--世界解放者（留言） 2024年7月20日 (六) 12:54 (UTC)[回复]
对一个网站进行介绍而又完全不提及其域名不是很奇怪吗？“連結就是要點開來看的”——若是如此，广告商也没必要费力提高点击率了，很多链接并不会被点击，比如参考来源。对于想要访问的人，即使这里没有也会想方设法寻找域名进而访问。Google不是美国政府，它的展示策略是它自己的设置，搜索引擎也不是只有Google。另外，移除此类网站的链接并不是中英文社群的通行做法，相反，存在Category:被美国封锁的网站、en:Category:Domain name seizures by United States这类分类。对于域名被查封，或是已经关闭的网站而言，提及域名应该是必要的。再者，就该讨论的标题而言，警告式的模板通常仅应用于用户讨论页和编辑提示，而不是放到条目上方。——暁月凛奈 (留言) 2024年7月20日 (六) 13:18 (UTC)[回复]
我的意思是，你用條目標題Google搜尋可能搜不到東西，但可以直接用網址連過去，兩者的意義不同。條目蘿莉塔之城也沒有提供網址，在英維的討論頁編者們是認為不要放連結，也不確定是否會有法律問題。
還有，問題不僅在於「想要訪問的人」，維基已經不止一次因為兒童色情內容惹上麻煩了（見網路觀察基金會與維基百科、en:Reporting of child pornography images on Wikimedia Commons），我可不想看到「驚！維基百科居然可以連到創意私房的網站？」這樣的台灣新聞報導。--世界解放者（留言） 2024年7月20日 (六) 13:37 (UTC)[回复]
我提到用户讨论页和编辑提示，是因为您想达到的目的不是只有在条目中放警告才能实现。在条目上方放警告可能适得其反。en的讨论参与人数并不多，更多的网站介绍仍然包括网址。另外，现在网络已与2008年不同，Wikimedia强制使用https。——暁月凛奈 (留言) 2024年7月20日 (六) 13:51 (UTC)[回复]
這可能屬Wikimedia Foundation Combating Online Child Exploitation Policy的管理範圍。當中清楚表明Sharing links to (or purporting to be to) such material is also in violation of this policy。當然若有關連結及圖片有明確的教育價值除外[該方針原則上禁止在沒有產生教育價值的地方上傳完全纯虛構的兒童色情]。當然創意私房最大問題我反而會說是無差別誘騙強迫偷拍，從某黃姓藝人的收藏中可得知當中不少是成年人的[我不是說那邊涉兒色的沒問題]。--S叔 2024年7月21日 (日) 00:36 (UTC)[回复]
既然基金會有規定，那就好。我來研究編輯提示怎麼弄。--世界解放者（留言） 2024年7月21日 (日) 11:16 (UTC)[回复]
感謝User:Hoben7599建立編輯提示。--世界解放者（留言） 2024年7月21日 (日) 11:27 (UTC)[回复]
@暁月凜奈：雖然張貼連結不等於直接散布兒童色情，但en:PROTECT Act of 2003有禁止「廣告」，張貼連結有可能算是「廣告」。--世界解放者（留言） 2024年7月22日 (一) 01:40 (UTC)[回复]
这讨论主题让人想起处女杀手和网络观察基金会与维基百科，不过在这一案例，基金会维持了有关图片的展示。創意私房可以说在任何主要的司法管辖区都完全不合法，也没有教育意义，链接或许可以基于共识加入过滤器。我觉得无须创建一个单一用途模板，您可以直接手写提醒用户，而在条目挂模板可能会WP:BEAN。--桐生ここ★[讨论] 2024年7月22日 (一) 09:12 (UTC)[回复]
目前添加過連結的編者（包括條目創建者）應該非屬惡意編輯，我有在討論頁提醒但不一定會被看到，所以想說有沒有一定會看到的方法。現在已經用Template:Editnotices/Page/創意私房來提醒。
依據New York v. Ferber禁止真人兒童色情不需要考慮其含有的價值，而創意私房的內容在en:Dost test下應該算是色情，所以不存在豁免的可能性。--世界解放者（留言） 2024年7月22日 (一) 12:13 (UTC)[回复]
明確一點來説，色情[引起性慾的物品，娛樂用]與教育價值應成反比。很難想個例子是同時有效刺激性慾和有教育目的[除了極少數人的性興趣就是學習]，最多分開進行。因此這只是界定何謂色情物品的標準。--S叔 2024年7月22日 (一) 13:18 (UTC)[回复]
有一说一，libgen和Z-Library的链接是不是也是违法网址 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年7月20日 (六) 18:41 (UTC)[回复]
我打「勿添加違法網址」是因為我想可能沒有「勿添加兒童色情網址」這種模板。--世界解放者（留言） 2024年7月21日 (日) 11:21 (UTC)[回复]
建议直接永久保护该条目--Bovemdep（留言） 2024年7月22日 (一) 07:34 (UTC)[回复]
沒有必要，這是因噎廢食。--世界解放者（留言） 2024年7月22日 (一) 12:18 (UTC)[回复]
直接加外部連結黑名單吧（或是更極端點如果基金會明顯會禁止的話問看看要不要加全域黑名單）--SunAfterRain 2024年7月22日 (一) 14:47 (UTC)[回复]
我在几天前给基金会发了邮件，基金会那边还没回复。Python6345（留言） 2024年7月22日 (一) 15:42 (UTC)[回复]
注意有一种处理方法是仅仅描述网址（www.example.com），不作为可以点击的链接（http://example.com）。英文版的例子。--GZWDer（留言） 2024年7月23日 (二) 13:49 (UTC)[回复]
中文维百也有例子--Bovemdep（留言） 2024年7月23日 (二) 15:31 (UTC)[回复]

維基百科iOS應用程式替代文字功能實驗

您好，我是維基媒體基金會負責支援行動應用程式團隊的資深運動通訊專家阿瑪爾·拉馬丹（Amal Ramadan）。

維基百科iOS應用程式伊始乃以閱讀為主要用途。最近兩年間，我們亦加強了應用程式的通訊功能，為此後支援「建議編輯」（Suggested edits）機制打下良好基礎。我們首先設計了替代文字（alternative text，alt text）原型為概念驗證，再引進「圖像建議」（Image Recommendations）功能，為iOS應用程式建議編輯機制的第一波適用對象。我們在下一階段將擴大實驗，推廣替代文字任務。

為何選擇替代文字？目前，維基百科許多條目中的圖像尚未提供替代文字，不利於視覺障礙人士及網路連線品質不佳者瀏覽。替代文字能夠有效描述圖像，增加可存取性，並促進使用者參與。近期研究指出，以iOS應用程式圖像建議功能添加的圖像，只有16%有替代文字，其中品質優良者更是屈指可數。本次實驗希望釐清，為編者指定替代文字任務是否能提升替代文字的數量及品質，並同時確認此種任務是否無論新手或資深編者都能上手。

我們誠摯邀請社群關注本次實驗，並在計畫頁面隨時跟進其進展及成效。本次實驗預定於2024年9月至10月間舉行，其間完成至少一次有效編輯的使用者，將獲得一次提示，學習如何撰寫高品質替代文字；所謂「有效編輯」，指以圖像建議功能添加圖像，或在有缺乏替代文字圖像的條目發布編輯者。在本次短期實驗期間開放編輯次數少於50次者存取iOS應用程式提供的圖像建議功能，以便評估新手在圖像建議及替代文字任務中的表現。

歡迎您在討論頁提供回饋意見或針貶不足之處，幫助我們改善功能。您可在實驗期間登入iOS應用程式，以圖像建議功能發布編輯等，親自嘗試替代文字任務。

不要錯過有關本次重大實驗的更新消息！

--ARamadan-WMF（留言） 2024年7月23日 (二) 12:33 (UTC)[回复]

Rastiniton

本人目前在維基百科:權限申請/申請回退權看見針對Rastiniton的提名，發現他在維基百科上廣受好評（目前已獲自由雨日跟Heihaheihaha的讚不絕口），然而他在回退時總是發出破壞的警告，望有用戶能跟他溝通，改變他說話的語氣（本人溝通沒用）。另外，本人不擅長表達，敬請見諒。--182.234.152.16（留言） 2024年7月27日 (六) 15:36 (UTC)[回复]

所提及用戶目前已擁有回退權限的用戶(回退員)，在反破壞的部分，他的確很活躍，我相信您理性好好的溝通，對方應當不至於給您臉色看。--薏仁將🍀 2024年7月28日 (日) 05:28 (UTC)[回复]
检索自“https://zh.wikipedia.org/w/index.php?title=Wikipedia:互助客栈/其他&oldid=83594863”