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

本页使用了标题或全文手工转换
维基百科，自由的百科全书

快捷方式

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

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


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


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

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

公告栏
# 💭 话题 💬 👥 🙋 最新发言 🕒 (UTC+8)
1 没有主题的页面如何评级 187 11 A2569875 2024-05-26 09:38
2 评级系统缺失问题 214 21 A2569875 2024-05-26 09:50
3 管理人员申请预讨论 280 47 Wong128hk 2024-05-27 09:04
4 对新用户禁用内容翻译工具（续） 32 13 SCP-2000 2024-05-24 00:31
5 Unblock-zh.org 32 11 魔琴 2024-05-27 14:29
6 第二十二次动员令筹备讨论 78 27 闪亮飞月 2024-05-27 22:42
7 2024年非洲月筹备讨论 28 12 Alankang 2024-05-26 21:19
8 Question: Can English read English Wikipedia Clearly? 9 4 魔琴 2024-05-25 13:43
9 设立法轮功为高风险主题 7 5 Hoben7599 2024-05-28 23:27
10 是不是创建一个披露过滤器细节的规范比较好 2 1 MilkyDefer 2024-05-28 00:30
11 关于“Save to”和“Moved to” 5 4 SunAfterRain 2024-05-28 21:13
发言更新图例
  • 最近一小时内
  • 最近一日内
  • 一周内
  • 一个月内
  • 逾一个月
特殊状态
已移动至其他页面
或完成讨论之议题
手动设置
当列表出现异常时，
请先检查设置是否有误

正在广泛征求意见的议题

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

维基专题与协作[编辑]

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

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

没有主题的页面如何评级[编辑]

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

已解决：
因Wikipedia:通用评级已通过，故没有主题的页面已可通过通用评级来进行评级，故此问题已解决-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年3月5日 (二) 09:31 (UTC)[回复]
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

像是包、比 (消歧义)、值 (消歧义)这种，内容并不属于任何专题管辖的页面，要如何评级？有没有办法“无专题评级”？不然在统计工具上面，这些未评级的页面都无法正常显示页面种类。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2023年12月7日 (四) 08:59 (UTC)[回复]

主题更多是用来评判重要度而非写作水准的吧，或许可以考虑一个通用评级，比如实际上并不应该被划到单一专题内的消歧义页。——暁月凛奈 (留言) 2023年12月7日 (四) 09:34 (UTC)[回复]
(？)疑问@暁月凛奈：比方说创建一个专用的、通用的评级模板，无专题，不使用{{WPBannerMeta}}元模板，内部只塞“本页面获评XX级”和Special:页面评级的解析器语法，然后没有别的说明？-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2023年12月7日 (四) 09:48 (UTC)[回复]
我基本没有参与评级相关，我不太明白为什么条目质量一定要和专题挂钩。举个例子的话，页面李的六个链接五个是姓氏，一个是植物，被划到生物还是人文都显然不合适，而且消歧义页本来也不算做条目。或许也可以设计成，“本页面尚未划分到具体专题，欢迎协助标记”，然后消歧义页等页面用参数取消这一句。——暁月凛奈 (留言) 2023年12月7日 (四) 11:51 (UTC)[回复]
{{WikiProject Article assessment}}可托管没有专题支援的条目--洛普利宁 2023年12月7日 (四) 11:58 (UTC)[回复]
(：)回应PJ:条目质量评级“这个维基专题已经废弃。”。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2023年12月7日 (四) 12:18 (UTC)[回复]
几乎所有专题都是废弃的，只是这个专题明面上写了而已；稍微好一点的是只有一个人参加的“个人专题”，不过这种专题基本上也是三分钟热度。如果你只是为了评级，那就不用管专题是否活跃，直接把{{WikiProject Article assessment}}往讨论页上贴就可以。以中维的实力来说，条目没有专题评级才应该是正常的，有评级的反而属于异端--洛普利宁 2023年12月7日 (四) 12:41 (UTC)[回复]
模板、分类、甚至是文件也是需要评级的项目，算上去真的跟异端没两样。而挂上专题模板呈现的未评级状态能算评级吗。 --窝法乙烷 儿法梦碎 2023年12月7日 (四) 14:03 (UTC)[回复]
(：)回应：@Milkypine：WP:评级：“约有38万条目”，中文维基百科条目数也才100万啊。哪有“异端”？我还异端儿勒。另WP:评级#统计，所有挂有评级模板条目讨论页有562,943页，未填写评级的“未评级状态”之条目讨论页有182,858页，562,943 − 182,858 = 380,085。所以被评级的“条目”是38万无误，100万分之38万 = 38%。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2023年12月7日 (四) 14:33 (UTC)[回复]
@A2569875：先定义何谓异端，如果数字多就不算异端，那么日本和中国市场可以除名异端状态了。 --窝法乙烷 儿法梦碎 2023年12月7日 (四) 14:54 (UTC)[回复]
更不用38%是数字少的一方，对中维其余62%条目来讲，这38%就是异端。 --窝法乙烷 儿法梦碎 2023年12月7日 (四) 14:59 (UTC)[回复]
{{WikiProject Disambiguation}}，这个？--Kethyga（留言） 2023年12月7日 (四) 12:47 (UTC)[回复]
这个连专题主页都不存在 囧rz……-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2023年12月7日 (四) 13:02 (UTC)[回复]
这个模板没有评级参数，而且doc页写明不要仅为放置该模板而新建讨论页。--Kcx36（留言） 2023年12月8日 (五) 03:38 (UTC)[回复]
仅供参考: enwiki之前也有相关讨论，现在已由{{WPBS}}自动为这类型非条目赋予NA-、Redirect-级别的评级与重要度。请参见w:wn:Wikipedia:Bots/Requests for approval/Qwerfjkl (bot) 24。中文或许如Category:非条目级条目?--Kanashimi（留言） 2024年1月10日 (三) 06:05 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

Random Thought: 跟进英维的WikiProject banner shell改版[编辑]

本主题或以下段落文字，在讨论结束后应存档至Template talk:WikiProject banner shell、Template talk:WPBannerMeta。

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

我倒是想起一个事儿。英维最近改版了{{WikiProject banner shell}}模版（新样式在这里），新的模版可以单独给条目一个总体的品质评级，各个WikiProject可以直接继承这个quality assessment，也可以搞自己的评级。你看是不是能实现你的没有管辖之WikiProject依然可以有评级的愿望？ --MilkyDefer 2023年12月7日 (四) 14:59 (UTC)[回复]

@A2569875，附知。--MilkyDefer 2023年12月8日 (五) 09:03 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

第一阶段：修改WikiProject banner shell[编辑]

已修改：
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。
工程量挺大，就看谁愿意改了。（几年前可能我有兴趣，现在我就精神上支持了）--洛普利宁 2023年12月8日 (五) 14:53 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

第二阶段：修改WPBannerMeta[编辑]

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

@Willy1018：提到了一个很有意义的问题。如果上方的更改套用了的话，只有“表面上”给了页面通用评级，而实际上的通用评级在各个专题中并没有达成“继承评级”的效果。这是因为评级模板默认不会知道他外面包着{{WikiProject banner shell}}模板，因此，如果要让每个评级模板都能读到通用评级，需要再一个编辑请求。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2023年12月24日 (日) 05:15 (UTC)[回复]

预计的修改方案以及其布署链接（记得填写讨论通过的diff和客栈PermaLink版本号）。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月3日 (三) 05:00 (UTC)[回复]

本主题或以下段落文字移动自Template_talk:WPBannerMeta#编辑请求_2024-01-08（固定链接），新留言请置于框外。执行人：-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月9日 (二) 13:21 (UTC)[回复]

相关议案

的配套修改-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月8日 (一) 05:03 (UTC)[回复]

想咨询一下@Kanashimi君相关修改是否有问题？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年1月8日 (一) 05:53 (UTC)[回复]
@Ericliu1912、Kanashimi：这主要是依据共识，让专题横幅能继承{{PJBS}}输入的评级值。我已经在{{多面体专题}}、{{电子游戏专题}}测试过了，没有问题。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月8日 (一) 06:00 (UTC)[回复]
User:A2569875的努力有目共睹。只不过我原先料想的是直接改w:en:Module:WikiProject banner及w:en:Module:Banner shell，而宇帆-娜娜奇看起来很辛苦的重构了代码，并且有些参数不太一样，这样我就不太好评论了。--Kanashimi（留言） 2024年1月8日 (一) 06:12 (UTC)[回复]
@Kanashimi：考虑到日后长期维护需求，我倾向请您以英文版本为基础来更新相关模板。是否能够确认有什么模板需要更新（或在互助客栈列出之类）？不过在此过渡期间，若技术上没有问题，是可以斟酌先批准既有之编辑请求。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年1月8日 (一) 12:18 (UTC)[回复]
这两个（Template_talk:WPBannerMeta#编辑请求_2024-01-08、Template_talk:WPBannerMeta/core#编辑请求_2023-12-28）属于案《Random Thought: 跟进英维的WikiProject_banner_shell改版》可以先进行；剩下的属于另一案（Module_talk:Class/data#编辑请求_2023-12-28、Template_talk:Class_mask#编辑请求_2024-01-05、Template_talk:Class_mask/core#编辑请求_2023-12-25、Template_talk:Class/colour#编辑请求_2024-01-05）属于案《同步各模板/块的评级值》目前正在公示，所以暂时还不用。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月8日 (一) 14:59 (UTC)[回复]
@Ericliu1912：要改哪些模板我在客栈上其实都有列，主要在案《没有主题的页面如何评级》和案《评级系统缺失问题》的子章节里。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月8日 (一) 15:03 (UTC)[回复]
（不用一直提及我，我有在看）—— Eric Liu 創造は生命（留言・留名・学生会） 2024年1月8日 (一) 15:11 (UTC)[回复]
@Ericliu1912、Kanashimi：另外参见此发言，User:Willy1018已复核效果符合预期，认为修改没有问题。测试也都充分了。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月8日 (一) 06:31 (UTC)[回复]
@Ericliu1912：另外如果要接受编辑请求的话，也把Template_talk:WPBannerMeta/core#编辑请求_2023-12-28也接受吧，两者是互相配套的（{{WPBannerMeta}}与{{WPBannerMeta/core}}高度相依）。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月8日 (一) 06:33 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

第三阶段：完善制度[编辑]

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

在Template_talk:WPBannerMeta#编辑请求_2024-01-08中有人认为需要给通用评级订一个“能填写什么级别”的标准来避免争议，因此立了草案Wikipedia:通用评级如下：

  1. 若一条目没有专题或不受任何专题管辖，则其通用评级可填写任意有被{{WikiProject banner shell}}支援的级别，仅要该条目有达到该级别的标准或满足该级别的条件，都可以评。
  2. 若一条目仅有一个专题，其通用评级应与该专题所评的等级一致。
  3. 若一条目有多个专题，通常由机器人自动依照规则4进行评级，但一旦出现争议时则通用评级应以所有专题都有开设的级别为主。
    • 例如：若一条目有四个专题，而有一个专题没有开设“丙级列表级”，那么通用评级就不得填写“丙级列表级”
  4. 对于有多个专题的条目，通用评级应填写最多专题评的那一等级。
    • 例如有一个条目有四个专题，其中三个专题都评为乙级，但有一个专题评为丙级，则通用评级应填写乙级。
  5. 若在规则4的情况抵触规则3，则应填写与对应级别最接近的且满足规则3的级别。
    • 例如有一个条目有四个专题，其中三个专题都评为“丙级列表级”，但有一个专题评为“列表级”且这个专题不开设“丙级列表级”。依据规则3，最多专题评的级别是“丙级列表级”，但有一个专题不开设“丙级列表级”，则通用评级应填写与“丙级列表级”最接近且位于该条目所有专题都有开设的级别，也就是“列表级”。
    • “最接近的级别”应该向下填写，例如未启用乙级的专题，通用级别遇到规则3判为乙级的情况时，则向下填写为丙级。如果丙级也有专题未开设，就再向下填写为初级。如遇到无法评级的情况，该通用评级模板就该留空。

提议将之升为指引，不晓得各位觉得如何？@Ma3r、Kanashimi、Z7504、桐生ここ：@Kethyga、暁月凛奈、MilkyDefer、Milkypine、Willy1018：-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月14日 (日) 09:44 (UTC)[回复]

实作上是否能让那些没开设大宗评级（数量最多专题）的在专题横幅内设置好参数即可？这样看起来就不会因为没开设评级、被覆盖而出问题。机器人很难判别每个专题开设的评级，因此条件3会让让机器人无法自动作业。
仅供参考，就enwiki来说，纯粹只考虑数量最多的评级。采用特殊评级的专题横幅有特殊分类，机器人处理时不会动到其评级。--Kanashimi（留言） 2024年1月14日 (日) 10:35 (UTC)[回复]
@Kanashimi：技术上不能读取评级模板的|QUALITY_SCALE=内容和/class子页面吗？如果|QUALITY_SCALE=填subpage，读取/class子页面就能得知该专题哪些评级有启用。例如{{多面体专题}}是|QUALITY_SCALE=subpage，所以读取Template:多面体专题/class原始码即可得到哪些级别是yes、哪些级别是no。如果|QUALITY_SCALE=填extended则是定义于{{Class mask/extended}}的级别。未填或standard就是只使用大宗评级。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月14日 (日) 11:00 (UTC)[回复]
如果改成“若一条目有多个专题，通常由机器人自动依照规则4进行评级，但一旦出现争议时则通用评级应以所有专题都有开设的级别为主。”机器人会不会好办一点？意为机器人填写值优先，但如果是人工评级时，才须考虑是否所有专题都有开设，且是遇到争议之时，这是为了解决“但是如果有人说“根据Wikipedia:条目质量评级标准#非标准级别和一些专题评CL的惯例，这篇列表内容充分，尽管支援条目的专题都没有设CL级别，但既然WPBS能评CL那我就评CL”呢？所以，这个评级的定位该怎么看？您作出了如此复杂的功能，但如果因为使用规则不完善而部署而引发争议，相信这是您不愿意见到的。”所描述的争议情境。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月14日 (日) 11:06 (UTC)[回复]
@A2569875 现在cewbot采用的方式是选出最大宗的评级（数量最多的评级），填入{{WPBS}}并且移除所有相同的评级。所有不同的评级都保留不动。不晓得这样的作业方式是否会产生问题？--Kanashimi（留言） 2024年1月14日 (日) 11:16 (UTC)[回复]
@Kanashimi：上面的情境说的是人为评级时可能出现的争议；如果是机器人评级，我相信应该没什么争议。所以应该不会有问题。该规则仅为了处理人为评级发生的争议，理应不影响机器人运作。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月14日 (日) 11:20 (UTC)[回复]
既然如此那我作为机器人操作者没有什么意见。当{{WPBS}}已经指定class，机器人不会动到{{WPBS}}的class。--Kanashimi（留言） 2024年1月14日 (日) 11:28 (UTC)[回复]
我在疗养，您自己请便。由于这个事情的业务逻辑挺复杂的，我不会拦着你用什么样的Lua。--MilkyDefer 2024年1月14日 (日) 12:48 (UTC)[回复]

公示已逾七日，公示期已过，期内无合理异议，因此提案通过。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月29日 (一) 03:28 (UTC)[回复]

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

临时动议：关于基础条目的额外提议[编辑]

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:基础条目。

已通过：
基础条目并入{{WPBS}}已经通过；{{WikiProject Biography}}参数还在讨论中。先行布署已通过的《将{{Vital article}}并入{{WPBS}}的|vital=参数》案。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月29日 (一) 05:36 (UTC)[回复]
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。
  • 似乎已有共识，跟随enwiki改版之后会由机器人自动完成：对各种专题横幅不再个别指定 class，而是统一置于{{WPBS}}。
  • 跟随enwiki改版之后会由机器人自动完成：将{{WikiProject Biography}}的 'living', 'blp', 'BLP', 'activepol', 'blpo', 'listas' 等参数皆改以{{WPBS}}处理，
  • 跟随enwiki改版之后会由机器人自动完成：将{{Vital article}}并入{{WPBS}}

这边最近在帮忙enwiki自动化这过程。这边将申请自动更新Wikipedia:基础条目所有子页面的图示（这部分最近测试中，已趋稳定。），以及定期维护{{WPBS}}（将各种专题横幅并入{{WPBS}}并维护 'class', 'living', 'blp', 'BLP', 'activepol', 'blpo', 'listas'等相关参数）。不知大家对此是否有建议？ --Kanashimi（留言） 2024年1月2日 (二) 09:53 (UTC)[回复]

本主题或以下段落文字移动自Wikipedia:互助客栈/条目探讨#引入enwiki近期{{WPBS}}之改版，暨将{{Vital_article}}并入{{WPBS}}（固定链接），新留言请置于框外。执行人：-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月3日 (三) 05:20 (UTC)[回复]

引入enwiki近期{{WPBS}}之改版，暨将{{Vital article}}并入{{WPBS}}

enwiki近期改版{{WikiProject banner shell}}，

这边最近在帮忙enwiki自动化这过程，并且将定期维护。想请教大家对上几种改变的赞否。

另这边将申请自动更新Wikipedia:基础条目的图示（这部分最近测试中，已趋稳定。），以及维护{{WPBS}}（将各种专题横幅并入{{WPBS}}）。不知大家对此是否有建议？

副知User:Ma3r、User:Ericliu1912--Kanashimi（留言） 2024年1月2日 (二) 06:11 (UTC)[回复]

其实个人早已注意到相关更新，只是苦于自身技术实力不足而未能协助，乐见在充分确保相容性的情况下跟进。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年1月2日 (二) 06:21 (UTC)[回复]
(＋)支持全部。--Ma3r（铁塔） 2024年1月2日 (二) 06:25 (UTC)[回复]
是的，enwiki采w:en:Category:WikiProjects using a non-standard quality scale表示自定义评级的专题，bot亦已考虑此问题，在User:Cewbot/log/20200122/configuration有此项。待zhwiki完成部署，填好User:Cewbot/log/20200122/configuration便可apply。--Kanashimi（留言） 2024年1月3日 (三) 07:08 (UTC)[回复]
  • 整理一下目前共识：
    • {{PJBS}}设立通用评级，可以统一管理同一条目的所有专题评级（已公示通过）
    • 确保最大相容性的前提下跟进英文维基的相关功能
    • 专题横幅看各专题意愿，评级可以选择统一放置于{{PJBS}}也可以自行输入
    • 未输入评级的专题横幅以继承载于{{PJBS}}的评级值为主，会优先采用载于{{PJBS}}的评级值
    • 如页面能自动判断评级则无论输入什么评级，都要以自动判断的评级为优先（原始来自这则留言，后续有在上方简单讨论）；另有设置参数能复写此设置。
    • 'living', 'blp', 'BLP', 'activepol', 'blpo', 'listas'已并入{{PJBS}}，但是否废除{{WikiProject Biography}}内的'living', 'blp', 'BLP', 'activepol', 'blpo', 'listas'还有待讨论
    • {{WPBS}}已经加入{{Vital article}}的所有参数，但是否要用{{WPBS}}取代{{Vital article}}还有待讨论
以上-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月9日 (二) 18:08 (UTC)[回复]

我有不同意见。英维的WPBannerMeta模块有很长一大坨代码都是在处理这个Vital Article的事情；具体来说，他们把校验这个Vital Article是不是真的Vital Article什么的逻辑全部写进去了。这一坨东西让可维护性和可读性（有可能还有效率）遭到了重大影响。我认为这更适合由一个外部机器人维护，而不是剥削这个已经很折磨人的Lua。 --MilkyDefer 2024年1月14日 (日) 12:53 (UTC)[回复]

我的建议方案是，|vital=参数可以存在，但是只有UI作用，由一个外部的机器人进行监察和更新操作。--MilkyDefer 2024年1月14日 (日) 12:55 (UTC)[回复]
若能简单改enwiki的程式码来用，或许不必担心折腾的问题。另一方面假如只留UI功能的话，是否干脆维持原来的{{Vital article}}就好?--Kanashimi（留言） 2024年1月14日 (日) 13:06 (UTC)[回复]
Module:Vital_articles都已经分成类似杂凑表查询了，有什么折腾的问题？已经高效率优化了好吗。理论上，此实现的内存开销甚至有望低于英文维基，因为英文维基只分成27个表，而中文维基是36个表，代表中文维基每个表的项目数量更少，在类似散列函数计算之后，要读取的JSON更小，表示内存用量更少，单个表项目更少表示查询更快。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月14日 (日) 13:12 (UTC)[回复]
基础条目模板合并案公示[编辑]

见公示声明。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月24日 (三) 03:38 (UTC)[回复]
  • 还真的没有，那应该误会了。那这BOTTOM TEXT参数到底是从哪里来的？该废除的参数还是应该尽早废除。基本上只剩下一个(？)疑问：是不是还要写{{WPBS|class=xxx}}才能让其强制正常显示？--Z7504非常建议必要时多关注评选（留言） 2024年1月22日 (一) 06:05 (UTC)[回复]
  • 总之全部都是Module:PJBSClass/main的问题，不镶嵌模板就无法判断，但“条目内挂了模板所以可以判断”，您如果那么清楚的话，那就直接建模板阿。标准的自欺欺人，结果居然是没动脑过的回复，被泼冷水真的刚好而已。这样如何保证里面可以不用写上比如|class=xxx的参数，变成{{WPBS|collapsed=yes||class=xxx还能让它正常显示？--Z7504非常建议必要时多关注评选（留言） 2024年1月22日 (一) 23:21 (UTC)[回复]
    • 不需要保证，因为机器人会自动填写{{WPBS|collapsed=yes||class=xxx，保证的话等于和机器人抢工作，与本案背道而驰，因为该设计就是要给机器人维护的空间，如果没有正面回答此陈述将视为无效。没填写|class=显示不一样，反而还有能分辨机器人是否填过的功能，岂不是更好？ 另，(！)抗议没考量读者体验就乱讲的提案，评级是面向编者的信息，(－)强烈反对把评级写在条目里，故我认为目前的方案已是最适合的方案； 另，在此警告，在此案讨论|class=参数已离题。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月23日 (二) 01:24 (UTC)[回复]
@Z7504：我直接针对你最初的问题回答“是不是还要写{{WPBS|class=xxx}}才能让其强制正常显示？”，是，所以需要手动填上。本案并不包含甲乙丙初级自动判断，公示也不包含这个部分，若你希望有甲乙丙初级自动判断请另提他案，因为不在本案处理范围内。 此外，你也无须担心“是不是还要写{{WPBS|class=xxx}}才能让其强制正常显示？”问题，因为下方Kanashimi已经申请机器人了，您无需手动填写，此意见可以结案了。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月23日 (二) 01:44 (UTC)[回复]
本公示不包含甲乙丙初级自动判断，若三日后还在要求甲乙丙初级自动判断将视为无效意见。若希望|class=没输入也能自动显示甲乙丙初级请另外提案谢谢，不在本案有办法处理的范围内。“这点小bug麻烦也先改了吧，不然都还要强制输入才能确保正常显示，问题不大才对”本案是处理基础条目自动化，而不包含class有没有输入的问题，因此不在此案处理范围内，请另提他案，谢谢。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月23日 (二) 02:02 (UTC)[回复]

已提出机器人作业申请，欢迎提供建议，谢谢。 --Kanashimi（留言） 2024年1月23日 (二) 01:38 (UTC)[回复]

公示期已到，期内无合理异议，且公示期内的意见之意见提出者已妥协，因此提案公示通过，将进行布署。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年1月29日 (一) 05:36 (UTC)[回复]

本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。
{{WikiProject Biography}}参数案[编辑]

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

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

公示到期，期内无合理异议，提案通过。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年2月13日 (二) 03:40 (UTC)[回复]

本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。
是否废除{{WikiProject Biography}}原生的'living', 'blp', 'BLP', 'activepol', 'blpo', 'listas' 等参数[编辑]

无共识：
没有共识，择日再议，结以待续。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年4月19日 (五) 06:32 (UTC)[回复]
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

待机器人User:Cewbot/log/20200122/configuration清理完所有{{WikiProject Biography}}的'living', 'blp', 'BLP', 'activepol', 'blpo', 'listas' 等参数再开始讨论。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年2月13日 (二) 03:42 (UTC)[回复]

本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。
Category:缺少listas变量的传记专题页面改由{{WPBS}}加入[编辑]

本主题或以下段落文字，在讨论结束后应存档至Category talk:缺少listas变量的传记专题页面。

Category:缺少listas变量的传记专题页面方案二[编辑]

评级系统缺失问题[编辑]

（原始标题为“将{{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)[回复]
    @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)[回复]
    • 我觉得改动WPBS最少的可能是将所有“条目品质性”（甲乙丙丁初等）和“非条目类别性”（Disambig、SIA、Template等）的级别全部设为标准评级（含少数专题另设的Bplus和D、以及很少专题用的A级等[有专题用A级，如台风之类的专题。]），“性质性”（Future、Current等）的级别全部设为非标准评级。这些“与条目品质无关”的评级就让专题自己评，不影响WPBS，就不会出现要在CL级或Future级取舍的状况了。然后各自专题不要的，自己去mask（到时全站公告一下，想接受的专题就接受，不想接受的专题就自行写mask，这样写mask的责任就不会在此次修改上）。技术上成本最小。 只不过以上作法因会将AL、BL、CL、SL也列入标准级别，代表List级别可能会变成没有任何页面会被评成List级，看是要废除List级还是保留List级在代码里，不想跟进的专题自己mask。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年3月25日 (一) 04:43 (UTC)[回复]
    • 然后主题专题自设的Complete、Substantial、Basic、Incomplete因WPBS默认在非条目命名空间时会因“Namespace优先”而评成“主题级”，所以我想应该也问题不大。如需在WPBS中禁掉，可可以将Module:PJBSClass#L-53的一堆if陈述式注解掉。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年3月25日 (一) 04:57 (UTC)[回复]
      您说的也是可行方案。目前启用BL、CL的专题，List基本都是当和Start对等的级别来理解；如果都接受List级=初级列表，而不用新建等级，那留着List级也OK。唯一担心的是A级，倒不是有没有人用的问题。A级是高于GA的，英维也是A级评级比GA评级规格高：GA可以随便一个外行评，A级专题内部出三个专家评，FA是包括专题专家在内的社群集体评，所以有FA>A>GA的逻辑链。但是我们的FAC/GAN和英维评级模式完全是两码事，到头会不会还是社群认GA不认A？--For Each element In group Next（留言） 2024年3月25日 (一) 14:33 (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[编辑]
  • 为所有标准类别补上例子。

后续讨论[编辑]

关于 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)[回复]

管理人员申请预讨论[编辑]

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:申请成为管理人员。

本主题全部或部分段落文字，已移动至Wikipedia talk:申请成为管理人员。

工单准备[编辑]

于Phabricator查看
编号T361902的工单

这里有一点需要注意的内容。首先，根据Wikipedia:征求意见/2024年管理人员制度改革#议案2B：处理合并选举规则不清晰问题，新投票界面应包含类似“管理人员选举无当选限额，各候选人分开计票，支持票不限于一票”的指引。其次需要考虑到Wikipedia:征求意见/2024年管理人员制度改革#议案2A：合并选举存废中所讨论的可否拆分。同时，根据上方讨论关于WT:ARBCOM#问卷的说法，同时包含关于仲裁委员会的调查问卷（不是选择，而是填文字回答）：

管理人员解任在多大程度由仲裁委员会处理？

  • 甲、仲裁委员会按调查事实及方针指引，直接作出除权决定。
  • 乙、由仲裁委员会调查事实并发布管理人员操守报告，确认存在违规事实后，才转交社群决议除权。
  • 丙、仲裁委员会完全不参与管理人员解任。

欢迎讨论。0xDeadbeef (留言) 2024年4月3日 (三) 12:42 (UTC)[回复]

请问这个是指提交给仲裁委员会的案件，还是所有RFDA案件？--桐生ここ★[讨论] 2024年4月3日 (三) 14:48 (UTC)[回复]
路西法人的意见是所有RFDA经过ARBCOM，我的意见是RFDA和ARBCOM不互相影响。这个问题或许也可以添到工单上。--0xDeadbeef (留言) 2024年4月4日 (四) 00:52 (UTC)[回复]
赞同你的意见“RFDA和ARBCOM不互相影响”，支持添加到工单上。--桐生ここ★[讨论] 2024年4月4日 (四) 03:44 (UTC)[回复]
这需要另行草拟问题。我觉得此问题本身可以先加上定语，只涵盖由仲裁委员会经手处理者（也就是原本社群提出者另议），以避免混淆。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年4月4日 (四) 09:35 (UTC)[回复]
可附上相关讨论链接。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年4月4日 (四) 09:35 (UTC)[回复]
我还是比较同意上方说Eric Liu说如果只是希望给意见，那还不如改成通告，直接请大家去讨论页留言互动，而不是事后再个别整理几条留言。的说法。这样附上留言的方式不便于详细展开讨论。--Ghren🐦🕐 2024年4月4日 (四) 17:24 (UTC)[回复]
如是者，我不清楚你们这个问卷调查是是不是要匿名征求意见。如果答案为是，可考虑加入工单；如是答案为否，我建议在管理员选举的说明中提及+MMS即可。--春卷柯南－发前人所未知 ( 论功行赏 ) 2024年4月4日 (四) 22:35 (UTC)[回复]
据说是匿名征求意见--0xDeadbeef (留言) 2024年4月5日 (五) 01:37 (UTC)[回复]
Why not both？匿名收集意见方便整合各方观点，也撇除了发言者身份的观感，方便往后只针对观点讨论；MMS内引导亦可即时邀请更多用户参与相关讨论。--路西法人 2024年4月5日 (五) 01:42 (UTC)[回复]
我想即使是在一般的页面讨论，也应该要做到“整合各方观点”和“对事不对人”这两件事吧。匿名收集意见不是完全对以上两点没有帮助，只是作用很少而已。--Ghren🐦🕒 2024年4月5日 (五) 07:13 (UTC)[回复]
不试试怎么知道有没有帮助呢？what's the worst that can happen？没有人提意见？没有有价值的意见？那又怎样。结果出来整合一下大家的意见，再公开讨论也还好吧。--0xDeadbeef (留言) 2024年4月5日 (五) 10:26 (UTC)[回复]
根据phab:T358067的时间轴，此次管理人员选举的投票时间只能够在5月初开始。我们有可能需要更新一下投票时间。--1233 （T / C） 2024年4月9日 (二) 06:51 (UTC)[回复]
依据现行指引，获得正式提名之时，必须立即置申请子页面，且一定要在四月二十八日前完成安全投票筹备。显然此规定无法实现，弹性过低，事后大概需要一并检讨。至于是次申请的处理方法，我认为可以经全体被提名者同意（或至少予以知会），请行政员宣告因现行规定窒碍难行，延后讨论期及投票期。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年4月11日 (四) 12:33 (UTC)[回复]
副知@Manchiu、UjuiUjuMandan、ASid、ATannedBurger、SickManWP。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年4月11日 (四) 12:34 (UTC)[回复]
本人已于昨晚宣布退选，故私以为不用为本人创建RFA子页面。我认为现时可以为四位候选人创建RFA子页面，这样就能提早进入发问环节，争取更多时间让社群了解候选人的观点及立场。--维基病夫邀请您加入❤️边缘人小组·🖊️签到 2024年4月11日 (四) 12:38 (UTC)[回复]
支持先进入提问期。--桐生ここ★[讨论] 2024年4月11日 (四) 16:10 (UTC)[回复]
但提早进入，也提早结束，我认为申请应反映社群最新共识变动，所以越迟开始越好。无论如何，在大家还没商定期限以前，都不应该径行开始。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年4月11日 (四) 16:28 (UTC)[回复]
个人认为可延长提问期以增加关注度。理论上当前条文为在被提名者经行政员确认获得正式提名之时起二周内，任何用户都可以发表意见，包含提问及讨论等，不过考量到此条自2006年以来就已设立，个人认为此根据自由意志的二周提问期限（若不是因自由意志所设立，我也很有兴趣知道为什么不是）已无法实际符合当前RFA的状况，包括因SecurePoll所导致的各种选举过程延宕的情况。
个人会希望提问期可从设立RfA子页面开始至投票前一到二周结束，而之所以留空一到两周的目的是作为缓冲并希望候选人能回答完所有问题。嘛，当然，这个提案很有可能会导致候选人需要答题的数量变多，但可通过其他措施如限制问题数量至一人三问或其他方式来进行改善。--（☎）dt 管理员竞选中 2024年4月14日 (日) 07:41 (UTC)[回复]
（及@AT）—— Eric Liu 創造は生命（留言・留名・学生会） 2024年4月11日 (四) 16:28 (UTC)[回复]
再副知其他行政员@Ffaarr、Jimmy Xu、Kegns、Shizhao、Wing、Wong128hk。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年4月11日 (四) 18:56 (UTC)[回复]
@Ericliu1912：已知悉。辛苦。-千村狐兔（留言） 2024年4月11日 (四) 15:09 (UTC)[回复]
感谢告知，辛苦了谢谢。--~~Sid~~ 2024年4月11日 (四) 15:43 (UTC)[回复]
@Ericliu1912 @Shizhao @ATannedBurger 距离五月不足两周了，本人认为应该开始讨论期（最好是4月21日），直到投票准备就绪为止。铁胶壹名 2024年4月18日 (四) 08:36 (UTC)[回复]
@Manchiu @UjuiUjuMandan @AT @ASid @ATannedBurger 行政员已完成申请资格复核，现已创建对应的选举页面（Manchiu、UjuiUjuMandan、AT、ASid、ATannedBurger），唯根据上面的讨论，提问时间尚未开始。铁胶壹名 2024年4月14日 (日) 07:11 (UTC)[回复]
辛苦了--（☎）dt 管理员竞选中 2024年4月14日 (日) 07:16 (UTC)[回复]
今天已经是4月23日（UTC+8），各候选人的RFA界面也都已经完成设立，本讨论自一周前已无更新内容。若按照工单中所述，4月26日直接进入投票期，是否意味着提问时间将与投票期重合？还是说社群有其他关于提问期及投票期之决议？--SheltonMartin留言|签名 2024年4月23日 (二) 02:03 (UTC)[回复]
@阿南之人 @SheltonMartin 根据phab:T358067，U4C的投票目前为第一优先级（由4月26日到5月9日），考虑到讨论期一般开启七天，如开启太长时间的话会给参选的人带来不必要的压力，则最早讨论期应由5月3日开启，在中维选举在U4C选举之后立即开始的情况下。--0xDeadbeef (留言) 2024年4月23日 (二) 12:23 (UTC)[回复]
（而U4C的投票还要点票这个事情，我建议先等U4C的投票点票结束再考虑什么时候开启讨论。）--0xDeadbeef (留言) 2024年4月23日 (二) 12:26 (UTC)[回复]
1. 请社群讨论，是否有必要在揭示板或其他地方对讨论期及投票期的时间节点作出更清晰的说明？
2. 先前有编辑提出延长讨论期的动议，社群是否考虑付诸讨论？
3. 建议明确后续管理人员任免投票的时间节点（如在某月第某周开启），对中维的大部分用户而言，U4C的投票能有多大限度影响中维的管理人员任免存疑，而且似乎也没有看到各语言维基需避开U4C或类似选举的规定或先例。
以上。--SheltonMartin留言|签名 2024年4月24日 (三) 00:27 (UTC)[回复]
U4C的投票能有多大限度影响中维的管理人员任免存疑 - votewiki在U4C投票期间是英文，而一般中维投票时会改为中文。你要觉得大家能看着英文投票就没事。
别的语言维基又不用SecurePoll。--0xDeadbeef (留言) 2024年4月24日 (三) 08:17 (UTC)[回复]
@Manchiu、UjuiUjuMandan、ASid、ATannedBurger：不然设五月一日至十四日为正式讨论期，十五日至二十八日为投票期？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年4月24日 (三) 07:57 (UTC)[回复]
可--（☎）dt 管理员竞选中 2024年4月24日 (三) 08:02 (UTC)[回复]
OK。 --ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨᡩ᠋ᠠᠨMandan 2024年4月24日 (三) 08:39 (UTC)[回复]
checkY已更新选举页面。铁胶壹名 2024年4月24日 (三) 09:43 (UTC)[回复]
好。辛苦诸位。-千村狐兔（留言） 2024年4月24日 (三) 23:30 (UTC)[回复]
@Manchiu @UjuiUjuMandan @ASid @AT @ATannedBurger 今天讨论+提问时间正式开始。请各用户和候选人做出准备。L'Internationale, Sera le genre humain! 2024年5月1日 (三) 03:32 (UTC)[回复]
@Manchiu、UjuiUjuMandan、ASid、ATannedBurger：考虑到设立选举的准备尚未完成（投票者列表相关 query 仍在执行，且 T&S 仍未回复），个人建议投票期由5/15延迟至两周后，即5/29举行？副知候选人。谢谢。--SCP-0000（留言） 2024年5月13日 (一) 15:32 (UTC)[回复]
那么提问环节是相应延长？已有候选人表示提问压力甚大…-千村狐兔（留言） 2024年5月14日 (二) 09:45 (UTC)[回复]
本人认为停止提问，但可以继续在意见区讨论。L'Internationale, Sera le genre humain! ✏️ 2024年5月14日 (二) 09:51 (UTC)[回复]
提问环节的长度是有规定的，我认为不宜延长。同意上面的见解。Sanmosa 全方贫工之联合 2024年5月14日 (二) 09:54 (UTC)[回复]
无论如何，感谢@SCP-2000：SCP-2000君辛劳。-千村狐兔（留言） 2024年5月15日 (三) 02:31 (UTC)[回复]
既然社群无异议，现暂定5/29 - 6/12举行，谢谢。--SCP-0000（留言） 2024年5月15日 (三) 06:06 (UTC)[回复]
提问，若5/29 T&S仍未回复，投票期是否会继续延长？--SheltonMartin留言|签名 2024年5月16日 (四) 05:25 (UTC)[回复]
@Manchiu、UjuiUjuMandan、ASid、ATannedBurger、Wong128hk、Jimmy Xu： T&S 回复称可在 5/29 - 6/12 期间举行选举。另外，由于运动宪章批准投票于 6/25 开始，技术上行政员不能作出延长选举一周的做法。副如候选人及监督员。谢谢。--SCP-0000（留言） 2024年5月18日 (六) 01:56 (UTC)[回复]
知悉，辛苦！－千村狐兔（留言） 2024年5月18日 (六) 02:25 (UTC)[回复]
知悉，有劳通知。--J.Wong 2024年5月27日 (一) 01:04 (UTC)[回复]

对新用户禁用内容翻译工具（续）[编辑]

于Phabricator查看
编号T349959的工单

原讨论存档见此：Wikipedia:互助客栈/其他/存档/2024年3月#对Phabricator的回应

以下为Pginer-WMF的最新回应：

Perfect. I think we can plan to introduce these changes. We plan to introduce these in iterations.

  1. Limit publishing into the main namespace to "extended confirmed users" only.
  2. Get input from the community on the effects, for the community to decide whether to make the restriction more/less strict.
  3. Make machine translation non-default.

In this way we can have a better understanding on the effect of each of the changes and how to adjust them.

简单而言，他们将作出以下更改：仅允许延伸确认用户将翻译发布到主命名空间，并愿意之后依社群意见将限制调整成更严格 / 宽松；以及机械翻译设为非默认选项。

@Lemonaka、Ericliu1912、SIridiuM28、Hoben7599、Cwek、S8321414、日期20220626、桐生ここ、魔琴、YFdyh000、MilkyDefer、Dewadipper、Stang： 考虑到他们的提议与过去讨论的共识（即禁止翻译发布到主命名空间及机翻设为非默认）相近，如果一周后没有任何异议，即视为社群同意他们的提议。副知所有曾参与讨论的编者。谢谢。--SCP-0000（留言） 2024年3月23日 (六) 13:27 (UTC)[回复]

没问题。--日期20220626（留言） 2024年3月23日 (六) 13:33 (UTC)[回复]
应该可以。--冥王欧西里斯（留言） 2024年3月23日 (六) 14:20 (UTC)[回复]
挺好，我收到了邮件但都忘了这事了。--MilkyDefer 2024年3月23日 (六) 15:01 (UTC)[回复]
好。 -‎Lemonaka 2024年3月23日 (六) 16:56 (UTC)[回复]
非常好。——Aggie Dewadipper 2024年3月23日 (六) 19:55 (UTC)[回复]
他们愿意退让是可以就此参考他们的意见啦--SunAfterRain 2024年3月24日 (日) 14:16 (UTC)[回复]
赞同。--桐生ここ★[讨论] 2024年3月24日 (日) 16:51 (UTC)[回复]

既然已有多人同意此更改，且正如上方提到他们的提议与过去的共识相近，故依照 WP:SNOW 视社群同意他们的提议，并已在 phab 反映社群的意愿。谢谢。--SCP-0000（留言） 2024年3月24日 (日) 14:29 (UTC)[回复]

不反对如此配置。但扒了三个有使用内容翻译工具的直出主条目空间的成品（中国的动物福利和权利、自由意志民主党人、杰克逊·欣克尔 ），我还是觉得禁用了可能更好。 囧rz……——Sakamotosan路过围观 | 避免做作，免敬 2024年3月25日 (一) 08:15 (UTC)[回复]
目前方案通过后第一个条目不会直接输出到主空间，因为作者的编辑数量还达不到延伸用户的级别。所以至少挡掉三分之一了，不错了。--日期20220626（留言） 2024年3月25日 (一) 08:20 (UTC)[回复]
如果可以，不知能否帮忙整理使用内容翻译而有问题的条目？这样方便与基金会沟通时，有相关例子可供他们参考及研究。谢谢。--SCP-0000（留言） 2024年3月25日 (一) 16:44 (UTC)[回复]
感觉被G13的多少都是内容翻译的条目。。。—-Aggie Dewadipper 2024年3月25日 (一) 18:39 (UTC)[回复]
偶尔也有非内容翻译的条目被挂G13。--日期20220626（留言） 2024年3月25日 (一) 22:26 (UTC)[回复]
@SCP-2000：用RTRC找主条目空间、新建页面（因为原生最近更改不方便找新建页面）、标签为“内容翻译”、“内容翻译2”的，应该会存在不少。例如找到一篇乔安娜·斯丁格蕾（oldid=82028905）。好像最近多了一批没用户页的新用户在用这个系统来翻译，而且首次格式质量都存在或多或少同类问题（包括斜体、数字间空格、参考注脚之间空格或者参考复制的一些格式暴露（<cite>这种）、缺少参考列表，部分还有格式紊乱、模板丢失）虽然这些问题是新页面巡查员应该去做的事……——Sakamotosan路过围观 | 避免做作，免敬 2024年3月26日 (二) 02:15 (UTC)[回复]
根据提案，新用户已经无法通过内容翻译直接在主空间生成条目。--日期20220626（留言） 2024年3月26日 (二) 03:31 (UTC)[回复]
只是提供收集说服来源的方法。当然希望拉高下限能挡住一部分借助该系统粗制滥造的低质量翻译条目。——Sakamotosan路过围观 | 避免做作，免敬 2024年3月26日 (二) 13:15 (UTC)[回复]
另外，感觉User:New user message不会对不是以本项目注册的新用户发自动欢迎的（例如找到的User:赛博崔会遇见电子铝黄瓜吗、User:Art4cn），有可能导致新用户缺乏对格式规则的了解。——Sakamotosan路过围观 | 避免做作，免敬 2024年3月26日 (二) 02:26 (UTC)[回复]
这个改配置即可，可以在其创建本地账号时发送。个人认为至少其有一个编辑在发送会好些？（改配置噩梦）--Hualin🎗️希望の星は青霄に昇る Commons|Talk 2024年3月30日 (六) 22:34 (UTC)[回复]
What the hell is that? -Lemonaka 2024年3月30日 (六) 01:21 (UTC)[回复]
In general, Content translation will redirect users to their chosen language of wiki, even if they use it on zhwiki. So I don't think it's the content translation's fault, but I have no idea how they can do that :)--SCP-0000（留言） 2024年3月30日 (六) 07:45 (UTC)[回复]

内容翻译现已缩紧[编辑]

（注：复制自WP:互助客栈/消息#内容翻译现已缩紧，原由User:MilkyDefer发布。）

自4月10日（三）起，只有拥有延伸确认权限的用户可以使用内容翻译功能将页面发布到主条目空间。这次调整是因应近期多发的粗滥翻译问题所做出的。延伸确认权限自动授予注册满90天且编辑满500次的编者，以及管理员。

请巡查员和所有编者留意这次更改后，翻译条目的品质是否有改善。其结果会决定是否采取下一阶段的措施：将“从原文开始”设置为默认翻译选项。

@Lemonaka、Ericliu1912、SIridiuM28、Hoben7599、Cwek、S8321414、日期20220626、桐生ここ、魔琴、YFdyh000、Dewadipper、HualinXMN、SunAfterRain、S8321414： 副知所有曾参与讨论的编者。谢谢。--SCP-0000（留言） 2024年4月11日 (四) 17:11 (UTC)[回复]

phab:T349959#9711650，疑似未生效。--碟之舞📀💿 2024年4月14日 (日) 07:50 (UTC)[回复]
不过好像数量并不多。--日期20220626（留言） 2024年4月14日 (日) 07:58 (UTC)[回复]
原因也大致抓到了，Special:PermanentLink/82270024#L-111应该能当临时补丁--SunAfterRain 2024年4月14日 (日) 14:35 (UTC)[回复]
并没有生效：Special:用户贡献/EitanVel。上面的patch有管理员review下么？--Tim Wu（留言） 2024年4月19日 (五) 01:36 (UTC)[回复]
@SunAfterRain Not applied till now, Special:Contributions/Hueydome88E92 -Lemonaka 2024年4月21日 (日) 10:52 (UTC)[回复]
@Lemonaka：phab:T349959#9734223 patch backports in today. 虽然我是不知道他们说的移植后仍然有问题是什么意思，毕竟我刚才看的结果确实有正确拦截到了...--SunAfterRain 2024年4月23日 (二) 12:39 (UTC)[回复]
确实还没有修正，如火腿黄油三明治。--SCP-0000（留言） 2024年4月24日 (三) 03:51 (UTC)[回复]
@Lemonaka、Ericliu1912、SIridiuM28、Hoben7599、Cwek、S8321414、日期20220626、桐生ここ、魔琴、YFdyh000、Dewadipper、HualinXMN、SunAfterRain、S8321414： 补丁已于5/15部署，目前为止未见有非延伸确认用户能发布条目至主条目空间，似乎已被修正。另外，现时仅限制发布权限，而没有限制使用机翻的权限，草稿仍大机会存在翻译质素低下的问题，烦请各位注意翻译条目的品质有否改善。如果一个月后没有任何意见，则会让此讨论自动存档。副知所有曾参与讨论的编者。谢谢。--SCP-0000（留言） 2024年5月23日 (四) 08:15 (UTC)[回复]
一月似过久，二周何如？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年5月23日 (四) 12:20 (UTC)[回复]
两星期未必足够观察其变化及影响，且此讨论非急需结案或关闭。--SCP-0000（留言） 2024年5月23日 (四) 16:31 (UTC)[回复]

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

Unblock-zh.org[编辑]

Unblock-zh.org网站的样子

很久以前讨论过的一个项目，也就是unblock-zh的网站版，我最近给他做出来了，如果对测试版软件感兴趣的话，请去 https://unblock-zh.org 这里去看看。（注意测试版软件，你的用户最后很可能被删掉！）

附带一个教学视频 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)[回复]

试运行[编辑]

在过去的几周里，我增加了最后的一些的功能，分别是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)[回复]

第二十二次动员令筹备讨论[编辑]

原标题为：今年没有动员令？

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:动员令/第二十二次动员令。

如题。都快五月了，看来暂停一年--Dragoon17cc（留言） 2024年4月29日 (一) 22:08 (UTC)[回复]

？？？有这么早准备？--在下荷花，请多指教（欢迎签到） 2024年4月30日 (二) 01:14 (UTC)[回复]
去年还真的是三月底时就有人在问要不要举办了，不过当时一路讨论到5月中旬才有近一步筹备，尚不算多晚。另这时间感觉也适合问WP:非洲月今年有没有要办？--WiTo🐤💬 2024年4月30日 (二) 12:59 (UTC)[回复]
我去，中文维基人集体失忆了 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年4月30日 (二) 15:03 (UTC)[回复]
可以开始筹备了吧？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年4月30日 (二) 19:24 (UTC)[回复]
为了避免像去年那么赶，还是先把可能有需要讨论的信息留在这好了：
  • 举办时间：若要沿用旧制，即“7月第二个星期六”至“9月第二个星期日”，则今年时间会是7月13日至9月8日，共57天，较去年（64天）少一周。
  • 另去年也有讨论但没后续的内容——是否需要将常常被纳入小动员令主题内的“亟需撰写”或“缺少来源”改为额外加成的方式，以让给其他更需要的主题？但就如当时所言，加分方式已经颇复杂，且“缺少来源”的计分并非一般计分方式可能有需要额外调整。—WiTo🐤💬 2024年5月1日 (三) 00:52 (UTC)[回复]
历史上，到了5月就差不多是时候筹备动员令了。但由于社群对于这回事越来越懈怠，我感觉今年不办还是可以的。先问想不想办，再问怎样办。如果决定要办，我建议把历年来动员令的规则合编为成文规则，这样以后社群就不用为了日期、计分等问题争论一番（但这估计会是一个大工程，明年才能用上）。另外就是处理常规问题，包括WiTo君提到“亟需撰写”、“缺少来源”加成悬而未决问题。--春卷柯南－发前人所未知 ( 论功行赏 ) 2024年5月1日 (三) 19:53 (UTC)[回复]
推到和亚洲月同期举办都不迟。--🎋竹生🎍 2024年5月2日 (四) 09:09 (UTC)[回复]
那就太迟了。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年5月2日 (四) 12:32 (UTC)[回复]
姑且先简易架好WP:DC22的页面了，再看这边要讨论到什么程度再移过去讨论其他细节。--WiTo🐤💬 2024年5月2日 (四) 13:59 (UTC)[回复]

主题[编辑]

本次我推荐哲学类及非虚构书籍类条目，两者都太冷门。--S叔 2024年5月1日 (三) 17:09 (UTC)[回复]
可以推荐色情类条目吗☺--日期20220626（留言） 2024年5月2日 (四) 02:20 (UTC)[回复]
可以的，但我相信会被电子游戏专题的エロ游戏专门编者镇压（若本人心血来潮参与的话那本人也算其中一分子）--S叔 2024年5月2日 (四) 02:35 (UTC)[回复]
哲学类不会有人写的。和DC19届“文学”类是一样的——中维很缺这个，但是您维没活跃编者写这个。倒不如将名额拿出来给其他范畴的。--Ghren🐦🕚 2024年5月4日 (六) 15:27 (UTC)[回复]
不然可以举办大中小混合动员令--August0422（留言） 2024年5月5日 (日) 08:37 (UTC)[回复]
兹推荐以艺人为主题，毕竟该主题之GA、FA甚至DYK皆非常少--August0422（留言） 2024年5月5日 (日) 08:41 (UTC)[回复]
{{law}}模板也有许多绿色链接，中维极缺法律类型之条目--August0422（留言） 2024年5月5日 (日) 08:42 (UTC)[回复]
哲学类个人认为似乎是一个过于专业的内容，受众或许过于狭窄，并不会有太多维基人编辑这些条目；
而非虚构书籍类条目很可能存在寻找参考资料的问题，或许在编辑上会提供一些阻力。--——这是不想改签名的Ghrkya（主页|讨论|签名） 2024年5月7日 (二) 15:44 (UTC)[回复]
哲学类我同意你的说法。不过证明非虚构书籍有关注度常用的门槛就是找两篇或以上独立可靠及以它为主题的书评，这比较简单。依序按访谈或著作前言写背景，按书评内容或自行写出书籍内容，再按书评写评价部分。--S叔 2024年5月8日 (三) 02:38 (UTC)[回复]
谢谢您的科普，本人对非虚构书籍的了解确实不深，但是由于本人并不非常喜欢阅读，或许无法在这类型中给出有意义且中立的看法，不过依然不胜感激！--——这是不想改签名的Ghrkya（主页|讨论|签名） 2024年5月9日 (四) 15:20 (UTC)[回复]
{{law}}模板也有許多綠色連結，中維極缺法律類型之條目--August.0422 2024年5月9日 (四) 10:44 (UTC)[回复]
若今年的非洲月直接告吹，那我想建议直接把这个范围放进中动员令的部分。另外个人感觉生物技术/医学相关条目貌似也较少。—WiTo🐤💬 2024年5月2日 (四) 01:30 (UTC)[回复]
鄙人推荐饮食和中国文化遗产作为本次动员令的主题，前者是因为少有新条目产出，后者则是由于近期除了几个文物保护单位FL外已很久没有高质量（GA、FA）的条目产出。--人间百态,独尊变态(讨论) 2024年5月2日 (四) 14:44 (UTC)[回复]
文化遗产不一定要限定在中国吧？毕竟有些国家的世界文化遗产都没条目，条目的空缺更严重。——BlackShadowG Slava Ukraini! 2024年5月3日 (五) 02:52 (UTC)[回复]
也不是不可以。--人间百态,独尊变态(讨论) 2024年5月3日 (五) 03:06 (UTC)[回复]
推荐“原创类”，可以改善动员令期间出现大量品质不佳翻译条目的问题。另外推荐生理学。—Y. Sean 2024年5月3日 (五) 03:05 (UTC)[回复]
冒昧地问一下，什么意思叫做“原创类”。我不是很理解这个主题的意思。--微肿头龙（留言） 2024年5月4日 (六) 14:30 (UTC)[回复]
“原创类”应该是指主编自行寻找参考资料，撰写的条目，不是从其他语文版本翻译来的条目--Wolfch (留言) 2024年5月4日 (六) 15:30 (UTC)[回复]
支持原创类，原创类应该分数加倍，因为自行搜集资料比翻译多出很多时间--Dragoon17cc（留言） 2024年5月12日 (日) 22:35 (UTC)[回复]
推荐交通类及交通设施条目，中文地区的交通类条目内容“非常丰富”，当中包括九巴条目的车牌资料，单凭一位编辑者处理根本没有可能完全清理及维持超过一千条条目品质；港铁相关条目也被公众质疑中维有意图淡化附来源的重要新闻事件。在非中文地区条目，绝大部分小型车站大多也只有一至二段，希望可以借此清理条目或补充内容。--唔好阻住我爱国（留言） 2024年5月6日 (一) 13:10 (UTC)[回复]
(＋)支持，此外还建议将地铁条目也加入考虑范围内，但是这些条目似乎本身的可查证性有一些问题……--——这是不想改签名的Ghrkya（主页|讨论|签名） 2024年5月6日 (一) 15:49 (UTC)[回复]
推荐家居和生活用品类的条目，对百科的重要性不言而喻，可是一直因为太常见而被忽视[1]，质量普遍十分差，没有脚注参考或者列出参考[2]，例如麻绳、鲍鱼刷、地暖系统、篮子、竹签、肥皂盒、棉袄等等只有不到两百字，缺少例如筷托（英语：Chopstick rest）、纸板盒（英语：Carton）、油炸锅（英语：Deep fryer）等条目，希望可以借此引起重视，改善扩充内容。--User:What7what8🏠 2024年5月7日 (二) 18:52 (UTC)[回复]
哲学（和心理学）不是不行，就怕曲高和寡。反对生医、法律，这里有多少用户具备足够的专业知识去写这些条目（而不是胡搞蛮缠）呢？艺人和交通过于热门，是否有必要预留主题名额呢？毕竟过往设立部分主题的目的是为了充实中文版缺乏的内容。另外可以考虑把主题范围扩阔一些，例如艺人归并到流行文化、日用品归并到应用科学或工业等。上面Y. Sean君提到鼓励原创的问题，令我想起十年前刘嘉和胡水果等用户的论争，我的个人论述有传送门，当时我就大致表达了自己的立场（今年好像我也在别的地方讲过，但忘了在那儿也懒得查）。最后，我去年提过把所有专项主题废除，改为自然科学、应用科学、社会科学、文史地哲四大主题，这可能跟上面提到的“大中小混合动员令”类似（但不肯定），而且又可以省略长篇累牍的讨论和免除自肥嫌疑，但这样做会动许多人的蛋糕（包括自己的），最后没什么声浪，无疾而终，反正社群接受才算。--春卷柯南－发前人所未知 ( 论功行赏 ) 2024年5月7日 (二) 20:23 (UTC)[回复]
这种大项目的合并还要一并动到计分方式之类的，如果没人主导修改的话今年恐怕是来不及修改（我个人没那方面的知识就没办法了），可能得等结束要成文化时再一并处理吧。不过我个人觉得可以试试，反正要调整完才知道有没有用。剩下主题的反对与否可以等投票期再决定，照前年时程大概会募集到六月中旬左右。--WiTo🐤💬 2024年5月8日 (三) 03:34 (UTC)[回复]

我归纳一下上面提到的一些条目类别：

  • 哲学类
  • 非虚构书籍
  • 色情
  • 流行文化（含艺人）
  • 法律
  • 非洲
  • 生物技术
  • 医学
  • 饮食
  • 文化遗产
  • 非翻译
  • 交通（含交通设施）
  • 应用科学（家居及生活用品）

此外，我不反对春卷柯南的四大主题方案，但是（如果采用的话）四大主题的计分方式可能需要另外商定，比如同属非翻译条目、待撰条目等是否可以额外计分。Sanmosa 全方贫工之联合 2024年5月12日 (日) 02:21 (UTC)[回复]

我的初步想法是让社群商定自然科学、应用科学、社会科学、文史地哲四大主题中哪些主题是社群现阶段较为侧重的，将那些较为侧重的大主题定为中动员令，其他大主题定为大动员令，但条目如果同属待撰条目，可以升格动员令级别，即由中动员令升格为小动员令，或由大动员令升格为中动员令。这样应该不会动到具体的计分方式。Sanmosa 全方贫工之联合 2024年5月12日 (日) 02:28 (UTC)[回复]
大致来看(＋)支持，不过我对待撰条目的态度倾向于简单做加分处理（比如×1.5或者×2），升格动员令级别看起来有点怪，毕竟这条目不是真的和某个中/小动员令主题挂钩。另所谓“原创”主题应该有明显定义，是要全文原创，还是只需要大部分就行？——Aggie Dewadipper 2024年5月15日 (三) 18:20 (UTC)[回复]
（我还是倾向于把“原创”称为“非翻译”）我认为只要能合理判断条目的核心内容并非翻译就能算成非翻译条目，虽然我并不支持非翻译条目额外加分的做法。技术上（以{{DC21/art}}为准）你说的那种“简单做加分处理”跟我说的升格动员令级别的具体操作是一样的，见下：
现时中、小动员令的计分方式相当于按大动员令的计分方式计分后直接乘以2或3，把type参数里填的数字换掉就行，甚至你填4也不会出现技术错误（上面我也特别演示了这部分）。至于乘以小数的技术可行性见下：
“升格动员令级别”这个说法可能不算太好，但我跟你想的东西大致上是一样的。我个人倾向于×2，顺道把小动员令的分数加成改为大动员令的4倍（这点我之前也有提议过）。Sanmosa 全方贫工之联合 2024年5月16日 (四) 00:26 (UTC)[回复]
@Dewadipper。Sanmosa 全方贫工之联合 2024年5月16日 (四) 00:27 (UTC)[回复]
感谢说明，那我对您的提议没什么异议了，(＋)支持。——Aggie Dewadipper 2024年5月16日 (四) 02:27 (UTC)[回复]
@春卷柯南、T45614631。Sanmosa 全方贫工之联合 2024年5月14日 (二) 09:08 (UTC)[回复]
我个人没意见，看社群共识（或主持人想法），而目前提议的主题多是人文类的主题就是了。--WiTo🐤💬 2024年5月14日 (二) 09:25 (UTC)[回复]
你这样说的话，我可能得争取当上主持人了。Sanmosa 全方贫工之联合 2024年5月14日 (二) 11:06 (UTC)[回复]
本人还要提议二战类--August0422 2024年5月16日 (四) 10:19 (UTC)[回复]
基于对语言学和文化多样性的关心，提议语言（学）类和民族类。我还想提议“中国大陆互联网”主题，因为很多此类内容虽影响范围仅限于中国大陆一地，但影响人数众多，堪称具备了相当的影响力；而且相关条目整体质量令人十分遗憾。--CuSO4 · 龙年大吉 2024年5月16日 (四) 21:08 (UTC)[回复]
如果采用春卷柯南的四大主题方案的话，所有较小的主题实际上都会被四大主题包含。Sanmosa 人人皆王 2024年5月17日 (五) 06:40 (UTC)[回复]
当初我的想法确实是这样的，设立四大主题后，基本上就没需要设立新的单项（除了无法仅纳入一个领域的“跨学科”？），但由于范围过大（历届动员令中比四大主题还宽泛的主题包括“世界各地”和“科学”，但不多），所以都应该列为大动员令，这对大家都公平。把任何一个大主题指定为中、小动员令，视乎情况，仍然有可能构成自肥嫌疑（假如获升级的主题跟社群大部分人的主力范围重合），但是“升格动员令级别”在原则上倒是不反对。--春卷柯南－发前人所未知 ( 论功行赏 ) 2024年5月24日 (五) 01:00 (UTC)[回复]
跨学科的主题在我理解中相当于同时属于多于一个四大主题类别的主题，这种情况我认为提报人想提报到哪个类别都可以（又或是让跨学科的条目也升格动员令级别也不是不行）。自肥嫌疑我倒是觉得不至于，真要这么说的话，以前选中小动员令主题的时候投票的人实际上都是想自肥，但以前的办法不还是沿用了好几届DC了吗？（虽然我不反对全部列为大动员令就是了）Sanmosa 人人皆王 2024年5月24日 (五) 02:00 (UTC)[回复]
在下推荐物理、化学、生物、历史、地理。--飞马（闪亮飞月） 2024年5月27日 (一) 14:42 (UTC)[回复]

主持人[编辑]

（占位）—— Eric Liu 創造は生命（留言・留名・学生会） 2024年5月3日 (五) 13:56 (UTC)[回复]

以下参照DC20、21的时间、规则、提议调整：
主持人资格：
在提名期开始之前（2024年5月17日 (五) 00:00 (UTC)）取得延伸确认用户资格，在提名期开始之前一年没有受到封禁（不合理封禁除外）。
提名规则：
  • 可以自荐或以他荐方式提名，他荐者仍须取得被提名者本人在提名时间结束前（2024年5月31日 (五) 00:00 (UTC)）的明确同意，否则视为拒绝该提名。
  • 每条自荐、提名、谢绝被提名告知或其他相关言论后必须签名，否则视为无效。
时程：
提名期：2024年5月17日 (五) 00:00 (UTC)起至2024年5月31日 (五) 00:00 (UTC)止。
冷静期：2024年5月31日 (五) 00:00 (UTC)起至2024年6月5日 (三) 00:00 (UTC)止。
投票期：2024年6月5日 (三) 00:00 (UTC)起至2024年6月12日 (三) 00:00 (UTC)止。
投票资格：
  • 投票者应在投票开始之前成为延伸确认用户，且未有一年内被禁止编辑站务页面（不合理封禁除外）的纪录。每人只可投票一次，但可在选举期内改票，改票次数不限。候选人不可以给自己投票。
  • 当选主持人的支持票应超过其总票数的2/3，且支持票数超过反对票数至少8票。
  • 每位候选人可以提供一份约100字的自述供投票人参考。
  • 在日后创建的表格中投票。可以投支持、中立、反对票。支持票，请用〇表示；反对票，请用×表示；中立票，请用=表示。也可以把其中一格留空，不给某候选人投票（不计入总票数）。
  • 废票请以红色标示。

以上调整仅有时间部分及DC20筹备纪录中所说“过去一年内被禁止编辑站务页面的用户不得参选或投票”，如果确定没问题想在稍晚后就开始公示该时程。但主持人跑路问题可能需要社群共识，去年如玖宸阁下所说的“可以请主持人们自行讨论决定是否给予跑路主持人军师头衔”的提议我个人觉得还挺好的。—WiTo🐤💬 2024年5月6日 (一) 03:55 (UTC)[回复]

现就该时程及规则（不含跑路处理一事） 公示7日，2024年5月14日 (二) 03:57 (UTC) 结束。—WiTo🐤💬 2024年5月7日 (二) 03:58 (UTC)[回复]
公示已通过。不过提名是要在这里提还是要改到讨论页内啊？--WiTo🐤💬 2024年5月14日 (二) 05:13 (UTC)[回复]
怎说呢。我承认上届我参与比较少，原因是脚本太难用了。经常就是我审完一个条目，然后不知道哪处的参数填错，又或者没编辑到哪一个页面，结果要全部回退由其他人处理。结果就不太敢审条目了。如果可以简化一下程序，相信参与主持人意愿也会比较高。去年好像没有“自行讨论是否给予跑路主持人军师头衔”的过程，结果好像是自己颁给自己来着的。考虑到自己参与工作比较少，我没有给自己的用户页加“军师”的头衔就是了。--Ghren🐦🕓 2024年5月16日 (四) 09:00 (UTC)[回复]

自荐与提名区[编辑]

没有人自荐或提名他人吗？那我就自荐了。Sanmosa 人人皆王 2024年5月17日 (五) 06:42 (UTC)[回复]
补充说明一下：我是两年前的动员令的主持人。Sanmosa 人人皆王 2024年5月18日 (六) 14:33 (UTC)[回复]
自荐。去年担任了主持人，受益匪浅，今年愿意与各位共同努力。--在下荷花，请多指教（欢迎签到） 2024年5月18日 (六) 11:02 (UTC)[回复]
自荐，同在去年担任主持人，希望今年也能有幸出一份力。——Aggie Dewadipper 2024年5月18日 (六) 13:43 (UTC)[回复]
自荐，曾担任三届（第十五至第十七次）主持人，今年有兴趣再协助活动行政。--Richard923888 Glory To HK 2024年5月20日 (一) 18:17 (UTC)[回复]
自荐，前两届的主持人，应该都勉强有空帮忙的。—achanhk ポケモンゲットだぜ！ 留言板 2024年5月25日 (六) 11:00 (UTC)[回复]

规则[编辑]

（占位）—— Eric Liu 創造は生命（留言・留名・学生会） 2024年5月3日 (五) 13:56 (UTC)[回复]

我想问一下，DC条目需要至少3500字节的规则是谁在何时定的？Sanmosa 全方贫工之联合 2024年5月16日 (四) 00:30 (UTC)[回复]
新条目字节限制是随时间增加的，大概自DC4起有2000字节限制、DC9变成3000字节，最后一次应该是在DC12经由投票决定变成3500字节的（当时总结该次投票的是小跃阁下）。--WiTo🐤💬 2024年5月16日 (四) 03:13 (UTC)[回复]
考虑到DYK的要求是3000字节，我建议把DC条目的最低要求revert回3000字节。（另一方面，对于只有六个人参与的投票到底能不能达到任何有效的结论，我存在很大的疑问）Sanmosa 全方贫工之联合 2024年5月16日 (四) 04:44 (UTC)[回复]

其他[编辑]

（占位）—— Eric Liu 創造は生命（留言・留名・学生会） 2024年5月3日 (五) 13:56 (UTC)[回复]

举办时间部分，我个人想提议使用与之前数次动员令相仿的举办时间，即7月13日至9月15日，共64天。（有稍微查了一下，至少自DC12起都是63~65天左右的长度，DC16当时也有类似问题而最后决议多一周，惟当时惯例是7月第一个星期六起至9月第一个星期日结束）之后如要像春卷柯南阁下所说要将之后的动员令合编为成文规则的话，也会比较有传承性，就是“7月第二个星期六”起至“9月第二个或第三个星期日”结束，补至约64天上下的长度。--WiTo🐤💬 2024年5月4日 (六) 04:34 (UTC)[回复]
以往选择这个日期，大多都是因为这是学生的暑假，有利维基人工作吧。把日期向9月后推似乎就不太达到这个目标？--HW（讨论 贡献） 2024年5月5日 (日) 15:50 (UTC)[回复]
@Waihorace：挪回之前的7月第一个星期六也可考虑。过往（DC18）延后到第二周似乎是因受到疫情影响后延，并一路维持至DC21，现在可能是个合适的时机，将其提回原本的时间？但这样筹备可能得快一点了。
还望其他人能提出看法，目前大概是这几个选项可考虑：
  • 7月6日至9月8日，共64天
  • 7月13日至9月8日，共57天
  • 7月13日至9月15日，共64天
--WiTo🐤💬 2024年5月6日 (一) 03:06 (UTC)[回复]
非常抱歉本人并没有参与过动员令的相关讨论，毕竟也没有加入维基多久，如果有些地方存在冒犯请各位见谅
本人认为7.6-9.8是一个相对更好的选项，正如HW所说，这个时间更大地覆盖了暑假时间。不过似乎这几个时间在宏观上没有太大区别（微观上可能存在个人在某段时间内有事？），感觉也很难有一些合理的论据来讨论，干脆今年就将日期选一个定下来（也是各位正在做的事？）
我也不知道发生了什么，似乎我写的剩下的内容没发布出去……只能来编辑下原始码，但绝没有改变各位的留言，当然，签名日期是删了重签的
个人根绝，因为宏观上区别不大，所以似乎投票等等方式都没啥用，本人也没啥想法，只是提供一点点思考，还请各位多多包涵！——这是不想改签名的Ghrkya（主页|讨论|签名） 2024年5月6日 (一) 16:08 (UTC)[回复]
(！)意见：WP:DC17也是7月6日00:00（UTC）至9月8日23:59（UTC），也是65日。个人认为只要是9月第二个星期日结束便可以。即是今年的DC为7月第一个星期六开始，明年可以回复至7月第二个星期六开始。--132.234.229.20（留言） 2024年5月7日 (二) 04:27 (UTC)[回复]
支持IP的提议 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年5月7日 (二) 07:41 (UTC)[回复]
(！)意见这样可能会导致每年都需要对时间做一次重复的讨论甚至是争辩。个人认为相比于直接确定时间带来的一些固化所产生的后果，每年一次的讨论看起来更加不必要。--——这是不想改签名的Ghrkya（主页|讨论|签名） 2024年5月7日 (二) 15:41 (UTC)[回复]
相对于客栈煮的其他话题，每年讨论一次动员令日期花费的时间实在是微不足道 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年5月14日 (二) 01:38 (UTC)[回复]
那确实是如此，不过之后如果要固定化的话也比较省事。--WiTo🐤💬 2024年5月14日 (二) 02:59 (UTC)[回复]
就讨论方向看来有共识，所以就以“7月6日至9月8日，共64天”一案 公示7日，2024年5月21日 (二) 05:19 (UTC) 结束。--WiTo🐤💬 2024年5月14日 (二) 05:19 (UTC)[回复]
应该确实有共识
唯一就是希望能够将这个时间通过社群讨论的方式确定下来，以免往后再出现此类浪费时间的无意义讨论。不过本人并不熟悉相关流程，请问是否有什么办法将其固定呢？--——这是不想改签名的Ghrkya（主页|讨论|签名） 2024年5月15日 (三) 12:47 (UTC)[回复]
公示通过。另固定的话我猜得另开一个话题讨论吧。--WiTo🐤💬 2024年5月21日 (二) 10:01 (UTC)[回复]
好的，谢谢您--——这是不想改签名的Ghrkya（主页|讨论|签名） 2024年5月22日 (三) 05:02 (UTC)[回复]

2024年非洲月筹备讨论[编辑]

原标题为：关于第三次非洲月

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:维基百科非洲月/2024。

去年非洲月在6月举行，取得了不少条目贡献，本人有意在今年同期继续举办非洲月，不知各位意向如何？

另Ping去年的主持人和活跃参与者@A Chinese ID@Tokisaki Kurumi@Newbamboo@Allervous@Alankang@Oscar0123@Baomi@BrianBYBYBY@AOrdinaryEditor@桃花影落飞神剑@T45614631@Nostalgiacn，如有打扰非常抱歉。——Aggie Dewadipper 2024年5月4日 (六) 22:04 (UTC)[回复]

(＋)支持虽然我很好奇为什么今年也会是6月而不是5月。--Allervous初音ミクのセーラー服 2024年5月4日 (六) 22:07 (UTC)[回复]
同上，我也想问。不过整体上是支持办的（虽然个人今年六月较忙恐生不出完整条目）。--WiTo🐤💬 2024年5月5日 (日) 00:42 (UTC)[回复]
(＋)支持在哪个月都好--苞米(☎)💴 2024年5月5日 (日) 00:45 (UTC)[回复]
(＋)支持，但可惜今年各方面压力都比较大，在下确已经抽不出时间来参加了；深感抱歉。--  2024年5月5日 (日) 15:45 (UTC)[回复]
(＋)支持，预祝成功。----FradonStar|八闽风云 2024年5月7日 (二) 00:56 (UTC)[回复]

：目前来看似乎没有反对意见，那暂定非洲月于6月1日0:00至6月30日23:59（UTC）举行，考虑到时间较为紧迫就先擅自在底下开始主持人招募了。话说在6月举办应该是没人想起来 囧rz……。——Aggie Dewadipper 2024年5月6日 (一) 06:34 (UTC)[回复]

今年就算了，不过来年或可考虑合并动员令与非洲月，集中有限的编辑量能。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年5月12日 (日) 02:56 (UTC)[回复]

主持人招募[编辑]

烦请有意担任本年非洲月主持人者在下方留言示意。招募期暂定于5月20日 00:00 (UTC)结束。——Aggie Dewadipper 2024年5月6日 (一) 06:34 (UTC)[回复]

来了。今年比较没有空写条目，但打杂，帮忙看条目还是可以的--A.K. 留言※签名 2024年5月6日 (一) 07:17 (UTC)[回复]
以及，我本人也有意主持此次活动。——Aggie Dewadipper 2024年5月7日 (二) 00:59 (UTC)[回复]
我，今年我暑假不用做事--August0422（留言） 2024年5月7日 (二) 08:29 (UTC)[回复]
阁下之前参加过非洲月吗...--人间百态,独尊变态(讨论) 2024年5月12日 (日) 08:11 (UTC)[回复]
这位阁下（的账号）今年年初才开始编辑，是一定没有的。--WiTo🐤💬 2024年5月12日 (日) 08:48 (UTC)[回复]
6月中旬过后大概有时间，争取一下 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年5月14日 (二) 01:36 (UTC)[回复]
行，我也兼一下非洲月主持人吧，毕竟当初办非洲月就是我提议的，另一方面我有当亚洲月主持人的经验。Sanmosa 人人皆王 2024年5月17日 (五) 15:06 (UTC)[回复]
@Dewadipper：后续如何处理？Sanmosa 人人皆王 2024年5月20日 (一) 11:41 (UTC)[回复]
先前几次文化月都没有对主持人有遴选，如果没有反对意见我认为目前四名自荐者（AlanKang、魔琴、Sanmosa和我本人）可直接默认为本次非洲月的主持人。——Aggie Dewadipper 2024年5月20日 (一) 21:24 (UTC)[回复]
不反对。那相关页面是否也可以直接设置？Sanmosa 人人皆王 2024年5月21日 (二) 02:31 (UTC)[回复]
应该是可以的。不过我近期忙于期中考试，可能要到24日左右才有空设置页面。—-Aggie Dewadipper 2024年5月22日 (三) 04:47 (UTC)[回复]
Wikipedia:维基百科非洲月/2024页面开好了，请查看内容是否需要调整。fountain 五月初已申请，申请时填写的主持人为 Dewadipper君与我，由于我不是管理员，无法调整参数。--A.K. 留言※签名 2024年5月22日 (三) 09:50 (UTC)[回复]
主页面看上去没大问题。fountain用不用我重新开一个？按道理如果fountain是你自己动手开的话，你应该是可以调整相关设置的。Sanmosa 人人皆王 2024年5月22日 (三) 10:45 (UTC)[回复]
fountain我是按照m:Wikipedia_Asian_Month/Fountain_tool/zh所述方式开设，当初我送出后变成draft，过几天后就通过了，如该页面所述“管理员审批过程”、“更改设置”必须拥有Wiki-project管理员权限才能更改。目前我在fountain的非洲月2024页面上可进入设置页面，但无法更改。--A.K. 留言※签名 2024年5月23日 (四) 00:12 (UTC)[回复]
@Alankang：那我重新开一个吧，不知道链接是否有效。Sanmosa 人人皆王 2024年5月23日 (四) 09:18 (UTC)[回复]
@Sanmosa：您开的那一个还无法读取，应该还在draft状态（可能是需要管理员核准），我开的这个 fountain的设置页面 已请Eric Liu 君帮忙添加您与魔琴君，您可以查看一下设置是否合适。--A.K. 留言※签名 2024年5月24日 (五) 06:24 (UTC)[回复]
还需要在Template那边勾选automatically add template，模板名称WAfM talk 2024，放置位置设置为讨论页。Sanmosa 人人皆王 2024年5月24日 (五) 09:36 (UTC)[回复]
已完成。--A.K. 留言※签名 2024年5月26日 (日) 13:19 (UTC)[回复]
不熟悉fountain更改设置的设置，但是之前办的活动改主持人时是确实是直接重开一个的（） ——魔琴［身份声明 留言 贡献 新手2023］ 2024年5月24日 (五) 10:55 (UTC)[回复]

Question: Can English read English Wikipedia Clearly?[编辑]

已关闭：
无关于本站的问题。另外话题发起人的英语水平可疑，如果A2都没有的话还是别去英维申请IPBE了。 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年5月25日 (六) 05:43 (UTC)[回复]
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

The English Wikipedia is read difficulty. A man can be only read Simple English Wikipedia clearly. That because of the English Wikipedia have a lot of difficult word, it out of our talking use word maximum.

Who can give a solution for it?

For help English to understand so I use the Chinese. Welcome to English to solve this question. Thanks for create a posting in English Wikipedia(I no IPBE in English Wikipedia).--GX01（留言） 2024年5月24日 (五) 08:49 (UTC)[回复]

如果你需要锻炼英语技能，也许还有更好的方式。一般来讲，编辑者应该以最易于理解的用词编辑百科，但很多表音文字语言中隔行如隔山，很多时候并不容易很好地照顾到所有读者。--Sheep-realms（留言） 2024年5月24日 (五) 09:17 (UTC)[回复]
确实，编辑者不应该使用生僻词。--GX01（留言） 2024年5月25日 (六) 03:42 (UTC)[回复]
学好英文，适当提高词汇量，再不济，用好机器翻译工具来转换为你熟悉的语言（或者可能是你的母语）。这种事不是跟英文维基反馈就能解决，就好像英文老外希望中文好学点，就像他们母语英文那样好学那样。——Sakamotosan路过围观 | 避免做作，免敬 2024年5月24日 (五) 09:46 (UTC)[回复]
是的，维基人确实应该提升词汇量。但是英文维基百科的编辑者不应该使用生僻词，应该使用非母人士语能够容易理解的单词。--GX01（留言） 2024年5月25日 (六) 03:42 (UTC)[回复]
错了，你无法理解作为现时普遍语言的英文应有的水平，或者你的词汇量不足以支持你去阅读英文维基，是你的问题，不是英文维基百科的问题，或者说你的能力只能够满足去阅读简化英文维基百科的能力。而且这个问题你更应该去英文维基百科那边抱怨，在这里抱怨并没有什么作用，毕竟不同社群互不干涉。——Sakamotosan路过围观 | 避免做作，免敬 2024年5月25日 (六) 04:14 (UTC)[回复]
我的英文维基百科没申请IPBE，无法编辑。而且主要是英语太难理解。理解英文维基百科需要的词汇量至少8000。我在材料1有说明。--GX01（留言） 2024年5月25日 (六) 05:03 (UTC)[回复]

Data 1[编辑]

According to English Wikipedia en:Wikipedia:Make technical articles understandable's article with Hemingway Editor, Result is: 

5 of 8 sentences are very hard to read.

1 of 8 sentences is hard to read.

Find grammar and spelling issues with Editor Plus.Upgrade

7 uses of weak language. Cut to 3 or fewer.

1 word with a simpler alternative.

There is a picture using Luguo Image Bed: https://imgse.com/i/pklPbDO because the Wikipedia picture uploader was not working. --GX01（留言） 2024年5月25日 (六) 05:03 (UTC)[回复]

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

设立法轮功为高风险主题[编辑]

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:高风险主题。

设立原因及原方案请见Wikipedia talk:高风险主题#设立新兴宗教为高风险主题。
法轮功页面自2005年起，已经被反反复复保护超过40次以上；讨论页也无幸免、打辩论的经典副本。
具体措施：

--Benho7599 | Talk 2024年5月26日 (日) 02:10 (UTC)[回复]

(＋)强烈支持，并建议将回退零容忍扩张至李洪志等关联条目。就最近讨论来看参与各方难以形成共识，导致编辑战频发。—Aggie Dewadipper 2024年5月26日 (日) 17:12 (UTC)[回复]
李洪志实际上似乎也十分需要0RR--Benho7599 | Talk 2024年5月28日 (二) 15:27 (UTC)[回复]
(＋)支持。从讨论页上连篇累牍的争执可以看出，法轮功是风险最高的政治相关主题之一。--CuSO4 · 龙年大吉 2024年5月26日 (日) 19:52 (UTC)[回复]
(＋)倾向支持WP:1RR 代替WP:0RR -Lemonaka 2024年5月27日 (一) 06:50 (UTC)[回复]
Skeptical toward whether 1RR would work. The current issue is that participating editors do not seek for consensus at all.--Aggie Dewadipper 2024年5月28日 (二) 05:20 (UTC)[回复]
不反对。Sanmosa 人人皆王 2024年5月28日 (二) 11:50 (UTC)[回复]

是不是创建一个披露过滤器细节的规范比较好[编辑]

我希望知道，披露某个编辑的哪个字眼触发过滤器，是否是可以的。比如说，披露“黑人警察”四个字触发过滤器是可行的吗？披露“收购”触发过滤器也是可行的吗？如果认为这种程度的披露是可以接受的话，我觉得我运用权限就能有更多的自由。我申请过滤器助理的原因之一就是处理这种情况。--MilkyDefer 2024年5月27日 (一) 16:25 (UTC)[回复]

又或者说，我以后是否可以依照“您编辑中的XXX字样触发了过滤器YYY中用以阻挡ZZZ等类似字眼的过滤规则”的句式来回应。此外，此等消息是否真的要闹到客栈长篇大论后才能披露，以闹取胜？--MilkyDefer 2024年5月27日 (一) 16:30 (UTC)[回复]

关于“Save to”和“Moved to”[编辑]

现时{{Save to}}和{{Moved to}}模板提供将讨论移动至多个讨论页的选项，然而有用户指出这有“若有人添加留言，则变成讨论闹多胞”的问题。我想Move to的逻辑能否修改成存档至一主页面，然后在其他页面提供“X处有和本条目相关讨论的”的导引，或者以{{#section-h:主页面|讨论标题}}的形式在其他页面存档。谢谢。Ghren🐦🕒 2024年5月28日 (二) 07:15 (UTC)[回复]

(＋)赞成：像重定向到某条目一样可以集中讨论，然而反对强制限于主页面讨论。 -- 月都 ※ 2024年5月28日 (二) 10:12 (UTC)[回复]
@Ghren：你说的是否{{save to}}？Sanmosa 人人皆王 2024年5月28日 (二) 11:49 (UTC)[回复]
标题指的是“Moved to”，不知何故被重定向至“Vmp”模板。不过“Save to”也可一并加上。Ghren🐦🕗 2024年5月28日 (二) 12:08 (UTC)[回复]
不支持，这两个模板几乎都是用在存档的情况，要配合集中讨论制度另开模板比较好，另您这完全没考虑导引失效的问题--SunAfterRain 2024年5月28日 (二) 13:13 (UTC)[回复]
取自“https://zh.wikipedia.org/w/index.php?title=Wikipedia:互助客栈/其他&oldid=82816174”