跳至內容

維基百科:互助客棧/方針/存檔/2015年12月

維基百科,自由的百科全書

有關於DYKC規則中的「原創」如何驗證

關於紅綠連的最終方案

批量議案

此處張貼一些關於現行方針的批量議案。這些議案均不或很少修改方針的實際內容,而是對於方針頁面的結構層次、附屬關係、術語用法加以調整。不過由於數量較多,仍然貼出以求社群認可。每個具體議案的內容、性質和目的將會在以下列表及討論區中詳細呈現。

議案名稱議案內容
第一議案(已執行)合併Wikipedia:半保護方針Wikipedia:保護方針
第二議案(無 果)合併Wikipedia:維基百科不是詞典Wikipedia:維基百科不是什麼
第三議案(已執行)修改保護方針兩處內容:允許用戶請求無限期半保護其用戶頁面,以及聲明全保護不用於高風險頁面以外的預見性保護。
第四議案(已執行)Wikipedia:管理員解任投票頁面中的方針部分剝離,合併到Wikipedia:管理員的離任

希望本次一系列的小修補能讓方針的內容層次更加清晰,並在保持內容的前提下適當精簡方針頁面數量。如果可能,希望每個議案各自達成相應共識,並請大家在討論時避免使用投票模板。

-- Bluedeck 2015年11月3日 (二) 03:08 (UTC)

第一議案討論區

第一議案內容為合併半保護方針和保護方針。理由是前者並沒有獨立的必要,且敘述內容和核心觀點均和後者相同。合併的好處是方針層次將更加整潔,同時保護方針頁面長度仍可以控制在合理範圍。合併後,WP:半保護方針頁面摘下方針模板,其實質內容將反映在WP:保護方針#半保護一節當中。預計本提議實現後,WP:保護方針頁面變成這個樣子:User:Bluedeck/bibliotek/history/1446518872196(本草稿是第一議案和第三議案合併執行結果,所以包含兩處實質性修改)。現將本第一議案張貼於此尋求共識。Bluedeck 2015年11月3日 (二) 03:09 (UTC)

請放心,這只是預覽。如果第一議案通過而第三議案否決,我將不會把「私貨」帶進去,這也是分開討論的好處。至於草稿沒有體現半保護方針的合併,關於這一點,請參看當前的WP:半保護方針頁面,可分為3部分:導言、「如何執行」的手冊以及導航部分(忽視一個「重複一遍」的章節)。其中,只有導言部分包含了實際的方針內容,而導言段落的敘述內容均已在草稿中體現(其大部分已經在現行保護方針中存在)。Bluedeck 2015年11月3日 (二) 12:47 (UTC)
前者並沒有獨立的必要,且敘述內容和核心觀點均和後者相同。合併的好處是方針層次將更加整潔,同時保護方針頁面長度仍可以控制在合理範圍。合併後,WP:半保護方針頁面摘下方針模板,其實質內容將反映在WP:保護方針#半保護一節當中。
誠然,沒人規定方針不能合併,但為了整潔而合併方針頁面,這顯然不是好理由;且本提案有涉及修改方針,非為單純的合併,故當前順序錯了,應先討論修改內容,有共識後再執行合併,現階段投支持或反對票都不宜。--秋意假髮濃(我已關閉了所有通知,所以@我看不到)留言2015年11月4日 (三) 18:18 (UTC)
我來說明。方針的系統性、邏輯性和層次性是非常重要的。自從我加入維基百科以來,雖然日漸熟悉各種方針,然而始終不敢說自己「系統性的」了解了維基的所有方針,這還不算指引。其原因就是我們的方針頁面數量多,層次亂。即使這點小的修改遠不能讓沒有維基經驗的人從零上手毫無難度,然而進步總是好的。而且整理方針層次並不涉及實質內容,所以我覺得「為了整潔而合併方針頁面」是一個值得去做的工作,也是很好的更新理由。由於涉及內容修改的提案,我已單獨列出,故不會造成混亂——正如我上邊所敘述的,如果第一議案通過,而第三議案否決,我將只把第一議案相關的內容更新進新的方針中去。至於結構性修改和內容性修改的討論同時進行一事,我認為並無不當。最後,在共識有望的情況下減少投票模板的使用確實值得提倡。以上。Bluedeck 阿里君♥優酷醬 2015年11月4日 (三) 19:24 (UTC)
維基基本法?--Temp3600留言2015年11月5日 (四) 05:18 (UTC)
那不是WP:5P?說到這個,樓主似乎是想把目前類似歐美法系的地方往大陸法系上靠……各有利弊,我不反對就是了。 --達師 - 318 - 527 2015年11月5日 (四) 08:38 (UTC)
我這在做的事情像大陸法系的風格嗎?我不這麼覺得。剝離手冊內容這種簡化操作應該是正相反的情況。維基百科的方針不可能做到大陸法系的水平,法無禁止即可行,所以我也沒有意願往那上靠。Bluedeck 阿里君♥優酷醬 2015年11月5日 (四) 13:38 (UTC)
  • (+)支持都是保護,合併好看一些 --(叮噹呀,誰都喜歡,小貓也自豪!) 2015年11月6日 (五) 09:40 (UTC)
  • 我認為方針與指引是寫給用戶看的,它並不是法條。我們不能保證任何用戶都能如同閣下精熟你所述的內容,或了解保護與半保護的差別(比方說,我常看到資深用戶以「條目內文不中立」作為刪除理由,明明就沒這條理由),會不會手機滑到一半覺得太長就跳過不看,誰知道?我認為,如果該頁面有必要獨立論述,則應分撰,反之就該合併;若單純僅以頁面長短或簡潔與否作為分拆或合併理據,都是不適宜的,若說現在討論的是百科全書條目,那就另論。--秋意假髮濃(我已關閉了所有通知,所以@我看不到)留言2015年11月6日 (五) 20:49 (UTC)
我感到閣下的一些想法和現實情況差距甚遠。您一定還沒讀過我寫的草稿。內容不變的情況下簡潔化方針,這就是本議案做的事情。長度幾乎不變的情況下精簡掉一個頁面,這就是草稿在呈現的狀況。您擔心「手機滑到一半覺得太長就跳過」,又聲明「以頁面長短或簡潔與否作為分拆或合併理據,都是不適宜的」;您指出「如果該頁面有必要獨立論述,則應分撰」,卻未見獨立敘述的必要性爲何。這是矛盾的邏輯啊。Bluedeck 阿里君♥優酷醬 2015年11月6日 (五) 22:03 (UTC)
暈。這事有這麼複雜?您說您的議案要簡潔方針,我也說了,沒人規定不可以簡潔方針。但是,只單純為了「長度幾乎不變的情況下精簡掉一個頁面」有何必要,您還是沒有回答啊,這和有沒有看過草稿怎又扯在一起?好,為何我會這樣問?我們現在討論的,是維基百科的方針或指引,它不僅僅是一個條目頁面的存廢,可能討論後,認為沒關注度就合併到主條目即可解決;而是在討論要將半保護方針合併到保護方針裏去;還有,您提案的合併,亦有涉及修改內文的部分,也不全是單純地將B重複內文的部分合併到A;最關鍵的問題是,為何一定要簡潔,頁面美觀清爽?看了心情舒暢?如果僅以此理由就要修改方針或指引,個人絕對反對。倘若繼續保持現狀不合併,又將導致誰的不便?或者合併後,網站速度會加快0.0000001秒?若以此類理由要修改社群方針是不必要的。最後,我一直很排斥這種鬥爭式的討論法。不回答問題,反而先指責的思維就沒意思了。請問,今日提案要合併的的是您還是我,怎麼提案要合併的,不指出合併的必要性,反而要我來提出獨立敘述的必要性,這種邏輯您自己不覺得怪?舉例:A說秋意假髮濃殺人,理由是「我覺得他有殺人」,「他看起來像殺人犯集團的一份子」,但A沒有提出任何證據,接着要秋意假髮濃證明自己沒殺人?--秋意假髮濃(我已關閉了所有通知,所以@我看不到)留言2015年11月7日 (六) 20:02 (UTC)
很抱歉,我沒有想到會給您造成爭鬥的印象。我沒有回答問題是因爲您沒有提出任何問題,僅僅敘述了觀點(唯一的一個問句是「誰知道?」);我挑您的邏輯的毛病是因爲在我看來真的是矛盾的。剛剛您增加了一個問題,「為何一定要簡潔」,我的回答是簡潔增強理解和層次性,這對於方針和讀者都是好事。您指出「您提案的合併,亦有涉及修改內文的部分」,我再此第四次説明我沒有這麽做——衹是沙盒合併,不是議案合併。您舉出例子「A說秋意假髮濃殺人……證明自己沒殺人?」,實際正好相反:我是「沒殺人」的主張方,要求對方拿出「殺了人」的證據。因爲同一個方針硬要拆分成兩頁才是需要理由的行為(議題方反轉)。實際上舉證責任在這種議題可反轉的情況下不起作用,請查看舉證責任_(哲學)#批評。以上。Bluedeck 阿里君♥優酷醬 2015年11月8日 (日) 07:19 (UTC)
本例中可留在WP下,也可留在H空間下。我建議其他例子中的手冊內容如果有重名則放在H空間里。Bluedeck 阿里君♥優酷醬 2015年11月7日 (六) 18:29 (UTC)

本議案執行完畢。Bluedeck Paris Attacks 2015年11月18日 (三) 20:03 (UTC)

第二議案討論區

Wikipedia:維基百科不是詞典Wikipedia:維基百科不是什麼是較為明顯的重複敘述,且並不能看出有特別需要強調的理由和效果。提議是合併前者到後者。以上。現將本第二議案張貼於此尋求共識。Bluedeck 2015年11月3日 (二) 03:48 (UTC)

請求合併的動機主要是為了精簡方針頁面的數量、降低導航難度以及理順邏輯關係。方針頁面區別於一般論述,應小心對待。大量沒有經過仔細考慮的方針頁面可能帶來社群層面的隱患。由於當前Wikipedia:維基百科不是詞典的內容遠不足以支持其單列方針,故請合併。一般而言,我認為如果一個方針的某個側面有特殊強調的必要,則應調整其篇幅,或者針對其撰寫論述或方針解釋。將其單列為一單獨方針的做法會造成一定混亂。Bluedeck 2015年11月3日 (二) 12:57 (UTC)
應該不會一直弄到TL的程度。當前凡是有TL的部分不是手冊內容太多就是話說的不系統導致冗長而信息量並不多。在以後的系列議案中,解決這個問題也是一個預想。Bluedeck 2015年11月4日 (三) 04:04 (UTC)

(!)意見同時昭,應擴充維基百科不是詞典。--Temp3600留言2015年11月8日 (日) 12:02 (UTC)

第三議案討論區

兩處方針內容修改:

第一處:允許用戶請求無限期半保護其用戶頁面。理由:實際處理保護請求時有先例,同時本規則可以節約編輯者不必要的時間浪費。
第二處:聲明全保護不用於高風險頁面以外的預見性保護。理由:實際處理保護請求時的默認性規則。在半保護方針中有闡明,但在全保護方針中沒有。現在闡明。

修改後的效果參見第一議案討論區提供的草稿頁面。以上。現將本第三議案張貼於此尋求共識。Bluedeck 2015年11月3日 (二) 03:25 (UTC)

第一處:是的,這裏只是允許用戶申請永久半保護,如果用戶的申請不合情理,管理員自然可以不予執行或者調整期限執行。第二處:例1(全)例2(半)。目前「不做出預見性保護」是管理員處理保護請求的常識性規則,無論半保護全保護均是如此,故加入全保護方針中去。Bluedeck 2015年11月3日 (二) 12:49 (UTC)
根據目前方針「如用戶頁遭破壞,用戶本人有權利申請對用戶頁進行最長一年的半保護。」,我認為已足夠保障編者。--Temp3600留言2015年11月3日 (二) 15:46 (UTC)
user:秋意假髮濃[[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]]您提出的這一點,我是經過仔細考慮的。我來敘述不做預防性保護的原因:因為預防性保護會妨害一些正常的編輯,從而使得維基效率下降。然而,對於用戶頁而言,出於非用戶意願的編輯是不正常的,所以「不預防」的邏輯不適用。在這裏,反而是預防性保護才能夠提高維基系統效率。所以這兩個處修改雖然表面上是向着相反的方向,而實際上目標是相同的。Bluedeck 阿里君♥優酷醬 2015年11月4日 (三) 19:11 (UTC)
不明白為何要永久保護。我認為一年保護已足夠保障編者。--Temp3600留言2015年11月5日 (四) 05:16 (UTC)
user:Temp3600[[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]]以下是某用戶的用戶頁被破壞情況:2012年8月31日,8次破壞。2013年3月11日,人身攻擊。2013年4月7日,擾亂。2013年4月17日,破壞。2013年8月28日,擾亂。2013年8月28日,人身攻擊。2013年11月18日,人身攻擊。2013年11月29日,破壞。2014年1月18日,擾亂。2014年12月13日,擾亂。2015年4月24日,威脅。2015年4月29日,威脅。2015年6月12日,擾亂。2015年7月15日,人身攻擊。2015年9月13日,被張貼版權內容。最後,幾天前的2015年10月21日,被張貼版權內容。本用戶頁其間被多次保護,保護終止後,破壞即開始。最長一年並非足以滿足所有需要。Bluedeck 阿里君♥優酷醬 2015年11月5日 (四) 19:33 (UTC)
  • (+)支持:之前悶聲中立)原來還有這麼誇張的案例,那我冒泡出來支持。-- SzMithrandir(留言2015年11月6日 (五) 00:31 (UTC)
  • @Bluedeck:您以個案作為修改方針的理據仍不充分。如果以您提出的草案做準,也不須用戶提出,管理員應當主動介入才對,因為當前保護頁面權限只賦予管理員(我修正,少數維基人就只單純想掛着管理員三個字「官銜』,根本不碰站務,不過這不能強迫,只能說社群當初是怎麼投票選的)用戶可主動申請永久半保護頁面,但重點來了,一、誰有這個權利同意或反對保護別人的用戶頁面?管理員?行政員?二、為何僅允許用戶頁可以預防性保護,非用戶頁面卻不允許,這個議案完全沒提到,未來如有維基人以此質疑時,社群對此爭議如何回應?因此案一與案三絕對不可包裹討論。小結:本議案「第二處」爭議不大,第一處則不夠具體。--秋意假髮濃(我已關閉了所有通知,所以@我看不到)留言2015年11月6日 (五) 20:31 (UTC)
「請放心,這只是預覽。如果第一議案通過而第三議案否決,我將不會把「私貨」帶進去,這也是分開討論的好處。」--Bluedeck 回復 Cwek 2015年11月3日
「正如我上邊所敘述的,如果第一議案通過,而第三議案否決,我將只把第一議案相關的內容更新進新的方針中去。」--Bluedeck 回復 秋意假髮濃 2015年11月4日
我在此第三次申明:沙盒是沙盒,議案是議案。我從一開始就是把第一議案和第三議案分開提的,從沒有打包過。因此我覺得您是不是沒有順序看完全部留言?您提出的「也不須用戶提出,管理員應當主動介入才對... ... 管理員?行政員?」部分我沒有看懂您的意思,可否重新敘述?您提出的「為何僅允許用戶頁可以預防性保護」問題,我已在2015年11月4日19點11分(UTC)回復,就在上面不遠處,您是否閲讀了?您指出「第一處則不夠具體」,當前第一處的敘述爲「允許用戶請求無限期半保護其用戶頁面」,我認爲已經講得非常明白,那就是把目前的最高一年期限放開,不設上限,您覺得是哪裏不夠具體,我願意回答。Bluedeck 阿里君♥優酷醬 2015年11月6日 (五) 22:08 (UTC)
看到您這段回復,我終於明白,您也是需要說明很清楚的。管理員不是法官,方針或指引不是法條,維基百科沒有法庭。社群投票推選維基人來做管理員,不等於管理員就是裁判員。社群給管理員判斷頁面存廢、封禁用戶、刪除或保護頁面等的權限,但管理員仍然不是法官(七十餘位管理員,幾個有法律相關背景專長的我很好奇),僅僅因為社群把這些權限集中給某些維基人,如此而已。諸位路人若認為管理員是維基百科的法官、官員什麼等,那就錯了,他們只是打雜工,每天做其他維基人不願碰的事(當然也有掛管理員名字不打雜的人,此處不討論),換言之管理員沒有權力准許或否決任何一個用戶的行為,管理員封禁用戶、保護與刪除頁面的行動出發點,都是為了忠實履行社群賦予的權限(各位可以想成「對事不對人」。當然,我這裏還是舉例)。所以,除非與此用戶相關的行為已經影響到了社群,這時管理員才有必要主動介入,因為當前能封禁用戶或保護、刪除頁面的權限,社群只賦予了管理員,但這不等於管理員的權限可以無限擴張。打字到這裏,我想一同和諸位路人一起試想。各位想像一下,維基百科剛初創的時候,有沒有設置管理員,是否任何人都可以自由的創建或者刪除頁面?其實這不光是維基百科會設置管理員,只要有一定規模的線上論壇也都會設置管理員。回題,這個提案是用戶可以申請永久半保護自己的用戶頁,所以我問了:誰、核、准?管理員可以批准某個用戶是否需要半保護,還是行政員?別忘了,保護或半保護頁面的原則都是在發生破壞之後才會實行,何以用戶頁就例外可以允許在未受破壞的情況下就半保護,提案裏面並沒有說啊。請記得,即便是用戶頁,它還是一個頁面。如果我們同意用戶可以申請永久半保護自己的頁面,那麼未來用戶也可以申請半保護其他頁面,因此,我說這不具體。規則不是不能改,而是「怎麼改」。另外,「節約編輯者不必要的時間浪費」的理由和議案一類似,都是「整潔」、「節約」。試問,如果未通過此提案,對所謂的「編輯者」造成多長的不必要時間浪費?我剛看了WP:VIP,也不是整頁都提報用戶頁被破壞,若以這種理由提案修改方針,個人認為都是不必要的。--秋意假髮濃(我已關閉了所有通知,所以@我看不到)留言2015年11月7日 (六) 20:49 (UTC)
這回我明白了。您提出的問題已經遠遠超過了本議案討論的範圍,您應當新開議題討論。本修改衹是修改一個時間上限,和權限怎麽執行這種深層次問題完全無關。爲防止誤會,我需要説明這句回復不是一句敷衍。您的提問已經涉及到哲學層面問題,我無力解答。可以肯定的是,本修改並不觸碰這個問題,以前怎麽做,以後就怎麽做。Bluedeck 阿里君♥優酷醬 2015年11月8日 (日) 07:05 (UTC)
  • (+)支持第一部分,第二部分我覺得現在對預見性編輯的定義有問題,高爭議條目被永久半保護一段時間之後竟然被解開,理由居然是保護已很長一段時間沒有破壞,不能以預見還有破壞維持保護?這不當然的嗎,就是因為保護了才沒有破壞啊。見溥儀--淺藍雪 2015年11月18日 (三) 00:49 (UTC)
    • user:淺藍雪[[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]]雖然是在探討界面用語時明確的,不過不限期並非永久,只是不確定何時解除罷了。Bluedeck Paris Attacks 2015年11月18日 (三) 19:47 (UTC)
      • user:Bluedeck[[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]]嗯,我好像有點看混了,如果第二部分只管全保護我支持。--淺藍雪 2015年11月19日 (四) 19:16 (UTC)
  • 如果沒有更多意見,預計於UTC-6的2015年12月2日(星期三)上午完成該議案的執行。Bluedeck 2015年11月27日 (五) 17:40 (UTC)

第四議案討論區

內容:將Wikipedia:管理員解任投票頁面中的方針部分剝離,合併到Wikipedia:管理員的離任。此番修改後,Wikipedia:管理員解任投票將變為純粹的操作性頁面。目前Wikipedia:管理員的離任頁面較短,可以承受一定規模的擴充而不至於過於冗長。以上。現將本第四議案張貼於此尋求共識。Bluedeck 2015年11月3日 (二) 03:54 (UTC)


本議案執行完畢。Bluedeck Paris Attacks 2015年11月18日 (三) 19:48 (UTC)

Shwangtianyuan的派生議案討論區

註:本段落留言標題、位置和格式曾經Bluedeck編輯:[1]Bluedeck 2015年11月3日 (二) 16:38 (UTC)

本人還有一個議案(第五議案),就是建議將維基百科:回退不過三原則併入維基百科:編輯戰,不知道各位是否可以接受。--Shwangtianyuan正義必勝!和平必勝!人民必勝! 請嚴格遵守中國國旗模板使用規則 2015年11月3日 (二) 04:40 (UTC)
建議將維基百科:回退不過三原則併入維基百科:編輯戰,因為「回退不過三原則」可以看成是「編輯戰」的一部分。--Shwangtianyuan正義必勝!和平必勝!人民必勝! 請嚴格遵守中國國旗模板使用規則 2015年11月3日 (二) 04:42 (UTC)

謝謝SzMithrandir的統計。這個議案我也有考慮,雖然不在日程上。Bluedeck 阿里君♥優酷醬 2015年11月5日 (四) 04:51 (UTC)
  • (-)反對:3RR部分不等於編輯戰。隨便3RR也算破壞(上上方說的有理...)--Engle躍】 2015年11月4日 (三) 10:09 (UTC)

暫定共識

近日社群對此議題的討論開始減少,故作此小結:

第一議案:通過
第二議案:無共識,意見分為同意合併,應擴充Wikipedia is not a dictionary,及降格為指引三種
第三議案:「聲明全保護不用於高風險頁面以外的預見性保護」已無反對意見;「允許用戶請求無限期半保護其用戶頁面」則共識較弱
第四議案:無反對意見,應可通過
Shwangtianyuan的派生議案:否決

希望社群加緊討論,在以上數項議案中達成最終共識。--Temp3600留言2015年11月9日 (一) 17:26 (UTC)

如11月16日前仍未有其他討論,建議通過第一議案、第三議案第一部分、及第四議案。--Temp3600留言2015年11月10日 (二) 16:38 (UTC)
無反對但也無複議,建議第四議案重新掛出。 --達師 - 318 - 527 2015年11月16日 (一) 12:03 (UTC)
@bluedeck:意下如何?--Temp3600留言2015年11月16日 (一) 15:44 (UTC)
就這樣更新好了。這也算冷門議案的標準結局了。繼續擺在這衹會一天天更冷。Bluedeck Paris Attacks 2015年11月16日 (一) 19:59 (UTC)
(+)支持:可以了吧,該說的都說清楚了,就行了。其他人沒參與進來,要麼是覺得太複雜,要麼是覺得肌無力,累感不愛,算了。而且這個爭議性很小了,幾乎可以算是管理員內部的站務,執行吧。-- SzMithrandirEred Luin 2015年11月17日 (二) 01:22 (UTC)
@bluedeck:嗯嗯,bluedeck您去改吧。--Temp3600留言2015年11月17日 (二) 15:20 (UTC)
關於第三部分我還有話說。。--淺藍雪 2015年11月18日 (三) 00:53 (UTC)
看見了,那第三部分就再擱一會兒。Bluedeck Paris Attacks 2015年11月18日 (三) 19:52 (UTC)

小作品的判定條件問題

漢化譯名和直譯譯名的處理

外文重定向問題

現存或已刪除的條目內文可以大量複製到使用者頁面嗎?

wp:刪除守則等7篇文章移動

2015年12月13日最新提案

我將對維基百科:命名常規的內容作出一些小修訂,主要是有關汽車車系的條目要注意的問題。具體內容為(放入「交通工具名稱」一節):

另外,若要創建有關汽車車系的條目時,請加入普遍使用的車廠名稱,以「車廠+車系名稱」為標準格式,例如「本田Civic」、「豐田Corolla」。不要加入合資車廠的名稱,例如「東風日產天籟」、「上海大眾桑塔納」,以避免地域中心

請各位對此提出意見,謝謝!--Shwangtianyuan正義必勝!和平必勝!人民必勝! 請嚴格遵守中國國旗模板使用規則 2015年12月13日 (日) 08:04 (UTC)

(+)支持。不過,可以舉個例嗎?剛剛我找了幾則條目,但是找不到有類似您說的命名情形。--Bowleerin留言2015年12月13日 (日) 08:54 (UTC)
我看不懂這兩類區別……是說後面的改成「東風天籟」還是「日產天籟」、「大眾桑塔納」(「上海桑塔納」不靠譜吧)?Liangent留言 2015年12月13日 (日) 13:41 (UTC)
向二位統一(:)回應一下:有些新用戶(尤其是從百度百科轉來的用戶)在創建有關汽車條目的時候,因為不知道維基百科的命名常規(新人嘛),可能會使用「合資車廠名稱+車系名稱」作為其標題(我之前在百度百科上已經看到了「鄭州日產NV200」這個詞條,在維基百科上絕對不行),這樣的話可能會出現地域中心。--Shwangtianyuan正義必勝!和平必勝!人民必勝! 請嚴格遵守中國國旗模板使用規則 2015年12月14日 (一) 06:17 (UTC)
這是預防性的提案嗎,目前沒有事例?不過不要加入合資車廠的理由,我認為是關注度。僅當「東風日產天籟」存在顯著的關注度(排除「日產天籟」),且「日產天籟」不存在條目或日產天籟條目過長,才可以創建獨立條目。--Gqqnb留言2015年12月14日 (一) 07:41 (UTC)
可以說的上是預防性的提案。--Shwangtianyuan正義必勝!和平必勝!人民必勝! 請嚴格遵守中國國旗模板使用規則 2015年12月14日 (一) 08:19 (UTC)
不覺得有什麼必要。內容短的用關注度提刪,內容長的說「通篇都在講『日產天籟』,不管『東風』什麼事」,可以移動改正成日產天籟。--Gqqnb留言2015年12月14日 (一) 08:26 (UTC)

有沒有興趣允許條目級CSS?

就是允許把一些css添加到特定條目。本來反覆使用內聯CSS(<font style="xxx">...</font>),如果改用統一的條目級CSS,條目大小可以減少,加快瀏覽器加載速度。技術上就是創建一個模板來填寫這些css,然後把javascript加到全局JS文件里去,在條目加載完畢時javascript讀取這些css加到document.styles里。這並不是技術問題,而是方針問題。現在好像沒現成的模板吧?有一些鐵路條目、列表類條目等,使用前景色、背景色、調整文字大小比較頻繁,條目級CSS能減少條目大小。不過我也知道格式手冊要求不要過於花俏,所以問問看大家的想法。--Gqqnb留言2015年12月14日 (一) 08:21 (UTC)

可以用class做,但問題是得有人整理。大小麼反正現在都gzip,差不到哪裏去的。開放用這個不現實,太容易被破壞了。--Jimmy Xu 2015年12月14日 (一) 08:23 (UTC)
mediawiki:common.css--百無一用是書生 () 2015年12月14日 (一) 09:26 (UTC)

論述既然沒有效力,怎麼可以衍生出相應的維護模板?

翻譯條目須在Talk頁標上{{Translated page}}

依據CC BY-SA及早期的GFDL授權方式,翻譯條目必須給出原文作者。{{Translated page}}的存在就是給翻譯作者一個方便,不知為何使用率極低。許多產量豐富的翻譯編者都忽視了要給出來源網址及作者的姓名,我認為中文維基應當落實CC協議的精神,而不是眾所周知是從某語言翻譯過來,就忽略不標了。我們應當在相應的方針裏寫入這條規則。畢竟英文維基的東西還是那邊作者所有的,我們翻譯過來,MediaWiki可沒有幫我們標註翻譯前的作者是誰,需要手動標上才行。--Jasonzhuocn留言2015年12月12日 (六) 07:32 (UTC)

存量有多少?--Antigng留言2015年12月12日 (六) 09:00 (UTC)
先完善相關方針吧,維基百科:翻譯守則,看看還有沒有其他指引順便一塊改。搞定這個以後,再請翻譯大戶把自己翻譯的作品給補上。不過從源頭來說,這應當是MediaWiki的一個插件功能,給作者一個表單填入來自某個語言的某條目,自動在talk頁加上模板。--Jasonzhuocn留言2015年12月12日 (六) 09:08 (UTC)

劉嘉一向都有使用這個模板,不過包括我在內,不加這個模板的翻譯編輯也不在少數。而且這樣做並沒有強制性質,其實如果某條目在參加特色/優良條目評選、新條目推薦候選的時候就已經表明該條目是翻譯條目和原文語種,早晚這個事實也是要在討論頁出現的,雖然這個模板能夠提供原文的連結,而上述的方法不能。自己曾經因為沒有在某翻譯條目的討論頁使用這個模板而在DYKC被某編輯嗆聲,當時就是用這個理由回應(PS. 結果這條目因為被某編輯撻伐,而要強行結束第一次評選而捲土重來,結果到了第二次才能當選)。--春卷柯南夫子 ( ) 2015年12月13日 (日) 08:59 (UTC)

真希望可以讓電腦來完成這件事。除了英文版之外,各大語言版應該都有類似功能需求。--Jasonzhuocn留言2015年12月13日 (日) 12:34 (UTC)
機器怎麼知道一個條目是不是翻譯的呢?--Antigng留言2015年12月13日 (日) 12:38 (UTC)
在機器沒有強人工智能以前。至少可以設個介面,給機器來源語言、條目名稱,可以再加個版本。剩下交給機器做,減少我們user的負擔。這些就當我在許願。--Jasonzhuocn留言2015年12月13日 (日) 12:43 (UTC)
用content translation的,我興許可以做一個bot幫助添加模板。維基百科:機械人/申請/Antigng-bot/12--Antigng留言2015年12月13日 (日) 13:30 (UTC)
開了個小工具對CX翻譯的頁面添加此模板,可以考慮設置為默認啟用。Antigng把先前翻譯的頁面跑一遍也不錯。Liangent留言 2015年12月16日 (三) 22:43 (UTC)

這個模板有version參數,可以指定翻譯頁面的歷史版本,也許在可供查證方面算是優點。--578985s留言2015年12月14日 (一) 07:09 (UTC)

喜歡version參數。我會在編輯摘要里寫翻譯自XX語維基,這樣符合要求嗎?--Gqqnb留言2015年12月14日 (一) 07:35 (UTC)
以前就寫過摘要,維基用GFDL時期還得在摘要列出五位作者。--Jasonzhuocn邀請台灣人加入 Wikimedia Taiwan2015年12月15日 (二) 05:45 (UTC)
近期翻譯的都會上version參數。——路過圍觀的Sakamotosan 2015年12月15日 (二) 09:23 (UTC)

再提跨語言連結清理

目前對於條目中不應有裸的跨語言連結(如[​[:en:Example|例子]])應已有共識,故在此提出將此種方式的連結在此批量替換為{{ilh}}的形式。如此一則顯示效果更加友好,一則能得到才女的機械人在中文維基有相應條目時進行清理,一則在社群對跨語言連結有其他共識時方便實現。

有鑑於目前有維基人出於各種原因不喜歡使用此模板,在此提出一折衷方案,即清理時會暫時跳過在此串中表明此意之維基人所編輯的條目。

在此歡迎各位對此任務提出意見,且請針對清理任務本身,對{{ilh}}的顯示效果如有不滿還請另開段落。以上。--Jimmy Xu 2015年12月14日 (一) 08:12 (UTC)

綠鏈萬歲!--祝維基百科生日快樂的Carrotkit 2015年12月15日 (二) 05:28 (UTC)

不用說了,全部改紅鏈-- Billy talking to HK People貢獻 2015年12月15日 (二) 07:36 (UTC)
甜鹹之爭還有紅綠之爭……--Antigng留言2015年12月15日 (二) 12:18 (UTC)
tooltip表示應戰(其實關掉現在默認的綠鏈腳本不就完事了嗎?)——路過圍觀的Sakamotosan 2015年12月16日 (三) 01:37 (UTC)
綠鏈好,綠鏈妙,綠鏈棒得不行了!--祝維基百科生日快樂的Carrotkit 2015年12月16日 (三) 05:37 (UTC)
tooltip大法好,退綠保平安。This is the war!——路過圍觀的Sakamotosan 2015年12月16日 (三) 06:15 (UTC)
CPU一耗天地滅,趕快退綠保平安。-- Billy talking to HK People貢獻 2015年12月16日 (三) 23:53 (UTC)
綠鏈賽高!不但能給看客進行提示,還能避免維基人的紅鏈強迫症。——萌萌噠CFSO6459留言2015年12月17日 (四) 00:28 (UTC)
+1 。--廣雅 范 2015年12月17日 (四) 12:08 (UTC)
藍連萬歲!消滅綠連英語Green link紅連!(XD - 和平、奮鬥、救地球!(留言)自然條目提升地質滅絕專題2015年12月17日 (四) 14:08 (UTC)

提議合併三大人物信息框模板

—以上未加入日期時間的留言是於2015年12月29日 (二) 00:42 (UTC)之前加入的。

修訂封禁方針,處置繞過封禁者的編輯和創建的條目

目前中文版的封禁方針大抵承襲自英文版,不過看來缺少了一個環節,就是如何處置繞過封禁者所創建的條目和進行的編輯。這事情的原因是最近某萬惡的惡搞破壞者亂寫劣質東南亞條目,真令人氣炸。還有最近另一個惡搞破壞者在互助客棧披露他人個人資料,並與少壯派展開回退戰的事件(我總覺得這兩個人就是中文版有史以來行徑最卑劣的兩個破壞者)。

英文版的規定是這樣的:

被封禁用戶所進行或藉助他人進行的編輯

任何人都可以隨意回退任何違反封禁方針的編輯行為,不作另行通知,也不需要理會回退不過三原則。然而這並不表示這些編輯因為由被封禁用戶完成,所以就一定要被回退(明顯有益的改動,例如改正錯別字和回退破壞,可以予以保留),不過在不確定情況的推定中(presumption in ambiguous cases),相關編輯則應予以回退。(按:沒讀過法律不肯定這個的意思)

相反,維基人不得按照被封禁用戶的指示建立或編輯資料(這種行為有時會被稱為代理編輯),除非他們能夠證明這些改動有根據或有建設,並擁有進行相關編輯的個人理據。對於在相同的處境進行與被封禁編輯/帳號的行為一致的行為的新帳號和只是為了這個目的而編輯維基百科的人士,適用於他們模仿的編輯者的補救措施也適用於他們(參見有關傀儡及真人傀儡方針)。

藉助回退的封禁實施

回退編輯的時候,要留意不要恢復違反中立、可供查證、生者傳記等基本方針的資料。隨後如果被封禁用戶的編輯被某編輯恢復,恢復者則需為這些內容負上全責。

繞過封禁者新創建的條目不可能予以回退,因為根本就沒東西可以回退,卻是快速刪除的適用對象。任何編輯都可以在這些條目中使用{{db-g5}}或{{db-banned}}模板(按:中文版G5隻適用於按照頁面存廢討論刪除,後來重新創建的條目)。如果被封禁用戶以外的其他編輯曾經該條目或其討論頁進行善意編輯,通知他們該頁面由被封禁用戶創建是一個有禮貌的做法。接着才視乎情況再決定善後安排。

我衷心希望這條能夠過,不過我不可能那麼獨裁,而且英文版的狀況也不一定適用於我們。所以請大家踴躍發言,提出意見。--春卷柯南夫子 ( ) 2015年12月19日 (六) 10:02 (UTC)

(!)意見應以現行的方針解決。--Temp3600留言2015年12月19日 (六) 16:08 (UTC)
  • 某些被封禁用戶(例如影武者和Labstore)被封禁之前仍然是有建設的,不過這並不表示比他們建設更少、破壞更多的用戶也要受到同等對待。雖然英文版有禁止個別編輯編輯個別題材的條目的安排,不過有鑑於中文社群的不成熟,一刀切又會對某些情節較輕的被封禁者不公道,不這樣的話就會令妥善執行這個方針變得更困難(沒有人會喜歡有人到自己家搗亂吧?)。--春卷柯南夫子 ( ) 2015年12月20日 (日) 06:33 (UTC)

建議對已有簡繁重定向進行提刪保護或者懸掛模板讓使用者不要將其提刪

如題,個人認爲簡繁重定向已有的不刪,但不建立新的是共識。在存廢討論三番兩次的提刪耗費人力時間。另外建議使用手段禁止新建簡繁重定向。-- M26パンーシン重戰車SCR-510Хорошо 中華民國 104年 2015年12月30日 (三) 15:50 (UTC)

(+)支持簡繁重定向已有的不刪,甚至應列為Wikipedia:快速保留之事項,刪除簡繁重定向會為轉換系統帶來技術風險,過往一向都有繁簡重定向被提刪但都會因技術原因而(○)快速保留之事例(如Wikipedia:頁面存廢討論/記錄/2015/08/22#簡體中文就被User:Jimmy Xu速留了)。
不過,(-)反對禁止新建簡繁重定向,反而應該積極建立,以避免潛在的技術問題發生在新條目上。(「不建立新的是共識」源自哪裏?)--街燈電箱150號 開箱維修 抄錶 檢驗證明 2015年12月30日 (三) 17:32 (UTC)
暫時別拆成兩個討論串分散討論吧,都去WP:VPMLiangent留言 2015年12月30日 (三) 18:19 (UTC)

DYK 提名人能否撤去提名?

昨日@追跡未來Amazingloong兩位在被投反對票後撤去了各自的 DYK 提名(見前者之編輯後者之編輯),而追跡未來更是未經重大修訂便再次提報了他的條目。這樣的情況在如今的 DYK 規則中似未被禁止。然而在下以爲這是一種近於作弊的行爲,理由有二:

  1. 假如提名人在落選前 1 秒刪去提名,隨後又重新提名。該條目本應以落選計,而再次提名則等同於延長了投票期限。(這裏還沒有討論落選條目再次提交是否需要滿足「重大修訂」之「重大」的要求)
  2. 在被反對後撤去提名,又重新提名,無異於洗去反對票。

社羣此前是否已見此類情況?是否需明確 DYK 提名不可中途撤銷,或撤銷則以落選計,並且再次提報需滿足「重大修訂」之要求?--Zetifree (Talk) 2015年12月27日 (日) 12:33 (UTC)

  • 我認為我推的條目被用不恰當的理由「故意刁難」了,溝通無果。我不高興了,所以「參考前例」我不推了,甘願敗選。另,我同意Zetifree的觀點,希望社群儘快做出規定。我贊成需滿足「重大修訂」之要求,不然和作弊刷掉反對票沒有兩樣。--Amazingloong留言2015年12月27日 (日) 13:20 (UTC)

(!)意見,這種案例多的是,敝人也希望堵塞這個漏洞,不過我認為「撤銷了便要視修訂期中斷」的做法又未免太過苛刻,那我也初步提議另一個框架:「若條目在符合資格的情況下由主編者提出撤銷提名,則自撤銷之日起計X天內,同一個主編者不得憑同一個條目再參與推薦」(敝人認為X=7),也許大家可以按此探討其可行性。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2015年12月27日 (日) 18:49 (UTC)

  • 這在上次討論修改DYKC規則時我就有提出了(見上面街燈大的連結),但當時的意思是就算失敗只要修訂其還在,可以無限提名,一來鼓勵繼續修正問題,二來也不認為會有人這麼有毅力一直提名,若是遊戲規則也可以封禁,所以最後並沒有特別堵掉這個問題--Liaon98 我是廢物 2015年12月28日 (一) 00:43 (UTC)
可以接受。但建議加一條:撤銷提名時應將討論存檔,並於再次提名時給出鏈接。目的是儘量防止中國房價這樣,沒有經過有效修改,若之前的反對者沒有注意到二次提名,則反對票被洗刷的情況。--Zetifree (Talk) 2015年12月28日 (一) 03:25 (UTC)
這個我覺得也許可以交給機械人來做。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2015年12月29日 (二) 16:27 (UTC)
機械人很難偵測那個編輯是「撤銷提名」吧。其實有規則我相信大家都會遵守。--Zetifree (Talk) 2015年12月31日 (四) 15:37 (UTC)