Template:Sandbox/Chi ZJ2

在有人发现维护人员申请下有着可被归类的提问后，这份可兴可观可群可怨的选辑便出现了。

相同内容的提问

你对萌百当下的议事机制及效率有何评价，有何改良建议？
User:Luoxuchan	放到年初我可能会说现在的议事机制没有什么问题，但现在恐怕不能这么说了。虽然提案流程的规范和快速提案的出现让萌百的政策修正变得非常简便可行，提案或方针政策版一片欣欣向荣，但其他方面的不足如今也确实显露： 萌娘百科对于突发事件和应急事件的处置能力向来不足，马娘和BA事件常常让维护组成员焦头烂额，一讨论就是大半天。这几天我在其他的编辑组也经常看到有人讨论BA事件，大概的说法是萌娘百科官方的发声和处理都是暗戳戳还没什么章法的，就官方切片都咕了一两天才做出来最后扔到一个巡查的用户页底下就再没什么动作了。就我之前的回答已经说过我不希望这种事情闹大，不希望外宣那边官方B站微博微信之类的下场，但现在这个样子显然也不是什么最佳解决方法。这些事件让我感觉整个运营和维护这边都很拖沓，今天明天后天都在讨论一个点，感觉缺少一个很核心的，愿意淌浑水还具有公信力号召力的人站出来指个方向告诉我们究竟要怎么做，结果就让萌百的回应变成这种不足以扭转舆论的样子。什么议会都要有一个议长，而维护组很多时候的内部议事完全是在大家都“平等”但注定没什么结果的双方械斗。 运维和普通编辑之间出现的一些割裂。在上面的回答我说过，有些时候，维护组其实是和广大编辑者站在一起去面对运维的，比如 Moeskin 的上线让很多人感到不解：“怎么说上就上了，对社群意见的采纳在哪里？”这是一个运维方主推的事情，一旦是运维方推的事情，能探讨的余地就很小了。包括很多人对 Moeskin 提出的问题也是，维护组和普通编辑一样对它出现的问题只能提报给运维（最多可能是提报途径不同）但什么都做不到，我们作为维护组看到有编辑在技术实现版提报关于 Moeskin 的 BUG 只能苦等黑卡回复，而回复也往往是“有待商榷”或者“至少要等半个月才能修复”，确实会让人想提出“萌百是运维的萌百还是大家的萌百？”这样的问题。我没当过管理员，没有在管理员的位置上看待过这一现象，但就我现在的视角来看萌百确实是在从一个社区共建的百科变成那种“资本”、“体制”的网站，换句话说萌百在运维参与的一些项目上确实不那么平易近人了，我想这也是当前议事机制的另一个重大问题。 2022年6月15日
User:Leranjun	先说说议事机制的问题。 1029之后，我们看到了议事机制的很大变化。从政策上来讲，非常多的大型议事政策（例如提案、投票等）被修订，包括快速提案的制定对传统提案的效率提升了不少。从结构上来讲，我们看到了维护成员之间、以及维护组和其他用户之间更多的互动，并且运维方面也更多地听取了用户的意见。这都说明我们在与时俱进，是好事。 但是如我在给星海的回答中提到的，目前的讨论串、提案等方式还是很冗长，对于没有精力密切关注的用户不是很友好。一些讨论串内容复杂、改动较多，经常会有用户反馈“看不懂”；尤其是有票权的维护人员在活跃度压力下，更容易发生“随票”的现象。我希望在一些比较长的讨论串（包括提案）里能有专门的地方维护更简洁的TLDR版本，简述“大概改了哪些方面”。比如，在比较复杂的讨论串正文上方添加一个概要部分，由讨论串发起人或对讨论串内容主要关注的用户概括讨论内容，随讨论串中的讨论更新。对于人事案，可以参考HW版史记的记录方式，为比较长的回答列个提纲。就有点类似于GitHub上通过把上一个版本和这一个版本之间所有PR信息集合自动生成的更新日志那样，一个主要论点只要一句话就行，毕竟完整讨论就在下面。我觉得这样应该会更直观。 举个例子，如果我要对这个问题的回答做概要的话这何尝不是一种套娃，可能会这么写： 总体上议事机制在不断改进。 长讨论串难以理解，建议增加概要部分。 缺少外宣紧急情况的应对方案，需要进一步商讨对策。 站外编辑群讨论的合“法”性存疑，应当保证站内的意见征询。 正如我在概要里所提到的，我认为另外一点比较重要的是突发事件的处理，尤其是外宣方面。这一点其实珞老师在他的申请里有提到，无论是马娘还是BA，目前我们对于这种对外事件的处理方式依然没有系统化，就连维护组内部获取的信息也不完整。BA事件我是亲眼所见，有人建议运维出面控制舆论、有人建议继续谈判、有人建议调查编辑组成员、还有人根本不知道发生了什么，场面一度非常混乱。我是真心不想看到这种事情再发生一次。当然，这个话题牵扯到了编辑组的外宣能力和权限，我个人并不是最拿手的，但是我希望主要负责这块的用户（Siv）能够格外注意制定对策，用最短的时间查明真相并做出处理动作，而不是让我们被打得措手不及。另外，编辑组负责人也应当加强对组内用户、尤其是新手的管理与指引，不要让别人先抓住我们的把柄，导致一点小事被夸大、造谣，最后演变成公关危机。正如我在给二饼的回答中提到的，这个时候就体现出一个编辑组具有完备编辑指引和指南的重要性了。扯远了。 最后一点就是编辑组内部讨论的议事机制。很显然，目前编辑组大部分都依赖站外群组作为主要沟通工具，而这也是有它的优势的，毕竟即时通讯还是更方便、对新手更友好、也能提升讨论速度。然而，尤其是一些比较大的编辑组里，我有观察到一些处于“灰色地带”的讨论：这些讨论对站内内容进行了比较大的修改，却没有在站内留下痕迹，这实际上有违反MGP:编辑组指引中“没有站内讨论的情况下直接以编辑组的共识作为讨论依据”的嫌疑。我就不说具体是什么事儿了，不然感觉像在点名批评一样，但是有些从该政策设立前遗留下来的一些讨论习惯确实需要整改，保证编辑组政策的落实。我认为利用站外工具方便、效率高的特点达成初步的讨论共识是没问题的，但是涉及重大改动时必须在站内留下讨论串，不能排斥没有加入站外群组、或是对该“共识”可能有其他意见的用户。不光是编辑组，这其实适用于任何一种站外讨论。 2022年7月12日
User:TsanconBYin	这个问题得分两方面回答。 常规议事，包括正常提案等，大部分都已经趋于完善且相当多的决策已经能够公开化，除了专题编辑指引的相关更改的计票方式未有明文规定，目前默认了使用和提案一样的计票方式，但个人认为尚存争议，鉴于上一次想修这个的提案已经被否了，我暂且不提出别的意见。除此以外，对于目前要求维护人员集体参加相关议事的设定，虽然我是(＋)支持 的，但是也确实存在维护人员对相关事项不了解但是随票的情况。且现在的制度可能不一定让有相关经验的编辑者有效参与讨论（这一点在我主力的虚拟UP主专题尤为突出，已经有人指责专题指引是“少部分人的游戏”了）。对以上的问题，我认为在短期内通过小修小补不可能改善，相关制度的强烈惯性会使得这种修改适得其反。但这不意味着随着目前维护人员的增多我们就完全不去改变，我们假定以后巡查姬和管理员队伍按照现在这个速率持续增多，那么相对来说我们可能就需要稍微放宽一些对维护人员的要求，同时相应地稍微提升（或者维持也行）管理员就部分事项的决定性作用。（关于这部分我会在对刘君的回答中详细阐明，为节省篇幅在此不表） 应急议事，包括危机公关之类的，我只能用两个字形容：灾难。马娘组和BA组事件里面，明显可以由少部分维护人员以及运维解决的事情，到最后居然占掉了大部分维护人员的精力，且最后得到的结果也绝不能说满意（虽然确实有对方的问题）。至于运维，尤其是在BA事件的处理中，我感受到了与维护组一样的意见混乱。造成这种现象的原因，从维护组层面来说，是维护组本身的架构就决定了很多事情都是平面化交流，大家都是志愿者，啥事儿都来搅合，这其实极大降低了办事效率，所以对于这部分我们可能需要明确这些事情以后由谁接洽，其他人不要过多干涉。从运维角度说，没有专业的公关团队（或者明确的公关流程）这确实是一个致命伤，这是需要运维自己注意的，但考虑到运维目前正在进行的工作，我觉得是遥遥无期了。 2022年8月23日
你对萌百当下的用户权限体系及当前维护组成员架构有何评价，有何改良建议？
User:泠佛.	萌百目前的用户权限体系基本完备，但自确获取难度低确实是存在的问题。另优编的覆盖文件权限迟迟没有实装，若能尽早实装该权限，可能会极大减轻维护组成员的工作。对于维护组而言，缺人是一直存在的问题，如何让更多人尝试加入维护组仍值得我们思考。 2022年3月6日
User:Leranjun	说一下比较常见的两个类别的用户组。 维护用户组方面，能够明显感觉到的就是巡查人数明显变多了。我认为大体上来看这是一件好事，因为维护人数的增加代表维护组意见更加多元化，并且越来越多的专题有对应的维护组成员负责，站务处理也更加便捷、高效。然而，在巡查申请增加的同时，巡查的定位也变得模糊了起来，给一些用户一种巡查手里的权限“不值钱”的错觉。很明显申请巡查的难度和管理、行政相比是不成比例地容易，而巡查和管理之间的权力差异相当大，从“条目维护者”直接上升成了“全站指引者”，没有一个很好的过渡，因此巡查和管理之间的数量差异也越来越大。上一次修正案加入了维护人员提问和考核部分后，这个问题还稍微好了一点，但是实际操作中很少有人提问，多半是“申了就过”。当然，用RJ前辈的话说，我并不希望把巡查申请变成“政审”，也比较反感那种把每条贡献都排查一遍、然后揪着早期的几次编辑质疑的鸡蛋里挑骨头的做法。但是我认为巡查的授权还是需要谨慎，毕竟是官方维护人员，手里握着“挂删”、“评论管理”等关键权限，并且能够访问维护组内部信息。这对于保持维护组信息透明其实也有好处——如果巡查的平均站务处理能力变低，导致整个维护组内很难进行重要的站务讨论（或是没有足够的信任），相当于鼓励管理、行政私下解决问题，又变成1029的情况。处理巡查申请的管理员一定要避免降低巡查申请的门槛、让巡查变成“大号优编”。当然，我没有说以上情况现在有发生，但是我不希望在未来发生。 技术用户组方面，我认为“技编”、“脚编”和“界管”的添加尤其重要。这其实将技术用户组和维护组做了一个分割，把一部分原来管理、巡查才有的技术权限（包括原来对重要模板的保护）下放给普通用户，这对于没有精力申请维护用户组、但技术力较强的用户提供了一个非常好的途径来直接参与技术性内容的维护，而不用每次都让其他不是很懂的管理员传菜，是吧星海。但是星海技术力其实在不断提高，可爱 2022年7月12日
User:TsanconBYin	同样分两方面来回答。 维护组方面的权限体系我原本不想做更多的评价与建议的，但就之前的“大申巡时代”以及MINGach、Zyszhao两位未通过实习期，我认为我有必要指出，现在确实存在一种“巡查过热”的倾向。虽然从我上一个回答中能稍微体现出一点我对维护人员队伍壮大的希求，且巡查确实相比管理，算一个操作可逆度较大的权限组，但是就目前我们对巡查处理站务的有关要求，如果巡查注水，那对站务的处理也必然低质化，且毕竟巡查手里还有个封禁权，还能绕过33，在授权这方面不得不慎重考虑。 一般用户组方面，技术类我举双手双脚赞成，将部分技术权限拆分出去这无疑是一个让我这种毫无技术的人也有胆量申请管理的设置。争论的焦点可能还是在优质编辑者相关的问题，我化用一下乐然申请管理员时的回答，就是优编在编辑者心中逐渐变成了一个“小号巡查”，很多人自申优编的时候都开始拿巡查的标准来套，这实在是离天下之大谱。对此有人说希望将优编重新改回巡查豁免，我觉得这样造成的社群反弹会很大，但是相对应的我发现目前确实有利用过滤器实现“优编保护”的情况，因此我在想能否将优编直接改造成一个类似于手确之于自确的用户组，所对标的是一个新设置的延确组或者这种情况是不是该叫做自动优编，以适应新的保护需要，同时也算是给优编一个相对来说配得上称号的权限解决这种不平衡问题。 2022年8月23日
请您就管理员的权限及其设计谈谈对「System operator(Sysop)」和「Administrator(Admin)」这两个词的理解。
User:TsanconBYin	我个人的理解的话，前者是管理员权限列表的代表符号，后者则是管理员社群影响力与责任的一面。 2022年5月14日
User:Luoxuchan	我不懂英语。现在萌百的管理员是叫 SysOP，我觉得这个管理员就是一个比 Admin 更狭窄的东西，像 Windows 的计算机管理员就是 Admin，那个“Administrator”账户拥有能改变系统几乎一切的权限，而萌百不行，萌百上头还有行政员，或者说最大的问题是很多决策行政员也没办法拍板（后边还有运维呢）。总而言之我认为萌百的管理本身没有那种可以控制一切的条件，萌娘百科管理员不是山大王也不能是山大王，只是管理体系的一分子，这和 Windows 系统里面那种统治一切的 Administrator 还是有很大不同的。 2022年6月15日
User:Leranjun	哦我的上帝啊，感谢圣母玛利亚，我终于可以在这个地方看见英语了。老伙计，我敢跟你打赌，霍稀泥（Hoshimi）小姐根本就不懂英语，简直就像老路德维希(注)路德维希·凡·贝多芬（德语：Ludwig van Beethoven；1770年12月16日－1827年3月26日），德意志作曲家、钢琴演奏家。大谈米开朗基罗一样一派胡言——对了，你喜欢喝茶吗？ 直译的话，“sysop”表示“系统操作者”，“administrator”表示“管理者”。看一下词源： Blend of system + operator. — wikt:sysop#English Borrowed from Latin operatōr, from operor (“work, labour”). Equivalent to operate + -or. — wikt:operator#English From Latin operātus, past participle of operārī (“to work, labor, toil, have effect”), from opus, operis (“work, labor”). — wikt:operate#English Borrowed from Latin administrātor (literally “he that is near to attend”). — wikt:administrator#English From administrō (“attend upon, assist”), from ad- (“to”) + ministrō (“attend, manage”). — wikt:administrator#Latin From minister (“attendant”). — wikt:ministro#Latin 也就是说，sysop来自于“工作、劳动”，而administrator来自于“注意、协助”。 我认为其实这两个词描绘的是同一个职位的不同方面。从管理员的职务方面，sysop是“系统”的“操作者”，代表管理员的“执行力”。一个好的sysop需要保证操作合理得当，做出每一笔操作时都清楚原因和后果。尤其是在作出影响范围较大的操作时（例如批量删除替换、修改影响全站的过滤器及代码等），应该谨慎谨慎再谨慎，尽量避免技术错误。从管理员的影响力方面，administrator是“服务者、管理者”，代表管理员在社群中的威信与职责。一个好的administrator需要保证自己在社群中有着与自己权力相符的信誉，才能做出有益于社群、提升社群满意度的事情。我再重申一遍，群众是监督的力量，也是管理者执政的基础，一个不为普通用户着想的管理者不会被社群所信任，也不可能有领导、指引社群的能力，更别说处理社群事物了。 2022年7月9日
在萌百当下的维护人员的用户权限体系及当前维护人员架构下，我们对维护人员在出现重大站务时参与度有较高的要求，这对专注于一个或数个特定领域/主题的维护人员是不太友好的。那么您认为这种让所有维护人员都参与到站务中来的思想是否有其局限性和改进空间呢？
User:AnnAngela	身在其位应谋其事，在现在拥有技术编辑组的情况下，维护人员应更集中于站务方面的参与，我不觉得该思想有其劣势，至多是相关制度应应时调整； 2022年1月3日
User:泠佛.	管理员拥有很多高级权限，如更改巡查姬等用户组、大量删除页面等；也拥有部分涉及用户隐私的权限，如查看、修改私有过滤器等。所以对申请人提出了很高的要求，其必须拥有独立思考、判断能力，能够倾听社群的意见，被社群信任。 2022年3月6日
User:云霞	我的看法如下： 就巡查姬而言，实际上除了重大事项的投票之外，没有要求巡查姬做太多的、额外的全站站务的关注事务，传统上巡查姬的提权往往也是由于对某几个领域的优秀编辑而得到能力上的认定的。 对于管理员而言，以目前来说管理员的数量是严重不足的（甚至可以说是历史以来比例的最低值），这很大程度上是对管理员的要求所导致的。 不过我也认为，在技术用户组拆分之后，管理员申请所需要的技术门槛降低了。可以鼓励更多对站务感兴趣，同时有一定站务能力的巡查姬加入管理员团队，这是一件好事。另外目前随着方针政策的细化（我不是很认同“细化”这一趋势）以及技术用户组的实行，也需要更多的管理员“分管”各个站务方向，这个问题我认为正在变得逐渐迫切。 对于局限性和改进空间的问题，我认为是一个循序渐进的过程：只有管理员数量逐渐提高的时候，在站务上才可以逐步降低对管理员“全部参与”的要求——我也认为很多目前的巡查具有成为管理员的潜质。 2022年2月7日
User:TsanconBYin	能面面俱到的人我觉得是不存在的，比起让人闭门造车，给所有维护人员设置一个义务去关注其他方面，或者至少看一眼，未尝不可。更好的制度或许存在，但是有没有可执行力我得打一个问号。 2022年5月14日
User:Luoxuchan	我认为只要是维护组成员就应具备对整个站点的，一定的信息掌控能力（并不是说要什么都了解透彻，至少知道有这么个事儿），而且“重大站务”（包括影响活跃度的投票、一些类似1029的处罚决定）影响力是波及整个站点的，即使维护组成员在进入维护组之前编辑范围非常局限，在作为维护组成员之后对这些很重大的需要全体维护组成员参与的事情都应该有一定的了解和自己的想法。所以我觉得现阶段的参与度要求并不是什么问题。而且我本身也是窄范围维护组成员，对这种事情还算应付得来（何况还有至多连续三次的不发表意见的次数可用）。 2022年6月15日
User:Leranjun	稍微分三个部分回答。 我认为“让所有维护人员都参与到站务中来”这个思路是正确的。作为维护人员，本来就应该对各种站务处理都有经验。即便是对于像我这样编辑范围一只手能数的过来的维护人员，万一类似的事情发生在自己主要维护的条目上怎么办？ 3次投票的活跃度要求，我觉得还行，基本上够用，也很少看到有人因为这个被撤职。但是我有一点顾虑，就是会不会因为活跃度要求而导致浊华前辈上面所说的“随票”的情况。不管是因为忙还是因为对内容不感兴趣，一定有不想完整阅读提案和人事申请讨论串、但是由于活跃度要求不能投弃权而不得不按照“大趋势”来投票的情况，这个时候就很难听见反对声音。我之前确实是有体验过短期忙碌、又不到请辞程度的时期，如果赶上提案和申请密集就会相当麻烦。或许可以考虑在3次的基础上加上时间限制？例如3次未投票间隔大于等于14天之类的。当然，只是个想法。 至于其他的“重大站务”，尤其是公关和外宣方面，大部分维护人员能够参与的程度也比较有限，主要还是需要与运维和行政商量。 2022年7月9日
在理性权衡利弊的前提下，如果跳出方针/指引的框架去做某些事情会得到更好的效果（即所谓的“滥权”），您是否会选择去做？如果是，请说说大致会怎么去做；如果为否，请说明原因。
User:Luoxuchan	就我个人而言会比较严格的遵照方针和指引的框架，最多可能会仔细去抠方针指引的内容做一些能从政策文件上解释通的事情，但是直接跳脱出这个框架来滥权会比较困难。上文我阐述了自己的一个观点，即管理员不是山大王，确需滥权的话这种事情还轮不到我做，或者，轮不到我仅凭自己的判断去做。我认为自己的主观判断不可靠，如果有复数个管理员和我持同样的观点，去执行这个“滥权”的大概也不会是我。 2022年6月15日
User:Leranjun	我认为“理性权衡利弊”的前提下不会出现“跳出方针/指引的框架”的滥权——如果有，说明方针政策出大问题。以目前的政策文件来看，基本上都有兜底条款，很难真的跳出这个框架执法。目前我所见到过的“滥权”顶多就是在一些细节上——比如撤销或回退编辑、判定条目质量、封禁破坏者这种有主观因素存在的操作里——夹带一些私货，但是这种情况也主要以方针政策为基准。我个人会尽量在日志里留下相关政策的链接，这样一方面可以justify这类操作的合法性，另一方面也能提醒那些因不了解政策而犯错的编辑者、帮助他们认识到自己的错误，而不是只是让他们认为我在“滥权”，然后下次被其他维护人员警告。退一万步讲，就算真的遇到方针政策解释不了的问题，我也认为应该先向其他维护人员求助，而不是冒失地进行可能会“滥权”的操作。说不定真的就是方针政策需要修改了呢？ 2022年7月9日
如何看待各类申请提问中的“为问而问”的现象，以及您有何建议或意见用以改善“没回答提问→投反对票”这种逻辑错误的情形。