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

添加话题

本頁提出或讨论维基百科政策、方针,请参看方針與指引方针列表
繁简处理的议题请前往字词转换讨论页
条目应当如何编辑才符合中立性原則寻求社群共识,请前往条目探讨留言。
請注重礼仪、遵守方針與指引,一般問題請至互助客棧其他區知识问答提出,留言后请务必签名(点击 )。


發表前請先搜索存档,參考舊討論中的内容可節省您的時間。
公告欄
# 💭 話題 💬 👥 🙋 最新發言 🕒 (UTC+8)
1 提議新建交通車輛條目內容指引2 122 24 鐵路1 2022-08-04 10:49
2 提议修改维基百科:防滥用过滤器 69 20 LuciferianThomas 2022-08-05 16:50
3 關於接下來的管理員投票 137 31 Lanwi1 2022-08-08 11:43
4 建議修改音樂關注度規則 72 14 Milkypine 2022-08-04 16:45
5 提议在电子游戏条目指引中规范游戏数字发行平台外链 37 12 YFdyh000 2022-08-04 16:07
6 修正快速刪除方針 15 8 Ericliu1912 2022-08-08 10:14
7 修订编辑战方针 17 8 Kriz Ju 2022-07-30 05:34
8 提議設立容許查看私密資訊的用戶組/flag 9 8 YFdyh000 2022-08-04 14:37
9 配置表单来方便用户发邮件申请账户或申请IPBE权限 14 5 Stang 2022-08-01 16:11
10 電視劇演員與角色排序指引 18 6 Kriz Ju 2022-08-06 05:05
11 有关节目列表条目的删除标准的补充讨论 8 3 Yinyue200 2022-07-31 20:49
12 提议修改优特内容评选规则 14 8 Yinyue200 2022-07-31 20:54
13 维基百科:关注度/提报問題 23 7 YFdyh000 2022-08-04 18:33
14 修改"特色图片标准" 3 3 Yinyue200 2022-07-31 20:59
15 提議新增一條有關條目評級的指引 2 2 S099001 2022-07-31 14:59
16 提議將格式手冊/序言章節#列明來源設為方針指引 43 11 Nostalgiacn 2022-08-08 13:19
17 提議建立中小學條目指引 16 7 S099001 2022-08-07 19:21
18 優良條目審查應否參考過往成功審查的紀錄? 1 1 Ericliu1912 2022-08-01 13:27
19 提议增设“线上活动特别贡献” 1 1 Ericliu1912 2022-08-02 22:03
20 提议规定巡查时将页面移动至草稿的规则 4 4 YFdyh000 2022-08-04 09:36
21 修订编辑战方针(二) 8 3 Ericliu1912 2022-08-07 12:22
22 修訂傀儡方針涉法律威脅之字樣 2 2 桐生ここ 2022-08-08 10:12
發言更新圖例
  • 最近一小時內
  • 最近一日內
  • 一週內
  • 一個月內
  • 逾一個月
特殊狀態
已移動至其他頁面
或完成討論之議題
手動設定
當列表出現異常時,
請先檢查設定是否有誤

提議新建交通車輛條目內容指引2

本指引為交通車輛條目內容指引,由各專業領域的維基達成的條目編寫共識。相似格式有助於閱讀及編輯維護上的便利性,以及減少特定章節的編輯戰,目的是提供編者符合編輯格式參考指引。果您有想法或疑問,請在討論頁面進行討論。除此之外,您還應該熟悉更優秀條目寫作指南

行文結構 本節介紹了幾類條目的結構,實際條目的分節方式和標題無需完全對應下文。若您的條目有特殊之處,請放手調整,不必拘泥於本文。

鐵路車輛

  • 導言:簡述車輛所屬的鐵路公司、製造商、服務路線、投入服務日期等,並精要概括正文。
  • 資訊框:一般用用{{鐵路車輛}},亦可使用{{鐵路車輛2}}。模版應照文檔填寫。
  • 概要:介紹車輛引進緣由、役緣由(如已除役之車輛)、基本概述等。
  • 規格與構造:介紹車輛基本構造、機電設備、外觀塗裝、設備規格、編組方式等。
  • 各代車輛:若車輛型號生產不只一代或子型號,依照各代不同之處進行介紹。
  • 重大事故:若車輛曾經發生過重大鐵路事故可初步簡述事故經過,並使用{{main}}作主條目導向。
  • 車輛保存:若車輛已退役,並且公開保存,針對保存位置以及緣由進行介紹。
  • 相關條目:與條目相關的車型或車種可於此列出。
  • 參考文獻:請列明來源!報章雜誌、鐵路公司官網的車輛簡介、車輛製造商的車輛簡介與政府出國報告書都是好的來源。切記,不可使用部落格與營運單位的內部文件作為來源。
  • 外部連結:可連接其他維基計畫或是未達可靠來源門檻的百科性資源

客運/公車車輛[註 1]

  • 導言:簡述車輛製造商、車輛類型等,並精要概括正文。
  • 資訊框:一般用{{Infobox Automobile}}。模版應照文檔填寫。
  • 概要:介紹車輛引進緣由、退役緣由(如已除役之車輛)、基本概述等。
  • 規格與構造:介紹車輛基本構造、設備規格等。
  • 各代車輛:若車輛型號生產不只一代,依照各代不同之處進行介紹。
  • 重大事故:若車輛曾經發生過重大交通事故可初步簡述事故經過,並使用{{main}}作主條目導向。
  • 車輛保存:若車輛已退役,並且公開保存,針對保存位置以及緣由進行介紹。
  • 相關條目:與條目相關的車型或車種可於此列出。
  • 參考文獻:請列明來源!
  • 外部連結:可連接其他維基計畫或是未達可靠來源門檻的百科性資源

條目內容 不合適的內容

  1. 愛好者內容
    • 鐵路車輛:請不要將車輛車次運用、車號機務段分配、改造期程、交車期程等瑣碎資訊加入條目內。
    • 客運/公車車輛:請勿將領牌車號、行駛路線、停靠站牌等瑣碎資訊加入條目內。
    依據:維基百科不是不經篩選的資訊收集處-說明書
  2. 大量的短條目:通常一個較大的條目能提供對主題更有條理的介紹與背景聯繫。當大條目能做到時,請不要創建大量小條目。理想的條目是既不過大,也不過小。
    依據:維基百科的條目大小指引
  3. 過多的圖片:請勿於條目內放置各車號的照片,於資訊框模板一張代表即可,其他照片則放入共享資源並於底下納入共享資源連結導引。
  4. 原創研究內容:原創研究內容建議寫在維基學院內。
    依據:非原創研究

備註

  1. ^ 此指大客車、巴士,不含小客車、計程車,小型車請參見汽車一節。

因討論被機器人存檔,且尚未完成討論故接續提案,部分內容已依照上次討論提議更新--🚊鐵路Railway 2022年2月20日 (日) 05:24 (UTC)

似乎沒有通知成功,重新標註一次@owennson心平星辰一片楓葉BIT0865Bus FollowerMys_721txNryaLuciferianThomasGhrenghrenSickManWP--🚊鐵路Railway 2022年2月21日 (一) 12:56 (UTC)
(+)支持,另外建議增加關注度方針。--Nrya ✰沿路看風雨漫漫 2022年2月21日 (一) 13:02 (UTC)
@Nrya:閣下的意思是再額外建立關注度方針、於此方針中加入還是於NT:T中加入?--🚊鐵路Railway 2022年2月21日 (一) 13:26 (UTC)
“行文结构”的“参考文献”一条,部落格的消息确实不敢保证真实性,但是营运单位的内部文件……抱歉,中国大陆有不少地铁列车都没法不用它,参见武汉地铁DKZ8型电动车组的参考文献。--BIT0865 · Discussion · 燕房线永远的神! 2022年2月21日 (一) 13:32 (UTC)
@BIT0865:噢....若將「檔案」更換成「公文」呢?呢因為臺灣的車輛條目經常出現使用短期且快速更新的內部資料編輯愛好者內容,當初使用檔案一詞是為了阻止此狀況,而這些引用屬公文電報,更改引述應該可行吧0.0--🚊鐵路Railway 2022年2月21日 (一) 14:08 (UTC)
內部文件關鍵應該是非公開的文件。公開文件是沒問題的,這種文件應該是可以網站找到,或者圖書館可以找到的,而不是那種要愛好者拍一次,再上傳才可以找到的的文獻。「武汉轨道交通一号线一期工程车辆使用维护说明书」這種文件雖然是官方的,但是理論上不外傳的吧,這樣的話其實不應該用。--Ghren🐦🕑 2022年2月22日 (二) 06:11 (UTC)
協助標註@BIT0865--🚊鐵路Railway 2022年2月23日 (三) 10:30 (UTC)
但是如果没有那本说明书的话,那个条目我可以直接提删了——因为没加说明书的内容之前条目里面确实没什么东西——很多地铁列车的小条目都有这样的遗留问题。--BIT0865 · Discussion · 燕房线永远的神! 2022年2月23日 (三) 11:32 (UTC)
还有就是,“而不是那种要爱好者拍一次,再上传才可以找到的的文献”……那我甚至可以退出维基了,请看这里的“各种 VVVF 铭牌”。--BIT0865 · Discussion · 燕房线永远的神! 2022年2月23日 (三) 11:34 (UTC)
@BIT0865:若逆向搜索能搜索到可靠來源則直接使用新的可靠來源,應該很多東西都是逆向搜索找到正確的參考資料,不一定要以照片為唯一來源--🚊鐵路Railway 2022年2月23日 (三) 14:57 (UTC)
有文献可查的话,能不拍铭牌就尽量不拍,铭牌充其量用作保底,典型的例子是广州地铁A1型广州地铁A5型。但是像DKZ16的情况,① 太平湖车辆段有介绍各种铭牌的小册子,② 车辆段的小站台边上也可以经常拍铭牌;但是不用这两种方法,(在将铭牌照片传到维基共享资源之前)根本搜不到 MAP-184-75VD177,就比较为难了。--BIT0865 · Discussion · 燕房线永远的神! 2022年2月23日 (三) 15:29 (UTC)
甚至于,有时查到的某个型号也不能确定属于哪种车型。比如 MAP-184-75V208 可能属于四种车的一种,MAP-164-15V230 可能属于两种车的一种,这两个型号都是单一来源,不去问员工的话,没有其他来源协助确定,但是问员工却不巧又出现了困难。所以说白了,新车到段之前就把车底下查完真的很重要。--BIT0865 · Discussion · 燕房线永远的神! 2022年2月23日 (三) 15:35 (UTC)
大致(+)支持相關方針改動。很抱歉由於健康問題(右眼失明)本人不太有時間參與相關方針的建設。--SickManWP邀請您加入❤️邊緣人小組·🖊️簽到 2022年2月21日 (一) 15:18 (UTC)
支持。-Mys_721tx留言) 2022年2月21日 (一) 17:36 (UTC)
(+)支持:支持另建方針。呈上,如果中國大陸境內有此情況,那可能就採取共用大架構,另立小特別款?畢竟台灣這端出現在拿未確定是否可公開外流的台鐵內部行車電報來放此舉應不妥;圖片部分車號是指大的編組,舉例以言之,TEMU1000型全編8輛,放這8輛圖片可,但每一編組(TEMU1001+1002~1015+1016)均放或可議,畢竟適量的放圖片有助於閱讀跟版面配置,其他放共享資源;車輛車次運用、車號機務段分配、改造期程、交車期程等這些就放入學院吧,維基是阻止不了的,那就面對現實導入比較可行的維基學院吧,以上相關資源則在條目內設連結引導。消波塊留言) 2022年2月22日 (二) 01:47 (UTC)
这里展开说下“中國大陸境內有此情況”:
① 不少爱好者遇见新车(尤其新车)只顾着看外观,没有查证设备的意识,等到新车上线了再去查往往非常困难。
② 中国大陆没有专门介绍地铁或者铁路车辆的报刊杂志,因此情况 ① 的直接后果就是不得不求助于员工。
③ 即便是求助于员工也不能保证马上得到反馈,尤其是铁路车辆,一些动车组的裙板非常重,不是所有员工都愿意动不动打开裙板去看里面有什么。
--BIT0865 · Discussion · 燕房线永远的神! 2022年2月23日 (三) 12:21 (UTC)
@BIT0865:關於第二點據在下所知有《鐵道知識》期刊,國際標準書號為ISSN 1000-0372,如北京地铁DKZ13型电动车组剛剛在下已協助增加來源。--🚊鐵路Railway 2022年2月23日 (三) 13:16 (UTC)
感谢添加文献,但是《铁道知识》似乎不如中国铁路总公司的《铁路机车概要》详细,里面应该没有记VFI-HR2420E和SVI-H116A(铭牌上有写,但是铭牌太小并且靠近车厢底板,所以站台上看不见,只能问员工)。--BIT0865 · Discussion · 燕房线永远的神! 2022年2月23日 (三) 13:30 (UTC)
@BIT0865:若是反向搜索來源應該可以吧...知道型號和廠牌之後去製造商官網找相關資料。--🚊鐵路Railway 2022年2月23日 (三) 14:07 (UTC)
你想得太天真了:DKZ13的牵引系统,《日立评论》倒是详细介绍了工作原理,但是对型号只字不提,不知何故;《东洋电机技报》里有关 SFM04/04A 和 DKZ32/33/34 的情况亦如是,它们的VVVF型号全是靠格式规律插值推出来的,然后再靠铭牌确认。--BIT0865 · Discussion · 燕房线永远的神! 2022年2月23日 (三) 15:18 (UTC)
@BIT0865:若查無可靠來源算原創研究,可能要改寫到維基學院了。--🚊鐵路Railway 2022年2月26日 (六) 07:39 (UTC)
補充:回復上面,問員工也算原創研究--🚊鐵路Railway 2022年2月26日 (六) 10:02 (UTC)
情况很严峻啊,我和 @LuisRichmond 很早就燕房线DKZ70型的条目讨论过原创研究的事,结果他一副无所谓的样子,我也没辙。BIT0865 · Discussion · 燕房线永远的神! 2022年2月26日 (六) 11:06 (UTC)
还有就是:DKZ4RG6023-A-M06C02VFI-HD1420B我觉得不算原创研究。--BIT0865 · Discussion · 燕房线永远的神! 2022年2月26日 (六) 16:00 (UTC)
@BIT0865:若真的沒辦法符合維基方針的內容就移至維基學院吧…,臺灣近期也是有很多內容移到學院。這種找不到來源的資訊,臺灣條目也有遇過,現在大部分都移到學院了。--🚊鐵路Railway 2022年2月26日 (六) 16:53 (UTC)
現在主要討論的是條目的整體架構,若整個條目或是部分內容都沒有適合的來源,就如上的方法解決吧…0.0
這邊邀請上面同樣有回覆此問題的@Ghrenghren一起討論。--🚊鐵路Railway 2022年2月26日 (六) 17:05 (UTC)
(+)支持,方针内容全面。--一片🍁枫叶展望未来 2022年2月22日 (二) 09:37 (UTC)
(+)支持,但應為內容指引級別而非方針級別,關注度同。--路西法人𖤐 2022年2月22日 (二) 10:45 (UTC)
(!)意見 可以引导爱好者将相关内容发布至维基学院。另认为应当为内容指引而不是方针。--Yinyue200留言) 2022年3月30日 (三) 17:19 (UTC)

🕗 公示7日,2022年3月13日 (日) 07:52 (UTC) 結束:贊成者多數,且7日無新留言,進入公示期。--🚊鐵路Railway 2022年3月6日 (日) 07:52 (UTC)

通知@owennson心平星辰一片楓葉BIT0865Bus FollowerMys_721txNryaLuciferianThomasGhrenghrenSickManWP@Qazwsaedx--🚊鐵路Railway 2022年3月6日 (日) 08:54 (UTC)
有些部落格的內容其實不錯且有公信力(例如[1]),不能當成來源有點可惜。--Poem留言) 2022年3月6日 (日) 15:15 (UTC)
🕗 暫停公示:公示期間有新提議,故暫停公示並進行討論。--🚊鐵路Railway 2022年3月6日 (日) 16:33 (UTC)
暫時來說比較半吊子,觀望下。--Ghren🐦🕐 2022年3月7日 (一) 05:32 (UTC)
@Ghrenghren:雖然目前尚未很完全,因鐵路條目近期較混亂,在下的想法是將最大宗的共同問題先行初步整頓,預計後面還會再提出其他車輛或細項,希望在台鐵的新車交車前先有個指引約束內容,避免與EMU900EMU3000條目一樣混亂。--🚊鐵路Railway 2022年3月7日 (一) 14:47 (UTC)
部落格本身就是用戶生成內容,出了引述觀點外幾乎完全不能用。--路西法人𖤐 2022年3月8日 (二) 02:46 (UTC)

且慢。抱歉有點久沒有登入維基百科。重點,本人想針對客運/公車車輛做些修正:
  1. 關於草案上文中的使用「資訊框」部分,若草案真的實行,代表舊有的翻掀式資訊需全部打掉重練。則請問是由何君來實施全臺近百家客運業者的條目整理呢?或是維持現狀?
  2. 再者,本人找到了關於公車客運使用車種的可靠參考來源( https://www.mvdis.gov.tw/m3-emv-mk3/freeway/query ),行政院交通部公路總局的"公路客運公司列表",應該可行吧?以屏東客運為例,則該客運的使用車種依據為此( https://www.mvdis.gov.tw/m3-emv-mk3/freeway/query?method=queryCarDetailByDisplaytag#anchor ),若此方案可行,本人可協助補充於各客運上。
  3. 移動到維基學院的問題:本人發現@鐵路君最近移動了一些客運的使用車種,但本人看見的是許多紅連,覺得跟維基百科的相互連結有大落差。


最後:可否請@鐵路1延後公示時間? -- Bus Follower留言) 2022年3月6日 (日) 15:42 (UTC)
Bus Follower君留言連結是公開資料,且來源為政府機關,是可靠來源。Poem留言) 2022年3月6日 (日) 16:09 (UTC)
@Bus Follower:1.翻頁式排版不易閱讀,且不符合維基基礎格式應盡量改善,可參見第三點的存廢討論紀錄。2.雖然閣下提供的參考來源為政府機關之可靠來源,但是車牌號碼實屬瑣碎資訊與愛好者內容,非愛好者並不會想要知道車號,另外在下建立主要是針對Category:巴士型號分類中的條目。3.使用車種在下查了編輯紀錄,在下僅移動豐原客運的內容,豐原客運的鏈結剛才以修整,而使用車種應該要使用表格式而非折疊式列表,且內容過於瑣碎,請參見Wikipedia:頁面存廢討論/記錄/2021/09/05#國光客運使用車種之討討論紀錄。--🚊鐵路Railway 2022年3月7日 (一) 14:37 (UTC)


了解,本人一看討論就知道大部分用戶對這塊是不怎麽友善的...不過君的意思應該是不要把使用/歷史車種寫在維基百科上,而是改寫至維基學院,對吧?如果是這樣的話,本人可以接受。也辛苦君對豐客的整理。但是關於什麼改成表格的部分,本人覺得還是先照舊吧...雖然舊的"畸形"式折疊式列表已不建議寫在維基百科上,但還是回到原點,若由君自己更新全台客運業的條目應該有困難吧
順帶一提,有看見君想要整理Category:巴士型號的分類,不過可笑的是,台灣最常見的DAEWOO BS120CN低底盤公車條目竟然被刪除了。本人發現只要有關於「公車」的條目幾乎都被提刪,不知道這種風氣在流行什麼,且刪除的原因都是什麼關注度不足的鬼,但事實上這些公車都滿街跑,怎麼會「關注度不足」?真是感到失望。當然這不是鐵路君的錯,關於其他編者的舊有固執思念,嗯。應該永遠也不會改吧,哈哈... --Bus Follower留言) 2022年3月9日 (三) 13:55 (UTC)
@Bus Follower:在下雖未找到提刪的討論紀錄或日誌,但從鏡像網頁的相關條目所看到的排版除了排版不符合編輯手冊,另外車輛介紹完全沒有列出任何參考文獻,若被關注度刪除據在下所知另外可能就是查無相關文獻或未提供相關文獻。在下主編的是鐵路相關的條目,公車的條目很不熟悉,也很難幫忙改善0ω0--🚊鐵路Railway 2022年3月10日 (四) 16:18 (UTC)
Wikipedia:頁面存廢討論/記錄/2021/07/23#大宇BS120CN。--Ghren🐦🕛 2022年3月10日 (四) 16:28 (UTC)

鐵路1讨论 | 貢獻) :
你好,不知道為什麼,最近才看到這個討論。作為一個大規模刪減香港巴士路線條目的編輯員(詳見九龍巴士1-30號所有路線),看到這篇討論後,發現有超過50%內容可以刪減,包括行車路線、車站、用車限制(因涉及ABc綜合)、車牌,對嗎?
這樣刪減的話還有什麼可以表述?--HK5201314留言) 2022年3月9日 (三) 01:04 (UTC)
鐵路1讨论 | 貢獻):
順帶一提,早前可靠來源佈告版已將一個經常被引用的香港巴士愛好者網站列入防濫用保護器內,限制編輯者引用,不知你會不會提出更多網站供限制?--HK5201314留言) 2022年3月9日 (三) 01:17 (UTC)
在維基百科內找不到公共交通總方針,只找到交通車輛方針,請問這里會不會跟進公共交通總方針(如車站、路線、車型)?--HK5201314留言) 2022年3月9日 (三) 01:36 (UTC)
個人認為香港巴士的情況與海外有非常大的差別,車型是非常多元化(特別是1990年代至2010年代初),也可以證明路線歷史的變遷。如果要強硬刪除的話,個人認為有關條目失去了應有的意義。感覺中維對“瑣碎資訊與愛好者內容”的定義無限放大,並不是好事。--Wpcpey留言) 2022年3月9日 (三) 01:45 (UTC)
@Wpcpey:路線、車站可參見NT:T指引,用車若車型不多可參見環狀線 (台北捷運)#電聯車的方式,若車型較多可參見橫須賀線#使用車輛,在路線條目中列出車型與簡介,詳細介紹則再另外的主條目進行介紹。另外,此指引主要是針對車輛,路線已有NT:T,在路線的條目中羅列停靠站還算正常,但是再車輛的條目再次出現行駛路線的車站就顯得過於重複,用車可稍微提及行駛路線與路線簡介,但不篇幅不要太長,不然就變成不是介紹車輛而是介紹路線,車牌號碼的部分,除愛好者外,一般民眾不太會去注意,且車牌號碼只要轉讓/轉手可能就又會更換一組號碼,屬不穩定的資訊,原創研究的內容應寫到維基學院,不是百科。--🚊鐵路Railway 2022年3月9日 (三) 05:44 (UTC)
對於我來說,其實不是有特別多的可靠來源記載一個路線的用車變遷。香港來說其實來來去去都是那幾本巴士書而己,實際使用可以記載車型使用的巴士路線實際上就不多,沒必要加上這條規定。列出簡介應該沒有問題的,只要不將車型過於陳述和原創研究就沒問題了。--Ghren🐦🕚 2022年3月10日 (四) 15:04 (UTC)
@Ghrenghren::但最大的問題是,用戶HK5201314仍然認為“用車變遷”是愛好者內容而刪除。加上目前的環境,會有人花時間查看巴士書再記載車型使用嗎?而那幾本巴士書是在2000年代初出版,之後又有一段空白期。而路線使用的車輛也可以反映人口,地理環境和需求情況。香港的巴士路線用車情況不能夠與其他地方比較的。--Wpcpey留言) 2022年3月26日 (六) 14:09 (UTC)

🕗 延長公示7日,2022年3月21日 (一) 04:12 (UTC) 結束:經討論後新提議有其他方式可替代,故延長公示。--🚊鐵路Railway 2022年3月14日 (一) 04:12 (UTC)

  • @鐵路1:「客運/公車車輛:請勿將領牌車號、行駛路線、停靠站牌等瑣碎資訊加入條目內」,單是一個汽車車型的條目不會無故有「停靠站牌」這資訊吧。Fran·1001·hk 2022年3月16日 (三) 08:31 (UTC)
    @‪Fran1001hk‬:幾個月以前在下是曾經看過有車型條目內還羅列停靠站牌0.0--🚊鐵路Railway 2022年3月16日 (三) 09:02 (UTC)
  • 且慢。抱歉有點久沒有登入維基百科。重點,的士也是一種公共客運,但是使用車種如豐田Hiace馬自達6等根本不可能依照這個架構去寫,這個指引未有考慮到私人和公共客運兩棲車種的情況。--Maccomcre留言) 2022年3月20日 (日) 23:34 (UTC)
    @Maccomcre:由於計程車與一般私家汽車使用車型相同,關於汽車稍後會有另一波的提議,目前正在準備中。--🚊鐵路Railway 2022年3月21日 (一) 12:12 (UTC)
    不同意這樣區分,巴士和的士都可能用上私家車型,而且像是豐田Coaster巴士車型都不應該是這種架構。--Maccomcre留言) 2022年3月28日 (一) 07:53 (UTC)
    @Maccomcre:若以載客量區分,大客車適用巴士,小客車、計程車以汽車為主呢?--🚊鐵路Railway 2022年3月31日 (四) 03:07 (UTC)
    補充:在下主編鐵路相關條目,客運、計程車不是很熟悉,若閣下有跟更適合的指引條文,還請直接提出,感謝。(•‿•)--🚊鐵路Railway 2022年3月31日 (四) 03:31 (UTC)
    不同意以載客量區分,像是VDL DB300的大巴其實跟豐田Coaster的小巴的模式相似。而且VDL DB300這種大巴士車型都不應該是這種架構。--Maccomcre留言) 2022年4月6日 (三) 23:41 (UTC)
    @Maccomcre:還請閣下提出條文,在下已想不到如何修改條文,公車條目在下不在行。--🚊鐵路Railway 2022年4月7日 (四) 03:16 (UTC)
    就以臺灣的法律來看,是以載客量區分車輛類型,不分客運用還是計程車用。--🚊鐵路Railway 2022年4月7日 (四) 03:19 (UTC)
User:鐵路1,有個小問題,類似香港小巴這種型式的交通會否納入?又,渡輪船隻飛機直升機之類交通可否納入?--owennson聊天室獎座櫃) 2022年3月22日 (二) 06:16 (UTC)
@Owennson:小巴也算是大客車,見[2],只要座位10人以上都算,目前指引名稱是交通車輛,若加入可能要改成交通載具的了--🚊鐵路Railway 2022年3月22日 (二) 06:32 (UTC)
User:鐵路1,個人對地鐵使用車輛內容直接放入路線條目有異議,畢竟有可能出現幾條地鐵線共用同一個車型。而且搞模板、分類時也十分不便。還是建議一個車型一個條目較好。--owennson聊天室獎座櫃) 2022年3月24日 (四) 00:42 (UTC)
@owennson  捂脸這根本已經不是維基的格式準則了…。直接修正就好了,另請教有哪些條目?0W0--🚊鐵路Railway 2022年3月24日 (四) 04:02 (UTC)
那就好,不是範圍內。因為我想幫上海地鐵03A02、04A02型建立條目,這種橫跨兩線的車型是不可能也不應重定向到路線條目的。--owennson聊天室獎座櫃) 2022年3月24日 (四) 05:08 (UTC)
(!)意見@owennson:若命名空間是模板,直接移動不留重定向後將內容更正即可,若是拆分在2個頁面的則直接除內容貼到新條目內吧。--🚊鐵路Railway 2022年3月24日 (四) 05:50 (UTC)

鐵路1讨论 | 貢獻) :
救命!原來我已有半年沒有參與香港巴士愛好者內容回退事宜,發現有大量ip用戶重新加入愛好者內容,單憑我一人之力無法處理這些內容,請問可否代為申請大規模限制ip或沒有自動確認用戶編輯交通模版及號召編輯員進行刪減?否則只好放棄數以千計的愛好者內容回退。--HK5201314留言) 2022年3月26日 (六) 08:53 (UTC)
    1. HK5201314這裏是指「車輛條目」,不是「路線條目」。
    2. 如何限制?除非把所有維基百科條目半保護[開玩笑的]Fran·1001·hk 2022年3月26日 (六) 09:35 (UTC)
      @Fran1001hk
      Yes,將巴士路線條目半保護,或號召編輯員都可以。
      畢竟需要刪減愛好者內容的數量太大--HK5201314留言) 2022年3月26日 (六) 11:15 (UTC)
    • HK5201314我想如果按閣下所說,其實不止香港,世界其他地方的巴士路線條目應該如你般「刪減愛好者內容」,可是條目數量會是很多很多(我也无法統計)。如果閣下只針對香港,只會引發更多爭議。Fran·1001·hk 2022年3月27日 (日) 06:04 (UTC)
      @Fran1001hk
      你大可以問問@DarkWizard21,他在香港交通模板的刪減動作完全獲得管理員的支持及認可。沒有任何管理員可以對他作出懲罰,所以如果單針對香港,不會引發爭議。--HK5201314留言) 2022年3月27日 (日) 06:57 (UTC)
      • HK5201314編輯模板本身會影響極大量的條目,除非是小修小補,否則未有共識而刪減裏面的內容會有挑起編輯戰風險。舉個例子,如閣下把模板:Infobox bus route中的Data14和16(即所屬車廠和路線用車)兩欄逕自刪去,便會有挑起編輯戰的風險。Fran·1001·hk 2022年3月27日 (日) 11:31 (UTC)
        @Fran1001hk
        請問你可否提供來源證明留下Data14&16的意義?--HK5201314留言) 2022年3月27日 (日) 12:58 (UTC)
        HK5201314DarkWizard21的刪減只限於香港交通模板,影響的條目僅局限於香港。可是,使用模板:Infobox bus route的條目不止於香港,还有中國大陸和其他地区,你進行任何刪減動作便會影響海量條目。Fran·1001·hk 2022年4月19日 (二) 02:09 (UTC)
個人認為“用車變遷”並不是愛好者內容,明顯是巴士路線條目基本的內容吧,根本不應該刪除。--Wpcpey留言) 2022年3月26日 (六) 14:09 (UTC)
@Wpcpey
當然以為用車變遷不是愛好者內容
只不過現時用車型號、車牌及車廠屬於愛好者內容。
如果單刪減上述三項內容,爭議性應該不大。--HK5201314留言) 2022年3月27日 (日) 06:59 (UTC)
個人認為用車型號是不可缺少的內容,特別是在香港的巴士路線,80年代至2010年代中有非常多類型的巴士在同一路線服務。其他地區和國家也沒有香港這樣的情況。--Wpcpey留言) 2022年3月27日 (日) 13:27 (UTC)
@Wpcpey
來源?這些內容很容易判為愛好者內容,更何況每一款巴士原則上沒有指定行駛哪條路線
舉個例,上年秋季某日西貢鄉郊發生水浸,ITtalk 報導原本派出的雙層巴士全部改為單層巴士,車款五花八門,請問這些每日不同的資料寫入合適嗎?
(&)建議
我在上面講過,不改動用車變遷,畢竟涉及歷史問題
而家IG咁多巴士記錄者,問佢哋攞幾幅相證明曾經使用相關車型咪ok囉(後以gallery形式顯示),當用車變遷就算啦(曾經),用不著寫入data16,因為沒有硬性規定一定要使用這款車,而寫得入data16的是該路線指定使用該車款。--HK5201314留言) 2022年3月27日 (日) 14:20 (UTC)
你說不改動用車變遷,但是閣下在去年在多條巴士條目已經刪除有關內容了。更甚的是那些巴士記錄者會願意拿出照片到維基證明嗎?特別是80年代至2010年代中那段時期。本人建議用不同年代描述主要車型(差不多5-10年為一個週期)。不需要再將資料細分到每日/每月,這樣就真是愛好者內容。--Wpcpey留言) 2022年3月27日 (日) 14:29 (UTC)
@Wpcpey
如果有相片會比較合適,使用文字會有紙上談兵的感覺,有作故事的可能,畢竟無法確認真偽。
況且不是有一本書講述80-00年代的用車變遷,引用isbn 應該不是問題。
如果有人在HKItalk以CC By Sa 3.0徵集照片,應該很多人支持,畢竟有推廣的可能,況且最後還要標示相片是來自相關人士的page,變相可協助他們增加page的關注度。--HK5201314留言) 2022年3月27日 (日) 14:42 (UTC)
鐵路條目有規格與構造和重大事故,但是公車條目就沒有?這是按什麼邏輯定的?十分不解。--Opky9407留言) 2022年4月13日 (三) 11:53 (UTC)
@Opky9407:在下是參照目前現有條目格式訂的,參照條目也不多,可能疏漏了,公車條目在下不是很熟悉(• ▽ •;)--~~--🚊鐵路Railway 2022年4月14日 (四) 01:38 (UTC)
已增加。--🚊鐵路Railway 2022年5月2日 (一) 05:11 (UTC)
建議「行文結構」一章參考电子游戏条目指引,在開頭加上類似的一段話:“本節介紹了幾類條目的結構,實際條目的分節方式和標題無需完全對應下文。若您的條目有特殊之處,請放手調整,不必拘泥於本文。 ”。條目不必强制統一格式,畢竟有些條目會有其特殊的地方。--Jhstriver留言) 2022年4月24日 (日) 09:07 (UTC)
@Jhstriver:感謝建議,已增加。--🚊鐵路Railway 2022年5月2日 (一) 05:11 (UTC)

🕗 公示7日,2022年5月9日 (一) 05:15 (UTC) 結束:7日無新意見,且主文變動不大,進入最後公示。--🚊鐵路Railway 2022年5月2日 (一) 05:15 (UTC)

(-)反对:到底你是怎樣參照條目的?上面有人給出的公車條目,其實有寫規格和構造,反而沒有重大事故,但是你卻在公車車輛那裡加了重大事故,規格和構造卻沒有,完全不明白為什麼會有這樣反過來的操作?感覺改得很隨便,所以只能反對繼續公示,需要再改。--Opky9407留言) 2022年5月8日 (日) 15:26 (UTC)
@Opky9407:感謝指教,已更新。--🚊鐵路Railway 2022年5月9日 (一) 04:10 (UTC)
其實,鐵路那部分都有問題,像是英國鐵路373型電力動車組都跟提出的架構有很大不同。條文太過以台灣為重心去制定,用在其它國家的車型應該會很容易出問題吧。要是問我怎樣修改,我寧可完全不要直接把行文結構定出來,因為各地和各類車型根本不可能完全共用同一個結構。只規定哪些內容是不能寫應該還要實際。--Maccomcre留言) 2022年5月9日 (一) 05:13 (UTC)
@Maccomcre:在下大部分是參照日本、香港、臺灣、韓國、中國大陸以及少數美國、印尼、越南鐵路車輛條目進行規劃,應該是少數車輛不適合吧...,若就少數車輛不適用可利用「本節介紹了幾類條目的結構,實際條目的分節方式和標題無需完全對應下文。若您的條目有特殊之處,請放手調整,不必拘泥於本文。 」這條應對修改ㄚ。--🚊鐵路Railway 2022年5月9日 (一) 12:52 (UTC)
(:)回應港鐵中期翻新列車新幹線E2系電力動車組日本國鐵D51型蒸汽機車等香港、日本鐵路車型都跟上面的架構有很大不同(JR東日本車輛形式裡面就有大部分車型都跟上面的架構有很大不同),所以是很多車型都不適合,而不是少數。如果很多車型都要當成有“特殊之處”去調整,那麼定出來的架構完全沒有意義,所以還是(-)反对。--Maccomcre留言) 2022年5月24日 (二) 15:52 (UTC)
(-)反对:擔心會有其他用戶會用此標準而進行大規模刪除,近年的環境已經趕走了很多人不願更新了。--Wpcpey留言) 2022年5月9日 (一) 12:59 (UTC)
在下建立初衷是許多新編輯加入不適合維基百科的內容或是格式不統一才提議的。--🚊鐵路Railway 2022年5月9日 (一) 13:56 (UTC)
問題是“不適合的內容”範圍越來越大,很多過去10多年來可以收錄的東西,由2020年起也不能再收錄。看看電視和鐵路條目就知道了。--Wpcpey留言) 2022年5月9日 (一) 14:16 (UTC)
有些是沒人清理就一直加下去,例如臺鐵的列車運用車輛配屬本來就不適合維基百科,是近期才清理到維基學院的。--🚊鐵路Railway 2022年5月10日 (二) 03:42 (UTC)

🕗 公示7日,2022年5月24日 (二) 17:47 (UTC) 結束:7日無新發言,公示。--🚊鐵路Railway 2022年5月17日 (二) 17:47 (UTC)

(+)支持建立相關規範--一個喜歡新興科技的維基人留言) 2022年5月18日 (三) 07:38 (UTC)
(+)强烈支持。不过可能存在一些因铁路交通工具的本地特殊性而需微调行文架构的问题,大概也应属于可接受范围?--         2022年5月21日 (六) 11:03 (UTC)
  • 竟然連支持的人都出現了疑問。其實再看開頭的那兩段說話已經很有問題,先是「統一格式將有助於閱讀及編輯維護上的便利性」,然後又說「請放手調整,不必拘泥於本文」,明顯前後矛盾的語句,讓人放手調整那麼就不可能是統一了。另外,本來提案人也承認了參考的條目不多,之後提案人對於結構的修改就好像見到什麼就加什麼的,其實每個條目都有很多不同之處,事實上很難舉出所有都用到的章節,與其這樣的大混雜,還不如上面有人說索性不要把結構釘起來,只告訴大家哪些內容是屬於愛好者等不適合百科全書,更來得實際。--Opky9407留言) 2022年5月24日 (二) 14:17 (UTC)
在下是主編鐵路車輛相關條目,對鐵路車輛較了解,大部分鐵路車輛應該都是可適用,公車相關的確是參考比較少--🚊鐵路Railway 2022年5月24日 (二) 17:12 (UTC)
引言有稍作修改了。--🚊鐵路Railway 2022年6月1日 (三) 01:07 (UTC)

🕗 公示7日,2022年6月8日 (三) 01:07 (UTC) 結束:7日無新發言,公示。--🚊鐵路Railway 2022年6月1日 (三) 01:07 (UTC)

  • (:)回應:「統一格式」和「同樣格式」根本沒有改變意思吧,改了跟沒改真的沒什麼差別,跟「請放手調整,不必拘泥於本文」的矛盾仍然存在,只能繼續反對。--Opky9407留言) 2022年6月7日 (二) 13:57 (UTC)
  • (:)回應:感覺完全無視了我提出的問題,我重複再提一次:「港鐵中期翻新列車新幹線E2系電力動車組日本國鐵D51型蒸汽機車等香港、日本鐵路車型都跟上面的架構有很大不同(JR東日本車輛形式裡面就有大部分車型都跟上面的架構有很大不同),所以是很多車型都不適合,而不是少數。如果很多車型都要當成有“特殊之處”去調整,那麼定出來的架構完全沒有意義,所以還是(-)反对」。--Maccomcre留言) 2022年6月8日 (三) 01:01 (UTC)
    "愛好者內容建議建議寫在維基學院內。 "确定这些爱好者内容是维基学院的收录对象么?--百無一用是書生 () 2022年6月8日 (三) 01:51 (UTC)
Shizhao,早前都沒留意到。放維基學院的條件是具有「研究」成分,不是愛好者內容就拋去學院的。--西 2022年6月8日 (三) 04:03 (UTC)
已修正原創研究部分,上面格式的部分在下在想幾天一下如何修改。--🚊鐵路Railway 2022年6月11日 (六) 16:53 (UTC)
@MaccomcreOpky9407ShizhaoLuciferianThomas:已進行修正,還請指教。--🚊鐵路Railway 2022年6月21日 (二) 15:04 (UTC)

🕗 公示7日,2022年7月7日 (四) 15:11 (UTC) 結束:超過7日無新意見,公示7日。--🚊鐵路Railway 2022年6月30日 (四) 15:11 (UTC)

鐵路1請同時於公告欄進行公示。—— Eric Liu 創造は生命(留言留名學生會 2022年7月1日 (五) 16:33 (UTC)
(:)回應:把「統一格式」改為「同樣格式」又再改為「相同格式」,真的不知道意思有什麼改變,跟「請放手調整,不必拘泥於本文」還是矛盾。還有為什麼鐵路條目加了車輛保存,但是公車條目就沒有加?這下子又出現了之前發生過的問題:這是按什麼邏輯定的?邏輯不明的制定方法那只能(-)反对。--Opky9407留言) 2022年7月7日 (四) 13:02 (UTC)
@Opky9407
  1. 相同與統一在下認為還是用差異,統一為強制規定,相同則非強制,使用非強制呼應「請放手調整,不必拘泥於本文」是合適的,若閣下有更好的說明方式還請指教。
  2. 保存車輛的部分,鐵路車輛依照過去閱讀與編輯過的條目增加,而公車條目在下參照Category:巴士型號分類內的條目,隨機看了數篇條目沒發現有此介紹章節,故無新增。
  3. 不一定鐵路有的公車就一定也要有阿...這樣一條指引內容就乾脆直接適用所有交通工具。--🚊鐵路Railway 2022年7月7日 (四) 15:34 (UTC)
補2:觀察約6、70篇左右。--🚊鐵路Railway 2022年7月7日 (四) 15:50 (UTC)
梅赛德斯-奔驰Vario這款巴士就有車輛保存。相同和統一的意思我覺得一樣,沒有強不強制的差別。還是維持反對定這種架構的想法。--Maccomcre留言) 2022年7月17日 (日) 07:49 (UTC)
已更改--🚊鐵路Railway 2022年7月18日 (一) 10:50 (UTC)
(?)疑問 “信息框:一般用用”这块是不是多了一个“用”。另外为什么铁路和公车的可靠来源说明不一样。--Yinyue200留言) 2022年7月20日 (三) 13:56 (UTC)
@Yinyue200:感謝提醒,已修正。公車的可靠來源有哪些在下不清楚,因此就沒有舉例。--🚊鐵路Railway 2022年7月20日 (三) 16:36 (UTC)

  公示7日,2022年8月4日 (四) 00:21 (UTC) 結束:超過7日無新意見,公示7日。--🚊鐵路Railway 2022年7月28日 (四) 00:21 (UTC)

  • 把相同改為相似,事實上沒有解決到我提出的問題,就拿回我之前提到的“港鐵中期翻新列車新幹線E2系電力動車組日本國鐵D51型蒸汽機車等香港、日本鐵路車型都跟上面的架構有很大不同(JR東日本車輛形式裡面就有大部分車型都跟上面的架構有很大不同)”,很大不同其實也意味著不相似,如果又是一大堆條目因為跟條文不相似而當成是有“特殊之處”來處理,那麼定來的架構也是沒有意義,所以繼續(-)反对,維持寧可完全不要直接把行文結構定出來的想法,只規定不能有哪些內容就夠了。--Maccomcre留言) 2022年8月3日 (三) 18:06 (UTC)
    @Maccomcre:就閣下所提與其他條目,在下觀察下來統整,基本上架構不外乎以下大綱:引言、資訊框、概要(概述、簡史)、規格構造(內裝、機電、塗裝、結構、編組…)、各代車輛(子型號、外銷型號…)與一兩小節針對該車特殊小節。如上閣下所提的條目也就是換了不同名稱與架構較分散介紹而已,例如E2系:「型式和車型」、「不同點」與「出國中國」可歸類在各代車輛內,「編組」可併入構造底下,「速度實驗」、「東北新幹線的高速化實施」與「今後計畫」可歸類在歷史內。指引主要是指引出建議大綱,不是要所有細節都要綁死。( π )题外话:此討論已經從元旦討論到現在已經足足8個月了,近期都是一週無人發言公示,然後又在公示結束前才又回覆,這樣時間拉距實在很沒討論效率,雖然可能大家平常時間很忙不常上線,但作為主提議的幾乎每次等到公示結束前才等到回覆感到無奈疲累疲😴,--🚊鐵路Railway 2022年8月4日 (四) 02:49 (UTC)

提议修改维基百科:防滥用过滤器

问题概述 目前,防滥用过滤器是反破坏的重要工具之一,隐藏过滤器日志和详情管理员和回退员都可见。
問題背景 此前曾出现过某些LTA可有效针对性地绕过防滥用过滤器的情况,尽管进行了快速的调整,但仍能多次被某些LTA破坏群在短时间内迅速绕过。
中文维基的回退员众多,既往任免门槛较低,因此可能会存在一定的破坏者通过GHBH策略或直接与回退员合作获取隐藏过滤器详情的情况。


(~)補充在过往的一些案例中,Tigerzeng等管理员观察到,破坏者未被新增的私有过滤器规则拦截而直接绕过了新增的那条规则。这是明确的监视过滤器更改并泄露过滤器规则,而非泄露日志详情的证据

我的解決方案 提议收紧可查看私有防滥用过滤器详情的人员,将其限制为管理员,隐藏过滤器日志对於管理員与回退员开放。
現行條文

用戶可以查看所有公开过滤器的詳情及觸發紀錄,而隐藏过滤器則只对於管理員与回退员开放

提議條文

用戶可以查看所有公开过滤器的詳情及觸發紀錄,隐藏过滤器日志对於管理員与回退员开放,而隐藏过滤器详情只对於管理員开放

此前的類似討論 Wikipedia_talk:防滥用过滤器#引入過濾器助理(EFH)權限
Wikipedia_talk:防滥用过滤器#进一步讨论“滥用过滤器编辑者”事宜
Wikipedia_talk:防滥用过滤器#有關防濫用過濾器

--PAVLOV 2022年5月25日 (三) 13:27 (UTC)

(-)強烈反对,隱藏過濾器詳情只對於管理員開放會大幅度降低高程度的反破壞,反破壞行動佔多數的非管理員用戶完全不知道過濾器在幹嘛的會很大程度降低透過過濾器監察破壞或找出錯判情況,也使用戶促使管理員更新過濾器以及監察管理員使用過濾器的情況變得完全不可能。至今仍然不少LTA傀儡被過濾器攔截而封禁,硬撞幾次撞出漏洞並不出為奇,不再開放隱藏過濾器詳情予反破壞的回退員而言弊遠遠大於利。--西 2022年5月26日 (四) 02:39 (UTC)
我不太感覺這種可能性存在。又不是剛執行OA過後,這種情況的出現機會非常小。你如果是7個月前來提案的話,我可能會支持。Sanmosa Χαίρε, ω χαίρε, Ελευθεριά! 2022年5月26日 (四) 06:14 (UTC)
亡羊补牢为时未晚,现在进行有效的重整也不迟。况乎OA有针对回退员的封锁或除权吗?
( π )题外话与主题无关,阁下能否解释一下曾经在删除讨论中,要对我请求基金会行动是基于什么?我只是步骤性提删,我的确不知道我是做了什么需要基金会来介入一下?--PAVLOV 2022年5月26日 (四) 20:48 (UTC)
  • (+)支持, 至少不能讓所有回退都接觸到。目前已有回退內鬼,公開af結構只會讓破壞者得利。--Temp3600留言) 2022年5月26日 (四) 15:52 (UTC)
    对答如下,兼答路西法人。
    既往某攻击性账号破坏群,很显然不是通过撞几次找出过滤器漏洞的,尤见QCHM的早期傀儡,(近期傀儡破坏方式改变,故略去)高度特征性绕过过滤器,且在多次小修补后仍能绕过,通过硬撞的可能性不高于(1-  可能)。
    近期,哈密瓜油的用户查核案件,查核到傀儡user:ST680让我们看到lta傀儡甚至可以通过GHBH策略轻松混到巡查员,随后沉睡。如果某lta用相同策略,亦可快速得到回退员权限,随后沉睡,至于有没有,心证即可。
    这类的沉睡傀儡甚至是用户查核亦难以发现的,见早期对QCHM的用户查核,该用户特异性地修改技术信息导致用户查核失效,下面的推论以及可能的做法说出来就有教导破坏的嫌疑了。--PAVLOV 2022年5月26日 (四) 21:03 (UTC)
    @Temp3600:此說是否屬實?如是,我感覺直接解任全體回退員能較快處理,反正安裝了Twinkle後實際回退功能不會喪失。Sanmosa Χαίρε, ω χαίρε, Ελευθεριά! 2022年5月27日 (五) 00:11 (UTC)
    提醒,系统级rollback和盖版本的编辑“回退”是两码事,详见WP:回退功能。——Sakamotosan路过围观 | 避免做作,免敬 2022年5月27日 (五) 01:04 (UTC)
    (*)提醒:回退员除了rollback权限外至少还有方便的unwatchedpages和supressredirect这两大方便权限。--MilkyDefer 2022年5月27日 (五) 03:18 (UTC)
    巡查員也有unwatchedpages與supressredirect這2個權限,而且申請門檻更低,也有一定數量的回退員同為巡查員,因此我感覺影響不大。真的需要unwatchedpages與supressredirect權限的非巡查員回退員可以申請巡查員權限。Sanmosa Χαίρε, ω χαίρε, Ελευθεριά! 2022年5月27日 (五) 04:34 (UTC)
    這點我是清楚的,但Twinkle機制與回退功能機制的效果其實差不太遠,所以我才說「實際回退功能」。Sanmosa Χαίρε, ω χαίρε, Ελευθεριά! 2022年5月27日 (五) 04:37 (UTC)
    “差不多”,指core-rollback可以绕过黑名单、过滤器,而盖版本编辑不能。——Sakamotosan路过围观 | 避免做作,免敬 2022年5月27日 (五) 06:03 (UTC)
其實我認爲解決這一問題,應當對回退員的申請門檻進行改革,過去中維申請回退權限只是申請人提供一些(至少五個)回退實例用於佐證對回退權方針、破壞方針等的熟悉程度。但是回退員也有查看标记为私密的过滤器的过滤日志、查看被标记为私密的防滥用过滤器兩項權限,在申請時恰恰卻忽略了私密過濾器方面的職業操守。倘若這一提案得到通過,就會出現像路西法人所説之大幅度降低高程度的反破壞等情況,同樣治標不治本。--紹💓煦意見箱 2022年5月26日 (四) 20:00 (UTC)
反对,舍本逐末。如果只是担心规则暴露且技术上可行,回退员取消查看规则的权限吧,私下请求并由管理员告知(比如经过邮件列表)。--YFdyh000留言) 2022年5月26日 (四) 20:04 (UTC)
技术非常可行。且这是目前最快的解决涉隐私的滥用过滤器暴露的方法。至于权限改革,或可日后再谈,因涉及权限改革之事往往在中维寸步难行。--PAVLOV 2022年5月26日 (四) 20:44 (UTC)
回退员的本职工作是批量运用回退功能,该功能的危害性相对不大(如上方用户的意见,TW也有回退,只是慢一些/不能绕过黑名单过滤器的限制等),也正是因为如此申请门槛才低,不涉及隐私问题。对于回退员来说,过滤器的日志记录了被阻挡的编辑的细节(试图添加/删除的内容,时间,用户名,摘要)等,对反破坏确实有益;但过滤器的代码本身对反破坏的贡献不见得非常大。上方有用户提到回退员查阅过滤器代码可协助管理员发现错判漏判的情况,但是:不见得回退员都熟悉正则表达式,以至于需要默认地给回退员这种权限;过滤器的错判漏判理应从结果(某笔适当/不适当的编辑->有/没有挡住)就能看出来。发现错误后除错和改错的任务可以让管理员一并完成,而无需回退员先除错,再交给管理员改错。最后,就算提高回退员门槛也无助于解决既有回退员中可能存在“内鬼”的问题。因此上,我认为“为过滤器查看权限的不当下放去提高回退员的门槛”,才是一种“舍本逐末”而且“治标不治本”的方法。--Antigng留言) 2022年5月27日 (五) 05:50 (UTC)
技术上说,abusefilter-log-private和abusefilter-view-private是两个独立、可单独配置的权限。另外事实上,依过往讨论的存档,当时社群“幾乎所有人同意可以給予某定用戶(回退員)查閱隱密過濾器的日誌,不過只有約一半的人同意可以給予某定用戶查閱隱密過濾器的詳情,其餘一半則認為只應由管理員查閱”。将非公开过滤器代码的查看权限和日志的查看权限一并给回退员,可能本来就是wmf那边执行社群意见时出错所致。--Antigng留言) 2022年5月27日 (五) 05:27 (UTC)
或者重提“过滤器助理”方案?——Sakamotosan路过围观 | 避免做作,免敬 2022年5月27日 (五) 06:05 (UTC)
本身我想提出这个,但考虑到引入一新权限的提议往往很容易在中文社群流产,而这类的权限调整则相对容易,故此先提出本提议。但阁下的提议非常有用,如阁下有空或可尽快起草。--PAVLOV 2022年5月27日 (五) 06:25 (UTC)
要是真的搞這個玩意,回退員的核心就只有回退一個功能,而實話和TW回退不是差特別多了。過濾器編輯的積壓已經放了一整年了,也好先搞好過濾器再說?--Ghren🐦🕒 2022年5月27日 (五) 07:10 (UTC)
本来巡查员/回退员/IPBE/巡查豁免/模板编辑/MMS之类的权限都分别只有一个核心功能。另外过滤器编辑请求积压与否与该提案的关系不大。目前即使回退员能查看非公开过滤器的代码,他们也没有修改权限。无论修改前还是修改后,决速步都在管理员这一边。--Antigng留言) 2022年5月27日 (五) 07:21 (UTC)
我會認為是反破壞的問題並不是在於什麼人能看到過濾器,而是過濾器的更新是否可以貼近破壞者的行為。你上面不是談到「而無需回退員先除錯,再交給管理員改錯」這事嗎?要是回退員能處理了簡單的前期問題,例如問題成立不成立之類的,我相信幫助還是會有的。如果你們真的打算要修的話,我想隱藏過濾器還是要解除掉一部份,例如Special:滥用过滤器/39之類的玩意,畢竟黑名單是公開的。--Ghren🐦🕒 2022年5月27日 (五) 07:44 (UTC)
我认为去检查过滤器规则的回退员不太多,拆分权限到单独的组或者渠道(如私密邮件列表)、工具(如编写于toolforge)会比较好。--YFdyh000留言) 2022年5月27日 (五) 18:54 (UTC)
(-)反对:查看过滤器有助于反破坏,意见同路西法人。桐生ここ[讨论] 2022年5月27日 (五) 08:53 (UTC)
查看过滤器“代码”何以有助于反破坏?--Antigng留言) 2022年5月27日 (五) 08:55 (UTC)
Antigng如某名用户的某笔编辑被96号过滤器或134号过滤器所拦截,此时若不知道过滤器实施细节,对于一般用户来说很难从日志中得到有意义的结论。--Yining Chen留言|签名页) 2022年5月29日 (日) 07:58 (UTC)
(-)反对:如此前有新手用户创建条目时被某私有过滤器拦截,经其求助后对照过滤器源码,最终找到被拦截的词汇为“垃圾”相关词语,经修改后得以发布。如果在这种情况下无法得知过滤器实施细节,那么想要从一篇文章中找到未知的“敏感词”会变得十分艰难。--Yining Chen留言|签名页) 2022年5月29日 (日) 07:58 (UTC)
(:)回應第一,遇到这种情况,如果条目质量没问题,帮助新手的普通用户完全可以在确认的前提下直接代新用户发布,同时及时报告给管理员修复错误;如果条目质量有问题,那么应向其指出条目质量的问题和改善方式,“不带金丝雀”并不是解决矿井下有瓦斯问题的方法。无论哪种情况都不需要教导新用户绕过过滤器;“教导新用户绕过过滤器”这一行为本身也存在风险。第二,退一步说,即使存在个别场景“非查看过滤器源码不可”——这里恐怕也没有人否认“查看过滤器源码”的价值。但问题回退员的本职工作是回退、反破坏,其低申请门槛也是围绕这一工作的特性而设计的。下放重要权限给低申请门槛的用户组不是没有利,而是很可能弊大于利,被有心人士利用(本人不止一次从站外渠道获悉有LTA获取过滤器规则的状况)。就好比即使不考虑WMF的限制,我们也不会将“用户查核日志”的查看权限下放给管理员或回退员,供社群监督查核权限的使用状况一样。--Antigng留言) 2022年5月29日 (日) 11:10 (UTC)
首先,AF应该是反破坏过程中十分有用的工具。而与CU不同的是,一般用户接触AF的概率应该要远远高于CU(除某些热衷于傀儡调查的用户及傀儡调查助理外),而且CU可能包含用户隐私信息,因此本人认为将AF与CU混为一谈可能并不妥当。第二点,目前是否有证据表明泄露过滤器信息的人是回退员而不是管理员?根据我的了解,在2020年-2021年期间有不只一名管理员被质疑为LTA提供相关信息(站内似乎曾有过相关讨论)。回退员数量约为管理员人数的3倍。换句话说,把这些回退员的abusefilter-view-private权限剥夺,未必能避免过滤器源码泄露。如果仅仅是因为某几名回退员的一些行为,便要剥夺所有回退员的相关权限,那么这对反破坏工作造成的困扰与过滤器源码泄露造成的后果相比,很难判断孰优孰劣。以目前的情况,提升回退员门槛或设立AFH/AFM貌似是更佳的选择。( π )题外话:据我所知,代替他人发布文章可能会存在一些版权方面的隐患与问题。--Yining Chen留言|签名页) 2022年5月29日 (日) 12:11 (UTC)
1. 提案人与本人都不否认“AF应该是反破坏过程中十分有用的工具”,但认为这种有用应该且仅应该体现在“通过过滤器日志查阅疑似滥用者的编辑细节”上。而本提案也无意于剥夺回退员查阅过滤器日志的权限,而是旨在剥夺回退员查阅过滤器代码的权限。然而您以及上方提出反对意见的用户却始终未阐明“剥夺回退员查看过滤器代码”的权限会对“反破坏工作”带来何种“困扰”。也如上方列出的旧讨论存档所示,社群甚至从一开始就没有共识将过滤器“代码”的查看权限下放给回退员。2. 本人过去从未看到有用户发起讨论来质疑管理员向LTA提供过滤器代码(LTA在站外途径提供的信息除外),如您有请列于此处供评估。此外,单纯比较管理员和回退员“人数”的意义并不大,两者的“遴选标准和门槛”均存在较大程度的差异。3. 最后,“设立AFH/AFM”与本提案不是二选一的关系。正如提案人所述,后续提案中可以考虑设立此类职位。--Antigng留言) 2022年5月29日 (日) 12:50 (UTC)
(:)回應对这一提议下的诸多疑问做一个总体的回复。过滤器代码和过滤器日志本身是不同的,看过滤器代码则可导致可看到所有的过滤词汇,看过滤器日志相当于你能看到diff,看到他的编辑是如何的。
如果你能看到他的编辑是如何的,仅仅剥夺了看过滤器代码的权限,这难道也会降低反破坏的效率吗?
本提议与提升回退员门槛、引入AFH等并不矛盾,只是提升门槛、引入AFH等或许可事后再论。--仁爱亲诚PAVLOV 2022年5月29日 (日) 16:24 (UTC)
提门槛和引入AFH此类提案在可以预见的一段时间内很难达成共识。--Yichen Ding留言|主账户) 2022年5月30日 (一) 14:56 (UTC)----Yichen Ding留言|主账户) 2022年5月30日 (一) 14:56 (UTC)
提供防滥用过滤器规则(ADM2)的第16条(设置过滤器私有的事由)、第18条(私有过滤器的泄密报告)作参考。--Kirk # 2022年5月31日 (二) 11:17 (UTC)
在配套措施完善之情形下,我認為應該考慮將權限交還予管理員。濫用過濾器內容之洩漏,對於本站反破壞工作之威脅明顯較嚴重。—— Eric Liu 創造は生命(留言留名學生會 2022年5月31日 (二) 15:08 (UTC)
首先更正本案的“问题背景”。在过往的一些案例中,我(和其他几位管理员)观察到的是,破坏者未被新增的私有过滤器规则拦截而直接绕过了新增的那条规则。这是明确的监视过滤器更改并泄露过滤器规则,而非泄露日志详情的证据。其次,回退员的门槛过低确实是一个问题,但是现在来提高门槛一不能解决现任回退员中有不可信任之人的问题,二涉及回退员这个权限本身的定位,又需要更多讨论。从回退权限本身反破坏的工作范围来说,协助新手编辑也不是回退权限的目的。查看过滤器拦截日志已足以排查有问题的编者并追踪回退。因此(+)支持。--Tiger留言) 2022年5月31日 (二) 21:55 (UTC)
限制AF源碼對反破壞有影響是不錯,但如果LTA能看到源碼,那反破壞簡直就無法工作下去了。--Temp3600留言) 2022年6月1日 (三) 01:36 (UTC)
前述讨论多次提到过滤器助理的问题。但感觉单设过滤器助理似无必要。这里提供一个思路,考虑到反破坏工作内容的相关性,可以令傀儡调查助理当然成为过滤器助理。--Kirk # 2022年6月2日 (四) 10:56 (UTC)
(-)強烈反对为傀儡调查助理增加特权。从最初的讨论中就已经确定“傀儡调查助理无任何别于其他用户的特权”。如果有AFH,那么就应该把申请相关权限的权力扩展到所有用户,而不应该只是限定于只有几名特定的用户才能有申请相关权限的权力(毕竟反破坏的范围十分宽泛,有多项反破坏工作与AF有直接关联,而不仅仅是SPI)。--Yining Chen留言|签名页) 2022年6月3日 (五) 09:39 (UTC)
我的意見是如果涉及私隱問題,那在這裏討論是沒有任何意思的,應該直接在全域站點反映,然後讓他們立即移除相關權限。Sanmosa Χαίρε, ω χαίρε, Ελευθεριά! 2022年6月3日 (五) 13:40 (UTC)
(?)異議,應該直接在全域站點反映,然後讓他們立即移除相關權限?中文社群的事情在全域讨论很难成功有结论吧?--仁爱亲诚PAVLOV 2022年6月8日 (三) 07:30 (UTC)
如果是涉及到私隱問題的事情的話,不及時處理會引起基金會的法律責任。我覺得只要有證據證明確實引發私隱問題,他們不能不立即移除相關權限。Sanmosa Χαίρε, ω χαίρε, Ελευθεριά! 2022年6月8日 (三) 08:16 (UTC)
过滤器规则基本上不涉及用户隐私,只是反破坏层面的隐私。如果牵扯到隐私,没签署保密协议的管理员都无权接触了。--YFdyh000留言) 2022年6月9日 (四) 00:14 (UTC)
(:)回應
仍然抱持反對意見,我完全不認同撤除了回退員檢視私有過濾器的權限就能完全堵截破壞者獲得過濾器反破壞資訊。與其說回退員泄漏過濾器資訊,還不如說是他們已經清楚瞭解了過濾器的運作,直接各種花樣來擾亂。印象中早期該等破壞者曾聲稱有管理人員提供協助,但自從OA2021之後好像越來越少聽到這樣的聲稱,且有關的破壞者的破壞力度也明顯降低了許多。該等破壞者也曾在偽基聲稱持有某些(非維基媒體)站點的管理權和CU權,可以從此看到該等破壞者已經非常充分地瞭解如何鑽反破壞的漏洞,也非常清楚反破壞工具的限制。該等破壞者懂得迴避查核是否代表他們持有查核的資訊?
再者,本站的過濾器一直以來並未能設計到能阻擋破壞者的擾亂行為,且未登錄的編輯者都能在Special:AbuseFilter看到過濾器是否曾有變更,要知道有更新過濾器有多難?又請問自OA2021後你們觀察到哪些破壞者仍有看似完全瞭解過濾器的資料而「繞過過濾器」的破壞行為?我甚至想說,擋的過濾器都寫得不甚嚴密,何談「繞過」?近期又有多少LTA破壞行徑被寫進過濾器裡了?(心內知曉,不用回答)
PAVLOV又提及ST680的例子,在過往SPI的討論中應該也有說過,不論是兩個號都是他創、還是兩個號都是被盜了,都有被同一人在同一裝置控制過,同樣會顯示為  已确认。早於2021年4月已經聲明過兩個帳號的關係,如果是破壞者盜號同樣的密碼就能都盜了。從ST680出現前的其他查核可見,這兩個帳號從未被監管員查出,代表當時並大概率未被持有其他傀儡帳號的破壞者控制或使用。帳號安全問題則不論是誰都是同樣的問題,這個不會扯上只有回退員才會有這樣的風險。
由於我未看到近期(2022年來)明顯知曉過濾器資訊而繞過的情況,故仍不能支持此提案。此外@Yining Chen,你大概率理解錯了KirkLU的意思,他是說「當然成為」,並非「只有他們才能」,但我也是覺得不需要額外特定SPI/C是當然的AFH啦,如果設AFH,申請時管理員還是會按照其經驗和可信程度來判斷,SPI/C只是協助判斷可信程度的因素而已,不用直接特定當然擔任這些了。--西 2022年6月9日 (四) 07:27 (UTC)
@Temp3600。另外想看看Xiplus有沒有相關數據。另外,我可以給一個大膽的假設,就是回退員的帳號在自己不知情的情況下被入侵,使入侵者得以看到過濾器相關資訊。如果這個情況成立,所有回退員都會因安全性不能獲得保障而被除權;我之前請辭回退員權限也是因為這個緣故。Sanmosa Χαίρε, ω χαίρε, Ελευθεριά! 2022年6月10日 (五) 02:11 (UTC)
@Sanmosa:什麼數據?--Xiplus#Talk 2022年6月10日 (五) 02:13 (UTC)
@Xiplus:2021年與2022年潛在因知曉隱藏過濾器內容而繞過隱藏過濾器的操作。Sanmosa Χαίρε, ω χαίρε, Ελευθεριά! 2022年6月10日 (五) 02:16 (UTC)
怎麼可能有這種數據,也難以現在回歸去計算。--Xiplus#Talk 2022年6月10日 (五) 02:18 (UTC)
@Sanmosa这个要求不能做,就算有这类的数据,直接公布也是BEAN或是未经许可的信息披露。--仁爱亲诚PAVLOV 2022年6月12日 (日) 01:53 (UTC)
哎,其實我應該ping Tigerzeng的。Sanmosa Χαίρε, ω χαίρε, Ελευθεριά! 2022年6月10日 (五) 02:16 (UTC)
我相信提出這個問題的管理員們(包含我)根據他們使用過濾器的經驗,都覺得將其解釋為「過濾器規則被洩漏」比起「熟悉過濾器設計」、「得知過濾器已變更」更為合理。--Xiplus#Talk 2022年6月10日 (五) 02:31 (UTC)
(-)反对:一般用户也可以根据日志确定那些广告机器人有绕过滥用器的尝试方式,从而针对性的提议改进,隐藏并不能阻止机器人尝试其他方法绕过,但却能阻挡一般用户的可见性,等于把任务全交给管理员了。--脳補。◕‿◕。讨论 2022年6月14日 (二) 08:14 (UTC)
機器人?—— Eric Liu 創造は生命(留言留名學生會 2022年6月14日 (二) 09:36 (UTC)
我支持该权限的调整,并建议引入过滤器助手之类的职务。毕竟回退员没有看到过滤器详情的必要。为什么?因为回退员不一定看得懂RegEx(比如在下,虽然看关键字也能猜出一些)。有志于研究过滤器的回退员可以申请高阶职务。 ——魔琴 [ 留言 贡献 ] 2022年6月15日 (三) 05:03 (UTC)
?人都去哪了 ——魔琴 [ 留言 贡献 ] 2022年6月23日 (四) 07:15 (UTC)
我覺得一個比較可行的辦法是在取消回退員查看防濫用過濾器權限的同時,引入防濫用過濾器助理之類的職務供有需求者申請。Ericliu1912留言) 2022年6月23日 (四) 12:01 (UTC)
  • 看來是卡住了。較可行的方法是eric的大修方案。--Temp3600留言) 2022年6月23日 (四) 14:42 (UTC)
    • 但仔细考虑实际场景可能会发现,AFH引入中维后的实际应用可能会十分尴尬。假若该提案成立,那么任何申请AFH的请求都可用“无必要检查AF详情”来回绝(但问题在于查看AF详情是有必要的)。几乎无法找到任何合理的申请AFH理由。--Yichen Ding留言|主账户) 2022年6月24日 (五) 05:25 (UTC)
      不反对单独用户组。很多偶尔使用可以通过如WP:AR的机制查询(应有尽快响应,以及某些标准/机制减少曝光度),而熟练者通过申请自然而然(有LTA潜入的风险,但这是不得不承担,至少比现在更好)。--YFdyh000留言) 2022年6月24日 (五) 05:32 (UTC)

拆分权限

目前讨论有一个走向是取消回退员的“查看私有过滤器详情”权限(abusefilter-view-private)并设置新的用户组接收。我建议可以从“1.申请资格;2.申请理由”两方面斟酌,看如何既能满足需要此权限的用户,又能一定程度上保护私有过滤器详情不被泄漏。 ——魔琴 [ 留言 贡献 ] 2022年7月1日 (五) 14:04 (UTC)

(!)意見 不建议隐藏过滤器详情。倘若真的隐藏描述详情,部分回退员甚至可能无从得知这个过滤器是干什么用的。支持User:魔琴所总结的提高回退员申请门槛和重启讨论WP:EFH。 如果技术上可行,能不能给部分有实质性贡献且账号足够安全的回退员开放所谓的「防滥用过滤器简介」?与过滤器源码查看权限分开,并且简介可以写的比较空泛笼统(tips:不太了解具体的权限机制,不清楚回退员看的过滤器详情具体能精细到什么程度  囧rz……)——诚挚的 ZhaoFJx 2022年7月3日 (日) 11:17 (UTC)

現有回退員中可能已有「內奸」。提高往後權限申請之門檻無助於解決目前實際存在之問題。—— Eric Liu 創造は生命(留言留名學生會 2022年7月4日 (一) 10:19 (UTC)
但还是存在上面说到过的问题,开放EFH之后,这个权限的实际申请/应用场景是什么?----Yichen Ding留言|主账户) 2022年7月5日 (二) 14:50 (UTC)
场景是非熟练者(一般回退员)无需持有权限,以减少攻击面。并或许会促进一些讨论和流程。--YFdyh000留言) 2022年7月5日 (二) 15:23 (UTC)
检视破坏?维护?捉? ——魔琴 [ 留言 贡献 ] 2022年7月13日 (三) 17:22 (UTC)
我認為將權限分拆有助於專業分工。—— Eric Liu 創造は生命(留言留名學生會 2022年7月21日 (四) 13:50 (UTC)
(+)支持:個人支持劃分相關權限,在綜合考量相關功能實用性、公開程度必要性、用戶站務經驗和專業性、反破壞實務需求和可能的人力養成,以及授權信任機制等因素下,可考慮啟用固有之維基百科:過濾器助理權限方案,或是在現有基礎下增列進階回退員權限(姑且暫稱,若可能建議有個權限專屬圖示)。為期許具專業技術之可信回退員長期投入貢獻且強化相關授權機制,直接在現有的回退員權限加增類似「進階回退員」或「技術回退員」(暫稱)之類的區隔(比如在《維基百科:回退功能的額外功能》章節附近加增改寫),而具備相關條件的回退員若有實際需求,認為知道過濾器代碼詳情有助於自身的反破壞工作,且可以協助管理員維護甚至討論代碼內容,應可適當獲得授權。
綜觀以上站友討論,個人認為關鍵在於過濾器的代碼設計內容對所有回退員公開是否有益,而非回退員權限之申請和權能本身具備何種弊端,且單純提高該權限申請門檻,似已超過原先核心命題的「過濾器設計代碼公開爭議」,對於反破壞站務長期而言亦未必有益;因此我認為本質上應回歸過濾器代碼公開的對象範圍及是否有益於多數回退員行權和執行反破壞站務,進一步而言可考量是否有益於具經驗的可信用戶進一步探索深耕或發展過濾器設計維護相關領域,而獲權用戶的持權操守仍回歸「授權信任」相關問題。個人考量和理據如下:
  • 首先,就一般的使用者需求而言,我不認為需要了解此種過濾器設計專業,而目前而言了解相關專業亦非獲權之必備條件。一般回退員若僅需「反破壞」,實則看不懂相關程式代碼設計的話(比如敝人完全看不懂),通常能看到「過濾器日誌」便足夠,所以我認為讓真正有需要、了解相關專業、具豐富反破壞經驗且自認能對社群和站務有益的可信任用戶視實際需求申請即可。否則連一般反破壞都未必具足夠經驗,或不具程式代碼相關專業,我認為若說要了解代碼設計細節以有效分擔站務或反破壞,實在難說具足夠說服力。
  • 承上,因此個人建議規劃權限,比如直接採用過濾器助理之規劃;若社群對於新設該權限有所爭議,亦可考慮在現有基礎上直接於回退員權限增列「進階回退員」,申請條件可考慮為:「持續於反破壞站務活躍之回退員依實務需求提出申請,經至少一名進階回退員或具過濾器設計維護站務經驗之管理員支持,由具相關站務經驗之管理員綜合考評後授權;若授權申請由具相關經驗之管理員支持提請,則授權之管理員不得為同一人。當社群對申請人獲權具足堪憂慮之具體事由,或參與討論之進階回退員意見顯明歧異,則管理員不應授權。」(「活躍」標準可參考《維基百科:過濾器助理》另訂之)。
  • 對於「防濫用過濾器管理」頁面中提供的公開訊息(尤其是「所有過濾器」之動態列表),對一般用戶公開之作用以及對於反破壞之利弊,個人認為社群可斟酌衡量(個人傾向該列表不應被所有人看見)。
  • 最後,個人認為將過濾器設計代碼公開範圍略作規劃,並非保證過濾器訊息絕無外洩可能或此後可禁絕防堵相關破壞者,仍需仰賴獲權用戶自持自重。
以上為個人意見,供參。--Kriz Ju留言) 2022年7月26日 (二) 19:57 (UTC)
意见大致相同。申请条件还得待社群讨论。动态列表似乎不能隐藏。 ——魔琴 [ 留言 贡献 ] 2022年8月1日 (一) 06:36 (UTC)

#提議設立容許查看私密資訊的用戶組/flag。個人覺得既然直接移除權限不可能達成任何形式的共識,倒不如等候下方討論更好。--西 2022年8月5日 (五) 08:50 (UTC)

關於接下來的管理員投票

應上一次WP:500Wikipedia:投票/是否在管理員選舉啟用SecurePoll)的共識,社群已經試行了一次安全投票(Wikipedia:申请成为管理员/和平奮鬥救地球/第5次),但是接下來社群如何進行投票是沒有充份共識的,引至出現了這種問題。因此,希望大家認真討論一下:

  1. 接下來的「申請成為管理員」,以及是其他管理人員職務是否使用安全投票?
    1. 如果決定不使用,(除了是在原地打轉之外,)如何滿足、解決「阻止拉票和人身威脅」的問題。
    2. 如果決定使用安全投票,如何決定程序,時間,方針對應的調整也是需要考慮的。

希望社群討論。--Ghren🐦🕓 2022年6月5日 (日) 08:11 (UTC)

@Lanwi11233中文維基百科20021024Z7504Yining ChenATEricliu1912SanmosaOutlookxp。--Ghren🐦🕓 2022年6月5日 (日) 08:14 (UTC)
支持2,免得自己支持或反對被人議論紛紛。和平奮鬥救地球的選舉流程應該沒什麼大問題吧,一些人提名+正式投票。--中文維基百科20021024留言) 2022年6月5日 (日) 08:20 (UTC)
@Ghrenghren:(我倒是覺得你先等Steward公佈了正式投票結果以後才開這討論串比較好,但現在開也不要緊)我覺得之後繼續使用安全投票是必然的事情,雖説不可能阻止拉票,但不使用也阻止不了,而且人身威脅問題明顯是基金會與社群極度關注的問題,必須優先處理,而且我也不認為基金會方面會容許社群在人身威脅問題上開倒車。我覺得程序可以比照Wikipedia:申请成为管理员/和平奮鬥救地球/第5次來擬定,這樣能省卻不少麻煩。Sanmosa Χαίρε, ω χαίρε, Ελευθεριά! 2022年6月5日 (日) 08:28 (UTC)
問題沒法根除的情況下就選最好的一種解決方案。--中文維基百科20021024留言) 2022年6月5日 (日) 08:44 (UTC)
(我是本來是這樣打算的,但是有些人比較心急。)--Ghren🐦🕓 2022年6月5日 (日) 08:45 (UTC)
我個人支持繼續採用安全投票。不過基於安全投票需要籌備的時間相對較長,因此建議集中提名,一次過投,這樣比較有效率,比如可能一年兩次提名期之類的。--AT 2022年6月5日 (日) 08:57 (UTC)
一年一次應該也夠吧,但我考慮到Steward選舉的情形,也同意集中提名與統一投票期的舉措。Sanmosa Χαίρε, ω χαίρε, Ελευθεριά! 2022年6月5日 (日) 16:06 (UTC)
就籌備時間的問題來說,一年兩次或一年一次的區別應該不大。但相較後者而言,前者可讓有意申請或提名管理員的用戶不必等那麼久。-Peacearth留言) 2022年6月10日 (五) 20:44 (UTC)
事實上頻率還可以更高。沒有必要把選管理員搞得像在選監管員一樣。—— Eric Liu 創造は生命(留言留名學生會 2022年6月11日 (六) 13:52 (UTC)
作為兩次安全投票監票人,覺得有些事情是要提醒社群,在作出上述決定之前是必須考慮︰
是否允許使用Proxy︰以本社群組成部分而言,如果使用安全投票,禁止使用Proxy幾乎等於阻斷相當一部分合資格用戶參與投票,但在投票意向隱藏之下,允許使用Proxy將會大幅度減弱監票效果。
臨界狀況︰因為安全投票與傳統方法差異不少,若出現傳統上臨界狀況,即75至80%時,行政員幾乎無法介入去作出決定。例如使用中立票去判斷候選人是否當選。
以上。--J.Wong 2022年6月5日 (日) 08:59 (UTC)
禁止使用Proxy幾乎相當於不讓居住在中國大陸境內的人投票,貌似免proxy使用Wikipedia比較繁瑣。--中文維基百科20021024留言) 2022年6月5日 (日) 09:05 (UTC)
避免(可能的)不正确信息造成误导,折叠。--东风留言) 2022年6月8日 (三) 11:34 (UTC)
在登錄賬戶的情況下使用proxy投票會有什麼問題嗎?--中文維基百科20021024留言) 2022年6月5日 (日) 09:07 (UTC)
表现为部分投票用户使用IP相同或相近,有傀儡的可能。--东风留言) 2022年6月5日 (日) 10:50 (UTC)
過往情況下不是有投票有資格限制嘛,那安全投票可以自動阻止不符合資格的人投票嗎?而且以前投票的時候不也沒有限制proxy。--中文維基百科20021024留言) 2022年6月5日 (日) 11:06 (UTC)
但過去是明票,投票意向跟編輯紀錄都是一覽無遺……--J.Wong 2022年6月5日 (日) 11:18 (UTC)
讓監管員把參與投票的人都CU一遍?--中文維基百科20021024留言) 2022年6月5日 (日) 11:22 (UTC)
不太明白……--J.Wong 2022年6月5日 (日) 11:43 (UTC)
维基百科:用戶查核,總不見得不讓中國用戶投票吧。--中文維基百科20021024留言) 2022年6月5日 (日) 12:14 (UTC)
对投票用户全部进行查核理论上可行,因为即使存在相同或相近IP,使用设备存在差异也会生成  不相关,但这无疑给监管员增加了(极大)工作量,我感觉他们的回应可能不会很积极。--东风留言) 2022年6月5日 (日) 12:24 (UTC)
那正好可以藉著這個機會把查核權要回來。--中文維基百科20021024留言) 2022年6月5日 (日) 12:26 (UTC)
@中文維基百科20021024Wikipedia talk:申请成为管理人员/存档7中有説明基金會對於恢復zhwiki用戶查核權的要求:以安全投票進行選舉、用戶查核員任期制(任期為2年)、基金會定除權機制(直接看連結吧,我懶得打出來了)、強制接受基金會培訓、基金會定期稽核。我覺得先處理好管理員選舉問題以後才處理恢復用戶查核權的事情會比較有説服力。Sanmosa Χαίρε, ω χαίρε, Ελευθεριά! 2022年6月5日 (日) 15:54 (UTC)
真的建議兩位先去了解一下什麼是secure poll,然後再來討論。--J.Wong 2022年6月5日 (日) 12:45 (UTC)
我对代理这部分的理解是这样的,那可能并不正确。--东风留言) 2022年6月5日 (日) 13:23 (UTC)
中立票之意見是否會顯示,以協助行政員判斷結果?-Peacearth留言) 2022年6月5日 (日) 13:22 (UTC)
幾乎無法辨識留言是否由投中立票之用戶留下。--J.Wong 2022年6月5日 (日) 21:44 (UTC)
原來如此。這樣的話的確不太能用來協助判斷。-Peacearth留言) 2022年6月6日 (一) 03:21 (UTC)
安全投票的缺点是禁止使用Proxy的话就几乎等于不让居住在中国大陆境内的人投票,行政员也几乎无法介入去作出决定。--Lanwi1(留言) 2022年6月5日 (日) 13:56 (UTC)
vote.wikimedia.org在中国大陆似乎可以正常访问,但大陆用户可能很难适应在投票前先关闭代理,如要禁用可能很多用户会误操作。此外,这次安全投票也有可选填的投票附言,临界状况下行政员也许可以根据这些意见进行判断?但安全投票似乎很难延长,所以行政员可能只能判当选或落选,而没法延长投票了?--BlackShadowG Slava Ukraini! 2022年6月5日 (日) 15:04 (UTC)
vote.wikimedia.org在中国大陆不可正常访问,不用Proxy就无法投票。--Lanwi1(留言) 2022年6月5日 (日) 19:49 (UTC)
只受到IP污染罢了,hosts半直连。--Liuxinyu970226留言) 2022年6月21日 (二) 07:35 (UTC)
考慮到基金會在此前因為安全理由而要求中國大陸用戶自行請辭重要權限一事(注意當時基金會所提到的“安全理由”沒包括Proxy),我有理由認為基金會並不信任中國大陸用戶。另一方面,基金會一向並不鼓勵使用Proxy。雖然禁止使用Proxy相當於不容許身處中國大陸的人投票,我認為這是唯一保證投票安全性的辦法,而且基金會不會對此有任何意見。Sanmosa Χαίρε, ω χαίρε, Ελευθεριά! 2022年6月5日 (日) 15:47 (UTC)
我认为这是滑坡谬误。我有理由认为这个“有理由认为”的理由不充分。--YFdyh000留言) 2022年6月6日 (一) 11:58 (UTC)
還需要決定是否通知選舉人投票事宜。—— Eric Liu 創造は生命(留言留名學生會 2022年6月5日 (日) 10:27 (UTC)
我觉得默认情况下没有必要,毕竟并不是所有活跃用户都关注人事任免。私以为可以像站内刊物那样制作一个发送名单,让用户自行选择是否订阅。--BlackShadowG Slava Ukraini! 2022年6月6日 (一) 12:20 (UTC)
同意--0906(回復請Ping我) 2022年6月7日 (二) 14:34 (UTC)
对一部分前管理员参选不使用安全投票不会有问题吧?--Lanwi1(留言) 2022年6月5日 (日) 14:26 (UTC)
Lanwi1如果两种投票方式并行,是否应给予候选人自主选择投票方式的机会,或是由社群整理出一份“强制记名投票候选人名单”?这样看起来会不会有些不公平(无论是对采用SP的候选人或是采用普通流程的候选人)?而且这样做可能意味着社群需要准备两份投票规则。--Yining Chen留言|签名页) 2022年6月5日 (日) 14:48 (UTC)
不建议让候选人自主选择,这可能导致不愿公开投票倾向(可能出于安全原因)的用户无法参与部分投票。--BlackShadowG Slava Ukraini! 2022年6月5日 (日) 15:07 (UTC)
支持继续使用安全投票。但继续使用安全投票可能意味着社群需要对RFA方针的全部内容进行讨论并重写。关于Proxy,在以往的投票中也未能有很好的方法来排除傀儡干扰(但在实际投票中,似乎是因为投票要求较高,所以很少见到过滥用傀儡投票),因此反对排除使用Proxy的用户。--Yining Chen留言|签名页) 2022年6月5日 (日) 14:48 (UTC)
重寫方針是比較簡單的部分;甚至不需要廢除既有之全部內容,只需要能夠反映採用安全投票的現實即可。當然根據相關討論,人事任免資格方針也得修一下了。—— Eric Liu 創造は生命(留言留名學生會 2022年6月5日 (日) 16:29 (UTC)
我要特別聲明一點:我反對任何容許以舊投票方式進行選舉的方案,並行方案也不行。只有安全投票能保證投票人的人身安全,因此只能統一使用安全投票。Sanmosa Χαίρε, ω χαίρε, Ελευθεριά! 2022年6月5日 (日) 15:49 (UTC)
PS提一句,如果Proxy是非公开的话,那是不是容许的范围,因为meta:No open proxies提到“Publicly available proxies (including paid proxies) may be blocked for any period at any time.”,现有的IP的Proxy封锁似乎也是基于怀疑是VPS常用的AS来判断(是否包括Proxy探测不能确定),如果存在Private Proxy(只有一个用户专用的Proxy),那应该不属于meta:No open proxies的情况?——Sakamotosan路过围观 | 避免做作,免敬 2022年6月6日 (一) 02:32 (UTC)
如果考虑利用CU排查的话,结合安排安全投票的配置和CU工作的效率,可以这样安排:每个两个月集中安排一次投票(CU默认保留3个月的数据,每个月开一次密度可能过高,取一个中间值),投票完毕后由CU进行事后复核,先按用户名查一次,再集合IP信息反向查一次,并且结合IP的whois等信息排除掉普通用户和private proxy类(IP是属于VPS但只有一个用户)的用户,剩下的大量集中特定VPS的可以考虑为明确的Publicly proxy。这些数据也最好记录在cuwiki中作为日后复查。CU将怀疑在Publicly proxy的用户名单交给行政员,再结合投票结果,决定是否排除这些用户的投票,然后再宣布正式的投票结果?——Sakamotosan路过围观 | 避免做作,免敬 2022年6月6日 (一) 02:32 (UTC)
除了“让候选人自主选择”之外另一个选项是“让投票人自主选择”。愿意承担风险者可以沿用既有投票方式,但须列明合理理由;不愿承担风险者可以去安全服务器投票。若重复投票,以安全服务器上的投票为准。这样遇到临界情形也有判别共识的依据。--Antigng留言) 2022年6月6日 (一) 05:51 (UTC)
此外避免“社群在人身威脅問題上開倒車”的关键在于要有良好的预防和应对“人身威胁”的站内机制。仅仅在管理人员选举层面各种加码并无助于从根源上解决问题,就算没有管理人员选举也有条目争议封禁争议等其它类型的争议,没有上述这种机制,样样都可能引发“人身威胁”。--Antigng留言) 2022年6月6日 (一) 06:01 (UTC)
不行,我覺得受人身威脅者也會被威脅不得到安全伺服器投票,所以不可容許安全伺服器投票以外的任何投票方法。另外,提醒一下大家安全投票機制只會讓大家知道誰已經投了,而沒人知道誰怎麼投Sanmosa Χαίρε, ω χαίρε, Ελευθεριά! 2022年6月6日 (一) 06:03 (UTC)
既然安全服务器可以看见谁已经投票,那么监票的行政员只要看到该用户投票,就可以自动将站内投票忽略,从而不会引发任何问题。此外,受威胁用户可以假意于站内页面顺应威胁者的意思,但在安全服务器表达真实意见。这样TA既表达了真实意见,也不再会受到威胁者的威胁。因此“以安全服务器上的投票为准”便可解决您所提出的问题。--Antigng留言) 2022年6月6日 (一) 06:25 (UTC)
@Antigng:還有一點,由於選舉期間所有人都能夠看到了誰已經投票,所以進行人身威脅者是會知道受人身威脅者有在安全投票那邊投票的,進行人身威脅者可以威脅受人身威脅者撤回在安全投票那邊投的票。Sanmosa Χαίρε, ω χαίρε, Ελευθεριά! 2022年6月6日 (一) 06:34 (UTC)
那么可以把这条信息关掉,使之对公众不可见,变成真正的安全投票。事后再让监票行政员汇总出一份结合站内外投票用户的名单,按字符先后顺序排列。--Antigng留言) 2022年6月6日 (一) 06:37 (UTC)
@Antigng:實務上不可行。安全投票是P站那邊負責的,所以那邊在投票結束後會直接給出所有參與安全投票的人的名單,進行人身威脅者還是可以知道受人身威脅者有沒有在安全投票那邊投票(而且還有考慮到被基金會除權的人包括管理員與行政員)。我主張只容許安全投票的原因是進行人身威脅者會失去得悉受人身威脅者是否有投票的誘因。Sanmosa Χαίρε, ω χαίρε, Ελευθεριά! 2022年6月6日 (一) 06:43 (UTC)
  1. 修改代码能解决的问题实务上并不算是问题;wmf的技术员也是为实现社群需要功能而服务的“打工人”而已。
  2. 此外,单纯“只容許安全投票”并不见得能使“進行人身威脅者”“失去得悉受人身威脅者是否有投票的誘因”。且不论威胁者可能非理性地照威胁不误,TA还完全可能“理性地”要求被威胁者在安全服务器进行投票,并出示投票的截图才放过。采用本人提出的方案,被威胁者遇到这种情况可以简单、假意地在站内投票。毕竟证有(投票)容易,证无(投票)难,威胁者有办法迫使被威胁者出示“在安全服务器进行投票”的证据,却没有办法迫使被威胁者出示“没有私下里去安全服务器投票、改票”的证据的,除非进行监视、非法拘禁等。--Antigng留言) 2022年6月6日 (一) 06:53 (UTC)
    安全投票是可以改票的,被威胁者即使被要求放出投票的截图也可以重新再投一次,因此进行人身威胁者无法得知受人身威胁者在安全服务器的投票意向,当然监视、非法拘禁是另当别论。--BlackShadowG Slava Ukraini! 2022年6月6日 (一) 09:55 (UTC)
有理。但至少本人提出的方案相较于“只容許安全投票”不会更利于威胁者对被威胁者展开威胁。
试行的方案,只容许安全投票的场景下:威胁者可以威胁投票人参加安全投票并出示截图等证明,也可以威胁投票人不投票;投票人可以分别采取“事后改票”、“秘密参与安全投票”的方式应对;
本人的方案,容许投票人选择安全与非安全投票的场景下:威胁者可以威胁投票人参加投票并提供证明,也可以威胁投票人不投票;投票人可以分别采取“在站内假意投票,事后去安全服务器表达真实意见”、“秘密参与安全投票”的方式应对;
有安全服务器“托底”,两方案的安全风险应该是相当的。而本人的方案更利于解决Wong128hk提出的临界状况不好判断的情形。--Antigng留言) 2022年6月6日 (一) 10:06 (UTC)
@Antigng:本人没能理解您的新方案是如何解决“临界状况不好判断”这一问题的。而且个人认为非安全投票与安全投票同步进行(该方案)很可能为投票增加了原本不存在的风险。--Yining Chen留言|签名页) 2022年6月6日 (一) 10:30 (UTC)
过去的投票之所以临界情况可以交由行政员裁决是因为投票与理由一一对应,通过理由可以判断哪一方的意见更有力;安全投票无法实现这一点。同时保留安全与非安全投票两个选项的前提下,如果最终出现了临界情况,而通过检验发现安全与非安全投票两个样本没有统计显著的差异,就可以站内非安全投票的样本进行类似的判读,决定投票延长还是直接不通过。--Antigng留言) 2022年6月6日 (一) 10:43 (UTC)
我觉得这会增强点票的难度。此外,由于同时使用两种投票方案需要比对重复票数,使用安全投票的用户的名单需要公开以便核对,这样就使威胁者可以要求被威胁者不投票。如果只使用安全投票,可以不公开投票的用户名单,以确保安全性。--BlackShadowG Slava Ukraini! 2022年6月6日 (一) 12:06 (UTC)
此外,我觉得即使是安全投票某种程度上也可以让行政员裁决临界情况:虽然用户的投票意向不会公开,但所有用户的投票附言会打乱顺序后公开,私以为行政员可以依据用户留下的意见来做出判决。--BlackShadowG Slava Ukraini! 2022年6月6日 (一) 12:10 (UTC)
一是如前述,可以从技术上限制普通帐户对已投票用户列表的访问,而仅允许监票行政员获取所有使用安全投票用户的名单。一旦用户出现在该名单中,站内投票自动作废;选举结束,站内外结果合并给出得票比例,监票行政员只给出站内外投票用户的总名单。这样威胁者就无从查证被威胁者有否使用安全投票进行改票。二是安全投票并不存在真正的讨论,参与者彼此看不见对方的留言,只是各说各话,难以归纳总结。此外,还不按照时间顺序排列,以至于无法识别“短期涌入大量支持/反对票”等异常情况。--Antigng留言) 2022年6月6日 (一) 12:22 (UTC)
那不如在选举页面开启“投票意见”章节,使用户可自愿公布其投票意向和理由,也可回复他人的意见,但最终结果仍以安全投票的结果为准。这样既便于行政员判断临界情况,也降低了计票的难度,安全性也没有问题。--BlackShadowG Slava Ukraini! 2022年6月6日 (一) 12:38 (UTC)
對於將已投票名單改設置為對公眾不可見的提案表示支持。但對於「投票意見」的部分,個人看法同Shizhao在下面說的,當前投票時已容許用戶發表意見,已足以供大眾及行政員判斷是否合理,而無需知道該意見提出者是否投了支持/反對/中立票、更不需要知道是哪位特定用戶所做出的。-Peacearth留言) 2022年6月10日 (五) 20:40 (UTC)
這會不會就是共識制?--J.Wong 2022年6月12日 (日) 04:53 (UTC)
“投票与理由一一对应,通过理由可以判断哪一方的意见更有力”,这点完全没有必要,只要看理由是不是合理,根本不需要知道某个理由是谁说的、是哪方说的--百無一用是書生 () 2022年6月8日 (三) 01:58 (UTC)
好像也是。不過至少「行政員可考慮中立票」的部分可能需要稍加修訂,雖然實質上並無太大區別。-Peacearth留言) 2022年6月10日 (五) 20:32 (UTC)
  • 順帶一說,我覺得看投票留言比看中立票更能判斷共識。以理服人嘛。--Temp3600留言) 2022年6月7日 (二) 14:27 (UTC)
  • 至少真的是不記名投票意見那邊有說過了。而且,投票期間結束後確實無法再投票,安全投票可行性是有的。就是...維基百科有無要創建一個頁面叫做「Wikipedia:安全投票」?--Z7504非常建議必要時多關注評選留言) 2022年6月9日 (四) 11:01 (UTC)
    等到正式确立相关方针再建立也不迟。--Yining Chen留言|签名页) 2022年6月12日 (日) 09:06 (UTC)
    也是喔,不過看看獨裁社群這樣搞,好像玩不起安全投票一樣,也就是說還是有人無法接受新格式的事實,就像Wikipedia:申请成为管理员/Lanwi1/第4次一樣。如果明知選不上管理員的奉勸就別選了,以免浪費很多寶貴時間,又不代表使用安全投票就一定能選上。還有喔,喊拉票的風聲去哪了?意思是說拉票經過安全投票過的也算過囉?--Z7504非常建議必要時多關注評選留言) 2022年6月13日 (一) 08:36 (UTC)
    社群应该考虑拉票的问题。Lanwi第四次竞选符合先前共识(上次只说进行一次SP投票,没有说SP投票完就暂停RfA选举。 ——魔琴 [ 留言 贡献 ] 2022年6月13日 (一) 10:29 (UTC)
    然而拉票這玩意也講過了啊,拉票是一種防不勝防的情況啊。只要有去討論過GA評選的爭議就知道了,GA評選就有出現過拉票的爭議了。為何這個獨裁社群沒有想過呢?--Z7504非常建議必要時多關注評選留言) 2022年6月13日 (一) 11:24 (UTC)
    问题是今后的RFA是否必须安全投票。--Lanwi1(留言) 2022年6月13日 (一) 13:42 (UTC)
    我覺得必須。拉票問題比起投票人受威脅的問題實在微不足道。Sanmosa Gottes Sonne strahl' in Frieden 2022年6月13日 (一) 14:02 (UTC)
    還會被人拉清單--中文維基百科20021024留言) 2022年6月13日 (一) 14:19 (UTC)
    我觉得这个投票非常好,但是中立票也能显示最好,而且不止管理员选举,罢免之类的也可以开启。--脳補。◕‿◕。讨论 2022年6月13日 (一) 15:31 (UTC)
  • 所以呢?要不要用安全投票是不是也要用安全投票決定呢?看吧都沒動靜了。--Z7504非常建議必要時多關注評選留言) 2022年6月16日 (四) 15:43 (UTC)
    從這個沒有動靜的看法,能否認為大家都覺得以後都要使用安全投票呢?上文除了討論兩者並行的方案外,不見明確的反對,如實在是沒有反對意見的話,不如就公示?--Ghren🐦🕕 2022年6月19日 (日) 10:28 (UTC)
    @Ghrenghren:問題是結論是甚麼,沒看出結論--SunAfterRain 2022年6月20日 (一) 00:16 (UTC)
    @SunAfterRain:我也沒看出在具體怎樣實行安全投票方面有什麼結論。但是如果可以有個初部共識決定以後都是用安全投票的話,對之下來的討論應該有幫助?--Ghren🐦🕙 2022年6月20日 (一) 02:42 (UTC)
    @Ghrenghren:如果不一次把這個討論串了結的話,我認為下一場選舉的準備時間還會拉長好幾倍(拖在討論時間)--SunAfterRain 2022年6月20日 (一) 07:39 (UTC)
    獨裁社群最好的方式真的是能拖延就拖延,導致一個討論串可能超過10萬位元組都不為過,沒想到要不要用安全投票居然都可以那麼的墨跡。--Z7504非常建議必要時多關注評選留言) 2022年6月20日 (一) 11:34 (UTC)
  • (!)意見(+)支持往後使用安全投票,至於有關此機制之技術性問題,竊以為應由基金會提供技術援助或解決(如投票介面、中立票、資訊顯示或隱藏、監驗票等功能設計或修訂)。個人認為,諸多站友既已花費大量時間、心力貢獻於此平台,提供平台所需之條目、站務、維運、構想、智慧等寶貴要素,甚而亦有用戶不吝捐款、出錢出力,且人事選舉相關議題紛擾已久,實應獲得有效解決。況且,中文社群亦已對相關議題發起討論至今,可謂集思廣益、盡心戮力了。綜觀站友意見,敝人斗膽表達意見和考量如下:
1.一切活動應以安全為優先考量。如果用戶光是上網投個票都不安全,或需承擔各種風險,甚至已經遭受到實質安全威脅,個人認為理當以自身安全為首要考量。若用戶真已感受到任何形式之人身安全脅迫(不論被迫以何種形式如何表態),敝人建議:先暫停維基百科內相關活動,必要時請求當地司法機構協助,在條件許可下向基金會具體陳情以尋求適當協助。在此之前,使用介面和機制之規劃應有所為。
2.投票過程中的已投票用戶名單等動態資訊不應對一般用戶公開
3.投票結果若處於臨界狀態,行政員可綜合考慮用戶投票意見和理由予以裁定
4.安全投票機制若能明確標註顯示「中立票」之附含意見較為理想;若最終安全投票介面仍不具此功能,且社群或具權限之監、驗票人員仍期待便於識別中立票內含之意見,竊以為於投票須知明確規範:「當用戶投下中立票,應於投票意見欄明確表達該票附具之意見或評價為『中立』,以便選舉結果之識別判讀。」即可(如投票用戶應於意見欄寫明:「中立,基於候選人....,但仍.....」;「投下中立票。平日候選人之站務表現已具XXX和OOO,往後可再加強AAA,....」)。
5.若設立選舉投票事宜通知機制,可供用戶自由選擇訂閱
6.其他技術性事項回歸安全投票機制所具功能,具投票資格用戶應皆可合規投票。
7.投票期間若發生異常或灌票現象,竊以為應可由具監、驗票權限之站務人員核查處置
8.現行投票頁面上方已有「意見」區,欲發言、討論、評論之站友應已有適合之區域,可供品評論議;站務人員選舉中「討論交流或評論表達以形成共識」之機制,竊以為此區塊應可具相當之功能,與「實際投票功能或機制」並行不悖。若有其他考量,或可對於「意見」區之規劃再行增補調整。
9.對於中立票之意義或代表性,過往已有相關討論及爭議,似懸而未決。敝人初步考古後認為,所謂中立票實則未必「中立」,觀諸過往中立票之具體意見和內容,所顯露之實質意向往往「偏向反對或不甚支持」(除去先置板凳、卡個位、看風向、只求個參與或真的沒意見等未帶實質意見內容者),亦即當投票用戶對參選人感到不太滿意或至少不夠滿意的情況下,仍希望參與投票並藉此加以評價,以對候選人表達「委婉反對」、「尚待加強」之意見或評價;竊以為講白了,其實幾乎就是偏向「不太支持」。用戶特地至此投下這一票,若對於候選人真毫無個人立場或意見偏好,又何必如此費力呢?個人認為其實就是不太支持參選人,可能基於種種考量,而不直接投下反對票,僅透過參與以表達意見或在投票結果臨界時期待發揮效用。若實行安全投票機制,行政員應仍可依據投票用戶留下的意見做出裁定,而投下中立票之用戶亦應明確其自身投票性質;否則,所謂「中立票」之存在意義甚至可供深入討論了。
以上為個人意見,供參。--Kriz Ju留言) 2022年6月20日 (一) 06:01 (UTC)
又没动静了。(+)支持安全投票,并认为现在就可以直接用普通投票的方式,来决定是否在以后的选举中采用安全投票。投票结束后,再讨论相关事宜也来得及。--50829!留言) 2022年6月22日 (三) 06:13 (UTC)
還不是有人不知道普通投票和安全投票的差別嗎?這種討論都可以一直沒動靜,基本上不用玩了,既然完全說服不了人還要考慮選管理員?最後恐怕就是互相投反對、浪費時間而已的奇葩社群。--Z7504非常建議必要時多關注評選留言) 2022年6月22日 (三) 15:30 (UTC)
  • 以上似乎对于使用安全投票没有明确的反对意见。下一步应该讨论投票的举行时间(定期举办或有人提名就举办)和修订相关方针指引了。至于投票流程,个人认为暂行规定的“发表意见”至“执行结果”部分可以继续沿用。--Steven Sun留言) 2022年6月23日 (四) 02:31 (UTC)

投票方式的共识

因为上方讨论过于冗长,因此在此开一个小节进行整理。希望能够推进讨论的进行。目前主要问题集中在以下两点:

  • 使用安全投票后,无法考虑中立票的意见;
  • 是否应转而使用安全投票与普通投票并行的方式。

但就目前共识而言,似乎并没有出现明确的反对使用安全投票的意见。是否可以认为大家已就“在接下来的投票中继续使用安全投票”这一点达成共识,并可以进行公示?或是需要举行投票来做出决定?另外,就以上两点问题,是否也可以通过举行另一场与此前类似的投票来进行选择?--Yining Chen留言|签名页) 2022年6月23日 (四) 15:10 (UTC)

  • 為何要並行呢?總之總有人搞不清楚何謂安全投票和普通投票的差別嘛,現在這個獨裁社群連以後要不要實施安全投票都可以無法做決定了,真的無法說服大眾,扯。請問如果要並行,那票是不是可以兩邊投阿?--Z7504非常建議必要時多關注評選留言) 2022年6月23日 (四) 16:53 (UTC)

我认为安全投票的缺点是成本比普通投票高,也就是说安全投票太消耗精力。--Lanwi1(留言) 2022年6月25日 (六) 23:56 (UTC)

我最担心的是有人利用安全投票来恶意投反对票,最坏的结果是候选人退出维基甚至是轻生,所以对一部分候选人而言,普通投票好一些。--Lanwi1(留言) 2022年6月27日 (一) 17:00 (UTC)

(!)意見:不好意思,敝人不確定候選人輕生是否指特定人士;若然如此,我強烈建議精神狀態不佳的站友敬請審酌衡量自身身心狀態,以個人安全和健康為重,如果的確身心狀態不佳,請立即停止所有維基百科相關活動,並尋求適當心理或醫療協助。況且,若用戶心神狀態確實如此,顯然不適合參與人事選舉等較可能產生火花之社群活動,亦敬請站友多多關心身邊的社群用戶。--Kriz Ju留言) 2022年6月27日 (一) 19:03 (UTC)
谁想轻生的话我也不知道,大陆用户轻生的可能性比港澳台用户高,因为大陆的言论管制,不能在现实生活中诉求自己的遭遇,所以更要多多关心依赖维基百科的渴望自由的大陆用户。--Lanwi1(留言) 2022年6月28日 (二) 00:36 (UTC)
中國大陸使用者是否輕生率較高敝人不認為可以從這一個簡單的投票介面和主題加以驗證,而仰賴投票介面表達意見自由致影響個人生命安全和身心健康或產生可能疑慮,我認為顯然亦非健康思維和應有舉措。敝人會建議,請各位站友多多關注生活和人生的美好面向,切勿因投入任何網路相關活動致影響生活平衡。與諸位站友共勉之。--Kriz Ju留言) 2022年6月28日 (二) 04:58 (UTC)
沒什麼屁用,就算用實體投票一樣也可以惡意投反對票。--Z7504非常建議必要時多關注評選留言) 2022年6月28日 (二) 14:08 (UTC)
实体的话可见,现在中维帮派化太重。--Lanwi1(留言) 2022年6月28日 (二) 14:33 (UTC)
為什麼我覺得恰恰相反?反倒是非安全投票下容易造成心理問題?(如果候選人的確有的話)非安全投票下投票會有壓力。--日期20220626留言) 2022年6月28日 (二) 14:36 (UTC)
对易被帮派排挤的候选人的而言,在安全投票下容易造成心理问题。--Lanwi1(留言) 2022年6月28日 (二) 14:57 (UTC)
不,對易被幫派排擠的候選人的而言,在沒有安全投票的情況下才容易造成心理問題。請不要將以前WMCUG干預RFA的情形視而不見。Sanmosa Királyunk s a közhazát 2022年6月29日 (三) 01:56 (UTC)
对易被WMC排挤的候选人的而言,不在安全投票下就容易造成心理问题,但我所说的帮派指的是反WMC的。--Lanwi1(留言) 2022年6月29日 (三) 03:17 (UTC)
我感覺把你說成同時存在的兩個「幫派」比較一下的話,就算這兩個「幫派」都真的同時存在,「反WMC的幫派」所產生的問題明顯不能與「親WMC的幫派」所產生的問題相提並論,至少「反WMC的幫派」不可能像「親WMC的幫派」一樣有羣體策劃的欺凌(包括但不限於網絡上與現實上)。Sanmosa Királyunk s a közhazát 2022年6月29日 (三) 15:25 (UTC)
亲WMC的帮派和反WMC的帮派不是同一类型,WMC的目的是获得地位,反WMC的帮派的目的是守住地位并排除WMC,此外还有一部分人的态度太强横,让人难以亲近。这两个帮派的区别是反WMC的帮派的地位比亲WMC的帮派高,我还认为有地位的违规者的危害比没地位的高。--Lanwi1(留言) 2022年6月29日 (三) 16:05 (UTC)
以前公開投票的時候有相互吵架的,對投反對票冷嘲熱諷的,還有我上面討論提到的有人投了反對票還會被人拉清單,就沒發現公開投票好在哪裡。--日期20220626留言) 2022年6月29日 (三) 03:08 (UTC)

中文维基百科过去有人事任免时的集体行动,今后也不会完全消失。个人的观察是此类集体行动受胁迫的成分少,人情的成分多。公开投票下,此类集体行动藏不住,谁重人情而眛事实,清清楚楚。倘若前几年WMC活跃时就启用了安全投票,想必只会掩盖而非制止媚世者的不当行为。至于上面说到的身心健康問題,也不止和人事任免相关,维基百科上有各种各样的事情会招致攻击;个人领教过WMC群组内的肆意谩骂,和人事任免无关的亦有很多。仅把RfA换成安全投票,恐怕治标不治本。上面讨论中支持安全投票者多,但本人的意见不同,供诸君参考。--Lt2818留言) 2022年6月29日 (三) 06:16 (UTC)

对,过去的拉票和在RfA时恶意投反对票基本上以人情的成分居多,例如以看不顺眼为由恶意投反对票。按照中维的现状,安全投票就是治标不治本,一切根源就是心怀不轨的人,WMC拉票的动机也包括对心怀不轨的人感到不满。--Lanwi1(留言) 2022年6月29日 (三) 09:46 (UTC)
我不支持完全採用安全投票而直接棄過往的投票方式不用,二者各有利弊。—— Eric Liu 創造は生命(留言留名學生會 2022年6月29日 (三) 17:09 (UTC)
那麼哪些情況下使用安全投票,根據候選人意願嗎?--日期20220626留言) 2022年6月29日 (三) 17:15 (UTC)
(!)意見:竊以為若技術可行,折衷方法或可考慮為「雙軌並行」,兩邊介面重複投票者計屬廢票,且該用戶視為擾亂選舉。若候選人於表態參選時指定選擇個人偏好之特定形式(不論「公開具名」或「安全匿名」形式),於七名用戶投下反對該候選人指定形式之反對票後,亦即相當於同時投下「反對候選人和其指定形式」之反對票(相當於雙重反對),則回歸雙軌並行制。之所以為七名反對者,敝人取自「罷免連署投票」之門檻;而同時反對候選人乃至出具理由反對其偏好形式,可見反對用戶對於參選人之「強烈反對或不信任」,以致其偏好之投票形式皆反對(此時投下之七票反對票為公開投票),此時則回歸雙軌並行。個人意見,供參。--Kriz Ju留言) 2022年6月29日 (三) 20:39 (UTC)
如果无法决定最终“胁迫投票”和“监督拉票”最终应选那个,似乎只能考虑某种双轨并行制。Kriz案二的“双重反对”部分不是很支持。看看其他人的意见。 ——魔琴 [ 留言 贡献 ] 2022年7月1日 (五) 13:26 (UTC)
上面就講過了嘛,這社群連看都沒在看,還在雙軌投票並行制?完全說服不了人就說了吧,真是有夠扭捏的。--Z7504非常建議必要時多關注評選留言) 2022年7月1日 (五) 15:57 (UTC)
  • 普通投票的缺點已經很清楚了。暫時沒有看出支持者有什麼補救辦法。--Temp3600留言) 2022年7月2日 (六) 19:28 (UTC)

若有什么人适合普通投票,大概以非被罢免的前管理员以及部分被WMF除权的前管理员居多,这些前管理员没有严重违规行为。--Lanwi1(留言) 2022年7月3日 (日) 04:04 (UTC)

 2016-08-20T17:44:49 Lanwi1 讨论 贡献 封禁解封了守望者爱孟 讨论 贡献 (封禁申诉)
--Mys_721tx留言) 2022年7月3日 (日) 13:27 (UTC)
@Mys 721tx:那是过去的我,我从爱孟被禁制后才明白自己的问题。现在的我已经不再是2018年4月以前的我了,人是有成长的。--Lanwi1(留言) 2022年7月3日 (日) 13:36 (UTC)
所以你覺得自己的問題是?--日期20220626留言) 2022年7月3日 (日) 13:38 (UTC)
我当时的问题是擅自解封,现在因为在爱孟事件中吸取教训,所以在Walter Grassroot事件中未犯相同错误。--Lanwi1(留言) 2022年7月3日 (日) 13:47 (UTC)
像上面这样的列出过去的问题对现在的我而言已经没有意义了,现在的我早已不想再碰像爱孟这样的封禁,在Walter Grassroot的封禁案我已经做到不想碰了。不明事理者就是不理解正常人犯错后会改进自己的行为,使自己不会再犯相同错误。--Lanwi1(留言) 2022年7月3日 (日) 18:04 (UTC)

(+)支持采用安全投票。“无法考虑中立票的意见”称不上是个问题,要想发表意见,可以去相应的RFA页面。“双轨并行”意味着仍要承受部分传统投票的缺点,我觉得没有必要;如果用户愿意,他们也可以在RFA页面表达支持或反对的意见。--CuSO4 2022年7月7日 (四) 04:23 (UTC)

如果要继续使用安全投票,是因为试验还没结束,需要“Key person”(指有影响力的关键人物)参选才能证明安全投票的效果。--Lanwi1(留言) 2022年7月11日 (一) 11:19 (UTC)

要不然就再「試行」幾次?—— Eric Liu 創造は生命(留言留名學生會 2022年7月11日 (一) 13:48 (UTC)
不知道谁想参选。如果我有方案,那就让包括部分被WMF除权的在内的人集中参选,正好消除对去年的基金会行动的最大不满,即活跃的反破坏管理员被除权。--Lanwi1(留言) 2022年7月11日 (一) 16:18 (UTC)
看來按這社群速度,要不我們再臨時數次試試看比較好。Ghren🐦🕛 2022年7月12日 (二) 16:25 (UTC)
我的意见就是再次试验,问题是谁想参选?--Lanwi1(留言) 2022年7月13日 (三) 01:52 (UTC)
上次试验通过后很快就有人提名。应该不用担心没人参选的问题。如果再次试验可以尝试一下多人同时参选。设立一周左右的提名期,通过提名的候选人集中使用安全投票选举。--Steven Sun留言) 2022年7月13日 (三) 09:22 (UTC)
多人同时参选最好,我已经想好提名谁了。--Lanwi1(留言) 2022年7月13日 (三) 09:42 (UTC)
但是再次「試行」安全投票是否需要社群授權?—— Eric Liu 創造は生命(留言留名學生會 2022年7月15日 (五) 03:19 (UTC)
跟上一次试验一样,再次试验。--Lanwi1(留言) 2022年7月15日 (五) 10:44 (UTC)
上次「試行」係經社群投票授權,這次雖然不一定要重新進行表決,但仍應得到社群共識。另外,還要多「試行」幾次,這也需要討論。—— Eric Liu 創造は生命(留言留名學生會 2022年7月15日 (五) 12:00 (UTC)

(!)意見:可以採用雙軌制,但普通投票只能投帶有意見的中立票,而且不能重複投。這相當於行政員只考慮沒有使用安全投票的使用者的意見。Acetophenone留言) 2022年7月14日 (四) 18:19 (UTC)

(+)支持完全使用安全投票,並可在對應的 RFA 頁面發表意見。--冥王歐西里斯留言) 2022年7月12日 (二) 09:24 (UTC)


看样子要继续使用安全投票了,安全投票暂行规定是否需要修改?--Lanwi1(留言) 2022年7月20日 (三) 10:08 (UTC)

如果社群就相關議題達成共識,我可以協助調整規定內容。—— Eric Liu 創造は生命(留言留名學生會 2022年7月20日 (三) 13:01 (UTC)
整理一下上面的討論?--冥王歐西里斯留言) 2022年7月24日 (日) 00:24 (UTC)
我覺得要討論的議題至少有:安全投票是否與原投票方式並行;以及如何修改安全投票暫行規定以應用於未來之申請等。—— Eric Liu 創造は生命(留言留名學生會 2022年7月31日 (日) 07:43 (UTC)
如果此次决定要再次试验,建议在此前试行的基础上放开人数限制,即提名期达到票数要求即可参选。--Yining Chen留言|签名页) 2022年7月24日 (日) 01:02 (UTC)
暂时支持再次试验,意见同Yining。 ——魔琴 [ 留言 贡献 ] 2022年8月1日 (一) 06:37 (UTC)
這獨裁社群真的在搞笑,原來過了一個多月的討論了結果還是要用安全投票嘛,都已經故意不想理會了。那請問為何沒有辦法直接6月底、7月初左右的時候就說繼續用安全投票,非要等到8月才能做出決定呢?肯定是因為維基百科已經是一個標準的「Parkinson's Law」了。搞笑的東西,原來要不要用安全投票要猶豫一個多月那麼久?--Z7504非常建議必要時多關注評選留言) 2022年8月5日 (五) 17:59 (UTC)
社群討論流程確實推進地有些慢,不過還輪不到您冷嘲熱諷呢。—— Eric Liu 創造は生命(留言留名學生會 2022年8月6日 (六) 14:15 (UTC)
中维不重视,所以推进就是慢。--Lanwi1(留言) 2022年8月8日 (一) 03:43 (UTC)
好了好了,既然都知道推进慢就不要在没意义的讨论中浪费时间了。再次试验大概相比这次试验需要调整哪些内容?--BlackShadowG Slava Ukraini! 2022年8月8日 (一) 10:55 (UTC)
目前看起來大概就還要不要保留傳統投票吧?但上面的討論看起來似乎比較傾向僅供表達意見,不做投票用。--冥王歐西里斯留言) 2022年8月8日 (一) 11:47 (UTC)

本章節暫時不存檔,直至社群達成共識。欲讓機器人存檔,請移除本模板。留言請置於本模板上方。

建議修改音樂關注度規則

由於部份國家或地區歌曲/歌手大多只在當地的流行歌曲排行榜上榜,在現有Wikipedia:關注度 (音樂)的情況下大多不符合「作品至少登上兩個國家或地區的音樂榜單前十名內,但不適用於登上同一個榜單的不同類別與單一國家或地區內的多個榜單」的條件,因此建議作以下修訂:

現行條文

音樂家與音樂團體 維基百科中有許多樂團、歌手與其他音樂家音樂團體的條目。

如果滿足以下條件其中之一,音樂家或音樂團體(包含樂團、歌手、饒舌歌手、樂隊、嘻哈樂團、DJ、音樂劇團等)被视为具有關注度:

  1. 他們曾經被多份獨立於該音樂家或團體以外的已出版可靠來源所提及[1]
  2. 作品至少登上兩個國家或地區的音樂榜單前十名內,但不適用於登上同一個榜單的不同類別與單一國家或地區內的多個榜單[2]
  3. 在至少一個國家或地區取得金唱片或更高級的唱片認證。
  4. 曾經獲得主要的音樂獎項,例如葛萊美獎朱諾獎水星音樂獎金曲獎选择音乐奖英语Choice Music Prize等。

另外,通常音樂團體成員的條目比較適合重定向到該擁有關注度的團體條目中,而非設置獨立的個人條目,除非他們有足夠個人關注度,比如擁有個人專輯等等。 作詞家與作曲家 對於作曲家、填詞家或編曲家,符合以下條件之一,具有關注度:

  1. 作品取得金唱片或更高級的唱片認證。
  2. 曾經獲得主要的音樂獎項,例如葛萊美獎朱諾獎水星音樂獎金曲獎选择音乐奖英语Choice Music Prize
  3. 作品至少登上兩個國家或地區的音樂榜單前十名內,但不適用於登上同一個榜單的不同類別與單一國家或地區內的多個榜單[2]

音樂作品 音樂作品需要满足下列条件之一才符合关注度:

  1. 该作品在至少在一地取得金唱片或更高級的唱片認證
  2. 该作品赢得了具關注度的國際性奖项(如葛萊美獎朱諾獎水星音樂獎等)或該地區受廣泛認同的音樂獎項。
  3. 作品至少登上兩個國家或地區的音樂榜單前十名內,但不適用於登上同一個榜單的不同類別與單一國家或地區內的多個榜單[2]

不满足關注度标准的作品條目應該被合併到相关条目(如專輯、艺人、词曲创作人或制作人等等)條目中。

参考資料

  1. ^ 自我宣传、自传以及置入性行销等资料并不能支持一篇百科全书。已出版的作品及相关的音乐、音乐家、作曲家、作词家、制片人必须由其他人独立撰写(参见维基百科:避免自我提及)。
  2. ^ 2.0 2.1 2.2 這裡提到的音樂榜單是指具有一定規模且國家或地區認證或成立榜單。
提議條文

音樂家與音樂團體 維基百科中有許多樂團、歌手與其他音樂家音樂團體的條目。

如果滿足以下條件其中之一,音樂家或音樂團體(包含樂團、歌手、饒舌歌手、樂隊、嘻哈樂團、DJ、音樂劇團等)被视为具有關注度:

  1. 他們曾經被多份獨立於該音樂家或團體以外的已出版可靠來源所提及[1]
  2. 作品至少登上两个具有一定规模且獲一個国家或地区认证或成立榜单的頭十名內,但登上同一个榜单的不同类别不在此列
  3. 在至少一個國家或地區取得金唱片或更高級的唱片認證。
  4. 曾經獲得主要的音樂獎項,例如葛萊美獎朱諾獎水星音樂獎金曲獎选择音乐奖英语Choice Music Prize等。

另外,通常音樂團體成員的條目比較適合重定向到該擁有關注度的團體條目中,而非設置獨立的個人條目,除非他們有足夠個人關注度,比如擁有個人專輯等等。 作詞家與作曲家 對於作曲家、填詞家或編曲家,符合以下條件之一,具有關注度:

  1. 作品取得金唱片或更高級的唱片認證。
  2. 曾經獲得主要的音樂獎項,例如葛萊美獎朱諾獎水星音樂獎金曲獎选择音乐奖英语Choice Music Prize
  3. 作品至少登上两个具有一定规模且獲一個国家或地区认证或成立榜单的頭十名內,但登上同一个榜单的不同类别不在此列

音樂作品 音樂作品需要满足下列条件之一才符合关注度:

  1. 该作品在至少在一地取得金唱片或更高級的唱片認證
  2. 该作品赢得了具關注度的國際性奖项(如葛萊美獎朱諾獎水星音樂獎等)或該地區受廣泛認同的音樂獎項。
  3. 作品至少登上两个具有一定规模且獲一個国家或地区认证或成立榜单的頭十名內,但登上同一个榜单的不同类别不在此列

不满足關注度标准的作品條目應該被合併到相关条目(如專輯、艺人、词曲创作人或制作人等等)條目中。

参考資料

  1. ^ 自我宣传、自传以及置入性行销等资料并不能支持一篇百科全书。已出版的作品及相关的音乐、音乐家、作曲家、作词家、制片人必须由其他人独立撰写(参见维基百科:避免自我提及)。

歡迎討論。--Billytanghh 討論 歡迎參與亞洲月 2022年6月20日 (一) 12:59 (UTC)

(+)支持,但一個關注點是哪些音樂榜單可被用作有效判斷關注度的標準?不怕被引用出任一不知名音樂榜單就當成滿足此項?--西 2022年6月20日 (一) 16:21 (UTC)
其實原有備註會被保留。--Billytanghh 討論 歡迎參與亞洲月 2022年6月20日 (一) 16:47 (UTC)
注释已代为补上。--Kirk # 2022年6月20日 (一) 22:52 (UTC)
修订主旨似乎是放宽到任意两合乎要求的榜单即可,“至少两个……,或一个……的两个或以上”的描述是否重复累赘。或可直接合并注释,似宜描述为“作品至少登上两个具有一定规模且国家或地区认证或成立榜单,但登上同一个榜单的不同类别不在此列”即可。--Kirk # 2022年6月20日 (一) 22:43 (UTC)
另,第1.2(作词家与作曲家)章节亦有“作品至少登上两个国家或地区的音乐榜单前十名内……”的要求,但修正案未提出修改,不知道是漏了(刚好可以补上),还是对词曲作家的标准另有考量(刚好可以详细说明一下)?--Kirk # 2022年6月20日 (一) 22:55 (UTC)
已修改。--Billytanghh 討論 歡迎參與亞洲月 2022年6月21日 (二) 01:53 (UTC)
(+)支持:建議「成立榜單」改為「成立週榜單」,至少以週為單位。是說我想提議一條「作品至少登上一個具有一定規模且國家或地區認證或成立週榜單前三名,名次限制隨著登榜時間增長而遞減。」 --Loving You Is A Losing Game 2022年6月21日 (二) 02:55 (UTC)
与其是写一定規模的榜單,為什麼不寫有關注度的榜單?這樣的話爭議相對少很多吧。--Ghren🐦🕛 2022年6月21日 (二) 04:25 (UTC)
這樣還要定義誰是符合關注度的榜單,很不方便。 --Loving You Is A Losing Game 2022年6月21日 (二) 06:03 (UTC)
我的關注點跟閑閑君一樣,何謂「一定規模」?--西 2022年6月22日 (三) 01:06 (UTC)
個人認為一定規模是指具可與比肩官方的榜單。像國內方面有日本Oricon公信榜和俄羅斯Tophit,國際方面則有拉美監控告示牌 (雜誌)具有高市占率,而某種程度上也擔任官方角色發布相關認證。當然這只是我認為,如果要歸納總結,大概會發展出誰是現任法國國王一樣長篇論戰。 --Loving You Is A Losing Game 2022年6月22日 (三) 05:05 (UTC)
是否直接定義符合通用關注度標準的榜單才能視作有效關注度條件?--西 2022年6月22日 (三) 05:11 (UTC)
改成奖项規定形式OK。 --Loving You Is A Losing Game 2022年6月22日 (三) 15:54 (UTC)
所以重點是不用在十名之內?那不錯。--中文維基百科20021024留言) 2022年6月23日 (四) 16:59 (UTC)
其實我的確認為需要頭十名內,已補回。--Billytanghh 討論 歡迎參與亞洲月 2022年6月23日 (四) 18:15 (UTC)
那這樣不是和你之前的提議原因抵觸了嗎?原話是「由於部份國家或地區歌曲/歌手大多只在當地的流行歌曲排行榜上榜」,如果加回前10名,不是和先前的版本沒實質上的區別?--中文維基百科20021024留言) 2022年6月23日 (四) 18:19 (UTC)
可能具體語句需要再修修,目前的修訂版本乍一看依舊強調「前十名」。--中文維基百科20021024留言) 2022年6月23日 (四) 18:21 (UTC)
先前版本要求兩個國家或地區,修訂版本只要求兩個具有一定规模且国家或地区认证或成立榜單便可,同一地區的兩張都可以。--Billytanghh 討論 歡迎參與亞洲月 2022年6月23日 (四) 18:52 (UTC)
你是指同一地區的「兩榜」都可以嗎?敝人反對,比利時還能解釋成地區(一個荷蘭一個法國),但日本韓國作品因為國內有兩榜算符合條件也太鬆散了,倒不如加上名次限制。 --Loving You Is A Losing Game 2022年6月24日 (五) 01:30 (UTC)
不鬆吧,至少一國之內有知名度了,應該夠了。--中文維基百科20021024留言) 2022年6月24日 (五) 03:17 (UTC)
我是覺得這個條款太有益於小國了。小國隨便和鄰國加起來兩個榜就行,假如是中國的話,一首歌那怕是好幾個省都上榜了也不行,其實多少有些不公平。--Ghren🐦🕖 2022年6月24日 (五) 11:02 (UTC)
怎麼不鬆?以日本為例,除了比較具有標示性的Oricon、告示牌還有RecoChoku、Mora等其他榜單,這還沒包括根據不同格式產生的不同類型榜單們,日本金唱片認證好歹要你賣100,000張,靠這張你只要國內榜單夠多,賣個1千拿個100名符合關注真的很鬆。 --Loving You Is A Losing Game 2022年6月24日 (五) 13:53 (UTC)
那“同一個榜單”改成“同一個公司發佈的榜單”如何?這種情況下,以告示牌為例,Oricon、RecoChoku與Mora都當成一個榜單。Sanmosa Királyunk s a közhazát 2022年6月25日 (六) 04:10 (UTC)
@BillytanghhMilkypineSanmosa Királyunk s a közhazát 2022年6月25日 (六) 04:11 (UTC)
這樣改是比較嚴謹,但我反對降低標準,僅支持至少两个具有一定规模且国家或地区认证或成立榜单(關注度符合)。 --Loving You Is A Losing Game 2022年6月25日 (六) 05:04 (UTC)
我沒意見,我甚至覺得為求嚴謹,可以進一步改成“至少兩個具備關注度、具備一定規模且國家或地區認證或成立的榜單(同一組織或單位發佈的榜單視為同一榜單)”。Sanmosa Királyunk s a közhazát 2022年6月28日 (二) 05:23 (UTC)
確定是鄰國效應不是文化環境嗎?照地理來看比起希臘,賽普勒斯還比較靠近土耳其,但現實是兩著一家親。回到中國,先不提自家人沒官方榜單也不信任那些商業平台,香港台灣乃至於新加坡等華語圈也有榜單,如果真的要靠拉低榜單標準來達成關注度,那還不如刪掉算了。 --Loving You Is A Losing Game 2022年6月24日 (五) 13:53 (UTC)
“具有一定规模”,“一定规模”有没有什么标准?--BlackShadowG Slava Ukraini! 2022年6月24日 (五) 12:25 (UTC)
建議條文和現行條文有什麼分別?我沒看出來。--AT 2022年6月24日 (五) 12:44 (UTC)
現行條文要求兩個國家或地區的兩個榜單或以上,建議條文只要求一個國家或地區的兩個榜單或以上。--Billytanghh 討論 歡迎參與亞洲月 2022年6月24日 (五) 17:16 (UTC)
「作品至少登上两个具有一定规模且国家或地区认证或成立榜单的頭十名內,但登上同一个榜单的不同类别不在此列」看不出來一個在哪裡。 --Loving You Is A Losing Game 2022年6月24日 (五) 17:34 (UTC)
已修改。--Billytanghh 討論 歡迎參與亞洲月 2022年6月24日 (五) 19:38 (UTC)
改成一國兩榜的話,前十位實在太容易了,前三位的話可以考慮。這樣也可以同時保留原本的兩國兩國前十的條文。--AT 2022年6月26日 (日) 13:44 (UTC)
(?)疑問,其他地域不是特别清楚,但就中国大陆地区而言,音乐榜单实在是太多了,仅以QQ音乐为例,其就包括了所谓“巅峰新歌榜”、“巅峰人气榜”、“巅峰流行指数榜”等等,其中这些榜单还包括所谓“日榜”、“周榜”、“月榜”。个人观点,对所谓“榜单”应有更明确限制,否则仍然无法满足关注度之要求。--SheltonMartin留言|签名 2022年7月7日 (四) 01:37 (UTC)
我認為應該將榜單限制至「週榜」或以上。--Billytanghh 討論 歡迎參與亞洲月 2022年7月16日 (六) 11:54 (UTC)
(!)意見:對於相關條文,敝人認為或可同時保留具備跨國或跨地域知名度,以及增列於單一國家或地區之流行或傳播代表性的收錄門檻,因此個人傾向仍保留「作品至少登上兩個國家或地區的音樂榜單前十名內」之條文,同時異動增列的條文為「作品至少登上一個具有一定規模的國家或地區月、年排行榜或兩個周排行榜前三名內,但登上同一個榜單的不同類別不在此列。」。--Kriz Ju留言) 2022年7月18日 (一) 00:36 (UTC)
@Kriz Ju:兩個周排行榜本身就是很嚴格的條件,個人認為不用加改為前三名。 --窝法乙烷 儿法梦碎 2022年7月19日 (二) 02:33 (UTC)
不然依Milkypine君您研究所得看看好了,個人無甚意見。--Kriz Ju留言) 2022年7月20日 (三) 15:45 (UTC)
既然要改順便整理一下其他內容好了。周榜單仍維持前10,另加上年月,是說不符榜單限制也可以曲線救國,畢竟符合一般關注度。 --窝法乙烷 儿法梦碎 2022年7月17日 (日) 16:07 (UTC)
現行條文

音樂家與音樂團體 維基百科中有許多樂團、歌手與其他音樂家音樂團體的條目。

如果滿足以下條件其中之一,音樂家或音樂團體(包含樂團、歌手、饒舌歌手、樂隊、嘻哈樂團、DJ、音樂劇團等)被视为具有關注度:

  1. 他們曾經被多份獨立於該音樂家或團體以外的已出版可靠來源所提及[1]
  2. 作品至少登上兩個國家或地區的音樂榜單前十名內,但不適用於登上同一個榜單的不同類別與單一國家或地區內的多個榜單[2]
  3. 在至少一個國家或地區取得金唱片或更高級的唱片認證
  4. 曾經獲得主要的音樂獎項,例如葛萊美獎朱諾獎水星音樂獎金曲獎选择音乐奖英语Choice Music Prize等。

另外,通常音樂團體成員的條目比較適合重定向到該擁有關注度的團體條目中,而非設置獨立的個人條目,除非他們有足夠個人關注度,比如擁有個人專輯等等。 作詞家與作曲家 對於作曲家、填詞家或編曲家,符合以下條件之一,具有關注度:

  1. 作品取得金唱片或更高級的唱片認證
  2. 曾經獲得主要的音樂獎項,例如葛萊美獎朱諾獎水星音樂獎金曲獎选择音乐奖英语Choice Music Prize
  3. 作品至少登上兩個國家或地區的音樂榜單前十名內,但不適用於登上同一個榜單的不同類別與單一國家或地區內的多個榜單[2]

音樂作品 音樂作品需要满足下列条件之一才符合关注度:

  1. 该作品在至少在一地取得金唱片或更高級的唱片認證
  2. 该作品赢得了具關注度的國際性奖项(如葛萊美獎朱諾獎水星音樂獎等)或該地區受廣泛認同的音樂獎項
  3. 作品至少登上兩個國家或地區的音樂榜單前十名內,但不適用於登上同一個榜單的不同類別與單一國家或地區內的多個榜單[2]

不满足關注度标准的作品條目應該被合併到相关条目(如專輯、艺人、词曲创作人或制作人等等)條目中。

参考資料

  1. ^ 自我宣传、自传以及置入性行销等资料并不能支持一篇百科全书。已出版的作品及相关的音乐、音乐家、作曲家、作词家、制片人必须由其他人独立撰写(参见维基百科:避免自我提及)。
  2. ^ 2.0 2.1 2.2 這裡提到的音樂榜單是指具有一定規模且國家或地區認證或成立榜單。
提議條文

音樂家與音樂團體 維基百科中有許多樂團、歌手與其他音樂家音樂團體的條目。

如果滿足以下條件其中之一,音樂家或音樂團體(包含樂團、歌手、饒舌歌手、樂隊、嘻哈樂團、DJ、音樂劇團等)被视为具有關注度:

  1. 他們曾經被多份獨立於該音樂家或團體以外的已出版可靠來源所提及[1]
  2. 作品至少在一地取得金唱片或更高級的唱片認證
  3. 曾獲得具關注度的國際性奖项(如葛萊美獎朱諾獎水星音樂獎金曲獎选择音乐奖英语Choice Music Prize等)或該地區受廣泛認同的音樂獎項
  4. 作品至少登上一个具有一定规模的国家或地区月、年音樂銷售(銷量)排行榜或两个周音樂銷售(銷量)排行榜頭十名內,但登上同一組織或單位發佈榜單的不同类别不在此列[2]

另外,通常音樂團體成員的條目比較適合重定向到該擁有關注度的團體條目中,而非設置獨立的個人條目,除非他們有足夠個人關注度,比如擁有個人專輯等等。 作詞家與作曲家 對於作曲家、填詞家或編曲家,符合以下條件之一,具有關注度:

  1. 作品至少在一地取得金唱片或更高級的唱片認證
  2. 曾獲得具關注度的國際性奖项(如葛萊美獎朱諾獎水星音樂獎金曲獎选择音乐奖英语Choice Music Prize等)或該地區受廣泛認同的音樂獎項
  3. 作品至少登上一个具有一定规模的国家或地区月、年音樂銷售(銷量)排行榜或两个周音樂銷售(銷量)排行榜頭十名內,但登上同一組織或單位發佈榜單的不同类别不在此列[2]

音樂作品 音樂作品需要满足下列条件之一才符合关注度:

  1. 作品至少在一地取得金唱片或更高級的唱片認證
  2. 作品獲得具關注度的國際性奖项(如葛萊美獎朱諾獎水星音樂獎金曲獎选择音乐奖英语Choice Music Prize等)或該地區受廣泛認同的音樂獎項
  3. 作品至少登上一个具有一定规模的国家或地区月、年音樂銷售(銷量)排行榜或两个周音樂銷售(銷量)排行榜頭十名內,但登上同一組織或單位發佈榜單的不同类别不在此列[2]

不满足關注度标准的作品條目應該被合併到相关条目(如專輯、艺人、词曲创作人或制作人等等)條目中。

参考資料

  1. ^ 自我宣传、自传以及置入性行销等资料并不能支持一篇百科全书。已出版的作品及相关的音乐、音乐家、作曲家、作词家、制片人必须由其他人独立撰写(参见维基百科:避免自我提及)。
  2. ^ 2.0 2.1 2.2 一定规模的音樂銷售(銷量)排行榜是指該榜單涵蓋多個來源的銷售或播送渠道,並由公認的可靠來源組織和機構製作、發佈(参见Wikipedia:音樂銷量排行與認證#原則)。
  1. 排行榜條文改為「作品至少登上一个具有一定规模的国家或地区月、年音樂銷售(銷量)排行榜或两个周音樂銷售(銷量)排行榜頭十名內,但登上同一組織或單位發佈榜單的不同类别不在此列」
  2. 排行榜中的一定规模定義為「涵蓋多個來源的銷售或播送渠道,並由公認的可靠來源組織和機構製作、發佈」
@Kriz JuBillytanghhSheltonMartinATBlackShadowGSanmosaghrenghren:@中文維基百科20021024LuciferianThomas魔琴Benevolen:公示前,想先確認各位是否可以接受以上內容。 --窝法乙烷 儿法梦碎 2022年7月21日 (四) 01:09 (UTC)
我的观点与Kriz Ju一致,排行榜应该具有跨地域或跨国限制,至少应该在两个(含)以上的国家和地区登上榜单方可认为具有关注度。--SheltonMartin留言|签名 2022年7月21日 (四) 02:02 (UTC)
(+)支持相關修訂:個人認為此類條目通常以面向大眾讀者(和聽眾)為主,細觀既已有一定規模榜單之限制,當中提及「由公認的可靠來源發佈或是公認的國家觀測公司」(已要求此類榜單須具跨地域之知名度或代表性),亦「涵蓋多個來源的銷售或播送渠道」(已要求此類作品之銷量和播出管道涵蓋完整性),對於相關條目所具備之「公眾關注」和「市場成績」應已有最低限度要求,也有助於關注此領域的所有熱心編者往後能建立在商業市場具一定關注度的音樂領域條目分享給讀者。題外話,個人前面已表達「個人無甚意見」,未和樓上站友意見一致,感謝(笑)。--Kriz Ju留言) 2022年7月23日 (六) 22:14 (UTC)
看來是沒啥問題,那就用這個版本公示7日。 --窝法乙烷 儿法梦碎 2022年7月29日 (五) 08:07 (UTC)
(!)意見我個人沒所謂。但由兩個地區改為同一地區的兩個榜單,誓必會令符合條件的歌曲和人物大增。--Factrecordor留言) 2022年8月2日 (二) 13:19 (UTC)
如同我先前說的,不符榜單限制也可以曲線救國,畢竟符合一般關注度(香港電台這麼大一家你說不符通用關注度好像也不合理)。 --窝法乙烷 儿法梦碎 2022年8月2日 (二) 13:59 (UTC)
@Milkypine:提議條文的榜單明確定義為「銷量」,有些(?)疑問。先聲明,我是香港人,很少留意榜單,可能有些以前討論過的事我不知道。以我的一般常識,香港本地長久以來,專輯必談銷量榜,而歌曲(Song)傳統上最廣受公認的標準,是所謂四台(有些時期不是四個電台/電視台同時存在)的「派台」成績榜單,主要計算的是播放率,基本上香港流行音樂條目都會慣常地至少列出四台成績。現時Wikipedia:音樂銷量排行與認證中香港地區推薦來源名單的叱咤樂壇流行榜就是四台之一,並不是銷量榜;雷霆音樂指數我不清楚是什麼,外連只是回到商業電台主頁,和叱咤樂壇流行榜均是商業電台;推薦來源沒有其他三台。那麼,在新條文下,叱咤樂壇流行榜究竟算不算符合要求的榜單?其他三台的榜單又算不算?--Factrecordor留言) 2022年8月3日 (三) 10:59 (UTC)
其實我當時對Milkypine說的「雷霆音樂指數」應該是「雷霆歌曲播放指數」,因為該榜和1996年前的叱咤樂壇流行榜的覆蓋範圍並不只是商業電台,還包括香港電台和(1991年後)新城電台,所以符合非單一渠道的標準。--Billytanghh 討論 歡迎參與亞洲月 2022年8月3日 (三) 12:11 (UTC)
關於商業電台,它其中一個聞名及爭議之處,就是1990年代推動「原創歌運動」(不播放寄調外語歌填上中文詞的改編歌),這點影響其全面性,建議討論時多加考慮。由於我著眼於舊作多於新作,對這點會較為敏感。--Factrecordor留言) 2022年8月3日 (三) 14:02 (UTC)
(?)疑問另,對於人物,作品至少登上兩個榜,請澄清以下情況是否符合:情況一,作品A只登上過榜單X,作品B只登上過榜單Y。情況二,作品A只登上過榜單X,作品B也只登上過榜單X。--Factrecordor留言) 2022年8月3日 (三) 11:11 (UTC)
首先有沒有在推薦來源上都不是問題,修改提案寫道僅適用於符合Wikipedia:音樂銷量排行與認證#原則的榜單。關於「榜單」,如果你和Benevolen大這麼在意字面意思而不是單字解釋,那改成非投票榜單會不會比較好? --窝法乙烷 儿法梦碎 2022年8月3日 (三) 14:24 (UTC)
( ✓ )同意:比較好。--Factrecordor留言) 2022年8月3日 (三) 14:48 (UTC)
改成商業榜單也可以,比較符合所謂的商業表現。我覺得你搞錯音樂關注度的用意,它只是創立的最低標準,鳟鱼 (歌曲)好歌獻給您沒上榜不等於該砍,不要去想條目符不符合榜單規則而是想還有沒有其他內容可以補充(例如創作背景或評價)。而原創歌運動就和根據歌曲語言和流派分類的榜單一樣,是不夠全面,但又怎樣?每個榜單都有自己的規則和客群,我們只能從中選擇較公正且符合實際商業表現的榜單。 --窝法乙烷 儿法梦碎 2022年8月3日 (三) 14:51 (UTC)
也好,沒意見。我明白通用關注度與個別類型關注度並行。--Factrecordor留言) 2022年8月3日 (三) 15:15 (UTC)

以此公示7日

現行條文

音樂家與音樂團體 維基百科中有許多樂團、歌手與其他音樂家音樂團體的條目。

如果滿足以下條件其中之一,音樂家或音樂團體(包含樂團、歌手、饒舌歌手、樂隊、嘻哈樂團、DJ、音樂劇團等)被视为具有關注度:

  1. 他們曾經被多份獨立於該音樂家或團體以外的已出版可靠來源所提及[1]
  2. 作品至少登上兩個國家或地區的音樂榜單前十名內,但不適用於登上同一個榜單的不同類別與單一國家或地區內的多個榜單[2]
  3. 在至少一個國家或地區取得金唱片或更高級的唱片認證
  4. 曾經獲得主要的音樂獎項,例如葛萊美獎朱諾獎水星音樂獎金曲獎选择音乐奖英语Choice Music Prize等。

另外,通常音樂團體成員的條目比較適合重定向到該擁有關注度的團體條目中,而非設置獨立的個人條目,除非他們有足夠個人關注度,比如擁有個人專輯等等。 作詞家與作曲家 對於作曲家、填詞家或編曲家,符合以下條件之一,具有關注度:

  1. 作品取得金唱片或更高級的唱片認證
  2. 曾經獲得主要的音樂獎項,例如葛萊美獎朱諾獎水星音樂獎金曲獎选择音乐奖英语Choice Music Prize
  3. 作品至少登上兩個國家或地區的音樂榜單前十名內,但不適用於登上同一個榜單的不同類別與單一國家或地區內的多個榜單[2]

音樂作品 音樂作品需要满足下列条件之一才符合关注度:

  1. 该作品在至少在一地取得金唱片或更高級的唱片認證
  2. 该作品赢得了具關注度的國際性奖项(如葛萊美獎朱諾獎水星音樂獎等)或該地區受廣泛認同的音樂獎項
  3. 作品至少登上兩個國家或地區的音樂榜單前十名內,但不適用於登上同一個榜單的不同類別與單一國家或地區內的多個榜單[2]

不满足關注度标准的作品條目應該被合併到相关条目(如專輯、艺人、词曲创作人或制作人等等)條目中。

参考資料

  1. ^ 自我宣传、自传以及置入性行销等资料并不能支持一篇百科全书。已出版的作品及相关的音乐、音乐家、作曲家、作词家、制片人必须由其他人独立撰写(参见维基百科:避免自我提及)。
  2. ^ 2.0 2.1 2.2 這裡提到的音樂榜單是指具有一定規模且國家或地區認證或成立榜單。
提議條文

音樂家與音樂團體 維基百科中有許多樂團、歌手與其他音樂家音樂團體的條目。

如果滿足以下條件其中之一,音樂家或音樂團體(包含樂團、歌手、饒舌歌手、樂隊、嘻哈樂團、DJ、音樂劇團等)被视为具有關注度:

  1. 他們曾經被多份獨立於該音樂家或團體以外的已出版可靠來源所提及[1]
  2. 作品至少在一地取得金唱片或更高級的唱片認證
  3. 曾獲得具關注度的國際性奖项(如葛萊美獎朱諾獎水星音樂獎金曲獎选择音乐奖英语Choice Music Prize等)或該地區受廣泛認同的音樂獎項
  4. 單一作品至少登上一个具有一定规模的国家或地区月、年商業排行榜或两个周商業排行榜頭十名內,但登上同一組織或單位發佈榜單的不同类别不在此列[2]

另外,通常音樂團體成員的條目比較適合重定向到該擁有關注度的團體條目中,而非設置獨立的個人條目,除非他們有足夠個人關注度,比如擁有個人專輯等等。 作詞家與作曲家 對於作曲家、填詞家或編曲家,符合以下條件之一,具有關注度:

  1. 作品至少在一地取得金唱片或更高級的唱片認證
  2. 曾獲得具關注度的國際性奖项(如葛萊美獎朱諾獎水星音樂獎金曲獎选择音乐奖英语Choice Music Prize等)或該地區受廣泛認同的音樂獎項
  3. 單一作品至少登上一个具有一定规模的国家或地区月、年商業排行榜或两个周商業排行榜頭十名內,但登上同一組織或單位發佈榜單的不同类别不在此列[2]

音樂作品 音樂作品需要满足下列条件之一才符合关注度:

  1. 作品至少在一地取得金唱片或更高級的唱片認證
  2. 作品獲得具關注度的國際性奖项(如葛萊美獎朱諾獎水星音樂獎金曲獎选择音乐奖英语Choice Music Prize等)或該地區受廣泛認同的音樂獎項
  3. 作品至少登上一个具有一定规模的国家或地区月、年商業排行榜或两个周商業排行榜頭十名內,但登上同一組織或單位發佈榜單的不同类别不在此列[2]

不满足關注度标准的作品條目應該被合併到相关条目(如專輯、艺人、词曲创作人或制作人等等)條目中。

参考資料

  1. ^ 自我宣传、自传以及置入性行销等资料并不能支持一篇百科全书。已出版的作品及相关的音乐、音乐家、作曲家、作词家、制片人必须由其他人独立撰写(参见维基百科:避免自我提及)。
  2. ^ 2.0 2.1 2.2 一定规模的商業排行榜是指該榜單涵蓋多個來源的銷售或播送渠道,並由公認的可靠來源組織和機構製作、發佈(参见Wikipedia:商業排行與認證#原則)。
@Factrecordor:令開章節,不然上面討論真的有點多。音樂人榜單部分加了「單一」,這樣應該達到和商業榜單相同的精確感。 --窝法乙烷 儿法梦碎 2022年8月4日 (四) 08:45 (UTC)

一定规模榜單

金善賢、​老奋、​Lilychen1388、​Drippinpunch、​Lienwingyan、​Bbene98、​Paristung、​Joshua ZhanAchanhkBillytanghh、​Sinsyuan、​Jane9306、​JuneAugust、​Ryti😈M、​FactrecordorWill629Detective Akai、​Hisa312、​愛子棋枰恩力JoJo_append、​Lopullinen、​AnYiLin、​Yel D'ohan、​Temp3600、​Bigbullfrog1996、​陳寅恪、​Tenhumantenok、​Prince of EreborK.Y.K.Z.K.Arivgao、​FredYYoo、​Apple v、​Tfcheng5597、​Comrade John、​Adsa562、​Austin Zhang、​Gracelllee、​Shwangtianyuan星巴克女王Easterlies、​AT、​卡達、​Yumeto、​SickManWP、​羊羊32521、​EdwardAlexanderCrowley、​Zhaoweizhi0325、​MoonLight3650HXXXXPunkhippie、​Louis0921gee、​Peace 621、​Whykitty、​Moonshimmer93、​夜来南风起、​Fake12345、​TreasureBabe325、​Hijk910Jacklamf1d14Ericliu1912、​Naverad、​Softyu、​Sammypan、​Tw drama、​Shingkei、​Hikki、​李新阳、​CHih-See HsiePv163Ohtashinichiro、​和平至上、​Leehsiao、​Sanmosa、​Tombus20032000、​百战天虫、​Kriz Ju、​生米一粒、​Pseudo ClassesKodokunaSmile我大概寫了一下符合條件,歡迎各位參觀。 --Loving You Is A Losing Game 2022年7月4日 (一) 15:14 (UTC)
前面討論有提議改符合關注度的榜單,但後來想想這樣東西會太多太雜,所以列了符合條件和不符合條件。抱歉Billytanghh大我回退你的內容,但這裡放入單一渠道榜單並不合適,至少你要加應該把「避免內容」的「它僅憑藉單一發行商或渠道的成績製作榜單」砍掉,另一方面是像HKRIA版權風波的情況,歌曲喪失上榜資格無法展現商業表現。 --Loving You Is A Losing Game 2022年7月1日 (五) 12:03 (UTC)
其實五台榜單不太算是「單一渠道榜單」,叱咤樂壇流行榜的排名要同時參考香港電台的播放數字,Chill Club 推介榜也是由各唱片公司代表投票決定的。--Billytanghh 討論 歡迎參與亞洲月 2022年7月2日 (六) 01:45 (UTC)
Billytanghh投票的Chill Club 推介榜可能沒法放在這裡,至於叱咤樂壇流行榜,有沒有直接導向的網站?我看都導到903推介,還是現在903推介繼承他的業務。 --Loving You Is A Losing Game 2022年7月2日 (六) 04:43 (UTC)
请教“投票的Chill Club 推介榜可能沒法放在這裡”的原因是?Grammy和Academy也是投票决定的哦?--Benevolen留言) 2022年7月17日 (日) 16:50 (UTC)
這裡是銷售排行不是投票排行,況且應該沒有人認為Grammy和Academy是排行吧。 --窝法乙烷 儿法梦碎 2022年7月19日 (二) 03:17 (UTC)
我的理解“作品至少登上兩個國家或地區的音樂榜單”并未暗示必须是“銷售排行”。音乐市场数字化之前华语乐坛也并没有专门的单曲销量榜,音樂榜單等同于传媒的流行榜,类似今天的“投票”榜。--Benevolen留言) 2022年7月19日 (二) 04:05 (UTC)
這裡的音樂榜單是“銷售(销量)排行”(上面提案也特別寫道為「一定規模的音樂榜單是指該榜單涵蓋多個來源的銷售或播送渠道,並由公認的可靠來源組織和機構製作、發佈」),還是你覺得各大評論的年度專輯年度歌曲算音樂榜單?不學Everyday、髮箍#銷售排行榜那年代用銷售除了懶,多少也考慮到電台或串流無法用銷售代稱,但這不表示投票就該納入,串流好歹聽個1000次會讓一人收到錢,投票可不會,況且投票門檻低,只要創帳號甚至不用都可以參與,就算公信力沒問題,它的性質更適合擺在「評價」而非跟其他「銷售(销量)排行」擺在一起
先不吐槽幹嘛自甘墮落不看銷量,销量榜可是一直都有,例如大陸的信诺榜、台灣的Hito排行榜、香港的叱咤樂壇流行榜。 --窝法乙烷 儿法梦碎 2022年7月19日 (二) 05:22 (UTC)
上面的长篇提案,其实目的就一个:证明关注度。销售和播送当然反映关注度,像Grammy和Academy等专业评选也是关注度。“Chill Club 推介榜也是由各唱片公司代表投票決定的”,代表了业内人士的专业意见,Chill Club 推介榜和历史更长、性质类似的劲歌金榜在当地都有广泛认受性,加在这里合理啊。至于“各大評論的年度專輯年度歌曲”,那得看“各大評論”是不是“由公認的可靠來源組織和機構製作、發佈”了,如果New York Times选出个年度华语歌曲呢?--Benevolen留言) 2022年7月19日 (二) 06:28 (UTC)
目前為止標準有4條,你的要求完全能夠通過其它3條,甚至是一般關注度實現,音樂榜單這項只根據销售和播送認證關注度,想要有其它要求應該是另聘新規,而不是音樂榜單,Chill Club 推介榜不適用於此不等於它不能證明關注度。 --窝法乙烷 儿法梦碎 2022年7月19日 (二) 07:09 (UTC)
原来阁下一直坚持评选榜单不算榜单的原因是阁下最近从英维翻译过来的论述里有类似提法,怪不得在这里总辩不明白。上面讨论的其实是英维对“榜单”的理解是不是该照搬过来。本人觉得如果告诉一位香港人说勁歌金榜不是一份音乐榜单将会是违背常识的。--Benevolen留言) 2022年7月19日 (二) 08:00 (UTC)
扯英維之前你有沒有想過為啥投票榜不在上面的原因?因為這裡討論的就是銷量,你現在跟我槓誰是音樂榜單,難道承認用詞不精準還不行嗎?再說,這裡唯一一個打字有出現勁歌金榜不是一份音乐榜单的人是你,如果你覺得音乐榜单這四個字無法符合你的期待,那就是改成銷售(销量)排行。 --窝法乙烷 儿法梦碎 2022年7月19日 (二) 13:10 (UTC)
回首過去,當初的確沒想這麼多,雖然討論銷量但名詞卻沒能讓讀者接受到訊息,造成誤會。至於一定規模的探討...當初應該用草稿OTZ。 --窝法乙烷 儿法梦碎 2022年7月19日 (二) 13:27 (UTC)
本人的确想过“為啥投票榜不在上面的原因”所以特地找了阁下翻译的论述的原文,发现论述中的两句“須避免以下幾點......它由票選產生”是阁下的原创标准,而阁下提供的例子“匈牙利唱片公司協會「Editors' Choice Top 40 slágerlista」和《滾石》「五百大專輯」等編輯評選榜單”似乎是单一机构的内部评选,与上面讨论提及的“Chill Club 推介榜......由各唱片公司代表投票決定”可能能代表更广泛、多方面意见的情况并不相同。“改成銷售(销量)排行”的确能解决概念不清的问题,至于这样一来大家是否仍然能认同新规则、Chill Club 推介榜和劲歌金榜之类榜单是不是对NMSUIC完全不起作用则需另商。--Benevolen留言) 2022年7月19日 (二) 15:12 (UTC)
老實說銷量和評選是兩回事,這也是為啥嚴格算是獎項的唱片認證會和獎項分開,对NMSUIC完全不起作用也不是什麼大問題,看看Wikipedia:关注度#通用關注度指引Chill Club 推介榜要是不符合就不會有條目了。至於這類榜單的詳細應用,就交給閣下想了。 --窝法乙烷 儿法梦碎 2022年7月19日 (二) 15:59 (UTC)
一次性ping 50个人以上不会有效果。 ——魔琴 [ 留言 贡献 ] 2022年7月4日 (一) 14:24 (UTC)
原來超過50...,那我分批。 --Loving You Is A Losing Game 2022年7月4日 (一) 15:14 (UTC)

提议在电子游戏条目指引中规范游戏数字发行平台外链

针对WP:頁面存廢討論/記錄/2022/06/11#Template:Steam的讨论结果,结合WP:ELNO的具体条文,现拟议在WP:电子游戏条目指引中加入对游戏在线商店外链的规范:

現行條文

合适的外部链接-如果存在这些链接,应当在电子游戏条目中列出

  • 电子游戏官方主页(由开发商或发行商提供)。游戏如在中文区发售应优先列出中文版主页。如果是外文游戏,还应列出首发国家的语言版本并注明网站是外语。如果开发商和发行商提供的网站不同则应一并列出。

...

提議條文

合适的外部链接-如果存在这些链接,应当在电子游戏条目中列出

  • 电子游戏官方主页(由开发商或发行商提供)。游戏如在中文区发售应优先列出中文版主页。如果是外文游戏,还应列出首发国家的语言版本并注明网站是外语。如果开发商和发行商提供的网站不同则应一并列出。对于没有独立官方主页的电子游戏,可采用Steam等数字发行平台的页面作为官方主页,否则不可加入

...

以上。--百战天虫留言) 2022年7月10日 (日) 06:24 (UTC)

(!)意見 那为什么影视剧就可以加入付费观看的链接呢。--Yinyue200留言) 2022年7月10日 (日) 07:35 (UTC)
netflex自己的作品不放他的链接要放誰? --Loving You Is A Losing Game 2022年7月10日 (日) 08:17 (UTC)
  • 楼上提出了一个好问题。从情感上我认为适当提供Steam链接是方便且合理的,里面常提供详实的介绍、用户评价,以及方便的购买,但宣传平台的问题确实存在。观察存废讨论和现有指引,我发现之前的讨论可能有瑕疵:
  1. WP:ELYES第二项,有关“其它媒体”的条目,“应该链接到有放置该作品档案的网站”。
  2. WP:ELNO虽然要求避免“主要为贩卖物品或服务的网页”,但其例外的“官方网站”(网址、链接)包括“链接的内容由条目叙述的主题(组织或人物)所控制。”,而Steam页面的“主要内容”(游戏介绍)理所当然由作者(或授权代理)控制,并符合“主要是关于条目主题”。
    1. 该指引注明的粉丝网站、慈善网站,是其他人管理运营再转嫁收益的网页,非作者主导。
    2. 如果将内容框外的其他内容也计入内容,假如作品官网采用某些托管站,作者无法充分控制内容。
  3. 将链接数目减至最少,允许多个官方链接。滥加难以避免,即便删模板、立指引。提议允许“官方主页”不够优良时链接Steam页面以提供充分的介绍,或者允许链接足够热度的Steam页面。
  4. 对于“官方链接”例外,不知道是否有体验很差的官方主页作例,包括难以阅读/加载、广告多、链接难找等。
  5. 题外话:对于“电子游戏官方主页(由开发商或发行商提供)”,或许不完全符合WP:ELOFFICIAL的“内容由条目叙述的主题(组织或人物)所控制”,因为代理发行商可能脱离作者改变主页乃至游戏内容。如《我的世界》外链了网易的我的世界中国版,是否可作前者的“官方主页”,或是该算作授权代理商的衍生游戏的主页?
  6. 如果有模板通过一行/区块、多个参数、多个图标/链接展示多个游戏平台上的官方页面,减少行数占用,会更好吗,宣传性会提升还是降低。平台排序可能成争议,但可按字典序。感觉,可能被滥用。如果读Wikidata,可能会不错。--YFdyh000留言) 2022年7月10日 (日) 08:45 (UTC)
    規則的制定有時代背景,同時也會有一定局限性。在上個世紀和本世紀初,遊戲製作是一件專門專業的內容,也要較大的投入。當時沒有成規模的遊戲社區,Steam這一類遊戲平台方興未艾,上網還靠黃頁。製作官網算是聚攏人氣和粉絲的方法。
    在當代隨著成規模的遊戲社區和遊戲平台的完善,相當一部分的製作人已經放棄自建官網,而是使用成熟的社交平台製作官網,或者直接使用遊戲平台內置的功能就算了。更重要的是遊戲製作門檻變低,有很多獨立遊戲。我就遇過很多遊戲利用Itch.io可以定制網頁的功能,直接當作遊戲的官網。考慮時代變化,支持這部分的修訂。
    第六項是在說{{Authority control}}吧。--Nostalgiacn留言) 2022年7月10日 (日) 10:58 (UTC)
    对,差不多。以及类似的{{Commons category}}、{{External media}}。或许主要在于是商业性、直接营利的网站,很可能有违WP:SOAP,不然当作电子游戏领域的规范控制来源网站,可能很不错,并且可以标注该版适用于哪些电脑平台,乃至支持的特色(如成就、云存档、线上对战等)。--YFdyh000留言) 2022年7月11日 (一) 13:16 (UTC)
    有些游戏除了在线商店外,同时通过Amazon或者Gamestop实体贩售;而且在线商店内部Steam vs. Epic也有竞争关系。当然没有官网的游戏估计也不会推出实体版。而且中文维基是个小站,商业公司估计也不会到这找麻烦。但就是怕有什么商业方面的潜在问题。权威控制我是认为vndb等游戏数据库比较中立。--洛普利寧 2022年7月11日 (一) 15:00 (UTC)
详实的介绍如果对编写条目有帮助,应该以通过参考引用到条目正文(而且Steam上的游戏介绍百科性很差);用户评价不是收录内容,不应该以这个目的提供链接。维基百科不是为玩家服务的,读者可能根本不打算玩游戏。想买游戏的玩家Google也可以搜索到Steam。所以抛开“方便的购买”的理由不谈,为什么一定要加Steam链接?
如果链接满足WP:ELNO则不适用WP:ELYES(……在不違反#連結上的限制#正常情況下應避免的連結的情況下……)。WP:ELNO#4指出“主要為販賣物品或服務的網頁”,就说明这类网页优先度不高。WP:ELMIN不反对链接多个页面,但前提“各連結提供不同的內容”。而官方网站一般都有Steam链接,就更没理由重复放商店链接了。
另外英文版指引“Inappropriate external links”下面有这样一条:“Links to storefronts, per WP:ELNO #5 (Steam, Xbox Store, PlayStation Store, Google Play, GOG.com, etc.)”。(英维相关讨论)供本地讨论参考。--洛普利寧 2022年7月10日 (日) 10:20 (UTC)

如同存废讨论的意见,我赞同这笔修订。稍有疑虑的就是,同时在多个在线商店在线商店销售(SteamEpicGOG.com等),但又没有官网的该如何处理。--洛普利寧 2022年7月10日 (日) 11:24 (UTC)

另外没有官网时,理论上可以用游戏数据库替代。比如巴哈ACG资料库也有丰富的资料,也提供游戏商店的链接。但是巴哈会把跨平台游戏分成好几个页面,也是一堆链接。对于华语游戏,英文圈的{{MobyGames}}又不靠谱。所以有没有什么好点数据库?(不过要说商店链接,Wikidata倒是也有……)--洛普利寧 2022年7月10日 (日) 10:56 (UTC)
同Lopullinen。只宣傳單一平台不太好,但都宣傳可能沒有空間?---Temp3600留言) 2022年7月10日 (日) 15:01 (UTC)
没有要宣传,只是作为官方网站展示,择其一即可。--百战天虫留言) 2022年7月11日 (一) 05:16 (UTC)
如果没有官网,我倾向选销量高的那个,以及官方且免费的(如果有)。有官网,就不太确定。--YFdyh000留言) 2022年7月11日 (一) 09:58 (UTC)
当年(?),《9-nine-》被Sekai Project代理出中文版的时候,他们把游戏界面的主页按钮从游戏的日文版官网改成了Steam商店的页面。虽然观感不好,但确实是中文页面。不知你作何想法?--MilkyDefer 2022年7月11日 (一) 14:29 (UTC)
我不确定“观感不好”的意思。将系列页面视作“官方链接”,有什么利弊。官网加载有点慢,且我怀疑无障碍性不好,我也很难从中找到游戏总体介绍、购买链接等。--YFdyh000留言) 2022年7月11日 (一) 14:46 (UTC)
这游戏貌似不止PC一个平台……而且觉得维基百科的总体介绍不好,Google不才是最好的选择吗,为什么老是只想着官方网站……--洛普利寧 2022年7月11日 (一) 15:38 (UTC)
@YFdyh000:我从来没有说过这游戏的日文版官网就是你贴出来的那个网址哟?看样子我要给你举个例子了:在第一章中,Sekai Project把游戏中的这个官网链接,改成了这个Steam商店链接,二三四章类推。你贴的那个网址是四章之后开发商一波全年龄化搞出来的网站。我的意思是说,条目列出官网,但是官网不是中文。有人说,明明有(代理商认证的)本地化官网为什么要为难我,结果所谓的本地化的官网是Steam商店页面,你打算怎么办?--MilkyDefer 2022年7月12日 (二) 09:41 (UTC)
不太明白,但只要是官方发布的可读性好的主页链接,我不介意都列,Steam也一样。不过“将链接数目减至最少”可能就不容易做到。以及网站的子页面是否能列,理论上不该,但指引毕竟是指引,如果利大于弊……如果没有官方主页,官方Steam页面又没多少有效内容,这种我反而觉得要斟酌一下,引流将大于介绍作用。--YFdyh000留言) 2022年7月12日 (二) 16:10 (UTC)
当然我们没有其他的意思,但这会不会被商业公司过度解读?比如跨平台游戏只放//一家的商店链接,或者电脑游戏只放Steam/Epic之一的链接:这样结果被其他公司指摘不够中立?因为WP:VGBOX有「如果游戏在多平台上的封面类似,应对封面图像进行编辑,使用不含任何平台标识的封面以表中立」这样一条,所以我想到了这点。--洛普利寧 2022年7月11日 (一) 15:17 (UTC)
(-)反对,都已经2022年了,有兴趣的人自己搜索一下什么都有,维基百科不是网址导航,无须给用户提供指路服务。->>Vocal&Guitar->>留言 2022年7月11日 (一) 11:26 (UTC)
哪里是指路啊,只不过是在没有官方网站的情况下展示平台网站而已。--百战天虫留言) 2022年7月11日 (一) 11:47 (UTC)
所以为什么要展示?。->>Vocal&Guitar->>留言 2022年7月13日 (三) 01:35 (UTC)
上方U:YFdyh000的论点中,一个重要的谬误是Steam页面的主要内容由作者提供,但最终由Steam控制,而显然Steam(及其他同类)是标准的“主要为贩卖物品或服务的网页”。因此,Steam链接不论如何都不应出现在条目中。同理,其他类似性质的网站,例如kindle电子书、apple music、爱奇艺等等, 也不应将非官方原创内容放入。->>Vocal&Guitar->>留言 2022年7月13日 (三) 01:35 (UTC)
我对此存有疑议。以itch.io作官方主页的游戏,其页面是否也为“itch.io”所控制而不属于官方链接,且该网站也提供销售功能。就爱奇艺而言,如果是独家非自制(网)剧,或许能“不建议”加,但对完全不能加我表示存疑。--YFdyh000留言) 2022年7月13日 (三) 02:01 (UTC)
从他们的term看不出这个站与steam有什么本质区别,所有内容都在他们的网站上,他们可以完整控制。->>Vocal&Guitar->>留言 2022年7月13日 (三) 02:26 (UTC)
en:WP:ELOFFICIAL "An official link is a link to a website or other Internet service that meets both of the following criteria",我不认为内容托管乃至在线销售服务就不能是官方链接。即便所有人自建网站,云服务商、执法或黑客事件等亦可能在少数情况下完全控制内容,不需要为此过度担心,且担心也没用。另外,人物的博客、微博是官方链接吗,演艺团体的官方微博又是或不是,以及官网网站的互联网档案馆版本又如何。我不解您追求的“控制”需何种程度,有多少价值,以及作者“完全控制”的网站真的最适合读者吗。--YFdyh000留言) 2022年7月13日 (三) 03:13 (UTC)
因为您提到的WP:ELOFFICIAL明确指出需要由该组织或人物所控制,您以这条来豁免ELNO#4,我认为不合适。扩展开来看,除官网之外的其他SNS平台,作为外部链接也应该谨慎。一个有意义的例子是特朗普的推特,他的发文被疯狂打标签,然后直到封号,那么到底是他在控制还是推特在控制?当然从读者的角度,适合他们的不是官网,也不是steam,是3dm这种从盗版到补丁到修改器到攻略一条龙的网站。
讲点不切实际的,在如今,想找某某人某某物在某平台的账号应该是十分简单的事,维基百科真的有必要把这些一五一十都列进来吗?我们要搞清楚这些链接真的帮助了这篇条目更加完善,或者只是让中立性多一分隐患。--。->>Vocal&Guitar->>留言 2022年7月13日 (三) 05:08 (UTC)
itch-io还在Epic商店上架。另外Steam和Epic是商业竞争关系,就像官方在天猫京东都开官方店。官方自己操控的网站,他放一个商店或几个商店的连接,那是他自己的事情。维基百科只放一个商店,说好一点是编者无意只知其一,说极端一点就成了「维基百科给XX电商公司导流」;全部放上去那就真成导购网站了。
当然对于一些品质很差、没有参考资料的新条目,我承认不放Steam外链,都不知道条目在说哪款游戏。(不过这个外链更适合用作参考)在线商店一般就是作品基本介绍,并摘选一些媒体的溢美之辞;这些内容都是维基百科的玩法和评价章节涵盖的。如果出于让读者「理解基础信息」而加入在线销售商店,那只能说是条目的失败。而且如Vocal&Guitar所言,「有兴趣的人自己搜索一下什么都有」。对比WP:ELMIN的「only one」和「does not provide a comprehensive web directory to every official website」,我认重点还是在「only one」。(更何况有编辑还认为在线商店不算官方网站)--洛普利寧 2022年7月13日 (三) 05:45 (UTC) [修改于2022年7月13日 (三) 06:49 (UTC)]
1980年的游戏没任何主页怎么办?--百無一用是書生 () 2022年7月13日 (三) 02:23 (UTC)
没有就不要加。->>Vocal&Guitar->>留言 2022年7月13日 (三) 02:26 (UTC)
外部链接不仅仅是主页啊--百無一用是書生 () 2022年7月13日 (三) 03:49 (UTC)
如果没有Steam一类的店面的话,可以加入到游戏数据库的链接,如IGBD莫比游戏。可以先去wikidata上找标识符。--BlackShadowG Slava Ukraini! 2022年7月13日 (三) 09:41 (UTC)

上面讨论比较乱,重新整理一下:

  1. 关于官方链接的定义。依照WP:VG/EL,官方主页限于「开发商或发行商提供」的;Steam商店网站store.steampowered.com由销售商Valve提供,因此不算官方网站。各位怎么看?
  2. 承上,如果Steam商店链接不算「官方网站」主页,但倾向有条件视其为「合适的外部链接」。那在没有「官方网站」时,Steam链接是按官方网站处理(放在首位且使用{{Official website}}),还是享受官网待遇,放在首位但只能写成[https://store.steampowered.com/app/123456 Steam商店]
  3. 如果倾向算作「不合适的外部链接」,但「不适合」也不是禁止。那有没有什么例外情况,Steam商店可以作为一般外链甚至第一外链加入?
  4. 在多个商店销售的游戏如何处理?比如电脑游戏在Steam、Epic等多家商店销售:对开发商来说,随机选哪个链接都一样;但对Steam、Epic等商业网站而言,这就是天壤之别。中国大陆手游也有类似问题:登陆多个应用商店(包括或不包括Google Play)。

以上。--洛普利寧 2022年7月13日 (三) 08:05 (UTC)

個人認為討論的觀點有點倖存者偏差。事實上,獨立遊戲開發者囊中羞澀遊戲發佈的平台當作官網來用是很常見的,因為他們沒有發行商,就是在發行平台上自主發行作品。只是他們大部分作品往往不符合維基百科的收錄要求,符合關注度的作品本來大多就有發行商負責宣發,也有餘力架設官網。獨立遊戲很少多平台發行,因為平台上架費其實對也算小貴的。
中國大陸的開發者由於遊戲版號問題,無法對遊戲進行商業操作,回籠資金,只能透過境外發行作品,算是轉空子。而境外擁有大量中文玩家的遊戲平台目前就只有Steam一家。中國大陸特殊的遊戲開發環境造成獨立遊戲集中以Steam為發行平台,也以Steam為官網這種特別的景象,也許是只此一家。
日本的獨立遊戲開發者也有類似的情況,如DLsite的同人開發者只在DLsite發行,還有直接用DLsite內置的博客ci-en作為開發日誌發佈地。
上文提到的網絡指路問題,搜索系統並沒有想像中的智能。特別是中國大陸社交平台局域網化,搜索系統不如想像中中用。
此外發行平台(商店)也可以下場做發行商,他們也會物色作品去承包發行。上文提到的itch.io作為發行平台,也會在Epic商店以發行商身份出現的情況,此外DLsite也在Steam商店以發行商身份發佈作品。
題外話,如果發行平台有為作品「特設網頁」,是否可以視作可以保留的外部連結,如《与奴隶的生活 -Teaching Feeling-》現在的情況。--Nostalgiacn留言) 2022年7月14日 (四) 16:29 (UTC)
所以你们的讨论是没有共识吗?--百战天虫留言) 2022年7月22日 (五) 07:27 (UTC)
(+)支持(!)意見:個人建議條文修訂為「對於沒有獨立官方主頁的電子遊戲,可採用Steam等數字發行平台的頁面作為具官方性質之介紹主頁,否則不可加入。」大致綜觀以上站友討論,敝人對相關主題不甚熟稔,在有效介紹條目主題、提供讀者實用資訊、豐富條目內容、適度結合外部資源、增進使用者體驗、吸引用戶加入、推廣維基百科平台,且相關規範需配合現實環境與時俱進等考量下,個人對上方站友彙整提問之意見如下:
  • 對於官方平台之核心特質,個人認為關鍵在於條目主題本身對其有效控制之力度、該平台或頁面與條目主體之關係親疏遠近,以及其實質上平台或頁面對於條目主體具備之「專屬性」程度。若以上方提案內容而言,數位發行平台似屬「官方頁面」(作品既無開發商亦無發行商所設的專屬官方網站);然而此類數位發行或下載平台其介面、功能以及同時存在諸多其他同類商品之宣傳推廣和強烈商業性,一眼看去並非條目主體之作品所專屬,個人認為以平台使用介面和頁面實質用途而言,對於一般讀者的常識和主觀認知是否能稱為「官方」(比如:放眼望去處處可見其他作品,亦見其他知名大作同樣上架於此等),爭議頗大。
  • 承上,因此個人認為不適合使用官方網站模板,而依此案欲改善之問題且於使用上明確設限後,加入數位發行平台屬合適連結,可享實質官網待遇,但限以介紹主頁(隨機以《數碼寶貝 絕境求生》為例,收錄形式類似Steam《數碼寶貝 絕境求生》介紹主頁)),或是僅提及平台名稱之形式收錄(如有站友提及的與奴隸的生活 -Teaching Feeling- DLsite(日語))。
  • 若遇複數平台發行者,僅可揀擇頁面內容最完整且具代表性者列出;若連結頁面之內容相仿、雷同甚至相同,則揀取最具代表性之平台收錄(簡單說選擇對條目主題的作品發行而言最大、最紅、賣最好、銷量最高的平台)。
以上為個人意見,供參。--Kriz Ju留言) 2022年7月31日 (日) 19:44 (UTC)
  • 非专属平台的链接不适用{{官方网站}}模板,我基本赞成。值得同时探究与参考维基数据、英文维基等讨论和实践。
  • 段落二的举例大致赞成,唯“介绍主页”用词需讨论。第二种似乎较好,但格式(-/,/,/其他)可能尚难统一。
  • 段落三的意见,我个人赞成,但很可能仍存争议,平台代表性、友好度、关系亲疏、宣传性等平衡均可能产生争议。比如游戏在Steam卖的最好、在公司/母公司的网站上有介绍但页面非游戏制作/宣发团队管理、在母公司经营的平台上有销售但销量很低,究竟哪个页面最“具代表性”和官方,又是否随各页面的更新频次、质量而有取舍。
  • WP:ELOFFICIAL之“官方链接”的控制程度争议,我认为仍模糊、共识不足。在某些方面,有时难以辨别官网内容的制作和维护者,可能为自行维护更新,可能为上级或其他宣传部门维护更新或编排内容,还可能交由第三方公司搭建和直接维护(技术支持),条目主体的“控制能力”是否绝对影响页面作为产品/机构的“官方链接”(门面)的身份。

修正快速刪除方針

R7快速刪除準則自從2019年設立以來,屢次遭到濫用或擴大解讀,已然背離重新導向制度本身之精神、損及百科全書體系之運作。故在此提議修正快速刪除方針如下:

現行條文

(略)

R7. 明顯與導向目標所涵蓋的主題無關或比導向目標所涵蓋的主題更廣泛重定向

(略)

提議條文

(略)

R7. 明顯與導向目標所涵蓋的主題無關的重定向

(略)

此提案僅影響一般無需討論之快速刪除操作,若欲提刪者有扎實之提刪理據,仍然可以按正常程序提交各種存廢討論,不受任何阻礙。—— Eric Liu 創造は生命(留言留名學生會 2022年7月11日 (一) 09:17 (UTC)

R7修訂公示版本

现有的条文仍然相当含糊(参考w:WP:NEWCSD,快速删除条文应该详细到一般用户能明确判断一个页面是否符合快速删除标准)。建议改成如此(我其实2019年就提出了):

現行條文

R7. 明顯與導向目標所涵蓋的主題無關或比導向目標所涵蓋的主題更廣泛的重定向

提議條文

R7. 明顯與導向目標所涵蓋的主題無關或比導向目標所涵蓋的主題更廣泛的重定向

  • 条目完全未提及重定向的名称,或重定向名称比条目主题更广泛[1],但条目不含有重定向名称的有效介绍。同时,重定向名称并不是条目的别名或错误拼写。有争议的情况下,应提出存廢討論
  • 如果原重定向标题可改成消歧义页(或重定向至其他消歧义页),则不適用。
  • 掛有{{关注度重定向}}或{{合併重定向}}模板的頁面亦不適用,請改為提出存廢討論
  • 如有用戶對標題用字存在未解決的爭議,則應交由存廢討論處理。

例如: (以下扩充中)

R7适用和不适用情况举例
重定向页 重定向目标 重定向目标是否提到重定向页名称 是否符合(修订后的)R7
1669 1000
1025 1000
梁新武 第16屆桃園縣議員列表
广台高速公路 广明高速公路 有提及但无有效介绍
杭长高速公路 杭新景高速公路2019年版本 有有效介绍
金三胖 金正恩 - 因为重定向页是重定向目标的别名,无论是否提及都不符合R7
28机步 乔尔诺莫尔西克 (敖德萨州)
王贯一 王贯一 (飞行员) - 否,可改成消歧义
赖瑞 拉里 (猫) - 否,可改成消歧义
陳彥廷 (台灣) 陳彥廷 (1982年) - 否,可重定向至陳彥廷
Bh (字母) Bh (二合字母) - 否,因为重定向页并无歧义,所以属于“是条目的别名”的情况
洗脑:思想控制的科学 洗脑心理学 - 否,英文标题的直译属于“是条目的别名”的情况
强制拆迁 中国强制拆迁 无有效介绍 是,但是原标题可以改成set index
民国时期货币 中華民國貨幣 (1912年-1949年) - 否,是条目的别名
2016年中国矿难列表 2016年中国大陆矿难列表 - 见下
白羊座流星雨 白天白羊座流星雨 - 否,可改成消歧义
芬兰冰人 奇米·雷克南 - 否,如无歧义:是条目的别名,如有歧义:可改成消歧义
诺里斯 蘭多·諾里斯 - 否,可改成消歧义

--GZWDer留言) 2022年7月11日 (一) 16:45 (UTC)

(+)支持總體概念,GZWDer版更為清晰,(+)傾向支持該版本。--西 2022年7月12日 (二) 03:22 (UTC)
行。總之能避免濫用規則就好。—— Eric Liu 創造は生命(留言留名學生會 2022年7月12日 (二) 14:54 (UTC)
(+)支持(!)意見:以此列表而言,敝人表達個人意見:
  • 關於「金三胖」:目前未重定向至傳主條目,亦未見於當前導向之條目「中國大陸網路熱點事件列表」中存在相關內容(故目前實用性不明,抑或曾經人為移動編輯之類(笑))。個人揣想若回歸站友提案修訂之初衷以及一般「生者傳記」的重定向論之,假設該重定向已導向至傳主「金正恩」之條目,敝人傾向於:
  • 「重新導向目標是否提到重新導向頁面名稱」一欄認定為:「是,有提及但無有效介紹」,而「是否符合(修訂後的)R7」一欄為:「否,對於具攻擊或嘲諷性等負面或爭議內容之生者傳記重定向,由於事涉傳主人身名譽保護法益和相關法律風險(含編者自身可能遭遇之法律或訴訟風險),故涉及在世傳主人身形象評價之重定向於使用上,建議編者應確保該重定向同時符合可供查證、於公領域廣為使用、具大量可靠來源證其具備並非短期之顯明關注度,且其生成或存續之因果於公共領域具社會影響力為宜。」。
暫時沒意見。Sanmosa Királyunk s a közhazát 2022年7月16日 (六) 15:53 (UTC)
所以,2016年中国矿难列表應該是不符合吧?--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年7月17日 (日) 10:18 (UTC)
不符合。--Kriz Ju留言) 2022年7月17日 (日) 23:41 (UTC)

提案已14日且無反對意見,幫推一下,  公示7日,2022年8月1日 (一) 01:35 (UTC) 結束。--西 2022年7月25日 (一) 01:35 (UTC)

能否說明你要公示GZWDer版本還是Eric Liu 版本。--Ghren🐦🕕 2022年7月25日 (一) 10:28 (UTC)
幫ping@LuciferianThomas--🚊鐵路Railway 2022年7月28日 (四) 00:30 (UTC)
有副標題#R7修訂公示版本啊,而且公告欄的連結也是直指副標題。--西 2022年7月28日 (四) 03:49 (UTC)
我又不會從T:B直接點下去看。我認為現在的方案過於繁雜了,要合「新導向名稱比條目主題更廣泛」一項,則要排除「條目不含有重新導向名稱的有效介紹」、「重新導向名稱並不是條目的別名或錯誤拼寫」、「重新導向標題可改成消歧義頁」三項,以這繁瑣條件,基本上和廢掉沒有分別。還有什麼「如果原重新導向標題可改成消歧義頁(或重新導向至其他消歧義頁),則不應刪除。」,這裏的意思應該是不合此款而不是「不應刪除」吧。--Ghren🐦🕒 2022年7月29日 (五) 07:15 (UTC)
已代為對草案進行微調。—— Eric Liu 創造は生命(留言留名學生會 2022年8月8日 (一) 02:14 (UTC)
(!)意見:綜觀兩案,若以快速刪除方針主要用途為「加快處理顯然不合適的頁面或檔案的情形,如果有爭議的不應該適用。」之核心功能和意旨而言,上方提案精簡有力,敝人亦無甚意見。就個人粗淺認知,綜觀站友所提兩案之實際效果和用途皆為規限適用條件,而關鍵差異在於是否容許如「條目完全未提及重定向的名稱」即可適用快速刪除、「是否屬於條目的別名」、「是否可改成消歧義頁」等實務情境之明列,或可視實務需求考慮將下方提案之「例外排除情形的說明內文」適當納入結合(當中條文的字面可考慮異動為「如果原重定向標題可改成消歧義頁(或重定向至其他消歧義頁),則不適用。」。若相關修訂可增益於條文實務應用、減少誤用和濫用、降低不必要的判斷和無謂爭議甚至維運成本,或皆有益處。--Kriz Ju留言) 2022年7月31日 (日) 22:25 (UTC)

参考資料

  1. ^ 不包括列表项目重定向到列表。

修订编辑战方针

現行條文

下述行为在适用回退不过三原则时,不视为一次回退。

...

移除涉嫌诽谤、非中立、无来源或来源不充足,违反生者传记方针的争议材料。

提議條文

移除涉嫌诽谤、非中立、无来源或来源不充足违反生者传记方针的争议材料。

鄙人认为该方针有修改的必要性,因为某用户就以来源不充足为由在中华人民共和国条目大肆回退。“来源不充足”的理由可以适用于很多回退,故应加以限制。--QiuLiming1留言) 2022年7月12日 (二) 05:19 (UTC)

(-)強烈反对可供查證是維基百科的核心方針,此與是否編輯戰無關。方針不是給你改來改去搬龍門的。--西 2022年7月12日 (二) 09:03 (UTC)
您看方针页面后半句不都写着这个有争议吗?如果编者A,B都一直回退别人的编辑且都没来源,那这样岂不是可以无穷无尽回退?--QiuLiming1留言) 2022年7月12日 (二) 15:31 (UTC)
在英维问了一下 [3],他们均认为回退无来源的非生者传记是属于编辑战,应按照Wp:争议的解决处理。虽然WP:ENWPSAID,但可以作为参考。--QiuLiming1留言) 2022年7月13日 (三) 22:50 (UTC)
Special:diff/46256983等修改看得出這是為了生者傳記定的,和你這個中華人民共和國有什麼關係。--Ghren🐦🕛 2022年7月12日 (二) 16:22 (UTC)
[4] 方针写的是“或”,也就是如果少来源就可以回退,不需要属于生者传记,我就建议改一个字而已。--QiuLiming1留言) 2022年7月12日 (二) 16:38 (UTC)
他整句的意思是假如相關內容是「誹謗、非中立、無來源或來源不充足」且是「在世人物的傳記內容」,就合符相關的規定,而不是單純「不中立」、「沒有來源」就不作3RR之內,以此作為非3RR的理由必需要其內容不合於生者傳記方針。--Ghren🐦🕐 2022年7月12日 (二) 17:46 (UTC)
是断句问题?先前条文和当前提案感觉都不太好。另见en:Wikipedia:3RRNO的英文原文。建议:
  • 方案1:“移除涉及生者传记方针的涉嫌诽谤、有偏见、无来源或来源欠佳的争议材料。”
  • 方案2:“移除涉及生者传记方针的涉嫌诽谤、有偏见、无来源或来源不充分的争议材料。”
  • 方案3:“移除涉及生者传记方针的涉嫌诽谤或有偏见的无来源或来源欠佳的争议材料。”
相关想法:1. 仅观提案中的条文,我最初以为针对非生者的诽谤材料(如针对产品的指控)也因此条豁免3RR。2. “涉及生者传记方针”应是不限于人物条目,也包括其他条目中对生者的介绍和评价。3. 个人建议称“有偏见”(英文方针原文biased)而非“非中立”,非常中立的来源和评价并不多,宣传性语调等问题也不需豁免反复回退。4. “来源不充足”或难以判断,而“来源欠佳”是否比较容易,观其可靠性即可,充足性问题应经讨论决定(如所有来源的宣传性/地域中心)。英文原文poorly sourced。不过此条也可再议。5. 方案3想法是将无来源但不具明显问题的材料排除3RR豁免,虽有WP:GAME方针,如果有用户坚持移除生者传记条目中所有无来源脚注的材料(并拒绝自行查证、{{fact}}等方案),具此豁免是否不合适。--YFdyh000留言) 2022年7月12日 (二) 18:20 (UTC)
偏向第一条,都说了是争议材料不需要重复。--QiuLiming1留言) 2022年7月12日 (二) 18:47 (UTC)
(!)意見 “非中立”说的应该是写在维基百科条目的内容“非中立”,并不要求来源是中立的。--Yinyue200留言) 2022年7月13日 (三) 14:39 (UTC)
(-)反对:若这样修改,回退IP用户的多次破坏就会违反3RR。--BlackShadowG Slava Ukraini! 2022年7月13日 (三) 09:57 (UTC)
@BlackShadowG:"回退破坏不是编辑战",前面已经写了,不需重复规定。--QiuLiming1留言) 2022年7月13日 (三) 15:36 (UTC)
那鄙人支持此项修订。看了英文维基百科的原文,那边写的就是违反BLP的才算,可能是最初翻译不佳,导致现在被过度解读了。--BlackShadowG Slava Ukraini! 2022年7月17日 (日) 13:59 (UTC)
從頁面的敘述,修改的內容和下面的內容無關
回退自己的編輯(「自我回退」)。回退在自己使用者空間中的編輯,前提是你必須遵守使用者頁面指引。回退明顯的破壞行為,即指任何一個假定他人的編輯是出於善意的使用者都會認為是破壞的編輯,例如清空頁面或是添加攻擊性語言。移除明顯侵犯著作權,或是毫無疑義違反合理使用方針的內容。移除明顯違反維基百科伺服器所在地——美國佛羅里達州法律的內容,例如兒童色情內容或盜版軟體。為了確保在首頁展示的特色列表和優良條目的品質而進行的回退操作,給予使用者一定的自由空間。
(?)疑問 @QiuLiming1 移除涉嫌誹謗、非中立、無來源或來源不充足違反生者傳記方針的爭議材料。對於刪除何種內容可享有生者傳記方針豁免而不受回退不過三限制可能會存有爭議。遇有不清晰或有爭議,則建議先行提報至互助客棧,而非依賴前述豁免。為什麼有必要改成移除涉嫌誹謗、非中立、無來源或來源不充足違反生者傳記方針的爭議材料。對於刪除何種內容可享有生者傳記方針豁免而不受回退不過三限制可能會存有爭議。遇有不清晰或有爭議,則建議先行提報至互助客棧,而非依賴前述豁免。差別只有將,換成且--Rastinition留言) 2022年7月17日 (日) 14:07 (UTC)
@Rastinition: 已换成YF君的方案,“移除涉及生者传记方针的涉嫌诽谤、有偏见、无来源或来源欠佳的争议材料。”--QiuLiming1留言) 2022年7月17日 (日) 15:22 (UTC)
重申一遍现在的观点:改成移除涉及生者传记方针的涉嫌诽谤、有偏见、无来源或来源欠佳的争议材料。
另外我看到英维也在讨论相关条文(en:Wikipedia_talk:Edit_warring#Making_WP:3RRNO_point_7_more_specific),要不要等到他们讨论完后再做决定?--QiuLiming1留言) 2022年7月20日 (三) 22:32 (UTC)
(!)意見:個人認為可待英文維基百科相關討論結束後看看是否有可挪用補充之內容。--Kriz Ju留言) 2022年7月29日 (五) 21:34 (UTC)

提議設立容許查看私密資訊的用戶組/flag

續上#提议修改维基百科:防滥用过滤器的討論,建議將查看私密過濾器資訊的權限連同新IPInfo檢視權限分拆為另一用戶組/flag,及後若推行IP masking此用戶組亦可不需另加討論容許此具有此flag的用戶檢視原始IP。原先僅將私密過濾器的查看權限分拆過於雞肋,上方的討論也似乎不會有共識;忽然想起還有IPInfo和未來IP masking的資訊現在尚未可授予其他用戶,故想到將這些權限一併置入新設用戶flag。固然,這也代表回退員將被移除查看私密資訊的權限,這個權限的申請要求將更加嚴謹。設置此用戶組可在不需要額外調整既有的回退員申請標準之下同時達到改善私密資訊的保密性。提請社群討論是否設立此用戶組、申請資格(個人傾向此部分以站務經驗作為標準,再輔以簡單的信任投票)以及用戶組的名字。--西 2022年7月16日 (六) 15:17 (UTC)

通知參與上方討論的用戶。Sanmosa、​Temp3600、​Cwek、​Nishino_Asuka、​YFdyh000、​Antigng、​桐生ここ、​Tigerzeng、​KirkLU、​Ericliu1912、​脳内補完、​魔琴ZhaoFJx--西 2022年7月16日 (六) 15:22 (UTC)
感觉是值得考虑的方案,但是我简单想了一下发现实操会比较困难。既然是以查看隐私为主要目的的用户组,那么能否信任基本上是最最重要的考虑。在这个前提下考虑申请流程,我能想到的只会是类似于申请管理员的那种。社群又是否期待再多一个这样相对繁复的流程呢?--Tiger留言) 2022年7月16日 (六) 15:36 (UTC)
(+)支持 这样可以做到又防内鬼又能了解作用。不过不是特别建议合并,感觉有些冗余……?话说回来,倘若两者合并为同一权限组,可以在WP:EFH的基础上进行修改,不如叫「反破坏助理」() ——诚挚的 ZhaoFJx 2022年7月16日 (六) 15:43 (UTC)
當查看IP Masking權限之要求,基金會會如何設定仍是未知之數時,此案基本上無從說起。--J.Wong 2022年7月16日 (六) 16:17 (UTC)
T309318被回复之前,本提案无法推进,请等待。 Stang 2022年7月16日 (六) 17:17 (UTC)
(+)支持,很合理--脳補。◕‿◕。讨论 2022年7月21日 (四) 08:08 (UTC)
总感觉lta-wiki(或站务维基)也可能可以参考本案。 ——魔琴 [ 留言 贡献 ] 2022年8月1日 (一) 06:40 (UTC)
值得考虑,但需等待IP Masking权限之全景和颁授范围。--YFdyh000留言) 2022年8月4日 (四) 06:37 (UTC)

本章節暫時不存檔,直到相關技術問題解決。欲讓機器人存檔,請移除本模板。留言請置於本模板上方。

配置表单来方便用户发邮件申请账户或申请IPBE权限

目前一个用户如果在自己的IP被封禁的情况下希望注册账户,或是第一次申请IPBE权限,其需依照本指引中的要求需要发送邮件至unblock-zh lists.wikimedia.org来申请。目前可以想象的已知问题包括:申请人遗漏了部分信息、申请人发的邮件未遵照模板难以阅读、管管无法验证用户对应的IP地址是否真的被封禁了。为解决这些问题,在此提议在本站安装ContactPage这一扩展,并书写对应的配置文件来定义表单。

这一扩展可以根据配置文件生成表单,其中包括若干必填或选填项,且注册用户和匿名用户均可使用。当提交表单时,扩展会将表单中填写的信息(甚至可以附带上填写人当时的IP地址)以一定的格式发送给某个用户(在本站就可以发给User:Unblock-zh)。比较不好的地方是表单的栏目需要手写配置文件(参考元维基的配置),但也算是一劳永逸。样例可以看这个位于元维基的表单。本扩展已于元维基、Governance Wiki和荷兰语维基百科安装,因此个人认为安装应该不成问题。希望获得社群共识。 -- Stang 2022年7月16日 (六) 17:15 (UTC)

没有意见。未见说明,但该表单似乎不受IPBE影响。关于填入IP地址,建议为可选而非隐含,以利隐私选择权。--YFdyh000留言) 2022年7月16日 (六) 18:25 (UTC)
那啥,两个问题:
  1. IP被封禁能提交得了这个表单么?
  2. 这个扩展有啥防滥用机制么?会不会被利用来大量发送spam?--百無一用是書生 () 2022年7月18日 (一) 02:22 (UTC)
这个扩展本质是Special:EmailUser套皮。如果使用者被禁止发送邮件,那么他们就用不了这个页面;页面的使用也受到邮件相关的速率控制。--MilkyDefer 2022年7月18日 (一) 14:29 (UTC)
尴尬,如果被封了是不能发邮件的;有一个可选的captcha。鉴于本提案无法实现,撤回。 Stang 2022年7月18日 (一) 14:55 (UTC)
@Stang:奇怪的是,我在meta上用被封禁的IP(编辑页面,提示已封禁),可以用这个表单啊。之前尝试好像没见到验证码,这次尝试见到验证码。"Your account or IP address has been blocked."、"Email sent"。--YFdyh000留言) 2022年7月19日 (二) 03:48 (UTC)
我强调一遍,是被撤除了邮件权力的人不能用。Stang作为前行政员在封人的时候不可能没见过“不能发送电子邮件”的选项吧?除非封锁一个IP用户,会导致受其影响的无账号人员不能发出请求代为创建账号的表单。--MilkyDefer 2022年7月19日 (二) 06:44 (UTC)
很奇怪的是我昨天用了某个不能编辑页面的IP在匿名情况下发现是无法使用这一功能的,但是刚刚我尝试复现的时候似乎又没法重新复现…?话说回来,这个扩展是用$user->isBlockedFromEmailuser()来判断的,那如果封一个匿名用户会干掉sendemail这个权限么,如果没有的话那还有继续讨论的余地。 Stang 2022年7月19日 (二) 11:28 (UTC)
MilkyDefer已經完整說明了,我很意外前管理員怎麼會不熟悉封鎖的相關設定。--Xiplus#Talk 2022年7月22日 (五) 06:12 (UTC)
介面可以參考mw:Help:Blocking users/zh的附圖。--Xiplus#Talk 2022年7月22日 (五) 12:36 (UTC)
从未对匿名用户执行过禁止发送电子邮件的设置,因此完全不了解这一点。 Stang 2022年7月24日 (日) 13:06 (UTC)
似乎没有明确的反对意见,故公示7天。 Stang 2022年7月31日 (日) 17:46 (UTC)
表單的欄位是通過後再討論嗎?--Xiplus#Talk 2022年8月1日 (一) 01:00 (UTC)
可以同时或者之后讨论,我认为把要不要做和怎么做分开是合理的。 Stang 2022年8月1日 (一) 08:11 (UTC)

電視劇演員與角色排序指引

簡介 電視劇的演員排序無任何指引規範
問題背景 在編輯《基督山小姐》時,因為Wikipedia:格式手冊/電視Template:电视节目信息框並未規範或明述演員排序如何羅列而引發編輯戰。《基督山小姐》的片尾演職員與海報排序均為:「李昭娟、崔汝珍、鮮于龍女、李晃儀、⋯⋯、金美羅、景盛煥、李尚寶、李多海、⋯⋯」,但官網首頁的출연(出演)標示「李昭娟、崔汝珍、景盛煥、李尚寶 等」,등장인물(登場人物)也是將四名演員所演的角色列在前四位,產生衝突。
我的觀點
  1. 個人傾向參考MOS:TVCAST,應以影片本身的排序為首準,如片尾完整的演職員表等,而不是非影片本身及可能無法取得完整排序的官網。以《伊甸園之東》為例,李多海在片尾演職員表或是海報中,均被列在第三位,官網改版後,中途辭演的李多海在人物介紹中被移至第八位,不符合首播時的排序。
  2. 為避免造成解讀差異,排序不得任意略過。
  3. 本人以所涉略之美、加、英、澳、臺、日、韓、港等電視劇作為案例考量,若有疏漏其他案例可提出。
  4. Wikipedia:格式手冊/電視制定指引後,同步於Template:电视节目信息框/doc的主演欄提及。
我的解決方案
現行條文

演員及角色資料 一般而言,電視劇條目之內,角色及演員資料會以角色表或演員表方式鋪陳。角色表段落會包含「演員」、「角色」及「角色扼要介紹」;可參考天與地 (無綫電視劇)。依據格式手冊(文字格式),演員及角色不應用粗體或斜體標示。

另外,除非有多個可靠來源佐證,否則請勿標記角色性質,例如第一男主角、第二男主角、第一女主角等。至於演員條目內,如有參演電視劇列表,亦作類似安排,如無多個可靠來源佐證,請勿羅列角色性質,應以「主演」或「配角」代替。

提議條文

演員及角色資料 一般而言,電視劇條目之內,角色及演員資料會以角色表或演員表方式鋪陳。角色表段落會包含「演員」、「角色」及「角色扼要介紹」;可參考天與地 (無綫電視劇)。依據格式手冊(文字格式),演員及角色不應用粗體或斜體標示。

另外,除非有多個可靠來源佐證,否則請勿標記角色性質,例如第一男主角、第二男主角、第一女主角等。至於演員條目內,如有參演電視劇列表,亦作類似安排,如無多個可靠來源佐證,請勿羅列角色性質,應以「主演」或「配角」代替。

演員與角色訊息(含信息框中的主演欄)一般可以正式官方網站公開發布訊息收錄,若編者因對於作品之可靠官方來源選擇或判定不一,或因其他理由,導致對於演員排序認定歧異,則依序以下列來源為依據:

  1. 影片中完整的演職員表(如片尾演職員表或片中的跑馬字幕),若影片是依出場順序排序則不適用。
  2. 影片片頭的演職員排序,若影片是依出場順序排序則不適用。
  3. 官方海報的演員名單排序。
  4. 官方網站的演員或人物介紹排序。
  5. 其他官方發行產品上的演員名單(如相關刊物、影音產品包裝等其他多媒體)。
案例:
  1. 植劇場-荼蘼》的片頭與片尾排序不同,但以片尾完整的演職員排序為準。
  2. 追殺夏娃》的片尾是依出場順序羅列,《想見你》的片尾僅列配角演員名單,此情況則依序參考上列排序,如前者以片中的演職員跑馬字幕為準,後者則參照片頭演職員排序。
  3. 由於日劇演職員排序多為「主演、共演1、共演2、其他1、其他2、共演3、共演4」,條目中可將共演往前排序為「主演、共演1、共演2、共演3、共演4、其他1、其他2」。

若影片有不同官方版本(如因場次、地域、再版、媒介等因素而產生不同版本),導致演員名單排序不一,以作品首播、首映、首發之原產地版本為準。而演員退出、辭演或角色身亡、刪除等,因考量資料收錄完整性,仍可保留在名單之中。

此前的類似討論

--Sa Young Sun留言) 2022年7月16日 (六) 19:14 (UTC)

不是啊,你這樣寫還是沒解決《基督山小姐》的問題啊,影片中完整的演職員表、海報、官網誰的優先度高不就是問題所在。 --窝法乙烷 儿法梦碎 2022年7月17日 (日) 02:32 (UTC)
制定指引就是解決問題啊,且還得適用於所有電視劇,目前優良條目、典範條目都符合此方案,「我的觀點」已明述我的立場,有異議歡迎提出來討論,比如疏漏且不適用的特例等。以往影視條目的爭議發客棧都沒人要回應,就連刪除來源的編輯爭議都沒人管,已經是走投無路了。  囧rz……--Sa Young Sun留言) 2022年7月17日 (日) 05:13 (UTC)
  • (!)意見:敝人認為,若編者產生強烈分歧致無法達成共識,個人傾向於以一般讀者可簡易公開查閱、可直接添加參考資料來源之官方來源為準;若該作品不僅具備單一公開官方來源(亦即可能有複數官方來源,可能二、三個以上之類,如官網和海報,或同時有官網或官方粉絲團等)或公開的官方來源有所異動致產生歧異,甚而不具公開可靠之官方來源(亦即可能官方來源本身沒公布完整名單,或是可能只能自己查找影片名單之類),以編者達成共識為準。個人第一時間偏好「正式的官方網站」,若真無選擇或始終無法達成共識,只得直接翻看「影片片尾的完整演、職員名單」(個人認為片頭名單常僅見該作的主要演、職員)。
敝人主觀以為如何排序或可尋求證明,惟未見明確規範之必要,其中區別對於一般不甚理解主題之讀者或初來乍到之編者無顯著差異。若須訂立相關規範,細節可由熱心站友共商。
  • 無適當理由移除可靠來源為破壞行為,遇此情形請適當以反破壞警示模板升級警醒相關編者,警諫等級提升後若仍未見改善,請再行提報。
  • 面對條目編輯爭議,若有編者持續無適當理由而拒絕溝通或提供來源和理據,僅以編輯戰反覆回退,顯為不當態度或行為,請相關編者於確認對方拒絕溝通、表達自身意見或提供理據後逕行提報。
以上為個人意見,供參。--Kriz Ju留言) 2022年7月17日 (日) 13:40 (UTC)
如果出现同一影片不同版本(场次、地域、再版、媒介)的演员表排序不同的情况呢?如果官方来源随时间变化了呢(如赵薇被除名)?--Benevolen留言) 2022年7月17日 (日) 16:59 (UTC)
(!)意見:敝人已於前段表達:若該作品不僅具備單一公開官方來源,或公開的官方來源有所異動致產生歧異,甚而不具公開可靠之官方來源,以編者達成共識為準。若同作影片內的名單仍各有版本、相互歧異、錯綜複雜,個人偏好作品首播、首映或原產地版本(若閱讀簡易,有需要或可再補充與其他版本之名單差異,這部分應可由編者發揮),但編者能相互達成共識更好。至於遭除名者,為資料完整性考量,個人認為收錄較佳,附註說明該演員遭除名之原因和事由即可。--Kriz Ju留言) 2022年7月17日 (日) 23:31 (UTC)
(:)回應:若是以官方網站為首準,這會影響到英、美、加、澳、臺等電視劇條目,英美等地的演員排序會有冠上with或and的情況(韓國用그리고、日本為尾番),代表該演員雖然被列在名單的尾端但舉足輕重(如《美麗心計》的梅莉·史翠普),這與官網的排序可能有出入,即無法表現,雖然一般讀者可能沒察覺。且演員究竟是主演、配角、guest還是special guest,也是要透過影片的演職員表才能確認。
我認為影片本身較能代表製作方的資訊(且完整),官網是由電視台建構,未必能正確、完整揭露,此前的類似討論中也點出官網不適用於港劇的例子,加上我所提及的案例,顯示官網不確定性相對高。或者,若以官網為準時,要用什麼但書來避免有誤的情況。畢竟有共識還能從寬,但有爭議就得參考指引。
關於影片也可能有異動,MOS:TVCAST: "their place in the list should be based on the order of credits in the first episode that they appear",以「首次」為概念的話,我也傾向參照「作品首播、首映或原產地版」。--Sa Young Sun留言) 2022年7月18日 (一) 07:07 (UTC)
要不要@當事人,他們反對不也是有他們的根據,把各種可能列出來大家也好看清楚哪種方式具有可行性,誰又比較好執行。 --窝法乙烷 儿法梦碎 2022年7月19日 (二) 14:18 (UTC)
@Stevencocoboy我的討論頁有他的回應,也可請他再做回應。--Sa Young Sun留言) 2022年7月20日 (三) 05:27 (UTC)
(!)意見:敝人對此類官方資料來源了解不深,稍加補充個人考量和理據。首先,個人認為太多版本、複雜、零散的來源多有歧異,所以海報或周邊產品等來源並非首選,也太容易起爭議。其次,如果連官方網站都不準,需要熱心資深編者告知其中差異甚至引用規則,這對一般想參與編撰入門的編者恐怕不甚友善,所以我認為第一時間仍需考慮來源的公開易得性和使用者直覺性。再次,的確是作品本身的片尾名單最完整。綜合以上考量彙整內容為:
「演員與角色訊息(含資訊框中的主演欄)一般可以正式官方網站公開發布訊息收錄,若編者因對於作品之可靠官方來源選擇或判定不一,或因其他理由,導致對於演員排序認定歧異,則依序以下列來源為依據:
1.影片中完整的演職員表(如片尾演職員表或片中的跑馬字幕),若影片是依出場順序排序則不適用。
2.影片片頭的演職員排序,若影片是依出場順序排序則不適用。
3.官方海報的演員名單排序。
4.官方網站的演員或人物介紹排序。
5.其他官方發行產品上的演員名單(如相關刊物、影音產品等其他多媒體)。
若影片有不同官方版本(如因場次、地域、再版、媒介等因素而產生不同版本),導致演員名單排序不一,以作品首播、首映、首發之原產地版本為準。(後略)」
個人意見,供參。--Kriz Ju留言) 2022年7月28日 (四) 21:25 (UTC)
已更新。同意有爭議時,再行參考的方案不錯。--Sa Young Sun留言) 2022年7月29日 (五) 02:13 (UTC)
(-)反对,規定先後順序的意義是什麼?為什麼老是要無中生有製造一些毫無意義的問題,確定誰先出場、誰比較重要?這連 fandom 的各個 wiki 都不會這麼幹吧。請先證實問題的必要性再來討論如何解決問題。--Austin Zhang留言) 2022年7月29日 (五) 19:12 (UTC)
(!)意見:個人認為,此提案產生的背景在於編者對於「演員順序」所選擇或偏好之資料來源認定不一,所產生難以達成共識之編輯戰或相關爭議,初步考古這似乎也是此主題爭論已久的課題。以主要演員或主演群而言,演員排序大致上可提供諸如:演員所飾角色於劇中的份量或重要性、演員本身在業界的聲望或地位等訊息,因此亦成為劇迷或影迷於條目中可能不斷爭論之焦點。此時,若對於究竟應以何種資料來源作為優先參考基準難以達成共識,除了讓相關編者徒耗心力於相關爭議上,亦某種程度妨礙編者將本就有限之時間和心力投入編著或創建條目,反倒有礙條目內容之增新充實;長久下來,除了參與的編者可能因不時產生的編輯戰心力耗損,亦於用戶間徒生磨擦和爭議,進而干擾或妨礙彼此之間原先可能的合作空間。不論怎麼看,對條目編輯和用戶協作皆非美事,亦顯無裨益。正因對一般讀者而言可能不見得關注演員排序的細微差異,此類細節反而對活躍或資深且熟悉此領域的熱心編者而言更為關注、重要,若能產生一個更有效率的來源判讀爭議解決方案,相信此後對於條目、編者、促進合作、減少過多爭論以及難以解決之編輯戰等面向將大有助益。--Kriz Ju留言) 2022年7月29日 (五) 20:13 (UTC)
你只是剛好沒遇到瘋子罷了,用音樂條目來看就是一群人大吵特吵哪個音樂類型先放、哪個製作人先放(好險飯圈只會爭C位不會在乎幕後工作人員的辛勞)。 --窝法乙烷 儿法梦碎 2022年7月30日 (六) 02:50 (UTC)
我觉得你与其这么说,不如直接给他几个疯子发癫现场看一看……--MilkyDefer 2022年7月30日 (六) 11:25 (UTC)
  • (!)意見:個人希望再做些微調整,考量和理據如下:
  • 關於「官方海報的演員名單排序」等條文似乎少了句號,另個人建議「正式條文」和「文中案例」以括號略作分隔。
  • 關於「其他官方發行產品上的演員名單(如刊物、DVD等)」:個人認為隨著時代背景差異、各種媒介載體有別,此處僅列出DVD,往後會否可能因載體差異而產生其他爭議(如:BD、VCD、LD、錄影帶、原聲帶等)?個人的考量是以概括性統稱不寫死即可,最理想的情況其實是盡量避免列舉式文字。另外,個人認知這裡指的「DVD」是指「產品包裝或外盒上的名單」;若否,則一開始不斷談及的「影片」為何,似有爭議。
  • 關於「演員退出、辭演或角色身亡、刪除等,仍應保留在名單之中,也不得任意略過。」:個人認為此條文似可再論,建議改為「演員退出、辭演或角色身亡、刪除等,因考量資料收錄完整性,仍可保留在名單之中。」即可。用「應....不得...。」將使此條文成為一種帶有懲罰性禁制措施之「強制性規範」,個人認為不符比例原則,彷彿參與的編者只要沒寫好或未收錄完整就要受到何種懲罰似的,那麼萬一編者因版本異動而不知、忽略或主動省略異動的演員而沒寫到是否要受罰呢?個人認為不甚妥適。且萬一與下方作品首播、首映、首發之原產地版本名單相衝突(比如該版本名單未收錄離開的演員),又產生矛盾。個人認為實務情境或許是:不想寫或沒寫到的人沒什麼錯,而想寫的人能適當合規寫上去並獲保留、不另遭遇無謂爭議即可,而非看似迫使編者沒寫到就得受罰。
  • 承上,因此以上方「名單的來源先後順序」條文作為「一般性通則適用」,後者的「異動後仍保留名單」條文做為「豁免性個案處理」,敝人認為行文先後次序應對調方合乎原提案意旨、實務應用和讀者理解。
  • 綜上所述,敝人再彙整調整為:

「(前略)

1.影片中完整的演職員表(如片尾演職員表或片中的跑馬字幕),若影片是依出場順序排序則不適用。
2.影片片頭的演職員排序,若影片是依出場順序排序則不適用。
3.官方海報的演員名單排序。
4.官方網站的演員或人物介紹排序。
5.其他官方發行產品上的演員名單(如相關刊物、影音產品包裝等其他多媒體)。
(案例略)
若影片有不同官方版本(如因場次、地域、再版、媒介等因素而產生不同版本),導致演員名單排序不一,以作品首播、首映、首發之原產地版本為準。而演員退出、辭演或角色身亡、刪除等,因考量資料收錄完整性,仍可保留在名單之中。」--Kriz Ju留言) 2022年8月1日 (一) 10:55 (UTC)
已更新,請複查。不過「正式條文」和「文中案例」以括號略作分隔這部分括號是建議加在何處?--Sa Young Sun留言) 2022年8月1日 (一) 15:41 (UTC)
敝人已直接自行稍作異動於「如片尾演職員表....」處,已無其他意見,請複查。--Kriz Ju留言) 2022年8月5日 (五) 21:05 (UTC)

有关节目列表条目的删除标准的补充讨论

遇到的问题 有关节目列表条目的删除标准的补充讨论
问题背景 OO电视台外购XX节目列表的问题类似于OO节目列表
我的观点 相关外购节目列表有可能会违反下面的方针
  1. WP:NOTDB(“主题关系松散的数据库或列表”)
  2. WP:NOTIINFO(“维基百科的条目并不是过度统计清单。”)
  3. WP:VERIFY(编辑者应为条目中的内容及其引用提供可靠来源。(这些条目涉及的即将播出节目的资讯内容可能会涉及到不可查证来源(例如某家电视台的广告商节目表)以及不可靠来源(例如新浪微博网友的猜测))
  4. WP:NOTE(这些条目基本上都是从已有的列表中拆分出来的没有对应的独立关注度)
我的解决方案 参考WP:TVCONTENT的解决方案统一搬到相关的爱好者网站
此前的类似讨论
  • 此前有没有过与本提案主题类似的讨论?有没有人遇到过相同问题?
  • 请在这里罗列,并给出对应的链接。

Wikipedia_talk:格式手冊/電視/存檔二#有關節目列表條目的刪除標準

--我永远喜欢末门牙王-第七号台风————查~帕~卡~——有——蓝屏死机 …….. 2022年7月18日 (一) 09:15 (UTC)


即使是英文維基百科也有en:List of television programmes broadcast by the BBC,而且已經存在了20年,所以我在5月說過「我不明白Wikipedia:维基百科不是什么明明是參考英文維基百科對應頁面創建,但是在中文維基百科就發展成、被詮釋成一套比英文維基百科那邊更加嚴苛的標準。」另外,對於不懂俄文的中文維基百科用戶來說,華語電視台的節目播放列表應該還是較古羅斯歷史條目更易查證。--Mewaqua留言) 2022年7月20日 (三) 03:04 (UTC)

最后一点我不认同(之前和现在播出的节目还算是可以查证但是未来播出的节目真的很难查证(七天内播出的还好未来一个月两个月的就真的没法做到可供查证。(例如勇者斗恶龙 达尔的大冒险将于今年一月份在翡翠台播出的不实消息到了今年一月份之后被证实为假消息后才被删除)(因为涉及到不可查证来源之前在中维TG群探讨过相关问题结果就是类似于广告商节目表(这种东西一般都是属于商业机密算是不可查证来源)这类的消息以及新浪微博上发布的节目播出资讯(涉及到原创研究)都属于不可靠来源)以及某些动画自媒体可能会把维基百科当成可靠的来源去发布相关动画资讯甚至有的维基人把相关列表的内容写进维基百科的动画条目中这种行为本身也违背了维基百科本身不能作为参考来源的原则))--我永远喜欢末门牙王-第七号台风————查~帕~卡~——有——蓝屏死机 …….. 2022年7月20日 (三) 04:39 (UTC)
難以查證的「未來播出的節目」記項可以刪除,就如假設有人在「地球」條目加入難以查證的文句,其他人看到之後,刪除該等內容即可,而不是提出刪除整個「地球」條目。--Mewaqua留言) 2022年7月20日 (三) 11:41 (UTC)
而且这些列表的话基本都是从别的列表中拆出来的(单独拆出来的话可能没有独立的关注度例如:Wikipedia:頁面存廢討論/記錄/2021/12/16#Now寬頻電視/香港電視娛樂外購劇集列表)而且这些拆出来的列表基本都是属于POVFUN早就应该删除了只不过由于历史遗留原因才能存在至今--我永远喜欢末门牙王-第七号台风————查~帕~卡~——有——蓝屏死机 …….. 2022年7月21日 (四) 09:43 (UTC)
en:Lists of TVB dramas and seriesen:Category:Lists of television series by network。--Mewaqua留言) 2022年7月24日 (日) 03:11 (UTC)
实际上英语维基的节目列表根本就有按照节目是否外购来拆分节目列表(这个现象是中文维基独有(尤其涉及到香港电视相关的列表))建议这种内容还是搬到相关爱好者网站比较好--我永远喜欢末门牙王-第七号台风————查~帕~卡~——有——蓝屏死机 …….. 2022年7月24日 (日) 08:19 (UTC)
保留,如内容不可查证则可移除不可查证的内容。--Yinyue200留言) 2022年7月31日 (日) 12:49 (UTC)

提议修改优特内容评选规则

提议修改所有优特内容评选规则,提名人或主编需回应所有意见,除明显的扰乱性意见以外,对于合理意见,应当按照意见修改候选条目,对于不合理意见,应当说明其不合理之处。到投票期结束为止,未对意见做出合理回应者,即使票数达标,也应当落选。--——٩(๑❛ᴗ❛๑)۶这里是浣熊君(Raccoozzy)浣熊窝欢迎您】 2022年7月19日 (二) 14:08 (UTC)

以优良条目为例:

現行條文

评选期为7日。评选期结束后绝对票有至少6票符合优良条目标准(“符合优良条目标准”和“不符合优良条目标准”相互抵消,如8符合,2不符合,绝对票就是6),且不符合优良条目标准票数低于或等于总票数三分之一(如16符合8不符合。另中立票不计入总票数,仅有参考意义),该列表就入选或维持优良条目(如果已经是优良条目)。如时效已过未达要求,提名条目从名单删除并存档。

提議條文

评选期为7日。评选期结束后绝对票有至少6票符合优良条目标准(“符合优良条目标准”和“不符合优良条目标准”相互抵消,如8符合,2不符合,绝对票就是6),不符合优良条目标准票数低于或等于总票数三分之一(如16符合8不符合。另中立票不计入总票数,仅有参考意义),且提名人对所有意见给出合理回应(对于合理意见,应当按照意见改进候选条目,对于不合理意见,应当说明其不合理之处,明显的扰乱性意见除外),该列表就入选或维持优良条目(如果已经是优良条目)。如时效已过未达要求,提名条目从名单删除并存档。

——٩(๑❛ᴗ❛๑)۶这里是浣熊君(Raccoozzy)浣熊窝欢迎您】 2022年7月19日 (二) 14:23 (UTC)

如此者投票期理應相應延長以讓編者有時間修改。--Ghren🐦🕙 2022年7月19日 (二) 14:47 (UTC)
這是否能算是內容評選從投票制轉向共識制的一種跡象?—— Eric Liu 創造は生命(留言留名學生會 2022年7月19日 (二) 14:55 (UTC)
不算。共識制也不是波蘭式一票否決權Sanmosa Királyunk s a közhazát 2022年7月19日 (二) 15:03 (UTC)
(-)反对,提案很明顯可以被鑽漏洞,也為參與評選者帶來不必要的麻煩。雖然情況較極端,但中文維基百科之前在其他類型的投票都有類似的問題,所以還是舉一下例:假設現在有一個FA評選已有足夠票數通過,有人在評選期結束的幾分鐘前加插一個意見,就算他投的是yesFA,根據提案,該FA評選亦將作不通過論,這明顯是不合理的,也同時違背該投票人的意願。提案人應無此意,但各內容評選中刻意找條目主編或提名人的麻煩的用戶並不在少數,我認為此提案就算作出任何的微調均無法妥善解決此一根本性問題。Sanmosa Királyunk s a közhazát 2022年7月19日 (二) 15:03 (UTC)
感谢阁下的建议,您说的情况我也考虑过,我认为可以相应修改评选期的规定,例如,在距离评选期截止不足24小时的时间内添加新的意见的,评选期延长至自该意见添加之时的24小时后(具体时间可以讨论)。反复在截止前添加无意义的意见或明显的扰乱性意见,导致评选无法结束的用户视为破坏。——٩(๑❛ᴗ❛๑)۶这里是浣熊君(Raccoozzy)浣熊窝欢迎您】 2022年7月19日 (二) 15:18 (UTC)
問題未獲根本性解決。假設延長的次數是有限的,我上方提到的問題顯然仍然存在,而假設延長的次數是無限的,可以被鑽的漏洞就變成不斷提意見使評選期遭無限延長,此無異於延宕否決(suspensive veto),就優特內容評選而言實屬浪費社羣資源。另一方面,「反覆」的定義不明,而且有些人是會刻意隔幾個月這樣來一兩次的,也不算「反覆」。我認為如果真的想從投票制轉向共識制的話,惟一可行的辦法是一次性直接變更制度為共識制。Sanmosa Királyunk s a közhazát 2022年7月19日 (二) 15:26 (UTC)
隔几个月这样来一两次似乎问题不大,不过是每隔几个月有一两个评选被延长一天而已。我所说的「反复」指的是在同一次评选中的「反复」,导致该次评选无法结束的。--——٩(๑❛ᴗ❛๑)۶这里是浣熊君(Raccoozzy)浣熊窝欢迎您】 2022年7月19日 (二) 15:41 (UTC)
那還是回到「反覆」的定義不明的問題了,不同管理員的判斷均不同,這樣很容易令主編直接放棄條目。Sanmosa Királyunk s a közhazát 2022年7月19日 (二) 15:56 (UTC)
個人樂見這種轉變,但是感覺執行上有系統性問題。比如提名者可否用「意見是FA標準的要求,現在只解決不符合GA標準的問題」(可能措辭更委婉)回應?如果這樣謝絕修改算有效回應,那我認為我們現在的方針指引和操作慣例還跟不上。畢竟「符合GA標準」的條目是甚麼樣,大家看法可能都很不一樣。--洛普利寧 2022年7月19日 (二) 15:15 (UTC)
提名人與投票人意見走向兩極是常有的事,現在DYKC就一個已連續5次落選的案例,每一次都在爭論同一個問題。如果這類案例發生在GAC/FAC,雙方到了限期尾聲仍不斷持續爭論,假如新規則又可以無限延長,有否想過這可能造成的積壓?--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年7月20日 (三) 14:43 (UTC)
这种情况下可能需要第三方[谁?]的介入。总之我也很乐于见到条目评选从纯投票制到共识制的转变。--BlackShadowG Slava Ukraini! 2022年7月21日 (四) 12:41 (UTC)
不太赞同,GA和FA不需要是完美的条目。--Yinyue200留言) 2022年7月31日 (日) 12:54 (UTC)

维基百科:关注度/提报問題

請問這個頁面中的條目一定要按照UTC時間才能算到期並提報嗎?我今天在UTC+8 7:00左右提刪6月27日提報的條目,鐵路1在User talk:日期20220626#AFD叫我8:00(UTC+8)後提報,我對這個以UTC為中心的做法表示質疑,因為中文使用者大部分都居住在UTC+8,自己沒必要去跟著UTC來。

我在他的討論頁User talk:鐵路1#AFD問題表示日語維基就按照他們UTC+9的時區行事。例如,7月24日 UTC+9 0:00過後提刪的條目就算在7月24日的提刪討論頁面,而此時UTC還是2022年7月23日。

我又來到twinkle的telegram群組詢問xiplus([5]),twinkle提刪能否自己設置時區(目前在UTC+8 8:00前用twinkle提刪,條目或頁面會算在前一天的存廢討論,除非自己手動更改),xiplus解釋「站務運作遵循一套統一標準」,我表示為何要以UTC為標準,根本就沒有多少人居住在UTC,不應UTC就是所謂的標準時區,一大堆UTC+8的人就要圍著UTC團團轉。--日期20220626留言) 2022年7月27日 (三) 02:22 (UTC)

方便技术实现吧,统一使用UTC作为时间划分标准,可以不用考虑因为时区差异而需要调整的处理。而且不要假设全部中文区编辑都在UTC+8区。——Sakamotosan路过围观 | 避免做作,免敬 2022年7月27日 (三) 03:00 (UTC)
不就跟北京时间#中国西部地区时间问题一樣?不住在UTC+8的也要配合用UTC+8。--Xiplus#Talk 2022年7月27日 (三) 03:51 (UTC)
所以爭議就出在要不要以某個時區為標准,這樣的話UTC也好UTC+8也罷都一樣,而且以前者為標準更不合理。--日期20220626留言) 2022年7月27日 (三) 04:18 (UTC)
其實吧,差八個小時而已,不一定要這麼嚴格,早一點提報也沒什麼影響。—— Eric Liu 創造は生命(留言留名學生會 2022年7月27日 (三) 04:14 (UTC)
那個群你也在現場,xiplus居然直接跟我說這叫「搗亂」了。--日期20220626留言) 2022年7月27日 (三) 04:21 (UTC)
Special:Diff/72912490,故意在錯誤的日期提報存廢討論,以及故意不使用簽名語法產生的時間戳格式,不僅僅是「搗亂」,而是WP:擾亂了。--Xiplus#Talk 2022年7月27日 (三) 06:35 (UTC)
就是因為現行的所謂UTC的機制,UTC+8 7月27日 7:28的提刪,你們叫我去7/26的頁面提報,到底哪個才是擾亂?非要一個生活在7月27日的人在維基穿越到7月26日?難道你們都生活在UTC+0以及以西的時區?
至於簽名語法,純粹是懶得改成「--~~~~」,倒不是故意要用+8。--日期20220626留言) 2022年7月27日 (三) 06:46 (UTC)
對啊,就是生活在這些時區啊。難道不存在這樣的編輯者嗎?--Xiplus#Talk 2022年7月27日 (三) 06:56 (UTC)
那這樣的編輯算是多數還是少數?维基百科:统计#用户来源分布,編輯用戶中UTC佔比只有可憐的1.5%, 81.6% UTC+8的人難道真的要以UTC為準?--日期20220626留言) 2022年7月27日 (三) 07:12 (UTC)
示例:如果你希望改變現行的提刪程序……理當爭取大家的一致意見。而不要故意違反現行程序。--Xiplus#Talk 2022年7月27日 (三) 06:38 (UTC)
所以今天有人跟我意見不同,你在那個群也不同意我的做法,我不就來互助客棧討論了嗎?不要動不動說別人「故意」。「子非魚,安知魚之樂?」--日期20220626留言) 2022年7月27日 (三) 07:06 (UTC)
您不是先徵求大家意見,而是已經做出錯誤的行為了。既然Twinkle或是站內的提刪按鈕都是指向7/26的頁面,那您就是應該先遵從這個指示,再來提出這是否有問題,而不是逕自違反這個指示。--Xiplus#Talk 2022年7月27日 (三) 07:16 (UTC)
我认为把本站时区改为UTC+8更合理。现有289个站点设置了自己的时区,技术上是没问题的。--Lt2818留言) 2022年7月27日 (三) 07:52 (UTC)
技術當然是沒問題,但問題是需要調整許多的基礎建設(模板、小工具、機器人)。--Xiplus#Talk 2022年7月27日 (三) 08:03 (UTC)
可能连一些管理数据会有问题,例如现在{{unsigned}}的时间是要求是UTC的,只需要直接复制页面历史的时间就可以了,改动了站点的时间设置会影响这个数据的录入。——Sakamotosan路过围观 | 避免做作,免敬 2022年7月27日 (三) 09:28 (UTC)
我认为技术实践优先于用户体验,如果强行修改站点时区,可能会影响很多“基础设施” 、涉及时间的规则的设计、配置、计算等。而且无法排除不在UTC+8外的用户,UTC是一个相对公正的时区标准。跨时间的影响可能有限,按照正常的作息从早上6点开始的话,到8点也就是2个小时的日期差。——Sakamotosan路过围观 | 避免做作,免敬 2022年7月27日 (三) 09:39 (UTC)
說到底還是路徑依賴,而不是所謂的UTC有多麼公正。--日期20220626留言) 2022年7月27日 (三) 09:51 (UTC)
使用UTC在「技術上公正」。--Xiplus#Talk 2022年7月27日 (三) 10:05 (UTC)
没办法,已经发生了。但还是可以灵活解决(例如一些依据日期提报但“放错”时间的提请,可以移到正确的时间上来回避)。——Sakamotosan路过围观 | 避免做作,免敬 2022年7月27日 (三) 11:51 (UTC)
改时区似乎并不能解决提报“放错”时间的问题吧?--百無一用是書生 () 2022年7月28日 (四) 02:18 (UTC)
改時區就可以使用#timel函數,會比較方便設計模板。--Xiplus#Talk 2022年7月28日 (四) 02:48 (UTC)
  • 因为迁移的技术成本+地域中心之说吵不出结果,所以一直沿用UTC。签名时间、存废讨论、首页内容等,都是按UTC在走。你说这造成不便,大家能理解,但说别人针对你、我就要按自己的理解来提交,我就不能理解了。
  • 并建议搜客栈存档,这个问题可说是WP:常年提案2005年就提出和深入讨论过,“xx中心”之说在那时就有。2013年1月等也有人提出过。2012年在客栈,就首页内容更新时差——Wikipedia_talk:历史上的今天#首页“历史上的今天”可否于每日UTC+8零时更新?吵得很凶,诞生了自选小工具方案,但问题是否算解决。也请参考其中的各种意见,不少用户认为“摒弃UTC”是地域中心之举。
  • 个人来说,UTC在我的维基生涯中偶尔造成不便(比如、尤其是填写{{未签名}}参数),更改对我有利,但我对说服部分用户所坚持的地域中心、地区/人数霸权等说法毫无信心,也对平稳迁移站内外所有工具没有信心,很多数据资料没有时区信息,势必造成不少千年虫式混乱。--YFdyh000留言) 2022年8月4日 (四) 10:33 (UTC)

修改"特色图片标准"

目前的特色图片标准中,有一条为“具有描述性、翔實且完整的英語文件描述”。这一条文由A1Cafel加入,猜测为对共享资源或别的项目类似标准的翻译;后由12З4567写入“評選程序”页面。由于这是一个中文站点,个人认为照搬其他语言项目/多语言项目的标准并不妥当,故提议修改为“具有描述性、翔实且完整的中文文件描述”,下面的详细说明同时进行微调。-- Stang 2022年7月29日 (五) 11:58 (UTC)

(+)支持--飛馬🎠🎈 2022年7月29日 (五) 14:32 (UTC)
(+)支持--Yinyue200留言) 2022年7月31日 (日) 12:59 (UTC)

提議新增一條有關條目評級的指引

由於在維基百科中有許多的專題是十分不活躍的,甚至有的已經廢除,所以在下想新增一條指引,來處理這些沒有所屬專題條目的評級,而在下製作的草本為wp:ge,翻譯至英維,並做出了修改。(此草案在英維為編輯指引)--飛馬🎠🎈 2022年7月29日 (五) 14:47 (UTC)

(+)支持。如果通過,建議後續在不活躍專題的評級頁面中,增加連結到此頁面。不過因為草稿最後使用了「條目評級專題」的用語,或許可以考慮重啟WikiProject:條目質量評級,並將該專題覆蓋範圍改成類似「凡無所屬專題,及所屬專題已不活躍或廢除的條目,由本專題負責評級其品質」的定義(不包含重要度評等)。--S099001留言) 2022年7月31日 (日) 06:59 (UTC)

提議將格式手冊/序言章節#列明來源設為方針指引

近日Wikipedia:優良條目評選/提名區有編輯表示「Top(導言)整部分缺乏來源」,雖然大家長久以來都習慣不塞來源,但這畢竟是闖紅燈行為,所以敝人提議將Wikipedia:格式手冊/序言章節#列明來源設為方針,永絕後患。 --窝法乙烷 儿法梦碎 2022年7月29日 (五) 16:03 (UTC)

個人認為序言部分,經常有人「原創總結」,還有就是有些編輯習慣把新的內容加到序言,正文不加,導致序言不斷膨脹。這些風尚沒有改善,還是保有來源比較好。--Nostalgiacn留言) 2022年7月30日 (六) 02:18 (UTC)
雖然這樣講有點過分,但大哥你原神角色條目一堆導言沒加來源耶。序言章節#列明來源寫說可以不在導言列來源不等於內文不用,文章講述「導言通常被寫成是比條目主體層次較淺的概述,而在序言章節中無爭議的東西看似是較少會被質疑的,繼而看似是較少機會被要求列明來源;不過這不是說序言可以例外地繞過參照要求。序言是否有必要列明來源應個別地、以編者共識來處理。複雜的、正在發生的、或有爭議的事項可能需要列明來源;其他的則列出少量甚或不用列出。這裡不要求也不禁止條目的序言作出參照,而需視不同狀況而定。」並沒有禁止列明來源,而閣下擔憂的序言膨脹不論此方針是否通過都沒差,因為這是人的問題,看看同樣防軍子不防小人的Wikipedia:列明来源。 --窝法乙烷 儿法梦碎 2022年7月30日 (六) 16:49 (UTC)
確定是防君子不防小人。其實Wikipedia:格式手冊/序言章節已經事實上作為GA的標準。如果只是針對優良條目評選的提名區「Top(導言)整部分缺乏來源」的情況,其實完全可以給出WP:LEADCITE說理。
過去個人是序言也加上來源的(《聖女戰旗》),也就是評選了GA後,才發現WP:LEADCITE部分情況豁免,之後個人不再給序言的事實性描述和內文已經提及內容寫來源。除去評選的情況,考慮到整體環境,還是收緊一下比較好。--Nostalgiacn留言) 2022年8月1日 (一) 04:32 (UTC)
雖然這兩個作為長久以來的共識被執行,但實際上都不是方針。如同GA的展示日期,當時吵這麼久不就是因為根本沒有所謂的共識,數大必有枯枝,人多必有白癡,無論本提案是否通過我們都有其他手段處理這些人造成的序言膨脹和不列來源的問題。 --窝法乙烷 儿法梦碎 2022年8月2日 (二) 07:09 (UTC)
我去看了近日的GA評選,你提到「有編輯」HK5201314在旁人提及「导言不标来源是英维GA常见的写作方式」,HK5201314之後也給出讚成票,並沒有到你說的「吵這麼久」的地步。還不如把WP:GA?變成共識,所有評選標準就看齊了。--Nostalgiacn留言) 2022年8月3日 (三) 07:21 (UTC)
@Nostalgiacn:閣下請看看我打字到底打了些甚麼......,「如同GA的展示日期,當時吵這麼久不就是因為根本沒有所謂的共識」,相關討論可以看這裡。我要處理的問題很簡單,就是允許導言可以不列來源,將GA評選列為方針不僅不是我的目標,同時也無法處理我想解決的問題。先不提可能要接續提Wikipedia:新条目推荐/候选#规则Wikipedia:典範條目標準,提GA評選意味要處理其他不受現有正式方針認可的標準,想想Wikipedia:条目长度討論3遍會耗費多少時間。 --窝法乙烷 儿法梦碎 2022年8月3日 (三) 15:10 (UTC)
那麼避免換燈泡的破事,加速通過應該沒什麼爭議的WP:LEADCITE吧。--Nostalgiacn留言) 2022年8月3日 (三) 16:41 (UTC)
個人認為列明來源設為指引會比較合適。--飛馬🎠🎈 2022年7月30日 (六) 04:23 (UTC)
WP:列明來源已經是中文維基百科的內容指引--Rastinition留言) 2022年8月4日 (四) 22:49 (UTC)
我還真是未看過摘要要加來源這種操作……btw 以常見的電影/電子遊戲條目為例,導言通常會包含極簡短的評價,但到了內文它就是好幾段文字加上十多個來源,如果要硬性規定補上來源,就有機會演變成一句句子附有十多個來源佐證,這極為影響美觀。另外上方Nostalgiacn君指的序言膨脹問題,其實這種情況有沒有來源都是一樣,就算規定了序言要加來源,亦不見得將來會減少。--銀の死神走馬燈劇場祝你在亂流下平安 2022年7月30日 (六) 15:41 (UTC)
行。—— Eric Liu 創造は生命(留言留名學生會 2022年7月31日 (日) 07:40 (UTC)
(+)支持,提议条文简而言之,就是导言避免列出多余来源,BLP有争议的必须列来源,其它有争议的看共识或常识。--BlackShadowG Slava Ukraini! 2022年7月31日 (日) 15:37 (UTC)
也可以说明下哪些争议适合列入导言,哪些不适合列入导言?--Kethyga留言) 2022年8月4日 (四) 13:21 (UTC)
同閃亮飛月,應設為指引而非方針。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年8月4日 (四) 03:28 (UTC)
我支持导言列来源,所有正文理应言之有据。“避免列出多余来源”在实践上含糊。赞成列为指引。(+)强烈建议将“列明来源”拆分为两个子章节,“导言必须符合可供查证、生者传记和其他方针”这段列为指引乃至方针,而第二段再进行一些考量和讨论。--YFdyh000留言) 2022年8月4日 (四) 06:43 (UTC)
蛤?恕敝人資質駑鈍,閣下大打算要叫两个子章节什麼? --窝法乙烷 儿法梦碎 2022年8月4日 (四) 08:33 (UTC)
设立子章节以利于标识。大概是这样。--YFdyh000留言) 2022年8月4日 (四) 09:13 (UTC)
不是啊,再有Wikipedia:可供查證Wikipedia:列明来源的基礎下,討論「原則」的意義何在? --窝法乙烷 儿法梦碎 2022年8月4日 (四) 09:46 (UTC)
因为此题是“提议将Wikipedia:格式手册/序言章节#列明来源设为方针”,且此处总不能直接写“参考可供查证和列明来源”。--YFdyh000留言) 2022年8月4日 (四) 10:02 (UTC)
還真的有,請參考Wikipedia:可供查證#可靠来源Wikipedia:可靠来源。該「原則」內容就是可供查證和列明来源,沒必要花7天公示已經是方針的內容。關於錯字,我加了刪除號。 --窝法乙烷 儿法梦碎 2022年8月4日 (四) 10:34 (UTC)
简述还是有用的,方针页面较长、特定方面不够具体。而指引/方针的内容是否要讨论公示,目前不就是出现了争议。我对段落一无异议,但段落二我认为易导致误解,或者本身就有模糊地带,我不希望别人据此发表非社群共识。--YFdyh000留言) 2022年8月4日 (四) 10:42 (UTC)
@YFdyh000:简述的確有用,但沒有简述也不影響導言需要羅列來源的事實,何苦浪費時間在段落一上?單刀直入段落二不好嗎。 --窝法乙烷 儿法梦碎 2022年8月4日 (四) 12:37 (UTC)
“单刀直入段落二”就是如上所述,我不赞成它列为指引。那么段落一呢,您认为应该“去掉”?--YFdyh000留言) 2022年8月4日 (四) 22:37 (UTC)
我只是說沒必要討論已經是方針的內容,不等於段落一要去掉,你要去掉也是可以啦...。 --窝法乙烷 儿法梦碎 2022年8月5日 (五) 01:51 (UTC)
現行條文

列明來源 由於序言章節通常會與條目主體文字的資料重複,故編者應該在避免列出多餘來源、與指導讀者至受質疑內容的來源間,取得平衡。導言通常被寫成是比條目主體層次較淺的概述,而在序言章節中無爭議的東西看似是較少會被質疑的,繼而看似是較少機會被要求列明來源;不過這不是說序言可以例外地繞過引用要求。序言是否有必要列明來源應個別地、以編者共識來處理。複雜的、正在發生的、或有爭議的事項可能需要列明來源;其他的則列出少量甚或不用列出。這裡不要求也不禁止條目的序言作出引用,而需視不同狀況而定。

提議條文

列明來源 導言通常是比條目內容更為顯淺的概述,同樣需要符合可供查證等方針。序言章節一般會截取或複述條目內已經有列明來源的文段,相關文段可考慮不重複列出來源,只是在涉及複雜的、正在發生的、或有爭議的內容時可能仍需列出來源。必要時編者可以在條目討論頁面、同行評審、互助客棧或其他討論頁面(包含評選)達成共識決定序言章節是否列明來源。簡而言之,這裡不要求也不禁止在條目的序言章節列出來源,而需視不同狀況而定。

我想問一下,樓上幾位有看過Wikipedia:格式手冊/序言章節#列明來源嗎?原文寫道「序言是否有必要列明來源應個別地、以編者共識來處理。」,所以不用特地寫出哪些争议适合列入导言,哪些不适合列入导言。而綜觀大半的DYK、優良、典範,避免列出多餘來源在實踐上可一點都不含糊(畢竟一堆不列的是要怎麼含糊ˊ_>ˋ)。
@Nostalgiacn閃亮飛月RastinitionSilverReaperEricliu1912KethygaCdip150YFdyh000:我直接粗暴的將導言羅列來源的討論挪到評選,反正不滿意的可以投反對並表示編輯應該加來源,這方法不知道各位覺得怎麼樣。 --窝法乙烷 儿法梦碎 2022年8月5日 (五) 03:07 (UTC)
建議原文也修改一下,讀起來不通順,如「與指導讀者至受質疑內容的來源」之類的用語也不太理解。
參考上面的說法,修改建議:
「導言通常是比條目內容更為顯淺的概述,同樣需要符合可供查證等方針。序言章節一般會截取條目內已經有列明來源的文段,截取的文段可考慮不重複列出來源,只是在涉及複雜的、正在發生的、或有爭議的內容時可能仍需列出來源。必要時編者可以在討論中達成共識決定序言章節是否列明來源。簡而言之,這裡不要求也不禁止在條目的序言章節列出來源,而需視不同狀況而定。」--Nostalgiacn留言) 2022年8月5日 (五) 16:38 (UTC)
不應該以評選頁面為討論地點,多數條目從不上評選,寫同行評審都好得多。不過,我是建議改為「在討論頁或同行評審等處取得編者共識」。—— Eric Liu 創造は生命(留言留名學生會 2022年8月6日 (六) 03:53 (UTC)
畢竟目前有編輯對導言有疑慮,而討論頁或同行評審的人氣可想而知,到最後也是到條目討論公審,而反對方都能在評選頁面發表意見,沒道理需要限流。 --窝法乙烷 儿法梦碎 2022年8月6日 (六) 14:05 (UTC)
那跟寫進政策頁面明示是兩回事。我不贊成「評選至上主義」。優先順序應該是條目討論頁面、同行評審、互助客棧、其他討論頁面(包含評選)。—— Eric Liu 創造は生命(留言留名學生會 2022年8月6日 (六) 15:31 (UTC)
@Ericliu1912Nostalgiacn:寫成這樣如何? --窝法乙烷 儿法梦碎 2022年8月7日 (日) 01:35 (UTC)
反對「截取」之類的字眼,不認為0段需要跟正文內的句子逐字相同。-hiJK910 走先喇 係咁先喇 下次再玩吖 2022年8月7日 (日) 02:09 (UTC)
可以描述修改一下:「序言章節一般會截取或複述條目內已經有列明來源的文段,相關文段可考慮不重複列出來源。」
結合上下文的表態,是否除了行文用字外,是支持其方向的。--Nostalgiacn留言) 2022年8月7日 (日) 05:36 (UTC)
這樣呢。 --窝法乙烷 儿法梦碎 2022年8月7日 (日) 07:14 (UTC)
@Hijk910:看看修改如何。--Nostalgiacn留言) 2022年8月8日 (一) 05:19 (UTC)
(▲)同上,上各种评选的相对来说质量还好,大多数受到质疑的一般不会选择评选。--Kethyga留言) 2022年8月7日 (日) 05:52 (UTC)
我突然想到,既然這條不是方針指引,那麼是不是現有的DYK、GA、FA都不符合資格? --窝法乙烷 儿法梦碎 2022年8月6日 (六) 14:10 (UTC)
如果不是真的想撤銷所有DYK、GA、FA資格的話,建議不要提出這種沒有建設性的問題,讓大家作無謂討論,浪費大家的時間。時間是很寶貴的。-hiJK910 走先喇 係咁先喇 下次再玩吖 2022年8月6日 (六) 14:18 (UTC)
就是不想撤銷所有資格才提案,但問題是現階段無法取得共識,也沒人想出兩全其美的辦法,還是我先提撤銷這樣大家才有感覺? --窝法乙烷 儿法梦碎 2022年8月7日 (日) 01:26 (UTC)
= =未取得共識和沒有取得共識的分別可大了,討論顯然正在推進。因為我相信這項「正式化導言不必註腳」的提案終會通過,所以假如你實行你口中的核彈選項,最終只會讓整個中文維基百科都成為你的敵人,讓你被視為舞着炸彈的瘋子。-hiJK910 走先喇 係咁先喇 下次再玩吖 2022年8月7日 (日) 02:05 (UTC)
還有啦,我一直認為,WP:CITELEAD並不是讓導言可以豁免WP:VER(寫入維基百科的內容須要能被讀者在可靠來源中得到驗證)和WP:CITE(內容添加者有義務列明來源),而是明文澄清導言不需要註腳也能彰顯這兩項規定。我並不認為你的核彈選項能夠炸開來用。-hiJK910 走先喇 係咁先喇 下次再玩吖 2022年8月7日 (日) 02:40 (UTC)
還犯不著拆屋以開窗的地步,這算是習慣法變成文法,耐心地還是能通過的。--Nostalgiacn留言) 2022年8月7日 (日) 05:34 (UTC)
我還沒炸就有人炸過了,我只是在評估要不要向那位開炸的人道歉。的確WP:CITELEAD並不是讓導言豁免添加來源的手段,但不將其列為指引難道要繼續闖紅燈嗎?看看我們身處的奇怪迴圈「評選時反應導言該加來源→有人反應自古以來都不用加→WP:CITELEAD不是指引→繼續反應導言該加來源」,既然評選突破不了那就突破方針看看,好歹存檔後可以讓後人知道導言要加來源,也是美事一樁。 --窝法乙烷 儿法梦碎 2022年8月7日 (日) 07:14 (UTC)

提議建立中小學條目指引

學校條目應涵蓋內容,迄今沒有一個標準,而這類條目又特別容易有受到破壞,或是加入宣傳內容。因此,提議建立Wikipedia:中小學條目指引規範學校條目內容,並參考了WikiProject:學校/條目指引Draft:英文維基百科學校專題編寫建議(上述二者均譯自英文維基百科學校專題論述,分別經過主要編者修改,基本綜合了內容指引與格式指引的性質)與歷來討論,試擬草稿,懇請賜予意見。

不將高等/大專院校納入的原因,是因為中、英文維基百科的學校專題與大學學院專題都是分開的,可見兩者性質略有不同,此處先行就較常被破壞,及條目內容詳盡程度較常有爭議的中小學部分擬定指引。

中小學條目指引是一篇內容指引,旨在規範中學小學相關條目。

資訊框 對於中小學條目適用的資訊框,社群已經在2020年間完成整合,請統一使用{{Infobox school}}。

建議避免填寫項目

  • 聯絡方式:例如電話號碼、傳真號碼、電子信箱。(維基百科不是電話簿
  • 副職領導人與臨時職位:例如副校長、副主席、代理校長。
  • 尊稱:前綴英语Pre-nominal letters後綴字(CEO、Dr、BA、BSc、MA、PhD等)及性別用語(先生、女士)。例如:不要使用「黨委書記:王大華先生」,只需要寫出「黨委書記:王大華」就好了。

導言 條目定義句應提到該校的官方全銜、常見名稱及歷史上使用過的其他名稱,並描述其類型與位置。如:

維基百科中學,簡稱維百中學,曾稱吉米·威爾士中學,是一所位在美國加州舊金山市私立高級中學
原始碼小學,簡稱源小,是日本的一間公立小學,位在茨城縣潮來市

如果該校校名的原文並非漢語,請加註原文,但如中國大陸和臺灣的絕大多數學校,其原文校名就是漢語者,則不應在第一句提到它的英文校名。

校歌歌詞 校歌歌詞應僅在確認其進入公有領域,或其他可以上傳到維基的前提下,上傳到維基文庫,並於適當處(如學校象徵章節,或末尾外部連結章節)給出連結,因為維基百科不應包含原始資料的副本

如果校歌歌詞非自由版權釋出,允許列出其部分具有特殊意義的詞句(以有文獻專門探討該句歌詞為判定標準),但應說明其意義為何。

人物

家長會等相關組織領導者 歷任家長會長、校友會長、教師會長、學生會長等資訊,均不應列出。

教職員、學生與校友 教職員、學生與校友,都應該只在人物本身就具備關注度,獨立第三方來源提及這位人士與學校的關係時,才被列入學校條目中。如果滿足獨立列表的要求,可以另以列表收錄(可參閱方針《列表的概述》、指引《以地方劃分的人物列表的收錄標準》,並參考《維基百科:格式手冊/列表之內容》以及《維基百科:獨立列表之選擇標準》建立相關列表)。

在學校條目內提及這些人物時,請以敘事散文為主,盡量避免使用表格或列點。

建築與學校設施

各項學校建築與設施,除非是古蹟等特殊建築,或者在可靠來源中具背景介紹或敘述者(不含單純提及建築/設施名稱,或僅具建物樓層數、面積、建成日期等基本資料者),否則不應單獨列出。

於條目中介紹建築與設施相關背景資料時,應使用百科全書式的語調,撰寫描述性質散文,盡量避免僅以列點形式羅列各項建物的名稱,也請避免除了名稱外,僅寫出建物樓層數、面積、建成日期等統計資料。

前述「學校建築與設施」泛指校園內之建築物及其內含或附屬之設施(包含但不限於校舍、運動場(含球場)、運動館等建物,以及校舍內的實驗室、專科教室、特別教室、建物旁的庭園等設施)。

交通資訊 請避免在學校條目中列出如何到達該校、校門口設有什麼公車站,停靠有什麼路線等資訊。(互助客棧2019年7月共識參照)

學生的考試成績 有關升學考試成績表現,均不應錄入。例如:不應該提到「某高中有多少比例的學生高考在該省平均前50%」(中國大陸),也不應該提到「某國民中學全體學生均在國中教育會考獲得B以上成績」(臺灣)。

學校特色 撰寫此類文字,務必特別謹慎,以免流於宣傳、廣告。

開設課程 諸如該國語文、數學、科學、歷史這種常見科目,不應該寫出。但是,如果該校有特別的課程(例如臺灣在108課綱中規定各校都應該要有「校訂必修課」),則可以列出。

外部連結

學校條目中,請置放學校官方網站的連結,並使用{{Official Website}}或{{Url}}等模板,以統一格式。盡量使用語言代碼模板(如{{zh-cn}})標註該網站的語言。

不要在學校條目中,加入該校社群網站專頁、影音頻道(如 Facebook, YouTube, 微博, Tiktok)帳號,除非此帳號實際上代替學校官方網站功能,且網際網路上找不到這間學校的官方網站。

參見

Category:維基百科內容指引

至於歷任校長、社團列表等先前較有爭議的部分,等待上述第一階段條文討論完畢後,再行處理。

此前的相關討論,除了已經以內部連結引用在提議條文中者,尚有:

--S099001留言) 2022年7月31日 (日) 04:48 (UTC)

我認為應當直接寫入學校條目指引,不必再特地另立頁面。—— Eric Liu 創造は生命(留言留名學生會 2022年7月31日 (日) 07:38 (UTC)
如果能有共識而能建立指引會較好,當然若在此處迴響不大,過七天存檔後,便會直接將之納入學校專題的論述中了。--S099001留言) 2022年7月31日 (日) 07:47 (UTC)
不赞同列为指引。为什么学生在毕业后具备关注度就不能列入呢?列入校友栏目都不可以吗?不是很明白。似乎与现行论述内容不一致。
此外我觉得部分内容如果有可靠第三方来源的有效介绍的话,应该允许列入。--Yinyue200留言) 2022年7月31日 (日) 13:06 (UTC)
校舍、設施是學校條目的基本必須內容,亦會經過擴建或重建,甚至搬遷。而且設施標準和種類亦並非所有學校都有,不應刪除。--Wpcpey留言) 2022年7月31日 (日) 13:18 (UTC)
@Yinyue200:「學生」原意僅指在學學生。我想就將學校相關人物統一改成類似標準,或許會好些,再請您看看:
現行條文

教職員與學生

教職員僅限本身具備關注度者,像胡適這樣有名的教師可以列入

學生除非在學時就具備關注度,如丹尼爾·雷德克里夫等,否則不應列入

提議條文

教職員、學生與校友

教職員、學生與校友,都應該只在人物本身就具備關注度獨立第三方來源提及這位人士與學校的關係時,才被列入學校條目中。

至於您提到「部分內容如果有可靠第三方來源的有效介紹」,還請您說明一下是哪些部分,可以將本指引草稿分成多節來討論,不用一次通過的。--S099001留言) 2022年7月31日 (日) 13:29 (UTC)
至少我觉得“校舍、设施 ”应当是允许列入的。--Yinyue200留言) 2022年7月31日 (日) 13:32 (UTC)
@WpcpeyYinyue200:謝謝提醒,上述提案的確可再商榷。不過現在中小學條目,偶爾仍會見到將校內所有建築物、設施列出清單。在中小學常見的籃球場、操場、物理實驗室、化學實驗室等,以及整棟大樓都是普通教室的建築,並沒有什麼特別之處,基於維基百科不是目錄,個人覺得可以不用錄入。
同樣地,參照WP:NOT方針提到避免「詳盡的軟體更新記錄」,個人也認為不需要詳述一棟大樓擴建、重建、搬遷的歷史。當然,像是建國中學紅樓這種具備獨立關注度的建築,是可以被列入的。提案稍後改為:
現行條文

校舍、設施

校舍除非是古蹟等特殊建築,否則不應列出。

運動場館、實驗室這類設施十分普遍,不應列出。

提議條文

建築與學校設施

建築與各項學校設施,除非是古蹟等特殊建築,或者在可靠來源中,有介紹該設施的敘述(單純提及建築/設施名稱,或除了建築/設施名稱外,只有建物樓層數、面積、建成日期等統計資料者,都不算),否則不應列出。

前述「建築」包含了校舍、運動場(含球場)、運動館等建物,「學校設施」指其附屬設施,例如校舍內的實驗室、專科教室、特別教室,還有建物旁的庭園。

在學校主條目中提到建築與各項學校設施,應當附上介紹,不要只羅列出各項建物的名稱,也不要除了名稱外,僅寫出建物樓層數、面積、建成日期等統計資料。

--S099001留言) 2022年7月31日 (日) 13:54 (UTC)
個人認為設施的敘述還是不需要定立這麼嚴格的要求,這些統計資料也是對讀者有參考的價值。--Wpcpey留言) 2022年7月31日 (日) 14:31 (UTC)
13:54 (UTC) 更改條文的第三段,並不是說統計資料不值得寫出來,而是除了這些基本資料以外,可以增加更多的敘述。主要配合前面第一段「...否則不應列出」已經要求,如果編者列出這些設施,應該也可以找到單純統計資料以外、更多的介紹。--S099001留言) 2022年7月31日 (日) 14:48 (UTC)
參考Shizhao的意見,我個人不建議設施使用列表介紹,如果值得被紀錄,一定有可以用描述性語句介紹的內容。相關被介紹的內容一定有來自獨立第三方來源(非第一手來源)的網頁或紙本資料WP:可供查證。--Rastinition留言) 2022年8月2日 (二) 14:06 (UTC)
@Rastinition:修正如:
現行條文

建築與各項學校設施,除非是古蹟等特殊建築,或者在可靠來源中,有介紹……,否則不應列出。

提議條文

建築與各項學校設施,除非是古蹟等特殊建築,或者在可靠獨立的第三方來源中,有介紹……,否則不應列出。

至於描述性語句,大致上如下方 2022年8月1日 (一) 07:22 (UTC) 修改版本,已經增列於草稿中,還請您檢視。--S099001留言) 2022年8月3日 (三) 07:28 (UTC)
人员和设施应该强调用描述性的百科语句进行介绍,尽量不要用表格或点列的形式展现--百無一用是書生 () 2022年8月1日 (一) 03:17 (UTC)
已修改為:
現行條文

教職員、學生與校友 教職員、學生與校友,都應該只在人物本身就具備關注度,獨立第三方來源提及這位人士與學校的關係時,才被列入學校條目中。

提議條文

教職員、學生與校友 教職員、學生與校友,都應該只在人物本身就具備關注度,獨立第三方來源提及這位人士與學校的關係時,才被列入學校條目中。

提及這些人物時,請以敘事散文為主,盡量避免使用表格或列點。

現行條文

在學校條目中提到建築與各項學校設施,應當附上介紹不要只羅列出各項建物的名稱,也不要除了名稱外,僅寫出建物樓層數、面積、建成日期等統計資料。

提議條文

在學校條目中提到建築與各項學校設施,應當附上介紹,並使用百科全書式的語調,撰寫描述性質散文。盡量避免使用列點形式,只羅列出各項建物的名稱,也請避免除了名稱外,僅寫出建物樓層數、面積、建成日期等統計資料。

--S099001留言) 2022年8月1日 (一) 07:22 (UTC)
(+)支持(!)意見:個人綜合考量條目所具備之基本資訊和易讀性、來源可靠性、避免不斷增生之過度細瑣訊息,以及適當促進編者參與,支持相關修訂,同時希望部分更動:
「各項學校建築與設施,除非是古蹟等特殊建築,或者在可靠來源中具背景介紹或敘述者(不含單純提及建築/設施名稱,或僅具建物樓層數、面積、建成日期等基本資料者),否則不應單獨列出。
於條目中介紹建築與設施相關背景資料時,應使用百科全書式的語調,撰寫描述性質散文,盡量避免僅以列點形式羅列各項建物的名稱。
前述「學校建築與設施」泛指校園內之建築物及其內含或附屬之設施(包含但不限於校舍、運動場(含球場)、運動館等建物,以及校舍內的實驗室、專科教室、特別教室、建物旁的庭園等設施)。」--Kriz Ju留言) 2022年8月5日 (五) 23:40 (UTC)

謝謝您的建議,「建築與學校設施」已經修改了,但是因為第一段還是提到了「僅具建物樓層數、面積、建成日期等基本資料者」不應列入條目中,因此還是將第二段「,也請避免除了名稱外,僅寫出建物樓層數、面積、建成日期等統計資料。」一句留住。至於「教職員、學生與校友」部分,獨立列表似乎比條目類列出有更嚴格要求,因此表述為「如果滿足獨立列表的要求,可以另以列表收錄。」具體差異見Special:Diff/73105184--S099001留言) 2022年8月7日 (日) 11:21 (UTC)

優良條目審查應否參考過往成功審查的紀錄?

提议增设“线上活动特别贡献”

提议规定巡查时将页面移动至草稿的规则

英文维基百科规定在一定情况下(比如条目质量严重不合标准但有可能有关注度)可以将条目“Draftify”(草稿化),在中维的存废讨论也确有一部分是这样处理的(例如Wikipedia:頁面存廢討論/記錄/2021/12/30#立普思),但还有一部分回退员/巡查员因把符合速删标准的条目移至草稿而引发争议(见WP:申请解除权限),所以敝人提议拟定将条目移至草稿的条件,英维的规则在en:WP:Draft,供大家参考。--QiuLiming1留言) 2022年8月2日 (二) 19:35 (UTC)

  說明:此前討論見Wikipedia_talk:草稿命名空间/存檔一#建議大修《草稿頁指引》,以將「草稿化」納入常規維護操作,當時的草案是Wikipedia:草稿命名空间/2019年更新草案#草稿化。相比之下en:WP:DRAFTIFY有更多細項規則,值得參考。(在下(+)支持訂立「草稿化」指引,當然還要視乎實際條文。又:除權似乎是因將WP:G3條目草稿化,但en:WP:DRAFTIFY要「has some potential merit」,此前中文草案也要「具有發展成完整條目的潛力」,無價值的WP:G3條目仍應速刪,因此指引與該次除權關係不大。)—— 留言) 2022年8月3日 (三) 12:02 (UTC)
或者和友善程度、具体执行有关?草稿的原本想法更像是让编辑自己提供可以公开编辑的草稿性质页面。条目一旦发布,就应该按照现有的规范去执行检查,如果巡查人员友善的话,可以标识完还专门说明一下哪里不符合规范,如果想做老好人的话,是可以考虑移到草稿,但如果将这个规则化下来,我认为不必要,因为上的条目空间就要考虑这个问题,也不是所有巡查都要做老好人。——Sakamotosan路过围观 | 避免做作,免敬 2022年8月4日 (四) 00:40 (UTC)
赞成翻译en:WP:DRAFTIFY之流程,但其页面也仅为流程而非方针或指引,在本地运用应仔细讨论和考量。赞成规范化,但目前运用应基于共识、“无争议”原则,出现争议时应协商共识或转入其他流程。--YFdyh000留言) 2022年8月4日 (四) 01:36 (UTC)

修订编辑战方针(二)

问题背景

参见上方的修订讨论,本站现行编辑战方针在“豁免原则”的表述上存在歧义,需要修正。然而本人在为该案草拟更好的修订稿时发现,现行编辑战方针曾于2018年通过J. Wong君发起的讨论合并了原回退不过三原则中的内容。该案审议时未拟修订稿,实际执行时也仅将两方针复制至一处,而未有效整合,导致现行方针内文内容大量冗余、还存在一定的矛盾。

以“豁免原则”的表述为例,现行方针中就有两处,一则来自旧编辑战方针:

...
回退破坏不是编辑战。注意,重复张贴明显非真实的内容(例如“恶搞”语录)或重复移除大量内容常被视作破坏行径,但是正常情况下的少量不中立观点,正常的加入或删除内容,或其他善意的修改,都不应当视为破坏。(参见破坏的类型和不视作破坏的行为)。
为了维护更重要的方针而采取的回退举动不应视作编辑战。例如,依照生者传记相关方针,为了避免对当事人造成损害,有关生者的无来源负面内容如不修改,必须移除。
...

一则来自旧“回退不过三”方针:


...下述行为在适用回退不过三原则时,不视為一次回退:

回退自己的编辑(“自我回退”)。
回退在自己用户空间中的编辑,前提是你必须遵守用户页指引。
回退明显的破坏行为,即指任何一个假定他人的编辑是出于善意的用户都会认为是破坏的编辑,例如清空页面或是添加攻击性语言。
移除明显侵犯著作权,或是毫无疑义违反合理使用方针的内容。
移除明显违反维基百科服务器所在地——美国佛罗里达州法律的内容,例如儿童色情内容或盗版软件。
移除涉嫌诽谤、非中立、无来源或来源不充足,违反生者传记方针的争议材料。對於刪除何種內容可享有生者傳記方針豁免而不受回退不過三限制可能會存有爭議。遇有不清晰或有爭議,則建議先行提報至互助客棧,而非依賴前述豁免。
为了确保在首页展示的特色列表和优良条目的质量而进行的回退操作,给予用户一定的自由空间。
...

这不利于方针的阅读和执行。此外,部分不受合并影响内容也存在字句不通顺、不确切、行文逻辑不清晰等问题。现行方针第一句话“维基百科的页面都是透過社群讨论形成的”就不合乎事实。有鉴于此,本人提出了编辑战方针的修订草稿Wikipedia:編輯戰/draft,其与现行方针的差异如该链接所示。具体如下:

引言

現行條文

维基百科的页面都是透過社群讨论形成的,用户需要遵循编辑守则,协力构筑共识,如果不起效果的话,应当设法解决争论并寻求帮助。如果两位或团体多位作者就一个问题无法达成协议,因此不断地互相删改或撤銷对方的编辑內容时,就被称为“编辑战”。如果要提报参与编辑战的用户,请前往管理員通告板

对编辑战有一个明确原则,即“回退不过三”(3RR)原则。该原则是指编者在24小时之内,不得对同一页面进行超过三次的回退动作。回退是指撤销另一编者的编辑动作,无论每次涉及内容是否一致,违反者可能会被封禁。当然,未违反“回退不过三”原则的编辑战也可能招致封禁。

編輯戰對於讀者跟編輯者都是有害的行為,试图强行维持条目的某一版本,可能会造成中立性的缺失,也可能会导致用户互相敌视,阻碍共识的形成。在警告和封禁之后仍然执意进行编辑战的用户将可能永久失去对某些页面的编辑权

提議條文

编辑战是指两位以上编者就一个问题无法达成共识,因而不断地互相删改或撤銷对方的编辑內容的行为。編輯戰對於讀者跟編輯者都有害,试图强行维持条目的某一版本,可能会造成中立性的缺失,也可能会导致编者互相敌视,阻碍共识的形成。

参与编辑战的编者可能暂时或永久剥夺部分全部页面的编辑权。处置编辑战时有一条界限供参考,即“回退不过三”(3RR)原则。该原则指出,编者在24小时之内,不得对同一页面进行超过三次的回退动作。该原则不应理解为回退频次上的合法配额;未违反“回退不过三”原则的编辑战参与者并不必然豁免管理措施。

管理员处置编辑战的基本原则是避免、制止争议行为,鼓励理性编辑,而非惩罚参与者。其它编者可通过管理員通告板提报编辑战的参与者。

  • 如同条目引言一样,方针的引言应当具有概括性。现行方针在该部分过多地交待了非必要的背景信息,却未能概括“管理员指引”中的内容。修订后本人删除了相应的背景信息,直接开宗明义地定义了“什么是编辑战”,并补充了“管理员指引”章节的内容。此外,“可能会被封禁”、“可能招致封禁”措辞调整为“暂时或永久剥夺部分全部页面的编辑权”,指明封禁和禁制均为可选项。

--Antigng留言) 2022年8月5日 (五) 13:57 (UTC)

什么是编辑战

現行條文

作为维基百科的一个核心理念,开放的系统可以产生高质量、中立的百科内容。但是不可避免的是,用户针对页面内容的某些方面会有不同的观点。当此类情况发生时,强烈建议编者透過文明的讨论达成共识,而不是在明知会招致反对时仍然固执己见,采取挑衅性的编辑行为,并且反复使用回退功能。后者称为编辑战

并非所有潜在的争议编辑行为,或是回退举动,都会被指为编辑战。应当注意以下的情形:

  • 维基百科鼓励编者勇于更新页面。一个潜在争议更改可能只是为了检测是否有反对声音,并开启讨论的手段。如果另一用户有充足的理由反对此项更改,他们可以采取回退行动。这就是所谓的更新,回退,讨论(BRD)循环,而非编辑战。只有在出现一系列非建设性,反复的编辑行为时,才構成编辑战。
  • 回退破坏不是编辑战。注意,重复张贴明显非真实的内容(例如“恶搞”语录)或重复移除大量内容常被视作破坏行径,但是正常情况下的少量不中立观点,正常的加入或删除内容,或其他善意的修改,都不应当视为破坏。(参见破坏的类型不视作破坏的行为)。
  • 为了维护更重要的方针而采取的回退举动不应视作编辑战。例如,依照生者传记相关方针,为了避免对当事人造成损害,有关生者的无来源负面内容如不修改,必须移除。

如果回退了他人的修改,请确保在编辑摘要中或讨论页中指明缘由(原因显而易见除外,例如回退破坏)。未给出适当理由的回退行为很有可能被理解为是挑衅。谨记回退操作是把其他编者的工作“丢到一旁”;或许你应当考虑改善文本质量,或是与其他编者进行沟通,而不是简单的撤销更改。

请牢记,例如TwinkleHuggle回退功能之类的反破坏工具不宜用來撤销有关条目内容的善意修改。

提議條文

维基百科的一项核心理念在于通过公众可参与的平台产出高质量、中立的百科内容。由此不可避免的是,不同编者针对页面内容的某些方面会有不同的观点。当此类情况发生时,编者应透過文明的讨论达成共识,而不是反复撤销他人的编辑,尤其是在明知会招致反对时故意而为,以示挑衅。后者称为编辑战

本方针范围内如无特别说明,“回退”一词均指任何在客观上撤消或部分撤消其他编者行动的编辑行为(或管理行为),不限于使用系统或工具(如Twinkle)提供的回退功能执行的操作。

本方针并非旨在规避所有具有潜在争议的编辑行为乃至回退举动。相反,本站鼓励编者大胆更新页面。某名编者进行编辑后,如有另一编者因充足的理由而反对此项更改,他完全可以采取回退行动,并展开沟通化解问题。这就是所谓的更新,回退,讨论(BRD)循环。这种良性循环并非编辑战。只有在出现一系列非建设性,反复的回退行为时,才構成编辑战。

例外 此外,下列回退行为即使反复发生,也不应纳入编辑战的考量:

  • 回退自己账户的编辑(“自我回退”)。
  • 回退在自己用户空间中的编辑,前提是您必须遵守用户页指引。
  • 回退明显的破坏行为,即指任何一个假定他人的编辑是出于善意的编者都会认为是破坏的编辑(例如无故清空页面、重复张贴明显非真实的内容、屡次添加攻击谩骂文字等)。但是正常情况下的少量不中立观点,正常地加入或删除内容,或其他善意的修改,都不应当视为破坏。(参见破坏的类型不视作破坏的行为)。
  • 为了维护更重要的方针,特别是法律相关方针,而采取的回退举动。例如,移除明显违反本站著作权方针、儿童色情、非主动公开的个人资料等涉嫌违反维基媒体服务器所在地法律的内容。移除明显违反生者传记方针的内容的回退(例如移除关于在世人物涉嫌诽谤、非中立、无来源或来源不充足的争议内容)也适用本条。但對於刪除何種內容可享有生者傳記方針豁免本身可能會存有爭議。遇有不清晰或有爭議,建議不要依賴此豁免。
  • 为了确保在首页展示的典范条目优良条目的质量而进行的回退操作,给予编者一定的自由空间。
  • 本章节合并了现行方针3RR部分的豁免原则,并将其另立为子章节“例外”加以阐述。在合并时,例外原则的措辞有一定调整:
    1. “回退自己的编辑”修改为“回退自己账户的编辑”:显然回退自己的合法分身帐户(例如机器人帐户)的编辑不应纳入编辑战的考量,故有此修改。
    2. “维护更重要的方针”“而采取的回退行动”补充说明“特别是法律相关方针”:列举的“受豁免”方针实质上均是本站的法律方针,故有此澄清。
    3. “移除涉嫌诽谤、非中立、无来源或来源不充足,违反生者传记方针的争议材料”调整措辞并入上一条:解决前一案的问题
  • 同时,本章节也合并了现行方针中,所有涉及“回退的定义”的内容,将其另立章节加以交待:“本方针范围内如无特别说明,‘回退’一词均指任何在客观上撤消或部分撤消其他编者行动的编辑行为(或管理行为),不限于使用系统或工具(如Twinkle)提供的回退功能执行的操作。”
  • 此外还有一些措辞方面的细微调整。

--Antigng留言) 2022年8月5日 (五) 13:57 (UTC)

编辑战的处理

現行條文

参与编辑战的用户很可能(通常在编辑战发生后)被封禁,以防止进一步的争端。尽管所有的编辑战行为都有可能导致此种处理,但有一条常用作封禁的明确界线——称作“回退不过三”(3RR)的原则。具体内容如下:

“回退不过三”原则

根据“回退不过三”原则:

一个“页面”意指维基百科上的所有页面,包括讨论页和计划空间。

这里提到的一次“回退”是指任何取消其他用户行动的编辑行为(或管理行为),无论是全页面还是部分内容。可能有的时候只是一个词的变动。在没有其他用户编辑的情况下,一个用户连续的一系列回退编辑视作一次回退。下述行为在适用回退不过三原则时,不视為一次回退:

  • 回退自己的编辑(“自我回退”)。
  • 回退在自己用户空间中的编辑,前提是你必须遵守用户页指引。
  • 回退明显的破坏行为,即指任何一个假定他人的编辑是出于善意的用户都会认为是破坏的编辑,例如清空页面或是添加攻击性语言。
  • 移除明显侵犯著作权,或是毫无疑义违反合理使用方针的内容。
  • 移除明显违反维基百科服务器所在地——美国佛罗里达州法律的内容,例如儿童色情内容或盗版软件。
  • 移除涉嫌诽谤、非中立、无来源或来源不充足,违反生者传记方针的争议材料。對於刪除何種內容可享有生者傳記方針豁免而不受回退不過三限制可能會存有爭議。遇有不清晰或有爭議,則建議先行提報至互助客棧,而非依賴前述豁免。
  • 为了确保在首页展示的典范条目优良条目的质量而进行的回退操作,给予用户一定的自由空间。

如果你认为自己的行为属于上述例外,请确保留下明确的编辑摘要或在讨论页的单独分段中阐明例外的原因。如果没有把握,请不要回退。可以代之以尝试解决争论,或者还可以针对特定的问题,前往相应的通告板求助,例如当前的編輯爭議提报页面

如果出现四次或更多次的回退,无论每次针对的是否是同一段内容,都构成违反“回退不过三”原则。该原则按人计算,不按编辑次数计算;由多重帐号所做的回退按同一人计算。

初犯该方针的用户通常会被封禁24个小时。

切记管理员可能在任何时间,对他们认为构成进行编辑战的用户采取行动。即使在未违反回退不过三原则时,任何用户也都可以提报编辑战。该原则并不是给回退页面一个特定数量的配额

如果编者无心违反了“回退不过三”的原则,他们应当撤销自己最近的回退行为。例如,某个用户并不是经常性引起争端的编者,并且真诚的希望纠正自己的过失,管理员就可以将此考虑在内,并决定此种情况不再予以封禁。

其他回退规则

针对特定编者和/或特定页面,有时社群(参见Wikipedia:编辑禁制方针)会对其采取额外的回退限制。可能会用诸如1RR(回退不过一)或者0RR(回退零容忍)等术语指代这样的规则。“回退不过一”类似于上面所说的回退不过三,但是“多于一次回退”取代了原来规则中的“多于三次回退”。“回退零容忍”是指完全禁止进行回退操作(这其实是回退不过三原则的初衷)。

有时,编者会志愿执行更为严格的回退准则,或者是为了应对某一领域的问题,或者是作为自己的一种编辑哲学。详情参见Wikipedia:仅在必要时进行回退

提議條文

参与编辑战的编者很可能因编辑战而被剥夺编辑权限,以防止进一步的争端。尽管所有的编辑战行为都有可能导致此种处理,但有一条常用作判断的明确界线——称作“回退不过三”(3RR)的原则。具体内容如下:

“回退不过三”原则

  • 本原则所述“页面”包括本站所有页面,包括讨论页和计划空间。
  • 本原则所述“回退”不计入属例外情形的回退
  • 在没有他人编辑的情况下,特定编者对特定页面连续的一系列编辑视作一次编辑;如其总体效果涉及回退,则计为一次回退。
  • 如果出现四次或更多次的回退,无论每次针对的是否是同一段内容,都构成违反“回退不过三”原则。该原则按人计算,不按编辑次数计算;由多重帐号所做的回退按同一人计算。

初犯该方针的编者通常会被封禁24个小时。

切记该原则并未给回退行为赋予特定频次的配额。未违反回退不过三原则的编辑战仍然是编辑战;如有必要,管理员仍可能在任何时间对其参与者采取适当的行动,任何编者也可以将其提报至管理员布告板 其他回退规则

针对特定编者和/或特定页面,有时社群(参见Wikipedia:编辑禁制方针)会采取更为严格的回退限制。例如1RR(回退不过一)或者0RR(回退零容忍)。“回退不过一”类似于上面所说的回退不过三,但是“多于一次回退”取代了原来规则中的“多于三次回退”。“回退零容忍”是指完全禁止进行回退操作(这其实是回退不过三原则的初衷)。

即使未有明确规定或社群共识,编者也可能主动执行更为严格的回退准则——或者是为了应对某一领域的问题,或者是作为自己编辑哲学的一部分。详情参见Wikipedia:仅在必要时进行回退

  • 本节修订后删去了与上一节冗余的“豁免”、应归属于下面的“管理员指引”等内容,并调整了相应的字句。一处比较明显的修订是,“在没有其他用户编辑的情况下,一个用户连续的一系列回退编辑视作一次回退”更改为“在没有他人编辑的情况下,特定编者对特定页面连续的一系列编辑视作一次编辑;如其总体效果涉及回退,则计为一次回退。”很显然现行版本的条文存在这样的漏洞:一名用户先回退了另一名用户的编辑,然后又撤销了自己的回退,按现行方针这“连续一系列回退”仍然会被计作一次回退。但这并不合理。

--Antigng留言) 2022年8月5日 (五) 13:57 (UTC)

应对编辑战行为

現行條文

发现编辑战你应当采取的行动

 
如果发生编辑战,参与者应当尝试在讨论页上讨论争论议题,并努力化解分歧

与其打编辑战,不如把重心放在争论议题上,寻求帮助。当分歧变得明显时,参加编辑战的一方或双方应当停战,并尝试通过对话页讨论该议题,或者通过适当途径寻求帮助。

如果出现即使努力尝试化解矛盾,参与的一名或多名用户仍然不肯罢休,拒绝协作,无视提供给他们的信息,或是不愿采取适当的解决争论的方法,则应通过向当前的破坏提报,请求管理员介入。此时并不一定需要进行警告,但如果用户表现出对“不允许编辑战”此一方针的不了解,可以通过在其对话页中挂上{{subst:uw-3rr}}信息模板来提示他们。如果你本人牵涉进编辑战中,请避免使用通用警告模板,以防止被视作是在挑衅。可以考虑自行撰写一条适当的留言,并明确地表示希望化解矛盾。

有经验的编者如何避免涉入编辑战

一般而言,交流是避免争端的良方:请务必遵守编辑守则。当发现存在争论时,避免仅通过编辑摘要交流,而应当前往条目的讨论页进行协商。讨论的争论的主要途径应是该条目的讨论页,这样当管理员检讨此事时,可以在其中发现试图解决争论的证据。

有必要提醒您,在维基百科没有最后期限英语Wikipedia:There is no deadline,用户可以添加适当的清理标记来指出根据现有讨论存在问题的段落。如果讨论没有结果,可以在更广的范围内(如:互助客棧)征求意见,以达成和解。得知争论的中立编者会协助限制不良编辑,并协助建立共识。如果这些方法都以失败告终,请寻求非正式或正式方法解决争论

许多有经验的编者会刻意只对上述的例外排除编辑进行回退,或者只进行一次回退;如果有更多的争论,他们会寻求对话或外部帮助,而非让局面恶化。如果希望只在上述例外排除情形才进行回退,参见仅在必要时回退。该策略针对一些争议性话题特别恰当,因为当观点两极分化,情绪激动时,编辑战也会更加频繁地发生。

记住底线:使用常识进行判断,不要参与编辑战。与其反复回退,不如同他人讨论;如果回退是必要的,另一名用户或许也有同样的想法并付诸行动(你并没怂恿他),这样针对此行为就产生了共识。另外,请求保护页面比起通过回退参与争论要明智的多。

提議條文
 
如果发生编辑战,参与者应当尝试在讨论页上讨论争论议题,并努力化解分歧

如何避免涉入编辑战

请务必遵守编辑守则,谨慎回退:谨记回退操作是把其他编者的工作“丢到一旁”。在“回退”之外,您还有“改善”、“与其他编者先行沟通”等其他选项。许多有经验的编者会刻意只对上述的例外排除编辑进行回退,或者至多进行一次回退;如果争议持续,他们会寻求对话或外部帮助,而非让局面恶化,参见仅在必要时回退。该策略针对一些可预期会引起编辑争议的话题(例如:该话题在现实世界中观点严重两极分化且双方阵营互不相让)特别恰当。

如果您确实要回退他人的修改,也请确保在编辑摘要中或讨论页中指明合理的缘由(原因显而易见除外,例如回退破坏)。未给出适当理由的回退行为很有可能被理解为是挑衅。TwinkleHuggle系统自带的回退功能之类的反破坏工具不应用來回退善意修改。

若编辑争议已经出现,请避免通过编辑战来解决;若编辑战已经发生,您应当立即停战。一般而言,良好的沟通仍然是化解争端的关键。通过回退编辑摘要交流并非良好的沟通方式。您应当前往讨论页进行协商,这样当其它编者乃至管理员参与时,可以在其中发现试图解决争论的证据。请避免使用通用警告模板或反破坏工具提供的警告功能跟对方“沟通”,这可能被视作挑衅;您可以考虑手工在对方用户讨论页撰写一条适当的留言,并明确地表示希望化解矛盾。此外,您还可以主动撤销自己最近的回退行为。

有必要提醒您,在维基百科没有最后期限英语Wikipedia:There is no deadline,“短期内化解争议”并非必然能达成的目标。编者可以添加适当的清理标记来指出根据现有讨论存在问题的段落。如果讨论页对话没有结果,可以在更广的范围内(如:互助客棧)征求意见,以达成共识。得知争论的第三方编者会协助限制不良编辑,并协助建立共识。如果这些方法都以失败告终,请寻求非正式或正式方法解决争论

记住底线:使用常识进行判断,不要参与编辑战。与其反复回退,不如同他人讨论;如果回退是必要的,另一名编者或许也独立地产生了同样的想法并付诸行动,这样针对此行为就产生了共识。另外,请求保护页面比起通过回退参与争论要明智的多。

发现他人编辑战您可以采取的行动 不要参战。您可以把重心放在争论议题上,尝试调解矛盾,必要时寻求帮助。若努力尝试化解矛盾后,参与的一名或多名编者仍然不肯罢休,拒绝协作,无视提供给他们的信息,或是不愿采取适当的解决争论的方法,您可通过向管理员通告板提报,请求管理员介入。此时并不一定需要进行警告,但如果编者表现出对“不允许编辑战”此一方针的不了解,可以通过在其对话页中挂上{{subst:uw-3rr}}信息模板来提示他们。

  • 现行方针中“发现编辑战你应当采取的行动”子章节既叙述了编辑战参与者的行为,也叙述了第三方编者的行为,“有经验的编者如何避免涉入编辑战”子章节主要阐述编辑争议和编辑战参与者的行为,行文较为混乱。本次修订将其整理为“如何避免涉入编辑战”和“发现他人编辑战您可以采取的行动”,分别为“参与者”和“第三方用户”提供指引。
  • 修改后“第三方用户”的指引中,除了“不要参战”唯一一条严厉措辞,其它现行方针中针对第三方用户的严厉措辞,如“你应采取的行动”,均软化为“可以”、“可”——毕竟没有理由“要求”留意到编辑战的用户参与调解或进行举报。
  • 而涉及“参与者”的指引,则按照争议的发展态势整理并阐述:“谨慎回退,考虑回退之外的选项”、“如果需要回退,除非理由显而易见否则请指明回退理由,勿用反破坏工具回退善意编辑”、“如确实出现编辑争议/编辑战,请避免/立即停止编辑战,考虑沟通化解争议,请手动留言、勿向对方挂警告当沟通,考虑主动撤销回退”、“如讨论未见共识,考虑解决争论的其它途径”。

--Antigng留言) 2022年8月5日 (五) 13:57 (UTC)

管理员指引

現行條文

管理员决定对于编辑战参与用户是予以警告还是封禁或編輯禁制;采取这些行动是为了避免、制止争议行为,鼓励理性编辑,而不是为此惩罚用户。初次封禁可能是因为违反回退不过三原则或是有编辑战行为,而持续的编辑战行为会导致进一步的封禁。当适应采取封禁手段时,对于初犯通常给予24小时的封禁期;管理员对于累犯者或是挑衅意味明显的违反者可能会延长封禁期,同时还会考虑其他因素,如文明。当出现多个用户参与编辑战或违反3RR时,管理员应该通盘考量,否则不公正的处理可能会让事端扩大。

管理员的行动主要是为了警告正在进行中的编辑战。如果编辑战已经明显结束,没有明显地或可预见的进一步行为时,可以考虑采取警告或(对于反复的情形)其他管理手段,例如在告示板中进行讨论或保护页面。累犯可能会发现自己因为最近的一次编辑战而被封禁;这种情形下,封禁不是对过去编辑战的阻止或是对上次监管的补偿,而是对其进行的威慑和强制教育,防止其在未来再次发起编辑战。(参见封禁的用途和方针

本方针和“回退不过三”原则,都是为了防止和限制编辑战而设计的。它们不是配额制,不是鼓励用户将回退作为一种编辑技巧。进行扰乱性编辑的用户即便没有违反3RR,也仍然会因编辑战受到封禁,特别是当他们在回退页面时试图游戏维基规则。管理员会将用户在过去涉及编辑战的封禁记录考虑在内,常常会在出现仅仅出现破坏或编辑战行为时就采取行动。

管理员在尝试解决争论的时候,常常需要判定行为是否为编辑战。总体而言,没有共识或充分讨论支持的反复回退,以及其他常见形式的破坏性和扰乱性行为更可能被判定为编辑战。这样的判定常常要考虑用户是否表现出故意地阻止他人编辑的行为,尤其是通过游戏维基规则有意为之,以及采用其他更加有计划或性质更为恶劣的手法,如通过间断性地回退进行一场缓慢的编辑战,不恰当地与其他用户联手回退、滥用多重帐号或是挑衅式地反复使用回退。

提議條文

管理员决定对于编辑战参与者是予以警告还是封禁或編輯禁制;采取这些行动是为了避免、制止争议行为,鼓励理性编辑,而不是为此惩罚编者。初次封禁可能是因为违反回退不过三原则或是有编辑战行为,而持续的编辑战行为会导致进一步的封禁。当适宜采取封禁手段时,对于初犯通常给予24小时的封禁期;管理员对于累犯者或是挑衅意味明显的违反者可能会延长封禁期,对于不常引起争端且真诚改过的违反者可能会免除封禁。同时还会考虑其他因素,如文明。当出现多个编者参与编辑战或违反3RR时,管理员应该通盘考量,否则不公正的处理可能会让事端扩大。

管理员的行动主要是为了警告正在进行中的编辑战。如果编辑战已经明显结束,没有明显地或可预见的进一步行为时,可以考虑采取警告或(对于反复的情形)其他管理手段,例如在告示板中进行讨论或保护页面。累犯可能会发现自己因为最近的一次编辑战而被封禁;这种情形下,封禁不是对过去编辑战的阻止或是对上次监管的补偿,而是对其进行的威慑和强制教育,防止其在未来再次发起编辑战。(参见封禁的用途和方针

本方针和“回退不过三”原则,都是为了防止和限制编辑战而设计的。它们不是配额制,不是鼓励编者将回退作为一种编辑技巧。进行扰乱性编辑的编者即便没有违反3RR,也仍然会因编辑战受到封禁,特别是当他们在回退页面时试图游戏维基规则。管理员会将编者在过去涉及编辑战的封禁记录考虑在内,常常会在出现仅仅出现破坏或编辑战行为时就采取行动。

管理员在尝试解决争论的时候,常常需要判定行为是否为编辑战。总体而言,没有共识或充分讨论支持的反复回退,以及其他常见形式的破坏性和扰乱性行为更可能被判定为编辑战。这样的判定常常要考虑编者是否表现出故意地阻止他人编辑的行为,尤其是通过游戏维基规则有意为之,以及采用其他更加有计划或性质更为恶劣的手法,如通过间断性地回退进行一场缓慢的编辑战,不恰当地与其他编者联手回退、滥用多重帐号或是挑衅式地反复使用回退。

  • 主要是并入了现行方针“3RR”章节中的内容。--Antigng留言) 2022年8月5日 (五) 13:57 (UTC)

讨论区

该修改妥否?请社群审议。--Antigng留言) 2022年8月5日 (五) 13:57 (UTC)

  • (+)支持(!)意見:敝人認為明晰易讀且釐清補充實務考量,同時希望能就以下條文字面稍作補充:
    • 對於「引言」的「參與編輯戰的編者可能暫時或永久剝奪部分或全部頁面的編輯權。」:個人傾向稍加補充調整為「参与编辑战的编者应優先考慮進行溝通,设法解决争论或寻求其他編者帮助,否則可能遭暂时或永久剥夺部分全部页面的编辑权。」
    • 對於「什麼是編輯戰」的「本方針並非旨在規避所有具有潛在爭議的編輯行為乃至回退舉動。」:個人傾向使用表達中性之功能性的「消除」,稍調整為「本方針並非旨在消除所有具有潛在爭議的編輯行為乃至回退舉動。」。
    • 對於「應對編輯戰行為」之「發現他人編輯戰您可以採取的行動」的「不要參戰。」:由於對應前文提及「如果回退是必要的,另一名編者或許也獨立地產生了同樣的想法並付諸行動」,為避免讀者在理解上可能產生之判斷模糊空間,且內文已多次提醒讀者可能產生之風險和代價,個人傾向稍調整為「避免貿然參戰。」。--Kriz Ju留言) 2022年8月7日 (日) 00:50 (UTC)
  • 基本(+)支持:感謝閣下所做之整理。—— Eric Liu 創造は生命(留言留名學生會 2022年8月7日 (日) 04:22 (UTC)

修訂傀儡方針涉法律威脅之字樣

現行條文

警告:滥用多重账号严重违反了社群对您的信任,将很可能导致您所有曾使用的账号和IP地址被封禁。(在极端情况下,操作傀儡的账号会被永久封禁,不得再参与维基百科的编辑。)此外,其他维基人可能提议将此事转交您所在地的相关执法部门处理。这将会严重影响您的雇主、朋友、家人及传媒对您在网上活动方面的看法。故此,请勿滥用多重账号。

提議條文

警告:滥用多重账号严重违反了社群对您的信任,将很可能导致您所有曾使用的账号和IP地址被封禁。(在极端情况下,操作傀儡的账号会被永久封禁,不得再参与维基百科的编辑。)

如題。--WMLO留言) 2022年8月8日 (一) 02:10 (UTC)
(+)支持桐生ここ[讨论] 2022年8月8日 (一) 02:12 (UTC)
(+)支持。--Wikij1089留言) 2022年8月8日 (一) 12:38 (UTC)