维基百科讨论:格式手册/列表

这是本页的一个历史版本,由Jimmy-bot留言 | 贡献2020年2月20日 (四) 16:14 (机器人: 1个讨论已存档)编辑。这可能和当前版本存在着巨大的差异。


Jimmy-bot在话题“疾病條目的人物列表”中的最新留言:4年前

WP:人物列表的修訂建議

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

對於2019年10月以僅2票而通過的修訂案,認為其共識認定是相當草率,也是魯莽地繼續增加了本地的編輯限制,並未有足夠適應本地編輯與體驗實際等,應待獲取足夠的不同意見去審慎處理。

對該章節基於編輯審視等,現有如下幾個動議:

  1. 推翻2019年10月以僅2票而通過的該修訂案;
  2. 去除本章節的方針地位。

以上,歡迎各位參與討論。——約克客留言2019年12月21日 (六) 14:10 (UTC)回复


我先反對,不喜歡條目純粹列出人物列表。--Bagakuco留言2019年12月25日 (三) 13:53 (UTC)回复
(!)意見:當時沒公示,其實現在可以公示,重新令它合法化,或者略作修改,然後公示。蟲蟲飛♡♡→♡℃留言 2019年12月25日 (三) 14:45 (UTC)回复
@Wong128hk:我的反對是針對Sunny00217用戶說的,如果三天沒人反對就直接凍結條文。--Bagakuco留言2019年12月26日 (四) 11:39 (UTC)回复
@Bagakuco...則此段條文直接凍結直到有新的共識,重新公示完凍結即失效,當然如果版本改了就以新的直接代替-- Sunny00217 2019年12月26日 (四) 14:30 (UTC)回复

舊修訂案具體處理

進行重新修訂與公示以正式通過

  • 基于社群整体意见,我不再反对完全禁止的大方向,提几点细节修正意见:
    1. 建议指引改为WP:人物嵌入列表之存废标准,“人物列表”会误认为是关于人物独立列表的指引,“收录标准”容易与列表内容的“收录准则”混淆。同时,新名称与独立列表之存废标准保持命名一致。
    2. 可考虑将指引放入Wikipedia:格式手冊/嵌入列表内,之后如能建立“嵌入列表之存废标准”,可再作为子段落合并。
    3. 应该在条文内明确提示这类信息的替代展示之处,即分类或独立列表。很多用户会基于姓氏/家乡自豪感参与编辑,我觉得应合理引导其在适当的位置参与完善人物相关信息,而不是仅仅告诉其不能在嵌入列表这么干。
  • 故提议具体条文为(现行条文指公示条文):
現行條文

对于条目内嵌入列表,其收录标准可较独立列表更为宽松一些,具体情况可自行考量,如遇争议可到Wikipedia:互助客栈/方针寻求共识。以下罗列已达成共识的部分主题:

  1. 姓氏條目禁止嵌入「著名人物」等人物列表。
  2. 行政區劃條目禁止嵌入「本地出身人物」等人物列表。
提議條文

对于条目内人物嵌入列表,其存废标准可较独立列表更为宽松一些,具体情况可自行考量,如遇争议可到Wikipedia:互助客栈/方针寻求共识。以下罗列已达成共识的部分主题:

  1. 姓氏條目禁止嵌入「著名人物」等人物列表,此类信息应由分类:X姓或独立列表体现。
  2. 行政區劃條目禁止嵌入「本地出身人物」等人物列表,此类信息应由分类:XX人或独立列表体现。
由於我們沒一個人知道Longway22所説的“令後續編輯和閱覽等可以理想地進行”是何物和需要給予“寬免和豁免空間”的原因,我打算日内把Kezpe方案給公示。我簽名那刻的時間是 2020年1月8日 (三) 07:50 (UTC)回复
請閣下不要當已具體提出的建議條款提議不存在而急於搞所謂公示,對於閣下繼續獨斷的作風非常遺憾,閣下的陳述是極為不專業與不負責任的,閣下既然打算稍微顯示看到本編已經表明的提議,起碼應該有點更有說服力的有效論述。——約克客留言2020年1月9日 (四) 10:52 (UTC)回复
然而這個討論看起來真的並沒有任何一個人知道您下面那句文謅謅的話有什麼意義,您也並沒有搭理Sanmosa閣下數日前對您的方案提出的疑問,直到要公示了才匆匆上來回應一句(然後仍然不理下面的意見),這是更不負責任的行為。—— Eric Liu 留言留名學生會 2020年1月9日 (四) 11:07 (UTC)回复
不只下面,還有上面,我還是看不懂要這樣提案的具體原因,我只看到一些虛無縹緲的文字在我的電腦屏幕上出現。我簽名那刻的時間是 2020年1月9日 (四) 11:48 (UTC)回复
我只是“打算”公示而不是正式進行公示已經是對Longway22非常忍讓,如果Longway22繼續不解釋提案的具體原因(我只是要Longway22以中文維基百科内的條目舉例説明而已),我就真的很快就走正式進行公示的程序了。能不能不要來虛的?我簽名那刻的時間是 2020年1月9日 (四) 11:51 (UTC)回复
  • 「一般不應展示過度冗長、內容在知名度與參考價值等不足以展示的人物列表」: 如果不在姓氏/行政區劃條目裏面,目前沒有打算要限制。如果你想收緊歡迎提出。
  • 「建立條目附屬或獨立的、內容在知名度與參考價值等可足夠予以展示的分類簡表與索引」:如果你的意思是分類以外有其他選擇(如獨立列表、列表索引),那的確可以考慮加入。
  • 感謝Temp君的意見。就第一點提到的想說下,建議是說再細點的話,應對於「行政區劃」條目上,考慮採用的措辭是可以引導編輯者在該範疇對人物嵌入列表,做出編輯簡化、兼顧編排佈局等,以更好地提示編輯者注意維持條目的觀感和質素等。想再強調「行政區劃」條目,在本地單一捆綁了行政與地理等多個範疇(簡單分就可以是行政區條目和地理性條目兩塊),就是說僅以單一管理的角度去考慮是遠遠不足的。針對到大中型政治(雜合地域、地理等)條目中牽涉人物有比較繁雜冗長的狀況,就可以應該嚴格的指引處理(著重於限制的一個就是冗長),而級別以下的條目,就可能在知名度與參考價值等方面進行另外評定,其實也可以使用更靈活的編輯思路。這是現在繼續的一點意見,歡迎討論。——約克客留言2020年1月12日 (日) 03:35 (UTC)回复
    • 我不明白「列表」這種形式在應對於「行政區劃」條目上有甚麼獨特的價值。如宁波市#著名人物就以段落形式將名人寫出來。列出一堆人名而不加介紹,對讀者無甚意義。--Temp3600留言2020年1月12日 (日) 14:50 (UTC)回复
      • 我覺得一個可行的方法是:勸喻編者在看到這類型的列表時,可以考慮擴充改寫。功成不必在我 2020年1月13日 (一) 01:36 (UTC)回复
      • 當然可以。--Temp3600留言2020年1月13日 (一) 15:47 (UTC)回复
        • 變思考停止了不希望出現繼續不照顧不同讀者需要的情況,不能理解為何仍以管制做出發點來考慮舊案。即使現階段諸位是明確認為不需要本編建議,適宜還有別的區域加碼一大堆通過,還建議未來應依照WP:常識等處理個案,本編堅持認為即使該規制最後落實,若無法有效制約,將有比本編已提出幾點外更多的衍生問題,希望各訪問用戶依照WP:常識WP:FAITH等理解本編陳述。——約克客留言2020年1月17日 (五) 12:37 (UTC)回复

所以可以再進行公示沒有?功成不必在我 2020年1月16日 (四) 15:39 (UTC)回复
User:Sanmosa您就公示吧,這樣約克客才會跑回來阻擋,然後討論就能推進了。—— Eric Liu 留言留名學生會 2020年1月16日 (四) 17:16 (UTC)回复
啊,那依所請公示七日吧。話說他這樣做好像算是遊戲規則的?功成不必在我 2020年1月16日 (四) 23:42 (UTC)回复

進行正式廢除

正式繼續提出,永久凍結與廢止WP:人物列表2019年10月修訂案並進行公示:

理解不足的更改編輯可以造成一些過度冗長雜亂等的狀況,但於閱者角度而言在地域條目看得到人物表是極為有價值的,當然很多只是一刀切減免麻煩的官僚化人士,是連具體的差異化考慮都不需要的,因為維基官僚們需要的只是一個禁制令,維基官僚喜歡還可以加長再加長,這樣就不再需要修正維護維基了,只要一勞永逸地鏟去自由、多樣與複合的空間,都就不需要在意維基未來。
本編在此刻所動議廢止的,就是這個連一點點的專業建議也被無視的荒謬修正案,因為連最初時參與者明顯過低下,也可以違背基本禮儀、規程和慣常等毫無約制地成為維基廣大用戶所看見的「政策指引」,其實本來就不可能是一個真的需要立即坐上位的選擇吧?真的如果是一個站出檯面的所謂共識代表人,不如回應下:所謂達成禁制主題的共識,如果存在形成的整個記錄話,可以完整地體現於這個急於補回遮羞布的修正案嗎?在整個預訂執行的條文中,這個也應是非常有交代必要,不然也根本對訪問維基的用戶對共識的真確理解是不負責任呢。——約克客留言2020年1月9日 (四) 13:48 (UTC)回复
User:Sanmosa(由於樓上的回應實在太冗長官僚多餘了,在此幫忙簡單濃縮一下,實際上他想表明的意見大概只有「該案的通過,明顯只會開極惡劣的禁制令先例」、「不可能說一個簡單又不加詳盡說明的籠統措辭放出來,就可以硬生生地加一道枷鎖上去」、「於閱者角度而言在地域條目看得到人物表是極為有價值」、「最初時參與者明顯過低下」、「不可能是一個真的需要立即坐上位的選擇」、「達成禁制主題的共識,如果存在形成的整個記錄話,可以完整地體現於這個急於補回遮羞布的修正案嗎」這幾段,其他的基本都是在吐苦水、繞口令和企圖拉高對話層次,可以不用看。然後他還是沒拿出具體例子。)—— Eric Liu 留言留名學生會 2020年1月10日 (五) 01:02 (UTC)回复
後面三段意見都可以透過在這裡討論以達成新的共識來解決,不成問題。—— Eric Liu 留言留名學生會 2020年1月10日 (五) 01:06 (UTC)回复
  • 「在地域條目看得到人物表是極為有價值的」是典型應該用分類取代的例子。勿忘X國人列表。--Temp3600留言2020年1月10日 (五) 07:41 (UTC)回复
    感謝Ericliu1912和Temp3600成功摘錄了一些Longway22在這裏說的比較有意義的文字出來。關於「最初時參與者明顯過低下」,那我們不正是再重新討論,找更多人來嗎?「於閱者角度而言在地域條目看得到人物表是極為有價值」,我恐怕和Temp3600有些同感。算了,我收貨了,Longway22你喜歡的話就不用再論述了,我相信這兩句就是你的中心論點,rephrase對這裏的討論毫無幫助。我沒那麽快公示。我簽名那刻的時間是 2020年1月10日 (五) 08:58 (UTC)回复
  • 小結:
  1. 本編之前陳述希望社群各自具體理解,前面有關的選擇性摘錄未必合乎WP:CIVIL等而會影響各位觀察,各位若有空餘,可以再仔細閱讀,包括:
  2. 本編於上區以假定續案坐正有所需求,而提出了補述平衡修訂初步建議,並有加色。遺憾未見有效交換意見,各位有意討論可以繼續移步上區補充意見。另外:
  3. 本區域中仍未見有回應本編後續提出,舊案應具有的原初共識形成記錄,現仍等待提供。——約克客留言2020年1月10日 (五) 10:24 (UTC)回复
  • 就不對回覆的語句通順問題挑骨頭了,您提案到互助客棧不就是為了形成新的共識嗎,一直糾纏在原本提案的共識基礎問題有什麼用?倒不如說就是因為所謂「舊案」不具有原初共識形成紀錄,我們才在這裡討論的不是嗎?目前整個討論只有您一位執意廢除條文內容,不像Kezpe、Temp3600閣下等人對條文提出具體的修改方案,亦不對Temp3600、Sanmosa閣下等人的質疑提出有效的回應,不斷以文謅謅的抽象語句長篇大論、雄辯滔滔,加上之前Sanmosa閣下在預備公示時急忙趕來「回擊」的行為,您這樣反倒像是在阻止共識形成了。—— Eric Liu 留言留名學生會 2020年1月11日 (六) 14:20 (UTC)回复
  • 感謝Eric君的回覆,本編在此也就再提出舊案中很大風險問題的另一點:「以下羅列已達成共識的部分主題」,這個引言是有對「共識」的誤導,還有連鎖後患的問題。為什麼會這樣說呢?
基於WP:CON的條文和本地實際等,可以知道WP:CON在不同位置有很多差異,不同的WP:CON不免因新的討論交換持續而發生變化,若再採用「」字,本身就是在編輯指引中對時間敘述上要避免使用的描述,這會反映了整體的代表性是無法涵蓋動態變化的。
本地「共識」內涵的穩定性在多方面是不確定的,而訪問和參與維基的許多朋友未必是長期深入本地架構,對於「共識」在本地的真確樣貌未必掌握足夠。不說引用自其他維基的成熟框架,本地後續中不斷改變的時候,像條文說明中所用的「共識」,不會是非常明顯地具實解釋建立時段節點、參與人、形成記錄等等。同一指引下不同的章節「共識」達成,就會有不同的時空、緣由過程等的差別,而像新手一進入新生版塊時未有留意,大膽開工而又熟悉不足,連鎖觸發的就可以是不可預見的問題。
本案大討論動議,原初就是本編發現而提出的,在後面分區的重新通過區中有更多修訂討論進行時,在此也再小列各位需要嚴謹考慮的:
  1. 對於WP:CON闡述的「共識」,不同條文說明中的具體註明,和:
  2. 不同情況大幅修改、追加、刪除等情況的有對條目編輯等有極大影響的條文或同類地位條目的具體註明,和:
  3. 對前二項各自在用於實踐的適當的校驗、評估、追溯等。
目前再有以上一些意見,希望有助繼續形成「共識」。——約克客留言2020年1月12日 (日) 04:50 (UTC)回复
非常遺憾有關做法限制本編的遊說,有違WP:假定善意WP:CON「誤區和錯誤」章節。——約克客留言2020年1月17日 (五) 12:13 (UTC)回复
我真誠地相信Longway22你上面的文句是在説你自己。請注意:這裏不是粵語維基百科,不是像那邊一樣任你行的空間。另外,你再不回應上面的話,上面的方案就會通過的了,還有你最好看看為何Ericliu1912叫我再公示相關條文。功成不必在我 2020年1月17日 (五) 14:00 (UTC)回复

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

疾病條目的人物列表

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

不好意思叨擾大家。上次討論WP:人物列表未能及時參與,請問是否方便新增條文:

現行條文

对于条目内人物嵌入列表,其存废标准可较独立列表更为宽松一些,具体情况可自行考量,如遇争议可到Wikipedia:互助客栈/方针寻求共识。以下罗列已达成共识的部分主题:

  1. 姓氏條目禁止嵌入「著名人物」等人物列表,此类信息应由分类:X姓或独立列表体现。
  2. 行政區劃條目禁止嵌入「本地出身人物」等人物列表,此类信息应由分类:XX人或独立列表体现。
提議條文

对于条目内人物嵌入列表,其存废标准可较独立列表更为宽松一些,具体情况可自行考量,如遇争议可到Wikipedia:互助客栈/方针寻求共识。以下罗列已达成共识的部分主题:

  1. 姓氏條目禁止嵌入「著名人物」等人物列表,此类信息应由分类:X姓或独立列表体现。
  2. 行政區劃條目禁止嵌入「本地出身人物」等人物列表,此类信息应由分类:XX人或独立列表体现。
  3. 疾病條目禁止嵌入「知名患者」等人物列表,此类信息应由分类:X疾病患者或独立列表体现。

  說明:生老病死是生物常態,這種人物列表恐怕沒有意義,尤其許多疾病發生率甚高,真要列表可以列非常長,比如白血病,然而查看英文維基日文維基皆未見如此列表。BagakucoKevin Smith Chen請大家不吝提供意見,謝謝。--Hjh474留言2020年1月30日 (四) 16:34 (UTC)回复

疾病相關的「著名人物」不一定是患者。我覺得如果是說發現該疾病的醫生、專門研究該疾病的人、歷史上非常著名的該疾病患者其實是可以列的,如果列出太多的話,那時候就要清理ꓢꓯꓠꓟꓳꓢꓮ 2020年1月31日 (五) 03:06 (UTC)回复
感謝回應。疾病診斷與治療的研究貢獻者會收錄在歷史章節,不會在人物列表章節,這倒不必擔心。--Hjh474留言2020年1月31日 (五) 06:28 (UTC)回复
這樣的情況下,我沒太大的意見,看看其他人的反應如何。ꓢꓯꓠꓟꓳꓢꓮ 2020年1月31日 (五) 06:33 (UTC)回复
可以直接将条文表述为“禁止嵌入‘知名患者’等人物列表”,以避免误解为医生、研究者等。至于“非常著名”的患者,我觉得也没必要单列。同理于姓氏条目的讨论,如果该人士的患病对该疾病的发现、研究、治疗历史有重大影响,大可以在正文章节中体现。否则,没理由因为知名度更高就单独列出,何况“非常著名”也没有共识的标准,容易引发争议。--Kezpe留言 2020年2月2日 (日) 15:59 (UTC)回复
了解了,已修改如上。 謝謝您的寶貴意見。--Hjh474留言2020年2月3日 (一) 17:22 (UTC)回复
Temp3600如上述之白血病。--Hjh474留言2020年1月31日 (五) 16:30 (UTC)回复
我同意這是一個不恰當的列表。不過有其他嗎?--Temp3600留言2020年1月31日 (五) 17:30 (UTC)回复
@Hjh474:抱歉忙於翻譯Kobe,我發現除了閣下提的條目,其他疾病條目並未發現不宜的列表,應該不用為此修訂條文吧。--Kevin Smith Chen🍠2020年2月1日 (六) 02:40 (UTC)回复
之前發現的並沒有逐一記錄下來,剛剛憑印象找了幾個:肝硬化甲狀腺癌肝癌中風肺炎,有的已被清理。若少人關注,直接清理亦可,或待之後若不幸遭遇編輯戰再麻煩大家修條文亦可。當然...最好是能改條文。。。--Hjh474留言2020年2月1日 (六) 06:51 (UTC)回复
(+)支持。如果特定患者确实对此疾病的研究或大众知名度有贡献,例如英国王室之于血友病,那么可以提及。但不能因为一个人有名,又得了这个病,就把他/她写到这个病的条目里。 --ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨᡩ᠋ᠠᠨMandan 2020年2月5日 (三) 01:49 (UTC)回复
Temp3600勿憂,有方針指引就好辦。只是...不知道怎麼公示(羞)。--Hjh474留言2020年2月9日 (日) 14:52 (UTC)回复

本討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。
返回到项目页面“格式手册/列表”。
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy