维基百科

维基百科:互助客栈/其他

< Wikipedia:互助客栈
世界解放者在话题“有没有“勿添加违法网址”的警示模板？”中的最新留言：22分钟前

快捷方式

本页讨论与维基百科有关的话题，但不包括新闻、方针、技术、求助、条目或繁简处理。

  • 如果您需要就具体条目应当如何编辑才符合中立性原则寻求社区共识，请前往条目探讨留言。
  • 请在主题栏简明扼要地写出问题主旨，不要使用如“新问题”等无意义的文字。
  • 请勿公开姓名、地理位置、电话、电子邮箱地址等联系资料。我们通常只在此页回应，并不利用电子邮箱或电话等私下回应。
  • 无关维基百科项目的问题，请往知识问答相关页面询问。


请注重礼仪、遵守方针与指引，一般问题请至互助客栈其他区或知识问答提出，留言后请务必签名（点击 ）。


发表前请先搜索存档，参考旧讨论中的内容可节省您的时间。

7月10日之后没有新回应的议题会移动至相应的讨论页或存档。跳至本页的：目录 · 底端

公告栏
# 💭 话题 💬 👥 🙋 最新发言 🕒 (UTC+8)
1 没有主题的页面如何评级 1 1 Sanmosa 2024-07-17 22:50
2 评级系统缺失问题 223 22 A2569875 2024-07-20 08:24
3 Unblock-zh.org 68 15 Bluedeck 2024-07-11 02:46
4 RFDA（及未来成立仲裁委员会后的解任程序）相关探讨 136 21 Tokisaki Kurumi 2024-07-15 18:04
5 新用户通过撰写新条目的方式“完成学科作业”的处理讨论 43 18 人间百态 2024-07-19 21:51
6 讨论页话题自动索引 10 5 LuciferianThomas 2024-07-17 16:41
7 私自发布（怀疑自我原创）英国官员译名 11 6 Yuyu 2024-07-10 21:32
8 设立编者著作权调查 8 6 桐生ここ 2024-07-14 17:54
9 关于IPBE申请的问题 6 2 ASid 2024-07-10 14:46
10 影武者已被基金会全域禁制 6 5 Sanmosa 2024-07-17 22:19
11 请求社群判断已经数据过期的用户是否为傀儡 2 1 MCC214 2024-07-18 13:24
12 有没有“勿添加违法网址”的警示模板？ 1 1 世界解放者 2024-07-20 13:28
发言更新图例
  • 最近一小时内
  • 最近一日内
  • 一周内
  • 一个月内
  • 逾一个月
特殊状态
已移动至其他页面
或完成讨论之议题
手动设置
当列表出现异常时，
请先检查设置是否有误

正在广泛征求意见的议题

以下讨论需要社群广泛关注：（重新整理）

维基专题与协作

编辑

目前此主题无正在讨论的议题

条目主题
非条目主题
提示
要将某一个讨论加入上述列表中：
  • 在讨论页中的对应讨论章节顶端加上{{rfc|xxx}}标签，其中“xxx”为分类缩写。各类分类缩写已列于上方项目中，并应将其插入{{rfc}}中。多个分类请使用管道符号分开，如{{rfc|xxx|yyy}}，其中“xxx”为第一个分类，“yyy”为第二个分类。
更多信息请参阅维基百科:征求意见。请在维基百科讨论:征求意见回报有关错误。本列表由LuciferianBot于每个小时进行更新。

没有主题的页面如何评级

编辑
最新留言：在2天前发布1条留言1人参与讨论

本主题全部或部分段落文字，已移动至WT:通用评级。执行人：Sanmosa 蚌埠 2024年7月17日 (三) 14:50 (UTC)。回复

评级系统缺失问题

编辑
最新留言：在6小时前发布223条留言22人参与讨论
（原始标题为“将{{Classicon}}与{{Class/icon}}同步”配合公告栏调整标题。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月5日 (五) 07:47 (UTC)）回复

配合上方#Random_Thought: 跟进英维的WikiProject_banner_shell改版因此需要解决评级系统缺失问题，故提出以下议案-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2023年12月25日 (一) 09:49 (UTC)回复

第一阶段：修正评级值不同步问题

编辑

议案1：将{{Classicon}}与{{Class/icon}}同步

编辑

本主题或以下段落文字，在讨论结束后应存档至Template talk:Class/icon。

已通过：
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

我认为应将{{Classicon}}与{{Class/icon}}进行同步。{{Class/icon}}提供了比{{Classicon}}更多种级别的图示，如请求、未来、动态等评级的图示，{{Classicon}}都没有。而若{{Classicon}}与{{Class/icon}}合并的话，则等同于{{Classicon}}改成Module模式，需要社群共识，故发起讨论。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2023年12月25日 (一) 09:49 (UTC)回复

(＋)支持合并，后者（{{Class/icon}}）目前只有在154页上使用。-- Willy1018（留言） 2023年12月26日 (二) 01:33 (UTC)回复
(？)疑问：@Willy1018：那要不要{{Classicon}}重定向到{{Class/icon}}？刚才已补充{{Classicon}}所有功能到{{Class/icon}}了。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2023年12月26日 (二) 02:33 (UTC)回复
可以，但前者{{Classicon}}被全保护，只有管理员才能进行编辑，需要提{{ep}}。-- Willy1018（留言） 2023年12月26日 (二) 04:56 (UTC)回复
似乎未来之类的评级并未被整个评级系统完全支持？--百無一用是書生 (☎) 2023年12月28日 (四) 02:24 (UTC)回复
(：)回应：@Shizhao：有支持，显示评级的最后一个调用是{{WPBannerMeta/qualityscale/mask}}，而{{WPBannerMeta/qualityscale/mask|future}}→“未来”，但在要送入{{#assessment:}}的{{Class_mask}}需要设|future=yes才有，不然会被滤掉。而要送入{{#assessment:}}的{{Class_mask}}直接写死无法设置参数，故建议将要送入{{#assessment:}}的mask改用{{WPBannerMeta/qualityscale/mask}}，这样才能正确支援。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2023年12月28日 (四) 02:50 (UTC)回复
支持合并。不过纯模板实现也不错。--桐生ここ★[讨论] 2023年12月28日 (四) 21:48 (UTC)回复
@桐生ここ：完全不建议模板实现。现时模板实现是使用{{#switch:}}，您忘了2020年初{{#switch:}}爆炸事件Special:PermaLink/58036835#A_technical_issue_with_articles_of_French_communes导致中维崩溃的事件了吗。{{#switch:}}的开销要高于模块实现，所以建议使用模块实现，安全又有效率。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2023年12月29日 (五) 00:06 (UTC)回复
这边最近在处理基础条目与{{WikiProject banner shell}}的图示问题（Wikipedia:互助客栈/条目探讨#引入enwiki近期{{WPBS}}之改版，暨将{{Vital_article}}并入{{WPBS}}），(＆)建议直接采用{{Icon}}会更通用。--Kanashimi（留言） 2024年1月2日 (二) 09:18 (UTC)回复
但我觉得要有专题专用模板。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月2日 (二) 09:33 (UTC)回复
我想采用不同模板来处理同一件事的问题是较不易维护。--Kanashimi（留言） 2024年1月2日 (二) 09:49 (UTC)回复
@Kanashimi：问题是目前{{Icon}}并未完整涵盖Class/icon现有内容。改用{{Icon}}将会导致部分图是消失，或发生变化。我认为专题图示应该要统一的Style，但例如{{Icon|image}} 和{{Class/icon|image}} 就不一致，而且{{Icon|image}} 与以下图示比较{{Class/icon|image}} 、{{Class/icon|A}} 、{{Class/icon|B}} 、{{Class/icon|C}} 明显Style严重变调，故(－)反对。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月2日 (二) 10:13 (UTC)回复
或许我们可以扩展{{Icon}}使之涵盖我们想要的范畴，例如采用{{Icon|image_class}}？--Kanashimi（留言） 2024年1月2日 (二) 10:20 (UTC)回复
@Kanashimi：我这个议案只是想先动全保护模板{{Classicon}}，至少先同步图示，但您目前这样介入会导致共识乱了，连同不都做不到了，会导致花费更多“跑流程”时间，我想先同步，也做好patch了，都准备好了被你弄没了？我想先动全保护模板{{Classicon}}至少先同步图示；至于以后怎么维护可以再讨论。而且您的提议“例如采用{{Icon|image_class}}”也还没有patch，先现实一点吧，不要纸上谈兵，我只想赶快同步图示，并让Style一致，评级图示是评级图示，其他图示是其他图示；评级图示就该有评级图示自己的Style，(！)抗议乱七八糟的不一致Style图示。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月2日 (二) 10:29 (UTC)回复
也好。那就等这个讨论结束再说吧。--Kanashimi（留言） 2024年1月2日 (二) 10:30 (UTC)回复
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

议案2：修正评级系统被不当过滤掉的评级值

编辑
已通过：
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

 
“未来级”等级被正确识别（使用沙盒class mask避免被滤掉而实现的），见此[1]。

上方User:Shizhao提到“未来级”等评级级别无法被完整支持问题，是因为送入评级系统的评级值被不当过滤掉了，即使专题上层已启用该等评级，但最终还是会被“未继承上层参数的{{class mask}}”过滤掉，这样的话就算专题启用了该等评级也没有用，都被滤掉了，根本装饰，白启用了，因此提议将送入评级系统的评级值改为{{WPBannerMeta/qualityscale/mask}}模板，见编辑请求Template_talk:WPBannerMeta/core#编辑请求_2023-12-28，修改前后的比较Special:PermaLink/80307466，可以看到原有的版本评级值大部分都被滤掉了，建议换成提议的Patch，以让“未来级”等评级级别能真正被支持。同时，我也确认值接送未来级能正确被工具识别，见右图，连图示都有，代表评级系统是支援此输出的，能正确地被读取并识别。

因此提出本动议。不晓得各位有没有异议或意见。Ping参与过相关讨论的人@桐生ここ、Z7504、Shizhao、Willy1018：，上方参与过评级讨论的也Ping一下@暁月凛奈、Lopullinen、Milkypine、MilkyDefer：-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2023年12月31日 (日) 08:29 (UTC)回复

支持。( π )题外话：台湾之星的标识现在还没改。--桐生ここ★[讨论] 2023年12月31日 (日) 10:36 (UTC)回复
资慈，我觉得行。 --窝法乙烷 儿法梦碎 2024年1月1日 (一) 14:38 (UTC)回复
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

议案3：同步各模板/块的评级值

编辑
已通过：
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

目前有多个被全保护的评级模板/块的评级值（如有的有漏掉、有的图案、颜色不一致）并不同步，因此提议同步各评级模板/块的评级值。不晓得各位有没有异议或意见。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2023年12月31日 (日) 10:30 (UTC)回复

(～)补充相应的编辑请求Module_talk:Class/data#编辑请求_2023-12-28、Template_talk:Class_mask/core#编辑请求_2023-12-25和Template_talk:Class_mask#编辑请求_2024-01-05（和2023-12-25是配套的），颜色的部分：Template_talk:Class/colour#编辑请求_2024-01-05。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2023年12月31日 (日) 10:31 (UTC)回复
支持。--桐生ここ★[讨论] 2024年1月1日 (一) 09:03 (UTC)回复
就先改看看，让其他用户实际去测试这样才准，而不是每天一直喊支持。不然只是一直放沙盒而不去实际更改的话，完全不知道到底能不能测试。虽然维基百科终于有认知要将其功能“进步”，但也不应每日这样“无止尽的讨论而没有作为”才是。因此，这个讨论就不用再多说什么了。--Z7504非常建议必要时多关注评选（留言） 2024年1月1日 (一) 11:52 (UTC)回复
(：)回应：@Z7504：其实我有私下找User:AT了，但他一直说影响范围太大要先讨论  囧rz…………。我当然也希望能直接改啊，不然WP:7DAYS获共识再公示7天半个月就过去了……-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月1日 (一) 12:05 (UTC)回复
还想说中文维基百科不是长期以来都对专题这个东西爱理不理的，这不就是专题模板在用的相关评级吗？为什么不直接修改让其他人测试呢？建议AT直接帮忙修改吧。因为如果要叫维基百科废除已经存在多年的专题，显然是不可能的，更没有讨论是否要废除专题的必要。--Z7504非常建议必要时多关注评选（留言） 2024年1月1日 (一) 13:45 (UTC)回复
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

提案已通过请求布署

编辑
已布署：
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。
布署相关编辑，也就是编辑以下模板：
-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月16日 (二) 13:23 (UTC)回复
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

评级缺失问题目前办理状况

编辑

截至2024年1月5日 (五) 17:08 (UTC)已提出三案讨论，三案皆在等待初步共识，以便公示。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月5日 (五) 17:08 (UTC)回复

评级缺失案办理状况
进度 讨论中 初步共识 公示中 部署中 已完成 后续维运
*通用评级设立 已获共识 已通过 已完成 已完成 进行中
*评级继承机制 初步共识 公示通过 已完成 进行中
评级值同步 初步共识 公示通过 已完成 进行中
修正过度过滤评级值 初步共识 公示通过 已完成 进行中
评级图示同步 初步共识 公示通过 已完成 进行中
完善评级系统规范 讨论中 等待中
注：标有“*”表示是其他相关提案。
以上为截至2024年2月2日 (五) 09:45 (UTC)的办理状况。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月5日 (五) 17:08 (UTC)回复
2024年2月2日 (五) 09:45 (UTC)更新-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年2月2日 (五) 09:45 (UTC)回复
2024年4月6日 (六) 08:29 (UTC)更新-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年4月6日 (六) 08:29 (UTC)回复

第二阶段：依据先前共识将不是条目命名空间的评级分类从“XX级条目”改为“XX级页面”

编辑
已通过：
公示通过。分类改名涉页面较多，会再进行公告；而Wikipedia:条目质量评级标准移动到Wikipedia:页面质量评级标准将会立即执行。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年2月13日 (二) 03:18 (UTC)回复
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

根据先前共识，需要将不是条目命名空间的评级“XX级条目”的分类改为“XX级页面”，但因技术限制未能将“XX级条目”的分类改为“XX级页面”，因此本案已提出新的方案，依据页面命名空间添加分类，以实现该共识。具体执行方案在Template:WPBannerMeta/qualityscale/sandbox。同时将Wikipedia:条目质量评级标准移动到Wikipedia:页面质量评级标准，不知道各位有没有异议？-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月17日 (三) 04:57 (UTC)回复

没有异议，就是不知道会不会出现突发状况。 --窝法乙烷 儿法梦碎 2024年1月17日 (三) 11:35 (UTC)回复
已在多面体专题进行测试，详见Category:分类级多面体页面、Category:模板级多面体页面，目前测试整个多面体专题尚未出现问题。待本案正式通过之后才会正式(►)移动分类页面。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月17日 (三) 11:39 (UTC)回复
没有意见，但在专题页面（WikiProject）中使用到的{{Articles by Quality and Importance}}模板应一并解决显示异常之问题（前几天似乎还有这问题，现在不知道），虽然这模板平常根本没什么人在意  囧rz……（所以没解决可能也没差吧？因为专题本来就没什么人在意了）--Z7504非常建议必要时多关注评选（留言） 2024年1月18日 (四) 14:26 (UTC)回复
首先，结尾为“XX重要度”的分类不会移动，不在本计划内，而{{Articles by Quality and Importance}}是读取结尾为“XX级XX重要度”的分类，故基本上本案不会影响{{Articles by Quality and Importance}}。再来，如果这个真的要处理，要本案通过后，分类全部清理好，分类全数移动完成后才能处理，不然现在处理数字都会变成0。故应是下一个阶段要处理的（或者共识是暂不处理），不是此案此阶段讨论范围。此外，如果是{{Articles by Quality}}的话，直接更新分类名称即可。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月18日 (四) 16:02 (UTC)回复
已逾一周无新发言，根据WP:7DAYS七日无进一步发言视为已获初步共识，如本声明无人有异议，将准备进行公示。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月26日 (五) 00:32 (UTC)回复
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

分类改名准备

编辑
已完成：
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

虽Special:Diff/80961277已公示通过，但因涉及的页面众多，因此宜再进行全站公告。公告完后将进行两个阶段完成：

  • 阶段1：全保护页面编辑请求：Template:WPBannerMeta/qualityscale和Template:Class
    由于该等分类都是以上被全保护的模板自动添加的，因此需要执行以上编辑请求。等编辑请求完成后，数万个页面缓存自动清理完毕后，分类将自动从“XX级条目”改归为“XX级页面”。
  • 阶段2：正式(►)移动分类页面（可能是约阶段1完成后再过一周）
    等缓存全部清完，再将“XX级条目”分类，逐个(►)移动到“XX级页面”分类。
-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年2月13日 (二) 03:30 (UTC)回复

  公告一周。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年2月13日 (二) 03:31 (UTC)回复

本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

第三阶段：Wikipedia_talk:页面质量评级标准#WP:QUALITY_升为指引

编辑

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:页面评级。

本案最初的初衷就是完成此共识Wikipedia_talk:页面质量评级标准#WP:QUALITY_升为指引，来完成WP:QUALITY_升为指引一事，来正式解决“评级系统缺失问题”（指引/规范未立也算是本系统的一种“缺失”）。等上方都完成，此处将继续。声明：当这些“缺失”都解决后，本人将不再碰评级系统这块了，这烫手山竽真是消磨人的精神。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年3月8日 (五) 04:40 (UTC)回复

可能我上面没说清楚，让你以为我是反对分类改名的，更不是什么越给我搞复杂，好啊WP:QUALITY永远升不了指引都你害的，不能有问题不让说是不是。总之是以下几点：
  1. 页面重新命名为Wikipedia:条目质量评级标准：因为评级针对的是WP:条目，其它模板级、分类级这些评级都是非标准级别（WP:QUALITY就是这么写的），那么页面应当以标准评级针对的对象命名，也就是条目质量评级标准。除非你打算搞什么甲级模板级，那不是更复杂。此外还存在Wikipedia:条目重要度评级标准，那是否要改成Wikipedia:页面重要度评级标准，总之得有一个要改
  2. 目前Wikipedia:条目重要度评级标准和Wikipedia:页面质量评级标准是正交的，所以有Category:分类级低重要度宗教条目这种东西的存在，那是不是得命名成Category:分类级低重要度宗教页面。既然分类级不属于标准评级，因此也不必设置重要度，引入更多复杂性，这类页面统统扔去Category:不适用重要度条目去（或者说Category:不适用重要度页面）。
  3. {{Grading scheme}}修改，因为Wikipedia:页面质量评级标准调用了，这个就是作为WP:指引用词统一的问题
--Kunjinkao（留言） 2024年3月8日 (五) 05:20 (UTC)回复
  1. 无论是前次讨论还是本次讨论，都没有提到重要度，因此认为重要度的那个论述怎么样，并不碍于WP:QUALITY升为指引一事。
  2. 此修改技术成本过大，且认为这样修改与否并不碍于WP:QUALITY升为指引一事。由于目前架构问题，该修改技术上的复杂性，不建议做此修改。除非有人能提出具体的patch ，否则我不支持也不相信此修改能够被实际执行。（当然，如果有人做patch 就另当别论）-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年3月8日 (五) 06:05 (UTC)回复
  3. 如果没有人有异议，你可以自行修改。
-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年3月8日 (五) 06:05 (UTC)回复
关于第一点，重要度只是顺带提及，核心是评级针对的是WP:条目，其它模板级、分类级这些评级都是非标准级别，那么页面应当以标准评级针对的对象命名，也就是条目质量评级标准。--Kunjinkao（留言） 2024年3月8日 (五) 06:26 (UTC)回复
Wikipedia_talk:页面质量评级标准#c-Cdip150-2016-03-14T04:31:00.000Z-Liaon98-2016-03-14T02:44:00.000Z。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年3月8日 (五) 06:47 (UTC)回复

第二阶段正式完成后的第三阶段讨论

编辑
已完成当时的共识Wikipedia_talk:页面质量评级标准#总结“将不是条目命名空间的评级分类从XX级条目改为XX级页面”，因此将安排Wikipedia_talk:页面质量评级标准#WP:QUALITY_升为指引重新公示。重Ping当时参与讨论的人：@Liaon98、JyunWaan、Lssrn：@Cdip150、Temp3600、Peacearth：。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年3月19日 (二) 10:49 (UTC)回复
  • 当时的讨论是专题各自评级，而现在的情况是多了通用评级（WPBS）。所以时过境迁，WP:QUALITY要重新讨论了。我之前没有参与讨论，现在有不少想法：
  1. WPBS评级是专题评级的容器，还是一套有自己标准的独立评级？现行做法属于前者：WPBS评级继承专题的评级，且受各专题各方面的干涉，因此评级原则看似“随意”。

    一篇列表WPBS获评List级而非CL级，是因为它确实没到CL级。另一篇列表获评List级而非CL级，只是因为某个参评专题不设CL级。第三篇列表和第二篇品质相似却成功获评CL级，原因竟是不设CL级的专题没有“染指”该列表。

    所以我的看法是，通用评级就该如WPBS模板所言，确实地“依照页面品质评定标准”来独立评定，而不是在各专题评级间谋求公约数。可以参考专题评级，但把专题评级当爸爸就不对了😂
  2. 承上，如果我们确定WP:ASSESS本位而非专题评级本位，那就要讨论条目的WPBS该设立哪些级别？英维的PIQA是只支持FA、A、GA、B、C、Start、Stub、FL、List、Unassessed几个经典的“标准级别”。而我们的WPBS是大杂烩：既包括BL、CL这种品质向评级，也包括Future这种非品质向评级。所以WPBS评级所支持的“标准等级”该设哪些？
    • BL、CL等品质向等级有两条出路。一是如同英维，只收录广为人知的传统评级，不收录BL、CL这种额外等级；个别专题想启用就在自己的横幅上评。二是将BL、CL升格为通用评级，全体专题横幅亦自动启用BL和CL；如果个别专题自己讨论后坚持不用BL，那可以用掩码把BL改成List或B。
    • 对于Future级，一篇未来级条目可以很烂（Stub），也可以比较充实（C），那Future这个等级就没有实现“评价页面质量”的作用。我能想到的用途是在话题中，用未来级作为宽限条目的标记，暂时不影响认定。但这个等级的确不够“通用”，或者说和条目所用的品质评级不是一个维度。
    • 对于A级条目。英维的A级在军事史专题存活（且活得很好），但其他专题都是死的。因此英维多次讨论A级的出路，比如从PIQA里开除把A级之类。但你维是真的所有专题都不评A级；所以，把这个只有理论价值的等级从通用评级中灭了挺好。
    • 上面的想法也会影响小工具的设置：包括对标准评级的契合，对各专题自定等级的支援，对非条目评级的简化（非条目空间一般人手评级无效）。
  3. 下文有提到“消歧义级条目/页面”。如果按照命名空间来理解，那就有一个问题：重定向在各个空间都有，那到底是叫“重定向级条目”还是“重定向级页面”？（或者两个都要，但这徒增烦恼）另一方面从实用性上看，专题统计“条目数”都是排除Disambig级的，那消歧义占据条目空间就成了bug而非feature 。这次从“条目”移到“页面”更像是正名，但是后缀分家无论是技术实现上还是命名统一性上，带来的麻烦都不少。考虑将后缀统一为“页”，比如品质评级这边的“乙级条目页”“丙级列表页”“模板页”，重要度那边也可以叫“高重要度页”“未知重要度页”，这样观后缀就知道是页面评级体系在整活。
我明白很多内容都不在讨论范围内，但我认为之前讨论本身就是系统性不足。比如把非条目品质评级改为“XX级页面”，那为何条目品质评级和非条目重要度分类不动？是改条目和重要度分类真的弊大于利，还是单纯没有讨论过而已？作为这套系统创始者，英文版的非条目还用articles的，个中原因是否值得参考？ --For Each element In group Next（留言） 2024年3月19日 (二) 16:05 (UTC)回复
争议已消失：
上述争议因进一步讨论已展开，因此可以视为争议已消失-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年6月1日 (六) 10:55 (UTC)回复
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。
@For Each element In group Next：老实说我真的不懂你们这些这时候再来提意见是用什么心态再看事情的，这个提案已经放超过三个月了，又不是放一个星期就说要公示，硬是等提案要准备收尾才来提意见是怎么回事？！我可以当成你是打算扰乱干扰提案通过吗？！--SunAfterRain 2024年3月19日 (二) 16:40 (UTC)回复
我几年前的主业之一就是评级理论。Wikipedia_talk:页面质量评级标准#WP:QUALITY_升为指引6年前甚至6个月前，我都会像推动MOS:FICT那样，亲自提出修改意见和方案（如WP:QUALITY第二段不符合新形式），让WP:QUALITY成为更优质的指引。但现在评级方面，我认为和这个装睡的社群去合作没有什么意义。所以我的做法就是不发言，看着这个社群未来到底走向哪里。出于对当初理想的怀念，我写下了这些明者自明的意见，但也仅此而已了。通过提案无非就是页面多个“指引”的标签；您看我用户页，就该知道我对这种“社群众评标签”有没有兴趣了。--For Each element In group Next（留言） 2024年3月20日 (三) 16:36 (UTC)回复
@For Each element In group Next：我不管你到底对这个议题有没有兴趣，反正你现在的意思是上方内容纯粹是发牢骚你没有要干扰这个提案？！--SunAfterRain 2024年3月20日 (三) 17:12 (UTC)回复
还没有细看，但我对洛普利宁君遭到这样的对待感到很悲哀。--Temp3600（留言） 2024年3月20日 (三) 17:43 (UTC)回复
在有用的讨论串下面离题吵架实在无奈，但似乎VP环境已经如此。
WP:CON明确指出"共识应采纳多数人的意见，并和重要少数的意见作出适当妥协。"、"共识在维基百科是持续不断的过程"，对于方针修改，更再次明示"共识最终将根据支持和反对该议题的论点质量所决定"。方针中没有任何字眼要求讨论应"收尾"，反而暗示了讨论本身是可以无限延长，以不断修改共识更贴合实况的。所谓扰乱更是莫名其妙。
回到讨论本身，如果有足以反驳洛普利宁君的理据，直接提出来就可以。如果反驳不了，甚至根本没有考虑到这一讨论角度，那显然就说明"之前讨论本身就是系统性不足"，提案一方存有思考盲点，应该进一步讨论下去。
回到这个提案。我与八年前一样，支持将WP:ASSESS创建为指引。然而，洛普利宁的问题必须先得到回答:维基百科:通用评级与维基百科:页面质量评级标准之间有潜在矛盾。通用评级到底是独立的评级系统，还是专题评级的平均分?我对这两者没有特别的见解，但WP:ASSESS应该清楚指明这一上下级关系。
如果不幸某页面只有一个专题，而这个专题将页面评为"未来级"等奇怪级别，通用评级是否跟随?
请赐教。--Temp3600（留言） 2024年3月21日 (四) 19:45 (UTC)回复
@Temp3600：那我倒觉得您来主持好了，包含修改模板模块的部分，反正您看起来很闲可以泡在客栈陪大家一直耗。--SunAfterRain 2024年3月22日 (五) 01:35 (UTC)回复
  • 折腾了三个月，我已经没有修改评级模块的心力了。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年3月22日 (五) 01:52 (UTC)回复
  • Special:PermaLink/81985508#第三阶段：完善制度这里有说，一切以维基百科:页面质量评级标准为主，当专题评完后，维基百科:通用评级再取各专题WP:ASSESS的公约数，不认为有矛盾。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年3月22日 (五) 02:00 (UTC)回复
    • @A2569875：如果方针是FA级，指引是GA级，那现行WP:QUALITY+维基百科:通用评级大概只有C的水平，还需要很多工作完善：
      • WP:QUALITY说“评级主要由专题进行……”。那WPBS评级人是作为什么身份评的？社群成员，还是专题成员？现在WPBS开展一段时间了，相信大部分人的评级逻辑是直接对WPBS评级（而不是专门针对各个专题）。这就和“评级主要由专题进行……”矛盾。
      • 有了WPBS后，就有了“社群心目中的评级”，这个评级就是WPBS的评级。这样，大部分专题出于信任社群/懒得评级，而继承了通用评级。对于旧页面，现在的做法很好——假定WPBS评级为各专题评级的公约数。不过这个做法并非必然，我们也可以取各专题的最高值/最低值，只要社群愿意信赖专题。例如英维只有WP:MILHIST真正地在评A，而其他专题是评GA或者B，此时一个做法是取A，而非众数或向下取GA/B。
      • 但是下面的问题理论上和执行上都很成问题。例如维基百科:通用评级第5点要求“例如未启用乙级的专题，通用级别遇到规则3判为乙级的情况时，则向下填写为丙级……”。
        • 首先，很难判定专题是否启用某个级别。机器人运行者好像都说过做不到这个事情，就更不用说人工评级了。
        • 其次，如果B级是标准评级，且多数专题都评B级，那这个条目在社群心目中就是B级。我们不应该迁就特例独行的专题，否则公认的B级条目评C，那B和C还有什么可比性？应该是说，不设B级的专题应该自己收拾自己的摊子，例如专题评级继承B而表示为unassessed，或者用掩码改成C。
        • 第三，现在的BL是标准评级吗？如果不是标准评级，那应该呈现在社群通用的WPBS上吗？如果呈现在WPBS上，多数编者没见过BL，他们看得懂吗？如果你认为大家能看懂，且乐见对列表细致评级，那不如将BL升格为标准评级？如果升格为标准评级，就应该预设对所有专题的class mask启用BL，否则又回到上一点专题“特立独行”的老路。
      • 只有一个专题评Future，那WPBS技术上当然可以评Future（且只能评Future）。但上面BL甚至D级都是品质导向级别，那Future和他们并列（而不是attention之类的flag）是什么用意？还有，如果两个专题一个是CL，另一个是Future，而且两者都未设对方的级别，那WPBS到底听谁的？
      • 上述问题可以不断打补丁解决（维基百科:通用评级就是打补丁的成果），但这并非良方。大道至简，最实际的方法是：编者以社群成员的身份，以WP:QUALITY的标准评级中的选项为依据，针对WPBS评级。专题评级理论上和WPBS独立，但实践上的评级方式是信任社群评级。然后，我们讨论WPBS具体该支援哪些级别——对于条目，我建议支援传统级别，或传统级别+BL/CL/(SL?)；而Future、Merge不属于品质评估，而A级又极不活跃常常被人误解，这两类可以考虑从通用级别中除去。至于要修改的地方，无非就是修订WP:QUALITY、WPBS支援代码、class/mask预设启用代码，就像您说的，要改很简单。
      • 您可能看不懂我的留言，也可能看懂了但没有观点。建议您和有实际开设特殊级别的专题联络，看看他们的意见。我可以写出蓝本，但我不想干涉这件事情，也不想在这个物是人非的地方留言。
    • @SunAfterRain：我可以当成你是打算扰乱干扰提案通过吗？！。当然可以！您怎么想是您的权利。--For Each element In group Next（留言） 2024年3月22日 (五) 16:26 (UTC)回复
      你以为你维的评级模块是Module:Namespace/data这种随手改一改就好的是吧，改一次的成本有多高您可以自己改看看，不是什么看起来很简单改一改就好--SunAfterRain 2024年3月23日 (六) 03:13 (UTC)回复
      我2015年到2016年大幅更改过WPBM相关子模块，比如引入bchecklist。而且如果WPBM不能满足我的需要，我也有能力手写模板。我固然不是A2569875那样的技术专家，但我也知道那些内容属于微调，哪些内容属于重炼。（那时候您似乎还没注册，如果您问一下八九年前一些关注评级的老用户，您大概会知道我都干过什么）
      上面的问题我早在两个月前就A2569875君交流过。当时他表示现在只讨论技术问题，具体制度问题可以后议。我的意见不是技术问题——等真正的技术修改部署后，对WPBS屏蔽某些等级就OK——所以的确可以后议。A2569875当时态度很激烈，我不想影响他的心情，而且他应该是没有看懂我的意见，所以我就没有继续争论下去。另一方面如果我做主导人，和议案有关的问题无论在发哪里讨论，我都会接受；而A2569875的思路就是a讨论页不谈b问题（我不知道这是不是今日你维的讨论规矩）。我们俩电波对不上，我也不想在客栈留言，所以就直接走了。现在的论题正是“第三阶段（WP:QUALITY_升为指引）讨论”，既然是讨论（而不是走形式直接通过）那我充分陈述我对WP:QUALITY的看法很合理吧？而且讨论3月19日开始，我也没有拖到26日要结案的时候发。
      就我看来，应该一开始就讨论WP:QUALITY评级这个哲学问题，讨论好方向之后再开始技术修改。而且有了修改体系背书，A2569875的技术修改也能一路绿灯，不用喊“折腾了三个月，我已经没有修改评级模块的心力了”。不过中维人少，评级哲学上确实没几个人能想到这么深；就像技术方面没A2569875，其他人也推不了这个提案。最后我认为本站应该以理服人，而不是靠方针指引或没讨论深度的“共识”堵嘴：能指出问题的内容标上指引也是根基不牢，有道理的论述没有标签也应该令人尊敬。--For Each element In group Next（留言） 2024年3月23日 (六) 05:29 (UTC)回复
      别为你不参与讨论找借口，电波对不上不代表就可以事后再来批判，你说以理服人光是你用这个理由我就觉得你服不了人了
      另外你觉得你的意见不是技术问题但事实就是改动不小的技术问题，光是要改动一个分类就要牵涉到多少模板模块了--SunAfterRain 2024年3月23日 (六) 05:49 (UTC)回复
      您的考虑方向我很赞同。不过如果例子举成“改动一个模板就会牵涉多少分类的移动”，那会更有说服力  --For Each element In group Next（留言） 2024年3月23日 (六) 06:58 (UTC)回复
      你到底在举什么...--SunAfterRain 2024年3月23日 (六) 07:28 (UTC)回复
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。
  • 首先感谢宇凡君的努力，您辛苦了。顺便说一点离题得罪人的话：
  • 目前的问题如要解决，通用评级指引势必重写。问题只是要怎样重写而已。说白了，洛普利宁是反对通用评级的“由下而上”逻辑，再深挖下去，涉及专题组与社群整体之间的互动问题，对应现实生活中的中央－地方政府间，集权－分权的冲突。这样展开就显然太复杂了，我只是希望指出为什么洛普利宁会认为这个指引写得不好。
    回到维基。尽管从宪法的观点出发，确立各子组织间的权力分立应是创建规则的第一步，但考虑到中文维基并不怎么关注这一问题，我就建议维持现状好了，省得麻烦。反正即使是下而上，要修改专题评级，直接一起修改所有专题的评级就可以（显然这就一次侵犯了数个专题的自主权，但上面说了，中维人这方面的理解力有限）。下而上的（理论上）优势当然是“各专题组可以按各自所擅长的领域，共同对跨领域的条目进行评级，会比WPBS只用一个评级员来得准确”。实际上嘛，就是懒得改。
    “WPBS评级人是作为什么身份评的”：从下而上的观点而言，没有专题组的条目评级，算是社群托管了该条目，留待专题组前来接收，等价于联合国托管理事会。最终还是需要专题组的专家前来正式评级。
    "标准评级":基于减少修改范围（懒）的因素，建议只容许使用“标准级别”来评级。也就是说，暂时放弃将BL／CL加入WPBS，待更多专题启用这些评级，更为人所熟悉后，再来讨论。future等评级则不容许更新到WPBS上去，机器人应视这些条目为“没有评级”，由人类前来处理。
    最后，感谢@For Each element In group Next：前来，指出这些要点供大家讨论。说实话我本来也不想发言的，打了这些东西花了我一个多小时。也希望你能与我一起坚持到这项修改完结。
    以上。--Temp3600（留言） 2024年3月23日 (六) 03:33 (UTC)回复
    如果硬要扯开这个话题，我反倒支持废掉所有专辑的质量评级全部统一处理，因为你维专题参与人数实在少到除了几个大专题之外没有办法给出一个真的符合自己专题的评级标准，而且去查大专题的评级标准实际上也与通用标准没有差异，那这样给各专题评质量有什么意义？--SunAfterRain 2024年3月23日 (六) 05:54 (UTC)回复
    （以上没有要废掉重要度评级）--SunAfterRain 2024年3月23日 (六) 05:56 (UTC)回复
    如果完全废除专题评级，将权力上移给WPBS，那就算不谈这种集权行为是否影响了专题组的自治，也需要将目前已经由专题组评级的条目改为WPBS格式，并处理评级不一致的问题。我是不太看好能搞定啦。--Temp3600（留言） 2024年3月23日 (六) 07:10 (UTC)回复
    @Temp3600：感谢您的解释！虽然讨论很不愉快，但至少讨论者都能理解我要引出的思考点了。现在我的任务大功告成了 --For Each element In group Next（留言） 2024年3月23日 (六) 06:58 (UTC)回复
    喂喂，不准跑掉（ --Temp3600（留言） 2024年3月23日 (六) 07:14 (UTC)回复
    所以你知道为什么我说他明显有意扰乱了吧（摊手--SunAfterRain 2024年3月23日 (六) 07:26 (UTC)回复

随意的分段

编辑
  • 另外回应SAR的是，技术人员与行政官僚本身就是两项不同的工作，互相批评在我看来并无意义。nerd的下场，可以参考为什么苹果公司会赶走乔布斯。--Temp3600（留言） 2024年3月23日 (六) 03:37 (UTC)回复
    • (：)回应：@Temp3600：最初的提案是Wikipedia:互助客栈/其他#没有主题的页面如何评级。起因是我遇到有条目不属于任何专题，所以如果要评级，会有困难。（所以，我的动机很简单，我本来就只是在写条目，遇到了一个问题，我来客栈讨论解方，结果折腾了三个月，途中不乏某些维基人精神攻击，提案看起来快搁浅，精力消磨没了，写条目的动力也没了。在本案开始之前，我一个月写十几个条目，本案开始之后，三个月我只写了两个条目。）。关于该问题由MilkyDefer给出的解决方案是修改{{WPBS}}，于是开始讨论共识并执行，以及其配套的《评级系统缺失案》甚至还因技术需要跑了几趟phab(如phab:T360012)。因为最原始的目的《没有主题的页面如何评级》，代表其讨论页会放置空{{WPBS}}，也就是没有任何专题的{{WPBS}}，所以当然要能支援填写所有评级级别，包括但不限于非标准级别（为此，我还特地翻过所有专题、所有维基百科上出现过的评级级别，统整出所有专题定义的所有级别，大概40几个）。而当{{WPBS}}如果开始填入复数个专题，{{WPBS}}如果又要限制能填写的级别，程式逻辑势必变得复杂，所以我的解决方案是不改程式（你知道的，改全保护的程式不是那么简单），改立WP:通用评级指引制约，如可能也把评级系统的不同步级缺失补齐，其实目的也就只是《没有主题的页面如何评级》而已。而只是恰好Kanashimi要跑评级机器人，所以我索性再修改一下程式，跑客栈共识+公示流程，虽中间与Z7504发生争议（其实消耗了我非常多精神）但最后都通过了，而“去match Kanashimi机器人”这部分其实已经超出我原本想编写的程式内容了。后续所有技术案都通过了（过程中洛普利宁在客栈中不发一语）所以程式码当然不会包含他所期望的部分啊。维基百科是志工性质，不强迫任何人参与，既然我已经写好我想写的程式，那我为何还要在最后“可能”可以收尾的时候，帮“洛普利宁的理想”写程式？程式技术不难，但全保护和繁杂的评级系统，加上客栈不时出现精神攻击，说实在我的精力已经耗尽。我提供的任何一段程式码都没有拿到任何薪水，纯粹就是最初我想做、我想解决某些问题，但像现在这样节外生枝是否生得太夸张了？-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年3月23日 (六) 04:13 (UTC)回复
    我想，在洛普利宁的心中，他在最初就已经您解决了你的问题：维基百科有一个万能专题{{WikiProject Article assessment}}，你只要将没有专题的条目通通添加到这个专题下就可以，问题立刻解决，不需要碰WPBS。我也认为这是最简单的方法。只需要跑一次机器人，把所有没有专题的条目全部加入WikiProject Article assessment，就可以了。
    顺便一说，我自己也试过帮助条目找专题，但即便有新rater的协助，仍然很难。最大的问题是，我不知道有那些专题存在，又不知道他们的简写。如果宇凡你能改良rater，让程式可以搜索，甚至推介专题给我来选择，会很有帮助。比如有一个英国足球队条目，但还没有专题，但分类已经写了这是英国条目，rater能不能够提示我加入英国专题（或者别的什么专题？）。
    如果不行，可以考虑一个简单一点的修改方案：当条目没有专题时，rater默认添加WikiProject Article assessment，就可以照常评级了。
    但现在WPBS已经生出来了，总不能走回头路。但这个也不容易，一会儿再写。--Temp3600（留言） 2024年3月23日 (六) 04:47 (UTC)回复
    @Temp3600：这完全不是什么两种不同工作的问题，有意见之前重写模块时一起纳入考量重写就好，那时候提出我想娜娜奇也会尽可能配合的，但洛普利宁同学是喔我支持改写，人家写完都开始运行了再来抱怨。不要跟我说什么滚动式修正，他提出的意见很显然不是因为模块上线才出现的。--SunAfterRain 2024年3月23日 (六) 05:38 (UTC)回复
    然后回到“Template_talk:WPBannerMeta#编辑请求_2024-01-08”。洛普利宁的批评是对的：宇帆在这次重构中，只考虑了技术层面上如何实行WPBS的改版，忽略了行政上的架构问题：所谓通用评级，由于每个条目只能有一个，客观上就有压倒原来专题评级的意味。于是这就进一步产生了通用评级与专题评级的冲突，新创建的WPBS机关在权责上如何与原来的专题委员会划分的问题。现在那些WPBS有没有CL级，未来级的问题，本质上都是没有完成项目定义就急于进入开发阶段，结果现在开发成果不完全符合要求，但是要再更改，工作量又很大，于是卡住了。
    所以现在还是要回到那个编辑请求，解决掉1月时的问题。然后由于技术负债，问题要尽量靠行政程序解决。这就是目前的工作。
    宇凡那时的观点，也不能说错，毕竟维基百科也没有技术可以阻止你发侵权垃圾内容对不对，但是我们有行政手段，有制度可以将侵权内容通过删除页面功能处理掉。我估计这边最后也会采用相同的方向，WPBS模版支持很多参数，但在指引中，会指明只有部分参数才可以合法使用，如果用了其他值，即使能够正常显示评级，其他人也可以回退，警告这一套。--Temp3600（留言） 2024年3月23日 (六) 08:43 (UTC)回复
    • @Temp3600：问题就出在于，最早MilkyDefer的起草就有未来级、CL级等等，然后我还Ping了洛普利宁问他这样可不可以，但他完全没有任何答复，到头来还是只有一句“精神上支持”，我怎么知道问题在哪，直到一月开发完成才开始说这里不对、那里不对，这样我是要怎么搞。反而User:Willy1018事先指出了具体问题，我得以依照他的问题在开发阶段先行解决，并让User:Willy1018说出了“感谢贡献，目前已复核已符合预期。”。完成后才再修改成本比较高，一开始又不讲清楚，说完“精神上支持”然后跑掉，然后现在争议后要叫我扛责任。我这样消磨掉的精神状况可能需要去放维基假期了-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年3月23日 (六) 09:00 (UTC)回复
      A2569875：首先向您道歉，我没有及时回复您的提醒，在1月份的讨论中，我也没有坚持将意见表达清楚，因为我认为您将来会用掩蔽代码的方式处理WPBS评级。我也知道了为何SunAfterRain君会将我提报到破坏区。其次感谢您完成了迄今所有的技术工作。我的意见是针对政策层面，亦即评级体系如何开展。我不参与客栈讨论，亦不会干涉指引讨论的工作；因为很多等级都是我带起来的，我这次只提出我的想法，希望让社群自行讨论如何评级等级。如果讨论结果是敲定启用或不启用某些等级而需要修改模块，而您疲于修改模块，我可以参与技术工作吗？最后就像Temp3600君所言，在下确实有责任。--For Each element In group Next（留言） 2024年3月23日 (六) 09:40 (UTC)回复
    (＋)支持User:Temp3600提的：不当使用WPBS参数时，其他人也可以回退，警告这一套。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年3月23日 (六) 09:11 (UTC)回复
  • 如果能够masking掉WPBS旳等级，待日后成熟等再开启，那自然是最好；不行的话，单改指引也算是解决了问题。--Temp3600（留言） 2024年3月24日 (日) 03:25 (UTC)回复
  • 另外拖@MilkyDefer：出来，future grade 条目要直接沿用还是怎样处理(pia!) --Temp3600（留言） 2024年3月24日 (日) 03:33 (UTC)回复
    什么叫沿用？事实上我连现在future grade的使用情况都不是很清楚，可否说明一下背景信息？--MilkyDefer 2024年3月24日 (日) 03:55 (UTC)回复
    @MilkyDefer：例如en:Talk:Texas_State_Highway_32按你的构想，是什么评级。背景资料....按我很初步的认识，英文WPBS的条目评级系统只容许BCStub等标准评级，但专题组可以按各自需要将条目评为future级等特殊等级。这与目前WP:QUALITY中建议的评级方案并不一致。--Temp3600（留言） 2024年3月24日 (日) 04:05 (UTC)回复
    有什么……不一致吗？Future Class列在非标准等级下，并且写有“部分专题还会启用附加等级。”看上去挺一致的欸。--MilkyDefer 2024年3月24日 (日) 04:36 (UTC)回复
    咦我写错了...en:Talk:Texas_State_Highway_32如果按维基百科:通用评级，它下面只有一个future-class的专题评级，那么就不能评为stub.在我看来这是问题。--Temp3600（留言） 2024年3月24日 (日) 05:01 (UTC)回复
    en:Template:WikiProject U.S. Roads列在en:Category:WikiProjects using a non-standard quality scale，因此此篇文章的评级没问题。我觉得WPBS的评级主要是条目整体评价，在zhwiki实施起来基本上也是这个目的。只不过 zhwiki评级似乎比较复杂，所以允许各专题自定义标准，每个专题模板都算non-standard quality scale。这部分实施起来，其精神与enwiki也相同。--Kanashimi（留言） 2024年3月24日 (日) 05:12 (UTC)回复
    按英文版的评级方式是没有问题，但来到中维，维基百科:通用评级并不是英维的对等翻译。于是就有了"若一条目仅有一个专题，其通用评级应与该专题所评的等级一致。"这样的条款，影响到WPBS专注在内容评级的工作。顺带一说，这一点也和LP为什么建议全面转用英维制度，将内容评级由专题组上提到社群的精神一致。不过这样就涉及更复杂的改动，恐怕还是免了。--Temp3600（留言） 2024年3月24日 (日) 05:30 (UTC)回复
    我个人觉得这一条仅限于单一专题模板采用标准评级的情况下才有效。但假如所有专题模板都属于 non-standard quality scale，则不如废掉。--Kanashimi（留言） 2024年3月24日 (日) 05:49 (UTC)回复
    • @Temp3600：我觉得像Future、Current（某主题是否是新闻事件或未来事件完全取决于专题领域，例如某主题在A领域可能是一件大新闻，所以评Future，但另一个领域关它屁事所以评甲乙丙丁初之一）Merge、Need（这种通常都是向特定专题请求重定向扩充为条目的标记，无关专题就标通用评级的  重定向级吧）这些“聚焦于特定专题”的级别就让相关的专题沿用吧，然后从通用评级的标准评级撤下变成非标准评级，我想问题应该就解决了。修订的部分，我想等到下面确立哪些要设为标准评级之后，再将通用评级指引加上“只能用标准评级”之类的规范应该就能从行政手段解决了。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年3月26日 (二) 17:36 (UTC)回复
  • 另另外我约略看了一下英维，看来它们已经将各专题评级整合起来，会个条目只有一个评级。这是你提出由上而下的背曔原因吗?@For Each element In group Next：--Temp3600（留言） 2024年3月24日 (日) 03:38 (UTC)回复
    我也认为WPBS是社群基于标准（WP:QUALITY）对条目做出的评价。当然，社群也允许专题依照自己的标准对条目做出评价，并标记在讨论页上。某种意义上，社群评级和专题评级是“人格独立”的，这里的“上”和“下”更像依赖的上下游，而不是官大一级的上下层。然后既然专题评级是独立的，那专题就可以选择各种策略：
    • 社群人多力量大，自行评级太繁杂，WPBS填啥我填啥。（看起来就像评级被废了，但其实是选择和WPBS的做法一样）如果对专题成员评级不服，要么以社群成员身份找社群吵，要么推动专题退群。这就是英维绝大部分专题的策略。
    • 预设继承社群评级，但也可以自行覆盖社群评级。这就是我们现在的状态。
    • 不继承WPBS的评级，只要自己的class不填就是未评级。英维的退群专题（比如有BL的WP:MILHIST、没A的WP:VG）都是这个策略。不排除有些专题是想自己搞；但也有专题是只开除掉A级，其他等级想继承社群，但因为英维技术不支持策略2而被迫退的。
    像SunAfterRain说的，绝大多数专题用策略1就够，而且理论上标准相同的专题应该评同样的等级。个别专题有特殊的评级标准，那就采用策略2。真有专题完全不想社群插手，那就上策略3。策略1那就是纯粹的自上而下了。此外，对上游的WPBS规定好标准等级后，将非标准等级映射到标准等级（假设规定BL->List、D->Start、Current->Unassessed），也可以让机器人参考策略2和3的专题填WPBS。
    自下而上主要还是一堆奇葩等级，逻辑上没法搞。刻度尺测量物体长度，得到的结果应该是稳定的；一次测3 cm、一次测5 cm，就说明测量错了。但如果两次测量都操作无误，那你用的大概不是尺子  WPBS本来评CL，因为来了个不支持CL的专题就改评List，两次评级都没有错，这就说明该制度不适合衡量条目品质。如果将奇葩等级改成WPBS标准评级，或者拒绝参考非标准等级，那这个制度就可行；但这基本就又成了上面的问题。--For Each element In group Next（留言） 2024年3月24日 (日) 16:21 (UTC)回复
  • 先多谢各位，意见都很有见地。希望在上方再拆一个小标题。A级与GA的问题是老大难了，我想这次还是先不处理为好。A级虽然很少用，但一直都算是标准评级，现在一下子移除不太好。List级对等于初级列表长远是好主意，但要标记清楚，因为许多旧列表是list级。所以现在list级代表初级或以上的列表。或许长远要创建start list?—Temp3600（留言） 2024年3月25日 (一) 23:35 (UTC)回复

D级与B+级等标准讨论

编辑

接上文宇帆君列出的等级。新级别是要写文档的，所以下列意见供参考：

  • D级目前看来只有宇帆君活跃的多面体在用，其条目是介于C和Start之间。讲真，流行文化领域，因为关注粉丝向这种扣分内容，D级还是很好用的。
    • 比如明星条目，内容上已经有C级该有的内容，但因为很多内容都以粉丝介绍口吻出现，需要大量清理和改写；这时评Start太可惜，就可以评D级。这基本就像多面体专题说的，“内容上可能达到C级水准，但其他方面有严重缺陷”。或者说，写条目的人擅长事实性内容，但不了解这里的格式手册，写出的东西很随意不像百科。
    • 另一方面，虚构作品条目也强调要写反响等现实世界内容。一般来说，编者不写现实世界内容，就表示他不熟悉格式手册，所以条目格式、行文等方面也不会太好。这种条目又要清理又要扩充，就可以给Start。但也有从英维FA翻译一半的，条目序言完整、作品介绍也很规范，但该到制作历史和评价，他又他不翻译了。这种只用扩充不用清理的，也可以从Start抬升为D。
    • 可以看到，流行文化领域这个D级主要还是可以彰显“内容杂乱/格式差”。但科学等领域大概没有“粉丝内容”，所以这个D级通常会怎么用？
    • 另外有了D，是不是未来有可能对等增加DL？
  • B+只有英维数学专题有用过，而且现在删了；本地没有专题实装过，只在一些理论研究中提到，所以还是要想想标准怎么订。
    • 之前B+的评级标准是“条目高于B级标准”，再把B级标准抄了一遍，这就比较不良定义。GA和B的区别主要在GA还要求中立性稳定性，且文笔和格式的要求高于B。如果要搞B+，那标准大概就是“不要求中立性和稳定性，但其他方面同GA标准”？PS：B6提到的WP:JARGON和地区词在GA标准里没有体现，所以B在某些方面还高于GA；不过现在的英维已经把JARGON要求增补到GA标准里了。
    • 之前有提过增设优良列表（GL）。GL和FL的主要区别可以理解为GL不管红（绿）链，且序言不用太优美；这个境界就有点像B+和GA了。不过，FL和GL应该是要有本质差异的——类似WP:GVF的comperhensive和board coverage。例如对于游戏系列，FA应该像死忠那样列出小众改编作品，而GA可以只列出重要作品。（但是很多领域列表是不是没有这种问题？）
  • 小小作品更像是一个临时状态，和未评级一样是不该长期存在的。而且小小作品只是长度短，问题还没有广告、侵权等小作品更严重，所以整体统计上把小小作品拆出来的意义是？从维护追踪角度考虑，WP:PETSCAN或者Shizhao的专题机器人通告应该都很好用了。--For Each element In group Next（留言） 2024年3月26日 (二) 15:50 (UTC)回复
    • 感谢提供意见。关于增设新评级级别，如您提出的D-List和Temp君提出Start-List以及上述提到的GL，我想作为长远目标来讨论，现阶段先不处理。一来是phab:T360012本站评级资料表更新工单根据API测试似乎已合并到主程式，而GL则是因为评选设立草案无共识所以工单中就没有申请加入该等级，所以就算现在评了GL可能也无法被某些系统正确识别，同时，一直频繁更改感觉对基金会人员也不太好意思；二来是又要改十余个全保护模板了  囧rz……。（注：如果说有了D就要对等增加DL，那为何有了GA没有对等增加GL😅 甚至图片有“特色图片”若对应FA的话，那为何没有GA对应“优良图片”、A对应“甲级图片”、B对应“乙级图片”[开玩笑的]）另外您提供的D级条目用法也十分不错，我(＋)附议这样子的用法，科学上可能可以用在使用了太多行话术语导致多数人看不太懂的这种情况吧；而Bplus 我这边是暂无其他想法，如果有其他维基人有什么想法欢迎补充；小小作品级是当时评级系统开发阶段进行测试时增加的级别，当时我找了几篇正文少于50字的条目但没被挂小小作品模板的“老条目”评上了此级，来试验系统能否接受输入，不过后来这些条目一些被提交AFD了、一些被扩充成小作品级了，但考虑到条目如果持续扩充也会持续升级啊，例如小作品升初级，这只是换成小小作品升小作品级而已，只是通常条目停留在  小小作品级的时间可能会非常短而已。另外，我前几个小时仔细重看了一下每个级别，发现比较有问题的应该是deferred级（中维评级系统本次更新完显示为  搁置级）经查，该级别于2015年被加入中维评级系统资料表中，但在WP:TG简单讨论并对照英文维基还有此级别的专题说明显示，该级别代表的意义是“本专题不提供评级，转介由涵盖本专题的专题提供评级”所以可能也不叫做“  搁置级”，TG上有群友建议“转介级”，不过这种级别对上通用评级的话，基本上存在感就没了，阿卡林～，不过UUM表示这种转介具有一定程度“重要性”，可能要讨论一下，看是要改名还是干脆就废除掉，或者以“未评级”论之类的。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年3月26日 (二) 16:52 (UTC)回复
    • 感谢宇凡的研究，这个转介级我都没听说过。评级级别方面，宇凡君所指的技术困难确实存在，就像我们这几天讨论了一下，又想到找到这么多评级。如果每次都去phab改，不免扰民。我初步的想法是，quality 指引的标准评级部分创建为指引，规定wpbs 目前社群认可的评级；专题评级维持论述级，方便专题修改，待有共识后再处理。至于wpbs模版，则不需修改原码，只需在模版说明页等写清楚那一些评级因尚未有广泛共识，暂不开放使用，就可以了。
    • 标准级方面，我比较关注CL与乙上，大家懂不懂得评。虽说当成推广也无不可。—Temp3600（留言） 2024年3月26日 (二) 23:53 (UTC)回复
  • （有感而发）除了本子节开始的争议外，以上讨论与研究其实都满有意义和价值的，如果能提前在去年十二月，也就是我当初Ping了洛普利宁时，他就发表了这些意见，并开展了我们现在所讨论的东西，那我觉得WPBS应该会更完美。不过现在说这些都是后话了。另，跟大家说声抱歉，我当时一心只想着如何把MilkyDefer起草的临时方案开发成正式方案、如何pass所有testcases 和解决讨论页上各种问题回报（1、2等），一切考量都以技术为优先（我当时优先级最高的考量是：程式怎么写更省效能，于是出现了mw.loadData("Module:PJBSClass/page")用于让该功能在整个页面解析的过程只会跑一次，而不会每次调用通用评级时都跑以节省效能），却忽略了行政上的执行问题，而导致了今次的争议，我感到十分抱歉。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年3月27日 (三) 01:30 (UTC)回复

B+我之前写过论述。鉴于中维的GAN机制（时间短、需求票数多，且评审者普遍社会惰性），B+当GAN预审还是很有生态位的。但是在务实上，等GAN评审素质普遍超过这个乙级评级，B+才会有得玩  耸肩

我想B+（Bplus）的标准可以用WP:WIABCA的大纲来套用WP:WIAGA：

这样B级评审时也顺手按GA（B+）提意见。--For Each element In group Next（留言） 2024年3月28日 (四) 14:20 (UTC)回复

WPBS级别列表

编辑

目前{{WPBS}}能接受输入的级别大部分都是phab:T360012向P站登记的级别以级在案《第一阶段：修正评级值不同步问题》时所有评级Data模板统一同步更新的评级值列举如下（共50个。此外由于表格过长，已折叠。请单击[显示]以展开表格）：

能够由{{WPBS}}程式自动评级的级别（详情）
 典范  特色列表  特色图片  优良  小作品  列表  同类索引
 消歧义  重定向  沙盒  模板  模块  分类  文件
 草稿  主题  专题  用户  使用说明  界面  非条目

以下建议供行政组参考：

  • 标准品质级别（可填写在WPBS）：
      典范级[FA]、  特色列表级[FL]、  特色图片级[FM]、  甲级[A]、  甲级列表级[AL]、  优良级[GA]、  乙上级[B+]、  乙级[B]、  乙级列表级[BL]、  丙级[C]、  丙级列表级[CL]、  丁级[D]、  初级[Start]、  列表级[List]（暂时作为  初级列表使用）、  小作品级[Stub]、  小列表级[SL]、  小小作品级[Substub]、  无级[No]
  • 标准类别级别（可填写在WPBS）：
      消歧义级[Disambig]、  同类索引级[SIA]、  重定向级[Redirect]、  沙盒级[Sandbox]、  模板级[Template]、  模块级[Module]、  分类级[Category]、  文件级[File]、  草稿级[Draft]、  主题级[Portal]、  专题级[Project]、  用户级[User]、  使用说明级[Help]、  界面级[interface]、  非条目级[NA]（如TimedText:空间）
  • 非标准类别级别（不应该填写在WPBS）：
      图书级[Book]（曾有共识引入，但因技术原因部署无限期推迟）、  音频级[Audio]（只有少数专题将File级做细分，WPBS应都填入File级）、图像级[Image]（(▲)同上）、  非页面级[NAPage]（只用于特殊专题）
  • 非标准品质级别（不应该填写在WPBS）：
      优良列表级[GL]（讨论尚无结果）、  特色主题[FPO]（未通过设立）、  完成级[Complete]、  充实级[Substantial]、  简单级[Basic]（完成、充实、简单仅用于PJ:主题）
  • 非标准级别（不应该填写在WPBS）：
      未来级[Future]、  动态级[Current]、  合并级[Merge]、  请求级[Needed]、  搁置级[Deferred]、
  • 技术性级别（不应该填写在WPBS）：
      委员会级[council]（仅做图示用途，不应手动输入此级）、  错误级[Error]（出错时会自动加入，不应手动输入此级）、  未评级[Unassessed]（无提供时自动产生，不应手动输入此级）、  未知级[Unknown]（无法正确识别的情况，应修正之，而不应手动输入此级）
-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年4月6日 (六) 03:43 (UTC)回复
感谢总结。我有一些疑问：
  • Substub作为标准品质，似乎比较增加维护负担？会创建小小作品的基本都是新手，他们不懂得在讨论页挂{{WPBS}}填|class=substub。维护人员也都在条目页标记{{substub}}，然后打捞人员再从Category:小小作品追踪，这就基本就没人会管讨论页。而且就算有专题模板，如果利用讨论页的分类来维护，就要从讨论页跳转到主页面，也是比较低效的。（MilkyDeferBot可以根据讨论页横幅和条目页{{substub}}自动生成页面列表，这样也没必要用讨论页评级）此外如果substub是被人手填了，那就还要经常盯着条目，看评级是否过时。所以依靠评级模板来维护substub，感觉有种打捞一分钟，评级三十秒，性价比相当低。所以，WPBS层面统合到stub是否好些？
  • 正规条目都应该有品质评级，尚未评估品质的条目是Unassessed，条目空间的Disambig等特殊页面也考虑进去了。看英维也没no这个级别，所以无级别的条目会是怎样的？
--For Each element In group Next（留言） 2024年4月6日 (六) 05:20 (UTC)回复

等级标准小结

编辑
洛普利宁在上文提到的“PJBS之PJBSClass.getClassByPage()”自动评级（小勘误：自动评级实由PJBSClass/main.getClassAuto()和PJBSClass.getAutoClass()共同完成，前者以页面状态和挂有模板判断、后者只看Namespace），这些评级会根据页面挂的模板、子页面名称、页面状况和所在命名空间等进行自动评级。这些评级分为两类：不可被|class=参数复写的评级以级可被|class=参数复写的评级。
这些级别有：
  • 不可被|class=参数复写的评级：  重定向级、  特色图片级（注：|class=有值时会强制被改为File级）、  模板级、  模块级、  分类级、  文件级、  草稿级、  主题级、  专题级、  用户级、  使用说明级、  界面级、  非条目级
  • 可被|class=参数复写的评级：  典范级、  特色列表级、  优良级、  小作品级、  沙盒级、  列表级、  同类索引级、  消歧义级
上文提到，目前不在WP:QUALITY中的级别都需要补上文档，因此我起了以下草稿供参考：
（注：如果有需要修改可以直接编辑本表格，无须经过我的同意(不被视为修改他人留言)）
（注2：下表只列出目前未出现于WP:QUALITY的级别）
（注3：由于表格过长，已折叠。请单击[显示]以展开表格）
预计种类分成三类：标准级别（描述条目品质）、标准类别（描述页面种类）、非标准级别（专题自定的东西）
@Temp3600：您看看这些信息对行政组作业有没有帮助？（请单击[显示]以展开表格）-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年4月5日 (五) 10:48 (UTC)回复
感谢宇帆君的总结。我大胆做了一些调整，说明如下：
  • Bplus之于GA类似A之于FA。A级的标准和文档页指出要走比较正规评审，类似这种，而不能像评B、C那样随手改|class=。所以Bplus的要求中我也提了要做评审；不过这也就是这么一说，大家肯定还是会随手改的😂。另外A级开始才算专业，GA只能叫接近专业（我上面说的，英维A级需要专家来评审，而GA不需要），所以调整了一下措辞。
  • D级还是可能有格式问题的，基本上B级才算比较遵循格式手册，连C级可能都差一点，而且爱好者内容广义上也算格式问题。其他方面调整了一下语言，大体是说条目内容方面有含量，但其他方面比较差。
--For Each element In group Next（留言） 2024年4月5日 (五) 13:54 (UTC)回复

页面评级与通用评级指引调整

编辑
    • 非常感谢娜娜奇。但我因为现实原因(pia!)暂时不能积极参与讨论。我预计会于19-21日的周末发言，这段时间麻烦诸位了。--Temp3600（留言） 2024年4月12日 (五) 11:29 (UTC)回复
      • 约略看过没有问题。在格式上有一点想法: 每个类别还是找一个例子，当参考。另外，会否用Template:Guideline section，只将标准评级立为指引会较好?如果专题组日后创立新评级供内部使用，便无须经VP共识修改评级表，而可自行加入。不过倒过来，如果自行加入评级会弄坏模版，那么还是经VP讨论，协调好再修改较好。这方面我不清楚，请给意见。--Temp3600（留言） 2024年4月12日 (五) 11:58 (UTC)回复
        • @Temp3600：届时，如果确定该等级都标准化的话，仅需要将{{Class_mask/core}}中，目前还没标准化的级别做“开放”即可（不必改程式，只要改类似config(设置)的东东），而专题自建级别已有相应功能，无须动到核心模板，示例见{{WikiProject_Example}}，因此完全无需更动本次系列模板/模块或任何程式码的核心，故自行加入评级不至于会弄坏模版。常见的专题非标准评级我觉得可以在WP:QUALITY提，在章节标题标注“本段不是指引”应该就可以了，就不必走VP共识了。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年4月12日 (五) 15:49 (UTC)回复
          • 先抱歉晚了许多上来...生活艰难QQ。
          • 如果如此，那么标准级别一节立为指引就可以，并在非标准级别一节清楚列明专题可以如何自行加入新评级(好像在模版说明里已经写好?那么就只需要提供链接)。--Temp3600（留言） 2024年5月5日 (日) 07:27 (UTC)回复

对于Wikipedia:页面质量评级标准（以及Wikipedia:通用评级）还有一些逻辑上的考量：

  • 英文版的页面en:Wikipedia:Content assessment翻译过来是内容评级。其内涵理论上包括评级流程、评级标准等多个部分。而中文版的标题是“页面质量评级标准”，一只介绍标准本身，二又强调品质评级。而当前页面是从古早期英维版翻译过来，现在两边都改了很多，这就很微妙了。所以页面是否要改名“Wikipedia:页面评级”？
  • 如果从标题强调质量评级来看，页面似乎应该将“标准质量评级”（≈条目）和“标准类别级别”（≈非条目）分设为两个大节。说约等于是因为特色图片属于非条目但又要评估品质，而同类索引（SIA）是自动评级但理论上属于条目。
    • 对于条目品质评级部分，是否需要流程图辅助说明？（比如写入指引页，或放在论述页给个连接）
  • 如何表述“通用评级”与“专题评级”的关系？从目前的讨论来看，可能还需要一个页面（可能是Wikipedia:页面评级）厘清：
    • 社群和专题都可以各自独立地对页面评级。评级结果登记于条目讨论页顶部。
    • 通用评级由社群编者评估，对社群负责。本页刊载的等级标准为通用标准，即适用于WPBS的通用评级。
    • 专题评级由专题自行解释，但因为专题评级一般直接继承通用评级，所以也还是这套标准。部分专题可能自选启用或关闭级别，也可能重新诠释通用级别，这些内容具体在专题评级页刊载。

我希望听听其他编者的意见，所以暂时不会积极回复。--For Each element In group Next（留言） 2024年4月14日 (日) 15:17 (UTC)回复

  • en:Wikipedia:Content assessment 有较多的内容，我认为这是因为他们是这个制度的来源地，所以有关于制度的历史流变等可以写。中维目前只是引入的制度，还没有社群的经验，因此没有这部分的本地经验可以立为指引，而只能写一些硬规定。我认为这暂时不是问题，如日后成熟，自然可以再将这些段落引进，指引名字也可以更改。“页面质量评级标准”就暂时只写标准，待评级流程成熟后，就可以加入这一部分的指引。
同意将“标准质量评级”与“标准类别级别”分立为两个三级标题。这是一项不涉及本质的结构修改，不难。
流程图最好有，但要有人来画...

“通用评级”与“专题评级”的关系:这是我最早就想改写的部分。既然“通用评级”只可填标准评级而专题评级可以填其他自定义评级，那么维基百科:通用评级就需要至少修改"若一条目仅有一个专题，其通用评级应与该专题所评的等级一致。"，最好是重新理顺这一部分的逻辑。

整理目前的讨论，建议"机器人会根据该页面最多专题评等的评级等级作为通用评级"继续保留，但机器人应检查这会否导致WPBS被评为非正式级别，如发生这种情况，那么机器人则跳过该条目(可以考虑加入"需要手动进行WPBS评级"的分类)，留待人类前来。
同意"社群和专题都可以各自独立地对页面评级"的基本策略。这样就解决了list级的问题。即使专题的评级只有list级，WPBS仍可以手动评为更准确的CL/BL等细分级别。由机器人自动评的list级也与这个逻辑没有冲突。
长远的最终方向是，WPBS作为条目的内容评级，专题评级则为某一方面提供额外的信息，类似tag.但这个需要将目前的评级逻辑反过来，我猜一两年也无法完成，就写在这而已。--Temp3600（留言） 2024年5月5日 (日) 08:10 (UTC)回复

修订案

编辑
维基百科:通用评级
编辑
  • 解决“通用评级”与“专题评级”的关系。断开两者的上下级关系。
  • 通用评级只限填写标准评级。
  • 介绍一些其他功能，例如专题可以自行加入评级，不过这些不属于WPBS的范围，将它们指示到其他页面去。
维基百科:页面质量评级标准
编辑
  • 对应通用评级的改动，明确两者间的关系。即: QUALITY负责规定那些级别属于标准评级，及提供评级的参考。也提供其他非标准级别的介绍。通用评级指引则负责通用评级的流程，由社群负责，为条目的质量提供评级，而专题级模版级等请不要来找WPBS.
  • 结构调整，将“标准质量评级”与“标准类别级别”分立为两个三级标题。
T: Grading scheme
编辑
  • 为所有标准类别补上例子。

似乎除了这笔移动外没太大进展，那我就先写个Draft:页面评级吧。T:Grading scheme的例子就没办法了，甲级估计社群这辈子也评不出来（现在的Talk:家牛也没找到评审在哪）😂 --For Each element In group ... Next 2024年7月10日 (三) 17:45 (UTC)回复

后续讨论

编辑

关于 rater.js 脚本

编辑

前面的讨论貌似没有涉及到老版本的rater.js脚本（User:Chiefwei/rater aka en:User:Kephir/gadgets/rater）。貌似enwiki那边已经废弃了老版本的rater.js，并且由Evad37推出了新版的rater.js（en:User:Evad37/rater）。我再考虑将新版本引入并做本地化，不知道目前是否已经有类似的工作了？--Ceba_robot 才不是机器人！ 2024年2月16日 (五) 17:57 (UTC)回复

有见到Ericliu1912和YFdyh000两版。--Cookai饼块🍪（💬留言） 2024年2月16日 (五) 18:17 (UTC)回复
妥了，看起来YFdyh000的目前跟上游已经同步，还是不要做重复工作比较好（--Ceba_robot 才不是机器人！ 2024年2月16日 (五) 18:24 (UTC)回复
我也跟进借鉴了，至少现在用哪一个版本都不会落后。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年3月4日 (一) 11:51 (UTC)回复

Unblock-zh.org

编辑
最新留言：在9天前发布68条留言15人参与讨论
 
Unblock-zh.org网站的样子

很久以前讨论过的一个项目，也就是unblock-zh的网站版，我最近给他做出来了，如果对测试版软件感兴趣的话，请去 https://unblock-zh.org 这里去看看。（注意测试版软件，你的用户最后很可能被删掉！）7月7日update：软件进入试运行阶段，此时产生的工单等数据将永久保留。Bluedeck 2024年7月8日 (一) 19:21 (UTC)回复

附带一个教学视频 https://www.youtube.com/watch?v=IImfyNnRB4M

目前站外用户申请账户的方式是Wikipedia:账号请求发送邮件，其实也没有太不方便。但是这个途径我觉得还是更直观一点，比邮件列表好用一点，尤其是管理员处理的时候。我的想法是网站可以和邮件列表并存，或者以后达成互联。欢迎提出意见。Bluedeck 2024年4月29日 (一) 04:05 (UTC)回复

PS. 已经收到tigerzeng的意见，允许用户自定义提供的IP地址字段，以解决部分代理的问题。Bluedeck 2024年4月29日 (一) 04:22 (UTC)回复
超 英 赶 美 —— Eric Liu 創造は生命（留言・留名・学生会） 2024年4月29日 (一) 08:09 (UTC)回复
我最期待的画面出现了。--AT 2024年4月29日 (一) 09:14 (UTC)回复
好吧，终于把这个弄出来了——是蓝桌弄的？那就不出奇了。  赞——Sakamotosan路过围观 | 避免做作，免敬 2024年4月29日 (一) 09:29 (UTC)回复
非常好UX。至于是否方便了用户，我好奇能否在合理的范围内收集一些统计数据作对比，这样最有说服力。--碟之舞📀💿 2024年4月29日 (一) 14:10 (UTC)回复
另外这个工具让我想到了我很久之前做的维基媒体服务器连通性面板。--碟之舞📀💿 2024年4月29日 (一) 14:37 (UTC)回复
非常好软件。
不必要的功能建议：1.通过遍历封禁日志的摘要有无对应模板，显示是否是ip封禁。2.通过接口调用在界面一键创建账户（和授予ipbe？）
另外问一下数据托管在哪里？将来投入使用的话需要作为存档使用，所以数据需要备份好。--落花有意12138 2024年4月29日 (一) 14:42 (UTC)回复
一键创建账户/授予PIBE的话，有两种途径。第一，管理员通过oAuth授权unblock-zh.org，通过管理员账户操作，然后从本地日志看来，操作者是管理员。第二种途径是，成立一个机器人账户，比如名叫 unblock-helper-abot，并且赋予机器人管理权限，然后通过机器人操作，并在摘要里说明是根据哪个管理员的指令操作的。让我来决定的话，我倾向于使用第二种方式，因为我希望尽量不要向第三方授权我自己的账户，但是第一种方式的日志更加清晰。请问一下其他人的想法。Bluedeck 2024年4月29日 (一) 17:39 (UTC)回复
使用OAuth可以只需要简单的身份识别获得权限，用于确认是不是登录系统的对应是wiki的哪个用户。然后代理操纵的机器人可以标记操作人员的wiki用户名（通过前面获得的信息）。——Sakamotosan路过围观 | 避免做作，免敬 2024年4月30日 (二) 02:33 (UTC)回复
如果不改变单管理员授权模式，我倾向于第一种，这样和原先的工作模式保持一致，便于查询。
mw:OAuth/For_Developers称应用做的操作会有标签。--落花有意12138 2024年4月30日 (二) 11:04 (UTC)回复
在这里没有看到可以使用oauth给用户添加组别的选项，那么也是说IPBE的授予只能透过abot进行了。Bluedeck 2024年5月1日 (三) 21:41 (UTC)回复
的确只能这样。——Sakamotosan路过围观 | 避免做作，免敬 2024年5月2日 (四) 03:40 (UTC)回复
咱好像记着这种权限似乎不需要特别勾上某个选项就默认拥有，您要不尝试一下？ Stang★ 2024年5月8日 (三) 01:14 (UTC)回复
真的假的，在授权的时候不声明却可以操作改变用户组这么重要的操作？如果是真的那也是个bug吧 Bluedeck 2024年5月11日 (六) 08:40 (UTC)回复
用API能查IP有没本地封或者全域封，好像不是必要。——Sakamotosan路过围观 | 避免做作，免敬 2024年4月30日 (二) 02:26 (UTC)回复
  赞  赞  赞 牛逼--Dnaimfz（留言） 2024年5月11日 (六) 04:04 (UTC)回复
@Bluedeck：话说可给管理员布告板抄送一份通知链接至此？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月1日 (六) 08:43 (UTC)回复
@Bluedeck：想好奇请问是否有考虑过部属在wikitech:Help:Cloud VPS？如果有，为什么不选择部属在该处？--SunAfterRain 2024年6月4日 (二) 09:30 (UTC)回复
管理员通告版：不知道效果会怎么样啊。等上线后在ASN通告一下，然后TG呀IRC呀广播一下应该就行。CloudVPS：他的介绍说自己是标准的VPS，但是又有迹象表明他不是完全标准的环境，导致我不想把时间花在部署，测试，更换环境，以及踩坑上面。对我来说，写软件是趣味十足的事情，而调试环境则是让我胃肠不适的事情。目前我没有换环境的需求，因为开销太小。如果有我再考虑cloudvps。cloudvps的另一个问题是只有在virginia有DC，但这不是一个大问题。Bluedeck 2024年6月8日 (六) 04:00 (UTC)回复
以我个人看法，部属在CloudVPS的隐私疑虑绝对会比一个外部网站好很多，当然你维社群愿意接受那我也没什么意见就是了。虽然不清楚是笔误还是什么的，如果开销太小的话我自己是会考虑换过去啦。--SunAfterRain 2024年6月10日 (一) 17:54 (UTC)回复
可以理解你所说的。我可以把cloudVPS当作一个长期目标，最终迁移到那上面去。Bluedeck 2024年6月14日 (五) 05:29 (UTC)回复

试运行

编辑

在过去的几周里，我增加了最后的一些的功能，分别是1）按日期搜索排列工单；2）邮件回复模板；3）管理员删除工单、删除消息界面；4）用户改名功能。我想知道大家觉得还缺少哪些网站本身的功能（邮件服务器、机器人授予IPBE除外）。如果感觉差不多了，那么可以进行试运行。试运行期间，再对可能发现的新的功能需求进行补充。试运行的提议正在进行公告。如果通过，将会将网站首页文字改为试运行，并暂时移除一些只具有展示效果的链接，然后在用户无法注册的提示页面加入网站的链接，这些操作大概最多需要一天就能完成。在试运行决议通过前，如果对网站有任何问题，欢迎在此讨论。Bluedeck 2024年5月13日 (一) 23:30 (UTC)回复

功能方面，个人认为管理员不应该有删除工单的能力，这个应该由维护者来做，比如遇到spam/扰乱性工单就打上相应的标签，若干天后自动删除；可不可以出个statistics大概写一下某月某人处理了多少工单之类的；反spam方面怎么样，你觉得需要加个recaptcha吗；模板建议是放到Github或者类似公开的地方，需要改的人发pr；可以考虑加一个link/merge功能么，比如一个用户就一个问题发了多个ticket，这个时候可以把它们关联起来；感觉可以把login改的小一点，或者让非管理人员意识到不需要登录就可以发ticket。
另外就是建议放到toolforge或者cloud VPS上。顺便问个问题，你觉得这个系统需要承担unblock-zh最原始的封禁申诉职能吗 Stang★ 2024年5月14日 (二) 01:47 (UTC)回复
  • 谢谢提议！简短回应：
  • 删除工单就是为了应对扰乱才设计的功能。删除之后可以恢复或检视。（UI需要另外添加）工单的永久保留或删除问题在下面讨论。
  • 反spam：UTRS目前是阻止同一个IP地址多次发送工单。但是我的方案不记录IP地址，无法阻止。我可以考虑一下记录ip地址的hash，并由此进行rate limit。我个人完全不喜欢captcha，除非不得已，我可能会考虑上captcha。在此之前我会尽量用其他手段处理spam问题。我有一些asymmetric proof of work的方法能防止自动化的spam。如果有人无聊到要手工spam，那么唯有记录IP并进行区段查封这一个办法。（但是这样一来，不就把本身的目的给击败了？？）
  • 邮件模板：我不会放在github，毕竟不是每个管理员都会开PR，我简单的开一个用户页面存储目前的模板，谁想添加，给我留个言即可。邮件模板都是非常简单的纯文字模板。当然，如果你喜欢用gh，那么在前端的repo里有一个文件，你也可以直接PR这个文件。
  • link/merge：race condition太多，最多做成stack overflow/github issues那样，“标记为#109的duplicate。关闭”这种解决方案。
  • login改小：我肯定会让新用户看到不login就能发工单，这是一个重要的因素。
  • statistics：这个我一定会做，因为这会让处理工单变得很有趣，我的设想是做一个leaderboard，能够激发人们对于处理工单的无限潜能，哈哈哈哈。
  • Hosting：toolforge不能满足我的要求，CloudVPS不熟悉。将来打算支持图片上传，需要一个能挂载S3的环境，另外多区域host允许你把服务器托管在东京/首尔/LA。目前，服务器托管在Vultr的新泽西区上面。
  • 这个网站做成网站的形式，是为了新用户方便的注册+IPBE（也就是unblock-zh-ipbe的功能）。处理被长期封禁的用户在邮件列表中50-100封邮件那么长的申诉，并不是网站初衷。如果有人就是要在网站上申诉，管理员也选择在网站上处理，那我不会站出来阻止，但是如果网站上出现了对维基百科历史有一定意义的讨论内容，我觉得有应当抄送一份到邮件列表。
Bluedeck 2024年5月14日 (二) 04:12 (UTC)回复
update: 已经增加了查看和恢复已删除工单的功能。Bluedeck 2024年5月19日 (日) 06:40 (UTC)回复

另外还有两个别的需要讨论的问题：

  1. 工单是否永久保存？永久保存是目前的默认，而且邮件列表也是永久保存的。但是我觉得比如挂上“处理结束”标记90/180天之后永久删除相关信息这个是更安全的做法，想征求一下大家的意见。
  2. 开源：从一开始我就设想开源。这个项目有4个repo，其中3个可以在最近开源。一个需要我检查一下有没有API Key之类的物品遗落在代码中，然后才能开源。请期待。
  3. 共同参与：如果您想共同参与开发，或者参与对服务器的运维，欢迎在这里提出来。Bluedeck 2024年5月14日 (二) 04:49 (UTC)回复
感谢贡献，整体非常完善。如有需要可以协助维护。--Borschts™ 欢迎外带一碗罗宋汤 2024年5月14日 (二) 13:32 (UTC)回复
存档应保留，只是可以限制普通用户存取。另外，也应考虑先行在站内撰写说明页面，或补充现有方针与指引不足，以便利用。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年5月14日 (二) 15:05 (UTC)回复
注意到两点可以改善：
  • 无法创建账号者不应提供“我不想提供邮箱”的选项，创建账号时需填写对方电邮地址才能安全发送临时密码。如果不想提供邮箱则难以协助创建账号。
  • 需要添加提示文字，若不提供IP地址则申请有可能不获受理（始终审批IPBE时需要验证用户是否使用proxy）。
--路西法人 2024年5月15日 (三) 07:52 (UTC)回复
我脑海中预想的不提供邮件的处理方式：网站生成一个强的随机密码并记录在工单中，用户通过随机密码登录。优点：用户不需要邮箱地址。缺点：不提供邮箱的用户等于需要不断的刷新页面查看处理进度，是一个糟糕的体验。对于管理员，需要复制粘贴网站生成的密码来创建账户，也是多了一个步骤。上面我只是说明了操作的可行性，至于这个功能是否保留，可以继续讨论决定。对于第二点，IPBEG如果有这个要求，那我完全可以添加这个提示文字（甚至可以在维基百科设置一个页面，比如Template:Unblock-zh/strings/new-ticket-notice，然后网站可以反映这个页面的任意文字。）Bluedeck 2024年5月19日 (日) 06:22 (UTC)回复
我的想法是只要有任何第三方人员可以接触到任何密码的方案都是不安全的，尤其在发送邮件时在此类第三方网站留存临时密码亦是相当危险的；即使我信任你会尽力保障网络安全，但显然不安全的操作应尽可能完全避免。邮件、代理IP地址等都尚算不太危险的信息，密码真的不行。--路西法人 2024年5月21日 (二) 01:25 (UTC)回复
我想了一下觉得你说得很有道理。如果有的用户收到临时密码后不加更改，那么等于这个用户的密码永远的挂在一个所有管理员都能看到的地方，是不妥的。我已经把界面改成如果请求账户，必须提供邮箱，否则无法提交。Bluedeck 2024年5月21日 (二) 01:50 (UTC)回复
一些minor的建议：about一页，Puzzle Globe似可译为“拼图球”，Wikibooks译名应为“维基教科书”非“维基图书”。不提供邮件的提示，“一串30几位的工单”应作“三十几位”。login界面没有明显的返回按钮，侧栏也消失了。lookup界面可以考虑加注工单号和邮箱择一提供即可。 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年5月21日 (二) 03:01 (UTC)回复
另外我在想让其选择点选提交IP的选项是否也应该把UA也提供给审核用户检阅（方便反破坏比对）。--路西法人 2024年5月23日 (四) 07:54 (UTC)回复
统一回复。1）login界面有意如此设计。2）必须同时输入工单号和邮件，否则任意人士可以通过广泛查询邮件探知私密工单。3）UA信息只有CU才能访问，所以显然不能提供。另外就算用户主动提供了，那么IPBE处理者拿什么进行比对呢？毕竟你又看不到LTA的UA。Bluedeck 2024年5月27日 (一) 06:11 (UTC)回复
2) 啊那就是提前提示创建工单时未提供电子邮箱的须放空？ ——魔琴［身份声明 留言 贡献 新手2023］ 2024年5月27日 (一) 06:29 (UTC)回复
没有提供电邮的工单号会比较长，所以我可以改一下软件，让这种工单号不论是否输入电邮都能够正常查询。这样可以不破坏界面简洁易用。Bluedeck 2024年5月29日 (三) 06:45 (UTC)回复
好的  赞 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年5月29日 (三) 07:32 (UTC)回复

将开始试运行。公示已经进行了一个多月，收集到了很多改进意见，并实施了很多更新。今天起，我将正式修改MediaWiki软件界面，在网站上标注试运行字样，并在公告栏和ASN中对社区和管理员们进行公告。Bluedeck 2024年7月7日 (日) 16:26 (UTC)回复

@Bluedeck：请问IPBEG们可以如何存取工单？--路西法人 2024年7月10日 (三) 03:25 (UTC)回复
@LuciferianThomas：我正在编写为IPBE权限持有者提供权限的功能。完成后，IPBE将获得和管理员基本一致的功能。目前编写的功能是对于下方讨论中方案一的实现。编写完成后，我将会在用户讨论页面通知IPBEG权限持有者。Bluedeck 2024年7月10日 (三) 18:46 (UTC)回复

繁体支援

编辑

这个网站估计主要的受众是大陆梯子人士。但是，由于很多管理员是繁体用户，那么我就增加了一系列的繁体支援，但是都是Google翻译的。请繁体管理员看看管理界面的翻译如果有很不和谐的地方，请指出来。如有需要，网站可以支援香港、台湾和澳门繁体的分别翻译。Bluedeck 2024年5月30日 (四) 08:15 (UTC)回复

感谢蓝桌照顾繁体用户，但我目前查看似乎有一些界面仍然是简体中文的，例如新建工单的部分，另查台湾的教育部字典，work order这个词在台湾可以翻译为“工令”、“工作命令”、“工作通知单”或“工作单”等，就是没有查到称之为“工单”之翻译，惟我日常生活中前开所有词汇均较为少见，平常类似功能之提交申请平台反而被称之为“电子表单”，这部分可能需要更多繁体用户来指出正确的翻译。--小过儿（留言） 2024年5月30日 (四) 15:30 (UTC)回复
新建工单的繁体化已经完成。关于工单这个用语的翻译，我参考了一下asus的网站，叫做“请求支援”、“搜寻案件”。不知道这算不算合适的翻译。如果觉得“案件”听其来正确，那么我就把繁体语言的工单改称案件。Bluedeck 2024年5月30日 (四) 23:49 (UTC)回复
“工单”是对应“ticket”而不是“work order”，比如Zendesk香港也是叫ticket作“工单”[2]。再甚者，直接“搜索申请”也是得了，不需要特地什么ticket不ticket的了。--路西法人 2024年6月1日 (六) 08:37 (UTC)回复
@Bluedeck：怎么查阅或更改翻译？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月1日 (一) 19:44 (UTC)回复
通过改变浏览器的语言设置并刷新页面，可以查看不同的语言版本。目前要修改，可以直接留言告诉我哪里需要改。以后，会开放一个repo在github上可以pr。不熟悉sveltekit和github的用户仍然可以直接联系我。Bluedeck 2024年7月2日 (二) 06:00 (UTC)回复

工单的永久删除

编辑

目前没有这个功能。不过，根据欧盟GDPR要求，在用户请求的情况下，应该提供一种方法永久移除其个人信息。我想让管理员能够在工单上添加一个标记，被标记的工单约一个月后真正的删除。删除真正执行前可取消。这种删除只应该在特别的情况下进行（也就是用户请求）。（也可以单独只允许行政员执行真正删除，但是我觉得管理员已经足够可信，并且还有一个缓冲期间。）Bluedeck 2024年5月31日 (五) 23:04 (UTC)回复

这个功能不错。( π )题外话：我想知道维基百科不能删除账号是否符合GDPR，以及即使OS似乎也不是真删除，这是否符合GDPR。有人去举报一下是不是基金会就会实现这个功能了 。--桐生ここ★[讨论] 2024年5月31日 (五) 23:25 (UTC)回复
应该是不符合的，而且显示未登录用户ip这个似乎也有一定问题。然而我们要团结一致，不要把基金会举报给欧盟。 Bluedeck 2024年6月1日 (六) 05:34 (UTC)回复

让 IPBEG 在 Unblock-zh 上获得和管理员一样的权限

编辑

因为我觉得 IPBE 也是一大痛点，所以我觉得让 IPBEG 能够一起帮助处理会大有裨益。现在抛出几个方案讨论：

  1. 让IPBEG组和管理员同在unblock-zh.org/zhwp下有一样的（或者接近的）权限。
  2. 像邮件列表一样，单独新建 unblock-zh.org/zhwp-ipbe空间。
    1. 网站面向用户的界面不改变，根据用户是否需要 IPBE，自动将工单分发至 zhwp 或 zhwp-ipbe
    2. 网站设计改变，入口页面一分为二，用户需要自己选择是投递给zhwp还是zhwp-ipbe
  3. 不支持 IPBEG。

我觉得，从用户体验的角度，不希望入口一分为二。另外，不管选择 1 还是 2，都需要一段时间来修改网站的代码，但是 2 所花时间会更久一点，并且会增加日后维护的工作量（主要是会出现两套表单同步的问题）。关于用户隐私，由于 IPBEG 是签署 NDA 的，应该视为可信人员，所以我比较倾向 1。Bluedeck 2024年6月1日 (六) 09:25 (UTC)回复

设立IPBEG的本意就是许可IPBEG处理该类申请邮件，理论上可以说已有社群共识支持选项2，但已有共识未必支持选项1。IPBEG不能处理unblock-zh上非申请IPBE的工单。我是认为，一般而言封禁申诉本应都是在公开场合发起，申诉内容多数都应该可被所有用户查看，实质需要使用邮件申诉封禁的仅有无法编辑讨论页的情况。如你所言，IPBEG本有签署NDA，就算看了也不应该会造成什么问题（虽然能避免最好）。如果是最后采用最简化的选项1，那我觉得您可以最低限度在处理人员的界面中加入标签工单的功能，让IPBEG能明确标记跟他们职务无关的申请，从IPBE队列隐藏，仅能由添加标记的IPBEG（直至工单标签被管理员确认）及管理员查看。--路西法人 2024年6月2日 (日) 11:58 (UTC)回复
如果要让IPBEG不能看到非IPBE工单，那应该执行方式2更优。如果执行方式2，那么管理员、行政员也应该自动获得zhwp-ipbe空间权限，并进行工单自动分发。Bluedeck 2024年6月3日 (一) 08:34 (UTC)回复
不是“不能看到”，而是“不再跟IPBE有关的就没必要继续显示在同一队列，令其他正在处理IPBE申请的用户不小心点进去”。“看到”大概是不会有什么大问题的。--路西法人 2024年6月5日 (三) 02:22 (UTC)回复
分成两列或许方案2实现起来更简单？--桐生ここ★[讨论] 2024年6月5日 (三) 09:51 (UTC)回复
不是不行，但必须考量没签署NDA的管理人员是否有权限接触unblock-zh内的工单，一般视乎工单是否涉及IP地址等可辨识信息。如果要再这样分就分成三列了。--路西法人 2024年6月6日 (四) 00:04 (UTC)回复
还是那句话，我无法理解WMF要求邮件列表内的IP必须有签署NDA才能接触，但允许使用unblock模板直接把IP公开。--桐生ここ★[讨论] 2024年6月6日 (四) 09:48 (UTC)回复
我一开始听说IPBEG需要NDA，但管理员不需要NDA的时候，我也觉得很费解。而且你知道吗，你用的任何JS组件要是对外部资源进行请求，那么就可能有意无意泄露IP。甚至你收到一封邮件，邮件里带个图，这图也能泄露IP。虽然说IP在wiki上被当作隐私，其实整个互联网对IP的保护可以用奇差来形容。Bluedeck 2024年6月8日 (六) 04:05 (UTC)回复
似乎是祇有涉及IP等隐私信息时，才要求管理员签署相关协议。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月23日 (日) 02:13 (UTC)回复
@Bluedeck：只要不僭越社群赋予之权限，应尽可能以您自身方便为宜。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月6日 (四) 00:11 (UTC)回复

提供的IP问题

编辑

现在有个问题

  • 如果申请者没有使用代理时使用此网站提交工单，被此网站自动带入的IP是其真实IP，而非使用代理且受到IP封禁的IP，对于IPBEG应该使用真实IP还是受到封禁的IP判断？如果有人使用代理访问此网站，有人不使用代理访问此网站，也会产生差异。
  • 是否像传统邮件列表一样另外要求用户手动填入封禁界面上显示的受封禁的IP或封禁ID？这样也有好处，就是IPBEG可以看到申请者被封禁IP同时也能看到真实IP，确定申请者处于中国大陆等受限地区。但产生另外一个风险，就是如果确实提供的是中国大陆IP地址，一旦泄露可能产生严重后果。--桐生ここ★[讨论] 2024年6月6日 (四) 10:00 (UTC)回复
    • 技术上有很多方法可以尽量避免记录IP，比如只记录部分IP、以及对管理员不显示IP，只显示IP是否处于封禁列表中。但是这些方法无一例外的会对管理员处理造成问题。我想到的各种方法中，只有一个值得实践的，是在工单解决之后将IP相关信息从工单中清除，避免永久留存。除此之外，就只有请管理员和IPBEG不要泄露IP地址。对于代理的问题，我可以加一个提示让用户记得开代理，再者就是干脆取消自动侦测IP这个功能，让用户自己填写IP和查封ID，和邮件列表保持一致。Bluedeck 2024年6月7日 (五) 07:43 (UTC)回复
      我有一个方案
      • 申请者不提供IP：不提交IP
      • 申请者选择提供IP：检测IP是否中国大陆或其他受限地区
        • 是：不提交IP地址，只自动提交申请者IP地区，并且要求申请者手动填写受封禁IP
        • 否：自动带入IP地址
      --桐生ここ★[讨论] 2024年6月7日 (五) 09:10 (UTC)回复
      补充：IP地区是提交由服务端判断，而不是在前端处理，所以实际上仍然会提交中国大陆IP，只是不会储存在服务器上。--桐生ここ★[讨论] 2024年6月7日 (五) 09:13 (UTC)回复
      检测IP是否中国大陆或其他受限地区 这个感觉不是长久之计，GFW未来可能会给Unblock-zh上SNI封锁，用户会不得不套代理访问，这样Unblock-zh获取到的就不是真实IP--Yuki Rutygr (留言) 2024年7月9日 (二) 13:15 (UTC)回复
      • 我想过geoip定位这个方案，但是ip定位数据库需要每个月更新，而且并不完全准确。连维基媒体基金会都放弃了自己的geoip API（否则我就可以利用了）。有一个折衷办法，那就是查询封禁数据库。如果用户目前的IP不再封禁列表中，大概率说明没有开代理，此时我弹窗提示开代理。Bluedeck 2024年6月7日 (五) 19:59 (UTC)回复

RFDA（及未来成立仲裁委员会后的解任程序）相关探讨

编辑
最新留言：在4天前发布136条留言21人参与讨论

原标题为：动议：冻结社群解任管理人员程序直至仲裁委员会成立或按照当前新主流共识更改RFDA要求

撤回冻结方针动议，下方继续探讨正在讨论的话题。--路西法人 2024年6月14日 (五) 04:04 (UTC)回复
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

在与最新一期管理人员投票同步进行，有关“管理人员解任在多大程度由仲裁委员会处理？”匿名RFC中，获得不少针对解任程序未来去向的意见，其中存在绝对多数用户同意或不反对任一先行经过调查才能解任的方案，反映社群有非常强烈的初步共识认为解任管理人员前应先经过调查确认是否存在违规事实，由社群部分人的片面之词（甚至是扭曲方针指引及事实的说辞）来发动解任显然已经不再是主流观点。

由此，我谨此动议，冻结社群解任管理人员程序，直至仲裁委员会成立或按照新的主流民意调整RFDA的基本立案要求，确保RFDA仍然符合社群的最新意见和初步共识。当然，“直至仲裁委员会成立”可能还要等比较久，冻结至完成调整RFDA立案要求至满足新主流观点为止。

补充说明：若是在仲裁委员会成立前调整RFDA立案条件，则是参考仲裁委员会机制下“先调查、确认违规事实存在，再开展除权程序”。虽然我可以想像由社群来调查很可能也仍然会被部分人通过扭曲事实扰乱调查，但起码要比现在任意发起RFDA，不用顾不当行为事实是否成立要强。 --路西法人 2024年6月13日 (四) 15:04 (UTC)回复

看了一下Wikipedia_talk:仲裁委员会#管理人员解任和其中的问卷，我觉得这个方法是可行的，问卷当中也确实绝大多数人对此抱有期待，期待改变中文维基百科社群有处理的情况，也许在一些保持反对意见的人来看这不是什么好事，但某种意义上是一种进步，社群试图寻找出路。不过有一些要点还是要提醒下
1.仲裁委员会成员受到社群信任
受到信任的成员发出来的报告，报告的性质才不会被因"人"的原因产生变化，试着想想不受信任的仲裁委员会发布的报告，社群大多数人会接受与否。
2.仲裁委员会的意见及报告等社群要接受
这里的接受不需要所有人都接受，只需要做到绝大多数人都接受，注意这不是忽略少数人的观点，只是社群很难做到所有人都接受的事情，在很多事情上必然要做出取舍，如果所有人都要同意才能进行改变，长久下来对社群的发展是不好的。
3.仲裁委员会的在中维当中是处于什么样的位置
处于什么位置很重要，没有确立好，很容易产生争执。
----
最后看完讨论后我倒是有个建议，在"乙"的提案中加入一个前提，确保RFDA讨论是无法有效进行，谁也不让谁的情况再交由仲裁委员会，不需要一开始就交给仲裁委员会，如果社群能够处理，那就不需要仲裁委员介入，一定程度上可以避免争议，毕竟即便是仲裁委员发出的报告，也必然会有一部分的人不认同，如果全权都交给仲裁委员会，社群对仲裁委员会的不满意度会越滚越大，最后反倒吵起来说要把仲裁委员会撤掉，这是我所担心的，以上希望我的建议能为大家所考虑，谢谢。--~~Sid~~ 2024年6月13日 (四) 15:56 (UTC)回复
题外话，我建议社群可以的话，请为方针指引设立案例页面，用很明确的方式告诉所有人什么样子的行为与内容违反方针指引是不能做的，指引可能会遇到的例外情况也建议一并列举。--~~Sid~~ 2024年6月13日 (四) 16:28 (UTC)回复
此外RFDA我认同可以冻结，但如同上方意见，有些事情或许应该多加考量。--~~Sid~~ 2024年6月13日 (四) 16:36 (UTC)回复
注意我认同可以冻结，并不是代表一定要冻结，可以的话我仍建议可以讨论一下，当然我希望是有效的讨论，而不是大家又吵成一团 ( ~~Sid~~ 2024年6月13日 (四) 16:59 (UTC)回复
我不认同冻结，RFA和RFDA是维基百科的根基，仲裁委员会是尚未验证的后来之物。至于上方RFDA请求是否成立，诉诸共识或大多数人的共识即可。--桐生ここ★[讨论] 2024年6月13日 (四) 18:16 (UTC)回复
  • 管理人员解任在多大程度由仲裁委员会处理？
    • 甲、仲裁委员会按调查事实及方针指引，直接作出除权决定。
    • 乙、由仲裁委员会调查事实并发布管理人员操守报告，确认存在违规事实后，才转交社群决议除权。
    • 丙、仲裁委员会完全不参与管理人员解任。
问卷问题不当，并没有说明是所有RFDA按上方甲乙丙处理，还是只有争议无法在社群解决然后送到仲裁委员会的RFDA案件，按上方甲乙丙处理。--桐生ここ★[讨论] 2024年6月13日 (四) 18:24 (UTC)回复
当初问卷内容实际上没有经过社群共识决定（贴出草稿而已，没有正式公示通过），所以问题很多。当初我早就提出质疑，也未获澄清，就莫名其妙拿去安全投票了。还好问卷祇是咨询性质，没有产生什么约束结果。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月13日 (四) 20:24 (UTC)回复
(－)反对冻结程序：现有之管理人员解任程序本来就是经共识产生；前述问卷祇是就仲裁委员会之角色提出咨询，没有如何连带处理社群既有程序的要求，故本来与此无涉，至少不应该过度延伸。再说，最近几次案例也显示，原来没有共识基础的解任投票提案，都根本不会通过，甚至一大部分提早就宣布无效，正是彰显社群尚未失能，现行程序运作无碍。另外，现有方针很明确定义管理人员解任条件及必要程序，早也就是所谓“确认违规事实存在（内容不符或原因不合理，可视作申请无效），再开展除权程序”之流程，差别只是在仲裁委员会作为实体机制，调查结果大概可以比较明确，而现有程序中，社群之“确认”较为隐性，反映在支持连署及讨论过程中。现有程序并没有任何常规替代方案（不计紧急解任），或可说共识陈旧而需要修订，然在有具体解方前，显然不应该剥夺社群对管理人员人事的最后决定权。该问卷祇是再一次确认社群长年以来认为有相当理据才能解任管理人员（这也应该是常识），并认同社群拥有最后决定权（而非由仲裁委员会径行决定）的固有认知（不是所谓“新主流共识”）；社群合资格者（以后的仲裁委员会当然也在内）都能提出解任，但祇有社群后续判断理据确实者，才有机会获得足够支持，这是兼顾维基人发言权利及社群意志实践的作法，自然符合社群共识。此提案属于凭空制造问题。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月13日 (四) 20:05 (UTC)回复
你的主张是现有方针很明确定义管理人员解任条件及必要程序，早也就是所谓“确认违规事实存在（内容不符或原因不合理，可视作申请无效），再开展除权程序”之流程，然而跟你自己的主张相抵触的是，你身为此解任案的第三方管理员，在该用户明显威胁、胁迫其他第三方管理员等不文明行为、连其主张的滥用封禁权限都已经被解封管理员的说法打脸（封禁理由成立只是解封管理员认为不需封禁），更公然声明将不会讨论违规事实成立与否、仅由联署人自行认定沟通无效，完全跟你口中的“必要程序”相抵触的时候，却完全不予阻止袖手旁观，这不就反映社群阻拦不文明、滥提解任的失能完全成立？过往非当时管理员依照方针赋予的权力提前结束解任案还受质疑，岂不是完全反映社群决策能力已完全失能，而仅有少数正常的管理人员维护方针？--路西法人 2024年6月13日 (四) 22:17 (UTC)回复

本主题全部或部分段落文字，已移动至#当前解任案效力。

一并回复Ericliu1912及桐生ここ：……（讨论已移动至下方）--路西法人 2024年6月13日 (四) 22:36 (UTC)回复
(－)强烈反对：
  1. 仲裁委员会机制尚未验证，其实际效果和操作过程尚不明确。为了一个尚未验证的机制，而冻结现行的有效程序（显然不会因行政员争议性的终止等同无效），无异于舍本逐末。关于仲裁委员会在管理人员解任中的角色，在下同@桐生ここ：目前的问卷问题存在明显的不足。问卷没有明确说明是所有RFDA按上述甲、乙、丙方案处理，还是仅有争议无法在社群解决的RFDA案件按上述方案处理。此种不明确性导致问卷结果不能充分反映社群的真实意见。
  2. 考虑到仲裁委员会的设立、仲裁员选举、立案时长分析、条文讨论等过程显而易见地非常冗长，冻结现行程序更有阻挠现行政策正常运作，即时处理当事管理员问题之嫌。应按照现行规则即时的处理管理员问题，确保社群的正常运作，不受争议管理员可能之危害。
  3. 最后，在下坚决反对行政员可能在任意时间决定冻结RFDA程序的行动。此种争议做法在前次已经引发“官官相卫”“未得社群共识”“违反官僚体系”等严重质疑，损害社群讨论之原则。甚至换句话说，如果仲裁委员会一日不创建，便一日不能追究、及时处理管理员之问题，显然干扰社群监察程序。综上，在下反对冻结。并建议直接滚雪球关闭此讨论。--Gluo88（留言） 2024年6月13日 (四) 20:18 (UTC)回复
@LuciferianThomas：还请动议人在此处说明一下仲裁委员会相关事宜的进度。假如进度推进得足够快的话，冻结程序并不一定必要。Sanmosa Snipe–Clam Grapple 2024年6月13日 (四) 23:13 (UTC)回复
目前尚余总结解任相关观点，并设计出符合尽量多人意愿的解任相关机制后，就能写整个方针，经过社群公投endorse后上路。
就算进度推进得够快，也无法阻挡当前Gluo88公然发表违反解任程序要求的提案，在修订社群解任途径确保程序公义前或仲委会机制上路前，仍应冻结当前程序。--路西法人 2024年6月13日 (四) 23:31 (UTC)回复
(！)意见-将这两件事情链接起来成为条件，恐怕有疑虑，是否要开这样的先例？恐怕会带来些副作用与后遗症。会否让既有方针被冻结了？过去，没有仲裁委员会，相关的程序与方针仍然持续进行，就是依照既有方针在做。Wetrace欢迎参与WP人权专题 2024年6月14日 (五) 00:21 (UTC)回复
实际上早有先例。过往就是本地用户查核权出了问题，使基金会冻结本地用户查核权。另外，请注意提案中除了“冻结到有仲裁委员会成立”外，还有“或（冻结至）按照调查得出大家的主流观点”（或如某些人否定调查得出的多数意见，也需确保程序公义得到彰显）的选项。--路西法人 2024年6月14日 (五) 02:09 (UTC)回复
社群提出与仲裁委员会调查管道实际上仍应并行，这里讨论的祇有前者。因为很显然，仲裁委员会祇能处理于该处提出告诉的案件，不能为整个社群越俎代庖。但我有点担心，新提案在加入仲裁委员会角色同时，还打算一并消灭社群自行提出管道。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月14日 (五) 00:33 (UTC)回复

本主题全部或部分段落文字，已移动至#仲裁体系下的解任机制。

我跟ATB正在共同筹备有关未来解任制度走向的提案……（讨论已移动至下方）……--路西法人 2024年6月14日 (五) 01:16 (UTC)回复
是否无论如何一定要先经过仲裁委员会“确认”？本人认为社群自身仍有径行运作程序的能力，不用全部经过仲裁委员会审查，祇有拒绝受理才能被动提案。当然，若要避免所谓“民粹政治”，可以提高标准。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月14日 (五) 03:31 (UTC)回复
或许我说的不清晰：我在ATB方案上增添的走线是给“社群提交给仲裁委员会”新增了前设，故产生“社群无人提请仲裁（而社群自行解决解任问题）”的走线。若社群自行走解任程序时理据出了问题，自然会有人提交给仲裁委员会；若真的几乎没有争议的，那社群自己走完整个程序都不会需要仲裁委员会插手。如果有人提交，仲裁委员会又认定社群本身在该案已能自行处理（发起除权无明显问题需要仲裁委员会插手），即可拒绝社群请求。不经仲委会提出除权的条件也不需要怎么提高，还是满足最基本的程序公义即可。--路西法人 2024年6月14日 (五) 03:42 (UTC)回复
本人认为，现行情况实际上就是这样，也就是社群多数时候能够有效拒绝理由不完备的提案正式投票。那或许是对“事前”部分疑虑较多？也就是欲阻止伊始即直接上客栈“大乱斗”的丑陋局面。不如拿上面刚刚提出的解任案问问，你觉得该案提请有什么可能不满足程序正义之处，毕竟有实际案例较好切磋。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月14日 (五) 03:54 (UTC)回复
另外抱歉刚刚太认真看右边那张图，没仔细注意您有提出“比图片多一条”的走线Orz —— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月14日 (五) 03:58 (UTC)回复
(－)反对。认为应该在选出仲裁委员会成员，完善相关方针之后再议，RFDA毕竟不是RFA，冻结不会带来什么好处，反而会带来麻烦，比如当前这项解任案，我不会对其进行任何评价，如果直接将之冻结，可能会使相关用户作出其他极端行为。如果其解任违反相关方针，可以直接由行政员决定关闭，而非冻结之。--在下荷花，请多指教（欢迎签到） 2024年6月14日 (五) 02:20 (UTC)回复
注意，解任方针是规定任何非当事管理员已可决定关闭，并无限制只能是行政员。另，我理解您反对冻结，若管理人员能及时阻止本次明显有可能要违规闯关的提案，而有关用户持续扭曲管理员言行的行为获确切的阻止，那我将不会继续追求冻结解任。能否请您就上方我和ATB（未在此留言，但右方流程图是他制作的）提出的解任走向有何意见？若我在仲裁委员会成立前参照该走向修改解任方针（就是把仲裁委员会替换成社群整体调查，走先调查后解任的流程，确保未来不能再有同类事情发生，你又是否同意？--路西法人 2024年6月14日 (五) 02:30 (UTC)回复
(－)反对，我觉得先等仲裁委员会成立，且已确定相关的流程及规则，再来调整RFDA的作法。不太适合此时冻结解任管理人员的程序。--Wolfch (留言) 2024年6月14日 (五) 02:37 (UTC)回复
(－)反对，目前没有数据是否有效，更且仲裁委员会还没成立，成立后，必须先观察，不需马上处理冻结解任管理人员的程序--HYHJKJYUJYTTY（留言） 2024年6月14日 (五) 03:43 (UTC)回复
(－)倾向反对：正如Gluo88君所说，“仲裁委员会的设立、仲裁员选举、立案时长分析、条文讨论等过程显而易见地非常冗长”，而这段时间内仍有RFDA的需求。如果现在冻结RFDA，恐怕会导致这些需求难以得到满足。--CuSO4 · 龙年大吉 2024年6月14日 (五) 03:48 (UTC)回复
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

当前解任案效力

编辑

一并回复Ericliu1912及桐生ここ： 虽然题目是针对仲裁委员会，但有关留言中的论据却很多是广泛对社群现象的描述，“社群失能”、“需要评估事实”、“先调查后除权”等显然是广泛的观念。该问卷无法直接影响此动议，但有一定参考价值；所谓“仲裁委员会只处理社群无法解决才送到仲裁委员会的RFDA案件”也几乎是没考虑到“毫无疑问需要除权的操作大概都是走紧急除权”，管理人员解任投票也甚少有不会引起争议，基本上到最后90%的都还得送到仲裁委员会解决（尤其是双方不认可对方的论证的情况），近年每次除权争议更是暴露了社群无法管控用户不捏造事实、不扭曲方针、不无视解任程序的弱点，完全佐证了当前解任程序需要更明确要求调查确认有违规事实再发起除权程序。所谓“比较隐性的确认”反而是“完全没有在发起前就明确确认”的意思，所谓的“确认”通过“联署及讨论过程”，但显然发起解任程序的用户没有也不会考量讨论内容，而是径自联署就打算闯关，联署也无法发表实际的反对意见，简而言之就是“七名无公信力用户自行认定有罪”就开展解任，并不存在真实的“确认”违规事实，这也是近期情况和你的声称所互相矛盾的。

另外，看到两位的反对都是针对仲裁委员会，然而我自己也在动议中表明更理想的情况不是“等仲裁委员会决定”，而是当前就直接明确RFDA的要求。还是那句，虽然题目针对仲裁委员会，但意见的变化是显而易见的，我也没有打算要把那个调查当作“已经存在的共识”来说话而是“参考其意见而发起新的动议”，请搞清楚此提案的意义。--路西法人 2024年6月13日 (四) 22:36 (UTC)回复

那可以继续讨论。由于本人支持未来社群提案与仲裁委员会调查两管道继续并行，自然也有查看前者并加以调整之必要。本人也并未否认近年来见得诸多不成熟之解任提案，徒然浪费社群资源。此处只是要指出，不应该因为若干用户可能脱序或滥用之行为，就要求直接“冻结”社群的民主权利，现在又不是什么非常时期。“提出解任”本身也是程序不可忽略的一部分，无论内容有多么不合理，至少也要先“存在”才能予以驳斥（更何况其实指引已经明确指出，提案伊始即“内容必须详细，指出管理滥权的原因，并根据编辑记录及用户贡献提出相关证据”，理论上不满足即自始无效）；即使往后要组织某种详细“调查”，也是要先有人“提出”或“申请”管理人员可能的滥权行为，不可能凭空造成。所以本人并不理解过度夸大此一阶段乱象的用意。另外，若既已为满足前述有效条件之提出，则此后之辩论，维基人间存在观点差异亦实属正常；虽不排除确实有“无脑支持”者（实际上任何站务程序都有），但径行认定联署是“无公信力用户自行认定有罪就开展解任”，则恐怕有歧视若干社群参与者及菁英主义思维作祟之嫌。照这种说法，所有人可能都是“无公信力用户”，管理员解任申请不就变成“无公信力用户法庭”。不过如此一来倒是大概可以理解，为什么那么坚持要走以仲裁委员会径行裁决这种路线。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月14日 (五) 00:07 (UTC)回复
一般用户不经任何选举，公信力是undefined（这种“没有公信力”）。仲裁委员整体有一定公信力。
另，虽解任案未正式发起，管理员未能按解任方针取缔，但他能预告将会作出违反程序的行为，管理人员也可明确告知违反程序的提案将会被截停，并呼吁其遵守程序，在已知会发生的问题发生前直接堵截，而不是等到问题发生才做事。--路西法人 2024年6月14日 (五) 01:29 (UTC)回复
若方针持续遭到滥用、扭曲，且情况非常明显，如果放任不管也会造成明显大的伤害（如除权方针），那么自然就该冻结程序，这好比现实中正在提出释宪的法案可被临时暂停执行；正如如果未来社群选出的仲裁委员会go rogue，放任不管也会造成明显的伤害，那么自然就该冻结程序。--路西法人 2024年6月14日 (五) 02:18 (UTC)回复
本人不认为冻结整个程序符合比例原则。所谓“持续”，也不必然。况且就该案而言，当事管理员作风问题乃长久以来众所皆知，也引起诸多争议。提请解任本身或许过当，但其来有自，当中所隐含的问题并非全然无探讨之可能。我们管理员是有权力的一方，本来就应该赋予对造相对多话语权，易言之即容许较大限度之发言自由，这本来也是他们唯一可以“制衡”管理员行使职权的办法。本人不认为该案之提出者在“滥用”解任程序，至少也不应该是扩大到其他个别案件的理由。另外，现行解任程序少数的大问题，就是虽然指出要“沟通无效”，但很多时候当事管理员坚持立场，就很容易构成，然后就是客栈提案一片混乱。本人认为就条文相关部分讨论如何清晰定义（尤其是什么样的内容理由为“有效”），且“同时”兼顾当事管理员及提请人权益，要比冻结整个程序实际多了。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月14日 (五) 03:38 (UTC)回复
以上讨论分拆自上方讨论。--路西法人 2024年6月14日 (五) 04:02 (UTC)回复
Gluo88以威胁的语气试图阻拦其他管理员正常行使方针的语气，并在其本身对管理员行为的扭曲理解下营造管理员滥权的不实情形，并可以从其语调看得出不会接受任何解释。反观苗君仍在积极解释、回应或回驳观点，也通过讨论、交涉获得解封Gluo88的蓝桌君出来说话，表明不认同Gluo88对苗君的指控。这些反映苗君确实有在积极沟通（回驳观点也是沟通的一种）。反而是Gluo88的态度表明拒绝接受一切解释，自己拒绝沟通并持续扭曲事实，自行制造沟通无效的条件，这显然不是解任方针的本意。--路西法人 2024年6月14日 (五) 04:02 (UTC)回复
我刚刚才发现，解任投票根本还没正式提出，那就更不用为此谈相关程序问题了吧？该话题现在已经变成实质沟通之处。唯一认同者，即在此情况下，当事人不宜径行提出解任。若未能如愿，而届时社群能有效应对，那亦可再度证明解任程序运作有效。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月14日 (五) 04:20 (UTC)回复
否，我上面有指出：虽解任案未正式发起，管理员未能按解任方针取缔，但他能预告将会作出违反程序的行为，管理人员也可明确告知违反程序的提案将会被截停，并呼吁其遵守程序，在已知会发生的问题发生前直接堵截，而不是等到问题发生才做事。--路西法人 2024年6月14日 (五) 04:29 (UTC)回复
我不太理解，难道质疑管理员亦不可？他虽如此“威胁”，但未付诸实行之前，无论如何实不可以“现行犯”论之。若社群多人持续表达关切意见，他也并非不可能拒绝“听劝”。此外，这毕竟也与解任投票本身没有直接关联（因为解任投票尚未启动，不构成程序问题）。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月14日 (五) 06:10 (UTC)回复
不是不能质疑，而是不能以扭曲方针的理解来质疑管理员，连给Gluo88解封的管理员都认为苗不存在扰乱或诽谤，而他自行判读管理员解封就代表对其的封禁是诽谤、是滥权，这不就反映观念上就有问题，问题并非出自于被发起除权的一方？Gluo不断合理化自己的行为，而苗、我甚至是蓝桌都一再指出Gluo88先前行为并非妥当（只是蓝桌认为不至封禁），这不叫质疑，而是扭曲方针及事件事实而诽谤管理员吧。--路西法人 2024年6月14日 (五) 09:38 (UTC)回复
他可以提出质疑，社群则可以适当支持或反驳之，这是共识形成的正常过程。在此案中，大概认为理由不充分者居多，是否成案尚有商榷余地。本人也不好评价个别管理员作风“惹人怨”的程度，但明显可见并非孤例，故此处比起“带有情绪而冲动质疑”之类形容，“诽谤”一词或需要慎用。当然也可能是我对此类批评管理权限行使问题态度向来比较“宽容”。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月14日 (五) 13:05 (UTC)回复
上方解任案成功且合规立案的可能性之低，我已无意愿再参与讨论。不论是原则上还是方针条文上，都没有条文能支持他做的事，如果他还是正式发起解任案，我再请求其他管理人员制裁有关行为即是。--路西法人 2024年6月15日 (六) 00:59 (UTC)回复
“以扭曲方针的理解”的操作空间过大，并非一个适合的判定标准，不然大家互相指控其他人的理解“扭曲方针”还得了。Sanmosa Snipe–Clam Grapple 2024年6月15日 (六) 00:58 (UTC)回复
每个方针都有背后的大原则，如果是对方针条文理解有误的人，都难以推翻背后的大原则。明知自己对方针条文理解与方针背后原则和用意冲突的情况仍继续坚持的，那就只能是扭曲方针了。--路西法人 2024年6月15日 (六) 01:02 (UTC)回复
我的意思是，真到了我说的那个情况，那个人是否真的“扭曲方针”还重要吗？我最担忧的事情是大家互相指控其他人的理解“扭曲方针”的时候，大家的指控实际上都是成立的，因为根本没有人（在任何意义上）“正确理解方针”。Sanmosa Snipe–Clam Grapple 2024年6月15日 (六) 07:53 (UTC)回复
同意。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月15日 (六) 18:02 (UTC)回复

仲裁体系下的解任机制

编辑
 

我跟ATB正在共同筹备有关未来解任制度走向的提案，当中不会完全汰除社群自行发动解任的途径，只是会有一定改动确保程序公义。右图是ATB建议的走向，而我的想法是再向上加一条走线：社群发起解任后，用户只能在投票发起前才能提交证据请求由仲裁处理，仲裁委员会在七日内需决定是否受理（条件：初步认为解任提案理由有问题）并展开详细调查。由于解任走SecurePoll似已通过，准备SecurePoll也需要时间，多等七天不会有什么大问题。拒绝受理或投票发起后不能由仲裁截停（已放弃受理权）；因拉票等因素而截停则不是RFDA仲裁机制了，而是一般用户行为仲裁。这样能确保仲裁不会被过度使用之余确保未来解任程序能达到程序公义。补充：若社群提交给仲委会的理由跟发起除权的理由太不同，则自然不能视作仲裁委员会已放弃调查权，为防被滥用规则而挟带不当理由闯关。--路西法人 2024年6月14日 (五) 01:16 (UTC)回复

是否无论如何一定要先经过仲裁委员会“确认”？本人认为社群自身仍有径行运作程序的能力，不用全部经过仲裁委员会审查，祇有拒绝受理才能被动提案。当然，若要避免所谓“民粹政治”，可以提高标准。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月14日 (五) 03:31 (UTC)回复
或许我说的不清晰：我在ATB方案上增添的走线是给“社群提交给仲裁委员会”新增了前设，故产生“社群无人提请仲裁（而社群自行解决解任问题）”的走线。若社群自行走解任程序时理据出了问题，自然会有人提交给仲裁委员会；若真的几乎没有争议的，那社群自己走完整个程序都不会需要仲裁委员会插手。如果有人提交，仲裁委员会又认定社群本身在该案已能自行处理（发起除权无明显问题需要仲裁委员会插手），即可拒绝社群请求。不经仲委会提出除权的条件也不需要怎么提高，还是满足最基本的程序公义即可。--路西法人 2024年6月14日 (五) 03:42 (UTC)回复
本人认为，现行情况实际上就是这样，那或许是对“事前”部分疑虑较多？也就是欲阻止直接上客栈“大乱斗”的丑陋局面。或许拿上面刚刚提出的解任案问问，你觉得该案提请有什么不满足程序正义之处，毕竟有实际案例较好切磋。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月14日 (五) 03:54 (UTC)回复
  1. Gluo88提出苗君滥用封禁的证据，光是与给他解封的管理员的理解已有显著落差。提案人径自认定管理员滥用权限或封禁有瑕疵，而未经审视方针是否禁止某些行为，违规事实并不明确，解任案则不应成立。
  2. Gluo88对苗君诽谤Lanwi1的指控显然存在误差，苗君作为当年事件的当事人，除了当时短时间内就补充提供了公开讨论的记录外，其当年作为用户查核员能将Lanwi1的公开口供跟技术信息比对，亦可作为其指控或怀疑的证据。有证有据者的合理怀疑显然难以构成诽谤，反观Gluo88在他人（我）指出苗君确有提供证据后，选择性无视并谎称“没有证据”（证据已经提供了，还有一些是苗君显然不能公开的），还在毫无证据的背景下相信Lanwi1的说辞，用以指控苗君诽谤，乃是明显的拉偏架，“诽谤”指控也难以成立。
  3. 苗君在讨论中积极解释、说明其行为，也通过交涉获得解封Gluo88的蓝桌君的认同；反观Gluo88全然不接受任何解释，并拒绝一切依照方针的规范及通用理解的观念，显然并非管理员所致之沟通无效（而是提案人拒绝沟通），不能成立解任案沟通无效之要件。
  4. Gluo88在一开头就声明将会发起明显违反方针（不审核是否构成解任条件，只凭其自身及联署人认定），亦有威胁其他管理人员不可执行方针赋予的权力（终止不当解任案），显然严重侵犯程序公义。
光是这些，若仲委会已成立，以上程序问题已经足以将此由社群发起的解任案提交仲裁委员会处理了。--路西法人 2024年6月14日 (五) 04:20 (UTC)回复
  1. Gluo88提出苗君滥用封禁的证据，光是与给他解封的管理员的理解已有显著落差。在管理员最初已认定封禁查封理由欠缺，这是事实。也尊重审核管理员认为程度不到罢免的理念。涉事管理员的理解与本人的理解（及其他用户的理解）也不相干，除非诉诸权威。
  2. Gluo88对苗君诽谤Lanwi1的指控显然存在误差，苗君作为当年事件的当事人...通篇仍然持续为当事人未经认证（CU、CA）臆测伪证据发言，并忽略当事人已遭受严重精神重创的事实。打个不恰当的比喻，如果一个强奸受害者侮辱强奸犯，然后某个认说她犯了侮辱诽谤罪，她的言行客观上是不妥的，但这种检讨受害人的行为更是拉偏架，扭曲一般人道德理解，态度可谓令人发指。
  3. 苗君在讨论中积极解释、说明其行为，也通过交涉获得解封Gluo88的蓝桌君的认同...先不论在下几乎已全面驳斥阁下及涉事用户谬论（并且您除了诡辩，显然无法正面回应；另一位也没有能力全面回应在下的质疑）只能是个人意见，不代表我认同（及其他潜在用户认同），照@LuciferianThomas这种伪逻辑，在下尝试总结一下：大概就是只要当事人不断“发言论证沟通”就不构成“沟通无效”（并将其归责于提案人及联署人死活不认可），上个这么声称及类似的案例已被基金会制裁了。
  4. Gluo88在一开头就声明将会发起明显违反方针（不审核是否构成解任条件，只凭其自身及联署人认定），亦有威胁其他管理人员不可执行方针赋予的权力（终止不当解任案）... 我并没说不审核，而是交由联署人审核认定（本来现行方针就不用一致共识确认），这恰恰是符合过往惯例标准的原则（《方针》政策指出，大部分被人们接受的惯例不会立即被写上。方针只是明文的惯例标准。）反观前次管理人员的所谓“决定”已被广泛质疑“官官相卫”“违反官僚主义”“凌驾讨论”“无权确认”“不避嫌”这种藐视社群的决定，恰恰是侵害程序公义的行为(“管理员没有任何高于其他用户的特权，唯能实现社群讨论所得的共识“)，更应该就行政员争议行为交到仲裁委员会裁决，以正视听。
  5. 其实面对您的指控，在下本来是不打算留言的，但在下考虑到您并未停止有关涉嫌扰乱及游戏讨论行为，甚至发出明显的威胁，呼吁第三方管理员制裁在下，才不得不在此回应。此外，这个发言涉嫌“针对特定受众”基于“推销立场”的拉票行为。根据行政员前次所谓认定，“RFDA是本站大事”浏览量极高，所以已经构成大幅张贴效果。考虑到相关留言通篇粗亮红字体，还有可能构成情绪勒索骚扰用户（与第三方管理员）。副知在上次解任时发起讨论“拉票”的@魔琴阁下就此发表看法 。
以上可合理确认LuciferianThomas君的所谓“程序问题”，无一例外其实都站不住脚。即使仲裁委员会成立，诸位仲裁员面对阁下指出的“程序问题”，在仔细审阅相关讨论后，除了给您发不应在讨论中，使用过多特效使别人感到骚扰的提醒或警告外，基于方针的正常理解相信也只能一笑而已。
在下请@LuciferianThomas君停止为涉嫌袒护涉事用户试图干扰本次Rfda的行为，并期望根据在下对阁下提出的质询，检讨当事管理员及自身问题，作出有益讨论事情。--Gluo88（留言） 2024年6月16日 (日) 01:06 (UTC)回复
我不好说其他人对于拉票是怎么定义的  ——魔琴［身份声明 留言 贡献 新手2023］ 2024年6月16日 (日) 02:07 (UTC)回复
另外抱歉刚刚太认真看右边那张图，没仔细注意您有提出“比图片多一条”的走线Orz —— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月14日 (五) 03:58 (UTC)回复
这个我自己也没说清楚。--路西法人 2024年6月14日 (五) 04:22 (UTC)回复
大致同意上述图片的内容。--在下荷花，请多指教（欢迎签到） 2024年6月14日 (五) 04:34 (UTC)回复
简而言之，我反对把像台湾选总统一样的直接民主改成香港选特首一样的代议民主。香港特首怎么选，我觉得你也知道。--桐生ここ★[讨论] 2024年6月14日 (五) 07:22 (UTC)回复
同意桐生的想法。--千村狐兔（留言） 2024年6月16日 (日) 01:43 (UTC)回复
 
右方为添加了我所说的比ATB版本多一个走法的机制，Ericliu1912及Hehua可以参考看看如何。除了RFDA，其实多数其他仲裁调查都可以比照处理。--路西法人 2024年6月14日 (五) 05:59 (UTC)回复
看起来主动权是否仍在仲裁委员会？因若每一案总是有人要求受理调查，那程序上便实质造成社群直接管道不得通。管理员解任争议向来大，可预见会有不少辩称个案程序不符合方针者。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月14日 (五) 06:11 (UTC)回复
是也没错，我甚至是预期未来绝大多数的仲裁提案最终必须经过仲裁委员会的手一次，但既然管理人员解任社群没办法自己处理（真的有问题的时候，还是得仲裁介入，总不能坚持不让仲裁处理违规事项吧？），那把这个程序几乎完全交给仲裁是可以理解的。我是不反对设置反联署的机制（联署改交仲裁委员会），但送往调查的门槛会要比直接送投票的要低一截（例如送往调查需5人联签，解任联署门槛提高至10人）。
不过起码这里保障了多数情况下社群仍保有投票除权的权力，也确保仲裁委员会仅能在真的有问题的时候才介入管理人员解任程序（在社群能自己处理及未获解任程序中的合理质疑的情况下应拒绝受理），但也确保在必要情况下由仲裁委员会自行行使去除管理人员权限的权力。（所谓必要情况，指滥用傀儡等所有可致（非短期）封禁或禁制的违规情况）--路西法人 2024年6月14日 (五) 06:58 (UTC)回复
如此怕是有游戏规则之嫌，毕竟祇要提出质疑，就可以强制将讨论拖入仲裁程序，也很难预见仲裁委员会不会因为期望有案件，而对此倾向“照单全收”之类。此外，本人认为仲裁委员会试行第一任期期间，不宜移交过多权力。希望还有某种折衷或过渡方案供社群选择。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月14日 (五) 12:59 (UTC)回复
不过，考虑到社群或有希望仲裁委员会针对此类提案提供调查报告，若祇是请求类似国际法院就议题提供咨询意见之类，而不直接跳过其他社群既有流程（即最右边那条路线），那本人并不反对。其区别在于是仲裁委员会是主动受理调查，还是基于社群需求被动提供意见（用词或有差异，但总之应该是这意思）。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月14日 (五) 13:09 (UTC)回复
回应第一则留言：
  • 很难预见仲裁委员会不会因为期望有案件，而对此倾向“照单全收”之类：仲裁委员会在接获针对已经发起的RFDA案请求时，并非单单议决“是否受理”，仲裁员公开议决是否受理案件时还必须指出受理或拒绝理据，也不能空口无凭说“社群已无法通过社群渠道解决”，而是要提供论证。究竟是怎样无法通过社群渠道解决，究竟是否非当事的管理人员采取行动即能解决，都是必须论证的点。当仲裁委员会收到直接提请调查管理人员行为之时，条件同样适用，这情况下提出调查的人也是需要论证为何不通过社群解任程序（例如：提出解任一方论据不当，可预期他们走社群解任必然会造成问题）。仲裁委员会就算是“想接受案件”也要写个合理到不行的理由，但有合理的理由就代表真的要接受案件了。
回应第二则留言：
  • 你的理解大致正确，但必须指出在“已经有明显必要解任”、“紧急解任”或“根本不成立”等情况下，则不会发起任何解任投票，而直接由仲裁委员会作出决定。你所说基于社群需求，这个就很难定义什么叫“社群需求”了，究竟是有人联署发起仲裁，还是需要有共识，都会有人不同意；后者在已经吵得不可开交的情况下显然已经难以实行，所以唯有通过联署的方式发起仲裁以确保真的是“社群”需求而非“个人”需求了。
--路西法人 2024年6月15日 (六) 00:48 (UTC)回复
据我所知，社群共识不希望仲裁委员会作出径行除权决定。那紧急除权外的“已经有明显必要解任”是什么意思？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月15日 (六) 18:01 (UTC)回复
说过了啊。--路西法人 2024年6月17日 (一) 01:53 (UTC)回复
这还真是没看清楚（ —— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月18日 (二) 17:58 (UTC)回复
感谢提及，我个人基本(＋)支持此方案。--在下荷花，请多指教（欢迎签到） 2024年6月14日 (五) 07:55 (UTC)回复
我认为此方案可以。--~~Sid~~ 2024年6月14日 (五) 08:36 (UTC)回复
支持这个版本。--Rice King 信箱 · 留名．边缘人 2024年6月14日 (五) 11:25 (UTC)回复
(＋)支持此一版本。--维基病夫邀请您加入❤️边缘人小组·🖊️签到 2024年6月14日 (五) 11:41 (UTC)回复
我问个问题，如果RFDA只有一人认为不符合方针，即使整个社群都支持联署，也必须进入仲裁委员会程序？这个有人认为的有人是多少人？--桐生ここ★[讨论] 2024年6月14日 (五) 13:03 (UTC)回复
这自然是需要"讨论"的，当然也有个更简单的方法是让认为不符合方针的人自己送，仲裁委员会看到这种情况自然会拒绝请求，有个坏处是会让仲裁委员会很累就是，如果要采用，建议赋予仲裁委员禁止滥用仲裁的人提出仲裁请求的权力。--~~Sid~~ 2024年6月14日 (五) 14:09 (UTC)回复
如我上方留言所述，确实可以新增反联署的概念，或为五名符合人事任免投票权的用户联署，或为最低限度一符合人事任免投票权的用户加一非当事管理员共签请求仲裁。一个人（尤其是当事管理员本人）即可发起进入仲裁程序也还真的门槛过低。--路西法人 2024年6月15日 (六) 00:29 (UTC)回复
如果要改革的话，我觉得应该加入反联署过程才能被仲裁委员会受理，不然就像你说的，当事管理员反对然后就进入仲裁就有点不合适了。--桐生ここ★[讨论] 2024年6月18日 (二) 19:23 (UTC)回复
原则上(＋)支持，太需要了。--Shwangtianyuan 不忘初心 牢记使命 2024年6月14日 (五) 16:13 (UTC)回复
  • 个人意见是发表调查报告后，解任与否应公付社群决议。即便调查报告认为提请解任是多么错误，社群应拥有解任事宜的最终裁量权。-千村狐兔（留言） 2024年6月16日 (日) 02:25 (UTC)回复
    此前社群咨询性投票已明确认可这点，我相信应该会体现在最终方案。没有的话再来商榷。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月16日 (日) 04:22 (UTC)回复
    大致上认同这个观点，毕竟不能排除调查报告出错的可能性（是的，请质疑一切的权威），但我的个人意见是如果调查报告的结果是管理人员因属于有必要的情况或紧急情况而被直接解任，这并不属于社群的裁量范围。换言之，我认为如果调查报告认为这不属于可以解任的情况，但社群形成了显然相反的共识时，无论调查报告是否出错，社群依旧可以在有相当共识的情况下发起解任投票，但其他方面我认同File:ArbCom de-admin procedure chart (LT version).png的表述。Sanmosa Snipe–Clam Grapple 2024年6月18日 (二) 12:09 (UTC)回复
    “真有必要”就直接解任了，没必要再提出调查报告，祇需要简短说明。“真有必要”的情况应当已经很明确，正常人都看得出来（常识判断），否则就不能说是“真有必要”。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月18日 (二) 17:57 (UTC)回复
    实际上就连上面举例的滥用傀儡，我也不觉得必然适用直接解任，至多是调查期间允许暂时褫夺管理权限。因为这终究取决社群对管理员的信赖，说不准社群愿意原谅过失，那凭什么需要由仲裁委员会擅自代为“处刑”呢？由于已经有真正最后手段“紧急解任”，我甚至不觉得有必要给予仲裁委员会所谓“有必要情况”除权的选择。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月18日 (二) 18:02 (UTC)回复
    管理员不会有其他用户没有的豁免权，管理员做出应受非短期(全站范围)封禁或禁制的行为理应受与一般用户相同的处理，而受(全站范围)封禁或禁制期间管理员本身就无权参与社群事务。近期受过封禁的用户本来就不能参选管理员，这个相比其他“建议条件”而言更几乎是“必然需要符合”的要求，也是社群的基本期望。因严重违规而致非短期封禁或禁制行为的用户本来就不适任管理员，这种情况的解任是弹劾而非罢免。社群有权在被弹劾用户接受封禁及一年冷静期后经重新选举上任管理员，但显然有过错的就不是“可以被社群原谅”的行为。用户单单因管理员身份而被“原谅过失”显然变成获得其他用户没有的特权。--路西法人 2024年6月19日 (三) 02:02 (UTC)回复
    本人早已指出，调查期间仲裁委员会认为确有必要时，可暂时取消当事人之管理权限，至于最终处份问题则完全是两回事；既然说“管理员做出应受非短期封禁或禁制的行为理应受与一般用户相同的处理”，那解除权限方针明确指出“当管理员封禁任何一位依从权限申请方针获得权限的用户时，请同时提报，让其他用户复核考虑是否为之除权”，而管理员就可以被仲裁委员会径行除权了？若真“理应受相同处理”，那此等失职行为，就虽自然成为得提出解任（“复核考虑是否为之除权”）之“理由”，但并不总是直接等于“结果”。又此种“复核”之对象一般而言是社群整体，不是仲裁委员会（部分例外既已言明于上述草案，此处不赘述）；社群有权就管理员解任案成立与否予以最后决定，此时又可参考解除权限方针提到的“蓄意犯规”、“草率行事”、“执于己见”、“没有悔意”等要件，构成对管理员与其他权限持有者一视同仁之量尺，达到所谓“理应受与一般用户相同的处理”。
    解任乃最终手段，请与社群事先商榷什么情况值得如此做，不要自己定义“本来”、“显然”、“特权”、“不是可以原谅的行为”，仿佛理所当然一般。尤其社群已明确倾向反对由仲裁委员会径行处份失职管理人员，是以若一定要置若干例外，依据比例原则及法律保留原则（当然本站政策不是法律，但基本观念类似），理当以明文列出，且或可能严格限缩处理。又即使如我个人意见上述如此，也没径行强求或压制谁去接受，祇是提出供社群参考，我想任何人的意见都一样；假使认为“应受非短期全站封禁或禁制的行为”可以由仲裁委员会径行除权，那就是首先要由社群确定是否同意此等条件，或初步予以修正（如不包含某些“禁制”情况、有权经社群额外同意排除某些意外情况个案之类），然后还要厘清所谓“非短期”具体指什么、又此种行为应可能包含什么情况（如上方提到“滥用傀儡”，具体是多严重之类）等细节，最后才得凝聚为真正可行且符合程序正义之共识（以上是随意举例）。不是提一些模棱两可的条件顺溜过去就行。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月19日 (三) 17:52 (UTC)回复
    考虑一些过往案例，本人目前认为所谓“有必要情况”祇有遭遇值得受不限期封禁之行为。受如此重大处份且未能申诉成功之管理员，亦往往会遭社群事后除权，甚至多数是紧急除权。本人认为，仲裁委员会在此种情况下裁决迳予除权，并不逾越社群过往实践缔造之共识及一般常识。若有其他认为可适用情况，还请社群具体提出。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月19日 (三) 18:20 (UTC)回复
    “因为这终究取决社群对管理员的信赖”不全然，这也视乎他本身造成的危害的严重性，这不是擅自代为“处刑”，而是避免社群擅自慷受害者之慨。这样说：就算你原谅了一个杀人犯，他还是一样要被判死刑或终身监禁，不能说因为你原谅了而直接认为他无罪。Sanmosa 蚌埠 2024年6月19日 (三) 05:55 (UTC)回复
    社群是本站最高“政权机关”及一切事务最终决定者，本人认为真有共识（大前提）的话要“慷受害者之慨”也行；反过来说，如果仲裁委员会经审酌决定“慷受害者之慨”，阁下又该如何应对？何况在本站，所谓“极刑”不过是禁止编辑，且除极少数社群不可抗力情况（如基金会行动、全域禁制等）外，没有真正不可逆的处份，此处完全不宜援用现实司法情况。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月19日 (三) 17:52 (UTC)回复
    真要用司法来比拟的话，仲裁委员会可以“限制迁徙”甚至“拘禁”，防止“嫌犯”继续迫害他人，也可以提出“证据”（此处指调查报告，并非报告本身采用的证据）给予“法官”（社群）参考；仲裁委员会在其他管辖内案件可能自己兼任“法官”，但就管理人员解任议题而言，最终判决“有期徒刑”（本站没有“死刑”）者则仍是社群，不是仲裁委员会（所以说为什么不应该用现实司法比较，因为太强行硬凑了）。社群已经彰显意志，不打算将仲裁委员会打造为非常之国民公会。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月19日 (三) 17:55 (UTC)回复
    我正是考虑到如此情况才会有上方“如果调查报告认为这不属于可以解任的情况，但社群形成了显然相反的共识时，无论调查报告是否出错，社群依旧可以在有相当共识的情况下发起解任投票”的提议，这已经足够救济仲裁委员会“慷受害者之慨”所造成的损害了。虽然我个人比较倾向于权限较大的仲裁委员会，但从我上方的留言可见，国民公会形态的仲裁委员会也不是我支持的东西。Sanmosa 蚌埠 2024年6月20日 (四) 14:25 (UTC)回复
    反过来说，岂不亦适用？可再商讨。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月22日 (六) 05:24 (UTC)回复
    这样说吧，我既不希望一个被架空的仲裁委员会，也不希望一个被架空的社群，我期望的是仲裁委员会与社群旗鼓相当、能相互制衡，所以如果我没有理解错你说的“反过来说”的意思的话，这正是我自己期望的效果。Sanmosa 蚌埠 2024年6月23日 (日) 14:52 (UTC)回复
    另外，我同意有关社群就与仲委会意见相左时，可重行循联署管道形成共识发起解任案的意见。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月18日 (二) 18:05 (UTC)回复
    (！)意见：同Eric Liu，此版本和上一个版本不同，缺少仲裁委员会拒绝后社群自行形成共识的流程，建议增加此流程。--桐生ここ★[讨论] 2024年6月22日 (六) 08:15 (UTC)回复
    直接沿用既有联署流程即可。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月23日 (日) 06:48 (UTC)回复
    (！)意见：个人路过，仅额外表达身为用户的意见，恕不参与后续和在此乱入。个人建议若有共识将类似仲裁的机制设立专属页面或区块，让有意愿的用户视案件试行参与，或若产生共识，视实际需求再看后续是否执行即可；在尚不具备特殊权限的情况下试行，若往后具备良好的实际效益和需求，以此另外举行相关选举也或无不可。然而我认为仲裁权的施行争议似乎仍有讨论空间，且难以比照现实生活的机制，光是“仲裁”本身具备的效力就极具争议，且定位难明（现实中的仲裁可能具备法律效果，但仍有法律管道作为当事人不服的救济机制；国际争端那种姑且不论），而如果只具备所谓“调查权”，再交付社群议论，其实与当前机制相去不远，直接交由社群议论或许更直接，了解议题或有兴趣的人自可参与，与是否具备权限亦无关；此外，若仲裁员本身遭到当事用户欺瞒拐骗又该如何？势必仍需另寻管道明查暗访、审慎查察等等，事实上这个过程和一般用户参与讨论相去不远。而一个连具备实际特殊权限的管理员也无法维持秩序的社群，特别选出负责厘清事情的用户，若再产生其他事实认定上的争论，又或者其他用户若有不服，救济制度何在？仲裁效益何在？又或是仲裁委员因仲裁无方、标准不一、效果不齐，是否又衍生其它争执呢？是否最后仍须交付基金会呢？而若绕回社群议决，一个不具实际决定性效果的权限是否可能绕一圈后又回归争执呢？而若具决定性效果，该具备何种权限，或许仍须回归实际需求，如果其实不太需要的话，也可能根本不需另行规划。这样看来，“仲裁”似乎有点像是“监察权”，但现实中的某些监察权亦已为人诟病颇多（笑）。以上并不代表不应规划此类机制或权限，而是此制度的施行就目前社群现况、投票及讨论结果来看，众人对于社群事务和机制中，强调“制衡”所带来的公平性和安全感，似乎仍远胜对于“决断或判定”所带来实际效益的信任和需求。既然如此，真正需要详加调查讨论的问题，终须回归社群决议，而议事的过程个人认为这仍属社群自制力和是否具共同目标的根本问题；至于管理员用权的“认事用法”问题，我认为则回归管理员所具备权限性质的长期命题，多数争议亦往往来自于此，而当前诸多网络平台似乎也是如此（警察＋判官，但好像也都是这样）。对于个案，个人倾向让具管理经验的行政员直接判断特定管理员是否于特定案例滥权或用权过当，以此提供实务意见，社群再行议论，这和诉诸社群民意类似，但可能可以尝试结合试行机制看看。目前是否需直接特别设立选举产生的特殊权限，个人倾向斟酌。--Kriz Ju（留言） 2024年7月1日 (一) 14:31 (UTC)回复
    支持Manchiu的意见，解任与否的决定权应在社群，仲裁委员会在解任案中不应拥有最终决定权，其作用更应该是处理私密信息和提供对证据的调查报告以供社群作出决定。当然我不反对仲裁委员会可以执行紧急除权等极为特殊的事态。另“仲裁委员会调查期间冻结案件”应明确规定冻结时间。--🎋竹生🎍 2024年7月7日 (日) 02:28 (UTC)回复

临时暂停特权机制

编辑

I'm going to make a proposal about temporarily desysopping, when a sysop, oversight or checkuser are being investigated, their priviledge may need to be temporarily removed by Arbcom to prevent further disruption if necessary. And shall not obtained again unless the investigation is over. Especially, for VRT and the ones who have signed NDA, Wikimedia Foundation need to be noticed if neccessary to remove such priviledge. I'm a little bit tired but good luck, god bless you.---Lemonaka 2024年6月14日 (五) 13:08 (UTC)回复

我准备提出一个关于暂时取消系统管理员的提案，当系统管理员、监督员或检查用户正在接受调查时，Arbcom可能需要暂时取消他们的权限，以防止在必要时造成进一步的干扰。除非调查结束，否则不得再次获得。特别是对于 VRT 和签署了保密协议的人，维基媒体基金会需要注意是否有必要取消这种权限。我有点累了，但祝你好运，上帝保佑你。---Lemonaka 2024年6月14日 (五) 13:08 (UTC)回复

@Ericliu1912 @LuciferianThomas -Lemonaka 2024年6月14日 (五) 13:11 (UTC)回复
仲裁委员会大概可以视情况决定是否技术上暂时取缔管理员行使权限。不过本地相较于英文维基百科，尚没有直接取消管理员系统操作权之权力，本人认为这代表两地社群习惯差异，故制度移植时亦应有本地化措施以为反映（例如缩减可取缔权限之案件种类等）。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月14日 (五) 13:15 (UTC)回复
我觉得可以提出紧急冻结机制，类似紧急除权，比方说监督员、界面管理员等重要权限，正在调查期间社群或行政员认为必须先除权以保证安全，则先除权，等待调查结果再恢复或维持除权。--桐生ここ★[讨论] 2024年6月14日 (五) 13:21 (UTC)回复
重点在于“无罪推定”（虽然应该少援用司法概念）。除上述情况外，本人认为唯有涉及管理权限行使可能损及当事人权利，或妨碍案件之进行，或有正当合理之依据认为案件进行中不适宜持有权限者，方得暂时除权。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月14日 (五) 13:40 (UTC)回复
这有个问题是谁来判定会比较好，Arbcom判定社群会有人不认同，社群自己来讨论要不要暂时除权又会因为争执而不了了之，一个很尴尬的情况。--~~Sid~~ 2024年6月17日 (一) 09:08 (UTC)回复
Sid说的有道理。仲裁委员会只是是少数人的决定，社群大多数人的共识才具有公信力。--桐生ここ★[讨论] 2024年6月22日 (六) 08:17 (UTC)回复
这种观点我真的不认同。仲裁委员会是社群选出来的，细节是由社群敲定的，最终的提案也是要由社群通过的。在这样的程序下，仲裁委员会的决定必须具有公信力。如果说决定不具有公信力那么要仲裁委员会干什么？
我选择甲的原因也同理。如果委员会需要调查再由社群讨论，那搞选举、审议这些程序完全没用。完全可以找几个看起来社群信得过的人，组成一个“非官方”的委员会，也可以调查。
再往普通解决行为争议来看，即使无法除权管理员，委员会一定需要有封禁，设置编辑禁制的能力。设置委员会就是为了一个“最终解决方案”。如果例如ANM上面的案子十分棘手，以至于没有管理员愿意去处理，那么就去找委员会。委员会基于社群方针来判断事务是否使用管理工具来处理，而不创建新的方针。如果说委员会在处理普通用户争议的时候也要“推荐”管理员如何处理，实则无权的话，那这个委员会不要也罢。--0xDeadbeef (留言) 2024年6月25日 (二) 11:54 (UTC)回复
说到底我怀疑社群能否选出这么一个委员会。--桐生ここ★[讨论] 2024年6月25日 (二) 13:33 (UTC)回复
我保持乐观，但我的想法是，与其将委员会的权力一砍再砍，就为了社群能够选出一批人，结果选出来也不能改变社群生态，不如保留委员会权力，社群在知情委员会权力的情况下选，选出则能对社群环境有一定的影响力，选不出就当失败。--0xDeadbeef (留言) 2024年6月25日 (二) 17:39 (UTC)回复
@0xDeadbeef What about A/B group? They can scrutinize each other. -Lemonaka 2024年6月26日 (三) 03:46 (UTC)回复
Not sure how well that will work in practice, but maybe worth a try if people want to.--0xDeadbeef (留言) 2024年6月26日 (三) 07:31 (UTC)回复
无论是ArbCom还是社群讨论处理，我认为可以先讨论当Arbcom决议有人不认同时社群要怎么解决，当社群讨论发生争执导致讨论不了了之时怎么解决，这是可以预想到的情况。
我很不希望到时候社群不接受仲裁委员会的决议，又嚷嚷着要罢免仲裁委员会，那是非常难看的情况。--~~Sid~~ 2024年6月30日 (日) 09:51 (UTC)回复
问题是这个“选的门槛”、“敲定的细节”，过程及结果是否合理？不少人有疑虑。既然并非如英文那边当年由威尔士“君权神授”，本人认为本地仲裁委员会的权威是要经由实际裁决确立，不是伊始就赋予莫大权限。尤其涉及直接处理管理权限者，应不必属于首届就奉送委员会的工具。目前本站与监管员等全域社群合作无间，本人虽一贯主张社群拿回应有之自治权，但现阶段也未见到由仲裁委员会接掌彼等紧急处置权限的必要。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月26日 (三) 05:30 (UTC)回复
那你觉得仲裁委员会是来干什么的呢？早就有人使用“没必要”这个理由来否认各种事情，我对此的回应是，确实，WP:CHOICE也说了，编辑维基百科也没必要。你当维基百科管理员有必要吗？那为什么还有人编辑百科，为什么你还要当维基百科管理员呢？
我知道我在委员会是否应该有权力去除管理员这个讨论中持少数观点，所以我也不想继续陈述我的观点。你说循序渐进我无所谓，要是能够通过实际判决历史来让社群更信任委员会是好事，但是我其实想强调的是刚开始ArbCom也至少应当拥有设立禁制及设高风险主题的权力。如果选出来的委员会没有办法实现决议出来的结果那就非常无能。就和WP:NAC不能关闭为删除一样。--0xDeadbeef (留言) 2024年6月26日 (三) 07:07 (UTC)回复
据我所知，仲裁委员会职能到现在都没有确定。具体而言，目前高风险主题在客栈提案模式运作良好（除了法轮功本来争议较多），对于本站来说高风险主题本来就是个低层级议题，确实不用仲委会插手。另外，我不确定你是想要仲委会有权下达什么形式的禁制，但大部分情况应该都没问题，因为社群至少有共识赋予仲委会某种裁决封禁操作之权，这自然也就包含禁制。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月26日 (三) 08:19 (UTC)回复
那就好。--0xDeadbeef (留言) 2024年6月26日 (三) 12:06 (UTC)回复
我是认为高风险主题作为编辑限制的一种，可以作为仲委会的争议解决手段之一（跟禁制权相似），但绝对不会覆盖社群本身订立高风险主题的权力。目前CTOP下，社群经共识实施的编辑限制只能由社群经共识解除，而不能由任何管理员自行解除；仲委会的则可有相似机制，仲委会的高风险主题限制（不论是设置新的高风险主题或是编辑限制）都只能由仲委会或极广泛共识（30人80%支持？）解除，仲委会也可基于方针及其原则解除社群共识订立的编辑限制（不过只能是回应申诉）。--路西法人 2024年6月27日 (四) 03:20 (UTC)回复
本人亦认为仲委会有权在必要时自行提出高风险主题，为其执行手段之一。当然，社群对此当有复核权，其门槛应与经一般社群管道（客栈）制定者相同。相对而言，仲委会祇能被动决定解除已无需求之高风险主题，而不应主动介入（这应该与阁下观点相同）。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月27日 (四) 04:16 (UTC)回复
@桐生ここ What? Arbcom are elected by the whole community, unless the community consensus is hijacked by a small group of users, the arb will be reviewed as the representative of the whole community. Why will they become the minor? -Lemonaka 2024年6月26日 (三) 03:48 (UTC)回复
问题是争议发生当下，当事人们是否认同委员会是他们选举出来的吗？而且事实上仲裁委员会的决定是有限数量的委员们达成的共识，而社群可以组成共识的人数是无限的。--桐生ここ★[讨论] 2024年6月27日 (四) 02:38 (UTC)回复
不认同也得认同。就像如果我进行扰乱维基百科，游戏维基百科的事情的话，有管理员要封禁我，我是不是说“我不认同你是被社群选举出来的管理员，你的决议不是社群共识，请在社群中形成共识再封禁我”就可以有免死金牌了？--0xDeadbeef (留言) 2024年6月27日 (四) 02:49 (UTC)回复
管理员是执行共识，仲裁委员会是没有共识的情况下制造一个“共识”，还是有点不一样。--桐生ここ★[讨论] 2024年7月1日 (一) 19:52 (UTC)回复
在什么情况下仲裁委员会是在没有共识的情况下制造一个共识，而不是执行共识？--0xDeadbeef (留言) 2024年7月2日 (二) 03:25 (UTC)回复
其实若仲裁委员会按方针与指引精神裁定，那本质上与管理员行使自由裁量权意涵相同，都是执行社群共识。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月2日 (二) 04:21 (UTC)回复
我倒觉得，与其说ARBCOM是没有共识制造共识，倒不如说ARBCOM是审批有争议的共识及强化共识。--ときさき くるみ 2024年7月15日 (一) 10:04 (UTC)回复
有几种民主解方：一种是社群以足够高门槛另行达成有效共识，推翻仲裁委员会决议；另一（两）种是经罢免或次届选举移除若干社群认为不适任之委员。社群可以决定是否两（三）种解方并行，或祇允许其中几种。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月1日 (一) 19:47 (UTC)回复
初期仲裁委员会或本地行政员都还没有权限可以自行取消管理员权限，这个或许要到未来届数的仲委会选举前再解决。目前状态下，仅有“可能需要紧急除权”、“（发布报告后）已经确认符合解任发起条件，等候社群投票重新确认管理员权限”两个情况是适合直接冻结权限。
虽然目前尚无技术手段直接冻结管理员权限，仲委会仍可通过审议施行禁制权，临时禁制当事人使用任何管理人员权限，违者亦可直接视作严重违规而符合除权条件即可。
不过如果是“冻结权限”，那么就不是“解任投票”而是“重新确认投票”，重新确认投票的通过标准（此处指支持留任比率）或许要提高；反过来解任投票的通过标准（此处指支持解任比率）也需因应略微提高（例如55%）。--路西法人 2024年6月15日 (六) 00:56 (UTC)回复
How can you “冻结”(maybe temporarily stop) VRT priviledge without removing them? What about Oversight? -Lemonaka 2024年6月15日 (六) 02:22 (UTC)回复
基本上都是需要通过暂时除权处理。使用行政手段如禁制也是可以等同冻结权限，违者即直接除权即可。--路西法人 2024年6月15日 (六) 03:15 (UTC)回复

机要原则

编辑

Taking the current privilege of ARBCOM into consideration, the member of ARBCOM should have signed or need to sign NDA before appointment, the result is that nearly all member from mainland China are excluded and they may not trust this group at all. However, Wikipedia is working based on the consensus, having a whole subgroup excepted from those may make it hard to function.

以ARBCOM目前享有的特权来看，ARBCOM的成员在任职前应该签署或者需要签署保密协议，结果就是几乎所有来自中国大陆的成员都被排除在外，他​​们可能根本不信任这个团体。然而，维基百科是基于共识运作的，如果将整个子群体排除在共识之外，可能会使其难以正常运作。---Lemonaka 2024年7月9日 (二) 01:34 (UTC)回复

这也是没办法的事，2021年时WMF好像已经有不承认中国大陆人士签署的保密协议的做法，这不是中文维基百科的裁量范围。Sanmosa 蚌埠 2024年7月9日 (二) 05:18 (UTC)回复
否。我记得过往讨论中是安排照样容许无法签署保密协议的用户参选，而在必须有前保密协议才能接触的证据的情况下设subcommittee处理有关证据或案件。--路西法人 2024年7月9日 (二) 06:42 (UTC)回复
我的理解是他是在表述他认为所有ArbCom成员都应该需要签署保密协议的个人意见，而不是在表述过往讨论的结论。Sanmosa 蚌埠 2024年7月9日 (二) 22:47 (UTC)回复
我没有说他正在表述过往讨论。你无法好好阅读、理解我的留言，并屡次超译我发言的行为已经严重造成我的困扰，请你停止。--路西法人 2024年7月10日 (三) 01:52 (UTC)回复
我好像也没表达出你说的这个意思？真正在超译的人是你吧？Sanmosa 蚌埠 2024年7月13日 (六) 01:23 (UTC)回复
@LuciferianThomas@SanmosaPlease focus on the topic, ARBCOM members are responsible for on and off-wiki invesitgation, including evidence regarding privacy, how can users send these information to the Arbcom members who never sign NDA?
请关注主题，ARBCOM 成员负责维基内外调查，包括有关隐私的证据，用户如何将这些信息发送给从未签署保密协议的 Arbcom 成员？ -Lemonaka 2024年7月15日 (一) 01:30 (UTC)回复
subcommittee，小组委员会，即仅有部分成员参与的调查。简而言之：不涉及隐私证据的案件可由所有仲裁员参与，涉及隐私证据的案件仅可由已签署NDA的仲裁员参与（未签署NDA的仲裁员recuse）。--路西法人 2024年7月15日 (一) 01:44 (UTC)回复
[来源请求]? -Lemonaka 2024年7月11日 (四) 03:17 (UTC)回复
Wikipedia_talk:仲裁委员会#保密协议及处理涉及隐私证据案件之职务、#公示RFC结果及仲裁方针草案。--路西法人 2024年7月11日 (四) 03:38 (UTC)回复
可尽量细分仲委会行使职权，最敏感部分才考虑保密协议为必要条件。具体之执行，应以个案为基准，确定证据是否涉及隐私，再行规划。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月9日 (二) 16:16 (UTC)回复

新用户通过撰写新条目的方式“完成学科作业”的处理讨论

编辑
最新留言：在17小时前发布43条留言18人参与讨论

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:教育项目、Wikipedia talk:给老师们的提示。

近日巡查当中发现疑似存在新用户通过撰写新条目的方式“完成学科作业”，目前主要涉及两位用户U:JINJINYAN和U:ZixuanHE以及其创建的四篇条目，见人权史（Draft:人权史）、中朝关系史（Draft:中朝关系史）、Draft:修理权、Draft:性别薪酬差距（目前的处理为：已全部转移至草稿空间，部分被绕过草稿空间重新发布的条目已提报存废讨论）。四篇条目均为机翻或者潦草翻译，且未进行维基化。据ZixuanHE所述，这些条目的创建疑似为“学科作业”，且必须发布才有可能拿到“节课的成绩”（见UT:ZixuanHE#阁下所创建条目已被移动至草稿）。

鉴于此类行为为显然带有倾向性或非百科编辑性动机的条目创建行为（可能不符合但类似于维基百科:有偿编辑方针），故提出此话题以寻求如何处理该类问题。--Sinet（讨论） 2024年6月14日 (五) 08:43 (UTC)回复

在下认为，无论以何种理由对中维条目进行编辑，都必须依照维基百科的方针和标准进行。完成学科作业并不是提交质量不佳的条目的理由。Sinet君将条目暂移至草稿空间以便于编者继续编辑的做法得体适当。--SheltonMartin留言|签名 2024年6月14日 (五) 08:49 (UTC)回复
看两人的对话确实像是要完成作业。但我记得本来就会有一些项目是让学生练习写条目的？--Rice King 信箱 · 留名．边缘人 2024年6月14日 (五) 09:30 (UTC)回复
enwp那边有类似的教学/课堂行为，参考那边的处理方式？--Leiem（留言·签名·维基调查） 2024年6月14日 (五) 09:31 (UTC)回复
en:Wikipedia:Wiki_Ed/Massachusetts_Institute_of_Technology/Organometallics_(Spring_2024) ← 找到了这个。--Leiem（留言·签名·维基调查） 2024年6月15日 (六) 08:34 (UTC)回复
中文维基有Wikipedia:给老师们的提示，另外，台湾维基人在推的教育项目（Wikipedia:台湾教育项目），是让作业放在教育项目以下的空间（如Wikipedia:台湾教育项目/台大物理系服务学习二_(107-1)/物理学家），该项目有维基人在该空间进行评分，符合维基百科标准的再移动到正式条目空间。以我的印象，中文维基百科的人力不太够帮助老师修正（或评改）同学的作业， 而新手若没有人协助的话， 也不太可能在短期（例如一周）产出符合维基百科规定， 不会被提删的条目。--Wolfch (留言) 2024年6月14日 (五) 09:48 (UTC)回复
此为韩国汉阳大学的教育项目，而教育项目显非“有偿编辑”。如果条目存在机械翻译等问题，移至草稿即可。另外，本站或许应创建专门讨论教育项目的布告板，如英文维基的 en:Wikipedia:Education noticeboard？谢谢。cc @Hanyangprofessor2：--SCP-0000（留言） 2024年6月14日 (五) 13:20 (UTC)回复
我好像听过这个事情，这位教授好像在我的讨论页面中提到过这个项目。--MilkyDefer 2024年6月14日 (五) 15:35 (UTC)回复
Yes, they are my students. They are Chinese nationals and supposedly fluent in Chinese (I do not speak Chinese, apologies). They are required to proofread their works so that it reads well in Chinese (instructions are at en:User:Piotrus/Ideas for students; I explicitly ask them to read 维基百科:翻译指引). They are also encouraged to ask for feedback at Chinese Discord or at 维基百科:同行评审. I am afraid some some students may not follow the instructions (yes, I am sure you are all shocked), for which I can only apologize, and some try to finish the Wikipedia-writing assignment (which is supposed to take ~3 months) in less time (say, a week or two before the class is supposed to be finished...). On the other hand, I'll also note that we should not assume that all poor translation is the result on reliance on machine translation - some people (students) may not know how to write properly, and the errors may be of their own making, rather than the fault of the translation software (just a thought). To end, I'll repeat the idea I mentioned few months ago here (at Chinese Wikipedia) - to create a Chinese equivalent of the en:Wikipedia:Education noticeboard mentioned above, as well as a dedicated space for students to list their works and ask for a review (so that their assignments do not flood the 维基百科:同行评审). PS. If anyone feels like this, one of my students got blocked again and their case could use a review, once they apply for an unblock, as I told them to (of course, I expect them to read and understand the reasons for their block...). User:Liangyiqiao2004
是的，他们是我的学生。他们是中国公民，据说中文很流利（我不会说中文，抱歉）。他们需要校对自己的作品，以便其中文可读性良好（学生的说明位于：en:User:Piotrus/Ideas；我明确要求他们阅读维基百科：翻译指引）。我们也鼓励他们在 Chinese Discord 或维基百科：同行评审中寻求回馈。我担心有些学生可能不遵循指示（是的，我相信你们都感到震惊），对此我只能表示歉意，还有一些学生尝试完成维基百科写作作业（预计需要大约 3 个月的时间）在更短的时间内（例如，在课程结束前一两周…）。另一方面，我还要指出，我们不应该假设所有糟糕的翻译都是依赖机器翻译的结果 - 有些人（学生）可能不知道如何正确书写，并且错误可能是他们自己造成的，而不是翻译软件的错（只是一个想法）。最后，我将重复几个月前在这里（中文维基百科）提到的想法——创建一个相当于上面提到的en:Wikipedia:Education 布告栏的中文版本，以及一个专门的空间，供学生列出他们的作品和要求审查（这样他们的作业就不会淹没维基百科：同行评审）。附言。如果有人有这样的感觉，我的一个学生再次被屏蔽，一旦他们申请解锁，他们的案件就可以进行审查，正如我告诉他们的那样（当然，我希望他们阅读并理解屏蔽的原因。 ..) 。用户：Liangyiqiao2004--Hanyangprofessor2（留言） 2024年6月17日 (一) 10:00 (UTC)回复
@Hanyangprofessor2：I'm afraid that the block would stay on for a while for Liangyiqiao until he/she/they answers the question from local admin @Tigerzeng： on the user talk page. I understand that there might be deadlines for students to reach, but if Liangyiqiao is not able to answer the question that Tigerzeng presents, it would be hard to convince the admins (I supposed that is at least Tigerzeng and myself) that he/she/they understands the reason for the block.
恐怕Liangyiqiao的封禁将会持续一段时间，直到他在用户讨论页上回答Tigerzeng的问题。我理解学生很有可能有缴交作品的截止日期需要达成，但如果Liangyiqiao无法回答Tigerzeng提出的问题，这将会很难让管理员（我想至少是Tigerzeng和我自己）相信他自己已经了解了封禁的原因。
注：原文是以英文写出后再翻译，若有不同之处请以英文为准。-- （☎）dt 2024年6月21日 (五) 02:00 (UTC)回复
@ATannedBurger Of course, I understand. It is the student's responsibility to monitor messages and answer them in a timely manner. 当然，我明白。查看信息并及时回复是学生的责任。--Hanyangprofessor2（留言） 2024年6月22日 (六) 03:57 (UTC)回复
又有一个。--Rice King 信箱 · 留名．边缘人 2024年6月15日 (六) 07:26 (UTC)回复
英维也有这种，主框架是Wikipedia:教育项目，具体课程例子比如 https://en.wiki.x.io/wiki/Wikipedia:Wiki_Ed/University_of_Southern_California_Viterbi_School_of_Engineering/WRIT_340_for_Engineers_-_Spring_2024_(Spring_2024) ，这种页面注明了哪个大学，哪个课程，哪个学期，哪个讲师，并有维基编辑审核。但中文维基只有这个“教育项目”的主页面，实际页面内没有规范。--桃花影落飞神剑（留言） 2024年6月15日 (六) 15:02 (UTC)回复
社群可以趁此机会完善相关的页面与规定，就我的观察教育项目在中维的需求不算低，但也没有到频繁。--~~Sid~~ 2024年6月17日 (一) 09:29 (UTC)回复
(＋)支持，可以对en:Wikipedia:Education进行引入或者设计其他暂行方针以标准化相关内容的处理。--Sinet（讨论） 2024年6月17日 (一) 12:52 (UTC)回复
(＋)支持，同上--HYHJKJYUJYTTY（留言） 2024年6月21日 (五) 07:40 (UTC)回复
(＋)支持--Rice King 信箱 · 留名．边缘人 2024年6月22日 (六) 04:27 (UTC)回复
@SCP-2000 @ATannedBurger @Flyinet Hello. Can you tell me why majority of my students contribution was removed from those two articles? 性别薪酬差距 and 修理权 . I am afraid I cannot understand the problem from edit summar or article's history, they look mostly fine to me? If there is a problem, I can tell the student to fix it in the near future, but I need to know what the problem is first. (Content was removed by @日期20220626)
你好。你能告诉我为什么我学生的大部分贡献被从这两篇文章中删除吗？ 性别薪酬差距和修理权 。恐怕我无法从编辑摘要或文章历史中了解问题所在，它们对我来说大部分都很好？如果有问题，我可以告诉学生在不久的将来修复它，但我需要先知道问题是什么。（内容被@日期20220626删除）--Hanyangprofessor2（留言） 2024年6月22日 (六) 08:28 (UTC)回复
There are comments about these two articles on User talk:JINJINYAN from user:ZixuanHE "However, the structure of some of your sentences is relatively complex, which affects the reading fluency".--Wolfch (留言) 2024年6月22日 (六) 08:52 (UTC)回复
@Hanyangprofessor2: Hello, if I understand correctly, 日期20220626 shortened articles and removed content with poor translation quality (i.e. translated by machine translation) and lack of Wikify, so that they can be published in the main namespace.
Students can write in the draft namespace and submit it for AFC review (by adding code {{subst:submit}} on the top of the page). Thanks.--SCP-0000（留言） 2024年6月22日 (六) 09:08 (UTC)回复
Hi, I am the patroller who reviewed the articles created by your two students. Overall, the reasons for the articles being disqualified can be summarized into three categories:
  1. The most severe and obvious reason is the massive presence of machine translation appearance throughout the articles. There are numerous noticeable signs of machine translation, including but not limited to: evident translation tone, incorrect Chinese proper nouns, and English-style sentence structures. These issues are easily detectable to native Chinese readers, leading to the articles being directly judged as unqualified.
  2. The articles lack proper "Wikification." They consist mainly of plain text and line breaks, without using any syntax to design headings or organize the article structure, resulting in poor readability. Additionally, some terminologies lack internal links or have incorrect links. These are obvious mistakes, making the articles clearly fail to meet Wikipedia's inclusion standards.
  3. The articles are primarily composed of assertive sentences without any connectors or transitional paragraphs. This results in a lack of coherence and logical flow, making the articles very difficult to read.
--Sinet（讨论） 2024年6月22日 (六) 09:27 (UTC)回复
@Flyinet @SCP-2000 @Wolfch Thank you for the explanation. I will ask the student @JINJINYAN to address those problems. 谢谢你的解释。我会请同学@JINJINYAN 解决这些问题。--Hanyangprofessor2（留言） 2024年6月23日 (日) 03:32 (UTC)回复

设立教育布告板

编辑

根据上方的讨论共识，已设立教育布告板的草案，欢迎各位前来讨论。--人间百态,独尊变态(讨论) 2024年6月22日 (六) 11:06 (UTC)回复

Ping一下相关用户@Flyinet、SheltonMartin、RiceKing、Leiem、SCP-2000、MilkyDefer、Hanyangprofessor2、ATannedBurger、桃花影落飞神剑、ASid、HYHJKJYUJYTTY：--人间百态,独尊变态(讨论) 2024年6月22日 (六) 11:12 (UTC)回复

你设计还不错--HYHJKJYUJYTTY（留言） 2024年6月22日 (六) 11:17 (UTC)回复
据我所知，目前有教育项目，都是在互助客栈其他区通报。至于是否需要独立的教育项目布告板，则尚待商榷。但无论具体地点如何，总是应鼓励教育项目主持人通报，俾利于社群复核。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月23日 (日) 02:20 (UTC)回复
“教育”布告板此称呼较含糊，或许改为“教育项目”布告板？谢谢。--SCP-0000（留言） 2024年6月23日 (日) 15:52 (UTC)回复
 完成--人间百态,独尊变态(讨论) 2024年6月24日 (一) 13:29 (UTC)回复
教育项目布告板看起来不错。--冥王欧西里斯（留言） 2024年6月27日 (四) 01:33 (UTC)回复
我觉得这个设计的不错，支持。--桐生ここ★[讨论] 2024年6月25日 (二) 16:21 (UTC)回复
在看草案之前我以为是用来通报/报备教学计划的布告板，但起来好像不是这个用途。
  • “参与教育项目的学生的条目作业已产生或可能产生的问题”是不是在条目讨论页或用户讨论页讨论相关问题会比较直接？除此之外还有互助客栈的条目讨论版。
  • “教育项目运行中产生的问题”需要为这些问题设立布告板吗？相关问题的讨论频率似乎不多，是否可以继续在互助客栈讨论？
  • “关于维基教育基金会的讨论”个人对这个基金会了解不多，其曾经在中文维基百科举办过什么活动吗？
--Steven Sun（留言） 2024年7月2日 (二) 02:11 (UTC)回复
@人间百态：感觉通报教育项目也可以纳入范围。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月2日 (二) 04:24 (UTC)回复
不反对。--冥王欧西里斯（留言） 2024年7月2日 (二) 04:44 (UTC)回复
建议加入一个列表备案当前进行中的教育项目，并要求教育项目的主管者填报，备案信息可包括：
  • 项目名称（相关机构名称）
  • 教育项目编写的条目性质（翻译或原创）
  • 教育项目的主管者用户ID以及其他监管者ID
  • 教育项目的参与者ID
  • 教育项目内正在编写的条目列表
方便巡查员和社群了解正在进行的项目信息。--Sinet（讨论） 2024年7月2日 (二) 15:26 (UTC)回复
@Flyinet，已完成。--人间百态,独尊变态(讨论) 2024年7月3日 (三) 14:20 (UTC)回复
已将通报教育项目纳入范围，顺便回复一下Steven Sun君的疑问。我对教育项目布告板设计的定位和英维是大致相同的，即集中处理维基教育项目的老师和学生在编写维基百科时可能产生的问题。条目讨论页、用户讨论页、互助客栈，这些地方确实比布告板直接不少，但这些页面比起布告板来或曝光度不足，或查阅困难。布告板设立后能够让社群更加有效的处理相关问题，并提供存档供用户查阅如何处理相关话题。--人间百态,独尊变态(讨论) 2024年7月2日 (二) 13:57 (UTC)回复
又想了一下，教育项目运行中产生的问题的讨论频率确实不是很大，就算出现大部分也是有关学生的作业质量问题。故此已将学生的作业质量问题一项并入教育项目运行中产生的问题之中。--人间百态,独尊变态(讨论) 2024年7月2日 (二) 14:10 (UTC)回复
  • 我想请问这个布告栏未来如何运作？目前看不出来有任何方法可以使想发起作业的老师能提前知道要来通报，而且如果要用维基界面写通报，大概使用率会很低；社群依然会一天到晚先被作业洗，然后才通知老师去登记，完全没有发挥预警效果。如果是合作社群要去登记……目前大宗会有合作案的就台湾社群，但我们已经有教育项目页面了。--Reke（留言） 2024年7月6日 (六) 15:02 (UTC)回复
    interesting的问题。不知道Reke君有没有关注过近来英维的教育布告板的讨论记录，在近几年中也几乎没有人用该布告板来提报项目。一来英维老师通常会使用Wiki ED进行课程，二来在英维老师也是不太管注教育布告板的。实际上这个布告板本来就不是为了“预警效果”而设计的，其目的正如上方的回复所说为了让社群“集中处理维基教育项目的老师和学生在编写维基百科时可能产生的问题”。布告板的确无法改变社群始终慢一步的事实，但它能在事情发生后让社群更加直接的处理相关问题并通知有关用户。--人间百态,独尊变态(讨论) 2024年7月7日 (日) 03:30 (UTC)回复
    感谢，我是看上方讨论都要把通报列入当中，而且目前板面说明中也容许提报教育项目，所以才这样问的。
    如果单就集中处理问题来讲，我建议不如在互助客栈开设一个“/教育项目”的分页面？这样子看互助客栈的其他版面时，也就可以顺便去关切一下。--Reke（留言） 2024年7月9日 (二) 04:14 (UTC)回复
    我个人是倾向不要再开客栈的子页面啦，况且看客栈的特定子页面的时候也未必会去看其他子页面就是了。--冥王欧西里斯（留言） 2024年7月9日 (二) 05:20 (UTC)回复
    同意，挺不错的设计。--SheltonMartin留言|签名 2024年7月11日 (四) 06:38 (UTC)回复

  公示7日，2024年7月26日 (五) 13:51 (UTC) 结束：最后一条留言距今已过7日且所有意见已解决，进入公示期。--人间百态,独尊变态(讨论) 2024年7月19日 (五) 13:51 (UTC)回复

讨论页话题自动索引

编辑
最新留言：在2天前发布10条留言5人参与讨论

为配合WP:CON/TRIAL鼓励用户多善用条目讨论页，我尝试重制了类似过往Shizhao君制作的Talkindexbot（WP:TALKINDEX），自动索引各讨论页的近期话题。目前索引暂时置于本人用户空间（User:LuciferianThomas/讨论页索引），未来将正式申请机器人任务更新WP:TALKINDEX。若各位对索引测试有任何意见或建议，欢迎在此提出。--路西法人 2024年7月6日 (六) 12:51 (UTC)回复

支持这个initiative（虽说这在WP:CON/TRIAL的提议出现前就该出现了）。Sanmosa 蚌埠 2024年7月6日 (六) 13:53 (UTC)回复
挺好的，不过我也发现了点问题，但恐怕并不容易修复：
  1. 有些讨论已经结束（比如，编辑请求解决了），却仍会出现在此索引上，导致其十分冗长
  2. 有些讨论发起时间比较早，或讨论较长时间都没有人回应，就不会出现在此索引上；这可能并不利于问题的解决/共识的形成
--古怪的Wang31（讨论 | 贡献） 2024年7月7日 (日) 13:09 (UTC)回复
聊胜于无，有问题可以之后慢慢改善。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月7日 (日) 15:35 (UTC)回复
  1. 现在仍然在初步测试阶段，未来将参考Cewbot，将已经结束（已有Archive框模板）的讨论以另一种方式标记；其余标签如已解决之编辑请求、移动请求等亦可纳入考量。此部分还请社群协助列举。
  2. 目前机器人设计为每次都搜索最近14天的RC来弄这个列表，未来或许会以暂存方式优化；但起始搜索RC也最多只能到30天，而14天的讨论串数量已贴近400大关，可以想像起始数据需要索引蛮久的（以防轰炸数据库）。不是做不了，但最多也只能做30天，但也还是会多串到用户难以索引不再有效的地步。另一个方法是恢复{{indiscussion}}模板以防拖延时间过长讨论不被索引，这又是另一个需要社群去讨论的议题。
--路西法人 2024年7月7日 (日) 15:51 (UTC)回复
其实很多讨论就没有结束，或即使结束了也未必有任何标记来表示已结束。我认为话题索引只索引最多30天内有进行讨论的就好了，30天都没人参与的讨论那就是暂时没人在意或没能力参与，或者讨论页的留言就只是对条目内容的一个注记，没有讨论必要。讨论页话题自动索引最大的意义是让人能够了解和检索近期发生在讨论页的所有讨论，以期达到能够有更多人关注参与讨论的目的--百無一用是書生 (☎) 2024年7月8日 (一) 02:45 (UTC)回复
目前确实其实是没什么大问题的，我提的只是算是一点细枝末节的问题，得不出结论也无伤大雅。
  1. 讨论结束的，通过一些模板标记可以排除；当然，这对机器人在技术上的设计要求就会比较高。要是总体上没有特别多活跃讨论，直接忽略其实也问题不大
  2. 没解决但没人回复的讨论，确实是个比较矛盾的问题。无限索引就的讨论无论从技术上还是价值上肯定都是不太现实的，还是要考虑是否需要一种“标记”。一方面，就让这些讨论不了了之，感觉也不太好，尤其一些争议要是总是不解决，可能容易产生积患；另一方面，如果真的把所有“未结束”的讨论都列出来，却没人想去讨论，那仍然会让索引变得越来越长，失去意义。（突然想到，这个问题其实也可以类比存废讨论的积压讨论的存在，关键在于讨论的问题到底重不重要）
    我也给个我的建议，可以考虑先恢复{{indiscussion}}（我不清楚模板具体内容，总之是恢复或创建一种标识“此处有讨论正在进行”的模板），试用一段时间，要是积压的讨论越来越多，就还是用按日期索引的方案。
--古怪的Wang31（讨论 | 贡献） 2024年7月9日 (二) 14:37 (UTC)回复
当初的删除理由是“在讨论页开新段落自然是寻求讨论，无必要专门用一模板彰显”。我觉得可以改成默认索引对象包含两者，一种像现在这样一定时间内发起讨论，另一种就是特别标示有此模板的话题（无论发起多久）。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月17日 (三) 08:02 (UTC)回复
正是我上方留言所说的做法。--路西法人 2024年7月17日 (三) 08:41 (UTC)回复
已更新至WP:TALKINDEX。--路西法人 2024年7月17日 (三) 03:12 (UTC)回复

私自发布（怀疑自我原创）英国官员译名

编辑
最新留言：在9天前发布11条留言6人参与讨论
参见：Talk:施纪贤 § Victoria Starmer之译名

最近适逢英国政府换阁，一系列官员的会有港式译名，但需要等英国领事馆发布。但我看到一些用户，似乎急不及待的将自己相信的译名发布出来。甚至我见到一些ip用户，如14.198.208.124，甚至发布英国首相配偶、和子女的译名。据了解，使馆没有发布这些人的译名，或者媒体也未必会“创造”这些译名，明显是该用户的私人原创。

我已经很久没有在此活动，但这些行动似乎已经违反不能发布原创内容的规则，希望有关管理员能适当处置此事。--JéRRy ~ 雨雨 （留言） 2024年7月7日 (日) 07:08 (UTC)回复

@Yuyu：若此类编辑没有可靠来源佐证，均可迳予回退。也请多注意违规用户，并协助通知提报。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月7日 (日) 12:05 (UTC)回复
我最多已经回退多一次，但上面的ip依然活跃发布其幻想，你们看看要不要处置一下？--JéRRy ~ 雨雨 （留言） 2024年7月7日 (日) 13:37 (UTC)回复
@Yuyu、Ericliu1912：还有这位@Jimmy HCH：在阿克莎塔·穆尔蒂的编辑（Special:Diff/79839604），于2023年11月22日发布。然而使用谷歌搜索香港译名“麥雅賢”发现关于她的新闻都是在2024年的，也有维基百科译名循环引用的可能。--The3moboi（留言） 2024年7月7日 (日) 14:58 (UTC)回复
也有可能是香港方面2024年新增的。不过也要看看使用量，若香港方面也不怎么用该译名应移除。--微肿头龙（留言） 2024年7月8日 (一) 03:32 (UTC)回复
以英国首相配偶为例，马卓安的夫人，一直看各种文件都没见过“庄乐敏”这个名字，搜google 几乎全都是维基百科。其他名字，除了“彭雪玲”有印象被广泛报导，其他基本上都出处不明。当然，一票子人还在疯狂维护。--JéRRy ~ 雨雨 （留言） 2024年7月8日 (一) 09:10 (UTC)回复
不好意思，该译名的确是还没有正式来源，不应回退你的。--Mykola（留言） 2024年7月8日 (一) 10:10 (UTC)回复
现在不吵什么善意了吗？--JéRRy ~ 雨雨 （留言） 2024年7月8日 (一) 13:48 (UTC)回复
嗯，是我误解了。--Mykola（留言） 2024年7月8日 (一) 13:54 (UTC)回复
尝试搜索了几个，并没有搜到来源。--杰里毛斯（留言） 2024年7月8日 (一) 10:39 (UTC)回复
还在有人说“杜安妮”是Anneliese Dodds 的官译，还说星岛01可以作数。之前不是他们信誓旦旦说 David Lammy 是“林伟德”吗，现在是什么样子？留着你们自己闹腾吧--JéRRy ~ 雨雨 （留言） 2024年7月10日 (三) 13:32 (UTC)回复

设立编者著作权调查

编辑
最新留言：在5天前发布8条留言6人参与讨论

鉴于最近本人发现有些许编辑持续侵犯著作权的情况，为了记录并核实侵权情况是否属实，与此同时可协作处理并查删确实存在侵权情况的内容，认为应将英维的en:WP:CCI搬过来，不知各位有何意见。以下是我的一些想法：

  • 任何编者被发现有5个实际侵权的情况后可以开启著作权调查案件。
  • 英维有设置调查助理，而限制只能管理员或助理查核侵权属实才可开启调查。个人看法是可以先不需要助理或管理员把关，仅需任意第三方查核证明侵权属实即可。
  • 可运行ContributionSurveyor.java开启调查并列出所有需要检查的编辑。例
  • 调查开启后，使用 、 、?标注是否为侵权。侵权文本应当被删除，如需WP:RD也应提删。

--0xDeadbeef (留言) 2024年7月7日 (日) 10:47 (UTC)回复

不反对，但硬性指标建议是暂定、灵活的。按英文说法，着眼于长期的侵权。不清楚怎么算5个，比如5个条目，5个修订版本或5个章节等。任意可能太过宽松而浪费调查资源，至少一或两名延伸确认用户？--YFdyh000（留言） 2024年7月7日 (日) 17:05 (UTC)回复
可暂定一名延伸确认用户吧。5个在英维是instances，算是较模糊，我认为是5个修订版本，但至少应有一些证据证明非单一侵权（多个条目均有）--0xDeadbeef (留言) 2024年7月7日 (日) 17:41 (UTC)回复
如果有志工自愿协助，似乎也不妨碍。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月8日 (一) 07:33 (UTC)回复
我已试着在自己用户空间暂时记录我对于HYHJKJYUJYTTY侵权的查核以及处理，见User:0xDeadbeef/CCI/HYHJKJYUJYTTY。如有人想帮忙可以安装我搬过来的Deputy脚本--0xDeadbeef (留言) 2024年7月8日 (一) 08:31 (UTC)回复
不反对，不过不知道会有多少人参与。--冥王欧西里斯（留言） 2024年7月9日 (二) 05:27 (UTC)回复
我只想说人手不够：（
要设立的话流程请从简不要太复杂。--~~Sid~~ 2024年7月9日 (二) 14:08 (UTC)回复
不反对，这个东西貌似还不错。--桐生ここ★[讨论] 2024年7月14日 (日) 09:54 (UTC)回复

关于IPBE申请的问题

编辑
最新留言：在10天前发布6条留言2人参与讨论

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:IP封禁豁免权授予者、Wikipedia talk:IP封禁豁免。

哈啰大家好，我是IPBEG，我想就以下几个问题请社群讨论，给予我们明确的共识，这个是我个人发起的讨论，并没有与其他授予者讨论，希望大家尽量参予。--~~Sid~~ 2024年7月9日 (二) 14:33 (UTC)回复

不强迫备案WP:RFR/IPBE

编辑

目前的情况是都会备案到权限申请，我希望可以不强迫，应该说不知道从何时开始有了惯例会备案至权限申请，事实上日志都写得很清楚，这个备案会让我们多一个步骤，备案时所描述的内容事实上并没有提供到多大的帮助，邮件列表只有订阅相关邮件列表的人才能查询。--~~Sid~~ 2024年7月9日 (二) 14:33 (UTC)回复

授权标准

编辑

目前基本上都是授予永久权限，各位应该有注意到我授权会经常授予临时权限，这是因为有人反映说授权过于宽松，所以我希望可以针对这一部分进行讨论，在不使处理变繁杂的情况下，兼顾标准的部分。有关于这一部分我是希望本地恢复CU，交由CU来定期随机查核用户是否确实有需要用到IPBE，不是授予者与管理员们提高标准，即便提高也无法防止有意骗取IPBE的用户。--~~Sid~~ 2024年7月9日 (二) 14:33 (UTC)回复

我理解有一些人可能会觉得这个讨论有点多余，然而我的目的是在于确保社群有一定的共识，不会单方面更改后有人跳出来说，你怎么这么做你应该这么做：​（--~~Sid~~ 2024年7月9日 (二) 14:33 (UTC)回复

稍微解释一下为什么是永久权限。曾经首次授权一般都是临时权限的，但是后来发现没有太多意义。基本上所有到期之后还想要继续编辑的都会申请续期，这里也没有太多可以审查的东西，基本上遇到申请都会转成永久权限。所以没有续期的那些，也就是没有实际编辑，到了时间就忘了的人。这部分人的除权，现在由机器人自动执行。所以永久权限和首次的临时权限本质上区别也就不大了，而且还减少处理的负担。这部分是有过讨论的，找一下的话应该是可以找到讨论的。--Tiger（留言） 2024年7月9日 (二) 14:45 (UTC)回复
感谢Tiger。--~~Sid~~ 2024年7月10日 (三) 06:46 (UTC)回复

影武者已被基金会全域禁制

编辑
最新留言：在2天前发布6条留言5人参与讨论

查询meta:List_of_globally_banned_users时发现，影武者已于7月9日被列入基金会全域禁制（WMF Ban）名单中。--Itcfangye（留言） 2024年7月12日 (五) 11:28 (UTC)回复

🍾--2A0D:2683:C100:0:0:0:0:F（留言） 2024年7月13日 (六) 07:54 (UTC)回复
大快人心。何时轮到WMLO？L'Internationale, Sera le genre humain! ✏️ 2024年7月14日 (日) 09:40 (UTC)回复
该用户的用户页仍未挂{{WMF-legal banned user}}，请管理员协助处理。--132.234.229.216（留言） 2024年7月17日 (三) 08:26 (UTC)回复
主账号影武者并未受到基金会全域禁制。L'Internationale, Sera le genre humain! ✏️ 2024年7月17日 (三) 10:04 (UTC)回复
不影响，禁制针对的是个人（或组织，但就此例而言不适用），而不是单一账号。Sanmosa 蚌埠 2024年7月17日 (三) 14:19 (UTC)回复

请求社群判断已经数据过期的用户是否为傀儡

编辑
最新留言：在2天前发布2条留言1人参与讨论

见相关SPI提报，现时最少有法国饮食文化、如懿传、册封体制受到影响（很可能还不止这些），请调查助理、管理员和其TA用户判断和彻底清查，谢谢！--MCC214（Sign | Contributions） 2024年7月18日 (四) 05:12 (UTC)回复

  • 外加一些账号（包括SPA），请检查是否为冏；
延伸内容

以上。--MCC214（Sign | Contributions） 2024年7月18日 (四) 05:24 (UTC)回复

  本讨论章节会维持开放，暂时不按最后意见发表时间存档。欲让机器人存档，请移除本模板。留言请置于本模板上方。

有没有“勿添加违法网址”的警示模板？

编辑
最新留言：在22分钟前发布3条留言2人参与讨论

因为又有人在创意私房加入网站网址，虽然网址被台湾政府停止解析，但仍有从其他国家进入的可能，添加网址会违反使用条款。所以我想要不要在条目顶端放个警示模板，但不知道要去哪里找。--世界解放者（留言） 2024年7月20日 (六) 05:28 (UTC)回复

添加网址并不等于ToU中提到的那些。网址本身并非色情内容。——暁月凛奈 (留言) 2024年7月20日 (六) 05:45 (UTC)回复
之前User:SCP-2000是用这个理由删去网址，虽然台湾的法律张贴网址可能不违法，但美国的法律我不清楚。--世界解放者（留言） 2024年7月20日 (六) 07:00 (UTC)回复
添加话题
检索自“https://zh.wiki.x.io/w/index.php?title=Wikipedia:互助客栈/其他&oldid=83482947”