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)
尴尬 怎么没讨论了..—— ほしみ 2021年10月15日 (五) 00:40 (CST)
尴尬萌百繁简转换日常没人关心。(+)支持 星海的观点。--枫叶·萌约者·伪娘·朔太郎(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)