萌娘百科討論:討論版/方針政策/存檔/2022年03月
討論版【方針政策】檔案館
對於條目名中一些符號是否應該被允許使用的觀點統計
自萌娘百科討論:討論版/方針政策/存檔/2021年12月#關於MGP:條目命名#避免特殊符號原則的意見徵集,一些問題得出了共識或者我想到了處理辦法,但還有一些沒有討論、沒有得到共識或需要細化討論。在此(再次)統計一下各位對以下符號的觀點,為對萌娘百科:條目命名的提案做準備。
逗號句號這些就不用說了,我絕對要讓它能用。
- 技術上沒有問題,但部分輸入法不易輸入的,一般來說去掉會很怪的符號,通常具有實際意義,如「×」(實際操作傾向於保留?):
- 技術上沒有問題,但部分輸入法不易輸入的,一般來說去掉也不會很怪的符號,通常為裝飾性,如「☆★❤♪*」(實際操作傾向於不保留?):
- 技術上沒有問題的衍生拉丁字母(Æáéíóúæø等):
- 想不出來 (~)補充 於2022年2月5日 (六) 17:28 (CST):Café Parade!
- 技術上稍微有問題的「&?%」等,與URL語法衝突,但MW會轉義(實際操作傾向於保留,甚至有專門把不會出問題的「?」移動到「?」的):
- 技術上有問題的「/」,與子頁面功能衝突,但可以用{{NoSubpage}}假裝不是子頁面:
- 技術上有問題,且在消歧義前後綴中出現的「/」:
我的觀點:
- (+)允許使用
- (=)不確定,但技術上沒有任何問題
- (+)允許使用,這樣可減少不必要的消歧義後綴
- (+)允許使用,理由:MW會轉義。小工具會出錯是小工具的事;試圖在瀏覽器地址欄輸入這些符號以進入條目的請把萌娘百科加入搜尋引擎
- (=)不確定
- (=)不確定
判斷題比簡答題簡單,汴京的話到提案的時候再汴吧。就算僅對某幾點發表觀點也大歡迎。 あめろ 論 2022年2月5日 (六) 03:05 (CST)
- 給3提個例子:Lycéenne(交響樂之雨歌曲),啊好像某個叫Lycee的TCG也該是Lycée——CG/SS domain AUTO CONFIRMED EDITOR Kaze Iro the Legend frog (wisdom·stupidity) 2022年2月5日 (六) 09:06 (CST)
- (~)補充 再來個:Weiß Schwarz——CG/SS domain AUTO CONFIRMED EDITOR Kaze Iro the Legend frog (wisdom·stupidity) 2022年2月5日 (六) 09:11 (CST)
- 個人暫無觀點,重新導向+{{標題替換}}能解決多少?另外會不會改變原意+輸入法好不好處理這個等我想想再答——CG/SS domain AUTO CONFIRMED EDITOR Kaze Iro the Legend frog (wisdom·stupidity) 2022年2月5日 (六) 09:13 (CST)
(-)不支持4 移動版切換語言時不會正確轉義。——移動版用戶 Bhsd 2022年2月5日 (六) 09:21 (CST)
( ¡ )題外話 順便問一下,對於「·•」等,是否仍計畫不允許在標題中使用?——4O74Y74L74J7(討論) 2022年2月5日 (六) 13:15 (CST)
- 目前計畫:若在搜尋引擎中輸入此類符號,自動跳轉到中文語境常用符號。如間隔號統一為·,日文波浪符跳轉到中文的,此後條目命名和此類重新導向可能徹底不被允許。—— ほしみ 2022年2月5日 (六) 13:32 (CST)
- 感謝告知,了解了。——4O74Y74L74J7(討論) 2022年2月5日 (六) 19:22 (CST)
(-)不支持6 消歧義後綴應當儘可能避免此類符號,存在技術性問題。順提,消歧義後綴也不該使用中英之外的文字。—— ほしみ 2022年2月5日 (六) 13:37 (CST)
無視技術問題的話,(+)強烈支持1、3、5,並希望4能夠有辦法解決——CG/SS domain AUTO CONFIRMED EDITOR Kaze Iro the Legend frog (wisdom·stupidity) 2022年2月5日 (六) 13:51 (CST)
- (~)補充 個人認為3應以原名為條目名,英文轉寫為重新導向。——CG/SS domain AUTO CONFIRMED EDITOR Kaze Iro the Legend frog (wisdom·stupidity) 2022年2月5日 (六) 14:06 (CST)
- (~)補充 既然已加入4的支持,那麼1、3、4、5均應可行。--CG/SS domain AUTO CONFIRMED EDITOR Kaze Iro the Legend frog (wisdom·stupidity) 2022年2月8日 (二) 08:17 (CST)
(-)不支持3 3還是做為重新導向比較好,相比×來說極難輸入,不適合作為條目名。再者,如果它可以被轉寫為英文名,按照條目命名規範,英文優先級更高,仍然會以轉寫後的英文標題作為條目名。—— ほしみ 2022年2月5日 (六) 14:04 (CST)
( ? )疑問 5、6的技術問題是否可以被解決?如技術上不可行,我建議考慮處理一下搜索問題。雖然可以進行標題替換,但像22/7、超可動女孩1/6這樣的帶數字頁面在去除符號後就完全無法被站內的搜尋引擎識別(也許可以考慮用空格代替問題符號)。--QAO-LP0 (討論) 2022年2月5日 (六) 14:18 (CST)
- 唯一的辦法是徹底禁止主名字空間子頁面。—— ほしみ 2022年2月5日 (六) 14:40 (CST)
- @星海子 這方法就是現在中文維基百科用的。但我們和中維不一樣的是,我們確實有主名字空間子頁面的需要,以便於讀者查閱。例如魔法少女小圓建立子頁面的問題,中維對於此的處理方式是換用其他表述:zhwp:魔法少女小圓角色列表。但問題在於,目前我們的很多子頁面無法根據調整表述避免「/」的方法解決,例:艦隊Collection/期間限定海域/海上護衛!保衛本土近海航路。對於此問題的解決,我也希望能看到其他人的意見。--Vcfch843875618(討論) 2022年2月5日 (六) 15:00 (CST)
- 如果技術上不可行,那個人建議在搜索部分做好工作。目前使用空格是可以在搜索上代替技術上有問題的「/」的(無論原標題如何),接下來要考慮是否容忍相關的重新導向了。--QAO-LP0 (討論) 2022年2月6日 (日) 10:41 (CST)
Lycéenne條目已建立,歡迎使用作例子調戲站內搜索及各種外部搜尋引擎。(匿了)——CG/SS domain AUTO CONFIRMED EDITOR Kaze Iro the Legend frog (wisdom·stupidity) 2022年2月5日 (六) 15:08 (CST)
- @Legend frog (…)吐槽 我只想說,法語優先度甚至都不如
日文英文高吧……--Vcfch843875618(討論) 2022年2月5日 (六) 15:22 (CST)- 該移動向不正確的英文轉寫、日文片假原名、肯定得消歧義的中文譯名?因為與本討論相關,您可以現在處理,但懇請結論得出後再回顧並進行操作。——CG/SS domain AUTO CONFIRMED EDITOR Kaze Iro the Legend frog (wisdom·stupidity) 2022年2月5日 (六) 15:29 (CST)
- 也許可以更名為女高中生(歌曲)或者用更易輸入的Lyceenne重新導向吧。既然這裡有討論,那不急,討論完後一併定奪。--Vcfch843875618(討論) 2022年2月5日 (六) 15:34 (CST)
- 重新導向是該加,不過當前有「哪個做條目名,哪個做重新導向」的討論,可能與站內/外部搜尋引擎相關,討論完後我處理下。——CG/SS domain AUTO CONFIRMED EDITOR Kaze Iro the Legend frog (wisdom·stupidity) 2022年2月5日 (六) 15:37 (CST)
- 也許可以更名為女高中生(歌曲)或者用更易輸入的Lyceenne重新導向吧。既然這裡有討論,那不急,討論完後一併定奪。--Vcfch843875618(討論) 2022年2月5日 (六) 15:34 (CST)
- 該移動向不正確的英文轉寫、日文片假原名、肯定得消歧義的中文譯名?因為與本討論相關,您可以現在處理,但懇請結論得出後再回顧並進行操作。——CG/SS domain AUTO CONFIRMED EDITOR Kaze Iro the Legend frog (wisdom·stupidity) 2022年2月5日 (六) 15:29 (CST)
(-)不支持 2和~各種波浪線,理由是很難分辨是哪種輸入法的波浪線(中文、英文、日文?);不加語言標記:♡(黑色實心愛心),加了語言標記:♡(空心愛心),區別很大。大多數都出現在日文歌曲名,而且還可能有動畫官網,唱片公司官網,歌詞網站等網站使用不一致的情況(錯別符號)。個人認為要核對是哪個五角星、愛心等符號的工作量會很大。--夜羽と善子(討論) 2022年2月5日 (六) 15:32 (CST)
- 除了技術限制以外,在不引起誤會的情況下,應該可以儘量放寬。另外全形標點符號什麼時候要解禁( —— Eric Liu 創造は生命(留言.留名) 2022年2月5日 (六) 17:47 (CST)
- 日萌倒是可以直接使用五角星、愛心等特殊符號,因為可以正常顯示。--夜羽と善子(討論) 2022年2月5日 (六) 19:49 (CST)
- 提案之後。 あめろ 論 2022年2月6日 (日) 05:39 (CST)
- 為什麼我用來舉例的那個愛心,在手機上看相同,在電腦上看不同?--夜羽と善子(討論) 2022年2月6日 (日) 12:51 (CST)
- 原因是字體,不是語言。 あめろ 論 2022年2月6日 (日) 21:20 (CST)
- 加了語言標籤就可以忽略不同字體的影響。這種情況怎麼辦?--夜羽と善子(討論) 2022年2月18日 (五) 18:24 (CST)
- ( ? )疑問 我沒理解這個問題。
- 我重新解釋一遍前面的吧。愛心顯示不同是由於字體不同,和語言沒有直接關係。標記了語言後愛心變了,是因為瀏覽器為了更好地顯示該語言的文字,換了一個字體。
- 手機上之所以愛心相同,是以下原因之一:是同一字體家族,設計上有一致性;是不同字體家族,但是出自同一字體廠商,且該廠商沒有為不同字體重新設計「♡」;手機上有對應語言的字體,但笨瀏覽器沒調用;手機上沒有對應語言的字體,故瀏覽器沒得換;所更換的字體中沒有「♡」這個字符,故fallback到其他字體。 あめろ 討論 2022年2月18日 (五) 19:53 (CST)
- 加了語言標籤就可以忽略不同字體的影響。這種情況怎麼辦?--夜羽と善子(討論) 2022年2月18日 (五) 18:24 (CST)
- 原因是字體,不是語言。 あめろ 論 2022年2月6日 (日) 21:20 (CST)
( ? )疑問 經星海啟發,對於情況3,如果我說不對此類符號做限制,而是通過官方名稱優先原則、常用稱呼優先原則、簡體中文優先原則等原則來儘量避免此類符號如何?如果這三個原則都管不住它,那說明真的很有必要使用這個符號了。舉個例子(雖然不是衍生拉丁字母):μ's。 あめろ 論 2022年2月8日 (二) 23:03 (CST)
來炸個墳。
( ? )疑問1 如何判定1、2點中的符號是否必要?或是說如果符號能夠換成空格或是常用字符的話這個標題的符號還有必要嗎?(也就是說對於1、2點是否也應該像情況3那樣「通過官方名稱優先原則、常用稱呼優先原則、簡體中文優先原則等原則來儘量避免此類符號」)另外現在站內對於同種情況的不同處理方式可謂是泛濫成災,譬如對於情況2,少女歌劇條目就沒有帶☆。
( ? )疑問2 如果有個閒的沒事的人想寫含有會出錯字符的標題,且該標題無法通過以上三原則規避,那怎麼辦?(比如如果有人想寫「#1f1e33」的話,雖然目前應該是沒有)
( ? )疑問3 在utau界中有許多仿海鮮市場類型的歌曲,其名稱多為亂麻空格和不明字符,有些無法用以上三原則概括甚至會出現空格標題、沒有標題的情況。由於該類utau曲很多都在萌百收錄範圍內而且未來確實也有出現該類歌曲標題的可能,那麼如何解決?
( ? )疑問4 如何看待空格和頓號等常用於替換特殊字符的形式?
(-)不支持6 我覺得完全可以通過縮減後綴或替換後綴的方式來規避該問題。—— 雪月❄️於冬日之會客室相談 2022年2月17日 (四) 23:37 (CST)
- 我的想法是具體到符號——「×」或「☆」,而非具體到情形——「有必要」或「無必要」,所以上面的概括帶上了「一般」和「通常」。即符號白名單與黑名單,這樣在以後操作時可以降低判定難度,減少辯經。至於為什麼分成1和2這兩類,是我觀察現有命名的結果:「×」多為保留,而「☆」多為不保留。你說了少女歌劇條目沒有帶☆,事實上上面舉的千戀萬花、Fate/kaleid liner 魔法少女伊莉雅、777 SISTERS、ROCKS、2winkle Star Beat也都沒有帶符號,帶符號的是重新導向。不同處理方式泛濫確實是一個問題,也是我在這裡徵集觀點的原因。
- 換全形「#」。
- +♂、Ϡ、.、.、.、...、!、・.・.・.、:|、 、 、 、 、?̵͔͖̺͓̬̩?̙̥̪͓̣̟̟?̟̀?̢̯̻̠?̫̯̲̝́??̜̲̼͖̗̩?̬̗̭͟?̙̰̫̝͙͉ͅ ?̮͕̟͎͙̺̮?͚͔̦̥͚?͓̗̩͔?͉̫̰͎̥̳?̡。自然有辦法解決。
- 瀉藥,不看待。
- あめろ 討論 2022年2月18日 (五) 01:26 (CST)
提一個百分號的問題,mw是不推薦使用的,原因為:The problem with % is that when using a path to query rewrite rule, URLs are double-unescaped: once by Apache's path conversion code, and again by PHP. So %253F, for example, becomes "?". Our code does not double-escape to compensate for this, indeed double escaping would break if the double-escaped title was passed in the query string rather than the path. —— ほしみ 2022年2月19日 (六) 05:01 (CST)
日文的『』允許使用嗎?標題中有『』。--夜羽と善子(討論) 2022年2月23日 (三) 17:58 (CST)
- 日文的要用就用吧,中文裡面有使用例嗎? あめろ 討論 2022年2月23日 (三) 21:31 (CST)
- 中文不清楚。--夜羽と善子(討論) 2022年2月23日 (三) 22:07 (CST)
- 中文的「」有使用例,如腦葉公司:「CENSORED」。guguguing.
討論 • 貢獻 2022年2月25日 (五) 08:16 (CST)
《萌娘百科月報》 二〇二二年二月號
- 云霞的管理員申請以(+)44(-)0(∅)1通過。
- 弗霖凯復任管理員。
- Sivlovski、Lyhic辭任管理員。
- 屠麟傲血的介面管理員申請以(+)5(-)0(∅)1通過。
- Qaolp0復任巡查姬。
- 胡祥又、甜的白萝卜的巡查姬申請被接受,進入15日實習期。
- 一位史蒂夫、Leranjun辭任巡查姬。
- Leranjun辭任介面管理員、指令碼編輯員。
- HUBERT CC的巡查姬申請被拒絕。
- Rosaline、森雨次世分身、MINGach、YukinasNeko分身、雾峰哲人、UenoYukitsuki分身、Legend frog、哈曼女王赛高、Kaikai947成為優質編輯者。
- 花落丿天使、MINGach被免去優質編輯者稱號。
- 東東君、Leranjun成為技術編輯員。
- 新增STAFF萌娘百科·娜娜奇、萌娘百科·莫莫。
- Eizenchan、机娘史蒂夫因持有者辭職,一併除去機器人及巡查姬用戶組。
- 本月新增2項提案:《關於使用者查核方針的提案》、《關於反破壞相關的提案》,另有1項提案被撤回。
- 《關於專題指引的提案》被發起人撤回。
- 其他本期月報未提及之論述修訂,詳見連出相關變更。
- 2月9日,行政員發布關於最近萌娘百科訪問困難的公告。
- 2月15日,「元宵燈謎猜猜猜」活動開啟。
- 2月25日,2022年春季新番導視內容徵集活動開啟。
- 萌娘百科官方群組新增QQ頻道。
- 萌娘百科對外宣傳平台帳號新增Facebook、YouTube。
2月月報已發送,抄送一份置於方針政策版。如希望發送月報至您的討論頁,請前往訂閱。——From 引夢者濁華(討論) 2022年3月2日 (三) 13:25 (CST)
關於自動確認使用者標準的調研與討論
據了解,包括我在內的一些用戶認為當前自動確認使用者標準(滿足編輯數達到10、註冊時長達到24小時這兩個條件)過低。
但由於只有自動確認使用者才可以使用評論系統,一些數據又顯示自動確認使用者比例極小,故本次調研不對編輯數這一變量進行討論,只從自註冊後的時間與自首次編輯以來的時間這兩個可行的變量進行討論。
例如,個人認為,為了更好地讓新用戶使用預覽功能,增加學習時間,可以將「註冊時長達到24小時」這一條件,修訂為「自首次編輯以來48小時」可能會更妥當。—— ほしみ 2022年2月5日 (六) 00:47 (CST)
- 如果出現問題的是「只有自動確認使用者才可以使用評論系統」,與其改變自動確認使用者的標準,會不會開放非自動確認使用者使用評論系統?
- 真的,憑著現在有的巡查和管理人數,開放非自確使用評論系統和讓非自確編輯的風險不會有太大分別。--By CHKO (Talk) @ 2022年2月5日 (六) 11:45 (CST)
- 閣下認為自動確認使用者這一身份的意義在於什麼?——From 玉幕辛 (討論)--沒事幹才會寫簽名 2022年2月5日 (六) 11:46 (CST)
- 修改成自首次編輯以來48小時的一個好處是能夠減少新手狂交版本的情況,寫個千把字節提交50+版本那樣。
但還是沒有解決評論門檻較高、新用戶把討論頁當評論區、自確保護效用過低等問題,所以不妨先問問這次修正是想在哪個方面做改進吧,能讓建議更有針對性。——From 引夢者濁華(討論) 2022年2月5日 (六) 12:51 (CST) - 改為註冊或第一次編輯起至少七日?或三日之類的?一日或二日是有點短了,真正要長期貢獻者不會在意把期限拉長一點。—— Eric Liu 創造は生命(留言.留名) 2022年2月5日 (六) 17:44 (CST)
- 並不贊成在不改變評論限制的情況下增加自確難度,這樣可能會大大減少遊客/純讀者評論的興趣
誰會為了發幾句評論編輯十次等48h啊。——From 泠佛. (討論) 2022年2月7日 (一) 00:55 (CST) - 如果一些數據顯示自確比例極小,不考慮取消需自確才能評論的限制嗎?取消了限制的話,更方便討論和修改自確的標準。--夜羽と善子(討論) 2022年2月14日 (一) 01:07 (CST)
- 可否將10次編輯限制為在(主)名字空間進行的編輯?感覺這樣更好。--在下荷花,請多指教 2022年2月17日 (四) 20:41 (CST)
- 在不開發新擴展的前提下,做不到。—— ほしみ 2022年2月17日 (四) 23:22 (CST)
- 好奇問下,「自首次編輯以來若干時間」技術上可行?為啥我在mw:Manual:Autoconfirmed_users/zh只看到「帳戶存在的秒數」和「達到的編輯次數」兩個指標……——C8H17OH(討論) 2022年2月17日 (四) 22:58 (CST)
- @C8H17OH 完整的在mw:Manual:$wgAutopromote#Possible conditions,你看到的自確的兩個常用配置項是$wgAutopromote的默認。 —— ほしみ 2022年2月17日 (四) 23:22 (CST)
- 一個小問題,能否做到將自確和編輯強制預覽分開?編輯一定次數+註冊一定時間可評論,但是強制預覽+驗證碼的時間達到1周以上?這樣評論的難度不變或者降低同時對wiki的學習成本會提高。
感覺這樣做似乎要加用戶組啊 - ( ¡ )題外話 除去把評論發在討論頁,把評論區當討論頁也是一個存在的現象,能否將形成討論的評論刪除並遷移至討論區?--Zyszhao.GoodEditor (討論頁與用戶貢獻) 2022年2月27日 (日) 18:24 (CST)
- 那在用戶和自動確認使用者之間新增一個用戶組,名為「可評論的用戶」,降低註冊時間or編輯次數,例如註冊24小時,編輯5次。但還是需要電子郵件驗證。這樣就可以修改自動確認使用者標準,Zyszhao所說的強制預覽和驗證碼的時間也可以改動。如果不打算把評論限制和自動確認使用者分開的話,個人推測每次討論基本上都是五五開,支持和不支持約各占一半,討論沒有結果。新增「可評論的用戶」這一用戶組是否可行?--夜羽と善子(討論) 2022年3月5日 (六) 17:41 (CST)
請求管理員/巡查姬的建議(方針方面)
萌娘百科_talk:討論版/頁面相關#一些涉亞文化頁面的問題串,請求管理員從方針與政策角度提供建議。--∷∷by Selfice🏠|📭 2022年3月7日 (一) 01:51 (CST)
或許這個討論串應該移動到這裡[萌娘百科_talk:討論版/方針政策]來?--∷∷by Selfice🏠|📭 2022年3月7日 (一) 01:55 (CST)
關於是否需要設立「評論區封禁」政策及相關用戶組的討論
最近評論區各種迷惑發言又多了起來。目前對於限制評論採取的政策為直接封禁用戶,在部分情況下可能並不是最佳選擇。同時也了解到確實存在編輯正常但在評論區經常出現違規發言的用戶。在此發起設立「評論區封禁」政策的可行性與必要性的討論。同時可能隨著政策能降低評論區的發言限制。在技術上設立一個用戶組用於取消評論權限是完全可行的,本次希望就是否需要相關政策進行討論。--SinonJZH(๑•̀ω•́๑)(討論) 2022年3月6日 (日) 00:48 (CST)
- 可能確實需要評論區相關的用戶組用於方便管理,不過可能需要配套的核查、禁止和封禁流程。( ¡ )題外話 我在上面那個串的思路是給出「允許評論」用戶組。。重複造軲轆.jpg--Zyszhao.GoodEditor (討論頁與用戶貢獻) 2022年3月6日 (日) 01:23 (CST)
- 在用戶和自動確認使用者之間新增一個名為「可評論的用戶」用戶組,是否可行?個人認為可能需要相關政策。--夜羽と善子(討論) 2022年3月6日 (日) 15:31 (CST)
- 如果可管可控的話,不如把評論區放開到非自確。——「今日も一日がんばるぞい!」(沼澤 • 討論) 2022年3月6日 (日) 15:33 (CST)
- 還真就是不可管可控,具體見本版第一個串,另外(▲)同夜羽と善子--Zyszhao.GoodEditor (討論頁與用戶貢獻) 2022年3月6日 (日) 16:23 (CST)
- 隔壁版的萌娘百科_talk:討論版/提問求助#【頁面反饋】人身攻擊_@_七海(虛擬UP主)不是證明了目前並不完全可管可控嗎--夜羽と善子(討論) 2022年3月6日 (日) 16:26 (CST)
- 如果可管可控的話,不如把評論區放開到非自確。——「今日も一日がんばるぞい!」(沼澤 • 討論) 2022年3月6日 (日) 15:33 (CST)
關於封禁復檢程序
萌娘百科上有兩個方針提到了「封禁復檢」這個程序,但以「封禁復檢」為關鍵詞進行搜索卻完全找不到這個程序本身的定義和流程是什麼。如果可以的話最好在封禁政策或者一個單獨的頁面寫一下這個程序的定義。McEndutalk 2022年3月9日 (三) 22:24 (CST)
- 「封禁復檢」這在哪兩個方針中出現?--By CHKO (Talk) @ 2022年3月9日 (三) 23:21 (CST)
- 似乎是MGP:分身帳戶方針和MGP:用戶頁面方針. ——Ithea 淮南皓月 2022年3月10日 (四) 00:27 (CST)
- 或許應該在萌娘百科:方針中「使用者封鎖政策」一節做簡略解釋。—— Eric Liu 創造は生命(留言·留名) 2022年3月10日 (四) 04:08 (CST)
- 首先,我寫MGP:用戶頁面方針的時候是抄的MGP:分身帳戶方針()。
- 然後,據我個人理解,這個詞包括:1.「封禁申訴」程序;2.其他人在討論版等處對某次封禁提出的異議/質疑。
- 最後,支持AnnA在反破壞提案中提出的有關建議。——C8H17OH(討論) 2022年3月10日 (四) 22:59 (CST)
- 已在提案中增加有關內容。——From 引夢者濁華(討論) 2022年3月11日 (五) 09:18 (CST)
關於人物收錄範圍修改的第二次預討論
在上個月,我曾針對收錄範圍提案後存在的問題展開過一次預討論,並收穫了不少寶貴的建議,在此感謝參與討論的各位。
目前針對爭議較小,但又相對比較急需修正的人物部分單獨發起討論,望各位能夠不吝提出修改建議。如無問題,我將儘量在本月15日前發起正式提案。
其中有部分內容也在配合#音樂收錄範圍第三修正案預討論提出的問題一併進行修改。——「今日も一日がんばるぞい!」(沼澤 • 討論) 2022年3月6日 (日) 12:54 (CST)
收錄範圍補遺提案的現實人物部分修正案 - 正文
收錄符合以下條件之一的現實人物:
- 作品一節所規定作品[1]的相關創作者:漫畫家、声優/配音演員、ACG歌手[2]、動畫師、原畫師、插畫家、小說家、P主、音樂家、腳本作家、製作人等;
- 其他ACG相關行業內容創作者:網絡畫師、歌手、Coser、舞者、網絡視頻製作者等;
- ACG產業的其他相關人員[5]:電子競技職業選手及解說員[6]、遊戲[7]主播等;
- 遊戲主播:必須在至少一個直播平台擁有10萬以上粉絲。[8]
- ACG行業從業人員:組織一節所規定組織的董事長/代表取締役等高級運營管理人員,或是大型綜合組織中ACG相關部門的主要負責人。[9]
- 與ACGN+文化、迷因等關聯的人物。但相關條目應當圍繞相關ACGN+文化、迷因為主予以介紹,非ACGN+相關的人物經歷進行簡要概述即可。
注意:
- 不要混淆作品中角色和現實人物;
- 不要惡搞現實人物;
- 與ACGN關聯不大,但擁有獨立二次元形象的網絡名人和明星,應當以其二次元形象為主予以介紹;
- 不符合上述收錄要求,但有較高流行度和迷因屬性的網絡人物,可通過網絡流行用語之方式收錄。若要撰寫人物的條目,條目內容應重點關注與其相關的用語、成句,而僅對人物經歷進行簡要描述;
- 不是ACG相關行業從業者,但有少數ACG經歷的明星、藝人、歌手等(統稱「多棲藝人」),若ACG經歷和作品多於三個,且認可自身的ACG相關內容創作者身份的,允許以獨立條目收錄,且條目內容應當以ACG經歷和作品為主。否則可將其ACG相關經歷和作品單獨匯總到多棲藝人條目下,而對人物本身不做任何介紹;
出於人物隱私及形象考慮,請勿使用非公開或不宜公開的、或者有損人物形象的照片作為條目圖片。[10]
另外需要調整音樂部分的收錄範圍:
注釋部分
- ↑ 參照角色一節的定義修改措辭避免歧義。根據淮南皓月的建議修改。
- ↑ 拆分後留下來的問題,少了一類重要的人物。
- ↑ 移動相關要求至現實人物一節。
- ↑ 統一表述:調整了措辭和順序。
- ↑ 因為較難認定這三類屬於「內容創作者」,故單獨分出。根據Amero的建議修改。
- ↑ 電競選手及賽事解說員算是遊戲產業的重要分子,應當予以收錄。根據Chko和Legend frog的建議增加。
- ↑ 主播從ACGNM幾大範疇來看,目前來看似乎只有遊戲主播一類因為不能搭上其他收錄範圍的許可,而需要在此進行特殊規定。直播看動畫、漫畫、輕小說的主播就算了吧。
- ↑ 增加了對於遊戲主播收錄的知名度限制,防止濫收。
- ↑ 增加關於部分人物的收錄許可,例如bishi和陳睿(bilibili董事長)。另外統一調整了措辭以避免歧義。根據北湖3的提議進行了另行擴充。
- ↑ 關於配圖的使用限制交給萌娘百科:現實人物條目編輯指引去規定。
- ↑ 增加關於組合的說明,避免收錄範圍缺損。
- ↑ 移動相關要求至現實人物一節。
討論區
沒有上次從chko建議那修改的「電競職業選手」嗎——CG/SS domain GOOD EDITOR Kaze Iro the Legend frog (wisdom·stupidity) 2022年3月6日 (日) 13:03 (CST)
( ¡ )題外話 可以順便修改一下「符合收錄範圍的作品」這個表述,要咬文嚼字的話,說不清是必須符合作品收錄條件,還是說只要是作品、能收錄,以原型標準收錄的作品也算。——Ithea 淮南皓月 2022年3月6日 (日) 14:08 (CST)
我質疑電子競技職業選手及解說員、遊戲主播的「內容創作者」地位,他們至少得換個位置。另外我對收錄只進行遊戲直播的現實人物持負面態度。 あめろ 討論 2022年3月7日 (一) 01:06 (CST)
- 那麼就把這三者一起開一個新欄目。單純只進行遊戲直播,而不產出任何切片的人我覺得是非常少的,自己玩遊戲的直播切片可以算作是一種產出嗎?——「今日も一日がんばるぞい!」(沼澤 • 討論) 2022年3月7日 (一) 09:09 (CST)
- (&)建議 :①對於舞者,應規定其有三首以上以收錄範圍內音樂作品或其二次創作作為BGM的舞蹈視頻投稿,以限制收錄某些以韓舞、某音風為主的舞蹈網絡視頻作者;
②對於某些僅有部分業務與ACG相關的大型企業集團,其主要負責ACG業務的部門、事業群等的主要負責人(如部門經理、總監等)也應予以收錄,畢竟我個人認為以其企業的體量,其對ACG產業的影響很可能遠大於某些只有ACG相關業務的小企業。——北湖3(討論) 2022年3月12日 (六) 19:00 (CST)
是否可以設立用戶每日發表評論數量限制
在存檔里看到了這個月早些時候關於自動確認使用者標準的調研與討論。因為原話題已被存檔,所以另開一條。 話題討論中一方面希望評論區更加活躍,並減少萌新把評論發到討論區的情況,另一方面擔心不了解相關規則的萌新和有意藉機破壞者影響評論區環境。我的建議是,可以考慮允許萌新註冊和認證郵箱後,或者滿足比較低的標準(比如一條編輯)後即可使用評論區,但滿足比較高的標準前對他發評論的頻率做出限制——比如每天只能發表一條評論。不知技術上能否辦到?--櫻桃納米粉(討論) 2022年3月17日 (四) 13:19 (CST)
- (-)反對 評論是萌百的一大特色,限制用戶每日發表評論數量不太現實;另外如果真的要限制用戶每日發表評論數量的話,我建議是每個條目每天只能發2-3條。--TNLHK(sign|talk) 2022年3月17日 (四) 13:27 (CST)
- (-)反對 甚至可以限制每天的編輯數以防止破壞—厚禮謝來喝茶吧 2022年3月17日 (四) 15:53 (CST)
- 現階段技術上做不到。 —— ほしみ 2022年3月17日 (四) 16:37 (CST)
關於限制同時存在討論中提案數量的提案的預討論
如題,也相信大家注意到萌百最近高得離譜的投案密度。截止目前,萌娘百科討論:提案/討論中提案下面共有6個子頁面。同時存在的提案過多會大大降低討論效率,使得討論不充分。因此,我認為有必要限制同時存在的討論中提案數量。通過對維護組成員進行意見徵集,我現在給出初步想法:在提案發起條件中加上萌娘百科討論:提案/討論中提案的子頁面數量不超過三個和提案發起人未有討論中提案。在此徵詢大家的意見。--CONTINUE TO FIGHT WITH OMICRON!·P. W. T.(萌利策獎提名) 2022年3月17日 (四) 23:26 (CST)
- (+)支持 早該有了--SinonJZH(๑•̀ω•́๑)(討論) 2022年3月17日 (四) 23:34 (CST)
- (+)強烈支持 大片的提案屬實比免疫學還噁心—— 秋園邀請你去地下室和重馬場一坐 2022年3月17日 (四) 23:39 (CST)
- (-)弱反對 能理解這樣做的初衷,但出台此規定也會有一個潛在的負面效果,就是提案者可能會傾向把多種短提案合併為一個長提案,而實際上長提案相比多提案更容易出現討論不充分、討論秩序混亂的問題。比如說,當前遊戲收錄範圍和現實人物收錄範圍的修正案是獨立的兩個,大概就是想吸取先前的教訓,方便用戶追蹤討論進度,避免長提案的各種問題。而如果只是去硬性限制總提案的數量,那麼提案者可能就會把這兩個合併為一個長提案來規避限制,其實對社群的壓力更大。——Sirogohan(討論) 2022年3月17日 (四) 23:42 (CST)
- 我們也在想辦法去通過規定避免這種提案的出現。您有什麼好的想法嗎?--CONTINUE TO FIGHT WITH OMICRON!·P. W. T.(萌利策獎提名) 2022年3月17日 (四) 23:46 (CST)
- 我覺得可以先對發起長提案、多提案做規勸,不一定立刻升級為硬性規定。另外也可以鼓勵提案者多進行預討論,特別是這種「預討論」不一定是非要在標題中寫上這三個字的、寬泛的、針對全篇草稿的討論,也可以是針對局部潛在爭議或細節的討論,這樣也可以改善正式提案過程中的討論秩序和效率。——Sirogohan(討論) 2022年3月17日 (四) 23:54 (CST)
- ( ¡ )題外話 我覺得本串的根本在於希望改善提案討論效率而不只是讓站務欄的外觀變得清爽,因此多補一個題外話的建議:我想提案討論區可以呼籲用戶儘量避免「U:XXX的意見」的子標題,統一按照內容或者款項設置標題,以及可以考慮按照正文款項的順序而不是建立子標題的時間順序來排列討論區的子標題,這對於提高效率可能也有一定的幫助。——Sirogohan(討論) 2022年3月18日 (五) 00:20 (CST)
- 像沼澤將收錄範圍的新提案分開提就有我的建議。我覺得提案發起人應當對提案負責。子標題那裡我原來也是和您一樣的想法,但今天寫人物收錄範圍修正案的意見的時候我覺得不能做強制性規定了,因為有的時候確實一個人把自己具有關聯性的意見在沒有他人提到的時候一併說出是好的。我覺得應當鼓勵提案發起人按階段對意見進行總結歸納,這樣我覺得也能提高效率,並且很提案發起人都在這樣做。而這意味著提案發起人要付出更多精力,所以我認為還是有必要限制同一個人同時發起提案的個數。星海說的關聯性提案的事也有道理,所以我現在覺得限制一個人同時最多提兩個提案應該是可以的吧。--CONTINUE TO FIGHT WITH OMICRON!·P. W. T.(萌利策獎提名) 2022年3月18日 (五) 01:18 (CST)
- 鑑於出發點是提高提案討論和結果的質量,確實由發起人自覺控制、自行處理是更好的做法。只是大家的熱情實在是過于震驚到我了,否則也不至於出此下策……如果早知道其他發起人也在準備這兩天發起提案,我一定不會趁這個熱鬧發起並不緊迫的用戶頁面方針修正案的。——C8H17OH(討論) 2022年3月18日 (五) 00:34 (CST)
- 我們也在想辦法去通過規定避免這種提案的出現。您有什麼好的想法嗎?--CONTINUE TO FIGHT WITH OMICRON!·P. W. T.(萌利策獎提名) 2022年3月17日 (四) 23:46 (CST)
- (-)反對 未來也許可以有相關政策,我支持討論中提案限制到3個。但我不認為現階段發第六個提案來限制是有必要的,反而更加重討論負擔。
- 我不認為「提案發起人未有討論中提案」是必要的。提案發起人很有可能發起兩個關聯提案,強制合併是不妥的,沒有限制的必要性。
- 我不認為把投票和討論算在一起是必要的。投票本就建立在討論基本結束的基礎上,我認為單獨限制討論數即可。用戶本應該在討論期間進行討論,如果沒有特殊原因,非要等到投票期才去看提案並在投票留言中發表大段意見是不推薦的行為。
- —— ほしみ 2022年3月17日 (四) 23:48 (CST)
- 問題在於在可進行提案總數有限的前提下,這可能會過於影響其他提案發起人的機會,
萬一星海連著發了一整年的提案,一個投完馬上發下一個,其他人完全沒機會發怎麼辦。也許不是大問題,或者說可能還是更需要自覺控制而不是硬性規定的問題。——C8H17OH(討論) 2022年3月18日 (五) 01:08 (CST) - 這個我在對白米飯的回答里已經提到了,另外我認為如果發起人同時提三個提案或許可能並不能像他自己想像中的有餘力……我擔心提案發起人也會有考慮不周的地方。但關聯性提案的事確實有道理。那我認為應當限制最多同時提兩個。--CONTINUE TO FIGHT WITH OMICRON!·P. W. T.(萌利策獎提名) 2022年3月18日 (五) 01:18 (CST)
- 問題在於在可進行提案總數有限的前提下,這可能會過於影響其他提案發起人的機會,
自去年十一月以來,萌百的站務效率明顯提升,通過了數量眾多的提案,在大幅完善方針體系的同時,也使得廣大維護人員和編輯者需要經常性地應對站務討論。尤其是昨天到今天兩天的時間,接連有四個提案提出,加上此前已經提出的提案,目前竟然有五個提案在討論中、一個在投票中。考慮到人很難同時思考太多的事務,如此高密度的提案會使參與者過於疲累,也會影響提案討論及最終成果的質量。因此,我和幾位維護人員私下討論了一下,覺得有必要限制一下同時進行的提案的數量。
關於具體方案方面,目前有幾種不同的觀點:第一種是分別計算處於討論期和處於投票期的提案,並分別限制數量;第二種只限制處於討論期的提案數量;第三種是將討論中和投票中的提案數量一起計算並限制。數量上大多認為3個(或各3個)較好。
我個人的想法是第一種,限制為各3個(其中投票期的還可以考慮將人事投票一起算入),理由是:投票期的提案通常已經比較完善,並且看過一遍、投完票之後就不用再看了,負擔相對較小;而討論中提案在短期內可能會經常有新的討論,需要較高密度的關注。基於兩種性質不同,可以分別考慮和計算。此外這也是第二種和第三種思路的折衷辦法。
另外關於如果限制後現狀不滿足要求如何處理,我的想法是延長提案的最後開始投票時間(MGP:提案#投票第2條第2款),直到滿足限制要求。
此外,還有觀點提出可以限制同一個發起人提出的提案數量,即一個人發起的上個提案沒結束前不能提下個。
在此徵求一下大家的意見,如果能達成較大的共識,我或者觀點相近的其他人可能會就此提出提案。是的,因為五個提案太多了,所以要提第六個。
以上。——C8H17OH(討論) 2022年3月17日 (四) 23:37 (CST)
- 預討論和投票中還好,討論中太多就太累了(?) 庫德里爾 ( 論 · 簽 ) 留於 2022年3月18日 (五) 07:43 (CST)
- (+)支持辛醇觀點3 這個可以有,不過我有一個疑問:是否應規定,當發生重大公關事件等情況,以至於需要緊急提出解決方案時,可以忽略提案上限。--From 環保酵素簽名提醒小助手(💬會客廳) 2022年3月18日 (五) 09:57 (CST)
- 我覺得不一定要硬性限死提案的數量,我覺得可以設置為超過三個的提案在前面的提案進入投票前不計算三十天的討論時限,等到前面的提案結束後再開始計算三十天時限。—SinonJZH(๑•̀ω•́๑)(討論) 2022年3月18日 (五) 14:55 (CST)
經過初步意見徵詢,萌娘百科討論:提案/討論中提案/關於限制同時進行提案數量的提案已經放出,歡迎各位討論。因為我實在不能保證之後能找到提案密度降下來的時間而如果該提案通過則提案密度一定會降下來,所以抱歉發起第六個同時討論的提案了。--CONTINUE TO FIGHT WITH OMICRON!·P. W. T.(萌利策獎提名) 2022年3月18日 (五) 15:37 (CST)