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

萌娘百科 talk:讨论版/方针政策/存档/2022年03月

萌娘百科，万物皆可萌的百科全书！转载请标注来源页面的网页链接，并声明引自萌娘百科。内容不可商用。
跳转到导航 跳转到搜索

档案馆讨论版【方针政策】档案馆

20

21

22

23

24年

对于条目名中一些符号是否应该被允许使用的观点统计

自萌娘百科讨论:讨论版/方针政策/存档/2021年12月#关于MGP:条目命名#避免特殊符号原则的意见征集，一些问题得出了共识或者我想到了处理办法，但还有一些没有讨论、没有得到共识或需要细化讨论。在此（再次）统计一下各位对以下符号的观点，为对萌娘百科:条目命名的提案做准备。

逗号句号这些就不用说了，我绝对要让它能用。

  1. 技术上没有问题，但部分输入法不易输入的，一般来说去掉会很怪的符号，通常具有实际意义，如“×”（实际操作倾向于保留？）：
  2. 技术上没有问题，但部分输入法不易输入的，一般来说去掉也不会很怪的符号，通常为装饰性，如“☆★❤♪＊”（实际操作倾向于不保留？）：
  3. 技术上没有问题的衍生拉丁字母（Æáéíóúæø等）：
    • 想不出来 (～)补充 于2022年2月5日 (六) 17:28 (CST)：Café Parade!
  4. 技术上稍微有问题的“&?%”等，与URL语法冲突，但MW会转义（实际操作倾向于保留，甚至有专门把不会出问题的“？”移动到“?”的）：
  5. 技术上有问题的“/”，与子页面功能冲突，但可以用{{NoSubpage}}假装不是子页面：
  6. 技术上有问题，且在消歧义前后缀中出现的“/”：

我的观点：

  1. (＋)允许使用
  2. (＝)不确定，但技术上没有任何问题
  3. (＋)允许使用，这样可减少不必要的消歧义后缀
  4. (＋)允许使用，理由：MW会转义。小工具会出错是小工具的事；试图在浏览器地址栏输入这些符号以进入条目的请把萌娘百科加入搜索引擎
  5. (＝)不确定
  6. (＝)不确定

判断题比简答题简单，汴京的话到提案的时候再汴吧。就算仅对某几点发表观点也大欢迎。　あめろ 论 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)
已在前端修復。——移动版用户 Bhsd 2022年2月8日 (二) 01:30 (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)

“再者，如果它可以被转写为英文名……”不合适，上面的café即是英文。　あめろ 论 2022年2月6日 (日) 21:43 (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)

(－)不支持 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)
(：)回应 假设条目命名中使用了♡，在我的电脑和你的电脑上看到的♡不一样，是这样的情况。无法保证在所有人的电脑上看都是相同图案的♡（空心爱心），所以不建议在条目命名中使用2，如果按Eric Liu所说的，在不引起误会的情况下，可以尽量放宽，允许在条目命名中使用，就会有这样的显示问题，而显示问题怎么解决。--夜羽と善子（讨论） 2022年2月18日 (五) 21:22 (CST)
（什么屑字体把“♡”做成实心的）。显示问题只有统一嵌入字体能够解决，这对中文网站来说是很难做到的。而且就算条目命名不让用，编者也会用标题替换加上那个符号，显示问题依旧存在。　あめろ 讨论 2022年2月23日 (三) 21:31 (CST)

( ? )疑问 经星海启发，对于情况3，如果我说不对此类符号做限制，而是通过官方名称优先原则、常用称呼优先原则、简体中文优先原则等原则来尽量避免此类符号如何？如果这三个原则都管不住它，那说明真的很有必要使用这个符号了。举个例子（虽然不是衍生拉丁字母）：μ's。　あめろ 论 2022年2月8日 (二) 23:03 (CST)

不如说六种情况都应该通过官方名称优先原则、常用称呼优先原则、简体中文优先原则等原则来尽量避免（滑稽）。—— 雪月❄️于冬日之会客室相谈 2022年2月17日 (四) 23:37 (CST)

来炸个坟。
( ? )疑问1 如何判定1、2点中的符号是否必要？或是说如果符号能够换成空格或是常用字符的话这个标题的符号还有必要吗？（也就是说对于1、2点是否也应该像情况3那样“通过官方名称优先原则、常用称呼优先原则、简体中文优先原则等原则来尽量避免此类符号”）另外现在站内对于同种情况的不同处理方式可谓是泛滥成灾，譬如对于情况2，少女歌剧条目就没有带☆。
( ? )疑问2 如果有个闲的没事的人想写含有会出错字符的标题，且该标题无法通过以上三原则规避，那怎么办？（比如如果有人想写“#1f1e33”的话，虽然目前应该是没有）
( ? )疑问3 在utau界中有许多仿海鲜市场类型的歌曲，其名称多为乱麻空格和不明字符，有些无法用以上三原则概括甚至会出现空格标题、没有标题的情况。由于该类utau曲很多都在萌百收录范围内而且未来确实也有出现该类歌曲标题的可能，那么如何解决？
( ? )疑问4 如何看待空格和顿号等常用于替换特殊字符的形式？
(－)不支持6 我觉得完全可以通过缩减后缀或替换后缀的方式来规避该问题。—— 雪月❄️于冬日之会客室相谈 2022年2月17日 (四) 23:37 (CST)

  1. 我的想法是具体到符号——“×”或“☆”，而非具体到情形——“有必要”或“无必要”，所以上面的概括带上了“一般”和“通常”。即符号白名单与黑名单，这样在以后操作时可以降低判定难度，减少辩经。至于为什么分成1和2这两类，是我观察现有命名的结果：“×”多为保留，而“☆”多为不保留。你说了少女歌剧条目没有带☆，事实上上面举的千恋万花、Fate/kaleid liner 魔法少女伊莉雅、777 SISTERS、ROCKS、2winkle Star Beat也都没有带符号，带符号的是重定向。不同处理方式泛滥确实是一个问题，也是我在这里征集观点的原因。
  2. 换全角“＃”。
  3. +♂、Ϡ、.、.、.、...、!、･.･.･.、:|、 、 、 、 、?̵͔͖̺͓̬̩?̙̥̪͓̣̟̟?̟̀?̢̯̻̠?̫̯̲̝́??̜̲̼͖̗̩?̬̗̭͟?̙̰̫̝͙͉ͅ ?̮͕̟͎͙̺̮?͚͔̦̥͚?͓̗̩͔?͉̫̰͎̥̳?̡。自然有办法解决。
  4. 泻药，不看待。
　あめろ 讨论 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日 (三) 21:31 (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)

日文的引号技术上存在困难：简体模式下，内置转换表会将日语引号单向转换为简体中文下的引号。—— 屠麟傲血（讨论） 2022年2月24日 (四) 20:32 (CST)

《萌娘百科月报》 二〇二二年二月号

上高防了！萌百娘复活啦！
人事动态
政策变化
技术更新
其他事务
订阅 • 存档 • 月饼


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)
嗯忘了说了，不考虑评论扩展的调整和启用另外扩展（如计算主名字空间编辑数等）。—— ほしみ 2022年2月5日 (六) 12:20 (CST)
我希望看到其他巡查和管理員的意見。--By CHKO (Talk) @ 2022年2月5日 (六) 12:28 (CST)
阁下认为自动确认用户这一身份的意义在于什么？——From 玉幕辛 (讨论)--没事干才会写签名 2022年2月5日 (六) 11:46 (CST)
@玉幕辛 請注意，你的簽名中含有未閉合的''元素，請修改你的簽名。--By CHKO (Talk) @ 2022年2月5日 (六) 12:14 (CST)
可能是为了在一定程度上防止破坏者破坏吧，自确和普通用户所有的权限还是有点差别的（虽然现在有好多更恶心的破坏方式（悲—厚礼谢来喝茶吧 2022年2月5日 (六) 13:56 (CST)
修改成自首次编辑以来48小时的一个好处是能够减少新手狂交版本的情况，写个千把字节提交50+版本那样。
但还是没有解决评论门槛较高、新用户把讨论页当评论区、自确保护效用过低等问题，所以不妨先问问这次修正是想在哪个方面做改进吧，能让建议更有针对性。——From 引梦者浊华(讨论) 2022年2月5日 (六) 12:51 (CST)
目的是增加新手学习成本，增长编辑前强制预览的时间。—— ほしみ 2022年2月5日 (六) 13:26 (CST)
不考虑更改评论拓展以及启用另外拓展的话有点难整，因为这可能造成的另一个现象是新用户蹲完首次编辑后的48h就开始编辑狂轰滥炸。我的设想是整一个滥用过滤器检测是不是用户首次编辑，是的话先拦截然后再过滤信息里头讲一些新手可能用到的东西引起他们的注意。毕竟现在啥也不看直接裸奔上手的编辑者也不少。—厚礼谢来喝茶吧 2022年2月5日 (六) 13:40 (CST)
改為註冊或第一次編輯起至少七日？或三日之類的？一日或二日是有點短了，真正要長期貢獻者不會在意把期限拉長一點。—— Eric Liu 創造は生命（留言．留名） 2022年2月5日 (六) 17:44 (CST)
首次编辑起2日刚好，3或7天都太长了点。—厚礼谢来喝茶吧 2022年2月5日 (六) 19:07 (CST)
并不赞成在不改变评论限制的情况下增加自确难度，这样可能会大大减少游客/纯读者评论的兴趣 谁会为了发几句评论编辑十次等48h啊 。——From 泠佛. (讨论) 2022年2月7日 (一) 00:55 (CST)
(＋)支持 以前不理解为什么会有新人把本该发在评论的东西发在讨论页，直到后来知道了非自确不能评论······——北湖3（讨论） 2022年2月26日 (六) 10:23 (CST)
如果一些数据显示自确比例极小，不考虑取消需自确才能评论的限制吗？取消了限制的话，更方便讨论和修改自确的标准。--夜羽と善子（讨论） 2022年2月14日 (一) 01:07 (CST)
暂不考虑。由于曾经有非自确用户进行破坏性评论、广告和评论区难以管理和追责等问题，现阶段评论限制仍然必须有。除非未来有更好的追责措施（如手机号验证才可评论等），不然自确（电子邮件验证+编辑）仍然是最好的一道限制。—— ほしみ 2022年2月14日 (一) 01:14 (CST)
有道理，反过来说如果取消限制，等于大量用户可以发评论，等于注册个账号就可以直接发评论（评论门槛低），虽然我个人认为现在的部分评论不能看。修改自首次编辑以来的时间这个变量更好一点，我也认为真正要长期贡献者不会在意把期限拉长一点。--夜羽と善子（讨论） 2022年2月14日 (一) 02:58 (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)
Symbol Circle OK.svg 了解。论手册的详尽度.caj（——C8H17OH（讨论） 2022年2月17日 (四) 23:29 (CST)
一个小问题，能否做到将自确和编辑强制预览分开？编辑一定次数+注册一定时间可评论，但是强制预览+验证码的时间达到1周以上？这样评论的难度不变或者降低同时对wiki的学习成本会提高。感觉这样做似乎要加用户组啊
( ¡ )题外话 除去把评论发在讨论页，把评论区当讨论页也是一个存在的现象，能否将形成讨论的评论删除并迁移至讨论区？--Zyszhao.GoodEditor (讨论页与用户贡献) 2022年2月27日 (日) 18:24 (CST)
那在用户和自动确认用户之间新增一个用户组，名为“可评论的用户”，降低注册时间or编辑次数，例如注册24小时，编辑5次。但还是需要电子邮件验证。这样就可以修改自动确认用户标准，Zyszhao所说的强制预览和验证码的时间也可以改动。如果不打算把评论限制和自动确认用户分开的话，个人推测每次讨论基本上都是五五开，支持和不支持约各占一半，讨论没有结果。新增“可评论的用户”这一用户组是否可行？--夜羽と善子（讨论） 2022年3月5日 (六) 17:41 (CST)

请求管理员/巡查姬的建议（方针方面）

萌娘百科_talk:讨论版/页面相关#一些涉亚文化页面的问题串，请求管理员从方针与政策角度提供建议。--∷∷by SelficeSelfice🏠|📭 2022年3月7日 (一) 01:51 (CST)

或许这个讨论串应该移动到这里[萌娘百科_talk:讨论版/方针政策]来？--∷∷by SelficeSelfice🏠|📭 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)

关于封禁复检程序

萌娘百科上有两个方针提到了“封禁复检”这个程序，但以“封禁复检”为关键词进行搜索却完全找不到这个程序本身的定义和流程是什么。如果可以的话最好在封禁政策或者一个单独的页面写一下这个程序的定义。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)
问题已答复。
您仍可以继续在本模板上方回复，但这个讨论串将会在本模板悬挂满3日后 (于2022年3月18日凌晨) 存档。
如果您有有关疑问，建议您开启一个新的讨论串。
处理人留言：
后续讨论可以在提案处进行，故存档。————「今日も一日がんばるぞい！」(沼泽 • 讨论) 2022年3月14日 (一) 19:49 (CST)

关于人物收录范围修改的第二次预讨论

在上个月，我曾针对收录范围提案后存在的问题展开过一次预讨论，并收获了不少宝贵的建议，在此感谢参与讨论的各位。

目前针对争议较小，但又相对比较急需修正的人物部分单独发起讨论，望各位能够不吝提出修改建议。如无问题，我将尽量在本月15日前发起正式提案。

其中有部分内容也在配合#音乐收录范围第三修正案预讨论提出的问题一并进行修改。——「今日も一日がんばるぞい！」(沼泽 • 讨论) 2022年3月6日 (日) 12:54 (CST)

收录范围补遗提案的现实人物部分修正案 - 正文

收录符合以下条件之一的现实人物：

  • 作品一节所规定作品[1]的相关创作者：漫画家、声優/配音演员、ACG歌手[2]、动画师、原画师、插画家、小说家、P主、音乐家、脚本作家、制作人等；
    • ACG歌手：其演唱歌曲的音乐出版物主打歌，有一半以上需要为音乐一节所规定的前两大类歌曲。[3]
  • 其他ACG相关行业内容创作者：网络画师、歌手、Coser、舞者、网络视频制作者等；
    • 网络歌手：必须有三首以上符合音乐收录范围的原创歌曲，单纯进行ACG相关歌曲翻唱的不予收录；
    • 网络视频制作者：其网络视频作品必须为主要使用ACG作品相关内容制作、且具有一定原创性。[4]
      • 收录符合其他收录范围要求的网络视频创作者，但相关条目应当不以其网络视频作品为主。
  • ACG产业的其他相关人员[5]：电子竞技职业选手及解说员[6]、游戏[7]主播等；
    • 游戏主播：必须在至少一个直播平台拥有10万以上粉丝。[8]
  • ACG行业从业人员：组织一节所规定组织的董事长/代表取締役等高级运营管理人员，或是大型综合组织中ACG相关部门的主要负责人。[9]
  • 与ACGN+文化、迷因等关联的人物。但相关条目应当围绕相关ACGN+文化、迷因为主予以介绍，非ACGN+相关的人物经历进行简要概述即可。

注意：

  • 不要混淆作品中角色和现实人物；
  • 不要恶搞现实人物；
  • 与ACGN关联不大，但拥有独立二次元形象的网络名人和明星，应当以其二次元形象为主予以介绍；
  • 不符合上述收录要求，但有较高流行度和迷因属性的网络人物，可通过网络流行用语之方式收录。若要撰写人物的条目，条目内容应重点关注与其相关的用语、成句，而仅对人物经历进行简要描述；
  • 不是ACG相关行业从业者，但有少数ACG经历的明星、艺人、歌手等（统称“多栖艺人”），若ACG经历和作品多于三个，且认可自身的ACG相关内容创作者身份的，允许以独立条目收录，且条目内容应当以ACG经历和作品为主。否则可将其ACG相关经历和作品单独汇总到多栖艺人条目下，而对人物本身不做任何介绍；
  • 出于人物隐私及形象考虑，请勿使用非公开或不宜公开的、或者有损人物形象的照片作为条目图片。[10]

另外需要调整音乐部分的收录范围：

    • 由声优歌手、唱见等收录范围内的ACG歌手（以及ACG歌手组成的歌手组合和声优组合等）[11]演唱的原创曲目。如有特殊情况则具体视之处理。
      • 此处的ACG歌手是指演唱歌曲的音乐出版物主打歌有一半以上为上述两大类歌曲的歌手。[12]
      • 不收录ACG歌手翻唱歌曲，除非该曲同时符合收录范围中的其他收录条件。

注释部分

  1. ↑ 参照角色一节的定义修改措辞避免歧义。根据淮南皓月的建议修改。
  2. ↑ 拆分后留下来的问题，少了一类重要的人物。
  3. ↑ 移动相关要求至现实人物一节。
  4. ↑ 统一表述：调整了措辞和顺序。
  5. ↑ 因为较难认定这三类属于“内容创作者”，故单独分出。根据Amero的建议修改。
  6. ↑ 电竞选手及赛事解说员算是游戏产业的重要分子，应当予以收录。根据Chko和Legend frog的建议增加。
  7. ↑ 主播从ACGNM几大范畴来看，目前来看似乎只有游戏主播一类因为不能搭上其他收录范围的许可，而需要在此进行特殊规定。直播看动画、漫画、轻小说的主播就算了吧。
  8. ↑ 增加了对于游戏主播收录的知名度限制，防止滥收。
  9. ↑ 增加关于部分人物的收录许可，例如bishi和陈睿(bilibili董事长)。另外统一调整了措辞以避免歧义。根据北湖3的提议进行了另行扩充。
  10. ↑ 关于配图的使用限制交给萌娘百科:现实人物条目编辑指引去规定。
  11. ↑ 增加关于组合的说明，避免收录范围缺损。
  12. ↑ 移动相关要求至现实人物一节。

讨论区

没有上次从chko建议那修改的“电竞职业选手”吗——CG/SS domain GOOD EDITOR Kaze Iro the Legend frog (wisdom·stupidity) 2022年3月6日 (日) 13:03 (CST)

加上了，确实应该加。——「今日も一日がんばるぞい！」(沼泽 • 讨论) 2022年3月6日 (日) 13:32 (CST)

( ¡ )题外话 可以顺便修改一下“符合收录范围的作品”这个表述，要咬文嚼字的话，说不清是必须符合作品收录条件，还是说只要是作品、能收录，以原型标准收录的作品也算。——Ithea 淮南皓月 2022年3月6日 (日) 14:08 (CST)

改了。不过作品是作品，原型是原型，这俩不应当被混淆的。——「今日も一日がんばるぞい！」(沼泽 • 讨论) 2022年3月6日 (日) 14:27 (CST)

我质疑电子竞技职业选手及解说员、游戏主播的“内容创作者”地位，他们至少得换个位置。另外我对收录只进行游戏直播的现实人物持负面态度。　あめろ 讨论 2022年3月7日 (一) 01:06 (CST)

那么就把这三者一起开一个新栏目。单纯只进行游戏直播，而不产出任何切片的人我觉得是非常少的，自己玩游戏的直播切片可以算作是一种产出吗？——「今日も一日がんばるぞい！」(沼泽 • 讨论) 2022年3月7日 (一) 09:09 (CST)
补充更何况现在直播平台基本都有直播回放自动存档功能。——北湖3（讨论） 2022年3月12日 (六) 19:00 (CST)
(＆)建议 ：①对于舞者，应规定其有三首以上以收录范围内音乐作品或其二次创作作为BGM的舞蹈视频投稿，以限制收录某些以韩舞、某音风为主的舞蹈网络视频作者；
②对于某些仅有部分业务与ACG相关的大型企业集团，其主要负责ACG业务的部门、事业群等的主要负责人（如部门经理、总监等）也应予以收录，毕竟我个人认为以其企业的体量，其对ACG产业的影响很可能远大于某些只有ACG相关业务的小企业。——北湖3（讨论） 2022年3月12日 (六) 19:00 (CST)
第二点已经修改，关于舞者我很想再确认一下目前站内的收录情况再确定具体标准，光用三个不一定好。——「今日も一日がんばるぞい！」(沼泽 • 讨论) 2022年3月14日 (一) 18:48 (CST)
(＆)建议 五个翻跳或三个原创编舞？反正我不希望像唱见那边一样纯粹限定于原创，毕竟我个人感觉原创编舞的门槛还是远高于给某个（相对意义上）冷门VC曲唱人本的。要是限定于“原创编舞”很可能会造成舞见相关内容的大规模打回/删除。——北湖3（讨论） 2022年3月15日 (二) 23:05 (CST)
大规模删除应该是不太可能，现在舞见收录还是很少的，也就十几个，基本也都是有了一定的作品与人气才有人写。我会在正式提案中询问一下社群对于舞见收录的看法，再具体讨论具体标准是严格一些好还是放松一些好。——「今日も一日がんばるぞい！」(沼泽 • 讨论) 2022年3月16日 (三) 17:38 (CST)
问题已答复。
您仍可以继续在本模板上方回复，但这个讨论串将会在本模板悬挂满3日后 (于2022年3月20日凌晨) 存档。
如果您有有关疑问，建议您开启一个新的讨论串。
处理人留言：
准备发起正式提案。————「今日も一日がんばるぞい！」(沼泽 • 讨论) 2022年3月16日 (三) 17:34 (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)
问题已答复。
您仍可以继续在本模板上方回复，但这个讨论串将会在本模板悬挂满3日后 (于2022年3月21日凌晨) 存档。
如果您有有关疑问，建议您开启一个新的讨论串。
————  ほしみ 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)
原则上我还是不主张限数量，不过要限制的话限一人两案也可以接受，毕竟一人非三开不可的情况确实比较罕见。另外让提案发起人多对讨论负责的方向也是好的，毕竟如果说需要一个人维持讨论秩序，那也一定是提案发起人了。这样也可以在规则上抑制不必要的集中开提案的行为，同时有助于讨论质量的提升。不过维持秩序的方法可能还需要探索。——Sirogohan（讨论） 2022年3月18日 (五) 15:17 (CST)
鉴于出发点是提高提案讨论和结果的质量，确实由发起人自觉控制、自行处理是更好的做法。只是大家的热情实在是过于震惊到我了，否则也不至于出此下策……如果早知道其他发起人也在准备这两天发起提案，我一定不会趁这个热闹发起并不紧迫的用户页面方针修正案的。——C8H17OH（讨论） 2022年3月18日 (五) 00:34 (CST)
(－)反对 未来也许可以有相关政策，我支持讨论中提案限制到3个。但我不认为现阶段发第六个提案来限制是有必要的，反而更加重讨论负担。
我不认为“提案发起人未有讨论中提案”是必要的。提案发起人很有可能发起两个关联提案，强制合并是不妥的，没有限制的必要性。
我不认为把投票和讨论算在一起是必要的。投票本就建立在讨论基本结束的基础上，我认为单独限制讨论数即可。用户本应该在讨论期间进行讨论，如果没有特殊原因，非要等到投票期才去看提案并在投票留言中发表大段意见是不推荐的行为。
 ——  ほしみ 2022年3月17日 (四) 23:48 (CST)
限制“提案发起人未有讨论中提案”本意是和限制讨论中提案总数相关联的，避免“同时进行的三个提案都是同一个人发起”的这种极端情况。但我承认你和Siro的观点有道理，我之前在群里也提到这样有使得提案发起人“憋个大的”的隐患。——C8H17OH（讨论） 2022年3月18日 (五) 00:37 (CST)
避免“同时进行的三个提案都是同一个人发起”有什么特殊原因么？我认为在发起人有余力的情况下，这是没问题的。 ——  ほしみ 2022年3月18日 (五) 00:59 (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)

我的观点是第三种。--CONTINUE TO FIGHT WITH OMICRON!·P. W. T.（萌利策奖提名） 2022年3月17日 (四) 23:46 (CST)
预讨论和投票中还好，讨论中太多就太累了（？）  库德里尔 ( 论 · 签 ) 留于 2022年3月18日 (五) 07:43 (CST)
(＋)支持辛醇想法2在目前的大量提案告一段落后将讨论中提案数量限制为3，其他提案要求使用预讨论可能会好一点。
同一个人的提案限制也应当有，我个人觉得应该至多为 以后决定的最大【讨论中】提案数-1。
还有就是长提案，如何界定，以及对于长短提案的限制，我还没想好早上好困，期待各位大佬的意见。  库德里尔 ( 论 · 签 ) 留于 2022年3月18日 (五) 07:58 (CST)
(＋)支持辛醇观点3 这个可以有，不过我有一个疑问：是否应规定，当发生重大公关事件等情况，以至于需要紧急提出解决方案时，可以忽略提案上限。--From   环保酵素签名提醒小助手（💬会客厅） 2022年3月18日 (五) 09:57 (CST)
比方说“特别地，至少一名管理员（还是行政？）声明为紧急议题的提案不受此限制”？  库德里尔 ( 论 · 签 ) 留于 2022年3月18日 (五) 10:13 (CST)
这个是准备交给行政员的特别权利。--CONTINUE TO FIGHT WITH OMICRON!·P. W. T.（萌利策奖提名） 2022年3月18日 (五) 11:44 (CST)
我觉得不一定要硬性限死提案的数量，我觉得可以设置为超过三个的提案在前面的提案进入投票前不计算三十天的讨论时限，等到前面的提案结束后再开始计算三十天时限。—SinonJZH(๑•̀ω•́๑)(讨论) 2022年3月18日 (五) 14:55 (CST)
关于类似于“推迟ddl”的规定，我昨天试着写了写，发现具体程序上稍微有点繁琐（）比如如果因为时间差，一直有其他提案发起投票，导致一个提案迟迟投不起来怎么办（）总之可能需要打磨下细节。——C8H17OH（讨论） 2022年3月18日 (五) 15:10 (CST)
@C8H17OH：我的意思是，不对投票或者讨论的提案作任何限制，只是推迟后续提案的时间限制而已。后面的提案甚至可以在还没开始计时时就开票，当然要讨论不充分肯定过不了就是了。我觉得这个政策主要就是保证每个提案的讨论质量，而不是为了限制数量而限制。—SinonJZH(๑•̀ω•́๑)(讨论) 2022年3月18日 (五) 15:26 (CST)

经过初步意见征询，萌娘百科讨论:提案/讨论中提案/关于限制同时进行提案数量的提案已经放出，欢迎各位讨论。因为我实在不能保证之后能找到提案密度降下来的时间而如果该提案通过则提案密度一定会降下来，所以抱歉发起第六个同时讨论的提案了。--CONTINUE TO FIGHT WITH OMICRON!·P. W. T.（萌利策奖提名） 2022年3月18日 (五) 15:37 (CST)

取自“https://moegirl.icu/index.php?title=萌娘百科_talk:讨论版/方针政策/存档/2022年03月&oldid=6249134”