2023年政策修订增补工作正在进行中,欢迎参与!
  • Moegirl.ICU:萌娘百科流亡社群 581077156(QQ),欢迎对萌娘百科运营感到失望的编辑者加入
  • Moegirl.ICU:账号认领正在试运行,有意者请参照账号认领流程

萌娘百科討論:討論版/方針政策/存檔/2021年10月

萌娘百科,萬物皆可萌的百科全書!轉載請標註來源頁面的網頁連結,並聲明引自萌娘百科。內容不可商用。
跳至導覽 跳至搜尋

檔案館討論版【方針政策】檔案館


20

21

22

23

24年

為用戶頁面方針草案徵求意見

前情提要:萌娘百科_talk:討論版/提問求助/存檔/2021年08月#關於「用戶沙盒」的定義萌娘百科_talk:討論版/方針政策/存檔/2021年08月#關於用戶沙盒相關方針的修訂草案(徵求意見)

之前在重寫用戶沙盒政策草案時就有擴展至重寫整個用戶頁面政策的想法,正好前一段時間連着處理了幾次未經允許修改他人用戶頁面的問題(包括一個被我挑起來的x),這兩天整理了一下思路和經驗,寫出了一篇草稿:User:C8H17OH/Drafts#萌娘百科:用戶頁面方針,之前的用戶沙盒政策草案也就合併進去了。

這個方針草案相比現行MGP:方針#用戶頁面政策主要有有以下改進:

  1. 優化了對用戶頁面內容的禁制的表述,與MGP:方針#頁面管理政策等段落中已有的更詳盡的規定銜接,保留了其他方針中未提及的兩點;
  2. 刪去了在MGP:討論區管理方針中已有詳細規定的用戶討論頁政策;
  3. 大幅細化了「未經許可不應無故修改他人的用戶頁」的規定以便在實踐中執行;
    • 其中,(雖然地方不一定合適,不過還是)放入了之前與Func、星海、橋姬討論時擬定的「申請修改被打回頁面」的程序;
  4. 細化了用戶沙盒政策,詳見此前的討論;
  5. 補充規定冒充其他用戶為破壞行為

寫得很草率而且是閉門造車,一些細節上主要是憑我自己的經驗來的,故再次在討論版徵求意見,請各位賜教,感謝。—— 在隔壁權限版意外被cue的C8H17OH討論) 2021年9月17日 (五) 15:38 (CST)

用戶沙盒相關草案中,第二條頁面位置「用戶沙盒應創建在用戶本人的用戶頁……」和第五條容錯「在不違反其他政策規範的前提下,原則上允許用戶沙盒存在內容、格式等錯誤,但是以下情況除外……將用戶頁本體用作用戶沙盒」似乎有所矛盾。此外個人認為將用戶頁本體用作用戶沙盒這一容許條款本身並不合適(因為有用戶使用不存在用戶/分身用戶的用戶頁進行破壞等違反方針的案例在先,個人對此還是有顧慮的)。--Qaolp0 (討論)「夜空を旅しよう。」 2021年9月17日 (五) 19:05 (CST)
這個我在下面的「用戶沙盒部分的早期說明」中有闡述:「因為用戶頁通常不作為沙盒,但也有少數用戶會用用戶頁做測試,故做折衷規定,允許將用戶頁用作沙盒,但不享受容錯特權。【後者待定】」。不過現有MGP:用戶頁面論述確實是不支持用戶頁用作沙盒的,而且用戶頁和子頁面在過濾器等方面也確實有差異,要不就還是維持現有做法,看下大家的意見。
至於這個破壞者的行為……說實話ta在任何頁面都能破壞,和用戶沙盒政策如何大概沒什麼關係。不過「不存在用戶」這個值得補上。——C8H17OH討論) 2021年9月17日 (五) 23:25 (CST)
我個人對「將用戶頁用作沙盒」這一點還是難以同意的,也更傾向於現有論述的表述。或許可以如您所說,先按目前慣例禁止將用戶頁主頁當做沙盒頁,再行就這一問題討論。
另外注意到了下面的討論,請教一下目前允許在用戶主頁面/子頁面添加的分類有哪些(不包括沙盒)?--Qaolp0 (討論)「夜空を旅しよう。」 2021年9月19日 (日) 00:14 (CST)
那我就先改回現行做法了。
這個我真不太了解,請教一下@星海子還能提供點參考嗎?看了一下MGP:討論區管理方針MGP:重新導向方針(都是星海主筆)中提及分類時也都是原則性規定而沒有列舉,所以這裡應該也不需要在方針中詳細列舉。——C8H17OH討論) 2021年9月19日 (日) 16:58 (CST)
例如,討論頁允許包含錯誤錨點、編輯請求等分類,重新導向頁面允許有分類重新導向等分類。事實上,許可的分類並不好列舉,唯一的共性是維護性分類,因此這麼寫的。—— ほしみ 2021年9月19日 (日) 17:21 (CST)
(~)補充 一個非實質性修改,修改他人的用戶頁面中,「若修改者偽稱或偽造授權,則按本章第6.1條處理……」,「第6.1條」應為「第7.1條」。
( ¡ )題外話 個人認為「頁面所屬用戶事後認可了這一修改」一般都會在回退操作執行完成後才會追認,其他和善意推定相關的處理辦法也存在執行難度(因為善意推定本身就非常主觀),或許統一先行回退再分情況處理會更好一些。--Qaolp0 (討論)「夜空を旅しよう。」 2021年9月17日 (五) 19:32 (CST)
加了一條之後忘了調整序號了,Face-smile.svg感謝
這點的話是基於我此前的一次經歷:有位比較新的用戶修改了另一用戶的用戶頁,給用戶框用表格排了版,我注意到之後去詢問了修改者是否得到授權,修改者承認沒有並去給頁面所屬用戶道了歉,頁面所屬用戶沒有責怪,並感謝了ta的排版,最終以我的提醒結束。(以上均為站內公開討論)
對照着闡述一下:首先,上面的修改能明顯看出是善意修改,既然是善意的修改那我覺得可以不必立即回退,由維護人員、修改者、頁面所屬用戶三方溝通解決更好,包括回退可以交給頁面所屬用戶自行決定,如果頁面所屬用戶還在活躍的話。
其次,本站不少編輯者會採用私下交流和授權的方式,而且很多時候他們不會記得去掛模板或者在摘要里寫上,尤其對於比較新的用戶,很多時候在詢問前確實難以得知是否是授權修改,萬一錯怪也不好。而且這一詢問操作本身也是一次提醒和「普法」的過程。
這裡我擬定的流程總體上給維護人員留下了很強的靈活性,包括比如說「無法判斷是否……」其實可以用任意方法判斷,善意推定也可以按處理此事的維護人員自己的思路來推定,總的來說我傾向於不設置過於死板的程序,發揮維護人員的主觀能動性。這樣吧我去把詢問程序改為可選的環節,避免在這裡過於約束手腳,使習慣一律先行回退再進一步處理的維護人員能免除疑慮。——C8H17OH討論) 2021年9月17日 (五) 23:25 (CST)
「用戶頁面不應添加任何分類」似乎有一點問題,感覺應該是不應存在非維護性分類(?
另外,我覺得還應該增加一條,除Gadgets等維護需求外,不允許用戶頁面在其他命名空間嵌入使用,包括但不限於以{{}}、templatestyles等形式嵌入。—— ほしみ 2021年9月17日 (五) 20:36 (CST)
除了用戶沙盒裡的即將用於正式頁面的分類,我似乎不知道有其他可以用於或專用於用戶空間的分類?前者通過用戶沙盒政策已經豁免了。
有道理,我想想放哪裡。——C8H17OH討論) 2021年9月17日 (五) 23:25 (CST)
例如cat:不可索引頁面,用戶可以通過魔術字自行添加。其他還有一些由系統自動添加的分類,例如含有受損文件什麼的。—— ほしみ 2021年9月17日 (五) 23:36 (CST)
Symbol Circle OK.svg 了解 那就改成除了允許的分類以外都不允許吧(廢話?和模板的「不允許使用不允許使用的模板」正好對上x)。——C8H17OH討論) 2021年9月18日 (六) 00:16 (CST)
「用戶頁面內容的禁制的表述」的內容,是否應該添加「對萌百用戶以及萌百收錄的條目所介紹的人物/作品/文化的人身攻擊和辱罵,不管他們在大眾的口碑如何」?我認為由於萌百區別於其他網站,這個也應該屬於違規內容。--愛吃麵包的Hooonooka討論) 2021年9月18日 (六) 12:26 (CST)
MGP:方針#頁面管理政策MGP:方針#破壞行為中已存在對所有頁面內容的禁止性規定,其中已包括人身攻擊、辱罵、地圖炮等,用戶頁面不需要有比所有頁面更嚴格的規則。——C8H17OH討論) 2021年9月18日 (六) 17:21 (CST)
(…)吐槽 您這問題已經(無端)糾結超過半年了,可以消停下了吧。——このLegend frogガンバラナイト 2021年9月20日 (一) 07:37 (CST)
( ¡ )半個題外話:對於被打回用戶頁的條目以及用戶用作條目草稿的用戶沙盒頁,是否有可能專門建立一個模板來統一標識,並且像施工中模板那樣設置一個最後編輯時間的計時以及在多久後需要維護人員進行處理。並且可以考慮利用這個模板將這些草稿頁面列入維護性分類中(比如[[Cat:用户正在撰写的草稿]]以及[[Cat:用户长时间未编辑的草稿]]之類的)以便於維護。更進一步,有沒有可能通過技術手段防止添加了這個模板的頁面中的其他分類生效呢?--SinonJZH(๑•̀ω•́๑)(討論) 2021年9月19日 (日) 22:16 (CST)
挺好的建議,是值得討論的話題;不過因為暫時沒有共識,我覺得在方針里先不需要急着規定。
上次用戶沙盒方針徵求意見時,月櫻雪曾經提過「可以建立一個用於標記被打回頁面的模板」,我覺得值得一試,不過似乎還沒有得到廣泛認可。關於被打回頁面的爭論,還可以看一下上月底的討論。此外,星海提出的引入Draft空間的設想也值得進一步研究。
至於非打回頁面的用戶沙盒,我認為不適合大規模掛模板,如果限定在只在有錯誤的頁面掛還好一點,不過我還是傾向於反對,原因在於:1.會增大維護負擔(主命名空間的CAT:積壓工作還干不完呢x);2.有點干涉用戶頁面自由的感覺,增加了一個並非用戶原本想顯示的模板;3.對於本就不太懂代碼和/或站務的非熟練用戶,可能會造成更多的理解困難甚至驚慌。
防止分類生效大概只能從MW系統方面入手,一個分類應該是沒法消去另一個分類,除非是用模板添加的;要搞的話可能用「用戶命名空間的分類一律無效」這樣的邏輯更方便?這裡我用「技術措施」一條預留了空間(其實也是用來催更x),看技術人員後續的措施吧。
——C8H17OH討論) 2021年9月19日 (日) 23:06 (CST)
如果能夠引入草稿命名空間的話確實能夠比較好的解決這一系列問題,而對於非打回頁面的用戶沙盒,我覺得可以把懸掛模板作為一種推薦措施,這樣在沒有草稿空間的情況下可以通過分類的方式統一管理和查找。同時懸掛模板也可以解決當前方針中禁止編輯他人用戶頁的問題。對於這一類懸掛了草稿模板的條目,可以加一個允許其他用戶編輯的選項,這樣其他用戶也可以查看現在仍然處於草稿狀態的頁面並作出改進。特別地,我覺得對於被打回用戶頁的頁面,應當默認允許所有人進行編輯(即與普通條目一樣),並且允許後來的編輯者改進後直接將條目轉正。在您提及的上個討論中,似乎對於被打回頁面的編輯權限問題並沒有討論出明確的結果,我覺得在這方面還是需要明確一下的。
另外關於被打回頁面查找困難的問題,我覺得可以在草稿模板中加入原始條目的連接,並在被打回的主條目加入編輯提示,可以在鏈入頁面中查看被打回的草稿版本,進行改進或作為參考。(僅是我想出的一種方案,可能還有更好的進行提示的方案)--SinonJZH(๑•̀ω•́๑)(討論) 2021年9月20日 (一) 00:25 (CST)
可行度不高。——單推人一位史蒂夫 討論·貢獻 請問您要單推一隻小浣熊嗎? 2021年9月21日 (二) 16:09 (CST)
關於「被打回頁面的編輯權限問題」,上次討論中達成的共識(?)是可以申請將被打回頁面移動回原位置後改善,但不能直接修改。這一點已經寫入了草案「修改他人的用戶頁面」第6條。關於為什麼這樣規定,我個人的理解是還是不放心讓普通用戶直接修改用戶頁面,但作為維護操作的打回本身是可逆的,故用戶可以申請進行這樣的逆操作,且申請後需要負責改進頁面。
關於其他的建議,想法是好的,但我感覺相比引入的複雜度來說效果不會太大,可以在以後的討論中再考慮。——C8H17OH討論) 2021年9月23日 (四) 10:26 (CST)
(~)補充 是否可以增加「用戶可以不經申請直接掛刪自己的用戶頁」的條款?這樣可以減輕一些維護組的負擔,同時在處理用戶頁刪除上更加高效一些。--SinonJZH(๑•̀ω•́๑)(討論) 2021年9月21日 (二) 14:13 (CST)
非維護組成員沒有掛刪權限。——From 月_櫻_雪 (討論) 2021年9月21日 (二) 14:29 (CST)
我的意思就是,可以考慮將掛刪自己用戶頁的權限下放,以簡化流程。--SinonJZH(๑•̀ω•́๑)(討論) 2021年9月21日 (二) 14:34 (CST)
(-)不支持 我擔心此類的權限下放會被某些人利用。--Qaolp0 (討論)「夜空を旅しよう。」 2021年9月21日 (二) 15:52 (CST)
這是十分麻煩的事,涉及的修改很多(後台數據、過濾器、掛刪模板等),而又容易被濫用(例如用戶故意將頁面移動至自己用戶頁下後掛刪),因此我認為完全不可接受,除非有完善的解決方案。——From 月_櫻_雪 (討論) 2021年9月21日 (二) 17:39 (CST)
掛刪相關權限與後台無關,普通用戶將其他命名空間的頁面移入用戶命名空間的行為也可以簡單地(我認為也有必要)被過濾器禁止。--Func討論·貢獻) 2021年9月21日 (二) 17:49 (CST)
(+)支持 (~)補充 我認為過濾器可以很好的限制用戶只能掛刪自己的用戶頁,另外正式刪除一個頁面前應當本來就至少需要進行一次確認的吧?--SinonJZH(๑•̀ω•́๑)(討論) 2021年9月21日 (二) 19:51 (CST)
如果如Func佬所說,修改過濾器以使用戶能且僅能掛刪自己的用戶頁面是可行的話,我是(+)支持 的。——C8H17OH討論) 2021年9月23日 (四) 10:26 (CST)
提案已經發起多日。——--4-0-2,20-0-4,27-2-7討論·貢獻) 2021年9月30日 (四) 10:03 (CST)
問題已解決。
您仍可以繼續在本模板上方回覆,但這個討論串將會在本模板懸掛滿3日後 (於2021年10月4日凌晨) 存檔。
如果您有有關疑問,建議您開啟一個新的討論串
——--4-0-2,20-0-4,27-2-7討論·貢獻) 2021年9月30日 (四) 10:03 (CST)

關於用戶權限體系調整的預討論

萌娘百科的用戶組已經很久沒有較大變動了,不僅部分用戶組不符合現狀,而且缺少一些新時代需要的用戶組。
因此,我參考了其他多個維基項目,結合管理員申請對內容維護要求高、多數現任管理員極少維護技術類內容的現狀,草擬了一個萌娘百科用戶權限體系調整的方案
由於全文太長,請移步User:星海子/UserGroup閱讀全文。
其實早在方針修正案時期就有了部分想法,正好前一段時間的一些現狀以及很難有更好的改進辦法引出了更深層次的問題,不妨藉此機會把草案放在討論版討論。
此外,用戶組和用戶權限調整在技術上沒有任何難度,調整也很快,細節不在此贅述。
歡迎大家參與討論!—— ほしみ 2021年9月27日 (一) 17:36 (CST)

我知道為什麼有人說看不懂了。給:

用戶組 權限
+ 介面管理員
(interface-admin)
+ 編輯全站CSS (editsitecss)
+ 編輯全站JSON (editsitejson)
+ 編輯全站JavaScript (editsitejs)
+ 編輯其他用戶的CSS文件 (editusercss)
+ 編輯其他用戶的JSON文件 (edituserjson)
+ 編輯其他用戶的JavaScript文件 (edituserjs)
+ 編輯用戶界面 (editinterface)
- 小部件編輯者
(widgeteditor)
-
+ 指令碼編輯員
(scripteditor)
+ 在 Widget 命名空間中創建和編輯小部件 (editwidgets)
+ 編輯保護級別為「僅允許技術編輯員和管理員」的頁面 (techedit)
+ 技術編輯員
(techeditor)
+ 編輯保護級別為「僅允許技術編輯員和管理員」的頁面 (techedit)
+ 導入員
(importer)
+ 從其他wiki導入頁面 (import)
+ 通過上傳文件導入頁面 (importupload)
+ 導出頁面 (export)
監督員
(suppress)
+ 將條目在濫用日誌中隱藏 (abusefilter-hide-log)
+ 查看隱藏的濫用日誌條目 (abusefilter-hidden-log)
管理員
(sysop)
- 編輯全站CSS (editsitecss)
- 編輯全站JavaScript (editsitejs)
- 編輯其他用戶的CSS文件 (editusercss)
- 編輯其他用戶的JavaScript文件 (edituserjs)
+ 編輯保護級別為「僅允許技術編輯員和管理員」的頁面 (techedit)
+ 導出頁面 (export)
+ 添加/移除用戶組:技術編輯員 (techeditor)
+ 添加/移除自己的用戶組:介面管理員 (interface-admin)
+ 移除用戶組:機器使用者 (flood)
+ 添加自己的用戶組:機器使用者 (flood)
+ IP封鎖例外者
(ipblock-exempt)
+ 繞過IP封禁、自動封禁和段封禁 (ipblock-exempt)
- 開發者
(developer)
-
- 刪除執行員 -

-- NSLog(@"Hello, World!"); · · ) 2021年9月30日 (四) 22:24 (CST)

Like —— 屠麟傲血討論) 2021年9月30日 (四) 22:29 (CST)
用戶組 作用 前置條件 申請流程 除權條件
介面管理員
(interface-admin)
介面管理員 (interface-admin) 是能夠編輯Mediawiki命名空間和全站所有CSS、JavaScript頁面的用戶組,屬於萌娘百科技術系用戶權限體系。
  1. 屬於以下用戶組之一:
    • 巡查姬
    • 指令碼編輯員
    • 技術編輯員
    • 管理員
  2. 擁有以下技能:
    • 能夠處理界面消息繁簡轉換
    • 具有Gadgets的維護能力
    • 能參與全站性CSS/JavaScript類的維護
  3. 註冊時間大於等於 1 年
  4. 最近 1 年內無觸犯封禁記錄(濫用過濾器誤封及維護組成員測試機制導致的非正常封禁不在此列)
  5. 發起申請前 1 個月內未被除去長期的該用戶組,也未發起過長期的該用戶組申請(自行請辭不在此列)
擁有行政員用戶組的管理員
  1. 無需申請即可獲得該用戶組權限。
管理員(長期申請)
  1. 向行政員證明有CSS/JavaScript類頁面的維護意向或長期受理刪除/保護請求
  2. 在申請發出後,若3日內無其他管理員或介面管理員的較多反對,經行政員審核無誤後,可發放用戶組
  3. 另:該用戶組成立兩周內,此用戶組正式設立前的管理員無需申請即可授予自己不限期的介面管理員用戶組權限
管理員(臨時申請)
  1. 可直接授予自己臨時的介面管理員用戶組(小於3日),以便短期執行JS/CSS模型頁面的移動、保護、刪除等請求
巡查姬、指令碼編輯員或技術編輯員(長期申請)
  1. 向行政員證明有CSS/JavaScript類頁面的維護意向或長期受理刪除/保護請求。
  2. 在申請發出後,若3日內無其他管理員或介面管理員的較多反對,經行政員審核無誤後,可發放用戶組
巡查姬、指令碼編輯員或技術編輯員(臨時申請)
  1. 向行政員證明有CSS/JavaScript類頁面的維護意向或長期受理刪除/保護請求,並註明需要維護的內容和時間。
  2. 在申請發出後,若3日內無其他管理員或介面管理員的較多反對,經行政員審核無誤後,可發放用戶組
  1. 用戶不再屬於以下任一用戶組:
    • 管理員
    • 巡查姬
    • 指令碼編輯員
    • 技術編輯員
  2. 自行申請
  3. 超過90個自然日在萌娘百科和子站(不含所有討論命名空間)編輯次數小於3次
  4. 短時間內超過3次對CSS/JavaScript的編輯出現嚴重錯誤
  5. 進行破壞或其他嚴重違反萌娘百科政策的行為
  6. 行政員直接除權

在滿足以下條件時,降級為臨時介面管理員:

  1. 未經批准授予自己該用戶組權限
指令碼編輯員
(scripteditor)
基於多種原因,不再使用Widgets擴展提供的用戶組小部件編輯者 (widgeteditor),新建指令碼編輯員用戶組 (scripteditor),屬於萌娘百科技術系用戶權限體系。Widgets擴展可以讓正常的wikitext頁面中嵌入原始的HTML頁面,管理員和此用戶組的用戶可在Widget命名空間中創建頁面。
  1. 不屬於管理員用戶組
  2. 模板、模塊命名空間的總編輯數編輯合計超過200次或模塊命名空間的編輯總數大於50次
  3. 註冊時間大於等於 1 年
  4. 能證明充分掌握Widget的使用方法,並寫出安全可靠的代碼
  5. 有意願參與各類工具的合作編寫,並且願意、熟練使用諸如Github等管理工具
  6. 且最近 1 年內無觸犯封禁記錄(濫用過濾器誤封及維護組成員測試機制導致的非正常封禁不在此列)
  1. 滿足前置條件後即可提交申請。
  2. 若無擁有此權限的用戶(含管理員、指令碼編輯員)的明顯反對,經行政員審核無誤後,可發放用戶組
  1. 當用戶同時屬於管理員用戶組時
  2. 自行申請
  3. 超過90個自然日在萌娘百科和子站(不含所有討論命名空間)編輯次數小於3次
  4. 在對任一Widget及其關聯模板的編輯時無法充分的小心,導致出現嚴重錯誤
  5. 拒絕與其他管理員或指令碼編輯員合作,我行我素
  6. 進行破壞或其他嚴重違反萌娘百科政策的行為
  7. 行政員直接除權
技術編輯員
(techeditor)
技術編輯員 (techeditor)是被社群信任、精通複雜wikitext或熟悉Lua的用戶,可編輯保護級別為「僅允許技術編輯員和管理員 (techedit)」的模板或模塊。
  1. 不屬於以下用戶組之一:
    • 管理員
    • 指令碼編輯員
  2. 萌娘百科和子站的模板(Template)、模塊(Module)命名空間的總編輯數編輯合計超過200次或模塊命名空間的編輯總數大於50次
  3. 精通複雜wikitext或熟悉Lua,了解處理高風險模板或模塊的職責
  4. 最近 1 個月內無觸犯萌娘百科:方針#用戶封禁政策的行為
  5. 無編輯戰、人身攻擊等行為
  6. 發起申請前一個月內未被除去技術編輯員用戶組,也未發起過技術編輯員申請(自行請辭不在此列)
  1. 使用權限變更版頁頂模板的預設按鈕發出合格式的申請
  2. 申請時列出主要維護的模塊、複雜模板或其他方式以證明精通複雜wikitext或熟悉Lua
  3. 在申請發出後,若無擁有此權限的用戶(含管理員、指令碼編輯員、技術編輯員)的明顯反對,經行政員審核無誤後,可發放用戶組
  1. 當用戶同時屬於以下用戶組之一時:
    • 管理員
    • 指令碼編輯員
  2. 自行申請
  3. 超過90個自然日在萌娘百科和子站(除用戶命名空間和所有討論命名空間)編輯次數小於3次
  4. 短時間內超過3次對任一模板、模塊的編輯出現嚴重錯誤
  5. 在編輯受保護的模板、模塊時無法充分的小心,導致出現嚴重錯誤
  6. 進行破壞或其他嚴重違反萌娘百科政策的行為
  7. 行政員直接除權
導入員
(importer)
此用戶組的用戶可以使用Special:導入頁面從其他wiki導入頁面。同時,將通過技術手段限制Special:導出頁面為此用戶組及管理員可使用。
  1. 屬於以下用戶組之一:
    • 介面管理員
    • 指令碼編輯員
  2. 掌握導入功能的使用方法
  3. 註冊滿 1 年
  4. 最近 1 年內無觸犯封禁記錄(濫用過濾器誤封及維護組成員測試機制導致的非正常封禁不在此列)
  5. 有需要從其他wiki導入頁面(此類頁面通常為複雜模板、模塊或是JS、CSS等),或長期活躍於多個萌娘百科及其姊妹項目且有大量導入的需求
  1. 在權限變更版申請此用戶組
  2. 申請時寫清使用相關權限的方向(例如需要導入的內容方向等)
  3. 經行政員審核無誤後,可發放用戶組
  1. 不再屬於以下用戶組之一:
    • 介面管理員
    • 指令碼編輯員
  2. 自行申請
  3. 濫用導入者權限(包括但不限於濫用權限進行破壞、無法提供上傳導入的可查證信息或信息可信度低等)
監督員
(suppress)
(暫缺)
機器使用者
(flood)
當人類需要手動進行大量重複性、無爭議的操作時,可臨時授予機器使用者(Flood flag)用戶組。當用戶屬於此用戶組時,其編輯行為將從默認的Special:最近更改中隱藏。
  1. 需要執行部分機械而無爭議的操作時,包括但不限於大規模的文本替換、大量刪除許多由廣告機器人創建的頁面、大量撤銷破壞行為等
  2. 需要手工執行大量無爭議、機械式,且無法由自動化程序執行的工作時
管理員
  1. 可直接授予自己該用戶組
其它用戶組
  1. 在權限變更版申請此用戶組
  2. 申請時應列明工作內容
  3. 經行政員審核無誤後,可發放用戶組
  4. 當用戶屬於此用戶組時,應該只進行預先獲批准的操作
  1. 執行完所有需要機器使用者的操作後自行除去
  2. 機器使用者執行完任務後忘記取消此用戶組
  3. 機器使用者執行了理應在最近更改顯示的操作
  4. 非管理員機器使用者執行了未批准的操作,管理員可同時視情形對相關用戶進行警告或封禁,此類行為可能被視為破壞

管理員可對未及時除權的機器使用者進行除權。

IP封鎖例外者
(ipblock-exempt)
(暫缺)

-- <div>Hello World</div> · · ) 2021年9月30日 (四) 23:07 (CST)


10月3日凌晨(CST),草案進行了較大幅度的更新。—— ほしみ 2021年10月3日 (日) 02:35 (CST)

關於技術編輯員

我記得@C8H17OH大佬1年前也有一個相關草案?也許可以交流分享一下。——移動版用戶 Bhsd 2021年9月27日 (一) 17:48 (CST)

我當時只是隨便想了一下,顯然沒有星海的方案全面,包括涉及具體的MW權限的問題。我此前已經大體瀏覽過這個方案,還沒有細看(主要是具體的MW權限我也不是很懂x 得仔細研究一下)。總之按不同的類別分別建立體系(管理類、技術類、榮譽類(?)……),我覺得是好文明(有點像IT大廠的職級系統了)。——C8H17OH討論) 2021年9月27日 (一) 19:36 (CST)

關於IA

建議IA的申請不走投票,而是前置用戶組(管理、技術編輯、小部件編輯)+申請。——From AnnAngela the Bureaucrat (Talk) 2021年9月27日 (一) 17:49 (CST)

(+)同意 --Sysop 北極星南十字(注)給我留言) 2021年9月27日 (一) 21:08 (CST)
(+)同意 進行了一些小調整完成—— ほしみ 2021年9月27日 (一) 22:07 (CST)


還是關於介面管理員,建議這個群組的用戶通常只受理編輯請求而不是獨立修改站點JS/CSS,這樣大概可以增加更多具備足夠社群信任但技術能力略有欠缺的潛在申請者。——移動版用戶 Bhsd 2021年9月28日 (二) 05:54 (CST)

我覺得對於SiteJs/SiteCss/SkinJs/SkinCss這一類,確實需要事先的覆核,具體是怎麼個操作方式可以再討論。—— ほしみ 2021年9月28日 (二) 09:17 (CST)

關於導入員

導入員這個位置的定義,目前是否有其他的wiki和萌百使用相同或者兼容的版權協議?--愛吃麵包的Hooonooka討論) 2021年9月28日 (二) 10:37 (CST)

主要用於萌娘百科及其姊妹站點間的界面消息和小工具的批量同步,並且能保留原貢獻者。另外,小工具一般都是額外註明協議的。—— ほしみ 2021年9月28日 (二) 11:01 (CST)

關於小部件編輯者

鑑於widget擴展並沒有被積極維護,可能在可見的將來被替代,借用和過度依賴這一用戶組可能是不太合適的。另外單純從名字上來看我會覺得小工具編輯者被技術編輯者包含,但實際不是這樣,不夠直觀。我認為可以有『模板編輯者(templateeditor)<技術編輯者』或者『技術編輯者<腳本編輯者(scripteditor)』的其他更好表述來替代草稿中的『技術編輯者<小工具編輯者』。另外後者似乎包含所有前者擁有的權限,兩個用戶組可能沒必要/不應共存於同一用戶?--Func討論·貢獻) 2021年9月28日 (二) 12:12 (CST)

擴展自帶的用戶組確實有這個問題,隨着擴展版本變更甚至默認的用戶組命名在不斷變化,新建一個自定義的固定用戶組腳本編輯者(scripteditor)可能會是一個更好的名稱。例如使用者查核擴展在站內的實現,是將checkuser權限分配給了一個自定義的、名為checkuser的用戶組。或許也可以將editwidgets權限分配給名為scripteditor的用戶組但是,這個用戶組中文簡稱為「腳」—— ほしみ 2021年9月28日 (二) 14:21 (CST)
足控狂喜 ——拒絕互膜的M.Main user page. J.Just a chat. H.How I contributed.【復】{{#forargs:}} is evil! 2021年9月28日 (二) 14:45 (CST)

關於「3個月未活躍自動除權」

Maya對「未活躍」的定義稍微有點不明確。比如說,techeditor的未活躍條件應當是3個月內未進行僅限techeditor的編輯?未進行模板和模塊空間的編輯?未進行任何編輯?對比巡查姬的活躍條件中有對投票等具體活動的規範,這邊是不是應該也類似地細化一下呢?感謝。 ——拒絕互膜的M.More about this user. J.Just a chat. H.Heritage.【渙】{{#forargs:}} is evil! 2021年9月28日 (二) 14:53 (CST)

已補充 —— ほしみ 2021年9月28日 (二) 15:38 (CST)

關於IP封鎖例外者的小建議

雖然對這東西有些印象,自己也好像申請過維基百科的豁免,但完全不知道為什麼這個用戶組要用在萌娘百科上,關於最後的那一段也有些雲裡霧裡,希望星海姐姐能夠進一步的解釋一下(也有可能是我語文不好如果是的話就不用理我了w) 2021年9月29日 (三) 21:29 (CST)

之前的ip封禁中有些是某大學的校園網,這導致了與破壞者同校的同學無法正常使用萌百,因此IPBE的設立被提上日程。——From 月_櫻_雪 (討論) 2021年9月29日 (三) 21:54 (CST)
貌似是懂了一點,是因為有些IP封禁會導致其他正常的編輯者無法編輯是吧,果真是我語文不好w 2021年9月29日 (三) 22:12 (CST)
ip封禁會導致來自該ip的賬戶註冊、提交編輯不被允許,因此需要向被誤傷的用戶發放豁免權限。——From 月_櫻_雪 (討論) 2021年9月29日 (三) 22:41 (CST)

關於機器使用者

把群里說的發在這裡留個備忘:建議將機器使用者的發放權下放至管理員,原因如下:

  1. 機器使用者的操作為手動的機械式操作,不像機器人一樣需要審閱代碼,管理員一般可以理解;
  2. 管理員既有權為自己臨時發放機器使用者,可以認為其有能力判斷何為合適的機械用戶操作;
  3. 機器使用者的權限十分有限,且不建議非維護人員申請,故申請者將多為臨時需權的巡查姬(以及可能有少數的可信、熟練編輯者),申請者可信程度較高,不需要太多的判斷;
  4. 行政員數量少且忙碌,而如上所述這一用戶組的權力有限,故該工作可以由管理員分擔。

——C8H17OH討論) 2021年10月1日 (五) 23:22 (CST)

關於臨時權限和非公開申請

目前部分用戶組明確了申請臨時權限的事宜,部分用戶組沒有,建議予以明確。(甚至可以順道明確管理員和巡查姬不可臨時授權(巡查姬實習期除外)。)

此外,目前的方案中這些技術系用戶組似乎都需要通過權限版來申請。考慮到此前有過臨時授予個別巡查姬developer權限以處理界面消息的先例,建議規定其中部分用戶組可以由非公開申請來臨時獲取,以便於處理部分維護需求。反正用戶權限日誌都公開可見,應該不會造成什麼問題。不過所有永久的用戶組仍建議只能通過權限版申請來獲得。——C8H17OH討論) 2021年10月1日 (五) 23:22 (CST)

可能可以在MGP:行政員#行為規範一節添加「當跳過申請程序授予用戶臨時的用戶組時,應在權限變更的日誌摘要註明申請信息(如工作方向、何處申請等)。」。—— ほしみ 2021年10月2日 (六) 22:48 (CST)

關於部分權限的下放

當前對於用戶頁面部分內容應當刪除的情況時,有維護組成員採取了刪除整個頁面的決定,理由是歷史版本仍然可見該內容。我覺得這對用戶權益構成了一定問題,究其技術上的原因,是對某一具體歷史版本進行刪除需要監督員才能進行操作。如果能夠把歷史版本刪除權限下放到管理,這個問題可以得到一定的緩解,同時也能夠讓監督員這一處理隱私、審查等機密內容的權限不開放理由更加充分。

另外,當前巡查要處理站內的條目移動中,頁面移動留下的重新導向延長了部分問題的解決時間,對讀者的閱讀造成了一定影響,為了減少這種影響,可以把移動頁面不留重新導向的權限下放到巡查。—— 屠麟傲血討論) 2021年10月3日 (日) 22:28 (CST)

建議等升級MW後再討論/進行調整,當然現在討論也不是不行。可討論的有這些:blockemail(1.35+可下放),reupload,reupload-own,delete-redirect(1.36+可使用),suppressredirect,deletelogentry, deleterevision。—— ほしみ 2021年10月3日 (日) 22:37 (CST)
(☩)意見 如下兩意見:
安全性問題:權限下放的前提是對應能夠被賦予權限的人可以得到社群的充分信任,由於萌娘百科通過志願者構成維護團隊運作(沒有所謂法律約束),而相關的技術性編輯一旦出錯極易導致不可知後果。因此如何能夠評估技術人員有充分的技術能力?如何確保技術人員可以承擔附加的職責(信息保密)等問題?
開發問題:萌娘百科絕大多數的人員均是流動性的,且人員技術參差不齊,而目前萌娘百科還沒有形成一個統一的有關技術方面的認知宗旨(參見User:雲霞/論述/讓猴子也能寫萌娘百科)。由於人員水平的參差不齊和流動性,倘若下放權限,易導致技術黑箱及一些工具在權限人員離職後,後續無人維護的可能,此類情況應當如何規避?--From KumoKasumi the Bureaucrat (Talk) 2021年10月5日 (二) 22:08 (CST)
@云霞
關於安全性問題。首先,草案中的用戶組中,只有介面管理員和腳本編輯者屬於高風險用戶組,而這兩個用戶組全部由行政員進行考察並發放。基於行政員本身已獲得社群的充分信任(也同樣不是法律約束),應認為他們有能力充分考察申請者是否符合信任度條件。同樣的,申請者可以通過站內編輯歷史、站外相關信息等多種方式證明自己有相關能力,而評估申請者是行政員的職責,術業有專攻,他們可以選擇邀請其他技術人員參與評估。另外,不太明白有何信息保密問題。
關於開發問題。如果草案通過,我相信界面和腳本的技術相關肯定會比目前極其非常依賴ann的狀況會來的好,這可以帶來更多的交流合作,同時也可以更好的進行交接工作。
雖然萌娘百科不是公司,大家都是志願者,但對於用戶體驗團隊來說,內容維護類和技術類都是分別需要的,我覺得充分發揮各類人才的專長是可行性很高的。—— ほしみ 2021年10月5日 (二) 23:38 (CST)


來自行政員的修改建議

我有幾個建議,不知可否考慮一下(雖並非強制性修改指令,但下述建議基於行政員的角度提出):

  1. 出於社群信任和維護組身份的需要,介面管理員-指令碼編輯員-技術編輯員 以及濫用過濾器維護員(由於涉及界面消息,該權限建議合併至介面管理員,確保明確的三級體系) 均應在申請前都應已經是巡查姬以上(且在職30天以上)的權限。
  2. 機器使用者、導入員、IP豁免:這三個權限我認為均應該由行政員/管理員執行臨時授權(或導入員額外由技術系人員副署同意後方可執行授權)且不予常駐授權(IP豁免也應當為臨時措施)。
  3. 體系授權方面,指令碼編輯員應由介面管理員同意(或額外通過介面管理員內部的簡易投票程序),行政員審核並執行授權;技術編輯員應由指令碼編輯員或介面管理員的權限組同意後,由管理員審核並執行授權。(儘管技術系用戶組不能執行授權,但是相關申請須經技術系用戶組相應人員同意後,再由對應的人事用戶組進行二次審核並執行授權,未經技術系用戶組人員同意而進行的授權應當視為嚴重錯誤)
  4. 這三級人員的活躍度除權我不太認可(並且由於前文建議至少需要巡查姬權限),應當明確為對應的命名空間下若干自然日未見編輯則予以除權,或與巡查姬的活躍度除權一致——考慮到介面管理員的重要性,該權限的活躍度除權相對於其他兩級可以相應放寬。
  5. 考慮到保險的需要,介面管理員也不應獨立修改頁面,應在摘要註明修改內容,理由,並確保有相應的覆核手段。

以上--From KumoKasumi the Bureaucrat (Talk) 2021年10月6日 (三) 01:53 (CST)

@云霞 其實關於技術權限體系還可以有這麼幾個可選項:
  1. 合併草案中的介面管理員、指令碼編輯員、濫用過濾器維護員為新的介面管理員
    • 優點:可以形成合理的上下級體系(介面管理員>技術編輯員);可維護過濾器;能更好的進行統籌管理與合作;
    • 缺點:對申請人的信任度評價大幅增加,申請難度增加;可以查閱濫用日誌和私有過濾器的內容,涉及保密性問題;
  2. 增加介面管理員的權限使其涵蓋指令碼編輯員
    • 優點:可以形成合理的上下級體系(介面管理員>指令碼編輯員>技術編輯員),同時可要求滿足條件維護人員申請
    • 缺點:介面管理員所需的信任度條件大大增加,申請門檻變高
    • 注意:這個方案要求維護組申請,和#關於IA一節中其他行政員/管理員的意見可能完全相反
  3. 將介面管理員的editsitejs、editsitecss分配給指令碼編輯員
    • 效果:編輯全站js/css實際需要介面管理員+指令碼編輯員權限
    • 優點:大幅度提高安全性
    • 缺點:指令碼編輯員所需的信任度條件大大增加;未能形成上下級體系

其他一些相關的:

  • 分配給介面管理員有限的過濾器編輯權限:效果是可維護公有的過濾器內容
  • 關於導入員允許長期持有的解釋:批量導出導入界面消息進行維護的效率更高,導入都會留下日誌,沒什麼特別不安全的。
  • 關於IP豁免:本身即為臨時授權,應與IP封禁的時長相符。
  • 關於上級授權:由於當前版本草案沒有上下級體系,所以是要求其他同屬於當前用戶組的用戶進行判斷。若最終草案含有上下級體系,是可以由上級參與授權討論的。
  • 關於活躍度除權:可以進行討論一下是否嚴格需要對應命名空間,亦或是僅活躍即可。我個人的意見是不必要太嚴,也不需要維護組一樣的警告流程。
—— ほしみ 2021年10月6日 (三) 03:26 (CST)
  • 我認為技術編輯員不應需要巡查姬前置,因為技術編輯員僅獲得特定保護級別頁面編輯權限,無需過高的要求;對指令碼編輯員是否需要巡查姬前置不持立場;贊同介面管理員需要巡查姬前置;
  • 我贊同將濫用過濾器維護員整合至介面管理員,避免用戶組過多導致混亂;
  • 我贊同機器使用者和導入員僅限管理員臨時授權,因為其無長期持有之必要;我認為IP豁免可以保留長期授權,有其必要;
  • 我認為如果不經投票,則應當允許所有的授權均為獨任授權,副署等做法沒有必要、增加難度且容易形成變相投票;
  • 我認為活躍度除權應當將行政權限和技術權限區分開,單獨設立一個僅檢測特定頁面範圍的活躍度標準用以除去技術權限;
  • 我認為可以建立一個覆核機制,比如可以用我那個qq機器人檢測全站類代碼頁的編輯情況,發現有介面管理員編輯則通知行政員,或其他做法。
——From AnnAngela the Bureaucrat (Talk) 2021年10月6日 (三) 10:54 (CST)
結合兩位行政員的意見,進行了一次調整,參見Special:差異/5301601/5303293,簡要說明如下:
  • 濫用過濾器維護員整合至介面管理員,介面管理員的前置條件變更為巡查姬及以上(但依舊不包含editwidget權限);
  • 指令碼編輯員的申請前置用戶組沒有變更,但申請條件內已包含巡查姬、技術編輯員的部分要求,旨在鼓勵非維護組技術人員的參與維護;
  • 調整了活躍度除權條件;
  • 調整了導入員和IP封鎖例外者的授權時長相關說明;
  • 形成了介面管理員/指令碼編輯員>技術編輯員的二級體系;
  • 另建議設立類似於T:討論版目錄的頁面,顯示SiteJS/CSS和Widget的變動。同時用QQbot在相關群組進行通知。
—— ほしみ 2021年10月6日 (三) 14:12 (CST)
改動後介面管理員的活躍度要求挺奇怪的:如果沒有bug要修的話,不編輯MediaWiki空間或濫用過濾器也挺正常吧。——移動版用戶 Bhsd 2021年10月6日 (三) 15:18 (CST)
進行了一些調整。另外,我覺得編輯其他用戶的CSS/JS文件 (editusercss & edituserjs)可以升級後自定義授權給管理員,以減少管理員因為刪除用戶命名空間下這些模型的頁面而頻繁自授權。—— ほしみ 2021年10月6日 (三) 15:55 (CST)
當我沒說x 實際測試結果是沒有editusercss & edituserjs不能編輯但能刪除((( —— ほしみ 2021年10月6日 (三) 16:22 (CST)

關於論述的建議

  • 在方針/指引的形成過程中,起到最核心作用的是社群的共識,並基於社群共識制定與修訂相關成文規定。自2020年8月通過了關於方針、指引與論述的提案後,社群已經釐清了政策頁面、論述頁面與幫助頁面的關係,並且依據該規則在後續提出了諸多有關方針、指引的修正提案。但是遺憾的是,作為為方針、指引提供補充、建議、針對站內某些事項專門討論的論述頁面卻一直以來沒有太大的發展。
  • 提議區分論述的初衷即是在成文的規定之外提供行事的依據,允許表達多樣化的觀點,並且為新的方針、指引提供原型基礎。
  • 也許是由於過往的提案並未對論述的撰寫及維護等事項作出明確規定,而現有的論述又太少,因此論述長期以來一直無法起到應有的作用。
  • 因此在這裡希望各位能夠在本討論串下提出有關萌娘百科論述的一些想法,同時我也建立了User:雲霞/論述/關於論述的論述‎,以期作為後續撰寫論述的指導性頁面,亦歡迎各位參與修改完善。--From KumoKasumi the Bureaucrat (Talk) 2021年9月23日 (四) 10:55 (CST)
其實Maya一直不明白一個事兒:論述和提案到底是什麼關係? ——拒絕互膜的M.More about this user. J.Judge my soul. H.How I contributed.【恆】{{#forargs:}} is evil! 2021年9月23日 (四) 11:02 (CST)
提案可以將論述升格為指引或者方針,如重新導向。—— 屠麟傲血討論) 2021年9月24日 (五) 12:42 (CST)
Maya是說,未被升格的論述……理論上來說,是為什麼目的而存在的呢?為記錄階段性共識的話有Talk,為增加指引或方針的話剛剛說了有提案,論述所占據的位置是什麼呢…… ——拒絕互膜的M.Me. J.Just a chat. H.Heritage.【觀】{{#forargs:}} is evil! 2021年9月24日 (五) 14:30 (CST)
個人感覺是,未升格的論述是編寫者對現行方針的解讀……之類的?--MnO43- 2021年10月1日 (五) 09:45 (CST)
( ¡ )題外話 能否藉此機會順帶釐清Project與Help命名空間的關係(? —— ほしみ 2021年9月24日 (五) 12:46 (CST)
(+)同意 萌娘百科現有的論述頁面似乎是論述類和Help指導類頁面混雜利用的--From KumoKasumi the Bureaucrat (Talk) 2021年9月26日 (日) 09:53 (CST)
( ¡ )題外話 以前常有建立了論述頁面卻被打回的情況,以至於現在很多人選擇僅在用戶頁下撰寫。我認為這不符合「論述」的初衷。——From 月_櫻_雪 (討論) 2021年9月26日 (日) 10:08 (CST)

或許可以考慮建立一個關於論述的指引,給建立Project命名空間的論述設立一個簡單的機制?例如,在方針政策版塊請求大家查看,一定時間無維護人員或較多用戶反對就可以主動移動……什麼的……?—萌百假期放傻了阿巴阿巴 ᕕ(。∀°)ᕗ🎜🎝 用戶名是公的驅逐艦的 壹陸 討論·最近編輯 2021年10月10日 (日) 10:11 (CST)

我認為不應該為論述設置這種門檻,僅要求不違反法律與站點政策、與萌娘百科相關、條理清晰即可。——From 月_櫻_雪 (討論) 2021年10月10日 (日) 10:35 (CST)
我認為,在發表前後公開徵求意見是很好的做法,事實上我自己就曾在發表後(雖然是發表後而非發表前)在這個版上公告。但是,(▲)同上 不應當將其設為必要程序。
根據現行MGP:方針、指引與論述:「論述…可以不經過批准而被創造及編寫」,但是「若是…與多數共識牴觸,則應該放在用戶頁下」,據此可以認為論述與主空間條目類似,採取事後監督機制(對論述主旨有異議,可以公開提出,經社群討論認為過於偏離共識的,打回用戶子頁;或者由由維護人員直接行使打回權),而不進行事前審核。這點我認為是符合論述的定位的,不應改變。況且現在是缺論述,不是論述泛濫。——C8H17OH討論) 2021年10月10日 (日) 15:02 (CST)

是否應該減少「打回用戶頁」這一操作的適用範圍?

目前這一操作用於質量不達標,但並非毫無價值的條目,以及小部分不在收錄範圍,但質量較高的的條目。建議將這一操作僅用於後者。因爲既然在收錄範圍內,就應該允許其他人完善,而允許其他人編輯用戶頁面的子頁面容易引起混亂。

對於前者,建議建立一個專門區域用於放置這些條目,或者掛上「急需改進」而留在原地。

此外,爲了使急需改進的條目得到注意,可以在醒目區域放置指向Category:急需改進的鏈接。--蝶影書於蝶翼齋 2021年9月29日 (三) 23:59 (CST)

關於Category:急需改進,我的意見是如果這一分類內現有的頁面能夠少一位數的話,打回操作會少很多。然而正是因為該分類中的頁面過多(一千以上),新加入的頁面很難得到注意及改進。通過最近更改、移動日誌、最新頁面等途徑定期巡視新條目的畢竟是少數,因此我支持保留內容不足但具有一定價值的頁面/建立草稿空間/提高急需改進分類的利用率(可從移除已改善的頁面、補充頁面內容等方面入手)。措施一會面臨標準不一的問題,在目前的情況下可行性不高;措施二需要後台方面的配合、方針的修改,且需要編輯者達成共識;措施三可以在目前的框架內進行,不過工作量較大。——From 月_櫻_雪 (討論) 2021年9月30日 (四) 00:48 (CST)
我之前設想過將急需改進根據原因細化為需要排版、內容過少等模板/分類。很多頁面被掛上急需改進是因為內容過少,然而動畫角色等條目需要了解相關作品的編輯者來補充,其他人若不熟悉故事情節,代碼力再強也是無濟於事。而在頁面排版方面,熟練的編輯者能夠發揮出自己的能力。將急需改進根據原因細化,處理起來的效率會好很多。——From 月_櫻_雪 (討論) 2021年9月30日 (四) 00:56 (CST)
打回的本質是對不符規範的頁面的處理,我個人認為這是一種編輯者數量較少,新頁面可能長期得不到修改的情況下產生的不是令人很滿意的處理方式。既涉及了用戶子頁面的所有權,又涉及到低質量頁面的處理。我認為只有從根源改進,即減少不合規頁面的產生,這個問題才能得到有效解決。畢竟,打回是一個標準不一的操作。在我看來只是內容較少,排版並無問題的頁面可能會被其他維護組成員視為質量低下而打回。在總體改進能力不足的情況下,倘若將那些質量不高而略有價值的頁面保留在主空間,很可能的結果是低質量條目泛濫。——From 月_櫻_雪 (討論) 2021年9月30日 (四) 01:07 (CST)
如果僅僅是低質量條目過多,而高質量條目並沒有減少,應該沒什麼危害吧。--蝶影書於蝶翼齋 2021年9月30日 (四) 23:12 (CST)
危害還是有的,例如服務器資源緊張、維護組維護困難(例如批量替換)、站內搜索/查看分類時被低質條目刷屏、新讀者點進低質條目概率增加導致對萌百印象負面等。
雖然放在主空間條目被他人改善的概率更高,但是很多時候行政規定並不是單純地追求效率,而是通過獎懲對用戶的行為做出約束和引導。打回用戶頁可以視為一種基礎的懲罰手段,對用戶發出明確的警訊,讓用戶去思考他們接下來該怎麼做。——Sirogohan討論) 2021年9月30日 (四) 23:33 (CST)
(▲)附議「新讀者點進低質條目概率增加導致對萌百印象負面」和「打回用戶頁可以視為一種基礎的懲罰手段」。不過「服務器資源緊張」倒不至於,放在用戶頁面一樣占用服務器;事實上即使刪除了,頁面日誌也會保留在服務器中(管理員可見),所以這條不成立。——C8H17OH討論) 2021年10月1日 (五) 12:45 (CST)
這麼多年血的教訓告訴我們,會創建低質頁面且不掛{{施工中}}模板的編輯者們,根本不會想着去完善那些條目----新たな世界を見せてあげよう!討論) 2021年9月30日 (四) 02:53 (CST)
這一提議並不是為了等待創建者去完善頁面,而是為了方便其他人完善。--蝶影書於蝶翼齋 2021年9月30日 (四) 23:12 (CST)
那麼請問您認為有多少人有完善頁面的意願呢?就拿類似的情況來說,MGP:條目創建請求中不乏一些好久之前就掛到上面但至今無頁面的條目。不打回頁面或者專門建立一個分區的話恐怕只會像條目創建請求一樣,成為積壓工作。另外,關於用戶頁面方針的提案的討論正在進行中,您不妨參與其中發表您的看法。——飯糰人一位史蒂夫 討論·貢獻 請問您要單推一隻小浣熊嗎? 2021年9月30日 (四) 23:59 (CST)
積壓工作存在對於百科並沒有明顯的危害。條目創建請求中的積壓工作也多半是因為缺乏能力而不能創建。願意完善現有條目的人還是很多的,但並沒有人有這樣的義務。因此,任何降低便利性的方針都會損失潛在編輯者。--蝶影書於蝶翼齋 2021年10月1日 (五) 00:57 (CST)
(?)異議那你見過有誰把中文歌曲掛上去的?連外文歌都少吧。掛上去的不都是那種對創建者綜合能力要求比較高的:娘化要求有娘化圖以及具體設定,上Pixiv找是個辦法,不過最好的辦法還是編輯者自己就是個畫手;梗、用語、現實人物(含虛擬UP主)需要強大的考據力,以便在浩如煙海的資料中找尋到創建條目所需的內容,要不然根本寫不出來一個條目;萌屬性甚至可能需要對潮流、時尚之類有點了解;原型條目看起來簡單,但因為相關方針的存在,要麼具備極大的ACG作品瀏覽量,要麼對背後的文化、美學之類的內容有所了解(參考民航機),要麼就只能「消歧義化」。
其實萌百以前女性向ACG作品資料極其匱乏(像歌之王子殿下之類到現在連個最起碼的主條目的都沒有,IDOLiSH7建主條目也是相當晚的事情,A3!這類高質量女性向作品專題基本就是靠一個人「單槍匹馬」建立起來的)不也是這方面原因?畢竟本質「猛男百科」,誰去看那堆女性向作品?現在情況好了一些,估計很大一部分原因也是女性用戶占比提高了吧?--北湖3討論) 2021年10月4日 (一) 11:31 (CST)
( ¿ ) 喵喵喵?所以您想表達什麼呢?我只是拿條目創建請求進行了一個不是特別恰當的類比,如果您要就此方面與我互煮,我認為沒有任何意義。——飯糰人一位史蒂夫 討論·貢獻 請問您要單推一隻小浣熊嗎? 2021年10月6日 (三) 03:08 (CST)
(:)回應 我只是想表達很多(對萌百主要活躍用戶群體)相對冷門(比如女性向大IP)或編輯較為困難(比如網絡迷因、現實人物、原型等)的領域並不是誰有意願就可以創建和完善的,但它們又都很重要。--北湖3討論) 2021年10月10日 (日) 19:57 (CST)
(?)異議那這個現象就會創建頁面這一行為本身的意義相違背了。我創建頁面,但我不寫,讓別人來寫,這河狸嗎----新たな世界を見せてあげよう!討論) 2021年10月1日 (五) 02:24 (CST)
如果完全不寫,那麼屬於毫無價值的頁面,應該直接掛刪。--蝶影書於蝶翼齋 2021年10月1日 (五) 15:12 (CST)
@蝶影那如果只寫了一點呢?這種情況可不少見----新たな世界を見せてあげよう!討論) 2021年10月2日 (六) 09:53 (CST)
這就是咱們要討論的問題。--北湖3討論) 2021年10月10日 (日) 19:57 (CST)
好,建議更新Mediawiki以獲取建立草稿空間。在現有的情況下,我反對把低質量頁面留在主空間。——From 引夢者濁華 (討論·貢獻) 2021年10月1日 (五) 00:41 (CST)
我與上面的若干位用戶一樣反對將低質量條目保留在主命名空間。「寧缺毋濫」是萌娘百科長年以來的一條指導原則。創建新的低質條目永遠比將其改進為高質量條目要(註)筆誤簡單,潛在的編輯者中只會創建低質條目的人也遠比可能的優質編輯者要多,因此放棄「寧缺毋濫」只會導致更多低質條目的泛濫,而非促進高質條目的產生。如果您有意改變這一局面,建議先自己拿出實際行動去改善別人的被打回條目,反正現在是允許申請移回的。
當然,我也不否認現有的打回程序存在一些實踐上的問題,但如我在用戶方針提案的討論區中所說,在其他條件保持不變的情況下,我認為這個做法利大於弊,畢竟以前可是一律掛刪的,而草稿空間的引入還需要討論。——C8H17OH討論) 2021年10月1日 (五) 12:55 (CST)
萌娘百科:用戶交流用語樣板#質量低下之言:「當然,您也可以等待條目被其他編輯者在一天、一個月或者一年之後完善,不管怎樣,還請您以後不要在準備不充分的情況下貿然創建條目,創建內容質量低下的條目是對萌娘百科的瀏覽者、編輯者、甚至條目本身所代表事物的不尊重。」——C8H17OH討論) 2021年10月1日 (五) 12:57 (CST)
那麼我提議的另一方案,即建立一個專門區域用於放置質量低下的頁面如何?--蝶影書於蝶翼齋 2021年10月1日 (五) 15:12 (CST)
那就要看草稿命名空間提案什麼時候咕出來了() 目前各種方案里:
  • 急需改進還是老問題(急需改進=永遠不會被改進),我難以贊成;
  • 月櫻雪的急需改進分類細化方案其實去年「不完整」提案的時候ta就提過,難度我覺得略微有點大,雖然如果真實行起來未必有我想象得麻煩;
  • 打回後開放編輯並/或掛模板,我其實覺得值得一試,不過可能不易達成共識(主要是對修改他人用戶頁面的管理難度),正在進行的用戶頁面方針提案中也沒有採納(不過還是寫入了申請移回的程序);
  • 草稿命名空間目前看來算是比較好的方案,也符合你說的「專門區域」,不過也是需要達成共識(現在看來支持者也不少),並且大概需要發個提案制定個方針來規範其運作。
——C8H17OH討論) 2021年10月1日 (五) 15:35 (CST)
或許可以在急需改進模板自帶的分類上作改動,如存在參數「內容過少」時生成分類:內容過少的頁面,「排版混亂」時生成分類:需要排版的頁面等。這樣不需要新建模板及手動批量修改。
至於草稿空間,我建議再進行一次規模較大的討論,如果社群整體傾向支持,則開始方針的修訂工作。——From 月_櫻_雪 (討論) 2021年10月1日 (五) 15:59 (CST)
基於2014-2019年Project:頁面存廢及其子頁面的實踐,並現在急需改進的嚴重堆積問題(且如今仍然難以得到切實改善的編輯實際),對包括草稿命名空間或者恢復頁面存廢子頁面制度的方案不予看好和支持。因為僅靠新建專門區域無法解決質量低下頁面的堆積問題,且此類頁面大量堆積本身就是對相應編輯者試圖改善內容的重要阻礙(堆積的情況,本身就會使編輯者更加難以尋找其中值得改進或者自己的條目)。如果有能改善現有堆積情況的可查詢和易於改善程度的方案措施,那當然十分歡迎,但是至少應當先使該方案可以解決現有的急需改進分類的內容堆積問題,證明該方案的行之有效性,而不是再創造一個可能堆積成現有急需改進分類的情況的「專門區域」。--未濟橋姬(☯太虛之門) 2021年10月1日 (五) 16:08 (CST)
這樣來看樓上兩位的意見有一定的相似之處,關於分類細化的論述我覺得很有道理。創建專門的區域,並/或分類細化以便查詢,這兩者我都不反對,同希望能早日看到好的方案。——C8H17OH討論) 2021年10月1日 (五) 16:15 (CST)
目前關於草稿空間有一點共識是一定時間未得到改進的低質量條目會被刪除,與之前的積壓還是有區別的。——From 月_櫻_雪 (討論) 2021年10月1日 (五) 16:27 (CST)
基於現有關於用戶頁面方針的提案內打回子頁面的相關討論(萌娘百科_talk:提案/討論中提案/關於用戶頁面方針的提案#關於打回子頁面的頁面廢存的建議)來看,一定時間內未得到改進的低質量頁面被刪除這一點並未達成共識,幾乎清一色的反對——而且相應意見中與一定時間刪除對立的意見,反而是創建專門空間,也就意味着創建專門空間後,一定時間未得到改進的低質量內容同樣會被積壓起來。故,這裡暫且對「關於草稿空間有一點共識是一定時間未得到改進的低質量條目會被刪除」這一結論保持質疑。--未濟橋姬(☯太虛之門) 2021年10月1日 (五) 16:42 (CST)
這裡的反對是對刪除用戶頁子頁面而言,與草稿空間並不是一回事。被打回的頁面可以是用戶自用的內容,但草稿空間的頁面是為了轉正而創建的,二者有本質上的差別。——From 月_櫻_雪 (討論) 2021年10月1日 (五) 22:18 (CST)
(▲)與月櫻雪觀點相似:上述反對人群中,可能有部分編輯者(至少我)是因為所討論的頁面為用戶頁面而反對限期刪除,如果是在草稿空間則不反對。不過也不排除其他在該串中表達反對意見的用戶並非持此觀點。——C8H17OH討論) 2021年10月1日 (五) 22:45 (CST)
據我觀察,在前述討論串有接近半數用戶的意見反對的是「限期刪除」行為本身,除非其意見在字面意思之外還有弦外之音。不妨你們在相應討論區域內詢問調查一下,徵求一下相應發表了反對意見的用戶的意見,了解一下其反對的是限期刪除用戶頁子頁面,還是對相應內容的限期刪除行為本身?--未濟橋姬(☯太虛之門) 2021年10月1日 (五) 23:42 (CST)
我發表的「反對限期刪除」觀點旨在尊重內容創作者的勞動成果,在這種有維護需求的情況下,我同意需要限期清理這些頁面,但仍反對直接刪除有內容的頁面。如果能實現草稿命名空間的話,我不反對對該命名空間下的頁面進行定期清理,但是我認為清理不能簡單地刪除,對於那些存在實質性內容的,我還是覺得應該移動回用戶子頁面,移除對應的低質量頁面分類,或者全都歸入「長期未改善的低質量頁面」之類的分類中。低質量頁面積壓可能無法避免,我覺得細化草稿命名空間的分類是比較好的選擇。比如對於在萌百上已有專題的頁面,可以將這些頁面歸為一個子分類供相應專題的編輯者查閱(對於很多編輯比較活躍的專題,我覺得這種方法幾乎可以解決所有這些專題下的頁面問題);沒有專題的則可以按現有分類歸到對應的未完善頁面中。--SinonJZH(๑•̀ω•́๑)(討論) 2021年10月2日 (六) 03:33 (CST)
(▲)附議(+)支持 建立限時清理的草稿空間並細化分類,以引導後來的編輯者改進這些條目,(-)反對 直接刪除這些頁面。(~)補充 個人認為草稿空間如果沒有專題分類與定時清理機制的話還有可能導致空間下頁面過多且混雜而使編輯者沒有耐心看下去。就跟MGP:條目創建請求一樣--Qimi142857討論) 2021年10月2日 (六) 09:13 (CST)
( ¡ )題外話 草稿空間其實只需要後台加幾行代碼,重點在於社群意願。如有必要我會開啟相關討論。——From 月_櫻_雪 (討論) 2021年10月2日 (六) 09:22 (CST)
他力本願之術請在建立條目之前使用。雖然Maya一向反對將「我投入了多少心血啊」作為保留條目的理由,但並不意味着Maya認為「沒投入多少心血」的條目就值得放在那兒了。
至於草稿空間,Maya的態度是「只要有定期清除機制就接受」。從橋姬上面發的討論來看,共識不太支持這樣的定期清除機制,那麼目前的狀況是「不太接受」。 ——拒絕互膜的M.Maya. J.Judge my soul. H.History.【夬】{{#forargs:}} is evil! 2021年10月1日 (五) 21:03 (CST)
個人認為草稿命名空間也應該設立相關門檻。那些寫了一半但因故無法繼續完成、需要他人幫助才能補完的條目可以存放在草稿裡,比如谷井明日香因缺乏更詳細的介紹和翻譯被打回,但該條目編輯者確實提供了不少資料,後來者在此基礎上續寫能減少很多工作量。但是某些幾句話條目就還是算了。個人認為放進草稿命名空間的條目的內容底線可以參考超理/常見物質列表(註)僅作內容質量方面的參考,實際情況是此條目相關內容已被其他條目合併。關於此類細節性的操作問題,需要更集中的討論,在此不多加贅述。——分柿方橙討論) 2021年10月2日 (六) 10:12 (CST)
啊對,忘了說,我支持設立草稿命名空間,減少「打回用戶頁」的操作。至於是否應該定期清理,我不太懂站情,由你們決定吧。——分柿方橙討論) 2021年10月2日 (六) 10:15 (CST)
(…)吐槽 這麼多假名,塞氏翻譯法根本用不了啊--北湖3討論) 2021年10月4日 (一) 11:31 (CST)
聲優、歌姬等條目本來就不能用塞氏翻譯法解決,這不是假名多少的問題,而是作品名和角色名屬於專有名詞,需要一個一個拉去查這東西中文叫做什麼。通常只有對ACG整體都比較了解的人才能編寫得又快又好。——分柿方橙討論) 2021年10月4日 (一) 23:33 (CST)
畢竟查完了還要知道是哪年播的,這個對資料搜集能力的要求也不低(主要是可能有沒條目的)( ? )疑問 另外我想知道現在的機翻一般情況下有沒有專有名詞庫?--北湖3討論) 2021年10月10日 (日) 19:57 (CST)
剛才嘗試了一下修改T:急需改進,希望能使其自動產生「需要排版的條目」等分類,不過能力有限,效果並不理想,但如果修改得當應該是可以達到我所設想的效果的,即自動產生與頁面問題對應的分類。
另外,之前留意到Func的機器人有在更新萌娘百科:填寫了改進方向的條目。我認為急需改進分類同樣需要這樣的頁面。正如我之前所說,分類內積壓的大量頁面是上手修改的阻礙,在WAF尚未取消的當下,編輯者不可能一個一個頁面地打開,去看自己能做到什麼。將急需改進分類內的頁面連帶着改進方向做成列表,定能一定程度上改善當下頁面堆積的情況。這樣自然也就縮小了打回頁面的需求。——From 月_櫻_雪 (討論) 2021年10月6日 (三) 00:58 (CST)
個人感覺可以直接新建模板,這不比用if列出所有可能的理由方便(大霧——飯糰人一位史蒂夫 討論·貢獻 請問您要單推一隻小浣熊嗎? 2021年10月6日 (三) 03:08 (CST)
@月_樱_雪 萌娘百科:急需改進的條目送上。----4-0-2,20-0-4,27-2-7討論·貢獻) 2021年10月6日 (三) 16:13 (CST)
本当にありがとうございます!——From 月_櫻_雪 (討論) 2021年10月6日 (三) 17:17 (CST)

關於字詞轉換指引的修訂討論

萌娘百科:字詞轉換指引通過已半月有餘,在運行期間,本起草人發現了一些問題,下面分別介紹問題所在及修改方案:

  • 其一:轉換表使用標準一節的「使用數量」定義含糊不清,應該做出修改:
修改前 修改後
「使用數量」指主空間、模板(不含模板參數名)、萌娘百科、幫助和分類命名空間出現相關源代碼的頁面之和; 「使用數量」指主空間、模板、萌娘百科、幫助和分類命名空間出現相關用於展示的源代碼的頁面之和;
  • 其二:異體字適當保留情形較預想中的多,宜將使用標準從10個提高到20個,當前表內規則有1個將被剔除。
  • 其二:當前萌娘百科和Help兩個命名空間中標題亦遵循簡體優先原則,考慮到萌娘百科論述中可能亦含有專有名詞,因此在頁面全文轉換的標題一節補充:
修改前 修改後
主(namespace=0)及使用中文的模板(namespace=10)、模塊(namespace=828)標題命名遵循官方名稱優先原則和簡體優先原則。 主(namespace=0)及使用中文的萌娘百科(namespace=4)、Help(namespace=12)、模板(namespace=10)、模塊(namespace=828)標題命名遵循簡體優先原則;上述標題含有專有名詞的,遵循官方名稱優先原則

根據之前的指引修訂討論經驗,公示3天內未有其他問題提出即不屬於大改,進行簡單表決即可。—— 屠麟傲血討論) 2021年10月5日 (二) 19:58 (CST)

考慮到hant表過於冗長,現有的編輯請求方式難以整理好轉換規則,遂嘗試使用歷史對比功能,在help:沙盒的子頁面建立一個沙盒來編寫將要提交的版本,若有其他意見歡迎提出。另外考慮到表內規則的過度轉換問題和萌百主要使用簡體中文的矛盾,準備增加一個兜底條款,但目前沒有頭緒。—— 屠麟傲血討論) 2021年10月5日 (二) 23:31 (CST)

「萌娘百科論述中可能亦含有專有名詞」,可以給一些例子嗎 —— ほしみ 2021年10月6日 (三) 03:53 (CST)
模塊:公共轉換組的命名是不是應該算例外情況,既不遵循簡體優先,也不遵循繁體優先,否則就不能算是地區詞轉換了。--夜羽と善子討論) 2021年10月6日 (三) 17:38 (CST)
為了減少分歧,公共轉換組的命名按照英文>日文羅馬字轉寫>無繁簡區別的漢字>其他命名方式來確定優先度。這個僅在help:公共轉換組中進行規定,尚未上升到政策文件的級別。既然基本都不會「使用中文」,那麼也不能算例外情況,如果死板的規定優先中文命名,顯然不切實際。—— 屠麟傲血討論) 2021年10月6日 (三) 17:44 (CST)
您的意思是公共轉換組不使用中文,所以不能算字詞轉換嗎,公共轉換組就是公共轉換組而不是其他的東西嗎?--夜羽と善子討論) 2021年10月7日 (四) 01:26 (CST)
標題命名中,非主空間命名的「簡體優先」這個原則的前提是「標題使用了中文」,如果標題沒有使用中文,那麼自然不受指引管轄。強迫模板模塊help里的標題優先使用中文不切實際。不過我也看到了一個漏洞——官方名稱優先原則規定出了問題,已修改。—— 屠麟傲血討論) 2021年10月7日 (四) 11:36 (CST)
(&)建議 大家族模板內的紅鏈允許轉換為簡體,防止一些新用戶點擊創建時出錯。理由和未創建的分類是一樣的。—— ほしみ 2021年10月7日 (四) 14:45 (CST)
囧rz... 怎麼沒討論了..—— ほしみ 2021年10月15日 (五) 00:40 (CST)
囧rz...萌百繁簡轉換日常沒人關心。(+)支持 星海的觀點。--楓葉·萌約者·偽娘·朔太郎(Sally)·討論·貢獻·火天大有 ䷍· 2021年10月16日 (六) 19:59 (CST)
(…)吐槽 可能是這種純粹技術類的東西相對於站務和行政本來就比較冷門?之前字詞轉換指引的討論熱度就不高。另外(+)支持 星海。--北湖3討論) 2021年10月16日 (六) 23:15 (CST)
(+)支持 但好像指引里沒有明確提到是否允許轉換?看了一下找不到哪裡有寫,星海的意思是要寫進指引里嗎?--夜羽と善子討論) 2021年10月19日 (二) 00:42 (CST)
是啊( —— ほしみ 2021年10月19日 (二) 01:16 (CST)

關於用戶頁面方針的提案即將發起投票

提案發出已有兩周,我將迄今的討論和修改總結在了提案討論區,並預告將於幾天內發起投票。各位編輯者如欲開啟新的討論,希望能在近日內儘快提出。以上,非常感謝各位的關注和參與。——C8H17OH討論) 2021年10月8日 (五) 21:30 (CST)

由於出現了新的問題,提案的討論又延長了一周有餘。剛才,我已進行了第二次總結和投票預告,還望各位感興趣的編輯者加以關注,非常感謝。——C8H17OH討論) 2021年10月18日 (一) 20:06 (CST)

關於爭議內容的討論

  • 察最近三起有關爭議內容的處理過程:
  • 社群均通過投票的方式決定爭議段落的處理辦法,但基於萌娘百科:方針所規定,方針沒有賦予社群通過投票終結提案、管理員申請及彈劾、巡查姬彈劾以外的討論的權利。因此上述投票結果均不具有效力。同時此種辦法亦易於令部分編輯者通過抱團投票的方式,大量地刪除對本群體不利的內容,甚至導致整個條目的刪除。同時若有後來人不認同相關處理措施,則極易推翻前人成果。
  • 其次,此類投票極度依賴其對應的討論充分程度和參與人群覆蓋程度,其討論的充分性和投票的真實性亦無法保證(註)辯論的價值無法判斷
  • 萌娘百科專門設立萌娘百科_talk:討論版/群組資訊板塊用於鼓勵編輯者高效協作。據我所知,也因而相當一部分爭議性行為均不經萌娘百科站內的公開討論解決,亦或經過內部討論後在站內經形式性討論後解決。(本述第三條爭議處理甚至未經可檢索的站內討論即進行投票,此實為不妥)。
  • 簡而言之,此類解決方式易造成抱團投票以及意見裹挾的危險,同時又易不被承認。
一些對應的處理意見:
  • 日後要求(註)形成方針或指引爭議類內容須有引用,主語不明確,來源不明的段落使用模板:來源請求模板:誰?模板:原創研究予以標記,並鏈接到相應論述以提供幫助。
  • 對於大量爭議性內容,允許進行頁面拆分(註)形成方針或指引
  • 明確賦予(註)形成方針或指引行政或多位管理解釋爭議處理的權利(例如萌娘百科:提案規定行政員或三名管理員聯署即有權打回提案)。

望社群考慮--From KumoKasumi the Bureaucrat (Talk) 2021年10月5日 (二) 21:48 (CST)

來源請求從理論上來說是個好方向,但感覺實際執行難免出問題。什麼樣的來源是算是可信來源,什麼樣的引用不合理,應當被標記甚至刪除?而且實際上本站有很多內容(特別是這些風口浪尖的爭議內容)並無法找出傳統意義上的可信來源,比如某些內容的證據可能是某些網站的截圖、記錄等、相關標準應當予以明確,否則這經很容易被念歪。
另外也存在着有編輯頂上「來源請求」開始信口開河的可能,可能會有編輯頂上這類東西開始寫無可信來源的內容,被指責即拿出此類模板作為擋箭牌。所以說要明確的不只是前述的「可信來源」的標準。還有何種內容可以在加注相關模板的情況下被保留,何種內容即便加注相關模板也不應被保留。
最後,對於給與行政員/管理員仲裁相關爭議的權力。我認為,如若能在既定的方針/指引的框架下解決問題是最好的,不應當過於依賴這種兜底條款。畢竟兜底條款過於頻繁的被使用,會顯得既存規則體系形同虛設,對於其之後的施行也是不利的。--Sysop 北極星南十字(注)給我留言) 2021年10月5日 (二) 22:19 (CST)
提兩條意見吧。
  • 首先,(☩)帶條件反對第二條:萌百不是垃圾場、也不是專供某一部分人使用的私人空間,不應收錄針對單一主題的大量爭議性內容,個人建議對於該部分內容應明令要求刪減至一定比例內且不可拆分至子頁面中(唯一例外應為「該事件涉及多方、反響巨大(註)應由方針或指引確定準線」,此情況下原則上允許作為事件類條目收錄)。
  • 其次,個人認為應在意見中新增「原則上不允許添加任何由頁面描述爭議內容引起的二次創作(包括表情包、梗文等),除非有直接證據證明該二創內容直接參與了事態的發展(於2021年10月6日修改)」一條,以保證萌百在相關內容描述的中立和精簡。
以上。--一位普通的刺客以及他的私人郵箱 2021年10月5日 (二) 22:25 (CST)
補充一條:「所有爭議內容均當且僅當在直接關係者的子頁面/或主頁面對應分欄下介紹一遍;唯一例外為『所有在收錄範圍內的直接關係者均未有對應條目』,此時應將相關內容單獨放置在萌百內指定主空間頁面中。」。
舉個例子:爭議內容「海貓的金字塔被唯@W轟塌了」,這一條就只能放在唯@W海貓絡合物的頁面中,而不是「明日方舟/爭議與影響」、「鷹角網絡」和其他。
--一位普通的刺客以及他的私人郵箱 2021年10月6日 (三) 09:55 (CST)
個人認為:
  • 社群形成共識的過程不應濫用投票,一是難以判斷投票的有效性(即如何設定應參與投票人員範圍),二是難以選擇計票的規則(同意參與比或同意總數比?1/2或2/3?),由此會導致該投票信服度不足;
  • 爭議內容是否收錄之所以爭議巨大,主要在於其收錄標準不明。條目是否收錄有收錄範圍調整,但爭議內容沒有,且很多爭議內容都是僅涉及小部分人群,其收錄價值難以做出價值判斷。如果需要收錄,我建議應對爭議性內容的收錄標準進行明確,要形成方針或指引。
供各位參考。——From AnnAngela the Bureaucrat (Talk) 2021年10月5日 (二) 22:46 (CST)
個人認為:
  • 投票不能替代討論。在討論某些條目內容上的取捨時,只應使用非正式投票來歸納意向,而不是替代討論結果。
  • 傾向反對使用原創研究模板。此類模板可能存有潛在的、嚴重的濫用問題,可能會助長此類爭議內容的肆意增長。此外,也應規定何種來源屬於可靠來源,需要一篇明確的指引。
—— ほしみ 2021年10月5日 (二) 22:55 (CST)
(:)回應 萌娘百科不是學術論壇,因此難以明確規定何種來源不可引用,也很難通過某種指標(例如影響因子)作出評判,但是顯然萌娘百科可以禁止經查實的自我引用(即編輯者引用自己在第三方網站撰寫的內容)。同時也應當明確規定爭議內容應當引用第三方網站的鏈接以供查實,失效的鏈接予以標記,並且禁止截圖及聊天記錄等內容。
明令要求刪減至一定比例內可能會導致「幾根頭髮算禿子」的困境中,因此實際執行可能會存在困難。
關於模板濫用問題,的確存在相關的風險,例如編輯者大量引用相關模板以規避編輯質疑。但是同樣一個大量標記了未知來源及原創研究的爭議段落顯然避免了內容所造成的的誤導可能(大量的來源標記即已證明內容不可靠、站不住腳),從而規避相關可能的法務及編輯戰風險,並為後續編輯者提供改善頁面的方法。
仲裁權則是明確規定最終的保底方案,在此則是給予明確規定,而實際操作中則依然通過明文的規定解決大多數爭端。
目前相當多的爭議段落的處理均為進行頁面拆分至子頁面,因此遵照目前慣例明文規定不會有太多問題,反而若規定明確比例進行刪減的話,則會陷入幾根頭髮算禿子的困境中,同時又會留下大量爭議內容需要進行大幅刪改,可行性存疑。--From KumoKasumi the Bureaucrat (Talk) 2021年10月5日 (二) 23:03 (CST)
@云霞與其說會造成「幾根頭髮算禿子」的困境,倒不如說此舉只是在篩選真正毛多的人(並將他們單獨列出來)。--一位普通的刺客以及他的私人郵箱 2021年10月6日 (三) 09:55 (CST)
Maya要說的只有四個字:客觀視角。一個話題是否有一大堆爭議是次要的,是否使用客觀視角表述才是主要的。即使是爭議話題,若採取客觀且在收錄範圍的描述,難道不是受方針保護的嗎?有了方針背書,其他的什麼討論又如之何? ——拒絕互膜的M.Main user page. J.Judge my soul. H.How I contributed.【豐】{{#forargs:}} is evil! 2021年10月5日 (二) 23:12 (CST)
Like 儘管實際上很難做到,但作為寫過一些事件和爭議的編輯者,我覺得若有相關規範出台的話無論政策級別如何,「客觀中立」這點是必要寫入的,儘管最後大概率會浮於虛名,但至少可以標明萌娘百科對爭議頁面的看法。--Thus Spoke Sivlovski.討論」 2021年10月5日 (二) 23:45 (CST)
(▲)MJH 針對所謂爭議內容(註)爭議只是說一件事物存在正反兩方的討論,不是洪水猛獸的收錄問題,我認為尋求在客觀視角方面的改善,是比尋求制定收錄標準更好的大方向。因為對於爭議大小、影響力的判斷,會隨時空環境的變化出現很大的偏差,以前芝麻大點的破事可能在自媒體時代就能掀起一些波瀾,以後又不知道會是什麼樣,因此試圖制定一個標準並持續地踐行是很困難的。而客觀性原則雖然如 Sivlovski 所言在實踐方面同樣很難,但至少編輯們對這一概念本身有一定的共識,不會隨時空變化而改變,而且在很多情況下文字是不是客觀也很容易判斷。更重要的是,客觀性原則是關乎爭議內容撰寫質量以及讀者閱讀體驗最關鍵的要素,而不是篇幅。我理解萌百各專題大多數都是由作品或人物的愛好者來長期維護的,不喜歡負面的內容,但既然來到百科就應該遵守百科的規矩,對客觀存在的爭議內容要能拿得出平常心來看待。——Sirogohan討論) 2021年10月6日 (三) 03:08 (CST)
同為個人意見,比較籠統也沒什麼建設性:
1.建議各位有能力訪問的編輯者閱讀維基百科的知名論述zhwp:WP:投票不能代替討論,重點參考其中關於一般性投票的論述(方針指引、人事案等重大投票在本站有成文規定,故不適用於本站)。
2.如果有編輯者是看到了其他專題的投票而在沒有充分討論的前提下模仿性地開啟所謂投票程序,請注意「小馬過河」的教訓,以及「投票不能代替討論」的原則。
3.關於比較合理的專題性質討論(包括投票),個人建議觀察、參考近期虛擬UP主專題的若干議題,以及更早前中文VOCALOID專題的若干議題。此外,全站性質的相關討論(包括提案)也值得觀察、參考。
——C8H17OH討論) 2021年10月5日 (二) 23:20 (CST)
對於上述提及的那些爭議內容,產生爭議的玩家群體之間本來就帶有相當大的主觀色彩,在這種情況下,即便添加來源也無非是玩家討論的一些帖子,我覺得這樣也很難說是一種「可靠來源」。這樣的話即便引入這些來源請求模板,也很容易被直接用來寫入主觀內容或者質疑他人添加的來源是否可靠,這樣又會陷入另一種爭議中。我認為對於這些爭議內容,尤其是這種來源的可靠性曖昧不清的,應當在更大範圍進行討論,形成諸如「遊戲作品的玩家群體產生的爭議內容是否應當被收錄進條目」、「如果要收錄的話,以何種形式或何種角度收錄」這一類的共識,才是解決更細一點的個別爭議的方法。--SinonJZH(๑•̀ω•́๑)(討論) 2021年10月5日 (二) 23:55 (CST)
個人意見:
1.事實上的爭議內容,大部分是因IP官方運營失誤/遊戲嚴重bug/劇情人設崩壞等原因導致的愛好者團體衝突。事實上由於萌百很多的IP專題的編輯已經形成了編輯組,這也意味着他們或多或少的會參與到衝突當中。這個我認為如果需要描述爭議,只需要描述造成爭議的原因即可,而不一定需要描述相關愛好者團體的描述和立場。
2.這裡支持投票不能代替討論,因為投票是可以被操縱的。其他原因星海等人已經說過了。
3.目前萌百還沒有關於可靠來源的方針或論述,我是看過維基百科的可靠來源方針和維基的zhwp:Wikipedia:可靠來源/常見有爭議來源列表,但似乎維基的情況並不符合萌百的現狀,特別是維基把如知乎、b站這樣的用戶生成類內容網站的內容視為不可靠,這顯然不適用於萌百乃至國內ACGN圈子的環境。使用原創研究來源請求這樣的模版,會有濫用的風險。比如加原創研究來暗示觀點不正確的情況。
4.客觀中立我是支持的,但似乎萌百是否要客觀中立似乎並沒有達成共識。此外爭議內容需有引用,但編輯可以通過內容的選擇(和省略)而讓條目看着確實中立客觀,其實是春秋筆法這樣鑽方針空子的可能。
5. 行政或多位管理解釋爭議處理的權利,但事實上站務對於爭議內容以及爭議涉及相關的作品、角色、文化知識與一般編輯並不一定有優勢。如果處理的是站務不了解的爭議內容,或對與爭議的立場與別的編輯有衝突,會可能會發生不可預知的衝突。
故我認為可以應該先定義什麼是爭議內容,什麼爭議內容可以在萌百被收錄,還有對中立客觀在萌百對定義,再討論如何編輯處理爭議內容。另外可能還需要一個論述,以消除部分編輯對於相關爭議/炎上導致的對條目發生編輯戰/破壞的憂慮。--愛吃麵包的Hooonooka討論) 2021年10月6日 (三) 02:29 (CST)
(:)回應 中文維基百科執行「可靠來源」政策(參見zhwp: Wikipedia:可靠來源),即「維基百科的條目應該採納可靠的已經出版的來源」,然而對於萌娘百科來說,絕大多數的信息並非來自「已經出版的來源」,更遑論其可靠性。
同時,上述zhwp:Wikipedia:可靠來源/常見有爭議來源列表是中文維基百科的論述而非指引,換言之中文維基百科也只能對信息來源可靠性提供參考性的意見而非明文規定,同時中文維基百科也承認許多條目都不會滿足「可靠的已經出版的來源」這一標準
zhwp:Wikipedia:可靠來源/常見有爭議來源列表本身而言,主要通過「內容農場」、「用戶提供內容」、以及「鮮明的政治立場」三個特徵判定信息來源的不可靠性,而萌娘百科的信息來源除去少數新聞和公式站點外,大多來自「內容農場」、「用戶提供內容」兩個信息源,這是萌娘百科的特徵所決定的。
目前認為在現在的狀況下,對於爭議內容,萌娘百科應該優先提倡「可供查證」(擁有來源)而非「可靠來源」(擁有的來源是否可靠)。即對於爭議內容提倡甚至要求(註)形成方針或指引優先對於相關信息能有注釋鏈接至第三方的信息源,在擁有信息源的基礎上考慮信息來源的篩選問題。而對於「可靠來源」的討論目前來看較難達成方針或指引性的共識,但可以通過論述的形式提供意見。而強調優先「可靠來源」則可能是相當一個時間之後才能執行的政策--From KumoKasumi the Bureaucrat (Talk) 2021年10月6日 (三) 03:20 (CST)
個人觀點:
  1. 這三次開票顯示出了一些不同的問題。在原神的投票中,出現了持有票權者/應參與投票者不明晰的問題(票權和參與率均無規定)。未定的投票未經過任何討論(無論站內站外)。這某種意義上是站內討論缺失的結果,我認為此類共識即使最終要以投票來產生結果,也應應用與提案類似的票權規則:【參與討論的自動確認使用者】每人1票,【維護組】每人1票。以簡單多數決定結果。
  2. 這裡多提一句,方針在投票形成共識這一問題上有所缺失(或者說根本在形成共識這一問題上就是缺失的),既未禁止亦未允許,希望以後能完善相關政策。
  3. 恕我(-)反對 有大量爭議即可開子頁面這種行為,如果維護組不花精力去跟進監管,只會形成一個無人處理的垃圾場(參見Bilibili/爭議與影響)。另外建議將爭議頁面的處置與解釋權給予整個維護組,必要時我認為可以進行維護組內的投票。
  4. 最後一點,我認為某些爭議,例如這次舉到的三個例子,完全屬於「玩家社區內容」,依現行方針根本不在收錄範圍之內。——From 引夢者濁華(討論) 2021年10月6日 (三) 10:12 (CST)
(+)支持 玄微子的看法,事實上應該先討論在決定存廢,就像正常條目的存廢討論程序那樣。
有三種處理方法:保持現狀、刪除或移入子頁面。但應該還有第四種處理,保留條目但重寫內容。--愛吃麵包的Hooonooka討論) 2021年10月6日 (三) 11:52 (CST)
(+)帶條件同意 前三條(+)支持 ,最後一條三個我都看了一下,起因應該都是官方的運營事故,而不是純粹的玩家論壇撕逼。--北湖3討論) 2021年10月7日 (四) 15:27 (CST)
(+)帶條件同意 同上。我認為,這些爭議起因在官方,處理結果的也是官方,而且確實對官方態度和遊戲發展有着重大影響,因此也可以視作重要歷史事件或遊戲發展進程,根本就不是"完全屬於玩家社區內容",把它們定義為只是玩家在撕逼然後說不在收錄範圍內確實是在刪除很有意義的內容。——憨憨給學生戒網癮(前來故意找茬⟪討論⟫爆破 )(劈過的瓜⟪貢獻⟫) 2021年10月16日 (六) 20:02 (CST)給學生戒網癮
(+)同意第三條說說對Bilibili/爭議與影響這個頁面的看法。由於開頭大段導語比如「即便在秉承着「客觀中立的撰寫原則」的情況下,B站的運營歷史中仍然充斥着大量飽受爭議的事件,甚至可以說是劣跡斑斑」充滿編輯者主觀情感傾向,很明顯在激發閱讀者的負面情緒,下面的評論區也完全是傾倒用戶不滿的垃圾場。這個頁面甚至比對B站本身的介紹還多,子頁面中套着多個子頁面,不僅偏離方針要求的「客觀中立」(雖然前面也談到「客觀中立」是極為困難的),確實有必要處理,當然首先應避免之後也出現類似子頁面其他垃圾場。—— 哥的金剛杵討論) 2021年10月16日 (六) 22:19 (CST)
個人感覺這些東西可以扔去那個「TNO世界線的萌娘百科」,畢竟那邊用來收錄這種東西再好不過了--假面騎士01討論) 2021年10月15日 (五) 19:46 (CST)
不想它們被翻出來做光子嫩膚的話,還是不要這麼做的比較好。--一位普通的刺客以及他的私人郵箱 2021年10月15日 (五) 20:03 (CST)
@假面骑士01警告:我們在討論自己的社區規範問題,別的網站愛咋地咋地。如再在公共討論區發表此類與正在進行的話題無關的無意義內容,將可能導致你被封禁。——巡查姬 C8H17OH討論) 2021年10月15日 (五) 21:20 (CST)

@C8H17OH那我的態度就是一個不留的全部清掉,我已經受夠這些東西了,打個遊戲還要混圈的???--假面騎士01討論) 2021年10月15日 (五) 22:33 (CST)

(&)建議 關於爭議內容的編寫,我認為可以效仿zhwp:Wikipedia:用戶頁#我的用戶頁上不可以放什麼內容?的第12條處理。這是我根據相關內容給出的一些建議:

對於爭議相關的愛好者團體的反應可以使用有限的文字簡單地宣告一次,例如愛好者團體對爭以的觀點、立場等。但不可以為相關觀點、立場進行論述。
被禁止的行為,就是已經脫離了上面「簡單地宣告一次」的規定,進而:
重複述說對某個爭議內容相關的某觀點、立場、語句聲明(例如XX就是個屑),不論是否在同一頁面還是在多個場合(例如用戶頁、討論版)。
為該思想、立場進行論述,例如假設某用戶開始解釋說明「XX角色的惡行」,或是某用戶引經據典試圖證明「XX作品垃圾」。
開始作出發揮該觀點或立場的行為,例如為對某個條目添加無意義內容來表示對該觀點或立場的支持。
大量引用(或摘錄)包含該觀點、立場的文章、報導、作品、社交網站內容等,不管相關網站版權是否和萌百兼容。

我還想提醒萌百的各位,我覺得在萌百,排除政治立場和民族認同,我們的首要身份是萌娘百科的編輯,而不是某個作品/角色/文化的愛好者。
此外我還想建議,萌娘百科:免責聲明的第一條添加以下以下內容:「萌娘百科部分內容可能被一些讀者視為褻瀆或具冒犯性。萌娘百科不能保證條目內容符合某些ACGN愛好者團體的觀點或立場。」--愛吃麵包的Hooonooka討論) 2021年10月16日 (六) 07:36 (CST)

(+)同意 但這個有點困難--假面騎士01討論) 2021年10月16日 (六) 13:17 (CST)
恰恰相反,我認為大多數編輯者首先是是某作品/角色的愛好者,才能將愛好轉變為萌娘百科相關主題的編輯者。可能您「完全中立」的出發點,就萌娘百科這一社區來看,存在不小的問題 —— ほしみ 2021年10月16日 (六) 15:05 (CST)
所以我的建議是不要在萌百寫這種東西,要寫去其他地方寫(這裡的「其他地方」無任何暗示,請巡查同志不要找我麻煩)--假面騎士01討論) 2021年10月16日 (六) 15:47 (CST)
@星海子這個確實,考慮到萌百的很多IP已經專題化,而不參與相關IP爭議的專題編輯組成員幾乎不存在。另外有人也提到了B站爭議的問題,有人提到B站爭議的作者對萌百的態度問題,如果被削除鬧不好會出現對B站參與爭議條目的惡意推定問題(雖然我也認為B爭議有對萌百的影射,但作者確實是想改善萌百),恐有算舊賬的問題。說實話真不知道怎麼處理了。--愛吃麵包的Hooonooka討論) 2021年10月16日 (六) 18:58 (CST)
「簡單地宣告一次」這一點是好的,我覺得可以考慮列入方針。什麼時候能把那個B站爭議的頁面揚咯?
但是,絕大多數的萌娘百科編輯者,首先是某某作品的愛好者,然後才會成為編輯者。我很早之前在獸娘動物園2相關討論里也說過類似的話。--Ceba討論) 2021年10月16日 (六) 23:22 (CST)
關於揚頁面的事,我看很困難,畢竟在那之前我們都不敢設想有「敢大張旗鼓出來拉人的垃圾場」過--一位普通的刺客以及他的私人郵箱 2021年10月17日 (日) 00:23 (CST)
(…)吐槽 ( ? )疑問 那幾個頁面(勉強算一個專題了)應該算是惡俗系在萌百的最後「重要據點」了吧?--北湖3討論) 2021年10月17日 (日) 19:05 (CST)
@Ceba_robot獸娘2的情況其實不會影響中立客觀的,因為獸娘2因為製作組內鬥而風評不佳是多數觀點,而且有普遍接受的參考文字便可很容易地證實它。雖然可能根據萌百三大宗旨第一條獸娘2的動畫版是收錄存疑的,但可以用不墨守成規來解釋。
@刺客王边城和@北湖3說實話這個問題最麻煩其實還是參與相關條目的編輯的處理問題,對他們強行封禁就是用惡意推定去應對惡意推定,而且考慮到作者對萌百的態度,從去年有人發起弗林凱彈劾案的情況來看,很多的萌百編輯是不希望翻舊賬的。另外,即使是維基百科,也沒有說明通過網絡暴力等犯罪所獲取的來源是否是為可靠來源,所以這個問題據我目前了解的wiki網站是沒有沒有判例的。恐怕刪除條目容易但處理相關編輯難。--愛吃麵包的Hooonooka討論) 2021年10月19日 (二) 14:09 (CST)
@Hooonooka還能怎麼處理,等條例一過就明令他們參與整改唄;至於現在不討論到時候逼逼賴賴的,再處理也不遲。--一位普通的刺客以及他的私人郵箱 2021年10月19日 (二) 14:16 (CST)

就對未成年用戶及其家長的相關論述展開意見徵集

雲霞佬的關於論述的建議讓我感觸頗深。據Mobtech2019年12月統計顯示,中國大陸的二次元用戶中18歲以下人群占比19.3%。考慮到萌娘百科的現狀和參考其他百科的情況,我認為,撰寫一份對於未成年用戶和其家長的建議性論述是有必要的。當然了,這份論述主要面向的是年齡層較小的未成年用戶,我認為主要應當涉及的方面也是保護個人信息、理性思考、學會在現實世界中找平衡、家長指引等方面。儘管之前我和玄微子[更多]對話頁貢獻上傳歷史封鎖及歷史被刪貢獻移動日誌巡查日誌使用者權限及日誌使用者查核已經在User:Sivlovski/沙盒#MGP:致未成年與家長們撰寫了一部分,但我認為這份論述依舊有更多可以挖掘的價值,故希望諸位能夠發表一些建設性意見或是直接上手更改,以便將這份論述完善後移動至MGP命名空間。

以上。--Thus Spoke Sivlovski.討論」 2021年10月23日 (六) 18:26 (CST)

Like 在近期出現多次疑似未成年人暴露個人信息的事件後,我也萌生了類似的想法,沒想到西弗和濁華已經寫了出來,深表讚賞。
通讀下來,對於給未成年用戶的建議部分,我覺得已經相當不錯(甚至其實可能並不只是未成年用戶受用)。
至於給家長的致信部分,總覺得可能還欠點東西,目前的部分我覺得略微有些拔高萌百的作用x(因為其實確實還是可能沉迷和影響現實生活的),我覺得對於家長可能更多的是需要勸導他們接受孩子的興趣和與孩子們溝通,畢竟家長們可能是認為動漫百害無利的,我們應該做的不是全盤否認其害,而是闡述其利、解答過當的疑慮、和告訴他們儘可能規避確實存在的害處的方法。不過說了這麼多,其實我也沒有具體的怎麼寫的想法,還望大家繼續共同探討。
——C8H17OH討論) 2021年10月23日 (六) 21:43 (CST)
( ? )疑問 大部分監護人可能不知道如何使用wikitext語法編輯與在討論版上留言,監護人使用與被監護未成年人相同的賬號編輯話題時也有可能產生一些誤會(可以考慮監護人使用分身賬戶?),甚至可能有一些較為偏激的監護人使用被監護人的賬號進行破壞,儘管他們可能並不懂wikitext?--這裡,是我。討論) 2021年10月23日 (六) 22:12 (CST)
Like 不過我覺得家長的部分,「我們不是壞人」和「不太好的內容」這兩個標題非常坦誠,但是可能也太老實了,容易一下子引起家長過度的警覺。我覺得對家長的解釋部分可以將重心放在「能給孩子帶來什麼」(也就是利)和「請您注意什麼」(也就是弊)兩部分。利的部分還可以稍微結合網絡百科文化來談(我自己多年前作為未成年人編過百度百科和維基百科,編百科對信息整理能力和說明文寫作能力的鍛煉我是有感受的)。弊的部分則以推薦給家長的指引、指示為主,類似操作說明書一樣。另外,也可以鼓勵家長和孩子一起思考條目的編寫邏輯,或是對不良內容一起舉報。——Sirogohan討論) 2021年10月23日 (六) 23:48 (CST)
Like 寫得非常好,已經在頁面里貢獻了一些內容--From KumoKasumi the Bureaucrat (Talk) 2021年10月24日 (日) 00:11 (CST)
Like 好活。但是是不是也應該多加一點鼓勵的內容?—— 冬月下的二重奏 LUO1P 2021年10月24日 (日) 00:26 (CST)
(+)同意 重新審讀了下,內容很棒,不過似乎「不要做什麼」的篇幅占了有點多,多一點鼓勵或者引導性質的內容會更好--From KumoKasumi the Bureaucrat (Talk) 2021年10月24日 (日) 00:38 (CST)
稍微想了下該從哪下手。
  1. 維基語法有些勸退。看看編輯指南講語法那一章就知道有多少人會止步於此。我的建議是用一個例子:學期開始的時候看期末試卷看不懂,學期末再看也沒有那麼難。更何況寫萌百相當於是開卷。
  2. 害怕自己寫不好。我自己開始編輯的時候就是這樣的,年紀挺小,害怕自己寫的不如意參考了四五個條目,最後還在評論區里發什麼第一次寫不好請見諒之類的(然而還是被罵了)。建議是讓他們在方針允許情況下放開膽子寫,錯了會有人來幫你改正,不過以後就不見得了。
想就只能想出來這兩個了,手錶碼字不好整。早上再總結下常見新手問題吧。如果大家有補充歡迎掛在下面。—— 冬月下的二重奏 LUO1P 2021年10月24日 (日) 01:16 (CST)
Like 讓我想起來了過去的一些趣事兒。--Ceba討論) 2021年10月24日 (日) 00:52 (CST)
Like 好活!雖然某些地方的用語還能再改上一改,但這是個很好的開始,不是嗎。——Jacklin612 ·🧾 2021年10月24日 (日) 01:51 (CST)

感謝各位的支持和實際作出的建議與修改。首先,我必須要向各位致歉,因為我起初並未料到這份論述可以有如此大的關注度,因此我只是放在了個人沙盒,目前我已將相關內容移動至單獨的用戶頁面U:sivlovski/temp並添加了「致謝」一欄以在論述移動至MGP命名空間後標明參與意見提出與內容編寫的編輯者。再次在這裡說一聲抱歉!

除此之外,我還做了一些修改:

  • 調整了小標題1.1,因為我認為英文原文並不是必要的。
  • 參考上文雲霞和LUO1P的建議,新增#積極學習一欄。

關於致家長們部分,我自己也的確認為這部分我寫的不是很好,一個處男怎麼能寫的來這種東西呢。因此,我在考慮或許可以將這部分內容先劃出,優先創建面向未成年人的論述。當然,如果諸位有更好地修改建議,也可以直接上手擴充相關部分的內容。

以上。--Thus Spoke Sivlovski.討論」 2021年10月24日 (日) 18:56 (CST)

Like 看了一下草稿,敝人認為可以在「致家長們」這一章節簡單介紹下ACGN文化,畢竟國內不乏有些較偏激的家長對這方面存在刻板印象。--森雨次世Senyucishi手啟·talk·contributions 2021年10月24日 (日) 19:30 (CST)

考慮到致家長部分撰寫難度較高,且將家長和未成年部分合併在一起也不是很符合中國大陸家庭關係現狀(你會和你媽一起看動畫嗎?),我暫時將致家長部分剝離,以致未成年部分為完稿,目前該論述MGP:致未成年業已在行政員云霞[更多]對話頁貢獻上傳歷史封鎖及歷史被刪貢獻移動日誌巡查日誌使用者權限及日誌使用者查核審閱後移動至MGP空間。

再次感謝各位提出的建議和直接進行的修改!辛苦了!--Thus Spoke Sivlovski.討論」 2021年10月26日 (二) 23:49 (CST)

已經正式將該論述升級為站點論述MGP:致未成年--From KumoKasumi the Bureaucrat (Talk) 2021年10月26日 (二) 23:48 (CST)
問題已解決。
您仍可以繼續在本模板上方回覆,但這個討論串將會在本模板懸掛滿3日後 (於2021年10月30日凌晨) 存檔。
如果您有有關疑問,建議您開啟一個新的討論串
——Thus Spoke Sivlovski.討論」 2021年10月26日 (二) 23:49 (CST)