维基百科:申请成为界面管理员/LuciferianThomas
现在的日期与时间是协调世界时2025年5月28日16时05分。※按此更新
|
投票现已结束！ |
| 请勿再作任何投票或改票，否则会被视为废票。 |
 | 本投票为人事任免投票，投票者须符合相应投票资格。检查本页编者资格
在管理人员解任投票联署或上任投票开始之前，注册满七天且符合以下两项之至少一项条件者有权投票：
|
- 申请者：LuciferianThomas（讨论 | 贡献）
- 自述/提名词：自荐成为界管。
先是维护DRN-wizard等自己留下来的技术债，未来逐渐学习维护其他script。对修订维基百科模板和模块有相当经验，可尝试协助维护。还有，可以辅助过滤器编辑者职务，增添和修订既有的过滤器讯息。--路西法人 2025年3月29日 (六) 10:45 (UTC)- （依安忆君之意见，更新申请自述，厘清申请界面管理员的能力要求和工作目标）
- 我是机器人User:LuciferianBot（使用NodeJS设计）的维护者，并在本站有数个自己或多或少客制化过的小工具，具备维护JavaScript脚本的经验；亦曾在本站编辑不少模板样式。另外，亦有自己管理的私有外部站点，从中获得在MediaWiki系统维护JS和CSS的经验。
- 我若获选为界面管理员，会处理以下工作：
- 维护自己引入的技术债（WP:争议解决布告板/请求使用的MediaWiki:DRN-wizard.js）；
- 设计其他布告板的类似提报脚本（供没有使用Twinkle等小工具的一般和新手用户）；
- 协助维护MediaWiki:Common.css（分拆模板样式、跟进Vector-2022更新暗色模式下的本地样式）及维护既有没有正式维护者的小工具；
- 使用界面管理员权限辅助过滤器编辑者职务，增添和修订既有的过滤器讯息；
- 协助处理界面讯息的编辑请求，尤其是通常没人处理的杂务请求。
- 综上，我认为我具备成为界面管理员的技术能力，亦有获得权限后贡献的目标，因此自荐成为界面管理员。--路西法人 2025年4月14日 (一) 03:36 (UTC)
- 提问时间：2025年4月11日 (五) 08:59 (UTC) － 2025年4月25日 (五) 08:59 (UTC)
- 投票时间：2025年4月22日 (二) 00:00 (UTC) － 2025年5月6日 (二) 00:00 (UTC)
意见
[编辑]安忆
[编辑]- 作为界管，结合目前权限的分配及其目的，我逐渐认为编辑MediaWiki空间的非JavaScript和CSS等“技术类”页面是管理员的工作。现在界管可以，或许只是当时偷懒把MediaWiki空间整体划给了界管而已。申请理由里提到“可以辅助过滤器编辑者职务”，我认为这不是一个合适的期望，因为在这方面界管的权限不足。比如当前MediaWiki_talk:Abusefilter-warning-dkyc-removal页面上的编辑请求，如果我没理解错他的意思，是要禁用这个过滤器并删掉相关页面，界管做不到这些。加之这种需求很少，管理员又很多，所以我有如此看法。另外“对修订维基百科模板和模块有相当经验，可尝试协助维护”这个理由，这是模板编辑员的活吧。我认为Diskdance才真的是在义务做前端开发，并有了一些成果。--安忆Talk 2025年4月11日 (五) 11:25 (UTC)
- 您好，感谢您的意见。
- 回应“编辑界面讯息是管理员的工作”及“偷懒把MediaWiki空间整体划给界管”：不论是m:WM:IA还是en:WP:IA，虽然界管权限专授予管理员，但仍然分别明确界面管理员可以编辑MediaWiki空间的界面讯息。对界面讯息及小工具的编辑请求不时有一些MediaWiki的杂物积压，也有相当一部分的不需要等待开发者就能修订的请求。在MediaWiki不断更新Vector-2022皮肤的同时，也有通过MediaWiki:Vector-2022.css及其他方式配合如暗色模式的界面显示修订、临时抑制更新带来的界面错误；还有比如时昭君MediaWiki:Common.css中逐步将部分CSS重新拆分至TemplateStyles的工作。此等工作正是我若持有此权限能处理当前缺乏人处理的工作。
- 社群仍未接受“Limited administrator”的概念，如此我认为社群尚无“给了权限，但有部分工作XXX不能做”的期望，那自然界面管理员也应顾及编辑界面讯息的工作。很多时候一些简单的杂物反而拖很久都没人处理。所谓“工作少而管理员多”并不符合实际情况，“管理员多”但真的做事的管理员两只手数都还有剩手指，当中真的去动界面的更是少之又少。界面管理员编辑界面并非只能专注于前端开发，还是可以在己所能及下处理社群给予的权限可以做到的工作。
- 回应与过滤器编辑者权限的关联：我现在持有过滤器编辑者的权限，在有需要时可以按共识协助创立过滤器，但到需要为过滤器加上警示讯息时，又要等管理员才能处理。当前管理员权限部分下放给社群熟悉特定工作的用户（如编辑过滤器），而管理员众所皆知在处理杂物这一方面人手比较不足，那么在下方的组别中有一两个能处理增加过滤器讯息这种杂物的用户对社群运作畅顺是意见好事。
- 详细例子：随着MOS:FLAG的修订，过滤器343需要更新，直接阻止用户新增国旗模板。我一直很想去更新这个过滤器，但自己改了过滤器又要等管理员去协助修改MediaWiki:Abusefilter-disallowed-mos-nationality，会出现非常明显的时间落差，所以343的修订一直搁置者。在我确信自己不能胜任管理员的情况下，我仍能通过同时持有过滤器编辑者及界面管理员两个权限去做一些我有能力处理此类工作。实际上，我会说确保过滤器警示讯息准确与编辑小工具等script的重要性相当——过滤器警示讯息影响所有用户（尤其是新用户）编辑时所接触到的指示，在社群有能者可以协助修订过滤器的这个时间点，确保能广由大部分用户接触的警示讯息能跟上过滤器的创建、修订、停用是相当重要的事情。
- 回应与模板、模块编辑的关联：MediaWiki空间不少界面讯息是需要使用到ParserFunction的wikitext，虽然我目前没有模板编辑员权限，但编辑模板、模块的经验却仍然是MediaWiki空间编辑界面讯息不可少的前设经验。我上面自荐词并非说自己想申请这个权限来维护模板模块等，而是提出自己有此等经验而已。
- 回应“编辑界面讯息是管理员的工作”及“偷懒把MediaWiki空间整体划给界管”：不论是m:WM:IA还是en:WP:IA，虽然界管权限专授予管理员，但仍然分别明确界面管理员可以编辑MediaWiki空间的界面讯息。对界面讯息及小工具的编辑请求不时有一些MediaWiki的杂物积压，也有相当一部分的不需要等待开发者就能修订的请求。在MediaWiki不断更新Vector-2022皮肤的同时，也有通过MediaWiki:Vector-2022.css及其他方式配合如暗色模式的界面显示修订、临时抑制更新带来的界面错误；还有比如时昭君MediaWiki:Common.css中逐步将部分CSS重新拆分至TemplateStyles的工作。此等工作正是我若持有此权限能处理当前缺乏人处理的工作。
- --路西法人 2025年4月12日 (六) 01:33 (UTC)
- 也恕我比较直白说：当前界管只有安忆阁下非管理员，您所说“您逐渐认为编辑界面讯息是管理员工作”的唯一参考值是您自己不太碰这个工作。在您不碰这些工作的情况下，自然只有管理员会去做这些工具（因为除去您，其他可以编辑界面讯息的用户都是管理员），我不认同您自己作为唯一参考值的情况能作为“编辑界面讯息是管理员工作”的论据。--路西法人 2025年4月12日 (六) 01:47 (UTC)
- 我不是管理员，所以才结合现状和我的经验，在此提出一些不同的意见以供参考。首先要说的是，我没有表达社群有“‘给了权限，但有部分工作XXX不能做’的期望”的观点，不是“不能”；僧多粥少也是事实，符合实际情况，是否有人摸鱼这点不是很影响我的一些观点；我也没有表达“界管只能专注于前端开发”，但不可否认的是，这是其最核心的内容。在你直白说之前，或许可以试着再理解下我的看法，我自认为我的表达还算清晰。
- 我认为上述之中极大部分目标都可以由管理员更方便地执行，所列工作中和界管最有关系的地方是MediaWiki空间的普通页面，但界管只是能增改它们而已，甚至不能删除。如果以这个为由，我认为日后行事上肯定会有些受限。同时，MediaWiki空间的编辑请求其实没有那么多，其中JS/CSS的重构和修改是一件相对复杂的事情，我认为以学习为由先行取得这个权限不是很合适，应该自证下这方面的能力，或像Diskdance一样做出一些成果，毕竟这才是界管的最基本的工作。至于这空间里的普通页面，我们有远比界管多几倍的数十位管理员，他们处理起来更方便、合适。最后，我不认可编辑界面消息和模板、模块编辑有关的说法，这些之间的经验基本上没有关系。
- 我不是在彻底反对什么，而是在说以上需求作为管理员会更方便、合适。也恕我比较直白说：就上述需求而言，建议试试申请管理员以更好地参与贡献，界管不太适合你的这些需求。我们不需要管理员本身是全能型人才，每个人都有自己擅长的方向。但话虽如此，如果真的成为管理员，还是希望你不要处理事务性的、讨论颇多的内容为好。--安忆Talk 2025年4月12日 (六) 06:51 (UTC)
- “前端开发是界管工作的核心内容”这一部分仍然是无社群共识体现，这个所谓“最核心的内容”仍然是阁下以仅您自己一个数据点而作出的定义。界面管理员跟管理员一样是功能性权限，本质上没有“工作的核心内容”，也不是为了某个目的、解决某个问题才设立／分立的权限，所谓“核心工作内容”仅是您的个人定义。
- 您所说“上述极大部分目标可以由管理员更方便执行”，惟一般而言我前述所有工作都不需要实质的删除权限，所谓“甚至不能删除”根本不影响我前述任何工作。过滤器编辑者停用过滤器，根本就不需要真的去删除过滤器提示页，停用了就用不着那个界面提示。
- 回应“MediaWiki空间的编辑请求其实没有那么多”：如果真的如阁下所言“管理员足够多、编辑请求其实没那么多”，那么不应该存在任何积压的理由。现在存在积压即代表问题存在。
- 回应“其中JS/CSS的重构和修改是一件相对复杂的事情”：我的机器人都是用JS写的。我自己还有一个自己host的私设外部站点，该站使用Citizen皮肤不能直抄中维所有CSS，还是有很大程度的本地化和魔改来处理的。我说“学习维护其他script”，在于我未仔细研究其他JS脚本，需先研究个别script的涉及才能维护的意思，并非我利用这个机会来学习如何写JS和CSS。
- 另外，还是请不要再拿“数十位管理员”来说事，您我很清楚知道这群管理员绝大部分都是不活跃、不工作的，实际上在站内活跃处理界面事务的管理员没几个。
- 我也很清楚自己不适合任管理员，但事实上我具备处理过滤器相关的界面讯息的工作需求，也具备写和修JS、CSS的能力。我必须指出界面管理员权限相对于管理员权限更贴合我的站务工作需求。管理员有很多我用不着的权限，但界管确实刚刚好能涵盖所有我需要也具备能力做的站务工作，所以申请界面管理员权限远比申请管理员适合我。
- --路西法人 2025年4月12日 (六) 07:45 (UTC)
- 我不认同第一点，界管是为了特定目的、避免一些问题才设立/分立的，数个核心权限正对应了前端相关工作，居然说无社群共识；三和五提到的占着茅坑不拉屎是另一码事了，大可在别处单开个讨论串去谴责。管理员可以修改界面消息，可以修改过滤器，可以修改模板模块，可以做很多事情，我认为它可以帮你更好地做出贡献，即便会有些权限用不到。我对这个交流颇感无语，这有什么好煮的，恕不再回复。--安忆Talk 2025年4月12日 (六) 08:51 (UTC)
- 界面管理员一职是MediaWiki的默认设置，不是社群自己为解决某些问题而设置的，乃是功能性权限，不是因社群共识认为需要解决某些问题而分立的用户组。不论是中文译名还是权限英文原名，都指明“界面”“interface”，权限功能当然包含编辑其他的界面讯息，这是“顾名思义”的部分。我不理解为何您自己不去翻讨论，还因为我指出权限本质非您一人所言而订就恼羞、“无语”？--路西法人 2025年4月12日 (六) 09:06 (UTC)
- 请阅读m:Creation_of_separate_user_group_for_editing_sitewide_CSS/JS。--安忆Talk 2025年4月12日 (六) 10:59 (UTC)
- 这不是社群共识啊。倒是“编辑CSS/JS以外的界面页”是元维基有关讨论中多次提起的讨论议题。另外多个站点也曾设可以编辑包含一般界面讯息在内的界面空间页面的权限。讨论中也有提到全域界面编辑者也可/会编辑CSS/JS以外的界面空间页面。
- 我并不反对您所说“界面管理员主要工作是编辑CSS/JS”，但我无法同意您主张“有意编辑其他界面页面者不适合申请界面管理员”。
- 我也无意跟阁下继续为界面管理员未曾明确定义的scope争论。我申请此权限，既会协助维护CSS/JS（包括自己引入的技术债），也打算新写更多像是MediaWiki:DRN-wizard.js直接用于社群页面（尤其是布告板）的脚本（取代仲裁委员会、傀儡调查、当前的破坏等页面使用替换模板提交提报的功能，目前有部分缺少指示）；另外也会打算善用权限给予我的编辑空间，辅助我其他职权的工作，以及协助refactor/分拆。请不要再说得好像我永远不会碰JS/CSS页面那样了。--路西法人 2025年4月13日 (日) 00:43 (UTC)
- 说自己不想继续和我对界管未曾明确定义的scope争论，我认为挑起争论的不是我，在那些个段落里我表达的意图也不是争个到底如何。你现在又认同“界管主要工作是编辑CSS/JS”了，上面我说“前端开发是界管工作的核心内容”的时候却被回复说这“核心内容”仅是由我个人定义的，我认为CSS/JS还是算前端开发的，“主要工作”和“核心内容”的意思也大差不差。
- 说我主张“有意编辑其他界面页面者不适合申请界面管理员”，我的主要看法局外人都能看出是“认为管理员权限可以帮你更好地做出贡献”。当然，你最初的申请理由和现在加粗的那个还是很有区别的，我的看法只对刚开始的那个负责。没人说你“永远不会碰CSS/JS页面”，只看你最初的申请理由，里面提到的绝大部分需求都可以由管理员完成。极少的编辑CSS/JS页面的需求会用到界管的权限，但这时候你大可以先像Diskdance一样，提EP，先做出一些成果。相比之下，我认为你更需要管理员的权限。
- 唉，煮多了是这样的。是的，正如你所说，我因你指出权限本质非如我所言就恼羞成怒、狠狠无语了，我就是在争这个，就是如此反对你呢。纵览全文，我因你直接把我当成反对者并放到对立面，看不懂好赖话且抓不住重点、分不清主次，些许无礼甚至开始左脑攻击右脑的行为和表达再次感到无语。拜托你静下心来吧，想想我说的，也看看自己说的。--安忆Talk 2025年4月13日 (日) 04:38 (UTC)
- 我只是在说我的意见，意见是“我认为你更需要管理员的权限”，不是反对投票。不需要大费周章地回复了，就到此为止吧，谢谢。--安忆Talk 2025年4月13日 (日) 04:42 (UTC)
- 既然我有意担任界面管理员，那我认为确实有存在厘清我可以行使的权限的范畴。说到“主要工作”和“核心内容”，确实有很大的差别。“主要”只需要是majority；“核心”则得是“最重要”或“根基”的意思，我并没有同意这是界管的“核心”工作。我并非认为你是反对者，只是这次我非常客气、礼貌地论述我的观点，全程未曾批评您的做法、澄清自己为何申请界面管理员权限。我唯一直接指向您的就是认为您不能以仅有自己可以参考的情况以偏概全就说是整个权限的“核心”，不知是否阁下对于我过往与其他维基人的互动而存在偏见。我能够理解这样的想法和对我的观感，但我确实不认为这次我有“不冷静”地吵。
- 我完全能理解您指出我当初申请时未有清楚指出我可以做的事情的说法，我为当初未有说清楚表示非常抱歉，也能一定部分理解为何您起初相当不同意我的申请理由。我希望在我指出我可以使用此权限做的工作后。我不会去拉票、希望您能因此理解、从而支持我去参选，但起码我希望您能理解我的观点。即：我认为这个权限最贴合我需要去完成的工作，也就是我能善用这个权限带给我的空间，因此而申请；而非这个权限是否比较适合去做我想做的某些事情。--路西法人 2025年4月13日 (日) 09:25 (UTC)
- 在此也感谢您的指导。纵使我们不可能同意对方的某些观点，但我能看出您是为了确保我适任而提出的观点，而非仅仅为了批评我而提出的情绪性意见（虽然中间确实参杂了少许情绪）。这里您没有侵入到我不能有一丝退让的观点，所以我也不会跟您争个你死我活。希望这串讨论是以和而不同解决。--路西法人 2025年4月13日 (日) 09:29 (UTC)
- 请阅读m:Creation_of_separate_user_group_for_editing_sitewide_CSS/JS。--安忆Talk 2025年4月12日 (六) 10:59 (UTC)
- 界面管理员一职是MediaWiki的默认设置，不是社群自己为解决某些问题而设置的，乃是功能性权限，不是因社群共识认为需要解决某些问题而分立的用户组。不论是中文译名还是权限英文原名，都指明“界面”“interface”，权限功能当然包含编辑其他的界面讯息，这是“顾名思义”的部分。我不理解为何您自己不去翻讨论，还因为我指出权限本质非您一人所言而订就恼羞、“无语”？--路西法人 2025年4月12日 (六) 09:06 (UTC)
- 我不认同第一点，界管是为了特定目的、避免一些问题才设立/分立的，数个核心权限正对应了前端相关工作，居然说无社群共识；三和五提到的占着茅坑不拉屎是另一码事了，大可在别处单开个讨论串去谴责。管理员可以修改界面消息，可以修改过滤器，可以修改模板模块，可以做很多事情，我认为它可以帮你更好地做出贡献，即便会有些权限用不到。我对这个交流颇感无语，这有什么好煮的，恕不再回复。--安忆Talk 2025年4月12日 (六) 08:51 (UTC)
- 您好，感谢您的意见。
XComhghall
[编辑]管理员选举仅决定能否信任、授权，相信候选人会善用权限，不管“是否需要更多管理员”。界面管理员似乎没这么说，但我想也类似。路西法人 LuciferianThomas 在用户页公然反对解任 Mys_721tx 的多数意见，称共识为“扰乱”“暴民政治”“违规滥罢”。所幸执行共识非界面管理员职责。或许暂且可以授权。— 𝕏ℂ𝕠𝕞𝕙𝕘𝕙𝕒𝕝𝕝 talk 2025年4月22日 (二) 17:56 (UTC)
- 当前的管理人员选举和解任机制显然不是“共识制”，该次解任案也有一大堆我可以拿出来论证违反解任方针的流程及行为问题。您这种意见就是典型解决提出问题的人，那您们不合规的操作都可以成合规了。够胆就把该案所有论据事实拿去仲委会审理，看看该解任案那一大堆毫不合规的操作如何能站得住脚。送去仲委会审理时我绝对乐意奉陪。--路西法人 2025年4月24日 (四) 04:48 (UTC)
问题
[编辑]糖
[编辑]界面管理员具备在数以万计的读者和编者的设备上执行代码的能力。你采取了什么手段来保障你的账号安全？你可以从多个方面回答这个问题。 Stang★ 2025年4月14日 (一) 01:41 (UTC)
- 感谢Stang君的提问。我这个账号使用每一段时间就更换的高强度随机密码，并已经启用双重认证（2FA），确保账号安全。--路西法人 2025年4月14日 (一) 03:39 (UTC)
- 我竟然写漏了：定期复检自己额外安装的用户小工具安全性，防止从账号内运行可疑脚本危害账号安全。--路西法人 2025年4月20日 (日) 00:34 (UTC)
- 你提到用户小工具的话，那我就顺势追问一下你对于这个段落的看法。 Stang★ 2025年4月22日 (二) 01:28 (UTC)
- 感谢提供信息。载入用户小工具时使用固定链接是很可取的账号安全保护方式，理论上取用任何可由用户任意编辑的脚本都最好使用固定链接。就当前而言，我一般只直接载入由自己或可信开发者用户空间下的脚本。我确实认为最佳做法仍是“不要信任任何其他人”，全数采取固定链接方式载入用户小工具脚本，避免任何风险；但基于对Xiplus、白磷等开发者的账号安全信任，风险似乎可以形容是极低。我接下来会审视一下是否有任何我取用而未必可信的用户小工具，并以固定链接方式更好保障账号安全。--路西法人 2025年4月22日 (二) 13:52 (UTC)
- 你提到用户小工具的话，那我就顺势追问一下你对于这个段落的看法。 Stang★ 2025年4月22日 (二) 01:28 (UTC)
安忆
[编辑]- 如果用户报告某脚本在移动版页面失效，你的排查步骤是什么？
- 如何定位一个导致页面加载缓慢的Gadget？优化策略有哪些？
谢谢。--安忆Talk 2025年4月14日 (一) 08:04 (UTC)
- 回应问一：
- 首先固然是确认脚本本身兼容移动版页面以及用户系统。很多脚本本身不能在移动版使用，也不能排除提报是因为有人在用一些过时的浏览器或系统版本。当然不要浪费时间在不兼容的情况上。（补充非与您问题直接有关，但社群可能想知道我设计脚本的考量：我提到要设计的布告板脚本必然需要考量移动版设计，以前布告板使用preload模板的方法无法在移动版使用）
- 其次，是使用电脑上的浏览器使用如开发者工具等查看错误所在。有错误的情况当然直接看看是什么位置出错；没有错误的情况就可能要看看脚本是否尝试修改某些移动版没有的界面。
- 还是得看看是否有些功能在流动版没法使用（mouseover等）。
- 如果是针对移动版的排查步骤就是这样，后续就是通用于一般情况的排查步骤。问二稍后回答。--路西法人 2025年4月14日 (一) 14:09 (UTC)
- 如果我没理解错您的问题二：我可以使用ResourceLoader的debug模式，在浏览器开发者工具查看各脚本的载入时间，查看是哪个脚本载入缓慢。另外，在参数设置逐个停用小工具也是比较粗暴但能够帮助排查载入缓慢的小工具的方法。避免将仅在少数页面由用户触发的脚本移出小工具、最小化JS/CSS脚本代码、避免重复和过多的DOM操作或聆听Event、等待页面完成载入再载入脚本等都可以在各方面优化载入页面的时间。--路西法人 2025年4月15日 (二) 06:01 (UTC)
桌
[编辑]为避免恶意软件进入您的工作站，请问您采取了哪些措施？为防范供应链攻击，请问您采取了哪些措施？对于某些以 curl -fsSL https://... | sh 作为安装方式的包，您是怎么处理的？Bluedeck 2025年4月18日 (五) 20:22 (UTC)
- 回应第一问：Mac之上再加防毒软件、定期更新系统和软件、使用与主要系统隔离的虚拟环境、避免点入可疑邮件、避免下载可疑附件/网络文件。
- 回应第二问，若专指在界管职权上发布脚本：保护维基百科账号安全（已在回应其他用户时详细说明此部分采取措施）、发布前先找其他界管和本地开发者做code review、避免使用第三方dependencies。（中文好难）
- 回应第三问：使用与系统隔离的虚拟环境、限制运行权限（root）。--路西法人 2025年4月20日 (日) 00:33 (UTC)
- 感谢您的回答。对于一些难以避免的sudo sh的确是装到vm里remote进去开发是最安全的做法。祝你选举顺利。Bluedeck 2025年4月23日 (三) 09:18 (UTC)
Eric的小问题
[编辑]你觉得本站与界面管理员有关之站务工作，何处积压最为严重（可不限于一种）？且为何如此，又如何解决为宜？—— Eric Liu 創造は生命（留言・留名・学生会） 2025年4月22日 (二) 22:36 (UTC)
- 感谢Eric君的提问。
- 简答：编辑请求，尤其是界面讯息和没有开发者集中维护的脚本，改善界面讯息等；没什么特别的解决方法，有个愿意做这些杂务的人去动就是了。
- 长答：其实很多脚本都只是辅助工具，不是维基百科运作上很critical的工作；这就是为何我不同意上方安忆君所说开发、维护小工具是界管的“核心”工作，真的是“核心”的小工具（如Twinkle或全域小工具）有特定任管理员的开发者长期维护，其余大部分小工具除了确保安全外真的没有很需要很多精力去维护。真正会“积压”的界管工作，会是(1)社群开始逐步分散更多权限后，以及修改方针指引后，跟进更新界面讯息、过滤器讯息；(2)改善界面讯息给新手的引导作用等，都是往往被忽略（甚至是没人提出，仿佛不存在）的工作。
- --路西法人 2025年4月23日 (三) 04:33 (UTC)
- 感谢答复！—— Eric Liu 創造は生命（留言・留名・学生会） 2025年4月23日 (三) 07:05 (UTC)
结果
[编辑]所有投票附言
- 该用户在Mys 721tx的RFDA中态度恶劣，对其他用户出言不逊，本人不信任其获取界面管理员权限。
- 维基百科活跃用户里面最不适合当管理员的之一，不过当界面管理员还是可以的，支持一下吧。
- 撐路西法人！
- 德不配位
- 與他人正常溝通而不是動輒起衝突是擔任一切維基百科職務的基本素質，尊重不同意見和建議是在維基百科執行權力的必要前提，不認為被選舉人有基本的溝通能力以勝任任何管理職位，也看不出被選舉人能做到對不同意見的起碼尊重。
- 收集帽子
- 反对。不信任。
- 能力對口
- 相信该候选人的沟通能力和学习能力
- 曾经和这名用户有过不少互动。尽管其中包括一些意见相左的互动，最终还是对此名用户抱有很高的信任。
- 前端能力根本不过关。。。未见界管对其现有工作的滞碍
- 自己去讀讀不要人身攻擊、文明方針。維基護法，長期對其他用戶惡意推定及嘲諷。某用戶說自己是泡客棧專業用戶，一堆中文維基百科政客。在這個頁面下方充分體現這位維基學院管理員的傲慢自大。
- 支持，但請不要遺忘閣下的傀儡調查助理職責
- 在用户页声称“由[[LTA:WMLO|{{color|LightSkyBlue|擾亂者}}]]及同黨操弄的[[暴民政治|{{color|LightSkyBlue|暴民政治}}]]終須推翻，平反[[Wikipedia:管理員解任投票/Mys_721tx/第2次|{{color|LightSkyBlue|違規濫罷}}]]”，无视社群共识和RFDA流程的用户不适合拥任何管理权限
- 具備充足的技術能力，也足夠可信。
- 近期活跃度堪忧，作为现任傀儡调查助理，在SPI等工作上活跃度不甚令人满意。
- 回应意见态度恶劣，无法信任授权。
- 加油，感謝閣下的貢獻。
- 加油！
- 加油！
- 因为袒护Mys 721tx，所以不信任。
- 偉大無須多言
此次投票共收114票：
- (＋)支持 共62票；
- (－)反对 共46票；
- (＝)中立 共6票；
- (＋)支持：(－)反对 = 57% : 43%
由于支持率低于75%，根据规定，结果是落选。票数经Jimmy Xu、J.Wong和本人复核，所有投票附言已经打乱顺序并列于上方。—AT⊿⁴⁶ 2025年5月8日 (四) 14:34 (UTC)
- 一如预期XD感谢投支持票的六十余名用户，尤其是在投票附言中理性指出意见相左但仍信任我获取此等职务的用户。看到自己获得的支持票不比另外两位当选人差多少就已经心满意足了，感谢各位支持。--路西法人 2025年5月9日 (五) 03:16 (UTC)