跳转到内容

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

本页使用了标题或全文手工转换
维基百科，自由的百科全书

快捷方式

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

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


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


發表前請先搜索存档，參考舊討論中的内容可節省您的時間。
一般
條目與內容
頁面處理
用户行為
其他

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

公告欄
# 💭 話題 💬 👥 🙋 最新發言 🕒 (UTC+8)
1 評級系統缺失問題 232 25 Patrickov 2024-08-06 01:17
2 Unblock-zh.org 82 16 Bluedeck 2024-08-03 04:35
3 討論頁話題自動索引 18 7 LuciferianThomas 2024-07-29 10:04
4 請求社群判斷已經數據過期的用戶是否為傀儡 4 2 MCC214 2024-07-21 13:32
5 Top 10 1 1 Sinsyuan 2024-07-31 23:09
6 林郁婷英文條目的破壞 25 6 甜甜圈真好吃 2024-08-06 17:30
7 仲裁委员会的选举 16 6 Kriz Ju 2024-08-05 21:38
8 爭議領土相關雙重標準問題 5 5 Patrickov 2024-08-06 11:35
9 HYHJKJYUJYTTY的侵权调查已完成 2 1 0xDeadbeef 2024-08-07 18:59
發言更新圖例
  • 最近一小時內
  • 最近一日內
  • 一週內
  • 一個月內
  • 逾一個月
特殊狀態
已移動至其他頁面
或完成討論之議題
手動設定
當列表出現異常時，
請先檢查設定是否有誤

正在廣泛徵求意見的議題

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

維基專題與協作

[编辑]

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

條目主題
非條目主題
提示
要將某一個討論加入上述列表中：
  • 在討論頁中的對應討論章節頂端加上{{rfc|xxx}}標籤，其中「xxx」為分類縮寫。各類分類縮寫已列於上方項目中，並應將其插入{{rfc}}中。多個分類請使用管道符號分開，如{{rfc|xxx|yyy}}，其中「xxx」為第一個分類，「yyy」為第二個分類。
更多資訊請參閱維基百科:徵求意見。請在維基百科討論:徵求意見回報有關錯誤。本列表由LuciferianBot於每個小時進行更新。

評級系統缺失問題

[编辑]

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

（原始標題為「將{{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)[回复]

路過說兩句。條目可以評甲級，前提應該已經是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)[回复]

後續討論

[编辑]

关于 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)[回复]
现在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啦，不過要擔心被亂改的問題。--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)[回复]
这种网站大概率被墙。--mije meli carrot_233 -- 讨论 2024年7月30日 (二) 07:42 (UTC)[回复]
這反對理由太怪了，你維本來就被GFW刀了，有差嗎？--SunAfterRain 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)[回复]

討論頁話題自動索引

[编辑]

本主題全部或部分段落文字，已移動至Wikipedia talk:討論頁話題索引。执行人：Jimmy-bot（留言） 2024年8月8日 (四) 08:14 (UTC)。[回复]

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

[编辑]

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

見相關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)[回复]

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

Top 10

[编辑]

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

我希望這個專案頁面能重新使用，因為目前WP:動態熱門提供每天瀏覽量前48名的條目排行，因此希望「Top 10」可用在月排行榜前10名條目。--Sinsyuan✍️🌏🚀 2024年7月31日 (三) 15:09 (UTC)[回复]

林郁婷英文條目的破壞

[编辑]

本主題或以下段落文字，在討論結束後應存檔至Talk:林郁婷。

en:Lin Yu-ting不斷有人將性別改成男性，現在條目已經受到半保護。話說我看到其中一個破壞者的討論頁被留下了以下文字：「Wikipedia refers to all people, including transgender and nonbinary people, by the pronouns they have most recently requested for themselves」，就我所知林郁婷從未聲稱自己是跨性別或非二元，看了留言的使用者的用戶頁，這是不是摻入個人意識啊……。

總之希望之後編輯相關條目的人，專注在事實上，不要變成反跨與挺跨的戰爭。--世界解放者（留言） 2024年8月1日 (四) 03:20 (UTC)[回复]

這個不得不說漢語好，在近代出現「妳」、「她」兩詞之前根本沒有第二、第三人稱的性別問題。
我主張這種有爭議的地方全部用回「他」，這個詞語只是指被描述者是人，絕對中立--派翠可夫 (留言按此) 2024年8月1日 (四) 15:30 (UTC)[回复]
人家根本不是跨性別者，誤解可大了！—— Eric Liu 創造は生命（留言・留名・學生會） 2024年8月1日 (四) 16:26 (UTC)[回复]
人家首先说的是all people，也就是说顺性别的人，想要他人将TA用什么样的pronoun就应该尊重，也就是说既然林郁婷对外是女性，就不应使用he。这个是在英维的GENDERID下的规定，而这一回退与跨性别显然无关。题主是不是有点太敏感了。--0xDeadbeef (留言) 2024年8月2日 (五) 04:50 (UTC)[回复]
另外，那个留言是uw-pronoun模板的，而不是留言用户自己写的。--0xDeadbeef (留言) 2024年8月2日 (五) 04:52 (UTC)[回复]
不是每個用戶警告破壞者都用這個模板，而且我在en:Talk:Lin Yu-ting留言後，那位用戶好像就沒再用這個警告模板。你現在去網路上繞一下，就可以知道用這個模板對破壞者來說是火上加油。--世界解放者（留言） 2024年8月2日 (五) 05:23 (UTC)[回复]
那最好让这些破坏者尽快自爆以便封禁。--0xDeadbeef (留言) 2024年8月2日 (五) 05:38 (UTC)[回复]
我不認同這種作法，這次的事件是在反跨與挺跨長期衝突之下引爆的，動不動就封鎖只會被說維基百科是一言堂。--世界解放者（留言） 2024年8月2日 (五) 05:44 (UTC)[回复]
所以你的意思是如果破坏者是因为反跨性别而造成破坏，就不应该「动不动就封禁」？--0xDeadbeef (留言) 2024年8月2日 (五) 06:20 (UTC)[回复]
我的意思是封鎖是最後手段，不論破壞者的立場，我都不會希望他們「儘快自爆以便封鎖」。--世界解放者（留言） 2024年8月2日 (五) 07:39 (UTC)[回复]
現在連J·K·羅琳、理查·道金斯、伊隆·馬斯克、唐納·川普都參戰了，連這些名人都不知道真相了，那些破壞者也可能自認是善意編輯。--世界解放者（留言） 2024年8月2日 (五) 07:50 (UTC)[回复]
現在連來自LGBT違法的阿爾及利亞的選手都會被說是跨性別，我真的不知道要說啥了。--世界解放者（留言） 2024年8月2日 (五) 05:38 (UTC)[回复]
@甜甜圈真好吃：不要隨便給人加上「跨性別運動員」的分類，已回退。--世界解放者（留言） 2024年8月2日 (五) 05:26 (UTC)[回复]
既然不能加跨性別運動員，那能不能加中性運動員或者是雙性運動員？(去年大陸也有因為類似的原因而被世界田聯和中國田聯禁賽的[3])--马华公会是一群汉奸创造出来的政党--甜甜圈 2024年8月4日 (日) 05:24 (UTC)[回复]
“中性运动员”“双性运动员”是什么鬼 捂脸--—自由雨日（留言｜贡献） 2024年8月4日 (日) 05:41 (UTC)[回复]
實際上指的是既有男性特徵也有女性特徵的運動員參見间性人--马华公会是一群汉奸创造出来的政党--甜甜圈 2024年8月4日 (日) 06:43 (UTC)[回复]
“既有男性特征也有女性特征的运动员”也不等于“间性人”啊 捂脸，以及“中性运动员”“双性运动员”那两个词是不是你原创？--—自由雨日（留言｜贡献） 2024年8月4日 (日) 06:45 (UTC)[回复]
是原創，但是不會用在編輯相關內容只是在討論用作描述用途。(實質就是代指跨性別運動員)--马华公会是一群汉奸创造出来的政党--甜甜圈 2024年8月4日 (日) 07:32 (UTC)[回复]
你并不“只是在讨论用作描述用途”，而是想把它加到分类啊 囧rz……请阅读WP:分类，分类尤其（比重定向等都更）禁止原创！--—自由雨日（留言｜贡献） 2024年8月4日 (日) 07:34 (UTC)[回复]
在沒有可靠證據之前，把林郁婷加上女性以外的描述都會給人帶來麻煩。我看網路愈吵愈兇，愈來愈擔心有極端分子會「付諸行動」了，畢竟台灣人頂多嘴巴上說LGBT噁心，外國人就難說囉。--世界解放者（留言） 2024年8月4日 (日) 10:42 (UTC)[回复]
結果在我上面說完這些話之後，就真的有人在中文條目中稱林郁婷是偽裝成女性的男性之後被人回退了。--马华公会是一群汉奸创造出来的政党--甜甜圈 2024年8月4日 (日) 23:01 (UTC)[回复]
早来源的时候看到了印尼对外媒体印尼之声的文章在标题中有提及涉事的两名选手是跨性别(2024年奥运会跨性别拳击手争议[4])。那是不是说可以使用有媒体来指明他们是跨性别？--马华公会是一群汉奸创造出来的政党--甜甜圈 2024年8月5日 (一) 02:01 (UTC)[回复]
編者要有綜合判斷該不該添加一個來源的能力，而不是只看它的發布機構。而且稍後的新聞也改成涉嫌了。--世界解放者（留言） 2024年8月5日 (一) 02:33 (UTC)[回复]
@甜甜圈真好吃：我覺得你沒有搞懂我的意思，我一直想表達的是，維基人編寫時要注意條目給人、社會帶來的影響，而不是拘泥於維基百科的規則。例如我在Talk:2024年台中捷運隨機傷人事件留言時，有許多媒體報導嫌犯的動機，但我認為假如加入的資訊有誤，可能就成為錯誤資訊的幫兇，增加社會的對立，這不能以「我只是引用新聞」來合理化。--世界解放者（留言） 2024年8月5日 (一) 03:02 (UTC)[回复]
那按照这种观点安东尼·阿米拉蒂在巴黎奥运会撑杆跳项目中，由于陰莖勃起导致无法进入决赛是不是不能收录？（英语和法语社群因为相关内容不符合生者传记方针导致相关内容被删除并且英语社群将其的条目进行了半保护。）--马华公会是一群汉奸创造出来的政党--甜甜圈 2024年8月6日 (二) 09:30 (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)[回复]

爭議領土相關雙重標準問題

[编辑]

原标题为：使用单一标准，停止双重标准

我的意见如下：User:Interaccoonale/论维基百科的双重标准

我不会回应这里的任何评论。我在客栈发表这个话题只是为了让某些人认识到自己有多么虚伪。--——🦝Interaccoonale（留言・贡献） 2024年8月5日 (一) 14:45 (UTC)[回复]

？ ——魔琴［身份声明 留言 贡献 新手2023］ 2024年8月5日 (一) 15:07 (UTC)[回复]
您回不回應隨你的便，我僅在此發表一些小意見：論「論維基百科的雙重標準」的雙重標準（當然他人也能回論「論「論維基百科的雙重標準」的雙重標準」的雙重標準，甚至論「論「論「論維基百科的雙重標準」的雙重標準」的雙重標準」的雙重標準⋯⋯）
關於「美帝」的雙重標準（斯諾登/北部灣⋯⋯），我無意反駁。然而，美帝雙重標準，難道反美帝的就不雙重標準？用以巴為例，猶太人用三分之一人數獲得過半原巴勒斯坦託管地土地（之後甚至更多），所以要「解決巴勒斯坦問題的根本出路是落實「兩國方案⋯⋯」。問題是，如果用三分之一人數獲得過半原巴勒斯坦託管地土地是「殖民」甚至「侵略」，請問漢人以不足十分之人控制新疆是否「殖民」甚至「侵略」（试论1949年以后新疆汉族移民的类型与功效）？如果是，為什麼不同樣在新疆「落實「兩國方案」」云云？如果不是，那為什麼猶太人用三分之一人數獲得過半原巴勒斯坦託管地土地就是「殖民」甚至「侵略」？
您願意反對雙重標準，這是一件美事。正因如此，我才要主張不能雙重標準地「反對雙重標準」/以「反對雙重標準」之名來雙重標準。借某網友一言：除非行納粹禮，否則當手指向他人時，有更多手指指向自己。所以反對雙重標準，就是反對一切的雙重標準，包括對己方的雙重標準。--Cmsth11126a02 (留言) 國民黨的正確名稱是大陸國民黨！ 2024年8月5日 (一) 16:01 (UTC)[回复]
此篇反映閣下對分析事件的深度遠遠不足。
  1. 俄烏衝突中，國際社會都不承認盧、頓兩共和國是獨立國家，但並非「自始至終」都是「獨立國家」（實際上也不過是俄國佔領），而是確確實實曾屬於烏克蘭（1991年至2014年）。而西藏的部分，西藏歷經中國大陸一整個政權的時光為獨立政權且非他國控制，乃是一個政權覆滅後自然產生的分裂政權，在解放軍進駐西藏前，中國也僅僅是「聲稱」擁有西藏而未曾實際擁有。藏南地區這片土地在此前未曾屬於中華民國或中華人民共和國政權，即自始就是「爭議領地」，而國際社會並無承認或否認任一政權對該片土地的主權。「俄佔」是因其中一方（烏克蘭）的聲稱獲極主流承認，而藏南地區的聲稱則雙方都沒有「多數」國家承認，自然只能以當前佔有方事實命名和敘述。當然，阿魯納恰爾邦等條目可以在資訊框等加上中國聲稱等字樣，這是確確實實存在的聲稱，當然可以反映出來；但無國際普遍認定的邊界就表示這片土地只能描述為「某方控制」而非「佔領」，因後者代表「控制明顯不屬於自己的土地」，而俄羅斯及其傀儡政權則是顯然被國際絕大多數國家（不論東西方）認定是「佔領」烏克蘭土地。
  2. 有關「大屠殺」：Interaccoonale自己擺明違反WP:UNDUE的編輯竟然還大言不慚地說是他人雙重標準。若你的編輯是添加「部分意見將該次事件定性為大屠殺事件」，這是合理比重的反映（因這是有可靠來源的支撐，但將有關事件描述為大屠殺的來源在比例上極少，甚至日本自己及受害城市未曾在國家及城市級別認定是大屠殺）；但你的編輯確實將顯然是自己同意小眾來源的定義置於中立的描述之上。自己違反了WP:UNDUE還大聲賊喊抓賊。相對而言，以哈衝突的有關條目則是更好地平衡雙方「行動」及「大屠殺」的描述。該衝突的大型平民遇害事件的定性未曾明朗，自然只能同等程度地描述雙方觀點，而該條目顯然做到。自己做不到合理比重就酸別人是雙重標準，也不想想是不是你自己的標準有問題？還有，通篇就列我一個用戶名，是想玩什麼抹黑？是擺明在玩假定惡意嗎？
--路西法人 2024年8月6日 (二) 02:34 (UTC)[回复]
既然樓主這樣說，在客棧回應似乎沒有意義。我已在樓主的討論頁留言。--派翠可夫 (留言按此) 2024年8月6日 (二) 03:35 (UTC)[回复]

HYHJKJYUJYTTY的侵权调查已完成

[编辑]

感谢人间百态在此案件上的不懈贡献，调查总结：HYHJKJYUJYTTY共在15个条目下加入了侵权内容。

具体请见User:0xDeadbeef/CCI/HYHJKJYUJYTTY下的详细内容。--0xDeadbeef (留言) 2024年8月7日 (三) 10:58 (UTC)[回复]

这次正好是作为正式（之前提出过）的「著作权调查」的试运行吧。--0xDeadbeef (留言) 2024年8月7日 (三) 10:59 (UTC)[回复]
检索自“https://zh.wikipedia.org/w/index.php?title=Wikipedia:互助客栈/其他&oldid=83726871”