2023年政策修订增补工作正在进行中，欢迎参与！
萌娘百科討論:討論版/方針政策/存檔/2021年10月
討論版【方針政策】檔案館
20
21
22
23
24年
為用戶頁面方針草案徵求意見
前情提要：萌娘百科_talk:討論版/提問求助/存檔/2021年08月#關於「用戶沙盒」的定義；萌娘百科_talk:討論版/方針政策/存檔/2021年08月#關於用戶沙盒相關方針的修訂草案（徵求意見）
之前在重寫用戶沙盒政策草案時就有擴展至重寫整個用戶頁面政策的想法，正好前一段時間連着處理了幾次未經允許修改他人用戶頁面的問題（包括一個被我挑起來的x），這兩天整理了一下思路和經驗，寫出了一篇草稿：User:C8H17OH/Drafts#萌娘百科:用戶頁面方針，之前的用戶沙盒政策草案也就合併進去了。
這個方針草案相比現行MGP:方針#用戶頁面政策主要有有以下改進：
- 優化了對用戶頁面內容的禁制的表述，與MGP:方針#頁面管理政策等段落中已有的更詳盡的規定銜接，保留了其他方針中未提及的兩點；
- 刪去了在MGP:討論區管理方針中已有詳細規定的用戶討論頁政策；
- 大幅細化了「未經許可不應無故修改他人的用戶頁」的規定以便在實踐中執行；
- 其中，（雖然地方不一定合適，不過還是）放入了之前與Func、星海、橋姬討論時擬定的「申請修改被打回頁面」的程序；
- 細化了用戶沙盒政策，詳見此前的討論；
- 補充規定冒充其他用戶為破壞行為。
寫得很草率而且是閉門造車，一些細節上主要是憑我自己的經驗來的，故再次在討論版徵求意見，請各位賜教，感謝。—— 在隔壁權限版意外被cue的C8H17OH（討論） 2021年9月17日 (五) 15:38 (CST)
- 用戶沙盒相關草案中，第二條頁面位置「用戶沙盒應創建在用戶本人的用戶頁……」和第五條容錯「在不違反其他政策規範的前提下，原則上允許用戶沙盒存在內容、格式等錯誤，但是以下情況除外……將用戶頁本體用作用戶沙盒」似乎有所矛盾。此外個人認為將用戶頁本體用作用戶沙盒這一容許條款本身並不合適（因為有用戶使用不存在用戶/分身用戶的用戶頁進行破壞等違反方針的案例在先，個人對此還是有顧慮的）。--Qaolp0 (討論)「夜空を旅しよう。」 2021年9月17日 (五) 19:05 (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)
- 加了一條之後忘了調整序號了，
感謝。 - 這點的話是基於我此前的一次經歷：有位比較新的用戶修改了另一用戶的用戶頁，給用戶框用表格排了版，我注意到之後去詢問了修改者是否得到授權，修改者承認沒有並去給頁面所屬用戶道了歉，頁面所屬用戶沒有責怪，並感謝了ta的排版，最終以我的提醒結束。（以上均為站內公開討論）
- 對照着闡述一下：首先，上面的修改能明顯看出是善意修改，既然是善意的修改那我覺得可以不必立即回退，由維護人員、修改者、頁面所屬用戶三方溝通解決更好，包括回退可以交給頁面所屬用戶自行決定，如果頁面所屬用戶還在活躍的話。
- 其次，本站不少編輯者會採用私下交流和授權的方式，而且很多時候他們不會記得去掛模板或者在摘要里寫上，尤其對於比較新的用戶，很多時候在詢問前確實難以得知是否是授權修改，萬一錯怪也不好。而且這一詢問操作本身也是一次提醒和「普法」的過程。
- 這裡我擬定的流程總體上給維護人員留下了很強的靈活性，包括比如說「無法判斷是否……」其實可以用任意方法判斷，善意推定也可以按處理此事的維護人員自己的思路來推定，總的來說我傾向於不設置過於死板的程序，發揮維護人員的主觀能動性。這樣吧我去把詢問程序改為可選的環節，避免在這裡過於約束手腳，使習慣一律先行回退再進一步處理的維護人員能免除疑慮。——C8H17OH（討論） 2021年9月17日 (五) 23:25 (CST)
- 加了一條之後忘了調整序號了，
- 「用戶頁面不應添加任何分類」似乎有一點問題，感覺應該是不應存在非維護性分類（？
- 另外，我覺得還應該增加一條，除Gadgets等維護需求外，不允許用戶頁面在其他命名空間嵌入使用，包括但不限於以
{{}}、templatestyles等形式嵌入。—— ほしみ 2021年9月17日 (五) 20:36 (CST)
了解 那就改成除了允許的分類以外都不允許吧（廢話？和模板的「不允許使用不允許使用的模板」正好對上x）。——- 「用戶頁面內容的禁制的表述」的內容，是否應該添加「對萌百用戶以及萌百收錄的條目所介紹的人物/作品/文化的人身攻擊和辱罵，不管他們在大眾的口碑如何」？我認為由於萌百區別於其他網站，這個也應該屬於違規內容。--愛吃麵包的Hooonooka（討論） 2021年9月18日 (六) 12:26 (CST)
- 在MGP:方針#頁面管理政策和MGP:方針#破壞行為中已存在對所有頁面內容的禁止性規定，其中已包括人身攻擊、辱罵、地圖炮等，用戶頁面不需要有比所有頁面更嚴格的規則。——C8H17OH（討論） 2021年9月18日 (六) 17:21 (CST)
- (…)吐槽 您這問題已經（無端）糾結超過半年了，可以消停下了吧。——このLegend frogもガンバラナイト 2021年9月20日 (一) 07:37 (CST)
Legend frog- ( ¡ )半個題外話：對於被打回用戶頁的條目以及用戶用作條目草稿的用戶沙盒頁，是否有可能專門建立一個模板來統一標識，並且像施工中模板那樣設置一個最後編輯時間的計時以及在多久後需要維護人員進行處理。並且可以考慮利用這個模板將這些草稿頁面列入維護性分類中（比如
[[Cat:用户正在撰写的草稿]]以及[[Cat:用户长时间未编辑的草稿]]之類的）以便於維護。更進一步，有沒有可能通過技術手段防止添加了這個模板的頁面中的其他分類生效呢？--SinonJZH(๑•̀ω•́๑)(討論) 2021年9月19日 (日) 22:16 (CST)
- 挺好的建議，是值得討論的話題；不過因為暫時沒有共識，我覺得在方針里先不需要急着規定。
- 在上次用戶沙盒方針徵求意見時，月櫻雪曾經提過「可以建立一個用於標記被打回頁面的模板」，我覺得值得一試，不過似乎還沒有得到廣泛認可。關於被打回頁面的爭論，還可以看一下上月底的討論。此外，星海提出的引入Draft空間的設想也值得進一步研究。
- 至於非打回頁面的用戶沙盒，我認為不適合大規模掛模板，如果限定在只在有錯誤的頁面掛還好一點，不過我還是傾向於反對，原因在於：1.會增大維護負擔（主命名空間的CAT:積壓工作還干不完呢x）；2.有點干涉用戶頁面自由的感覺，增加了一個並非用戶原本想顯示的模板；3.對於本就不太懂代碼和/或站務的非熟練用戶，可能會造成更多的理解困難甚至驚慌。
- 防止分類生效大概只能從MW系統方面入手，一個分類應該是沒法消去另一個分類，除非是用模板添加的；要搞的話可能用「用戶命名空間的分類一律無效」這樣的邏輯更方便？這裡我用「技術措施」一條預留了空間
（其實也是用來催更x），看技術人員後續的措施吧。 - ——C8H17OH（討論） 2021年9月19日 (日) 23:06 (CST)
- 如果能夠引入草稿命名空間的話確實能夠比較好的解決這一系列問題，而對於非打回頁面的用戶沙盒，我覺得可以把懸掛模板作為一種推薦措施，這樣在沒有草稿空間的情況下可以通過分類的方式統一管理和查找。同時懸掛模板也可以解決當前方針中禁止編輯他人用戶頁的問題。對於這一類懸掛了草稿模板的條目，可以加一個允許其他用戶編輯的選項，這樣其他用戶也可以查看現在仍然處於草稿狀態的頁面並作出改進。特別地，我覺得對於被打回用戶頁的頁面，應當默認允許所有人進行編輯（即與普通條目一樣），並且允許後來的編輯者改進後直接將條目轉正。在您提及的上個討論中，似乎對於被打回頁面的編輯權限問題並沒有討論出明確的結果，我覺得在這方面還是需要明確一下的。
- (～)補充 是否可以增加「用戶可以不經申請直接掛刪自己的用戶頁」的條款？這樣可以減輕一些維護組的負擔，同時在處理用戶頁刪除上更加高效一些。--
- 提案已經發起多日。——--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) |
- |
| - | |
| - | |
| - | |
| + 編輯保護級別為「僅允許技術編輯員和管理員」的頁面 (techedit) | |
| + 導出頁面 (export) | |
| + 添加/移除用戶組：技術編輯員 (techeditor) | |
| + 添加/移除自己的用戶組：介面管理員 (interface-admin) | |
| + 移除用戶組：機器使用者 (flood) | |
| + 添加自己的用戶組：機器使用者 (flood) | |
| + IP封鎖例外者 (ipblock-exempt) |
+ 繞過IP封禁、自動封禁和段封禁 (ipblock-exempt) |
| - (developer) |
- |
| - |
- |
-- NSLog(@"Hello, World!");（查 · 論 · 編） 2021年9月30日 (四) 22:24 (CST)
屠麟傲血| 用戶組 | 作用 | 前置條件 | 申請流程 | 除權條件 |
|---|---|---|---|---|
| 介面管理員 (interface-admin) |
介面管理員 (interface-admin) 是能夠編輯Mediawiki命名空間和全站所有CSS、JavaScript頁面的用戶組，屬於萌娘百科技術系用戶權限體系。 |
|
|
在滿足以下條件時，降級為臨時介面管理員：
|
| 指令碼編輯員 (scripteditor) |
基於多種原因，不再使用Widgets擴展提供的用戶組小部件編輯者 (widgeteditor)，新建指令碼編輯員用戶組 (scripteditor)，屬於萌娘百科技術系用戶權限體系。Widgets擴展可以讓正常的wikitext頁面中嵌入原始的HTML頁面，管理員和此用戶組的用戶可在Widget命名空間中創建頁面。 |
|
|
|
| 技術編輯員 (techeditor) |
技術編輯員 (techeditor)是被社群信任、精通複雜wikitext或熟悉Lua的用戶，可編輯保護級別為「僅允許技術編輯員和管理員 (techedit)」的模板或模塊。 |
|
|
|
| 導入員 (importer) |
此用戶組的用戶可以使用Special:導入頁面從其他wiki導入頁面。同時，將通過技術手段限制Special:導出頁面為此用戶組及管理員可使用。 |
|
|
|
| 監督員 (suppress) |
（暫缺） | |||
| 機器使用者 (flood) |
當人類需要手動進行大量重複性、無爭議的操作時，可臨時授予機器使用者(Flood flag)用戶組。當用戶屬於此用戶組時，其編輯行為將從默認的Special:最近更改中隱藏。 |
|
|
管理員可對未及時除權的機器使用者進行除權。 |
| 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. J. H. 【復】{{#forargs:}} is evil! 2021年9月28日 (二) 14:45 (CST)
關於「3個月未活躍自動除權」
Maya對「未活躍」的定義稍微有點不明確。比如說，techeditor的未活躍條件應當是3個月內未進行僅限techeditor的編輯？未進行模板和模塊空間的編輯？未進行任何編輯？對比巡查姬的活躍條件中有對投票等具體活動的規範，這邊是不是應該也類似地細化一下呢？感謝。 ——拒絕互膜的
- 已補充 —— ほしみ 2021年9月28日 (二) 15:38 (CST)
關於IP封鎖例外者的小建議
雖然對這東西有些印象，自己也好像申請過維基百科的豁免，但完全不知道為什麼這個用戶組要用在萌娘百科上，關於最後的那一段也有些雲裡霧裡，希望星海姐姐能夠進一步的解釋一下（也有可能是我語文不好如果是的話就不用理我了w）
2021年9月29日 (三) 21:29 (CST)
- 之前的ip封禁中有些是某大學的校園網，這導致了與破壞者同校的同學無法正常使用萌百，因此IPBE的設立被提上日程。——From
月_櫻_雪 (討論) 2021年9月29日 (三) 21:54 (CST)
關於機器使用者
把群里說的發在這裡留個備忘：建議將機器使用者的發放權下放至管理員，原因如下：
- 機器使用者的操作為手動的機械式操作，不像機器人一樣需要審閱代碼，管理員一般可以理解；
- 管理員既有權為自己臨時發放機器使用者，可以認為其有能力判斷何為合適的機械用戶操作；
- 機器使用者的權限十分有限，且不建議非維護人員申請，故申請者將多為臨時需權的巡查姬（以及可能有少數的可信、熟練編輯者），申請者可信程度較高，不需要太多的判斷；
- 行政員數量少且忙碌，而如上所述這一用戶組的權力有限，故該工作可以由管理員分擔。
——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)
來自行政員的修改建議
我有幾個建議，不知可否考慮一下（雖並非強制性修改指令，但下述建議基於行政員的角度提出）：
- 出於社群信任和維護組身份的需要，介面管理員-指令碼編輯員-技術編輯員 以及濫用過濾器維護員（由於涉及界面消息，該權限建議合併至介面管理員，確保明確的三級體系） 均應在申請前都應已經是巡查姬以上（且在職30天以上）的權限。
- 機器使用者、導入員、IP豁免：這三個權限我認為均應該由行政員/管理員執行臨時授權（或導入員額外由技術系人員副署同意後方可執行授權）且不予常駐授權（IP豁免也應當為臨時措施）。
- 體系授權方面，指令碼編輯員應由介面管理員同意（或額外通過介面管理員內部的簡易投票程序），行政員審核並執行授權；技術編輯員應由指令碼編輯員或介面管理員的權限組同意後，由管理員審核並執行授權。（儘管技術系用戶組不能執行授權，但是相關申請須經技術系用戶組相應人員同意後，再由對應的人事用戶組進行二次審核並執行授權，未經技術系用戶組人員同意而進行的授權應當視為嚴重錯誤）
- 這三級人員的活躍度除權我不太認可（並且由於前文建議至少需要巡查姬權限），應當明確為對應的命名空間下若干自然日未見編輯則予以除權，或與巡查姬的活躍度除權一致——考慮到介面管理員的重要性，該權限的活躍度除權相對於其他兩級可以相應放寬。
- 考慮到保險的需要，介面管理員也不應獨立修改頁面，應在摘要註明修改內容，理由，並確保有相應的覆核手段。
以上--From KumoKasumi the Bureaucrat (Talk) 2021年10月6日 (三) 01:53 (CST)
- @云霞 其實關於技術權限體系還可以有這麼幾個可選項：
- 合併草案中的介面管理員、指令碼編輯員、濫用過濾器維護員為新的介面管理員
- 優點：可以形成合理的上下級體系（介面管理員>技術編輯員）；可維護過濾器；能更好的進行統籌管理與合作；
- 缺點：對申請人的信任度評價大幅增加，申請難度增加；可以查閱濫用日誌和私有過濾器的內容，涉及保密性問題；
- 增加介面管理員的權限使其涵蓋指令碼編輯員
- 優點：可以形成合理的上下級體系（介面管理員>指令碼編輯員>技術編輯員），同時可要求滿足條件維護人員申請
- 缺點：介面管理員所需的信任度條件大大增加，申請門檻變高
- 注意：這個方案要求維護組申請，和#關於IA一節中其他行政員/管理員的意見可能完全相反
- 將介面管理員的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)
- 結合兩位行政員的意見，進行了一次調整，參見Special:差異/5301601/5303293，簡要說明如下：
關於論述的建議
- 在方針/指引的形成過程中，起到最核心作用的是社群的共識，並基於社群共識制定與修訂相關成文規定。自2020年8月通過了關於方針、指引與論述的提案後，社群已經釐清了政策頁面、論述頁面與幫助頁面的關係，並且依據該規則在後續提出了諸多有關方針、指引的修正提案。但是遺憾的是，作為為方針、指引提供補充、建議、針對站內某些事項專門討論的論述頁面卻一直以來沒有太大的發展。
- 提議區分論述的初衷即是在成文的規定之外提供行事的依據，允許表達多樣化的觀點，並且為新的方針、指引提供原型基礎。
- 也許是由於過往的提案並未對論述的撰寫及維護等事項作出明確規定，而現有的論述又太少，因此論述長期以來一直無法起到應有的作用。
- 因此在這裡希望各位能夠在本討論串下提出有關萌娘百科論述的一些想法，同時我也建立了User:雲霞/論述/關於論述的論述，以期作為後續撰寫論述的指導性頁面，亦歡迎各位參與修改完善。--From KumoKasumi the Bureaucrat (Talk) 2021年9月23日 (四) 10:55 (CST)
- 其實Maya一直不明白一個事兒：論述和提案到底是什麼關係？ ——拒絕互膜的
M. J. H. 【恆】{{#forargs:}} is evil! 2021年9月23日 (四) 11:02 (CST)
- ( ¡ )題外話 能否藉此機會順帶釐清Project與Help命名空間的關係（？ —— ほしみ 2021年9月24日 (五) 12:46 (CST)
- (＋)同意 萌娘百科現有的論述頁面似乎是論述類和Help指導類頁面混雜利用的--From KumoKasumi the Bureaucrat (Talk) 2021年9月26日 (日) 09:53 (CST)
- ( ¡ )題外話 以前常有建立了論述頁面卻被打回的情況，以至於現在很多人選擇僅在用戶頁下撰寫。我認為這不符合「論述」的初衷。——From
或許可以考慮建立一個關於論述的指引，給建立Project命名空間的論述設立一個簡單的機制？例如，在方針政策版塊請求大家查看，一定時間無維護人員或較多用戶反對就可以主動移動……什麼的……？—萌百假期放傻了阿巴阿巴 ᕕ(｡∀°)ᕗ🎜🎝 用戶名是公的驅逐艦的 壹陸 討論·最近編輯 2021年10月10日 (日) 10:11 (CST)
- 我認為，在發表前後公開徵求意見是很好的做法，事實上我自己就曾在發表後（雖然是發表後而非發表前）在這個版上公告。但是，(▲)同上 不應當將其設為必要程序。
- 根據現行MGP:方針、指引與論述：「論述…可以不經過批准而被創造及編寫」，但是「若是…與多數共識牴觸，則應該放在用戶頁下」，據此可以認為論述與主空間條目類似，採取事後監督機制（對論述主旨有異議，可以公開提出，經社群討論認為過於偏離共識的，打回用戶子頁；或者由由維護人員直接行使打回權），而不進行事前審核。這點我認為是符合論述的定位的，不應改變。況且現在是缺論述，不是論述泛濫。——C8H17OH（討論） 2021年10月10日 (日) 15:02 (CST)
是否應該減少「打回用戶頁」這一操作的適用範圍？
目前這一操作用於質量不達標，但並非毫無價值的條目，以及小部分不在收錄範圍，但質量較高的的條目。建議將這一操作僅用於後者。因爲既然在收錄範圍內，就應該允許其他人完善，而允許其他人編輯用戶頁面的子頁面容易引起混亂。
對於前者，建議建立一個專門區域用於放置這些條目，或者掛上「急需改進」而留在原地。
此外，爲了使急需改進的條目得到注意，可以在醒目區域放置指向Category:急需改進的鏈接。--蝶影書於蝶翼齋 2021年9月29日 (三) 23:59 (CST)
- 關於Category:急需改進，我的意見是如果這一分類內現有的頁面能夠少一位數的話，打回操作會少很多。然而正是因為該分類中的頁面過多（一千以上），新加入的頁面很難得到注意及改進。通過最近更改、移動日誌、最新頁面等途徑定期巡視新條目的畢竟是少數，因此我支持保留內容不足但具有一定價值的頁面/建立草稿空間/提高急需改進分類的利用率（可從移除已改善的頁面、補充頁面內容等方面入手）。措施一會面臨標準不一的問題，在目前的情況下可行性不高；措施二需要後台方面的配合、方針的修改，且需要編輯者達成共識；措施三可以在目前的框架內進行，不過工作量較大。——From
- 我之前設想過將急需改進根據原因細化為需要排版、內容過少等模板/分類。很多頁面被掛上急需改進是因為內容過少，然而動畫角色等條目需要了解相關作品的編輯者來補充，其他人若不熟悉故事情節，代碼力再強也是無濟於事。而在頁面排版方面，熟練的編輯者能夠發揮出自己的能力。將急需改進根據原因細化，處理起來的效率會好很多。——From
- 打回的本質是對不符規範的頁面的處理，我個人認為這是一種編輯者數量較少，新頁面可能長期得不到修改的情況下產生的不是令人很滿意的處理方式。既涉及了用戶子頁面的所有權，又涉及到低質量頁面的處理。我認為只有從根源改進，即減少不合規頁面的產生，這個問題才能得到有效解決。畢竟，打回是一個標準不一的操作。在我看來只是內容較少，排版並無問題的頁面可能會被其他維護組成員視為質量低下而打回。在總體改進能力不足的情況下，倘若將那些質量不高而略有價值的頁面保留在主空間，很可能的結果是低質量條目泛濫。——From
- 這麼多年血的教訓告訴我們，會創建低質頁面且不掛{{施工中}}模板的編輯者們，根本不會想着去完善那些條目----
新たな世界を見せてあげよう！（討論） 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)
- (？)異議那這個現象就會創建頁面這一行為本身的意義相違背了。我創建頁面，但我不寫，讓別人來寫，這河狸嗎----
- 那麼請問您認為有多少人有完善頁面的意願呢？就拿類似的情況來說，MGP:條目創建請求中不乏一些好久之前就掛到上面但至今無頁面的條目。不打回頁面或者專門建立一個分區的話恐怕只會像條目創建請求一樣，成為積壓工作。另外，關於用戶頁面方針的提案的討論正在進行中，您不妨參與其中發表您的看法。——飯糰人⭐一位史蒂夫 （討論·貢獻）✉❶ 請問您要單推一隻小浣熊嗎？ 2021年9月30日 (四) 23:59 (CST)
- 這一提議並不是為了等待創建者去完善頁面，而是為了方便其他人完善。--蝶影書於蝶翼齋 2021年9月30日 (四) 23:12 (CST)
- 我與上面的若干位用戶一樣反對將低質量條目保留在主命名空間。「寧缺毋濫」是萌娘百科長年以來的一條指導原則。創建新的低質條目永遠比將其改進為高質量條目要
難(註)筆誤簡單，潛在的編輯者中只會創建低質條目的人也遠比可能的優質編輯者要多，因此放棄「寧缺毋濫」只會導致更多低質條目的泛濫，而非促進高質條目的產生。如果您有意改變這一局面，建議先自己拿出實際行動去改善別人的被打回條目，反正現在是允許申請移回的。 - 當然，我也不否認現有的打回程序存在一些實踐上的問題，但如我在用戶方針提案的討論區中所說，在其他條件保持不變的情況下，我認為這個做法利大於弊，畢竟以前可是一律掛刪的，而草稿空間的引入還需要討論。——C8H17OH（討論） 2021年10月1日 (五) 12:55 (CST)
- 附萌娘百科:用戶交流用語樣板#質量低下之言：「當然，您也可以等待條目被其他編輯者在一天、一個月或者一年之後完善，不管怎樣，還請您以後不要在準備不充分的情況下貿然創建條目，創建內容質量低下的條目是對萌娘百科的瀏覽者、編輯者、甚至條目本身所代表事物的不尊重。」——C8H17OH（討論） 2021年10月1日 (五) 12:57 (CST)
那就要看草稿命名空間提案什麼時候咕出來了（）目前各種方案里：- 急需改進還是老問題（急需改進=永遠不會被改進），我難以贊成；
- 月櫻雪的急需改進分類細化方案其實去年「不完整」提案的時候ta就提過，難度我覺得略微有點大，雖然如果真實行起來未必有我想象得麻煩；
- 打回後開放編輯並/或掛模板，我其實覺得值得一試，不過可能不易達成共識（主要是對修改他人用戶頁面的管理難度），正在進行的用戶頁面方針提案中也沒有採納（不過還是寫入了申請移回的程序）；
- 草稿命名空間目前看來算是比較好的方案，也符合你說的「專門區域」，不過也是需要達成共識（現在看來支持者也不少），並且大概需要發個提案制定個方針來規範其運作。
- ——C8H17OH（討論） 2021年10月1日 (五) 15:35 (CST)
- 或許可以在急需改進模板自帶的分類上作改動，如存在參數「內容過少」時生成分類:內容過少的頁面，「排版混亂」時生成分類:需要排版的頁面等。這樣不需要新建模板及手動批量修改。
- 至於草稿空間，我建議再進行一次規模較大的討論，如果社群整體傾向支持，則開始方針的修訂工作。——From
- 基於2014-2019年Project:頁面存廢及其子頁面的實踐，並現在急需改進的嚴重堆積問題（且如今仍然難以得到切實改善的編輯實際），對包括草稿命名空間或者恢復頁面存廢子頁面制度的方案不予看好和支持。因為僅靠新建專門區域無法解決質量低下頁面的堆積問題，且此類頁面大量堆積本身就是對相應編輯者試圖改善內容的重要阻礙（堆積的情況，本身就會使編輯者更加難以尋找其中值得改進或者自己的條目）。如果有能改善現有堆積情況的可查詢和易於改善程度的方案措施，那當然十分歡迎，但是至少應當先使該方案可以解決現有的急需改進分類的內容堆積問題，證明該方案的行之有效性，而不是再創造一個可能堆積成現有急需改進分類的情況的「專門區域」。--未濟橋姬(☯太虛之門) 2021年10月1日 (五) 16:08 (CST)
- 這樣來看樓上兩位的意見有一定的相似之處，關於分類細化的論述我覺得很有道理。創建專門的區域，並/或分類細化以便查詢，這兩者我都不反對，同希望能早日看到好的方案。——C8H17OH（討論） 2021年10月1日 (五) 16:15 (CST)
- 目前關於草稿空間有一點共識是一定時間未得到改進的低質量條目會被刪除，與之前的積壓還是有區別的。——From
- 基於現有關於用戶頁面方針的提案內打回子頁面的相關討論（萌娘百科_talk:提案/討論中提案/關於用戶頁面方針的提案#關於打回子頁面的頁面廢存的建議）來看，一定時間內未得到改進的低質量頁面被刪除這一點並未達成共識，幾乎清一色的反對——而且相應意見中與一定時間刪除對立的意見，反而是創建專門空間，也就意味着創建專門空間後，一定時間未得到改進的低質量內容同樣會被積壓起來。故，這裡暫且對「關於草稿空間有一點共識是一定時間未得到改進的低質量條目會被刪除」這一結論保持質疑。--未濟橋姬(☯太虛之門) 2021年10月1日 (五) 16:42 (CST)
我發表的「反對限期刪除」觀點旨在尊重內容創作者的勞動成果，在這種有維護需求的情況下，我同意需要限期清理這些頁面，但仍反對直接刪除有內容的頁面。如果能實現草稿命名空間的話，我不反對對該命名空間下的頁面進行定期清理，但是我認為清理不能簡單地刪除，對於那些存在實質性內容的，我還是覺得應該移動回用戶子頁面，移除對應的低質量頁面分類，或者全都歸入「長期未改善的低質量頁面」之類的分類中。低質量頁面積壓可能無法避免，我覺得細化草稿命名空間的分類是比較好的選擇。比如對於在萌百上已有專題的頁面，可以將這些頁面歸為一個子分類供相應專題的編輯者查閱（對於很多編輯比較活躍的專題，我覺得這種方法幾乎可以解決所有這些專題下的頁面問題）；沒有專題的則可以按現有分類歸到對應的未完善頁面中。--SinonJZH(๑•̀ω•́๑)(討論) 2021年10月2日 (六) 03:33 (CST)
SinonJZH(๑•̀ω•́๑)(討論) 2021年10月2日 (六) 03:33 (CST)
- (▲)附議(＋)支持 建立限時清理的草稿空間並細化分類，以引導後來的編輯者改進這些條目，(－)反對 直接刪除這些頁面。(～)補充 個人認為草稿空間如果沒有專題分類與定時清理機制的話還有可能導致空間下頁面過多且混雜而使編輯者沒有耐心看下去。就跟MGP:條目創建請求一樣--Qimi142857（討論） 2021年10月2日 (六) 09:13 (CST)
- 他力本願之術請在建立條目之前使用。雖然Maya一向反對將「我投入了多少心血啊」作為保留條目的理由，但並不意味着Maya認為「沒投入多少心血」的條目就值得放在那兒了。
- 至於草稿空間，Maya的態度是「只要有定期清除機制就接受」。從橋姬上面發的討論來看，共識不太支持這樣的定期清除機制，那麼目前的狀況是「不太接受」。 ——拒絕互膜的
M. J. H. 【夬】{{#forargs:}} is evil! 2021年10月1日 (五) 21:03 (CST) - 個人認為草稿命名空間也應該設立相關門檻。那些寫了一半但因故無法繼續完成、需要他人幫助才能補完的條目可以存放在草稿裡，比如谷井明日香因缺乏更詳細的介紹和翻譯被打回，但該條目編輯者確實提供了不少資料，後來者在此基礎上續寫能減少很多工作量。但是某些幾句話條目就還是算了。個人認為放進草稿命名空間的條目的內容底線可以參考超理/常見物質列表(註)僅作內容質量方面的參考，實際情況是此條目相關內容已被其他條目合併。關於此類細節性的操作問題，需要更集中的討論，在此不多加贅述。——分柿方橙（討論） 2021年10月2日 (六) 10:12 (CST)
- 剛才嘗試了一下修改T:急需改進，希望能使其自動產生「需要排版的條目」等分類，不過能力有限，效果並不理想，但如果修改得當應該是可以達到我所設想的效果的，即自動產生與頁面問題對應的分類。
- 另外，之前留意到Func的機器人有在更新萌娘百科:填寫了改進方向的條目。我認為急需改進分類同樣需要這樣的頁面。正如我之前所說，分類內積壓的大量頁面是上手修改的阻礙，在WAF尚未取消的當下，編輯者不可能一個一個頁面地打開，去看自己能做到什麼。將急需改進分類內的頁面連帶着改進方向做成列表，定能一定程度上改善當下頁面堆積的情況。這樣自然也就縮小了打回頁面的需求。——From
關於字詞轉換指引的修訂討論
萌娘百科:字詞轉換指引通過已半月有餘，在運行期間，本起草人發現了一些問題，下面分別介紹問題所在及修改方案：
- 其一：轉換表使用標準一節的「使用數量」定義含糊不清，應該做出修改：
| 修改前 | 修改後 |
| 「使用數量」指主空間、模板 |
「使用數量」指主空間、模板、萌娘百科、幫助和分類命名空間出現相關用於展示的源代碼的頁面之和； |
- 其二：異體字適當保留情形較預想中的多，宜將使用標準從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)
- (＆)建議 大家族模板內的紅鏈允許轉換為簡體，防止一些新用戶點擊創建時出錯。理由和未創建的分類是一樣的。—— ほしみ 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)
- 個人認為：
- 社群形成共識的過程不應濫用投票，一是難以判斷投票的有效性（即如何設定應參與投票人員範圍），二是難以選擇計票的規則（同意參與比或同意總數比？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)
- Maya要說的只有四個字：客觀視角。一個話題是否有一大堆爭議是次要的，是否使用客觀視角表述才是主要的。即使是爭議話題，若採取客觀且在收錄範圍的描述，難道不是受方針保護的嗎？有了方針背書，其他的什麼討論又如之何？ ——拒絕互膜的
M. J. H. 【豐】{{#forargs:}} is evil! 2021年10月5日 (二) 23:12 (CST)
讚 儘管實際上很難做到，但作為寫過一些事件和爭議的編輯者，我覺得若有相關規範出台的話無論政策級別如何，「客觀中立」這點是必要寫入的，儘管最後大概率會浮於虛名，但至少可以標明萌娘百科對爭議頁面的看法。--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)
- 對於上述提及的那些爭議內容，產生爭議的玩家群體之間本來就帶有相當大的主觀色彩，在這種情況下，即便添加來源也無非是玩家討論的一些帖子，我覺得這樣也很難說是一種「可靠來源」。這樣的話即便引入這些來源請求模板，也很容易被直接用來寫入主觀內容或者質疑他人添加的來源是否可靠，這樣又會陷入另一種爭議中。我認為對於這些爭議內容，尤其是這種來源的可靠性曖昧不清的，應當在更大範圍進行討論，形成諸如「遊戲作品的玩家群體產生的爭議內容是否應當被收錄進條目」、「如果要收錄的話，以何種形式或何種角度收錄」這一類的共識，才是解決更細一點的個別爭議的方法。--
- 個人意見：
- 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票。以簡單多數決定結果。
- 這裡多提一句，方針在投票形成共識這一問題上有所缺失（或者說根本在形成共識這一問題上就是缺失的），既未禁止亦未允許，希望以後能完善相關政策。
- 恕我(－)反對 有大量爭議即可開子頁面這種行為，如果維護組不花精力去跟進監管，只會形成一個無人處理的垃圾場（參見Bilibili/爭議與影響）。另外建議將爭議頁面的處置與解釋權給予整個維護組，必要時我認為可以進行維護組內的投票。
- 最後一點，我認為某些爭議，例如這次舉到的三個例子，完全屬於「玩家社區內容」，依現行方針根本不在收錄範圍之內。——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)
@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)
- 關於揚頁面的事，我看很困難，畢竟在那之前我們都不敢設想有「敢大張旗鼓出來拉人的垃圾場」過。--一位普通的刺客以及他的私人郵箱 2021年10月17日 (日) 00:23 (CST)
就對未成年用戶及其家長的相關論述展開意見徵集
雲霞佬的關於論述的建議讓我感觸頗深。據Mobtech2019年12月統計顯示，中國大陸的二次元用戶中18歲以下人群占比19.3%。考慮到萌娘百科的現狀和參考其他百科的情況，我認為，撰寫一份對於未成年用戶和其家長的建議性論述是有必要的。當然了，這份論述主要面向的是年齡層較小的未成年用戶，我認為主要應當涉及的方面也是保護個人信息、理性思考、學會在現實世界中找平衡、家長指引等方面。儘管之前我和玄微子[更多]已經在User:Sivlovski/沙盒#MGP:致未成年與家長們撰寫了一部分，但我認為這份論述依舊有更多可以挖掘的價值，故希望諸位能夠發表一些建設性意見或是直接上手更改，以便將這份論述完善後移動至MGP命名空間。
以上。--Thus Spoke Sivlovski.「討論」 2021年10月23日 (六) 18:26 (CST)
- 讚 在近期出現多次疑似未成年人暴露個人信息的事件後，我也萌生了類似的想法，沒想到西弗和濁華已經寫了出來，深表讚賞。
- 通讀下來，對於給未成年用戶的建議部分，我覺得已經相當不錯（甚至其實可能並不只是未成年用戶受用）。
- 至於給家長的致信部分，總覺得可能還欠點東西，目前的部分我覺得略微有些拔高萌百的作用x（因為其實確實還是可能沉迷和影響現實生活的），我覺得對於家長可能更多的是需要勸導他們接受孩子的興趣和與孩子們溝通，畢竟家長們可能是認為動漫百害無利的，我們應該做的不是全盤否認其害，而是闡述其利、解答過當的疑慮、和告訴他們儘可能規避確實存在的害處的方法。不過說了這麼多，其實我也沒有具體的怎麼寫的想法，還望大家繼續共同探討。
- ——C8H17OH（討論） 2021年10月23日 (六) 21:43 (CST)
- ( ? )疑問 大部分監護人可能不知道如何使用wikitext語法編輯與在討論版上留言，監護人使用與被監護未成年人相同的賬號編輯話題時也有可能產生一些誤會（可以考慮監護人使用分身賬戶？），甚至可能有一些較為偏激的監護人使用被監護人的賬號進行破壞，儘管他們可能並不懂wikitext？--這裡，是我。（討論） 2021年10月23日 (六) 22:12 (CST)
- 讚 不過我覺得家長的部分，「我們不是壞人」和「不太好的內容」這兩個標題非常坦誠，但是可能也太老實了，容易一下子引起家長過度的警覺。我覺得對家長的解釋部分可以將重心放在「能給孩子帶來什麼」（也就是利）和「請您注意什麼」（也就是弊）兩部分。利的部分還可以稍微結合網絡百科文化來談（我自己多年前作為未成年人編過百度百科和維基百科，編百科對信息整理能力和說明文寫作能力的鍛煉我是有感受的）。弊的部分則以推薦給家長的指引、指示為主，類似操作說明書一樣。另外，也可以鼓勵家長和孩子一起思考條目的編寫邏輯，或是對不良內容一起舉報。——Sirogohan（討論） 2021年10月23日 (六) 23:48 (CST)
- 讚 寫得非常好，已經在頁面里貢獻了一些內容--From KumoKasumi the Bureaucrat (Talk) 2021年10月24日 (日) 00:11 (CST)
- 讚 好活。但是是不是也應該多加一點鼓勵的內容？—— 冬月下的二重奏
LUO1P✾ 2021年10月24日 (日) 00:26 (CST)
- (＋)同意 重新審讀了下，內容很棒，不過似乎「不要做什麼」的篇幅占了有點多，多一點鼓勵或者引導性質的內容會更好--From KumoKasumi the Bureaucrat (Talk) 2021年10月24日 (日) 00:38 (CST)
- 稍微想了下該從哪下手。
- 維基語法有些勸退。看看編輯指南講語法那一章就知道有多少人會止步於此。我的建議是用一個例子：學期開始的時候看期末試卷看不懂，學期末再看也沒有那麼難。更何況寫萌百相當於是開卷。
- 害怕自己寫不好。我自己開始編輯的時候就是這樣的，年紀挺小，害怕自己寫的不如意參考了四五個條目，最後還在評論區里發什麼第一次寫不好請見諒之類的（然而還是被罵了）。建議是讓他們在方針允許情況下放開膽子寫，錯了會有人來幫你改正，不過以後就不見得了。
- 想就只能想出來這兩個了，手錶碼字不好整。早上再總結下常見新手問題吧。如果大家有補充歡迎掛在下面。—— 冬月下的二重奏 LUO1P✾ 2021年10月24日 (日) 01:16 (CST)
- 讚 讓我想起來了過去的一些趣事兒。--Ceba（討論） 2021年10月24日 (日) 00:52 (CST)
- 讚 好活！雖然某些地方的用語還能再改上一改，但這是個很好的開始，不是嗎。——Jacklin612 ☎·🧾 2021年10月24日 (日) 01:51 (CST)
感謝各位的支持和實際作出的建議與修改。首先，我必須要向各位致歉，因為我起初並未料到這份論述可以有如此大的關注度，因此我只是放在了個人沙盒，目前我已將相關內容移動至單獨的用戶頁面U:sivlovski/temp並添加了「致謝」一欄以在論述移動至MGP命名空間後標明參與意見提出與內容編寫的編輯者。再次在這裡說一聲抱歉！
除此之外，我還做了一些修改：
- 調整了小標題1.1，因為我認為英文原文並不是必要的。
- 參考上文雲霞和LUO1P的建議，新增#積極學習一欄。
關於致家長們部分，我自己也的確認為這部分我寫的不是很好，一個處男怎麼能寫的來這種東西呢。因此，我在考慮或許可以將這部分內容先劃出，優先創建面向未成年人的論述。當然，如果諸位有更好地修改建議，也可以直接上手擴充相關部分的內容。
以上。--Thus Spoke Sivlovski.「討論」 2021年10月24日 (日) 18:56 (CST)
- 讚 看了一下草稿，敝人認為可以在「致家長們」這一章節簡單介紹下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)