維基百科:互助客棧/其他
發表前請先搜尋存檔,參考舊討論中的內容可節省您的時間。 |
|
- [人事] 請關注管理員Mys 721tx的解任案聯署。
- [人事] 於2024年5月管理人員申請中,AT當選監督員、Manchiu當選管理員、ATannedBurger當選臨時管理員。
- [公告] 破壞方針重修條文已經通過。
- [公告] 2024年日本ACGN條目通用譯名定義更新議案及更新日本遊戲命名辦法議案、電視條目播放資訊增加收錄準則及規範討論發起步驟正在公示,如有意見請儘快提出。
- [公告] 互助客棧正在對於Unblock-zh.org的各項細節徵求意見。
- [討論] 隨管理人員申請進行,有關仲裁委員會與管理人員解任程序調整的問卷調查結果經已刊登。社群正在討論實行機制,敬請踴躍參與。
- [討論] 互助客棧方針區正在討論修訂高風險主題回退限制,請踴躍參與討論。
- [討論] 互助客棧技術區正在討論更改未登入用戶的預設字體大小及增加外觀選單,請踴躍參與討論。
- [討論] 互助客棧其他區正在討論頁面評級與通用評級行政層面上的統合方案及將法輪功及臺灣政治訂為高風險主題,請踴躍參與討論。
- [廣告] 第二十二次動員令將於7月6日至9月8日間舉行,現正在提議、協調主題,歡迎踴躍參與!
- [廣告] 維基百科非洲月現正舉行,直至6月30日完結,歡迎踴躍參與!
存檔 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
# | 💭 話題 | 💬 | 👥 | 🙋 最新發言 | 🕒 (UTC+8) |
---|---|---|---|---|---|
1 | 沒有主題的頁面如何評級 | 195 | 12 | A2569875 | 2024-06-16 19:58 |
2 | 評級系統缺失問題 | 216 | 21 | A2569875 | 2024-06-16 20:06 |
3 | 管理人員申請預討論 | 60 | 18 | 阿南之人 | 2024-06-13 11:52 |
4 | 對新用戶禁用內容翻譯工具(續) | 32 | 13 | SCP-2000 | 2024-05-24 00:31 |
5 | Unblock-zh.org | 60 | 14 | Bluedeck | 2024-06-14 13:29 |
6 | 2024年非洲月籌備討論 | 1 | 1 | Alankang | 2024-06-10 22:08 |
7 | 設立法輪功為高風險主題 | 80 | 20 | Wetrace | 2024-06-20 00:07 |
8 | 將「1945年後臺灣政治」訂為高風險主題 | 32 | 15 | Wetrace | 2024-06-20 00:14 |
9 | 關於牢大 | 4 | 2 | YFdyh000 | 2024-06-10 22:01 |
10 | 維基餐廳食品增減 | 26 | 13 | Lemonaka | 2024-06-14 18:45 |
11 | 移除Module:RFX report的「驗票」連結 | 6 | 3 | LuciferianThomas | 2024-06-12 12:42 |
12 | 要求社群處理Mys 721tx管理員擾亂性用權、誹謗用戶事情 | 58 | 19 | Hoben7599 | 2024-06-19 22:55 |
13 | RFDA(及未來成立仲裁委員會後的解任程序)相關探討 | 97 | 17 | Ericliu1912 | 2024-06-20 02:20 |
14 | 新用戶通過撰寫新條目的方式「完成學科作業」的處理討論 | 13 | 10 | Flyinet | 2024-06-17 20:52 |
15 | 請求討論LuciferianThomas涉嫌擾亂、遊戲Rfda共識形成事情 | 18 | 8 | Ericliu1912 | 2024-06-19 22:20 |
16 | 建議多多關注那些潛在的高風險主題 | 1 | 1 | Great Brightstar | 2024-06-17 13:48 |
17 | Template:Policy風格 | 4 | 4 | What7what8 | 2024-06-19 23:34 |
發言更新圖例 |
---|
|
|
|
|
|
特殊狀態 |
已移動至其他頁面 或完成討論之議題 |
手動設定 |
當列表出現異常時, 請先檢查設定是否有誤 |
正在廣泛徵求意見的議題
以下討論需要社群廣泛關注:(重新整理)
維基專題與協作[編輯]
目前此主題無正在討論的議題
|
沒有主題的頁面如何評級[編輯]
- 下列討論已經關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
像是包、比 (消歧義)、值 (消歧義)這種,內容並不屬於任何專題管轄的頁面,要如何評級?有沒有辦法「無專題評級」?不然在統計工具上面,這些未評級的頁面都無法正常顯示頁面種類。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2023年12月7日 (四) 08:59 (UTC)
- 主題更多是用來評判重要度而非寫作水準的吧,或許可以考慮一個通用評級,比如實際上並不應該被劃到單一專題內的消歧義頁。——暁月凜奈 (留言) 2023年12月7日 (四) 09:34 (UTC)
- (?)疑問@暁月凛奈:比方說創建一個專用的、通用的評級模板,無專題,不使用{{WPBannerMeta}}元模板,內部只塞「本頁面獲評XX級」和Special:頁面評級的解析器語法,然後沒有別的說明?-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2023年12月7日 (四) 09:48 (UTC)
- 我基本沒有參與評級相關,我不太明白為什麼條目質量一定要和專題掛鉤。舉個例子的話,頁面李的六個鏈接五個是姓氏,一個是植物,被劃到生物還是人文都顯然不合適,而且消歧義頁本來也不算做條目。或許也可以設計成,「本頁面尚未劃分到具體專題,歡迎協助標記」,然後消歧義頁等頁面用參數取消這一句。——暁月凜奈 (留言) 2023年12月7日 (四) 11:51 (UTC)
- (?)疑問@暁月凛奈:比方說創建一個專用的、通用的評級模板,無專題,不使用{{WPBannerMeta}}元模板,內部只塞「本頁面獲評XX級」和Special:頁面評級的解析器語法,然後沒有別的說明?-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2023年12月7日 (四) 09:48 (UTC)
{{WikiProject Article assessment}}
可託管沒有專題支援的條目--洛普利寧 2023年12月7日 (四) 11:58 (UTC)- (:)回應PJ:條目質量評級「
這個維基專題已經廢棄。
」。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2023年12月7日 (四) 12:18 (UTC)- 幾乎所有專題都是廢棄的,只是這個專題明面上寫了而已;稍微好一點的是只有一個人參加的「個人專題」,不過這種專題基本上也是三分鐘熱度。如果你只是為了評級,那就不用管專題是否活躍,直接把
{{WikiProject Article assessment}}
往討論頁上貼就可以。以中維的實力來說,條目沒有專題評級才應該是正常的,有評級的反而屬於異端--洛普利寧 2023年12月7日 (四) 12:41 (UTC)- 沒有到「
異端
」那麼慘吧,根據WP:評級:「截至2022年,英文維基百科已經有超過700萬條目被評級。很多其他語言版本也開始使用評級系統。中文維基百科約有38萬條目接受評級。
」現在中文維基約有100萬條目,100萬中的38萬,三成多,這樣平均三個條目就有一個條目有評級啊。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2023年12月7日 (四) 13:10 (UTC)
- 模板、分類、甚至是檔案也是需要評級的項目,算上去真的跟異端沒兩樣。而掛上專題模板呈現的未評級狀態能算評級嗎。 --窩法乙烷 兒法夢碎 2023年12月7日 (四) 14:03 (UTC)
- (:)回應:@Milkypine:WP:評級:「
約有38萬條目
」,中文維基百科條目數也才100萬啊。哪有「異端
」?我還異端兒勒。另WP:評級#統計,所有掛有評級模板條目討論頁有562,943頁,未填寫評級的「未評級狀態」之條目討論頁有182,858頁,562,943 − 182,858 = 380,085。所以被評級的「條目」是38萬無誤,100萬分之38萬 = 38%。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2023年12月7日 (四) 14:33 (UTC)- @A2569875:先定義何謂異端,如果數字多就不算異端,那麼日本和中國市場可以除名異端狀態了。 --窩法乙烷 兒法夢碎 2023年12月7日 (四) 14:54 (UTC)
- 更不用38%是數字少的一方,對中維其餘62%條目來講,這38%就是異端。 --窩法乙烷 兒法夢碎 2023年12月7日 (四) 14:59 (UTC)
- (:)回應:@Milkypine:WP:評級:「
- 模板、分類、甚至是檔案也是需要評級的項目,算上去真的跟異端沒兩樣。而掛上專題模板呈現的未評級狀態能算評級嗎。 --窩法乙烷 兒法夢碎 2023年12月7日 (四) 14:03 (UTC)
- 沒有到「
- 幾乎所有專題都是廢棄的,只是這個專題明面上寫了而已;稍微好一點的是只有一個人參加的「個人專題」,不過這種專題基本上也是三分鐘熱度。如果你只是為了評級,那就不用管專題是否活躍,直接把
- (:)回應PJ:條目質量評級「
- {{WikiProject Disambiguation}},這個?--Kethyga(留言) 2023年12月7日 (四) 12:47 (UTC)
- 僅供參考: enwiki之前也有相關討論,現在已由{{WPBS}}自動為這類型非條目賦予NA-、Redirect-級別的評級與重要度。請參見w:wn:Wikipedia:Bots/Requests for approval/Qwerfjkl (bot) 24。中文或許如Category:非條目級條目?--Kanashimi(留言) 2024年1月10日 (三) 06:05 (UTC)
- 本討論已關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
Random Thought: 跟進英維的WikiProject banner shell改版[編輯]
- 下列討論已經關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
我倒是想起一個事兒。英維最近改版了{{WikiProject banner shell}}模版(新樣式在這裡),新的模版可以單獨給條目一個總體的品質評級,各個WikiProject可以直接繼承這個quality assessment,也可以搞自己的評級。你看是不是能實現你的沒有管轄之WikiProject依然可以有評級的願望? --MilkyDefer 2023年12月7日 (四) 14:59 (UTC)
- @A2569875,附知。--MilkyDefer 2023年12月8日 (五) 09:03 (UTC)
- @MilkyDefer稍微研究了一下,跟本地系統完全不相容,根本不知道怎麼改。他的評級是純粹使用英文字母的,我們是中文,從他目前的模組架構,我看不出來哪邊可以插入本地的評級模式。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2023年12月9日 (六) 07:47 (UTC)
- @MilkyDefer既然您提議了,我請求您給出可以執行的方案或建議,謝謝。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2023年12月9日 (六) 07:49 (UTC)
- 那就是我自己按照人家代碼的思路重新實現一個類似的咯。上一次的ping模板改版姑且讓我熟悉了一點Lua語言。--MilkyDefer 2023年12月9日 (六) 11:24 (UTC)
- 原樣照辦英維的codebase要動的手術很大。不過我姑且給你實作了一個長得差不多的在對應沙盒裡面。--MilkyDefer 2023年12月9日 (六) 14:14 (UTC)
- (:)回應:@MilkyDefer:可是我好像沒看到
{{#assessment:}}
語法。沒使用{{#assessment:}}
的話也無法被系統和各類工具識別,那樣也無法解決我最初提出來的問題啊⋯⋯ -- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2023年12月10日 (日) 05:09 (UTC) - (:)回應:@MilkyDefer:我把
{{#assessment:}}
加上去了,順便調整一下讓預設(模板預覽)不要顯示錯誤,你看一下這樣適不適當。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2023年12月10日 (日) 17:43 (UTC)- 你自己決斷。如我前面所述,我的改動只是一個臨時性的方案。遲早需要重新規劃這一套系統的技術編排,屆時現在的變動會被新架構完全覆蓋掉。--MilkyDefer 2023年12月10日 (日) 18:22 (UTC)
- (:)回應:@MilkyDefer:{{WikiProject banner shell}}目前獲WP:模板保護,即使是這個臨時方案也須獲社群共識才得以使用。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2023年12月11日 (一) 00:05 (UTC)
- 你自己決斷。如我前面所述,我的改動只是一個臨時性的方案。遲早需要重新規劃這一套系統的技術編排,屆時現在的變動會被新架構完全覆蓋掉。--MilkyDefer 2023年12月10日 (日) 18:22 (UTC)
- (:)回應:@MilkyDefer:可是我好像沒看到
- @MilkyDefer既然您提議了,我請求您給出可以執行的方案或建議,謝謝。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2023年12月9日 (六) 07:49 (UTC)
- @MilkyDefer稍微研究了一下,跟本地系統完全不相容,根本不知道怎麼改。他的評級是純粹使用英文字母的,我們是中文,從他目前的模組架構,我看不出來哪邊可以插入本地的評級模式。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2023年12月9日 (六) 07:47 (UTC)
- 本討論已關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
第一階段:修改WikiProject banner shell[編輯]
- 下列討論已經關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
- 工程量挺大,就看誰願意改了。(幾年前可能我有興趣,現在我就精神上支持了)--洛普利寧 2023年12月8日 (五) 14:53 (UTC)
- 目前(+)支持User:MilkyDefer的臨時方案。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2023年12月11日 (一) 00:17 (UTC)
- (?)疑問:@Milkypine、暁月凛奈:您們認為暫時先用MilkyDefer的臨時方案如何?暫且能解決目前問題,且朝模板的新版改進邁進中。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2023年12月11日 (一) 00:24 (UTC)
- (+)支持設立通用評級,但最好展現一下沙盒效果,現在點進去看到的文件說明還是舊版本。 --窩法乙烷 兒法夢碎 2023年12月11日 (一) 11:16 (UTC)
- (:)回應:@Milkypine:可以參考測試樣例Template talk:WikiProject banner shell/testcases(評級模板的測試樣例只能放討論頁,不然會有錯誤訊息 囧rz……;首個測試樣例填了GA,所以這裡可以看到這表格最下面「評級」是「優良」,表示新模板有效)-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2023年12月11日 (一) 12:15 (UTC)
- 已逾一周無新意見,視為已有初步共識。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2023年12月20日 (三) 13:23 (UTC)
- 一個小問題,見測試11,若是位於模板空間應修先顯示為模板級。且依據我於Talk:醫學測試結果,似乎不符合預期。-- Willy1018(留言) 2023年12月21日 (四) 06:26 (UTC)
- (?)疑問@Willy1018:Talk:醫學測試結果哪邊不合預期?不是都正常顯示甲級嗎,下面也能展開
|collapsed=yes
預設不展開也正常啊。然後無法理解測試11明明已經指定了,為何要fallback to模板級?指定級別顯然優先於預設級別;未指定本來就該都沒有評級。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2023年12月21日 (四) 13:29 (UTC)- 底下:網際網路專題、維基百科專題、機器人學專題,應顯示為A級而不是未評。-- Willy1018(留言) 2023年12月22日 (五) 03:47 (UTC)
- 如果本來就是這樣設計的,當我沒說吧。-- Willy1018(留言) 2023年12月22日 (五) 03:48 (UTC)
- @Willy1018:網際網路專題、維基百科專題、機器人學專題的模板又沒有要改版,既然他沒有要改版,那麼那些模板沒有輸入評級他是要怎麼知道評級成什麼?通靈嗎?而且模板參數因技術限制無法跨模板互通,所以也不可能把A級資訊傳遞進模板(實現如此傳遞需要mw:Extension:Variables,萌娘百科有,但中文維基沒有,且相關擴展不相容於目前版本的MediaWiki)。再來,你看User:MilkyDefer的原始提案「
新的模版可以單獨給條目一個總體的品質評級[…]也可以搞自己的評級。
」這代表各個專題的評級模板是自己搞自己的,每個專題的評級互相獨立並不相干,因此沒有輸入就該維持沒有輸入評級的狀態,本就不應該蹦出沒有輸入卻變成A級的這種狀況。再來「優先顯示模板級」問題肯定也是上方誤會導致的。既然你都說「如果本來就是這樣設計的,當我沒說吧。
」了,那麼我就視為異議已排除,可以準備進行公示階段。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2023年12月22日 (五) 04:15 (UTC)
- @Willy1018:網際網路專題、維基百科專題、機器人學專題的模板又沒有要改版,既然他沒有要改版,那麼那些模板沒有輸入評級他是要怎麼知道評級成什麼?通靈嗎?而且模板參數因技術限制無法跨模板互通,所以也不可能把A級資訊傳遞進模板(實現如此傳遞需要mw:Extension:Variables,萌娘百科有,但中文維基沒有,且相關擴展不相容於目前版本的MediaWiki)。再來,你看User:MilkyDefer的原始提案「
- 如果本來就是這樣設計的,當我沒說吧。-- Willy1018(留言) 2023年12月22日 (五) 03:48 (UTC)
- 底下:網際網路專題、維基百科專題、機器人學專題,應顯示為A級而不是未評。-- Willy1018(留言) 2023年12月22日 (五) 03:47 (UTC)
- @Willy1018:跟您說明一下目前辦理狀況。已建立專門讀取通用評級資訊的模組Module:PJBSClass,目前我用電子遊戲專題測試,測試結果見Talk:皮卡丘的測試結果,在電子遊戲專題模板未輸入評級時,其有確實從外層的{{WikiProject banner shell/sandbox}}讀到
|class=Start
,你看這是不是你要的,如果是,則還須對Template:WPBannerMeta提編輯請求。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2023年12月24日 (日) 02:58 (UTC)- 感謝貢獻,目前已覆核已符合預期。-- Willy1018(留言) 2023年12月24日 (日) 05:17 (UTC)
- (:)回應:@Willy1018:但要達成您所見到的效果需要第二階段的修改,跟{{WPBannerMeta}}配合。這樣的話,我就視為您對第二階段持(+)支持態度囉。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2023年12月24日 (日) 08:12 (UTC)
- 無異議。-- Willy1018(留言) 2023年12月25日 (一) 04:00 (UTC)
- (:)回應:@Willy1018:但要達成您所見到的效果需要第二階段的修改,跟{{WPBannerMeta}}配合。這樣的話,我就視為您對第二階段持(+)支持態度囉。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2023年12月24日 (日) 08:12 (UTC)
- 感謝貢獻,目前已覆核已符合預期。-- Willy1018(留言) 2023年12月24日 (日) 05:17 (UTC)
- (?)疑問@Willy1018:Talk:醫學測試結果哪邊不合預期?不是都正常顯示甲級嗎,下面也能展開
- 一個小問題,見測試11,若是位於模板空間應修先顯示為模板級。且依據我於Talk:醫學測試結果,似乎不符合預期。-- Willy1018(留言) 2023年12月21日 (四) 06:26 (UTC)
- (+)支持設立通用評級,但最好展現一下沙盒效果,現在點進去看到的文件說明還是舊版本。 --窩法乙烷 兒法夢碎 2023年12月11日 (一) 11:16 (UTC)
- 此段落最後發言至今已逾七日,超過一周無新留言,且此前已形成初步共識,因此根據WP:7DAYS準備進行公示。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月1日 (一) 04:04 (UTC)
- 公示7日。公示內容見此-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月1日 (一) 04:04 (UTC)
- 本討論已關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
- 完成:已佈署Special:Diff/80410249。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月8日 (一) 04:40 (UTC)
第二階段:修改WPBannerMeta[編輯]
- 下列討論已經關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
@Willy1018:提到了一個很有意義的問題。如果上方的變更套用了的話,只有「表面上」給了頁面通用評級,而實際上的通用評級在各個專題中並沒有達成「繼承評級」的效果。這是因為評級模板預設不會知道他外面包著{{WikiProject banner shell}}模板,因此,如果要讓每個評級模板都能讀到通用評級,需要再一個編輯請求。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2023年12月24日 (日) 05:15 (UTC)
- 預計將會使用Module:PJBSClass來讀取{{WikiProject banner shell}}模板中的評級,並傳遞給{{WPBannerMeta}}注入進class參數。由於這需要第一階段先通過才有用,故先 擱置,等第一階段。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2023年12月24日 (日) 05:15 (UTC)
- 第二階段相關討論Special:PermaLink/80224436#回復通告-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2023年12月25日 (一) 02:56 (UTC)
- 已覆核,已符合預期,再次感謝您的貢獻。(搬運自Special:PermaLink/80233084)-- Willy1018(留言) 2023年12月25日 (一) 04:02 (UTC)
- 上面的共識是「
可以單獨給條目一個總體的品質評級,各個WikiProject可以直接繼承這個quality assessment,也可以搞自己的評級。
」,下方Wikipedia:互助客棧/其他#關於基礎條目的額外提議也有多個(+)支持「對各種專題橫幅不再個別指定 class,而是統一置於{{WPBS}}
」的聲音,為了實現上方共識「各個WikiProject可以直接繼承這個quality assessment」以及下方討論的「專題橫幅不再個別指定 class,而是統一置於{{WPBS}}」因此需要在{{WPBannerMeta}}置入讀取{{WPBS}}評級值的模板,以便讓專題橫幅能正確識別統一置於{{WPBS}}的評級,故本修改是必要的,目前已經佈署於電子遊戲專題和多面體專題,運作穩定。如無異議,將會進行公示,進行全面佈署。
- 預計的修改方案以及其佈署連結(記得填寫討論通過的diff和客棧PermaLink版本號)。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月3日 (三) 05:00 (UTC)
相關議案
的配套修改-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月8日 (一) 05:03 (UTC)
- 想諮詢一下@Kanashimi君相關修改是否有問題?—— Eric Liu 創造は生命(留言・留名・學生會) 2024年1月8日 (一) 05:53 (UTC)
- @Ericliu1912、Kanashimi:這主要是依據共識,讓專題橫幅能繼承{{PJBS}}輸入的評級值。我已經在{{多面體專題}}、{{電子遊戲專題}}測試過了,沒有問題。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月8日 (一) 06:00 (UTC)
- User:A2569875的努力有目共睹。只不過我原先料想的是直接改w:en:Module:WikiProject banner及w:en:Module:Banner shell,而宇帆-娜娜奇看起來很辛苦的重構了代碼,並且有些參數不太一樣,這樣我就不太好評論了。--Kanashimi(留言) 2024年1月8日 (一) 06:12 (UTC)
- @Ericliu1912、Kanashimi:那就用測試數據來說話吧。目前我是刻意讓{{多面體專題}}內部是調用Template:WPBannerMeta/sandbox/sandbox(同於Template:WPBannerMeta/sandbox,只是Template:WPBannerMeta/sandbox/sandbox裡面都塞/sandbox模板以便測試效果),效果完全符合預期,十分正常,見下列測試結果(只要是調用{{多面體專題}}的,基本上都等同於這個Patch):
- Talk:二十面體對稱的多面體列表:裡面輸入了列表級,Template:WPBannerMeta/sandbox確實讀到了列表級,沒有問題。
- 其他可參考Special:鏈入頁面/Template:WPBannerMeta/sandbox/sandbox,基本上都沒有問題,我檢查一個禮拜了。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月8日 (一) 06:16 (UTC)
- Eric Liu 創造は生命(留言・留名・學生會) 2024年1月8日 (一) 12:18 (UTC)
- @Ericliu1912:若以Wikipedia:互助客棧/其他#Random_Thought:_跟進英維的WikiProject_banner_shell改版這一案來看的話(或者說只看這一案)的話,只有{{WPBannerMeta/core}}和{{WPBannerMeta}}要更新。其他案目前還在討論中。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月8日 (一) 12:23 (UTC)
- (~)補充:@Ericliu1912:參考這個留言Wikipedia:互助客棧/其他#MilkyDefer2023年12月9日(六)14:14(UTC),「
原樣照辦英維的codebase要動的手術很大。不過我姑且給你實作了一個長得差不多的在對應沙盒裡面。
」考慮到最大相容性和中文維基的特殊性(如繁簡問題),本地評級系統本來就跟英文維基不太相同。目前只能「按照人家代碼的思路重新實現一個類似的咯。
」(by User:MilkyDefer)此外,我也不想換掉現在中文維基熟悉的Style。目前您所看到的系統都是基於MilkyDefer的修改版再把enwiki對應功能實作出來。主要功能去年年底就完工了,經過了半個多月的測試,我相信技術上不會有太大的問題。且相關函數已於電子遊戲專題兩萬多條目進行測試,問題幾乎都解決了。技術上沒有問題。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月8日 (一) 12:58 (UTC)
- (~)補充:@Ericliu1912:參考這個留言Wikipedia:互助客棧/其他#MilkyDefer2023年12月9日(六)14:14(UTC),「
考慮到日後長期維護需求,我傾向請您以英文版本為基礎來更新相關模板。是否能夠確認有什麼模板需要更新(或在互助客棧列出之類)?不過在此過渡期間,若技術上沒有問題,是可以斟酌先批准既有之編輯請求。—— - @Ericliu1912:若以Wikipedia:互助客棧/其他#Random_Thought:_跟進英維的WikiProject_banner_shell改版這一案來看的話(或者說只看這一案)的話,只有{{WPBannerMeta/core}}和{{WPBannerMeta}}要更新。其他案目前還在討論中。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月8日 (一) 12:23 (UTC)
- 這兩個(Template_talk:WPBannerMeta#編輯請求_2024-01-08、Template_talk:WPBannerMeta/core#編輯請求_2023-12-28)屬於案《Random Thought: 跟進英維的WikiProject_banner_shell改版》可以先進行;剩下的屬於另一案(Module_talk:Class/data#編輯請求_2023-12-28、Template_talk:Class_mask#編輯請求_2024-01-05、Template_talk:Class_mask/core#編輯請求_2023-12-25、Template_talk:Class/colour#編輯請求_2024-01-05)屬於案《同步各模板/組的評級值》目前正在公示,所以暫時還不用。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月8日 (一) 14:59 (UTC)
- @Ericliu1912:要改哪些模板我在客棧上其實都有列,主要在案《沒有主題的頁面如何評級》和案《評級系統缺失問題》的子章節裡。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月8日 (一) 15:03 (UTC)
- (不用一直提及我,我有在看)—— Eric Liu 創造は生命(留言・留名・學生會) 2024年1月8日 (一) 15:11 (UTC)
- (:)回應:既然你有在看,那我就更仔細地說明這兩個編輯請求(Template_talk:WPBannerMeta#編輯請求_2024-01-08、Template_talk:WPBannerMeta/core#編輯請求_2023-12-28)技術上沒有問題、無疑慮的理由。這兩個編輯請求加起來的編輯內容等價於我上個月在{{WikiProject Video games}}做出的這筆編輯Special:Diff/80221014。用的模組和函數完全相同,只是僅限於電子遊戲專題,而這兩個編輯請求加起來的編輯內容就等於佈署到所有專題。電子遊戲專題之所有不用編輯兩個模板是因為{{WikiProject Video games}}不使用元模板,也沒有/core,因此編輯一個頁面就能達到效果,而所有專題共用的元模板有使用元模板/core,因此需要編輯兩個模板(主模板和/core模板)才能生效。電子遊戲專題共有兩萬多個條目,這功能佈署到電子遊戲專題至今已半個多月,未見什麼大問題,代表已經在兩萬個條目測試沒問題(稍早也測試了{{多面體專題}},500+條目;實際上還佈署到了{{互聯網專題}}、{{維基百科專題}}和{{WikiProject Robotics}}上以便讓User:Willy1018已覆核效果符合預期;更進一步的技術測試則在{{WikiProject_Sandbox}}及{{WikiProject Portals}}完成,均未發現任何問題;為了避免影響到Patch,測試是由{{WPBannerMeta/sandbox/sandbox}}和{{WPBannerMeta/core/sandbox/sandbox}}完成,測試方式是直接先暫時將對應模板改用{{WPBannerMeta/sandbox/sandbox}}和{{WPBannerMeta/core/sandbox/sandbox}}以觀察佈署後的效果),我這半個月也實際複查數百個條目,沒發現任何問題,代表這兩萬多個條目的測試是成功的,因此認為本開發已趨於穩定,是時候可以佈署到所有專題了。以上,故認為技術上沒有問題,可以佈署Template_talk:WPBannerMeta#編輯請求_2024-01-08和Template_talk:WPBannerMeta/core#編輯請求_2023-12-28。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月8日 (一) 15:46 (UTC)
- (~)補充:若這兩個編輯請求(Template_talk:WPBannerMeta#編輯請求_2024-01-08和Template_talk:WPBannerMeta/core#編輯請求_2023-12-28)核准了,記得通知我一聲,我需要在{{多面體專題}}、{{互聯網專題}}、{{維基百科專題}}、{{WikiProject Robotics}}和{{WikiProject Portals}}取消佈署,避免重複佈署和{{WPBannerMeta}}及{{WPBannerMeta/core}}相衝。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月8日 (一) 15:55 (UTC)
- (:)回應:既然你有在看,那我就更仔細地說明這兩個編輯請求(Template_talk:WPBannerMeta#編輯請求_2024-01-08、Template_talk:WPBannerMeta/core#編輯請求_2023-12-28)技術上沒有問題、無疑慮的理由。這兩個編輯請求加起來的編輯內容等價於我上個月在{{WikiProject Video games}}做出的這筆編輯Special:Diff/80221014。用的模組和函數完全相同,只是僅限於電子遊戲專題,而這兩個編輯請求加起來的編輯內容就等於佈署到所有專題。電子遊戲專題之所有不用編輯兩個模板是因為{{WikiProject Video games}}不使用元模板,也沒有/core,因此編輯一個頁面就能達到效果,而所有專題共用的元模板有使用元模板/core,因此需要編輯兩個模板(主模板和/core模板)才能生效。電子遊戲專題共有兩萬多個條目,這功能佈署到電子遊戲專題至今已半個多月,未見什麼大問題,代表已經在兩萬個條目測試沒問題(稍早也測試了{{多面體專題}},500+條目;實際上還佈署到了{{互聯網專題}}、{{維基百科專題}}和{{WikiProject Robotics}}上以便讓User:Willy1018已覆核效果符合預期;更進一步的技術測試則在{{WikiProject_Sandbox}}及{{WikiProject Portals}}完成,均未發現任何問題;為了避免影響到Patch,測試是由{{WPBannerMeta/sandbox/sandbox}}和{{WPBannerMeta/core/sandbox/sandbox}}完成,測試方式是直接先暫時將對應模板改用{{WPBannerMeta/sandbox/sandbox}}和{{WPBannerMeta/core/sandbox/sandbox}}以觀察佈署後的效果),我這半個月也實際複查數百個條目,沒發現任何問題,代表這兩萬多個條目的測試是成功的,因此認為本開發已趨於穩定,是時候可以佈署到所有專題了。以上,故認為技術上沒有問題,可以佈署Template_talk:WPBannerMeta#編輯請求_2024-01-08和Template_talk:WPBannerMeta/core#編輯請求_2023-12-28。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月8日 (一) 15:46 (UTC)
- (不用一直提及我,我有在看)—— Eric Liu 創造は生命(留言・留名・學生會) 2024年1月8日 (一) 15:11 (UTC)
- @Ericliu1912:要改哪些模板我在客棧上其實都有列,主要在案《沒有主題的頁面如何評級》和案《評級系統缺失問題》的子章節裡。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月8日 (一) 15:03 (UTC)
- @Ericliu1912、Kanashimi:那就用測試數據來說話吧。目前我是刻意讓{{多面體專題}}內部是調用Template:WPBannerMeta/sandbox/sandbox(同於Template:WPBannerMeta/sandbox,只是Template:WPBannerMeta/sandbox/sandbox裡面都塞/sandbox模板以便測試效果),效果完全符合預期,十分正常,見下列測試結果(只要是調用{{多面體專題}}的,基本上都等同於這個Patch):
- @Ericliu1912、Kanashimi:另外參見此發言,User:Willy1018已覆核效果符合預期,認為修改沒有問題。測試也都充分了。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月8日 (一) 06:31 (UTC)
- @Ericliu1912:另外如果要接受編輯請求的話,也把Template_talk:WPBannerMeta/core#編輯請求_2023-12-28也接受吧,兩者是互相配套的({{WPBannerMeta}}與{{WPBannerMeta/core}}高度相依)。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月8日 (一) 06:33 (UTC)
- 相關討論移動到此供參考。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月9日 (二) 13:22 (UTC)
- 本議案旨在「讓專題橫幅能從{{PJBS}}繼承評級值」是否佈署到所有專題。目前已暫時透過沙盒模板測試性地佈署到電子遊戲專題、多面體專題、網際網路專題、維基百科專題、主題專題、沙盒專題。如無異議的話,將會就「是否佈署於所有專題」進行公示。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月9日 (二) 13:54 (UTC)
- 目前沒有合理異議,因此仍照原定計畫若2024年1月10日 (三) 05:00 (UTC)之前沒有其他異議就視為已獲共識。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月9日 (二) 17:48 (UTC)
- 依據此以及WP:7DAYS,時間已逾2024年1月10日 (三) 05:00 (UTC),且本篇討論始於2023年12月7日已逾一個月,依據WP:1MONTH,因此視為已達成共識,準備開始公示。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月10日 (三) 05:37 (UTC)
- 公示7日,公示說明。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月10日 (三) 05:37 (UTC)
- 由於相依性, 公示延長至《Wikipedia:互助客棧/其他#提案已通過請求佈署》佈署的三日後。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月16日 (二) 15:36 (UTC)
- 《Wikipedia:互助客棧/其他#提案已通過請求佈署》佈署已逾時三日;公示期內位於Template_talk:WPBannerMeta#編輯請求_2024-01-08的合理意見可以透過下方議案《通用評級規範》來解決,且該議案已獲初步共識並進入公示階段(詳見此說明),故可以預見該問題將被解決,故此案應可通過;但為了謹慎起見,公示再延三日,若三日內沒有合理異議則視本案為通過。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月21日 (日) 13:05 (UTC)
- 本討論已關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
第三階段:完善制度[編輯]
- 下列討論已經關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
在Template_talk:WPBannerMeta#編輯請求_2024-01-08中有人認為需要給通用評級訂一個「能填寫甚麼級別」的標準來避免爭議,因此立了草案Wikipedia:通用評級如下:
- 若一條目沒有專題或不受任何專題管轄,則其通用評級可填寫任意有被{{WikiProject banner shell}}支援的級別,僅要該條目有達到該級別的標準或滿足該級別的條件,都可以評。
- 若一條目僅有一個專題,其通用評級應與該專題所評的等級一致。
- 若一條目有多個專題,通常由機器人自動依照規則4進行評級,但一旦出現爭議時則通用評級應以所有專題都有開設的級別為主。
- 例如:若一條目有四個專題,而有一個專題沒有開設「丙級列表級」,那麼通用評級就不得填寫「丙級列表級」
- 對於有多個專題的條目,通用評級應填寫最多專題評的那一等級。
- 例如有一個條目有四個專題,其中三個專題都評為乙級,但有一個專題評為丙級,則通用評級應填寫乙級。
- 若在規則4的情況牴觸規則3,則應填寫與對應級別最接近的且滿足規則3的級別。
- 例如有一個條目有四個專題,其中三個專題都評為「丙級列表級」,但有一個專題評為「列表級」且這個專題不開設「丙級列表級」。依據規則3,最多專題評的級別是「丙級列表級」,但有一個專題不開設「丙級列表級」,則通用評級應填寫與「丙級列表級」最接近且位於該條目所有專題都有開設的級別,也就是「列表級」。
- 「最接近的級別」應該向下填寫,例如未啟用乙級的專題,通用級別遇到規則3判為乙級的情況時,則向下填寫為丙級。如果丙級也有專題未開設,就再向下填寫為初級。如遇到無法評級的情況,該通用評級模板就該留空。
提議將之升為指引,不曉得各位覺得如何?@Ma3r、Kanashimi、Z7504、桐生ここ:@Kethyga、暁月凛奈、MilkyDefer、Milkypine、Willy1018:-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月14日 (日) 09:44 (UTC)
- 實作上是否能讓那些沒開設大宗評級(數量最多專題)的在專題橫幅內設定好參數即可?這樣看起來就不會因為沒開設評級、被覆蓋而出問題。機器人很難判別每個專題開設的評級,因此條件3會讓讓機器人無法自動作業。
- 僅供參考,就enwiki來說,純粹只考慮數量最多的評級。採用特殊評級的專題橫幅有特殊分類,機器人處理時不會動到其評級。--Kanashimi(留言) 2024年1月14日 (日) 10:35 (UTC)
- @Kanashimi:技術上不能讀取評級模板的
|QUALITY_SCALE=
內容和/class子頁面嗎?如果|QUALITY_SCALE=
填subpage,讀取/class子頁面就能得知該專題哪些評級有啟用。例如{{多面體專題}}是|QUALITY_SCALE=subpage
,所以讀取Template:多面體專題/class原始碼即可得到哪些級別是yes、哪些級別是no。如果|QUALITY_SCALE=
填extended則是定義於{{Class mask/extended}}的級別。未填或standard就是只使用大宗評級。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月14日 (日) 11:00 (UTC) - 如果改成「若一條目有多個專題,通常由機器人自動依照規則4進行評級,但一旦出現爭議時則通用評級應以所有專題都有開設的級別為主。」機器人會不會好辦一點?意為機器人填寫值優先,但如果是人工評級時,才須考慮是否所有專題都有開設,且是遇到爭議之時,這是為了解決「
但是如果有人說「根據Wikipedia:條目質量評級標準#非標準級別和一些專題評CL的慣例,這篇列表內容充分,儘管支援條目的專題都沒有設CL級別,但既然WPBS能評CL那我就評CL」呢?所以,這個評級的定位該怎麽看?您作出了如此複雜的功能,但如果因爲使用規則不完善而部署而引發爭議,相信這是您不願意見到的。
」所描述的爭議情境。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月14日 (日) 11:06 (UTC)- @A2569875 現在cewbot採用的方式是選出最大宗的評級(數量最多的評級),填入{{WPBS}}並且移除所有相同的評級。所有不同的評級都保留不動。不曉得這樣的作業方式是否會產生問題?--Kanashimi(留言) 2024年1月14日 (日) 11:16 (UTC)
- @Kanashimi:技術上不能讀取評級模板的
- 我在療養,您自己請便。由於這個事情的業務邏輯挺複雜的,我不會攔着你用什麼樣的Lua。--MilkyDefer 2024年1月14日 (日) 12:48 (UTC)
- 已逾一周沒有任何發言,根據WP:7DAYS,七日無新留言視為已達成初步共識,因此將準備進行公示。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月21日 (日) 12:54 (UTC)
- 公示7日-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月21日 (日) 12:54 (UTC)
公示已逾七日,公示期已過,期內無合理異議,因此提案通過。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月29日 (一) 03:28 (UTC)
- 本討論已關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
臨時動議:關於基礎條目的額外提議[編輯]
|vital=
參數》案。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月29日 (一) 05:36 (UTC)- 下列討論已經關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
- 似乎已有共識,跟隨enwiki改版之後會由機器人自動完成:對各種專題橫幅不再個別指定 class,而是統一置於{{WPBS}}。
- 跟隨enwiki改版之後會由機器人自動完成:將{{WikiProject Biography}}的 'living', 'blp', 'BLP', 'activepol', 'blpo', 'listas' 等參數皆改以{{WPBS}}處理,
- 跟隨enwiki改版之後會由機器人自動完成:將{{Vital article}}併入{{WPBS}}
這邊最近在幫忙enwiki自動化這過程。這邊將申請自動更新Wikipedia:基礎條目所有子頁面的圖示(這部分最近測試中,已趨穩定。),以及定期維護{{WPBS}}(將各種專題橫幅併入{{WPBS}}並維護 'class', 'living', 'blp', 'BLP', 'activepol', 'blpo', 'listas'等相關參數)。不知大家對此是否有建議? --Kanashimi(留言) 2024年1月2日 (二) 09:53 (UTC)
enwiki近期改版{{WikiProject banner shell}},
- 對各種專題橫幅不再個別指定 class,而是統一置於{{WPBS}}。
- 將{{WikiProject Biography}}的 'living', 'blp', 'BLP', 'activepol', 'blpo', 'listas' 等參數皆改以{{WPBS}}處理,
- 將{{Vital article}}併入{{WPBS}}
這邊最近在幫忙enwiki自動化這過程,並且將定期維護。想請教大家對上幾種改變的贊否。
另這邊將申請自動更新Wikipedia:基礎條目的圖示(這部分最近測試中,已趨穩定。),以及維護{{WPBS}}(將各種專題橫幅併入{{WPBS}})。不知大家對此是否有建議?
副知User:Ma3r、User:Ericliu1912--Kanashimi(留言) 2024年1月2日 (二) 06:11 (UTC)
- 其實個人早已注意到相關更新,只是苦於自身技術實力不足而未能協助,樂見在充分確保相容性的情況下跟進。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年1月2日 (二) 06:21 (UTC)
- (+)支持全部。--Ma3r(鐵塔) 2024年1月2日 (二) 06:25 (UTC)
- @Kanashimi:可是這個即將公示通過了耶Wikipedia:互助客棧/其他#Random_Thought:_跟進英維的WikiProject_banner_shell改版。這個預計會先上架,這邊去年年底弄了從{{WPBS}}讀取評級到專題橫幅的模組Module:PJBSClass,你是要讓我做白工嗎?-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月2日 (二) 09:30 (UTC)
- 唉呀感謝提醒我沒注意到。看起來改版是已經有共識的結果了。我把建議移到那個討論串下好了,這邊可以關閉了。--Kanashimi(留言) 2024年1月2日 (二) 09:37 (UTC)
- Eric Liu 創造は生命(留言・留名・學生會) 2024年1月3日 (三) 04:47 (UTC)
- 已遷移討論@Ma3r、Ericliu1912:(User:Kanashimi應該已經知道了)-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月3日 (三) 05:51 (UTC)
您可以將整個討論移到其他區( ——
- Eric Liu 創造は生命(留言・留名・學生會) 2024年1月3日 (三) 04:47 (UTC)
- 唉呀感謝提醒我沒注意到。看起來改版是已經有共識的結果了。我把建議移到那個討論串下好了,這邊可以關閉了。--Kanashimi(留言) 2024年1月2日 (二) 09:37 (UTC)
- (:)回應:但上面的共識是「
可以單獨給條目一個總體的品質評級,各個WikiProject可以直接繼承這個quality assessment,也可以搞自己的評級。
」,代表雖然評級統一放在{{WPBS}},但仍然要允許個別專題能用自己的標準來搞自訂評級,所以應保留各專題橫幅的評級參數與功能。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月3日 (三) 04:57 (UTC)
- 是的,enwiki採w:en:Category:WikiProjects using a non-standard quality scale表示自訂評級的專題,bot亦已考慮此問題,在User:Cewbot/log/20200122/configuration有此項。待zhwiki完成部署,填好User:Cewbot/log/20200122/configuration便可apply。--Kanashimi(留言) 2024年1月3日 (三) 07:08 (UTC)
- (:)回應:@Kanashimi:我指的是可能會有專題有自己的標準,導致評級值與{{WPBS}}不同的情況(如可能有些專題的乙級比較嚴格,導致該專題只能評丙級,但WPBS是乙級,其他專題也是乙級),而非「非標準評級」(non-standard quality)的情況。雖然兩者都需要保留著各專題橫幅模板的評級class參數。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月3日 (三) 07:26 (UTC)
- 是的,w:en:Category:WikiProjects using a non-standard quality scale包含您所提的這兩種非正規、不繼承的狀況。--Kanashimi(留言) 2024年1月3日 (三) 07:47 (UTC)
- Category:使用自訂專題評級的條目,我是指「一個頁面的評級」滿足「不繼承、非正規」的狀況,不是「專題橫幅自己」滿足「不繼承、非正規」的條件。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月3日 (三) 09:41 (UTC)
- 或許我們該用Category:使用非正規質量評級的專題橫幅?至於您說的「一個頁面的評級」很抱歉我不太理解,是否能舉個例子呢?--Kanashimi(留言) 2024年1月3日 (三) 11:34 (UTC)
- (:)回應:@Kanashimi:Category:使用自訂專題評級的條目裡面的頁面就是「一個頁面的評級」滿足「不繼承」的狀況。Category:使用自訂專題評級的條目指的是「考慮一個已使用{{WPBS}}指定評級為X的條目,其有至少一個專題橫幅評級值為Y,或不為{{WPBS}}指定的X」,而考察w:en:Category:WikiProjects using a non-standard quality scale分類內都是「專題橫幅模板」本身,我猜它是指「允許『不繼承、非正規』評級的橫幅」,而不是條目評級的「個例」;而Category:使用自訂專題評級的條目是指「已經『不繼承、非正規』評級的頁面」的「個例」而非橫幅模板本身。我想你有所誤解,我希望是元模板都保留
|class=
參數,讓專題自己決定要怎麼送值,然後預社會繼承,這樣的話我們就不需要Category:使用非正規質量評級的專題橫幅分類。也就是說,本地的狀況宜以條目個例來看,而非以專題為單位來看。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月3日 (三) 11:43 (UTC)- 假如我沒有理解錯,您的意思是就您看來,zhwiki採用因地制宜的條目追蹤Category會比較好,因此您建議的是Category:使用自訂專題評級的條目而非Category:使用非正規質量評級的專題橫幅?--Kanashimi(留言) 2024年1月3日 (三) 11:49 (UTC)
- 另外這兩個追蹤的標的不同,一個是專題橫幅,一個是條目,我建議先取消d:Q122718872的連結。--Kanashimi(留言) 2024年1月3日 (三) 11:52 (UTC)
- d:Specail:Diff/2044308721已取消。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月3日 (三) 11:56 (UTC)
- (:)回應:@Kanashimi:是的,根據我的觀察,我認為中文維基環境宜用Category:使用自訂專題評級的條目(因為人手較少,很多專題都是不活躍或單人專題,因此中維的關注點以條目居多,故追蹤分類追蹤條目很符合邏輯),且Patch已寫好,已使用少量條目測試,目前運作正常,預計會先跟上面的patch一起佈署。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月3日 (三) 11:54 (UTC)
- enwiki採用這種方法的過程與部分考量可參考w:en:Template talk:WikiProject banner shell#Issue with assessments not applying to WikiProject Lists template,關乎Special:PageAssessments。就我最近的測試,有些模板如您所述
有些專題的乙級比較嚴格,導致該專題只能評丙級,但WPBS是乙級,其他專題也是乙級
,更有像w:en:Template:WikiProject Military history模板本身有額外採用class參數的代碼,這些模板本來就該與採用一般正規評級的模板分開。因此我會建議保留Category:使用非正規質量評級的專題橫幅這部分的功能,輔以Category:使用自訂專題評級的條目的patch。--Kanashimi(留言) 2024年1月3日 (三) 12:06 (UTC)- 目前的patch是對所有的專題橫幅全面保留
|class=
參數,只是設定未輸入時會從WPBS讀取評級值,也就是預設繼承,也就是說,所有專題橫幅模板都可以繼承或覆蓋,因為是所有的橫幅都可以覆蓋,所以Category:使用非正規質量評級的專題橫幅對於「不繼承評級」沒有意義。共識也有說要在最大相容的情況下佈署,所以我主張要盡可能保留原本的功能,即每個專題橫幅模板都能自訂評級,這是原本的情況,新共識是保留原本情況額外加上可以繼承評級的功能,且符合共識的patch也就緒了,您的意思看起來好像要取消專題橫幅預設都可以獨立評級、不繼承評級,我(-)反對如此作法,我主張應對所有專題(○)保留可覆蓋評級的功能,就像你程式的類別成員函數預設都是可以繼承或複寫Override的啊,怎麼會有預設是不准Override的情況?因此我反對預設關閉橫幅不繼承評級之功能,反正現在的patch已經是預設繼承WPBS之評級的情況,對專題橫幅元模板保留「允許不繼承評級」功能無傷大雅。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月4日 (四) 04:20 (UTC)- 我了解您的意思了。enwiki現在也是預設繼承,允許Override但會被列入w:en:Category:Articles with conflicting quality ratings。那邊的想法似乎是除非退出,否則應採用同一評級。我建議還是保留專題橫幅退出的餘地,畢竟有些專題橫幅就是比較特別。
- 就現在的機器人實作方法,zhwiki應該不會有問題。專題橫幅模板的質量評級若與{{WPBS}}相同,將會被移到{{WPBS}}。若與{{WPBS}}不同則會保留。--Kanashimi(留言) 2024年1月4日 (四) 06:05 (UTC)
- 目前的patch是對所有的專題橫幅全面保留
- enwiki採用這種方法的過程與部分考量可參考w:en:Template talk:WikiProject banner shell#Issue with assessments not applying to WikiProject Lists template,關乎Special:PageAssessments。就我最近的測試,有些模板如您所述
- 例如Talk:康威多面體裡面{{WPBS}}指定了
|class=stub
,但{{多面體專題}}指定了|class=start
蓋掉了{{WPBS}}的|class=stub
,因此被自動加入Category:使用自訂專題評級的條目分類。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月3日 (三) 11:46 (UTC)
- (:)回應:@Kanashimi:Category:使用自訂專題評級的條目裡面的頁面就是「一個頁面的評級」滿足「不繼承」的狀況。Category:使用自訂專題評級的條目指的是「考慮一個已使用{{WPBS}}指定評級為X的條目,其有至少一個專題橫幅評級值為Y,或不為{{WPBS}}指定的X」,而考察w:en:Category:WikiProjects using a non-standard quality scale分類內都是「專題橫幅模板」本身,我猜它是指「允許『不繼承、非正規』評級的橫幅」,而不是條目評級的「個例」;而Category:使用自訂專題評級的條目是指「已經『不繼承、非正規』評級的頁面」的「個例」而非橫幅模板本身。我想你有所誤解,我希望是元模板都保留
建好後,發現好像跟你說的不是一個東西? - 或許我們該用Category:使用非正規質量評級的專題橫幅?至於您說的「一個頁面的評級」很抱歉我不太理解,是否能舉個例子呢?--Kanashimi(留言) 2024年1月3日 (三) 11:34 (UTC)
- Category:使用自訂專題評級的條目,我是指「一個頁面的評級」滿足「不繼承、非正規」的狀況,不是「專題橫幅自己」滿足「不繼承、非正規」的條件。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月3日 (三) 09:41 (UTC)
- 是的,w:en:Category:WikiProjects using a non-standard quality scale包含您所提的這兩種非正規、不繼承的狀況。--Kanashimi(留言) 2024年1月3日 (三) 07:47 (UTC)
- WPBS}}能自動判斷評級的情況嗎?此時,{{WPBS}}不會有輸入任何
|class=
參數,也不必輸入|class=
,因為它是自動判定,例如Talk:2J(請看此版本的原始碼)。甚至還能傳遞給內層專題橫幅讓專題橫幅繼承這個「沒有輸入」的評級級別,例如Talk:二側錐五角柱(請看此版本原始碼)和Talk:五複合半刻面立方體(請看此版本原始碼),bot有考慮到這種{{WPBS}}未輸入|class=
參數,但能產生結果的狀況嗎?-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月3日 (三) 10:21 (UTC)- 機器人基本上不會動這種類型的 {{WPBS}}。另外依照MSGJ在w:en:Wikipedia:Bots/Requests for approval/Qwerfjkl (bot) 24的說法,「We have changed the logic so it is impossible to rate a non-article with an article quality rating.」,也就是這類型的問題會由Module:Banner shell處理。--Kanashimi(留言) 2024年1月3日 (三) 11:44 (UTC)
那您的bot有考慮到{{
- (:)回應:@Kanashimi:我指的是可能會有專題有自己的標準,導致評級值與{{WPBS}}不同的情況(如可能有些專題的乙級比較嚴格,導致該專題只能評丙級,但WPBS是乙級,其他專題也是乙級),而非「非標準評級」(non-standard quality)的情況。雖然兩者都需要保留著各專題橫幅模板的評級class參數。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月3日 (三) 07:26 (UTC)
- 整理一下目前共識:
- {{PJBS}}設立通用評級,可以統一管理同一條目的所有專題評級(已公示通過)
- 確保最大相容性的前提下跟進英文維基的相關功能
- 專題橫幅看各專題意願,評級可以選擇統一放置於{{PJBS}}也可以自行輸入
- 未輸入評級的專題橫幅以繼承載於{{PJBS}}的評級值為主,會優先採用載於{{PJBS}}的評級值
- 如頁面能自動判斷評級則無論輸入什麼評級,都要以自動判斷的評級為優先(原始來自這則留言,後續有在上方簡單討論);另有設定參數能複寫此設定。
- 'living', 'blp', 'BLP', 'activepol', 'blpo', 'listas'已併入{{PJBS}},但是否廢除{{WikiProject Biography}}內的'living', 'blp', 'BLP', 'activepol', 'blpo', 'listas'還有待討論
- {{WPBS}}已經加入{{Vital article}}的所有參數,但是否要用{{WPBS}}取代{{Vital article}}還有待討論
我有不同意見。英維的WPBannerMeta模組有很長一大坨代碼都是在處理這個Vital Article的事情;具體來說,他們把校驗這個Vital Article是不是真的Vital Article什麼的邏輯全部寫進去了。這一坨東西讓可維護性和可讀性(有可能還有效率)遭到了重大影響。我認為這更適合由一個外部機器人維護,而不是剝削這個已經很折磨人的Lua。 --MilkyDefer 2024年1月14日 (日) 12:53 (UTC)
- 我的建議方案是,
|vital=
參數可以存在,但是只有UI作用,由一個外部的機器人進行監察和更新操作。--MilkyDefer 2024年1月14日 (日) 12:55 (UTC)- 若能簡單改enwiki的程式碼來用,或許不必擔心折騰的問題。另一方面假如只留UI功能的話,是否乾脆維持原來的{{Vital article}}就好?--Kanashimi(留言) 2024年1月14日 (日) 13:06 (UTC)
- Module:Vital_articles都已經分成類似雜湊表查詢了,有甚麼折騰的問題?已經高效率優化了好嗎。理論上,此實現的記憶體開銷甚至有望低於英文維基,因為英文維基只分成27個表,而中文維基是36個表,代表中文維基每個表的項目數量更少,在類似散列函數計算之後,要讀取的JSON更小,表示記憶體用量更少,單個表項目更少表示查詢更快。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月14日 (日) 13:12 (UTC)
- @Kanashimi:Module:Vital_articles#L-216基本上就是英文維基的Code,我們已經簡單改enwiki的程式碼來用了,您似乎有所誤會,請自行對照Module:Vital_articles#L-216與en:Module:Banner_shell#L-90。而且您可以看到,本提案預計的作法已經把它下分到Module:Vital_articles去了,並不是像英文維基裡全部整坨塞WPBS模組,故不存在您所提的「可維護性和可讀性低」的問題,因為已經分門別類處理了:WPBS處理WPBS的任務、Vital articles處理Vital articles的任務,故上述疑慮不存在,杞人憂天。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月14日 (日) 13:14 (UTC)
- 是的,所以我想應該不至於有折騰的問題。--Kanashimi(留言) 2024年1月14日 (日) 13:17 (UTC)
- 不同意「剝削這個已經很折磨人的Lua」一說。您似乎保守過頭了。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月14日 (日) 13:16 (UTC)
- @MilkyDefer:而且一個頁面最多只會放置一個{{WPBS}}或{{Vital article}},代表該運算始終只會做一次,一個半秒內完成的運算只算一次,是要擔心甚麼效能問題?難道你想塞一萬個{{WPBS}}或{{Vital article}}在討論頁?-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月14日 (日) 13:20 (UTC)
- 我們用實際數據來說話吧。Special:PermaLink/80500375這是隨便測試6620個條目進行基礎條目判別,並輸出{{Vital article}}字串。
- 這6620個條目全部運算完畢在預覽模式下Lua的後台輸出為:
- Lua 使用時間:6.375/10.000 秒
- Lua 記憶體使用狀況:20,669,093/52,428,800位元組
- 跑6620次花6.375秒,平均每次基礎條目判斷僅需花費0.00096299093秒,也就是0.96299093毫秒,連1毫秒都不到。記憶體用量則是20,669,093 / 6620 = 3122.2194864,平均每個基礎條目判段僅需3122位元組,3.1kB,而可用的記憶體有52MB那麼多,更不用說這運算只算一次。你總共只需要 0.96 ms、3.12 kB,這甚至比其他很多模組有效率了好嗎。
- 一個1毫秒內完成的運算只算一次,是要擔心甚麼效能問題?我實在沒有辦法看出是要擔心哪門子的性能問題。既然一個基礎條目判段只需要不到1毫秒,那我認為你上面的「削這個已經很折磨人的Lua」完全是無稽之談,完全說不過去。Lua本身的目的就是要來降低維基代碼的開銷的,你隨便一個維基代碼解析都可能比我上面那個運算來的久。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月15日 (一) 05:28 (UTC)
- 已逾一周無新留言,因此根據WP:7DAYS,七日無進一步發言視為已達成初步共識;再依據WP:7DAYS「
已獲提案人正當合理的回應,且自該回應起計的3日後無進一步再回應,應視為該意見已解決。
」上方意見自最後發言起已逾三日無其他回應,因此視為該意見已解決,故將「將{{Vital article}}併入{{WPBS}}的|vital=
參數」視為已達成初步共識,預計將使用修改方案以及其佈署連結和測試樣例1、測試樣例2,以及(±)合併{{Vital article}}到{{WPBS}},來達成這個初步共識。既然依據WP:7DAYS已達成初步共識,那麼將準備進行公示。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月22日 (一) 05:31 (UTC)
- 已逾一周無新留言,因此根據WP:7DAYS,七日無進一步發言視為已達成初步共識;再依據WP:7DAYS「
- 這6620個條目全部運算完畢在預覽模式下Lua的後台輸出為:
- 公示7日,公示內容「將{{Vital article}}併入{{WPBS}}的
|vital=
參數」(同時執行方案①修改方案以及其佈署連結和方案②(±)合併{{基礎條目橫幅}}及{{Cba/discuss}}到{{WPBS}}(已由修改方案涵蓋)),另見此說明。(註:{{Vital article}}是重定向頁,亦會更改重定向目標)-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月22日 (一) 05:31 (UTC)
- 我們用實際數據來說話吧。Special:PermaLink/80500375這是隨便測試6620個條目進行基礎條目判別,並輸出{{Vital article}}字串。
- @Kanashimi:Module:Vital_articles#L-216基本上就是英文維基的Code,我們已經簡單改enwiki的程式碼來用了,您似乎有所誤會,請自行對照Module:Vital_articles#L-216與en:Module:Banner_shell#L-90。而且您可以看到,本提案預計的作法已經把它下分到Module:Vital_articles去了,並不是像英文維基裡全部整坨塞WPBS模組,故不存在您所提的「可維護性和可讀性低」的問題,因為已經分門別類處理了:WPBS處理WPBS的任務、Vital articles處理Vital articles的任務,故上述疑慮不存在,杞人憂天。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月14日 (日) 13:14 (UTC)
- Module:Vital_articles都已經分成類似雜湊表查詢了,有甚麼折騰的問題?已經高效率優化了好嗎。理論上,此實現的記憶體開銷甚至有望低於英文維基,因為英文維基只分成27個表,而中文維基是36個表,代表中文維基每個表的項目數量更少,在類似散列函數計算之後,要讀取的JSON更小,表示記憶體用量更少,單個表項目更少表示查詢更快。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月14日 (日) 13:12 (UTC)
- 若能簡單改enwiki的程式碼來用,或許不必擔心折騰的問題。另一方面假如只留UI功能的話,是否乾脆維持原來的{{Vital article}}就好?--Kanashimi(留言) 2024年1月14日 (日) 13:06 (UTC)
基礎條目模板合併案公示[編輯]
- 見公示聲明。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月24日 (三) 03:38 (UTC)
- @A2569875:我試過了,沒有什麼大問題,但建議WikiProject banner shell模板中的
BOTTOM TEXT
參數可以自動廢除了,不然如果還有發現這個參數的專題模板還要備註也真夠麻煩的。--Z7504非常建議必要時多關注評選(留言) 2024年1月22日 (一) 05:38 (UTC)
- @Z7504:請問WikiProject banner shell模板哪來的
BOTTOM TEXT
?你是不是弄錯了?WikiProject banner shell的原始碼內根本沒有你你提及的那種內容。你是否搞錯了什麼,還是誤會了什麼?-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月22日 (一) 05:44 (UTC)
- 還真的沒有,那應該誤會了。那這
BOTTOM TEXT
參數到底是從哪裡來的?該廢除的參數還是應該盡早廢除。基本上只剩下一個(?)疑問:是不是還要寫{{WPBS|class=xxx}}
才能讓其強制正常顯示?--Z7504非常建議必要時多關注評選(留言) 2024年1月22日 (一) 06:05 (UTC)
- @Z7504:顯示什麼?你是不是又誤會了?本次公示是針對基礎條目的參數,請問跟class到底有什麼關聯?-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月22日 (一) 06:12 (UTC)
- 這裡就是一個活生生的例子(比如這筆和這筆),這點小bug麻煩也先改了吧,不然都還要強制輸入才能確保正常顯示,問題不大才對。--Z7504非常建議必要時多關注評選(留言) 2024年1月22日 (一) 06:30 (UTC)
- @Z7504:這根本不是BUG,因為你如果沒有給WPBS模板輸入評級,它本來就不應該顯示任何評級,因為那代表「該條目沒有指定通用評級」,不顯示評級才是正常現象。再來是,所有維基媒體基金會旗下站點都沒有佈署能給跨模板傳遞資料的擴展,所以你輸入在專題模板的class當然無法被WBPS獲知,如果可以,那就是魔法或者見鬼了。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月22日 (一) 06:48 (UTC)
- 還有class處理的部分根本不在本案本次公示的處理及討論範圍內,強烈抗議強迫併案處理或企圖搞案外案的要求。然後還有上面說明的WPBS沒有辦法直接獲取輸入在專題模板的評級值。關於你的疑慮,等本案通過後User:Kanashimi會用機器人自動將專題模板的評級參數補給WPBS模板,故您也不需要手動給WPBS手動給評級。故您所提到的東西不予修復,因為屆時他會被Kanashimi的機器人自動處理。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月22日 (一) 06:58 (UTC)
- @Z7504 我稍後會申請將數量最多之評級填入{{WPBS}}的任務,基本效果就如同您上面所列的編輯。不曉得這是不是能解決您的問題呢?--Kanashimi(留言) 2024年1月22日 (一) 06:57 (UTC)
- @Z7504:這根本不是BUG,因為你如果沒有給WPBS模板輸入評級,它本來就不應該顯示任何評級,因為那代表「該條目沒有指定通用評級」,不顯示評級才是正常現象。再來是,所有維基媒體基金會旗下站點都沒有佈署能給跨模板傳遞資料的擴展,所以你輸入在專題模板的class當然無法被WBPS獲知,如果可以,那就是魔法或者見鬼了。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月22日 (一) 06:48 (UTC)
- 這根本不是需要修復的BUG。WPBS中
|class=
參數的填寫一開始就是設計要讓機器人自動維護的部分,讓模板自動處理此問題反而問題更多且不切實際,更適合由一個外部機器人進行監察和更新操作,因此該意見應視為對上方議案有所誤會所提出的意見,同時|class=
參數的填寫也與本案《將{{Vital article}}併入{{WPBS}}的|vital=
參數》毫無關聯,因此應無效,若三日內沒有異議或進一步回應,則視為該意見已解決。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月22日 (一) 08:40 (UTC)
- 總之全部都是Module:PJBSClass/main的問題,不鑲嵌模板就無法判斷,但「條目內掛了模板所以可以判斷」,您如果那麼清楚的話,那就直接建模板阿。標準的自欺欺人,結果居然是沒動腦過的回覆,被潑冷水真的剛好而已。這樣如何保證裡面可以不用寫上比如
|class=xxx
的參數,變成{{WPBS|collapsed=yes||class=xxx
還能讓它正常顯示?--Z7504非常建議必要時多關注評選(留言) 2024年1月22日 (一) 23:21 (UTC)- 不需要保證,因為機器人會自動填寫
{{WPBS|collapsed=yes||class=xxx
,保證的話等於和機器人搶工作,與本案背道而馳,因為該設計就是要給機器人維護的空間,如果沒有正面回答此陳述將視為無效。沒填寫|class=
顯示不一樣,反而還有能分辨機器人是否填過的功能,豈不是更好? 另,(!)抗議沒考量讀者體驗就亂講的提案,評級是面向編者的資訊,(-)強烈反對把評級寫在條目裡,故我認為目前的方案已是最適合的方案; 另,在此警告,在此案討論|class=
參數已離題。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月23日 (二) 01:24 (UTC)
- 不需要保證,因為機器人會自動填寫
- 總之全部都是Module:PJBSClass/main的問題,不鑲嵌模板就無法判斷,但「條目內掛了模板所以可以判斷」,您如果那麼清楚的話,那就直接建模板阿。標準的自欺欺人,結果居然是沒動腦過的回覆,被潑冷水真的剛好而已。這樣如何保證裡面可以不用寫上比如
- 這裡就是一個活生生的例子(比如這筆和這筆),這點小bug麻煩也先改了吧,不然都還要強制輸入才能確保正常顯示,問題不大才對。--Z7504非常建議必要時多關注評選(留言) 2024年1月22日 (一) 06:30 (UTC)
- @Z7504:我直接針對你最初的問題回答「
是不是還要寫
」,是,所以需要手動填上。本案並不包含甲乙丙初級自動判斷,公示也不包含這個部分,若你希望有甲乙丙初級自動判斷請另提他案,因為不在本案處理範圍內。 此外,你也無須擔心「{{WPBS|class=xxx}}
才能讓其強制正常顯示?是不是還要寫
」問題,因為下方Kanashimi已經申請機器人了,您無需手動填寫,此意見可以結案了。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月23日 (二) 01:44 (UTC){{WPBS|class=xxx}}
才能讓其強制正常顯示?
- 本公示不包含甲乙丙初級自動判斷,若三日後還在要求甲乙丙初級自動判斷將視為無效意見。若希望
|class=
沒輸入也能自動顯示甲乙丙初級請另外提案謝謝,不在本案有辦法處理的範圍內。「這點小bug麻煩也先改了吧,不然都還要強制輸入才能確保正常顯示,問題不大才對
」本案是處理基礎條目自動化,而不包含class有沒有輸入的問題,因此不在此案處理範圍內,請另提他案,謝謝。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月23日 (二) 02:02 (UTC)
- 還真的沒有,那應該誤會了。那這
- @Z7504:請問WikiProject banner shell模板哪來的
- @A2569875:我試過了,沒有什麼大問題,但建議WikiProject banner shell模板中的
- 見公示聲明。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月24日 (三) 03:38 (UTC)
已提出機器人作業申請,歡迎提供建議,謝謝。 --Kanashimi(留言) 2024年1月23日 (二) 01:38 (UTC)
- 您直接宣布通過就好了,不必再等三天,因為您全部都解釋完畢了,拒絕再溝通。另外有關Kanashimi所提議的機器人提案,沒有意見。如此的溝通是不可能會有共識的,別浪費時間了。您如果這麼愛寫新的條目,麻煩自己繼續寫條目就好,不要打擾了。因為維基百科的條目已經足夠多了,如果不想寫新的其實也沒差。因為設立A article、B article、C article、Start article、Stub article...這些模板也會有人有意見,但「不鑲嵌模板就無法判斷,掛了模板所以可以判斷」,怪誰啊?上面也講了您既然自己都知道是Module:PJBSClass/main影響的,但不去考慮修訂Module:PJBSClass/main,那麼就有設立這個機器人的必要。--Z7504非常建議必要時多關注評選(留言) 2024年1月23日 (二) 04:36 (UTC)
- 還有一點我要聲明,並不是不願意修訂module:PJBSClass/main,而是module:PJBSClass/main本來就是設計成要配合Kanashimi所提議的機器人提案而設計的,那麼要做的事情顯然是讓機器人提案推行順利,而不是去浪費時間修改module:PJBSClass/main。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月23日 (二) 05:06 (UTC)
公示期已到,期內無合理異議,且公示期內的意見之意見提出者已妥協,因此提案公示通過,將進行佈署。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月29日 (一) 05:36 (UTC)
- 本討論已關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
{{WikiProject Biography}}參數案[編輯]
- 下列討論已經關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
- 《將Vital_article併入WPBS的vital參數》案已進入公示,現就是否將{{WikiProject Biography}}的'living', 'blp', 'BLP', 'activepol', 'blpo', 'listas' 等參數併入{{WPBS}}進行討論。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月24日 (三) 03:41 (UTC)
- c.f. Wikipedia:機器人/申請/Cewbot/29。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月24日 (三) 03:43 (UTC)
- 本討論開始於2024年1月2日 (二) 09:53 (UTC)(發起討論的留言見此),當中包含了支持的意見,至今已逾一個月,因此根據WP:1MONTH「
互助客棧中的提案僅在7日內無新留言時或已討論達30日後,方可在已取得共識的前提下公示。
」,且本段落已逾8日無新留言,已超過一周無新留言,因此根據WP:7DAYS,有人附議此案(全部支持
視為該附議包含本案),而往後將近一個月沒有反對意見,因此視為已有初步共識,根據WP:1MONTH和WP:7DAYS將進行公示。(若三日無人對以上論述有異議將開始執行)-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年2月2日 (五) 09:57 (UTC)
公示到期,期內無合理異議,提案通過。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年2月13日 (二) 03:40 (UTC)
- 本討論已關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
是否廢除{{WikiProject Biography}}原生的'living', 'blp', 'BLP', 'activepol', 'blpo', 'listas' 等參數[編輯]
- 下列討論已經關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
待機器人User:Cewbot/log/20200122/configuration清理完所有{{WikiProject Biography}}的'living', 'blp', 'BLP', 'activepol', 'blpo', 'listas' 等參數再開始討論。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年2月13日 (二) 03:42 (UTC)
- 機器人User:Cewbot/log/20200122/configuration正在工作中。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年2月20日 (二) 08:21 (UTC)
- @Kanashimi:'living', 'blp', 'BLP', 'activepol', 'blpo', 'listas' 等參數併入{{PJBS}}好像未能達成共識,未看到有人支持也未有人反對,好像不符WP:共識標準?-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年3月12日 (二) 05:11 (UTC)
- 唉,看起來需要徵集些人發表意見...--Kanashimi(留言) 2024年3月12日 (二) 05:29 (UTC)
- 機器人這個算是已經併入了嗎?感覺只要{{WikiProject Biography}}能夠正常運作就可以了。--Kethyga(留言) 2024年3月16日 (六) 11:07 (UTC)
- @Kethyga:根據模板全保護方針,要把參數廢棄掉需要社群共識。何況這邊是要一次性地棄用超過5個參數。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年3月16日 (六) 11:09 (UTC)
- User:Kanashimi「
唉,看起來需要徵集些人發表意見
」,所以是要ping點人來嗎?-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年3月23日 (六) 05:20 (UTC)- 找一些最近發表意見的,以及{{WikiProject Biography}}最近的編輯者編輯者問問意見。
- @Kethyga @Willy1018 @Z7504 @AT @Shizhao @Iokseng 能夠給些意見嗎?謝謝。--Kanashimi(留言) 2024年3月23日 (六) 06:12 (UTC)
- 目前WPBS好像只有listas參數未傳遞到{{WikiProject Biography}},感覺也不一定要去掉,假如其他用戶添加專題模板的時候沒有用{{WPBS}},但是在{{WikiProject Biography}}添加了上述的幾個參數,該如何處理。--Kethyga(留言) 2024年3月23日 (六) 10:32 (UTC)
- 這種情況機器人會自動添加{{WPBS}}。--Kanashimi(留言) 2024年3月23日 (六) 11:11 (UTC)
- 目前WPBS好像只有listas參數未傳遞到{{WikiProject Biography}},感覺也不一定要去掉,假如其他用戶添加專題模板的時候沒有用{{WPBS}},但是在{{WikiProject Biography}}添加了上述的幾個參數,該如何處理。--Kethyga(留言) 2024年3月23日 (六) 10:32 (UTC)
- 還是說,修改「Category:缺少listas變量的傳記專題頁面」的判定條件?-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年3月30日 (六) 08:45 (UTC)
- 看了下該分類中的條目,排序應該是正常的,應該只有{{WPBS}}中參數listas為空的時候才加入該分類。--Kethyga(留言) 2024年3月30日 (六) 10:11 (UTC)
- Category:缺少listas變量的傳記專題頁面分類的添加,由{{WikiProject Biography}}轉移到{{WPBS}}如何?這樣就不用廢除{{WikiProject Biography}}的任何參數(如果廢除參數沒有共識)只是令{{WikiProject Biography}}不再添加Category:缺少listas變量的傳記專題頁面,改由{{WPBS}}判斷有無傳記專題模板,如果有,再根據listas變量的狀況增減分類。這部分的patch已經準備好了[2],如無異議可以公示了。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年3月31日 (日) 05:01 (UTC)
- 是否要跟英維保持一致呢,不知道是否有些人習慣將listas添加到{{WikiProject Biography}}上。--Kethyga(留言) 2024年4月5日 (五) 09:36 (UTC)
- 我覺得不用。而且Kanashimi也說機器人會自動將listas參數轉移到WPBS。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年4月5日 (五) 09:57 (UTC)
- 應該問題不大,反正使用評級的也不多,而且BLP參數也轉移過去了。--Kethyga(留言) 2024年4月6日 (六) 07:32 (UTC)
- 那我就公示《Category:缺少listas變量的傳記專題頁面改由{{WPBS}}加入》囉,距離提出已經一周,整個討論超過一個月,有關意見也已解決。至於參數是否廢除目前就作為尚無共識結以待續,因為這一案90%以上完成佔據客棧太久了,待《Category:缺少listas變量的傳記專題頁面改由{{WPBS}}加入》公示若通過後就先存檔,參數廢除案擇日再議。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年4月6日 (六) 08:18 (UTC)
- 應該問題不大,反正使用評級的也不多,而且BLP參數也轉移過去了。--Kethyga(留言) 2024年4月6日 (六) 07:32 (UTC)
- 我覺得不用。而且Kanashimi也說機器人會自動將listas參數轉移到WPBS。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年4月5日 (五) 09:57 (UTC)
不然這樣好了,我把 - 是否要跟英維保持一致呢,不知道是否有些人習慣將listas添加到{{WikiProject Biography}}上。--Kethyga(留言) 2024年4月5日 (五) 09:36 (UTC)
- Category:缺少listas變量的傳記專題頁面分類的添加,由{{WikiProject Biography}}轉移到{{WPBS}}如何?這樣就不用廢除{{WikiProject Biography}}的任何參數(如果廢除參數沒有共識)只是令{{WikiProject Biography}}不再添加Category:缺少listas變量的傳記專題頁面,改由{{WPBS}}判斷有無傳記專題模板,如果有,再根據listas變量的狀況增減分類。這部分的patch已經準備好了[2],如無異議可以公示了。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年3月31日 (日) 05:01 (UTC)
- 看了下該分類中的條目,排序應該是正常的,應該只有{{WPBS}}中參數listas為空的時候才加入該分類。--Kethyga(留言) 2024年3月30日 (六) 10:11 (UTC)
- User:Kanashimi「
- @Kethyga:根據模板全保護方針,要把參數廢棄掉需要社群共識。何況這邊是要一次性地棄用超過5個參數。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年3月16日 (六) 11:09 (UTC)
- 機器人這個算是已經併入了嗎?感覺只要{{WikiProject Biography}}能夠正常運作就可以了。--Kethyga(留言) 2024年3月16日 (六) 11:07 (UTC)
- 唉,看起來需要徵集些人發表意見...--Kanashimi(留言) 2024年3月12日 (二) 05:29 (UTC)
- 本討論已關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
Category:缺少listas變量的傳記專題頁面改由{{WPBS}}加入[編輯]
- 下列討論已經關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
公示7日如上留言,內容已經準備好了[3]。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年4月6日 (六) 08:20 (UTC)公示期滿,期內無合理異議,提案通過。將提出編輯請求。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年4月13日 (六) 09:03 (UTC)- @Shizhao:為什麼要回退?不是公示通過了?你為何要強行阻止提案通過??你是要這個議案卡死多久???請立刻說明理由!!-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年4月16日 (二) 03:39 (UTC)
- 兩個疑問:不用wpbs,直接用了傳記專題模板的怎麼辦?機器人停擺了怎麼辦?--百無一用是書生 (☎) 2024年4月16日 (二) 06:37 (UTC)
- @Kanashimi:如果一般用戶把參數加到傳記專題模板,且不放置WPBS模板時,有配套措施嗎?雖然你說這種情況機器人會自動加入WPBS模板,但我看你的機器人好像沒法做到那麼「即時」的更新?您對此情況有什麼看法?-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年4月16日 (二) 08:01 (UTC)
- 現在應該每個禮拜會執行一次。若是有必要也可以改成每天執行。--Kanashimi(留言) 2024年4月16日 (二) 22:53 (UTC)
- 不能WPBS和傳記專題模板兩套參數並行麼?--百無一用是書生 (☎) 2024年4月19日 (五) 03:34 (UTC)
- 現在的傳記專題模板,沒辦法得知頁面中是否已掛上WPBS。如果要並存,需要再寫一個程式讓傳記專題模板「認知到WPBS模板存在與否」。如果傳記專題模板能「認知到WPBS存在」那就可以把在無WPBS時加分類、有WPBS不加分類。所以,如果要實現的話,就必須寫程式讓傳記專題模板能識別WPBS的存在與否。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年4月19日 (五) 03:56 (UTC)
- @Shizhao:en:special:diff/1156304191看起來好像還挺簡單的?但需另外引入en:Template:Find page text。且此diff無須編輯{{WPBS}}即能解決問題-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年4月19日 (五) 04:48 (UTC)
- 現在的傳記專題模板,沒辦法得知頁面中是否已掛上WPBS。如果要並存,需要再寫一個程式讓傳記專題模板「認知到WPBS模板存在與否」。如果傳記專題模板能「認知到WPBS存在」那就可以把在無WPBS時加分類、有WPBS不加分類。所以,如果要實現的話,就必須寫程式讓傳記專題模板能識別WPBS的存在與否。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年4月19日 (五) 03:56 (UTC)
- 不能WPBS和傳記專題模板兩套參數並行麼?--百無一用是書生 (☎) 2024年4月19日 (五) 03:34 (UTC)
- (?)疑問:@Kanashimi:那麼Shizhao說的「機器人停擺了怎麼辦」,這部分有解方嗎?-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年4月18日 (四) 14:59 (UTC)
- 程式碼開源,真出問題其他人可接手。--Kanashimi(留言) 2024年4月18日 (四) 21:46 (UTC)
- 我的意思是儘可能能夠保留/提供一種不必依賴機器人(對人類友好)的方式,這樣即使沒了機器人也可以依靠手工維護--百無一用是書生 (☎) 2024年4月19日 (五) 03:32 (UTC)
- 現在應該每個禮拜會執行一次。若是有必要也可以改成每天執行。--Kanashimi(留言) 2024年4月16日 (二) 22:53 (UTC)
- @Kanashimi:如果一般用戶把參數加到傳記專題模板,且不放置WPBS模板時,有配套措施嗎?雖然你說這種情況機器人會自動加入WPBS模板,但我看你的機器人好像沒法做到那麼「即時」的更新?您對此情況有什麼看法?-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年4月16日 (二) 08:01 (UTC)
- 兩個疑問:不用wpbs,直接用了傳記專題模板的怎麼辦?機器人停擺了怎麼辦?--百無一用是書生 (☎) 2024年4月16日 (二) 06:37 (UTC)
- @Shizhao:為什麼要回退?不是公示通過了?你為何要強行阻止提案通過??你是要這個議案卡死多久???請立刻說明理由!!-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年4月16日 (二) 03:39 (UTC)
- 管理員在嘗試執行通過的提案時發現潛在問題,先前並未考慮到此問題,故此案公示結果 擱置。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年4月16日 (二) 07:42 (UTC)
- 本討論已關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
Category:缺少listas變量的傳記專題頁面方案二[編輯]
- 這個en:special:diff/1156304191可以解決上方Shizhao提出的問題,即由{{傳記專題}}自行偵測是否有其他模板(包括但不限於WPBS)提供了listas參數(上方提案內的patch的重複分類之參數
|living=
也可以依此方案執行)來決定是否加入分類。這種方法只需編輯一個模板——只需編輯{{傳記專題}}無須編輯{{WPBS}}——但要實行此方案須從enwiki引入一個模板:{{Find page text}},因此提請討論。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年4月19日 (五) 06:30 (UTC)- 由於此案為原案的修正(原案已公示通過),且一周無人有異議,視為有初步共識。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年4月26日 (五) 10:15 (UTC)
- 因需引入{{Find page text}},而引入{{Find page text}}已一周無異議,視為有初步共識。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年5月4日 (六) 07:27 (UTC)
- 公示7日-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年5月12日 (日) 02:54 (UTC)
- 公示期間已過,期內無合理異議-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年5月19日 (日) 09:01 (UTC)
- 已約一周無人對「
公示期間已過,期內無合理異議
」有異議,因此公示通過,提案通過,將開始引入{{Find page text}},而引入{{Find page text}}。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年5月26日 (日) 01:38 (UTC)
- 已約一周無人對「
- 公示期間已過,期內無合理異議-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年5月19日 (日) 09:01 (UTC)
- 公示7日-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年5月12日 (日) 02:54 (UTC)
- 因需引入{{Find page text}},而引入{{Find page text}}已一周無異議,視為有初步共識。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年5月4日 (六) 07:27 (UTC)
- 由於此案為原案的修正(原案已公示通過),且一周無人有異議,視為有初步共識。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年4月26日 (五) 10:15 (UTC)
- {{Find page text}}引入成功。已為新方案建立Patch,Special:Diff/82875808,並且經過測試Special:Diff/82875855,測試為有效,能正確地實現本案《Category:缺少listas變量的傳記專題頁面改由{{WPBS}}加入》的預期效果。且由於其判定的方式,該參數得以保留,並且達到預期效果,因而解決了User:Shizhao所提出的問題。本聲明放置一周,若無異議,將進行下一個階段。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年6月1日 (六) 10:47 (UTC)
- 說實話根本看不懂相關提案,也不知道從何評價Orz —— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月3日 (一) 02:32 (UTC)
- 因為這案子基本已經尾聲很久了,且最後一個項目也公示通過了,只是後來發生了點事情導致本案《Category:缺少listas變量的傳記專題頁面改由{{WPBS}}加入》需要「公示通過後再變更」。@Ericliu1912:簡單來講,本案就是要解決#臨時動議:關於基礎條目的額外提議,Kanashimi的User:Cewbot已經把{{WikiProject Biography}}的 'living', 'blp', 'BLP', 'activepol', 'blpo', 'listas' 等參數合併到{{WPBS}}處理,在機器人處理了幾十萬頁面後,發現這樣會造成{{WikiProject Biography}}和{{WPBS}}重複加上分類、或者是{{WikiProject Biography}}的有關參數已被機器人改到{{WPBS}}去了,{{WikiProject Biography}}變成沒有參數而導致分類誤加。為了解決此問題,於是誕生了議案《Category:缺少listas變量的傳記專題頁面改由{{WPBS}}加入》一案。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年6月7日 (五) 23:38 (UTC)
- 公示5日,如上所述,現將此案交付公示。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年6月10日 (一) 00:41 (UTC)
- @Shizhao:新方案看起來有共識了。新方案patch,同時解決了您說的①「直接用了傳記專題模板的怎麼辦」:本模板自動判斷家參數者是{{WPBS}}還是{{WikiProject Biography}},因此無論是用{{WPBS}}還是直接用了傳記專題模板都能正確加入分類、不會重複加、也不會多加(見測試);②「機器人停擺了怎麼辦」:不影響,因為機器人停擺了只是會導致加入在{{WikiProject Biography}}的參數維持在{{WikiProject Biography}},而根據①,分類能能正常加入,不會重複加、也不會多加(另見④);③「不能WPBS和傳記專題模板兩套參數並行麼」:可以,根據「①」和「②」可以很明顯看出,參數只放在{{WikiProject Biography}}沒問題、只放在{{WPBS}}也沒問題,甚至兩個都放也不成問題,因為根據①,分類能能正常加入,不會重複加、也不會多加;④「我的意思是儘可能能夠保留/提供一種不必依賴機器人(對人類友好)的方式,這樣即使沒了機器人也可以依靠手工維護」:是的,根據②,機器人停擺也仍能正常洽洽說明了⒈不必依賴機器人⒉沒了機器人也可以依靠手工維護(參考③);請您協助複查,感謝。如無誤,將再次提出編輯請求,感謝。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年6月16日 (日) 11:58 (UTC)
評級系統缺失問題[編輯]
- (原始標題為「將{{Classicon}}與{{Class/icon}}同步」配合公告欄調整標題。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月5日 (五) 07:47 (UTC))
配合上方#Random_Thought: 跟進英維的WikiProject_banner_shell改版因此需要解決評級系統缺失問題,故提出以下議案-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2023年12月25日 (一) 09:49 (UTC)
- 預計辦理流程:
- 修正評級系統被不當過濾掉的評級值: 公示通過已佈署
- 讓評級系統Special:頁面評級均能正確接收到評級值,以便讓{{WikiProject_banner_shell}}工作順利。
- 同步各模板/組的評級值: 公示通過已佈署
- 評級元模板調用了多個不同的評級值轉換模板,但各評級值轉換模板/組的評級值定義有所出入,將會影響{{WikiProject_banner_shell}}的運作,因此需要修正。
- 將{{Classicon}}與{{Class/icon}}同步: 公示通過已佈署
- 以上都完成後,目前評級系統的圖是在各評級定義模板/組不一致,且Style也不一致,為了與XTools也統一,故作出此提案。
- 一切完成之後,將會同時把評級規範立起來(即立WP:QUALITY)為指引,以便完善評級系統的所有缺失部分。
- 修正評級系統被不當過濾掉的評級值: 公示通過已佈署
- 目前先做到這樣,統整整個評級系統並修正評級系統缺失問題。若未來還有需要調整的會在辦理過程提出,滾動式修正,歡迎發表意見。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月5日 (五) 08:06 (UTC)
第一階段:修正評級值不同步問題[編輯]
議案1:將{{Classicon}}與{{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)
- @Shizhao:已提出編輯請求,Template_talk:WPBannerMeta/core#編輯請求_2023-12-28,處理完畢後未來之類的評級就能被支持了。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2023年12月28日 (四) 04:11 (UTC)
- (:)回應:@Shizhao:有支持,顯示評級的最後一個調用是{{WPBannerMeta/qualityscale/mask}},而{{WPBannerMeta/qualityscale/mask|future}}→「未來」,但在要送入
- 似乎未來之類的評級並未被整個評級系統完全支持?--百無一用是書生 (☎) 2023年12月28日 (四) 02:24 (UTC)
- 可以,但前者{{Classicon}}被全保護,只有管理員才能進行編輯,需要提{{ep}}。-- Willy1018(留言) 2023年12月26日 (二) 04:56 (UTC)
- (?)疑問:@Willy1018:那要不要{{Classicon}}重定向到{{Class/icon}}?剛才已補充{{Classicon}}所有功能到{{Class/icon}}了。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2023年12月26日 (二) 02:33 (UTC)
- (+)支持,沒特別的意見--Z7504非常建議必要時多關注評選(留言) 2023年12月28日 (四) 14:13 (UTC)
- 支持合併。不過純模板實現也不錯。--桐生ここ★[討論] 2023年12月28日 (四) 21:48 (UTC)
- @桐生ここ:完全不建議模板實現。現時模板實現是使用
{{#switch:}}
,您忘了2020年初{{#switch:}}
爆炸事件Special:PermaLink/58036835#A_technical_issue_with_articles_of_French_communes導致中維崩潰的事件了嗎。{{#switch:}}
的開銷要高於模組實現,所以建議使用模組實現,安全又有效率。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2023年12月29日 (五) 00:06 (UTC)- 這邊最近在處理基礎條目與{{WikiProject banner shell}}的圖示問題(Wikipedia:互助客棧/條目探討#引入enwiki近期{{WPBS}}之改版,暨將{{Vital_article}}併入{{WPBS}}),(&)建議直接採用{{Icon}}會更通用。--Kanashimi(留言) 2024年1月2日 (二) 09:18 (UTC)
- 但我覺得要有專題專用模板。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月2日 (二) 09:33 (UTC)
- 我想採用不同模板來處理同一件事的問題是較不易維護。--Kanashimi(留言) 2024年1月2日 (二) 09:49 (UTC)
- @Kanashimi:問題是目前{{Icon}}並未完整涵蓋Class/icon現有內容。改用{{Icon}}將會導致部分圖是消失,或發生變化。我認為專題圖示應該要統一的Style,但例如{{Icon|image}}和{{Class/icon|image}}就不一致,而且{{Icon|image}}與以下圖示比較{{Class/icon|image}}、{{Class/icon|A}}、{{Class/icon|B}}、{{Class/icon|C}}明顯Style嚴重變調,故(-)反對。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月2日 (二) 10:13 (UTC)
- 或許我們可以擴展{{Icon}}使之涵蓋我們想要的範疇,例如採用
{{Icon|image_class}}
?--Kanashimi(留言) 2024年1月2日 (二) 10:20 (UTC)- @Kanashimi:我這個議案只是想先動全保護模板{{Classicon}},至少先同步圖示,但您目前這樣介入會導致共識亂了,連同不都做不到了,會導致花費更多「跑流程」時間,我想先同步,也做好patch了,都準備好了被你弄沒了?我想先動全保護模板{{Classicon}}至少先同步圖示;至於以後怎麼維護可以再討論。而且您的提議「
例如採用
」也還沒有patch,先現實一點吧,不要紙上談兵,我只想趕快同步圖示,並讓Style一致,評級圖示是評級圖示,其他圖示是其他圖示;評級圖示就該有評級圖示自己的Style,(!)抗議亂七八糟的不一致Style圖示。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月2日 (二) 10:29 (UTC){{Icon|image_class}}
- 也好。那就等這個討論結束再說吧。--Kanashimi(留言) 2024年1月2日 (二) 10:30 (UTC)
- @Kanashimi:問題2
{{Icon|image_class}}
會導致評級模板輸出的值無法直接輸入此模板。評級模板肯定是輸出字尾沒有「_class」的結果,你這樣搞還要多寫一個轉換器,不是更難維護?-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月2日 (二) 10:33 (UTC)- 我嘗試在Module:Icon/data加上下面的項目,似乎可以用?
- --Kanashimi(留言) 2024年1月2日 (二) 11:00 (UTC)
image_class = { image = "Symbol file class.svg", tooltip = "媒體文件頁", },
- @Kanashimi:我這個議案只是想先動全保護模板{{Classicon}},至少先同步圖示,但您目前這樣介入會導致共識亂了,連同不都做不到了,會導致花費更多「跑流程」時間,我想先同步,也做好patch了,都準備好了被你弄沒了?我想先動全保護模板{{Classicon}}至少先同步圖示;至於以後怎麼維護可以再討論。而且您的提議「
- 或許我們可以擴展{{Icon}}使之涵蓋我們想要的範疇,例如採用
- @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)
- 我想採用不同模板來處理同一件事的問題是較不易維護。--Kanashimi(留言) 2024年1月2日 (二) 09:49 (UTC)
- 但我覺得要有專題專用模板。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月2日 (二) 09:33 (UTC)
- 這邊最近在處理基礎條目與{{WikiProject banner shell}}的圖示問題(Wikipedia:互助客棧/條目探討#引入enwiki近期{{WPBS}}之改版,暨將{{Vital_article}}併入{{WPBS}}),(&)建議直接採用{{Icon}}會更通用。--Kanashimi(留言) 2024年1月2日 (二) 09:18 (UTC)
- @桐生ここ:完全不建議模板實現。現時模板實現是使用
- 此段落最後發言至今已逾七日,超過一周無新留言,因此根據WP:7DAYS準備進行公示。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月9日 (二) 12:56 (UTC)
- 公示7日-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月9日 (二) 12:56 (UTC)
- 請管理員編輯Template_talk:Classicon#編輯請求_2024-01-16。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月16日 (二) 13:19 (UTC)
- 本討論已關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
議案2:修正評級系統被不當過濾掉的評級值[編輯]
- 下列討論已經關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
上方User:Shizhao提到「未來級」等評級級別無法被完整支持問題,是因為送入評級系統的評級值被不當過濾掉了,即使專題上層已啟用該等評級,但最終還是會被「未繼承上層參數的{{class mask}}」過濾掉,這樣的話就算專題啟用了該等評級也沒有用,都被濾掉了,根本裝飾,白啟用了,因此提議將送入評級系統的評級值改為{{WPBannerMeta/qualityscale/mask}}模板,見編輯請求Template_talk:WPBannerMeta/core#編輯請求_2023-12-28,修改前後的比較Special:PermaLink/80307466,可以看到原有的版本評級值大部分都被濾掉了,建議換成提議的Patch,以讓「未來級」等評級級別能真正被支持。同時,我也確認值接送未來級能正確被工具識別,見右圖,連圖示都有,代表評級系統是支援此輸出的,能正確地被讀取並識別。
因此提出本動議。不曉得各位有沒有異議或意見。Ping參與過相關討論的人@桐生ここ、Z7504、Shizhao、Willy1018:,上方參與過評級討論的也Ping一下@暁月凛奈、Lopullinen、Milkypine、MilkyDefer:-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2023年12月31日 (日) 08:29 (UTC)
- 支持。( π )題外話:台灣之星的標識現在還沒改。--桐生ここ★[討論] 2023年12月31日 (日) 10:36 (UTC)
- 資慈,我覺得行。 --窩法乙烷 兒法夢碎 2024年1月1日 (一) 14:38 (UTC)
- 此段落最後發言至今已逾七日,超過一周無新留言,因此根據WP:7DAYS準備進行公示。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月8日 (一) 2024年1月8日 (一) 14:39 (UTC)
- 公示7日-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月8日 (一) 14:39 (UTC)
- 請管理員編輯Template_talk:WPBannerMeta/core#編輯請求_2023-12-28。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月15日 (一) 14:45 (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)
- (:)回應:@Z7504:其實我有私下找User:AT了,但他一直說影響範圍太大要先討論 囧rz…………。我當然也希望能直接改啊,不然WP:7DAYS獲共識再公示7天半個月就過去了……-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月1日 (一) 12:05 (UTC)
- 此段落最後發言至今已逾七日,超過一周無新留言,因此根據WP:7DAYS準備進行公示。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月8日 (一) 14:36 (UTC)
- 公示7日-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月8日 (一) 14:36 (UTC)
- 請管理員依照這則留言佈署相關編輯,也就是編輯以下模板:
- 本討論已關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
提案已通過請求佈署[編輯]
- 下列討論已經關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
- 全案公示通過,請管理員依據以下留言:
- 佈署相關編輯,也就是編輯以下模板:
- 本討論已關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
評級缺失問題目前辦理狀況[編輯]
截至2024年1月5日 (五) 17:08 (UTC)已提出三案討論,三案皆在等待初步共識,以便公示。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月5日 (五) 17:08 (UTC)
進度 | 討論中 | 初步共識 | 公示中 | 部署中 | 已完成 | 後續維運 |
---|---|---|---|---|---|---|
*通用評級設立 | 已獲共識 | 已通過 | 已完成 | 已完成 | 進行中 | |
*評級繼承機制 | 初步共識 | 公示通過 | 已完成 | 進行中 | ||
評級值同步 | 初步共識 | 公示通過 | 已完成 | 進行中 | ||
修正過度過濾評級值 | 初步共識 | 公示通過 | 已完成 | 進行中 | ||
評級圖示同步 | 初步共識 | 公示通過 | 已完成 | 進行中 | ||
完善評級系統規範 | 討論中 | 等待中 | ||||
註:標有「*」表示是其他相關提案。 |
- 完成:在本次更新中,以下模板的評級資料已獲同步:
- Template:評級
- Module:Class/definition.json
- Module:Class/data
- Module:Class/icon
- Module:Class/styles.css
- Template:Class/colour
- Template:Class mask
- Template:Class mask/core
- Template:Class mask/table
- Template:Class mask/templatepage
- Template:Articles by Quality
- Template:Articles by Quality/total
- phab:T360012(註:若下次要再變更,需要提交新工單)
第二階段:依據先前共識將不是條目命名空間的評級分類從「XX級條目」改為「XX級頁面」[編輯]
- 下列討論已經關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
根據先前共識,需要將不是條目命名空間的評級「XX級條目」的分類改為「XX級頁面」,但因技術限制未能將「XX級條目」的分類改為「XX級頁面」,因此本案已提出新的方案,依據頁面命名空間添加分類,以實現該共識。具體執行方案在Template:WPBannerMeta/qualityscale/sandbox。同時將Wikipedia:條目質量評級標準移動到Wikipedia:頁面質量評級標準,不知道各位有沒有異議?-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月17日 (三) 04:57 (UTC)
- 副知@Ma3r、Kanashimi、Z7504、桐生ここ:@Kethyga、暁月凛奈、MilkyDefer、Milkypine、Willy1018:-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月17日 (三) 04:58 (UTC)
- 沒有異議,
就是不知道會不會出現突發狀況。 --窩法乙烷 兒法夢碎 2024年1月17日 (三) 11:35 (UTC)- 已在多面體專題進行測試,詳見Category:分類級多面體頁面、Category:模板級多面體頁面,目前測試整個多面體專題尚未出現問題。待本案正式通過之後才會正式(►)移動分類頁面。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月17日 (三) 11:39 (UTC)
- 沒有意見,但在專題頁面(WikiProject)中使用到的{{Articles by Quality and Importance}}模板應一併解決顯示異常之問題(前幾天似乎還有這問題,現在不知道),雖然這模板平常根本沒什麼人在意 囧rz……(所以沒解決可能也沒差吧?因為專題本來就沒什麼人在意了)--Z7504非常建議必要時多關注評選(留言) 2024年1月18日 (四) 14:26 (UTC)
- 首先,結尾為「XX重要度」的分類不會移動,不在本計畫內,而{{Articles by Quality and Importance}}是讀取結尾為「XX級XX重要度」的分類,故基本上本案不會影響{{Articles by Quality and Importance}}。再來,如果這個真的要處理,要本案通過後,分類全部清理好,分類全數移動完成後才能處理,不然現在處理數字都會變成0。故應是下一個階段要處理的(或者共識是暫不處理),不是此案此階段討論範圍。此外,如果是{{Articles by Quality}}的話,直接更新分類名稱即可。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月18日 (四) 16:02 (UTC)
- 已逾一周無新發言,根據WP:7DAYS七日無進一步發言視為已獲初步共識,如本聲明無人有異議,將準備進行公示。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年1月26日 (五) 00:32 (UTC)
- 已逾十日無新發言,根據WP:7DAYS一周無進一步發言視為社群「對以上『已有初步共識』的論述」沒有異議,因此將開始公示。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年2月5日 (一) 10:00 (UTC)
- 公示7日-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年2月5日 (一) 10:00 (UTC)
- 本討論已關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
分類改名準備[編輯]
- 下列討論已經關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
雖Special:Diff/80961277已公示通過,但因涉及的頁面眾多,因此宜再進行全站公告。公告完後將進行兩個階段完成:
- 階段1:全保護頁面編輯請求:Template:WPBannerMeta/qualityscale和Template:Class
- 由於該等分類都是以上被全保護的模板自動添加的,因此需要執行以上編輯請求。等編輯請求完成後,數萬個頁面緩存自動清理完畢後,分類將自動從「XX級條目」改歸為「XX級頁面」。
- 階段2:正式(►)移動分類頁面(可能是約階段1完成後再過一周)
- 等緩存全部清完,再將「XX級條目」分類,逐個(►)移動到「XX級頁面」分類。
公告一周。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年2月13日 (二) 03:31 (UTC)
- 已提出編輯請求。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年2月25日 (日) 01:07 (UTC)
- 編輯請求已由User:Shizhao執行。 等待系統清除緩存。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年2月27日 (二) 13:22 (UTC)
- 系統緩存已清除完畢,但Wikipedia:互助客棧/求助#「Category:模板級條目」的分類是不是應該移動至「Category:模板級頁面」才對?有異議,因此移動作業暫時先暫緩一周,若下周二前沒有其他異議,才執行移動(本次實屬折騰,明明都WP:7DAYS+公示1周+公告1周+等待編輯請求與系統清除緩存,整個流程走了超過一個月,突然冒出異議到底是啥情況,而且該異議還跟本站無關。。。)。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年3月4日 (一) 03:50 (UTC)
- Wikipedia:頁面質量評級標準中標準級別都是針對條目的,只有非標準級別才有模板級、分類級這些評級,而且非條目命名空間的都不能評甲乙丙初之類的等級,所以評級主要針對的是條目。因此是否應當將其移回Wikipedia:條目質量評級標準,將頁面評級作為擴展(專題條目類別標準→專題頁面類別標準,需要修改{{Grading scheme}}),與Wikipedia:條目重要度評級標準統一。
- 此外,非條目頁面不應該設置重要度,所以Category:不適用重要度條目及其子分類也應一併移動至Category:不適用重要度頁面。--Kunjinkao(留言) 2024年3月8日 (五) 02:37 (UTC)
- @Kunjinkao:我提此延伸案的目的就是為了Wikipedia_talk:頁面質量評級標準#WP:QUALITY_升為指引,你現在越給我搞複雜,好啊WP:QUALITY永遠升不了指引都你害的。Category:XX重要度條目如果改名Category:XX重要度頁面]且有的有改有的沒改,那你判斷統計的模板將被複雜化,這從12月折騰到現在,我已經沒有心力了,中間又被Z7504搞,既然你要這樣,那我不管這個案子了,你自己想辦法。且公示都已經通過了,你又來個「公示通過後」異議,是甚麼鬼?專門故意折騰我的是不是?-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年3月8日 (五) 03:55 (UTC)
- @Kunjinkao:我近期沒有時間也沒有心力針對Module:Articles_by_Quality_and_Importance修改。「Category:不適用重要度條目及其子分類也應一併移動至Category:不適用重要度頁面」Module:Articles_by_Quality_and_Importance判斷將會變得複雜,如您希望「Category:不適用重要度條目及其子分類也應一併移動至Category:不適用重要度頁面」請您自己提出相應模板的修改patch。如無人提出,就會如Wikipedia_talk:條目質量評級標準#總結變成就算有共識也永遠不會實現,因為沒人寫程式。我自己的提案,我當然有義務寫完與該提案相關所需的程式碼,但並不意味著各種節外生枝我也需要幫忙寫程式,這樣根本沒完沒了。
- 本案先前早已公示7天通過+公告7天通過,在這之後冒出異議.....我實在不想評論如此行為。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年3月8日 (五) 04:11 (UTC)
- @Kunjinkao:您好,由於議案已公示通過,若您覺得議案還有不妥之處還請另起章節修正,此處不受理已通過之議案之再變更,謝謝。--SunAfterRain 2024年3月8日 (五) 04:35 (UTC)
- 我沒看到
結尾為「XX重要度」的分類不會移動,不在本計劃內
,以為這是提案的一部分。既然如此那就放在後面說吧--Kunjinkao(留言) 2024年3月8日 (五) 04:42 (UTC) - 至於{{Module:Articles_by_Quality_and_Importance}},先看看名稱以「Category:分类级不适用」開頭的所有分類、名稱以「Category:模板级不适用」開頭的所有分類該怎麼處理吧,這總該是分類改名共識的範疇吧。但我要說明一點,我是在指出實施時出現的問題,並不代表我想推翻共識。--Kunjinkao(留言) 2024年3月8日 (五) 05:34 (UTC)
- 我沒看到
- @Kunjinkao:我提此延伸案的目的就是為了Wikipedia_talk:頁面質量評級標準#WP:QUALITY_升為指引,你現在越給我搞複雜,好啊WP:QUALITY永遠升不了指引都你害的。Category:XX重要度條目如果改名Category:XX重要度頁面]且有的有改有的沒改,那你判斷統計的模板將被複雜化,這從12月折騰到現在,我已經沒有心力了,中間又被Z7504搞,既然你要這樣,那我不管這個案子了,你自己想辦法。且公示都已經通過了,你又來個「公示通過後」異議,是甚麼鬼?專門故意折騰我的是不是?-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年3月8日 (五) 03:55 (UTC)
- (►)移動作業進行中。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年3月12日 (二) 05:02 (UTC)
- (!)意見:絕大部分評級模板都指定了{{class}}的
category
參數,且都為「xx條目」,如此將導致非條目頁面的專題橫幅模板出現紅鏈。模板參數需要考慮重新設計,比如僅使用「xx」並由模板判定後綴。--PexEric 💬|📝 2024年3月16日 (六) 12:08 (UTC)
- 本討論已關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
第三階段:Wikipedia_talk:頁面質量評級標準#WP:QUALITY_升為指引[編輯]
本案最初的初衷就是完成此共識Wikipedia_talk:頁面質量評級標準#WP:QUALITY_升為指引,來完成WP:QUALITY_升為指引一事,來正式解決「評級系統缺失問題」(指引/規範未立也算是本系統的一種「缺失」)。等上方都完成,此處將繼續。聲明:當這些「缺失」都解決後,本人將不再碰評級系統這塊了,這燙手山竽真是消磨人的精神。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年3月8日 (五) 04:40 (UTC)
- 可能我上面沒說清楚,讓你以為我是反對分類改名的,更不是什麼
越給我搞複雜,好啊WP:QUALITY永遠升不了指引都你害的
,不能有問題不讓說是不是。總之是以下幾點:- 頁面重新命名為Wikipedia:條目質量評級標準:因為評級針對的是WP:條目,其它模板級、分類級這些評級都是非標準級別(WP:QUALITY就是這麼寫的),那麼頁面應當以標準評級針對的對象命名,也就是條目質量評級標準。
除非你打算搞什麼甲級模板級,那不是更複雜。此外還存在Wikipedia:條目重要度評級標準,那是否要改成Wikipedia:頁面重要度評級標準,總之得有一個要改 - 目前Wikipedia:條目重要度評級標準和Wikipedia:頁面質量評級標準是正交的,所以有Category:分類級低重要度宗教條目這種東西的存在,那是不是得命名成Category:分類級低重要度宗教頁面。既然分類級不屬於標準評級,因此也不必設置重要度,引入更多複雜性,這類頁面統統扔去Category:不適用重要度條目去(或者說Category:不適用重要度頁面)。
- {{Grading scheme}}修改,因為Wikipedia:頁面質量評級標準調用了,這個就是作為WP:指引用詞統一的問題
- 頁面重新命名為Wikipedia:條目質量評級標準:因為評級針對的是WP:條目,其它模板級、分類級這些評級都是非標準級別(WP:QUALITY就是這麼寫的),那麼頁面應當以標準評級針對的對象命名,也就是條目質量評級標準。
- --Kunjinkao(留言) 2024年3月8日 (五) 05:20 (UTC)
- 無論是前次討論還是本次討論,都沒有提到重要度,因此認為重要度的那個論述怎麼樣,並不礙於WP:QUALITY升為指引一事。
- 此修改技術成本過大,且認為這樣修改與否並不礙於WP:QUALITY升為指引一事。由於目前架構問題,該修改技術上的複雜性,不建議做此修改。除非有人能提出具體的patch ,否則我不支持也不相信此修改能夠被實際執行。(當然,如果有人做patch 就另當別論)-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年3月8日 (五) 06:05 (UTC)
- 如果沒有人有異議,你可以自行修改。
- -- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年3月8日 (五) 06:05 (UTC)
- 關於第一點,重要度只是順帶提及,核心是
評級針對的是WP:條目,其它模板級、分類級這些評級都是非標準級別,那麼頁面應當以標準評級針對的對象命名,也就是條目質量評級標準。
--Kunjinkao(留言) 2024年3月8日 (五) 06:26 (UTC)
- 關於第一點,重要度只是順帶提及,核心是
第二階段正式完成後的第三階段討論[編輯]
- Wikipedia:互助客棧/其他#評級系統缺失問題已分階段按部就班完成,可以準備進入最終階段進行收尾:
- 已完成當時的共識Wikipedia_talk:頁面質量評級標準#總結「將不是條目命名空間的評級分類從XX級條目改為XX級頁面」,因此將安排Wikipedia_talk:頁面質量評級標準#WP:QUALITY_升為指引重新公示。重Ping當時參與討論的人:@Liaon98、JyunWaan、Lssrn:@Cdip150、Temp3600、Peacearth:。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年3月19日 (二) 10:49 (UTC)
- 當時的討論是專題各自評級,而現在的情況是多了通用評級(WPBS)。所以時過境遷,WP:QUALITY要重新討論了。我之前沒有參與討論,現在有不少想法:
- WPBS評級是專題評級的容器,還是一套有自己標準的獨立評級?現行做法屬於前者:WPBS評級繼承專題的評級,且受各專題各方面的干涉,因此評級原則看似「隨意」。
所以我的看法是,通用評級就該如WPBS模板所言,確實地「依照頁面品質評定標準」來獨立評定,而不是在各專題評級間謀求公約數。可以參考專題評級,但把專題評級當爸爸就不對了😂一篇列表WPBS獲評List級而非CL級,是因為它確實沒到CL級。另一篇列表獲評List級而非CL級,只是因為某個參評專題不設CL級。第三篇列表和第二篇品質相似卻成功獲評CL級,原因竟是不設CL級的專題沒有「染指」該列表。
- 承上,如果我們確定WP:ASSESS本位而非專題評級本位,那就要討論條目的WPBS該設立哪些級別?英維的PIQA是只支持FA、A、GA、B、C、Start、Stub、FL、List、Unassessed幾個經典的「標準級別」。而我們的WPBS是大雜燴:既包括BL、CL這種品質向評級,也包括Future這種非品質向評級。所以WPBS評級所支持的「標準等級」該設哪些?
- BL、CL等品質向等級有兩條出路。一是如同英維,只收錄廣為人知的傳統評級,不收錄BL、CL這種額外等級;個別專題想啟用就在自己的橫幅上評。二是將BL、CL升格為通用評級,全體專題橫幅亦自動啟用BL和CL;如果個別專題自己討論後堅持不用BL,那可以用掩碼把BL改成List或B。
- 對於Future級,一篇未來級條目可以很爛(Stub),也可以比較充實(C),那Future這個等級就沒有實現「評價頁面質量」的作用。我能想到的用途是在話題中,用未來級作為寬限條目的標記,暫時不影響認定。但這個等級的確不夠「通用」,或者說和條目所用的品質評級不是一個維度。
- 對於A級條目。英維的A級在軍事史專題存活(且活得很好),但其他專題都是死的。因此英維多次討論A級的出路,比如從PIQA里開除把A級之類。但你維是真的所有專題都不評A級;所以,把這個只有理論價值的等級從通用評級中滅了挺好。
- 上面的想法也會影響小工具的設定:包括對標準評級的契合,對各專題自定等級的支援,對非條目評級的簡化(非條目空間一般人手評級無效)。
- 下文有提到「消歧義級條目/頁面」。如果按照命名空間來理解,那就有一個問題:重定向在各個空間都有,那到底是叫「重定向級條目」還是「重定向級頁面」?(或者兩個都要,但這徒增煩惱)另一方面從實用性上看,專題統計「條目數」都是排除Disambig級的,那消歧義占據條目空間就成了bug而非feature。這次從「條目」移到「頁面」更像是正名,但是後綴分家無論是技術實現上還是命名統一性上,帶來的麻煩都不少。考慮將後綴統一為「頁」,比如品質評級這邊的「乙級條目頁」「丙級列表頁」「模板頁」,重要度那邊也可以叫「高重要度頁」「未知重要度頁」,這樣觀後綴就知道是頁面評級體系在整活。
- 我明白很多內容都不在討論範圍內,但我認為之前討論本身就是系統性不足。比如把非條目品質評級改爲「XX級頁面」,那爲何條目品質評級和非條目重要度分類不動?是改條目和重要度分類真的弊大於利,還是單純沒有討論過而已?作爲這套系統創始者,英文版的非條目還用articles的,個中原因是否值得參考?--For Each element In group Next(留言) 2024年3月19日 (二) 16:05 (UTC)
- 下列討論已經關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
- 硬是等提案要準備收尾才來提意見是怎麼回事?!我可以當成你是打算擾亂干擾提案通過嗎?!--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)
- SunAfterRain 2024年3月20日 (三) 17:12 (UTC)
- 還沒有細看,但我對洛普利寧君遭到這樣的對待感到很悲哀。--Temp3600(留言) 2024年3月20日 (三) 17:43 (UTC)
- 最初提案開始時說「精神上支持」後消失三個月(2023年12月8日-2024年3月19日),等到提案東西都搞好,準備收尾時,冒出千字文異議,請問這樣到底哪裡恰當了?—38.46.221.138(留言) 2024年3月21日 (四) 04:10 (UTC)
- 在有用的討論串下面離題吵架實在無奈,但似乎VP環境已經如此。
- WP:CON明確指出"共識應採納多數人的意見,並和重要少數的意見作出適當妥協。"、"共識在維基百科是持續不斷的過程",對於方針修改,更再次明示"共識最終將根據支持和反對該議題的論點質量所決定"。方針中沒有任何字眼要求討論應"收尾",反而暗示了討論本身是可以無限延長,以不斷修改共識更貼合實況的。所謂擾亂更是莫名其妙。
- 回到討論本身,如果有足以反駁洛普利寧君的理據,直接提出來就可以。如果反駁不了,甚至根本沒有考慮到這一討論角度,那顯然就說明"之前討論本身就是系統性不足",提案一方存有思考盲點,應該進一步討論下去。
- 回到這個提案。我與八年前一樣,支持將WP:ASSESS建立為指引。然而,洛普利寧的問題必須先得到回答:維基百科:通用評級與維基百科:頁面質量評級標準之間有潛在矛盾。通用評級到底是獨立的評級系統,還是專題評級的平均分?我對這兩者沒有特別的見解,但WP:ASSESS應該清楚指明這一上下級關係。
- 如果不幸某頁面只有一個專題,而這個專題將頁面評為"未來級"等奇怪級別,通用評級是否跟隨?
- 請賜教。--Temp3600(留言) 2024年3月21日 (四) 19:45 (UTC)
- 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)
- 您的考慮方向我很贊同。不過如果例子舉成「改動一個模板就會牽涉多少分類的移動」,那會更有說服力 --For Each element In group Next(留言) 2024年3月23日 (六) 06:58 (UTC)
- 你以為你維的評級模組是Module:Namespace/data這種隨手改一改就好的是吧,改一次的成本有多高您可以自己改看看,不是什麼看起來很簡單改一改就好--SunAfterRain 2024年3月23日 (六) 03:13 (UTC)
- @A2569875:如果方針是FA級,指引是GA級,那現行WP:QUALITY+維基百科:通用評級大概只有C的水平,還需要很多工作完善:
那我倒覺得您來主持好了,包含修改模板模組的部分,反正您看起來很閒可以泡在客棧陪大家一直耗。--
- SunAfterRain 2024年3月22日 (五) 01:35 (UTC)
我不管你到底對這個議題有沒有興趣,反正你現在的意思是上方內容純粹是發牢騷你沒有要干擾這個提案?!-- - 還沒有細看,但我對洛普利寧君遭到這樣的對待感到很悲哀。--Temp3600(留言) 2024年3月20日 (三) 17:43 (UTC)
- SunAfterRain 2024年3月20日 (三) 17:12 (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)
- 硬是等提案要準備收尾才來提意見是怎麼回事?!我可以當成你是打算擾亂干擾提案通過嗎?!--SunAfterRain 2024年3月19日 (二) 16:40 (UTC)
- 上述爭議主要是因為前期討論不夠充分所致。而近期進一步討論已展開,因此可以視為爭議已消失,引此這段「爭議」先關閉,討論主力請移動到這裡來繼續進行,以便凝聚共識。感謝配合。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年6月1日 (六) 10:55 (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)
- 喂喂,不准跑掉( --Temp3600(留言) 2024年3月23日 (六) 07:14 (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)
- @Temp3600:問題就出在於,最早MilkyDefer的起草就有未來級、CL級等等,然後我還Ping了洛普利寧問他這樣可不可以,但他完全沒有任何答覆,到頭來還是只有一句「精神上支持」,我怎麼知道問題在哪,直到一月開發完成才開始說這裡不對、那裏不對,這樣我是要怎麼搞。反而User:Willy1018事先指出了具體問題,我得以依照他的問題在開發階段先行解決,並讓User:Willy1018說出了「
- (+)支持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)
- 按英文版的評級方式是沒有問題,但來到中維,維基百科:通用評級並不是英維的對等翻譯。於是就有了"若一條目僅有一個專題,其通用評級應與該專題所評的等級一致。"這樣的條款,影響到WPBS專註在內容評級的工作。順帶一說,這一點也和LP為什麼建議全面轉用英維制度,將內容評級由專題組上提到社群的精神一致。不過這樣就涉及更複雜的改動,恐怕還是免了。--Temp3600(留言) 2024年3月24日 (日) 05:30 (UTC)
- @Temp3600:我覺得像Future、Current(某主題是否是新聞事件或未來事件完全取決於專題領域,例如某主題在A領域可能是一件大新聞,所以評Future,但另一個領域關它屁事所以評甲乙丙丁初之一)Merge、Need(這種通常都是向特定專題請求重定向擴充為條目的標記,無關專題就標通用評級的 重定向級吧)這些「聚焦於特定專題」的級別就讓相關的專題沿用吧,然後從通用評級的標準評級撤下變成非標準評級,我想問題應該就解決了。修訂的部分,我想等到下面確立哪些要設為標準評級之後,再將通用評級指引加上「只能用標準評級」之類的規範應該就能從行政手段解決了。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年3月26日 (二) 17:36 (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)
- 咦我寫錯了...en:Talk:Texas_State_Highway_32如果按維基百科:通用評級,它下面只有一個future-class的專題評級,那麼就不能評為stub.在我看來這是問題。--Temp3600(留言) 2024年3月24日 (日) 05:01 (UTC)
- 有什麼……不一致嗎?Future Class列在非標準等級下,並且寫有「部分專題還會啟用附加等級。」看上去挺一致的欸。--MilkyDefer 2024年3月24日 (日) 04:36 (UTC)
- @MilkyDefer:例如en:Talk:Texas_State_Highway_32按你的構想,是什麼評級。背景資料....按我很初步的認識,英文WPBS的條目評級系統只容許BCStub等標準評級,但專題組可以按各自需要將條目評為future級等特殊等級。這與目前WP:QUALITY中建議的評級方案並不一致。--Temp3600(留言) 2024年3月24日 (日) 04:05 (UTC)
- 什麼叫沿用?事實上我連現在future grade的使用情況都不是很清楚,可否說明一下背景信息?--MilkyDefer 2024年3月24日 (日) 03:55 (UTC)
- 另另外我約略看了一下英維,看來它們已經將各專題評級整合起來,會個條目只有一個評級。這是你提出由上而下的背曔原因嗎?@For Each element In group Next:--Temp3600(留言) 2024年3月24日 (日) 03:38 (UTC)
- 我也認為WPBS是社群基於標準(WP:QUALITY)對條目做出的評價。當然,社群也允許專題依照自己的標準對條目做出評價,並標記在討論頁上。某種意義上,社群評級和專題評級是「人格獨立」的,這裡的「上」和「下」更像依賴的上下游,而不是官大一級的上下層。然後既然專題評級是獨立的,那專題就可以選擇各種策略:
- 社群人多力量大,自行評級太繁雜,WPBS填啥我填啥。(看起來就像評級被廢了,但其實是選擇和WPBS的做法一樣)如果對專題成員評級不服,要麼以社群成員身份找社群吵,要麼推動專題退群。這就是英維絕大部分專題的策略。
- 預設繼承社群評級,但也可以自行覆蓋社群評級。這就是我們現在的狀態。
- 不繼承WPBS的評級,只要自己的class不填就是未評級。英維的退群專題(比如有BL的WP:MILHIST、沒A的WP:VG)都是這個策略。不排除有些專題是想自己搞;但也有專題是只開除掉A級,其他等級想繼承社群,但因為英維技術不支持策略2而被迫退的。
- 像SunAfterRain說的,絕大多數專題用策略1就夠,而且理論上標準相同的專題應該評同樣的等級。個別專題有特殊的評級標準,那就採用策略2。真有專題完全不想社群插手,那就上策略3。策略1那就是純粹的自上而下了。此外,對上游的WPBS規定好標準等級後,將非標準等級映射到標準等級(假設規定BL->List、D->Start、Current->Unassessed),也可以讓機器人參考策略2和3的專題填WPBS。
- 自下而上主要還是一堆奇葩等級,邏輯上沒法搞。刻度尺測量物體長度,得到的結果應該是穩定的;一次測3 cm、一次測5 cm,就說明測量錯了。但如果兩次測量都操作無誤,那你用的大概不是尺子 WPBS本來評CL,因為來了個不支持CL的專題就改評List,兩次評級都沒有錯,這就說明該制度不適合衡量條目品質。如果將奇葩等級改成WPBS標準評級,或者拒絕參考非標準等級,那這個制度就可行;但這基本就又成了上面的問題。--For Each element In group Next(留言) 2024年3月24日 (日) 16:21 (UTC)
- 我覺得改動WPBS最少的可能是將所有「條目品質性」(甲乙丙丁初等)和「非條目類別性」(Disambig、SIA、Template等)的級別全部設為標準評級(含少數專題另設的Bplus和D、以及很少專題用的A級等[有專題用A級,如颱風之類的專題。]),「性質性」(Future、Current等)的級別全部設為非標準評級。這些「與條目品質無關」的評級就讓專題自己評,不影響WPBS,就不會出現要在CL級或Future級取捨的狀況了。然後各自專題不要的,自己去mask(到時全站公告一下,想接受的專題就接受,不想接受的專題就自行寫mask,這樣寫mask的責任就不會在此次修改上)。技術上成本最小。 只不過以上作法因會將AL、BL、CL、SL也列入標準級別,代表List級別可能會變成沒有任何頁面會被評成List級,看是要廢除List級還是保留List級在代碼裡,不想跟進的專題自己mask。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年3月25日 (一) 04:43 (UTC)
- 然後主題專題自設的Complete、Substantial、Basic、Incomplete因WPBS預設在非條目命名空間時會因「Namespace優先」而評成「主題級」,所以我想應該也問題不大。如需在WPBS中禁掉,可可以將Module:PJBSClass#L-53的一堆if陳述式註解掉。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年3月25日 (一) 04:57 (UTC)
- (~)補充提升為標準評級的級別:
- 典範級、 甲級、 優良級、 乙上級、 乙級、 丙級、 丁級、 初級、 小作品級、( 小小作品級待討論,因為通常30天就被刪除了或提升為 小作品級以上)、 特色列表級、 甲級列表級、 乙級列表級、 丙級列表級、 列表級、 小列表級,以及列在Category:自動評級的頁面#分類索引中的所有評級(即一系列可由WPBS自動完成評級的級別)。
- 設定為非標準評級的級別:
- 您說的也是可行方案。目前啟用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)
- (~)補充提升為標準評級的級別:
- 我也認為WPBS是社群基於標準(WP:QUALITY)對條目做出的評價。當然,社群也允許專題依照自己的標準對條目做出評價,並標記在討論頁上。某種意義上,社群評級和專題評級是「人格獨立」的,這裡的「上」和「下」更像依賴的上下游,而不是官大一級的上下層。然後既然專題評級是獨立的,那專題就可以選擇各種策略:
- 先多謝各位,意見都很有見地。希望在上方再拆一個小標題。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)
- 那我們現在就先以已登記於phab的級別為主,也就是我上面列出的那些以及列在Category:自動評級的頁面#分類索引中的所有評級(即一系列可由WPBS自動完成評級的級別)。CL級標準之前已經訂清楚了,所以我想,直接設為標準沒有問題,(+)支持作為推廣;比較需要討論的會是 乙上級。我想就用洛普利寧提出的「不要求中立性和穩定性,但其他方面同GA標準」如何?@Temp3600:-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年3月27日 (三) 01:11 (UTC)
- Template:Grading scheme可能也有關連,描述可能需按這兒的討論結果一拼修改。--Temp3600(留言) 2024年3月27日 (三) 04:50 (UTC)
- B+在我心中是"沖擊優良但失敗了"的意思(pia!)--Temp3600(留言) 2024年3月27日 (三) 09:53 (UTC)
- Template:Grading scheme可能也有關連,描述可能需按這兒的討論結果一拼修改。--Temp3600(留言) 2024年3月27日 (三) 04:50 (UTC)
- (~)補充轉介級有登記在phab上,只不過登記成了 擱置級;但如果又要去改,感覺沒幾天就又要去麻煩基金會技術人員好像不太好……因為2015年就這樣寫了,就先當歷史遺留吧😅-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年3月27日 (三) 01:17 (UTC)
- 關於「轉介級」(現稱 擱置級),其也是目前中維{{WPBS}}可填的參數之一。您認為應該要如何處置呢?翻閱en:Wikipedia:WikiProject_Firearms#Quality_scale他似乎把它視為「品質等級」的一種,但實為將評級工作轉介至其他專題,然而如此的做法在有{{WPBS}}時就沒有存在意義了,因為轉介最終就會落回給{{WPBS}}提供評級,所以英文維基{{WPBS}}實施後其有關分類就被WP:O4了(他們好像叫做en:WP:CSD#C1),那所以我們應該要把他列為「非標準級別」還是直接列為「已停用級別」即在{{WPBS}}的Doc上說不要輸入此級別?-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年3月31日 (日) 10:08 (UTC)
- 那我們現在就先以已登記於phab的級別為主,也就是我上面列出的那些以及列在Category:自動評級的頁面#分類索引中的所有評級(即一系列可由WPBS自動完成評級的級別)。CL級標準之前已經訂清楚了,所以我想,直接設為標準沒有問題,(+)支持作為推廣;比較需要討論的會是 乙上級。我想就用洛普利寧提出的「不要求中立性和穩定性,但其他方面同GA標準」如何?@Temp3600:-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年3月27日 (三) 01:11 (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上有群友建議「轉介級」,不過這種級別對上通用評級的話,基本上存在感就沒了,
- (有感而發)除了本子節開始的爭議外,以上討論與研究其實都滿有意義和價值的,如果能提前在去年十二月,也就是我當初Ping了洛普利寧時,他就發表了這些意見,並開展了我們現在所討論的東西,那我覺得WPBS應該會更完美。不過現在說這些都是後話了。另,跟大家說聲抱歉,我當時一心只想著如何把MilkyDefer起草的臨時方案開發成正式方案、如何pass所有testcases 和解決討論頁上各種問題回報(1、2等),一切考量都以技術為優先(我當時優先級最高的考量是:程式怎麼寫更省效能,於是出現了
mw.loadData("Module:PJBSClass/page")
用於讓該功能在整個頁面解析的過程只會跑一次,而不會每次調用通用評級時都跑以節省效能),卻忽略了行政上的執行問題,而導致了今次的爭議,我感到十分抱歉。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年3月27日 (三) 01:30 (UTC)- 所謂「話到嘴邊留半句,理從是處讓三分」,我覺得是挺有道理的。得饒人處且饒人嘛。(當然這得看對象,要是遇到得寸進尺的惡人,這樣就行不通)
- 如果說程式碼是機器運行的邏輯,那麼行政可說是人類組織運作的邏輯。要做好事情,既需要機器運作暢順,也需要眾人合力。不同維基人從各自的強項出發,一起解決問題,這就是討論的意義嘛。--Temp3600(留言) 2024年3月27日 (三) 04:47 (UTC)
- ((*)提醒:本次提案推動技術修改的兩位「工程師」(User:Kanashimi、User:A2569875)都沒時間寫程式了...雖然我的原因是因為改到沒精力了)。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年4月1日 (一) 02:00 (UTC)
- 維基百科:通用評級與WP:QUALITY都要弄修改草稿,行政組這邊也不好當呢...--Temp3600(留言) 2024年4月2日 (二) 11:40 (UTC)
- 從這裡入手,在Module:Class/conver外再套一個函數,把不支援的評級映射到未評級可行嗎?--For Each element In group Next(留言) 2024年4月2日 (二) 16:31 (UTC)
- (-)反對我想保留這些自動評級Category:自動評級的頁面#分類索引,不然phab白跑了。而且不想被濾的專題也會被你一刀切不當濾掉。後果不會是你想像的那麼簡單。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年4月2日 (二) 16:41 (UTC)
- 自動評級的頁面基本都是非條目,那不是屬於PJBS支援的範疇嗎……?對於條目,如果按照上面WPBS作為獨立評級的思路,那PJBS就只應接受他自己的等級。比如PJBS不支援current,那PJBS的
class
就不應該填current(如果一定要填current,那PJBSClass.getClassByPage()也應該返回未評級);所以到頭來,WPBS只會告訴各個專題自己未對此頁面評級。既然WPBS理論上都不會填寫current,那支援current的專題就只能手填自己的class;據我所知,專題自己填寫的class是優先的,那這時只要對專題模板自己的class套用Module:Class/convert規範化就OK。宇帆君的代碼很模塊化(不像我寫代碼什麼東西都揉一起😂),我想這個問題應該的確不是複雜問題。當然,如果我們的總工程師說複雜,那就是複雜😂 另外,如果思路確實是要WPBS兼顧所有專題,比如PJBS評級未顯示但往外傳current,那這個想法就的確不成立了。--For Each element In group Next(留言) 2024年4月3日 (三) 14:16 (UTC) - 另外即使我的意見合理,宇帆君您也沒有義務在近期執行技術修改(甚至沒必要執行修改)。畢竟「這個想法很好,但礙於技術原因,目前無法實現;歡迎提議人自行解決」也是合理意見😂--For Each element In group Next(留言) 2024年4月3日 (三) 14:33 (UTC)
- 自動評級的頁面基本都是非條目,那不是屬於PJBS支援的範疇嗎……?對於條目,如果按照上面WPBS作為獨立評級的思路,那PJBS就只應接受他自己的等級。比如PJBS不支援current,那PJBS的
- (-)反對我想保留這些自動評級Category:自動評級的頁面#分類索引,不然phab白跑了。而且不想被濾的專題也會被你一刀切不當濾掉。後果不會是你想像的那麼簡單。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年4月2日 (二) 16:41 (UTC)
- 感覺還是社群沒有體系性討論。比如日語羅馬字表示方法討論過好幾次,但正經的日本格式手冊卻現在還推不出來。我之前不留言,基本也是感覺本站沒救,什麼都懶得說😂 當然只限條目編寫方面;站務領域我看討論挺熱烈的。
- ((*)提醒:本次提案推動技術修改的兩位「工程師」(User:Kanashimi、User:A2569875)都沒時間寫程式了...雖然我的原因是因為改到沒精力了)。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年4月1日 (一) 02:00 (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個。此外由於表格過長,已折疊。請單擊[顯示]
以展開表格):
標準類別級別 | 標準品質級別 | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
非頁面級 | (條目) | 典範級 | 甲級 | 優良級 | 乙上級 | 乙級 | 丙級 | 丁級 | 初級 | 小作品級 | 小小作品級 | 無級 | |
列表級 | 特色列表級 | 甲級列表級 | 優良列表級 | N/A | 乙級列表級 | 丙級列表級 | N/A | 小列表級 | N/A | ||||
非條目級 | 文件級 | 特色圖片級 | N/A | ||||||||||
主題級 | 特色主題 | N/A | 完成級 | 充實級 | N/A | 簡單級 | N/A | ||||||
消歧義級 | N/A | ||||||||||||
同類索引級 | |||||||||||||
重定向級 | |||||||||||||
沙盒級 | |||||||||||||
模板級 | |||||||||||||
模塊級 | |||||||||||||
分類級 | |||||||||||||
草稿級 | |||||||||||||
專題級 | |||||||||||||
用戶級 | |||||||||||||
使用說明級 | |||||||||||||
界面級 | |||||||||||||
非標準類別 | |||||||||||||
圖書級 | |||||||||||||
音頻級 | |||||||||||||
未分類級別 | 非標準級別 | ||||||||||||
N/A | 未來級 | 動態級 | 合併級 | 請求級 | 擱置級 | ||||||||
委員會級 | N/A | ||||||||||||
錯誤級 | |||||||||||||
未評級 | |||||||||||||
未知級 | |||||||||||||
輸入其他值{{WPBS}}會輸出:錯誤:無效的輸入 |
典範 | 特色列表 | 特色圖片 | 優良 | 小作品 | 列表 | 同類索引 |
消歧義 | 重定向 | 沙盒 | 模板 | 模塊 | 分類 | 文件 |
草稿 | 主題 | 專題 | 用戶 | 使用說明 | 界面 | 非條目 |
以下建議供行政組參考:
- 標準品質級別(可填寫在WPBS):
- 標準類別級別(可填寫在WPBS):
- 非標準類別級別(不應該填寫在WPBS):
- 圖書級[Book](曾有共識引入,但因技術原因部署無限期推遲)、 音頻級[Audio](只有少數專題將File級做細分,WPBS應都填入File級)、圖像級[Image]((▲)同上)、 非頁面級[NAPage](只用於特殊專題)
- 非標準品質級別(不應該填寫在WPBS):
- 非標準級別(不應該填寫在WPBS):
- 技術性級別(不應該填寫在WPBS):
- -- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年4月6日 (六) 03:43 (UTC)
- 感謝總結。我有一些疑問:
- Substub作為標準品質,似乎比較增加維護負擔?會創建小小作品的基本都是新手,他們不懂得在討論頁掛{{WPBS}}填
|class=substub
。維護人員也都在條目頁標記{{substub}}
,然後打撈人員再從Category:小小作品追蹤,這就基本就沒人會管討論頁。而且就算有專題模板,如果利用討論頁的分類來維護,就要從討論頁跳轉到主頁面,也是比較低效的。(MilkyDeferBot可以根據討論頁橫幅和條目頁{{substub}}
自動生成頁面列表,這樣也沒必要用討論頁評級)此外如果substub是被人手填了,那就還要經常盯着條目,看評級是否過時。所以依靠評級模板來維護substub,感覺有種打撈一分鐘,評級三十秒,性價比相當低。所以,WPBS層面統合到stub是否好些? - 正規條目都應該有品質評級,尚未評估品質的條目是Unassessed,條目空間的Disambig等特殊頁面也考慮進去了。看英維也沒no這個級別,所以無級別的條目會是怎樣的?
- Substub作為標準品質,似乎比較增加維護負擔?會創建小小作品的基本都是新手,他們不懂得在討論頁掛{{WPBS}}填
- --For Each element In group Next(留言) 2024年4月6日 (六) 05:20 (UTC)
- (:)回應 no級(無級別)是由您建檔於評級系統的Special:Diff/72525905#L-149,我只是照抄,並同步到所有評級模板,以及提報到phab:T360012上。所以我也不知道具體會是甚麼,可能還需要諮詢您(因為由您加入的)。我在整理時看到它的理解為「沒有級別的」但我當時沒有仔細思考甚麼條目或頁面會「沒有級別」,您能否協助回想一下當時的時代背景下,您建檔No級時的想法或根據呢。 小小作品級我認為是有些條目可能加上了資訊框、圖片等被WP:小小作品指引PASS而保留,但正文還是不足50字的情況下可以評(我就是有用隨機頁面看過有很舊的頁面有這種狀況,但因為它是甚麼我沒聽過的小城鎮的條目,我不熟就沒去擴充,繼續按下一個隨機頁面)。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年4月6日 (六) 05:56 (UTC)
- Classicon}}里就有no級,我也是從那裡搬過去的。做頁面列表的時候可能會用到no這個概念,比如這個從英維搬運的名單,no可以用來標記不掛專題橫幅的條目。至於用no給條目本身評級,我倒是沒見過。 最早的時候{{
- 我明白您說的小小作品級了,這和WP:SUBSTUB又是兩個概念,就類似「小作品級」和「小作品」了。我是認為對這麼短的條目,精確數50字感覺都浪費時間(反正多20%到60字也一樣很爛😂)。如要設立這個級別,換成「正文只有一兩句話(約50字以下)的條目」,這樣大概看下數量級會比較實用。當然我就只是拋個磚,評級能弄下去還是靠大家,所以這還是看看其他人有什麼想法吧。--For Each element In group Next(留言) 2024年4月6日 (六) 06:16 (UTC)
- 所以沒有級別(no)是指未建立或已刪除的條目嗎(紅鏈)?這樣可能真的評不了 囧rz……,因為如果在一個紅鏈條目的討論頁掛一個
{{WPBS|class=no}}
就構成孤立頁面會被速刪😂,如果是刪除後建立成重定向頁也不會是no級會是redirect級。所以no級可能就變成一個永遠不會被填進{{WPBS}}的概念級別了。是否當作標準級別我覺得可以,畢竟您說了做頁面列表的時候可能會用到no這個概念,那它應該列入標準,只不過這個標準級別可能永遠不會被填入{{WPBS}}罷了。 小小作品級我也想等看看其他人的意見。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年4月6日 (六) 06:29 (UTC)- 其實說no這個概念也不準確。英維早把不用的圖標和等級(包括bplus和no)刪了,中維就各種「集大成」從來不做減法,所以留下了一堆未定義的東西。我上面的用例準確來說,是頁面已經建立且可能被WPBS評級,但因為沒有掛遊戲專題的橫幅,所以表現出未由遊戲專題維護。既然遊戲專題不維護,那在專題內部就不用關心頁面品質;但是所有頁面都有圖標,你不放個東西也不好看,所以才放了個圖標。或者說,語義上這裡應該用
{{icon3|Wikivoyage outline icon.png|alt=未标记专题横幅}}
,但因為偷懶才用了{{class/icon|no}}
;畢竟從分類中根本抓不到no級,這裡還是if判斷頁面已建立但未標遊戲橫幅,為True才拉到這個分類的。--For Each element In group Next(留言) 2024年4月6日 (六) 06:52 (UTC)
- (:)回應: @洛普利寧:我知道甚麼東西可能是無級別條目了,大概是Category:維基百科綱要,這些條目基本是點列式(如戰爭綱要),讓人了解「主題綱要」之用。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年4月21日 (日) 01:31 (UTC)
- 綱要也有完整和不完整的區別。這個相當於列表,也有級別。寫得完整點的綱要就是CL/BL。--For Each element In group Next(留言) 2024年4月21日 (日) 03:35 (UTC)
- 其實說no這個概念也不準確。英維早把不用的圖標和等級(包括bplus和no)刪了,中維就各種「集大成」從來不做減法,所以留下了一堆未定義的東西。我上面的用例準確來說,是頁面已經建立且可能被WPBS評級,但因為沒有掛遊戲專題的橫幅,所以表現出未由遊戲專題維護。既然遊戲專題不維護,那在專題內部就不用關心頁面品質;但是所有頁面都有圖標,你不放個東西也不好看,所以才放了個圖標。或者說,語義上這裡應該用
- 所以沒有級別(no)是指未建立或已刪除的條目嗎(紅鏈)?這樣可能真的評不了 囧rz……,因為如果在一個紅鏈條目的討論頁掛一個
- (:)回應 no級(無級別)是由您建檔於評級系統的Special:Diff/72525905#L-149,我只是照抄,並同步到所有評級模板,以及提報到phab:T360012上。所以我也不知道具體會是甚麼,可能還需要諮詢您(因為由您加入的)。我在整理時看到它的理解為「沒有級別的」但我當時沒有仔細思考甚麼條目或頁面會「沒有級別」,您能否協助回想一下當時的時代背景下,您建檔No級時的想法或根據呢。 小小作品級我認為是有些條目可能加上了資訊框、圖片等被WP:小小作品指引PASS而保留,但正文還是不足50字的情況下可以評(我就是有用隨機頁面看過有很舊的頁面有這種狀況,但因為它是甚麼我沒聽過的小城鎮的條目,我不熟就沒去擴充,繼續按下一個隨機頁面)。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年4月6日 (六) 05:56 (UTC)
- 感謝總結。我有一些疑問:
等級標準小結[編輯]
- 洛普利寧在上文提到的「PJBS之PJBSClass.getClassByPage()」自動評級(小勘誤:自動評級實由PJBSClass/main.getClassAuto()和PJBSClass.getAutoClass()共同完成,前者以頁面狀態和掛有模板判斷、後者只看Namespace),這些評級會根據頁面掛的模板、子頁面名稱、頁面狀況和所在命名空間等進行自動評級。這些評級分為兩類:不可被
|class=
參數複寫的評級以級可被|class=
參數複寫的評級。 - 這些級別有:
- 上文提到,目前不在WP:QUALITY中的級別都需要補上文檔,因此我起了以下草稿供參考:
- (註:如果有需要修改可以直接編輯本表格,無須經過我的同意(不被視為修改他人留言))
- (註2:下表只列出目前未出現於WP:QUALITY的級別)
- (註3:由於表格過長,已折疊。請單擊
[顯示]
以展開表格)- 預計種類分成三類:標準級別(描述條目品質)、標準類別(描述頁面種類)、非標準級別(專題自定的東西)
預計種類 | 級別 | 代碼 | 評級方式 | 標準 | 詳細標準 | 讀者感受 | 編輯建議 |
---|---|---|---|---|---|---|---|
標準級別 | 特色列表級 | FL | 手動 | 條目通過正式評審,現為特色列表。 | (載於WP:特色列表標準) | 專業水準。它完整覆蓋所屬範圍,通常能提供一個完整的列表,並為每一項提供有用的資訊。 | 除非列表所列之主題有了項目變動或所屬範圍有新發展,否則不應大量增改內容;可能需要改進文法、列表格式,讓列表整體更加優美。 |
特色圖片級 | FM | 圖片、文件或其他媒體通過正式評審,現為特色圖片。 | (載於Wikipedia:特色圖片標準) | 讀者能從該圖像、音頻、視頻或其他媒體以令人信服的方式說明該主題,使觀看者想要了解更多。且這個媒體能很大程度的讓讀者更了解文章的內容或主題。 | 通常不需要對媒體文件做出任何改動,除非能提升解析度或其他外觀品質。可能可以改進對於該特特圖片的描述文字或對應題目中的文法,讓特色圖片能更好地發揮其價值。 | ||
甲級列表級 | AL | (WP:QUALITY已有內容) | |||||
乙上級 | Bplus | 條目已基本完成,有當選優良條目的潛質,經相關專題、討論頁或其他管道評審,確認符合乙上級條目標準。 | 無明顯問題,對幾乎所有讀者都實用。基本達到(未必完全符合)專業百科全書水準。 | 或需相關領域的編者和格式專家修改。可提名WP:同行評審以釐清與優良條目的差距,並進行改善。 | |||
乙級列表級 | BL | (WP:QUALITY已有內容) | |||||
丙級列表級 | CL | (WP:QUALITY已有內容) | |||||
丁級 | D | 條目有所發展,較初級條目更為完整,但仍有重要內容缺失。條目可能在內容方面達丙級水準,但因行文、結構等問題無法獲評丙級。 | 條目有些不錯的內容,也列出了些許可靠來源,但與丙級條目對比仍有明顯缺陷。例如條目未遵循百科文風,文字條理性不足,大量內容僅面向特定圈子(如愛好者內容、科學專業術語或內容)。 | 條目有較多百科全書資訊,但可能也伴隨較多難以理解的內容。讀者可收穫一定的資訊,但可能感到條目章法混亂、某些內容不易理解,難以通讀全文。 | 仍需擴充資訊,且或需大幅清理與重組內容。 | ||
列表級(作初級列表使用) | List | 符合獨立列表的要求,較小列表更為完整,但未能達到丙級列表的水準。列表中的可靠來源可能引用充分,也可能不充分。尚未細分為甲、乙、丙級的列表也可能暫時歸為此類。 | 列表有些有用的內容,但是在許多方面仍有不足,通常缺乏參考資料。列表內容可能不適合百科全書,不符合格式手冊的要求。但是列表必須滿足最基本的內容方針和獨立列表的基本要求,諸如關注度、生者傳記,並提供足夠符合可供查證要求的來源。初級的列表應無快速刪除之虞。 | 已經列出了一些有意義的內容,但對於多數讀者仍屬不足。 | 應當儘快提供可靠來源,並需大幅更動和組織內容。此外也可改善語法、別字、寫作風格、術語的使用。 | ||
小列表級 | SL | (WP:QUALITY已有內容) | |||||
小小作品級 | Substub | 對主題非常基本的描述,但正文不足50字。 | 條目有基本定義,但正文只有一兩句話(約50字以下)的條目。其可能有資訊框、圖片或參考文獻。如正文不足50字的條目也缺乏資訊框、圖片或參考文獻,則其可能會被提請刪除。 | 有意義內容極少,可能跟典解釋差不多。 | 應當儘快將正文擴充至50字以上。 | ||
無級 | No | 尚未建立或已被刪除的條目。通常用於建立條目清單時標記不存在頁面的級別。 | N/A | 由於條目不存在,因此讀者無法獲得任何資訊。 | 如該主題有建立條目的需求,可以視情況建立條目。 | ||
標準類別 | 同類索引級 | SIA | 由{{WPBS}}程式自動給予級別 | 任何同類索引條目(SIA)頁面都屬於此類。這些是關於一組具有相同(或相似)名稱的特定類型項目的清單文章。 | 掛有{{SIA}}模板的頁面 | 讀者能找到特定類型項目的文章。 | 請注意,同類索引條目對名稱和主題都有要求,即索引項目必須屬性相同且名稱相似。比如地震列表不是同類索引條目,但以X爲名的地震列表就因滿足同名、同主題兩項條件,屬於同類索引條目。 |
沙盒級 | Sandbox | 社群認可用於測試的頁面。 | 掛有沙盒標示模板的頁面,或模板、模組的/sandbox子頁面 | 這個頁面的內容可能因為測試原因而頻繁變動,可能對任何讀者都不實用。 | 無建議。 | ||
草稿級 | Draft | 任何草稿都屬於此類。這些通常位於Draft命名空間中,但也可能位於User命名空間中。 | N/A | 這可能是一個發展中的條目,因此可能有一些有意義內容,但對於多數讀者仍屬不足。 | 任何編輯或者增加內容都會有幫助。應當儘快增加有意義的內容。並儘快推動完成WP:AFC流程,解決相關問題以便成為正式條目。 | ||
專題級 | Project | 任何維基專題相關頁面。 | N/A | 專題頁面主要是面相編者的資訊,對讀者而言可能沒有有用資訊。 | 編者應確保內容能反映專題或社群共識。 | ||
用戶級 | User | 任何屬於User名字空間的頁面 | N/A | 可能有些有用的資訊,也可能只包含特定編者的立場。 | 應遵守Wikipedia:用戶頁規範。 | ||
使用說明級 | Help | 任何屬於Help名字空間的頁面 | N/A | 讀者能找到維基百科相關功能的使用說明。 | 編者應當確保說明內容不過時。 | ||
界面級 | Interface | 任何屬於MediaWiki名字空間的頁面 | N/A | 定義介面的顯示方式,可能對任何讀者都不實用。 | 任何對系統介面的修改都應反映社群共識。有時會因技術需求或其他原因由維基媒體基金會職員進行修改。 | ||
非標準級別 | 擱置級 | Deferred | 只能手動給定 | 代表本頁面的評級作業轉介給涵蓋該頁面主題的其他專題。 | 任何編輯都可以在有開放此級別的專題指定此評級,但不能評於通用評級。應謹慎使用此評級,並且僅在其他專題完全覆蓋此專題導致冗餘的情況時使用。 | 由於對應專題沒有提供級別,因此實際情況可能會有所不同。 |
- @Temp3600:您看看這些資訊對行政組作業有沒有幫助?(請單擊
[顯示]
以展開表格)-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年4月5日 (五) 10:48 (UTC) - 感謝宇帆君的總結。我大膽做了一些調整,說明如下:
- --For Each element In group Next(留言) 2024年4月5日 (五) 13:54 (UTC)
- 已經五天無新意見了,我先把資料整理進WP:QUALITY。如到時還有討論出新結論也可以再修改。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年4月10日 (三) 03:22 (UTC)
頁面評級與通用評級指引調整[編輯]
- 非常感謝娜娜奇。但我因為現實原因(pia!)暫時不能積極參與討論。我預計會於19-21日的週末發言,這段時間麻煩諸位了。--Temp3600(留言) 2024年4月12日 (五) 11:29 (UTC)
- 約略看過沒有問題。在格式上有一點想法: 每個類別還是找一個例子,當參考。另外,會否用Template:Guideline section,只將標準評級立為指引會較好?如果專題組日後創立新評級供內部使用,便無須經VP共識修改評級表,而可自行加入。不過倒過來,如果自行加入評級會弄壞模版,那麼還是經VP討論,協調好再修改較好。這方面我不清楚,請給意見。--Temp3600(留言) 2024年4月12日 (五) 11:58 (UTC)
- Class_mask/core}}中,目前還沒標準化的級別做「開放」即可(不必改程式,只要改類似config(設定)的東東),而專題自建級別已有相應功能,無須動到核心模板,範例見{{WikiProject_Example}},因此完全無需更動本次系列模板/模組或任何程式碼的核心,故自行加入評級不至於會弄壞模版。常見的專題非標準評級我覺得可以在WP:QUALITY提,在章節標題標註「本段不是指引」應該就可以了,就不必走VP共識了。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年4月12日 (五) 15:49 (UTC)
- 先抱歉晚了許多上來...生活艱難QQ。
- 如果如此,那麼標準級別一節立為指引就可以,並在非標準級別一節清楚列明專題可以如何自行加入新評級(好像在模版說明裏已經寫好?那麼就只需要提供連結)。--Temp3600(留言) 2024年5月5日 (日) 07:27 (UTC)
屆時,如果確定該等級都標準化的話,僅需要將{{
- Class_mask/core}}中,目前還沒標準化的級別做「開放」即可(不必改程式,只要改類似config(設定)的東東),而專題自建級別已有相應功能,無須動到核心模板,範例見{{WikiProject_Example}},因此完全無需更動本次系列模板/模組或任何程式碼的核心,故自行加入評級不至於會弄壞模版。常見的專題非標準評級我覺得可以在WP:QUALITY提,在章節標題標註「本段不是指引」應該就可以了,就不必走VP共識了。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年4月12日 (五) 15:49 (UTC)
- 約略看過沒有問題。在格式上有一點想法: 每個類別還是找一個例子,當參考。另外,會否用Template:Guideline section,只將標準評級立為指引會較好?如果專題組日後創立新評級供內部使用,便無須經VP共識修改評級表,而可自行加入。不過倒過來,如果自行加入評級會弄壞模版,那麼還是經VP討論,協調好再修改較好。這方面我不清楚,請給意見。--Temp3600(留言) 2024年4月12日 (五) 11:58 (UTC)
- 非常感謝娜娜奇。但我因為現實原因(pia!)暫時不能積極參與討論。我預計會於19-21日的週末發言,這段時間麻煩諸位了。--Temp3600(留言) 2024年4月12日 (五) 11:29 (UTC)
對於Wikipedia:頁面質量評級標準(以及Wikipedia:通用評級)還有一些邏輯上的考量:
- 英文版的頁面en:Wikipedia:Content assessment翻譯過來是內容評級。其內涵理論上包括評級流程、評級標準等多個部分。而中文版的標題是「頁面質量評級標準」,一隻介紹標準本身,二又強調品質評級。而當前頁面是從古早期英維版翻譯過來,現在兩邊都改了很多,這就很微妙了。所以頁面是否要改名「Wikipedia:頁面評級」?
- 如果從標題強調質量評級來看,頁面似乎應該將「標準質量評級」(≈條目)和「標準類別級別」(≈非條目)分設為兩個大節。說約等於是因為特色圖片屬於非條目但又要評估品質,而同類索引(SIA)是自動評級但理論上屬於條目。
- 對於條目品質評級部分,是否需要流程圖輔助說明?(比如寫入指引頁,或放在論述頁給個連接)
- 如何表述「通用評級」與「專題評級」的關係?從目前的討論來看,可能還需要一個頁面(可能是Wikipedia:頁面評級)釐清:
- 社群和專題都可以各自獨立地對頁面評級。評級結果登記於條目討論頁頂部。
- 通用評級由社群編者評估,對社群負責。本頁刊載的等級標準為通用標準,即適用於WPBS的通用評級。
- 專題評級由專題自行解釋,但因為專題評級一般直接繼承通用評級,所以也還是這套標準。部分專題可能自選啟用或關閉級別,也可能重新詮釋通用級別,這些內容具體在專題評級頁刊載。
我希望聽聽其他編者的意見,所以暫時不會積極回復。--For Each element In group Next(留言) 2024年4月14日 (日) 15:17 (UTC)
- 那我再Ping一次討論開頭的那些人吧:@Liaon98、JyunWaan、Lssrn:@Cdip150、Temp3600、Peacearth:。還有User:KanashimiPing的那些人@Kethyga @Willy1018 @Z7504 @AT @Shizhao @Iokseng 能夠給些意見嗎?謝謝。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年4月14日 (日) 15:34 (UTC)
- 週末來研究 --Temp3600(留言) 2024年4月14日 (日) 15:47 (UTC)
- 只講這一句,其餘不說了:「WPBS模板目前看來機器人執行上是沒什麼問題的。另外,有些分類基本用不到(例如 同類索引級),不予評論」。反正評級功能沒什麼大問題,個人認為就不用再浪費時間在這種沒問題的上面,不打擾了。--Z7504非常建議必要時多關注評選(留言) 2024年4月18日 (四) 13:45 (UTC)
- 之前說過了,自動評級「有掛模板就能判斷」,既然{{同類索引}}模板存在,就能被自動判斷,且分類裡確實有東西,故不認同「用不到」一說(例三碘化物 (索引)既非消歧義也不是列表),真用不到的話,分類早就O4了。就這樣,我也不想就這個話題繼續(真要較勁的話,{{導論}}也有模板存在,病毒v.s.病毒 (導論),也可以搞出 導論級[Introduction][甚至是 綱要級[Outline]](如馬來西亞v.s.馬來西亞綱要)],但因為導論也有品質,不像同類索引偏點列式,所以導論類條目就共用條目的甲乙丙丁初級)。哪壺不開提哪壺,我們在討論評級時的規範,而你在講機器人能不能工作,這完全兩碼子事,而且顯然現在貿然增減或棄用一個級別存在技術上的複雜性和已報上phab且工程師已完成作業還要頻繁去phab「吵他們」、「煩他們」顯然不是一個好的做法(這點Temp3600講過了不再贅述)。仍然主張維持放所有能自動判斷的級別設為標準級別。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年4月18日 (四) 13:57 (UTC)
- 然後,有點離題了,建議聚焦在頁面評級與通用評級指引邏輯上的考量。WPBS能使用哪些評級的議案已經公示通過,且能使用,機器人和系統自動評級的部分正 正常工作著,故不必再浪費時間討論。從行政組的工作切入討論起來比較重要-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年4月18日 (四) 14:26 (UTC)
- 基於此,上面Ping的人已經有一個給出答覆了(Z7504)。其他人我再重Ping一次。@Liaon98、JyunWaan、Lssrn、Cdip150:@Temp3600、Peacearth、Kethyga、Willy1018:@AT、Shizhao: 能夠給些意見嗎?謝謝。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年4月19日 (五) 15:28 (UTC)
- 所以現在是什麼情況?2402:7500:579:89C4:84ED:51FA:80FD:F1D1(留言) 2024年4月26日 (五) 05:52 (UTC)
- ( π )題外話 我終於見識到條目重要度評級標準的存在感有多低了。L'Internationale, Sera le genre humain! 2024年4月27日 (六) 14:52 (UTC)
- 這其實是一個很不幸的情況......條目評級與條目評審是本站的QC,QC壞了,本站其他的管治水平也可想而知。--Temp3600(留言) 2024年5月5日 (日) 07:20 (UTC)
- ( π )題外話 我終於見識到條目重要度評級標準的存在感有多低了。L'Internationale, Sera le genre humain! 2024年4月27日 (六) 14:52 (UTC)
- 才發現通過了一整個指引。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年4月27日 (六) 15:20 (UTC)
- @A2569875:注意到閣下修改了{{Grading scheme}},添加了一些新的評級,但這些評級全部成為了默認選項。個人認為對於一些小型專題來說,可能不需要這麼多類評級。建議把部分評級改為非默認的選項,只需把對應評級
|trigger=
參數的默認值yes
移除即可。——BlackShadowG Slava Ukraini! 2024年5月3日 (五) 01:34 (UTC)
- en:Wikipedia:Content assessment 有較多的內容,我認為這是因為他們是這個制度的來源地,所以有關於制度的歷史流變等可以寫。中維目前只是引入的制度,還沒有社群的經驗,因此沒有這部分的本地經驗可以立為指引,而只能寫一些硬規定。我認為這暫時不是問題,如日後成熟,自然可以再將這些段落引進,指引名字也可以更改。「頁面質量評級標準」就暫時只寫標準,待評級流程成熟後,就可以加入這一部分的指引。
- 同意將「標準質量評級」與「標準類別級別」分立為兩個三級標題。這是一項不涉及本質的結構修改,不難。
- 流程圖最好有,但要有人來畫...
「通用評級」與「專題評級」的關係:這是我最早就想改寫的部分。既然「通用評級」只可填標準評級而專題評級可以填其他自訂評級,那麼維基百科:通用評級就需要至少修改"若一條目僅有一個專題,其通用評級應與該專題所評的等級一致。",最好是重新理順這一部分的邏輯。
- 整理目前的討論,建議"機器人會根據該頁面最多專題評等的評級等級作為通用評級"繼續保留,但機械人應檢查這會否導致WPBS被評為非正式級別,如發生這種情況,那麼機械人則跳過該條目(可以考慮加入"需要手動進行WPBS評級"的分類),留待人類前來。
- 同意"社群和專題都可以各自獨立地對頁面評級"的基本策略。這樣就解決了list級的問題。即使專題的評級只有list級,WPBS仍可以手動評為更準確的CL/BL等細分級別。由機械人自動評的list級也與這個邏輯沒有沖突。
- 長遠的最終方向是,WPBS作為條目的內容評級,專題評級則為某一方面提供額外的資訊,類似tag.但這個需要將目前的評級邏輯反過來,我猜一兩年也無法完成,就寫在這而已。--Temp3600(留言) 2024年5月5日 (日) 08:10 (UTC)
修訂案[編輯]
- 雖然我累得(今天)打不完整個修訂案,但至少可以生出一個大綱...--Temp3600(留言) 2024年5月5日 (日) 08:28 (UTC)
維基百科:通用評級[編輯]
- 解決「通用評級」與「專題評級」的關係。斷開兩者的上下級關係。
- 通用評級只限填寫標準評級。
- 介紹一些其他功能,例如專題可以自行加入評級,不過這些不屬於WPBS的範圍,將它們指示到其他頁面去。
維基百科:頁面質量評級標準[編輯]
- 對應通用評級的改動,明確兩者間的關係。即: QUALITY負責規定那些級別屬於標準評級,及提供評級的參考。也提供其他非標準級別的介紹。通用評級指引則負責通用評級的流程,由社群負責,為條目的質量提供評級,而專題級模版級等請不要來找WPBS.
- 結構調整,將「標準質量評級」與「標準類別級別」分立為兩個三級標題。
T: Grading scheme[編輯]
- 為所有標準類別補上例子。
後續討論[編輯]
關於 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)
- 我也跟進
- 妥了,看起來YFdyh000的目前跟上游已經同步,還是不要做重複工作比較好(--Ceba_robot 才不是機器人! 2024年2月16日 (五) 18:24 (UTC)
- 目前仍有大量站內頁面連結至User:Chiefwei/rater,建議更新。--Temp3600(留言) 2024年3月3日 (日) 07:57 (UTC)
- 還真不知道rater.js有這東西,但這個社群對於專題過往都是冷漠處理的,沒想到近幾個月開始變得重視了。沒差,評級功能不要影響到就好,多說可能無益。--Z7504非常建議必要時多關注評選(留言) 2024年4月18日 (四) 13:47 (UTC)
管理人員申請預討論[編輯]
工單準備[編輯]
這裡有一點需要注意的內容。首先,根據Wikipedia:徵求意見/2024年管理人員制度改革#議案2B:處理合併選舉規則不清晰問題,新投票界面應包含類似「管理人員選舉無當選限額,各候選人分開計票,支持票不限於一票」的指引。其次需要考慮到Wikipedia:徵求意見/2024年管理人員制度改革#議案2A:合併選舉存廢中所討論的可否拆分。同時,根據上方討論關於WT:ARBCOM#問卷的說法,同時包含關於仲裁委員會的調查問卷(不是選擇,而是填文字回答):
管理人員解任在多大程度由仲裁委員會處理?
- 甲、仲裁委員會按調查事實及方針指引,直接作出除權決定。
- 乙、由仲裁委員會調查事實並發佈管理人員操守報告,確認存在違規事實後,才轉交社群決議除權。
- 丙、仲裁委員會完全不參與管理人員解任。
歡迎討論。0xDeadbeef (留言) 2024年4月3日 (三) 12:42 (UTC)
- 請問這個是指提交給仲裁委員會的案件,還是所有RFDA案件?--桐生ここ★[討論] 2024年4月3日 (三) 14:48 (UTC)
- 路西法人的意見是所有RFDA經過ARBCOM,我的意見是RFDA和ARBCOM不互相影響。這個問題或許也可以添到工單上。--0xDeadbeef (留言) 2024年4月4日 (四) 00:52 (UTC)
- 贊同你的意見「RFDA和ARBCOM不互相影響」,支持添加到工單上。--桐生ここ★[討論] 2024年4月4日 (四) 03:44 (UTC)
- 這需要另行草擬問題。我覺得此問題本身可以先加上定語,只涵蓋由仲裁委員會經手處理者(也就是原本社群提出者另議),以避免混淆。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年4月4日 (四) 09:35 (UTC)
- 贊同你的意見「RFDA和ARBCOM不互相影響」,支持添加到工單上。--桐生ここ★[討論] 2024年4月4日 (四) 03:44 (UTC)
- 路西法人的意見是所有RFDA經過ARBCOM,我的意見是RFDA和ARBCOM不互相影響。這個問題或許也可以添到工單上。--0xDeadbeef (留言) 2024年4月4日 (四) 00:52 (UTC)
- 可附上相關討論連結。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年4月4日 (四) 09:35 (UTC)
- 我還是比較同意上方說Eric Liu說
如果只是希望給意見,那還不如改成通告,直接請大家去討論頁留言互動,而不是事後再個別整理幾條留言。
的說法。這樣附上留言的方式不便於詳細展開討論。--Ghren🐦🕐 2024年4月4日 (四) 17:24 (UTC)- 如是者,我不清楚你們這個問卷調查是是不是要匿名徵求意見。如果答案為是,可考慮加入工單;如是答案為否,我建議在管理員選舉的說明中提及+MMS即可。--春卷柯南-發前人所未知 ( 論功行賞 ) 2024年4月4日 (四) 22:35 (UTC)
- 據說是匿名徵求意見--0xDeadbeef (留言) 2024年4月5日 (五) 01:37 (UTC)
- Why not both?匿名收集意見方便整合各方觀點,也撇除了發言者身份的觀感,方便往後只針對觀點討論;MMS內引導亦可即時邀請更多用戶參與相關討論。--路西法人 2024年4月5日 (五) 01:42 (UTC)
- 我想即使是在一般的頁面討論,也應該要做到「整合各方觀點」和「對事不對人」這兩件事吧。匿名收集意見不是完全對以上兩點沒有幫助,只是作用很少而已。--Ghren🐦🕒 2024年4月5日 (五) 07:13 (UTC)
- 不試試怎麼知道有沒有幫助呢?what's the worst that can happen?沒有人提意見?沒有有價值的意見?那又怎樣。結果出來整合一下大家的意見,再公開討論也還好吧。--0xDeadbeef (留言) 2024年4月5日 (五) 10:26 (UTC)
- 我想即使是在一般的頁面討論,也應該要做到「整合各方觀點」和「對事不對人」這兩件事吧。匿名收集意見不是完全對以上兩點沒有幫助,只是作用很少而已。--Ghren🐦🕒 2024年4月5日 (五) 07:13 (UTC)
- 如是者,我不清楚你們這個問卷調查是是不是要匿名徵求意見。如果答案為是,可考慮加入工單;如是答案為否,我建議在管理員選舉的說明中提及+MMS即可。--春卷柯南-發前人所未知 ( 論功行賞 ) 2024年4月4日 (四) 22:35 (UTC)
- 根據phab:T358067的時間軸,此次管理人員選舉的投票時間只能夠在5月初開始。我們有可能需要更新一下投票時間。--1233 (T / C) 2024年4月9日 (二) 06:51 (UTC)
- 依據現行指引,獲得正式提名之時,必須立即置申請子頁面,且一定要在四月二十八日前完成安全投票籌備。顯然此規定無法實現,彈性過低,事後大概需要一併檢討。至於是次申請的處理方法,我認為可以經全體被提名者同意(或至少予以知會),請行政員宣告因現行規定窒礙難行,延後討論期及投票期。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年4月11日 (四) 12:33 (UTC)
- 副知@Manchiu、UjuiUjuMandan、ASid、ATannedBurger、SickManWP。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年4月11日 (四) 12:34 (UTC)
- 本人已於昨晚宣佈退選,故私以為不用為本人建立RFA子頁面。我認為現時可以為四位候選人建立RFA子頁面,這樣就能提早進入發問環節,爭取更多時間讓社群了解候選人的觀點及立場。--維基病夫邀請您加入❤️邊緣人小組·🖊️簽到 2024年4月11日 (四) 12:38 (UTC)
- 支持先進入提問期。--桐生ここ★[討論] 2024年4月11日 (四) 16:10 (UTC)
- 但提早進入,也提早結束,我認為申請應反映社群最新共識變動,所以越遲開始越好。無論如何,在大家還沒商定期限以前,都不應該逕行開始。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年4月11日 (四) 16:28 (UTC)
- 個人認為可延長提問期以增加關注度。理論上當前條文為
在被提名者經行政員確認獲得正式提名之時起二週內,任何使用者都可以發表意見,包含提問及討論等
,不過考量到此條自2006年以來就已設立,個人認為此根據自由意志的二週
提問期限(若不是因自由意志所設立,我也很有興趣知道為什麼不是)已無法實際符合當前RFA的狀況,包括因SecurePoll所導致的各種選舉過程延宕的情況。 - 個人會希望提問期可從設立RfA子頁面開始至投票前一到二週結束,而之所以留空一到兩週的目的是作為緩衝並希望候選人能回答完所有問題。嘛,當然,這個提案很有可能會導致候選人需要答題的數量變多,但可透過其他措施如限制問題數量至一人三問或其他方式來進行改善。--(☎)dt 管理員競選中 2024年4月14日 (日) 07:41 (UTC)
- 個人認為可延長提問期以增加關注度。理論上當前條文為
- (及@AT)—— Eric Liu 創造は生命(留言・留名・學生會) 2024年4月11日 (四) 16:28 (UTC)
- 再副知其他行政員@Ffaarr、Jimmy Xu、Kegns、Shizhao、Wing、Wong128hk。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年4月11日 (四) 18:56 (UTC)
- 本人已於昨晚宣佈退選,故私以為不用為本人建立RFA子頁面。我認為現時可以為四位候選人建立RFA子頁面,這樣就能提早進入發問環節,爭取更多時間讓社群了解候選人的觀點及立場。--維基病夫邀請您加入❤️邊緣人小組·🖊️簽到 2024年4月11日 (四) 12:38 (UTC)
- 千村狐兔(留言) 2024年4月11日 (四) 15:09 (UTC) 已知悉。辛苦。-
- 感謝告知,辛苦了謝謝。--~~Sid~~ 2024年4月11日 (四) 15:43 (UTC)
- 副知@Manchiu、UjuiUjuMandan、ASid、ATannedBurger、SickManWP。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年4月11日 (四) 12:34 (UTC)
- @Ericliu1912 @Shizhao @ATannedBurger 距離五月不足兩周了,本人認為應該開始討論期(最好是4月21日),直到投票準備就緒為止。鐵膠壹名 2024年4月18日 (四) 08:36 (UTC)
- 依據現行指引,獲得正式提名之時,必須立即置申請子頁面,且一定要在四月二十八日前完成安全投票籌備。顯然此規定無法實現,彈性過低,事後大概需要一併檢討。至於是次申請的處理方法,我認為可以經全體被提名者同意(或至少予以知會),請行政員宣告因現行規定窒礙難行,延後討論期及投票期。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年4月11日 (四) 12:33 (UTC)
- @Manchiu @UjuiUjuMandan @AT @ASid @ATannedBurger 行政員已完成申請資格覆核,現已建立對應的選舉頁面(Manchiu、UjuiUjuMandan、AT、ASid、ATannedBurger),唯根據上面的討論,提問時間尚未開始。鐵膠壹名 2024年4月14日 (日) 07:11 (UTC)
- 辛苦了--(☎)dt 管理員競選中 2024年4月14日 (日) 07:16 (UTC)
- 今天已經是4月23日(UTC+8),各候選人的RFA界面也都已經完成設立,本討論自一周前已無更新內容。若按照工單中所述,4月26日直接進入投票期,是否意味着提問時間將與投票期重合?還是說社群有其他關於提問期及投票期之決議?--SheltonMartin留言|簽名 2024年4月23日 (二) 02:03 (UTC)
- @阿南之人 @SheltonMartin 根據phab:T358067,U4C的投票目前為第一優先級(由4月26日到5月9日),考慮到討論期一般開啟七天,如開啟太長時間的話會給參選的人帶來不必要的壓力,則最早討論期應由5月3日開啟,在中維選舉在U4C選舉之後立即開始的情況下。--0xDeadbeef (留言) 2024年4月23日 (二) 12:23 (UTC)
- (而U4C的投票還要點票這個事情,我建議先等U4C的投票點票結束再考慮什麼時候開啟討論。)--0xDeadbeef (留言) 2024年4月23日 (二) 12:26 (UTC)
- 1. 請社群討論,是否有必要在揭示板或其他地方對討論期及投票期的時間節點作出更清晰的說明?
- 2. 先前有編輯提出延長討論期的動議,社群是否考慮付諸討論?
- 3. 建議明確後續管理人員任免投票的時間節點(如在某月第某周開啟),對中維的大部分用戶而言,U4C的投票能有多大限度影響中維的管理人員任免存疑,而且似乎也沒有看到各語言維基需避開U4C或類似選舉的規定或先例。
- 以上。--SheltonMartin留言|簽名 2024年4月24日 (三) 00:27 (UTC)
U4C的投票能有多大限度影響中維的管理人員任免存疑
- votewiki在U4C投票期間是英文,而一般中維投票時會改為中文。你要覺得大家能看着英文投票就沒事。- 別的語言維基又不用SecurePoll。--0xDeadbeef (留言) 2024年4月24日 (三) 08:17 (UTC)
- @Manchiu、UjuiUjuMandan、ASid、ATannedBurger:不然設五月一日至十四日為正式討論期,十五日至二十八日為投票期?—— Eric Liu 創造は生命(留言・留名・學生會) 2024年4月24日 (三) 07:57 (UTC)
- 可--(☎)dt 管理員競選中 2024年4月24日 (三) 08:02 (UTC)
- OK。 --ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨᡩ᠋ᠠᠨMandan 2024年4月24日 (三) 08:39 (UTC)
- 已更新選舉頁面。鐵膠壹名 2024年4月24日 (三) 09:43 (UTC)
- @阿南之人 @SheltonMartin 根據phab:T358067,U4C的投票目前為第一優先級(由4月26日到5月9日),考慮到討論期一般開啟七天,如開啟太長時間的話會給參選的人帶來不必要的壓力,則最早討論期應由5月3日開啟,在中維選舉在U4C選舉之後立即開始的情況下。--0xDeadbeef (留言) 2024年4月23日 (二) 12:23 (UTC)
- 好。辛苦諸位。-千村狐兔(留言) 2024年4月24日 (三) 23:30 (UTC)
- @Manchiu @UjuiUjuMandan @ASid @AT @ATannedBurger 今天討論+提問時間正式開始。請各用戶和候選人做出準備。L'Internationale, Sera le genre humain! 2024年5月1日 (三) 03:32 (UTC)
- SCP-0000(留言) 2024年5月13日 (一) 15:32 (UTC)
- 那麼提問環節是相應延長?已有候選人表示提問壓力甚大…-千村狐兔(留言) 2024年5月14日 (二) 09:45 (UTC)
- 本人認為停止提問,但可以繼續在意見區討論。L'Internationale, Sera le genre humain! ✏️ 2024年5月14日 (二) 09:51 (UTC)
- 提問環節的長度是有規定的,我認為不宜延長。同意上面的見解。Sanmosa 全方貧工之聯合 2024年5月14日 (二) 09:54 (UTC)
- 無論如何,感謝千村狐兔(留言) 2024年5月15日 (三) 02:31 (UTC) SCP-2000君辛勞。-
- 既然社群無異議,現暫定5/29 - 6/12舉行,謝謝。--SCP-0000(留言) 2024年5月15日 (三) 06:06 (UTC)
- 提問,若5/29 T&S仍未回復,投票期是否會繼續延長?--SheltonMartin留言|簽名 2024年5月16日 (四) 05:25 (UTC)
考慮到設立選舉的準備尚未完成(投票者列表相關 query 仍在執行,且 T&S 仍未回覆),個人建議投票期由5/15延遲至兩週後,即5/29舉行?副知候選人。謝謝。-- - 那麼提問環節是相應延長?已有候選人表示提問壓力甚大…-千村狐兔(留言) 2024年5月14日 (二) 09:45 (UTC)
- SCP-0000(留言) 2024年5月18日 (六) 01:56 (UTC)
- 知悉,辛苦!-千村狐兔(留言) 2024年5月18日 (六) 02:25 (UTC)
- 知悉,有勞通知。--J.Wong 2024年5月27日 (一) 01:04 (UTC)
T&S 回覆稱可在 5/29 - 6/12 期間舉行選舉。另外,由於運動憲章批准投票於 6/25 開始,技術上行政員不能作出延長選舉一週的做法。副如候選人及監督員。謝謝。-- - @AT @ATannedBurger @ASid @Manchiu @UjuiUjuMandan 再次通知候選人,投票已經於8:00開始。雖然是我八點二十多補上投票鏈接的 L'Internationale, Sera le genre humain! ✏️ 2024年5月29日 (三) 00:39 (UTC)
- 投票今天結束,請@SCP-2000以及其他監督員@Jimmy Xu @Wong128hk 點票並結束選舉。留意通過的新指引,超過75%者可以當選,超過65%的管理員者可授予臨時管理員6個月。L'Internationale, Sera le genre humain! ✏️ 2024年6月12日 (三) 04:15 (UTC)
- 註:僅有Wong128hk和Jimmy Xu兩位監督員有權限在安全投票介面點票。謝謝。--SCP-0000(留言) 2024年6月12日 (三) 05:07 (UTC)
- 需要T&S授權方能完成點票流程。--J.Wong 2024年6月12日 (三) 07:14 (UTC)
- 管理員選舉已經結束,等候存檔。L'Internationale, Sera le genre humain! ✏️ 2024年6月13日 (四) 03:52 (UTC)
這裡有兩個問題。第一、徵求意見內容實際上並未經公示通過,措辭亦有商榷之虞(包含上方早已提出之若干意見,以及事後他人提出翻譯腔問題等),由於程序不夠完備而無法及時調整;且此次投票本因故延長,還有更多時間(一個多月)準備,既非匆忙間不能顧及者,則更不應該如此才是。本人要求嚴正檢討改進程序問題。第二、有人無法投票,或許是因為合格選舉人名單過時而未更新。此為極嚴重之差錯,請社群立即協助處理。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年5月29日 (三) 06:40 (UTC)
- @Ericliu1912、RiceKing: 已請求增加至投票者列表。--SCP-0000(留言) 2024年5月29日 (三) 06:57 (UTC)
- @RiceKing: 已增加,請問能否正常投票?--SCP-0000(留言) 2024年5月29日 (三) 07:41 (UTC)
- @SCP-2000@Ericliu1912:現在可以了,感謝二位!--Rice King 信箱 · 留名.邊緣人 2024年5月29日 (三) 07:41 (UTC)
- 這邊也問一下協助設立選舉的相關用戶@SCP-2000、阿南之人:候選人自己選舉的投票是否和上次一樣,在最後結算的時候減一票支持以抵銷候選人投給自己的票?--(☎)dt 管理員競選中 2024年5月30日 (四) 13:13 (UTC)
- @ATannedBurger:與監督員 Wong128hk 討論中。--SCP-0000(留言) 2024年5月30日 (四) 13:28 (UTC)
- 見目前投票頁是分立,所以為什麼會有候選人投票予自己之情況?
- 理論上,結算時可以將特定用戶之選票刪去。--J.Wong 2024年6月2日 (日) 02:45 (UTC)
對新用戶禁用內容翻譯工具(續)[編輯]
原討論存檔見此:Wikipedia:互助客棧/其他/存檔/2024年3月#對Phabricator的回應
以下為Pginer-WMF的最新回應:
Perfect. I think we can plan to introduce these changes. We plan to introduce these in iterations.
- Limit publishing into the main namespace to "extended confirmed users" only.
- Get input from the community on the effects, for the community to decide whether to make the restriction more/less strict.
- Make machine translation non-default.
In this way we can have a better understanding on the effect of each of the changes and how to adjust them.
簡單而言,他們將作出以下更改:僅允許延伸確認用戶將翻譯發佈到主命名空間,並願意之後依社群意見將限制調整成更嚴格 / 寬鬆;以及機械翻譯設為非預設選項。
SCP-0000(留言) 2024年3月23日 (六) 13:27 (UTC)
考慮到他們的提議與過去討論的共識(即禁止翻譯發佈到主命名空間及機翻設為非預設)相近,如果一週後沒有任何異議,即視為社群同意他們的提議。副知所有曾參與討論的編者。謝謝。--- 沒問題。--日期20220626(留言) 2024年3月23日 (六) 13:33 (UTC)
- 應該可以。--冥王歐西里斯(留言) 2024年3月23日 (六) 14:20 (UTC)
- 挺好,我收到了郵件但都忘了這事了。--MilkyDefer 2024年3月23日 (六) 15:01 (UTC)
- 好。 -Lemonaka 2024年3月23日 (六) 16:56 (UTC)
- 非常好。——Aggie Dewadipper 2024年3月23日 (六) 19:55 (UTC)
- 他們願意退讓是可以就此參考他們的意見啦--SunAfterRain 2024年3月24日 (日) 14:16 (UTC)
- 贊同。--桐生ここ★[討論] 2024年3月24日 (日) 16:51 (UTC)
既然已有多人同意此變更,且正如上方提到他們的提議與過去的共識相近,故依照 WP:SNOW 視社群同意他們的提議,並已在 phab 反映社群的意願。謝謝。--SCP-0000(留言) 2024年3月24日 (日) 14:29 (UTC)
- 不反對如此配置。但扒了三個有使用內容翻譯工具的直出主條目空間的成品(中國的動物福利和權利、自由意志民主黨人、傑克遜·欣克爾 ),我還是覺得禁用了可能更好。 囧rz……——Sakamotosan路過圍觀 | 避免做作,免敬 2024年3月25日 (一) 08:15 (UTC)
- 目前方案通過後第一個條目不會直接輸出到主空間,因為作者的編輯數量還達不到延伸用戶的級別。所以至少擋掉三分之一了,不錯了。--日期20220626(留言) 2024年3月25日 (一) 08:20 (UTC)
- 如果可以,不知能否幫忙整理使用內容翻譯而有問題的條目?這樣方便與基金會溝通時,有相關例子可供他們參考及研究。謝謝。--SCP-0000(留言) 2024年3月25日 (一) 16:44 (UTC)
- 感覺被G13的多少都是內容翻譯的條目。。。—-Aggie Dewadipper 2024年3月25日 (一) 18:39 (UTC)
- 偶爾也有非內容翻譯的條目被掛G13。--日期20220626(留言) 2024年3月25日 (一) 22:26 (UTC)
- 感覺被G13的多少都是內容翻譯的條目。。。—-Aggie Dewadipper 2024年3月25日 (一) 18:39 (UTC)
- @SCP-2000:用RTRC找主條目空間、新建頁面(因為原生最近更改不方便找新建頁面)、標籤為「內容翻譯」、「內容翻譯2」的,應該會存在不少。例如找到一篇喬安娜·斯丁格蕾(oldid=82028905)。好像最近多了一批沒用戶頁的新用戶在用這個系統來翻譯,而且首次格式質量都存在或多或少同類問題(包括斜體、數字間空格、參考註腳之間空格或者參考複製的一些格式暴露(<cite>這種)、缺少參考列表,部分還有格式紊亂、模板丟失)雖然這些問題是新頁面巡查員應該去做的事……——Sakamotosan路過圍觀 | 避免做作,免敬 2024年3月26日 (二) 02:15 (UTC)
- 根據提案,新用戶已經無法通過內容翻譯直接在主空間生成條目。--日期20220626(留言) 2024年3月26日 (二) 03:31 (UTC)
- 只是提供收集說服來源的方法。當然希望拉高下限能擋住一部分藉助該系統粗製濫造的低質量翻譯條目。——Sakamotosan路過圍觀 | 避免做作,免敬 2024年3月26日 (二) 13:15 (UTC)
- 根據提案,新用戶已經無法通過內容翻譯直接在主空間生成條目。--日期20220626(留言) 2024年3月26日 (二) 03:31 (UTC)
- 另外,感覺User:New user message不會對不是以本項目註冊的新用戶發自動歡迎的(例如找到的User:賽博崔會遇見電子鋁黃瓜嗎、User:Art4cn),有可能導致新用戶缺乏對格式規則的了解。——Sakamotosan路過圍觀 | 避免做作,免敬 2024年3月26日 (二) 02:26 (UTC)
- 這個改配置即可,可以在其建立本地賬號時發送。個人認為至少其有一個編輯在發送會好些?(改配置噩夢)--Hualin🎗️希望の星は青霄に昇る Commons|Talk 2024年3月30日 (六) 22:34 (UTC)
- What the hell is that? -Lemonaka 2024年3月30日 (六) 01:21 (UTC)
- In general, Content translation will redirect users to their chosen language of wiki, even if they use it on zhwiki. So I don't think it's the content translation's fault, but I have no idea how they can do that :)--SCP-0000(留言) 2024年3月30日 (六) 07:45 (UTC)
內容翻譯現已縮緊[編輯]
(註:複製自WP:互助客棧/消息#內容翻譯現已縮緊,原由User:MilkyDefer發布。)
自4月10日(三)起,只有擁有延伸確認權限的使用者可以使用內容翻譯功能將頁面發布到主條目空間。這次調整是因應近期多發的粗濫翻譯問題所做出的。延伸確認權限自動授予註冊滿90天且編輯滿500次的編者,以及管理員。
請巡查員和所有編者留意這次更改後,翻譯條目的品質是否有改善。其結果會決定是否採取下一階段的措施:將「從原文開始」設定為默認翻譯選項。
SCP-0000(留言) 2024年4月11日 (四) 17:11 (UTC)
副知所有曾參與討論的編者。謝謝。--- phab:T349959#9711650,疑似未生效。--碟之舞📀💿 2024年4月14日 (日) 07:50 (UTC)
- 不過好像數量並不多。--日期20220626(留言) 2024年4月14日 (日) 07:58 (UTC)
- 原因也大致抓到了,Special:PermanentLink/82270024#L-111應該能當臨時補丁--SunAfterRain 2024年4月14日 (日) 14:35 (UTC)
- 並沒有生效:Special:用戶貢獻/EitanVel。上面的patch有管理員review下麼?--Tim Wu(留言) 2024年4月19日 (五) 01:36 (UTC)
- @SunAfterRain Not applied till now, Special:Contributions/Hueydome88E92 -Lemonaka 2024年4月21日 (日) 10:52 (UTC)
- phab:T349959#9734223 patch backports in today. 雖然我是不知道他們說的移植後仍然有問題是甚麼意思,畢竟我剛才看的結果確實有正確攔截到了...--SunAfterRain 2024年4月23日 (二) 12:39 (UTC)
- 確實還沒有修正,如火腿黃油三明治。--SCP-0000(留言) 2024年4月24日 (三) 03:51 (UTC)
- phab:T349959#9734223 patch backports in today. 雖然我是不知道他們說的移植後仍然有問題是甚麼意思,畢竟我剛才看的結果確實有正確攔截到了...--SunAfterRain 2024年4月23日 (二) 12:39 (UTC)
- 目前為止未見有非延伸確認用戶能發布條目至主條目空間,似乎已被修正。另外,現時僅限制發布權限,而沒有限制使用機翻的權限,草稿仍大機會存在翻譯質素低下的問題,煩請各位注意翻譯條目的品質有否改善。如果一個月後沒有任何意見,則會讓此討論自動存檔。副知所有曾參與討論的編者。謝謝。--SCP-0000(留言) 2024年5月23日 (四) 08:15 (UTC) 補丁已於5/15部署,
- 一月似過久,二週何如?—— Eric Liu 創造は生命(留言・留名・學生會) 2024年5月23日 (四) 12:20 (UTC)
- 兩星期未必足夠觀察其變化及影響,且此討論非急需結案或關閉。--SCP-0000(留言) 2024年5月23日 (四) 16:31 (UTC)
Unblock-zh.org[編輯]
很久以前討論過的一個項目,也就是unblock-zh的網站版,我最近給他做出來了,如果對測試版軟件感興趣的話,請去 https://unblock-zh.org 這裡去看看。(注意測試版軟件,你的用戶最後很可能被刪掉!)
附帶一個教學視頻 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)
- 在這裡沒有看到可以使用oauth給用戶添加組別的選項,那麼也是說IPBE的授予只能透過abot進行了。Bluedeck 2024年5月1日 (三) 21:41 (UTC)
- 用API能查IP有沒本地封或者全域封,好像不是必要。——Sakamotosan路過圍觀 | 避免做作,免敬 2024年4月30日 (二) 02:26 (UTC)
- 一鍵創建賬戶/授予PIBE的話,有兩種途徑。第一,管理員通過oAuth授權unblock-zh.org,通過管理員賬戶操作,然後從本地日誌看來,操作者是管理員。第二種途徑是,成立一個機器人賬戶,比如名叫 unblock-helper-abot,並且賦予機器人管理權限,然後通過機器人操作,並在摘要里說明是根據哪個管理員的指令操作的。讓我來決定的話,我傾向於使用第二種方式,因為我希望儘量不要向第三方授權我自己的賬戶,但是第一種方式的日誌更加清晰。請問一下其他人的想法。Bluedeck 2024年4月29日 (一) 17:39 (UTC)
- 讚 讚 讚 牛逼--Dnaimfz(留言) 2024年5月11日 (六) 04:04 (UTC)
- 管理員布告板抄送一份通知連結至此?—— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月1日 (六) 08:43 (UTC) 話說可給
- 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)
- 以我個人看法,部屬在CloudVPS的隱私疑慮絕對會比一個外部網站好很多,當然你維社群願意接受那我也沒什麼意見就是了。雖然不清楚是筆誤還是什麼的,如果開銷太小的話我自己是會考慮換過去啦。--SunAfterRain 2024年6月10日 (一) 17:54 (UTC)
想好奇請問是否有考慮過部屬在 - 管理員通告版:不知道效果會怎麼樣啊。等上線後在ASN通告一下,然後TG呀IRC呀廣播一下應該就行。CloudVPS:他的介紹說自己是標準的VPS,但是又有跡象表明他不是完全標準的環境,導致我不想把時間花在部署,測試,更換環境,以及踩坑上面。對我來說,寫軟件是趣味十足的事情,而調試環境則是讓我胃腸不適的事情。目前我沒有換環境的需求,因為開銷太小。如果有我再考慮cloudvps。cloudvps的另一個問題是只有在virginia有DC,但這不是一個大問題。Bluedeck 2024年6月8日 (六) 04:00 (UTC)
試運行[編輯]
在過去的幾周里,我增加了最後的一些的功能,分別是1)按日期搜索排列工單;2)郵件回復模板;3)管理員刪除工單、刪除消息界面;4)用戶改名功能。我想知道大家覺得還缺少哪些網站本身的功能(郵件服務器、機器人授予IPBE除外)。如果感覺差不多了,那麼可以進行試運行。試運行期間,再對可能發現的新的功能需求進行補充。試運行的提議正在進行公告。如果通過,將會將網站首頁文字改為試運行,並暫時移除一些只具有展示效果的鏈接,然後在用戶無法註冊的提示頁面加入網站的鏈接,這些操作大概最多需要一天就能完成。在試運行決議通過前,如果對網站有任何問題,歡迎在此討論。Bluedeck 2024年5月13日 (一) 23:30 (UTC)
- 功能方面,個人認為管理員不應該有刪除工單的能力,這個應該由維護者來做,比如遇到spam/擾亂性工單就打上相應的標籤,若干天后自動刪除;可不可以出個statistics大概寫一下某月某人處理了多少工單之類的;反spam方面怎麼樣,你覺得需要加個recaptcha嗎;模板建議是放到Github或者類似公開的地方,需要改的人發pr;可以考慮加一個link/merge功能麼,比如一個用戶就一個問題發了多個ticket,這個時候可以把它們關聯起來;感覺可以把login改的小一點,或者讓非管理人員意識到不需要登錄就可以發ticket。
- 另外就是建議放到toolforge或者cloud VPS上。順便問個問題,你覺得這個系統需要承擔unblock-zh最原始的封禁申訴職能嗎 Stang★ 2024年5月14日 (二) 01:47 (UTC)
- 謝謝提議!簡短回應:
- 刪除工單就是為了應對擾亂才設計的功能。刪除之後可以恢復或檢視。(UI需要另外添加)工單的永久保留或刪除問題在下面討論。
- 反spam:UTRS目前是阻止同一個IP地址多次發送工單。但是我的方案不記錄IP地址,無法阻止。我可以考慮一下記錄ip地址的hash,並由此進行rate limit。我個人完全不喜歡captcha,除非不得已,我可能會考慮上captcha。在此之前我會儘量用其他手段處理spam問題。我有一些asymmetric proof of work的方法能防止自動化的spam。如果有人無聊到要手工spam,那麼唯有記錄IP並進行區段查封這一個辦法。(但是這樣一來,不就把本身的目的給擊敗了??)
- 郵件模板:我不會放在github,畢竟不是每個管理員都會開PR,我簡單的開一個用戶頁面存儲目前的模板,誰想添加,給我留個言即可。郵件模板都是非常簡單的純文字模板。當然,如果你喜歡用gh,那麼在前端的repo里有一個文件,你也可以直接PR這個文件。
- link/merge:race condition太多,最多做成stack overflow/github issues那樣,「標記為#109的duplicate。關閉」這種解決方案。
- login改小:我肯定會讓新用戶看到不login就能發工單,這是一個重要的因素。
- statistics:這個我一定會做,因為這會讓處理工單變得很有趣,我的設想是做一個leaderboard,能夠激發人們對於處理工單的無限潛能,哈哈哈哈。
- Hosting:toolforge不能滿足我的要求,CloudVPS不熟悉。將來打算支持圖片上傳,需要一個能掛載S3的環境,另外多區域host允許你把服務器託管在東京/首爾/LA。目前,服務器託管在Vultr的新澤西區上面。
- 這個網站做成網站的形式,是為了新用戶方便的註冊+IPBE(也就是unblock-zh-ipbe的功能)。處理被長期封禁的用戶在郵件列表中50-100封郵件那麼長的申訴,並不是網站初衷。如果有人就是要在網站上申訴,管理員也選擇在網站上處理,那我不會站出來阻止,但是如果網站上出現了對維基百科歷史有一定意義的討論內容,我覺得有應當抄送一份到郵件列表。
- Bluedeck 2024年5月14日 (二) 04:12 (UTC)
- update: 已經增加了查看和恢復已刪除工單的功能。Bluedeck 2024年5月19日 (日) 06:40 (UTC)
另外還有兩個別的需要討論的問題:
- 工單是否永久保存?永久保存是目前的默認,而且郵件列表也是永久保存的。但是我覺得比如掛上「處理結束」標記90/180天之後永久刪除相關信息這個是更安全的做法,想徵求一下大家的意見。
- 開源:從一開始我就設想開源。這個項目有4個repo,其中3個可以在最近開源。一個需要我檢查一下有沒有API Key之類的物品遺落在代碼中,然後才能開源。請期待。
- 共同參與:如果您想共同參與開發,或者參與對服務器的運維,歡迎在這裡提出來。Bluedeck 2024年5月14日 (二) 04:49 (UTC)
- 感謝貢獻,整體非常完善。如有需要可以協助維護。--Borschts™ 歡迎外帶一碗羅宋湯 2024年5月14日 (二) 13:32 (UTC)
- 存檔應保留,只是可以限制普通使用者存取。另外,也應考慮先行在站內撰寫說明頁面,或補充現有方針與指引不足,以便利用。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年5月14日 (二) 15:05 (UTC)
- 注意到兩點可以改善:
- 無法創建帳號者不應提供「我不想提供郵箱」的選項,創建帳號時需填寫對方電郵地址才能安全發送臨時密碼。如果不想提供郵箱則難以協助創建帳號。
- 需要添加提示文字,若不提供IP地址則申請有可能不獲受理(始終審批IPBE時需要驗證用戶是否使用proxy)。
- --路西法人 2024年5月15日 (三) 07:52 (UTC)
- 我腦海中預想的不提供郵件的處理方式:網站生成一個強的隨機密碼並記錄在工單中,用戶通過隨機密碼登入。優點:用戶不需要郵箱地址。缺點:不提供郵箱的用戶等於需要不斷的刷新頁面查看處理進度,是一個糟糕的體驗。對於管理員,需要複製粘貼網站生成的密碼來創建賬戶,也是多了一個步驟。上面我只是說明了操作的可行性,至於這個功能是否保留,可以繼續討論決定。對於第二點,IPBEG如果有這個要求,那我完全可以添加這個提示文字(甚至可以在維基百科設置一個頁面,比如Template:Unblock-zh/strings/new-ticket-notice,然後網站可以反映這個頁面的任意文字。)Bluedeck 2024年5月19日 (日) 06:22 (UTC)
- 我的想法是只要有任何第三方人員可以接觸到任何密碼的方案都是不安全的,尤其在發送郵件時在此類第三方網站留存臨時密碼亦是相當危險的;即使我信任你會盡力保障網絡安全,但顯然不安全的操作應儘可能完全避免。郵件、代理IP地址等都尚算不太危險的資訊,密碼真的不行。--路西法人 2024年5月21日 (二) 01:25 (UTC)
- 我想了一下覺得你說得很有道理。如果有的用戶收到臨時密碼後不加更改,那麼等於這個用戶的密碼永遠的掛在一個所有管理員都能看到的地方,是不妥的。我已經把界面改成如果請求賬戶,必須提供郵箱,否則無法提交。Bluedeck 2024年5月21日 (二) 01:50 (UTC)
- 我的想法是只要有任何第三方人員可以接觸到任何密碼的方案都是不安全的,尤其在發送郵件時在此類第三方網站留存臨時密碼亦是相當危險的;即使我信任你會盡力保障網絡安全,但顯然不安全的操作應儘可能完全避免。郵件、代理IP地址等都尚算不太危險的資訊,密碼真的不行。--路西法人 2024年5月21日 (二) 01:25 (UTC)
- 我腦海中預想的不提供郵件的處理方式:網站生成一個強的隨機密碼並記錄在工單中,用戶通過隨機密碼登入。優點:用戶不需要郵箱地址。缺點:不提供郵箱的用戶等於需要不斷的刷新頁面查看處理進度,是一個糟糕的體驗。對於管理員,需要複製粘貼網站生成的密碼來創建賬戶,也是多了一個步驟。上面我只是說明了操作的可行性,至於這個功能是否保留,可以繼續討論決定。對於第二點,IPBEG如果有這個要求,那我完全可以添加這個提示文字(甚至可以在維基百科設置一個頁面,比如Template:Unblock-zh/strings/new-ticket-notice,然後網站可以反映這個頁面的任意文字。)Bluedeck 2024年5月19日 (日) 06:22 (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)
- 2) 啊那就是提前提示創建工單時未提供電子郵件的須放空? ——魔琴[身份聲明 留言 貢獻 新手2023] 2024年5月27日 (一) 06:29 (UTC)
- 統一回復。1)login界面有意如此設計。2)必須同時輸入工單號和郵件,否則任意人士可以通過廣泛查詢郵件探知私密工單。3)UA信息只有CU才能訪問,所以顯然不能提供。另外就算用戶主動提供了,那麼IPBE處理者拿什麼進行比對呢?畢竟你又看不到LTA的UA。Bluedeck 2024年5月27日 (一) 06:11 (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)
工單的永久刪除[編輯]
目前沒有這個功能。不過,根據歐盟GDPR要求,在用戶請求的情況下,應該提供一種方法永久移除其個人信息。我想讓管理員能夠在工單上添加一個標記,被標記的工單約一個月後真正的刪除。刪除真正執行前可取消。這種刪除只應該在特別的情況下進行(也就是用戶請求)。(也可以單獨只允許行政員執行真正刪除,但是我覺得管理員已經足夠可信,並且還有一個緩衝期間。)Bluedeck 2024年5月31日 (五) 23:04 (UTC)
- 這個功能不錯。( π )題外話:我想知道維基百科不能刪除賬號是否符合GDPR,以及即使OS似乎也不是真刪除,這是否符合GDPR。有人去舉報一下是不是基金會就會實現這個功能了。--桐生ここ★[討論] 2024年5月31日 (五) 23:25 (UTC)
- 應該是不符合的,而且顯示未登錄用戶ip這個似乎也有一定問題。然而我們要團結一致,不要把基金會舉報給歐盟。Bluedeck 2024年6月1日 (六) 05:34 (UTC)
讓 IPBEG 在 Unblock-zh 上獲得和管理員一樣的權限[編輯]
因為我覺得 IPBE 也是一大痛點,所以我覺得讓 IPBEG 能夠一起幫助處理會大有裨益。現在拋出幾個方案討論:
- 讓IPBEG組和管理員同在unblock-zh.org/zhwp下有一樣的(或者接近的)權限。
- 像郵件列表一樣,單獨新建 unblock-zh.org/zhwp-ipbe空間。
- 網站面向用戶的界面不改變,根據用戶是否需要 IPBE,自動將工單分發至 zhwp 或 zhwp-ipbe
- 網站設計改變,入口頁面一分為二,用戶需要自己選擇是投遞給zhwp還是zhwp-ipbe
- 不支持 IPBEG。
我覺得,從用戶體驗的角度,不希望入口一分為二。另外,不管選擇 1 還是 2,都需要一段時間來修改網站的代碼,但是 2 所花時間會更久一點,並且會增加日後維護的工作量(主要是會出現兩套表單同步的問題)。關於用戶隱私,由於 IPBEG 是簽署 NDA 的,應該視為可信人員,所以我比較傾向 1。Bluedeck 2024年6月1日 (六) 09:25 (UTC)
- 設立IPBEG的本意就是許可IPBEG處理該類申請郵件,理論上可以說已有社群共識支持選項2,但已有共識未必支持選項1。IPBEG不能處理unblock-zh上非申請IPBE的工單。我是認為,一般而言封鎖申訴本應都是在公開場合發起,申訴內容多數都應該可被所有用戶檢視,實質需要使用郵件申訴封鎖的僅有無法編輯討論頁的情況。如你所言,IPBEG本有簽署NDA,就算看了也不應該會造成什麼問題(雖然能避免最好)。如果是最後採用最簡化的選項1,那我覺得您可以最低限度在處理人員的界面中加入標籤工單的功能,讓IPBEG能明確標記跟他們職務無關的申請,從IPBE隊列隱藏,僅能由添加標記的IPBEG(直至工單標籤被管理員確認)及管理員檢視。--路西法人 2024年6月2日 (日) 11:58 (UTC)
- 如果要讓IPBEG不能看到非IPBE工單,那應該執行方式2更優。如果執行方式2,那麼管理員、行政員也應該自動獲得zhwp-ipbe空間權限,並進行工單自動分發。Bluedeck 2024年6月3日 (一) 08:34 (UTC)
- 不是「不能看到」,而是「不再跟IPBE有關的就沒必要繼續顯示在同一隊列,令其他正在處理IPBE申請的用戶不小心點進去」。「看到」大概是不會有什麼大問題的。--路西法人 2024年6月5日 (三) 02:22 (UTC)
- 分成兩列或許方案2實現起來更簡單?--桐生ここ★[討論] 2024年6月5日 (三) 09:51 (UTC)
- 不是不行,但必須考量沒簽署NDA的管理人員是否有權限接觸unblock-zh內的工單,一般視乎工單是否涉及IP位址等可辨識資訊。如果要再這樣分就分成三列了。--路西法人 2024年6月6日 (四) 00:04 (UTC)
- 還是那句話,我無法理解WMF要求郵件列表內的IP必須有簽署NDA才能接觸,但允許使用unblock模板直接把IP公開。--桐生ここ★[討論] 2024年6月6日 (四) 09:48 (UTC)
- 我一開始聽說IPBEG需要NDA,但管理員不需要NDA的時候,我也覺得很費解。而且你知道嗎,你用的任何JS組件要是對外部資源進行請求,那麼就可能有意無意泄露IP。甚至你收到一封郵件,郵件裡帶個圖,這圖也能泄露IP。雖然說IP在wiki上被當作隱私,其實整個互聯網對IP的保護可以用奇差來形容。Bluedeck 2024年6月8日 (六) 04:05 (UTC)
- 還是那句話,我無法理解WMF要求郵件列表內的IP必須有簽署NDA才能接觸,但允許使用unblock模板直接把IP公開。--桐生ここ★[討論] 2024年6月6日 (四) 09:48 (UTC)
- 不是不行,但必須考量沒簽署NDA的管理人員是否有權限接觸unblock-zh內的工單,一般視乎工單是否涉及IP位址等可辨識資訊。如果要再這樣分就分成三列了。--路西法人 2024年6月6日 (四) 00:04 (UTC)
- 分成兩列或許方案2實現起來更簡單?--桐生ここ★[討論] 2024年6月5日 (三) 09:51 (UTC)
- 不是「不能看到」,而是「不再跟IPBE有關的就沒必要繼續顯示在同一隊列,令其他正在處理IPBE申請的用戶不小心點進去」。「看到」大概是不會有什麼大問題的。--路西法人 2024年6月5日 (三) 02:22 (UTC)
- 如果要讓IPBEG不能看到非IPBE工單,那應該執行方式2更優。如果執行方式2,那麼管理員、行政員也應該自動獲得zhwp-ipbe空間權限,並進行工單自動分發。Bluedeck 2024年6月3日 (一) 08:34 (UTC)
- Eric Liu 創造は生命(留言・留名・學生會) 2024年6月6日 (四) 00:11 (UTC) 只要不僭越社群賦予之權限,應儘可能以您自身方便為宜。——
提供的IP問題[編輯]
現在有個問題
- 如果申請者沒有使用代理時使用此網站提交工單,被此網站自動帶入的IP是其真實IP,而非使用代理且受到IP封禁的IP,對於IPBEG應該使用真實IP還是受到封禁的IP判斷?如果有人使用代理訪問此網站,有人不使用代理訪問此網站,也會產生差異。
- 是否像傳統郵件列表一樣另外要求用戶手動填入封禁界面上顯示的受封禁的IP或封禁ID?這樣也有好處,就是IPBEG可以看到申請者被封禁IP同時也能看到真實IP,確定申請者處於中國大陸等受限地區。但產生另外一個風險,就是如果確實提供的是中國大陸IP地址,一旦泄露可能產生嚴重後果。--桐生ここ★[討論] 2024年6月6日 (四) 10:00 (UTC)
- 技術上有很多方法可以儘量避免記錄IP,比如只記錄部分IP、以及對管理員不顯示IP,只顯示IP是否處於封禁列表中。但是這些方法無一例外的會對管理員處理造成問題。我想到的各種方法中,只有一個值得實踐的,是在工單解決之後將IP相關信息從工單中清除,避免永久留存。除此之外,就只有請管理員和IPBEG不要泄露IP地址。對於代理的問題,我可以加一個提示讓用戶記得開代理,再者就是乾脆取消自動偵測IP這個功能,讓用戶自己填寫IP和查封ID,和郵件列表保持一致。Bluedeck 2024年6月7日 (五) 07:43 (UTC)
- 我有一個方案
- 申請者不提供IP:不提交IP
- 申請者選擇提供IP:檢測IP是否中國大陸或其他受限地區
- 是:不提交IP地址,只自動提交申請者IP地區,並且要求申請者手動填寫受封禁IP
- 否:自動帶入IP地址
- --桐生ここ★[討論] 2024年6月7日 (五) 09:10 (UTC)
- 補充:IP地區是提交由服務端判斷,而不是在前端處理,所以實際上仍然會提交中國大陸IP,只是不會儲存在服務器上。--桐生ここ★[討論] 2024年6月7日 (五) 09:13 (UTC)
- 我想過geoip定位這個方案,但是ip定位數據庫需要每個月更新,而且並不完全準確。連維基媒體基金會都放棄了自己的geoip API(否則我就可以利用了)。有一個折衷辦法,那就是查詢封禁數據庫。如果用戶目前的IP不再封禁列表中,大概率說明沒有開代理,此時我彈窗提示開代理。Bluedeck 2024年6月7日 (五) 19:59 (UTC)
- 我有一個方案
- 技術上有很多方法可以儘量避免記錄IP,比如只記錄部分IP、以及對管理員不顯示IP,只顯示IP是否處於封禁列表中。但是這些方法無一例外的會對管理員處理造成問題。我想到的各種方法中,只有一個值得實踐的,是在工單解決之後將IP相關信息從工單中清除,避免永久留存。除此之外,就只有請管理員和IPBEG不要泄露IP地址。對於代理的問題,我可以加一個提示讓用戶記得開代理,再者就是乾脆取消自動偵測IP這個功能,讓用戶自己填寫IP和查封ID,和郵件列表保持一致。Bluedeck 2024年6月7日 (五) 07:43 (UTC)
2024年非洲月籌備討論[編輯]
設立法輪功為高風險主題[編輯]
請先保留此討論串。下面有多位用戶在討論中
- (!)意見-查閱Wikipedia:高風險主題,各個討論期間,此前都在14天以上。
- 法輪功主題---討論期,2024年 5/26~6/3,8天。
- Wikipedia_talk:高風險主題/在世人物傳記--討論期 2023年8/30~9/13,約14天。
- Wikipedia_talk:高風險主題/臺灣海峽兩岸關係及政治地位---2023年8/30~9/18,約19天。
- Wikipedia_talk:高風險主題/加密貨幣及區塊鏈--2023年 9/27~10/19,約22天
- Wikipedia_talk:高風險主題/反對逃犯條例修訂草案運動--2023年8/30~11/24,約25天。
- Wikipedia_talk:高風險主題/八九民主運動--2023年 11/7~12/19,約42天。
- Wikipedia_talk:高風險主題/醫學--2023年10/9~11/22,約43-44天。
- Wikipedia_talk:高風險主題/搜尋引擎優化與營銷---2023年 8/31~10/27,約57天。
- 下列討論已經關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
設立原因及原方案請見Wikipedia talk:高風險主題#設立新興宗教為高風險主題。
法輪功頁面自2005年起,已經被反反覆覆保護超過40次以上;討論頁也無倖免、打辯論的經典副本。
範圍:
Template:法輪功、Category:法輪功
具體措施:
- 當有自動確認用戶參與爭議時將條目提升至延伸確認保護
- 編輯時需恪守Wikipedia:中立的觀點、Wikipedia:文明、Wikipedia:可靠來源、Wikipedia:生者傳記
- 管理員應當對無法遵守者實施合理編輯限制
- 法輪功及李洪志頁面實施不限期半保護、回退零容忍編輯限制,以便有效阻止編輯戰
--Benho7599 | Talk 2024年5月26日 (日) 02:10 (UTC)
- (+)強烈支持,並建議將回退零容忍擴張至李洪志等關聯條目。就最近討論來看參與各方難以形成共識,導致編輯戰頻發。—Aggie Dewadipper 2024年5月26日 (日) 17:12 (UTC)
- 李洪志實際上似乎也十分需要0RR--Benho7599 | Talk 2024年5月28日 (二) 15:27 (UTC)
- (+)支持。從討論頁上連篇累牘的爭執可以看出,法輪功是風險最高的政治相關主題之一。--CuSO4 · 龍年大吉 2024年5月26日 (日) 19:52 (UTC)
- (+)傾向支持WP:1RR 代替WP:0RR -Lemonaka 2024年5月27日 (一) 06:50 (UTC)
- Skeptical toward whether 1RR would work. The current issue is that participating editors do not seek for consensus at all.--Aggie Dewadipper 2024年5月28日 (二) 05:20 (UTC)
- 不反對。Sanmosa 人人皆王 2024年5月28日 (二) 11:50 (UTC)
- 第一條任何條目都適用,不用寫出來。--Cmsth11126a02 (留言) 沈伯洋是被大陸國民黨立委扯衣服導致頭部落地的! 2024年5月29日 (三) 04:51 (UTC)
- 需要先確定具體範圍有多大,法輪功相關條目可不少。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年5月29日 (三) 17:29 (UTC)
- 我暫時想到的範圍是法輪功、法輪功的成員、法輪功的聯繫組織、與法輪功關係高度密切的人與組織。Sanmosa 人人皆王 2024年5月29日 (三) 23:39 (UTC)
- 分類:法輪功?--Cmsth11126a02 (留言) 沈伯洋是被大陸國民黨立委扯衣服導致頭部落地的! 2024年5月30日 (四) 13:40 (UTC)
- @Cmsth11126a02、Ericliu1912:範圍暫定是Template:法輪功、Category:法輪功--Benho7599 | Talk 2024年5月31日 (五) 10:21 (UTC)
- 還要加上其他直接涉及對法輪功評價的條目(比如目前在EWIP吵的中國大陸宗教相關內容)。——Aggie Dewadipper 2024年5月31日 (五) 17:13 (UTC)
- @Cmsth11126a02、Ericliu1912:範圍暫定是Template:法輪功、Category:法輪功--Benho7599 | Talk 2024年5月31日 (五) 10:21 (UTC)
- (+)支持,(&)建議可以先在互助客棧相關版面發起更具討論度的共識討論,以解決最近的編輯爭議(如維基百科:管理員布告板/編輯爭議#Marvin 2009)並為該例爭議確立共識標準以及為未來可能的討論頁內爭議(鑑於基本上並非尋求共識的情況)建立某種程度上從互助客棧引入共識的參考解決方案。Sinet(討論) 2024年5月30日 (四) 22:48 (UTC)
已通過,建立Wikipedia:高風險主題/法輪功。-Mys_721tx(留言) 2024年6月3日 (一) 03:00 (UTC)
- 註:根據WP:CTOP注釋一根據雪球法則一周結案。-Mys_721tx(留言) 2024年6月3日 (一) 03:22 (UTC)
- 本討論已關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
(註:依據方針原則上應至少討論14天,但被提前關閉。6月3日後,後面有多位用戶仍在下面討論,還請先保留討論串。)--此條留言未正確簽名。
- (!)意見+(?)疑問-(1)沒有注意到有這裡有此討論,沒有掛在「法輪功」條目頁通知。早上,在下在「法輪功」條目討論頁回應交流時,突然看到條目被半保護等。討論留言僅到5月31日,近期參與條目討論的用戶似乎並不知道、未能參與,是否應該在相關條目、例如主要條目上有個通知。(2)在下對於設立高風險主題的問題,認為需要更多的討論為宜。Wetrace歡迎參與WP人權專題 2024年6月3日 (一) 03:36 (UTC)
- (?)疑問--共識並未達成。程序不符合方針規範,討論區8天剛過就遭關閉,但方針要求「維持開放最少兩週」。
- 依據WP:高風險主題---任何延伸確認用戶可在互助客棧其他板發起及參與指定高風險主題及相關編輯限制的討論。提案人必須論證主題之風險,並建議合適的編輯限制措施。討論發起一日內應於公告欄張貼通知。討論一般維持開放最少二週,若社群取得共識[a]即可由管理員結案,通過者並應創建主題子頁面(例如「維基百科:高風險主題/<主題>」)。
- 這次討論僅進行8天,違反「討論一般維持開放『最少二週』」的規範。
- Benho7599從5月26日UTC時間2點左右在互助客棧張貼,最後一筆留言在5月31日,管理員Mys 721tx在6月3日UTC時間3點左右關閉,討論只進行「剛滿8天」就遭到關閉、稱達成共識。在下Wetrace在法輪功條目討論頁留言後不久,就看到管理員Mys 721tx關閉討論,並列為「高風險主題」。----在下於6月3日UTC時間3點多,在互助客棧留言表示,認為需要更多的討論為宜、近期參與條目討論的用戶不知道、是否應該條目討論頁通知有此討論。
- 「討論發起一日內應於公告欄張貼通知」,請問是否有放在「公告欄」?「公告欄」是指哪裡?是否能有效的讓常參與的相關參與用戶知曉,表達意見?----討論包含發起人,僅7人(更正,10人)留言。
- 管理員Mys 721tx稱「根據雪球法則一周結案」,雪球法則不是方針、不是指引。尤其在只有7人(更正,10人)在5/26-31留言,許多人恐怕並未知曉來表達意見。
- 【後面有 重新整理這部分,這裡就畫線、不用重複看。】
發起理由、範圍、方式都值得商榷。試舉幾例- 發起人理由稱,2005年以來「法輪功」條目頁面保護40次----這是「19年」的時間,而且也要看看保護的原因。
- 涉及條目範圍恐怕過大,將「分類:法輪功」都納入,是不是都需要呢?由於涉及範圍大,條目的風險,論證是否足夠?依據方針,「提案人必須『論證』主題之風險,並建議合適的編輯限制措施。」
- 發起討論人的理由寫到「設立原因及原方案請見Wikipedia talk:高風險主題#設立新興宗教為高風險主題」。點入後裡面提到「不熟悉方針的新手/IP用戶可能會根據自己的立場加入不符合編輯方針的內容」---這其實可以先透過「半保護」就可大幅改善處理。
- 且例如,要求對條目0RR,也會大幅影響WP:修改、回退、討論循環的合理進行。留言中也有用戶提出不同意見。
此前,用戶違反3RR、人身攻擊屢屢違反文明方針,在下列出明確證據舉報後,管理員並未處理。從落實現有方針來改善,也是重要的作法。Wetrace歡迎參與WP人權專題 2024年6月4日 (二) 00:11 (UTC)
- (?)疑問--共識並未達成。程序不符合方針規範,討論區8天剛過就遭關閉,但方針要求「維持開放最少兩週」。
- 討論一般維持開放最少二週,若社群取得共識[a]即可由管理員結案。
- [a]:若討論發起七日後已有大量用戶參與且非常明顯近乎完全一致則可考慮提早結案。
- 討論一般維持開放最少二週,若社群取得共識[a]即可由管理員結案。
- 可以看到上述討論完全一致支持,適用雪球法則,而且一般來說在客棧討論已經非常醒目,無需使用RFC、FRS或在其他討論頁通知。--桐生ここ★[討論] 2024年6月4日 (二) 00:22 (UTC)
- (-)反對-「討論一般維持開放最少二週,若社群取得共識[a]即可由管理員結案。」從方針來看,「開放至少兩週」+「若社群取得共識」,兩者皆為要件。方針中也並未規範「雪球法則」,這會不會架空了方針?管理員8天即關閉討論、並且在條目頁面半保護,引起在下注意到,發現原來正在進行此討論,在下隨即來此討論頁留言表達異議,認為需要更多時間討論、並是否應在條目討論頁採取方式讓參與編輯的用戶知悉、Wetrace歡迎參與WP人權專題 2024年6月4日 (二) 00:33 (UTC)
- 你這個真的叫錯誤解讀方針,和Gluo88那個不一樣。--桐生ここ★[討論] 2024年6月4日 (二) 00:56 (UTC)
- Gluo88 是什麼事?在下不清楚。Wetrace歡迎參與WP人權專題 2024年6月4日 (二) 01:03 (UTC)
- 你看他日誌。--桐生ここ★[討論] 2024年6月4日 (二) 01:16 (UTC)
- Gluo88 是什麼事?在下不清楚。Wetrace歡迎參與WP人權專題 2024年6月4日 (二) 01:03 (UTC)
- 你這個真的叫錯誤解讀方針,和Gluo88那個不一樣。--桐生ここ★[討論] 2024年6月4日 (二) 00:56 (UTC)
- (-)反對-「討論一般維持開放最少二週,若社群取得共識[a]即可由管理員結案。」從方針來看,「開放至少兩週」+「若社群取得共識」,兩者皆為要件。方針中也並未規範「雪球法則」,這會不會架空了方針?管理員8天即關閉討論、並且在條目頁面半保護,引起在下注意到,發現原來正在進行此討論,在下隨即來此討論頁留言表達異議,認為需要更多時間討論、並是否應在條目討論頁採取方式讓參與編輯的用戶知悉、Wetrace歡迎參與WP人權專題 2024年6月4日 (二) 00:33 (UTC)
- 此外,按照以往案例,將在世人物傳記訂為高風險主題為4人支持,八九民主運動為6人支持,加密貨幣及區塊鏈為6人支持,搜尋引擎優化與營銷為3人支持,因此支持人數按照以往案例來說並不低。--桐生ここ★[討論] 2024年6月4日 (二) 00:38 (UTC)
- 桐生您好,該附款的要件是「七日後已有『大量用戶參與』且『非常明顯近乎完全一致』則可考慮提早結案」,而不是「支持人數」。Wetrace歡迎參與WP人權專題 2024年6月4日 (二) 12:53 (UTC)
- (!)意見-桐生您好,這樣的支持人數,是不是很可能反映了這樣的討論,「公告」機制上的不足?方針要求「討論發起一日內應於『公告欄張貼通知』。」Wetrace歡迎參與WP人權專題 2024年6月4日 (二) 00:46 (UTC)
- 2024年5月26日已經在公告欄通知。--桐生ここ★[討論] 2024年6月4日 (二) 00:52 (UTC)
- 謝謝桐生貼出。Wetrace歡迎參與WP人權專題 2024年6月4日 (二) 13:07 (UTC)
- (!)意見
- 方針要求「討論發起一日內應於『公告欄張貼通知』。」從方針要求「公告欄張貼通知」、討論「開放最少兩週」,顯示是讓社群有充分注意、討論。
- 方針寫到「討論一般維持開放最少二週,若社群取得共識[a]即可由管理員結案」。在[a]附註,「制定討論的共識不強求一致同意,但也不是點票。制定討論的共識需考量所有用戶提出的理據和觀點。若討論發起七日後已有大量用戶參與且非常明顯近乎完全一致則可考慮提早結案。」
- (1)將此重要訊息寫在 [a]附註,在公示效果上是否適當?在下高度保留,如果認為有此需要,應寫入本文。且使用上應相當謹慎。
- (2)a[附註]寫到「七日後已有大量用戶參與」---但是「七日後已有大量用戶參與」---加發起人僅7人留言(更正:含發起人10人-仍難屬「大量用戶」),屬於「大量用戶參與」嗎?這樣的認定,恐怕出現很大的恣意性空間,是否宜更審慎。 實際上大幅壓縮了方針「討論一般維持開放最少二週」。
- (3)當管理員到去對條目半保護等,在下發現此討論,就過來留言表達 需要更多時間討論。Wetrace歡迎參與WP人權專題 2024年6月4日 (二) 00:58 (UTC)
- 關於2(1),方針既然已經這樣寫,說明管理員執行的沒問題,即使寫入了正文,也不會影響本次執行結果。--桐生ここ★[討論] 2024年6月4日 (二) 01:05 (UTC)
- (?)疑問--「討論一般維持開放最少二週」,[a]附註「七日後已有大量用戶參與」---加發起人僅7人留言(更正:10人-仍難屬「大量用戶」),屬於「大量用戶參與」嗎?這樣的認定,恐怕出現很大的恣意性空間,是否宜更審慎。否則,這樣的作法,實際上大幅壓縮了方針原則性的「討論一般維持開放最少二週」。---在下實在疑惑:既然鼓勵用戶「踴躍參與」表達意見,7人(更正:含發起人10人-仍難屬「大量用戶」)能算是維基社群的「大量用戶參與」嗎?Wetrace歡迎參與WP人權專題 2024年6月4日 (二) 01:08 (UTC)
- (!)意見-桐生您好, (1)7人討論(更正:含發起人10人-仍難屬「大量用戶」),很難說是「已有大量用戶參與」,因此「考慮提前結案」更應該審慎。在這樣情況下,應當遵循方針「討論一般維持開放最少二週」。何況,當管理員要提前結案,在下就來此表達不同意見,認為需要更多時間討論了。(2)即便在這7人的討論中,也對於內容、方法等有些意見,這些疑問還存在。討論應當持續進行。Wetrace歡迎參與WP人權專題 2024年6月4日 (二) 01:32 (UTC)
- (?)疑問--「討論一般維持開放最少二週」,[a]附註「七日後已有大量用戶參與」---加發起人僅7人留言(更正:10人-仍難屬「大量用戶」),屬於「大量用戶參與」嗎?這樣的認定,恐怕出現很大的恣意性空間,是否宜更審慎。否則,這樣的作法,實際上大幅壓縮了方針原則性的「討論一般維持開放最少二週」。---在下實在疑惑:既然鼓勵用戶「踴躍參與」表達意見,7人(更正:含發起人10人-仍難屬「大量用戶」)能算是維基社群的「大量用戶參與」嗎?Wetrace歡迎參與WP人權專題 2024年6月4日 (二) 01:08 (UTC)
- 2024年5月26日已經在公告欄通知。--桐生ここ★[討論] 2024年6月4日 (二) 00:52 (UTC)
- 此外,按照以往案例,將在世人物傳記訂為高風險主題為4人支持,八九民主運動為6人支持,加密貨幣及區塊鏈為6人支持,搜尋引擎優化與營銷為3人支持,因此支持人數按照以往案例來說並不低。--桐生ここ★[討論] 2024年6月4日 (二) 00:38 (UTC)
- 通過公示又推翻的又不是一次兩次,@Wetrace所以您的看法是? ——魔琴[留言 貢獻] 2024年6月4日 (二) 02:05 (UTC)
- (!)意見-魔琴您好,如上表述的意見,在下以為,這一討論並未完成、參與者少、留言討論少、現有的留言也有分歧意見未獲充分討論,並不符合「已有大量用戶參與」的「考慮提前」關閉的情況。提前關閉並不合適,應依據方針開放至少14天的討論。Wetrace歡迎參與WP人權專題 2024年6月4日 (二) 02:16 (UTC)
- 我覺得提前結案沒有問題,如果您反對提案或者有異議的話可以繼續討論,尋求達成新的共識 ——魔琴[留言 貢獻] 2024年6月4日 (二) 02:22 (UTC)
- 魔琴您好,在下以為,此一討論應該依據方針持續14天,不宜提前關閉。7人討論(更正:含發起人10人-仍難屬「大量用戶」),很難說是「已有大量用戶參與」,且也存在些具體不同意見。Wetrace歡迎參與WP人權專題 2024年6月4日 (二) 02:25 (UTC)
- @Wetrace:我個人認為管理員的操作反映了共識。如果您認為現在不應該結案,那您具體的意見是什麼呢?如果您也沒有意見沒必要再等吧? ——魔琴[留言 貢獻] 2024年6月4日 (二) 09:31 (UTC)
- 魔琴您好,在下以為,此一討論應該依據方針持續14天,不宜提前關閉。7人討論(更正:含發起人10人-仍難屬「大量用戶」),很難說是「已有大量用戶參與」,且也存在些具體不同意見。Wetrace歡迎參與WP人權專題 2024年6月4日 (二) 02:25 (UTC)
- 我覺得提前結案沒有問題,如果您反對提案或者有異議的話可以繼續討論,尋求達成新的共識 ——魔琴[留言 貢獻] 2024年6月4日 (二) 02:22 (UTC)
- (!)意見--魔琴您好,在下上面已經具體提出了一些具體疑問,例如範圍、作法、是否需要,等等。在下認為,應該至少討論14天Wetrace歡迎參與WP人權專題 2024年6月4日 (二) 11:24 (UTC)
- (!)意見--(1) 7人討論(更正:含發起人10人-仍難屬「大量用戶」),能算是「已有大量用戶參與」而提前關閉討論?在下以為,對於維基「高風險主題」方針的解讀、執行應嚴謹,不然,如果今天改一點、明天變一點,會不會似乎變相成了潛規則、被利用的漏洞?那麼,不僅對條目爭議不利,恐怕還可能增加了對新方針的誤導、糾偏的爭議或後遺症。(2)或許提案人本意想有助於解決問題,但解決問題,需要避免的情況是,會不會反而增加了問題複雜性。如果依據過去的主要方針不能解決問題,是執行方針的問題嗎?或者什麼? 如果需要 新設的「WP:高風險主題」方針,就一個議題設定為高風險主題,要形成共識,那麼方針規定「至少討論14天」,其實也意味可能需要更多討論時間,畢竟這不是局部小問題的探討,而可能是影響長久的,過程不宜粗糙的解讀操作,理應更多人參加較細緻的討論,不宜簡單過去。Wetrace歡迎參與WP人權專題 2024年6月4日 (二) 11:18 (UTC)
- (!)意見-魔琴您好,如上表述的意見,在下以為,這一討論並未完成、參與者少、留言討論少、現有的留言也有分歧意見未獲充分討論,並不符合「已有大量用戶參與」的「考慮提前」關閉的情況。提前關閉並不合適,應依據方針開放至少14天的討論。Wetrace歡迎參與WP人權專題 2024年6月4日 (二) 02:16 (UTC)
- (!)意見-魔琴您好,與魔琴、發起人Hoben7599、參與的各位交流。對於本案,實質面,在下在上面列舉部分意見與疑慮,再整理如下,提供參考,感謝耐心閱讀:
- 此討論的,發起理由、範圍、方式,有些值得商榷處,試舉幾例提出交流
- 發起人理由稱,2005年以來「法輪功」條目頁面保護40次----這是「19年」的時間,而且也要看看保護的原因。
- 涉及條目範圍恐怕過大,將「分類:法輪功」中的條目都納入,相關條目,是不是都需要呢?涉及範圍大,條目的風險,論證是否足夠?依據方針,「提案人必須『論證』主題之風險,並建議『合適』的編輯限制措施。」
- 發起討論人的理由寫到「設立原因及原方案請見Wikipedia talk:高風險主題#設立新興宗教為高風險主題」。點入後裡面提到「不熟悉方針的新手/IP用戶可能會根據自己的立場加入不符合編輯方針的內容」---(1)這其實可以先透過「半保護」就可大幅改善處理。(2)發起人建議,對兩個條目的方案是「不限期半保護+0RR」,但是,0RR不得回退,會不會反過來 讓這些「不符合編輯方針的內容」不被回退,而限制了正常的編輯與反破壞?這會不會影響,很常見的WP:修改、回退、討論循環的合理進行。在前面的討論中,也有用戶提出對0RR的不同意見。是不是需要再商榷?
- 方案中,「『當有自動確認用戶參與爭議』時將條目提升至延伸確認保護」---「當有自動確認用戶參與爭議」---這要如何判斷?
- 發起人的方案,要求「恪守Wikipedia:中立的觀點、Wikipedia:文明、Wikipedia:可靠來源、Wikipedia:生者傳記」-----疑問:如果要方案,是不是該有相當關鍵核心的WP:可供查證? 要有WP:不要人身攻擊?
- 此外,從落實現有方針來改善,也是重要的作法。此前,有用戶在相關條目上,違反3RR、人身攻擊屢屢違反文明方針,在下列出明確證據舉報後,不知為何管理員並未處理。Wetrace歡迎參與WP人權專題 2024年6月4日 (二) 12:06 (UTC)
- 此討論的,發起理由、範圍、方式,有些值得商榷處,試舉幾例提出交流
- (!)意見-魔琴您好,與魔琴、發起人Hoben7599、參與的各位交流。對於本案,實質面,在下在上面列舉部分意見與疑慮,再整理如下,提供參考,感謝耐心閱讀:
- (!)意見-查閱Wikipedia:高風險主題,各個討論期間,此前都在14天以上。
- 法輪功主題---討論期,2024年 5/26~6/3,8天。
- Wikipedia_talk:高風險主題/在世人物傳記--討論期 2023年8/30~9/13,約14天。
- Wikipedia_talk:高風險主題/臺灣海峽兩岸關係及政治地位---2023年8/30~9/18,約19天。
- Wikipedia_talk:高風險主題/加密貨幣及區塊鏈--2023年 9/27~10/19,約22天
- Wikipedia_talk:高風險主題/反對逃犯條例修訂草案運動--2023年8/30~11/24,約25天。
- Wikipedia_talk:高風險主題/八九民主運動--2023年 11/7~12/19,約42天。
- Wikipedia_talk:高風險主題/醫學--2023年10/9~11/22,約43-44天。
- Wikipedia_talk:高風險主題/搜尋引擎優化與營銷---2023年 8/31~10/27,約57天。
- Wetrace歡迎參與WP人權專題 2024年6月4日 (二) 12:44 (UTC)
- 其實你有意見可以直接提的,沒必要搞一堆procedural comments然後浪費別人時間。剩下的我有精力的時候再說我想不想回你。--0xDeadbeef (留言) 2024年6月5日 (三) 14:15 (UTC)
- Wetrace歡迎參與WP人權專題 2024年6月4日 (二) 12:44 (UTC)
- 0xDeadbeef您好,(1)在下有直接在上面提實質意見,例如其他用戶討論的0RR或1RR。(2)程序上、討論期間要審慎符合方針,是重要的,「高風險主題」的討論宜謹慎,開此例可能留下後遺症。Wetrace歡迎參與WP人權專題 2024年6月8日 (六) 01:07 (UTC)
- WP:NOTBURO,如果沒有對實際內容有反對意見的話,我看不出8天快速關閉有什麼壞處。—-Aggie Dewadipper 2024年6月8日 (六) 03:02 (UTC)
- 看不懂他是打算支持還是反對?若只是程序性反對,那就等滿十四天,也沒啥不行的吧?—— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月6日 (四) 00:07 (UTC)
- 如果是程序性反對,我倒是還確實支持。--MilkyDefer 2024年6月6日 (四) 13:25 (UTC)
- 0xDeadbeef您好,(1)在下有直接在上面提實質意見,例如其他用戶討論的0RR或1RR。(2)程序上、討論期間要審慎符合方針,是重要的,「高風險主題」的討論宜謹慎,開此例可能留下後遺症。Wetrace歡迎參與WP人權專題 2024年6月8日 (六) 01:07 (UTC)
- Ericliu MilkyDefer兩位好,程序上依據方針應討論至少14天,在過去也都如此;這次被縮短到8天,在下以為是很有疑慮的,「高風險主題」的討論宜謹慎,開此例可能留下後遺症。在下6/3即留言,認為需要更多討論,在下於前面也就實質議題也提出了一些疑問希望交流;部分議題是其他用戶在討論過程中也有提出的,但並未被釐清、進一步討論,就被關閉了。Wetrace歡迎參與WP人權專題 2024年6月7日 (五) 23:57 (UTC)
- 7天還是14天更多是程序議題,反而1RR還是0RR算是實質議題,故@Hoben7599、Dewadipper、CopperSulfate、Lemonaka、Sanmosa、August0422、Ericliu1912、Flyinet、John123521、Wetrace、桐生ここ、魔琴、0xDeadbeef、MilkyDefer:您們對法輪功或李洪志實施1RR還是0RR有何意見?--Cmsth11126a02 (留言) 沈伯洋是被大陸國民黨立委扯衣服導致頭部落地的! 2024年6月8日 (六) 08:15 (UTC)
- 不反對。John123521(留言-貢獻) 2024年6月8日 (六) 10:07 (UTC)
- 不反對,不過建議改1RR,0RR不應該長期使用。--桐生ここ★[討論] 2024年6月8日 (六) 11:07 (UTC)
- 建議使用回退不過一--August0422 2024年6月8日 (六) 12:07 (UTC)
- Inclined to WP:1RR instead of WP:0RR, which is too strict for such a topic. -Lemonaka 2024年6月8日 (六) 18:18 (UTC)
- 我覺得應該修改高風險主題相關方針,確立一個原則,就是0RR不能長期使用,就像IP不能永久封禁一樣。--桐生ここ★[討論] 2024年6月8日 (六) 23:42 (UTC)
- 已在方針區開啟有關討論。--Cmsth11126a02 (留言) 沈伯洋是被大陸國民黨立委扯衣服導致頭部落地的! 2024年6月9日 (日) 08:37 (UTC)
- 1RR吧。--MilkyDefer 2024年6月9日 (日) 07:22 (UTC)
- 我個人建議暫時維持0RR,直到有關條目內容和編輯爭議得到共識解決再改為1RR等。0RR並不限制反破壞(見WP:NOTEW),而是為了儘量避免編輯戰。當前「法輪功」相關主題爭議巨大,「回退戰」反覆發生(比如法輪功:撤銷、手工回退),允許回退可能無助於解決爭議。--Wnotieagusdr(留言) 2024年6月10日 (一) 01:22 (UTC)
- 暫時是暫時,不限期是不限期,上面反對的是不限期的0RR,而不是暫時的0RR。--桐生ここ★[討論] 2024年6月10日 (一) 17:41 (UTC)
- 我覺得應該修改高風險主題相關方針,確立一個原則,就是0RR不能長期使用,就像IP不能永久封禁一樣。--桐生ここ★[討論] 2024年6月8日 (六) 23:42 (UTC)
- 我感覺或許可以先為0RR設定一年的限期,要是一年後發現有限期的0RR並不足以處理相關情況,那就説明這並不屬於「一般情況」,因此有正當理由實行不限期的0RR。Sanmosa Snipe–Clam Grapple 2024年6月10日 (一) 22:55 (UTC)
- 0RR反而可能衍生新的問題。如前所述,0RR不得回退,會不會反過來 讓這些「不符合編輯方針的內容」不被回退,而限制了正常的編輯與反破壞?這會不會影響,很常見的WP:修改、回退、討論循環的合理進行。Wetrace歡迎參與WP人權專題 2024年6月11日 (二) 23:51 (UTC)
- 0RR的重點是在回退前必須得到相關編者的共識(當然純破壞用戶/IP不算),目前來看非常有必要使用0RR:絕大多數法輪功相關條目的編輯都相當固執,執意說服別人而非尋求共識妥協,而顯然維基百科不是遊說的好地方,這些行為也鮮少有成功的,最終導致編輯戰頻繁。1RR是治標不治本的行為,只是把互相回退對方編輯的頻率調低了,並不能減少編輯戰。——Aggie Dewadipper 2024年6月12日 (三) 00:33 (UTC)
- 過去長期存在用戶添加 非第三方來源等問題。WP:修改、回退、討論循環。例如,發起討論人的理由寫到「設立原因及原方案請見Wikipedia talk:高風險主題#設立新興宗教為高風險主題」---點入後裡面提到「不熟悉方針的新手/IP用戶可能會根據自己的立場加入不符合編輯方針的內容」Wetrace歡迎參與WP人權專題 2024年6月12日 (三) 00:41 (UTC)
- 0RR的重點是在回退前必須得到相關編者的共識(當然純破壞用戶/IP不算),目前來看非常有必要使用0RR:絕大多數法輪功相關條目的編輯都相當固執,執意說服別人而非尋求共識妥協,而顯然維基百科不是遊說的好地方,這些行為也鮮少有成功的,最終導致編輯戰頻繁。1RR是治標不治本的行為,只是把互相回退對方編輯的頻率調低了,並不能減少編輯戰。——Aggie Dewadipper 2024年6月12日 (三) 00:33 (UTC)
- 0RR反而可能衍生新的問題。如前所述,0RR不得回退,會不會反過來 讓這些「不符合編輯方針的內容」不被回退,而限制了正常的編輯與反破壞?這會不會影響,很常見的WP:修改、回退、討論循環的合理進行。Wetrace歡迎參與WP人權專題 2024年6月11日 (二) 23:51 (UTC)
- (+)支持任何能防止法輪功相關編輯戰的措施,我看著這些條目被信徒寫成難以閱讀的模樣已經很多年了。我偏好最嚴格的無限期0RR,但也不反對其他任何較輕的手段,總之都好過現狀。--C9mVio9JRy(留言) 2024年6月11日 (二) 13:55 (UTC)
- 我寫CTOP方針時提供的限制措施是寫寂寞的啊?0RR的實際原理是要求編者儘可能先獲取共識再撤銷他人編輯,所謂「不讓回退不符合方針的內容」並不成立(獲取了共識就可以撤銷)。雖然0RR的編輯循環比較緩慢,但確保的是經過討論才撤銷他人編輯;方針也指明參照WP:NOTEW的條款,反破壞並不計入0RR之內,上方用戶所說「限制正常編輯與反破壞」均不成立。再說,如果覺得0RR嚴格,鑑於此主題的編輯戰的嚴重情況,改成0RR及1RR之間的「共識要求」不行嗎?硬是要雙方都回退對方編輯一次才開始討論?高風險主題的最高原則之一就是在該等條目遇編輯爭議應先行溝通而非回退戰解決,所謂「0RR太過嚴格」就反映了上面用戶着重於「要可以回退」而不是「先討論再行動」的戰鬥心態。--路西法人 2024年6月12日 (三) 03:54 (UTC)
- 倒不是「寫寂寞」,這不過是社羣並未對你當時設定出來的東西建立信心而已。Sanmosa Snipe–Clam Grapple 2024年6月12日 (三) 05:44 (UTC)
- (!)意見-LuciferianThomas您好,謝謝您分享看法與初衷。在下提幾點切磋交換意見,思考看看,是否適合在個案?
- 關於共識的形成,維基百科,本來存在WP:修改、回退、討論循環的合理過程,這是一個極其常見、自然的運作過程。
- 您表述提到「0RR的實際原理是要求編者儘可能先獲取共識再撤銷他人編輯」。疑問,在維基百科上,新增內容、刪除既有內容呢?要不要獲取共識?(當發生編輯戰時,管理員經常會保護在 編輯戰發生之前的版本。)當被撤銷、或者修改,並且討論,就是尋求共識的一個過程,並非就是非善意,也不能說就是「編輯戰」了。
- 本案發起人提出的設定高風險理由,點入看,是「新手/IP用戶可能會根據自己的立場加入不符合編輯方針的內容」。在這裡0RR的作法,是否有助於達到那目的呢?會不會反向增加了用戶反破壞的負擔?
- 您說明「反破壞並不計入0RR之內」。不過,當另一方不認為是破壞,要怎麼斷定這一個RR是反破壞、不計入 0RR?這也說明0RR執行上的難度。在維基上現實情況,是不是破壞,也往往在吵;修改,是不是RR呢?原創研究內容、不符合維基要求的來源,被加入時呢?
- 以上幾點淺見思考,提出切磋。Wetrace歡迎參與WP人權專題 2024年6月13日 (四) 00:41 (UTC)
- 正常情況下,WP:BRD當然是非常理想的編輯生態。在高風險主題中,很多情況下連什麼是「合理符合方針」都無法清楚定義。除了非常明顯地不中立(完全傾向一邊,甚至包含攻擊特定群體的用詞)的情況適合直接回退(參考即將上路的新版破壞方針,目前公示中),用戶先行討論再撤銷是更好的做法。
- 在高風險主題編輯的用戶應學會忍。內容都存在問題這麼多年,顯然也不會因為編者回退了這一筆編輯就得到解決,糟的內容多放一天也沒分別。真的緊急的情況下,請求管理人員介入處理即可。
- 對於其他高風險主題而言,1RR仍能一定限度遏阻用戶開展回退戰。如這個議題這樣具爭議性的情況下,就算改施1RR,請問編者看到自己不同意的編輯回退對方編輯,對方基本上必然又用自己那一次「扣打」回退你的回退,你還是跟0RR一樣不能繼續回退,根本就沒有分別,反而是在討論開始前就產生了編輯戰和對對方的惡意。有些用戶提出「1RR能提供緩衝」,但這些議題下又有多少用戶是拿1RR來合理化自己的回退,大家心知肚明。既然0RR和1RR沒分別,編輯戰又如此嚴重,1RR也實際被當成quota對待,直接實施0RR是更加合理的。
- 此高風險議題除了要求用戶遵守0RR,也有數條方針是被社群要求嚴格遵守的,而管理員獲授權嚴格執行這些規則。目前社群的管理員多不帶特定立場,判別原創研究或不符合維基百科要求的內容也比較中性合理,與其編者自己回退,為何不提報交由社群公論後由管理員處理?如果管理員認為「不足以認定明顯違反規定而直接封鎖」,那不就代表這些編輯應先經討論再撤銷嗎?
- 上面說了一堆,必須說,比對0RR和1RR而言,我是覺得在此議題實施0RR更合適(限期的0RR也無法改變0RR的本質,限不限期幾乎是個偽議題)。我在引入高風險主題方針時,除了本地既有的回退限制外,也引入了「共識要求」的編輯限制,實際運作介乎0RR及1RR之間,這是BRD的加強版(BRD要求編輯被回退等候24小時,「共識要求」要等有共識)。如果社群有意願,可以改為實施這些編輯限制(我是認為這些實際要比nRR都好)。高風險主題是用來阻止編輯戰,鼓勵編者在編輯條目時以溝通為上;但如果編輯該主題的用戶還是抱着「先回退再討論」的觀念,那維持0RR不是壞事。--路西法人 2024年6月13日 (四) 06:14 (UTC)
- 另,CTOP本來設計的時候就有提早結束討論的條文,這裏所說的「大量用戶」雖然比較模糊,但可參照一般客棧每串討論參與的用戶數。以開啟七天的討論來說,約十名用戶參與討論已經算是「正常以上數量」,且可以明顯判斷出存在共識,那麼就能走完加速走流程開高風險主題,苗君的關閉符合我當時設計CTOP方針提供的加速選項條件。你就此提出的程序性反對與程序賦予管理員提早總結討論的設計不相容,不能當是正確合理的程序性反對。--路西法人 2024年6月13日 (四) 06:23 (UTC)
- (!)意見- 您好,1RR、nRR,撤銷回退,需要適當理由。關於共識的形成,維基百科,本來存在WP:修改、回退、討論循環的合理過程。
- 手段 與 目的 應有合理有效的連結。高風險主題方針要求「提案人『必須論證』主題之風險,並建議合適的編輯限制措施。」------本案發起人提出的設定理由,點入看,例如是「新手/IP用戶可能會根據自己的立場加入不符合編輯方針的內容」。----但實施0RR 是抑制這問題?還是讓壓縮了處理這問題的空間?
- 0RR 與 1RR是有分別。部分的影響,前面已述。例如其中一點,您表述提到「0RR的實際原理是要求編者儘可能先獲取共識再撤銷他人編輯」。疑問,(1)在維基百科上,新增內容、刪除既有內容呢?(注意本案發起人的理由「新手/IP用戶可能會根據自己的立場加入不符合編輯方針的內容」)要不要獲取共識?(當發生編輯戰時,管理員經常會保護在 編輯戰發生之前的版本。)當被撤銷、或者修改,並且討論,就是尋求共識的一個過程,並非就是非善意,也不能說就是「編輯戰」了。(2)原創研究內容、不符合維基要求的來源,被加入時呢?(3)修改,是不是RR呢?
- 在下前面提問,0RR之下的反破壞?-----您提到「目前社群的管理員多不帶特定立場,判別原創研究或不符合維基百科要求的內容也比較中性合理,與其編者自己回退,為何不提報交由社群公論後由管理員處理」---幾點疑惑提出切磋,(1)這是否意味著,在0RR實際運作下,用戶處理反破壞等明顯編輯爭議的空間,恐怕被大幅壓縮、甚至會不會幾乎壓縮到零?(2)在下擔心,看起來為了解決一個問題,恐怕衍生更多問題。(3)維基百科的管理員,是否有這麼多時間?顯然情況不是如此。無此前,明確3RR、違反文明的人身攻擊案,在下提列完整證據,完全無人處理。
- 1RR,並不意味著用戶可以隨意無理撤銷。2RR、3RR也都不意味可以隨意撤銷。Wetrace歡迎參與WP人權專題 2024年6月14日 (五) 01:15 (UTC)
- (!)意見-LuciferianThomas您好,前面多位用戶表達了認為0RR過嚴的意見,即便在討論8天就被關閉前,也有用戶對0RR有不同意見,這沒有被處理到,就被關閉討論。-----您對於提前關閉討論的「大量用戶」的解釋,在下認為,應當審慎,不宜過模糊而超越了方針的原則性規範。
- 在下於前面其實提出多點 實質性意見。此外,在程序性問題方面,方針寫到「討論一般維持開放最少二週,若社群取得共識[a]即可由管理員結案」。在[a]附註,「制定討論的共識需考量所有用戶提出的理據和觀點。若討論發起七日後已有大量用戶參與且非常明顯近乎完全一致則可考慮提早結案。」。----這裡的「大量用戶」解釋上應當審慎。
- 查閱Wikipedia:高風險主題,各個討論期間,此前都在14天以上。
- 法輪功主題---討論期,2024年 5/26~6/3,8天。
- Wikipedia_talk:高風險主題/在世人物傳記--討論期 2023年8/30~9/13,約14天。
- Wikipedia_talk:高風險主題/臺灣海峽兩岸關係及政治地位---2023年8/30~9/18,約19天。
- Wikipedia_talk:高風險主題/加密貨幣及區塊鏈--2023年 9/27~10/19,約22天
- Wikipedia_talk:高風險主題/反對逃犯條例修訂草案運動--2023年8/30~11/24,約25天。
- Wikipedia_talk:高風險主題/八九民主運動--2023年 11/7~12/19,約42天。
- Wikipedia_talk:高風險主題/醫學--2023年10/9~11/22,約43-44天。
- Wikipedia_talk:高風險主題/搜尋引擎優化與營銷---2023年 8/31~10/27,約57天。Wetrace歡迎參與WP人權專題 2024年6月14日 (五) 00:17 (UTC)
- (!)意見- 您好,1RR、nRR,撤銷回退,需要適當理由。關於共識的形成,維基百科,本來存在WP:修改、回退、討論循環的合理過程。
- (!)意見-LuciferianThomas您好,謝謝您分享看法與初衷。在下提幾點切磋交換意見,思考看看,是否適合在個案?
- 倒不是「寫寂寞」,這不過是社羣並未對你當時設定出來的東西建立信心而已。Sanmosa Snipe–Clam Grapple 2024年6月12日 (三) 05:44 (UTC)
- 0RR被打破了再退回也是跟1RR類似,而1RR會多更多無謂的來回回退,傾向0RR。至於永久0RR過於嚴格的問題,Antigng曾經全保護漢服條目7年之久,我覺得可以參考;如果覺得不要永久,建議設置20年0RR,到2044年1月1日為止。 ——魔琴[身份聲明 留言 貢獻 新手2023] 2024年6月15日 (六) 14:56 (UTC)
- 同意,不過20年太久,建議參考歷史,以7年0RR為宜,之後改不限期1RR。--桐生ここ★[討論] 2024年6月17日 (一) 07:11 (UTC)
- Antigng保護漢服條目七年是基於14—21年打了七年編輯戰,如果認為法輪功條目從05年來開始一直打編輯戰的話,比照操作確實是20年 ——魔琴[身份聲明 留言 貢獻 新手2023] 2024年6月17日 (一) 07:22 (UTC)
- 很好奇我提議設立新型宗教為高風險主題時卻沒上過公告欄,是管理員的問題嗎--重慶軌交18(留言) 2024年6月19日 (三) 14:12 (UTC)
- 您可以自己更新。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月19日 (三) 14:18 (UTC)
- 很好奇我提議設立新型宗教為高風險主題時卻沒上過公告欄,是管理員的問題嗎--重慶軌交18(留言) 2024年6月19日 (三) 14:12 (UTC)
- Antigng保護漢服條目七年是基於14—21年打了七年編輯戰,如果認為法輪功條目從05年來開始一直打編輯戰的話,比照操作確實是20年 ——魔琴[身份聲明 留言 貢獻 新手2023] 2024年6月17日 (一) 07:22 (UTC)
- 同意,不過20年太久,建議參考歷史,以7年0RR為宜,之後改不限期1RR。--桐生ここ★[討論] 2024年6月17日 (一) 07:11 (UTC)
- (?)疑問-魔琴、桐生、LuciferianThomas等用戶們好。前面多位用戶表達了認為0RR過嚴的意見,即便在討論8天就被關閉前,也有用戶對0RR有不同意見,這分歧沒有被處理到,卻就被提前關閉了討論。
- 在下淺見思索,是否對症下藥了?在下以為,0RR不一定能應對,還可能衍生新問題、副作用,維基會不會不再是自由編輯貢獻的維基了?(1)維基百科的措施、例如保護方針,盡量不影響用戶的編輯貢獻。(2)恐怕形成制度漏洞與風險被利用,有心人要在維基百科上去限制用戶編輯一些條目,動用IP用戶等,不時有人打編輯戰,就可以形成高風險、設定0RR?0RR這在手段、目的的對應上是否有效?例如最近客棧上Wikipedia:互助客棧/其他#將「1945年後臺灣政治」訂為高風險主題討論,發起人建議的方案是「不定期半保護」、「不定期半保護+1RR」。(3)目前看看,幾個被列高風險主題的(香港反送中、八九六四、台海政治),主要都是對中共的敏感議題。Wetrace歡迎參與WP人權專題 2024年6月19日 (三) 16:07 (UTC)
- (!)意見- 依據高風險主題方針的規定,「提案人必須論證主題之風險,並建議合適的編輯限制措施。」,這部分在下感到在對應上可以再思考,例如 條目的保護歷史紀錄、情況,在過去一些「編輯戰」或者撤銷,許多情況實際上是反破壞、因應新註冊或IP用戶添加不符方針來源。
- 這次被提案 0RR的兩個條目,在下查詢過去5年半紀錄如下,在下認為0RR是非必要,手段與目標的連結與效果,值得思量。:
- (一)【條目法輪功,從2019年起5年半,被保護紀錄6次】來觀察。(1)3次理由是「被IP用戶或新用戶破壞」。(2)2021年1次理由寫「編輯戰」,但原因是一方無理由刪除內容,另一方4天內只撤銷1次。(3) 2020年1次理由寫「編輯戰」,但原因是一方用戶無討論、模糊或不具理由刪除十多萬字長期內容,浮濫添加模板。--這是否應是反破壞。
- 2024年,1次,5月25日「全保護1週」,是因為「模板」的編輯戰問題(新註冊用戶堅持添加模板,在討論頁溝通)。(6月是因為高風險主題而被「不限期半保護」。)
- 2023年,沒有保護紀錄
- 2022年,1次,11月30日「不定期半保護」,理由是「被IP用戶或新用戶破壞」。
- 2021年,1次,5月31日,「全保護1週」,理由是「編輯戰」。---(有疑義?是否應屬反破壞。。查詢5/27~5/31編輯紀錄,A用戶5月27日無理由刪除第三方來源內容、無理由隨意改寫改變了原意;B用戶5/27隻撤銷1次,到5/31都沒有再撤銷,4天內只撤銷1次「不附理由、刪除大量內容的編輯」。---這是否能算「編輯戰」?
- 2020年2次,(A)6月13日,「全保護一個月」,理由「編輯戰」。---(有疑義,應是反破壞)。查詢編輯紀錄,應是「反破壞」。原因是,A用戶未經討論、沒什麼具體理由,刪除了13萬-14萬字元來源長期內容,C用戶無理由浮濫添加十多個模板。---這應是反破壞。(B)7月18日,「半保護一年」,理由是「被IP用戶或新用戶破壞」。
- 2019年2次但應屬1次,8月16日「半保護3個月」,同一管理員3分鐘後改「半保護1年」,理由是「被IP用戶或新用戶破壞」。
- (二)【條目李洪志,從2019年起5年半,2次保護】
- 2024年,沒有增保護紀錄
- 2023年,沒有增保護紀錄
- 2022年,沒有增保護紀錄
- 2021年,2次,6月12日「不限期半保護」。6月3日「全保護1週」,理由「編輯戰」。---(有疑義,應是反破壞)。原因是5月27日起,A用戶 無理由刪改大量內容,B用戶、C用戶在5/27~6/2 五天內,各自都附上理由說明 撤銷了1次。
- 註:以上兩個條目,五年來幾次被保護情況,3處提到的A(無理由刪改大量長期內容)是同一用戶。Wetrace歡迎參與WP人權專題 2024年6月19日 (三) 16:07 (UTC)
將「1945年後臺灣政治」訂為高風險主題[編輯]
原標題為:將「臺灣政治」訂為高風險主題
- 下列討論已經關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
臺灣政治類內容長期遭受破壞及編輯戰影響,當中不乏管理員下場參與編輯戰,近期的社會運動導致的破壞及編輯戰更是反映有需要增加一定限制。由此,我提議新增「臺灣政治」高風險主題,涵蓋「1945年後臺澎金馬地區內政外交有關的人物、組織及事件」(不包括已有主題的海峽兩岸關係及臺灣政治地位),實施以下編輯限制:
- 編者須嚴格遵守可供查證、中立的觀點、生者傳記等核心方針指引;
- 管理員可對擾亂編輯(包括破壞、編輯戰及其他不當編輯,或在討論時發表任何針對政治地位的訴諸人身、不文明行為和假定惡意的言論)實施標準編輯限制措施。
- 以下條目因長期遭受破壞及編輯戰影響而提請實施編輯限制措施:
- 中華民國(目前已按WP:CTOP/CSRPS主題不限期保護,不需改變保護狀態)
- 中國國民黨(目前已按WP:CTOP/CSRPS主題不限期保護,而最近的保護是因臺灣本地政治引發的破壞,不需改變保護狀態但應從CSRPS剔除)
- 民主進步黨:不限期半保護
- 台灣民眾黨:不限期半保護
- 二二八事件:不限期半保護+回退不過一
- 太陽花學運:不限期半保護
- 其他建議的編輯限制措施:
- 2024年立法院改革爭議、青鳥行動及子條目:不限期半保護+回退不過一,至事件結束解除;解除全保護以回退限制取代(因事件急速發展,全保護僅會限制條目更新)
--路西法人 2024年5月30日 (四) 12:48 (UTC)
- 「有關的個體」範圍太大(難道合一行動聯盟、中國民主黨也要涵蓋?),建議改為「有關的主要政黨」。--Cmsth11126a02 (留言) 沈伯洋是被大陸國民黨立委扯衣服導致頭部落地的! 2024年5月30日 (四) 13:49 (UTC)
- 「有關的個體」預設僅須遵守三大核心方針,如果起爭議的話也應該按此高風險主題處理即可。--路西法人 2024年5月30日 (四) 16:07 (UTC)
- 臺灣政治相關內容範圍太大,建議縮小。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年5月30日 (四) 13:57 (UTC)
- 或得將「海峽兩岸關係及臺灣政治地位」更名為「海峽兩岸關係及臺灣政治」,然後直接將上該條目列入管制範圍。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年5月30日 (四) 14:03 (UTC)
- 英維能把1992年後美國政治整個納入高風險,1949年後臺灣政治除了年份外顯然不會比1992年後美國政治廣多少,真的難以說是「範圍太大」。海峽兩岸的高風險主題核心在於兩岸間的WP:NPOV、MOS:CS4D,而此建議高風險主題的核心則在於臺灣本地政黨間的內容,兩者顯然屬於不同的範疇,不適宜合併處理。--路西法人 2024年5月30日 (四) 16:11 (UTC)
- 上邊既然包括了二二八,那倒不如將年份拉到1945年。反正只差四年。--Ghren🐦🕓 2024年5月31日 (五) 08:42 (UTC)
- 太習慣1949這個年份了 囧rz……已修訂年份。--路西法人 2024年5月31日 (五) 09:54 (UTC)
- 1945-1949期間哪有台澎金馬地區這種東西( ——魔琴[身份聲明 留言 貢獻 新手2023] 2024年5月31日 (五) 10:15 (UTC)
- 我主要不想特地標明政權名字是為了涵蓋未來任何變化。45-49年台灣的議題到現在還是爭議相當大,寫「45-49年間台灣本島及49年後台澎金馬地區」也比較彆扭吧(((小範圍地有點奇怪大概也問題不大。--路西法人 2024年5月31日 (五) 11:11 (UTC)
- 其實真要說的話,「外交」一詞也能起爭議,所以我覺得確實是別較真詞彙了。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月1日 (六) 17:12 (UTC)
- 我主要不想特地標明政權名字是為了涵蓋未來任何變化。45-49年台灣的議題到現在還是爭議相當大,寫「45-49年間台灣本島及49年後台澎金馬地區」也比較彆扭吧(((小範圍地有點奇怪大概也問題不大。--路西法人 2024年5月31日 (五) 11:11 (UTC)
- 那末「1945年後臺澎金馬地區內政外交有關的個體和事件」或應改為「1945年以後與臺澎金馬地區內政及外交有關的人事物」較為通順。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月1日 (六) 17:10 (UTC)
- 比較少會「物」,更多是「人組成的組織」,形容做「物」有點奇怪吧。--路西法人 2024年6月1日 (六) 17:24 (UTC)
- 「人物、事件及組織」?—— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月3日 (一) 02:30 (UTC)
- 比較少會「物」,更多是「人組成的組織」,形容做「物」有點奇怪吧。--路西法人 2024年6月1日 (六) 17:24 (UTC)
- 1945-1949期間哪有台澎金馬地區這種東西( ——魔琴[身份聲明 留言 貢獻 新手2023] 2024年5月31日 (五) 10:15 (UTC)
- 太習慣1949這個年份了 囧rz……已修訂年份。--路西法人 2024年5月31日 (五) 09:54 (UTC)
- 上邊既然包括了二二八,那倒不如將年份拉到1945年。反正只差四年。--Ghren🐦🕓 2024年5月31日 (五) 08:42 (UTC)
- (+)支持,至於上面提到的範圍太大的問題,目前我是不這麼覺得啦,畢竟那些條目目前也沒有長期受破壞與編輯戰影響,自然並無適用更嚴格編輯限制措施的必要。--冥王歐西里斯(留言) 2024年5月31日 (五) 01:44 (UTC)
- (+)支持--Benho7599 | Talk 2024年5月31日 (五) 06:41 (UTC)
- (+)支持--CaryCheng(留言) 2024年6月2日 (日) 16:45 (UTC)
- 那些表態支持統一的台灣藝人,當作"臺灣政治相關"嗎?--北極企鵝觀賞團(留言) 2024年6月4日 (二) 00:21 (UTC)
- 受到破壞的頁面好像不是很多?——暁月凜奈 (留言) 2024年6月4日 (二) 02:37 (UTC)
- 若人物條目遇政治表態相關的破壞或編輯戰,那麼就適用高風險主題的措施;若破壞或編輯戰與政治表態無關,那麼則不視作高風險主題的編輯限制。--路西法人 2024年6月4日 (二) 05:23 (UTC)
- 人物條目通常適用「WP:CTOP/BLP」(儘管有無政治表態),如果因為政治表態而在短時間內有多則編輯,應該只要臨時半保護就好了(至少3個月)。--Sinsyuan✍️🌏🚀 2024年6月4日 (二) 07:27 (UTC)
- 應該不算。這個主題應該是藍綠白相關。你說的那個大概應該歸兩岸話題管。--MilkyDefer 2024年6月7日 (五) 12:39 (UTC)
- (!)意見-在下以為,(1)「高風險主題」宜審慎討論,避免為了解決改善問題,但增加的限制措施,會不會增加了新問題、副作用或後遺症?(2)是否需要在一些條目討論頁,提醒正在進行這一討論呢?Wetrace歡迎參與WP人權專題 2024年6月8日 (六) 02:48 (UTC)
- 有關2024年立法院改革爭議、青鳥行動及子條目:青鳥行動已結束,2024年立法院改革爭議的主體(2024年立法院改革)也基本結束,只剩一點餘波,大概沒有再限制的必要@LuciferianThomas:。--Cmsth11126a02 (留言) 沈伯洋是被大陸國民黨立委扯衣服導致頭部落地的! 2024年6月8日 (六) 08:21 (UTC)
- 覆議、釋憲、罷免、倒閣等仍然是非常imminent的事情,顯然只是第一階段暫時過去。另外還有關聯爭議(二兆法案、中天條款、黨產條款)等持續中,這也叫「結束」還真的是比較難說得過去。--路西法人 2024年6月8日 (六) 10:23 (UTC)
- 那青鳥行動最起碼是已結束吧。--Cmsth11126a02 (留言) 沈伯洋是被大陸國民黨立委扯衣服導致頭部落地的! 2024年6月8日 (六) 12:19 (UTC)
- 實際上那都算是短期衝突,雖然遺憾,但不應該是高風險主題管制的內容。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月8日 (六) 15:35 (UTC)
- 覆議、釋憲、罷免、倒閣等仍然是非常imminent的事情,顯然只是第一階段暫時過去。另外還有關聯爭議(二兆法案、中天條款、黨產條款)等持續中,這也叫「結束」還真的是比較難說得過去。--路西法人 2024年6月8日 (六) 10:23 (UTC)
- 暫時不反對。Sanmosa Snipe–Clam Grapple 2024年6月10日 (一) 09:42 (UTC)
- 本討論已關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
- (?)疑問-請教,依據「高風險主題」方針,「制定討論的共識需考量所有用戶提出的理據和觀點。」在本案討論中的一些不同意見,結論上會如何處理?Wetrace歡迎參與WP人權專題 2024年6月14日 (五) 01:18 (UTC)
- (?)疑問--請教,以上的問題,依據方針該如何處理?Wetrace歡迎參與WP人權專題 2024年6月19日 (三) 16:14 (UTC)
關於牢大[編輯]
在兩個月前,Shizhao以G3快速刪除了一個標題為牢大的頁面。自然,我用腳趾頭都想得到它在被刪之前寫的大概是什麼。
似乎這個頁面在創建之時不是重新導向頁面。那麼,假如把它改成重定向頁面的話,現時對於確有廣泛使用、意義明確沒有歧義、且帶侮辱性質的重定向頁面的處理為何?--MilkyDefer 2024年6月10日 (一) 13:17 (UTC)
- 不覺得是廣泛使用無歧義,只是一時熱度。重定向到人物很可能無法自解釋,除非指向專門章節或條目。沒有很具體標準吧。--YFdyh000(留言) 2024年6月10日 (一) 13:36 (UTC)
- 如果真的是一時熱度的話,那我明年再問。--MilkyDefer 2024年6月10日 (一) 13:39 (UTC)
- 下列討論已經關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
維基餐廳條文改動投票。
直接寫入菜單[編輯]
|
|
投票:
- (+)支持--☥⚕20204622⚚⚘⸻𒀯космос♾ 2024年6月11日 (二) 11:41 (UTC)
- (=)中立--Cmsth11126a02 (留言) 沈伯洋是被大陸國民黨立委扯衣服導致頭部落地的! 2024年6月11日 (二) 18:42 (UTC)
- 支持。桐生ここ★[討論] 2024年6月12日 (三) 14:39 (UTC)
- 只要不牽扯客棧與RFC機制,那你們怎樣弄都行。Sanmosa Snipe–Clam Grapple 2024年6月13日 (四) 07:39 (UTC)
討論區評審[編輯]
|
投票:
- (+)支持--☥⚕20204622⚚⚘⸻𒀯космос♾ 2024年6月11日 (二) 11:41 (UTC)
- (+)支持--Cmsth11126a02 (留言) 沈伯洋是被大陸國民黨立委扯衣服導致頭部落地的! 2024年6月11日 (二) 18:42 (UTC)
- 支持。桐生ここ★[討論] 2024年6月12日 (三) 14:39 (UTC)
- 只要不牽扯客棧與RFC機制,那你們怎樣弄都行。Sanmosa Snipe–Clam Grapple 2024年6月13日 (四) 07:40 (UTC)
只能由互助客棧改動[編輯]
條文照舊。目前可以使用的食物都列在了下面。如果你有其他的想法(增添、修改、刪除食物),可以在互助客棧中提出。不過要自己加入大家應該也不反對...
投票:
- (=)中立,增添食品要用互助客棧可能太小題大做。--☥⚕20204622⚚⚘⸻𒀯космос♾ 2024年6月11日 (二) 11:41 (UTC)
- (-)反對:(▲)同上,雖然互煮客棧也是一個好廚房[開玩笑的]。--Cmsth11126a02 (留言) 沈伯洋是被大陸國民黨立委扯衣服導致頭部落地的! 2024年6月11日 (二) 18:42 (UTC)
- 作為大廚之一,個人認為若要新增新菜式,可逕行創造相關食物模板或在討論頁中請求大廚烹製相關食物便可,無須經過互煮客棧討論。眾所周知以中維目前社群的狀況,新增食物都要在這裏煮一煮,無疑是浪費社群時間之舉。--維基病夫邀請您加入❤️邊緣人小組·🖊️簽到 2024年6月11日 (二) 11:54 (UTC)
- 這整個議案都沒有在此討論的價值,那不是正式的方針指引而是幽默條目,關於該幽默條目如何編輯的事根本不需要在此討論,任何人都可以直接改動,有不同看法的話在那邊討論即可。--C9mVio9JRy(留言) 2024年6月11日 (二) 14:03 (UTC)
- 一、過往幾個相關討論多有拿來客棧討論(畢竟受眾較廣),此話題確實也「與維基百科有關」,沒見到不允許的理由;二、我想社群應當有保持一絲幽默的資格,偶爾歡樂並無大礙。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月11日 (二) 16:17 (UTC)
- 一個給維基人自娛自樂的頁面,還能如此一本正經地拿出來討論,真有你的。煮不再糊。——Sakamotosan路過圍觀 | 避免做作,免敬 2024年6月12日 (三) 00:53 (UTC)
- 同上,目前不該在客棧。--YFdyh000(留言) 2024年6月12日 (三) 12:29 (UTC)
只能由RFC改動[編輯]
|
|
Why so serious??---Lemonaka 2024年6月12日 (三) 01:22 (UTC)
- 不要為了幽默頁面而打擾眾多維基人。--路西法人 2024年6月12日 (三) 03:47 (UTC)
- 等等等一下,怎麼一個幽默頁面還會吵上來客棧?當維基百科是什麼了?!--SunAfterRain 2024年6月12日 (三) 15:22 (UTC)
- 對於在登記使用RFC服務時設定無接收限制的用戶而言,這樣做過分擾民。Sanmosa Snipe–Clam Grapple 2024年6月13日 (四) 07:41 (UTC)
- Why so serious is a quote from 小丑 (角色), it's a joke to discuss WP:維基餐廳 on WP:VP, this proposal is just a satire for the whole topic.---Lemonaka 2024年6月13日 (四) 10:17 (UTC)
- 然而我就是登記使用RFC服務時設定無接收限制的用戶,我可不認為這是能開玩笑的事情。說嚴重一點,在選舉裏開玩笑能真的把最棒黨選上台。Sanmosa Snipe–Clam Grapple 2024年6月13日 (四) 13:09 (UTC)
- 這整個話題都莫名奇妙地ironic —— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月13日 (四) 19:51 (UTC)
- History is more dramatic than a drama. Sanmosa Snipe–Clam Grapple 2024年6月13日 (四) 23:02 (UTC)
- 這整個話題都莫名奇妙地ironic —— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月13日 (四) 19:51 (UTC)
- 然而我就是登記使用RFC服務時設定無接收限制的用戶,我可不認為這是能開玩笑的事情。說嚴重一點,在選舉裏開玩笑能真的把最棒黨選上台。Sanmosa Snipe–Clam Grapple 2024年6月13日 (四) 13:09 (UTC)
- Why so serious is a quote from 小丑 (角色), it's a joke to discuss WP:維基餐廳 on WP:VP, this proposal is just a satire for the whole topic.---Lemonaka 2024年6月13日 (四) 10:17 (UTC)
- 幽默條目,這未免太歡樂,很會惡作劇--HYHJKJYUJYTTY(留言) 2024年6月14日 (五) 04:28 (UTC)
- 本討論已關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
移除Module:RFX report的「驗票」連結[編輯]
原標題為:Remove 驗票 button from Module:RFX report
- 下列討論已經關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
Morning,It's useless for common users to press "驗票" button on Module:RFX report whilst we have secure poll for our RFA process. The result we got are also not correct. Shall we remove such a button?---Lemonaka 2024年6月12日 (三) 03:19 (UTC)
早上好,我們的RFA流程有安全投票,普通用戶在Module:RFX report上按「驗票」按鈕是沒用的,而且得到的結果也不正確,要不要去掉這個按鈕?---Lemonaka 2024年6月12日 (三) 03:19 (UTC)---Lemonaka 2024年6月12日 (三) 03:19 (UTC)
- ( ✓ )同意--SheltonMartin留言|簽名 2024年6月12日 (三) 03:30 (UTC)
- 在其他討論中看到不少恢復記名投票的聲音,或許應考量添加參數隱藏而非直接移除。--路西法人 2024年6月12日 (三) 03:46 (UTC)
- 本討論已關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
要求社群處理Mys 721tx管理員擾亂性用權、誹謗用戶事情[編輯]
聯署前討論[編輯]
- 不合理封禁:詳情見在下封鎖記錄,Mys 721tx於去年五月份經過「嚴謹的獨立調查」以多項罪名,分別是「大幅刪改擾亂討論秩序」「與共識違背之言論」「未遵循CC-BY-SA署名最低要求」以及「增添未有來源之內容」不限期編輯禁止了我多個頁面。在下認為上述四條指控前兩項是明顯不成立的,後兩項則有嚴重瑕疵。Mys 721tx行為涉嫌不當、充斥瑕疵、違反假定善意、曲解方針、遊戲維基規則,並嚴重缺乏正當溝通。 詳見在下封禁申訴理據,這裡大致講一下:
- 「大幅刪改擾亂討論秩序」,也就是在下在共識政策整理相關言論的編輯行為,Mys 721tx君認為是「經提醒後仍大幅刪改擾亂討論秩序」,根據TPG的規定可明顯得知,此指引限制的是不應在他人給出留言後修改留言,導致已回應之留言被扭曲;去年Peacearth提醒在下的,也是儘量不應在他人回復後大幅刪改留言。Mys 721tx君給出的四項鍊接,其中三個未有人就留言內容進行回復,只是調整格式,一個是根據管理員Ericliu1912進行的排版修訂。故封禁理由與此方針明顯不合。如果考慮該則理由從未給出詳細論證何處違規,違反文明方針輕率指控他人行為不當一條;如果考慮到其作為管理員以不符合方針理由、過往提醒的封禁用戶,還有可能違反了遊戲維基規則中「試圖強行曲解方針,或者無視社群慣用標準,強行使用自己全新的解讀作為「適用標準」。
- 「與共識違背之言論」根據維基百科五大支柱之五,維基百科不墨守成規。方針及其解釋永遠不會板上釘釘不可更改,可以隨着時間推演逐漸擴充。即使在下發表的言論不全然符現存方針,如是改善意願目的而更改,則應假定善意。有用戶如@桐生ここ君則主張, 在下言論屬基於現實資料的,對共識概念的個人理解發表看法,而非試圖針對方針進行曲解。
- 「未遵循CC-BY-SA署名最低要求」即未在相關翻譯頁面增添Translate模板:蓋兩則鏈接,一則在今年一月份由其他用戶添加,不知何處違規(未得其解釋)。第二則本人確實疏忽,然而此前未就此次編輯有提醒、可能嚴重擾亂(即會被封禁甚至永久封禁)的警告下,直接施以方針限制用於嚴重擾亂行為的不限期封禁,明顯過當。
- 「增添未有來源之內容」蓋兩則鏈接,第一則翻譯自英文維基百科,均有來源,不知何處違規(未得解釋)。第二則仍是翻譯自英文維基百科,雖無來源,但根據相關事實推定整修,應符合社群最低限度。同時,此為獨立議題,在下此前從未收到過添加無來源內容將被封禁之通告、提醒與警告等。如此直接地予以必須是針對「嚴重擾亂行為」的不限期封禁,顯有違封禁方針的「確認有改善可能」及「教育用戶熟悉方針」的原則。
- 此封禁已被我在內五名普通用戶(Gluo88、Lanwi1、桐生ここ、Shwangtianyuan、Hoben7599)及三名管理員(Ericliu1912、Manchiu以及認定該則查封理據欠缺的Bluedeck)質疑理據或認為不妥。當中有用戶陳述其封禁為「暴力派管理員執行的不當封禁」「過激行為」「已開始質疑其封禁的公信力」「沒有認真思考,沒考慮到用戶權益」「有必要檢視他的如此做法是否妥當」等。
- 持續拒絕溝通、遊戲社群承諾:Mys 721tx君在去年9月份罷免終止時作出「
感覺到有必要與社群作更有效之溝通
」的宣稱,然而半年後在今年五月份再次發生未經適當溝通情事(至少在下被封禁期內,無論事前事後,均並無感覺到有所謂「更有效之溝通」。先前兩則回應,均稱在下質疑是「對扭曲方針的認識」,並明確拒絕解封,直到在下「通過行為意識自己的錯誤」)。在下依據封禁政策「執行封禁的管理員則可能按情況被要求查看及參與申訴討論,並提供更多信息。」三度通知涉事管理員(兩次Ping、一次正面要求)對封禁質疑diff逐條解釋,回應社群用戶質疑。直至解封,Mys 721tx未給出任何回應(包括Shwangtianyuan君在討論頁的提問)。在下認為此言論如果不是僅為撇清責任之語惡意協商(遊戲維基規則:惡意協商,提出讓步以吸引其他編者達成妥協,但在對方妥協後拒不執行之前承諾的讓步。
),就是對自身行為認知仍有嚴重缺失。 - 誹謗用戶:去年9月份Mys 721tx罷免案,在經過行政員爭議的終止後,Mys 721tx自稱「我理解過去的一些言論不符合社群部分成員的預期,行為永遠比承諾更為重要。在過去的半年時間內,我已經儘量避免了任何可能引起爭議的言辭。這部分大家有目共睹。」然而,Mys 721tx卻在罷免期內(9月20日)於站外群組wikipedia-zh-autoconfirmed同支持者Quinnie.wong誹謗、侮辱彈劾動議支持人,前管理員Lanwi1泄露用戶個人資料的指控暗示:
我很好奇支持者是誰,然後看了一下簡介,原來是反對基金會2021行動的大陸編輯 😂當初基金會為啥沒把他一齊封了? 😜--Quinnie.wong,2023-09-20-2:00
[1]Lanwi1選上CU之後守望者愛孟立馬可以接觸到cuwiki的內容。--Mys 721tx,2023-09-20-2:19
[2]
- 上述兩則惡意言論已造成Lanwi1的精神痛苦加劇。根據維基媒體運動通用行為準則條款,不文明行為的限制同樣限制在虛擬空間內(包括站外群組)。作為管理員在面對爭議時不回應,反為避免自身指控,對質疑他的人訴諸人身,不符合中文維基百科與維基媒體運動的通用行為準則文明政策。此外,將不合理封禁中的第三條、第四條部分合規編輯定性為擾亂,並拒絕給出解釋,同樣屬於誹謗用戶行為。
以上種種,不一而足。涉事用戶在去年RFDA曾作出所謂「改善承諾」使社群(包括彈劾動議支持者的在下)原以為其能認真反省,珍惜社群給予機會。甫經九個月不到,該君違反承諾再次作出明顯擾亂性用權,不屑於同當事者溝通,態度居高臨下,令人難以忍受。現依據《管理員的離任》政策:
- 不合理的封禁用戶或者以封禁相威脅。
- 一再發生的、嚴重違反社群共識及禮儀。
因此在下要求社群討論並處理該用戶自2021年不當封禁Arikimal起,常年危害社群協作的問題,包括多次擾亂性用權(扭曲方針政策認識的濫用封禁、誹謗用戶行為)、長期違反協作準則行為(輕蔑用戶、冷處理、溝通不當、遊戲承諾)等。同時鄭重邀請另一事件當事人@Lanwi1君向社群陳述涉事用戶行徑對您的影響。 依去年RFDA修訂案(路西法人版本)被社群否決,行政員無權在本討論過程中確認RFDA(若有發起)共識或溝通有效與否,亦無需得一致共識讨论认为罪状成立与否(仅依往年惯例标准,由提案人在内联署者意定沟通无效之共识倾向,48小时过后,适当时正式发起解任投票联署确定罪状)。以上。--Gluo88(留言) 2024年6月13日 (四) 12:44 (UTC)
- 我只能說時隔一年,同樣的事情再次發生,我感到非常遺憾。
- 我建議社群考慮設置類似「請求封禁」的機制,即有共識後再執行封禁,而非管理員獨自判斷引起爭議。
- 對於解封請求,我建議擴大WP:AARV的使用,由社群進行判斷封禁是否適當,在此廣告一下。--桐生ここ★[討論] 2024年6月13日 (四) 12:53 (UTC)
- 請求封禁好像來自日維?--日期20220626(留言) 2024年6月13日 (四) 13:25 (UTC)
- (+)支持。封禁幾乎是維基社群對某名編輯的最高程度處罰,而這種級別的處罰居然沒有復核機制,這倒是讓我覺得有些詫異。特別是某位同樣作風強硬的人已經當選後,我覺得封禁複核非常有必要了。--Chiu Hsiao (✉️Message) 2024年6月13日 (四) 13:44 (UTC)
- 我是從英文維基引入的方針,原方針在此。--Shwangtianyuan 不忘初心 牢記使命 2024年6月13日 (四) 14:02 (UTC)
- 日文站確有此規則,LTA:WMLO主賬戶即透過「請求封鎖」機制被日文站管理員封鎖(ja:Wikipedia:投稿ブロック依頼/維基百科最忠誠的反對者 條件変更)。--Allervous初音ミクのセーラー服 2024年6月17日 (一) 04:04 (UTC)
- 請求封禁好像來自日維?--日期20220626(留言) 2024年6月13日 (四) 13:25 (UTC)
- 我看了維基百科:管理員解任投票, 有看到要提出解任申請的理由,沒有看到所謂的「罪狀」--Wolfch (留言) 2024年6月13日 (四) 13:20 (UTC)
- 2021年某用戶的封禁就是一個例子,該人在「烏合麒麟」添加了他的配偶資料之後在無警告下被苗管無限期封禁,之後還是在交涉下縮短至14天(但還是過重)。--Shwangtianyuan 不忘初心 牢記使命 2024年6月13日 (四) 14:06 (UTC)
- 無限期封鎖後確認有意願改善是可以解封的,這個也是你所寫的不限期不等於永久非常好的例子。這些例子中,「不限期封鎖」並不代表「過重」,而是要對方知曉自己編輯有什麼問題才解封,理論上不限期封鎖可以是半天、可以是一個月,並沒有「比哪個特定時長更嚴重」一說。本案中針對Gluo88的封鎖亦是如此,只是解封管理員認為「不至封鎖」(原先解封理由寫「不構成封鎖理由」,後在表達只是他認為「可以不查封」而解除封鎖,表示Gluo88在此案中所指苗君封鎖理由錯誤、疏忽、瑕疵等說法並不成立。「可以不查封」不代表「不能查封」或「封鎖不合規」。--路西法人 2024年6月13日 (四) 15:42 (UTC)
- 兩個IP用戶加入侵犯個人隱私內容(Special:Diff/68715432、Special:Diff/68719665、Special:Diff/68718186、Special:Diff/68718195)導致條目半保護後,有自動確認用戶繼續加入侵犯個人隱私內容。請問如何解釋該巧合?編輯提示中明確顯示"在世人物的爭議性內容必須帶有來源且來源充分可靠,否則就不能加入至條目中"時沒有人會意外違反WP:BLP。--Mys_721tx(留言) 2024年6月13日 (四) 16:55 (UTC)
- LuciferianThomas所謂:
這些例子中,「不限期封禁」並不代表「過重」,而是要對方知曉自己編輯有什麼問題才解封,理論上不限期封禁可以是半天、可以是一個月,並沒有「比哪個特定時長更嚴重」一說。
明顯曲解政策「厘定封禁期限」一欄指出「封禁的目的是預防不當行為,因此封禁期限應根據用戶是否可能重複不當行為而定。」「簡而言之,管理員在厘定封禁期限時應考慮:該不當行為的嚴重程度;及該用戶是否初犯」
封禁政策兩則條款均指出封禁必須顧慮到「嚴重程度」以及「用戶是否初犯」。 - 有關條文指出不限期封禁的限定範圍屬於構成「嚴重擾亂」才得以施以。對於輕微或者明顯誤判、被人質疑過當之等可能不構成嚴重擾亂必須適當釐清封禁的期限,而非對此類行為動輒予以不限期封禁,期待對方悔改後降低標準。並且必須通過嚴謹調查(封禁政策指出「對用戶有極大的影響,因此必須基於可被復檢的證據及合理判斷,經詳細考慮才執行。」)有關言論再度顯示出Mys 721tx及其支持者濫用不限期封禁的扭曲認識。如在下一案,以及Shuwang君指出僅為初犯的案子,未見「持續不當行為」便被不限期之封禁。。
- 所有用戶均可以尤其本案已被多名用戶及一名以上管理員質疑理據、指出封禁不妥、過重(包括「誤判」理據、魯莽指控他人行為不當、曲解政策、未經事前教育溝通、仔細查證等等),涉事「管理員」被指出濫用封禁後,至今仍然不屑於回復上述問題,顯然對自身擾亂性為毫無認知。在下在此呼籲Mys 721tx閣下因擾亂性用權辭去管理員一職,以正視聽。並呼籲LuciferianThomas君正視該管理員被多名用戶指出之問題,而非以一人之見,檢討受害人、引用法律條文闡述政策之維基法匠行為、運用紅鯡魚(無論有意無意)持續涉嫌袒護涉事用戶。
- LuciferianThomas所謂:
- --Gluo88(留言) 2024年6月13日 (四) 18:40 (UTC)
- User:Lanwi1所謂"暴力派管理員執行的不當封禁"屬於明顯未經論證的魯莽指控。
- User:Shwangtianyuan多次主張"他封禁用戶的次數,可能是中維之最"是明顯未經論證的誹謗。僅以具有"爭議"帶過明顯經過調查的封禁是明顯魯莽指責。其列舉的激進行為亦是與騷擾User:Wing時的羅列罪名如出一轍(Wikipedia:互助客棧/其他/存檔/2024年2月#關於行政員、管理員Wing的提報侵權行為)。User:Shwangtianyuan所指控反駁如下:
- User:User3204作為自動確認用戶,在條目因IP用戶破壞被半保護加入泄漏他人隱私站點鏈接顯然嚴重違反生者傳記。
- User:PaintWoodSt顯然違反嚴重原創研究(見User talk:PaintWoodSt眾多例子)。
- 以User:Shwangtianyuan自己的話說,"User:Stevencocoboy曾由於持續添加無可靠來源、臆測內容,且近一日內無解釋,而被不限期禁止編輯主命名空間。"
- 多人進行魯莽指控仍然是魯莽指控。--Mys_721tx(留言) 2024年6月13日 (四) 19:26 (UTC)
- 此外見User:Bluedeck/etc/sandbox/box1718239888243中對與User:Gluo88侵權與原創研究的獨立驗證。--Mys_721tx(留言) 2024年6月13日 (四) 19:29 (UTC)
- 上述所謂「魯莽指控」顯示涉事用戶Mys 721tx君明顯雙重標準,嚴以待人,寬以律己,在本年一次4月的討論中,mys 721tx在被問及部分指控是否違反文明時,自稱「
因線下事物繁忙,未能完整看完來龍去脈。單就文明一事,因為沒找到適合的中文表達方法且需要nuanced analysis,英文留言如此:A heated discussion per se is not uncivil. A discussion of a user's conduct or history is not inherently a personal attack either.
」上述用戶質疑均是Mys 721tx針對本案及常年用權行為與言行之主體觀感(包括過激封禁、誹謗等),天理昭昭,顯然符合上述定義的「A discussion of a user's conduct or history is not inherently a personal attack either」。 - 雖在下被閣下「涉嫌不當、充斥瑕疵、違反假定善意、曲解方針、遊戲維基規則,並嚴重缺乏正當溝通。 」地顯然將封禁用作懲罰、警告,但仍然在事後鄭重向第三方管理員宣言「
...在下仍於此及討論頁鄭重承諾會熟悉相關政策後,謹慎地作出有益維基百科編輯
」反觀閣下被(現今除某支持者外)多名用戶指出問題,仍然堅持拒絕承認自身錯誤,不得不感到十分遺憾。 - 上述持續發表規避爭議、涉嫌指控其他用戶轉移自身矛盾,更加論證在下指控其去年作出的承諾宣言明顯屬於「惡意協商」(
惡意協商,提出讓步以吸引其他編者達成妥協,但在對方妥協後拒不執行之前承諾的讓步
)」,遊戲「感覺到有必要與社群作更有效之溝通」改善承諾。請求社群持續探討該君不當態度事情。
- 上述所謂「魯莽指控」顯示涉事用戶Mys 721tx君明顯雙重標準,嚴以待人,寬以律己,在本年一次4月的討論中,mys 721tx在被問及部分指控是否違反文明時,自稱「
- --Gluo88(留言) 2024年6月13日 (四) 21:41 (UTC)
- Accusations about personal behavior that lack evidence [are personal attacks]. Serious accusations require serious evidence, usually in the form of diffs and links. Lawyering will get you nowhere.--Mys_721tx(留言) 2024年6月13日 (四) 22:33 (UTC)
- 此外見User:Bluedeck/etc/sandbox/box1718239888243中對與User:Gluo88侵權與原創研究的獨立驗證。--Mys_721tx(留言) 2024年6月13日 (四) 19:29 (UTC)
- 2021年某用戶的封禁就是一個例子,該人在「烏合麒麟」添加了他的配偶資料之後在無警告下被苗管無限期封禁,之後還是在交涉下縮短至14天(但還是過重)。--Shwangtianyuan 不忘初心 牢記使命 2024年6月13日 (四) 14:06 (UTC)
- 光是這一則發起解任的討論就足以論證Gluo88究竟要扭曲多少個概念。從「被大家認定跟苗君走得很近」的我的視角來說:
- 「大幅刪改擾亂討論秩序」封鎖理由:Gluo88過往在討論中確實有該類行為,但後續「刪改討論擾亂秩序」的情況確實為苗君誤判(但行為相當類似過往行為),藍桌君解封後苗君未有就該點提出異議。如果說苗沒有對被封鎖人假定善意,那麼被封鎖人對苗毫無假定善意為誤判又是什麼道理?
- 「與方針相違背的言論」封鎖理由:Gluo88在該處討論中,雖然是如桐生ここ所言「引用真實狀況」描述「現實中的共識」,Gluo88卻是在該處討論中多次以「現實中的共識」來解釋「維基百科上的共識」,並試圖以該等解讀強加於本站的討論流程之上。
- Gluo88在其發起的話題中,在我指出維基百科不是民主體制後,仍然持續發表「共識是民主體制的一種,而且是加強版的民主」等話,接續的留言已經完全跟「現實的民主共識」和「維基百科的共識體制」混為一談,已經不再單純是「引用真實狀況」描述「現實中的共識」,而更有強行選擇性地摘用「不墨守成規」扭曲理解方針,用來支持實際上不符合方針的觀點。WP:NOT作為五大支柱之一,其中WP:NOTDEMOCRACY高於WP:共識中被本地超譯得來、英維原則性不存在的「多數決」。
- 更何況,本地共識方針不論當前版本的制定討論還是現有方針文內,還有各站版本的共識方針,都明確「論點強弱比支持人數更重要」的敘述,在我指出有關維基百科共識的原則後,Gluo88持續無視並繼續強行將外間不符合本站核心方針的理解強加於討論的程序性問題當中,顯然不是只是「提出觀點」,而已經是「以不符合本站方針的理解強加於本站之內」了。
- 「未遵循CC-BY-SA署名最低要求」封鎖理由:就連給Gluo88解封的藍桌君都在解封時的留言是指出署名不當,後續苗君抗議時也清楚指明CC BY-SA要求必須提供頁面連結及過往貢獻者列表,Gluo88獲我過往提醒後也仍然多次未能滿足基本版權需求。藍桌也在後續留言中改口指其解封理由中「不能構成查封理由」是理解作「他認為可以不查封」而非「查封理由不成立」的意思,完全直接給Gluo88口中的苗君在此項封鎖上所謂「嚴重瑕疵」打臉。
- 「增添未有來源之內容」封鎖理由:給Gluo88解封的藍桌君在與苗君交涉時已表明同意苗君所指
從英文維基百科翻譯無來源內容仍違反可供查證方針。添加內容的編輯有舉證責任。
雖指出「給出的例子不足以封禁」,但也有補充指明如果能發現本用戶更多更大量的違反2, 4,那麼的確可以再檢討
,繼續打臉Gluo88口中的苗君在此項封鎖上所謂「嚴重瑕疵」。 - 「持續拒絕溝通」:這一點真的是荒謬之極。為什麼苗君作為管理員,在依照方針認定用戶違規後,指出用戶「對扭曲方針的認識」,並明確拒絕解封,直到你「通過行為意識自己的錯誤」,這樣就叫做「無效溝通」;而申訴人就可以徑自判定自己的行為完全合理、判定管理員行為不當,申訴人就必然是對的,申訴人不從執行封鎖的管理員的角度去分析管理員指控的問題,這就可以接受?況且管理員已經回覆過,他的立場不變的情況下,為何要重複回應?重複回應同樣立場的說辭是不是又會被Gluo88打成「無效溝通」?所以結局必須是管理員撤回封鎖才叫「有效溝通」?荒謬至極。
- 「誹謗用戶」:這個更完全是無稽之談。既然Gluo88這麼愛拿現實的例子來說,而本站又沒有對「誹謗」有異於一般的理解,拿就拿現實的「誹謗」來說。誹謗在臺灣法律中,可受公評之事及與公共利益有關的申請不能認定誹謗、有盡力查證也不構成誹謗。對Lanwi1的有關質疑是針對其擔任用戶查核員的時期,這是「可受公評」之事;CU資訊被泄漏顯然是涉及「公共利益」之事。況且,Gluo88也選擇性摘錄苗君言論、斷章取義——苗君在Gluo88引用的這一句後,在短時間內也補充了「也可能只是巧合(」、「這算第一手來源(」「不是考古(」,也在後續給出兩條令他合理認為Lanwi1涉案的站內diff(訊息 diff、訊息 diff),具備查證和證據,從任何角度上,這都不能構成誹謗。再結合苗發言中的「時機點」分析,也就是剛好Lanwi1上任後鬧出這一齣問題。這或許當中包含了對事件的臆測,這確實不是理想做法,但苗君的發言幾乎完全符合現實世界刑法中不構成誹謗罪的多個條件。更甚者,苗的留言只是指出兩個時機,後續所說「也可能只是巧合」更是證明他有描述時機的可能性,而並沒有實質指控Lanwi1就是做了某件事。當中表現出他有這些懷疑,但從字面上根本不存在指控一說,「A做了某件事,然後B就發生了」這一句話根本就不等於「A做了某件事令B發生」;「有懷疑」更不可能構成誹謗(懷疑公民犯案而舉報但最終證明沒有也不一定構成誹謗,除非捏造或毫無證據而形成誣告)。反過來說,Gluo88指出Lanwi1受到心理壓力的diff中,Lanwi1卻是毫無證據論證的情況下指控了「會不會反而是說他(L)泄漏CU資訊的人自己做的」,無論證的指控比有論證有證據懷疑的指控更「可能」構成誹謗,但還是那句,在我眼中可受公評之事不構成誹謗。
- Gluo88為了「證明」苗君有罪,此處所列的所謂「擾亂用權」事項無一對管理員有任何假定善意,卻要求管理員對自己假定善意,從頭到尾簡直不可理喻。--路西法人 2024年6月13日 (四) 14:35 (UTC)
- 另外,在上次的除權過後,雖則我的提案未獲通過,但
解任共識之討論或投票,其形式、程序與投票者資格,皆與管理員選任相近。濫提、不符合假定善意、違反維基方針、禮儀、討論程序之解任提請,皆可經非當事管理員或行政員取消或中止
條文仍然未被動搖。若提案人試圖以明顯扭曲時機情況、明顯扭曲方針指引及存在明顯錯誤的指控,以至符合「不符合假定善意」、「濫提」(所謂行為不當事實被扭曲至構成擾亂),不符合解任基本條件而推動管理人員解任投票,我仍然會提請任何非當事管理員終止解任程序。如果Gluo88是認為自己的論據這麼站得住腳、這麼符合方針指引理解的,在社群主流意見已經傾向需要經過調查構成違規事實才開展解任程序的背景下(有相當主流、近乎共識的社群觀點),不妨等候仲裁委員會成立,要求仲裁委員會按照Finding of facts及各用戶的陳述,按照方針指引規範認定苗是否需要被解任,以及你的過往行為是否確實構成違規,而不是單憑你自己因為不喜歡苗的行為,就無限扭曲事實來發起解任。--路西法人 2024年6月13日 (四) 14:48 (UTC)- 路君提到了「仲裁委」,現在看來還是有必要在中維設置該委員會處理爭論,作為爭論解決的「最終手段」。--Shwangtianyuan 不忘初心 牢記使命 2024年6月13日 (四) 15:04 (UTC)
- 本來就是,而不是容許某些用戶徑自扭曲方針理解,不顧其理據是否合理就硬闖解任投票。沒有合理原因的解任乃是對社群的羞辱。--路西法人 2024年6月13日 (四) 15:19 (UTC)
- 感謝您的評論:在下對「被大家認定跟苗君走得很近」的LuciferianThomas前來發言,踴躍參與此討論的可能性早有預料,茲對閣下回應如下:
- 一、
Gluo88過往在討論中確實有該類行為,但後續「刪改討論擾亂秩序」的情況確實為苗君誤判(但行為相當類似過往行為),藍桌君解封後苗君未有就該點提出異議。
在下很高興閣下確認這是「管理員誤判」的情形。在下自被封禁期間已明確假定善意Mys 721tx封禁本人「...一定是有令人敬服及光明正大之理由,因此在下才要求Mys 721tx君必須按維基百科的精神 「充分溝通 」,供社群檢驗。」
在下已連續Ping多次(包括一名用戶在討論頁通知)並一次當面要求當事管理員回應此誤判質疑,卻未能得到任何回復,可合理認為其拒絕自己錯誤封禁理據溝通解釋。另此則質疑明顯屬於訴諸偽善。請停止詭辯。 - 二、
Gluo88卻是在該處討論中多次以「現實中的共識」來解釋「維基百科上的共識」,並試圖以該等解讀強加於本站的討論流程之上。
屬於個人觀點。在下只能說包括我在內的桐生君、Manchiu君和第三方管理員Bluedeck君均認為在下發表之言論理應假定善意,或不構成擾亂討論之查封理由。可見其明顯爭議封禁理據並非在下一人獨斷或一人扭曲概念,而是參與討論用戶多數認定(如果閣下欲將其定性為「未獲絕對多數同意但反方理據極度薄弱」,在下無回復必要。)- 三、四:
後續苗君抗議時也清楚指明CC BY-SA要求必須提供頁面鏈接及過往貢獻者列表,Gluo88獲我過往提醒後也仍然多次未能滿足基本著作權需求。
在下此處所指瑕疵即「程序溝通不當」「未經正當溝通」「未考慮觸犯」「未考慮有改善可能」。我於第三方管理員Bluedeck君處已完全闡釋在下的對於管理員理應如何對待用戶之態度(或者「更適當」的態度)
- 三、四:
- 一、
不顧警告,多次張貼版權材料的貢獻者可以由任何管理員加以封禁,以阻止問題進一步產生
在下完全同意。然而需要分清什麼是「警告」什麼是「不足的提醒」。根據閣下去年10月份在在下的留言,我可以視作善意提醒。但是這足以保證一位用戶認知到持續此一行為將導致封禁甚至不限期封禁麼?根據封禁政策的三項原則「確保用戶熟悉規範」「確保目前無改善可能」「封禁始終為最後手段」,我認為當事管理員Mys 721tx君可以採取適當的措施教育用戶(不僅僅是本人,而是每一個編者)指出問題,並熟悉有關政策(比如提請互助客棧討論(見此案)、在本人討論頁面發可能受到封禁警告等,在下熟知後完全可以接受並改善審查過往問題),而非直接無預警予以不限期封禁。政策原則已明確規定不能用於懲罰,也不能用作警告。- 在此跳過上述溝通程序,明顯不當,並侮辱了封禁政策三大原則最重要的,即封禁永遠只能視作最後手段。
- 五:
為什麼苗君作為管理員,在依照方針認定用戶違規後,指出用戶「對扭曲方針的認識」,並明確拒絕解封,直到你「通過行為意識自己的錯誤」,這樣就叫做「無效溝通」
:您提出的這個問題甚好,那麼就請Mys 721tx自在下提出自在下封禁申訴以來,針對本封禁所有(連LuciferianThomas君替他承認的「誤判」)Mys 721tx封禁行為被質疑涉嫌不當、充斥瑕疵、違反假定善意、曲解方針、遊戲維基規則,並嚴重缺乏正當溝通的每條diff的依照方針所給出之解釋與回答。如果您認為居高臨下的,武斷指控別人「方針的扭曲認識」後拒絕予以解釋自己的被多名用戶廣泛質疑的封禁,屬於所謂「有效溝通」,在下無話可說。至於所以結局必須是管理員撤回封禁才叫「有效溝通」?
屬於明顯紅鯡魚並曲解本人封禁申訴多次要求管理員解釋不當封禁理據保護用戶權益的本意,而非為解封不擇手段。不對此涉嫌詭辯作出評論、 - 六、
誹謗在台灣法律中,可受公評之事及與公共利益有關的申請不能認定誹謗、有盡力查證也不構成誹謗...
及其一系列法律引用闡釋,明顯屬於維基法匠謬論:以不恰當的方式使用正式的法律條款討論維基百科政策...
。我們這裡僅討論何為一般人所理解之誹謗為何:字典解釋即「散布不實言論而損壞他人名譽」。如果有明確證據(屬實而非不實)證明Lanwi1泄露CU數據,自然屬於公評之事。但是連閣下自己都承認這或許當中包含了對事件的臆測,這確實不是理想做法
既然沒有任何證據,那麼屬於無端臆測,持續散布這一言論明顯構成對當事人之誹謗,無需多言(並且明顯造成他人強烈精神痛苦,就算在此精神痛苦情境下即使反指控等仍可被原諒)。 - 況且,如果閣下認為Lanwi嫌疑關乎所謂「社群利益」,閣下與Mys 721tx君應該將Lanwi1提至元維基CU部門,根據其調查結果在做論斷、評議。相信到時社群自有一番公論,而非散布未經證實之謠言,造謠誹謗用戶名譽(尤其還在罷免期間發表此等不當言論,顯然是為訴諸人身規避自身爭議),甚至對這種誹謗行為採取辯護、鼓勵,謂之所謂「可受公評」,實在無法忍受。在下在此(!)強烈抗議LuciferianThomas這種檢討受害者的擾亂討論行為。請立刻停止,並對Lanwi1道歉。否則不排除提報,請求社群處理。
- 綜上,在下認為任何人都能知道是誰在扭曲政策,假定惡意、對被封鎖用戶施行雙重標準,幾乎無條件擁護管理員的言辭,甚至發出檢討受害人,此類漠視、扭曲一般人禮儀標準的明顯擾亂言辭,藐視通用行為準則及維基百科的和諧原則。
- 最後,在下對於LuciferianThomas君持續如在Wp:共識討論一般,發表牴牾與自己意見不合者之冗長言論、以尚未通過組建之仲裁委員會成立審核機制為由,明顯對管理員的個人擁護,試圖阻撓、凍結本次彈劾表示(-)強烈反對與(!)強烈抗議,並且此則為獨立議題,顯然不與本次涉事管理員爭議相關,在下已拆分作為獨立議案,以免分散討論,望知悉。
- 在下聲告,如有行政員在社群討論過程中違背維基百科不是官僚主義地迅速如上次般(七個小時不到地)作出凍結此案決定,不排除要求社群對涉事行政員提出新一輪質詢。
- 不對進一步冗長討論及曲解政策發言作出進一步回應。除非擾亂討論秩序。--Gluo88(留言) 2024年6月13日 (四) 16:48 (UTC)
- 充滿邏輯謬誤的觀點不會站得住腳。
- 有關「誤判」:這一點我不清楚,但苗君是否有可能以過往你的不當刪改、移動自己的留言,從而認定你在其他討論頁將留言多次移動分拆構成該等理由。我這裏所指的「誤判」是「與過往提醒不盡相同的違規行為一併認定」,過往是被回覆了的留言的刪改,現在是尚未回覆但已相隔一段時間,有可能已有用戶閱讀的情況,後述情況苗君單憑在你在發表留言後大幅刪改留言即可成立「剪貼討論構成擾亂討論串運作」;而苗君在對藍桌君解封理由的交涉中未有提及該項,苗君是否認為藍桌認定未有後續留言的論點作為合理解釋也是未知。
- 有關「對苗君的假定善意」:你從被封鎖後首則回應就質疑管理員是否不當就聯署報復(無證據指控)、本次封鎖後首條找Ericliu1912的求助訊息的第一個點列項就已經質疑苗君的能力,這些都是封鎖過後先發生的事,從一開頭就假定惡意、訴諸動機、通過發訊息及提及拉人支持自己,這些從一開頭就不是假定善意的表現;而詢問苗君封鎖原因為何的語句更是有咄咄逼人甚至是挑釁的意味。我不只是單純說「你也一樣」,而是「你這些簡直就不是假定善意」。更何況,管理員封鎖的「善意認定」單從過往是否已獲提醒,後續是否持續再犯認定編者編輯非善意,更何況善意的損害性編輯亦可構成擾亂,苗君封鎖時以「提醒後持續」認定需要封鎖顯然已經符合以上要求。
- 有關「對你扭曲本地方針理解的假定善意」:同上論點,在我已經明確告知你不應在維基百科討論將現實中的觀念與站內的觀念混為一談後,你仍然持續混淆有關觀念,並強行將「現實中的共識」是「民主體制」用以辯論站內流程,顯然已經越過了可以被假定善意的底線。經提醒(假定善意)後仍然持續的行為被封鎖是完全合理的。
- 有關「程序溝通不當」「未經正當溝通」「未考慮觸犯」「未考慮有改善可能」:苗君的四項封鎖理由中,有三項你都已經獲得明確的提醒(已經滿足教育用戶的要求),經提醒後仍然持續觸犯而認定無改善,需要以封鎖阻止不當編輯持續,完全合乎程序。另外一項則是調查你的貢獻時另外發現的長期擾亂性編輯(不等於是你的編輯帶有惡意,善意的損害性編輯亦可構成擾亂),合併加入作為封鎖時長考量而已。你不是未獲提醒,而是在多種行為都獲得過提醒而仍然持續,尤其WP:COPYVIO及WP:V都是本站不可侵犯的重要方針,在提醒後短時間內繼續違規,顯然已經是認定無法通過提醒停止你的錯誤編輯下才作出最後封鎖的決定。
- 有關「缺乏溝通」:除了對藍桌解封提出的交涉外,苗君在封鎖時亦有列出清楚的diff。你已經完全認定其是出於惡意而封鎖下,顯然苗君再說什麼你也只會不顧方針依據而認定為扭曲。光是你在提此案是的態度已經足以證明你是打算學WMLO那樣,不論苗的說辭如何、是否符合方針,都將強行闖關提出解任。
- 有關「誹謗Lanwi1」:顯然你已經是在選擇性閱讀我所指的事項。苗君確實有為其說法提出證據,連diff都給了,那些diff都是Lanwi1自己在客棧的留言存在前後矛盾,也只是在複述當年社群對於Lanwi1行為的質疑。Gluo88選擇性閱讀,並在我已經指出苗君有提供證據的情況下,還謊稱苗君的懷疑或聲稱「有任何證據,更何況當時正是苗君對Lanwi1對CU結果理解提出的質疑,該串討論惟有Lanwi1與其他用戶查核員觀點不一致,而當時情況正是說被外流的用戶查核資訊與用戶查核員結論被指不相符,在任何直觀的邏輯下,苗君當時及現在也是作為第一身用戶(用戶查核員)接觸到的資訊而懷疑Lanwi1。提出基於證據的合理懷疑和指控顯然跟「毫無證據的虛假指控」完全沾不上邊,而指出過往留言作證據不可能構成「散佈不實言論」(並無憑空捏造證據),從而不能構成「誹謗」。再者,你說什麼「應該將Lanwi1提至元維基CU部門」,當初大概就是有用戶向基金會有關部門提出指控而導致全站凍結用戶查核權,這豈不是已經發生了嗎?還是你裝作看不到?
- 有關「檢討受害者」「無條件擁護管理員的言辭」:我「無條件擁護管理員的言辭」?苗君的錯處我都能指正出來,但他的錯處明顯多數存在被你放大扭曲的情況,指出你的錯誤就叫「擁護管理員」?苗君作為第一身用戶提出對Lanwi1的懷疑,你毫不懷疑就完全接納Lanwi1的說辭和對苗君的反指控,更是對Lanwi1沒有半點質疑和懷疑,定性Lanwi1必然為「受害者」而毫無懷疑,還為了他而選擇性閱讀證據,這不是才是「無條件」擁護(前)管理人員的言辭?這個「受害者」是何來的證據認定其無辜?苗君作為當時第一身用戶的證據可指出合理懷疑(而不能直接篤定)是Lanwi1所為並提出這類的指控,相反Lanwi1身為「受害人」,在毫無證據、論證的情況下一下子指控多名用戶涉案,而僅有「我推斷」這樣的說法,連「基於當時某些用戶的某些行為」都沒有,這是哪門子的受害人?這些行為正是「加害人」行為!
- Gluo88在此次除權討論中多次明言威脅其他管理人員,以此脅迫他人無視實際情況而就範,藏都不藏,乃是完全不可接受的行為。社群如果接受這樣子的脅迫,那是否以後威脅其他管理人員提出除權就是王道?顯然不可能!--路西法人 2024年6月13日 (四) 22:10 (UTC)
- Gluo88肆意威脅、攻擊管理人員的行為已經明確構成維基百科:管理員的離任 § 通過解任投票除權下所指的「濫提、不符合假定善意、違反維基方針、禮儀、討論程序之解任提請」,若此用戶意圖發起任何違反方針要求的解任請求,第三方管理人員應按方針阻止,不能放任此用戶以扭曲的觀念及明顯不文明的態度發起解任請求。--路西法人 2024年6月13日 (四) 22:39 (UTC)
- Wikipedia:討論頁指引#自己的意見中規定儘量不應修改自己的意見,若有修改亦應明確表示。刪改移動留言確實可能影響已閱讀討論的編輯。社群習慣做法是在修改留言後附註改動、或通知討論參與者變動。缺少這些展示會影響到修改前後參加討論的編輯。指引中已"列明儘量不要更改"之前留言,習慣性修改之前的意見顯然不是"儘量",尤其在已經獲通知後持續違規行為。我雖然同意User:Bluedeck該項或可不封禁,但不代表該行為不會擾亂討論秩序。持續擾亂討論順序的行為本身就是可封鎖事宜,亦不代表封禁不符合規範。--Mys_721tx(留言) 2024年6月13日 (四) 23:49 (UTC)
- User talk:Gluo88上反對封禁的編輯意見可分為以下三種:
- 部分認為不限期封鎖過重,「不限期重於有限期」的觀點已被淘汰;
- 部分因用戶與我有衝突而表達不信任,是對人不對事的反應,而非對封鎖理據的異議。
- 還有少數用戶認為可以假定善意。即便善意編輯仍能構成擾亂(Wikipedia:毀損性編輯)。
- 經過溝通,解封管理員Bluedeck也認同這些行為違反方針,封禁並非不合理的舉措,只是他認為不至於需要封禁而已。 修改留言及違反CC-BY-SA兩事Gluo88屬於接受提醒後重犯。Gluo88未獲提醒的長期原創研究同樣可致封禁。單一未獲提醒的事項不足以獨立作為封禁理由,但此次是其他違規行為共同導致的封禁。Gluo88多項違規重複發生,或許是善意編輯但仍造成較大影響的擾亂行為。在提醒後依然繼續不當編輯,顯示出Gluo88缺乏遵照提醒的能力。 這些因素最終決定進行不限期封禁。--Mys_721tx(留言) 2024年6月14日 (五) 05:54 (UTC)
- 就兩位涉嫌擾亂討論言論、未認知自身言行錯誤一併回應:
- 一、首先令在下不忍卒讀就是一開始的「
誤判:這一點我不清楚
」閣下口口聲聲說在下發言充滿邏輯謬誤,卻連自己先前的言論「...Gluo88過往在討論中確實有該類行為,但後續「刪改討論擾亂秩序」的情況確實為苗君誤判
」都自相矛盾,如是表達有誤,還請精進表述能力,以免使他人誤會或看不懂閣下發言。至於我這裡所指的「誤判」是「與過往提醒不盡相同的違規行為一併認定」,過往是被回復了的留言的刪改,現在是尚未回復但已相隔一段時間,有可能已有用戶閱讀的情況,後述情況苗君單憑在你在發表留言後大幅刪改留言即可成立「剪貼討論構成擾亂討論串運作」
則是完全曲解TPG政策原則即不得在別人回復後修改自己留言,造成已回復留言被扭曲,而非不得更改留言(倒果為因)。相關方針詮釋完全屬於對此政策扭曲理解,超譯TPG政策(因別人可能看過進而刪改因此構成擾亂討論秩序更是原文中完全沒有內容),可合理認為相關言論符合遊戲維基規則中的故意謊稱某一觀點或立場受到方針的保護、管轄或支持,但是其實是違背方針的
以及試圖強行曲解方針,或者無視社群慣用標準,強行使用自己全新的解讀作為「適用標準」。
並且該君自稱引用去年十月份Peacearth提醒,然而封禁事由與提醒模版本意完全相違背。屬於明顯擾亂性封禁,可借閣下一言更何況善意的損害性編輯亦可構成擾亂
,仍然屬於擾亂性封禁。 - 二、
...從一開頭就假定惡意、訴諸動機、通過發訊息及提及拉人支持自己,這些從一開頭就不是假定善意的表現
在下經他人提醒後早已更改第一則留言,以免被人說訴諸動機或言語不妥。閣下借在下修改之前的言論說事,明顯是翻舊賬、訴諸惡意。至於質疑苗君能力,涉嫌濫用權限者之能力自然需要被質疑。請求第三方管理員評估、申訴均符合維基人權益受損疑慮時之合理行動,閣下以此指控本人,明顯違背AGF。 - 最讓在下感到震驚的是這句:
而詢問苗君封禁原因為何的語句更是有咄咄逼人甚至是挑釁的意味。
從多次被認為態度高傲、語句不當的Luciferian君說出來,堪稱千古奇談,令在下大跌眼鏡,如果不是某位英維管理員老生所談之「語氣監管」(Tone_policing),就是對用戶遭受明顯無理封禁發出之合理質詢的否定,侮辱封禁政策中:「執行封禁的管理員則可能按情況被要求查看及參與申訴討論,並提供更多信息。」
的原則。在下無必要受到涉嫌不當、充斥瑕疵、違反假定善意、曲解方針、遊戲維基規則,並嚴重缺乏正當溝通之封禁,仍要打不還手,罵不還口,在下不是聖人。閣下與其質疑在下語氣如何,更應該檢討當事管理員所作所為是否符合用戶期許。 - 三、
我不只是單純說「你也一樣」,而是「你這些簡直就不是假定善意」。更何況,管理員封禁的「善意認定」單從過往是否已獲提醒,後續是否持續再犯認定編者編輯非善意,更何況善意的損害性編輯亦可構成擾亂,苗君封禁時以「提醒後持續」認定需要封禁顯然已經符合以上要求。
:針對當事用戶涉嫌濫用權限之認定單從過往是否已獲提醒,後續是否再犯認定管理員用權非善意,更何況善意的擾亂性用權亦可構成擾亂。在下已明確提出所有封禁理據均有不當問題,獲得多位用戶認可,可合理認為Mys 721tx涉嫌構成擾亂性用權。LuciferianThomas君口口聲聲管理員如何如何,對管理員要求假定善意,對被封鎖之用戶就要翻舊賬、惡意推定、語氣監管、侮辱封鎖方針,可謂雙標典範。請停止持續雙標擾亂討論偏袒涉事管理員之行為。 - 四、
苗君的四項封禁理由中,有三項你都已經獲得明確的提醒(已經滿足教育用戶的要求),經提醒後仍然持續觸犯而認定無改善,需要以封禁阻止不當編輯持續,完全合乎程序
請停止選擇性失明,在下所列舉的Bluedeck君討論頁留言已明確指出教育用戶不嚴謹之問題(即根據閣下去年10月份在在下的留言,我可以視作善意提醒。但是這足以保證一位用戶認知到持續此一行為將導致封禁甚至不限期封禁麼?
),完全可以用更適當的方式指出相關用戶問題情況下,卻直接無預警不限期封鎖,明顯將封鎖視作警告、懲罰,曲解封禁政策本意。對此論點不再重複,裝睡的人永遠不會醒。只待社群討論及後續聯署議定。 - 五、「
除了對藍桌解封提出的交涉外,苗君在封禁時亦有列出清楚的diff
」有回應在下在內所有用戶的質疑嗎?有參與討論嗎?有對在下駁斥與質疑提供自己的解釋嗎?如果連這種程度問答都回答不上來,更證明當事管理員溝通能力不符合一般用戶(至少在下在內多名用戶)之期許。因此在下再次呼籲@Mys 721tx君請辭,以謝社群。光是你在提此案是的態度已經足以證明你是打算學WMLO那樣,不論苗的說辭如何、是否符合方針,都將強行闖關提出解任。
在下不評價前用戶行為,只能說目前的討論態勢均是尊重過往形成慣例(前次終止決定已屬不妥,不能作為反對本罷免的合理異議),要求社群討論並處理Mys 721tx君之行為,合乎常理。 - 六、七
苗君確實有為其說法提出證據,連diff都給了
:使用此類未經證實所謂「證據」顯然涉嫌羅織罪名、基於個人揣測的相關證據無正當效力權威(如CU、CA)直接認證,不足為評。如果閣下與Mys 721tx君是CU部門成員倒有幾分可信,如果只是普通社群群員,請問誰給你們的勇氣搜羅這些所謂的證據誹謗用戶,妄加揣測?如果這套基於臆測的偽證據可以成立使用,在下也完全可以搜羅LuciferianThomas同Mys 721tx頻繁交互的「證據」(這點很明顯,基本上所有用戶都知道),在站內大肆宣揚你們有特殊性「關係」,但顯然如果在下真的這麼做,早就被社群制裁。更別提作為管理員應成為社群用戶倫理規範之表率,而非造謠生事。至於「Lanwi1」反指控,在下已提過在其精神狀態嚴重受創並且當事人不道歉的前提下,我認為此類言行應可被諒解(先輕視他人者無權要求別人不輕視自己)。上述論據仍然是曲解一般人禮儀認知、持續對誹謗行為辯護,顯然擾亂整體討論。 - 最後是對我個人所謂「威脅」「攻擊」第三方管理員之嚴重指控。在下已聲告行政員前次決定已被多名用戶指出「官官相衛」「未得社群共識」「違反官僚體系」,再次宣告終止或無效,明顯將可能造成嚴重問題。提前告知行政員這一行為面臨的可能質詢,完全是為維護社群法治(維基百科不是官僚體系)的必要準備。作出此一聲告並非威脅,而是上次行政員本身決定就充滿爭議,甚至不具有正當性。在下也不認為探討行政員可能濫用權限的行為是所謂「威脅」「脅迫」(正如不會對一個用戶可能破壞頁面之警告屬於「威脅」),此指控明顯滑坡謬誤,魯莽指控在下行為不當,因此恕在下完全不接受上述明顯違反假定善意之荒謬指控。再次想起閣下這句
但他的錯處明顯多數存在被你放大扭曲的情況
,我想任何人都看出來LuciferianThomas君在整串討論中的行為幾乎都是對Mys 721tx就要不斷縮小標準寬恕假定善意,對在下卻雙標至極,嚴重誇大並扭曲本人言行,明顯擾亂整體秩序。 - 有鑑於LuciferianThomas君持續黑白不分、搬弄是非袒護涉事用戶、對在下施行雙重標準、滑坡謬誤、曲解言論、扭曲相關政策認識,一則留言更全篇紅色粗體,大喊大叫(使在下感到恐嚇騷擾(
請注意過多的文字特效會使別的用戶有被騷擾的感覺,亦讓人感到這些留言帶強烈的語氣,例如是斜體文字、粗體文字,以及英文中完全的大寫字母和過多的感嘆號,就像是「SHOUTING」...
),但在下仍要指出)、濫用RFDA方針顯然試圖阻撓本次正當彈劾議題,並對在下為維護社群法治言行作出魯莽指控,連續違反AGF、禮儀與文明,在下聲明拒絕參與有關LuciferianThomas的任何發言,公道自在社群,除非其針對其他編者繼續此類擾亂行為。在下最後勸解LuciferianThomas君一句,您這種情緒化且不可理喻的發言不會為Mys 721tx君提供任何正當性,反而讓社群用戶意識到某些人會為涉嫌袒護涉事管理員無所不用其極,導致其更有可能被解任。請閣下思之,並且,在Mys出事的時候,您屢次「代替」Mys 721tx君發表冗長言論回復質疑,讓只有有限時間和精力的用戶感到難以與Mys 721tx君直接討論,顯然影響社群其他用戶與Mys 721tx君的直接溝通。 請他自己作為參與站務十幾年的資深用戶獨自面對諸位同好質疑其權限使用問題。(在下對您進一步冗長討論及曲解政策發言,恕無時間回應,請社群看在下前面的論述, 多半已經駁斥或解釋)謝謝。- Ps:至於
社群如果接受這樣子的脅迫,那是否以後威脅其他管理人員提出除權就是王道?顯然不可能!
如果提案人必須受到這樣雙標壓力,那是否以後威脅遏制提案人並宣告終止RFDA就是王道?顯然不可能!
- Ps:至於
- 一、首先令在下不忍卒讀就是一開始的「
- --Gluo88(留言) 2024年6月14日 (五) 12:42 (UTC)
- 各位,我就這一話題作最後的發言。
- 首先是我於2024年2月騷擾某人的事件作最後澄清。我當時是創建條目後被人侵權提報,然後我無端指責提報人的行為,之後被苗管無限期封禁,2天後反省解封。我對此要說的是,整個程序雖無問題,但實際上是當時表達有誤。不過我後來發現這又涉及一個問題,因為涉及侵權提報所用的Template:Copyvio模板,英文版已經進行了大改版(可以按段落處理),而中維還是只能按全文處理,因此模板和程序都需要作進一步的優化(後續我會做討論,但由於模板涉及Twinkle技術問題,因此稿子還沒寫好)。再次向各位道歉。
- 有關苗管反駁我「他封禁用戶的次數,可能是中維之最」涉嫌誹謗的回應:我是根據當前的破壞作粗略統計的,亦參考了封禁日誌,因此說我「誹謗」不準確。
- 有關苗管反駁我所指出的對苗管有爭議封禁的回應:2號「違反嚴重原創研究」、3號是有理有據的,1號「因IP用戶破壞被半保護加入泄漏他人隱私站點鏈接」(僅一次)是「嚴重違反生者傳記」而被無限期封禁,顯然不當,我懷疑苗管當時可能以「零容忍」為由實施封禁。據生者傳記#封禁方針:
重複於在世人物條目添加無來源或來源不足之爭議資料的編者可能會因其擾亂行為而受到封禁
,而他只實施了一次。總結下來,苗管對用戶採取封禁,有些做法確實過於激進,我也再次強調不鼓勵採取激進手段。 - 回復@HYHJKJYUJYTTY:的發言:從苗管的兩次管理員申請記錄來看(1、2),一些人評價當時的他「參與反破壞」、「站務新力軍」、「對待新人的詢問很和藹」、「積極參與維護工作」、「熱心站務」等,很明顯他處理破壞案件很積極。人總有好壞兩面,雖然一些人批評他,但他也有好的一面,的確是反破壞的實力派。
- 我再來引用論述的一些話(溫馨提示:論述僅代表部分編者的觀點,並非社群共識):
- 《不限期不等於永久》裡面提到:
不限期封禁的常見原因包括純破壞、傀儡、發布垃圾內容,以及其他存在目的與維基百科的宗旨明顯相悖的人
,總結下來,純破壞、發布垃圾內容等與違反維基百科的宗旨的用戶都會被封禁,無需警告;傀儡則需要進一步調查。但「不限期封禁」並不能自動解封,而是「用戶需要花多久才能解決問題」。通常來說,這些人被封禁之後都不會花時間解決問題,因此論述提到不希望這些人回來,儘管某些人非常相信第二次機會(在合理範圍內),且某些人認為任何人都可以改變。
依我看,有爭議的封禁還是在於長期(資深)編輯上,但對被封用戶來說,最主要的還是通過積極行動才能解除封禁。 - 《任何對編輯的制裁不應是懲罰性的》裡面提到:
一些編輯,甚至一些維基百科的管理員,忘記了我們在這裡的初衷,開始在維基百科的運作中採用懲罰性模式……管理員應遵循預防性模式來採取行動,目的是遏制編輯的破壞性或有害行為,而不是試圖懲罰他們。
這也提到了管理員的建議:主題禁制、頁面保護、部分頁面封禁等,在某些情況下比不限期封禁或全站範圍禁制對項目更有幫助。
論述最後說的一句話是:管理行為需要承擔責任。
- 從前文的一句話再引述《管理員不是什麼》:
- 「不是開玩笑」一節:
重要的是要意識到您使用這些功能執行的任何操作都可能被其他管理員撤銷。管理操作應始終謹慎使用。
;封禁是管理員可以執行的最具爭議的行為之一,被認為是一件非常嚴重的事情。不當的封禁可能會導致您不受社群知名成員的歡迎,並且在這種情況下,您可能會遭到明顯的人身攻擊。在某些情況下,不良的封禁實施記錄可能會導致管理員被解職。
(後面的這段話很重要) - 「沒有方針的豁免權」一節:
每個管理員都必須牢記,管理員只是擁有協助維基百科維護的工具,僅此而已。這意味着,所有方針指引對管理員的適用性與對其他用戶的適用性完全相同——甚至更為顯著……管理員必須遵守所有維基百科方針(例如「回退不過三」原則),並像其他編輯者一樣堅持共識和中立觀點。
- 「不是權利」一節:
較高的編輯次數和對維基百科的奉獻精神通常體現出管理的可靠性和才能……重要的是要知道,管理員用戶權限是一套高級工具集,適用於在維基百科的方針和指引上表現出高水平的智慧、知識和專業性,並始終尊重維基百科五大支柱的用戶。他們在編輯條目時保持中立,並在需要修改時引用可靠來源。他們始終對與之互動的其他用戶保持文明—即使那些對他們不禮貌的用戶也是如此。他們帶頭幫助其他用戶找到正確的解決方案,並且他們在各個領域都擁有豐富的經驗,能夠充分了解維基百科的準則。此外,管理員權限並不意味着任何特殊權限……它不會賦予任何額外的地位、討論權重或特殊權限。
- 最後以「綜述」收尾:管理員沒有某些人想象的「指揮權」,他們通常對用戶有很好的見解和建議,他們應該善於獲得其他維基人的合作並與人合作。但他們永遠不會以商業意義上的「管理者」的身份來對待人們。
- 「不是開玩笑」一節:
- 《不限期不等於永久》裡面提到:
- 另悉:我在2021年基金會行動上看到User:瑞麗江的河水曾經是管理員,2019年被授予權限,2021年被基金會除權。請@瑞丽江的河水:發表一下看法。
- 最後我說幾句話:我是2012年2月22日加入維基媒體項目的,當時人在加拿大,一開始我用學校電腦以IP用戶的身份進行編輯維基百科(也因為當時不知道方針指引,違規曾被苗管暫時封禁),出於個人愛好便加入維基,當時我不到16歲(沒錯,苗管09年底加入維基也跟我差不多歲數)。連續服務12年,我貢獻的內容相當廣泛,共享資源上傳圖片相當多,而且這12年整個世界也是經歷了許多變化。特別是有人說「Mys 721tx很久以前不像現在這麼凶」,2017年後態度有了變化。自我2024年2月因違規被苗管無限期封禁,不到2天被解封後,我便開始關注其他用戶對苗管的看法,發現此人是激進派,暴露了一些問題,而後我了解了2021年基金會行動(當時因關注疫情不知道這事情)以及折毛事件,察覺到現在的社群環境已大不如前。於是我圍繞這次封禁,對中維的一些方針作修訂建議,封禁方針的修訂建議,尤其是為「不限期封禁」正名即是邁出第一步。本月我的工作以修訂方針、創建論述為主,整個工作將在WP:動員令開始前完成。在這裡我做最後總結:
- 遇到問題不要慌,要直面正視問題,不要迴避,要防止小問題變成大問題,防止問題矛盾化。
- 管理員不是權利,跟一般用戶一樣都是普通人。優秀的管理員應該是理性、公正、客觀,對一般用戶負責的,這樣才能得到社群的廣泛尊重。
- 再次跟各位說一句:沒有最好,只有更好!No best, only better!
- 以上。--Shwangtianyuan 不忘初心 牢記使命 2024年6月14日 (五) 16:11 (UTC)
- 各位,我就這一話題作最後的發言。
- 就兩位涉嫌擾亂討論言論、未認知自身言行錯誤一併回應:
- User talk:Gluo88上反對封禁的編輯意見可分為以下三種:
- 充滿邏輯謬誤的觀點不會站得住腳。
- 路君提到了「仲裁委」,現在看來還是有必要在中維設置該委員會處理爭論,作為爭論解決的「最終手段」。--Shwangtianyuan 不忘初心 牢記使命 2024年6月13日 (四) 15:04 (UTC)
- 我記得Mys 721tx很久以前不像現在這麼凶,Mys 721tx態度高壓、惡意斷定的問題從2017年時就明顯了,那個時候WMC在拉票(包括我四次參選CU員在內,參選時我確實不知道是拉票)以及Mys 721tx封過霧島聖。無論是濫權還是說我泄露CUWIKI數據都跟從跟WMC打交道後發狂有關,正義感過高以及積累壓力後就容易做出惡意推定等不當行為。
- 關於泄露CUWIKI數據,我現在的推斷是那個被除權的WMC成員(推薦我參選CU員的那個)、Mys 721tx(說我泄露?會使我更認為是Mys 721tx,我也記得包括我本人在內的其他時任CU員不像Mys 721tx這麼凶。)、利用CUWIKI漏洞的非CU員三者中的一個。
- 關於對我的負面影響,我想輕生的原因就是因為包括Mys 721tx在內的暴力用戶的攻擊。中維的暴力用戶的問題嚴重的原因就是貢獻至上主義,貢獻至上主義者認為有貢獻的維基人都該留在維基,尤其是貢獻更多的維基人,只要有這種不良氛圍存在,就會有縱容有大量貢獻的違反文明方針者這個問題。
- 關於我和WMC的關係,暴力用戶無法理解「世上沒有永遠的朋友,只有永遠的利益」這句話,我和WMC的相同點只有「對暴力用戶不滿」,WMC拉票的原因也包括對暴力用戶不滿,暴力用戶容易認為反對自己的都是WMC成員。
- 我不再活躍中維的原因就是中維社群沒有能力解決像Mys 721tx這樣的問題,我也不認同行政員在去年9月認定對Mys 721tx的第一次罷免案無效的決定,在罷免暴力管理員時提出修改罷免程序會容易使人認為提出修改者包庇暴力管理員。--Lanwi1Talk 2024年6月13日 (四) 20:58 (UTC)
- User:Lanwi1對CU-wiki數據泄露的指控僅基於個人推測,缺乏實質性證據。我對User:Lanwi1的懷疑建立於其交涉中的反覆(Wikipedia:互助客棧/其他/存檔/2017年10月#我認為必須確認清楚、Wikipedia talk:2021年基金會針對中文維基百科的行動#近期的基金會行動、Wikipedia talk:2021年基金會針對中文維基百科的行動#我覺得調查仍有不足)。我並不希望數據泄露為User:Lanwi1所做。然而User:Lanwi1在表示多年來收到指控的壓力的同時指責其他原用戶核查員。我能理解User:Lanwi1對被指控的壓力,但是這不代表User:Lanwi1可以以此解釋令人懷疑的行為。2021年User:lanwi1甚至有機會通過公布與User:守望者愛孟的郵件頭(僅包含發信人與收信人以及轉發郵件服務器信息)證明自己的清白,然而User:Lanwi1顧左右而言他。(Wikipedia_talk:2021年基金會針對中文維基百科的行動#我覺得調查仍有不足)多年來不但User:Lanwi1無法提出證據,還在此指控立場上與User:Kegns相同的我、被認定為被核查用戶對立面的我。我有什麼動機把數據泄漏給立場對立的用戶?無理由指責Kegns編造CU結論、泄露CU數據是過去WMC用戶誹謗行為(已刪除頁面存檔)為什麼User:Lanwi1在此無證據誹謗User:Alexander Misel與我?--Mys_721tx(留言) 2024年6月13日 (四) 23:34 (UTC)
- 一向認為當事管理員溝通手腕或有改善之餘地,處置亦可更為人性。但管理員作風本有不同實屬自然,不能強求所有管理員如此辦事。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月13日 (四) 20:33 (UTC)
- Mys 721tx老問題又犯,所以我認為沒有改善餘地,誰願意跟態度高壓的用戶協作?--Lanwi1Talk 2024年6月13日 (四) 22:02 (UTC)
- 說句不好聽的,態度高壓只能說明某些用戶實在不適合協作--百無一用是書生 (☎) 2024年6月14日 (五) 02:17 (UTC)
- 我還是要幫他說一句公道話,處理舉報破壞,他比較積極,但不否認態度確實要加強--HYHJKJYUJYTTY(留言) 2024年6月14日 (五) 03:25 (UTC)
- 同意。雖然我覺得一上來就不限期封禁可能可以商榷(不要說不限期不是永久,按這樣的看法除了nop外任何封禁都應該直接上不限期,建議上phab要求取消封禁限期功能,所有封禁等到申訴認識到問題再解封。我打編輯戰你封我1天難道1天過後我就自動不會編輯戰了嗎),但這畢竟是管理員自由裁量範圍,不好談什麼過當啊濫權啊什麼的。 ——魔琴[身份聲明 留言 貢獻 新手2023] 2024年6月15日 (六) 14:45 (UTC)
- @Shizhao君所稱「說句不好聽的,態度高壓只能說明某些用戶實在不適合協作」, 「只能」論顯然以偏概全, 顯然不當地排除了這種可能性:儘管某些用戶非常適合協作,但某些管理員的態度高壓行為卻使其不適合繼續擔任管理員職責(「管理員沒有任何高於其他用戶的特權,唯能實現社群討論所得的共識「)。在下也可以站在普通用戶的立場說,按您的方式只選一種可能性, 用戶不再協作只能說明管理員態度高壓。然而顯而易見,就拿本案來說,Mys 721tx的誹謗、涉嫌擾亂性用權已被多次質疑,如果將其定性為「只能說明某些用戶實在不適合協作」,仍然屬於檢討受害者。您所言這種話我感覺非常難聽,在下認為作為管理階層不宜說出這番話,否則這會讓用戶寒心管理層之無情。 管理階層對個別管理員態度高壓行為的態度非常重要,整理出有關論述如下:
- 態度高壓並不是合適的協作方式, 高壓態度只會加劇緊張氛圍,不利於建立積極的社區環境。
- 協作的關鍵在於理解、尊重和包容不同的觀點。即使某些用戶表現不佳,作為管理員,我們應該保持專業和耐心,而不是採取高壓態度。
- 管理員應該保持客觀、公正和理性,而不是簡單地採取高壓態度。公信力需要建立在合理和公正的行為基礎。
- 這是在下的淺見,不知道您怎麼看? 也希望和您進一步探討管理員是否應該態度高壓。
- 也不同意@魔琴君論述,管理員權限依託自社群賦予,方針明文規定不限期封禁僅限於嚴重擾亂,不構成嚴重擾亂的封禁必須考慮是否初犯、違規程度(並且必須事前溝通與否、詳細調查、是否確保用戶持續不當行為將被封禁等)。封禁固然是「自由裁量」不假(但顯然不是「權」,受到上述兩則條款的限制),也不會因為自由裁量所導致的問題裁決被合理化。拿Luciferian君自己的法律條款來說,現實中尚有對有理論上有「自由裁量」權的法官的徇私舞弊、濫用職權罪。按這個邏輯,所有封禁(包括無視相關條款限制)本質都是管理員的自由裁量範圍,所以不能商屬過當或濫權,因此不能追究?此陳述明顯有誤。
- @Shizhao君所稱「說句不好聽的,態度高壓只能說明某些用戶實在不適合協作」, 「只能」論顯然以偏概全, 顯然不當地排除了這種可能性:儘管某些用戶非常適合協作,但某些管理員的態度高壓行為卻使其不適合繼續擔任管理員職責(「管理員沒有任何高於其他用戶的特權,唯能實現社群討論所得的共識「)。在下也可以站在普通用戶的立場說,按您的方式只選一種可能性, 用戶不再協作只能說明管理員態度高壓。然而顯而易見,就拿本案來說,Mys 721tx的誹謗、涉嫌擾亂性用權已被多次質疑,如果將其定性為「只能說明某些用戶實在不適合協作」,仍然屬於檢討受害者。您所言這種話我感覺非常難聽,在下認為作為管理階層不宜說出這番話,否則這會讓用戶寒心管理層之無情。 管理階層對個別管理員態度高壓行為的態度非常重要,整理出有關論述如下:
- --Gluo88(留言) 2024年6月16日 (日) 12:14 (UTC)
- Mys 721tx老問題又犯,所以我認為沒有改善餘地,誰願意跟態度高壓的用戶協作?--Lanwi1Talk 2024年6月13日 (四) 22:02 (UTC)
- 我雖然解封了,但我可不認為Mys是作出了擾亂和誹謗的性質的事情。尤其是Mys在解封後提出了額外的證據,讓我意識到他的查封理由實際上比一開始所展現出來的要更充分。這些證據確實展現出編者存在的問題。目前我正在獨立的覆核這些證據。Bluedeck 2024年6月13日 (四) 23:58 (UTC)
- (+)支持,User:桐生ここ方案建立社群設定類似「請求封鎖」的機制,有好的規則,自然支持,能讓維基再更好,但解任我(=)中立,我只是針對User:桐生ここ方案建立社群設定類似「請求封鎖」的機制回答而已,可能有人會誤解--HYHJKJYUJYTTY(留言) 2024年6月14日 (五) 03:29 (UTC)
- 對於解任mys,表示(-)反對。在這個案件中,管理員的行為是:查封用戶 -> 在用戶討論張貼理由 -> 用戶反駁獲得我解封 -> Mys前來和我溝通 -> 在我的討論頁面提交更多證據。這是很正常的操作,沒有激烈的言辭,也沒有不合理的要求,其貼出的討論完全是就事論事,這個不叫做有態度問題。而且,說真的後來他提交的證據(見沙盒以及我的討論頁)在我看來使得查封的合理性有很大的增強。Bluedeck 2024年6月14日 (五) 05:42 (UTC)
- 明白理解閣下對於管理員用權行為標準的不同,並仍然感謝閣下指出當時理據中的封禁欠缺意見。在下會慎重根據您的審核結果,審查以往編輯,並承諾謹慎編輯,作出有益維基百科之事情。Mys 721tx君之相關用權態度問題,並非在下一人之見(一再重複,已被多名用戶質疑),如果閣下認為不至於罷免,在下會理解。但仍可受社群用戶意見檢驗諮詢。至於結果如何,應看RFDA總體共識形成結果。謝謝--Gluo88(留言) 2024年6月14日 (五) 13:02 (UTC)
- 有人能說明一下現在溝通是否有效?以及是否達成某種共識?--桐生ここ★[討論] 2024年6月16日 (日) 12:19 (UTC)
- 謝謝提醒。 48小時已過,在下認為目前沒有解決分歧,應屬溝通無效。稍後會開啟聯署,由聯署人按慣例審核確認。--Gluo88(留言) 2024年6月16日 (日) 15:24 (UTC)
- 我認為Gluo88的行為已構成擾亂了--百無一用是書生 (☎) 2024年6月17日 (一) 02:42 (UTC)
- 我覺得要勸U:Gluo88不要當第二個U:維基百科最忠誠的反對者(per U:Lemonaka)--Sinsyuan✍️🌏🚀 2024年6月17日 (一) 04:09 (UTC)
- 本次解任案與上次WMLO提出的解任案一樣都是通過扭曲的理由試圖強行推進解任程序。鑑於Lemonaka表示私下受到WMLO威脅(Special:Diff/83069105/83070035),可合理懷疑該提案可能已遭站外操縱,甚至可能形成站外拉票。鑑於Gluo88在多名管理員已指出該討論有問題時繼續強行推動解任,可見Gluo88並沒有就事論事的意願。請求其他管理員終止提案並予以處理。
- 我願意在未來接受仲裁委員會公開公正、按照事實的調查以查清該案中的指控。若仲裁委員會認定我的行為確實違規,我自然會承擔責任。若仲裁委員會認定我的行為沒有違規,我希望以此證明自己清白。--Mys_721tx(留言) 2024年6月17日 (一) 06:31 (UTC)
- 就WMLO繞過全域鎖定違規參加社群事務一事亦會提出用戶核查,以調查相關賬號。--Mys_721tx(留言) 2024年6月17日 (一) 06:35 (UTC)
參考資料
- ^ Wing Kwong Street in wikipedia-zh-autoconfirmed. Telegram. [2024-06-09].
- ^ Yishen Miao in wikipedia-zh-autoconfirmed. Telegram. [2024-06-09].
聯署區[編輯]
下面重複一遍解任理據:
- 濫用封禁:在在下參與路西法人的整理討論時,5月30日以多項罪名無預警不限期封禁多個頁面。四項封禁理據前兩項明顯不成立並曲解政策(比如曲解TPG政策認定本人調整未被回復的留言是「擾亂討論秩序」;其他用戶主張在下發言可假定善意,也不是扭曲政策,或不構成擾亂),後兩項理據則未經嚴謹調查或基於不實性質(兩則鏈接不構成查封事實,另外兩則欠缺事前討論,未確保用戶熟知自己問題可能會被封禁甚至無限期封禁。並以此永封明顯過激)。是次封禁被我在內五名普通用戶與一名以上的管理員質疑不妥。
- 遊戲社群承諾:涉事用戶在去年9月23日初次罷免被爭議的終止後,表示「感到有必要與社群進行更有效之溝通」。該用戶在本案經過兩次Ping兩次當面詢問通知後,除先前稱在下質詢是對方針的扭曲認識後,一貫冷處理在下及諸多用戶質疑,未見其試圖與社群用戶「達成所謂「更有效之溝通」」。其言行舉止與先前承諾出爾反爾,涉嫌遊戲承諾:
惡意協商——提出讓步以吸引其他編者達成妥協,但在對方妥協後拒不執行之前承諾的讓步。
。 - 誹謗用戶:去年罷免期間9月20日使用搜羅個人臆測鏈接(未經CA、CU證實),在公開群組與Quinniewong誹謗、侮辱前管理員Lanwi1(當時為彈劾動議支持人)泄露CU數據,為避免自身指控對Lanwi1訴諸人身,造成當事人精神痛苦加劇(個別用戶提到他「反指控」,我認為已輕視別人的人無權要求被傷害的人「尊重」自己)。此類公開群組發言,違反全域政策與基金會通用行為準則。並且經人指出後拒不道歉。
在此提請社群聯署移除涉事用戶Mys 721tx之管理員權限。——Gluo88
- 謹此(+)支持開啟本案,同時作為提案人發表一下個人看法:
- 在下及其他用戶認為當事管理員似乎是不斷輕微違規達到管理員擴權的結果:從最開始的Arikima(被認為違反避嫌)、到Shwangtianyuan君(被認為封禁過重)、再到在下被封禁(被認為未照顧用戶權益、過激、封禁理據明顯不妥),體現當事管理員試圖不斷使用封禁擴權,為無視對用戶事前必要的教育政策,優先確保討論的政策,進而放寬管理員用權的標準。
- 我們可以說,這種所謂的封禁在幾年是絕對無法被社群接受(從當年Arikima事件事前被警告後被無限期封禁,尚被多名用戶認為違反避嫌或封禁不妥,現在甚至不與用戶討論直接無限期封禁)該用戶面對用權質疑聲稱「不限期封禁比有限期封禁過重」的概念已被社群推翻,我認為這已是曲解封禁政策必須考慮用戶是否初犯及違規程度;不限期封禁則明確指出要構成嚴重擾亂,確保目前無改善可能才得以施行。按照這種邏輯,只要用戶違規隨時都可以予以不限期封禁,然後再觀察予以有條件解封,涉嫌扭曲方針認識、遊戲維基未曾被社群廣泛認可的規則。
- 很明顯,當事人至今仍認知不到自身行為問題(我認為已構成溝通無效,明確拒絕承認只要當事人不斷發言就不構成溝通無效的虛假論述,謹依往年慣例標準交由聯署人意定溝通無效傾向),同時上列拒絕與質疑用戶討論的行為與該君去年
感到有必要與社群進行更有效之溝通
的宣言自相矛盾,僅僅不到九個月便出爾反爾。請各位思之Mys 721tx的用權態度,是否有品格持續擔任這一被社群信任之權限。--Gluo88(留言) 2024年6月16日 (日) 15:36 (UTC)
- (+)支持:老問題又犯了,像這種遊戲規則的暴力管理員應該下台,誰願意跟像你這樣的態度高壓、刻薄的用戶協作?大量正面貢獻也不能掩蓋長年的老問題。--Lanwi1Talk 2024年6月16日 (日) 16:44 (UTC)
- 因解任程序有問題而划去,抱歉。--Lanwi1Talk 2024年6月17日 (一) 14:42 (UTC)
- 不過,我仍認為Mys 721tx有問題。--Lanwi1Talk 2024年6月17日 (一) 16:03 (UTC)
- 撤回劃票,我覺得不像受站外控制,站外控制是個魯莽的指控。--Lanwi1Talk 2024年6月19日 (三) 12:03 (UTC)
- (+)支持,恕我無法說服自己。不僅濫用封禁,在去年九月的罷免案拒絕溝通、至使罷免不當終結,加上之前提到的大量理由,實在令我難以接受;很希望各位能夠「人民的沈默、將是當權者的勝利之歌」這一道理。--Benho7599 | Talk 2024年6月19日 (三) 14:55 (UTC)
聯署中討論[編輯]
表態[編輯]
在此重複一下之前發言:
- 本次解任案與上次WMLO提出的解任案一樣都是通過扭曲的理由試圖強行推進解任程序。鑑於Lemonaka表示私下受到WMLO威脅(Special:Diff/83069105/83070035),可合理懷疑該提案可能已遭站外操縱,甚至可能形成站外拉票。鑑於Gluo88在多名管理員已指出該討論有問題時繼續強行推動解任,可見Gluo88並沒有就事論事的意願。請求其他管理員終止提案並予以處理。
- 我願意在未來接受仲裁委員會公開公正、按照事實的調查以查清該案中的指控。若仲裁委員會認定我的行為確實違規,我自然會承擔責任。若仲裁委員會認定我的行為沒有違規,我希望以此證明自己清白。
- 就WMLO繞過全域鎖定違規參加社群事務一事亦會提出用戶核查,以調查相關賬號。
-Mys_721tx(留言) 2024年6月17日 (一) 07:13 (UTC)
關於Mys 721tx君之表態[編輯]
本次解任案與上次WMLO提出的解任案一樣都是通過扭曲的理由試圖強行推進解任程序。
只有閣下和路西法人如此聲稱(扭曲的理由),並且您們並沒有回覆在下對您們「扭曲的理由試圖強行推進解任程序」的質疑。可合理認為無法答辯。看下方本人對您和路西的辯證反駁。反而可能是您們明顯通過對管理員情緒勒索、拉票、使用放大亮紅色字體騷擾、威脅在下。為終止本次彈劾,LuciferianThomas先前為此試圖凍結Rfda程序,直到仲裁委員會成立,已遭到大量否決,自覺撤回。鑑於Gluo88在多名管理員已指出該討論有問題時繼續強行推動解任,可見Gluo88並沒有就事論事的意願。請求其他管理員終止提案並予以處理。
我感覺作為被質詢者的您沒有回應反駁本人的這個留言和這個留言,好像不就事論事者,是您和路西法人吧?(還是說在下必須無條件接受您的意見,才不是「扭曲」?您是這個意思嗎?)如在下所言,Bluedeck君確實覺得閣下沒有到罷免的程度(雖然先前認為封禁理由查缺,我對此尊重),不過這屬於個人意見。基本上每次罷免議題都有用戶個人意見表態不支持彈劾,這很正常。- 關於全域鎖定的LTA通過電子郵件通知用戶,再進而「可合理懷疑該提案可能已遭站外操縱」首先在下得說這種指控非常嚴重,相當於暗指在下是真人傀儡。如果Kage等LTA隨便在這個時候送一個電子郵件「威脅」別人,閣下是否仍會以此為由逃避指控?在下認為這是不合理的。
- 同時,在下亦可以保證,未曾收到任何WMLO的郵件(如有必要可私下聯絡職員檢查)。如果閣下要提出用戶查核請自便,但請勿以此為由試圖躲過罷免。而且按正常人的邏輯認知,WMLO既然有如此策略想到「站外拉票」「操縱社群」,這時候更應該謹慎小心,而不是明目張胆地威脅某個用戶(而且看起來Lemonaka是中立的用戶),因為這樣反而會給閣下口舌。
- 換句話說,按在下的理解只要WMLO存在一天,就有可能操縱社群(仿佛托洛茨基帝國主義仍潛伏在社群周圍...感嘆),所以不能發起對管理員投票?我希望各位認真想想這個問題。
- 同時@Lemonaka我對閣下遭遇感到很遺憾,不知道您是否可以聯繫幾位第三方管理員或監管員,在不違反隱私政策的前提下轉述WMLO對您郵件內容是什麼(對您人身威脅,還是別的什麼?)如有意願,您也可以轉述聯繫相關部門(如信任與安全)處理此事件。在下也可以主動與監管員或用戶查核員看看此案是否有真人傀儡情形。
- 不知道各位用戶是否認可在下的意見。望提供建議。在下在此堅決(-)反對行政員或其他管理員如上次般,快速終止、中斷本次罷免的任何決定。為了一個明顯存在滑坡謬誤、不合理的原因,「抓住機會」地終止此罷免案,只會再給人「官官相衛」「凌駕討論」「無權裁決」的觀感,體現社群機制失能的嚴重擔憂。請各位管理員三思。
- 另外在下記得上次WMLO就是魯莽指控某站外群組有「拉票行為」而被指控騷擾鎖定的,Mys 721tx君僅僅因為一個被社群不信任的LTA的「威脅郵件」而斷定整個討論被「已被操縱」「站外拉票」「真人傀儡」,這種不當言論與WMLO當時擾亂社群又有什麼區別?在下為閣下未經深思脫口而出如此污衊在下人格的質疑感到非常遺憾。
- 實話說,在下面對您和另外某位用戶的壓力言論、在我回應後被指扭曲方針認識、又因特效字體騷擾(向管理員情緒勒索、拉票)威脅,在願意表態同@Shizhao探討「高壓問題」時隨後被指「構成擾亂了」,現又被指「真人傀儡」感到真的非常的疲憊。在下未曾想只是向社群提出對您權限使用的質疑會受到如此壓力重重的風波,在下早知如此當時寧願不發起了,甚至這幾日幾乎是在亢奮緊張的神經上度過的(有時失眠,我已打算休維基假期,如Asid閣下提出般)。在下至今仍然恐懼會不會因為因為對您提出罷免隨而被管理員封禁制裁,被「處理」。只是,在下自認問心無愧的。原諒在下可能未有更多時間回應您的問題。謝謝您,也祝您好運。恕在下之後不再過多參與此案。
--Gluo88(留言) 2024年6月17日 (一) 11:18 (UTC)
- Kenny023一些回退不合理的能不能也處理下?看人家討論頁就知道,人家專注於在回退上,有些回退合理,有些有問題。這個那(留言) 2024年6月17日 (一) 11:35 (UTC)
- @這個那君,如果你覺得Kenny023君有濫權的行為,請您提供相關事證至維基百科:申請解除權限做提報,但是同時我也要鄭重(*)提醒你,如果您只是為了提報而提報,如同您在其他不當行為#Kenny023的提報,那麼你可能會構成擾亂行為與遊戲維基百科規則的嫌疑,特此說明。--薏仁將🍀 2024年6月18日 (二) 00:00 (UTC)
其他[編輯]
- 註:聯署期自至2024年6月16日 (日) 15:36 (UTC)至2024年6月23日 (日) 15:36 (UTC)為止。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月18日 (二) 16:34 (UTC)
- 至於此次聯署是否無效,尚待非當事管理員判定。本人基本上反對解任案,不過若有機會讓聯署自然失敗,當事人自知意見較不受社群同意,或也是一種折衷解方。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月18日 (二) 17:22 (UTC)
- 所以說聯署過程能有效駁回不受社群支持的RFDA,路西法人君完全無需過度反應,也不需要限制RFDA流程,不需要推行仲裁委員會介入RFDA。--桐生ここ★[討論] 2024年6月18日 (二) 19:19 (UTC)
- 請搞清楚「聯署失敗」跟「解任案無效」的分別。從根基上都應該無效的解任案是連聯署都不應該發生(因程序上不符合解任條件,發起聯署已是不合規);聯署失敗僅代表無人認同,跟解任案無效的認定理據不合理並不相等。不符合方針的解任案發起而未因程序規定終止已是機制失效,這樣叫「有效駁回」顯然是偷換觀念。
- 過往社群表現也反映社群對於「聯署」的意味並不重視,有實際效力的「聯署」即代表聯署人為共同提案人,代表認同並共同推行提案人的所有論據,而不是僅僅的「支持發起解任」。若提案存在違反解任條件的情況,聯署人作為共同提案人顯然需共同負責。(此處「聯署」是指共簽或副簽議案,跟RFA稱「聯署」的公民提名為不同觀念,請勿混淆。)--路西法人 2024年6月19日 (三) 02:13 (UTC)
- 所以說聯署過程能有效駁回不受社群支持的RFDA,路西法人君完全無需過度反應,也不需要限制RFDA流程,不需要推行仲裁委員會介入RFDA。--桐生ここ★[討論] 2024年6月18日 (二) 19:19 (UTC)
- 至於此次聯署是否無效,尚待非當事管理員判定。本人基本上反對解任案,不過若有機會讓聯署自然失敗,當事人自知意見較不受社群同意,或也是一種折衷解方。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月18日 (二) 17:22 (UTC)
RFDA(及未來成立仲裁委員會後的解任程序)相關探討[編輯]
原標題為:動議:凍結社群解任管理人員程序直至仲裁委員會成立或按照當前新主流共識更改RFDA要求
- 下列討論已經關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
在與最新一期管理人員投票同步進行,有關「管理人員解任在多大程度由仲裁委員會處理?」匿名RFC中,獲得不少針對解任程序未來去向的意見,其中存在絕對多數用戶同意或不反對任一先行經過調查才能解任的方案,反映社群有非常強烈的初步共識認為解任管理人員前應先經過調查確認是否存在違規事實,由社群部分人的片面之詞(甚至是扭曲方針指引及事實的說辭)來發動解任顯然已經不再是主流觀點。
由此,我謹此動議,凍結社群解任管理人員程序,直至仲裁委員會成立或按照新的主流民意調整RFDA的基本立案要求,確保RFDA仍然符合社群的最新意見和初步共識。當然,「直至仲裁委員會成立」可能還要等比較久,凍結至完成調整RFDA立案要求至滿足新主流觀點為止。
補充說明:若是在仲裁委員會成立前調整RFDA立案條件,則是參考仲裁委員會機制下「先調查、確認違規事實存在,再開展除權程序」。雖然我可以想像由社群來調查很可能也仍然會被部分人通過扭曲事實擾亂調查,但起碼要比現在任意發起RFDA,不用顧不當行為事實是否成立要強。 --路西法人 2024年6月13日 (四) 15:04 (UTC)
- 看了一下Wikipedia_talk:仲裁委員會#管理人員解任和其中的問卷,我覺得這個方法是可行的,問卷當中也確實絕大多數人對此抱有期待,期待改變中文維基百科社群有處理的情況,也許在一些保持反對意見的人來看這不是什麼好事,但某種意義上是一種進步,社群試圖尋找出路。不過有一些要點還是要提醒下
- 1.仲裁委員會成員受到社群信任
- 受到信任的成員發出來的報告,報告的性質才不會被因"人"的原因產生變化,試著想想不受信任的仲裁委員會發布的報告,社群大多數人會接受與否。
- 2.仲裁委員會的意見及報告等社群要接受
- 這裡的接受不需要所有人都接受,只需要做到絕大多數人都接受,注意這不是忽略少數人的觀點,只是社群很難做到所有人都接受的事情,在很多事情上必然要做出取捨,如果所有人都要同意才能進行改變,長久下來對社群的發展是不好的。
- 3.仲裁委員會的在中維當中是處於什麼樣的位置
- 處於什麼位置很重要,沒有確立好,很容易產生爭執。
- ----
- 最後看完討論後我倒是有個建議,在"乙"的提案中加入一個前提,確保RFDA討論是無法有效進行,誰也不讓誰的情況再交由仲裁委員會,不需要一開始就交給仲裁委員會,如果社群能夠處理,那就不需要仲裁委員介入,一定程度上可以避免爭議,畢竟即便是仲裁委員發出的報告,也必然會有一部分的人不認同,如果全權都交給仲裁委員會,社群對仲裁委員會的不滿意度會越滾越大,最後反倒吵起來說要把仲裁委員會撤掉,這是我所擔心的,以上希望我的建議能為大家所考慮,謝謝。--~~Sid~~ 2024年6月13日 (四) 15:56 (UTC)
- 題外話,我建議社群可以的話,請為方針指引設立案例頁面,用很明確的方式告訴所有人什麼樣子的行為與內容違反方針指引是不能做的,指引可能會遇到的例外情況也建議一併列舉。--~~Sid~~ 2024年6月13日 (四) 16:28 (UTC)
- 此外RFDA我認同可以凍結,但如同上方意見,有些事情或許應該多加考量。--~~Sid~~ 2024年6月13日 (四) 16:36 (UTC)
- 注意我認同可以凍結,並不是代表一定要凍結,可以的話我仍建議可以討論一下,當然我希望是有效的討論,而不是大家又吵成一團 ( ~~Sid~~ 2024年6月13日 (四) 16:59 (UTC)
- 我不認同凍結,RFA和RFDA是維基百科的根基,仲裁委員會是尚未驗證的後來之物。至於上方RFDA請求是否成立,訴諸共識或大多數人的共識即可。--桐生ここ★[討論] 2024年6月13日 (四) 18:16 (UTC)
- 管理人員解任在多大程度由仲裁委員會處理?
- 甲、仲裁委員會按調查事實及方針指引,直接作出除權決定。
- 乙、由仲裁委員會調查事實並發佈管理人員操守報告,確認存在違規事實後,才轉交社群決議除權。
- 丙、仲裁委員會完全不參與管理人員解任。
- 管理人員解任在多大程度由仲裁委員會處理?
- 問卷問題不當,並沒有說明是所有RFDA按上方甲乙丙處理,還是只有爭議無法在社群解決然後送到仲裁委員會的RFDA案件,按上方甲乙丙處理。--桐生ここ★[討論] 2024年6月13日 (四) 18:24 (UTC)
- 當初問卷內容實際上沒有經過社群共識決定(貼出草稿而已,沒有正式公示通過),所以問題很多。當初我早就提出質疑,也未獲澄清,就莫名其妙拿去安全投票了。還好問卷祇是諮詢性質,沒有產生什麼約束結果。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月13日 (四) 20:24 (UTC)
- (-)反對凍結程序:現有之管理人員解任程序本來就是經共識產生;前述問卷祇是就仲裁委員會之角色提出諮詢,沒有如何連帶處理社群既有程序的要求,故本來與此無涉,至少不應該過度延伸。再說,最近幾次案例也顯示,原來沒有共識基礎的解任投票提案,都根本不會通過,甚至一大部分提早就宣布無效,正是彰顯社群尚未失能,現行程序運作無礙。另外,現有方針很明確定義管理人員解任條件及必要程序,早也就是所謂「確認違規事實存在(內容不符或原因不合理,可視作申請無效),再開展除權程序」之流程,差別只是在仲裁委員會作為實體機制,調查結果大概可以比較明確,而現有程序中,社群之「確認」較為隱性,反映在支持連署及討論過程中。現有程序並沒有任何常規替代方案(不計緊急解任),或可說共識陳舊而需要修訂,然在有具體解方前,顯然不應該剝奪社群對管理人員人事的最後決定權。該問卷祇是再一次確認社群長年以來認為有相當理據才能解任管理人員(這也應該是常識),並認同社群擁有最後決定權(而非由仲裁委員會逕行決定)的固有認知(不是所謂「新主流共識」);社群合資格者(以後的仲裁委員會當然也在內)都能提出解任,但祇有社群後續判斷理據確實者,纔有機會獲得足夠支持,這是兼顧維基人發言權利及社群意志實踐的作法,自然符合社群共識。此提案屬於憑空製造問題。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月13日 (四) 20:05 (UTC)
- 你的主張是
現有方針很明確定義管理人員解任條件及必要程序,早也就是所謂「確認違規事實存在(內容不符或原因不合理,可視作申請無效),再開展除權程序」之流程
,然而跟你自己的主張相牴觸的是,你身為此解任案的第三方管理員,在該用戶明顯威脅、脅迫其他第三方管理員等不文明行為、連其主張的濫用封鎖權限都已經被解封管理員的說法打臉(封鎖理由成立只是解封管理員認為不需封鎖),更公然聲明將不會討論違規事實成立與否、僅由聯署人自行認定溝通無效,完全跟你口中的「必要程序」相牴觸的時候,卻完全不予阻止袖手旁觀,這不就反映社群阻攔不文明、濫提解任的失能完全成立?過往非當時管理員依照方針賦予的權力提前結束解任案還受質疑,豈不是完全反映社群決策能力已完全失能,而僅有少數正常的管理人員維護方針?--路西法人 2024年6月13日 (四) 22:17 (UTC)
- 你的主張是
- 一併回覆Ericliu1912及桐生ここ:……(討論已移動至下方)--路西法人 2024年6月13日 (四) 22:36 (UTC)
- (-)強烈反對:
- 仲裁委員會機制尚未驗證,其實際效果和操作過程尚不明確。為了一個尚未驗證的機制,而凍結現行的有效程序(顯然不會因行政員爭議性的終止等同無效),無異於捨本逐末。關於仲裁委員會在管理人員解任中的角色,在下同@桐生ここ:目前的問卷問題存在明顯的不足。問卷沒有明確說明是所有RFDA按上述甲、乙、丙方案處理,還是僅有爭議無法在社群解決的RFDA案件按上述方案處理。此種不明確性導致問卷結果不能充分反映社群的真實意見。
- 考慮到仲裁委員會的設立、仲裁員選舉、立案時長分析、條文討論等過程顯而易見地非常冗長,凍結現行程序更有阻撓現行政策正常運作,即時處理當事管理員問題之嫌。應按照現行規則即時的處理管理員問題,確保社群的正常運作,不受爭議管理員可能之危害。
- 最後,在下堅決反對行政員可能在任意時間決定凍結RFDA程序的行動。此種爭議做法在前次已經引發「官官相衛」「未得社群共識」「違反官僚體系」等嚴重質疑,損害社群討論之原則。甚至換句話說,如果仲裁委員會一日不建立,便一日不能追究、及時處理管理員之問題,顯然干擾社群監察程序。綜上,在下反對凍結。並建議直接滾雪球關閉此討論。--Gluo88(留言) 2024年6月13日 (四) 20:18 (UTC)
- @LuciferianThomas:還請動議人在此處說明一下仲裁委員會相關事宜的進度。假如進度推進得足夠快的話,凍結程序並不一定必要。Sanmosa Snipe–Clam Grapple 2024年6月13日 (四) 23:13 (UTC)
- 目前尚餘總結解任相關觀點,並設計出符合儘量多人意願的解任相關機制後,就能寫整個方針,經過社群公投endorse後上路。
- 就算進度推進得夠快,也無法阻擋當前Gluo88公然發表違反解任程序要求的提案,在修訂社群解任途徑確保程序公義前或仲委會機制上路前,仍應凍結當前程序。--路西法人 2024年6月13日 (四) 23:31 (UTC)
- (!)意見-將這兩件事情連結起來成為條件,恐怕有疑慮,是否要開這樣的先例?恐怕會帶來些副作用與後遺症。會否讓既有方針被凍結了?過去,沒有仲裁委員會,相關的程序與方針仍然持續進行,就是依照既有方針在做。Wetrace歡迎參與WP人權專題 2024年6月14日 (五) 00:21 (UTC)
- 實際上早有先例。過往就是本地用戶查核權出了問題,使基金會凍結本地用戶查核權。另外,請注意提案中除了「凍結到有仲裁委員會成立」外,還有「或(凍結至)按照調查得出大家的主流觀點」(或如某些人否定調查得出的多數意見,也需確保程序公義得到彰顯)的選項。--路西法人 2024年6月14日 (五) 02:09 (UTC)
- (!)意見-將這兩件事情連結起來成為條件,恐怕有疑慮,是否要開這樣的先例?恐怕會帶來些副作用與後遺症。會否讓既有方針被凍結了?過去,沒有仲裁委員會,相關的程序與方針仍然持續進行,就是依照既有方針在做。Wetrace歡迎參與WP人權專題 2024年6月14日 (五) 00:21 (UTC)
- 社群提出與仲裁委員會調查管道實際上仍應並行,這裡討論的祇有前者。因為很顯然,仲裁委員會祇能處理於該處提出告訴的案件,不能為整個社群越俎代庖。但我有點擔心,新提案在加入仲裁委員會角色同時,還打算一併消滅社群自行提出管道。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月14日 (五) 00:33 (UTC)
- 我跟ATB正在共同籌備有關未來解任制度走向的提案……(討論已移動至下方)……--路西法人 2024年6月14日 (五) 01:16 (UTC)
- 是否無論如何一定要先經過仲裁委員會「確認」?本人認為社群自身仍有逕行運作程序的能力,不用全部經過仲裁委員會審查,祇有拒絕受理才能被動提案。當然,若要避免所謂「民粹政治」,可以提高標準。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月14日 (五) 03:31 (UTC)
- 或許我說的不清晰:我在ATB方案上增添的走綫是給「社群提交給仲裁委員會」新增了前設,故產生「社群無人提請仲裁(而社群自行解決解任問題)」的走線。若社群自行走解任程序時理據出了問題,自然會有人提交給仲裁委員會;若真的幾乎沒有爭議的,那社群自己走完整個程序都不會需要仲裁委員會插手。如果有人提交,仲裁委員會又認定社群本身在該案已能自行處理(發起除權無明顯問題需要仲裁委員會插手),即可拒絕社群請求。不經仲委會提出除權的條件也不需要怎麽提高,還是滿足最基本的程序公義即可。--路西法人 2024年6月14日 (五) 03:42 (UTC)
- 本人認為,現行情況實際上就是這樣,也就是社群多數時候能夠有效拒絕理由不完備的提案正式投票。那或許是對「事前」部分疑慮較多?也就是欲阻止伊始即直接上客棧「大亂鬥」的醜陋局面。不如拿上面剛剛提出的解任案問問,你覺得該案提請有什麼可能不滿足程序正義之處,畢竟有實際案例較好切磋。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月14日 (五) 03:54 (UTC)
- 另外抱歉剛剛太認真看右邊那張圖,沒仔細注意您有提出「比圖片多一條」的走線Orz —— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月14日 (五) 03:58 (UTC)
- 或許我說的不清晰:我在ATB方案上增添的走綫是給「社群提交給仲裁委員會」新增了前設,故產生「社群無人提請仲裁(而社群自行解決解任問題)」的走線。若社群自行走解任程序時理據出了問題,自然會有人提交給仲裁委員會;若真的幾乎沒有爭議的,那社群自己走完整個程序都不會需要仲裁委員會插手。如果有人提交,仲裁委員會又認定社群本身在該案已能自行處理(發起除權無明顯問題需要仲裁委員會插手),即可拒絕社群請求。不經仲委會提出除權的條件也不需要怎麽提高,還是滿足最基本的程序公義即可。--路西法人 2024年6月14日 (五) 03:42 (UTC)
- 是否無論如何一定要先經過仲裁委員會「確認」?本人認為社群自身仍有逕行運作程序的能力,不用全部經過仲裁委員會審查,祇有拒絕受理才能被動提案。當然,若要避免所謂「民粹政治」,可以提高標準。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月14日 (五) 03:31 (UTC)
- (-)反對。認為應該在選出仲裁委員會成員,完善相關方針之後再議,RFDA畢竟不是RFA,凍結不會帶來什麼好處,反而會帶來麻煩,比如當前這項解任案,我不會對其進行任何評價,如果直接將之凍結,可能會使相關用戶作出其他極端行為。如果其解任違反相關方針,可以直接由行政員決定關閉,而非凍結之。--在下荷花,請多指教(歡迎簽到) 2024年6月14日 (五) 02:20 (UTC)
- 注意,解任方針是規定任何非當事管理員已可決定關閉,並無限制只能是行政員。另,我理解您反對凍結,若管理人員能及時阻止本次明顯有可能要違規闖關的提案,而有關用戶持續扭曲管理員言行的行為獲確切的阻止,那我將不會繼續追求凍結解任。能否請您就上方我和ATB(未在此留言,但右方流程圖是他製作的)提出的解任走向有何意見?若我在仲裁委員會成立前參照該走向修改解任方針(就是把仲裁委員會替換成社群整體調查,走先調查後解任的流程,確保未來不能再有同類事情發生,你又是否同意?--路西法人 2024年6月14日 (五) 02:30 (UTC)
- (-)反對,我覺得先等仲裁委員會成立,且已確定相關的流程及規則,再來調整RFDA的作法。不太適合此時凍結解任管理人員的程序。--Wolfch (留言) 2024年6月14日 (五) 02:37 (UTC)
- (-)反對,目前沒有數據是否有效,更且仲裁委員會還沒成立,成立後,必須先觀察,不需馬上處理凍結解任管理人員的程序--HYHJKJYUJYTTY(留言) 2024年6月14日 (五) 03:43 (UTC)
- (-)傾向反對:正如Gluo88君所說,「仲裁委員會的設立、仲裁員選舉、立案時長分析、條文討論等過程顯而易見地非常冗長」,而這段時間內仍有RFDA的需求。如果現在凍結RFDA,恐怕會導致這些需求難以得到滿足。--CuSO4 · 龍年大吉 2024年6月14日 (五) 03:48 (UTC)
- 本討論已關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。
當前解任案效力[編輯]
一併回覆Ericliu1912及桐生ここ: 雖然題目是針對仲裁委員會,但有關留言中的論據卻很多是廣泛對社群現象的描述,「社群失能」、「需要評估事實」、「先調查後除權」等顯然是廣泛的觀念。該問卷無法直接影響此動議,但有一定參考價值;所謂「仲裁委員會只處理社群無法解決才送到仲裁委員會的RFDA案件」也幾乎是沒考慮到「毫無疑問需要除權的操作大概都是走緊急除權」,管理人員解任投票也甚少有不會引起爭議,基本上到最後90%的都還得送到仲裁委員會解決(尤其是雙方不認可對方的論證的情況),近年每次除權爭議更是暴露了社群無法管控用戶不捏造事實、不扭曲方針、不無視解任程序的弱點,完全佐證了當前解任程序需要更明確要求調查確認有違規事實再發起除權程序。所謂「比較隱性的確認」反而是「完全沒有在發起前就明確確認」的意思,所謂的「確認」通過「聯署及討論過程」,但顯然發起解任程序的用戶沒有也不會考量討論內容,而是徑自聯署就打算闖關,聯署也無法發表實際的反對意見,簡而言之就是「七名無公信力用戶自行認定有罪」就開展解任,並不存在真實的「確認」違規事實,這也是近期情況和你的聲稱所互相矛盾的。
另外,看到兩位的反對都是針對仲裁委員會,然而我自己也在動議中表明更理想的情況不是「等仲裁委員會決定」,而是當前就直接明確RFDA的要求。還是那句,雖然題目針對仲裁委員會,但意見的變化是顯而易見的,我也沒有打算要把那個調查當作「已經存在的共識」來說話而是「參考其意見而發起新的動議」,請搞清楚此提案的意義。--路西法人 2024年6月13日 (四) 22:36 (UTC)
- 那可以繼續討論。由於本人支持未來社群提案與仲裁委員會調查兩管道繼續並行,自然也有檢視前者並加以調整之必要。本人也並未否認近年來見得諸多不成熟之解任提案,徒然浪費社群資源。此處只是要指出,不應該因為若干使用者可能脫序或濫用之行為,就要求直接「凍結」社群的民主權利,現在又不是什麼非常時期。「提出解任」本身也是程序不可忽略的一部分,無論內容有多麼不合理,至少也要先「存在」才能予以駁斥(更何況其實指引已經明確指出,提案伊始即「內容必須詳細,指出管理濫權的原因,並根據編輯記錄及使用者貢獻提出相關證據」,理論上不滿足即自始無效);即使往後要組織某種詳細「調查」,也是要先有人「提出」或「申請」管理人員可能的濫權行為,不可能憑空造成。所以本人並不理解過度誇大此一階段亂象的用意。另外,若既已為滿足前述有效條件之提出,則此後之辯論,維基人間存在觀點差異亦實屬正常;雖不排除確實有「無腦支持」者(實際上任何站務程序都有),但逕行認定聯署是「無公信力用戶自行認定有罪就開展解任」,則恐怕有歧視若干社群參與者及菁英主義思維作祟之嫌。照這種說法,所有人可能都是「無公信力用戶」,管理員解任申請不就變成「無公信力用戶法庭」。不過如此一來倒是大概可以理解,為什麼那麼堅持要走以仲裁委員會逕行裁決這種路線。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月14日 (五) 00:07 (UTC)
- 一般用戶不經任何選舉,公信力是undefined(這種「沒有公信力」)。仲裁委員整體有一定公信力。
- 另,雖解任案未正式發起,管理員未能按解任方針取締,但他能預告將會作出違反程序的行為,管理人員也可明確告知違反程序的提案將會被截停,並呼籲其遵守程序,在已知會發生的問題發生前直接堵截,而不是等到問題發生才做事。--路西法人 2024年6月14日 (五) 01:29 (UTC)
- 若方針持續遭到濫用、扭曲,且情況非常明顯,如果放任不管也會造成明顯大的傷害(如除權方針),那麼自然就該凍結程序,這好比現實中正在提出釋憲的法案可被臨時暫停執行;正如如果未來社群選出的仲裁委員會go rogue,放任不管也會造成明顯的傷害,那麼自然就該凍結程序。--路西法人 2024年6月14日 (五) 02:18 (UTC)
- 本人不認為凍結整個程序符合比例原則。所謂「持續」,也不必然。況且就該案而言,當事管理員作風問題乃長久以來眾所皆知,也引起諸多爭議。提請解任本身或許過當,但其來有自,當中所隱含的問題並非全然無探討之可能。我們管理員是有權力的一方,本來就應該賦予對造相對多話語權,易言之即容許較大限度之發言自由,這本來也是他們唯一可以「制衡」管理員行使職權的辦法。本人不認為該案之提出者在「濫用」解任程序,至少也不應該是擴大到其他個別案件的理由。另外,現行解任程序少數的大問題,就是雖然指出要「溝通無效」,但很多時候當事管理員堅持立場,就很容易構成,然後就是客棧提案一片混亂。本人認為就條文相關部分討論如何清晰定義(尤其是什麼樣的內容理由為「有效」),且「同時」兼顧當事管理員及提請人權益,要比凍結整個程序實際多了。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月14日 (五) 03:38 (UTC)
- 以上討論分拆自上方討論。--路西法人 2024年6月14日 (五) 04:02 (UTC)
- Gluo88以威脅的語氣試圖阻攔其他管理員正常行使方針的語氣,並在其本身對管理員行為的扭曲理解下營造管理員濫權的不實情形,並可以從其語調看得出不會接受任何解釋。反觀苗君仍在積極解釋、回應或回駁觀點,也通過討論、交涉獲得解封Gluo88的藍桌君出來說話,表明不認同Gluo88對苗君的指控。這些反映苗君確實有在積極溝通(回駁觀點也是溝通的一種)。反而是Gluo88的態度表明拒絕接受一切解釋,自己拒絕溝通並持續扭曲事實,自行製造溝通無效的條件,這顯然不是解任方針的本意。--路西法人 2024年6月14日 (五) 04:02 (UTC)
- 我剛剛才發現,解任投票根本還沒正式提出,那就更不用為此談相關程序問題了吧?該話題現在已經變成實質溝通之處。唯一認同者,即在此情況下,當事人不宜逕行提出解任。若未能如願,而屆時社群能有效應對,那亦可再度證明解任程序運作有效。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月14日 (五) 04:20 (UTC)
- 否,我上面有指出:
雖解任案未正式發起,管理員未能按解任方針取締,但他能預告將會作出違反程序的行為,管理人員也可明確告知違反程序的提案將會被截停,並呼籲其遵守程序,在已知會發生的問題發生前直接堵截,而不是等到問題發生才做事
。--路西法人 2024年6月14日 (五) 04:29 (UTC)- 我不太理解,難道質疑管理員亦不可?他雖如此「威脅」,但未付諸實行之前,無論如何實不可以「現行犯」論之。若社群多人持續表達關切意見,他也並非不可能拒絕「聽勸」。此外,這畢竟也與解任投票本身沒有直接關聯(因為解任投票尚未啟動,不構成程序問題)。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月14日 (五) 06:10 (UTC)
- 不是不能質疑,而是不能以扭曲方針的理解來質疑管理員,連給Gluo88解封的管理員都認為苗不存在擾亂或誹謗,而他自行判讀管理員解封就代表對其的封鎖是誹謗、是濫權,這不就反映觀念上就有問題,問題並非出自於被發起除權的一方?Gluo不斷合理化自己的行為,而苗、我甚至是藍桌都一再指出Gluo88先前行為並非妥當(只是藍桌認為不至封鎖),這不叫質疑,而是扭曲方針及事件事實而誹謗管理員吧。--路西法人 2024年6月14日 (五) 09:38 (UTC)
- 他可以提出質疑,社群則可以適當支持或反駁之,這是共識形成的正常過程。在此案中,大概認為理由不充分者居多,是否成案尚有商榷餘地。本人也不好評價個別管理員作風「惹人怨」的程度,但明顯可見並非孤例,故此處比起「帶有情緒而衝動質疑」之類形容,「誹謗」一詞或需要慎用。當然也可能是我對此類批評管理權限行使問題態度向來比較「寬容」。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月14日 (五) 13:05 (UTC)
- 上方解任案成功且合規立案的可能性之低,我已無意願再參與討論。不論是原則上還是方針條文上,都沒有條文能支持他做的事,如果他還是正式發起解任案,我再請求其他管理人員制裁有關行為即是。--路西法人 2024年6月15日 (六) 00:59 (UTC)
- 「以扭曲方針的理解」的操作空間過大,並非一個適合的判定標準,不然大家互相指控其他人的理解「扭曲方針」還得了。Sanmosa Snipe–Clam Grapple 2024年6月15日 (六) 00:58 (UTC)
- 每個方針都有背後的大原則,如果是對方針條文理解有誤的人,都難以推翻背後的大原則。明知自己對方針條文理解與方針背後原則和用意衝突的情況仍繼續堅持的,那就只能是扭曲方針了。--路西法人 2024年6月15日 (六) 01:02 (UTC)
- 我的意思是,真到了我説的那個情況,那個人是否真的「扭曲方針」還重要嗎?我最擔憂的事情是大家互相指控其他人的理解「扭曲方針」的時候,大家的指控實際上都是成立的,因為根本沒有人(在任何意義上)「正確理解方針」。Sanmosa Snipe–Clam Grapple 2024年6月15日 (六) 07:53 (UTC)
- 同意。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月15日 (六) 18:02 (UTC)
- 我的意思是,真到了我説的那個情況,那個人是否真的「扭曲方針」還重要嗎?我最擔憂的事情是大家互相指控其他人的理解「扭曲方針」的時候,大家的指控實際上都是成立的,因為根本沒有人(在任何意義上)「正確理解方針」。Sanmosa Snipe–Clam Grapple 2024年6月15日 (六) 07:53 (UTC)
- 每個方針都有背後的大原則,如果是對方針條文理解有誤的人,都難以推翻背後的大原則。明知自己對方針條文理解與方針背後原則和用意衝突的情況仍繼續堅持的,那就只能是扭曲方針了。--路西法人 2024年6月15日 (六) 01:02 (UTC)
- 他可以提出質疑,社群則可以適當支持或反駁之,這是共識形成的正常過程。在此案中,大概認為理由不充分者居多,是否成案尚有商榷餘地。本人也不好評價個別管理員作風「惹人怨」的程度,但明顯可見並非孤例,故此處比起「帶有情緒而衝動質疑」之類形容,「誹謗」一詞或需要慎用。當然也可能是我對此類批評管理權限行使問題態度向來比較「寬容」。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月14日 (五) 13:05 (UTC)
- 不是不能質疑,而是不能以扭曲方針的理解來質疑管理員,連給Gluo88解封的管理員都認為苗不存在擾亂或誹謗,而他自行判讀管理員解封就代表對其的封鎖是誹謗、是濫權,這不就反映觀念上就有問題,問題並非出自於被發起除權的一方?Gluo不斷合理化自己的行為,而苗、我甚至是藍桌都一再指出Gluo88先前行為並非妥當(只是藍桌認為不至封鎖),這不叫質疑,而是扭曲方針及事件事實而誹謗管理員吧。--路西法人 2024年6月14日 (五) 09:38 (UTC)
- 我不太理解,難道質疑管理員亦不可?他雖如此「威脅」,但未付諸實行之前,無論如何實不可以「現行犯」論之。若社群多人持續表達關切意見,他也並非不可能拒絕「聽勸」。此外,這畢竟也與解任投票本身沒有直接關聯(因為解任投票尚未啟動,不構成程序問題)。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月14日 (五) 06:10 (UTC)
- 否,我上面有指出:
- 我剛剛才發現,解任投票根本還沒正式提出,那就更不用為此談相關程序問題了吧?該話題現在已經變成實質溝通之處。唯一認同者,即在此情況下,當事人不宜逕行提出解任。若未能如願,而屆時社群能有效應對,那亦可再度證明解任程序運作有效。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月14日 (五) 04:20 (UTC)
- 本人不認為凍結整個程序符合比例原則。所謂「持續」,也不必然。況且就該案而言,當事管理員作風問題乃長久以來眾所皆知,也引起諸多爭議。提請解任本身或許過當,但其來有自,當中所隱含的問題並非全然無探討之可能。我們管理員是有權力的一方,本來就應該賦予對造相對多話語權,易言之即容許較大限度之發言自由,這本來也是他們唯一可以「制衡」管理員行使職權的辦法。本人不認為該案之提出者在「濫用」解任程序,至少也不應該是擴大到其他個別案件的理由。另外,現行解任程序少數的大問題,就是雖然指出要「溝通無效」,但很多時候當事管理員堅持立場,就很容易構成,然後就是客棧提案一片混亂。本人認為就條文相關部分討論如何清晰定義(尤其是什麼樣的內容理由為「有效」),且「同時」兼顧當事管理員及提請人權益,要比凍結整個程序實際多了。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月14日 (五) 03:38 (UTC)
仲裁體系下的解任機制[編輯]
我跟ATB正在共同籌備有關未來解任制度走向的提案,當中不會完全汰除社群自行發動解任的途徑,只是會有一定改動確保程序公義。右圖是ATB建議的走向,而我的想法是再向上加一條走線:社群發起解任後,用戶只能在投票發起前才能提交證據請求由仲裁處理,仲裁委員會在七日內需決定是否受理(條件:初步認為解任提案理由有問題)並展開詳細調查。由於解任走SecurePoll似已通過,準備SecurePoll也需要時間,多等七天不會有什麼大問題。拒絕受理或投票發起後不能由仲裁截停(已放棄受理權);因拉票等因素而截停則不是RFDA仲裁機制了,而是一般用戶行為仲裁。這樣能確保仲裁不會被過度使用之餘確保未來解任程序能達到程序公義。補充:若社群提交給仲委會的理由跟發起除權的理由太不同,則自然不能視作仲裁委員會已放棄調查權,為防被濫用規則而挾帶不當理由闖關。--路西法人 2024年6月14日 (五) 01:16 (UTC)
- 是否無論如何一定要先經過仲裁委員會「確認」?本人認為社群自身仍有逕行運作程序的能力,不用全部經過仲裁委員會審查,祇有拒絕受理才能被動提案。當然,若要避免所謂「民粹政治」,可以提高標準。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月14日 (五) 03:31 (UTC)
- 或許我說的不清晰:我在ATB方案上增添的走綫是給「社群提交給仲裁委員會」新增了前設,故產生「社群無人提請仲裁(而社群自行解決解任問題)」的走線。若社群自行走解任程序時理據出了問題,自然會有人提交給仲裁委員會;若真的幾乎沒有爭議的,那社群自己走完整個程序都不會需要仲裁委員會插手。如果有人提交,仲裁委員會又認定社群本身在該案已能自行處理(發起除權無明顯問題需要仲裁委員會插手),即可拒絕社群請求。不經仲委會提出除權的條件也不需要怎麽提高,還是滿足最基本的程序公義即可。--路西法人 2024年6月14日 (五) 03:42 (UTC)
- 本人認為,現行情況實際上就是這樣,那或許是對「事前」部分疑慮較多?也就是欲阻止直接上客棧「大亂鬥」的醜陋局面。或許拿上面剛剛提出的解任案問問,你覺得該案提請有什麼不滿足程序正義之處,畢竟有實際案例較好切磋。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月14日 (五) 03:54 (UTC)
- Gluo88提出苗君濫用封鎖的證據,光是與給他解封的管理員的理解已有顯著落差。提案人逕自認定管理員濫用權限或封鎖有瑕疵,而未經審視方針是否禁止某些行為,違規事實並不明確,解任案則不應成立。
- Gluo88對苗君誹謗Lanwi1的指控顯然存在誤差,苗君作為當年事件的當事人,除了當時短時間內就補充提供了公開討論的記錄外,其當年作為用戶查核員能將Lanwi1的公開口供跟技術資訊比對,亦可作為其指控或懷疑的證據。有證有據者的合理懷疑顯然難以構成誹謗,反觀Gluo88在他人(我)指出苗君確有提供證據後,選擇性無視並謊稱「沒有證據」(證據已經提供了,還有一些是苗君顯然不能公開的),還在毫無證據的背景下相信Lanwi1的說辭,用以指控苗君誹謗,乃是明顯的拉偏架,「誹謗」指控也難以成立。
- 苗君在討論中積極解釋、說明其行為,也通過交涉獲得解封Gluo88的藍桌君的認同;反觀Gluo88全然不接受任何解釋,並拒絕一切依照方針的規範及通用理解的觀念,顯然並非管理員所致之溝通無效(而是提案人拒絕溝通),不能成立解任案溝通無效之要件。
- Gluo88在一開頭就聲明將會發起明顯違反方針(不審核是否構成解任條件,只憑其自身及聯署人認定),亦有威脅其他管理人員不可執行方針賦予的權力(終止不當解任案),顯然嚴重侵犯程序公義。
- 光是這些,若仲委會已成立,以上程序問題已經足以將此由社群發起的解任案提交仲裁委員會處理了。--路西法人 2024年6月14日 (五) 04:20 (UTC)
Gluo88提出苗君濫用封禁的證據,光是與給他解封的管理員的理解已有顯著落差。
在管理員最初已認定封禁查封理由欠缺,這是事實。也尊重審核管理員認為程度不到罷免的理念。涉事管理員的理解與本人的理解(及其他用戶的理解)也不相干,除非訴諸權威。Gluo88對苗君誹謗Lanwi1的指控顯然存在誤差,苗君作為當年事件的當事人...
通篇仍然持續為當事人未經認證(CU、CA)臆測偽證據發言,並忽略當事人已遭受嚴重精神重創的事實。打個不恰當的比喻,如果一個強姦受害者侮辱強姦犯,然後某個認說她犯了侮辱誹謗罪,她的言行客觀上是不妥的,但這種檢討受害人的行為更是拉偏架,扭曲一般人道德理解,態度可謂令人髮指。苗君在討論中積極解釋、說明其行為,也通過交涉獲得解封Gluo88的藍桌君的認同...
先不論在下幾乎已全面駁斥閣下及涉事用戶謬論(並且您除了詭辯,顯然無法正面回應;另一位也沒有能力全面回應在下的質疑)只能是個人意見,不代表我認同(及其他潛在用戶認同),照@LuciferianThomas這種偽邏輯,在下嘗試總結一下:大概就是只要當事人不斷「發言論證溝通」就不構成「溝通無效」(並將其歸責於提案人及聯署人死活不認可),上個這麼聲稱及類似的案例已被基金會制裁了。Gluo88在一開頭就聲明將會發起明顯違反方針(不審核是否構成解任條件,只憑其自身及聯署人認定),亦有威脅其他管理人員不可執行方針賦予的權力(終止不當解任案)...
我並沒說不審核,而是交由聯署人審核認定(本來現行方針就不用一致共識確認),這恰恰是符合過往慣例標準的原則(《方針》政策指出,大部分被人們接受的慣例不會立即被寫上。方針只是明文的慣例標準。)反觀前次管理人員的所謂「決定」已被廣泛質疑「官官相衛」「違反官僚主義」「凌駕討論」「無權確認」「不避嫌」這種藐視社群的決定,恰恰是侵害程序公義的行為(「管理員沒有任何高於其他用戶的特權,唯能實現社群討論所得的共識「),更應該就行政員爭議行為交到仲裁委員會裁決,以正視聽。- 其實面對您的指控,在下本來是不打算留言的,但在下考慮到您並未停止有關涉嫌擾亂及遊戲討論行為,甚至發出明顯的威脅,呼籲第三方管理員制裁在下,才不得不在此回應。此外,這個發言涉嫌「針對特定受眾」基於「推銷立場」的拉票行為。根據行政員前次所謂認定,「RFDA是本站大事」瀏覽量極高,所以已經構成大幅張貼效果。考慮到相關留言通篇粗亮紅字體,還有可能構成情緒勒索騷擾用戶(與第三方管理員)。副知在上次解任時發起討論「拉票」的@魔琴閣下就此發表看法。
- 以上可合理確認LuciferianThomas君的所謂「程序問題」,無一例外其實都站不住腳。即使仲裁委員會成立,諸位仲裁員面對閣下指出的「程序問題」,在仔細審閱相關討論後,除了給您發不應在討論中,使用過多特效使別人感到騷擾的提醒或警告外,基於方針的正常理解相信也只能一笑而已。
- 在下請@LuciferianThomas君停止為涉嫌袒護涉事用戶試圖干擾本次Rfda的行為,並期望根據在下對閣下提出的質詢,檢討當事管理員及自身問題,作出有益討論事情。--Gluo88(留言) 2024年6月16日 (日) 01:06 (UTC)
- 另外抱歉剛剛太認真看右邊那張圖,沒仔細注意您有提出「比圖片多一條」的走線Orz —— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月14日 (五) 03:58 (UTC)
- 這個我自己也沒說清楚。--路西法人 2024年6月14日 (五) 04:22 (UTC)
- 本人認為,現行情況實際上就是這樣,那或許是對「事前」部分疑慮較多?也就是欲阻止直接上客棧「大亂鬥」的醜陋局面。或許拿上面剛剛提出的解任案問問,你覺得該案提請有什麼不滿足程序正義之處,畢竟有實際案例較好切磋。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月14日 (五) 03:54 (UTC)
- 或許我說的不清晰:我在ATB方案上增添的走綫是給「社群提交給仲裁委員會」新增了前設,故產生「社群無人提請仲裁(而社群自行解決解任問題)」的走線。若社群自行走解任程序時理據出了問題,自然會有人提交給仲裁委員會;若真的幾乎沒有爭議的,那社群自己走完整個程序都不會需要仲裁委員會插手。如果有人提交,仲裁委員會又認定社群本身在該案已能自行處理(發起除權無明顯問題需要仲裁委員會插手),即可拒絕社群請求。不經仲委會提出除權的條件也不需要怎麽提高,還是滿足最基本的程序公義即可。--路西法人 2024年6月14日 (五) 03:42 (UTC)
- 大致同意上述圖片的內容。--在下荷花,請多指教(歡迎簽到) 2024年6月14日 (五) 04:34 (UTC)
- 簡而言之,我反對把像台灣選總統一樣的直接民主改成香港選特首一樣的代議民主。香港特首怎麼選,我覺得你也知道。--桐生ここ★[討論] 2024年6月14日 (五) 07:22 (UTC)
- 同意桐生的想法。--千村狐兔(留言) 2024年6月16日 (日) 01:43 (UTC)
- 右方為添加了我所說的比ATB版本多一個走法的機制,Ericliu1912及Hehua可以參考看看如何。除了RFDA,其實多數其他仲裁調查都可以比照處理。--路西法人 2024年6月14日 (五) 05:59 (UTC)
- 看起來主動權是否仍在仲裁委員會?因若每一案總是有人要求受理調查,那程序上便實質造成社群直接管道不得通。管理員解任爭議向來大,可預見會有不少辯稱個案程序不符合方針者。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月14日 (五) 06:11 (UTC)
- 是也沒錯,我甚至是預期未來絕大多數的仲裁提案最終必須經過仲裁委員會的手一次,但既然管理人員解任社群沒辦法自己處理(真的有問題的時候,還是得仲裁介入,總不能堅持不讓仲裁處理違規事項吧?),那把這個程序幾乎完全交給仲裁是可以理解的。我是不反對設定反聯署的機制(聯署改交仲裁委員會),但送往調查的門檻會要比直接送投票的要低一截(例如送往調查需5人聯簽,解任聯署門檻提高至10人)。
- 不過起碼這裏保障了多數情況下社群仍保有投票除權的權力,也確保仲裁委員會僅能在真的有問題的時候才介入管理人員解任程序(在社群能自己處理及未獲解任程序中的合理質疑的情況下應拒絕受理),但也確保在必要情況下由仲裁委員會自行行使去除管理人員權限的權力。(所謂必要情況,指濫用傀儡等所有可致(非短期)封鎖或禁制的違規情況)--路西法人 2024年6月14日 (五) 06:58 (UTC)
- 如此怕是有遊戲規則之嫌,畢竟祇要提出質疑,就可以強制將討論拖入仲裁程序,也很難預見仲裁委員會不會因為期望有案件,而對此傾向「照單全收」之類。此外,本人認為仲裁委員會試行第一任期期間,不宜移交過多權力。希望還有某種折衷或過渡方案供社群選擇。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月14日 (五) 12:59 (UTC)
- 不過,考慮到社群或有希望仲裁委員會針對此類提案提供調查報告,若祇是請求類似國際法院就議題提供諮詢意見之類,而不直接跳過其他社群既有流程(即最右邊那條路線),那本人並不反對。其區別在於是仲裁委員會是主動受理調查,還是基於社群需求被動提供意見(用詞或有差異,但總之應該是這意思)。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月14日 (五) 13:09 (UTC)
- 回應第一則留言:
很難預見仲裁委員會不會因為期望有案件,而對此傾向「照單全收」之類
:仲裁委員會在接獲針對已經發起的RFDA案請求時,並非單單議決「是否受理」,仲裁員公開議決是否受理案件時還必須指出受理或拒絕理據,也不能空口無憑說「社群已無法通過社群渠道解決」,而是要提供論證。究竟是怎樣無法通過社群渠道解決,究竟是否非當事的管理人員採取行動即能解決,都是必須論證的點。當仲裁委員會收到直接提請調查管理人員行為之時,條件同樣適用,這情況下提出調查的人也是需要論證為何不通過社群解任程序(例如:提出解任一方論據不當,可預期他們走社群解任必然會造成問題)。仲裁委員會就算是「想接受案件」也要寫個合理到不行的理由,但有合理的理由就代表真的要接受案件了。
- 回應第二則留言:
- 你的理解大致正確,但必須指出在「已經有明顯必要解任」、「緊急解任」或「根本不成立」等情況下,則不會發起任何解任投票,而直接由仲裁委員會作出決定。你所說
基於社群需求
,這個就很難定義什麼叫「社群需求」了,究竟是有人聯署發起仲裁,還是需要有共識,都會有人不同意;後者在已經吵得不可開交的情況下顯然已經難以實行,所以唯有通過聯署的方式發起仲裁以確保真的是「社群」需求而非「個人」需求了。
- 你的理解大致正確,但必須指出在「已經有明顯必要解任」、「緊急解任」或「根本不成立」等情況下,則不會發起任何解任投票,而直接由仲裁委員會作出決定。你所說
- --路西法人 2024年6月15日 (六) 00:48 (UTC)
- 回應第一則留言:
- 看起來主動權是否仍在仲裁委員會?因若每一案總是有人要求受理調查,那程序上便實質造成社群直接管道不得通。管理員解任爭議向來大,可預見會有不少辯稱個案程序不符合方針者。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月14日 (五) 06:11 (UTC)
- 感謝提及,我個人基本(+)支持此方案。--在下荷花,請多指教(歡迎簽到) 2024年6月14日 (五) 07:55 (UTC)
- 我認為此方案可以。--~~Sid~~ 2024年6月14日 (五) 08:36 (UTC)
- 支持這個版本。--Rice King 信箱 · 留名.邊緣人 2024年6月14日 (五) 11:25 (UTC)
- (+)支持此一版本。--維基病夫邀請您加入❤️邊緣人小組·🖊️簽到 2024年6月14日 (五) 11:41 (UTC)
- 我問個問題,如果RFDA只有一人認為不符合方針,即使整個社群都支持聯署,也必須進入仲裁委員會程序?這個有人認為的有人是多少人?--桐生ここ★[討論] 2024年6月14日 (五) 13:03 (UTC)
- 這自然是需要"討論"的,當然也有個更簡單的方法是讓認為不符合方針的人自己送,仲裁委員會看到這種情況自然會拒絕請求,有個壞處是會讓仲裁委員會很累就是,如果要採用,建議賦予仲裁委員禁止濫用仲裁的人提出仲裁請求的權力。--~~Sid~~ 2024年6月14日 (五) 14:09 (UTC)
- 如我上方留言所述,確實可以新增反聯署的概念,或為五名符合人事任免投票權的用戶聯署,或為最低限度一符合人事任免投票權的用戶加一非當事管理員共簽請求仲裁。一個人(尤其是當事管理員本人)即可發起進入仲裁程序也還真的門檻過低。--路西法人 2024年6月15日 (六) 00:29 (UTC)
- 如果要改革的話,我覺得應該加入反聯署過程才能被仲裁委員會受理,不然就像你說的,當事管理員反對然後就進入仲裁就有點不合適了。--桐生ここ★[討論] 2024年6月18日 (二) 19:23 (UTC)
- 原則上(+)支持,太需要了。--Shwangtianyuan 不忘初心 牢記使命 2024年6月14日 (五) 16:13 (UTC)
- 個人意見是發表調查報告後,解任與否應公付社群決議。即便調查報告認為提請解任是多麼錯誤,社群應擁有解任事宜的最終裁量權。-千村狐兔(留言) 2024年6月16日 (日) 02:25 (UTC)
- 此前社群諮詢性投票已明確認可這點,我相信應該會體現在最終方案。沒有的話再來商榷。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月16日 (日) 04:22 (UTC)
- 大致上認同這個觀點,畢竟不能排除調查報告出錯的可能性(是的,請質疑一切的權威),但我的個人意見是如果調查報告的結果是管理人員因屬於有必要的情況或緊急情況而被直接解任,這並不屬於社羣的裁量範圍。換言之,我認為如果調查報告認為這不屬於可以解任的情況,但社羣形成了顯然相反的共識時,無論調查報告是否出錯,社羣依舊可以在有相當共識的情況下發起解任投票,但其他方面我認同File:ArbCom de-admin procedure chart (LT version).png的表述。Sanmosa Snipe–Clam Grapple 2024年6月18日 (二) 12:09 (UTC)
- 「真有必要」就直接解任了,沒必要再提出調查報告,祇需要簡短說明。「真有必要」的情況應當已經很明確,正常人都看得出來(常識判斷),否則就不能說是「真有必要」。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月18日 (二) 17:57 (UTC)
- 實際上就連上面舉例的濫用傀儡,我也不覺得必然適用直接解任,至多是調查期間允許暫時褫奪管理權限。因為這終究取決社群對管理員的信賴,說不準社群願意原諒過失,那憑什麼需要由仲裁委員會擅自代為「處刑」呢?由於已經有真正最後手段「緊急解任」,我甚至不覺得有必要給予仲裁委員會所謂「有必要情況」除權的選擇。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月18日 (二) 18:02 (UTC)
- 管理員不會有其他用戶沒有的豁免權,管理員做出應受非短期(全站範圍)封鎖或禁制的行為理應受與一般用戶相同的處理,而受(全站範圍)封鎖或禁制期間管理員本身就無權參與社群事務。近期受過封鎖的用戶本來就不能參選管理員,這個相比其他「建議條件」而言更幾乎是「必然需要符合」的要求,也是社群的基本期望。因嚴重違規而致非短期封鎖或禁制行為的用戶本來就不適任管理員,這種情況的解任是彈劾而非罷免。社群有權在被彈劾用戶接受封鎖及一年冷靜期後經重新選舉上任管理員,但顯然有過錯的就不是「可以被社群原諒」的行為。用戶單單因管理員身份而被「原諒過失」顯然變成獲得其他用戶沒有的特權。--路西法人 2024年6月19日 (三) 02:02 (UTC)
- 本人早已指出,調查期間仲裁委員會認為確有必要時,可暫時取消當事人之管理權限,至於最終處份問題則完全是兩回事;既然說「管理員做出應受非短期封鎖或禁制的行為理應受與一般用戶相同的處理」,那解除權限方針明確指出「當管理員封鎖任何一位依從權限申請方針獲得權限的使用者時,請同時提報,讓其他使用者覆核考慮是否為之除權」,而管理員就可以被仲裁委員會逕行除權了?若真「理應受相同處理」,那此等失職行為,就雖自然成為得提出解任(「覆核考慮是否為之除權」)之「理由」,但並不總是直接等於「結果」。又此種「覆核」之對象一般而言是社群整體,不是仲裁委員會(部分例外既已言明於上述草案,此處不贅述);社群有權就管理員解任案成立與否予以最後決定,此時又可參考解除權限方針提到的「蓄意犯規」、「草率行事」、「執於己見」、「沒有悔意」等要件,構成對管理員與其他權限持有者一視同仁之量尺,達到所謂「理應受與一般使用者相同的處理」。
- 解任乃最終手段,請與社群事先商榷什麼情況值得如此做,不要自己定義「本來」、「顯然」、「特權」、「不是可以原諒的行為」,彷彿理所當然一般。尤其社群已明確傾向反對由仲裁委員會逕行處份失職管理人員,是以若一定要置若干例外,依據比例原則及法律保留原則(當然本站政策不是法律,但基本觀念類似),理當以明文列出,且或可能嚴格限縮處理。又即使如我個人意見上述如此,也沒逕行強求或壓制誰去接受,祇是提出供社群參考,我想任何人的意見都一樣;假使認為「應受非短期全站封鎖或禁制的行為」可以由仲裁委員會逕行除權,那就是首先要由社群確定是否同意此等條件,或初步予以修正(如不包含某些「禁制」情況、有權經社群額外同意排除某些意外情況個案之類),然後還要釐清所謂「非短期」具體指什麼、又此種行為應可能包含什麼情況(如上方提到「濫用傀儡」,具體是多嚴重之類)等細節,最後纔得凝聚為真正可行且符合程序正義之共識(以上是隨意舉例)。不是提一些模稜兩可的條件順溜過去就行。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月19日 (三) 17:52 (UTC)
- 考慮一些過往案例,本人目前認為所謂「有必要情況」祇有遭遇值得受不限期封鎖之行為。受如此重大處份且未能申訴成功之管理員,亦往往會遭社群事後除權,甚至多數是緊急除權。本人認為,仲裁委員會在此種情況下裁決逕予除權,並不逾越社群過往實踐締造之共識及一般常識。若有其他認為可適用情況,還請社群具體提出。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月19日 (三) 18:20 (UTC)
- 「因為這終究取決社群對管理員的信賴」不全然,這也視乎他本身造成的危害的嚴重性,這不是擅自代為「處刑」,而是避免社羣擅自慷受害者之慨。這樣說:就算你原諒了一個殺人犯,他還是一樣要被判死刑或終身監禁,不能說因為你原諒了而直接認為他無罪。Sanmosa 蚌埠 2024年6月19日 (三) 05:55 (UTC)
- 社群是本站最高「政權機關」及一切事務最終決定者,本人認為真有共識(大前提)的話要「慷受害者之慨」也行;反過來說,如果仲裁委員會經審酌決定「慷受害者之慨」,閣下又該如何應對?何況在本站,所謂「極刑」不過是禁止編輯,且除極少數社群不可抗力情況(如基金會行動、全域禁制等)外,沒有真正不可逆的處份,此處完全不宜援用現實司法情況。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月19日 (三) 17:52 (UTC)
- 真要用司法來比擬的話,仲裁委員會可以「限制遷徙」甚至「拘禁」,防止「嫌犯」繼續迫害他人,也可以提出「證據」(此處指調查報告,並非報告本身採用的證據)給予「法官」(社群)參考;仲裁委員會在其他管轄內案件可能自己兼任「法官」,但就管理人員解任議題而言,最終判決「有期徒刑」(本站沒有「死刑」)者則仍是社群,不是仲裁委員會(所以說為什麼不應該用現實司法比較,因為太強行硬湊了)。社群已經彰顯意志,不打算將仲裁委員會打造為非常之國民公會。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月19日 (三) 17:55 (UTC)
- 管理員不會有其他用戶沒有的豁免權,管理員做出應受非短期(全站範圍)封鎖或禁制的行為理應受與一般用戶相同的處理,而受(全站範圍)封鎖或禁制期間管理員本身就無權參與社群事務。近期受過封鎖的用戶本來就不能參選管理員,這個相比其他「建議條件」而言更幾乎是「必然需要符合」的要求,也是社群的基本期望。因嚴重違規而致非短期封鎖或禁制行為的用戶本來就不適任管理員,這種情況的解任是彈劾而非罷免。社群有權在被彈劾用戶接受封鎖及一年冷靜期後經重新選舉上任管理員,但顯然有過錯的就不是「可以被社群原諒」的行為。用戶單單因管理員身份而被「原諒過失」顯然變成獲得其他用戶沒有的特權。--路西法人 2024年6月19日 (三) 02:02 (UTC)
- 另外,我同意有關社群就與仲委會意見相左時,可重行循聯署管道形成共識發起解任案的意見。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月18日 (二) 18:05 (UTC)
臨時暫停特權機制[編輯]
I'm going to make a proposal about temporarily desysopping, when a sysop, oversight or checkuser are being investigated, their priviledge may need to be temporarily removed by Arbcom to prevent further disruption if necessary. And shall not obtained again unless the investigation is over. Especially, for VRT and the ones who have signed NDA, Wikimedia Foundation need to be noticed if neccessary to remove such priviledge. I'm a little bit tired but good luck, god bless you.---Lemonaka 2024年6月14日 (五) 13:08 (UTC)
我準備提出一個關於暫時取消系統管理員的提案,當系統管理員、監督員或檢查用戶正在接受調查時,Arbcom可能需要暫時取消他們的權限,以防止在必要時造成進一步的干擾。除非調查結束,否則不得再次獲得。特別是對於 VRT 和簽署了保密協議的人,維基媒體基金會需要注意是否有必要取消這種權限。我有點累了,但祝你好運,上帝保佑你。---Lemonaka 2024年6月14日 (五) 13:08 (UTC)
- @Ericliu1912 @LuciferianThomas -Lemonaka 2024年6月14日 (五) 13:11 (UTC)
- 仲裁委員會大概可以視情況決定是否技術上暫時取締管理員行使權限。不過本地相較於英文維基百科,尚沒有直接取消管理員系統操作權之權力,本人認為這代表兩地社群習慣差異,故制度移植時亦應有本地化措施以為反映(例如縮減可取締權限之案件種類等)。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月14日 (五) 13:15 (UTC)
- 我覺得可以提出緊急凍結機制,類似緊急除權,比方說監督員、界面管理員等重要權限,正在調查期間社群或行政員認為必須先除權以保證安全,則先除權,等待調查結果再恢復或維持除權。--桐生ここ★[討論] 2024年6月14日 (五) 13:21 (UTC)
- 重點在於「無罪推定」(雖然應該少援用司法概念)。除上述情況外,本人認為唯有涉及管理權限行使可能損及當事人權利,或妨礙案件之進行,或有正當合理之依據認為案件進行中不適宜持有權限者,方得暫時除權。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月14日 (五) 13:40 (UTC)
- 這有個問題是誰來判定會比較好,Arbcom判定社群會有人不認同,社群自己來討論要不要暫時除權又會因為爭執而不了了之,一個很尷尬的情況。--~~Sid~~ 2024年6月17日 (一) 09:08 (UTC)
- 重點在於「無罪推定」(雖然應該少援用司法概念)。除上述情況外,本人認為唯有涉及管理權限行使可能損及當事人權利,或妨礙案件之進行,或有正當合理之依據認為案件進行中不適宜持有權限者,方得暫時除權。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月14日 (五) 13:40 (UTC)
- 我覺得可以提出緊急凍結機制,類似緊急除權,比方說監督員、界面管理員等重要權限,正在調查期間社群或行政員認為必須先除權以保證安全,則先除權,等待調查結果再恢復或維持除權。--桐生ここ★[討論] 2024年6月14日 (五) 13:21 (UTC)
- 初期仲裁委員會或本地行政員都還沒有權限可以自行取消管理員權限,這個或許要到未來屆數的仲委會選舉前再解決。目前狀態下,僅有「可能需要緊急除權」、「(發佈報告後)已經確認符合解任發起條件,等候社群投票重新確認管理員權限」兩個情況是適合直接凍結權限。
- 雖然目前尚無技術手段直接凍結管理員權限,仲委會仍可通過審議施行禁制權,臨時禁制當事人使用任何管理人員權限,違者亦可直接視作嚴重違規而符合除權條件即可。
- 不過如果是「凍結權限」,那麼就不是「解任投票」而是「重新確認投票」,重新確認投票的通過標準(此處指支持留任比率)或許要提高;反過來解任投票的通過標準(此處指支持解任比率)也需因應略微提高(例如55%)。--路西法人 2024年6月15日 (六) 00:56 (UTC)
- How can you 「凍結」(maybe temporarily stop) VRT priviledge without removing them? What about Oversight? -Lemonaka 2024年6月15日 (六) 02:22 (UTC)
- 基本上都是需要通過暫時除權處理。使用行政手段如禁制也是可以等同凍結權限,違者即直接除權即可。--路西法人 2024年6月15日 (六) 03:15 (UTC)
- How can you 「凍結」(maybe temporarily stop) VRT priviledge without removing them? What about Oversight? -Lemonaka 2024年6月15日 (六) 02:22 (UTC)
新用戶通過撰寫新條目的方式「完成學科作業」的處理討論[編輯]
近日巡查當中發現疑似存在新用戶通過撰寫新條目的方式「完成學科作業」,目前主要涉及兩位用戶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)
- 中文維基有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)
- 又有一個。--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)
- 社群可以趁此機會完善相關的頁面與規定,就我的觀察教育專案在中維的需求不算低,但也沒有到頻繁。--~~Sid~~ 2024年6月17日 (一) 09:29 (UTC)
請求討論LuciferianThomas涉嫌擾亂、遊戲Rfda共識形成事情[編輯]
用戶LuciferianThomas在近期有關用戶Mys 721tx不當用權態度、誹謗用戶事情為闡述觀點多次發表擾亂、遊戲討論言論:
- 一、訴諸詭辯技巧:針對在下的幾則言論見下:
- 「
如果說苗沒有對被封禁人假定善意,那麼被封禁人對苗毫無假定善意為誤判又是什麼道理?
」首先在下一開始的言論就完全假定善意,對涉事用戶的期許「...(Mys 721tx君封禁在下)一定是有令人敬服及光明正大之理由,因此在下才要求Mys 721tx君必須按維基百科的精神 「充分溝通 」,供社群檢驗。
,此則言論亦可能訴諸偽善,進而淡化涉事用戶不當行為。 為什麼苗君作為管理員,在依照方針認定用戶違規後,指出用戶「對扭曲方針的認識」,並明確拒絕解封,直到你「通過行為意識自己的錯誤」,這樣就叫做「無效溝通」...所以結局必須是管理員撤回封禁才叫「有效溝通」?
在下從未發表要求任何管理員必須解封言論,而是要求管理員詳細調查充分回應用戶質疑後行權。該言論我認為符合紅鯡魚定義的通過修辭、轉移言論性質,曲解在下解封申訴是為施行用戶正當要求合理解釋,保證用戶權益之本意。誹謗在台灣法律中,可受公評之事及與公共利益有關的申請不能認定誹謗、有盡力查證也不構成誹謗...
通篇引用法律解釋不當陳述誹謗定義,屬於維基法匠謬論,併合理化已造成當事人精神痛苦的誹謗行為。這種為袒護涉事管理員而扭曲一般人禮儀的發言令人髮指。至於所謂「證據」未得CU等權威機構認證,可合理認為屬於羅織罪名、捕風捉影。在此情境下,已經受到嚴重精神痛苦的Lanwi1即使在此等糟糕情緒下反指控,也可以理解。(這裡不是說相關言論妥當,但在下認為輕視別人的人無權要求自己不被輕視,Mys 721tx君應先尊重別人再要求被傷害的人尊重自己。)
- 二、強推意見的冗長發言:該君上述諸詭辯發言之冗長,可合理認為其涉嫌為袒護Mys 721tx君拉布、牴牾意見不和者。此等類似言論也非Luciferian君首次被質疑:早在WP:共識討論中已被諸多用戶認為強推、漠視反對意見,見下方用戶評價:
- 但我想閣下這等高傲的態度,連移動討論都能給人家扣擾亂帽子,大概是別想討論了。——Ericliu1912
- 壞處只是你的主觀認為,你現在的做法純屬強制推銷,愛用RFC的可以在RFC推進討論,不愛用或者不需要用到小心討論可以維持在客棧進行。——Cwek
- 因為社群的慣性的確是將各種廣泛性的問題放在客棧解決,而你斥之為陋習,就算你沒直接聲明需要「架空客棧」,但搞出一個RFC機制來分散討論,甚至還期望強制設立共識確立位置的規定來限制客棧或者推廣RFC的使用,但這些做法怎樣看都是不滿於RFC的利用不足而嘗試架空客棧。——Sanmosa
- 如果提出來的方案得不到社群支持,使用,逆社群之習慣,只怕是得不償失。——Ericliu1912
- 然而目前反對聲音眾,支持聲音寡,非得要強硬闖關,浪費大量社群資源,實在不無遺憾。我已經可以想像您給什麼說話我聽了,無非是「Stoneball」「非合理意見」「老調重彈不新鮮」之類。我本就應該如Fire Ice所說的不別花這樣多口水的。嘆嘆!——Ghren
- 確實,目前看來只有路西法君一人支持該提案。我本人雖認同他的初衷,但反對強制推行。——微腫頭龍
- 綜上可證明LuciferianThomas君習慣性為闡釋觀點發表冗長言論,強推不被人接受的觀點, 讓只有有限時間和精力的用戶感到難以繼續回應,遊戲共識形成。
- 三、魯莽指控他人行為不當':將在下提前聲告行政員如果違背社群程序、共識強行如上次討論般迅速終止決定,提出必要質詢的言論謂之「威脅」「恐嚇」進而違反RFDA,並就此要求第三方管理員「遏制」在下、阻止本次RFDA共識形成。顯然不符合常人認知。
- 同時一整段言論使用放大粗紅字體,已使在下感到威脅與恐嚇,也TPG指引的:「
避免過多的文字特效:請注意過多的文字特效會使別的用戶有被騷擾的感覺,亦讓人感到這些留言帶強烈的語氣,例如是斜體文字、粗體文字,以及英文中完全的大寫字母和過多的感嘆號,就像是「SHOUTING」
」 - 四、傾向言行、雙重標準:涉事用戶Mys 721tx之不當用權態度被多名用戶指出、質疑,卻絲毫不承認自己過錯。借@LuciferianThomas一言:人生最厭惡自己違規還好面子說是別人問題的人。LuciferianThomas卻完全忽視用戶質疑,對當事管理員問題隻字不提,顯示出Luciferian為袒護(自稱)「與自己走的很近的管理員」對用戶雙重標準、特別對待。
- 五、威脅用戶:在在下發表論證言論駁斥其冗長、不當言論後,在另一相關討論中,其不針對本人言論作出回應,反而威脅在下如果開啟聯署,將訴諸第三方管理員制裁。
- 我提前告知,如果管理人員如施行前次般被廣泛用戶質疑之行為,將提起新一輪質詢讓社群檢驗,Luciferian君能謂之「威脅」「脅迫」「攻擊」。在下依照過往慣例標準,駁斥其袒護管理員的發言後,其仍只是一貫未回應論證地指稱在下「扭曲方針」「不合規定,並威脅「
如果他還是正式發起解任案,我再請求其他管理人員制裁有關行為即是。
」(似乎在他眼裡這就不是威脅了)可合理認為LuciferianThomas君繼續雙重標準,優待涉事管理員、試圖「鎮壓」質詢管理員的用戶。
在下鑑於用戶LuciferianThomas君涉嫌擾亂、遊戲共識形成言論嚴重性,在此希望社群討論該用戶近期行為,保護社群用戶質詢管理員應有之權利。 同時再次(!)強烈抗議,並呼籲LuciferianThomas君立即停止涉嫌為偏袒管理員,阻撓當前RFDA共識形成發表詭辯言論、誇大扭曲意圖遏制質疑管理員的用戶、遊戲討論等違反AGF、文明與禮儀的不當行為。 希望LuciferianThomas自覺停止相關行為,作出有益討論。如無改善,社群理應對此進一步討論。保留其他方式維護討論秩序。--Gluo88(留言) 2024年6月15日 (六) 14:22 (UTC)
- 若是要討論單一使用者的行為以及實施封禁,應該去WP:VIP、WP:AN3或是WP:ANM提報。--CaryCheng(留言) 2024年6月15日 (六) 14:47 (UTC)
- 另外,我認為U:LuciferianThomas近期的發言及編輯並無不當,沒有閣下宣稱的擾亂、遊戲共識等情形。--CaryCheng(留言) 2024年6月15日 (六) 14:51 (UTC)
- 「若是要討論單一用戶的行為以及實施封禁,應該去WP:VIP、WP:AN3或是WP:ANM提報。」此事有關正在形成的RFDA共識,在此版面請求討論也廣泛利用版面徵詢其他用戶發言。此外,@LuciferianThomas君此前亦曾對前用戶在此版面提出要求社群討論處理,相信他能理解這一行為。至於您不認為近期發言或編輯並無不當,我能理解你的觀感。只是可以的話,還望給出您的理由陳述上方情形如何不違反,相信這有助於社群理解有關觀點。--Gluo88(留言) 2024年6月15日 (六) 15:03 (UTC)
- 喔不,你不理解,若是理解了就不會接著說出後面那一段。
- 閣下花了很大的篇幅試圖說服社群成員,U:LuciferianThomas做了很糟糕的事。我要說的就只是,我作為社群成員之一,閣下的長篇論述終究沒有說服我U:LuciferianThomas違反了方針與指引。
- --CaryCheng(留言) 2024年6月15日 (六) 18:44 (UTC)
- 維基百科共識決議的機制基本上就是論據合理性之間的相互博弈形成,如果編者沒有提出論據的能力,不會形成有益共識。
- 正如有人僅以「我認為該條目有所不當,沒有某些人宣稱的資料完備、敘述流暢等情形」投票反對DYK,而不指出具體的問題。這種行為可能構成POINT,即不樂見共識建立的發言:
在其他編者對自己的編輯提出問題/異議或要求解釋時,反覆漠視他們的訴求。
。 - 當然以上只是建議,或許在下仍然無法說服閣下。只是請注意自身討論態度引起的可能問題。
- 謝謝您,祝編安
- --Gluo88(留言) 2024年6月15日 (六) 19:26 (UTC)
- 感謝提醒,我一向態度和藹、口氣和善、立場中立、就事論事,一定不會引起問題。
- 簡單地說,我希望閣下提出更有說服力的論述,以利我參與討論形成共識。
- 祝編安。--CaryCheng(留言) 2024年6月16日 (日) 17:07 (UTC)
- 「若是要討論單一用戶的行為以及實施封禁,應該去WP:VIP、WP:AN3或是WP:ANM提報。」此事有關正在形成的RFDA共識,在此版面請求討論也廣泛利用版面徵詢其他用戶發言。此外,@LuciferianThomas君此前亦曾對前用戶在此版面提出要求社群討論處理,相信他能理解這一行為。至於您不認為近期發言或編輯並無不當,我能理解你的觀感。只是可以的話,還望給出您的理由陳述上方情形如何不違反,相信這有助於社群理解有關觀點。--Gluo88(留言) 2024年6月15日 (六) 15:03 (UTC)
- 另外,我認為U:LuciferianThomas近期的發言及編輯並無不當,沒有閣下宣稱的擾亂、遊戲共識等情形。--CaryCheng(留言) 2024年6月15日 (六) 14:51 (UTC)
- 贊成CaryCheng所述:「若是要討論單一使用者的行為以及實施封禁,應該去WP:VIP、WP:AN3或是WP:ANM提報。」,也希望Gluo88自覺停止相關行為,在其他適合的頁面進行提報--Wolfch (留言) 2024年6月15日 (六) 15:29 (UTC)
- 這只是原則問題,封禁政策指出的也只是
任何用戶在提供充分證據下可向適當的布告板提報不當編輯行為,提議管理員封禁相關賬號和IP地址。
而不是必須在有關版面提出。所以我不知道「要求我自覺停止相關行為」的原因何在(擾亂?遊戲?在下不過是用@LuciferianThomas君先前的標準行為處事在此對他提出質詢與邀請用戶討論,如果能改善,我目前亦無將其舉報意願,只是希望社群討論此事),除非將維基百科視作維基百科不是官僚體系。只是從引文條文的非強制性來看,這點自然也是不成立的。請就用戶相關行為發言,謝謝。--Gluo88(留言) 2024年6月15日 (六) 15:45 (UTC)- 最近的討論似乎有帳號提到貢獻至上原則,只有這個原則切入一種觀點
- A帳號的編輯產生數值X正面效果(此時假設X數值無限大),數值Y負面效果,X-Y>0(此時必定是X÷Y>1)且X÷Y>2
- 假設第一項成立,讓A機能停止是否適合
- 將第一項的的等式改成Y-X>0(此時必定是Y÷X>1)且Y÷X>2,此時讓A機能停止是否適合
- --Rastinition(留言) 2024年6月15日 (六) 20:29 (UTC)
- 最近的討論似乎有帳號提到貢獻至上原則,只有這個原則切入一種觀點
- 這只是原則問題,封禁政策指出的也只是
- @Gluo88 stop, you are close to WMLO(討論 | 貢獻) who got a CBAN on this community. I once tried to persuade them to stop accusing all the users but failed. Do you want to second their process? -Lemonaka 2024年6月16日 (日) 11:31 (UTC)
- 同Lemonaka,我建議您避免步入WMLO後塵。--桐生ここ★[討論] 2024年6月16日 (日) 12:24 (UTC)
- @Gluo88:建議您可以放一段假期,您太激動了,也十分感謝您對我上面留言的認可,您使用系統功能發送的感謝我有收到,加油。--~~Sid~~ 2024年6月17日 (一) 09:03 (UTC)
謝謝兩位提醒 , 我目前儘量不發言了。--Gluo88(留言) 2024年6月16日 (日) 12:43 (UTC)
當事人回應區[編輯]
在下認同維基百科不強迫任何人參與,但我覺得閣下的言行可能對未來討論造成不是很好的影響(在下現在還在擔心是否我真的發起聯署,您會將此前威脅訴諸真實)。所以特此設立當事人回應區。如果可以的話,還請您在此回復上述問題。如果您不想回答,也沒關係。 --Gluo88(留言) 2024年6月16日 (日) 12:30 (UTC)
- I got a severe threat from WMLO, a previous banned user, after posting this comment by direct emailing. I will step away from this topic. Good luck for every parties in this case. -Lemonaka 2024年6月17日 (一) 05:38 (UTC)
- 建議您閱讀WP:ANON,並尋求信任與安全團隊協助。--桐生ここ★[討論] 2024年6月17日 (一) 06:50 (UTC)
- How do he mail you? —— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月19日 (三) 14:20 (UTC)
建議多多關注那些潛在的高風險主題[編輯]
看了近期新提議高風險主題後,我覺得還有另外一些主題的的條目長期遭受破壞及編輯戰影響,或者近幾年這樣的問題、爭議激增的,但是可能還沒有引起足夠的關注,再加之近年封禁那7位管理員的風波的影響,我建議熱心用戶多加留意,及早提報。--⚞︎★⚟︎ 2024年6月17日 (一) 05:48 (UTC)
Template:Policy風格[編輯]
Template:Policy和Template:Nutshell的邊框怎麼全撐到頁面的邊上了,之前應該是居中,兩邊留有一定的空白,見互聯網檔案館備份。英維的也是居中,兩邊留有空白。似乎是所有調用Module:Message box的模板,顯示結果均變成如此。--Kethyga(留言) 2024年6月18日 (二) 14:38 (UTC)
- 這似乎不是本地技術問題。—— Eric Liu 創造は生命(留言・留名・學生會) 2024年6月18日 (二) 17:23 (UTC)
- 已修復,昨天為了修dark mode下的問題,偷懶抄enwiki沒抄全。已經補上--百無一用是書生 (☎) 2024年6月19日 (三) 02:36 (UTC)
- 現在dark mode有這麽多問題,不如專門開個RFC討論一下吧。--User:What7what8🏠 2024年6月19日 (三) 15:34 (UTC)