本页使用了标题或全文手工转换

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

维基百科,自由的百科全书
跳到导航 跳到搜索

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


發表前請先搜索存档,參考舊討論中的内容可節省您的時間。
公告欄
# 話題 發言 參與 最新發言 最後更新(UTC+8)
1 提議新建交通車輛條目內容方針2 98 20 新科技 2022-05-18 15:38
2 規範人事任免投票的提問環節 46 16 Ericliu1912 2022-05-20 09:25
3 提议设立官方维基百科镜像供国内直连访问和编辑 90 26 Heihaheihaha 2022-05-19 19:58
4 信息安全问题 1 1 Ericliu1912 2022-05-13 05:43
5 修訂刪除方針 14 5 YFdyh000 2022-05-19 13:40
6 建議重啟管理員布告板 14 5 Ericliu1912 2022-05-15 01:20
7 修訂草稿指引准备草稿段落 1 1 Jimmy-bot 2022-05-20 00:14
8 关于Wikipedia:COVID-19條目共識 16 9 Ericliu1912 2022-05-17 10:35
9 限制flow-hide权限到自动确认用户 10 7 Stang 2022-05-19 03:35
10 研擬快速刪除孤立消歧義頁面 29 8 Sanmosa 2022-05-17 22:34
11 虚构格式手册的改善 34 7 Taeas 2022-05-19 22:17
12 關於WP:RFR/P、WP:RFR/R的排版問題 7 5 閃亮飛月 2022-05-18 22:44
13 提议引入en:WP:CSD#G5以快速删除被封禁用户滥用傀儡创建的低质条目 26 11 Lt2818 2022-05-20 20:02
14 可靠来源评级指引措辞调整 5 4 Steven Sun 2022-05-20 22:17
15 提议废除Wikipedia:小小作品的50字删除规定 14 11 閃亮飛月 2022-05-20 20:13
16 《人事任免投票资格方针(PL507)》条件1的修订 1 1 KirkLU 2022-05-20 20:06
發言更新圖例
  • 最近一小時內
  • 最近一日內
  • 一週內
  • 一個月內
  • 逾一個月
特殊狀態
已移動至其他頁面
或完成討論之議題
手動設定
當列表出現異常時,
請先檢查設定是否有誤

提議新建交通車輛條目內容方針2[编辑]

本指引為交通車輛條目內容指引,統一格式將有助於閱讀及編輯維護上的便利性,以及減少特定章節的編輯戰,目的是幫助編者建立具有一致性的條目作品。

行文結構

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

鐵路車輛

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

客運/公車車輛[註 1]

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

條目內容

不合適的內容

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

備註

  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)[回复]
@owennsonFacepalm3.svg 捂脸這根本已經不是維基的格式準則了…。直接修正就好了,另請教有哪些條目?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)[回复]
(-)反对:擔心會有其他用戶會用此標準而進行大規模刪除,近年的環境已經趕走了很多人不願更新了。--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)[回复]

規範人事任免投票的提問環節[编辑]

原标题为:限制RFA提问数量

限制提問數量提案[编辑]

为应对暂行安全投票的日程安排问题,拆分自管理人员选举制度改革。原提案者User:Ericliu1912

修訂申請成為管理人員指引內容如下:

現行條文

參與方式 管理人員提名需要經過14天(即兩周)的投票。具人事任免投票資格的使用者可以投支持票、反對票或中立票,也可以僅發表意見、向候選人提問(候選人有權決定是否作答)。投票后票數會自動更新,如果發現錯誤可至此處手動更正票數。

提議條文

參與方式 管理人員提名需要經過14天(即兩周)的投票。具人事任免投票資格的使用者可以投支持票、反對票或中立票,也可以僅發表意見、向候選人提問(候選人有權決定是否作答)。就提問而言,每人最多可提問二題,並允許就提問開展相關討論;超過額度者,其問題將被直接刪除。禁止以多重問題或「小題」形式繞過限制,這樣將被視為遊戲維基規則投票后票數會自動更新,如果發現錯誤可至此處手動更正票數。

鉴于原提案讨论中没有对提问数量限制提出明确的反对意见,故🕗 公示7日,2022年3月6日 (日) 02:02 (UTC) 結束。--Steven Sun留言) 2022年2月27日 (日) 02:02 (UTC)[回复]

我想說中維的RFA問題和英維的問題根本是完全不同。中維的問題一向就是以快問快答的形式,問題短,答案也短。至現今的RFA,只有極少的參與者是真的可以做到只問兩條問題。然後,即使是不作制止,候選人依然去回答問題與否。以兩題的方式根本很難讓一個投票者去了解候選人本身,畢竟問一下會否活躍,選不選介管己經是兩條問題。我是想說,就算設這些限制,只是想問問題的人只會轉到Talk Page、電郵、TG其他地方問,然後這些情況就更難掌握。對於我而言只是削足適履的方案。此外,像User:Carrotkit/猴子孵育場這些應該怎樣算。這是六個分題,還是只是一個大問題?--Ghren🐦🕐 2022年2月27日 (日) 05:33 (UTC)[回复]
  1. 候选人一般为社群较为活跃用户,在提名前社群一般就对候选人有大体的了解。不需要通过大量提问去从头了解候选人。况且问太多的低质问题,尤其是那些与维基百科无关的问题,同样也干扰投票者对候选人的认识。
  2. 本指引应只限制投票页的提问数量。在其它地方提问只要不违反其它相关指引及方针即可(以前社群也没有在其它地方提问的习惯,而且不少人的讨论页也不经常回复别人)。但不能在投票页为其他页面的提问引流,否则视为绕过限制。--Steven Sun留言) 2022年2月27日 (日) 08:13 (UTC)[回复]
    實際上當然是較為活躍的才可以被社群支持,但是提名本身是深入了解主張的行為。很多候選人沒有很具體的用戶論述,引致候選人雖然在某一方(比如專心在條目的用戶)很出色,但是對站務的主張卻可能不太具體的,只靠兩條發問實在難而得知具體立場。引流視作繞過規定基本上就只能(-)反对到底了。我想說低質問題就不應該回答。--Ghren🐦🕓 2022年2月27日 (日) 08:23 (UTC)[回复]
那得問多少題?幾百題是太過分了,你「問清楚」候選人的時候他也差不多要退選。引流這種「解壓縮」手段也是不怎麼可取,表面上一兩題,事實上得造成候選人數倍的負擔。—— Eric Liu 創造は生命(留言留名學生會 2022年2月27日 (日) 15:52 (UTC)[回复]
(...) 吐槽你至少也丟個幾天再公示吧 囧rz……--SunAfterRain 2022年2月28日 (一) 10:03 (UTC)[回复]
(-)反对,就之前管理員選舉的情況來看很多人提的問題數量都遠超兩題,此提案顯然不當。--🎋🎍 2022年3月1日 (二) 03:08 (UTC)[回复]
你这什么逻辑啊?因为之前很多人提的问题数量远超两题(我承认我也超过),所以现在提出限制每个人只能问最多两个问题。你的反对理据恰恰是这个提案要针对的问题;你自己说说,你这个反驳有效吗?--MilkyDefer 2022年3月1日 (二) 14:26 (UTC)[回复]
以人為單位其實換湯不換藥,你用盡「配額」,還可以找人替你追問啊,只要不被識穿就行了。我懶得翻查原來的討論紀錄了,但去年我想過一個方案:限制問題的總數(當時設想是14條左右),設立小組/專員審查問題,然後從獲批的問題抽籤;也許還可以考慮禁止必答和選答的選項(三條必答題出外)。這樣做對候選人負擔說不定會比公示方案小,但問題是誰來審查。--春卷柯南-發前人所未知 ( ) 2022年3月1日 (二) 09:56 (UTC)[回复]
供参考:Stewards organise the elections themselves... Therefore, stewards create an election committee for every election consisting of volunteers for the following tasks...,其中包括了划去不合要求的问题。 Stang 2022年3月1日 (二) 13:47 (UTC)[回复]
🕗 暫停公示。--Steven Sun留言) 2022年3月1日 (二) 11:27 (UTC)[回复]
我覺得比較可行的做法是讓社群意識到候選人拒絕回答不重要或有偏謬的問題的權利是絕對的(我不説候選人拒絕回答所有問題的權利是絕對的的原因是如果相關問題屬於合理憂慮的話,我認為任何人都會想問,而且候選人的回答有助釋疑)。Sanmosa A-DWY3 2022年3月3日 (四) 05:51 (UTC) +2 [回复]
  • 被選人本來就有不回答問題的權利。問題是,怎樣避免投票者因而投下反對票。--Temp3600留言) 2022年3月17日 (四) 12:25 (UTC)[回复]
    根本不可能避免,尤其是假如改採安全投票形式的話,就更難以用投票理由判斷投票有效程度。(加上籌備投票程序之複雜,我已經不怎麼支持管理人員選舉採用安全投票了)—— Eric Liu 創造は生命(留言留名學生會 2022年3月17日 (四) 12:52 (UTC)[回复]
    倒不是不可能避免,但避免的方式可能會很極端:如果規定候選人只需要作答三個基本問題,並禁止任何人進行任何其他的非程序性提問,那投票人不可能因為候選人拒絕回答三個基本問題以外的問題而投反對票,因為他一開始的非程序性提問已經違反規則了。Sanmosa Avec cœur 2022年3月17日 (四) 13:52 (UTC)[回复]

規範問答環節提案[编辑]

既然都+2了,我就提個反建議好了:

現行條文

參與方式 管理人員提名需要經過14天(即兩周)的投票。具人事任免投票資格的使用者可以投支持票、反對票或中立票,也可以僅發表意見、向候選人提問(候選人有權決定是否作答)。投票后票數會自動更新,如果發現錯誤可至此處手動更正票數。

  • 誰可以投票:為了確保使用者對於維基社群的運作有一定了解,僅限於符合人事任免投票資格者才能參與投票。投票者請先閱讀申請成為管理員的討論中應避免的理由
  • 誰不可以投票:未登录或未註冊使用者,以及不符合人事任免投票資格的註冊使用者不可以投票,非常新的使用者如果被懷疑是欺詐,如傀儡,則有可能會被視為無效票。
  • 加入你的投票:点击相關使用者的“在此投票”,並在相應的標題下簽上你的名字,以表明你是支持反對还是中立。與相應的標題相互矛盾的投票有可能被視為無效票。
  • 可以投中立票:中立票將不計算在有效票數中,但當投票結果處於通過標準的臨界時(如支持25票,反对6票),行政員會在評估結果時考慮中立票。
  • 為你的投票做出解釋:最好給出一個簡短的原因,尤其在投反對票時。這樣候選人及他人可以理解你的想法並給予答覆。
  • 注意尊重所有人:有時對話雙方可能愈來愈激動,甚至爭吵起來。請記住,所有人都是有感覺、情緒和自尊的。
  • 討論:詳細的討論請在意見區進行。任何人都可以討論或發表意見,包括匿名使用者。
提議條文

參與方式 管理人員提名需要經過14天(即兩周)的投票。具人事任免投票資格的使用者可以投支持票、反對票或中立票,也可以僅發表意見、向候選人提問。投票后票數會自動更新,如果發現錯誤可至此處手動更正票數。

  • 誰可以投票:為了確保使用者對於維基社群的運作有一定了解,僅限於符合人事任免投票資格者才能參與投票。投票者請先閱讀申請成為管理員的討論中應避免的理由
  • 誰不可以投票:未登录或未註冊使用者,以及不符合人事任免投票資格的註冊使用者不可以投票,非常新的使用者如果被懷疑是欺詐,如傀儡,則有可能會被視為無效票。
  • 加入你的投票:点击相關使用者的“在此投票”,並在相應的標題下簽上你的名字,以表明你是支持反對还是中立。與相應的標題相互矛盾的投票有可能被視為無效票。
  • 可以投中立票:中立票將不計算在有效票數中,但當投票結果處於通過標準的臨界時(如支持25票,反对6票),行政員會在評估結果時考慮中立票。
  • 為你的投票做出解釋:最好給出一個簡短的原因,尤其在投反對票時。這樣候選人及他人可以理解你的想法並給予答覆。
  • 注意尊重所有人:有時對話雙方可能愈來愈激動,甚至爭吵起來。請記住,所有人都是有感覺、情緒和自尊的。
  • 討論:詳細的討論請在意見區進行。任何人都可以討論或發表意見,包括匿名使用者。
  • 提問:任何人都可以向候選人提問,包括匿名使用者。請確保相關問題於維基百科或候選人在維基百科的活動而言屬重要,而且並不存在任何不當預設的謬誤,否則相關問題會造成候選人的困擾。候選人有權拒絕作答三個基本問題以外的一切問題,偏執要求候選人作答與維基百科或候選人在維基百科的活動無關或存在不當預設的謬誤的問題可被視為扰乱

以上。@Ericliu1912Jonathan5566GhrenghrenSteven SunSanmosa Veritas Vincit 2022年3月9日 (三) 14:15 (UTC)[回复]

支持概念。提出以下較細化的提問規則:
提議條文

參與方式 ... 向候選人提問 在管理員選舉中,候選人回答提問有助投票人作出是否支持此候選人成為管理員的決定。候選人自薦或接受提名時,需要回答三條基本問題(請見#流程一節)。除此之外,任何人都可以向候選人提出問題。為確保問題素質,防止程序被擾亂,問題應先在討論頁提出,若十二小時內未獲合理反對並獲得另一名具有投票權的用戶支持提出問題後,則可轉發至投票頁面的提問區。每一名具有投票權的用戶僅能支持或反對提出一條問題。提出的問題應當保持語調中立,不應明示或暗示投票立場,並應與維基百科或候選人於維基百科的活動相關,且不存在不當預設的謬誤,以確保問答環節能作為一個具建設性的對話環境。候選人有權拒絕作答三個基本問題以外的一切提問,但建議(不強制要求)說明拒絕作答及原因。在候選人回應後追加延伸問題是可接受的行為,但追加的問題必須與原先問題及候選人的回答有關;候選人同樣有權拒絕回應追加的問題。就要求候選人回應問題進行施壓,包括但不限於以選票威脅回應[a]和在候選人明確表明拒絕作答時仍反覆要求作答[b]等行為均可被視作擾亂程序的行為。

補充說明

  1. ^ 「不回應我就投反對」等類似發言屬於明確地以選票作出威脅要求候選人回應,此等行為是不被容許的。另,仍不建議作出「候選人的回答會影響我的投票決定」等雖禮貌但對問題無作用且稍有施壓意味的發言,這些發言對於問答沒有任何作用,是不需要明示的。
  2. ^ 您可以作出一次簡單、禮貌地回應請求(例:希望候選人能回答有關問題)。然而,尤其在候選人已經表明不想回應的時候,無論您的發言多麼禮貌,不斷、重複地作出有關要求也可能會有施壓的意味,請避免反覆要求回應問題。
@Sanmosa:看看這樣會不會對各方都更加友善?--路西法人𖤐 2022年3月10日 (四) 03:46 (UTC)[回复]
@LuciferianThomas:我還是如之前説的一樣:我不説候選人拒絕回答所有問題的權利是絕對的的原因是如果相關問題屬於合理憂慮的話,我認為任何人都會想問,而且候選人的回答有助釋疑。如果社群合理地認為某問題於維基百科或候選人在維基百科的活動而言非常重要,而且將會影響維基百科日後的運作情況,我認為任何一個或多個社群成員要求他回答是合理的,這種情況應當排除於“偏執要求作答”的情形外。我不反對禁止“威脅作出回答”,但我還是想就“威脅作出回答”的定義請求澄清:假如我提問時表示“候選人的回答會影響我的投票決定”(對,這就是原話)的話,這算是“威脅作出回答”嗎(我自己覺得這個措辭應該算是委婉)?Sanmosa Veritas Vincit 2022年3月10日 (四) 07:57 (UTC)[回复]
「候選人的回答會影響我的投票決定」不算威脅,確實符合中立語調也起碼算是禮貌,不過仍稍有施壓意味(我本來好像不是想寫威脅而是施壓,不過我當時想不起這個詞 囧rz……)。個人不建議說出來,因為這一句是沒有意義的,也不是給候選人的提問。
讓RFA不要成為一個toxic的環境是為此修訂的重點。關於社群要求作答的部分,如果候選人拒絕回答就沒有不斷要求作答的必要了,反正也不見得會改變到候選人的主意。其實我的寫法反而是想強調RFA提問的禮儀,而不是限制這個限制那個。禮貌地在討論中提到「希望能回答有關問題」的問題不大,但就算是多禮貌的說法,重複就會造成施壓,這才是我這個提議條文重心要避免的情況。候選人拒絕回答某些問題或在拒絕回答時是否提出合理理由應足以影響投票人的意見,施壓是完全不必要的行為。--路西法人𖤐 2022年3月10日 (四) 09:53 (UTC)[回复]
這樣說好像也是。而且,就算沒有施壓的意味,「候選人的回答會影響我的投票決定」這句話其實也形同廢話,因為就算提問人不説,候選人的回答本來就是大家的投票決定的合理影響因素之一(除非投票人鐵了心要支持或反對),因此我同意你修改後的版本。--Sanmosa 2022年3月10日 (四) 14:07 (UTC)[回复]
微調了字眼。--路西法人𖤐 2022年3月10日 (四) 13:27 (UTC)[回复]
@LuciferianThomasSanmosa
  1. 不建议给 支持/反对 限额。不可行。建议删去此条,转发门槛的1支持改为2支持,其余不变。
  2. 追加延伸(有这样说的吗?)问题是否需要再经过遴选?
  3. 提问的截止时间应提早一天。
  4. 个人认为新开独立页面作为提问(遴选)区可能更好。
  5. 不建议用tooltip。
  6. 为确保问题素质防止程序被扰乱。【翻译腔】
  7. 所有问题应先在讨论页提出。【无用且重复】
  8. 但建议可以不强制要求)说明拒绝作答及原因【累赘】
 ——魔琴 [ 留言 贡献 ] 2022年3月10日 (四) 16:27 (UTC)[回复]
感謝魔琴君的意見。
  1. 對支持、反對限額的作用是防止某些維基人因為不喜歡候選人而大量同意對候選人提出質疑的問題,幾個支持都沒分別,有一件事情叫組團。有限制之後組團來提出質疑性問題拉低投票人的很容易發現,因為得玩互相支持問題的套路。
  2. 我有想過這個問題,但跟上面一樣,防止灌問題。某程度上是跟限制問題數量相似,不過確實可以提出無限問題,只不過大家看到你這樣水問題有多少人會都給你全灌下去而已。
  3. 這個嘛……看上面投票時間討論成怎樣先吧。
  4. 不評論,不是不行,但好像又不太必要。
  5. 純粹是提案給你們參考字眼用,寫進指引不會包含。
後面三個您可以直接修訂,小問題(--路西法人𖤐 2022年3月10日 (四) 16:38 (UTC)[回复]
  1. 但是,这个提问是流动的。也就是说,第一天,我不知道我第13天会不会看到一个我需要去支持或反对的问题。而且如果大量灌问题,似乎也无法有效反对(当然也没人支持就是)。针对组团的事情,反对票可以解决……吧?
  1. 因为提问提出后不能直接被回答,提前一天截止可以防止提问废掉(而且上面讨论的好像只是临时)
  1. 已修改。
 ——魔琴 [ 留言 贡献 ] 2022年3月10日 (四) 23:05 (UTC)[回复]
(回覆見下,忘了ping)--路西法人𖤐 2022年3月11日 (五) 12:03 (UTC)[回复]
不知所云。假如每個有權者只能支持一條問題的話,事實上是將上邊的兩條問題收至一條,然後還再加上「十二小時」的規定約束之,四捨五入就是不要問問題。制度複雜,為候選人和投票者增加不必要的負擔。--Ghren🐦🕚 2022年3月11日 (五) 03:56 (UTC)[回复]
您的理解似乎誤會了這裡的意思。每個人仍然可以提出無限條問題,不過需要有其他用戶也覺得這題值得回答才送去問答區,不提問的當然也可以支持問題,我相信算下來會協助篩選題目的用戶數量應該比提問者數量多。A用戶可以提出五條問題,全部都是非常具有建設性的問題,態度也非常良好,那麼有另外五個個別的用戶來支持提出這些問題絕對不是難事。相反,如果B用戶提出五條沒建設性或者重複的問題,自然一條都不值得被轉過去。總而言之,這不是像上面的提案那樣按量去限制個別用戶的提問數量,而是按質去篩選題目(支持和反對題目可以看到題目是否真的值得提出)。以和平奮鬥救地球君的上次RFA有32個題目分段,且大部分發問者均提出多條問題,問題數多達百題,即使假設所有題目都是具有建設性的,不論在7天也好14天也好的提問期都明顯讓候選人不太可能招架。在這個新框架下,提問數量應比較可能控制在20至30題左右(7天提問期的話就應該15到20題左右),同一人當然仍然可以提出數道題目,但是不是每一題都具備對RFA的同等重要性,其他用戶就可以選擇說覺得哪些題目更具有重要性並支持提出有關問題,那麼就能讓最重要的議題能獲優先提問,次重要的就未必需要提出。關於魔琴的問題,我甚至覺得可以改成五天收集問題,兩天給所有延伸確認用戶篩選問題。我不覺得所有參與投票的都會跑去支持題目,這樣算下來應該能平衡流動性的問題。--路西法人𖤐 2022年3月11日 (五) 11:06 (UTC)[回复]
另一個可行方案是如上面所說,有五天收集問題(同樣容許一人多題),兩天進行問題篩選,然後僅轉發有限量的題目。甚至說,收集題目也可以匿名化,那樣就不會被「這個那個用戶提出的哦,支持/反對好了」影響。包括提問者和沒有提問的人均可兩票支持兩票反對,然後按照提問的支持率去篩選題目。這樣也可以確保題目數量對候選人而言比較可控的情況下回答具有重要性的題目。--路西法人𖤐 2022年3月11日 (五) 11:13 (UTC)[回复]
我沒有誤會這裏的意思。首先,本來每個用戶在方案一本來是可以是提出兩條問題的。但是,在新方案之下,實際上每個用戶被規定在一個問題上,只是用戶可以自由分配給誰問問題,實效來說就是一題。也就是說,實際上的問題數只會大概和投票人數之下,因為確實是有些用戶是不參與答辯的,不愛關注提問區,只是看一回就投了,然後假如是收集問題制,希望問問題的人又要以多餘的時間關注在提問之上,不然又會錯過了提問期;又或者要花時間在支持問題上,兩天支持一條問題,你實在是看得起整個社群的活動能力,中維的社群活躍度其實高度集中在百餘個用戶上,留意到與否也是一個問題。問題就是在於,在縮小題目數至一個極端的時候,實際上影響和候選人之間的交流。而且,你首先要將問題放在討論頁,然後要人支持,還需要人去確認支持的用戶是否有權,然後確定只是有一次,再放至主頁面,只是為了讓候選人回答。對於我來說就是為了換一個燈炮,然後出動了整村人,增加整倍的時間,只是為了候選人不敢果斷拒絕問題而擔心。整個方案充滿對社群的不信任。ADMIN的工作是自願的,候選人本來就沒有責任去回答所有的問題,自由權本來就應該在候選人上,而不是在社群之上。
我覺得可以探討的是沒投票權用戶提問的優次,可以像萌娘一樣明確要他們的提問是較為次要的,又或者禁止IP提問之類的。差不多IP提問都是各種傀儡,問題價值差不多就是零。--Ghren🐦🕗 2022年3月11日 (五) 12:38 (UTC)[回复]
萌娘百科那樣行得通是因為只有少數人有投票資格。在本站符合人事任免資格者眾。—— Eric Liu 創造は生命(留言留名學生會 2022年3月18日 (五) 19:11 (UTC)[回复]
即使如此,每一屆都有IP和無投權者問問題,而這些人的問題質量明顯低下。--Ghren🐦🕘 2022年3月24日 (四) 13:07 (UTC)[回复]
確實。—— Eric Liu 創造は生命(留言留名學生會 2022年4月2日 (六) 09:02 (UTC)[回复]
匿名化太難了,難不成每次都要用安全投票之類的問?--SunAfterRain 2022年3月13日 (日) 09:46 (UTC)[回复]
(沒有說必要)--路西法人𖤐 2022年3月24日 (四) 12:50 (UTC)[回复]
「所有問題均應先在討論頁提出」何也?—— Eric Liu 創造は生命(留言留名學生會 2022年3月10日 (四) 17:59 (UTC)[回复]
我猜可能是指RFA页面对应的讨论页?--Steven Sun留言) 2022年3月11日 (五) 02:42 (UTC)[回复]
是。--路西法人𖤐 2022年3月11日 (五) 10:24 (UTC)[回复]
我的意思是,為什麼要這樣進行?—— Eric Liu 創造は生命(留言留名學生會 2022年3月11日 (五) 16:59 (UTC)[回复]
如同Temp3600下面所言,如果維基人能夠自律,當然不用……需要的原因還是因為防止灌題而已。--路西法人𖤐 2022年3月24日 (四) 12:48 (UTC)[回复]
確實有理。—— Eric Liu 創造は生命(留言留名學生會 2022年4月14日 (四) 19:45 (UTC)[回复]
  • 支持上述的軟性規範。說到底,維基人如果能自律,就能減少這類難以設立有效規範的情況。另外,再次建議設立問題庫。--Temp3600留言) 2022年3月17日 (四) 14:42 (UTC)[回复]
  • 支持概念版。细化版或可作为指引,作方针需要评估试行再说,并且“明确要求”难以避免很多问题。“仅能支持或反对提出一条问题。”需要改掉,非常像仅有一笔投票权。--YFdyh000留言) 2022年4月6日 (三) 16:57 (UTC)[回复]
  • 能否由行政员和管理员作为提问主持人根据提问参与度选出10个以内相关度高的问题,同时根据提问数量也可再加选出5个以内呼声高的问题作为补充提问。不限制提问数量,不限制每个人的问题的入选数量。-- WPTO 2022年4月7日 (四) 01:19 (UTC)[回复]
  • 或许提问者可以尝试用邮件功能向候选人提问,这样提问和回答都是私密的。即使候选人不回答提问者的问题,也只会影响相应提问者的投票决定,不会影响更多人。可能可以减轻候选人的负担。--50829! Talk · 494,976,576 2022年5月14日 (六) 05:44 (UTC)[回复]
  • 根据到目前的实践来看,尚无任何一名管理员候选人在不回答任何问题的情况下当选。是否可以规定候选人必须回答的问题数量,如必须回答所有问题中任意的30%,其余问题则可以忽略?--Yining Chen留言|签名页) 2022年5月19日 (四) 15:04 (UTC)[回复]
    我想就是因為如此,才不會有候選人敢不回答任何問題的。個人以為並無必要設置答題數量低標。—— Eric Liu 創造は生命(留言留名學生會 2022年5月20日 (五) 01:25 (UTC)[回复]

提议设立官方维基百科镜像供国内直连访问和编辑[编辑]

首先提醒一下,这不是纯粹的技术问题,只有社群确定“这样做合适”之后才应该讨论技术细节。

这是我在近期乌克兰战争的背景下产生的想法。如果设立官方镜像,以下问题可以解决:

  1. 国内用户无法直连访问(不考虑少部分技术能力强的用户)
  2. 国内用户编辑必须要通过代理及申请IPBE,步骤繁琐(这是本站长期以来的痛点)

然后关于能不能实现,我问了几个技术人员,回答是“有难度但并非完全不可行”。

补充:下方我的两个发言澄清了常见的误解,请各位发言之前先看一遍,已有的问题请不要重复提出,谢谢。

以上。好久没来客栈了,总之欢迎各位留言,谢谢。--Tranve () 2022年4月1日 (五) 01:43 (UTC)[回复]

如果好不容易建起來然後就被封了怎麼辦?—— Eric Liu 創造は生命(留言留名學生會 2022年4月1日 (五) 01:47 (UTC)[回复]
当然是打一枪换一个阵地。域名封一个换一个。IP的话可以考虑用CDN,GFW一般不会封CDN的IP。--Tranve () 2022年4月1日 (五) 01:49 (UTC)[回复]
2021年维基媒体基金会针对中文维基百科的行动里面中国政府的态度还不够明确?这种跟土共打游击的玩法没啥意义,就算是CDN,CDN的IP一样有办法扬掉(github等有几个CDN服务商的IP被长期盯死了)。——Sakamotosan路过围观 | 避免做作,免敬 2022年4月1日 (五) 02:37 (UTC)[回复]
设立官方维基百科镜像,就需要走合规途径。“当然是打一枪换一个阵地。域名封一个换一个。IP的话可以考虑用CDN,GFW一般不会封CDN的IP”。这是完全不合规的做法--百無一用是書生 () 2022年4月1日 (五) 03:14 (UTC)[回复]
嗯……我想你误解我的意思了。如果你的“规定”指的是中国法律的话,那上维基百科本来就犯法了,还管它干什么?如果是基金会的相关规定,我的本意就是想现在这里沟通然后再去和基金会提意见。--Tranve () 2022年4月2日 (六) 02:11 (UTC)[回复]
这种不合CDN服务商的规定,最终结果就是CDN被GFW封掉,GFW为了封掉Twitter可是把Fastly封了,于是没有CDN会愿意为维基百科提供服务。桐生ここ[讨论] 2022年4月3日 (日) 14:33 (UTC)[回复]
为什么不合规?Fire Ice 2022年4月1日 (五) 14:23 (UTC)[回复]
多让一个人上维基百科就是意义。你维到底为十四亿人接触自由知识做了什么!?--Fire Ice 2022年4月1日 (五) 16:02 (UTC)[回复]
這些話你找習近平說更好,為什麼不讓中國人瀏覽維基百科,為什麼要把翻墻瀏覽維基百科的中國人拘留。如果要找基金會,就像我下面所說的,勸他們允許使用代理服務器的用戶直接免IPBE就能編輯。--中文維基百科20021024留言) 2022年4月1日 (五) 16:45 (UTC)[回复]
现在是客观条件无法改变,只能指望基金会主观努力了。--Fire Ice 2022年4月2日 (六) 12:35 (UTC)[回复]
基金会没有主观努力的必要,只要不按照中国政府的要求进行内容审查,主观努力反而会得罪中国政府,彻底被认证为境外颠覆势力,造成基金会人士或社群知名人士进入中国境内的人身安全风险。你见Facebook、Twitter、Google有主观努力和GFW打游击战吗?桐生ここ[讨论] 2022年4月3日 (日) 14:26 (UTC)[回复]
@Cwek:首先那些服务商都没有被完全扬掉,只是间歇性抽风。退一万步讲,就算你维真的被这样针对,也比现在的情况好太多了。现在可是完全不能访问啊!--Tranve () 2022年4月2日 (六) 02:13 (UTC)[回复]
是CDN服务商的部分IP。推断是路由黑洞。——Sakamotosan路过围观 | 避免做作,免敬 2022年4月2日 (六) 02:26 (UTC)[回复]
是的,阁下提出了一个可能有机会解决问题的方法,与其解决镜像站的准入标准,不如使用官方镜像站。--Pavlov2仁爱亲诚 2022年4月1日 (五) 12:55 (UTC)[回复]
與其提供中國直連不如允許中文站無需IPBE直接代理編輯更好。因為中國直連這一方式政治上走不通。代理編輯由與基金會政策違背,除非基金會願意特殊對待中文站。如果說說服中共和基金會的話,好像說服基金會相對更容易一些?--中文維基百科20021024留言) 2022年4月1日 (五) 16:41 (UTC)[回复]
又是閆那個消極對待開放代理的方法嗎?--Ghren🐦🕛 2022年4月1日 (五) 16:53 (UTC)[回复]
消極對待開放代理是指?--中文維基百科20021024留言) 2022年4月1日 (五) 17:04 (UTC)[回复]
之前Techyan等提出开放代理不应该自动封禁,而是有破坏再去封,方便大陆用户注册使用,然后Jimmy-abot就停止自动封禁开放代理。(節刪)[2021年9月]被推翻。 ——魔琴 [ 留言 贡献 ] 2022年4月3日 (日) 03:22 (UTC)[回复]
因為techyan被封禁所以那個措施就要被推翻?誰提出的?--中文維基百科20021024留言) 2022年4月3日 (日) 03:27 (UTC)[回复]
Wikipedia:互助客栈/其他/存档/2021年9月#重启“机器人自动封禁机房IP段的任务”的提议,和913没啥关系。--Lt2818留言) 2022年4月3日 (日) 03:50 (UTC)[回复]
忘记具体时间了,已经节删。 ——魔琴 [ 留言 贡献 ] 2022年4月3日 (日) 06:39 (UTC)[回复]
我只能说techyan这么做,为LTA逃脱CU大开方便之门--Pavlov2仁爱亲诚 2022年4月3日 (日) 07:57 (UTC)[回复]
我猜测肯定之前有人讨论过这个方案,但是事实上中维并没有放开IPBE,估计这么做肯定是遇到问题了。--Tranve () 2022年4月2日 (六) 14:07 (UTC)[回复]
(~)補充:澄清一下上方的误会。我的想法是我们可以像某些VPN服务商、NSFW网站和樱花动漫一样,搞一系列的官方镜像站,通过多种渠道散播其地址。如果一个被封了,就换另一个顶替。--Tranve () 2022年4月2日 (六) 02:10 (UTC)[回复]
因为是官方镜像站,所以技术上我们是可以知道访问者的真实IP的,这样就从根本上规避了IPBE的问题。
我知道这个做法比较难看,但它却是最符合中国国情的方案——对新手友好,学习成本低。想想看Help:如何访问维基百科里头有多少技术范的方案,但是又有几个新手会用呢?--Tranve () 2022年4月2日 (六) 02:22 (UTC)[回复]
维基百科条目常被引注,其链接需要长期保持可用。如果搞一系列的官方镜像站,那么每个域名都不能随意抛弃,要考虑长期维护域名的成本。--Lt2818留言) 2022年4月2日 (六) 04:56 (UTC)[回复]
确实有这个情况。但我觉得在镜像站里写好“引注使用原网址”,像安忆的镜像站一样,就好。总之感谢各位的意见。--Tranve () 2022年4月2日 (六) 14:06 (UTC)[回复]
官方镜像站八成不会有,“封一个换一个”不是说的那么简单的,无论是域名还是IP,很显然要考虑成本问题。树大容易招风,镜像站本就应该小众,才能降低被封的几率,官方提供镜像站做不到维持小众,而且维基百科本就受到墙的重视,要不然不至于五个IP有三个被封。--🔨留言) 2022年4月2日 (六) 08:56 (UTC)[回复]
成本问题我觉得WMF自己最清楚吧。到时候可以问问他们。--Tranve () 2022年4月2日 (六) 14:04 (UTC)[回复]
域名也是要钱的,同时维护镜像站也需要一定的人力。假如说每换一个域名都是没过几天就被墙,还不如干脆不搞。--🔨留言) 2022年4月2日 (六) 14:59 (UTC)[回复]
咱不知道基金会能不能做,咱只知道安忆的镜像站没钱了( ——魔琴 [ 留言 贡献 ] 2022年4月2日 (六) 15:42 (UTC)[回复]
还有爱发电的捐助链接(——诚挚的 ZhaoFJx 2022年4月12日 (二) 13:53 (UTC)[回复]
2020年Techyan就提过几乎相同的提案:m:Wikimedians of Mainland China/Draft proposal on establishing an official mirror site of Wikimedia projects for mainland Chinese users。--GZWDer留言) 2022年4月2日 (六) 20:25 (UTC)[回复]
这个似乎只是草稿,还没有正式讨论。--Tranve () 2022年4月2日 (六) 23:22 (UTC)[回复]
真要合规运营,我估计必须在镜像站删掉一些(甚至大量)“敏感内容”,这就是彻底把WP:NOTCENSOR当摆设了。--BlackShadowG留言) 2022年4月3日 (日) 07:23 (UTC)[回复]
用镜像站和GFW打游击战这种方式,WMF肯定是不会做的,倒是可以中维社群设立一个社群官方镜像站。WMF服务器通过捐款运营,那么社群官方镜像站也可以通过捐款运营,可以成立一个维基百科组织负责运营官方镜像站,并且可以和WMF一样在中文维基百科打募集捐款的广告,这个组织可以写入方针指引,就像WP:機械人審核小組一样。桐生ここ[讨论] 2022年4月3日 (日) 14:44 (UTC)[回复]
我觉得这个想法很好啊!--Fire Ice 2022年4月3日 (日) 14:50 (UTC)[回复]
如此镜像站运营者面临极高法律风险,相当于外国基金会注资的代理人;用户数据安全也成问题;捐款同样有法律问题。官方性质或背书的镜像站运营我认为不可行,推广亦同样需慎重低调,希望各位先想清楚。如果是通过工具或网站代理访问,面临渠道被封和IPBE、反破坏问题。--YFdyh000留言) 2022年4月3日 (日) 15:19 (UTC)[回复]
我们都不是WMF,谁也不能代替他们发言吧?--Tranve () 2022年4月3日 (日) 15:59 (UTC)[回复]
这个想法不错,不过还是那句话,树大招风,而且还要考虑“内鬼”的问题,如果能够确保维持小众低调,镜像站自然活得久一些,同时也能够尽最大可能节省成本。--🔨留言) 2022年4月3日 (日) 16:58 (UTC)[回复]
  • 要是這樣可行,google等早就做了,何必等我們提出。--Temp3600留言) 2022年4月4日 (一) 02:18 (UTC)[回复]
    WMF出面也不是没有可行性。一种可能合规的偷鸡办法是WMF在GFW自由港租用服务器设立缓存代理,中国大陆IP访问维基百科直接路由到这里的服务器。因为GFW自由港位于GFW之内又不受GFW管控,所以中国大陆用户应该可以自由访问维基百科。这个办法最大的问题是如何在GFW自由港租用到服务器?--百無一用是書生 () 2022年4月6日 (三) 02:41 (UTC)[回复]
    “GFW自由港”是什么东西啊。@Shizhao Stang 2022年4月6日 (三) 13:48 (UTC)[回复]
    HK?--BlackShadowG留言) 2022年4月7日 (四) 00:07 (UTC)[回复]
    Shizhao,你对大陆的理解有点脱节了吧,港澳都算是中国大陆境外的,一样要过墙的。——Sakamotosan路过围观 | 避免做作,免敬 2022年4月7日 (四) 01:00 (UTC)[回复]
    北京、上海等少数几个城市有专为外资服务的数据中心,这些数据中心不受GFW管控,不用过墙,同时又位于墙内。我一时不知道怎么说这个事,可以类比于中国大陆境内的自由贸易区,故以“GFW自由港”称之--百無一用是書生 () 2022年4月7日 (四) 02:01 (UTC)[回复]
    我不认为这些自由贸易区的网络和中国互联网骨干网之间不过墙(好处就是国外企业可以直接在中国大陆落地,减少过海的通信延迟,不用像中国电信主力出口都在美国西海岸或者德国,自动增加100ms加抖得要命的抖动,对于国外CDN来说会体验改善不少),而且按照一如既往的中国政府态度,内容审核是逃不过。结果就是,如果直接放在国内网络,肯定要做内容审核;放在贸易区,除了延时和丢包抖动会大幅减少,该过墙的还是过墙,和放在香港某些非专线的服务器一样没啥区别(例如移动的出口主要在香港,算上过墙延迟也在60ms左右,基本就是国内骨干网的常态)。——Sakamotosan路过围观 | 避免做作,免敬 2022年4月7日 (四) 02:20 (UTC)[回复]
    说的是墙内节点走专线做CDN?我不认为这可能通过审批/备案和稳定运行,同时高成本。安全性也很难兼顾,似乎比较安全的CloudFlare Keyless SSL非标准化。--YFdyh000留言) 2022年4月7日 (四) 07:55 (UTC)[回复]
    不一定要用IPLC之类的专线。只要国内能访问,不容易被GFW墙掉就可以。这点取决于基金会。--Tranve () 2022年4月8日 (五) 11:41 (UTC)[回复]
    不大可能,最常用的访问入口——域名可以被投毒或者审计控制(例如托管在中国大陆的VPS如果绑上没备案的域名提供HTTP(S)服务,VPS服务商是知道的,然后直接将机器下线)。IP可以被黑洞掉或者要求ISP接入商拔线。甚至还有TCP RST等其他技术手段。——Sakamotosan路过围观 | 避免做作,免敬 2022年4月10日 (日) 09:50 (UTC)[回复]
    取得任何物理位置在中华人民共和国(含港澳)内的服务器之掌控权对于官老爷来说可谓轻而易举,所谓的“GFW自由港”也不会例外。--🔨留言) 2022年4月7日 (四) 02:59 (UTC)[回复]
    就算当地政府允许,wmf本身都不会同意吧。目前wmf甚至不允许居住地在中国大陆且该信息为他人所知的用户持CU权限,以免权限遭破解;直接把服务器设在中国大陆就不怕用物理手段破解权限了么?--Antigng留言) 2022年4月6日 (三) 14:26 (UTC)[回复]
    @Antigng:没说要让当地政府允许啊……是基金会设立官方镜像和不允许访问维基百科的政府玩躲猫猫。--Tranve () 2022年4月8日 (五) 11:40 (UTC)[回复]
    这个讨论总是想技术上有没问题,就没有考虑过内容有没问题。从内容而言,一堆不符合中国政府意见的内容,这足以断掉满足“合规”的想法,如果把接入服务器(无论是类似现在基金会使用的准静态缓存机制,还是现在常见的动态反向代理)放在中国大陆境内互联网的,就肯定无法通过域名或者服务器接入审批,就算打游击,被端掉是迟早的事;如果放在离中国大陆近但属于“境外”的网络,例如自由贸易区和香港等,该过墙的还是和现在的一样,除了延迟减少了,没啥区别;如果搞配合内容审查的,那就和百度百科那些不就一丘之貉?简而言之,在内容问题没解决之前,技术不是主要问题。——Sakamotosan路过围观 | 避免做作,免敬 2022年4月7日 (四) 09:06 (UTC)[回复]
    果然还是绕不开内容问题。这样我能想到的最多也就是在大陆建立一个会过滤内容,只可浏览,不可编辑的镜像站(有点类似于蜻蜓计划)。这样能让更多的大陆用户看到维基百科的一些比较优质的条目,有利于吸引更多大陆用户来主站编辑,且应该也不会让维基百科沦落成百度百科那样,毕竟真的想来编辑的还是得绕开GFW的。--BlackShadowG留言) 2022年4月7日 (四) 12:22 (UTC)[回复]
    要不然怎么会催生出类似万维百科这样的的玩意?(或者求闻百科之类的)——Sakamotosan路过围观 | 避免做作,免敬 2022年4月8日 (五) 00:45 (UTC)[回复]
(~)補充:再次澄清上方的误会:
  1. 镜像站是否需要得到政府允许?是否需要自我审查?答案都是“否”。显然,WMF和中文维基百科社群都不会向审查妥协。设立官方镜像站本身的目的也在于规避政府的网络审查,还请各位不要搞错了。
  2. 为什么别人没有做?有人做过。我举几个例子,NordVPN、赛风和自由门等都存在大量这样的官方镜像站。
  3. WMF愿不愿意做?我们都不是WMF,我们怎么知道?这得去问他们。我已经在想办法问了,各位稍等。
  4. 最后在啰嗦一句,我在客栈发起讨论的目的仅仅是征求大家的意见,及“假定所有技术问题都可以解决,社群愿不愿意假设这样的镜像站”。具体的技术问题只有讨论得出共识和结论之后,才能由WMF解决。
以上。--Tranve () 2022年4月8日 (五) 08:03 (UTC)[回复]
cc @Antigng、@Cwek、@BlackShadowG、@Ericliu1912、@Fire-and-Ice、@GZWDer、@Ghrenghren、@Liu116。--Tranve () 2022年4月8日 (五) 08:04 (UTC)[回复]
WMF支持的話我也沒理由反對。問題是WMF不可能支持,要是WMF支持的話,我和劉醬一樣女裝 囧rz……[開玩笑的]。--Ghren🐦🕓 2022年4月8日 (五) 08:11 (UTC)[回复]
技术可行不代表实际可行,因为政策或法律上不太可行。如果不是政策或法律上的问题,为什么像“万维百科”那样搞出手工审查来筛选显示的条目和内容,不少私下的动态镜像要么想法子设限制或者躲避探测,要么就是嗝屁了(无论是无法维持运营,还是因为被发现而端了)。正如上面所说的,如果搞游击是可行的话,Google等早就可以这样玩了,如果搞内容审查可行的话,Google为什么想搞蜻蜓计划,最后还被搞黄了?技术谁不知道可行?——Sakamotosan路过围观 | 避免做作,免敬 2022年4月8日 (五) 09:14 (UTC)[回复]
既然提到我们不是WMF,那我们讨论这些就是废话。有问题请到元维基meta:Requests for comment他们反馈,最好at上WMF的法律相关工作人员。——Sakamotosan路过围观 | 避免做作,免敬 2022年4月8日 (五) 09:17 (UTC)[回复]
这些站点(NordVPN、赛风和自由门等)打游击而不是光明正大地设一个不会跑的庙,不就是因为无法解决法律合规性嘛。如果是固定的庙,被端只不过是迟早的事。——Sakamotosan路过围观 | 避免做作,免敬 2022年4月8日 (五) 09:20 (UTC)[回复]
PS.从技术而言,城墙的三板斧有的是搞你的路数。被发现和被端只是时间问题。(可以查阅一下中国大陆对维基媒体的封锁措施的演进,甚至我怀疑部分措施升级,如IP黑洞,中国大陆默认分配旧金山接入点,虽然可以通过技术来调整,但部分没分配给中国大陆的接入点IP一样黑洞掉;或者wikipedia.org的二级域,早期只是特定语区的域名投毒,后来直接整个二级域SNI RST,是不是和一些规避手段滥用有关。)——Sakamotosan路过围观 | 避免做作,免敬 2022年4月8日 (五) 09:33 (UTC)[回复]
(!)意見感觉没有必要。想想谷歌的Dragonfly计划,再想想一旦官方镜像被传播之后大陆官方会有什么反应,所以不如没有。或者不如说传播必然导致北京实施对WMF不利的举措。--Я, Якийсь Вікіпедист із КитаїU·K·R) 2022年4月10日 (日) 03:18 (UTC)[回复]
(~)補充关于中国大陆对维基当前的态度,在下讲一个发生在自己身上的故事,也许有参考意义。在下因为在维基编辑活跃(与政治类条目无关)而在17天前被一部分自诩为“爱国”的学生举报,8天前被大学建议进行“休学”。足可见镜像站公布后大陆会是什么反应。--Я, Якийсь Вікіпедист із КитаїU·K·R) 2022年4月10日 (日) 03:48 (UTC)[回复]
@A Chinese user:請問是聊天的時候透露出去自己在寫維基還是在寫維基的時候被寢室室友看到了?--中文維基百科20021024留言) 2022年4月10日 (日) 04:04 (UTC)[回复]
在下是被人“开盒”了。寝室室友没有过激的反应。--Я, Якийсь Вікіпедист із КитаїU·K·R) 2022年4月10日 (日) 04:12 (UTC)[回复]
太张扬了?不过现在某些人的主观过于激进了。——Sakamotosan路过围观 | 避免做作,免敬 2022年4月10日 (日) 08:01 (UTC)[回复]
这应该在这里是题外话,有兴趣不妨移步在下讨论页。--Я, Якийсь Вікіпедист із КитаїU·K·R) 2022年4月10日 (日) 08:43 (UTC)[回复]
可怕,建议WP:ANON桐生ここ[讨论] 2022年4月11日 (一) 03:42 (UTC)[回复]
( ✓ )同意。--Я, Якийсь Вікіпедист із КитаїU·K·R) 2022年4月11日 (一) 03:45 (UTC)[回复]
(?)疑問 与其大张旗鼓公开官方镜像站并冒着被封的风险,大陆人难道就不能用自建/他建的小众镜像站?小众镜像站使用的人群更少且更隐秘,使用体验与官站相差无几。私站与官方镜像站的区别就是一个承认与否的事情。具体可参考安忆的Wikimirror——诚挚的 ZhaoFJx 2022年4月13日 (三) 04:59 (UTC)[回复]
只要能按照基金会的要求,正确设置X-Forwarded-For,基金会就能正确处理反向代理后的正确IP。如果由基金会设立大陆内代理甚至是正规的边缘缓存接入(就像旧金山、新加坡、阿姆斯特丹)那样,可信性更好;如果是靠私下设立的动态代理或者镜像,谁保证会遵守设好这些设置?就像安忆的好几次被投诉过能不能针对他的代理的出口开IP豁免,可能就是没有设置正确的xff。——Sakamotosan路过围观 | 避免做作,免敬 2022年4月13日 (三) 05:50 (UTC)[回复]
不……部分大陆编者可能出于安全性的考量而不想使自己的IP地址被任何人查阅。如果使用XFF透过反向代理解析原IP地址反而可能引发大陆编者的不信任。 囧rz……总不能到时候用Tor访问镜像站吧。——诚挚的 ZhaoFJx 2022年4月14日 (四) 14:14 (UTC)[回复]
你搞错了问题吧,初始提议就是希望避免大量使用LIPE方便中国大陆编辑,那就两套机制:在中国大陆内的边缘缓存(就像基金会的旧金山、新加坡、阿姆斯特丹节点),或者在地的代理配置好xff(代理转达其背后的真正的源地址);前者存在不可能的合规性,后者同样有合规性和技术可信性问题(xff可以伪造或不提供)。如果单纯为了隐藏身份,要么搞到国外的家用宽带地址使用而不需要LIPE,要么买VPS做跳板,做好xff的话就和正常情况一样,没做好的话就等于隐藏了真实IP,但按照NoProxy的态势,请按需 申请LIPE解决。——Sakamotosan路过围观 | 避免做作,免敬 2022年4月15日 (五) 00:59 (UTC)[回复]
你们打开IP查询不怕zf查阅吗,毕竟GFW都在不断升级,zf总有办法。还不如直接在中文把vpn封禁单方面取消,否则那么多大陆用户注册都那么艰难。或者搞一个Wikipedia China也行。--Neonlight185留言) 2022年4月21日 (四) 08:57 (UTC)[回复]
开放代理封禁取消不担心有人用傀儡破坏?以及,中国中文维基百科是直接秘密在中国建服务器(本质上还是镜像站)还是与政府合作跨维基导入审查?————诚挚的 ZhaoFJx 2022年4月21日 (四) 10:13 (UTC)[回复]
关于开放代理封禁的问题无疑荒谬,原因同上。「直接秘密在中国建服务器」(严格意义上说这已经很难说得上是镜像站了)传播后必然招致审查,毋庸置疑。--  2022年4月24日 (日) 05:20 (UTC)[回复]
我就支持能够处理反向代理正确IP的镜像站,毕竟有时即便是有本地IPBE和全域IPBE,但若是代理IP被其他语言的维基百科追加本地封锁,还是不方便编辑该语言版本的。担心IP泄露的话,完全可以为镜像站加个必须登录才能编辑的设定。--🔨留言) 2022年4月24日 (日) 06:53 (UTC)[回复]
有没有一种可能,中国大陆的(官方)镜像站自动设置虚拟IP(但做出恶意编辑时可以找回真实IP)作为「掩体」?--  2022年4月24日 (日) 07:27 (UTC)[回复]
(純技術問題)讓鏡像站永遠回傳X-Forwarded-For,並且向基金會申請讓鏡像站IP成為(對基金會來說)已知的代理伺服器,只要登入時紀錄在CU系統的就是它的原始IP?--SunAfterRain 2022年5月10日 (二) 01:46 (UTC)[回复]
基金会IP mask方案准备给IP用户临时用户名了,似乎可选,基于Cookie。所以镜像站或可能基于IP和Cookie强制给用户启用临时用户名。--YFdyh000留言) 2022年5月11日 (三) 00:39 (UTC)[回复]
目前来看在每个非官方镜像站当中已经有wikimirror这个站点,感觉很稳定。--我是软路过偶尔会编各种条目的(^O^) 2022年5月1日 (日) 12:57 (UTC)[回复]
安忆的镜像站确实可以——诚挚的 ZhaoFJx 2022年5月2日 (一) 01:12 (UTC)[回复]
可能也要考慮到穩定性問題以及其他因素(譬如GFW)。--紹💓煦11000+ · 意見箱 2022年5月9日 (一) 17:55 (UTC)[回复]
(-)反对,没有必要。中国国内的人不翻墙,不仅上不了中文维基,也不上不了英文维基,上不了Google查资料,上不了new york times、BBC新闻网。就算用户不翻墙能上维基百科了,他找不到合格的参考资料,也写不了条目。--Gqqnb留言) 2022年5月16日 (一) 16:20 (UTC)[回复]
您难道是指只要是中国大陆人都用不着维基百科、写不好条目吗?--Tranve () 2022年5月17日 (二) 11:43 (UTC)[回复]
我觉得从微博抖音等社交平台的评论风气来看,应该对开放编辑持谨慎态度。我并不确定他们会不会关注维基,会不会有肖战粉丝类似的行为?(编辑战?)(可能是我反应过激了)(认识不深还请多多谅解)
另起:vpn也多半是有vpn的才能扩散,未翻墙的人是很难翻墙的(授人以鱼不如授人以渔?)--Heihaheihaha留言) 2022年5月19日 (四) 11:58 (UTC)[回复]
提醒两点,编辑只是镜像的作用之一,以及不是只有墙外才有可靠来源。--YFdyh000留言) 2022年5月17日 (二) 22:31 (UTC)[回复]

信息安全问题[编辑]

修訂刪除方針[编辑]

刪除方針

現行條文

流程 (...)

存廢討論

七日後,若對於提刪頁面的處理方式(例如保留、刪除、合併、重新導向)有共識,一名未參與提刪和討論的管理員或富有經驗的編者將依有關指引關閉存廢討論,在頁面討論頁記錄討論共識(除非共識為刪除)並執行共識。如果有編者對結案有異議,則此討論須由管理員最終結案。(...)

提議條文

流程 (...)

存廢討論

七日後,若對於提刪頁面的處理方式(例如保留、刪除、合併、重新導向)有共識,一名未參與提刪和討論的管理員或富有經驗的編者將依有關指引關閉存廢討論,在頁面討論頁記錄討論共識並執行共識。請注意結案者的職責是執行共識。如果共識很明顯的一面倒但結案的管理員不同意其他人給出的理由,那麼他並不應該直接以管理員身分執行與共識相關相反的結果,而是應該以一個普通編者的身份參與討論,並陳述為什麼他認為其他人不符相關的方針指引,留待其他管理員結案。如果有編者對非管理員的結案有異議,則此討論須由管理員最終結案。(...)


關閉存廢討論指引

現行條文

頁面存廢討論關閉的規則 (...)七日後,若對於提刪頁面的處理方式(例如保留、刪除、合併、重定向)有共識,一名未參與提刪和討論的管理員或富有經驗的編者將依《關閉存廢討論指引》關閉存廢討論,在頁面討論頁記錄討論共識(除非共識為刪除)並執行共識。如果有編者對結案有異議,則此討論須由管理員最終結案。(...)

提議條文

頁面存廢討論關閉的規則 (...)七日後,若對於提刪頁面的處理方式(例如保留、刪除、合併、重定向)有共識,一名未參與提刪和討論的管理員或富有經驗的編者將依《關閉存廢討論指引》關閉存廢討論,在頁面討論頁記錄討論共識(除非共識為刪除)並執行共識。請注意結案者的職責是執行共識。如果共識很明顯的一面倒但結案的管理員不同意其他人給出的理由,那麼他並不應該直接以管理員身分執行與共識相關相反的結果,而是應該以一個普通編者的身份參與討論,並陳述為什麼他認為其他人不符相關的方針指引,留待其他管理員結案。如果有編者對非管理員的結案有異議,則此討論須由管理員最終結案。(...)

發生過太多次管理員以個人意見罔顧共識關閉存廢討論,這種歪風自蟲蟲飛甚至更早就已經一直存在,應予制止。況且以現在情況「結案人必須未參與提刪或討論」這項規定就淪為無牙老虎:因為如果管理員不同意共識,那麼只要他不參與討論就可以以自己的一己之見結案-某人 2022年4月29日 (五) 18:39 (UTC)[回复]

  • (-)反对。在本站,共识不是数票数,而是要比较争议双方/多方意见的合理性。如果某一方“給出的理由並不符相關的方針指引”,而另一方则符合,那无论票数如何分布,按定义共识都是“一边倒”——只不过是倒向有合法理由的一方,而不是票多的一方,也不存在执行“與共識相關相反的結果”的问题。--Antigng留言) 2022年4月30日 (六) 01:07 (UTC)[回复]
  • 我沒有說要數票數,但至少執行在討論中完全沒有人提出過的所謂「共識」明顯不妥-某人 2022年4月30日 (六) 03:56 (UTC)[回复]
  • 请问有具体案例么?如果有的话请列一下。--Antigng留言) 2022年4月30日 (六) 04:57 (UTC)[回复]
  • 最近兩次[3][4]-某人 2022年4月30日 (六) 07:00 (UTC)[回复]
    @AINH:我這裏參照Antigng“共識不是數票數,而是要比較爭議雙方/多方意見的合理性”的説法,想問一個問題:假設在某頁面的存廢討論中,除了提刪者本人外所有參與者都表達應保留頁面意見,但他們之中沒有任何一個人的意見符合相關方針指引,這種頁面能不能以刪除結案?節刪 2022年5月9日 (一) 10:52 (UTC)[回复]
    有具體案例嗎?假設有十幾個人都表達應保留,然後理由全部都是「我喜歡這個主題」那當然應該刪除。但除了傀儡投票之外我還真好像從來沒看過有活躍於AFD的正常用戶這樣投票過--某人 2022年5月9日 (一) 20:11 (UTC)[回复]
    如果“均不符合方针指引”不显著,我建议管理员自行投票,必要时存废复核或转交行政员,而非按自己设想执行,以免自身判断有误;并且有违反避嫌的嫌疑,自身是共识的50%兼执行者。某些条目有潜力出现均同意删除,但删除不符合方针指引。--YFdyh000留言) 2022年5月11日 (三) 00:58 (UTC)[回复]
我的看法是管理員不能在社群有共識的情況下拿出新理據結案。否則的話,新理據是否成立根本沒有得到社群認可是否成立,是與不是沒有得到充分的討論下,結果就是重新走DRV,廢時失事。即是是資深用戶也好,有時候都未必了解指引,於是就出現將Wikipedia:存廢覆核請求/存檔/2022年1月#徐哲_(南朝陳)的這樣的問題。但是這樣的問題我認為是否要直接修,以這樣的方式修是有所相榷的。--Ghren🐦🕐 2022年4月30日 (六) 05:47 (UTC)[回复]
  • 我先把「非管理員的」改了,事實性文句修訂-某人 2022年5月6日 (五) 13:55 (UTC)[回复]
首先支持做修订,问题是存在的。但当前草案不理想,“结案管理员的职责”应该是“结案者”的职责。“在页面讨论页记录讨论共识并执行共识”本身已经概述了,重复强调感觉意义有限。方针和关闭规则相同内容也感觉怪怪的。“一面倒”的用词和限定也很怪,争执不休时管理员也不一定有权决定,有时应当“无共识”。简而言之“结案应符合讨论所体现的共识。”,且这个“讨论”共识有时是在客栈等地方的后续、统一讨论。--YFdyh000留言) 2022年5月8日 (日) 22:31 (UTC)[回复]
方針抄指引是現在行文已經有的問題,並不在我現在想處理的範圍以內。我現在也沒有雅興把整段方針剷掉重寫--某人 2022年5月11日 (三) 01:02 (UTC)[回复]
@YFdyh000:所以你覺得當前草案字眼應該怎樣改?-某人 2022年5月18日 (三) 23:08 (UTC)[回复]
暂时没有兴趣写,因为这虽然应当是共识,但实践中可能不乏违反。--YFdyh000留言) 2022年5月19日 (四) 05:40 (UTC)[回复]

建議重啟管理員布告板[编辑]

個人在處理站務時,常常遇到自己或他人需要聯繫或通告管理員之情況,但有時私下聯繫並不得體,且有礙於往後存檔之查詢,而全然仰賴互助客棧其他區亦非良策。去年社群曾有討論,惟無下文。考慮到長期需求確實是存在的,現請求重啟管理員布告板主頁面,用於討論與協調管理員相關事務,惟不包含編輯爭議其他使用者之不當行為在內。副知參與上次討論之@GhrenghrenKriz JuLuciferianThomas桐生ここ無聊龍。—— Eric Liu 創造は生命(留言留名學生會 2022年4月30日 (六) 02:55 (UTC)[回复]

只要它不要辦得好像一個用戶行為終審法庭一樣的地方其實就應該沒有問題。提醒積壓之類,互相交流的理論上應該不會有問題,但是假如日後又成為用戶互相舉報之場所,只怕管理員不會有心思去管這些玩意。單純作為管理員之間交流,請求管理員協助的頁面就好。--Ghren🐦🕐 2022年4月30日 (六) 05:19 (UTC)[回复]
比方說像是合併條目的請求,或是與本站管理員相關的通告等,我認為都是可以上布告板的,符合該頁面宗旨的。至於使用者之間互相舉報,畢竟多半適用於上述例外子布告板的範圍,分流便是。—— Eric Liu 創造は生命(留言留名學生會 2022年4月30日 (六) 11:38 (UTC)[回复]
合併條目不是已經有WP:合併條目了,這種情況可能將合併條目放寬點改成合併編輯歷史也可以比較好。--Ghren🐦🕐 2022年5月1日 (日) 05:54 (UTC)[回复]
合併歷史是移動請求而非合併請求,另外有{{Histmerge}},但未有相關程序也不廣為人知。--Xiplus#Talk 2022年5月1日 (日) 05:58 (UTC)[回复]
emmm...確實。相關的情序比較含糊而不清晰,也難怪大家都走去管理員的討論頁問。--Ghren🐦🕑 2022年5月1日 (日) 06:31 (UTC)[回复]
规定长讨论应尽快{{moveto}}到适当页面会有用吗,比如讨论达3天或3人,且移动无需避嫌。条目讨论页可能是冷却争执的好地方?而客栈可能有更多关注度。--YFdyh000留言) 2022年5月1日 (日) 06:38 (UTC)[回复]
支持,WP:ANO偏向“举报”,需要一个“讨论”的板块,也可用来寻求管理员帮助,请求合并页面历史/移动flow页等等。看了客栈其它版近半年存档,这些也适用:关于Unblock-zh邮件列表的一些事、WP:AR积压、条目名含间隔号_需管理员代劳、请求xxx管理员解释其近期言行的详细原因 --及时雨 留言 2022年5月2日 (一) 22:01 (UTC)[回复]
請求xxx管理員解釋其近期言行還應該是移到VPO討論比較好,合併頁面歷史和移動Flow也看來是移動請求做的。--Ghren🐦🕛 2022年5月7日 (六) 16:16 (UTC)[回复]
對於這種話題,管理員布告板亦可作為集中分流之處。總好過四散在各種布告板、討論頁、互助客棧而難以收拾吧。—— Eric Liu 創造は生命(留言留名學生會 2022年5月7日 (六) 17:03 (UTC)[回复]
我總覺得社群是戒不掉將向某指定的管理員作出請求的毛病。假如確實有四散在各種佈告板的問題,這說明可能相近的佈告板可能太多了。雖說這次我不反對,但是我還是不看好新手能搞請什麼要找管理員,什麼不用找管理員。--Ghren🐦🕐 2022年5月8日 (日) 05:11 (UTC)[回复]
若在看完請求管理員幫助頁面之後還是不知道什麼時候要找管理員,那大概還是真的去找管理員比較好。—— Eric Liu 創造は生命(留言留名學生會 2022年5月9日 (一) 12:01 (UTC)[回复]

公示建議七日。—— Eric Liu 創造は生命(留言留名學生會 2022年5月7日 (六) 17:09 (UTC)[回复]

通過。—— Eric Liu 創造は生命(留言留名學生會 2022年5月14日 (六) 17:20 (UTC)[回复]

修訂草稿指引准备草稿段落[编辑]

关于Wikipedia:COVID-19條目共識[编辑]

Wikipedia:COVID-19條目共識本身为信息页,但页面中却说自身“具有和指引等同的效力”,那这样为什么不直接把它列为指引,比如纳入格式手册?以前方针是方针,指引是指引,信息页是信息页,清清楚楚。结果现在信息页说有指引的效力,是不是以后要出现什么指引也说有方针的效力?确实不是什么大事,但我觉得注重细节很重要,因此我不觉得这样搞成一团乱有什么好处。--Tranve () 2022年5月3日 (二) 03:38 (UTC)[回复]

應該是可以考慮列為指引。不過此頁面之原初性質應該是記錄共識,說是資訊頁亦不爲過吧。—— Eric Liu 創造は生命(留言留名學生會 2022年5月3日 (二) 07:59 (UTC)[回复]
方针和指引也是记录共识的啊……--Tranve () 2022年5月3日 (二) 08:27 (UTC)[回复]
@Tranve:我覺得可以參考WP:BLUE的情況,那個頁面雖為資訊頁但具備規則的效力。節刪 2022年5月3日 (二) 15:45 (UTC)[回复]
个人认为信息页形式的规则与方针和指引还是有区别的,而且COVID-19这个页面按照其内容似乎很适合放入格式手册。--Tranve () 2022年5月3日 (二) 15:51 (UTC)[回复]
“规则的力量并不源于一个页面被标记上了“指引”或“方针”,而是反映共同的观点和众多编者的看法与做法”。(Wikipedia:何谓忽略所有规则),而且考虑到以后疫情结束后这些信息就会成为存档,似乎标识并不重要?——Sakamotosan路过围观 | 避免做作,免敬 2022年5月3日 (二) 09:17 (UTC)[回复]
难道疫情结束了就不需要写疫情的条目了?这不太对吧。--Tranve () 2022年5月3日 (二) 11:50 (UTC)[回复]
指引也有方针的效力:MOS:CS4DMOS:COR。 ——魔琴 [ 留言 贡献 ] 2022年5月4日 (三) 15:57 (UTC)[回复]
參考WP:資料頁,使用{{Guideline section top}}及{{Guideline section}}標記即可。--CaryCheng留言) 2022年5月10日 (二) 17:33 (UTC)[回复]
@TranveEricliu1912Sanmosacwek魔琴:請問各位是否同意

Wikipedia:COVID-19條目共識頁面頂端加上{{Guideline section top}},
Wikipedia:COVID-19條目共識#避免全保护章節加上{{Guideline section}}。

若7日後沒有反對意見,我就進行修改。--CaryCheng留言) 2022年5月13日 (五) 04:05 (UTC)[回复]
@CaryCheng:我有反建議:直接移除Wikipedia:COVID-19條目共識中“此共識有相等於指引的約束力”的字眼,畢竟包括管理員在内的大家都知道那個是社群共識,我覺得不加那句話也沒關係。Sanmosa Νεκρα 2022年5月16日 (一) 13:33 (UTC)[回复]
不知所云。Ghren🐦🕘 2022年5月16日 (一) 13:43 (UTC)[回复]

U:Sanmosa的建議,修改Wikipedia:COVID-19條目共識如下:

現行條文

避免全保护 如在相關條目發生編輯戰,可行情況下管理員應以封禁過濾器處理,避免全保護處理。此共識有相等於指引的約束力。[註 1]

提議條文

避免全保护 如在相關條目發生編輯戰,可行情況下管理員應以封禁過濾器處理,避免全保護處理。[註 2]

註釋

  1. ^ 此共識的相關討論見此
  2. ^ 此共識的相關討論見此
過去討論

並通知@SCP-2000:。--CaryCheng留言) 2022年5月17日 (二) 02:14 (UTC)[回复]

不反對,共識與方針指引本身不牴觸的話本身就具有相等效力。--西 2022年5月17日 (二) 02:26 (UTC)[回复]
由於我認為相關註釋仍然可以保留,故對草案做出了一點微調。—— Eric Liu 創造は生命(留言留名學生會 2022年5月17日 (二) 02:35 (UTC)[回复]

限制flow-hide权限到自动确认用户[编辑]

通过。 Stang 2022年5月18日 (三) 19:35 (UTC)[回复]
下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

Flow(结构式讨论)的默认设定是任何用户都可以隐藏话题和帖子。鉴于之前有一些LTA滥用该功能来搞破坏,但Flow的功能不完善导致这些破坏难以拦截和清理,因此提议收回相关权限即flow-hide权限给自动确认用户。

注:这是一个先斩后奏的提案,在LTA搞破坏的时候已经紧急执行了,但不能一直这样下去,需要看看社群的意见是否允许这个权限设定常态化。--砜中嘌呤的白磷萃取 打谱 2022年5月5日 (四) 03:27 (UTC)[回复]

至少在 (1) 過濾器可以阻止flow-hide操作 及 (2) 管理員可以刪除/隱藏相關破壞 前應繼續限制flow-hide權限為自動確認使用者。--Xiplus#Talk 2022年5月5日 (四) 05:00 (UTC)[回复]
同Xiplus君。--SCP-0000留言) 2022年5月5日 (四) 10:06 (UTC)[回复]
(+)支持。另外我個人覺得整個結構式討論都應該廢掉 :P —— Eric Liu 創造は生命(留言留名學生會 2022年5月5日 (四) 12:05 (UTC)[回复]
@WhitePhosphorus:我覺得直接把這臨時安排變成常規安排沒大問題,因為非自動確認用戶沒有需要flow-hide權限的顯著需求。節刪 2022年5月5日 (四) 12:20 (UTC)[回复]
猫老师说得对。 Stang 2022年5月5日 (四) 15:10 (UTC)[回复]
貓老師是誰(不鼓勵行話 —— Eric Liu 創造は生命(留言留名學生會 2022年5月5日 (四) 15:29 (UTC)[回复]
同Xiplus。--YFdyh000留言) 2022年5月5日 (四) 15:31 (UTC)[回复]
公示7日。这个东西应该也不需要改什么现有的页面,就单纯删几行注释。 Stang 2022年5月11日 (三) 16:24 (UTC)[回复]

本討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

研擬快速刪除孤立消歧義頁面[编辑]

這提案先不用放著在這討論吧,我現在似乎沒能分出太多時間在這,反正當初我就沒預期這提案能過。這背後的問題我預期最終只能投票處理。Sanmosa Νεκρα 2022年5月17日 (二) 14:34 (UTC)[回复]
下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

快速刪除紅色連結消歧義頁面的提案被常年反對我就忍了,現在竟然連涉台用语 (消歧义)這樣的無歧義項+無歧義項連結消歧義頁面都有了,會不會太離譜了些?先把基本步走好非常重要,所以這裏也就來提個案:

現行條文

(无)

提議條文
G18. 孤立的消歧義頁面。
  • 包括以下幾種類型:
    1. 並無列出任何歧義項的消歧義頁面。
      • 如頁面名稱並不帶有「(消歧義)」字樣,則不適用。
    2. 所有列出的歧義項均不包含任何維基百科內部連結(無論是否可連結到任何已有維基百科頁面)的消歧義頁面。
  • 此項不論頁面是否引用消歧義模板消歧義訊息模板均適用。

以上。符合上述兩種情況的頁面應該很明顯不符合消歧義頁面的定義了。節刪 2022年5月5日 (四) 12:44 (UTC)[回复]

上面所提到的那個頁面只是標題有「消歧義」而已,按內容來看根本就不是正規的消歧義頁面。我認為這是孤例,不需要為此制定快速刪除準則,走一般頁面存廢討論程序即可。—— Eric Liu 創造は生命(留言留名學生會 2022年5月5日 (四) 12:59 (UTC)[回复]
(-)反对,第一類:同上意見,而且即使打着消歧義名稱但內容不是消歧義,描述的內容是否肯定不能移到其他命名?答案顯然是否定的,應在AFD讓人個別評估,不能一概而論。第二類:這些也是應該放在AFD讓人評估是否有被修正為有連結的可能,沒有任何連結就斷定一定沒有修正的可能而去速刪,根本過於武斷。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年5月5日 (四) 13:10 (UTC)[回复]
(1)@Ericliu1912:我不認為這種情況真的是“孤例”(或許是以“孤立”表達擬議G18的意思的方式不夠好),下面提及到的“綠營 (臺灣)”已經算臨界。@Cdip150:一個正常人不可能在無「(消歧義)」字樣的頁面名稱無頁面的情況下建立帶有「(消歧義)」字樣的頁面名稱的頁面,因此你這個問題本來就有問題。(2)不接受這個理由。按這個邏輯,快速刪除方針可以完全廢止,因為所有頁面都有「被修正的可能」。我希望你能提出除此以外的其他理由。節刪 2022年5月5日 (四) 14:39 (UTC)[回复]
或許我詳細解釋一下為何Cdip150的問題本來就有問題。在一個正常人不可能在無「(消歧義)」字樣的頁面名稱無頁面的情況下建立帶有「(消歧義)」字樣的頁面名稱的頁面的前提下,那該頁面的內容一般來説會是對該主題的一般性內容介紹,因此如果一個人在帶有「(消歧義)」字樣的頁面名稱下建立並無列出任何歧義項的消歧義頁面,頁面的內容只可能併回主條目(並不留重新導向)。至於一個人在並不帶有「(消歧義)」字樣的頁面名稱下建立並無列出任何歧義項的消歧義頁面的情況,那那個人就相等於正常建立條目,因此我特地將這種情形排除出G18外。節刪 2022年5月5日 (四) 14:56 (UTC)[回复]
這種情況下衹考慮「正常人」會或不會做某些事情本來就有問題了——這是明顯的因人設事啊。況且,新手們作出一些不正常的編輯我想都是等閒事,他們建立一些完全沒有連結的頁面(不論名稱有否「(消歧義)」字樣)也是見慣不怪的事情。就打個比方:如果有位新手創建「區議會 (消歧義)」(請假設這是個不存在頁面),然後僅寫上「一些國家或地區的區域性議會組織,例如香港特別行政區劃分成十八區的議會。」完全不帶任何連結的兩句話,如果有理沒理就此拿去速刪而不經討論(因為符合上述G18的第2項),我會覺得非常非常的武斷。而說到「快速刪除方針可以完全廢止」完全又是偷換概念,上述被修正的可能性並不像其他的速刪那般微不足道,根本不能直接類比。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年5月5日 (四) 16:11 (UTC)[回复]
我認為你就是在誇大偶發性事件的發生頻率。恕我真的看不出來你搬「應該放在AFD讓人評估是否有被修正的可能」(以及「被修正的可能性並不像其他的速刪那般微不足道」、「不可(直接)類比」)來當理由還有甚麼合理的用意,這些「理由」我已經聽得太多次了,難道你就不感到煩厭嗎。節刪 2022年5月6日 (五) 00:43 (UTC)[回复]
快速刪除本身就不是單看出現頻率來決定是否適合,衹是說某些事情不頻繁出現所以就不考慮,不見得這種用意又有何合理。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年5月8日 (日) 06:05 (UTC)[回复]
@Cdip150:我覺得你實際上做出來的東西往往與你說你正在做的東西是有差別的(雖然這未必是故意為之的)。你這裏說的話是“快速刪除本身就不是單看出現頻率來決定是否適合”,但你實際上表現出來的潛在意見是“快速刪除條文不能將出現頻率作為決定設立與否的因素”。你必須論證在擬議G18的情境下就算偶發性事件的發生頻率處於極低水平到底還能合理地產生甚麽危害(而且你還要論證最後產生的結果確實是無可爭議的“危害”),我才能相信你的真實想法真的是“快速刪除本身就不是單看出現頻率來決定是否適合”。節刪 2022年5月9日 (一) 08:28 (UTC)[回复]
很明顯您並未正解本人的意思——我是在說“快速刪除本身就不是單看出現頻率來決定是否適合”而不是“快速刪除本身就不是看出現頻率來決定是否適合”,請不要吃掉我中間的「單」,所以我的理據並不構成“快速刪除條文不能將出現頻率作為決定設立與否的因素”這個意思,換句話說,除了頻率之外,您還要舉出其他合理理據來配合,不然單說頻率多少是不足夠的(簡單說您就是把「不足夠」錯誤理解成「不能夠」)。況且,G18會有甚麼問題,我想下面有人舉出的AFD反例已說明了一切。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年5月16日 (一) 02:50 (UTC)[回复]
不,我的意思就是説你説出來的意思是「單」,但你內心實際想的意思沒有「單」。你知不知道你跟他在同類話題的出現頻率已經高到讓我開始懷疑你跟他有關聯?下面那個例子不叫“改善”,那叫“改寫”或者“重寫”(在條目評選以外的場合有必要區分兩者),請你跟他不要把這兩種概念混淆。Sanmosa Νεκρα 2022年5月16日 (一) 13:21 (UTC)[回复]
Wikipedia:文明#其他不文明行為:「援引他人留言並斷章取義,以令他人誤以為發言者抱持某觀點而其實際並無持有,或達到中傷之效」,我的意思確實是有「單」,您硬要斷章人家的意思我不知道還有甚麼好討論。下例我認為其內容是基於舊版本進行格式修正:舊版本明顯是在解釋歧義,衹是不依格式罷了,之後的看成是依WP:格式手冊/消歧義頁進行修正其實也不為過,符合Wikipedia:删除方针#可能不需要通过删除解决的常见问题:需要改進的條目——依格式手冊清理頁面,所以還是「改善」。(用戶之間的關聯與否屬離題,我衹會答您一次:您不說我也不知道,此後一概不予討論;請勿透過肆意的懷疑來企圖行中傷之實)--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年5月17日 (二) 03:10 (UTC)[回复]
我認為,只要消歧義頁面具備任何有意義的非破壞性內容,無論其格式如何,都不應該走快速刪除程序。顯然此快速刪除準則不能滿足前述要求。—— Eric Liu 創造は生命(留言留名學生會 2022年5月5日 (四) 15:21 (UTC)[回复]
不接受這個理由。按這個邏輯,快速刪除方針只留著G3款就可以了,但這明顯不合理。節刪 2022年5月6日 (五) 00:44 (UTC)[回复]
正是因為已經有條目了,不合格式消歧義頁面的內容才不見得多數時候都不必經過討論而快速刪除,而是應該逐個討論如何整併,或至少應該給社群看過一遍。請銘記快速刪除的保守本質。—— Eric Liu 創造は生命(留言留名學生會 2022年5月7日 (六) 17:07 (UTC)[回复]
這樣說翻譯粗劣就應該提刪然後給看看哪一個好心用戶要不要打撈囉。如是者大可刪掉很多速刪規則。依我看來速刪是以目前這個狀態:某页面必定無用,因此刪除,而不是让用戶打撈以使其變成不可速刪的狀態,这不是很好的理由。如是者O4、G13大可以不要。但是假如真的需要時間打撈的話,可以以G14的方法給14天的時間給用戶去做。--Ghren🐦🕐 2022年5月8日 (日) 05:24 (UTC)[回复]
@Ericliu1912:上面這個意見真不是我說的,但我也想聽一下你的回應。節刪 2022年5月9日 (一) 08:32 (UTC)[回复]
(!)意見:若消歧義頁已表明「某事可指A或B」,則不屬「無列出任何歧義項」,不能僅因沒有採用點列格式而斷言「無歧義項」。此種例子有涉台用语 (消歧义)已刪除的「綠營 (臺灣)」的歷史版本。當然在下認同該兩頁面應當刪除,但是理由不是「無歧義項」或沒有列出歧義項,似乎也沒有必要為此訂立速刪準則。——留言) 2022年5月5日 (四) 14:08 (UTC)[回复]
@HTinC23:我認為“列出”並不意味“點列”,就像zhwiki的列表條目也不是必須使用點列一樣(甚至zhwiki的FL大多數都對點列避之唯恐不及)。你不妨再看一下涉台用语 (消歧义)説的話:「涉台用語……包括中華人民共和國涉台宣傳用語及其他國家地區的涉台用語」,這句話的意思大概與「蘋果包括紅色的蘋果與紅色以外的顏色的蘋果」一樣,都是毫無意義的,用中國大陸的網絡用語來説就是「廢話文學」,因此我覺得這種情形屬於「無歧義項」。節刪 2022年5月5日 (四) 14:46 (UTC)[回复]
(:)回應:有道理,但是對於有列出(看似)歧義項的(看似)消歧義頁,要判斷其所列各項是否確實屬歧義項(同名不同義),抑或如閣下所舉蘋果的例子是同名同義(但屬同一主題下的分題),可能比較微妙,有經存廢討論的必要。速刪衹應處理最明顯的情況。——留言) 2022年5月5日 (四) 14:57 (UTC)[回复]
證明消歧義頁面有列出歧義項的責任在於建立者本身,如果一個普通人無法在消歧義頁面中直觀地看出歧義項,那判定為並無列出任何歧義項是沒問題的。另一方面,擬議的G18也包含「所有列出的歧義項均不包含任何維基百科內部連結」一條,因此就算該消歧義頁面可能有列出歧義項,也不用擔心刪除理由不當的問題。節刪 2022年5月6日 (五) 00:53 (UTC)[回复]
速刪消歧義就像是每個月都看的大戲一樣,沒有意義,也不可能通過。--Ghren🐦🕚 2022年5月5日 (四) 15:12 (UTC)[回复]
容我毫不客氣地說一句:我感覺那些常年反對就是為反對而反對而已,那些常年反對意見基本上就是一個template,但根本沒管理員能正視問題。節刪 2022年5月6日 (五) 00:56 (UTC)[回复]
同Eric Liu。--YFdyh000留言) 2022年5月5日 (四) 15:33 (UTC)[回复]
问一下“涉台用语 (消歧义)”这样的例子是否常见,如不常见,感觉无必要设为速删。--东风留言) 2022年5月17日 (二) 10:30 (UTC)[回复]
我就只見過這一個。—— Eric Liu 創造は生命(留言留名學生會 2022年5月17日 (二) 11:01 (UTC)[回复]

本討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

虚构格式手册的改善[编辑]

上一次讨论,部分人认为还存在一些问题需要修改,故此提议对以下内容进行修改。

現行條文

对于虚构的元素,如果读者了解该元素在作品中的作用,创作的细节和其它相关的现实世界的信息会更有帮助。这往往涉及到提供简洁的情节摘要、人物描述或直接引语。按照惯例,这些梗概应该用现在时态(在这里被称为叙述性的现在时)来写,因为这是一个真实的人体验故事的方式。在故事的任何一个特定点,都有一个“过去”和一个“未来”,但某件事情是“过去”还是“未来”会随着故事的发展而改变。将整个描述作为连续的“现在”来叙述是最简单和常规的。

提議條文

对于虚构的元素,如果读者了解该元素在作品中的作用,创作的细节和其它相关的现实世界的信息会更有帮助。这往往涉及到提供简洁的情节摘要、人物描述或直接引语。这些梗概应该以现实中的“现在”来编写,而不是以作品中的“现在”、“过去”、“未来”进行编写,因为这是一个真实的人体验故事的方式。在故事的任何一个特定点,都有一个“过去”和一个“未来”,但某件事情是“过去”还是“未来”会随着故事的发展而改变。将整个描述作为连续的“现在”来叙述是最简单和常规的。

現行條文

某部作品本身由于其结构可能需要引入虚构世界外现实世界的视角。包含非线性叙事元素的作品,例如闪回(《公民凯恩》)或开门见山(《普通嫌疑犯》叙述方式,或其他叙事技巧如打破第四面墙(《春天不是读书天》)或引入自嘲式幽默(《巨蟒与圣杯》),可能需要使用虚构世界外的语言将其剧情描述给读者或观众。例如,《公民凯恩》的摘要应确定视频的大部分内容是一个延长的倒叙,并以视频中的现在场景为结尾;整个情节摘要仍应以叙述性的现在时来写。如果可以改善并浓缩剧情,那么从现实世界的角度写的剧情简介无需遵循虚构作品的时间顺序。如果一部作品有两个同时发生的、相互变化的故事情节,那么最好先完整地总结一个故事情节,然后再总结第二个故事情节。如果叙事手段是作品的一个重要特征,如电影《记忆碎片》,则应向读者解释这一结构。

提議條文

某部作品本身由于其结构可能需要引入虚构世界外现实世界的视角。包含非线性叙事元素的作品,例如闪回(《公民凯恩》)或开门见山(《普通嫌疑犯》叙述方式,或其他叙事技巧如打破第四面墙(《春天不是读书天》)或引入自嘲式幽默(《巨蟒与圣杯》),可能需要使用虚构世界外的语言将其剧情描述给读者或观众。例如,《公民凯恩》的摘要应确定视频的大部分内容是一个延长的倒叙,并以视频中的现在场景为结尾;整个情节摘要仍应以现实中的“现在”来写。如果可以改善并浓缩剧情,那么从现实世界的角度写的剧情简介无需遵循虚构作品的时间顺序。如果一部作品有两个同时发生的、相互变化的故事情节,那么最好先完整地总结一个故事情节,然后再总结第二个故事情节。如果叙事手段是作品的一个重要特征,如电影《记忆碎片》,则应向读者解释这一结构。

--Taeas留言) 2022年5月5日 (四) 12:45 (UTC)[回复]

@Ericliu1912@Nostalgiacn--Taeas留言) 2022年5月5日 (四) 12:48 (UTC)[回复]
直接删掉即可,“应该用现在时态”是专指英文中应该用的时态,例如写剧情应该用“plays”,而不是“playing”或“played”;中文写剧情时不会遇到这种问题,删去即可。--BlackShadowG Pray for Ukraine 2022年5月5日 (四) 14:57 (UTC)[回复]
已经下方提出新版,可以看看还有什么问题。--Taeas留言) 2022年5月5日 (四) 15:07 (UTC)[回复]

第二版[编辑]

現行條文

对于虚构的元素,如果读者了解该元素在作品中的作用,创作的细节和其它相关的现实世界的信息会更有帮助。这往往涉及到提供简洁的情节摘要、人物描述或直接引语。按照惯例,这些梗概应该用现在时态(在这里被称为叙述性的现在时)来写,因为这是一个真实的人体验故事的方式。在故事的任何一个特定点,都有一个“过去”和一个“未来”,但某件事情是“过去”还是“未来”会随着故事的发展而改变。将整个描述作为连续的“现在”来叙述是最简单和常规的。

提議條文

对于虚构的元素,如果读者了解该元素在作品中的作用,创作的细节和其它相关的现实世界的信息会更有帮助。这往往涉及到提供简洁的情节摘要、人物描述或直接引语。在故事的任何一个特定点,都有一个“过去”和一个“未来”,但某件事情是“过去”还是“未来”会随着故事的发展而改变。将整个描述作为连续的“现在”来叙述是最简单和常规的。

現行條文

某部作品本身由于其结构可能需要引入虚构世界外现实世界的视角。包含非线性叙事元素的作品,例如闪回(《公民凯恩》)或开门见山(《普通嫌疑犯》叙述方式,或其他叙事技巧如打破第四面墙(《春天不是读书天》)或引入自嘲式幽默(《巨蟒与圣杯》),可能需要使用虚构世界外的语言将其剧情描述给读者或观众。例如,《公民凯恩》的摘要应确定视频的大部分内容是一个延长的倒叙,并以视频中的现在场景为结尾;整个情节摘要仍应以叙述性的现在时来写。如果可以改善并浓缩剧情,那么从现实世界的角度写的剧情简介无需遵循虚构作品的时间顺序。如果一部作品有两个同时发生的、相互变化的故事情节,那么最好先完整地总结一个故事情节,然后再总结第二个故事情节。如果叙事手段是作品的一个重要特征,如电影《记忆碎片》,则应向读者解释这一结构。

提議條文

某部作品本身由于其结构可能需要引入虚构世界外现实世界的视角。包含非线性叙事元素的作品,例如闪回(《公民凯恩》)或开门见山(《普通嫌疑犯》叙述方式,或其他叙事技巧如打破第四面墙(《春天不是读书天》)或引入自嘲式幽默(《巨蟒与圣杯》),可能需要使用虚构世界外的语言将其剧情描述给读者或观众。例如,《公民凯恩》的摘要应确定视频的大部分内容是一个延长的倒叙,并以视频中的现在场景为结尾。如果可以改善并浓缩剧情,那么从现实世界的角度写的剧情简介无需遵循虚构作品的时间顺序。如果一部作品有两个同时发生的、相互变化的故事情节,那么最好先完整地总结一个故事情节,然后再总结第二个故事情节。如果叙事手段是作品的一个重要特征,如电影《记忆碎片》,则应向读者解释这一结构。

感谢@NostalgiacnBlackShadowG的建议 --Taeas留言) 2022年5月5日 (四) 15:04 (UTC)[回复]

要不您自行提案撤销指引状态让我们好好改改,否则现在是指引状态稍微改善点语句都要在这里大动干戈,很没效率。--MilkyDefer 2022年5月5日 (四) 15:15 (UTC)[回复]
趁这次提案统一进行修改,我想这会是更好的方式。--Taeas留言) 2022年5月5日 (四) 15:19 (UTC)[回复]
即使非要如此,顯然至少也應該在修正期間暫停施行。—— Eric Liu 創造は生命(留言留名學生會 2022年5月5日 (四) 15:24 (UTC)[回复]
暂时施行我认为完全没有问题,但是如果改善比暂停施行先通过,那我认为就没必要暂停施行。--Taeas留言) 2022年5月5日 (四) 15:26 (UTC)[回复]

直接修改[编辑]

鉴于目前已暂时被撤销指引状态,建议各位编辑直接修改指引有问题的地方。如果对指引的行文有疑问,建议在此进行讨论。待修缮完成后,将会进行公示恢复指引状态。--Taeas留言) 2022年5月6日 (五) 01:52 (UTC)[回复]

既然不是正式指引,就直接改了。冒昧一問,雖然大部分內容都不是你翻譯的,底稿是Where was I last night?翻譯的,但是你讀一次就能發現很多翻譯有問題吧,提呈為指引也太心急了。你母語是不是中文?--Nostalgiacn留言) 2022年5月6日 (五) 03:42 (UTC)[回复]
母语确实是中文,但是由于平时写代码的原因,经常接触到欧化的语法,所以一些内容读起来没有感觉到障碍。--Taeas留言) 2022年5月6日 (五) 03:57 (UTC)[回复]
另外 BlackShadowG 有在重新翻译了,User:BlackShadowG/格式手册虚构,之前的原文有问题建议在这里讨论。--Taeas留言) 2022年5月6日 (五) 03:59 (UTC)[回复]
当然 Where was I last night? 也只是其中一部分。英维有很多中维的没有的内容,已有内容确实参照了前人的翻译做了略微调整或者没调整。--Taeas留言) 2022年5月6日 (五) 04:04 (UTC)[回复]
现行版本的“单个作品的剧情简介”、“分析和解释”的内容几乎全部进行了二次翻译并校对,其它小部分内容也进行了二次翻译,但我记不清了。除了内容外,“语境介绍”及其子标题也进行了二次翻译。以上的“二次翻译”是指本人在第一次翻译后进行的第二次翻译。--Taeas留言) 2022年5月6日 (五) 04:10 (UTC)[回复]
大部分内容经过社群的校对,但由于篇幅比较长,难免会有遗漏的地方。--Taeas留言) 2022年5月6日 (五) 04:13 (UTC)[回复]
之前确实是心急了,很抱歉给大家带来这么多麻烦。--Taeas留言) 2022年5月6日 (五) 04:11 (UTC)[回复]

BlackShadowG重译版本[编辑]

我将英文版的指引重新翻译并进行了一定的本地化处理,鉴于英文版指引本身就很晦涩难懂,所以我在翻译时没有完全参照英文版的内容,并结合本地的情况删去了一些本地不存在的问题。由于重译版本与现存版本有一定的差别,我将其放在了用户页User:BlackShadowG/格式手册虚构,供各位参考。——BlackShadowG Pray for Ukraine 2022年5月6日 (五) 08:31 (UTC)[回复]

辛苦了!--Taeas留言) 2022年5月6日 (五) 08:37 (UTC)[回复]
重译版本已完成数日,且已在电子游戏专题进一步讨论和完善专题讨论,如无新意见,准备开始公示?@Ericliu1912CwekMilkyDeferNostalgiacnTaeasLopullinen:--BlackShadowG Pray for Ukraine 2022年5月12日 (四) 07:17 (UTC)[回复]
老实说,我在想一个涉及了双线叙事的例子,等我想到了加进去之后,我没有进一步的意见。--MilkyDefer 2022年5月12日 (四) 07:20 (UTC)[回复]
(+)支持但如果MilkyDefer进度还算快的情况下,可以等MilkyDefer先完成。--Taeas留言) 2022年5月12日 (四) 07:30 (UTC)[回复]
我实在想不到好例子,放弃了,你们继续吧。--MilkyDefer 2022年5月13日 (五) 05:10 (UTC)[回复]
待阅。——Sakamotosan路过围观 | 避免做作,免敬 2022年5月12日 (四) 07:31 (UTC)[回复]
章節「单个作品的剧情简介」提到的「对其剧情的大致描述可以不提供参考来源」和WP:VG#参考来源的要求「剧情章节也应引用来源」有一些衝突。DYKN經常有這類爭議(如12),就是劇情部分要不要給出來源。希望在DYKN上有討論過劇情是否要有參考資料的相關人士可以發表一下看法:@Hijk910DjhutyNewbambooAT:--Nostalgiacn留言) 2022年5月13日 (五) 07:17 (UTC)[回复]
如果是dykc和gac,我会让过;如果是fac,我不会让过,至少要将一手来源也好标出来。条文也写清楚了,不强求,但为严防原创研究,多多益善。本身以有来源为最高目标,适当许可implicit来源的情况发生。我觉得是最适合的了。--MilkyDefer 2022年5月13日 (五) 08:49 (UTC)[回复]
来源是必须要有。把参考资料全部堆到条目底部也是有来源的。参考作品本身时,在条目底部把作品名字再写一遍也没意思,所以就什么也不写了。
关键还是这个“引用”(约等于脚注)。WP:WIAGA的要求是必要时加脚注,比如涉及直接引语、统计数字、争议内容时。而WP:WIAFA的要求是适用时加脚注。VG方针我的理解是,故事部分和其他内容一样,也是适用内文引用的。
当然实际惯例是另一回事。比如现在条目真按WIAGA要求,只在必要的地方引用,那评选肯定是过不了。维基的剧情概要又不用像粉丝一样考据,写出来的断言相对没有争议。端看条目评选怎么执行了。—洛普利寧 2022年5月13日 (五) 10:41 (UTC)[回复]
我认为剧情没有必要强求来源,毕竟一般剧情的来源就是作品本身。如果一定要引用来源,参考作品本身时,只用{{cite video game}}一类的模板把游戏信息抄一遍也算是引用,然而这是没有什么意义的。除非是剧情十分复杂,或者有易被忽略的重要情节等情况,才可能有必要详细指出这个剧情是来自小说第几卷第几页、动画第几集第几分钟、游戏哪个场景哪个对话之类的,有必要时还可以用“|quote=”提供具体的引文。但所有一般的剧情都需要详细引用显然意义不大,编者也吃不消。--BlackShadowG Pray for Ukraine 2022年5月13日 (五) 11:14 (UTC)[回复]
首先虛構條目,包括作品條目(小說、電視劇、電影、漫畫、遊戲等),虛構事物(角色、組織、武器、世界觀等),前者在引用自身可能認為「没有什么意义」,但是後者未必。特別是「系列作品」篇幅極長,設定繁雜,如中土大陸,對虛構事物的描述資料可能來好自好幾個篇章、衍生作品、跨媒體等。關於作品劇情「争议内容」,其實會對劇情描述提出爭議的,也就是看過作品的讀者或者作品粉絲。粉絲之間的交流要來源,不認識作品的路人與粉絲之間反而不需要來源,個人認為不太合適。
此外,沒有要求詳細到哪一個頁,那句話的程度,畢竟劇情編寫要求簡要,因應部分敘事方式要重構劇情,一句話可能就是代表故事裡面很長的內容,甚至要通篇去看。通常下應該是哪一冊、哪一集、哪一篇章、哪一關卡的程度。--Nostalgiacn留言) 2022年5月13日 (五) 13:21 (UTC)[回复]

我说,可以开始公示了吧?普遍共识是认为剧情内容通常implicitly有一手资料来源,特别的断言要特别的来源。这吊在这里我根本不好处理隔壁極速快感:全民公敵的那堆垃圾。 --MilkyDefer 2022年5月19日 (四) 12:59 (UTC)[回复]

让我们开始吧--Taeas留言) 2022年5月19日 (四) 13:13 (UTC)[回复]

🕗 公示7日,2022年5月26日 (四) 13:24 (UTC) 結束:進入公示期----Taeas留言) 2022年5月19日 (四) 13:24 (UTC)[回复]

現行條文

一般而言,作品自身就是剧情简介的主要来源。因此,作品条目的剧情简介不强求引用来源(脚注)。但为防范原创研究,内文引用多多益善。但倘使涉及作品的直接引文,就必须依WP:可供查证之规定加入内文引用。编者可以引用总结作品的第二手来源。如果未找到合适的二手来源,也可以简短引用作品内容,方便查证关键或复杂的情节点。

提議條文

一般而言,作品自身就是剧情简介的主要来源。因此,作品条目的剧情简介不强求引用来源(脚注)。但为防范原创研究,内文引用多多益善。但倘使涉及作品的直接引文,就必须依WP:可供查证之规定加入内文引用。虚构事物类条目的虚构设定资料可能来自作品的多个部分,亦有可能来自于读者很少注意的部分,应尽可能引用来源便于查证;系列作品条目的剧情简介若整合自系列中的多个作品,也应引用来源。编者可以引用总结作品的第二手来源。如果未找到合适的二手来源,也可以简短引用作品内容,方便查证关键或复杂的情节点。

赞同Nostalgiacn的观点,因此我建议在公示前对剧情来源相关规定进行一些修改,加入虚构事物和系列作品类条目应尽可能引用来源。——BlackShadowG Pray for Ukraine 2022年5月19日 (四) 13:47 (UTC)[回复]

(+)支持可以包含在公示范围内--Taeas留言) 2022年5月19日 (四) 14:17 (UTC)[回复]

關於WP:RFR/PWP:RFR/R的排版問題[编辑]

最近我觀察到這兩個RFR的排版有些混亂,導致申請人例子、管理員與非管理員的意見混雜在一起,界限非常模糊,所以我想效仿SPI分爲疑似傀儡區、其他用戶的意見區、調查助理、監管員、巡檢管理員的意見區,將RFR分爲申請人區、其他用戶意見區、管理員意見區,以改善RFR的排版問題:

解决方案
現行條文

User:Example

狀態:   新申請
申請者/獲提名者:Example讨论页 · 贡献 · 已删贡献 · 編輯報告 · 所創條目 · 日志 · 注册日期 · 封鎖日誌 · 授予權限|资格检查:巡查權 · 回退權 · 自动确认用户
XXX--簽名時間
提議條文

User:Example

狀態:   新申請
申請者/獲提名者:Example讨论页 · 贡献 · 已删贡献 · 編輯報告 · 所創條目 · 日志 · 注册日期 · 封鎖日誌 · 授予權限|资格检查:巡查權 · 回退權 · 自动确认用户
理由+巡退例子--簽名時間

其他用戶的意見 其他用戶對於申請人的意見。 管理員的意見 管理員對於申請人的意見。

--紹💓煦11000+ · 意見箱 2022年5月9日 (一) 16:05 (UTC)[回复]

別,沒有必要搞得像傀儡調查那麼複雜orz —— Eric Liu 創造は生命(留言留名學生會 2022年5月9日 (一) 16:26 (UTC)[回复]
@Ericliu1912:我只是爲了調整排版,加以區分而已。--紹💓煦11000+ · 意見箱 2022年5月9日 (一) 16:41 (UTC)[回复]
副知@AT。—— Eric Liu 創造は生命(留言留名學生會 2022年5月9日 (一) 16:26 (UTC)[回复]
沒有必要。申請權限的理應能過就是能過,不能過就是不能過,沒有什麼討論可言。--Ghren🐦🕛 2022年5月10日 (二) 04:46 (UTC)[回复]
管理員跟申請者的問答,本來就在放在一起,不可能分開。--Xiplus#Talk 2022年5月10日 (二) 13:16 (UTC)[回复]
(+)傾向支持個人感覺原先版面實在太亂飛馬🎠🎈留言) 2022年5月18日 (三) 14:44 (UTC)[回复]

提议引入en:WP:CSD#G5以快速删除被封禁用户滥用傀儡创建的低质条目[编辑]

G5. Creations by banned or blocked users

This applies to pages created by banned or blocked users in violation of their ban or block, and that have no substantial edits by others. G5 should not be applied to transcluded templates or to categories that may be useful or suitable for merging.

To qualify, the edit or page must have been made while the user was actually banned or blocked. A page created before the ban or block was imposed or after it was lifted will not qualify under this criterion. For topic-banned editors, the page must be a violation of the user's specific ban, and does not include contributions legitimately about some other topic. When a blocked or banned person uses an alternate account (sockpuppet) to avoid a restriction, any pages created via the sock account after the earliest block or ban of any of that person's accounts qualify for G5 (if not substantially edited by others); this is the most common case for applying G5.

G5. 由受编辑禁制或封禁的用户创建

由受限于编辑禁制或封禁的用户绕过禁制或封禁创建的页面,且该页面的主要贡献者仅此用户一人。但不适用于可能有价值或适合被合并的嵌入模板或分类。[請求校對翻譯]

此标准仅适用于创建者在被禁制或封禁期间创建的条目,在其生效之前或移除之后创建的页面则不适用。 对于受限于主题禁制的用户,此标准仅适用于该特定主题的页面,不适用于其它主题的正常贡献。 当受禁制或封禁的用户使用替代账号(傀儡)绕过限制,所有创建于此人任意账号最早封禁生效之后的页面都适用于G5标准(除非期间有其它用户密切参与此页面的编辑)。

这将有助于快速清理有偿编辑者或者出于特定不当意图的被封禁者滥用傀儡大量创建低质量条目。例如,有偿编辑者LTA:123A创建的条目,大都内容质量不佳(只适合重写)、来源低劣、关注度极低(往往不是“百科全书网络的一部分”,根本不会有内链,但也未必满足WP:雪球)。按照标准大多都最终会被删除。但如果按照现有流程,有时需进行关注度提报再等候一月或无价值的提删流程。关注度流程的首要目的是让条目的主要贡献者或其它编者有足够时间改进条目,但是此种情况下实无必要。社群没有必要为这种条目投入任何多余精力。--虹易留言) 2022年5月11日 (三) 02:36 (UTC)[回复]

可以套用G3来处理吧?——Sakamotosan路过围观 | 避免做作,免敬 2022年5月11日 (三) 02:59 (UTC)[回复]
(+)支持没有这条则封禁/禁制缺少震慑力,被封后不申诉只是换个帐号重来的大有人在;en:WP:BMB可供参考。“滥用傀儡大量创建低质量条目”的例子还有LTA:Adam Asrul,直接全部删除最好。第一段末句可以翻译成:G5不适用于已被嵌入的模板,以及可能有价值或适合被合并的分类。--Lt2818留言) 2022年5月11日 (三) 03:17 (UTC)[回复]
回顾近几年本地在封禁事务上的种种不合适处置,如在傀儡方面蟲蟲飛案嘉傑案Comezgirl案的颠倒黑白,以及时有冒出的对轻罪重判的投诉,此时引入英维G5可能尚不合适。G5能在傀儡被发现后,将其建立的页面格杀勿论,或将加剧冤假错案造成的伤害。--Lt2818留言) 2022年5月20日 (五) 11:32 (UTC)[回复]
可以强调“低质量”,或是限定在页面创建x天内有效(如14天或30天)。本身被有效编辑过就不适用G5。以及可以存废复核(视同重建)。--YFdyh000留言) 2022年5月20日 (五) 11:44 (UTC)[回复]
“低质量”较为主观,标准难以划定。限定在页面创建x天内有效挺不错。--Lt2818留言) 2022年5月20日 (五) 12:02 (UTC)[回复]
(+)傾向支持,但注意本地已經佔用G5代號。@Cwek:確實很多情況下G3可以用來套用,但很多時候G3有頗大的灰色地帶,例如LTA建立的非破壞性又非錯誤資訊(G3:純粹破壞,包括但不限於明顯的惡作劇、錯誤資訊、人身攻擊等),但又無保留可能的條目使用G3又好像有點擦邊。例子如LTA:RF創建的新聞性條目(非破壞且真實資訊)、LTA:AALTA:123A的劣質條目,這些都不是純粹破壞,但又無任何保留價值,用en:G5刪除我覺得還算合理。--西 2022年5月11日 (三) 03:48 (UTC)[回复]
直接搬材料这种完全属于G3。甚至封完之后开Nuke就完事了。如果能被修葺的就不适宜SD。——Sakamotosan路过围观 | 避免做作,免敬 2022年5月11日 (三) 06:05 (UTC)[回复]
G3的主语是“纯属破坏”,“包括但不限于”。主要问题是管理员的speed快还是无聊人的干活速度快。(甚至更遥远时期直接使用标题黑名单限制全部非自动确认用户来临时阻止创建条目。)——Sakamotosan路过围观 | 避免做作,免敬 2022年5月11日 (三) 06:07 (UTC)[回复]
@Cwek:您的意思是指“包括但不限於”這一則嗎?--紹💓煦11000+ · 意見箱 2022年5月11日 (三) 21:21 (UTC)[回复]
還有啊,直接搬材料的直接構成G3了?--紹💓煦11000+ · 意見箱 2022年5月11日 (三) 21:23 (UTC)[回复]
如果要对应的话,侵权、没来源的原创研究(本来应该考虑提删的),加上多次出现(只要有管理员之前处理过类似的,作为案例),都可以直接处理吧。——Sakamotosan路过围观 | 避免做作,免敬 2022年5月12日 (四) 00:14 (UTC)[回复]
@Cwek:其實這一條也不完全是針對LTA吧。如果是說繞過WP:PAID等禁制而建立頁面,頁面未達G11標準(明顯的廣告),也明顯不是破壞或錯誤資訊(不適合套用G3),但又很可能被提刪(不符合關注度或包含軟廣告),則適用這一條。「沒來源的原創研究」也未至於G3。--西 2022年5月12日 (四) 03:01 (UTC)[回复]
期望明确:1.提报或删除时是否要提供清晰理由(G5/LTA创建/某某LTA创建)。2.“substantially edited”(“密切参与”)的程度认知,比如:30%内容被改写/重写(可能是:3句中的一句,3个章节中的1个章节,或者按新增字数等),增加关注度来源,至少其他2人做出内容上的编辑,是否算而不应该G5。substantially可能是大篇幅,也可能是“本质上有”?--YFdyh000留言) 2022年5月11日 (三) 06:59 (UTC)[回复]
1.应该要指明是哪个用户(英维提交格式为{{Db-g5|name of banned user}})。2.en:WP:G7亦有substantial字眼,在本站跟WP:G10同一标准即可。--Lt2818留言) 2022年5月11日 (三) 07:27 (UTC)[回复]
包括用户子页面/草稿页吗?--东风留言) 2022年5月11日 (三) 23:50 (UTC)[回复]
G而非A,自然是包含的。如果不含,创建很多草稿也挺麻烦,走存废还得举证向外界解释、提升LTA曝光度。--YFdyh000留言) 2022年5月12日 (四) 03:14 (UTC)[回复]
标题为“低质条目”,英文原文为“Creations”,我才这么一问。--东风留言) 2022年5月12日 (四) 04:15 (UTC)[回复]
註:此處原有文字,因為LTA擾亂惡意曲解方針,已由Ghren🐦🕙 2022年5月17日 (二) 02:23 (UTC)於{{{time}}}刪除,尚祈見諒。若有異議請至互助客棧或向管理員反映。[回复]

註:此處原有文字,因為LTA擾亂惡意曲解方針,已由西於2022年5月13日 (五) 13:55 (UTC)刪除,尚祈見諒。若有異議請至互助客棧或向管理員反映。[回复]

現行條文
提議條文

G6. 在被封禁禁制期间,只由被封禁用户或其傀儡创建和编辑的页面。

包括以下几种类型:

  1. 符合删除方针规定之任意一条删除原因的页面;
  2. 明显没有关注度,或关注度极低的条目;
  3. 低质量条目(包括但不限于没有维基化原创研究、大量引用不可靠来源)。

--12З4567留言) 2022年5月12日 (四) 14:50 (UTC)[回复]

行文怪怪的。建议:“仅由被封禁的用户或其傀儡绕过封禁而创建的低质量页面。”、“违反编辑禁制视作绕过封禁”。以及建议“善意用户对页面内容进行过实质性补充时不适用[1]”。--YFdyh000留言) 2022年5月12日 (四) 15:27 (UTC)[回复]

参考資料

  1. ^ 含可推定善意的IP用户、一般用户,不含调整分类或格式、语句润色,含补充可靠来源、新增原本未有可靠信息。
@12З4567:這些感覺都沒有必要,走存廢不好嗎?--紹💓煦11000+ · 意見箱 2022年5月12日 (四) 21:54 (UTC)[回复]
(~)補充:第一則,我認爲快速刪除方針(CSD)旨在加快刪除明顯不合規頁面或文件,若不明顯合規應當走存廢流程就好了,存廢討論本來就是要求上述頁面在有限的時間内積纍一定討論,讓諸位用戶發表意見以達成共識。第二則和第三則同理。--紹💓煦11000+ · 意見箱 2022年5月12日 (四) 23:12 (UTC)[回复]
(-)反对,這與早前才被廢除的WP:CSD#G6實務上有何分別?逐點再看——第一則:刪除方針的理由除第1點外本身都不是可速刪的理由,若僅以一個用戶是否被封禁就能被延伸至CSD,有訴諸人身之嫌,速刪應衹針對內容而不應針對身份。第二和三則:這恐怕會重蹈已被廢除的WP:CSD#A4的覆轍,不久前才說過,明顯沒有關注度等這類速刪理由在以往的經驗裏經常容易引發爭議,才導致有關速刪標準被廢止;而且應該會與WP:NOTCSD所指的「原創研究」和「不合關注度的頁面」不可作為速刪理由發生矛盾。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年5月16日 (一) 04:03 (UTC)[回复]
我建議限定僅Cross-wiki破壞者適用,畢竟管理員(例如上面那位,但顯然不止上面那位)分辨相關內容是否Cross-wiki spam的能力低下,我真不明白為何普通用戶能極快以極為簡單的方式分辨出Cross-wiki spam,而管理員不能。Sanmosa Νεκρα 2022年5月16日 (一) 13:29 (UTC)[回复]

可靠来源评级指引措辞调整[编辑]

現行條文

以下評級以通常可靠(原第四級)為最高級,即評為通常可靠的來源為最可靠列入黑名单為最低級,評為應停用列入黑名单的來源

提議條文

以下評級以通常可靠(原第四級)為最高級;列入黑名单為最低級,評為應停用列入黑名单的來源

个人认为不应断言“通常可靠”的来源是“最可靠”的。WP:CONTEXTMATTERS也指出指出:“来源的可靠性取决于特定情境”。因此提议在Wikipedia:可靠来源/布告板/评级指引中移除这部分内容。--Steven Sun留言) 2022年5月17日 (二) 14:03 (UTC)[回复]

同意。Sanmosa Νεκρα 2022年5月19日 (四) 05:48 (UTC)[回复]
同意。--YFdyh000留言) 2022年5月19日 (四) 07:29 (UTC)[回复]
這也算維基百科的一種Bug啊,以前就問過這問題了,那措辭顯然...(不講了)。--Z7504非常建議必要時多關注評選留言) 2022年5月19日 (四) 13:36 (UTC)[回复]
鉴于无反对意见及本修改不影响评级标准,🕗 公示7日,2022年5月27日 (五) 14:17 (UTC) 結束。--Steven Sun留言) 2022年5月20日 (五) 14:17 (UTC)[回复]

提议废除Wikipedia:小小作品的50字删除规定[编辑]

个人认为,在目前快速删除中的A1标准调整为内容空泛之后,实际上内容空洞的条目已可以通过A1删除。相比之下,小小作品50字标准设立的初衷是使条目能具有基本的内容。在快速删除A1标准为“内容空泛”的当下,尤其是考虑到部分条目内容可能不满50字,但依然具有基本内容,个人认为小小作品的50字标准已很大程度上弊大于利,可以废除,或者改为柔性规定。希望知道大家的看法。--クオン·千の海を越えて·残夢 2022年5月18日 (三) 16:00 (UTC)[回复]

同意廢除,畢竟就算超過50個字也不一定能做到充分介紹,那以50個字作為紅綫就是不合理的。Sanmosa Νεκρα 2022年5月19日 (四) 05:48 (UTC)[回复]
這已經是本年第三次提出了,這能有共識嗎?--Ghren🐦🕑 2022年5月19日 (四) 06:35 (UTC)[回复]
(-)強烈反对50字門檻已奇低,就一句的頁面不可能稱之為完整「條目」-某人 2022年5月19日 (四) 06:39 (UTC)[回复]
@Kuon.HakuSanmosa Νεκρα 2022年5月20日 (五) 02:16 (UTC)[回复]
虽然明文数字不一定合理,但“柔性”会带来太多问题,目前不看好废除。--YFdyh000留言) 2022年5月19日 (四) 07:29 (UTC)[回复]
至少我巡查的时候,遇到过一些刚好超过50个字(可能也就是多十来个的,或者还有infobox等加分项)的条目,但条目整体长度和质量实在很难认为不是小小(也有可能是我的屏幕太大了,以至于看上去太小小了)。我认为如果单纯不加分的情况,能单纯有100~150字的才算基本具有一定规模的小作品条目。——Sakamotosan路过围观 | 避免做作,免敬 2022年5月19日 (四) 08:34 (UTC)[回复]
字数从来不是关键,不是51个字就不是小小作品了,也不是49个字就一定是小小作品。一句话就是一个条目在传统百科里也很常见--百無一用是書生 () 2022年5月19日 (四) 08:44 (UTC)[回复]
條目在於能否提供一定的信息量,而字數相對來說比較次要。--中文維基百科20021024留言) 2022年5月19日 (四) 12:20 (UTC)[回复]
(-)傾向反對小小作品中的內容通常都不適合編入維基百科。若某一小小條目具有關注度也有可靠來源,且符合方針指引,建議可以將其合併到某一大條目中的章節中,因為小小作品的字數實在太少,無法做出有效的介紹--飛馬🎠🎈留言) 2022年5月19日 (四) 12:10 (UTC)[回复]
我有點懷疑你是否真的瞭解相關的東西,畢竟你是在幾天前才加入維基百科的。Sanmosa Νεκρα 2022年5月20日 (五) 02:17 (UTC)[回复]
我之前是用匿名ip編輯條目,條目編久膩了想參與站務,故建立了帳號,所以我對方針有一定程度的認識飛馬🎠🎈留言) 2022年5月20日 (五) 12:13 (UTC)[回复]
話說最近小小作品相關刪除或保留之案例有什麼趨勢嗎?—— Eric Liu 創造は生命(留言留名學生會 2022年5月19日 (四) 13:31 (UTC)[回复]
越摆越烂。->>Vocal&Guitar->>留言 2022年5月19日 (四) 23:58 (UTC)[回复]

《人事任免投票资格方针(PL507)》条件1的修订[编辑]

現行條文

……

  1. 解任投票聯署提出或上任投票開始120天前,編輯至少500次;聯署提出或上任投票開始前90天內至少有1次編輯(不包括任何用戶頁及用戶對話頁);

……

提議條文

……

  1. 解任或提名提出120天前,編輯至少500次;解任或提名提出90天內至少有1次編輯(不包括任何用戶頁及用戶對話頁);

……

修订理由有下:

  1. 人事任免投票资格方针(PL507)》序言章节所列条件1中作出了“上任投票开始120天前”和”上任投票开始前90天内”的约束,其本质是防止潜在的傀儡制造者,在已经得知某一人事任免投票开始的情况下通过编辑行为取得人事任免投票资格。《申请成为管理人员指引(GD803)》新增第2.6(安全投票暂行规定)章节后,投票起始时间由提名时直接开始,变为完成预提名程序并在技术上安全投票系统的设置后方才开始。此时,现行方针中”上任投票开始前90天内”的约束,不再能起到原有的效果。考虑到联署提出是新任免程序开启的信息最初向社群披露的时间点,故提议统一修订为“提名提出前”;
  2. GD803第2.6(安全投票暂行规定)章节规定,预提名须得到“七位具人事任免投票资格之用户联署支持”。因此,从方针指引的自洽性上而言,PL507应在GD803所规定预提名(联署)阶段即能够评估用户是否具备人事任免投票资格,故提议统一修订为“提名提出前”;
  3. 上述修改兼容潜在的变动,即使联署程序不再使用,方针亦能适用。

亦可统一改为“任免程序开始120天前/90天内”。以上。--Kirk # 2022年5月20日 (五) 12:06 (UTC)[回复]